DHC Markus Rentschler
Internet Draft Hirschmann Electronics
Expires: April 2004 November 2003
DHCP Discovery Extensions
<draft-rentschler-dhc-discovery-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The discovery mechanism described here is built upon and coexists
with BOOTP according to RFC 1542 and DHCP according to RFC 2131
and RFC 3203.
It allows server-initiated communication to specific or all clients
in the network, using the DHCP packet format and with that the
relay agent functionality.
The Discovery mechanism is a powerful and flexible extension to
client-initiated DHCP that allows a variety of applications,
for example:
- Discovery and supervision of clients in the network
- Server-initiated configuration of clients
- DHCP server redundancy
Rentschler Expires April 2004 [Page 1]
Internet-Draft DHCP Discovery Extensions Nov 2003
Requirements terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
1. Introduction
Host Configuration using "traditional" DHCP according to RFC 2131
is based on host- (client-) initiated communication. If a network
is booting, all the clients start sending DHCP requests until
accepting an answer from a DHCP server.
The server may either allocate IP addresses out of a pool of
available adresses or, similar to BOOTP, pre-configured static
IP addresses and configuration parameters for each known client.
These concepts did not intend server-initiated and -controlled
configuration or reconfiguration of clients. This capability was
later partially added with RFC 3203, but the mechanism there does
not allow to discover "silent" clients yet unknown to the server
or trigger the configuration of such a client.
This is especially limiting when a server is later plugged to an
already configured network.
These shortcomings will be overcome with the protocol extensions
described in this document, which will provide useful functionality
for centralized network administration:
- scanning the network for clients even prior to their
initialization with IP parameters. Building a database of all
clients present in a network.
- detecting and identifying duplicate network addresses
- administrator controlled reconfiguration of certain clients
- server redundancy mechanism
The main goal of the discovery extension is to allow as much
flexibility as possible for the server to communicate with the
client(s) to allow a wide range of applications, which are not
subject of this document.
The DHCP discovery extensions may also be adopted for DHCPv6.
Rentschler Expires April 2004 [Page 2]
Internet-Draft DHCP Discovery Extensions Nov 2003
2. The DHCP Discovery Protocol
One of the intentions of the DHCP Discovery Protocol Extension is
to work with an inactive DHCP client (the client is not sending
initial DHCPDISCOVER messages) to allow the configuration process
be entirely performed and controlled by the administrator's
management station, without having the network "spammed" with
DHCPDISCOVER-Requests.
The DHCP Discovery Protocol MUST also work with an active client
(the client is sending initial DHCPDISCOVER messages).
This server-initiated communication mechanism has basically the
following modes of operation:
The server sends the new DHCPNETSCAN message into the network,
either as broadcast to all clients or directed to a certain client.
The client responds with the new DHCPREPORT message containing
the client's actual parameter settings. All servers that receive
the DHCPREPORT message SHOULD use the information contained in
this message to maintain their internal database (list of clients
and leases).
With this mechanism all available DHCP servers in the network
can collect information about granted leases and can take over in
the normal rebinding process if the granting server fails.
For the configuration of a certain client the server sends the
new DHCPCONFIGURE message to this client that MUST contains all
parameters required to set the client's IP stack in operation.
The client responds with a DHCPREPORT message back to the
server(s) to indicate if it accepted the new configuration
parameters. The DHCP client MUST maintain its internal database
and MUST release an already existing lease by sending a DHCPRELEASE
message, if it accepted new IP settings.
The server that has granted a lease MUST be able to renew and rebind
that lease.
All other servers that have sufficient information about that lease
in their database MAY rebind it as well to provide server redundancy.
Rentschler Expires April 2004 [Page 3]
Internet-Draft DHCP Discovery Extensions Nov 2003
3. New DHCP message types
Three messages MUST be added to the set of existing DHCP messages:
DHCPNETSCAN
DHCPCONFIGURE
DHCPREPORT
The value of the message types -to be encoded in DHCP option 53-
is left as TBD until assigned by IANA.
Existing correct implementations of DHCP clients or servers SHOULD
ignore and discard these new message types.
To existing correct implementations of BOOTP relay agents these new
message types SHOULD be transparent.
3.1 DHCPNETSCAN message
The DHCPNETSCAN message is sent from a server to one client
(unicast) or to all clients (broadcast). A broadcasted DHCPNETSCAN
message SHOULD be broadcasted into a relay agent's other subnets.
Its purpose is to request the client's actual parameter settings
and report them to the server(s) by triggering a DHCPREPORT message.
Field Contents
----- ------------
'op' BOOTREPLY (RFC 2131: server to client direction)
'xid' 'xid' from server
'secs' 0
'flags' Set 'BROADCAST' flag if server requires broadcast reply
'ciaddr' 0 or client's network address
'yiaddr' 0
'siaddr' IP address of server
'giaddr' 0 or the target relay agent's interface IP adress
'chaddr' 0 or client's hardware address
'sname' unused
'file' unused
'options' 53: DHCP Message Type: DHCPNETSCAN
54: Server Identifier
55: Parameter Request List
82: Relay information option (MAY be used for path information,
if a relay is involved in transportation to the client)
Rentschler Expires April 2004 [Page 4]
Internet-Draft DHCP Discovery Extensions Nov 2003
3.2 DHCPCONFIGURE message
The DHCPCONFIGURE message is sent from a server to a certain client.
Its purpose is to provide the client with new parameter settings.
Field Contents
----- ------------
'op' BOOTREPLY (RFC 2131: server to client direction)
'xid' 'xid' from server
'secs' 0
'flags' Set 'BROADCAST' flag if server requires broadcast reply
'ciaddr' 0 or client's network address
'yiaddr' IP address for client
'siaddr' IP address of server
'giaddr' 0
'chaddr' 0 or client's hardware address
'sname' Server host name or options
'file' Client boot file name or options
'options' 53: DHCP Message Type: DHCPCONFIGURE
54: Server Identifier
55: Parameter Request List
additional any other option, which must then also be
present in the parameter request list.
It is recommended that upon ip configuration the following options
SHOULD be included:
01: Subnet Mask
03: Router
51: IP address lease time
61: Client-Identifier
For reconfiguration of single non-ip parameters, only the options
representing these parameters are required to transmit.
Rentschler Expires April 2004 [Page 5]
Internet-Draft DHCP Discovery Extensions Nov 2003
3.3 DHCPREPORT message
The purpose of this message is to report the client's actual
parameter settings to one or all servers. It is the acknowledgement
towards the server upon a DHCPNETSCAN or DHCPCONFIGURE request.
The DHCPREPORT message is sent from a client to a server as
broadcast or unicast, depending on the 'BROADCAST' flag in the
original DHCPNETSCAN or DHCPCONFIGURE message and the state of
the client's IP stack. A client that has not yet assigned a
valid IP address SHOULD always broadcast this message,
using 0.0.0.0 as source address and the limited broadcast
address 255.255.255.255 as destination address.
Field Contents
----- ------------
'op' BOOTREQUEST (RFC 2131: client to server direction)
'xid' 'xid' from server
'secs' 0 or seconds since DHCP process started
'flags' flags from DHCPNETSCAN or DHCPNETCONIFG message
'ciaddr' 0 or client's network address
'yiaddr' IP address of client
'siaddr' 0
'giaddr' 0
'chaddr' client's hardware address
'sname' Server host name or options
'file' Client boot file name or options
'options' 53: DHCP Message Type: DHCPREPORT
54: Server Identifier
57: Maximum DHCP Message Size
additional all supported options requested
in DHCPNETSCAN or DHCPCONFIGURE.
The client MUST omit any options it cannot provide.
Rentschler Expires April 2004 [Page 6]
Internet-Draft DHCP Discovery Extensions Nov 2003
4. The DHCP Server
DHCP Server implementations MAY incorporate any administrative
conrols or policies desired by network administrators that make use
of the underlying protocol described in this and related documents.
DHCP servers that support the protocol described in this document
MUST be able to send DHCPNETSCAN and DHCPCONFIGURE messages,
either automatically at startup, program controlled, in certain
intervals and/or on manual requests.
The content of the BROADCAST flag in the DHCPNETSCAN and
DHCPCONFIGURE messages SHOULD be configurable and disabled
by default.
The DHCP server MUST be able to receive DHCPREPORT messages and
SHOULD use them to verify the state of pending requests.
The 'xid' field SHOULD be used by the server to match incoming DHCP
messages with pending requests.
Pending requests SHOULD be supervised using a timeout mechanism.
The timeout value MUST be configurable and SHOULD have a default
value of 4 seconds.
A retransmission strategy for unacknowledged requests SHOULD be
implemented.
The server MAY use all received DHCPREPORT messages to build and
maintain an internal database (based on IP addresses), that MAY
contain all known leases in the network. This database MAY be
periodically updated by sending DHCPNETSCAN messages.
If a server receives a DHCPREPORT message for a lease that was
granted by itself, the contents MUST be checked for consistency
with the internal lease database.
If any inconsistency is detected (i.e. unknown MAC address or
wrong relay agent information option contents), these DHCPREPORTS
MUST be ignored and their occurence MUST be reported to the
administrator.
It is RECOMMENDED that a timeout mechanism removes expired leases
in this database.
The server MUST be able to renew and rebind existing leases which
were granted by itself.
The server MAY be able to rebind existing leases which were not
granted by itself, but are listed in its internal database as known
leases. This feature should be configurable and disabled by default.
If duplicate IP addresses are detected in the database, the server
SHOULD report this to the administrator.
If duplicate client identifiers (DHCP Option 61) are detected in
the database, the server MAY report this to the administrator.
Rentschler Expires April 2004 [Page 7]
Internet-Draft DHCP Discovery Extensions Nov 2003
5. The DHCP Client
The DHCP client needs to be modified to incorporate the handling of
the new message types.
The clients network interface MUST always be able to receive
BOOTREPLY packets on its UDP client port (68), even if the local
IP stack has not yet assigned a valid IP address.
DHCPNETSCAN and DHCPCONFIGURE messages MUST always be processed,
even if the local DHCP client is not active in terms of sending
initial DHCPDISCOVER messages.
It SHOULD be configurable whether a client is allowed to accept
reconfiguration due to receipt of a DHCPCONFIGURE message from
another than its initially lease-granting server.
This feature SHOULD be enabled by default.
It is RECOMMENDED that normal DHCP (sending initial DHCPDISCOVER
messages) is enabled by default.
The client MUST respond to a DHCPNETSCAN or DHCPCONFIGURE message
with the message DHCPREPORT and return the requested parameters
to the server.
The Message DHCPREPORT contains always the client's current
parameter settings. The client MUST omit any parameters it cannot
provide.
The sending of a broadcast DHCPREPORT message that was generated
in response to a DHCPNETSCAN message SHOULD be delayed a random time
interval up to 2 seconds to prevent broadcast storms on the network.
DHCPNETSCAN messages that arrive in the meantime, SHOULD be silently
discarded and not queued for processing.
The client's handling of a received DHCPNETSCAN message SHOULD be
the same in every state of the DHCP client's state machine. It SHOULD
not affect the current state of the client's state machine.
The receipt of a DHCPCONFIGURE message MUST result in the
following actions:
If the message and the parameters offered to the client are correct
and acceptance of DHCPCONFIGURE is not disabled, the new parameters
MUST be accepted. An existing lease MUST be terminated by
sending a DHCPRELEASE message. Then the client's IP stack is
initialized with the new parameters and the client sends a
DHCPREPORT to the server, containing the new parameter settings.
Then the DHCP client's state machine always enters the state BOUND
and starts its timers T1 and T2 for the renewing/rebinding process.
If any DHCP message received by the client contains a relay agent
information option, this field MAY be examined for informational
purposes.
Rentschler Expires April 2004 [Page 8]
Internet-Draft DHCP Discovery Extensions Nov 2003
6. The BOOTP Relay Agent
DHCPNETSCAN messages that are received as IP broadcast on one of
the relay's interfaces MUST be broadcasted in all other IP subnets
accessible by this relay agent.
This option SHOULD be configurable and disabled by default.
DHCPNETSCAN messages that are received as IP unicast directed to
one of the relay agent's IP interfaces and have the giaddr field
set to the same interface address MUST be broadcasted only on the
physical ports attached to this IP interface. This allows scanning
of a specified subnet.
This option SHOULD be configurable and disabled by default.
If one of the above packets -directed to the client- has the relay
agent information option present, this field SHOULD be examined.
If the contents of the Agent Remote ID matches the relay agent's
unique identifier (i.e. MAC, Client-Id or an IP address) AND the
Agent Circuit ID suboption contains a valid physical port number,
this information SHOULD be used to forward the DHCPNETSCAN
message to the client.
Rentschler Expires April 2004 [Page 9]
Internet-Draft DHCP Discovery Extensions Nov 2003
7. Security Considerations
In this section possible security attacks and prevention
mechanisms will be discussed.
- Denial of Service attacks through DHCPNETSCAN
A bogus server may flood the network with broadcast DHCPNETSCAN
messages at such a rate, that due to multiple client responses
other communication will slow down.
In order to keep damage low in case of such an attack, the client
delays the generation of the DHCPREPORT message and discards
DHCPNETSCAN messages that were received in the meantime.
- Denial of Service attacks through DHCPCONFIGURE
A bogus server may send DHCPCONFIGURE packets to misconfigure
clients in the network. To prevent this the client incorporates
a configurable mechanism that only allows reconfiguration by the
initially lease-granting server. An authentication mechanism can be
used to verify the integritiy of this server.
- Denial of Service attacks through DHCPREPORT
A bogus client may send DHCPREPORT packets into the network to
misinform servers about existing leases in the network.
A server that has granted a lease needs to check incoming
DHCPREPORTS concerning this lease for consistency.
8. IANA Considerations
The value for the new message types
DHCPNETSCAN
DHCPCONFIGURE
DHCPREPORT
must be assigned from the numbering space defined for message types
in RFC 2939.
Rentschler Expires April 2004 [Page 10]
Internet-Draft DHCP Discovery Extensions Nov 2003
9. References
RFC 1542 W. Wimer, October 1993,
"Clarifications/Extensions for the Bootstrap Protocol",
RFC 2131 R. Droms, March 1997,
"The Dynamic Host Configuration Protocol",
RFC 2939 R. Droms, September 2000,
"Procedures an IANA guidelines for Definition
of new DHCP Options and Message Types",
RFC 3046, M. Patrick, January 2001,
"DHCP Relay Agent Information Option",
RFC 3118 R. Droms and W. Arbaugh, June 2001,
"Authentication for DHCP Messages",
RFC 3203, Y. T'Joens et. al., December 2001,
"DHCP reconfigure extension",
10. Acknowledgments
We Acknowledge the help of .... and all the members of the
development department at Hirschmann Electronics GmbH & Co. KG.
11. Author's Address
Markus Rentschler
Hirschmann Electronics GmbH & Co. KG,
Neckartenzlingen,
Germany.
Email: mrentsch@nt.hirschmann.de
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into.
Rentschler Expires April 2004 [Page 11]