From nobody Thu Apr 2 18:36:24 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 4fmrD32gxzz6YW3b; Thu, 02 Apr 2026 18:36:35 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4fmrD320Pbz3WJT; Thu, 02 Apr 2026 18:36:35 +0000 (UTC) (envelope-from bz@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1775154995; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=K0X86mzVZSpsSNMMUH+2uOTNq5JO7Zz8KUBbPhxx76k=; b=Rx/eyZgquZfNPCjg3Q3nG9ONgTgUh02BgEUEGEXHSudVFdkm7Y3CmlcISTUV1zyC1AhhUT ZoJGxbhUGcZ02l5Q2AOw8BxaM8I8mS44/3Tu/5jen48lsIvbrvSl9CCL4obT3rJfkDYsOS HkvkK61trFyjh71HHZMht0ut28q1QdGF3O/yQVLhyDo6nomUSIwK8NMJxaaByUORUfhiix 4q6itMSKkEBXFQcJQloTkqIpe8Jh+Oyvs8TSHLdxZxVCwBHdZ3mw9Y9K1pceDp/Wy7lfQY OOVZYtJ90qG364nrdZV4a2eydkzpxdaLez+gO30t40hfDL56bFvvXHT8x5gX6w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1775154995; a=rsa-sha256; cv=none; b=YSuwqFTwGbbJOve5qk1LzzV/KN6CgOhZCfgM7AtwKJC/wyeOlRBI2+QyUKXx8O26gD3BC4 UHcvhFOEJqHlV0YU3yrE66wRwGg9KPwk3tAz+b1GRInT988QxgJIOGznHO/73V2cWiA9hh 5YDsaAhwBZHflpoBxPAyD3tCWkhRDDkcSo8N3zJV9L3iPl7ID1eTxDhzn+M2ivFdA2IDbP hhg+JnwlwFpqM2gZ3si/LEsPIYuA6rnb39/P/9uUlh/udf/fnvV7IBnnF0IhIhA8Qo6Q8Z M+adNcOmLu5g82mMP3pB7Yb0VXAXpAtGqxg7IBdFeF0ljVdiM4cogr8eHW6pzw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1775154995; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=K0X86mzVZSpsSNMMUH+2uOTNq5JO7Zz8KUBbPhxx76k=; b=WfqA7onQT5aaqThQG0zCMpAptvqyYhczvlKvLs204vSUIRyZF0shsW86la56iFVhzDQgCp YjmtFslpjp8svM4/ufScOCxihyegAV+axparuy8cJmAuUunSqsliq63RAZfYQkho9uuhhO ATOxPNLGTpT/4eqdFQIq0WbcM0VZ1CHjIa4tOs3EZSV6L2odtveI6ZhoDTA/xpW1G8pgaH I1uYhYZhbjWFxR1jSqJ5y3nZQvC7Mnsgy+GfGx7un+cgeVmrn9MjikQzBKrWUG7fXOgQG8 y7eXRiUGhlTU6OY9v527WkPotIHXE94j/ycHAPdyubReVMLdoy/ZBHPhhfaItA== Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (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 "mx-01.divo.sbone.de", Issuer "E7" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4fmrD26RL3z1K4T; Thu, 02 Apr 2026 18:36:34 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id 82CF9A64805; Thu, 02 Apr 2026 18:36:06 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 8D47A2D029E9; Thu, 2 Apr 2026 18:36:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id L2KdKha5GFwE; Thu, 2 Apr 2026 18:36:24 +0000 (UTC) Received: from nv.t4-02.sbone.de (nv.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:22]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 54E3C2D029D8; Thu, 2 Apr 2026 18:36:24 +0000 (UTC) Date: Thu, 2 Apr 2026 18:36:24 +0000 (UTC) From: "Bjoern A. Zeeb" To: Pouria Mousavizadeh Tehrani cc: freebsd-current@freebsd.org, net@freebsd.org Subject: Re: Proposal: remove IPv6-only RA draft bits to adopt DHCP option (RFC 8925) In-Reply-To: <3a6e219f-905b-456f-8135-00e67c3652fb@FreeBSD.org> Message-ID: References: <3a6e219f-905b-456f-8135-00e67c3652fb@FreeBSD.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 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 Content-Type: multipart/mixed; boundary="0-431469178-1775154984=:11296" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-431469178-1775154984=:11296 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 2 Apr 2026, Pouria Mousavizadeh Tehrani wrote: Hi, Cc: net also > 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. Most of the above isn't actually historically right but so be it. Just to clarify one fact: it wasn't my idea in first place; I joined the others who had done the first version of the draft and I did the actual implementation to see if it would work and how well. That said, it did and does. People keep forgetting that FreeBSD is (was) (probably still?) the only non-router OS shipping with a working SeND implementation (kernel + net-mgmt/send, which I think got removed unfortunately), which can secure your RAs. Certificates are hard, the world is still not there... > 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. Please do. The one drawback DHCPv4 has, on a pure IPv6-only machine you cannot run DHCPv4 properly anymore to even handle those "dual-stack clients" not wanting IPv4 anymore but the world will need another decade to get there... The good news is, that should be purely a user space feature. You may have seen the IPv6-only semi-only-April1st Linux one yesterday with the follow-up of thinking it should really happen: https://lore.kernel.org/lkml/2cb91533e22ed6cb11205dbc56b8aeedbbce0cca.camel@infradead.org/ As I pointed out, it's been 15 years since FreeBSD had done so: https://lore.kernel.org/lkml/20260401163500.AE4862D029D8@mail.sbone.de/ So by all means, the more IPv6 stuff works and turns off IPv4 on FreeBSD the better. I do have more WIP changes pending in places a particular project we should be in mind. But let's take that offlist. Related to your request: I have a window open here with the SVN sequence of commits which happened as I wanted to remove this and the EXPERIMENTAL option some time before 16 anyway. I wanted to do so before 15 but it didn't happen anymore. Do you want me to do it myself or do you want to do it and just put me on review? If the latter please try to catch it all in one go, including user space as you have outlined below. > 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. /bz -- Bjoern A. Zeeb r15:7 --0-431469178-1775154984=:11296--