On 07/16/2011 07:02, John C Klensin wrote:
--On Friday, July 15, 2011 15:39 -0700 Doug Barton
<dougb(_at_)dougbarton(_dot_)us> wrote:
To address your concern about whether or not vendors are paying
attention to this discussion, and why historic status is
substantively different than "off by default, no really, OFF
BY DEFAULT," I'll put my FreeBSD developer hat on for a minute
and tell you that we definitely do pay attention to stuff like
this, and whereas we already have it off by default (and have
for some time) moving it to historic gives us the cover we
need to remove the code at some point down the road when that's
appropriate. That's an extremely important distinction, and
one of the reasons that as a "member" of v6ops I ultimately
came down in support of the 2-document strategy.
Doug,
And that is exactly where we agree on the effect and disagree
about whether it is desirable.
Right.
I think there is consensus that 6to4 is dangerous unless
carefully and intelligently configured and that is certainly
should not be turned on by default. If anyone has argued
against that position, they are in a tiny minority.
Similarly, I think there is consensus that following the advice
in the "advice" document makes 6to4 much safer to use, even if
not entirely risk-free (I contend that there is no "risk-free",
perhaps as a corollary to the principle that, if we invent
something idiot-proof, someone will invent a better idiot). So
there should be no question about the desirability about
publishing the content of that document.
Agreed so far, especially about the idiots. :)
The question, as far as the "advice" document is concerned, is
how to get the message out most effectively, most clearly, and
on as timely a basis as possible. I think that having it
"update" the base 6to4 specs is important because that is how
the RFC Series is threaded. Without that, there is an increased
risk of people finding the 6to4 specs and implementing them
without ever seeing the "advice" piece (just as, even with the
"updates"/"updated by" pointers, we still hear about new TCP
implementations based on RFC 793 alone). For the reasons
discussed above, I don't think anyone would find that outcome
desirable.
You know the subtleties of the various document tracks infinitely better
than I do, so I'm not even going to try and debate you on that.
OTOH, I find the idea of someone implementing 6to4 from scratch at this
point highly unlikely. I also think that declaring it historic would
make the scenario you describe that much more unlikely.
[snip]
But, while some people have argued that 6to4 has caused so much
damage by being misconfigured that it should, presumably as
punishment or to create a public example, be eliminated entirely
as an option
My perspective, which I've described at length many times now, is not
that 6to4 needs to be punished, but that the widespread deployment of
IPv6 is being harmed as a result of the negative user experience that it
creates for the majority of its users (particularly the unintentional
ones) and therefore the network as a whole is better off if it goes away.
To summarize my main points once again (since you seem determined to
reopen the debate on 6to4's utility):
1. There is next to zero IPv6-only content at this time.
2. Therefore the number of people who actually *need* IPv6 is so close
to zero as to not be a factor.
3. Of the tiny number of people that actually do need IPv6, there are
plenty of other tunnel options.
4. By the time that there *is* IPv6-only content the market will have
sorted out access for the average user.
Thus, 6to4 hurts way more than it helps at this point.
Furthermore you have the huge problem that neither end of the 6to4
equation has *any* motivation to fix it. The ISP side can simply block
tunnels (or even simpler, ignore the problem). The content side can
simply not deploy AAAA records.
I do think that the -advice document is a good thing, and for those that
care I think it's great that the IETF is going to help them out. But all
statements of the form "all we need to do to fix 6to4 is X" are
non-starters because the people with the ability to actually fix it are
not going to.
-- for FreeBSD users, the exact effect of your removing the code --
To be clear, I didn't say that we *will* remove it, only that making it
historic gives us that opportunity at some point down the road *if* that
becomes appropriate.
I haven't seen nearly as strong as case, or
anything even close to consensus, for that position. If it was
actually what the community believed, then the "advice" document
would be a complete waste of time except possibly as a
retrospective on how 6to4 might have been better specified (a
retrospective that we would want to publish as (immediately)
Historic).
Once again repeating myself, but I disagree. The idea of publishing both
documents represents a fine compromise between the 2 extreme positions,
and allows those who want to continue using it to do so in the best way
possible. It's also not the first time the IETF has published a document
that says, effectively, "We don't think you should do this, but if
you're going to do it anyway, here's how to do it right."
If the thing is still useful, even in limited circumstances and
used correctly, then the IETF should not provide you with
"cover" to remove the code because it is not in the best
interest of the community for you to remove the code. Might
both your removing the code and moving 6to4 to Historic in the
future be appropriate? Sure. I also look forward to the day
when we can move IPv4 to Historic (just as the various
specifications that make up NCP should have been moved years ago
if we paid attention to that sort of housekeeping).
So the debate is on the timing. I (and others) think that the time is
now. My opinion is that there is also a pretty strong community
consensus that the time is now, modulo a very vocal group of people who
do not. But fortunately I'm not the one who has to make the decision
about what there is and is not consensus for. :)
[snip]
FWIW, I note that there are at least a few other things that
shipped for years with FreeBSD that could cause a lot of damage
if misconfigured and were hard to configure correctly, but were
nonetheless included in the code in version after version and
even were enabled by default. Getting rid of them would not
have required any IETF action -- there were other
implementations of the same protocols that could have been
included in the base systems instead. But they weren't removed
or replaced (the folks who produced them eventually produced
better versions).
Putting my FreeBSD hat back on for a second, we're always interested in
improving our code base, and would certainly not want to intentionally
do anything to "cause a lot of damage." If there are concrete concerns
anyone should feel free to file a Problem Report at
http://www.freebsd.org/send-pr.html, or use the 'send-pr' utility in
FreeBSD.
But I don't recall seeing the sort of venom
that is directed toward 6to4 being focused on them. Perhaps
there weren't enough complaints or you have solid data that 6to4
has caused even more damage.
Once again repeating myself ... I have no venom towards 6to4. This isn't
a personal attack. And yes, various people and organizations that have
vested interests in seeing IPv6 deployed have posted the data about why
6to4 causes way more problems than it solves, and I believe them.
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf