Dynamic Host Configuration Protocol
From Computing and Software Wiki
| Line 1: | Line 1: | ||
| - | '''Dynamic Host Configuration Protocol''' ('''DHCP''') is a client/server protocol used to enable clients to obtain configuration information for operation in an [[Internet_Protocol|IP]] network. DHCP is used to shrinks system administration workload by permitting DHCP clients to be added to an IP network with little or no manual intervention through the allocation of network addresses and additional configuration option. | + | '''Dynamic Host Configuration Protocol''' ('''DHCP''') is a client/server protocol used to enable clients to obtain configuration information for operation in an [[Internet_Protocol|IP]] network. DHCP is used to shrinks system administration workload by permitting DHCP clients to be added to an IP network with little or no manual intervention through the allocation of network addresses and additional configuration option. |
| - | DHCP is defined by two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocation of network addresses to hosts. | + | DHCP is defined by two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocation of network addresses to hosts. <sup>[1]</sup> |
==History== | ==History== | ||
| - | DHCP was created by the Dynamic Host Configuration Working Group at the [http://www.ietf.org/ Internet Engineering Task Force (IETF;] a volunteer organization which defines protocols for use on the Internet). It was originally defined in RFC 1531 in October 1993 as a superset of the BOOTstrap Protocol (BOOTP). It was further refined with corrections and more options in RFC 1541 in the same month. The current definition of DHCP for IPv4 networks is in RFC 2131, released in March 1997. Various DHCP options available as of March 1997 are discussed in RFC 2132. DHCPv6, the extension of DHCP for IPv6, is defined in RFC 3315. | + | DHCP was created by the Dynamic Host Configuration Working Group at the [http://www.ietf.org/ Internet Engineering Task Force (IETF;] a volunteer organization which defines protocols for use on the Internet). It was originally defined in RFC 1531 in October 1993 as a superset of the BOOTstrap Protocol (BOOTP). It was further refined with corrections and more options in RFC 1541 in the same month. The current definition of DHCP for IPv4 networks is in RFC 2131, released in March 1997. Various DHCP options available as of March 1997 are discussed in RFC 2132. DHCPv6, the extension of DHCP for IPv6, is defined in RFC 3315.<sup>[2,3]</sup> |
===The Need For DHCP=== | ===The Need For DHCP=== | ||
| Line 15: | Line 15: | ||
BOOTP works well in relatively static environments. However, as computers got smaller and lighter, it was common for them to move from one network to another, requiring a new IP address while the previous one was still assigned to it until manual intervention. Keeping track of all these IP address changes became be a daunting task. This coupled with the limited number of IP addresses in an organization lead to a new protocol. | BOOTP works well in relatively static environments. However, as computers got smaller and lighter, it was common for them to move from one network to another, requiring a new IP address while the previous one was still assigned to it until manual intervention. Keeping track of all these IP address changes became be a daunting task. This coupled with the limited number of IP addresses in an organization lead to a new protocol. | ||
| - | To automate configuration, the IETF created DHCP to allow for the dynamic allocation of network addresses and configurations to newly attached hosts with no manual intervention. DHCP was originally designed as a successor to BOOTP. As such, it maintains some backward compatibility and many DHCP servers support BOOTP clients. DHCPv6 drops this compatibility to produce a cleaner implementation. | + | To automate configuration, the IETF created DHCP to allow for the dynamic allocation of network addresses and configurations to newly attached hosts with no manual intervention. DHCP was originally designed as a successor to BOOTP. As such, it maintains some backward compatibility and many DHCP servers support BOOTP clients. DHCPv6 drops this compatibility to produce a cleaner implementation.<sup>[4]</sup> |
==Technical Overview== | ==Technical Overview== | ||
| - | [[Image:BasicDHCP.jpg|right|thumb|300px|Basic DHCP process< | + | [[Image:BasicDHCP.jpg|right|thumb|300px|Basic DHCP process<sup>[12]</sup>]] |
| - | DHCPv4 utilizes UDP port 67 for the server side and UDP port 68 on the client side. | + | DHCPv4 utilizes UDP port 67 for the server side and UDP port 68 on the client side.<sup>[3]</sup> |
In most DHCP client/server software, DHCP uses the following basic process, see Technical Details for a more indepth explanation). | In most DHCP client/server software, DHCP uses the following basic process, see Technical Details for a more indepth explanation). | ||
| Line 28: | Line 28: | ||
#All DHCP servers on the network that receive the message and contain a valid address configuration for the client send an IP address offer back to the DHCP client. | #All DHCP servers on the network that receive the message and contain a valid address configuration for the client send an IP address offer back to the DHCP client. | ||
#From the offers received, the client chooses an IP address configuration to use. The server that sent the offer the client selected, receives a broadcasted request message to use the selected configuration. The other DHCP servers that sent offers receive this broadcasted message, realize the request for another server, and reclaim the offered IP address. | #From the offers received, the client chooses an IP address configuration to use. The server that sent the offer the client selected, receives a broadcasted request message to use the selected configuration. The other DHCP servers that sent offers receive this broadcasted message, realize the request for another server, and reclaim the offered IP address. | ||
| - | #The DHCP server selected by the client, assigns the IP address configuration to the DHCP client and sends an acknowledgement message to the client to verify the acceptance.[ | + | #The DHCP server selected by the client, assigns the IP address configuration to the DHCP client and sends an acknowledgement message to the client to verify the acceptance.<sup>[5]</sup> |
| - | After the client obtained an IP address, the client may start an address resolution (ARP) query to prevent IP conflicts caused by address pool overlapping of DHCP servers. [ | + | After the client obtained an IP address, the client may start an address resolution (ARP) query to prevent IP conflicts caused by address pool overlapping of DHCP servers.<sup>[3]</sup> |
====Lease Renewal==== | ====Lease Renewal==== | ||
| - | Before the lease time expires, the client will request to extend the lease by sending a request to the server. The server will update and extend the lease time and send an acknowledgment message to the client, letting it know the lease has been extended. If the client does not receive an acknowledgement message, it assumes the server is down and tries to renew the lease again after the lease period is 87.5% done. If it does not receive and acknowledgement this time, it will retry renewing one last time. If the client does not receice a response this final time, the lease expires and it releases the IP and starts at step 1 above. | + | Before the lease time expires, the client will request to extend the lease by sending a request to the server. The server will update and extend the lease time and send an acknowledgment message to the client, letting it know the lease has been extended. If the client does not receive an acknowledgement message, it assumes the server is down and tries to renew the lease again after the lease period is 87.5% done. If it does not receive and acknowledgement this time, it will retry renewing one last time. If the client does not receice a response this final time, the lease expires and it releases the IP and starts at step 1 above.<sup>[6]</sup> |
| - | + | ||
===Address Allocation Policies=== | ===Address Allocation Policies=== | ||
| - | Generally, depending on the implementation, there are three methods for a DHCP Server to allocate IP-addresses. It is also possible to combine these methods, in a hybrid allocation policy. [ | + | Generally, depending on the implementation, there are three methods for a DHCP Server to allocate IP-addresses. It is also possible to combine these methods, in a hybrid allocation policy.<sup>[7]</sup> |
====Manual (or Static) Allocation==== | ====Manual (or Static) Allocation==== | ||
| Line 43: | Line 43: | ||
====Dynamic Allocation==== | ====Dynamic Allocation==== | ||
| - | The DHCP Server's administrator specifies a pool of IP addresses to be automatically assigned to clients for a specified limited period of time. IP address that are not renewed before the period of time ends or have their lease canceled are reclaimed and can be reallocated. | + | The DHCP Server's administrator specifies a pool of IP addresses to be automatically assigned to clients for a specified limited period of time. IP address that are not renewed before the period of time ends or have their lease canceled are reclaimed and can be reallocated.<sup>[2,3]</sup> |
====Automatic Allocation ==== | ====Automatic Allocation ==== | ||
| - | The DHCP Server's administrator specifies a pool of IP addresses to be permanently assigned to clients. Upon request, a free IP address in this range is automatically assigned to a client. Once associated with a client, the IP address is permanently assigned to the client until the server's administrator intervenes. Many DHCP Servers do not implement this method of allocation, as it can be approximated with long lease times in dynamic allocation. | + | The DHCP Server's administrator specifies a pool of IP addresses to be permanently assigned to clients. Upon request, a free IP address in this range is automatically assigned to a client. Once associated with a client, the IP address is permanently assigned to the client until the server's administrator intervenes. Many DHCP Servers do not implement this method of allocation, as it can be approximated with long lease times in dynamic allocation.<sup>[2,3]</sup> |
| - | [ | + | |
| - | + | ||
====Hybrid Allocation Policies==== | ====Hybrid Allocation Policies==== | ||
| - | There are various hybrid allocation possibilities with DHCP. One common one is the DHCP Server's administrator creates a list of allowed clients without assigning them fixed IP addresses. These allowed clients can then acquire a dynamically allocated IP address whenever they connect. This allows the administrator to limit the use of DHCP without the need for manual intervention every time a client moves. | + | There are various hybrid allocation possibilities with DHCP. One common one is the DHCP Server's administrator creates a list of allowed clients without assigning them fixed IP addresses. These allowed clients can then acquire a dynamically allocated IP address whenever they connect. This allows the administrator to limit the use of DHCP without the need for manual intervention every time a client moves.<sup>[2,3]</sup> |
==Technical Details== | ==Technical Details== | ||
===DHCP Initialization=== | ===DHCP Initialization=== | ||
| - | DHCP operations fall into four basic phases. These phases are IP discovery(DHCPDISCOVER), IP lease offer(DHCPOFFER), IP request (DHCPREQUEST), and IP lease acknowledgment (DHCPACK).[ | + | DHCP operations fall into four basic phases. These phases are IP discovery(DHCPDISCOVER), IP lease offer(DHCPOFFER), IP request (DHCPREQUEST), and IP lease acknowledgment (DHCPACK).<sup>[3]</sup> |
====DHCP Discovery==== | ====DHCP Discovery==== | ||
Upon connection to a network, the DHCP client will send out a broadcast message on the physical subnet to find DHCP servers. This message is in the form of a UDP DHCPDiscover packet and usually at least contains the clients MAC address in the OPTIONS section, with the broadcasted destination of 255.255.255.255 (or 0.0.0.0, depending on the implementation) or subnet broadcast address. | Upon connection to a network, the DHCP client will send out a broadcast message on the physical subnet to find DHCP servers. This message is in the form of a UDP DHCPDiscover packet and usually at least contains the clients MAC address in the OPTIONS section, with the broadcasted destination of 255.255.255.255 (or 0.0.0.0, depending on the implementation) or subnet broadcast address. | ||
| - | If the client previously had an IP address, it can request this IP address again by placing the previous IP address in the OPTIONS section of the DHCPDiscover message. Provided the the IP address is still valid in the network, the server might grant the request. If the address is not valid,the actions taken depend on whether or not the server is set up as authoritative. An authoritative server will deny the request, causing the client to request a new IP address. A non-authoritative server will ignore the request and the client will not get a new IP until it gives up its old lease. The time before the client gives up on its old lease varies between implementations. Most modern clients, will release the IP within a few minutes and request a new IP from the server. | + | If the client previously had an IP address, it can request this IP address again by placing the previous IP address in the OPTIONS section of the DHCPDiscover message. Provided the the IP address is still valid in the network, the server might grant the request. If the address is not valid,the actions taken depend on whether or not the server is set up as authoritative. An authoritative server will deny the request, causing the client to request a new IP address. A non-authoritative server will ignore the request and the client will not get a new IP until it gives up its old lease. The time before the client gives up on its old lease varies between implementations. Most modern clients, will release the IP within a few minutes and request a new IP from the server.<sup>[3]</sup> |
====DHCP Offers==== | ====DHCP Offers==== | ||
| - | Upon receiving a DHCPDiscover packet from the client, the DHCP Server allocates an IP address for the client and extends an IP lease offer by sending a DHCPOFFER message to the client. The DHCPOFFER message contains the client's MAC address, the offered IP address, the subnet mask, lease duration, the IP address of the DHCP server, and any additional options, such as DNS server addresses. | + | Upon receiving a DHCPDiscover packet from the client, the DHCP Server allocates an IP address for the client and extends an IP lease offer by sending a DHCPOFFER message to the client. The DHCPOFFER message contains the client's MAC address, the offered IP address, the subnet mask, lease duration, the IP address of the DHCP server, and any additional options, such as DNS server addresses.<sup>[3]</sup> |
====DHCP requests==== | ====DHCP requests==== | ||
| - | If there are multiple DHCP servers on the network, the client can receive multiple DHCPOFFERs. The client will select an offer, usually the first offer it received, and broadcast a DHCPREQUEST message. The servers on the network are informed as to which offer the client selected based on the Transaction ID field in the DHCPREQUEST message. Any Server whose offer was not selected reclaims the offered IP address. | + | If there are multiple DHCP servers on the network, the client can receive multiple DHCPOFFERs. The client will select an offer, usually the first offer it received, and broadcast a DHCPREQUEST message. The servers on the network are informed as to which offer the client selected based on the Transaction ID field in the DHCPREQUEST message. Any Server whose offer was not selected reclaims the offered IP address.<sup>[3]</sup> |
====DHCP acknowledgement==== | ====DHCP acknowledgement==== | ||
| - | Upon receiving the DHCPREQUEST message from the client, the DHCP Server who's offer was selected sends a DHCPACK message to the client. This message contains the lease duration and any other configuration information the client requested. The IP configuration process is now complete and the client now configures its network interface with the configuration information. | + | Upon receiving the DHCPREQUEST message from the client, the DHCP Server who's offer was selected sends a DHCPACK message to the client. This message contains the lease duration and any other configuration information the client requested. The IP configuration process is now complete and the client now configures its network interface with the configuration information.<sup>[3]</sup> |
===Lease Renewal=== | ===Lease Renewal=== | ||
| Line 77: | Line 75: | ||
If the client never receives an DHCPACK message, the client automatically assumes that the DHCP server is down. It will wait until 87.5% of the lease time has expired and send a DHCPREQUEST message to the server again requesting an extension to its lease time. If a negative DHCPNACK message is received by the client, the Client will immediately stop using its current IP address, and moves back to the INITIALIZE state. If the client receives a DHCPACK message, its lease has been renewed and its timers restart. | If the client never receives an DHCPACK message, the client automatically assumes that the DHCP server is down. It will wait until 87.5% of the lease time has expired and send a DHCPREQUEST message to the server again requesting an extension to its lease time. If a negative DHCPNACK message is received by the client, the Client will immediately stop using its current IP address, and moves back to the INITIALIZE state. If the client receives a DHCPACK message, its lease has been renewed and its timers restart. | ||
| - | If client does not receive a response this time, it broadcasts a DHCPREQUEST to the original server and all other DHCP servers on the network for its lease to be extended. If the client does not receive a DHCPACK message this third and final time, the lease expires. The client must relinquish the IP address and move back to the INITIALIZE state to try to acquire a new address. | + | If client does not receive a response this time, it broadcasts a DHCPREQUEST to the original server and all other DHCP servers on the network for its lease to be extended. If the client does not receive a DHCPACK message this third and final time, the lease expires. The client must relinquish the IP address and move back to the INITIALIZE state to try to acquire a new address.<sup>[3,8]</sup> |
===DHCP information=== | ===DHCP information=== | ||
| - | Should the client require additional information from the server or the repetition of data, the client can send an DHCPINFORM message to the DHCP server requesting the information. The server will send back an DHCPACK message with the requested information. Browsers use this to obtain automatic configuration of web proxy setting. This does not cause the renewal of an lease. | + | Should the client require additional information from the server or the repetition of data, the client can send an DHCPINFORM message to the DHCP server requesting the information. The server will send back an DHCPACK message with the requested information. Browsers use this to obtain automatic configuration of web proxy setting. This does not cause the renewal of an lease.<sup>[3]</sup> |
===DHCP releasing=== | ===DHCP releasing=== | ||
| - | When a client wishes to cancel a lease, it sends a DHCPRELEASE message to the DHCP server to release the DHCP information and terminate the lease without waiting for it to expire. It is not necessary for a client to send a DHCPRELEASE message for lease termination. If the lease time expires before the client renews it, the lease will terminate and the IP address will be reclaimed. | + | When a client wishes to cancel a lease, it sends a DHCPRELEASE message to the DHCP server to release the DHCP information and terminate the lease without waiting for it to expire. It is not necessary for a client to send a DHCPRELEASE message for lease termination. If the lease time expires before the client renews it, the lease will terminate and the IP address will be reclaimed.<sup>[3]</sup> |
===DHCP Options=== | ===DHCP Options=== | ||
| - | DHCP servers support the passing of optional configuration information to clients. DNS server addresses, NTP server addresses, SMTP server address, and many others can be passed to clients with the use of DHCP options. DHCP Options are easily extended as the need arises. The Internet Assigned Numbers Authority (IANA) provides an [http://www.iana.org/assignments/bootp-dhcp-parameters/ exhaustive list] for DHCPv4 options. | + | DHCP servers support the passing of optional configuration information to clients. DNS server addresses, NTP server addresses, SMTP server address, and many others can be passed to clients with the use of DHCP options. DHCP Options are easily extended as the need arises. The Internet Assigned Numbers Authority (IANA) provides an [http://www.iana.org/assignments/bootp-dhcp-parameters/ exhaustive list] for DHCPv4 options.<sup>[3]</sup> |
==DHCPv6== | ==DHCPv6== | ||
| Line 92: | Line 90: | ||
===DHCPv4 vs DHCPv6=== | ===DHCPv4 vs DHCPv6=== | ||
| - | DHCPv6 essentionally works the same as DHCPv4. However, the details of DHCPv6 are different from DHCPv4. While it was conceptually based on DHCPv4, DHCPv6 was rewritten from scratch instead of being based on an older protocol like DHCPv4 was. This allowed for an overall cleaner implementation than DHCPv4. The compatibility with BOOTP was removed, saving space in the packet layout. A lot of useless options available in DHCPv4 were able to be removed from DHCPv6. Moreover, any hacks DHCPv4 accumulated throughout the years to work with certain clients were able to be forgotten. DHCPv6 also uses different ports than DHCPv4. DHCPv6 utilizes UDP port 547 for the server side and UDP port 546 on the client side. | + | DHCPv6 essentionally works the same as DHCPv4. However, the details of DHCPv6 are different from DHCPv4. While it was conceptually based on DHCPv4, DHCPv6 was rewritten from scratch instead of being based on an older protocol like DHCPv4 was. This allowed for an overall cleaner implementation than DHCPv4. The compatibility with BOOTP was removed, saving space in the packet layout. A lot of useless options available in DHCPv4 were able to be removed from DHCPv6. Moreover, any hacks DHCPv4 accumulated throughout the years to work with certain clients were able to be forgotten. DHCPv6 also uses different ports than DHCPv4. DHCPv6 utilizes UDP port 547 for the server side and UDP port 546 on the client side.<sup>[9]</sup> |
| - | Besides, the cleaner implementation, DHCPv6 has some key advantages over DHCPv4. In DHCPv6 all interfaces on a client can be configured with one exchange with each interface having different options. DHCPv6 allows DHCPv6 packets to have options encapsulated at many different levels. DHCPv6 allows normal address allocation, as well as temporary address allocation, which allows the use of a IPv6 privacy address. Privacy addresses allow a network user to generate a new unique IPv6 address periodically or for each session. [ | + | Besides, the cleaner implementation, DHCPv6 has some key advantages over DHCPv4. In DHCPv6 all interfaces on a client can be configured with one exchange with each interface having different options. DHCPv6 allows DHCPv6 packets to have options encapsulated at many different levels. DHCPv6 allows normal address allocation, as well as temporary address allocation, which allows the use of a IPv6 privacy address. Privacy addresses allow a network user to generate a new unique IPv6 address periodically or for each session.<sup>[10]</sup> |
| - | Many features of IPv6 help to improve DHCPv6. IPv6 hosts have link-local addresses where every network interface has a unique address. As such, IPv6 hosts can use its link-local address to send requests to the DHCPv6 Server for a network valid IPv6 address. IPv4 clients must use system specific hacks before they have an address. All IPv6 networks support multicasting, so DHCPv6 servers are able to recieve only DHCPv6 multicast packets. This allows the server to know where to send packets. In IPv4, when a clients broadcast a request, the server does not know how far to send an offer. These features allow a more efficient implementation of DHCP. | + | Many features of IPv6 help to improve DHCPv6. IPv6 hosts have link-local addresses where every network interface has a unique address. As such, IPv6 hosts can use its link-local address to send requests to the DHCPv6 Server for a network valid IPv6 address. IPv4 clients must use system specific hacks before they have an address. All IPv6 networks support multicasting, so DHCPv6 servers are able to recieve only DHCPv6 multicast packets. This allows the server to know where to send packets. In IPv4, when a clients broadcast a request, the server does not know how far to send an offer. These features allow a more efficient implementation of DHCP.<sup>[9]</sup> |
===DHCPv6 vs IPv6 Autoconfiguration=== | ===DHCPv6 vs IPv6 Autoconfiguration=== | ||
| - | IPv6 has a stateless autoconfiguration protocol (defined in RFC 2462) that IPv4 does not have. This protocol allows hosts to automatically get an address without the need of a server or relay. This is done by having the router on a network periodically | + | IPv6 has a stateless autoconfiguration protocol (defined in RFC 2462) that IPv4 does not have. This protocol allows hosts to automatically get an address without the need of a server or relay. This is done by having the router on a network periodically broadcast the address that the network uses. The host then uses this broadcasted address in combination with unique information, such as a MAC address, to obtain a new IPv6 address.<sup>[11]</sup> |
| - | broadcast the address that the network uses. The host then uses this broadcasted address in combination with unique information, such as a MAC address, to obtain a new IPv6 address. [ | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| + | There are a few advantages to DHCPv6 over IPv6 address autoconfiguration. IPv6 address autoconfiguration can only provide a very limited amount of configuration information. Generally only the IP address, subnet mask, server IP, and sometimes DNS server addresses. DHCPv6 allows for many more options and is easily extended to include new information as the need arises. DHCPv6 allows you control over which addresses are allocated and to whom. IPv6 autoconfiguration has no control as to who obtains an address and what address they obtain.<sup>[9]</sup> | ||
| - | + | Despite the crossover in usage, it is possible to use autoconfiguration to set host addresses, and then use DHCPv6 to provide further information to the hosts. As such, DHCPv6 can be used to compliment IPv6 address autoconfiguration.<sup>[9]</sup> | |
==See Also== | ==See Also== | ||
| Line 120: | Line 112: | ||
==References== | ==References== | ||
| + | #[http://www.nycwireless.net/presentation/DarioLaverde_DHCP_2002.07.31.pdf A DHCP Primer], NYC Wireless, Dario Laverde, 2002 | ||
#[http://www.dhcp-handbook.com/dhcp_faq.html DHCP FAQ], The DHCP Handbook, Retrieved on April 12th 2009 | #[http://www.dhcp-handbook.com/dhcp_faq.html DHCP FAQ], The DHCP Handbook, Retrieved on April 12th 2009 | ||
#[http://en.wikipedia.org/wiki/Dhcp DHCP], Wikipedia, Retrieved on April 12th 2009 | #[http://en.wikipedia.org/wiki/Dhcp DHCP], Wikipedia, Retrieved on April 12th 2009 | ||
| - | #[ | + | #[http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_5-2/dhcp.html One Byte at a Time: Bootstrapping with BOOTP and DHCP], Cisco, Douglas Comer, Retrieved on April 12th 2009 |
#[http://technet.microsoft.com/en-us/library/bb727003.aspx Chapter 6 - Dynamic Host Configuration Protocol], Microsoft Technet, Retrieved on April 12th 2009 | #[http://technet.microsoft.com/en-us/library/bb727003.aspx Chapter 6 - Dynamic Host Configuration Protocol], Microsoft Technet, Retrieved on April 12th 2009 | ||
| - | #[ | + | #[http://www.docs.hp.com/en/B2355-90685/ch06s02.html DHCP Components and Concepts], HP Technical Documentation, Retrieved on April 12th 2009 |
#Ralph Droms & Ted Lemon (2003). "The DHCP Handbook", 2ed, Sams | #Ralph Droms & Ted Lemon (2003). "The DHCP Handbook", 2ed, Sams | ||
#Douglas E. Comer (2006). "Internetworking with TCP/IP Vol.1: Principles, Protocols, and Architecture", 5ed, Prentice Hall | #Douglas E. Comer (2006). "Internetworking with TCP/IP Vol.1: Principles, Protocols, and Architecture", 5ed, Prentice Hall | ||
#[http://www.ripe.net/ripe/meetings/ripe-53/presentations/dhcpv6.pdf DHCPv6], Shane Kerr, RIPE-53 Meeting, Oct 2006 | #[http://www.ripe.net/ripe/meetings/ripe-53/presentations/dhcpv6.pdf DHCPv6], Shane Kerr, RIPE-53 Meeting, Oct 2006 | ||
#[http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/white_paper_c11-474201.html IPv6 Local Network Protection with Cisco IOS Routers and Switches], Cisco, Retrieved on April 12th 2009 | #[http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/white_paper_c11-474201.html IPv6 Local Network Protection with Cisco IOS Routers and Switches], Cisco, Retrieved on April 12th 2009 | ||
| - | #[ | + | #[http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-2/ipv6_autoconfig.html IPv6 Autoconfiguration], Cisco, François Donzé, Retrieved on April 12th 2009 |
#[http://learn-networking.com/network-design/dynamic-host-configuration-protocol An Introduction to Dynamic Host Configuration Protocol], Learn Networking, Retrieved on April 12th 2009 | #[http://learn-networking.com/network-design/dynamic-host-configuration-protocol An Introduction to Dynamic Host Configuration Protocol], Learn Networking, Retrieved on April 12th 2009 | ||
==External links== | ==External links== | ||
Revision as of 03:11, 13 April 2009
Dynamic Host Configuration Protocol (DHCP) is a client/server protocol used to enable clients to obtain configuration information for operation in an IP network. DHCP is used to shrinks system administration workload by permitting DHCP clients to be added to an IP network with little or no manual intervention through the allocation of network addresses and additional configuration option.
DHCP is defined by two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocation of network addresses to hosts. [1]
Contents |
History
DHCP was created by the Dynamic Host Configuration Working Group at the Internet Engineering Task Force (IETF; a volunteer organization which defines protocols for use on the Internet). It was originally defined in RFC 1531 in October 1993 as a superset of the BOOTstrap Protocol (BOOTP). It was further refined with corrections and more options in RFC 1541 in the same month. The current definition of DHCP for IPv4 networks is in RFC 2131, released in March 1997. Various DHCP options available as of March 1997 are discussed in RFC 2132. DHCPv6, the extension of DHCP for IPv6, is defined in RFC 3315.[2,3]
The Need For DHCP
When first creating TCP/IP, the designers decided to provide a separate mechanism for each item of configuration information. As such, the Reverse Address Resolution Protocol (RARP) was created (RFC 903) to only allow computers to find out its own IP address. When subnet masks were introduced, ICMP Address Mask messages were created to allow a computer to obtain a subnet mask. This allows a great deal of flexibility but at the cost of network traffic and delay.
As more configuration information become available, TCP/IP designers observed that many of the configuration steps could be combined into one single step. To circumvent this problems, the designers created the BOOTstrap Protocol (BOOTP) in RFC 951. BOOTP was designed for manual pre-configuration of the host information in a server database. This helped to simplify configuration information and reduced the overall number of servers required on a network. When a BOOTP server receives a request, the computer is looked up in its database of information. If the computer is not found, it does not receive any configuration information. Thus, a computer cannot connect to a new network until the administrator manually adds information to the database.
BOOTP works well in relatively static environments. However, as computers got smaller and lighter, it was common for them to move from one network to another, requiring a new IP address while the previous one was still assigned to it until manual intervention. Keeping track of all these IP address changes became be a daunting task. This coupled with the limited number of IP addresses in an organization lead to a new protocol.
To automate configuration, the IETF created DHCP to allow for the dynamic allocation of network addresses and configurations to newly attached hosts with no manual intervention. DHCP was originally designed as a successor to BOOTP. As such, it maintains some backward compatibility and many DHCP servers support BOOTP clients. DHCPv6 drops this compatibility to produce a cleaner implementation.[4]
Technical Overview
DHCPv4 utilizes UDP port 67 for the server side and UDP port 68 on the client side.[3]
In most DHCP client/server software, DHCP uses the following basic process, see Technical Details for a more indepth explanation).
- When a DHCP client connects to a network, it sends a broadcast query message to find the DHCP servers on the network.
- All DHCP servers on the network that receive the message and contain a valid address configuration for the client send an IP address offer back to the DHCP client.
- From the offers received, the client chooses an IP address configuration to use. The server that sent the offer the client selected, receives a broadcasted request message to use the selected configuration. The other DHCP servers that sent offers receive this broadcasted message, realize the request for another server, and reclaim the offered IP address.
- The DHCP server selected by the client, assigns the IP address configuration to the DHCP client and sends an acknowledgement message to the client to verify the acceptance.[5]
After the client obtained an IP address, the client may start an address resolution (ARP) query to prevent IP conflicts caused by address pool overlapping of DHCP servers.[3]
Lease Renewal
Before the lease time expires, the client will request to extend the lease by sending a request to the server. The server will update and extend the lease time and send an acknowledgment message to the client, letting it know the lease has been extended. If the client does not receive an acknowledgement message, it assumes the server is down and tries to renew the lease again after the lease period is 87.5% done. If it does not receive and acknowledgement this time, it will retry renewing one last time. If the client does not receice a response this final time, the lease expires and it releases the IP and starts at step 1 above.[6]
Address Allocation Policies
Generally, depending on the implementation, there are three methods for a DHCP Server to allocate IP-addresses. It is also possible to combine these methods, in a hybrid allocation policy.[7]
Manual (or Static) Allocation
The DHCP Server's administrator manually assigns a permanent IP address to a client, usually using a MAC address for the client identifier. The subsequent client identifier/IP address pair is stored in a table. Only requesting clients in this table will be given configuration information. This method of allocation is functionally equivalent to BOOTP though the protocol is incompatible.
Dynamic Allocation
The DHCP Server's administrator specifies a pool of IP addresses to be automatically assigned to clients for a specified limited period of time. IP address that are not renewed before the period of time ends or have their lease canceled are reclaimed and can be reallocated.[2,3]
Automatic Allocation
The DHCP Server's administrator specifies a pool of IP addresses to be permanently assigned to clients. Upon request, a free IP address in this range is automatically assigned to a client. Once associated with a client, the IP address is permanently assigned to the client until the server's administrator intervenes. Many DHCP Servers do not implement this method of allocation, as it can be approximated with long lease times in dynamic allocation.[2,3]
Hybrid Allocation Policies
There are various hybrid allocation possibilities with DHCP. One common one is the DHCP Server's administrator creates a list of allowed clients without assigning them fixed IP addresses. These allowed clients can then acquire a dynamically allocated IP address whenever they connect. This allows the administrator to limit the use of DHCP without the need for manual intervention every time a client moves.[2,3]
Technical Details
DHCP Initialization
DHCP operations fall into four basic phases. These phases are IP discovery(DHCPDISCOVER), IP lease offer(DHCPOFFER), IP request (DHCPREQUEST), and IP lease acknowledgment (DHCPACK).[3]
DHCP Discovery
Upon connection to a network, the DHCP client will send out a broadcast message on the physical subnet to find DHCP servers. This message is in the form of a UDP DHCPDiscover packet and usually at least contains the clients MAC address in the OPTIONS section, with the broadcasted destination of 255.255.255.255 (or 0.0.0.0, depending on the implementation) or subnet broadcast address.
If the client previously had an IP address, it can request this IP address again by placing the previous IP address in the OPTIONS section of the DHCPDiscover message. Provided the the IP address is still valid in the network, the server might grant the request. If the address is not valid,the actions taken depend on whether or not the server is set up as authoritative. An authoritative server will deny the request, causing the client to request a new IP address. A non-authoritative server will ignore the request and the client will not get a new IP until it gives up its old lease. The time before the client gives up on its old lease varies between implementations. Most modern clients, will release the IP within a few minutes and request a new IP from the server.[3]
DHCP Offers
Upon receiving a DHCPDiscover packet from the client, the DHCP Server allocates an IP address for the client and extends an IP lease offer by sending a DHCPOFFER message to the client. The DHCPOFFER message contains the client's MAC address, the offered IP address, the subnet mask, lease duration, the IP address of the DHCP server, and any additional options, such as DNS server addresses.[3]
DHCP requests
If there are multiple DHCP servers on the network, the client can receive multiple DHCPOFFERs. The client will select an offer, usually the first offer it received, and broadcast a DHCPREQUEST message. The servers on the network are informed as to which offer the client selected based on the Transaction ID field in the DHCPREQUEST message. Any Server whose offer was not selected reclaims the offered IP address.[3]
DHCP acknowledgement
Upon receiving the DHCPREQUEST message from the client, the DHCP Server who's offer was selected sends a DHCPACK message to the client. This message contains the lease duration and any other configuration information the client requested. The IP configuration process is now complete and the client now configures its network interface with the configuration information.[3]
Lease Renewal
Upon reaching a server specified timer value (or one-half the total lease time if a value is not specified), the client will try to renew its lease by sending a DHCPREQUEST message to the server. The server will update and extend the DHCP lease time. The server then sends a DHCPACK message to the client with the new lease time. There is no limit as to how many times a client can renew its lease.
If the client never receives an DHCPACK message, the client automatically assumes that the DHCP server is down. It will wait until 87.5% of the lease time has expired and send a DHCPREQUEST message to the server again requesting an extension to its lease time. If a negative DHCPNACK message is received by the client, the Client will immediately stop using its current IP address, and moves back to the INITIALIZE state. If the client receives a DHCPACK message, its lease has been renewed and its timers restart.
If client does not receive a response this time, it broadcasts a DHCPREQUEST to the original server and all other DHCP servers on the network for its lease to be extended. If the client does not receive a DHCPACK message this third and final time, the lease expires. The client must relinquish the IP address and move back to the INITIALIZE state to try to acquire a new address.[3,8]
DHCP information
Should the client require additional information from the server or the repetition of data, the client can send an DHCPINFORM message to the DHCP server requesting the information. The server will send back an DHCPACK message with the requested information. Browsers use this to obtain automatic configuration of web proxy setting. This does not cause the renewal of an lease.[3]
DHCP releasing
When a client wishes to cancel a lease, it sends a DHCPRELEASE message to the DHCP server to release the DHCP information and terminate the lease without waiting for it to expire. It is not necessary for a client to send a DHCPRELEASE message for lease termination. If the lease time expires before the client renews it, the lease will terminate and the IP address will be reclaimed.[3]
DHCP Options
DHCP servers support the passing of optional configuration information to clients. DNS server addresses, NTP server addresses, SMTP server address, and many others can be passed to clients with the use of DHCP options. DHCP Options are easily extended as the need arises. The Internet Assigned Numbers Authority (IANA) provides an exhaustive list for DHCPv4 options.[3]
DHCPv6
DHCPv4 vs DHCPv6
DHCPv6 essentionally works the same as DHCPv4. However, the details of DHCPv6 are different from DHCPv4. While it was conceptually based on DHCPv4, DHCPv6 was rewritten from scratch instead of being based on an older protocol like DHCPv4 was. This allowed for an overall cleaner implementation than DHCPv4. The compatibility with BOOTP was removed, saving space in the packet layout. A lot of useless options available in DHCPv4 were able to be removed from DHCPv6. Moreover, any hacks DHCPv4 accumulated throughout the years to work with certain clients were able to be forgotten. DHCPv6 also uses different ports than DHCPv4. DHCPv6 utilizes UDP port 547 for the server side and UDP port 546 on the client side.[9]
Besides, the cleaner implementation, DHCPv6 has some key advantages over DHCPv4. In DHCPv6 all interfaces on a client can be configured with one exchange with each interface having different options. DHCPv6 allows DHCPv6 packets to have options encapsulated at many different levels. DHCPv6 allows normal address allocation, as well as temporary address allocation, which allows the use of a IPv6 privacy address. Privacy addresses allow a network user to generate a new unique IPv6 address periodically or for each session.[10]
Many features of IPv6 help to improve DHCPv6. IPv6 hosts have link-local addresses where every network interface has a unique address. As such, IPv6 hosts can use its link-local address to send requests to the DHCPv6 Server for a network valid IPv6 address. IPv4 clients must use system specific hacks before they have an address. All IPv6 networks support multicasting, so DHCPv6 servers are able to recieve only DHCPv6 multicast packets. This allows the server to know where to send packets. In IPv4, when a clients broadcast a request, the server does not know how far to send an offer. These features allow a more efficient implementation of DHCP.[9]
DHCPv6 vs IPv6 Autoconfiguration
IPv6 has a stateless autoconfiguration protocol (defined in RFC 2462) that IPv4 does not have. This protocol allows hosts to automatically get an address without the need of a server or relay. This is done by having the router on a network periodically broadcast the address that the network uses. The host then uses this broadcasted address in combination with unique information, such as a MAC address, to obtain a new IPv6 address.[11]
There are a few advantages to DHCPv6 over IPv6 address autoconfiguration. IPv6 address autoconfiguration can only provide a very limited amount of configuration information. Generally only the IP address, subnet mask, server IP, and sometimes DNS server addresses. DHCPv6 allows for many more options and is easily extended to include new information as the need arises. DHCPv6 allows you control over which addresses are allocated and to whom. IPv6 autoconfiguration has no control as to who obtains an address and what address they obtain.[9]
Despite the crossover in usage, it is possible to use autoconfiguration to set host addresses, and then use DHCPv6 to provide further information to the hosts. As such, DHCPv6 can be used to compliment IPv6 address autoconfiguration.[9]
See Also
- Internet Protocol
- Address Resolution Protocol (ARP)
- Ethernet Routing Devices
- Proxy Server
- Simple Mail Transfer Protocol (SMTP)
- The Future of the Internet: IPv6
References
- A DHCP Primer, NYC Wireless, Dario Laverde, 2002
- DHCP FAQ, The DHCP Handbook, Retrieved on April 12th 2009
- DHCP, Wikipedia, Retrieved on April 12th 2009
- One Byte at a Time: Bootstrapping with BOOTP and DHCP, Cisco, Douglas Comer, Retrieved on April 12th 2009
- Chapter 6 - Dynamic Host Configuration Protocol, Microsoft Technet, Retrieved on April 12th 2009
- DHCP Components and Concepts, HP Technical Documentation, Retrieved on April 12th 2009
- Ralph Droms & Ted Lemon (2003). "The DHCP Handbook", 2ed, Sams
- Douglas E. Comer (2006). "Internetworking with TCP/IP Vol.1: Principles, Protocols, and Architecture", 5ed, Prentice Hall
- DHCPv6, Shane Kerr, RIPE-53 Meeting, Oct 2006
- IPv6 Local Network Protection with Cisco IOS Routers and Switches, Cisco, Retrieved on April 12th 2009
- IPv6 Autoconfiguration, Cisco, François Donzé, Retrieved on April 12th 2009
- An Introduction to Dynamic Host Configuration Protocol, Learn Networking, Retrieved on April 12th 2009
External links
| 0 | 8 | 16 | 24 31 |
| OP | HTYPE | HLEN | HOPS |
| Transaction ID | |||
| Seconds | Flags | ||
| Client IP Address | |||
