OSPFv3 Link State Advertisement (LSA) ExtensibilityCisco Systems301 Midenhall WayCaryNCUnited States of America27513acee@cisco.comCisco Systems170 Tasman DriveSan JoseCAUnited States of America95134akr@cisco.comNokiaCopernicuslaan 50Antwerp 2018Belgiumdirk.goethals@nokia.comBangaloreIndiavallem.veerendra@gmail.comSanta Barbara93117CaliforniaUnited States of AmericaFredBaker.IETF@gmail.comOSPFv3 requires functional extension beyond what can readily be done with the
fixed-format Link State Advertisement (LSA) as described in RFC 5340.
Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes
must be advertised in separate LSAs and correlated to the fixed-format LSAs.
This document extends the LSA format by encoding the existing OSPFv3 LSA
information in Type-Length-Value (TLV) tuples and allowing advertisement
of additional information with additional TLVs.
Backward-compatibility mechanisms are also described.This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address
Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support
and OSPFv3 address family support.OSPFv3 requires functional extension beyond what can readily be done with the
fixed-format Link State Advertisement (LSA) as described in RFC 5340 .
Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes
must be advertised in separate LSAs and correlated to the fixed-format LSAs.
This document extends the LSA format by encoding the existing OSPFv3 LSA
information in Type-Length-Value (TLV) tuples and allowing advertisement
of additional information with additional TLVs.
Backward-compatibility mechanisms are also described.This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address
Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 support
and OSPFv3 address family support .A similar extension was previously proposed in support of multi-topology routing.
Additional requirements for the OSPFv3 LSA extension include source/destination routing,
route tagging, and others.A final requirement is to limit the changes to OSPFv3 to those necessary for
TLV-based LSAs. For the most part, the semantics of existing OSPFv3 LSAs are retained for
their TLV-based successor LSAs described herein. Additionally, encoding details, e.g.,
the representation of IPv6 prefixes as described in Appendix A.4.1 in
RFC 5340 , have been retained. This requirement was included
to increase the expedience of IETF adoption and deployment.The following aspects of the OSPFv3 LSA extension are described:
Extended LSA TypesExtended LSA TLVsExtended LSA FormatsBackward CompatibilityThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.The TLV-based OSPFv3 LSAs described in this document will be referred to as
Extended LSAs. The OSPFv3 fixed-format LSAs will
be referred to as Legacy LSAs.In order to provide backward compatibility, new LSA codes must be allocated. There are eight
fixed-format LSAs defined in RFC 5340 . For ease of implementation and
debugging, the LSA function codes are the same as the fixed-format LSAs only with 32, i.e., 0x20, added.
The alternative to this mapping was to allocate a bit in the LS Type indicating the
new LSA format. However, this would have used one half the LSA function code space for the
migration of the eight original fixed-format LSAs. For backward compatibility, the U-bit MUST be
set in the LS Type so that the LSAs will be flooded by OSPFv3 routers that do not understand them.The format of the TLVs within the body of the Extended LSAs is the same as
the format used by the Traffic Engineering Extensions to OSPF .
The variable TLV section consists of one or more nested TLV
tuples. Nested TLVs are also referred to as sub-TLVs.
The format of each TLV is: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 32-bit
aligned. For example, a 1-byte 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.This document defines the following top-level TLV types:
0 - Reserved1 - Router-Link TLV2 - Attached-Routers TLV3 - Inter-Area-Prefix TLV4 - Inter-Area-Router TLV5 - External-Prefix TLV6 - Intra-Area-Prefix TLV7 - IPv6 Link-Local Address TLV8 - IPv4 Link-Local Address TLVAdditionally, this document defines the following sub-TLV types:
0 - Reserved1 - IPv6-Forwarding-Address sub-TLV2 - IPv4-Forwarding-Address sub-TLV3 - Route-Tag sub-TLVIn general, TLVs and sub-TLVs MAY occur in any order, and the specification
should define whether the TLV or sub-TLV is required and the behavior when
there are multiple occurrences of the TLV or sub-TLV. While this document only
describes the usage of TLVs and sub-TLVs, sub-TLVs may be nested to any
level as long as the sub-TLVs are fully specified in the specification for the
subsuming sub-TLV.
For backward compatibility, an LSA is not considered malformed from a TLV perspective
unless either a required TLV is missing or a specified TLV is less than the minimum
required length. Refer to for more information on TLV
backward compatibility.
The prefix options are extended from Appendix A.4.1.1 .
The applicability of the LA-bit is expanded, and it
SHOULD be set in Inter-Area-Prefix TLVs and MAY be set in External-Prefix TLVs when the
advertised host IPv6 address, i.e., PrefixLength = 128 for the IPv6 Address Family or PrefixLength = 32 for the
IPv4 Address Family , is an interface address. In RFC 5340,
the LA-bit is only set in Intra-Area-Prefix-LSAs (Section 4.4.3.9 of
). This will allow a stable address to be advertised without having
to configure a separate loopback address in every OSPFv3 area.Additionally, the N-bit prefix option is defined. The figure below shows the position
of the N-bit in the prefix options (value 0x20).
The N-bit is set in PrefixOptions for a host address
(PrefixLength=128 for the IPv6 Address Family or PrefixLength=32 for
the IPv4 Address Family ) that identifies the advertising router. While it is similar to the LA-bit,
there are two differences. The advertising router MAY choose NOT to set the N-bit even
when the above conditions are met. If the N-bit is set and the
PrefixLength is NOT 128 for the IPv6 Address Family or 32 for the IPv4 Address Family , the N-bit
MUST be ignored. Additionally, the N-bit is propagated
in the PrefixOptions when an OSPFv3 Area Border Router (ABR) originates an
Inter-Area-Prefix-LSA for an Intra-Area route that has the N-bit set in the PrefixOptions.
Similarly, the N-bit is propagated in the PrefixOptions when an OSPFv3 Not-So-Stubby Area (NSSA) ABR originates an
E-AS-External-LSA corresponding to an NSSA route as described in Section 3 of
RFC 3101 .
The N-bit is added to the Inter&nbhy;Area&nbhy;Prefix TLV (),
External-Prefix TLV (),
and Intra&nbhy;Area&nbhy;Prefix&nbhy;TLV (). The N-bit is used as hint
to identify the preferred address to reach the advertising OSPFv3 router. This would be in
contrast to an anycast address , which could also be a local address with
the LA&nbhy;bit set. It is useful for applications such as identifying the prefixes corresponding to
Node Segment Identifiers (SIDs) in Segment Routing . There may be
future applications requiring selection of a prefix associated with an OSPFv3 router.The Router-Link TLV defines a single router link, and the field
definitions correspond directly to links in the OSPFv3 Router-LSA;
see Appendix A.4.3 of . The Router-Link TLV is only
applicable to the E-Router-LSA ().
Inclusion in other Extended LSAs MUST be ignored.The Attached-Routers TLV defines all the routers attached to an OSPFv3
multi-access network. The field
definitions correspond directly to content of the OSPFv3 Network-LSA; see
Appendix A.4.4 of . The Attached-Routers TLV is only
applicable to the E&nbhy;Network&nbhy;LSA ().
Inclusion in other Extended LSAs MUST be ignored.There are two reasons for not having a separate TLV or sub-TLV for
each adjacent neighbor. The first is to discourage using the
E&nbhy;Network&nbhy;LSA for more than its current role of solely advertising
the routers attached to a multi-access network. The router's metric
as well as the attributes of individual attached routers should be advertised
in their respective E-Router-LSAs. The second reason is that
there is only a single E-Network-LSA per multi-access link
with the Link State ID set to the Designated Router's Interface ID,
and consequently, compact encoding has been chosen to
decrease the likelihood that the size of the E-Network-LSA will require
IPv6 fragmentation when advertised in an OSPFv3 Link State
Update packet.The Inter-Area-Prefix TLV defines a single OSPFV3 inter-area prefix.
The field definitions correspond directly to the content of an OSPFv3 IPv6 Prefix,
as defined in Appendix A.4.1 of , and an OSPFv3
Inter-Area-Prefix-LSA, as defined in Appendix A.4.5 of .
Additionally, the PrefixOptions are extended as described in
.
The Inter-Area-Prefix TLV is only
applicable to the E&nbhy;Inter&nbhy;Area&nbhy;Prefix&nbhy;LSA ().
Inclusion in other Extended LSAs MUST be ignored.The Inter-Area-Router TLV defines a single OSPFv3 Autonomous System
Boundary Router (ASBR) that is reachable in another area.
The field definitions correspond directly to the content of an
OSPFv3 Inter&nbhy;Area&nbhy;Router&nbhy;LSA, as
defined in Appendix A.4.6 of . The Inter-Area-Router TLV is only
applicable to the E&nbhy;Inter&nbhy;Area&nbhy;Router&nbhy;LSA ().
Inclusion in other Extended LSAs MUST be ignored.The External-Prefix TLV defines a single OSPFv3 external prefix.
With the exception of omitted fields noted below, the field definitions
correspond directly to the content of an OSPFv3 IPv6 Prefix,
as defined in Appendix A.4.1 of , and an OSPFv3 AS&nbhy;External&nbhy;LSA,
as defined in Appendix A.4.7 of . The External-Prefix TLV is only
applicable to the E-AS-External-LSA () and
the E-NSSA-LSA ().
Additionally, the PrefixOptions are extended as described in
.
Inclusion in other Extended LSAs MUST be ignored.In the External-Prefix TLV, the optional IPv6/IPv4 Forwarding Address and
External Route Tag are now sub-TLVs. Given
the Referenced LS Type and Referenced Link State ID from the
AS-External-LSA have never been used or even specified, they have
been omitted from the External-Prefix TLV. If there were ever
a requirement for a referenced LSA, it could be satisfied
with a sub-TLV.The following sub-TLVs are defined for optional inclusion in
the External-Prefix TLV:
1 - IPv6-Forwarding-Address sub-TLV ()2 - IPv4-Forwarding-Address sub-TLV ()3 - Route-Tag sub-TLV ()The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix.
The field definitions correspond directly to the content of an OSPFv3 IPv6 Prefix,
as defined in Appendix A.4.1 of , and an OSPFv3 Link-LSA, as
defined in Appendix A.4.9 of . The Intra&nbhy;Area&nbhy;Prefix TLV is only
applicable to the E-Link-LSA () and the
E-Intra-Area-Prefix-LSA ().
Additionally, the PrefixOptions are extended as described in
.
Inclusion in other Extended LSAs MUST be ignored.The IPv6 Link-Local Address TLV is to be used with IPv6 address families
as defined in .
The IPv6 Link-Local Address TLV is only applicable
to the E-Link-LSA (). Inclusion in other Extended
LSAs MUST be ignored.The IPv4 Link-Local Address TLV is to be used with IPv4 address families
as defined in .
The IPv4 Link-Local Address TLV is only applicable
to the E-Link-LSA (). Inclusion in other Extended
LSAs MUST be ignored.The IPv6-Forwarding-Address TLV has identical semantics
to the optional forwarding address in Appendix A.4.7 of
. The IPv6-Forwarding-Address TLV is
applicable to the External-Prefix TLV ().
Specification as a sub-TLV of other TLVs is not defined herein.
The sub-TLV is optional and the first specified instance is used
as the forwarding address as defined in .
Instances
subsequent to the first MUST be ignored.The IPv6-Forwarding-Address TLV is to be used with IPv6 address families
as defined in . It MUST be ignored for other
address families.
The IPv6-Forwarding-Address TLV length must meet a minimum
length (16 octets), or it will be considered malformed as described in
.
The IPv4-Forwarding-Address TLV has identical semantics
to the optional forwarding address in Appendix A.4.7 of
. The IPv4-Forwarding-Address TLV is
applicable to the External-Prefix TLV ().
Specification as a sub-TLV of other TLVs is not defined herein.
The sub-TLV is optional, and the first specified instance is used
as the forwarding address as defined in .
Instances
subsequent to the first MUST be ignored.The IPv4-Forwarding-Address TLV is to be used with IPv4 address families
as defined in . It MUST be ignored for other
address families.
The IPv4-Forwarding-Address TLV length must meet a minimum
length (4 octets), or it will be considered malformed as described in
.
The optional Route-Tag sub-TLV has identical semantics
to the optional External Route Tag in Appendix A.4.7 of
. The Route-Tag sub-TLV is
applicable to the External-Prefix TLV ().
Specification as a sub-TLV
of other TLVs is not defined herein. The sub-TLV is optional,
and the first specified instance is used as the Route Tag
as defined in . Instances
subsequent to the first MUST be ignored.The Route-Tag TLV length must meet a minimum
length (4 octets), or it will be considered malformed as described in
.
This section specifies the OSPFv3 Extended LSA formats and
encoding. The Extended OSPFv3 LSAs corresponded directly to the
original OSPFv3 LSAs specified in .The E-Router-LSA has an LS Type of 0xA021 and has
the same base information content as the Router-LSA defined in
Appendix A.4.3 of . However, unlike the existing
Router-LSA, it is fully extensible and represented as TLVs.Other than having a different LS Type, all LSA Header fields are
the same as defined for the Router-LSA.
Initially, only the top-level Router-Link TLV ()
is applicable, and an E-Router-LSA may include multiple
Router-Link TLVs. Like the existing Router-LSA, the LSA length is used to
determine the end of the LSA including any TLVs. Depending on the
implementation, it is perfectly valid for an E&nbhy;Router&nbhy;LSA to not
contain any Router-Link TLVs. However, this would imply that the
OSPFv3 router doesn't have any adjacencies in the corresponding
area and is forming an adjacency or adjacencies over an unnumbered
link(s). Note that no E-Router-LSA stub link is advertised for
an unnumbered link.
The E-Network-LSA has an LS Type of 0xA022 and has the same
base information content as the Network-LSA defined in Appendix A.4.4
of . However, unlike the existing Network-LSA,
it is fully extensible and represented as TLVs.Other than having a different LS Type, all LSA Header fields are
the same as defined for the Network-LSA.
Like the existing Network-LSA, the LSA length is used to determine
the end of the LSA including any TLVs.
Initially, only the top-level Attached-Routers TLV
() is applicable.
If the Attached-Router TLV is not included in the E-Network-LSA, it is
treated as malformed as described in .
Instances of the Attached-Router TLV subsequent to the first MUST be ignored.
The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same
base information content as the Inter-Area-Prefix-LSA defined in Appendix A.4.5 of
. However, unlike the existing Inter&nbhy;Area&nbhy;Prefix&nbhy;LSA,
it is fully extensible and represented as TLVs.Other than having a different LS Type, all LSA Header fields are
the same as defined for the Inter-Area-Prefix-LSA. In order to retain
compatibility and semantics
with the current OSPFv3 specification, each Inter-Area-Prefix LSA
MUST contain a single Inter-Area-Prefix TLV. This will
facilitate migration and avoid changes to functions such as
incremental Shortest Path First (SPF) computation.Like the existing Inter-Area-Prefix-LSA, the LSA length is used to determine
the end of the LSA including any TLVs.
Initially, only the top-level Inter-Area-Prefix TLV
() is applicable.
If the Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA,
it is treated as malformed as described in .
Instances of the
Inter-Area-Prefix TLV subsequent to the first MUST be ignored.
The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same base
information content as the Inter-Area-Router-LSA defined in Appendix A.4.6
of . However, unlike the Inter&nbhy;Area&nbhy;Router&nbhy;LSA, it is
fully extensible and represented as TLVs.Other than having a different LS Type, all LSA Header fields are the
same as defined for the Inter-Area-Router-LSA. In order to retain
compatibility and semantics
with the current OSPFv3 specification, each Inter-Area-Router-LSA
MUST contain a single Inter-Area-Router TLV. This will
facilitate migration and avoid changes to functions such as
incremental SPF computation.Like the existing Inter-Area-Router-LSA, the LSA length is used to determine
the end of the LSA including any TLVs.
Initially, only the top-level Inter-Area-Router TLV
() is applicable.
If the Inter-Area-Router TLV is not included in the E-Inter-Area-Router-LSA, it is
treated as malformed as described in .
Instances of the
Inter-Area-Router TLV subsequent to the first MUST be ignored.
The E-AS-External-LSA has an LS Type of 0xC025 and has the same base
information content as the AS-External-LSA defined in Appendix A.4.7 of
. However, unlike the existing AS-External-LSA, it is
fully extensible and represented as TLVs.Other than having a different LS Type, all LSA Header fields are the same
as defined for the AS-External-LSA.
In order to retain compatibility and semantics with the current
OSPFv3 specification, each LSA MUST contain a single
External-Prefix TLV. This will facilitate migration and avoid
changes to OSPFv3 functions such as incremental SPF computation.Like the existing AS-External-LSA, the LSA length is used
to determine the end of the LSA including any TLVs.
Initially, only the top-level External-Prefix TLV
() is applicable.
If the External-Prefix TLV is not included in the E-External-AS-LSA, it is
treated as malformed as described in .
Instances of the
External-Prefix TLV subsequent to the first MUST be ignored.
The E-NSSA-LSA will have the same format and TLVs
as the Extended AS&nbhy;External&nbhy;LSA ().
This is the same relationship that exists
between the NSSA-LSA, as defined in Appendix A.4.8 of ,
and the AS-External-LSA. The
NSSA-LSA will have type 0xA027, which implies area flooding scope.
Future requirements may dictate that supported TLVs differ between the
E-AS-External-LSA and the E-NSSA-LSA. However, future requirements are
beyond the scope of this document.The E-Link-LSA has an LS Type of 0x8028 and will have the same
base information content as the Link-LSA defined in Appendix A.4.9 of
. However, unlike the existing Link-LSA, it
is fully extensible and represented as TLVs.Other than having a different LS Type, all LSA Header fields are the same
as defined for the Link-LSA.Only the Intra-Area-Prefix TLV (),
IPv6 Link-Local Address TLV (),
and IPv4 Link-Local Address TLV ()
are applicable to the E-Link-LSA.
Like the Link-LSA, the E-Link-LSA affords advertisement
of multiple intra-area prefixes. Hence, multiple Intra-Area-Prefix TLVs
()
may be specified, and the LSA length defines the end of the LSA including
any TLVs.A single instance of the
IPv6 Link-Local Address TLV ()
SHOULD be included in the E-Link-LSA.
Instances following the first MUST be ignored.
For IPv4 address families
as defined in , this TLV MUST be ignored.Similarly, only a single instance of the
IPv4 Link-Local Address TLV ()
SHOULD be included in the E-Link-LSA.
Instances following the first MUST be ignored. For OSPFv3 IPv6 address
families as defined in , this TLV SHOULD be ignored.If the IPv4/IPv6 Link-Local Address TLV corresponding to the OSPFv3 Address Family
is not included in the E-Link-LSA, it is
treated as malformed as described in .Future specifications may support advertisement of routing and topology
information for multiple address families. However, this is beyond
the scope of this document.The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same base
information content as the Intra-Area-Prefix-LSA defined in
Appendix A.4.10 of except for the Referenced LS Type.
However, unlike the Intra-Area-Prefix-LSA, it is fully extensible and represented
as TLVs. The Referenced LS Type MUST be either an E&nbhy;Router&nbhy;LSA (0xA021) or an
E-Network-LSA (0xA022).Other than having a different LS Type, all LSA Header fields are the same
as defined for the Intra-Area-Prefix-LSA.Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords advertisement
of multiple intra-area prefixes. Hence, multiple Intra-Area-Prefix TLVs
may be specified, and the LSA length defines the end of the LSA including
any TLVs.Extended LSAs that have inconsistent length or other encoding errors, as described
herein, MUST NOT be installed in the Link State Database, acknowledged, or flooded. Reception
of malformed LSAs SHOULD be counted and/or logged for examination by the administrator
of the OSPFv3 routing domain. Note that for the purposes of length validation, a TLV
or sub-TLV should not be considered invalid unless the length exceeds the length of the
LSA or does not meet the minimum length requirements for the TLV or sub-TLV. This allows for sub-TLVs to
be added as described in .Additionally, an LSA MUST be considered malformed if it does not include all of
the required TLVs and sub-TLVs.In the context of this document, backward compatibility is solely related to the
capability of an OSPFv3 router to receive, process, and originate the TLV-based LSAs defined
herein. Unrecognized TLVs and sub-TLVs are ignored.
Backward compatibility for future OSPFv3 extensions utilizing the TLV-based LSAs is
out of scope and must be covered in the documents describing those extensions. Both full
and, if applicable, partial deployment SHOULD be specified for future TLV-based OSPFv3 LSA
extensions.If ExtendedLSASupport is enabled (), OSPFv3 Extended LSAs will
be originated and used for the SPF computation. Individual OSPF Areas can be migrated separately
with the Legacy AS-External-LSAs being originated and used for the
SPF computation. This is accomplished by enabling AreaExtendedLSASupport
().An OSPFv3 routing domain or area may be non-disruptively migrated using separate OSPFv3 instances
for the Extended LSAs. Initially, the OSPFv3 instances with ExtendedLSASupport will have a lower
preference, i.e., higher administrative distance, than the OSPFv3 instances originating and
using the Legacy LSAs. Once the routing domain or area is fully migrated and the OSPFv3
Routing Information Bases (RIBs) have been verified, the OSPFv3 instances using the Extended LSAs
can be given preference. When this has been completed and the routing within the OSPF routing domain
or area has been verified, the original OSPFv3 instance using Legacy LSAs can be removed.In this mode, OSPFv3 will use the Legacy LSAs for the SPF computation and will only originate
Extended LSAs when LSA origination is required in support of additional functionality. Furthermore, those
Extended LSAs will only include the top-level TLVs (e.g., Router-Link TLVs or Inter-Area TLVs), which
are required for that new functionality. However, if a top-level TLV is advertised,
it MUST include required sub-TLVs, or it will be considered malformed as described in
.
Hence, this mode of compatibility is known as "sparse-mode". The advantage of sparse-mode is that
functionality utilizing the OSPFv3 Extended LSAs can be added to an existing OSPFv3 routing domain
without the requirement for migration. In essence, this compatibility mode is very much like
the approach taken for OSPFv2 . As with all the compatibility
modes, backward compatibility for the functions utilizing the Extended LSAs must be described
in the IETF documents describing those functions.This section defines the general rules for processing LSA TLVs. To ensure compatibility of
future TLV-based LSA extensions, all implementations MUST adhere to these rules:
Unrecognized TLVs and sub-TLVs are ignored when parsing or processing Extended LSAs.Whether or not partial deployment of a given TLV is supported MUST be specified.If partial deployment is not supported, mechanisms to ensure the corresponding feature
is not deployed MUST be specified in the document defining the new TLV or sub-TLV.If partial deployment is supported, backward compatibility and partial deployment MUST
be specified in the document defining the new TLV or sub-TLV.If a TLV or sub-TLV is recognized but the length is less than the minimum, then the LSA
should be considered malformed, and it SHOULD NOT be acknowledged. Additionally, the
occurrence SHOULD be logged with enough information to identify the LSA by type, Link State ID, originator,
and sequence number and identify the TLV or sub-TLV in error.
Ideally, the log entry would include
the hexadecimal or binary representation of the LSA including the malformed
TLV or sub-TLV.Documents specifying future TLVs or Sub-TLVs MUST specify the requirements for usage of
those TLVs or sub-TLVs.Future TLVs or sub-TLVs must be optional. However, there may be requirements for sub-TLVs if
an optional TLV is specified.In general, extensible OSPFv3 LSAs are subject to the same security concerns as those described
in RFC 5340 . Additionally, implementations must assure that malformed
TLV and sub-TLV permutations do not result in errors that cause hard OSPFv3 failures.If there were ever a requirement to digitally sign OSPFv3 LSAs as described for OSPFv2 LSAs
in RFC 2154 , the mechanisms described herein would greatly
simplify the extension.This specification defines nine OSPFv3 Extended LSA types as described
in . These have been added to the existing OSPFv3 LSA Function
Codes registry.The specification defines a code point for
the N-bit in the OSPFv3 Prefix-Options registry. The value 0x20 has been assigned.This specification also creates two registries for OSPFv3 Extended LSA TLVs and sub-TLVs.
The TLV and sub-TLV code points in these registries are common to all Extended LSAs, and their
respective definitions must define where they are applicable.The "OSPFv3 Extended LSA TLVs" registry defines top-level TLVs for Extended LSAs and
has been placed in the existing OSPFv3 IANA registry.Nine values have been allocated:
0 - Reserved1 - Router-Link TLV2 - Attached-Routers TLV3 - Inter-Area-Prefix TLV4 - Inter-Area-Router TLV5 - External-Prefix TLV6 - Intra-Area-Prefix TLV7 - IPv6 Link-Local Address TLV8 - IPv4 Link-Local Address TLVTypes in the range 9-32767 are allocated via IETF Review or
IESG Approval .Types in the range 32768-33023 are Reserved for Experimental Use; these will
not be registered with IANA and MUST NOT be mentioned by RFCs.Types in the range 33024-45055 are to be assigned on a
First Come First Served (FCFS) basis.Types in the range 45056-65535 are not to be assigned at this time.
Before any assignments can be made in the 33024-65535 range, there MUST
be an IETF specification that specifies IANA Considerations that cover
the range being assigned.The "OSPFv3 Extended LSA Sub-TLVs" registry defines sub-TLVs at any level of
nesting for Extended LSAs and
has been placed in the existing OSPFv3 IANA registry.Four values have been allocated:
0 - Reserved1 - IPv6-Forwarding-Address sub-TLV2 - IPv4-Forwarding-Address sub-TLV3 - Route-Tag sub-TLVTypes in the range 4-32767 are allocated via IETF Review or
IESG Approval.Types in the range 32768-33023 are Reserved for Experimental Use; these will
not be registered with IANA and MUST NOT be mentioned by RFCs.Types in the range 33024-45055 are to be assigned on
an FCFS basis.Types in the range 45056-65535 are not to be assigned at this time.
Before any assignments can be made in the 33024-65535 range, there MUST
be an IETF specification that specifies IANA Considerations that cover
the range being assigned.OSPF for IPv6Acoustra ProductionssJuniper Network, IncSycamore Systems, IncRedback NetworksSupport of Address Families in OSPFv3Traffic Engineering (TE) Extensions to OSPF Version 2Juniper NetworksJuniper NetworksProcket NetworksThe OSPF Not-So-Stubby Area (NSSA) OptionUS Geological SurveyOSPF with Digital SignaturesTrusted Information SystemsTrusted Information SystemsTrusted Information SystemsMulti-topology routing in OSPFv3 (MT-OSPFv3)IP Version 6 Addressing ArchitectureNokiaCisco SystemsOSPFv3 Extensions for Segment RoutingOSPFv2 Prefix/Link Attribute AdvertisementCisco SystemsJuniper NetworksIndividual ContributerAlcatel-LucentEricssonCisco SystemsThe global configurable parameter ExtendedLSASupport is added to the
OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 router will originate
OSPFv3 Extended LSAs and use the LSAs for the SPF computation. If ExtendedLSASupport is
not enabled, a subset of OSPFv3 Extended LSAs may still be originated and used for other
functions as described in .The area configurable parameter AreaExtendedLSASupport is added to the
OSPFv3 protocol. If AreaExtendedLSASupport is enabled, the OSPFv3 router will originate
link and area OSPFv3 Extended LSAs and use the LSAs for the SPF computation.
Legacy AS-Scoped LSAs will still be originated and used for the AS-External-LSA
computation. If AreaExtendedLSASupport is
not enabled, a subset of OSPFv3 link and area Extended LSAs may still be originated and
used for other functions as described in .For regular areas, i.e., areas where AS-scoped LSAs are flooded, disabling
AreaExtendedLSASupport for a regular OSPFv3 area (not a Stub or NSSA area)
when ExtendedLSASupport is enabled is contradictory and
SHOULD be prohibited by implementations.OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing in
OSPFv3 (MT-OSPFv3)" .Thanks for Peter Psenak for significant contributions to the backward-compatibility
mechanisms.Thanks go to Michael Barnes, Mike Dubrovsky, Anton Smirnov, and Tony Przygienda for
review of the draft versions and discussions of backward compatibility.Thanks to Alan Davey for review and comments including the suggestion to separate
the Extended LSA TLV definitions from the Extended LSAs definitions.Thanks to David Lamparter for review and suggestions on
backward compatibility.Thanks to Karsten Thomann, Chris Bowers, Meng Zhang, and Nagendra Kumar for review
and editorial comments.Thanks to Alia Atlas for substantive Routing Area Director (AD) comments prior
to IETF last call.Thanks to Alvaro Retana and Suresh Krishnan for substantive comments during
IESG Review.Thanks to Mehmet Ersue for the Operations and Management (OPS) Directorate review.