> Am 03.09.2024 um 04:51 schrieb Chris Ross <cross+open...@distal.com>:
> 
> 
> 
>> On Sep 2, 2024, at 18:30, Mike Fischer <fischer+o...@lavielle.com> wrote:
>> 
>> To my knowledge there is no mechanism or hook to trigger when the public 
>> IPv6 prefix changes. (It would be nice to have such a mechanism though.)
> 
> Yeah.  I see rtsold has a couple scripts it knows how to run, so that is a
> place.  But having a hook in slaacd(8) (or somewhere else?) would be nice.
> Heck, I’d love to be able to configure “these are my IIDs for this interface”
> in a conf file.  That would be a little mixed between “autoconfiguration”
> and manual though I guess.
> Please speak up if you also think it would be valuable to have slaacd
> configuration for either multiple IIDs for an interface, or a hook script
> to be called when receiving and applying a RA.

There are two parts to this:
- The IPv6 prefix.
- The IID.

The changes of the IPv6 prefix are generally triggered from the outside 
(Internet provider). So here some mechanism to notify about changes would be 
nice.

Note that I am not advocating for slaacd to directly execute arbitrary scripts. 
But maybe an (optional) service that can be notified by slaacd would allow 
slaacd to stay secure, stable and compact while still providing proactive 
notification instead of polling might fit the bill.

The IID is controlled by the host. Currently the only combination of automatic 
prefix + static IID seems to be EUI64 IIDs. Additional syntax to allow manually 
set static IIDs might be nice. Something like: `ifconfig $if inet6 autoconf 
-iid aaaa:bbbb:cccc:dddd` which would imply -temporary -soii. And the same for 
alias addresses.


> 
>> The following (adjust for your interface) is one way to extract the current 
>> public IPv6 prefix:
>> $interface='em0'
>> slaacctl show interface "$interface" \
>> | grep 'prefix:' \
>> | grep -v 'prefix: fd' \
>> | cut -d' ' -f2 \
>> | awk -F'::/' '{print substr($1,1,19)}'
> 
> I think this will not work when the network changes.

Not sure what you mean by "the network changes“? Are you talking about the IPv6 
prefix? If so it does work. I am using this in my setup to update DDNS for IPv6 
hosts on a dynamic IP Internet connection.


>  Right now I see
> two matches for that, one from the router I’m building which is getting
> its IPv6 from a different location than the prior/current gateway.
> I have the “new” network from that advertisement last night, with a
> lifetime of 0.

Are you talking about a situation where multiple RAs from different routers 
reach your host? That would take additional handling as that would lead to your 
host having multiple (public/routable) IPv6 addresses with different prefixes. 
I have not seen such a setup and have not thought about how to handle that. 
Should be possible though.

I my case I also get an RA for a ULA prefix I have configured on my LAN. But 
that is filtered with the `grep -v 'prefix: fd'` line (though it could be 
improved to also filter fc… as the range is officially fc00::/7). Maybe `egrep 
-v 'prefix: f(c|d)'` (untested) might work?


> With some effort, I could write something to parse
> slaacctl output with more thought.  But, I’m not wholly sure I’d be
> able to know enough about what the possible outputs mean.

The main issue I see with multiple public/routable prefixes would be to decide 
what to do with them. E.g. updating DDNS would need to choose one hostname for 
each prefix/address. But how would you identify which one goes with which 
prefix? The same goes for services that are supposed to run on a specific 
uplink only. How do you identify the upping based on the prefix? That would 
require more elaborate parsing of the slaacctl output, maybe based on the IID 
of the advertising router.

For me this all speculation as I don’t have such a setup. And maybe I 
misunderstood your situation?

If I understand your situation correctly, you are implementing your new setup 
in parallel to the old one? So you have the old router advertising a static 
prefix and the new router advertising a different dynamic prefix?

What does `slaacctl show interface $if` output look like in that case? Do you 
get two separate »Router Advertisement from …« sections?

That would lead to multiple prefixes being reported by:
$interface='em0'
slaacctl show interface "$interface" \
| grep 'prefix:' \
| egrep -v 'prefix: f(c|d)' \
| cut -d' ' -f2 \
| awk -F'::/' '{print substr($1,1,19)}'

In your case you could probably easily identify your static prefix and make 
choices based on that. But for the general case choosing what to do with each 
prefix gets much harder.


> 
>> If you have static Interface IDs (IIDs, the lower 64 bits of the IPv6 
>> address) then once you have determined that your prefix has changed you can 
>> trigger actions such updating DDNS, reconfiguring services listening on a 
>> specific public IPv6 address, etc.
>> 
>> I use this in my /etc/hostname.if files to get a static IID with the current 
>> public IPv6 prefix:
>> inet6 autoconf -temporary -soii
>> This generates an EUI64 IID based on the MAC address.
> 
> I only have “inet6 autoconf” for the same purpose.  Then, after sleeping
> a few seconds, a couple of “inet6 alias” lines for the static secondary
> addresses.

But isn’t this the same situation you have now with the only difference being 
the frequency of the prefix changes? As soon as you use autoconf, you 
potentially have changing prefixes.

How did you choose the alias addresses? Manually or based on the addresses set 
by autoconf? With just autoconf without -temporary -soii you will get multiple 
temporary IPv6 addresses for the prefix. Even if your prefix never changes, the 
IIDs will.

Note: autoconf gets you additional data as well, such as MTU, DNS, etc. So it 
is probably a good idea to have autoconf in there at some place even if you 
don’t plan to actively use the IPs it suggests.


> But, of course, that only works for the historic static
> IPv6 network I am moving away from.

Depends on the answer to the above question ;-) In theory the frequency of 
prefix changes should not make any difference to the overall mechanism.


Just complicate things even more, how do you handle routing? If your host gets 
multiple public/routable prefixes, your default route will still point to only 
one of the routers. So might need to deal with incoming packets from router A 
sending responses to router B?


Mike

Reply via email to