Re: Another look at 6to4 (and other IPv6 transition issues)

So the rational for the advice document not being combined with the standards action in it is that the later has some polarizing impact, the advice document does not. the advice document is through and done, historic is not.

On Jul 15, 2011, at 8:55 AM, John C Klensin 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
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 