W dniu 30.09.2025 o 17:25, Tom Pusateri pisze:
On Sep 30, 2025, at 8:18 AM, Karl Denninger <[email protected]> wrote:
On 9/30/2025 07:43, Ronald Klop wrote:
Van: Tom Pusateri <[email protected]>
Datum: maandag, 29 september 2025 23:32
Aan: "[email protected]" <[email protected]>
Onderwerp: IPv6 accept_rtadv for default route and prefix but force host
portion of /64 address?
Is there a way to change the configuration in /etc/rc.conf to get the prefix
from the router advertisement but fix the host portion to something like ::123
so that I can change network cards in the server and never have to worry about
the IPv6 address changing?
Hi,
I think DHCPv6 could help you here. In IPv6 the address via DHCP is not
connected to the MAC address directly, but to a DUID, which is something
similar to the hostuuid. AFAIK it should be stable between hardware changes.
The details might be important, read something like this
https://metebalci.com/blog/a-note-on-dhcpv6-duid-and-prefix-delegation/. I
think in my dhcpv6-client I can hardcode the DUID also if needed.
Not necessarily.
Many providers (including mine) form what amounts to a "tuple" with the duid,
MAC on the device on your end and the MAC on their device (e.g. ONT in the case of a
fiber connection, etc.)
Changing ANY of them will typically result in a different delegation and in
some cases (e.g. changing the duid but not the MAC) will result in their end
locking out the delegation (!!!) which is very bad for obvious reasons. My
provider locks out a connection that changes duid but not the MAC.
My experience is that if you wish to have a "reasonable" expectation that the delegation
will not change your MAC and duid must not change. Most interfaces can have their MAC overridden,
so that can be accomplished even if you do change hardware out. This presumes you're on an
allegedly-fixed delegation from the provider lest they change it anyway since on a
"consumer" connection they typically do not guarantee that it won't change nor do they
provide a reverse DNS entry.
My provider (and many others) in the IPv6 realm also sends down two delegations
via DHCP; one for the interface specifically (as a /128), and the second for
your network (typically a /56).
Dhcpcd is more-configurable in this regard than the dhcp6c alternative and is a "one
for both" alternative to the use of two daemons (one to get IPv4 and one for IPv6)
with only the IPv4 client being in the base.
The issue is not on the router that is running DHCPv6 to the provider but for
the DMZ server. I have a static allocation of the delegated prefix from my
provider. I just didn’t want to configure it on the router and the server but I
have for now and it works ok.
Since the prefix is sent via a router advertisement from rtadvd which is necessary
to run in order to get the default router link local address, I was hoping there was
a way to merge that prefix, with a local host portion instead of having the kernel
create one based on Mac address but there doesn’t seem to be a way to do this
without specifying the whole address. RFC 4862 section 5.5 calls this an
"interface identifier”.
It would cool if in the /etc/rc.conf, you could specify something like:
ifconfig_igb0_ipv6="inet6 ifid ::123 accept_rtadv”
Thanks,
Tom
I’m not sure if any(?!) OS actually supports assigning an interface
identifier manually in SLAAC, but, FreeBSD does not. However, there’s a
useful enhancement that was recently added: RFC 7217 support has been
implemented in the FreeBSD stack[1], though it’s not yet included in any
release.
If you’re running FreeBSD 15, you can easily MFC three commits to enable
full functionality. With this approach, as long as you copy the host ID
and use the same interface name, the system will consistently generate
the same static address for your interface.
1. https://cgit.freebsd.org/src/commit/?id=31ec8b6407
Cheers
Marek
