idnits 2.17.00 (12 Aug 2021) /tmp/idnits34304/draft-ietf-ospf-ospfv3-autoconfig-13.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5340, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5340, updated by this document, for RFC5378 checks: 2004-11-30) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 27, 2015) is 2671 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) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'IANA-GUIDELINES') (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem 3 Internet-Draft Cisco Systems 4 Updates: 5340 (if approved) J. Arkko 5 Intended status: Standards Track Ericsson 6 Expires: July 31, 2015 January 27, 2015 8 OSPFv3 Auto-Configuration 9 draft-ietf-ospf-ospfv3-autoconfig-13.txt 11 Abstract 13 OSPFv3 is a candidate for deployments in environments where auto- 14 configuration is a requirement. One such environment is the IPv6 15 home network where users expect to simply plug in a router and have 16 it automatically use OSPFv3 for intra-domain routing. This document 17 describes the necessary mechanisms for OSPFv3 to be self-configuring. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 31, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 55 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 3 56 2. OSPFv3 Default Configuration . . . . . . . . . . . . . . . . 4 57 3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . . 5 58 3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . 5 59 4. OSPFv3 Minimal Authentication Configuration . . . . . . . . . 5 60 5. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . 6 61 6. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . 6 62 7. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 6 63 7.1. Duplicate Router ID Detection for Neighbors . . . . . . . 7 64 7.2. Duplicate Router ID Detection for Non-Neighbors . . . . . 7 65 7.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . 7 66 7.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 9 67 7.3. Duplicate Router ID Resolution . . . . . . . . . . . . . 9 68 7.4. Change to RFC 2328 Section 13.4, 'Receiving Self- 69 Originated LSAs' . . . . . . . . . . . . . . . . . . . . 9 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 9. Management Considerations . . . . . . . . . . . . . . . . . . 10 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 11.2. Informative References . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 OSPFv3 [OSPFV3] is a candidate for deployments in environments where 81 auto-configuration is a requirement. Its operation is largely 82 unchanged from the base OSPFv3 protocol specification [OSPFV3]. 84 The following aspects of OSPFv3 auto-configuration are described: 86 1. Default OSPFv3 Configuration 88 2. HelloInterval/RouterDeadInterval Flexibility 90 3. Unique OSPFv3 Router ID generation 92 4. OSPFv3 Adjacency Formation 94 5. Duplicate OSPFv3 Router ID Resolution 96 1.1. Requirements notation 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC-KEYWORDS]. 102 1.2. Acknowledgments 104 This specification was inspired by the work presented in the Homenet 105 working group meeting in October 2011 in Philadelphia, Pennsylvania. 106 In particular, we would like to thank Fred Baker, Lorenzo Colitti, 107 Ole Troan, Mark Townsley, and Michael Richardson. 109 Arthur Dimitrelis and Aidan Williams did prior work in OSPFv3 auto- 110 configuration in the expired "Autoconfiguration of routers using a 111 link state routing protocol" IETF Draft. There are many similarities 112 between the concepts and techniques in this document. 114 Thanks for Abhay Roy and Manav Bhatia for comments regarding 115 duplicate router-id processing. 117 Thanks for Alvaro Retana and Michael Barnes for comments regarding 118 OSPFv3 Instance ID auto-configuration. 120 Thanks to Faraz Shamim for review and comments. 122 Thanks to Mark Smith for the requirement to reduce the adjacency 123 formation delay in the back-to-back ethernet topologies that are 124 prevalent in home networks. 126 Thanks to Les Ginsberg for document review and recommendations on 127 OSPFv3 hardware fingerprint content. 129 Thanks to Curtis Villamizar for document review and analysis of 130 duplicate router-id resolution nuances. 132 Thanks to Uma Chunduri for comments during OSPF WG last call. 134 Thanks to Martin Vigoureux for Routing Area Directorate review and 135 comments. 137 Thanks to Adam Montville for Security Area Directorate review and 138 comments. 140 Thanks to Qin Wu for Operations & Management Area Directorate review 141 and comments. 143 Thanks to Robert Sparks for General Area (GEN-ART) review and 144 comments. 146 Thanks to Rama Darbha for review and comments. 148 Special thanks go to Markus Stenberg for his implementation of this 149 specification in Bird. 151 Special thanks also go to David Lamparter for his implementation of 152 this specification in Quagga. 154 The RFC text was produced using Marshall Rose's xml2rfc tool. 156 2. OSPFv3 Default Configuration 158 For complete auto-configuration, OSPFv3 will need to choose suitable 159 configuration defaults. These include: 161 1. Area 0 Only - All auto-configured OSPFv3 interfaces MUST be in 162 area 0. 164 2. OSPFv3 SHOULD be auto-configured for IPv6 on all interfaces 165 intended as general IPv6-capable routers. Optionally, an 166 interface MAY be excluded if it is clear that running OSPFv3 on 167 the interface is not required. For example, if manual 168 configuration or another condition indicates that an interface is 169 connected to an Internet Service Provider (ISP) and there is no 170 Border Gateway Protocol (BGP) [BGP] peering, there is typically 171 no need to employ OSPFv3. In fact, [IPv6-CPE] specifically 172 requires that IPv6 Customer Premise Equipment (CPE) routers do 173 not initiate any dynamic routing protocol by default on the 174 router's WAN, i.e., ISP-facing, interface. In home networking 175 environments, an interface where no OSPFv3 neighbors are found 176 but a DHCP IPv6 prefix can be acquired may be considered an ISP- 177 facing interface and running OSPFv3 is unnecessary. 179 3. OSPFv3 interfaces will be auto-configured to an interface type 180 corresponding to their layer-2 capability. For example, Ethernet 181 interfaces and vanilla Wi-Fi interfaces will be auto-configured 182 as OSPFv3 broadcast networks and Point-to-Point Protocol (PPP) 183 interfaces will be auto-configured as OSPFv3 Point-to-Point 184 interfaces. Most extant OSPFv3 implementations do this already. 185 Auto-configured operation over wireless networks requiring a 186 point-to-multipoint (P2MP) topology and dynamic metrics based on 187 wireless feedback is not within the scope of this document. 188 However, auto-configuration is not precluded in these 189 environments. 191 4. OSPFv3 interfaces MAY use an arbitrary HelloInterval and 192 RouterDeadInterval as specified in Section 3. Of course, an 193 identical HelloInterval and RouterDeadInterval will still be 194 required to form an adjacency with an OSPFv3 router not 195 supporting auto-configuration [OSPFV3]. 197 5. All OSPFv3 interfaces SHOULD be auto-configured to use an 198 Interface Instance ID of 0 that corresponds to the base IPv6 199 unicast address family instance ID as defined in [OSPFV3-AF]. 200 Similarly, if IPv4 unicast addresses are advertised in a separate 201 auto-configured OSPFv3 instance, the base IPv4 unicast address 202 family instance ID value, i.e., 64, SHOULD be auto-configured as 203 the Interface Instance ID for all interfaces corresponding to the 204 IPv4 unicast OSPFv3 instance [OSPFV3-AF]. 206 3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility 208 Auto-configured OSPFv3 routers will not require an identical 209 HelloInterval and RouterDeadInterval to form adjacencies. Rather, 210 the received HelloInterval will be ignored and the received 211 RouterDeadInterval will be used to determine OSPFv3 liveliness with 212 the sending router. In other words, the Neighbor Inactivity Timer 213 (Section 10 of [OSPFV2]) for each neighbor will reflect that 214 neighbor's advertised RouterDeadInterval and MAY be different from 215 other OSPFv3 routers on the link without impacting adjacency 216 formation. A similar mechanism requiring additional signaling is 217 proposed for all OSPFv2 and OSPFv3 routers [ASYNC-HELLO]. 219 3.1. Wait Timer Reduction 221 In many situations, auto-configured OSPFv3 routers will be deployed 222 in environments where back-to-back ethernet connections are utilized. 223 When this is the case, an OSPFv3 broadcast interface will not come up 224 until the other OSPFv3 router is connected and the routers will wait 225 RouterDeadInterval seconds before forming an adjacency [OSPFV2]. In 226 order to reduce this delay, an auto-configured OSPFv3 router MAY 227 reduce the wait interval to a value no less than (HelloInterval + 1). 228 Reducing the setting will slightly increase the likelihood of the 229 Designated Router (DR) flapping but is preferable to the long 230 adjacency formation delay. Note that this value is not included in 231 OSPFv3 Hello packets and does not impact interoperability. 233 4. OSPFv3 Minimal Authentication Configuration 235 In many deployments, the requirement for OSPFv3 authentication 236 overrides the goal of complete OSPFv3 autoconfiguration. Therefore, 237 it is RECOMMENDED that OSPFv3 routers supporting this specification 238 minimally offer an option to explicitly configure a single password 239 for HMAC-SHA authentication as described in [OSPFV3-AUTH-TRAILER]. 240 When configured, the password will be used on all auto-configured 241 interfaces with the Security Association Identifier (SA ID) set to 1 242 and HMAC-SHA-256 used as the authentication algorithm. 244 5. OSPFv3 Router ID Selection 246 An OSPFv3 router requires a unique Router ID within the OSPFv3 247 routing domain for correct protocol operation. Existing Router ID 248 selection algorithms (section C.1 in [OSPFV2] and [OSPFV3]) are not 249 viable since they are dependent on a unique IPv4 interface address 250 which is not likely to be available in autoconfigured deployments. 251 An OSPFv3 router implementing this specification will select a 252 router-id that has a high probability of uniqueness. A pseudo-random 253 number SHOULD be used for the OSPFv3 Router ID. The generation 254 SHOULD be seeded with a variable that is likely to be unique in the 255 applicable OSPFv3 router deployment. A good choice of seed would be 256 some portion or hash of the Router-Hardware-Fingerprint as described 257 in Section 7.2.2. 259 Since there is a possibility of a Router ID collision, duplicate 260 Router ID detection and resolution are required as described in 261 Section 7 and Section 7.3. OSPFv3 routers SHOULD maintain the last 262 successfully chosen Router ID in non-volatile storage to avoid 263 collisions subsequent to when an autoconfigured OSPFv3 router is 264 first added to the OSPFv3 routing domain. 266 6. OSPFv3 Adjacency Formation 268 Since OSPFv3 uses IPv6 link-local addresses for all protocol messages 269 other than messages sent on virtual links (which are not applicable 270 to auto-configuration), OSPFv3 adjacency formation can proceed as 271 soon as a Router ID has been selected and the IPv6 link-local address 272 has completed Duplicate Address Detection (DAD) as specified in IPv6 273 Stateless Address Autoconfiguration [SLAAC]. Otherwise, the only 274 changes to the OSPFv3 base specification are supporting 275 HelloInterval/RouterDeadInterval flexibility as described in 276 Section 3 and duplicate Router ID detection and resolution as 277 described in Section 7 and Section 7.3. 279 7. OSPFv3 Duplicate Router ID Detection and Resolution 281 There are two cases of duplicate OSPFv3 Router ID detection. One 282 where the OSPFv3 router with the duplicate Router ID is directly 283 connected and one where it is not. In both cases, the duplicate 284 resolution is for one of the routers to select a new OSPFv3 Router 285 ID. 287 7.1. Duplicate Router ID Detection for Neighbors 289 In this case, a duplicate Router ID is detected if any valid OSPFv3 290 packet is received with the same OSPFv3 Router ID but a different 291 IPv6 link-local source address. Once this occurs, the OSPFv3 router 292 with the numerically smaller IPv6 link-local address will need to 293 select a new Router ID as described in Section 7.3. Note that the 294 fact that the OSPFv3 router is a neighbor on a non-virtual interface 295 implies that the router is directly connected. An OSPFv3 router 296 implementing this specification should assure that the inadvertent 297 connection of multiple router interfaces to the same physical link is 298 not misconstrued as detection of an OSPFv3 neighbor with a duplicate 299 Router ID. 301 7.2. Duplicate Router ID Detection for Non-Neighbors 303 OSPFv3 routers implementing auto-configuration, as specified herein, 304 MUST originate an Auto-Configuration (AC) Link State Advertisement 305 (LSA) including the Router-Hardware-Fingerprint Type-Length-Value 306 (TLV). The Router-Hardware-Fingerprint TLV contains a variable 307 length value that has a very high probability of uniquely identifying 308 the advertising OSPFv3 router. An OSPFv3 router implementing this 309 specification MUST detect received Auto-Configuration LSAs with its 310 Router ID specified in the LSA header. LSAs received with the local 311 OSPFv3 Router's Router ID in the LSA header are perceived as self- 312 originated (see section 4.6 of [OSPFV3]). In these received Auto- 313 Configuration LSAs, the Router-Hardware-Fingerprint TLV is compared 314 against the OSPFv3 Router's own router hardware fingerprint. If the 315 fingerprints are not equal, there is a duplicate Router ID conflict 316 and the OSPFv3 router with the numerically smaller router hardware 317 fingerprint MUST select a new Router ID as described in Section 7.3. 319 This new LSA is designated for information related to OSPFv3 Auto- 320 configuration and, in the future, could be used for other auto- 321 configuration information, e.g., global IPv6 prefixes. However, this 322 is beyond the scope of this document. 324 7.2.1. OSPFv3 Router Auto-Configuration LSA 326 The OSPFv3 Auto-Configuration (AC) LSA has a function code of TBD and 327 the S2/S1 bits set to 01 indicating Area Flooding Scope. The U bit 328 will be set indicating that the OSPFv3 AC LSA should be flooded even 329 if it is not understood. The Link State ID (LSID) value will be a 330 integer index used to discriminate between multiple AC LSAs 331 originated by the same OSPFv3 router. This specification only 332 describes the contents of an AC LSA with a Link State ID (LSID) of 0. 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | LS age |1|0|1| TBD | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Link State ID | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Advertising Router | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | LS sequence number | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | LS checksum | Length | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | 348 +- TLVs -+ 349 | ... | 351 OSPFv3 Auto-Configuration (AC) LSA 353 The format of the TLVs within the body of an AC LSA is the same as 354 the format used by the Traffic Engineering Extensions to OSPF [TE]. 355 The LSA payload consists of one or more nested Type/Length/Value 356 (TLV) triplets. The format of each TLV is: 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Type | Length | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Value... | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 TLV Format 368 The Length field defines the length of the value portion in octets 369 (thus a TLV with no value portion would have a length of 0). The TLV 370 is padded to 4-octet alignment; padding is not included in the length 371 field (so a 3-octet value would have a length of 3, but the total 372 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 373 aligned. For example, a 1-byte value would have the length field set 374 to 1, and 3 octets of padding would be added to the end of the value 375 portion of the TLV. Unrecognized types are ignored. 377 The new LSA is designated for information related to OSPFv3 Auto- 378 configuration and, in the future, can be used other auto- 379 configuration information. 381 7.2.2. Router-Hardware-Fingerprint TLV 383 The Router-Hardware-Fingerprint TLV is the first TLV defined for the 384 OSPFv3 Auto-Configuration (AC) LSA. It will have type 1 and MUST be 385 advertised in the LSID OSPFv3 AC LSA with an LSID of 0. It SHOULD 386 occur, at most, once and the first instance of the TLV will take 387 precedence over subsequent TLV instances. The length of the Router- 388 Hardware-Fingerprint is variable but must be 32 octets or greater. 390 The contents of the hardware fingerprint MUST be some combination of 391 MAC addresses, CPU ID, or serial number(s) that provides an extremely 392 high probability of uniqueness. It is RECOMMENDED that one or more 393 available universal tokens (e.g., IEEE 802 48-bit MAC addresses or 394 IEEE EUI-64 Identifiers [EUI64]) associated with the OSPFv3 router be 395 included in the hardware fingerprint. It MUST be based on hardware 396 attributes that will not change across hard and soft restarts. 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | 1 | >32 | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Router Hardware Fingerprint | 404 o 405 o 406 o 407 | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Router-Hardware-Fingerprint TLV Format 412 7.3. Duplicate Router ID Resolution 414 The OSPFv3 router selected to resolve the duplicate OSPFv3 Router ID 415 condition must select a new OSPFv3 Router ID. After selecting a new 416 Router ID, all self-originated LSAs MUST be reoriginated, and any 417 OSPFv3 neighbor adjacencies MUST be reestablished. The OSPFv3 router 418 retaining the Router ID causing the conflict will reoriginate or 419 purge stale any LSAs as described in Section 13.4 [OSPFV2]. 421 7.4. Change to RFC 2328 Section 13.4, 'Receiving Self-Originated LSAs' 423 RFC 2328 [OSPFV2], Section 13.4, describes the processing of received 424 self-originated LSAs. If the received LSA doesn't exist, the 425 receiving router will purge it from the OSPF routing domain. If the 426 LSA is newer than the version in the Link State Database (LSDB), the 427 receiving router will originate a newer version by advancing the LSA 428 sequence number and reflooding. Since it is possible for an auto- 429 configured OSPFv3 router to choose a duplicate OSPFv3 Router ID, 430 OSPFv3 routers implementing this specification should detect when 431 multiple instances of the same self-originated LSA are purged or 432 reoriginated since this is indicative of an OSPFv3 router with a 433 duplicate Router ID in the OSPFv3 routing domain. When this 434 condition is detected, the OSPFv3 router SHOULD delay self-originated 435 LSA processing for LSAs that have recently been purged or reflooded. 436 This specification recommends 10 seconds as the interval defining 437 recent self-originated LSA processing and an exponential back off of 438 1 to 8 seconds for the processing delay. This additional delay 439 should allow for the mechanisms described in Section 7 to resolve the 440 duplicate OSPFv3 Router ID conflict. 442 8. Security Considerations 444 A unique OSPFv3 Interface Instance ID is used for auto-configuration 445 to prevent inadvertent OSPFv3 adjacency formation, see Section 2 447 The goals of security and complete OSPFv3 auto-configuration are 448 somewhat contradictory. When no explicit security configuration 449 takes place, auto-configuration implies that additional devices 450 placed in the network are automatically adopted as a part of the 451 network. However, auto-configuration can also be combined with 452 password configuration (see Section 4) or future extensions for 453 automatic pairing between devices. These mechanisms can help provide 454 an automatically configured, securely routed network. 456 In deployments where stronger authentification or encryption is 457 required, OSPFv3 IPsec [OSPFV3-IPSEC] or stronger OSPFv3 458 Authentication trailer [OSPFV3-AUTH-TRAILER] algorithms MAY be used 459 at the expense of additional configuration. The configuration and 460 operational description of such deployments is beyond the scope of 461 this document. 463 9. Management Considerations 465 It is RECOMMENDED that OSPFv3 routers supporting this specification 466 also allow explicit configuration of OSPFv3 parameters as specified 467 in Appendix C of [OSPFV3]. The would allow explicit override of 468 autoconfigured parameters in situations where it is required (e.g., 469 if the deployment requires multiple OSPFv3 areas). This is in 470 addition to the authentication key configuration recommended in 471 Section 4 which supports OSPFv3 authentication with the absolute 472 minimum manual configuration. 474 Since there is a small possibility of OSPFv3 Router ID collisions, 475 manual configuration of OSPFv3 Router IDs is RECOMMENDED in OSPFv3 476 routing domains where route recovergence due to a router ID change is 477 intolerable. 479 10. IANA Considerations 481 This specification defines an OSPFv3 LSA Type for the OSPFv3 Auto- 482 Configuration (AC) LSA, as described in Section 7.2.1. The value TBD 483 will be allocated from the existing "OSPFv3 LSA Function Code" 484 registry for the OSPFv3 Auto-Configuration LSA. 486 This specification also creates a registry for OSPFv3 Auto- 487 Configuration (AC) LSA TLVs. This registry should be placed in the 488 existing OSPFv3 IANA registry, and new values can be allocated via 489 IETF Review or, under exceptional circumstances, IESG Approval. 490 [IANA-GUIDELINES] 492 Three initial values are allocated: 494 o 0 is marked as reserved. 496 o 1 is Router-Hardware-Fingerprint TLV (Section 7.2.2). 498 o 65535 is an Auto-configuration-Experiment-TLV, a common value that 499 can be used for experimental purposes. 501 11. References 503 11.1. Normative References 505 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 507 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 508 for IPv6", RFC 5340, July 2008. 510 [OSPFV3-AF] 511 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 512 Aggarwal, "Support of Address Families in OSPFv3", RFC 513 5838, April 2010. 515 [OSPFV3-AUTH-TRAILER] 516 Bhatia, M., Manral, V., and A. Lindem, "Supporting 517 Authentication Trailer for OSPFv3", RFC 7166, February 518 2012. 520 [RFC-KEYWORDS] 521 Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", RFC 2119, March 1997. 524 [SLAAC] Thomson, S., Narten, T., and J. Tatuya, "IPv6 Stateless 525 Address Autoconfiguration", RFC 4862, September 2007. 527 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 528 Extensions to OSPF", RFC 3630, September 2003. 530 11.2. Informative References 532 [ASYNC-HELLO] 533 Anand, M., Grover, H., and A. Roy, "Asymmetric OSPF Hold 534 Timer", draft-madhukar-ospf-agr-asymmetric-01.txt (work in 535 progress), June 2013. 537 [BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 538 Protocol 4 (BGP-4)", RFC 4271, January 2006. 540 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 541 Registration Authority", IEEE Tutorial 542 http://standards.ieee.org/regauth/oui/tutorials/ 543 EUI64.html, March 1997. 545 [IANA-GUIDELINES] 546 Narten, T. and H. Alvestrand, "Guidelines for Writing an 547 IANA Considerations Sectino in RFCs", RFC 5226, May 2008. 549 [IPv6-CPE] 550 Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 551 Requirements for IPv6 Customer Edge Routers", RFC 7084, 552 November 2013. 554 [OSPFV3-IPSEC] 555 Gupta, M. and S. Melam, "Authentication/Confidentiality 556 for OSPFv3", RFC 4552, June 2006. 558 Authors' Addresses 560 Acee Lindem 561 Cisco Systems 562 301 Midenhall Way 563 Cary, NC 27513 564 USA 566 Email: acee@cisco.com 567 Jari Arkko 568 Ericsson 569 Jorvas, 02420 570 Finland 572 Email: jari.arkko@piuha.net