The advantage in IPv6 is that almost always one can do NAT into /64, so it can be full-cone 1:1 IP-based NAT, instead of port/connection-based NAT like in IPv4. Such NAT has minimum disadvantages and can be implemented more efficiently.
It also only applies to the laptop in question, instead of being set up for the whole network. I don't like that the title can be read as "you still need NAT with IPv6, so why bother?"
IPv6 NAT is also useful because the /48 IP block I get from my ISP may change. I switched from DSL to Fiber and I got a different IPv6 block. But because if that, I also needed to update IPv6 addresses to my local DNS server (which needs to work across VLANs - so link-local address is not an option there). With NAT66 I could just assign a private address space to my LAN and have it only translate it externally to WAN.
Basically article describes that thanks to the NAT you can have your own little garden where you can do whatever you want without caring what is happening in front of the NAT. I completely agree with that. No idea why I should care what is happening with ISP network, that's ISP problem not mine.
For WAN comms you give it a GUA address as I mentioned. Most of my v6-enabled devices have at least 3 IPs: one link-local, one ULA and one GUA. Some have 5 IPs, some more.
Hotter take: IPv6 isn't going to happen. Most people's needs are met by NAT for clients and SNI routing for servers. We ran out of IPv4 addresses years ago. If it was actually a problem it would have happened then. It makes me sad for the p2p internet but it's true.
A response I've seen is that the relatively recent IPv4 price increases will change that. SNI routing solves that too.
IPv6 has already happened. Maybe "get rid of public IPv4 everywhere" isn't going to happen but mobile carriers already rely heavily on IPv6 NAT64 to avoid multi-layered IPv4 CG-NAT. It's where the majority of IPv6 traffic comes from and another one of the reasons we may not need "traditional" devices to get off IPv4.
IPv6 is one of the solutions that will allow IPv4 to continue. If you run into something like an address conflict you can often just use IPv6 to avoid the conflict rather than dealing with the conflict.
I think this raises some valid points but also spends a lot of focus on dubious ones.
In regards to the fixation on /64 being the smallest block - does it really matter to the user or operator if e.g. a /60 prefix is delegated instead of a /64 or /96 prefix? How many laptops need >16 public subnets in a single delegation, each with more addresses than they could ever hope to actually use? In the note at the end is the author really worried we'll run out of the ~4 billion /32 assignments, each of which can delegate hundreds of millions of /60s? Any of these prefix assignments are laughably wasteful for however many IPs will ever be on a laptop and there's not really much utility in them being tiny (i.e. it's not like we're about to run out of /64s to delegate). There is, however, some utility in hardware routers assuming all routing happens on the first 64 bits though. In all, I'm not sure what they are really hoping to gain by saying delegation would be better with smaller prefix sizes.
The "laptop has VMs that need to get out" use case is an interesting one though. It can be solved decently well (this is what I do personally) by a combination of link-local and/or private IPv6 IP assignments for the "internal" VM<->VM communication and letting the normal automatic SLAAC assignments handle "outbound" communication with the default route. In this method the laptop doesn't even need to route (unless you're using multiple private subnets, in which case it'll route just those). This is actually remarkably similar to the way NAT would work, sans the NAT (the difference being NAT places the dynamic assignment at a single, statefully tracked, point while in this case dynamic assignment is provided directly to each VM/container separate from the static assignments).
The big downside of this is if you are trying to emulate the exact public boundary of a production system then you want to emulate that it has everything running on 1 static public IP. For other cases in between these scenarios you can often get away with just matching any public IP in the rules. This use case "intentionally duplicate some other public network without conflicting" begs for NAT since it doesn't really change one way or the other by having as many public IPs as you'd like.
There is still upside of IPv6 even if you're in such a use case for NAT - you can just do 1:1 NAT of a private /64 to one of your delegated /64s. This drops the requirement for configuring port forwards or PAT, leaving it "true" NAT with less configuration.
This assumes the laptop would need to act as a router.
If the VMs are going to get dynamic addresses from the network, why not have them act as clients on the parent network? Why have the laptop act as a router with prefix delegation?
And if they have static addresses like labs often do, NAT will already need to happen.
> And if they have static addresses like labs often do, NAT will already need to happen.
Only if the static addresses also need to be static global addresses, which, if you were to use NAT for network portability, they wouldn't be anyway. So what you end up with instead is two addresses on each machine: Static ULAs for internal use, SLAAC/DHCPv6 from the parent network for dynamic global addresses, and no NAT.
In private “host only” VM networks, the hosts do act as routers, DNS, and DHCP servers. In those networks you do not want the VMs getting addresses from the parent network, you want them contained in the laptop.
The advantage in IPv6 is that almost always one can do NAT into /64, so it can be full-cone 1:1 IP-based NAT, instead of port/connection-based NAT like in IPv4. Such NAT has minimum disadvantages and can be implemented more efficiently.
It also only applies to the laptop in question, instead of being set up for the whole network. I don't like that the title can be read as "you still need NAT with IPv6, so why bother?"
IPv6 NAT is also useful because the /48 IP block I get from my ISP may change. I switched from DSL to Fiber and I got a different IPv6 block. But because if that, I also needed to update IPv6 addresses to my local DNS server (which needs to work across VLANs - so link-local address is not an option there). With NAT66 I could just assign a private address space to my LAN and have it only translate it externally to WAN.
You don't need NAT for that, you can just use ULA:s within your LAN and GUA:s for global communication.
Basically article describes that thanks to the NAT you can have your own little garden where you can do whatever you want without caring what is happening in front of the NAT. I completely agree with that. No idea why I should care what is happening with ISP network, that's ISP problem not mine.
That's what the ULA is for. You can do whatever you want with ULA and you don't need NAT to have that if you only use GUA for WAN comms.
Your device with ULA address either needs NAT66 to be able to talk outside or it is destined to talk only in LAN forever.
For WAN comms you give it a GUA address as I mentioned. Most of my v6-enabled devices have at least 3 IPs: one link-local, one ULA and one GUA. Some have 5 IPs, some more.
Hotter take: IPv6 isn't going to happen. Most people's needs are met by NAT for clients and SNI routing for servers. We ran out of IPv4 addresses years ago. If it was actually a problem it would have happened then. It makes me sad for the p2p internet but it's true.
A response I've seen is that the relatively recent IPv4 price increases will change that. SNI routing solves that too.
IPv6 has already happened. Maybe "get rid of public IPv4 everywhere" isn't going to happen but mobile carriers already rely heavily on IPv6 NAT64 to avoid multi-layered IPv4 CG-NAT. It's where the majority of IPv6 traffic comes from and another one of the reasons we may not need "traditional" devices to get off IPv4.
IPv6 is one of the solutions that will allow IPv4 to continue. If you run into something like an address conflict you can often just use IPv6 to avoid the conflict rather than dealing with the conflict.
I think this raises some valid points but also spends a lot of focus on dubious ones.
In regards to the fixation on /64 being the smallest block - does it really matter to the user or operator if e.g. a /60 prefix is delegated instead of a /64 or /96 prefix? How many laptops need >16 public subnets in a single delegation, each with more addresses than they could ever hope to actually use? In the note at the end is the author really worried we'll run out of the ~4 billion /32 assignments, each of which can delegate hundreds of millions of /60s? Any of these prefix assignments are laughably wasteful for however many IPs will ever be on a laptop and there's not really much utility in them being tiny (i.e. it's not like we're about to run out of /64s to delegate). There is, however, some utility in hardware routers assuming all routing happens on the first 64 bits though. In all, I'm not sure what they are really hoping to gain by saying delegation would be better with smaller prefix sizes.
The "laptop has VMs that need to get out" use case is an interesting one though. It can be solved decently well (this is what I do personally) by a combination of link-local and/or private IPv6 IP assignments for the "internal" VM<->VM communication and letting the normal automatic SLAAC assignments handle "outbound" communication with the default route. In this method the laptop doesn't even need to route (unless you're using multiple private subnets, in which case it'll route just those). This is actually remarkably similar to the way NAT would work, sans the NAT (the difference being NAT places the dynamic assignment at a single, statefully tracked, point while in this case dynamic assignment is provided directly to each VM/container separate from the static assignments).
The big downside of this is if you are trying to emulate the exact public boundary of a production system then you want to emulate that it has everything running on 1 static public IP. For other cases in between these scenarios you can often get away with just matching any public IP in the rules. This use case "intentionally duplicate some other public network without conflicting" begs for NAT since it doesn't really change one way or the other by having as many public IPs as you'd like.
There is still upside of IPv6 even if you're in such a use case for NAT - you can just do 1:1 NAT of a private /64 to one of your delegated /64s. This drops the requirement for configuring port forwards or PAT, leaving it "true" NAT with less configuration.
This assumes the laptop would need to act as a router.
If the VMs are going to get dynamic addresses from the network, why not have them act as clients on the parent network? Why have the laptop act as a router with prefix delegation?
And if they have static addresses like labs often do, NAT will already need to happen.
> And if they have static addresses like labs often do, NAT will already need to happen.
Only if the static addresses also need to be static global addresses, which, if you were to use NAT for network portability, they wouldn't be anyway. So what you end up with instead is two addresses on each machine: Static ULAs for internal use, SLAAC/DHCPv6 from the parent network for dynamic global addresses, and no NAT.
In private “host only” VM networks, the hosts do act as routers, DNS, and DHCP servers. In those networks you do not want the VMs getting addresses from the parent network, you want them contained in the laptop.