GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4940

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.
 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] 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 [RFC2119].

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 [RFC2328], updated in Section A.1 of
 [RFC2370].  See also [RFC3101].)
 Assignment policy: Standards Action.

2.2. OSPFv3 Options

 (Defined in Section A.2 of [RFC2740])
 Assignment policy: Standards Action.

2.3. OSPF Packet Type (Both v2 and v3)

 (Defined in Section A.3.1 of [RFC2328])
                   +---------+--------------------+
                   | 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] RFC 4940 IANA Considerations for OSPF June 2007

2.3.1. OSPF Authentication Type

 (Defined in Section A.3.1 of [RFC2328])
 (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 [RFC2328])
                   +---------+--------------------+
                   | 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 [RFC2328])
                   +---------+--------------------+
                   | 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] 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 [RFC2328], updated in [RFC3101])
 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
 [RFC2740].

2.5.1. OSPFv3 Prefix Options

 (Defined in Section A.4.1.1 of [RFC2740])
 Assignment policy: Standards Action.

2.5.2. OSPFv3 Router LSA Link Type

 (Defined in Section A.4.3 of [RFC2740])
                   +---------+--------------------+
                   | 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] RFC 4940 IANA Considerations for OSPF June 2007

2.6. OSPFv2 Opaque LSA Type

 (Defined in Section A.2 of [RFC2370])
 (Note: this registry is called "OSPF Opaque LSA Option" by IANA.  See
 also [RFC3630].)
                   +---------+--------------------+
                   | 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 [RFC3623])
                 +-------------+--------------------+
                 | 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] 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       [RFC2328]
 0x04  MC-bit      [RFC1584]
 0x08  N/P-bit     [RFC3101]
 0x10  Reserved
 0x20  DC-bit      [RFC1793]
 0x40  O-bit       [RFC2370]

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] RFC 4940 IANA Considerations for OSPF June 2007

 OSPFv3 Options Registry (Section 2.2)
 Value    Description Reference
 -------- ----------- ---------
 0x000001 V6-bit      [RFC2740]
 0x000002 E-bit       [RFC2328]
 0x000004 MC-bit      [RFC1584]
 0x000008 N-bit       [RFC3101]
 0x000010 R-Bit       [RFC2740]
 0x000020 DC-bit      [RFC1793]

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                [RFC2328]
 2     Database Description [RFC2328]
 3     Link State Request   [RFC2328]
 4     Link State Update    [RFC2328]
 5     Link State Ack       [RFC2328]

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] RFC 4940 IANA Considerations for OSPF June 2007

 OSPFv2 Link State (LS) Type (Section 2.4)
 Value Description              Reference
 ----- ------------------------ ---------
 1     Router-LSA               [RFC2328]
 2     Network-LSA              [RFC2328]
 3     Summary-LSA (IP network) [RFC2328]
 4     Summary-LSA (ASBR)       [RFC2328]
 5     AS-external-LSA          [RFC2328]
 6     Group-membership-LSA     [RFC1584]
 7     NSSA AS-external LSA     [RFC3101]
 8     Reserved
 9     Link-local Opaque LSA    [RFC2370]
 10    Area-local Opaque LSA    [RFC2370]
 11    Opaque LSA               [RFC2370]

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 [RFC2328]
 2     Transit Network                             [RFC2328]
 3     Stub Network                                [RFC2328]
 4     Virtual Link                                [RFC2328]

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       [RFC2328]
 0x02  W-bit       [RFC2328]
 0x04  V-bit       [RFC2328]
 0x08  W-bit       [RFC1584]
 0x10  Nt-bit      [RFC3101]

Kompella & Fenner Best Current Practice [Page 10] 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 [RFC2740].
 As defined in [RFC2740], 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] 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            [RFC2740]
 2                 0x2002  Network-LSA           [RFC2740]
 3                 0x2003  Inter-Area-Prefix-LSA [RFC2740]
 4                 0x2004  Inter-Area-Router-LSA [RFC2740]
 5                 0x4005  AS-External-LSA       [RFC2740]
 6                 0x2006  Group-membership-LSA  [RFC2740]
 7                 0x2007  Type-7-LSA            [RFC2740]
 8                 0x0008  Link-LSA              [RFC2740]
 9                 0x2009  Intra-Area-Prefix-LSA [RFC2740]

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      [RFC2740]
 0x02  LA-bit      [RFC2740]
 0x04  MC-bit      [RFC2740]
 0x08  P-bit       [RFC2740]

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 [RFC2740]
 2     Transit Network                             [RFC2740]
 3     Reserved                                    [RFC2740]
 4     Virtual Link                                [RFC2740]

Kompella & Fenner Best Current Practice [Page 12] 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            [RFC3623]
 2     Graceful Restart reason [RFC3623]
 3     IP Interface Address    [RFC3623]

6. References

6.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC1584]  Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
            1994.
 [RFC1793]  Moy, J., "Extending OSPF to Support Demand Circuits", RFC
            1793, April 1995.
 [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
 [RFC2370]  Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July
            1998.
 [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 2434,
            October 1998.
 [RFC2740]  Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC
            2740, December 1999.
 [RFC3101]  Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
            RFC 3101, January 2003.

Kompella & Fenner Best Current Practice [Page 13] RFC 4940 IANA Considerations for OSPF June 2007

 [RFC3623]  Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF
            Restart", RFC 3623, November 2003.
 [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
            (TE) Extensions to OSPF Version 2", RFC 3630, September
            2003.
 [RFC3692]  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] RFC 4940 IANA Considerations for OSPF June 2007

Full Copyright Statement

 Copyright (C) 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4940.txt · Last modified: 2007/06/30 00:12 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki