From nobody Thu Apr 2 19:57:31 2026 X-Original-To: freebsd-current@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 4fmt1g02Y1z6Ydk9 for ; Thu, 02 Apr 2026 19:57:43 +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 4fmt1f51Zqz3hxq; Thu, 02 Apr 2026 19:57:42 +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.2/8.17.2) with ESMTPSA id 632JvWiG052313 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 2 Apr 2026 21:57:32 +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=1775159853; bh=V/LwhSu+GIxHJIm9gHqffmzdJfE3LVCApX0lNjDjhUg=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=yupIlBI+mItJhvD8lEvjX2ZeZncZTha8I2L/qLn2a6Js6FEDUv5pCT8gpUvGFbf+I mmBXYtHAS2n1izXMT3rOfhrr7TjRIVDQ+YuPlVvoynqYIufw9vCje6me6MBfAu88df cwZV/tSRAYs9gKnO62jb68iUke04faEmZvk3yahkcOpiAhiPlrGhycSa9RlAlp0LD/ heC0Bula20Bkio3aEQiYMHPX8LDLvp5ciHJ7P+wY3q64WjYv72eZgUQFw8nm+/ht/p nT+8dUdiatPDo+DSZxxbClgWVDhTPhPf5y0g6AuZ7Ib42WkDsXcc/L4zC5nOcQdmVO HJk2RSlmCTV6Q== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Content-Type: multipart/alternative; boundary="------------Y0COhTkrAsb5tqGKu6VLTh3k" Message-ID: Date: Thu, 2 Apr 2026 21:57:31 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Proposal: remove IPv6-only RA draft bits to adopt DHCP option (RFC 8925) To: Pouria Mousavizadeh Tehrani , freebsd-current@freebsd.org Cc: bz@freebsd.org References: <3a6e219f-905b-456f-8135-00e67c3652fb@FreeBSD.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: <3a6e219f-905b-456f-8135-00e67c3652fb@FreeBSD.org> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated 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-Queue-Id: 4fmt1f51Zqz3hxq X-Spamd-Bar: ---- This is a multi-part message in MIME format. --------------Y0COhTkrAsb5tqGKu6VLTh3k Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2.04.2026 at 19:55, Pouria Mousavizadeh Tehrani wrote: > Hi everyone, > > There is an implementation of the DRAFT_IETF_6MAN_IPV6ONLY_FLAG draft > in the OS. It is the excellent work of Bjoern (@bz), both the > Internet-Draft and its implementation. > > I'm requesting removal of the draft-specific bits (which is not > compiled by default), but first a short history from an outsider's > reading of the IETF archives. > > The draft's history is unfortunate. @bz had a great idea about making > a network automatically become IPv6-only by advertising it as a RA flag. > However, the idea had a small flaw: RAs can be trivially forged and > could be used to maliciously disable v4 networks, so RA was not a safe > transport for such a flag. > IMHO, the same attack surface could exist for DHCP, but DHCP > deployments are commonly protected by DHCP snooping in practice. > That led to the conclusion that a DHCP option would be a safer place > for this signal. > The draft was eventually abandoned (mailing-list archive: > https://mailarchive.ietf.org/arch/msg/ipv6/7nwZ6BUqbSqEC11eTqVqCOZwGI8/). > > Shortly after, someone else (google) submitted the same idea as a DHCP > option, which became RFC 8925. > Although the original idea came from Bjoern, neither his name nor his > draft is acknowledged in that RFC. > I have not discussed this with Bjoern (cc'ed), only observed the > sequence of events. > I appreciated his work, it appears to be his last draft. > > We should move forward and align with RFC 8925. > I use the DHCP option at my company and at home, mobiles and most > devices support it well. > I'd like to make this work on my FreeBSD boxes as well. > > In short, I'm asking for willingness to remove or replace the > EXPERIMENTAL/DRAFT_IETF_6MAN_IPV6ONLY_FLAG bits and adopt the > DHCP-option-based approach (RFC 8925). > The current code locations referencing the draft are: > Kernel: > sys/netinet6/nd6_rtr.c: lines 107–115, 251–355, 602–604, 782–784 > sys/netinet6/nd6.h: lines 77–82 > sys/netinet/icmp6.h: #define ND_RA_FLAG_IPV6_ONLY 0x02 > sys/net/if_ethersubr.c: lines ~478–497, 544–560 > > Userland: > grep -r DRAFT_IETF_6MAN_IPV6ONLY_FLAG > ./usr.sbin/rtadvd/rtadvd.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG > ./usr.sbin/rtadvd/Makefile:CFLAGS+= -DDRAFT_IETF_6MAN_IPV6ONLY_FLAG > ./usr.sbin/rtadvd/config.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG > ./usr.sbin/rtadvd/config.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG > ./usr.sbin/rtadvd/config.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG > ./usr.sbin/rtadvd/rtadvd.h:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG > ./usr.sbin/ndp/Makefile:CFLAGS+= -DDRAFT_IETF_6MAN_IPV6ONLY_FLAG > ./usr.sbin/ndp/ndp.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG > ./sbin/ifconfig/af_nd6.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG > ./sbin/ifconfig/Makefile:CFLAGS+= -DDRAFT_IETF_6MAN_IPV6ONLY_FLAG > > The existing implementation is reusable, but I want to ensure Bjoern > and others are comfortable with reworking/removing the draft-specific > code and moving to RFC 8925. > Please reply if you have concerns, objections, or if you're ok with > this removal of this option. > Hi Pouria, all, adopting the |option v6-only-preferred| would be an excellent step toward modernizing the FreeBSD network stack. I have to admit that for several years now we have been successfully advertising this option across a couple of dual-stack Wi-Fi SSIDs, including for a dual-stack eduroam network. This is not a typical dual-stack deployment. Instead, we provide DNS64 servers via RADNSS and use NAT64 for this network. As a result, some clients - primarily Android phones - gain network connectivity very quickly by transitioning entirely to IPv6. This eliminates a number of issues and reduces the potential attack surface associated with IPv4. I strongly support this kind of modernization of the FreeBSD network stack and am looking forward to the opportunity to test this functionality. Cheers -- Marek Zarychta --------------Y0COhTkrAsb5tqGKu6VLTh3k Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 2.04.2026 at 19:55, Pouria Mousavizadeh Tehrani wrote:
Hi everyone,

