|
|
|
|
|
|
by mahboi
38 days ago
|
|
|
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. 6to4 etc didn't cut it. Assigning IPs, DNS records, etc is way easier if you don't need to change all of it immediately to get onto v5. You can just get to v5. Changing more things after is easier once nobody is using v4 anymore. The other less important problem with v6 is that it's inherently less user-friendly. There's unclear guidance about firewall defaults that in practice has led to security issues vs just using NAT. The spec has the kitchen sink in it that aren't broadly supported, like DHCP6 and NAT6. SLAAC meant privacy issues that they had to resolve way later with the privacy extension, even though it's more technically elegant in other ways. And people don't like the long :: hex addrs, partially a consequence of using SLAAC. |
|
|
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.