Differential D56637
dhclient(8): Add support for IPv6-Only option (RFC 8925) Authored by pouria on Sat, Apr 25, 6:02 PM. Tags None Referenced Files
Details Accept and validate ipv6only option and stop dhcp configuration Relnotes: yes I have absolutely no idea about DHCP state machine and its interaction Set ipv6only option in your dhcp server. % mdo dhclient bridge0 DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 7 DHCPOFFER from 100.64.1.254 IPv6-Only Preferred option received (300 seconds), abort If option sets after dhclient get bounded, it will renew, DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 3 DHCPOFFER from 100.64.1.254 DHCPREQUEST on bridge0 to 255.255.255.255 port 67 DHCPACK from 100.64.1.254 bound to 100.64.1.125 -- renewal in 300 seconds. DHCPREQUEST on bridge0 to 100.64.1.254 port 67 DHCPACK from 100.64.1.254 bound to 100.64.1.125 -- renewal in 300 seconds. So, normally existing clients shouldn't react to option since they simply % mdo cat /var/db/dhclient.leases.bridge0
lease {
interface "bridge0";
fixed-address 100.64.1.125;
next-server 100.64.1.254;
option subnet-mask 255.255.255.0;
option routers 100.64.1.254;
option domain-name-servers 100.64.1.53,9.9.9.9;
option domain-name "spmzt.net";
option dhcp-lease-time 600;
option dhcp-message-type 5;
option dhcp-server-identifier 100.64.1.254;
option ipv6only 4095;
renew 6 2026/4/25 20:32:56;
rebind 6 2026/4/25 20:36:41;
expire 6 2026/4/25 20:37:56;
}
% mdo dhclient bridge0
DHCPREQUEST on bridge0 to 255.255.255.255 port 67
DHCPACK from 100.64.1.254
bound to 100.64.1.125 -- renewal in 300 seconds.
% mdo pkill dhclient
% mdo dhclient bridge0
DHCPREQUEST on bridge0 to 255.255.255.255 port 67
DHCPACK from 100.64.1.254
IPv6-Only Preferred option received (4095 seconds), abortIf compiled without netlink support, it assumes we don't have connectivity
Diff Detail
Event TimelineComment Actions
Comment Actions We may want to also update the /etc/rc.d/defaultroute consequently to avoid unnecessary wait time. Comment Actions YES PLEASE but also in a way that if there is no IPv4 but 127.1 maybe it doesn't run. People complained about 3 seconds rtsol in the past when I complained about 30 seconds defaultroute. I think further checks in the script and not having DHCP configured anymore made it more bareable if I still have a dual-stack enabled kernel but ... getting it right would be good :) Comment Actions Unfortunately, I'm not an expert in our /etc/network.subr. Comment Actions Thank you for adding me to the list of subscribers and thus allowing testing it early. --- /etc/rc.d/defaultroute.orig 2026-04-27 00:21:39.995670000 +0200 +++ /etc/rc.d/defaultroute 2026-04-27 08:45:00.451195000 +0200 @@ -36,6 +36,12 @@ afexists inet || return 0 + # Skip if we support and already have default IPv6 route + afexists inet6 && { + defif=`get_default_if -inet6` + [ -n "${defif}" ] && return + } + # Return without waiting if we don't have dhcp interfaces or # if none of the dhcp interfaces is plugged in. dhcp_interfaces=`list_net_interfaces dhcp` --- /etc/devd.conf.orig 2026-04-27 09:14:32.715984000 +0200 +++ /etc/devd.conf 2026-04-27 10:03:57.566192000 +0200 @@ -53,7 +53,7 @@ match "system" "IFNET"; match "type" "LINK_UP"; media-type "ethernet"; - action "service dhclient quietstart $subsystem"; + action "service dhclient quietstart $subsystem; service rtsold quietrestart"; }; # @@ -72,7 +72,7 @@ match "system" "IFNET"; match "type" "LINK_UP"; media-type "802.11"; - action "service dhclient quietstart $subsystem"; + action "service dhclient quietstart $subsystem; service rtsold quietrestart"; }; # An entry like this might be in a different file, but is included here Comment Actions ipv6only option will check if you have a working connection or not.
Unfortunately, skipping configuration of defaultroute and automatically starting rtsold beside dhcp are depends on administrator. Comment Actions I only noticed this once on a wireless network, so considering the number of experiments performed, the probability of this occurring was less than 10%.
I hope that most people testing this solution are not only FreeBSD users but also administrators, and will be able to improve their IPv6-only testing experience this way. You have to admit, waiting for the next periodic RA after plugging in an Ethernet cable can be stressful, as can waiting for the defaultroute script to timeout while booting a laptop. I also believe servers can start once the system has IPv6 network access, so I'll add these fixes to my local repository until the FreeBSD developers resolve the issues. None of these issues is directly related to this review, and these shortcomings have been present in FreeBSD for a long time, as initially IPv6 connections were marginal, experimental, and didn't provide the real network access services needed. Today, in my opinion, things are different. So definitely, I haven’t identified any real drawbacks in the proposed solution. Finally, I would like to express my sincere gratitude - I truly appreciate the opportunity to test this upcoming feature. Comment Actions Manpage changes LGTM! Thanks for tagging me!
Comment Actions Are there some DHCP servers in the wild which set this option? Is it important to support it? It's not immediately obvious to me why this handling is worth the extra complexity.
Comment Actions Yes, there are a lot, all the modern OSes supports it, windows, linux, android, ios...
Comment Actions A couple of hours ago, I watched an excellent talk by Ondřej Caletka during the IPv6 Working Group session at RIPE 92 in Edinburgh [1]. I am linking it below especially for those who are still not convinced whether this feature should be implemented and how soon. First of all, I would like to report that the patch works flawlessly for me. With the patch from review D56797, I do not observe any noticeable delay during boot. I have also been testing it on my laptop connected to both wired and wireless networks at my workplace, where the “IPv6-Only Preferred” option is deployed. So far, it behaves correctly — after receiving the first DHCPOFFER containing this option, it stops IPv4 lease negotiation as expected. After watching the RIPE presentation linked below, I have a few remarks. I am not in a position to demand changes since I am not a reviewer, but perhaps these points are worth considering:
[1] https://ripe92.ripe.net/programme/meeting-plan/sessions/94/PBHCLK/ | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||