idnits 2.17.1 draft-ietf-ospf-ospfv3-lsa-extend-23.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5838, but the abstract doesn't seem to directly say this. It does mention RFC5838 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5340, updated by this document, for RFC5378 checks: 2004-11-30) (Using the creation date from RFC5838, updated by this document, for RFC5378 checks: 2004-04-06) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 25, 2018) is 2282 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Unexpected draft version: The latest known version of draft-ietf-ospf-mt-ospfv3 is -03, but you're referring to -04. == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-10 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem 3 Internet-Draft A. Roy 4 Updates: 5340, 5838 (if approved) Cisco Systems 5 Intended status: Standards Track D. Goethals 6 Expires: July 29, 2018 Nokia 7 V. Reddy Vallem 9 F. Baker 10 January 25, 2018 12 OSPFv3 LSA Extendibility 13 draft-ietf-ospf-ospfv3-lsa-extend-23.txt 15 Abstract 17 OSPFv3 requires functional extension beyond what can readily be done 18 with the fixed-format Link State Advertisement (LSA) as described in 19 RFC 5340. Without LSA extension, attributes associated with OSPFv3 20 links and advertised IPv6 prefixes must be advertised in separate 21 LSAs and correlated to the fixed-format LSAs. This document extends 22 the LSA format by encoding the existing OSPFv3 LSA information in 23 Type-Length-Value (TLV) tuples and allowing advertisement of 24 additional information with additional TLVs. Backward compatibility 25 mechanisms are also described. 27 This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, 28 "Support of Address Families in OSPFv3" by providing TLV-based 29 encodings for the base OSPFv3 unicast support and OSPFv3 address 30 family support. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 29, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 68 1.2. OSPFv3 LSA Terminology . . . . . . . . . . . . . . . . . 4 69 2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 4 70 3. OSPFv3 Extended LSA TLVs . . . . . . . . . . . . . . . . . . 5 71 3.1. Prefix Options Extensions . . . . . . . . . . . . . . . . 6 72 3.1.1. N-bit Prefix Option . . . . . . . . . . . . . . . . . 6 73 3.2. Router-Link TLV . . . . . . . . . . . . . . . . . . . . . 7 74 3.3. Attached-Routers TLV . . . . . . . . . . . . . . . . . . 8 75 3.4. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 10 76 3.5. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 11 77 3.6. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 12 78 3.7. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 13 79 3.8. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 14 80 3.9. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 15 81 3.10. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16 82 3.11. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16 83 3.12. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 17 84 4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . 17 85 4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 17 86 4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . 19 87 4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . 20 88 4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . 21 89 4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . 22 90 4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 23 91 4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 24 92 4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . 26 93 5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . 27 94 6. LSA Extension Backward Compatibility . . . . . . . . . . . . 27 95 6.1. Full Extended LSA Migration . . . . . . . . . . . . . . . 27 96 6.2. Extended LSA Sparse-Mode Backward Compatibility . . . . . 28 97 6.3. LSA TLV Processing Backward Compatibility . . . . . . . . 28 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 100 8.1. OSPFv3 Extended-LSA TLV Registry . . . . . . . . . . . . 29 101 8.2. OSPFv3 Extended-LSA sub-TLV Registry . . . . . . . . . . 30 102 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 104 10.1. Normative References . . . . . . . . . . . . . . . . . . 31 105 10.2. Informative References . . . . . . . . . . . . . . . . . 31 106 Appendix A. Appendix A - Global Configuration Parameters . . . . 32 107 Appendix B. Appendix B - Area Configuration Parameters . . . . . 32 108 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 33 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 111 1. Introduction 113 OSPFv3 requires functional extension beyond what can readily be done 114 with the fixed-format Link State Advertisement (LSA) as described in 115 RFC 5340 [OSPFV3]. Without LSA extension, attributes associated with 116 OSPFv3 links and advertised IPv6 prefixes must be advertised in 117 separate LSAs and correlated to the fixed-format LSAs. This document 118 extends the LSA format by encoding the existing OSPFv3 LSA 119 information in Type-Length-Value (TLV) tuples and allowing 120 advertisement of additional information with additional TLVs. 121 Backward compatibility mechanisms are also described. 123 This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, 124 "Support of Address Families in OSPFv3" by providing TLV-based 125 encodings for the base OSPFv3 support [OSPFV3] and OSPFv3 address 126 family support [OSPFV3-AF]. 128 A similar extension was previously proposed in support of multi- 129 topology routing. Additional requirements for OSPFv3 LSA extension 130 include source/destination routing, route tagging, and others. 132 A final requirement is to limit the changes to OSPFv3 to those 133 necessary for TLV-based LSAs. For the most part, the semantics of 134 existing OSPFv3 LSAs are retained for their TLV-based successor LSAs 135 described herein. Additionally, encoding details, e.g., the 136 representation of IPv6 prefixes as described in section A.4.1 in RFC 137 5340 [OSPFV3], have been retained. This requirement was included to 138 increase the expedience of IETF adoption and deployment. 140 The following aspects of OSPFv3 LSA extension are described: 142 1. Extended LSA Types 144 2. Extended LSA TLVs 145 3. Extended LSA Formats 147 4. Backward Compatibility 149 1.1. Requirements notation 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 1.2. OSPFv3 LSA Terminology 159 The TLV-based OSPFv3 LSAs described in this document will be referred 160 to as Extended LSAs. The OSPFv3 fixed-format LSAs [OSPFV3] will be 161 referred to as Legacy LSAs. 163 2. OSPFv3 Extended LSA Types 165 In order to provide backward compatibility, new LSA codes must be 166 allocated. There are eight fixed-format LSAs defined in RFC 5340 167 [OSPFV3]. For ease of implementation and debugging, the LSA function 168 codes are the same as the fixed-format LSAs only with 32, i.e., 0x20, 169 added. The alternative to this mapping was to allocate a bit in the 170 LS Type indicating the new LSA format. However, this would have used 171 one half the LSA function code space for the migration of the eight 172 original fixed-format LSAs. For backward compatibility, the U-bit 173 MUST be set in LS Type so that the LSAs will be flooded by OSPFv3 174 routers that do not understand them. 176 LSA function code LS Type Description 177 ---------------------------------------------------- 178 33 0xA021 E-Router-LSA 179 34 0xA022 E-Network-LSA 180 35 0xA023 E-Inter-Area-Prefix-LSA 181 36 0xA024 E-Inter-Area-Router-LSA 182 37 0xC025 E-AS-External-LSA 183 38 N/A Unused (Not to be allocated) 184 39 0xA027 E-Type-7-LSA 185 40 0x8028 E-Link-LSA 186 41 0xA029 E-Intra-Area-Prefix-LSA 188 OSPFv3 Extended LSA Types 190 3. OSPFv3 Extended LSA TLVs 192 The format of the TLVs within the body of the extended LSAs is the 193 same as the format used by the Traffic Engineering Extensions to OSPF 194 [TE]. The variable TLV section consists of one or more nested 195 Type/Length/Value (TLV) tuples. Nested TLVs are also referred to as 196 sub-TLVs. The format of each TLV is: 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Type | Length | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Value... | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 TLV Format 208 The Length field defines the length of the value portion in octets 209 (thus, a TLV with no value portion would have a length of 0). The 210 TLV is padded to 4-octet alignment; padding is not included in the 211 length field (so a 3-octet value would have a length of 3, but the 212 total size of the TLV would be 8 octets). Nested TLVs are also 213 32-bit aligned. For example, a 1-byte value would have the length 214 field set to 1, and 3 octets of padding would be added to the end of 215 the value portion of the TLV. 217 This document defines the following top-level TLV types: 219 o 0 - Reserved 221 o 1 - Router-Link TLV 223 o 2 - Attached-Routers TLV 225 o 3 - Inter-Area Prefix TLV 227 o 4 - Inter-Area Router TLV 229 o 5 - External Prefix TLV 231 o 6 - Intra-Area Prefix TLV 233 o 7 - IPv6 Link-Local Address TLV 235 o 8 - IPv4 Link-Local Address TLV 236 Additionally, this document defines the following sub-TLV types: 238 o 0 - Reserved 240 o 1 - IPv6 Forwarding Address sub-TLV 242 o 2 - IPv4 Forwarding Address sub-TLV 244 o 3 - Route Tag sub-TLV 246 In general, TLVs and sub-TLVs MAY occur in any order and the 247 specification should define whether the TLV or sub-TLV is required 248 and the behavior when there are multiple occurrences of the TLV or 249 sub-TLV. While this document only describes the usage of TLVs and 250 Sub-TLVs, Sub-TLVs may be nested to any level as long as the Sub-TLVs 251 are fully specified in the specification for the subsuming Sub-TLV. 253 For backward compatibility, an LSA is not considered malformed from a 254 TLV perspective unless either a required TLV is missing or a 255 specified TLV is less than the minimum required length. Refer to 256 Section 6.3 for more information on TLV backward compatibility. 258 3.1. Prefix Options Extensions 260 The prefix options are extended from Appendix A.4.1.1 [OSPFV3]. The 261 applicability of the LA-bit is expanded and it SHOULD be set in 262 Inter-Area-Prefix-TLVs and MAY be set in External-Prefix-TLVs when 263 the advertised host IPv6 address, i.e., PrefixLength = 128, is an 264 interface address. In RFC 5340, the LA-bit is only set in Intra- 265 Area-Prefix-LSAs (Section 4.4.3.9 in [OSPFV3]). This will allow a 266 stable address to be advertised without having to configure a 267 separate loopback address in every OSPFv3 area. 269 3.1.1. N-bit Prefix Option 271 Additionally, the N-bit prefix option is defined. The figure below 272 shows the position of the N-bit in the prefix options (pending IANA 273 allocation). This corresponds to the value 0x20. 275 0 1 2 3 4 5 6 7 276 +--+--+--+--+--+--+--+--+ 277 | | | N|DN| P| x|LA|NU| 278 +--+--+--+--+--+--+--+--+ 280 The Prefix Options field 282 The N-bit is set in PrefixOptions for a host address 283 (PrefixLength=128) that identifies the advertising router. While it 284 is similar to the LA-bit, there are two differences. The advertising 285 router MAY choose NOT to set the N-bit even when the above conditions 286 are met. If the N-bit is set and the PrefixLength is NOT 128, the 287 N-bit MUST be ignored. Additionally, the N-bit is propagated in the 288 PrefixOptions when an OSPFv3 Area Border Router (ABR) originates an 289 Inter-Area-Prefix-LSA for an Intra-Area route which has the N-bit set 290 in the PrefixOptions. Similarly, the N-bit is propagated in the 291 PrefixOptions when an OSPFv3 NSSA ABR originates an E-AS-External-LSA 292 corresponding to an NSSA route as described in section 3 of RFC 3101 293 ([NSSA]). The N-bit is added to the Inter-Area-Prefix-TLV 294 (Section 3.4), External-Prefix-TLV (Section 3.6), and Intra-Area- 295 Prefix-TLV (Section 3.7). The N-bit is used as hint to identify the 296 preferred address to reach the advertising OSPFv3 router. This would 297 be in contrast to an Anycast Address [IPV6-ADDRESS-ARCH] which could 298 also be a local address with the LA-bit set. It is useful for 299 applications such as identifying the prefixes corresponding to Node 300 Segment Identifiers (SIDs) in Segment Routing [SEGMENT-ROUTING]. 301 There may be future applications requiring selection of a prefix 302 associated with an OSPFv3 router. 304 3.2. Router-Link TLV 306 The Router-Link TLV defines a single router link and the field 307 definitions correspond directly to links in the OSPFv3 Router-LSA, 308 section A.4.3, [OSPFV3]. The Router-Link TLV is only applicable to 309 the E-Router-LSA (Section 4.1). Inclusion in other Extended LSAs 310 MUST be ignored. 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | 1 (Router-Link) | TLV Length | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type | 0 | Metric | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Interface ID | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Neighbor Interface ID | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Neighbor Router ID | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 . . 326 . sub-TLVs . 327 . . 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Router-Link TLV 332 3.3. Attached-Routers TLV 334 The Attached-Routers TLV defines all the routers attached to an 335 OSPFv3 multi-access network. The field definitions correspond 336 directly to content of the OSPFv3 Network-LSA, section A.4.4, 337 [OSPFV3]. The Attached-Routers TLV is only applicable to the E- 338 Network-LSA (Section 4.2). Inclusion in other Extended LSAs MUST be 339 ignored. 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | 2 (Attached-Routers) | TLV Length | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Adjacent Neighbor Router ID | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 . . 349 . Additional Adjacent Neighbors . 350 . . 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Attached-Routers TLV 355 There are two reasons for not having a separate TLV or sub-TLV for 356 each adjacent neighbor. The first is to discourage using the E- 357 Network-LSA for more than its current role of solely advertising the 358 routers attached to a multi-access network. The router's metric as 359 well as the attributes of individual attached routers should be 360 advertised in their respective E-Router-LSAs. The second reason is 361 that there is only a single E-Network-LSA per multi-access link with 362 the Link State ID set to the Designated Router's Interface ID and, 363 consequently, compact encoding has been chosen to decrease the 364 likelihood that the size of the E-Network-LSA will require IPv6 365 fragmentation when advertised in an OSPFv3 Link State Update packet. 367 3.4. Inter-Area-Prefix TLV 369 The Inter-Area-Prefix TLV defines a single OSPFV3 inter-area prefix. 370 The field definitions correspond directly to the content of an OSPFv3 371 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 372 Inter-Area-Prefix-LSA, as defined in section A.4.5, [OSPFV3]. 373 Additionally, the PrefixOptions are extended as described in 374 Section 3.1. The Inter-Area-Prefix TLV is only applicable to the E- 375 Inter-Area-Prefix-LSA (Section 4.3). Inclusion in other Extended 376 LSAs MUST be ignored. 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | 3 (Inter-Area Prefix) | TLV Length | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | 0 | Metric | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | PrefixLength | PrefixOptions | 0 | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Address Prefix | 388 | ... | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 . . 391 . sub-TLVs . 392 . . 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Inter-Area Prefix TLV 397 3.5. Inter-Area-Router TLV 399 The Inter-Area-Router TLV defines a single OSPFv3 Autonomous System 400 Boundary Router (ASBR) reachable in another area. The field 401 definitions correspond directly to the content of an OSPFv3 Inter- 402 Area-Router-LSA, as defined in section A.4.6, [OSPFV3]. The Inter- 403 Area-Router TLV is only applicable to the E-Inter-Area-Router-LSA 404 (Section 4.4). Inclusion in other Extended LSAs MUST be ignored. 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | 4 (Inter-Area Router) | TLV Length | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | 0 | Options | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | 0 | Metric | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Destination Router ID | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 . . 418 . sub-TLVs . 419 . . 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Inter-Area Router TLV 424 3.6. External-Prefix TLV 426 The External-Prefix TLV defines a single OSPFv3 external prefix. 427 With the exception of omitted fields noted below, the field 428 definitions correspond directly to the content of an OSPFv3 IPv6 429 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 AS- 430 External-LSA, as defined in section A.4.7, [OSPFV3]. The External- 431 Prefix TLV is only applicable to the E-AS-External-LSA (Section 4.5) 432 and the E-NSSA-LSA (Section 4.6). Additionally, the PrefixOptions 433 are extended as described in Section 3.1. Inclusion in other 434 Extended LSAs MUST be ignored. 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | 5 (External Prefix) | TLV Length | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | |E| | | Metric | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | PrefixLength | PrefixOptions | 0 | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Address Prefix | 446 | ... | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 . . 449 . sub-TLVs . 450 . . 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 External Prefix TLV 455 In the External-Prefix TLV, the optional IPv6/IPv4 Forwarding Address 456 and External Route Tag are now sub-TLVs. Given the Referenced LS 457 type and Referenced Link State ID from the AS-External-LSA have never 458 been used or even specified, they have been omitted from the External 459 Prefix TLV. If there were ever a requirement for a referenced LSA, 460 it could be satisfied with a sub-TLV. 462 The following sub-TLVs are defined for optional inclusion in the 463 External Prefix TLV: 465 o 1 - IPv6 Forwarding Address sub-TLV (Section 3.10) 467 o 2 - IPv4 Forwarding Address sub-TLV (Section 3.11) 469 o 3 - Route Tag sub-TLV (Section 3.12) 471 3.7. Intra-Area-Prefix TLV 473 The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix. 474 The field definitions correspond directly to the content of an OSPFv3 475 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 Link- 476 LSA, as defined in section A.4.9, [OSPFV3]. The Intra-Area-Prefix 477 TLV is only applicable to the E-Link-LSA (Section 4.7) and the E- 478 Intra-Area-Prefix-LSA (Section 4.8). Additionally, the PrefixOptions 479 are extended as described in Section 3.1. Inclusion in other 480 Extended LSAs MUST be ignored. 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | 6 (Intra-Area Prefix) | TLV Length | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | 0 | Metric | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | PrefixLength | PrefixOptions | 0 | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Address Prefix | 492 | ... | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 . . 495 . sub-TLVs . 496 . . 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 Intra-Area Prefix TLV 501 3.8. IPv6 Link-Local Address TLV 503 The IPv6 Link-Local Address TLV is to be used with IPv6 address 504 families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV 505 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 506 other Extended LSAs MUST be ignored. 508 0 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | 7 (IPv6 Local-Local Address) | TLV Length | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | | 514 +- -+ 515 | | 516 +- IPv6 Link-Local Interface Address -+ 517 | | 518 +- -+ 519 | | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 . . 522 . sub-TLVs . 523 . . 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 IPv6 Link-Local Address TLV 528 3.9. IPv4 Link-Local Address TLV 530 The IPv4 Link-Local Address TLV is to be used with IPv4 address 531 families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV 532 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 533 other Extended LSAs MUST be ignored. 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | 8 (IPv4 Local-Local Address) | TLV Length | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | IPv4 Link-Local Interface Address | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 . . 543 . sub-TLVs . 544 . . 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 IPv4 Link-Local Address TLV 549 3.10. IPv6-Forwarding-Address Sub-TLV 551 The IPv6 Forwarding Address TLV has identical semantics to the 552 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv6 553 Forwarding Address TLV is applicable to the External-Prefix TLV 554 (Section 3.6). Specification as a sub-TLV of other TLVs is not 555 defined herein. The sub-TLV is optional and the first specified 556 instance is used as the Forwarding Address as defined in [OSPFV3]. 557 Instances subsequent to the first MUST be ignored. 559 The IPv6 Forwarding Address TLV is to be used with IPv6 address 560 families as defined in [OSPFV3-AF] It MUST be ignored for other 561 address families. The IPv6 Forwarding Address TLV length must meet 562 minimum length (16 octets) or it will be considered malformed as 563 described in Section 6.3. 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | 1 - Forwarding Address | sub-TLV Length | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | | 571 +- -+ 572 | | 573 +- Forwarding Address -+ 574 | | 575 +- -+ 576 | | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 IPv6 Forwarding Address TLV 581 3.11. IPv4-Forwarding-Address Sub-TLV 583 The IPv4 Forwarding Address TLV has identical semantics to the 584 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv4 585 Forwarding Address TLV is The IPv4 Forwarding Address TLV is 586 applicable to the External-Prefix TLV (Section 3.6). Specification 587 as a sub-TLV of other TLVs is not defined herein. The sub-TLV is 588 optional and the first specified instance is used as the Forwarding 589 Address as defined in [OSPFV3]. Instances subsequent to the first 590 MUST be ignored. 592 The IPv4 Forwarding Address TLV is to be used with IPv4 address 593 families as defined in [OSPFV3-AF] It MUST be ignored for other 594 address families. The IPv4 Forwarding Address TLV length must meet 595 minimum length (4 octets) or it will be considered malformed as 596 described in Section 6.3. 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | 2 - Forwarding Address | sub-TLV Length | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Forwarding Address | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 IPv4 Forwarding Address TLV 608 3.12. Route-Tag Sub-TLV 610 The optional Route Tag sub-TLV has identical semantics to the 611 optional External Route Tag in section A.4.7 of [OSPFV3]. The Route 612 Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.6). 613 Specification as a sub-TLV of other TLVs is not defined herein. The 614 sub-TLV is optional and the first specified instance is used as the 615 Route Tag as defined in [OSPFV3]. Instances subsequent to the first 616 MUST be ignored. 618 The Route Tag TLV length must meet minimum length (4 octets) or it 619 will be considered malformed as described in Section 6.3. 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | 3 - Route Tag | sub-TLV Length | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Route Tag | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 Route Tag Sub-TLV 631 4. OSPFv3 Extended LSAs 633 This section specifies the OSPFv3 Extended LSA formats and encoding. 634 The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3 635 LSAs specified in [OSPFV3]. 637 4.1. OSPFv3 E-Router-LSA 639 The E-Router-LSA has an LS Type of 0xA021 and has the same base 640 information content as the Router-LSA defined in section A.4.3 of 641 [OSPFV3]. However, unlike the existing Router-LSA, it is fully 642 extendable and represented as TLVs. 644 0 1 2 3 645 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 646 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | LS Age |1|0|1| 0x21 | 648 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Link State ID | 650 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Advertising Router | 652 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | LS Sequence Number | 654 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | LS Checksum | Length | 656 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | 0 |Nt|x|V|E|B| Options | 658 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 . . 660 . TLVs . 661 . . 662 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 Extended Router-LSA 666 Other than having a different LS Type, all LSA Header fields are the 667 same as defined for the Router-LSA. Initially, only the top-level 668 Router-Link TLV Section 3.2 is applicable and an E-Router-LSA may 669 include multiple Router-Link TLVs. Like the existing Router-LSA, the 670 LSA length is used to determine the end of the LSA including TLVs. 671 Depending on the implementation, it is perfectly valid for an E- 672 Router-LSA to not contain any Router-Link TLVs. However, this would 673 imply that the OSPFv3 router doesn't have any adjacencies in the 674 corresponding area and is forming an adjacency or adjacencies over 675 unnumbered link(s). Note that no E-Router-LSA stub link is 676 advertised for an unnumbered link. 678 4.2. OSPFv3 E-Network-LSA 680 The E-Network-LSA has an LS Type of 0xA022 and has the same base 681 information content as the Network-LSA defined in section A.4.4 of 682 [OSPFV3]. However, unlike the existing Network-LSA, it is fully 683 extendable and represented as TLVs. 685 0 1 2 3 686 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 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | LS Age |1|0|1| 0x22 | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Link State ID | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Advertising Router | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | LS Sequence Number | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | LS Checksum | Length | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | 0 | Options | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 . . 701 . TLVs . 702 . . 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 E-Network-LSA 707 Other than having a different LS Type, all LSA Header fields are the 708 same as defined for the Network-LSA. Like the existing Network-LSA, 709 the LSA length is used to determine the end of the LSA including 710 TLVs. Initially, only the top-level Attached-Routers TLV Section 3.3 711 is applicable. If the Attached-Router TLV is not included in the E- 712 Network-LSA, it is treated as malformed as described in Section 5. 713 Instances of the Attached-Router TLV subsequent to the first MUST be 714 ignored. 716 4.3. OSPFv3 E-Inter-Area-Prefix-LSA 718 The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same 719 base information content as the Inter-Area-Prefix-LSA defined in 720 section A.4.5 of [OSPFV3]. However, unlike the existing Inter-Area- 721 Prefix-LSA, it is fully extendable and represented as TLVs. 723 0 1 2 3 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | LS Age |1|0|1| 0x23 | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Link State ID | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Advertising Router | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | LS Sequence Number | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | LS Checksum | Length | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 . . 737 . TLVs . 738 . . 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 E-Inter-Area-Prefix-LSA 743 Other than having a different LS Type, all LSA Header fields are the 744 same as defined for the Inter-Area-Prefix-LSA. In order to retain 745 compatibility and semantics with the current OSPFv3 specification, 746 each Inter-Area-Prefix LSA MUST contain a single Inter-Area Prefix 747 TLV. This will facilitate migration and avoid changes to functions 748 such as incremental SPF computation. 750 Like the existing Inter-Area-Prefix-LSA, the LSA length is used to 751 determine the end of the LSA including TLV. Initially, only the top- 752 level Inter-Area-Prefix TLV (Section 3.4) is applicable. If the 753 Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA, 754 it is treated as malformed as described in Section 5. Instances of 755 the Inter-Area-Prefix TLV subsequent to the first MUST be ignored. 757 4.4. OSPFv3 E-Inter-Area-Router-LSA 759 The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same 760 base information content as the Inter-Area-Router-LSA defined in 761 section A.4.6 of [OSPFV3]. However, unlike the Inter-Area-Router- 762 LSA, it is fully extendable and represented as TLVs. 764 0 1 2 3 765 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 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | LS Age |1|0|1| 0x24 | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Link State ID | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Advertising Router | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | LS Sequence Number | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | LS Checksum | Length | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 . . 778 . TLVs . 779 . . 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 E-Inter-Area-Router-LSA 784 Other than having a different LS Type, all LSA Header fields are the 785 same as defined for the Inter-Area-Router-LSA. In order to retain 786 compatibility and semantics with the current OSPFv3 specification, 787 each Inter-Area-Router LSA MUST contain a single Inter-Area Router 788 TLV. This will facilitate migration and avoid changes to functions 789 such as incremental SPF computation. 791 Like the existing Inter-Area-Router-LSA, the LSA length is used to 792 determine the end of the LSA including TLV. Initially, only the top- 793 level Inter-Area-Router TLV (Section 3.5) is applicable. If the 794 Inter-Area-Router TLV is not included in the E-Inter-Area-Router-LSA, 795 it is treated as malformed as described in Section 5. Instances of 796 the Inter-Area-Router TLV subsequent to the first MUST be ignored. 798 4.5. OSPFv3 E-AS-External-LSA 800 The E-AS-External-LSA has an LS Type of 0xC025 and has the same base 801 information content as the AS-External-LSA defined in section A.4.7 802 of [OSPFV3]. However, unlike the existing AS-External-LSA, it is 803 fully extendable and represented as TLVs. 805 0 1 2 3 806 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 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | LS Age |1|1|0| 0x25 | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Link State ID | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Advertising Router | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | LS Sequence Number | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | LS Checksum | Length | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 . . 819 . TLVs . 820 . . 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 E-AS-External-LSA 825 Other than having a different LS Type, all LSA Header fields are the 826 same as defined for the AS-External-LSA. In order to retain 827 compatibility and semantics with the current OSPFv3 specification, 828 each LSA MUST contain a single External Prefix TLV. This will 829 facilitate migration and avoid changes to OSPFv3 processes such as 830 incremental SPF computation. 832 Like the existing AS-External-LSA, the LSA length is used to 833 determine the end of the LSA including sub-TLVs. Initially, only the 834 top-level External-Prefix TLV (Section 3.6) is applicable. If the 835 External-Prefix TLV is not included in the E-External-AS-LSA, it is 836 treated as malformed as described in Section 5. Instances of the 837 External-Prefix TLV subsequent to the first MUST be ignored. 839 4.6. OSPFv3 E-NSSA-LSA 841 The E-NSSA-LSA will have the same format and TLVs as the Extended AS- 842 External-LSA Section 4.5. This is the same relationship as exists 843 between the NSSA-LSA defined in section A.4.8 of [OSPFV3], and the 844 AS-External-LSA. The NSSA-LSA will have type 0xA027 which implies 845 area flooding scope. Future requirements may dictate that supported 846 TLVs differ between the E-AS-External-LSA and the E-NSSA-LSA. 847 However, future requirements are beyond the scope of this document. 849 4.7. OSPFv3 E-Link-LSA 851 The E-Link-LSA has an LS Type of 0x8028 and will have the same base 852 information content as the Link-LSA defined in section A.4.9 of 853 [OSPFV3]. However, unlike the existing Link-LSA, it is extendable 854 and represented as TLVs. 856 0 1 2 3 857 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 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | LS Age |1|0|0| 0x28 | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Link State ID | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Advertising Router | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | LS Sequence Number | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | LS Checksum | Length | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Rtr Priority | Options | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 . . 872 . TLVs . 873 . . 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 E-Link-LSA 878 Other than having a different LS Type, all LSA Header fields are the 879 same as defined for the Link-LSA. 881 Only the Intra-Area-Prefix TLV (Section 3.7), IPv6 Link-Local Address 882 TLV (Section 3.8), and IPv4 Link-Local Address TLV (Section 3.9) are 883 applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA 884 affords advertisement of multiple intra-area prefixes. Hence, 885 multiple Intra-Area Prefix TLVs (Section 3.7) may be specified and 886 the LSA length defines the end of the LSA including all TLVs. 888 A single instance of the IPv6 Link-Local Address TLV (Section 3.8) 889 SHOULD be included in the E-Link-LSA. Instances following the first 890 MUST be ignored. For IPv4 address families as defined in 891 [OSPFV3-AF], this TLV MUST be ignored. 893 Similarly, only a single instance of the IPv4 Link-Local Address TLV 894 (Section 3.9) SHOULD be included in the E-Link-LSA. Instances 895 following the first MUST be ignored. For OSPFv3 IPv6 address 896 families as defined in [OSPFV3-AF], this TLV SHOULD be ignored. 898 If the IPv4/IPv6 Link-Local Address TLV corresponding to the OSPFv3 899 Address Family is not included in the E-Link-LSA, it is treated as 900 malformed as described in Section 5. 902 Future specifications may support advertisement of routing and 903 topology information for multiple address families. However, this is 904 beyond the scope of this document. 906 4.8. OSPFv3 E-Intra-Area-Prefix-LSA 908 The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same 909 base information content as the Intra-Area-Prefix-LSA defined in 910 section A.4.10 of [OSPFV3] except for the Referenced LS Type. 911 However, unlike the Intra-Area-Prefix-LSA, it is fully extendable and 912 represented as TLVs. The Referenced LS Type MUST be either an E- 913 Router-LSA (0xA021) or an E-Network-LSA (0xA022). 915 0 1 2 3 916 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 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | LS Age |1|0|1| 0x29 | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Link State ID | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Advertising Router | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | LS Sequence Number | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | LS Checksum | Length | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | 0 | Referenced LS Type | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Referenced Link State ID | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Referenced Advertising Router | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 . . 935 . TLVs . 936 . . 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 E-Intra-Area-Prefix-LSA 941 Other than having a different LS Type, all LSA Header fields are the 942 same as defined for the Intra-Area-Prefix-LSA. 944 Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords 945 advertisement of multiple intra-area prefixes. Hence, multiple 946 Intra-Area Prefix TLVs may be specified and the LSA length defines 947 the end of the LSA including all TLVs. 949 5. Malformed OSPFv3 Extended LSA Handling 951 Extended LSAs that have inconsistent length or other encoding errors, 952 as described herein, MUST NOT be installed in the Link State 953 Database, acknowledged, or flooded. Reception of malformed LSAs 954 SHOULD be counted and/or logged for examination by the administrator 955 of the OSPFv3 Routing Domain. Note that for the purposes of length 956 validation, a TLV or Sub-TLV should not be considered invalid unless 957 the length exceeds the length of the LSA or does not meet the minimum 958 length requirements. This allows for Sub-TLVs to be added as 959 described in Section 6.3. 961 Additionally, an LSA MUST be considered malformed if it does not 962 include all of the required TLVs and Sub-TLVs. 964 6. LSA Extension Backward Compatibility 966 In the context of this document, backward compatibility is solely 967 related to the capability of an OSPFv3 router to receive, process, 968 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 969 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 970 extensions utilizing the TLV-based LSAs is out of scope and must be 971 covered in the documents describing those extensions. Both full and, 972 if applicable, partial deployment SHOULD be specified for future TLV- 973 based OSPFv3 LSA extensions. 975 6.1. Full Extended LSA Migration 977 If ExtendedLSASupport is enabled Appendix A, OSPFv3 Extended LSAs 978 will be originated and used for the SPF computation. Individual OSPF 979 Areas can be migrated separately with the Legacy AS-External LSAs 980 being originated and used for the SPF computation. This is 981 accomplished by enabled AreaExtendedLSASupport Appendix B. 983 An OSPFv3 routing domain or area may be non-disruptively migrated 984 using separate OSPFv3 instances for the extended LSAs. Initially, 985 the OSPFv3 instances with ExtendedLSASupport will have a lower 986 preference, i.e., higher administrative distance, than the OSPFv3 987 instances originating and using the Legacy LSAs. Once the routing 988 domain or area is fully migrated and the OSPFv3 Routing Information 989 Bases (RIB) have been verified, the OSPFv3 instances using the 990 extended LSAs can be given preference. When this has been completed 991 and the routing within the OSPF routing domain or area has been 992 verified, the original OSPFv3 instance using Legacy LSAs can be 993 removed. 995 6.2. Extended LSA Sparse-Mode Backward Compatibility 997 In this mode, OSPFv3 will use the Legacy LSAs for the SPF computation 998 and will only originate extended LSAs when LSA origination is 999 required in support of additional functionality. Furthermore, those 1000 extended LSAs will only include the top-level TLVs (e.g., Router-Link 1001 TLVs or Inter-Area TLVs) which require further specification for that 1002 new functionality. However, if a top-level TLV is advertised, it 1003 MUST include required Sub-TLVs or it will be considered malformed as 1004 described in Section 5. Hence, this mode of compatibility is known 1005 as "sparse-mode". The advantage of sparse-mode is that functionality 1006 utilizing the OSPFv3 extended LSAs can be added to an existing OSFPv3 1007 routing domain without the requirement for migration. In essence, 1008 this compatibility mode is very much like the approach taken for 1009 OSPFv2 [OSPF-PREFIX-LINK]. As with all the compatibility modes, 1010 backward compatibility for the functions utilizing the extended LSAs 1011 must be described in the IETF documents describing those functions. 1013 6.3. LSA TLV Processing Backward Compatibility 1015 This section defines the general rules for processing LSA TLVs. To 1016 ensure compatibility of future TLV-based LSA extensions, all 1017 implementations MUST adhere to these rules: 1019 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or 1020 processing Extended-LSAs. 1022 2. Whether or not partial deployment of a given TLV is supported 1023 MUST be specified. 1025 3. If partial deployment is not supported, mechanisms to ensure the 1026 corresponding feature are not deployed MUST be specified in the 1027 document defining the new TLV or sub-TLV. 1029 4. If partial deployment is supported, backward compatibility and 1030 partial deployment MUST be specified in the document defining the 1031 new TLV or sub-TLV. 1033 5. If a TLV or Sub-TLV is recognized but the length is less than the 1034 minimum, then the LSA should be considered malformed and it 1035 SHOULD NOT be acknowledged. Additionally, the occurrence SHOULD 1036 be logged with enough information to identify the LSA by type, 1037 originator, and sequence number and the TLV or Sub-TLV in error. 1038 Ideally, the log entry would include the hexadecimal or binary 1039 representation of the LSA including the malformed TLS or Sub-TLV. 1041 6. Documents specifying future TLVs or Sub-TLVs MUST specify the 1042 requirements for usage of those TLVs or Sub-TLVs. 1044 7. Future TLV or Sub-TLVs must be optional. However, there may be 1045 requirements for Sub-TLVs if an optional TLV is specified. 1047 7. Security Considerations 1049 In general, extendible OSPFv3 LSAs are subject to the same security 1050 concerns as those described in RFC 5340 [OSPFV3]. Additionally, 1051 implementations must assure that malformed TLV and sub-TLV 1052 permutations do not result in errors that cause hard OSPFv3 failures. 1054 If there were ever a requirement to digitally sign OSPFv3 LSAs as 1055 described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the 1056 mechanisms described herein would greatly simplify the extension. 1058 8. IANA Considerations 1060 This specification defines nine OSPFv3 Extended LSA types as 1061 described in Section 2. These are added the existing OSPFv3 LSA 1062 Function Codes registry. 1064 The specification defines a new code point for the N-bit in the 1065 OSPFv3 Prefix-Options registry. The value 0x20 is suggested. 1067 This specification also creates two registries OSPFv3 Extended-LSAs 1068 TLVs and sub-TLVs. The TLV and sub-TLV code-points in these 1069 registries are common to all Extended-LSAs and their respective 1070 definitions must define where they are applicable. 1072 8.1. OSPFv3 Extended-LSA TLV Registry 1074 The OSPFv3 Extended-LSA TLV registry defines top-level TLVs for 1075 Extended-LSAs and should be placed in the existing OSPFv3 IANA 1076 registry. 1078 Nine values are allocated by this specification: 1080 o 0 - Reserved 1082 o 1 - Router-Link TLV 1084 o 2 - Attached-Routers TLV 1086 o 3 - Inter-Area Prefix TLV 1088 o 4 - Inter-Area Router TLV 1090 o 5 - External Prefix TLV 1091 o 6 - Intra-Area Prefix TLV 1093 o 7 - IPv6 Link-Local Address TLV 1095 o 8 - IPv4 Link-Local Address TLV 1097 Types in the range 9-32767 are allocated via IETF Consensus or IESG 1098 Approval. 1100 Types in the range 32768-33023 are for experimental use; these will 1101 not be registered with IANA, and MUST NOT be mentioned by RFCs. 1103 Types in the range 33024-45055 are to be assigned on a First-Come- 1104 First-Serve (FCFS) basis. 1106 Types in the range 45056-65535 are not to be assigned at this time. 1107 Before any assignments can be made in the 33024-65535 range, there 1108 MUST be an IETF specification that specifies IANA Considerations that 1109 covers the range being assigned. 1111 8.2. OSPFv3 Extended-LSA sub-TLV Registry 1113 The OSPFv3 Extended-LSA sub-TLV registry defines sub-TLVs at any 1114 level of nesting for Extended-LSAs and should be placed in the 1115 existing OSPFv3 IANA registry. 1117 Four values are allocated by this specification: 1119 o 0 - Reserved 1121 o 1 - IPv6 Forwarding Address sub-TLV 1123 o 2 - IPv4 Forwarding Address sub-TLV 1125 o 3 - Route Tag sub-TLV 1127 Types in the range 4-32767 are allocated via IETF Consensus or IESG 1128 Approval. 1130 Types in the range 32768-33023 are for experimental use; these will 1131 not be registered with IANA, and MUST NOT be mentioned by RFCs. 1133 Types in the range 33024-45055 are to be assigned on a First-Come- 1134 First-Serve (FCFS) basis. 1136 Types in the range 45056-65535 are not to be assigned at this time. 1137 Before any assignments can be made in the 33024-65535 range, there 1138 MUST be an IETF specification that specifies IANA Considerations that 1139 covers the range being assigned. 1141 9. Contributors 1143 Contributors' Addresses 1145 Sina Mirtorabi 1146 Cisco Systems 1147 170 Tasman Drive 1148 San Jose, CA 95134 1149 USA 1150 Email: sina@cisco.com 1152 10. References 1154 10.1. Normative References 1156 [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1157 RFC 3101, January 2003. 1159 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1160 for IPv6", RFC 5340, July 2008. 1162 [OSPFV3-AF] 1163 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 1164 Aggarwal, "Support of Address Families in OSPFv3", 1165 RFC 5838, April 2010. 1167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1168 Requirement Levels", RFC 2119, March 1997. 1170 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1171 2119 Key Words", RFC 8174, May 2017. 1173 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 1174 Extensions to OSPF", RFC 3630, September 2003. 1176 10.2. Informative References 1178 [IPV6-ADDRESS-ARCH] 1179 Hinden, R. and S. Deering, "IP Version 6 Addressing 1180 Architecture", RFC 4291, February 2006. 1182 [MT-OSPFV3] 1183 Mirtorabi, S. and A. Roy, "Multi-topology routing in 1184 OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt 1185 (work in progress), January 2008. 1187 [OSPF-DIGITAL-SIGNATURE] 1188 Murphy, S., Badger, M., and B. Wellington, "OSPF with 1189 Digital Signatures", RFC 2154, June 1997. 1191 [OSPF-PREFIX-LINK] 1192 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1193 Tantsura, J., and A. Lindem, "OSPF Prefix/Link 1194 Attributes", RFC 7684, December 2015. 1196 [SEGMENT-ROUTING] 1197 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1198 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1199 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1200 segment-routing-extensions-10.txt (work in progress), July 1201 2016. 1203 Appendix A. Appendix A - Global Configuration Parameters 1205 The global configurable parameter ExtendedLSASupport is added to the 1206 OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 Router 1207 will originate OSPFv3 Extended LSAs and use the LSAs for the SPF 1208 computation. If ExtendedLSASupport is not enabled, a subset of 1209 OSPFv3 Extended LSAs may still be originated and used for other 1210 functions as described in Section 6.2. 1212 Appendix B. Appendix B - Area Configuration Parameters 1214 The area configurable parameter AreaExtendedLSASupport is added to 1215 the OSPFv3 protocol. If AreaExtendedLSASupport is enabled, the 1216 OSPFv3 Router will originate link and area OSPFv3 Extended LSAs and 1217 use the LSAs for the SPF computation. Legacy AS-Scoped LSAs will 1218 still be originated and used for the AS External LSA computation. If 1219 AreaExtendedLSASupport is not enabled a subset of OSPFv3 link and 1220 area Extended LSAs may still be originated and used for other 1221 functions as described in Section 6.2. 1223 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1224 disabling AreaExtendedLSASupport for a regular OSPFv3 area (not a 1225 Stub or NSSA area) when ExtendedLSASupport is enabled is 1226 contradictory and SHOULD be prohibited by the implementation. 1228 Appendix C. Acknowledgments 1230 OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing 1231 in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3]. 1233 Thanks for Peter Psenak for significant contributions to the backward 1234 compatibility mechanisms. 1236 Thanks go to Michael Barnes, Mike Dubrovsky, Anton Smirnov, and Tony 1237 Przygienda for review of the draft versions and discussions of 1238 backward compatibility. 1240 Thanks to Alan Davey for review and comments including the suggestion 1241 to separate the extended LSA TLV definitions from the extended LSAs 1242 definitions. 1244 Thanks to David Lamparter for review and suggestions on backward 1245 compatibility. 1247 Thanks to Karsten Thomann, Chris Bowers, Meng Zhang, and Nagendra 1248 Kumar for review and editorial comments. 1250 Thanks to Alia Atlas for substantive Routing Area Director (AD) 1251 comments prior to IETF last call. 1253 Thanks to Alvaro Retana and Suresh Krishna for substantive comments 1254 during IESG Review. 1256 Thanks to Mehmet Ersue for OPS Directorate review. 1258 The RFC text was produced using Marshall Rose's xml2rfc tool. 1260 Authors' Addresses 1262 Acee Lindem 1263 Cisco Systems 1264 301 Midenhall Way 1265 Cary, NC 27513 1266 USA 1268 Email: acee@cisco.com 1269 Abhay Roy 1270 Cisco Systems 1271 170 Tasman Drive 1272 San Jose, CA 95134 1273 USA 1275 Email: akr@cisco.com 1277 Dirk Goethals 1278 Nokia 1279 Copernicuslaan 50 1280 Antwerp 2018 1281 Belgium 1283 Email: dirk.goethals@nokia.com 1285 Veerendranatha Reddy Vallem 1286 Bangalore 1287 India 1289 Email: vallem.veerendra@gmail.com 1291 Fred Baker 1292 Santa Barbara, California 93117 1293 USA 1295 Email: FredBaker.IETF@gmail.com