Hi Jinmei,
I will make the change by taking out the DESYNC_FACTOR from the Valid
Lifetime calculation.
Thanks
Suresh
JINMEI Tatuya / 神明達哉 wrote:
I've just noticed that the latest draft of
draft-ietf-ipv6-privacy-addrs-v2 has not reflected a previous discussion.
See the first point of this:
http://www.atm.tut.fi/list-archive/ipng/msg01005.html
Rephrasing it for the latest draft would be as follows:
In section 3.3, it states:
1. Process the Prefix Information Option as defined in [ADDRCONF],
either creating a new public address or adjusting the lifetimes
of existing addresses, both public and temporary. If a received
option will extend the lifetime of a public address, the
lifetimes of temporary addresses should be extended, subject to
the overall constraint that no temporary addresses should ever
remain "valid" or "preferred" for a time longer than
(TEMP_VALID_LIFETIME - DESYNC_FACTOR) or (TEMP_PREFERRED_LIFETIME
- DESYNC_FACTOR) respectively. The configuration variables
TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to
approximate target lifetimes for temporary addresses.
But "(TEMP_VALID_LIFETIME - DESYNC_FACTOR)" should actually be just
TEMP_VALID_LIFETIME because there is no timing issue for regeneration
on valid lifetimes.
The main author at that time (Rich Draves) agreed this point:
http://www.atm.tut.fi/list-archive/ipng/msg01097.html
Unless I miss something, I still believe just using
TEMP_VALID_LIFETIME is more reasonable, and this document should
incorporate the change before publication.
(I myself had forgotten the past discussion, and have changed our
implementation with the seemingly redundant DESYNC_FACTOR...)
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------