[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-kompella-ospf-iana) 00 01 02 03 RFC 4940

Network Working Group                                        K. Kompella
Internet-Draft                                          Juniper Networks
Expires: September 30, 2005                               March 29, 2005


                      IANA Considerations for OSPF
                        draft-ietf-ospf-iana-00

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 30, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

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








Kompella               Expires September 30, 2005               [Page 1]

Internet-Draft        IANA Considerations for OSPF            March 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Conventions used in this document  . . . . . . . . . . . .  4
   2.  OSPF Registries  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1   OSPFv2 Options . . . . . . . . . . . . . . . . . . . . . .  5
     2.2   OSPFv3 Options . . . . . . . . . . . . . . . . . . . . . .  5
     2.3   OSPF Packet Type (both v2 and v3)  . . . . . . . . . . . .  5
       2.3.1   OSPF Authentication Type . . . . . . . . . . . . . . .  5
     2.4   OSPFv2 Link State (LS) Type  . . . . . . . . . . . . . . .  6
       2.4.1   OSPFv2 Router LSA Link Type  . . . . . . . . . . . . .  6
       2.4.2   OSPFv2 Router Properties . . . . . . . . . . . . . . .  7
     2.5   OSPFv3 LSA Function Code . . . . . . . . . . . . . . . . .  7
       2.5.1   OSPFv3 Prefix Options  . . . . . . . . . . . . . . . .  8
       2.5.2   OSPFv3 Router LSA Link Type  . . . . . . . . . . . . .  8
     2.6   OSPFv2 Opaque LSA Type . . . . . . . . . . . . . . . . . .  8
       2.6.1   OSPFv2 Grace LSA Top Level TLVs  . . . . . . . . . . .  9
   3.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1   Normative References . . . . . . . . . . . . . . . . . . . 13
     6.2   Informative References . . . . . . . . . . . . . . . . . . 13
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
       Intellectual Property and Copyright Statements . . . . . . . . 14


























Kompella               Expires September 30, 2005               [Page 2]

Internet-Draft        IANA Considerations for OSPF            March 2005


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:
      - Standards Action
      - Experimentation
      - Vendor Private Use
      - Reserved

   Standards Action means that assignment in that range MUST only be
   made for Standards Track RFCs (as defined in [4]).

   A range of values MAY be reserved for Experimentation as set out in
   [9].  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 [9].  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.  (An example of such protocol machinery is the U bit in
   OSPFv2 Opaque LSAs.)  "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 enterprise code (see
   [10]) 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 recognises; if so, the implementation MAY choose to
   interpret the code point and data structure.  Otherwise, it SHOULD
   ignore the code point, unless protocol machinery says how to deal
   with the data structure (as defined in the previous paragraph).  This
   allows multiple vendor private extensions to co-exist 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
   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.





Kompella               Expires September 30, 2005               [Page 3]

Internet-Draft        IANA Considerations for OSPF            March 2005


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














































Kompella               Expires September 30, 2005               [Page 4]

Internet-Draft        IANA Considerations for OSPF            March 2005


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 pre-date 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 [2], updated in section A.1 of [3].  See
   also [6].)

   Assignment policy: Standards Action.

2.2  OSPFv3 Options

   (Defined in section A.2 of [5])

   Assignment policy: Standards Action.

2.3  OSPF Packet Type (both v2 and v3)

   (Defined in section A.3.1 of [2])

                    +---------+--------------------+
                    | Range   | Assignment Policy  |
                    +---------+--------------------+
                    | 0       | Not to be assigned |
                    |         |                    |
                    | 1-5     | Already assigned   |
                    |         |                    |
                    | 6-127   | Standards Action   |
                    |         |                    |
                    | 128-255 | Reserved           |
                    +---------+--------------------+


2.3.1  OSPF Authentication Type

   (Defined in section A.3.1 of [2])

   (Note: this registry is called "OSPF AUTHENTICATION CODES" by IANA.)




Kompella               Expires September 30, 2005               [Page 5]

Internet-Draft        IANA Considerations for OSPF            March 2005


                  +-------------+-------------------+
                  | Range       | Assignment Policy |
                  +-------------+-------------------+
                  | 0-2         | Already assigned  |
                  |             |                   |
                  | 3-247       | Standards Action  |
                  |             |                   |
                  | 248-65519   | Reserved          |
                  |             |                   |
                  | 65520-65535 | Experimentation   |
                  +-------------+-------------------+

   It is unclear at this point if it makes sense to have a Vendor
   Private Use range for this registry.

2.4  OSPFv2 Link State (LS) Type

   (Defined in section A.4.1 of [2])

                    +---------+--------------------+
                    | 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, as well as what the flooding scope
   of the LSA is.

