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

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.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/