I've implemented draft-ietf-ipngwg-temp-addresses-v2-00.txt and have
a couple of comments:
In section 3.3. Generating Temporary Addresses
1) Process the Prefix Information Option as defined in [ADDRCONF],
either creating a public address or adjusting the lifetimes of
existing addresses, both public and temporary. When adjusting the
lifetime of an existing temporary address, there are two cases to
consider:
(snip)
b) In many cases, the lifetime in a received option will extend
the lifetime of a public address. For example, a site might
advertise short lifetimes (on the order of hours or minutes)
that are effectively extended with each new RA. In such cases,
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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^I think this should be
just "TEMP_VALID_LIFETIME", because there is no timing issue for
regeneration on valid lifetimes.
(TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR) respectively. The
configuration variables TEMP_VALID_LIFETIME and
TEMP_PREFERRED_LIFETIME correspond to approximate target
lifetimes for temporary addresses.
In section 3.2.1,
4) Compare the generated identifier against a list of known values
that should not be used. Inappropriate values include those used
in reserved anycast addresses [RFC 2526], those used by ISATAP
[ISATAP], the value 0, and those already assigned to an address on
the local device. ...
I'm not sure what "the local device" exactly means. Is it the
"interface" on which a new identifier are being generated, or is it
the "whole node"? Our current implementation takes the latter
interpretation.
In any case, probably due to this addition, Step 4) in section 3.3 was
simplified:
4) New temporary addresses are created by appending the interface's
current randomized interface identifier to the prefix that was
used to generate the corresponding public address.
than the one in RFC3041:
4) New temporary addresses are created by appending the interface's
current randomized interface identifier to the prefix that was
used to generate the corresponding public address. If by chance
the new temporary address is the same as an address already
assigned to the interface, generate a new randomized interface
identifier and repeat this step.
That is, the duplication check was omitted. But, technically, this
cannot be omitted, because there is a time-lag between the generation
of interface identifiers and the generation of actual temporary
addresses.
If the draft regards this time-lag as practically negligible, I think
it's okay. But IMH it should mention the issue anyway.
Our current implementation checks the duplication at the generation of
actual addresses as well as at the generation of interface
identifiers.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
