idnits 2.17.1 draft-ietf-ospf-ospfv3-autoconfig-00.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 5, 2012) is 4221 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 normative reference: RFC 6506 (ref. 'OSPFV3-AUTH-TRAILER') (Obsoleted by RFC 7166) Summary: 1 error (**), 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 J. Arkko 4 Intended status: Standards Track Ericsson 5 Expires: April 8, 2013 October 5, 2012 7 OSPFv3 Auto-Configuration 8 draft-ietf-ospf-ospfv3-autoconfig-00.txt 10 Abstract 12 OSPFv3 is a candidate for deployments in environments where auto- 13 configuration is a requirement. One such environment is the IPv6 14 home network where users expect to simply plug in a router and have 15 it automatically use OSPFv3 for intra-domain routing. This document 16 describes the necessary mechanisms for OSPFv3 to be self-configuring. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 8, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 66 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 3 67 2. OSPFv3 Default Configuration . . . . . . . . . . . . . . . . . 4 68 2.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . . 4 69 3. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . . 6 70 4. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . . 7 71 5. OSPFv3 Duplicate Router-ID Detection and Resolution . . . . . 8 72 5.1. Duplicate Router-ID Detection for Neighbors . . . . . . . 8 73 5.2. Duplicate Router-ID Detection for OSPFv3 Routers that 74 are not Neighbors . . . . . . . . . . . . . . . . . . . . 8 75 5.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . . 8 76 5.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 10 77 5.3. Duplicate Router-ID Resolution . . . . . . . . . . . . . . 10 78 5.4. Change to Received Self-Originated LSA Processing . . . . 11 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 7. Management Considerations . . . . . . . . . . . . . . . . . . 13 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 OSPFv3 [OSPFV3] is a candidate for deployments in environments where 90 auto-configuration is a requirement. Its operation is largely 91 unchanged from the base OSPFv3 protocol specification [OSPFV3]. 93 The following aspects of OSPFv3 auto-configuration are described: 95 1. Default OSPFv3 Configuration 97 2. Unique OSPFv3 Router-ID generation 99 3. OSPFv3 Adjacency Formation 101 4. Duplicate OSPFv3 Router-ID Resolution 103 1.1. Requirements notation 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC-KEYWORDS]. 109 1.2. Acknowledgments 111 This specification was inspired by the work presented in the Homenet 112 working group meeting in October 2011 in Philadelphia, Pennsylvania. 113 In particular, we would like to thank Fred Baker, Lorenzo Colitti, 114 Ole Troan, Mark Townsley, and Michael Richardson. 116 Arthur Dimitrelis and Aidan Williams did prior work in OSPFv3 auto- 117 configuration in the expired "Autoconfiguration of routers using a 118 link state routing protocol" IETF Draft. There are many similarities 119 between the concepts and techniques in this document. 121 Thanks for Abhay Roy and Manav Bhatia for comments regarding 122 duplicate router-id processing. 124 Thanks for Alvaro Retana and Michael Barnes for comments regarding 125 OSPFv3 Instance ID auto-configuration. 127 Thanks to Faraz Shamim for review and comments. 129 Thanks to Mark Smith for the requirement to reduce the adjacency 130 formation delay in the back-to-back ethernet topologies that are 131 prevalent in home networks. 133 The RFC text was produced using Marshall Rose's xml2rfc tool. 135 2. OSPFv3 Default Configuration 137 For complete auto-configuration, OSPFv3 will need to choose suitable 138 configuration defaults. These include: 140 1. Area 0 Only - All auto-configured OSPFv3 interfaces MUST be in 141 area 0. 143 2. OSPFv3 SHOULD be auto-configured on for IPv6 on all interfaces 144 intended as general IPv6-capable routers. Optionally, an 145 interface MAY be excluded if it is clear that running OSPFv3 on 146 the interface is not required. For example, if manual 147 configuration or an other condition indicates that an interface 148 is connected to an Internet Service Provider (ISP) and there is 149 no Border Gateway Protocol (BGP) [BGP] peering, there is 150 typically no need to employ OSPFv3. However, note that in many 151 environments it can be useful to test whether an OSPFv3 adjacency 152 can be established. In home networking environments, an 153 interface where no OSPFv3 neighbors are found but a DHCP prefix 154 can be acquired may be considered as an ISP interface. 156 3. OSPFv3 interfaces will be auto-configured to an interface type 157 corresponding to their layer-2 capability. For example, Ethernet 158 interfaces will be auto-configured as broadcast networks and 159 Point-to-Point Protocol (PPP) interfaces will be auto-configured 160 as Point-to-Point interfaces. Most extant OSPFv3 implementations 161 do this already. 163 4. OSPFv3 interfaces MUST use the default HelloInterval, 10 seconds, 164 and RouterDeadInterval, 40 seconds, as suggested in Appendix C of 165 [OSPFV3]. 167 5. All OSPFv3 interfaces SHOULD be auto-configured to use an 168 Interface Instance ID of 0 that corresponds to the base IPv6 169 unicast address family instance ID as defined in [OSPFV3-AF]. 170 Similarly, if IPv4 unicast addresses are advertised in a separate 171 auto-configured OSPFv3 instance, the base IPv4 unicast address 172 family instance ID value, i.e., 64, SHOULD be auto-configured as 173 the Interface Instance ID for all interfaces corresponding to the 174 OSPFv3 instance [OSPFV3-AF]. 176 2.1. Wait Timer Reduction 178 In many situations, auto-configured OSPFv3 routers will be deployed 179 in environments where back-to-back ethernet connections are utilized. 180 When this is the case, an OSPFv3 broadcast interface will not come up 181 until the other OSPFv3 router is connected and the routers will wait 182 RouterDeadInterval seconds before forming an adjacency [OSPFV2]. In 183 order to reduce this delay, an auto-configured OSPFv3 router MAY 184 reduce the wait interval to a value no less than (HelloInterval + 1), 185 i.e., 11 seconds. Reducing the setting will slightly increase the 186 likelihood of the Designated Router (DR) flapping but is preferable 187 to the long adjacency formation delay. Note that this value is not 188 included in OSPFv3 Hello packets and does not impact 189 interoperability. 191 3. OSPFv3 Router ID Selection 193 As OSPFv3 Router implementing this specification must select a unique 194 Router-ID. A pseudo-random number SHOULD be used for the OSPFv3 195 Router-ID. The generation should be seeded with a variable that is 196 likely to be unique in that environment. A good choice of seed would 197 be some portion or hash of the Route-Hardware-Fingerprint as 198 described in Section 5.2.2. 200 Since there is a possibility of a Router ID collision, duplicate 201 Router ID detection and resolution are required as described in 202 Section 5 and Section 5.3. 204 4. OSPFv3 Adjacency Formation 206 Since OSPFv3 uses IPv6 link-local addresses for all protocol messages 207 other than message sent on virtual links (which are not applicable to 208 auto-configuration), OSPFv3 adjacency formation can proceed as soon 209 as a Router-ID has been selected and the IPv6 link-local address has 210 completed Duplicate Address Detection (DAD) as specified in IPv6 211 Stateless Address Autoconfiguration [SLAAC]. Otherwise, there is no 212 change to the OSPFv3 base specification except with respect to 213 duplicate Router-ID detection and resolution as described in 214 Section 5 and Section 5.3. 216 5. OSPFv3 Duplicate Router-ID Detection and Resolution 218 There are two cases of duplicate OSPFv3 Router-ID detection. One 219 where the OSPFv3 router with the duplicate Router-ID is directly 220 connected and one where it is not. In both cases, the resolution is 221 for one of the routers with the duplicate OSPFv3 Router-ID to select 222 a new one. 224 5.1. Duplicate Router-ID Detection for Neighbors 226 In this case, a duplicate Router-ID is detected if any valid OSPFv3 227 packet is received with the same OSPFv3 Router-ID but a different 228 IPv6 link-local source address. Once that occurs, the OSPFv3 router 229 with the numerically smaller IPv6 link-local address will need to 230 select a new Router-ID as described in Section 5.3. Note that the 231 fact that the OSPFv3 router is a neighbor on a non-virtual interface 232 implies that the router is directly connected. An OSPFv3 router 233 implementing this specification should assure that the inadvertent 234 connection of multiple router interfaces to the same physical link in 235 not misconstrued as detection of a different OSPFv3 router with a 236 duplicate Router-ID. 238 5.2. Duplicate Router-ID Detection for OSPFv3 Routers that are not 239 Neighbors 241 OSPFv3 Routers implementing auto-configuration, as specified herein, 242 MUST originate an Auto-Config (AC) Link State Advertisement (LSA) 243 including the Router-Hardware-Fingerprint Type-Length-Value (TLV). 244 The Router-Hardware-Fingerprint TLV contains a variable length value 245 that has a very high probability of uniquely identifying the 246 advertising OSPFv3 router. An OSPFv3 router implementing this 247 specification MUST compare a received self-originated Auto-Config 248 LSA's Router-Hardware-Fingerprint TLV against its own router hardware 249 fingerprint. If the fingerprints are not equal, there is a Router-ID 250 conflict and the OSPFv3 Router with the numerically smaller router 251 hardware fingerprint MUST select a new Router-ID as described in 252 Section 5.3. 254 This new LSA is designated for information related to OSPFv3 Auto- 255 configuration and, in the future, could be used other auto- 256 configuration information, e.g., global IPv6 prefixes. However, this 257 is beyond the scope of this document. 259 5.2.1. OSPFv3 Router Auto-Configuration LSA 261 The OSPFv3 Auto-Configuration (AC) LSA has a function code of TBD and 262 the S2/S1 bits set to 01 indicating Area Flooding Scope. The U bit 263 will be set indicating that the OSPFv3 AC LSA should be flooded even 264 if it is not understood. The Link State ID (LSID) value will be a 265 integer index used to discriminate between multiple AC LSAs 266 originated by the same OSPF Router. This specification only 267 describes the contents of an AC LSA with a Link State ID (LSID) of 0. 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | LS age |1|0|1| TBD | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Link State ID | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Advertising Router | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | LS sequence number | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | LS checksum | Length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 +- TLVs -+ 284 | ... | 286 OSPFv3 Auto-Configuration (AC) LSA 288 The format of the TLVs within the body of an AC LSA is the same as 289 the format used by the Traffic Engineering Extensions to OSPF [TE]. 290 The LSA payload consists of one or more nested Type/Length/Value 291 (TLV) triplets. The format of each TLV is: 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Type | Length | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Value... | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 TLV Format 303 The Length field defines the length of the value portion in octets 304 (thus a TLV with no value portion would have a length of 0). The TLV 305 is padded to 4-octet alignment; padding is not included in the length 306 field (so a 3-octet value would have a length of 3, but the total 307 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 308 aligned. For example, a 1-byte value would have the length field set 309 to 1, and 3 octets of padding would be added to the end of the value 310 portion of the TLV. Unrecognized types are ignored. 312 The new LSA is designated for information related to OSPFv3 Auto- 313 configuration and, in the future, can be used other auto- 314 configuration information, e.g., global IPv6 prefixes. 316 5.2.2. Router-Hardware-Fingerprint TLV 318 The Router-Hardware-Fingerprint TLV is the first TLV defined for the 319 OSPFv3 Auto-Configuration (AC) LSA. It will have type 1 and MUST be 320 advertised in the LSID OSPFv3 AC LSA with an LSID of 0. It SHOULD 321 occur, at most, once and the first instance of the TLV will take 322 precedence over preceding TLV instances. The length of the Router- 323 Hardware-Fingerprint is variable but must be 32 bytes or greater. 325 The contents of the hardware fingerprint should be some combination 326 of MAC addresses, CPU ID, or serial number(s) that provides an 327 extremely high probability of uniqueness. It MUST be based on 328 hardware attributes that will not change across hard and soft 329 restarts. 331 0 1 2 3 332 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | 1 | >32 | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Router Hardware Fingerprint | 337 o 338 o 339 o 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Router-Hardware-Fingerprint TLV Format 345 5.3. Duplicate Router-ID Resolution 347 The OSPFv3 Router selected to resolve the duplicate OSPFv3 Router-ID 348 condition must select a new OSPFv3 Router-ID. After selecting a new 349 Router-ID, the Router-LSA with the prior duplicate Router-ID MUST be 350 purged. all self-originated LSAs MUST be reoriginated, and any OSPFv3 351 neighbor adjacencies MUST be reestablished. 353 5.4. Change to Received Self-Originated LSA Processing 355 RFC 2328 [OSPFV2], Section 13.4, describes the processing of received 356 self-originated LSAs. If the received LSA doesn't exist, the 357 receiving router will purge it from the OSPF routing domain. If the 358 LSA is newer than the version in the Link State Database (LSDB), the 359 receiving router will originate a newer version by advancing the LSA 360 sequence number and reflooding. Since it is possible for an auto- 361 configured OSPFv3 router to choose a duplicate OSPFv3 Router-ID, 362 OSPFv3 routers implementing this specification should detect when 363 multiple instances of the same self-originated LSA are purged or 364 reoriginated since this is indicative of an OSPFv3 router with a 365 duplicate Router-ID in the OSPFv3 routing domain. When this 366 condition is detected, the OSPFv3 Router SHOULD delay self-originated 367 LSA processing for LSAs that have recently been purged or reflooded. 368 This specification recommends 10 seconds as the interval defining 369 recent self-originated LSA processing and an exponential back off of 370 1 to 8 seconds for the processing delay. 372 6. Security Considerations 374 A unique OSPFv3 Interface Instance ID is used for auto-configuration 375 to prevent inadvertent OSPFv3 adjacency formation, see Section 2 377 The goals of security and complete OSPFv3 auto-configuration are 378 somewhat contradictory. When no explicit security configuration 379 takes place, auto-configuration implies that additional devices 380 placed in the network are automatically adopted as a part of the 381 network. However, auto-configuration can also be combined with 382 password configuration (see below) or future extensions for automatic 383 pairing between devices. These mechanisms can help provide an 384 automatically configured, securely routed network. 386 It is RECOMMENDED that OSPFv3 routers supporting this specification 387 also offer an option to explicitly configure a password for HMAC- SHA 388 authentication as described in [OSPFV3-AUTH-TRAILER]. When 389 configured, the password will be used on all auto-configured 390 interfaces with the Security Association Identifier (SA ID) set to 1 391 and HMAC-SHA-256 will be used as the authentication algorithm. 393 7. Management Considerations 395 It is RECOMMENDED that OSPFv3 routers supporting this specification 396 also allow explicit configuration of OSPFv3 parameters as specified 397 in Appendix C of [OSPFV3]. This is in addition to the authentication 398 key configuration recommended in Section 6. However, it is 399 acknowledged that there may be some deployment scenarios where manual 400 configuration is not required. 402 8. IANA Considerations 404 This specification allocates a new OSPFv3 LSA, OSPFv3 Auto- 405 Configuration (AC) LSA, TBD, as described in Section 5.2.1. 407 This specification also creates a registry for OSPFv3 Auto- 408 Configuration (AC) LSA TLVs. This registry should be placed in the 409 existing OSPFv3 IANA registry, and new values can be allocated via 410 IETF Consensus or IESG Approval. 412 Three initial values are allocated: 414 o 0 is marked as reserved. 416 o 1 is Router-Hardware-Fingerprint TLV (Section 5.2.2). 418 o 65535 is an Auto-configuration-Experiment-TLV, a common value that 419 can be used for experimental purposes. 421 9. References 423 9.1. Normative References 425 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 427 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 428 for IPv6", RFC 5340, July 2008. 430 [OSPFV3-AF] 431 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 432 Aggarwal, "Support of Address Families in OSPFv3", 433 RFC 5838, April 2010. 435 [OSPFV3-AUTH-TRAILER] 436 Bhatia, M., Manral, V., and A. Lindem, "Supporting 437 Authentication Trailer for OSPFv3", RFC 6506, 438 February 2012. 440 [RFC-KEYWORDS] 441 Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", RFC 2119, March 1997. 444 [SLAAC] Thomson, S., Narten, T., and J. Tatuya, "IPv6 Stateless 445 Address Autoconfiguration", RFC 4862, September 2007. 447 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 448 Extensions to OSPF", RFC 3630, September 2003. 450 9.2. Informative References 452 [BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 453 Protocol 4 (BGP-4)", RFC 4271, January 2006. 455 Authors' Addresses 457 Acee Lindem 458 Ericsson 459 102 Carric Bend Court 460 Cary, NC 27519 461 USA 463 Email: acee.lindem@ericsson.com 465 Jari Arkko 466 Ericsson 467 Jorvas, 02420 468 Finland 470 Email: jari.arkko@piuha.net