idnits 2.17.1 draft-ietf-ipv6-rfc2462bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 39), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 313: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 314: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 514: '... A node MUST allow the following aut...' RFC 2119 keyword, line 584: '... Duplicate Address Detection MUST take...' RFC 2119 keyword, line 589: '...ddress Detection MUST NOT be performed...' (24 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 (July 19, 2004) is 7221 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? 'RFC3315' on line 417 looks like a reference -- Missing reference section? 'RFC3736' on line 419 looks like a reference -- Missing reference section? 'RFC2461' on line 877 looks like a reference -- Missing reference section? 'RFC3513' on line 883 looks like a reference -- Missing reference section? 'RFC2464' on line 527 looks like a reference -- Missing reference section? 'RFC2119' on line 316 looks like a reference -- Missing reference section? 'RFC3041' on line 604 looks like a reference -- Missing reference section? 'I-D.ietf-send-cga' on line 604 looks like a reference -- Missing reference section? 'RFC2710' on line 696 looks like a reference -- Missing reference section? 'RFC2402' on line 913 looks like a reference -- Missing reference section? 'RFC3484' on line 976 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 14 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: January 17, 2005 T. Narten 4 IBM 5 T. Jinmei 6 Toshiba 7 July 19, 2004 9 IPv6 Stateless Address Autoconfiguration 10 draft-ietf-ipv6-rfc2462bis-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 or will be disclosed, and any of which I become aware will be 17 disclosed, in accordance with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 17, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This document specifies the steps a host takes in deciding how to 44 autoconfigure its interfaces in IP version 6. The autoconfiguration 45 process includes creating a link-local address and verifying its 46 uniqueness on a link, determining what information can be 47 autoconfigured (addresses, other information, or both), and in the 48 case of addresses, whether they can be obtained through the stateless 49 mechanism, the stateful mechanism, or both. This document defines 50 the process for generating a link-local address, the process for 51 generating global addresses via stateless address autoconfiguration, 52 and the Duplicate Address Detection procedure. The details of 53 autoconfiguration using the stateful protocol is specified in RFC 54 3315 and RFC 3736. 56 Table of Contents 58 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. TERMINOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 61 3. DESIGN GOALS . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. PROTOCOL OVERVIEW . . . . . . . . . . . . . . . . . . . . . . 8 63 4.1 Site Renumbering . . . . . . . . . . . . . . . . . . . . . 10 64 5. PROTOCOL SPECIFICATION . . . . . . . . . . . . . . . . . . . . 11 65 5.1 Node Configuration Variables . . . . . . . . . . . . . . . 11 66 5.2 Autoconfiguration-Related Structures . . . . . . . . . . . 12 67 5.3 Creation of Link-Local Addresses . . . . . . . . . . . . . 12 68 5.4 Duplicate Address Detection . . . . . . . . . . . . . . . 13 69 5.4.1 Message Validation . . . . . . . . . . . . . . . . . . 14 70 5.4.2 Sending Neighbor Solicitation Messages . . . . . . . . 14 71 5.4.3 Receiving Neighbor Solicitation Messages . . . . . . . 16 72 5.4.4 Receiving Neighbor Advertisement Messages . . . . . . 17 73 5.4.5 When Duplicate Address Detection Fails . . . . . . . . 17 74 5.5 Creation of Global Addresses . . . . . . . . . . . . . . . 17 75 5.5.1 Soliciting Router Advertisements . . . . . . . . . . . 18 76 5.5.2 Absence of Router Advertisements . . . . . . . . . . . 18 77 5.5.3 Router Advertisement Processing . . . . . . . . . . . 18 78 5.5.4 Address Lifetime Expiry . . . . . . . . . . . . . . . 20 79 5.6 Configuration Consistency . . . . . . . . . . . . . . . . 21 80 5.7 Retaining Configured Addresses for Stability . . . . . . . 22 81 6. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . 22 82 7. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . 22 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 85 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 86 9.2 Informative References . . . . . . . . . . . . . . . . . . . 23 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 88 A. LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION . . . . . . 25 89 B. CHANGES SINCE RFC 1971 . . . . . . . . . . . . . . . . . . . . 26 90 C. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . . . . . . 26 91 Intellectual Property and Copyright Statements . . . . . . . . 29 93 1. INTRODUCTION 95 This document specifies the steps a host takes in deciding how to 96 autoconfigure its interfaces in IP version 6 (IPv6). The 97 autoconfiguration process includes creating a link-local address and 98 verifying its uniqueness on a link, determining what information can 99 be autoconfigured (addresses, other information, or both), and in the 100 case of addresses, whether they can be obtained through the stateless 101 mechanism, the stateful mechanism, or both. This document defines 102 the process for generating a link-local address, the process for 103 generating global addresses via stateless address autoconfiguration, 104 and the Duplicate Address Detection procedure. The details of 105 autoconfiguration using the stateful protocol is specified in 106 [RFC3315] and [RFC3736]. 108 IPv6 defines both a stateful and stateless address autoconfiguration 109 mechanism. Stateless autoconfiguration requires no manual 110 configuration of hosts, minimal (if any) configuration of routers, 111 and no additional servers. The stateless mechanism allows a host to 112 generate its own addresses using a combination of locally available 113 information and information advertised by routers. Routers advertise 114 prefixes that identify the subnet(s) associated with a link, while 115 hosts generate an "interface identifier" that uniquely identifies an 116 interface on a subnet. An address is formed by combining the two. 117 In the absence of routers, a host can only generate link-local 118 addresses. However, link-local addresses are sufficient for allowing 119 communication among nodes attached to the same link. 121 In the stateful autoconfiguration model, hosts obtain interface 122 addresses and/or configuration information and parameters from a 123 Dynamic Host Configuration Protocol (DHCPv6) server. Servers 124 maintain a database that keeps track of which addresses have been 125 assigned to which hosts. The stateful autoconfiguration protocol 126 allows hosts to obtain addresses, other configuration information or 127 both from a server. Stateless and stateful autoconfiguration 128 complement each other. For example, a host can use stateless 129 autoconfiguration to configure its own addresses, but use stateful 130 autoconfiguration to obtain other information. 132 To obtain other configuration information without configuring 133 addresses in the stateful autoconfiguration model, a subset of DHCPv6 134 [RFC3736] will be used. While the model is called "stateful" here in 135 order to highlight the contrast to the stateless protocol defined in 136 this document, the intended protocol is also defined to work in a 137 stateless fashion. This is based on a result, through operational 138 experiments, that all known "other" configuration information can be 139 managed by a stateless server, that is, a server that does not 140 maintain state of each client that the server provides with the 141 configuration information. 143 The stateless approach is used when a site is not particularly 144 concerned with the exact addresses hosts use, so long as they are 145 unique and properly routable. The stateful approach is used when a 146 site requires tighter control over exact address assignments. Both 147 stateful and stateless address autoconfiguration may be used 148 simultaneously. The site administrator specifies which type of 149 autoconfiguration is available through the setting of appropriate 150 fields in Router Advertisement messages [RFC2461]. 152 IPv6 addresses are leased to an interface for a fixed (possibly 153 infinite) length of time. Each address has an associated lifetime 154 that indicates how long the address is bound to an interface. When a 155 lifetime expires, the binding (and address) become invalid and the 156 address may be reassigned to another interface elsewhere in the 157 Internet. To handle the expiration of address bindings gracefully, 158 an address goes through two distinct phases while assigned to an 159 interface. Initially, an address is "preferred", meaning that its 160 use in arbitrary communication is unrestricted. Later, an address 161 becomes "deprecated" in anticipation that its current interface 162 binding will become invalid. While in a deprecated state, the use of 163 an address is discouraged, but not strictly forbidden. New 164 communication (e.g., the opening of a new TCP connection) should use 165 a preferred address when possible. A deprecated address should be 166 used only by applications that have been using it and would have 167 difficulty switching to another address without a service disruption. 169 To ensure that all configured addresses are likely to be unique on a 170 given link, nodes run a "duplicate address detection" algorithm on 171 addresses before assigning them to an interface. The Duplicate 172 Address Detection algorithm is performed on all addresses, 173 independent of whether they are obtained via stateless or stateful 174 autoconfiguration. This document defines the Duplicate Address 175 Detection algorithm. 177 The autoconfiguration process specified in this document applies only 178 to hosts and not routers. Since host autoconfiguration uses 179 information advertised by routers, routers will need to be configured 180 by some other means. However, it is expected that routers will 181 generate link-local addresses using the mechanism described in this 182 document. In addition, routers are expected to successfully pass the 183 Duplicate Address Detection procedure described in this document on 184 all addresses prior to assigning them to an interface. 186 Section 2 provides definitions for terminology used throughout this 187 document. Section 3 describes the design goals that lead to the 188 current autoconfiguration procedure. Section 4 provides an overview 189 of the protocol, while Section 5 describes the protocol in detail. 191 2. TERMINOLOGY 193 IP - Internet Protocol Version 6. The terms IPv4 and IPv6 are used 194 only in contexts where necessary to avoid ambiguity. 196 node - a device that implements IP. 198 router - a node that forwards IP packets not explicitly addressed to 199 itself. 201 host - any node that is not a router. 203 upper layer - a protocol layer immediately above IP. Examples are 204 transport protocols such as TCP and UDP, control protocols such as 205 ICMP, routing protocols such as OSPF, and internet or lower-layer 206 protocols being "tunneled" over (i.e., encapsulated in) IP such as 207 IPX, AppleTalk, or IP itself. 209 link - a communication facility or medium over which nodes can 210 communicate at the link layer, i.e., the layer immediately below 211 IP. Examples are Ethernets (simple or bridged); PPP links; X.25, 212 Frame Relay, or ATM networks; and internet (or higher) layer 213 "tunnels", such as tunnels over IPv4 or IPv6 itself. 215 interface - a node's attachment to a link. 217 packet - an IP header plus payload. 219 address - an IP-layer identifier for an interface or a set of 220 interfaces. 222 unicast address - an identifier for a single interface. A packet 223 sent to a unicast address is delivered to the interface identified 224 by that address. 226 multicast address - an identifier for a set of interfaces (typically 227 belonging to different nodes). A packet sent to a multicast 228 address is delivered to all interfaces identified by that address. 230 anycast address - an identifier for a set of interfaces (typically 231 belonging to different nodes). A packet sent to an anycast 232 address is delivered to one of the interfaces identified by that 233 address (the "nearest" one, according to the routing protocol's 234 measure of distance). See [RFC3513]. 236 solicited-node multicast address - a multicast address to which 237 Neighbor Solicitation messages are sent. The algorithm for 238 computing the address is given in [RFC3513]. 240 link-layer address - a link-layer identifier for an interface. 241 Examples include IEEE 802 addresses for Ethernet links and E.164 242 addresses for ISDN links. 244 link-local address - an address having link-only scope that can be 245 used to reach neighboring nodes attached to the same link. All 246 interfaces have a link-local unicast address. 248 global address - an address with unlimited scope. 250 communication - any packet exchange among nodes that requires that 251 the address of each node used in the exchange remain the same for 252 the duration of the packet exchange. Examples are a TCP 253 connection or a UDP request-response. 255 tentative address - an address whose uniqueness on a link is being 256 verified, prior to its assignment to an interface. A tentative 257 address is not considered assigned to an interface in the usual 258 sense. An interface discards received packets addressed to a 259 tentative address, but accepts Neighbor Discovery packets related 260 to Duplicate Address Detection for the tentative address. 262 preferred address - an address assigned to an interface whose use by 263 upper layer protocols is unrestricted. Preferred addresses may be 264 used as the source (or destination) address of packets sent from 265 (or to) the interface. 267 deprecated address - An address assigned to an interface whose use is 268 discouraged, but not forbidden. A deprecated address should no 269 longer be used as a source address in new communications, but 270 packets sent from or to deprecated addresses are delivered as 271 expected. A deprecated address may continue to be used as a 272 source address in communications where switching to a preferred 273 address causes hardship to a specific upper-layer activity (e.g., 274 an existing TCP connection). 276 valid address - a preferred or deprecated address. A valid address 277 may appear as the source or destination address of a packet, and 278 the internet routing system is expected to deliver packets sent to 279 a valid address to their intended recipients. 281 invalid address - an address that is not assigned to any interface. 282 A valid address becomes invalid when its valid lifetime expires. 283 Invalid addresses should not appear as the destination or source 284 address of a packet. In the former case, the internet routing 285 system will be unable to deliver the packet, in the latter case 286 the recipient of the packet will be unable to respond to it. 288 preferred lifetime - the length of time that a valid address is 289 preferred (i.e., the time until deprecation). When the preferred 290 lifetime expires, the address becomes deprecated. 292 valid lifetime - the length of time an address remains in the valid 293 state (i.e., the time until invalidation). The valid lifetime 294 must be greater than or equal to the preferred lifetime. When the 295 valid lifetime expires, the address becomes invalid. 297 interface identifier - a link-dependent identifier for an interface 298 that is (at least) unique per link [RFC3513]. Stateless address 299 autoconfiguration combines an interface identifier with a prefix 300 to form an address. From address autoconfiguration's perspective, 301 an interface identifier is a bit string of known length. The 302 exact length of an interface identifier and the way it is created 303 is defined in a separate link-type specific document that covers 304 issues related to the transmission of IP over a particular link 305 type (e.g., [RFC2464]). Note that the address architecture 306 [RFC3513] also defines the length of the interface identifiers for 307 some set of addresses, but the two sets of definitions must be 308 consistent. In many cases, the identifier will be derived from 309 the interface's link-layer address. 311 2.1 Requirements 313 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 314 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 315 document, are to be interpreted as described in [RFC2119]. 317 3. DESIGN GOALS 319 Stateless autoconfiguration is designed with the following goals in 320 mind: 322 o Manual configuration of individual machines before connecting them 323 to the network should not be required. Consequently, a mechanism 324 is needed that allows a host to obtain or create unique addresses 325 for each of its interfaces. Address autoconfiguration assumes 326 that each interface can provide a unique identifier for that 327 interface (i.e., an "interface identifier"). In the simplest 328 case, an interface identifier consists of the interface's 329 link-layer address. An interface identifier can be combined with 330 a prefix to form an address. 332 o Small sites consisting of a set of machines attached to a single 333 link should not require the presence of a stateful server or 334 router as a prerequisite for communicating. Plug-and-play 335 communication is achieved through the use of link-local addresses. 336 Link-local addresses have a well-known prefix that identifies the 337 (single) shared link to which a set of nodes attach. A host forms 338 a link-local address by appending its interface identifier to the 339 link-local prefix. 341 o A large site with multiple networks and routers should not require 342 the presence of a stateful address configuration server. In order 343 to generate global addresses, hosts must determine the prefixes 344 that identify the subnets to which they attach. Routers generate 345 periodic Router Advertisements that include options listing the 346 set of active prefixes on a link. 348 o Address configuration should facilitate the graceful renumbering 349 of a site's machines. For example, a site may wish to renumber 350 all of its nodes when it switches to a new network service 351 provider. Renumbering is achieved through the leasing of 352 addresses to interfaces and the assignment of multiple addresses 353 to the same interface. Lease lifetimes provide the mechanism 354 through which a site phases out old prefixes. The assignment of 355 multiple addresses to an interface provides for a transition 356 period during which both a new address and the one being phased 357 out work simultaneously. 359 o System administrators need the ability to specify whether 360 stateless autoconfiguration, stateful autoconfiguration, or both 361 are available. Router Advertisements include flags specifying 362 which mechanisms a host can use. 364 4. PROTOCOL OVERVIEW 366 This section provides an overview of the typical steps that take 367 place when an interface autoconfigures itself. Autoconfiguration is 368 performed only on multicast-capable links and begins when a 369 multicast-capable interface is enabled, e.g., during system startup. 370 Nodes (both hosts and routers) begin the autoconfiguration process by 371 generating a link-local address for the interface. A link-local 372 address is formed by appending the interface's identifier to the 373 well-known link-local prefix. 375 Before the link-local address can be assigned to an interface and 376 used, however, a node must attempt to verify that this "tentative" 377 address is not already in use by another node on the link. 378 Specifically, it sends a Neighbor Solicitation message containing the 379 tentative address as the target. If another node is already using 380 that address, it will return a Neighbor Advertisement saying so. If 381 another node is also attempting to use the same address, it will send 382 a Neighbor Solicitation for the target as well. The exact number of 383 times the Neighbor Solicitation is (re)transmitted and the delay time 384 between consecutive solicitations is link-specific and may be set by 385 system management. 387 If a node determines that its tentative link-local address is not 388 unique, autoconfiguration stops and manual configuration of the 389 interface is required. To simplify recovery in this case, it should 390 be possible for an administrator to supply an alternate interface 391 identifier that overrides the default identifier in such a way that 392 the autoconfiguration mechanism can then be applied using the new 393 (presumably unique) interface identifier. Alternatively, link-local 394 and other addresses will need to be configured manually. 396 Once a node ascertains that its tentative link-local address is 397 unique, it assigns the address to the interface. At this point, the 398 node has IP-level connectivity with neighboring nodes. The remaining 399 autoconfiguration steps are performed only by hosts; the 400 (auto)configuration of routers is beyond the scope of this document. 402 The next phase of autoconfiguration involves obtaining a Router 403 Advertisement or determining that no routers are present. If routers 404 are present, they will send Router Advertisements that specify what 405 sort of autoconfiguration a host can do. Note that stateful 406 autoconfiguration may still be available even if no routers are 407 present. 409 Routers send Router Advertisements periodically, but the delay 410 between successive advertisements will generally be longer than a 411 host performing autoconfiguration will want to wait [RFC2461]. To 412 obtain an advertisement quickly, a host sends one or more Router 413 Solicitations to the all-routers multicast group. Router 414 Advertisements contain two flags indicating what type of stateful 415 autoconfiguration (if any) is available. A "managed address 416 configuration (M)" flag indicates whether hosts can use stateful 417 autoconfiguration [RFC3315] to obtain addresses. An "other stateful 418 configuration (O)" flag indicates whether hosts can use stateful 419 autoconfiguration [RFC3736] to obtain additional information 420 (excluding addresses). 422 The details of how a host may use the M flag, including any use of 423 the "on" and "off" transitions for this flag, to control the use of 424 the stateful protocol for address assignment will be described in a 425 separate document. Similarly, the details of how a host may use the 426 O flag, including any use of the "on" and "off" transitions for this 427 flag, to control the use of the stateful protocol for getting other 428 configuration information will be described in a separate document. 430 Router Advertisements also contain zero or more Prefix Information 431 options that contain information used by stateless address 432 autoconfiguration to generate global addresses. It should be noted 433 that the stateless and stateful address autoconfiguration fields in 434 Router Advertisements are processed independently of one another, and 435 a host may use both stateful and stateless address autoconfiguration 436 simultaneously. One Prefix Information option field, the "autonomous 437 address-configuration flag", indicates whether or not the option even 438 applies to stateless autoconfiguration. If it does, additional 439 option fields contain a subnet prefix together with lifetime values 440 indicating how long addresses created from the prefix remain 441 preferred and valid. 443 Because routers generate Router Advertisements periodically, hosts 444 will continually receive new advertisements. Hosts process the 445 information contained in each advertisement as described above, 446 adding to and refreshing information received in previous 447 advertisements. 449 For safety, all addresses must be tested for uniqueness prior to 450 their assignment to an interface. The test should individually be 451 performed on all addresses obtained manually, via stateless address 452 autoconfiguration, or via stateful address autoconfiguration. To 453 accommodate sites that believe the overhead of performing Duplicate 454 Address Detection outweighs its benefits, the use of Duplicate 455 Address Detection can be disabled through the administrative setting 456 of a per-interface configuration flag. 458 To speed the autoconfiguration process, a host may generate its 459 link-local address (and verify its uniqueness) in parallel with 460 waiting for a Router Advertisement. Because a router may delay 461 responding to a Router Solicitation for a few seconds, the total time 462 needed to complete autoconfiguration can be significantly longer if 463 the two steps are done serially. 465 4.1 Site Renumbering 467 Address leasing facilitates site renumbering by providing a mechanism 468 to time-out addresses assigned to interfaces in hosts. At present, 469 upper layer protocols such as TCP provide no support for changing 470 end-point addresses while a connection is open. If an end-point 471 address becomes invalid, existing connections break and all 472 communication to the invalid address fails. Even when applications 473 use UDP as a transport protocol, addresses must generally remain the 474 same during a packet exchange. 476 Dividing valid addresses into preferred and deprecated categories 477 provides a way of indicating to upper layers that a valid address may 478 become invalid shortly and that future communication using the 479 address will fail, should the address's valid lifetime expire before 480 communication ends. To avoid this scenario, higher layers should use 481 a preferred address (assuming one of sufficient scope exists) to 482 increase the likelihood that an address will remain valid for the 483 duration of the communication. It is up to system administrators to 484 set appropriate prefix lifetimes in order to minimize the impact of 485 failed communication when renumbering takes place. The deprecation 486 period should be long enough that most, if not all, communications 487 are using the new address at the time an address becomes invalid. 489 The IP layer is expected to provide a means for upper layers 490 (including applications) to select the most appropriate source 491 address given a particular destination and possibly other 492 constraints. An application may choose to select the source address 493 itself before starting a new communication or may leave the address 494 unspecified, in which case the upper networking layers will use the 495 mechanism provided by the IP layer to choose a suitable address on 496 the application's behalf. 498 Detailed address selection rules are beyond the scope of this 499 document. 501 5. PROTOCOL SPECIFICATION 503 Autoconfiguration is performed on a per-interface basis on 504 multicast-capable interfaces. For multihomed hosts, 505 autoconfiguration is performed independently on each interface. 506 Autoconfiguration applies primarily to hosts, with two exceptions. 507 Routers are expected to generate a link-local address using the 508 procedure outlined below. In addition, routers perform Duplicate 509 Address Detection on all addresses prior to assigning them to an 510 interface. 512 5.1 Node Configuration Variables 514 A node MUST allow the following autoconfiguration-related variable to 515 be configured by system management for each multicast interface: 517 DupAddrDetectTransmits 519 The number of consecutive Neighbor Solicitation messages sent 520 while performing Duplicate Address Detection on a tentative 521 address. A value of zero indicates that Duplicate Address 522 Detection is not performed on tentative addresses. A value of one 523 indicates a single transmission with no follow up retransmissions. 525 Default: 1, but may be overridden by a link-type specific value in 526 the document that covers issues related to the transmission of IP 527 over a particular link type (e.g., [RFC2464]). 529 Autoconfiguration also assumes the presence of the variable 530 RetransTimer as defined in [RFC2461]. For autoconfiguration 531 purposes, RetransTimer specifies the delay between consecutive 532 Neighbor Solicitation transmissions performed during Duplicate 533 Address Detection (if DupAddrDetectTransmits is greater than 1), 534 as well as the time a node waits after sending the last Neighbor 535 Solicitation before ending the Duplicate Address Detection 536 process. 538 5.2 Autoconfiguration-Related Structures 540 Beyond the formation of a link-local address and using Duplicate 541 Address Detection, how routers (auto)configure their interfaces is 542 beyond the scope of this document. 544 A host maintains a list of addresses together with their 545 corresponding lifetimes. The address list contains both 546 autoconfigured addresses and those configured manually. 548 5.3 Creation of Link-Local Addresses 550 A node forms a link-local address whenever an interface becomes 551 enabled. An interface may become enabled after any of the following 552 events: 554 - The interface is initialized at system startup time. 556 - The interface is reinitialized after a temporary interface failure 557 or after being temporarily disabled by system management. 559 - The interface attaches to a link for the first time. 561 - The interface becomes enabled by system management after having 562 been administratively disabled. 564 A link-local address is formed by prepending the well-known link- 565 local prefix FE80::0 [RFC3513] (of appropriate length not less than 566 10 bits) to the interface identifier. If the interface identifier 567 has a length of N bits, the interface identifier replaces the 568 right-most N zero bits of the link-local prefix. If the interface 569 identifier is more than 118 bits in length, autoconfiguration fails 570 and manual configuration is required. The length of the interface 571 identifier is defined in a separate link-type specific document, 572 which should also be consistent with the address architecture 573 [RFC3513] (see Section 2). These documents will carefully define the 574 length so that link-local addresses can be autoconfigured on the 575 link. 577 A link-local address has an infinite preferred and valid lifetime; it 578 is never timed out. 580 5.4 Duplicate Address Detection 582 Duplicate Address Detection is performed on unicast addresses prior 583 to assigning them to an interface whose DupAddrDetectTransmits 584 variable is greater than zero. Duplicate Address Detection MUST take 585 place on all unicast addresses, regardless of whether they are 586 obtained through stateful, stateless or manual configuration, with 587 the exception of the following cases: 589 - Duplicate Address Detection MUST NOT be performed on anycast 590 addresses. 592 - Each individual unicast address SHOULD be tested for uniqueness. 593 Note that there are implementations deployed that only perform 594 Duplicate Address Detection for the link-local address and skip 595 the test for the global address using the same interface 596 identifier as that of the link-local address. Whereas this 597 document does not invalidate such implementations, this kind of 598 "optimization" is NOT RECOMMENDED, and new implementations MUST 599 NOT do that optimization. This optimization came from the 600 assumption that all of an interface's addresses are generated from 601 the same identifier. However, the assumption does actually not 602 stand; new types of addresses have been introduced where the 603 interface identifiers are not necessarily the same for all unicast 604 addresses on a single interface [RFC3041][I-D.ietf-send-cga]. 605 Requiring to perform Duplicate Address Detection for all unicast 606 addresses will make the algorithm robust for the current and 607 future such special interface identifiers. 609 The procedure for detecting duplicate addresses uses Neighbor 610 Solicitation and Advertisement messages as described below. If a 611 duplicate address is discovered during the procedure, the address 612 cannot be assigned to the interface. If the address is derived from 613 an interface identifier, a new identifier will need to be assigned to 614 the interface, or all IP addresses for the interface will need to be 615 manually configured. Note that the method for detecting duplicates 616 is not completely reliable, and it is possible that duplicate 617 addresses will still exist (e.g., if the link was partitioned while 618 Duplicate Address Detection was performed). 620 An address on which the Duplicate Address Detection procedure is 621 applied is said to be tentative until the procedure has completed 622 successfully. A tentative address is not considered "assigned to an 623 interface" in the traditional sense. That is, the interface must 624 accept Neighbor Solicitation and Advertisement messages containing 625 the tentative address in the Target Address field, but processes such 626 packets differently from those whose Target Address matches an 627 address assigned to the interface. Other packets addressed to the 628 tentative address should be silently discarded. Note that the "other 629 packets" include Neighbor Solicitation and Advertisement messages 630 which have the tentative (i.e., unicast) address as the IP 631 destination address and contain the tentative address in the Target 632 Address field. Such a case should not happen in normal operation, 633 though, since these messages are multicasted in the Duplicate Address 634 Detection procedure. 636 It should also be noted that Duplicate Address Detection must be 637 performed prior to assigning an address to an interface in order to 638 prevent multiple nodes from using the same address simultaneously. 639 If a node begins using an address in parallel with Duplicate Address 640 Detection, and another node is already using the address, the node 641 performing Duplicate Address Detection will erroneously process 642 traffic intended for the other node, resulting in such possible 643 negative consequences as the resetting of open TCP connections. 645 The following subsections describe specific tests a node performs to 646 verify an address's uniqueness. An address is considered unique if 647 none of the tests indicate the presence of a duplicate address within 648 RetransTimer milliseconds after having sent DupAddrDetectTransmits 649 Neighbor Solicitations. Once an address is determined to be unique, 650 it may be assigned to an interface. 652 5.4.1 Message Validation 654 A node MUST silently discard any Neighbor Solicitation or 655 Advertisement message that does not pass the validity checks 656 specified in [RFC2461]. A Neighbor Solicitation or Advertisement 657 message that passes these validity checks is called a valid 658 solicitation or valid advertisement, respectively. 660 5.4.2 Sending Neighbor Solicitation Messages 662 Before sending a Neighbor Solicitation, an interface MUST join the 663 all-nodes multicast address and the solicited-node multicast address 664 of the tentative address. The former ensures that the node receives 665 Neighbor Advertisements from other nodes already using the address; 666 the latter ensures that two nodes attempting to use the same address 667 simultaneously detect each other's presence. 669 To check an address, a node sends DupAddrDetectTransmits Neighbor 670 Solicitations, each separated by RetransTimer milliseconds. The 671 solicitation's Target Address is set to the address being checked, 672 the IP source is set to the unspecified address and the IP 673 destination is set to the solicited-node multicast address of the 674 target address. 676 If the Neighbor Solicitation is going to be the first message to be 677 sent from an interface after interface (re)initialization, the node 678 SHOULD delay joining the solicited-node multicast address by a random 679 delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in 680 [RFC2461]. This serves to alleviate congestion when many nodes start 681 up on the link at the same time, such as after a power failure, and 682 may help to avoid race conditions when more than one node is trying 683 to solicit for the same address at the same time. 685 Even if the Neighbor Solicitation is not going to be the first 686 message to be sent, the node SHOULD delay joining the solicited-node 687 multicast address by a random delay between 0 and 688 MAX_RTR_SOLICITATION_DELAY if the address being checked is configured 689 by a router advertisement message sent to a multicast address. The 690 delay will avoid similar congestion when multiple nodes are going to 691 configure addresses by receiving a same single multicast router 692 advertisement. 694 Note that the delay for joining the multicast address implicitly 695 means delaying transmission of the corresponding Multicast Listener 696 Discovery (MLD) report message [RFC2710]. Since [RFC2710] does not 697 request a random delay to avoid race conditions, just delaying 698 Neighbor Solicitation would cause congestion by the MLD report 699 messages. The congestion would then prevent MLD-snooping switches 700 from working correctly, and, as a result, prevent Duplicate Address 701 Detection from working. The requirement to include the delay for the 702 MLD report in this case avoids this scenario. 704 In order to improve the robustness of the Duplicate Address Detection 705 algorithm, an interface MUST receive and process datagrams sent to 706 the all-nodes multicast address or solicited-node multicast address 707 of the tentative address while the delaying period. This does not 708 necessarily conflict with the requirement that joining the multicast 709 group be delayed. In fact, in some cases it is possible for a node 710 to start listening to the group during the delay period before MLD 711 report transmission. It should be noted, however, that in some 712 link-layer environments, particularly with MLD-snooping switches, no 713 multicast reception will be available until the MLD report is sent. 715 5.4.3 Receiving Neighbor Solicitation Messages 717 On receipt of a valid Neighbor Solicitation message on an interface, 718 node behavior depends on whether the target address is tentative or 719 not. If the target address is not tentative (i.e., it is assigned to 720 the receiving interface), the solicitation is processed as described 721 in [RFC2461]. If the target address is tentative, and the source 722 address is a unicast address, the solicitation's sender is performing 723 address resolution on the target; the solicitation should be silently 724 ignored. Otherwise, processing takes place as described below. In 725 all cases, a node MUST NOT respond to a Neighbor Solicitation for a 726 tentative address. 728 If the source address of the Neighbor Solicitation is the unspecified 729 address, the solicitation is from a node performing Duplicate Address 730 Detection. If the solicitation is from another node, the tentative 731 address is a duplicate and should not be used (by either node). If 732 the solicitation is from the node itself (because the node loops back 733 multicast packets), the solicitation does not indicate the presence 734 of a duplicate address. 736 Implementor's Note: many interfaces provide a way for upper layers to 737 selectively enable and disable the looping back of multicast packets. 738 The details of how such a facility is implemented may prevent 739 Duplicate Address Detection from working correctly. See the Appendix 740 A for further discussion. 742 The following tests identify conditions under which a tentative 743 address is not unique: 745 - If a Neighbor Solicitation for a tentative address is received 746 prior to having sent one, the tentative address is a duplicate. 747 This condition occurs when two nodes run Duplicate Address 748 Detection simultaneously, but transmit initial solicitations at 749 different times (e.g., by selecting different random delay values 750 before joining the solicited-node multicast address and 751 transmitting an initial solicitation). 753 - If the actual number of Neighbor Solicitations received exceeds 754 the number expected based on the loopback semantics (e.g., the 755 interface does not loopback packet, yet one or more solicitations 756 was received), the tentative address is a duplicate. This 757 condition occurs when two nodes run Duplicate Address Detection 758 simultaneously and transmit solicitations at roughly the same 759 time. 761 5.4.4 Receiving Neighbor Advertisement Messages 763 On receipt of a valid Neighbor Advertisement message on an interface, 764 node behavior depends on whether the target address is tentative or 765 matches a unicast or anycast address assigned to the interface. If 766 the target address is assigned to the receiving interface, the 767 solicitation is processed as described in [RFC2461]. If the target 768 address is tentative, the tentative address is not unique. 770 5.4.5 When Duplicate Address Detection Fails 772 A tentative address that is determined to be a duplicate as described 773 above MUST NOT be assigned to an interface and the node SHOULD log a 774 system management error. 776 If the address is a link-local address formed from an interface 777 identifier based on the hardware address which is supposed to be 778 uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP 779 operation on the interface SHOULD be disabled. By disabling IP 780 operation, the node will then 782 - not send any IP packets from the interface 783 - silently drop any IP packets received on the interface 784 - not forward any IP packets to the interface (when acting as a 785 router or processing a packet with a Routing header) 787 In this case, the IP address duplication probably means duplicate 788 hardware addresses are in use, and trying to recover from it by 789 configuring another IP address will not result in a usable network. 790 In fact, it probably makes things worse by creating problems that are 791 harder to diagnose than just disabling network operation on the 792 interface; the user will see a partially working network where some 793 things work, and other things will not. 795 On the other hand, if the duplicate link-local address is not formed 796 from an interface identifier based on the hardware address which is 797 supposed to be uniquely assigned, IP operation on the interface MAY 798 be continued. 800 Note: as specified in Section 2, "IP" means "IPv6" in the above 801 description. While the background rationale about the hardware 802 address is independent of particular network protocols, the effect on 803 other protocols is beyond the scope of this document. 805 5.5 Creation of Global Addresses 807 Global addresses are formed by appending an interface identifier to a 808 prefix of appropriate length. Prefixes are obtained from Prefix 809 Information options contained in Router Advertisements. Creation of 810 global addresses and configuration of other parameters as described 811 in this section SHOULD be locally configurable. However, the 812 processing described below MUST be enabled by default. 814 5.5.1 Soliciting Router Advertisements 816 Router Advertisements are sent periodically to the all-nodes 817 multicast address. To obtain an advertisement quickly, a host sends 818 out Router Solicitations as described in [RFC2461]. 820 5.5.2 Absence of Router Advertisements 822 Even if a link has no routers, stateful autoconfiguration to obtain 823 addresses and other configuration information may still be available, 824 and hosts may want to use the mechanism. From the perspective of 825 autoconfiguration, a link has no routers if no Router Advertisements 826 are received after having sent a small number of Router Solicitations 827 as described in [RFC2461]. 829 Note that it is possible that there is no router on the link in this 830 sense but there is a node that has the ability to forward packets. 831 In this case, the forwarding node's address must be manually 832 configured in hosts to be able to send packets off-link, since the 833 only mechanism to configure the default router's address 834 automatically is the one using router advertisements. 836 5.5.3 Router Advertisement Processing 838 For each Prefix-Information option in the Router Advertisement: 840 a) If the Autonomous flag is not set, silently ignore the Prefix 841 Information option. 843 b) If the prefix is the link-local prefix, silently ignore the 844 Prefix Information option. 846 c) If the preferred lifetime is greater than the valid lifetime, 847 silently ignore the Prefix Information option. A node MAY wish to 848 log a system management error in this case. 850 d) If the prefix advertised is not equal to the prefix of an address 851 configured by stateless autoconfiguration already in the list of 852 addresses associated with the interface (where "equal" means the 853 two prefix lengths are the same and the first prefix-length bits 854 of the prefixes are identical), and the Valid Lifetime is not 0, 855 form an address (and add it to the list) by combining the 856 advertised prefix with the link's interface identifier as follows: 858 | 128 - N bits | N bits | 859 +---------------------------------------+------------------------+ 860 | link prefix | interface identifier | 861 +----------------------------------------------------------------+ 863 If the sum of the prefix length and interface identifier length 864 does not equal 128 bits, the Prefix Information option MUST be 865 ignored. An implementation MAY wish to log a system management 866 error in this case. The length of the interface identifier is 867 defined in a separate link-type specific document, which should 868 also be consistent with the address architecture [RFC3513] (see 869 Section 2). 871 It is the responsibility of the system administrator to insure 872 that the lengths of prefixes contained in Router Advertisements 873 are consistent with the length of interface identifiers for that 874 link type. It should be noted, however, that this does not mean 875 the advertised prefix length is meaningless. In fact, the 876 advertised length has non trivial meaning for on-link 877 determination in [RFC2461] where the sum of the prefix length and 878 the interface identifier length may not be equal to 128. Thus, it 879 should be safe to validate the advertised prefix length here, in 880 order to detect and avoid a configuration error specifying an 881 invalid prefix length in the context of address autoconfiguration. 883 Note that a future revision of the address architecture [RFC3513] 884 and a future link-type specific document, which will still be 885 consistent with each other, could potentially allow for an 886 interface identifier of length other than the value defined in the 887 current documents. Thus, an implementation should not assume a 888 particular constant. Rather, it should expect any lengths of 889 interface identifiers. 891 If an address is formed successfully, the host adds it to the list 892 of addresses assigned to the interface, initializing its preferred 893 and valid lifetime values from the Prefix Information option. 895 e) If the advertised prefix is equal to the prefix of an address 896 configured by stateless autoconfiguration in the list, the 897 preferred lifetime of the address is reset to the Preferred 898 Lifetime in the received advertisement. The specific action to 899 perform for the valid lifetime of the address depends on the Valid 900 Lifetime in the received advertisement and the remaining time to 901 the valid lifetime expiration of the previously autoconfigured 902 address. We call the remaining time "RemainingLifetime" in the 903 following discussion: 905 1. If the received Valid Lifetime is greater than 2 hours or 906 greater than RemainingLifetime, set the valid lifetime of the 907 corresponding address to the advertised Valid Lifetime. 909 2. If RemainingLifetime is less than or equal to 2 hours, ignore 910 the Prefix Information option with regards to the valid 911 lifetime, unless the Router Advertisement from which this 912 option was obtained has been authenticated (e.g., via IP 913 security [RFC2402]). If the Router Advertisement was 914 authenticated, the valid lifetime of the corresponding address 915 should be set to the Valid Lifetime in the received option. 917 3. Otherwise, reset the valid lifetime of the corresponding 918 address to two hours. 920 The above rules address a specific denial of service attack in 921 which a bogus advertisement could contain prefixes with very small 922 Valid Lifetimes. Without the above rules, a single 923 unauthenticated advertisement containing bogus Prefix Information 924 options with short Valid Lifetimes could cause all of a node's 925 addresses to expire prematurely. The above rules ensure that 926 legitimate advertisements (which are sent periodically) will 927 "cancel" the short Valid Lifetimes before they actually take 928 effect. 930 Note that the preferred lifetime of the corresponding address is 931 always reset to the Preferred Lifetime in the received Prefix 932 Information option, regardless of whether the valid lifetime is 933 also reset or ignored. The difference comes from the fact that 934 the possible attack for the preferred lifetime is relatively 935 minor. Additionally, it is even undesirable to ignore the 936 preferred lifetime when a valid administrator wants to deprecate a 937 particular address by sending a short preferred lifetime (and the 938 valid lifetime is ignored by accident). 940 5.5.4 Address Lifetime Expiry 942 A preferred address becomes deprecated when its preferred lifetime 943 expires. A deprecated address SHOULD continue to be used as a source 944 address in existing communications, but SHOULD NOT be used to 945 initiate new communications if an alternate (non-deprecated) address 946 of sufficient scope can easily be used instead. 948 Note that the feasibility of initiating new communication using a 949 non-deprecated address may be an application-specific decision, as 950 only the application may have knowledge about whether the (now) 951 deprecated address was (or still is) in use by the application. For 952 example, if an application explicitly specifies the protocol stack to 953 use a deprecated address as a source address, the protocol stack must 954 accept that; the application might request it because that IP address 955 is used for in higher-level communication and there might be a 956 requirement that the multiple connections in such a grouping use the 957 same pair of IP addresses. 959 IP and higher layers (e.g., TCP, UDP) MUST continue to accept and 960 process datagrams destined to a deprecated address as normal since a 961 deprecated address is still a valid address for the interface. In 962 the case of TCP, this means TCP SYN segments sent to a deprecated 963 address are responded to using the deprecated address as a source 964 address in the corresponding SYN-ACK (if the connection would 965 otherwise be allowed). 967 An implementation MAY prevent any new communication from using a 968 deprecated address, but system management MUST have the ability to 969 disable such a facility, and the facility MUST be disabled by 970 default. 972 Other subtle cases should also be noted about source address 973 selection. For example, the above description does not clarify which 974 address should be used between a deprecated, smaller-scope address 975 and a non-deprecated, enough scope address. The details of the 976 address selection including this case are described in [RFC3484] and 977 beyond the scope of this document. 979 An address (and its association with an interface) becomes invalid 980 when its valid lifetime expires. An invalid address MUST NOT be used 981 as a source address in outgoing communications and MUST NOT be 982 recognized as a destination on a receiving interface. 984 5.6 Configuration Consistency 986 It is possible for hosts to obtain address information using both 987 stateless and stateful protocols since both may be enabled at the 988 same time. It is also possible that the values of other 989 configuration parameters such as MTU size and hop limit will be 990 learned from both Router Advertisements and the stateful 991 autoconfiguration protocol. If the same configuration information is 992 provided by multiple sources, the value of this information should be 993 consistent. However, it is not considered a fatal error if 994 information received from multiple sources is inconsistent. Hosts 995 accept the union of all information received via the stateless and 996 stateful protocols. If inconsistent info