Subject: Re: HEADS UP! Default value of ip6_v6only changed
To: Perry E. Metzger <email@example.com>
From: Daniel Carosone <firstname.lastname@example.org>
Date: 10/29/2003 07:45:41
On Tue, Oct 28, 2003 at 09:25:08AM -0500, Perry E. Metzger wrote:
> > Itojun still has significant concerns about the new default behavior.
> He's not the only one.
Count me among that group.
However, my concerns are at least in part because I haven't seen
a compelling case *for* the new behaviour. I'm sure there must be
> Might I suggest that Core convene a group of v6 experts to re-consider
> the question?
Hm. See below.
> It might also be reasonable to request a more current
> opinion from the appropriate IETF working group -- I suspect that they
> would no longer support mapping by default.
That is reasonable, but I think at least part of the "problem" with
this issue is that, at least as evidenced by rfc's and drafts, the
-harmful case has failed to persuade the IETF.
Perhaps those of us with such concerns need to take the case there.
> By the way, as a matter of process, it might be useful if core announced
> that it was considering changes like this and explicitly solicited
> input. If I had known that you were considering this, I would have
> spoken up. I had assumed the recent discussion on the subject was just
> the usual argumentation -- I didn't know you were going to make a decision.
I'm not so sure about this. I think there's an aspect here of
"damned if you do, damned if you don't" for core. I'm sure that
core took this decision exactly because of all the usual argumentation,
in an effort to forestall more (which, of course, we're now doing
I'm glad to see this, regardless of my personal opinions on the
particular matter at hand. Many of us have wished in the past that
some of the long-running recurring threads could be put in their
place with an official technical decision - either way. So I don't
want to fault core for doing so this time.
On the question of process, what Perry suggests above might be
worth discussing separately for next time. If I were to point out
faults with process this time, it would be that the published
decision from core didn't include any helpful information for those
affected - what the meaning and nature of the change was, why it
was made, and how to address any fallout.
And in the meantime, I can set my own policy on this issue to
reflect my own preferences in sysctl.conf.