Dynamic Host Configuration Protocol
The Dynamic Host Configuration Protocol (DHCP) allows the assignment of the network configuration to clients by a server.
The Dynamic Host Configuration Protocol defined in RFC 2131 and was by the Internet Assigned Numbers Authority 67 and 68 assigned to the UDP ports.
- 5.1 Initial address assignment ( lease / assignment)
- 5.2 DHCP Refresh (only for dynamic allocation )
- 5.3 Miscellaneous
- 5.4 DHCP and DNS
- 5.5 Possible assignments
- 9.1 specifications
- 9.2 External links
- 9.3 Notes and references
DHCP enables automatic integration of a computer to an existing network without the manual configuration is possible. At this, the client, only the automatic assignment of the IP address must be set in the normal case. When starting the computer in the network, it can enter the IP address, subnet mask, gateway, DNS server, and optionally WINS server from a DHCP server. Without DHCP, are to - depending on the network to be connected to the the computer - some settings are required. DHCP is an extension of the Bootstrap Protocol ( BOOTP), can be realized with by diskless workstations that initially get an IP address from the BOOTP server. Then they invite a bootable operating system from the network to which they then start. DHCP is largely compatible with BOOTP and can work with limited BOOTP clients and servers.
The Dynamic Host Configuration Protocol was developed in terms of two application scenarios:
In networks, DHCP provides the advantage that any topology changes, not all affected workstations must be reconfigured by hand, but the relevant provisions by the administrator only once in the configuration file of the DHCP server to be changed. Even for computers with frequently changing location (eg notebooks) eliminates the error-prone configuration - the computer is simply connected to the network and asks for all relevant parameters from the DHCP server. This is sometimes referred to as Plug ' n Play for networks.
DHCP was first in 1993 in RFC 1531 and RFC 1541, building on the from 1985 BOOTP ( RFC 951), defined.
Construction of a DHCP packet
- Op ( 1 byte): information, whether it is a request ( request = 1) or a response ( reply = 2) is
- Htype (1 byte): Network type (eg, 1 = Ethernet, 6 = IEEE 802 networks, or 7 = ARCNET )
- Select (1 byte): length of the physical network address in bytes ( for example, 6 = MAC / Ethernet Address)
- Hops (1 byte, optional): Number of DHCP Relay Agent on the data path
- Xid (4 bytes): ID of the connection between client and server
- Secs (2 bytes ): The time in seconds since the start of the client
- Flags (2 bytes): Z. currently is only the first bit is used (indicates whether the client still has a valid IP address), the remaining bits are reserved for future protocol extensions
- Ciaddr (4 bytes): client IP address
- Yiaddr (4 bytes): its own IP address
- Siaddr (4 bytes): Server IP address
- Giaddr (4 bytes): Relay agent IP address
- Chaddr (16 bytes): client MAC address
- Sname ( 64 bytes ): Name of the DHCP server, if a particular is required ( includes C- String), specifying optional
- File ( 128 bytes ): name of file (eg system kernel ) to be sent to the client from the server using TFTP (contains C string ) parameter optional
- Options (variable, optional): DHCP parameters and options (described in RFC 2132 ) - client should at least here options with 312 bytes in length ( as a maximum), can receive a packet with the size of 576 bytes, in other words. A larger maximum number of bytes can be ' negotiated ' between server and client.
The DHCP server
The DHCP server is - like all network services - started as a background process (daemon or service ) and waits for UDP port 67 to client requests. In its configuration file contains information about the address pool to be awarded as well as additional information about network- relevant parameters such as the subnet mask, the local DNS domain or the gateway to use. In addition, even more BOOTP server or the location of the boot image to be used can be set.
There are three different modes of operation of a DHCP server: manual, automatic and dynamic allocation.
In this mode (static DHCP) IP addresses are assigned to specific MAC addresses firmly on the DHCP server. The addresses are assigned indefinitely to the MAC address. The disadvantage may be that there are no additional clients can be integrated into the network because the addresses are permanently assigned. This may be desirable from a safety point.
Manual assignments are used primarily to ensure that when the DHCP client is for example Server services available and, therefore, under a fixed IP address should be reachable. Also port forwarding from a router to a client need a fixed IP address in the rule.
For automatic assignment, the DHCP server at a range of IP addresses (range) is defined. IP addresses are automatically assigned to the MAC addresses of new DHCP clients, which is held in a table. In contrast to the dynamic allocation automatic allocations are permanent and can not be removed. The advantage is that hosts will always receive the same IP address and an assigned IP address to another host is assigned. The disadvantage is that new clients can not get IP address if the address range is completely forgiven, even if IP addresses are no longer actively used. Compared to the manual and dynamic allocation, this mode plays in practice a subordinate role.
This method is similar to automatic allocation, but the DHCP server in its configuration file an indication of how long a particular IP address to a client may be 'awarded' before the client must log into the server again and apply for an "extension " needs. He does not answer, the address is released and can be reassigned to another (or the same) computer. Defined by the administrator time is the lease time (in German, saying " rental period ").
Some DHCP servers also assign the MAC address -based IP addresses, ie, a client receives even after prolonged abstinence and network expiry of the lease period, the same IP address as before ( unless, of course, this is now been assigned otherwise ).
- DHCPDISCOVER: A client without an IP address sends a broadcast request for address Offered to the / DHCP server on the local network.
- DHCPOFFER: The / DHCP servers respond with corresponding values on a DHCPDISCOVER request.
- DHCPREQUEST: The client requests (one of the offered ) IP address (es ), more data and extend the lease time of one of the responding DHCP server.
- DHCPACK: Acknowledgement of the DHCP server in a DHCPREQUEST request
- DHCPNAK: rejection of a DHCPREQUEST request by the DHCP server
- DHCPDECLINE: rejection by the client because the IP address is already in use.
- DHCPRELEASE: The client releases its own configuration, so that the parameters are again available to other clients.
- DHCPINFORM: a client request for data without an IP address, for example, because the client has a static IP address.
Expiration of the DHCP communication
For the client to use a DHCP server, it must be in the same network segment as the DHCP broadcasts used and routers do not forward broadcasts (routers form broadcast domains ). The DHCP server is on a different network segment, a so-called DHCP Relay Agent must be installed, which forwards the DHCP requests to the real server.
Initial address assignment ( lease / assignment)
If a client needs the first time an IP address, it sends a DHCPDISCOVER message ( with its MAC address) as the network broadcast the available DHCP server ( it can be quite a number of them in the same subnet enter ). This broadcast has as source IP address of 0.0.0.0 and a destination address of 255.255.255.255, because the sender does not yet have the IP address and its request "to all " addresses. Here, the UDP source port 68 and destination UDP port 67 is the DHCP servers respond with DHCPOFFER and make proposals for an IP address. This is also done with a broadcast to the address 255.255.255.255 with UDP source port 67 and UDP destination port 68
The client may now choose among the offerings arrived ( DHCP Offers ). If he has opted for a (eg due longest lease time or due to rejection of a special, possibly misconfigured DHCP server, or just for the first response ), he contacted via broadcast and a server identifier contained in the package appropriate server with the message DHCPREQUEST. All any additional DHCP server this as a rejection of their offers. The selected server from the client confirmed in a DHCPACK message ( DHCP Acknowledged ) the IP address with other relevant data, or it pulls its offer ( DHCPNAK, see also other).
Before the client configures its network interface with the assigned address, he should still consider whether accidentally or another computer uses the address. This is typically done by an ARP request with the just- assigned IP address. Answers another host in the network to this request, so the client will reject the proposed address with a DHCPDECLINE message.
DHCP Refresh (only for dynamic allocation )
Combined with the IP address of the client receives the DHCPACK message, the lease time. This is a value that specifies how long the client may use the assigned IP configuration; it is set by the administrator of the DHCP server. The standard requires that the client after half the lease time sends a DHCPREQUEST again and so expressed that further interest in the reserved IP address is. This DHCPREQUEST is sent via unicast to the server that has assigned the IP configuration. The server should then usually send a DHCPACK with the same data as before, but a new lease time. Thus, the address is considered to be extended.
If the server does not, so the client can use the IP configuration with no restrictions on until the lease has expired. However, it is after 7 /8 lease- time (87.5%) are trying to get an extension of the IP configuration from any DHCP server ( sending the request in the broadcast). One possible reason for this is that the original server has been shut down and now a new server is responsible for managing the IP addresses.
Should the client fail to apply for an extension to the expiry of the lease period, it must unconfigure its network card, and begin again at DHCPDISCOVER with an initial address assignment. If the DHCP server does not address longer have available or have received promised during the process already another client 's last address, the server sends a DHCPNAK ( DHCP not acknowledged ), and the process of address request starts again.
DHCPNAK A negative acknowledgment may be the cause that the client is trying to lease its former IP address ( engl. lease: rent or lease ), but which is now no longer available, or if the client computer is moved to a different subnet been.
To reduce the probability of default, it is also possible to place multiple DHCP servers on a network. However, it should be noted that do not overlap the address ranges of each server, as it may cause double entries of IP addresses otherwise. There are the "authoritative " (English for "relevant " ) setting that you can set whether a DHCPNAK should also be sent, if the DHCP server is not responsible for the proposed client address.
When the client receives a negative acknowledgment, the DHCP lease process is started again.
A client sends DHCPRELEASE if he wants to return an IP address to the expiration of the lease time ago.
Should determine the client that the assigned address is already in use, it shall notify the with the server by DHCPDECLINE, which should in turn inform the administrator of this potential misconfiguration.
DHCP and DNS
Thus their name resolution is possible, register computer their name and IP address in the rule with a DNS server. Some DHCP servers can take the place of the client. For operating systems from Microsoft that was required prior to Windows 2000.
By default, DHCP assign the following settings to the client:
- IP address and network mask
- Default Gateway
- Name Server
- Proxy configuration via WPAD
- Time ( RFC 868 ), and NTP server
- DNS server, DNS, and the DNS Context Tree
- Secondary DNS Server
- WINS Server ( for Microsoft Windows clients)
DHCP for multiple subnets
The DHCP server can ( sub) networks operate if it has definitions for the respective network. The choice of definition is then determined by the network card through which comes the request. At the start of the DHCP server, you can specify on which interface the server listens.
On the other hand, a DHCP servers and remote networks when a DHCP relay agent (often available as a function of a router ) are connected. The relay agent receives the remote network, the broadcast DHCP requests and forwards them as unicast messages to the / the configured DHCP server. The IP address of the interface on which the broadcast was received, the relay agent added to the unicast packet in the DHCP header, so that the DHCP server can not determine from this information network segment from which the request comes. The DHCP relay agent receives the reply packets to the DHCP server on UDP port 67 and then forwards them to the destination port UDP 68 to the client.
DHCP can be easily disturbed and manipulated because DHCP clients accept any DHCP server.
The accidental activation of a DHCP server, for example, by a simple DSL router or wireless router on delivery port can largely cripple a network. This may respond faster than the actually foreseen DHCP server and distributed thereby possibly invalid configurations.
An attacker can allocate all addresses a DHCP Server (DHCP Starvation Attack), thereby preventing its response to further inquiries and then act as the sole DHCP server. He now has the possibility of rogue DHCP to operate spoofing by redirecting to other DNS servers that refer to computers that compromise the communication.
The supposed uniqueness of the MAC address must not be used as a safety criterion. It is far too easy to operate MAC address spoofing. Almost all operating systems allow ordinary users, the MAC address comfortable to write to the configuration masks or simple utilities such as ifconfig (UNIX, Linux) or ip link ( Linux). Valid MAC addresses in a Layer 2 network can be identified by listening to the network traffic. This only physical access to the network is necessary. The exclusive assignment of IP addresses only to registered MAC addresses via DHCP or RARP does not exclude that unauthorized access to the network; for the use of a secure authentication mechanism like IEEE 802.1X is necessary.
A pastiche of efforts to circumvent these problems, the Clothespin Peg DHCP protocol.
IPv6 is required for the actual address assignment no DHCP service (see IPv6 auto-configuration ). However, a client next to a gateway usually requires nor the assignment of a DNS server. So far, there is no common method to transmit the additional information by the auto-configuration of the client. A standardized procedure for notification of the DNS server, however in RFC 6106 ( RDNSS, DNSSL ) described, could be omitted in simple scenarios to DHCPv6.
For the described case scenarios and the DHCPv6 protocol is since July 2003 in RFC 3315 defined, which provides similar functionality as the current DHCPv4 for IPv4 currently available in the IPv6 world. In addition, DHCPv6 is designed configuration information about NIS with optional fields in the DHCPv6 protocol - transport, SIP, NTP and other services. What options are included in DHCPv6 is determined by the DHCP working group of the IETF. Other features of DHCPv6 are the built-in security features through which it is possible to make DHCPv6 only authorized clients accessible, as well as the opportunity to continue to have the address configuration made by stateless autoconfiguration, but to bring more setup details DHCPv6 on the client.
Notwithstanding DHCPv4 running at v6 communication over UDP ports 546 (client) and 547 (server).