What is the IP of host when it is in DHCP INIT-REBOOT and REBOOTING status ?

[sheepuking wu]

Hi,

According to description of RFC2131,  if host is in INIT-REBOOT status, it will send DHCP Request to ask DHCP Server if it can reuse previous IP. After sending DHCP Request, the host is in "REBOOTING" status. If the host receives DHCPACK that describes this IP can be reused, it will be "Bound" status and start to use previous IP.  But what is the IP of this host when it is in INIT-REBOOT and REBOOTING status ? I found my personal computer starts to use previous IP in INIT-REBOOT status. Is there any RFC document that describes host can start to use previous IP in INIT-REBOOT status ?

Thanks for your teaching!

BR.

Karl

[Rob Cluett]

Fairly confident the IP is 0.0.0.0.  I ran into this when my LXC's were retrieving their DHCP address from the DHCP Server.

[Rob Cluett]

This article backs it up.  Note that the source ip address in the DHCP Discover and DHCP Request State is 0.0.0.0.

https://support.microsoft.com/en-us/help/169289/dhcp-dynamic-host-configuration-protocol-basics

[sheepuking wu]

Hi 2rcluett,

Thanks for your reply. The operation system of my host is Windows 7, when the host is sending DHCP Request in INIT-REBOOT, the source IP of DHCP packet is indeed 0.0.0.0 , but I type DOS command "ipconfig/all" , I found the IP of the host is previous IP instead of 0.0.0.0. And another host can use this previous IP to communicate with my host by ICMP packet. Is this the reasonable result ?

Thanks for your teaching!

BR.

Karl

[Rob Cluett]

I don't believe you would ever see the DHCP address of 0.0.0.0 in ipconfig /all. You would, however, see it in a packet capture.

Do you have the ability to run a pcap?  You could capture traffic forcing DHCP into the appropriate scenario and see what the src. ip is in the traffic.  Alternatively I may be able to run one for you here once I modify my lab.

[Rob Cluett]

Run a Wireshark from your desktop while performing the scenario and post the .pcap file here.  We can take a look at it together.

[sheepuking wu]

Hi Cluett,

I can capture the DHCP packets by Wireshark and capture the result of "ipconfig/all", but my operation system is Chinese Windows 7, so the result of "ipconfig/all" can include Chinese words. And I can't make operation system become English Windows 7.

If it is OK that I post the result of "ipconfig/all" that includes Chinese words, I will post the result of my test includes result of "ipconfig/all" and captured DHCP packets here in the future.

BR.

Karl

[Rob Cluett]

OK.  I'll wait for the capture. Thanks for the update.

[Rob Cluett]

Here's a procedure for an embedded packet capture.  It can be done from a router or switch as long as you're running the right code.  I know 15.x has the feature.

https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-embedded-packet-capture/116045-productconfig-epc-00.html?dtid=osscdc000283

[Rob Cluett]

Here's a capture with the first set of 4 being when the host is powered on. The second set is during a renew.  It appears in all cases that 0.0.0.0 is the client IP address.  One thing to keep in mind is that if you're on a small network it's going to grab the first available IP from the DHCP server.  If no other client's exist on the network you'll likely get the same IP.  This scenario was done with a linux client not a windows client.

DHCP Discover (power on)

DHCP Offer (power on)

DHCP Request  (power on)

DHCP Ack (power on)

Client IP Address (after power on)

DHCP Discover (during renew)

DHCP Offer (during renew)

DHCP Request (during renew)

DHCP Ack (during renew)

Client IP Address (after renew)

[sheepuking wu]

Hi Cluett,

Thanks for your reply.

The following two figures is my captured DHCP Request Packet.

When host sends this DHCP Request , it is in INIT-REBOOT status.

I have questions about these two figures are as follow:

1. About the first figure, my host runs ARP Probe immediately after it sends DHCP request, so it can verify that the host wants to set IP as "192.168.208.204" firstly before DHCP Server replies DHCP ACK. I think this action confuses me, why it wants to set IP firstly without getting permission from DHCP Server ?

2. About the second figure, all the packets except for DHCP Request have source IP "192.168.208.204", but when host sends DHCP Request again, source IP of this packet is still "0.0.0.0". This result confuses me. Why the source IP of DHCP Request and other packets are inconsistent ? Why all the packets except for DHCP Request include source IP "192.168.208.204" rather than "0.0.0.0" ?

Thanks for your teaching!

BR.

Karl

[Rob Cluett]

I'm learning too... :)

I think one thing to keep in mind is that the DHCP request is happening at Layer 2 and the 0.0.0.0 address is really being used as a null address (more of a place holder). If you look further in the packets the request are dependent on the MAC addresses.

This behavior, where a host is asking to use a specific IP address, is new to me and looks to be something unique to Windows. I do agree that it looks like its using the IP address that it's requesting from the DHCP server before the DHCP server agrees to allocate it to the host.

Can you filter your Wireshark to the DHCP protocol. I'd be interested in seeing all DHCP traffic.  Also wondering if you can post the pcap to this discussion so I can take a look?

In the meantime I did my own wireshark of a Windows 10 reboot.  I see the same condition you are talking about.  It begins using the IP without going through all the phases of a DHCP Request.

Notice the 3 ARP requests.  I wonder if Windows logic has a timeout or counter such that if no one responds to the ARP it assumes the IP without permission from the DHCP server.

It has the IP as early as packet 6.  Note the sender IP.

[sheepuking wu]

Hi Cluett,

The attachment is my pcap file. Actually I am confused with the behavior that Windows 7 or 10 uses previous IP before DHCP Server agrees to allocate.  For example, assume the previous IP is 192.168.208.204, if my host disconnects from original NAT and reconnects to another NAT which has allocated 192.168.208.204 to other host, then two host will use identical IP 192.168.208.204 and IP conflict is occurred.

Of course I know the probability that occurs above event is very low, but I believe this probability is larger than zero and the risk is exist.

Do you agree my description ?

Thanks a lot!

BR.

Karl

[Rob Cluett]

Yes. I'm confused on how this works when trying to reclaim the last IP used.  It's as if the DHCP server is not involved in the process at all. When you filtered the packets did you include DHCP communication from the server to host with IP 0.0.0.0?  Your packet capture only shows traffic going in one direction.

[sheepuking wu]

Hi Cluett,

The reason that packet capture only shows traffic going in one direction is my operation of procedure.

My procedure is as follow:

Step 1, make my host connect with DHCP Server, and get dynamic IP successfully.

Step 2, make my host disconnect from DHCP Server.

Step 3, make my host connect with other host rather than DHCP server.

Step 4, then my host links up its Ethernet card, and it start to send DHCP Request.

But my host doesn't connect with DHCP server, so it can get any reply from DHCP server and my capture file doesn't include any reply of DHCP server.