From: Florian Obser Subject: Re: rad(8): track vltime / pltime for "auto prefix"es To: tech@openbsd.org Date: Fri, 24 May 2024 11:16:36 +0200 On 2024-05-23 13:20 -07, Ryan Vogt wrote: > On Mon, May 20, 2024 at 12:16:33PM +0000, Florian Obser wrote: >> Prefixes delegated via DHCPv6 have a lifetime, honour it. >> >> The "auto prefix" feature derives the prefix to announce from a >> configured IPv6 address. If that address has a vltime / pltime use >> that value in router advertisements instead of statically configured >> values. >> >> We also need to count down the vltime / pltime as time progresses. >> >> This is on top of "rad(8): reduce calls to getifaddrs(3)" and also needs >> "send RTM_CHGADDRATTR for vltime / pltime changes" to work correctly. > > Hi, I have a question about the intended behaviour of this patch in a > few cases, which I've outlined below. If the behaviour I see with this > patch is the intended behaviour, I've suggested a few sentences for > the rad.conf(5) man page that describes the behaviour. > > Very short version: are the "preferred lifetime" and "valid lifetime" > options in rad.conf always ignored for any prefix that's delegated, > *regardless* of their values in rad.conf? > > Longer version: > > To set up our situation, I have rad(8) running on igc1. On igc1, I > have a static prefix, and a prefix delegated from DHCPv6 (dhcpcd > running on igc0): > > $ ifconfig igc1 > [...] > inet6 fe80::bbbb:bbbb:bbbb:bbbb%igc1 prefixlen 64 scopeid 0x2 > inet6 fdaa:aaaa:aaaa:1::1 prefixlen 64 > inet6 2001:db80:eeee:eeee::1 prefixlen 64 pltime 103481 \ > vltime 103481 > > The fdaa:... prefix is static, and the 2001:... prefix is delegated by > my ISP. > > Here are 4 cases. The first 2 cases are just to set the stage, and > I'll come back to that question about values in rad.conf(5) in cases 3 > and 4. > > 1) For the first case, I've set up rad.conf(5) to look like the following: > > interface igc1 { > auto prefix > } > > With the patch applied, my clients receive router-advertisement > messages from rad(8) with the following prefix info options. > > - fdaa:aaaa:aaaa:1::/64 with valid time 5400, pref. time 2700 > - 2001:db80:eeee:eeee::/64 with valid time 103481, > pref. time 103481 > > This is clearly the intended behaviour -- the default values in > rad.conf for "preferred lifetime" and "valid lifetime" for the > delegated prefix are overridden with the DHCPv6-provided values. > yes > 2) For the second case, I'll modify rad.conf(5) to include some very > large lifetimes: > > interface igc1 { > auto prefix { > preferred lifetime 150000 > valid lifetime 200000 > } > } > > My clients now receive the following prefix info options: > > - fdaa:aaaa:aaaa:1::/64 with valid time 200000, > pref. time 150000 > - 2001:db80:eeee:eeee::/64 with valid time 103481, > pref. time 103481 > > Also clearly the intended behaviour -- and, what I think is the most > important effect of the patch. For the delegated prefix, the valid and > preferred lifetimes are *reduced* from the large values in rad.conf to > the values given by my ISP, so rad doesn't send prefix info with too- > long lifetimes. > yes > 3) But, for the third case, let's change up rad.conf(5) again: > > interface igc1 { > auto prefix { > preferred lifetime 500 > valid lifetime 1000 > } > } > > Now, my clients receive a router advertisement message that contains > these two prefix info options: > > - fdaa:aaaa:aaaa:1::/64 with valid time 1000, pref. time 500 > - 2001:db80:eeee:eeee::/64 with valid time 103481, > pref. time 103481 > > This time I'd like to verify -- is this the intended behaviour of the > patch? If so, I've proposed an addition to the rad.conf(5) man page No, this limitation occurred to me as well a few days after I had send the patch. The configured lifetime should be an upper limit. I have not found an easy way yet on how to do this in rad(8). I was also considering of letting the dhcpv6 client handle this, but it does not seem like dhcpcd lets us put a limit on the lifetimes it configures. There is also RFC 9096 to consider. Long story short, I need to figure out how to do this better in rad(8). > below, because it differs from my intuition of what this rad.conf > would have done (if I hadn't read the patch itself, that is). > > My intuition would have been that the 500-second preferred and 1000- > second valid lifetimes in rad.conf would be upper bounds on the > preferred and valid lifetime in rad's router advertisement messages -- > values that would only be lowered if my delegated lifetimes were too > short (as in case 2). That is, I would have (wrongly) expected that my > clients would receive: > > - fdaa:aaaa:aaaa:1::/64 with valid time 1000, pref. time 500 > - 2001:db80:eeee:eeee::/64 with valid time 1000, > pref. time 500 > correct, that should happen. > 4) The fourth case is an extension of the third case, with a more- > explicit rad.conf. Here's an rad.conf that someone with an > essentially-static delegation from their ISP could use (I'm not so > lucky): > > interface igc1 { > prefix fdaa:aaaa:aaaa:1:: { > preferred lifetime 2000 > valid lifetime 3000 > } > prefix 2001:db80:eeee:eeee:: { > preferred lifetime 4000 > valid lifetime 5000 > } > } > > The behaviour with the new patch is that clients receive the following > prefix info options from rad: > > - fdaa:aaaa:aaaa:1::/64 with valid time 3000, pref. time 2000 > - 2001:db80:eeee:eeee::/64 with valid time 103481, > pref. time 103481 > I don't think this actually happens, if you are not configuring an auto prefix rad(8) does not look at prefixes, does it? if (ra_iface_conf->autoprefix) get_interface_prefixes(ra_iface, ra_iface_conf->autoprefix, ifap); I think you should get this: - fdaa:aaaa:aaaa:1::/64 with valid time 3000, pref. time 2000 - 2001:db80:eeee:eeee::/64 with valid time 5000, pref. time 4000 > Here, I have the same observation about the behaviour as in case 3. If > this is the intended behaviour, might I suggest a change to the man > page to make the behaviour clearer? > > diff --git a/rad.conf.5 b/rad.conf.5 > index 87c2b32..ccb5ba4 100644 > --- a/rad.conf.5 > +++ b/rad.conf.5 > @@ -166,10 +166,14 @@ The default is yes. > .It Ic preferred lifetime Ar seconds > The preferred lifetime (pltime) in seconds for addresses generated from this > prefix. > +This option will be ignored if the prefix has a delegated preferred lifetime > +from a DHCPv6 server. This option will be ignored for auto prefixes that have a preferred lifetime configured. Or something like that. We need to get "auto prefixes" in somehow. To bad my sentences drops "DHCPv6 server". Anyway, maybe shelf the documentation diff for now and I'll try to fix this in rad(8) first, then we need to change the documentation anyway. > The default is 2700. > .It Ic valid lifetime Ar seconds > The valid lifetime (vltime) in seconds for addresses generated from this > prefix. > +This option will be ignored if the prefix has a delegated valid lifetime from > +a DHCPv6 server. > The default is 5400. > .El > .Sh FILES > -- In my defence, I have been left unsupervised.