idnits 2.17.1 draft-ietf-ospf-ospfv3-autoconfig-15.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 (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 10, 2015) is 3361 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 (==), 3 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 14, 2015 February 10, 2015 8 OSPFv3 Auto-Configuration 9 draft-ietf-ospf-ospfv3-autoconfig-15.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. 18 This document updates RFC 5340 by relaxing the HelloInterval/ 19 RouterDeadInterval checking during OSPFv3 adjacency formation and 20 adding hysteresis to the update of self-originated Link State 21 Advertisements (LSAs). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 14, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 59 2. OSPFv3 Default Configuration . . . . . . . . . . . . . . . . 3 60 3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . . 4 61 3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . 4 62 4. OSPFv3 Minimal Authentication Configuration . . . . . . . . . 5 63 5. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . 5 64 6. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . 5 65 7. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 6 66 7.1. Duplicate Router ID Detection for Neighbors . . . . . . . 6 67 7.2. Duplicate Router ID Detection for Non-Neighbors . . . . . 6 68 7.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . 7 69 7.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 8 70 7.3. Duplicate Router ID Resolution . . . . . . . . . . . . . 9 71 7.4. Change to RFC 2328 Section 13.4, 'Receiving Self- 72 Originated LSAs' . . . . . . . . . . . . . . . . . . . . 9 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 9. Management Considerations . . . . . . . . . . . . . . . . . . 10 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 79 12.2. Informative References . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 OSPFv3 [OSPFV3] is a candidate for deployments in environments where 85 auto-configuration is a requirement. This document describes 86 extensions to OSPFv3 to enable it to operate in these environments. 87 In this mode of operation, the protocol is largely unchanged from the 88 base OSPFv3 protocol specification [OSPFV3]. Since the goals of 89 auto-configuration and security can be conflicting, operators and 90 network administrators should carefully consider their security 91 requirements before deploying the solution described in this 92 document. Refer to Section 8 for more information. 94 The following aspects of OSPFv3 auto-configuration are described in 95 this document: 97 1. Default OSPFv3 Configuration 99 2. HelloInterval/RouterDeadInterval Flexibility 101 3. Unique OSPFv3 Router ID generation 103 4. OSPFv3 Adjacency Formation 105 5. Duplicate OSPFv3 Router ID Resolution 107 6. Self-Originated LSA Processing 109 OSPFv3 [OSPFV3] is updated by allowing OSPFv3 adjacencies to be 110 formed between OSPFv3 routers with differing HelloIntervals or 111 RouterDeadIntervals (refer to Section 3). Additionally, hysteresis 112 has been added to the processing of stale self-originated LSAs to 113 mitigate the flooding overhead created by an OSPFv3 Router with a 114 duplicate OSPFv3 Router ID in the OSPFv3 routing domain (refer to 115 Section 7.4. Both updates are fully backward compatible. 117 1.1. Requirements notation 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC-KEYWORDS]. 123 2. OSPFv3 Default Configuration 125 For complete auto-configuration, OSPFv3 will need to choose suitable 126 configuration defaults. These include: 128 1. Area 0 Only - All auto-configured OSPFv3 interfaces MUST be in 129 area 0. 131 2. OSPFv3 SHOULD be auto-configured on all IPv6-capable interface on 132 the router. An interface MAY be excluded if it is clear that 133 running OSPFv3 on the interface is not required. For example, if 134 manual configuration or another condition indicates that an 135 interface is connected to an Internet Service Provider (ISP), 136 there is typically no need to employ OSPFv3. In fact, [IPv6-CPE] 137 specifically requires that IPv6 Customer Premise Equipment (CPE) 138 routers do not initiate any dynamic routing protocol by default 139 on the router's WAN, i.e., ISP-facing, interface. In home 140 networking environments, an interface where no OSPFv3 neighbors 141 are found but a DHCP IPv6 prefix can be acquired may be 142 considered an ISP-facing interface and running OSPFv3 is 143 unnecessary. 145 3. OSPFv3 interfaces will be auto-configured to an interface type 146 corresponding to their layer-2 capability. For example, Ethernet 147 interfaces and Wi-Fi interfaces will be auto-configured as OSPFv3 148 broadcast networks and Point-to-Point Protocol (PPP) interfaces 149 will be auto-configured as OSPFv3 Point-to-Point interfaces. 150 Most extant OSPFv3 implementations do this already. Auto- 151 configured operation over wireless networks requiring a point-to- 152 multipoint (P2MP) topology and dynamic metrics based on wireless 153 feedback is not within the scope of this document. However, 154 auto-configuration is not precluded in these environments. 156 4. OSPFv3 interfaces MAY use an arbitrary HelloInterval and 157 RouterDeadInterval as specified in Section 3. Of course, an 158 identical HelloInterval and RouterDeadInterval will still be 159 required to form an adjacency with an OSPFv3 router not 160 supporting auto-configuration [OSPFV3]. 162 5. All OSPFv3 interfaces SHOULD be auto-configured to use an 163 Interface Instance ID of 0 that corresponds to the base IPv6 164 unicast address family instance ID as defined in [OSPFV3-AF]. 165 Similarly, if IPv4 unicast addresses are advertised in a separate 166 auto-configured OSPFv3 instance, the base IPv4 unicast address 167 family instance ID value, i.e., 64, SHOULD be auto-configured as 168 the Interface Instance ID for all interfaces corresponding to the 169 IPv4 unicast OSPFv3 instance [OSPFV3-AF]. 171 3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility 173 Auto-configured OSPFv3 routers will not require an identical 174 HelloInterval and RouterDeadInterval to form adjacencies. Rather, 175 the received HelloInterval will be ignored and the received 176 RouterDeadInterval will be used to determine OSPFv3 liveliness with 177 the sending router. In other words, the Neighbor Inactivity Timer 178 (Section 10 of [OSPFV2]) for each neighbor will reflect that 179 neighbor's advertised RouterDeadInterval and MAY be different from 180 other OSPFv3 routers on the link without impacting adjacency 181 formation. A similar mechanism requiring additional signaling is 182 proposed for all OSPFv2 and OSPFv3 routers [ASYNC-HELLO]. 184 3.1. Wait Timer Reduction 186 In many situations, auto-configured OSPFv3 routers will be deployed 187 in environments where back-to-back ethernet connections are utilized. 188 When this is the case, an OSPFv3 broadcast interface will not come up 189 until the other OSPFv3 router is connected and the routers will wait 190 RouterDeadInterval seconds before forming an adjacency [OSPFV2]. In 191 order to reduce this delay, an auto-configured OSPFv3 router MAY 192 reduce the wait interval to a value no less than (HelloInterval + 1). 194 Reducing the setting will slightly increase the likelihood of the 195 Designated Router (DR) flapping but is preferable to the long 196 adjacency formation delay. Note that this value is not included in 197 OSPFv3 Hello packets and does not impact interoperability. 199 4. OSPFv3 Minimal Authentication Configuration 201 In many deployments, the requirement for OSPFv3 authentication 202 overrides the goal of complete OSPFv3 autoconfiguration. Therefore, 203 it is RECOMMENDED that OSPFv3 routers supporting this specification 204 minimally offer an option to explicitly configure a single password 205 for HMAC-SHA authentication as described in [OSPFV3-AUTH-TRAILER]. 206 It is RECOMMENDED that the password entered as ASCII hexadecimal 207 digits and that 32 or more digits to facilitate a password with a 208 high degree of entropy. When configured, the password will be used 209 on all auto-configured interfaces with the Security Association 210 Identifier (SA ID) set to 1 and HMAC-SHA-256 used as the 211 authentication algorithm. 213 5. OSPFv3 Router ID Selection 215 An OSPFv3 router requires a unique Router ID within the OSPFv3 216 routing domain for correct protocol operation. Existing Router ID 217 selection algorithms (section C.1 in [OSPFV2] and [OSPFV3]) are not 218 viable since they are dependent on a unique IPv4 interface address 219 which is not likely to be available in autoconfigured deployments. 220 An OSPFv3 router implementing this specification will select a 221 router-id that has a high probability of uniqueness. A pseudo-random 222 number SHOULD be used for the OSPFv3 Router ID. The generation 223 SHOULD be seeded with a variable that is likely to be unique in the 224 applicable OSPFv3 router deployment. A good choice of seed would be 225 some portion or hash of the Router-Hardware-Fingerprint as described 226 in Section 7.2.2. 228 Since there is a possibility of a Router ID collision, duplicate 229 Router ID detection and resolution are required as described in 230 Section 7 and Section 7.3. OSPFv3 routers SHOULD maintain the last 231 successfully chosen Router ID in non-volatile storage to avoid 232 collisions subsequent to when an autoconfigured OSPFv3 router is 233 first added to the OSPFv3 routing domain. 235 6. OSPFv3 Adjacency Formation 237 Since OSPFv3 uses IPv6 link-local addresses for all protocol messages 238 other than messages sent on virtual links (which are not applicable 239 to auto-configuration), OSPFv3 adjacency formation can proceed as 240 soon as a Router ID has been selected and the IPv6 link-local address 241 has completed Duplicate Address Detection (DAD) as specified in IPv6 242 Stateless Address Autoconfiguration [SLAAC]. Otherwise, the only 243 changes to the OSPFv3 base specification are supporting 244 HelloInterval/RouterDeadInterval flexibility as described in 245 Section 3 and duplicate Router ID detection and resolution as 246 described in Section 7 and Section 7.3. 248 7. OSPFv3 Duplicate Router ID Detection and Resolution 250 There are two cases of duplicate OSPFv3 Router ID detection. One 251 where the OSPFv3 router with the duplicate Router ID is directly 252 connected and one where it is not. In both cases, the duplicate 253 resolution is for one of the routers to select a new OSPFv3 Router 254 ID. 256 7.1. Duplicate Router ID Detection for Neighbors 258 In this case, a duplicate Router ID is detected if any valid OSPFv3 259 packet is received with the same OSPFv3 Router ID but a different 260 IPv6 link-local source address. Once this occurs, the OSPFv3 router 261 with the numerically smaller IPv6 link-local address will need to 262 select a new Router ID as described in Section 7.3. Note that the 263 fact that the OSPFv3 router is a neighbor on a non-virtual interface 264 implies that the router is directly connected. An OSPFv3 router 265 implementing this specification should assure that the inadvertent 266 connection of multiple router interfaces to the same physical link is 267 not misconstrued as detection of an OSPFv3 neighbor with a duplicate 268 Router ID. 270 7.2. Duplicate Router ID Detection for Non-Neighbors 272 OSPFv3 routers implementing auto-configuration, as specified herein, 273 MUST originate an Auto-Configuration (AC) Link State Advertisement 274 (LSA) including the Router-Hardware-Fingerprint Type-Length-Value 275 (TLV). The Router-Hardware-Fingerprint TLV contains a variable 276 length value that has a very high probability of uniquely identifying 277 the advertising OSPFv3 router. An OSPFv3 router implementing this 278 specification MUST detect received Auto-Configuration LSAs with its 279 Router ID specified in the LSA header. LSAs received with the local 280 OSPFv3 Router's Router ID in the LSA header are perceived as self- 281 originated (see section 4.6 of [OSPFV3]). In these received Auto- 282 Configuration LSAs, the Router-Hardware-Fingerprint TLV is compared 283 against the OSPFv3 Router's own router hardware fingerprint. If the 284 fingerprints are not equal, there is a duplicate Router ID conflict 285 and the OSPFv3 router with the numerically smaller router hardware 286 fingerprint MUST select a new Router ID as described in Section 7.3. 288 This new LSA is designated for information related to OSPFv3 Auto- 289 configuration and, in the future, could be used for other auto- 290 configuration information, e.g., global IPv6 prefixes. However, this 291 is beyond the scope of this document. 293 7.2.1. OSPFv3 Router Auto-Configuration LSA 295 The OSPFv3 Auto-Configuration (AC) LSA has a function code of TBD and 296 the S2/S1 bits set to 01 indicating Area Flooding Scope. The U bit 297 will be set indicating that the OSPFv3 AC LSA should be flooded even 298 if it is not understood. The Link State ID (LSID) value will be a 299 integer index used to discriminate between multiple AC LSAs 300 originated by the same OSPFv3 router. This specification only 301 describes the contents of an AC LSA with a Link State ID (LSID) of 0. 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | LS age |1|0|1| TBD | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Link State ID | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Advertising Router | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | LS sequence number | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | LS checksum | Length | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | | 317 +- TLVs -+ 318 | ... | 320 OSPFv3 Auto-Configuration (AC) LSA 322 The format of the TLVs within the body of an AC LSA is the same as 323 the format used by the Traffic Engineering Extensions to OSPF [TE]. 324 The LSA payload consists of one or more nested Type/Length/Value 325 (TLV) triplets. The format of each TLV is: 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Type | Length | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Value... | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 TLV Format 337 The Length field defines the length of the value portion in octets 338 (thus a TLV with no value portion would have a length of 0). The TLV 339 is padded to 4-octet alignment; padding is not included in the length 340 field (so a 3-octet value would have a length of 3, but the total 341 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 342 aligned. For example, a 1-byte value would have the length field set 343 to 1, and 3 octets of padding would be added to the end of the value 344 portion of the TLV. Unrecognized types are ignored. 346 The new LSA is designated for information related to OSPFv3 Auto- 347 configuration and, in the future, can be used other auto- 348 configuration information. 350 7.2.2. Router-Hardware-Fingerprint TLV 352 The Router-Hardware-Fingerprint TLV is the first TLV defined for the 353 OSPFv3 Auto-Configuration (AC) LSA. It will have type 1 and MUST be 354 advertised in the LSID OSPFv3 AC LSA with an LSID of 0. It SHOULD 355 occur, at most, once and the first instance of the TLV will take 356 precedence over subsequent TLV instances. The length of the Router- 357 Hardware-Fingerprint is variable but must be 32 octets or greater. 358 If the Router-Hardware-Fingerprint TLV is not present as the first 359 TLV, the AC-LSA is considered malformed and is ignored for the 360 purposes of duplicate Router ID detection. Additionally, the event 361 SHOULD be logged. 363 The contents of the hardware fingerprint MUST have an extremely high 364 probability of uniqueness. It SHOULD be constructed from the 365 concatenation of a number of local values that themselves have a high 366 likelihood of uniqueness, such as MAC addresses, CPU ID, or serial 367 numbers. It is RECOMMENDED that one or more available universal 368 tokens (e.g., IEEE 802 48-bit MAC addresses or IEEE EUI-64 369 Identifiers [EUI64]) associated with the OSPFv3 router be included in 370 the hardware fingerprint. It MUST be based on hardware attributes 371 that will not change across hard and soft restarts. 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | 1 | >32 | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Router Hardware Fingerprint | 379 o 380 o 381 o 382 | | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Router-Hardware-Fingerprint TLV Format 387 7.3. Duplicate Router ID Resolution 389 The OSPFv3 router selected to resolve the duplicate OSPFv3 Router ID 390 condition must select a new OSPFv3 Router ID. The OSPFv3 router 391 SHOULD reduce the possibility of a subsequent Router ID collision by 392 checking the Link State Database for an OSPFv3 Auto-Configuration LSA 393 with the newly selected Router ID and a different Router-Hardware- 394 Fingerprint. If one is detected, a new Router ID should be selected 395 without going through the resolution process Section 7. After 396 selecting a new Router ID, all self-originated LSAs MUST be 397 reoriginated, and any OSPFv3 neighbor adjacencies MUST be 398 reestablished. The OSPFv3 router retaining the Router ID causing the 399 conflict will reoriginate or purge stale any LSAs as described in 400 Section 13.4 [OSPFV2]. 402 7.4. Change to RFC 2328 Section 13.4, 'Receiving Self-Originated LSAs' 404 RFC 2328 [OSPFV2], Section 13.4, describes the processing of received 405 self-originated LSAs. If the received LSA doesn't exist, the 406 receiving router will purge it from the OSPF routing domain. If the 407 LSA is newer than the version in the Link State Database (LSDB), the 408 receiving router will originate a newer version by advancing the LSA 409 sequence number and reoriginating. Since it is possible for an auto- 410 configured OSPFv3 router to choose a duplicate OSPFv3 Router ID, 411 OSPFv3 routers implementing this specification should detect when 412 multiple instances of the same self-originated LSA are purged or 413 reoriginated since this is indicative of an OSPFv3 router with a 414 duplicate Router ID in the OSPFv3 routing domain. When this 415 condition is detected, the OSPFv3 router SHOULD delay self-originated 416 LSA processing for LSAs that have recently been purged or 417 reoriginated. This specification recommends 10 seconds as the 418 interval defining recent self-originated LSA processing and an 419 exponential back off of 1 to 8 seconds for the processing delay. 421 This additional delay should allow for the mechanisms described in 422 Section 7 to resolve the duplicate OSPFv3 Router ID conflict. 424 Since this mechanism is useful in mitigating the flooding overhead 425 associated with the inadvertent or malicious introduction of an 426 OSPFv3 router with a duplicate Router ID into an OSPFv3 routing 427 domain, it MAY be deployed outside of autoconfigured deployments. 428 The detection of a self-originated LSA that is being repeated 429 reoriginated or purged SHOULD be logged. 431 8. Security Considerations 433 A unique OSPFv3 Interface Instance ID is used for auto-configuration 434 to prevent inadvertent OSPFv3 adjacency formation, see Section 2 436 The goals of security and complete OSPFv3 auto-configuration are 437 somewhat contradictory. When no explicit security configuration 438 takes place, auto-configuration implies that additional devices 439 placed in the network are automatically adopted as a part of the 440 network. However, auto-configuration can also be combined with 441 password configuration (see Section 4) or future extensions for 442 automatic pairing between devices. These mechanisms can help provide 443 an automatically configured, securely routed network. 445 In deployments where different authentication algorithm, per- 446 interface keys, or encryption is required, OSPFv3 IPsec 447 [OSPFV3-IPSEC] or alternate OSPFv3 Authentication trailer 448 [OSPFV3-AUTH-TRAILER] algorithms MAY be used at the expense of 449 additional configuration. The configuration and operational 450 description of such deployments is beyond the scope of this document. 451 However, a deployment could always revert to explicit configuration 452 as described in Section 9 for features such as IPsec, per-interface 453 keys, or alternate authentication algorithms. 455 The introduction, either malicious or accidental, of an OSPFv3 router 456 with a duplicate Router ID is an attack point for OSPFv3 routing 457 domains. This is due to the fact that OSPFv3 routers will interpret 458 LSAs advertised by the router with the same Router ID as self- 459 originated LSAs and attempt to purge them from the routing domain. 460 The mechanisms in Section 7.4 will mitigate the effects of 461 duplication. 463 9. Management Considerations 465 It is RECOMMENDED that OSPFv3 routers supporting this specification 466 also support 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. Additionally, it is RECOMMENDED that OSPFv3 routers 472 supporting this specification allow autoconfiguration to be 473 completely disabled. 475 Since there is a small possibility of OSPFv3 Router ID collisions, 476 manual configuration of OSPFv3 Router IDs is RECOMMENDED in OSPFv3 477 routing domains where route convergence due to a router ID change is 478 intolerable. 480 OSPFv3 Routers supporting this specification MUST augment mechanisms 481 for displaying or otherwise conveying OSPFv3 operational state to 482 indicate whether or not the OSPFv3 router was autoconfigured and 483 whether or not its OSPFv3 interfaces have been auto-configured. 485 10. IANA Considerations 487 This specification defines an OSPFv3 LSA Type for the OSPFv3 Auto- 488 Configuration (AC) LSA, as described in Section 7.2.1. The value TBD 489 will be allocated from the existing "OSPFv3 LSA Function Code" 490 registry for the OSPFv3 Auto-Configuration LSA. 492 This specification also creates a registry for OSPFv3 Auto- 493 Configuration (AC) LSA TLVs. This registry should be placed in the 494 existing OSPFv3 IANA registry, and new values can be allocated via 495 IETF Review or, under exceptional circumstances, IESG Approval. 496 [IANA-GUIDELINES] 498 Three initial values are allocated: 500 o 0 is marked as reserved. 502 o 1 is Router-Hardware-Fingerprint TLV (Section 7.2.2). 504 o 65535 is an Auto-configuration-Experiment-TLV, a common value that 505 can be used for experimental purposes. 507 11. Acknowledgments 509 This specification was inspired by the work presented in the Homenet 510 working group meeting in October 2011 in Philadelphia, Pennsylvania. 511 In particular, we would like to thank Fred Baker, Lorenzo Colitti, 512 Ole Troan, Mark Townsley, and Michael Richardson. 514 Arthur Dimitrelis and Aidan Williams did prior work in OSPFv3 auto- 515 configuration in the expired "Autoconfiguration of routers using a 516 link state routing protocol" IETF Draft. There are many similarities 517 between the concepts and techniques in this document. 519 Thanks for Abhay Roy and Manav Bhatia for comments regarding 520 duplicate router-id processing. 522 Thanks for Alvaro Retana and Michael Barnes for comments regarding 523 OSPFv3 Instance ID auto-configuration. 525 Thanks to Faraz Shamim for review and comments. 527 Thanks to Mark Smith for the requirement to reduce the adjacency 528 formation delay in the back-to-back ethernet topologies that are 529 prevalent in home networks. 531 Thanks to Les Ginsberg for document review and recommendations on 532 OSPFv3 hardware fingerprint content. 534 Thanks to Curtis Villamizar for document review and analysis of 535 duplicate router-id resolution nuances. 537 Thanks to Uma Chunduri for comments during OSPF WG last call. 539 Thanks to Martin Vigoureux for Routing Area Directorate review and 540 comments. 542 Thanks to Adam Montville for Security Area Directorate review and 543 comments. 545 Thanks to Qin Wu for Operations & Management Area Directorate review 546 and comments. 548 Thanks to Robert Sparks for General Area (GEN-ART) review and 549 comments. 551 Thanks to Rama Darbha for review and comments. 553 Special thanks to Adrian Farrel for his in-depth review, copious 554 comments, and suggested text. 556 Special thanks go to Markus Stenberg for his implementation of this 557 specification in Bird. 559 Special thanks also go to David Lamparter for his implementation of 560 this specification in Quagga. 562 The RFC text was produced using Marshall Rose's xml2rfc tool. 564 12. References 566 12.1. Normative References 568 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 570 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 571 for IPv6", RFC 5340, July 2008. 573 [OSPFV3-AF] 574 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 575 Aggarwal, "Support of Address Families in OSPFv3", RFC 576 5838, April 2010. 578 [OSPFV3-AUTH-TRAILER] 579 Bhatia, M., Manral, V., and A. Lindem, "Supporting 580 Authentication Trailer for OSPFv3", RFC 7166, February 581 2012. 583 [RFC-KEYWORDS] 584 Bradner, S., "Key words for use in RFCs to Indicate 585 Requirement Levels", RFC 2119, March 1997. 587 [SLAAC] Thomson, S., Narten, T., and J. Tatuya, "IPv6 Stateless 588 Address Autoconfiguration", RFC 4862, September 2007. 590 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 591 Extensions to OSPF", RFC 3630, September 2003. 593 12.2. Informative References 595 [ASYNC-HELLO] 596 Anand, M., Grover, H., and A. Roy, "Asymmetric OSPF Hold 597 Timer", draft-madhukar-ospf-agr-asymmetric-01.txt (work in 598 progress), June 2013. 600 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 601 Registration Authority", IEEE Tutorial 602 http://standards.ieee.org/regauth/oui/tutorials/ 603 EUI64.html, March 1997. 605 [IANA-GUIDELINES] 606 Narten, T. and H. Alvestrand, "Guidelines for Writing an 607 IANA Considerations Sectino in RFCs", RFC 5226, May 2008. 609 [IPv6-CPE] 610 Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 611 Requirements for IPv6 Customer Edge Routers", RFC 7084, 612 November 2013. 614 [OSPFV3-IPSEC] 615 Gupta, M. and S. Melam, "Authentication/Confidentiality 616 for OSPFv3", RFC 4552, June 2006. 618 Authors' Addresses 620 Acee Lindem 621 Cisco Systems 622 301 Midenhall Way 623 Cary, NC 27513 624 USA 626 Email: acee@cisco.com 628 Jari Arkko 629 Ericsson 630 Jorvas, 02420 631 Finland 633 Email: jari.arkko@piuha.net