idnits 2.17.1 draft-ietf-ospf-ospfv3-lsa-extend-12.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 (September 26, 2016) is 2769 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: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-06 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: March 30, 2017 Cisco Systems 6 F. Baker 8 September 26, 2016 10 OSPFv3 LSA Extendibility 11 draft-ietf-ospf-ospfv3-lsa-extend-12.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 March 30, 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 and Chris Bowers for review and editorial 174 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. The 430 field definitions correspond directly to the content of an OSPFv3 431 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 AS- 432 External-LSA, as defined in section A.4.7, [OSPFV3]. The External- 433 Prefix TLV is only applicable to the E-AS-External-LSA (Section 4.5) 434 and the E-NSSA-LSA (Section 4.6). Additionally, the PrefixOptions 435 are extended as described in Section 3.1. Inclusion in other 436 Extended LSAs MUST be ignored. 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | 5 (External Prefix) | TLV Length | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | |E| | | Metric | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | PrefixLength | PrefixOptions | 0 | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Address Prefix | 448 | ... | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 . . 451 . sub-TLVs . 452 . . 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 External Prefix TLV 457 In the External-Prefix TLV, the optional IPv6/IPv4 Forwarding Address 458 and External Route Tag are now sub-TLVs. Given the Referenced LS 459 type and Referenced Link State ID from the AS-External-LSA have never 460 been used or even specified, they have been omitted from the External 461 Prefix TLV. If there were ever a requirement for a referenced LSA, 462 it could be satisfied with a sub-TLV. 464 The following sub-TLVs are defined for optional inclusion in the 465 External Prefix TLV: 467 o 1 - IPv6 Forwarding Address sub-TLV (Section 3.10) 469 o 2 - IPv4 Forwarding Address sub-TLV (Section 3.11) 471 o 3 - Route Tag sub-TLV (Section 3.12) 473 3.7. Intra-Area-Prefix TLV 475 The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix. 476 The field definitions correspond directly to the content of an OSPFv3 477 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 Link- 478 LSA, as defined in section A.4.9, [OSPFV3]. The Intra-Area-Prefix 479 TLV is only applicable to the E-Link-LSA (Section 4.7) and the 480 Additionally, the PrefixOptions are extended as described in 481 Section 3.1. E-Intra-Area-Prefix-LSA (Section 4.8). Inclusion in 482 other Extended LSAs MUST be ignored. 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | 6 (Intra-Area Prefix) | TLV Length | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | 0 | Metric | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | PrefixLength | PrefixOptions | 0 | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Address Prefix | 494 | ... | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 . . 497 . sub-TLVs . 498 . . 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Intra-Area Prefix TLV 503 3.8. IPv6 Link-Local Address TLV 505 The IPv6 Link-Local Address TLV is to be used with IPv6 address 506 families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV 507 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 508 other Extended LSAs MUST be ignored. 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | 7 (IPv6 Local-Local Address) | TLV Length | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | | 516 +- -+ 517 | | 518 +- IPv6 Link-Local Interface Address -+ 519 | | 520 +- -+ 521 | | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 . . 524 . sub-TLVs . 525 . . 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 IPv6 Link-Local Address TLV 530 3.9. IPv4 Link-Local Address TLV 532 The IPv4 Link-Local Address TLV is to be used with IPv4 address 533 families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV 534 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 535 other Extended LSAs MUST be ignored. 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | 8 (IPv4 Local-Local Address) | TLV Length | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | IPv4 Link-Local Interface Address | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 . . 545 . sub-TLVs . 546 . . 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 IPv4 Link-Local Address TLV 551 3.10. IPv6-Forwarding-Address Sub-TLV 553 The IPv6 Forwarding Address TLV has identical semantics to the 554 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv6 555 Forwarding Address TLV is applicable to the External-Prefix TLV 556 (Section 3.6). Specification as a sub-TLV of other TLVs is not 557 defined herein. The sub-TLV is optional and the first specified 558 instance is used as the Forwarding Address as defined in [OSPFV3]. 559 Instances subsequent to the first MUST be ignored. 561 The IPv6 Forwarding Address TLV is to be used with IPv6 address 562 families as defined in [OSPFV3-AF] It MUST be ignored for other 563 address families. 565 0 1 2 3 566 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | 1 - Forwarding Address | sub-TLV Length | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | | 571 +- -+ 572 | | 573 +- Forwarding Address -+ 574 | | 575 +- -+ 576 | | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Forwarding Address Tag TLV 581 3.11. IPv4-Forwarding-Address Sub-TLV 583 The IPv4 Forwarding Address TLV has identical semantics to the 584 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv4 585 Forwarding Address TLV is The IPv4 Forwarding Address TLV is 586 applicable to the External-Prefix TLV (Section 3.6). Specification 587 as a sub-TLV of other TLVs is not defined herein. The sub-TLV is 588 optional and the first specified instance is used as the Forwarding 589 Address as defined in [OSPFV3]. Instances subsequent to the first 590 MUST be ignored. 592 The IPv4 Forwarding Address TLV is to be used with IPv3 address 593 families as defined in [OSPFV3-AF] It MUST be ignored for other 594 address families. 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | 2 - Forwarding Address | sub-TLV Length | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Forwarding Address | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Forwarding Address Tag TLV 606 3.12. Route-Tag Sub-TLV 608 The optional Route Tag sub-TLV has identical semantics to the 609 optional External Route Tag in section A.4.7 of [OSPFV3]. The Route 610 Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.6). 611 Specification as a sub-TLV of other TLVs is not defined herein. The 612 sub-TLV is optional and the first specified instance is used as the 613 Route Tag as defined in [OSPFV3]. Instances subsequent to the first 614 MUST be ignored. 616 0 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | 3 - Route Tag | sub-TLV Length | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Route Tag | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 Route Tag Sub-TLV 626 4. OSPFv3 Extended LSAs 628 This section specifies the OSPFv3 Extended LSA formats and encoding. 629 The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3 630 LSAs specifed in [OSPFV3]. 632 4.1. OSPFv3 E-Router-LSA 634 The E-Router-LSA has an LS Type of 0xA021 and has the same base 635 information content as the Router-LSA defined in section A.4.3 of 636 [OSPFV3]. However, unlike the existing Router-LSA, it is fully 637 extendable and represented as TLVs. 639 0 1 2 3 640 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 641 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | LS Age |1|0|1| 0x21 | 643 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Link State ID | 645 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Advertising Router | 647 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | LS Sequence Number | 649 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | LS Checksum | Length | 651 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | 0 |Nt|x|V|E|B| Options | 653 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 . . 655 . TLVs . 656 . . 657 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 Extended Router-LSA 661 All LSA Header fields are the same as defined for the Router-LSA. 662 Initially, only the top-level Router-Link TLV Section 3.2 is 663 applicable and an E-Router-LSA may include multiple Router-Link TLVs. 664 Like the existing Router-LSA, the LSA length is used to determine the 665 end of the LSA including TLVs. 667 4.2. OSPFv3 E-Network-LSA 669 The E-Network-LSA has an LS Type of 0xA022 and has the same base 670 information content as the Network-LSA defined in section A.4.4 of 671 [OSPFV3]. However, unlike the existing Network-LSA, it is fully 672 extendable and represented as TLVs. 674 0 1 2 3 675 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 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | LS Age |1|0|1| 0x22 | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Link State ID | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Advertising Router | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | LS Sequence Number | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | LS Checksum | Length | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | 0 | Options | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 . . 690 . TLVs . 691 . . 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 E-Network-LSA 696 All LSA Header fields are the same as defined for the Network-LSA. 697 Like the existing Network-LSA, the LSA length is used to determine 698 the end of the LSA including TLVs. Initially, only the top-level 699 Attached-Routers TLV Section 3.3 is applicable. If the Attached- 700 Router TLV is not included in the E-Network-LSA, it is treated as 701 malformed as described in Section 5. Instances of the Attached- 702 Router TLV subsequent to the first MUST be ignored. 704 4.3. OSPFv3 E-Inter-Area-Prefix-LSA 706 The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same 707 base information content as the Inter-Area-Prefix-LSA defined in 708 section A.4.5 of [OSPFV3]. However, unlike the existing Inter-Area- 709 Prefix-LSA, it is fully extendable and represented as TLVs. 711 0 1 2 3 712 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 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | LS Age |1|0|1| 0x23 | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Link State ID | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Advertising Router | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | LS Sequence Number | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | LS Checksum | Length | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 . . 725 . TLVs . 726 . . 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 E-Inter-Area-Prefix-LSA 731 All LSA Header fields are the same as defined for the Inter-Area- 732 Prefix-LSA. In order to retain compatibility and semantics with the 733 current OSPFv3 specification, each Inter-Area-Prefix LSA MUST contain 734 a single Inter-Area Prefix TLV. This will facilitate migration and 735 avoid changes to functions 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 All LSA Header fields are the same as defined for the Inter-Area- 772 Router-LSA. In order to retain compatibility and semantics with the 773 current OSPFv3 specification, each Inter-Area-Router LSA MUST contain 774 a single Inter-Area Router TLV. This will facilitate migration and 775 avoid changes to functions such as incremental SPF computation. 777 Like the existing Inter-Area-Router-LSA, the LSA length is used to 778 determine the end of the LSA including TLV. Initially, only the top- 779 level Inter-Area-Router TLV (Section 3.5) is applicable. If the 780 Inter-Area-Router TLV is not included in the E-Inter-Area-Router-LSA, 781 it is treated as malformed as described in Section 5. Instances of 782 the Inter-Area-Router TLV subsequent to the first MUST be ignored. 784 4.5. OSPFv3 E-AS-External-LSA 786 The E-AS-External-LSA has an LS Type of 0xC025 and has the same base 787 information content as the AS-External-LSA defined in section A.4.7 788 of [OSPFV3]. However, unlike the existing AS-External-LSA, it is 789 fully extendable and represented as TLVs. 791 0 1 2 3 792 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 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | LS Age |1|1|0| 0x25 | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Link State ID | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Advertising Router | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | LS Sequence Number | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | LS Checksum | Length | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 . . 805 . TLVs . 806 . . 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 E-AS-External-LSA 811 All LSA Header fields are the same as defined for the AS-External- 812 LSA. In order to retain compatibility and semantics with the current 813 OSPFv3 specification, each LSA MUST contain a single External Prefix 814 TLV. This will facilitate migration and avoid changes to OSPFv3 815 processes such as incremental SPF computation. 817 Like the existing AS-External-LSA, the LSA length is used to 818 determine the end of the LSA including sub-TLVs. Initially, only the 819 top-level External-Prefix TLV (Section 3.6) is applicable. If the 820 External-Prefix TLV is not included in the E-External-AS-LSA, it is 821 treated as malformed as described in Section 5. Instances of the 822 External-Prefix TLV subsequent to the first MUST be ignored. 824 4.6. OSPFv3 E-NSSA-LSA 826 The E-NSSA-LSA will have the same format and TLVs as the Extended AS- 827 External-LSA Section 4.5. This is the same relationship as exists 828 between the NSSA-LSA defined in section A.4.8 of [OSPFV3], and the 829 AS-External-LSA. The NSSA-LSA will have type 0xA027 which implies 830 area flooding scope. Future requirements may dictate that supported 831 TLVs differ between the E-AS-External-LSA and the E-NSSA-LSA. 832 However, future requirements are beyond the scope of this document. 834 4.7. OSPFv3 E-Link-LSA 836 The E-Link-LSA has an LS Type of 0x8028 and will have the same base 837 information content as the Link-LSA defined in section A.4.9 of 838 [OSPFV3]. However, unlike the existing Link-LSA, it is extendable 839 and represented as TLVs. 841 0 1 2 3 842 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 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | LS Age |1|0|0| 0x28 | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Link State ID | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Advertising Router | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | LS Sequence Number | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | LS Checksum | Length | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Rtr Priority | Options | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 . . 857 . TLVs . 858 . . 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 E-Link-LSA 863 All LSA Header fields are the same as defined for the Link-LSA. 865 Only the Intra-Area-Prefix TLV (Section 3.7), IPv6 Link-Local Address 866 TLV (Section 3.8), and IPv4 Link-Local Address TLV (Section 3.9) are 867 applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA 868 affords advertisement of multiple intra-area prefixes. Hence, 869 multiple Intra-Area Prefix TLVs (Section 3.7) may be specified and 870 the LSA length defines the end of the LSA including all TLVs. 872 A single instance of the IPv6 Link-Local Address TLV (Section 3.8) 873 SHOULD be included in the E-Link-LSA. Instances following the first 874 MUST be ignored. For IPv4 address families as defined in 875 [OSPFV3-AF], this TLV MUST be ignored. 877 Similarly, only a single instance of the IPv4 Link-Local Address TLV 878 (Section 3.9) SHOULD be included in the E-Link-LSA. Instances 879 following the first MUST be ignored. For OSPFv3 IPv6 address 880 families as defined in [OSPFV3-AF], this TLV MUST be ignored. 882 If the IPv4/IPv6 Link-Local Address TLV corresponding to the OSPFv3 883 Address Family is not included in the E-Link-LSA, it is treated as 884 malformed as described in Section 5. 886 Future specifications may support advertisement of routing and 887 topology information for multiple address families. However, this is 888 beyond the scope of this document. 890 4.8. OSPFv3 E-Intra-Area-Prefix-LSA 892 The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same 893 base information content as the Intra-Area-Prefix-LSA defined in 894 section A.4.10 of [OSPFV3]. However, unlike the Intra-Area-Prefix- 895 LSA, it is fully extendable and represented as TLVs. 897 0 1 2 3 898 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 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | LS Age |1|0|1| 0x29 | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Link State ID | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Advertising Router | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | LS Sequence Number | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | LS Checksum | Length | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | 0 | Referenced LS Type | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Referenced Link State ID | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Referenced Advertising Router | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 . . 917 . TLVs . 918 . . 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 E-Intra-Area-Prefix-LSA 923 All LSA Header fields are the same as defined for the Intra-Area- 924 Prefix-LSA. 926 Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords 927 advertisement of multiple intra-area prefixes. Hence, multiple 928 Intra-Area Prefix TLVs may be specified and the LSA length defines 929 the end of the LSA including all TLVs. 931 5. Malformed OSPFv3 Extended LSA Handling 933 Extended LSAs that have inconsistent length or other encoding errors, 934 as described herein, MUST NOT be installed in the Link State 935 Database, acknowledged, or flooded. Reception of malformed LSAs 936 SHOULD be counted and/or logged for examination by the administrator 937 of the OSPFv3 Routing Domain. 939 6. LSA Extension Backward Compatibility 941 In the context of this document, backward compatibility is solely 942 related to the capability of an OSPFv3 router to receive, process, 943 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 944 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 945 extensions utilizing the TLV-based LSAs is out of scope and must be 946 covered in the documents describing those extensions. Both full and, 947 if applicable, partial deployment SHOULD be specified for future TLV- 948 based OSPFv3 LSA extensions. 950 6.1. Full Extended LSA Migration 952 If ExtendedLSASupport is enabled Appendix A, OSPFv3 Extended LSAs 953 will be originated and used for the SPF computation. Individual OSPF 954 Areas can be migrated separately with the Legacy AS-External LSAs 955 being originated and used for the SPF computation. This is 956 accomplished by enabled AreaExtendedLSASupport Appendix B. 958 An OSPFv3 routing domain or area may be non-disruptively migrated 959 using separate OSPFv3 instances for the extended LSAs. Initially, 960 the OSPFv3 instances with ExtendedLSASupport will have a lower 961 preference, i.e., higher administrative distance, than the OSPFv3 962 instances originating and using the Legacy LSAs. Once the routing 963 domain or area is fully migrated and the OSPFv3 Routing Information 964 Bases (RIB) have been verified, the OSPFv3 instances using the 965 extended LSAs can be given preference. When this has been completed 966 and the routing within the OSPF routing domain or area has been 967 verified, the original OSPFv3 instance using Legacy LSAs can be 968 removed. 970 6.2. Extended LSA Spare-Mode Backward Compatibility 972 In this mode, OSPFv3 will use the Legacy LSAs for the SPF computation 973 and will only originate extended LSAs when LSA origination is 974 required in support of addtional functionality. Furthermore, the 975 extended LSAs will only include those TLVs which require further 976 specification for that new functionality. Hence, this mode of 977 compatibility is know as "sparse-mode". The advantage of sparse-mode 978 is that functionality utilizing the OSPFv3 extended LSAs can be added 979 to an existing OSFPv3 routing domain without the requirement for 980 migration. In essence, this compatibility mode is very much like the 981 approach taken for OSPFv2 [OSPF-PREFIX-LINK]. As with all the 982 compatibility modes, backward compatibility for the functions 983 utilizing the extended LSAs must be described in the IETF documents 984 describing those functions. 986 6.3. LSA TLV Processing Backward Compatibility 988 This section defines the general rules for processing LSA TLVs. To 989 ensure compatibility of future TLV-based LSA extensions, all 990 implementations MUST adhere to these rules: 992 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or 993 processing Extended-LSAs. 995 2. Whether or not partial deployment of a given TLV is supported 996 MUST be specified. 998 3. If partial deployment is not supported, mechanisms to ensure the 999 corresponding feature are not deployed MUST be specified in the 1000 document defining the new TLV or sub-TLV. 1002 4. If partial deployment is supported, backward compatibility and 1003 partial deployment MUST be specified in the document defining the 1004 new TLV or sub-TLV. 1006 7. Security Considerations 1008 In general, extendible OSPFv3 LSAs are subject to the same security 1009 concerns as those described in RFC 5340 [OSPFV3]. Additionally, 1010 implementations must assure that malformed TLV and sub-TLV 1011 permutations do not result in errors that cause hard OSPFv3 failures. 1013 If there were ever a requirement to digitally sign OSPFv3 LSAs as 1014 described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the 1015 mechanisms described herein would greatly simplify the extension. 1017 8. IANA Considerations 1019 This specification defines nine OSPFv3 Extended LSA types as 1020 described in Section 2. 1022 This specification also creates two registries OSPFv3 Extended-LSAs 1023 TLVs and sub-TLVs. The TLV and sub-TLV code-points in these 1024 registries are common to all Extended-LSAs and their respective 1025 definitions must define where they are applicable. 1027 The OSPFv3 Extended-LSA TLV registry will define top-level TLVs for 1028 Extended-LSAs and should be placed in the existing OSPFv3 IANA 1029 registry. New values can be allocated via IETF Consensus or IESG 1030 Approval. 1032 Nine values are allocated by this specification: 1034 o 0 - Reserved 1036 o 1 - Router-Link TLV 1038 o 2 - Attached-Routers TLV 1040 o 3 - Inter-Area Prefix TLV 1042 o 4 - Inter-Area Router TLV 1044 o 5 - External Prefix TLV 1046 o 6 - Intra-Area Prefix TLV 1048 o 7 - IPv6 Link-Local Address TLV 1050 o 8 - IPv4 Link-Local Address TLV 1052 The OSPFv3 Extended-LSA sub-TLV registry will define sub-TLVs at any 1053 level of nesting for Extended-LSAs and should be placed in the 1054 existing OSPFv3 IANA registry. New values can be allocated via IETF 1055 Review. 1057 Three values are allocated by this specification: 1059 o 0 - Reserved 1061 o 1 - Forwarding Address 1063 o 2 - Route Tag 1065 The OSPFv3 Prefix Options registry will define a new code point for 1066 the N-bit. The value 0x20 is suggested. 1068 9. References 1070 9.1. Normative References 1072 [GRACEFUL-RESTART] 1073 Lindem, A. and P. Pillay-Esnault, "OSPFv3 Graceful 1074 Restart", RFC 5187, June 2008. 1076 [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1077 RFC 3101, January 2003. 1079 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1080 for IPv6", RFC 5340, July 2008. 1082 [OSPFV3-AF] 1083 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 1084 Aggarwal, "Support of Address Families in OSPFv3", RFC 1085 5838, April 2010. 1087 [RFC-KEYWORDS] 1088 Bradner, S., "Key words for use in RFCs to Indicate 1089 Requirement Levels", RFC 2119, March 1997. 1091 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 1092 Extensions to OSPF", RFC 3630, September 2003. 1094 9.2. Informative References 1096 [MT-OSPFV3] 1097 Mirtorabi, S. and A. Roy, "Multi-topology routing in 1098 OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-03.txt 1099 (work in progress), January 2008. 1101 [OSPF-DIGITAL-SIGNATURE] 1102 Murphy, S., Badger, M., and B. Wellington, "OSPF with 1103 Digital Signatures", RFC 2154, June 1997. 1105 [OSPF-PREFIX-LINK] 1106 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1107 Tantsura, J., and A. Lindem, "OSPF Prefix/Link 1108 Attributes", RFC 7684, December 2015. 1110 [SEGMENT-ROUTING] 1111 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1112 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1113 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1114 segment-routing-extensions-06.txt (work in progress), July 1115 2016. 1117 Appendix A. Appendix A - Global Configuration Parameters 1119 The global configurable parameter ExtendedLSASupport will be added to 1120 the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 1121 Router will originate OSPFv3 Extended LSAs and use the LSAs for the 1122 SPF computation. If ExtendedLSASupport is not enabled, a subset of 1123 OSPFv3 Extended LSAs may still be originated and used for other 1124 functions as described in Section 6.2. 1126 Appendix B. Appendix B - Area Configuration Parameters 1128 The area configurable parameter AreaExtendedLSASupport will be added 1129 to the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 1130 Router will originate link and area OSPFv3 Extended LSAs and use the 1131 LSAs for the SPF computation. Legacy AS-Scoped LSAs will still be 1132 originated and used for the AS External LSA computation. If 1133 AreaExtendedLSASupport is not enabled a subset of OSPFv3 link and 1134 area Extended LSAs may still be originated and used for other 1135 functions as described in Section 6.2. 1137 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1138 disabling AreaExtendedLSASupport when ExtendedLSASupport is enabled 1139 is contradictory and MAY be prohibited by the implementation. 1141 Appendix C. Appendix C - Deprecated LSA Extension Backward 1142 Compatibility 1144 In the context of this document, backward compatibility is solely 1145 related to the capability of an OSPFv3 router to receive, process, 1146 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 1147 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 1148 extensions utilizing the TLV-based LSAs is out of scope and must be 1149 covered in the documents describing those extensions. Both full and, 1150 if applicable, partial deployment SHOULD be specified for future TLV- 1151 based OSPFv3 LSA extensions. 1153 Three distinct backward compatibility modes are supported dependent 1154 on the OSPFv3 routing domain migration requirements. For simplicity 1155 and to avoid the scaling impact of maintaining both TLV and non-TLV 1156 based versions of the same LSA within a routing domain, the basic 1157 backward compatibility mode will not allow mixing of LSA formats. 1158 Different LSA formats could still be supported with multiple OSPFv3 1159 instances and separate OSPFv3 routing domains. Additionally, a more 1160 flexible mode is provided in Appendix C.1, where both formats of LSA 1161 coexist. In order to facilitate backward compatibility, the OSPFv3 1162 options field (as described in Appendix A.2 of RFC 5340 [OSPFV3]), 1163 will contain two additional options bits. The EL-bits will be used 1164 to indicate that the OSPFv3 router's level of Extended LSA support. 1165 An OSPFv3 router configured to support extended LSAs MUST set its 1166 options field EL-bits in OSPFv3 Hello and Database Description 1167 packets as follows: 1169 B'00' 1170 None - Extended LSAs are not originated nor used in the SPF 1171 calculation (except for future functionalities as described in 1172 Section 6.2) . 1174 B'01' 1175 MixedModeOriginateOnly - Both Extended and Legacy LSAs are 1176 originated. Legacy LSAs are used in the SPF computation. 1178 B'10' 1179 MixedModeOriginateSPF - Both extended and Legacy LSAs are 1180 originated. Extended LSAs are used in the SPF computation. 1182 B'11' 1183 Full - Only extended LSAs are originated and used in the SPF 1184 computation. 1186 If Full is specified for ExtendedLSASupport, the OSPFv3 router MUST 1187 NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and 1188 Database Description packets with the options field EL-bits set to 1189 MixedModeOriginateOnly or None. Similarly, if MixModeOriginateSPF is 1190 specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form 1191 adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database 1192 Description packets with the options field EL-bits set to None 1193 (B'00'). In this manner, OSPFv3 routers using new encodings can be 1194 completely isolated from those OSPFv3 routers depending on the RFC 1195 5340 encoding and not setting their options field EL-bits since the 1196 default setting indicates no support for extended LSAs. 1198 Finally, a mode supporting existing OSPFv3 routing domains is 1199 provided. This mode, subsequently referred to as "sparse-mode", will 1200 use the TLV-based LSAs solely in support of new functionality 1201 Section 6.2. In this compatibility mode, the EL-bits will be 1202 advertised as B'00' since the backward compatibility with the Legacy 1203 LSAs is not supported or required. 1205 1 2 1206 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 1208 | | | | | | | | | | | | EL|AT|L|AF|*|*|DC|R|N|x|E|V6| 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 1210 The Options field 1212 EL-bits 1213 These bits indicate the level of Extended LSA support. 1214 B'00' - Extended LSAs are not originate nor used in the 1215 SPF calculation (except for new functionalities 1216 for future functions as described in Section 6.2). 1217 B'01' - Both extended and Legacy LSAs are originated. 1218 Non-extended LSAs are used in the SPF computation. 1219 B'10' - Both extended and Legacy LSAs are originated. 1220 Extended LSAs are used in the SPF computation. 1221 B'11' - Only extended LSA are originated and used in the 1222 SPF computation. 1224 Options Field EL-bits 1226 The EL-bits will also be set in the LSA options field in Extended and 1227 Legacy LSAs. While the value of the EL-bits has no functional 1228 significance in the LSA options field, visibility of every OSPFv3 1229 Router's extended LSA support is expected to be very useful for 1230 management and troubleshooting during the migration period. 1232 C.1. Extended LSA Mixed-Mode Backward Compatibility 1234 An implementation MAY support configuration allowing a graceful 1235 transition from the Legacy (non-TLV-based) LSAs to the extended (TLV- 1236 based) LSAs in an OSPFv3 routing domain. In these routing domains, 1237 the OSPFv3 routers configured with a value of MixedModeOriginateOnly 1238 or MixedModeOriginateSPF for ExtendedLSASupport, (Appendix C.2), MUST 1239 originate both the extended and legacy versions of the OSPFv3 LSAs 1240 described herein. For the purposes of Shortest Path First (SPF) 1241 computation, the Legacy LSAs are used for SPF computation when 1242 MixedModeOriginateOnly is configured and the extended LSAs are used 1243 when MixedModeOriginateSPF is specified. The Extended LSAs MAY be 1244 used for functions other than routing computation as long as backward 1245 compatibility is specified in the documents specifying those 1246 functions. 1248 In this manner, OSPFv3 routing domains utilizing the new encodings 1249 can be gradually migrated with a worst-case overhead cost of 1250 approximately doubling the number of LSAs in the routing domain. The 1251 transition within an OSPFv3 routing domain would progress as follows: 1253 1. Configure OSPFv3 Router ExtendedLSASupport to 1254 MixedModeOriginateOnly so that routers originate the extended 1255 LSAs. 1257 2. When all the OSPFv3 Routers have been reconfigured to 1258 MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to 1259 use the extended LSAs by configuring ExtendedLSASupport to 1260 MixedModeOriginateSPF. This can be done on a small subset of 1261 OSPFv3 Routers and the route tables can be verified. 1263 3. When all the OSPFv3 Routers have been reconfigured to 1264 MixedModeOriginateSPF and the routing has been verified, 1265 reconfigure OSPFv3 Routers to purge or simply not refresh the 1266 Legacy LSA by configuring ExtendedLSASupport to Full. 1268 In order to prevent OSPFv3 routing domain routing loops, the 1269 advertised metrics in the Extended LSAs and Legacy LSAs MUST be 1270 identical. 1272 C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility 1274 An implementation MAY also support configuration allowing graceful 1275 transition from the Legacy LSAs to the extended LSAs within a single 1276 area. In these areas, the parameter AreaExtendedLSASupport 1277 (Appendix C.3) may be configured to take precedence over the global 1278 parameter ExtendedLSASupport. However, the AreaExtendedLSASupport 1279 will only apply to link and area scoped LSAs within the area and area 1280 based SPF calculations. The default is for the 1281 AreaExtendedLSASupport to be inherited from the ExtendedLSASupport. 1282 The configuration of ExtendedLSASupport will apply to AS-External 1283 LSAs even when AreaExtendedLSASupport takes precedence. 1285 When preforming a graceful restart [GRACEFUL-RESTART], an OSPFv3 1286 router configured with MixedModeOriginate will use the Legacy LSAs to 1287 determine whether or not the graceful restart has completed 1288 successfully. Similarly, an OSPFv3 router configured with 1289 MixedModeOriginateSPF will use the extended LSAs. In other words, 1290 successful OSPFv3 graceful restart determination will follow the SPF 1291 calculation. 1293 C.2. Global Configuration Parameters 1295 An additional global configurable parameter will be added to the 1296 OSPFv3 protocol. 1298 ExtendedLSASupport 1299 This is an enumeration type indicating the extent to which the 1300 OSPFv3 instance supports the TLV format described herein for 1301 Extended LSAs. The valid values for the enumeration are: 1303 * None - Extended LSAs will not be originated or used in the SPF 1304 calculation. This is the default. When OSPFv3 functions 1305 requiring extended LSA are configured, and the 1306 ExtendedLSASuppport is "None", extended LSAs may be used as 1307 described in Section 6.2. 1309 * MixedModeOriginateOnly - Both extended and Legacy LSAs will be 1310 originated. OSPFv3 adjacencies will be formed with OSPFv3 1311 routers not supporting this specification. The Legacy LSAs are 1312 used for the SPF computation. 1314 * MixedModeOriginateSPF - Both Extended LSAs and Legacy LSAs will 1315 be originated. OSPFv3 adjacencies will be formed with OSPFv3 1316 routers not supporting this specification. The Extended LSAs 1317 are used for the SPF computation. 1319 * Full - Extended LSAs will be originated and adjacencies will 1320 ndot be formed with OSPFv3 routers not supporting this 1321 specification. Only Extended LSAs will be originated. 1323 C.3. Area Configuration Parameters 1325 An additional area configurable parameter will be added to the OSPFv3 1326 protocol. 1328 AreaExtendedLSASupport 1329 This is an enumeration type indicating the extent to which the 1330 OSPFv3 area supports the TLV format described herein for Extended 1331 LSAs. The valid value for the enumeration are: 1333 * InheritGlobal - The AreaExtendedLSASupport will be inherited 1334 from ExtendedLSASupport. This is the default. 1336 * None - Extended LSAs will not be originated or used in the SPF 1337 calculation. This is the default. When OSPFv3 functions 1338 requiring extended LSA are configured, and the 1339 ExtendedLSASuppport is "None", the spare-mode compatability is 1340 in effect Section 6.2. 1342 * MixedModeOriginateOnly - Both extended and legacy link and area 1343 scoped LSAs will be originated. OSPFv3 adjacencies will be 1344 formed with OSPFv3 routers not supporting this specification. 1345 The Legacy LSAs are used for the area SPF computation. 1347 * MixedModeOriginateSPF - Both extended and legacy link and area 1348 scoped LSAs will be originated. OSPFv3 adjacencies will be 1349 formed with OSPFv3 routers not supporting this specification. 1350 The Extended LSAs are used for the area SPF computation. 1352 * Full - Link and area scoped Extended LSAs will be originated 1353 and adjacencies will not be formed with OSPFv3 routers not 1354 supporting this specification. Only Extended LSAs will be 1355 originated. 1357 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1358 configuring None or MixedModeOriginateOnly for AreaExtendedLSASupport 1359 when Full is specified for ExtendedLSASupport is contradictory and 1360 MAY be prohibited by the implementation. 1362 Authors' Addresses 1364 Acee Lindem 1365 Cisco Systems 1366 301 Midenhall Way 1367 Cary, NC 27513 1368 USA 1370 Email: acee@cisco.com 1372 Sina Mirtorabi 1373 Cisco Systems 1374 170 Tasman Drive 1375 San Jose, CA 95134 1376 USA 1378 Email: sina@cisco.com 1380 Abhay Roy 1381 Cisco Systems 1382 170 Tasman Drive 1383 San Jose, CA 95134 1384 USA 1386 Email: akr@cisco.com 1387 Fred Baker 1388 Santa Barbara, California 93117 1389 USA 1391 Email: FredBaker.IETF@gmail.com