RE: Teredo vs Silkroad

["Tony Hain" <alh-ietf@tndh.net>]

Liu Min wrote:
> 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 is a tunnel broker, though it tries to optimize the path. The
earlier messages on the thread made the case that Silkroad handles symmetric
nat, so it is better than Teredo. In the claimed high value case of
symmetric nat, there appears to be no architectural difference between
Silkroad and any other generic tunnel broker. When it is not possible to
optimize the path, and a stable prefix forces all packets for a given node
have to flow through a specific tunnel endpoint, it is a tunnel broker. 

Please provide a clear problem statement, with an explanation of what is
different between Silkroad and a generic tunnel broker. You are focused on
nat traversal, and seem to be ignoring the point that tunnel brokers also
solve that problem. In other words, nat traversal is not a problem that
needs solving, so Silkroad brings nothing to the table if that is all it is
intended to do. 

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

That assumes there is only one nat in the path and it is close to the SC.
When routing changes upstream, the new path may include a different type of
nat which invalidates the earlier decision (consider a nat connection to a
network that uses address space from a primary provider, then uses a nat
connection to a backup provider, which nat was the decision based on? How do
you know? Was the backup path in use when the SC started? What if adjacent
SCs start under different routing and make different decisions?). Your
perspective also seems to ignore the fact that there are two ends to every
conversation, and the decision at one end will not automatically be valid
for all other potential endpoints. 

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

Like I said, there is no point in the optimization since it will take longer
to set up than the vast majority of transfers. Since the only real value
Silkroad provides over every other tunnel broker is this path optimization,
it needs to do that efficiently enough to make a difference. 

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

A major problem with the Silkroad draft is that basic required steps are
very unclear due to the array of optional ideas. In the email thread, the
claimed problem is nat traversal, but that is not a problem that needs
solving in yet another different way from the existing mechanisms. As far as
I can tell, what Silkroad does provide is the prefix stability of a tunnel
broker, coupled with the route optimization characteristic of Teredo. As a
concept that appears to have value. The actual mechanics described in the
draft completely ignore the operational realities of routing changes, and
the need for path determination on every connection due to untested
topology. The Internet is not a contained, strictly hierarchical, low
latency lab scale network, so deployable mechanisms are required to deal
with the messy details of continually shifting topology, planned & unplanned
outages of single nodes, abuse tracking and mitigation, and such
non-technical details as irrational business necessities. While the idea of
route optimized tunnel brokers has merit, the current Silkroad draft appears
to be lacking in all those areas. For the Silkroad draft to make progress,
it needs to clearly state its goal and differences from existing
technologies, sort all the mandatory basics up front, then get realistic
about continuous change and scale.

Tony


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