Re: Teredo vs Silkroad

[lidefeng <77cronux.leed0621@huawei.com>]

Please read in lines.

----- Original Message ----- 
From: "Tony Hain" <alh-ietf@tndh.net>
To: "'Liu Min'" <liumin@ict.ac.cn>; "'Christian Huitema'"
<huitema@windows.microsoft.com>; "'Eiffel Wu'" <xgwu@ict.ac.cn>;
<pekkas@netcore.fi>
Cc: <v6ops@ops.ietf.org>
Sent: Thursday, May 27, 2004 1:44 AM
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.

> "Tony wrote:"
> 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.


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.


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

> "Tony wrote:"
> 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.

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.

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

> "Tony wrote:"
> 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.

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.


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

> "Tony wrote:"
> 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.

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

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



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