Dynamic Host Configuration Protocol

from Wikipedia, the free encyclopedia
DHCP (Dynamic Host Configuration Protocol)
Family: Internet protocol family
Operation area: Automatic acquisition of
IP addresses and other
parameters
Ports: 67 / UDP (IPv4 server or relay agent)
68 / UDP (IPv4 client)

547 / UDP (IPv6 server or relay agent)
546 / UDP (IPv6 client)

DHCP on the TCP / IP protocol stack :
application DHCP
transport UDP
Internet IP ( IPv4 , IPv6 )
Network access Ethernet Token
bus 		Token
ring 		FDDI ...
Standards: RFC 2131 (1997)

The Dynamic Host Configuration Protocol ( DHCP ) is a communication protocol in computer technology . It enables the network configuration to be assigned to clients by a server .

DHCP is in the RFC 2131 defined and obtained from the Internet Assigned Numbers Authority , the UDP - ports 67 and 68 are assigned.

concept

DHCP enables connected clients to be integrated into an existing network without manual configuration of the network interface . Necessary information such as IP address , network mask , gateway , name server (DNS) and any other settings are assigned automatically, provided the operating system of the respective client supports this.

DHCP is an extension of the bootstrap protocol (BOOTP), which was necessary for workstation computers without their own hard drive ( diskless workstation ), where the computer was initially assigned an IP address by the BOOTP server and then the operating system to load from the network. DHCP is largely compatible with BOOTP and can accordingly work (to a limited extent) with BOOTP clients and servers.

DHCP was first defined in 1993 in RFC 1531 and RFC 1541 , based on the 1985 BOOTP ( RFC 951 ).

Structure of a DHCP packet

32 bit
op htype hlen hops
xid
secs flags
ciaddr
yiaddr
siaddr
giaddr
chaddr
sname
file
options
  • op (1 byte): Information as to whether it is a request (request = 1) or a response (reply = 2)
  • htype (1 byte): network type (e.g. 1 = Ethernet, 6 = IEEE 802 networks or 7 = ARCNET )
  • hlen (1 byte): Length of the physical network address in bytes (e.g. 6 = MAC / Ethernet address)
  • hops (1 byte, optional): Number of DHCP relay agents on the data path
  • xid (4 bytes): ID of the connection between client and server
  • secs (2 bytes): Time in seconds since the start of the client
  • flags (2 bytes): Currently only the first bit is used (indicates whether the client still has a valid IP address), the remaining bits are reserved for later protocol extensions
  • ciaddr (4 bytes): Client IP address
  • yiaddr (4 bytes): 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 specific one is required (contains C-String) , optional
  • file (128 bytes): Name of a file (e.g. system kernel) to be sent from the server to the client via TFTP (contains C-string) , optional
  • options (variable, optional): DHCP parameters and options (described in RFC 2132 ) - The options can be up to 312 bytes long, so that a packet of up to 576 bytes in length can occur. A larger maximum number of bytes can be 'negotiated' between server and client.

The DHCP server

Like all network services , the DHCP server is started as a background process ( service or daemon ) and waits on UDP port 67 for client requests. Its configuration file contains information about the address pool to be assigned as well as additional information about network-relevant parameters such as the subnet mask , the local DNS domain or the gateway to be used. You can also set other BOOTP servers or the location of the boot image to be used.

There are three different operating modes of a DHCP server: manual, automatic and dynamic assignment.

Manual assignment

In this mode ( static DHCP ) the IP addresses are permanently assigned to specific MAC addresses on the DHCP server . The addresses are assigned to the MAC address for an indefinite period of time. The disadvantage can be that no additional clients can be integrated into the network because the addresses are fixed. This can be desirable from a security perspective.

Manual assignments are primarily made when the DHCP client provides server services, for example, and should therefore be accessible under a fixed IP address. Port forwarding from a router to a client usually also requires a fixed IP address.

Automatic assignment

