> Am 03.09.2024 um 04:51 schrieb Chris Ross <cross+openbsd@distal.com>:
>
>
>
>> On Sep 2, 2024, at 18:30, Mike Fischer <fischer+obsd@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
No comments:
Post a Comment