Re: Teredo spec has been published!

[Rémi Denis-Courmont <Remi.Denis-Courmont@via.ecp.fr>]

Le Dimanche 5 Février 2006 13:14, JORDI PALET MARTINEZ a écrit :
> I don't agree.

> If you do so, you break one of the principles of Teredo, and then you
> do not longer need an IANA assigned prefix.

> The idea is to ensure that all the Teredo clients can talk
> peer-to-peer.

I would say there are different problems here:
1/ the transition from Microsoft experimental (3ffe:831f::/32) to IANA 
assigned (2001:0000::/32) prefixes
2/ internal private use of Teredo as a NAT-friendly ISATAP, whereas it 
is defined as a NAT-friendly 6to4 (sort of)


Regarding the Teredo prefixes transition:

I would say it would have been more practical if Windows-based clients 
had accepted any (sensible?) Teredo prefix until the RFC was published, 
which is what my -admittedly hardly used at all- implementation does. 
Similarly, it should have been possible to configure the prefix 
advertised by servers and relays until a post-RFC updates, to ease 
migration of pre-RFC users.

The fact is that they are many Windows users that use pre-RFC Teredo 
clients that only accept 3ffe:831f::/32, probably many of whom not even 
knowingly. As a reference, the www.videolan.org typically receives 
something like 50Gb/day IPv4 traffic, 500Mb/day native IPv6+6to4, 
50Mb/day via pre-RFC Teredo, and absolute zero IANA Teredo. It has 
Teredo relays for both Microsoft experimental and IANA assigned 
prefixes.

If you maintain a relay, you can transition smoothly by putting two 
relays until 6bone is phased out. But for Teredo servers and clients, 
there is no way to transition smoothly at the moment.


Regarding the private use case:

The fact that the prefix has to be a /32 renders, it is almost 
impossible in practice. I would say implementors should obviously use 
and encourage use of the IANA prefix by default. It is arguably useless 
to allow the use of another prefix, but implementations should at least 
accept the experimental prefix until 6bone is phased out for pratical 
reasons discussed above.

A company willing to use Teredo internal as a "NAT-friendly ISATAP" may 
still want to use a different prefix, e.g. for access-control, or 
because it wants to put the servers/relays on private IPv4. However, in 
any case, that would involve a bunch of modifications in contradiction 
to the Teredo RFC in any case, such as:
- allowing Teredo addresses bits 32-63 to differ from the server IPv4 so 
that 64-bits prefix is sufficient, provided all clients can assume the 
others use the same server as themselves,
- ignoring the requirements for mapped and server IPv4 addresses to be 
unicast global.

So... well... there is indeed probably no case for a *RFC-compliant* 
implementation to accept a prefix other than the IANA (and 
experimental) one(s).

But then, Microsoft is already promising an unspecified extension in 
upcoming Vista, which is the ability to use Teredo from behind a 
symmetric NAT, at the obvious expense of transitive reachability. Also, 
as I already pointed out a long time ago here, Teredo clients assume 
that the server secondary IPv4 address is always next to the server 
primary address, though I could find no mention of that requirement in 
the RFC nor any of the six drafts (I've not read the older "shipworm" 
ones).

-- 
Rémi Denis-Courmont
Student-engineer at the Ecole Centrale Paris
http://www.simphalempin.com/home/infos/cv.shtml.en