Re: Opportunistic Tunneling

[Pekka Savola <pekkas@netcore.fi>]

Tailed down Cc: a bit.

On Tue, 24 Feb 2004, Erik Nordmark wrote:
> It seems odd to say that the criteria is "nodes that implement
> X can talk to other nodes which implement X without extra infrastructure"
> when extra infrastructure is needed for nodes that implement X 
> to be able to communicate with nodes that have native IPv6 service.
> That seems to forget that the goal is to move towards IPv6
> and not stay with X forever.

Yes, this seems odd, and is very unfortunate, causing a "transition
mechanism lock-in" of two sorts: requirement for implementing
everything, and requirement for keeping everything enabled for a long
time.  

However, unfortunately that seems to be the direction at least some of
the deployment is heading..

Do you see feasible-to-deploy methods which would allow basically
everyone to obtain IPv6 service independent of their ISP?  I'd
certainly want to see one -- as it appears, we only seem to have bad
choices. Because that seems to be the requirement (with the additional
argument, 1), below) causing the inevitability of the abovementioned
effect..

> TSP, teredo and 6to4 all need some infrastructure to be able
> communicate with nodes that do native IPv6.
> Why is it important to make any finer grain distinction?

Thanks for bringing this up.  I think there are basically two kinds of
assumptions which argue for the more fine-grained distinction.  Let's
try to see if there are others, or if people disagree about these.

 1) that the traffic between the users of the same mechanism (or
opportunistic mechanisms or dual-stack in general, with glue)  would
be such that tunnel-brokered model would not be sufficient when the
tunnel termination does not occur close to the sources.  That is, the
prime reasons here are probably:

    - using applications with heavy bandwidth requirements, causing
load to the tunnel servers, causing increased costs to the operators
of such servers, even making it unfeasible.  With high latency (see
below), it might also be impossible to even achieve sufficient
bandwidth without major rigging of TCP timers.

    - using applications with delay requirements, implying that a 
direct path between two nodes would be preferred.  This would rule out 
tunnel broker/server -like deployments if the deployment is not 
widespread enough.  Tunnel broker in the US would be unacceptable for 
European users, for example -- and a tunnel broker in the neighboring 
EU country might even be similarly unacceptable if you wanted to do 
VoIP with your neighbor.

    So, this assumption basically implies that if we can reduce the
amount of traffic that has to go through the infrastructure, either
bandwidth or latency-wise, it might be more feasible to deploy this
infrastructure. (One might be able to compare this to the SIP model
where the control traffic goes through some intermediaries, but media
goes through a more direct route.)

 2) 6to4 and Teredo (to a lesser degree AFAIK) are pretty anonymous
services.  When someone abuses using those addresses, there is no ISP
"hosting" the service which would get abuse etc. reports, get
blacklisted if someone behaves badly, etc. -- on the other hand, if
the ISP offers the service to outsiders using its RIR address space,
this will certainly lead to all kinds of nasty administrative
actions.. sooner or later raising the question, "why are we even
providing this kind of service to outsiders for free, if we get
nothing but trouble!?!"

Actually, as mentioned in the unmanaged connectivity requirements
drafts, if we assume that third parties would be giving away tunnel
service for free to anyone, a level of anonymity is desirable (e.g.,
in our network, we do run 6to4 relay, but we will never run a tunnel
broker (well, we could consider tunnel broker for our own customers,
but that's beside the point here)).

Obviously, this requirement is different if your own ISP is offering
this kind of service, or you're entering a contract with the ISP, but
the whole point of this "opportunistic" discussion was being able to
cope in the scenario when your ISP does NOT offer IPv6 services, and
you not being required to "fill any forms" to get IPv6 connectivity.

This is why the fundamental first question in considering the
"opportunistic" tunneling is whether you consider the deployment to be
"vendor-driven" or "user-driven".

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings