idnits 2.17.00 (12 Aug 2021) /tmp/idnits32508/draft-ietf-ospf-ospfv3-autoconfig-10.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 (January 5, 2015) is 2693 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: July 9, 2015 Ericsson 6 January 5, 2015 8 OSPFv3 Auto-Configuration 9 draft-ietf-ospf-ospfv3-autoconfig-10.txt 11 Abstract 13 OSPFv3 is a candidate for deployments in environments where auto- 14 configuration is a requirement. One such environment is the IPv6 15 home network where users expect to simply plug in a router and have 16 it automatically use OSPFv3 for intra-domain routing. This document 17 describes the necessary mechanisms for OSPFv3 to be self-configuring. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 9, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 55 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 3 56 2. OSPFv3 Default Configuration . . . . . . . . . . . . . . . . 4 57 3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . . 5 58 3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . 5 59 4. OSPFv3 Minimal Authentication Configuration . . . . . . . . . 5 60 5. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . 5 61 6. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . 6 62 7. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 6 63 7.1. Duplicate Router ID Detection for Neighbors . . . . . . . 6 64 7.2. Duplicate Router ID Detection for OSPFv3 Routers that are 65 not Neighbors . . . . . . . . . . . . . . . . . . . . . . 7 66 7.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . 7 67 7.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 9 68 7.3. Duplicate Router ID Resolution . . . . . . . . . . . . . 9 69 7.4. Change to RFC 2328 Section 13.4, 'Receiving Self- 70 Originated LSA' Processing . . . . . . . . . . . . . . . 9 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 9. Management Considerations . . . . . . . . . . . . . . . . . . 10 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 11.2. Informative References . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 Thanks to Martin Vigoureux for Routing Area Directorate review and 136 comments. 138 Special thanks go to Markus Stenberg for his implementation of this 139 specification in Bird. 141 Special thanks also go to David Lamparter for his implementation of 142 this specification in Quagga. 144 The RFC text was produced using Marshall Rose's xml2rfc tool. 146 2. OSPFv3 Default Configuration 148 For complete auto-configuration, OSPFv3 will need to choose suitable 149 configuration defaults. These include: 151 1. Area 0 Only - All auto-configured OSPFv3 interfaces MUST be in 152 area 0. 154 2. OSPFv3 SHOULD be auto-configured for IPv6 on all interfaces 155 intended as general IPv6-capable routers. Optionally, an 156 interface MAY be excluded if it is clear that running OSPFv3 on 157 the interface is not required. For example, if manual 158 configuration or another condition indicates that an interface is 159 connected to an Internet Service Provider (ISP) and there is no 160 Border Gateway Protocol (BGP) [BGP] peering, there is typically 161 no need to employ OSPFv3. In fact, [IPv6-CPE] specifically 162 requires that IPv6 Customer Premise Equipment (CPE) routers do 163 not initiate any dynamic routing protocol by default on the 164 router's WAN, i.e., ISP-facing, interface. In home networking 165 environments, an interface where no OSPFv3 neighbors are found 166 but a DHCP IPv6 prefix can be acquired may be considered an ISP- 167 facing interface and running OSPFv3 is unnecessary. 169 3. OSPFv3 interfaces will be auto-configured to an interface type 170 corresponding to their layer-2 capability. For example, Ethernet 171 interfaces and vanilla Wi-Fi interfaces will be auto-configured 172 as OSPFv3 broadcast networks and Point-to-Point Protocol (PPP) 173 interfaces will be auto-configured as OSPFv3 Point-to-Point 174 interfaces. Most extant OSPFv3 implementations do this already. 175 Auto-configured operation over wireless networks requiring a 176 point-to-multipoint (P2MP) topology and dynamic metrics based on 177 wireless feedback is not within the scope of this document. 178 However, auto-configuration is not precluded in these 179 environments. 181 4. OSPFv3 interfaces MAY use an arbitrary HelloInterval and 182 RouterDeadInterval as specified in Section 3. Of course, an 183 identical HelloInterval and RouterDeadInterval will still be 184 required to form an adjacency with an OSPFv3 router not 185 supporting auto-configuration [OSPFV3]. 187 5. All OSPFv3 interfaces SHOULD be auto-configured to use an 188 Interface Instance ID of 0 that corresponds to the base IPv6 189 unicast address family instance ID as defined in [OSPFV3-AF]. 190 Similarly, if IPv4 unicast addresses are advertised in a separate 191 auto-configured OSPFv3 instance, the base IPv4 unicast address 192 family instance ID value, i.e., 64, SHOULD be auto-configured as 193 the Interface Instance ID for all interfaces corresponding to the 194 IPv4 unicast OSPFv3 instance [OSPFV3-AF]. 196 3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility 198 Auto-configured OSPFv3 routers will not require an identical 199 HelloInterval and RouterDeadInterval to form adjacencies. Rather, 200 the received HelloInterval will be ignored and the received 201 RouterDeadInterval will be used to determine OSPFv3 liveliness with 202 the sending router. In other words, the Neighbor Inactivity Timer 203 (Section 10 of [OSPFV2]) for each neighbor will reflect that 204 neighbor's advertised RouterDeadInterval and MAY be different from 205 other OSPFv3 routers on the link without impacting adjacency 206 formation. A similar mechanism requiring additional signaling is 207 proposed for all OSPFv2 and OSPFv3 routers [ASYNC-HELLO]. 209 3.1. Wait Timer Reduction 211 In many situations, auto-configured OSPFv3 routers will be deployed 212 in environments where back-to-back ethernet connections are utilized. 213 When this is the case, an OSPFv3 broadcast interface will not come up 214 until the other OSPFv3 router is connected and the routers will wait 215 RouterDeadInterval seconds before forming an adjacency [OSPFV2]. In 216 order to reduce this delay, an auto-configured OSPFv3 router MAY 217 reduce the wait interval to a value no less than (HelloInterval + 1). 218 Reducing the setting will slightly increase the likelihood of the 219 Designated Router (DR) flapping but is preferable to the long 220 adjacency formation delay. Note that this value is not included in 221 OSPFv3 Hello packets and does not impact interoperability. 223 4. OSPFv3 Minimal Authentication Configuration 225 In many deployments, the requirement for OSPFv3 authentication 226 overrides the goal of complete OSPFv3 autoconfiguration. Therefore, 227 it is RECOMMENDED that OSPFv3 routers supporting this specification 228 minimally offer an option to explicitly configure a single password 229 for HMAC-SHA authentication as described in [OSPFV3-AUTH-TRAILER]. 230 When configured, the password will be used on all auto-configured 231 interfaces with the Security Association Identifier (SA ID) set to 1 232 and HMAC-SHA-256 used as the authentication algorithm. 234 5. OSPFv3 Router ID Selection 236 An OSPFv3 router requires a unique Router ID for correct protocol 237 operation. An OSPFv3 router implementing this specification will 238 select a router-id that has a high probability of uniqueness. A 239 pseudo-random number SHOULD be used for the OSPFv3 Router ID. The 240 generation should be seeded with a variable that is likely to be 241 unique in the applicable OSPFv3 router deployment. A good choice of 242 seed would be some portion or hash of the Router-Hardware-Fingerprint 243 as described in Section 7.2.2. 245 Since there is a possibility of a Router ID collision, duplicate 246 Router ID detection and resolution are required as described in 247 Section 7 and Section 7.3. OSPFv3 routers SHOULD maintain the last 248 successfully chosen Router ID in non-volatile storage to avoid 249 collisions subsequent to when an autoconfigured OSPFv3 router is 250 first added to the OSPFv3 routing domain. 252 6. OSPFv3 Adjacency Formation 254 Since OSPFv3 uses IPv6 link-local addresses for all protocol messages 255 other than messages sent on virtual links (which are not applicable 256 to auto-configuration), OSPFv3 adjacency formation can proceed as 257 soon as a Router ID has been selected and the IPv6 link-local address 258 has completed Duplicate Address Detection (DAD) as specified in IPv6 259 Stateless Address Autoconfiguration [SLAAC]. Otherwise, the only 260 changes to the OSPFv3 base specification are supporting 261 HelloInterval/RouterDeadInterval flexibility as described in 262 Section 3 and duplicate Router ID detection and resolution as 263 described in Section 7 and Section 7.3. 265 7. OSPFv3 Duplicate Router ID Detection and Resolution 267 There are two cases of duplicate OSPFv3 Router ID detection. One 268 where the OSPFv3 router with the duplicate Router ID is directly 269 connected and one where it is not. In both cases, the duplicate 270 resolution is for one of the routers to select a new OSPFv3 Router 271 ID. 273 7.1. Duplicate Router ID Detection for Neighbors 275 In this case, a duplicate Router ID is detected if any valid OSPFv3 276 packet is received with the same OSPFv3 Router ID but a different 277 IPv6 link-local source address. Once this occurs, the OSPFv3 router 278 with the numerically smaller IPv6 link-local address will need to 279 select a new Router ID as described in Section 7.3. Note that the 280 fact that the OSPFv3 router is a neighbor on a non-virtual interface 281 implies that the router is directly connected. An OSPFv3 router 282 implementing this specification should assure that the inadvertent 283 connection of multiple router interfaces to the same physical link is 284 not misconstrued as detection of an OSPFv3 neighbor with a duplicate 285 Router ID. 287 7.2. Duplicate Router ID Detection for OSPFv3 Routers that are not 288 Neighbors 290 OSPFv3 routers implementing auto-configuration, as specified herein, 291 MUST originate an Auto-Configuration (AC) Link State Advertisement 292 (LSA) including the Router-Hardware-Fingerprint Type-Length-Value 293 (TLV). The Router-Hardware-Fingerprint TLV contains a variable 294 length value that has a very high probability of uniquely identifying 295 the advertising OSPFv3 router. An OSPFv3 router implementing this 296 specification MUST detect received Auto-Configuration LSAs with its 297 Router ID specified in the LSA header. LSAs received with the local 298 OSPFv3 Router's Router ID in the LSA header are perceived as self- 299 originated (see section 4.6 of [OSPFV3]). In these received Auto- 300 Configuration LSAs, the Router-Hardware-Fingerprint TLV is compared 301 against the OSPFv3 Router's own router hardware fingerprint. If the 302 fingerprints are not equal, there is a duplicate Router ID conflict 303 and the OSPFv3 router with the numerically smaller router hardware 304 fingerprint MUST select a new Router ID as described in Section 7.3. 306 This new LSA is designated for information related to OSPFv3 Auto- 307 configuration and, in the future, could be used other auto- 308 configuration information, e.g., global IPv6 prefixes. However, this 309 is beyond the scope of this document. 311 7.2.1. OSPFv3 Router Auto-Configuration LSA 313 The OSPFv3 Auto-Configuration (AC) LSA has a function code of TBD and 314 the S2/S1 bits set to 01 indicating Area Flooding Scope. The U bit 315 will be set indicating that the OSPFv3 AC LSA should be flooded even 316 if it is not understood. The Link State ID (LSID) value will be a 317 integer index used to discriminate between multiple AC LSAs 318 originated by the same OSPFv3 router. This specification only 319 describes the contents of an AC LSA with a Link State ID (LSID) of 0. 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | LS age |1|0|1| TBD | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Link State ID | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Advertising Router | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | LS sequence number | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | LS checksum | Length | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | | 335 +- TLVs -+ 336 | ... | 338 OSPFv3 Auto-Configuration (AC) LSA 340 The format of the TLVs within the body of an AC LSA is the same as 341 the format used by the Traffic Engineering Extensions to OSPF [TE]. 342 The LSA payload consists of one or more nested Type/Length/Value 343 (TLV) triplets. The format of each TLV is: 345 0 1 2 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Type | Length | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Value... | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 TLV Format 355 The Length field defines the length of the value portion in octets 356 (thus a TLV with no value portion would have a length of 0). The TLV 357 is padded to 4-octet alignment; padding is not included in the length 358 field (so a 3-octet value would have a length of 3, but the total 359 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 360 aligned. For example, a 1-byte value would have the length field set 361 to 1, and 3 octets of padding would be added to the end of the value 362 portion of the TLV. Unrecognized types are ignored. 364 The new LSA is designated for information related to OSPFv3 Auto- 365 configuration and, in the future, can be used other auto- 366 configuration information. 368 7.2.2. Router-Hardware-Fingerprint TLV 370 The Router-Hardware-Fingerprint TLV is the first TLV defined for the 371 OSPFv3 Auto-Configuration (AC) LSA. It will have type 1 and MUST be 372 advertised in the LSID OSPFv3 AC LSA with an LSID of 0. It SHOULD 373 occur, at most, once and the first instance of the TLV will take 374 precedence over subsequent TLV instances. The length of the Router- 375 Hardware-Fingerprint is variable but must be 32 octets or greater. 377 The contents of the hardware fingerprint MUST be some combination of 378 MAC addresses, CPU ID, or serial number(s) that provides an extremely 379 high probability of uniqueness. It is RECOMMENDED that one or more 380 available universal tokens (e.g., IEEE 802 48-bit MAC addresses or 381 IEEE EUI-64 Identifiers [EUI64]) associated with the OSPFv3 router be 382 included in the hardware fingerprint. It MUST be based on hardware 383 attributes that will not change across hard and soft restarts. 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | 1 | >32 | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Router Hardware Fingerprint | 391 o 392 o 393 o 394 | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Router-Hardware-Fingerprint TLV Format 399 7.3. Duplicate Router ID Resolution 401 The OSPFv3 router selected to resolve the duplicate OSPFv3 Router ID 402 condition must select a new OSPFv3 Router ID. After selecting a new 403 Router ID, all self-originated LSAs MUST be reoriginated, and any 404 OSPFv3 neighbor adjacencies MUST be reestablished. The OSPFv3 router 405 retaining the Router ID causing the conflict will reoriginate or 406 purge stale any LSAs as described in Section 13.4 [OSPFV2]. 408 7.4. Change to RFC 2328 Section 13.4, 'Receiving Self-Originated LSA' 409 Processing 411 RFC 2328 [OSPFV2], Section 13.4, describes the processing of received 412 self-originated LSAs. If the received LSA doesn't exist, the 413 receiving router will purge it from the OSPF routing domain. If the 414 LSA is newer than the version in the Link State Database (LSDB), the 415 receiving router will originate a newer version by advancing the LSA 416 sequence number and reflooding. Since it is possible for an auto- 417 configured OSPFv3 router to choose a duplicate OSPFv3 Router ID, 418 OSPFv3 routers implementing this specification should detect when 419 multiple instances of the same self-originated LSA are purged or 420 reoriginated since this is indicative of an OSPFv3 router with a 421 duplicate Router ID in the OSPFv3 routing domain. When this 422 condition is detected, the OSPFv3 router SHOULD delay self-originated 423 LSA processing for LSAs that have recently been purged or reflooded. 424 This specification recommends 10 seconds as the interval defining 425 recent self-originated LSA processing and an exponential back off of 426 1 to 8 seconds for the processing delay. This additional delay 427 should allow for the mechanisms described in Section 7 to resolve the 428 duplicate OSPFv3 Router ID conflict. 430 8. Security Considerations 432 A unique OSPFv3 Interface Instance ID is used for auto-configuration 433 to prevent inadvertent OSPFv3 adjacency formation, see Section 2 435 The goals of security and complete OSPFv3 auto-configuration are 436 somewhat contradictory. When no explicit security configuration 437 takes place, auto-configuration implies that additional devices 438 placed in the network are automatically adopted as a part of the 439 network. However, auto-configuration can also be combined with 440 password configuration (see Section 4) or future extensions for 441 automatic pairing between devices. These mechanisms can help provide 442 an automatically configured, securely routed network. 444 9. Management Considerations 446 It is RECOMMENDED that OSPFv3 routers supporting this specification 447 also allow explicit configuration of OSPFv3 parameters as specified 448 in Appendix C of [OSPFV3]. This is in addition to the authentication 449 key configuration recommended in Section 4. However, it is 450 acknowledged that there may be some deployment scenarios where manual 451 authentication key configuration is not required. 453 Since there is a small possibility of OSPFv3 Router ID collisions, 454 manual configuration of OSPFv3 Router IDs is RECOMMENDED in OSPFv3 455 routing domains where route recovergence due to a router ID change is 456 intolerable. 458 10. IANA Considerations 460 This specification defines an OSPFv3 LSA Type for the OSPFv3 Auto- 461 Configuration (AC) LSA, as described in Section 7.2.1. The value TBD 462 will be allocated from the existing "OSPFv3 LSA Function Code" 463 registry for the OSPFv3 Auto-Configuration LSA. 465 This specification also creates a registry for OSPFv3 Auto- 466 Configuration (AC) LSA TLVs. This registry should be placed in the 467 existing OSPFv3 IANA registry, and new values can be allocated via 468 IETF Consensus or IESG Approval. 470 Three initial values are allocated: 472 o 0 is marked as reserved. 474 o 1 is Router-Hardware-Fingerprint TLV (Section 7.2.2). 476 o 65535 is an Auto-configuration-Experiment-TLV, a common value that 477 can be used for experimental purposes. 479 11. References 481 11.1. Normative References 483 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 485 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 486 for IPv6", RFC 5340, July 2008. 488 [OSPFV3-AF] 489 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 490 Aggarwal, "Support of Address Families in OSPFv3", RFC 491 5838, April 2010. 493 [OSPFV3-AUTH-TRAILER] 494 Bhatia, M., Manral, V., and A. Lindem, "Supporting 495 Authentication Trailer for OSPFv3", RFC 7166, February 496 2012. 498 [RFC-KEYWORDS] 499 Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", RFC 2119, March 1997. 502 [SLAAC] Thomson, S., Narten, T., and J. Tatuya, "IPv6 Stateless 503 Address Autoconfiguration", RFC 4862, September 2007. 505 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 506 Extensions to OSPF", RFC 3630, September 2003. 508 11.2. Informative References 510 [ASYNC-HELLO] 511 Anand, M., Grover, H., and A. Roy, "Asymmetric OSPF Hold 512 Timer", draft-madhukar-ospf-agr-asymmetric-01.txt (work in 513 progress), June 2013. 515 [BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 516 Protocol 4 (BGP-4)", RFC 4271, January 2006. 518 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 519 Registration Authority", IEEE Tutorial 520 http://standards.ieee.org/regauth/oui/tutorials/ 521 EUI64.html, March 1997. 523 [IPv6-CPE] 524 Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 525 Requirements for IPv6 Customer Edge Routers", RFC 7084, 526 November 2013. 528 Authors' Addresses 530 Acee Lindem 531 Cisco Systems 532 301 Midenhall Way 533 Cary, NC 27513 534 USA 536 Email: acee@cisco.com 538 Jari Arkko 539 Ericsson 540 Jorvas, 02420 541 Finland 543 Email: jari.arkko@piuha.net