dhclient(8): Add support for IPv6-Only option (RFC 8925)

[pouria]

Summary

Accept and validate ipv6only option and stop dhcp configuration
process if and only if ipv6 connectivity exists.
Use netlink for ipv6 connectivity check.

Relnotes: yes

I have absolutely no idea about DHCP state machine and its interaction
with dhcp script.
PLEASE REVIEW CAREFULLY.

Test Plan

Set ipv6only option in your dhcp server.
If its value is set to 0xffffffff, dhcp client should not try again.
If it was below max value, it should wait and try again at least
MIN_V6ONLY_WAIT (300) seconds to send another request.
In both cases, it should go_daemon.

% 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,
even if the option added later to dhcp server.

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
send a DHCP REQUEST to renew and we only react to DHCP ACK if we're in INIT-REBOOT state.

% 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), abort

If compiled without netlink support, it assumes we don't have connectivity
and ignores the option.

[pouria]

Fix typo in a single log message + rebase main.

[pouria]

• If the client is in the INIT-REBOOT state and the DHCPv4 server responds with a DHCPACK that includes the IPv6-Only Preferred option, react.
• Remove extra INET6 macro.

[pouria]

We may want to also update the /etc/rc.d/defaultroute consequently to avoid unnecessary wait time.
But that's another review.

[bz]

In D56637#1297541, @pouria wrote:

We may want to also update the /etc/rc.d/defaultroute consequently to avoid unnecessary wait time.
But that's another review.

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 :)

[pouria]

In D56637#1297542, @bz wrote:

In D56637#1297541, @pouria wrote:

We may want to also update the /etc/rc.d/defaultroute consequently to avoid unnecessary wait time.
But that's another review.

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 :)

Unfortunately, I'm not an expert in our /etc/network.subr.
However, I'd like to work on it and see what can I do about it. of course, after this review.

[zarychtam_plan-b.pwste.edu.pl]

Thank you for adding me to the list of subscribers and thus allowing testing it early.
Today I have tested it in a wired and wireless network, and I can confirm that it works fine. I have not investigated why, but once, after a fresh reboot, the wireless interface got an IPv4 address along with IPv6 - though it never happened to the wired one. I will try to figure out what was going on, perhaps some delays in the wireless network can trigger this.
To make it even smoother, let me propose some enhancements in devd.conf and the defaultroute script - it can improve UX slightly.

--- /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

[pouria]

In D56637#1297782, @zarychtam_plan-b.pwste.edu.pl wrote:

Thank you for adding me to the list of subscribers and thus allowing testing it early.
Today I have tested it in a wired and wireless network, and I can confirm that it works fine. I have not investigated why, but once, after a fresh reboot, the wireless interface got an IPv4 address along with IPv6 - though it never happened to the wired one. I will try to figure out what was going on, perhaps some delays in the wireless network can trigger this.

ipv6only option will check if you have a working connection or not.
I guess DORA happens faster than receiving RA in your wifi network.
Is this problem happening all the time or at random?

To make it even smoother, let me propose some enhancements in devd.conf and the defaultroute script - it can improve UX slightly.

--- /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

Unfortunately, skipping configuration of defaultroute and automatically starting rtsold beside dhcp are depends on administrator.
We're not allowed to do this automatically for user.

[zarychtam_plan-b.pwste.edu.pl]

In D56637#1298187, @pouria wrote:

In D56637#1297782, @zarychtam_plan-b.pwste.edu.pl wrote:

Thank you for adding me to the list of subscribers and thus allowing testing it early.
Today I have tested it in a wired and wireless network, and I can confirm that it works fine. I have not investigated why, but once, after a fresh reboot, the wireless interface got an IPv4 address along with IPv6 - though it never happened to the wired one. I will try to figure out what was going on, perhaps some delays in the wireless network can trigger this.

ipv6only option will check if you have a working connection or not.
I guess DORA happens faster than receiving RA in your wifi network.
Is this problem happening all the time or at random?

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%.

To make it even smoother, let me propose some enhancements in devd.conf and the defaultroute script - it can improve UX slightly.

--- /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

Unfortunately, skipping configuration of defaultroute and automatically starting rtsold beside dhcp are depends on administrator.
We're not allowed to do this automatically for user.

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.

[ziaee]

Manpage changes LGTM! Thanks for tagging me!

