Suggestion at the end...
Pekka Savola wrote:
On Wed, 20 Oct 2004, Suresh Krishnan wrote:
o An attacker who is in the path between the node in question and
the peer(s) it is communicating to, and can view the IPv6
addresses present in the datagrams.
However, note that such on the path attacks are likely able to perform significant correlation even with RFC 3041 addresses especially if the payloads are not encrypted.
I would rather state something like this
"However, note that an attacker, who is on path, may be able to perform significant correlation based on the payloads of the packets on the wire. Use of temporary addresses will not prevent such payload based correlation"
This clearly indicates that the correlation is done using data present in the payload. Is this text acceptable to you?
That's fine.
As far as I can see, it's exactly the opposite -- privacy extensions should not be enabled by default for ULAs.
This is already the case. Privacy extensions are disabled by default for ALL types of global addresses (including the ULA).
Yes, it's not default -- but what I want to have is being able to distinguish between "enabling privacy for all prefixes" and "enabling privacy for global range prefixes".
I.e., the implementations, when privacy is enabled, should not start using privacy extensions by default for ULA addresses, but doing so might be configurable.
I think that would be in line with most ULA users' goals.. too bad it's relatively difficult to unambugously say what those global, non-ULA addresses should be called..
One way to go about this will be to attach a disable flag for specific prefix ranges. i.e. fc00::/7 in case of ULAs. This flag will override the global enable setting if present for the fc00::/7 range.
I will add the following text after the first paragraph of "Deployment Considerations"
"Additionally, sites might wish to disable the use of temporary addresses for some prefixes while still using them for other global prefixes. For example, a site might wish to disable temporary address generation for "Unique local" [ULA] prefixes while still generating
temporary addresses for all other global prefixes.To support this behavior,
implementations MAY provide a way to disable generation of temporary
addresses for specific prefix subranges. This setting, if present, MUST override the global settings on the node with respect to the
specified prefix subranges."
I'm slightly unconformtable with this approach for a couple of reasons. First, by default, privacy addresses are generated for ULAs as well. Second, such a flag is just a MAY.
What I'd propose is specify that ULAs SHOULD be excluded by default
when privacy addresses are enabled, but that there MAY [or SHOULD] be a flag to enable privacy addresses for ULAs.
Would that be reasonable?
Note that this will create a dependency on ULA spec(s) becoming RFC before this one does (so that the IANA assigns the prefix range), but that might not be a problem, as AFAIR they're relatively far in the process. There's no need for normative reference as we want just to know the prefix(es).
I think it would be better to RECOMMEND that an implementation should support netmasks for privacy addresses to be enabled, e.g. enable them for 2001::/16 and 2002::/16 only, else disable. Then you don't have to call out ULAs at all.
Brian
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
