|
|
|
|
|
by nybble41
2067 days ago
|
|
6to4 provides a standard way to tunnel IPv6 traffic at the perimeter over an IPv4 backbone, essentially assigning a range of IPv6 subnets to every public IPv4 address, but it doesn't provide full backward compatibility, and it still depends on proxies at the border of the IPv4 network. The applications at the endpoints need to support IPv6—so all the existing software still needs to be updated—and you still need new protocols for address assignment (SLAAC or DHCPv6) and domain resolution (AAAA records), along with any other protocols than embed IP addresses. Most of this is an inevitable consequence of extending the address space; no amount of clever tricks can make IPv4-only applications, hosts, or protocols automatically compatible with larger IP addresses. 6rd works on similar principles, but in a way that plays more nicely with ISP routing and traffic management policies. The main user-visible change is that a variable-length, ISP-specific prefix is used instead of 2002::/16. There are a few other transition mechanisms and embeddings of the IPv4 address space, for example the ::a.b.c.d address format. They all suffer from the fact that two-way communication without a proxy requires each endpoint to be capable of representing the full address of its peer. For a node which does not have a public IPv4 address to communicate with a node which does not understand larger addresses, some third node must exist in between to perform protocol translation. |
|
Applications would still need to change, but apps change a lot faster than ISPs.
6to4 died because it was never the primary mode of addressing. Performance between 2002::/16 and the rest of IPv6 relied on anycast, which was unpredictable and therefore useless for real traffic.