> On Sep 3, 2024, at 10:28, Mike Fischer <[email protected]> wrote:
>
> 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.
Yup. I can totally see the point of not wanting a script for both security and
sanity. The other suggestions above look reasonable and interesting.
>> 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.
I did mean the prefix/network being advertised.
> 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.
No, no. Sorry if this became unclear. I am talking about what you presumed, a
single router advertising a single prefix, but that could/would change.
I do see two prefixes, from different routers. But, they were not both active
at the same time. One went away, and should’ve deprecated the network. I
presumed the same would happen with a change of RA from the same router. That
it would deprecate the old one and provide a new one. So, I would expect to
see the same thing I’m seeing now. Perhaps it’s not the same, and changing
addresses from a single router LL address doesn’t work the same way.
>
> For me this all speculation as I don’t have such a setup. And maybe I
> misunderstood your situation?
Yes, but only because I didn’t provide enough information. :-)
> 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?
In parallel as in switching back and forth, but not ever having them
active/active (or even active/standby really. More like a cold spare)
> What does `slaacctl show interface $if` output look like in that case? Do you
> get two separate »Router Advertisement from …« sections?
What I’m seeing now is three “Router Advertisement from” from three different
LL addresses on my single network interface. I don’t know why that is. Two of
them are 61000+ seconds ago, so testing the new router with the new local-ISP
IPv6 network. But I can’t think of why there might've been two different LL
address from that period of experimentation last night. Of those two, one
shows a router lifetime of 1800s, the other 0s. That last is what I expected,
that a deprecated route would show up with a 0 lifetime or something similar I
could parse out indicating such.
(I also count 15 Address proposals, 4 from the original (and current) router,
and 11 from the experimentation with the new router last night. Much more
complicated than I expected.)
I think this is all because this system has an uptime of more than 2 months and
I’ve switched the routers around many times in recent weeks. I think we can
just ignore what I was/am seeing, and I’m happy to presume that you’re right
with your commands and my situation is just unusual.
>> 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.
I suppose that’s true, but I have been using the same /48 over a tunnel for
more than 15 years. It’s reserved. So, I just knew my prefix wouldn’t change.
> 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.
The alias addresses were just chosen by me that were meaningful or interesting
to me as a human. Simple addresses.
And I don’t see changing IIDs. I have an autoconf IPv6 address in DNS for this
host and it hasn’t changed. It came up when the system did and stays that way.
It’s not a temporary address. Of the 3 proposed addresses I see now from this
router in slaacctl output, two are temporary (one with a 0 pltime) and one is
not. That one is what I put in DNS years ago, and doesn’t change.
>> 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.
Right. The issue now is that I have no mechansim. Well, static alias add on
boot, and the advertised network never changes, so. :-). I need a mechanism
that can handle changes. That was my original reason for inquiry.
Thanks.
- Chris
