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.

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.

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
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

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

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.
 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