Draft RFC3484bis-01 currently references RFC4941 as a normative
reference in Section 11.1:
Privacy considerations have introduced the concepts of "public
addresses" and "temporary addresses" [RFC4941
<http://77.72.230.30/html/rfc4941>].
So I think we have to assume that a node will have such addresses
present by default when considering RFC3484bis.
I could completely agree with your logic if RFC3484bis did not have
RFC4941 as a normative reference, or if 3484bis was coupled with
draft-gont-6man-managing-slaac-policy-00, or
draft-ietf-6man-addr-select-opt-03 was already deployed in the field,
or the M&O bits of RA were defined to force use of DHCPv6, or there was
a common proprietary cross-OS mechanism available or indeed anything
else that would allow a network manager to reliably control use of
temporary addresses. But there isn't AFAIK. Unless you also
intentionally break SLAAC.
So IMHO, in the absence of any other reliable OFF switch, RFC3484-bis
itself currently really is the only place where a reliable default "OFF"
can be specified at this time. I don't mind how this is achieved: either
in the preference rules themselves, or in other clarification text that
describes safe default backwards-compatible end-node behavior that will
not break other systems that currently rely on IPv4-like behavior.
regards,
RayH
Karl Auer wrote:
On Tue, 2012-03-27 at 21:05 +0200, Ray Hunter wrote:
IMHO the proper *default* behavior is still "off" = option A. In other
words, default = IPv4-like behavior, at least until we really figure
out how to operate all of these fancy new features of IPv6.
The question is not whether the use of privacy addresses (temporary
addresses) should be enabled by default. Though some OSes do that, I
believe.
The question is, where a host *does* have both a temporary and a
non-temporary addresses, which one it should prefer by default. "Prefer
by default" in this case means "select as the source address for new
outbound connections in the absence of specific instructions to do
otherwise".
Regards, K.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
