Hi Brian, That sounds fair to me. I will come up with text with SHOULD language for per-prefix enabling of privacy addresses. I just have to figure out how it will interact/override with the global enable/disable option.
Pekka, If I make this change, would you still like me to add specific defaults for ULAs? Thanks Suresh On Thu, 21 Oct 2004, Brian E Carpenter wrote: >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 --------------------------------------------------------------------
