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 :
>
> On Thu, 7 Oct 2021 02:52:13 +0200, Mike Fischer
> 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
