summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4940.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4940.txt')
-rw-r--r--doc/rfc/rfc4940.txt843
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc4940.txt b/doc/rfc/rfc4940.txt
new file mode 100644
index 0000000..d58a010
--- /dev/null
+++ b/doc/rfc/rfc4940.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+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]
+