[v6tc] Re: Tunneling and Transition Drafts

[JORDI PALET MARTINEZ <[e-mail]>]

Hi Fred, all,

First of all, I think is a very good question to know if the v6tc is really
dead, or what, unless I've missed something, there was not any message about
this. I was about to ask soon in v6tc list (copied now).

Then regarding the rest of your email, without entering into many details at
this point, basically agree with your view.

When I started looking into the tunneling/transition work (with several
documents such as TED auto-discovery and solution, auto-transition,
zero-tunneling-configuration, etc.), my main goal was precisely to be able
to pick up those gazillion existing mechanism and:

1) Try to automate the mechanism selection and configuration process as much
as possible (and probably this doesn't need a new protocol but some
guidelines about how to use existing things to do it). The idea is that this
could be done even w/o modifying the existing mechanisms. I think the work
here is almost done (but has not received for some of the documents, almost
any feedback from the WG, specially for proposed solutions).

2) Define a new mechanism, which actually takes advantage of existing ones
and a lot of deployment experience (including IPv6-dominant environments,
which I'm already deploying for some customers, so there is a real need
here). Clearly the deployment experience that we have now is not all what we
need, but is much more than what we had when we started working in the
existing mechanism (at least some of them). The point is probably to
consider two basic environments narrow-band and broad-band networks (for
example 3GPP or ISDN and xDSL/WLAN), but have a single mechanism, a kind of
one-fits-all (or very close to that), which can self-adapt, starting from
the "worst" situation (so it fits for 3GPP folks, with limited features, but
no new network requirements/devices), but can improve the features offered
in case there is a better link (example WLAN). For example I see the point
of a cellular phone with 3GPP and WLAN, moving from one network to another.
Why we need to have different mechanisms in that device, if instead we can
have one which can "self-adapt" (even using different encapsulation if
required, automatically).

For 2) We have a draft document (even a set of slides) which depict our idea
on this (our team worked the last 3-4 months on this already, in addition to
all the work done in 1) and v6tc documents). If this sounds a good idea, we
will be able to have an initial i-d probably in 10-15 days (may be earlier,
but need to recheck some other priorities).

The important thing that we have kept in mind always while working on 2) has
been also to avoid designing something completely new, but instead, looking
into all the existing mechanism to see which one seems to fit better and
modify it a bit to match the "one-fits-all". So, insisting a bit, the point
was here not to "mine is better" but "take the best and try to put it
together".

Our view not necessarily is perfect, of course, but we don't want to be 100%
as good as native IPv6, and of course, if we start working on this in the
WG, we really need a lot of input to be able to reach a consensus.

Obviously choice 1) somehow exist in some OSs, but could be improved and
will also support choice 2). We also need to understand that existing
implementations may decide not to go quickly or 2), so some parallel work
here is good and required.

So answering your final question, I will opt for the consensus, and actually
will like to continue our work on this (in the WG if possible), and I think
it can be done in a short time if the WG contributes a bit (just a bit more
than now !).

Despite that, I would not exclude that some of the mechanisms want to follow
their actual process and go for informational, in a parallel. At the end,
depending on timing, results of 2), market will take the decision, but at
least we will be able in the position, as IETF, to provide a good solution.

Regards,
Jordi




> De: Fred Baker <[e-mail]>
> Responder a: <[e-mail]>
> Fecha: Tue, 5 Apr 2005 16:34:52 -0700
> Para: "[e-mail]" <[e-mail]>
> CC: Lindqvist Erik Kurt <[e-mail]>, David Kessens
> <[e-mail]>
> Asunto: Tunneling and Transition Drafts
> 
> I need a consensus of the WG.
> 
> In what I am about to say, someone might possibly feel their toes
> stepped on. Apologies in advance - and get used to it. I have big feet,
> and I often put them in my mouth.
> 
> In taking over the working group, Kurt and I basically were presented
> with the following scenario:
>   - this group is for operational questions (not protocols)
>   - this group seeks to conform to RFC 1958 (we are not here to bless
> very lame solution that comes along)
>   - transition mechanisms are generally out of scope.
> 
> 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).
> 
> That said, there are roughly 80 gazillion different transition
> solutions out there, including at least silkroad, teredo, DSTM, secure
> tunnels, etc. To deploy IPv6 in a network that is in parts IPv4-only,
> in parts IPv6-only, in parts dual, and in parts what Jim Bound calls
> "IPv6-dominant" (which is not a bad term, btw), which I think I would
> say is ipv6-only in its service but might use IPv4 internally, it seems
> to me that one needs six things said or defined:
> 
>   - "please turn IPv6 on by default in your end systems"
> 
>   - "please turn IPv6 on in your enterprise network"
> 
>   - "please turn IPv6 on in your access/ISP network"
> 
>   - 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.
> 
>   - how to tunnel IPv4 through an IPv6-only/dominant network between
>     IPv4-only/dominant hosts or networks
> 
>     key attribute: static or dynamic IPv4/IPv6 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 IPv4 address but delivering an IPv6 "AAAA" record. Could
>     also be done through simple routing if the tunnels sty up or use
>     a concept like RFC 1793.
> 
>   - 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.
> 
> Note that I didn't say what kind of tunnel. GRE, MPLS, IP/IP, IPSEC,
> L2TP, who knows what else - they all must be addressed.
> 
> I have a fairly large number of ways to do those - silkroad, teredo,
> dstm, and a list of others. Each one, when it looks at the others, says
> "but mine is better" or "my customers want to deploy mine now".
> 
> I have no idea how this transition is going to happen if we can't sound
> a clear signal on how to do it.
> 
> 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 *I*will*support*that*in*favor*of*all*others".
> 
> Opinions?
> 




************************************
Barcelona 2005 Global IPv6 Summit
Registration open. Information available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.




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