In your previous mail you wrote:
> I believe you can make your set of rules simpler if you introduce
> a new lifetime (or condition if one needs something smarter than
> a delay). I'll call it "regen lifetime" and when the regen lifetime
> of an anonymous address expires then a new address is created, checked
> by DAD then is used as the anonymous address, the old one is
> deprecated.
> With this we can keep the current deprecated/invalid mechanism on RA
> receptions (this is complex enough with the two hour rule and all the
> side effects we can get from short lifetimes (mis)used for mobility).
I don't think this works. Suppose you have an existing anonymous address,
say with a zero preferred lifetime and a 3 hour valid lifetime. (And you
also have other anonymous addresses and a public address with the same
prefix.)
=> I believe this anonymous address is an old one, ie. its preferred lifetime
is zero because its regen lifetime has expired.
Now you receive an RA with a matching prefix information option.
The lifetimes in the option are 1 day preferred and 1 week valid. You don't
want to change the lifetimes of the existing anonymous address.
=> when the regen lifetime has expired received RAs can only shorten the
valid lifetime, for instance if the announced valid lifetime is X,
the remaining valid lifetime Y with X < Y then the valid lifetime will be
set to X modulo the two hour rule.
When the regen lifetime has not expired then the standard RA processing
can be used.
Hence, the rules for processing lifetimes in prefix information options do
need a special case for anonymous addresses.
=> yes but my purpose was (and still is) to get a simpler set of rules
and I think this is easier with three lifetimes than with a hierarchy
of exceptions: just apply the KISS principle (:-).
Thanks
[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]
--------------------------------------------------------------------
