The RFC Archive
 The RFC Archive   RFC 4940   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 4940

IANA Considerations for OSPF

Last modified on Saturday, June 30th, 2007

Permanent link to RFC 4940
Search GitHub Wiki for RFC 4940
Show other RFCs mentioning RFC 4940







Network Working Group                                        K. Kompella
Request for Comments: 4940                              Juniper Networks
BCP: 130                                                       B. Fenner
Category: Best Current Practice                    AT&T Labs--Research
                                                               June 2007


                      IANA Considerations for OSPF

 Status of This Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

 Copyright Notice

   Copyright © The IETF Trust (2007).

 Abstract

   This memo creates a number of OSPF registries and provides guidance
   to IANA for assignment of code points within these registries.




























Kompella & Fenner        Best Current Practice               PAGE 1 top


RFC 4940 IANA Considerations for OSPF June 2007 Table of Contents 1. Introduction ....................................................3 1.1. Conventions Used in This Document ..........................4 2. OSPF Registries .................................................4 2.1. OSPFv2 Options .............................................4 2.2. OSPFv3 Options .............................................4 2.3. OSPF Packet Type (Both v2 and v3) ..........................4 2.3.1. OSPF Authentication Type ............................5 2.4. OSPFv2 Link State (LS) Type ................................5 2.4.1. OSPFv2 Router LSA Link Type .........................5 2.4.2. OSPFv2 Router Properties ............................6 2.5. OSPFv3 LSA Function Code ...................................6 2.5.1. OSPFv3 Prefix Options ...............................6 2.5.2. OSPFv3 Router LSA Link Type .........................6 2.6. OSPFv2 Opaque LSA Type .....................................7 2.6.1. OSPFv2 Grace LSA Top Level TLVs .....................7 3. Acknowledgments .................................................8 4. Security Considerations .........................................8 5. IANA Considerations .............................................8 5.1. OSPFv2 Options Registry ....................................8 5.2. OSPFv3 Options Registry ....................................8 5.3. OSPF Packet Type Registry ..................................9 5.4. OSPF Authentication Type Registry ..........................9 5.5. OSPFv2 Link State Type Registry ............................9 5.6. OSPFv2 Router LSA Link Type Registry ......................10 5.7. OSPFv2 Router Properties Registry .........................10 5.8. OSPFv3 LSA Function Code Registry .........................11 5.9. OSPFv3 Prefix Options Registry ............................12 5.10. OSPFv3 Router LSA Link Type Registry .....................12 5.11. OSPFv2 Opaque LSA Type Registry ..........................13 5.12. OSPFv2 Grace LSA Top Level TLV Registry ..................13 6. References .....................................................13 6.1. Normative References ......................................13 6.2. Informative References ....................................14 Kompella & Fenner Best Current Practice PAGE 2 top

RFC 4940 IANA Considerations for OSPF June 2007 1. Introduction This memo defines various OSPF registries for IANA to set up and maintain for OSPF code points. In some cases, this memo defines ranges of code point values within these registries; each such range has a different assignment policy. The terms used in describing the assignment policies are as follows: o Standards Action o Experimentation o Vendor Private Use o Reserved Standards Action means that assignments in that range MUST only be made for Standards Track RFCs (as defined in [RFC 2434]). Some of the registries defined below reserve a range of values for Experimentation. For guidelines regarding the use of such values see [RFC 3692]. Values from this range MUST NOT be assigned by IANA. Further guidance on the use of the Experimentation range may be found in paragraphs 4, 5, and 6 of [RFC 3692]. An implementation MAY choose to not support values from the Experimentation range. In such a case, the protocol data structure with a code point from the Experimentation range is ignored, unless other protocol machinery says how to deal with it. "Ignored" in this context means that the associated data structure is removed from the received packet before further processing, including flooding. Values set aside as Vendor Private Use MUST NOT be assigned by IANA. A protocol data structure whose code point falls in this range MUST have a disambiguating field identifying the Vendor. This identifier consists of four octets of the Vendor's SMI (Structure of Management Information) enterprise code (see [ENTERPRISE-NUMBERS]) in network byte order; the location of this code must be well-defined per data structure. An implementation that encounters a Vendor Private code point SHOULD check whether the enterprise code is one that it recognizes; if so, the implementation MAY choose to interpret the code point and data structure. Otherwise, it SHOULD ignore the code point, unless the protocol machinery says how to deal with the data structure (as defined in the previous paragraph). This allows multiple vendor private extensions to coexist in a network. Values in the Reserved range MUST NOT be assigned until a Standards Track or Best Common Practices RFC is published defining the Kompella & Fenner Best Current Practice PAGE 3 top

