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
   be successful.

   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
   nefarious purposes.

   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
   resource.

   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
   service attack.

   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

      -  DUID

      -  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 [11].

   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 [11].  The
   final assignment of DHCP option codes is through Standards Action, as
   defined in RFC 2434 [11].

   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 [4].

   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
   both.

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.2. DHCP Message Types

   IANA has recorded the following message types (defined in section
   5.3).  IANA will maintain the registry of DHCP message types.

      SOLICIT               1

      ADVERTISE             2

      REQUEST               3

      CONFIRM               4

      RENEW                 5

      REBIND                6

      REPLY                 7

      RELEASE               8

      DECLINE               9

      RECONFIGURE           10

      INFORMATION-REQUEST   11

      RELAY-FORW            12

      RELAY-REPL            13

24.3. DHCP Options

   IANA has recorded the following option-codes (as defined in section
   22).  IANA will maintain the registry of DHCP option codes.

      OPTION_CLIENTID       1

      OPTION_SERVERID       2

      OPTION_IA_NA          3

      OPTION_IA_TA          4

      OPTION_IAADDR         5

      OPTION_ORO            6

      OPTION_PREFERENCE     7

      OPTION_ELAPSED_TIME   8

      OPTION_RELAY_MSG      9

      OPTION_AUTH           11

      OPTION_UNICAST        12

      OPTION_STATUS_CODE    13

      OPTION_RAPID_COMMIT   14

      OPTION_USER_CLASS     15

      OPTION_VENDOR_CLASS   16

      OPTION_VENDOR_OPTS    17

      OPTION_INTERFACE_ID   18

      OPTION_RECONF_MSG     19

      OPTION_RECONF_ACCEPT  20

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
   future.

   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
                     document.
   NoAddrsAvail    2 Server has no addresses available to assign to
                     the IA(s).
   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
                     address.

24.5. DUID

   IANA has recorded the following DUID types (as defined in section
   9.1).  IANA will manage the definition of additional DUID types in
   the future.

      DUID-LLT                       1

      DUID-EN                        2

      DUID-LL                        3

25. Acknowledgments

   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
   specifications.

   And, thanks to Steve Deering for pointing out at IETF 51 in London
   that the DHCPv6 specification has the highest revision number of any
   Internet Draft.

26. References

26.1. Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
        Networks", RFC 2464, December 1998.

   [3]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998.

   [4]  Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for DHCP
        Messages", RFC 3118, June 2001.

   [5]  Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

   [6]  IANA.  Private Enterprise Numbers.
        http://www.iana.org/assignments/enterprise-numbers.html.

   [7]  Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

   [8]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
        for Message Authentication", RFC 2104, February 1997.

   [9]  Mills, D., "Network Time Protocol (Version 3) Specification,
        Implementation", RFC 1305, March 1992.

   [10] Mockapetris, P., "Domain names - implementation and
        specification", RFC 1035, November 1987.

   [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [12] Narten, T. and R. Draves, "Privacy Extensions for Stateless
        Address Autoconfiguration in IPv6", RFC 3041, January 2001.

   [13] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
        IP Version 6 (IPv6)", RFC 2461, December 1998.

   [14] 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,
        November 1982.

   [15] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
        1980.

   [16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
        1992.

   [17] Thomson, S. and T. Narten, "IPv6 Stateless Address
        Autoconfiguration", RFC 2462, December 1998.

26.2. Informative References

   [18] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
        Extensions", RFC 2132, March 1997.

   [19] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
        March 1997.

   [20] R. Droms, Ed.  DNS Configuration options for DHCPv6.  April
        2002.  Work in Progress.

   [21] A. K. Vijayabhaskar.  Time Configuration Options for DHCPv6.
        May 2002.  Work in Progress.

   [22] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
        Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
        1997.

A. Appearance of Options in Message Types

   The following table indicates with a "*" the options are allowed in
   each DHCP message type:

           Client Server IA_NA  Option Pref  Time Relay Auth. Server
             ID     ID   IA_TA  Request            Msg.       Unica.
   Solicit   *             *      *           *           *
   Advert.   *      *      *            *                 *
   Request   *      *      *      *           *           *
   Confirm   *             *      *           *           *
   Renew     *      *      *      *           *           *
   Rebind    *             *      *           *           *
   Decline   *      *      *      *           *           *
   Release   *      *      *      *           *           *
   Reply     *      *      *            *                 *     *
   Reconf.   *      *             *                       *
   Inform.   * (see note)         *           *           *
   R-forw.                                          *     *
   R-repl.                                          *     *

   NOTE:

      Only included in Information-Request messages that are sent
      in response to a Reconfigure (see section 19.4.3).

            Status  Rap. User  Vendor Vendor Inter. Recon. Recon.
             Code  Comm. Class Class  Spec.    ID    Msg.  Accept
   Solicit           *     *     *      *                    *
   Advert.    *            *     *      *                    *
   Request                 *     *      *                    *
   Confirm                 *     *      *
   Renew                   *     *      *                    *
   Rebind                  *     *      *                    *
   Decline                 *     *      *
   Release                 *     *      *
   Reply      *      *     *     *      *                    *
   Reconf.                                            *
   Inform.                 *     *      *                    *
   R-forw.                 *     *      *      *
   R-repl.                 *     *      *      *

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      *
   IA_NA/IA_TA    *
   IAADDR                 *
   ORO            *
   Preference     *
   Elapsed Time   *
   Relay Message                        *      *
   Authentic.     *
   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.

Chair's Address

   The working group can be contacted via the current chair:

   Ralph Droms
   Cisco Systems
   1414 Massachusetts Avenue
   Boxborough, MA 01719

   Phone: (978) 936-1674
   EMail: rdroms@cisco.com

Authors' Addresses

   Jim Bound
   Hewlett Packard Corporation
   ZK3-3/W20
   110 Spit Brook Road
   Nashua, NH 03062-2698
   USA

   Phone:  +1 603 884 0062
   EMail:  Jim.Bound@hp.com

   Bernie Volz
   116 Hawkins Pond Road
   Center Harbor, NH  03226-3103
   USA

   Phone:  +1-508-259-3734
   EMail:  volz@metrocast.net

   Ted Lemon
   Nominum, Inc.
   950 Charter Street
   Redwood City, CA 94043
   USA

   EMail:  Ted.Lemon@nominum.com

   Charles E. Perkins
   Communications Systems Lab
   Nokia Research Center
   313 Fairchild Drive
   Mountain View, California 94043
   USA

   Phone:  +1-650 625-2986
   EMail:  charles.perkins@nokia.com

   Mike Carney
   Sun Microsystems, Inc
   17 Network Circle
   Menlo Park, CA 94025
   USA

   Phone:  +1-650-786-4171
   EMail:  michael.carney@sun.com

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
   English.

   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.