One document matched: draft-kompella-ospf-iana-00.txt
Network Working Group K. Kompella
Internet Draft Juniper Networks
Proposed Category: Best Current Practice July 2004
Updates: 2328 2370
Expires: January 2005
IANA Considerations for OSPF
draft-kompella-ospf-iana-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I 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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Kompella Best Current Practice [Page 1]
Internet Draft IANA Considerations for OSPF July 2004
Abstract
This memo creates a number of OSPF registries and provides guidance
to IANA for assignment of code points within these registries.
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 [KEYWORDS].
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 [IANA]).
A range of values may be reserved for Experimentation as set out in
[EXPT]. 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 [EXPT]. 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
[ENT]) 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
Kompella Best Current Practice [Page 2]
Internet Draft IANA Considerations for OSPF July 2004
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.
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 [OSPFv2], updated in section A.1 of
[OPAQ]. See also [NSSA].)
Assignment policy: Standards Action.
2.2. OSPFv3 Options
(Defined in section A.2 of [OSPFv3])
Assignment policy: Standards Action.
2.3. OSPF Packet Type
(Defined in section A.3.1 of [OSPFv2])
Range Assignment Policy
----- -----------------
0 Not to be assigned
1-5 Already assigned
5-127 Standards Action
128-247 Reserved
Kompella Best Current Practice [Page 3]
Internet Draft IANA Considerations for OSPF July 2004
248-251 Experimentation
252-255 Vendor Private Use
In an OSPF packet with Packet Type in the Vendor Private Use range,
the first four octets after the 24 octets of packet header MUST be
the Vendor enterprise code.
2.3.1. OSPF Authentication Type
(Defined in section A.3.1 of [OSPFv2])
(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
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 [OSPFv2])
Range Assignment Policy
----- -----------------
0 Not to be assigned
1-11 Already assigned
12-127 Standards Action
128-247 Reserved
248-251 Experimentation
252-255 Vendor Private Use
In an OSPFv2 LSA with LS Type in the Experimentation or Vendor
Private Use ranges, the first four octets following the 20 octets of
LSA header MUST be formatted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|S|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where U, S and T are defined as follows (see also [OSPFv3]):
Kompella Best Current Practice [Page 4]
Internet Draft IANA Considerations for OSPF July 2004
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 S and T bits indicate the flooding scope of the LSA. The values
are:
S T 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
In an OSPFv2 LSA with LS Type in the Vendor Private Use range, the
second four octets following the 20 octets of LSA header MUST be the
Vendor enterprise code.
If a new LS Type is documented, the documentation SHOULD say how the
Link State ID is to be filled in, as well as the flooding scope of
the LSA.
2.4.1. OSPFv2 Router LSA Link Type
(Defined in section A.4.2 of [OSPFv2])
Range Assignment Policy
----- -----------------
0 Not to be assigned
1-4 Already assigned
5-127 Standards Action
128-247 Reserved
248-255 Experimentation
There is no range for Vendor Private Use, as there is no space for an
enterprise code to identify the Vendor.
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 [OSPFv2], updated in [NSSA])
This field in the Router LSA is unnamed; it is the field immediately
following the Router LSA length.
Kompella Best Current Practice [Page 5]
Internet Draft IANA Considerations for OSPF July 2004
Assignment policy: Standards Action.
2.5. OSPFv3 LSA Function Code
(Defined in section A.4.2.1 of [OSPFv3])
Range Assignment Policy
----- -----------------
0 Not to be assigned
1-9 Already assigned
10-247 Standards Action
248-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.
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 [OSPFv3])
Assignment policy: Standards Action.
2.5.2. OSPFv3 Router LSA Link Type
(Defined in section A.4.3 of [OSPFv3])
Range Assignment Policy
----- -----------------
0 Not to be assigned
1-4 Already assigned
5-127 Standards Action
128-247 Reserved
248-255 Experimentation
There is no range for Vendor Private Use, as there is no space for an
enterprise code to identify the Vendor.
Kompella Best Current Practice [Page 6]
Internet Draft IANA Considerations for OSPF July 2004
2.6. OSPFv2 Opaque LSA Type
(Defined in section A.2 of [OPAQ])
(Note: this registry is called "OSPF Opaque LSA Option" by IANA.)
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 Section A of [OSPF-GR].)
Range Assignment Policy
----- -----------------
0 Not to be assigned
1-3 Already assigned
4-247 Standards Action
248-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 Best Current Practice [Page 7]
Internet Draft IANA Considerations for OSPF July 2004
3. Acknowledgments
Many thanks to Adrian Farrel for his 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
Done, at last.
6. Normative References
[EXPT] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004
[IANA] Narten, T., and Alvestrand, H., "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
RFC 3101, January 2003
[OPAQ] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July
1998
[OSPF-GR] Moy, J. et al, "Graceful OSPF Restart", RFC 3623, November
2003
[OSPFv2] Moy, J. (Editor), "OSPF Version 2", STD 54, RFC 2328,
April 1998
[OSPFv3] Coltun, R., Ferguson, D., and Moy, J. "OSPF for IPv6", RFC
2740, December 1999
Kompella Best Current Practice [Page 8]
Internet Draft IANA Considerations for OSPF July 2004
7. Informative References
[ENT] IANA PRIVATE ENTERPRISE NUMBERS,
http://www.iana.org/assignments/enterprise-numbers
Author's Addresses
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
USA
Email: kireeti@juniper.net
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 IETF's procedures with respect to rights in IETF 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.
Kompella Best Current Practice [Page 9]
Internet Draft IANA Considerations for OSPF July 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Disclaimer
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.
Acknowledgement:
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kompella Best Current Practice [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-21 03:30:50 |