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