RFC 4940 IANA Considerations for OSPF June 2007 assignment policy for that range. This RFC MUST be the product of the OSPF Working Group; if the OSPF WG is terminated, then it MUST be reviewed by an Expert Reviewer designated by the IESG. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. 2. OSPF Registries This section lists the various registries for OSPF protocol code points. Note that some of these are for OSPF, and some are specific to a particular version of OSPF; also, some registries predate this memo. Registries that are specific to one version of OSPF reflect the version number in the registry name (e.g., OSPFv2 Options). A registry whose name does not mention a version number applies to both OSPFv2 and OSPFv3 (e.g., OSPF Packet Type). 2.1. OSPFv2 Options (Defined in Section A.2 of [RFC 2328], updated in Section A.1 of [RFC 2370]. See also [RFC 3101].) Assignment policy: Standards Action. 2.2. OSPFv3 Options (Defined in Section A.2 of [RFC 2740]) Assignment policy: Standards Action. 2.3. OSPF Packet Type (Both v2 and v3) (Defined in Section A.3.1 of [RFC 2328]) +---------+--------------------+ | Range | Assignment Policy | +---------+--------------------+ | 0 | Not to be assigned | | 1-5 | Already assigned | | 6-127 | Standards Action | | 128-255 | Reserved | +---------+--------------------+ Kompella & Fenner Best Current Practice PAGE 4 top

RFC 4940 IANA Considerations for OSPF June 2007 2.3.1. OSPF Authentication Type (Defined in Section A.3.1 of [RFC 2328]) (Note: this registry is called "OSPF AUTHENTICATION CODES" by IANA.) +-------------+-------------------+ | Range | Assignment Policy | +-------------+-------------------+ | 0-2 | Already assigned | | 3-247 | Standards Action | | 248-65519 | Reserved | | 65520-65535 | Experimentation | +-------------+-------------------+ 2.4. OSPFv2 Link State (LS) Type (Defined in Section A.4.1 of [RFC 2328]) +---------+--------------------+ | Range | Assignment Policy | +---------+--------------------+ | 0 | Not to be assigned | | 1-11 | Already assigned | | 12-127 | Standards Action | | 128-255 | Reserved | +---------+--------------------+ If a new LS Type is documented, the documentation MUST say how the Link State ID is to be filled in, what the flooding scope of the LSA (Link State Advertisement) is, and how backward compatibility is maintained. 2.4.1. OSPFv2 Router LSA Link Type (Defined in Section A.4.2 of [RFC 2328]) +---------+--------------------+ | Range | Assignment Policy | +---------+--------------------+ | 0 | Not to be assigned | | 1-4 | Already assigned | | 5-127 | Standards Action | | 128-255 | Reserved | +---------+--------------------+ There is no range for Vendor Private Use, as there is no space for an enterprise code to identify the Vendor. Kompella & Fenner Best Current Practice PAGE 5 top

