> 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

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