On killing IPv6 transition mechanisms

[Tore Anderson]

Hi,

* Benedikt Stockebrand

> Gert Doering <gert at space.net> writes:
> 
>> If you connect to a dual-stacked host, and your operating system is
>> behaving as Windows does (prefer native IPv6, but if that is not
>> available, prefer IPv4 before 6to4 and Teredo), your client will
>> not use 6to4.
> 
> ok, you know I'm more of a Unixer.  This approach appears quite 
> reasonable but either I misinterpret RFC 3484 or it is a 
> Windows-specific arrangement.

It is not a Windows-specific arrangement, it's implemented in
getaddrinfo() at least in GNU libc, probably most other modern variants
as well.  This is because rule 4 of the destination address selection
(chapter 6) comes into play, which says to prefer matching labels.  A
normal IPv6 address has a different label than a 6to4 address (the table
is in chapter 2.1), so communication between two normal IPv4 addresses
are preferred.

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.

Another far more serious shortcoming of the RFC is that it does not take
into account the prevalence of IPv4 NAT.  RFC 1918 addresses are given
the site-local scope, and rule 2 of the destination address selection
algorithm says to prefer addresses with a matching scope.  A 6to4
address is globally scoped like any other IPv6 address, so this means
that 6to4 connections will be preferred over NAT-ed IPv4 connections
from RFC 1918 prefix.  This becomes a real problem if you for instance
have a SOHO router that can do 6to4 tunneling from its WAN address and
also send regular router advertisements on the LAN side, in addition to
regular IPv4 NAT.  The Apple Airport Extreme is one well-known example
of such a device.

I see quite a bit of breakage (lost clients that's using Mac OS X)
towards my dualstack testing host due to this.  Even though the
behaviour is clearly problematic, it is a completely correct
implementation of the RFC, as far as I can tell.  Unfortunately.  I've
not really seen this behaviour from other operating systems though,
perhaps other implementers have decided not to follow the RFC to the
letter to avoid the problem, or it could simply be that it's really only
Mac users that buy the Airport Extreme.  I would have to look more into
it to say for certain.

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