RFC 4940 IANA Considerations for OSPF June 2007 No Experimental range is defined, due to possible backwards compatibility issues. If a new Router LSA Link Type is documented, the documentation SHOULD say how the Link State ID, Link ID, and Link Data fields are to be filled in, and how backward compatibility is maintained. 2.4.2. OSPFv2 Router Properties (Defined in Section A.4.2 of [RFC 2328], updated in [RFC 3101]) This 8-bit field in the Router LSA is unnamed; it is the field immediately following the Router LSA length. Assignment policy: Standards Action. 2.5. OSPFv3 LSA Function Code This registry is created by [OSPF-CAP]. This document provides the values to be populated for values defined in Section A.4.2.1 of [RFC 2740]. 2.5.1. OSPFv3 Prefix Options (Defined in Section A.4.1.1 of [RFC 2740]) Assignment policy: Standards Action. 2.5.2. OSPFv3 Router LSA Link Type (Defined in Section A.4.3 of [RFC 2740]) +---------+--------------------+ | Range | Assignment Policy | +---------+--------------------+ | 0 | Not to be assigned | | 1-4 | Already assigned | | 5-127 | Standards Action | | 128-255 | Reserved | +---------+--------------------+ There is no range for Vendor Private Use, as there is no space for an enterprise code to identify the Vendor. No Experimental range is defined, due to possible backwards compatibility issues. Kompella & Fenner Best Current Practice PAGE 6 top

RFC 4940 IANA Considerations for OSPF June 2007 2.6. OSPFv2 Opaque LSA Type (Defined in Section A.2 of [RFC 2370]) (Note: this registry is called "OSPF Opaque LSA Option" by IANA. See also [RFC 3630].) +---------+--------------------+ | Range | Assignment Policy | +---------+--------------------+ | 0 | Not to be assigned | | 1-3 | Already assigned | | 4-127 | Standards Action | | 128-247 | Reserved | | 248-251 | Experimentation | | 252-255 | Vendor Private Use | +---------+--------------------+ In an OSPFv2 Opaque LSA with Opaque LSA Type in the Vendor Private Use range, the first four octets of Opaque Information MUST be the Vendor enterprise code. A document defining a new Standards Track Opaque LSA with TLVs and sub-TLVs MUST describe ranges and assignment policies for these TLVs. 2.6.1. OSPFv2 Grace LSA Top Level TLVs (Defined in Appendix A of [RFC 3623]) +-------------+--------------------+ | Range | Assignment Policy | +-------------+--------------------+ | 0 | Not to be assigned | | 1-3 | Already assigned | | 4-255 | Standards Action | | 256-65519 | Reserved | | 65520-65527 | Experimentation | | 65528-65535 | Vendor Private Use | +-------------+--------------------+ In a Grace LSA, if a top-level TLV has a Type from the Vendor Private Use range, the Length MUST be at least four, and the first four octets of the Value field MUST be the Vendor enterprise code. Kompella & Fenner Best Current Practice PAGE 7 top

RFC 4940 IANA Considerations for OSPF June 2007 3. Acknowledgments Many thanks to Adrian Farrel and Acee Lindem for their review and comments. 4. Security Considerations The lack of adequate IANA guidelines may be viewed as an avenue for Denial of Service attacks on IETF protocols (in this case, OSPFv2 and OSPFv3), and on the IETF Standards Process in general. This memo attempts to close this loophole for OSPFv2 and OSPFv3. Authors contemplating extensions to OSPF SHOULD examine such extensions carefully, and consider whether new registries are needed, and if so, allocation policies within each registry. 5. IANA Considerations This document specifies assignment policy for several existing IANA registries and creates several more. 5.1. OSPFv2 Options Registry Section 2.1 defines the policy for allocation of bits from this registry as "Standards Action". There are only 8 bits in this field, and 6 are already assigned. The initial registry contents are given below. OSPFv2 Options Registry (Section 2.1) Value Description Reference ----- ----------- --------- 0x02 E-bit [RFC 2328] 0x04 MC-bit [RFC 1584] 0x08 N/P-bit [RFC 3101] 0x10 Reserved 0x20 DC-bit [RFC 1793] 0x40 O-bit [RFC 2370] 5.2. OSPFv3 Options Registry Section 2.2 defines the policy for allocation of bits from this registry as "Standards Action". There are 24 bits in this field, and 6 are assigned. The initial registry contents are given below. Kompella & Fenner Best Current Practice PAGE 8 top

