On 20/11/2008, at 11:05 AM, Jack Bates wrote:
Nathan Ward wrote:
The problem here is XPSP2/Vista assuming that non-RFC1918 =
unfiltered/unNATed for the purposes of 6to4.
Well, deeper problem is that they're using 6to4 on an end host I
suppose - it's supposed to be used on routers.
While I don't doubt that the 6to4 is broken in such circumstances,
how many IPv6 content providers are using 6to4 addressing and not
2001:: addressing? 6to4 by default on xp and vista, in my
experience, is only used if a) talking to another 6to4 address or b)
there is no IPv4 address available.
IPv6 will be used in preference to IPv4 if it is available. If 6to4 is
the only IPv6 connectivity then it will be used. See RFC3484.
Preference of IPv4 is 10, 6to4 is 30.
Things are a bit different with Teredo.. In Vista, if Teredo is the
only IPv6 connectivity available, WSAConnectByName will not send
queries for AAAA - obviously Teredo can still be used if the
application does its own name resolution and opens sockets by INET6
address, not name.
This Teredo behaviour is not documented in an RFC anywhere I don't
believe, it is Windows specific.
6to4 never seemed like a viable method for content providing, though
its use at the eyeball layer is somewhat iffy given that it's
primary use is for other 6to4 addresses. If prefix policies are
altered to use it for 2001:: addressing, problems start arising
quickly.
Right, so, because of how RFC3484 works the above is largely invalid.
Because of RFC3484, putting 6to4 addresses on content is actually
quite a good idea. It means that hosts with 6to4 connectivity only
will not have to go via an RFC3068 (192.88.99.1) relay - they will go
direct over an IPv4 best path between their 6to4 router and yours.
This works best if RFC3484 is widely deployed - it is, however it does
not exist on OS X. Because of this, if you do this you may find OS X
clients visiting your content on a 6to4 address when they have native
connectivity, or vice versa.
So.. stuff to play with, and please go encourage Apple to do RFC3484
if you are a big customer of theirs.
A good example is that traceroutes through my he.net tunnel using
6to4 source addresses do not get replies through he.net's network,
presumably due to their routers not being 6to4 aware and having no
route to respond. Responses pick up again after picking up a network
such as NTT that is 6to4 aware. My 2001:: addressing works just fine
the entire route.
No, he.net does not have a 6to4 relay. If they did it would be used by
a very large number of networks as he.net is fairly well peered.
Because of that, the traffic would be quite high, and any relay
deployment there would have to be managed quite carefully.
I'm sure there's quite a few networks that aren't 6to4 aware,
hindering 6to4 connectivity to non-6to4 addresses.
6to4 does not require networks to be 6to4 aware - the Internet has
many public 6to4 relays available.
Note though that most end user IPv6 hosts have a 6to4 relay within 3
IPv6 hops. This is easy to calculate - throw up an AAAA pointing only
to a 2002::/16 address, and look at the HLIM of the IPv6 header (not
the IPv4 header). You will see that it is generally between 124 and
128, or 60 and 64.
(Some hosts start at 128, some 64. Few start at much else it seems.)
I did some work looking at IPv6 adoption using Bittorrent DHT to talk
to large numbers of peers without downloading any content, this was
one of the interesting points that fell out of that work.
Content providers wanting to put AAAA records on things should run
6to4 relays until IPv4-only networks are a thing of the past. If they
don't, they'll have to rely on third party relays that might not work.
--
Nathan Ward
