It would be really nice to add NAT66 support for IPv6 in ROSv7!

Thanks.

You mean NAT64?

No, I mean proper IPv6 NAT support.

As far as I know it is now supported on kernels 3.9+

Please give links to the RFC or description of what you mean.

IPv6 doesn't need any NAT by design The only NAT is needed to access IPv4 (NAT64)

Forgive me, I meant to say NAT66 (which is the proper term).

https://tools.ietf.org/html/draft-mrw-behave-nat66-01

Juniper has already implemented NAT66.
http://www.juniper.net/techpubs/en_US/j ... ml#jd0e173

IPv6 NAT

IPv6-to-IPv6 NAT (NAT66), defined in Internet draft draft-mrw-behave-nat66-01, IPv6-to-IPv6 Network Address Translation (NAT66), is fully supported by the Junos OS.

http://www.juniper.net/documentation/en ... rview.html

Also CentOS for example with kernel 3.7+ already supports NAT66
http://atoomnet.net/howto-ipv6-nat-in-centos-6/
http://kernelnewbies.org/Linux_3.7#head ... c118ba2beb

There is also an RFC about NPT (Network prefix translation) - also useful.
https://tools.ietf.org/html/rfc6296


Regardless of the RFCs though, I believe NAT66 is an extremely useful feature.
It would be a shame to not implement it when giants like Juniper do.

Since RouterOS is essentially linux based, and since the linux kernel in recent versions does support NAT66 it's merely a matter of integrating an already implemented feature on ROS UI/CLI (ok that's a speculation on my part, but I mean the hard work - implementation - has already been done ).

Please consider adding support for NAT66. I am sure many people will appreciate it.
It won't hurt those who oppose NAT but it will help those who need it for whatever reasons (good or bad - in network engineering terms).

I'm not for NAT66 but NPT (RFC6296 ) is in some configuration usefull for SME with multi homing connection to the Internet and linux kernel supports this. For this feature I vote.
But please - firstly policy routing for IPv6 (witout it is not multihoming NPT possible) and router advertisement with router selection priority (RFC4191 / cap 2.1 a 2.2).

If you need to use NAT with IPv6 you're doing something wrong..

If you need to use NAT with IPv6 you're doing something wrong..

No offense, but that's just a lame argument and you know it. By that logic if you are using NAT on IPv4 (which I am sure you do) then you are doing something wrong. There isn't right and wrong. NAT is just a tool among many others. Just because you don't need it or you don't like it doesn't make it 'wrong'.

Or just because the so called IPv6-evangellists say there shouldn't be NAT, that does not mean that there are not legit use cases for some networks.

What I really don't understand is what is the problem? If someone does not want to use NAT (for ideological IPv6 nonsense or because there is no need) then don't use it. But some of us need to use it so please enough with this 'propaganda' about NAT.

If Juniper - which is among the leaders that actually route the whole internet - implements it then there is a reason and a use for it.
I don't think that a company that deals only with enterprise clients would spend time implement a feature that wasn't asked for.

I honestly cannot understand why anyone would oppose to a feature that they don't need. If you don't need it just don't use it. Don't deprive the rest of us of the opportunity to have it.

Ok. NAT66 is wrong.

Let's see...
You have a private network, and IPv6 IPs assigned to your machines from one provider.
Now you want a secondary provider as redundancy for outgoing IPV6 access, and that provider hands you out another IPv6 subnet (maybe even dynamically assigned).

Except paying a lot of money to have your own IPv6 subnet and publish it via BGP on both providers, can you offer a solution to have this redundancy AND not change network's internal v6 IPs other than NAT66?

Second use case:
A slower static IPv6 subnet from one provider. A high speed dynamically assigned IPv6 subnet from a second one. You want to have incoming connection on the first, outgoing connections for the internal machines on the second... Any other (cheap) solution except NAT66?

Both scenarios handle IPv6 natively without NAT66 or BGP peering with PI prefixes....
First scenario (active-backup multihoming) I uses in combination with Mikrotik routers on many places for years.
The second (active-active multihoming) is not possible with Mikrotik because ROS do not have support for IPv6 policy routing.
Well, for the second example is now simplest way to use NPT - network prefix translation (RFC6296). that other mechanism (default source address selection configuration and so on). So support for NPT will be nice for this situation in some enviroments - but first, there is missing policy routing for IPv6 (and router preference adverstiment) as background for active-active multihoming in any way.

Ok. Got it now.
Basically both situations can in fact covered by NPT (I have always regarded that one as a kind of NAT).
Tnx. for clarifying this to me.
So +1 for NPT.

