RE: Teredo vs Silkroad

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

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On 
> Behalf Of Tony Hain
> Sent: Thursday, May 27, 2004 1:44 AM
> To: 'Liu Min'; 'Christian Huitema'; 'Eiffel Wu'; pekkas@netcore.fi
> Cc: v6ops@ops.ietf.org
> Subject: RE: Teredo vs Silkroad
> 
> 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.

From earlier discussion in this mailing list about whether to go forward
with Teredo, many people think that NAT traversal in IPv6 transition is a
very important issue and should be solved. I don't think if silkroad tries
to solve this problem, it will bring nothing to the table.

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

No, I never assume there is only one NAT in the path.

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

If the SC is behind a Full cone NAT, it could finish route optimization
immediately. For other NAT types, there should be more actions to setup the
corresponding mapping in the NAT. For the same reason, Teredo needs to send
bubbles when the NAT type is not Full cone NAT. It comes from the inherent
characteristics of these NAT types.

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

Ok, we will explicitly indicate the mandatory basics for Silkroad and
improve the security consideration in the next version.

Liu Min