On 22.05.2024 12:57, Francis Dupont wrote: > Looking the RFC 8925 to try to understand how it is supposed to work... > I think you should add a pool and have the client to ignore the offered > address (it is the only MUST in client and server behaviors which can make > the feature to work). I leave further details to Tomek who is one of the > authors... The option 108 is partially supported by Kea. The option itself can be configured and sent back to client. That part should work fine.
The RFC8925 also says that the server should send back a response (DHCPOFFER or ACK) with 0.0.0.0 address. Kea doesn't allow that yet. There's a ticket about it (#3094) and we hope to implement this logic sometime soon. For completeness, here's the relevant RFC text: The server SHOULD NOT assign an address from the pool. Instead, it SHOULD return 0.0.0.0 as the offered address. Alternatively, if offering 0.0.0.0 is not feasible -- for example, due to some limitations of the server or the network infrastructure -- the server MAY include in the DHCPOFFER an available IPv4 address from the pool, as per recommendations in [RFC2131]. In this case, the offered address MUST be a valid address that is not committed to any other client. Because the client is not ever expected to request this address, the server SHOULD NOT reserve the address and SHOULD NOT verify its uniqueness. If the client then issues a DHCPREQUEST for the address, the server MUST process it per [RFC2131], including replying with a DHCPACK for the address if it has not been committed to another client in the meantime. Hope that helps, Tomek -- 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 mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
