IANA Considerations for OSPF
RFC 4940
Document | Type |
RFC - Best Current Practice
(July 2007; Errata)
Also known as BCP 130
Was draft-ietf-ospf-iana (ospf WG)
|
|
---|---|---|---|
Authors | Bill Fenner , Kireeti Kompella | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4940 (Best Current Practice) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Bill Fenner | ||
Send notices to | (None) |
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 (C) 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] 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] 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 [RFC2434]). Some of the registries defined below reserve a range of values for Experimentation. For guidelines regarding the use of such values see [RFC3692]. 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 [RFC3692]. 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.Show full document text