[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Teredo spec has been published!



Agree.

So then let's work in a "transision" plan. I guess we want to make it
coordinated among different implementations, not just the Microsoft one.

I guess Microsoft has some specific thought of how you're going to do that,
and it will be good to coordinate some how, so the current people who has
already deployed Teredo Relays and/or Servers can follow the same criteria.

Can you already tell us something on this, or is still not concreted ?

Regards,
Jordi




> De: Christian Huitema <huitema@windows.microsoft.com>
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Sun, 5 Feb 2006 08:37:31 -0800
> Para: <jordi.palet@consulintel.es>, Vincent Jardin <vincent.jardin@6wind.com>
> CC: <v6ops@ops.ietf.org>
> Conversación: Teredo spec has been published!
> Asunto: RE: Teredo spec has been published!
> 
>> Regarding the private usages, it will be probably so easy as to
> describe
>> them in a new draft, so implementers can decide if support only the
>> existing
>> RFC or also the private usages (I guess most of the open source
>> implementations will be happy to do that).
> 
> The Teredo specification, as it stands, is largely "good enough". It
> could certainly be made even better. But, before we work on a new
> solution, it would be nice to understand the new requirements that we
> try to address. 
> 
> The current specification is designed for the "capital I" Internet, and
> the use of a common prefix pretty much derives from that requirement.
> The 32 bit length derives from a requirement was to embed the server's
> IPv4 address in the prefix. If you don't do that, you end up with a
> reliance on a static "IPv4 anycast" address, which would have to be used
> as source address for the packets sent by Teredo servers. This was in
> fact the original "shipworm" design. It was rejected by the IESG because
> using "anycast" as source causes hard management issues. In any case,
> obtaining a /32 bit allocation from the IANA was very hard, and I don't
> think we will see another one anytime soon.
> 
> -- Christian Huitema
> 




**********************************************
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.