Hi,
Finally my ISP is providing my DOCSIS broadband link IPv6 addresses in dual-stack. So I went to recreate my firewall settings for IPv6 and for my surprise I noticed in RouterOS v6.34 there is no tarpit action for firewall rules.
Mikrotik developers, please consider implementing this feature in the next releases and other to shorten the gap between IPv4 and IPv6 firewall. Thanks in advance.
well-spotted, but personally i slightly more aboutabsence of NAT in IPv6 firewall(which DO exist in IPv6 too, yep).
Isn’t the reason for IPv6 to have flat wholeworld network routed without natting?
yes, no, yes, no, yes, no.
but seriously-talking: its VERY complicated to asnwer “Properly”:
and NO, despite numerous misconceptions IPv6 range is NOT flat, despite size.
IPv4 was flat, but IPv6 was seriously HIERARCHY-based. there was TLA, NLA and other levels and possible mecanics to deprecate/phase-out and upgrade various services(like say DNS for example)for more modern counterparts/replacements, aswell as fine-grained control(both from legal and technical perspectives), responsibilities.
thats why aside various “transition” or edge-only things like 6to4, 4to6, DSL and alikes
(464XLAT, 6rd, teredo, isatap… you name it. depend purpose/context), NAT64 - remain the MOST-DEPLOYED service in IPv6 networks aswell as it in IPv4 segments of ISP networks. while huge/behemoth ISP rely on more serious “Carrier-grade”(usually proprietary/tweaked forks/implementations)NAT, smaller companies deploy NAT64 aswell(which allow to transparently converge Ipv4 and IPv6 networks, btw)
also competing company - develop IPv6 version of NPT under “MAP” nickname to boost NAT traversality of.
for further details about NAT64(for example) - check relevant wiki https://en.wikipedia.org/wiki/NAT64 and RFC
https://tools.ietf.org/html/rfc6052
https://tools.ietf.org/html/rfc6146
http://tools.ietf.org/html/rfc6877
http://blog.apteriks.com/2012/12/08/ipv6-nat64-power-and-limitations/
my botton line:
Anyone else interested in NAT give a thumbs up on this feature request thread http://forum.mikrotik.com/t/feature-request-ipv6-nat66-support/82264/1
Isn’t the reason for IPv6 to have flat wholeworld network routed without natting?
This is just the propaganda spread by the IPv6 evangelists. In the real world there is no such thing as end to end connectivity. period.
Academia can theorize all they want. What will be adopted in the end is dictated by business not some engineer’s wet dream of how the world should be.
If Juniper implemented NAT on IPv6 then there is a business (and not just any business but enterprise business) need for it no matter what the IPv6 evangelists say.
No one should dictate how I set up my network and why I would wanna use NAT (with all its drawbacks admittedly). No one.
What’s next? Forcing us to stop using firewalls to enable true end to end connectivity to satisfy a few network engineers?
This is nonsense. End to end connectivity it’s just BS IMHO.
And to get back on topic, yes I would like to see tarpit (along with pretty much anything else already implemented on IPv4 firewall) on IPv6.
NAT64/NAT46/NAT66 is crucial, yep.
p.s.
anything is myth/mirage according to Zen/Dao/hindu masters 
That is (was) very important thing to do. It was clear that IPv6 NAT would come eventually, but it would have been bad, if it happened too soon. If it was available right from the beginning, I don’t want to imagine how many ISPs would use it as standard #1 and give just one IPv6 address per customer, because “it worked so great with IPv4”. Now that everyone is aware (hopefully) that things can work without NAT, we can have it for those who have good reason to use it. 
Very impressive answers, guys. I haven’t expected that. Sorry for my ignorance to the IPv6 topic. I am still living fine without it and hope I can survive further.
Let me give you another good reason for NAT66.
You want to use IPv6 internally in your network. Your ISP hands out dynamic /64 prefixes. Now how would one expect to have a static internal network with full IPv6 acces? A simple NAT between prefixes solves this fully.
In reality, the ISPs should probably be assigning static IPv6 prefixes to customers, but old habits die hard.
I’m in the “let’s kill nat” crowd, but I understand the reasons why it is still useful - dynamic provider-assigned prefixes is a big one.
Transparently Intercepting / redirecting the destination address of packets is another very useful thing that can’t be easily done otherwise.
“My host is globally-addressible” is NOT a reason because stateful firewall is what makes the devices inaccessible in IPv6 and IPv4. The fact that the inside address happens to be un-routable is secondary to the discussion. The black-hat crowd has long ago found many ways to get at internal resources without needing direct inbound communication. Usually, an infected box behind the NAT is all it takes to get inside scanning/attacking operational, and there are lots of ways to get a LAN client to invite the evil inside the firewall.
If you have local resources that don’t need Internet access, there’s always the fd00::/8 globally unique private addressing range to use.
Load balancing / fault tolerance could be done using MPTCP, for instance if you have multiple connections which give multiple prefixes to use, so you wouldn’t need to use masquerading to accomplish this task in a world that has adopted MPTCP.
I guess I’m just saying that we shouldn’t chain ourselves to the past just because “that’s how it’s done.” Too many times, I’ve seen engineers and executives give very stringent requirements that such-and-such a feature behave a certain way, when in fact, it’s not the feature itself they’re concerned with but a certain objective. Sticking to this design has often led to strange configurations and finnicky work-arounds that take newcomers to the organization by surprise because something so “custom” was being done that they inadvertently broke it by doing something that would otherwise be straightforward.
If an objective can be met in an entirely different fashion, then it shouldn’t matter how it’s done so long as the underlying solution adequately addresses the requirements of the objective and is a sound solution in its own right. I’ve simplified many projects by going to the decision makers and saying “hey, it’s not really this feature that you want, right? What you REALLY want is just this. We can do it this other way, and give what you need - why not let us do it this way?” That usually works.
A NAT isn’t simple nor needed. You’d just assign ULAs. This is even simpler than a NAT and solves the problem in an elegant way since you can have a dynamic global prefix from your ISP and an ULA prefix for local addresses. This gives you stable internal addresses (like a NAT) but you can still have end to end connections.
How well do modern devices understand the correct scope for ULAs? (not being snarky - actually hoping to learn from someone else’s hands-on experiences). If the host doesn’t understand the scope of a ULA as “site only” - then how does it know to use the global IP to talk to Google, but the ULA to talk to other ULAs, especially if you’re using multiple /48 ULA prefixes in your enterprise?
Actually, I have no idea, but so far it just works.
I have a global prefix from my ISP and use ULAs primarily to limit some services to my local network. E.g. my local unbound instance (a DNS resolver) answers only to queries from devices with addresses from my ULA prefix. I don’t know if this is a best practice, but it works perfectly fine for me.
Hmm - looks like time for me to build a lab.
Step 1 - get IPv6 connectivity deep inside a v4-only shop
Step 2 - ?
Step 3 - Profit!
I’ll post here with my results.