Re: RFC4941bis: consequences of many addresses for the network

[Fernando Gont <[e-mail]>]

On 24/1/20 11:54, Gyan Mishra wrote:
> 
> 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.

NOt sure what you mean.


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

NO idea what this means. You shouldn't use EUI64-nbased addressess. If 
you need stable addresses, that's what RFC7217 is for.



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

That's a misrepresentation of RFC7217 and RFC8064.

RFC7217 specifies an alternative algorithm (to EUI64-baed) for 
generating stable addresses. RFC8064 simply recommends RFC7217 over the 
traditional slaac addresses that embed a mac address.

Those two documents don't say much about temporary addresses -- and they 
shouldn't, since they are about stable addresses.



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

Not sure what you mean. RFC6724 is, in fact, all about leveraging 
multiple addresses.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492