RFC 8362
OSPFv3 Link State Advertisement (LSA) Extensibility
Internet Engineering Task Force (IETF) A. Lindem Request for Comments: 8362 A. Roy Updates: 5340, 5838 Cisco Systems Category: Standards Track D. Goethals ISSN: 2070-1721 Nokia V. Reddy Vallem F. Baker April 2018 OSPFv3 Link State Advertisement (LSA) ExtensibilityAbstract
OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described. This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at 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 (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. Requirements Notation . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 7 3.2. Router-Link TLV . . . . . . . . . . . . . . . . . . . . . 8 3.3. Attached-Routers TLV . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . 14 3.10. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 15 3.11. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 15 3.12. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 16 4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . 16 4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 16 4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . 18 4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . 19 4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . 20 4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . 21 4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 22 4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 22 4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . 24 5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . 25 6. LSA Extension Backward Compatibility . . . . . . . . . . . . 25 6.1. Full Extended LSA Migration . . . . . . . . . . . . . . . 25 6.2. Extended LSA Sparse-Mode Backward Compatibility . . . . . 26
6.3. LSA TLV Processing Backward Compatibility . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8.1. OSPFv3 Extended LSA TLV Registry . . . . . . . . . . . . 27
8.2. OSPFv3 Extended LSA Sub-TLV Registry . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Global Configuration Parameters . . . . . . . . . . 31
Appendix B. Area Configuration Parameters . . . . . . . . . . . 31
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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.
This document updates RFC 5340, "OSPF for IPv6", and RFC 5838,
"Support of Address Families in OSPFv3", by providing TLV-based
encodings for the base OSPFv3 support [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 in Appendix 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 Compatibility1.1. Requirements Notation
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 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 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.
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 occurrences of the TLV or sub-TLV. While this document only describes the usage of TLVs and sub-TLVs, sub-TLVs may be nested to any level as long as the sub-TLVs are fully specified in the specification for the subsuming sub-TLV. For backward compatibility, an LSA is not considered malformed from a TLV perspective unless either a required TLV is missing or a specified TLV is less than the minimum required length. Refer to 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 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 in Intra-Area-Prefix-LSAs (Section 4.4.3.9 of [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 (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 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 NOT 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 route that has the N-bit set in the PrefixOptions. Similarly, the N-bit is propagated in the PrefixOptions when an OSPFv3 Not-So-Stubby Area (NSSA) ABR originates an E-AS-External-LSA corresponding to an NSSA route as described in Section 3 of RFC 3101 [NSSA]. The N-bit is added 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 used as hint to identify the preferred address to reach the advertising OSPFv3 router. This would be in contrast to an 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 router link, and the field definitions correspond directly to links in the OSPFv3 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-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; see Appendix A.4.4 of [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 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.
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 Appendix A.4.1 of [OSPFV3], and an OSPFv3 Inter-Area-Prefix-LSA, as defined in 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 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
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 OSPFv3 Inter-Area-Router-LSA, as defined in Appendix A.4.6 of [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
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 Appendix A.4.1 of [OSPFV3], and an OSPFv3 AS-External-LSA, as defined in Appendix A.4.7 of [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)
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 Appendix A.4.1 of [OSPFV3], and an OSPFv3 Link-LSA, as defined in Appendix A.4.9 of [OSPFV3]. The Intra-Area-Prefix TLV is only applicable to the E-Link-LSA (Section 4.7) and the E-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-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Intra-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-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Link-Local Address TLV3.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
3.10. IPv6-Forwarding-Address Sub-TLV
The IPv6-Forwarding-Address TLV has identical semantics to the optional forwarding address in Appendix 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. The IPv6-Forwarding-Address TLV length must meet a minimum length (16 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-Address TLV3.11. IPv4-Forwarding-Address Sub-TLV
The IPv4-Forwarding-Address TLV has identical semantics to the optional forwarding address in Appendix A.4.7 of [OSPFV3]. 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 IPv4 address families as defined in [OSPFV3-AF]. It MUST be ignored for other address families. The IPv4-Forwarding-Address TLV length must meet a minimum length (4 octets), or it will be considered malformed as described in 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-Address TLV
3.12. Route-Tag Sub-TLV
The optional Route-Tag sub-TLV has identical semantics to the
optional External Route Tag in Appendix 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.
The Route-Tag TLV length must meet a minimum length (4 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-Tag Sub-TLV
(page 16 continued on part 2)
