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