DHCPv6 ignores 'leasetime'

[perkelix]

version 9.4.1

dhcpcd.conf contains:

allowinterfaces enp4s0
require domain_name_servers
slaac private
leasetime 7200
timeout 0
reboot 0
noipv6rs
noarp
duid
waitip 4 6
interface enp4s0
  ipv6rs
  ia_ta 0
  ia_pd 0 br0

The requested leasetime is granted by the ISP for DHCPv4:

enp4s0: leased X.X.X.X for 7200 seconds

However, this has no effect for DHCPv6 with prefix delegation:

enp4s0: renew in 1800, rebind in 2880, expire in 3600 seconds

I realize that IPv6 works differently and instead receives T1 and T2 via RA. However the manual page doesn't document ways of requesting specific T1 and T2 values for IPv6.

The problem is that if lifetime is less that 7200 seconds, the prefix information option is supposed to be ignored as per RFC4862 5.5.3.e.2. Android phones conform to this and drop the IPv6 connection if the prefix changes before a minimum of 2 hours. This results in my phone connected to a WiFi router running dhcpcd on the WAN side losing its IPv6 connection in a systematic way.

It also appears that dhcpcd PD gives br0 3600 for both T1 and T2, yet 2880 would have been expected for preferred_lft, and 3600 for valid_lft.

[rsmarples]

This is because DHCPv6 has no leasetime or any specific timers. Instead the addresses the message contains has the timers which effectively makes them address specific. This makes it challenging to define a leasetime for DHCPv6.

RFC4862 5.5.3.e.2. just talks about ignoring the valid time to avoid a DoS attack to remove the address. I will look into implementing this.

[perkelix]

Understood, but dnchcp does receive different timers for preferred and valid lifetimes, yet it delegates the same value for both:

heinä 29 12:52:56 p8h61 dhcpcd[593]: enp4s0: REPLY6 received from fe80::bb heinä 29 12:52:56 p8h61 dhcpcd[593]: enp4s0: renew in 1800, rebind in 2880, expire in 3600 seconds

In this case, it delegated 3600 seconds for both values. I might misunderstand how this is supposed to work, but I would have expected 3600 for valid_lft and 2880 for preferred_lft.

[rsmarples]

Why not examine the message with tcpdump or wireleshark. I'm willing to bet that both T1 and T2 have the same value.

[rsmarples]

I have addressed RFC 4862 5.5.3.e in 41b8ff09 so this can now be closed.

[perkelix]

This is of course a useful addition, except that the request was not for dhcpcd to implement that. It rather was about figuring out a way to avoid Android clients connecting to a host that gets a prefix from dhcpcd constantly losing their IPv6 route because of Android's pedantic implementation of said RFC.

[rsmarples]

Ah so you want to force Delegated Prefixes to have a configurable minimum valid lifetime to satisfy RFC incompliant downstream hosts?

[perkelix]

Yes, that would be the idea.

In my particular case, the ISP's RA gives 3600 seconds of valid_lft, but Android's broken implementations of the above RFC apparently drops the IPv6 route completely once the lifetime has depleted, if it's less than 7200 seconds, presumably because dhcpcd renews the lease and resets the lifetime before 7200 seconds has elapsed.

• One solution could be to always delegate at least 7200 seconds.
• Another solution could be to configure it to a multiple of the lifetime received from upstream e.g. 2 times RA -provided lifetime.

In both cases, I would avoid setting the same value for valid_lft and preferred_lft, since doing so results in a momentary complete loss of IPv6, instead of giving clients a window to transition to a new prefix if needed.

One path toward the later could be to use the rebind time, if upstream provides the same value for valid_lft and preferred_lft. In my own case, as shown above, RA gave 3600, 2880, 1800 seconds. I would have thus expected 2880 to be the preferred_lft.

[perkelix]

Returning to this issue, I cannot help but notice that, even though we receive different RA values for T1 and T2, dhcpcd delegates what it got as T2 for both.