The Future of DHCP Dr. Ralph Droms Bucknell University

Futures Draft Standard status New options DHCP and DNS Inter-server protocol Authentication DHCPv6

DHCP to “Draft Standard” DHCP has been accepted as a “Draft Standard” Rules for progression in STD 1 (currently, RFC 1920) Multiple, independent, interoperable implementations Sufficient time for review as ”Proposed Standard” Will be submitted for full “Standard” status New options will progress through process independently

New Options Acceptance New options must have non-overlapping option codes Numbers handed out by Internet Assigned Numbers Authority (IANA) New mechanism approves each new option as a separate RFC (like TELNET)

User Class Identifier Encodes category or type of user or applications - for example, ACCOUNTING or SALES Classes locally defined by DHCP administrator Client may specify more than one class Server interpretation is implementation dependent; policy is determined by DHCP administrator Server returns class in response so client knows if it was accepted See “The User Class Option for DHCP, “ by Stump and Droms (draft-ietf-dhc-userclass-01.txt)

FQDN Modifier Options that identify servers only allow for 32-bit IP addresses If servers change IP addresses, clients may not be informed FQDN (Fully Qualified Domain Name) modifier allow options to replace IP addresses with FQDNs See “An Option for FQDNs in DHCP Options,” by Rekhter and Droms (draft-ietf-dhc-fqdn-opt-03.txt)

FQDN Modifier Example

Option Extension BOOTP established 0-127 as globally defined, 128-254 as locally defined options Currently have defined roughly 80 options Option extension defines option 127 as a tag for more suboptions See “An Extension to the DHCP Option Codes,” by Droms (draft-ietf-dhc-options-opt127-03.txt)

Server Selection Option Client may receive multiple OFFERs and must choose one server OFFERs may not include enough information for client to make “good” choice Server selection option will include server identification on which client can base selection See “The Server Selection Option for DHCP,” by Stump and Gupta (draft-ietf-dhc-sso-00.txt)

Allocation From Network With Multiple Subnets Relay agent must pick one address to put in ‘giaddr’ If there are multiple subnets on one physical network, which address should relay agent choose? Always picking one limits flexibility in allocation Specifying rules requires configuration of each relay agent

Allocation From Network With Multiple Subnets (con’t) Server must have knowledge of network architecture and set of policies about allocating addresses based on ‘giaddr’ Different relay agents may insert different values for ‘giaddr’ Must be described as set of subnets that appear on same physical subnet DHCP administrator can use classing options to define allocation policy See “Subnet Selection Option for DHCP,” by Townsley (draft-ietf-dhc-subsel-00.txt)

Other New Options Options for Service Location Protocol IEEE 1003.1 POSIX timezone specification Relay agent information Multicast address allocation Netware/IP and NDS Subnet selection Domain search See www.bucknell.edu/~droms/dhcp for pointers

Dynamic DNS When client is allocated a new address, DNS records need to be updated A record: Name to IP address PTR record: IP address to name Newly defined extensions to DNS for dynamic updates allow updates through the network DHCP extended to allow coordination between client and server Which does updates Error conditions

Inter-Server Communication Becomes a distributed database problem Windows when information managed by servers is inconsistent Newly allocated addresses Extended leases Released addresses Solution - look at those windows carefully Determine which are really a problem Fix just those problem windows This slide used to be titled “problems with multiple servers”

Windows Newly allocated address, not yet propagated to other servers Other servers can’t provide redundancy Won’t return incorrect information Extended lease, not yet propagated to other servers Client can choose longest outstanding lease Early expiration simply implies server discards lease from database Released lease, not yet propagated to other servers Client may reboot and send DISCOVER May get back old lease from servers that haven’t been notified

Reusing Addresses When reusing an address, must be very careful to ensure that it is not in use All servers must be polled to make sure there are no outstanding leases In response to a RELEASE, server informs all other servers to terminate that lease Server can’t reuse until all other servers have been polled If any servers have extended the lease after the RELEASE message was received, address can’t be reused

Inter-Server Protocol “An Inter-server Protocol for DHCP,” by Kinnear, Cole and Droms (draft-ietf-interserver-02.txt) addresses the “windows” Based on the Server Cache Synchronization Protocol (draft-ietf-ion-scsp-01.txt) From IP-over-ATM (ION) WG Used for, e.g., ATMARP Currently under discussion in WG

Security / Authentication Unauthorized - either intentional or accidental - server can cause denial of service problems Server authentication allows clients to discard messages from bogus servers Some sites may want to limit IP address allocation to authorized client Client authentication allows servers to disregard requests from unauthorized clients

Security / Authentication (con’t) Authentication based on shared private key, an authentication ticket and a message digest Assures source of message is valid and message hasn’t been tampered with en route ‘giaddr’ causes problems with end-to-end IP security

Security / Authentication (con’t) Alternative 1: simple cleartext identifier in message Alternative 2: shared secret between server and client (Schiller/Huitema) Alternative 3: public key exchange (Gudmundsson)

Change Management Many new options have been proposed Some make fundamental changes to DHCP as interpreted by client and server Others involve new data types (e.g., FQDN) Each change requires development and deployment of new software

DHCPv2 ? “Freeze” DHCP at present state and study process for developing new options Define and deploy new option set Accommodate data typing for options that may carry multiple types Use new “cookie” value to identify new syntax

IPv6 IP Version 6 (aka IPv6 or IPng) is a new internet protocol to replace IP Includes new features for host configuration: Router advertisement Autoconfiguration Link-local addresses To accommodate sites that want centralized management of addresses, DHCP for IPv6 (DHCPv6) is being developed by the DHC WG.

DHCPv6 DHCPv6 client uses link-local address to find relay agent and server Client puts relay agent and server addresses in request avoids relay agent modifying message client must perform PMTU fragmentation Client can request multiple addresses from server May use DHCPv6 more than once to obtain addresses from server Client can request server drop all current addresses at initialization

Reconfiguring IPv6 Clients IPv6 accommodates dynamic renumbering Server may need to force clients to reconfirm current addresses RECONFIGURE message tells client to contact server for new configuration information

Summary 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