0

This question already has an answer here:

I know this is the DHCP process:

  1. Discover: Host broadcasts “DHCP discover” message
  2. Offer: DHCP server responds with “DHCP offer” message
  3. Request: host requests IP address: “DHCP request” message
  4. Acknowledge: DHCP server sends address: “DHCP acknowledge” message

My question is, how the DHCP server knows who sent the broadcast if the sending computer don't have an IP yet?

marked as duplicate by Ron Maupin, Ricky Beam, Craig Constantine Feb 25 '16 at 0:40

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

3

how the DHCP server knows who sent the broadcast if the sending computer don't have an IP yet?

The server usually identifies the client by its MAC address. However, it might use the field 'client identifier' option, if present.

See also:

1

The sending computer is known by its physical address (MAC address).

1

Any frame sent across a broadcast domain has some bits set in it's PDU which identifies the sending device in that domain: the MAC address. That address is the only one which is needed to carry a message to a certain destination (in this case, the DHCP client). In this particular case, when the broadcast message is sent to 255.255.255.255 the special ff:ff:ff:ff:ff:ff MAC address is used for destination, which means that all devices in the domain should recieve the message. The following table contains the value of some of the attributes of the DHCPDISCOVER and DHCPOFFER messages:

Attribute        | DHCPDISCOVER      | DHCPOFFER
-----------------+-------------------+-------------------
Source MAC       | <Client MAC>      | <Server MAC>
Destination MAC  | ff:ff:ff:ff:ff:ff | <Client MAC>
Source IP        | 0.0.0.0           | <Server IP>
Destination IP   | 255.255.255.255   | 255.255.255.255
Transport        | UDP               | UDP
Source Port      | 68                | 67
Destination Port | 67                | 68

When the client sends the DHCPDISCOVER message every device in the broadcast domain recieves that message, in which the client's own MAC address is included as the source. One of the recipient devices of that message is the DHCP server, which in turns may answer with a DHCPOFFER to the MAC address of the client, and that's why the client gets the message.

If it happens that the broadcast domain is also a colision domain (like a HUB) then every device connected in that network recieves every message sent across that network and all but the device owning the message's destination MAC address will silently discard the message. If, on the contrary, the network is switched (or bridged) then it is a broadcast domain but not a colision domain (every single paired physical connection between two devices is a colision domain). In such a network the switches or bridges understand the IP protocol and also the Address Resolution Protocol (ARP), which helps that device remember in which port is found an originating MAC address and when a message is sent to a specific MAC address, creating a map of MAC address - IP address.

When the DHCP server sends a message to a known MAC address, such as the one of the DHCP client's one, the intermediate switches or bridges know exactly to which port should they transmit the message because they remember where the DHCPDISCOVER (with the source MAC address matching the current message's destination) came from. In the case they don't remember, they simply send the message to every port, similarly to the case of the HUB (that is the purpose of ARP poisoning, for example).

Not the answer you're looking for? Browse other questions tagged or ask your own question.