23. Security Considerations
The threat to DHCP is inherently an insider threat (assuming a
properly configured network where DHCPv6 ports are blocked on the
perimeter gateways of the enterprise). Regardless of the gateway
configuration, however, the potential attacks by insiders and
outsiders are the same.
Use of manually configured preshared keys for IPsec between relay
agents and servers does not defend against replayed DHCP messages.
Replayed messages can represent a DOS attack through exhaustion of
processing resources, but not through mis-configuration or exhaustion
of other resources such as assignable addresses.
One attack specific to a DHCP client is the establishment of a
malicious server with the intent of providing incorrect configuration
information to the client. The motivation for doing so may be to
mount a "man in the middle" attack that causes the client to
communicate with a malicious server instead of a valid server for
some service such as DNS or NTP. The malicious server may also mount
a denial of service attack through misconfiguration of the client
that causes all network communication from the client to fail.
There is another threat to DHCP clients from mistakenly or
accidentally configured DHCP servers that answer DHCP client requests
with unintentionally incorrect configuration parameters.
A DHCP client may also be subject to attack through the receipt of a
Reconfigure message from a malicious server that causes the client to
obtain incorrect configuration information from that server. Note
that although a client sends its response (Renew or
Information-request message) through a relay agent and, therefore,
that response will only be received by servers to which DHCP messages
are relayed, a malicious server could send a Reconfigure message to a
client, followed (after an appropriate delay) by a Reply message that
would be accepted by the client. Thus, a malicious server that is
not on the network path between the client and the server may still
be able to mount a Reconfigure attack on a client. The use of
transaction IDs that are cryptographically sound and cannot easily be
predicted will also reduce the probability that such an attack will
The threat specific to a DHCP server is an invalid client
masquerading as a valid client. The motivation for this may be for
theft of service, or to circumvent auditing for any number of
The threat common to both the client and the server is the resource
"denial of service" (DoS) attack. These attacks typically involve
the exhaustion of available addresses, or the exhaustion of CPU or
network bandwidth, and are present anytime there is a shared
In the case where relay agents add additional options to Relay
Forward messages, the messages exchanged between relay agents and
servers may be used to mount a "man in the middle" or denial of
This threat model does not consider the privacy of the contents of
DHCP messages to be important. DHCP is not used to exchange
authentication or configuration information that must be kept secret
from other networks nodes.
DHCP authentication provides for authentication of the identity of
DHCP clients and servers, and for the integrity of messages delivered
between DHCP clients and servers. DHCP authentication does not
provide any privacy for the contents of DHCP messages.
The Delayed Authentication protocol described in section 21.4 uses a
secret key that is shared between a client and a server. The use of
a "DHCP realm" in the shared key allows identification of
administrative domains so that a client can select the appropriate
key or keys when roaming between administrative domains. However,
the Delayed Authentication protocol does not define any mechanism for
sharing of keys, so a client may require separate keys for each
administrative domain it encounters. The use of shared keys may not
scale well and does not provide for repudiation of compromised keys.
This protocol is focused on solving the intradomain problem where the
out-of-band exchange of a shared key is feasible.
Because of the opportunity for attack through the Reconfigure
message, a DHCP client MUST discard any Reconfigure message that does
not include authentication or that does not pass the validation
process for the authentication protocol.
The Reconfigure Key protocol described in section 21.5 provides
protection against the use of a Reconfigure message by a malicious
DHCP server to mount a denial of service or man-in-the-middle attack
on a client. This protocol can be compromised by an attacker that
can intercept the initial message in which the DHCP server sends the
key to the client.
Communication between a server and a relay agent, and communication
between relay agents, can be secured through the use of IPSec, as
described in section 21.1. The use of manual configuration and
installation of static keys are acceptable in this instance because
relay agents and the server will belong to the same administrative
domain and the relay agents will require other specific configuration
(for example, configuration of the DHCP server address) as well as
the IPSec configuration.
24. IANA Considerations
This document defines several new name spaces associated with DHCPv6
and DHCPv6 options:
- Message types
- Status codes
- Option codes
IANA has established a registry of values for each of these name
spaces, which are described in the remainder of this section. These
name spaces will be managed by the IANA and all will be managed
separately from the name spaces defined for DHCPv4.
New multicast addresses, message types, status codes, and DUID types
are assigned via Standards Action .
New DHCP option codes are tentatively assigned after the
specification for the associated option, published as an Internet
Draft, has received expert review by a designated expert . The
final assignment of DHCP option codes is through Standards Action, as
defined in RFC 2434 .
This document also references three name spaces in section 21 that
are associated with the Authentication Option (section 22.11). These
name spaces are defined by the authentication mechanism for DHCPv4 in
RFC 3118 .
The authentication name spaces currently registered by IANA will
apply to both DHCPv6 and DHCPv4. In the future, specifications that
define new Protocol, Algorithm and RDM mechanisms will explicitly
define whether the new mechanisms are used with DHCPv4, DHCPv6 or
24.1. Multicast Addresses
Section 5.1 defines the following multicast addresses, which have
been assigned by IANA for use by DHCPv6:
All_DHCP_Relay_Agents_and_Servers address: FF02::1:2
All_DHCP_Servers address: FF05::1:3
24.4. Status Codes
IANA has recorded the status codes defined in the following table.
IANA will manage the definition of additional status codes in the
Name Code Description
---------- ---- -----------
Success 0 Success.
UnspecFail 1 Failure, reason unspecified; this
status code is sent by either a client
or a server to indicate a failure
not explicitly specified in this
NoAddrsAvail 2 Server has no addresses available to assign to
NoBinding 3 Client record (binding) unavailable.
NotOnLink 4 The prefix for the address is not appropriate for
the link to which the client is attached.
UseMulticast 5 Sent by a server to a client to force the
client to send messages to the server.
using the All_DHCP_Relay_Agents_and_Servers
IANA has recorded the following DUID types (as defined in section
9.1). IANA will manage the definition of additional DUID types in
Thanks to the DHC Working Group and the members of the IETF for their
time and input into the specification. In particular, thanks also
for the consistent input, ideas, and review by (in alphabetical
order) Bernard Aboba, Bill Arbaugh, Thirumalesh Bhat, Steve Bellovin,
A. K. Vijayabhaskar, Brian Carpenter, Matt Crawford, Francis Dupont,
Richard Hussong, Kim Kinnear, Fredrik Lindholm, Tony Lindstrom, Josh
Littlefield, Gerald Maguire, Jack McCann, Shin Miyakawa, Thomas
Narten, Erik Nordmark, Jarno Rajahalme, Yakov Rekhter, Mark Stapp,
Matt Thomas, Sue Thomson, Tatuya Jinmei and Phil Wells.
Thanks to Steve Deering and Bob Hinden, who have consistently taken
the time to discuss the more complex parts of the IPv6
And, thanks to Steve Deering for pointing out at IETF 51 in London
that the DHCPv6 specification has the highest revision number of any
26.1. Normative References
 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
 Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
 Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
 Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for DHCP
