[v6tc] Re: Tunneling and Transition Drafts (fwd)

[Pekka Savola <[e-mail]>]

FYI -- I didn't think this was relevant to v6tc (except about the 
clarification of the focus of v6tc) so I didn't add Cc:.

---------- Forwarded message ----------
Date: Wed, 6 Apr 2005 09:13:24 +0300 (EEST)
From: Pekka Savola <[e-mail]>
To: Fred Baker <[e-mail]>
Cc: [e-mail], Lindqvist Erik Kurt <[e-mail]>,
     David Kessens <[e-mail]>
Subject: 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

_______________________________________________
v6tc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/v6tc