Tuesday, September 03, 2024

Re: IPv6 static host address inside dynamic network



On Sep 3, 2024, at 10:28, Mike Fischer <fischer+obsd@lavielle.com> 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

No comments:

Post a Comment