[FEATURE REQUEST] Option "auto" for AdvValidLifetime and AdvPreferredLifetime

[bmeirellesRJ]

Hi friends,

If possible, add the option "auto" for AdvValidLifetime and AdvPreferredLifetime.

this option is intended for use with dynamic prefix with short lease time assigned by some providers or connectivity issues

This option should read the time assigned to the ip by the dhcpv6 client and updated whenever the lease is renewed

to be used with the "deprecated prefix on" and "decrement lifetimes on" options

Thanks

[robbat2]

Can you expand on the intended behavior please?

• How should radvd identify which IP was assigned by DHCPv6 client? By client, by interface, some other way?
• Does this matter if there are multiple different links? (e.g. getting different RAs on different links on the host)
• Does it require integrations with specific DHCPv6 clients? Which clients?
• what logic should that auto have for lifetime values?
• DecrementLifetimes on should already cap the lifetimes to whatever is present on the system, so how does your request differ from that?
• AdvValidLifetime & AdvPreferredLifetime are prefix-specific options, and if your prefix is very dynamic, are you using the special prefix of ::/64 or some other scheme? (e.g. Ubiquiti edgerouters rewrite the radvd config).

[bmeirellesRJ]

How should radvd identify which IP was assigned by DHCPv6 client? By client, by interface, some other way?

radvd is capable of listening to interface and address changes.
https://github.com/radvd-project/radvd/blob/master/netlink.c#L210

Does this matter if there are multiple different links? (e.g. getting different RAs on different links on the host)

Only when it is set to "auto"

Does it require integrations with specific DHCPv6 clients? Which clients?

Not. It should work with everyone, because it's based on interface changes. The dhcp6-client only add/change/renew/remove the address.

what logic should that auto have for lifetime values?

Whenever radvd detects that the ip has been added, it will take the prefix and time and announce it. If dhcpv6-client renews with the same ip, it will announce the same prefix with the new times. If the ip is changed, it will stop announcing the old prefix and announcing the new prefix with the new time

DecrementLifetimes on should already cap the lifetimes to whatever is present on the system, so how does your request differ from that?

Yes, but it is not easy to configure. If it's too short it stops working. If it's too long the devices get too many addresses when the prefix changes and some stop working. Even configuring it right, if the telecom company changes, it stops working

AdvValidLifetime & AdvPreferredLifetime are prefix-specific options, and if your prefix is very dynamic, are you using the special prefix of ::/64 or some other scheme? (e.g. Ubiquiti edgerouters rewrite the radvd config).

I'm using ::/64. dhcpv6-client rewriting the radvd.conf file and restarting the service is an inelegant solution

hugs

[Neustradamus]

@systemcrash, @Noltari. @Alphix: What do you think about this radvd issue?