RE: Teredo vs Silkroad

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

lidefeng wrote:
> ...
> 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.

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. 

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

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. 

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

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. 

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

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.

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

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. 

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

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