North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Iljitsch van Beijnum
  • Date: Sat Sep 15 16:31:14 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.