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

Re: Tunneling and Transition Drafts

On Tue, 5 Apr 2005, Fred Baker wrote:
As I understand it, v6tc (which was intended to take over all the tunneling stuff, which is to say a large proposition of the transition stuff) is dead in the water. The expectation was that all the tunneling/transition stuff would move there, but the BOF was a non-event. There isn't likely to be a v6tc WG. (Dear AD: if you disagree, this would be a good time to say so).

No, "[v6tc] intended to take over all the tunneling stuff" was *never* the goal of v6tc.

Many months ago (maybe it's at about a year now), when we first discussed how to move around with all the work that keeps coming to v6ops, one of the first proposals was to create "v6tuns" working group, working on the tunneling mechanisms.

The idea was rejected in the relatively short order, and has not been seen since. We don't need another ngtrans, specifying all the transition mechanisms people come up with.

(However, one, slightly better idea was to create a maintenance WG to move 6to4 to Draft Standard, figure out what to do with so-called 6over4, move rfc2893(bis) to DS, etc. -- but there would undoubtedly be a big slippery slope there, and it may be a bit too early for this activity.)

- how to tunnel IPv6 through an IPv4-only/dominant network between
  IPv6-only/dominant hosts or networks

  key attribute: static or dynamic IPv6/IPv4 tunnels between tunnel
  endpoints, and appropriate routing through the IPv4 domain to
  determine what the appropriate tunnel endpoint router would be.
  Could be done with a DNS name not unlike a reverse lookup for
  the IPv6 address but delivering an IPv4 "A" record. Could also
  be done through simple routing if the tunnels sty up or use a
  concept like RFC 1793.

The DNS lookup (after you know what you're looking for -- including "discovery" part is trickier) is not a hard problem. The real problem, which v6tc set out primarily to solve was how to set up the tunnel at both endpoints without requiring manual configuration (especially the endpoint addresses) at both ends -- and running a routing protocol between the two is a non-starter.

- how to translate IPv6->IPv4 and IPv6-IPv4 between an IPv6-only/dominant
  and an IPv4-only/dominant domain

  key attribute: translation system captures DNS lookups and
  re-advertises its own address in some way, so that IPv4 hosts
  seeking IPv6 peers connect to it and it translates, and IPv6
  hosts connect to it and it translates.

This must be badly worded because that you're saying is basically NAT-PT with DNS-ALG, which is exactly what we just decided was a bit.. um.. problematic, and requested reclassification as Experimental.

Which brings me to my question. I am being asked by various proponents of various things what the working group wants to do with their approach. I need to know what the game plan for this working group is: let a thousand flowers bloom (they can all ask for informational status from the RFC Editor and the probability that the transition will happen in an orderly fashion rapidly approaches zero), or I need a consensus statement from the working group that every single approach on the table will be set aside and the working group will actively work on providing a single solution that meets all those needs that the IETF can look at and say "yes, that will accomplish an orderly transition in a timely fashion and 

If I read this correctly, you see two options:

 1) let the authors publish their stuff as RFC-ed informational, if
    they want to, or
 2) produce a Grand Unified Mechanism somewhere (here or some other
    WG) which solves all the needs (and hopefully world hunger
    besides).  [This is a bit challenging as those needs include
    tunneling in every possible way, translation, etc.]

These are a bit polarized.  What I think we should do is:

- obviously, allow 1) if that's what people want
- not use the v6ops meeting time etc. on these proposals; short pointers on the list may be OK, but lengthy discussions should be elsewhere (discretion of the chairs to rule out stuff as out of scope, as always)
- if a mechanism comes along that a lot of people actually want to work on, ask that they create a BOF, and then see if it gains sufficient momentum or not.
- or the authors can obviously try to reach ADs and ask sponsoring the work; or use appropriate other WGs if the work is in scope there (e.g., 6PE (bgp tunneling) work has moved over to IDR wg)

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