Network Working GroupInternet Engineering Task Force (IETF) A. LindemInternet-DraftRequest for Comments: 8362 A. Roy Updates: 5340, 5838(if approved)Cisco SystemsIntended status:Category: Standards Track D. GoethalsExpires: July 29, 2018ISSN: 2070-1721 Nokia V. Reddy Vallem F. BakerJanuary 25,March 2018 OSPFv3LSA Extendibility draft-ietf-ospf-ospfv3-lsa-extend-23.txtLink State Advertisement (LSA) Extensibility Abstract 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 compatibilityBackward-compatibility mechanisms are also described. This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families inOSPFv3"OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support. Status of This Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 29, 2018.https://www.rfc-editor.org/info/rfc8362. Copyright Notice Copyright (c) 2018 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)(https://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. RequirementsnotationNotation . . . . . . . . . . . . . . . . . . 4 1.2. OSPFv3 LSA Terminology . . . . . . . . . . . . . . . . . 4 2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 4 3. OSPFv3 Extended LSA TLVs . . . . . . . . . . . . . . . . . . 5 3.1. Prefix Options Extensions . . . . . . . . . . . . . . . . 6 3.1.1. N-bit Prefix Option . . . . . . . . . . . . . . . . . 6 3.2. Router-Link TLV . . . . . . . . . . . . . . . . . . . . . 7 3.3. Attached-Routers TLV . . . . . . . . . . . . . . . . . . 8 3.4. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . .109 3.5. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . .1110 3.6. External-Prefix TLV . . . . . . . . . . . . . . . . . . .1211 3.7. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . .1312 3.8. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . .1413 3.9. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . .1514 3.10. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . .1615 3.11. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . .1615 3.12. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . .1716 4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . .1716 4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . .1716 4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . .1918 4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . .2019 4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . .2120 4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . .2221 4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . .2322 4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . .2423 4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . .2625 5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . .2726 6. LSA Extension Backward Compatibility . . . . . . . . . . . .2726 6.1. Full Extended LSA Migration . . . . . . . . . . . . . . .2726 6.2. Extended LSA Sparse-Mode Backward Compatibility . . . . .2827 6.3. LSA TLV Processing Backward Compatibility . . . . . . . .2827 7. Security Considerations . . . . . . . . . . . . . . . . . . .2928 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . .2928 8.1. OSPFv3Extended-LSAExtended LSA TLV Registry . . . . . . . . . . . .2928 8.2. OSPFv3Extended-LSA sub-TLVExtended LSA Sub-TLV Registry . . . . . . . . . .3029 9.ContributorsReferences . . . . . . . . . . . . . . . . . . . . . . . .31 10.. 30 9.1. Normative References . . . . . . . . . . . . . . . . . . 30 9.2. Informative References . . . . . . . .31 10.1. Normative References. . . . . . . . . 30 Appendix A. Global Configuration Parameters . . . . . . . . . . 3110.2. Informative ReferencesAppendix B. Area Configuration Parameters . . . . . . . . . . . 31 Acknowledgments . . . . . . . . . . . . . . . .31 Appendix A. Appendix A - Global Configuration Parameters. . . .32 Appendix B. Appendix B - Area Configuration Parameters. . . . . 32Appendix C. AcknowledgmentsContributors . . . . . . . . . . . . . . . . . .33. . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .3332 1. Introduction OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340 [OSPFV3]. 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 compatibilityBackward-compatibility mechanisms are also described. This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families inOSPFv3"OSPFv3", by providing TLV-based encodings for the base OSPFv3 support [OSPFV3] and OSPFv3 address family support [OSPFV3-AF]. 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 insectionAppendix A.4.1 in RFC 5340 [OSPFV3], 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: 1. Extended LSA Types 2. Extended LSA TLVs 3. Extended LSA Formats 4. Backward Compatibility 1.1. RequirementsnotationNotation The 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. OSPFv3 LSA Terminology The TLV-based OSPFv3 LSAs described in this document will be referred to as Extended LSAs. The OSPFv3 fixed-format LSAs [OSPFV3] will be referred to as Legacy LSAs. 2. OSPFv3 Extended LSA Types In order to provide backward compatibility, new LSA codes must be allocated. There are eight fixed-format LSAs defined in RFC 5340 [OSPFV3]. 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. LSA function code LS Type Description ---------------------------------------------------- 33 0xA021 E-Router-LSA 34 0xA022 E-Network-LSA 35 0xA023 E-Inter-Area-Prefix-LSA 36 0xA024 E-Inter-Area-Router-LSA 37 0xC025 E-AS-External-LSA 38 N/A Unused (Not to be allocated) 39 0xA027 E-Type-7-LSA 40 0x8028 E-Link-LSA 41 0xA029 E-Intra-Area-Prefix-LSA OSPFv3 Extended LSA Types 3. OSPFv3 Extended LSA TLVs The format of the TLVs within the body of theextendedExtended LSAs is the same as the format used by the Traffic Engineering Extensions to OSPF [TE]. The variable TLV section consists of one or more nestedType/Length/Value (TLV)TLV tuples. Nested TLVs are also referred to as sub-TLVs. 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... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 thelengthLength 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 thelengthLength 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: o 0 - Reserved o 1 - Router-Link TLV o 2 - Attached-Routers TLV o 3 -Inter-Area PrefixInter-Area-Prefix TLV o 4 -Inter-Area RouterInter-Area-Router TLV o 5 -External PrefixExternal-Prefix TLV o 6 -Intra-Area PrefixIntra-Area-Prefix TLV o 7 - IPv6 Link-Local Address TLV o 8 - IPv4 Link-Local Address TLV Additionally, this document defines the following sub-TLV types: o 0 - Reserved o 1 -IPv6 Forwarding AddressIPv6-Forwarding-Address sub-TLV o 2 -IPv4 Forwarding AddressIPv4-Forwarding-Address sub-TLV o 3 -Route TagRoute-Tag sub-TLV In general, TLVs and sub-TLVs MAY occur in anyorderorder, 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 andSub-TLVs, Sub-TLVssub-TLVs, sub-TLVs may be nested to any level as long as theSub-TLVssub-TLVs are fully specified in the specification for the subsumingSub-TLV.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 Section 6.3 for more information on TLV backward compatibility. 3.1. Prefix Options Extensions The prefix options are extended from Appendix A.4.1.1 [OSPFV3]. The applicability of the LA-bit isexpandedexpanded, and it SHOULD be set inInter-Area-Prefix-TLVsInter-Area-Prefix TLVs and MAY be set inExternal-Prefix-TLVsExternal-Prefix TLVs when the advertised host IPv6 address, i.e., PrefixLength =128,128 for the IPv6 Address Family or PrefixLength = 32 for the IPv4 Address Family [OSPFV3-AF], is an interface address. In RFC 5340, the LA-bit is only set inIntra- Area-Prefix-LSAsIntra-Area-Prefix-LSAs (Section 4.4.3.9inof [OSPFV3]). This will allow a stable address to be advertised without having to configure a separate loopback address in every OSPFv3 area. 3.1.1. N-bit Prefix Option Additionally, the N-bit prefix option is defined. The figure below shows the position of the N-bit in the prefix options(pending IANA allocation). This corresponds to the value 0x20.(value 0x20). 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | | | N|DN| P| x|LA|NU| +--+--+--+--+--+--+--+--+ The Prefix OptionsfieldField The N-bit is set in PrefixOptions for a host address(PrefixLength=128)(PrefixLength=128 for the IPv6 Address Family or PrefixLength=32 for the IPv4 Address Family [OSPFV3-AF]) 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 NOT128,128 for the IPv6 Address Family or 32 for the IPv4 Address Family [OSPFV3-AF], 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 routewhichthat has the N-bit set in the PrefixOptions. Similarly, the N-bit is propagated in the PrefixOptions when an OSPFv3NSSANot-So-Stubby Area (NSSA) ABR originates an E-AS-External-LSA corresponding to an NSSA route as described insectionSection 3 of RFC 3101([NSSA]).[NSSA]. The N-bit is added to theInter-Area-Prefix-TLVInter-Area-Prefix TLV (Section 3.4),External-Prefix-TLVExternal-Prefix TLV (Section 3.6), andIntra-Area- Prefix-TLVIntra-Area-Prefix-TLV (Section 3.7). The N-bit is used as hint to identify the preferred address to reach the advertising OSPFv3 router. This would be in contrast to anAnycast Address [IPV6-ADDRESS-ARCH]anycast address [IPV6-ADDRESS-ARCH], which could also be a local address with the LA-bit set. It is useful for applications such as identifying the prefixes corresponding to Node Segment Identifiers (SIDs) in Segment Routing [SEGMENT-ROUTING]. There may be future applications requiring selection of a prefix associated with an OSPFv3 router. 3.2. Router-Link TLV The Router-Link TLV defines a single routerlinklink, and the field definitions correspond directly to links in the OSPFv3Router-LSA, section A.4.3,Router-LSA; see Appendix A.4.3 of [OSPFV3]. The Router-Link TLV is only applicable to the E-Router-LSA (Section 4.1). Inclusion in other Extended LSAs MUST be ignored. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 (Router-Link) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | 0 | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .sub-TLVsSub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Router-Link TLV 3.3. Attached-Routers TLV The Attached-Routers TLV defines all the routers attached to an OSPFv3 multi-access network. The field definitions correspond directly to content of the OSPFv3Network-LSA, section A.4.4,Network-LSA; see Appendix A.4.4 of [OSPFV3]. The Attached-Routers TLV is only applicable to theE- Network-LSAE-Network-LSA (Section 4.2). Inclusion in other Extended LSAs MUST be ignored. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 (Attached-Routers) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adjacent Neighbor Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Additional Adjacent Neighbors . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attached-Routers TLV There are two reasons for not having a separate TLV or sub-TLV for each adjacent neighbor. The first is to discourage using theE- Network-LSAE-Network-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 InterfaceID and,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. 3.4. Inter-Area-Prefix TLV The Inter-Area-Prefix TLV defines a single OSPFV3 inter-area prefix. The field definitions correspond directly to the content of an OSPFv3 IPv6PrefixPrefix, as defined inSection A.4.1, [OSPFV3]Appendix A.4.1 of [OSPFV3], and an OSPFv3 Inter-Area-Prefix-LSA, as defined insection A.4.5,Appendix A.4.5 of [OSPFV3]. Additionally, the PrefixOptions are extended as described in Section 3.1. The Inter-Area-Prefix TLV is only applicable to theE- Inter-Area-Prefix-LSAE-Inter-Area-Prefix-LSA (Section 4.3). Inclusion in other Extended LSAs MUST be ignored. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (Inter-Area Prefix) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | PrefixOptions | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .sub-TLVsSub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Inter-Area PrefixInter-Area-Prefix TLV 3.5. Inter-Area-Router TLV 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 OSPFv3Inter- Area-Router-LSA,Inter-Area-Router-LSA, as defined insection A.4.6,Appendix A.4.6 of [OSPFV3]. TheInter- Area-RouterInter-Area-Router TLV is only applicable to the E-Inter-Area-Router-LSA (Section 4.4). Inclusion in other Extended LSAs MUST be ignored. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 (Inter-Area Router) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .sub-TLVsSub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Inter-Area RouterInter-Area-Router TLV 3.6. External-Prefix TLV 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 IPv6PrefixPrefix, as defined inSection A.4.1, [OSPFV3]Appendix A.4.1 of [OSPFV3], and an OSPFv3AS- External-LSA,AS-External-LSA, as defined insection A.4.7,Appendix A.4.7 of [OSPFV3]. TheExternal- PrefixExternal-Prefix TLV is only applicable to the E-AS-External-LSA (Section 4.5) and the E-NSSA-LSA (Section 4.6). Additionally, the PrefixOptions are extended as described in Section 3.1. Inclusion in other Extended LSAs MUST be ignored. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 (External Prefix) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |E| | | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | PrefixOptions | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .sub-TLVsSub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+External PrefixExternal-Prefix TLV In the External-Prefix TLV, the optional IPv6/IPv4 Forwarding Address and External Route Tag are now sub-TLVs. Given the Referenced LStypeType and Referenced Link State ID from the AS-External-LSA have never been used or even specified, they have been omitted from theExternal PrefixExternal-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 theExternal PrefixExternal-Prefix TLV: o 1 -IPv6 Forwarding AddressIPv6-Forwarding-Address sub-TLV (Section 3.10) o 2 -IPv4 Forwarding AddressIPv4-Forwarding-Address sub-TLV (Section 3.11) o 3 -Route TagRoute-Tag sub-TLV (Section 3.12) 3.7. Intra-Area-Prefix TLV The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix. The field definitions correspond directly to the content of an OSPFv3 IPv6PrefixPrefix, as defined inSection A.4.1, [OSPFV3]Appendix A.4.1 of [OSPFV3], and an OSPFv3Link- LSA,Link-LSA, as defined insection A.4.9,Appendix A.4.9 of [OSPFV3]. The Intra-Area-Prefix TLV is only applicable to the E-Link-LSA (Section 4.7) and theE- Intra-Area-Prefix-LSAE-Intra-Area-Prefix-LSA (Section 4.8). Additionally, the PrefixOptions are extended as described in Section 3.1. Inclusion in other Extended LSAs MUST be ignored. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 (Intra-Area Prefix) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | PrefixOptions | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .sub-TLVsSub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Intra-Area PrefixIntra-Area-Prefix TLV 3.8. IPv6 Link-Local Address TLV The IPv6 Link-Local Address TLV is to be used with IPv6 address families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV is only applicable to the E-Link-LSA (Section 4.7). Inclusion in other Extended LSAs MUST be ignored. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 (IPv6 Local-Local Address) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- IPv6 Link-Local Interface Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .sub-TLVsSub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Link-Local Address TLV 3.9. IPv4 Link-Local Address TLV The IPv4 Link-Local Address TLV is to be used with IPv4 address families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV is only applicable to the E-Link-LSA (Section 4.7). Inclusion in other Extended LSAs MUST be ignored. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 8 (IPv4 Local-Local Address) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Link-Local Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .sub-TLVsSub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Link-Local Address TLV 3.10. IPv6-Forwarding-Address Sub-TLV TheIPv6 Forwarding AddressIPv6-Forwarding-Address TLV has identical semantics to the optional forwarding address insectionAppendix A.4.7 of [OSPFV3]. TheIPv6 Forwarding AddressIPv6- Forwarding-Address TLV is applicable to the External-Prefix TLV (Section 3.6). 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 theForwarding Addressforwarding address as defined in [OSPFV3]. Instances subsequent to the first MUST be ignored. TheIPv6 Forwarding AddressIPv6-Forwarding-Address TLV is to be used with IPv6 address families as defined in[OSPFV3-AF][OSPFV3-AF]. It MUST be ignored for other address families. TheIPv6 Forwarding AddressIPv6-Forwarding-Address TLV length must meet a minimum length (16octets)octets), or it will be considered malformed as described in Section 6.3. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 - Forwarding Address | sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- Forwarding Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IPv6 Forwarding AddressIPv6-Forwarding-Address TLV 3.11. IPv4-Forwarding-Address Sub-TLV TheIPv4 Forwarding AddressIPv4-Forwarding-Address TLV has identical semantics to the optional forwarding address insectionAppendix A.4.7 of [OSPFV3]. TheIPv4 Forwarding Address TLV is The IPv4 Forwarding AddressIPv4- Forwarding-Address TLV is applicable to the External-Prefix TLV (Section 3.6). Specification as a sub-TLV of other TLVs is not defined herein. The sub-TLV isoptionaloptional, and the first specified instance is used as theForwarding Addressforwarding address as defined in [OSPFV3]. Instances subsequent to the first MUST be ignored. TheIPv4 Forwarding AddressIPv4-Forwarding-Address TLV is to be used with IPv4 address families as defined in[OSPFV3-AF][OSPFV3-AF]. It MUST be ignored for other address families. TheIPv4 Forwarding AddressIPv4-Forwarding-Address TLV length must meet a minimum length (4octets)octets), or it will be considered malformed as described in Section 6.3. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 - Forwarding Address | sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarding Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IPv4 Forwarding AddressIPv4-Forwarding-Address TLV 3.12. Route-Tag Sub-TLV The optionalRoute TagRoute-Tag sub-TLV has identical semantics to the optional External Route Tag insectionAppendix A.4.7 of [OSPFV3]. TheRoute TagRoute-Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.6). Specification as a sub-TLV of other TLVs is not defined herein. The sub-TLV isoptionaloptional, and the first specified instance is used as the Route Tag as defined in [OSPFV3]. Instances subsequent to the first MUST be ignored. TheRoute TagRoute-Tag TLV length must meet a minimum length (4octets)octets), or it will be considered malformed as described in Section 6.3. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 - Route Tag | sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Route TagRoute-Tag Sub-TLV 4. OSPFv3 Extended LSAs This section specifies the OSPFv3 Extended LSA formats and encoding. The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3 LSAs specified in [OSPFV3]. 4.1. OSPFv3 E-Router-LSA The E-Router-LSA has an LS Type of 0xA021 and has the same base information content as the Router-LSA defined insectionAppendix A.4.3 of [OSPFV3]. However, unlike the existing Router-LSA, it is fullyextendableextensible and represented as TLVs. 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|0|1| 0x21 | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Checksum | Length | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |Nt|x|V|E|B| Options | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extended Router-LSA 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 TLVSection 3.2(Section 3.2) isapplicableapplicable, 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 anE- Router-LSAE-Router-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. 4.2. OSPFv3 E-Network-LSA The E-Network-LSA has an LS Type of 0xA022 and has the same base information content as the Network-LSA defined insectionAppendix A.4.4 of [OSPFV3]. However, unlike the existing Network-LSA, it is fullyextendableextensible and represented as TLVs. 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|0|1| 0x22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E-Network-LSA 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 TLVSection 3.3(Section 3.3) is applicable. If the Attached-Router TLV is not included in theE- Network-LSA,E-Network-LSA, it is treated as malformed as described in Section 5. Instances of the Attached-Router TLV subsequent to the first MUST be ignored. 4.3. OSPFv3 E-Inter-Area-Prefix-LSA 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 insectionAppendix A.4.5 of [OSPFV3]. However, unlike the existingInter-Area- Prefix-LSA,Inter-Area-Prefix-LSA, it is fullyextendableextensible and represented as TLVs. 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|0|1| 0x23 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E-Inter-Area-Prefix-LSA 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 singleInter-Area PrefixInter-Area-Prefix TLV. This will facilitate migration and avoid changes to functions such as incrementalSPFShortest Path First (SPF) computation. Like the existing Inter-Area-Prefix-LSA, the LSA length is used to determine the end of the LSA includingTLV.any TLVs. Initially, only thetop- leveltop-level Inter-Area-Prefix TLV (Section 3.4) 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 Section 5. Instances of the Inter-Area-Prefix TLV subsequent to the first MUST be ignored. 4.4. OSPFv3 E-Inter-Area-Router-LSA 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 insectionAppendix A.4.6 of [OSPFV3]. However, unlike theInter-Area-Router- LSA,Inter-Area-Router-LSA, it is fullyextendableextensible and represented as TLVs. 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|0|1| 0x24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E-Inter-Area-Router-LSA 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, eachInter-Area-Router LSAInter-Area-Router-LSA MUST contain a singleInter-Area RouterInter-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 includingTLV.any TLVs. Initially, only thetop- leveltop-level Inter-Area-Router TLV (Section 3.5) 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 Section 5. Instances of the Inter-Area-Router TLV subsequent to the first MUST be ignored. 4.5. OSPFv3 E-AS-External-LSA The E-AS-External-LSA has an LS Type of 0xC025 and has the same base information content as the AS-External-LSA defined insectionAppendix A.4.7 of [OSPFV3]. However, unlike the existing AS-External-LSA, it is fullyextendableextensible and represented as TLVs. 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|1|0| 0x25 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E-AS-External-LSA 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 singleExternal PrefixExternal-Prefix TLV. This will facilitate migration and avoid changes to OSPFv3processesfunctions such as incremental SPF computation. Like the existing AS-External-LSA, the LSA length is used to determine the end of the LSA includingsub-TLVs.any TLVs. Initially, only the top-level External-Prefix TLV (Section 3.6) is applicable. If the External-Prefix TLV is not included in the E-External-AS-LSA, it is treated as malformed as described in Section 5. Instances of the External-Prefix TLV subsequent to the first MUST be ignored. 4.6. OSPFv3 E-NSSA-LSA The E-NSSA-LSA will have the same format and TLVs as the ExtendedAS- External-LSA Section 4.5.AS-External-LSA (Section 4.5). This is the same relationshipasthat exists between theNSSA-LSANSSA-LSA, as defined insectionAppendix A.4.8 of [OSPFV3], and the AS-External-LSA. The NSSA-LSA will have type0xA0270xA027, 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. 4.7. OSPFv3 E-Link-LSA The E-Link-LSA has an LS Type of 0x8028 and will have the same base information content as the Link-LSA defined insectionAppendix A.4.9 of [OSPFV3]. However, unlike the existing Link-LSA, it isextendablefully extensible and represented as TLVs. 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|0|0| 0x28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rtr Priority | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E-Link-LSA 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 (Section 3.7), IPv6 Link-Local Address TLV (Section 3.8), and IPv4 Link-Local Address TLV (Section 3.9) are applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA affords advertisement of multiple intra-area prefixes. Hence, multipleIntra-Area PrefixIntra-Area-Prefix TLVs (Section 3.7) may bespecifiedspecified, and the LSA length defines the end of the LSA includingallany TLVs. A single instance of the IPv6 Link-Local Address TLV (Section 3.8) SHOULD be included in the E-Link-LSA. Instances following the first MUST be ignored. For IPv4 address families as defined in [OSPFV3-AF], this TLV MUST be ignored. Similarly, only a single instance of the IPv4 Link-Local Address TLV (Section 3.9) SHOULD be included in the E-Link-LSA. Instances following the first MUST be ignored. For OSPFv3 IPv6 address families as defined in [OSPFV3-AF], 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 Section 5. Future specifications may support advertisement of routing and topology information for multiple address families. However, this is beyond the scope of this document. 4.8. OSPFv3 E-Intra-Area-Prefix-LSA 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 insectionAppendix A.4.10 of [OSPFV3] except for the Referenced LS Type. However, unlike the Intra-Area-Prefix-LSA, it is fullyextendableextensible and represented as TLVs. The Referenced LS Type MUST be either anE- Router-LSAE-Router-LSA (0xA021) or an E-Network-LSA (0xA022). 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|0|1| 0x29 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Referenced LS Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Referenced Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Referenced Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E-Intra-Area-Prefix-LSA 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, multipleIntra-Area PrefixIntra-Area-Prefix TLVs may bespecifiedspecified, and the LSA length defines the end of the LSA includingallany TLVs. 5. Malformed OSPFv3 Extended LSA Handling 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 OSPFv3Routing Domain.routing domain. Note that for the purposes of length validation, a TLV orSub-TLVsub-TLV should not be considered invalid unless the length exceeds the length of the LSA or does not meet the minimum lengthrequirements.requirements for the TLV or sub-TLV. This allows forSub-TLVssub-TLVs to be added as described in Section 6.3. Additionally, an LSA MUST be considered malformed if it does not include all of the required TLVs andSub-TLVs.sub-TLVs. 6. LSA Extension Backward Compatibility 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. 6.1. Full Extended LSA Migration If ExtendedLSASupport is enabledAppendix A,(Appendix A), OSPFv3 Extended LSAs will be originated and used for the SPF computation. Individual OSPF Areas can be migrated separately with the LegacyAS-External LSAsAS-External-LSAs being originated and used for the SPF computation. This is accomplished byenabledenabling AreaExtendedLSASupportAppendix B.(Appendix B). An OSPFv3 routing domain or area may be non-disruptively migrated using separate OSPFv3 instances for theextendedExtended 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(RIB)(RIBs) have been verified, the OSPFv3 instances using theextendedExtended 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. 6.2. Extended LSA Sparse-Mode Backward Compatibility In this mode, OSPFv3 will use the Legacy LSAs for the SPF computation and will only originateextendedExtended LSAs when LSA origination is required in support of additional functionality. Furthermore, thoseextendedExtended LSAs will only include the top-level TLVs (e.g., Router-Link TLVs or Inter-AreaTLVs)TLVs), whichrequire further specificationare required for that new functionality. However, if a top-level TLV is advertised, it MUST include requiredSub-TLVssub-TLVs, or it will be considered malformed as described in Section 5. Hence, this mode of compatibility is known as "sparse-mode". The advantage of sparse-mode is that functionality utilizing the OSPFv3extendedExtended LSAs can be added to an existingOSFPv3OSPFv3 routing domain without the requirement for migration. In essence, this compatibility mode is very much like the approach taken for OSPFv2 [OSPF-PREFIX-LINK]. As with all the compatibility modes, backward compatibility for the functions utilizing theextendedExtended LSAs must be described in the IETF documents describing those functions. 6.3. LSA TLV Processing Backward Compatibility 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: 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or processingExtended-LSAs.Extended LSAs. 2. Whether or not partial deployment of a given TLV is supported MUST be specified. 3. If partial deployment is not supported, mechanisms to ensure the corresponding featureareis not deployed MUST be specified in the document defining the new TLV or sub-TLV. 4. If partial deployment is supported, backward compatibility and partial deployment MUST be specified in the document defining the new TLV or sub-TLV. 5. If a TLV orSub-TLVsub-TLV is recognized but the length is less than the minimum, then the LSA should be consideredmalformedmalformed, 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 orSub-TLVsub-TLV in error. Ideally, the log entry would include the hexadecimal or binary representation of the LSA including the malformedTLSTLV orSub-TLV.sub-TLV. 6. Documents specifying future TLVs or Sub-TLVs MUST specify the requirements for usage of those TLVs orSub-TLVs.sub-TLVs. 7. FutureTLVTLVs orSub-TLVssub-TLVs must be optional. However, there may be requirements forSub-TLVssub-TLVs if an optional TLV is specified. 7. Security Considerations In general,extendibleextensible OSPFv3 LSAs are subject to the same security concerns as those described in RFC 5340 [OSPFV3]. 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 [OSPF-DIGITAL-SIGNATURE], the mechanisms described herein would greatly simplify the extension. 8. IANA Considerations This specification defines nine OSPFv3 Extended LSA types as described in Section 2. Thesearehave been added to the existing OSPFv3 LSA Function Codes registry. The specification defines anewcode point for the N-bit in the OSPFv3 Prefix-Options registry. The value 0x20is suggested.has been assigned. This specification also creates two registries for OSPFv3Extended-LSAsExtended LSA TLVs and sub-TLVs. The TLV and sub-TLVcode-pointscode points in these registries are common to allExtended-LSAsExtended LSAs, and their respective definitions must define where they are applicable. 8.1. OSPFv3Extended-LSAExtended LSA TLV Registry TheOSPFv3 Extended-LSA TLV"OSPFv3 Extended LSA TLVs" registry defines top-level TLVs forExtended-LSAsExtended LSAs andshould behas been placed in the existing OSPFv3 IANA registry. Nine valuesare allocated by this specification:have been allocated: o 0 - Reserved o 1 - Router-Link TLV o 2 - Attached-Routers TLV o 3 -Inter-Area PrefixInter-Area-Prefix TLV o 4 -Inter-Area RouterInter-Area-Router TLV o 5 -External PrefixExternal-Prefix TLV o 6 -Intra-Area PrefixIntra-Area-Prefix TLV o 7 - IPv6 Link-Local Address TLV o 8 - IPv4 Link-Local Address TLV Types in the range 9-32767 are allocated via IETFConsensusReview or IESGApproval.Approval [RFC8126]. Types in the range 32768-33023 are Reserved forexperimental use;Experimental Use; these will not be registered withIANA,IANA and MUST NOT be mentioned by RFCs. Types in the range 33024-45055 are to be assigned on aFirst-Come- First-ServeFirst 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 thatcoverscover the range being assigned. 8.2. OSPFv3Extended-LSA sub-TLVExtended LSA Sub-TLV Registry TheOSPFv3 Extended-LSA sub-TLV"OSPFv3 Extended LSA Sub-TLVs" registry defines sub-TLVs at any level of nesting forExtended-LSAsExtended LSAs andshould behas been placed in the existing OSPFv3 IANA registry. Four valuesare allocated by this specification:have been allocated: o 0 - Reserved o 1 -IPv6 Forwarding AddressIPv6-Forwarding-Address sub-TLV o 2 -IPv4 Forwarding AddressIPv4-Forwarding-Address sub-TLV o 3 -Route TagRoute-Tag sub-TLV Types in the range 4-32767 are allocated via IETFConsensusReview or IESG Approval. Types in the range 32768-33023 are Reserved forexperimental use;Experimental Use; these will not be registered withIANA,IANA and MUST NOT be mentioned by RFCs. Types in the range 33024-45055 are to be assigned ona First-Come- First-Serve (FCFS)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 thatcoverscover the range being assigned. 9.Contributors Contributors' Addresses Sina Mirtorabi Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA Email: sina@cisco.com 10.References10.1.9.1. Normative References [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, DOI 10.17487/RFC3101, January2003.2003, <https://www.rfc-editor.org/info/rfc3101>. [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July2008.2008, <https://www.rfc-editor.org/info/rfc5340>. [OSPFV3-AF] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, DOI 10.17487/RFC5838, April2010.2010, <https://www.rfc-editor.org/info/rfc5838>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March1997.1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May2017.2017, <https://www.rfc-editor.org/info/rfc8174>. [TE] Katz, D.,Yeung, D., and K.Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions toOSPF",OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September2003. 10.2.2003, <https://www.rfc-editor.org/info/rfc3630>. 9.2. Informative References [IPV6-ADDRESS-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February2006.2006, <https://www.rfc-editor.org/info/rfc4291>. [MT-OSPFV3] Mirtorabi, S. and A. Roy, "Multi-topology routing in OSPFv3(MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt (work(MT-OSPFv3)", Work inprogress), January 2008.Progress, draft-ietf-ospf-mt- ospfv3-03, July 2007. [OSPF-DIGITAL-SIGNATURE] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, DOI 10.17487/RFC2154, June1997.1997, <https://www.rfc-editor.org/info/rfc2154>. [OSPF-PREFIX-LINK] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem,"OSPF"OSPFv2 Prefix/LinkAttributes",Attribute Advertisement", RFC 7684,December 2015.DOI 10.17487/RFC7684, November 2015, <https://www.rfc-editor.org/info/rfc7684>. [SEGMENT-ROUTING] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for Segment Routing",draft-ietf-ospf-ospfv3- segment-routing-extensions-10.txt (workWork inprogress), July 2016.Progress, draft- ietf-ospf-ospfv3-segment-routing-extensions-11, January 2018. Appendix A.Appendix A -Global Configuration Parameters The global configurable parameter ExtendedLSASupport is added to the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3Routerrouter 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 Section 6.2. Appendix B.Appendix B -Area Configuration Parameters The area configurable parameter AreaExtendedLSASupport is added to the OSPFv3 protocol. If AreaExtendedLSASupport is enabled, the OSPFv3Routerrouter 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 theAS External LSAAS-External-LSA computation. If AreaExtendedLSASupport is notenabledenabled, a subset of OSPFv3 link and area Extended LSAs may still be originated and used for other functions as described in Section 6.2. For regular areas, i.e., areas whereAS scopedAS-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 bythe implementation. Appendix C.implementations. Acknowledgments OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3]. Thanks for Peter Psenak for significant contributions to thebackward compatibilitybackward-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 theextendedExtended LSA TLV definitions from theextendedExtended 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 SureshKrishnaKrishnan for substantive comments during IESG Review. Thanks to Mehmet Ersue forOPSthe Operations and Management (OPS) Directorate review.The RFC text was produced using Marshall Rose's xml2rfc tool.Contributors Sina Mirtorabi Cisco Systems 170 Tasman Drive San Jose, CA 95134 United States of America Email: sina@cisco.com Authors' Addresses Acee Lindem Cisco Systems 301 Midenhall Way Cary, NC 27513USAUnited States of America Email: acee@cisco.com Abhay Roy Cisco Systems 170 Tasman Drive San Jose, CA 95134USAUnited States of America Email: akr@cisco.com Dirk Goethals Nokia Copernicuslaan 50 Antwerp 2018 Belgium Email: dirk.goethals@nokia.com Veerendranatha Reddy Vallem Bangalore India Email: vallem.veerendra@gmail.com Fred Baker Santa Barbara, California 93117USAUnited States of America Email: FredBaker.IETF@gmail.com