There is an implementation of the DRAFT_IETF_6MAN_IPV6ONLY_FLAG draft in the OS. It is the excellent work of Bjoern (@bz), both the Internet-Draft and its implementation.

I'm requesting removal of the draft-specific bits (which is not compiled by default), but first a short history from an outsider's reading of the IETF archives.

The draft's history is unfortunate. @bz had a great idea about making a network automatically become IPv6-only by advertising it as a RA flag.
However, the idea had a small flaw: RAs can be trivially forged and could be used to maliciously disable v4 networks, so RA was not a safe transport for such a flag.
IMHO, the same attack surface could exist for DHCP, but DHCP deployments are commonly protected by DHCP snooping in practice.
That led to the conclusion that a DHCP option would be a safer place for this signal.
The draft was eventually abandoned (mailing-list archive: https://mailarchive.ietf.org/arch/msg/ipv6/7nwZ6BUqbSqEC11eTqVqCOZwGI8/).

Shortly after, someone else (google) submitted the same idea as a DHCP option, which became RFC 8925.
Although the original idea came from Bjoern, neither his name nor his draft is acknowledged in that RFC.
I have not discussed this with Bjoern (cc'ed), only observed the sequence of events.
I appreciated his work, it appears to be his last draft.

We should move forward and align with RFC 8925.
I use the DHCP option at my company and at home, mobiles and most devices support it well.
I'd like to make this work on my FreeBSD boxes as well.

In short, I'm asking for willingness to remove or replace the EXPERIMENTAL/DRAFT_IETF_6MAN_IPV6ONLY_FLAG bits and adopt the DHCP-option-based approach (RFC 8925).
The current code locations referencing the draft are:
Kernel:
sys/netinet6/nd6_rtr.c: lines 107–115, 251–355, 602–604, 782–784
sys/netinet6/nd6.h: lines 77–82
sys/netinet/icmp6.h: #define ND_RA_FLAG_IPV6_ONLY 0x02
sys/net/if_ethersubr.c: lines ~478–497, 544–560

Userland:
grep -r DRAFT_IETF_6MAN_IPV6ONLY_FLAG
./usr.sbin/rtadvd/rtadvd.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG
./usr.sbin/rtadvd/Makefile:CFLAGS+=     -DDRAFT_IETF_6MAN_IPV6ONLY_FLAG
./usr.sbin/rtadvd/config.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG
./usr.sbin/rtadvd/config.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG
./usr.sbin/rtadvd/config.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG
./usr.sbin/rtadvd/rtadvd.h:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG
./usr.sbin/ndp/Makefile:CFLAGS+=        -DDRAFT_IETF_6MAN_IPV6ONLY_FLAG
./usr.sbin/ndp/ndp.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG
./sbin/ifconfig/af_nd6.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG
./sbin/ifconfig/Makefile:CFLAGS+= -DDRAFT_IETF_6MAN_IPV6ONLY_FLAG

The existing implementation is reusable, but I want to ensure Bjoern and others are comfortable with reworking/removing the draft-specific code and moving to RFC 8925.
Please reply if you have concerns, objections, or if you're ok with this removal of this option.

Hi Pouria, all,
adopting the option v6-only-preferred would be an excellent step toward modernizing the FreeBSD network stack. I have to admit that for several years now we have been successfully advertising this option across a couple of dual-stack Wi-Fi SSIDs, including for a dual-stack eduroam network.

This is not a typical dual-stack deployment. Instead, we provide DNS64 servers via RADNSS and use NAT64 for this network. As a result, some clients - primarily Android phones - gain network connectivity very quickly by transitioning entirely to IPv6. This eliminates a number of issues and reduces the potential attack surface associated with IPv4.

I strongly support this kind of modernization of the FreeBSD network stack and am looking forward to the opportunity to test this functionality.

Cheers

-- 
Marek Zarychta
--------------Y0COhTkrAsb5tqGKu6VLTh3k--