Re: one data point regarding native IPv6 support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Saturday, June 11, 2011 05:28 +1200 Brian E Carpenter
<brian.e.carpenter@xxxxxxxxx> wrote:

> John,
> 
> On 2011-06-11 05:05, John C Klensin wrote:
> 
> ...
>> But, to the extent to which the motivation for moving 6to4 to
>> Historic is what Tony describes as "kill-what-we-don't-like",
> 
> Unfortunately, as I know from the enormous amount of technical
> feedback I got from living, breathing operators while drafting
> draft-ietf-v6ops-advisory, the motivation is "kill something
> that is causing real operational problems and failure modes."
> I wouldn't be endorsing draft-ietf-v6ops-6to4-to-historic if
> there wasn't a very sound operational argument for it.
> 
> I think nobody wants to kill the successful use of 6to4, but
> we need to stop the operational problems getting worse. It
> appears that the default help desk advice to disable 1PV6 is
> generally an echo of problems caused by on-by-default 6to4.

Brian,

This is not in my primary area of expertise and I am painfully
aware that it has been almost a decade since I have been able to
look in on these things from the viewpoint of an ISP with
default-free backbone arrangements, small end-site customers,
and almost everything in between.

>From the above and other comments you have made, I don't think
we disagree very much on the substance here.  I'm certainly not
about to try to make the case that 6to4 is a wonderful option to
be widely preferred.  As a variation on your comment above, I
don't want to see the IETF denounce or kill the successful use
of 6to4 and don't believe anyone else does either (or at least
should).

Where we disagree is about a procedural matter and the stance
the IETF takes formally and, perhaps still, about where the
motivations to deploy IPv6 "for real" comes from.

Let me see if I can describe my position and recommendation in
another way:

Even among those of us who believe that IPv6 conversion has
ceased being optional and has to be considered the only option
at this stage, we really have few clues about what is going to
cause a given ISP, or a given end-node customer, to switch over.
Most of our arguments are faulty, at least for some particular
set of cases.  Your capitalism/competition one is an example --
there are places where it will work and places where it won't.
The applications support and availability of IPv6-capable (and
IPv6-native) servers is another -- sometimes ISPs are waiting
for customer demand and/or enough deployment on customer sites
before they think about making the switch and the customers are
waiting for more evidence that the applications issues are
sorted out and will work reliably.  We talk about the advantages
to the folks who switch early, but we are aware that some folks
don't want to be the first to switch.   And so on, for a rather
long list.

Part of this adds up to a conclusion that we are lots better at
protocol design than we are at predicting the future or gaming
out the decision processes under various circumstances.  We had
better be -- our track record for those predictions is bad
enough that, if our protocol design and engineering were worse,
we should all find other occupations.

At the same time, my very limited and quite anecdotal experience
suggests that the decision in several dual-stack setups to
automatically prefer IPv6 when it is available (following IETF
advice if I recall) combines with sometimes-sketchy IPv6
connections and routing to cause connectivity problems that can
overwhelm the sorts of folks who staff first-level help desks.
6to4 is certainly part of that problem --and a little worse if
it is set up without user or ISP knowledge-- but the implicit
argument in both ..-6to4-advice and 6to4-historic that 6to4 is
the dominant cause of those problems isn't convincing.  Maybe it
is the case, maybe it is the dominant case (and, again, I don't
have enough firsthand experience in recent years to claim to
know) but certainly it is not the only one.  

I accept the claim that it can easily be misconfigured, but that
may not be sufficient to demonize it.

I don't think the technical content of either
draft-ietf-v6ops-6to4-to-historic or
draft-ietf-v6ops-6to4-advisory is especially bad.   Indeed, the
analysis in ...-6to4-advisory seems quite good to me -- the sort
of thing the IETF should, IMO, be doing a lot more often.  I'm
just suggesting that we should not write off _any_ option that
has proven useful to folks in preparing to transition, planning
for transitions, or actually transitioning.    To that end, the
abstract of ...6to4-advisory is just the right think to do.
Advising that 6to4 is a really lousy default, that
implementations should allow it to be turned on only after
appropriate warnings and only if the advice in Section 4 of
..-6to4-advice is followed _really_ carefully may be entirely
appropriate.  Put differently, your analysis appears good enough
that I can see no argument against branding 6to4 as "really
dangerous -- use only if actually understood and needed, then
with great caution, and then only if there is some reason why
6rd is inappropriate or unavailable".

But "Historic" is a really blunt instrument, especially since we
use it primarily for protocols that are no longer in use and/or
that have been demonstrated to be of no redeeming value.  This
situation is, IMO, an almost perfect example of why 2026 permits
us to identify a protocol specification as "NOT RECOMMENDED"
(yes, I think 2119 is defective in listing the conformance
language (MUST/ SHOULD/ MAY/...) but not the recommendation
terminology, but that is another topic).

So my personal preference, in a more perfect world, would be to
fold these two drafts together, drop "Historic" and any even
slightly hyperbolic language, issue the combination as a
standards-track A/S that updates 3056 and 3068 and makes a clear
and carefully explained "NOT RECOMMENDED" statement.   If, in
conjunction with that move, you or others see value in
downgrading 3056 and 3068 to Experimental and including comments
to the effect that they are normally useful only for
exploratory/experimental use, I wouldn't have any problem with
that at all.

I actually don't feel very strongly about the above.  I probably
would not have said anything in this thread if you hadn't raised
the capitalism/competition argument.  But, if there is a
situation where 6to4 really is appropriate and the IETF makes
what appears to be a strong statement deprecating it, we either
convince someone to further defer thinking through and migrating
to IPv6 or we help contribute to the impression that the IETF is
out of touch with real world realities.  I don't consider either
of those outcomes desirable and presume you don't either.   On
the other hand, my impression from conversations with operations
is that it certainly would not be either the first or the most
extreme case in which we've shown the IETF to be out of touch
and at least some users and implementers who find value in 6to4
are likely to continue doing whatever they think it is
appropriate to do regardless of what labels the IETF decided to
put on the specs.

best,
   john


p.s. Editorial nit: I'd love to know what a "domestic customer"
in Sections 2 and 4.2.4 of ...-6to4-advice is.  The term is as
likely to be construed as "within a particular country" (New
Zealand?) as "residential" (which I'm guessing is what you
mean).  As far as I can tell from skimming the document
"residential, small office, or home office (SOHO)" would be more
appropriate and consistent with terminology in common use.

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]