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