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

Re: Teredo spec has been published!



Hi Vincent,

I mean peer-to-peer across different domains if we allow different prefixes
(except the issue of the transition period from the 6bone one to the RFC
one).

(see my previous email regarding the transition)

In general I'm not sure if it is a good practice to ignore the IANA defines
definitions for prefixes, addresses, ports, etc. If you really want to use a
different one for an experiment, it may be safer to force doing a patch for
it instead of allowing users to arbitrary change it.

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

Regards,
Jordi




> De: Vincent Jardin <vincent.jardin@6wind.com>
> Organización: http://www.6wind.com/
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Sun, 05 Feb 2006 15:02:58 +0100
> Para: <jordi.palet@consulintel.es>
> CC: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
> Asunto: Re: Teredo spec has been published!
> 
> Jordi,
> 
> Even if you remove the constraint on the hard-coded prefix, the Teredo
> clients "can talk peer-to-peer"; it does not break any compatibility,
> please can you explain why it would be broken ?
> 
> The requirement of being able to configure the Teredo prefix is:
>   - control the transition from the previous prefix to the new one,
>   - be able to support some private usages of the Teredo prefix
> (development, testing, etc.).
> 
> I don't say that 2001:0000::/32 should not be the default value, as
> recommended by the IANA, but it should be configure-able. It is more a
> implementation constraint rather than a standardization constraint.
> 
> Regards,
>   Vincent
> 
> Le dimanche 05 février 2006 à 13:14 +0100, 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.
>> 
>> Regards,
>> Jordi
>> 
>> 
>> 
>> 
>>> De: Vincent Jardin <vincent.jardin@6wind.com>
>>> Organización: http://www.6wind.com/
>>> Responder a: <owner-v6ops@ops.ietf.org>
>>> Fecha: Sun, 05 Feb 2006 13:01:58 +0100
>>> Para: haofeng Zhang <hfzhang.cn@gmail.com>
>>> CC: Christian Huitema <huitema@windows.microsoft.com>, "v6ops@ops.ietf.org"
>>> <v6ops@ops.ietf.org>
>>> Asunto: Re: Teredo spec has been published!
>>> 
>>> Le dimanche 05 février 2006 à 10:56 +0800, haofeng Zhang a écrit :
>>>> Great News.
>>>> I am expecting the next version of Windows will support Teredo service
>>>> proposed by RFC4380.
>>>> Also, I think it will be more flexible if a Teredo Client accepts any
>>>> reasonable global IPv6 prefix, not only 2001:0000::/32 defined in the
>>>> sepcification.
>>> 
>>> Yes, it would be very usefull with we can configure the Teredo prefix on
>>> the next update of Windows, instead of having a hard-coded
>>> 2001:0000::/32.
>>> 
>>> Regards,
>>>   Vincent
>>> 
>>>> 
>>>>  
>>>> 2006/2/4, Christian Huitema <huitema@windows.microsoft.com>:
>>>>         The Teredo spec has been published as an individual
>>>>         submission:
>>>>         
>>>>                RFC4380
>>>>                Teredo: Tunneling IPv6 over UDP through Network
>>>>         Address
>>>>                Translations (NATs)
>>>>                C. Huitema February 2006 ASCII
>>>>                PROPOSED STANDARD
>>>>         
>>>>         Thanks to the many NGTRANS and V6OPS working group members who
>>>>         reviewed
>>>>         the spec!
>>>>         
>>>>         -- Christian Huitema
>>>>         
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Best regards,
>>>> Zhang haofeng 
>>> 
>>> 
>> 
>> 
>> 
>> 
>> **********************************************
>> 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.
>> 
>> 
>> 
>> 
>> 
> 
> 




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