>4. This text: > > Note that, except for the > transient period when a temporary address is being regenerated, in > normal operation at most one temporary address per prefix should be > in a non-deprecated state at any given time on a given interface. > >seems excessive because it immediately makes all current implementations >non-compliant. It also does not seem like a good thing to limit the number >of temporary addresses in general. If an implementation wants to create >more than one for extra privacy (e.g., to use different IPv6 addresses for >different applications), it should be free to do so. This text is also not >true if a user changes TEMP_VALID_LIFETIME to a value that is not exactly >2x TEMP_PREFERRED_LIFETIME. Users are explicitly permitted to change these >values in section 3.8. Can you explain what current implementations are doing differently? As far as I know there is usually only one temporary address that is not deprecated. I'm not sure how it would work if you have multiple addresses that are not deprecated. It becomes ambiguous which address will be selected by source addresss selection. At the same time, if an application wants to bind to a specific address then an address only needs to valid, deprecated is fine. Even better because that means that source address selection will not select that address (unless all addresses are deprecated). -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
