idnits 2.17.00 (12 Aug 2021) /tmp/idnits30393/draft-ietf-ospf-ospfv3-lsa-extend-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 18, 2014) is 2802 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Unexpected draft version: The latest known version of draft-ietf-ospf-mt-ospfv3 is -03, but you're referring to -04. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem 3 Internet-Draft S. Mirtorabi 4 Intended status: Standards Track A. Roy 5 Expires: March 22, 2015 F. Baker 6 Cisco Systems 7 September 18, 2014 9 OSPFv3 LSA Extendibility 10 draft-ietf-ospf-ospfv3-lsa-extend-04.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 March 22, 2015. 41 Copyright Notice 43 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . 5 62 3. OSPFv3 Extended LSA TLVs . . . . . . . . . . . . . . . . . . . 6 63 3.1. Router-Link TLV . . . . . . . . . . . . . . . . . . . . . 7 64 3.2. Attached-Routers TLV . . . . . . . . . . . . . . . . . . . 8 65 3.3. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 9 66 3.4. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 10 67 3.5. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 11 68 3.6. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 12 69 3.7. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 13 70 3.8. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 14 71 3.9. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 15 72 3.10. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 15 73 3.11. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 16 74 4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . . 17 75 4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 17 76 4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . . 18 77 4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . . 19 78 4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . . 20 79 4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . . 21 80 4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 22 81 4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 23 82 4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . . 25 83 5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . . 26 84 6. LSA Extension Backward Compatibility . . . . . . . . . . . . . 27 85 6.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . . 28 86 6.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 29 87 6.2. LSA TLV Processing Backward Compatibility . . . . . . . . 30 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 91 9.1. Normative References . . . . . . . . . . . . . . . . . . . 33 92 9.2. Informative References . . . . . . . . . . . . . . . . . . 33 93 Appendix A. Global Configuration Parameters . . . . . . . . . . . 34 94 Appendix B. Area Configuration Parameters . . . . . . . . . . . . 35 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 97 1. Introduction 99 OSPFv3 requires functional extension beyond what can readily be done 100 with the fixed-format Link State Advertisement (LSA) as described in 101 RFC 5340 [OSPFV3]. Without LSA extension, attributes associated with 102 OSPFv3 links and advertised IPv6 prefixes must be advertised in 103 separate LSAs and correlated to the fixed-format LSAs. This document 104 extends the LSA format by encoding the existing OSPFv3 LSA 105 information in Type-Length-Value (TLV) tuples and allowing 106 advertisement of additional information with additional TLVs. 107 Backward compatibility mechanisms are also described. 109 A similar extension was previously proposed in support of multi- 110 topology routing. Additional requirements for OSPFv3 LSA extension 111 include source/destination routing, route tagging, and others. 113 A final requirement is to limit the changes to OSPFv3 to those 114 necessary for TLV-based LSAs. For the most part, the semantics of 115 existing OSPFv3 LSAs are retained for their TLV-based successor LSAs 116 described herein. Additionally, encoding details, e.g., the 117 representation of IPv6 prefixes as described in section A.4.1 in RFC 118 5340 [OSPFV3], have been retained. This requirement was included to 119 increase the expedience of IETF adoption and deployment. 121 The following aspects of OSPFv3 LSA extension are described: 123 1. Extended LSA Types 125 2. Extended LSA TLVs 127 3. Extended LSA Formats 129 4. Backward Compatibility 131 1.1. Requirements notation 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC-KEYWORDS]. 137 1.2. Acknowledgments 139 OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing 140 in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3]. 142 Thanks for Peter Psenak for significant contributions to the backward 143 compatibility mechanisms. 145 Thanks go to Michael Barnes, Mike Dubrovsky, Anton Smirnov, and Tony 146 Przygienda for review of the draft versions and discussions of 147 backward compatibility. 149 Thanks to Alan Davey for review and comments including the suggestion 150 to separate the extended LSA TLV definitions from the extended LSAs 151 definitions. 153 Thanks to David Lamparter for review and suggestions on backward 154 compatibility. 156 The RFC text was produced using Marshall Rose's xml2rfc tool. 158 2. OSPFv3 Extended LSA Types 160 In order to provide backward compatibility, new LSA codes must be 161 allocated. There are eight fixed-format LSAs defined in RFC 5340 162 [OSPFV3]. For ease of implementation and debugging, the LSA function 163 codes are the same as the fixed-format LSAs only with 32, i.e., 0x20, 164 added. The alternative to this mapping was to allocate a bit in the 165 LS Type indicating the new LSA format. However, this would have used 166 one half the LSA function code space for the migration of the eight 167 original fixed-format LSAs. For backward compatibility, the U-bit 168 will be set in LS Type so that the LSAs will be flooded by OSPFv3 169 routers that do not understand them. 171 LSA function code LS Type Description 172 ---------------------------------------------------- 173 33 0xA021 E-Router-LSA 174 34 0xA022 E-Network-LSA 175 35 0xA023 E-Inter-Area-Prefix-LSA 176 36 0xA024 E-Inter-Area-Router-LSA 177 37 0xC025 E-AS-External-LSA 178 38 N/A Unused (Not to be allocated) 179 39 0xA027 E-Type-7-LSA 180 40 0x8028 E-Link-LSA 181 41 0xA029 E-Intra-Area-Prefix-LSA 183 OSPFv3 Extended LSA Types 185 3. OSPFv3 Extended LSA TLVs 187 The format of the TLVs within the body of the extended LSAs is the 188 same as the format used by the Traffic Engineering Extensions to OSPF 189 [TE]. The variable TLV section consists of one or more nested Type/ 190 Length/Value (TLV) tuples. Nested TLVs are also referred to as sub- 191 TLVs. The format of each TLV is: 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Type | Length | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Value... | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 TLV Format 203 The Length field defines the length of the value portion in octets 204 (thus a TLV with no value portion would have a length of 0). The TLV 205 is padded to 4-octet alignment; padding is not included in the length 206 field (so a 3-octet value would have a length of 3, but the total 207 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 208 aligned. For example, a 1-byte value would have the length field set 209 to 1, and 3 octets of padding would be added to the end of the value 210 portion of the TLV. 212 This document defines the following top-level TLV types: 214 o 0 - Reserved 216 o 1 - Router-Link TLV 218 o 2 - Attached-Routers TLV 220 o 3 - Inter-Area Prefix TLV 222 o 4 - Inter-Area Router TLV 224 o 5 - External Prefix TLV 226 o 6 - Intra-Area Prefix TLV 228 o 7 - IPv6 Link-Local Address TLV 229 o 8 - IPv4 Link-Local Address TLV 231 Additionally, this document defines the following sub-TLV types: 233 o 0 - Reserved 235 o 1 - IPv6 Forwarding Address sub-TLV 237 o 2 - IPv4 Forwarding Address sub-TLV 239 o 3 - Route Tag sub-TLV 241 In general, TLVs and sub-TLVs MAY occur in any order and the 242 specification should define whether the TLV or sub-TLV is required 243 and the behavior when there are multiple occurances of the TLV or 244 sub-TLVs. 246 3.1. Router-Link TLV 248 The Router-Link TLV defines a single router link and the field 249 definitions correspond directly to links in the OSPFv3 Router-LSA, 250 section A.4.3, [OSPFV3]. The Router-Link TLV is only applicable to 251 the E-Router-LSA (Section 4.1). Inclusion in other Extended LSAs 252 MUST be ignored. 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | 1 (Router-Link) | TLV Length | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Type | 0 | Metric | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Interface ID | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Neighbor Interface ID | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Neighbor Router ID | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 . . 268 . sub-TLVs . 269 . . 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Router-Link TLV 274 3.2. Attached-Routers TLV 276 The Attached-Routers TLV defines all the routers attached to an 277 OSPFv3 multi-access network. The field definitions correspond 278 directly to content of the OSPFv3 Network-LSA, section A.4.4, 279 [OSPFV3]. The Attached-Routers TLV is only applicable to the 280 E-Network-LSA (Section 4.2). Inclusion in other Extended LSAs MUST 281 be ignored. 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | 2 (Attached-Routers) | TLV Length | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Adjacent Neighbor Router ID | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 . . 291 . Additional Adjacent Neighbors . 292 . . 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Attached-Routers TLV 297 There are two reasons for not having a separate TLV or sub-TLV for 298 each adjacent neighbor. The first is to discourage using the 299 E-Network-LSA for more than its current role of solely advertising 300 the routers attached to a multi-access network. The router's metric 301 as well as the attributes of individual attached routers should be 302 advertised in their respective E-Router-LSAs. The second reason is 303 that there is only a single E-Network-LSA per multi-access link with 304 the Link State ID set to the Designated Router's Interface ID and, 305 consequently, compact encoding has been chosen to decrease the 306 likelihood that the size of the E-Network-LSA will require IPv6 307 fragmentation when advertised in an OSPFv3 Link State Update packet. 309 3.3. Inter-Area-Prefix TLV 311 The Inter-Area-Prefix TLV defines a single OSPFV3 inter-area prefix. 312 The field definitions correspond directly to the content of an OSPFv3 313 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 314 Inter-Area-Prefix-LSA, as defined in section A.4.5, [OSPFV3]. The 315 Inter-Area-Prefix TLV is only applicable to the E-Inter-Area-Prefix- 316 LSA (Section 4.3). Inclusion in other Extended LSAs MUST be ignored. 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | 3 (Inter-Area Prefix) | TLV Length | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | 0 | Metric | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | PrefixLength | PrefixOptions | 0 | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Address Prefix | 328 | ... | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 . . 331 . sub-TLVs . 332 . . 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Inter-Area Prefix TLV 337 3.4. Inter-Area-Router TLV 339 The Inter-Area-Router TLV defines a single OSPFv3 Autonomous System 340 Boundary Router (ASBR) reachable in another area. The field 341 definitions correspond directly to the content of an OSPFv3 Inter- 342 Area-Router-LSA, as defined in section A.4.6, [OSPFV3]. The Inter- 343 Area-Router TLV is only applicable to the E-Inter-Area-Router-LSA 344 (Section 4.4). Inclusion in other Extended LSAs MUST be ignored. 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | 4 (Inter-Area Router) | TLV Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | 0 | Options | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | 0 | Metric | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Destination Router ID | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 . . 358 . sub-TLVs . 359 . . 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Inter-Area Router TLV 364 3.5. External-Prefix TLV 366 The External-Prefix TLV defines a single OSPFv3 external prefix. The 367 field definitions correspond directly to the content of an OSPFv3 368 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 AS- 369 External-LSA, as defined in section A.4.7, [OSPFV3]. The External- 370 Prefix TLV is only applicable to the E-AS-External-LSA (Section 4.5) 371 and the E-NSSA-LSA (Section 4.6). Inclusion in other Extended LSAs 372 MUST be ignored. 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | 5 (External Prefix) | TLV Length | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | |E| | | Metric | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | PrefixLength | PrefixOptions | 0 | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Address Prefix | 384 | ... | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 . . 387 . sub-TLVs . 388 . . 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 External Prefix TLV 393 In the External-Prefix TLV, the optional IPv6/IPv4 Forwarding Address 394 and External Route Tag are now sub-TLVs. Given the Referenced LS 395 type and Referenced Link State ID from the AS-External-LSA have never 396 been used or even specified, they have been omitted from the External 397 Prefix TLV. If there were ever a requirement for a referenced LSA, 398 it could be satisfied with a sub-TLV. 400 The following sub-TLVs are defined for optional inclusion in the 401 External Prefix TLV: 403 o 1 - IPv6 Forwarding Address sub-TLV (Section 3.9) 405 o 2 - IPv4 Forwarding Address sub-TLV (Section 3.10) 407 o 3 - Route Tag sub-TLV (Section 3.11) 409 3.6. Intra-Area-Prefix TLV 411 The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix. 412 The field definitions correspond directly to the content of an OSPFv3 413 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 Link- 414 LSA, as defined in section A.4.9, [OSPFV3]. The Intra-Area-Prefix 415 TLV is only applicable to the E-Link-LSA (Section 4.7) and the 416 E-Intra-Area-Prefix-LSA (Section 4.8). Inclusion in other Extended 417 LSAs MUST be ignored. 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | 6 (Intra-Area Prefix) | TLV Length | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | 0 | Metric | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | PrefixLength | PrefixOptions | 0 | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Address Prefix | 429 | ... | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 . . 432 . sub-TLVs . 433 . . 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Intra-Area Prefix TLV 438 3.7. IPv6 Link-Local Address TLV 440 The IPv6 Link-Local Address TLV is to be used with IPv6 address 441 families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV 442 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 443 other Extended LSAs MUST be ignored. 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | 7 (IPv6 Local-Local Address) | TLV Length | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | | 451 +- -+ 452 | | 453 +- IPv6 Link-Local Interface Address -+ 454 | | 455 +- -+ 456 | | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 . . 459 . sub-TLVs . 460 . . 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 IPv6 Link-Local Address TLV 465 3.8. IPv4 Link-Local Address TLV 467 The IPv4 Link-Local Address TLV is to be used with IPv4 address 468 families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV 469 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 470 other Extended LSAs MUST be ignored. 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | 8 (IPv4 Local-Local Address) | TLV Length | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | IPv4 Link-Local Interface Address | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 . . 480 . sub-TLVs . 481 . . 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 IPv4 Link-Local Address TLV 486 3.9. IPv6-Forwarding-Address Sub-TLV 488 The IPv6 Forwarding Address TLV has identical semantics to the 489 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv6 490 Forwarding Address TLV is applicable to the External-Prefix TLV 491 (Section 3.5). Specification as a sub-TLV of other TLVs is not 492 defined herein. The sub-TLV is optional and the first specified 493 instance is used as the Forwarding Address as defined in [OSPFV3]. 494 Instances subsequent to the first MUST be ignored. 496 The IPv6 Forwarding Address TLV is to be used with IPv6 address 497 families as defined in [OSPFV3-AF] It will be ignored for other 498 address families. 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | 1 - Forwarding Address | sub-TLV Length | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | | 506 +- -+ 507 | | 508 +- Forwarding Address -+ 509 | | 510 +- -+ 511 | | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Forwarding Address Tag TLV 516 3.10. IPv4-Forwarding-Address Sub-TLV 518 The IPv4 Forwarding Address TLV has identical semantics to the 519 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv4 520 Forwarding Address TLV is The IPv4 Forwarding Address TLV is 521 applicable to the External-Prefix TLV (Section 3.5). Specification 522 as a sub-TLV of other TLVs is not defined herein. The sub-TLV is 523 optional and the first specified instance is used as the Forwarding 524 Address as defined in [OSPFV3]. Instances subsequent to the first 525 MUST be ignored. 527 The IPv4 Forwarding Address TLV is to be used with IPv3 address 528 families as defined in [OSPFV3-AF] It will be ignored for other 529 address families. 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | 2 - Forwarding Address | sub-TLV Length | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Forwarding Address | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Forwarding Address Tag TLV 541 3.11. Route-Tag Sub-TLV 543 The optional Route Tag sub-TLV has identical semantics to the 544 optional External Route Tag in section A.4.7 of [OSPFV3]. The Route 545 Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.5). 546 Specification as a sub-TLV of other TLVs is not defined herein. The 547 sub-TLV is optional and the first specified instance is used as the 548 Route Tag as defined in [OSPFV3]. Instances subsequent to the first 549 MUST be ignored. 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | 3 - Route Tag | sub-TLV Length | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Route Tag | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 Route Tag Sub-TLV 561 4. OSPFv3 Extended LSAs 563 This section specifies the OSPFv3 Extended LSA formats and encoding. 564 The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3 565 LSAs specifed in [OSPFV3]. 567 4.1. OSPFv3 E-Router-LSA 569 The E-Router-LSA has an LS Type of 0xA021 and has the same base 570 information content as the Router-LSA defined in section A.4.3 of 571 [OSPFV3]. However, unlike the existing Router-LSA, it is fully 572 extendable and represented as TLVs. 574 0 1 2 3 575 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 576 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | LS Age |1|0|1| 0x21 | 578 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Link State ID | 580 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Advertising Router | 582 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | LS Sequence Number | 584 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | LS Checksum | Length | 586 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | 0 |Nt|x|V|E|B| Options | 588 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 . . 590 . TLVs . 591 . . 592 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 Extended Router-LSA 596 All LSA Header fields are the same as defined for the Router-LSA. 597 Initially, only the top-level Router-Link TLV Section 3.1 is 598 applicable and an E-Router-LSA may include multiple Router-Link TLVs. 599 Like the existing Router-LSA, the LSA length is used to determine the 600 end of the LSA including TLVs. 602 4.2. OSPFv3 E-Network-LSA 604 The E-Network-LSA has an LS Type of 0xA022 and has the same base 605 information content as the Network-LSA defined in section A.4.4 of 606 [OSPFV3]. However, unlike the existing Network-LSA, it is fully 607 extendable and represented as TLVs. 609 0 1 2 3 610 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | LS Age |1|0|1| 0x22 | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Link State ID | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Advertising Router | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | LS Sequence Number | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | LS Checksum | Length | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | 0 | Options | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 . . 625 . TLVs . 626 . . 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 E-Network-LSA 631 All LSA Header fields are the same as defined for the Network-LSA. 632 Like the existing Network-LSA, the LSA length is used to determine 633 the end of the LSA including TLVs. Initially, only the top-level 634 Attached-Routers TLV Section 3.2 is applicable. If the Attached- 635 Router TLV is not included in the E-Network-LSA, it is treated as 636 malformed as described in Section 5. Instances of the Attached- 637 Router TLV subsequent to the first MUST be ignored. 639 4.3. OSPFv3 E-Inter-Area-Prefix-LSA 641 The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same 642 base information content as the Inter-Area-Prefix-LSA defined in 643 section A.4.5 of [OSPFV3]. However, unlike the existing Inter-Area- 644 Prefix-LSA, it is fully extendable and represented as TLVs. 646 0 1 2 3 647 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 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | LS Age |1|0|1| 0x23 | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Link State ID | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Advertising Router | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | LS Sequence Number | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | LS Checksum | Length | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 . . 660 . TLVs . 661 . . 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 E-Inter-Area-Prefix-LSA 666 All LSA Header fields are the same as defined for the Inter-Area- 667 Prefix-LSA. In order to retain compatibility and semantics with the 668 current OSPFv3 specification, each Inter-Area-Prefix LSA MUST contain 669 a single Inter-Area Prefix TLV. This will facilitate migration and 670 avoid changes to functions such as incremental SPF computation. 672 Like the existing Inter-Area-Prefix-LSA, the LSA length is used to 673 determine the end of the LSA including TLV. Initially, only the top- 674 level Inter-Area-Prefix TLV (Section 3.3) is applicable. If the 675 Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA, 676 it is treated as malformed as described in Section 5. Instances of 677 the Inter-Area-Prefix TLV subsequent to the first MUST be ignored. 679 4.4. OSPFv3 E-Inter-Area-Router-LSA 681 The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same 682 base information content as the Inter-Area-Router-LSAE defined in 683 section A.4.6 of [OSPFV3]. However, unlike the Inter-Area-Router- 684 LSA, it is fully extendable and represented as TLVs. 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | LS Age |1|0|1| 0x24 | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Link State ID | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Advertising Router | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | LS Sequence Number | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | LS Checksum | Length | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 . . 700 . TLVs . 701 . . 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 E-Inter-Area-Router-LSA 706 All LSA Header fields are the same as defined for the Inter-Area- 707 Router-LSA. In order to retain compatibility and semantics with the 708 current OSPFv3 specification, each Inter-Area-Router LSA MUST contain 709 a single Inter-Area Router TLV. This will facilitate migration and 710 avoid changes to functions such as incremental SPF computation. 712 Like the existing Inter-Area-Router-LSA, the LSA length is used to 713 determine the end of the LSA including TLV. Initially, only the top- 714 level Inter-Area-Router TLV (Section 3.4) is applicable. If the 715 Inter-Area-Router TLV is not included in the E-Inter-Area-Router-LSA, 716 it is treated as malformed as described in Section 5. Instances of 717 the Inter-Area-Router TLV subsequent to the first MUST be ignored. 719 4.5. OSPFv3 E-AS-External-LSA 721 The E-AS-External-LSA has an LS Type of 0xC025 and has the same base 722 information content as the AS-External-LSA defined in section A.4.7 723 of [OSPFV3]. However, unlike the existing AS-External-LSA, it is 724 fully extendable and represented as TLVs. 726 0 1 2 3 727 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 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | LS Age |1|1|0| 0x25 | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Link State ID | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Advertising Router | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | LS Sequence Number | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | LS Checksum | Length | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 . . 740 . TLVs . 741 . . 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 E-AS-External-LSA 746 All LSA Header fields are the same as defined for the AS-External- 747 LSA. In order to retain compatibility and semantics with the current 748 OSPFv3 specification, each LSA MUST contain a single External Prefix 749 TLV. This will facilitate migration and avoid changes to OSPFv3 750 processes such as incremental SPF computation. 752 Like the existing AS-External-LSA, the LSA length is used to 753 determine the end of the LSA including sub-TLVs. Initially, only the 754 top-level External-Prefix TLV (Section 3.5) is applicable. If the 755 External-Prefix TLV is not included in the E-External-AS-LSA, it is 756 treated as malformed as described in Section 5. Instances of the 757 External-Prefix TLV subsequent to the first MUST be ignored. 759 4.6. OSPFv3 E-NSSA-LSA 761 The E-NSSA-LSA will have the same format and TLVs as the Extended AS- 762 External-LSA Section 4.5. This is the same relationship as exists 763 between the NSSA-LSA defined in section A.4.8 of [OSPFV3], and the 764 AS-External-LSA. The NSSA-LSA will have type 0xA027 which implies 765 area flooding scope. Future requirements may dictate that supported 766 TLVs differ between the E-AS-External-LSA and the E-NSSA-LSA. 767 However, future requirements are beyond the scope of this document. 769 4.7. OSPFv3 E-Link-LSA 771 The E-Link-LSA has an LS Type of 0x8028 and will have the same base 772 information content as the Link-LSA defined in section A.4.9 of 773 [OSPFV3]. However, unlike the existing Link-LFA, it is extendable 774 and represented as TLVs. 776 0 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | LS Age |1|0|0| 0x28 | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Link State ID | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Advertising Router | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | LS Sequence Number | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | LS Checksum | Length | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Rtr Priority | Options | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 . . 792 . TLVs . 793 . . 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 E-Link-LSA 798 All LSA Header fields are the same as defined for the Link-LSA. 800 Only the Intra-Area-Prefix TLV (Section 3.6), IPv6 Link-Local Address 801 TLV (Section 3.7), and IPv4 Link-Local Address TLV (Section 3.8) are 802 applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA 803 affords advertisement of multiple intra-area prefixes. Hence, 804 multiple Intra-Area Prefix TLVs (Section 3.6) may be specified and 805 the LSA length defines the end of the LSA including all TLVs. 807 A single instance of the IPv6 Link-Local Address TLV (Section 3.7) 808 SHOULD be included in the E-Link-LSA. Instances following the first 809 MUST be ignored. For IPv4 address families as defined in 810 [OSPFV3-AF], this TLV MUST be ignored. 812 Similarly, only a single instance of the IPv4 Link-Local Address TLV 813 (Section 3.8) SHOULD be included in the E-Link-LSA. Instances 814 following the first MUST be ignored. For OSPFv3 IPv6 address 815 families as defined in [OSPFV3-AF], this TLV MUST be ignored. 817 If the IPv4/IPv6 Link-Local Address TLV corresponding to the OSPFv3 818 Address Family is not included in the E-Link-LSA, it is treated as 819 malformed as described in Section 5. 821 Future specifications may support advertisement of routing and 822 topology information for multiple address families. However, this is 823 beyond the scope of this document. 825 4.8. OSPFv3 E-Intra-Area-Prefix-LSA 827 The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same 828 base information content as the Intra-Area-Prefix-LSA defined in 829 section A.4.10 of [OSPFV3]. However, unlike the Intra-Area-Prefix- 830 LSA, it is fully extendable and represented as TLVs. 832 0 1 2 3 833 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 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | LS Age |1|0|1| 0x29 | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Link State ID | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Advertising Router | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | LS Sequence Number | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | LS Checksum | Length | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | 0 | Referenced LS Type | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Referenced Link State ID | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Referenced Advertising Router | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 . . 852 . TLVs . 853 . . 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 E-Intra-Area-Prefix-LSA 858 All LSA Header fields are the same as defined for the Intra-Area- 859 Prefix-LSA. 861 Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords 862 advertisement of multiple intra-area prefixes. Hence, multiple 863 Intra-Area Prefix TLVs may be specified and the LSA length defines 864 the end of the LSA including all TLVs. 866 5. Malformed OSPFv3 Extended LSA Handling 868 Extended LSAs that have inconsistent length or other encoding errors, 869 as described herein, MUST NOT be installed in the Link State 870 Database, acknowledged, or flooded. Reception of malformed LSAs 871 SHOULD be counted and/or logged for examination by the administrator 872 of the OSPFv3 Routing Domain. 874 6. LSA Extension Backward Compatibility 876 In the context of this document, backward compatibility is solely 877 related to the capability of an OSPFv3 router to receive, process, 878 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 879 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 880 extensions utilizing the TLV-based LSAs is out of scope and must be 881 covered in the documents describing those extensions. Both full and, 882 if applicable, partial deployment SHOULD be specified for future TLV- 883 based OSPFv3 LSA extensions. 885 Two distinct backward compatibility modes are supported dependent on 886 the OSPFv3 routing domain migration requirements. For simplicity and 887 to avoid the scaling impact of maintaining both TLV and non-TLV based 888 versions of the same LSA within a routing domain, the basic backward 889 compatibility mode will not allow mixing of LSA formats. Different 890 LSA formats could still be supported with multiple OSPFv3 instances 891 and separate OSPFv3 routing domains. Additionally, a more flexible 892 mode is provided in Section 6.1, where both formats of LSA coexist. 893 In order to facilitate backward compatibility, the OSPFv3 options 894 field (as described in Appendix A.2 of RFC 5340 [OSPFV3]), will 895 contain two additional options bits. The EL-bits will be used to 896 indicate that the OSPFv3 router's level of Extended LSA support. An 897 OSPFv3 router configured to support extended LSAs MUST set its 898 options field EL-bits in OSPFv3 Hello and Database Description 899 packets as follows: 901 B'00' 902 None - Extended LSAs are not originate nor used in the SPF 903 calculation. 905 B'01' 906 MixedModeOriginateOnly - Both extended and non-extended LSAs are 907 originated. Non-extended LSAs are used in the SPF computation. 909 B'10' 910 MixedModeOriginateSPF - Both extended and non-extended LSAs are 911 originated. Extended LSAs are used in the SPF computation. 913 B'11' 914 Full - Only extended LSAs are originated and used in the SPF 915 computation. 917 If Full is specified for ExtendedLSASupport, the OSPFv3 router MUST 918 NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and 919 Database Description packets with the options field EL-bits set to 920 MixedModeOriginateOnly or None. Similarly, if MixModeOriginateSPF is 921 specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form 922 adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database 923 Description packets with the options field EL-bits set to None 924 (B'00'). In this manner, OSPFv3 routers using new encodings can be 925 completely isolated from those OSPFv3 routers depending on the RFC 926 5340 encoding and not setting their options field EL-bits since the 927 default setting indicates no support for extended LSAs. 929 1 2 930 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 932 | | | | | | | | | | | | EL|AT|L|AF|*|*|DC|R|N|x|E|V6| 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 934 The Options field 936 EL-bits 937 These bits indicate the level of Extended LSA support. 938 B'00' - Extended LSAs are not originate nor used in the 939 SPF calculation. 940 B'01' - Both extended and non-extended LSAs are originated. 941 Non-extended LSAs are used in the SPF computation. 942 B'10' - Both extended and non-extended LSAs are originated. 943 Extended LSAs are used in the SPF computation. 944 B'11' - Only extended LSA are originated and used in the 945 SPF computation. 947 Options Field EL-bits 949 The EL-bits will also be set in the LSA options field in Extended and 950 Non-Extended LSAs. While the value of the EL-bits has no functional 951 significance in the LSA options field, visibility of every OSPFv3 952 Router's extended LSA support is expected to be very useful for 953 management and troubleshooting during the migration period. 955 6.1. Extended LSA Mixed-Mode Backward Compatibility 957 An implementation MAY support configuration allowing a graceful 958 transition from the non-extended (non-TLV-based) LSAs to the extended 959 (TLV-based) LSAs in an OSPFv3 routing domain. In these routing 960 domains, the OSPFv3 routers configured with a value of 961 MixedModeOriginateOnly or MixedModeOriginateSPF for 962 ExtendedLSASupport, (Appendix A), MUST originate both the extended 963 and non-extended versions of the OSPFv3 LSAs described herein. For 964 the purposes of Shortest Path First (SPF) computation, the non- 965 extended OSPFv3 LSAs are used for SPF computation when 966 MixedModeOriginateOnly is configured and the extended LSAs are used 967 when MixedModeOriginateSPF is specified. The extended LSAs MAY be 968 used for functions other than routing computation as long as backward 969 compatibility is specified in the documents specifying those 970 functions. 972 In this manner, OSPFv3 routing domains utilizing the new encodings 973 can be gradually migrated with a worst-case overhead cost of 974 approximately doubling the number of LSAs in the routing domain. The 975 transition within an OSPFv3 routing domain would progress as follows: 977 1. Configure OSPFv3 Router ExtendedLSASupport to 978 MixedModeOriginateOnly so that routers originate the extended 979 LSAs. 981 2. When all the OSPFv3 Routers have been reconfigured to 982 MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to 983 use the extended LSAs by configuring ExtendedLSASupport to 984 MixedModeOriginateSPF. This can be done on a small subset of 985 OSPFv3 Routers and the route tables can be verified. 987 3. When all the OSPFv3 Routers have been reconfigured to 988 MixedModeOriginateSPF and the routing has been verified, 989 reconfigure OSPFv3 Routers to purge or simply not refresh the 990 non-extended OSPFv3 LSA by configuring ExtendedLSASupport to 991 Full. 993 In order to prevent OSPFv3 routing domain routing loops, the 994 advertised metrics in the extended and non-extended OSPFv3 LSAs MUST 995 be identical. 997 6.1.1. Area Extended LSA Mixed-Mode Backward Compatibility 999 An implementation MAY also support configuration allowing graceful 1000 transition from the non-extended LSAs to the extended LSAs within a 1001 single area. In these areas, the parameter AreaExtendedLSASupport 1002 (Appendix B) may be configured to take precedence over the global 1003 parameter ExtendedLSASupport. However, the AreaExtendedLSASupport 1004 will only apply to link and area scoped LSAs within the area and area 1005 based SPF calculations. The default is for the 1006 AreaExtendedLSASupport to be inherited from the ExtendedLSASupport. 1007 The configuration of ExtendedLSASupport will apply to AS-External 1008 LSAs even when AreaExtendedLSASupport takes precedence. 1010 When preforming a graceful restart [GRACEFUL-RESTART], an OSPFv3 1011 router configured with MixedModeOriginate will use the non-extended 1012 OSPFv3 LSAs to determine whether or not the graceful restart has 1013 completed successfully. Similarly, an OSPFv3 router configured with 1014 MixedModeOriginateSPF will use the extended LSAs. In other words, 1015 successful OSPFv3 graceful restart determination will follow the SPF 1016 calculation. 1018 6.2. LSA TLV Processing Backward Compatibility 1020 This section defines the general rules for processing LSA TLVs. To 1021 ensure compatibility of future TLV-based LSA extensions, all 1022 implementations MUST adhere to these rules: 1024 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or 1025 processing Extended-LSAs. 1027 2. Whether or not partial deployment of a given TLV is supported 1028 MUST be specified. 1030 3. If partial deployment is not supported, mechanisms to ensure the 1031 corresponding feature are not deployed MUST be specified in the 1032 document defining the new TLV or sub-TLV. 1034 4. If partial deployment is supported, backward compatibility and 1035 partial deployment MUST be specified in the document defining the 1036 new TLV or sub-TLV. 1038 7. Security Considerations 1040 In general, extendible OSPFv3 LSAs are subject to the same security 1041 concerns as those described in RFC 5340 [OSPFV3]. Additionally, 1042 implementations must assure that malformed TLV and sub-TLV 1043 permutations do not result in errors that cause hard OSPFv3 failures. 1045 If there were ever a requirement to digitally sign OSPFv3 LSAs as 1046 described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the 1047 mechanisms described herein would greatly simplify the extension. 1049 8. IANA Considerations 1051 This specification defines nine OSPFv3 Extended LSA types as 1052 described in Section 2. 1054 This specification also creates two registries OSPFv3 Extended-LSAs 1055 TLVs and sub-TLVs. The TLV and sub-TLV code-points in these 1056 registries are common to all Extended-LSAs and their respective 1057 definitions must define where they are applicable. 1059 The OSPFv3 Extend-LSA TLV registry will define top-level TLVs for 1060 Extended-LSAs and should be placed in the existing OSPFv3 IANA 1061 registry. New values can be allocated via IETF Consensus or IESG 1062 Approval. 1064 Nine values are allocated by this specification: 1066 o 0 - Reserved 1068 o 1 - Router-Link TLV 1070 o 2 - Attached-Routers TLV 1072 o 3 - Inter-Area Prefix TLV 1074 o 4 - Inter-Area Router TLV 1076 o 5 - External Prefix TLV 1078 o 6 - Intra-Area Prefix TLV 1080 o 7 - IPv6 Link-Local Address TLV 1082 o 8 - IPv4 Link-Local Address TLV 1084 The OSPFv3 Extend-LSA sub-TLV registry will define sub-TLVs at any 1085 level of nesting for Extended-LSAs and should be placed in the 1086 existing OSPFv3 IANA registry. New values can be allocated via IETF 1087 Consensus or IESG Approval. 1089 Three values are allocated by this specification: 1091 o 0 - Reserved 1093 o 1 - Forwarding Address 1095 o 2 - Route Tag 1097 9. References 1099 9.1. Normative References 1101 [GRACEFUL-RESTART] 1102 Lindem, A. and P. Pillay-Esnault, "OSPFv3 Graceful 1103 Restart", RFC 5178, June 2008. 1105 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1106 for IPv6", RFC 5340, July 2008. 1108 [OSPFV3-AF] 1109 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 1110 Aggarwal, "Support of Address Families in OSPFv3", 1111 RFC 5838, April 2010. 1113 [RFC-KEYWORDS] 1114 Bradner, S., "Key words for use in RFCs to Indicate 1115 Requirement Levels", RFC 2119, March 1997. 1117 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 1118 Extensions to OSPF", RFC 3630, September 2003. 1120 9.2. Informative References 1122 [MT-OSPFV3] 1123 Mirtorabi, S. and A. Roy, "Multi-topology routing in 1124 OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt 1125 (work in progress). 1127 [OSPF-DIGITAL-SIGNATURE] 1128 Murphy, S., Badger, M., and B. Wellington, "OSPF with 1129 Digital Signatures", RFC 2154, June 1997. 1131 Appendix A. Global Configuration Parameters 1133 An additional global configurable parameter will be added to the 1134 OSPFv3 protocol. 1136 ExtendedLSASupport 1137 This is an enumeration type indicating the extent to which the 1138 OSPFv3 instance supports the TLV format described herein for 1139 Extended LSAs. The valid values for the enumeration are: 1141 * None - Extended LSAs will not be originated or used in the SPF 1142 calculation. This is the default. 1144 * MixedModeOriginateOnly - Both extended and non-extended LSAs 1145 will be originated. OSPFv3 adjacencies will be formed with 1146 OSPFv3 routers not supporting this specification. The non- 1147 extended LSAs are used for the SPF computation. 1149 * MixedModeOriginateSPF - Both extended and non-extended LSAs 1150 will be originated. OSPFv3 adjacencies will be formed with 1151 OSPFv3 routers not supporting this specification. The extended 1152 LSAs are used for the SPF computation. 1154 * Full - Extended LSAs will be originated and adjacencies will 1155 not be formed with OSPFv3 routers not supporting this 1156 specification. Only Extended LSAs will be originated. 1158 Appendix B. Area Configuration Parameters 1160 An additional area configurable parameter will be added to the OSPFv3 1161 protocol. 1163 AreaExtendedLSASupport 1164 This is an enumeration type indicating the extent to which the 1165 OSPFv3 area supports the TLV format described herein for Extended 1166 LSAs. The valid value for the enumeration are: 1168 * InheritGlobal - The AreaExtendedLSASupport will be inherited 1169 from ExtendedLSASupport. This is the default. 1171 * None - Non-extended LSAs will not be originated or used in the 1172 SPF calculation. 1174 * MixedModeOriginateOnly - Both extended and non-extended link 1175 and area scoped LSAs will be originated. OSPFv3 adjacencies 1176 will be formed with OSPFv3 routers not supporting this 1177 specification. The non-extended LSAs are used for the SPF 1178 computation. 1180 * MixedModeOriginateSPF - Both extended and non-extended link and 1181 area scoped LSAs will be originated. OSPFv3 adjacencies will 1182 be formed with OSPFv3 routers not supporting this 1183 specification. The extended LSAs are used for the area SPF 1184 computation. 1186 * Full - Link and area scoped extended LSAs will be originated 1187 and adjacencies will not be formed with OSPFv3 routers not 1188 supporting this specification. Only Extended LSAs will be 1189 originated. 1191 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1192 configuring None or MixedModeOriginateOnly for AreaExtendedLSASupport 1193 when Full is specified for ExtendedLSASupport is contradictory and 1194 MAY be prohibited by the implementation. 1196 Authors' Addresses 1198 Acee Lindem 1199 Cisco Systems 1200 301 Midenhall Way 1201 Cary, NC 27513 1202 USA 1204 Email: acee@cisco.com 1206 Sina Mirtorabi 1207 Cisco Systems 1208 170 Tasman Drive 1209 San Jose, CA 95134 1210 USA 1212 Email: sina@cisco.com 1214 Abhay Roy 1215 Cisco Systems 1216 170 Tasman Drive 1217 San Jose, CA 95134 1218 USA 1220 Email: akr@cisco.com 1222 Fred Baker 1223 Cisco Systems 1224 Santa Barbara, CA 93117 1225 USA 1227 Email: fred@cisco.com