Re: IPv6 routing /48s

From: Nathan Ward (no email)
Date: Wed Nov 19 2008 - 17:56:58 EST

  • Next message: Jack Bates: "Re: IPv6 routing /48s"

    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 ( 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 tunnel using
    > 6to4 source addresses do not get replies through'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, does not have a 6to4 relay. If they did it would be used by
    a very large number of networks as 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

  • Next message: Jack Bates: "Re: IPv6 routing /48s"

    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs

    Powered By FreeBSD   Powered By FreeBSD