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 Vendor Private Use
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.
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].
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).
+---------+--------------------+ | 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.
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.
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.
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]
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.
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
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.
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.
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 email@example.com.
Funding for the RFC Editor function is currently provided by the Internet Society.