Question about 6to4

[Erik Kline]

2009/5/14 Kevin Loch <kloch at kl.net>

> Steve Wilcox wrote:
>
>  Thats one of the downsides with 6to4 - the packet may go in the wrong
>> direction in v6 before passing through the relay and then heading in the
>> opposite direction to find the v4 endpoint.
>>
>
> This is why it is best for both ends to be as close to a relay as
> possible.  Route efficiency should be vastly better for the "real"
> endpoint IPs than for the few public relays that will likely involve a
> significant detour.
>
> I can't recommend the proliferation of public relays as they
> cause more problems than they solve.  Private relays are another
> story as they help mitigate the problems of the anycast relays.  If
> every service provider ran private 6to4 relays for their customers
> it would be a Good Thing.
>
> - Kevin
>

The problem is that only addresses half the flow.  You've succeeded in
helping your customers get their packets onto the IPv6 Internet efficiently
(yay!).  But to get them back 1 of 2 things needs to happen:

    (1) Every content provider/destination needs to have good, and
preferably local, access to a 2002::/16 return device so it can re-encap the
packets and send them to their IPv4 origin.  Otherwise they go off into
wherever 2002:/16 happens to point at that time.

Obviously, this doesn't scale so well.

    (2) You attempt to advertise your own IPv4 networks under 2002::/16,
thereby adding portions of the IPv4 routing table into IPv6  (assuming you
could even get anything longer than a /32 past everyone's filters).

This also doesn't scale.

Unfortunately Lorenzo's latest presentation from RIPE 58 isn't up, but in it
he showed how we see roughly ~100msec extra latency with the various relay
mechanisms like 6to4 and Teredo over native and static tunnel methods.

Personally, I'm a fan of 6rd.  That's what works for free.fr.  That, or just
go native.

2c,
-Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090514/970ab5fd/attachment.htm>