I prefer B, and this is what most existing implementations of RFC 3484 seem to already do (i.e., they follow the MAY not the SHOULD) whenever privacy addresses are enabled. I have yet to hear of an implementation of RFC 3484 that actually follows the SHOULD (A) rather than the MAY (B), but maybe someone on this list knows of one.
To respond to Ray's "From the corporate World: option A as default, with local user controlled option to override": In the corporate world, one requirement we've heard is to disable privacy addresses all together, not just depreference them. This is consistent with Brian Carpenter's response. As such, the Windows implementation of RFC 3484 has always preferred privacy addresses when enabled, and lets the administrator enable/disable them. Client OS's (Vista, Windows 7, etc.) have them enabled by default, but can be disabled by an enterprise administrator either manually or across the enterprise via Group Policy. Server OS's (Server 2003, Server 2008, etc.) have them disabled by default, but can be enabled by an administrator. -Dave From: [email protected] [mailto:[email protected]] On Behalf Of Ray Hunter Sent: Tuesday, March 27, 2012 10:00 AM To: Brian Haberman Cc: [email protected] Subject: Re: 3484bis and privacy addresses >From the corporate World: option A as default, with local user controlled >option to override. RFC3484 (which references RFC3041) "Temporary addresses" are a menace to fault finding, audit, logging, firewall rules, filtering, QoS matching, conformance: anywhere where an ACL or stable address is used today. Sure we shouldn't use fixed/stable IP literals, but we do. And in many cases there aren't any practical alternatives in today's products, so the IP address is the lowest common denominator used to identify a machine (and dare I say even "a user" in some circumstances). Also not sure if any DHCPv6 server implementations actually provide DHCPv6 assigned temporary addresses in practice. My take on this is that a set of a few hundred individual persons who are worried about privacy are more likely to be able to control their own particular machines to correctly override the "default off" setting than a single corporate network manager is to be able to guarantee overriding a "default on" setting on 100% of 10000 machines attached to their network. regards, RayH Brian Haberman wrote: <div class="moz-text-flowed">All, The chairs would like to get a sense of the working group on changing the current (defined 3484) model of preferring public addresses over privacy addresses during the address selection process. RFC 3484 prefers public addresses with the ability (MAY) of an implementation to reverse the preference. The suggestion has been made to reverse that preference in 3484bis (prefer privacy addresses over public ones). Regardless, the document will allow implementers/users to reverse the default preference. Please state your preference for one of the following default options : A. Prefer public addresses over privacy addresses B. Prefer privacy addresses over public addresses Regards, Brian, Bob, & Ole </div> -- Ray Hunter [email protected]<mailto:[email protected]> Globis Consulting BV, Fazantlaan 23, 5613CB Eindhoven NL, Registered at the KvK, Eindhoven, under number BV 17098279 mobile: +31 620 363864
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
