idnits 2.17.1 draft-ietf-ospf-ospfv3-lsa-extend-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 8, 2015) is 3122 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) == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem 3 Internet-Draft S. Mirtorabi 4 Intended status: Standards Track A. Roy 5 Expires: April 10, 2016 F. Baker 6 Cisco Systems 7 October 8, 2015 9 OSPFv3 LSA Extendibility 10 draft-ietf-ospf-ospfv3-lsa-extend-08.txt 12 Abstract 14 OSPFv3 requires functional extension beyond what can readily be done 15 with the fixed-format Link State Advertisement (LSA) as described in 16 RFC 5340. Without LSA extension, attributes associated with OSPFv3 17 links and advertised IPv6 prefixes must be advertised in separate 18 LSAs and correlated to the fixed-format LSAs. This document extends 19 the LSA format by encoding the existing OSPFv3 LSA information in 20 Type-Length-Value (TLV) tuples and allowing advertisement of 21 additional information with additional TLVs. Backward compatibility 22 mechanisms are also described. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 10, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 60 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 3 61 2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 4 62 3. OSPFv3 Extended LSA TLVs . . . . . . . . . . . . . . . . . . 5 63 3.1. Prefix Options Extensions . . . . . . . . . . . . . . . . 6 64 3.1.1. N-bit Prefix Option . . . . . . . . . . . . . . . . . 6 65 3.2. Router-Link TLV . . . . . . . . . . . . . . . . . . . . . 7 66 3.3. Attached-Routers TLV . . . . . . . . . . . . . . . . . . 7 67 3.4. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 9 68 3.5. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 10 69 3.6. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 11 70 3.7. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 12 71 3.8. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 13 72 3.9. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 14 73 3.10. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 15 74 3.11. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 15 75 3.12. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 16 76 4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . 16 77 4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 16 78 4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . 18 79 4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . 19 80 4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . 20 81 4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . 21 82 4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 22 83 4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 23 84 4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . 25 85 5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . 25 86 6. LSA Extension Backward Compatibility . . . . . . . . . . . . 26 87 6.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . 28 88 6.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 28 89 6.2. Extended LSA Spare-Mode Backward Compatibility . . . . . 29 90 6.3. LSA TLV Processing Backward Compatibility . . . . . . . . 29 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 94 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 95 9.2. Informative References . . . . . . . . . . . . . . . . . 32 96 Appendix A. Global Configuration Parameters . . . . . . . . . . 32 97 Appendix B. Area Configuration Parameters . . . . . . . . . . . 33 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 100 1. Introduction 102 OSPFv3 requires functional extension beyond what can readily be done 103 with the fixed-format Link State Advertisement (LSA) as described in 104 RFC 5340 [OSPFV3]. Without LSA extension, attributes associated with 105 OSPFv3 links and advertised IPv6 prefixes must be advertised in 106 separate LSAs and correlated to the fixed-format LSAs. This document 107 extends the LSA format by encoding the existing OSPFv3 LSA 108 information in Type-Length-Value (TLV) tuples and allowing 109 advertisement of additional information with additional TLVs. 110 Backward compatibility mechanisms are also described. 112 A similar extension was previously proposed in support of multi- 113 topology routing. Additional requirements for OSPFv3 LSA extension 114 include source/destination routing, route tagging, and others. 116 A final requirement is to limit the changes to OSPFv3 to those 117 necessary for TLV-based LSAs. For the most part, the semantics of 118 existing OSPFv3 LSAs are retained for their TLV-based successor LSAs 119 described herein. Additionally, encoding details, e.g., the 120 representation of IPv6 prefixes as described in section A.4.1 in RFC 121 5340 [OSPFV3], have been retained. This requirement was included to 122 increase the expedience of IETF adoption and deployment. 124 The following aspects of OSPFv3 LSA extension are described: 126 1. Extended LSA Types 128 2. Extended LSA TLVs 130 3. Extended LSA Formats 132 4. Backward Compatibility 134 1.1. Requirements notation 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC-KEYWORDS]. 140 1.2. Acknowledgments 142 OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing 143 in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3]. 145 Thanks for Peter Psenak for significant contributions to the backward 146 compatibility mechanisms. 148 Thanks go to Michael Barnes, Mike Dubrovsky, Anton Smirnov, and Tony 149 Przygienda for review of the draft versions and discussions of 150 backward compatibility. 152 Thanks to Alan Davey for review and comments including the suggestion 153 to separate the extended LSA TLV definitions from the extended LSAs 154 definitions. 156 Thanks to David Lamparter for review and suggestions on backward 157 compatibility. 159 Thanks to Karsten Thomann for review and editorial comments. 161 The RFC text was produced using Marshall Rose's xml2rfc tool. 163 2. OSPFv3 Extended LSA Types 165 In order to provide backward compatibility, new LSA codes must be 166 allocated. There are eight fixed-format LSAs defined in RFC 5340 167 [OSPFV3]. For ease of implementation and debugging, the LSA function 168 codes are the same as the fixed-format LSAs only with 32, i.e., 0x20, 169 added. The alternative to this mapping was to allocate a bit in the 170 LS Type indicating the new LSA format. However, this would have used 171 one half the LSA function code space for the migration of the eight 172 original fixed-format LSAs. For backward compatibility, the U-bit 173 will be set in LS Type so that the LSAs will be flooded by OSPFv3 174 routers that do not understand them. 176 LSA function code LS Type Description 177 ---------------------------------------------------- 178 33 0xA021 E-Router-LSA 179 34 0xA022 E-Network-LSA 180 35 0xA023 E-Inter-Area-Prefix-LSA 181 36 0xA024 E-Inter-Area-Router-LSA 182 37 0xC025 E-AS-External-LSA 183 38 N/A Unused (Not to be allocated) 184 39 0xA027 E-Type-7-LSA 185 40 0x8028 E-Link-LSA 186 41 0xA029 E-Intra-Area-Prefix-LSA 188 OSPFv3 Extended LSA Types 190 3. OSPFv3 Extended LSA TLVs 192 The format of the TLVs within the body of the extended LSAs is the 193 same as the format used by the Traffic Engineering Extensions to OSPF 194 [TE]. The variable TLV section consists of one or more nested 195 Type/Length/Value (TLV) tuples. Nested TLVs are also referred to as 196 sub-TLVs. The format of each TLV is: 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Type | Length | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Value... | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 TLV Format 208 The Length field defines the length of the value portion in octets 209 (thus a TLV with no value portion would have a length of 0). The TLV 210 is padded to 4-octet alignment; padding is not included in the length 211 field (so a 3-octet value would have a length of 3, but the total 212 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 213 aligned. For example, a 1-byte value would have the length field set 214 to 1, and 3 octets of padding would be added to the end of the value 215 portion of the TLV. 217 This document defines the following top-level TLV types: 219 o 0 - Reserved 221 o 1 - Router-Link TLV 223 o 2 - Attached-Routers TLV 225 o 3 - Inter-Area Prefix TLV 227 o 4 - Inter-Area Router TLV 229 o 5 - External Prefix TLV 231 o 6 - Intra-Area Prefix TLV 233 o 7 - IPv6 Link-Local Address TLV 235 o 8 - IPv4 Link-Local Address TLV 236 Additionally, this document defines the following sub-TLV types: 238 o 0 - Reserved 240 o 1 - IPv6 Forwarding Address sub-TLV 242 o 2 - IPv4 Forwarding Address sub-TLV 244 o 3 - Route Tag sub-TLV 246 In general, TLVs and sub-TLVs MAY occur in any order and the 247 specification should define whether the TLV or sub-TLV is required 248 and the behavior when there are multiple occurances of the TLV or 249 sub-TLVs. 251 3.1. Prefix Options Extensions 253 The prefix options are extended from Appendix A.4.1.1 [OSPFV3]. The 254 applicability of the LA-bit is expanded and it SHOULD be set in 255 Inter-Area-Prefix-TLVs and MAY be set in External-Prefix-TLVs when 256 the advertised host IPv6 address, i.e., PrefixLength = 128, is an 257 interface address. In RFC 5340, the LA-bit is only set in Intra- 258 Area-Prefix-LSAs (Section 4.4.3.9 in [OSPFV3]). This will allow a 259 stable address to be advertised without having to configure a 260 separate loopback address in every OSPFv3 area. 262 3.1.1. N-bit Prefix Option 264 Additionally, the N-bit prefix option is defined. The figure below 265 shows the position of the N-bit in the prefix options (pending IANA 266 allocation). This corresponds to the value 0x20. 268 0 1 2 3 4 5 6 7 269 +--+--+--+--+--+--+--+--+ 270 | | | N|DN| P| x|LA|NU| 271 +--+--+--+--+--+--+--+--+ 273 The Prefix Options field 275 The N-bit is set in PrefixOptions for a host address 276 (PrefixLength=128) that identifies the advertising router. While it 277 is similar to the LA-bit, there are two differences. The advertising 278 router MAY choose NOT to set the N-bit even when the above conditions 279 are met. If the N-bit is set and the PrefixLength is NOT 128, the 280 N-bit MUST be ignored. Additionally, the N-bit is propagated in the 281 PrefixOptions when an OSPFv3 Area Border Router (ABR) originates an 282 Inter-Area-Prefix-LSA for an Intra-Area route which has the N-bit set 283 in the PrefixOptions. Similarly, the N-bit is propagated in the 284 PrefixOptions when an OSPFv3 NSSA ABR originates an Extended-AS- 285 External-LSA corresponding to an NSSA route as described in section 3 286 of RFC 3101 ([NSSA]). The N-bit is to the Inter-Area-Prefix-TLV 287 (Section 3.4), External-Prefix-TLV (Section 3.6), and Intra-Area- 288 Prefix-TLV (Section 3.7) The N-bit is useful for applications such as 289 identifying the prefixes corresponding to Node Segment Identifiers 290 (SIDs) in Segment Routing [SEGMENT-ROUTING]. 292 3.2. Router-Link TLV 294 The Router-Link TLV defines a single router link and the field 295 definitions correspond directly to links in the OSPFv3 Router-LSA, 296 section A.4.3, [OSPFV3]. The Router-Link TLV is only applicable to 297 the E-Router-LSA (Section 4.1). Inclusion in other Extended LSAs 298 MUST be ignored. 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | 1 (Router-Link) | TLV Length | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Type | 0 | Metric | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Interface ID | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Neighbor Interface ID | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Neighbor Router ID | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 . . 314 . sub-TLVs . 315 . . 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Router-Link TLV 320 3.3. Attached-Routers TLV 322 The Attached-Routers TLV defines all the routers attached to an 323 OSPFv3 multi-access network. The field definitions correspond 324 directly to content of the OSPFv3 Network-LSA, section A.4.4, 325 [OSPFV3]. The Attached-Routers TLV is only applicable to the E- 326 Network-LSA (Section 4.2). Inclusion in other Extended LSAs MUST be 327 ignored. 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | 2 (Attached-Routers) | TLV Length | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Adjacent Neighbor Router ID | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 . . 337 . Additional Adjacent Neighbors . 338 . . 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Attached-Routers TLV 343 There are two reasons for not having a separate TLV or sub-TLV for 344 each adjacent neighbor. The first is to discourage using the E- 345 Network-LSA for more than its current role of solely advertising the 346 routers attached to a multi-access network. The router's metric as 347 well as the attributes of individual attached routers should be 348 advertised in their respective E-Router-LSAs. The second reason is 349 that there is only a single E-Network-LSA per multi-access link with 350 the Link State ID set to the Designated Router's Interface ID and, 351 consequently, compact encoding has been chosen to decrease the 352 likelihood that the size of the E-Network-LSA will require IPv6 353 fragmentation when advertised in an OSPFv3 Link State Update packet. 355 3.4. Inter-Area-Prefix TLV 357 The Inter-Area-Prefix TLV defines a single OSPFV3 inter-area prefix. 358 The field definitions correspond directly to the content of an OSPFv3 359 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 360 Inter-Area-Prefix-LSA, as defined in section A.4.5, [OSPFV3]. 361 Additionally, the PrefixOptions are extended as described in 362 Section 3.1. The Inter-Area-Prefix TLV is only applicable to the E- 363 Inter-Area-Prefix-LSA (Section 4.3). Inclusion in other Extended 364 LSAs MUST be ignored. 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | 3 (Inter-Area Prefix) | TLV Length | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | 0 | Metric | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | PrefixLength | PrefixOptions | 0 | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Address Prefix | 376 | ... | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 . . 379 . sub-TLVs . 380 . . 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Inter-Area Prefix TLV 385 3.5. Inter-Area-Router TLV 387 The Inter-Area-Router TLV defines a single OSPFv3 Autonomous System 388 Boundary Router (ASBR) reachable in another area. The field 389 definitions correspond directly to the content of an OSPFv3 Inter- 390 Area-Router-LSA, as defined in section A.4.6, [OSPFV3]. The Inter- 391 Area-Router TLV is only applicable to the E-Inter-Area-Router-LSA 392 (Section 4.4). Inclusion in other Extended LSAs MUST be ignored. 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | 4 (Inter-Area Router) | TLV Length | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | 0 | Options | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | 0 | Metric | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Destination Router ID | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 . . 406 . sub-TLVs . 407 . . 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Inter-Area Router TLV 412 3.6. External-Prefix TLV 414 The External-Prefix TLV defines a single OSPFv3 external prefix. The 415 field definitions correspond directly to the content of an OSPFv3 416 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 AS- 417 External-LSA, as defined in section A.4.7, [OSPFV3]. The External- 418 Prefix TLV is only applicable to the E-AS-External-LSA (Section 4.5) 419 and the E-NSSA-LSA (Section 4.6). Additionally, the PrefixOptions 420 are extended as described in Section 3.1. Inclusion in other 421 Extended LSAs MUST be ignored. 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | 5 (External Prefix) | TLV Length | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | |E| | | Metric | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | PrefixLength | PrefixOptions | 0 | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Address Prefix | 433 | ... | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 . . 436 . sub-TLVs . 437 . . 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 External Prefix TLV 442 In the External-Prefix TLV, the optional IPv6/IPv4 Forwarding Address 443 and External Route Tag are now sub-TLVs. Given the Referenced LS 444 type and Referenced Link State ID from the AS-External-LSA have never 445 been used or even specified, they have been omitted from the External 446 Prefix TLV. If there were ever a requirement for a referenced LSA, 447 it could be satisfied with a sub-TLV. 449 The following sub-TLVs are defined for optional inclusion in the 450 External Prefix TLV: 452 o 1 - IPv6 Forwarding Address sub-TLV (Section 3.10) 454 o 2 - IPv4 Forwarding Address sub-TLV (Section 3.11) 456 o 3 - Route Tag sub-TLV (Section 3.12) 458 3.7. Intra-Area-Prefix TLV 460 The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix. 461 The field definitions correspond directly to the content of an OSPFv3 462 IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 Link- 463 LSA, as defined in section A.4.9, [OSPFV3]. The Intra-Area-Prefix 464 TLV is only applicable to the E-Link-LSA (Section 4.7) and the 465 Additionally, the PrefixOptions are extended as described in 466 Section 3.1. E-Intra-Area-Prefix-LSA (Section 4.8). Inclusion in 467 other Extended LSAs MUST be ignored. 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | 6 (Intra-Area Prefix) | TLV Length | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | 0 | Metric | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | PrefixLength | PrefixOptions | 0 | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Address Prefix | 479 | ... | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 . . 482 . sub-TLVs . 483 . . 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Intra-Area Prefix TLV 488 3.8. IPv6 Link-Local Address TLV 490 The IPv6 Link-Local Address TLV is to be used with IPv6 address 491 families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV 492 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 493 other Extended LSAs MUST be ignored. 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | 7 (IPv6 Local-Local Address) | TLV Length | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | | 501 +- -+ 502 | | 503 +- IPv6 Link-Local Interface Address -+ 504 | | 505 +- -+ 506 | | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 . . 509 . sub-TLVs . 510 . . 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 IPv6 Link-Local Address TLV 515 3.9. IPv4 Link-Local Address TLV 517 The IPv4 Link-Local Address TLV is to be used with IPv4 address 518 families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV 519 is only applicable to the E-Link-LSA (Section 4.7). Inclusion in 520 other Extended LSAs MUST be ignored. 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | 8 (IPv4 Local-Local Address) | TLV Length | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | IPv4 Link-Local Interface Address | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 . . 530 . sub-TLVs . 531 . . 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 IPv4 Link-Local Address TLV 536 3.10. IPv6-Forwarding-Address Sub-TLV 538 The IPv6 Forwarding Address TLV has identical semantics to the 539 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv6 540 Forwarding Address TLV is applicable to the External-Prefix TLV 541 (Section 3.6). Specification as a sub-TLV of other TLVs is not 542 defined herein. The sub-TLV is optional and the first specified 543 instance is used as the Forwarding Address as defined in [OSPFV3]. 544 Instances subsequent to the first MUST be ignored. 546 The IPv6 Forwarding Address TLV is to be used with IPv6 address 547 families as defined in [OSPFV3-AF] It MUST be ignored for other 548 address families. 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | 1 - Forwarding Address | sub-TLV Length | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | | 556 +- -+ 557 | | 558 +- Forwarding Address -+ 559 | | 560 +- -+ 561 | | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 Forwarding Address Tag TLV 566 3.11. IPv4-Forwarding-Address Sub-TLV 568 The IPv4 Forwarding Address TLV has identical semantics to the 569 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv4 570 Forwarding Address TLV is The IPv4 Forwarding Address TLV is 571 applicable to the External-Prefix TLV (Section 3.6). Specification 572 as a sub-TLV of other TLVs is not defined herein. The sub-TLV is 573 optional and the first specified instance is used as the Forwarding 574 Address as defined in [OSPFV3]. Instances subsequent to the first 575 MUST be ignored. 577 The IPv4 Forwarding Address TLV is to be used with IPv3 address 578 families as defined in [OSPFV3-AF] It MUST be ignored for other 579 address families. 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | 2 - Forwarding Address | sub-TLV Length | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Forwarding Address | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 Forwarding Address Tag TLV 591 3.12. Route-Tag Sub-TLV 593 The optional Route Tag sub-TLV has identical semantics to the 594 optional External Route Tag in section A.4.7 of [OSPFV3]. The Route 595 Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.6). 596 Specification as a sub-TLV of other TLVs is not defined herein. The 597 sub-TLV is optional and the first specified instance is used as the 598 Route Tag as defined in [OSPFV3]. Instances subsequent to the first 599 MUST be ignored. 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 | 3 - Route Tag | sub-TLV Length | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Route Tag | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 Route Tag Sub-TLV 611 4. OSPFv3 Extended LSAs 613 This section specifies the OSPFv3 Extended LSA formats and encoding. 614 The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3 615 LSAs specifed in [OSPFV3]. 617 4.1. OSPFv3 E-Router-LSA 619 The E-Router-LSA has an LS Type of 0xA021 and has the same base 620 information content as the Router-LSA defined in section A.4.3 of 621 [OSPFV3]. However, unlike the existing Router-LSA, it is fully 622 extendable and represented as TLVs. 624 0 1 2 3 625 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 626 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | LS Age |1|0|1| 0x21 | 628 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Link State ID | 630 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Advertising Router | 632 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | LS Sequence Number | 634 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | LS Checksum | Length | 636 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | 0 |Nt|x|V|E|B| Options | 638 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 . . 640 . TLVs . 641 . . 642 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Extended Router-LSA 646 All LSA Header fields are the same as defined for the Router-LSA. 647 Initially, only the top-level Router-Link TLV Section 3.2 is 648 applicable and an E-Router-LSA may include multiple Router-Link TLVs. 649 Like the existing Router-LSA, the LSA length is used to determine the 650 end of the LSA including TLVs. 652 4.2. OSPFv3 E-Network-LSA 654 The E-Network-LSA has an LS Type of 0xA022 and has the same base 655 information content as the Network-LSA defined in section A.4.4 of 656 [OSPFV3]. However, unlike the existing Network-LSA, it is fully 657 extendable and represented as TLVs. 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | LS Age |1|0|1| 0x22 | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Link State ID | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Advertising Router | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | LS Sequence Number | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | LS Checksum | Length | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | 0 | Options | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 . . 675 . TLVs . 676 . . 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 E-Network-LSA 681 All LSA Header fields are the same as defined for the Network-LSA. 682 Like the existing Network-LSA, the LSA length is used to determine 683 the end of the LSA including TLVs. Initially, only the top-level 684 Attached-Routers TLV Section 3.3 is applicable. If the Attached- 685 Router TLV is not included in the E-Network-LSA, it is treated as 686 malformed as described in Section 5. Instances of the Attached- 687 Router TLV subsequent to the first MUST be ignored. 689 4.3. OSPFv3 E-Inter-Area-Prefix-LSA 691 The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same 692 base information content as the Inter-Area-Prefix-LSA defined in 693 section A.4.5 of [OSPFV3]. However, unlike the existing Inter-Area- 694 Prefix-LSA, it is fully extendable and represented as TLVs. 696 0 1 2 3 697 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 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | LS Age |1|0|1| 0x23 | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Link State ID | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Advertising Router | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | LS Sequence Number | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | LS Checksum | Length | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 . . 710 . TLVs . 711 . . 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 E-Inter-Area-Prefix-LSA 716 All LSA Header fields are the same as defined for the Inter-Area- 717 Prefix-LSA. In order to retain compatibility and semantics with the 718 current OSPFv3 specification, each Inter-Area-Prefix LSA MUST contain 719 a single Inter-Area Prefix TLV. This will facilitate migration and 720 avoid changes to functions such as incremental SPF computation. 722 Like the existing Inter-Area-Prefix-LSA, the LSA length is used to 723 determine the end of the LSA including TLV. Initially, only the top- 724 level Inter-Area-Prefix TLV (Section 3.4) is applicable. If the 725 Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA, 726 it is treated as malformed as described in Section 5. Instances of 727 the Inter-Area-Prefix TLV subsequent to the first MUST be ignored. 729 4.4. OSPFv3 E-Inter-Area-Router-LSA 731 The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same 732 base information content as the Inter-Area-Router-LSAE defined in 733 section A.4.6 of [OSPFV3]. However, unlike the Inter-Area-Router- 734 LSA, it is fully extendable and represented as TLVs. 736 0 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | LS Age |1|0|1| 0x24 | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Link State ID | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Advertising Router | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | LS Sequence Number | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | LS Checksum | Length | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 . . 750 . TLVs . 751 . . 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 E-Inter-Area-Router-LSA 756 All LSA Header fields are the same as defined for the Inter-Area- 757 Router-LSA. In order to retain compatibility and semantics with the 758 current OSPFv3 specification, each Inter-Area-Router LSA MUST contain 759 a single Inter-Area Router TLV. This will facilitate migration and 760 avoid changes to functions such as incremental SPF computation. 762 Like the existing Inter-Area-Router-LSA, the LSA length is used to 763 determine the end of the LSA including TLV. Initially, only the top- 764 level Inter-Area-Router TLV (Section 3.5) is applicable. If the 765 Inter-Area-Router TLV is not included in the E-Inter-Area-Router-LSA, 766 it is treated as malformed as described in Section 5. Instances of 767 the Inter-Area-Router TLV subsequent to the first MUST be ignored. 769 4.5. OSPFv3 E-AS-External-LSA 771 The E-AS-External-LSA has an LS Type of 0xC025 and has the same base 772 information content as the AS-External-LSA defined in section A.4.7 773 of [OSPFV3]. However, unlike the existing AS-External-LSA, it is 774 fully extendable and represented as TLVs. 776 0 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | LS Age |1|1|0| 0x25 | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Link State ID | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Advertising Router | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | LS Sequence Number | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | LS Checksum | Length | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 . . 790 . TLVs . 791 . . 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 E-AS-External-LSA 796 All LSA Header fields are the same as defined for the AS-External- 797 LSA. In order to retain compatibility and semantics with the current 798 OSPFv3 specification, each LSA MUST contain a single External Prefix 799 TLV. This will facilitate migration and avoid changes to OSPFv3 800 processes such as incremental SPF computation. 802 Like the existing AS-External-LSA, the LSA length is used to 803 determine the end of the LSA including sub-TLVs. Initially, only the 804 top-level External-Prefix TLV (Section 3.6) is applicable. If the 805 External-Prefix TLV is not included in the E-External-AS-LSA, it is 806 treated as malformed as described in Section 5. Instances of the 807 External-Prefix TLV subsequent to the first MUST be ignored. 809 4.6. OSPFv3 E-NSSA-LSA 811 The E-NSSA-LSA will have the same format and TLVs as the Extended AS- 812 External-LSA Section 4.5. This is the same relationship as exists 813 between the NSSA-LSA defined in section A.4.8 of [OSPFV3], and the 814 AS-External-LSA. The NSSA-LSA will have type 0xA027 which implies 815 area flooding scope. Future requirements may dictate that supported 816 TLVs differ between the E-AS-External-LSA and the E-NSSA-LSA. 817 However, future requirements are beyond the scope of this document. 819 4.7. OSPFv3 E-Link-LSA 821 The E-Link-LSA has an LS Type of 0x8028 and will have the same base 822 information content as the Link-LSA defined in section A.4.9 of 823 [OSPFV3]. However, unlike the existing Link-LSA, it is extendable 824 and represented as TLVs. 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | LS Age |1|0|0| 0x28 | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Link State ID | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Advertising Router | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | LS Sequence Number | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | LS Checksum | Length | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Rtr Priority | Options | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 . . 842 . TLVs . 843 . . 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 E-Link-LSA 848 All LSA Header fields are the same as defined for the Link-LSA. 850 Only the Intra-Area-Prefix TLV (Section 3.7), IPv6 Link-Local Address 851 TLV (Section 3.8), and IPv4 Link-Local Address TLV (Section 3.9) are 852 applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA 853 affords advertisement of multiple intra-area prefixes. Hence, 854 multiple Intra-Area Prefix TLVs (Section 3.7) may be specified and 855 the LSA length defines the end of the LSA including all TLVs. 857 A single instance of the IPv6 Link-Local Address TLV (Section 3.8) 858 SHOULD be included in the E-Link-LSA. Instances following the first 859 MUST be ignored. For IPv4 address families as defined in 860 [OSPFV3-AF], this TLV MUST be ignored. 862 Similarly, only a single instance of the IPv4 Link-Local Address TLV 863 (Section 3.9) SHOULD be included in the E-Link-LSA. Instances 864 following the first MUST be ignored. For OSPFv3 IPv6 address 865 families as defined in [OSPFV3-AF], this TLV MUST be ignored. 867 If the IPv4/IPv6 Link-Local Address TLV corresponding to the OSPFv3 868 Address Family is not included in the E-Link-LSA, it is treated as 869 malformed as described in Section 5. 871 Future specifications may support advertisement of routing and 872 topology information for multiple address families. However, this is 873 beyond the scope of this document. 875 4.8. OSPFv3 E-Intra-Area-Prefix-LSA 877 The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same 878 base information content as the Intra-Area-Prefix-LSA defined in 879 section A.4.10 of [OSPFV3]. However, unlike the Intra-Area-Prefix- 880 LSA, it is fully extendable and represented as TLVs. 882 0 1 2 3 883 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 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | LS Age |1|0|1| 0x29 | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Link State ID | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Advertising Router | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | LS Sequence Number | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | LS Checksum | Length | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | 0 | Referenced LS Type | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Referenced Link State ID | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Referenced Advertising Router | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 . . 902 . TLVs . 903 . . 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 E-Intra-Area-Prefix-LSA 908 All LSA Header fields are the same as defined for the Intra-Area- 909 Prefix-LSA. 911 Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords 912 advertisement of multiple intra-area prefixes. Hence, multiple 913 Intra-Area Prefix TLVs may be specified and the LSA length defines 914 the end of the LSA including all TLVs. 916 5. Malformed OSPFv3 Extended LSA Handling 918 Extended LSAs that have inconsistent length or other encoding errors, 919 as described herein, MUST NOT be installed in the Link State 920 Database, acknowledged, or flooded. Reception of malformed LSAs 921 SHOULD be counted and/or logged for examination by the administrator 922 of the OSPFv3 Routing Domain. 924 6. LSA Extension Backward Compatibility 926 In the context of this document, backward compatibility is solely 927 related to the capability of an OSPFv3 router to receive, process, 928 and originate the TLV-based LSAs defined herein. Unrecognized TLVs 929 and sub-TLVs are ignored. Backward compatibility for future OSPFv3 930 extensions utilizing the TLV-based LSAs is out of scope and must be 931 covered in the documents describing those extensions. Both full and, 932 if applicable, partial deployment SHOULD be specified for future TLV- 933 based OSPFv3 LSA extensions. 935 Three distinct backward compatibility modes are supported dependent 936 on the OSPFv3 routing domain migration requirements. For simplicity 937 and to avoid the scaling impact of maintaining both TLV and non-TLV 938 based versions of the same LSA within a routing domain, the basic 939 backward compatibility mode will not allow mixing of LSA formats. 940 Different LSA formats could still be supported with multiple OSPFv3 941 instances and separate OSPFv3 routing domains. Additionally, a more 942 flexible mode is provided in Section 6.1, where both formats of LSA 943 coexist. In order to facilitate backward compatibility, the OSPFv3 944 options field (as described in Appendix A.2 of RFC 5340 [OSPFV3]), 945 will contain two additional options bits. The EL-bits will be used 946 to indicate that the OSPFv3 router's level of Extended LSA support. 947 An OSPFv3 router configured to support extended LSAs MUST set its 948 options field EL-bits in OSPFv3 Hello and Database Description 949 packets as follows: 951 B'00' 952 None - Extended LSAs are not originated nor used in the SPF 953 calculation (except for future functionalities as described in 954 Section 6.2) . 956 B'01' 957 MixedModeOriginateOnly - Both extended and non-extended LSAs are 958 originated. Non-extended LSAs are used in the SPF computation. 960 B'10' 961 MixedModeOriginateSPF - Both extended and non-extended LSAs are 962 originated. Extended LSAs are used in the SPF computation. 964 B'11' 965 Full - Only extended LSAs are originated and used in the SPF 966 computation. 968 If Full is specified for ExtendedLSASupport, the OSPFv3 router MUST 969 NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and 970 Database Description packets with the options field EL-bits set to 971 MixedModeOriginateOnly or None. Similarly, if MixModeOriginateSPF is 972 specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form 973 adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database 974 Description packets with the options field EL-bits set to None 975 (B'00'). In this manner, OSPFv3 routers using new encodings can be 976 completely isolated from those OSPFv3 routers depending on the RFC 977 5340 encoding and not setting their options field EL-bits since the 978 default setting indicates no support for extended LSAs. 980 Finally, a mode supporting existing OSPFv3 routing domains is 981 provided. This mode, subsequently referred to as "sparse-mode", will 982 use the TLV-based LSAs solely in support of new functionality 983 Section 6.2. In this compatibility mode, the EL-bits will be 984 advertised as B'00' since the backward compatibility with the non- 985 extended LSAs is not supported or required. 987 1 2 988 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 990 | | | | | | | | | | | | EL|AT|L|AF|*|*|DC|R|N|x|E|V6| 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+ 992 The Options field 994 EL-bits 995 These bits indicate the level of Extended LSA support. 996 B'00' - Extended LSAs are not originate nor used in the 997 SPF calculation (except for new functionalities 998 for future functions as described in Section 6.2). 999 B'01' - Both extended and non-extended LSAs are originated. 1000 Non-extended LSAs are used in the SPF computation. 1001 B'10' - Both extended and non-extended LSAs are originated. 1002 Extended LSAs are used in the SPF computation. 1003 B'11' - Only extended LSA are originated and used in the 1004 SPF computation. 1006 Options Field EL-bits 1008 The EL-bits will also be set in the LSA options field in Extended and 1009 Non-Extended LSAs. While the value of the EL-bits has no functional 1010 significance in the LSA options field, visibility of every OSPFv3 1011 Router's extended LSA support is expected to be very useful for 1012 management and troubleshooting during the migration period. 1014 6.1. Extended LSA Mixed-Mode Backward Compatibility 1016 An implementation MAY support configuration allowing a graceful 1017 transition from the non-extended (non-TLV-based) LSAs to the extended 1018 (TLV-based) LSAs in an OSPFv3 routing domain. In these routing 1019 domains, the OSPFv3 routers configured with a value of 1020 MixedModeOriginateOnly or MixedModeOriginateSPF for 1021 ExtendedLSASupport, (Appendix A), MUST originate both the extended 1022 and non-extended versions of the OSPFv3 LSAs described herein. For 1023 the purposes of Shortest Path First (SPF) computation, the non- 1024 extended OSPFv3 LSAs are used for SPF computation when 1025 MixedModeOriginateOnly is configured and the extended LSAs are used 1026 when MixedModeOriginateSPF is specified. The extended LSAs MAY be 1027 used for functions other than routing computation as long as backward 1028 compatibility is specified in the documents specifying those 1029 functions. 1031 In this manner, OSPFv3 routing domains utilizing the new encodings 1032 can be gradually migrated with a worst-case overhead cost of 1033 approximately doubling the number of LSAs in the routing domain. The 1034 transition within an OSPFv3 routing domain would progress as follows: 1036 1. Configure OSPFv3 Router ExtendedLSASupport to 1037 MixedModeOriginateOnly so that routers originate the extended 1038 LSAs. 1040 2. When all the OSPFv3 Routers have been reconfigured to 1041 MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to 1042 use the extended LSAs by configuring ExtendedLSASupport to 1043 MixedModeOriginateSPF. This can be done on a small subset of 1044 OSPFv3 Routers and the route tables can be verified. 1046 3. When all the OSPFv3 Routers have been reconfigured to 1047 MixedModeOriginateSPF and the routing has been verified, 1048 reconfigure OSPFv3 Routers to purge or simply not refresh the 1049 non-extended OSPFv3 LSA by configuring ExtendedLSASupport to 1050 Full. 1052 In order to prevent OSPFv3 routing domain routing loops, the 1053 advertised metrics in the extended and non-extended OSPFv3 LSAs MUST 1054 be identical. 1056 6.1.1. Area Extended LSA Mixed-Mode Backward Compatibility 1058 An implementation MAY also support configuration allowing graceful 1059 transition from the non-extended LSAs to the extended LSAs within a 1060 single area. In these areas, the parameter AreaExtendedLSASupport 1061 (Appendix B) may be configured to take precedence over the global 1062 parameter ExtendedLSASupport. However, the AreaExtendedLSASupport 1063 will only apply to link and area scoped LSAs within the area and area 1064 based SPF calculations. The default is for the 1065 AreaExtendedLSASupport to be inherited from the ExtendedLSASupport. 1066 The configuration of ExtendedLSASupport will apply to AS-External 1067 LSAs even when AreaExtendedLSASupport takes precedence. 1069 When preforming a graceful restart [GRACEFUL-RESTART], an OSPFv3 1070 router configured with MixedModeOriginate will use the non-extended 1071 OSPFv3 LSAs to determine whether or not the graceful restart has 1072 completed successfully. Similarly, an OSPFv3 router configured with 1073 MixedModeOriginateSPF will use the extended LSAs. In other words, 1074 successful OSPFv3 graceful restart determination will follow the SPF 1075 calculation. 1077 6.2. Extended LSA Spare-Mode Backward Compatibility 1079 In this mode, OSPFv3 will use the non-extended LSAs for the SPF 1080 computation and will only originate extended LSAs when LSA 1081 origination is required in support of addtional functionality. 1082 Furthermore, the extended LSAs will only include those TLVs which 1083 require further specification for that new functionality. Hence, 1084 this mode of compatibility is know as "sparse-mode". The advantage 1085 of sparse-mode is that functionality utilizing the OSPFv3 extended 1086 LSAs can be added to an existing OSFPv3 routing domain without the 1087 requirement for migration. In essence, this compatibility mode is 1088 very much like the approach taken for OSPFv2 [OSPF-PREFIX-LINK]. As 1089 with all the compatibility modes, backward compatibility for the 1090 functions utilizing the extended LSAs must be described in the IETF 1091 documents describing those functions. 1093 6.3. LSA TLV Processing Backward Compatibility 1095 This section defines the general rules for processing LSA TLVs. To 1096 ensure compatibility of future TLV-based LSA extensions, all 1097 implementations MUST adhere to these rules: 1099 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or 1100 processing Extended-LSAs. 1102 2. Whether or not partial deployment of a given TLV is supported 1103 MUST be specified. 1105 3. If partial deployment is not supported, mechanisms to ensure the 1106 corresponding feature are not deployed MUST be specified in the 1107 document defining the new TLV or sub-TLV. 1109 4. If partial deployment is supported, backward compatibility and 1110 partial deployment MUST be specified in the document defining the 1111 new TLV or sub-TLV. 1113 7. Security Considerations 1115 In general, extendible OSPFv3 LSAs are subject to the same security 1116 concerns as those described in RFC 5340 [OSPFV3]. Additionally, 1117 implementations must assure that malformed TLV and sub-TLV 1118 permutations do not result in errors that cause hard OSPFv3 failures. 1120 If there were ever a requirement to digitally sign OSPFv3 LSAs as 1121 described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the 1122 mechanisms described herein would greatly simplify the extension. 1124 8. IANA Considerations 1126 This specification defines nine OSPFv3 Extended LSA types as 1127 described in Section 2. 1129 This specification also creates two registries OSPFv3 Extended-LSAs 1130 TLVs and sub-TLVs. The TLV and sub-TLV code-points in these 1131 registries are common to all Extended-LSAs and their respective 1132 definitions must define where they are applicable. 1134 The OSPFv3 Extend-LSA TLV registry will define top-level TLVs for 1135 Extended-LSAs and should be placed in the existing OSPFv3 IANA 1136 registry. New values can be allocated via IETF Consensus or IESG 1137 Approval. 1139 Nine values are allocated by this specification: 1141 o 0 - Reserved 1143 o 1 - Router-Link TLV 1145 o 2 - Attached-Routers TLV 1147 o 3 - Inter-Area Prefix TLV 1149 o 4 - Inter-Area Router TLV 1151 o 5 - External Prefix TLV 1153 o 6 - Intra-Area Prefix TLV 1155 o 7 - IPv6 Link-Local Address TLV 1156 o 8 - IPv4 Link-Local Address TLV 1158 The OSPFv3 Extend-LSA sub-TLV registry will define sub-TLVs at any 1159 level of nesting for Extended-LSAs and should be placed in the 1160 existing OSPFv3 IANA registry. New values can be allocated via IETF 1161 Review. 1163 Three values are allocated by this specification: 1165 o 0 - Reserved 1167 o 1 - Forwarding Address 1169 o 2 - Route Tag 1171 The OSPFv3 Prefix Options registry will define a new code point for 1172 the N-bit. The value 0x20 is suggested. 1174 9. References 1176 9.1. Normative References 1178 [GRACEFUL-RESTART] 1179 Lindem, A. and P. Pillay-Esnault, "OSPFv3 Graceful 1180 Restart", RFC 5187, June 2008. 1182 [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 1183 RFC 3101, January 2003. 1185 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1186 for IPv6", RFC 5340, July 2008. 1188 [OSPFV3-AF] 1189 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 1190 Aggarwal, "Support of Address Families in OSPFv3", RFC 1191 5838, April 2010. 1193 [RFC-KEYWORDS] 1194 Bradner, S., "Key words for use in RFCs to Indicate 1195 Requirement Levels", RFC 2119, March 1997. 1197 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 1198 Extensions to OSPF", RFC 3630, September 2003. 1200 9.2. Informative References 1202 [MT-OSPFV3] 1203 Mirtorabi, S. and A. Roy, "Multi-topology routing in 1204 OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-03.txt 1205 (work in progress), January 2008. 1207 [OSPF-DIGITAL-SIGNATURE] 1208 Murphy, S., Badger, M., and B. Wellington, "OSPF with 1209 Digital Signatures", RFC 2154, June 1997. 1211 [OSPF-PREFIX-LINK] 1212 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1213 Tantsura, J., and A. Lindem, "OSPF Prefix/Link 1214 Attributes", draft-ietf-ospf-prefix-link-attr-13.txt (work 1215 in progress), August 2015. 1217 [SEGMENT-ROUTING] 1218 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1219 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1220 Extensions for Segment Routing", draft-ietf-ospf-segment- 1221 routing-extensions-05.txt (work in progress), February 1222 2015. 1224 Appendix A. Global Configuration Parameters 1226 An additional global configurable parameter will be added to the 1227 OSPFv3 protocol. 1229 ExtendedLSASupport 1230 This is an enumeration type indicating the extent to which the 1231 OSPFv3 instance supports the TLV format described herein for 1232 Extended LSAs. The valid values for the enumeration are: 1234 * None - Extended LSAs will not be originated or used in the SPF 1235 calculation. This is the default. When OSPFv3 functions 1236 requiring extended LSA are configured, and the 1237 ExtendedLSASuppport is "None", extended LSAs may be used as 1238 described in Section 6.2. 1240 * MixedModeOriginateOnly - Both extended and non-extended LSAs 1241 will be originated. OSPFv3 adjacencies will be formed with 1242 OSPFv3 routers not supporting this specification. The non- 1243 extended LSAs are used for the SPF computation. 1245 * MixedModeOriginateSPF - Both extended and non-extended LSAs 1246 will be originated. OSPFv3 adjacencies will be formed with 1247 OSPFv3 routers not supporting this specification. The extended 1248 LSAs are used for the SPF computation. 1250 * Full - Extended LSAs will be originated and adjacencies will 1251 ndot be formed with OSPFv3 routers not supporting this 1252 specification. Only Extended LSAs will be originated. 1254 Appendix B. Area Configuration Parameters 1256 An additional area configurable parameter will be added to the OSPFv3 1257 protocol. 1259 AreaExtendedLSASupport 1260 This is an enumeration type indicating the extent to which the 1261 OSPFv3 area supports the TLV format described herein for Extended 1262 LSAs. The valid value for the enumeration are: 1264 * InheritGlobal - The AreaExtendedLSASupport will be inherited 1265 from ExtendedLSASupport. This is the default. 1267 * None - Extended LSAs will not be originated or used in the SPF 1268 calculation. This is the default. When OSPFv3 functions 1269 requiring extended LSA are configured, and the 1270 ExtendedLSASuppport is "None", the spare-mode compatability is 1271 in effect Section 6.2. 1273 * MixedModeOriginateOnly - Both extended and non-extended link 1274 and area scoped LSAs will be originated. OSPFv3 adjacencies 1275 will be formed with OSPFv3 routers not supporting this 1276 specification. The non-extended LSAs are used for the SPF 1277 computation. 1279 * MixedModeOriginateSPF - Both extended and non-extended link and 1280 area scoped LSAs will be originated. OSPFv3 adjacencies will 1281 be formed with OSPFv3 routers not supporting this 1282 specification. The extended LSAs are used for the area SPF 1283 computation. 1285 * Full - Link and area scoped extended LSAs will be originated 1286 and adjacencies will not be formed with OSPFv3 routers not 1287 supporting this specification. Only Extended LSAs will be 1288 originated. 1290 For regular areas, i.e., areas where AS scoped LSAs are flooded, 1291 configuring None or MixedModeOriginateOnly for AreaExtendedLSASupport 1292 when Full is specified for ExtendedLSASupport is contradictory and 1293 MAY be prohibited by the implementation. 1295 Authors' Addresses 1297 Acee Lindem 1298 Cisco Systems 1299 301 Midenhall Way 1300 Cary, NC 27513 1301 USA 1303 Email: acee@cisco.com 1305 Sina Mirtorabi 1306 Cisco Systems 1307 170 Tasman Drive 1308 San Jose, CA 95134 1309 USA 1311 Email: sina@cisco.com 1313 Abhay Roy 1314 Cisco Systems 1315 170 Tasman Drive 1316 San Jose, CA 95134 1317 USA 1319 Email: akr@cisco.com 1321 Fred Baker 1322 Cisco Systems 1323 Santa Barbara, CA 93117 1324 USA 1326 Email: fred@cisco.com