Subject: RE: Teredo vs Silkroad

From: "Bound, Jim" <[email-masked]>
Date: Fri, 21 May 2004 23:35:05 -0400

I don't see any relays in Silkroad?
thanks
/jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christian Huitema
> Sent: Friday, May 21, 2004 11:58 AM
> To: Eiffel Wu; [email-masked]
> Cc: [email-masked]
> Subject: RE: Teredo vs Silkroad
> 
> From an analysis of the drafts, it appears that silkroad is 
> closer to tunnel brokers than to Teredo. Silkroad relies on 
> the deployment of a large number of relays and servers, that 
> become part of the ISP
> infrastructure: this is very similar to the deployment of 
> tunnel servers by the ISP. It provides pretty much the same 
> advantages as tunnel brokers, i.e. stable addresses and 
> robust tunneling across different types of infrastructure.
> 
> The part of Silkroad that somewhat resemble Teredo is the 
> routing optimization between the tunnel servers (called SAR 
> in silkroad). I don't think that this is particularly 
> valuable: once you have reached an ISP router, you would 
> expect normal routing protocols to take over and route 
> packets along the optimal path. In fact, this feature will be 
> perceived as detrimental by many ISP, since it makes their 
> network management more complex than necessary. 
> 
> -- Christian Huitema
> 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 21 May 2004 23:36:09 -0400

Silkroad defines a protocol within UDP to discover routers.  That is new
IMO.  And worth discussion.
/jim 

> [mailto:[email-masked]] On Behalf Of JF Tremblay
> Sent: Friday, May 21, 2004 12:04 PM
> To: rengrong wang; [email-masked]
> Subject: Re: Teredo vs Silkroad
> 
> --On May 21, 2004 2:31 PM +0800 rengrong wang 
> <[email-masked]> wrote:
> 
> > Hi,
> >
> > In draft-liumin-v6ops-silkroad-01.txt it is said that 
> Silkroad wants 
> > to enable nodes located behind one or several IPv4 NATs to 
> obtain IPv6 
> > connectivity and it seems like a tunnel-broker solution.  
> It is known 
> > that Teredo is a automatic tunnel mechanism that figures 
> out the same 
> > problem.
> >
> > What's the difference between Silkroad and Teredo?
> 
> IMHO, Silkroad is simply another protocol based on tunnel 
> broker/server model (RFC3053) with an optimization to make 
> two hosts on the same link realize they can talk directly. 
> Teredo on the other hand allows hosts implementing a Teredo 
> client to exchange directly through NATs, except symmetric 
> ones. However traffic to hosts not implementing a Teredo 
> client must go through a relay.
> 
> At first sight, Silkroad doesn't seem to offer any 
> significant improvement over TSP, except the 
> nodes-on-same-link optimization. Both support NAT traversal 
> with any type of NAT, including nested ones. However TSP 
> doesn't require the use of a web page, offers prefix 
> delegation, authentication and has a solid experimental 
> background since it's been deployed for over 5 years to more 
> than 100000 users.
> 
> The question sparking in my mind from this is whether of not 
> the detection of two tunneled hosts on the same link would be 
> a desirable feature to include in the tunnel broker model. It 
> involves the broker telling a host what is the public IPv4 
> address and port of another host, which may be a security 
> issue. However with Teredo this information is already 
> included in the IPv6 address, so I guess it would provide the 
> same level of security.
> 
> > Best regards,
> >
> > Crisy(Rengrong) Wang
> > =======================================
> > USC,EE-Systems
> >
> >
> 
> Jean-Francois Tremblay
> Hexago
> -------------------------------------------------
> http://www.freenet6.net : Free IPv6 Connectivity
> -------------------------------------------------
> "Computer Science is no more about computers than astronomy 
> is about telescopes" - E. W. Dijkstra
> -------------------------------------------------
> 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 21 May 2004 23:33:56 -0400

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Eiffel Wu
	Sent: Friday, May 21, 2004 9:55 AM
	To: [email-masked]
	Cc: [email-masked]
	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.

---

From: "Eiffel Wu" <[email-masked]>
Date: Sat, 22 May 2004 16:39:53 +0800

>From an analysis of the drafts, it appears that silkroad is closer to
>tunnel brokers than to Teredo. Silkroad relies on the deployment of a
>large number of relays and servers, that become part of the ISP
>infrastructure: this is very similar to the deployment of tunnel servers
>by the ISP. It provides pretty much the same advantages as tunnel
>brokers, i.e. stable addresses and robust tunneling across different
>types of infrastructure.
>
>The part of Silkroad that somewhat resemble Teredo is the routing
>optimization between the tunnel servers (called SAR in silkroad). I
>don't think that this is particularly valuable: once you have reached an
>ISP router, you would expect normal routing protocols to take over and
>route packets along the optimal path. In fact, this feature will be
>perceived as detrimental by many ISP, since it makes their network
>management more complex than necessary. 

Thanks for your advice, we will take it into account.
I think it's not contradiction between Teredo and Silkroad. They can be complemented with each other.

Eiffel Wu

---

From: "Eiffel Wu" <[email-masked]>
Date: Tue, 25 May 2004 09:49:51 +0800

>The whole lifetime discussion is confused. All prefixes will have a
>lifetime, it may be very long, but it will be there. Any discussion about
>'permanent' only invites people to believe the prefix will move with them
>when they leave Slikroad behind, but that can't happen if the prefix is part
>of the SAR aggregate. 

"permanent" means that the SC can get the same IPv6 address as one used in last time.
Address of SC will not change, except the users want to a random address because
of security issue. 
As a comparison, Teredo address consists of clinet ipv4 address and udp port, which
must be different with last one. How can Teredo Client be found if there is no 
appropriate naming service ? Teredo does not provide such a naming service.

>In short Silkroad is nothing more than trying to provide a scaling front end
>for the forwarding function of the tunnel broker model. While that function
>is an admirable goal, this spec will need major rework before it even comes
>close to something that is operationally deployable. A reasonable trust
>model and fully dynamic routing update system are the first steps. In any
>case Silkroad should not be compared to Teredo because it is fundamentally a
>tunnel broker (albeit a broken one in the current spec) so section 7.4
>should simply be removed. 

I have told that Silkroad is a tunnel broker similar mechanism. It has the same goal 
but different way as Teredo has. I don't understand why a tunnel broker similar 
mechanism should not be compared to Teredo.

Eiffel Wu

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 25 May 2004 09:30:50 -0700

> What choices does Teredo advise, dynamic DNS or SIP, or some others ?

I don't think IP level technologies should make any recommendation about
specific name services. The choice of the name service is independent of
the transport in use. The only requirement is that the update rate of
the name service be compatible with the lifetime of the address. 

-- Christian Huitema