|Summary:||net/dhcp6: dhcp6c discards lifetime from delegated prefix when configuring interface(s).|
|Product:||Ports & Packages||Reporter:||mickey242|
|Component:||Individual Port(s)||Assignee:||Hiroki Sato <hrs>|
|Status:||In Progress ---|
|Severity:||Affects Some People||CC:||leres|
Description mickey242 2019-03-06 13:31:12 UTC
Created attachment 202651 [details] Fix to apply the lifetime of the delegated prefix to the target interface(s). When doing prefix delegation dhcp6c discards the lifetime from the delegated prefix when configuring the target interface(s) and uses an infinite lifetime instead.
Comment 1 Hiroki Sato 2019-03-06 19:23:51 UTC
Can you describe your problem with dhcp6c setting the prefix's lifetime to infinity? dhcp6c intentionally sets lifetime of the delegated prefix on the in-kernel prefix list to infinity and creates an expiration timer based on the prefix's lifetime to prevent the kernel from removing the prefix. It does not simply discard the lifetime from the delegated prefix because dhcp6c is responsible to remove the prefix when expired.
Comment 2 mickey242 2019-03-07 11:05:18 UTC
A prefix that has been leased by means of dhcp comes with a lifetime by definition. In my case I get a new dynamic prefix every 24 hours with the leases having a lifetime of a little over 2 days. Given the fact that there is already a mechanism in place to propagate this lifetime to the subprefixes assigned to the interfaces, it just doesn't seem right not to so and thereby give other components (i.e. rtadvd) access to the real prefix lifetime instead of one that was completely made up. Also I do not see a problem here, as dhcp6c is still responsible for either renewing the lease or removing the prefixes in time, before the lease expires.
Comment 3 Hiroki Sato 2019-03-17 09:44:50 UTC
(In reply to mickey242 from comment #2) Having two or more timeout handlers independently in the kernel and the dhcp6c daemon will cause a race condition. dhcp6c cannot know that the kernel accidentally removes a prefix due to the lifetime expiry. This can happen because counting down is not synchronized between kernel and dhcp6c. Just setting the kernel one to infinity and managing timer expiry in dhcp6c is the design choice to avoid it. One practical scenario where infinity causes a problem is that the prefix will never be removed if dhcp6c becomes down. However, there still is no good reason to set in-kernel prefix lifetime exactly to the value which is obtained by DHCP when dhcp6c is actively dealing with the expirations. Setting 2x of the lifetime would be safer, for example. > Given the fact that there is already a mechanism in place to propagate this lifetime to the subprefixes assigned to the interfaces, it just doesn't seem right not to so and thereby give other components rtadvd(8) does not redistribute the in-kernel lifetime value for this reason. Propagation of timer values does not work in general because of the synchronization problem.
Comment 4 mickey242 2019-03-17 18:55:15 UTC
(In reply to Hiroki Sato from comment #3) I do understand the problem with the possible race condition of timer expiry. However dhcp6c should not wait until the leased prefix becomes invalid (because expired) before it renews the lease. It should rather renew a while before the expiration time, possibly including room for retries, should the first renew attempt fail. Having something like 2x lease time would in my opinion still be the better choice than infinity. rtadvd(8) is another story in itself. Current implementation just uses a default prefix lifetime of ~30 days with no option whatsoever to reduce that lifetime to something more sensible, at least not if you don't happen to have the luxury of static prefixes. Without statically configured prefixes in rtadvd.conf, rtadvd will just ignore each and every setting regarding the lifetime completely. In my situation this causes a large number of deprecated prefixes to accumulate on every machine connected to the network, as the prefix is dynamic and changes every 24 hours.