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.
That's....not true.
The world in which IPv6 was a good design (2017)
21–30 of 318 posts
Re: The world in which IPv6 was a good design (2017)
#22IPv6 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…
Freeing up more IPv4 space wouldn't have helped. IANA was assigning /8 per month at the end. The extra space would have gone in less than a year.
IPv6 would have worked better if they had made minimal changes to the support protocols. But it was have had slow adoption because there was no incentive to switch until addresses ran out.
Re: The world in which IPv6 was a good design (2017)
#23Ugh. 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…
> 3. Replacing ARP with neighbor discovery via multicast messages to interface addresses is... ok? But it's not necessary.
I don’t even think it’s really ok. ARP was layered correctly: IPv4 runs on Ethernet+ARP. Or it can run on other things that aren’t Ethernet+ARP. IPv6 uses IPv6 messages to make itself work on Ethernet, thus baking knowledge of Ethernet into the IPv6 neighbor discovery logic.
If multicast neighbor discovery is useful (which it may well be), then ARPv6 could have used multicast.
Re: The world in which IPv6 was a good design (2017)
#2435% 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 the packet.
2. Each router inspects this field, and sets it to the MTU of the next hop link, if it is lower than the MTU already in the packet. This will be cheap, as the field is not checksummed.
3. If the packet is bigger than the MTU of the next hop, just truncate it, and set a special bit somewhere in the packet header to indicate it. No need to recalculate the checksum either, the packet is going to be corrupt anyway.
4. The destination host gets the discovered MTU of the forward path, and sends it back to the originating host in the header of the next packet (in a checksummed part).
That's it. Easy, continuous MTU discovery, with robust handling of failures, that doesn't require any smarts from the routers (a comparator to update the MTU can be done in a few logical gates!).
Alas, nobody had the presence of mind to think about this back then.
Re: The world in which IPv6 was a good design (2017)
#25Earlier quoted context omitted.
ipv4 with NAT is in fact still extremely common, but skipping that, which parts of ipv6 (beyond extra bits) do you regard as essential versus which parts are over-engineered?
What "parts of ipv6 (beyond extra bits)" are you concerned about? As far as I know there aren't any, unless you're talking about extensions or something?
I haven't been fresh on this stuff for years, but there are some other differences. Included multicast, true QoS, included IPsec, a few other things. It's just that I sometimes see people advocating upgrading from ipv4+NAT to ipv6 for reasons beyond address bits, so I thought that's where you (edit, "they", oops) were coming from. I was just curious.
Re: The world in which IPv6 was a good design (2017)
#26The 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.
Yes, it's a common idea but relies on a misunderstanding - it would have required exactly the same difficulty as switching to IPv6, because there's no way to make an 'ipv4 with more bits' compatible with regular IPv4 software or hardware, without changing to a dual stack arrangement (which requires replacing all the packet processing hardware in big routers that relies on the layout of the IP header) - exactly the sa…
No.
The difficulty is social. Everyone would have been fine with "IPV4.2", IPV4 with six octets, because it's just like something they already knew, fixing its one obvious defect, not enough addresses.
The consitituency for replacing the hardware/firmware and software stacks would have been there.
IPV6 was not just like IPV4 and so people naturally resisted the devaluation of their hard-won knowledge.
Re: The world in which IPv6 was a good design (2017)
#27The 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.
[deleted]
Re: The world in which IPv6 was a good design (2017)
#28I've only dabbled in IPv6, but the one thing that blew my mind was that you cannot set DNS automatically without DHCPv6. Other methods of "automatic addressing" are thus useless.
Re: The world in which IPv6 was a good design (2017)
#29I've only dabbled in IPv6, but the one thing that blew my mind was that you cannot set DNS automatically without DHCPv6. Other methods of "automatic addressing" are thus useless.
RFC8106 IPv6 Router Advertisement Options for DNS Configuration https://datatracker.ietf.org/doc/html/rfc8106
Re: The world in which IPv6 was a good design (2017)
#30The 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.
IPv4 with more bits is usually proposed to have 64-bit (or even just 40-bit). IPv6 with 128-bit seems excessive but it makes transition mechanisms possible. NAT64 encodes the IPv4 address in the 64-bit host portion. MAP is even more interesting since it stores the whole NAT address and port for stateless CGNAT.