2.4.1  OSPFv2 Router LSA Link Type

   (Defined in section A.4.2 of [2])

                    +---------+--------------------+
                    | Range   | Assignment Policy  |
                    +---------+--------------------+
                    | 0       | Not to be assigned |
                    |         |                    |
                    | 1-4     | Already assigned   |
                    |         |                    |
                    | 5-127   | Standards Action   |
                    |         |                    |



Kompella               Expires September 30, 2005               [Page 6]

Internet-Draft        IANA Considerations for OSPF            March 2005


                    | 128-255 | Reserved           |
                    +---------+--------------------+

   There is no range for Vendor Private Use, as there is no space for an
   enterprise code to identify the Vendor.

   There is currently no range for Experimental, as it is not clear that
   such extensions will be backward compatible.

   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.

2.4.2  OSPFv2 Router Properties

   (Defined in section A.4.2 of [2], updated in [6])

   This 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

   (Defined in section A.4.2.1 of [5])

                   +-----------+--------------------+
                   | Range     | Assignment Policy  |
                   +-----------+--------------------+
                   | 0         | Not to be assigned |
                   |           |                    |
                   | 1-9       | Already assigned   |
                   |           |                    |
                   | 10-255    | Standards Action   |
                   |           |                    |
                   | 256-8175  | Reserved           |
                   |           |                    |
                   | 8176-8183 | Experimentation    |
                   |           |                    |
                   | 8184-8191 | Vendor Private Use |
                   +-----------+--------------------+

   In an OSPFv3 LSA with LSA Function Code in the Vendor Private Use
   range, the first four octets following the 20 octets of LSA header
   MUST be the Vendor enterprise code.

   If a new LSA Function Code is documented, the documentation MUST
   include the valid combinations of the U, S2 and S1 bits for the LSA.



Kompella               Expires September 30, 2005               [Page 7]

Internet-Draft        IANA Considerations for OSPF            March 2005


   It SHOULD also say how the Link State ID is to be filled in.

2.5.1  OSPFv3 Prefix Options

   (Defined in section A.4.1.1 of [5])

   Assignment policy: Standards Action.

2.5.2  OSPFv3 Router LSA Link Type

   (Defined in section A.4.3 of [5])

                    +---------+--------------------+
                    | 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.

   There is currently no range for Experimental, as it is not clear that
   such extensions will be backward compatible.

2.6  OSPFv2 Opaque LSA Type

   (Defined in section A.2 of [3])

   (Note: this registry is called "OSPF Opaque LSA Option" by IANA.  See
   also [8].)

                    +---------+--------------------+
                    | Range   | Assignment Policy  |
                    +---------+--------------------+
                    | 0       | Not to be assigned |
                    |         |                    |
                    | 1-3     | Already assigned   |
                    |         |                    |
                    | 4-127   | Standards Action   |
                    |         |                    |
                    | 128-247 | Reserved           |
                    |         |                    |



Kompella               Expires September 30, 2005               [Page 8]

Internet-Draft        IANA Considerations for OSPF            March 2005


                    | 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 Section A of [7])

                  +-------------+--------------------+
                  | 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               Expires September 30, 2005               [Page 9]

Internet-Draft        IANA Considerations for OSPF            March 2005


3.  Acknowledgments

   Many thanks to Adrian Farrel and Acee Lindem for their review and
   comments.















































Kompella               Expires September 30, 2005              [Page 10]

Internet-Draft        IANA Considerations for OSPF            March 2005


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.









































Kompella               Expires September 30, 2005              [Page 11]

Internet-Draft        IANA Considerations for OSPF            March 2005


5.  IANA Considerations

   Done, at last.
















































Kompella               Expires September 30, 2005              [Page 12]

Internet-Draft        IANA Considerations for OSPF            March 2005


6.  References

6.1  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [3]  Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.

   [4]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [5]  Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740,
        December 1999.

   [6]  Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
        RFC 3101, January 2003.

   [7]  Moy, J., Pillay-Esnault, P. and A. Lindem, "Graceful OSPF
        Restart", RFC 3623, November 2003.

   [8]  Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE)
        Extensions to OSPF Version 2", RFC 3630, September 2003.

   [9]  Narten, T., "Assigning Experimental and Testing Numbers
        Considered Useful", BCP 82, RFC 3692, January 2004.

6.2  Informative References

   [10]  "PRIVATE ENTERPRISE NUMBERS".

         http://www.iana.org/assignments/enterprise-numbers


Author's Address

   Kireeti Kompella
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

   Email: kireeti@juniper.net






Kompella               Expires September 30, 2005              [Page 13]

Internet-Draft        IANA Considerations for OSPF            March 2005


Intellectual Property Statement

   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.


Disclaimer of Validity

   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 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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Kompella               Expires September 30, 2005              [Page 14]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/