Re: Proposal: remove IPv6-only RA draft bits to adopt DHCP option (RFC 8925)

From: Marek Zarychta <zarychtam_at_plan-b.pwste.edu.pl>
Date: Thu, 02 Apr 2026 19:57:31 UTC
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