RFC 4940 IANA Considerations for OSPF June 2007 OSPFv3 Options Registry (Section 2.2) Value Description Reference -------- ----------- --------- 0x000001 V6-bit [RFC 2740] 0x000002 E-bit [RFC 2328] 0x000004 MC-bit [RFC 1584] 0x000008 N-bit [RFC 3101] 0x000010 R-Bit [RFC 2740] 0x000020 DC-bit [RFC 1793] 5.3. OSPF Packet Type Registry Section 2.3 defines the policy for allocation of values from this registry for different ranges. The initial registry contents are given below. OSPF Packet Type (Section 2.3) Value Description Reference ----- -------------------- --------- 1 Hello [RFC 2328] 2 Database Description [RFC 2328] 3 Link State Request [RFC 2328] 4 Link State Update [RFC 2328] 5 Link State Ack [RFC 2328] 5.4. OSPF Authentication Type Registry This registry already exists at IANA, called "ospf-authentication- codes". Section 2.3.1 defines the policy for allocation from this registry for different ranges. 5.5. OSPFv2 Link State Type Registry Section 2.4 defines the policy for allocations from this registry for different ranges. The initial registry contents are given below. Kompella & Fenner Best Current Practice PAGE 9 top

RFC 4940 IANA Considerations for OSPF June 2007 OSPFv2 Link State (LS) Type (Section 2.4) Value Description Reference ----- ------------------------ --------- 1 Router-LSA [RFC 2328] 2 Network-LSA [RFC 2328] 3 Summary-LSA (IP network) [RFC 2328] 4 Summary-LSA (ASBR) [RFC 2328] 5 AS-external-LSA [RFC 2328] 6 Group-membership-LSA [RFC 1584] 7 NSSA AS-external LSA [RFC 3101] 8 Reserved 9 Link-local Opaque LSA [RFC 2370] 10 Area-local Opaque LSA [RFC 2370] 11 Opaque LSA [RFC 2370] 5.6. OSPFv2 Router LSA Link Type Registry Section 2.4.1 defines the policy for allocations from this registry for different ranges. The initial registry contents are given below. OSPFv2 Router LSA Link Type (Section 2.4.1) Value Description Reference ----- ------------------------------------------- --------- 1 Point-to-Point connection to another router [RFC 2328] 2 Transit Network [RFC 2328] 3 Stub Network [RFC 2328] 4 Virtual Link [RFC 2328] 5.7. OSPFv2 Router Properties Registry Section 2.4.2 defines the policy for allocation of bits from this registry as "Standards Action". There are only 8 bits in this field, and 5 are already assigned. The initial registry contents are given below. OSPFv2 Options Registry (Section 2.1) Value Description Reference ----- ----------- --------- 0x01 B-bit [RFC 2328] 0x02 W-bit [RFC 2328] 0x04 V-bit [RFC 2328] 0x08 W-bit [RFC 1584] 0x10 Nt-bit [RFC 3101] Kompella & Fenner Best Current Practice PAGE 10 top

RFC 4940 IANA Considerations for OSPF June 2007 5.8. OSPFv3 LSA Function Code Registry This registry is created by [OSPF-CAP], which also defines the registration policy. This section contains values that belong in this registry that were defined by [RFC 2740]. As defined in [RFC 2740], the first 3 bits of the LSA Function Code are the U, S1, and S2 bits. A given function code implies a specific setting for the U, S1, and S2 bits as shown in the "LS Type" column. 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |U |S2|S1| LSA Function Code | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The U bit indicates how the LSA should be handled by a router which does not recognize the LSA's function code. Its values are: U-bit LSA Handling ----- ---------------------------------------------------- 0 Treat the LSA as if it had link-local flooding scope 1 Store and flood the LSA, as if type understood The S1 and S2 bits indicate the flooding scope of the LSA. The values are: S1 S2 Flooding Scope -- -- -------------------------------------------------------------- 0 0 Link-Local Scoping. Flooded only on link it is originated on 0 1 Area Scoping. Flooded to all routers in the originating area 1 0 AS Scoping. Flooded to all routers in the AS 1 1 Reserved The initial registry contents are given below. Kompella & Fenner Best Current Practice PAGE 11 top

