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)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html 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