On killing IPv6 transition mechanisms

Mohacsi Janos mohacsi at niif.hu
Fri Mar 19 10:22:18 CET 2010




On Thu, 18 Mar 2010, 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.
>
> 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.

1. most of the RFC 3484 implementation changes this behaviour: RFC-1918 
addresses treated as global scope due to proliferation of NAT devices.

2. IETF 6man is working on revising the RFC 3484 - express your opinion on 
mailing list ipv6 at ietf.org about this topic.

Best Regards,
 	Janos Mohacsi


More information about the ipv6-ops mailing list