[v6ops] Fwd: Another look at 6to4 (and other IPv6 transition issues)

[Roger Jørgensen <[e-mail]>]

no point in removing v6ops@ for the to: list


---------- Forwarded message ----------
From: Roger Jørgensen <[e-mail]>
Date: Fri, Jul 15, 2011 at 7:25 PM
Subject: Re: Another look at 6to4 (and other IPv6 transition issues)
To: John C Klensin <[e-mail]>, Brian E Carpenter
<[e-mail]>
Cc: [e-mail]


+1 (as in G+) from me.

Get on with the work of rewriting/combining it into one document. It
is for me a much more sound strategy. I've read the -experimental
draft and I don't think it is the sort of document we should publish.

And with some hindsight, we should have combined -historic and
-advisory into one and not attempted to run them side-by-side through
the system :(


ps: thanks for, probably the first grown-up mail on this subject for
quite a while!


--- Roger J ---

On Fri, Jul 15, 2011 at 5:55 PM, John C Klensin <[e-mail]> wrote:
> Hi.
>
> I've been thinking about this and having a few off-list
> conversations and want to make a suggestion that draws together
> a few others.  Since many people don't like my long notes with
> the conclusion at the end, this one is suggestion-first.  If the
> suggestion offends you sufficiently, you can just stop reading
> there.
>
> Recommendation:
>
> (1) Abandon the effort to classify the specifications as
> Historic.  It is at best a symbolic act that few people outside
> the IETF community will even notice, much less act differently
> because we have done it.  Instead, let's try to focus on what is
> actually important, not classification and name-called ("curse
> you, you Historic protocol" :-(  ).
>
> (2) Pull the "-advice" document back from the RFC Editor queue
> and fold the actual substantive content of the "-historic"
> document into it, preferably as a very clear and very prominent
> Applicability Statement.  If this is what v6ops believes, the
> statement might reasonably say something like:
>
>        (2a) This protocol, if not used very carefully, leads to
>        bad operational situations in which things get lost and
>        the problems are hard to diagnose.   We strongly
>        recommend that it not ever be a default and that it not
>        be used except under special circumstances and with
>        great care.
>
>        (2b) Even then, we recommend that it not be used unless
>        all of those configuring routing information and all the
>        systems along the routing path are run by experts who
>        both understanding the issues and are willing to accept
>        responsibility.
>
>        (2c) If you do decide to use the thing, the "advice"
>        recommendations in the rest of this document are
>        mandatory and MUST be followed to avoid serious
>        operational problems.
>
> I haven't included either Randy's colorful language or mine in
> the example above, but the intent should be clear.  Depending on
> how much detail the community thinks is useful, there is a good
> deal of potentially-useful text in draft-moore-6to4-experimental
> as well as in the "-historic" draft.
>
> The resulting document should explicitly update RFC3056 and
> RFC3068.  Taking that action will send a much stronger "you need
> to read that document before doing anything with this one"
> message to most of the people who are familiar with how things
> work than a reclassification of the base documents.  For those
> who aren't familiar with how things work, all of these
> approaches, including moving 6to4 to Historic, are pointless.
>
> That is all.  This can and should be made to sound like mature
> engineering advice, which it presumably is, and not like small
> children throwing mud at each other.
>
>
> Explanation and Rants:
>
> (ii) I think moving _this_ protocol to Experimental is just
> silly.  We use Experimental for things that are
> pre-standardization or not sufficiently mature to be
> standardized.  Although the bar is higher, there are elements of
> "experiment" in every Proposed Standard --that is why we have a
> multiple-step standardization process.   If there is really
> something to be learned from 6to4 operated in a different way,
> then the right action to take would be to propose a 6to4bis that
> outlines the characteristics of the protocol, eliminates
> anything we have concluded should not be done, and outlines the
> desired experiment.  That document might reasonably be listed as
> updating RFC3056 and RFC3068 as well.
>
> (i) <rant> Presumably our goal is to get IPv6 deployed and
> provide advice useful to its deployment, independent of any
> particular piece of protocol or transition arrangement.  At
> least one of the many reasons we haven't seen more deployment is
> that we keep sending messages to the broader community that,
> however unintentionally, discourage that deployment.  In the
> early days of IPv6, we did that by advertising (or letting
> others who were presumed to be speaking for us advertise) that
> IPv6 was completely ready and that transition was going to be
> easy, cheap, and seamless.  For those who had to make decisions
> as to when to deploy IPv6, sufficient investigation tp discover
> that some of that story was untrue became sufficient motivation
> to back away from IPv6 entirely until we got our acts together.
> In more recent years, we have continued to deliver the message
> that the IETF (and, to a lesser extent the RIRs) are simply
> confused about what advice to give and therefore that IPv6 isn't
> ready for someone to deploy who suffers from limited resources
> and a strong desire to do it only when all of the ducks are
> lined up.  Every time we propose a new transition model or
> denounce an old one without what seems to be an
> externally-convincing analysis of the complete picture, we make
> things worse by distributing yet another chapter of "even the
> IETF has no real idea how to transition to IPv6".
>
> If we are serious about encouraging deployment of IPv6 -- and I
> hope we are -- then it is time to stop the apparent war among
> transition strategies.  It seems to me that the document that is
> needed is a vastly strengthened (and probably standards-track)
> version of RFC 6180 (a rather nice document that I would
> encourage those who are engaged in the 6to4 debate on the IETF
> list to read), but one that goes beyond such statements as
>
>        There are several types of tunneling mechanisms,
>        including manually configured IPv6-over-IPv4 tunnels
>        [RFC4213], 6to4 [RFC3056], automatic host-based tunnels
>        [RFC4380], tunnel brokers [RFC3053], running IPv6 over
>        MPLS with IPv6 Provider Edge Routers (6PE) [RFC4798],
>        the use of Virtual Private Networks (VPNs) or mobility
>        tunnels to carry both IPv4 and IPv6 [RFC4301] [RFC5454]
>        [RFC5555] [RFC5844], and many others.
>
> (from Section 4.2) and into a serious discussion of the
> scenarios that are the best match to different of these
> strategies (and others).  If we don't know, then let's say,
> explicitly, that we haven't had quite enough experience to
> provide a differential chart of when particular techniques can
> be used but that they are out their, with their strengths and
> weaknesses, for situations to which they seem well-adapted.  It
> is almost possible to infer from 6180's conclusions that almost
> all transition mechanisms are equivalent, at least within
> groups, and those that aren't are best dealt with by public
> burning.  Clearly we don't believe the first part of that; we
> should get away from the appearance of believing the second.
>
> And, again and most important, if we want to see IPv6 deployed,
> we need a clear message that we actually understand what we are
> doing, that we have a coherent picture, and that our process is
> not one of lurching among solutions, hoping that each one will
> be the magic bullet, and then denouncing any that turn out to
> not have sufficient magical properties.  The marketplace knows
> how to deal with the message we are sending with debates about
> recategorization and we have already seen the answer: it isn't
> the universal deployment of IPv6 before now or any time soon.
> </rant>
>
>    john
>
>
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>



--

Roger Jorgensen           |
[e-mail]          | - IPv6 is The Key!
http://www.jorgensen.no   | [e-mail]



-- 

Roger Jorgensen           |
[e-mail]          | - IPv6 is The Key!
http://www.jorgensen.no   | [e-mail]