from Hacker News

I feel that NAT is inevitable even with IPv6

by deivid on 11/4/24, 1:11 PM with 21 comments

• by apitman on 11/4/24, 3:35 PM

  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.

• by zajio1am on 11/4/24, 3:28 PM

  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.

• by sebazzz on 11/4/24, 4:27 PM

  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.

• by MrHamburger on 11/4/24, 4:12 PM

  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.

• by unethical_ban on 11/4/24, 3:27 PM

  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.

• by zamadatix on 11/4/24, 3:46 PM

  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.

• by ahmetozer on 11/6/24, 11:32 PM

  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.