Network Working Group R. Droms Internet-Draft Cisco Systems Expires: April 27, 2003 October 27, 2002 Issues Concerning DHCP in IPv6 Specifications draft-droms-dhcpv6-issues-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 27, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract There are several issues related to DHCPv6 in various IPv6 documents that require clarification or resolution. The v6ops working group discussed these issues at an interim meeting in August, 2002. This document presents those issues and summarizes the v6ops working group discussion. 1. Introduction There are several issues related to DHCPv6 in various IPv6 documents that require clarification or resolution. The v6ops working group discussed these issues at an interim meeting in August, 2002. This document presents those issues and summarizes the v6ops working group Droms Expires April 27, 2003 [Page 1] Internet-Draft Issues Concerning DHCP in IPv6 Specifications October 2002 discussion. 2. Terminology This document uses IPv6 terminology from "The IPv6 Protocol" (RFC 2460 [1]), "IPv6 Addressing Architecture "(RFC 2373 [2]), and "IPv6 Stateless Address Autoconfiguration" (RFC 2462 [3]). This document also uses the DHCP terminology from "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" [4]. 3. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [5]. 4. Operational issues concerning DHCPv6 This section presents the issues discussed at the v6ops working group interim meeting and a summary of the discussion of each issue. Except as noted, the v6ops working group suggested that these issues should be referred to the ipv6 working group for further discussion. 4.1 "Stateful autoconfiguration" == DHCPv6? Issue: IPv6 documents refer loosely to "stateful autoconfiguration" (SAC) as an alternative to "stateless address autoconfiguration" [3] (SLAAC). Does this reference require clarification; e.g., should DHCP be cited as the mechanism to use for "stateful autoconfiguration"? Discussion: The consensus was that references to "stateful autoconfiguration" should be clarified to DHCP. 4.2 'M', 'O' and 'A' bits Issue: The interaction of 'M', 'O' and 'A' bits with SLAAC and SAC may not be clear [6][3]. Summary of bits: 1. 'A' bit set in the prefix advertisement causes hosts to perform SLAAC on the prefix, independent of the 'M' and 'O' bits in the router advertisement (RA). 2. 'M' bit set in the prefix advertisement causes SAC for address assignment (and implies 'O' bit), independent of SLAAC; 'M' bit not set gives no guidance on use of DHCP. 3. 'O' bit set in RA causes SAC for other configuration (not address Droms Expires April 27, 2003 [Page 2] Internet-Draft Issues Concerning DHCP in IPv6 Specifications October 2002 assignment); 'O' bit not set gives not guidance on use of DHCP. As an example of the use of these bits, a network administrator can restrict hosts to use of SAC for address assignment (disallowing SLAAC) by setting the 'M' bit in RAs and not setting the 'A' bit in any prefix advertisements. Discussion: Some relevant text from section 4 of RFC 2462 may clarify points 2 and 3: A "managed address configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain addresses. An "other stateful configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain additional information (excluding addresses). This text can be interpreted to mean that if the 'M' bit and 'O' bit are not set, the host does not use SAC. The consensus was that this issue could use some additional clarification. 4.3 Requirement for DHCP Issue: Does the requirement for SAC, as controlled by the 'M' and 'O' bits, imply that an IPv6 implementation MUST include DHCP? Discussion: There was no clear consensus. During the discussion, doubt about the utility of the 'M' and 'O' bits was raised, now that DHCP and the reserved address for DNS resolvers mechanism has been defined. If the 'O' bit is set, is it useful to preclude use of the reserved resolver addresses if the host doesn't receive a response from a DHCP server? 4.4 SLAAC and DHCP address assignment from the same prefix Issue: Is use of SLAAC and DHCP address assignment from the same prefix OK? Discussion: DAD should prevent conflict between SLAAC and DHCP addresses. See following section for discussion of inconsistency between RA prefix lifetimes and DHCP address lifetimes. 4.5 Inconsistencies between SLAAC and DHCP Issue: Is the description of what to do when SLAAC and DHCP provide inconsistent information - e.g., prefix/address lifetimes - sufficiently clear? Droms Expires April 27, 2003 [Page 3] Internet-Draft Issues Concerning DHCP in IPv6 Specifications October 2002 Discussion: Section 6.3.4 of RFC 2461 includes the following text: When multiple routers are present, the information advertised collectively by all routers may be a superset of the information contained in a single Router Advertisement. Moreover, information may also be obtained through other dynamic means, such as stateful autoconfiguration. Hosts accept the union of all received information; the receipt of a Router Advertisement MUST NOT invalidate all information received in a previous advertisement or from another source. However, when received information for a specific parameter (e.g., Link MTU) or option (e.g., Lifetime on a specific Prefix) differs from information received earlier, and the parameter/option can only have one value, the most recently- received information is considered authoritative. However, this test doesn't clarify, for example, whether a preferred lifetime on a prefix as obtained from a prefix advertisement overrides the preferred lifetime on an address assigned through DHCP 4.6 Reserved interface identifiers Issue: Should there be an explicit recommendation in the DHCPv6 specification against assigning addresses through DHCP that use any reserved interface identifiers? Discussion: Yes. 5. Security considerations This document has no references to security issues. 6. Acknowledgments This document is based on the discussion of of DHCPv6 issues at the v6ops working group interim meeting of August, 2002. Thanks to Bob Fink for compiling the minutes from that meeting, and to Bob Hinden, Bernie Volz and Margaret Wasserman for their review and input. References [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [2] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [3] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. Droms Expires April 27, 2003 [Page 4] Internet-Draft Issues Concerning DHCP in IPv6 Specifications October 2002 [4] Droms, R., Perkins, C., Bound, J., Volz, B., Carney, M. and T. Lemon, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-27 (work in progress), October 2002. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Author's Address Ralph Droms Cisco Systems 300 Apollo Drive Chelmsford, MA 01824 USA Phone: +1 978 497 4733 EMail: rdroms@cisco.com Droms Expires April 27, 2003 [Page 5] Internet-Draft Issues Concerning DHCP in IPv6 Specifications October 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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. Droms Expires April 27, 2003 [Page 6]