Yes, with NPT or any other IPv6 NAT variant looks configurtation a bit simplest that to use dynamic renumbering and so on.... But, but - do you tried to use any form of the IPv6 NAT in real life?
I did it and very fastly leave it. This NAT break end-to-end transparency and there are protocols that expect it. When I tested this last time the linux IPv6 NAT was able handle only active FTP.
But protocols like IPsec, SIP VoIP, MIP, ... was not able operate over IPv6 NAT. And if you look deeply in some RFC editorials about IPv6 NATing / IPv6 multihoming and there are recommendatitons for the IPv6 NAT implemetation to not implement any protocol helpers, a recommnedation for the application developers/protocol designers to not complicate their products/protocols with NAT traversal extensions becouse IPv6 NAT is inot intended as mainstream solution...

Regardless of what some applications/protocols do or don't, having some form of NAT (at least NPT) in your toolbox is useful.
Not all networks are the same, or are able to change because of this arbitrary 'requirement' of end to end connectivity.
Plus not all networks are connected to the public internet but may need a quick n dirty 'gateway' to it without changing tons of IPs just 'because'...

We've all used FTP, SIP, and all of that jazz for 2 decades now with NAT. Yes, it's not perfect, nor 'right' but just because a few protocols require you to have end to end connectivity to work, does not mean that NAT becomes useless or even bad for all the other protocols out there.

Not all use cases are the same.

To put it differently, let's say I don't use RIP because I prefer OSPF or because I am just biased against it.
Should Mikrotik (or any other vendor) ditch RIP because I don't use or like it? Of course not.
I may not need it, but someone else might! I wouldn't go downvoting feature requests just because I don't need them. Especially when they don't interfere with my way of working (as I said, NAT is just a tool, if you don't want it don't use it).

can someone please explain why there isnt ipv6 (internet adress) to ipv4 (internal network) nat? Lets dont talk about masquerade, but what about 1:1 NAT?

I would +1 this, I have plenty of devices in my setup that I see no need in even having a public address (local media servers,printers) and if I wanted something public nothing is stopping me from assigning one of the /64 addresses to it. It may not be "needed" but I also don't want to have update all firewall rules anytime my ISP decides my currently assigned /64 needs to change. I want to be in control of my assignments ( which means I need a local pool to myself) and allow them to connect whenever I choose (NAT).

so far both NAT64 and NAT66 derrivatives are essential and handy.
and NPT-forks for IPv6 aswell, inlcuding rebranded versions from two biggest vendors.
but personally i care bout NAT64 and NAT46(yep, its exist TOO ж)bit more for obvious resons, yet ;=)
either way - NAT remain cornerstone of networking with or without IPv6 or TCP/IP itself(in different shapes/forms, then)

+1.

It would be really nice to add NAT66 support for IPv6 ...

+1

I am dual-homed residential customer and both my ISPs support IPv6.

IPv6 multihoming without BGP is nearly impossible to do "the IPv6 way", i.e. with two advertised prefixes on the same LAN, from the two routers of the two ISPs. Most people use NAT66 to have a predictable behaviour in case of single failure.

I use it with iptables, it is included in linux kernels since many years. Add it to the list of benefits of an upgraded kernel.

I believe stateless NPTv6 to be useful as well (it solves the use case above), but I do not have a production deployment at this time.

I have been using ND proxy for a while, on a OpenWRT device that I am now trying to replace with a mikrotik using bridge firewall + "use-ip-firewall", i.e. an ND bridge with IPv6 stateful firewall (same /64 prefix in the two interfaces). I am doing it in spare time, but if/when done I will keep you informed.

I asked if there would be extensions to IPv6 on a recent MUM (mentioning only policy routing as an example, as without that the NAT66 usecase is not valid either)
and unfortunately the reply was that MikroTik do not see much use of IPv6 and that new development on it cannot be expected before RouterOS v7.
(and of course we all know about that one...)

It is unfortunate, because indeed the Linux kernel in v6 can probably do all that we need to have at least some support for dual-uplink IPv6 without BGP routing,
just for load balancing and failover.

NETMAP needed.

not nat.

There is a real need for RFC6296 IPv6-to-IPv6 Network Prefix Translation. No, this is not Port Address Translation or Masquerading. It is straight, simple, 1:1 prefix swapping. It takes simple bitwise operations to swap prefixes. No connection tracking is required. No state is required. No, this isn't for the false sense of security that masquerading grants. The 1:1 mapping still requires a firewall.

A few days ago, I had to re-number all the servers on my local network because Comcast decided to give me a different IPv6 block, again. Devices on my network were broken for hours as they kept using the old IPv6 block until their DHCPv6 expired. Thank goodness for dual-stack because good ol' stable IPv4 came to the rescue.

I have a secondary DSL line from CenturyLink. They assign an entirely different IPv6 block. That entire block changes every single time the PPPoE client logs in.

I have consumer-grade Internet connections. My providers will never allow me to BGP announce my own IPv6 block or another provider's block.

