RE: Teredo vs Silkroad

["Liu Min" <liumin@ict.ac.cn>]

I omit the previous letters since it has been a chaos of multiple re-mail.
My answers are as following:

1. Although silkroad is similar as tunnel broker based solution, it is not a
tunnel broker. Tunnel broker is not presented to solve NAT transversal but
to provide one easy way to configure and maintain many different tunnels.
Tunnel broker focuses on the lifecycle management of tunnels, not the tunnel
technologies. From this point, silkroad can also be managed by tunnel
broker. If you really want to compare it to tunnel broker, the SAR will play
the role of both TB and TS in tunnel broker. SN can help SARs route between
each other, which is a novel entity in tunnel broker scheme.

2. Silkroad and Teredo are two solutions to the same problem: tunneling IPv6
packets through NAT devices. Silkroad assumes the SC know the IPv4 address
of the SN. And Teredo also needs some configuration at setup. "Before using
the Teredo service, the client must be configured with:   
   -	the IPv4 address of a server.
      If secure discovery is required, the client must also be configured
   with:
   - a client identifier,
   - a secret value, shared with the server."

3. In your letter you said "Yes the mechanism will find the least common
capabilities, but what was the point? The result is limited to a very
specific address (and possibly port) over a short period of time. Every
transfer will required a different decision, so the SC is very likely to
spend more time trying to figure out the optimization than actually
transferring data. The whole mechanism will be simpler if you just assume
that the SA will be in the path, because it will be more often than not."

I think you misunderstand my point. Not every transfer will required a
different decision. No matter how many NATs there are, you need not judge
each NAT's type. 
The NAT type determining process will only work once. Then you will know
could you receive a packet from an arbitrary address or only an address to
which you have sent a packet, or something like this. In our draft, the
process is a reference to STUN. In Teredo, the process is similar. In
addition, SC only needs to determine the NAT type when it starts silkroad
service for the first time. Anyway, the route optimization is optional. It
is recommended for cone NAT users to do optimization. Other NAT users are
recommended to choose to do route optimization only if they want to transmit
large bulk traffic. 

4. Silkroad Router Advertisement is a private packet format defined in
silkroad for SN to indicate the IPv4 address of SAR to SC. It is not the
IPv6 RA in RFC2461. So it is not using IPv6 function to provide IPv4
information. If it causes some confusion, I will change the packet name in
the next version. In fact, the interaction between the SC and the SN could
go on different means, such as http. Silkroad Router Advertisement is just
one alternative way, which is not a necessary part in silkroad.

5. There are many works ongoing for silkroad. We will refine our
draft/prototype in the following versions and you and anyone else are
welcome to give any comments and suggestions.

Liu Min

> -----Original Message-----
> From: Tony Hain [mailto:alh-ietf@tndh.net]
> Sent: Wednesday, May 26, 2004 3:53 AM
> To: 'Liu Min'; 'Christian Huitema'; 'Eiffel Wu'; pekkas@netcore.fi
> Cc: v6ops@ops.ietf.org
> Subject: RE: Teredo vs Silkroad
> 
> Liu Min wrote:
> > Thank you for your comments. You have mentioned some problems which 
> > are common to NAT transversal mechanism, such as the security and 
> > multiple NATs in a path. I will try to answer the questions in-line. 
> > Any suggestions will
> > be appreciated.
> >
> > > -----Original Message-----
> > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] 
> > > On Behalf Of Tony Hain
> > > Sent: Tuesday, May 25, 2004 2:30 AM
> > > To: 'Liu Min'; 'Christian Huitema'; 'Eiffel Wu'; pekkas@netcore.fi
> > > Cc: v6ops@ops.ietf.org
> > > Subject: RE: Teredo vs Silkroad