I recently came across this thread:
http://forum.mikrotik.com/viewtopic.php?f=1&t=42614
(Requesting to know if NAT64/DNS64 are in the feature roadmap for ROSv5)

Obviously, being 6 years later, we can all say that the answer to that question was a big "hell no."

Over the years, I've generally fallen in with the idealogues who are almost religiously opposed to any sort of NAT in the IPv6 world. I do still feel that stateful, per-session NAT66 with a many-to-one mapping capability is an evil that should never be unleashed upon the IPv6 world. So much can be improved by eliminating all of this nat-traversal stuff that we've all become so accustomed to. It wasn't supposed to be this way. It didn't work this way before, and we can go back to the way things were supposed to be again!

However, I now feel that there are cases where NAT is justified in the brave new world of IPv6 tomorrow land: NAT64 and Stateless prefix translation

NAT64 (both stateless and stateful)
This is the primary focus of the thread I linked above. Many people (including myself) poo-pooed the idea, saying that dual stack is just the way to go, and that NAT is problematic. IPv6 should just be free from the scourge of NAT from inception through the end of time. I still do feel that dual stack is the best way to go, but I have realized that this view is not a valid critique of NAT64. NAT64 is an interworking function designed to allow direct communication between the parallel universes of internet4 and internet6. Some far-flung future day will dawn, when the last IPv4 address is turned off, and there will be much rejoicing. On that day, NAT64 will not be a part of IPv6, so there's no reason to oppose NAT64 because dual-stack is better than interworking.....

It seems that most people (including myself) have missed the point of NAT64.

The prevailing view of NAT64 in the thread was that its use is for early-adopters of IPv6 to throw IPv4 out of their networks, and use the NAT64+DNS64 gateway as the way to reach the 'legacy' IPv4 Internet. Only someone who's totally chugged the Kool-Aid would drop all IPv4 on their own network just to be an early adopter; accepting the hiccups of NAT64 in this mode of deployment. Therefore, while NAT64+DNS64 would allow someone to leap into the world of early-adoption (and let's face it - it's silly to say that deploying IPv6 today is "early" anymore - you can watch Netflix using only IPv6 for crying out loud), this isn't really where NAT64 is most useful.

NAT64 allows the end user networks to operate as dual-stack islands crossing a sea of IPv6 to reach the IPv4 Internet.

The true benefit of NAT64 is in the ISP's space - where IPv4 addresses must ultimately be public, and the supply is down to the point where a rationing mentality prevails. Stateless NAT64 as a feature in ROS would allow use of Mikrotik routers as the CLAT component in a 464XLAT deployment. 464XLAT is much more seamless to end users than running v6-only w/ NAT64.

Why? IPv4 literals, that's why!

If a user needs to communicate with a host using only its IPv4 address, then there's no amount of help that DNS64 can offer, and there's no way to get an IPv6-only host to even think about talking to it (without running a CLAT shim right on every host - which is NOT a reasonable requirement IMO). If the user's network is dual-stack internally, there is nothing special required for the end user devices. They can operate as dual-stack hosts without any realization that their IPv4 space is an island. The fact of the matter is that even in today's world, the IPv4 space is ALREADY an island - it's just an island of RFC1918 (private IP) space that gets translated into some public IP address before crossing the ocean of IPv4. NAT64 just changes the ocean from the fresh water of IPv4 to the salt water of IPv6, so to speak.

NAT64 not only relieves the ISP from having to supply a unique public IP address for each customer just like CGNat does, but it ALSO frees the customer from being behind double NAT. The ISP can run a centralized (or distributed) IPv4 gateway (stateful NAT64) as the PLAT portion of the 464XLAT architecture, and there NAT directly between the customer's internal private IPv4 address and the server's public IP address pool. In fact, there's no reason the PLAT even needs to be run by the ISP at all. New ISPs could go into business as pure IPv6 from day one, and simply pass the IPv4 connectivity up to an out-sourced provider. It's completely transparent to the customers - whenever they feel that they no longer need IPv4 inside their networks, they can just turn it off. Poof.

Stateless Prefix Translation

This is another NAT technology in the IPv6 world that I have come to accept, contrary to my previous "NAT is the devil in all cases" stance.

Multi-homed networks will pretty much require this kind of functionality to operate without deploying BGP. Another situation where it's useful is organizations connected to ISPs which insist on using dynamic prefix assignment. Can you imagine if your printer's IP address is always changing at the ISP's whim?

Now, I'm not as strongly in favor of prefix-translation as I am NAT64, but I do think it's a useful tool to have in the tool box. I would rather these same situations be taken care of by more forward-thinking means. For instance, the multi-home issue could be addressed just as easily with protocols like MPTCP and SCTP. If hosts would all have an address from each ISP, they could easily use these protocols to automatically load share all available Internet connections without much fancy stuff going on in the routers at all. And the dynamic prefix issue with ISPs is simply the remaining IPv4 mentality that resources must be assigned dynamically because of things like pools, over-subscribing resources, and preventing residential users from running servers. With an address space so vast, there's no reason in the world that end users couldn't receive permanent assignments of address space, and with TOS agreements, there's no reason the ISP couldn't simply block inbound connection requests for "business-class" services.

