On killing IPv6 transition mechanisms

[Brian E Carpenter]

On 2010-03-19 10:46, Tore Anderson wrote:
> 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.

I believe this was intentional, since the philosophy was 'prefer IPv6
connectivity if it exists'. I also agree that reversing this in
the policy table would be very reasonable; 3484 only provides a
*default* policy table.

> 
> 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.  

Again, intentional, for the same reason.

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.  

You mean, I assume, that it turns out that there is no 6to4 relay
in the outbound or return path? That is (IMHO) the problem
with RFC 3068. The assumption of RFC 3056 was that the placement
of 6to4 relays would be a managed process, for savvy early-adopter
sites. The addition of the anycast relay model in RFC 3068 broke that
assumption and brought about unmanaged deployment.

Nathan Ward has suggested a way to fix this (and the equivalent
problem with Vista/Teredo) but it does need sites or ISPs to install
a box to catch the anycasts.

    Brian

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,