3 ms·

In retrospect, the decision to bootstrap IPng as a hierarchically routed superset of IPv4 seems painfully obvious. A quarter of a century later the great IPv6 t

by yholio 5y ago

In retrospect, the decision to bootstrap IPng as a hierarchically routed superset of IPv4 seems painfully obvious. A quarter of a century later the great IPv6 transition is still incomplete and the limits of IPv4 continue to haunt us. The IPv4 architecture even contained mechanisms to enable such a transition in the form of IP options. This proposal from Bernstein is not functional, but IPng designers could have defined the IPng header format so that 96 bits of the 128 bits source or destination addresses mapped to a structure that looks like an unknown IP option for legacy stacks. For example the IPng address could have had a logical design like this: [upper 64 bit IPng][standard 32bit IPv4][lower 32 bit IPng] With the [upper 64 bit IPng][lower 32 bit IPng] part stored inside the option, and the IPv4 stored at the regular location in the IPv4 header. This means that legacy systems could still interpret and route IPng traffic, and even if they strip the IPng option, the connection can fallback transparently to IPv4, as long as the extended fields are nil. In time, the infrastructure would upgrade to the new header format and would learn to route the extended address space, leaving the legacy IPv4 space to live in a /64 inside the 128 bit space. In the meantime, the lower IPng 32 bit could have prevented the proliferation of NAT, if the endpoints were upgraded and the backbone was transparent to options (essentially, IPng islands connected via the IPv4 internet). There were proposals for such mechanisms in the 90s but the committee wanted a clean slate design, ignoring decades of experience with interoperability and technological transitions. Of course, any talk about such alternatives is today a purely pedantic exercise, the window was closed 20 years ago and today IPv6 is the only possible future.

cesarb 5y ago
> In retrospect, the decision to bootstrap IPng as a hierarchically routed superset of IPv4 seems painfully obvious. Indeed. For IPv6, it's called 6to4, and it actually worked; for a while, I had configured the office network to use it, and could reach IPv6 networks even though that office only had a single public IPv4 address. (I'm working elsewhere right now and no longer the network admin, so I don't know how well 6to4 works nowadays.) > The IPv4 architecture even contained mechanisms to enable such a transition in the form of IP options. Unfortunately, that's no longer an option, and was already no longer an option back then. This is because of middleboxes like firewalls, IDS, or worse, which discard and/or reject anything they don't know, instead of leaving the end system to deal with it (as would be correct following the end-to-end principle the Internet is designed on). This is called "protocol ossification": https://en.wikipedia.org/wiki/Protocol_ossification https://en.wikipedia.org/wiki/Protocol_ossification > This means that legacy systems could still interpret and route IPng traffic, [...] as long as the extended fields are nil. They would have to be nil forever, or at least as long as the IPv6 transition is currently taking. If even a single endpoint you might want to talk to doesn't understand that new IP option (and since you don't control all the remote endpoints, you can never be sure), your local address has to have zeros on these extended fields. The dual-stack approach used by IPv6 avoids this issue by having two independent addresses, one to contact legacy remote endpoints, the other one to contact newer endpoints, and keeping them separate. > In the meantime, the lower IPng 32 bit could have prevented the proliferation of NAT It would instead lead to the proliferation of NAT, as that would be the only guaranteed way to make it work when the local endpoint address has a non-zero value in the extended fields. > if the endpoints were upgraded and the backbone was option transparent That's where all these proposals fail: they would require all endpoints to be upgraded before use of these extended addresses can start. And while the core Internet backbone might be completely transparent, the path to reach it often isn't.

by yholio 5y ago

cesarb 5y ago

> In retrospect, the decision to bootstrap IPng as a hierarchically routed superset of IPv4 seems painfully obvious. Indeed. For IPv6, it's called 6to4, and it actually worked; for a while, I had configured the office network to use it, and could reach IPv6 networks even though that office only had a single public IPv4 address. (I'm working elsewhere right now and no longer the network admin, so I don't know how well 6to4 works nowadays.) > The IPv4 architecture even contained mechanisms to enable such a transition in the form of IP options. Unfortunately, that's no longer an option, and was already no longer an option back then. This is because of middleboxes like firewalls, IDS, or worse, which discard and/or reject anything they don't know, instead of leaving the end system to deal with it (as would be correct following the end-to-end principle the Internet is designed on). This is called "protocol ossification": https://en.wikipedia.org/wiki/Protocol_ossification https://en.wikipedia.org/wiki/Protocol_ossification > This means that legacy systems could still interpret and route IPng traffic, [...] as long as the extended fields are nil. They would have to be nil forever, or at least as long as the IPv6 transition is currently taking. If even a single endpoint you might want to talk to doesn't understand that new IP option (and since you don't control all the remote endpoints, you can never be sure), your local address has to have zeros on these extended fields. The dual-stack approach used by IPv6 avoids this issue by having two independent addresses, one to contact legacy remote endpoints, the other one to contact newer endpoints, and keeping them separate. > In the meantime, the lower IPng 32 bit could have prevented the proliferation of NAT It would instead lead to the proliferation of NAT, as that would be the only guaranteed way to make it work when the local endpoint address has a non-zero value in the extended fields. > if the endpoints were upgraded and the backbone was option transparent That's where all these proposals fail: they would require all endpoints to be upgraded before use of these extended addresses can start. And while the core Internet backbone might be completely transparent, the path to reach it often isn't.