On Fri, 14 Oct 2005, Stephen Sprunk wrote:
RFC 3068 also has another problem -- not enough relays, or at least not enough in logical locations. From my home in Texas, a traceroute shows the topologically "closest" instance of 192.88.99.1 to be in France.
Well, anycast isn't necessarily the best way to do it. And when I lasyt checked routeviews, there weren't all that many orgs advertising the anycast special route. Yes, more should, but... <sigh> That said, even such a distant gateway would be fine for v6 *eyeballs* if organizations would voluntarily set up 6to4 outbound relays for their own v6 networks. It's as simple as setting up a route to 2002::/16 at the border with a 6to4 conversion. Only the border router itself needs to know about it; the v6 source address in the payload can continue to be native. (This still passes the security checks noted by RFC-I-can't-remember-right-now.) The great kick about this is that 6to4 eyeballs will mostly have content going *to* them, so the 6to4 relay at the organization's border will get the packets to their destination in the most efficient fashion: traveling v4 from the border to the user. This assumption is based on the typical 6to4 situation, because using 6to4 normally implies that the v4 path is the more efficient one. So, while mostly ACKs are going the slow route from the user, the big chunks of data are coming back to the user via the fast route. Example: home.duh.org is 2001:470:1f00:342::2, but if you connect to it via 6to4, the return packets will come back tunneled 6to4 directly by my border. This is doubly good for me, because my "natively addressed" v6 is tunneled anyway, so using my v6 upstream for 6to4 return traffic would mean twice the yummy tunnel slowness. Instead, my return traffic for 6to4 clients uses *zero* third party v6 tunnels. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>