-1

RFC2131 section 3.1 describe the DHCP working flow as follows:

            Server          Client          Server
        (not selected)                    (selected)

              v               v               v
              |               |               |
              |     Begins initialization     |
              |               |               |
              | _____________/|\____________  |
              |/DHCPDISCOVER  | DHCPDISCOVER \|
              |               |               |
          Determines          |          Determines
         configuration        |         configuration
              |               |               |
              |\              |  ____________/|
              | \________     | /DHCPOFFER    |
              |  DHCPOFFER\   |/              |
              |            \  |               |
              |       Collects replies        |
              |              \|               |
              |     Selects configuration     |
              |               |               |
              | _____________/|\____________  |
              |/ DHCPREQUEST  |  DHCPREQUEST\ |
              |               |               |
              |               |     Commits configuration
              |               |               |
              |               | _____________/|
              |               |/ DHCPACK      |
              |               |               |
              |    Initialization complete    |
              |               |               |
              .               .               .
              .               .               .
              |               |               |
              |      Graceful shutdown        |
              |               |               |
              |               |\ ____________ |
              |               | DHCPRELEASE  \|
              |               |               |
              |               |        Discards lease
              |               |               |
              v               v               v
 Figure 3: Timeline diagram of messages exchanged between DHCP
           client and servers when allocating a new network address

My question is: As for client requsting an IP address, What's the benefit of two phase packet exchange? I think it's sufficient to only define DHCPREQUEST/DHCPACK .

I mean, I hope someone can cite a case where DHCPDISCOVER can bring benefit to the working of the protocol.

Reducing one packet exchange(specifically involving MAC broadcast) reduces the risk of packet lost, especially on some not-so-reliable medium, such as 802.11 wireless network.

Jimm Chen
  • 1,759
  • 5
  • 18
  • 32
  • 3
    You probably need to discuss this with the authors of the RFC who will probably have good engineering reasons for doing it this way. As sysadmins we (mostly) just use the tool as designed. – user9517 May 14 '13 at 10:03
  • I feel sad this question gets closed in a half day. Maybe the power users think the world will not be changed even if this question is answered. But I think, thinking always has the potential to change the world, maybe in the far future. – Jimm Chen May 15 '13 at 01:07
  • 1
    Please read the faq carefully it provides insights into why your question was closed and as to why this is not a good Server Fault question. – user9517 May 15 '13 at 06:45
  • Enough. I definitely conform to the FAQ. FAQ question criteria one: "Server and Business Workstation operating systems, hardware, software and virtualization". DHCP is about server software, right? – Jimm Chen May 16 '13 at 00:42
  • 2
    No, your question as stated is about the design rationale... of a piece of software. To know the answer to this you need to ask the people who designed it and as such your question faile the practical answerable test. – user9517 May 16 '13 at 06:01
  • I just don't know which person on the earth to ask at this moment, so I ask it here and hope someday someone can answer it then I can accept the most reasonable one. Well, to make my question more answerable, I add a statement to clarify it. – Jimm Chen May 16 '13 at 06:34
  • You did get an answer about who to ask - the authors of the RFC. – Jenny D May 16 '13 at 12:13
  • I tried sending mail to RFC2131's author, the 15 year-old email address droms@bucknell.edu turns out to no longer exist. http://i.stack.imgur.com/5utZ1.png . So am I entitled to ask here now? It is rediculous I have to contact the author before I can ask question here, if so, 90% of the question should be marked [closed]. I insist my question in this case is decent, clear and no-nonsense, don't abuse your power to close it just because you think you know what DHCP is but only have a scanty knowledge of it. – Jimm Chen May 18 '13 at 07:56

1 Answers1

3

The benefit of sending a discovery out and then sending a request to just one of those servers that responded is that you don't get all the DHCP servers going through the process of allocating an IP address.

I can't think of many reasons to have multiple DHCP servers handling the same clients (other than redundancy), but if you have, a single stage process would end up with DHCP servers allocating an IP address that never gets used. It makes sense for the client to search for DHCP servers, then actually ask one of them to allocate the IP address in a second step.

