I feel that NAT is inevitable even with IPv6 | Hacker News Reader

I feel that NAT is inevitable even with IPv6

utcc.utoronto.ca

40 pointsdeivid21 comments

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've been running IPv6 for over 15 years, first with a various tunnels, then native. A couple years ago I was able to get a /44 block and use that for experimentation.

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.

I am a network engineer who understands what those acronyms mean, and what you're describing is an order of magnitude more complicated and more work for the average use case in a large corporate environment, a small business environment, or a home network environment.

This is not simply architecture astronomy, it's the equivalent of planning an expedition to a planet to plant a flag with a title granted by the "International Star Registry"

I genuinely have no idea what you are talking about. Having the router advertise two kinds of subnet (one local and one global) is no more complicated than setting up NAT66. It's actually likely easier because it's likely something that can just be enabled with a simple setting, if it's not enabled by default, while NAT66 will probably require more intricate configuration, if it's even possible at all.

Not sure what the second paragraph is supposed to mean.

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.

Which then creates double the amount of work in managing firewall rules, QoS policies etc.

Nah - NPTv6, as it plays nicer.

See RFC 6296 and RFC 7157.

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.

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.

Why not use bridge for ipv6 and nat for v4. I use this combination and i dont have any delagation calculations in a small size network.

Reply on news.ycombinator.com