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

RE: Teredo vs Silkroad



I saw that too in the draft via the http ability to the SN adding a tunnel broker like service was very good.  I think this has merit and well written and clear technical specification.  I also want to add the fact that silkroad does not require fixed or defined prefix is a big win for several current IPv6 deployment efforts.   Many clients do not want anything but their aggregatable prefixes used within the network and for transition, and silkroad as one of the mechanisms we have do this too.  It also has security benefit too.
 
/jim


From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Eiffel Wu
Sent: Friday, May 21, 2004 9:55 AM
To: pekkas@netcore.fi
Cc: v6ops@ops.ietf.org
Subject: Re:Teredo vs Silkroad


>> >On Fri, 21 May 2004, Eiffel Wu wrote:
>> >> As compared with the Teredo, Silkroad has the following
>> >> strongpoints:
>> >>
>> >> 2. Silkroad can deploy without the support of relay, while the
>> >> Teredo needs the relay which advertises the reachability of Teredo
>> >> Prefix.
>> >
>> >That's not really true, I think.  You can deploy Teredo using your
>> >own, arbitrary prefix, ("internal Teredo server"), and to the rest of
>> >the Internet, it looks like native IPv6 service.
>>
>> Cited from Teredo:
>> Teredo relays are IPv6 routers that advertise reachability of the
>> Teredo service IPv6 prefix through the IPv6 routing protocols.
>>
>> Teredo address format:
>>   +-------------+-------------+-------+------+-------------+
>>   | Prefix      | Server IPv4 | Flags | Port | Client IPv4 |
>>   +-------------+-------------+-------+------+-------------+
>>   
>>    - Prefix: the 32 bit Teredo service prefix.
>>    - Server IPv4: the IPv4 address of a Teredo server.
>
>Yes, but look at the definitions:
>
>========
>2.5     Teredo IPv6 service prefix
>  
>   An IPv6 addressing prefix which is used to construct the IPv6
>   address of Teredo clients.
>  
>2.5.1   Global Teredo IPv6 service prefix
>  
>   An IPv6 addressing prefix whose value is XXXX:XXXX:/32.
>   (TBD IANA; experiments use the value 3FFE:831F::/32, taken from a  
>   range of experimental IPv6 prefixes assigned to Microsoft.)
>=========
>
>in other words, there can be multiple Teredo IPv6 service prefixes. 
>Anyone can establish one just if the operator has a /32 prefix to
>spare. Many probably don't :).
How many ISPs have a /32 prefix ?
As i know, now there are no ISPs that have a /32 prefix in China.
Moreover, There are thousands of million NAT users in China, which will need
many of Teredo relays and corresponding Teredo /32 prefixes. When does Chinese
ISPs have so many /32 prefixes ? i don't think the day will come soon.
 

>> >> 3. Silkroad supports all types of NATs, while Teredo doesn't support
>> >> symmetric NATs.
>> >
>> >Obviously, this could be added very easily to Teredo as well, but it
>> >would require that Teredo servers would act as tunnel endpoints, and
>> >there would not be direct tunneling.  That would burden the servers to
>> >that it would probably be undesirable.
>>
>> Whether or no, Teredo does not support symmetric NATs.
>
>See section 6.  If you used Teredo just as a tunnel service, it would
>work with symmetric NATs as well.  I don't think many people would
>want to deploy the servers like that though.. :)
 
The tunnel service is mentioned just as an idea and described simply in Teredo.
Silkroad is a tunnel broken similar mechanism and it overcomes the known limitations
of tunnel broker that it can not work if the user is using private IPv4 addresses
behind a NAT box.