idnits 2.17.1 draft-ietf-ipv6-rfc2462bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 310: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 311: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 510: '... A node MUST allow the following aut...' RFC 2119 keyword, line 579: '... Duplicate Address Detection MUST take...' RFC 2119 keyword, line 584: '...ddress Detection MUST NOT be performed...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 14, 2004) is 7228 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) -- Missing reference section? '7' on line 413 looks like a reference -- Missing reference section? '8' on line 415 looks like a reference -- Missing reference section? '5' on line 794 looks like a reference -- Missing reference section? '4' on line 568 looks like a reference -- Missing reference section? '2' on line 523 looks like a reference -- Missing reference section? '3' on line 313 looks like a reference -- Missing reference section? '10' on line 599 looks like a reference -- Missing reference section? '11' on line 599 looks like a reference -- Missing reference section? '12' on line 690 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF IPv6 Working Group S. Thomson 2 Internet-Draft Cisco 3 Expires: December 13, 2004 T. Narten 4 IBM 5 T. Jinmei 6 Toshiba 7 H. Soliman 8 Flarion Technologies 9 June 14, 2004 11 IPv6 Stateless Address Autoconfiguration 12 draft-ietf-ipv6-rfc2462bis-01.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 13, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document specifies the steps a host takes in deciding how to 43 autoconfigure its interfaces in IP version 6. The autoconfiguration 44 process includes creating a link-local address and verifying its 45 uniqueness on a link, determining what information can be 46 autoconfigured (addresses, other information, or both), and in the 47 case of addresses, whether they can be obtained through the stateless 48 mechanism, the stateful mechanism, or both. This document defines the 49 process for generating a link-local address, the process for 50 generating global addresses via stateless address autoconfiguration, 51 and the Duplicate Address Detection procedure. The details of 52 autoconfiguration using the stateful protocol is specified in RFC 53 3315 and RFC 3736. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. TERMINOLOGY . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3. DESIGN GOALS . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4. PROTOCOL OVERVIEW . . . . . . . . . . . . . . . . . . . . . 8 62 4.1 Site Renumbering . . . . . . . . . . . . . . . . . . . . . . 10 63 5. PROTOCOL SPECIFICATION . . . . . . . . . . . . . . . . . . . 11 64 5.1 Node Configuration Variables . . . . . . . . . . . . . . . . 11 65 5.2 Autoconfiguration-Related Structures . . . . . . . . . . . . 12 66 5.3 Creation of Link-Local Addresses . . . . . . . . . . . . . . 12 67 5.4 Duplicate Address Detection . . . . . . . . . . . . . . . . 13 68 5.4.1 Message Validation . . . . . . . . . . . . . . . . . . . . . 14 69 5.4.2 Sending Neighbor Solicitation Messages . . . . . . . . . . . 14 70 5.4.3 Receiving Neighbor Solicitation Messages . . . . . . . . . . 15 71 5.4.4 Receiving Neighbor Advertisement Messages . . . . . . . . . 16 72 5.4.5 When Duplicate Address Detection Fails . . . . . . . . . . . 17 73 5.5 Creation of Global Addresses . . . . . . . . . . . . . . . . 17 74 5.5.1 Soliciting Router Advertisements . . . . . . . . . . . . . . 17 75 5.5.2 Absence of Router Advertisements . . . . . . . . . . . . . . 17 76 5.5.3 Router Advertisement Processing . . . . . . . . . . . . . . 18 77 5.5.4 Address Lifetime Expiry . . . . . . . . . . . . . . . . . . 20 78 5.6 Configuration Consistency . . . . . . . . . . . . . . . . . 21 79 5.7 Retaining Configured Addresses for Stability . . . . . . . . 21 80 6. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . 21 81 7. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 22 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 83 Normative References . . . . . . . . . . . . . . . . . . . . 22 84 Informative References . . . . . . . . . . . . . . . . . . . 23 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 86 A. LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION . . . . . 24 87 B. CHANGES SINCE RFC 1971 . . . . . . . . . . . . . . . . . . . 26 88 C. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . . . . . 26 89 Intellectual Property and Copyright Statements . . . . . . . 29 91 1. Introduction 93 This document specifies the steps a host takes in deciding how to 94 autoconfigure its interfaces in IP version 6. The autoconfiguration 95 process includes creating a link-local address and verifying its 96 uniqueness on a link, determining what information can be 97 autoconfigured (addresses, other information, or both), and in the 98 case of addresses, whether they can be obtained through the stateless 99 mechanism, the stateful mechanism, or both. This document defines the 100 process for generating a link-local address, the process for 101 generating global addresses via stateless address autoconfiguration, 102 and the Duplicate Address Detection procedure. The details of 103 autoconfiguration using the stateful protocol is specified in RFC 104 3315 [7] and RFC 3736 [8]. 106 IPv6 defines both a stateful and stateless address autoconfiguration 107 mechanism. Stateless autoconfiguration requires no manual 108 configuration of hosts, minimal (if any) configuration of routers, 109 and no additional servers. The stateless mechanism allows a host to 110 generate its own addresses using a combination of locally available 111 information and information advertised by routers. Routers advertise 112 prefixes that identify the subnet(s) associated with a link, while 113 hosts generate an "interface identifier" that uniquely identifies an 114 interface on a subnet. An address is formed by combining the two. In 115 the absence of routers, a host can only generate link-local 116 addresses. However, link-local addresses are sufficient for allowing 117 communication among nodes attached to the same link. 119 In the stateful autoconfiguration model, hosts obtain interface 120 addresses and/or configuration information and parameters from a 121 DHCPv6 server. Servers maintain a database that keeps track of which 122 addresses have been assigned to which hosts. The stateful 123 autoconfiguration protocol allows hosts to obtain addresses, other 124 configuration information or both from a server. Stateless and 125 stateful autoconfiguration complement each other. For example, a host 126 can use stateless autoconfiguration to configure its own addresses, 127 but use stateful autoconfiguration to obtain other information. 129 To obtain other configuration information without configuring 130 addresses in the stateful autoconfiguration model, a subset of DHCPv6 131 will be used [8]. While the model is called "stateful" here in order 132 to highlight the contrast to the stateless protocol defined in this 133 document, the intended protocol is also defined to work in a 134 stateless fashion. This is based on a result, through operational 135 experiments, that all known "other" configuration information can be 136 managed by a stateless server, that is, a server that does not 137 maintain state of each client that the server provides with the 138 configuration information. 140 The stateless approach is used when a site is not particularly 141 concerned with the exact addresses hosts use, so long as they are 142 unique and properly routable. The stateful approach is used when a 143 site requires tighter control over exact address assignments. Both 144 stateful and stateless address autoconfiguration may be used 145 simultaneously. The site administrator specifies which type of 146 autoconfiguration is available through the setting of appropriate 147 fields in Router Advertisement messages [5]. 149 IPv6 addresses are leased to an interface for a fixed (possibly 150 infinite) length of time. Each address has an associated lifetime 151 that indicates how long the address is bound to an interface. When a 152 lifetime expires, the binding (and address) become invalid and the 153 address may be reassigned to another interface elsewhere in the 154 Internet. To handle the expiration of address bindings gracefully, an 155 address goes through two distinct phases while assigned to an 156 interface. Initially, an address is "preferred", meaning that its use 157 in arbitrary communication is unrestricted. Later, an address becomes 158 "deprecated" in anticipation that its current interface binding will 159 become invalid. While in a deprecated state, the use of an address is 160 discouraged, but not strictly forbidden. New communication (e.g., 161 the opening of a new TCP connection) should use a preferred address 162 when possible. A deprecated address should be used only by 163 applications that have been using it and would have difficulty 164 switching to another address without a service disruption. 166 To ensure that all configured addresses are likely to be unique on a 167 given link, nodes run a "duplicate address detection" algorithm on 168 addresses before assigning them to an interface. The Duplicate 169 Address Detection algorithm is performed on all addresses, 170 independent of whether they are obtained via stateless or stateful 171 autoconfiguration. This document defines the Duplicate Address 172 Detection algorithm. 174 The autoconfiguration process specified in this document applies only 175 to hosts and not routers. Since host autoconfiguration uses 176 information advertised by routers, routers will need to be configured 177 by some other means. However, it is expected that routers will 178 generate link-local addresses using the mechanism described in this 179 document. In addition, routers are expected to successfully pass the 180 Duplicate Address Detection procedure described in this document on 181 all addresses prior to assigning them to an interface. 183 Section 2 provides definitions for terminology used throughout this 184 document. Section 3 describes the design goals that lead to the 185 current autoconfiguration procedure. Section 4 provides an overview 186 of the protocol, while Section 5 describes the protocol in detail. 188 2. TERMINOLOGY 190 IP - Internet Protocol Version 6. The terms IPv4 and IPv6 are used 191 only in contexts where necessary to avoid ambiguity. 193 node - a device that implements IP. 195 router - a node that forwards IP packets not explicitly addressed to 196 itself. 198 host - any node that is not a router. 200 upper layer - a protocol layer immediately above IP. Examples are 201 transport protocols such as TCP and UDP, control protocols such as 202 ICMP, routing protocols such as OSPF, and internet or lower-layer 203 protocols being "tunneled" over (i.e., encapsulated in) IP such as 204 IPX, AppleTalk, or IP itself. 206 link - a communication facility or medium over which nodes can 207 communicate at the link layer, i.e., the layer immediately below 208 IP. Examples are Ethernets (simple or bridged); PPP links; X.25, 209 Frame Relay, or ATM networks; and internet (or higher) layer 210 "tunnels", such as tunnels over IPv4 or IPv6 itself. 212 interface - a node's attachment to a link. 214 packet - an IP header plus payload. 216 address - an IP-layer identifier for an interface or a set of 217 interfaces. 219 unicast address - an identifier for a single interface. A packet sent 220 to a unicast address is delivered to the interface identified by 221 that address. 223 multicast address - an identifier for a set of interfaces (typically 224 belonging to different nodes). A packet sent to a multicast 225 address is delivered to all interfaces identified by that address. 227 anycast address - an identifier for a set of interfaces (typically 228 belonging to different nodes). A packet sent to an anycast 229 address is delivered to one of the interfaces identified by that 230 address (the "nearest" one, according to the routing protocol's 231 measure of distance). See the IPv6 addressing architecture [4]. 233 solicited-node multicast address - a multicast address to which 234 Neighbor Solicitation messages are sent. The algorithm for 235 computing the address is given in RFC 2461 [5]. 237 link-layer address - a link-layer identifier for an interface. 238 Examples include IEEE 802 addresses for Ethernet links and E.164 239 addresses for ISDN links. 241 link-local address - an address having link-only scope that can be 242 used to reach neighboring nodes attached to the same link. All 243 interfaces have a link-local unicast address. 245 global address - an address with unlimited scope. 247 communication - any packet exchange among nodes that requires that 248 the address of each node used in the exchange remain the same for 249 the duration of the packet exchange. Examples are a TCP 250 connection or a UDP request-response. 252 tentative address - an address whose uniqueness on a link is being 253 verified, prior to its assignment to an interface. A tentative 254 address is not considered assigned to an interface in the usual 255 sense. An interface discards received packets addressed to a 256 tentative address, but accepts Neighbor Discovery packets related 257 to Duplicate Address Detection for the tentative address. 259 preferred address - an address assigned to an interface whose use by 260 upper layer protocols is unrestricted. Preferred addresses may be 261 used as the source (or destination) address of packets sent from 262 (or to) the interface. 264 deprecated address - An address assigned to an interface whose use is 265 discouraged, but not forbidden. A deprecated address should no 266 longer be used as a source address in new communications, but 267 packets sent from or to deprecated addresses are delivered as 268 expected. A deprecated address may continue to be used as a 269 source address in communications where switching to a preferred 270 address causes hardship to a specific upper-layer activity (e.g., 271 an existing TCP connection). 273 valid address - a preferred or deprecated address. A valid address 274 may appear as the source or destination address of a packet, and 275 the internet routing system is expected to deliver packets sent to 276 a valid address to their intended recipients. 278 invalid address - an address that is not assigned to any interface. A 279 valid address becomes invalid when its valid lifetime expires. 280 Invalid addresses should not appear as the destination or source 281 address of a packet. In the former case, the internet routing 282 system will be unable to deliver the packet, in the latter case 283 the recipient of the packet will be unable to respond to it. 285 preferred lifetime - the length of time that a valid address is 286 preferred (i.e., the time until deprecation). When the preferred 287 lifetime expires, the address becomes deprecated. 289 valid lifetime - the length of time an address remains in the valid 290 state (i.e., the time until invalidation). The valid lifetime must 291 be greater than or equal to the preferred lifetime. When the 292 valid lifetime expires, the address becomes invalid. 294 interface identifier - a link-dependent identifier for an interface 295 that is (at least) unique per link [4]. Stateless address 296 autoconfiguration combines an interface identifier with a prefix 297 to form an address. From address autoconfiguration's perspective, 298 an interface identifier is a bit string of known length. The exact 299 length of an interface identifier and the way it is created is 300 defined in a separate link-type specific document that covers 301 issues related to the transmission of IP over a particular link 302 type (e.g., IPv6 over Ethernet [2]). Note that the address 303 architecture [4] also defines the length of the interface 304 identifiers for some set of addresses, but the two sets of 305 definitions must be consistent. In many cases, the identifier will 306 be derived from the interface's link-layer address. 308 2.1 Requirements 310 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 311 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 312 document, are to be interpreted as described in RFC 2119 [3]. 314 3. DESIGN GOALS 316 Stateless autoconfiguration is designed with the following goals in 317 mind: 319 o Manual configuration of individual machines before connecting them 320 to the network should not be required. Consequently, a mechanism 321 is needed that allows a host to obtain or create unique addresses 322 for each of its interfaces. Address autoconfiguration assumes that 323 each interface can provide a unique identifier for that interface 324 (i.e., an "interface identifier"). In the simplest case, an 325 interface identifier consists of the interface's link-layer 326 address. An interface identifier can be combined with a prefix to 327 form an address. 329 o Small sites consisting of a set of machines attached to a single 330 link should not require the presence of a stateful server or 331 router as a prerequisite for communicating. Plug-and-play 332 communication is achieved through the use of link-local addresses. 333 Link-local addresses have a well-known prefix that identifies the 334 (single) shared link to which a set of nodes attach. A host forms 335 a link-local address by appending its interface identifier to the 336 link-local prefix. 338 o A large site with multiple networks and routers should not require 339 the presence of a stateful address configuration server. In order 340 to generate global addresses, hosts must determine the prefixes 341 that identify the subnets to which they attach. Routers generate 342 periodic Router Advertisements that include options listing the 343 set of active prefixes on a link. 345 o Address configuration should facilitate the graceful renumbering 346 of a site's machines. For example, a site may wish to renumber all 347 of its nodes when it switches to a new network service provider. 348 Renumbering is achieved through the leasing of addresses to 349 interfaces and the assignment of multiple addresses to the same 350 interface. Lease lifetimes provide the mechanism through which a 351 site phases out old prefixes. The assignment of multiple 352 addresses to an interface provides for a transition period during 353 which both a new address and the one being phased out work 354 simultaneously. 356 o System administrators need the ability to specify whether 357 stateless autoconfiguration, stateful autoconfiguration, or both 358 are available. Router Advertisements include flags specifying 359 which mechanisms a host can use. 361 4. PROTOCOL OVERVIEW 363 This section provides an overview of the typical steps that take 364 place when an interface autoconfigures itself. Autoconfiguration is 365 performed only on multicast-capable links and begins when a 366 multicast-capable interface is enabled, e.g., during system startup. 367 Nodes (both hosts and routers) begin the autoconfiguration process by 368 generating a link-local address for the interface. A link-local 369 address is formed by appending the interface's identifier to the 370 well-known link-local prefix. 372 Before the link-local address can be assigned to an interface and 373 used, however, a node must attempt to verify that this "tentative" 374 address is not already in use by another node on the link. 375 Specifically, it sends a Neighbor Solicitation message containing the 376 tentative address as the target. If another node is already using 377 that address, it will return a Neighbor Advertisement saying so. If 378 another node is also attempting to use the same address, it will send 379 a Neighbor Solicitation for the target as well. The exact number of 380 times the Neighbor Solicitation is (re)transmitted and the delay time 381 between consecutive solicitations is link-specific and may be set by 382 system management. 384 If a node determines that its tentative link-local address is not 385 unique, autoconfiguration stops and manual configuration of the 386 interface is required. To simplify recovery in this case, it should 387 be possible for an administrator to supply an alternate interface 388 identifier that overrides the default identifier in such a way that 389 the autoconfiguration mechanism can then be applied using the new 390 (presumably unique) interface identifier. Alternatively, link-local 391 and other addresses will need to be configured manually. 393 Once a node ascertains that its tentative link-local address is 394 unique, it assigns the address to the interface. At this point, the 395 node has IP-level connectivity with neighboring nodes. The remaining 396 autoconfiguration steps are performed only by hosts; the 397 (auto)configuration of routers is beyond the scope of this document. 399 The next phase of autoconfiguration involves obtaining a Router 400 Advertisement or determining that no routers are present. If routers 401 are present, they will send Router Advertisements that specify what 402 sort of autoconfiguration a host can do. Note that stateful 403 autoconfiguration may still be available even if no routers are 404 present. 406 Routers send Router Advertisements periodically, but the delay 407 between successive advertisements will generally be longer than a 408 host performing autoconfiguration will want to wait [5]. To obtain an 409 advertisement quickly, a host sends one or more Router Solicitations 410 to the all-routers multicast group. Router Advertisements contain two 411 flags indicating what type of stateful autoconfiguration (if any) is 412 available. A "managed address configuration (M)" flag indicates 413 whether hosts can use stateful autoconfiguration [7] to obtain 414 addresses. An "other stateful configuration (O)" flag indicates 415 whether hosts can use stateful autoconfiguration [8] to obtain 416 additional information (excluding addresses). 418 The details of how a host may use the M flags, including any use of 419 the "on" and "off" transitions for this flag, to control the use of 420 the stateful protocol for address assignment will be described in a 421 separate document. Similarly, the details of how a host may use the O 422 flags, including any use of the "on" and "off" transitions for this 423 flag, to control the use of the stateful protocol for getting other 424 configuration information will be described in a separate document. 426 Router Advertisements also contain zero or more Prefix Information 427 options that contain information used by stateless address 428 autoconfiguration to generate global addresses. It should be noted 429 that the stateless and stateful address autoconfiguration fields in 430 Router Advertisements are processed independently of one another, and 431 a host may use both stateful and stateless address autoconfiguration 432 simultaneously. One Prefix Information option field, the "autonomous 433 address-configuration flag", indicates whether or not the option even 434 applies to stateless autoconfiguration. If it does, additional 435 option fields contain a subnet prefix together with lifetime values 436 indicating how long addresses created from the prefix remain 437 preferred and valid. 439 Because routers generate Router Advertisements periodically, hosts 440 will continually receive new advertisements. Hosts process the 441 information contained in each advertisement as described above, 442 adding to and refreshing information received in previous 443 advertisements. 445 For safety, all addresses must be tested for uniqueness prior to 446 their assignment to an interface. The test should individually be 447 performed on all addresses obtained manually, via stateless address 448 autoconfiguration, or via stateful address autoconfiguration. To 449 accommodate sites that believe the overhead of performing Duplicate 450 Address Detection outweighs its benefits, the use of Duplicate 451 Address Detection can be disabled through the administrative setting 452 of a per-interface configuration flag. 454 To speed the autoconfiguration process, a host may generate its 455 link-local address (and verify its uniqueness) in parallel with 456 waiting for a Router Advertisement. Because a router may delay 457 responding to a Router Solicitation for a few seconds, the total time 458 needed to complete autoconfiguration can be significantly longer if 459 the two steps are done serially. 461 4.1 Site Renumbering 463 Address leasing facilitates site renumbering by providing a mechanism 464 to time-out addresses assigned to interfaces in hosts. At present, 465 upper layer protocols such as TCP provide no support for changing 466 end-point addresses while a connection is open. If an end-point 467 address becomes invalid, existing connections break and all 468 communication to the invalid address fails. Even when applications 469 use UDP as a transport protocol, addresses must generally remain the 470 same during a packet exchange. 472 Dividing valid addresses into preferred and deprecated categories 473 provides a way of indicating to upper layers that a valid address may 474 become invalid shortly and that future communication using the 475 address will fail, should the address's valid lifetime expire before 476 communication ends. To avoid this scenario, higher layers should use 477 a preferred address (assuming one of sufficient scope exists) to 478 increase the likelihood that an address will remain valid for the 479 duration of the communication. It is up to system administrators to 480 set appropriate prefix lifetimes in order to minimize the impact of 481 failed communication when renumbering takes place. The deprecation 482 period should be long enough that most, if not all, communications 483 are using the new address at the time an address becomes invalid. 485 The IP layer is expected to provide a means for upper layers 486 (including applications) to select the most appropriate source 487 address given a particular destination and possibly other 488 constraints. An application may choose to select the source address 489 itself before starting a new communication or may leave the address 490 unspecified, in which case the upper networking layers will use the 491 mechanism provided by the IP layer to choose a suitable address on 492 the application's behalf. 494 Detailed address selection rules are beyond the scope of this 495 document. 497 5. PROTOCOL SPECIFICATION 499 Autoconfiguration is performed on a per-interface basis on 500 multicast-capable interfaces. For multihomed hosts, 501 autoconfiguration is performed independently on each interface. 502 Autoconfiguration applies primarily to hosts, with two exceptions. 503 Routers are expected to generate a link-local address using the 504 procedure outlined below. In addition, routers perform Duplicate 505 Address Detection on all addresses prior to assigning them to an 506 interface. 508 5.1 Node Configuration Variables 510 A node MUST allow the following autoconfiguration-related variable to 511 be configured by system management for each multicast interface: 513 DupAddrDetectTransmits 515 The number of consecutive Neighbor Solicitation messages sent 516 while performing Duplicate Address Detection on a tentative 517 address. A value of zero indicates that Duplicate Address 518 Detection is not performed on tentative addresses. A value of one 519 indicates a single transmission with no follow up retransmissions. 521 Default: 1, but may be overridden by a link-type specific value in 522 the document that covers issues related to the transmission of IP 523 over a particular link type (e.g., IPv6 over Ethernet [2]). 525 Autoconfiguration also assumes the presence of the variable 526 RetransTimer as defined in RFC 2461 [5]. For autoconfiguration 527 purposes, RetransTimer specifies the delay between consecutive 528 Neighbor Solicitation transmissions performed during Duplicate 529 Address Detection (if DupAddrDetectTransmits is greater than 1), 530 as well as the time a node waits after sending the last Neighbor 531 Solicitation before ending the Duplicate Address Detection 532 process. 534 5.2 Autoconfiguration-Related Structures 536 Beyond the formation of a link-local address and using Duplicate 537 Address Detection, how routers (auto)configure their interfaces is 538 beyond the scope of this document. 540 A host maintains a list of addresses together with their 541 corresponding lifetimes. The address list contains both 542 autoconfigured addresses and those configured manually. 544 5.3 Creation of Link-Local Addresses 546 A node forms a link-local address whenever an interface becomes 547 enabled. An interface may become enabled after any of the following 548 events: 550 - The interface is initialized at system startup time. 552 - The interface is reinitialized after a temporary interface failure 553 or after being temporarily disabled by system management. 555 - The interface attaches to a link for the first time. 557 - The interface becomes enabled by system management after having 558 been administratively disabled. 560 A link-local address is formed by prepending the well-known link- 561 local prefix FE80::0 [4] (of appropriate length) to the interface 562 identifier. If the interface identifier has a length of N bits, the 563 interface identifier replaces the right-most N zero bits of the 564 link-local prefix. If the interface identifier is more than 118 bits 565 in length, autoconfiguration fails and manual configuration is 566 required. The length of the interface identifier is defined in a 567 separate link-type specific document, which should also be consistent 568 with the address architecture [4] (see Section 2). These documents 569 will carefully define the length so that link-local addresses can be 570 autoconfigured on the link. 572 A link-local address has an infinite preferred and valid lifetime; it 573 is never timed out. 575 5.4 Duplicate Address Detection 577 Duplicate Address Detection is performed on unicast addresses prior 578 to assigning them to an interface whose DupAddrDetectTransmits 579 variable is greater than zero. Duplicate Address Detection MUST take 580 place on all unicast addresses, regardless of whether they are 581 obtained through stateful, stateless or manual configuration, with 582 the exception of the following cases: 584 IP - Duplicate Address Detection MUST NOT be performed on anycast 585 addresses. 587 IP - Each individual unicast address SHOULD be tested for uniqueness. 588 Note that there are implementations deployed that only perform 589 Duplicate Address Detection for the link-local address and skip 590 the test for the global address using the same interface 591 identifier as that of the link-local address. Whereas this 592 document does not invalidate such implementations, this kind of 593 "optimization" is NOT RECOMMENDED, and new implementations MUST 594 NOT do that optimization. This optimization came from the 595 assumption that all of an interface's addresses are generated from 596 the same identifier. However, the assumption does actually not 597 stand; new types of addresses have been introduced where the 598 interface identifiers are not necessarily the same for all unicast 599 addresses on a single interface [10] [11]. Requiring to perform 600 Duplicate Address Detection for all unicast addresses will make 601 the algorithm robust for the current and future such special 602 interface identifiers. 604 The procedure for detecting duplicate addresses uses Neighbor 605 Solicitation and Advertisement messages as described below. If a 606 duplicate address is discovered during the procedure, the address 607 cannot be assigned to the interface. If the address is derived from 608 an interface identifier, a new identifier will need to be assigned to 609 the interface, or all IP addresses for the interface will need to be 610 manually configured. Note that the method for detecting duplicates 611 is not completely reliable, and it is possible that duplicate 612 addresses will still exist (e.g., if the link was partitioned while 613 Duplicate Address Detection was performed). 615 An address on which the Duplicate Address Detection Procedure is 616 applied is said to be tentative until the procedure has completed 617 successfully. A tentative address is not considered "assigned to an 618 interface" in the traditional sense. That is, the interface must 619 accept Neighbor Solicitation and Advertisement messages containing 620 the tentative address in the Target Address field, but processes such 621 packets differently from those whose Target Address matches an 622 address assigned to the interface. Other packets addressed to the 623 tentative address should be silently discarded. Note that the "other 624 packets" include Neighbor Solicitation and Advertisement messages to 625 the tentative address containing the tentative address in the Target 626 Address field. Such a case should not happen in normal operation, 627 though, since these messages are multicasted in the Duplicate Address 628 Detection Procedure. 630 It should also be noted that Duplicate Address Detection must be 631 performed prior to assigning an address to an interface in order to 632 prevent multiple nodes from using the same address simultaneously. If 633 a node begins using an address in parallel with Duplicate Address 634 Detection, and another node is already using the address, the node 635 performing Duplicate Address Detection will erroneously process 636 traffic intended for the other node, resulting in such possible 637 negative consequences as the resetting of open TCP connections. 639 The following subsections describe specific tests a node performs to 640 verify an address's uniqueness. An address is considered unique if 641 none of the tests indicate the presence of a duplicate address within 642 RetransTimer milliseconds after having sent DupAddrDetectTransmits 643 Neighbor Solicitations. Once an address is determined to be unique, 644 it may be assigned to an interface. 646 5.4.1 Message Validation 648 A node MUST silently discard any Neighbor Solicitation or 649 Advertisement message that does not pass the validity checks 650 specified in RFC 2461 [5]. A Neighbor Solicitation or Advertisement 651 message that passes these validity checks is called a valid 652 solicitation or valid advertisement, respectively. 654 5.4.2 Sending Neighbor Solicitation Messages 656 Before sending a Neighbor Solicitation, an interface MUST join the 657 all-nodes multicast address and the solicited-node multicast address 658 of the tentative address. The former ensures that the node receives 659 Neighbor Advertisements from other nodes already using the address; 660 the latter ensures that two nodes attempting to use the same address 661 simultaneously detect each other's presence. 663 To check an address, a node sends DupAddrDetectTransmits Neighbor 664 Solicitations, each separated by RetransTimer milliseconds. The 665 solicitation's Target Address is set to the address being checked, 666 the IP source is set to the unspecified address and the IP 667 destination is set to the solicited-node multicast address of the 668 target address. 670 If the Neighbor Solicitation is going to be the first message to be 671 sent from an interface after interface (re)initialization, the node 672 SHOULD delay joining the solicited-node multicast address by a random 673 delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in RFC 674 2461 [5]. This serves to alleviate congestion when many nodes start 675 up on the link at the same time, such as after a power failure, and 676 may help to avoid race conditions when more than one node is trying 677 to solicit for the same address at the same time. 679 Even if the Neighbor Solicitation is not going to be the first 680 message to be sent, the node SHOULD delay joining the solicited-node 681 multicast address by a random delay between 0 and 682 MAX_RTR_SOLICITATION_DELAY if the address being checked is configured 683 by a router advertisement message sent to a multicast address. The 684 delay will avoid similar congestion when multiple nodes are going to 685 configure addresses by receiving a same single multicast router 686 advertisement. 688 Note that the delay for joining the multicast address implicitly 689 means delaying transmission of the corresponding MLD report message 690 [12]. Since RFC 2710 [12] does not request a random delay to avoid 691 race conditions, just delaying Neighbor Solicitation would cause 692 congestion by the MLD report messages. The congestion would then 693 prevent MLD-snooping switches from working correctly, and, as a 694 result, prevent Duplicate Address Detection from working. The 695 requirement to include the delay for the MLD report in this case 696 avoids this scenario. 698 In order to improve the robustness of the Duplicate Address Detection 699 algorithm, an interface MUST receive and process datagrams sent to 700 the all-nodes multicast address or solicited-node multicast address 701 of the tentative address while the delaying period. This does not 702 necessarily conflict with the requirement that joining the multicast 703 group be delayed. In fact, in some cases it is possible for a node to 704 start listening to the group during the delay period before MLD 705 report transmission. It should be noted, however, that in some 706 link-layer environments, particularly with MLD-snooping switches, no 707 multicast reception will be available until the MLD report is sent. 709 5.4.3 Receiving Neighbor Solicitation Messages 711 On receipt of a valid Neighbor Solicitation message on an interface, 712 node behavior depends on whether the target address is tentative or 713 not. If the target address is not tentative (i.e., it is assigned to 714 the receiving interface), the solicitation is processed as described 715 in RFC 2461 [5]. If the target address is tentative, and the source 716 address is a unicast address, the solicitation's sender is performing 717 address resolution on the target; the solicitation should be silently 718 ignored. Otherwise, processing takes place as described below. In 719 all cases, a node MUST NOT respond to a Neighbor Solicitation for a 720 tentative address. 722 If the source address of the Neighbor Solicitation is the unspecified 723 address, the solicitation is from a node performing Duplicate Address 724 Detection. If the solicitation is from another node, the tentative 725 address is a duplicate and should not be used (by either node). If 726 the solicitation is from the node itself (because the node loops back 727 multicast packets), the solicitation does not indicate the presence 728 of a duplicate address. 730 Implementor's Note: many interfaces provide a way for upper layers to 731 selectively enable and disable the looping back of multicast packets. 732 The details of how such a facility is implemented may prevent 733 Duplicate Address Detection from working correctly. See the Appendix 734 A for further discussion. 736 The following tests identify conditions under which a tentative 737 address is not unique: 739 - If a Neighbor Solicitation for a tentative address is received 740 prior to having sent one, the tentative address is a duplicate. 741 This condition occurs when two nodes run Duplicate Address 742 Detection simultaneously, but transmit initial solicitations at 743 different times (e.g., by selecting different random delay values 744 before joining the solicited-node multicast address and 745 transmitting an initial solicitation). 747 - If the actual number of Neighbor Solicitations received exceeds 748 the number expected based on the loopback semantics (e.g., the 749 interface does not loopback packet, yet one or more solicitations 750 was received), the tentative address is a duplicate. This 751 condition occurs when two nodes run Duplicate Address Detection 752 simultaneously and transmit solicitations at roughly the same 753 time. 755 5.4.4 Receiving Neighbor Advertisement Messages 757 On receipt of a valid Neighbor Advertisement message on an interface, 758 node behavior depends on whether the target address is tentative or 759 matches a unicast or anycast address assigned to the interface. If 760 the target address is assigned to the receiving interface, the 761 solicitation is processed as described in RFC 2461 [5]. If the target 762 address is tentative, the tentative address is not unique. 764 5.4.5 When Duplicate Address Detection Fails 766 A tentative address that is determined to be a duplicate as described 767 above MUST NOT be assigned to an interface and the node SHOULD log a 768 system management error. If the address is a link-local address 769 formed from an interface identifier based on the hardware address 770 (e.g., EUI-64), the interface SHOULD be disabled. In this case, the 771 IP address duplication probably means duplicate hardware addresses 772 are in use, and trying to recover from it by configuring another IP 773 address will not result in a usable network. In fact, it probably 774 makes things worse by creating problems that are harder to diagnose 775 than just shutting down the interface; the user will see a partially 776 working network where some things work, and other things will not. On 777 the other hand, if the duplicated link-local address is not formed 778 from an interface identifier based on the hardware address, the 779 interface MAY continue to be used. 781 5.5 Creation of Global Addresses 783 Global addresses are formed by appending an interface identifier to a 784 prefix of appropriate length. Prefixes are obtained from Prefix 785 Information options contained in Router Advertisements. Creation of 786 global addresses and configuration of other parameters as described 787 in this section SHOULD be locally configurable. However, the 788 processing described below MUST be enabled by default. 790 5.5.1 Soliciting Router Advertisements 792 Router Advertisements are sent periodically to the all-nodes 793 multicast address. To obtain an advertisement quickly, a host sends 794 out Router Solicitations as described in RFC 2461 [5]. 796 5.5.2 Absence of Router Advertisements 798 Even if a link has no routers, stateful autoconfiguration to obtain 799 addresses and other configuration information may still be available, 800 and hosts may want to use the mechanism.