sbin/dhclient/dhcp-options.5

375

we may want to alphasort this list in a later commit.

sbin/dhclient/inet6.c

2

Please remove this hyphen. It was for a long abandoned WIP parser that was deemed infeasible. I think I have removed it from all of our style guides, please let me know if this is not the case.

Also, check style.9 or the https://docs.freebsd.org/en/articles/license-guide/ . Now that SPDX license identifiers are an ISO standard, the project's preferred license is to omit the body of the license text, that way we don't have to keep defining it in every singe file.

[markj]

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.

sbin/dhclient/clparse.c

109

How does this comment relate to the code? That is, what does "IPv4-requiring" really mean?

sbin/dhclient/dhclient.c

552

I don't love that we create a global pointer which refers to a stack variable. Can we make ss global too?

sbin/dhclient/inet6.c

49

Some brief comment here explaining what exactly we're "checking" would be helpful.

75

83

Same here? What is this checking? I cannot easily tell by reading the function.

126

Indentation looks wrong.

sbin/dhclient/options.c

106

I don't think these comments are useful.

[pouria]

Address @ziaee and @markj comments.

[pouria]

In D56637#1300703, @markj wrote:

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.

Yes, there are a lot, all the modern OSes supports it, windows, linux, android, ios...
And it definitely worth it.
I've tried my best to implement this feature as simple as possible.

sbin/dhclient/clparse.c

109

How does this comment relate to the code? That is, what does "IPv4-requiring" really mean?

Yes, by definition:

IPv4-requiring host: A host that is not IPv6-only capable and cannot
operate in an IPv6-only network providing NAT64 service.

I kept it simple here.
We could verify kernel support for INET6 with kern.features.inet6, but since dhclient is included in our base, we can reuse the INET6 macro to avoid extra complexity.
Of course, the more accurate method would be checking via sysctl.

The reason for this comment is to explain why this is wrapped inside the INET6 macro.

sbin/dhclient/dhclient.c

552

I don't love that we create a global pointer which refers to a stack variable. Can we make ss global too?

I don't like it either.
Most of my time on this revision was spent on this part because I had to follow the existing style for cap_rights_init, and unfortunately, I'm not an expert on cap_rights.
We could make it global, but I feel it would probably become uglier than it already is.

I'd appreciate any suggestions you might have. I can't think of a cleaner approach.

sbin/dhclient/inet6.c

75

I saw this style of checking negative conditions on some of the Gleb's code.
I thought it improve readability :)
Done.

[zarychtam_plan-b.pwste.edu.pl]

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. Perhaps dhclient should support an explicit opt-in flag for this behavior initially. For example, the implemented feature could become active only when using something like dhclient_flags="-6" (or another dedicated option). In the future, this behavior may become the default, but FreeBSD users tend to be rather conservative. Because of that, it might also be worth keeping a way to ignore this DHCP option and continue normal IPv4 DHCP lease negotiation if desired.
2. Making this feature non-default initially — similarly to Linux NetworkManager — could help with earlier MFC and potentially allow it to land in FreeBSD 15.2 sooner. This would be a nice step toward modernising the FreeBSD networking stack. Once FreeBSD gains CLAT support, enabling this behavior by default would make even more sense.

[1] https://ripe92.ripe.net/programme/meeting-plan/sessions/94/PBHCLK/

[kfv]

sbin/dhclient/dhclient.c

882

I might be reading this wrong, just wanted to check the S_INIT branch in this IPv6-only condition. RFC 8925 §3.2 ties the special DHCPACK behaviour to INIT-REBOOT (RFC 2131 §4.4.2), which only maps to S_REBOOTING, I believe. I don't see the INIT discover path (as covered in RFC 2131 §4.4.1) mentioned anywhere.

Besides, dhcpack() already returns early unless state matches the guard at lines 796–800, and S_INIT isn't listed there, so this branch is basically unreachable anyway.

