Editing Dynamic Host Configuration Protocol (section)

==Reliability==
The DHCP ensures reliability in several ways: periodic renewal, rebinding,{{Ref RFC|2131|rsection=4.4.5}} and failover. DHCP clients are allocated leases that last for some period of time. Clients begin to attempt to renew their leases once half the lease interval has expired.{{Ref RFC|2131|rsection=4.4.5 Paragraph 3}}   They do this by sending a unicast ''DHCPREQUEST'' message to the DHCP server that granted the original lease. If that server is down or unreachable, it will fail to respond to the ''DHCPREQUEST''. However, in that case the client repeats the ''DHCPREQUEST'' from time to time,{{Ref RFC|2131|rsection=4.4.5 Paragraph 8}}{{Efn|The RFC calls for the client to wait one half of the remaining time until T2 before it retransmits the ''DHCPREQUEST'' packet}} so if the DHCP server comes back up or becomes reachable again, the DHCP client will succeed in contacting it and renew the lease.

If the DHCP server is unreachable for an extended period of time,{{Ref RFC|2131|rsection=4.4.5 Paragraph 5}} the DHCP client will attempt to rebind, by broadcasting its ''DHCPREQUEST'' rather than unicasting it. Because it is [[Broadcasting (networking)|broadcast]], the ''DHCPREQUEST'' message will reach all available DHCP servers. If some other DHCP server is able to renew the lease, it will do so at this time.

In order for rebinding to work, when the client successfully contacts a backup DHCP server, that server must have accurate information about the client's binding. Maintaining accurate binding information between two servers is a complicated problem; if both servers are able to update the same lease database, there must be a mechanism to avoid conflicts between updates on the independent servers. A proposal for implementing [[fault-tolerant]] DHCP servers was submitted to the Internet Engineering Task Force, but never formalized.<ref>{{cite IETF
| title = DHCP Failover Protocol
| draft = draft-ietf-dhc-failover-12
| last1 = Droms | first1 = Ralph
| last2 = Kinnear | first2 = Kim
| last3 = Stapp | first3 = Mark
| last4 = Volz | first4 = Bernie
| last5 = Gonczi | first5 = Steve
| last6 = Rabil | first6 = Greg
| last7 = Dooley | first7 = Michael
| last8 = Kapur | first8 = Arun
| date = March 2003
| publisher = [[IETF]]
| access-date = May 9, 2010
}}</ref>{{Efn|The proposal provided a mechanism whereby two servers could remain loosely in sync with each other in such a way that even in the event of a total failure of one server, the other server could recover the lease database and continue operating. Due to the length and complexity of the specification, it was never published as a standard; however, the techniques described in the proposal are in wide use, with open-source and several commercial implementations.}}

If rebinding fails, the lease will eventually expire. When the lease expires, the client must stop using the IP address granted to it in its lease.{{Ref RFC|2131|rsection=4.4.5 Paragraph 9}}   At that time it will restart the DHCP process from the beginning by broadcasting a <code>DHCPDISCOVER</code> message. Since its lease has expired, it will accept any IP address offered to it. Once it has a new IP address (presumably from a different DHCP server) it will once again be able to use the network. However, since its IP address has changed, any ongoing connections will be broken.