Subject: RE: Teredo vs Silkroad

From: "Liu Min" <[email-masked]>
Date: Wed, 26 May 2004 23:43:09 +0800

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:[email-masked]]
> Sent: Wednesday, May 26, 2004 3:53 AM
> To: 'Liu Min'; 'Christian Huitema'; 'Eiffel Wu'; [email-masked]
> Cc: [email-masked]
> 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: [email-masked] [mailto:[email-masked]] 
> > > On Behalf Of Tony Hain
> > > Sent: Tuesday, May 25, 2004 2:30 AM
> > > To: 'Liu Min'; 'Christian Huitema'; 'Eiffel Wu'; [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: Teredo vs Silkroad

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 May 2004 10:44:08 -0700

Liu Min wrote:
> 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
> 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

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. 

> 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

---

From: "Liu Min" <[email-masked]>
Date: Thu, 27 May 2004 15:37:31 +0800

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Tony Hain
> Sent: Thursday, May 27, 2004 1:44 AM
> > 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
> > 2. Silkroad and Teredo are two solutions to the same problem: 
> > tunneling IPv6 packets through NAT devices.
> 
> 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.

> > of the SN. And Teredo also needs some configuration at setup. 
> > "Before using the Teredo service, the client must be configured 
> > with:
> > 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.
> 

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

---

From: lidefeng <[email-masked]>
Date: Fri, 28 May 2004 10:28:43 +0800

Please read in lines.

----- Original Message ----- 
From: "Tony Hain" <[email-masked]>
To: "'Liu Min'" <[email-masked]>; "'Christian Huitema'"
<[email-masked]>; "'Eiffel Wu'" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 27, 2004 1:44 AM
Subject: RE: Teredo vs Silkroad

> > I omit the previous letters since it has been a chaos of multiple
re-mail.
> > 1. Although silkroad is similar as tunnel broker based solution, it is
not
> > a

> "Tony wrote:"
symmetric
> needs solving, so Silkroad brings nothing to the table if that is all it
is

Defeng Li:
I think what we concern is not whether Silkroad is tunnel broker or not,but
how to resolve the problem met in the IPv4-IPv6 transition,even Silkroad
have some similarity with tunnel broker, it doesn't mean that tunnel broker
can resolve the problem which is addressed by Silkroad,in fact, RFC
3053(IPv6 Tunnel Broker, which should be Tunnel Broker Mechanism you always
mentioned in your mails) explicitly stated in section "3. Known limitations"
that "This mechanism may not work if the user is using private IPv4
addresses behind a NAT box." And Silkroad can resolve the Nat traversal
problem very well, I think "the problem statement and the difference between
silkroad and a generic tunnel broker" is very very clear.

Another point you missed very far is that you insist that "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",maybe it is right only in the scope of
United States,where the IPv4 addresses are abundant, however in Asia IPv4
addresses is so scarce that almost every ISP access their customers with
private IPv4 addresses.

> "Tony wrote:"

Defeng Li:
Though there is only one NAT is displayed in the figures of the Silkroad
document, is doesn't mean that silkroad only assume there is only one NAT in
the path,as long as the NAT can transfer the different IPv4 addresses
correctly, several NAT can be deployed in the path,in this case, the IPv6
packet are encapsulated in UDP payload.

When routing changes upstream during the session, and the new path may
include a different type of NAT,then Silkroad can setup another UDP tunnel
which cater for this different type of NAT and delete the old UDP tunnel and
the relevant information will be updated in SC and SAR and the IPv6 domain
where B belongs,then following IPv6 packets of the session will tunneled in
the new UDP tunnel, it is the same as when one route for a destination is
failure, then another route is selected to forward the packets. Though the
convergence of such information is needed,it isn't be problem can't be
resolved, and some of the updation will be done by routing protocols of
IPv4/IPv6 domains,Silkroad just need to setup the new tunnel and delete the
old tunnel according the updated information.

> "Tony wrote:"
longer
> it needs to do that efficiently enough to make a difference.

Defeng Li:
As stated in the above text,Silkroad not only optimizes the path, but goes
beyond the limitation of tunnel broker. It makes differences.

> "Tony wrote:"
> solving in yet another different way from the existing mechanisms.

Defeng Li:
Though there is another existing mechanism (Teredo) to resolve the NAT
traversal problem,if this mechanism is difficult to deploy and will make the
network more complex, why shouldn't we solve it in another simple
way,moreover,who said Teredo mechanism is widely accepted? I think it will
be better not to make the dicision so hasty.I hope those service providers
deployed NAT widely in their network can help to input some information.

>"Tony wrote:"
> As far as I can tell, what Silkroad does provide is the prefix stability
of a tunnel
> about continuous change and scale.

Defeng Li:
I think the route optimization can be done by route protocols, route
protocol should solve the problem of multi-homing and the route change or
updation,the Silkroad just utilize the optimized route information to
maintain(setup or delete) the Silkroad tunnel,fo course Silkroad should
cooperate with the route optimization to solve the NAT traversal problem
better, but it make no sense to enable Silkroad to do all the work.

Defeng Li

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 28 May 2004 12:16:32 -0700

lidefeng wrote:
> ...

There are several proposed tunnel broker mechanisms. RFC 3053 only outlines
the broad class of solution, so it should not be taken as the mechanism I
referenced in earlier mail. The nat issue in known limitations is there to
point out that specific tunnel brokers that expect the client to provide an
address in the protocol will fail when the client is behind a nat. If
instead the implementation pulls the address from the IPv4 header it will
work through a nat. 

To be very clear, Silkroad is a tunnel broker primarily because a 'broker'
is required to acquire an IPv6 prefix, and there is a fixed mapping to the
endpoint of the non-optimized tunnel. That is the fundamental characteristic
of Silkroad. What sets it apart from other tunnel brokers is the innovative
approach to tunnel optimization. The fact that this optimization is targeted
to work in nat environments is an additional enhancement. 

> addresses is so scarce that almost every ISP access their customers with

That was a poor choice of words which assumed a significant amount of
context. Yes, mechanisms need to work in nat rich environments. The point I
was trying to make was that other proposals work through nat, so if that is
the only thing Silkroad does, it brings nothing NEW to the table. That said,
Silkroad does bring the route optimization characteristics of Teredo to the
tunnel broker environment, so it does add value, just not in the area you
appear to be focused on. 

To be clear, while the U.S. has a large number of IPv4 addresses, there is
an even greater abundance of nat. Even in the U.S. I spend more time
connected through nat than otherwise. I submitted RFC 2993 while my home
network was connected through 2 different nat implementations (now down to
1). My machines on the corporate network are in 10.x space. Every airport
lounge, coffee shop, and hotel I get network access through have deployed
nat. I also maintain some distribution statistics at:
www.nav6tf.org/RIR_eNations/e-Nations-data.pdf
so I am acutely aware of both the lack of address space and the abundance of
nat around the world. 

> > > ...
> > ...

Your statements contradict each other. The process will only work once, or
it will have to run continually because the SC has no real-time feedback
about routing changes upstream. This is where the optimization brings
considerably more complexity to the picture than a simple tunnel broker. The
simple tunnel broker model has only one point where the association between
IPv4 & IPv6 headers needs to be maintained. Therefore it has a relatively
easy job of authenticating any updates to that which result from routing
changes (a periodic authentication would both keep the nat open and provide
updated IPv4 address information due to nat path changes). Silkroad on the
other hand has to figure out how to do a distributed trust model so that new
tunnel mappings can happen for all the route optimized endpoints. To really
be successful this tunnel mapping update will have to happen for all the
active tunnels within the timeout of any TCP connections to keep the
applications on the SC nodes unaware of the change. 

> ...

You are reading too much into the RFC. See these drafts for more:
www.ietf.org/internet-drafts/draft-massar-v6ops-heartbeat-00.txt
www.ietf.org/internet-drafts/draft-blanchet-v6ops-tunnelbroker-tsp-00.txt
www.ietf.org/internet-drafts/draft-palet-v6ops-tun-auto-disc-00.txt
www.ietf.org/internet-drafts/draft-massar-v6ops-ayiya-00.txt
There are undoubtedly others I missed, as well as implementations of drafts
which may have expired. The point is you need to take the informational RFC
in context as just that, information. It does not specify an implementation,
therefore you can't assume Silkroad is providing something new.

NOTE TO AD & CHAIR: this confusion is yet another example of why we need to
get the mechanism documents out the door.

> ...

If you are going to figure out how to make Silkroad work correctly you need
to stop comparing Silkroad to Teredo. Silkroad provides a managed IPv6
prefix via a broker, while Teredo provides an automated IPv6 prefix as a
derivative of the IPv4 address. The issue of working through nat is a design
goal of each, but Teredo is primarily a way to make 6to4 style automation
work through nat, while Silkroad is one way to make a managed tunnel broker
work through nat. If you focus on the nat part you will miss the broader
context and never get the mechanics right to make the approach work at
scale. 

Market acceptance is not something I am worried about in an IETF context.
There are many different problems to be solved in the deployment space, and
it is clear to everyone (except the past and current IESG) that we need more
than one tool to solve the individual cases. We don't need a vast array of
niche specific tools, but one hammer will not work either. If Silkroad
provides value to those who are looking for managed prefixes, it will be for
its route optimization. By design it will never solve the automated prefix
case that Teredo is dealing with, so it is best to stop worrying about
Teredo and stop making comparisons. Due to their different target clients,
they are complementary rather than competing technologies. 

> better, but it make no sense to enable Silkroad to do all the work.

We have an overload of 'routing' by mixing IPv4 & IPv6. I was not expecting
Silkroad to be aware of the underlying IPv4 routing, but to build the direct
path tunnels, Silkroad clients will explicitly need IPv6 routing
information. They will need at least enough to know which IPv6 prefixes are
on the IPv4-logical-link vs. connected behind their designated access
router. The process for updating this client side routing cache needs to be
very dynamic, and at the same time secured against intentional pollution
from malicious clients. This is not 'making Silkroad do all the work', but
making Silkroad do the work that is necessary to achieve its design goals.
While having the SC poll the SAR may be the most effective ND-proxy, the
whole 'poll the SN' concept is not scalable, so effectively Silkroad needs
to run a routing protocol between all the SARs so they can have a real-time
perspective on which IPv6 prefixes are accessed through which neighbors on
the IPv4-logical-link. IGPs are not designed to run on the global scale of
the Internet, and they are not designed to run between a massive number of
independent trust boundaries. This effectively leads to BGP with a massive
number of peers on the IPv4-logical-link. Since we know N^2 trust even
between the SARs will never happen, the SN will need to take on the role of
the trusted route reflector, where the independently operated SNs can have a
more manageable trust infrastructure. 

In short, step back from the current draft and rethink the overall problem
statement. While nat traversal is a necessity, it is not the fundamental
characteristic here. Silkroad is providing managed IPv6 prefixes with path
optimized routing directly between clients. As a secondary issue it also
includes appropriate hooks to allow those clients to be connected via nat.
Once the concept is reframed in that context, the next step will be to
revisit all the operating environment assumptions and make sure they take
into account the scale, trust relationships, and continual change that are
the reality of the global Internet.

Tony