idnits 2.17.00 (12 Aug 2021) /tmp/idnits25467/draft-ietf-ospf-ospfv3-lsa-extend-01.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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (February 10, 2014) is 3022 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 (~~), 3 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: August 14, 2014 A. Roy 6 F. Baker 7 Cisco Systems 8 February 10, 2014 10 OSPFv3 LSA Extendibility 11 draft-ietf-ospf-ospfv3-lsa-extend-01.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 LSA. This document extends 20 the LSA format by allowing the optional inclusion of Type-Length- 21 Value (TLV) tuples in the LSAs. Backward compatibility mechanisms 22 are also described. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 14, 2014. 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 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 72 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 73 2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 6 74 3. OSPFv3 Extended LSA TLV . . . . . . . . . . . . . . . . . . . 7 75 4. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . . . 8 76 5. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . . . . 10 77 6. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . . . . 12 78 7. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . . . . 14 79 8. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . . . . 16 80 9. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . . . 19 81 10. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . . . 20 82 11. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . . . . 23 83 12. LSA Extension Backward Compatibility . . . . . . . . . . . . . 24 84 12.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . . 25 85 12.1.1. Area Extended LSA Mixed-Mode Backward 86 Compatibility . . . . . . . . . . . . . . . . . . . . 25 87 12.2. LSA TLV Processing Backward Compatibility . . . . . . . . 26 88 13. Security Considerations . . . . . . . . . . . . . . . . . . . 27 89 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 90 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 91 15.1. Normative References . . . . . . . . . . . . . . . . . . . 29 92 15.2. Informative References . . . . . . . . . . . . . . . . . . 29 93 Appendix A. Global Configuration Parameters . . . . . . . . . . . 30 94 Appendix B. Area Configuration Parameters . . . . . . . . . . . . 31 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 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 LSA. This document 104 extends the LSA format by allowing the optional inclusion of Type- 105 Length-Value (TLV) tuples in the LSAs. Backward compatibility 106 mechanisms are also described. 108 A similar extension was previously proposed in support of multi- 109 topology routing. Additional requirements for OSPFv3 LSA extension 110 include source/destination routing, route tagging, and others. 112 A final requirement is to limit the changes to OSPFv3 to those 113 necessary for TLV-based LSAs. For the most part, the semantics of 114 existing OSPFv3 LSA are retained for their TLV-based successor LSAs 115 described herein. Additionally, encoding details, e.g., the 116 representation of IPv6 prefixes as described in section A.4.1 in RFC 117 5340 [OSPFV3], have been retained. This requirement was included to 118 increase the expedience of IETF adoption and deployment. 120 The following aspects of OSPFv3 LSA extension are described: 122 1. Extended LSA Types 124 2. Extended LSA Formats 126 3. Backward Compatibility 128 1.1. Requirements notation 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC-KEYWORDS]. 134 1.2. Acknowledgments 136 OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing 137 in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3]. 139 Thanks for Peter Psenak for significant contributions to the backward 140 compatibility mechanisms. 142 Thanks go to Michael Barnes, Mike Dubrovsky, and Anton Smirnov for 143 review of the draft versions and discussions of backward 144 compatibility. 146 The RFC text was produced using Marshall Rose's xml2rfc tool. 148 2. OSPFv3 Extended LSA Types 150 In order to provide backward compatibility, new LSA codes must be 151 allocated. There are eight fixed-format LSAs defined in RFC 5340 152 [OSPFV3]. For ease of implementation and debugging, the LSA function 153 codes are the same as the fixed-format LSAs only with 32, i.e., 0x20, 154 added. The alternative was to allocate a bit in the LSA Type 155 indicating the new LSA format. However, this would have used one 156 half the LSA function code space for the migration of the eight 157 original fixed-format LSAs. For backward compatibility, the U-bit 158 will be set in LS Type so that the LSAs will be flooded by OSPFv3 159 routers that do not understand them. 161 LSA function code LS Type Description 162 ---------------------------------------------------- 163 33 0xA021 E-Router-LSA 164 34 0xA022 E-Network-LSA 165 35 0xA023 E-Inter-Area-Prefix-LSA 166 36 0xA024 E-Inter-Area-Router-LSA 167 37 0xC025 E-AS-External-LSA 168 38 N/A Unused (Not to be allocated) 169 39 0xA027 E-Type-7-LSA 170 40 0x8028 E-Link-LSA 171 41 0xA029 E-Intra-Area-Prefix-LSA 173 OSPFv3 Extended LSA Types 175 3. OSPFv3 Extended LSA TLV 177 The format of the TLVs within the body of the extended LSAs is the 178 same as the format used by the Traffic Engineering Extensions to OSPF 179 [TE]. The variable TLV section consists of one or more nested Type/ 180 Length/Value (TLV) tuples. The format of each TLV is: 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Type | Length | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Value... | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 TLV Format 192 The Length field defines the length of the value portion in octets 193 (thus a TLV with no value portion would have a length of 0). The TLV 194 is padded to 4-octet alignment; padding is not included in the length 195 field (so a 3-octet value would have a length of 3, but the total 196 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 197 aligned. For example, a 1-byte value would have the length field set 198 to 1, and 3 octets of padding would be added to the end of the value 199 portion of the TLV. Unrecognized types are ignored. 201 4. OSPFv3 E-Router-LSA 203 The E-Router-LSA has an LS Type of 0xA021 and has the same base 204 information content as the Router-LSA, section 4.4.3.2 in [OSPFV3]. 205 However, unlike the existing Router-LSA, it is fully extendable and 206 represented as TLVs. 208 0 1 2 3 209 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 210 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | LS Age |1|0|1| 0x21 | 212 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Link State ID | 214 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Advertising Router | 216 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | LS Sequence Number | 218 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | LS Checksum | Length | 220 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | 0 |Nt|x|V|E|B| Options | 222 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 . . 224 . TLVs . 225 . . 226 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Extended Router-LSA 230 All LSA Header fields are the same as defined for the Router-LSA. 231 The following top-level TLVs are defined: 233 o 0 - Reserved 235 o 1 - Router-Link TLV 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | 1 (Router-Link) | TLV Length | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Type | 0 | Metric | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Interface ID | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Neighbor Interface ID | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Neighbor Router ID | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 . . 250 . sub-TLVs . 251 . . 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Router-Link TLV 256 Like the existing Router-LSA, the LSA length is used to determine the 257 end of the LSA including TLVs. The Router-Link TLV is only 258 applicable to the E-Router-LSA. Inclusion in other Extended LSAs 259 MUST be ignored. 261 5. OSPFv3 E-Network-LSA 263 The E-Network-LSA has an LS Type of 0xA022 and has the same base 264 information content as the Network-LSA, section 4.4.3.3 in [OSPFV3]. 265 However, unlike the existing Network-LSA, it is fully extendable and 266 represented as TLVs. 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | LS Age |1|0|1| 0x22 | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Link State ID | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Advertising Router | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | LS Sequence Number | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | LS Checksum | Length | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | 0 | Options | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 . . 284 . TLVs . 285 . . 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 E-Network-LSA 290 All LSA Header fields are the same as defined for the Network-LSA. 291 The following top-level TLVs are defined: 293 o 2 - Attached-Routers TLV 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | 2 (Attached-Routers) | TLV Length | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Adjacent Neighbor Router ID | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 . . 303 . Additional Adjacent Neighbors . 304 . . 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Attached-Routers TLV 309 There are two reasons for not having a separate TLV or sub-TLV for 310 each adjacent neighbor. The first is to discourage using the 311 E-Network-LSA for more than its current role of solely advertising 312 the routers attached to a multi-access network. The router's metric 313 as well as her attributes of individual attached routers should be 314 advertised in their respective E-Router-LSAs. The second reason is 315 that there is only a single E-Network-LSA per multi-access link with 316 the Link State ID set to the Designated Router's Interface ID and, 317 consequently, compact encoding has been chosen to decrease the 318 likelihood of the size of the E-Network-LSA requiring IPv6 319 fragmentation when advertised in an OSPFv3 Link State Update packet. 321 Like the existing Network-LSA, the LSA length is used to determine 322 the end of the LSA including TLVs. The Attached-Routers TLV is only 323 applicable to the E-Network-LSA. Inclusion in other Extended LSAs 324 MUST be ignored. 326 6. OSPFv3 E-Inter-Area-Prefix-LSA 328 The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same 329 base information content as the Inter-Area-Prefix-LSA, section 330 4.4.3.4 in [OSPFV3]. However, unlike the existing Inter-Area-Prefix- 331 LSA, it is fully extendable and represented as TLVs. 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | LS Age |1|0|1| 0x23 | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Link State ID | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Advertising Router | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | LS Sequence Number | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | LS Checksum | Length | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 . . 347 . TLVs . 348 . . 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 E-Inter-Area-Prefix-LSA 353 All LSA Header fields are the same as defined for the Network-LSA. 354 The following top-level TLVs are defined: 356 o 3 - Inter-Area Prefix TLV 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | 3 (Inter-Area Prefix) | TLV Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | 0 | Metric | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | PrefixLength | PrefixOptions | 0 | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Address Prefix | 367 | ... | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 . . 370 . sub-TLVs . 371 . . 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Inter-Area Prefix TLV 376 In order to retain compatibility and semantics with the current 377 OSPFv3 specification, each LSA MUST contain a single Inter-Area 378 Prefix TLV. This will facilitate migration and avoid changes to 379 functions such as incremental SPF computation. 381 Like the existing Inter-Area-Prefix-LSA, the LSA length is used to 382 determine the end of the LSA including TLV. The Inter-Area-Prefix 383 TLV is only applicable to the E-Inter-Area-Prefix-LSA. Inclusion in 384 other Extended LSAs MUST be ignored. 386 7. OSPFv3 E-Inter-Area-Router-LSA 388 The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same 389 base information content as the Inter-Area-Router-LSA, section 390 4.4.3.5 in [OSPFV3]. However, unlike the Inter-Area-Router-LSA, it 391 is fully extendable and represented as TLVs. 393 0 1 2 3 394 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | LS Age |1|0|1| 0x24 | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Link State ID | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Advertising Router | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | LS Sequence Number | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | LS Checksum | Length | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 . . 407 . TLVs . 408 . . 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 E-Inter-Area-Router-LSA 413 All LSA Header fields are the same as defined for the Inter-Area- 414 Router-LSA. The following top-level TLVs are defined: 416 o 4 - Inter-Area Router TLV 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | 3 (Inter-Area Router) | TLV Length | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | 0 | Options | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | 0 | Metric | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Destination Router ID | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 . . 429 . sub-TLVs . 430 . . 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Inter-Area Router TLV 435 In order to retain compatibility and semantics with the current 436 OSPFv3 specification, each LSA MUST contain a single Inter-Area 437 Router TLV. This will facilitate migration and avoid changes to 438 functions such as incremental SPF computation. 440 Like the existing Inter-Area-Router-LSA, the LSA length is used to 441 determine the end of the LSA including sub-TLVs. The Inter-Area- 442 Router TLV is only applicable to the E-Inter-Area-Router-LSA. 443 Inclusion in other Extended LSAs MUST be ignored. 445 8. OSPFv3 E-AS-External-LSA 447 The E-AS-External-LSA has an LS Type of 0xC025 and has the same base 448 information content as the AS-External-LSA, section 4.4.3.6 in 449 [OSPFV3]. However, unlike the existing AS-External-LSA, it is fully 450 extendable and represented as TLVs. 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 | LS Age |1|1|0| 0x25 | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Link State ID | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Advertising Router | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | LS Sequence Number | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | LS Checksum | Length | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 . . 466 . TLVs . 467 . . 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 E-AS-External-LSA 472 All LSA Header fields are the same as defined for the AS-External- 473 LSA. The following top-level TLVs are defined: 475 o 5 - External Prefix TLV 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | 5 (External Prefix) | TLV Length | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | |E| | | Metric | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | PrefixLength | PrefixOptions | 0 | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Address Prefix | 486 | ... | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 . . 489 . sub-TLVs . 490 . . 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 External Prefix TLV 495 In order to retain compatibility and semantics with the current 496 OSPFv3 specification, each LSA MUST contain a single External Prefix 497 TLV. This will facilitate migration and avoid changes to OSPFv3 498 processes such as incremental SPF computation. In External Prefix 499 TLV, the optional Forwarding Address and External Route Tag are now 500 sub-TLVs. Given the Referenced LS type and Referenced Link State ID 501 from the AS-External-LSA have never been used or even specified, they 502 have been omitted from the External Prefix TLV. If there were ever a 503 requirement for a referenced LSA, it could be satisfied with a sub- 504 TLV. 506 Like the existing AS-External-LSA, the LSA length is used to 507 determine the end of the LSA including sub-TLVs. The External-Prefix 508 TLV is only applicable to the E-AS-External-LSA and the E-NSSA-LSA. 509 Inclusion in other Extended LSAs MUST be ignored. 511 The following sub-TLVs are defined for the External Prefix TLV: 513 o 1 - Forwarding Address sub-TLV 515 o 2 - Route Tag sub-TLV 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | 1 - Forwarding Address | sub-TLV Length (16) | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | | 522 +- -+ 523 | | 524 +- Forwarding Address -+ 525 | | 526 +- -+ 527 | | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 External Route Tag Sub-TLV 532 The optional Forwarding Address sub-TLV has identical semantics to 533 the optional forwarding address in section 4.4.3.6 of [OSPFV3]. The 534 Forwarding Address sub-TLV is applicable to the External-Prefix TLV. 535 Specification as a sub-TLV of other TLVs is not defined herein. The 536 sub-TLV is optional and the first specified instance is used as the 537 Forwarding Address as defined in [OSPFV3]. Instances subsequent to 538 the first are ignored. 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | 2 - Route Tag | sub-TLV Length (4) | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Route Tag | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Route Tag Sub-TLV 550 The optional Route Tag sub-TLV has identical semantics to the 551 optional External Route Tag in section 4.4.3.6 of [OSPFV3]. The 552 Route Tag sub-TLV is applicable to the External-Prefix TLV. 553 Specification as a sub-TLV of other TLVs is not defined herein. The 554 sub-TLV is optional and the first specified instance is used as the 555 Route Tag as defined in [OSPFV3]. Instances subsequent to the first 556 are ignored. 558 9. OSPFv3 E-NSSA-LSA 560 The E-NSSA-LSA will have the same format and TLVs as the Extended AS- 561 External-LSA Section 8. This is the same relationship as exists 562 between the NSSA-LSA, section 4.4.3.7 in [OSPFV3], and the AS- 563 External-LSA. The NSSA-LSA will have type 0xA027 which implies area 564 flooding scope. Future requirements may dictate that supported TLVs 565 differ between the E-AS-External-LSA and the E-NSSA-LSA. However, 566 future requirements are beyond the scope of this document. 568 10. OSPFv3 E-Link-LSA 570 The E-Link-LSA has an LS Type of 0x8028 and will have the same base 571 information content as the Link-LSA, section 4.4.3.8 in [OSPFV3]. 572 However, unlike the existing Link-LFA, it is extendable and 573 represented as TLVs. 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | LS Age |1|0|0| 0x28 | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Link State ID | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Advertising Router | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | LS Sequence Number | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | LS Checksum | Length | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Rtr Priority | Options | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 . . 591 . TLVs . 592 . . 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 E-Link-LSA 597 The following top-level TLVs are defined: 599 o 6 - Intra-Area Prefix TLV 601 o 7 - IPv6 Link-Local Address TLV 603 o 8 - IPv4 Link-Local Address TLV 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | 6 (Intra-Area Prefix) | TLV Length | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | 0 | Metric | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | PrefixLength | PrefixOptions | 0 | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Address Prefix | 614 | ... | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 . . 617 . sub-TLVs . 618 . . 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 Intra-Area Prefix TLV 623 Like the Link-LSA, the E-Link-LSA affords advertisement of multiple 624 intra-area prefixes. Hence, multiple Intra-Area Prefix TLVs may be 625 specified and the LSA length defines the end of the LSA including all 626 TLVs. The Intra-Area-Prefix TLV is only applicable to the E-Link-LSA 627 and the E-Intra-Area-Prefix-LSA. Inclusion in other Extended LSAs 628 MUST be ignored. 630 0 1 2 3 631 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 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | 7 (IPv6 Local-Local Address) | TLV Length | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | | 636 +- -+ 637 | | 638 +- IPv6 Link-Local Interface Address -+ 639 | | 640 +- -+ 641 | | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 . . 644 . sub-TLVs . 645 . . 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 IPv6 Link-Local Address TLV 650 The IPv6 Link-Local Address TLV is to be used with IPv6 address 651 families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV 652 is only applicable to the E-Link-LSA. Inclusion in other Extended 653 LSAs MUST be ignored. Only a single instance of the IPv6 Link-Local 654 Address family SHOULD be included in the E-Link-LSA. Instances 655 following the first MUST be ignored. For IPv4 address families as 656 defined in [OSPFV3-AF], this TLV SHOULD be ignored. Future 657 specifications may support advertisement of routing and topology 658 information for multiple address families. However, this is beyond 659 the scope of this document. 661 0 1 2 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | 8 (IPv4 Local-Local Address) | TLV Length | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | IPv4 Link-Local Interface Address | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 . . 669 . sub-TLVs . 670 . . 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 IPv4 Link-Local Address TLV 675 The IPv4 Link-Local Address TLV is to be used with IPv4 address 676 families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV 677 is only applicable to the E-Link-LSA. Inclusion in other Extended 678 LSAs MUST be ignored. Only a single instance of the IPv4 Link-Local 679 Address family SHOULD be included in the E-Link-LSA. Instances 680 following the first MUST be ignored. For OSPFv3 IPv6 address 681 families as defined in [OSPFV3-AF], this TLV MUST be ignored. Future 682 specifications may support advertisement of routing and topology 683 information for multiple address families. However, this is beyond 684 the scope of this document. 686 11. OSPFv3 E-Intra-Area-Prefix-LSA 688 The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same 689 base information content as the Intra-Area-Prefix-LSA, section 690 4.4.3.9 in [OSPFV3]. However, unlike the Intra-Area-Prefix-LSA, it 691 is fully extendable and represented as TLVs. 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | LS Age |1|0|1| 0x29 | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Link State ID | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Advertising Router | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | LS Sequence Number | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | LS Checksum | Length | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | 0 | Referenced LS Type | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Referenced Link State ID | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Referenced Advertising Router | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 . . 713 . TLVs . 714 . . 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 E-Intra-Area-Prefix-LSA 719 All LSA Header fields are the same as defined for the Intra-Area- 720 Prefix-LSA. The following top-level TLVs are defined: 722 o 6 - Intra-Area-Prefix TLV (defined in Section 10) 724 Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords 725 advertisement of multiple intra-area prefixes. Hence, multiple 726 Intra-Area Prefix TLVs may be specified and the LSA length defines 727 the end of the LSA including all TLVs. 729 12. LSA Extension Backward Compatibility 731 In the context of this document, backward compatibility is solely 732 related to the capability of an OSPFv3 router to receive, process, 733 and originate the TLV-based LSAs defined herein. Backward 734 compatibility for future OSPFv3 extensions utilizing the TLV-based 735 LSAs is out of scope and must be covered in the documents describing 736 those extensions. Both full and, if applicable, partial deployment 737 should be covered for future OSPFv3 LSA extensions. 739 For simplicity and to avoid the scaling impact of maintaining both 740 TLV and non-TLV based versions of the same LSA within a routing 741 domain, the base backward compatibility mode will not allow mixing of 742 LSA formats. Different formats could still be supported with 743 multiple OSPFv3 instances and separate OSPFv3 routing domains. 744 Additionally, a more complex mode is provided in Section 12.1, where 745 both formats of LSA coexist. In order to facilitate backward 746 compatibility, the OSPFv3 options field (as described in Appendix A.2 747 of RFC 5340 [OSPFV3]), will contain an additional options bits. The 748 EL-bit will be used to indicate that the advertising OSPFv3 Router 749 can receive, process, and originate TLV-based LSAs. An OSPFv3 router 750 configured to support TLV-based LSAs WILL set its option field EL-bit 751 in OSPFv3 Hello and Database Description packets. If Full is 752 specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form 753 adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database 754 Description packets with the options field EL-bit clear. In this 755 manner, OSPFv3 routing domains utilizing the new encoding will be 756 completely isolated from those using the RFC 5340 encodings. 758 If MixedModeOriginateOnly, MixedModeOriginateSPF, or Full is 759 specified for ExtendedLSASupport, (Appendix A), or 760 AreaExtendedLSASupport (Appendix B) the EL-bit will be set in the 761 OSPFv3 Hello and Database Description packet options field. 763 1 2 764 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 765 +-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+--+-+-+--+-+-+-+--+--+ 766 | | | | | | | | | | | | |EL|AT|L|AF|*|*|DC|R|N|x| E|V6| 767 +-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+--+-+-+--+-+-+-+--+--+ 768 The Options field 770 EL-bit 771 This bit is indicates whether or not the OSPFv3 router 772 supports the Extended LSA format with the bit set condition 773 indicating support. 775 Options Field EL-bit 777 12.1. Extended LSA Mixed-Mode Backward Compatibility 779 An implementation MAY support configuration allowing a graceful 780 transition from the non-extended (non-TLV-based) LSAs to the extended 781 (TLV-based) LSAs in an OSPFv3 routing domain. In these routing 782 domains, the OSPFv3 routers configured with a value of 783 MixedModeOriginateOnly or MixedModeOriginateSPF for 784 ExtendedLSASupport, (Appendix A), MUST originate both the extended 785 and non-extended versions of the OSPFv3 LSAs described herein. For 786 the purposes of Shortest Path First (SPF) computation, the non- 787 exteneded versions of the OSPFv3 LSAs are used for SPF computation 788 when MixedModeOrignateOnly is configured and the extended versions 789 are used when MixedModeOriginateSPF is specified. The extended LSAs 790 MAY be used for functions other than routing computation as long as 791 backward compatility is described in the documents describing those 792 functions. OSPFv3 routers configured for mixed mode operation also 793 MUST form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and 794 Database Description packets with the options field EL-bit clear. 796 In this manner, OSPFv3 routing domains utilizing the new encodings 797 can be gradually migrated with a worst-case cost of approximately 798 doubling the number of LSAs in the routing domain. The transition 799 within an OSPFv3 routing domain would progress as follows: 801 1. Configure OSPFv3 Router ExtendedLSASupport to 802 MixedModeOriginateOnly so that routers orginate the extended 803 LSAs. 805 2. When all the OSPFv3 Routers have been reconfigured to 806 MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to 807 use the extended LSAs by configuring ExtendedLSASupport to 808 MixedModeOriginateSPF. This can be done on a small subset of 809 OSPFv3 Routers and the route tables can be verified. 811 3. When all the OSPFv3 Routers have been reconfigured to 812 MixedModeOriginateSPF and the routing has been verified, 813 reconfigure OSPFv3 Routers to purge or simply not refresh the 814 non-extended OSPFv3 LSA by configuring ExtendedLSASupport to 815 Full. 817 12.1.1. Area Extended LSA Mixed-Mode Backward Compatibility 819 An implemenation MAY also support configuration allowing graceful 820 transition from the non-extended LSAs to the extended LSAs within a 821 single area. In these area, the parameter AreaExtendedLSASupport 822 (Appendix B) may be configured to take precedence over the global 823 parameter ExtendedLSASupport. However, the AreaExtendedLSASupport 824 will only apply to link and area scoped LSAs within the area and area 825 based SPF calculations. The default is for the 826 AreaExtendedLSASupport to be inherited from the ExtendedLSASupport. 828 12.2. LSA TLV Processing Backward Compatibility 830 This section defines the general rules for processing LSA TLVs. To 831 ensure compatibility of future TLV-based LSA extensions, all 832 implementations MUST adhere to these rules: 834 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or 835 processing Extended-LSAs. 837 2. Whether or not partial deployment of a given TLV is supported 838 MUST be specified. 840 3. If partial deployment is not supported, mechanisms to ensure the 841 corresponding feature are not deployed MUST be specified in the 842 document defining the new TLV or sub-TLV. 844 4. If partial deployment is supported, backward compatibility and 845 partial deployment MUST be specified in the document defining the 846 new TLV or sub-TLV. 848 13. Security Considerations 850 In general, extendible OSPFv3 LSAs are subject to the same security 851 concerns as those described in RFC 5340 [OSPFV3]. Additionally, 852 implementations must assure that malformed TLV and Sub-TLV 853 permutations do not result in errors which cause hard OSPFv3 854 failures. 856 If there were ever a requirement to digitally sign OSPFv3 LSAs as 857 described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the 858 mechanisms described herein would greatly simplify the extension. 860 14. IANA Considerations 862 This specification defines nine OSPFv3 Extended LSA types as 863 described in Section 2. 865 This specification also creates two registries OSPFv3 Extended-LSAs 866 TLVs and sub-TLVs. The TLV and Sub-TLV code-points in these 867 registries are common to all Extended-LSAs and their respective 868 definitions must define where they are applicable. 870 The OSPFv3 Extend-LSA TLV registry will define top-level TLVs for 871 Extended-LSAs and should be placed in the existing OSPFv3 IANA 872 registry. New values can be allocated via IETF Consensus or IESG 873 Approval. 875 Nine initial values are allocated: 877 o 0 - Reserved 879 o 1 - Router-Link TLV 881 o 2 - Attached-Routers TLV 883 o 3 - Inter-Area Prefix TLV 885 o 4 - Inter-Area Router TLV 887 o 5 - External Prefix TLV 889 o 6 - Intra-Area Prefix TLV 891 o 7 - IPv6 Link-Local Address TLV 893 o 8 - IPv4 Link-Local Address TLV 895 The OSPFv3 Extend-LSA sub-TLV registry will define sub-TLVs at any 896 level of nesting for Extended-LSAs and should be placed in the 897 existing OSPFv3 IANA registry. New values can be allocated via IETF 898 Consensus or IESG Approval. 900 One initial value is allocated: 902 o 0 - Reserved 904 o 1 - Forwarding Address 906 o 2 - Route Tag 908 15. References 910 15.1. Normative References 912 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 913 for IPv6", RFC 5340, July 2008. 915 [OSPFV3-AF] 916 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 917 Aggarwal, "Support of Address Families in OSPFv3", 918 RFC 5838, April 2010. 920 [RFC-KEYWORDS] 921 Bradner, S., "Key words for use in RFCs to Indicate 922 Requirement Levels", RFC 2119, March 1997. 924 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 925 Extensions to OSPF", RFC 3630, September 2003. 927 15.2. Informative References 929 [MT-OSPFV3] 930 Mirtorabi, S. and A. Roy, "Multi-topology routing in 931 OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt 932 (work in progress). 934 [OSPF-DIGITAL-SIGNATURE] 935 Murphy, S., Badger, M., and B. Wellington, "OSPF with 936 Digital Signatures", RFC 2154, June 1997. 938 Appendix A. Global Configuration Parameters 940 An additional global configurable parameter will be added to the 941 OSPFv3 protocol. 943 ExtendedLSASupport 944 This is an enumeration type indicating the extent to which the 945 OSPFv3 instance supports the TLV format described herein for 946 Extended LSAs. The valid value for the enumeration are: 948 * None - Non-extended LSAs will not be originated or used in the 949 SPF calculation. This is the default. 951 * MixedModeOriginateOnly - Both extended and non-extended LSAs 952 will be originated. OSPFv3 adjacencies will be formed with 953 OSPFv3 routers not supporting this specification. The non- 954 extended LSAs are used for the SPF computation. 956 * MixedModeOriginateSPF - Both extended and non-extended LSAs 957 will be originated. OSPFv3 adjacencies will be formed with 958 OSPFv3 routers not supporting this specification. The extended 959 LSAs are used for the SPF computation. 961 * Full - Extended LSAs will be originated and adjacencies will 962 not be formed with OSPFv3 routers not supporting this 963 specification. Only Extended LSAs will be originated. 965 Appendix B. Area Configuration Parameters 967 An additional area configurable parameter will be added to the OSPFv3 968 protocol. 970 AreaExtendedLSASupport 971 This is an enumeration type indicating the extent to which the 972 OSPFv3 area supports the TLV format described herein for Extended 973 LSAs. The valid value for the enumeration are: 975 * InheritGlobal - The AreaExtendedLSASupport will be inherited 976 from ExtendedLSASupport. This is the default. 978 * None - Non-extended LSAs will not be originated or used in the 979 SPF calculation. 981 * MixedModeOriginateOnly - Both extended and non-extended link 982 and area scoped LSAs will be originated. OSPFv3 adjacencies 983 will be formed with OSPFv3 routers not supporting this 984 specification. The non-extended LSAs are used for the SPF 985 computation. 987 * MixedModeOriginateSPF - Both extended and non-extended link and 988 area scoped LSAs will be originated. OSPFv3 adjacencies will 989 be formed with OSPFv3 routers not supporting this 990 specification. The extended LSAs are used for the area SPF 991 computation. 993 * Full - Link and area scoped extended LSAs will be originated 994 and adjacencies will not be formed with OSPFv3 routers not 995 supporting this specification. Only Extended LSAs will be 996 originated. 998 For regular areas, i.e., areas where AS scoped LSAs are flooded, 999 configuring None or MixedModeOriginateOnly for AreaExtendedLSASupport 1000 when Full is specified for ExtendedLSASupport is contradictory and 1001 MAY be prohibited by the implementation. 1003 Authors' Addresses 1005 Acee Lindem 1006 Ericsson 1007 301 Midenhall Way 1008 Cary, NC 27513 1009 USA 1011 Email: acee.lindem@ericsson.com 1013 Sina Mirtorabi 1014 Cisco Systems 1015 170 Tasman Drive 1016 San Jose, CA 95134 1017 USA 1019 Email: sina@cisco.com 1021 Abhay Roy 1022 Cisco Systems 1023 170 Tasman Drive 1024 San Jose, CA 95134 1025 USA 1027 Email: akr@cisco.com 1029 Fred Baker 1030 Cisco Systems 1031 Santa Barbara, CA 93117 1032 USA 1034 Email: fred@cisco.com