However, both of these things require a change in the common mentality of the Internet service community at large, and cannot be reasonably expected to gain any kind of traction any time soon, so in the mean time - prefix translation gives us a way to deal with them w/o waiting for the world to enlighten itself.


I know this has been an essay, but if you've read it, I hope that maybe I've helped shed some light on why NAT isn't 100% evil in the IPv6 world, while still holding to the ideal that direct end-to-end addressing should be maintained as a goal of the Internet.

I've (need to) read your post 6 times and dozens of rfc, now I've understood (probably only 80-90%, better than nothing).. and:

+1 I strongly agree

+1 !!!

Stateless Prefix Translation is definitely a must!
I would go as far as asking for even NAT66 support. I know that some will consider it the 'devil' but it IS useful in some use cases no matter what the ideology anyone wants to stick to. As you said it's just another tool in your tool box. If someone doesn't like it then don't use it for "crying out loud"! (to quote Jack O'Neill )

I made a request about NAT66 a while back http://forum.mikrotik.com/viewtopic.php ... ilit=NAT66

Great read Zero and excellent technical content!

You ought to listen to the Packet Pushers podcast with Geoff Huston about why we don't need IPv6 and NAT should be expanded in all areas of networking. It's a great nerd deep dive.

http://packetpushers.net/podcast/podcas ... ff-huston/

So about the podcast, the arguments for IPv4+NAT over IPv6 go like this: IPv4 address space is quite large and we don't use it effectively, there are huge numbers of addresses that are allocated, but not really used, i.e. wasted. In other words, we have not really run out of IPv4 addresses yet. Can we do something about using it more effectively? Who knows. At the same time, there's much more devices than 2^32 theoretically addressable using IPv4. They can all access internet and they all work, so what's all the fuss about? Lack of addresses as a problem for adopting new technologies? Not really, nowadays it's NAT everywhere, so you have to make your new technology work with it anyway. And hey, it might be good in the end, maybe we'll invent something interesting because of it. And if we're so desperate for larger address space, it doesn't necessarily have to be made of addresses. We can dip into ports and use them as extension to addresses. And to hell with addresses anyway, they are overrated, people don't connect to addresses, they connect to services. Lets invent some routing of names instead! Nope, sorry, I'm not convinced.

IPv4 NAT was a necessity, otherwise we'd be screwed. Unfortunately, it worked too well. And as everything else, even NAT is not strictly good or bad. It has some nice properties, like clear separation between user and ISP. I as a user have my own internal network and it's only mine, no one else tells me what I can or can not do inside. And it's great for ISP too, they deliver one address to my WAN and can not care less about what happens behind my router. I must admit, I really like this. NAT also brought some unexpected progress, e.g. all kinds of ways to make stuff work even with NAT in the way can be useful in the future with firewalls. Because lets face it, the original unrestricted internet is not coming back.

About IPv6 NAT, my "official" answer is no, never, it's evil, over my dead body! But to be honest, I want it, all kinds, I like all crazy technical stuff. But only as a possibility, backup, plan B, an extra tool. It must not be thought about as something normal and to be used by default. Imagine if sometime in the past IPv6 magically appeared in ready to be deployed state with all features, including NAT. Half of ISPs would continue with IPv4-style "one public address must be enough for everyone". Hopefully now the message got through, that it's possible to live without NAT and even when it's available, this won't be happening. Although, I'm not completely sure, maybe we should delay it a little longer. Because many ISPs still did not start with IPv6. And looking at what some other more progressive ones are doing (e.g. our largest national ISP already does offer IPv6 by default, but only one single /64... I mean, seriously, you got ***load of addresses, can get as many more as you need and this is what you give to users?!), maybe I'm too optimistic to think that they will know what's the right thing.

The proponents of IPv6 always pressed the need for every device to be able to communicate with every other device, so
each device should have a unique address. This was nice from a theoretical standpoint, but it is not realistic. I don't
need my intelligent fridge (often mentioned example) to communicate with your fridge. My fridge should communicate with
some service, and so does yours. However, this is already possible with NAT.
Furthermore, because of malicious people on the net, you always require some form of stateful firewalling in front of every
device, and NAT conveniently provides it. Providers that have rolled out IPv6 here have demanded from their modem/router
suppliers that by default incoming connections on IPv6 are disallowed, giving a similar situation as with IPv4+NAT.
So the most apparent advantage of IPv6, direct device-to-device communication, is now not possible anymore.

Another often-heard need for IPv6 was because of mobile devices. Ironically, here it is the mobile network that now
lags in the transition to IPv6. All the mobile operators use NAT. The mobile devices now can use IPv6, e.g. on WiFi,
but it does not work over 3G/4G because the operators do not offer IPv6. (a tunnel would work, but who needs it?)

