Re: [v6tc] Re: Tunneling and Transition Drafts

On Apr 12, 2005, at 10:30 PM, Tim Chown wrote:
> (Hinden) Have a zillion tunnel protocols and I don't see advantage of 
> new generic one.  I vote for limited scope.   Concerned that we are 
> reinventing deployed solutions? (broker?)
> (Durand) (hat off) Schizophrenia or IETF - requirements analysis vs 
> desire to be generic... ball going back and forth.   Chances of 
> success higher if we stay focused on IPv6.

<head uncovered>

My sense is that this sort of hits the point, but in fact misses it 
pretty widely.

The issues with IPv4/IPv6 transition and coexistence boil down, I 
think, to the questions of rendezvous and how/when to use a tunnel vs a 
translation mechanism. The discussion of "do we need 
yet-another-GRE-format" is beside the point - we *don't* need another 
GRE, but we need to know how and when to use the one we have, and in 
that case which one to use, and when the only option is to translate 
(NAT-PT or whatever).

The key question is how one enables two systems to talk with each 
other. This is trivial if we have a parallel implementation - dual 
stacks in both hosts and the entire network. In that case, pick one and 
go with it, and those systems that have not yet turned on IPv6 use 
IPv4. That is already a pretty strong recommendation.

But it also misses something basic - the value that IPv6 brings to the 
party is mostly related to increasing the address pool. If that is not 
true, if we have enough IPv4 addresses that we can build parallel 
networks everywhere, then we don't need a new protocol in the first 
place. If it is true (and it is) then you have to assume that there 
will be edge networks and service networks that are IPv6-only or 
IPv6-dominant pretty early - pick your reason. Once you have an 
IPv6-only/dominant service network, you have the question of IPv4 hosts 
having to use it to communicate over it, IPv6-only/dominant hosts 
needing to communicate over IPv4-only/dominant networks, and IPv6-only 
hosts needing to communicate with IPv4-only hosts.

At that point we have to solve a rendezvous problem. When two of one 
kind of host need to communicate over a network of the other kind, we 
obviously want to tunnel. We can do this using static tunnels, but that 
is a lot of manual configuration. What we really want is some kind of 
auto-tunneling, which means some kind of automated tunnel-endpoint 
location. We could do it by routing, which some proposals suggest: 
inject one type of routes into the other type of network using an 
interesting addressing scheme and make it all automagic. We could do it 
by naming - have what amount do DNS translators and tunnel brokers that 
insert the local-form-addresses of gateways into networks, and as a 
result both communicate to systems of one type of the address of the 
translator/tunnel endpoint and communicate to systems of the other type 
who to route a tunnel to. There are probably other approaches. But if 
we do this in multiple ways, we create a new layer of problems - how 
does a Teredo gateway talk to a Silkroad gateway talk to a DSTM gateway 
talk to a ...? We really need, I think, to pick *one*. and make it work 
well for 90+% of the cases. Note I don't say "cover every case". I'd 
like to, but I also wonder at what point doing so slows down getting 
the protocol out or slows down the transition itself.

I'm perfectly happy to standardize on existing types of tunnels - 
IPsec, GRE, IPv4/IPv6, IPv4/IPv4, IPv6/IPv4, IPv6/IPv6, L2TP, or 
whatever. If we don't solve the rendezvous problem (and btw communicate 
to the peer what kind of tunnel a given gateway is willing to support) 
we have not *touched* the transition problem.

And what I would like to see happen is for someone, somewhere - and 
note that I am very willing to do this in v6ops if people want and also 
willing to send it to v6tc or wherever else - to solve that rendezvous 
problem. As a result, I would like to see the various competing 
transition strategies all rendered OBE and get everyone to converge on 
a single transition approach.

_______________________________________________
v6tc mailing list
v6tc@ietf.org
https://www1.ietf.org/mailman/listinfo/v6tc