On killing IPv6 transition mechanisms
gert at space.net
Fri Mar 19 12:10:52 CET 2010
On Fri, Mar 19, 2010 at 11:15:38AM +0100, Tore Anderson wrote:
> > Since in this case, no anycast relays are used, [...]
> What makes you think that? The RFC does not distinguish between anycast
> or unicast 6to4 being used; an implementation would have no way of
> determining that anyway (at least for the remote end).
Well, the theory is that 6to4<->6to4 can always go unicast, as the
IPv4 address of the correct relay is in the 2002:<ipv4>:: address.
Only when going from 6to4<->native v6 or native v6<->6to4, you need
to find a "to/from native" relay - and that's either statically configured,
or defaults to 126.96.36.199 - anycasted, so packets can find "the nearest
Now, it would be possible to send packets to 2002:0102:0304::1 and
have "188.8.131.52" be anycasted to multiple relays that will then know
how to access the v6 infrastructure 2002:0102:0304::/48, but that's
a different issue - it's unlikely that "just some random network ops"
out there will add a badly-maintained anycast relay for a specific 6to4
> I just verified this on a Windows 7 host that has auto-configured
> anycast 6to4 connectivity, by trying a dualstacked host-name, where the
> AAAA record is a 6to4 address, in a web browser. The remote web server
> (running Linux) is also using anycast for its 6to4 connectivity. As
> expected (and mandated by RFC 3484), the web browser attempted to use
> 6to4-to-6to4 for the connection, even though the IPv4-to-IPv4
> alternative (no NAT or RFC 1918 involved here by the way) is in my
> opinion clearly superior.
Why is it "superior"? Is the latency (significantly) better?
If you follow the assumption "if the latency is the same, IPv4 is not what
I want to use", the policy table is right. If you follow the assumption
"if everything else is the same, prefer non-tunneled connectivity", the
policy table needs changing.
But in general, "accessing a web server" is not what 6to4 is really
useful for - but for peer-to-peer applications, it is:
Imagine two home users, both sitting behind a single public address
and a NAT, and the NAT box also does 6to4. 6to4 will given them full
peer2peer connectivity to all the machines in the respective subnet,
without latency-impacting detours (because the encapsulated packets
will go directly "6to4 router A" --> "6to4 router B", no 3rd-party
relays needed), and you really gain something here.
(Now where it gets nasty is "6to4 in home A" <-> "Teredo in home B",
because then you have the worst of all worlds - 6to4 anycast relay
and Teredo relay are needed, and unless both are really nearby network-
wise, latency will be awful)
Total number of prefixes smaller than registry allocations: 150584
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 306 bytes
Desc: not available
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100319/e2e1c095/attachment.bin
More information about the ipv6-ops