idnits 2.17.00 (12 Aug 2021) /tmp/idnits35331/draft-ietf-ospf-ospfv3-autoconfig-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2014) is 2811 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 Cisco Systems 4 Intended status: Standards Track J. Arkko 5 Expires: March 13, 2015 Ericsson 6 September 9, 2014 8 OSPFv3 Auto-Configuration 9 draft-ietf-ospf-ospfv3-autoconfig-09.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 March 13, 2015. 36 Copyright Notice 38 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 55 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 3 56 2. OSPFv3 Default Configuration . . . . . . . . . . . . . . . . . 5 57 3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . . 7 58 3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . . 7 59 4. OSPFv3 Minimal Authentication Configuration . . . . . . . . . 8 60 5. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . . 9 61 6. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . . 10 62 7. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 11 63 7.1. Duplicate Router ID Detection for Neighbors . . . . . . . 11 64 7.2. Duplicate Router ID Detection for OSPFv3 Routers that 65 are not Neighbors . . . . . . . . . . . . . . . . . . . . 11 66 7.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . . 11 67 7.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 13 68 7.3. Duplicate Router ID Resolution . . . . . . . . . . . . . . 14 69 7.4. Change to RFC 2328 Section 13.4, 'Receiving 70 Self-Originated LSA' Processing . . . . . . . . . . . . . 14 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 72 9. Management Considerations . . . . . . . . . . . . . . . . . . 16 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 76 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 79 1. Introduction 81 OSPFv3 [OSPFV3] is a candidate for deployments in environments where 82 auto-configuration is a requirement. Its operation is largely 83 unchanged from the base OSPFv3 protocol specification [OSPFV3]. 85 The following aspects of OSPFv3 auto-configuration are described: 87 1. Default OSPFv3 Configuration 89 2. HelloInterval/RouterDeadInterval Flexibility 91 3. Unique OSPFv3 Router-ID generation 93 4. OSPFv3 Adjacency Formation 95 5. Duplicate OSPFv3 Router-ID Resolution 97 1.1. Requirements notation 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC-KEYWORDS]. 103 1.2. Acknowledgments 105 This specification was inspired by the work presented in the Homenet 106 working group meeting in October 2011 in Philadelphia, Pennsylvania. 107 In particular, we would like to thank Fred Baker, Lorenzo Colitti, 108 Ole Troan, Mark Townsley, and Michael Richardson. 110 Arthur Dimitrelis and Aidan Williams did prior work in OSPFv3 auto- 111 configuration in the expired "Autoconfiguration of routers using a 112 link state routing protocol" IETF Draft. There are many similarities 113 between the concepts and techniques in this document. 115 Thanks for Abhay Roy and Manav Bhatia for comments regarding 116 duplicate router-id processing. 118 Thanks for Alvaro Retana and Michael Barnes for comments regarding 119 OSPFv3 Instance ID auto-configuration. 121 Thanks to Faraz Shamim for review and comments. 123 Thanks to Mark Smith for the requirement to reduce the adjacency 124 formation delay in the back-to-back ethernet topologies that are 125 prevalent in home networks. 127 Thanks to Les Ginsberg for document review and recommendations on 128 OSPFv3 hardware fingerprint content. 130 Thanks to Curtis Villamizar for document review and analysis of 131 duplicate router-id resolution nuances. 133 Thanks to Uma Chunduri for comments during OSPF WG last call. 135 Special thanks go to Markus Stenberg for his implementation of this 136 specification in Bird. 138 Special thanks also go to David Lamparter for his implementation of 139 this specification in Quagga. 141 The RFC text was produced using Marshall Rose's xml2rfc tool. 143 2. OSPFv3 Default Configuration 145 For complete auto-configuration, OSPFv3 will need to choose suitable 146 configuration defaults. These include: 148 1. Area 0 Only - All auto-configured OSPFv3 interfaces MUST be in 149 area 0. 151 2. OSPFv3 SHOULD be auto-configured on for IPv6 on all interfaces 152 intended as general IPv6-capable routers. Optionally, an 153 interface MAY be excluded if it is clear that running OSPFv3 on 154 the interface is not required. For example, if manual 155 configuration or another condition indicates that an interface is 156 connected to an Internet Service Provider (ISP) and there is no 157 Border Gateway Protocol (BGP) [BGP] peering, there is typically 158 no need to employ OSPFv3. In fact, [IPv6-CPE] specifically 159 requires that IPv6 Customer Premise Equipment (CPE) routers do 160 not initiate any dynamic routing protocol by default on the 161 router's WAN, i.e., ISP-facing, interface. In home networking 162 environments, an interface where no OSPFv3 neighbors are found 163 but a DHCP IPv6 prefix can be acquired may be considered an ISP- 164 facing interface and running OSPFv3 is unnecessary. 166 3. OSPFv3 interfaces will be auto-configured to an interface type 167 corresponding to their layer-2 capability. For example, Ethernet 168 interfaces and vanilla Wi-Fi interfaces will be auto-configured 169 as OSPFv3 broadcast networks and Point-to-Point Protocol (PPP) 170 interfaces will be auto-configured as OSPFv3 Point-to-Point 171 interfaces. Most extant OSPFv3 implementations do this already. 172 Auto-configured operation over wireless networks requiring a 173 point-to-multipoint (P2MP) topology and dynamic metrics based on 174 wireless feedback is not within the scope of this document. 175 However, auto-configuration is not precluded in these 176 environments. 178 4. OSPFv3 interfaces MAY use an arbitrary HelloInterval and 179 RouterDeadInterval as specified in Section 3. Of course, an 180 identical HelloInterval and RouterDeadInterval will still be 181 required to form an adjacency with an OSPFv3 router not 182 supporting auto-configuration [OSPFV3]. 184 5. All OSPFv3 interfaces SHOULD be auto-configured to use an 185 Interface Instance ID of 0 that corresponds to the base IPv6 186 unicast address family instance ID as defined in [OSPFV3-AF]. 187 Similarly, if IPv4 unicast addresses are advertised in a separate 188 auto-configured OSPFv3 instance, the base IPv4 unicast address 189 family instance ID value, i.e., 64, SHOULD be auto-configured as 190 the Interface Instance ID for all interfaces corresponding to the 191 IPv4 unicast OSPFv3 instance [OSPFV3-AF]. 193 3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility 195 Auto-configured OSPFv3 routers will not require an identical 196 HelloInterval and RouterDeadInterval to form adjacencies. Rather, 197 the received HelloInterval will be ignored and the received 198 RouterDeadInterval will be used to determine OSPFv3 liveliness with 199 the sending router. In other words, the Neighbor Inactivity Timer 200 (Section 10 of [OSPFV2]) for each neighbor will reflect that 201 neighbor's advertised RouterDeadInterval and MAY be different from 202 other OSPFv3 routers on the link without impacting adjacency 203 formation. A similar mechanism requiring additional signaling is 204 proposed for all OSPFv2 and OSPFv3 routers [ASYNC-HELLO]. 206 3.1. Wait Timer Reduction 208 In many situations, auto-configured OSPFv3 routers will be deployed 209 in environments where back-to-back ethernet connections are utilized. 210 When this is the case, an OSPFv3 broadcast interface will not come up 211 until the other OSPFv3 router is connected and the routers will wait 212 RouterDeadInterval seconds before forming an adjacency [OSPFV2]. In 213 order to reduce this delay, an auto-configured OSPFv3 router MAY 214 reduce the wait interval to a value no less than (HelloInterval + 1). 215 Reducing the setting will slightly increase the likelihood of the 216 Designated Router (DR) flapping but is preferable to the long 217 adjacency formation delay. Note that this value is not included in 218 OSPFv3 Hello packets and does not impact interoperability. 220 4. OSPFv3 Minimal Authentication Configuration 222 In many deployments, the requirement for OSPFv3 authentication 223 overrides the goal of complete OSPFv3 autoconfiguration. Therefore, 224 it is RECOMMENDED that OSPFv3 routers supporting this specification 225 minimally offer an option to explicitly configure a single password 226 for HMAC-SHA authentication as described in [OSPFV3-AUTH-TRAILER]. 227 When configured, the password will be used on all auto-configured 228 interfaces with the Security Association Identifier (SA ID) set to 1 229 and HMAC-SHA-256 used as the authentication algorithm. 231 5. OSPFv3 Router ID Selection 233 As OSPFv3 Router implementing this specification must select a unique 234 Router ID. A pseudo-random number SHOULD be used for the OSPFv3 235 Router ID. The generation should be seeded with a variable that is 236 likely to be unique in the applicable OSPFv3 router deployment. A 237 good choice of seed would be some portion or hash of the Router- 238 Hardware-Fingerprint as described in Section 7.2.2. 240 Since there is a possibility of a Router ID collision, duplicate 241 Router ID detection and resolution are required as described in 242 Section 7 and Section 7.3. OSPFv3 Routers SHOULD maintain the last 243 successfully chosen Router ID in non-volatile storage to avoid 244 collisions subsequent to when an autoconfigured OSPFv3 router is 245 first added to the OSPFv3 routing domain. 247 6. OSPFv3 Adjacency Formation 249 Since OSPFv3 uses IPv6 link-local addresses for all protocol messages 250 other than messages sent on virtual links (which are not applicable 251 to auto-configuration), OSPFv3 adjacency formation can proceed as 252 soon as a Router ID has been selected and the IPv6 link-local address 253 has completed Duplicate Address Detection (DAD) as specified in IPv6 254 Stateless Address Autoconfiguration [SLAAC]. Otherwise, the only 255 changes to the OSPFv3 base specification are supporting 256 HelloInterval/RouterDeadInterval flexibility as described in 257 Section 3 and duplicate Router ID detection and resolution as 258 described in Section 7 and Section 7.3. 260 7. OSPFv3 Duplicate Router ID Detection and Resolution 262 There are two cases of duplicate OSPFv3 Router ID detection. One 263 where the OSPFv3 router with the duplicate Router ID is directly 264 connected and one where it is not. In both cases, the duplicate 265 resolution is for one of the routers to select a new OSPFv3 Router 266 ID. 268 7.1. Duplicate Router ID Detection for Neighbors 270 In this case, a duplicate Router ID is detected if any valid OSPFv3 271 packet is received with the same OSPFv3 Router ID but a different 272 IPv6 link-local source address. Once this occurs, the OSPFv3 router 273 with the numerically smaller IPv6 link-local address will need to 274 select a new Router ID as described in Section 7.3. Note that the 275 fact that the OSPFv3 router is a neighbor on a non-virtual interface 276 implies that the router is directly connected. An OSPFv3 router 277 implementing this specification should assure that the inadvertent 278 connection of multiple router interfaces to the same physical link is 279 not misconstrued as detection of an OSPFv3 neighbor with a duplicate 280 Router ID. 282 7.2. Duplicate Router ID Detection for OSPFv3 Routers that are not 283 Neighbors 285 OSPFv3 Routers implementing auto-configuration, as specified herein, 286 MUST originate an Auto-Configuration (AC) Link State Advertisement 287 (LSA) including the Router-Hardware-Fingerprint Type-Length-Value 288 (TLV). The Router-Hardware-Fingerprint TLV contains a variable 289 length value that has a very high probability of uniquely identifying 290 the advertising OSPFv3 router. An OSPFv3 router implementing this 291 specification MUST compare a received self-originated Auto- 292 Configuration LSA's Router-Hardware-Fingerprint TLV against its own 293 router hardware fingerprint. If the fingerprints are not equal, 294 there is a duplicate Router ID conflict and the OSPFv3 Router with 295 the numerically smaller router hardware fingerprint MUST select a new 296 Router ID as described in Section 7.3. 298 This new LSA is designated for information related to OSPFv3 Auto- 299 configuration and, in the future, could be used other auto- 300 configuration information, e.g., global IPv6 prefixes. However, this 301 is beyond the scope of this document. 303 7.2.1. OSPFv3 Router Auto-Configuration LSA 305 The OSPFv3 Auto-Configuration (AC) LSA has a function code of TBD and 306 the S2/S1 bits set to 01 indicating Area Flooding Scope. The U bit 307 will be set indicating that the OSPFv3 AC LSA should be flooded even 308 if it is not understood. The Link State ID (LSID) value will be a 309 integer index used to discriminate between multiple AC LSAs 310 originated by the same OSPFv3 Router. This specification only 311 describes the contents of an AC LSA with a Link State ID (LSID) of 0. 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | LS age |1|0|1| TBD | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Link State ID | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Advertising Router | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | LS sequence number | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | LS checksum | Length | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | | 327 +- TLVs -+ 328 | ... | 330 OSPFv3 Auto-Configuration (AC) LSA 332 The format of the TLVs within the body of an AC LSA is the same as 333 the format used by the Traffic Engineering Extensions to OSPF [TE]. 334 The LSA payload consists of one or more nested Type/Length/Value 335 (TLV) triplets. The format of each TLV is: 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Type | Length | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Value... | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 TLV Format 347 The Length field defines the length of the value portion in octets 348 (thus a TLV with no value portion would have a length of 0). The TLV 349 is padded to 4-octet alignment; padding is not included in the length 350 field (so a 3-octet value would have a length of 3, but the total 351 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 352 aligned. For example, a 1-byte value would have the length field set 353 to 1, and 3 octets of padding would be added to the end of the value 354 portion of the TLV. Unrecognized types are ignored. 356 The new LSA is designated for information related to OSPFv3 Auto- 357 configuration and, in the future, can be used other auto- 358 configuration information. 360 7.2.2. Router-Hardware-Fingerprint TLV 362 The Router-Hardware-Fingerprint TLV is the first TLV defined for the 363 OSPFv3 Auto-Configuration (AC) LSA. It will have type 1 and MUST be 364 advertised in the LSID OSPFv3 AC LSA with an LSID of 0. It SHOULD 365 occur, at most, once and the first instance of the TLV will take 366 precedence over subsequent TLV instances. The length of the Router- 367 Hardware-Fingerprint is variable but must be 32 octets or greater. 369 The contents of the hardware fingerprint MUST be some combination of 370 MAC addresses, CPU ID, or serial number(s) that provides an extremely 371 high probability of uniqueness. It is RECOMMENDED that one or more 372 available universal tokens (e.g., IEEE 802 48-bit MAC addresses or 373 IEEE EUI-64 Identifiers [EUI64]) associated with the OSPFv3 router be 374 included in the hardware fingerprint. It MUST be based on hardware 375 attributes that will not change across hard and soft restarts. 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | 1 | >32 | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Router Hardware Fingerprint | 383 o 384 o 385 o 386 | | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 Router-Hardware-Fingerprint TLV Format 391 7.3. Duplicate Router ID Resolution 393 The OSPFv3 Router selected to resolve the duplicate OSPFv3 Router ID 394 condition must select a new OSPFv3 Router ID. After selecting a new 395 Router ID, all self-originated LSAs MUST be reoriginated, and any 396 OSPFv3 neighbor adjacencies MUST be reestablished. The OSPFv3 router 397 retaining the Router ID causing the conflict will reoriginate or 398 purge stale any LSAs as described in Section 13.4 [OSPFV2]. 400 7.4. Change to RFC 2328 Section 13.4, 'Receiving Self-Originated LSA' 401 Processing 403 RFC 2328 [OSPFV2], Section 13.4, describes the processing of received 404 self-originated LSAs. If the received LSA doesn't exist, the 405 receiving router will purge it from the OSPF routing domain. If the 406 LSA is newer than the version in the Link State Database (LSDB), the 407 receiving router will originate a newer version by advancing the LSA 408 sequence number and reflooding. Since it is possible for an auto- 409 configured OSPFv3 router to choose a duplicate OSPFv3 Router ID, 410 OSPFv3 routers implementing this specification should detect when 411 multiple instances of the same self-originated LSA are purged or 412 reoriginated since this is indicative of an OSPFv3 router with a 413 duplicate Router ID in the OSPFv3 routing domain. When this 414 condition is detected, the OSPFv3 Router SHOULD delay self-originated 415 LSA processing for LSAs that have recently been purged or reflooded. 416 This specification recommends 10 seconds as the interval defining 417 recent self-originated LSA processing and an exponential back off of 418 1 to 8 seconds for the processing delay. This additional delay 419 should allow for the mechanisms described in Section 7 to resolve the 420 duplicate OSPFv3 Router ID conflict. 422 8. Security Considerations 424 A unique OSPFv3 Interface Instance ID is used for auto-configuration 425 to prevent inadvertent OSPFv3 adjacency formation, see Section 2 427 The goals of security and complete OSPFv3 auto-configuration are 428 somewhat contradictory. When no explicit security configuration 429 takes place, auto-configuration implies that additional devices 430 placed in the network are automatically adopted as a part of the 431 network. However, auto-configuration can also be combined with 432 password configuration (see Section 4) or future extensions for 433 automatic pairing between devices. These mechanisms can help provide 434 an automatically configured, securely routed network. 436 9. Management Considerations 438 It is RECOMMENDED that OSPFv3 routers supporting this specification 439 also allow explicit configuration of OSPFv3 parameters as specified 440 in Appendix C of [OSPFV3]. This is in addition to the authentication 441 key configuration recommended in Section 4. However, it is 442 acknowledged that there may be some deployment scenarios where manual 443 authentication key configuration is not required. 445 Since there is a small possibility of OSPFv3 Router ID collisions, 446 manual configuration of OSPFv3 Router-IDs is RECOMMENDED in OSPFv3 447 routing domains where route recovergence due to a router ID change is 448 intolerable. 450 10. IANA Considerations 452 This specification defines an OSPFv3 LSA Type for the OSPFv3 Auto- 453 Configuration (AC) LSA, as described in Section 7.2.1. The value TBD 454 will be allocated from the existing "OSPFv3 LSA Function Code" 455 registry for the OSPFv3 Auto-Configuration LSA. 457 This specification also creates a registry for OSPFv3 Auto- 458 Configuration (AC) LSA TLVs. This registry should be placed in the 459 existing OSPFv3 IANA registry, and new values can be allocated via 460 IETF Consensus or IESG Approval. 462 Three initial values are allocated: 464 o 0 is marked as reserved. 466 o 1 is Router-Hardware-Fingerprint TLV (Section 7.2.2). 468 o 65535 is an Auto-configuration-Experiment-TLV, a common value that 469 can be used for experimental purposes. 471 11. References 473 11.1. Normative References 475 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 477 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 478 for IPv6", RFC 5340, July 2008. 480 [OSPFV3-AF] 481 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 482 Aggarwal, "Support of Address Families in OSPFv3", 483 RFC 5838, April 2010. 485 [OSPFV3-AUTH-TRAILER] 486 Bhatia, M., Manral, V., and A. Lindem, "Supporting 487 Authentication Trailer for OSPFv3", RFC 7166, 488 February 2012. 490 [RFC-KEYWORDS] 491 Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", RFC 2119, March 1997. 494 [SLAAC] Thomson, S., Narten, T., and J. Tatuya, "IPv6 Stateless 495 Address Autoconfiguration", RFC 4862, September 2007. 497 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 498 Extensions to OSPF", RFC 3630, September 2003. 500 11.2. Informative References 502 [ASYNC-HELLO] 503 Anand, M., Grover, H., and A. Roy, "Asymmetric OSPF Hold 504 Timer", draft-madhukar-ospf-agr-asymmetric-01.txt (work in 505 progress). 507 [BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 508 Protocol 4 (BGP-4)", RFC 4271, January 2006. 510 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 511 Registration Authority", IEEE Tutorial http:// 512 standards.ieee.org/regauth/oui/tutorials/EUI64.html, 513 March 1997. 515 [IPv6-CPE] 516 Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 517 Requirements for IPv6 Customer Edge Routers", RFC 7084, 518 November 2013. 520 Authors' Addresses 522 Acee Lindem 523 Cisco Systems 524 301 Midenhall Way 525 Cary, NC 27513 526 USA 528 Email: acee@cisco.com 530 Jari Arkko 531 Ericsson 532 Jorvas, 02420 533 Finland 535 Email: jari.arkko@piuha.net