idnits 2.17.1 draft-ietf-ospf-iana-01.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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 432. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 439. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 445. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 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 (June 23, 2005) is 6882 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 2370 (ref. '3') (Obsoleted by RFC 5250) ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2740 (ref. '5') (Obsoleted by RFC 5340) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 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 Expires: December 25, 2005 June 23, 2005 5 IANA Considerations for OSPF 6 draft-ietf-ospf-iana-01 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 25, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). 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 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 1.1 Conventions used in this document . . . . . . . . . . . . 4 46 1.2 Changes from version -00 . . . . . . . . . . . . . . . . . 4 47 2. OSPF Registries . . . . . . . . . . . . . . . . . . . . . . . 5 48 2.1 OSPFv2 Options . . . . . . . . . . . . . . . . . . . . . . 5 49 2.2 OSPFv3 Options . . . . . . . . . . . . . . . . . . . . . . 5 50 2.3 OSPF Packet Type (both v2 and v3) . . . . . . . . . . . . 5 51 2.3.1 OSPF Authentication Type . . . . . . . . . . . . . . . 5 52 2.4 OSPFv2 Link State (LS) Type . . . . . . . . . . . . . . . 6 53 2.4.1 OSPFv2 Router LSA Link Type . . . . . . . . . . . . . 6 54 2.4.2 OSPFv2 Router Properties . . . . . . . . . . . . . . . 7 55 2.5 OSPFv3 LSA Function Code . . . . . . . . . . . . . . . . . 7 56 2.5.1 OSPFv3 Prefix Options . . . . . . . . . . . . . . . . 8 57 2.5.2 OSPFv3 Router LSA Link Type . . . . . . . . . . . . . 8 58 2.6 OSPFv2 Opaque LSA Type . . . . . . . . . . . . . . . . . . 9 59 2.6.1 OSPFv2 Grace LSA Top Level TLVs . . . . . . . . . . . 9 60 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 6.1 Normative References . . . . . . . . . . . . . . . . . . . 14 65 6.2 Informative References . . . . . . . . . . . . . . . . . . 14 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 67 Intellectual Property and Copyright Statements . . . . . . . . 15 69 1. Introduction 71 This memo defines various OSPF registries for IANA to set up and 72 maintain for OSPF code points. In some cases, this memo defines 73 ranges of code point values within these registries; each such range 74 has a different assignment policy. 76 The terms used in describing the assignment policies are as follows: 78 - Standards Action 80 - Experimentation 82 - Vendor Private Use 84 - Reserved 86 Standards Action means that assignment in that range MUST only be 87 made for Standards Track RFCs (as defined in [4]). 89 A range of values MAY be reserved for Experimentation as set out in 90 [9]. Values from this range MUST NOT be assigned by IANA. Further 91 guidance on the use of the Experimentation range may be found in 92 paragraphs 4, 5 and 6 of [9]. An implementation MAY choose to not 93 support values from the Experimentation range. In such a case, the 94 protocol data structure with a code point from the Experimentation 95 range is ignored, unless other protocol machinery says how to deal 96 with it. "Ignored" in this context means that the associated data 97 structure is removed from the received packet before further 98 processing, including flooding. 100 Values set aside as Vendor Private Use MUST NOT be assigned by IANA. 101 A protocol data structure whose code point falls in this range MUST 102 have a disambiguating field identifying the Vendor. This identifier 103 consists of four octets of the Vendor's SMI enterprise code (see 104 [10]) in network byte order; the location of this code must be well- 105 defined per data structure. An implementation that encounters a 106 Vendor Private code point SHOULD check whether the enterprise code is 107 one that it recognises; if so, the implementation MAY choose to 108 interpret the code point and data structure. Otherwise, it SHOULD 109 ignore the code point, unless protocol machinery says how to deal 110 with the data structure (as defined in the previous paragraph). This 111 allows multiple vendor private extensions to co-exist in a network. 113 Values in the Reserved range MUST NOT be assigned until a Standards 114 Track or Best Common Practices RFC is published defining the 115 assignment policy for that range. This RFC MUST be the product of 116 the OSPF Working Group; if the OSPF WG is terminated, then it MUST be 117 reviewed by an Expert Reviewer designated by the IESG. 119 1.1 Conventions used in this document 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [1]. 125 1.2 Changes from version -00 127 [This section to be removed before publication.] 129 Removed misguided reference to non-existent U bit in OSPFv2 Opaque 130 LSAs. 132 Tightened up requirements for defining new OSPFv2 Link State (LS) 133 Type (section 2.4) and OSPFv2 Router LSA Link Type (section 2.4.1). 135 2. OSPF Registries 137 This section lists the various registries for OSPF protocol code 138 points. Note that some of these are for OSPF, and some are specific 139 to a particular version of OSPF; also, some registries pre-date this 140 memo. 142 Registries that are specific to one version of OSPF reflect the 143 version number in the registry name (e.g., OSPFv2 Options). A 144 registry whose name does not mention a version number applies to both 145 OSPFv2 and OSPFv3 (e.g., OSPF Packet Type). 147 2.1 OSPFv2 Options 149 (Defined in section A.2 of [2], updated in section A.1 of [3]. See 150 also [6].) 152 Assignment policy: Standards Action. 154 2.2 OSPFv3 Options 156 (Defined in section A.2 of [5]) 158 Assignment policy: Standards Action. 160 2.3 OSPF Packet Type (both v2 and v3) 162 (Defined in section A.3.1 of [2]) 164 +---------+--------------------+ 165 | Range | Assignment Policy | 166 +---------+--------------------+ 167 | 0 | Not to be assigned | 168 | | | 169 | 1-5 | Already assigned | 170 | | | 171 | 6-127 | Standards Action | 172 | | | 173 | 128-255 | Reserved | 174 +---------+--------------------+ 176 2.3.1 OSPF Authentication Type 178 (Defined in section A.3.1 of [2]) 180 (Note: this registry is called "OSPF AUTHENTICATION CODES" by IANA.) 181 +-------------+-------------------+ 182 | Range | Assignment Policy | 183 +-------------+-------------------+ 184 | 0-2 | Already assigned | 185 | | | 186 | 3-247 | Standards Action | 187 | | | 188 | 248-65519 | Reserved | 189 | | | 190 | 65520-65535 | Experimentation | 191 +-------------+-------------------+ 193 It is unclear at this point if it makes sense to have a Vendor 194 Private Use range for this registry. 196 2.4 OSPFv2 Link State (LS) Type 198 (Defined in section A.4.1 of [2]) 200 +---------+--------------------+ 201 | Range | Assignment Policy | 202 +---------+--------------------+ 203 | 0 | Not to be assigned | 204 | | | 205 | 1-11 | Already assigned | 206 | | | 207 | 12-127 | Standards Action | 208 | | | 209 | 128-255 | Reserved | 210 +---------+--------------------+ 212 If a new LS Type is documented, the documentation MUST say how the 213 Link State ID is to be filled in, what the flooding scope of the LSA 214 is, and how backward compatibility is maintained. 216 2.4.1 OSPFv2 Router LSA Link Type 218 (Defined in section A.4.2 of [2]) 219 +---------+--------------------+ 220 | Range | Assignment Policy | 221 +---------+--------------------+ 222 | 0 | Not to be assigned | 223 | | | 224 | 1-4 | Already assigned | 225 | | | 226 | 5-127 | Standards Action | 227 | | | 228 | 128-255 | Reserved | 229 +---------+--------------------+ 231 There is no range for Vendor Private Use, as there is no space for an 232 enterprise code to identify the Vendor. 234 There is currently no range for Experimental, as it is not clear that 235 such extensions will be backward compatible. 237 If a new Router LSA Link Type is documented, the documentation SHOULD 238 say how the Link State ID, Link ID and Link Data fields are to be 239 filled in, and how backward compatibility is maintained. 241 2.4.2 OSPFv2 Router Properties 243 (Defined in section A.4.2 of [2], updated in [6]) 245 This field in the Router LSA is unnamed; it is the field immediately 246 following the Router LSA length. 248 Assignment policy: Standards Action. 250 2.5 OSPFv3 LSA Function Code 252 (Defined in section A.4.2.1 of [5]) 253 +-----------+--------------------+ 254 | Range | Assignment Policy | 255 +-----------+--------------------+ 256 | 0 | Not to be assigned | 257 | | | 258 | 1-9 | Already assigned | 259 | | | 260 | 10-255 | Standards Action | 261 | | | 262 | 256-8175 | Reserved | 263 | | | 264 | 8176-8183 | Experimentation | 265 | | | 266 | 8184-8191 | Vendor Private Use | 267 +-----------+--------------------+ 269 In an OSPFv3 LSA with LSA Function Code in the Vendor Private Use 270 range, the first four octets following the 20 octets of LSA header 271 MUST be the Vendor enterprise code. 273 If a new LSA Function Code is documented, the documentation MUST 274 include the valid combinations of the U, S2 and S1 bits for the LSA. 275 It SHOULD also say how the Link State ID is to be filled in. 277 2.5.1 OSPFv3 Prefix Options 279 (Defined in section A.4.1.1 of [5]) 281 Assignment policy: Standards Action. 283 2.5.2 OSPFv3 Router LSA Link Type 285 (Defined in section A.4.3 of [5]) 287 +---------+--------------------+ 288 | Range | Assignment Policy | 289 +---------+--------------------+ 290 | 0 | Not to be assigned | 291 | | | 292 | 1-4 | Already assigned | 293 | | | 294 | 5-127 | Standards Action | 295 | | | 296 | 128-255 | Reserved | 297 +---------+--------------------+ 299 There is no range for Vendor Private Use, as there is no space for an 300 enterprise code to identify the Vendor. 302 There is currently no range for Experimental, as it is not clear that 303 such extensions will be backward compatible. 305 2.6 OSPFv2 Opaque LSA Type 307 (Defined in section A.2 of [3]) 309 (Note: this registry is called "OSPF Opaque LSA Option" by IANA. See 310 also [8].) 312 +---------+--------------------+ 313 | Range | Assignment Policy | 314 +---------+--------------------+ 315 | 0 | Not to be assigned | 316 | | | 317 | 1-3 | Already assigned | 318 | | | 319 | 4-127 | Standards Action | 320 | | | 321 | 128-247 | Reserved | 322 | | | 323 | 248-251 | Experimentation | 324 | | | 325 | 252-255 | Vendor Private Use | 326 +---------+--------------------+ 328 In an OSPFv2 Opaque LSA with Opaque LSA Type in the Vendor Private 329 Use range, the first four octets of Opaque Information MUST be the 330 Vendor enterprise code. 332 A document defining a new Standards Track Opaque LSA with TLVs and 333 sub-TLVs MUST describe ranges and assignment policies for these TLVs. 335 2.6.1 OSPFv2 Grace LSA Top Level TLVs 337 (Defined in Section A of [7]) 338 +-------------+--------------------+ 339 | Range | Assignment Policy | 340 +-------------+--------------------+ 341 | 0 | Not to be assigned | 342 | | | 343 | 1-3 | Already assigned | 344 | | | 345 | 4-255 | Standards Action | 346 | | | 347 | 256-65519 | Reserved | 348 | | | 349 | 65520-65527 | Experimentation | 350 | | | 351 | 65528-65535 | Vendor Private Use | 352 +-------------+--------------------+ 354 In a Grace LSA, if a top-level TLV has a Type from the Vendor Private 355 Use range, the Length MUST be at least four, and the first four 356 octets of the Value field MUST be the Vendor enterprise code. 358 3. Acknowledgments 360 Many thanks to Adrian Farrel and Acee Lindem for their review and 361 comments. 363 4. Security Considerations 365 The lack of adequate IANA guidelines may be viewed as an avenue for 366 Denial of Service attacks on IETF protocols (in this case, OSPFv2 and 367 OSPFv3), and on the IETF Standards Process in general. This memo 368 attempts to close this loophole for OSPFv2 and OSPFv3. 370 Authors contemplating extensions to OSPF SHOULD examine such 371 extensions carefully, and consider whether new registries are needed, 372 and if so, allocation policies within each registry. 374 5. IANA Considerations 376 Done, at last. 378 6. References 380 6.1 Normative References 382 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 383 Levels", BCP 14, RFC 2119, March 1997. 385 [2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 387 [3] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. 389 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 390 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 392 [5] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, 393 December 1999. 395 [6] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 396 RFC 3101, January 2003. 398 [7] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF 399 Restart", RFC 3623, November 2003. 401 [8] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) 402 Extensions to OSPF Version 2", RFC 3630, September 2003. 404 [9] Narten, T., "Assigning Experimental and Testing Numbers 405 Considered Useful", BCP 82, RFC 3692, January 2004. 407 6.2 Informative References 409 [10] "PRIVATE ENTERPRISE NUMBERS". 411 http://www.iana.org/assignments/enterprise-numbers 413 Author's Address 415 Kireeti Kompella 416 Juniper Networks 417 1194 N. Mathilda Ave. 418 Sunnyvale, CA 94089 419 US 421 Email: kireeti@juniper.net 423 Intellectual Property Statement 425 The IETF takes no position regarding the validity or scope of any 426 Intellectual Property Rights or other rights that might be claimed to 427 pertain to the implementation or use of the technology described in 428 this document or the extent to which any license under such rights 429 might or might not be available; nor does it represent that it has 430 made any independent effort to identify any such rights. Information 431 on the procedures with respect to rights in RFC documents can be 432 found in BCP 78 and BCP 79. 434 Copies of IPR disclosures made to the IETF Secretariat and any 435 assurances of licenses to be made available, or the result of an 436 attempt made to obtain a general license or permission for the use of 437 such proprietary rights by implementers or users of this 438 specification can be obtained from the IETF on-line IPR repository at 439 http://www.ietf.org/ipr. 441 The IETF invites any interested party to bring to its attention any 442 copyrights, patents or patent applications, or other proprietary 443 rights that may cover technology that may be required to implement 444 this standard. Please address the information to the IETF at 445 ietf-ipr@ietf.org. 447 Disclaimer of Validity 449 This document and the information contained herein are provided on an 450 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 451 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 452 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 453 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 454 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 455 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 457 Copyright Statement 459 Copyright (C) The Internet Society (2005). This document is subject 460 to the rights, licenses and restrictions contained in BCP 78, and 461 except as set forth therein, the authors retain all their rights. 463 Acknowledgment 465 Funding for the RFC Editor function is currently provided by the 466 Internet Society.