From nobody Tue Sep 30 16:08:24 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 4cbjfG4rY2z69HYd for ; Tue, 30 Sep 2025 16:08:38 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (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-signature ECDSA (prime256v1) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT TLS ECC 1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cbjfG0vT7z3gZW for ; Tue, 30 Sep 2025 16:08:37 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; none Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.18.1/8.17.2) with ESMTPSA id 58UG8P6k016894 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 30 Sep 2025 18:08:25 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1759248505; bh=pRNYryPMyT/RWrdMAntuXvgx/nEBvqdgkHBjUVTRtKg=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=lQCafyRPkl7n4RKdMNtdlRcFSaKYBLezPO2GLMEtG78X54EoYm95443GrZOErLWIN +tyE4y48+Wrbvm+6gWy9/6Hz020MubeDe8NZtWh+FJq/bIewrrqZSidMeb9hBc2eWC bS2UXgaSs3b+UKtqHPmS8S/SAPp96zNxjOx56cy5MW74/wcD41bOSGpyMfzOwHKt/I ouissabB+9gVwpqsrbaTxoQOeCkqteejTdmoAOri1PzEzINIq08qI/dZV0RxZN3jm5 Edf1woCCmMTsj/aSV5jm72B8n5794swMUvkULG9UgeosYc6Pp01HNjvLFM2gRnw2oq 2350+BrUktZaA== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Message-ID: <4f9140d1-7b48-46c7-913c-24a203af147b@plan-b.pwste.edu.pl> Date: Tue, 30 Sep 2025 18:08:24 +0200 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 User-Agent: Mozilla Thunderbird Subject: Re: IPv6 accept_rtadv for default route and prefix but force host portion of /64 address? To: Tom Pusateri Cc: freebsd-net@freebsd.org References: <1819478143.6522.1759232622123@localhost> <7CCDAED0-9F43-435D-B5E6-7B1ADA82F04F@keehole.org> Content-Language: en-US From: Marek Zarychta Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; keydata= xsBNBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAHNN01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD7CwHcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgc7ATQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABwsBf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V4= In-Reply-To: <7CCDAED0-9F43-435D-B5E6-7B1ADA82F04F@keehole.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cbjfG0vT7z3gZW W dniu 30.09.2025 o 17:25, Tom Pusateri pisze: > >> On Sep 30, 2025, at 8:18 AM, Karl Denninger wrote: >> >> On 9/30/2025 07:43, Ronald Klop wrote: >>> 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, >>> >>> 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