W.r.t. the original posting, I agree that while IPv6 NAT is not something you would want to have in the same structure
as with IPv4 (cone NAT), but that there is a definite place for "prefix NAT". And even without that, there is a need for
better control over the prefixes used. My provider requires DHCPv6 PD and I get a /48 prefix, in the MikroTik I can
specify for all my internal interfaces that I want to get a /64 prefix from that pool, but there is no way to specify what
goes where. So when I change something in the configuration, potentially all my IPv6 addresses get changed on the
next router reboot. Not good. Solving that, maybe combined with prefix NAT (I set an internal prefix and it gets
translated to what can be retrieved from the pool) could be nice to have.

I'm running my mobile single stack IPv6 and it is using 464XLAT and it's fine. I feel that NAT64 (and DNS64) are almost must haves in 2016. I don't quite understand how CLAT in a gateway is any better than NAT behind a CGNAT. The clients are both still behind double NAT, however, I would want this feature so you could exist in the IPv6 only world.

NAT64 DNS64 and CLAT are all features that would be nice to have today. There are IPv6 only networks already out there (or at least aspirational IPv6 only) so to ignore this as reality is simply a race to the bottom as people seek NAT64, DNS64 and 464XLAT support.

It is interesting that iOS are not supporting CLAT and rather forcing all apps to be NAT64 and DNS64 compatible as this will keep dual stack around longer than it needs to be.

I don't like this idea of perpetual dual stack everywhere. It is completely unnecessary and the battle has already been lost (T-Mobile). It's like those who were making the case for HDDVD despite bluray already being adopted.

Telstra in Australia are going IPv6 only on their mobile network too now. http://lists.ausnog.net/pipermail/ausno ... 36106.html

Furthermore, because of malicious people on the net, you always require some form of stateful firewalling in front of every
device, and NAT conveniently provides it. Providers that have rolled out IPv6 here have demanded from their modem/router
suppliers that by default incoming connections on IPv6 are disallowed, giving a similar situation as with IPv4+NAT.

This is both true and deceptive.
NAT is not the same thing as a stateful firewall. It just so happens to give a very similar condition of 1-way reachability, but it's a side effect of what nat does do.
Furthermore, the primary function of NAT has other side effects on connectivity that purely stateful firewall filtering does not produce.

The biggest example would be VoIP:
Endpoint addresses are signaled in-band with VoIP. Just because the SIP conversation is between IP addresses X and Y, doesn't mean that the voice path will involve either of those addresses. The audio could end up being between devices W and Z. A simple NAT box won't necessarily know that the Z -> W packet stream is related to the X<>Y SIP conversation. Worse still is this - what if the SIP conversation negotiates two media streams to the same port, and both local endpoints are being NATed to the same public IP? The NAT box can't know which udp packet is for which internal IP... Both streams come from the same remote IP and from the same remote port number.... and are destined to the same local port number and public IP..... See the problem?
With IPv6 stateful firewall only (no nat), this doesn't happen. Even though 2001:db8::5060 is doing the signalling, and has asked remote server to send media to two different local machines, the local machines actually have unique addresses, so the firewall need only be able to recognize that this traffic is permissible. If the local machine sends outbound packets too, then the firewall doesn't even need an AGL because whenever local host 2001:db8::1010 starts sending RTP, the state will allow "reply" packets from the remote end - which should ALSO be a unique routable address. So even though the local side still needs to start sending packets to open "pinholes" in the stateful firewall, there is no additional confusion to be caused by address translation.

Things will be much simpler when everything can be uniquely addressed, even if routers/firewalls still block new incoming connections.

I don't quite understand how CLAT in a gateway is any better than NAT behind a CGNAT.

It is behind double nat in a sense - but one of them is a stateless 1:1 nat (the module I argued for in the OP) and really doesn't cause any of the issues that cone nat causes.
Basically, only one box (the PLAT) must keep track of session states. The CLAT can simply use a specific subset of the host addresses to map the entirety of IPv4...
For instance, when sending an outbound 4->6 packet, it could map all IPv4 into just 32 bits of one particular host address range.
Suppose the customer router has 2001:db8:c001:cafe::/64 as their routable prefix.
The customer's CLAT could map 2001:db8:c001:cafe:0000:ffff:xxxx:xxxx as the local IPv4 address space. So if local host 192.168.1.128 sends a packet out to the Internet4 world, the CLAT maps the source to be 2001:db8:c001:cafe::ffff:c0a8:180 and the destination to be whatever the ISP's 4->6 mapped prefix is. This way, the PLAT can have a direct map to every device inside of every customer network, thus only requiring one cone of NAT.

It's good to run this in the gateway so that even legacy devices that are created by defunct companies (i.e. no updates to support IPv6 will ever come about) can still talk to the rest of the LAN and to the Internetv4. Running the CLAT shim within a host is definitely a good way to go, but it's just not reasonable to expect every single user to install and utilize this on every device.

NAT is not the same thing as a stateful firewall. It just so happens to give a very similar condition of 1-way reachability, but it's a side effect of what nat does do.
Furthermore, the primary function of NAT has other side effects on connectivity that purely stateful firewall filtering does not produce.

I know that, I am sure that NAT is not the best thing to have, but I think the disadvantages do not outweigh the problems of introducing a new network protocol in an existing network with billions of devices. Especially because the net is not what it used to be.

