Subject: Teredo vs Silkroad

From: rengrong wang <[email-masked]>
Date: Fri, 21 May 2004 14:31:43 +0800

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?

Best regards,

Crisy(Rengrong) Wang
=======================================
USC,EE-Systems

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 21 May 2004 09:37:59 +0200

> It is known that Teredo is a automatic tunnel mechanism that figures out the same problem.

At first I thought that you where mixing up shipworm and Teredo, which
are the same but have been renamed due to the fact that 'shipworm' is
more easily related to something viral than something good, which Teredo
is ;)

They are quite different though and though it looks the same it is
something different, it seems to be more of an addon seems to me.
At a first glance mind you, it seems IMHO to be overly complex too.

> What's the difference between Silkroad and Teredo?

I suggest you read section 7.4 of the draft as it is stated there
completely. Main issue is address stability apparently:

Something peculiar, quote:
8<-----------
    In fact, although Teredo can minimize the fraction of
   traffic routing through the servers, it need Teredo relays in every
   IPv6 network to receive traffic destined to Teredo clients and 
   forward it using the Teredo service, which needs to update the 
   existing infrastructure.
------------>8

The Teredo prefix that is used is globally announced using normal IPv6
routing tables, thus as long as there is some kind of transit service
this is no issue.

PS: note for the authors, the draft uses non RFC3330 /
draft-huston-ipv6-documentation-prefix addressing.
It is a should on the id-checklist but still.

Greets,
 Jeroen

---

From: lidefeng <[email-masked]>
Date: Fri, 21 May 2004 16:57:36 +0800

Silkroad can configure the Silkroad Clients with structured consecutive
global IPv6 addresses, without any special prefix like Teredo, this feature
will do good to the IPv6 routes aggregation in the network, which will
condense the amount of IPv6 routes entries.

Besides, Silkroad is more compatible with the current network and the
requirements of NAT customers, it is much easier to deploy in the network.

To deploy Teredo, Teredo Server should be added to help setup the connection
with Teredo Client, and Teredo Relay function is needed at the routers
access to IPv6 sites, and Teredo Relay Teredo Server should both traverse
NAT, all these demands requires the updation to the router access to IPv6
sites. and the number of such routers will be very large, so the updation
work is somewhat painful for the customers.

While Silkroad can be compatible with the current network, the routers
needn't be updated, even the Silkroad Navigator is not needed in the simple
netowrk,and the SAR(Silkroad Access Server) can be deployed at any place in
the network.

----- Original Message ----- 
From: "rengrong wang" <[email-masked]>
To: <[email-masked]>
Sent: Friday, May 21, 2004 2:31 PM
Subject: Teredo vs Silkroad

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

---

From: JF Tremblay <[email-masked]>
Date: Fri, 21 May 2004 12:03:59 -0400

--On May 21, 2004 2:31 PM +0800 rengrong wang <[email-masked]> wrote:

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

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.

> Crisy(Rengrong) Wang

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: Jeroen Massar <[email-masked]>
Date: Fri, 21 May 2004 18:53:06 +0200

On Fri, 2004-05-21 at 18:03, JF Tremblay wrote:
<SNIP>

> require the use of a web page, offers prefix delegation, authentication and 

TSP as in "Tunnel Setup Protocol", isn't that only the control part
which communicates what the parameters of the tunnel are?
The current draft, as far as I have read it does not specify any
protocol for trafficing data/IPv6 payload.

> has a solid experimental background since it's been deployed for
> over 5 years to more than 100000 users.

Any traffic/usage statistics of this 100k users as it would be very
interresting to know for what such a big amount of users are using IPv6.
Also are these seperate users, individual signups, tunnels, returning
users?

Greets,
 Jeroen

---

From: "liumin" <[email-masked]>
Date: Sat, 22 May 2004 01:12:01 +0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of JF Tremblay
> Sent: Saturday, May 22, 2004 12:04 AM
> To: rengrong wang; [email-masked]
> Subject: Re: Teredo vs Silkroad
> 

I don't think so. TSP is a tunnel broker solution, which is not
presented to solve NAT transversal but to provide one easy way to
configure and maintain many different tunnels. From this point, TSP has
relation to all existing tunnel technologies. But it is a "pure
procedure" management technology for tunnels. It is totally different
from tunnel technologies which focus on methodology for tunnels.  

Silkroad is not an implementation of tunnel broker like TSP.

> years to more than 100000 users.

Web pages is just one way for Silkroad client to learn its SAR, there
are many other ways to reach this point, including XML presentation.

---

From: "liumin" <[email-masked]>
Date: Sat, 22 May 2004 01:12:01 +0800

Behalf

---

From: "liumin" <[email-masked]>
Date: Sat, 22 May 2004 01:12:01 +0800

Behalf

---

From: "liumin" <[email-masked]>
Date: Sat, 22 May 2004 01:12:01 +0800

Behalf

---

From: "liumin" <[email-masked]>
Date: Sat, 22 May 2004 01:12:01 +0800

Behalf

---

From: "liumin" <[email-masked]>
Date: Sat, 22 May 2004 01:12:01 +0800

Behalf

---

From: "liumin" <[email-masked]>
Date: Sat, 22 May 2004 01:12:01 +0800

Behalf

---

From: "liumin" <[email-masked]>
Date: Sat, 22 May 2004 01:12:01 +0800

Behalf

---

From: "liumin" <[email-masked]>
Date: Sat, 22 May 2004 01:12:01 +0800

Behalf