[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Teredo spec has been published!
Hi Remi,
I see your point regarding the transition, but I'm sure Microsoft, which is
where we have the *much much much* higher % of the Clients, Servers and
Relays, will issue an automatic update that will correct it. Also, as the
clients point by default to the Microsoft Teredo Server, something there may
also do "something" regarding this.
May be the Microsoft Patch for the servers will come out first, allowing
some kind of "dual prefix" support until 6bone phase out, then after a few
weeks, the Client update will be made available.
I guess Christian could describe the "transition" plan so other implementers
can follow a similar approach and we don't get 2 disconnected Teredo
"Internets".
Once this Teredo Server/Relay/Client update is available, at least in our
case, which maintain a Server and a Relay, will move to the new prefix. It
will be just a matter of minutes, hopefully, but an "official" procedure
could be very useful.
I'm not sure if it make sense to make a draft for this. It could be possible
to make a draft just to describe it, even if afterwards is not promoted to
RFC. Just in order to ensure that people looking for "Teredo" in the next 6
months for implementing and/or deploying it, make sure to follow the same
"transition" plan.
Regards,
Jordi
> De: Rémi Denis-Courmont <Remi.Denis-Courmont@via.ecp.fr>
> Organización: Élève de l'École Centrale Paris
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Sun, 5 Feb 2006 14:23:28 +0100
> Para: <jordi.palet@consulintel.es>
> Asunto: Re: Teredo spec has been published!
>
> 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
>
**********************************************
The IPv6 Portal: http://www.ipv6tf.org
Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.