idnits 2.17.1 draft-kompella-ospf-iana-00.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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 392. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 398), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. -- The draft header indicates that this document updates RFC2328, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2328, updated by this document, for RFC5378 checks: 1997-11-05) -- 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 (July 2004) is 7218 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2370 (ref. 'OPAQ') (Obsoleted by RFC 5250) ** Obsolete normative reference: RFC 2740 (ref. 'OSPFv3') (Obsoleted by RFC 5340) Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Kompella 2 Internet Draft Juniper Networks 3 Proposed Category: Best Current Practice July 2004 4 Updates: 2328 2370 5 Expires: January 2005 7 IANA Considerations for OSPF 8 draft-kompella-ospf-iana-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than a "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This memo creates a number of OSPF registries and provides guidance 40 to IANA for assignment of code points within these registries. 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 48 1. Introduction 50 This memo defines various OSPF registries for IANA to set up and 51 maintain for OSPF code points. In some cases, this memo defines 52 ranges of code point values within these registries; each such range 53 has a different assignment policy. 55 The terms used in describing the assignment policies are as follows: 56 - Standards Action 57 - Experimentation 58 - Vendor Private Use 59 - Reserved 61 Standards Action means that assignment in that range MUST only be 62 made for Standards Track RFCs (as defined in [IANA]). 64 A range of values may be reserved for Experimentation as set out in 65 [EXPT]. Values from this range MUST NOT be assigned by IANA. 66 Further guidance on the use of the Experimentation range may be found 67 in paragraphs 4, 5 and 6 of [EXPT]. An implementation MAY choose to 68 not support values from the Experimentation range. In such a case, 69 the protocol data structure with a code point from the 70 Experimentation range is ignored, unless other protocol machinery 71 says how to deal with it. (An example of such protocol machinery is 72 the U bit in OSPFv2 Opaque LSAs.) "Ignored" in this context means 73 that the associated data structure is removed from the received 74 packet before further processing, including flooding. 76 Values set aside as Vendor Private Use MUST NOT be assigned by IANA. 77 A protocol data structure whose code point falls in this range MUST 78 have a disambiguating field identifying the Vendor. This identifier 79 consists of four octets of the Vendor's SMI enterprise code (see 80 [ENT]) in network byte order; the location of this code must be 81 well-defined per data structure. An implementation that encounters a 82 Vendor Private code point SHOULD check whether the enterprise code is 83 one that it recognises; if so, the implementation MAY choose to 84 interpret the code point and data structure. Otherwise, it SHOULD 85 ignore the code point, unless protocol machinery says how to deal 86 with the data structure (as defined in the previous paragraph). This 87 allows multiple vendor private extensions to co-exist in a network. 89 Values in the Reserved range MUST NOT be assigned until a Standards 90 Track or Best Common Practices RFC is published defining the 91 assignment policy for that range. This RFC MUST be the product of 92 the OSPF Working Group; if the OSPF WG is terminated, then it MUST be 93 reviewed by an Expert Reviewer designated by the IESG. 95 2. OSPF Registries 97 This section lists the various registries for OSPF protocol code 98 points. Note that some of these are for OSPF, and some are specific 99 to a particular version of OSPF; also, some registries pre-date this 100 memo. 102 Registries that are specific to one version of OSPF reflect the 103 version number in the registry name (e.g., OSPFv2 Options). A 104 registry whose name does not mention a version number applies to both 105 OSPFv2 and OSPFv3 (e.g., OSPF Packet Type). 107 2.1. OSPFv2 Options 109 (Defined in section A.2 of [OSPFv2], updated in section A.1 of 110 [OPAQ]. See also [NSSA].) 112 Assignment policy: Standards Action. 114 2.2. OSPFv3 Options 116 (Defined in section A.2 of [OSPFv3]) 118 Assignment policy: Standards Action. 120 2.3. OSPF Packet Type 122 (Defined in section A.3.1 of [OSPFv2]) 124 Range Assignment Policy 125 ----- ----------------- 126 0 Not to be assigned 127 1-5 Already assigned 128 5-127 Standards Action 129 128-247 Reserved 130 248-251 Experimentation 131 252-255 Vendor Private Use 133 In an OSPF packet with Packet Type in the Vendor Private Use range, 134 the first four octets after the 24 octets of packet header MUST be 135 the Vendor enterprise code. 137 2.3.1. OSPF Authentication Type 139 (Defined in section A.3.1 of [OSPFv2]) 141 (Note: this registry is called "OSPF AUTHENTICATION CODES" by IANA.) 143 Range Assignment Policy 144 ----- ----------------- 145 0-2 Already assigned 146 3-247 Standards Action 147 248-65519 Reserved 148 65520-65535 Experimentation 150 It is unclear at this point if it makes sense to have a Vendor 151 Private Use range for this registry. 153 2.4. OSPFv2 Link State (LS) Type 155 (Defined in section A.4.1 of [OSPFv2]) 157 Range Assignment Policy 158 ----- ----------------- 159 0 Not to be assigned 160 1-11 Already assigned 161 12-127 Standards Action 162 128-247 Reserved 163 248-251 Experimentation 164 252-255 Vendor Private Use 166 In an OSPFv2 LSA with LS Type in the Experimentation or Vendor 167 Private Use ranges, the first four octets following the 20 octets of 168 LSA header MUST be formatted as follows: 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 |U|S|T| Reserved | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 where U, S and T are defined as follows (see also [OSPFv3]): 178 U-bit LSA Handling 179 ------------------------------------------------------------- 180 0 Treat the LSA as if it had link-local flooding scope 181 1 Store and flood the LSA, as if type understood 183 The S and T bits indicate the flooding scope of the LSA. The values 184 are: 186 S T Flooding Scope 187 --------------------------------------------------------------------- 188 0 0 Link-Local Scoping. Flooded only on link it is originated on. 189 0 1 Area Scoping. Flooded to all routers in the originating area 190 1 0 AS Scoping. Flooded to all routers in the AS 191 1 1 Reserved 193 In an OSPFv2 LSA with LS Type in the Vendor Private Use range, the 194 second four octets following the 20 octets of LSA header MUST be the 195 Vendor enterprise code. 197 If a new LS Type is documented, the documentation SHOULD say how the 198 Link State ID is to be filled in, as well as the flooding scope of 199 the LSA. 201 2.4.1. OSPFv2 Router LSA Link Type 203 (Defined in section A.4.2 of [OSPFv2]) 205 Range Assignment Policy 206 ----- ----------------- 207 0 Not to be assigned 208 1-4 Already assigned 209 5-127 Standards Action 210 128-247 Reserved 211 248-255 Experimentation 213 There is no range for Vendor Private Use, as there is no space for an 214 enterprise code to identify the Vendor. 216 If a new Router LSA Link Type is documented, the documentation SHOULD 217 say how the Link State ID, Link ID and Link Data fields are to be 218 filled in. 220 2.4.2. OSPFv2 Router Properties 222 (Defined in section A.4.2 of [OSPFv2], updated in [NSSA]) 224 This field in the Router LSA is unnamed; it is the field immediately 225 following the Router LSA length. 227 Assignment policy: Standards Action. 229 2.5. OSPFv3 LSA Function Code 231 (Defined in section A.4.2.1 of [OSPFv3]) 233 Range Assignment Policy 234 ----- ----------------- 235 0 Not to be assigned 236 1-9 Already assigned 237 10-247 Standards Action 238 248-8175 Reserved 239 8176-8183 Experimentation 240 8184-8191 Vendor Private Use 242 In an OSPFv3 LSA with LSA Function Code in the Vendor Private Use 243 range, the first four octets following the 20 octets of LSA header 244 MUST be the Vendor enterprise code. 246 If a new LSA Function Code is documented, the documentation MUST 247 include the valid combinations of the U, S2 and S1 bits for the LSA. 248 It SHOULD also say how the Link State ID is to be filled in. 250 2.5.1. OSPFv3 Prefix Options 252 (Defined in section A.4.1.1 of [OSPFv3]) 254 Assignment policy: Standards Action. 256 2.5.2. OSPFv3 Router LSA Link Type 258 (Defined in section A.4.3 of [OSPFv3]) 260 Range Assignment Policy 261 ----- ----------------- 262 0 Not to be assigned 263 1-4 Already assigned 264 5-127 Standards Action 265 128-247 Reserved 266 248-255 Experimentation 268 There is no range for Vendor Private Use, as there is no space for an 269 enterprise code to identify the Vendor. 271 2.6. OSPFv2 Opaque LSA Type 273 (Defined in section A.2 of [OPAQ]) 275 (Note: this registry is called "OSPF Opaque LSA Option" by IANA.) 277 Range Assignment Policy 278 ----- ----------------- 279 0 Not to be assigned 280 1-3 Already assigned 281 4-127 Standards Action 282 128-247 Reserved 283 248-251 Experimentation 284 252-255 Vendor Private Use 286 In an OSPFv2 Opaque LSA with Opaque LSA Type in the Vendor Private 287 Use range, the first four octets of Opaque Information MUST be the 288 Vendor enterprise code. 290 A document defining a new Standards Track Opaque LSA with TLVs and 291 sub-TLVs MUST describe ranges and assignment policies for these TLVs. 293 2.6.1. OSPFv2 Grace LSA Top Level TLVs 295 (Defined in Section A of [OSPF-GR].) 297 Range Assignment Policy 298 ----- ----------------- 299 0 Not to be assigned 300 1-3 Already assigned 301 4-247 Standards Action 302 248-65519 Reserved 303 65520-65527 Experimentation 304 65528-65535 Vendor Private Use 306 In a Grace LSA, if a top-level TLV has a Type from the Vendor Private 307 Use range, the Length MUST be at least four, and the first four 308 octets of the Value field MUST be the Vendor enterprise code. 310 3. Acknowledgments 312 Many thanks to Adrian Farrel for his review and comments. 314 4. Security Considerations 316 The lack of adequate IANA guidelines may be viewed as an avenue for 317 Denial of Service attacks on IETF protocols (in this case, OSPFv2 and 318 OSPFv3), and on the IETF Standards Process in general. This memo 319 attempts to close this loophole for OSPFv2 and OSPFv3. 321 Authors contemplating extensions to OSPF SHOULD examine such 322 extensions carefully, and consider whether new registries are needed, 323 and if so, allocation policies within each registry. 325 5. IANA Considerations 327 Done, at last. 329 6. Normative References 331 [EXPT] Narten, T., "Assigning Experimental and Testing Numbers 332 Considered Useful", BCP 82, RFC 3692, January 2004 334 [IANA] Narten, T., and Alvestrand, H., "Guidelines for Writing an 335 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 336 October 1998 338 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997 341 [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 342 RFC 3101, January 2003 344 [OPAQ] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 345 1998 347 [OSPF-GR] Moy, J. et al, "Graceful OSPF Restart", RFC 3623, November 348 2003 350 [OSPFv2] Moy, J. (Editor), "OSPF Version 2", STD 54, RFC 2328, 351 April 1998 353 [OSPFv3] Coltun, R., Ferguson, D., and Moy, J. "OSPF for IPv6", RFC 354 2740, December 1999 356 7. Informative References 358 [ENT] IANA PRIVATE ENTERPRISE NUMBERS, 359 http://www.iana.org/assignments/enterprise-numbers 361 Author's Addresses 363 Kireeti Kompella 364 Juniper Networks 365 1194 N. Mathilda Ave 366 Sunnyvale, CA 94089 367 USA 368 Email: kireeti@juniper.net 370 Intellectual Property Statement 372 The IETF takes no position regarding the validity or scope of any 373 Intellectual Property Rights or other rights that might be claimed to 374 pertain to the implementation or use of the technology described in 375 this document or the extent to which any license under such rights 376 might or might not be available; nor does it represent that it has 377 made any independent effort to identify any such rights. Information 378 on the IETF's procedures with respect to rights in IETF Documents can 379 be found in BCP 78 and BCP 79. 381 Copies of IPR disclosures made to the IETF Secretariat and any 382 assurances of licenses to be made available, or the result of an 383 attempt made to obtain a general license or permission for the use of 384 such proprietary rights by implementers or users of this 385 specification can be obtained from the IETF on-line IPR repository at 386 http://www.ietf.org/ipr. 388 The IETF invites any interested party to bring to its attention any 389 copyrights, patents or patent applications, or other proprietary 390 rights that may cover technology that may be required to implement 391 this standard. Please address the information to the IETF at ietf- 392 ipr@ietf.org. 394 Full Copyright Statement 396 Copyright (C) The Internet Society (2004). This document is subject 397 to the rights, licenses and restrictions contained in BCP 78, and 398 except as set forth therein, the authors retain all their rights. 400 Disclaimer 402 This document and the information contained herein are provided on an 403 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 404 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 405 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 406 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 407 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 408 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 410 Acknowledgement: 412 Funding for the RFC Editor function is currently provided by the 413 Internet Society.