[dhcwg] dhcp request

Client behavior is governed by which of six "states"  the client is in at
the time a DHCP message is sent.  Server responses are governed by the
content of the client's message, and the server's awareness of the network
at the time.

In the instance you describe, the client interface seems to have been
previously configured via DHCP.  It may or may not have a valid lease, or
it may not know if a lease is still valid.  This, plus the indication that
the DHCPREQUEST message was broadcast could mean that this client
interface is in the INIT-REBOOT state, and may or may not respond to an ARP
or PING.  For this reason, it would not be fruitful for a server to test
the address.

In the INIT-REBOOT state the DHCPREQUEST message is broadcast, because the
client may have been moved to a different area of the network, and could
need address assignment from a different server.  (The client needs to get
a DHCPNAK message from any server in this case).

Overall, DHCP makes very efficient use of the number and scope of packets
sent between client and server.    For example, a client may receive offers
from multiple servers in response to a DHCPDISCOVER message it sent.  The
client broadcasts a DHCPREQUEST message that contains the id of the server
it has selected.  In this manner, the client accepts one offer and rejects
all others with a single packet.

I am told that Chapter 3, of the IBM Redbook "Beyond DHCP, Work Your
Internetwork with Dynamic IP" contains a good explanation of the client
states, and different DHCP messages.  You might find this book to be a
helpful companion to the RFCs.  At one time this book was free at
www.redbooks.ibm.com

Regards,
Bob

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg