Re: [dhcwg] Comments on draft-ietf-dhc-addr-notification-00

[Lorenzo Colitti <[e-mail]>]

Thanks for all the comments! I think these should all be addressed in -03
which we posted a few minutes ago.

On Tue, Aug 15, 2023 at 12:56 PM Bernie Volz <[e-mail]> wrote:

> Just looked at draft refresh section (not other parts). And looks ok.
> Though the following seems a bit odd:
>
> If the address registration server does not receive such a refresh after
> the Valid Lifetime has passed, it SHOULD remove the record of the
> Client-Identifier-to-IPv6-address binding.¶
> <https://wkumari.github.io/draft-wkumari-dhc-addr-notification/draft-ietf-dhc-addr-notification.html#section-4.3-7>
>
> Shouldn’t this be before (not after)?
>
> - Bernie (from iPad)
>
> On Aug 14, 2023, at 11:00 PM, Lorenzo Colitti <[e-mail]> wrote:
>
> 
> The text in the working copy has been updated to reflect this thread. See updated
> text here
> <https://wkumari.github.io/draft-wkumari-dhc-addr-notification/draft-ietf-dhc-addr-notification.html#name-registration-expiry-and-ref>.
> Michael, Bernie, does that work?
>
> There are a couple of other issues I just thought of.
>
> First, clock skew and transmission delays might affect the algorithm.
> Example:
>
>    1. Server sends an RA with a lifetime of 600, but it is delayed by
>    300ms by congestion.
>    2. After 60 seconds, server sends an RA with a lifetime of 540, which
>    is not delayed by congestion. At this point the client will think the
>    lifetime is still 541 seconds, and thus it might think that the lifetime
>    "changed".
>
> To avoid this we might want to change "changes the Valid Lifetime of an
> existing address" to "changes the Valid Lifetime of an existing address by
> more than 1% (to account for clock skew)".
>
> Second: should we say that when the ADDR-REG-INFORM message is
> retransmitted, the retransmitted packet SHOULD (or even MUST) contain the
> current lifetime of the address, not the one in the original packet?
> Rationale: If a client sends an update with a lifetime of 600s, and then
> later retransmits the packet a few times, and the server only gets the
> retransmit that happens 10s later, it would be good if the server received
> a lifetime of 590s instead of 600s. Bernie, do you know of anything in the
> DHCPv6 RFCs that say that retransmitted packets must be identical to the
> original packet?
>
> Thoughts?
>
> On Sat, Aug 12, 2023 at 4:52 PM Jen Linkova <[e-mail]> wrote:
>
>> On Fri, Aug 11, 2023 at 5:40 PM Bernie Volz <[e-mail]> wrote:
>> >
>> > How about "The client MUST periodically refresh addresses using the
>> > logic described below"?That would clearly indicate how the refreshes
>> > shall be scheduled,
>> >
>> >
>> > I’d remove periodically.
>>
>> SGTM, the change will be integrated into the next version of the draft.
>>
>> >
>> > - Bernie (from iPad)
>> >
>> > On Aug 11, 2023, at 7:34 PM, Jen Linkova <[e-mail]> wrote:
>> >
>> > On Fri, Aug 11, 2023 at 3:26 PM Bernie Volz <[e-mail]> wrote:
>> >
>> >
>> > So you are saying that if host generates address with lifetime of 10m,
>> only one refresh at 8m will be sent. Unless and if a PIO received.
>> >
>> >
>> > Yes, exactly.
>> >
>> > Let's look at different cases:
>> >
>> > Case1: The network keeps sending RAs with constant valid lifetime for
>> > the given PIO.
>> >
>> > Initial state: a hoist has no addresses.
>> > t=0. A PIO with valid = 10m received. An address is formed and moved
>> > to preferred state. The address has a lifetime of 10 mins, a
>> > registration is sent, and the message includes the current preferred
>> > and valid lifetimes (X mins and 10 mins). The next refresh is
>> > scheduled to be sent in 8 mins.
>> > All RAs received between t=0 and t=8 refresh the address's actual
>> > lifetime, but do not trigger a new refresh message (as those messages
>> > would have been scheduled *after* one which is scheduled already).
>> > t = 8m.  As the host has been receiving RAs for that PIO with valid
>> > lifetime = 10m, the actual lifetime (Y) is getting refreshed, so it's
>> > 2mins  < Y < 10min.
>> > The host sends a registration message (as it's already scheduled) with
>> > the actual lifetime. NO new registration messages are scheduled at
>> > that point.
>> >
>> > t < 8 + Y: a host would receive an RA  with the PIO with valid
>> > lifetime = 10m. (otherwise the address becomes invalid, we are done).
>> > That refreshes the actual lifetime (making it 10 mins again), and, as
>> > per #1 from the proposed algorithm, would schedule a new refresh in
>> > the next 8 mins.
>> > etc.
>> >
>> > Case 2: The prefix disappeared from the network.
>> > t = 0. The address was either formed (or an RA refreshed the lifetime
>> > and triggered the refresh message). The actual address lifetime is
>> > 10m.
>> > The next message is scheduled in 8 mins.
>> > t = 8m. The message is sent, informing the server that the address
>> > currently has a valid lifetime of 2 mins.
>> > t = 10m. The address is invalid. End of story.
>> >
>> > Case 3. The network needs to *reduce* the valid lifetime (e.g. for
>> renumbering).
>> > t = 0.  The address was either formed (or an RA refreshed the lifetime
>> > and triggered the refresh message). The actual address lifetime is
>> > 10m.
>> > The next message is scheduled in 8 mins.
>> > t = 4 mins (4 is just an example). A PIO received with valid = 4 mins.
>> > It sets the address's actual valid lifetime to 4 min, and - as per #2
>> > from the proposed algorithm, the next refresh should happen in 3.5
>> > mins (t=7.5m), which is earlier than the currently scheduled message,
>> > so the client reschedules it.
>> > t = 7.5m. The registration message is sent, containing the *actual*
>> > lifetime of the address (which is between 0.5 and 4 mins at that
>> > moment).
>> > .... the next PIO received (which must come before the address becomes
>> > invalid) would cause another refresh message and schedule one in 3.5
>> > mins.
>> > Etc.
>> >
>> > Case 4. The network increases the valid lifetime for a PIO.
>> > t = 0.  The address was either formed (or an RA refreshed the lifetime
>> > and triggered the refresh message). The actual address lifetime is
>> > 10m.
>> > The next message is scheduled in 8 mins.
>> > t = 4 mins (4 is just an example). A PIO received with valid = 24hrs.
>> > it refreshes the actual lifetime of the address, setting it to 24 hrs,
>> > but it doesn't reschedule the refresh message.
>> > t = 8 mins. A refresh message is sent, informing the server that the
>> > address is still there with the valid lifetime of 23hrs 56mins. No
>> > other refresh messages are scheduled.
>> > 8mins < t1 <24hrs: an RA received, which refreshes the lifetime,
>> > triggers the refresh message and schedules the next one in 4hrs (as
>> > 24hrs*0.8 > 4hrs).
>> > t1 + 4hrs: A refresh message is sent, informing the server that the
>> > address is still there with the valid lifetime of ..whatever it is ;)
>> >
>> > yes, if the valid lifetime is very short (which means a lot of RAs are
>> > sent), the client might be refreshing too often - that's why we might
>> > want  (as Lorenzo suggested) to set a lower limit as well.
>> >
>> > But what happens in case where lifetime is 24 hours? Then only one
>> refresh will be sent (after 4 hours) unless a PIO is received?
>> >
>> >
>> > Please keep in mind that the host would receive multiple (definitely
>> > more than 3) RAs with the PIO during the valid lifetime interval.
>> >
>> > Example case (all times from t=0) when address generated with 24 hour
>> lifetime. Registration sent. First refresh sent after 4 hours. And PIO sent
>> after 12 hours to extend another 24.
>> >
>> > This re-registration happens here happens after 8 hours (when PIO
>> received) - this is case 1.
>> >
>> >
>> > So the 4 hour periodic refresh is not done?
>> >
>> >
>> > Maybe we get rid of the 4 hour periodic refreshes altogether?? Or maybe
>> these edge cases are just that and will show odd behavior.
>> >
>> >
>> > It's not our goal to guarantee that the message is always sent at
>> > least every 4 hrs. There is no practical difference between 4 hrs and
>> > 8 hrs, as long as the message contains the up-to-date address's
>> > lifetime (so the administrator knows "if the lifetime expired and we
>> > haven't heard from the host - it's not there").
>> > The reason to introduce the 4 hrs upper limit in the algorithm is that
>> > many networks use the default valid lifetime value, which is 30 days.
>> > So w/o 4 hrs limit the host would schedule the very first refresh in
>> > 24 days, which makes the refresh useless.
>> > Basically that X (X= 4) hrs shall be comparable with how long a client
>> > would stay connected.
>> >
>> > I think adding something to the text that makes it clear that when a
>> refresh expires, it is not automatically rescheduled. Only a PIO can
>> reschedule (or initiate a new one). I still had the old model in mind and
>> the statement "The client MUST periodically refresh addresses” implies
>> periodicity and rescheduling when refresh expires?
>> >
>> >
>> > How about "The client MUST periodically refresh addresses using the
>> > logic described below"?That would clearly indicate how the refreshes
>> > shall be scheduled,
>> >
>> >
>> > On Aug 11, 2023, at 5:17 PM, Jen Linkova <[e-mail]> wrote:
>> >
>> >
>> > On Fri, Aug 11, 2023 at 1:04 PM Bernie Volz <[e-mail]> wrote:
>> >
>> >
>> > Hum … there’s still one case that concerns me … so I’m going to shot a
>> hole in the algorithm.
>> >
>> >
>> > If the lifetime is 2h and not being extended, a refresh will occur at
>> 0.8*2h = 96 min, now lifetime that remains is 24 min, so refresh happens at
>> 19.2 min with 4.8 min left, then again at 230 sec … so, refresh come very
>> often while lifetime is running down (such as when a prefix is being
>> deprecated).
>> >
>> >
>> > Oh, what you found is not a hole in the algorithm, but us being lazy at
>> wording.
>> >
>> > We did spend some time thinking about that case and explicitly made
>> >
>> > sure hosts DO NOT send updates more and more often,  but we didn't
>> >
>> > phrase it properly in the text ;(
>> >
>> > The idea behind "the refresh is scheduled when the address becomes
>> >
>> > valid (== created) and after that - ONLY when an RA is received. We
>> >
>> > phrased it as "the host updates the Valid Lifetime of an existing
>> >
>> > address" - so yes, the text kind of covers "counting a lifetime down
>> >
>> > in an absence of RA" but it wasn't the intention.
>> >
>> >
>> > Thank you for pointing this out.
>> >
>> >
>> > How about:
>> >
>> >
>> > "The client MUST periodically refresh addresses. Each refresh is
>> >
>> > scheduled after AddrRegRefresh seconds, where AddrRegRefresh is min(4
>> >
>> > hours, 80% of the address's current Valid Lifetime). Refreshes SHOULD
>> >
>> > be jittered by +/- 10% to avoid synchronization.
>> >
>> >
>> > Whenever the client creates an address or receives an RA which updates
>> >
>> > the Valid Lifetime of an existing address, then:
>> >
>> > 1. If no refresh is currently scheduled, it MUST register immediately
>> >
>> > and schedule a refresh.
>> >
>> > 2. If a refresh is currently scheduled, it MUST reschedule the
>> >
>> > existing refresh if this would result in the refresh being sooner than
>> >
>> > currently scheduled.
>> >
>> > "
>> >
>> >
>> >
>> > I wonder if solution is to schedule refreshes every min(lifetime, 4
>> hours). And for client to track lifetime remaining at server and when the
>> lifetime is extended (via PIO), client reschedules refresh if server’s
>> remaining lifetime is less than 0.8 * min(server’s remaining lifetime,
>> currently scheduled refresh time) and reschedules for that 0.8*min…?
>> >
>> >
>> > Note that refresh when lifetime is 0 means to notify server address is
>> no longer in use (or just leave it as server will expire anyway).
>> >
>> >
>> > Note that client cannot just use its lifetime in the extended lifetime
>> case as there could have been several extended lifetimes since last time
>> server was refreshed; hence important to track what server has.
>> >
>> >
>> > With your earlier case:
>> >
>> >
>> > t=0 receive RA with lifetime 10m ==> schedule refresh at t=10m
>> >
>> > t=9 receive RA with lifetime 10m ==> client determines refresh needed
>> at 0.8*min(1m, 1m)=48sec
>> >
>> >
>> > t=9:48 client refreshes registration
>> >
>> >
>> >
>> > We could be more agressive and use 0.5 (renewal) factor here instead of
>> 0.8 (rebinding). That would send the refresh at 9:30.
>> >
>> >
>> > This probably falls apart for ultra short lifetimes (i.e., ~60 seconds
>> or less).
>> >
>> >
>> > - Bernie (from iPad)
>> >
>> >
>> > On Aug 11, 2023, at 10:38 AM, Bernie Volz <[e-mail]> wrote:
>> >
>> >
>> > Let’s go with your algorithm unless someone can come up with a
>> situation where this doesn’t work.
>> >
>> >
>> > Regarding minimum times, that’s a more difficult situation. Perhaps
>> there’s something useful in what Michael pointed out to refresh things when
>> there is traffic (keeping NCE entry hot)? Especially when a registration
>> server previously replied indicating that it is using the information … and
>> this should result in a single packet/client most times.
>> >
>> >
>> > If specified, you need to make it clear that minimum lifetime is for
>> registration purposes ONLY.
>> >
>> >
>> > And perhaps use of this mechanism should be discouraged when short
>> lifetimes are in use on a network? If DHCPv6 is otherwise not in use, then
>> not setting O (and M) bit is administratively something to recommend. If
>> DHCPv6 address assignment is used, one would assume that DHCPv6 lifetimes
>> are short too, then having these transmissions is no different that what
>> DHCPv6 would see (actually, it will be less as they are coming at 0.8 the
>> valid lifetime instead of RENEWs at 0.5 the preferred lifetime).
>> >
>> >
>> > And if you’re using short lifetimes, there will be frequent RA
>> transmissions (while these me be multicast, they might not be). So, you’re
>> already paying penalties (such as battery life) for that.
>> >
>> >
>> > - Bernie (from iPad)
>> >
>> >
>> > On Aug 10, 2023, at 6:20 AM, Bernie Volz <[e-mail]> wrote:
>> >
>> >
>> > I do think that reconsidering the refresh when extending is the proper
>> way to go … I had been trying to see if that could be avoided but it
>> obviously cannot be. I think you may have a good algorithm in what you sent
>> but will think a bit more on it.
>> >
>> >
>> > - Bernie (from iPad)
>> >
>> >
>> > On Aug 10, 2023, at 6:01 AM, Lorenzo Colitti <[e-mail]>
>> wrote:
>> >
>> >
>> > 
>> >
>> > On Tue, Aug 8, 2023 at 1:12 AM Bernie Volz <[e-mail]> wrote:
>> >
>> >
>> > Well this would make this even more useless than it currently is as
>> even devices that are using an address and were reporting may now not be in
>> cases where shorter lifetimes are in use.
>> >
>> >
>> > The -00/01 text was:
>> >
>> >
>> > The client MUST refresh the registration every AddrRegRefresh seconds,
>> where AddrRegRefresh is min(1/3 of the Valid Lifetime filed in the very
>> first PIO received to form the address; 4 hours ).
>> >
>> >
>> > And I don’t recall any WG discussion to reduce this as you’ve proposed
>> … though we are discussing it now.
>> >
>> >
>> >
>> > Ah, yes. My mistake, I misread the min.
>> >
>> >
>> >
>> >
>> > The client MUST refresh the registration every AddrRegRefresh seconds,
>> where AddrRegRefresh is min(0.8 of the Valid Lifetime and 4 hours).
>> However, the client MUST NOT send a refresh when this timer expires unless
>> the Valid Lifetime was extended since the last registration or the Valid
>> Lifetime is greater than 5 hours.
>> >
>> >
>> >
>> > I think this algorithm does not work in corner cases like the following:
>> >
>> >
>> > t=0 receive RA with lifetime 10m ==> schedule refresh at t=8m
>> >
>> > ... no RAs received
>> >
>> > t=8m ==> client does not refresh because the lifetime was never extended
>> >
>> > t=9 receive RA with lifetime 10m ==> client does not schedule a refresh
>> >
>> > t=10 server believes address has expired, but actually it still has 9
>> minutes left.
>> >
>> >
>> > Jen and I spent a while thinking about various corner cases and came up
>> with the following. This seems simple to implement and robust. Thoughts?
>> >
>> >
>> > ==========
>> >
>> > The client MUST periodically refresh addresses. Each refresh is
>> scheduled after AddrRegRefresh seconds, where AddrRegRefresh is min(4
>> hours, 80% of the address's current Valid Lifetime). Refreshes SHOULD be
>> jittered by +/- 10% to avoid synchronization.
>> >
>> >
>> > Whenever the client creates an address or updates the Valid Lifetime of
>> an existing address, then:
>> >
>> > 1. If no refresh is currently scheduled, it MUST register immediately
>> and schedule a refresh.
>> >
>> > 2. If a refresh is currently scheduled, it MUST reschedule the existing
>> refresh if this would result in the refresh being sooner than currently
>> scheduled.
>> >
>> >
>> > Discussion: this algorithm ensures that refreshes are not sent too
>> frequently, while ensuring that the server never believes that the address
>> has expired when it has not. Specifically:
>> >
>> > - If the network never changes the lifetime, or stops refreshing the
>> lifetime, then only one refresh ever occurs. The address expires.
>> >
>> > - #1 ensures that any time the network changes the lifetime when no
>> refresh is scheduled, the server will be informed of the correct lifetime.
>> If the network does not change the address's lifetime, then the server
>> already knows the correct lifetime and no update needs to be sent.
>> >
>> > - #2 ensures that if the network reduces the lifetime of the address,
>> then the server will be informed of the new lifetime. If the network
>> increases the lifetime of the address, the refresh will be sent at the
>> previously scheduled time, and the server will be informed of the correct
>> lifetime. From this point on, either the address expires (and the server is
>> informed of when this will happen) or an RA increases the lifetime, in
>> which case a refresh will be sent.
>> >
>> >
>> > ==========
>> >
>> >
>> > I still think we need a minimum lifetime somewhere - if a router sends
>> PIOs with a lifetime of 3 minutes (and there are lots of home networks that
>> do this), then the device will be sending 4 packets every 2.4 minutes.
>> That's not terrible but it's still pretty bad for battery life.
>> >
>> >
>> > Can we say that networks that want to receive address registrations on
>> this SHOULD NOT use lifetimes less than, say, 10 minutes? Then we can say
>> that the client MAY ignore lifetimes less than 10 minutes and treat them as
>> if they were 10 minutes?
>> >
>> >
>> > Cheers,
>> >
>> > Lorenzo
>> >
>> >
>> > _______________________________________________
>> >
>> > dhcwg mailing list
>> >
>> > [e-mail]
>> >
>> > https://www.ietf.org/mailman/listinfo/dhcwg
>> >
>> >
>> >
>> >
>> > --
>> >
>> > SY, Jen Linkova aka Furry
>> >
>> >
>> >
>> >
>> > --
>> > SY, Jen Linkova aka Furry
>>
>>
>>
>> --
>> SY, Jen Linkova aka Furry
>>
>