Re: IPv6 accept_rtadv for default route and prefix but force host portion of /64 address?

W dniu 30.09.2025 o 17:25, Tom Pusateri pisze:
>
>> On Sep 30, 2025, at 8:18 AM, Karl Denninger <karl@denninger.net> wrote:
>>
>> On 9/30/2025 07:43, Ronald Klop wrote:
>>> Van: Tom Pusateri <pusateri@keehole.org>
>>> Datum: maandag, 29 september 2025 23:32
>>> Aan: "net@freebsd.org" <net@FreeBSD.org>
>>> 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