Endpoint addresses are signaled in-band with VoIP. Just because the SIP conversation is between IP addresses X and Y, doesn't mean that the voice path will involve either of those addresses. The audio could end up being between devices W and Z.

We run a VoIP network like that on the LAN, but it is not practical to do this on internet. Too many goofs that will ruin your day. In practice, SIP calls on Internet are always through some exchange.

Note that the internet is not anymore what it was designed to be, and what the IPv6 people thought it would always be like: a peer-to-peer network where every atom in the universe can directly communicate with every other atom.
In practice, the internet has morphed from a peer-to-peer network into a client-server network where the servers are the big guys that provide the things everyone is interested in, and the clients are the people that connect those servers and are never connected by other clients or those servers. Today, 99% of all traffic is https over a TCP connection to port 443 of some server.
In such an environment, NAT is really not that problematic, especially when the protocol designers do not do stupid things. And it looks like they have learned from the past.

You're right, NAT is really not that problematic, we learned to live with it. If someone has enough public IPv4 addresses for their current needs and preferably even some to spare, they can probably live happily without IPv6 for many years to come. And going by the golden rule "if it works, do not touch it", staying away from IPv6 is even smart thing to do, because IPv4 really does work well for many people and IPv6 brings no obvious benefits for them.

But it can't last forever. Even if wet dreams of IPv6 fans about world-wide unrestricted peer-to-peer communication won't come true, there will be a moment when the amount of available public IPv4 addresses simply won't be enough. Then what? We will have to do something about it, that's unavoidable. We can't just expand IPv4 without making it into something completely different. And if we have to accept something different, IPv6 is really the only option, we can't start again from scratch and wait another twenty years before it catches up.