If there's a case where DHCPACK should be handled in S_INIT, the outer guard would need updating too, and a comment would be really helpful since it's not obvious from the RFCs (unless there's something I have missed.) Otherwise, perhaps we should just drop S_INIT here.

885

I recommend declaring v6wait as u_int32_t/uint32_t. RFC 8925 defines option 108 as a 32-bit unsigned duration, not necessarily a time_t epoch offset, and herein it's only used as a wait length (timespecadd, logging,) it's never adjusted with += cur_time etc. Therefore, using time_t conflates duration with absolute time, I might say, and more importantly breaks on 32-bit hosts when wire values exceed INT32_MAX.

u_int32_t matches both getULong() and ipv6_only_option()'s val. Then you'd only need to convert to time_t when assigning timespec.tv_sec after clamping to TIME_MAX - time_now.tv_sec (same pattern as lease expiry—take a look at commit 223c44a its corresponding problem report 218980) so timespecadd() can't overflow. Also note that this clamp is vital and required on 32-bit platforms; on 64-bit it's still a good defensive practice, but not crucially required for sure.

If v6wait stays time_t, at minimum fix the note() call. %lu with a bare time_t is UB. I'd possibly go with (intmax_t)v6wait and %jd.

1202

packet_to_lease() at line 1116 allocates a lease object, but here on the IPv6-only path, we bale out and return without putting it on offered_leases or calling free_client_lease(lease). So each qualifying DHCPOFFER leaks a full client_lease (and copied options,) and with state still S_SELECTING, this repeats and every subsequent offer that arrives before state_reboot runs will leak again.

I recommend you either move the IPv6-only handling above packet_to_lease(), or add free_client_lease(lease) before this return. I'd personally go with moving it up: no point allocating a lease we're just going to throw away.

sbin/dhclient/dhcp-options.5

377

Perhaps you could drop "from".

sbin/dhclient/inet6.c

21

Unused include, can be removed.

[zarychtam_plan-b.pwste.edu.pl]

For what it's worth, I have not encountered any issues with this patch so far, and it has been running in production on my laptop at the workplace on a daily basis.

IMHO, instead of focusing on 100% RFC compliance from the very beginning, what we really need is someone willing to implement a host-side CLAT solution. FreeBSD already supports NAT64 with both IPFW and PF, but it still lacks a CLAT implementation required for 464XLAT operation.

[pouria]

@kfv_kfv.io
Thank you so much for your review.
I'll check ASAP.

In D56637#1319212, @zarychtam_plan-b.pwste.edu.pl wrote:

what we really need is someone willing to implement a host-side CLAT solution. FreeBSD already supports NAT64 with both IPFW and PF, but it still lacks a CLAT implementation required for 464XLAT operation.

We have CLAT support in FreeBSD with IPFW.
At least, I've it in my infrastructure and it works perfectly.

[pouria]

Address @kfv_kfv.io comments. Thanks!

[markj]

sbin/dhclient/dhclient.c

552

I'm worried less about ugliness than about ss becoming invalid because the stack frame gets reused after a tail call. Even though this is main(), it's not guaranteed that ss will be valid for the lifetime of the process. ss should be global IMO.

[pouria]

Address @markj comment.
Remove nl_ss_route and make nl_ss global.

[zarychtam_plan-b.pwste.edu.pl]

I am still testing it 24/7 on my laptop and can confirm that dhclient with this patch is working great!

[pouria]

In D56637#1366756, @zarychtam_plan-b.pwste.edu.pl wrote:

I am still testing it 24/7 on my laptop and can confirm that dhclient with this patch is working great!

I will commit this tomorrow if no one complains.

[kfv]

Same here, I’ve been testing it for a while now, and it has my approval as well. Thanks a lot for all the effort, Pouria!

[pouria]

• Implement the optional DHCPRELEASE part of the RFC: "It also MAY send a DHCPRELEASE message."
• Respect "ignore ipv6only" in dhclient.conf
• Free snl allocation
• cancel other timers with respect to INIT-REBOOT state

[pouria]

• Disassociate the ip address on release.

[kfv]

Diff 7/8 looks good on the INIT-REBOOT RELEASE/disassoc path, but ignore ipv6only doesn't seem to be a real opt-out.

As per RFC 8925 §3.2, an IPv4-requiring client MUST NOT put 108 in the PRL. We add DHO_IPV6_ONLY to requested_options in clparse.c before dhclient.conf is parsed, and ipv6_only_option() only discards the received option. DISCOVER/REQUEST still advertise 108.

Please drop 108 from requested_options after parsing if it is ignored.

[pouria]

• Unregister ignored options from default PRL. @kfv done.

[pouria]

Style

[pouria]

Style

[kfv]

Looks good to me now. Thanks!