4 ms·
“In December 1998, IPv6 became a Draft Standard for the IETF,[2] which subsequently ratified it as an Internet Standard on 14 July 2017.” 40% adoption after 25
by krnlpnc 4y ago
“In December 1998, IPv6 became a Draft Standard for the IETF,[2] which subsequently ratified it as an Internet Standard on 14 July 2017.”
40% adoption after 25 years? Really highlights how terrible IPv6 is in terms of backwards compatibility.
What we needed was an internet protocol with the benefits of IPv6 that runs as an extension to the IPv4 stack.
The current approach to duplicate everything into IPv6 is wasteful and time consuming, proven by the extremely slow adoption rate.
- goodpoint 4y agoDespite the downvotes you are right. IPv6 replaces IPv4 rather than building on top of it and this really harmed adoption.
- Arnt 4y agoI read all of the IPv6-ish proposals at the time, and they all had major problems of one kind or another. The chosen proposal "really harmed adoption" when compared to a pie in the sky, not to the other proposals.
- neilalexander 4y agoIt's not as simple as that. There's no just "extending" the IPv4 stack unless you're going to "extend" every device that supports IPv4 with it. By that point you'd might as well just have IPv6.
- CharlesW 4y ago> What we needed was an internet protocol with the benefits of IPv6 that runs as an extension to the IPv4 stack. My understanding is that the reason it's a new version is so existing IPv4 infrastructure would not need to be changed. This "ships in the night" approach has pros and cons, of course, but I'm personally happy to give folks who thought about this problem for many years the benefit of the doubt. > The current approach to duplicate everything into IPv6 is wasteful and time consuming, proven by the extremely slow adoption rate. The beauty of the IPv6 approach is that it doesn’t matter how long it takes. I don't understand how it's "wasteful". Is it wasteful to support 3 versions of HTTP?
- krnlpnc 4y agoHTTP is backwards compatible
- CharlesW 4y agoIt's not. There's a negotiation process, but you can't use HTTP/3 to deliver content to a client that doesn't support it. "HTTP/3 uses QUIC instead of TCP for the underlying transport protocol. Like HTTP/2, it does not obsolesce previous major versions of the protocol." - https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
- drivebycomment 4y agoWould you care to elaborate what "an internet protocol with the benefits of IPv6 that runs as an extension to the IPv4 stack" actually looks like at the technical level that would give the "backward compatibility" that IPv6 you claim is lacking ?
- welterde 4y agoIPv6 is perfectly backwards compatible with IPv4 with the IPv4-in-IPv6-address embedding and other technologies. The problem is that IPv4 is not forward-compatible with anything that has a larger address space. Thus a IPv4-only host will never ever be able to communicate with a non-IPv4 host, since there is no way to encode more than 32-bit of information in the IPv4 header. So you will always end up in this situation where people just won't bother implementing the IPv4-replacement and you cannot simply switch to it.
- kortex 4y agoBut why couldn't we just put a middlebox in front of the host which translates a 4-over-6 address to a plain ipv4? The host box still sees only v4 but v6-only devices can still connect to it. Like I could envision a simple router-like device doing this.
- welterde 4y agoThat's not the direction that's the problem - like I mentioned (IPv6 is backwards compatible), NAT64 and so forth boxes exist (but still not great since you have to hold state). But the problem is that the inverse is not possible. How would a IPv4-only box connect to a non-IPv4 box? How do you encode more than 32-bit of information into the 32-bit destination address field of the IPv4 packet?