Subject: RE: comments about temp-addresses-v2-00

From: "Richard Draves" <[email-masked]>
Date: Wed, 19 Sep 2001 12:58:41 -0700

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

Yes. Section 3.3 step 3) has this correct.

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

In my implementation, I don't do any checks directly on the generated
interface identifier. Instead when I create a temporary address, I check
for known anycast addresses, collisions with existing addresses, etc. If
there is a problem, then I generate a new interface identifier and
repeat. This avoids any timing windows.

This is not quite equivalent to what the draft specifies. For example
suppose an interface A has an EUI-64 based interface identifier IDA and
derived link-local address LIDA. Now interface B is using temporary
addresses with global prefix P and happens to generate interface
identifier IDA. Then my implementation will proceed to create a
temporary address PIDA whereas the draft would prevent interface B from
using IDA.

Is there some reason that the more restrictive behavior specified in the
draft is necessary?

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

---

From: Robert Elz <[email-masked]>
Date: Thu, 20 Sep 2001 11:24:46 +0700

Date:        Wed, 19 Sep 2001 12:58:41 -0700
    From:        "Richard Draves" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Is there some reason that the more restrictive behavior specified in the
  | draft is necessary?

I was thinking about a related issue earlier today, before reading mail,
and while I hadn't connected it to the temp-address draft (it wasn't
related to temp addresses) my conclusion was the same as yours - assigning
the same identifier to different links should be explicitly allowed,
attempts to avoid it are just plain silly.   So, I certainly can't think
of a reason for that particular restriction.   That is, your implementation,
as described, seems like it is the way it should be done.

For temp-address of course it doesn't really matter, Jinmei's implementation
is fine too - since it is a random number being created, no-one can tell
from outside whether that was done using 2 calls of the RNG, with the first
rejected (for any reason the node likes), or using 1 call that happened to
fluke upon a value that was acceptable.   Only when the node starts running
the DAD algorithm can the address selected be observed.

kre