On killing IPv6 transition mechanisms

[Tore Anderson]

Hi Gert,

* Gert Doering

> On Thu, Mar 18, 2010 at 10:46:49PM +0100, Tore Anderson wrote:
>> However, if both the client and the server were to have 6to4-addresses,
>> a 6to4-to-6to4 connection will be preferred over IPv4-to-IPv4, since now
>> both the options have matching labels, but the 6to4 one wins because it
>> has a higher sorting precedence.  In my opinion, this is a bug in the
>> RFC, but I don't think it has any significant operational impact.
> 
> Since in this case, no anycast relays are used, [...]

What makes you think that?  The RFC does not distinguish between anycast
or unicast 6to4 being used;  an implementation would have no way of
determining that anyway (at least for the remote end).

I just verified this on a Windows 7 host that has auto-configured
anycast 6to4 connectivity, by trying a dualstacked host-name, where the
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.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27