On 4/10/2007, at 12:24 PM, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
I did not change anything on that page, either. For the record, that's because I have a screaming two-year-old trying to use me as a climbing wall right now.
My 10 month-old is soundly sleeping right now so I incorporated your suggestions into the page.
Michael, It would also be worth noting that 6to4 <-> 6to4 goes direct over IPv4 - not through 192.88.99.1 (or whatever other relay you've chosen). It's truely stateless, and the concept of client/server is misleading - when a 6to4 router transmits an IPv6 packet over IPv4, all it's doing is looking at the next-hop to reach that v6 address, and taking bytes 3-6 from the IPv6 address and using that as the destination IPv4 address. In most cases, the next-hop for 2000::/3 is set to 2002:192.88:99.1:: So, content providers would be wise to route 2002::/16 at a 6to4 router they run in-house, so that at least the return path to the 'customer'/'client'/'end user of their content services' goes over a more-or-less identical path as it would if it were IPv4. The content provider can run this on any public IPv4 address, and packets aren't going to be coming back that way. (RFC1918 would work, but you might be blocked by bogon RPFs in some cases). Teredo is really good in this sense - your client detects which relay Teredo packets come from, and caches that as the best relay to use to talk to that host. So, you get close-to-IPv4-path for both forward and reverse. So, content providers should run Teredo relays also - their over- Teredo performance will be almost the same as their over-IPv4 performance. There should be no reason that 6to4 can't do the same thing, I suppose. -- Nathan Ward