Does DHCP protocol allow a server to offer multiple addresses to clients instead of just one? [closed]

Question

This is an exam question of Internet Protocol.

I thought the answer is "NO" but I want to make sure.

Answer 1

You'll find what you're looking for here (and if you actually bother to read it you'll learn something, as opposed to just having the answer given to you).

Answer 2

A server of this protocol assigns an IP address per MAC address. So YES the protocol can support multiple IP addresses per Host given multiple NICs.

Answer 3

As far as I know the answer is no. not at the same time. (at least if the client have 1 nic)

Answer 4

Sure enough, a single DHCP server will not supply multiple addresses to one client and let it choose.

But if you have more than one DHCP servers on your network (for redundancy in legacy windows (2003) environments?) a client will often get one DHCPOFFER from each DHCP server. Then, the client chooses one server to send his DHCPREQUEST to. Usually the client takes the server which answered first.

Answer 5

The answer is yes. It has to use a separate DHCPOFFER message for each IP address it wishes to offer. The client has to be programmed to wait some amount of time to see if it receives additional DHCPOFFER messages rather than responding to the first one.

This is most commonly used when there's more than one DHCP server. It is not unusual to have two DHCP servers on a subnet for redundancy. Often each DHCP server handles a different range of IP addresses. So the client may receive two offers, one from each server. To be general, the spec just says that a client may receive some number of offers from some number of servers and may choose which to accept.

Typically clients just accept the first offer they receive, but the specification is clear that they do not have to.

RFC 2131 3.1 3 says:

The client receives one or more DHCPOFFER messages from one or more servers. The client may choose to wait for multiple responses. The client chooses one server from which to request configuration parameters, based on the configuration parameters offered in the DHCPOFFER messages. The client broadcasts a DHCPREQUEST message that MUST include the 'server identifier' option to indicate which server it has selected, and that MAY include other options specifying desired configuration values. The 'requested IP address' option MUST be set to the value of 'yiaddr' in the DHCPOFFER message from the server.

By the way, it is entirely unreasonable to expect someone to know this off the top of their head without reference to the RFC. It's an obscure detail that isn't relevant to any real-world implementation that I know of.

In fact, it's possible that if you actually used it, it might confuse a client that hadn't been coded with this possibility in mind. For example, consider a client that has a table, indexed by server, that tracks the IP it was offered. The client might receive one DHCPOFFER, accept it, and then when it receives the second DHCPOFFER from the same server, it might overwrite the IP address entry for that server, losing track of the IP address it had accepted. This client is broken, of course, but such an error could lay undetected for years.