idnits 2.17.00 (12 Aug 2021) /tmp/idnits31726/draft-ietf-ospf-ospfv3-lsa-extend-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 24, 2014) is 2735 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: May 28, 2015 F. Baker 6 Cisco Systems 7 November 24, 2014 9 OSPFv3 LSA Extendibility 10 draft-ietf-ospf-ospfv3-lsa-extend-05.txt 12 Abstract 14 OSPFv3 requires functional extension beyond what can readily be done 15 with the fixed-format Link State Advertisement (LSA) as described in 16 RFC 5340. Without LSA extension, attributes associated with OSPFv3 17 links and advertised IPv6 prefixes must be advertised in separate 18 LSAs and correlated to the fixed-format LSAs. This document extends 19 the LSA format by encoding the existing OSPFv3 LSA information in 20 Type-Length-Value (TLV) tuples and allowing advertisement of 21 additional information with additional TLVs. Backward compatibility 22 mechanisms are also described. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 28, 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 Thanks to Karsten Thomann for review and editorial comments. 158 The RFC text was produced using Marshall Rose's xml2rfc tool. 160 2. OSPFv3 Extended LSA Types 162 In order to provide backward compatibility, new LSA codes must be 163 allocated. There are eight fixed-format LSAs defined in RFC 5340 164 [OSPFV3]. For ease of implementation and debugging, the LSA function 165 codes are the same as the fixed-format LSAs only with 32, i.e., 0x20, 166 added. The alternative to this mapping was to allocate a bit in the 167 LS Type indicating the new LSA format. However, this would have used 168 one half the LSA function code space for the migration of the eight 169 original fixed-format LSAs. For backward compatibility, the U-bit 170 will be set in LS Type so that the LSAs will be flooded by OSPFv3 171 routers that do not understand them. 173 LSA function code LS Type Description 174 ---------------------------------------------------- 175 33 0xA021 E-Router-LSA 176 34 0xA022 E-Network-LSA 177 35 0xA023 E-Inter-Area-Prefix-LSA 178 36 0xA024 E-Inter-Area-Router-LSA 179 37 0xC025 E-AS-External-LSA 180 38 N/A Unused (Not to be allocated) 181 39 0xA027 E-Type-7-LSA 182 40 0x8028 E-Link-LSA 183 41 0xA029 E-Intra-Area-Prefix-LSA 185 OSPFv3 Extended LSA Types 187 3. OSPFv3 Extended LSA TLVs 189 The format of the TLVs within the body of the extended LSAs is the 190 same as the format used by the Traffic Engineering Extensions to OSPF 191 [TE]. The variable TLV section consists of one or more nested Type/ 192 Length/Value (TLV) tuples. Nested TLVs are also referred to as sub- 193 TLVs. The format of each TLV is: 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Type | Length | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Value... | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 TLV Format 205 The Length field defines the length of the value portion in octets 206 (thus a TLV with no value portion would have a length of 0). The TLV 207 is padded to 4-octet alignment; padding is not included in the length 208 field (so a 3-octet value would have a length of 3, but the total 209 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 210 aligned. For example, a 1-byte value would have the length field set 211 to 1, and 3 octets of padding would be added to the end of the value 212 portion of the TLV. 214 This document defines the following top-level TLV types: 216 o 0 - Reserved 218 o 1 - Router-Link TLV 220 o 2 - Attached-Routers TLV 222 o 3 - Inter-Area Prefix TLV 224 o 4 - Inter-Area Router TLV 226 o 5 - External Prefix TLV 228 o 6 - Intra-Area Prefix TLV 230 o 7 - IPv6 Link-Local Address TLV 231 o 8 - IPv4 Link-Local Address TLV 233 Additionally, this document defines the following sub-TLV types: 235 o 0 - Reserved 237 o 1 - IPv6 Forwarding Address sub-TLV 239 o 2 - IPv4 Forwarding Address sub-TLV 241 o 3 - Route Tag sub-TLV 243 In general, TLVs and sub-TLVs MAY occur in any order and the 244 specification should define whether the TLV or sub-TLV is required 245 and the behavior when there are multiple occurances of the TLV or 246 sub-TLVs. 248 3.1. Router-Link TLV 250 The Router-Link TLV defines a single router link and the field 251 definitions correspond directly to links in the OSPFv3 Router-LSA, 252 section A.4.3, [OSPFV3]. The Router-Link TLV is only applicable to 253 the E-Router-LSA (Section 4.1). Inclusion in other Extended LSAs 254 MUST be ignored. 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | 1 (Router-Link) | TLV Length | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Type | 0 | Metric | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Interface ID | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Neighbor Interface ID | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Neighbor Router ID | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 . . 270 . sub-TLVs . 271 . . 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Router-Link TLV 276 3.2. Attached-Routers TLV 278 The Attached-Routers TLV defines all the routers attached to an 279 OSPFv3 multi-access network. The field definitions correspond 280 directly to content of the OSPFv3 Network-LSA, section A.4.4, 281 [OSPFV3]. The Attached-Routers TLV is only applicable to the 282 E-Network-LSA (Section 4.2). Inclusion in other Extended LSAs MUST 283 be ignored. 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | 2 (Attached-Routers) | TLV Length | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Adjacent Neighbor Router ID | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 . . 293 . Additional Adjacent Neighbors . 294 . . 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Attached-Routers TLV 299 There are two reasons for not having a separate TLV or sub-TLV for 300 each adjacent neighbor. The first is to discourage using the 301 E-Network-LSA for more than its current role of solely advertising 302 the routers attached to a multi-access network. The router's metric 303 as well as the attributes of individual attached routers should be 304 advertised in their respective E-Router-LSAs. The second reason is 305 that there is only a single E-Network-LSA per multi-access link with 306 the Link State ID set to the Designated Router's Interface ID and, 307 consequently, compact encoding has been chosen to decrease the 308 likelihood that the size of the E-Network-LSA will require IPv6 309 fragmentation when advertised in an OSPFv3 Link State Update packet. 311 3.3. Inter-Area-Prefix TLV 313 The Inter-Area-Prefix TLV defines a single OSPFV3 inter-area prefix. 314 The field definitions correspond directly to the content of an OSPFv3 315 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 316 Inter-Area-Prefix-LSA, as defined in section A.4.5, [OSPFV3]. The 317 Inter-Area-Prefix TLV is only applicable to the E-Inter-Area-Prefix- 318 LSA (Section 4.3). Inclusion in other Extended LSAs MUST be ignored. 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | 3 (Inter-Area Prefix) | TLV Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | 0 | Metric | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | PrefixLength | PrefixOptions | 0 | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Address Prefix | 330 | ... | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 . . 333 . sub-TLVs . 334 . . 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Inter-Area Prefix TLV 339 3.4. Inter-Area-Router TLV 341 The Inter-Area-Router TLV defines a single OSPFv3 Autonomous System 342 Boundary Router (ASBR) reachable in another area. The field 343 definitions correspond directly to the content of an OSPFv3 Inter- 344 Area-Router-LSA, as defined in section A.4.6, [OSPFV3]. The Inter- 345 Area-Router TLV is only applicable to the E-Inter-Area-Router-LSA 346 (Section 4.4). Inclusion in other Extended LSAs MUST be ignored. 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | 4 (Inter-Area Router) | TLV Length | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | 0 | Options | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | 0 | Metric | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Destination Router ID | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 . . 360 . sub-TLVs . 361 . . 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Inter-Area Router TLV 366 3.5. External-Prefix TLV 368 The External-Prefix TLV defines a single OSPFv3 external prefix. The 369 field definitions correspond directly to the content of an OSPFv3 370 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 AS- 371 External-LSA, as defined in section A.4.7, [OSPFV3]. The External- 372 Prefix TLV is only applicable to the E-AS-External-LSA (Section 4.5) 373 and the E-NSSA-LSA (Section 4.6). Inclusion in other Extended LSAs 374 MUST be ignored. 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | 5 (External Prefix) | TLV Length | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | |E| | | Metric | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | PrefixLength | PrefixOptions | 0 | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Address Prefix | 386 | ... | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 . . 389 . sub-TLVs . 390 . . 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 External Prefix TLV 395 In the External-Prefix TLV, the optional IPv6/IPv4 Forwarding Address 396 and External Route Tag are now sub-TLVs. Given the Referenced LS 397 type and Referenced Link State ID from the AS-External-LSA have never 398 been used or even specified, they have been omitted from the External 399 Prefix TLV. If there were ever a requirement for a referenced LSA, 400 it could be satisfied with a sub-TLV. 402 The following sub-TLVs are defined for optional inclusion in the 403 External Prefix TLV: 405 o 1 - IPv6 Forwarding Address sub-TLV (Section 3.9) 407 o 2 - IPv4 Forwarding Address sub-TLV (Section 3.10) 409 o 3 - Route Tag sub-TLV (Section 3.11) 411 3.6. Intra-Area-Prefix TLV 413 The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix. 414 The field definitions correspond directly to the content of an OSPFv3 415 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 Link- 416 LSA, as defined in section A.4.9, [OSPFV3]. The Intra-Area-Prefix 417 TLV is only applicable to the E-Link-LSA (Section 4.7) and the 418 E-Intra-Area-Prefix-LSA (Section 4.8). Inclusion in other Extended 419 LSAs MUST be ignored. 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | 6 (Intra-Area Prefix) | TLV Length | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | 0 | Metric | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | PrefixLength | PrefixOptions | 0 | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Address Prefix | 431 | ... | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 . . 434 . sub-TLVs . 435 . . 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 Intra-Area Prefix TLV 440 3.7. IPv6 Link-Local Address TLV 442 The IPv6 Link-Local Address TLV is to be used with IPv6 address 443 families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV 444 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 445 other Extended LSAs MUST be ignored. 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | 7 (IPv6 Local-Local Address) | TLV Length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | | 453 +- -+ 454 | | 455 +- IPv6 Link-Local Interface Address -+ 456 | | 457 +- -+ 458 | | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 . . 461 . sub-TLVs . 462 . . 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 IPv6 Link-Local Address TLV 467 3.8. IPv4 Link-Local Address TLV 469 The IPv4 Link-Local Address TLV is to be used with IPv4 address 470 families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV 471 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 472 other Extended LSAs MUST be ignored. 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | 8 (IPv4 Local-Local Address) | TLV Length | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | IPv4 Link-Local Interface Address | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 . . 482 . sub-TLVs . 483 . . 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 IPv4 Link-Local Address TLV 488 3.9. IPv6-Forwarding-Address Sub-TLV 490 The IPv6 Forwarding Address TLV has identical semantics to the 491 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv6 492 Forwarding Address TLV is applicable to the External-Prefix TLV 493 (Section 3.5). Specification as a sub-TLV of other TLVs is not 494 defined herein. The sub-TLV is optional and the first specified 495 instance is used as the Forwarding Address as defined in [OSPFV3]. 496 Instances subsequent to the first MUST be ignored. 498 The IPv6 Forwarding Address TLV is to be used with IPv6 address 499 families as defined in [OSPFV3-AF] It MUST be ignored for other 500 address families. 502 0 1 2 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | 1 - Forwarding Address | sub-TLV Length | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | | 508 +- -+ 509 | | 510 +- Forwarding Address -+ 511 | | 512 +- -+ 513 | | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Forwarding Address Tag TLV 518 3.10. IPv4-Forwarding-Address Sub-TLV 520 The IPv4 Forwarding Address TLV has identical semantics to the 521 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv4 522 Forwarding Address TLV is The IPv4 Forwarding Address TLV is 523 applicable to the External-Prefix TLV (Section 3.5). Specification 524 as a sub-TLV of other TLVs is not defined herein. The sub-TLV is 525 optional and the first specified instance is used as the Forwarding 526 Address as defined in [OSPFV3]. Instances subsequent to the first 527 MUST be ignored. 529 The IPv4 Forwarding Address TLV is to be used with IPv3 address 530 families as defined in [OSPFV3-AF] It MUST be ignored for other 531 address families. 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | 2 - Forwarding Address | sub-TLV Length | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Forwarding Address | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 Forwarding Address Tag TLV 543 3.11. Route-Tag Sub-TLV 545 The optional Route Tag sub-TLV has identical semantics to the 546 optional External Route Tag in section A.4.7 of [OSPFV3]. The Route 547 Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.5). 548 Specification as a sub-TLV of other TLVs is not defined herein. The 549 sub-TLV is optional and the first specified instance is used as the 550 Route Tag as defined in [OSPFV3]. Instances subsequent to the first 551 MUST be ignored. 553 0 1 2 3 554 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 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | 3 - Route Tag | sub-TLV Length | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Route Tag | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Route Tag Sub-TLV 563 4. OSPFv3 Extended LSAs 565 This section specifies the OSPFv3 Extended LSA formats and encoding. 566 The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3 567 LSAs specifed in [OSPFV3]. 569 4.1. OSPFv3 E-Router-LSA 571 The E-Router-LSA has an LS Type of 0xA021 and has the same base 572 information content as the Router-LSA defined in section A.4.3 of 573 [OSPFV3]. However, unlike the existing Router-LSA, it is fully 574 extendable and represented as TLVs. 576 0 1 2 3 577 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 578 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | LS Age |1|0|1| 0x21 | 580 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Link State ID | 582 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Advertising Router | 584 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | LS Sequence Number | 586 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | LS Checksum | Length | 588 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | 0 |Nt|x|V|E|B| Options | 590 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 . . 592 . TLVs . 593 . . 594 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Extended Router-LSA 598 All LSA Header fields are the same as defined for the Router-LSA. 599 Initially, only the top-level Router-Link TLV Section 3.1 is 600 applicable and an E-Router-LSA may include multiple Router-Link TLVs. 601 Like the existing Router-LSA, the LSA length is used to determine the 602 end of the LSA including TLVs. 604 4.2. OSPFv3 E-Network-LSA 606 The E-Network-LSA has an LS Type of 0xA022 and has the same base 607 information content as the Network-LSA defined in section A.4.4 of 608 [OSPFV3]. However, unlike the existing Network-LSA, it is fully 609 extendable and represented as TLVs. 611 0 1 2 3 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | LS Age |1|0|1| 0x22 | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Link State ID | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Advertising Router | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | LS Sequence Number | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | LS Checksum | Length | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | 0 | Options | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 . . 627 . TLVs . 628 . . 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 E-Network-LSA 633 All LSA Header fields are the same as defined for the Network-LSA. 634 Like the existing Network-LSA, the LSA length is used to determine 635 the end of the LSA including TLVs. Initially, only the top-level 636 Attached-Routers TLV Section 3.2 is applicable. If the Attached- 637 Router TLV is not included in the E-Network-LSA, it is treated as 638 malformed as described in Section 5. Instances of the Attached- 639 Router TLV subsequent to the first MUST be ignored. 641 4.3. OSPFv3 E-Inter-Area-Prefix-LSA 643 The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same 644 base information content as the Inter-Area-Prefix-LSA defined in 645 section A.4.5 of [OSPFV3]. However, unlike the existing Inter-Area- 646 Prefix-LSA, it is fully extendable and represented as TLVs. 648 0 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | LS Age |1|0|1| 0x23 | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Link State ID | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Advertising Router | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | LS Sequence Number | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | LS Checksum | Length | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 . . 662 . TLVs . 663 . . 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 E-Inter-Area-Prefix-LSA 668 All LSA Header fields are the same as defined for the Inter-Area- 669 Prefix-LSA. In order to retain compatibility and semantics with the 670 current OSPFv3 specification, each Inter-Area-Prefix LSA MUST contain 671 a single Inter-Area Prefix TLV. This will facilitate migration and 672 avoid changes to functions such as incremental SPF computation. 674 Like the existing Inter-Area-Prefix-LSA, the LSA length is used to 675 determine the end of the LSA including TLV. Initially, only the top- 676 level Inter-Area-Prefix TLV (Section 3.3) is applicable. If the 677 Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA, 678 it is treated as malformed as described in Section 5. Instances of 679 the Inter-Area-Prefix TLV subsequent to the first MUST be ignored. 681 4.4. OSPFv3 E-Inter-Area-Router-LSA 683 The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same 684 base information content as the Inter-Area-Router-LSAE defined in 685 section A.4.6 of [OSPFV3]. However, unlike the Inter-Area-Router- 686 LSA, it is fully extendable and represented as TLVs. 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | LS Age |1|0|1| 0x24 | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Link State ID | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Advertising Router | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | LS Sequence Number | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | LS Checksum | Length | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 . . 702 . TLVs . 703 . . 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 E-Inter-Area-Router-LSA 708 All LSA Header fields are the same as defined for the Inter-Area- 709 Router-LSA. In order to retain compatibility and semantics with the 710 current OSPFv3 specification, each Inter-Area-Router LSA MUST contain 711 a single Inter-Area Router TLV. This will facilitate migration and 712 avoid changes to functions such as incremental SPF computation. 714 Like the existing Inter-Area-Router-LSA, the LSA length is used to 715 determine the end of the LSA including TLV. Initially, only the top- 716 level Inter-Area-Router TLV (Section 3.4) is applicable. If the 717 Inter-Area-Router TLV is not included in the E-Inter-Area-Router-LSA, 718 it is treated as malformed as described in Section 5. Instances of 719 the Inter-Area-Router TLV subsequent to the first MUST be ignored. 721 4.5. OSPFv3 E-AS-External-LSA 723 The E-AS-External-LSA has an LS Type of 0xC025 and has the same base 724 information content as the AS-External-LSA defined in section A.4.7 725 of [OSPFV3]. However, unlike the existing AS-External-LSA, it is 726 fully extendable and represented as TLVs. 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | LS Age |1|1|0| 0x25 | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Link State ID | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Advertising Router | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | LS Sequence Number | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | LS Checksum | Length | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 . . 742 . TLVs . 743 . . 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 E-AS-External-LSA 748 All LSA Header fields are the same as defined for the AS-External- 749 LSA. In order to retain compatibility and semantics with the current 750 OSPFv3 specification, each LSA MUST contain a single External Prefix 751 TLV. This will facilitate migration and avoid changes to OSPFv3 752 processes such as incremental SPF computation. 754 Like the existing AS-External-LSA, the LSA length is used to 755 determine the end of the LSA including sub-TLVs. Initially, only the 756 top-level External-Prefix TLV (Section 3.5) is applicable. If the 757 External-Prefix TLV is not included in the E-External-AS-LSA, it is 758 treated as malformed as described in Section 5. Instances of the 759 External-Prefix TLV subsequent to the first MUST be ignored. 761 4.6. OSPFv3 E-NSSA-LSA 763 The E-NSSA-LSA will have the same format and TLVs as the Extended AS- 764 External-LSA Section 4.5. This is the same relationship as exists 765 between the NSSA-LSA defined in section A.4.8 of [OSPFV3], and the 766 AS-External-LSA. The NSSA-LSA will have type 0xA027 which implies 767 area flooding scope. Future requirements may dictate that supported 768 TLVs differ between the E-AS-External-LSA and the E-NSSA-LSA. 769 However, future requirements are beyond the scope of this document. 771 4.7. OSPFv3 E-Link-LSA 773 The E-Link-LSA has an LS Type of 0x8028 and will have the same base 774 information content as the Link-LSA defined in section A.4.9 of 775 [OSPFV3]. However, unlike the existing Link-LSA, it is extendable 776 and represented as TLVs. 778 0 1 2 3 779 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 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | LS Age |1|0|0| 0x28 | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Link State ID | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Advertising Router | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | LS Sequence Number | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | LS Checksum | Length | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Rtr Priority | Options | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 . . 794 . TLVs . 795 . . 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 E-Link-LSA 800 All LSA Header fields are the same as defined for the Link-LSA. 802 Only the Intra-Area-Prefix TLV (Section 3.6), IPv6 Link-Local Address 803 TLV (Section 3.7), and IPv4 Link-Local Address TLV (Section 3.8) are 804 applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA 805 affords advertisement of multiple intra-area prefixes. Hence, 806 multiple Intra-Area Prefix TLVs (Section 3.6) may be specified and 807 the LSA length defines the end of the LSA including all TLVs. 809 A single instance of the IPv6 Link-Local Address TLV (Section 3.7) 810 SHOULD be included in the E-Link-LSA. Instances following the first 811 MUST be ignored. For IPv4 address families as defined in 812 [OSPFV3-AF], this TLV MUST be ignored. 814 Similarly, only a single instance of the IPv4 Link-Local Address TLV 815 (Section 3.8) SHOULD be included in the E-Link-LSA. Instances 816 following the first MUST be ignored. For OSPFv3 IPv6 address 817 families as defined in [OSPFV3-AF], this TLV MUST be ignored. 819 If the IPv4/IPv6 Link-Local Address TLV corresponding to the OSPFv3 820 Address Family is not included in the E-Link-LSA, it is treated as 821 malformed as described in Section 5. 823 Future specifications may support advertisement of routing and 824 topology information for multiple address families. However, this is 825 beyond the scope of this document. 827 4.8. OSPFv3 E-Intra-Area-Prefix-LSA 829 The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same 830 base information content as the Intra-Area-Prefix-LSA defined in 831 section A.4.10 of [OSPFV3]. However, unlike the Intra-Area-Prefix- 832 LSA, it is fully extendable and represented as TLVs. 834 0 1 2 3 835 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 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | LS Age |1|0|1| 0x29 | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Link State ID | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Advertising Router | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | LS Sequence Number | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | LS Checksum | Length | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | 0 | Referenced LS Type | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Referenced Link State ID | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Referenced Advertising Router | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 . . 854 . TLVs . 855 . . 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 E-Intra-Area-Prefix-LSA 860 All LSA Header fields are the same as defined for the Intra-Area- 861 Prefix-LSA. 863 Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords 864 advertisement of multiple intra-area prefixes. Hence, multiple 865 Intra-Area Prefix TLVs may be specified and the LSA length defines 866 the end of the LSA including all TLVs. 868 5. Malformed OSPFv3 Extended LSA Handling 870 Extended LSAs that have inconsistent length or other encoding errors, 871 as described herein, MUST NOT be installed in the Link State 872 Database, acknowledged, or flooded. Reception of malformed LSAs 873 SHOULD be counted and/or logged for examination by the administrator 874 of the OSPFv3 Routing Domain. 876 6. LSA Extension Backward Compatibility 878 In the context of this document, backward compatibility is solely 879 related to the capability of an OSPFv3 router to receive, process, 880 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 881 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 882 extensions utilizing the TLV-based LSAs is out of scope and must be 883 covered in the documents describing those extensions. Both full and, 884 if applicable, partial deployment SHOULD be specified for future TLV- 885 based OSPFv3 LSA extensions. 887 Two distinct backward compatibility modes are supported dependent on 888 the OSPFv3 routing domain migration requirements. For simplicity and 889 to avoid the scaling impact of maintaining both TLV and non-TLV based 890 versions of the same LSA within a routing domain, the basic backward 891 compatibility mode will not allow mixing of LSA formats. Different 892 LSA formats could still be supported with multiple OSPFv3 instances 893 and separate OSPFv3 routing domains. Additionally, a more flexible 894 mode is provided in Section 6.1, where both formats of LSA coexist. 895 In order to facilitate backward compatibility, the OSPFv3 options 896 field (as described in Appendix A.2 of RFC 5340 [OSPFV3]), will 897 contain two additional options bits. The EL-bits will be used to 898 indicate that the OSPFv3 router's level of Extended LSA support. An 899 OSPFv3 router configured to support extended LSAs MUST set its 900 options field EL-bits in OSPFv3 Hello and Database Description 901 packets as follows: 903 B'00' 904 None - Extended LSAs are not originate nor used in the SPF 905 calculation. 907 B'01' 908 MixedModeOriginateOnly - Both extended and non-extended LSAs are 909 originated. Non-extended LSAs are used in the SPF computation. 911 B'10' 912 MixedModeOriginateSPF - Both extended and non-extended LSAs are 913 originated. Extended LSAs are used in the SPF computation. 915 B'11' 916 Full - Only extended LSAs are originated and used in the SPF 917 computation. 919 If Full is specified for ExtendedLSASupport, the OSPFv3 router MUST 920 NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and 921 Database Description packets with the options field EL-bits set to 922 MixedModeOriginateOnly or None. Similarly, if MixModeOriginateSPF is 923 specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form 924 adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database 925 Description packets with the options field EL-bits set to None 926 (B'00'). In this manner, OSPFv3 routers using new encodings can be 927 completely isolated from those OSPFv3 routers depending on the RFC 928 5340 encoding and not setting their options field EL-bits since the 929 default setting indicates no support for extended LSAs. 931 1 2 932 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 934 | | | | | | | | | | | | EL|AT|L|AF|*|*|DC|R|N|x|E|V6| 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 936 The Options field 938 EL-bits 939 These bits indicate the level of Extended LSA support. 940 B'00' - Extended LSAs are not originate nor used in the 941 SPF calculation. 942 B'01' - Both extended and non-extended LSAs are originated. 943 Non-extended LSAs are used in the SPF computation. 944 B'10' - Both extended and non-extended LSAs are originated. 945 Extended LSAs are used in the SPF computation. 946 B'11' - Only extended LSA are originated and used in the 947 SPF computation. 949 Options Field EL-bits 951 The EL-bits will also be set in the LSA options field in Extended and 952 Non-Extended LSAs. While the value of the EL-bits has no functional 953 significance in the LSA options field, visibility of every OSPFv3 954 Router's extended LSA support is expected to be very useful for 955 management and troubleshooting during the migration period. 957 6.1. Extended LSA Mixed-Mode Backward Compatibility 959 An implementation MAY support configuration allowing a graceful 960 transition from the non-extended (non-TLV-based) LSAs to the extended 961 (TLV-based) LSAs in an OSPFv3 routing domain. In these routing 962 domains, the OSPFv3 routers configured with a value of 963 MixedModeOriginateOnly or MixedModeOriginateSPF for 964 ExtendedLSASupport, (Appendix A), MUST originate both the extended 965 and non-extended versions of the OSPFv3 LSAs described herein. For 966 the purposes of Shortest Path First (SPF) computation, the non- 967 extended OSPFv3 LSAs are used for SPF computation when 968 MixedModeOriginateOnly is configured and the extended LSAs are used 969 when MixedModeOriginateSPF is specified. The extended LSAs MAY be 970 used for functions other than routing computation as long as backward 971 compatibility is specified in the documents specifying those 972 functions. 974 In this manner, OSPFv3 routing domains utilizing the new encodings 975 can be gradually migrated with a worst-case overhead cost of 976 approximately doubling the number of LSAs in the routing domain. The 977 transition within an OSPFv3 routing domain would progress as follows: 979 1. Configure OSPFv3 Router ExtendedLSASupport to 980 MixedModeOriginateOnly so that routers originate the extended 981 LSAs. 983 2. When all the OSPFv3 Routers have been reconfigured to 984 MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to 985 use the extended LSAs by configuring ExtendedLSASupport to 986 MixedModeOriginateSPF. This can be done on a small subset of 987 OSPFv3 Routers and the route tables can be verified. 989 3. When all the OSPFv3 Routers have been reconfigured to 990 MixedModeOriginateSPF and the routing has been verified, 991 reconfigure OSPFv3 Routers to purge or simply not refresh the 992 non-extended OSPFv3 LSA by configuring ExtendedLSASupport to 993 Full. 995 In order to prevent OSPFv3 routing domain routing loops, the 996 advertised metrics in the extended and non-extended OSPFv3 LSAs MUST 997 be identical. 999 6.1.1. Area Extended LSA Mixed-Mode Backward Compatibility 1001 An implementation MAY also support configuration allowing graceful 1002 transition from the non-extended LSAs to the extended LSAs within a 1003 single area. In these areas, the parameter AreaExtendedLSASupport 1004 (Appendix B) may be configured to take precedence over the global 1005 parameter ExtendedLSASupport. However, the AreaExtendedLSASupport 1006 will only apply to link and area scoped LSAs within the area and area 1007 based SPF calculations. The default is for the 1008 AreaExtendedLSASupport to be inherited from the ExtendedLSASupport. 1009 The configuration of ExtendedLSASupport will apply to AS-External 1010 LSAs even when AreaExtendedLSASupport takes precedence. 1012 When preforming a graceful restart [GRACEFUL-RESTART], an OSPFv3 1013 router configured with MixedModeOriginate will use the non-extended 1014 OSPFv3 LSAs to determine whether or not the graceful restart has 1015 completed successfully. Similarly, an OSPFv3 router configured with 1016 MixedModeOriginateSPF will use the extended LSAs. In other words, 1017 successful OSPFv3 graceful restart determination will follow the SPF 1018 calculation. 1020 6.2. LSA TLV Processing Backward Compatibility 1022 This section defines the general rules for processing LSA TLVs. To 1023 ensure compatibility of future TLV-based LSA extensions, all 1024 implementations MUST adhere to these rules: 1026 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or 1027 processing Extended-LSAs. 1029 2. Whether or not partial deployment of a given TLV is supported 1030 MUST be specified. 1032 3. If partial deployment is not supported, mechanisms to ensure the 1033 corresponding feature are not deployed MUST be specified in the 1034 document defining the new TLV or sub-TLV. 1036 4. If partial deployment is supported, backward compatibility and 1037 partial deployment MUST be specified in the document defining the 1038 new TLV or sub-TLV. 1040 7. Security Considerations 1042 In general, extendible OSPFv3 LSAs are subject to the same security 1043 concerns as those described in RFC 5340 [OSPFV3]. Additionally, 1044 implementations must assure that malformed TLV and sub-TLV 1045 permutations do not result in errors that cause hard OSPFv3 failures. 1047 If there were ever a requirement to digitally sign OSPFv3 LSAs as 1048 described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the 1049 mechanisms described herein would greatly simplify the extension. 1051 8. IANA Considerations 1053 This specification defines nine OSPFv3 Extended LSA types as 1054 described in Section 2. 1056 This specification also creates two registries OSPFv3 Extended-LSAs 1057 TLVs and sub-TLVs. The TLV and sub-TLV code-points in these 1058 registries are common to all Extended-LSAs and their respective 1059 definitions must define where they are applicable. 1061 The OSPFv3 Extend-LSA TLV registry will define top-level TLVs for 1062 Extended-LSAs and should be placed in the existing OSPFv3 IANA 1063 registry. New values can be allocated via IETF Consensus or IESG 1064 Approval. 1066 Nine values are allocated by this specification: 1068 o 0 - Reserved 1070 o 1 - Router-Link TLV 1072 o 2 - Attached-Routers TLV 1074 o 3 - Inter-Area Prefix TLV 1076 o 4 - Inter-Area Router TLV 1078 o 5 - External Prefix TLV 1080 o 6 - Intra-Area Prefix TLV 1082 o 7 - IPv6 Link-Local Address TLV 1084 o 8 - IPv4 Link-Local Address TLV 1086 The OSPFv3 Extend-LSA sub-TLV registry will define sub-TLVs at any 1087 level of nesting for Extended-LSAs and should be placed in the 1088 existing OSPFv3 IANA registry. New values can be allocated via IETF 1089 Consensus or IESG Approval. 1091 Three values are allocated by this specification: 1093 o 0 - Reserved 1095 o 1 - Forwarding Address 1097 o 2 - Route Tag 1099 9. References 1101 9.1. Normative References 1103 [GRACEFUL-RESTART] 1104 Lindem, A. and P. Pillay-Esnault, "OSPFv3 Graceful 1105 Restart", RFC 5178, June 2008. 1107 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1108 for IPv6", RFC 5340, July 2008. 1110 [OSPFV3-AF] 1111 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 1112 Aggarwal, "Support of Address Families in OSPFv3", 1113 RFC 5838, April 2010. 1115 [RFC-KEYWORDS] 1116 Bradner, S., "Key words for use in RFCs to Indicate 1117 Requirement Levels", RFC 2119, March 1997. 1119 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 1120 Extensions to OSPF", RFC 3630, September 2003. 1122 9.2. Informative References 1124 [MT-OSPFV3] 1125 Mirtorabi, S. and A. Roy, "Multi-topology routing in 1126 OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt 1127 (work in progress). 1129 [OSPF-DIGITAL-SIGNATURE] 1130 Murphy, S., Badger, M., and B. Wellington, "OSPF with 1131 Digital Signatures", RFC 2154, June 1997. 1133 Appendix A. Global Configuration Parameters 1135 An additional global configurable parameter will be added to the 1136 OSPFv3 protocol. 1138 ExtendedLSASupport 1139 This is an enumeration type indicating the extent to which the 1140 OSPFv3 instance supports the TLV format described herein for 1141 Extended LSAs. The valid values for the enumeration are: 1143 * None - Extended LSAs will not be originated or used in the SPF 1144 calculation. This is the default. 1146 * MixedModeOriginateOnly - Both extended and non-extended LSAs 1147 will be originated. OSPFv3 adjacencies will be formed with 1148 OSPFv3 routers not supporting this specification. The non- 1149 extended LSAs are used for the SPF computation. 1151 * MixedModeOriginateSPF - Both extended and non-extended LSAs 1152 will be originated. OSPFv3 adjacencies will be formed with 1153 OSPFv3 routers not supporting this specification. The extended 1154 LSAs are used for the SPF computation. 1156 * Full - Extended LSAs will be originated and adjacencies will 1157 not be formed with OSPFv3 routers not supporting this 1158 specification. Only Extended LSAs will be originated. 1160 Appendix B. Area Configuration Parameters 1162 An additional area configurable parameter will be added to the OSPFv3 1163 protocol. 1165 AreaExtendedLSASupport 1166 This is an enumeration type indicating the extent to which the 1167 OSPFv3 area supports the TLV format described herein for Extended 1168 LSAs. The valid value for the enumeration are: 1170 * InheritGlobal - The AreaExtendedLSASupport will be inherited 1171 from ExtendedLSASupport. This is the default. 1173 * None - Non-extended LSAs will not be originated or used in the 1174 SPF calculation. 1176 * MixedModeOriginateOnly - Both extended and non-extended link 1177 and area scoped LSAs will be originated. OSPFv3 adjacencies 1178 will be formed with OSPFv3 routers not supporting this 1179 specification. The non-extended LSAs are used for the SPF 1180 computation. 1182 * MixedModeOriginateSPF - Both extended and non-extended link and 1183 area scoped LSAs will be originated. OSPFv3 adjacencies will 1184 be formed with OSPFv3 routers not supporting this 1185 specification. The extended LSAs are used for the area SPF 1186 computation. 1188 * Full - Link and area scoped extended LSAs will be originated 1189 and adjacencies will not be formed with OSPFv3 routers not 1190 supporting this specification. Only Extended LSAs will be 1191 originated. 1193 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1194 configuring None or MixedModeOriginateOnly for AreaExtendedLSASupport 1195 when Full is specified for ExtendedLSASupport is contradictory and 1196 MAY be prohibited by the implementation. 1198 Authors' Addresses 1200 Acee Lindem 1201 Cisco Systems 1202 301 Midenhall Way 1203 Cary, NC 27513 1204 USA 1206 Email: acee@cisco.com 1208 Sina Mirtorabi 1209 Cisco Systems 1210 170 Tasman Drive 1211 San Jose, CA 95134 1212 USA 1214 Email: sina@cisco.com 1216 Abhay Roy 1217 Cisco Systems 1218 170 Tasman Drive 1219 San Jose, CA 95134 1220 USA 1222 Email: akr@cisco.com 1224 Fred Baker 1225 Cisco Systems 1226 Santa Barbara, CA 93117 1227 USA 1229 Email: fred@cisco.com