IPv6 routing /48s
alh-ietf at tndh.net
Tue Nov 25 18:02:22 CST 2008
Jack Bates wrote:
> Yes and no. The test that was being run used 6to4 addresses, so every
> 6to4 capable device did try to reach it via 6to4, since that is
> preferred over IPv4. If it had used non-6to4 addressing, then IPv4
> had been preferred on those hosts that didn't have non-6to4 addresses.
> This is one reason why I believe using 6to4 addresses to be an issue
> content providers. If they use non-6to4 addressing for the content,
> most people will prefer IPv4 except for those who have configured
> non-6to4 addresses or altered the labels to force 6to4 to work with
> non-6to4 addressing.
> Gads, is it appropriate to just say Native when referring to non-6to4?
Terminology is a mess, because 2001:: could be tunneled directly from the
end system, and 2002:: might be received in an RA by an end system so it
doesn't know the difference between that and any other prefix.
In any case, content providers can avoid the confusion if they simply put up
a local 6to4 router alongside their 2001:: prefix, and populate DNS with
both. Longest match will cause 2001:: connected systems to chose that dst,
while 6to4 connected systems will chose 2002:: as the dst. There is no need
to offer transit service to the entire world, and the latency/path selection
for 6to4 to their demark will be exactly the same as the IPv4 service.
Access providers could offer a localized 6to4 relay by ignoring the comment
in the RFC that says 'must advertize 2002::/16', and send the appropriate
~32-40 into the IPv6 routing system that corresponds just to the customers
being served by that relay. Yes the IPv6 routing system gets bigger, but
there aren't enough people that would consider deploying a 6to4 relay to
create a --real-- problem. FUD mongers will scream, but be pragmatic and
only announce what is necessary to get some stable service to your
customers. Running this service also provides a way to document how many
people are using IPv6 despite the lack of availability on the distribution
media. Now we get constant reports of no-traffic, because it is bypassing
the local ISP monitoring system. On a recent torrent ~ 1/3 of the peers were
connecting via IPv6, and most of the content my client exchanged was via
those peers rather than the IPv4 ones. Clearly there is traffic, it is just
going over the top to work around the lack of the service that is required
More information about the NANOG