On killing IPv6 transition mechanisms

[Gert Doering]

Hi,

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 192.88.99.1 - anycasted, so packets can find "the nearest
relay".

Now, it would be possible to send packets to 2002:0102:0304::1 and
have "1.2.3.4" 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
range.


> 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)

Gert Doering
        -- NetMaster
-- 
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
Type: application/pgp-signature
Size: 306 bytes
Desc: not available
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100319/e2e1c095/attachment.sig>