Date: Tue, 30 Sep 2025 11:25:40 -0400 From: Tom Pusateri <pusateri@keehole.org> To: Karl Denninger <karl@denninger.net> Cc: freebsd-net@freebsd.org Subject: Re: IPv6 accept_rtadv for default route and prefix but force host portion of /64 address? Message-ID: <7CCDAED0-9F43-435D-B5E6-7B1ADA82F04F@keehole.org> In-Reply-To: <f33ddf87-c410-4e5d-bc13-642720269a95@denninger.net> References: <BD1858FA-744F-465D-AD6D-C2659FC11D3F@keehole.org> <1819478143.6522.1759232622123@localhost> <f33ddf87-c410-4e5d-bc13-642720269a95@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sep 30, 2025, at 8:18=E2=80=AFAM, Karl Denninger = <karl@denninger.net> wrote: >=20 > On 9/30/2025 07:43, Ronald Klop wrote: >>=20 >> 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, >>=20 >> 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=E2=80=99t 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=E2=80=99t seem to be a way to do this without specifying the = whole address. RFC 4862 section 5.5 calls this an "interface = identifier=E2=80=9D. It would cool if in the /etc/rc.conf, you could specify something like: ifconfig_igb0_ipv6=3D"inet6 ifid ::123 accept_rtadv=E2=80=9D Thanks, Tom
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7CCDAED0-9F43-435D-B5E6-7B1ADA82F04F>