[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.