Option "Enable DHCP rapid commit (fast address assignment)"

General
1

Just noticed the option

Enable DHCP rapid commit (fast address assignment)

on the DHCP tab.

If you have the same question as me, "What is DHCP rapid commit?"...

You can configure the DHCPv6 local server to support the DHCPv6 Rapid Commit option (DHCPv6 option 14). When rapid commit is enabled, the server recognizes the Rapid Commit option in Solicit messages sent from the DHCPv6 client. (DHCPv6 clients are configured separately to include the DHCPv6 Rapid Commit option in the Solicit messages.) The server and client then use a two-message exchange (Solicit and Reply) to configure clients, rather than the default four-message exchange (Solicit, Advertise, Request, and Reply). The two-message exchange provides faster client configuration, and is beneficial in environments in which networks are under a heavy load.

Source

5 Likes
2

I am curious, why isn't this enabled by default?

3

We didn't see the need for it two years ago.

And DHCPv6 is a nasty hack that shouldn't exist.

2 Likes
4

Interesting! Maybe it could be marked as a hack or workaround in the UI copy? Any web links explaining the situation?

5

IPv6 was designed to be a decentralized protocol. Clients are supposed to self-generate their addressing, the necessary gear on the network advertises it's capabilities and clients pick what they need. It was supposed to be self-healing and autonomous. Adding in a central configuration like DHCPv6 breaks all of that. You lose a lot of what IPv6 was designed for in the first place. IPv6 addresses are not meant to be static, in the terms of what we consider static for IPv4.

Edit: For clarity, statically assigned, instead of static. Of course you can manually configure a static address.

2 Likes
6

So for these two options

[ ] Enable IPv6 support (SLAAC + RA)
[ ] Enable DHCP rapid commit (fast address assignment)

In what situations would you recommend that they be turned from off (the default), to on?

1 Like
9

I'll let Dom step in to clarify. But to comment, SLAAC is stateless, there is no DHCPv6 involved.

10

Wait, there is some confusion going on here. The setting on the Pi-hole UI is not about rapid commits for DHCPv6 (which is altogether a separte beast!). It is only about rapid commits for IPv4 DHCP.

Instead, enabling this feature does the following according to the documentation (emphasis added):

Enable DHCPv4 Rapid Commit Option specified in RFC 4039. When enabled, dnsmasq will respond to a DHCPDISCOVER message including a Rapid Commit option with a DHCPACK including a Rapid Commit option and fully committed address and configuration information.
Should only be enabled if either the server is the only server for the subnet, or multiple servers are present and they each commit a binding for all clients.

DHCP rapid commit is always a good idea when the requirements above (bold text) are fulfilled. This is basically always the case at home but basically means not always, hence it is disabled by default. DHCPv6 is more experimental and can help with some misbehaving routers. However, I'm not recommending it. But if it can solve an IPv6 issue it's fine to be there.

3 Likes
11

Oh, this is great to read if you want some background:

1 Like
12

Still a bit confusing.. so the only reason to have

[ ] Enable DHCP rapid commit (fast address assignment)

off, is if you have multiple DHCP servers on the network? In the case where there is one, and only one, DHCP server on the network, then this setting makes sense? :thinking:

13

Yes, that's correct. The standard is from 2005. All clients should support it. Just keep in mind that there may be some (ancient) clients out there that that don't work as expected with DHCP rapid commits.

4 Likes
14

A post was split to a new topic: DLink camera and Pi-hole's DHCP rapid commit