idnits 2.17.1 draft-acee-ospfv3-lsa-extend-02.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 (September 10, 2013) is 3881 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: March 14, 2014 A. Roy 6 F. Baker 7 Cisco Systems 8 September 10, 2013 10 OSPFv3 LSA Extendibility 11 draft-acee-ospfv3-lsa-extend-02.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 March 14, 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 . . . . . . . . . . . . . . . . . . . . . . 18 81 10. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . . . 19 82 11. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . . . . 22 83 12. LSA Extension Backward Compatibility . . . . . . . . . . . . . 23 84 12.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . . 24 85 12.2. LSA TLV Processing Backward Compatibility . . . . . . . . 24 86 13. Security Considerations . . . . . . . . . . . . . . . . . . . 25 87 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 88 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 15.1. Normative References . . . . . . . . . . . . . . . . . . . 27 90 15.2. Informative References . . . . . . . . . . . . . . . . . . 27 91 Appendix A. Configurable Constants . . . . . . . . . . . . . . . 28 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 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 . . 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Attached-Routers TLV 307 There are two reasons for not having a separate TLV or sub-TLV for 308 each adjacent neighbor. The first is to discourage using the 309 E-Network-LSA for more than its current role of solely advertising 310 the routers attached to a multi-access network. The router's metric 311 as well as her attributes of individual attached routers should be 312 advertised in their respective E-Router-LSAs. The second reason is 313 that there is only a single E-Network-LSA per multi-access link with 314 the Link State ID set to the Designated Router's Interface ID and, 315 consequently, compact encoding has been chosen to decrease the 316 likelihood of the size of the E-Network-LSA requiring IPv6 317 fragmentation when advertised in an OSPFv3 Link State Update packet. 319 Like the existing Network-LSA, the LSA length is used to determine 320 the end of the LSA including TLVs. The Attached-Routers TLV is only 321 applicable to the E-Network-LSA. Inclusion in other Extended LSAs 322 MUST be ignored. 324 6. OSPFv3 E-Inter-Area-Prefix-LSA 326 The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same 327 base information content as the Inter-Area-Prefix-LSA, section 328 4.4.3.4 in [OSPFV3]. However, unlike the existing Inter-Area-Prefix- 329 LSA, it is fully extendable and represented as TLVs. 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | LS Age |1|0|1| 0x23 | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Link State ID | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Advertising Router | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | LS Sequence Number | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | LS Checksum | Length | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 . . 345 . TLVs . 346 . . 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 E-Inter-Area-Prefix-LSA 351 All LSA Header fields are the same as defined for the Network-LSA. 352 The following top-level TLVs are defined: 354 o 3 - Inter-Area Prefix TLV 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 | 3 (Inter-Area Prefix) | TLV Length | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | 0 | Metric | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | PrefixLength | PrefixOptions | 0 | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Address Prefix | 365 | ... | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 . . 368 . sub-TLVs . 369 . . 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Inter-Area Prefix TLV 374 In order to retain compatibility and semantics with the current 375 OSPFv3 specification, each LSA MUST contain a single Inter-Area 376 Prefix TLV. This will facilitate migration and avoid changes to 377 functions such as incremental SPF computation. 379 Like the existing Inter-Area-Prefix-LSA, the LSA length is used to 380 determine the end of the LSA including TLV. The Inter-Area-Prefix 381 TLV is only applicable to the E-Inter-Area-Prefix-LSA. Inclusion in 382 other Extended LSAs MUST be ignored. 384 7. OSPFv3 E-Inter-Area-Router-LSA 386 The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same 387 base information content as the Inter-Area-Router-LSA, section 388 4.4.3.5 in [OSPFV3]. However, unlike the Inter-Area-Router-LSA, it 389 is fully extendable and represented as TLVs. 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | LS Age |1|0|1| 0x24 | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Link State ID | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Advertising Router | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | LS Sequence Number | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | LS Checksum | Length | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 . . 405 . TLVs . 406 . . 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 E-Inter-Area-Router-LSA 411 All LSA Header fields are the same as defined for the Inter-Area- 412 Router-LSA. The following top-level TLVs are defined: 414 o 4 - Inter-Area Router TLV 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | 3 (Inter-Area Router) | TLV Length | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | 0 | Options | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | 0 | Metric | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Destination Router ID | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 . . 427 . sub-TLVs . 428 . . 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 Inter-Area Router TLV 433 In order to retain compatibility and semantics with the current 434 OSPFv3 specification, each LSA MUST contain a single Inter-Area 435 Router TLV. This will facilitate migration and avoid changes to 436 functions such as incremental SPF computation. 438 Like the existing Inter-Area-Router-LSA, the LSA length is used to 439 determine the end of the LSA including sub-TLVs. The Inter-Area- 440 Router TLV is only applicable to the E-Inter-Area-Router-LSA. 441 Inclusion in other Extended LSAs MUST be ignored. 443 8. OSPFv3 E-AS-External-LSA 445 The E-AS-External-LSA has an LS Type of 0xC025 and has the same base 446 information content as the AS-External-LSA, section 4.4.3.6 in 447 [OSPFV3]. However, unlike the existing AS-External-LSA, it is fully 448 extendable and represented as TLVs. 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | LS Age |1|1|0| 0x25 | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Link State ID | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Advertising Router | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | LS Sequence Number | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | LS Checksum | Length | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 . . 464 . TLVs . 465 . . 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 E-AS-External-LSA 470 All LSA Header fields are the same as defined for the AS-External- 471 LSA. The following top-level TLVs are defined: 473 o 5 - External Prefix TLV 474 0 1 2 3 475 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | 5 (External Prefix) | TLV Length | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | |E|F|T| Metric | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | PrefixLength | PrefixOptions | 0 | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Address Prefix | 484 | ... | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | | 487 +- -+ 488 | | 489 +- Forwarding Address (Optional) -+ 490 | | 491 +- -+ 492 | | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | External Route Tag (Optional) | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 . . 497 . sub-TLVs . 498 . . 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 External Prefix TLV 503 In order to retain compatibility and semantics with the current 504 OSPFv3 specification, each LSA MUST contain a single External Prefix 505 TLV. This will facilitate migration and avoid changes to functions 506 such as incremental SPF computation. Given the Referenced LS type 507 and Referenced Link State ID from the AS-External-LSA have never been 508 used or even specified, they have been omitted from the External 509 Prefix TLV. If there were ever a requirement for a referenced LSA, 510 it could be satisfied with a sub-TLV. 512 Like the existing AS-External-LSA, the LSA length is used to 513 determine the end of the LSA including sub-TLVs. The External-Prefix 514 TLV is only applicable to the E-AS-External-LSA and the E-NSSA-LSA. 515 Inclusion in other Extended LSAs MUST be ignored. 517 9. OSPFv3 E-NSSA-LSA 519 The E-NSSA-LSA will have the same format and TLVs as the Extended AS- 520 External-LSA Section 8. This is the same relationship as exists 521 between the NSSA-LSA, section 4.4.3.7 in [OSPFV3], and the AS- 522 External-LSA. The NSSA-LSA will have type 0xA027 which implies area 523 flooding scope. Future requirements may dictate that supported TLVs 524 differ between the E-AS-External-LSA and the E-NSSA-LSA. However, 525 future requirements are beyond the scope of this document. 527 10. OSPFv3 E-Link-LSA 529 The E-Link-LSA has an LS Type of 0x8028 and will have the same base 530 information content as the Link-LSA, section 4.4.3.8 in [OSPFV3]. 531 However, unlike the existing Link-LFA, it is extendable and 532 represented as TLVs. 534 0 1 2 3 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | LS Age |1|0|0| 0x28 | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Link State ID | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Advertising Router | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | LS Sequence Number | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | LS Checksum | Length | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Rtr Priority | Options | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 . . 550 . TLVs . 551 . . 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 E-Link-LSA 556 The following top-level TLVs are defined: 558 o 6 - Intra-Area Prefix TLV 560 o 7 - IPv6 Link-Local Address TLV 562 o 8 - IPv4 Link-Local Address TLV 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | 6 (Intra-Area Prefix) | TLV Length | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | 0 | Metric | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | PrefixLength | PrefixOptions | 0 | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Address Prefix | 573 | ... | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 . . 576 . sub-TLVs . 577 . . 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Intra-Area Prefix TLV 582 Like the Link-LSA, the E-Link-LSA affords advertisement of multiple 583 intra-area prefixes. Hence, multiple Intra-Area Prefix TLVs may be 584 specified and the LSA length defines the end of the LSA including all 585 TLVs. The Intra-Area-Prefix TLV is only applicable to the E-Link-LSA 586 and the E-Intra-Area-Prefix-LSA. Inclusion in other Extended LSAs 587 MUST be ignored. 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | 7 (IPv6 Local-Local Address) | TLV Length | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | | 595 +- -+ 596 | | 597 +- IPv6 Link-Local Interface Address -+ 598 | | 599 +- -+ 600 | | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 . . 603 . sub-TLVs . 604 . . 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 IPv6 Link-Local Address TLV 609 The IPv6 Link-Local Address TLV is to be used with IPv6 address 610 families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV 611 is only applicable to the E-Link-LSA. Inclusion in other Extended 612 LSAs MUST be ignored. Only a single instance of the IPv6 Link-Local 613 Address family SHOULD be included in the E-Link-LSA. Instances 614 preceding the first MUST be ignored. For IPv4 address families as 615 defined in [OSPFV3-AF], this TLV SHOULD be ignored. Future 616 specifications may support advertisement of routing and topology 617 information for multiple address families. However, this is beyond 618 the scope of this document. 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | 8 (IPv4 Local-Local Address) | TLV Length | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | IPv4 Link-Local Interface Address | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 . . 628 . sub-TLVs . 629 . . 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 IPv4 Link-Local Address TLV 634 The IPv4 Link-Local Address TLV is to be used with IPv4 address 635 families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV 636 is only applicable to the E-Link-LSA. Inclusion in other Extended 637 LSAs MUST be ignored. Only a single instance of the IPv4 Link-Local 638 Address family SHOULD be included in the E-Link-LSA. Instances 639 preceding the first MUST be ignored. For IPv6 address families as 640 defined in [OSPFV3-AF]. Future specifications may support 641 advertisement of routing and topology information for multiple 642 address families. However, this is beyond the scope of this 643 document. 645 11. OSPFv3 E-Intra-Area-Prefix-LSA 647 The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same 648 base information content as the Intra-Area-Prefix-LSA, section 649 4.4.3.9 in [OSPFV3]. However, unlike the Intra-Area-Prefix-LSA, it 650 is fully extendable and represented as TLVs. 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | LS Age |1|0|1| 0x29 | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Link State ID | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Advertising Router | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | LS Sequence Number | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | LS Checksum | Length | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | 0 | Referenced LS Type | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Referenced Link State ID | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Referenced Advertising Router | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 . . 672 . TLVs . 673 . . 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 E-Intra-Area-Prefix-LSA 678 All LSA Header fields are the same as defined for the Intra-Area- 679 Prefix-LSA. The following top-level TLVs are defined: 681 o 6 - Intra-Area-Prefix TLV (defined in Section 10) 683 Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords 684 advertisement of multiple intra-area prefixes. Hence, multiple 685 Intra-Area Prefix TLVs may be specified and the LSA length defines 686 the end of the LSA including all TLVs. 688 12. LSA Extension Backward Compatibility 690 In the context of this document, backward compatibility is solely 691 related to the capability of an OSPFv3 router to receive, process, 692 and originate the TLV-based LSAs defined herein. Backward 693 compatibility for future OSPFv3 extensions utilizing the TLV-based 694 LSAs is out of scope and must be covered in the documents describing 695 those extensions. Both full and, if applicable, partial deployment 696 should be covered for future OSPFv3 LSA extensions. 698 For simplicity and to avoid the scaling impact of maintaining both 699 TLV and non-TLV based versions of the same LSA within a routing 700 domain, the basic backward compatibility mode will not allow mixing 701 of LSA formats. Different formats could still be supported with 702 multiple OSPFv3 instances and separate OSPFv3 routing domains. 703 Additionally, a more complex mode is provided in Section 12.1, where 704 both formats of LSA coexist. An OSPFv3 instance will be configured 705 to use either the Non-TLV-based LSAs, TLV-based LSAs, or support both 706 (Appendix A). In order to facilitate backward compatibility, the 707 OSPFv3 options field (as described in Appendix A.2 of RFC 5340 708 [OSPFV3]), will contain an additional options bits. The EL-bit will 709 be used to indicate that the advertising OSPFv3 Router can receive, 710 process, and originate TLV-based LSAs. An OSPFv3 router configured 711 to support TLV-based LSAs WILL set its option field EL-bit in OSPFv3 712 Hello and Database Description packets. If "Normal" is specified for 713 ExtendedLSASupport, the OSPFv3 router MUST NOT form adjacencies with 714 OSPFv3 Routers sending OSPFv3 Hello and Database Description packets 715 with the options field EL-bit clear. In this manner, OSPFv3 routing 716 domains utilizing the new encoding will be completely isolated from 717 those using the RFC 5340 encodings. 719 1 2 720 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 721 +-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+--+-+-+--+-+-+-+--+--+ 722 | | | | | | | | | | | | |EL|AT|L|AF|*|*|DC|R|N|x| E|V6| 723 +-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+--+-+-+--+-+-+-+--+--+ 724 The Options field 726 EL-bit 727 This bit is indicates whether or not the OSPFv3 router 728 supports the Extended LSA format with the bit set condition 729 indicating support. 731 Options Field EL-bit 733 12.1. Extended LSA Mixed-Mode Backward Compatibility 735 An implementation MAY support configuration allowing a mixture of 736 OSPFv3 routers supporting and not supporting TLV-based LSAs in the 737 same OSPFv3 routing domain. In these deployments, the OSPFv3 routers 738 configured with a value of MixedMode or MixedModeDegraded for 739 ExtendedLSASupport, (Appendix A), MUST originate both the TLV-based 740 and non-TLV-based versions of the OSPFv3 LSAs described herein. For 741 the purposes of Shortest Path First (SPF) computation, if the 742 configured value is MixedMode, the TLV-based LSAs MUST be used by 743 OSPFv3 routers supporting this specification. If MixedModeDegraded 744 is configured, the non-TLV-based versions of the OSPFv3 LSAs are used 745 for SPF computation. OSPFv3 routers configured for mixed mode 746 operation also MUST form adjacencies with OSPFv3 Routers sending 747 OSPFv3 Hello and Database Description packets with the options field 748 EL-bit clear. In this manner, OSPFv3 routing domains utilizing the 749 new encodings can be gradually migrated with a worst-case cost of 750 approximately doubling the number of LSAs in the routing domain. 752 12.2. LSA TLV Processing Backward Compatibility 754 This section defines the general rules for processing LSA TLVs. To 755 ensure compatibility of future TLV-based LSA extensions, all 756 implementations MUST adhere to these rules: 758 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or 759 processing Extended-LSAs. 761 2. Whether or not partial deployment of a given TLV is supported 762 MUST be specified. 764 3. If partial deployment is not supported, mechanisms to ensure the 765 corresponding feature are not deployed MUST be specified in the 766 document defining the new TLV or sub-TLV. 768 4. If partial deployment is supported, backward compatibility and 769 partial deployment MUST be specified in the document defining the 770 new TLV or sub-TLV. 772 13. Security Considerations 774 In general, extendible OSPFv3 LSAs are subject to the same security 775 concerns as those described in RFC 5340 [OSPFV3]. Additionally, 776 implementations must assure that malformed TLV and Sub-TLV 777 permutations do not result in errors which cause hard OSPFv3 778 failures. 780 If there were ever a requirement to digitally sign OSPFv3 LSAs as 781 described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the 782 mechanisms described herein would greatly simplify the extension. 784 14. IANA Considerations 786 This specification defines nine OSPFv3 Extended LSA types as 787 described in Section 2. 789 This specification also creates two registries OSPFv3 Extended-LSAs 790 TLVs and sub-TLVs. The TLV and Sub-TLV code-points in these 791 registries are common to all Extended-LSAs and their respective 792 definitions must define where they are applicable. 794 The OSPFv3 Extend-LSA TLV registry will define top-level TLVs for 795 Extended-LSAs and should be placed in the existing OSPFv3 IANA 796 registry. New values can be allocated via IETF Consensus or IESG 797 Approval. 799 Nine initial values are allocated: 801 o 0 - Reserved 803 o 1 - Router-Link TLV 805 o 2 - Attached-Routers TLV 807 o 3 - Inter-Area Prefix TLV 809 o 4 - Inter-Area Router TLV 811 o 5 - External Prefix TLV 813 o 6 - Intra-Area Prefix TLV 815 o 7 - IPv6 Link-Local Address TLV 817 o 8 - IPv4 Link-Local Address TLV 819 The OSPFv3 Extend-LSA sub-TLV registry will define sub-TLVs at any 820 level of nesting for Extended-LSAs and should be placed in the 821 existing OSPFv3 IANA registry. New values can be allocated via IETF 822 Consensus or IESG Approval. 824 One initial value is allocated: 826 o 0 - Reserved 828 15. References 830 15.1. Normative References 832 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 833 for IPv6", RFC 5340, July 2008. 835 [OSPFV3-AF] 836 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 837 Aggarwal, "Support of Address Families in OSPFv3", 838 RFC 5838, April 2010. 840 [RFC-KEYWORDS] 841 Bradner, S., "Key words for use in RFCs to Indicate 842 Requirement Levels", RFC 2119, March 1997. 844 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 845 Extensions to OSPF", RFC 3630, September 2003. 847 15.2. Informative References 849 [MT-OSPFV3] 850 Mirtorabi, S. and A. Roy, "Multi-topology routing in 851 OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt 852 (work in progress). 854 [OSPF-DIGITAL-SIGNATURE] 855 Murphy, S., Badger, M., and B. Wellington, "OSPF with 856 Digital Signatures", RFC 2154, June 1997. 858 Appendix A. Configurable Constants 860 An additional global configurable constant will be added to the 861 OSPFv3 protocol. 863 ExtendedLSASupport 864 This is an enumeration type indicating the extent to which the 865 OSPFv3 instance supports the TLV format described herein for 866 Extended LSAs. The valid value for the enumeration are: 868 * None - Non-extended LSAs will not be originated or used in the 869 SPF calculation. 871 * Normal - Extended LSAs will be originated and adjacencies will 872 not be formed with OSPFv3 routers not supporting this 873 specification. 875 * MixedMode - Both extended and non-extended LSAs will be 876 originated. OSPFv3 adjacencies will be formed with OSPFv3 877 routers not supporting this specification. The extended LSAs 878 are used for the SPF computation. 880 * MixedModeDegraded - Both extended and non-extended LSAs will be 881 originated. OSPFv3 adjacencies will be formed with OSPFv3 882 routers not supporting this specification. The non-extended 883 LSAs are used for the SPF computation. 885 Authors' Addresses 887 Acee Lindem 888 Ericsson 889 301 Midenhall Way 890 Cary, NC 27513 891 USA 893 Email: acee.lindem@ericsson.com 895 Sina Mirtorabi 896 Cisco Systems 897 170 Tasman Drive 898 San Jose, CA 95134 899 USA 901 Email: sina@cisco.com 903 Abhay Roy 904 Cisco Systems 905 170 Tasman Drive 906 San Jose, CA 95134 907 USA 909 Email: akr@cisco.com 911 Fred Baker 912 Cisco Systems 913 Santa Barbara, CA 93117 914 USA 916 Email: fred@cisco.com