4 ms·
What we should take away from the IPv6 debacle is a fine lesson in hubris. I was hanging out in the IPv6 mailing lists at the time the various solutions were b
by grandinj 8y ago
What we should take away from the IPv6 debacle is a fine lesson in hubris.
I was hanging out in the IPv6 mailing lists at the time the various solutions were being debated.
The prevailing attitude was "the Internet is about to die from routing overload without IPv6, so we can stick whatever complexity we want inside it, and they will have no choice but to accept it."
Except that new router hardware and new incremental software improvements came out, and the enormous complexity of the "boil the ocean" redesign inherent in IPv6 was rightly regarded as completely unnecessary.
If the IETF had simply made IPV6 "ipv4 with longer addresses", (and there was a proposal to do just that), implementations and deployment would have been dramatically simpler and would have stood a real chance of succeeding.
Instead we have this baroque construction, which I _still_ have to explicitly disable in my work environment because various bits of supposedly IPV6 software don't play nice together.
- MR4D 8y agoWell said! I was in the camp hoping for two octects at the beginning of the address (so they could be zeroes). Actually, a single i text would have taken us to a trillion IPs and given us enough time to think about the topic a bit more. Large changes rarely succeed. Perl 6, Mozilla (back in the 1990’s) and others come to mind. This is hard stuff, and we were made to swallow the kitchen sink.
- magicalhippo 8y agoI guess one could say, to paraphrase, extraordinary change requires extraordinary motivation. For me as a home user, IPv6 seems like what you'd get when you ask a group of 6-year olds to design a concept car.
- zAy0LfpBZLC8mAC 8y agoSo, what are the changes in IPv6 other than change in address size that hinder adoption?
- noinsight 8y agoARP was replaced by neighbor discovery protocol. Broadcast was replaced by multicast.
- throwaway2048 8y agoARP was unsuitable for anything except ethernet and ipv4, and would have needed to change in an incompatable way no matter what. I dont see why replacing it is a big deal.
- zAy0LfpBZLC8mAC 8y ago> ARP was replaced by neighbor discovery protocol. Would you be happy if we renamed NDP to ARPv6? Or is your suggestion that we continue to use ARP and put a more-than-four-byte-address into a fixed-size four byte field? > Broadcast was replaced by multicast. So, in IPv6 you can only send packets to a small subset of recipients, whereas in IPv4 you could address a packet to "every IPv4 device on the planet"? Or are you suggesting we should misname multicast in IPv6 as "broadcast" just as we did in IPv4 in order to solve which technical problem exactly?
- noinsight 8y agoI don't have a problem with IPv6, I was just stating changes between it and v4.
- zAy0LfpBZLC8mAC 8y agoWell, but I didn't ask for "changes between v6 and v4", I was asking for changes other than the change in address size that hinder adoption--with the point being that most of the stuff that people complain about is actually an unavoidable consequence of the change in address size, such as the replacement of ARP with a new protocol that can actually transport longer addresses than 32 bits (and that otherwise isn't all that different from ARP).
- throwaway2048 8y agoIts not like "ipv4 with longer addresses" would have been any more compatable, we would be stuck in exactly the same situation wrt actually deploying it. The things that ipv6 brings along that are not present in ipv4 are pretty inconsequential.
- grandinj 8y agoNot really. Virtually every related protocol (e.g. ARP, BOOTP, OSPF, BGP) was modified in non-trivial ways, the rules around different kinds of addresses (link-local, etc) are very different, IP-level encryption stuff started out mandatory (may not be anymore), various flow-control stuff was tweaked (and tweaked again since then to match the improvements in IPv4), rules for parsing optional header fields was tweaked, etc, etc.
- throwaway2048 8y agoAll of those things would needed to be changed for "IPv4 but longer", its not like you could take the IPv4 versions of any of them and use them.
- noselasd 8y agoBut then you could change them in trivial ways. This really does make big difference.
- 88768768 8y agonice https://bit.ly/2JTdt8x https://bit.ly/2JTdt8x
- billpg 8y agoDo you have a link to the "ipv4 with longer addresses" proposal please?
- dvfjsdhgfv 8y ago> Instead we have this baroque construction, which I _still_ have to explicitly disable in my work environment because various bits of supposedly IPV6 software don't play nice together. Most security-conscious people do the same.
- dvfjsdhgfv 8y agoTo the downvoters: I'd be curious to read your counter-arguments. To start the discussion - "NATO cybersecurity bods warn about transition to new protocol": > What's the solution? According to the authors, nothing short of a wholesale review of how network traffic is interpreted. Sysadmins need to look at how their security systems are configured to make sure they pick up any unusual traffic flows made using this technique. https://www.theregister.co.uk/2017/04/10/ipv6_security_concerns/ https://www.theregister.co.uk/2017/04/10/ipv6_security_conce... This is just one example of many IPv6 security threats.
- throwaway2048 8y agoThe fact that network security software dosent support ipv6, so ipv6 is an inherent risk is sort of a vaccuous statement, it also wouldnt support whatever replaced ipv4 either.
- dvfjsdhgfv 8y agoThat's just one of the main security issues with IPv6: https://searchsecurity.techtarget.com/tip/Get-ready-for-IPv6-Five-security-issues-to-consider https://searchsecurity.techtarget.com/tip/Get-ready-for-IPv6... Also, if IPv6 was a simpler protocol it would be easier for the authors of security tools to implement support for it.
- joquarky 8y agoI've had this question for some time, and you mentioned that you were present during the debate phase. I wonder if I could ask if there was any mention of a solution to expand IP address space in a manner similar to how UTF-8 expands as needed? I'm not a SME on low-level protocols, but it seems the jump from 32 to 128 bits was an ambitious leap to future-proof and maybe a small part of the reason adoption is slowed.
- grandinj 8y agoI don't remember any variable-length encodings being proposed, but it was a long time ago. I don't think the 128-bit length was ever an issue, that is just a field length, one parameter amongst many. It's all the other details that make a protocol (and it's surrounding infrastructure) more or less difficult to implement. One of the contending proposals literally modified an existing TCP/IP stack with a constant in all the relevant places, and was then compiled twice. It had #ifdef IPV6 #define ADDR_LENGTH 4 #else #define ADDR_LENGTH 16 #endif and then you could compile the same source twice, once for each protocol, just passing a -DIP6 on the command line for the IPV6 version.