alternative dhcp server?

[mcb30]

(2011-08-25 16:14)patpat Wrote:  about chainloading:
1) I think the $USERCLASS$” is kind of an ugly hack, non portable to other DHCP servers, etc etc…

The primary constraint is the requirement to work out-of-the-box with the Microsoft DHCP server, which has very limited support for conditional responses. This DHCP server can vary the response based on the DHCP user class, and we can use an iPXE-specific user class without running afoul of any of the various specifications (DHCP, PXE, etc.).

ISC dhcpd is flexible enough to cope with pretty much any scheme; it's just simplest to document a scheme that works in exactly the same way for both ISC dhcpd and the Microsoft DHCP server.

Quote:2) Dispatching different payloads for option 67 on different DHCP answers it represents also a problem; DHCP (v4) is a stateless protocol, and DHCP server engines (v4) are stateless, I do not consider changing the protocol engine to statefull would be a good approach.

Using the DHCP user class to determine the response is still stateless. The response depends only upon the request. No state is retained by the server.

Quote:3) Then why not answering the “file” field blank and both options 67 “in the same DHCP answer”?…
I think making ipxe able to chose option 67 #2, or #3 or #whatever should be very easy to do (from a programmers point of view), and also it would be completely portable..

1. You won't be able to persuade most DHCP servers to specify multiple versions of option #67 in the same packet.
2. Even if you could do so, you'd be violating the DHCP standard by treating them as separate options. RFC3396 (and RFC2131) state that "when more than one option with a given type code appears in the DHCP packet, all such options should be concatenated together".
3. You would still need some way to specify which of the equivalent options was intended to be used.
   

Michael