Bug 288426 - rtadvd ignores vlttime and pltime both in default and interface sections
Summary: rtadvd ignores vlttime and pltime both in default and interface sections
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 14.3-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-net (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-07-24 22:58 UTC by karl
Modified: 2025-11-14 02:55 UTC (History)
5 users (show)

See Also:


Attachments
Cause rtadvd to pick up the default vltime/pltime parameters w/o an address (836 bytes, patch)
2025-07-25 01:24 UTC, karl
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description karl 2025-07-24 22:58:08 UTC
Unless a specific address is specified in an interface section (which obviously would not be in the default section of the configuration file) pltime and vltime are ignored and the default values are always used.

For example the following file /etc/rtadvd.conf does nothing:

default:\
        :vltime=86400:\
        :pltime=3600: 
ix1:\
        :vltime=86400:\
        :pltime=3600:
ix1.4:\
        :vltime=86400:\
        :pltime=3600:

A trace on a SLACC-configured machine that gateway advertises routes to shows:
[root@NewFS ~]# tcpdump -v -i mce0 icmp6 and ip6[40] == 134
tcpdump: listening on mce0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

18:54:16.990562 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 56) fe80::2e0:b4ff:fe68:f895 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 56
        hop limit 64, Flags [none], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
          source link-address option (1), length 8 (1): 00:e0:b4:68:f8:95
          prefix info option (3), length 32 (4): 2606:83c0:8000:1b00::/64, Flags [onlink, auto], valid time 2592000s, pref. time 604800s

The configured values are ignored.

Most of the time this is an annoyance -- if your gateway gets a new delegation rtadvd will correctly and almost-immediately deprecate the old SLACC addresses your hosts have, so the impact is that their list of "old" (depreciated) address can get quite large however operation is not impacted.  Those MOST of the time this is an annoyance in that across reboots you have one deprecated address for each boot (if your delegation floats) or re-delegation event.

There is, however, one very bad circumstance impacting connectivity that can arise -- if the gateway running rtadvd is rebooted or crashes and then fails to get a delegation on restart the old IPv6 host addresses on ALL of your SLACC-configured hosts remain with valid routes and do not expire for an extremely long period of time.  The hosts will thus try to communicate on those addresses they obtained via SLACC but they go nowhere and this has a quite-serious network performance impact in that connection attempts (if IPv4 is available) will time out trying to reach IPv6 endpoints that are not accessible.  The only way to clear them is to (1) wait for the default vltime to expire, (2) manually delete them from each interface on each SLACC-configured host or (3) reboot all the SLACC configured hosts.

Mitigating this risk to a large degree could be done by setting both pltime and vltime to a reasonable period (e.g. 30 minutes and one hour respectively) and thus after an hour with no updated transmissions the advertised routes would thus expire.  However, with rtadvd ignoring the configuration directives there's no way to do this, and since you do not know the prefix or address in question for each interface until the delegation occurs there's no real fix unless you have an exit script edit that file and "kick" rtadvd each time delegations update.

This should not be necessary; if you specify a pltime and vltime they should be honored -- and in addition the man page specifically notes a "default:" interface entry that includes both the vltime and pltime parameters, thus effectively stating that they can be set there and then overridden for specific items (e.g. dns servers and suffixes)
Comment 1 karl 2025-07-25 01:24:54 UTC
Created attachment 262398 [details]
Cause rtadvd to pick up the default vltime/pltime parameters w/o an address

These few lines (the originals commented out) give the documented behavior except you do have to set it for each interface -- setting it in the "default" stanza does not set them.
Comment 2 Dmitrij Nexus 2025-09-01 17:29:19 UTC
(In reply to karl from comment #0)
As a temporary workaround administrators may run ndp -P <if> on affected hosts. This command flushes all the entries in the prefix list and forces a re-run of SLAAC on the interface, immediately removing obsolete IPv6 addresses and triggering reconfiguration from Router Advertisements. To automate this, a cron job can periodically run a simple connectivity test (for example a ping to a known IPv6 endpoint) and, if it does not complete within a reasonable time, execute ndp -P <if>. This avoids long periods with unreachable but still-valid addresses, although it requires manual or scripted execution and does not replace proper honoring of pltime/vltime settings in rtadvd.
Comment 3 karl 2025-09-01 17:39:37 UTC
(In reply to Dmitry Nexus from comment #2)
The patch I attached is running here and has been for over a month now with zero ill effects and all the expected and positive effects.

Ndp (and similar schemes) are of course usable on a FreeBSD box but that doesn't help the Android or Windows client machine..... :-)
Comment 4 Dmitrij Nexus 2025-09-01 18:04:56 UTC
(In reply to karl from comment #3)
Many thanks — great to see this fixed and working reliably. I had assumed everyone was running only FreeBSD :-)
Comment 5 karl 2025-09-01 18:06:27 UTC
(In reply to Dmitry Nexus from comment #4)
Well, it hasn't been picked up by anyone as far as I can tell in the codebase (never mind being MFC'd back) at least thus far.
Comment 6 karl 2025-09-29 16:12:46 UTC
Submitted as a pull request; been running here for ~2 months, no bad effects and all good ones as expected.