idnits 2.17.00 (12 Aug 2021) /tmp/idnits32193/draft-ietf-ospf-ospfv3-lsa-extend-03.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 29, 2014) is 2914 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 (~~), 2 warnings (==), 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 Ericsson 4 Intended status: Standards Track S. Mirtorabi 5 Expires: November 30, 2014 A. Roy 6 F. Baker 7 Cisco Systems 8 May 29, 2014 10 OSPFv3 LSA Extendibility 11 draft-ietf-ospf-ospfv3-lsa-extend-03.txt 13 Abstract 15 OSPFv3 requires functional extension beyond what can readily be done 16 with the fixed-format Link State Advertisement (LSA) as described in 17 RFC 5340. Without LSA extension, attributes associated with OSPFv3 18 links and advertised IPv6 prefixes must be advertised in separate 19 LSAs and correlated to the fixed-format LSAs. This document extends 20 the LSA format by encoding the existing OSPFv3 LSA information in 21 Type-Length-Value (TLV) tuples and allowing advertisement of 22 additional information with additional TLVs. Backward compatibility 23 mechanisms are also described. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 30, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 73 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 74 2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 6 75 3. OSPFv3 Extended LSA TLVs . . . . . . . . . . . . . . . . . . . 7 76 3.1. Router-Link TLVs . . . . . . . . . . . . . . . . . . . . . 8 77 3.2. Attached-Routers TLV . . . . . . . . . . . . . . . . . . . 9 78 3.3. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 10 79 3.4. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 11 80 3.5. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 12 81 3.6. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 13 82 3.7. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 14 83 3.8. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 15 84 3.9. Forwarding-Address Sub-TLV . . . . . . . . . . . . . . . . 16 85 3.10. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 16 86 4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . . 17 87 4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 17 88 4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . . 18 89 4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . . 19 90 4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . . 20 91 4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . . 21 92 4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 22 93 4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 23 94 4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . . 25 95 5. LSA Extension Backward Compatibility . . . . . . . . . . . . . 26 96 5.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . . 27 97 5.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 28 98 5.2. LSA TLV Processing Backward Compatibility . . . . . . . . 28 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 101 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 102 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 103 8.2. Informative References . . . . . . . . . . . . . . . . . . 32 104 Appendix A. Global Configuration Parameters . . . . . . . . . . . 33 105 Appendix B. Area Configuration Parameters . . . . . . . . . . . . 34 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 108 1. Introduction 110 OSPFv3 requires functional extension beyond what can readily be done 111 with the fixed-format Link State Advertisement (LSA) as described in 112 RFC 5340 [OSPFV3]. Without LSA extension, attributes associated with 113 OSPFv3 links and advertised IPv6 prefixes must be advertised in 114 separate LSAs and correlated to the fixed-format LSAs. This document 115 extends the LSA format by encoding the existing OSPFv3 LSA 116 information in Type-Length-Value (TLV) tuples and allowing 117 advertisement of additional information with additional TLVs. 118 Backward compatibility mechanisms are also described. 120 A similar extension was previously proposed in support of multi- 121 topology routing. Additional requirements for OSPFv3 LSA extension 122 include source/destination routing, route tagging, and others. 124 A final requirement is to limit the changes to OSPFv3 to those 125 necessary for TLV-based LSAs. For the most part, the semantics of 126 existing OSPFv3 LSAs are retained for their TLV-based successor LSAs 127 described herein. Additionally, encoding details, e.g., the 128 representation of IPv6 prefixes as described in section A.4.1 in RFC 129 5340 [OSPFV3], have been retained. This requirement was included to 130 increase the expedience of IETF adoption and deployment. 132 The following aspects of OSPFv3 LSA extension are described: 134 1. Extended LSA Types 136 2. Extended LSA TLVs 138 3. Extended LSA Formats 140 4. Backward Compatibility 142 1.1. Requirements notation 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC-KEYWORDS]. 148 1.2. Acknowledgments 150 OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing 151 in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3]. 153 Thanks for Peter Psenak for significant contributions to the backward 154 compatibility mechanisms. 156 Thanks go to Michael Barnes, Mike Dubrovsky, Anton Smirnov, and Tony 157 Przygienda for review of the draft versions and discussions of 158 backward compatibility. 160 Thanks to Alan Davey for review and comments including the suggestion 161 to separate the extended LSA TLV definitions from the extended LSAs 162 definitions. 164 Thanks to David Lamparter for review and suggestions on backward 165 compatibility. 167 The RFC text was produced using Marshall Rose's xml2rfc tool. 169 2. OSPFv3 Extended LSA Types 171 In order to provide backward compatibility, new LSA codes must be 172 allocated. There are eight fixed-format LSAs defined in RFC 5340 173 [OSPFV3]. For ease of implementation and debugging, the LSA function 174 codes are the same as the fixed-format LSAs only with 32, i.e., 0x20, 175 added. The alternative to this mapping was to allocate a bit in the 176 LS Type indicating the new LSA format. However, this would have used 177 one half the LSA function code space for the migration of the eight 178 original fixed-format LSAs. For backward compatibility, the U-bit 179 will be set in LS Type so that the LSAs will be flooded by OSPFv3 180 routers that do not understand them. 182 LSA function code LS Type Description 183 ---------------------------------------------------- 184 33 0xA021 E-Router-LSA 185 34 0xA022 E-Network-LSA 186 35 0xA023 E-Inter-Area-Prefix-LSA 187 36 0xA024 E-Inter-Area-Router-LSA 188 37 0xC025 E-AS-External-LSA 189 38 N/A Unused (Not to be allocated) 190 39 0xA027 E-Type-7-LSA 191 40 0x8028 E-Link-LSA 192 41 0xA029 E-Intra-Area-Prefix-LSA 194 OSPFv3 Extended LSA Types 196 3. OSPFv3 Extended LSA TLVs 198 The format of the TLVs within the body of the extended LSAs is the 199 same as the format used by the Traffic Engineering Extensions to OSPF 200 [TE]. The variable TLV section consists of one or more nested Type/ 201 Length/Value (TLV) tuples. Nested TLVs are also referred to as sub- 202 TLVs. The format of each TLV is: 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Type | Length | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Value... | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 TLV Format 214 The Length field defines the length of the value portion in octets 215 (thus a TLV with no value portion would have a length of 0). The TLV 216 is padded to 4-octet alignment; padding is not included in the length 217 field (so a 3-octet value would have a length of 3, but the total 218 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 219 aligned. For example, a 1-byte value would have the length field set 220 to 1, and 3 octets of padding would be added to the end of the value 221 portion of the TLV. 223 This document defines the following top-level TLV types: 225 o 0 - Reserved 227 o 1 - Router-Link TLV 229 o 2 - Attached-Routers TLV 231 o 3 - Inter-Area Prefix TLV 233 o 4 - Inter-Area Router TLV 235 o 5 - External Prefix TLV 237 o 6 - Intra-Area Prefix TLV 239 o 7 - IPv6 Link-Local Address TLV 240 o 8 - IPv4 Link-Local Address TLV 242 Additionally, this document defines the following sub-TLV types: 244 o 0 - Reserved 246 o 1 - Forwarding Address sub-TLV 248 o 2 - Route Tag sub-TLV 250 In general, TLVs and sub-TLVs MAY occur in any order and the 251 specification should define whether the TLV or sub-TLV is required 252 and the behavior when there are multiple occurances of the TLV or 253 sub-TLVs. 255 3.1. Router-Link TLVs 257 The Router-Link TLV defines a single router link and the field 258 definitions correspond directly to links in the OSPFv3 Router-LSA, 259 section A.4.3, [OSPFV3]. The Router-Link TLV is only applicable to 260 the E-Router-LSA (Section 4.1). Inclusion in other Extended LSAs 261 MUST be ignored. 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | 1 (Router-Link) | TLV Length | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Type | 0 | Metric | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Interface ID | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Neighbor Interface ID | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Neighbor Router ID | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 . . 277 . sub-TLVs . 278 . . 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Router-Link TLV 283 3.2. Attached-Routers TLV 285 The Attached-Routers TLV defines all the routers attached to an 286 OSPFv3 multi-access network. The field definitions correspond 287 directly to content of the OSPFv3 Network-LSA, section A.4.4, 288 [OSPFV3]. The Attached-Routers TLV is only applicable to the 289 E-Network-LSA (Section 4.2). Inclusion in other Extended LSAs MUST 290 be ignored. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | 2 (Attached-Routers) | TLV Length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Adjacent Neighbor Router ID | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 . . 300 . Additional Adjacent Neighbors . 301 . . 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Attached-Routers TLV 306 There are two reasons for not having a separate TLV or sub-TLV for 307 each adjacent neighbor. The first is to discourage using the 308 E-Network-LSA for more than its current role of solely advertising 309 the routers attached to a multi-access network. The router's metric 310 as well as the attributes of individual attached routers should be 311 advertised in their respective E-Router-LSAs. The second reason is 312 that there is only a single E-Network-LSA per multi-access link with 313 the Link State ID set to the Designated Router's Interface ID and, 314 consequently, compact encoding has been chosen to decrease the 315 likelihood that the size of the E-Network-LSA will require IPv6 316 fragmentation when advertised in an OSPFv3 Link State Update packet. 318 3.3. Inter-Area-Prefix TLV 320 The Inter-Area-Prefix TLV defines a single OSPFV3 inter-area prefix. 321 The field definitions correspond directly to the content of an OSPFv3 322 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 323 Inter-Area-Prefix-LSA, as defined in section A.4.5, [OSPFV3]. The 324 Inter-Area-Prefix TLV is only applicable to the E-Inter-Area-Prefix- 325 LSA (Section 4.3). Inclusion in other Extended LSAs MUST be ignored. 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | 3 (Inter-Area Prefix) | TLV Length | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | 0 | Metric | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | PrefixLength | PrefixOptions | 0 | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Address Prefix | 337 | ... | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 . . 340 . sub-TLVs . 341 . . 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Inter-Area Prefix TLV 346 3.4. Inter-Area-Router TLV 348 The Inter-Area-Router TLV defines a single OSPFv3 Autonomous System 349 Boundary Router (ASBR) reachable in another area. The field 350 definitions correspond directly to the content of an OSPFv3 Inter- 351 Area-Router-LSA, as defined in section A.4.6, [OSPFV3]. The Inter- 352 Area-Router TLV is only applicable to the E-Inter-Area-Router-LSA 353 (Section 4.4). Inclusion in other Extended LSAs MUST be ignored. 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | 4 (Inter-Area Router) | TLV Length | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | 0 | Options | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | 0 | Metric | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Destination Router ID | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 . . 367 . sub-TLVs . 368 . . 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Inter-Area Router TLV 373 3.5. External-Prefix TLV 375 The External-Prefix TLV defines a single OSPFv3 external prefix. The 376 field definitions correspond directly to the content of an OSPFv3 377 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 AS- 378 External-LSA, as defined in section A.4.7, [OSPFV3]. The External- 379 Prefix TLV is only applicable to the E-AS-External-LSA (Section 4.5) 380 and the E-NSSA-LSA (Section 4.6). Inclusion in other Extended LSAs 381 MUST be ignored. 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | 5 (External Prefix) | TLV Length | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | |E| | | Metric | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | PrefixLength | PrefixOptions | 0 | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Address Prefix | 393 | ... | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 . . 396 . sub-TLVs . 397 . . 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 External Prefix TLV 402 In the External-Prefix TLV, the optional Forwarding Address and 403 External Route Tag are now sub-TLVs. Given the Referenced LS type 404 and Referenced Link State ID from the AS-External-LSA have never been 405 used or even specified, they have been omitted from the External 406 Prefix TLV. If there were ever a requirement for a referenced LSA, 407 it could be satisfied with a sub-TLV. 409 The following sub-TLVs are defined for optional inclusion in the 410 External Prefix TLV: 412 o 1 - Forwarding Address sub-TLV (Section 3.9) 414 o 2 - Route Tag sub-TLV (Section 3.10) 416 3.6. Intra-Area-Prefix TLV 418 The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix. 419 The field definitions correspond directly to the content of an OSPFv3 420 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 Link- 421 LSA, as defined in section A.4.9, [OSPFV3]. The Intra-Area-Prefix 422 TLV is only applicable to the E-Link-LSA (Section 4.7) and the 423 E-Intra-Area-Prefix-LSA (Section 4.8). Inclusion in other Extended 424 LSAs MUST be ignored. 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | 6 (Intra-Area Prefix) | TLV Length | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | 0 | Metric | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | PrefixLength | PrefixOptions | 0 | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Address Prefix | 436 | ... | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 . . 439 . sub-TLVs . 440 . . 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Intra-Area Prefix TLV 445 3.7. IPv6 Link-Local Address TLV 447 The IPv6 Link-Local Address TLV is to be used with IPv6 address 448 families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV 449 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 450 other Extended LSAs MUST be ignored. 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | 7 (IPv6 Local-Local Address) | TLV Length | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | | 458 +- -+ 459 | | 460 +- IPv6 Link-Local Interface Address -+ 461 | | 462 +- -+ 463 | | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 . . 466 . sub-TLVs . 467 . . 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 IPv6 Link-Local Address TLV 472 3.8. IPv4 Link-Local Address TLV 474 The IPv4 Link-Local Address TLV is to be used with IPv4 address 475 families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV 476 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 477 other Extended LSAs MUST be ignored. 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | 8 (IPv4 Local-Local Address) | TLV Length | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | IPv4 Link-Local Interface Address | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 . . 487 . sub-TLVs . 488 . . 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 IPv4 Link-Local Address TLV 493 3.9. Forwarding-Address Sub-TLV 495 The Forwarding Address TLV has identical semantics to the optional 496 forwarding address in section A.4.7 of [OSPFV3]. The Forwarding 497 Address TLV is applicable to the External-Prefix TLV (Section 3.5). 498 Specification as a sub-TLV of other TLVs is not defined herein. The 499 sub-TLV is optional and the first specified instance is used as the 500 Forwarding Address as defined in [OSPFV3]. Instances subsequent to 501 the first are ignored. 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | 1 - Forwarding Address | sub-TLV Length | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | | 509 +- -+ 510 | | 511 +- Forwarding Address -+ 512 | | 513 +- -+ 514 | | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 Forwarding Address Tag TLV 519 3.10. Route-Tag Sub-TLV 521 The optional Route Tag sub-TLV has identical semantics to the 522 optional External Route Tag in section A.4.7 of [OSPFV3]. The Route 523 Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.5). 524 Specification as a sub-TLV of other TLVs is not defined herein. The 525 sub-TLV is optional and the first specified instance is used as the 526 Route Tag as defined in [OSPFV3]. Instances subsequent to the first 527 are ignored. 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | 2 - Route Tag | sub-TLV Length | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Route Tag | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Route Tag Sub-TLV 539 4. OSPFv3 Extended LSAs 541 This section specifies the OSPFv3 Extended LSA formats and encoding. 542 The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3 543 LSAs specifed in [OSPFV3]. 545 4.1. OSPFv3 E-Router-LSA 547 The E-Router-LSA has an LS Type of 0xA021 and has the same base 548 information content as the Router-LSA defined in section A.4.3 of 549 [OSPFV3]. However, unlike the existing Router-LSA, it is fully 550 extendable and represented as TLVs. 552 0 1 2 3 553 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 554 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | LS Age |1|0|1| 0x21 | 556 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Link State ID | 558 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Advertising Router | 560 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | LS Sequence Number | 562 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | LS Checksum | Length | 564 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | 0 |Nt|x|V|E|B| Options | 566 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 . . 568 . TLVs . 569 . . 570 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 Extended Router-LSA 574 All LSA Header fields are the same as defined for the Router-LSA. 575 Initially, only the top-level Router-Link TLV Section 3.1 is 576 applicable and an E-Router-LSA may include multiple Router-Link TLVs. 577 Like the existing Router-LSA, the LSA length is used to determine the 578 end of the LSA including TLVs. 580 4.2. OSPFv3 E-Network-LSA 582 The E-Network-LSA has an LS Type of 0xA022 and has the same base 583 information content as the Network-LSA defined in section A.4.4 of 584 [OSPFV3]. However, unlike the existing Network-LSA, it is fully 585 extendable and represented as TLVs. 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | LS Age |1|0|1| 0x22 | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Link State ID | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Advertising Router | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | LS Sequence Number | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | LS Checksum | Length | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | 0 | Options | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 . . 603 . TLVs . 604 . . 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 E-Network-LSA 609 All LSA Header fields are the same as defined for the Network-LSA. 610 Like the existing Network-LSA, the LSA length is used to determine 611 the end of the LSA including TLVs. Initially, only the top-level 612 Attached-Routers TLV Section 3.2 is applicable. 614 4.3. OSPFv3 E-Inter-Area-Prefix-LSA 616 The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same 617 base information content as the Inter-Area-Prefix-LSA defined in 618 section A.4.5 of [OSPFV3]. However, unlike the existing Inter-Area- 619 Prefix-LSA, it is fully extendable and represented as TLVs. 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | LS Age |1|0|1| 0x23 | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Link State ID | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Advertising Router | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | LS Sequence Number | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | LS Checksum | Length | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 . . 635 . TLVs . 636 . . 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 E-Inter-Area-Prefix-LSA 641 All LSA Header fields are the same as defined for the Inter-Area- 642 Prefix-LSA. In order to retain compatibility and semantics with the 643 current OSPFv3 specification, each Inter-Area-Prefix LSA MUST contain 644 a single Inter-Area Prefix TLV. This will facilitate migration and 645 avoid changes to functions such as incremental SPF computation. 647 Like the existing Inter-Area-Prefix-LSA, the LSA length is used to 648 determine the end of the LSA including TLV. Initially, only the top- 649 level Inter-Area-Prefix TLV (Section 3.3) is applicable. 651 4.4. OSPFv3 E-Inter-Area-Router-LSA 653 The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same 654 base information content as the Inter-Area-Router-LSAE defined in 655 section A.4.6 of [OSPFV3]. However, unlike the Inter-Area-Router- 656 LSA, it is fully extendable and represented as TLVs. 658 0 1 2 3 659 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | LS Age |1|0|1| 0x24 | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Link State ID | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Advertising Router | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | LS Sequence Number | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | LS Checksum | Length | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 . . 672 . TLVs . 673 . . 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 E-Inter-Area-Router-LSA 678 All LSA Header fields are the same as defined for the Inter-Area- 679 Router-LSA. In order to retain compatibility and semantics with the 680 current OSPFv3 specification, each Inter-Area-Router LSA MUST contain 681 a single Inter-Area Router TLV. This will facilitate migration and 682 avoid changes to functions such as incremental SPF computation. 684 Like the existing Inter-Area-Router-LSA, the LSA length is used to 685 determine the end of the LSA including TLV. Initially, only the top- 686 level Inter-Area-Router TLV (Section 3.4) is applicable. 688 4.5. OSPFv3 E-AS-External-LSA 690 The E-AS-External-LSA has an LS Type of 0xC025 and has the same base 691 information content as the AS-External-LSA defined in section A.4.7 692 of [OSPFV3]. However, unlike the existing AS-External-LSA, it is 693 fully extendable and represented as TLVs. 695 0 1 2 3 696 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | LS Age |1|1|0| 0x25 | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Link State ID | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Advertising Router | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | LS Sequence Number | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | LS Checksum | Length | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 . . 709 . TLVs . 710 . . 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 E-AS-External-LSA 715 All LSA Header fields are the same as defined for the AS-External- 716 LSA. In order to retain compatibility and semantics with the current 717 OSPFv3 specification, each LSA MUST contain a single External Prefix 718 TLV. This will facilitate migration and avoid changes to OSPFv3 719 processes such as incremental SPF computation. 721 Like the existing AS-External-LSA, the LSA length is used to 722 determine the end of the LSA including sub-TLVs. Initially, only the 723 top-level External-Prefix TLV (Section 3.5) is applicable. 725 4.6. OSPFv3 E-NSSA-LSA 727 The E-NSSA-LSA will have the same format and TLVs as the Extended AS- 728 External-LSA Section 4.5. This is the same relationship as exists 729 between the NSSA-LSA defined in section A.4.8 of [OSPFV3], and the 730 AS-External-LSA. The NSSA-LSA will have type 0xA027 which implies 731 area flooding scope. Future requirements may dictate that supported 732 TLVs differ between the E-AS-External-LSA and the E-NSSA-LSA. 733 However, future requirements are beyond the scope of this document. 735 4.7. OSPFv3 E-Link-LSA 737 The E-Link-LSA has an LS Type of 0x8028 and will have the same base 738 information content as the Link-LSA defined in section A.4.9 of 739 [OSPFV3]. However, unlike the existing Link-LFA, it is extendable 740 and represented as TLVs. 742 0 1 2 3 743 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 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | LS Age |1|0|0| 0x28 | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Link State ID | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Advertising Router | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | LS Sequence Number | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | LS Checksum | Length | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Rtr Priority | Options | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 . . 758 . TLVs . 759 . . 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 E-Link-LSA 764 All LSA Header fields are the same as defined for the Link-LSA. 766 Only the Intra-Area-Prefix TLV (Section 3.6), IPv6 Link-Local Address 767 TLV (Section 3.7), and IPv4 Link-Local Address TLV (Section 3.8) are 768 applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA 769 affords advertisement of multiple intra-area prefixes. Hence, 770 multiple Intra-Area Prefix TLVs (Section 3.6) may be specified and 771 the LSA length defines the end of the LSA including all TLVs. 773 Only a single instance of the IPv6 Link-Local Address TLV 774 (Section 3.7) SHOULD be included in the E-Link-LSA. Instances 775 following the first MUST be ignored. For IPv4 address families as 776 defined in [OSPFV3-AF], this TLV MUST be ignored. 778 Similarly, only a single instance of the IPv4 Link-Local Address TLV 779 (Section 3.8) SHOULD be included in the E-Link-LSA. Instances 780 following the first MUST be ignored. For OSPFv3 IPv6 address 781 families as defined in [OSPFV3-AF], this TLV MUST be ignored. 783 Future specifications may support advertisement of routing and 784 topology information for multiple address families. However, this is 785 beyond the scope of this document. 787 4.8. OSPFv3 E-Intra-Area-Prefix-LSA 789 The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same 790 base information content as the Intra-Area-Prefix-LSA defined in 791 section A.4.10 of [OSPFV3]. However, unlike the Intra-Area-Prefix- 792 LSA, it is fully extendable and represented as TLVs. 794 0 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | LS Age |1|0|1| 0x29 | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Link State ID | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Advertising Router | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | LS Sequence Number | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | LS Checksum | Length | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | 0 | Referenced LS Type | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Referenced Link State ID | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Referenced Advertising Router | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 . . 814 . TLVs . 815 . . 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 E-Intra-Area-Prefix-LSA 820 All LSA Header fields are the same as defined for the Intra-Area- 821 Prefix-LSA. 823 Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords 824 advertisement of multiple intra-area prefixes. Hence, multiple 825 Intra-Area Prefix TLVs may be specified and the LSA length defines 826 the end of the LSA including all TLVs. 828 5. LSA Extension Backward Compatibility 830 In the context of this document, backward compatibility is solely 831 related to the capability of an OSPFv3 router to receive, process, 832 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 833 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 834 extensions utilizing the TLV-based LSAs is out of scope and must be 835 covered in the documents describing those extensions. Both full and, 836 if applicable, partial deployment SHOULD be specified for future TLV- 837 based OSPFv3 LSA extensions. 839 Two distinct backward compatibility modes are supported dependent on 840 the OSPFv3 routing domain migration requirements. For simplicity and 841 to avoid the scaling impact of maintaining both TLV and non-TLV based 842 versions of the same LSA within a routing domain, the basic backward 843 compatibility mode will not allow mixing of LSA formats. Different 844 LSA formats could still be supported with multiple OSPFv3 instances 845 and separate OSPFv3 routing domains. Additionally, a more flexible 846 mode is provided in Section 5.1, where both formats of LSA coexist. 847 In order to facilitate backward compatibility, the OSPFv3 options 848 field (as described in Appendix A.2 of RFC 5340 [OSPFV3]), will 849 contain two additional options bits. The EL-bits will be used to 850 indicate that the OSPFv3 router's level of Extended LSA support. An 851 OSPFv3 router configured to support extended LSAs MUST set its 852 options field EL-bits in OSPFv3 Hello and Database Description 853 packets as follows: 855 B'00' 856 None - Extended LSAs are not originate nor used in the SPF 857 calculation. 859 B'01' 860 MixedModeOriginateOnly - Both extended and non-extended LSAs are 861 originated. Non-extended LSAs are used in the SPF computation. 863 B'10' 864 MixedModeOriginateSPF - Both extended and non-extended LSAs are 865 originated. Extended LSAs are used in the SPF computation. 867 B'11' 868 Full - Only extended LSAs are originated and used in the SPF 869 computation. 871 If Full is specified for ExtendedLSASupport, the OSPFv3 router MUST 872 NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and 873 Database Description packets with the options field EL-bits set to 874 MixedModeOriginateOnly or None. Similarly, if MixModeOriginateSPF is 875 specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form 876 adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database 877 Description packets with the options field EL-bits set to None 878 (B'00'). In this manner, OSPFv3 routers using new encodings can be 879 completely isolated from those OSPFv3 routers depending on the RFC 880 5340 encoding and not setting their options field EL-bits since the 881 default setting indicates no support for extended LSAs. 883 1 2 884 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 886 | | | | | | | | | | | | EL|AT|L|AF|*|*|DC|R|N|x|E|V6| 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 888 The Options field 890 EL-bits 891 These bits indicate the level of Extended LSA support. 892 B'00' - Extended LSAs are not originate nor used in the 893 SPF calculation. 894 B'01' - Both extended and non-extended LSAs are originated. 895 Non-extended LSAs are used in the SPF computation. 896 B'10' - Both extended and non-extended LSAs are originated. 897 Extended LSAs are used in the SPF computation. 898 B'11' - Only extended LSA are originated and used in the 899 SPF computation. 901 Options Field EL-bits 903 The EL-bits will also be set in the LSA options field in Extended and 904 Non-Extended LSAs. While the value of the EL-bits has no functional 905 significance in the LSA options field, visibility of every OSPFv3 906 Router's extended LSA support is expected to be very useful for 907 management and troubleshooting during the migration period. 909 5.1. Extended LSA Mixed-Mode Backward Compatibility 911 An implementation MAY support configuration allowing a graceful 912 transition from the non-extended (non-TLV-based) LSAs to the extended 913 (TLV-based) LSAs in an OSPFv3 routing domain. In these routing 914 domains, the OSPFv3 routers configured with a value of 915 MixedModeOriginateOnly or MixedModeOriginateSPF for 916 ExtendedLSASupport, (Appendix A), MUST originate both the extended 917 and non-extended versions of the OSPFv3 LSAs described herein. For 918 the purposes of Shortest Path First (SPF) computation, the non- 919 extended OSPFv3 LSAs are used for SPF computation when 920 MixedModeOriginateOnly is configured and the extended LSAs are used 921 when MixedModeOriginateSPF is specified. The extended LSAs MAY be 922 used for functions other than routing computation as long as backward 923 compatibility is specified in the documents specifying those 924 functions. 926 In this manner, OSPFv3 routing domains utilizing the new encodings 927 can be gradually migrated with a worst-case overhead cost of 928 approximately doubling the number of LSAs in the routing domain. The 929 transition within an OSPFv3 routing domain would progress as follows: 931 1. Configure OSPFv3 Router ExtendedLSASupport to 932 MixedModeOriginateOnly so that routers originate the extended 933 LSAs. 935 2. When all the OSPFv3 Routers have been reconfigured to 936 MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to 937 use the extended LSAs by configuring ExtendedLSASupport to 938 MixedModeOriginateSPF. This can be done on a small subset of 939 OSPFv3 Routers and the route tables can be verified. 941 3. When all the OSPFv3 Routers have been reconfigured to 942 MixedModeOriginateSPF and the routing has been verified, 943 reconfigure OSPFv3 Routers to purge or simply not refresh the 944 non-extended OSPFv3 LSA by configuring ExtendedLSASupport to 945 Full. 947 In order to prevent OSPFv3 routing domain routing loops, the 948 advertised metrics in the extended and non-extended OSPFv3 LSAs MUST 949 be identical. 951 5.1.1. Area Extended LSA Mixed-Mode Backward Compatibility 953 An implementation MAY also support configuration allowing graceful 954 transition from the non-extended LSAs to the extended LSAs within a 955 single area. In these areas, the parameter AreaExtendedLSASupport 956 (Appendix B) may be configured to take precedence over the global 957 parameter ExtendedLSASupport. However, the AreaExtendedLSASupport 958 will only apply to link and area scoped LSAs within the area and area 959 based SPF calculations. The default is for the 960 AreaExtendedLSASupport to be inherited from the ExtendedLSASupport. 961 The configuration of ExtendedLSASupport will apply to AS-External 962 LSAs even when AreaExtendedLSASupport takes precedence. 964 5.2. LSA TLV Processing Backward Compatibility 966 This section defines the general rules for processing LSA TLVs. To 967 ensure compatibility of future TLV-based LSA extensions, all 968 implementations MUST adhere to these rules: 970 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or 971 processing Extended-LSAs. 973 2. Whether or not partial deployment of a given TLV is supported 974 MUST be specified. 976 3. If partial deployment is not supported, mechanisms to ensure the 977 corresponding feature are not deployed MUST be specified in the 978 document defining the new TLV or sub-TLV. 980 4. If partial deployment is supported, backward compatibility and 981 partial deployment MUST be specified in the document defining the 982 new TLV or sub-TLV. 984 6. Security Considerations 986 In general, extendible OSPFv3 LSAs are subject to the same security 987 concerns as those described in RFC 5340 [OSPFV3]. Additionally, 988 implementations must assure that malformed TLV and Sub-TLV 989 permutations do not result in errors that cause hard OSPFv3 failures. 991 If there were ever a requirement to digitally sign OSPFv3 LSAs as 992 described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the 993 mechanisms described herein would greatly simplify the extension. 995 7. IANA Considerations 997 This specification defines nine OSPFv3 Extended LSA types as 998 described in Section 2. 1000 This specification also creates two registries OSPFv3 Extended-LSAs 1001 TLVs and sub-TLVs. The TLV and Sub-TLV code-points in these 1002 registries are common to all Extended-LSAs and their respective 1003 definitions must define where they are applicable. 1005 The OSPFv3 Extend-LSA TLV registry will define top-level TLVs for 1006 Extended-LSAs and should be placed in the existing OSPFv3 IANA 1007 registry. New values can be allocated via IETF Consensus or IESG 1008 Approval. 1010 Nine values are allocated by this specification: 1012 o 0 - Reserved 1014 o 1 - Router-Link TLV 1016 o 2 - Attached-Routers TLV 1018 o 3 - Inter-Area Prefix TLV 1020 o 4 - Inter-Area Router TLV 1022 o 5 - External Prefix TLV 1024 o 6 - Intra-Area Prefix TLV 1026 o 7 - IPv6 Link-Local Address TLV 1028 o 8 - IPv4 Link-Local Address TLV 1030 The OSPFv3 Extend-LSA sub-TLV registry will define sub-TLVs at any 1031 level of nesting for Extended-LSAs and should be placed in the 1032 existing OSPFv3 IANA registry. New values can be allocated via IETF 1033 Consensus or IESG Approval. 1035 Three values are allocated by this specification: 1037 o 0 - Reserved 1039 o 1 - Forwarding Address 1041 o 2 - Route Tag 1043 8. References 1045 8.1. Normative References 1047 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1048 for IPv6", RFC 5340, July 2008. 1050 [OSPFV3-AF] 1051 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 1052 Aggarwal, "Support of Address Families in OSPFv3", 1053 RFC 5838, April 2010. 1055 [RFC-KEYWORDS] 1056 Bradner, S., "Key words for use in RFCs to Indicate 1057 Requirement Levels", RFC 2119, March 1997. 1059 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 1060 Extensions to OSPF", RFC 3630, September 2003. 1062 8.2. Informative References 1064 [MT-OSPFV3] 1065 Mirtorabi, S. and A. Roy, "Multi-topology routing in 1066 OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt 1067 (work in progress). 1069 [OSPF-DIGITAL-SIGNATURE] 1070 Murphy, S., Badger, M., and B. Wellington, "OSPF with 1071 Digital Signatures", RFC 2154, June 1997. 1073 Appendix A. Global Configuration Parameters 1075 An additional global configurable parameter will be added to the 1076 OSPFv3 protocol. 1078 ExtendedLSASupport 1079 This is an enumeration type indicating the extent to which the 1080 OSPFv3 instance supports the TLV format described herein for 1081 Extended LSAs. The valid values for the enumeration are: 1083 * None - Extended LSAs will not be originated or used in the SPF 1084 calculation. This is the default. 1086 * MixedModeOriginateOnly - Both extended and non-extended LSAs 1087 will be originated. OSPFv3 adjacencies will be formed with 1088 OSPFv3 routers not supporting this specification. The non- 1089 extended LSAs are used for the SPF computation. 1091 * MixedModeOriginateSPF - Both extended and non-extended LSAs 1092 will be originated. OSPFv3 adjacencies will be formed with 1093 OSPFv3 routers not supporting this specification. The extended 1094 LSAs are used for the SPF computation. 1096 * Full - Extended LSAs will be originated and adjacencies will 1097 not be formed with OSPFv3 routers not supporting this 1098 specification. Only Extended LSAs will be originated. 1100 Appendix B. Area Configuration Parameters 1102 An additional area configurable parameter will be added to the OSPFv3 1103 protocol. 1105 AreaExtendedLSASupport 1106 This is an enumeration type indicating the extent to which the 1107 OSPFv3 area supports the TLV format described herein for Extended 1108 LSAs. The valid value for the enumeration are: 1110 * InheritGlobal - The AreaExtendedLSASupport will be inherited 1111 from ExtendedLSASupport. This is the default. 1113 * None - Non-extended LSAs will not be originated or used in the 1114 SPF calculation. 1116 * MixedModeOriginateOnly - Both extended and non-extended link 1117 and area scoped LSAs will be originated. OSPFv3 adjacencies 1118 will be formed with OSPFv3 routers not supporting this 1119 specification. The non-extended LSAs are used for the SPF 1120 computation. 1122 * MixedModeOriginateSPF - Both extended and non-extended link and 1123 area scoped LSAs will be originated. OSPFv3 adjacencies will 1124 be formed with OSPFv3 routers not supporting this 1125 specification. The extended LSAs are used for the area SPF 1126 computation. 1128 * Full - Link and area scoped extended LSAs will be originated 1129 and adjacencies will not be formed with OSPFv3 routers not 1130 supporting this specification. Only Extended LSAs will be 1131 originated. 1133 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1134 configuring None or MixedModeOriginateOnly for AreaExtendedLSASupport 1135 when Full is specified for ExtendedLSASupport is contradictory and 1136 MAY be prohibited by the implementation. 1138 Authors' Addresses 1140 Acee Lindem 1141 Ericsson 1142 301 Midenhall Way 1143 Cary, NC 27513 1144 USA 1146 Email: acee.lindem@ericsson.com 1148 Sina Mirtorabi 1149 Cisco Systems 1150 170 Tasman Drive 1151 San Jose, CA 95134 1152 USA 1154 Email: sina@cisco.com 1156 Abhay Roy 1157 Cisco Systems 1158 170 Tasman Drive 1159 San Jose, CA 95134 1160 USA 1162 Email: akr@cisco.com 1164 Fred Baker 1165 Cisco Systems 1166 Santa Barbara, CA 93117 1167 USA 1169 Email: fred@cisco.com