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.