idnits 2.17.00 (12 Aug 2021) /tmp/idnits33622/draft-ietf-ospf-ospfv3-autoconfig-14.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 (February 9, 2015) is 2658 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: August 13, 2015 February 9, 2015 8 OSPFv3 Auto-Configuration 9 draft-ietf-ospf-ospfv3-autoconfig-14.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 August 13, 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 2. OSPFv3 Default Configuration . . . . . . . . . . . . . . . . 3 56 3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . . 4 57 3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . 4 58 4. OSPFv3 Minimal Authentication Configuration . . . . . . . . . 4 59 5. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . 5 60 6. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . 5 61 7. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 5 62 7.1. Duplicate Router ID Detection for Neighbors . . . . . . . 6 63 7.2. Duplicate Router ID Detection for Non-Neighbors . . . . . 6 64 7.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . 6 65 7.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 8 66 7.3. Duplicate Router ID Resolution . . . . . . . . . . . . . 8 67 7.4. Change to RFC 2328 Section 13.4, 'Receiving Self- 68 Originated LSAs' . . . . . . . . . . . . . . . . . . . . 9 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 9. Management Considerations . . . . . . . . . . . . . . . . . . 10 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 12.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 OSPFv3 [OSPFV3] is a candidate for deployments in environments where 81 auto-configuration is a requirement. This document describes 82 extensions to OSPFv3 to enable it to operate in these environments. 83 In this mode of operation, the protocol is largely unchanged from the 84 base OSPFv3 protocol specification [OSPFV3]. Since the goals of 85 auto-configuration and security can be conflicting, operators and 86 network administrators should carefully consider their security 87 requirements before deploying the solution described in this 88 document. Refer to Section 8 for more information. 90 The following aspects of OSPFv3 auto-configuration are described in 91 this document: 93 1. Default OSPFv3 Configuration 95 2. HelloInterval/RouterDeadInterval Flexibility 96 3. Unique OSPFv3 Router ID generation 98 4. OSPFv3 Adjacency Formation 100 5. Duplicate OSPFv3 Router ID Resolution 102 1.1. Requirements notation 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC-KEYWORDS]. 108 2. OSPFv3 Default Configuration 110 For complete auto-configuration, OSPFv3 will need to choose suitable 111 configuration defaults. These include: 113 1. Area 0 Only - All auto-configured OSPFv3 interfaces MUST be in 114 area 0. 116 2. OSPFv3 SHOULD be auto-configured on all IPv6-capable interface on 117 the router. An interface MAY be excluded if it is clear that 118 running OSPFv3 on the interface is not required. For example, if 119 manual configuration or another condition indicates that an 120 interface is connected to an Internet Service Provider (ISP), 121 there is typically no need to employ OSPFv3. In fact, [IPv6-CPE] 122 specifically requires that IPv6 Customer Premise Equipment (CPE) 123 routers do not initiate any dynamic routing protocol by default 124 on the router's WAN, i.e., ISP-facing, interface. In home 125 networking environments, an interface where no OSPFv3 neighbors 126 are found but a DHCP IPv6 prefix can be acquired may be 127 considered an ISP-facing interface and running OSPFv3 is 128 unnecessary. 130 3. OSPFv3 interfaces will be auto-configured to an interface type 131 corresponding to their layer-2 capability. For example, Ethernet 132 interfaces and Wi-Fi interfaces will be auto-configured as OSPFv3 133 broadcast networks and Point-to-Point Protocol (PPP) interfaces 134 will be auto-configured as OSPFv3 Point-to-Point interfaces. 135 Most extant OSPFv3 implementations do this already. Auto- 136 configured operation over wireless networks requiring a point-to- 137 multipoint (P2MP) topology and dynamic metrics based on wireless 138 feedback is not within the scope of this document. However, 139 auto-configuration is not precluded in these environments. 141 4. OSPFv3 interfaces MAY use an arbitrary HelloInterval and 142 RouterDeadInterval as specified in Section 3. Of course, an 143 identical HelloInterval and RouterDeadInterval will still be 144 required to form an adjacency with an OSPFv3 router not 145 supporting auto-configuration [OSPFV3]. 147 5. All OSPFv3 interfaces SHOULD be auto-configured to use an 148 Interface Instance ID of 0 that corresponds to the base IPv6 149 unicast address family instance ID as defined in [OSPFV3-AF]. 150 Similarly, if IPv4 unicast addresses are advertised in a separate 151 auto-configured OSPFv3 instance, the base IPv4 unicast address 152 family instance ID value, i.e., 64, SHOULD be auto-configured as 153 the Interface Instance ID for all interfaces corresponding to the 154 IPv4 unicast OSPFv3 instance [OSPFV3-AF]. 156 3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility 158 Auto-configured OSPFv3 routers will not require an identical 159 HelloInterval and RouterDeadInterval to form adjacencies. Rather, 160 the received HelloInterval will be ignored and the received 161 RouterDeadInterval will be used to determine OSPFv3 liveliness with 162 the sending router. In other words, the Neighbor Inactivity Timer 163 (Section 10 of [OSPFV2]) for each neighbor will reflect that 164 neighbor's advertised RouterDeadInterval and MAY be different from 165 other OSPFv3 routers on the link without impacting adjacency 166 formation. A similar mechanism requiring additional signaling is 167 proposed for all OSPFv2 and OSPFv3 routers [ASYNC-HELLO]. 169 3.1. Wait Timer Reduction 171 In many situations, auto-configured OSPFv3 routers will be deployed 172 in environments where back-to-back ethernet connections are utilized. 173 When this is the case, an OSPFv3 broadcast interface will not come up 174 until the other OSPFv3 router is connected and the routers will wait 175 RouterDeadInterval seconds before forming an adjacency [OSPFV2]. In 176 order to reduce this delay, an auto-configured OSPFv3 router MAY 177 reduce the wait interval to a value no less than (HelloInterval + 1). 178 Reducing the setting will slightly increase the likelihood of the 179 Designated Router (DR) flapping but is preferable to the long 180 adjacency formation delay. Note that this value is not included in 181 OSPFv3 Hello packets and does not impact interoperability. 183 4. OSPFv3 Minimal Authentication Configuration 185 In many deployments, the requirement for OSPFv3 authentication 186 overrides the goal of complete OSPFv3 autoconfiguration. Therefore, 187 it is RECOMMENDED that OSPFv3 routers supporting this specification 188 minimally offer an option to explicitly configure a single password 189 for HMAC-SHA authentication as described in [OSPFV3-AUTH-TRAILER]. 190 It is RECOMMENDED that the password entered as ASCII hexadecimal 191 digits and that 32 or more digits to facilitate a password with a 192 high degree of entropy. When configured, the password will be used 193 on all auto-configured interfaces with the Security Association 194 Identifier (SA ID) set to 1 and HMAC-SHA-256 used as the 195 authentication algorithm. 197 5. OSPFv3 Router ID Selection 199 An OSPFv3 router requires a unique Router ID within the OSPFv3 200 routing domain for correct protocol operation. Existing Router ID 201 selection algorithms (section C.1 in [OSPFV2] and [OSPFV3]) are not 202 viable since they are dependent on a unique IPv4 interface address 203 which is not likely to be available in autoconfigured deployments. 204 An OSPFv3 router implementing this specification will select a 205 router-id that has a high probability of uniqueness. A pseudo-random 206 number SHOULD be used for the OSPFv3 Router ID. The generation 207 SHOULD be seeded with a variable that is likely to be unique in the 208 applicable OSPFv3 router deployment. A good choice of seed would be 209 some portion or hash of the Router-Hardware-Fingerprint as described 210 in Section 7.2.2. 212 Since there is a possibility of a Router ID collision, duplicate 213 Router ID detection and resolution are required as described in 214 Section 7 and Section 7.3. OSPFv3 routers SHOULD maintain the last 215 successfully chosen Router ID in non-volatile storage to avoid 216 collisions subsequent to when an autoconfigured OSPFv3 router is 217 first added to the OSPFv3 routing domain. 219 6. OSPFv3 Adjacency Formation 221 Since OSPFv3 uses IPv6 link-local addresses for all protocol messages 222 other than messages sent on virtual links (which are not applicable 223 to auto-configuration), OSPFv3 adjacency formation can proceed as 224 soon as a Router ID has been selected and the IPv6 link-local address 225 has completed Duplicate Address Detection (DAD) as specified in IPv6 226 Stateless Address Autoconfiguration [SLAAC]. Otherwise, the only 227 changes to the OSPFv3 base specification are supporting 228 HelloInterval/RouterDeadInterval flexibility as described in 229 Section 3 and duplicate Router ID detection and resolution as 230 described in Section 7 and Section 7.3. 232 7. OSPFv3 Duplicate Router ID Detection and Resolution 234 There are two cases of duplicate OSPFv3 Router ID detection. One 235 where the OSPFv3 router with the duplicate Router ID is directly 236 connected and one where it is not. In both cases, the duplicate 237 resolution is for one of the routers to select a new OSPFv3 Router 238 ID. 240 7.1. Duplicate Router ID Detection for Neighbors 242 In this case, a duplicate Router ID is detected if any valid OSPFv3 243 packet is received with the same OSPFv3 Router ID but a different 244 IPv6 link-local source address. Once this occurs, the OSPFv3 router 245 with the numerically smaller IPv6 link-local address will need to 246 select a new Router ID as described in Section 7.3. Note that the 247 fact that the OSPFv3 router is a neighbor on a non-virtual interface 248 implies that the router is directly connected. An OSPFv3 router 249 implementing this specification should assure that the inadvertent 250 connection of multiple router interfaces to the same physical link is 251 not misconstrued as detection of an OSPFv3 neighbor with a duplicate 252 Router ID. 254 7.2. Duplicate Router ID Detection for Non-Neighbors 256 OSPFv3 routers implementing auto-configuration, as specified herein, 257 MUST originate an Auto-Configuration (AC) Link State Advertisement 258 (LSA) including the Router-Hardware-Fingerprint Type-Length-Value 259 (TLV). The Router-Hardware-Fingerprint TLV contains a variable 260 length value that has a very high probability of uniquely identifying 261 the advertising OSPFv3 router. An OSPFv3 router implementing this 262 specification MUST detect received Auto-Configuration LSAs with its 263 Router ID specified in the LSA header. LSAs received with the local 264 OSPFv3 Router's Router ID in the LSA header are perceived as self- 265 originated (see section 4.6 of [OSPFV3]). In these received Auto- 266 Configuration LSAs, the Router-Hardware-Fingerprint TLV is compared 267 against the OSPFv3 Router's own router hardware fingerprint. If the 268 fingerprints are not equal, there is a duplicate Router ID conflict 269 and the OSPFv3 router with the numerically smaller router hardware 270 fingerprint MUST select a new Router ID as described in Section 7.3. 272 This new LSA is designated for information related to OSPFv3 Auto- 273 configuration and, in the future, could be used for other auto- 274 configuration information, e.g., global IPv6 prefixes. However, this 275 is beyond the scope of this document. 277 7.2.1. OSPFv3 Router Auto-Configuration LSA 279 The OSPFv3 Auto-Configuration (AC) LSA has a function code of TBD and 280 the S2/S1 bits set to 01 indicating Area Flooding Scope. The U bit 281 will be set indicating that the OSPFv3 AC LSA should be flooded even 282 if it is not understood. The Link State ID (LSID) value will be a 283 integer index used to discriminate between multiple AC LSAs 284 originated by the same OSPFv3 router. This specification only 285 describes the contents of an AC LSA with a Link State ID (LSID) of 0. 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | LS age |1|0|1| TBD | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Link State ID | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Advertising Router | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | LS sequence number | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | LS checksum | Length | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | 301 +- TLVs -+ 302 | ... | 304 OSPFv3 Auto-Configuration (AC) LSA 306 The format of the TLVs within the body of an AC LSA is the same as 307 the format used by the Traffic Engineering Extensions to OSPF [TE]. 308 The LSA payload consists of one or more nested Type/Length/Value 309 (TLV) triplets. The format of each TLV is: 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Type | Length | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Value... | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 TLV Format 321 The Length field defines the length of the value portion in octets 322 (thus a TLV with no value portion would have a length of 0). The TLV 323 is padded to 4-octet alignment; padding is not included in the length 324 field (so a 3-octet value would have a length of 3, but the total 325 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 326 aligned. For example, a 1-byte value would have the length field set 327 to 1, and 3 octets of padding would be added to the end of the value 328 portion of the TLV. Unrecognized types are ignored. 330 The new LSA is designated for information related to OSPFv3 Auto- 331 configuration and, in the future, can be used other auto- 332 configuration information. 334 7.2.2. Router-Hardware-Fingerprint TLV 336 The Router-Hardware-Fingerprint TLV is the first TLV defined for the 337 OSPFv3 Auto-Configuration (AC) LSA. It will have type 1 and MUST be 338 advertised in the LSID OSPFv3 AC LSA with an LSID of 0. It SHOULD 339 occur, at most, once and the first instance of the TLV will take 340 precedence over subsequent TLV instances. The length of the Router- 341 Hardware-Fingerprint is variable but must be 32 octets or greater. 342 If the Router-Hardware-Fingerprint TLV is not present as the first 343 TLV, the AC-LSA is considered malformed and is ignored for the 344 purposes of duplicate Router ID detection. Additionally, the event 345 SHOULD be logged. 347 The contents of the hardware fingerprint MUST have an extremely high 348 probability of uniqueness. It SHOULD be constructed from the 349 concatenation of a number of local values that themselves have a high 350 likelihood of uniqueness, such as MAC addresses, CPU ID, or serial 351 numbers. It is RECOMMENDED that one or more available universal 352 tokens (e.g., IEEE 802 48-bit MAC addresses or IEEE EUI-64 353 Identifiers [EUI64]) associated with the OSPFv3 router be included in 354 the hardware fingerprint. It MUST be based on hardware attributes 355 that will not change across hard and soft restarts. 357 0 1 2 3 358 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | 1 | >32 | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Router Hardware Fingerprint | 363 o 364 o 365 o 366 | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Router-Hardware-Fingerprint TLV Format 371 7.3. Duplicate Router ID Resolution 373 The OSPFv3 router selected to resolve the duplicate OSPFv3 Router ID 374 condition must select a new OSPFv3 Router ID. The OSPFv3 router 375 SHOULD reduce the possibility of a subsequent Router ID collision by 376 checking the Link State Database for an OSPFv3 Auto-Configuration LSA 377 with the newly selected Router ID and a different Router-Hardware- 378 Fingerprint. If one is detected, a new Router ID should be selected 379 without going through the resolution process Section 7. After 380 selecting a new Router ID, all self-originated LSAs MUST be 381 reoriginated, and any OSPFv3 neighbor adjacencies MUST be 382 reestablished. The OSPFv3 router retaining the Router ID causing the 383 conflict will reoriginate or purge stale any LSAs as described in 384 Section 13.4 [OSPFV2]. 386 7.4. Change to RFC 2328 Section 13.4, 'Receiving Self-Originated LSAs' 388 RFC 2328 [OSPFV2], Section 13.4, describes the processing of received 389 self-originated LSAs. If the received LSA doesn't exist, the 390 receiving router will purge it from the OSPF routing domain. If the 391 LSA is newer than the version in the Link State Database (LSDB), the 392 receiving router will originate a newer version by advancing the LSA 393 sequence number and reflooding. Since it is possible for an auto- 394 configured OSPFv3 router to choose a duplicate OSPFv3 Router ID, 395 OSPFv3 routers implementing this specification should detect when 396 multiple instances of the same self-originated LSA are purged or 397 reoriginated since this is indicative of an OSPFv3 router with a 398 duplicate Router ID in the OSPFv3 routing domain. When this 399 condition is detected, the OSPFv3 router SHOULD delay self-originated 400 LSA processing for LSAs that have recently been purged or reflooded. 401 This specification recommends 10 seconds as the interval defining 402 recent self-originated LSA processing and an exponential back off of 403 1 to 8 seconds for the processing delay. This additional delay 404 should allow for the mechanisms described in Section 7 to resolve the 405 duplicate OSPFv3 Router ID conflict. 407 8. Security Considerations 409 A unique OSPFv3 Interface Instance ID is used for auto-configuration 410 to prevent inadvertent OSPFv3 adjacency formation, see Section 2 412 The goals of security and complete OSPFv3 auto-configuration are 413 somewhat contradictory. When no explicit security configuration 414 takes place, auto-configuration implies that additional devices 415 placed in the network are automatically adopted as a part of the 416 network. However, auto-configuration can also be combined with 417 password configuration (see Section 4) or future extensions for 418 automatic pairing between devices. These mechanisms can help provide 419 an automatically configured, securely routed network. 421 In deployments where different authentification algorithm, per- 422 interface keys, or encryption is required, OSPFv3 IPsec 423 [OSPFV3-IPSEC] or alternate OSPFv3 Authentication trailer 424 [OSPFV3-AUTH-TRAILER] algorithms MAY be used at the expense of 425 additional configuration. The configuration and operational 426 description of such deployments is beyond the scope of this document. 427 However, a deployment could always revert to explicit configuration 428 as described in Section 9 for features such as IPsec, per-interface 429 keys, or alternate authentication algorithms. 431 The introduction, either malious or accidental, of an OSPFv3 router 432 with a duplicate Router ID is an attack point for OSPFv3 routing 433 domains. This is due to the fact that OSPFv3 routers will interpret 434 LSAs advertised by the router with the same ROuter ID as self- 435 originated LSAs and attempt to purge them from the routing domain. 436 The mechanisms in Section 7.4 will mitigate the effects of 437 duplication. 439 9. Management Considerations 441 It is RECOMMENDED that OSPFv3 routers supporting this specification 442 also support explicit configuration of OSPFv3 parameters as specified 443 in Appendix C of [OSPFV3]. The would allow explicit override of 444 autoconfigured parameters in situations where it is required (e.g., 445 if the deployment requires multiple OSPFv3 areas). This is in 446 addition to the authentication key configuration recommended in 447 Section 4. Additionally, it is RECOMMENDED that OSPFv3 routers 448 supporting this specification allow autoconfiguration to be 449 completely disabled. 451 Since there is a small possibility of OSPFv3 Router ID collisions, 452 manual configuration of OSPFv3 Router IDs is RECOMMENDED in OSPFv3 453 routing domains where route recovergence due to a router ID change is 454 intolerable. 456 OSPFv3 Routers supporting this specification MUST augment mechanisms 457 for displaying or otherwise conveying OSPFv3 operational state to 458 indicate whether or not the OSPFv3 router was autoconfigured and 459 whether or not its OSPFv3 interfaces have been auto-configured. 461 10. IANA Considerations 463 This specification defines an OSPFv3 LSA Type for the OSPFv3 Auto- 464 Configuration (AC) LSA, as described in Section 7.2.1. The value TBD 465 will be allocated from the existing "OSPFv3 LSA Function Code" 466 registry for the OSPFv3 Auto-Configuration LSA. 468 This specification also creates a registry for OSPFv3 Auto- 469 Configuration (AC) LSA TLVs. This registry should be placed in the 470 existing OSPFv3 IANA registry, and new values can be allocated via 471 IETF Review or, under exceptional circumstances, IESG Approval. 472 [IANA-GUIDELINES] 474 Three initial values are allocated: 476 o 0 is marked as reserved. 478 o 1 is Router-Hardware-Fingerprint TLV (Section 7.2.2). 480 o 65535 is an Auto-configuration-Experiment-TLV, a common value that 481 can be used for experimental purposes. 483 11. Acknowledgments 485 This specification was inspired by the work presented in the Homenet 486 working group meeting in October 2011 in Philadelphia, Pennsylvania. 487 In particular, we would like to thank Fred Baker, Lorenzo Colitti, 488 Ole Troan, Mark Townsley, and Michael Richardson. 490 Arthur Dimitrelis and Aidan Williams did prior work in OSPFv3 auto- 491 configuration in the expired "Autoconfiguration of routers using a 492 link state routing protocol" IETF Draft. There are many similarities 493 between the concepts and techniques in this document. 495 Thanks for Abhay Roy and Manav Bhatia for comments regarding 496 duplicate router-id processing. 498 Thanks for Alvaro Retana and Michael Barnes for comments regarding 499 OSPFv3 Instance ID auto-configuration. 501 Thanks to Faraz Shamim for review and comments. 503 Thanks to Mark Smith for the requirement to reduce the adjacency 504 formation delay in the back-to-back ethernet topologies that are 505 prevalent in home networks. 507 Thanks to Les Ginsberg for document review and recommendations on 508 OSPFv3 hardware fingerprint content. 510 Thanks to Curtis Villamizar for document review and analysis of 511 duplicate router-id resolution nuances. 513 Thanks to Uma Chunduri for comments during OSPF WG last call. 515 Thanks to Martin Vigoureux for Routing Area Directorate review and 516 comments. 518 Thanks to Adam Montville for Security Area Directorate review and 519 comments. 521 Thanks to Qin Wu for Operations & Management Area Directorate review 522 and comments. 524 Thanks to Robert Sparks for General Area (GEN-ART) review and 525 comments. 527 Thanks to Rama Darbha for review and comments. 529 Special thanks to Adrian Farrel for his in-depth review, copious 530 comments, and suggested text. 532 Special thanks go to Markus Stenberg for his implementation of this 533 specification in Bird. 535 Special thanks also go to David Lamparter for his implementation of 536 this specification in Quagga. 538 The RFC text was produced using Marshall Rose's xml2rfc tool. 540 12. References 542 12.1. Normative References 544 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 546 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 547 for IPv6", RFC 5340, July 2008. 549 [OSPFV3-AF] 550 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 551 Aggarwal, "Support of Address Families in OSPFv3", RFC 552 5838, April 2010. 554 [OSPFV3-AUTH-TRAILER] 555 Bhatia, M., Manral, V., and A. Lindem, "Supporting 556 Authentication Trailer for OSPFv3", RFC 7166, February 557 2012. 559 [RFC-KEYWORDS] 560 Bradner, S., "Key words for use in RFCs to Indicate 561 Requirement Levels", RFC 2119, March 1997. 563 [SLAAC] Thomson, S., Narten, T., and J. Tatuya, "IPv6 Stateless 564 Address Autoconfiguration", RFC 4862, September 2007. 566 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 567 Extensions to OSPF", RFC 3630, September 2003. 569 12.2. Informative References 571 [ASYNC-HELLO] 572 Anand, M., Grover, H., and A. Roy, "Asymmetric OSPF Hold 573 Timer", draft-madhukar-ospf-agr-asymmetric-01.txt (work in 574 progress), June 2013. 576 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 577 Registration Authority", IEEE Tutorial 578 http://standards.ieee.org/regauth/oui/tutorials/ 579 EUI64.html, March 1997. 581 [IANA-GUIDELINES] 582 Narten, T. and H. Alvestrand, "Guidelines for Writing an 583 IANA Considerations Sectino in RFCs", RFC 5226, May 2008. 585 [IPv6-CPE] 586 Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 587 Requirements for IPv6 Customer Edge Routers", RFC 7084, 588 November 2013. 590 [OSPFV3-IPSEC] 591 Gupta, M. and S. Melam, "Authentication/Confidentiality 592 for OSPFv3", RFC 4552, June 2006. 594 Authors' Addresses 596 Acee Lindem 597 Cisco Systems 598 301 Midenhall Way 599 Cary, NC 27513 600 USA 602 Email: acee@cisco.com 604 Jari Arkko 605 Ericsson 606 Jorvas, 02420 607 Finland 609 Email: jari.arkko@piuha.net