idnits 2.17.00 (12 Aug 2021) /tmp/idnits25324/draft-ietf-ospf-ospfv3-lsa-extend-00.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 (October 15, 2013) is 3140 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: April 18, 2014 A. Roy 6 F. Baker 7 Cisco Systems 8 October 15, 2013 10 OSPFv3 LSA Extendibility 11 draft-ietf-ospf-ospfv3-lsa-extend-00.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 April 18, 2014. 41 Copyright Notice 43 Copyright (c) 2013 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.2. LSA TLV Processing Backward Compatibility . . . . . . . . 25 86 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 87 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 88 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 89 15.1. Normative References . . . . . . . . . . . . . . . . . . . 28 90 15.2. Informative References . . . . . . . . . . . . . . . . . . 28 91 Appendix A. Configurable Constants . . . . . . . . . . . . . . . 29 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 94 1. Introduction 96 OSPFv3 requires functional extension beyond what can readily be done 97 with the fixed-format Link State Advertisement (LSA) as described in 98 RFC 5340 [OSPFV3]. Without LSA extension, attributes associated with 99 OSPFv3 links and advertised IPv6 prefixes must be advertised in 100 separate LSAs and correlated to the fixed-format LSA. This document 101 extends the LSA format by allowing the optional inclusion of Type- 102 Length-Value (TLV) tuples in the LSAs. Backward compatibility 103 mechanisms are also described. 105 A similar extension was previously proposed in support of multi- 106 topology routing. Additional requirements for OSPFv3 LSA extension 107 include source/destination routing, route tagging, and others. 109 A final requirement is to limit the changes to OSPFv3 to those 110 necessary for TLV-based LSAs. For the most part, the semantics of 111 existing OSPFv3 LSA are retained for their TLV-based successor LSAs 112 described herein. Additionally, encoding details, e.g., the 113 representation of IPv6 prefixes as described in section A.4.1 in RFC 114 5340 [OSPFV3], have been retained. This requirement was included to 115 increase the expedience of IETF adoption and deployment. 117 The following aspects of OSPFv3 LSA extension are described: 119 1. Extended LSA Types 121 2. Extended LSA Formats 123 3. Backward Compatibility 125 1.1. Requirements notation 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC-KEYWORDS]. 131 1.2. Acknowledgments 133 OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing 134 in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3]. 136 Thanks for Peter Psenak for significant contributions to the backward 137 compatibility mechanisms. 139 Thanks go to Michael Barnes, Mike Dubrovsky, and Anton Smirnov for 140 review of the draft versions and discussions of backward 141 compatibility. 143 The RFC text was produced using Marshall Rose's xml2rfc tool. 145 2. OSPFv3 Extended LSA Types 147 In order to provide backward compatibility, new LSA codes must be 148 allocated. There are eight fixed-format LSAs defined in RFC 5340 149 [OSPFV3]. For ease of implementation and debugging, the LSA function 150 codes are the same as the fixed-format LSAs only with 32, i.e., 0x20, 151 added. The alternative was to allocate a bit in the LSA Type 152 indicating the new LSA format. However, this would have used one 153 half the LSA function code space for the migration of the eight 154 original fixed-format LSAs. For backward compatibility, the U-bit 155 will be set in LS Type so that the LSAs will be flooded by OSPFv3 156 routers that do not understand them. 158 LSA function code LS Type Description 159 ---------------------------------------------------- 160 33 0xA021 E-Router-LSA 161 34 0xA022 E-Network-LSA 162 35 0xA023 E-Inter-Area-Prefix-LSA 163 36 0xA024 E-Inter-Area-Router-LSA 164 37 0xC025 E-AS-External-LSA 165 38 N/A Unused (Not to be allocated) 166 39 0xA027 E-Type-7-LSA 167 40 0x8028 E-Link-LSA 168 41 0xA029 E-Intra-Area-Prefix-LSA 170 OSPFv3 Extended LSA Types 172 3. OSPFv3 Extended LSA TLV 174 The format of the TLVs within the body of the extended LSAs is the 175 same as the format used by the Traffic Engineering Extensions to OSPF 176 [TE]. The variable TLV section consists of one or more nested Type/ 177 Length/Value (TLV) tuples. The format of each TLV is: 179 0 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Type | Length | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Value... | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 TLV Format 189 The Length field defines the length of the value portion in octets 190 (thus a TLV with no value portion would have a length of 0). The TLV 191 is padded to 4-octet alignment; padding is not included in the length 192 field (so a 3-octet value would have a length of 3, but the total 193 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 194 aligned. For example, a 1-byte value would have the length field set 195 to 1, and 3 octets of padding would be added to the end of the value 196 portion of the TLV. Unrecognized types are ignored. 198 4. OSPFv3 E-Router-LSA 200 The E-Router-LSA has an LS Type of 0xA021 and has the same base 201 information content as the Router-LSA, section 4.4.3.2 in [OSPFV3]. 202 However, unlike the existing Router-LSA, it is fully extendable and 203 represented as TLVs. 205 0 1 2 3 206 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 207 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | LS Age |1|0|1| 0x21 | 209 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Link State ID | 211 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Advertising Router | 213 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | LS Sequence Number | 215 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | LS Checksum | Length | 217 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | 0 |Nt|x|V|E|B| Options | 219 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 . . 221 . TLVs . 222 . . 223 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Extended Router-LSA 227 All LSA Header fields are the same as defined for the Router-LSA. 228 The following top-level TLVs are defined: 230 o 0 - Reserved 232 o 1 - Router-Link TLV 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | 1 (Router-Link) | TLV Length | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Type | 0 | Metric | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Interface ID | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Neighbor Interface ID | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Neighbor Router ID | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 . . 247 . sub-TLVs . 248 . . 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Router-Link TLV 253 Like the existing Router-LSA, the LSA length is used to determine the 254 end of the LSA including TLVs. The Router-Link TLV is only 255 applicable to the E-Router-LSA. Inclusion in other Extended LSAs 256 MUST be ignored. 258 5. OSPFv3 E-Network-LSA 260 The E-Network-LSA has an LS Type of 0xA022 and has the same base 261 information content as the Network-LSA, section 4.4.3.3 in [OSPFV3]. 262 However, unlike the existing Network-LSA, it is fully extendable and 263 represented as TLVs. 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | LS Age |1|0|1| 0x22 | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Link State ID | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Advertising Router | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | LS Sequence Number | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | LS Checksum | Length | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | 0 | Options | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 . . 281 . TLVs . 282 . . 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 E-Network-LSA 287 All LSA Header fields are the same as defined for the Network-LSA. 288 The following top-level TLVs are defined: 290 o 2 - Attached-Routers TLV 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 her 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 of the size of the E-Network-LSA requiring IPv6 316 fragmentation when advertised in an OSPFv3 Link State Update packet. 318 Like the existing Network-LSA, the LSA length is used to determine 319 the end of the LSA including TLVs. The Attached-Routers TLV is only 320 applicable to the E-Network-LSA. Inclusion in other Extended LSAs 321 MUST be ignored. 323 6. OSPFv3 E-Inter-Area-Prefix-LSA 325 The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same 326 base information content as the Inter-Area-Prefix-LSA, section 327 4.4.3.4 in [OSPFV3]. However, unlike the existing Inter-Area-Prefix- 328 LSA, it is fully extendable and represented as TLVs. 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | LS Age |1|0|1| 0x23 | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Link State ID | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Advertising Router | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | LS Sequence Number | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | LS Checksum | Length | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 . . 344 . TLVs . 345 . . 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 E-Inter-Area-Prefix-LSA 350 All LSA Header fields are the same as defined for the Network-LSA. 351 The following top-level TLVs are defined: 353 o 3 - Inter-Area Prefix TLV 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | 3 (Inter-Area Prefix) | TLV Length | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | 0 | Metric | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | PrefixLength | PrefixOptions | 0 | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Address Prefix | 364 | ... | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 . . 367 . sub-TLVs . 368 . . 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Inter-Area Prefix TLV 373 In order to retain compatibility and semantics with the current 374 OSPFv3 specification, each LSA MUST contain a single Inter-Area 375 Prefix TLV. This will facilitate migration and avoid changes to 376 functions such as incremental SPF computation. 378 Like the existing Inter-Area-Prefix-LSA, the LSA length is used to 379 determine the end of the LSA including TLV. The Inter-Area-Prefix 380 TLV is only applicable to the E-Inter-Area-Prefix-LSA. Inclusion in 381 other Extended LSAs MUST be ignored. 383 7. OSPFv3 E-Inter-Area-Router-LSA 385 The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same 386 base information content as the Inter-Area-Router-LSA, section 387 4.4.3.5 in [OSPFV3]. However, unlike the Inter-Area-Router-LSA, it 388 is fully extendable and represented as TLVs. 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | LS Age |1|0|1| 0x24 | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Link State ID | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Advertising Router | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | LS Sequence Number | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | LS Checksum | Length | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 . . 404 . TLVs . 405 . . 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 E-Inter-Area-Router-LSA 410 All LSA Header fields are the same as defined for the Inter-Area- 411 Router-LSA. The following top-level TLVs are defined: 413 o 4 - Inter-Area Router TLV 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | 3 (Inter-Area Router) | TLV Length | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | 0 | Options | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | 0 | Metric | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Destination Router ID | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 . . 426 . sub-TLVs . 427 . . 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 Inter-Area Router TLV 432 In order to retain compatibility and semantics with the current 433 OSPFv3 specification, each LSA MUST contain a single Inter-Area 434 Router TLV. This will facilitate migration and avoid changes to 435 functions such as incremental SPF computation. 437 Like the existing Inter-Area-Router-LSA, the LSA length is used to 438 determine the end of the LSA including sub-TLVs. The Inter-Area- 439 Router TLV is only applicable to the E-Inter-Area-Router-LSA. 440 Inclusion in other Extended LSAs MUST be ignored. 442 8. OSPFv3 E-AS-External-LSA 444 The E-AS-External-LSA has an LS Type of 0xC025 and has the same base 445 information content as the AS-External-LSA, section 4.4.3.6 in 446 [OSPFV3]. However, unlike the existing AS-External-LSA, it is fully 447 extendable and represented as TLVs. 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | LS Age |1|1|0| 0x25 | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Link State ID | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Advertising Router | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | LS Sequence Number | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | LS Checksum | Length | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 . . 463 . TLVs . 464 . . 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 E-AS-External-LSA 469 All LSA Header fields are the same as defined for the AS-External- 470 LSA. The following top-level TLVs are defined: 472 o 5 - External Prefix TLV 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | 5 (External Prefix) | TLV Length | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | |E| | | Metric | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | PrefixLength | PrefixOptions | 0 | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Address Prefix | 483 | ... | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 . . 486 . sub-TLVs . 487 . . 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 External Prefix TLV 492 In order to retain compatibility and semantics with the current 493 OSPFv3 specification, each LSA MUST contain a single External Prefix 494 TLV. This will facilitate migration and avoid changes to OSPFv3 495 processes such as incremental SPF computation. In External Prefix 496 TLV, the optional Forwarding Address and External Route Tag are now 497 sub-TLVs. Given the Referenced LS type and Referenced Link State ID 498 from the AS-External-LSA have never been used or even specified, they 499 have been omitted from the External Prefix TLV. If there were ever a 500 requirement for a referenced LSA, it could be satisfied with a sub- 501 TLV. 503 Like the existing AS-External-LSA, the LSA length is used to 504 determine the end of the LSA including sub-TLVs. The External-Prefix 505 TLV is only applicable to the E-AS-External-LSA and the E-NSSA-LSA. 506 Inclusion in other Extended LSAs MUST be ignored. 508 The following sub-TLVs are defined for the External Prefix TLV: 510 o 1 - Forwarding Address sub-TLV 512 o 2 - Route Tag sub-TLV 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | 1 - Forwarding Address | sub-TLV Length (16) | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | | 519 +- -+ 520 | | 521 +- Forwarding Address -+ 522 | | 523 +- -+ 524 | | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 External Route Tag Sub-TLV 529 The optional Forwarding Address sub-TLV has identical semantics to 530 the optional forwarding address in section 4.4.3.6 of [OSPFV3]. The 531 Forwarding Address sub-TLV is applicable to the External-Prefix TLV. 532 Specification as a sub-TLV of other TLVs is not defined herein. The 533 sub-TLV is optional and the first specified instance is used as the 534 Forwarding Address as defined in [OSPFV3]. Instances subsequent to 535 the first are ignored. 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | 2 - Route Tag | sub-TLV Length (4) | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Route Tag | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 Route Tag Sub-TLV 547 The optional Route Tag sub-TLV has identical semantics to the 548 optional External Route Tag in section 4.4.3.6 of [OSPFV3]. The 549 Route Tag sub-TLV is applicable to the External-Prefix TLV. 550 Specification as a sub-TLV of other TLVs is not defined herein. The 551 sub-TLV is optional and the first specified instance is used as the 552 Route Tag as defined in [OSPFV3]. Instances subsequent to the first 553 are ignored. 555 9. OSPFv3 E-NSSA-LSA 557 The E-NSSA-LSA will have the same format and TLVs as the Extended AS- 558 External-LSA Section 8. This is the same relationship as exists 559 between the NSSA-LSA, section 4.4.3.7 in [OSPFV3], and the AS- 560 External-LSA. The NSSA-LSA will have type 0xA027 which implies area 561 flooding scope. Future requirements may dictate that supported TLVs 562 differ between the E-AS-External-LSA and the E-NSSA-LSA. However, 563 future requirements are beyond the scope of this document. 565 10. OSPFv3 E-Link-LSA 567 The E-Link-LSA has an LS Type of 0x8028 and will have the same base 568 information content as the Link-LSA, section 4.4.3.8 in [OSPFV3]. 569 However, unlike the existing Link-LFA, it is extendable and 570 represented as TLVs. 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | LS Age |1|0|0| 0x28 | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Link State ID | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Advertising Router | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | LS Sequence Number | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | LS Checksum | Length | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Rtr Priority | Options | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 . . 588 . TLVs . 589 . . 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 E-Link-LSA 594 The following top-level TLVs are defined: 596 o 6 - Intra-Area Prefix TLV 598 o 7 - IPv6 Link-Local Address TLV 600 o 8 - IPv4 Link-Local Address TLV 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | 6 (Intra-Area Prefix) | TLV Length | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | 0 | Metric | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | PrefixLength | PrefixOptions | 0 | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Address Prefix | 611 | ... | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 . . 614 . sub-TLVs . 615 . . 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Intra-Area Prefix TLV 620 Like the Link-LSA, the E-Link-LSA affords advertisement of multiple 621 intra-area prefixes. Hence, multiple Intra-Area Prefix TLVs may be 622 specified and the LSA length defines the end of the LSA including all 623 TLVs. The Intra-Area-Prefix TLV is only applicable to the E-Link-LSA 624 and the E-Intra-Area-Prefix-LSA. Inclusion in other Extended LSAs 625 MUST be ignored. 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | 7 (IPv6 Local-Local Address) | TLV Length | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | | 633 +- -+ 634 | | 635 +- IPv6 Link-Local Interface Address -+ 636 | | 637 +- -+ 638 | | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 . . 641 . sub-TLVs . 642 . . 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 IPv6 Link-Local Address TLV 647 The IPv6 Link-Local Address TLV is to be used with IPv6 address 648 families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV 649 is only applicable to the E-Link-LSA. Inclusion in other Extended 650 LSAs MUST be ignored. Only a single instance of the IPv6 Link-Local 651 Address family SHOULD be included in the E-Link-LSA. Instances 652 following the first MUST be ignored. For IPv4 address families as 653 defined in [OSPFV3-AF], this TLV SHOULD be ignored. Future 654 specifications may support advertisement of routing and topology 655 information for multiple address families. However, this is beyond 656 the scope of this document. 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 | 8 (IPv4 Local-Local Address) | TLV Length | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | IPv4 Link-Local Interface Address | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 . . 666 . sub-TLVs . 667 . . 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 IPv4 Link-Local Address TLV 672 The IPv4 Link-Local Address TLV is to be used with IPv4 address 673 families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV 674 is only applicable to the E-Link-LSA. Inclusion in other Extended 675 LSAs MUST be ignored. Only a single instance of the IPv4 Link-Local 676 Address family SHOULD be included in the E-Link-LSA. Instances 677 following the first MUST be ignored. For OSPFv3 IPv6 address 678 families as defined in [OSPFV3-AF], this TLV MUST be ignored. Future 679 specifications may support advertisement of routing and topology 680 information for multiple address families. However, this is beyond 681 the scope of this document. 683 11. OSPFv3 E-Intra-Area-Prefix-LSA 685 The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same 686 base information content as the Intra-Area-Prefix-LSA, section 687 4.4.3.9 in [OSPFV3]. However, unlike the Intra-Area-Prefix-LSA, it 688 is fully extendable and represented as TLVs. 690 0 1 2 3 691 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 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | LS Age |1|0|1| 0x29 | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Link State ID | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Advertising Router | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | LS Sequence Number | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | LS Checksum | Length | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | 0 | Referenced LS Type | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Referenced Link State ID | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Referenced Advertising Router | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 . . 710 . TLVs . 711 . . 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 E-Intra-Area-Prefix-LSA 716 All LSA Header fields are the same as defined for the Intra-Area- 717 Prefix-LSA. The following top-level TLVs are defined: 719 o 6 - Intra-Area-Prefix TLV (defined in Section 10) 721 Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords 722 advertisement of multiple intra-area prefixes. Hence, multiple 723 Intra-Area Prefix TLVs may be specified and the LSA length defines 724 the end of the LSA including all TLVs. 726 12. LSA Extension Backward Compatibility 728 In the context of this document, backward compatibility is solely 729 related to the capability of an OSPFv3 router to receive, process, 730 and originate the TLV-based LSAs defined herein. Backward 731 compatibility for future OSPFv3 extensions utilizing the TLV-based 732 LSAs is out of scope and must be covered in the documents describing 733 those extensions. Both full and, if applicable, partial deployment 734 should be covered for future OSPFv3 LSA extensions. 736 For simplicity and to avoid the scaling impact of maintaining both 737 TLV and non-TLV based versions of the same LSA within a routing 738 domain, the base backward compatibility mode will not allow mixing of 739 LSA formats. Different formats could still be supported with 740 multiple OSPFv3 instances and separate OSPFv3 routing domains. 741 Additionally, a more complex mode is provided in Section 12.1, where 742 both formats of LSA coexist. An OSPFv3 instance will be configured 743 to use either the Non-TLV-based LSAs, TLV-based LSAs, or support both 744 (Appendix A). In order to facilitate backward compatibility, the 745 OSPFv3 options field (as described in Appendix A.2 of RFC 5340 746 [OSPFV3]), will contain an additional options bits. The EL-bit will 747 be used to indicate that the advertising OSPFv3 Router can receive, 748 process, and originate TLV-based LSAs. An OSPFv3 router configured 749 to support TLV-based LSAs WILL set its option field EL-bit in OSPFv3 750 Hello and Database Description packets. If "Normal" is specified for 751 ExtendedLSASupport, the OSPFv3 router MUST NOT form adjacencies with 752 OSPFv3 Routers sending OSPFv3 Hello and Database Description packets 753 with the options field EL-bit clear. In this manner, OSPFv3 routing 754 domains utilizing the new encoding will be completely isolated from 755 those using the RFC 5340 encodings. 757 1 2 758 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 759 +-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+--+-+-+--+-+-+-+--+--+ 760 | | | | | | | | | | | | |EL|AT|L|AF|*|*|DC|R|N|x| E|V6| 761 +-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+--+-+-+--+-+-+-+--+--+ 762 The Options field 764 EL-bit 765 This bit is indicates whether or not the OSPFv3 router 766 supports the Extended LSA format with the bit set condition 767 indicating support. 769 Options Field EL-bit 771 12.1. Extended LSA Mixed-Mode Backward Compatibility 773 An implementation MAY support configuration allowing a mixture of 774 OSPFv3 routers supporting and not supporting TLV-based LSAs in the 775 same OSPFv3 routing domain. In these deployments, the OSPFv3 routers 776 configured with a value of MixedMode or MixedModeDegraded for 777 ExtendedLSASupport, (Appendix A), MUST originate both the TLV-based 778 and non-TLV-based versions of the OSPFv3 LSAs described herein. For 779 the purposes of Shortest Path First (SPF) computation, if the 780 configured value is MixedMode, the TLV-based LSAs MUST be used by 781 OSPFv3 routers supporting this specification. If MixedModeDegraded 782 is configured, the non-TLV-based versions of the OSPFv3 LSAs are used 783 for SPF computation. OSPFv3 routers configured for mixed mode 784 operation also MUST form adjacencies with OSPFv3 Routers sending 785 OSPFv3 Hello and Database Description packets with the options field 786 EL-bit clear. In this manner, OSPFv3 routing domains utilizing the 787 new encodings can be gradually migrated with a worst-case cost of 788 approximately doubling the number of LSAs in the routing domain. 790 12.2. LSA TLV Processing Backward Compatibility 792 This section defines the general rules for processing LSA TLVs. To 793 ensure compatibility of future TLV-based LSA extensions, all 794 implementations MUST adhere to these rules: 796 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or 797 processing Extended-LSAs. 799 2. Whether or not partial deployment of a given TLV is supported 800 MUST be specified. 802 3. If partial deployment is not supported, mechanisms to ensure the 803 corresponding feature are not deployed MUST be specified in the 804 document defining the new TLV or sub-TLV. 806 4. If partial deployment is supported, backward compatibility and 807 partial deployment MUST be specified in the document defining the 808 new TLV or sub-TLV. 810 13. Security Considerations 812 In general, extendible OSPFv3 LSAs are subject to the same security 813 concerns as those described in RFC 5340 [OSPFV3]. Additionally, 814 implementations must assure that malformed TLV and Sub-TLV 815 permutations do not result in errors which cause hard OSPFv3 816 failures. 818 If there were ever a requirement to digitally sign OSPFv3 LSAs as 819 described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the 820 mechanisms described herein would greatly simplify the extension. 822 14. IANA Considerations 824 This specification defines nine OSPFv3 Extended LSA types as 825 described in Section 2. 827 This specification also creates two registries OSPFv3 Extended-LSAs 828 TLVs and sub-TLVs. The TLV and Sub-TLV code-points in these 829 registries are common to all Extended-LSAs and their respective 830 definitions must define where they are applicable. 832 The OSPFv3 Extend-LSA TLV registry will define top-level TLVs for 833 Extended-LSAs and should be placed in the existing OSPFv3 IANA 834 registry. New values can be allocated via IETF Consensus or IESG 835 Approval. 837 Nine initial values are allocated: 839 o 0 - Reserved 841 o 1 - Router-Link TLV 843 o 2 - Attached-Routers TLV 845 o 3 - Inter-Area Prefix TLV 847 o 4 - Inter-Area Router TLV 849 o 5 - External Prefix TLV 851 o 6 - Intra-Area Prefix TLV 853 o 7 - IPv6 Link-Local Address TLV 855 o 8 - IPv4 Link-Local Address TLV 857 The OSPFv3 Extend-LSA sub-TLV registry will define sub-TLVs at any 858 level of nesting for Extended-LSAs and should be placed in the 859 existing OSPFv3 IANA registry. New values can be allocated via IETF 860 Consensus or IESG Approval. 862 One initial value is allocated: 864 o 0 - Reserved 866 o 1 - Forwarding Address 868 o 2 - Route Tag 870 15. References 872 15.1. Normative References 874 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 875 for IPv6", RFC 5340, July 2008. 877 [OSPFV3-AF] 878 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 879 Aggarwal, "Support of Address Families in OSPFv3", 880 RFC 5838, April 2010. 882 [RFC-KEYWORDS] 883 Bradner, S., "Key words for use in RFCs to Indicate 884 Requirement Levels", RFC 2119, March 1997. 886 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 887 Extensions to OSPF", RFC 3630, September 2003. 889 15.2. Informative References 891 [MT-OSPFV3] 892 Mirtorabi, S. and A. Roy, "Multi-topology routing in 893 OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt 894 (work in progress). 896 [OSPF-DIGITAL-SIGNATURE] 897 Murphy, S., Badger, M., and B. Wellington, "OSPF with 898 Digital Signatures", RFC 2154, June 1997. 900 Appendix A. Configurable Constants 902 An additional global configurable constant will be added to the 903 OSPFv3 protocol. 905 ExtendedLSASupport 906 This is an enumeration type indicating the extent to which the 907 OSPFv3 instance supports the TLV format described herein for 908 Extended LSAs. The valid value for the enumeration are: 910 * None - Non-extended LSAs will not be originated or used in the 911 SPF calculation. 913 * Normal - Extended LSAs will be originated and adjacencies will 914 not be formed with OSPFv3 routers not supporting this 915 specification. 917 * MixedMode - Both extended and non-extended LSAs will be 918 originated. OSPFv3 adjacencies will be formed with OSPFv3 919 routers not supporting this specification. The extended LSAs 920 are used for the SPF computation. 922 * MixedModeDegraded - Both extended and non-extended LSAs will be 923 originated. OSPFv3 adjacencies will be formed with OSPFv3 924 routers not supporting this specification. The non-extended 925 LSAs are used for the SPF computation. 927 Authors' Addresses 929 Acee Lindem 930 Ericsson 931 301 Midenhall Way 932 Cary, NC 27513 933 USA 935 Email: acee.lindem@ericsson.com 937 Sina Mirtorabi 938 Cisco Systems 939 170 Tasman Drive 940 San Jose, CA 95134 941 USA 943 Email: sina@cisco.com 945 Abhay Roy 946 Cisco Systems 947 170 Tasman Drive 948 San Jose, CA 95134 949 USA 951 Email: akr@cisco.com 953 Fred Baker 954 Cisco Systems 955 Santa Barbara, CA 93117 956 USA 958 Email: fred@cisco.com