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.
- 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 both. 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
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
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
section 9.1). IANA will manage the definition of additional DUID types in the future. DUID-LLT 1 DUID-EN 2 DUID-LL 3
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.  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. http://www.iana.org/assignments/enterprise-numbers.html.  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, November 1982.  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.  Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.  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 1997.
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. * * * *
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.