Dynamic Host Configuration Protocol: Difference between revisions
imported>Howard C. Berkowitz (Various citations and put into subpage format) |
mNo edit summary |
||
| (One intermediate revision by one other user not shown) | |||
| Line 7: | Line 7: | ||
| url = http://www.ietf.org/rfc/rfc2131.txt}}</ref> | | url = http://www.ietf.org/rfc/rfc2131.txt}}</ref> | ||
This gets rid of the need to statically give an IP to a device by an administrator. Thus, a device can have a different IP address every time it connects to the network automatically. Even if the device addresses do not change frequently, such as on servers, DHCP makes the job of the administrator much easier whenever it is necessary to change addresses. It may be necessary to renumber if the organization that has a particular address range merges with, or is acquired by, a larger organization, and the new owners want to make the addresses consistent. | This gets rid of the need to statically give an IP to a device by an administrator. Thus, a device can have a different [[IP address]] every time it connects to the network automatically. Even if the device addresses do not change frequently, such as on servers, DHCP makes the job of the administrator much easier whenever it is necessary to change addresses. It may be necessary to renumber if the organization that has a particular address range merges with, or is acquired by, a larger organization, and the new owners want to make the addresses consistent. | ||
It frees the network administrator from the hassle of having to know all the IP addresses on his network and giving valid IP address to each new device that connects to it.<ref name=RFC2071>{{citation | It frees the network administrator from the hassle of having to know all the IP addresses on his network and giving valid IP address to each new device that connects to it.<ref name=RFC2071>{{citation | ||
| Line 14: | Line 14: | ||
| date = January 1997 | | date = January 1997 | ||
| id = RFC2071 | | id = RFC2071 | ||
| url = http://www.ietf.org/rfc/rfc2071.txt}}</ref> A very effective way to keep track of real devices, rather than changing IP addresses, is to have the DHCP server automatically pass assignments to a DNS server.<ref name=RFC3007>{{citation | | url = http://www.ietf.org/rfc/rfc2071.txt}}</ref> A very effective way to keep track of real devices, rather than changing IP addresses, is to have the DHCP server automatically pass assignments to a [[Domain Name System]] (DNS) server.<ref name=RFC3007>{{citation | ||
| title = Secure Domain Name System (DNS) Dynamic Update | | title = Secure Domain Name System (DNS) Dynamic Update | ||
| author = B. Wellington | | author = B. Wellington | ||
| date = November 2002 | | date = November 2002 | ||
| id = RFC3007 | | id = RFC3007 | ||
| url = http://www.ietf.org/rfc/rfc3007.txt}}</ref> A host name such as Desk2-Room102.Campus3.example.com can be very helpful in troubleshooting when you can | | url = http://www.ietf.org/rfc/rfc3007.txt}}</ref> A host name such as Desk2-Room102.Campus3.example.com can be very helpful in troubleshooting when you can ask the DNS server what number has been assigned to it. Many commercial ISPs use this technology. | ||
It is also used on more complex networks where the connected devices continually change their IP address while still connected. | It is also used on more complex networks where the connected devices continually change their IP address while still connected. | ||
==General issues== | |||
*Host configuration/unique host naming | |||
*Lease time considerations | |||
==IPv4 issues and support mechanisms== | |||
*Proxies for PPP/IPCP | |||
*Collision avoidance | |||
*DHCP failover mechanisms | |||
==IPv6 issues and support mechanisms== | |||
[[Internet Protocol version 6]] has a DHCP version, also called stateful address assignment. It also has a self-configuring alternative called [[stateless autoconfigurtion]] | |||
==References== | ==References== | ||
{{reflist}} | {{reflist}}[[Category:Suggestion Bot Tag]] | ||
Latest revision as of 11:00, 9 August 2024
Dynamic Host Configuration Protocol, is a client-server technology for dynamically assigning IP addresses to devices on a network.[1]
This gets rid of the need to statically give an IP to a device by an administrator. Thus, a device can have a different IP address every time it connects to the network automatically. Even if the device addresses do not change frequently, such as on servers, DHCP makes the job of the administrator much easier whenever it is necessary to change addresses. It may be necessary to renumber if the organization that has a particular address range merges with, or is acquired by, a larger organization, and the new owners want to make the addresses consistent.
It frees the network administrator from the hassle of having to know all the IP addresses on his network and giving valid IP address to each new device that connects to it.[2] A very effective way to keep track of real devices, rather than changing IP addresses, is to have the DHCP server automatically pass assignments to a Domain Name System (DNS) server.[3] A host name such as Desk2-Room102.Campus3.example.com can be very helpful in troubleshooting when you can ask the DNS server what number has been assigned to it. Many commercial ISPs use this technology.
It is also used on more complex networks where the connected devices continually change their IP address while still connected.
General issues
- Host configuration/unique host naming
- Lease time considerations
IPv4 issues and support mechanisms
- Proxies for PPP/IPCP
- Collision avoidance
- DHCP failover mechanisms
IPv6 issues and support mechanisms
Internet Protocol version 6 has a DHCP version, also called stateful address assignment. It also has a self-configuring alternative called stateless autoconfigurtion
References
- ↑ R. Droms (March 1997), Dynamic Host Configuration Protocol, RFC2131
- ↑ P. Ferguson, H. Berkowitz (January 1997), Network Renumbering Overview: Why would I want it and what is it anyway?, RFC2071
- ↑ B. Wellington (November 2002), Secure Domain Name System (DNS) Dynamic Update, RFC3007