Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)

Sat Sep 15 20:24:35 UTC 2007

On 15-sep-2007, at 22:03, Jeroen Massar wrote:

> [spam: Check http://www.sixxs.net/misc/toys/ for an IPv6 Toy  
> Gallery :)]

Spam: read a good book about IPv6.  :-)

> The IETF recommendation is that IPv6 is tried before IPv4, BUT  
> there is
> RFC3484 (http://www.ietf.org/rfc/rfc3484.txt) which gives an extra  
> edge
> to this. In general it comes down that the resolver will, assuming  
> there
> is both an IPv4 and IPv6 address (A + AAAA) on the dns label requested
> try, as a source address:

> - IPv6 native (anything not 2002::/16 + 2003::/32)
> - IPv4 native
> - IPv6 6to4 (2002::/16)
> - IPv6 Teredo (2003::/32

No, that's not true:

    If an implementation is not configurable or has not been configured,
    then it SHOULD operate according to the algorithms specified here in
    conjunction with the following default policy table:

       Prefix        Precedence Label
       ::1/128               50     0
       ::/0                  40     1
       2002::/16             30     2
       ::/96                 20     3
       ::ffff:0:0/96         10     4

So first IPv6 loopback, then IPv6 any, then some ancient automatic  
tunneling that nobody uses and finally IPv4. ::ffff:0:0/96 is for  
IPv4-mapped IPv6 addresses (or was it the other way around??) so that  
prefix contains all IPv4 addresses in a way that they can be used  
with IPv6 APIs.

However, Windows XP wil _in_ _practice_ do what Jeroen says because  
of the label matching. The idea is that source and dest must have the  
same label value and then the highest precedence wins, this avoids  
using an IPv6 source address with an IPv4 destination address and the  
like. If you have native IPv6 on the remote end and 6to4 (2002::/16)  
on your end, then the labels don't match but for IPv4 on both ends  
they do so XP will choose that over the native/6to4 combo. Not sure  
what Vista or FreeBSD do, not aware of any other OSes that implement  
RFC 3484.

> 6to4 and Teredo are a big problem here, especially from an operator
> viewpoint. This as an operator has absolutely no control over the flow
> of packets from/to his/her network. When the packets flow back it  
> might
> just be that, due to BGP in the remote network, something attracts the
> 6to4 packets destined back for 6to4 and they mysteriously disappear or
> get routed around the world.

Easily solved by running your own private (or public) 6to4 relay:  
then the packet goes directly to the other end without detours over  
IPv4. You can't control how the packets get from the remote 6to4 user  
to you, though.