In the automatic assignment of the DHCP server, a range of IP addresses (is range ) defined. IP addresses are automatically assigned to the MAC addresses of new DHCP clients, which is recorded in a table. In contrast to dynamic assignment, automatic assignments are permanent and are not removed. The advantage is that hosts always receive the same IP address and an assigned IP address is not assigned to another host. The disadvantage is that new clients do not receive an IP address if the entire address range has been assigned, even if IP addresses are no longer actively used. Compared to manual and dynamic assignment, this mode plays a subordinate role in practice.

Dynamic assignment

This procedure is similar to the automatic assignment, but the DHCP server has an indication in its configuration file of how long a certain IP address can be "lent" to a client before the client reports to the server again and applies for an "extension" got to. If he does not respond, the address becomes available and can be reassigned to another (or the same) computer. This time, determined by the administrator, is called the lease time .

Some DHCP servers also assign IP addresses that are dependent on the MAC address, i. H. a client receives the same IP address as before, even after a long period of abstinence from the network and expiry of the lease time (unless, of course, it has already been assigned elsewhere).

DHCP messages

  • DHCP DISCOVER : A client without an IP address sends a broadcast request for address offers to all DHCP servers in the local network.
  • DHCP OFFER : The DHCP servers respond to a DHCP DISCOVER request with appropriate values .
  • DHCP REQUEST : The client requests one of the IP addresses offered, additional data and an extension of the lease time from one of the responding DHCP servers.
  • DHCP ACK : Confirmation of the DHCP server to a DHCP REQUEST request or the transmission of configuration parameters that were previously requested by the client by DHCP INFORM .
  • DHCP NAK : Rejection of a DHCP REQUEST request by the DHCP server.
  • DHCP DECLINE : Rejection by the client because the IP address is already in use.
  • DHCP RELEASE : The client releases its own configuration so that the parameters are available again for other clients.
  • DHCP INFORM : Request from a client for further configuration parameters, e.g. B. because the client has a static IP address.

DHCP relay

DHCP relay is a function that enables DHCP to be used beyond network boundaries (broadcast domains). This avoids the need to provide a DHCP server on every subnet where DHCP clients are located. The DHCP relay function is usually performed by the router itself. On the client side, DHCP requests sent via broadcast are received by the DHCP relay and sent to one or more DHCP servers via unicast. The DHCP relay agent is functionally placed on the interface of the router.

DHCP and Active Directory

In an Active Directory , the DHCP service is integrated into the AD database. Only authorized servers are allowed to distribute leases. To authorize a server, it must be a DC or have a domain account.

Process of the DHCP communication

Procedure for assigning an IP address via DHCP

In order for the client to be able to use a DHCP server, it must be in the same network segment, as DHCP uses broadcasts and routers do not forward broadcasts (routers form broadcast domains ). If the DHCP server is in a different network segment , a so-called DHCP relay agent must be installed, which forwards the DHCP requests to the actual server.

Initial address assignment (lease / assignment)

When a client needs an IP address for the first time, it sends a DHCPDISCOVER message (with its MAC address) as a network broadcast to the available DHCP servers (there can be several of them in the same subnet). This broadcast has 0.0.0.0 as the sender IP address and 255.255.255.255 as the destination address, since the sender does not yet have an IP address and sends his request to "everyone". The UDP source port is 68 and the UDP destination port is 67. The DHCP servers respond with DHCPOFFER and make suggestions for an IP address. This happens either with a broadcast to the address 255.255.255.255 with UDP source port 67 and UDP destination port 68 or with a unicast to the suggested IP address and the MAC address of the client, depending on whether the client is in the DHCPDISCOVER message has set the broadcast bit.

