Date: Thu, 2 Apr 2026 21:57:31 +0200 From: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> To: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>, freebsd-current@freebsd.org Cc: bz@freebsd.org Subject: Re: Proposal: remove IPv6-only RA draft bits to adopt DHCP option (RFC 8925) Message-ID: <f1df3229-0d83-4328-9666-efb64b116614@plan-b.pwste.edu.pl> In-Reply-To: <3a6e219f-905b-456f-8135-00e67c3652fb@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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 [-- Attachment #2 --] <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">On 2.04.2026 at 19:55, Pouria Mousavizadeh Tehrani wrote:<br> </div> <blockquote type="cite" cite="mid:3a6e219f-905b-456f-8135-00e67c3652fb@FreeBSD.org">Hi everyone, <br> <br> 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. <br> <br> 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. <br> <br> 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. <br> 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. <br> IMHO, the same attack surface could exist for DHCP, but DHCP deployments are commonly protected by DHCP snooping in practice. <br> That led to the conclusion that a DHCP option would be a safer place for this signal. <br> The draft was eventually abandoned (mailing-list archive: <a class="moz-txt-link-freetext" href="https://mailarchive.ietf.org/arch/msg/ipv6/7nwZ6BUqbSqEC11eTqVqCOZwGI8/">https://mailarchive.ietf.org/arch/msg/ipv6/7nwZ6BUqbSqEC11eTqVqCOZwGI8/</a>).<br>; <br> Shortly after, someone else (google) submitted the same idea as a DHCP option, which became RFC 8925. <br> Although the original idea came from Bjoern, neither his name nor his draft is acknowledged in that RFC. <br> I have not discussed this with Bjoern (cc'ed), only observed the sequence of events. <br> I appreciated his work, it appears to be his last draft. <br> <br> We should move forward and align with RFC 8925. <br> I use the DHCP option at my company and at home, mobiles and most devices support it well. <br> I'd like to make this work on my FreeBSD boxes as well. <br> <br> 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). <br> The current code locations referencing the draft are: <br> Kernel: <br> sys/netinet6/nd6_rtr.c: lines 107–115, 251–355, 602–604, 782–784 <br> sys/netinet6/nd6.h: lines 77–82 <br> sys/netinet/icmp6.h: #define ND_RA_FLAG_IPV6_ONLY 0x02 <br> sys/net/if_ethersubr.c: lines ~478–497, 544–560 <br> <br> Userland: <br> grep -r DRAFT_IETF_6MAN_IPV6ONLY_FLAG <br> ./usr.sbin/rtadvd/rtadvd.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG <br> ./usr.sbin/rtadvd/Makefile:CFLAGS+= -DDRAFT_IETF_6MAN_IPV6ONLY_FLAG <br> ./usr.sbin/rtadvd/config.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG <br> ./usr.sbin/rtadvd/config.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG <br> ./usr.sbin/rtadvd/config.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG <br> ./usr.sbin/rtadvd/rtadvd.h:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG <br> ./usr.sbin/ndp/Makefile:CFLAGS+= -DDRAFT_IETF_6MAN_IPV6ONLY_FLAG <br> ./usr.sbin/ndp/ndp.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG <br> ./sbin/ifconfig/af_nd6.c:#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG <br> ./sbin/ifconfig/Makefile:CFLAGS+= -DDRAFT_IETF_6MAN_IPV6ONLY_FLAG <br> <br> 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. <br> Please reply if you have concerns, objections, or if you're ok with this removal of this option. <br> <br> </blockquote> <p data-start="86" data-end="364">Hi Pouria, all,<br> adopting the <code data-start="99" data-end="125">option v6-only-preferred</code> 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.</p> <p data-start="366" data-end="710">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.</p> <p data-start="712" data-end="856">I strongly support this kind of modernization of the FreeBSD network stack and am looking forward to the opportunity to test this functionality.</p> <p>Cheers</p> <pre class="moz-signature" cols="72">-- Marek Zarychta</pre> </body> </html>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f1df3229-0d83-4328-9666-efb64b116614>