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
--------------------------------------------------------------------