The client can now choose from the offers received ( DHCPOFFER ). When he has decided on one (e.g. because of the longest lease time or because a special, possibly incorrectly configured DHCP server has been rejected, or simply for the first response), he contacts the via broadcast and a server identifier contained in the packet corresponding server with the message DHCPREQUEST . Any other DHCP servers consider this a rejection of their offers. The server selected by the client confirms the IP address with the other relevant data in a DHCPACK message (DHCP Acknowledged), or it withdraws its offer ( DHCPNAK , see also Miscellaneous).

Before the client configures its network interface with the assigned address, it should also check whether another computer is accidentally using the address. This is usually done by an ARP request with the IP address that has just been assigned. If another host in the network replies to this request, the client will reject the suggested address with a DHCPDECLINE message.

DHCP refresh (only with dynamic assignment)

Together with the IP address, the client receives the " lease time ", ie the period of validity of the IP configuration, two deadlines in the DHCPACK message : the " renewal time " T1 and the " rebinding time " T2. The standard suggests that T1 be set to half and T2 to 7/8, i.e. 87.5% of the validity period of the lease time . The DHCP server can optionally specify other values ​​for both values.

After the time T1 has expired, the client tries to extend its lease time . To do this, the client sends DHCPREQUEST s again via unicast to the server that assigned the IP configuration. The server should then normally send a DHCPACK with the same data as before, but with a new lease time . This means that the validity period of the client's IP configuration is considered extended.

If the server does not answer, for example because it has been switched off and a new server is now responsible for managing the IP addresses, the client can continue to use the IP configuration without restrictions until the lease time has expired. However, after T2 has expired , it will now start sending DHCPREQUESTs by broadcast in order to receive a new IP configuration from some other DHCP server.

If the client fails to apply for an extension by the end of the lease time, it must deconfigure its network card and start again with an initial address assignment with DHCPDISCOVER . If the DHCP server no longer has any addresses available or if another client has already been confirmed its last address during the process, the server sends a DHCPNAK (DHCP-Not Acknowledged) and the address request process begins again.

Others

A negative confirmation from DHCPNAK can be caused by the client trying to lease its former IP address, which is no longer available, or if the client computer has moved to a different subnet has been.

To reduce the probability of failure, it is also possible to place several DHCP servers in a network. It should be noted, however, that the address ranges of the individual servers do not overlap, otherwise double assignment of IP addresses can occur. There is also the “authoritative” setting, with which you can set whether a DHCPNAK should also be sent if the DHCP server is not responsible for the address suggested by the client.

If the client receives a negative acknowledgment, the DHCP lease process is started again.

A client sends DHCPRELEASE if it wants to return an IP address before the lease time expires.

If the client finds that the assigned address is already being used, it informs the server via DHCPDECLINE , which in turn should inform the administrator of this potential misconfiguration.

DHCP and DNS

In order for their name resolution to be possible, computers usually register their name and IP address with a DNS server. Some DHCP servers can do this in place of the clients. This was necessary for Microsoft operating systems prior to Windows 2000 .

Possible assignments

By default, DHCP can assign the following settings to the client, among others:

  • IP address and network mask
  • Default gateway
  • DNS server, DNS context and DNS tree
  • Secondary DNS server
  • Time (according to RFC 868 ) and NTP server
  • WINS server (for Microsoft Windows clients)
  • Proxy configuration via WPAD

However, there are far more DHCP options that the DHCP client can implement. A good example is the specification of a TFTP server for the operation of a diskless workstation . In this case, the BIOS / UEFI must support TFTP assignment via DHCP in order to initiate a PXE boot .

DHCP for multiple subnets

The DHCP server can serve (sub) networks if it has definitions for the respective network. The choice of definition is then determined by the network card through which the request comes in. When starting the DHCP server, you can specify which interfaces the server is listening to.

On the other hand, a DHCP server can also serve remote networks if these are connected by a DHCP relay agent (often available as a router function). The relay agent receives the DHCP broadcast requests in the remote network and forwards them as unicast messages to the configured DHCP server (s). The IP address of the interface over which the broadcast was received is added by the relay agent to the unicast packet in the DHCP header so that the DHCP server can use this information to determine from which network segment the request comes. The DHCP relay agent receives the response packets from the DHCP server on port UDP 67 and then forwards them to the client using destination port UDP 68.

