[142734] in North American Network Operators' Group
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
daemon@ATHENA.MIT.EDU (Tim Chown)
Tue Jul 12 12:12:14 2011
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <D246AAA8-4DD3-414C-8CE0-2B4ED074B5BD@delong.com>
Date: Tue, 12 Jul 2011 17:11:58 +0100
To: NANOG list <nanog@nanog.org>
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 10 Jul 2011, at 21:22, Owen DeLong wrote:
> On Jul 10, 2011, at 12:23 PM, William Herrin wrote:
>=20
>> Consider, for example, RFC 3484. That's the one that determines how =
an
>> IPv6 capable host selects which of a group of candidate IPv4 and IPv6
>> addresses for a particular host name gets priority. How is a server's
>> address priority NOT an issue that should be managed at an operations
>> level by individual server administrators? Yet the working group =
which
>> produced it came up with a static prioritization that is the root
>> cause of a significant portion of the IPv6 deployment headaches we
>> face.
>>=20
> 3484 specifies a static default. By definition, defaults in absence of
> operator configuration kind of have to be static. Having a reasonable
> and expected set of defaults documented in an RFC provides a known
> quantity for what operators can/should expect from hosts they have
> not configured. I see nothing wrong with RFC 3484 other than I would
> agree that the choices made were suboptimal. Mostly that was based
> on optimism and a lack of experience available at the time of writing.
>=20
> There is another RFC and there are APIs and most operating systems
> have configuration mechanisms where an operator CAN set that to
> something other than the 3484 defaults.
There is a DHCPv6 option to configure host policy described in =
http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-01, which is =
hopefully approaching a WGLC at IETF81. =20
RFC3484 was originally published in 2003, which is a long time ago. And =
of course it turned out that, with wider operational experience and =
feedback from the operator community, there were some issues uncovered =
and some omissions. Perhaps some of those might have been foreseen, but =
I highly doubt all of them would have. Many of the issues were captured =
in RFC5220, which led to the work on RFC3484-bis, which is also close to =
publication. =20
Now, perhaps the DHCPv6 option and the 3484-bis drafts could be posted =
to the NANOG list at an appropriate time, for example when the docs hit =
WGLC. But there are a lot of WGLCs out there and the question is then =
whether the NANOG list, or some special NANOG list for IETF WGLCs, would =
want all those notifications.
As a co-author of the DHCPv6 and 3484-bis drafts, I am quite happy to =
post about these to NANOG as they approach last call. There are three =
open issues on 3484-bis that some feedback would be welcomed on. =20
>> There should be an operations callout as well -- a section where
>> proposed operations defaults (as well as statics for which a solid
>> case can be made for an operations tunable) are extracted from the
>> thick of it and offered for operator scrutiny prior to publication of
>> the RFC.
>=20
> I think this would be a good idea, actually. It would probably be more
> effective to propose it to IETF than to NANOG, however.
Whether it's a separate section in the draft, or a recommendation to =
post to operators communities (which is more than just NANOG of course), =
the question as mentioned above is how that's done in a way to get the =
attention of appropriate operators without drowning them in =
notifications. =20
Tim