So what is everyone waiting for? Sure, it's convenient and safe to sit and wait for others to try it first and then learn from their mistakes. Unfortunately, too many people do it for too long. And meanwhile, the other people have to beg for public addresses and then pay and pay if they're lucky enough to get some. "So what, why should I bother if IPv4 still gives me everything I need?", someone might ask. The sad thing is (from IPv6 fan's perspective), they're right, there isn't an answer that would convince them.

The sad thing is (from IPv6 fan's perspective), they're right, there isn't an answer that would convince them.

Because there is that market who cannot afford the IPv4 space and as others adopt IPv6 the opportunity of an interconnected world creates new opportunity that may well force them to change. Sounds like I'm drinking the coolaid. However, what I'm saying is the flip side to if it ain't broke is you want to manage change not have it manage you.

The internet is getting more inter connected now. Even windows does p2p updates now. In the world of CGNAT this sort of thing starts to die as two sides of the connection end up behind a double NAT.

It's happening http://www.worldipv6launch.org/major-mo ... threshold/

I think that holding my breath for NAT64 in Mikrotik is probably a bad idea though.
I just went looking to see how to do this in nftables for Linux - and guess what, there's nothing.
I've set up 464XLAT using Linux boxes, but I had to use an add-on application to do the NAT64 portion.

I chose jool, and it was very easy to get it running, but with no support on the horizon in the official kernel-space tools.... well, let's just say that I doubt Mikrotik will do such a thing. If it's not a built-in feature, they're probably not going to use it (and I can't say that I blame them in this case).

since anyone recon that IPv6 aren't solution for and cause other problems, there was emerge of ad-hot adress resolution and routing thus.
things built alike cjdns(but w/o "broken by design" and "partially implemented" stuff like Ipv6 within) keep emerging, but in half dead state, yet, sadly.

NAT64/DNS64 is a must. Without it, we have no migration path. Mikrotik has been sleeping on this issue.

There are very few solutions for this at the moment. One being Cisco based gear, the other one for example being Tayga on Linux.

On the DNS side, there used to be the Trick or Treat Daemon (totd) .. it's now gone the way of the dodo, but that's because bind9 will do DNS64 natively.

--

Stateless 1:1 NAT66 is a must for migration purposes or multihoming, where BGP or the likes is not an option. I wouldn't see it as quite as critical as NAT64, but it's needed.

--

Any other form of NAT in IPv6 is not needed, should never be implemented and NAT in itself always has been a terrible hack. It lures users into a false sense of security.

Just my 2c.

--

An example of an IPv6 only network, that employs NAT64 at it's provider edge is http://www.freemesh.ie/ ... Mikrotik gear could not be used due to lack of functionality.

/M

Actually, perfect NAT64 can be build using OpenBSD.

It is extremely difficult to setup (I did not set it up, colegue did), but it shall pay off. Tayga is also OK, but its quite slow.

Alternatively, I have considered using Juniper SRX and it also SHOULD work well as I read the documentation.

Actually, perfect NAT64 can be build using OpenBSD.

It is extremely difficult to setup (I did not set it up, colegue did), but it shall pay off. Tayga is also OK, but its quite slow.

Alternatively, I have considered using Juniper SRX and it also SHOULD work well as I read the documentation.

There's also other solutions for Linux: Jool, which is more on a kernel level.

On the DNS64 side there are totd, the implementation in bind9 and the knot resolver.

Not having to resort to Cisco or Juniper solutions is the point of this thread. So suggesting Juniper SRX as a solution is counter productive. Sure they exist and work. But at what pricepoint ?

/M

NAT64 and the companion function of DNS64 is the realizer for us that want to move to the no more nat land.

Only 6 Native clients able to talk to all 6 and the small old 4 for these petty sites and services not yet migrated.

A Hell Yeah Big +1 from me.

I saw the other threads and thought o my good they miss the point but here comes a new lit candle in the darkness.
Good to see the new shiny morning isn't it

@Marlow:

Not having to resort to Cisco or Juniper solutions is the point of this thread. So suggesting Juniper SRX as a solution is counter productive. Sure they exist and work. But at what pricepoint ?

What? since when suggesting solution is counter productive? And SRX100 it cheaper than CCR9 so cmon, its worth all the money since MT does not even provide any NAT64. I also apparently didn't get the point, sice I thought this thread is about reading the essay till its end, which I did.

To stay productive, posting some random links from my searches (for solution):

Cisco:
http://www.cisco.com/c/en/us/products/c ... 76278.html

Jool:
https://www.jool.mx/en/index.html
Internet is silent and does not mention any real jool usage

Juniper:
https://www.juniper.net/documentation/e ... nding.html

Tayga Gentoo:
https://forums.he.net/index.php?topic=1998.0
BTW: DNS64 - BIND in DNS64 configuration

Tayga vs PF:
https://www.researchgate.net/publicatio ... mentations

Regards.

i'll be just ok with a proper NAT64 implementation inside RouterOS. the DNS stuff is relatively easy to deliver and having control over the DNS gives one the ability to keep the load distributed among multiple NAT64 boxes. you'll do DNS64/NAT64 on a centralised device anyway - at least if you really wanna save on the v4 addresses.
so you could fire up a set of pizzaboxes running NAT64, even distribute them around you SP network, and have 2 DNS64 resolvers to feed traffic to them.
then it's up to you how you decide which request shall be served by which NAT64 gateway:
- based on location
- based on previous requests
- based on NAT64 gateway usage
- sky's the limit

it's true i can run it on whatever random VM, but if i really need performance (read throughput) it seems you'll be better off with some 1U box running on an NP than buying the generic x86 HW (doesn't matter if it's a VM, as VMs also need some gear to run on), rolling your own (bloated) linux and then the NAT64 implementation. which can be kernel dependent & so on.
to be honest, for most people out there, running open source stuff doesn't solve a lot of issues, unless they are able to make modifications & know what to do. wherever the community decides to go, you need to follow them - and this is the same with the vendor proprietary stuff. yes, there are technically gifted/experienced folks out there who know how to mend/build things, but it time-to-market sense a reasonably priced vendor solution can get things sorted out faster. YMMV, but it seems the TCO will be roughly the same even if i buy (if the feature will be there) dedicated Mikrotik gear for the purpose.

i'm not against open source. there is a ton of network related implementations out there for bgp, pppoe, l2tp & so on, yet we seem to prefer the pre-packaged Mikrotik approach running on their HW, as their HW seems to be pretty fit for these stuff. and time does matter.

+1.

+1.

At what point will I slowly convert? Will it first be my IP address given to me by the ISP is an IPV6 address and my LAN is IPV4?
After that??? As stated I dont want my fridge IPV6 address to be accessible outside my router, unless talking to the fridge company cloud I suppose.

Conceptually IPv6 is similar to IPv4. With later one can get (wrong?) impression that NAT provides some extra level of control and/or security. But if you think of it, with MT's highly customizable firewall there's nothing which can be done with NAT that couldn't be done with firewall. Even with IPv4 NAT you can't really block fridge from connecting food store if you don't play with segmenting the LAN etc (no, static DHCP leases and blocking according gadget's IP address is not fail-safe). And most techniques apply to IPv6 as well. Provided that ISP offers prefixes shorter than 64 bit that is. Surely MT lacks some stuff (such as stateful DHCPv6 server) but that's not a problem with IPv6 itself.

I am a ipv6 purist ... not at all interested in NAT64 .... D day is 2025 when US Gov completes its conversion THEN everyone falls in line.

@ZeroByte. you make a good argument ... Good Luck ... :-)

With IPv6 , there is no need for NAT. Normally an upstream provider will hand off something like a /64 or a /60/ or possibly a whopping large /56

Now with the shortage of IPv4 ( as in no more new IPv4 blocks are available ) and upstream provider could do something like this:
((( Dual Stack )))
Upstream provider - hands you a NATted ( CGN ) IPv4 ( you then NAT the natted IPv4 address given to you so that you can run multiple computers.
Upstream provider - hands you a live IPv6 ( /64 ), then you pass out 18,446,744,073,709,551,616 IPv6 addresses live IP-V6 address to your multiple computers.

FYI , normally , a dual-stack ( IPv4 & IPv6 ) computer/networking-device will always try IPv6 connections first , if can't connect using IPv6 then retry using IPv4.

North Idaho Tom Jones

I am a ipv6 purist ... not at all interested in NAT64 .... D day is 2025 when US Gov completes its conversion THEN everyone falls in line.

@ZeroByte. you make a good argument ... Good Luck ... :-)

