The Future of DHCP

Dr. Ralph DromsBucknell University

The Future of DHCP

Dr. Ralph DromsBucknell University

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

FuturesFutures

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

DHCP to “Draft Standard”DHCP to “Draft Standard”

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)

New Options AcceptanceNew Options Acceptance

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)

User Class IdentifierUser Class Identifier

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 ModifierFQDN Modifier

XX 56

41 16 'n' 'i' 's' '.' 'n'

'e' 'l' 'l' '.' 'e' 'd' 'u'

12 17 'l' 'u''r' '.' 'b''1''p' 'k'

FQDN modifier

NIS server

LPR server

'b' 'u' 'c' 'k'

'c'

'n' 'e' 'l' 'l' '.' 'e' 'd' 'u'

12 17 'l' 'u''r' '.' 'b''2''p' 'k''c'

'n' 'e' 'l' 'l' '.' 'e' 'd' 'u'

LPR server

FQDN Modifier ExampleFQDN Modifier Example

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)

Option ExtensionOption Extension

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)

Server Selection OptionServer Selection Option

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

Allocation From Network With Multiple Subnets

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)

Allocation From Network With Multiple Subnets (con’t)

Allocation From Network With Multiple Subnets (con’t)

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

Other New OptionsOther New Options

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

Dynamic DNSDynamic DNS

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

Inter-Server CommunicationInter-Server Communication

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

WindowsWindows

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

Reusing AddressesReusing Addresses

“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

Inter-Server ProtocolInter-Server Protocol

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 / AuthenticationSecurity / Authentication

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)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)

Security / Authentication (con’t)Security / Authentication (con’t)

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

Change ManagementChange Management

“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

DHCPv2 ?DHCPv2 ?

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.

IPv6IPv6

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

DHCPv6DHCPv6

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

Reconfiguring IPv6 ClientsReconfiguring IPv6 Clients

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

SummarySummary