USD Matt
  • 5,391
  • Thank you for responding. BUT... If the premise is we always follow the wise practice to deploy ONLY ONE DHCP server on one network segment, then your statements about downside of DHCP servers makes little sense. Right? client to search for DHCP servers don't make senses as well which violates the benefit of DHCP's auto-configuration nature. Did you see Windows or MAC present a facility about choosing which DHCP server to use? Maybe there is some historic reason, and I hope someone can provide a hint here. – Jimm Chen May 15 '13 at 01:03
  • Why do you think it's always the best practice to only have one DHCP server? I already gave one good example of why you might have multiple - redundancy - one DHCP server fails, everything continues to work as normal (assuming you gave both servers non-overlapping ranges within the same subnet). There's no reason for a computer to give you a choice of DHCP server, it'll just use the first one it gets an offer from. – USD Matt May 15 '13 at 12:20
  • Easily found in the DHCP RFC: A DHCP client must be prepared to receive multiple responses to a request for configuration parameters. Some installations may include multiple, overlapping DHCP servers to enhance reliability and increase performance. – USD Matt May 15 '13 at 12:20
  • I don't agree. If we could have used DHCPREQUEST alone, client can still choose from one of the overlapping responses. – Jimm Chen May 16 '13 at 00:39
  • Did you see Windows or MAC present a facility about choosing which DHCP server to use? well no. They don't need to because that's already taken care of by the very part of the design of the protocol that you are disputing. Essentially, choosing the fastest responder this way also provides a primitive form of load balancing too. http://serverfault.com/questions/368512/can-i-have-multiple-dhcp-servers-on-one-network talks about multiple DHCP servers on the same scope. – Rob Moir May 16 '13 at 07:18
  • As I said in the answer, doing it with just DHCPREQUEST would end up with both servers allocating an address as used (not really an acceptable solution). If you're only concern is that sending a broadcast following by a response packet is safer than a broadcast and 3 packets, then getting an address is the least of your worries, the network is unusable anyway. – USD Matt May 16 '13 at 08:31
  • Just to be clear, making it one step would still require a broadcast as the clients still have to find a DHCP server. You'd either have to modify DHCP to have servers reply to DHCPDISCOVER with an allocated address (and end there), or have the DHCPREQUEST broadcast on the network and, again, have DHCP servers reply with an allocated address. You can't get away from having the broadcast. – USD Matt May 16 '13 at 08:37
  • 1
    There is an actual use case of multiple DHCP servers serving a single client: remote install environments often use split servers - one providing the IP address, another one the PXE boot options. – the-wabbit May 16 '13 at 11:50
  • I actually have multiple DHCP servers in use on a wireless project. If one fails I can go on-site and fix when convenient, rather than it stopping clients working and having to rush out 24x7. – USD Matt May 16 '13 at 13:31
  • I check the link of RobM; his answer is great and I specially agree with the "50/50 split" scheme. So to Matt, "end up with both servers allocating an address" is totally acceptable in my opinion if your do want that redundancy. If someone agree with the 50/50 split deployment, then he should agree DHCPDISCOVER is verbose. The other hand, I admit DHCP must work with broadcast, but we shoud strive to use it less often. If you know 802.11 protocol, you should know broadcast is vulnerable, because broadcast packet does not get 802.11 link-layer retransmission. – Jimm Chen May 17 '13 at 02:23
  • From RobM's link, I really doubt the "80/20 split" is a good practice. As RobM points out: How can you guarantee the "main" DHCP server always respond quicker than the "aux" one? So we may hope there is a "delay answering" option on the server side. Is there? – Jimm Chen May 17 '13 at 02:33
  • I believe the DHCP client will retry the request if it does not get a response so loss of the broadcast is not critical. Personally I agree with the DHCP designers that the current method makes more sense. As I said above, if DHCP doesn't work then you have bigger problems. Also, any sort of split doesn't work if all servers allocate an address, you'd need to have a scope of unique addresses big enough to fit all clients on every DHCP server. – USD Matt May 17 '13 at 08:15
  • "any sort of split doesn't work if all servers allocate an address,"??? Why??? Give me a case. RobM's 50/50 split case works very well. – Jimm Chen May 18 '13 at 07:56
  • Coming back one year later, now I come to agree that "a single stage process would end up with DHCP servers allocating an IP address that never gets used". Thank you Matt. – Jimm Chen Apr 30 '14 at 00:55