Re: Creating demand for IPv6

[Nathan Ward <nanog () daork net>]

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