Hacker News Reader

Comment by jorams | Hacker News Reader

We need IPv6 because we're out of IPv4 addresses. When you launch a new ISP and knock on the door of a RIR like RIPE, they don't have any IPv4 addresses left to allocate and so you're put on a waiting list. The solution is IPv6. Even without allocating an address per device, without IPv6 just the status quo of every customer having an IP address is no longer possible.

The predecessor of my ISP introduced full IPv6 support for all customers 15 years ago. The only argument against at this point is inertia.

View on HN

If that's the problem, then the solution would've been just adding more address space to ipv4, preserving all existing addresses and pretty much everything else about it. 1.1.1.1/32 is still 1.1.1.1/32, and new ISPs can take blocks like 72.33.22.11.33/40 once enough routers are updated to support them. This could've even used the exact ipv6 packet structure, making it quite similar to v6 under the hood but more like v4 from the user's perspective.

Instead, ipv6 created a separate world, with extra goals like making every device addressable (aka removing NAT), using randomized addresses, and resetting all ownership of existing blocks. "We're out of addresses" is not a good excuse for all that.

> If that's the problem, then the solution would've been just adding more address space to ipv4, preserving all existing addresses and pretty much everything else about it.

That's not possible. IPv4 addresses are 32-bit numbers. Once you change that, you're no longer "preserving existing addresses".

> once enough routers are updated to support them.

That's actually "once all routers and end devices are updated to support them". As the classic spamsolutions.txt says, "requires immediate total cooperation from everybody at once".

> This could've even used the exact ipv6 packet structure, making it quite similar to v6 under the hood but more like v4 from the user's perspective.

Changing the packet structure means changing all hardware and software (yes, software too, the API for IPv4 uses 32 bits for the addresses). The changes visible to the user are the easy part.

> Instead, ipv6 created a separate world, with extra goals like making every device addressable (aka removing NAT),

It's more like "not needing NAT" than removing it; port mapping NAT is not a part of IPv4 (it's a hack on top of it), and it can be done identically in IPv6, but few do it on IPv6 since it's not necessary.

> using randomized addresses,

This is an optional thing which was added later; nothing in IPv6 requires randomized addresses, but IPv6 makes them possible by virtue of having enough free bits in the address. Were randomized addresses possible with IPv4, we'd see them happening.

> and resetting all ownership of existing blocks.

IPv6 has done no such thing; the existing IPv4 blocks are still there.

> That's actually "once all routers and end devices are updated to support them". As the classic spamsolutions.txt says, "requires immediate total cooperation from everybody at once".

This point cannot be emphasized enough. To quote Hyrum's Law [0]:

> With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

And for networking this means that, even if the NRO decreed that all reserved/testing IPv4 blocks [1] would be publicly routable and turned over to the RIRs for allocation, those blocks would be effectively unusable. It doesn't matter how many RFCs you produce saying "you must assume these addresses will be someday used", networking hardware and software has ossified around specific expectations pertaining to what addresses are valid and invalid, what protocols are acceptable, etc.

A great example of this is TLS 1.3: due to protocol ossification, the spec had to be rewritten to be more similar to TLS 1.2 because network middleboxes kept assuming it was a threat and blocking the connections [2]. This is also the reason SCTP has yet to gain widespread adoption, and why any new layer 4 protocol is likely doomed to fail: networking hardware hates anything that deviates from the acceptable traffic patterns which have been hard-coded in, RFCs be damned.

Imagine if previously unused IPv4 blocks started getting allocated. You'd be cut off from most of the internet, and most of the internet would be cut off from you. It wouldn't be enough, of course - even if all 2^32 addresses were publicly routable, that's still not even enough for 1 IP per person, you'd still have to rely on NAT, and all the problems it causes. (This is also why I think suggestions like "organizations like Apple who have a /8 but barely use it should just give up those extra IPv4s" are misguided and really understate of the scale of the problem - it's just putting a band-aid on an open fracture that cut your femoral artery.)

[0]: https://www.hyrumslaw.com/

[1]: https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4

[2]: https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet...

> That's not possible. IPv4 addresses are 32-bit numbers. Once you change that, you're no longer "preserving existing addresses".

I am uniquely employee number 6100. That field is 32 bits in HR's database. If they make it 64-bit, I'm still 6100.

> That's actually "once all routers and end devices are updated to support them". As the classic spamsolutions.txt says, "requires immediate total cooperation from everybody at once".

No it doesn't, it requires gradual cooperation, as the 4.1-compatible hosts will still speak v4 as needed. Same as how v6 stack support was added even to hosts not using it.

> It's more like "not needing NAT" than removing it; port mapping NAT is not a part of IPv4 (it's a hack on top of it), and it can be done identically in IPv6, but few do it on IPv6 since it's not necessary.

Yeah but the goal is to remove it. The feature set of v6, including random addressing, is intended to support p2p applications. The authors of ipv6 did not envision NAT being enable by default. Defaults and intent matter more than technical details here.

> IPv6 has done no such thing; the existing IPv4 blocks are still there.

They aren't there on practically any ipv6 network, despite an optional ipv6 extension for v4-mapped addresses. That's the critical difference vs what I've described.

Reply on news.ycombinator.com