Subject: comments about temp-addresses-v2-00

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 10 Sep 2001 22:26:10 +0900

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-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------