idnits 2.17.00 (12 Aug 2021) /tmp/idnits26600/draft-ietf-ipv6-ra-flags-option-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 277. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 295. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 301. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (September 13, 2007) is 5357 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) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 180 ** Obsolete normative reference: RFC 2461 (ref. '1') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '4') (Obsoleted by RFC 6275) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Haberman, Ed. 3 Internet-Draft JHU APL 4 Intended status: Standards Track R. Hinden 5 Expires: March 16, 2008 Nokia 6 September 13, 2007 8 IPv6 Router Advertisement Flags Option 9 draft-ietf-ipv6-ra-flags-option-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 16, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The IPv6 Neighbor Discovery's Router Advertisement message contains 43 an 8-bit field reserved for single-bit flags. Several protocols have 44 reserved flags in this field and others are preparing to reserve a 45 sufficient number of flags to exhaust the field. This document 46 defines an option to the Router Advertisement message that expands 47 the available number of flag bits available. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Current Router Advertisement Flags . . . . . . . . . . . . . . 3 54 4. Flags Expansion Option . . . . . . . . . . . . . . . . . . . . 4 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 59 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 61 Intellectual Property and Copyright Statements . . . . . . . . . . 8 63 1. Introduction 65 The IPv6 Neighbor Discovery Protocol's [1] Router Advertisement 66 message contains an 8-bit field reserved for single-bit flags. 67 Several protocols have reserved flags in this field and others are 68 preparing to reserve a sufficient number of flags to exhaust the 69 field. 71 This document defines an option for the Router Advertisement message 72 that expands the available number of flag bits by adding an 73 additional 48 flag bits to NDP messages. 75 2. Terminology 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [2]. 81 3. Current Router Advertisement Flags 83 Currently, the NDP Router Advertisement message contains the 84 following one-bit flags defined in published RFCs: 86 0 1 2 3 4 5 6 7 87 +-+-+-+-+-+-+-+-+ 88 |M|O|H|Prf|P|R|R| 89 +-+-+-+-+-+-+-+-+ 91 Figure 1: Router Advertisement Flags 93 o M - Managed Address Configuration Flag [1] 95 o O - Other Configuration Flag [1] 97 o H - Mobile IPv6 Home Agent Flag [4] 99 o Prf - Router Selection Preferences [5] 101 o P - Neighbor Discovery Proxy Flag [6] 103 o R - Reserved 105 With other protocols in the works (e.g., Detecting Network 106 Attachment) that are wanting to use flags in the NDP messages, it is 107 necessary to define an expansion capability to support new features. 109 4. Flags Expansion Option 111 The Neighbor Discovery specification [1] contains the capability to 112 define NDP options. The following (Figure 2) is the definition of 113 the Expanded Flags Option (EFO) for NDP Router Advertisement 114 messages. 116 0 1 2 3 117 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Type | Length | Bit fields available .. 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 ... for assignment | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 Figure 2: Router Advertisement Expanded Flags Option 126 o Type - TBD (to be assigned by IANA) 128 o Length - The length MUST be checked when processing the option in 129 order to allow for future expansion of this option. An 130 implementation of this specification MUST set the Length to 1, 131 MUST ignore any unrecognized data, and MUST be able to recognize 132 the specific length in order to skip over unrecognized bits. 134 o Bits - allocated by IANA 136 The definition and usage of these bits is to be found in the document 137 requesting their allocation. 139 During the construction/transmission, this option: 141 o MUST only occur in Router Advertisement messages 143 o MUST occur prior to any additional options associated with any 144 flags set in this option 146 o MUST only occur once in the Router Advertisement message 148 o MUST NOT be added to a Router Advertisement message if no flags in 149 the option are set 151 o MUST set all unused flags to zero. 153 Upon reception, a receiver processing NDP messages containing this 154 option: 156 o MUST ignore the option if it occurs in a message other than a 157 Router Advertisement 159 o MUST ignore all instances of the option except the first one 160 encountered in the Router Advertisement message 162 o MUST ignore the option if the Length is less than 1 164 o MUST ignore any unknown flag bits. 166 The bit fields within the option are numbered from left to right from 167 8 to 55 (starting as bit offset 16 in the option) and follow the 168 numbering of the flag bits in the RA option described in Figure 1. 169 Flag bits 0 to 7 are found in the Router Advertisement message header 170 defined in [1] 172 5. IANA Considerations 174 The IANA is requested to define a new IPv6 Neighbor Discovery option 175 for the option defined in this document of the form: 177 +------+---------------------------+-----------+ 178 | Type | Description | Reference | 179 +------+---------------------------+-----------+ 180 | TBA | RA Flags Extension Option | [RFCXXXX] | 181 +------+---------------------------+-----------+ 183 The registry for these options can be found at: 184 http://www.iana.org/assignments/icmpv6-parameters 186 The IANA is requested to create a new registry for IPv6 ND Router 187 Advertisement flags. This should include the current flags in the RA 188 option and in the extension option defined in this document. It is 189 suggested the new registry be added to the icmpv6-parameters as shown 190 above. The format for the registry is: 192 +---------------+---------------------------------------+-----------+ 193 | RA Option Bit | Description | Reference | 194 +---------------+---------------------------------------+-----------+ 195 | 0 | M - Managed Address Configuration | [1] | 196 | | Flag | | 197 | 1 | O - Other Configuration Flag | [1] | 198 | 2 | H - Mobile IPv6 Home Agent Flag | [4] | 199 | 3 | Prf - Router Selection Preferences | [5] | 200 | 4 | Prf - Router Selection Preferences | [5] | 201 | 5 | P - Neighbor Discovery Proxy Flag | [6] | 202 | 6-53 | R - Reserved; Available for | | 203 | | assignment | | 204 | 54-55 | Private Experimentation | | 205 +---------------+---------------------------------------+-----------+ 207 The assignment of new RA flags in the RA option header and for the 208 bits defined in the RA extension option defined in this document 209 require standards action or IESG approval[3]. 211 6. Security Considerations 213 This protocol shares the security issues of NDP that are documented 214 in the "Security Considerations" section of [1]. 216 The inclusion of additional optional bit fields provides a potential 217 covert channel useful for passing information. 219 7. References 221 7.1. Normative References 223 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 224 for IP Version 6 (IPv6)", RFC 2461, December 1998. 226 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 227 Levels", BCP 14, RFC 2119, March 1997. 229 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 230 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 232 7.2. Informative References 234 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 235 IPv6", RFC 3775, June 2004. 237 [5] Draves, R. and D. Thaler, "Default Router Preferences and More- 238 Specific Routes", RFC 4191, November 2005. 240 [6] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 241 Proxies (ND Proxy)", RFC 4389, April 2006. 243 Authors' Addresses 245 Brian Haberman (editor) 246 Johns Hopkins University Applied Physics Lab 247 11100 Johns Hopkins Road 248 Laurel, MD 20723-6099 249 USA 251 Phone: +1 443 778 1319 252 Email: brian@innovationslab.net 254 Robert Hinden 255 Nokia 256 313 Fairchild Drive 257 Mountain View, CA 94043 258 USA 260 Phone: +1 650 625 2004 261 Email: bob.hinden@nokia.com 263 Full Copyright Statement 265 Copyright (C) The IETF Trust (2007). 267 This document is subject to the rights, licenses and restrictions 268 contained in BCP 78, and except as set forth therein, the authors 269 retain all their rights. 271 This document and the information contained herein are provided on an 272 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 273 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 274 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 275 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 276 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 277 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 279 Intellectual Property 281 The IETF takes no position regarding the validity or scope of any 282 Intellectual Property Rights or other rights that might be claimed to 283 pertain to the implementation or use of the technology described in 284 this document or the extent to which any license under such rights 285 might or might not be available; nor does it represent that it has 286 made any independent effort to identify any such rights. Information 287 on the procedures with respect to rights in RFC documents can be 288 found in BCP 78 and BCP 79. 290 Copies of IPR disclosures made to the IETF Secretariat and any 291 assurances of licenses to be made available, or the result of an 292 attempt made to obtain a general license or permission for the use of 293 such proprietary rights by implementers or users of this 294 specification can be obtained from the IETF on-line IPR repository at 295 http://www.ietf.org/ipr. 297 The IETF invites any interested party to bring to its attention any 298 copyrights, patents or patent applications, or other proprietary 299 rights that may cover technology that may be required to implement 300 this standard. Please address the information to the IETF at 301 ietf-ipr@ietf.org. 303 Acknowledgment 305 Funding for the RFC Editor function is provided by the IETF 306 Administrative Support Activity (IASA).