I can also live with Brian Carpenter's response.
In terms of a general default in shipped IPv6 stacks, I prefer
B, but it has to be qualified:
There MUST be a user option to change this preference.
There SHOULD be a network manager option to change this preference.
The rationale for this is that we need privacy by default in shipped
products, with the ability for the person deploying the product to
override this.
Brian C
Windows may have got it pretty much right for allowing network operators
to control privacy addresses, and turning them off by default at least
on servers. But with all due respect, the control mechanism mentioned by
Dave only covers machines that are members of a (proprietary) Active
Directory domain: It does not cover guest LANs, outsourced services,
other operating systems, nor Bring Your Own Device, which are all
increasing trends in the corporate World.
Network managers need that switch.
Can anyone show me where that's defined in an RFC?
regards,
RayH
Dave Thaler wrote:
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:* ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] *On
Behalf Of *Ray Hunter
*Sent:* Tuesday, March 27, 2012 10:00 AM
*To:* Brian Haberman
*Cc:* ipv6@ietf.org
*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
ray.hun...@globis.net <mailto:ray.hun...@globis.net>
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
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
