Transcript Ralph`s DHCP #2a

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

New Options Acceptance
New options must have nonoverlapping 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-
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
FQDN modifier
XX
56
NIS server
41
16
LPR server
LPR server
12
12
17
17
'n'
'i'
's'
'.'
'b'
'u'
'c'
'k'
'n'
'e'
'l'
'l'
'.'
'e'
'd'
'u'
'l'
'p'
'r'
'1'
'.'
'b'
'u'
'c'
'k'
'n'
'e'
'l'
'l'
'.'
'e'
'd'
'u'
'l'
'p'
'r'
'2'
'.'
'b'
'u'
'c'
'n'
'e'
'l'
'l'
'.'
'e'
'd'
'u'
'k'
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-ietfdhc-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

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

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
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
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
Inter-Server Protocol
“An Inter-server Protocol for DHCP,”
by Kinnear, Cole and Droms (draftietf-interserver-02.txt) addresses the
“windows”
 Based on the Server Cache
Synchronization Protocol (draft-ietfion-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
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 endto-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
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
