IANA Considerations for OSPF
RFC 4940

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

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.