Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

apenwarr.ca

Post reply on HN
Print view View original

41–50 of 318 posts

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

#41

Post by kccqzy »

cyberax wrote: 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.

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

#42

Post by [deleted] »

TedDoesntTalk wrote: post #33
throwaway892238 wrote: post #10

Earlier quoted context omitted.

It doesn't matter if even 98% of "the internet" is "on" IPv6. If public websites don't advertise an IPv6 address, every user is still going to use IPv4 to connect to them. All the cloud providers still prioritize IPv4, and usually don't support IPv6 at all until a few years after a new service comes out.

Entire countries still do not have IPv6. Ukraine for example.

[deleted]

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

#43

Post by RedShift1 »

kccqzy wrote: post #37
cyberax wrote: 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…

> Remove SLAAC and stateless DHCPv6. This statement then implies that we would need to have NAT66. Why? Stateful DHCP then implies the possibility of an endpoint having only a single assigned address. But what if the endpoint needs to have multiple addresses such as tethering or running VMs? With SLAAC the endpoint can just get multiple addresses. Now, just because today stateful DHCPv6 is a possibility, hypervisors…

The VM could just have a bridged network connection, no NAT66 required.

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

#44

Post by cyberax »

kccqzy wrote: post #37
cyberax wrote: 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…

> Remove SLAAC and stateless DHCPv6. This statement then implies that we would need to have NAT66. Why? Stateful DHCP then implies the possibility of an endpoint having only a single assigned address. But what if the endpoint needs to have multiple addresses such as tethering or running VMs? With SLAAC the endpoint can just get multiple addresses. Now, just because today stateful DHCPv6 is a possibility, hypervisors…

Stateful DHCPv6 allows prefix delegation even now, in its half-assed stupid form.

And if you don't want/have prefix delegation, you can just use multiple DUIDs to get several leases for one endpoint. Unlike in V4, this is fully supported in V6.

Your VM hypervisor will need to request an address during the VM startup, but I think it's actually better from the management standpoint. The network operator will be able to see VMs as the first class citizens in the network management console.

> But what if the endpoint needs to have multiple addresses such as tethering or running VMs?

Android developers are actually adding support for stateful DHCPv6 for exactly that reason :) They want to support tethering for V6 without doing NAT or bridging.

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

#46

Post by greyface- »

TedDoesntTalk wrote: post #33
throwaway892238 wrote: post #10

Earlier quoted context omitted.

It doesn't matter if even 98% of "the internet" is "on" IPv6. If public websites don't advertise an IPv6 address, every user is still going to use IPv4 to connect to them. All the cloud providers still prioritize IPv4, and usually don't support IPv6 at all until a few years after a new service comes out.

Entire countries still do not have IPv6. Ukraine for example.

There is some IPv6 adoption in Ukraine. https://stats.labs.apnic.net/ipv6/UA

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

#47

Post by vbezhenar »

mike_d wrote: 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…

IPv6 did not fail. It's used by a sizeable chunk of hosts, network owners made investitions in hardware, software and skills. It's not going anywhere, like it or not. Just like IPv4 will not go anywhere. They will coexist.

I still don't understand why IPv6 is a thing. End users can use NAT just fine. Servers can use CDNs and reverse proxies, sharing single IPv4 address among any number of hostnames. But it is a thing, so it's hard to imagine any other protocol to take over.

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

#48

Post by klabb3 »

toast0 wrote: post #11
ggm wrote: 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…

> 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.

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

#49

Post by gavinsyancey »

cyberax wrote: 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.

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

#50

Post by narrator »

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.
Post reply on HN