Re: RFC4941bis: consequences of many addresses for the network

[Gyan Mishra <[e-mail]>]

Operators already have the option of not using the default valid and
preferred lifetimes.  Most operators don’t change the default values so
maybe  a suggestion could be to change the default values of of the
temporary address regeneration would help with stability.

Also disable temporary address regeneration churn is an issue to make the
address stable by disabling the privacy extension.  If security and
tracking of IPv6 addresses in use is a concern, disable the random station
ID defaulting to the modified EUI64 format.

Can we mention in the draft that a stable IID with privacy extension and
not having a separate temporary address is the directional approach for
6MAN to RFC 7217 and 8064.  Does everyone agree???

Also mention caveats with having multiple addresses from an operations
perspective is not desirable per the default source address selection
algorithm RFC 6724.  With RFC 6724 and predecessor 3484you are not gaining
anything with multiple addresses as the same address is always used.  So
the recommendation is to not send multiple slaac prefixes.

On Fri, Jan 24, 2020 at 7:20 AM Philip Homburg <
[e-mail]> wrote:

> >However, when it comes to rfc4941bis, I don't think there's much more to
> >do than simply including a small paragraph noting that an implementation
> >should be aware about regenerating addresses too quickly,
>
> If people feel strongly about the risk of generating temporary addresses
> too quickly, why not have a TEMP_MIN_PREFERRED_LIFETIME and have some
> text that a node SHOULD NOT generate temporary addresses more often
> than one address (per prefix) per TEMP_MIN_PREFERRED_LIFETIME.
>
> This still allows any future RFC to describe a more advance privacy model
> that does generate addresses more often.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]