| > The problem is they designed v6 with no good compatibility in either direction. I get that there's no way for v6 to support v4, but at least going from v4 to v6 should've been easier. Here are the constraints: """ 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. Furthermore, you don't want to split the Internet in two, so you must design a method of interworking between the 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... 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. |