Live data from Hacker News

The world in which IPv6 was a good design (2017)

apenwarr.ca

51–60 of 318 posts

Re: The world in which IPv6 was a good design (2017)

#51
post #41
post #14

Ugh. This is one of my favorite "what ifs" in the computer engineering. Things I would change: 1. Use 72-bit addresses. 56 bits for the network address, 16 bits for the end-user networks. 2. Just use the IPv4 "local subnet" prefix logic for broadcast domains. No "on-link" nonsense. 3. Replacing ARP with neighbor discovery via multicast messages to interface addresses is... ok? But it's not necessary. 4. Remove SLAAC…

> Use 72-bit addresses. 56 bits for the network address, 16 bits for the end-user networks. 16 bits is just way too small. The article clearly states that network operators just love to bridge together larger and larger networks due to the mobile IP problem. In the IPv4 world they can even have 24 bits (10.0.0.0/8) why should IPv6 have only 16 bits? It's definitely not enough.

8 bits for the home network feels cramped even now, my home network is at 56 devices. But 16 bits are fine for end-user networks.

And once you go over 16 bits, you really need to start dealing with routing.

> In the IPv4 world they can even have 24 bits (10.0.0.0/8) why should IPv6 have only 16 bits? It's definitely not enough.

This is not a fair comparison. You won't have a 10.0.0.0/8 network in IPv4 that has 16 million computers in the same broadcast domain. You'll likely have multiple /8 or /16 networks, with routing between them.

And in my hypothetical world, you'll have 56 bits for that routing. Your ISP can delegate you a /32 prefix, giving you 24 bits for your own routing hierarchy.

This is not dissimilar from the current situation. You have just 64 bits of the "network address", because the lower 64 bits are needed for SLAAC.

Re: The world in which IPv6 was a good design (2017)

#52
post #14

Ugh. This is one of my favorite "what ifs" in the computer engineering. Things I would change: 1. Use 72-bit addresses. 56 bits for the network address, 16 bits for the end-user networks. 2. Just use the IPv4 "local subnet" prefix logic for broadcast domains. No "on-link" nonsense. 3. Replacing ARP with neighbor discovery via multicast messages to interface addresses is... ok? But it's not necessary. 4. Remove SLAAC…

> Reify the MTU into the IP layer. No more ICMP nonsense for PMTU. If the MTU is fixed, you can't have VPNs, or any other protocol that encapsulates IPv6 packets and then sends them over IPv6. There needs to be some way for a middlebox to communicate that the MTU is lower than normal on a specific path because it is taking up a bit of every packet for overhead.

MTU will not be "fixed", I described my proposed solution here: https://news.ycombinator.com/item?id=37117455

Re: The world in which IPv6 was a good design (2017)

#53
post #17

The myth that it would have been easier to switch to a protocol that is just ip4 with more bits needs to die. The companies too cheap or lazy to adopt ipv6 would still be clinging to classic ipv4 with NAT.

Is it such a myth, though? IPv6 still causes troubles in deployment. For example, Android phones (still!!!) don't support stateful DHCPv6. Moreover, DHCPv6 was designed by idiots and out of many options for DUIDs it doesn't allow the most logical one: a user-specified host name. PMTU in IPv6 is even _more_ broken than in V4 because extension headers just plain don't work in the wide Internet.

> For example, Android phones (still!!!) don't support stateful DHCPv6.

That's Google's fault, not the protocol's.

Re: The world in which IPv6 was a good design (2017)

#54

I have said for the last decade or so whenever IPV6 comes up on HN that IPV6 was way too big of an address space for anything but having some sort of unique identifier in there to support an online digital ID. Like some space for a hash of a biometric or something in the lower 64 bits.

You may be interested in IPv6 CGAs.

https://en.wikipedia.org/wiki/Cryptographically_Generated_Ad...

https://datatracker.ietf.org/doc/html/rfc3972

Re: The world in which IPv6 was a good design (2017)

#55
post #48
post #11

Earlier quoted context omitted.

> Now, if only we could get jumbogram more widely deployed. Thats older than V6 is and still struggling to break the 1500 byte MTU limit. Really, we barely hit 1500. Look at mss for popular websites, most people drop from 1500, because 1500 has problems in enough places. Does http/3 even send 1500 byte packets ever? One major problem is most servers (Linux all versions, I think, FreeBSD before about 2000 and after so…

> Does http/3 even send 1500 byte packets ever? Iirc quic has a hard MTU cap at 1280 bytes.

Nope. QUIC requires the _minimum_ MTU of 1280: https://datatracker.ietf.org/doc/html/rfc9000#name-datagram-...

The maximum permitted size is 65527 (max_udp_payload_size).

Re: The world in which IPv6 was a good design (2017)

#57
post #20

IPv6 failed because they tried to boil the ocean. It was design by committee, where everyone got their pet feature thrown in to appease and gain consensus. Alternatively IPv4 is a mountain of small hacks, which is its biggest strength. We could have done a lot of good by adopting proposals to extend v4 like 0/8 and class D, but instead the decision was made to collectively drown the babies in the bathwater and insist…

I run a large multi-campus network. At least 75% of our outgoing Internet traffic is IPv6. Looking at home ISPs accessing our services, it’s at least the majority of them coming in on IPv6. My guess is it’s a similar ratio as outgoing.

IPv6 has issues but it hasn’t failed.

Re: The world in which IPv6 was a good design (2017)

#58
post #24
post #5

35% worldwide by population of users in random samples at APNIC: https://stats.labs.apnic.net/ipv6/XA US on 50%, India on 70% and China just shy of 40% -As China continues to grow (and it will) the likely outcome is > 50% IPv6 Capable. I doubt any new Mobile deployment will be single stack, the most likely is pure IPv6 with CGN for 4. So Africa which is still in growth, the most likely outcome is dualstack preferring…

There will be no larger MTU, this battle is lost. 1500 will live forever. If it makes you feel better, think about it as if Ethernet packets are just oversized ATM cells. Solving PMTU problem would have required reifying the MTU to the IP layer. It could have been done like this: 1. Use a 16-bit field in the non-checksummed portion of the IP header. Initially this field is set to the MTU of the link that originates t…

It should be noted that pockets of jumbogram-in-the-wild exist. It's just normalised to clamp it to the point few people can exploit it.

For example, the NBN in Australia uses a 2000+ layer-2 frame and nothing like 500 bytes is consumed to mark the upper carrier. They COULD have gone higher than 1500 and I would be surprised if there arent customers using 1300 or less because of the ADSL configuration they brought over when they uplifted from a real modem.

A lot of people do 9000 in their filestore network. They know it works on the local segment. Reducing the forwarding burden in header-TCAM-routing by a factor of 5 is a significant win, if you have a lot of packets.

People continue to discuss mechanistic approaches to finding your MTU in the IETF but I think you're right: its 1500 or less pretty much forever unless somebody makes a move here for product differentiation reasons. Given the embedding of content inside the ISP or at the IX, I suspect it COULD happen, if e.g. Netflix said it was a better overall experience? The ISPs would do it.

Re: The world in which IPv6 was a good design (2017)

#59

(2017), and it should be noted that the author has updated his views since then: https://apenwarr.ca/log/20200708 ("IPv4, IPv6, and a sudden change in attitude", 2020).

"The awesome unstoppable terribleness that is Postel's Law."

Eloquence for the ages.

Post reply on HN