RFC 8362
OSPFv3 Link State Advertisement (LSA) Extensibility
OSPFv3 Link State Advertisement (LSA) Extensibility ✨
RFC 8362 🦋
- Internet Engineering Task Force (IETF)
- Category: Standards Track
- ISSN: 2070-1721
- Date: April 2018
- Updates: RFC 5340 ("OSPF for IPv6") and RFC 5838 ("Support of Address Families in OSPFv3")
- No Obsoletes entry is listed in this title block.
- Authors: A. Lindem and A. Roy (Cisco Systems), D. Goethals (Nokia), V. Reddy Vallem, and F. Baker. No affiliations are listed for Vallem or Baker in this copy.
Abstract
okay so OSPFv3 needs more functionality than the fixed-format Link State Advertisement (LSA) from RFC 5340 can comfortably hold 🙈. Right now, if you want to attach extra attributes to OSPFv3 links or advertised IPv6 prefixes, those have to go in separate LSAs that get correlated back to the fixed-format ones. This doc fixes that. It encodes the existing OSPFv3 LSA info in Type-Length-Value (TLV) tuples, so you can advertise extra info with extra TLVs. It also explains the backward-compatibility mechanisms 💅.
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 . . . . . . . . . . . . . . . . . . . . . . . 331. Introduction 💖
Okay, so the big idea: OSPFv3 needs functional extension beyond what you can easily do with the fixed-format Link State Advertisement (LSA) described in RFC 5340 [OSPFV3]. Without LSA extension, attributes tied to OSPFv3 links and advertised IPv6 prefixes have to be advertised in separate LSAs and correlated back to the fixed-format LSAs. Messy 🙃. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples, and it lets you advertise additional information with additional TLVs. Backward-compatibility mechanisms are covered too ✨.
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 to support 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 here. Encoding details are also kept. For example, the representation of IPv6 prefixes described in Appendix A.4.1 in RFC 5340 [OSPFV3] is retained. This requirement was included to speed up IETF adoption and deployment 🚀.
The following aspects of the OSPFv3 LSA extension are described:
- Extended LSA Types
- Extended LSA TLVs
- Extended LSA Formats
- Backward Compatibility
1.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 🦋
Here's the deal with backward compatibility: new LSA codes have to 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, just with 32 (i.e., 0x20) added. 🧠 The alternative was to allocate a bit in the LS Type to indicate the new LSA format. However, that would have used one half the LSA function code space for migrating 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-LSAOSPFv3 Extended LSA Types 💜
3. OSPFv3 Extended LSA TLVs ✨
okay so TLVs are the little building blocks inside Extended LSAs 🧱💖. The way they're formatted is the same as the one used by the Traffic Engineering Extensions to OSPF [TE], which is so iconic of them to keep it consistent 🙌. The variable TLV section is made of one or more nested TLV tuples, and the nested ones get called sub-TLVs 🫶. Each TLV looks like this:
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 FormatThe Length field tells you how long the value part is, in octets. So a TLV with no value at all has a length of 0 🌸. The TLV gets padded to 4-octet alignment, but the padding does NOT count toward the Length field 👀. So a 3-octet value has a Length of 3, but the whole TLV takes up 8 octets 💅. Nested TLVs are 32-bit aligned too. For example, a 1-byte value gets a Length of 1, and then 3 octets of padding go on the end of the value 🎀.
This document defines these top-level TLV types:
- 0 - Reserved
- 1 - Router-Link TLV
- 2 - Attached-Routers TLV
- 3 - Inter-Area-Prefix TLV
- 4 - Inter-Area-Router TLV
- 5 - External-Prefix TLV
- 6 - Intra-Area-Prefix TLV
- 7 - IPv6 Link-Local Address TLV
- 8 - IPv4 Link-Local Address TLV
It also defines these sub-TLV types:
- 0 - Reserved
- 1 - IPv6-Forwarding-Address sub-TLV
- 2 - IPv4-Forwarding-Address sub-TLV
- 3 - Route-Tag sub-TLV
In general, TLVs and sub-TLVs MAY occur in any order 🦋, and the specification should define whether a TLV or sub-TLV is required and what happens when there are multiple occurrences of it 🧐. This doc only covers how TLVs and sub-TLVs get used, but sub-TLVs can be nested to any level, as long as the spec for the parent sub-TLV fully specifies them 🪆.
For backward compatibility 🫶, an LSA is NOT considered malformed from a TLV point of view unless either a required TLV is missing or a specified TLV is shorter than its minimum required length. Check out Section 6.3 for more on TLV backward compatibility 💜.
3.1. Prefix Options Extensions
The prefix options get extended from Appendix A.4.1.1 [OSPFV3] 🌈. The LA-bit's applicability gets expanded ✨. It SHOULD be set in Inter-Area-Prefix TLVs and MAY be set in External-Prefix TLVs when the advertised host IPv6 address is an interface address. A "host" address here means PrefixLength = 128 for the IPv6 Address Family or PrefixLength = 32 for the IPv4 Address Family [OSPFV3-AF] 🧚. Back in RFC 5340, the LA-bit only showed up in Intra-Area-Prefix-LSAs (Section 4.4.3.9 of [OSPFV3]) 🙈. This expansion lets a stable address get advertised without needing a separate loopback address in every OSPFv3 area, which is lowkey genius 🍓.
3.1.1. N-bit Prefix Option
Additionally, the N-bit prefix option is defined 🎀. Here's where the N-bit sits in the prefix options (value 0x20):
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
| | | N|DN| P| x|LA|NU|
+--+--+--+--+--+--+--+--+
The Prefix Options FieldThe 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 🫠. It's kind of like the LA-bit, but there are two differences 👑. First, the advertising router MAY choose NOT to set the N-bit, even when those conditions are met 🙃. Second, 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 🚫.
The N-bit also gets 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 its PrefixOptions 🔁. Same vibe for an OSPFv3 Not-So-Stubby Area (NSSA) ABR: it propagates the N-bit when it originates an E-AS-External-LSA for an NSSA route, as described in Section 3 of RFC 3101 [NSSA] 💅. The N-bit gets added to the Inter-Area-Prefix TLV (Section 3.4), the External-Prefix TLV (Section 3.6), and the Intra-Area-Prefix-TLV (Section 3.7) 🌸.
Here's the real tea: the N-bit is a hint for figuring out the preferred address to reach the advertising OSPFv3 router ✨. That's different from an anycast address [IPV6-ADDRESS-ARCH], which could also be a local address with the LA-bit set 🔍. It's useful for stuff like finding the prefixes that match Node Segment Identifiers (SIDs) in Segment Routing [SEGMENT-ROUTING] 🦋. And there may be future applications that need to pick a prefix associated with an OSPFv3 router, so bestie, keep an eye out 👀💜.
3.2. Router-Link TLV
The Router-Link TLV defines a single router link, and its field definitions line up directly with the links in the OSPFv3 Router-LSA. See Appendix A.4.3 of [OSPFV3] 🔗. The Router-Link TLV only applies to the E-Router-LSA (Section 4.1). If it shows up in any other Extended LSA, it 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 TLV3.3. Attached-Routers TLV
The Attached-Routers TLV defines all the routers attached to an OSPFv3 multi-access network 🌐. Its field definitions match the content of the OSPFv3 Network-LSA. See Appendix A.4.4 of [OSPFV3] 🧩. This TLV only applies to the E-Network-LSA (Section 4.2), and if it appears in any other Extended LSA, it 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 TLVSo why not give each adjacent neighbor its own TLV or sub-TLV? There are two reasons, and they're both very chic 💅. First, it discourages using the E-Network-LSA for anything beyond its current job of just advertising the routers attached to a multi-access network 🚫. The router's metric, plus the attributes of each attached router, SHOULD be advertised in their own E-Router-LSAs instead 📣. Second, there's only a single E-Network-LSA per multi-access link, with the Link State ID set to the Designated Router's Interface ID 🎯. Because of that, compact encoding was chosen to lower the chances that the E-Network-LSA gets big enough to need IPv6 fragmentation when it's sent 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 🦄. Its field definitions line up directly with an OSPFv3 IPv6 Prefix (Appendix A.4.1 of [OSPFV3]) and an OSPFv3 Inter-Area-Prefix-LSA (Appendix A.4.5 of [OSPFV3]) 📚. The PrefixOptions also get extended, as covered in Section 3.1 ✨. This TLV only applies to the E-Inter-Area-Prefix-LSA (Section 4.3), and if it turns up in any other Extended LSA, it 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 TLV3.5. Inter-Area-Router TLV
okay bestie, this one is the "hey, there's an ASBR over in another area and here's how to reach it" TLV 🧚✨ It defines a single OSPFv3 Autonomous System Boundary Router (ASBR) that's reachable in another area. The fields match the OSPFv3 Inter-Area-Router-LSA line for line (see Appendix A.4.6 of [OSPFV3]) 💅 It only belongs in the E-Inter-Area-Router-LSA (Section 4.4). If you stick it in any other Extended LSA, it 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 TLV3.6. External-Prefix TLV
this TLV is giving OSPFv3 external prefix energy 🌸 It defines a single OSPFv3 external prefix. Apart from a few fields we dropped (more on that in a sec), it lines up with the OSPFv3 IPv6 Prefix (Appendix A.4.1 of [OSPFV3]) and the OSPFv3 AS-External-LSA (Appendix A.4.7 of [OSPFV3]). It's only for the E-AS-External-LSA (Section 4.5) and the E-NSSA-LSA (Section 4.6). The PrefixOptions get extended too, as described in Section 3.1. Stick it in any other Extended LSA and it 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 TLVSo here's the tea ☕ In the External-Prefix TLV, the optional IPv6/IPv4 Forwarding Address and External Route Tag are now sub-TLVs. The Referenced LS Type and Referenced Link State ID from the AS-External-LSA have never been used or even specified, so they're gone from this TLV. If a referenced LSA ever becomes a requirement, a sub-TLV can handle it 🫶
These sub-TLVs can optionally be included in the External-Prefix TLV:
- 1 - IPv6-Forwarding-Address sub-TLV (Section 3.10)
- 2 - IPv4-Forwarding-Address sub-TLV (Section 3.11)
- 3 - Route-Tag sub-TLV (Section 3.12)
3.7. Intra-Area-Prefix TLV
main character energy for intra-area prefixes 👑 This TLV defines a single OSPFv3 intra-area prefix. The fields match the OSPFv3 IPv6 Prefix (Appendix A.4.1 of [OSPFV3]) and the OSPFv3 Link-LSA (Appendix A.4.9 of [OSPFV3]). It's only applicable to the E-Link-LSA (Section 4.7) and the E-Intra-Area-Prefix-LSA (Section 4.8). Again, the PrefixOptions are extended as described in Section 3.1, and in any other Extended LSA it 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 TLV3.8. IPv6 Link-Local Address TLV
this one is for IPv6 address families as defined in [OSPFV3-AF] 🌈 It's only applicable to the E-Link-LSA (Section 4.7). Anywhere else, it 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 sibling 🦋 This is for IPv4 address families as defined in [OSPFV3-AF]. It's only applicable to the E-Link-LSA (Section 4.7), and anywhere else it 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 TLV3.10. IPv6-Forwarding-Address Sub-TLV
this sub-TLV has the same semantics as the optional forwarding address in Appendix A.4.7 of [OSPFV3] 🧚 It applies to the External-Prefix TLV (Section 3.6). Using it as a sub-TLV of other TLVs isn't defined here. It's optional, and the first instance you see is the one used as the forwarding address (as defined in [OSPFV3]). Any instances after the first MUST be ignored 🙈
This one is for IPv6 address families as defined in [OSPFV3-AF]. For other address families it MUST be ignored. Also, the IPv6-Forwarding-Address TLV length must meet a minimum length (16 octets), or it counts as 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 buddy 🎀 It has the same semantics as the optional forwarding address in Appendix A.4.7 of [OSPFV3] and applies to the External-Prefix TLV (Section 3.6). Using it as a sub-TLV of other TLVs isn't defined here. It's optional, and the first specified instance is the forwarding address (as defined in [OSPFV3]). Any instances after the first MUST be ignored 🙈
This one is for IPv4 address families as defined in [OSPFV3-AF]. For other address families it MUST be ignored. The IPv4-Forwarding-Address TLV length must meet a minimum length (4 octets), or it's 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 TLV3.12. Route-Tag Sub-TLV 🎀
okay bestie, the optional Route-Tag sub-TLV 💅 has identical semantics to the optional External Route Tag in Appendix A.4.7 of [OSPFV3], so it's giving continuity ✨. It's applicable to the External-Prefix TLV (Section 3.6). Specifying it as a sub-TLV of other TLVs is not defined here 🙅♀️. The sub-TLV is optional, and the first specified instance is used as the Route Tag as defined in [OSPFV3]. Any instances after the first MUST be ignored 🚫 (no drama, just skip them).
The Route-Tag TLV length must meet a minimum length (4 octets), or it will be considered malformed as described in Section 6.3 💀. Here's the layout 👇
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-TLV4. OSPFv3 Extended LSAs ✨
okay so this section is where the OSPFv3 Extended LSA formats and encoding get specified 🧚. The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3 LSAs specified in [OSPFV3]. Same vibes, just upgraded 🦋.
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 Appendix A.4.3 of [OSPFV3]. BUT, unlike the existing Router-LSA, it is fully 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|1| 0x21 |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |Nt|x|V|E|B| Options |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Extended Router-LSAOther than having a different LS Type, all LSA Header fields are the same as defined for the Router-LSA 💖. Initially, only the top-level Router-Link TLV (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 any TLVs ⭐. Depending on the implementation, it is perfectly valid for an E-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 in Appendix A.4.4 of [OSPFV3]. Again, unlike the existing Network-LSA, it's fully 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|1| 0x22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Network-LSAOther than having a different LS Type, all LSA Header fields are the same as defined for the Network-LSA 🫶. Like the existing Network-LSA, the LSA length is used to determine the end of the LSA including any TLVs. Initially, only the top-level Attached-Routers TLV (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 🚫.
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 Appendix A.4.5 of [OSPFV3]. However, unlike the existing Inter-Area-Prefix-LSA, it is fully 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|1| 0x23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Inter-Area-Prefix-LSAOther than having a different LS Type, all LSA Header fields are the same as defined for the Inter-Area-Prefix-LSA 🎀. To keep compatibility and semantics with the current OSPFv3 specification, each Inter-Area-Prefix LSA MUST contain a single Inter-Area-Prefix TLV. This makes migration way easier and avoids changes to functions such as incremental Shortest Path First (SPF) computation ✨.
Like the existing Inter-Area-Prefix-LSA, the LSA length is used to determine the end of the LSA including any TLVs. Initially, only the top-level Inter-Area-Prefix TLV (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 in Appendix A.4.6 of [OSPFV3]. However, unlike the Inter-Area-Router-LSA, it is fully 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|1| 0x24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Inter-Area-Router-LSAOther than having a different LS Type, all LSA Header fields are the same as defined for the Inter-Area-Router-LSA. To keep compatibility and semantics with the current OSPFv3 specification, each Inter-Area-Router-LSA MUST contain a single Inter-Area-Router TLV. This will facilitate migration and avoid changes to functions such as incremental SPF computation 🌸.
Like the existing Inter-Area-Router-LSA, the LSA length is used to determine the end of the LSA including any TLVs. Initially, only the top-level Inter-Area-Router TLV (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 ✨
okay so the E-AS-External-LSA has an LS Type of 0xC025 💖 and it carries the same base info as the AS-External-LSA from Appendix A.4.7 of [OSPFV3]. the glow-up is that it's fully extensible and written as TLVs, so it's giving future-proof energy 🦋
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-LSAso other than the different LS Type, all the LSA Header fields are the same as the AS-External-LSA's. 🎀 to keep compatibility and semantics with the current OSPFv3 spec, each LSA MUST contain a single External-Prefix TLV. this makes migrating easier and means we don't have to mess with OSPFv3 stuff like incremental SPF computation 🧚
like the old AS-External-LSA, the LSA length is what tells you where the LSA ends, TLVs included. at first, only the top-level External-Prefix TLV (Section 3.6) is applicable. if the External-Prefix TLV isn't in the E-External-AS-LSA, it's treated as malformed, as described in Section 5. 💀 instances of the External-Prefix TLV after the first MUST be ignored, no exceptions bestie 🙅♀️
4.6. OSPFv3 E-NSSA-LSA 🌸
the E-NSSA-LSA has the same format and TLVs as the Extended AS-External-LSA (Section 4.5). it's the same relationship the NSSA-LSA (from Appendix A.4.8 of [OSPFV3]) has with the AS-External-LSA 💅 the NSSA-LSA gets type 0xA027, which means area flooding scope. future requirements might make the supported TLVs differ between the E-AS-External-LSA and the E-NSSA-LSA, but future requirements are beyond the scope of this document, so that's a later problem 🙈
4.7. OSPFv3 E-Link-LSA 🔥
the E-Link-LSA has an LS Type of 0x8028 and has the same base info as the Link-LSA from Appendix A.4.9 of [OSPFV3]. but unlike the old Link-LSA, it's fully extensible and written as TLVs. iconic 👑
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-LSAother than the different LS Type, all the LSA Header fields are the same as the Link-LSA's ✨
only the Intra-Area-Prefix TLV (Section 3.7), the IPv6 Link-Local Address TLV (Section 3.8), and the IPv4 Link-Local Address TLV (Section 3.9) are applicable to the E-Link-LSA. like the Link-LSA, the E-Link-LSA lets you advertise multiple intra-area prefixes, so multiple Intra-Area-Prefix TLVs (Section 3.7) may be specified, and the LSA length marks the end of the LSA, TLVs and all 🦋
a single instance of the IPv6 Link-Local Address TLV (Section 3.8) SHOULD be included in the E-Link-LSA. instances after 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 after 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 that matches the OSPFv3 Address Family isn't in the E-Link-LSA, it's treated as malformed, as described in Section 5. 😭
future specs might support advertising routing and topology info for multiple address families, but that's 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 the same base info as the Intra-Area-Prefix-LSA from Appendix A.4.10 of [OSPFV3], except for the Referenced LS Type. again, unlike the old one, it's fully extensible and written as TLVs. the Referenced LS Type MUST be either an E-Router-LSA (0xA021) or an E-Network-LSA (0xA022). no other vibes allowed 🙅♀️
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-LSAother than the different LS Type, all the LSA Header fields are the same as the Intra-Area-Prefix-LSA's 💜
like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords advertisement of multiple intra-area prefixes. so multiple Intra-Area-Prefix TLVs may be specified, and the LSA length defines the end of the LSA including any TLVs 🍓
5. Malformed OSPFv3 Extended LSA Handling 💀
okay this part is serious bestie 🫶 extended LSAs that have an inconsistent length or other encoding errors, as described in this doc, 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 length validation, a TLV or sub-TLV should not be considered invalid unless its length exceeds the length of the LSA or it doesn't meet the minimum length requirements for that TLV or sub-TLV. this leaves room for sub-TLVs to be added, as described in Section 6.3 ✨
additionally, an LSA MUST be considered malformed if it doesn't include all of the required TLVs and sub-TLVs. 🙈
6. LSA Extension Backward Compatibility 🦋
in the context of this document, backward compatibility is solely about whether an OSPFv3 router can receive, process, and originate the TLV-based LSAs defined here. unrecognized TLVs and sub-TLVs are ignored. backward compatibility for future OSPFv3 extensions that use 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 done by enabling AreaExtendedLSASupport (Appendix B) 💅
an OSPFv3 routing domain or area may be non-disruptively migrated using separate OSPFv3 instances for the Extended LSAs. at first, the OSPFv3 instances with ExtendedLSASupport will have a lower preference (i.e., higher administrative distance) than the OSPFv3 instances originating and using the Legacy LSAs. once the routing domain or area is fully migrated and the OSPFv3 Routing Information Bases (RIBs) have been verified, the instances using the Extended LSAs can be given preference. when that's done and 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 ✨
okay so sparse-mode is giving "low-key minimalist" 💅 OSPFv3 keeps using the Legacy LSAs for the SPF computation 🧮 and only originates Extended LSAs when it genuinely needs them to support some new functionality 🎀. Even then, those Extended LSAs only carry the top-level TLVs (like Router-Link TLVs or Inter-Area TLVs) that the new feature actually needs 🦋. bestie, the rule here is strict: if a top-level TLV is advertised, it MUST include its required sub-TLVs, or it counts as malformed as described in Section 5 🙈.
This is why it's called "sparse-mode" 🌸. The big perk is that features using Extended LSAs can be dropped into an existing OSPFv3 routing domain without anyone having to migrate first ✨ ngl, that's iconic. Honestly it's very much like the approach taken for OSPFv2 [OSPF-PREFIX-LINK] 👑. And just like every other compatibility mode, the backward compatibility for each function that uses Extended LSAs has to be spelled out in the IETF documents that describe that function 💜.
6.3. LSA TLV Processing Backward Compatibility 🧚
this section is where we lay down the general rules for processing LSA TLVs 📜. To keep future TLV-based LSA extensions compatible with each other, all implementations MUST follow these rules 💖:
- Unrecognized TLVs and sub-TLVs are ignored when parsing or processing Extended LSAs. 🫶
- Whether or not partial deployment of a given TLV is supported MUST be specified. 🌈
- If partial deployment is not supported, mechanisms to ensure the corresponding feature is not deployed MUST be specified in the document defining the new TLV or sub-TLV. 🔒
- If partial deployment is supported, backward compatibility and partial deployment MUST be specified in the document defining the new TLV or sub-TLV. ✨
- If a TLV or sub-TLV is recognized but the length is less than the minimum, then the LSA should be considered malformed, and it SHOULD NOT be acknowledged. Additionally, the occurrence SHOULD be logged with enough information to identify the LSA by type, Link State ID, originator, and sequence number and identify the TLV or sub-TLV in error. Ideally, the log entry would include the hexadecimal or binary representation of the LSA including the malformed TLV or sub-TLV. 🚨
- Documents specifying future TLVs or Sub-TLVs MUST specify the requirements for usage of those TLVs or sub-TLVs. 📝
- Future TLVs or sub-TLVs must be optional. However, there may be requirements for sub-TLVs if an optional TLV is specified. 🦋
7. Security Considerations 🔐
💀 bestie, this part is serious, so read it carefully.
In general, extensible 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. These have been added to the existing OSPFv3 LSA Function Codes registry. 🎀
The specification defines a code point for the N-bit in the OSPFv3 Prefix-Options registry. The value 0x20 has been assigned. 🌸
This specification also creates two registries for OSPFv3 Extended LSA TLVs and sub-TLVs. The TLV and sub-TLV code points in these registries are common to all Extended LSAs, and their respective definitions must define where they are applicable. 💜
8.1. OSPFv3 Extended LSA TLV Registry 🦋
The "OSPFv3 Extended LSA TLVs" registry defines top-level TLVs for Extended LSAs and has been placed in the existing OSPFv3 IANA registry. 🧚
Nine values have been allocated:
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 TLVTypes in the range 9-32767 are allocated via IETF Review or IESG Approval [RFC8126]. 🌈
Types in the range 32768-33023 are Reserved for Experimental Use; these will not be registered with IANA and MUST NOT be mentioned by RFCs. 🧪
Types in the range 33024-45055 are to be assigned on a First Come First Served (FCFS) basis. 🍓
Types in the range 45056-65535 are not to be assigned at this time. Before any assignments can be made in the 33024-65535 range, there MUST be an IETF specification that specifies IANA Considerations that cover the range being assigned. 🔒
8.2. OSPFv3 Extended LSA Sub-TLV Registry 🌟
The "OSPFv3 Extended LSA Sub-TLVs" registry defines sub-TLVs at any level of nesting for Extended LSAs and has been placed in the existing OSPFv3 IANA registry. 💅
Four values have been allocated:
o 0 - Reserved
o 1 - IPv6-Forwarding-Address sub-TLV
o 2 - IPv4-Forwarding-Address sub-TLV
o 3 - Route-Tag sub-TLVTypes in the range 4-32767 are allocated via IETF Review or IESG Approval. 🫶
Types in the range 32768-33023 are Reserved for Experimental Use; these will not be registered with IANA and MUST NOT be mentioned by RFCs. 🧪
Types in the range 33024-45055 are to be assigned on an FCFS basis. 🍓
Types in the range 45056-65535 are not to be assigned at this time. Before any assignments can be made in the 33024-65535 range, there MUST be an IETF specification that specifies IANA Considerations that cover the range being assigned. 🔒
9. References 📚
9.1. Normative References 💜
[NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
RFC 3101, DOI 10.17487/RFC3101, January 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, July 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, April 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, March 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,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 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, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[MT-OSPFV3]
Mirtorabi, S. and A. Roy, "Multi-topology routing in
OSPFv3 (MT-OSPFv3)", Work in 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, June
1997, <https://www.rfc-editor.org/info/rfc2154>.
[OSPF-PREFIX-LINK]
Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, 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", Work in Progress,
draft-ietf-ospf-ospfv3-segment-routing-extensions-11,
January 2018.Appendix A. Global Configuration Parameters ⚙️
The global configurable parameter ExtendedLSASupport is added to the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 router will originate OSPFv3 Extended LSAs and use the LSAs for the SPF computation. If ExtendedLSASupport is not enabled, a subset of OSPFv3 Extended LSAs may still be originated and used for other functions as described in Section 6.2. 🌈
Appendix B. Area Configuration Parameters 🗺️
The area configurable parameter AreaExtendedLSASupport is added to the OSPFv3 protocol. If AreaExtendedLSASupport is enabled, the OSPFv3 router will originate link and area OSPFv3 Extended LSAs and use the LSAs for the SPF computation. Legacy AS-Scoped LSAs will still be originated and used for the AS-External-LSA computation. If AreaExtendedLSASupport is not enabled, a subset of OSPFv3 link and area Extended LSAs may still be originated and used for other functions as described in Section 6.2. 🎀
For regular areas, i.e., areas where AS-scoped LSAs are flooded, disabling AreaExtendedLSASupport for a regular OSPFv3 area (not a Stub or NSSA area) when ExtendedLSASupport is enabled is contradictory and SHOULD be prohibited by implementations. 🙅♀️
Acknowledgments 🫶
OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3]. 🌸
Huge thanks to Peter Psenak for significant contributions to the backward-compatibility mechanisms. 👑
Thanks to Michael Barnes, Mike Dubrovsky, Anton Smirnov, and Tony Przygienda for reviewing the draft versions and for the discussions on backward compatibility. 💖
Thanks to Alan Davey for review and comments, including the suggestion to separate the Extended LSA TLV definitions from the Extended LSAs definitions. ✨
Thanks to David Lamparter for review and suggestions on backward compatibility. 🦋
Thanks to Karsten Thomann, Chris Bowers, Meng Zhang, and Nagendra Kumar for review and editorial comments. 💅
Thanks to Alia Atlas for substantive Routing Area Director (AD) comments prior to IETF last call. 🧚
Thanks to Alvaro Retana and Suresh Krishnan for substantive comments during IESG Review. 🌟
Thanks to Mehmet Ersue for the Operations and Management (OPS) Directorate review. 🍓
Contributors 🌈
Sina Mirtorabi
Cisco Systems
170 Tasman Drive
San Jose, CA 95134
United States of America
Email: sina@cisco.comAuthors' Addresses 💌
Acee Lindem
Cisco Systems
301 Midenhall Way
Cary, NC 27513
United States of America
Email: acee@cisco.com
Abhay Roy
Cisco Systems
170 Tasman Drive
San Jose, CA 95134
United 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 93117
United States of America
Email: FredBaker.IETF@gmail.com📦 where this page comes from
- ietf: rfc8362 2018-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms