Question about 6to4

[Steven Lisson]

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=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: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090515/d35a14a7/attachment.htm>