If I want load-balancing or fault recovery for outgoing traffic, I can't do it. I can only DHCPv6 one provider's random IPv6 block on my LAN, or the other provider's random IPv6 block. Having to re-address everything when the primary provider goes down will still break everything until the renumbering is done.

NPT would solve a lot of my problems with IPv6 and two providers who hand out random IPv6 prefixes. If only I could have a static local block that never changes! Then, swap out the first 64 bits for the outgoing provider's block, whichever one it is, and whatever block they decide to give me that day.

Ideally, I would rather have a single static IPv6 prefix that is world-routable through either provider, but I can't see that happening for consumer-grade Internet connections. As long as they keep treating IPv6 prefixes like scarce IPv4 addresses by randomly assigning them, we need NAT66.

NETMAP needed.

not nat.

You mean NPT, and both NAT66 and NPT (or netmap) are types of NAT.

up

+1.

More need netmap for IPv6

Is more actually

I agree, NETMAP is a very useful tool. Its available in the linux kernel and some people could find it helpful.

Please do not deflect the subject saying that NAT is an insult and that it does not exist in IPv6.
We have lots of not-so-important tools implemented in RouterOS just in case, this can be another one.

Kindest regards

Yes indeed, but (unless that has changed by now) MikroTik do not see a need to work on IPv6 features as their customers do not request that.
(single requests made to employees do not count, what you need is a big distributor ringing the bell that they lose sales because large numbers of customers require better IPv6 support)

I have recently found a need for something like this as well due to my ISP playing games with changing out ipv6 prefixes underneath me without warning. Would really be nice if I could just renumber my internal network to use ULA and then translate to/from the appropriate prefix at my router.

Would be great to see action=netmap for ipv6 stack

Once again, I had to change all IPv6 addresses for services on my local network because Comcast changed my /60 for what seems like the sixth time. I am quite tired of this, so this time, I defined a ULA for my local network instead of changing all of my servers' addresses and reverse DNS zones to the new Comcast block. Since Mikrotik RouterOS still cannot do IPv6 Network Prefix Translation, I had to rely on a little Raspberry Pi 4 to do it through a tiny intermediate VLAN segment. I do not like this solution because it is a hacky workaround. I wish I could do this right on my Mikrotik CCR2004 border router and remove the extra bottleneck and single point of failure.

The new Linux kernel in RouterOS 7 should already be able to do prefix translation. It's not like Mikrotik needs to reinvent the wheel. All Mikrotik needs to do is allow us to define the prefix translation in using their RouterOS abstraction. We need a way to do the equivalent of either of these iptables commands:

Using the Linux Network Prefix Translation tables from the mangle table: (man: DNPT, SNPT)

Using the Linux NETMAP table from the nat table: (man: NETMAP)

This one little feature would immensely help all Mikrotik users deal with ISPs who dynamically assign and often change IPv6 prefix delegations on their customers.

Once again, I had to change all IPv6 addresses for services on my local network because Comcast changed my /60 for what seems like the sixth time. I am quite tired of this, so this time, I defined a ULA for my local network instead of changing all of my servers' addresses and reverse DNS zones to the new Comcast block. Since Mikrotik RouterOS still cannot do IPv6 Network Prefix Translation, I had to rely on a little Raspberry Pi 4 to do it through a tiny intermediate VLAN segment. I do not like this solution because it is a hacky workaround. I wish I could do this right on my Mikrotik CCR2004 border router and remove the extra bottleneck and single point of failure.

The new Linux kernel in RouterOS 7 should already be able to do prefix translation. It's not like Mikrotik needs to reinvent the wheel. All Mikrotik needs to do is allow us to define the prefix translation in using their RouterOS abstraction. We need a way to do the equivalent of either of these iptables commands:

Using the Linux Network Prefix Translation tables from the mangle table: (man: DNPT, SNPT)

Code: Select all

ip6tables -t mangle -A PREROUTING -i ${EXTERNAL_INTERFACE} -d ${GUA_BLOCK} -j DNPT --src-pfx ${GUA_BLOCK} --dst-pfx ${ULA_BLOCK}
ip6tables -t mangle -A POSTROUTING -o ${EXTERNAL_INTERFACE} -s ${ULA_BLOCK} -j SNPT --src-pfx ${ULA_BLOCK} --dst-pfx ${GUA_BLOCK}

Using the Linux NETMAP table from the nat table: (man: NETMAP)

Code: Select all

ip6tables -t nat -A PREROUTING -i ${EXTERNAL_INTERFACE} -j NETMAP -d ${GUA_BLOCK} --to ${ULA_BLOCK}
ip6tables -t nat -A POSTROUTING -o ${EXTERNAL_INTERFACE} -j NETMAP --to ${GUA_BLOCK} -s ${ULA_BLOCK}

This one little feature would immensely help all Mikrotik users deal with ISPs who dynamically assign and often change IPv6 prefix delegations on their customers.