Question re: D day is 2025
I was not aware there was a a government D day to drop IPv4 - or is this a government D day to have all government agencies running IPv6 ?


North Idaho Tom Jones

With IPv6 , there is no need for NAT. Normally an upstream provider will hand off something like a /64 or a /60/ or possibly a whopping large /56

There is no need for many-to-one translation as is usual with IPv4 and having only a single external address for your entire network, but even with IPv6 you still require network prefix translation in these cases:
- ISP changes IPv6 address willy-nilly and you want the addresses on your LAN to remain static
- ISP gives only a /64 and you want to run multiple internal networks (e.g. for guest WiFi)
- You have multiple ISP connections and want to do load balancing/failover between them (and you don't have portable address space and BGP)

With IPv6 , there is no need for NAT. Normally an upstream provider will hand off something like a /64 or a /60/ or possibly a whopping large /56

There is no need for many-to-one translation as is usual with IPv4 and having only a single external address for your entire network, but even with IPv6 you still require network prefix translation in these cases:
- ISP changes IPv6 address willy-nilly and you want the addresses on your LAN to remain static
- ISP gives only a /64 and you want to run multiple internal networks (e.g. for guest WiFi)
- You have multiple ISP connections and want to do load balancing/failover between them (and you don't have portable address space and BGP)

Re: ... ISP changes IPv6 address willy-nilly and you want the addresses on your LAN to remain static ...
You have a very strong point about using IPv6 network prefix translation ( well done :) )

As an ISP/WISP , I have the bulk of my servers running dual-stack IPv4 & IPv6.
I am getting ready to roll out IPv6 to a thousand+ Mikrotik wireless DHCP-Client CPEs.

Thinking about the prior post from pe1chl and his reasoning to use IPv6 network prefix translation because DHCP to clients has got me to thinking ...
Questions:
Is the stock out-of-the-box Mikrotik default-configuration ( with IPv6 enabled ) already pre-configured for IPv6 with network prefix translation for the LAN interfaces ?
( I've never looked at the default configuration , mostly because we just blow-away the default Mikrotik config and use an IPv4-only config I created. )

Anybody know where there is a fully operational Mikrotik wireless-client config with WAN-(DHCP-Client wireless) LAN-(DHCP-Server IPv4-NAT & IPv6 network translation) ?
I need to update the IP-v4 only config we use because I am really close to rolling out IPv6 on-top of my existing IPv4 networks.

North Idaho Tom Jones

No, MikroTik routers do not come with preconfigured network prefix translation, as they do not support it at all. (at least in v6)
The main supported configuration for MikroTik routers with IPv6 is:
- use DHCPv6 client to request IPv6 prefix pool from ISP and store it in a local pool
- configure local interfaces with automatic address from that pool, and announce it on the network (SLAAC)
- when needed, configure DHCPv6 server for prefix delegation to routers further down the line (so they can request new network prefixes and route them)

DHCPv6 server for individual addresses (for systems, rather than routers) is not supported. However, the DHCPv6 server can deliver other info, like a DNS server address, to those.
It is "easy" to support IPv6 for multiple wireless clients as long as you have sufficient prefixes available to hand out.
That should be no problem, however. As an ISP you can easily get a /32 network. Many ISPs give /48 to their clients, which would even be sufficient for a small wireless ISP to send to their clients. (65536 networks)

Question re: D day is 2025
I was not aware there was a a government D day to drop IPv4 - or is this a government D day to have all government agencies running IPv6 ?
North Idaho Tom Jones

U.S. Government Paves the Way to IPv6 with Mandate Compliance
OMB to Agencies: Time to Finish IPv6 Transition
US government to fully transition to IPv6-only networks

No, MikroTik routers do not come with preconfigured network prefix translation, as they do not support it at all. (at least in v6)
The main supported configuration for MikroTik routers with IPv6 is:
- use DHCPv6 client to request IPv6 prefix pool from ISP and store it in a local pool
- configure local interfaces with automatic address from that pool, and announce it on the network (SLAAC)
- when needed, configure DHCPv6 server for prefix delegation to routers further down the line (so they can request new network prefixes and route them)

DHCPv6 server for individual addresses (for systems, rather than routers) is not supported. However, the DHCPv6 server can deliver other info, like a DNS server address, to those.
It is "easy" to support IPv6 for multiple wireless clients as long as you have sufficient prefixes available to hand out.
That should be no problem, however. As an ISP you can easily get a /32 network. Many ISPs give /48 to their clients, which would even be sufficient for a small wireless ISP to send to their clients. (65536 networks)

Re: As an ISP you can easily get a /32 ...
Yup - I've got two IPv6 /32's

What about mobile operators that will now only give IPv6 /64 out by SLAAC? How can that be consumed by an established IPv4 Mikrotik network?

Im facing an issue where I have enjoyed providing clients with LHG-LTEx on the roof with IPv4 WAN passed through to the router in the house (usually Mikrotik, CAPsMAN etc etc). Now a UK operator EE is only issuing sim cards with IPv6 and have stated they are turning off all IPv4 in 2023. I currently have no solution in Mikrotik ecosystem. But I would be laughing if I had NAT64 and its accoutrements.

Can you provide a link where it states that EE will no longer provide IPv4 connectivity in 2023?

Love the pic.

An agent told me this over the phone when I begged them to make my brand new sim card IPv4. What this actually means is probably that all new sim cards will be IPv6 only. Maybe existing sim cards that get IPv4 like PAYG will also be switched over.

So either way we need a way to make an IPv6 LTE connection consumable by established IPv4 LANs.

What about mobile operators that will now only give IPv6 /64 out by SLAAC? How can that be consumed by an established IPv4 Mikrotik network?

It cannot. A single /64 range given out by SLAAC can only be used by a single host, not by a network.

It cannot. A single /64 range given out by SLAAC can only be used by a single host, not by a network.

...Yet a humble mobile phone can tether several devices off that address but Mikrotik cant?

The single /64 prefix can run one subnet. Which is connected directly to the device giving it out. But if you stick a router in between and router is forced to use it on WAN interface, then no, it can't be done.
It could be done if that /64 prefix was actually prefix (and not /64 address) ... that would mean that router could use prefix on LAN interface and communicate with upstream device using link local addresses. But most often that's not the case when single /64 is in the play.

Interesting.

If I look in Prefixes there is an entry of: "2a01:xxx:c2a:/64"

Is this a usable prefix?

Yes, but for one network only. The network between your MikroTik and your provider.
You cannot take a part of that and route it to a local network on the other side of the MikroTik.
For that you need a larger range, e.g. a /60 or /56 or /48, and you can take a /64 out of that and route it to a LAN for example.
It is unfortunate that still so many ISPs don't understand IPv6 and give only a single /64 to their customers, and use SLAAC for that.
This is not how it should be done. SLAAC is for use on a LAN, for your router to give addresses to your clients.
On the provider side, something like DHCPv6 PD should be used.

Ok penny dropping when you said its for the network between provider and mikrotik. Gotcha.

Is the new ipv6 firewall NAT in mikrotik not helpful with ability to masquerade? Could I not create an ipv6 LAN and share it via NAT? This would at least get ipv6 compatible devices a connection

No, there is no "masquerade" in IPv6 NAT. It is more like "netmap": it translates a whole network 1:1 into another network address.
It can e.g. be used when your ISP gives you a dynamic address but you want a static address on your LAN, or when you have 2 ISPs with failover and want the LAN addresses to remain the same when failover occurs.

No, there is no "masquerade" in IPv6 NAT. [...]

Um....

It is unfortunate that still so many ISPs don't understand IPv6 and give only a single /64 to their customers, and use SLAAC for that.
This is not how it should be done.

Well, this is just fine if ISPs assume that customers will use ISP provided gear ... which many users do. But it's not fine in case of advanced customers who want to use their own routers as border device and/or who want to split their LAN to two or more parts. I can imagine that there are ISPs who by default hand out single /64 prefix via SLAAC but offer shorter prefix (e.g. /56) via DHCPv6 prefix delegation upon request (possibly backed up with certain sum of money). And I can also imagine that some users fail to request shorter and/or static prefix from their ISP and then bitch about how stupid their ISP is.

No, there is no "masquerade" in IPv6 NAT.

Masquerade def seems to work.

Ping to cloudflare DNS sourced from GUA that's not publicly routable.
NAT config

Connection table entry

This is very cool. So Even a mobile /64 address could be utilised to get internal IPv6 capable devices connected.

Haha, Bet the designers of IPv6 have veins popping out of their heads finding out this is how it will be used.

What I dont understand is why the designers of IPv6 built in such colossal waste since a /64 is the smallest subnet, each time a /64 is assigned that space is 99% wasted.

There's nothing wrong with using masquerade on IPv6 when you have to, for instance things like VPN services where you might just get a single IPv6 but connect that to a router. It is better to have NAT-ed IPv6 than no IPv6 at all.

What you shouldn't do is enable masquerade for security or privacy - lots of people have this misguided notion that NAT provides security and that is false.

What I dont understand is why the designers of IPv6 built in such colossal waste since a /64 is the smallest subnet, each time a /64 is assigned that space is 99% wasted.

It's probably better to think of IPv6 as a 64-bit global address concatenated with a 64-bit local address. Calling the local address part "wasted" would really only be fair if it served no purpose beyond manual numbering. I guarantee the IETF working group was not under some illusion that any LAN would have 2^64 hosts on it. The ability to use an existing link-layer address (48-bit MAC in the case of Ethernet) to derive a unique address completely statelessly is a feature that relies on having at least that many bits free that aren't being used for topology information. Furthermore, even absent some practical considerations like ND cache exhaustion, having IPv6 hosts allocated dynamically and sparsely across 64 bits is a security feature. Scanning IP address space relies on the relatively small size of IPv4 to be a tractable problem.

There's nothing wrong with using masquerade on IPv6 when you have to, for instance things like VPN services where you might just get a single IPv6 but connect that to a router. It is better to have NAT-ed IPv6 than no IPv6 at all.

The internet was built on the proud tradition of implementing things that shouldn't be implemented and NAPT66 is one of them. I can't deny that there are some circumstances in which you might gain some utility from having it, but I sincerely hope that IPv4 norms don't cause IPv6 deployments to backslide into using NAPT66 with any regularity. Stateless NAT66 on whole prefixes is a whole other deal and I can see valid technical arguments for it existing (mostly centered around AS multihoming receiving DHCPv6 PD delegations from two providers' PA blocks) but ... address-overloaded NAPT66? ... please no.

but I sincerely hope that IPv4 norms don't cause IPv6 deployments to backslide into using NAPT66 with any regularity.

I don't think this is going to happen. The only reason why people actually *want* to use NAPT66 is the misguided notion of it being more secure or enhancing privacy. Some people still have this misunderstanding but it is being corrected over time. The larger problem is people not using IPv6 at all and not knowing why anyone would want to use it. I work for an ISP and when I was rolling out IPv6 I dealt with the gripes of the sysadmin -> we don't need IPv6, nobody needs it, NAT is good enough.

I'm using it to give my phone IPv6 connectivity, since the other Wireguard peer has a dynamic IPv6 prefix, I've found it to be the only easy option.

Haha, Bet the designers of IPv6 have veins popping out of their heads finding out this is how it will be used.

I hope not. Who cares about designers, the ones who should be concerned are users. Main point of IPv6 was "endless" supply of public addresses for everyone. That should be the normal thing. No need for NAT anymore, except for rare special cases. It may not be big deal for things like web browsing, but if it was just that, we could have stayed with IPv4 forever.

Forum a few day ago, an Android device doing things it should not do. I just wrote "IPv6?". Solved.....deactivating IPv6 did solved it also there.

Used IPv6 for years but since a few no IPv6 for me. NAT for IPv6 sounds good but bad memories of my earlier IPv6 time still prevails.

As of March 2022, according to Google, the IPv6 adoption rate globally is around 34%, but in the U.S. it’s at about 46%.

What is IPv6, and why is adoption taking so long?

Like cooking a frog in a frying pan, the right way, slowly!

Otherwise it will be ugly, kicking braying, biting, spitting and extreme flatulence!!

Nah, do it quick. Just use the pan cover (the non-transparent one) to hide the ugly details.

As of March 2022, according to Google, the IPv6 adoption rate globally is around 34%, but in the U.S. it’s at about 46%.

Microsoft does not support this for Hot/Live-mail etc. Is Microsoft then a outdated company?

@msatter
My knowledge oh Hotmail/Live is very poor so I cannot answer to those specific services … office 365 and all other Windows systems provide 100% support for ipv6 …. 90% of US government mail systems are now ipv6 …. Where MS now has a dominate position by 2023 all US government depts will be Ipv6 …. This will force everyone to convert faster because the US Goverment is the pre-emanate purchaser of goods and service … so anyone wanting to do business with the US will and must convert …. Many have converted … it’s just going to happen much faster starting in 2023.

All my TV services are ipv6 exclusively as is my cell phone service … I am 100% certain that ipv6 will become the defecto standard before long.In Canada all the major Telecoms are ipv6 … Bell Canada and all their subsidiaries will be converting their FTTH infrastucture to ipv6 in 2023.this will force Anav to convert as well

I am 100% certain that ipv6 will become the defecto standard before long.

That's my exact thought from twenty years ago. Now I'm no longer that optimistic anymore.

It must be also 20 years ago that I was offered it and then the time frameeas that 2012 the switch would be made to all IPv6.

https://tweakers.net/nieuws/23639/xs4al ... nsten.html (Dutch language)

Ten years later all got default, an IPv6 addres:

https://tweakers.net/nieuws/82260/xs4al ... rzien.html (also in Dutch)

IPv6 adoptation almost stopped in September 2021:

https://www.sidn.nl/nieuws-en-blogs/ver ... nd-gekomen (also in Dutch)

Dutch Government starts adopting IPv6: December 2021

https://forumstandaardisatie.nl/nieuws/ ... e-overheid (also in Dutch)

NAT config

Code: Select all

/ipv6 firewall nat
add action=masquerade chain=srcnat dst-address=2000::/3 src-address=\
    200:c01d:c01a:beef::7ac0/128 to-address=2603:XXXX:XXXX:XXXX::2/128

Do you also happen to have solution for the following two common issues with IPv6 in residential deployments:

1. Dynamic address and prefix assignment by the ISP changes the addresses in one's network (so joining "the typical Unix hacker [who] never can remember what the PRINT command is called this week" (Ed Post, Real Programmers Don't Use PASCAL) one many not know what the IPv6 address of the printer is this day).
2. Subnetting in case the ISP only provides a /64 address (for the router) and a /64 prefix (for the network behind the router)?