From nobody Tue Sep 30 15:25:40 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cbhhw0gQYz69DxT for ; Tue, 30 Sep 2025 15:25:52 +0000 (UTC) (envelope-from pusateri@keehole.org) Received: from kem.keehole.org (kem.keehole.org [136.41.224.255]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cbhhv5L5Lz3RyD for ; Tue, 30 Sep 2025 15:25:51 +0000 (UTC) (envelope-from pusateri@keehole.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [136.41.224.198]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by kem.keehole.org (Postfix) with ESMTPSA id A6A7177303; Tue, 30 Sep 2025 11:25:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=keehole.org; s=202408; t=1759245950; bh=bfmrHOGiuUpLS6ny0pUCmniLhV9oOKL/3WH9X51rgUw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=GZ+q/x+k3pYusoNlFD3Gjvngis1qqT5kpJOUpo1TELlKHpLoUISeyE/Wr+JEEy7/g JPwyYrpgUeDVvBFGmNWGrJWI/L6MIiTrSq8t+e4E+W5jidtkkiWOEgMa8jAm6PrN25 kkvvMml9FjQGfV/mQ8ADAbWaeOsHrZhtarcLG7cPXC8/KLApzppVa3/y1X+hU7TY8n v/Caj0HWpFltjB/z03NlKziT4EV982tKjDeCHFlV7rPdiehZD48bmeY5CXkjAZzXkJ xNVpn9uThwtys7+zFizaEGP7QcuJvd4wHdsD7HHzAoWZRDUu0JlWVimbz6yTix0jzP WPAqT/R6Zxyxw== Content-Type: text/plain; charset=utf-8 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: IPv6 accept_rtadv for default route and prefix but force host portion of /64 address? From: Tom Pusateri In-Reply-To: Date: Tue, 30 Sep 2025 11:25:40 -0400 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7CCDAED0-9F43-435D-B5E6-7B1ADA82F04F@keehole.org> References: <1819478143.6522.1759232622123@localhost> To: Karl Denninger X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cbhhv5L5Lz3RyD > On Sep 30, 2025, at 8:18=E2=80=AFAM, Karl Denninger = wrote: >=20 > On 9/30/2025 07:43, Ronald Klop wrote: >>=20 >> Van: Tom Pusateri >> Datum: maandag, 29 september 2025 23:32 >> Aan: "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