Is NAT66 the same as NPTv6 though? I believe they are a different concept, different RFCs even.

My useless ISP gives only a single /64, you can imagine trying to subnet that. I'm moving to VyOS as soon as I can as they support NPTv6 natively.

On IPv6 I generally avoid NAT but see the need for NPT.

However, I do actually agree that in a few corner cases NAT66 can be helpful. I would never use it to NAT users, but in one case I am using NAT66 port forward for a RADIUS IP to avoid having to manually add dozens of clients as RADIUS clients. The NAT66 rule ensures that the RADIUS server sees all clients as actually coming from the same source IPv6 address. I don't see any harm in allowing it for such uses.

On IPv6 I generally avoid NAT but see the need for NPT.

However, I do actually agree that in a few corner cases NAT66 can be helpful. I would never use it to NAT users, but in one case I am using NAT66 port forward for a RADIUS IP to avoid having to manually add dozens of clients as RADIUS clients. The NAT66 rule ensures that the RADIUS server sees all clients as actually coming from the same source IPv6 address. I don't see any harm in allowing it for such uses.

As long as end-users' router/client devices still get the end-to-end principle (the whole point of IPv6), it should be fine. But keep in mind IPv6 was designed to make our lives easier by being stateless/ND/RADVD based.

The fact that it is designed to make your life easier does not mean that essential features have to be omitted for everyone!
When you can live without something like NPT and/or think that is easier for you, fine. But do not impose that limitation on others please.
There are several cases where such a feature is actually very helpful, as indicated by troybowman and also others.
When people think it is wrong, they are free to not use it.

Is NAT66 the same as NPTv6, though? I believe they are a different concept, different RFCs even.

You're right: NAT66 is not the same thing as NPTv6. The Opening Post originally asked for NAT66 six years ago, but many people in this thread have asked for NPT instead. NAT66 is the stateful port translation from a single overloaded address hack that we have to do for IPv4. On the other hand, Network Prefix Translation can be stateless and grants end-to-end connectivity. I can access any internal host using any protocol from the outside through the prefix swap (that is, if I allow them through my firewall). In IPv4 terms, Network Prefix Translation is as if your ISP would grant your connection an entire IPv4 /24 (class C) block which you then map directly to a private /24, with a 1:1 address relationship at layer 3, with no necessary knowledge of ports, connections, or whatever else is going on in layers 4 and above.

My useless ISP gives only a single /64, you can imagine trying to subnet that. I'm moving to VyOS as soon as I can as they support NPTv6 natively.

Have you tried setting your DHCPv6 client to ask for a /60 or /56 in the prefix hint? I did that when I was first messing around with IPv6 a few years ago, and Comcast miraculously granted a /60. If they don't, you should whine and rock the boat.

You can do prefix translation for a single /64, but if the router (i.e., Mikrotik) is not doing the translation, it would require proxying neighbor discovery, which has other issues because of the sheer size of a /64.

You can subnet the 18 quintillion addresses in a /64 if you turn on the managed flag in your router advertisements and use DHCPv6 instead of SLAAC, but the tradeoffs of doing this is a different topic.

My useless ISP gives only a single /64, you can imagine trying to subnet that. I'm moving to VyOS as soon as I can as they support NPTv6 natively.

Have you tried setting your DHCPv6 client to ask for a /60 or /56 in the prefix hint? I did that when I was first messing around with IPv6 a few years ago, and Comcast miraculously granted a /60. If they don't, you should whine and rock the boat.

Yes, I second this suggestion about the prefix hint. A lot of ISPs around here default to /64, but will give larger with a prefix hint. It is unfortunately commonplace that ISPs have to default to giving out /64's. The underlying issue is that a *lot* of home router vendors (D-Link, Linksys, Belkin, TP-Link, etc.) will expect the ISP to provide a /64 and only a /64. If you give those devices something bigger like a /56, they will take the entire /56 and place it on the LAN interface, which breaks SLAAC and then nothing gets an IPv6 address. We give our customers /56's and out of about 1500 customers, we have at least 200 customers who have routers that are affected by this. If I reduced the prefix size to /64, I would have 200 more customers using IPv6 immediately. The home router vendors for the most part don't care to fix this - contacting them gives such responses as "you don't need IPv6 anyway", which makes me suspect that they don't really care about IPv6 support and just add a half-baked version so that they can check the "IPv6" box in product comparisons with competitors.

There is a big thread on the BT (British Telecom) forum about people trying to get their home routers working with the BT IPv6 DHCP prefix delegation service. Loads of people in that thread were getting angry with BT because the router vendor support people were telling them that BT was doing something weird in giving them a /56 and that they should be giving them a /64 only. A few people of course responded that BT was doing the correct and recommended thing by giving customers a large enough prefix that they could at least have more than one subnet. After seeing that, I'm not too surprised that a bunch of other ISPs who elected to roll out IPv6 decided to use the /64 default to work around these horrible home routers, especially since if they did not, they could have angry customers calling them complaining b/c they were getting something other than a /64 and some first level D-Link support person told them their ISP was doing something weird and wrong.

