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

Marek Zarychta <[email protected]>
Newsgroups gmane.os.freebsd.current
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.