Why can the lifetimes reported by ip address be slightly higher than the content of a received IPv6 Router Advertisement?

I'm currently investigating a strange network issue. Consider the following IPv6 Router Advertisement (note the **prefix lifetimes**, 5400 and 2700, respectively.):

$ rdisc6 -1 wlan0
Soliciting ff02::2 (ff02::2) on wlan0...

Hop limit                 :           64 (      0x40)
Stateful address conf.    :          Yes
Stateful other conf.      :          Yes
Mobile home agent         :           No
Router preference         :       medium
Neighbor discovery proxy  :           No
Router lifetime           :         1800 (0x00000708) seconds
Reachable time            :      3600000 (0x0036ee80) milliseconds
Retransmit time           :  unspecified (0x00000000)
 Recursive DNS server     : 2a02:####:####:####:f2af:85ff:fe11:70d
  DNS server lifetime     :          300 (0x0000012c) seconds
 Prefix                   : 2a02:####:####:####::/64
  On-link                 :          Yes
  Autonomous address conf.:          Yes
  Valid time              :         5400 (0x00001518) seconds
  Pref. time              :         2700 (0x00000a8c) seconds
 Route                    : 2a02:####:####:####::/62
  Route preference        :       medium
  Route lifetime          :         5400 (0x00001518) seconds
 Route                    : ::/0
  Route preference        :       medium
  Route lifetime          :         1800 (0x00000708) seconds
 Source link-layer address: ##:##:##:##:##:##
 from fe80::f2af:85ff:fe11:70d

I have observed that the lifetimes reported for one particular address are sometimes slightly *higher* than the values in the router advertisement. inet6 2a02:####:####:####:2f89:f9d2:504f:595d/64 (...) valid_lft 5401sec preferred_lft 2701sec (This output is handcrafted. I cannot get a live capture right now because of the network issue I'm ultimately trying to solve, but it is representative of how the lifetimes can be **a second or so higher** than the RA value.) Why would that be? I'm currently considering whether this is a possible bug in the network stack that is used in Debian (12), because I'm also observing the following: This is a router advertisement with both prefix lifetimes set to 0, and as far as I understand, this is not an error, but the router is deliberately trying to invalidate that prefix.

$ rdisc6 -1 wlan0
Soliciting ff02::2 (ff02::2) on wlan0...

Hop limit                 :           64 (      0x40)
Stateful address conf.    :          Yes
Stateful other conf.      :          Yes
Mobile home agent         :           No
Router preference         :       medium
Neighbor discovery proxy  :           No
Router lifetime           :         1800 (0x00000708) seconds
Reachable time            :      3600000 (0x0036ee80) milliseconds
Retransmit time           :  unspecified (0x00000000)
 Recursive DNS server     : 2a02:####:####:####:f2af:85ff:fe11:70d
  DNS server lifetime     :          300 (0x0000012c) seconds
 Prefix                   : 2a02:####:####:####::/64
  On-link                 :          Yes
  Autonomous address conf.:          Yes
  Valid time              :            0 (0x00000000) seconds
  Pref. time              :            0 (0x00000000) seconds
 Route                    : ::/0
  Route preference        :       medium
  Route lifetime          :         1800 (0x00000708) seconds
 Source link-layer address: ##:##:##:##:##:##
 from fe80::f2af:85ff:fe11:70d

In this case, the preferred_lft reported by ip address *also* varies by 1 second (while the valid_lft just seems to tick down normally from 5400s in real-time). In practice, when I spam ip address, preferred_lft periodically toggles between 1s and 0s. Furthermore, ip monitor outputs this about every few seconds:

2: wlan0    inet6 2a02:####:####:####:2f89:f9d2:504f:595d/64 scope global dynamic noprefixroute
       valid_lft 4916sec preferred_lft 1sec
2: wlan0    inet6 2a02:####:####:####:2f89:f9d2:504f:595d/64 scope global deprecated dynamic noprefixroute
       valid_lft 4915sec preferred_lft 0sec
2: wlan0    inet6 2a02:####:####:####:2f89:f9d2:504f:595d/64 scope global dynamic noprefixroute
       valid_lft 4913sec preferred_lft 1sec
2: wlan0    inet6 2a02:####:####:####:2f89:f9d2:504f:595d/64 scope global deprecated dynamic noprefixroute
       valid_lft 4912sec preferred_lft 0sec
(and so on)

This also causes severe /var/log/syslog spam:

2023-12-19T19:22:15.143458+01:00 ... avahi-daemon: Registering new address record for 2a02:####:####:####:2f89:f9d2:504f:595d on wlan0.*.
2023-12-19T19:22:16.181261+01:00 ... avahi-daemon: Withdrawing address record for 2a02:####:####:####:2f89:f9d2:504f:595d on wlan0.
2023-12-19T19:22:18.011506+01:00 ... avahi-daemon: Registering new address record for 2a02:####:####:####:2f89:f9d2:504f:595d on wlan0.*.
2023-12-19T19:22:19.240632+01:00 ... avahi-daemon: Withdrawing address record for 2a02:####:####:####:2f89:f9d2:504f:595d on wlan0.
(and so on)

This behavior is certainly unwanted. The arbitrary addition of a small value to the preferred lifetime in the router advertisement could explain this partly. I was able to observe this on Debian 12 and Raspberry Pi OS. I was **not** able to observe this on Arch Linux and Lubuntu. Tested on 3 different devices. *However, tests may not be conclusive* because I cannot control my router, and it does not always send the same router advertisements, and I do not have an isolated test environment.