Is NAT66 the same as NPTv6, though? I believe they are a different concept, different RFCs even.

You're right: NAT66 is not the same thing as NPTv6. The Opening Post originally asked for NAT66 six years ago, but many people in this thread have asked for NPT instead. NAT66 is the stateful port translation from a single overloaded address hack that we have to do for IPv4. On the other hand, Network Prefix Translation can be stateless and grants end-to-end connectivity. I can access any internal host using any protocol from the outside through the prefix swap (that is, if I allow them through my firewall). In IPv4 terms, Network Prefix Translation is as if your ISP would grant your connection an entire IPv4 /24 (class C) block which you then map directly to a private /24, with a 1:1 address relationship at layer 3, with no necessary knowledge of ports, connections, or whatever else is going on in layers 4 and above.

My useless ISP gives only a single /64, you can imagine trying to subnet that. I'm moving to VyOS as soon as I can as they support NPTv6 natively.

Have you tried setting your DHCPv6 client to ask for a /60 or /56 in the prefix hint? I did that when I was first messing around with IPv6 a few years ago, and Comcast miraculously granted a /60. If they don't, you should whine and rock the boat.

You can do prefix translation for a single /64, but if the router (i.e., Mikrotik) is not doing the translation, it would require proxying neighbor discovery, which has other issues because of the sheer size of a /64.

You can subnet the 18 quintillion addresses in a /64 if you turn on the managed flag in your router advertisements and use DHCPv6 instead of SLAAC, but the tradeoffs of doing this is a different topic.

I wouldn't bother with /64 for now, until networking vendors catch up with a more reliable solution for subnetting a /64.
More here: viewtopic.php?f=2&t=171140#p836595

I wouldn't hold my breath for ways to subnet /64. Personally I don't think that SLAAC in current form was great idea. Using /64 is terribly wasteful. Deriving IP address from MAC address turned out to be quite unfortunate. Fixing privacy problem with Privacy Extensions and the whole thing with temporary IP addresses that change all the time, doesn't make me jump from joy either.

But it's the only thing we have, it exists for over twenty years, and everything relies on it. There won't be any replacement any time soon. In theory, it's extremely simple, just allow use of any prefix length, let devices choose addresses randomly (it's going in that direction anyway), and beautiful new SLAAC2 is ready. And then just wait ten to twenty years before old devices die out and new ones implement it properly, so you'll be able to start using it as something reliable and compatible with everything. Assuming it doesn't fail either, because someone again messes something up.

The way forward is to slowly fix current mess. But really fix what's broken, not create workarounds that allow broken stuff to work. If home routers can't deal with larger prefix, then they are broken and users should get their money back. If ISPs give out single /64s to accomodate broken routers, they should not. If they give out single /64s because they think it's enough, they are wrong, and they should either fix it, or users should say "no thanks" and go elsewhere. And yes, I know how naive that is. But it's either that, or we'll end up with NAT66 (same kind as we have with IPv4) being "pretty normal" thing.

That said, of course RouterOS should support NPTv6 and NAT66 too, because those are tools that in some cases can be useful. Downside is that if it can also cover someone else's mistakes, there will be less pressure to fix them.

That said, of course RouterOS should support NPTv6 and NAT66 too, because those are tools that in some cases can be useful. Downside is that if it can also cover someone else's mistakes, there will be less pressure to fix them.

Sometimes the ISP does not consider it a mistake. E.g. there are places where it is considered to be "best practice" to give residential users a new address every day.
I think it has to do with the possibility to track people.
It would be better when there is NPT support that can be configured to use a fixed address on the local networks and translate it to the (prefix) address that the ISP has assigned that day.

Well, changing prefix is matter of opinion, I guess. I wouldn't want it, but I can see why somebody else would. Preferably it should be a choice offered by ISP. When I wrote mistake, I was thinking about giving only single /64 to user, because it's limiting and I don't think there's any way how it can be seen as advantage.

Yeah I would not want it either, and fortunately it is normal practice to give every home user a static /48 here (which also can be considered a bad idea and wasteful).
My use-case for NPT would be as one of the building blocks to enable balancing and fail-over on two different ISP connections to the same router without doing internet BGP routing.
(of course it requires more than that, like policy routing with route marking, and a per-connection-classifier like in IPv4)

The way forward is to slowly fix current mess. But really fix what's broken, not create workarounds that allow broken stuff to work. If home routers can't deal with larger prefix, then they are broken and users should get their money back. If ISPs give out single /64s to accomodate broken routers, they should not.

