Anybody can participate in the IETF (Was: Why is IPv6 broken?)

Mon Jul 11 06:57:37 UTC 2011

On Sun, Jul 10, 2011 at 4:22 PM, Owen DeLong <owen at delong.com> wrote:
> On Jul 10, 2011, at 12:23 PM, William Herrin wrote:
>> 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.
>>
> 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.

Hi Owen,

A more optimal answer would have been to make AAAA records more like
MX or SRV records -- with explicit priorities the clients are
encouraged to follow. I wasn't there but I'd be willing to bet there
was a lonely voice in the room saying, hey, this should be controlled
by the sysadmin. A lonely voice that got shouted down.

>> Today's RFC candidates are required to call out IANA considerations
>> and security considerations in special sections. They do so because
>> each of these areas has landmines that the majority of working groups
>> are ill equipped to consider on their own.
>>
>> 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.
>
> I think this would be a good idea, actually. It would probably be more
> effective to propose it to IETF than to NANOG, however.

If the complaint is that the IETF doesn't adequately listen to the
operations folk, then I think it makes sense to consult the operations
folks early and often on potential fixes. If folks here think it would
help, -that- is when I'll it to the IETF.

Regards,
Bill Herrin

-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004