idnits 2.17.00 (12 Aug 2021) /tmp/idnits2871/draft-ietf-ospf-ospfv3-lsa-extend-13.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2016) is 2037 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) == Outdated reference: draft-ietf-ospf-ospfv3-segment-routing-extensions has been published as RFC 8666 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem 3 Internet-Draft S. Mirtorabi 4 Intended status: Standards Track A. Roy 5 Expires: April 24, 2017 Cisco Systems 6 F. Baker 8 October 21, 2016 10 OSPFv3 LSA Extendibility 11 draft-ietf-ospf-ospfv3-lsa-extend-13.txt 13 Abstract 15 OSPFv3 requires functional extension beyond what can readily be done 16 with the fixed-format Link State Advertisement (LSA) as described in 17 RFC 5340. Without LSA extension, attributes associated with OSPFv3 18 links and advertised IPv6 prefixes must be advertised in separate 19 LSAs and correlated to the fixed-format LSAs. This document extends 20 the LSA format by encoding the existing OSPFv3 LSA information in 21 Type-Length-Value (TLV) tuples and allowing advertisement of 22 additional information with additional TLVs. Backward compatibility 23 mechanisms are also described. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 24, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 61 1.2. OSPFv3 LSA Terminology . . . . . . . . . . . . . . . . . 4 62 1.3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 63 2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 4 64 3. OSPFv3 Extended LSA TLVs . . . . . . . . . . . . . . . . . . 5 65 3.1. Prefix Options Extensions . . . . . . . . . . . . . . . . 6 66 3.1.1. N-bit Prefix Option . . . . . . . . . . . . . . . . . 6 67 3.2. Router-Link TLV . . . . . . . . . . . . . . . . . . . . . 7 68 3.3. Attached-Routers TLV . . . . . . . . . . . . . . . . . . 8 69 3.4. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 10 70 3.5. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 11 71 3.6. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 12 72 3.7. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 13 73 3.8. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 14 74 3.9. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 15 75 3.10. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16 76 3.11. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16 77 3.12. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 17 78 4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . 17 79 4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 17 80 4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . 19 81 4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . 20 82 4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . 21 83 4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . 22 84 4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 23 85 4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 24 86 4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . 26 87 5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . 26 88 6. LSA Extension Backward Compatibility . . . . . . . . . . . . 27 89 6.1. Full Extended LSA Migration . . . . . . . . . . . . . . . 27 90 6.2. Extended LSA Spare-Mode Backward Compatibility . . . . . 27 91 6.3. LSA TLV Processing Backward Compatibility . . . . . . . . 28 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 29 96 9.2. Informative References . . . . . . . . . . . . . . . . . 30 98 Appendix A. Appendix A - Global Configuration Parameters . . . . 30 99 Appendix B. Appendix B - Area Configuration Parameters . . . . . 31 100 Appendix C. Appendix C - Deprecated LSA Extension Backward 101 Compatibility . . . . . . . . . . . . . . . . . . . 31 102 C.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . 33 103 C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 34 104 C.2. Global Configuration Parameters . . . . . . . . . . . . . 34 105 C.3. Area Configuration Parameters . . . . . . . . . . . . . . 35 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 108 1. Introduction 110 OSPFv3 requires functional extension beyond what can readily be done 111 with the fixed-format Link State Advertisement (LSA) as described in 112 RFC 5340 [OSPFV3]. Without LSA extension, attributes associated with 113 OSPFv3 links and advertised IPv6 prefixes must be advertised in 114 separate LSAs and correlated to the fixed-format LSAs. This document 115 extends the LSA format by encoding the existing OSPFv3 LSA 116 information in Type-Length-Value (TLV) tuples and allowing 117 advertisement of additional information with additional TLVs. 118 Backward compatibility mechanisms are also described. 120 A similar extension was previously proposed in support of multi- 121 topology routing. Additional requirements for OSPFv3 LSA extension 122 include source/destination routing, route tagging, and others. 124 A final requirement is to limit the changes to OSPFv3 to those 125 necessary for TLV-based LSAs. For the most part, the semantics of 126 existing OSPFv3 LSAs are retained for their TLV-based successor LSAs 127 described herein. Additionally, encoding details, e.g., the 128 representation of IPv6 prefixes as described in section A.4.1 in RFC 129 5340 [OSPFV3], have been retained. This requirement was included to 130 increase the expedience of IETF adoption and deployment. 132 The following aspects of OSPFv3 LSA extension are described: 134 1. Extended LSA Types 136 2. Extended LSA TLVs 138 3. Extended LSA Formats 140 4. Backward Compatibility 142 1.1. Requirements notation 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC-KEYWORDS]. 148 1.2. OSPFv3 LSA Terminology 150 The TLV-based OSPFv3 LSAs described in this document will be referred 151 to as Extended LSAs. The OSPFv3 fixed-format LSAs [OSPFV3] will be 152 referred to as Legacy LSAs. 154 1.3. Acknowledgments 156 OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing 157 in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3]. 159 Thanks for Peter Psenak for significant contributions to the backward 160 compatibility mechanisms. 162 Thanks go to Michael Barnes, Mike Dubrovsky, Anton Smirnov, and Tony 163 Przygienda for review of the draft versions and discussions of 164 backward compatibility. 166 Thanks to Alan Davey for review and comments including the suggestion 167 to separate the extended LSA TLV definitions from the extended LSAs 168 definitions. 170 Thanks to David Lamparter for review and suggestions on backward 171 compatibility. 173 Thanks to Karsten Thomann, Chris Bowers, and Meng Zhang for review 174 and editorial comments. 176 The RFC text was produced using Marshall Rose's xml2rfc tool. 178 2. OSPFv3 Extended LSA Types 180 In order to provide backward compatibility, new LSA codes must be 181 allocated. There are eight fixed-format LSAs defined in RFC 5340 182 [OSPFV3]. For ease of implementation and debugging, the LSA function 183 codes are the same as the fixed-format LSAs only with 32, i.e., 0x20, 184 added. The alternative to this mapping was to allocate a bit in the 185 LS Type indicating the new LSA format. However, this would have used 186 one half the LSA function code space for the migration of the eight 187 original fixed-format LSAs. For backward compatibility, the U-bit 188 will be set in LS Type so that the LSAs will be flooded by OSPFv3 189 routers that do not understand them. 191 LSA function code LS Type Description 192 ---------------------------------------------------- 193 33 0xA021 E-Router-LSA 194 34 0xA022 E-Network-LSA 195 35 0xA023 E-Inter-Area-Prefix-LSA 196 36 0xA024 E-Inter-Area-Router-LSA 197 37 0xC025 E-AS-External-LSA 198 38 N/A Unused (Not to be allocated) 199 39 0xA027 E-Type-7-LSA 200 40 0x8028 E-Link-LSA 201 41 0xA029 E-Intra-Area-Prefix-LSA 203 OSPFv3 Extended LSA Types 205 3. OSPFv3 Extended LSA TLVs 207 The format of the TLVs within the body of the extended LSAs is the 208 same as the format used by the Traffic Engineering Extensions to OSPF 209 [TE]. The variable TLV section consists of one or more nested 210 Type/Length/Value (TLV) tuples. Nested TLVs are also referred to as 211 sub-TLVs. The format of each TLV is: 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Type | Length | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Value... | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 TLV Format 223 The Length field defines the length of the value portion in octets 224 (thus a TLV with no value portion would have a length of 0). The TLV 225 is padded to 4-octet alignment; padding is not included in the length 226 field (so a 3-octet value would have a length of 3, but the total 227 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 228 aligned. For example, a 1-byte value would have the length field set 229 to 1, and 3 octets of padding would be added to the end of the value 230 portion of the TLV. 232 This document defines the following top-level TLV types: 234 o 0 - Reserved 236 o 1 - Router-Link TLV 237 o 2 - Attached-Routers TLV 239 o 3 - Inter-Area Prefix TLV 241 o 4 - Inter-Area Router TLV 243 o 5 - External Prefix TLV 245 o 6 - Intra-Area Prefix TLV 247 o 7 - IPv6 Link-Local Address TLV 249 o 8 - IPv4 Link-Local Address TLV 251 Additionally, this document defines the following sub-TLV types: 253 o 0 - Reserved 255 o 1 - IPv6 Forwarding Address sub-TLV 257 o 2 - IPv4 Forwarding Address sub-TLV 259 o 3 - Route Tag sub-TLV 261 In general, TLVs and sub-TLVs MAY occur in any order and the 262 specification should define whether the TLV or sub-TLV is required 263 and the behavior when there are multiple occurances of the TLV or 264 sub-TLVs. 266 3.1. Prefix Options Extensions 268 The prefix options are extended from Appendix A.4.1.1 [OSPFV3]. The 269 applicability of the LA-bit is expanded and it SHOULD be set in 270 Inter-Area-Prefix-TLVs and MAY be set in External-Prefix-TLVs when 271 the advertised host IPv6 address, i.e., PrefixLength = 128, is an 272 interface address. In RFC 5340, the LA-bit is only set in Intra- 273 Area-Prefix-LSAs (Section 4.4.3.9 in [OSPFV3]). This will allow a 274 stable address to be advertised without having to configure a 275 separate loopback address in every OSPFv3 area. 277 3.1.1. N-bit Prefix Option 279 Additionally, the N-bit prefix option is defined. The figure below 280 shows the position of the N-bit in the prefix options (pending IANA 281 allocation). This corresponds to the value 0x20. 283 0 1 2 3 4 5 6 7 284 +--+--+--+--+--+--+--+--+ 285 | | | N|DN| P| x|LA|NU| 286 +--+--+--+--+--+--+--+--+ 288 The Prefix Options field 290 The N-bit is set in PrefixOptions for a host address 291 (PrefixLength=128) that identifies the advertising router. While it 292 is similar to the LA-bit, there are two differences. The advertising 293 router MAY choose NOT to set the N-bit even when the above conditions 294 are met. If the N-bit is set and the PrefixLength is NOT 128, the 295 N-bit MUST be ignored. Additionally, the N-bit is propagated in the 296 PrefixOptions when an OSPFv3 Area Border Router (ABR) originates an 297 Inter-Area-Prefix-LSA for an Intra-Area route which has the N-bit set 298 in the PrefixOptions. Similarly, the N-bit is propagated in the 299 PrefixOptions when an OSPFv3 NSSA ABR originates an Extended-AS- 300 External-LSA corresponding to an NSSA route as described in section 3 301 of RFC 3101 ([NSSA]). The N-bit is to the Inter-Area-Prefix-TLV 302 (Section 3.4), External-Prefix-TLV (Section 3.6), and Intra-Area- 303 Prefix-TLV (Section 3.7) The N-bit is useful for applications such as 304 identifying the prefixes corresponding to Node Segment Identifiers 305 (SIDs) in Segment Routing [SEGMENT-ROUTING]. 307 3.2. Router-Link TLV 309 The Router-Link TLV defines a single router link and the field 310 definitions correspond directly to links in the OSPFv3 Router-LSA, 311 section A.4.3, [OSPFV3]. The Router-Link TLV is only applicable to 312 the E-Router-LSA (Section 4.1). Inclusion in other Extended LSAs 313 MUST be ignored. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | 1 (Router-Link) | TLV Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Type | 0 | Metric | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Interface ID | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Neighbor Interface ID | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Neighbor Router ID | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 . . 329 . sub-TLVs . 330 . . 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Router-Link TLV 335 3.3. Attached-Routers TLV 337 The Attached-Routers TLV defines all the routers attached to an 338 OSPFv3 multi-access network. The field definitions correspond 339 directly to content of the OSPFv3 Network-LSA, section A.4.4, 340 [OSPFV3]. The Attached-Routers TLV is only applicable to the E- 341 Network-LSA (Section 4.2). Inclusion in other Extended LSAs MUST be 342 ignored. 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | 2 (Attached-Routers) | TLV Length | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Adjacent Neighbor Router ID | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 . . 352 . Additional Adjacent Neighbors . 353 . . 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Attached-Routers TLV 358 There are two reasons for not having a separate TLV or sub-TLV for 359 each adjacent neighbor. The first is to discourage using the E- 360 Network-LSA for more than its current role of solely advertising the 361 routers attached to a multi-access network. The router's metric as 362 well as the attributes of individual attached routers should be 363 advertised in their respective E-Router-LSAs. The second reason is 364 that there is only a single E-Network-LSA per multi-access link with 365 the Link State ID set to the Designated Router's Interface ID and, 366 consequently, compact encoding has been chosen to decrease the 367 likelihood that the size of the E-Network-LSA will require IPv6 368 fragmentation when advertised in an OSPFv3 Link State Update packet. 370 3.4. Inter-Area-Prefix TLV 372 The Inter-Area-Prefix TLV defines a single OSPFV3 inter-area prefix. 373 The field definitions correspond directly to the content of an OSPFv3 374 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 375 Inter-Area-Prefix-LSA, as defined in section A.4.5, [OSPFV3]. 376 Additionally, the PrefixOptions are extended as described in 377 Section 3.1. The Inter-Area-Prefix TLV is only applicable to the E- 378 Inter-Area-Prefix-LSA (Section 4.3). Inclusion in other Extended 379 LSAs MUST be ignored. 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | 3 (Inter-Area Prefix) | TLV Length | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | 0 | Metric | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | PrefixLength | PrefixOptions | 0 | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Address Prefix | 391 | ... | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 . . 394 . sub-TLVs . 395 . . 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Inter-Area Prefix TLV 400 3.5. Inter-Area-Router TLV 402 The Inter-Area-Router TLV defines a single OSPFv3 Autonomous System 403 Boundary Router (ASBR) reachable in another area. The field 404 definitions correspond directly to the content of an OSPFv3 Inter- 405 Area-Router-LSA, as defined in section A.4.6, [OSPFV3]. The Inter- 406 Area-Router TLV is only applicable to the E-Inter-Area-Router-LSA 407 (Section 4.4). Inclusion in other Extended LSAs MUST be ignored. 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | 4 (Inter-Area Router) | TLV Length | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | 0 | Options | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | 0 | Metric | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Destination Router ID | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 . . 421 . sub-TLVs . 422 . . 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Inter-Area Router TLV 427 3.6. External-Prefix TLV 429 The External-Prefix TLV defines a single OSPFv3 external prefix. 430 With the exception of omitted fields noted below, the field 431 definitions correspond directly to the content of an OSPFv3 IPv6 432 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 AS- 433 External-LSA, as defined in section A.4.7, [OSPFV3]. The External- 434 Prefix TLV is only applicable to the E-AS-External-LSA (Section 4.5) 435 and the E-NSSA-LSA (Section 4.6). Additionally, the PrefixOptions 436 are extended as described in Section 3.1. Inclusion in other 437 Extended LSAs MUST be ignored. 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | 5 (External Prefix) | TLV Length | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | |E| | | Metric | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | PrefixLength | PrefixOptions | 0 | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Address Prefix | 449 | ... | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 . . 452 . sub-TLVs . 453 . . 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 External Prefix TLV 458 In the External-Prefix TLV, the optional IPv6/IPv4 Forwarding Address 459 and External Route Tag are now sub-TLVs. Given the Referenced LS 460 type and Referenced Link State ID from the AS-External-LSA have never 461 been used or even specified, they have been omitted from the External 462 Prefix TLV. If there were ever a requirement for a referenced LSA, 463 it could be satisfied with a sub-TLV. 465 The following sub-TLVs are defined for optional inclusion in the 466 External Prefix TLV: 468 o 1 - IPv6 Forwarding Address sub-TLV (Section 3.10) 470 o 2 - IPv4 Forwarding Address sub-TLV (Section 3.11) 472 o 3 - Route Tag sub-TLV (Section 3.12) 474 3.7. Intra-Area-Prefix TLV 476 The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix. 477 The field definitions correspond directly to the content of an OSPFv3 478 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 Link- 479 LSA, as defined in section A.4.9, [OSPFV3]. The Intra-Area-Prefix 480 TLV is only applicable to the E-Link-LSA (Section 4.7) and the 481 Additionally, the PrefixOptions are extended as described in 482 Section 3.1. E-Intra-Area-Prefix-LSA (Section 4.8). Inclusion in 483 other Extended LSAs MUST be ignored. 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | 6 (Intra-Area Prefix) | TLV Length | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | 0 | Metric | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | PrefixLength | PrefixOptions | 0 | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Address Prefix | 495 | ... | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 . . 498 . sub-TLVs . 499 . . 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Intra-Area Prefix TLV 504 3.8. IPv6 Link-Local Address TLV 506 The IPv6 Link-Local Address TLV is to be used with IPv6 address 507 families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV 508 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 509 other Extended LSAs MUST be ignored. 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | 7 (IPv6 Local-Local Address) | TLV Length | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | | 517 +- -+ 518 | | 519 +- IPv6 Link-Local Interface Address -+ 520 | | 521 +- -+ 522 | | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 . . 525 . sub-TLVs . 526 . . 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 IPv6 Link-Local Address TLV 531 3.9. IPv4 Link-Local Address TLV 533 The IPv4 Link-Local Address TLV is to be used with IPv4 address 534 families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV 535 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 536 other Extended LSAs MUST be ignored. 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | 8 (IPv4 Local-Local Address) | TLV Length | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | IPv4 Link-Local Interface Address | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 . . 546 . sub-TLVs . 547 . . 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 IPv4 Link-Local Address TLV 552 3.10. IPv6-Forwarding-Address Sub-TLV 554 The IPv6 Forwarding Address TLV has identical semantics to the 555 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv6 556 Forwarding Address TLV is applicable to the External-Prefix TLV 557 (Section 3.6). Specification as a sub-TLV of other TLVs is not 558 defined herein. The sub-TLV is optional and the first specified 559 instance is used as the Forwarding Address as defined in [OSPFV3]. 560 Instances subsequent to the first MUST be ignored. 562 The IPv6 Forwarding Address TLV is to be used with IPv6 address 563 families as defined in [OSPFV3-AF] It MUST be ignored for other 564 address families. 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | 1 - Forwarding Address | sub-TLV Length | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | | 572 +- -+ 573 | | 574 +- Forwarding Address -+ 575 | | 576 +- -+ 577 | | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Forwarding Address Tag TLV 582 3.11. IPv4-Forwarding-Address Sub-TLV 584 The IPv4 Forwarding Address TLV has identical semantics to the 585 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv4 586 Forwarding Address TLV is The IPv4 Forwarding Address TLV is 587 applicable to the External-Prefix TLV (Section 3.6). Specification 588 as a sub-TLV of other TLVs is not defined herein. The sub-TLV is 589 optional and the first specified instance is used as the Forwarding 590 Address as defined in [OSPFV3]. Instances subsequent to the first 591 MUST be ignored. 593 The IPv4 Forwarding Address TLV is to be used with IPv3 address 594 families as defined in [OSPFV3-AF] It MUST be ignored for other 595 address families. 597 0 1 2 3 598 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 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | 2 - Forwarding Address | sub-TLV Length | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Forwarding Address | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 Forwarding Address Tag TLV 607 3.12. Route-Tag Sub-TLV 609 The optional Route Tag sub-TLV has identical semantics to the 610 optional External Route Tag in section A.4.7 of [OSPFV3]. The Route 611 Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.6). 612 Specification as a sub-TLV of other TLVs is not defined herein. The 613 sub-TLV is optional and the first specified instance is used as the 614 Route Tag as defined in [OSPFV3]. Instances subsequent to the first 615 MUST be ignored. 617 0 1 2 3 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | 3 - Route Tag | sub-TLV Length | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Route Tag | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 Route Tag Sub-TLV 627 4. OSPFv3 Extended LSAs 629 This section specifies the OSPFv3 Extended LSA formats and encoding. 630 The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3 631 LSAs specifed in [OSPFV3]. 633 4.1. OSPFv3 E-Router-LSA 635 The E-Router-LSA has an LS Type of 0xA021 and has the same base 636 information content as the Router-LSA defined in section A.4.3 of 637 [OSPFV3]. However, unlike the existing Router-LSA, it is fully 638 extendable and represented as TLVs. 640 0 1 2 3 641 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 642 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | LS Age |1|0|1| 0x21 | 644 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Link State ID | 646 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Advertising Router | 648 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | LS Sequence Number | 650 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | LS Checksum | Length | 652 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | 0 |Nt|x|V|E|B| Options | 654 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 . . 656 . TLVs . 657 . . 658 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 Extended Router-LSA 662 All LSA Header fields are the same as defined for the Router-LSA. 663 Initially, only the top-level Router-Link TLV Section 3.2 is 664 applicable and an E-Router-LSA may include multiple Router-Link TLVs. 665 Like the existing Router-LSA, the LSA length is used to determine the 666 end of the LSA including TLVs. 668 4.2. OSPFv3 E-Network-LSA 670 The E-Network-LSA has an LS Type of 0xA022 and has the same base 671 information content as the Network-LSA defined in section A.4.4 of 672 [OSPFV3]. However, unlike the existing Network-LSA, it is fully 673 extendable and represented as TLVs. 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | LS Age |1|0|1| 0x22 | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Link State ID | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Advertising Router | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | LS Sequence Number | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | LS Checksum | Length | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | 0 | Options | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 . . 691 . TLVs . 692 . . 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 E-Network-LSA 697 All LSA Header fields are the same as defined for the Network-LSA. 698 Like the existing Network-LSA, the LSA length is used to determine 699 the end of the LSA including TLVs. Initially, only the top-level 700 Attached-Routers TLV Section 3.3 is applicable. If the Attached- 701 Router TLV is not included in the E-Network-LSA, it is treated as 702 malformed as described in Section 5. Instances of the Attached- 703 Router TLV subsequent to the first MUST be ignored. 705 4.3. OSPFv3 E-Inter-Area-Prefix-LSA 707 The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same 708 base information content as the Inter-Area-Prefix-LSA defined in 709 section A.4.5 of [OSPFV3]. However, unlike the existing Inter-Area- 710 Prefix-LSA, it is fully extendable and represented as TLVs. 712 0 1 2 3 713 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 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | LS Age |1|0|1| 0x23 | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Link State ID | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Advertising Router | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | LS Sequence Number | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | LS Checksum | Length | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 . . 726 . TLVs . 727 . . 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 E-Inter-Area-Prefix-LSA 732 All LSA Header fields are the same as defined for the Inter-Area- 733 Prefix-LSA. In order to retain compatibility and semantics with the 734 current OSPFv3 specification, each Inter-Area-Prefix LSA MUST contain 735 a single Inter-Area Prefix TLV. This will facilitate migration and 736 avoid changes to functions such as incremental SPF computation. 738 Like the existing Inter-Area-Prefix-LSA, the LSA length is used to 739 determine the end of the LSA including TLV. Initially, only the top- 740 level Inter-Area-Prefix TLV (Section 3.4) is applicable. If the 741 Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA, 742 it is treated as malformed as described in Section 5. Instances of 743 the Inter-Area-Prefix TLV subsequent to the first MUST be ignored. 745 4.4. OSPFv3 E-Inter-Area-Router-LSA 747 The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same 748 base information content as the Inter-Area-Router-LSAE defined in 749 section A.4.6 of [OSPFV3]. However, unlike the Inter-Area-Router- 750 LSA, it is fully extendable and represented as TLVs. 752 0 1 2 3 753 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 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | LS Age |1|0|1| 0x24 | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Link State ID | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Advertising Router | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | LS Sequence Number | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | LS Checksum | Length | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 . . 766 . TLVs . 767 . . 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 E-Inter-Area-Router-LSA 772 All LSA Header fields are the same as defined for the Inter-Area- 773 Router-LSA. In order to retain compatibility and semantics with the 774 current OSPFv3 specification, each Inter-Area-Router LSA MUST contain 775 a single Inter-Area Router TLV. This will facilitate migration and 776 avoid changes to functions 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 All LSA Header fields are the same as defined for the AS-External- 813 LSA. In order to retain compatibility and semantics with the current 814 OSPFv3 specification, each LSA MUST contain a single External Prefix 815 TLV. This will facilitate migration and avoid changes to OSPFv3 816 processes such as incremental SPF computation. 818 Like the existing AS-External-LSA, the LSA length is used to 819 determine the end of the LSA including sub-TLVs. Initially, only the 820 top-level External-Prefix TLV (Section 3.6) is applicable. If the 821 External-Prefix TLV is not included in the E-External-AS-LSA, it is 822 treated as malformed as described in Section 5. Instances of the 823 External-Prefix TLV subsequent to the first MUST be ignored. 825 4.6. OSPFv3 E-NSSA-LSA 827 The E-NSSA-LSA will have the same format and TLVs as the Extended AS- 828 External-LSA Section 4.5. This is the same relationship as exists 829 between the NSSA-LSA defined in section A.4.8 of [OSPFV3], and the 830 AS-External-LSA. The NSSA-LSA will have type 0xA027 which implies 831 area flooding scope. Future requirements may dictate that supported 832 TLVs differ between the E-AS-External-LSA and the E-NSSA-LSA. 833 However, future requirements are beyond the scope of this document. 835 4.7. OSPFv3 E-Link-LSA 837 The E-Link-LSA has an LS Type of 0x8028 and will have the same base 838 information content as the Link-LSA defined in section A.4.9 of 839 [OSPFV3]. However, unlike the existing Link-LSA, it is extendable 840 and represented as TLVs. 842 0 1 2 3 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | LS Age |1|0|0| 0x28 | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Link State ID | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Advertising Router | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | LS Sequence Number | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | LS Checksum | Length | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Rtr Priority | Options | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 . . 858 . TLVs . 859 . . 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 E-Link-LSA 864 All LSA Header fields are the same as defined for the Link-LSA. 866 Only the Intra-Area-Prefix TLV (Section 3.7), IPv6 Link-Local Address 867 TLV (Section 3.8), and IPv4 Link-Local Address TLV (Section 3.9) are 868 applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA 869 affords advertisement of multiple intra-area prefixes. Hence, 870 multiple Intra-Area Prefix TLVs (Section 3.7) may be specified and 871 the LSA length defines the end of the LSA including all TLVs. 873 A single instance of the IPv6 Link-Local Address TLV (Section 3.8) 874 SHOULD be included in the E-Link-LSA. Instances following the first 875 MUST be ignored. For IPv4 address families as defined in 876 [OSPFV3-AF], this TLV MUST be ignored. 878 Similarly, only a single instance of the IPv4 Link-Local Address TLV 879 (Section 3.9) SHOULD be included in the E-Link-LSA. Instances 880 following the first MUST be ignored. For OSPFv3 IPv6 address 881 families as defined in [OSPFV3-AF], this TLV MUST be ignored. 883 If the IPv4/IPv6 Link-Local Address TLV corresponding to the OSPFv3 884 Address Family is not included in the E-Link-LSA, it is treated as 885 malformed as described in Section 5. 887 Future specifications may support advertisement of routing and 888 topology information for multiple address families. However, this is 889 beyond the scope of this document. 891 4.8. OSPFv3 E-Intra-Area-Prefix-LSA 893 The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same 894 base information content as the Intra-Area-Prefix-LSA defined in 895 section A.4.10 of [OSPFV3]. However, unlike the Intra-Area-Prefix- 896 LSA, it is fully extendable and represented as TLVs. 898 0 1 2 3 899 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 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | LS Age |1|0|1| 0x29 | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Link State ID | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Advertising Router | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | LS Sequence Number | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | LS Checksum | Length | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | 0 | Referenced LS Type | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Referenced Link State ID | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Referenced Advertising Router | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 . . 918 . TLVs . 919 . . 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 E-Intra-Area-Prefix-LSA 924 All LSA Header fields are the same as defined for the Intra-Area- 925 Prefix-LSA. 927 Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords 928 advertisement of multiple intra-area prefixes. Hence, multiple 929 Intra-Area Prefix TLVs may be specified and the LSA length defines 930 the end of the LSA including all TLVs. 932 5. Malformed OSPFv3 Extended LSA Handling 934 Extended LSAs that have inconsistent length or other encoding errors, 935 as described herein, MUST NOT be installed in the Link State 936 Database, acknowledged, or flooded. Reception of malformed LSAs 937 SHOULD be counted and/or logged for examination by the administrator 938 of the OSPFv3 Routing Domain. 940 6. LSA Extension Backward Compatibility 942 In the context of this document, backward compatibility is solely 943 related to the capability of an OSPFv3 router to receive, process, 944 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 945 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 946 extensions utilizing the TLV-based LSAs is out of scope and must be 947 covered in the documents describing those extensions. Both full and, 948 if applicable, partial deployment SHOULD be specified for future TLV- 949 based OSPFv3 LSA extensions. 951 6.1. Full Extended LSA Migration 953 If ExtendedLSASupport is enabled Appendix A, OSPFv3 Extended LSAs 954 will be originated and used for the SPF computation. Individual OSPF 955 Areas can be migrated separately with the Legacy AS-External LSAs 956 being originated and used for the SPF computation. This is 957 accomplished by enabled AreaExtendedLSASupport Appendix B. 959 An OSPFv3 routing domain or area may be non-disruptively migrated 960 using separate OSPFv3 instances for the extended LSAs. Initially, 961 the OSPFv3 instances with ExtendedLSASupport will have a lower 962 preference, i.e., higher administrative distance, than the OSPFv3 963 instances originating and using the Legacy LSAs. Once the routing 964 domain or area is fully migrated and the OSPFv3 Routing Information 965 Bases (RIB) have been verified, the OSPFv3 instances using the 966 extended LSAs can be given preference. When this has been completed 967 and the routing within the OSPF routing domain or area has been 968 verified, the original OSPFv3 instance using Legacy LSAs can be 969 removed. 971 6.2. Extended LSA Spare-Mode Backward Compatibility 973 In this mode, OSPFv3 will use the Legacy LSAs for the SPF computation 974 and will only originate extended LSAs when LSA origination is 975 required in support of addtional functionality. Furthermore, the 976 extended LSAs will only include those TLVs which require further 977 specification for that new functionality. Hence, this mode of 978 compatibility is know as "sparse-mode". The advantage of sparse-mode 979 is that functionality utilizing the OSPFv3 extended LSAs can be added 980 to an existing OSFPv3 routing domain without the requirement for 981 migration. In essence, this compatibility mode is very much like the 982 approach taken for OSPFv2 [OSPF-PREFIX-LINK]. As with all the 983 compatibility modes, backward compatibility for the functions 984 utilizing the extended LSAs must be described in the IETF documents 985 describing those functions. 987 6.3. LSA TLV Processing Backward Compatibility 989 This section defines the general rules for processing LSA TLVs. To 990 ensure compatibility of future TLV-based LSA extensions, all 991 implementations MUST adhere to these rules: 993 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or 994 processing Extended-LSAs. 996 2. Whether or not partial deployment of a given TLV is supported 997 MUST be specified. 999 3. If partial deployment is not supported, mechanisms to ensure the 1000 corresponding feature are not deployed MUST be specified in the 1001 document defining the new TLV or sub-TLV. 1003 4. If partial deployment is supported, backward compatibility and 1004 partial deployment MUST be specified in the document defining the 1005 new TLV or sub-TLV. 1007 7. Security Considerations 1009 In general, extendible OSPFv3 LSAs are subject to the same security 1010 concerns as those described in RFC 5340 [OSPFV3]. Additionally, 1011 implementations must assure that malformed TLV and sub-TLV 1012 permutations do not result in errors that cause hard OSPFv3 failures. 1014 If there were ever a requirement to digitally sign OSPFv3 LSAs as 1015 described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the 1016 mechanisms described herein would greatly simplify the extension. 1018 8. IANA Considerations 1020 This specification defines nine OSPFv3 Extended LSA types as 1021 described in Section 2. 1023 This specification also creates two registries OSPFv3 Extended-LSAs 1024 TLVs and sub-TLVs. The TLV and sub-TLV code-points in these 1025 registries are common to all Extended-LSAs and their respective 1026 definitions must define where they are applicable. 1028 The OSPFv3 Extended-LSA TLV registry will define top-level TLVs for 1029 Extended-LSAs and should be placed in the existing OSPFv3 IANA 1030 registry. New values can be allocated via IETF Consensus or IESG 1031 Approval. 1033 Nine values are allocated by this specification: 1035 o 0 - Reserved 1037 o 1 - Router-Link TLV 1039 o 2 - Attached-Routers TLV 1041 o 3 - Inter-Area Prefix TLV 1043 o 4 - Inter-Area Router TLV 1045 o 5 - External Prefix TLV 1047 o 6 - Intra-Area Prefix TLV 1049 o 7 - IPv6 Link-Local Address TLV 1051 o 8 - IPv4 Link-Local Address TLV 1053 The OSPFv3 Extended-LSA sub-TLV registry will define sub-TLVs at any 1054 level of nesting for Extended-LSAs and should be placed in the 1055 existing OSPFv3 IANA registry. New values can be allocated via IETF 1056 Review. 1058 Three values are allocated by this specification: 1060 o 0 - Reserved 1062 o 1 - Forwarding Address 1064 o 2 - Route Tag 1066 The OSPFv3 Prefix Options registry will define a new code point for 1067 the N-bit. The value 0x20 is suggested. 1069 9. References 1071 9.1. Normative References 1073 [GRACEFUL-RESTART] 1074 Lindem, A. and P. Pillay-Esnault, "OSPFv3 Graceful 1075 Restart", RFC 5187, June 2008. 1077 [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1078 RFC 3101, January 2003. 1080 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1081 for IPv6", RFC 5340, July 2008. 1083 [OSPFV3-AF] 1084 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 1085 Aggarwal, "Support of Address Families in OSPFv3", RFC 1086 5838, April 2010. 1088 [RFC-KEYWORDS] 1089 Bradner, S., "Key words for use in RFCs to Indicate 1090 Requirement Levels", RFC 2119, March 1997. 1092 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 1093 Extensions to OSPF", RFC 3630, September 2003. 1095 9.2. Informative References 1097 [MT-OSPFV3] 1098 Mirtorabi, S. and A. Roy, "Multi-topology routing in 1099 OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-03.txt 1100 (work in progress), January 2008. 1102 [OSPF-DIGITAL-SIGNATURE] 1103 Murphy, S., Badger, M., and B. Wellington, "OSPF with 1104 Digital Signatures", RFC 2154, June 1997. 1106 [OSPF-PREFIX-LINK] 1107 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1108 Tantsura, J., and A. Lindem, "OSPF Prefix/Link 1109 Attributes", RFC 7684, December 2015. 1111 [SEGMENT-ROUTING] 1112 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1113 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1114 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1115 segment-routing-extensions-06.txt (work in progress), July 1116 2016. 1118 Appendix A. Appendix A - Global Configuration Parameters 1120 The global configurable parameter ExtendedLSASupport will be added to 1121 the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 1122 Router will originate OSPFv3 Extended LSAs and use the LSAs for the 1123 SPF computation. If ExtendedLSASupport is not enabled, a subset of 1124 OSPFv3 Extended LSAs may still be originated and used for other 1125 functions as described in Section 6.2. 1127 Appendix B. Appendix B - Area Configuration Parameters 1129 The area configurable parameter AreaExtendedLSASupport will be added 1130 to the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 1131 Router will originate link and area OSPFv3 Extended LSAs and use the 1132 LSAs for the SPF computation. Legacy AS-Scoped LSAs will still be 1133 originated and used for the AS External LSA computation. If 1134 AreaExtendedLSASupport is not enabled a subset of OSPFv3 link and 1135 area Extended LSAs may still be originated and used for other 1136 functions as described in Section 6.2. 1138 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1139 disabling AreaExtendedLSASupport when ExtendedLSASupport is enabled 1140 is contradictory and MAY be prohibited by the implementation. 1142 Appendix C. Appendix C - Deprecated LSA Extension Backward 1143 Compatibility 1145 In the context of this document, backward compatibility is solely 1146 related to the capability of an OSPFv3 router to receive, process, 1147 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 1148 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 1149 extensions utilizing the TLV-based LSAs is out of scope and must be 1150 covered in the documents describing those extensions. Both full and, 1151 if applicable, partial deployment SHOULD be specified for future TLV- 1152 based OSPFv3 LSA extensions. 1154 Three distinct backward compatibility modes are supported dependent 1155 on the OSPFv3 routing domain migration requirements. For simplicity 1156 and to avoid the scaling impact of maintaining both TLV and non-TLV 1157 based versions of the same LSA within a routing domain, the basic 1158 backward compatibility mode will not allow mixing of LSA formats. 1159 Different LSA formats could still be supported with multiple OSPFv3 1160 instances and separate OSPFv3 routing domains. Additionally, a more 1161 flexible mode is provided in Appendix C.1, where both formats of LSA 1162 coexist. In order to facilitate backward compatibility, the OSPFv3 1163 options field (as described in Appendix A.2 of RFC 5340 [OSPFV3]), 1164 will contain two additional options bits. The EL-bits will be used 1165 to indicate that the OSPFv3 router's level of Extended LSA support. 1166 An OSPFv3 router configured to support extended LSAs MUST set its 1167 options field EL-bits in OSPFv3 Hello and Database Description 1168 packets as follows: 1170 B'00' 1171 None - Extended LSAs are not originated nor used in the SPF 1172 calculation (except for future functionalities as described in 1173 Section 6.2) . 1175 B'01' 1176 MixedModeOriginateOnly - Both Extended and Legacy LSAs are 1177 originated. Legacy LSAs are used in the SPF computation. 1179 B'10' 1180 MixedModeOriginateSPF - Both extended and Legacy LSAs are 1181 originated. Extended LSAs are used in the SPF computation. 1183 B'11' 1184 Full - Only extended LSAs are originated and used in the SPF 1185 computation. 1187 If Full is specified for ExtendedLSASupport, the OSPFv3 router MUST 1188 NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and 1189 Database Description packets with the options field EL-bits set to 1190 MixedModeOriginateOnly or None. Similarly, if MixModeOriginateSPF is 1191 specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form 1192 adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database 1193 Description packets with the options field EL-bits set to None 1194 (B'00'). In this manner, OSPFv3 routers using new encodings can be 1195 completely isolated from those OSPFv3 routers depending on the RFC 1196 5340 encoding and not setting their options field EL-bits since the 1197 default setting indicates no support for extended LSAs. 1199 Finally, a mode supporting existing OSPFv3 routing domains is 1200 provided. This mode, subsequently referred to as "sparse-mode", will 1201 use the TLV-based LSAs solely in support of new functionality 1202 Section 6.2. In this compatibility mode, the EL-bits will be 1203 advertised as B'00' since the backward compatibility with the Legacy 1204 LSAs is not supported or required. 1206 1 2 1207 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 1209 | | | | | | | | | | | | EL|AT|L|AF|*|*|DC|R|N|x|E|V6| 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 1211 The Options field 1213 EL-bits 1214 These bits indicate the level of Extended LSA support. 1215 B'00' - Extended LSAs are not originate nor used in the 1216 SPF calculation (except for new functionalities 1217 for future functions as described in Section 6.2). 1218 B'01' - Both extended and Legacy LSAs are originated. 1219 Non-extended LSAs are used in the SPF computation. 1220 B'10' - Both extended and Legacy LSAs are originated. 1221 Extended LSAs are used in the SPF computation. 1222 B'11' - Only extended LSA are originated and used in the 1223 SPF computation. 1225 Options Field EL-bits 1227 The EL-bits will also be set in the LSA options field in Extended and 1228 Legacy LSAs. While the value of the EL-bits has no functional 1229 significance in the LSA options field, visibility of every OSPFv3 1230 Router's extended LSA support is expected to be very useful for 1231 management and troubleshooting during the migration period. 1233 C.1. Extended LSA Mixed-Mode Backward Compatibility 1235 An implementation MAY support configuration allowing a graceful 1236 transition from the Legacy (non-TLV-based) LSAs to the extended (TLV- 1237 based) LSAs in an OSPFv3 routing domain. In these routing domains, 1238 the OSPFv3 routers configured with a value of MixedModeOriginateOnly 1239 or MixedModeOriginateSPF for ExtendedLSASupport, (Appendix C.2), MUST 1240 originate both the extended and legacy versions of the OSPFv3 LSAs 1241 described herein. For the purposes of Shortest Path First (SPF) 1242 computation, the Legacy LSAs are used for SPF computation when 1243 MixedModeOriginateOnly is configured and the extended LSAs are used 1244 when MixedModeOriginateSPF is specified. The Extended LSAs MAY be 1245 used for functions other than routing computation as long as backward 1246 compatibility is specified in the documents specifying those 1247 functions. 1249 In this manner, OSPFv3 routing domains utilizing the new encodings 1250 can be gradually migrated with a worst-case overhead cost of 1251 approximately doubling the number of LSAs in the routing domain. The 1252 transition within an OSPFv3 routing domain would progress as follows: 1254 1. Configure OSPFv3 Router ExtendedLSASupport to 1255 MixedModeOriginateOnly so that routers originate the extended 1256 LSAs. 1258 2. When all the OSPFv3 Routers have been reconfigured to 1259 MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to 1260 use the extended LSAs by configuring ExtendedLSASupport to 1261 MixedModeOriginateSPF. This can be done on a small subset of 1262 OSPFv3 Routers and the route tables can be verified. 1264 3. When all the OSPFv3 Routers have been reconfigured to 1265 MixedModeOriginateSPF and the routing has been verified, 1266 reconfigure OSPFv3 Routers to purge or simply not refresh the 1267 Legacy LSA by configuring ExtendedLSASupport to Full. 1269 In order to prevent OSPFv3 routing domain routing loops, the 1270 advertised metrics in the Extended LSAs and Legacy LSAs MUST be 1271 identical. 1273 C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility 1275 An implementation MAY also support configuration allowing graceful 1276 transition from the Legacy LSAs to the extended LSAs within a single 1277 area. In these areas, the parameter AreaExtendedLSASupport 1278 (Appendix C.3) may be configured to take precedence over the global 1279 parameter ExtendedLSASupport. However, the AreaExtendedLSASupport 1280 will only apply to link and area scoped LSAs within the area and area 1281 based SPF calculations. The default is for the 1282 AreaExtendedLSASupport to be inherited from the ExtendedLSASupport. 1283 The configuration of ExtendedLSASupport will apply to AS-External 1284 LSAs even when AreaExtendedLSASupport takes precedence. 1286 When preforming a graceful restart [GRACEFUL-RESTART], an OSPFv3 1287 router configured with MixedModeOriginate will use the Legacy LSAs to 1288 determine whether or not the graceful restart has completed 1289 successfully. Similarly, an OSPFv3 router configured with 1290 MixedModeOriginateSPF will use the extended LSAs. In other words, 1291 successful OSPFv3 graceful restart determination will follow the SPF 1292 calculation. 1294 C.2. Global Configuration Parameters 1296 An additional global configurable parameter will be added to the 1297 OSPFv3 protocol. 1299 ExtendedLSASupport 1300 This is an enumeration type indicating the extent to which the 1301 OSPFv3 instance supports the TLV format described herein for 1302 Extended LSAs. The valid values for the enumeration are: 1304 * None - Extended LSAs will not be originated or used in the SPF 1305 calculation. This is the default. When OSPFv3 functions 1306 requiring extended LSA are configured, and the 1307 ExtendedLSASuppport is "None", extended LSAs may be used as 1308 described in Section 6.2. 1310 * MixedModeOriginateOnly - Both extended and Legacy LSAs will be 1311 originated. OSPFv3 adjacencies will be formed with OSPFv3 1312 routers not supporting this specification. The Legacy LSAs are 1313 used for the SPF computation. 1315 * MixedModeOriginateSPF - Both Extended LSAs and Legacy LSAs will 1316 be originated. OSPFv3 adjacencies will be formed with OSPFv3 1317 routers not supporting this specification. The Extended LSAs 1318 are used for the SPF computation. 1320 * Full - Extended LSAs will be originated and adjacencies will 1321 ndot be formed with OSPFv3 routers not supporting this 1322 specification. Only Extended LSAs will be originated. 1324 C.3. Area Configuration Parameters 1326 An additional area configurable parameter will be added to the OSPFv3 1327 protocol. 1329 AreaExtendedLSASupport 1330 This is an enumeration type indicating the extent to which the 1331 OSPFv3 area supports the TLV format described herein for Extended 1332 LSAs. The valid value for the enumeration are: 1334 * InheritGlobal - The AreaExtendedLSASupport will be inherited 1335 from ExtendedLSASupport. This is the default. 1337 * None - Extended LSAs will not be originated or used in the SPF 1338 calculation. This is the default. When OSPFv3 functions 1339 requiring extended LSA are configured, and the 1340 ExtendedLSASuppport is "None", the spare-mode compatability is 1341 in effect Section 6.2. 1343 * MixedModeOriginateOnly - Both extended and legacy link and area 1344 scoped LSAs will be originated. OSPFv3 adjacencies will be 1345 formed with OSPFv3 routers not supporting this specification. 1346 The Legacy LSAs are used for the area SPF computation. 1348 * MixedModeOriginateSPF - Both extended and legacy link and area 1349 scoped LSAs will be originated. OSPFv3 adjacencies will be 1350 formed with OSPFv3 routers not supporting this specification. 1351 The Extended LSAs are used for the area SPF computation. 1353 * Full - Link and area scoped Extended LSAs will be originated 1354 and adjacencies will not be formed with OSPFv3 routers not 1355 supporting this specification. Only Extended LSAs will be 1356 originated. 1358 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1359 configuring None or MixedModeOriginateOnly for AreaExtendedLSASupport 1360 when Full is specified for ExtendedLSASupport is contradictory and 1361 MAY be prohibited by the implementation. 1363 Authors' Addresses 1365 Acee Lindem 1366 Cisco Systems 1367 301 Midenhall Way 1368 Cary, NC 27513 1369 USA 1371 Email: acee@cisco.com 1373 Sina Mirtorabi 1374 Cisco Systems 1375 170 Tasman Drive 1376 San Jose, CA 95134 1377 USA 1379 Email: sina@cisco.com 1381 Abhay Roy 1382 Cisco Systems 1383 170 Tasman Drive 1384 San Jose, CA 95134 1385 USA 1387 Email: akr@cisco.com 1388 Fred Baker 1389 Santa Barbara, California 93117 1390 USA 1392 Email: FredBaker.IETF@gmail.com