NAT is essentially required in IPv4 due to IPv4 address exhaustion.

NAT, when done on the carrier level (CGNAT), more or less prevents external systems from initating connections with anything on your network (without ISP involvement). You can still initiate outgoing connections fine.

Sounds great for security, but this enforces the existence of centralized services (middlemen) that you have to use/pay for if you want to have asynchronous communication with anyone that you might not necessarily initiate.

If you want a chance at a real decentralized Internet without dependency on tech giants, you're gonna need IPv6.

Does the CGNAT setup you contend with not support NAT-PMP/PCP? (To me that is the reasonable solution to the problem you cite, not IPv6, and I have been thinking it is already widely deployed... just not adopted by developers for some reason.)

I don't contend with CGNAT, thankfully, but no one ever moves from IPv4 then everyone's going to eventually be behind a CGNAT at some point.

I don't know too much about NAT-PMP/PCP - so I'm looking into it.

It’s easy to cause triple-NAT if you tether to a phone, or if you run VMs at home...

One of the vexing things about IPv4 (which is not really fixed by IPv6) is that endpoint devices are connected to the network but not really part of the network: there are different sets of protocols for connectivity within the network, and at the edge of the network. So an edge device (your phone, your VM host) can’t easily extend the network to more downstream systems (tethered devices, VMs) without hacks that hide the cluster from the network so the whole thing still appears to be a single device.

The "single device" problem comes from WiFi, not IP. Normally, you can extend Ethernet by plugging in a switch or bridge, but WiFi is limited to 1 MAC address per associated client, unless operating in WDS mode.

So an unprivileged WiFi client needs to hide tethered devices and VMs behind a single MAC address, using ARP proxy (IPv4) or ND proxy (IPv6). These proxies do NAT-like mangling of MAC addresses, but are mostly transparent at the IP layer.

The Linux environment on Chrome OS uses ND proxy, and IPv6 works fine on WiFi. Compare that to WSL2 on Windows, which is IPv4-only.

It isn’t specific to WiFi: there is the same problem if you use SLIP or PPP dial-up or DSL or cellular data, or many kinds of VPN.

And for IPv6 over ethernet, ND proxying is not a protocol you would normally use to construct a network.

Right. This is a big clash between the "v4 model" (as it has panned out in practice) and the "v6 model". The OG assumption of both was that there is _only one_ Network, but v4 in practice turned out to be segregated, private networks that happen to have a gateway to The Network. The original RFCs for private IPv4 networks and NAT explicitly call this change in stance out. So v6 was designed to go back to a world with only The One Network. The possibility of having a private v6 network was added much later (some time in the 2000s I think?).

This is probably why going to v6 is so confusing even for us Elite HN Readers; you don't have a private network connected to The Internet any more, The Internet directly extends to all devices. You can have a private network _in addition_ to that though.

This is actually pretty nice because it restores end-to-end connectivity, so P2P and mesh networking become easier; however, most everyone has a central firewall between their splinter of The Internet and The Greater Internet, so in practice you still need hole punching and some central services to offer hole punching duties, because hole punching works around NAT and opens a port in stateful firewalls; v6 only removes the NAT part in most instances. So in reality P2P with v6 is only slightly less messy than with v4.

> The possibility of having a private v6 network was added much later (some time in the 2000s I think?).

ULA seems to be RFC 4193 (October 2005). NTPv6 is RFC 6296 (June 2011).

* https://datatracker.ietf.org/doc/html/rfc4193

* https://datatracker.ietf.org/doc/html/rfc6296