Re: Mail regarding draft-ietf-dhc-addr-notification

Aditi,

Good to hear feedback from a DHCPv6 implementer on the algorithm. Wanted to
reply on this specific point:

On Fri, Jan 5, 2024 at 11:31 AM Aditi Patange <Aditi.Patange=
[email protected]> wrote:

>
>
>    - Section 4.6 “Whenever the client creates an address or receives a
>    PIO which changes the Valid Lifetime of an existing address by more than 1%”
>
> The Prefix Information Option aspect of the above statement requires the
> client to listen to the state of every address on every adapter, and store
> significant additional state. The client needs to track every address on
> every adapter, lifetime of each address, and has to store both the existing
> time as well as the newly-received time. Needless to say, this could lead
> to race conditions. Also, as the draft briefly acknowledged, this refresh
> logic would have significant power implications especially for devices
> running in low power mode. Can we please simplify the renewal logic to
> reduce computation required by the client?
>

The intent of this text was to ensure that the server always knows about
what addresses are in use. The reason it's written this way is that RAs can
extend, or reduce, the lifetime of existing addresses to arbitrary values
at arbitrary times. So static refresh intervals wouldn't work. Some common
examples in the real world are:

   1. Constant: periodic RAs which refresh the address lifetime to the
   *original* value.
   2. Sawtooth: periodic RAs which refresh the address lifetime to the
   *current* value for a while, then jump back to a higher value (e.g., RA at
   t=0 with lifetime 3600, RA at t=300 with lifetime 3300, RA at t=600 with
   lifetime 3000, RA at t=900 with lifetime 2700, RA at t=1200 with lifetime
   3600). This happens on routers that sync RA lifetimes with DHCPv6 PD timers
   - the RA reflects the remaining lease time of the PD, and then when the PD
   renew happens, it
   3. Configuration changes RAs which lower the lifetime to 0 for
   renumbering, or raise the lifetime for config changes, or...

and so on.

That said, I don't think it's that expensive to implement. Yes, the stack
needs to know the current lifetime (aka expiry time) of every address, and
it needs to detect changes in address lifetime. I don't think it's possible
to write any correct algorithm that doesn't require the client to know this
though. And also, the stack needs this information because otherwise it
can't delete the addresses when their lifetime expires. Even in a situation
where you have a mixed kernel/userspace stack (like Android) this
information isn't difficult to track.

As for CPU and power - the algorithm looks complicated, but in practice, in
most cases, the client only needs to send a bit more than one refresh per
lifetime. Consider case #1 above: if the RA always announces a lifetime of
3600, no matter how many RAs are received, the first refresh happens after
around 2880s, and after that, after another 2880s, and so on. Case #2 is
similar - even though the lifetime in the RA goes down every time, it goes
down linearly, and the 1% text prevents any refreshes until 2880s. At that
point, the next refresh is scheduled for whatever 80% of the remaining
lifetime is. In the example I gave, the next refresh would happen 80% of
2700 and 80% of 3600, or between 2160 and 2880 seconds in the future. The
10% jitter also helps because the client can try to align the refresh with
other wakeups.

The number of packets that need to be sent is similar to (but a bit lower
than) the number of packets that need to be sent for stateful DHCPv6 - by
default, in DHCPv6 T1 is 0.5, so refreshes occur at 50% of lifetime,
whereas here they occur at 80%. If the client has multiple addresses with
the same lifetimes (which is typical for privacy addresses), then it can
refresh all of them at once; sending packets back-to-back makes this
relatively cheap.

Would definitely be interested in any thoughts you have on how to improve
this further. Or maybe some of this should be written down in the draft,
since perhaps not very obvious?

Cheers,
Lorenzo

_______________________________________________
dhcwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dhcwg