I agree, which is why we do not do this. However, users can at least request larger prefixes from ISPs that do implement such workarounds by using a prefix hint of /60 or /56. The thing I do not like about that is that it removes pressure from the home router vendors to fix their broken products. The good news is that I'm starting to see more and more new routers behave correctly, so the vendors seem to be slowly (and finally) starting to fix it.

Hi,

I would like to see this feature implemented as soon as possible.

Here in Hungary around my location are only ISPs delegating /64 prefix only and they are not even willing to discuss about other prefix. This is really unfortunate because I would like to have separate network for guests and other IoT crap to. The only mean as far as I understand ipv6 is that I have to assign ULA to the devices and do NAT somehow as I won't get any bigger prefix than /64 from any provider in my area.
I thought I could tinker with DHCPv6 and make smaller subnets than /64 until I read that Android is not implementing and will not implement DHCPv6. What? ;(

Now sorry to say that but I'm thinking about to ditch my Mikrotik hAP router in favor of RPi.

Now sorry to say that but I'm thinking about to ditch my Mikrotik hAP router in favor of RPi.

I haven't looked into the RPi world for "router" images to use - which one are you considering?

It's been a while since I've even touched my router at home. It just works, but I do want to implement NPTv6 because I too subscribe to Comcast and have the issues that troybowman mentions. I decided to try out ROS 7 beta on a CHR in GNS3 just to kick the tires a little, and was sad to see that there's still not 'nat' tab in the IPv6 firewalls menu.

NPTv6 is most certainly an almost mandatory extension to IPv6 support in RoS for real-world deployments.
- it doesn't break the end-to-end principle
- it is a lightweight tool to mitigate things like dynamic prefixes from clueless/apathetic ISPs who renumber your network for you every time the power goes off or your link reconnects
- it allows simple multi-provider failover in SOHO environments w/o requiring even PBR, but with PBR it can also do load-balancing for SOHO
- Using RA + SLAAC to "dynamically" renumber along with ISP is not fast enough for office environments.
- It's a very useful tool to have in the toolbox of a system (routerOS) that is one of the most versatile platforms out there, and not including this "just because" seems asinine.

I decided to try out ROS 7 beta on a CHR in GNS3 just to kick the tires a little, and was sad to see that there's still not 'nat' tab in the IPv6 firewalls menu.

Oh, sigh. I was hoping, but alas. Thanks for checking on this.

ZeroByte, thanks so much for chiming in! Your comments are always so informative and thoughtful. I hope Mikrotik will listen now. :)

You make good points about NPTv6 being practically mandatory. Just today, I had to renumber for a new IPv6 /60 delegation yet again because I swapped out my Comcast modem for a multi-gig MB8611. Thankfully, all I had to do was change my little Raspberry Pi's netmap prefix to one of the /64s in the new /60, add a route for it to the Pi from my router, and now I am visiting this forum's web page through the IPv6 netmap without having to renumber everything else on my network. If RouterOS would allow us to netmap, it could be all automatic. Dynamic IPv6 delegation without prefix swapping is a major inconvenience for anyone who runs Intranet services on their private network.

+1 or at least NPt
Nave no Idea how to do high availibility (or load balancing) with 2 different providers without this...
And no here its not possible to have an AS number routed on a private cheap internet connection.

To allow incoming connections for my private server at home, I added firewall rules in my Asus router to whitelist the server. Finally I could reach it from the internet. But unfortunately I had to learn that my ISP in Hungary (Digi) keeps changing the prefix as well. So I need to change the firewall rules manually which is very inconvenient and not practical. After reading into this topic, I've come to the conclusion that NPTv6 can solve this problem.

One solution seems to be explained here:
https://unix.stackexchange.com/question ... g-on-linux

Then I got to know MIkrotik and I was excited about RouterOS having many setting options, assuming I can change IPv6 firewall rules in depth easily. So I ordered one. Then sadly I read that the IPv6 support is very basic.

But it seems updates are coming!
IPv6 NAT support is arriving in RouterOS, I expect that I can try to implement above solution.

I am very pleased to see netmap listed in 7.1 in /ipv6/firewall/nat, as @Thoru pointed out. I'll be playing with this to see if I can get it to work as I would expect it to.

Hi, folks.

Could you, please confirm that the IPv6 NETMAP works properly in ROSv7.1.1 CHR? For some reason, I can't get it working. I dig deep into official documentation but there are even no words about the feature. From logs I see that it doesn't work as expected.

Microtik guys - could you, please, provide us several examples of how the feature can be configured?

Thank you in advance.

I tested the IPv6 NETMAP feature - it works the same as DSTNAT. It looks as if the feature is broken or just a stub feature... Also, there are SNPT/DNPT actions in mangle chains - they also work pretty oddly... Anyway, with no well-written documentation, we can just guess why these odd features were released. Ah, hopes, hopes... As we can see there Mikrotik still sleeps.

No, netmap works the same as netmap. Not the same as dstnat. When you think it works the same as dstnat you will not get it to work.