safety

DHCP can easily be disturbed and tampered with because DHCP clients accept any DHCP server.

Inadvertent activation of a DHCP server, for example by connecting a simple DSL router or WLAN router in the delivery state, can largely paralyze a network. This may respond faster than the actually intended DHCP server and thus distribute invalid configurations.

An attacker can reserve all addresses of a DHCP server ( DHCP Starvation Attack ), thereby preventing its response to further queries and then acting as the only DHCP server. It now has the option of running rogue DHCP spoofing by redirecting to other DNS servers that point to computers that are compromising communication .

On the one hand, the attacker can start denial-of-service attacks , for example , by assigning each client its own subnet, not transmitting a gateway or responding to all inquiries with the same IP address. On the other hand, it can try to infiltrate a third-party router with the help of incorrect gateway and DNS information, which records or redirects the client's data traffic ( man-in-the-middle attack ).

The supposed uniqueness of the MAC address must not be used as a security criterion. It is far too easy to do MAC address spoofing . Almost all operating systems allow ordinary users to easily overwrite the MAC address in configuration masks or with simple tools such as ifconfig (UNIX, Linux) or ip link (Linux). Valid MAC addresses in a Layer 2 network can be found by listening to network traffic. All that is required is physical access to the network. The exclusive assignment of IP addresses only to registered MAC addresses via RARP or DHCP does not rule out unauthorized access to the network; this requires the use of a secure authentication mechanism such as IEEE 802.1X .

One satirical effort to circumvent these problems is the Peg DHCP clothespin protocol .

DHCPv6

IPv6 does not require a DHCP service for the actual address assignment (see IPv6 auto configuration ). However, in addition to a gateway, a client usually also needs the assignment of a DNS server. A standardized procedure for the notification of the DNS server is described in RFC 8106 (RDNSS, DNSSL) and represents an extension to auto-configuration. If configuration information is also required, DHCPv6 can be used instead of auto-configuration.

DHCPv6 has been specified in RFC 3315 since July 2003 and enables the same functionality for IPv6 as the current DHCPv4 for IPv4 . In addition, DHCPv6 is designed to transport configuration information via NIS + , SIP , NTP and other services via optional fields in the DHCPv6 protocol . Which options are included in DHCPv6 is determined by the IETF DHCP Working Group . Further features of DHCPv6 are the integrated security functions, through which it is possible to make DHCPv6 accessible only to authorized clients, as well as the possibility to continue the address configuration via stateless autoconfiguration, but to bring further configuration details to the clients via DHCPv6.

In contrast to DHCPv4, with v6 communication takes place via UDP ports 546 (client) and 547 (server).

literature

Specifications

  • RFC 2131 - Dynamic Host Configuration Protocol for IPv4
  • RFC 2132 - DHCP Options and BOOTP Vendor Extensions
  • RFC 2136 - Dynamic Updates in the Domain Name System (DNS UPDATE)
  • RFC 3315 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
  • RFC 3396 - Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)
  • RFC 4361 - Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
  • RFC 6221 - Lightweight DHCPv6 Relay Agent
  • RFC 6422 - Relay-Supplied DHCP Options
  • RFC 6644 - Rebind Capability in DHCPv6 Reconfigure Messages
  • RFC 6842 - Client Identifier Option in DHCP Server Replies

Web links

Individual evidence

  1. ↑ RFC 2131 - page 10 below. → Link (English)
  2. ↑ RFC 2131 , section 4.1, page 22.
  3. ↑ http://www.networksorcery.com/enp/protocol/bootp/options.htm
  4. ↑ DHCP: This is behind the Dynamic Host Configuration Protocol . 1und1.de/digitalguide. Retrieved October 2, 2017.