DHCP - Managed Configuration of TCP/IP Hosts Dr. Ralph Droms Bucknell University DHCP - Managed Configuration of TCP/IP Hosts Dr. Ralph Droms Bucknell University

 DHCP purpose and goals  Background and history of DHCP  Operational details  Using DHCP  DHCP purpose and goals  Background and history of DHCP  Operational details  Using DHCP Outline

From RFC2131: The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP consists of 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. From RFC2131: The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP consists of 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. Purpose of DHCP

 A host without a valid IP address locates and communicates with a DHCP server  A DHCP server passes configuration parameters, including an IP address, to the host  The DHCP server may dynamically allocate addresses to hosts and reuse addresses  Hosts can detect when they require a new IP address  Unavailability of DHCP server has minimal effect on operation of hosts  A host without a valid IP address locates and communicates with a DHCP server  A DHCP server passes configuration parameters, including an IP address, to the host  The DHCP server may dynamically allocate addresses to hosts and reuse addresses  Hosts can detect when they require a new IP address  Unavailability of DHCP server has minimal effect on operation of hosts DHCP Functional Goals

 Provides protocol stack, application and other configuration parameters to hosts  Eliminates need for individual, manual configuration for hosts  Includes administrative controls for network administrators  Backward compatible packet format for BOOTP interoperation (RFC 1542)  Can coexist with hosts that have pre- assigned IP addresses and hosts that do not participate in DHCP  Provides protocol stack, application and other configuration parameters to hosts  Eliminates need for individual, manual configuration for hosts  Includes administrative controls for network administrators  Backward compatible packet format for BOOTP interoperation (RFC 1542)  Can coexist with hosts that have pre- assigned IP addresses and hosts that do not participate in DHCP What Does DHCP Do?

 Eliminate manual configuration of hosts  Prevent use of any IP address by more than one host  Should not require a server on every subnet  Allow for multiple servers  Provide a mechanism, not a policy  Provide same configuration - including IP address - to a host whenever possible  Eliminate manual configuration of hosts  Prevent use of any IP address by more than one host  Should not require a server on every subnet  Allow for multiple servers  Provide a mechanism, not a policy  Provide same configuration - including IP address - to a host whenever possible Design Goals

 Plug-and-play  Move clients/desktop PCs between offices  Renumber  Other restructuring - change subnet masks  Mobile IP - laptops  Moving equipment - cartable  Plug-and-play  Move clients/desktop PCs between offices  Renumber  Other restructuring - change subnet masks  Mobile IP - laptops  Moving equipment - cartable What Can You Do With DHCP?

 Support multiple addresses per interface  Inform running host that parameters have changed  Propagate new addresses to DNS (yet!)  Support inter-server communication (yet!)  Provide authenticated message delivery (yet!)  Support multiple addresses per interface  Inform running host that parameters have changed  Propagate new addresses to DNS (yet!)  Support inter-server communication (yet!)  Provide authenticated message delivery (yet!) What DHCP Doesn’t Do

 DHCP purpose and goals  Background and history of DHCP -Origin of DHCP -Specification documents -Protocol status  Operational details  Using DHCP  DHCP purpose and goals  Background and history of DHCP -Origin of DHCP -Specification documents -Protocol status  Operational details  Using DHCP Outline

 Internet Engineering Task Force (IETF)  Dynamic Host Configuration Working Group (DHC WG)  BootP  Internet Engineering Task Force (IETF)  Dynamic Host Configuration Working Group (DHC WG)  BootP What Is DHCP and Where Does It Come From?

 Formal process for development, review and acceptance of TCP/IP protocol suite standards  Initial specifications published as Internet Drafts (I-Ds)  Accepted specifications published as Request for Comments (RFCs)  Formal process for development, review and acceptance of TCP/IP protocol suite standards  Initial specifications published as Internet Drafts (I-Ds)  Accepted specifications published as Request for Comments (RFCs) IETF Standards

 DHCP has been accepted as a Draft Standard; the specifications are published in: -RFC 2131: Dynamic Host Configuration Protocol -RFC 2132: DHCP Options and BOOTP Vendor Extensions -RFC 1534: Interoperation between DHCP and BOOTP -RFC 1542: Clarifications and Extensions for the Bootstrap Protocol  Several additional options are in development  DHCP has been accepted as a Draft Standard; the specifications are published in: -RFC 2131: Dynamic Host Configuration Protocol -RFC 2132: DHCP Options and BOOTP Vendor Extensions -RFC 1534: Interoperation between DHCP and BOOTP -RFC 1542: Clarifications and Extensions for the Bootstrap Protocol  Several additional options are in development Protocol Status

 DHCP is an open standard, with freely available specifications  Can be (and has been) implemented entirely from the specification  Commercial implementations are widely available  Non-commerical implementations are also available  DHCP is an open standard, with freely available specifications  Can be (and has been) implemented entirely from the specification  Commercial implementations are widely available  Non-commerical implementations are also available Implementation Status

 Compilation of DHCP-related WWW links and other information:  DHCP FAQ (maintained by John Wobus):  mailing list (admin requests to  IETF information can be retrieved from:  I-Ds and RFCs can also be retrieved from:  Compilation of DHCP-related WWW links and other information:  DHCP FAQ (maintained by John Wobus):  mailing list (admin requests to  IETF information can be retrieved from:  I-Ds and RFCs can also be retrieved from: DHCP Resources

 RARP/DRARP  TFTP  ICMP  Router Discovery  Mobile IP  Wireless/“cellular” IP  RARP/DRARP  TFTP  ICMP  Router Discovery  Mobile IP  Wireless/“cellular” IP Related Work

 DHCP purpose and goals  Background and history of DHCP  Operational details -Server function -Address allocation and leases -Message sequences -Options  Using DHCP  DHCP purpose and goals  Background and history of DHCP  Operational details -Server function -Address allocation and leases -Message sequences -Options  Using DHCP Outline

 Provide a variety of mechanisms for controlled configuration  Can override default parameters from Host Requirements  “Classing” for individualized configuration of new hosts  Provide a variety of mechanisms for controlled configuration  Can override default parameters from Host Requirements  “Classing” for individualized configuration of new hosts Server Manages Client Configurations

 Static (BOOTP): client must be pre- configured into database  Automatic: server can allocate new address to client  Dynamic: server can allocate and reuse addresses  Static (BOOTP): client must be pre- configured into database  Automatic: server can allocate new address to client  Dynamic: server can allocate and reuse addresses Address Allocation

 Dynamic addresses are allocated for a period of time known as the lease  Client is allowed to use the address until the lease expires  Client MUST NOT use the address after the lease expires, even if there are active connections using the address  Server MUST NOT reuse the address before the lease expires  Dynamic addresses are allocated for a period of time known as the lease  Client is allowed to use the address until the lease expires  Client MUST NOT use the address after the lease expires, even if there are active connections using the address  Server MUST NOT reuse the address before the lease expires Leases

 An IP internet may not always be completely operational; there may not always be connectivity between any two hosts, so: -Can’t use distributed (client-based) assignment of addresses -Can’t use “address defense” before server reuse of addresses  Leases guarantee an agreement as to when an address may be safely reused even if the server can’t contact the client  An IP internet may not always be completely operational; there may not always be connectivity between any two hosts, so: -Can’t use distributed (client-based) assignment of addresses -Can’t use “address defense” before server reuse of addresses  Leases guarantee an agreement as to when an address may be safely reused even if the server can’t contact the client Motivation for Leases

 Server MAY choose to reuse an address by reassigning it to a different client after the lease has expired  Server can check using ICMP echo to see if the address is still in use (but no response is not a definitive answer!)  Allows address sharing -From old computers replaced by new ones -Among a pool of computers not always using TCP/IP -For transient hosts like laptops  Server MAY choose to reuse an address by reassigning it to a different client after the lease has expired  Server can check using ICMP echo to see if the address is still in use (but no response is not a definitive answer!)  Allows address sharing -From old computers replaced by new ones -Among a pool of computers not always using TCP/IP -For transient hosts like laptops Address Reuse

 Clients check on address validity at reboot time (renumbering)  Clients can extend the lease on an address at startup time  Clients can extend the lease on an address as expiration time approaches (without closing and restarting existing connections)  Clients with addresses that have been configured manually can use DHCP to obtain other configuration parameters  Clients check on address validity at reboot time (renumbering)  Clients can extend the lease on an address at startup time  Clients can extend the lease on an address as expiration time approaches (without closing and restarting existing connections)  Clients with addresses that have been configured manually can use DHCP to obtain other configuration parameters Address Allocation Details

 INIT - acquire an IP address and configuration information  INIT-REBOOT - confirm validity of previously acquired address and configuration  RENEWING - extend a lease from the original server  REBINDING - extend a lease from any server  INIT - acquire an IP address and configuration information  INIT-REBOOT - confirm validity of previously acquired address and configuration  RENEWING - extend a lease from the original server  REBINDING - extend a lease from any server Four Ways a Client Uses DHCP

 Client broadcasts DISCOVER to locate servers  Server chooses address and returns in OFFER  Client selects a server and sends REQUEST for address  Server commits allocation and returns ACK with address and other parameters  Client can now use configured address  Client broadcasts DISCOVER to locate servers  Server chooses address and returns in OFFER  Client selects a server and sends REQUEST for address  Server commits allocation and returns ACK with address and other parameters  Client can now use configured address ClientServer DISCOVER OFFER REQUEST ACK Obtaining A New Address

 Client puts address in REQUEST and broadcasts  Server checks validity and returns ACK with parameters  Client puts address in REQUEST and broadcasts  Server checks validity and returns ACK with parameters ClientServer REQUEST ACK Rebooting Client

 Client puts requested lease extension in REQUEST and sends to server  Server commits extension and returns ACK with parameters  Client puts requested lease extension in REQUEST and sends to server  Server commits extension and returns ACK with parameters ClientServer REQUEST ACK Renewing Client

 Client puts requested lease extension in REQUEST and broadcasts  Server commits extension and returns ACK  Client puts requested lease extension in REQUEST and broadcasts  Server commits extension and returns ACK ClientServer REQUEST ACK Rebinding Client

 Client broadcasts INFORM  Server returns ACK with parameters  Client broadcasts INFORM  Server returns ACK with parameters ClientServer INFORM ACK Client With Externally Configured Address

 Using hardware and IP broadcast still limits DHCP message from client to single physical network  Relay agent can retransmit DHCP message to a remote server  Server replies to relay agent, which retransmits the message to the DHCP client  Relay agent and server exchange messages using unicast UDP -Servers can be located anywhere on organization’s internet -Servers can be centrally located for ease of administration  Using hardware and IP broadcast still limits DHCP message from client to single physical network  Relay agent can retransmit DHCP message to a remote server  Server replies to relay agent, which retransmits the message to the DHCP client  Relay agent and server exchange messages using unicast UDP -Servers can be located anywhere on organization’s internet -Servers can be centrally located for ease of administration Relay Agents

 Client and server are on different physical networks  Client and relay agent are on same physical network  Relay agent retransmits broadcast from client and response from server  Client and server are on different physical networks  Client and relay agent are on same physical network  Relay agent retransmits broadcast from client and response from server ClientServer REQUEST ACK Relay agent REQUEST ACK Illustration of Relay Agent

 Identical to BOOTP relay agents (except for ‘broadcast flag’)  Very simple in function and implementation -Stateless; all information carried in DHCP messages -Needs to examine only a couple of header fields, not the entire DHCP message and options  Usually, but not necessarily, located in routers  More than one relay agent on a physical network is OK  Identical to BOOTP relay agents (except for ‘broadcast flag’)  Very simple in function and implementation -Stateless; all information carried in DHCP messages -Needs to examine only a couple of header fields, not the entire DHCP message and options  Usually, but not necessarily, located in routers  More than one relay agent on a physical network is OK Implementation of Relay Agents

 DHCP purpose and goals  Background and history of DHCP  Operational details  Using DHCP -Using multiple servers -Lease times and strategies -Some scenarios for using DHCP -Integrated DHCP/IP address management tools  DHCP purpose and goals  Background and history of DHCP  Operational details  Using DHCP -Using multiple servers -Lease times and strategies -Some scenarios for using DHCP -Integrated DHCP/IP address management tools Outline

 Client behavior is designed to accommodate multiple servers  Using multiple servers can provide reliability through redundancy -UDP does not guarantee delivery -Server may be down  All coordination must be managed by DHCP administrator -Distributed database -Off-line batch updates -Manually  Client behavior is designed to accommodate multiple servers  Using multiple servers can provide reliability through redundancy -UDP does not guarantee delivery -Server may be down  All coordination must be managed by DHCP administrator -Distributed database -Off-line batch updates -Manually Using Multiple Servers

 Split address pool for each subnet among servers  Coordinate leases off-line  Reallocate addresses when needed  Split address pool for each subnet among servers  Coordinate leases off-line  Reallocate addresses when needed Strategies For Using Multiple Servers

 Choice of lease times made by DHCP administrator  Long lease times decrease traffic and server load, short lease times increase flexibility  Should choose lease time allow for server unavailability -Allows clients to use old addresses -For example, long enough to span weekends  Can use management tools to differentiate between desktop computers, cartable systems and laptops  Choice of lease times made by DHCP administrator  Long lease times decrease traffic and server load, short lease times increase flexibility  Should choose lease time allow for server unavailability -Allows clients to use old addresses -For example, long enough to span weekends  Can use management tools to differentiate between desktop computers, cartable systems and laptops Lease Times and Strategies

 Fresh out-of-the-box systems  Renumbering  Changing other parameters  Moving to new location  Replacing a system  Fresh out-of-the-box systems  Renumbering  Changing other parameters  Moving to new location  Replacing a system Scenarios

 500 new computers show up on loading dock Friday afternoon  Software loaded, network cards installed - all ready to go  But... these systems go to six different departments in three different buildings  500 new computers show up on loading dock Friday afternoon  Software loaded, network cards installed - all ready to go  But... these systems go to six different departments in three different buildings New Systems

 Make sure network infrastructure is in place -Routers (correctly configured) -Network addresses -Subnet masks -DHCP servers  Configure DHCP management with class identifiers (if desired)  Plug them in...  Make sure network infrastructure is in place -Routers (correctly configured) -Network addresses -Subnet masks -DHCP servers  Configure DHCP management with class identifiers (if desired)  Plug them in... New Systems - DHCP Solution

 Network administrator may have to change IP addresses across significant parts of an enterprise internet -Change in subnet numbering scheme -Change of ISP -Restructuring of internal network architecture  Want to minimize downtime  Network administrator may have to change IP addresses across significant parts of an enterprise internet -Change in subnet numbering scheme -Change of ISP -Restructuring of internal network architecture  Want to minimize downtime Renumbering

 Set up plan for renumbering -New network architecture -Network addresses, server addresses -Timing of cutovers  Force DHCP clients to contact server for notification about new address -Set short leases -Require all clients be rebooted  Set up plan for renumbering -New network architecture -Network addresses, server addresses -Timing of cutovers  Force DHCP clients to contact server for notification about new address -Set short leases -Require all clients be rebooted Renumbering - DHCP Solution

 Use FQDNs for servers; when servers move, DHCP clients will find new IP addresses  Rebooting, although not elegant, probably most reliable  Schedule subnet cutover for overnight or weekend, force reboot through “alternate protocol” (e.g.., e- mail to all users)  Use FQDNs for servers; when servers move, DHCP clients will find new IP addresses  Rebooting, although not elegant, probably most reliable  Schedule subnet cutover for overnight or weekend, force reboot through “alternate protocol” (e.g.., e- mail to all users) Renumbering - DHCP Solution

 Other configuration parameters such as print servers may change  Reconfigure DHCP server with new parameters  At next reconfirmation, clients will get new addresses  Use INFORM on computers that get IP addresses through some other mechanism  Other configuration parameters such as print servers may change  Reconfigure DHCP server with new parameters  At next reconfirmation, clients will get new addresses  Use INFORM on computers that get IP addresses through some other mechanism Changing Other Configuration Parameters

 User may get moved to a new location on a different subnet  User may arrange to move computer system without contacting network administrator  DHCP will allocate address for new location  What about old lease? -New server can notify network administrator about address allocation -Client can issue RELEASE before moving from old location  User may get moved to a new location on a different subnet  User may arrange to move computer system without contacting network administrator  DHCP will allocate address for new location  What about old lease? -New server can notify network administrator about address allocation -Client can issue RELEASE before moving from old location Moving A Client To A New Location

 User may get new computer on desktop  Network administrator wants to allocate same IP address to the new computer  But, new computer will have different hardware address  Use client id as system identifier and transfer to new system  User may get new computer on desktop  Network administrator wants to allocate same IP address to the new computer  But, new computer will have different hardware address  Use client id as system identifier and transfer to new system Replacing A System

 DHCP works today as a tool for automatic configuration of TCP/IP hosts  It is an open Internet standard and interoperable client implementations are widely available  Ongoing work will extend DHCP with authentication, DHCP-DNS interaction and inter-server communication  DHCP works today as a tool for automatic configuration of TCP/IP hosts  It is an open Internet standard and interoperable client implementations are widely available  Ongoing work will extend DHCP with authentication, DHCP-DNS interaction and inter-server communication Summary