I don't think it works as dstnat. It works as dstnat. They are completely different things. I wish to think it works as NETMAP but it doesn't work as NETMAP. I tested it. Did you test how IPv6 NETMAP works? I did. Therefore I wrote that in current implementation the IPv6 NETMAP works the same as DSTNAT. And yep, I can prove it.

The difference between netmap and dstnat is that netmap works stateless and unidirectional, and dstnat keeps state and automatically does the mapping the other way.
With netmap you always need 2 maps.

It looks as if you didn't test the IPv6 NETMAP. I mean that DSTNAT forwards traffic to just one destination IP - it changes destination IP. NETMAP must not even touch the destination. It must change the source IP prefix to another specified prefix. It is what NETMAP (1-to-1) should do. It is its logic. But in the current implementation, the IPv6 netmap strips prefix length from the passed argument (considers it as /128) and sends traffic to that IP. Then what is the functional difference from DSTNAT?

Let's look a bit closer. You have an internal network with fd20::/64 prefix and you wish to map it to (let's say) 2001:560:6264:201::/64 to be able to access Internet. Is it work for netmap? yes. Now let's test it. Let's ping 2a00401b:806::200e from fd20::30 (why not?). Put a LOG rule to catch result packets into FORWARD chain because NETMAP can be placed only in DSTNAT chain. With no NETMAP rule you see something like that:
it should be clear and shouldn't cause any difficulties in reading. Now do:
Pay attention to the argument: it isn't "to-addresses" - it is "to-address" because there is no "to-addresses" like for IPv4 netmap. Ok, now ping again and what you see? Correct, something like that:
It is not as expected, isn't it? This test is quite easy and it should explain to you the problem with the IPv6 netmap. Though IPv4 netmap works as expected. Still not clear? Then look attentive at the SRC and DST in the log entry.

So, what you talked me about?

That kind of translation does not make sense! You cannot translate src-address to dst-address.
In a netmap you must translate dst-address (a subnet) to to-address (a subnet). You did not specify any dst-address!

He says that NETMAP with "to-address=2001:560:6264:201::/64" should convert 2a00:1450:401b:806::200e to something like 2001:560:6264:201::200e, not just 2001:560:6264:201::

But then it should be:

/ipv6/firewall/nat/add chain=dstnat dst-address=fd20::/64 action=netmap to-address=2001:560:6264:201::/64

Or similar with srcnat.
The rule he posts mentions no dst-address and so it is meaningless to translate it to something else.
See the examples for IPv4 on the wiki:

/ip firewall nat add chain=dstnat dst-address=11.11.11.0/24 \
action=netmap to-addresses=2.2.2.0/24

/ip firewall nat add chain=srcnat src-address=2.2.2.0/24 \
action=netmap to-addresses=11.11.11.0/24

The DST-ADDRESS will never work because the fd20::/64 in the example - is source prefix, not destination.
I know how it can be done with SRCNAT/DSTNAT. Or SNPT/DNPT for IPv6. Thie question was not "how it can be implemented with SNPT/DNPT". The question was "how to configure IPv6 NETMAP to work properly in ROS v7.1.1". Exactly about IPv6 NETMAP, not about IPv4 NETMAP, because as per my posts - IPv4 NETMAP works exactly as expected - I especially mentioned it.

Obviously don't understand what the NETMAP is. It explains all the things.

NETMAP (1-to-1) changes original SRC prefix to specified SRC prefix and doesn't change DST. It is what NETMAP exactly does. Not that you're telling here. I don't see any sense to continue this useless conversation until you will learn NETMAP and won't test behavior or current implementation of IPv6 NETMAP in ROS 7.1.1.

Its'a pity. Sorry for that.

Did you perhaps miss that you can have action=netmap in both chain=srcnat (to change source) and chain=dstnat (to change destination)?

Do you know that ROS 7.1.1 allows you to put IPv6 NETMAP only in DSTNAT chain? Did you test it? Just test - you will be surprized so much.

Ok, you're right:
But it means that from the two netmaps possible for IPv4 (source/destination), they added only the destination type for IPv6. It looks like mistake or bug.

Actually, this restriction is correct. As the NETMAP changes SRC addresses - the placement chain is correct. it should be placed in DSTNAT chain because these changes should be done in PREROUTING chain-set. The problem is that the IPv6 netmap doesn't perform prefix translation at all. Functionally it works similarly to DSTNAT. It is the problem and it is what requires an explanation from DEVs. Obliously, the IPv6 implementation of NETMAP works in different way than IPv4 NETMAP and there is nothing about that at all in the ROS7 documentation. It isn't clear why and it isn't clear what the IPv6 NETMAP does at all. There are two other actions (as I mentioned earlier): SNPT/DNPT - they works (conditionally) well. There is another oddity with these two actions but it is out off-topic here. But they work. But the IPv6 NETMAP does something senseless at all.

