Misunderstanding of DHCP/DNS - What is the IP of a machine before DHCPOFFER/DHCPREQUEST

Question

From what little I understand, DHCP allows for dynamic assignment of IP addresses to client machines on a network from a DHCP server. The client transmits a DHCPDISCOVER packet, followed by a DHCPOFFER from the server back to the client, and that can be followed by a DHCPREQUEST and so on.

So if the IP address is formally "assigned" once the server receives the client's DHCPREQUEST packet, is there some generic rule for IP assignment before that point? Made by a router, switch, or network card?

I'm curious because I know I have quite a few misunderstandings about how networks work but also because I'm trying to use wireshark to look at some DHCPOFFER and DHCPREQUEST packets and wireshark of course lists the source and destination IP addresses, but I have no clue what that would be before this whole process finishes. All I know about is the client's MAC address, because /var/log/messages literally just says: DHCPDISCOVER from [MAC ADDRESS]

Answer 1

There is one fundamental point that should be crystal-clear to properly figure out what's happening with DHCP: you're on an Ethernet network... on top of which, IP packets are flowing, inside of which, UDP packets are encapsulated, inside of which DHCP messages are sent/received. In short, you've to consider the whole protocol stack, and not limit yourself to DHCP.

You say: "The client transmits a DHCPDISCOVER packet, followed by a DHCPOFFER from the server back to the client, and that can be followed by a DHCPREQUEST and so on"

As for the "The client transmits" part, you should consider that on an Ethernet network two hosts can "talk" each-other only thanks to MAC-addresses. Those are addresses that are burned by the hardware mufacturer within the physical network adapter on a uniquely basis. As an example, the network adapter of the PC I'm using right now has this MAC: "a4:ba:db:98:fc:a4".

If you think, MAC addresses cannot be defined/assigned on a "random" basis. Actually every vendor has been assigned a fixed "set" of addresses and thanks to this, it's perfectly possibile to know that my network adapter have been built by DELL

So, now, we know that addressing on Ethernet networks is based on MAC addresses (and not IP addresses). This means that in order to effectively route IP packets within Ethernet networks, we need something in order to obtain the MAC address of the destination host. Something like: "I want to send a message to host whose IP address is a.b.c.d; I need it's MAC address; once I get such MAC address, I'll encapsulate my IP packet properly and send it to that MAC address".

You may wonder:

1. what if I don't know the MAC address of the destination host?

or, more high-level on the protocol stack:

2. what if I don't know the IP address of the destination host?

The key concept, here, is the BROADCAST. Both Ethernet and IP provides special addresses to be used exactly when we need to reach someone whose address is, to us, unknown.

Within Ethernet, the special MAC address: ff:ff:ff:ff:ff:ff (48 bits, all at 1), is the broadcast. The Ethernet protocols provides that if you are an Ethernet adapter, you MUST fetch and read:

• packets addressed to your very own MAC address (a4:ba:db:98:fc:a4, in case of my notebook);
• packets addressed to the broadcast address (ff:ff:ff:ff:ff:ff).

This means that:

• if I'm an host that is not yet configured with an IP address and...
• I'm configured to request an IP address based on the DHCP protocol and...
• I normally don't know the MAC address of the DHCP server to ask

then

• I can send a DHCP-request within an Ethernet frame addressed to the Ethernet-broadcast-address (ff:ff:ff:ff:ff:ff).

By doing this:

• every ethernet host, on my LAN, will receive my request;
• all the host that are not running a DHCP-server will simply ignore it;
• the DHCP server will understand that it's a DHCP message and will treat it accordingly.
• the DHCP server will reply (with an Ethernet frame) using its own MAC address as the "source MAC" and its own IP address as "source IP" (so, for me, to send next frame directly to it, and no more via broadcast), and using my MAC address as destination MAC (my MAC was reported in my original frame, in the source_MAC field).

Back to your question, you were wondering about IP-addresses.

Now that we know that DHCP-discover messages are sent to Ethernet broadcast MAC-address, we need to remind that within the Ethernet frame there's, encapsulated, an IPv4 packet. Such IPv4 packet MUST contain a SOURCE_IP address and a DESTINATION_IP address. In this very particular case (the DHCP-discover message), the sending host doesn't know none of the two:

• it doesn't know it's own IPv4 address, as it's exactly what's is starting to ask for. As such, the source address field will be set to 0.0.0.0;

• it doesn't know the IPv4 address of the DHCP-server. As such, the destination address field will be set to 255.255.255.255 (guess what? 32 bits, set to 1. Do you note similarities?)

Please note that in this very particular case (the DHCP-discover) both such addresses... are mostly useless: MAC addresses are what counts (again: in this DHCP-discover frame).

Let me add a final note. You wrote: "I'm trying to use wireshark to look at some DHCPOFFER and DHCPREQUEST packets and wireshark of course lists the source and destination IP addresses". Wireshark, as every packet sniffer running on ethernet networks, reports to you LOTS of things, including source-mac-address and destination-mac-address.

Actually Wireshark will really help you in understanding the encapsulation process, 'cause you'll see exactly the Ethernet-Layer (Layer 2) addressed with MACs, containing, inside, the Layer 3 (IPv4) containing the IP packet. Also, within IP you'll see the UDP packet with inside the DHCP-message.

I'm expecting you launched the wireshark capture without any filter. This 'cause if you use filters, you run the risk to not capture all that you need (remind about broadcast and address-less frames/packets).

---

P.S.: I beg for pardon to all of the very technician reading this message: I know I've been _extremely_ general and plenty of not-scritcly-and-formal concepts. I know. I thought it's needed to help @krb686 entering the networking world that I like so much :-)

Answer 2

It has no IP before it has an IP.

An example DHCP Discover packet sets the source IP to 0.0.0.0 and the destination is 255.255.255.255 to broadcast to every host on the local net.

The reply from the server goes to the client's MAC address. When you say All I know about is the client's MAC address - that's all the DHCP server knows about as well, and that's enough.

However, there is a standard for hosts to assign themselves an IP, which usually happens if a DHCP request fails. These IPs are in the 169.254.0.0/16 range.

http://packetlife.net/blog/2008/sep/24/169-254-0-0-addresses-explained/

When a host fails to dynamically acquire an address, it can optionally assign itself a link-local IPv4 address in accordance with RFC 3927. Microsoft's term for this is Automatic Private Internet Protocol Addressing (APIPA).

So it's possible a host has a self-assigned link-local address if it has tried DHCP before and failed to get an address, and is now trying DHCP again.

(And this has nothing to do with DNS)

Answer 3

The client doesn't have an IP address until the DHCP handshake completes successfully.

The reason it works and you don't hit a 'chicken and egg' problem is that an IP address isn't necessary for two hosts to communicate within the same subnet - it can be done using just the MAC addresses.

Answer 4

DHCP is done over UDP which means, yes, it does use IP addresses. The destination is broadcast and the source is 0.0.0.0 for the client or the ip for the server for server replies.