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:
- what if I don't know the MAC address of the destination host?
or, more high-level on the protocol stack:
- 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 :-)