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

Re: IPv6 routing /48s

  • From: Nathan Ward
  • Date: Wed Nov 19 17:57:07 2008
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