[Kea-users] subnet-mask not sent in DHCPINFORM flow

Adonis smooth.map9660 at isadon.com
Tue Nov 10 18:19:37 UTC 2026


Hi Darren,

Yes this is a Stateless DHCP configuration flow. On MacOS 27.2 when the user selects "DHCP with Manual Address" they cannot specify a subnet mask, it is greyed out along with the router; please see attached screenshot. They can specify their client address, which ends becoming the "ciaddr" that kea-dhcp4 sees. In the RFC's I am not sure if the clients are required to specify a subnet mask or if they are prohibited from specifying one and must always request it but I do see that when MacOS sends the request it does also send the "DHCP option 55 param 1" in its DHCP request which basically requests the DHCP server to provide the subnet mask. As you will see in the pcap, kea-dhcp4 doesn't actually send it, even though it matches a subnet in its configuration. As requested the pcap is attached. In the screenshot of the DHCP on MacOS you will also see that it settles on a subnet mask of 255.255.255.255 because kea-dhcp4 never sends the subnet mask. A subnet mask of 255.255.255.255 ends up breaking connectivity.

-- 
Adonis


On Tue, Nov 10, 2026, at 5:16 AM, Darren Ankney wrote:
> Hi Adonis,
> 
> If I understand correctly, you are performing a stateless
> configuration (https://kea.readthedocs.io/en/stable/arm/dhcp4-srv.html#stateless-configuration-of-dhcpv4-clients)?
> Does it make sense to send a subnet mask since you must have already
> configured such IP information on the client?  RFC 2131 section 3.4
> (https://www.rfc-editor.org/info/rfc2131/#section-3.4) says:
> 
> > Servers receiving a
> > DHCPINFORM message construct a DHCPACK message with any local
> > configuration parameters appropriate for the client without:
> > allocating a new address, checking for an existing binding, filling
> > in 'yiaddr' or including lease time parameters.  The servers SHOULD
> > unicast the DHCPACK reply to the address given in the 'ciaddr' field
> > of the DHCPINFORM message.
> 
> which would seem to imply that Kea would not be able to find such
> address related information as subnet mask (since it did not go
> through the process of allocating the address).  Does the MacOS not
> let you manually configure the subnet mask when you are setting an
> address on the interface?
> 
> If you don't mind, a traffic capture file (pcap) that could be opened
> in Wireshark would be very informative here. You can obtain such a
> capture using tcpdump on the kea-dhcp4 server: "tcpdump -i <interface>
> -w <file.pcap> port 67".  Run that command, cause MacOS to send a
> DHCPINFORM, then stop the command.  This file can be opened in
> Wireshark for packet inspection and filtering.  I would be interested
> to see what MacOS requested and what kea-dhcp4 responded with.
> 
> Thank you,
> Darren Ankney
> 
> On Mon, Nov 9, 2026 at 12:00 PM Adonis <smooth.map9660 at isadon.com> wrote:
> >
> > Hi all,
> >
> > So on macOS 27.2, when I configure DHCP with a manual address: 192.168.1.50, kea-dhcp4 (3.2.0) matches the client to one of its subnets in the configuration but sends no subnet-mask (option 1). This causes macOS to set the subnet mask to 255.255.255.255 (instead of 255.255.255.0) and break network connectivity. When using DHCP or DHCP with manual addressing in macOS the subnet-mask cannot be changed, it is meant to use whatever the server sends.
> >
> > In the initial DHCP request (DHCPINFORM option 53) by macOS (src ip 0.0.0.0 to dst ip 255.255.255.255) I can see the ciaddr is correctly set to 192.168.1.50 in the request and the request asks for a subnet mask (DHCP option 55 param 1). Yet in the response from kea no subnet-mask is sent while other options like domain-name, domain-search, domain-name-servers configured for the subnet for 192.168.1.50 are sent. The subnet declaration in kea-dhcp4.conf has "192.168.1.0/24" set and is being matched properly, but it seems the auto subnet mask calculation is not run and the respective subnet-mask field is not sent in response. Given the subnet-mask is explicitly stated to be auto-calculated and managed, this behavior seems like a bug to me.
> >
> > --
> > Adonis
> > --
> > ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> >
> > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> > Kea-users at lists.isc.org
> -- 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> Kea-users at lists.isc.org
> 

-- 
Adonis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20261110/924e6289/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: macOS_dhcp_stateless_subnet_not_configurable.jpeg
Type: image/jpeg
Size: 70357 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20261110/924e6289/attachment-0001.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dhcp_inform_no_subnet_kea.pcap
Type: application/octet-stream
Size: 735 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20261110/924e6289/attachment-0001.obj>


More information about the Kea-users mailing list