On killing IPv6 transition mechanisms
pete at twisted.org.uk
Fri Mar 19 12:33:30 CET 2010
> AAAA record is a 6to4 address, in a web browser. The remote web server
> (running Linux) is also using anycast for its 6to4 connectivity. As
> expected (and mandated by RFC 3484), the web browser attempted to use
> 6to4-to-6to4 for the connection, even though the IPv4-to-IPv4
> alternative (no NAT or RFC 1918 involved here by the way) is in my
> opinion clearly superior.
Superor maybe, but both of them work - there is no actual breakage by
using the IPv6 in this case is there ?
I've never seen any breakage when trying to talk between to 6to4 hosts,
only when I have a 6to4 trying to talk to a native server (or vice-versa).
Given that 6to4->6to4 will be preferred if it exists, then providing
the servers with both a native IPv6 and a 6to4 address when enabling them
for IPv6 would seem to handle the 6to4 breakage, no ? Any customer with
working IPv4 to the server should then be able to see it on IPv6 as well,
regardless of the existence if working relays or not, unless I have badly
misunderstood how 6to4->6to4 routing at the IPv4 gateway works (it just
sends the packet directly over IPv4 does it not?).
More information about the ipv6-ops