Messages", RFC 3118, June 2001.
 Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
 IANA. Private Enterprise Numbers.
 Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
 Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
 Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992.
 Mockapetris, P., "Domain names - implementation and
specification", RFC 1035, November 1987.
 Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
 Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
 Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
 Plummer, D.C., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet address
for transmission on Ethernet hardware", STD 37, RFC 826,
 Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
 Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
26.2. Informative References
 Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
 Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
 R. Droms, Ed. DNS Configuration options for DHCPv6. April
2002. Work in Progress.
 A. K. Vijayabhaskar. Time Configuration Options for DHCPv6.
May 2002. Work in Progress.
 Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
B. Appearance of Options in the Options Field of DHCP Options
The following table indicates with a "*" where options can appear in
the options field of other options:
Option IA_NA/ IAADDR Relay Relay
Field IA_TA Forw. Reply
Client ID *
Server ID *
Elapsed Time *
Relay Message * *
Server Uni. *
Status Code * * *
Rapid Comm. *
User Class *
Vendor Class *
Vendor Info. *
Interf. ID * *
Reconf. MSG. *
Reconf. Accept *
Note: "Relay Forw" / "Relay Reply" options appear in the options
field of the message but may only appear in these messages.
The working group can be contacted via the current chair:
1414 Massachusetts Avenue
Boxborough, MA 01719
Phone: (978) 936-1674
Hewlett Packard Corporation
110 Spit Brook Road
Nashua, NH 03062-2698
Phone: +1 603 884 0062
116 Hawkins Pond Road
Center Harbor, NH 03226-3103
950 Charter Street
Redwood City, CA 94043
Charles E. Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
Phone: +1-650 625-2986
Sun Microsystems, Inc
17 Network Circle
Menlo Park, CA 94025
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 languages other than
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC Editor function is currently provided by the