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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf