Hi Pekka/Brian, This is the text I added to have a per-prefix enable/disable setting. Hope it resolves your issues.
"Additionally, sites might wish to selectively enable or disable the use of temporary addresses for some 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. Another site might wish to enable temporary address generation only for the prefixes 2001::/16 and 2002::/16 while disabling it for all other prefixes. To support this behavior, implementations SHOULD provide a way to enable and disable generation of temporary addresses for specific prefix subranges. This per-prefix setting SHOULD override the global settings on the node with respect to the specified prefix subranges." Thanks Suresh On Fri, 22 Oct 2004, Suresh Krishnan wrote: >Hi Pekka/Brian, > I was thinking of enable/disable flags for separate prefixes which >override the global settings. > >Let's say you want privacy addresses for everything but ULA >you would have the following settings > >Global -> Enabled >fc00::/7 -> Disabled > >Let's say Brian just wants to enable them for 2001::/16 and 2002::/16 > >Global -> Disabled >2001::/16 -> Enabled >2002::/16 -> Enabled > >I think that should address both your concern and Brian's concern. > >Thanks >Suresh > > On Thu, 21 Oct 2004, Pekka Savola wrote: > >>On Thu, 21 Oct 2004, Suresh Krishnan wrote: >>> 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? >> >>I can live with 2001::/16 + 2002::/16, but I think that's a bad choice >>for multiple reasons. What if we invent 6to4v2 which uses 2005::/16 >>and we'd like to automatically apply these semantics to it? What if >>we run out of 2001::/16 for native allocations? -- actually we've >>already 1/3 used it up. >> >>Thus being generic and excluding just those that we _know_ aren't >>really, really global might seem as a better approach -- one that we >>might not need to tweak e.g., 2-3 years down the road.. >> >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------