idnits 2.17.1 draft-ietf-ospf-ospfv3-lsa-extend-20.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 (December 26, 2017) is 2306 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: June 29, 2018 Nokia 7 V. Reddy Vallem 9 F. Baker 10 December 26, 2017 12 OSPFv3 LSA Extendibility 13 draft-ietf-ospf-ospfv3-lsa-extend-20.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". 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on June 29, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 66 1.2. OSPFv3 LSA Terminology . . . . . . . . . . . . . . . . . 4 67 2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 4 68 3. OSPFv3 Extended LSA TLVs . . . . . . . . . . . . . . . . . . 5 69 3.1. Prefix Options Extensions . . . . . . . . . . . . . . . . 6 70 3.1.1. N-bit Prefix Option . . . . . . . . . . . . . . . . . 6 71 3.2. Router-Link TLV . . . . . . . . . . . . . . . . . . . . . 7 72 3.3. Attached-Routers TLV . . . . . . . . . . . . . . . . . . 8 73 3.4. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 9 74 3.5. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 10 75 3.6. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 11 76 3.7. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 12 77 3.8. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 13 78 3.9. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 14 79 3.10. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 15 80 3.11. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 15 81 3.12. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 16 82 4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . 16 83 4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 16 84 4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . 18 85 4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . 19 86 4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . 20 87 4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . 21 88 4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 22 89 4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 23 90 4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . 25 91 5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . 26 92 6. LSA Extension Backward Compatibility . . . . . . . . . . . . 26 93 6.1. Full Extended LSA Migration . . . . . . . . . . . . . . . 26 94 6.2. Extended LSA Spare-Mode Backward Compatibility . . . . . 27 95 6.3. LSA TLV Processing Backward Compatibility . . . . . . . . 27 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 97 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 98 8.1. OSPFv3 Extended-LSA TLV Registry . . . . . . . . . . . . 28 99 8.2. OSPFv3 Extended-LSA sub-TLV Registry . . . . . . . . . . 29 100 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 102 10.1. Normative References . . . . . . . . . . . . . . . . . . 30 103 10.2. Informative References . . . . . . . . . . . . . . . . . 30 104 Appendix A. Appendix A - Global Configuration Parameters . . . . 31 105 Appendix B. Appendix B - Area Configuration Parameters . . . . . 31 106 Appendix C. Appendix C - Deprecated LSA Extension Backward 107 Compatibility . . . . . . . . . . . . . . . . . . . 31 108 C.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . 33 109 C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 34 110 C.2. Global Configuration Parameters . . . . . . . . . . . . . 35 111 C.3. Area Configuration Parameters . . . . . . . . . . . . . . 35 112 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 36 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 115 1. Introduction 117 OSPFv3 requires functional extension beyond what can readily be done 118 with the fixed-format Link State Advertisement (LSA) as described in 119 RFC 5340 [OSPFV3]. Without LSA extension, attributes associated with 120 OSPFv3 links and advertised IPv6 prefixes must be advertised in 121 separate LSAs and correlated to the fixed-format LSAs. This document 122 extends the LSA format by encoding the existing OSPFv3 LSA 123 information in Type-Length-Value (TLV) tuples and allowing 124 advertisement of additional information with additional TLVs. 125 Backward compatibility mechanisms are also described. 127 This document updates [OSPFV3] and [OSPFV3-AF]. 129 A similar extension was previously proposed in support of multi- 130 topology routing. Additional requirements for OSPFv3 LSA extension 131 include source/destination routing, route tagging, and others. 133 A final requirement is to limit the changes to OSPFv3 to those 134 necessary for TLV-based LSAs. For the most part, the semantics of 135 existing OSPFv3 LSAs are retained for their TLV-based successor LSAs 136 described herein. Additionally, encoding details, e.g., the 137 representation of IPv6 prefixes as described in section A.4.1 in RFC 138 5340 [OSPFV3], have been retained. This requirement was included to 139 increase the expedience of IETF adoption and deployment. 141 The following aspects of OSPFv3 LSA extension are described: 143 1. Extended LSA Types 145 2. Extended LSA TLVs 147 3. Extended LSA Formats 149 4. Backward Compatibility 151 1.1. Requirements notation 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC-KEYWORDS]. 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 will 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 Extended-AS- 292 External-LSA corresponding to an NSSA route as described in section 3 293 of RFC 3101 ([NSSA]). The N-bit is added to the Inter-Area-Prefix- 294 TLV (Section 3.4), External-Prefix-TLV (Section 3.6), and Intra-Area- 295 Prefix-TLV (Section 3.7). The N-bit is useful for applications such 296 as identifying the prefixes corresponding to Node Segment Identifiers 297 (SIDs) in Segment Routing [SEGMENT-ROUTING]. 299 3.2. Router-Link TLV 301 The Router-Link TLV defines a single router link and the field 302 definitions correspond directly to links in the OSPFv3 Router-LSA, 303 section A.4.3, [OSPFV3]. The Router-Link TLV is only applicable to 304 the E-Router-LSA (Section 4.1). Inclusion in other Extended LSAs 305 MUST be ignored. 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | 1 (Router-Link) | TLV Length | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type | 0 | Metric | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Interface ID | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Neighbor Interface ID | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Neighbor Router ID | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 . . 321 . sub-TLVs . 322 . . 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Router-Link TLV 327 3.3. Attached-Routers TLV 329 The Attached-Routers TLV defines all the routers attached to an 330 OSPFv3 multi-access network. The field definitions correspond 331 directly to content of the OSPFv3 Network-LSA, section A.4.4, 332 [OSPFV3]. The Attached-Routers TLV is only applicable to the E- 333 Network-LSA (Section 4.2). Inclusion in other Extended LSAs MUST be 334 ignored. 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | 2 (Attached-Routers) | TLV Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Adjacent Neighbor Router ID | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 . . 344 . Additional Adjacent Neighbors . 345 . . 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Attached-Routers TLV 350 There are two reasons for not having a separate TLV or sub-TLV for 351 each adjacent neighbor. The first is to discourage using the E- 352 Network-LSA for more than its current role of solely advertising the 353 routers attached to a multi-access network. The router's metric as 354 well as the attributes of individual attached routers should be 355 advertised in their respective E-Router-LSAs. The second reason is 356 that there is only a single E-Network-LSA per multi-access link with 357 the Link State ID set to the Designated Router's Interface ID and, 358 consequently, compact encoding has been chosen to decrease the 359 likelihood that the size of the E-Network-LSA will require IPv6 360 fragmentation when advertised in an OSPFv3 Link State Update packet. 362 3.4. Inter-Area-Prefix TLV 364 The Inter-Area-Prefix TLV defines a single OSPFV3 inter-area prefix. 365 The field definitions correspond directly to the content of an OSPFv3 366 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 367 Inter-Area-Prefix-LSA, as defined in section A.4.5, [OSPFV3]. 368 Additionally, the PrefixOptions are extended as described in 369 Section 3.1. The Inter-Area-Prefix TLV is only applicable to the E- 370 Inter-Area-Prefix-LSA (Section 4.3). Inclusion in other Extended 371 LSAs MUST be ignored. 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | 3 (Inter-Area Prefix) | TLV Length | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | 0 | Metric | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | PrefixLength | PrefixOptions | 0 | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Address Prefix | 383 | ... | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 . . 386 . sub-TLVs . 387 . . 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Inter-Area Prefix TLV 392 3.5. Inter-Area-Router TLV 394 The Inter-Area-Router TLV defines a single OSPFv3 Autonomous System 395 Boundary Router (ASBR) reachable in another area. The field 396 definitions correspond directly to the content of an OSPFv3 Inter- 397 Area-Router-LSA, as defined in section A.4.6, [OSPFV3]. The Inter- 398 Area-Router TLV is only applicable to the E-Inter-Area-Router-LSA 399 (Section 4.4). Inclusion in other Extended LSAs MUST be ignored. 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | 4 (Inter-Area Router) | TLV Length | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | 0 | Options | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | 0 | Metric | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Destination Router ID | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 . . 413 . sub-TLVs . 414 . . 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Inter-Area Router TLV 419 3.6. External-Prefix TLV 421 The External-Prefix TLV defines a single OSPFv3 external prefix. 422 With the exception of omitted fields noted below, the field 423 definitions correspond directly to the content of an OSPFv3 IPv6 424 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 AS- 425 External-LSA, as defined in section A.4.7, [OSPFV3]. The External- 426 Prefix TLV is only applicable to the E-AS-External-LSA (Section 4.5) 427 and the E-NSSA-LSA (Section 4.6). Additionally, the PrefixOptions 428 are extended as described in Section 3.1. Inclusion in other 429 Extended LSAs MUST be ignored. 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | 5 (External Prefix) | TLV Length | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | |E| | | Metric | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | PrefixLength | PrefixOptions | 0 | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Address Prefix | 441 | ... | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 . . 444 . sub-TLVs . 445 . . 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 External Prefix TLV 450 In the External-Prefix TLV, the optional IPv6/IPv4 Forwarding Address 451 and External Route Tag are now sub-TLVs. Given the Referenced LS 452 type and Referenced Link State ID from the AS-External-LSA have never 453 been used or even specified, they have been omitted from the External 454 Prefix TLV. If there were ever a requirement for a referenced LSA, 455 it could be satisfied with a sub-TLV. 457 The following sub-TLVs are defined for optional inclusion in the 458 External Prefix TLV: 460 o 1 - IPv6 Forwarding Address sub-TLV (Section 3.10) 462 o 2 - IPv4 Forwarding Address sub-TLV (Section 3.11) 464 o 3 - Route Tag sub-TLV (Section 3.12) 466 3.7. Intra-Area-Prefix TLV 468 The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix. 469 The field definitions correspond directly to the content of an OSPFv3 470 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 Link- 471 LSA, as defined in section A.4.9, [OSPFV3]. The Intra-Area-Prefix 472 TLV is only applicable to the E-Link-LSA (Section 4.7) and the E- 473 Intra-Area-Prefix-LSA (Section 4.8). Additionally, the PrefixOptions 474 are extended as described in Section 3.1. Inclusion in other 475 Extended LSAs MUST be ignored. 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | 6 (Intra-Area Prefix) | TLV Length | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | 0 | Metric | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | PrefixLength | PrefixOptions | 0 | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Address Prefix | 487 | ... | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 . . 490 . sub-TLVs . 491 . . 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Intra-Area Prefix TLV 496 3.8. IPv6 Link-Local Address TLV 498 The IPv6 Link-Local Address TLV is to be used with IPv6 address 499 families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV 500 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 501 other Extended LSAs MUST be ignored. 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | 7 (IPv6 Local-Local Address) | TLV Length | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | | 509 +- -+ 510 | | 511 +- IPv6 Link-Local Interface Address -+ 512 | | 513 +- -+ 514 | | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 . . 517 . sub-TLVs . 518 . . 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 IPv6 Link-Local Address TLV 523 3.9. IPv4 Link-Local Address TLV 525 The IPv4 Link-Local Address TLV is to be used with IPv4 address 526 families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV 527 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 528 other Extended LSAs MUST be ignored. 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | 8 (IPv4 Local-Local Address) | TLV Length | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | IPv4 Link-Local Interface Address | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 . . 538 . sub-TLVs . 539 . . 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 IPv4 Link-Local Address TLV 544 3.10. IPv6-Forwarding-Address Sub-TLV 546 The IPv6 Forwarding Address TLV has identical semantics to the 547 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv6 548 Forwarding Address TLV is applicable to the External-Prefix TLV 549 (Section 3.6). Specification as a sub-TLV of other TLVs is not 550 defined herein. The sub-TLV is optional and the first specified 551 instance is used as the Forwarding Address as defined in [OSPFV3]. 552 Instances subsequent to the first MUST be ignored. 554 The IPv6 Forwarding Address TLV is to be used with IPv6 address 555 families as defined in [OSPFV3-AF] It MUST be ignored for other 556 address families. 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | 1 - Forwarding Address | sub-TLV Length | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | | 564 +- -+ 565 | | 566 +- Forwarding Address -+ 567 | | 568 +- -+ 569 | | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 Forwarding Address Tag TLV 574 3.11. IPv4-Forwarding-Address Sub-TLV 576 The IPv4 Forwarding Address TLV has identical semantics to the 577 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv4 578 Forwarding Address TLV is The IPv4 Forwarding Address TLV is 579 applicable to the External-Prefix TLV (Section 3.6). Specification 580 as a sub-TLV of other TLVs is not defined herein. The sub-TLV is 581 optional and the first specified instance is used as the Forwarding 582 Address as defined in [OSPFV3]. Instances subsequent to the first 583 MUST be ignored. 585 The IPv4 Forwarding Address TLV is to be used with IPv3 address 586 families as defined in [OSPFV3-AF] It MUST be ignored for other 587 address families. 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | 2 - Forwarding Address | sub-TLV Length | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Forwarding Address | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 Forwarding Address Tag TLV 599 3.12. Route-Tag Sub-TLV 601 The optional Route Tag sub-TLV has identical semantics to the 602 optional External Route Tag in section A.4.7 of [OSPFV3]. The Route 603 Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.6). 604 Specification as a sub-TLV of other TLVs is not defined herein. The 605 sub-TLV is optional and the first specified instance is used as the 606 Route Tag as defined in [OSPFV3]. Instances subsequent to the first 607 MUST be ignored. 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | 3 - Route Tag | sub-TLV Length | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Route Tag | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 Route Tag Sub-TLV 619 4. OSPFv3 Extended LSAs 621 This section specifies the OSPFv3 Extended LSA formats and encoding. 622 The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3 623 LSAs specified in [OSPFV3]. 625 4.1. OSPFv3 E-Router-LSA 627 The E-Router-LSA has an LS Type of 0xA021 and has the same base 628 information content as the Router-LSA defined in section A.4.3 of 629 [OSPFV3]. However, unlike the existing Router-LSA, it is fully 630 extendable and represented as TLVs. 632 0 1 2 3 633 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 634 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | LS Age |1|0|1| 0x21 | 636 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Link State ID | 638 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Advertising Router | 640 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | LS Sequence Number | 642 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | LS Checksum | Length | 644 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | 0 |Nt|x|V|E|B| Options | 646 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 . . 648 . TLVs . 649 . . 650 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 Extended Router-LSA 654 Other than having a different LS Type, all LSA Header fields are the 655 same as defined for the Router-LSA. Initially, only the top-level 656 Router-Link TLV Section 3.2 is applicable and an E-Router-LSA may 657 include multiple Router-Link TLVs. Like the existing Router-LSA, the 658 LSA length is used to determine the end of the LSA including TLVs. 659 Depending on the implementation, it is perfectly valid for an E- 660 Router-LSA to not contain any Router-Link TLVs. However, this would 661 imply that the OSPFv3 router doesn't have any active interfaces in 662 the corresponding area and such E-Router-LSA would never be flooded 663 to other OSPFv3 routers in the area. 665 4.2. OSPFv3 E-Network-LSA 667 The E-Network-LSA has an LS Type of 0xA022 and has the same base 668 information content as the Network-LSA defined in section A.4.4 of 669 [OSPFV3]. However, unlike the existing Network-LSA, it is fully 670 extendable and represented as TLVs. 672 0 1 2 3 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | LS Age |1|0|1| 0x22 | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Link State ID | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Advertising Router | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | LS Sequence Number | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | LS Checksum | Length | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | 0 | Options | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 . . 688 . TLVs . 689 . . 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 E-Network-LSA 694 Other than having a different LS Type, all LSA Header fields are the 695 same as defined for the Network-LSA. Like the existing Network-LSA, 696 the LSA length is used to determine the end of the LSA including 697 TLVs. Initially, only the top-level Attached-Routers TLV Section 3.3 698 is applicable. If the Attached-Router TLV is not included in the E- 699 Network-LSA, it is treated as malformed as described in Section 5. 700 Instances of the Attached-Router TLV subsequent to the first MUST be 701 ignored. 703 4.3. OSPFv3 E-Inter-Area-Prefix-LSA 705 The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same 706 base information content as the Inter-Area-Prefix-LSA defined in 707 section A.4.5 of [OSPFV3]. However, unlike the existing Inter-Area- 708 Prefix-LSA, it is fully extendable and represented as TLVs. 710 0 1 2 3 711 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 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | LS Age |1|0|1| 0x23 | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Link State ID | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Advertising Router | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | LS Sequence Number | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | LS Checksum | Length | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 . . 724 . TLVs . 725 . . 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 E-Inter-Area-Prefix-LSA 730 Other than having a different LS Type, all LSA Header fields are the 731 same as defined for the Inter-Area-Prefix-LSA. In order to retain 732 compatibility and semantics with the current OSPFv3 specification, 733 each Inter-Area-Prefix LSA MUST contain a single Inter-Area Prefix 734 TLV. This will facilitate migration and avoid changes to functions 735 such as incremental SPF computation. 737 Like the existing Inter-Area-Prefix-LSA, the LSA length is used to 738 determine the end of the LSA including TLV. Initially, only the top- 739 level Inter-Area-Prefix TLV (Section 3.4) is applicable. If the 740 Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA, 741 it is treated as malformed as described in Section 5. Instances of 742 the Inter-Area-Prefix TLV subsequent to the first MUST be ignored. 744 4.4. OSPFv3 E-Inter-Area-Router-LSA 746 The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same 747 base information content as the Inter-Area-Router-LSAE defined in 748 section A.4.6 of [OSPFV3]. However, unlike the Inter-Area-Router- 749 LSA, it is fully extendable and represented as TLVs. 751 0 1 2 3 752 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 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | LS Age |1|0|1| 0x24 | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Link State ID | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Advertising Router | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | LS Sequence Number | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | LS Checksum | Length | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 . . 765 . TLVs . 766 . . 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 E-Inter-Area-Router-LSA 771 Other than having a different LS Type, all LSA Header fields are the 772 same as defined for the Inter-Area-Router-LSA. In order to retain 773 compatibility and semantics with the current OSPFv3 specification, 774 each Inter-Area-Router LSA MUST contain a single Inter-Area Router 775 TLV. This will facilitate migration and avoid changes to functions 776 such as incremental SPF computation. 778 Like the existing Inter-Area-Router-LSA, the LSA length is used to 779 determine the end of the LSA including TLV. Initially, only the top- 780 level Inter-Area-Router TLV (Section 3.5) is applicable. If the 781 Inter-Area-Router TLV is not included in the E-Inter-Area-Router-LSA, 782 it is treated as malformed as described in Section 5. Instances of 783 the Inter-Area-Router TLV subsequent to the first MUST be ignored. 785 4.5. OSPFv3 E-AS-External-LSA 787 The E-AS-External-LSA has an LS Type of 0xC025 and has the same base 788 information content as the AS-External-LSA defined in section A.4.7 789 of [OSPFV3]. However, unlike the existing AS-External-LSA, it is 790 fully extendable and represented as TLVs. 792 0 1 2 3 793 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 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | LS Age |1|1|0| 0x25 | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Link State ID | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Advertising Router | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | LS Sequence Number | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | LS Checksum | Length | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 . . 806 . TLVs . 807 . . 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 E-AS-External-LSA 812 Other than having a different LS Type, all LSA Header fields are the 813 same as defined for the AS-External-LSA. In order to retain 814 compatibility and semantics with the current OSPFv3 specification, 815 each LSA MUST contain a single External Prefix TLV. This will 816 facilitate migration and avoid changes to OSPFv3 processes such as 817 incremental SPF computation. 819 Like the existing AS-External-LSA, the LSA length is used to 820 determine the end of the LSA including sub-TLVs. Initially, only the 821 top-level External-Prefix TLV (Section 3.6) is applicable. If the 822 External-Prefix TLV is not included in the E-External-AS-LSA, it is 823 treated as malformed as described in Section 5. Instances of the 824 External-Prefix TLV subsequent to the first MUST be ignored. 826 4.6. OSPFv3 E-NSSA-LSA 828 The E-NSSA-LSA will have the same format and TLVs as the Extended AS- 829 External-LSA Section 4.5. This is the same relationship as exists 830 between the NSSA-LSA defined in section A.4.8 of [OSPFV3], and the 831 AS-External-LSA. The NSSA-LSA will have type 0xA027 which implies 832 area flooding scope. Future requirements may dictate that supported 833 TLVs differ between the E-AS-External-LSA and the E-NSSA-LSA. 834 However, future requirements are beyond the scope of this document. 836 4.7. OSPFv3 E-Link-LSA 838 The E-Link-LSA has an LS Type of 0x8028 and will have the same base 839 information content as the Link-LSA defined in section A.4.9 of 840 [OSPFV3]. However, unlike the existing Link-LSA, it is extendable 841 and represented as TLVs. 843 0 1 2 3 844 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 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | LS Age |1|0|0| 0x28 | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Link State ID | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Advertising Router | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | LS Sequence Number | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | LS Checksum | Length | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Rtr Priority | Options | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 . . 859 . TLVs . 860 . . 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 E-Link-LSA 865 Other than having a different LS Type, all LSA Header fields are the 866 same as defined for the Link-LSA. 868 Only the Intra-Area-Prefix TLV (Section 3.7), IPv6 Link-Local Address 869 TLV (Section 3.8), and IPv4 Link-Local Address TLV (Section 3.9) are 870 applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA 871 affords advertisement of multiple intra-area prefixes. Hence, 872 multiple Intra-Area Prefix TLVs (Section 3.7) may be specified and 873 the LSA length defines the end of the LSA including all TLVs. 875 A single instance of the IPv6 Link-Local Address TLV (Section 3.8) 876 SHOULD be included in the E-Link-LSA. Instances following the first 877 MUST be ignored. For IPv4 address families as defined in 878 [OSPFV3-AF], this TLV MUST be ignored. 880 Similarly, only a single instance of the IPv4 Link-Local Address TLV 881 (Section 3.9) SHOULD be included in the E-Link-LSA. Instances 882 following the first MUST be ignored. For OSPFv3 IPv6 address 883 families as defined in [OSPFV3-AF], this TLV SHOULD be ignored. 885 If the IPv4/IPv6 Link-Local Address TLV corresponding to the OSPFv3 886 Address Family is not included in the E-Link-LSA, it is treated as 887 malformed as described in Section 5. 889 Future specifications may support advertisement of routing and 890 topology information for multiple address families. However, this is 891 beyond the scope of this document. 893 4.8. OSPFv3 E-Intra-Area-Prefix-LSA 895 The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same 896 base information content as the Intra-Area-Prefix-LSA defined in 897 section A.4.10 of [OSPFV3] except for the Referenced LS Type. 898 However, unlike the Intra-Area-Prefix-LSA, it is fully extendable and 899 represented as TLVs. The Referenced LS Type MUST be either an E- 900 Router-LSA (0xA021) or an E-Network-LSA (0xA022). 902 0 1 2 3 903 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 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | LS Age |1|0|1| 0x29 | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Link State ID | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Advertising Router | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | LS Sequence Number | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | LS Checksum | Length | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | 0 | Referenced LS Type | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Referenced Link State ID | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Referenced Advertising Router | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 . . 922 . TLVs . 923 . . 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 E-Intra-Area-Prefix-LSA 928 Other than having a different LS Type, all LSA Header fields are the 929 same as defined for the Intra-Area-Prefix-LSA. 931 Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords 932 advertisement of multiple intra-area prefixes. Hence, multiple 933 Intra-Area Prefix TLVs may be specified and the LSA length defines 934 the end of the LSA including all TLVs. 936 5. Malformed OSPFv3 Extended LSA Handling 938 Extended LSAs that have inconsistent length or other encoding errors, 939 as described herein, MUST NOT be installed in the Link State 940 Database, acknowledged, or flooded. Reception of malformed LSAs 941 SHOULD be counted and/or logged for examination by the administrator 942 of the OSPFv3 Routing Domain. Note that for the purposes of length 943 validation, a TLV or Sub-TLV should not be considered invalid unless 944 the length exceeds the length of the LSA or does not meet the minimum 945 length requirements. This allows for Sub-TLVs to be added as 946 described in Section 6.3. 948 Additionally, an LSA MUST be considered malformed if it does not 949 include all of the required TLVs and Sub-TLVs. 951 6. LSA Extension Backward Compatibility 953 In the context of this document, backward compatibility is solely 954 related to the capability of an OSPFv3 router to receive, process, 955 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 956 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 957 extensions utilizing the TLV-based LSAs is out of scope and must be 958 covered in the documents describing those extensions. Both full and, 959 if applicable, partial deployment SHOULD be specified for future TLV- 960 based OSPFv3 LSA extensions. 962 6.1. Full Extended LSA Migration 964 If ExtendedLSASupport is enabled Appendix A, OSPFv3 Extended LSAs 965 will be originated and used for the SPF computation. Individual OSPF 966 Areas can be migrated separately with the Legacy AS-External LSAs 967 being originated and used for the SPF computation. This is 968 accomplished by enabled AreaExtendedLSASupport Appendix B. 970 An OSPFv3 routing domain or area may be non-disruptively migrated 971 using separate OSPFv3 instances for the extended LSAs. Initially, 972 the OSPFv3 instances with ExtendedLSASupport will have a lower 973 preference, i.e., higher administrative distance, than the OSPFv3 974 instances originating and using the Legacy LSAs. Once the routing 975 domain or area is fully migrated and the OSPFv3 Routing Information 976 Bases (RIB) have been verified, the OSPFv3 instances using the 977 extended LSAs can be given preference. When this has been completed 978 and the routing within the OSPF routing domain or area has been 979 verified, the original OSPFv3 instance using Legacy LSAs can be 980 removed. 982 6.2. Extended LSA Spare-Mode Backward Compatibility 984 In this mode, OSPFv3 will use the Legacy LSAs for the SPF computation 985 and will only originate extended LSAs when LSA origination is 986 required in support of additional functionality. Furthermore, those 987 extended LSAs will only include the top-level TLVs (e.g., Router-Link 988 TLVs or Inter-Area TLVs) which require further specification for that 989 new functionality. However, if a top-level TLV is advertised, it 990 MUST include required Sub-TLVs or it will be considered malformed as 991 described in Section 5. Hence, this mode of compatibility is known 992 as "sparse-mode". The advantage of sparse-mode is that functionality 993 utilizing the OSPFv3 extended LSAs can be added to an existing OSFPv3 994 routing domain without the requirement for migration. In essence, 995 this compatibility mode is very much like the approach taken for 996 OSPFv2 [OSPF-PREFIX-LINK]. As with all the compatibility modes, 997 backward compatibility for the functions utilizing the extended LSAs 998 must be described in the IETF documents describing those functions. 1000 6.3. LSA TLV Processing Backward Compatibility 1002 This section defines the general rules for processing LSA TLVs. To 1003 ensure compatibility of future TLV-based LSA extensions, all 1004 implementations MUST adhere to these rules: 1006 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or 1007 processing Extended-LSAs. 1009 2. Whether or not partial deployment of a given TLV is supported 1010 MUST be specified. 1012 3. If partial deployment is not supported, mechanisms to ensure the 1013 corresponding feature are not deployed MUST be specified in the 1014 document defining the new TLV or sub-TLV. 1016 4. If partial deployment is supported, backward compatibility and 1017 partial deployment MUST be specified in the document defining the 1018 new TLV or sub-TLV. 1020 5. If a TLV or Sub-TLV is recognized but the length is less than the 1021 minimum, then the LSA should be considered malformed and it 1022 SHOULD NOT be acknowledged. Additionally, the occurrence SHOULD 1023 be logged with enough information to identify the LSA by type, 1024 originator, and sequence number and the TLV or Sub-TLV in error. 1025 Ideally, the log entry would include the hexadecimal or binary 1026 representation of the LSA including the malformed TLS or Sub-TLV. 1028 6. Documents specifying future TLVs or Sub-TLVs MUST specify the 1029 requirements for usage of those TLVs or Sub-TLVs. 1031 7. Future TLV or Sub-TLVs must be optional. However, there may be 1032 requirements for Sub-TLVs if an optional TLV is specified. 1034 7. Security Considerations 1036 In general, extendible OSPFv3 LSAs are subject to the same security 1037 concerns as those described in RFC 5340 [OSPFV3]. Additionally, 1038 implementations must assure that malformed TLV and sub-TLV 1039 permutations do not result in errors that cause hard OSPFv3 failures. 1041 If there were ever a requirement to digitally sign OSPFv3 LSAs as 1042 described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the 1043 mechanisms described herein would greatly simplify the extension. 1045 8. IANA Considerations 1047 This specification defines nine OSPFv3 Extended LSA types as 1048 described in Section 2. These will be added to the existing OSPFv3 1049 LSA Function Codes registry. 1051 The specification will define a new code point for the N-bit in the 1052 OSPFv3 Prefix-Options registry. The value 0x20 is suggested. 1054 This specification also creates two registries OSPFv3 Extended-LSAs 1055 TLVs and sub-TLVs. The TLV and sub-TLV code-points in these 1056 registries are common to all Extended-LSAs and their respective 1057 definitions must define where they are applicable. 1059 8.1. OSPFv3 Extended-LSA TLV Registry 1061 The OSPFv3 Extended-LSA TLV registry will define top-level TLVs for 1062 Extended-LSAs and should be placed in the existing OSPFv3 IANA 1063 registry. 1065 Nine values are allocated by this specification: 1067 o 0 - Reserved 1069 o 1 - Router-Link TLV 1071 o 2 - Attached-Routers TLV 1073 o 3 - Inter-Area Prefix TLV 1075 o 4 - Inter-Area Router TLV 1077 o 5 - External Prefix TLV 1078 o 6 - Intra-Area Prefix TLV 1080 o 7 - IPv6 Link-Local Address TLV 1082 o 8 - IPv4 Link-Local Address TLV 1084 Types in the range 9-32767 are allocated via IETF Consensus or IESG 1085 Approval. 1087 Types in the range 32768-33023 are for experimental use; these will 1088 not be registered with IANA, and MUST NOT be mentioned by RFCs. 1090 Types in the range 33024-45055 are to be assigned on a FCFS basis 1091 subject to IETF expert review. 1093 Types in the range 45056-65535 are not to be assigned at this time. 1094 Before any assignments can be made in the 33024-65535 range, there 1095 MUST be an IETF specification that specifies IANA Considerations that 1096 covers the range being assigned. 1098 8.2. OSPFv3 Extended-LSA sub-TLV Registry 1100 The OSPFv3 Extended-LSA sub-TLV registry will define sub-TLVs at any 1101 level of nesting for Extended-LSAs and should be placed in the 1102 existing OSPFv3 IANA registry. 1104 Four values are allocated by this specification: 1106 o 0 - Reserved 1108 o 1 - IPv6 Forwarding Address sub-TLV 1110 o 2 - IPv4 Forwarding Address sub-TLV 1112 o 3 - Route Tag sub-TLV 1114 Types in the range 4-32767 are allocated via IETF Consensus or IESG 1115 Approval. 1117 Types in the range 32768-33023 are for experimental use; these will 1118 not be registered with IANA, and MUST NOT be mentioned by RFCs. 1120 Types in the range 33024-45055 are to be assigned on a FCFS basis 1121 subject to IETF expert review. 1123 Types in the range 45056-65535 are not to be assigned at this time. 1124 Before any assignments can be made in the 33024-65535 range, there 1125 MUST be an IETF specification that specifies IANA Considerations that 1126 covers the range being assigned. 1128 9. Contributors 1130 Contributors' Addresses 1132 Sina Mirtorabi 1133 Cisco Systems 1134 170 Tasman Drive 1135 San Jose, CA 95134 1136 USA 1137 Email: sina@cisco.com 1139 10. References 1141 10.1. Normative References 1143 [GRACEFUL-RESTART] 1144 Lindem, A. and P. Pillay-Esnault, "OSPFv3 Graceful 1145 Restart", RFC 5187, June 2008. 1147 [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1148 RFC 3101, January 2003. 1150 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1151 for IPv6", RFC 5340, July 2008. 1153 [OSPFV3-AF] 1154 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 1155 Aggarwal, "Support of Address Families in OSPFv3", 1156 RFC 5838, April 2010. 1158 [RFC-KEYWORDS] 1159 Bradner, S., "Key words for use in RFCs to Indicate 1160 Requirement Levels", RFC 2119, March 1997. 1162 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 1163 Extensions to OSPF", RFC 3630, September 2003. 1165 10.2. Informative References 1167 [MT-OSPFV3] 1168 Mirtorabi, S. and A. Roy, "Multi-topology routing in 1169 OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt 1170 (work in progress), January 2008. 1172 [OSPF-DIGITAL-SIGNATURE] 1173 Murphy, S., Badger, M., and B. Wellington, "OSPF with 1174 Digital Signatures", RFC 2154, June 1997. 1176 [OSPF-PREFIX-LINK] 1177 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1178 Tantsura, J., and A. Lindem, "OSPF Prefix/Link 1179 Attributes", RFC 7684, December 2015. 1181 [SEGMENT-ROUTING] 1182 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1183 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1184 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1185 segment-routing-extensions-10.txt (work in progress), July 1186 2016. 1188 Appendix A. Appendix A - Global Configuration Parameters 1190 The global configurable parameter ExtendedLSASupport will be added to 1191 the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 1192 Router will originate OSPFv3 Extended LSAs and use the LSAs for the 1193 SPF computation. If ExtendedLSASupport is not enabled, a subset of 1194 OSPFv3 Extended LSAs may still be originated and used for other 1195 functions as described in Section 6.2. 1197 Appendix B. Appendix B - Area Configuration Parameters 1199 The area configurable parameter AreaExtendedLSASupport will be added 1200 to the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 1201 Router will originate link and area OSPFv3 Extended LSAs and use the 1202 LSAs for the SPF computation. Legacy AS-Scoped LSAs will still be 1203 originated and used for the AS External LSA computation. If 1204 AreaExtendedLSASupport is not enabled a subset of OSPFv3 link and 1205 area Extended LSAs may still be originated and used for other 1206 functions as described in Section 6.2. 1208 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1209 disabling AreaExtendedLSASupport when ExtendedLSASupport is enabled 1210 is contradictory and MAY be prohibited by the implementation. 1212 Appendix C. Appendix C - Deprecated LSA Extension Backward 1213 Compatibility 1215 In the context of this document, backward compatibility is solely 1216 related to the capability of an OSPFv3 router to receive, process, 1217 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 1218 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 1219 extensions utilizing the TLV-based LSAs is out of scope and must be 1220 covered in the documents describing those extensions. Both full and, 1221 if applicable, partial deployment SHOULD be specified for future TLV- 1222 based OSPFv3 LSA extensions. 1224 Three distinct backward compatibility modes are supported dependent 1225 on the OSPFv3 routing domain migration requirements. For simplicity 1226 and to avoid the scaling impact of maintaining both TLV and non-TLV 1227 based versions of the same LSA within a routing domain, the basic 1228 backward compatibility mode will not allow mixing of LSA formats. 1229 Different LSA formats could still be supported with multiple OSPFv3 1230 instances and separate OSPFv3 routing domains. Additionally, a more 1231 flexible mode is provided in Appendix C.1, where both formats of LSA 1232 coexist. In order to facilitate backward compatibility, the OSPFv3 1233 options field (as described in Appendix A.2 of RFC 5340 [OSPFV3]), 1234 will contain two additional options bits. The EL-bits will be used 1235 to indicate that the OSPFv3 router's level of Extended LSA support. 1236 An OSPFv3 router configured to support extended LSAs MUST set its 1237 options field EL-bits in OSPFv3 Hello and Database Description 1238 packets as follows: 1240 B'00' 1241 None - Extended LSAs are not originated nor used in the SPF 1242 calculation (except for future functionalities as described in 1243 Section 6.2) . 1245 B'01' 1246 MixedModeOriginateOnly - Both Extended and Legacy LSAs are 1247 originated. Legacy LSAs are used in the SPF computation. 1249 B'10' 1250 MixedModeOriginateSPF - Both extended and Legacy LSAs are 1251 originated. Extended LSAs are used in the SPF computation. 1253 B'11' 1254 Full - Only extended LSAs are originated and used in the SPF 1255 computation. 1257 If Full is specified for ExtendedLSASupport, the OSPFv3 router MUST 1258 NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and 1259 Database Description packets with the options field EL-bits set to 1260 MixedModeOriginateOnly or None. Similarly, if MixModeOriginateSPF is 1261 specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form 1262 adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database 1263 Description packets with the options field EL-bits set to None 1264 (B'00'). In this manner, OSPFv3 routers using new encodings can be 1265 completely isolated from those OSPFv3 routers depending on the RFC 1266 5340 encoding and not setting their options field EL-bits since the 1267 default setting indicates no support for extended LSAs. 1269 Finally, a mode supporting existing OSPFv3 routing domains is 1270 provided. This mode, subsequently referred to as "sparse-mode", will 1271 use the TLV-based LSAs solely in support of new functionality 1272 Section 6.2. In this compatibility mode, the EL-bits will be 1273 advertised as B'00' since the backward compatibility with the Legacy 1274 LSAs is not supported or required. 1276 1 2 1277 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 1279 | | | | | | | | | | | | EL|AT|L|AF|*|*|DC|R|N|x|E|V6| 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 1281 The Options field 1283 EL-bits 1284 These bits indicate the level of Extended LSA support. 1285 B'00' - Extended LSAs are not originate nor used in the 1286 SPF calculation (except for new functionalities 1287 for future functions as described in Section 6.2). 1288 B'01' - Both extended and Legacy LSAs are originated. 1289 Non-extended LSAs are used in the SPF computation. 1290 B'10' - Both extended and Legacy LSAs are originated. 1291 Extended LSAs are used in the SPF computation. 1292 B'11' - Only extended LSA are originated and used in the 1293 SPF computation. 1295 Options Field EL-bits 1297 The EL-bits will also be set in the LSA options field in Extended and 1298 Legacy LSAs. While the value of the EL-bits has no functional 1299 significance in the LSA options field, visibility of every OSPFv3 1300 Router's extended LSA support is expected to be very useful for 1301 management and troubleshooting during the migration period. 1303 C.1. Extended LSA Mixed-Mode Backward Compatibility 1305 An implementation MAY support configuration allowing a graceful 1306 transition from the Legacy (non-TLV-based) LSAs to the extended (TLV- 1307 based) LSAs in an OSPFv3 routing domain. In these routing domains, 1308 the OSPFv3 routers configured with a value of MixedModeOriginateOnly 1309 or MixedModeOriginateSPF for ExtendedLSASupport, (Appendix C.2), MUST 1310 originate both the extended and legacy versions of the OSPFv3 LSAs 1311 described herein. For the purposes of Shortest Path First (SPF) 1312 computation, the Legacy LSAs are used for SPF computation when 1313 MixedModeOriginateOnly is configured and the extended LSAs are used 1314 when MixedModeOriginateSPF is specified. The Extended LSAs MAY be 1315 used for functions other than routing computation as long as backward 1316 compatibility is specified in the documents specifying those 1317 functions. 1319 In this manner, OSPFv3 routing domains utilizing the new encodings 1320 can be gradually migrated with a worst-case overhead cost of 1321 approximately doubling the number of LSAs in the routing domain. The 1322 transition within an OSPFv3 routing domain would progress as follows: 1324 1. Configure OSPFv3 Router ExtendedLSASupport to 1325 MixedModeOriginateOnly so that routers originate the extended 1326 LSAs. 1328 2. When all the OSPFv3 Routers have been reconfigured to 1329 MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to 1330 use the extended LSAs by configuring ExtendedLSASupport to 1331 MixedModeOriginateSPF. This can be done on a small subset of 1332 OSPFv3 Routers and the route tables can be verified. 1334 3. When all the OSPFv3 Routers have been reconfigured to 1335 MixedModeOriginateSPF and the routing has been verified, 1336 reconfigure OSPFv3 Routers to purge or simply not refresh the 1337 Legacy LSA by configuring ExtendedLSASupport to Full. 1339 In order to prevent OSPFv3 routing domain routing loops, the 1340 advertised metrics in the Extended LSAs and Legacy LSAs MUST be 1341 identical. 1343 C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility 1345 An implementation MAY also support configuration allowing graceful 1346 transition from the Legacy LSAs to the extended LSAs within a single 1347 area. In these areas, the parameter AreaExtendedLSASupport 1348 (Appendix C.3) may be configured to take precedence over the global 1349 parameter ExtendedLSASupport. However, the AreaExtendedLSASupport 1350 will only apply to link and area scoped LSAs within the area and area 1351 based SPF calculations. The default is for the 1352 AreaExtendedLSASupport to be inherited from the ExtendedLSASupport. 1353 The configuration of ExtendedLSASupport will apply to AS-External 1354 LSAs even when AreaExtendedLSASupport takes precedence. 1356 When preforming a graceful restart [GRACEFUL-RESTART], an OSPFv3 1357 router configured with MixedModeOriginate will use the Legacy LSAs to 1358 determine whether or not the graceful restart has completed 1359 successfully. Similarly, an OSPFv3 router configured with 1360 MixedModeOriginateSPF will use the extended LSAs. In other words, 1361 successful OSPFv3 graceful restart determination will follow the SPF 1362 calculation. 1364 C.2. Global Configuration Parameters 1366 An additional global configurable parameter will be added to the 1367 OSPFv3 protocol. 1369 ExtendedLSASupport 1370 This is an enumeration type indicating the extent to which the 1371 OSPFv3 instance supports the TLV format described herein for 1372 Extended LSAs. The valid values for the enumeration are: 1374 * None - Extended LSAs will not be originated or used in the SPF 1375 calculation. This is the default. When OSPFv3 functions 1376 requiring extended LSA are configured, and the 1377 ExtendedLSASuppport is "None", extended LSAs may be used as 1378 described in Section 6.2. 1380 * MixedModeOriginateOnly - Both extended and Legacy LSAs will be 1381 originated. OSPFv3 adjacencies will be formed with OSPFv3 1382 routers not supporting this specification. The Legacy LSAs are 1383 used for the SPF computation. 1385 * MixedModeOriginateSPF - Both Extended LSAs and Legacy LSAs will 1386 be originated. OSPFv3 adjacencies will be formed with OSPFv3 1387 routers not supporting this specification. The Extended LSAs 1388 are used for the SPF computation. 1390 * Full - Extended LSAs will be originated and adjacencies will 1391 not be formed with OSPFv3 routers not supporting this 1392 specification. Only Extended LSAs will be originated. 1394 C.3. Area Configuration Parameters 1396 An additional area configurable parameter will be added to the OSPFv3 1397 protocol. 1399 AreaExtendedLSASupport 1400 This is an enumeration type indicating the extent to which the 1401 OSPFv3 area supports the TLV format described herein for Extended 1402 LSAs. The valid value for the enumeration are: 1404 * InheritGlobal - The AreaExtendedLSASupport will be inherited 1405 from ExtendedLSASupport. This is the default. 1407 * None - Extended LSAs will not be originated or used in the SPF 1408 calculation. This is the default. When OSPFv3 functions 1409 requiring extended LSA are configured, and the 1410 ExtendedLSASuppport is "None", the spare-mode compatibility is 1411 in effect Section 6.2. 1413 * MixedModeOriginateOnly - Both extended and legacy link and area 1414 scoped LSAs will be originated. OSPFv3 adjacencies will be 1415 formed with OSPFv3 routers not supporting this specification. 1416 The Legacy LSAs are used for the area SPF computation. 1418 * MixedModeOriginateSPF - Both extended and legacy link and area 1419 scoped LSAs will be originated. OSPFv3 adjacencies will be 1420 formed with OSPFv3 routers not supporting this specification. 1421 The Extended LSAs are used for the area SPF computation. 1423 * Full - Link and area scoped Extended LSAs will be originated 1424 and adjacencies will not be formed with OSPFv3 routers not 1425 supporting this specification. Only Extended LSAs will be 1426 originated. 1428 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1429 configuring None or MixedModeOriginateOnly for AreaExtendedLSASupport 1430 when Full is specified for ExtendedLSASupport is contradictory and 1431 MAY be prohibited by the implementation. 1433 Appendix D. Acknowledgments 1435 OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing 1436 in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3]. 1438 Thanks for Peter Psenak for significant contributions to the backward 1439 compatibility mechanisms. 1441 Thanks go to Michael Barnes, Mike Dubrovsky, Anton Smirnov, and Tony 1442 Przygienda for review of the draft versions and discussions of 1443 backward compatibility. 1445 Thanks to Alan Davey for review and comments including the suggestion 1446 to separate the extended LSA TLV definitions from the extended LSAs 1447 definitions. 1449 Thanks to David Lamparter for review and suggestions on backward 1450 compatibility. 1452 Thanks to Karsten Thomann, Chris Bowers, Meng Zhang, and Nagendra 1453 Kumar for review and editorial comments. 1455 Thanks to Alia Atlas for substantive Routing Area Director (AD) 1456 comments prior to IETF last call. 1458 The RFC text was produced using Marshall Rose's xml2rfc tool. 1460 Authors' Addresses 1462 Acee Lindem 1463 Cisco Systems 1464 301 Midenhall Way 1465 Cary, NC 27513 1466 USA 1468 Email: acee@cisco.com 1470 Abhay Roy 1471 Cisco Systems 1472 170 Tasman Drive 1473 San Jose, CA 95134 1474 USA 1476 Email: akr@cisco.com 1478 Dirk Goethals 1479 Nokia 1480 Copernicuslaan 50 1481 Antwerp 2018 1482 Belgium 1484 Email: dirk.goethals@nokia.com 1486 Veerendranatha Reddy Vallem 1487 Bangalore 1488 India 1490 Email: vallem.veerendra@gmail.com 1491 Fred Baker 1492 Santa Barbara, California 93117 1493 USA 1495 Email: FredBaker.IETF@gmail.com