Re: one data point regarding native IPv6 support

[Brian E Carpenter <[e-mail]>]

John,

On one specific point:

>> So my personal preference, in a more perfect world, would be to
>> fold these two drafts together, 

I specifically pushed for the -advisory draft to be kept separate
and Informational in order to get it out ASAP (in my dreams, before
IPv6 Day, but that didn't prove possible). I still think that is the
correct approach - decouple the practical advice from the admittedly
political debate.

I'm not dismissing the rest of your points - clearly there are
varied opinions and "Historic" is, as you say, a blunt instrument.

Regards
   Brian

On 2011-06-11 09:05, John C Klensin wrote:
> 
> --On Saturday, June 11, 2011 05:28 +1200 Brian E Carpenter
> <[e-mail]> 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.
> 
>