Hi Daniel! I didn’t know about ifstated(8) but reading the man page I get the impression that it only triggers on up/down events. And for other things it relies on polling, e.g. sending a ping packet somewhere every 10 seconds to test reachability.
The route monitor command seems somewhat more promising. Though I don’t know if it works event based internally or not. I have tested this as follows: I have a ULA prefix configured on my router. Yes I know, for a small network that is not really required. So my router actually advertises 2 prefixes to my clients: - The one from my provider (/56 changed to /64) - My ULA prefix, also expanded to a /64 prefix. Testing a provider prefix change is impractical because it happens fairly infrequently and I suspect they tear down the whole PPPoE session and have my router reconnect. (That would probably have side effects as outlined in RFC 8978 which would complicate matters.) So I decided to use changes to the ULA prefix to test this in a somewhat controlled way. 1) Start `route monitor` 2) Run `ifconfig em0|grep inet6` to get a baseline 3) Modify my ULA prefix on the router 4) Check the output of the `route monitor` command 5) Run `ifconfig em0|grep inet6` to get differences Results: - Indeed, when the ULA changes, `route monitor` on my host produces output. - The non-temporary IP using the old prefix still existed and was not marked in any way other than having very slightly lower pltime and vltime attributes (5s difference on ≈ 1 and 2 hours). - A new IPv6 address using the new prefix was added to the interface. Note that the IID was completely new, probably caused by the autoconf setting. Also, my test script configured in /etc/hostname.em0 as "!/root/bin/if_log.sh \$if“ does not trigger which confirms my theory that this only runs when /etc/netstart is executed. Which does not happen for prefix changes. The output of `route monitor` itself does not seem to be easily parseable for what I need. But that is secondary. At least I have a potential trigger mechanism. OTOH the route(8) command needs to kept running and I’m not so sure that is a great idea. Maybe polling myself would be easier after all? I repeated the experiment by changing the ULA prefix back to its original value. This again yielded `route monitor` output and the pltime/vltime differences where reversed while keeping all IPs. So provisionally my algorithm could look like this: - Wait for output from `route monitor`… (I would need to figure out, how to generate events from this output stream.) - Then run `ifconfig em0|grep inet6|grep -vE '(temporary|fe80:|deprecated|inet6 fd)‘|grep autoconf` which will yield all candidate IPs I’m interested in. - Figure out the correct one (by comparing the pltime/vltime values if there is more than one IP) - Extract the IPv6 IP from the line - Do my actions (update DNS, pf(4) table, etc.) using the IP. For some actions I might need to keep state in the form of the old IP to remove it. Anyway, thanks for your suggestions. Mike > Am 07.10.2021 um 04:34 schrieb Daniel Jakots <d...@chown.me>: > > On Thu, 7 Oct 2021 02:52:13 +0200, Mike Fischer > <fischer+o...@lavielle.com> wrote: > >> Would a IPv6 address prefix change be something the hotplug(4) / >> hotplugd(8) mechanism would see? > > It would rather be ifstated(8), but I don't think so. I've never looked > into this, but if I were, I would check the route(8) monitor command: > https://man.openbsd.org/route#monitor
