Network Working Group A. Lindem Internet-Draft A. Roy Intended status: Standards Track Cisco Systems Expires: April 12, 2018 D. Goethals Nokia V. Reddy Vallem Huawei, Inc F. Baker October 9, 2017 OSPFv3 LSA Extendibility draft-ietf-ospf-ospfv3-lsa-extend-15.txt 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 compatibility mechanisms are also described. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 12, 2018. Lindem, et al. Expires April 12, 2018 [Page 1] Internet-Draft OSPFv3 LSA Extendibility October 2017 Copyright Notice Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . 4 1.2. OSPFv3 LSA Terminology . . . . . . . . . . . . . . . . . 4 1.3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 7 3.2. Router-Link TLV . . . . . . . . . . . . . . . . . . . . . 7 3.3. Attached-Routers TLV . . . . . . . . . . . . . . . . . . 8 3.4. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 10 3.5. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 11 3.6. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 12 3.7. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 13 3.8. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 14 3.9. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 15 3.10. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16 3.11. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16 3.12. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 17 4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . 17 4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 17 4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . 19 4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . 20 4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . 21 4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . 22 4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 23 4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 24 4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . 26 5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . 27 6. LSA Extension Backward Compatibility . . . . . . . . . . . . 27 6.1. Full Extended LSA Migration . . . . . . . . . . . . . . . 27 Lindem, et al. Expires April 12, 2018 [Page 2] Internet-Draft OSPFv3 LSA Extendibility October 2017 6.2. Extended LSA Spare-Mode Backward Compatibility . . . . . 28 6.3. LSA TLV Processing Backward Compatibility . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . 30 10.2. Informative References . . . . . . . . . . . . . . . . . 31 Appendix A. Appendix A - Global Configuration Parameters . . . . 31 Appendix B. Appendix B - Area Configuration Parameters . . . . . 31 Appendix C. Appendix C - Deprecated LSA Extension Backward Compatibility . . . . . . . . . . . . . . . . . . . 32 C.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . 34 C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 34 C.2. Global Configuration Parameters . . . . . . . . . . . . . 35 C.3. Area Configuration Parameters . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 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 compatibility mechanisms are also described. A similar extension was previously proposed in support of multi- topology routing. Additional requirements for 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 section 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 OSPFv3 LSA extension are described: 1. Extended LSA Types 2. Extended LSA TLVs Lindem, et al. Expires April 12, 2018 [Page 3] Internet-Draft OSPFv3 LSA Extendibility October 2017 3. Extended LSA Formats 4. Backward Compatibility 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. 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. 1.3. 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 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, and Meng Zhang for review and editorial comments. The RFC text was produced using Marshall Rose's xml2rfc tool. 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 Lindem, et al. Expires April 12, 2018 [Page 4] Internet-Draft OSPFv3 LSA Extendibility October 2017 one half the LSA function code space for the migration of the eight original fixed-format LSAs. For backward compatibility, the U-bit will be set in 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 the extended 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 nested Type/Length/Value (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 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. Lindem, et al. Expires April 12, 2018 [Page 5] Internet-Draft OSPFv3 LSA Extendibility October 2017 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 Prefix TLV o 4 - Inter-Area Router TLV o 5 - External Prefix TLV o 6 - Intra-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 Address sub-TLV o 2 - IPv4 Forwarding Address sub-TLV o 3 - Route Tag sub-TLV In 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 occurances of the TLV or sub-TLVs. 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 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, is an interface address. In RFC 5340, the LA-bit is only set in Intra- Area-Prefix-LSAs (Section 4.4.3.9 in [OSPFV3]). This will allow a Lindem, et al. Expires April 12, 2018 [Page 6] Internet-Draft OSPFv3 LSA Extendibility October 2017 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. 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | | | N|DN| P| x|LA|NU| +--+--+--+--+--+--+--+--+ The Prefix Options field The N-bit is set in PrefixOptions for a host address (PrefixLength=128) 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, 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 which has the N-bit set in the PrefixOptions. Similarly, the N-bit is propagated in the PrefixOptions when an OSPFv3 NSSA ABR originates an Extended-AS- External-LSA corresponding to an NSSA route as described in section 3 of RFC 3101 ([NSSA]). The N-bit is to the Inter-Area-Prefix-TLV (Section 3.4), External-Prefix-TLV (Section 3.6), and Intra-Area- Prefix-TLV (Section 3.7) The N-bit is useful for applications such as identifying the prefixes corresponding to Node Segment Identifiers (SIDs) in Segment Routing [SEGMENT-ROUTING]. 3.2. Router-Link TLV The Router-Link TLV defines a single router link and the field definitions correspond directly to links in the OSPFv3 Router-LSA, section A.4.3, [OSPFV3]. The Router-Link TLV is only applicable to the E-Router-LSA (Section 4.1). Inclusion in other Extended LSAs MUST be ignored. Lindem, et al. Expires April 12, 2018 [Page 7] Internet-Draft OSPFv3 LSA Extendibility October 2017 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-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 OSPFv3 Network-LSA, section A.4.4, [OSPFV3]. The Attached-Routers TLV is only applicable to the E- 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 the E- 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 Lindem, et al. Expires April 12, 2018 [Page 8] Internet-Draft OSPFv3 LSA Extendibility October 2017 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. Lindem, et al. Expires April 12, 2018 [Page 9] Internet-Draft OSPFv3 LSA Extendibility October 2017 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 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 Inter-Area-Prefix-LSA, as defined in section A.4.5, [OSPFV3]. Additionally, the PrefixOptions are extended as described in Section 3.1. The Inter-Area-Prefix TLV is only applicable to the E- 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-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Inter-Area Prefix TLV Lindem, et al. Expires April 12, 2018 [Page 10] Internet-Draft OSPFv3 LSA Extendibility October 2017 3.5. Inter-Area-Router TLV The Inter-Area-Router TLV defines a single OSPFv3 Autonomous System Boundary Router (ASBR) reachable in another area. The field definitions correspond directly to the content of an OSPFv3 Inter- Area-Router-LSA, as defined in section A.4.6, [OSPFV3]. The Inter- 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-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Inter-Area Router TLV Lindem, et al. Expires April 12, 2018 [Page 11] Internet-Draft OSPFv3 LSA Extendibility October 2017 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 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 AS- External-LSA, as defined in section A.4.7, [OSPFV3]. The External- 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-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ External Prefix TLV 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: o 1 - IPv6 Forwarding Address sub-TLV (Section 3.10) o 2 - IPv4 Forwarding Address sub-TLV (Section 3.11) o 3 - Route Tag sub-TLV (Section 3.12) Lindem, et al. Expires April 12, 2018 [Page 12] Internet-Draft OSPFv3 LSA Extendibility October 2017 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 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 Link- LSA, as defined in section A.4.9, [OSPFV3]. The Intra-Area-Prefix TLV is only applicable to the E-Link-LSA (Section 4.7) and the Additionally, the PrefixOptions are extended as described in Section 3.1. E-Intra-Area-Prefix-LSA (Section 4.8). 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-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Intra-Area Prefix TLV Lindem, et al. Expires April 12, 2018 [Page 13] Internet-Draft OSPFv3 LSA Extendibility October 2017 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-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Link-Local Address TLV Lindem, et al. Expires April 12, 2018 [Page 14] Internet-Draft OSPFv3 LSA Extendibility October 2017 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-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Link-Local Address TLV Lindem, et al. Expires April 12, 2018 [Page 15] Internet-Draft OSPFv3 LSA Extendibility October 2017 3.10. IPv6-Forwarding-Address Sub-TLV The IPv6 Forwarding Address TLV has identical semantics to the optional forwarding address in section A.4.7 of [OSPFV3]. The IPv6 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 the Forwarding Address as defined in [OSPFV3]. Instances subsequent to the first MUST be ignored. The IPv6 Forwarding Address TLV is to be used with IPv6 address families as defined in [OSPFV3-AF] It MUST be ignored for other address families. 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 -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Forwarding Address Tag TLV 3.11. IPv4-Forwarding-Address Sub-TLV The IPv4 Forwarding Address TLV has identical semantics to the optional forwarding address in section A.4.7 of [OSPFV3]. The IPv4 Forwarding Address TLV is The IPv4 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 the Forwarding Address as defined in [OSPFV3]. Instances subsequent to the first MUST be ignored. The IPv4 Forwarding Address TLV is to be used with IPv3 address families as defined in [OSPFV3-AF] It MUST be ignored for other address families. Lindem, et al. Expires April 12, 2018 [Page 16] Internet-Draft OSPFv3 LSA Extendibility October 2017 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Forwarding Address Tag TLV 3.12. Route-Tag Sub-TLV The optional Route Tag sub-TLV has identical semantics to the optional External Route Tag in section A.4.7 of [OSPFV3]. The Route 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 is optional and the first specified instance is used as the Route Tag as defined in [OSPFV3]. Instances subsequent to the first 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 - Route Tag | sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Route 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 specifed 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 in section A.4.3 of [OSPFV3]. However, unlike the existing Router-LSA, it is fully extendable and represented as TLVs. Lindem, et al. Expires April 12, 2018 [Page 17] Internet-Draft OSPFv3 LSA Extendibility October 2017 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 differnt LS Type, all LSA Header fields are the same as defined for the Router-LSA. Initially, only the top-level Router-Link TLV Section 3.2 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 TLVs. Lindem, et al. Expires April 12, 2018 [Page 18] Internet-Draft OSPFv3 LSA Extendibility October 2017 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 in section A.4.4 of [OSPFV3]. However, unlike the existing Network-LSA, it is fully extendable 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 differnt 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 TLVs. Initially, only the top-level Attached-Routers TLV Section 3.3 is applicable. If the Attached-Router TLV is not included in the 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. Lindem, et al. Expires April 12, 2018 [Page 19] Internet-Draft OSPFv3 LSA Extendibility October 2017 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 in section A.4.5 of [OSPFV3]. However, unlike the existing Inter-Area- Prefix-LSA, it is fully extendable 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 differnt 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 SPF computation. Like the existing Inter-Area-Prefix-LSA, the LSA length is used to determine the end of the LSA including TLV. Initially, only the top- 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. Lindem, et al. Expires April 12, 2018 [Page 20] Internet-Draft OSPFv3 LSA Extendibility October 2017 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-LSAE defined in section A.4.6 of [OSPFV3]. However, unlike the Inter-Area-Router- LSA, it is fully extendable 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 differnt 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 TLV. Initially, only the top- 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. Lindem, et al. Expires April 12, 2018 [Page 21] Internet-Draft OSPFv3 LSA Extendibility October 2017 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 in section A.4.7 of [OSPFV3]. However, unlike the existing AS-External-LSA, it is fully extendable 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 differnt 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 processes such as incremental SPF computation. Like the existing AS-External-LSA, the LSA length is used to determine the end of the LSA including sub-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. Lindem, et al. Expires April 12, 2018 [Page 22] Internet-Draft OSPFv3 LSA Extendibility October 2017 4.6. OSPFv3 E-NSSA-LSA The E-NSSA-LSA will have the same format and TLVs as the Extended AS- External-LSA Section 4.5. This is the same relationship as exists between the NSSA-LSA defined in section A.4.8 of [OSPFV3], 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. Lindem, et al. Expires April 12, 2018 [Page 23] Internet-Draft OSPFv3 LSA Extendibility October 2017 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 in section A.4.9 of [OSPFV3]. However, unlike the existing Link-LSA, it is extendable 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 differnt 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, multiple Intra-Area Prefix TLVs (Section 3.7) may be specified and the LSA length defines the end of the LSA including all 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 Lindem, et al. Expires April 12, 2018 [Page 24] Internet-Draft OSPFv3 LSA Extendibility October 2017 following the first MUST be ignored. For OSPFv3 IPv6 address families as defined in [OSPFV3-AF], this TLV MUST 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. Lindem, et al. Expires April 12, 2018 [Page 25] Internet-Draft OSPFv3 LSA Extendibility October 2017 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 in section A.4.10 of [OSPFV3] except for the Referenced LS Type. However, unlike the Intra-Area-Prefix-LSA, it is fully extendable and represented as TLVs. The Referenced LS Type MUST be either an E- 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 differnt 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 all TLVs. Lindem, et al. Expires April 12, 2018 [Page 26] Internet-Draft OSPFv3 LSA Extendibility October 2017 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 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. This allows for Sub-TLVs to be added as described in Section 6.3. Additionally, an LSA MUST be considered malformed if it does not include any required TLV or 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 enabled Appendix A, 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 enabled AreaExtendedLSASupport Appendix B. 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 (RIB) 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. Lindem, et al. Expires April 12, 2018 [Page 27] Internet-Draft OSPFv3 LSA Extendibility October 2017 6.2. Extended LSA Spare-Mode Backward Compatibility 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 addtional functionality. Furthermore, the extended LSAs will only include those TLVs which require further specification for that new functionality. Hence, this mode of compatibility is know as "sparse-mode". The advantage of sparse-mode is that functionality utilizing the OSPFv3 extended LSAs can be added to an existing OSFPv3 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 the extended 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 processing 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 feature are 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 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 occurence SHOULD be logged with enough information to identify the LSA by type, originator, and sequence number and the TLV or Sub-TLV in error. Ideally, the log entry would include the hexidecimal or binary representation of the LSA including the malformed TLS or Sub-TLV. 6. Documents specifying future TLVs or Sub-TLVs MUST specify the requirements for usage of those TLVs or Sub-TLVs. Lindem, et al. Expires April 12, 2018 [Page 28] Internet-Draft OSPFv3 LSA Extendibility October 2017 7. Future TLV or Sub-TLVs must be optional. However, there may be requirements for Sub-TLVs if an optional TLV is specified. 7. Security Considerations In general, extendible 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. This specification also creates two registries OSPFv3 Extended-LSAs 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 TLV registry will define top-level TLVs for Extended-LSAs and should be placed in the existing OSPFv3 IANA registry. New values can be allocated via IETF Consensus or IESG Approval. Nine values are allocated by this specification: o 0 - Reserved o 1 - Router-Link TLV o 2 - Attached-Routers TLV o 3 - Inter-Area Prefix TLV o 4 - Inter-Area Router TLV o 5 - External Prefix TLV o 6 - Intra-Area Prefix TLV o 7 - IPv6 Link-Local Address TLV o 8 - IPv4 Link-Local Address TLV Lindem, et al. Expires April 12, 2018 [Page 29] Internet-Draft OSPFv3 LSA Extendibility October 2017 The OSPFv3 Extended-LSA sub-TLV registry will define sub-TLVs at any level of nesting for Extended-LSAs and should be placed in the existing OSPFv3 IANA registry. New values can be allocated via IETF Review. Three values are allocated by this specification: o 0 - Reserved o 1 - Forwarding Address o 2 - Route Tag The OSPFv3 Prefix Options registry will define a new code point for the N-bit. The value 0x20 is suggested. 9. Contributors Contributors' Addresses Sina Mirtorabi Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA Email: sina@cisco.com 10. References 10.1. Normative References [GRACEFUL-RESTART] Lindem, A. and P. Pillay-Esnault, "OSPFv3 Graceful Restart", RFC 5187, June 2008. [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003. [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. [OSPFV3-AF] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010. Lindem, et al. Expires April 12, 2018 [Page 30] Internet-Draft OSPFv3 LSA Extendibility October 2017 [RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering Extensions to OSPF", RFC 3630, September 2003. 10.2. Informative References [MT-OSPFV3] Mirtorabi, S. and A. Roy, "Multi-topology routing in OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-03.txt (work in progress), January 2008. [OSPF-DIGITAL-SIGNATURE] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997. [OSPF-PREFIX-LINK] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPF Prefix/Link Attributes", RFC 7684, December 2015. [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-06.txt (work in progress), July 2016. Appendix A. Appendix A - Global Configuration Parameters The global configurable parameter ExtendedLSASupport will be 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 Section 6.2. Appendix B. Appendix B - Area Configuration Parameters The area configurable parameter AreaExtendedLSASupport will be added to the OSPFv3 protocol. If ExtendedLSASupport 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 Lindem, et al. Expires April 12, 2018 [Page 31] Internet-Draft OSPFv3 LSA Extendibility October 2017 area Extended LSAs may still be originated and used for other functions as described in Section 6.2. For regular areas, i.e., areas where AS scoped LSAs are flooded, disabling AreaExtendedLSASupport when ExtendedLSASupport is enabled is contradictory and MAY be prohibited by the implementation. Appendix C. Appendix C - Deprecated 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. Three distinct backward compatibility modes are supported dependent on the OSPFv3 routing domain migration requirements. For simplicity and to avoid the scaling impact of maintaining both TLV and non-TLV based versions of the same LSA within a routing domain, the basic backward compatibility mode will not allow mixing of LSA formats. Different LSA formats could still be supported with multiple OSPFv3 instances and separate OSPFv3 routing domains. Additionally, a more flexible mode is provided in Appendix C.1, where both formats of LSA coexist. In order to facilitate backward compatibility, the OSPFv3 options field (as described in Appendix A.2 of RFC 5340 [OSPFV3]), will contain two additional options bits. The EL-bits will be used to indicate that the OSPFv3 router's level of Extended LSA support. An OSPFv3 router configured to support extended LSAs MUST set its options field EL-bits in OSPFv3 Hello and Database Description packets as follows: B'00' None - Extended LSAs are not originated nor used in the SPF calculation (except for future functionalities as described in Section 6.2) . B'01' MixedModeOriginateOnly - Both Extended and Legacy LSAs are originated. Legacy LSAs are used in the SPF computation. B'10' MixedModeOriginateSPF - Both extended and Legacy LSAs are originated. Extended LSAs are used in the SPF computation. Lindem, et al. Expires April 12, 2018 [Page 32] Internet-Draft OSPFv3 LSA Extendibility October 2017 B'11' Full - Only extended LSAs are originated and used in the SPF computation. If Full is specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database Description packets with the options field EL-bits set to MixedModeOriginateOnly or None. Similarly, if MixModeOriginateSPF is specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database Description packets with the options field EL-bits set to None (B'00'). In this manner, OSPFv3 routers using new encodings can be completely isolated from those OSPFv3 routers depending on the RFC 5340 encoding and not setting their options field EL-bits since the default setting indicates no support for extended LSAs. Finally, a mode supporting existing OSPFv3 routing domains is provided. This mode, subsequently referred to as "sparse-mode", will use the TLV-based LSAs solely in support of new functionality Section 6.2. In this compatibility mode, the EL-bits will be advertised as B'00' since the backward compatibility with the Legacy LSAs is not supported or required. 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ | | | | | | | | | | | | EL|AT|L|AF|*|*|DC|R|N|x|E|V6| +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ The Options field EL-bits These bits indicate the level of Extended LSA support. B'00' - Extended LSAs are not originate nor used in the SPF calculation (except for new functionalities for future functions as described in Section 6.2). B'01' - Both extended and Legacy LSAs are originated. Non-extended LSAs are used in the SPF computation. B'10' - Both extended and Legacy LSAs are originated. Extended LSAs are used in the SPF computation. B'11' - Only extended LSA are originated and used in the SPF computation. Options Field EL-bits The EL-bits will also be set in the LSA options field in Extended and Legacy LSAs. While the value of the EL-bits has no functional significance in the LSA options field, visibility of every OSPFv3 Lindem, et al. Expires April 12, 2018 [Page 33] Internet-Draft OSPFv3 LSA Extendibility October 2017 Router's extended LSA support is expected to be very useful for management and troubleshooting during the migration period. C.1. Extended LSA Mixed-Mode Backward Compatibility An implementation MAY support configuration allowing a graceful transition from the Legacy (non-TLV-based) LSAs to the extended (TLV- based) LSAs in an OSPFv3 routing domain. In these routing domains, the OSPFv3 routers configured with a value of MixedModeOriginateOnly or MixedModeOriginateSPF for ExtendedLSASupport, (Appendix C.2), MUST originate both the extended and legacy versions of the OSPFv3 LSAs described herein. For the purposes of Shortest Path First (SPF) computation, the Legacy LSAs are used for SPF computation when MixedModeOriginateOnly is configured and the extended LSAs are used when MixedModeOriginateSPF is specified. The Extended LSAs MAY be used for functions other than routing computation as long as backward compatibility is specified in the documents specifying those functions. In this manner, OSPFv3 routing domains utilizing the new encodings can be gradually migrated with a worst-case overhead cost of approximately doubling the number of LSAs in the routing domain. The transition within an OSPFv3 routing domain would progress as follows: 1. Configure OSPFv3 Router ExtendedLSASupport to MixedModeOriginateOnly so that routers originate the extended LSAs. 2. When all the OSPFv3 Routers have been reconfigured to MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to use the extended LSAs by configuring ExtendedLSASupport to MixedModeOriginateSPF. This can be done on a small subset of OSPFv3 Routers and the route tables can be verified. 3. When all the OSPFv3 Routers have been reconfigured to MixedModeOriginateSPF and the routing has been verified, reconfigure OSPFv3 Routers to purge or simply not refresh the Legacy LSA by configuring ExtendedLSASupport to Full. In order to prevent OSPFv3 routing domain routing loops, the advertised metrics in the Extended LSAs and Legacy LSAs MUST be identical. C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility An implementation MAY also support configuration allowing graceful transition from the Legacy LSAs to the extended LSAs within a single area. In these areas, the parameter AreaExtendedLSASupport Lindem, et al. Expires April 12, 2018 [Page 34] Internet-Draft OSPFv3 LSA Extendibility October 2017 (Appendix C.3) may be configured to take precedence over the global parameter ExtendedLSASupport. However, the AreaExtendedLSASupport will only apply to link and area scoped LSAs within the area and area based SPF calculations. The default is for the AreaExtendedLSASupport to be inherited from the ExtendedLSASupport. The configuration of ExtendedLSASupport will apply to AS-External LSAs even when AreaExtendedLSASupport takes precedence. When preforming a graceful restart [GRACEFUL-RESTART], an OSPFv3 router configured with MixedModeOriginate will use the Legacy LSAs to determine whether or not the graceful restart has completed successfully. Similarly, an OSPFv3 router configured with MixedModeOriginateSPF will use the extended LSAs. In other words, successful OSPFv3 graceful restart determination will follow the SPF calculation. C.2. Global Configuration Parameters An additional global configurable parameter will be added to the OSPFv3 protocol. ExtendedLSASupport This is an enumeration type indicating the extent to which the OSPFv3 instance supports the TLV format described herein for Extended LSAs. The valid values for the enumeration are: * None - Extended LSAs will not be originated or used in the SPF calculation. This is the default. When OSPFv3 functions requiring extended LSA are configured, and the ExtendedLSASuppport is "None", extended LSAs may be used as described in Section 6.2. * MixedModeOriginateOnly - Both extended and Legacy LSAs will be originated. OSPFv3 adjacencies will be formed with OSPFv3 routers not supporting this specification. The Legacy LSAs are used for the SPF computation. * MixedModeOriginateSPF - Both Extended LSAs and Legacy LSAs will be originated. OSPFv3 adjacencies will be formed with OSPFv3 routers not supporting this specification. The Extended LSAs are used for the SPF computation. * Full - Extended LSAs will be originated and adjacencies will ndot be formed with OSPFv3 routers not supporting this specification. Only Extended LSAs will be originated. Lindem, et al. Expires April 12, 2018 [Page 35] Internet-Draft OSPFv3 LSA Extendibility October 2017 C.3. Area Configuration Parameters An additional area configurable parameter will be added to the OSPFv3 protocol. AreaExtendedLSASupport This is an enumeration type indicating the extent to which the OSPFv3 area supports the TLV format described herein for Extended LSAs. The valid value for the enumeration are: * InheritGlobal - The AreaExtendedLSASupport will be inherited from ExtendedLSASupport. This is the default. * None - Extended LSAs will not be originated or used in the SPF calculation. This is the default. When OSPFv3 functions requiring extended LSA are configured, and the ExtendedLSASuppport is "None", the spare-mode compatability is in effect Section 6.2. * MixedModeOriginateOnly - Both extended and legacy link and area scoped LSAs will be originated. OSPFv3 adjacencies will be formed with OSPFv3 routers not supporting this specification. The Legacy LSAs are used for the area SPF computation. * MixedModeOriginateSPF - Both extended and legacy link and area scoped LSAs will be originated. OSPFv3 adjacencies will be formed with OSPFv3 routers not supporting this specification. The Extended LSAs are used for the area SPF computation. * Full - Link and area scoped Extended LSAs will be originated and adjacencies will not be formed with OSPFv3 routers not supporting this specification. Only Extended LSAs will be originated. For regular areas, i.e., areas where AS scoped LSAs are flooded, configuring None or MixedModeOriginateOnly for AreaExtendedLSASupport when Full is specified for ExtendedLSASupport is contradictory and MAY be prohibited by the implementation. Authors' Addresses Lindem, et al. Expires April 12, 2018 [Page 36] Internet-Draft OSPFv3 LSA Extendibility October 2017 Acee Lindem Cisco Systems 301 Midenhall Way Cary, NC 27513 USA Email: acee@cisco.com Abhay Roy Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA Email: akr@cisco.com Dirk Goethals Nokia Copernicuslaan 50 Antwerp 2018 Belgium Email: dirk.goethals@nokia.com Veerendranatha Reddy Vallem Huawei, Inc Email: veerendranatharv@huawei.com Fred Baker Santa Barbara, California 93117 USA Email: FredBaker.IETF@gmail.com Lindem, et al. Expires April 12, 2018 [Page 37]