<br><br><div class="gmail_quote">2009/5/14 Kevin Loch <span dir="ltr"><<a href="mailto:kloch@kl.net">kloch@kl.net</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Steve Wilcox wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote>
<br></div>
This is why it is best for both ends to be as close to a relay as<br>
possible. Route efficiency should be vastly better for the "real"<br>
endpoint IPs than for the few public relays that will likely involve a<br>
significant detour.<br>
<br>
I can't recommend the proliferation of public relays as they<br>
cause more problems than they solve. Private relays are another<br>
story as they help mitigate the problems of the anycast relays. If<br>
every service provider ran private 6to4 relays for their customers<br>
it would be a Good Thing.<br><font color="#888888">
<br>
- Kevin<br>
</font></blockquote></div><br>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:<br>
<br> (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.<br>
<br>Obviously, this doesn't scale so well.<br><br> (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).<br>
<br>This also doesn't scale.<br><br>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.<br>
<br>Personally, I'm a fan of 6rd. That's what works for <a href="http://free.fr">free.fr</a>. That, or just go native.<br><br>2c,<br>-Erik<br>