Question about 6to4
ek at google.com
Fri May 15 07:19:50 CEST 2009
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ipv6-ops