380 likes | 394 Views
Dynamic Host Configuration Protocol (DHCP) explained - history, design goals, message formats, operations, event flows, performance & security issues, including DHCPv6. Overview of topics related to DHCP management.
E N D
DHCPDynamic Host Configuration Protocol VRUSHALI SONAR
Introduction • History (BOOTP) • Purpose of DHCP • Design goals • Message formats and message fields • Operations of DHCP • Event flows and State machine • Performance issues, Problems and Security issues • Extension: DHCPv6 • Conclusion and Reference Summary of topics
Every computer on a TCP/IP network must have a unique IP address. The IP address identifies both the host computer and the subnet to which it is attached. When you move a computer to a different subnet, the IP address must be changed. DHCP allows you to dynamically assign an IP address to a client from a DHCP server IP address database: Introduction
Dynamic Host Configuration Protocol(DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. • DHCP is based on the Bootstrap Protocol(BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. • DHCP captures the behavior of BOOTP relay agents and DHCP participants can interoperate with BOOTP participants.
DHCP was created by the Dynamic Host Configuration Working Group of the Internet Engineering Task Force (IETF). • It was first defined in RFC 1531 October 1993 written by Ralph Droms at Bucknell University. Then, RFC 1541 in same month, same year. • In March 1997, he made some changes in RFC 2131. History of DHCP
DHCP is an extension of Bootstrap protocol (BOOTP) • BOOTP allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. BOOTP
Similarities of DHCP and BOOTP: - Client/server model - Nearly identical message structure (BOOTP/DHCP relay agent usually treat their messages as the same message type without differentiating them) - UDP port numbers(67/68) (Both BOOTP and DHCP servers use UDP port 67 to listen for and receive client request messages. And both their clients use 68 for accepting message replies from either a BOOTP or DHCP server) - IP address distribution as an integral part of configuration service BOOTP (cont.)
Two major differences: 1. BOOTP database was static and maintained manually (DHCP database is dynamic. The size of the database is dependent upon the number of DHCP clients on the network. The DHCP database grows and shrinks over time.) 2. BOOTP server cannot do dynamic allocation and distribution of IP addresses to the hosts. (It provides fixed allocation of a single IP address for each client, permanently reserving this address in its database. However, DHCP provides dynamic, leased allocation of available IP addresses, reserving each DHCP client address temporarily in the database.) BOOTP (cont.)
Enable individual hosts on an IP network to extract their configuration from a DHCP server or servers. Purpose of DHCP • IP address allocation to the hosts. • Overall, reduce the administrator’s work for a large IP network.
Automatic allocation: • Dynamic allocation: • Manual allocation: Three mechanisms to allocate IP address to hosts - assigns a permanent IP address to a client - assigns an IP address to a client for a limit time or until the client explicitly relinquishes the address - network administrator assigns a client’s IP address, DHCP is just to convey the assigned address to the client
DHCP should be a mechanism rather than a policy • Clients should require no manual configuration • Networks should require no manual configuration for individual clients • DHCP should not require a server on each subnet (most routers can forward DHCP configuration requests) • A DHCP client must be prepared to receive multiple responses to a request for configuration parameters • DHCP must coexist with statically configured, non-participating hosts and with existing network protocol implementations • DHCP must interoperate with the BOOTP relay agent • DHCP must provide service to existing BOOTP clients. General Design goal of DHCP
Guarantee that any specific network address will not be in use by more than one DHCP client at a time • Retain DHCP client configuration across DHCP client reboot • Retain DHCP client configuration across server reboots and whenever possible, a DHCP client should be assigned the same configuration parameters despite restarts of the DHCP mechanism • Allow automated assignment of configuration parameters to new clients to avoid hand configuration for new clients • Support fixed or permanent allocation of configuration parameters to specific clients Design goal for network layer
Message formats & Message fields Opcode: 1 for BOOTREQUEST, 2 for BOOTREPLY Hardware type: 1 for Ethernet … 33 for CAI (Common Air Interface) Hop count: This field is used by relay agents. Transaction ID: A random number chosen by the client, used by the client and server to associate messages and responses between a client and a server. Number of seconds: The elapsed time in seconds since the client began an address acquisition or renewal process.
Message formats & Message fields (cont.) Client IP address: only filled in if client is in BOUND, RENEW or REBINDING state and can respond to ARP requests. Your (client) IP address. Gateway IP address: is Relay agent IP address, used in booting via a relay agent. Boot file name: null terminated string; "generic" name or null in DHCPDISCOVER, fully qualified directory-path name in DHCPOFFER.
DHCPDISCOVER: broadcast to locate available servers • DHCPREQUEST either: (a) requesting offered parameters from one server and implicitly declining offers from all others (b) confirming correctness of previously allocated address after extending the lease on a particular network address • DHCPDECLINE: indicating network address is already in use • DHCPRELEASE: relinquishing network address and canceling remaining lease • DHCPINFORM: asking only for local configuration parameters; client already has externally configured network address Client’s operations
DHCPOFFER: • response to DHCPDISCOVER with offer of configuration parameters • DHCPACK: • Contains configuration parameters and committed network address • DHCPNAK: • indicating refusing request for configuration parameters (e.g., requested network address already allocated). Server’s operations
Two kinds of event flow Event flow for allocating a new network address Event flow for reusing a previous allocated network address
Step by step to allocate a new network address The client broadcasts a DHCPDISCOVER message on its local physical subnet. Each server may respond with a DHCPOFFER message that includes an available network address The client receives one or more DHCPOFFER messages from and chooses one server, then broadcasts a DHCPREQUEST message include the 'server identifier' to indicate the selected server. 1 2 3
Step by step to allocate a new network address 4. The servers receive the DHCPREQUEST broadcast from the client. The selected server commits the binding for the client to persistent storage and responds with a DHCPACK message containing the configuration parameters for the requesting client. 5. The client receives the DHCPACK message with configuration parameters. 6. The client may choose to relinquish its lease on a network address by sending a DHCPRELEASE message to the server. 4 5 6
A much more Clear View 1. DHCPDISCOVER 2. DHCPOFFER 3. DHCPREQUEST 4. DHCPACK DHCP client 5. DHCPRELEASE DHCP server
Event flows for reusing a previous allocated network address
Step by step to reuse a previous allocated network address The client broadcasts a DHCPREQUEST message on its local subnet. The message includes the client's network address in the 'requested IP address' option. 2. Servers with knowledge of the client's configuration parameters respond with a DHCPACK message to the client. Servers SHOULD NOT check that the client's network address is already in use; the client may respond to ICMP Echo Request messages at this point. If the client's request is invalid (e.g., the client has moved to a new subnet), servers SHOULD respond with a DHCPNAK message to the client. 1 2
Step by step to reuse a previous allocated network address 3. The client receives the DHCPACK message with configuration parameters and performs a final check on the parameters, notes the duration of the lease specified in the DHCPACK message. 4. The client may choose to relinquish its lease on a network address by sending a DHCPRELEASE message to the server. 3 4
A much more Clear View 1. DHCPREQUEST 2. DHCPACK DHCP client 3. DHCPRELEASE DHCP server
Highlight for a successful allocation of new network address
Highlight for a successful reusing a previously allocated address
The client maintains two times, T1 and T2, that specify the times at which the client tries to extend its lease on its network address. • T1 is the time at which the client enters the RENEWING state and attempts to contact the server • T2 is the time at which the client enters the REBINDING state and attempts to contact any server. • T1 MUST be earlier than T2, which MUST be earlier than the time at which the client's lease will expire. Reacquisition and expiration
A DHCP server should be able to start up very quickly. (Don’t need do a lot of things such as committing entries in the transaction log to its database and load a lot information into memory) • A DHCP server should be persistence. (Means it should be able to keep state and also recover from a disaster) • DHCP server should be able to quickly receive, process, and answer requests. Performance issues
Malicious DHCP server (May lead misconfiguration across entire network) • Malicious DHCP client (denial-of-service attack on DHCP servers by requesting many leases from the server, thereby depleting the number of leases that are available to other DHCP clients) • DHCP is built directly on UDP and IP which are as yet inherently insecure. • DHCP is generally intended to make maintenance of remote and/or diskless hosts easier. Configuring such hosts with passwords or keys may be difficult and inconvenient. Therefore, DHCP in its current form is quite insecure. Problems, Security issues
The Dynamic Host Configuration Protocol for IPv6 enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. • It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. IPv6 defines 2 classifications of address auto-configuration: • Stateless • nodes configure addresses themselves with information from routers • no managed addresses • Stateful • nodes use DHCPv6 to obtain addresses. • Duplicate address detection (DAD) used to avoid duplicated addresses Extension: DHCPv6
The DHCPv6, RFC 3315, submitted in July 2003, proposes an almost entire rewrite of DHCPv4, complete with authentication and interoperability with stateless auto-configuration. DHCPv6 (more) • DHCPv6 Versus DHCPv4 (major differences): • Unlike DHCPv4, IPv6 address allocation in DHCPv6 is handled using a message option instead in the main header. • The operations such as DHCPDISCOVER and DHCPOFFER supported by DHCPv4 are removed in DHCPv6. Instead, DHCPv6 servers are located by a client SOLICIT message followed by a server ADVERTISE message. • Now, DHCPv6 clients can request multiple IPv6 addresses.
DHCP provides a framework for passing configuration information to hosts on a TCP/IP network. • It supports three mechanisms for IP address allocation: automatic, dynamic and manual allocation. • It saves a lot of work for network administrator. • However, remember that DHCP in its current form is quite insecure. There are some security issues about it. • Now, newer version of DHCP is DHCPv6. It is for passing configuration parameters to a node in IPv6 network. Conclusion
1. RFC 1531, 1541, 2131, 3315 www.ietf.org RFC database 2.The DHCP handbook http://www.dhcp-handbook.com/dhcp_faq.html 3. Debugging DHCP Performance http://www.cs.wisc.edu/~suman/pubs/imc04.pdf 4. Windows server 2003: DHCP http://technet2.microsoft.com/WindowsServer/en/Library/8cf0b3bf-0ea2-4dcf-a3b9-d71ba386f5e51033.mspx Reference