doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc7770.txt b/doc/rfc/rfc7770.txt
new file mode 100644
index 0000000..50ef1cb
--- /dev/null
+++ b/doc/rfc/rfc7770.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                    A. Lindem, Ed.
+Request for Comments: 7770                                       N. Shen
+Obsoletes: 4970                                              JP. Vasseur
+Category: Standards Track                                  Cisco Systems
+ISSN: 2070-1721                                              R. Aggarwal
+                                                                  Arktan
+                                                              S. Shaffer
+                                                                  Akamai
+                                                           February 2016
+
+
+    Extensions to OSPF for Advertising Optional Router Capabilities
+
+Abstract
+
+   It is useful for routers in an OSPFv2 or OSPFv3 routing domain to
+   know the capabilities of their neighbors and other routers in the
+   routing domain.  This document proposes extensions to OSPFv2 and
+   OSPFv3 for advertising optional router capabilities.  The Router
+   Information (RI) Link State Advertisement (LSA) is defined for this
+   purpose.  In OSPFv2, the RI LSA will be implemented with an Opaque
+   LSA type ID.  In OSPFv3, the RI LSA will be implemented with a unique
+   LSA type function code.  In both protocols, the RI LSA can be
+   advertised at any of the defined flooding scopes (link, area, or
+   autonomous system (AS)).  This document obsoletes RFC 4970 by
+   providing a revised specification that includes support for
+   advertisement of multiple instances of the RI LSA and a TLV for
+   functional capabilities.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7770.
+
+
+
+
+
+
+
+
+
+Lindem, et al.               Standards Track                    [Page 1]
+
+RFC 7770               OSPF Capability Extensions          February 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   3
+     1.2.  Summary of Changes from RFC 4970  . . . . . . . . . . . .   3
+   2.  OSPF Router Information (RI) LSA  . . . . . . . . . . . . . .   4
+     2.1.  OSPFv2 Router Information (RI) Opaque LSA . . . . . . . .   4
+     2.2.  OSPFv3 Router Information (RI) Opaque LSA . . . . . . . .   5
+     2.3.  OSPF Router Information LSA TLV Format  . . . . . . . . .   6
+     2.4.  OSPF Router Informational Capabilities TLV  . . . . . . .   6
+     2.5.  Assigned OSPF Router Informational Capability Bits  . . .   7
+     2.6.  OSPF Router Functional Capabilities TLV . . . . . . . . .   8
+     2.7.  Flooding Scope of the Router Information LSA  . . . . . .   9
+   3.  Backwards Compatibility . . . . . . . . . . . . . . . . . . .   9
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
+     5.1.  OSPFv2 Opaque LSA Type Assignment . . . . . . . . . . . .  10
+     5.2.  OSPFv3 LSA Function Code Assignment . . . . . . . . . . .  10
+     5.3.  OSPF RI LSA TLV Type Assignment . . . . . . . . . . . . .  11
+     5.4.  Registry for OSPF Router Informational Capability Bits  .  12
+     5.5.  Registry for OSPF Router Functional Capability Bits . . .  12
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
+     6.2.  Informative References  . . . . . . . . . . . . . . . . .  13
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15
+
+
+
+
+
+
+
+
+
+
+Lindem, et al.               Standards Track                    [Page 2]
+
+RFC 7770               OSPF Capability Extensions          February 2016
+
+
+1.  Introduction
+
+   It is useful for routers in an OSPFv2 [OSPF] or OSPFv3 [OSPFv3]
+   routing domain to know the capabilities of their neighbors and other
+   routers in the routing domain.  This can be useful for both the
+   advertisement and discovery of OSPFv2 and OSPFv3 capabilities.
+   Throughout this document, OSPF will be used when the specification is
+   applicable to both OSPFv2 and OSPFv3.  Similarly, OSPFv2 or OSPFv3
+   will be used when the text is protocol specific.
+
+   OSPF uses the options field in LSAs and hello packets to advertise
+   optional router capabilities.  In the case of OSPFv2, all the bits in
+   this field have been allocated so additional optional capabilities
+   cannot be advertised.  This document describes extensions to OSPF to
+   advertise these optional capabilities via Opaque LSAs in OSPFv2 and
+   LSAs with a unique type in OSPFv3.  For existing OSPF capabilities,
+   backwards compatibility issues dictate that this advertisement is
+   used primarily for informational purposes.  For future OSPF
+   extensions, this advertisement MAY be used as the sole mechanism for
+   advertisement and discovery.
+
+   This document obsoletes RFC 4970 by providing a revised specification
+   including support for advertisement of multiple instances of the RI
+   LSA and a TLV for functional capabilities.
+
+1.1.  Requirements Notation
+
+   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-KEYWORDS].
+
+1.2.  Summary of Changes from RFC 4970
+
+   This document includes the following changes from RFC 4970 [RFC4970]:
+
+   1. The main change is that an OSPF router will be able to advertise
+      multiple instances of the OSPF Router Information LSA.  This
+      change permeates through much of the document.
+
+   2. Additionally, Section 2.6 includes an additional TLV for
+      functional capabilities.  This is in contrast to the existing TLV
+      that is used to advertise capabilities for informational purposes
+      only.
+
+
+
+
+
+
+
+
+Lindem, et al.               Standards Track                    [Page 3]
+
+RFC 7770               OSPF Capability Extensions          February 2016
+
+
+   3. The IANA allocation policy has been changed from "Standards
+      Action" to "IETF Review" [IANA-GUIDE] for the following
+      registries:
+
+      o  OSPFv3 LSA Function Codes
+      o  OSPF Router Information (RI) TLVs
+      o  OSPF Router Informational Capability Bits
+      o  OSPF Router Functional Capability Bits
+
+   4. Finally, references have been updated for documents that have
+      become RFCs and RFCs that have been obsoleted since the
+      publication of RFC 4970.
+
+2.  OSPF Router Information (RI) LSA
+
+2.1.  OSPFv2 Router Information (RI) Opaque LSA
+
+   OSPFv2 routers will advertise a link scoped, area-scoped, or AS-
+   scoped Opaque LSA [OPAQUE].  The OSPFv2 RI LSA has an Opaque type of
+   4 and the Opaque ID is the RI LSA Instance ID.  The first Opaque ID,
+   i.e., 0, SHOULD always contain the Router Informational Capabilities
+   TLV and, if advertised, the Router Functional Capabilities TLV.  RI
+   LSA instances subsequent to the first can be used for information
+   that doesn't fit in the first instance.
+
+   OSPFv2 routers will advertise a link-scoped, area-scoped, or AS-
+   scoped Opaque LSA [OPAQUE].  The OSPFv2 Router Information LSA has an
+   Opaque type of 4.  The Opaque ID specifies the LSA Instance ID with
+   the first instance always having an Instance ID of 0.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |            LS age             |     Options   |  9, 10, or 11 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |       4       |     Opaque ID (Instance ID)                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+d-+-+-+-+-+-+-+-+-+-+-+
+      |                     Advertising Router                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     LS sequence number                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         LS checksum           |             length            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +-                            TLVs                             -+
+      |                             ...                               |
+
+                Figure 1.  OSPFv2 Router Information Opaque LSA
+
+
+
+Lindem, et al.               Standards Track                    [Page 4]
+
+RFC 7770               OSPF Capability Extensions          February 2016
+
+
+   The format of the TLVs within the body of an RI LSA is as defined in
+   Section 2.3.
+
+2.2.  OSPFv3 Router Information (RI) Opaque LSA
+
+   The OSPFv3 Router Information LSA has a function code of 12 while the
+   S1/S2 bits are dependent on the desired flooding scope for the LSA.
+   The U bit will be set indicating that the OSPFv3 RI LSA should be
+   flooded even if it is not understood.  The Link State ID (LSID) value
+   for this LSA is the Instance ID.  The first Instance ID, i.e., 0,
+   SHOULD always contain the Router Informational Capabilities TLV and,
+   if advertised, the Router Functional Capabilities TLV.  OSPFv3 Router
+   Information LSAs subsequent to the first can be used for information
+   that doesn't fit in the first instance.  OSPFv3 routers MAY advertise
+   multiple RI LSAs per flooding scope.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |            LS age             |1|S12|          12             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Link State ID (Instance ID)             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Advertising Router                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       LS sequence number                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        LS checksum            |            Length             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +-                            TLVs                             -+
+      |                             ...                               |
+
+                  Figure 2.  OSPFv3 Router Information LSA
+
+   The format of the TLVs within the body of an RI LSA is as defined in
+   Section 2.3
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lindem, et al.               Standards Track                    [Page 5]
+
+RFC 7770               OSPF Capability Extensions          February 2016
+
+
+2.3.  OSPF Router Information LSA TLV Format
+
+   The format of the TLVs within the body of an RI LSA is the same as
+   the format used by the Traffic Engineering Extensions to OSPF [TE].
+   The LSA payload consists of one or more nested Type/Length/Value
+   (TLV) triplets.  The format of each TLV is:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              Type             |             Length            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                            Value...                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                             Figure 3.  TLV Format
+
+   The Length field defines the length of the value portion in octets
+   (thus a TLV with no value portion would have a length of 0).  The TLV
+   is padded to 4-octet alignment; padding is not included in the length
+   field (so a 3-octet value would have a length of 3, but the total
+   size of the TLV would be 8 octets).  Nested TLVs are also 4-octet
+   aligned.  For example, a 1-octet value would have the length field
+   set to 1, and 3 octets of padding would be added to the end of the
+   value portion of the TLV.  The padding is composed of undefined bits.
+   Unrecognized types are ignored.
+
+   When a new Router Information LSA TLV is defined, the specification
+   MUST explicitly state whether the TLV is applicable to OSPFv2 only,
+   OSPFv3 only, or both OSPFv2 and OSPFv3.
+
+2.4.  OSPF Router Informational Capabilities TLV
+
+   An OSPF router advertising an OSPF RI LSA MAY include the Router
+   Informational Capabilities TLV.  If included, it MUST be the first
+   TLV in the first instance, i.e., Instance 0, of the OSPF RI LSA.
+   Additionally, the TLV MUST accurately reflect the OSPF router's
+   capabilities in the scope advertised.  However, the informational
+   capabilities advertised have no impact on OSPF protocol operation;
+   they are advertised purely for informational purposes.
+
+
+
+
+
+
+
+
+
+
+
+Lindem, et al.               Standards Track                    [Page 6]
+
+RFC 7770               OSPF Capability Extensions          February 2016
+
+
+   The format of the Router Informational Capabilities TLV is 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              Type             |             Length            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             Informational Capabilities                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type     A 16-bit field set to 1.
+
+      Length   A 16-bit field that indicates the length of the value
+               portion in octets and will be a multiple of 4 octets
+               dependent on the number of capabilities advertised.
+               Initially, the length will be 4, denoting 4 octets of
+               informational capability bits.
+
+      Value    A variable-length sequence of capability bits rounded to
+               a multiple of 4 octets padded with undefined bits.
+               Initially, there are 4 octets of capability bits.  Bits
+               are numbered left to right starting with the most
+               significant bit being bit 0.
+
+           Figure 4.  OSPF Router Informational Capabilities TLV
+
+   The Router Informational Capabilities TLV MAY be followed by optional
+   TLVs that further specify a capability.
+
+2.5.  Assigned OSPF Router Informational Capability Bits
+
+   The following informational capability bits have been assigned:
+
+      Bit       Capabilities
+
+      0         OSPF graceful restart capable [GRACE]
+      1         OSPF graceful restart helper  [GRACE]
+      2         OSPF Stub Router support [STUB]
+      3         OSPF Traffic Engineering support [TE]
+      4         OSPF point-to-point over LAN [P2PLAN]
+      5         OSPF Experimental TE [EXP-TE]
+      6-31      Unassigned (IETF Review)
+
+      Figure 5.  OSPF Router Informational Capabilities Bits
+
+   References for [GRACE], [STUB], [TE], [P2PLAN], and [EXP-TE] are
+   included herein.
+
+
+
+Lindem, et al.               Standards Track                    [Page 7]
+
+RFC 7770               OSPF Capability Extensions          February 2016
+
+
+2.6.  OSPF Router Functional Capabilities TLV
+
+   This specification also defines the Router Functional Capabilities
+   TLV for advertisement in the OSPF Router Information LSA.  An OSPF
+   router advertising an OSPF RI LSA MAY include the Router Functional
+   Capabilities TLV.  If included, it MUST be the included in the first
+   instance of the LSA.  Additionally, the TLV MUST reflect the
+   advertising OSPF router's actual functional capabilities since the
+   information will be used to dictate OSPF protocol operation in the
+   flooding scope of the containing OSPF RI LSA.  If the TLV is not
+   included or the length doesn't include the assigned OSPF functional
+   capability bit, the corresponding OSPF functional capability is
+   implicitly advertised as not being supported by the advertising OSPF
+   router.
+
+   The format of the Router Functional Capabilities TLV is 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              Type             |             Length            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             Functional Capabilities                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type     A 16-bit field set to 2.
+
+      Length   A 16-bit field that indicates the length of the value
+               portion in octets and will be a multiple of 4 octets
+               dependent on the number of capabilities advertised.
+               Initially, the length will be 4, denoting 4 octets of
+               informational capability bits.
+
+      Value    A variable-length sequence of capability bits rounded
+               to a multiple of 4 octets padded with undefined bits.
+               Initially, there are 4 octets of capability bits.  Bits
+               are numbered left to right starting with the most
+               significant bit being bit 0.
+
+             Figure 6.  OSPF Router Functional Capabilities TLV
+
+   The Router Functional Capabilities TLV MAY be followed by optional
+   TLVs that further specify a capability.  In contrast to the Router
+   Informational Capabilities TLV, the OSPF extensions advertised in
+   this TLV MAY be used by other OSPF routers to dictate protocol
+   operation.  The specifications for functional capabilities advertised
+   in this TLV MUST describe protocol behavior and address backwards
+   compatibility.
+
+
+
+Lindem, et al.               Standards Track                    [Page 8]
+
+RFC 7770               OSPF Capability Extensions          February 2016
+
+
+2.7.  Flooding Scope of the Router Information LSA
+
+   The flooding scope for a Router Information LSA is determined by the
+   LSA type.  For OSPFv2, a type 9 (link-scoped), type 10 (area-scoped),
+   or type 11 (AS-scoped) Opaque LSA may be flooded.  For OSPFv3, the S1
+   and S2 bits in the LSA type determine the flooding scope.  If AS-wide
+   flooding scope is chosen, the originating router should also
+   advertise area-scoped LSA(s) into any attached Not-So-Stubby Area
+   (NSSA) area(s).  An OSPF router MAY advertise different capabilities
+   when both NSSA area-scoped LSA(s) and an AS-scoped LSA are
+   advertised.  This allows functional capabilities to be limited in
+   scope.  For example, a router may be an area border router but only
+   support traffic engineering (TE) in a subset of its attached areas.
+
+   The choice of flooding scope is made by the advertising router and is
+   a matter of local policy.  The originating router MAY advertise
+   multiple RI LSAs with the same Instance ID as long as the flooding
+   scopes differ.  TLV flooding-scope rules will be specified on a per-
+   TLV basis and MUST be specified in the accompanying specifications
+   for future Router Information LSA TLVs.
+
+3.  Backwards Compatibility
+
+   For backwards compatibility, previously advertised Router Information
+   TLVs SHOULD continue to be advertised in the first instance, i.e., 0,
+   of the Router Information LSA.  If a Router Information TLV is
+   advertised in multiple Router Information LSA instances and the
+   multiple instance processing is not explicitly specified in the RFC
+   defining that Router Information TLV, the Router Instance TLV in the
+   Router Information LSA with the numerically smallest Instance ID will
+   be used and subsequent instances will be ignored.
+
+4.  Security Considerations
+
+   This document describes both a generic mechanism for advertising
+   router capabilities and TLVs for advertising informational and
+   functional capabilities.  The capability TLVs are less critical than
+   the topology information currently advertised by the base OSPF
+   protocol.  The security considerations for the generic mechanism are
+   dependent on the future application and, as such, should be described
+   as additional capabilities are proposed for advertisement.  Security
+   considerations for the base OSPF protocol are covered in [OSPF] and
+   [OSPFv3].
+
+
+
+
+
+
+
+
+Lindem, et al.               Standards Track                    [Page 9]
+
+RFC 7770               OSPF Capability Extensions          February 2016
+
+
+5.  IANA Considerations
+
+5.1.  OSPFv2 Opaque LSA Type Assignment
+
+   [RFC4970] defined the Router Information Opaque LSA as type 4 in the
+   "Opaque Link-State Advertisements (LSA) Option Types" registry.  IANA
+   has updated the reference for that entry to point to this RFC.
+
+5.2.  OSPFv3 LSA Function Code Assignment
+
+   [RFC4970] created the registry for "OSPFv3 LSA Function Codes".  IANA
+   has updated the reference for that registry to point to this RFC.
+   References within that registry to [RFC4970] have been updated to
+   point to this RFC; references to other RFCs are unchanged.
+
+   The definition and assignment policy has been updated as follows.
+
+   This registry is now comprised of the fields Value, LSA Function Code
+   Name, and Reference.  The OSPFv3 LSA function code is defined in
+   Appendix A.4.2.1 of [OSPFv3].  Values 1-11 and 13-15 have already
+   been assigned.  The OSPFv3 LSA function code 12 has been assigned to
+   the OSPFv3 Router Information (RI) LSA as defined herein.
+
+         +-----------+-------------------------------------+
+         | Range     | Assignment Policy                   |
+         +-----------+-------------------------------------+
+         | 0         | Reserved (not to be assigned)       |
+         |           |                                     |
+         | 16-255    | Unassigned (IETF Review)            |
+         |           |                                     |
+         | 256-8175  | Reserved (No assignments)           |
+         |           |                                     |
+         | 8176-8183 | Experimentation (No assignments)    |
+         |           |                                     |
+         | 8184-8190 | Vendor Private Use (No assignments) |
+         |           |                                     |
+         | 8191      | Reserved (not to be assigned)       |
+         +-----------+-------------------------------------+
+
+                Figure 7.  OSPFv3 LSA Function Codes
+
+   o  The assignment policy for OSPFv3 LSA function codes in the range
+      16-255 has changed and are now assigned subject to IETF Review.
+      New values are assigned through RFCs that have been shepherded
+      through the IESG as AD-Sponsored or IETF WG documents
+      [IANA-GUIDE].
+
+
+
+
+
+Lindem, et al.               Standards Track                   [Page 10]
+
+RFC 7770               OSPF Capability Extensions          February 2016
+
+
+   o  OSPFv3 LSA function codes in the range 8176-8183 are for
+      experimental use; these will not be registered with IANA and MUST
+      NOT be mentioned by RFCs.
+
+   o  OSPFv3 LSAs with an LSA Function Code in the Vendor Private Use
+      range 8184-8190 MUST include the Enterprise Code [ENTERPRISE-CODE]
+      as the first 4 octets following the 20 octets of LSA header.
+
+   o  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 describe how the Link State ID is to be
+      assigned.
+
+5.3.  OSPF RI LSA TLV Type Assignment
+
+   [RFC4970] created the registry for "OSPF Router Information (RI)
+   TLVs".  IANA has updated the reference for this registry to point to
+   this RFC.  References within that registry to [RFC4970] have been
+   updated to point to this RFC; references to other RFCs are unchanged.
+
+   The definition and assignment policy has been updated as follows.
+
+   The registry is now comprised of the fields Value, TLV Name, and
+   Reference.  Values 3-9 have already been assigned.  Value 1 has been
+   assigned to the Router Informational Capabilities TLV and value 2 has
+   been assigned to the Router Functional Capabilities TLV as defined
+   herein.
+
+            +-------------+-----------------------------------+
+            | Range       | Assignment Policy                 |
+            +-------------+-----------------------------------+
+            | 0           | Reserved (not to be assigned)     |
+            |             |                                   |
+            | 10-32767    | Unassigned (IETF Review)          |
+            |             |                                   |
+            | 32768-32777 | Experimentation (No assignments)  |
+            |             |                                   |
+            | 32778-65535 | Reserved (Not to be assigned)     |
+            +-------------+-----------------------------------+
+
+                         Figure 8.  OSPF RI TLVs
+
+   o  Types in the range 10-32767 are to be assigned subject to IETF
+      Review.  New values are assigned through RFCs that have been
+      shepherded through the IESG as AD-Sponsored or IETF WG documents
+      [IANA-GUIDE].
+
+
+
+
+
+Lindem, et al.               Standards Track                   [Page 11]
+
+RFC 7770               OSPF Capability Extensions          February 2016
+
+
+   o  Types in the range 32778-65535 are reserved and are not to be
+      assigned at this time.  Before any assignments can be made in this
+      range, there MUST be a Standards Track RFC that specifies IANA
+      Considerations that cover the range being assigned.
+
+5.4.  Registry for OSPF Router Informational Capability Bits
+
+   [RFC4970] created the registry for "OSPF Router Informational
+   Capability Bits".  IANA has updated the reference for this registry
+   to point to this RFC.  The definition and assignment policy has been
+   updated as follows.
+
+   o  This registry is now comprised of the fields Bit Number,
+      Capability Name, and Reference.
+
+   o  The values are defined in Section 2.6.  All Router Informational
+      Capability TLV additions are to be assigned through IETF Review
+      [IANA-GUIDE].
+
+5.5.  Registry for OSPF Router Functional Capability Bits
+
+   IANA has created a subregistry for "OSPF Router Functional Capability
+   Bits" within the "Open Shortest Path First v2 (OSPFv2) Parameters"
+   registry.  This subregistry is comprised of the fields Bit Number,
+   Capability Name, and Reference.  Initially, the subregistry will be
+   empty but will be available for future capabilities.  All Router
+   Functional Capability TLV additions are to be assigned through IETF
+   Review [IANA-GUIDE].
+
+6.  References
+
+6.1.  Normative References
+
+   [OPAQUE]  Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
+             OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
+             July 2008, <http://www.rfc-editor.org/info/rfc5250>.
+
+   [OSPF]    Moy, J., "OSPF Version 2", STD 54, RFC 2328,
+             DOI 10.17487/RFC2328, April 1998,
+             <http://www.rfc-editor.org/info/rfc2328>.
+
+   [OSPFv3]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for
+             IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
+             <http://www.rfc-editor.org/info/rfc5340>.
+
+
+
+
+
+
+
+Lindem, et al.               Standards Track                   [Page 12]
+
+RFC 7770               OSPF Capability Extensions          February 2016
+
+
+   [RFC-KEYWORDS]
+             Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119,
+             DOI 10.17487/RFC2119, March 1997,
+             <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
+             S. Shaffer, "Extensions to OSPF for Advertising Optional
+             Router Capabilities", RFC 4970, DOI 10.17487/RFC4970,
+             July 2007, <http://www.rfc-editor.org/info/rfc4970>.
+
+   [TE]      Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
+             (TE) Extensions to OSPF Version 2", RFC 3630,
+             DOI 10.17487/RFC3630, September 2003,
+             <http://www.rfc-editor.org/info/rfc3630>.
+
+6.2.  Informative References
+
+   [ENTERPRISE-CODE]
+             Eronen, P. and D. Harrington, "Enterprise Number for
+             Documentation Use", RFC 5612, DOI 10.17487/RFC5612,
+             August 2009, <http://www.rfc-editor.org/info/rfc5612>.
+
+   [EXP-TE]  Srisuresh, P. and P. Joseph, "OSPF-xTE: Experimental
+             Extension to OSPF for Traffic Engineering", RFC 4973,
+             DOI 10.17487/RFC4973, July 2007,
+             <http://www.rfc-editor.org/info/rfc4973>.
+
+   [GRACE]   Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF
+             Restart", RFC 3623, DOI 10.17487/RFC3623, November 2003,
+             <http://www.rfc-editor.org/info/rfc3623>.
+
+   [IANA-GUIDE]
+             Narten, T. and H. Alvestrand, "Guidelines for Writing an
+             IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+             DOI 10.17487/RFC5226, May 2008,
+             <http://www.rfc-editor.org/info/rfc5226>.
+
+   [P2PLAN]  Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point Operation
+             over LAN in Link State Routing Protocols", RFC 5309,
+             DOI 10.17487/RFC5309, October 2008,
+             <http://www.rfc-editor.org/info/rfc5309>.
+
+   [STUB]    Retana, A., Nguyen, L., Zinin, A., White, R., and D.
+             McPherson, "OSPF Stub Router Advertisement", RFC 6987,
+             DOI 10.17487/RFC6987, September 2013,
+             <http://www.rfc-editor.org/info/rfc6987>.
+
+
+
+
+Lindem, et al.               Standards Track                   [Page 13]
+
+RFC 7770               OSPF Capability Extensions          February 2016
+
+
+Acknowledgments
+
+   The idea for this work grew out of a conversation with Andrew Partan
+   and we thank him for his contribution.  The authors thank Peter
+   Psenak for his review and helpful comments on early draft versions of
+   the document.
+
+   Special thanks to Tom Petch for providing the updated IANA text in
+   this document.
+
+   Comments from Abhay Roy, Vishwas Manral, Vivek Dubey, and Adrian
+   Farrel have been incorporated into later draft versions of this
+   document.
+
+   Thanks to Yingzhen Qu for acting as document shepherd.
+
+   Thanks to Chris Bowers, Alia Atlas, Shraddha Hegde, Dan Romascanu,
+   and Victor Kuarsingh for review of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lindem, et al.               Standards Track                   [Page 14]
+
+RFC 7770               OSPF Capability Extensions          February 2016
+
+
+Authors' Addresses
+
+   Acee Lindem (editor)
+   Cisco Systems
+   301 Midenhall Way
+   Cary, NC  27513
+   United States
+
+   Email: acee@cisco.com
+
+
+   Naiming Shen
+   Cisco Systems
+   225 West Tasman Drive
+   San Jose, CA  95134
+   United States
+
+   Email: naiming@cisco.com
+
+
+   Jean-Philippe Vasseur
+   Cisco Systems
+   1414 Massachusetts Avenue
+   Boxborough, MA  01719
+   United States
+
+   Email: jpv@cisco.com
+
+
+   Rahul Aggarwal
+   Arktan
+
+   Email: raggarwa_1@yahoo.com
+
+
+   Scott Shaffer
+   Akamai
+   8 Cambridge Center
+   Cambridge, MA  02142
+   United States
+
+   Email: sshaffer@akamai.com
+
+
+
+
+
+
+
+
+
+Lindem, et al.               Standards Track                   [Page 15]
+