idnits 2.17.00 (12 Aug 2021) /tmp/idnits62989/draft-ietf-ospf-ospfv3-lsa-extend-06.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 (February 16, 2015) is 2650 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-ospf-segment-routing-extensions has been published as RFC 8665 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: August 20, 2015 F. Baker 6 Cisco Systems 7 February 16, 2015 9 OSPFv3 LSA Extendibility 10 draft-ietf-ospf-ospfv3-lsa-extend-06.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 August 20, 2015. 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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 3 61 2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 4 62 3. OSPFv3 Extended LSA TLVs . . . . . . . . . . . . . . . . . . 5 63 3.1. Prefix Options Extensions . . . . . . . . . . . . . . . . 6 64 3.1.1. N-bit Prefix Option . . . . . . . . . . . . . . . . . 6 65 3.2. Router-Link TLV . . . . . . . . . . . . . . . . . . . . . 7 66 3.3. Attached-Routers TLV . . . . . . . . . . . . . . . . . . 7 67 3.4. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 9 68 3.5. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 10 69 3.6. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 11 70 3.7. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 12 71 3.8. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 13 72 3.9. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 14 73 3.10. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 15 74 3.11. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 15 75 3.12. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 16 76 4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . 16 77 4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 16 78 4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . 18 79 4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . 19 80 4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . 20 81 4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . 21 82 4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 22 83 4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 23 84 4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . 25 85 5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . 25 86 6. LSA Extension Backward Compatibility . . . . . . . . . . . . 26 87 6.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . 27 88 6.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 28 89 6.2. LSA TLV Processing Backward Compatibility . . . . . . . . 29 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 30 94 9.2. Informative References . . . . . . . . . . . . . . . . . 31 95 Appendix A. Global Configuration Parameters . . . . . . . . . . 31 96 Appendix B. Area Configuration Parameters . . . . . . . . . . . 32 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 99 1. Introduction 101 OSPFv3 requires functional extension beyond what can readily be done 102 with the fixed-format Link State Advertisement (LSA) as described in 103 RFC 5340 [OSPFV3]. Without LSA extension, attributes associated with 104 OSPFv3 links and advertised IPv6 prefixes must be advertised in 105 separate LSAs and correlated to the fixed-format LSAs. This document 106 extends the LSA format by encoding the existing OSPFv3 LSA 107 information in Type-Length-Value (TLV) tuples and allowing 108 advertisement of additional information with additional TLVs. 109 Backward compatibility mechanisms are also described. 111 A similar extension was previously proposed in support of multi- 112 topology routing. Additional requirements for OSPFv3 LSA extension 113 include source/destination routing, route tagging, and others. 115 A final requirement is to limit the changes to OSPFv3 to those 116 necessary for TLV-based LSAs. For the most part, the semantics of 117 existing OSPFv3 LSAs are retained for their TLV-based successor LSAs 118 described herein. Additionally, encoding details, e.g., the 119 representation of IPv6 prefixes as described in section A.4.1 in RFC 120 5340 [OSPFV3], have been retained. This requirement was included to 121 increase the expedience of IETF adoption and deployment. 123 The following aspects of OSPFv3 LSA extension are described: 125 1. Extended LSA Types 127 2. Extended LSA TLVs 129 3. Extended LSA Formats 131 4. Backward Compatibility 133 1.1. Requirements notation 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC-KEYWORDS]. 139 1.2. Acknowledgments 141 OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing 142 in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3]. 144 Thanks for Peter Psenak for significant contributions to the backward 145 compatibility mechanisms. 147 Thanks go to Michael Barnes, Mike Dubrovsky, Anton Smirnov, and Tony 148 Przygienda for review of the draft versions and discussions of 149 backward compatibility. 151 Thanks to Alan Davey for review and comments including the suggestion 152 to separate the extended LSA TLV definitions from the extended LSAs 153 definitions. 155 Thanks to David Lamparter for review and suggestions on backward 156 compatibility. 158 Thanks to Karsten Thomann for review and editorial comments. 160 The RFC text was produced using Marshall Rose's xml2rfc tool. 162 2. OSPFv3 Extended LSA Types 164 In order to provide backward compatibility, new LSA codes must be 165 allocated. There are eight fixed-format LSAs defined in RFC 5340 166 [OSPFV3]. For ease of implementation and debugging, the LSA function 167 codes are the same as the fixed-format LSAs only with 32, i.e., 0x20, 168 added. The alternative to this mapping was to allocate a bit in the 169 LS Type indicating the new LSA format. However, this would have used 170 one half the LSA function code space for the migration of the eight 171 original fixed-format LSAs. For backward compatibility, the U-bit 172 will be set in LS Type so that the LSAs will be flooded by OSPFv3 173 routers that do not understand them. 175 LSA function code LS Type Description 176 ---------------------------------------------------- 177 33 0xA021 E-Router-LSA 178 34 0xA022 E-Network-LSA 179 35 0xA023 E-Inter-Area-Prefix-LSA 180 36 0xA024 E-Inter-Area-Router-LSA 181 37 0xC025 E-AS-External-LSA 182 38 N/A Unused (Not to be allocated) 183 39 0xA027 E-Type-7-LSA 184 40 0x8028 E-Link-LSA 185 41 0xA029 E-Intra-Area-Prefix-LSA 187 OSPFv3 Extended LSA Types 189 3. OSPFv3 Extended LSA TLVs 191 The format of the TLVs within the body of the extended LSAs is the 192 same as the format used by the Traffic Engineering Extensions to OSPF 193 [TE]. The variable TLV section consists of one or more nested 194 Type/Length/Value (TLV) tuples. Nested TLVs are also referred to as 195 sub-TLVs. The format of each TLV is: 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Type | Length | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Value... | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 TLV Format 207 The Length field defines the length of the value portion in octets 208 (thus a TLV with no value portion would have a length of 0). The TLV 209 is padded to 4-octet alignment; padding is not included in the length 210 field (so a 3-octet value would have a length of 3, but the total 211 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 212 aligned. For example, a 1-byte value would have the length field set 213 to 1, and 3 octets of padding would be added to the end of the value 214 portion of the TLV. 216 This document defines the following top-level TLV types: 218 o 0 - Reserved 220 o 1 - Router-Link TLV 222 o 2 - Attached-Routers TLV 224 o 3 - Inter-Area Prefix TLV 226 o 4 - Inter-Area Router TLV 228 o 5 - External Prefix TLV 230 o 6 - Intra-Area Prefix TLV 232 o 7 - IPv6 Link-Local Address TLV 234 o 8 - IPv4 Link-Local Address TLV 235 Additionally, this document defines the following sub-TLV types: 237 o 0 - Reserved 239 o 1 - IPv6 Forwarding Address sub-TLV 241 o 2 - IPv4 Forwarding Address sub-TLV 243 o 3 - Route Tag sub-TLV 245 In general, TLVs and sub-TLVs MAY occur in any order and the 246 specification should define whether the TLV or sub-TLV is required 247 and the behavior when there are multiple occurances of the TLV or 248 sub-TLVs. 250 3.1. Prefix Options Extensions 252 The prefix options are extended from Appendix A.4.1.1 [OSPFV3]. The 253 applicability of the LA-bit is expanded and it SHOULD be set in 254 Inter-Area-Prefix-TLVs and MAY be set in External-Prefix-TLVs when 255 the advertised host IPv6 address, i.e., PrefixLength = 128, is an 256 interface address. In RFC 5340, the LA-bit is only set in Intra- 257 Area-Prefix-LSAs (Section 4.4.3.9 in [OSPFV3]). This will allow a 258 stable address to be advertised without having to configure a 259 separate loopback address in every OSPFv3 area. 261 3.1.1. N-bit Prefix Option 263 Additionally, the N-bit prefix option is defined. The figure below 264 shows the position of the N-bit in the prefix options (pending IANA 265 allocation). This corresponds to the value 0x20. 267 0 1 2 3 4 5 6 7 268 +--+--+--+--+--+--+--+--+ 269 | | | N|DN| P| x|LA|NU| 270 +--+--+--+--+--+--+--+--+ 272 The Prefix Options field 274 The N-bit is set in PrefixOptions for a host address 275 (PrefixLength=128) that identifies the advertising router. While it 276 is similar to the LA-bit, there are two differences. The advertising 277 router MAY choose NOT to set the N-bit even when the above conditions 278 are met. If the N-bit is set and the PrefixLength is NOT 128, the 279 N-bit MUST be ignored. Additionally, the N-bit is propagated in the 280 PrefixOptions when an OSPFv3 Area Border Router (ABR) originates an 281 Inter-Area-Prefix-LSA for an Intra-Area route which has the N-bit set 282 in the PrefixOptions. Similarly, the N-bit is propagated in the 283 PrefixOptions when an OSPFv3 NSSA ABR originates an Extended-AS- 284 External-LSA corresponding to an NSSA route as described in section 3 285 of RFC 3101 ([NSSA]). The N-bit is to the Inter-Area-Prefix-TLV 286 (Section 3.4), External-Prefix-TLV (Section 3.6), and Intra-Area- 287 Prefix-TLV (Section 3.7) The N-bit is useful for applications such as 288 identifying the prefixes corresponding to Node Segment Identifiers 289 (SIDs) in Segment Routing [SEGMENT-ROUTING]. 291 3.2. Router-Link TLV 293 The Router-Link TLV defines a single router link and the field 294 definitions correspond directly to links in the OSPFv3 Router-LSA, 295 section A.4.3, [OSPFV3]. The Router-Link TLV is only applicable to 296 the E-Router-LSA (Section 4.1). Inclusion in other Extended LSAs 297 MUST be ignored. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | 1 (Router-Link) | TLV Length | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Type | 0 | Metric | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Interface ID | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Neighbor Interface ID | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Neighbor Router ID | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 . . 313 . sub-TLVs . 314 . . 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Router-Link TLV 319 3.3. Attached-Routers TLV 321 The Attached-Routers TLV defines all the routers attached to an 322 OSPFv3 multi-access network. The field definitions correspond 323 directly to content of the OSPFv3 Network-LSA, section A.4.4, 324 [OSPFV3]. The Attached-Routers TLV is only applicable to the E- 325 Network-LSA (Section 4.2). Inclusion in other Extended LSAs MUST be 326 ignored. 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | 2 (Attached-Routers) | TLV Length | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Adjacent Neighbor Router ID | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 . . 336 . Additional Adjacent Neighbors . 337 . . 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Attached-Routers TLV 342 There are two reasons for not having a separate TLV or sub-TLV for 343 each adjacent neighbor. The first is to discourage using the E- 344 Network-LSA for more than its current role of solely advertising the 345 routers attached to a multi-access network. The router's metric as 346 well as the attributes of individual attached routers should be 347 advertised in their respective E-Router-LSAs. The second reason is 348 that there is only a single E-Network-LSA per multi-access link with 349 the Link State ID set to the Designated Router's Interface ID and, 350 consequently, compact encoding has been chosen to decrease the 351 likelihood that the size of the E-Network-LSA will require IPv6 352 fragmentation when advertised in an OSPFv3 Link State Update packet. 354 3.4. Inter-Area-Prefix TLV 356 The Inter-Area-Prefix TLV defines a single OSPFV3 inter-area prefix. 357 The field definitions correspond directly to the content of an OSPFv3 358 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 359 Inter-Area-Prefix-LSA, as defined in section A.4.5, [OSPFV3]. 360 Additionally, the PrefixOptions are extended as described in 361 Section 3.1. The Inter-Area-Prefix TLV is only applicable to the E- 362 Inter-Area-Prefix-LSA (Section 4.3). Inclusion in other Extended 363 LSAs MUST be ignored. 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | 3 (Inter-Area Prefix) | TLV Length | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | 0 | Metric | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | PrefixLength | PrefixOptions | 0 | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Address Prefix | 375 | ... | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 . . 378 . sub-TLVs . 379 . . 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Inter-Area Prefix TLV 384 3.5. Inter-Area-Router TLV 386 The Inter-Area-Router TLV defines a single OSPFv3 Autonomous System 387 Boundary Router (ASBR) reachable in another area. The field 388 definitions correspond directly to the content of an OSPFv3 Inter- 389 Area-Router-LSA, as defined in section A.4.6, [OSPFV3]. The Inter- 390 Area-Router TLV is only applicable to the E-Inter-Area-Router-LSA 391 (Section 4.4). Inclusion in other Extended LSAs MUST be ignored. 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | 4 (Inter-Area Router) | TLV Length | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | 0 | Options | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | 0 | Metric | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Destination Router ID | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 . . 405 . sub-TLVs . 406 . . 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Inter-Area Router TLV 411 3.6. External-Prefix TLV 413 The External-Prefix TLV defines a single OSPFv3 external prefix. The 414 field definitions correspond directly to the content of an OSPFv3 415 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 AS- 416 External-LSA, as defined in section A.4.7, [OSPFV3]. The External- 417 Prefix TLV is only applicable to the E-AS-External-LSA (Section 4.5) 418 and the E-NSSA-LSA (Section 4.6). Additionally, the PrefixOptions 419 are extended as described in Section 3.1. Inclusion in other 420 Extended LSAs MUST be ignored. 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | 5 (External Prefix) | TLV Length | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | |E| | | Metric | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | PrefixLength | PrefixOptions | 0 | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Address Prefix | 432 | ... | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 . . 435 . sub-TLVs . 436 . . 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 External Prefix TLV 441 In the External-Prefix TLV, the optional IPv6/IPv4 Forwarding Address 442 and External Route Tag are now sub-TLVs. Given the Referenced LS 443 type and Referenced Link State ID from the AS-External-LSA have never 444 been used or even specified, they have been omitted from the External 445 Prefix TLV. If there were ever a requirement for a referenced LSA, 446 it could be satisfied with a sub-TLV. 448 The following sub-TLVs are defined for optional inclusion in the 449 External Prefix TLV: 451 o 1 - IPv6 Forwarding Address sub-TLV (Section 3.10) 453 o 2 - IPv4 Forwarding Address sub-TLV (Section 3.11) 455 o 3 - Route Tag sub-TLV (Section 3.12) 457 3.7. Intra-Area-Prefix TLV 459 The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix. 460 The field definitions correspond directly to the content of an OSPFv3 461 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 Link- 462 LSA, as defined in section A.4.9, [OSPFV3]. The Intra-Area-Prefix 463 TLV is only applicable to the E-Link-LSA (Section 4.7) and the 464 Additionally, the PrefixOptions are extended as described in 465 Section 3.1. E-Intra-Area-Prefix-LSA (Section 4.8). Inclusion in 466 other Extended LSAs MUST be ignored. 468 0 1 2 3 469 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 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | 6 (Intra-Area Prefix) | TLV Length | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | 0 | Metric | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | PrefixLength | PrefixOptions | 0 | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Address Prefix | 478 | ... | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 . . 481 . sub-TLVs . 482 . . 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 Intra-Area Prefix TLV 487 3.8. IPv6 Link-Local Address TLV 489 The IPv6 Link-Local Address TLV is to be used with IPv6 address 490 families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV 491 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 492 other Extended LSAs MUST be ignored. 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | 7 (IPv6 Local-Local Address) | TLV Length | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | | 500 +- -+ 501 | | 502 +- IPv6 Link-Local Interface Address -+ 503 | | 504 +- -+ 505 | | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 . . 508 . sub-TLVs . 509 . . 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 IPv6 Link-Local Address TLV 514 3.9. IPv4 Link-Local Address TLV 516 The IPv4 Link-Local Address TLV is to be used with IPv4 address 517 families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV 518 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 519 other Extended LSAs MUST be ignored. 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | 8 (IPv4 Local-Local Address) | TLV Length | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | IPv4 Link-Local Interface Address | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 . . 529 . sub-TLVs . 530 . . 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 IPv4 Link-Local Address TLV 535 3.10. IPv6-Forwarding-Address Sub-TLV 537 The IPv6 Forwarding Address TLV has identical semantics to the 538 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv6 539 Forwarding Address TLV is applicable to the External-Prefix TLV 540 (Section 3.6). Specification as a sub-TLV of other TLVs is not 541 defined herein. The sub-TLV is optional and the first specified 542 instance is used as the Forwarding Address as defined in [OSPFV3]. 543 Instances subsequent to the first MUST be ignored. 545 The IPv6 Forwarding Address TLV is to be used with IPv6 address 546 families as defined in [OSPFV3-AF] It MUST be ignored for other 547 address families. 549 0 1 2 3 550 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 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | 1 - Forwarding Address | sub-TLV Length | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | | 555 +- -+ 556 | | 557 +- Forwarding Address -+ 558 | | 559 +- -+ 560 | | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 Forwarding Address Tag TLV 565 3.11. IPv4-Forwarding-Address Sub-TLV 567 The IPv4 Forwarding Address TLV has identical semantics to the 568 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv4 569 Forwarding Address TLV is The IPv4 Forwarding Address TLV is 570 applicable to the External-Prefix TLV (Section 3.6). Specification 571 as a sub-TLV of other TLVs is not defined herein. The sub-TLV is 572 optional and the first specified instance is used as the Forwarding 573 Address as defined in [OSPFV3]. Instances subsequent to the first 574 MUST be ignored. 576 The IPv4 Forwarding Address TLV is to be used with IPv3 address 577 families as defined in [OSPFV3-AF] It MUST be ignored for other 578 address families. 580 0 1 2 3 581 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 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | 2 - Forwarding Address | sub-TLV Length | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Forwarding Address | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 Forwarding Address Tag TLV 590 3.12. Route-Tag Sub-TLV 592 The optional Route Tag sub-TLV has identical semantics to the 593 optional External Route Tag in section A.4.7 of [OSPFV3]. The Route 594 Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.6). 595 Specification as a sub-TLV of other TLVs is not defined herein. The 596 sub-TLV is optional and the first specified instance is used as the 597 Route Tag as defined in [OSPFV3]. Instances subsequent to the first 598 MUST be ignored. 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | 3 - Route Tag | sub-TLV Length | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Route Tag | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Route Tag Sub-TLV 610 4. OSPFv3 Extended LSAs 612 This section specifies the OSPFv3 Extended LSA formats and encoding. 613 The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3 614 LSAs specifed in [OSPFV3]. 616 4.1. OSPFv3 E-Router-LSA 618 The E-Router-LSA has an LS Type of 0xA021 and has the same base 619 information content as the Router-LSA defined in section A.4.3 of 620 [OSPFV3]. However, unlike the existing Router-LSA, it is fully 621 extendable and represented as TLVs. 623 0 1 2 3 624 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 625 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | LS Age |1|0|1| 0x21 | 627 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Link State ID | 629 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Advertising Router | 631 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | LS Sequence Number | 633 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | LS Checksum | Length | 635 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | 0 |Nt|x|V|E|B| Options | 637 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 . . 639 . TLVs . 640 . . 641 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Extended Router-LSA 645 All LSA Header fields are the same as defined for the Router-LSA. 646 Initially, only the top-level Router-Link TLV Section 3.2 is 647 applicable and an E-Router-LSA may include multiple Router-Link TLVs. 648 Like the existing Router-LSA, the LSA length is used to determine the 649 end of the LSA including TLVs. 651 4.2. OSPFv3 E-Network-LSA 653 The E-Network-LSA has an LS Type of 0xA022 and has the same base 654 information content as the Network-LSA defined in section A.4.4 of 655 [OSPFV3]. However, unlike the existing Network-LSA, it is fully 656 extendable and represented as TLVs. 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | LS Age |1|0|1| 0x22 | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Link State ID | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Advertising Router | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | LS Sequence Number | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | LS Checksum | Length | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | 0 | Options | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 . . 674 . TLVs . 675 . . 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 E-Network-LSA 680 All LSA Header fields are the same as defined for the Network-LSA. 681 Like the existing Network-LSA, the LSA length is used to determine 682 the end of the LSA including TLVs. Initially, only the top-level 683 Attached-Routers TLV Section 3.3 is applicable. If the Attached- 684 Router TLV is not included in the E-Network-LSA, it is treated as 685 malformed as described in Section 5. Instances of the Attached- 686 Router TLV subsequent to the first MUST be ignored. 688 4.3. OSPFv3 E-Inter-Area-Prefix-LSA 690 The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same 691 base information content as the Inter-Area-Prefix-LSA defined in 692 section A.4.5 of [OSPFV3]. However, unlike the existing Inter-Area- 693 Prefix-LSA, it is fully extendable and represented as TLVs. 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | LS Age |1|0|1| 0x23 | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Link State ID | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Advertising Router | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | LS Sequence Number | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | LS Checksum | Length | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 . . 709 . TLVs . 710 . . 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 E-Inter-Area-Prefix-LSA 715 All LSA Header fields are the same as defined for the Inter-Area- 716 Prefix-LSA. In order to retain compatibility and semantics with the 717 current OSPFv3 specification, each Inter-Area-Prefix LSA MUST contain 718 a single Inter-Area Prefix TLV. This will facilitate migration and 719 avoid changes to functions such as incremental SPF computation. 721 Like the existing Inter-Area-Prefix-LSA, the LSA length is used to 722 determine the end of the LSA including TLV. Initially, only the top- 723 level Inter-Area-Prefix TLV (Section 3.4) is applicable. If the 724 Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA, 725 it is treated as malformed as described in Section 5. Instances of 726 the Inter-Area-Prefix TLV subsequent to the first MUST be ignored. 728 4.4. OSPFv3 E-Inter-Area-Router-LSA 730 The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same 731 base information content as the Inter-Area-Router-LSAE defined in 732 section A.4.6 of [OSPFV3]. However, unlike the Inter-Area-Router- 733 LSA, it is fully extendable and represented as TLVs. 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | LS Age |1|0|1| 0x24 | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Link State ID | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Advertising Router | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | LS Sequence Number | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | LS Checksum | Length | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 . . 749 . TLVs . 750 . . 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 E-Inter-Area-Router-LSA 755 All LSA Header fields are the same as defined for the Inter-Area- 756 Router-LSA. In order to retain compatibility and semantics with the 757 current OSPFv3 specification, each Inter-Area-Router LSA MUST contain 758 a single Inter-Area Router TLV. This will facilitate migration and 759 avoid changes to functions such as incremental SPF computation. 761 Like the existing Inter-Area-Router-LSA, the LSA length is used to 762 determine the end of the LSA including TLV. Initially, only the top- 763 level Inter-Area-Router TLV (Section 3.5) is applicable. If the 764 Inter-Area-Router TLV is not included in the E-Inter-Area-Router-LSA, 765 it is treated as malformed as described in Section 5. Instances of 766 the Inter-Area-Router TLV subsequent to the first MUST be ignored. 768 4.5. OSPFv3 E-AS-External-LSA 770 The E-AS-External-LSA has an LS Type of 0xC025 and has the same base 771 information content as the AS-External-LSA defined in section A.4.7 772 of [OSPFV3]. However, unlike the existing AS-External-LSA, it is 773 fully extendable and represented as TLVs. 775 0 1 2 3 776 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 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | LS Age |1|1|0| 0x25 | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Link State ID | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Advertising Router | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | LS Sequence Number | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | LS Checksum | Length | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 . . 789 . TLVs . 790 . . 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 E-AS-External-LSA 795 All LSA Header fields are the same as defined for the AS-External- 796 LSA. In order to retain compatibility and semantics with the current 797 OSPFv3 specification, each LSA MUST contain a single External Prefix 798 TLV. This will facilitate migration and avoid changes to OSPFv3 799 processes such as incremental SPF computation. 801 Like the existing AS-External-LSA, the LSA length is used to 802 determine the end of the LSA including sub-TLVs. Initially, only the 803 top-level External-Prefix TLV (Section 3.6) is applicable. If the 804 External-Prefix TLV is not included in the E-External-AS-LSA, it is 805 treated as malformed as described in Section 5. Instances of the 806 External-Prefix TLV subsequent to the first MUST be ignored. 808 4.6. OSPFv3 E-NSSA-LSA 810 The E-NSSA-LSA will have the same format and TLVs as the Extended AS- 811 External-LSA Section 4.5. This is the same relationship as exists 812 between the NSSA-LSA defined in section A.4.8 of [OSPFV3], and the 813 AS-External-LSA. The NSSA-LSA will have type 0xA027 which implies 814 area flooding scope. Future requirements may dictate that supported 815 TLVs differ between the E-AS-External-LSA and the E-NSSA-LSA. 816 However, future requirements are beyond the scope of this document. 818 4.7. OSPFv3 E-Link-LSA 820 The E-Link-LSA has an LS Type of 0x8028 and will have the same base 821 information content as the Link-LSA defined in section A.4.9 of 822 [OSPFV3]. However, unlike the existing Link-LSA, it is extendable 823 and represented as TLVs. 825 0 1 2 3 826 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 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | LS Age |1|0|0| 0x28 | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Link State ID | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Advertising Router | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | LS Sequence Number | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | LS Checksum | Length | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Rtr Priority | Options | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 . . 841 . TLVs . 842 . . 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 E-Link-LSA 847 All LSA Header fields are the same as defined for the Link-LSA. 849 Only the Intra-Area-Prefix TLV (Section 3.7), IPv6 Link-Local Address 850 TLV (Section 3.8), and IPv4 Link-Local Address TLV (Section 3.9) are 851 applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA 852 affords advertisement of multiple intra-area prefixes. Hence, 853 multiple Intra-Area Prefix TLVs (Section 3.7) may be specified and 854 the LSA length defines the end of the LSA including all TLVs. 856 A single instance of the IPv6 Link-Local Address TLV (Section 3.8) 857 SHOULD be included in the E-Link-LSA. Instances following the first 858 MUST be ignored. For IPv4 address families as defined in 859 [OSPFV3-AF], this TLV MUST be ignored. 861 Similarly, only a single instance of the IPv4 Link-Local Address TLV 862 (Section 3.9) SHOULD be included in the E-Link-LSA. Instances 863 following the first MUST be ignored. For OSPFv3 IPv6 address 864 families as defined in [OSPFV3-AF], this TLV MUST be ignored. 866 If the IPv4/IPv6 Link-Local Address TLV corresponding to the OSPFv3 867 Address Family is not included in the E-Link-LSA, it is treated as 868 malformed as described in Section 5. 870 Future specifications may support advertisement of routing and 871 topology information for multiple address families. However, this is 872 beyond the scope of this document. 874 4.8. OSPFv3 E-Intra-Area-Prefix-LSA 876 The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same 877 base information content as the Intra-Area-Prefix-LSA defined in 878 section A.4.10 of [OSPFV3]. However, unlike the Intra-Area-Prefix- 879 LSA, it is fully extendable and represented as TLVs. 881 0 1 2 3 882 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 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | LS Age |1|0|1| 0x29 | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Link State ID | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Advertising Router | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | LS Sequence Number | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | LS Checksum | Length | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | 0 | Referenced LS Type | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Referenced Link State ID | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Referenced Advertising Router | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 . . 901 . TLVs . 902 . . 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 E-Intra-Area-Prefix-LSA 907 All LSA Header fields are the same as defined for the Intra-Area- 908 Prefix-LSA. 910 Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords 911 advertisement of multiple intra-area prefixes. Hence, multiple 912 Intra-Area Prefix TLVs may be specified and the LSA length defines 913 the end of the LSA including all TLVs. 915 5. Malformed OSPFv3 Extended LSA Handling 917 Extended LSAs that have inconsistent length or other encoding errors, 918 as described herein, MUST NOT be installed in the Link State 919 Database, acknowledged, or flooded. Reception of malformed LSAs 920 SHOULD be counted and/or logged for examination by the administrator 921 of the OSPFv3 Routing Domain. 923 6. LSA Extension Backward Compatibility 925 In the context of this document, backward compatibility is solely 926 related to the capability of an OSPFv3 router to receive, process, 927 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 928 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 929 extensions utilizing the TLV-based LSAs is out of scope and must be 930 covered in the documents describing those extensions. Both full and, 931 if applicable, partial deployment SHOULD be specified for future TLV- 932 based OSPFv3 LSA extensions. 934 Two distinct backward compatibility modes are supported dependent on 935 the OSPFv3 routing domain migration requirements. For simplicity and 936 to avoid the scaling impact of maintaining both TLV and non-TLV based 937 versions of the same LSA within a routing domain, the basic backward 938 compatibility mode will not allow mixing of LSA formats. Different 939 LSA formats could still be supported with multiple OSPFv3 instances 940 and separate OSPFv3 routing domains. Additionally, a more flexible 941 mode is provided in Section 6.1, where both formats of LSA coexist. 942 In order to facilitate backward compatibility, the OSPFv3 options 943 field (as described in Appendix A.2 of RFC 5340 [OSPFV3]), will 944 contain two additional options bits. The EL-bits will be used to 945 indicate that the OSPFv3 router's level of Extended LSA support. An 946 OSPFv3 router configured to support extended LSAs MUST set its 947 options field EL-bits in OSPFv3 Hello and Database Description 948 packets as follows: 950 B'00' 951 None - Extended LSAs are not originate nor used in the SPF 952 calculation. 954 B'01' 955 MixedModeOriginateOnly - Both extended and non-extended LSAs are 956 originated. Non-extended LSAs are used in the SPF computation. 958 B'10' 959 MixedModeOriginateSPF - Both extended and non-extended LSAs are 960 originated. Extended LSAs are used in the SPF computation. 962 B'11' 963 Full - Only extended LSAs are originated and used in the SPF 964 computation. 966 If Full is specified for ExtendedLSASupport, the OSPFv3 router MUST 967 NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and 968 Database Description packets with the options field EL-bits set to 969 MixedModeOriginateOnly or None. Similarly, if MixModeOriginateSPF is 970 specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form 971 adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database 972 Description packets with the options field EL-bits set to None 973 (B'00'). In this manner, OSPFv3 routers using new encodings can be 974 completely isolated from those OSPFv3 routers depending on the RFC 975 5340 encoding and not setting their options field EL-bits since the 976 default setting indicates no support for extended LSAs. 978 1 2 979 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 981 | | | | | | | | | | | | EL|AT|L|AF|*|*|DC|R|N|x|E|V6| 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 983 The Options field 985 EL-bits 986 These bits indicate the level of Extended LSA support. 987 B'00' - Extended LSAs are not originate nor used in the 988 SPF calculation. 989 B'01' - Both extended and non-extended LSAs are originated. 990 Non-extended LSAs are used in the SPF computation. 991 B'10' - Both extended and non-extended LSAs are originated. 992 Extended LSAs are used in the SPF computation. 993 B'11' - Only extended LSA are originated and used in the 994 SPF computation. 996 Options Field EL-bits 998 The EL-bits will also be set in the LSA options field in Extended and 999 Non-Extended LSAs. While the value of the EL-bits has no functional 1000 significance in the LSA options field, visibility of every OSPFv3 1001 Router's extended LSA support is expected to be very useful for 1002 management and troubleshooting during the migration period. 1004 6.1. Extended LSA Mixed-Mode Backward Compatibility 1006 An implementation MAY support configuration allowing a graceful 1007 transition from the non-extended (non-TLV-based) LSAs to the extended 1008 (TLV-based) LSAs in an OSPFv3 routing domain. In these routing 1009 domains, the OSPFv3 routers configured with a value of 1010 MixedModeOriginateOnly or MixedModeOriginateSPF for 1011 ExtendedLSASupport, (Appendix A), MUST originate both the extended 1012 and non-extended versions of the OSPFv3 LSAs described herein. For 1013 the purposes of Shortest Path First (SPF) computation, the non- 1014 extended OSPFv3 LSAs are used for SPF computation when 1015 MixedModeOriginateOnly is configured and the extended LSAs are used 1016 when MixedModeOriginateSPF is specified. The extended LSAs MAY be 1017 used for functions other than routing computation as long as backward 1018 compatibility is specified in the documents specifying those 1019 functions. 1021 In this manner, OSPFv3 routing domains utilizing the new encodings 1022 can be gradually migrated with a worst-case overhead cost of 1023 approximately doubling the number of LSAs in the routing domain. The 1024 transition within an OSPFv3 routing domain would progress as follows: 1026 1. Configure OSPFv3 Router ExtendedLSASupport to 1027 MixedModeOriginateOnly so that routers originate the extended 1028 LSAs. 1030 2. When all the OSPFv3 Routers have been reconfigured to 1031 MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to 1032 use the extended LSAs by configuring ExtendedLSASupport to 1033 MixedModeOriginateSPF. This can be done on a small subset of 1034 OSPFv3 Routers and the route tables can be verified. 1036 3. When all the OSPFv3 Routers have been reconfigured to 1037 MixedModeOriginateSPF and the routing has been verified, 1038 reconfigure OSPFv3 Routers to purge or simply not refresh the 1039 non-extended OSPFv3 LSA by configuring ExtendedLSASupport to 1040 Full. 1042 In order to prevent OSPFv3 routing domain routing loops, the 1043 advertised metrics in the extended and non-extended OSPFv3 LSAs MUST 1044 be identical. 1046 6.1.1. Area Extended LSA Mixed-Mode Backward Compatibility 1048 An implementation MAY also support configuration allowing graceful 1049 transition from the non-extended LSAs to the extended LSAs within a 1050 single area. In these areas, the parameter AreaExtendedLSASupport 1051 (Appendix B) may be configured to take precedence over the global 1052 parameter ExtendedLSASupport. However, the AreaExtendedLSASupport 1053 will only apply to link and area scoped LSAs within the area and area 1054 based SPF calculations. The default is for the 1055 AreaExtendedLSASupport to be inherited from the ExtendedLSASupport. 1056 The configuration of ExtendedLSASupport will apply to AS-External 1057 LSAs even when AreaExtendedLSASupport takes precedence. 1059 When preforming a graceful restart [GRACEFUL-RESTART], an OSPFv3 1060 router configured with MixedModeOriginate will use the non-extended 1061 OSPFv3 LSAs to determine whether or not the graceful restart has 1062 completed successfully. Similarly, an OSPFv3 router configured with 1063 MixedModeOriginateSPF will use the extended LSAs. In other words, 1064 successful OSPFv3 graceful restart determination will follow the SPF 1065 calculation. 1067 6.2. LSA TLV Processing Backward Compatibility 1069 This section defines the general rules for processing LSA TLVs. To 1070 ensure compatibility of future TLV-based LSA extensions, all 1071 implementations MUST adhere to these rules: 1073 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or 1074 processing Extended-LSAs. 1076 2. Whether or not partial deployment of a given TLV is supported 1077 MUST be specified. 1079 3. If partial deployment is not supported, mechanisms to ensure the 1080 corresponding feature are not deployed MUST be specified in the 1081 document defining the new TLV or sub-TLV. 1083 4. If partial deployment is supported, backward compatibility and 1084 partial deployment MUST be specified in the document defining the 1085 new TLV or sub-TLV. 1087 7. Security Considerations 1089 In general, extendible OSPFv3 LSAs are subject to the same security 1090 concerns as those described in RFC 5340 [OSPFV3]. Additionally, 1091 implementations must assure that malformed TLV and sub-TLV 1092 permutations do not result in errors that cause hard OSPFv3 failures. 1094 If there were ever a requirement to digitally sign OSPFv3 LSAs as 1095 described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the 1096 mechanisms described herein would greatly simplify the extension. 1098 8. IANA Considerations 1100 This specification defines nine OSPFv3 Extended LSA types as 1101 described in Section 2. 1103 This specification also creates two registries OSPFv3 Extended-LSAs 1104 TLVs and sub-TLVs. The TLV and sub-TLV code-points in these 1105 registries are common to all Extended-LSAs and their respective 1106 definitions must define where they are applicable. 1108 The OSPFv3 Extend-LSA TLV registry will define top-level TLVs for 1109 Extended-LSAs and should be placed in the existing OSPFv3 IANA 1110 registry. New values can be allocated via IETF Consensus or IESG 1111 Approval. 1113 Nine values are allocated by this specification: 1115 o 0 - Reserved 1117 o 1 - Router-Link TLV 1119 o 2 - Attached-Routers TLV 1121 o 3 - Inter-Area Prefix TLV 1123 o 4 - Inter-Area Router TLV 1125 o 5 - External Prefix TLV 1127 o 6 - Intra-Area Prefix TLV 1129 o 7 - IPv6 Link-Local Address TLV 1131 o 8 - IPv4 Link-Local Address TLV 1133 The OSPFv3 Extend-LSA sub-TLV registry will define sub-TLVs at any 1134 level of nesting for Extended-LSAs and should be placed in the 1135 existing OSPFv3 IANA registry. New values can be allocated via IETF 1136 Consensus or IESG Approval. 1138 Three values are allocated by this specification: 1140 o 0 - Reserved 1142 o 1 - Forwarding Address 1144 o 2 - Route Tag 1146 The OSPFv3 Prefix Options registry will define a new code point for 1147 the N-bit. The value 0x20 is suggested. 1149 9. References 1151 9.1. Normative References 1153 [GRACEFUL-RESTART] 1154 Lindem, A. and P. Pillay-Esnault, "OSPFv3 Graceful 1155 Restart", RFC 5187, June 2008. 1157 [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1158 RFC 3101, January 2003. 1160 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1161 for IPv6", RFC 5340, July 2008. 1163 [OSPFV3-AF] 1164 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 1165 Aggarwal, "Support of Address Families in OSPFv3", RFC 1166 5838, April 2010. 1168 [RFC-KEYWORDS] 1169 Bradner, S., "Key words for use in RFCs to Indicate 1170 Requirement Levels", RFC 2119, March 1997. 1172 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 1173 Extensions to OSPF", RFC 3630, September 2003. 1175 9.2. Informative References 1177 [MT-OSPFV3] 1178 Mirtorabi, S. and A. Roy, "Multi-topology routing in 1179 OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-03.txt 1180 (work in progress), January 2008. 1182 [OSPF-DIGITAL-SIGNATURE] 1183 Murphy, S., Badger, M., and B. Wellington, "OSPF with 1184 Digital Signatures", RFC 2154, June 1997. 1186 [SEGMENT-ROUTING] 1187 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1188 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1189 Extensions for Segment Routing", draft-ietf-ospf-segment- 1190 routing-extensions-04.txt (work in progress), February 1191 2015. 1193 Appendix A. Global Configuration Parameters 1195 An additional global configurable parameter will be added to the 1196 OSPFv3 protocol. 1198 ExtendedLSASupport 1199 This is an enumeration type indicating the extent to which the 1200 OSPFv3 instance supports the TLV format described herein for 1201 Extended LSAs. The valid values for the enumeration are: 1203 * None - Extended LSAs will not be originated or used in the SPF 1204 calculation. This is the default. 1206 * MixedModeOriginateOnly - Both extended and non-extended LSAs 1207 will be originated. OSPFv3 adjacencies will be formed with 1208 OSPFv3 routers not supporting this specification. The non- 1209 extended LSAs are used for the SPF computation. 1211 * MixedModeOriginateSPF - Both extended and non-extended LSAs 1212 will be originated. OSPFv3 adjacencies will be formed with 1213 OSPFv3 routers not supporting this specification. The extended 1214 LSAs are used for the SPF computation. 1216 * Full - Extended LSAs will be originated and adjacencies will 1217 not be formed with OSPFv3 routers not supporting this 1218 specification. Only Extended LSAs will be originated. 1220 Appendix B. Area Configuration Parameters 1222 An additional area configurable parameter will be added to the OSPFv3 1223 protocol. 1225 AreaExtendedLSASupport 1226 This is an enumeration type indicating the extent to which the 1227 OSPFv3 area supports the TLV format described herein for Extended 1228 LSAs. The valid value for the enumeration are: 1230 * InheritGlobal - The AreaExtendedLSASupport will be inherited 1231 from ExtendedLSASupport. This is the default. 1233 * None - Non-extended LSAs will not be originated or used in the 1234 SPF calculation. 1236 * MixedModeOriginateOnly - Both extended and non-extended link 1237 and area scoped LSAs will be originated. OSPFv3 adjacencies 1238 will be formed with OSPFv3 routers not supporting this 1239 specification. The non-extended LSAs are used for the SPF 1240 computation. 1242 * MixedModeOriginateSPF - Both extended and non-extended link and 1243 area scoped LSAs will be originated. OSPFv3 adjacencies will 1244 be formed with OSPFv3 routers not supporting this 1245 specification. The extended LSAs are used for the area SPF 1246 computation. 1248 * Full - Link and area scoped extended LSAs will be originated 1249 and adjacencies will not be formed with OSPFv3 routers not 1250 supporting this specification. Only Extended LSAs will be 1251 originated. 1253 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1254 configuring None or MixedModeOriginateOnly for AreaExtendedLSASupport 1255 when Full is specified for ExtendedLSASupport is contradictory and 1256 MAY be prohibited by the implementation. 1258 Authors' Addresses 1260 Acee Lindem 1261 Cisco Systems 1262 301 Midenhall Way 1263 Cary, NC 27513 1264 USA 1266 Email: acee@cisco.com 1268 Sina Mirtorabi 1269 Cisco Systems 1270 170 Tasman Drive 1271 San Jose, CA 95134 1272 USA 1274 Email: sina@cisco.com 1276 Abhay Roy 1277 Cisco Systems 1278 170 Tasman Drive 1279 San Jose, CA 95134 1280 USA 1282 Email: akr@cisco.com 1284 Fred Baker 1285 Cisco Systems 1286 Santa Barbara, CA 93117 1287 USA 1289 Email: fred@cisco.com