RFC 4940 IANA Considerations for OSPF June 2007 OSPFv3 LSA Function Code (Section 2.5) LSA Function Code LS Type Description Reference ----------------- ------- --------------------- --------- 1 0x2001 Router-LSA [RFC 2740] 2 0x2002 Network-LSA [RFC 2740] 3 0x2003 Inter-Area-Prefix-LSA [RFC 2740] 4 0x2004 Inter-Area-Router-LSA [RFC 2740] 5 0x4005 AS-External-LSA [RFC 2740] 6 0x2006 Group-membership-LSA [RFC 2740] 7 0x2007 Type-7-LSA [RFC 2740] 8 0x0008 Link-LSA [RFC 2740] 9 0x2009 Intra-Area-Prefix-LSA [RFC 2740] 5.9. OSPFv3 Prefix Options Registry Section 2.5.1 defines the policy for allocation of bits from this registry as "Standards Action". There are only 8 bits in this field, and 4 are already assigned. The initial registry contents are given below. OSPFv3 Prefix Options Registry (Section 2.5.1) Value Description Reference ----- ----------- --------- 0x01 NU-bit [RFC 2740] 0x02 LA-bit [RFC 2740] 0x04 MC-bit [RFC 2740] 0x08 P-bit [RFC 2740] 5.10. OSPFv3 Router LSA Link Type Registry Section 2.5.2 defines the policy for allocations from this registry for different ranges. The initial registry contents are given below. OSPFv3 Router LSA Link Type (Section 2.5.2) Value Description Reference ----- ------------------------------------------- --------- 1 Point-to-Point connection to another router [RFC 2740] 2 Transit Network [RFC 2740] 3 Reserved [RFC 2740] 4 Virtual Link [RFC 2740] Kompella & Fenner Best Current Practice PAGE 12 top

RFC 4940 IANA Considerations for OSPF June 2007 5.11. OSPFv2 Opaque LSA Type Registry This registry already exists at IANA, called "ospf-opaque-types". Section 2.6 defines the policy for allocation from this registry for different ranges. 5.12. OSPFv2 Grace LSA Top Level TLV Registry Section 2.6.1 defines the policy for allocations from this registry for different ranges. The initial registry contents are given below. OSPFv2 Grace LSA Top Level TLV (Section 2.6.1) Value Description Reference ----- ----------------------- --------- 1 Grace Period [RFC 3623] 2 Graceful Restart reason [RFC 3623] 3 IP Interface Address [RFC 3623] 6. References 6.1. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994. [RFC 1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995. [RFC 2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC 2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC 2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [RFC 3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003. Kompella & Fenner Best Current Practice PAGE 13 top

RFC 4940 IANA Considerations for OSPF June 2007 [RFC 3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003. [RFC 3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC 3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. 6.2. Informative References [ENTERPRISE-NUMBERS] "PRIVATE ENTERPRISE NUMBERS", http://www.iana.org/assignments/enterprise-numbers. [OSPF-CAP] Lindem, A., "Extensions to OSPF for Advertising Optional Router Capabilities", Work in Progress, May 2007. Authors' Addresses Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: kireeti@juniper.net Bill Fenner AT&T Labs--Research 1 River Oaks Place San Jose, CA 95134 US Phone: +1 (408) 493-8505 EMail: fenner@research.att.com Kompella & Fenner Best Current Practice PAGE 14 top

RFC 4940 IANA Considerations for OSPF June 2007 Full Copyright Statement Copyright © The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kompella & Fenner Best Current Practice PAGE 15 top

IANA Considerations for OSPF RFC TOTAL SIZE: 27595 bytes PUBLICATION DATE: Saturday, June 30th, 2007 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 4940: The IETF Trust, Saturday, June 30th, 2007
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement