idnits 2.17.1 draft-droms-dhcpv6-issues-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2002) is 7853 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (ref. '1') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2373 (ref. '2') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2462 (ref. '3') (Obsoleted by RFC 4862) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-27 ** Obsolete normative reference: RFC 2461 (ref. '6') (Obsoleted by RFC 4861) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Droms 3 Internet-Draft Cisco Systems 4 Expires: April 27, 2003 October 27, 2002 6 Issues Concerning DHCP in IPv6 Specifications 7 draft-droms-dhcpv6-issues-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on April 27, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 There are several issues related to DHCPv6 in various IPv6 documents 39 that require clarification or resolution. The v6ops working group 40 discussed these issues at an interim meeting in August, 2002. This 41 document presents those issues and summarizes the v6ops working group 42 discussion. 44 1. Introduction 46 There are several issues related to DHCPv6 in various IPv6 documents 47 that require clarification or resolution. The v6ops working group 48 discussed these issues at an interim meeting in August, 2002. This 49 document presents those issues and summarizes the v6ops working group 50 discussion. 52 2. Terminology 54 This document uses IPv6 terminology from "The IPv6 Protocol" (RFC 55 2460 [1]), "IPv6 Addressing Architecture "(RFC 2373 [2]), and "IPv6 56 Stateless Address Autoconfiguration" (RFC 2462 [3]). This document 57 also uses the DHCP terminology from "Dynamic Host Configuration 58 Protocol for IPv6 (DHCPv6)" [4]. 60 3. Requirements 62 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 63 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 64 document, are to be interpreted as described in RFC 2119 [5]. 66 4. Operational issues concerning DHCPv6 68 This section presents the issues discussed at the v6ops working group 69 interim meeting and a summary of the discussion of each issue. 70 Except as noted, the v6ops working group suggested that these issues 71 should be referred to the ipv6 working group for further discussion. 73 4.1 "Stateful autoconfiguration" == DHCPv6? 75 Issue: IPv6 documents refer loosely to "stateful autoconfiguration" 76 (SAC) as an alternative to "stateless address autoconfiguration" [3] 77 (SLAAC). Does this reference require clarification; e.g., should 78 DHCP be cited as the mechanism to use for "stateful 79 autoconfiguration"? 81 Discussion: The consensus was that references to "stateful 82 autoconfiguration" should be clarified to DHCP. 84 4.2 'M', 'O' and 'A' bits 86 Issue: The interaction of 'M', 'O' and 'A' bits with SLAAC and SAC 87 may not be clear [6][3]. Summary of bits: 89 1. 'A' bit set in the prefix advertisement causes hosts to perform 90 SLAAC on the prefix, independent of the 'M' and 'O' bits in the 91 router advertisement (RA). 93 2. 'M' bit set in the prefix advertisement causes SAC for address 94 assignment (and implies 'O' bit), independent of SLAAC; 'M' bit 95 not set gives no guidance on use of DHCP. 97 3. 'O' bit set in RA causes SAC for other configuration (not address 98 assignment); 'O' bit not set gives not guidance on use of DHCP. 100 As an example of the use of these bits, a network administrator can 101 restrict hosts to use of SAC for address assignment (disallowing 102 SLAAC) by setting the 'M' bit in RAs and not setting the 'A' bit in 103 any prefix advertisements. 105 Discussion: Some relevant text from section 4 of RFC 2462 may clarify 106 points 2 and 3: 108 A "managed address configuration" flag indicates whether hosts 109 should use stateful autoconfiguration to obtain addresses. An 110 "other stateful configuration" flag indicates whether hosts should 111 use stateful autoconfiguration to obtain additional information 112 (excluding addresses). 114 This text can be interpreted to mean that if the 'M' bit and 'O' bit 115 are not set, the host does not use SAC. 117 The consensus was that this issue could use some additional 118 clarification. 120 4.3 Requirement for DHCP 122 Issue: Does the requirement for SAC, as controlled by the 'M' and 'O' 123 bits, imply that an IPv6 implementation MUST include DHCP? 125 Discussion: There was no clear consensus. During the discussion, 126 doubt about the utility of the 'M' and 'O' bits was raised, now that 127 DHCP and the reserved address for DNS resolvers mechanism has been 128 defined. If the 'O' bit is set, is it useful to preclude use of the 129 reserved resolver addresses if the host doesn't receive a response 130 from a DHCP server? 132 4.4 SLAAC and DHCP address assignment from the same prefix 134 Issue: Is use of SLAAC and DHCP address assignment from the same 135 prefix OK? 137 Discussion: DAD should prevent conflict between SLAAC and DHCP 138 addresses. See following section for discussion of inconsistency 139 between RA prefix lifetimes and DHCP address lifetimes. 141 4.5 Inconsistencies between SLAAC and DHCP 143 Issue: Is the description of what to do when SLAAC and DHCP provide 144 inconsistent information - e.g., prefix/address lifetimes - 145 sufficiently clear? 146 Discussion: Section 6.3.4 of RFC 2461 includes the following text: 148 When multiple routers are present, the information advertised 149 collectively by all routers may be a superset of the information 150 contained in a single Router Advertisement. Moreover, information 151 may also be obtained through other dynamic means, such as stateful 152 autoconfiguration. Hosts accept the union of all received 153 information; the receipt of a Router Advertisement MUST NOT 154 invalidate all information received in a previous advertisement or 155 from another source. However, when received information for a 156 specific parameter (e.g., Link MTU) or option (e.g., Lifetime on a 157 specific Prefix) differs from information received earlier, and 158 the parameter/option can only have one value, the most recently- 159 received information is considered authoritative. 161 However, this test doesn't clarify, for example, whether a preferred 162 lifetime on a prefix as obtained from a prefix advertisement 163 overrides the preferred lifetime on an address assigned through DHCP 165 4.6 Reserved interface identifiers 167 Issue: Should there be an explicit recommendation in the DHCPv6 168 specification against assigning addresses through DHCP that use any 169 reserved interface identifiers? 171 Discussion: Yes. 173 5. Security considerations 175 This document has no references to security issues. 177 6. Acknowledgments 179 This document is based on the discussion of of DHCPv6 issues at the 180 v6ops working group interim meeting of August, 2002. Thanks to Bob 181 Fink for compiling the minutes from that meeting, and to Bob Hinden, 182 Bernie Volz and Margaret Wasserman for their review and input. 184 References 186 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 187 Specification", RFC 2460, December 1998. 189 [2] Hinden, R. and S. Deering, "IP Version 6 Addressing 190 Architecture", RFC 2373, July 1998. 192 [3] Thomson, S. and T. Narten, "IPv6 Stateless Address 193 Autoconfiguration", RFC 2462, December 1998. 195 [4] Droms, R., Perkins, C., Bound, J., Volz, B., Carney, M. and T. 196 Lemon, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 197 draft-ietf-dhc-dhcpv6-27 (work in progress), October 2002. 199 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 200 Levels", BCP 14, RFC 2119, March 1997. 202 [6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 203 IP Version 6 (IPv6)", RFC 2461, December 1998. 205 Author's Address 207 Ralph Droms 208 Cisco Systems 209 300 Apollo Drive 210 Chelmsford, MA 01824 211 USA 213 Phone: +1 978 497 4733 214 EMail: rdroms@cisco.com 216 Full Copyright Statement 218 Copyright (C) The Internet Society (2002). All Rights Reserved. 220 This document and translations of it may be copied and furnished to 221 others, and derivative works that comment on or otherwise explain it 222 or assist in its implementation may be prepared, copied, published 223 and distributed, in whole or in part, without restriction of any 224 kind, provided that the above copyright notice and this paragraph are 225 included on all such copies and derivative works. However, this 226 document itself may not be modified in any way, such as by removing 227 the copyright notice or references to the Internet Society or other 228 Internet organizations, except as needed for the purpose of 229 developing Internet standards in which case the procedures for 230 copyrights defined in the Internet Standards process must be 231 followed, or as required to translate it into languages other than 232 English. 234 The limited permissions granted above are perpetual and will not be 235 revoked by the Internet Society or its successors or assigns. 237 This document and the information contained herein is provided on an 238 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 239 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 240 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 241 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 242 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 244 Acknowledgement 246 Funding for the RFC Editor function is currently provided by the 247 Internet Society.