idnits 2.17.1 draft-ietf-ospf-ospfv3-lsa-extend-09.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 (November 19, 2015) is 3074 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 (-27) exists of draft-ietf-ospf-segment-routing-extensions-05 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: May 22, 2016 F. Baker 6 Cisco Systems 7 November 19, 2015 9 OSPFv3 LSA Extendibility 10 draft-ietf-ospf-ospfv3-lsa-extend-09.txt 12 Abstract 14 OSPFv3 requires functional extension beyond what can readily be done 15 with the fixed-format Link State Advertisement (LSA) as described in 16 RFC 5340. Without LSA extension, attributes associated with OSPFv3 17 links and advertised IPv6 prefixes must be advertised in separate 18 LSAs and correlated to the fixed-format LSAs. This document extends 19 the LSA format by encoding the existing OSPFv3 LSA information in 20 Type-Length-Value (TLV) tuples and allowing advertisement of 21 additional information with additional TLVs. Backward compatibility 22 mechanisms are also described. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 22, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 60 1.2. OSPFv3 LSA Terminology . . . . . . . . . . . . . . . . . 4 61 1.3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 62 2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 4 63 3. OSPFv3 Extended LSA TLVs . . . . . . . . . . . . . . . . . . 5 64 3.1. Prefix Options Extensions . . . . . . . . . . . . . . . . 6 65 3.1.1. N-bit Prefix Option . . . . . . . . . . . . . . . . . 6 66 3.2. Router-Link TLV . . . . . . . . . . . . . . . . . . . . . 7 67 3.3. Attached-Routers TLV . . . . . . . . . . . . . . . . . . 8 68 3.4. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 10 69 3.5. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 11 70 3.6. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 12 71 3.7. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 13 72 3.8. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 14 73 3.9. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 15 74 3.10. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16 75 3.11. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16 76 3.12. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 17 77 4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . 17 78 4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 17 79 4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . 19 80 4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . 20 81 4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . 21 82 4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . 22 83 4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 23 84 4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 24 85 4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . 26 86 5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . 26 87 6. LSA Extension Backward Compatibility . . . . . . . . . . . . 27 88 6.1. Full Extended LSA Migration . . . . . . . . . . . . . . . 27 89 6.2. Extended LSA Spare-Mode Backward Compatibility . . . . . 27 90 6.3. LSA TLV Processing Backward Compatibility . . . . . . . . 28 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 94 9.1. Normative References . . . . . . . . . . . . . . . . . . 29 95 9.2. Informative References . . . . . . . . . . . . . . . . . 30 96 Appendix A. Appendix A - Global Configuration Parameters . . . . 30 97 Appendix B. Appendix B - Area Configuration Parameters . . . . . 31 98 Appendix C. Appendix C - Deprecated LSA Extension Backward 99 Compatibility . . . . . . . . . . . . . . . . . . . 31 100 C.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . 33 101 C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 34 102 C.2. Global Configuration Parameters . . . . . . . . . . . . . 34 103 C.3. Area Configuration Parameters . . . . . . . . . . . . . . 35 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 106 1. Introduction 108 OSPFv3 requires functional extension beyond what can readily be done 109 with the fixed-format Link State Advertisement (LSA) as described in 110 RFC 5340 [OSPFV3]. Without LSA extension, attributes associated with 111 OSPFv3 links and advertised IPv6 prefixes must be advertised in 112 separate LSAs and correlated to the fixed-format LSAs. This document 113 extends the LSA format by encoding the existing OSPFv3 LSA 114 information in Type-Length-Value (TLV) tuples and allowing 115 advertisement of additional information with additional TLVs. 116 Backward compatibility mechanisms are also described. 118 A similar extension was previously proposed in support of multi- 119 topology routing. Additional requirements for OSPFv3 LSA extension 120 include source/destination routing, route tagging, and others. 122 A final requirement is to limit the changes to OSPFv3 to those 123 necessary for TLV-based LSAs. For the most part, the semantics of 124 existing OSPFv3 LSAs are retained for their TLV-based successor LSAs 125 described herein. Additionally, encoding details, e.g., the 126 representation of IPv6 prefixes as described in section A.4.1 in RFC 127 5340 [OSPFV3], have been retained. This requirement was included to 128 increase the expedience of IETF adoption and deployment. 130 The following aspects of OSPFv3 LSA extension are described: 132 1. Extended LSA Types 134 2. Extended LSA TLVs 136 3. Extended LSA Formats 138 4. Backward Compatibility 140 1.1. Requirements notation 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC-KEYWORDS]. 146 1.2. OSPFv3 LSA Terminology 148 The TLV-based OSPFv3 LSAs described in this document will be referred 149 to as Extended LSAs. The OSPFv3 fixed-format LSAs [OSPFV3] will be 150 referred to as Legacy LSAs. 152 1.3. Acknowledgments 154 OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing 155 in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3]. 157 Thanks for Peter Psenak for significant contributions to the backward 158 compatibility mechanisms. 160 Thanks go to Michael Barnes, Mike Dubrovsky, Anton Smirnov, and Tony 161 Przygienda for review of the draft versions and discussions of 162 backward compatibility. 164 Thanks to Alan Davey for review and comments including the suggestion 165 to separate the extended LSA TLV definitions from the extended LSAs 166 definitions. 168 Thanks to David Lamparter for review and suggestions on backward 169 compatibility. 171 Thanks to Karsten Thomann and Chris Bowers for review and editorial 172 comments. 174 The RFC text was produced using Marshall Rose's xml2rfc tool. 176 2. OSPFv3 Extended LSA Types 178 In order to provide backward compatibility, new LSA codes must be 179 allocated. There are eight fixed-format LSAs defined in RFC 5340 180 [OSPFV3]. For ease of implementation and debugging, the LSA function 181 codes are the same as the fixed-format LSAs only with 32, i.e., 0x20, 182 added. The alternative to this mapping was to allocate a bit in the 183 LS Type indicating the new LSA format. However, this would have used 184 one half the LSA function code space for the migration of the eight 185 original fixed-format LSAs. For backward compatibility, the U-bit 186 will be set in LS Type so that the LSAs will be flooded by OSPFv3 187 routers that do not understand them. 189 LSA function code LS Type Description 190 ---------------------------------------------------- 191 33 0xA021 E-Router-LSA 192 34 0xA022 E-Network-LSA 193 35 0xA023 E-Inter-Area-Prefix-LSA 194 36 0xA024 E-Inter-Area-Router-LSA 195 37 0xC025 E-AS-External-LSA 196 38 N/A Unused (Not to be allocated) 197 39 0xA027 E-Type-7-LSA 198 40 0x8028 E-Link-LSA 199 41 0xA029 E-Intra-Area-Prefix-LSA 201 OSPFv3 Extended LSA Types 203 3. OSPFv3 Extended LSA TLVs 205 The format of the TLVs within the body of the extended LSAs is the 206 same as the format used by the Traffic Engineering Extensions to OSPF 207 [TE]. The variable TLV section consists of one or more nested 208 Type/Length/Value (TLV) tuples. Nested TLVs are also referred to as 209 sub-TLVs. The format of each TLV is: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Type | Length | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Value... | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 TLV Format 221 The Length field defines the length of the value portion in octets 222 (thus a TLV with no value portion would have a length of 0). The TLV 223 is padded to 4-octet alignment; padding is not included in the length 224 field (so a 3-octet value would have a length of 3, but the total 225 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 226 aligned. For example, a 1-byte value would have the length field set 227 to 1, and 3 octets of padding would be added to the end of the value 228 portion of the TLV. 230 This document defines the following top-level TLV types: 232 o 0 - Reserved 234 o 1 - Router-Link TLV 235 o 2 - Attached-Routers TLV 237 o 3 - Inter-Area Prefix TLV 239 o 4 - Inter-Area Router TLV 241 o 5 - External Prefix TLV 243 o 6 - Intra-Area Prefix TLV 245 o 7 - IPv6 Link-Local Address TLV 247 o 8 - IPv4 Link-Local Address TLV 249 Additionally, this document defines the following sub-TLV types: 251 o 0 - Reserved 253 o 1 - IPv6 Forwarding Address sub-TLV 255 o 2 - IPv4 Forwarding Address sub-TLV 257 o 3 - Route Tag sub-TLV 259 In general, TLVs and sub-TLVs MAY occur in any order and the 260 specification should define whether the TLV or sub-TLV is required 261 and the behavior when there are multiple occurances of the TLV or 262 sub-TLVs. 264 3.1. Prefix Options Extensions 266 The prefix options are extended from Appendix A.4.1.1 [OSPFV3]. The 267 applicability of the LA-bit is expanded and it SHOULD be set in 268 Inter-Area-Prefix-TLVs and MAY be set in External-Prefix-TLVs when 269 the advertised host IPv6 address, i.e., PrefixLength = 128, is an 270 interface address. In RFC 5340, the LA-bit is only set in Intra- 271 Area-Prefix-LSAs (Section 4.4.3.9 in [OSPFV3]). This will allow a 272 stable address to be advertised without having to configure a 273 separate loopback address in every OSPFv3 area. 275 3.1.1. N-bit Prefix Option 277 Additionally, the N-bit prefix option is defined. The figure below 278 shows the position of the N-bit in the prefix options (pending IANA 279 allocation). This corresponds to the value 0x20. 281 0 1 2 3 4 5 6 7 282 +--+--+--+--+--+--+--+--+ 283 | | | N|DN| P| x|LA|NU| 284 +--+--+--+--+--+--+--+--+ 286 The Prefix Options field 288 The N-bit is set in PrefixOptions for a host address 289 (PrefixLength=128) that identifies the advertising router. While it 290 is similar to the LA-bit, there are two differences. The advertising 291 router MAY choose NOT to set the N-bit even when the above conditions 292 are met. If the N-bit is set and the PrefixLength is NOT 128, the 293 N-bit MUST be ignored. Additionally, the N-bit is propagated in the 294 PrefixOptions when an OSPFv3 Area Border Router (ABR) originates an 295 Inter-Area-Prefix-LSA for an Intra-Area route which has the N-bit set 296 in the PrefixOptions. Similarly, the N-bit is propagated in the 297 PrefixOptions when an OSPFv3 NSSA ABR originates an Extended-AS- 298 External-LSA corresponding to an NSSA route as described in section 3 299 of RFC 3101 ([NSSA]). The N-bit is to the Inter-Area-Prefix-TLV 300 (Section 3.4), External-Prefix-TLV (Section 3.6), and Intra-Area- 301 Prefix-TLV (Section 3.7) The N-bit is useful for applications such as 302 identifying the prefixes corresponding to Node Segment Identifiers 303 (SIDs) in Segment Routing [SEGMENT-ROUTING]. 305 3.2. Router-Link TLV 307 The Router-Link TLV defines a single router link and the field 308 definitions correspond directly to links in the OSPFv3 Router-LSA, 309 section A.4.3, [OSPFV3]. The Router-Link TLV is only applicable to 310 the E-Router-LSA (Section 4.1). Inclusion in other Extended LSAs 311 MUST be ignored. 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | 1 (Router-Link) | TLV Length | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type | 0 | Metric | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Interface ID | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Neighbor Interface ID | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Neighbor Router ID | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 . . 327 . sub-TLVs . 328 . . 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Router-Link TLV 333 3.3. Attached-Routers TLV 335 The Attached-Routers TLV defines all the routers attached to an 336 OSPFv3 multi-access network. The field definitions correspond 337 directly to content of the OSPFv3 Network-LSA, section A.4.4, 338 [OSPFV3]. The Attached-Routers TLV is only applicable to the E- 339 Network-LSA (Section 4.2). Inclusion in other Extended LSAs MUST be 340 ignored. 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | 2 (Attached-Routers) | TLV Length | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Adjacent Neighbor Router ID | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 . . 350 . Additional Adjacent Neighbors . 351 . . 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Attached-Routers TLV 356 There are two reasons for not having a separate TLV or sub-TLV for 357 each adjacent neighbor. The first is to discourage using the E- 358 Network-LSA for more than its current role of solely advertising the 359 routers attached to a multi-access network. The router's metric as 360 well as the attributes of individual attached routers should be 361 advertised in their respective E-Router-LSAs. The second reason is 362 that there is only a single E-Network-LSA per multi-access link with 363 the Link State ID set to the Designated Router's Interface ID and, 364 consequently, compact encoding has been chosen to decrease the 365 likelihood that the size of the E-Network-LSA will require IPv6 366 fragmentation when advertised in an OSPFv3 Link State Update packet. 368 3.4. Inter-Area-Prefix TLV 370 The Inter-Area-Prefix TLV defines a single OSPFV3 inter-area prefix. 371 The field definitions correspond directly to the content of an OSPFv3 372 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 373 Inter-Area-Prefix-LSA, as defined in section A.4.5, [OSPFV3]. 374 Additionally, the PrefixOptions are extended as described in 375 Section 3.1. The Inter-Area-Prefix TLV is only applicable to the E- 376 Inter-Area-Prefix-LSA (Section 4.3). Inclusion in other Extended 377 LSAs MUST be ignored. 379 0 1 2 3 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | 3 (Inter-Area Prefix) | TLV Length | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | 0 | Metric | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | PrefixLength | PrefixOptions | 0 | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Address Prefix | 389 | ... | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 . . 392 . sub-TLVs . 393 . . 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Inter-Area Prefix TLV 398 3.5. Inter-Area-Router TLV 400 The Inter-Area-Router TLV defines a single OSPFv3 Autonomous System 401 Boundary Router (ASBR) reachable in another area. The field 402 definitions correspond directly to the content of an OSPFv3 Inter- 403 Area-Router-LSA, as defined in section A.4.6, [OSPFV3]. The Inter- 404 Area-Router TLV is only applicable to the E-Inter-Area-Router-LSA 405 (Section 4.4). Inclusion in other Extended LSAs MUST be ignored. 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | 4 (Inter-Area Router) | TLV Length | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | 0 | Options | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | 0 | Metric | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Destination Router ID | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 . . 419 . sub-TLVs . 420 . . 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Inter-Area Router TLV 425 3.6. External-Prefix TLV 427 The External-Prefix TLV defines a single OSPFv3 external prefix. The 428 field definitions correspond directly to the content of an OSPFv3 429 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 AS- 430 External-LSA, as defined in section A.4.7, [OSPFV3]. The External- 431 Prefix TLV is only applicable to the E-AS-External-LSA (Section 4.5) 432 and the E-NSSA-LSA (Section 4.6). Additionally, the PrefixOptions 433 are extended as described in Section 3.1. Inclusion in other 434 Extended LSAs MUST be ignored. 436 0 1 2 3 437 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | 5 (External Prefix) | TLV Length | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | |E| | | Metric | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | PrefixLength | PrefixOptions | 0 | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Address Prefix | 446 | ... | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 . . 449 . sub-TLVs . 450 . . 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 External Prefix TLV 455 In the External-Prefix TLV, the optional IPv6/IPv4 Forwarding Address 456 and External Route Tag are now sub-TLVs. Given the Referenced LS 457 type and Referenced Link State ID from the AS-External-LSA have never 458 been used or even specified, they have been omitted from the External 459 Prefix TLV. If there were ever a requirement for a referenced LSA, 460 it could be satisfied with a sub-TLV. 462 The following sub-TLVs are defined for optional inclusion in the 463 External Prefix TLV: 465 o 1 - IPv6 Forwarding Address sub-TLV (Section 3.10) 467 o 2 - IPv4 Forwarding Address sub-TLV (Section 3.11) 469 o 3 - Route Tag sub-TLV (Section 3.12) 471 3.7. Intra-Area-Prefix TLV 473 The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix. 474 The field definitions correspond directly to the content of an OSPFv3 475 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 Link- 476 LSA, as defined in section A.4.9, [OSPFV3]. The Intra-Area-Prefix 477 TLV is only applicable to the E-Link-LSA (Section 4.7) and the 478 Additionally, the PrefixOptions are extended as described in 479 Section 3.1. E-Intra-Area-Prefix-LSA (Section 4.8). Inclusion in 480 other Extended LSAs MUST be ignored. 482 0 1 2 3 483 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | 6 (Intra-Area Prefix) | TLV Length | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | 0 | Metric | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | PrefixLength | PrefixOptions | 0 | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Address Prefix | 492 | ... | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 . . 495 . sub-TLVs . 496 . . 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 Intra-Area Prefix TLV 501 3.8. IPv6 Link-Local Address TLV 503 The IPv6 Link-Local Address TLV is to be used with IPv6 address 504 families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV 505 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 506 other Extended LSAs MUST be ignored. 508 0 1 2 3 509 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | 7 (IPv6 Local-Local Address) | TLV Length | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | | 514 +- -+ 515 | | 516 +- IPv6 Link-Local Interface Address -+ 517 | | 518 +- -+ 519 | | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 . . 522 . sub-TLVs . 523 . . 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 IPv6 Link-Local Address TLV 528 3.9. IPv4 Link-Local Address TLV 530 The IPv4 Link-Local Address TLV is to be used with IPv4 address 531 families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV 532 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 533 other Extended LSAs MUST be ignored. 535 0 1 2 3 536 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | 8 (IPv4 Local-Local Address) | TLV Length | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | IPv4 Link-Local Interface Address | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 . . 543 . sub-TLVs . 544 . . 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 IPv4 Link-Local Address TLV 549 3.10. IPv6-Forwarding-Address Sub-TLV 551 The IPv6 Forwarding Address TLV has identical semantics to the 552 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv6 553 Forwarding Address TLV is applicable to the External-Prefix TLV 554 (Section 3.6). Specification as a sub-TLV of other TLVs is not 555 defined herein. The sub-TLV is optional and the first specified 556 instance is used as the Forwarding Address as defined in [OSPFV3]. 557 Instances subsequent to the first MUST be ignored. 559 The IPv6 Forwarding Address TLV is to be used with IPv6 address 560 families as defined in [OSPFV3-AF] It MUST be ignored for other 561 address families. 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | 1 - Forwarding Address | sub-TLV Length | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | | 569 +- -+ 570 | | 571 +- Forwarding Address -+ 572 | | 573 +- -+ 574 | | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 Forwarding Address Tag TLV 579 3.11. IPv4-Forwarding-Address Sub-TLV 581 The IPv4 Forwarding Address TLV has identical semantics to the 582 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv4 583 Forwarding Address TLV is The IPv4 Forwarding Address TLV is 584 applicable to the External-Prefix TLV (Section 3.6). Specification 585 as a sub-TLV of other TLVs is not defined herein. The sub-TLV is 586 optional and the first specified instance is used as the Forwarding 587 Address as defined in [OSPFV3]. Instances subsequent to the first 588 MUST be ignored. 590 The IPv4 Forwarding Address TLV is to be used with IPv3 address 591 families as defined in [OSPFV3-AF] It MUST be ignored for other 592 address families. 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | 2 - Forwarding Address | sub-TLV Length | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Forwarding Address | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 Forwarding Address Tag TLV 604 3.12. Route-Tag Sub-TLV 606 The optional Route Tag sub-TLV has identical semantics to the 607 optional External Route Tag in section A.4.7 of [OSPFV3]. The Route 608 Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.6). 609 Specification as a sub-TLV of other TLVs is not defined herein. The 610 sub-TLV is optional and the first specified instance is used as the 611 Route Tag as defined in [OSPFV3]. Instances subsequent to the first 612 MUST be ignored. 614 0 1 2 3 615 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 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | 3 - Route Tag | sub-TLV Length | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Route Tag | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 Route Tag Sub-TLV 624 4. OSPFv3 Extended LSAs 626 This section specifies the OSPFv3 Extended LSA formats and encoding. 627 The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3 628 LSAs specifed in [OSPFV3]. 630 4.1. OSPFv3 E-Router-LSA 632 The E-Router-LSA has an LS Type of 0xA021 and has the same base 633 information content as the Router-LSA defined in section A.4.3 of 634 [OSPFV3]. However, unlike the existing Router-LSA, it is fully 635 extendable and represented as TLVs. 637 0 1 2 3 638 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 639 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | LS Age |1|0|1| 0x21 | 641 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Link State ID | 643 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Advertising Router | 645 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | LS Sequence Number | 647 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | LS Checksum | Length | 649 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | 0 |Nt|x|V|E|B| Options | 651 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 . . 653 . TLVs . 654 . . 655 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 Extended Router-LSA 659 All LSA Header fields are the same as defined for the Router-LSA. 660 Initially, only the top-level Router-Link TLV Section 3.2 is 661 applicable and an E-Router-LSA may include multiple Router-Link TLVs. 662 Like the existing Router-LSA, the LSA length is used to determine the 663 end of the LSA including TLVs. 665 4.2. OSPFv3 E-Network-LSA 667 The E-Network-LSA has an LS Type of 0xA022 and has the same base 668 information content as the Network-LSA defined in section A.4.4 of 669 [OSPFV3]. However, unlike the existing Network-LSA, it is fully 670 extendable and represented as TLVs. 672 0 1 2 3 673 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | LS Age |1|0|1| 0x22 | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Link State ID | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Advertising Router | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | LS Sequence Number | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | LS Checksum | Length | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | 0 | Options | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 . . 688 . TLVs . 689 . . 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 E-Network-LSA 694 All LSA Header fields are the same as defined for the Network-LSA. 695 Like the existing Network-LSA, the LSA length is used to determine 696 the end of the LSA including TLVs. Initially, only the top-level 697 Attached-Routers TLV Section 3.3 is applicable. If the Attached- 698 Router TLV is not included in the E-Network-LSA, it is treated as 699 malformed as described in Section 5. Instances of the Attached- 700 Router TLV subsequent to the first MUST be ignored. 702 4.3. OSPFv3 E-Inter-Area-Prefix-LSA 704 The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same 705 base information content as the Inter-Area-Prefix-LSA defined in 706 section A.4.5 of [OSPFV3]. However, unlike the existing Inter-Area- 707 Prefix-LSA, it is fully extendable and represented as TLVs. 709 0 1 2 3 710 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 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | LS Age |1|0|1| 0x23 | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Link State ID | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Advertising Router | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | LS Sequence Number | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | LS Checksum | Length | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 . . 723 . TLVs . 724 . . 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 E-Inter-Area-Prefix-LSA 729 All LSA Header fields are the same as defined for the Inter-Area- 730 Prefix-LSA. In order to retain compatibility and semantics with the 731 current OSPFv3 specification, each Inter-Area-Prefix LSA MUST contain 732 a single Inter-Area Prefix TLV. This will facilitate migration and 733 avoid changes to functions such as incremental SPF computation. 735 Like the existing Inter-Area-Prefix-LSA, the LSA length is used to 736 determine the end of the LSA including TLV. Initially, only the top- 737 level Inter-Area-Prefix TLV (Section 3.4) is applicable. If the 738 Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA, 739 it is treated as malformed as described in Section 5. Instances of 740 the Inter-Area-Prefix TLV subsequent to the first MUST be ignored. 742 4.4. OSPFv3 E-Inter-Area-Router-LSA 744 The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same 745 base information content as the Inter-Area-Router-LSAE defined in 746 section A.4.6 of [OSPFV3]. However, unlike the Inter-Area-Router- 747 LSA, it is fully extendable and represented as TLVs. 749 0 1 2 3 750 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 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | LS Age |1|0|1| 0x24 | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Link State ID | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Advertising Router | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | LS Sequence Number | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | LS Checksum | Length | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 . . 763 . TLVs . 764 . . 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 E-Inter-Area-Router-LSA 769 All LSA Header fields are the same as defined for the Inter-Area- 770 Router-LSA. In order to retain compatibility and semantics with the 771 current OSPFv3 specification, each Inter-Area-Router LSA MUST contain 772 a single Inter-Area Router TLV. This will facilitate migration and 773 avoid changes to functions such as incremental SPF computation. 775 Like the existing Inter-Area-Router-LSA, the LSA length is used to 776 determine the end of the LSA including TLV. Initially, only the top- 777 level Inter-Area-Router TLV (Section 3.5) is applicable. If the 778 Inter-Area-Router TLV is not included in the E-Inter-Area-Router-LSA, 779 it is treated as malformed as described in Section 5. Instances of 780 the Inter-Area-Router TLV subsequent to the first MUST be ignored. 782 4.5. OSPFv3 E-AS-External-LSA 784 The E-AS-External-LSA has an LS Type of 0xC025 and has the same base 785 information content as the AS-External-LSA defined in section A.4.7 786 of [OSPFV3]. However, unlike the existing AS-External-LSA, it is 787 fully extendable and represented as TLVs. 789 0 1 2 3 790 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 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | LS Age |1|1|0| 0x25 | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Link State ID | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Advertising Router | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | LS Sequence Number | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | LS Checksum | Length | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 . . 803 . TLVs . 804 . . 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 E-AS-External-LSA 809 All LSA Header fields are the same as defined for the AS-External- 810 LSA. In order to retain compatibility and semantics with the current 811 OSPFv3 specification, each LSA MUST contain a single External Prefix 812 TLV. This will facilitate migration and avoid changes to OSPFv3 813 processes such as incremental SPF computation. 815 Like the existing AS-External-LSA, the LSA length is used to 816 determine the end of the LSA including sub-TLVs. Initially, only the 817 top-level External-Prefix TLV (Section 3.6) is applicable. If the 818 External-Prefix TLV is not included in the E-External-AS-LSA, it is 819 treated as malformed as described in Section 5. Instances of the 820 External-Prefix TLV subsequent to the first MUST be ignored. 822 4.6. OSPFv3 E-NSSA-LSA 824 The E-NSSA-LSA will have the same format and TLVs as the Extended AS- 825 External-LSA Section 4.5. This is the same relationship as exists 826 between the NSSA-LSA defined in section A.4.8 of [OSPFV3], and the 827 AS-External-LSA. The NSSA-LSA will have type 0xA027 which implies 828 area flooding scope. Future requirements may dictate that supported 829 TLVs differ between the E-AS-External-LSA and the E-NSSA-LSA. 830 However, future requirements are beyond the scope of this document. 832 4.7. OSPFv3 E-Link-LSA 834 The E-Link-LSA has an LS Type of 0x8028 and will have the same base 835 information content as the Link-LSA defined in section A.4.9 of 836 [OSPFV3]. However, unlike the existing Link-LSA, it is extendable 837 and represented as TLVs. 839 0 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | LS Age |1|0|0| 0x28 | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Link State ID | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Advertising Router | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | LS Sequence Number | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | LS Checksum | Length | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Rtr Priority | Options | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 . . 855 . TLVs . 856 . . 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 E-Link-LSA 861 All LSA Header fields are the same as defined for the Link-LSA. 863 Only the Intra-Area-Prefix TLV (Section 3.7), IPv6 Link-Local Address 864 TLV (Section 3.8), and IPv4 Link-Local Address TLV (Section 3.9) are 865 applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA 866 affords advertisement of multiple intra-area prefixes. Hence, 867 multiple Intra-Area Prefix TLVs (Section 3.7) may be specified and 868 the LSA length defines the end of the LSA including all TLVs. 870 A single instance of the IPv6 Link-Local Address TLV (Section 3.8) 871 SHOULD be included in the E-Link-LSA. Instances following the first 872 MUST be ignored. For IPv4 address families as defined in 873 [OSPFV3-AF], this TLV MUST be ignored. 875 Similarly, only a single instance of the IPv4 Link-Local Address TLV 876 (Section 3.9) SHOULD be included in the E-Link-LSA. Instances 877 following the first MUST be ignored. For OSPFv3 IPv6 address 878 families as defined in [OSPFV3-AF], this TLV MUST be ignored. 880 If the IPv4/IPv6 Link-Local Address TLV corresponding to the OSPFv3 881 Address Family is not included in the E-Link-LSA, it is treated as 882 malformed as described in Section 5. 884 Future specifications may support advertisement of routing and 885 topology information for multiple address families. However, this is 886 beyond the scope of this document. 888 4.8. OSPFv3 E-Intra-Area-Prefix-LSA 890 The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same 891 base information content as the Intra-Area-Prefix-LSA defined in 892 section A.4.10 of [OSPFV3]. However, unlike the Intra-Area-Prefix- 893 LSA, it is fully extendable and represented as TLVs. 895 0 1 2 3 896 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 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | LS Age |1|0|1| 0x29 | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Link State ID | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Advertising Router | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | LS Sequence Number | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | LS Checksum | Length | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | 0 | Referenced LS Type | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Referenced Link State ID | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Referenced Advertising Router | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 . . 915 . TLVs . 916 . . 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 E-Intra-Area-Prefix-LSA 921 All LSA Header fields are the same as defined for the Intra-Area- 922 Prefix-LSA. 924 Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords 925 advertisement of multiple intra-area prefixes. Hence, multiple 926 Intra-Area Prefix TLVs may be specified and the LSA length defines 927 the end of the LSA including all TLVs. 929 5. Malformed OSPFv3 Extended LSA Handling 931 Extended LSAs that have inconsistent length or other encoding errors, 932 as described herein, MUST NOT be installed in the Link State 933 Database, acknowledged, or flooded. Reception of malformed LSAs 934 SHOULD be counted and/or logged for examination by the administrator 935 of the OSPFv3 Routing Domain. 937 6. LSA Extension Backward Compatibility 939 In the context of this document, backward compatibility is solely 940 related to the capability of an OSPFv3 router to receive, process, 941 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 942 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 943 extensions utilizing the TLV-based LSAs is out of scope and must be 944 covered in the documents describing those extensions. Both full and, 945 if applicable, partial deployment SHOULD be specified for future TLV- 946 based OSPFv3 LSA extensions. 948 6.1. Full Extended LSA Migration 950 If ExtendedLSASupport is enabled Appendix A, OSPFv3 Extended LSAs 951 will be originated and used for the SPF computation. Individual OSPF 952 Areas can be migrated separately with the Legacy AS-External LSAs 953 being originated and used for the SPF computation. This is 954 accomplished by enabled AreaExtendedLSASupport Appendix B. 956 An OSPFv3 routing domain or area may be non-disruptively migrated 957 using separate OSPFv3 instances for the extended LSAs. Initially, 958 the OSPFv3 instances with ExtendedLSASupport will have a lower 959 preference, i.e., higher administrative distance, than the OSPFv3 960 instances originating and using the Legacy LSAs. Once the routing 961 domain or area is fully migrated and the OSPFv3 Routing Information 962 Bases (RIB) have been verified, the OSPFv3 instances using the 963 extended LSAs can be given preference. When this has been completed 964 and the routing within the OSPF routing domain or area has been 965 verified, the original OSPFv3 instance using Legacy LSAs can be 966 removed. 968 6.2. Extended LSA Spare-Mode Backward Compatibility 970 In this mode, OSPFv3 will use the Legacy LSAs for the SPF computation 971 and will only originate extended LSAs when LSA origination is 972 required in support of addtional functionality. Furthermore, the 973 extended LSAs will only include those TLVs which require further 974 specification for that new functionality. Hence, this mode of 975 compatibility is know as "sparse-mode". The advantage of sparse-mode 976 is that functionality utilizing the OSPFv3 extended LSAs can be added 977 to an existing OSFPv3 routing domain without the requirement for 978 migration. In essence, this compatibility mode is very much like the 979 approach taken for OSPFv2 [OSPF-PREFIX-LINK]. As with all the 980 compatibility modes, backward compatibility for the functions 981 utilizing the extended LSAs must be described in the IETF documents 982 describing those functions. 984 6.3. LSA TLV Processing Backward Compatibility 986 This section defines the general rules for processing LSA TLVs. To 987 ensure compatibility of future TLV-based LSA extensions, all 988 implementations MUST adhere to these rules: 990 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or 991 processing Extended-LSAs. 993 2. Whether or not partial deployment of a given TLV is supported 994 MUST be specified. 996 3. If partial deployment is not supported, mechanisms to ensure the 997 corresponding feature are not deployed MUST be specified in the 998 document defining the new TLV or sub-TLV. 1000 4. If partial deployment is supported, backward compatibility and 1001 partial deployment MUST be specified in the document defining the 1002 new TLV or sub-TLV. 1004 7. Security Considerations 1006 In general, extendible OSPFv3 LSAs are subject to the same security 1007 concerns as those described in RFC 5340 [OSPFV3]. Additionally, 1008 implementations must assure that malformed TLV and sub-TLV 1009 permutations do not result in errors that cause hard OSPFv3 failures. 1011 If there were ever a requirement to digitally sign OSPFv3 LSAs as 1012 described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the 1013 mechanisms described herein would greatly simplify the extension. 1015 8. IANA Considerations 1017 This specification defines nine OSPFv3 Extended LSA types as 1018 described in Section 2. 1020 This specification also creates two registries OSPFv3 Extended-LSAs 1021 TLVs and sub-TLVs. The TLV and sub-TLV code-points in these 1022 registries are common to all Extended-LSAs and their respective 1023 definitions must define where they are applicable. 1025 The OSPFv3 Extended-LSA TLV registry will define top-level TLVs for 1026 Extended-LSAs and should be placed in the existing OSPFv3 IANA 1027 registry. New values can be allocated via IETF Consensus or IESG 1028 Approval. 1030 Nine values are allocated by this specification: 1032 o 0 - Reserved 1034 o 1 - Router-Link TLV 1036 o 2 - Attached-Routers TLV 1038 o 3 - Inter-Area Prefix TLV 1040 o 4 - Inter-Area Router TLV 1042 o 5 - External Prefix TLV 1044 o 6 - Intra-Area Prefix TLV 1046 o 7 - IPv6 Link-Local Address TLV 1048 o 8 - IPv4 Link-Local Address TLV 1050 The OSPFv3 Extended-LSA sub-TLV registry will define sub-TLVs at any 1051 level of nesting for Extended-LSAs and should be placed in the 1052 existing OSPFv3 IANA registry. New values can be allocated via IETF 1053 Review. 1055 Three values are allocated by this specification: 1057 o 0 - Reserved 1059 o 1 - Forwarding Address 1061 o 2 - Route Tag 1063 The OSPFv3 Prefix Options registry will define a new code point for 1064 the N-bit. The value 0x20 is suggested. 1066 9. References 1068 9.1. Normative References 1070 [GRACEFUL-RESTART] 1071 Lindem, A. and P. Pillay-Esnault, "OSPFv3 Graceful 1072 Restart", RFC 5187, June 2008. 1074 [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1075 RFC 3101, January 2003. 1077 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1078 for IPv6", RFC 5340, July 2008. 1080 [OSPFV3-AF] 1081 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 1082 Aggarwal, "Support of Address Families in OSPFv3", RFC 1083 5838, April 2010. 1085 [RFC-KEYWORDS] 1086 Bradner, S., "Key words for use in RFCs to Indicate 1087 Requirement Levels", RFC 2119, March 1997. 1089 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 1090 Extensions to OSPF", RFC 3630, September 2003. 1092 9.2. Informative References 1094 [MT-OSPFV3] 1095 Mirtorabi, S. and A. Roy, "Multi-topology routing in 1096 OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-03.txt 1097 (work in progress), January 2008. 1099 [OSPF-DIGITAL-SIGNATURE] 1100 Murphy, S., Badger, M., and B. Wellington, "OSPF with 1101 Digital Signatures", RFC 2154, June 1997. 1103 [OSPF-PREFIX-LINK] 1104 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1105 Tantsura, J., and A. Lindem, "OSPF Prefix/Link 1106 Attributes", draft-ietf-ospf-prefix-link-attr-13.txt (work 1107 in progress), August 2015. 1109 [SEGMENT-ROUTING] 1110 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1111 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1112 Extensions for Segment Routing", draft-ietf-ospf-segment- 1113 routing-extensions-05.txt (work in progress), February 1114 2015. 1116 Appendix A. Appendix A - Global Configuration Parameters 1118 The global configurable parameter ExtendedLSASupport will be added to 1119 the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 1120 Router will originate OSPFv3 Extended LSAs and use the LSAs for the 1121 SPF computation. If ExtendedLSASupport is not enabled, a subset of 1122 OSPFv3 Extended LSAs may still be originated and used for other 1123 functions as described in Section 6.2. 1125 Appendix B. Appendix B - Area Configuration Parameters 1127 The area configurable parameter AreaExtendedLSASupport will be added 1128 to the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 1129 Router will originate link and area OSPFv3 Extended LSAs and use the 1130 LSAs for the SPF computation. Legacy AS-Scoped LSAs will still be 1131 originated and used for the AS External LSA computation. If 1132 AreaExtendedLSASupport is not enabled a subset of OSPFv3 link and 1133 area Extended LSAs may still be originated and used for other 1134 functions as described in Section 6.2. 1136 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1137 disabling AreaExtendedLSASupport when ExtendedLSASupport is enabled 1138 is contradictory and MAY be prohibited by the implementation. 1140 Appendix C. Appendix C - Deprecated LSA Extension Backward 1141 Compatibility 1143 In the context of this document, backward compatibility is solely 1144 related to the capability of an OSPFv3 router to receive, process, 1145 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 1146 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 1147 extensions utilizing the TLV-based LSAs is out of scope and must be 1148 covered in the documents describing those extensions. Both full and, 1149 if applicable, partial deployment SHOULD be specified for future TLV- 1150 based OSPFv3 LSA extensions. 1152 Three distinct backward compatibility modes are supported dependent 1153 on the OSPFv3 routing domain migration requirements. For simplicity 1154 and to avoid the scaling impact of maintaining both TLV and non-TLV 1155 based versions of the same LSA within a routing domain, the basic 1156 backward compatibility mode will not allow mixing of LSA formats. 1157 Different LSA formats could still be supported with multiple OSPFv3 1158 instances and separate OSPFv3 routing domains. Additionally, a more 1159 flexible mode is provided in Appendix C.1, where both formats of LSA 1160 coexist. In order to facilitate backward compatibility, the OSPFv3 1161 options field (as described in Appendix A.2 of RFC 5340 [OSPFV3]), 1162 will contain two additional options bits. The EL-bits will be used 1163 to indicate that the OSPFv3 router's level of Extended LSA support. 1164 An OSPFv3 router configured to support extended LSAs MUST set its 1165 options field EL-bits in OSPFv3 Hello and Database Description 1166 packets as follows: 1168 B'00' 1169 None - Extended LSAs are not originated nor used in the SPF 1170 calculation (except for future functionalities as described in 1171 Section 6.2) . 1173 B'01' 1174 MixedModeOriginateOnly - Both Extended and Legacy LSAs are 1175 originated. Legacy LSAs are used in the SPF computation. 1177 B'10' 1178 MixedModeOriginateSPF - Both extended and Legacy LSAs are 1179 originated. Extended LSAs are used in the SPF computation. 1181 B'11' 1182 Full - Only extended LSAs are originated and used in the SPF 1183 computation. 1185 If Full is specified for ExtendedLSASupport, the OSPFv3 router MUST 1186 NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and 1187 Database Description packets with the options field EL-bits set to 1188 MixedModeOriginateOnly or None. Similarly, if MixModeOriginateSPF is 1189 specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form 1190 adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database 1191 Description packets with the options field EL-bits set to None 1192 (B'00'). In this manner, OSPFv3 routers using new encodings can be 1193 completely isolated from those OSPFv3 routers depending on the RFC 1194 5340 encoding and not setting their options field EL-bits since the 1195 default setting indicates no support for extended LSAs. 1197 Finally, a mode supporting existing OSPFv3 routing domains is 1198 provided. This mode, subsequently referred to as "sparse-mode", will 1199 use the TLV-based LSAs solely in support of new functionality 1200 Section 6.2. In this compatibility mode, the EL-bits will be 1201 advertised as B'00' since the backward compatibility with the Legacy 1202 LSAs is not supported or required. 1204 1 2 1205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 1207 | | | | | | | | | | | | EL|AT|L|AF|*|*|DC|R|N|x|E|V6| 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 1209 The Options field 1211 EL-bits 1212 These bits indicate the level of Extended LSA support. 1213 B'00' - Extended LSAs are not originate nor used in the 1214 SPF calculation (except for new functionalities 1215 for future functions as described in Section 6.2). 1216 B'01' - Both extended and Legacy LSAs are originated. 1217 Non-extended LSAs are used in the SPF computation. 1218 B'10' - Both extended and Legacy LSAs are originated. 1219 Extended LSAs are used in the SPF computation. 1220 B'11' - Only extended LSA are originated and used in the 1221 SPF computation. 1223 Options Field EL-bits 1225 The EL-bits will also be set in the LSA options field in Extended and 1226 Legacy LSAs. While the value of the EL-bits has no functional 1227 significance in the LSA options field, visibility of every OSPFv3 1228 Router's extended LSA support is expected to be very useful for 1229 management and troubleshooting during the migration period. 1231 C.1. Extended LSA Mixed-Mode Backward Compatibility 1233 An implementation MAY support configuration allowing a graceful 1234 transition from the Legacy (non-TLV-based) LSAs to the extended (TLV- 1235 based) LSAs in an OSPFv3 routing domain. In these routing domains, 1236 the OSPFv3 routers configured with a value of MixedModeOriginateOnly 1237 or MixedModeOriginateSPF for ExtendedLSASupport, (Appendix C.2), MUST 1238 originate both the extended and legacy versions of the OSPFv3 LSAs 1239 described herein. For the purposes of Shortest Path First (SPF) 1240 computation, the Legacy LSAs are used for SPF computation when 1241 MixedModeOriginateOnly is configured and the extended LSAs are used 1242 when MixedModeOriginateSPF is specified. The Extended LSAs MAY be 1243 used for functions other than routing computation as long as backward 1244 compatibility is specified in the documents specifying those 1245 functions. 1247 In this manner, OSPFv3 routing domains utilizing the new encodings 1248 can be gradually migrated with a worst-case overhead cost of 1249 approximately doubling the number of LSAs in the routing domain. The 1250 transition within an OSPFv3 routing domain would progress as follows: 1252 1. Configure OSPFv3 Router ExtendedLSASupport to 1253 MixedModeOriginateOnly so that routers originate the extended 1254 LSAs. 1256 2. When all the OSPFv3 Routers have been reconfigured to 1257 MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to 1258 use the extended LSAs by configuring ExtendedLSASupport to 1259 MixedModeOriginateSPF. This can be done on a small subset of 1260 OSPFv3 Routers and the route tables can be verified. 1262 3. When all the OSPFv3 Routers have been reconfigured to 1263 MixedModeOriginateSPF and the routing has been verified, 1264 reconfigure OSPFv3 Routers to purge or simply not refresh the 1265 Legacy LSA by configuring ExtendedLSASupport to Full. 1267 In order to prevent OSPFv3 routing domain routing loops, the 1268 advertised metrics in the Extended LSAs and Legacy LSAs MUST be 1269 identical. 1271 C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility 1273 An implementation MAY also support configuration allowing graceful 1274 transition from the Legacy LSAs to the extended LSAs within a single 1275 area. In these areas, the parameter AreaExtendedLSASupport 1276 (Appendix C.3) may be configured to take precedence over the global 1277 parameter ExtendedLSASupport. However, the AreaExtendedLSASupport 1278 will only apply to link and area scoped LSAs within the area and area 1279 based SPF calculations. The default is for the 1280 AreaExtendedLSASupport to be inherited from the ExtendedLSASupport. 1281 The configuration of ExtendedLSASupport will apply to AS-External 1282 LSAs even when AreaExtendedLSASupport takes precedence. 1284 When preforming a graceful restart [GRACEFUL-RESTART], an OSPFv3 1285 router configured with MixedModeOriginate will use the Legacy LSAs to 1286 determine whether or not the graceful restart has completed 1287 successfully. Similarly, an OSPFv3 router configured with 1288 MixedModeOriginateSPF will use the extended LSAs. In other words, 1289 successful OSPFv3 graceful restart determination will follow the SPF 1290 calculation. 1292 C.2. Global Configuration Parameters 1294 An additional global configurable parameter will be added to the 1295 OSPFv3 protocol. 1297 ExtendedLSASupport 1298 This is an enumeration type indicating the extent to which the 1299 OSPFv3 instance supports the TLV format described herein for 1300 Extended LSAs. The valid values for the enumeration are: 1302 * None - Extended LSAs will not be originated or used in the SPF 1303 calculation. This is the default. When OSPFv3 functions 1304 requiring extended LSA are configured, and the 1305 ExtendedLSASuppport is "None", extended LSAs may be used as 1306 described in Section 6.2. 1308 * MixedModeOriginateOnly - Both extended and Legacy LSAs will be 1309 originated. OSPFv3 adjacencies will be formed with OSPFv3 1310 routers not supporting this specification. The Legacy LSAs are 1311 used for the SPF computation. 1313 * MixedModeOriginateSPF - Both Extended LSAs and Legacy LSAs will 1314 be originated. OSPFv3 adjacencies will be formed with OSPFv3 1315 routers not supporting this specification. The Extended LSAs 1316 are used for the SPF computation. 1318 * Full - Extended LSAs will be originated and adjacencies will 1319 ndot be formed with OSPFv3 routers not supporting this 1320 specification. Only Extended LSAs will be originated. 1322 C.3. Area Configuration Parameters 1324 An additional area configurable parameter will be added to the OSPFv3 1325 protocol. 1327 AreaExtendedLSASupport 1328 This is an enumeration type indicating the extent to which the 1329 OSPFv3 area supports the TLV format described herein for Extended 1330 LSAs. The valid value for the enumeration are: 1332 * InheritGlobal - The AreaExtendedLSASupport will be inherited 1333 from ExtendedLSASupport. This is the default. 1335 * None - Extended LSAs will not be originated or used in the SPF 1336 calculation. This is the default. When OSPFv3 functions 1337 requiring extended LSA are configured, and the 1338 ExtendedLSASuppport is "None", the spare-mode compatability is 1339 in effect Section 6.2. 1341 * MixedModeOriginateOnly - Both extended and legacy link and area 1342 scoped LSAs will be originated. OSPFv3 adjacencies will be 1343 formed with OSPFv3 routers not supporting this specification. 1344 The Legacy LSAs are used for the area SPF computation. 1346 * MixedModeOriginateSPF - Both extended and legacy link and area 1347 scoped LSAs will be originated. OSPFv3 adjacencies will be 1348 formed with OSPFv3 routers not supporting this specification. 1349 The Extended LSAs are used for the area SPF computation. 1351 * Full - Link and area scoped Extended LSAs will be originated 1352 and adjacencies will not be formed with OSPFv3 routers not 1353 supporting this specification. Only Extended LSAs will be 1354 originated. 1356 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1357 configuring None or MixedModeOriginateOnly for AreaExtendedLSASupport 1358 when Full is specified for ExtendedLSASupport is contradictory and 1359 MAY be prohibited by the implementation. 1361 Authors' Addresses 1363 Acee Lindem 1364 Cisco Systems 1365 301 Midenhall Way 1366 Cary, NC 27513 1367 USA 1369 Email: acee@cisco.com 1371 Sina Mirtorabi 1372 Cisco Systems 1373 170 Tasman Drive 1374 San Jose, CA 95134 1375 USA 1377 Email: sina@cisco.com 1379 Abhay Roy 1380 Cisco Systems 1381 170 Tasman Drive 1382 San Jose, CA 95134 1383 USA 1385 Email: akr@cisco.com 1386 Fred Baker 1387 Cisco Systems 1388 Santa Barbara, CA 93117 1389 USA 1391 Email: fred@cisco.com