Question about 6to4

[Erik Kline]

I certainly wasn't advocating it.  Just pointing out how futile it is.

2009/5/14 Steven Lisson <stevel at dedicatedservers.net.au>

>  Hi,
>
>
>
> Do not advertise anything more specific than 2002::/16, it is specific in
> the RFC that this is not allowed to prevent BGP table bloat. You either
> advertise 2002::/16 or nothing.
>
>
>
> 6to4 is a transition mechanism, we don’t want the ipv6 bgp table becoming
> twice the size with hosts advertising both their IPv6 allocation and any
> 6to4 addresses from their IPv4 allocations.
>
>
>
> Regards,
>
> Steven
>
>
>  ------------------------------
>
> *From:* ipv6-ops-bounces+stevel=dedicatedservers.net.au at lists.cluenet.de[mailto:
> ipv6-ops-bounces+stevel <ipv6-ops-bounces%2Bstevel>=
> dedicatedservers.net.au at lists.cluenet.de] *On Behalf Of *Erik Kline
> *Sent:* Friday, 15 May 2009 3:20 PM
> *To:* Kevin Loch
> *Cc:* ipv6-ops at lists.cluenet.de
> *Subject:* Re: Question about 6to4
>
>
>
>
>
> 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: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090514/1ebad2ee/attachment.html