It's possible that I may have missed something, because I didn't play much with IPv6 NAT yet. But I don't see any reason why IPv6 netmap should be fundamentally different from IPv4 netmap. And since Linux is happy to accept these:
Which is the same way as I'd do it with IPv4, then for now I'm going to stick with my theory that MikroTik simply added only half of netmap by mistake.

Which is the same way as I'd do it with IPv4, then for now I'm going to stick with my theory that MikroTik simply added only half of netmap by mistake.

Yes, I noticed this before and came to the same conclusion. Also, the action src-nat is not available in the srcnat chain for some reason, only masquerade. I haven't checked on a Linux box but I assume this option is available in ip6tables.

The problem with the IPv6 NETMAP isn't a big problem. The problem is that the DEVs keep silent. It isn't a big deal to post an update like "Folks, don't rush with the IPv6 NETMAP - it is implemented buggy". Just 1 minute to post such update which could explain the things and avoid all these theories... But there is just that what is there.

Nevermind. I implemented this functionality in another way.

Do you really think that "DEVs" should be held accountable for all possible problems and can be summoned by you to explain their behavior here?

I believe DEVs are responsible for buggy features in "stable" releases. In alphas, betas, dev- and test- releases they can do everything they wish - no any complaints about that. But the "stable" means the stable. It is a well-documented and well-tested release. Frankly speaking, they are obvious things. As the question is related to ROS7.1.1 which is declared as the STABLE release - yes, they should explain all unclear and odd things they released as "stable".

Also, I believe DEVs are responsible for useful documentation that can be used to find all product-related details including implemented IPv6 NETMAP. Also, I believe it must be done with no summon from users.

I advise you to buy equipment from a manufacturer that charges 5 times as much and then forces you to have a "support contract" to report any issues and download new firmware.
You will get a very warm feeling scolding them when problems occur, and you can tell others that you have chosen the brand that treats you as a king.

Awful... What are you telling??? Is it actually possible at all?

It's just a joke. I'm not an amateur and not a newbie neither in software nor in networks. Even "enterprise-grade" contracts don't scare me. Thank you for the advice. I appreciate it a lot. But it has nothing to do with this topic and the issue under consideration. Fortunately, I'm able to decide on my own what to do and what to buy without your advices

Does anyone have a working example of nptv6 netmap? or even nat66? I am trying to translate a ::/56 ULA to ::/56 public prefix.

ipv6 netmap through prefix translation isn’t implemented until kernel 5.8 so curious how Mikrotik has it working; I believe ROS is still 5.6

Quick test with latest 7.3beta37 says that netmap in srcnat chain still isn't accepted (see few posts back). As for snpt/dnpt, it's either broken too, or I'm doing something wrong (no idea what). If I have this:
Then ping from fd00:1234:5678:9a01::183 to internet works, but translation seems weird, because the source gets changed to publ:icpr:efix:b701:1905::183 (I'd expect publ:icpr:efix:b701::183). Response going back to that is correctly translated to fd00:1234:5678:9a01::183. But other incoming traffic is broken, because publ:icpr:efix:b701::183 gets changed to fd00:1234:5678:9a01:e6fa::183.

Update, it looks like snpt/dnpt probably works correctly. But as user expectations go, it's a mess. Problem is that it's supposed to be as simple as possible, which doesn't sound bad, but it brings some limitations. If it's stateless and only rewrites addresses, it at the same time breaks checksums. So it needs to correct them, and that can be done by changing also some other bits in addresses:

https://datatracker.ietf.org/doc/html/r ... ection-2.6

It's not too bad if you get /48, because then it changes only 16 bits between 48 and 64, which means that you don't have complete control over them (e.g. mapping internal i:i:i:0001:: to external e:e:e:0001:: is not possible, external will be computed automatically based on internal and will be different), but at least it doesn't touch rightmost 64 bits, so this part of address stays the same (i:i:i:0001::1234 will be e:e:e:xxxx::1234).

But if you get longer prefix (/56, /60, ...) it has to use also rightmost 64 bits. Which works, but doesn't seem user friendly at all, because internal and external address won't be just different, but completely different. You can't just swap prefix and know what the new address will be (that's the same with /48 too, but here it's even worse).

Well I would prefer changing a part of the local address (e.g. the middle 16 bits that are FFFE when a static address is used) over changing the network address.
I have /48 at work but I would want to use that function to map external addresses to a constant local network address so load-balancing and failover can be done with 2 ISPs similar to IPv4, but of course we have several internal networks so we cannot burn all 65536 network prefixes on a single local network.

I probably like netmap more (in case I'd need any kind of translation). It's not stateless, so it's in a way worse. But if I'm going to use stateful firewall anyway (so the heavy part with connection tracking will still need to happen), I don't see it as problem.