book6

x.y.z::/48. It has nothing to do with "clean slate" or not. There are two immovable facts: """ IPv4 implementations, in 1994 and still today, have the 32-bit address format built into their code. Whether you expand the address size to 33, 64 or 128 bits, all IPv4 implementations will discard the packets. So it's a matter of mathematical and physical fact that to expand the address size, you must change the protocol, and that means two things immediately: 1. You have to change the version number. 2. You have to add new code to handle the new version. "" * https://github.com/becarpenter/book6/blob/main/01.%20Introdu... And this also includes 'accessory protocols': DNS A records are fixed at 32-bits, so if you want to use hostname with IPng you needed to upgrade the DNS infrastructure, including APIs to say "give me A and Ang", and then you perhaps need fallback mechanisms, in which case you're at: * https://en.wikipedia.org/wiki/Happy_Eyeballs Any IPng protocol, including 'just' adding bits, regardless of how you want to hand wave it as being 'just' an extension of IPv4 will be in same situation because you can't fit >32-bits in the 32-bits of the original code. You're rolling out new code in a rolling fashion, just like had to be done with IPv6.

64 | 64 | |------|------|------| NEW | XX | 64 | 64 | ---------------------- * https://github.com/becarpenter/book6/blob/main/01.%20Introdu... There's no way around it: a non-IPng-having node will have to go through a translation box of some kind.

So, You need a coexistence technique so that updated systems, with the new protocol, can connect to old systems that know nothing of the new protocol. Two minutes of thought show that this third requirement has only two solutions: (3A) Dual stack, in which the new machines speak both the old (IPv4) and new (IPng) protocol. (3B) Translation, in which something translates addresses between the old and new protocols. […] Incidentally, "IPv8" proponents often ask why IPv6 didn't simply stick some extra bits on the front of IPv4 addresses, instead of inventing a whole new format. Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in [RFC3513] but deprecated by [RFC4291] because it turned out to be of no practical use for coexistence or transition. The related "IPv4-Mapped IPv6 address" format is still valid and has a role in the POSIX socket API. Mappings of this kind also figured in the moderately successful coexistence technologies known as 6to4 [RFC3056, RFC3068] and Teredo [RFC4380], which have now been overtaken by events. """ * https://github.com/becarpenter/book6/blob/main/01.%20Introdu... * Interview with author of article: https://www.youtube.com/watch?v=W3jkZ1Ulz-s

machines don't know anything at all about the new version, by definition. So, 3. You need a coexistence technique so that updated systems, with the new protocol, can connect to old systems that know nothing of the new protocol. Two minutes of thought show that this third requirement has only two solutions: (3A) Dual stack, in which the new machines speak both the old (IPv4) and new (IPng) protocol. (3B) Translation, in which something translates addresses between the old and new protocols. This has been known for more than 30 years [RFC1671], although people still sometimes try to deny it. """ * https://github.com/becarpenter/book6/blob/main/01.%20Introdu... It is impossible for IPv4 to connect to IPv6: IPv4 data structures have 32-bit data structures, and this includes the fact that DNS A records are 32-bit only. You cannot have a more-than-32-bit-addresses protocol scheme that can be reach by non-updated IPv4 systems. If you want to add more bits there is no way around adding/changing code, in which case you are in the exact same situation as we have now with IPv6. You either go with 3A or 3B above.

rpenter/book6/blob/main/01.%20Introdu... The people who created IPv6 weren't stupid: if you think you've thought up of a new idea, you probably haven't. Your "new idea" is either in the exact same situation as IPv6 or it was actually attempted and ended up being discarded.

he old version and the new version. Annoyingly, you need to do that in a way that can be done completely in machines that know about the new version, because other machines don't know anything at all about the new version, by definition. So, 3. You need a coexistence technique so that updated systems, with the new protocol, can connect to old systems that know nothing of the new protocol. Two minutes of thought show that this third requirement has only two solutions: (3A) Dual stack, in which the new machines speak both the old (IPv4) and new (IPng) protocol. (3B) Translation, in which something translates addresses between the old and new protocols. This has been known for more than 30 years [RFC1671], although people still sometimes try to deny it. """ * https://github.com/becarpenter/book6/blob/main/01.%20Introdu... Any IPv4+ idea that "just" adds more address bits will same issues we've faced with IPv6.