idnits 2.17.1 draft-ietf-ipv6-rfc2462bis-04.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1401. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1417), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** 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. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (August 10, 2004) is 7198 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF IPv6 Working Group S. Thomson 3 Internet-Draft Cisco 4 Expires: February 8, 2005 T. Narten 5 IBM 6 T. Jinmei 7 Toshiba 8 August 10, 2004 10 IPv6 Stateless Address Autoconfiguration 11 draft-ietf-ipv6-rfc2462bis-04.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 or will be disclosed, and any of which I become aware will be 18 disclosed, in accordance with RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on February 8, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This document specifies the steps a host takes in deciding how to 45 autoconfigure its interfaces in IP version 6. The autoconfiguration 46 process includes creating a link-local address and verifying its 47 uniqueness on a link, determining what information can be 48 autoconfigured (addresses, other information, or both), and in the 49 case of addresses, whether they can be obtained through the stateless 50 mechanism, the stateful mechanism, or both. This document defines 51 the process for generating a link-local address, the process for 52 generating global addresses via stateless address autoconfiguration, 53 and the Duplicate Address Detection procedure. The details of 54 autoconfiguration using the stateful protocol is specified in RFC 55 3315 and RFC 3736. 57 Table of Contents 59 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. TERMINOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 62 3. DESIGN GOALS . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4. PROTOCOL OVERVIEW . . . . . . . . . . . . . . . . . . . . . . 8 64 4.1 Site Renumbering . . . . . . . . . . . . . . . . . . . . . 10 65 5. PROTOCOL SPECIFICATION . . . . . . . . . . . . . . . . . . . . 11 66 5.1 Node Configuration Variables . . . . . . . . . . . . . . . 11 67 5.2 Autoconfiguration-Related Structures . . . . . . . . . . . 12 68 5.3 Creation of Link-Local Addresses . . . . . . . . . . . . . 12 69 5.4 Duplicate Address Detection . . . . . . . . . . . . . . . 13 70 5.4.1 Message Validation . . . . . . . . . . . . . . . . . . 14 71 5.4.2 Sending Neighbor Solicitation Messages . . . . . . . . 14 72 5.4.3 Receiving Neighbor Solicitation Messages . . . . . . . 16 73 5.4.4 Receiving Neighbor Advertisement Messages . . . . . . 17 74 5.4.5 When Duplicate Address Detection Fails . . . . . . . . 17 75 5.5 Creation of Global Addresses . . . . . . . . . . . . . . . 18 76 5.5.1 Soliciting Router Advertisements . . . . . . . . . . . 18 77 5.5.2 Absence of Router Advertisements . . . . . . . . . . . 18 78 5.5.3 Router Advertisement Processing . . . . . . . . . . . 18 79 5.5.4 Address Lifetime Expiry . . . . . . . . . . . . . . . 20 80 5.6 Configuration Consistency . . . . . . . . . . . . . . . . 21 81 5.7 Retaining Configured Addresses for Stability . . . . . . . 22 82 6. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . 22 83 7. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . 23 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 87 9.2 Informative References . . . . . . . . . . . . . . . . . . . 23 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 89 A. LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION . . . . . . 25 90 B. CHANGES SINCE RFC 1971 . . . . . . . . . . . . . . . . . . . . 26 91 C. CHANGES SINCE RFC 2462 . . . . . . . . . . . . . . . . . . . . 27 92 D. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . . . . . . 28 93 Intellectual Property and Copyright Statements . . . . . . . . 31 95 1. INTRODUCTION 97 This document specifies the steps a host takes in deciding how to 98 autoconfigure its interfaces in IP version 6 (IPv6). The 99 autoconfiguration process includes creating a link-local address and 100 verifying its uniqueness on a link, determining what information can 101 be autoconfigured (addresses, other information, or both), and in the 102 case of addresses, whether they can be obtained through the stateless 103 mechanism, the stateful mechanism, or both. This document defines 104 the process for generating a link-local address, the process for 105 generating global addresses via stateless address autoconfiguration, 106 and the Duplicate Address Detection procedure. The details of 107 autoconfiguration using the stateful protocol is specified in 108 [RFC3315] and [RFC3736]. 110 IPv6 defines both a stateful and stateless address autoconfiguration 111 mechanism. Stateless autoconfiguration requires no manual 112 configuration of hosts, minimal (if any) configuration of routers, 113 and no additional servers. The stateless mechanism allows a host to 114 generate its own addresses using a combination of locally available 115 information and information advertised by routers. Routers advertise 116 prefixes that identify the subnet(s) associated with a link, while 117 hosts generate an "interface identifier" that uniquely identifies an 118 interface on a subnet. An address is formed by combining the two. 119 In the absence of routers, a host can only generate link-local 120 addresses. However, link-local addresses are sufficient for allowing 121 communication among nodes attached to the same link. 123 In the stateful autoconfiguration model, hosts obtain interface 124 addresses and/or configuration information and parameters from a 125 Dynamic Host Configuration Protocol (DHCPv6) server. Servers 126 maintain a database that keeps track of which addresses have been 127 assigned to which hosts. The stateful autoconfiguration protocol 128 allows hosts to obtain addresses, other configuration information or 129 both from a server. Stateless and stateful autoconfiguration 130 complement each other. For example, a host can use stateless 131 autoconfiguration to configure its own addresses, but use stateful 132 autoconfiguration to obtain other information. 134 To obtain other configuration information without configuring 135 addresses in the stateful autoconfiguration model, a subset of DHCPv6 136 [RFC3736] will be used. While the model is called "stateful" here in 137 order to highlight the contrast to the stateless protocol defined in 138 this document, the intended protocol is also defined to work in a 139 stateless fashion. This is based on a result, through operational 140 experiments, that all known "other" configuration information can be 141 managed by a stateless server, that is, a server that does not 142 maintain state of each client that the server provides with the 143 configuration information. 145 The stateless approach is used when a site is not particularly 146 concerned with the exact addresses hosts use, so long as they are 147 unique and properly routable. The stateful approach is used when a 148 site requires tighter control over exact address assignments. Both 149 stateful and stateless address autoconfiguration may be used 150 simultaneously. The site administrator specifies which type of 151 autoconfiguration is available through the setting of appropriate 152 fields in Router Advertisement messages [RFC2461]. 154 IPv6 addresses are leased to an interface for a fixed (possibly 155 infinite) length of time. Each address has an associated lifetime 156 that indicates how long the address is bound to an interface. When a 157 lifetime expires, the binding (and address) become invalid and the 158 address may be reassigned to another interface elsewhere in the 159 Internet. To handle the expiration of address bindings gracefully, 160 an address goes through two distinct phases while assigned to an 161 interface. Initially, an address is "preferred", meaning that its 162 use in arbitrary communication is unrestricted. Later, an address 163 becomes "deprecated" in anticipation that its current interface 164 binding will become invalid. While in a deprecated state, the use of 165 an address is discouraged, but not strictly forbidden. New 166 communication (e.g., the opening of a new TCP connection) should use 167 a preferred address when possible. A deprecated address should be 168 used only by applications that have been using it and would have 169 difficulty switching to another address without a service disruption. 171 To ensure that all configured addresses are likely to be unique on a 172 given link, nodes run a "duplicate address detection" algorithm on 173 addresses before assigning them to an interface. The Duplicate 174 Address Detection algorithm is performed on all addresses, 175 independent of whether they are obtained via stateless or stateful 176 autoconfiguration. This document defines the Duplicate Address 177 Detection algorithm. 179 The autoconfiguration process specified in this document applies only 180 to hosts and not routers. Since host autoconfiguration uses 181 information advertised by routers, routers will need to be configured 182 by some other means. However, it is expected that routers will 183 generate link-local addresses using the mechanism described in this 184 document. In addition, routers are expected to successfully pass the 185 Duplicate Address Detection procedure described in this document on 186 all addresses prior to assigning them to an interface. 188 Section 2 provides definitions for terminology used throughout this 189 document. Section 3 describes the design goals that lead to the 190 current autoconfiguration procedure. Section 4 provides an overview 191 of the protocol, while Section 5 describes the protocol in detail. 193 2. TERMINOLOGY 195 IP - Internet Protocol Version 6. The terms IPv4 and IPv6 are used 196 only in contexts where necessary to avoid ambiguity. 198 node - a device that implements IP. 200 router - a node that forwards IP packets not explicitly addressed to 201 itself. 203 host - any node that is not a router. 205 upper layer - a protocol layer immediately above IP. Examples are 206 transport protocols such as TCP and UDP, control protocols such as 207 ICMP, routing protocols such as OSPF, and internet or lower-layer 208 protocols being "tunneled" over (i.e., encapsulated in) IP such as 209 IPX, AppleTalk, or IP itself. 211 link - a communication facility or medium over which nodes can 212 communicate at the link layer, i.e., the layer immediately below 213 IP. Examples are Ethernets (simple or bridged); PPP links; X.25, 214 Frame Relay, or ATM networks; and internet (or higher) layer 215 "tunnels", such as tunnels over IPv4 or IPv6 itself. 217 interface - a node's attachment to a link. 219 packet - an IP header plus payload. 221 address - an IP-layer identifier for an interface or a set of 222 interfaces. 224 unicast address - an identifier for a single interface. A packet 225 sent to a unicast address is delivered to the interface identified 226 by that address. 228 multicast address - an identifier for a set of interfaces (typically 229 belonging to different nodes). A packet sent to a multicast 230 address is delivered to all interfaces identified by that address. 232 anycast address - an identifier for a set of interfaces (typically 233 belonging to different nodes). A packet sent to an anycast 234 address is delivered to one of the interfaces identified by that 235 address (the "nearest" one, according to the routing protocol's 236 measure of distance). See [RFC3513]. 238 solicited-node multicast address - a multicast address to which 239 Neighbor Solicitation messages are sent. The algorithm for 240 computing the address is given in [RFC3513]. 242 link-layer address - a link-layer identifier for an interface. 243 Examples include IEEE 802 addresses for Ethernet links and E.164 244 addresses for ISDN links. 246 link-local address - an address having link-only scope that can be 247 used to reach neighboring nodes attached to the same link. All 248 interfaces have a link-local unicast address. 250 global address - an address with unlimited scope. 252 communication - any packet exchange among nodes that requires that 253 the address of each node used in the exchange remain the same for 254 the duration of the packet exchange. Examples are a TCP 255 connection or a UDP request-response. 257 tentative address - an address whose uniqueness on a link is being 258 verified, prior to its assignment to an interface. A tentative 259 address is not considered assigned to an interface in the usual 260 sense. An interface discards received packets addressed to a 261 tentative address, but accepts Neighbor Discovery packets related 262 to Duplicate Address Detection for the tentative address. 264 preferred address - an address assigned to an interface whose use by 265 upper layer protocols is unrestricted. Preferred addresses may be 266 used as the source (or destination) address of packets sent from 267 (or to) the interface. 269 deprecated address - An address assigned to an interface whose use is 270 discouraged, but not forbidden. A deprecated address should no 271 longer be used as a source address in new communications, but 272 packets sent from or to deprecated addresses are delivered as 273 expected. A deprecated address may continue to be used as a 274 source address in communications where switching to a preferred 275 address causes hardship to a specific upper-layer activity (e.g., 276 an existing TCP connection). 278 valid address - a preferred or deprecated address. A valid address 279 may appear as the source or destination address of a packet, and 280 the internet routing system is expected to deliver packets sent to 281 a valid address to their intended recipients. 283 invalid address - an address that is not assigned to any interface. 284 A valid address becomes invalid when its valid lifetime expires. 285 Invalid addresses should not appear as the destination or source 286 address of a packet. In the former case, the internet routing 287 system will be unable to deliver the packet, in the latter case 288 the recipient of the packet will be unable to respond to it. 290 preferred lifetime - the length of time that a valid address is 291 preferred (i.e., the time until deprecation). When the preferred 292 lifetime expires, the address becomes deprecated. 294 valid lifetime - the length of time an address remains in the valid 295 state (i.e., the time until invalidation). The valid lifetime 296 must be greater than or equal to the preferred lifetime. When the 297 valid lifetime expires, the address becomes invalid. 299 interface identifier - a link-dependent identifier for an interface 300 that is (at least) unique per link [RFC3513]. Stateless address 301 autoconfiguration combines an interface identifier with a prefix 302 to form an address. From address autoconfiguration's perspective, 303 an interface identifier is a bit string of known length. The 304 exact length of an interface identifier and the way it is created 305 is defined in a separate link-type specific document that covers 306 issues related to the transmission of IP over a particular link 307 type (e.g., [RFC2464]). Note that the address architecture 308 [RFC3513] also defines the length of the interface identifiers for 309 some set of addresses, but the two sets of definitions must be 310 consistent. In many cases, the identifier will be derived from 311 the interface's link-layer address. 313 2.1 Requirements 315 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 316 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 317 document, are to be interpreted as described in [RFC2119]. 319 3. DESIGN GOALS 321 Stateless autoconfiguration is designed with the following goals in 322 mind: 324 o Manual configuration of individual machines before connecting them 325 to the network should not be required. Consequently, a mechanism 326 is needed that allows a host to obtain or create unique addresses 327 for each of its interfaces. Address autoconfiguration assumes 328 that each interface can provide a unique identifier for that 329 interface (i.e., an "interface identifier"). In the simplest 330 case, an interface identifier consists of the interface's 331 link-layer address. An interface identifier can be combined with 332 a prefix to form an address. 334 o Small sites consisting of a set of machines attached to a single 335 link should not require the presence of a stateful server or 336 router as a prerequisite for communicating. Plug-and-play 337 communication is achieved through the use of link-local addresses. 338 Link-local addresses have a well-known prefix that identifies the 339 (single) shared link to which a set of nodes attach. A host forms 340 a link-local address by appending its interface identifier to the 341 link-local prefix. 343 o A large site with multiple networks and routers should not require 344 the presence of a stateful address configuration server. In order 345 to generate global addresses, hosts must determine the prefixes 346 that identify the subnets to which they attach. Routers generate 347 periodic Router Advertisements that include options listing the 348 set of active prefixes on a link. 350 o Address configuration should facilitate the graceful renumbering 351 of a site's machines. For example, a site may wish to renumber 352 all of its nodes when it switches to a new network service 353 provider. Renumbering is achieved through the leasing of 354 addresses to interfaces and the assignment of multiple addresses 355 to the same interface. Lease lifetimes provide the mechanism 356 through which a site phases out old prefixes. The assignment of 357 multiple addresses to an interface provides for a transition 358 period during which both a new address and the one being phased 359 out work simultaneously. 361 o System administrators need the ability to specify whether 362 stateless autoconfiguration, stateful autoconfiguration, or both 363 are available. Router Advertisements include flags specifying 364 which mechanisms a host can use. 366 4. PROTOCOL OVERVIEW 368 This section provides an overview of the typical steps that take 369 place when an interface autoconfigures itself. Autoconfiguration is 370 performed only on multicast-capable links and begins when a 371 multicast-capable interface is enabled, e.g., during system startup. 372 Nodes (both hosts and routers) begin the autoconfiguration process by 373 generating a link-local address for the interface. A link-local 374 address is formed by appending the interface's identifier to the 375 well-known link-local prefix. 377 Before the link-local address can be assigned to an interface and 378 used, however, a node must attempt to verify that this "tentative" 379 address is not already in use by another node on the link. 380 Specifically, it sends a Neighbor Solicitation message containing the 381 tentative address as the target. If another node is already using 382 that address, it will return a Neighbor Advertisement saying so. If 383 another node is also attempting to use the same address, it will send 384 a Neighbor Solicitation for the target as well. The exact number of 385 times the Neighbor Solicitation is (re)transmitted and the delay time 386 between consecutive solicitations is link-specific and may be set by 387 system management. 389 If a node determines that its tentative link-local address is not 390 unique, autoconfiguration stops and manual configuration of the 391 interface is required. To simplify recovery in this case, it should 392 be possible for an administrator to supply an alternate interface 393 identifier that overrides the default identifier in such a way that 394 the autoconfiguration mechanism can then be applied using the new 395 (presumably unique) interface identifier. Alternatively, link-local 396 and other addresses will need to be configured manually. 398 Once a node ascertains that its tentative link-local address is 399 unique, it assigns the address to the interface. At this point, the 400 node has IP-level connectivity with neighboring nodes. The remaining 401 autoconfiguration steps are performed only by hosts; the 402 (auto)configuration of routers is beyond the scope of this document. 404 The next phase of autoconfiguration involves obtaining a Router 405 Advertisement or determining that no routers are present. If routers 406 are present, they will send Router Advertisements that specify what 407 sort of autoconfiguration a host can do. Note that stateful 408 autoconfiguration may still be available even if no routers are 409 present. 411 Routers send Router Advertisements periodically, but the delay 412 between successive advertisements will generally be longer than a 413 host performing autoconfiguration will want to wait [RFC2461]. To 414 obtain an advertisement quickly, a host sends one or more Router 415 Solicitations to the all-routers multicast group. Router 416 Advertisements contain two flags indicating what type of stateful 417 autoconfiguration (if any) is available. A "managed address 418 configuration (M)" flag indicates whether hosts can use stateful 419 autoconfiguration [RFC3315] to obtain addresses. An "other stateful 420 configuration (O)" flag indicates whether hosts can use stateful 421 autoconfiguration [RFC3736] to obtain additional information 422 (excluding addresses). 424 The details of how a host may use the M flag, including any use of 425 the "on" and "off" transitions for this flag, to control the use of 426 the stateful protocol for address assignment will be described in a 427 separate document. Similarly, the details of how a host may use the 428 O flag, including any use of the "on" and "off" transitions for this 429 flag, to control the use of the stateful protocol for getting other 430 configuration information will be described in a separate document. 432 Router Advertisements also contain zero or more Prefix Information 433 options that contain information used by stateless address 434 autoconfiguration to generate global addresses. It should be noted 435 that the stateless and stateful address autoconfiguration fields in 436 Router Advertisements are processed independently of one another, and 437 a host may use both stateful and stateless address autoconfiguration 438 simultaneously. One Prefix Information option field, the "autonomous 439 address-configuration flag", indicates whether or not the option even 440 applies to stateless autoconfiguration. If it does, additional 441 option fields contain a subnet prefix together with lifetime values 442 indicating how long addresses created from the prefix remain 443 preferred and valid. 445 Because routers generate Router Advertisements periodically, hosts 446 will continually receive new advertisements. Hosts process the 447 information contained in each advertisement as described above, 448 adding to and refreshing information received in previous 449 advertisements. 451 For safety, all addresses must be tested for uniqueness prior to 452 their assignment to an interface. The test should individually be 453 performed on all addresses obtained manually, via stateless address 454 autoconfiguration, or via stateful address autoconfiguration. To 455 accommodate sites that believe the overhead of performing Duplicate 456 Address Detection outweighs its benefits, the use of Duplicate 457 Address Detection can be disabled through the administrative setting 458 of a per-interface configuration flag. 460 To speed the autoconfiguration process, a host may generate its 461 link-local address (and verify its uniqueness) in parallel with 462 waiting for a Router Advertisement. Because a router may delay 463 responding to a Router Solicitation for a few seconds, the total time 464 needed to complete autoconfiguration can be significantly longer if 465 the two steps are done serially. 467 4.1 Site Renumbering 469 Address leasing facilitates site renumbering by providing a mechanism 470 to time-out addresses assigned to interfaces in hosts. At present, 471 upper layer protocols such as TCP provide no support for changing 472 end-point addresses while a connection is open. If an end-point 473 address becomes invalid, existing connections break and all 474 communication to the invalid address fails. Even when applications 475 use UDP as a transport protocol, addresses must generally remain the 476 same during a packet exchange. 478 Dividing valid addresses into preferred and deprecated categories 479 provides a way of indicating to upper layers that a valid address may 480 become invalid shortly and that future communication using the 481 address will fail, should the address's valid lifetime expire before 482 communication ends. To avoid this scenario, higher layers should use 483 a preferred address (assuming one of sufficient scope exists) to 484 increase the likelihood that an address will remain valid for the 485 duration of the communication. It is up to system administrators to 486 set appropriate prefix lifetimes in order to minimize the impact of 487 failed communication when renumbering takes place. The deprecation 488 period should be long enough that most, if not all, communications 489 are using the new address at the time an address becomes invalid. 491 The IP layer is expected to provide a means for upper layers 492 (including applications) to select the most appropriate source 493 address given a particular destination and possibly other 494 constraints. An application may choose to select the source address 495 itself before starting a new communication or may leave the address 496 unspecified, in which case the upper networking layers will use the 497 mechanism provided by the IP layer to choose a suitable address on 498 the application's behalf. 500 Detailed address selection rules are beyond the scope of this 501 document. 503 5. PROTOCOL SPECIFICATION 505 Autoconfiguration is performed on a per-interface basis on 506 multicast-capable interfaces. For multihomed hosts, 507 autoconfiguration is performed independently on each interface. 508 Autoconfiguration applies primarily to hosts, with two exceptions. 509 Routers are expected to generate a link-local address using the 510 procedure outlined below. In addition, routers perform Duplicate 511 Address Detection on all addresses prior to assigning them to an 512 interface. 514 5.1 Node Configuration Variables 516 A node MUST allow the following autoconfiguration-related variable to 517 be configured by system management for each multicast interface: 519 DupAddrDetectTransmits 521 The number of consecutive Neighbor Solicitation messages sent 522 while performing Duplicate Address Detection on a tentative 523 address. A value of zero indicates that Duplicate Address 524 Detection is not performed on tentative addresses. A value of one 525 indicates a single transmission with no follow up retransmissions. 527 Default: 1, but may be overridden by a link-type specific value in 528 the document that covers issues related to the transmission of IP 529 over a particular link type (e.g., [RFC2464]). 531 Autoconfiguration also assumes the presence of the variable 532 RetransTimer as defined in [RFC2461]. For autoconfiguration 533 purposes, RetransTimer specifies the delay between consecutive 534 Neighbor Solicitation transmissions performed during Duplicate 535 Address Detection (if DupAddrDetectTransmits is greater than 1), 536 as well as the time a node waits after sending the last Neighbor 537 Solicitation before ending the Duplicate Address Detection 538 process. 540 5.2 Autoconfiguration-Related Structures 542 Beyond the formation of a link-local address and using Duplicate 543 Address Detection, how routers (auto)configure their interfaces is 544 beyond the scope of this document. 546 A host maintains a list of addresses together with their 547 corresponding lifetimes. The address list contains both 548 autoconfigured addresses and those configured manually. 550 5.3 Creation of Link-Local Addresses 552 A node forms a link-local address whenever an interface becomes 553 enabled. An interface may become enabled after any of the following 554 events: 556 - The interface is initialized at system startup time. 558 - The interface is reinitialized after a temporary interface failure 559 or after being temporarily disabled by system management. 561 - The interface attaches to a link for the first time. 563 - The interface becomes enabled by system management after having 564 been administratively disabled. 566 A link-local address is formed by prepending the well-known link- 567 local prefix FE80::0 [RFC3513] (of appropriate length not less than 568 10 bits) to the interface identifier. If the interface identifier 569 has a length of N bits, the interface identifier replaces the 570 right-most N zero bits of the link-local prefix. If the interface 571 identifier is more than 118 bits in length, autoconfiguration fails 572 and manual configuration is required. The length of the interface 573 identifier is defined in a separate link-type specific document, 574 which should also be consistent with the address architecture 575 [RFC3513] (see Section 2). These documents will carefully define the 576 length so that link-local addresses can be autoconfigured on the 577 link. 579 A link-local address has an infinite preferred and valid lifetime; it 580 is never timed out. 582 5.4 Duplicate Address Detection 584 Duplicate Address Detection is performed on unicast addresses prior 585 to assigning them to an interface whose DupAddrDetectTransmits 586 variable is greater than zero. Duplicate Address Detection MUST take 587 place on all unicast addresses, regardless of whether they are 588 obtained through stateful, stateless or manual configuration, with 589 the exception of the following cases: 591 - Duplicate Address Detection MUST NOT be performed on anycast 592 addresses. 594 - Each individual unicast address SHOULD be tested for uniqueness. 595 Note that there are implementations deployed that only perform 596 Duplicate Address Detection for the link-local address and skip 597 the test for the global address using the same interface 598 identifier as that of the link-local address. Whereas this 599 document does not invalidate such implementations, this kind of 600 "optimization" is NOT RECOMMENDED, and new implementations MUST 601 NOT do that optimization. This optimization came from the 602 assumption that all of an interface's addresses are generated from 603 the same identifier. However, the assumption does actually not 604 stand; new types of addresses have been introduced where the 605 interface identifiers are not necessarily the same for all unicast 606 addresses on a single interface [RFC3041][I-D.ietf-send-cga]. 607 Requiring to perform Duplicate Address Detection for all unicast 608 addresses will make the algorithm robust for the current and 609 future such special interface identifiers. 611 The procedure for detecting duplicate addresses uses Neighbor 612 Solicitation and Advertisement messages as described below. If a 613 duplicate address is discovered during the procedure, the address 614 cannot be assigned to the interface. If the address is derived from 615 an interface identifier, a new identifier will need to be assigned to 616 the interface, or all IP addresses for the interface will need to be 617 manually configured. Note that the method for detecting duplicates 618 is not completely reliable, and it is possible that duplicate 619 addresses will still exist (e.g., if the link was partitioned while 620 Duplicate Address Detection was performed). 622 An address on which the Duplicate Address Detection procedure is 623 applied is said to be tentative until the procedure has completed 624 successfully. A tentative address is not considered "assigned to an 625 interface" in the traditional sense. That is, the interface must 626 accept Neighbor Solicitation and Advertisement messages containing 627 the tentative address in the Target Address field, but processes such 628 packets differently from those whose Target Address matches an 629 address assigned to the interface. Other packets addressed to the 630 tentative address should be silently discarded. Note that the "other 631 packets" include Neighbor Solicitation and Advertisement messages 632 which have the tentative (i.e., unicast) address as the IP 633 destination address and contain the tentative address in the Target 634 Address field. Such a case should not happen in normal operation, 635 though, since these messages are multicasted in the Duplicate Address 636 Detection procedure. 638 It should also be noted that Duplicate Address Detection must be 639 performed prior to assigning an address to an interface in order to 640 prevent multiple nodes from using the same address simultaneously. 641 If a node begins using an address in parallel with Duplicate Address 642 Detection, and another node is already using the address, the node 643 performing Duplicate Address Detection will erroneously process 644 traffic intended for the other node, resulting in such possible 645 negative consequences as the resetting of open TCP connections. 647 The following subsections describe specific tests a node performs to 648 verify an address's uniqueness. An address is considered unique if 649 none of the tests indicate the presence of a duplicate address within 650 RetransTimer milliseconds after having sent DupAddrDetectTransmits 651 Neighbor Solicitations. Once an address is determined to be unique, 652 it may be assigned to an interface. 654 5.4.1 Message Validation 656 A node MUST silently discard any Neighbor Solicitation or 657 Advertisement message that does not pass the validity checks 658 specified in [RFC2461]. A Neighbor Solicitation or Advertisement 659 message that passes these validity checks is called a valid 660 solicitation or valid advertisement, respectively. 662 5.4.2 Sending Neighbor Solicitation Messages 664 Before sending a Neighbor Solicitation, an interface MUST join the 665 all-nodes multicast address and the solicited-node multicast address 666 of the tentative address. The former ensures that the node receives 667 Neighbor Advertisements from other nodes already using the address; 668 the latter ensures that two nodes attempting to use the same address 669 simultaneously detect each other's presence. 671 To check an address, a node sends DupAddrDetectTransmits Neighbor 672 Solicitations, each separated by RetransTimer milliseconds. The 673 solicitation's Target Address is set to the address being checked, 674 the IP source is set to the unspecified address and the IP 675 destination is set to the solicited-node multicast address of the 676 target address. 678 If the Neighbor Solicitation is going to be the first message to be 679 sent from an interface after interface (re)initialization, the node 680 SHOULD delay joining the solicited-node multicast address by a random 681 delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in 682 [RFC2461]. This serves to alleviate congestion when many nodes start 683 up on the link at the same time, such as after a power failure, and 684 may help to avoid race conditions when more than one node is trying 685 to solicit for the same address at the same time. 687 Even if the Neighbor Solicitation is not going to be the first 688 message to be sent, the node SHOULD delay joining the solicited-node 689 multicast address by a random delay between 0 and 690 MAX_RTR_SOLICITATION_DELAY if the address being checked is configured 691 by a router advertisement message sent to a multicast address. The 692 delay will avoid similar congestion when multiple nodes are going to 693 configure addresses by receiving a same single multicast router 694 advertisement. 696 Note that the delay for joining the multicast address implicitly 697 means delaying transmission of the corresponding Multicast Listener 698 Discovery (MLD) report message [RFC2710]. Since [RFC2710] does not 699 request a random delay to avoid race conditions, just delaying 700 Neighbor Solicitation would cause congestion by the MLD report 701 messages. The congestion would then prevent MLD-snooping switches 702 from working correctly, and, as a result, prevent Duplicate Address 703 Detection from working. The requirement to include the delay for the 704 MLD report in this case avoids this scenario. [RFC3590] also talks 705 about some interaction issues between Duplicate Address Detection and 706 MLD. 708 In order to improve the robustness of the Duplicate Address Detection 709 algorithm, an interface MUST receive and process datagrams sent to 710 the all-nodes multicast address or solicited-node multicast address 711 of the tentative address while the delaying period. This does not 712 necessarily conflict with the requirement that joining the multicast 713 group be delayed. In fact, in some cases it is possible for a node 714 to start listening to the group during the delay period before MLD 715 report transmission. It should be noted, however, that in some 716 link-layer environments, particularly with MLD-snooping switches, no 717 multicast reception will be available until the MLD report is sent. 719 5.4.3 Receiving Neighbor Solicitation Messages 721 On receipt of a valid Neighbor Solicitation message on an interface, 722 node behavior depends on whether the target address is tentative or 723 not. If the target address is not tentative (i.e., it is assigned to 724 the receiving interface), the solicitation is processed as described 725 in [RFC2461]. If the target address is tentative, and the source 726 address is a unicast address, the solicitation's sender is performing 727 address resolution on the target; the solicitation should be silently 728 ignored. Otherwise, processing takes place as described below. In 729 all cases, a node MUST NOT respond to a Neighbor Solicitation for a 730 tentative address. 732 If the source address of the Neighbor Solicitation is the unspecified 733 address, the solicitation is from a node performing Duplicate Address 734 Detection. If the solicitation is from another node, the tentative 735 address is a duplicate and should not be used (by either node). If 736 the solicitation is from the node itself (because the node loops back 737 multicast packets), the solicitation does not indicate the presence 738 of a duplicate address. 740 Implementor's Note: many interfaces provide a way for upper layers to 741 selectively enable and disable the looping back of multicast packets. 742 The details of how such a facility is implemented may prevent 743 Duplicate Address Detection from working correctly. See the Appendix 744 A for further discussion. 746 The following tests identify conditions under which a tentative 747 address is not unique: 749 - If a Neighbor Solicitation for a tentative address is received 750 prior to having sent one, the tentative address is a duplicate. 751 This condition occurs when two nodes run Duplicate Address 752 Detection simultaneously, but transmit initial solicitations at 753 different times (e.g., by selecting different random delay values 754 before joining the solicited-node multicast address and 755 transmitting an initial solicitation). 757 - If the actual number of Neighbor Solicitations received exceeds 758 the number expected based on the loopback semantics (e.g., the 759 interface does not loopback packet, yet one or more solicitations 760 was received), the tentative address is a duplicate. This 761 condition occurs when two nodes run Duplicate Address Detection 762 simultaneously and transmit solicitations at roughly the same 763 time. 765 5.4.4 Receiving Neighbor Advertisement Messages 767 On receipt of a valid Neighbor Advertisement message on an interface, 768 node behavior depends on whether the target address is tentative or 769 matches a unicast or anycast address assigned to the interface. If 770 the target address is assigned to the receiving interface, the 771 solicitation is processed as described in [RFC2461]. If the target 772 address is tentative, the tentative address is not unique. 774 5.4.5 When Duplicate Address Detection Fails 776 A tentative address that is determined to be a duplicate as described 777 above MUST NOT be assigned to an interface and the node SHOULD log a 778 system management error. 780 If the address is a link-local address formed from an interface 781 identifier based on the hardware address which is supposed to be 782 uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP 783 operation on the interface SHOULD be disabled. By disabling IP 784 operation, the node will then 786 - not send any IP packets from the interface 787 - silently drop any IP packets received on the interface 788 - not forward any IP packets to the interface (when acting as a 789 router or processing a packet with a Routing header) 791 In this case, the IP address duplication probably means duplicate 792 hardware addresses are in use, and trying to recover from it by 793 configuring another IP address will not result in a usable network. 794 In fact, it probably makes things worse by creating problems that are 795 harder to diagnose than just disabling network operation on the 796 interface; the user will see a partially working network where some 797 things work, and other things will not. 799 On the other hand, if the duplicate link-local address is not formed 800 from an interface identifier based on the hardware address which is 801 supposed to be uniquely assigned, IP operation on the interface MAY 802 be continued. 804 Note: as specified in Section 2, "IP" means "IPv6" in the above 805 description. While the background rationale about hardware address 806 is independent of particular network protocols, its effect on other 807 protocols is beyond the scope of this document. 809 5.5 Creation of Global Addresses 811 Global addresses are formed by appending an interface identifier to a 812 prefix of appropriate length. Prefixes are obtained from Prefix 813 Information options contained in Router Advertisements. Creation of 814 global addresses and configuration of other parameters as described 815 in this section SHOULD be locally configurable. However, the 816 processing described below MUST be enabled by default. 818 5.5.1 Soliciting Router Advertisements 820 Router Advertisements are sent periodically to the all-nodes 821 multicast address. To obtain an advertisement quickly, a host sends 822 out Router Solicitations as described in [RFC2461]. 824 5.5.2 Absence of Router Advertisements 826 Even if a link has no routers, stateful autoconfiguration to obtain 827 addresses and other configuration information may still be available, 828 and hosts may want to use the mechanism. From the perspective of 829 autoconfiguration, a link has no routers if no Router Advertisements 830 are received after having sent a small number of Router Solicitations 831 as described in [RFC2461]. 833 Note that it is possible that there is no router on the link in this 834 sense but there is a node that has the ability to forward packets. 835 In this case, the forwarding node's address must be manually 836 configured in hosts to be able to send packets off-link, since the 837 only mechanism to configure the default router's address 838 automatically is the one using Router Advertisements. 840 5.5.3 Router Advertisement Processing 842 For each Prefix-Information option in the Router Advertisement: 844 a) If the Autonomous flag is not set, silently ignore the Prefix 845 Information option. 847 b) If the prefix is the link-local prefix, silently ignore the 848 Prefix Information option. 850 c) If the preferred lifetime is greater than the valid lifetime, 851 silently ignore the Prefix Information option. A node MAY wish to 852 log a system management error in this case. 854 d) If the prefix advertised is not equal to the prefix of an address 855 configured by stateless autoconfiguration already in the list of 856 addresses associated with the interface (where "equal" means the 857 two prefix lengths are the same and the first prefix-length bits 858 of the prefixes are identical), and the Valid Lifetime is not 0, 859 form an address (and add it to the list) by combining the 860 advertised prefix with the link's interface identifier as follows: 862 | 128 - N bits | N bits | 863 +---------------------------------------+------------------------+ 864 | link prefix | interface identifier | 865 +----------------------------------------------------------------+ 867 If the sum of the prefix length and interface identifier length 868 does not equal 128 bits, the Prefix Information option MUST be 869 ignored. An implementation MAY wish to log a system management 870 error in this case. The length of the interface identifier is 871 defined in a separate link-type specific document, which should 872 also be consistent with the address architecture [RFC3513] (see 873 Section 2). 875 It is the responsibility of the system administrator to insure 876 that the lengths of prefixes contained in Router Advertisements 877 are consistent with the length of interface identifiers for that 878 link type. It should be noted, however, that this does not mean 879 the advertised prefix length is meaningless. In fact, the 880 advertised length has non trivial meaning for on-link 881 determination in [RFC2461] where the sum of the prefix length and 882 the interface identifier length may not be equal to 128. Thus, it 883 should be safe to validate the advertised prefix length here, in 884 order to detect and avoid a configuration error specifying an 885 invalid prefix length in the context of address autoconfiguration. 887 Note that a future revision of the address architecture [RFC3513] 888 and a future link-type specific document, which will still be 889 consistent with each other, could potentially allow for an 890 interface identifier of length other than the value defined in the 891 current documents. Thus, an implementation should not assume a 892 particular constant. Rather, it should expect any lengths of 893 interface identifiers. 895 If an address is formed successfully, the host adds it to the list 896 of addresses assigned to the interface, initializing its preferred 897 and valid lifetime values from the Prefix Information option. 899 e) If the advertised prefix is equal to the prefix of an address 900 configured by stateless autoconfiguration in the list, the 901 preferred lifetime of the address is reset to the Preferred 902 Lifetime in the received advertisement. The specific action to 903 perform for the valid lifetime of the address depends on the Valid 904 Lifetime in the received advertisement and the remaining time to 905 the valid lifetime expiration of the previously autoconfigured 906 address. We call the remaining time "RemainingLifetime" in the 907 following discussion: 909 1. If the received Valid Lifetime is greater than 2 hours or 910 greater than RemainingLifetime, set the valid lifetime of the 911 corresponding address to the advertised Valid Lifetime. 913 2. If RemainingLifetime is less than or equal to 2 hours, ignore 914 the Prefix Information option with regards to the valid 915 lifetime, unless the Router Advertisement from which this 916 option was obtained has been authenticated (e.g., via IP 917 security [RFC2402]). If the Router Advertisement was 918 authenticated, the valid lifetime of the corresponding address 919 should be set to the Valid Lifetime in the received option. 921 3. Otherwise, reset the valid lifetime of the corresponding 922 address to two hours. 924 The above rules address a specific denial of service attack in 925 which a bogus advertisement could contain prefixes with very small 926 Valid Lifetimes. Without the above rules, a single 927 unauthenticated advertisement containing bogus Prefix Information 928 options with short Valid Lifetimes could cause all of a node's 929 addresses to expire prematurely. The above rules ensure that 930 legitimate advertisements (which are sent periodically) will 931 "cancel" the short Valid Lifetimes before they actually take 932 effect. 934 Note that the preferred lifetime of the corresponding address is 935 always reset to the Preferred Lifetime in the received Prefix 936 Information option, regardless of whether the valid lifetime is 937 also reset or ignored. The difference comes from the fact that 938 the possible attack for the preferred lifetime is relatively 939 minor. Additionally, it is even undesirable to ignore the 940 preferred lifetime when a valid administrator wants to deprecate a 941 particular address by sending a short preferred lifetime (and the 942 valid lifetime is ignored by accident). 944 5.5.4 Address Lifetime Expiry 946 A preferred address becomes deprecated when its preferred lifetime 947 expires. A deprecated address SHOULD continue to be used as a source 948 address in existing communications, but SHOULD NOT be used to 949 initiate new communications if an alternate (non-deprecated) address 950 of sufficient scope can easily be used instead. 952 Note that the feasibility of initiating new communication using a 953 non-deprecated address may be an application-specific decision, as 954 only the application may have knowledge about whether the (now) 955 deprecated address was (or still is) in use by the application. For 956 example, if an application explicitly specifies the protocol stack to 957 use a deprecated address as a source address, the protocol stack must 958 accept that; the application might request it because that IP address 959 is used for in higher-level communication and there might be a 960 requirement that the multiple connections in such a grouping use the 961 same pair of IP addresses. 963 IP and higher layers (e.g., TCP, UDP) MUST continue to accept and 964 process datagrams destined to a deprecated address as normal since a 965 deprecated address is still a valid address for the interface. In 966 the case of TCP, this means TCP SYN segments sent to a deprecated 967 address are responded to using the deprecated address as a source 968 address in the corresponding SYN-ACK (if the connection would 969 otherwise be allowed). 971 An implementation MAY prevent any new communication from using a 972 deprecated address, but system management MUST have the ability to 973 disable such a facility, and the facility MUST be disabled by 974 default. 976 Other subtle cases should also be noted about source address 977 selection. For example, the above description does not clarify which 978 address should be used between a deprecated, smaller-scope address 979 and a non-deprecated, enough scope address. The details of the 980 address selection including this case are described in [RFC3484] and 981 beyond the scope of this document. 983 An address (and its association with an interface) becomes invalid 984 when its valid lifetime expires. An invalid address MUST NOT be used 985 as a source address in outgoing communications and MUST NOT be 986 recognized as a destination on a receiving interface. 988 5.6 Configuration Consistency 990 It is possible for hosts to obtain address information using both 991 stateless and stateful protocols since both may be enabled at the 992 same time. It is also possible that the values of other 993 configuration parameters such as MTU size and hop limit will be 994 learned from both Router Advertisements and the stateful 995 autoconfiguration protocol. If the same configuration information is 996 provided by multiple sources, the value of this information should be 997 consistent. However, it is not considered a fatal error if 998 information received from multiple sources is inconsistent. Hosts 999 accept the union of all information received via the stateless and 1000 stateful protocols. If inconsistent information is learned from 1001 different sources, the most recently obtained values always have 1002 precedence over information learned earlier. 1004 5.7 Retaining Configured Addresses for Stability 1006 An implementation that has stable storage may want to retain 1007 addresses in the storage when the addresses were acquired using 1008 stateless address autoconfiguration. Assuming the lifetimes used are 1009 reasonable, this technique implies that a temporary outage (less than 1010 the valid lifetime) of a router will never result in the node losing 1011 its global address even if the node were to reboot. When this 1012 technique is used, it should also be noted that the expiration times 1013 of the preferred and valid lifetimes must be retained, in order to 1014 prevent the use of an address after it has become deprecated or 1015 invalid. 1017 Further details on this kind of extension are beyond the scope of 1018 this document. 1020 6. SECURITY CONSIDERATIONS 1022 Stateless address autoconfiguration allows a host to connect to a 1023 network, configure an address and start communicating with other 1024 nodes without ever registering or authenticating itself with the 1025 local site. Although this allows unauthorized users to connect to 1026 and use a network, the threat is inherently present in the Internet 1027 architecture. Any node with a physical attachment to a network can 1028 generate an address (using a variety of ad hoc techniques) that 1029 provides connectivity. 1031 The use of stateless address autoconfiguration and Duplicate Address 1032 Detection opens up the possibility of several denial of service 1033 attacks. For example, any node can respond to Neighbor Solicitations 1034 for a tentative address, causing the other node to reject the address 1035 as a duplicate. A separate document [RFC3756] discusses details 1036 about these attacks. These attacks can be addressed by requiring 1037 that Neighbor Discovery packets be authenticated with IP security 1038 [RFC2402]. However, it should be noted that [RFC3756] points out the 1039 use of IP security is not always feasible depending on network 1040 environments. 1042 7. IANA CONSIDERATIONS 1044 This document has no actions for IANA. 1046 8. Acknowledgements 1048 The authors would like to thank the members of both the IPNG (which 1049 is now IPV6) and ADDRCONF working groups for their input. In 1050 particular, thanks to Jim Bound, Steve Deering, Richard Draves, and 1051 Erik Nordmark. Thanks also goes to John Gilmore for alerting the WG 1052 of the "0 Lifetime Prefix Advertisement" denial of service attack 1053 vulnerability; this document incorporates changes that address this 1054 vulnerability. 1056 A number of people have contributed to identifying issues on a 1057 previous version of this document and to proposing resolutions to the 1058 issues, on which this version is based. In addition to those listed 1059 above, the contributors include Jari Arkko, Brian E Carpenter, 1060 Gregory Daley, Ralph Droms, Jun-ichiro itojun Hagino, Christian 1061 Huitema, Suresh Krishnan, Soohong Daniel Park, Markku Savela, and 1062 Pekka Savola. 1064 9. References 1066 9.1 Normative References 1068 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 1069 2402, November 1998. 1071 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1072 Networks", RFC 2464, December 1998. 1074 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1075 Requirement Levels", BCP 14, RFC 2119, March 1997. 1077 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1078 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1080 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 1081 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1082 1998. 1084 9.2 Informative References 1086 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 1087 M. Carney, "Dynamic Host Configuration Protocol for IPv6 1088 (DHCPv6)", RFC 3315, July 2003. 1090 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1091 (DHCP) Service for IPv6", RFC 3736, April 2004. 1093 [RFC3484] Draves, R., "Default Address Selection for Internet 1094 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1096 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 1097 Stateless Address Autoconfiguration in IPv6", RFC 3041, 1098 January 2001. 1100 [I-D.ietf-send-cga] 1101 Aura, T., "Cryptographically Generated Addresses (CGA)", 1102 draft-ietf-send-cga-06 (work in progress), April 2004. 1104 [RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast 1105 Listener Discovery (MLD) for IPv6", RFC 2710, October 1106 1999. 1108 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 1109 Listener Discovery (MLD) Protocol", RFC 3590, September 1110 2003. 1112 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 1113 Discovery (ND) Trust Models and Threats", RFC 3756, May 1114 2004. 1116 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1117 RFC 1112, August 1989. 1119 [IEEE802.11] 1120 IEEE, "Wireless LAN Medium Access Control (MAC) and 1121 Physical Layer (PHY) Specifications", ANSI/IEEE STd 1122 802.11, August 1999. 1124 Authors' Addresses 1126 Susan Thomson 1127 Cisco Systems 1129 EMail: sethomso@cisco.com 1130 Thomas Narten 1131 IBM Corporation 1132 P.O. Box 12195 1133 Research Triangle Park, NC 27709-2195 1134 USA 1136 Phone: +1 919-254-7798 1137 EMail: narten@us.ibm.com 1139 Tatuya Jinmei 1140 Corporate Research & Development Center, Toshiba Corporation 1141 1 Komukai Toshiba-cho, Saiwai-ku 1142 Kawasaki-shi, Kanagawa 212-8582 1143 Japan 1145 Phone: +81 44-549-2230 1146 EMail: jinmei@isl.rdc.toshiba.co.jp 1148 Appendix A. LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION 1150 Determining whether a received multicast solicitation was looped back 1151 to the sender or actually came from another node is implementation- 1152 dependent. A problematic case occurs when two interfaces attached to 1153 the same link happen to have the same identifier and link-layer 1154 address, and they both send out packets with identical contents at 1155 roughly the same time (e.g., Neighbor Solicitations for a tentative 1156 address as part of Duplicate Address Detection messages). Although a 1157 receiver will receive both packets, it cannot determine which packet 1158 was looped back and which packet came from the other node by simply 1159 comparing packet contents (i.e., the contents are identical). In 1160 this particular case, it is not necessary to know precisely which 1161 packet was looped back and which was sent by another node; if one 1162 receives more solicitations than were sent, the tentative address is 1163 a duplicate. However, the situation may not always be this 1164 straightforward. 1166 The IPv4 multicast specification [RFC1112] recommends that the 1167 service interface provide a way for an upper-layer protocol to 1168 inhibit local delivery of packets sent to a multicast group that the 1169 sending host is a member of. Some applications know that there will 1170 be no other group members on the same host, and suppressing loopback 1171 prevents them from having to receive (and discard) the packets they 1172 themselves send out. A straightforward way to implement this 1173 facility is to disable loopback at the hardware level (if supported 1174 by the hardware), with packets looped back (if requested) by 1175 software. On interfaces in which the hardware itself suppresses 1176 loopbacks, a node running Duplicate Address Detection simply counts 1177 the number of Neighbor Solicitations received for a tentative address 1178 and compares them with the number expected. If there is a mismatch, 1179 the tentative address is a duplicate. 1181 In those cases where the hardware cannot suppress loopbacks, however, 1182 one possible software heuristic to filter out unwanted loopbacks is 1183 to discard any received packet whose link-layer source address is the 1184 same as the receiving interface's. There is even a link-layer 1185 specification that requires to discard any such packets [IEEE802.11]. 1186 Unfortunately, use of that criteria also results in the discarding of 1187 all packets sent by another node using the same link-layer address. 1188 Duplicate Address Detection will fail on interfaces that filter 1189 received packets in this manner: 1191 o If a node performing Duplicate Address Detection discards received 1192 packets having the same source link-layer address as the receiving 1193 interface, it will also discard packets from other nodes also 1194 using the same link-layer address, including Neighbor 1195 Advertisement and Neighbor Solicitation messages required to make 1196 Duplicate Address Detection work correctly. This particular 1197 problem can be avoided by temporarily disabling the software 1198 suppression of loopbacks while a node performs Duplicate Address 1199 Detection, if it is possible to disable the suppression. 1201 o If a node that is already using a particular IP address discards 1202 received packets having the same link-layer source address as the 1203 interface, it will also discard Duplicate Address 1204 Detection-related Neighbor Solicitation messages sent by another 1205 node also using the same link-layer address. Consequently, 1206 Duplicate Address Detection will fail, and the other node will 1207 configure a non-unique address. Since it is generally impossible 1208 to know when another node is performing Duplicate Address 1209 Detection, this scenario can be avoided only if software 1210 suppression of loopback is permanently disabled. 1212 Thus, to perform Duplicate Address Detection correctly in the case 1213 where two interfaces are using the same link-layer address, an 1214 implementation must have a good understanding of the interface's 1215 multicast loopback semantics, and the interface cannot discard 1216 received packets simply because the source link-layer address is the 1217 same as the interface's. It should also be noted that a link-layer 1218 specification can conflict with the condition necessary to make 1219 Duplicate Address Detection work. 1221 Appendix B. CHANGES SINCE RFC 1971 1223 o Changed document to use term "interface identifier" rather than 1224 "interface token" for consistency with other IPv6 documents. 1226 o Clarified definition of deprecated address to make clear it is OK 1227 to continue sending to or from deprecated addresses. 1228 o Added rules to Section 5.5.3 Router Advertisement processing to 1229 address potential denial-of-service attack when prefixes are 1230 advertised with very short Lifetimes. 1231 o Clarified wording in Section 5.5.4 to make clear that all upper 1232 layer protocols must process (i.e., send and receive) packets sent 1233 to deprecated addresses. 1235 Appendix C. CHANGES SINCE RFC 2462 1237 Major changes that can affect existing implementations: 1239 o Specified that a node performing Duplicate Address Detection delay 1240 joining the solicited-node multicast group, not just delay sending 1241 Neighbor Solicitations, explaining the detailed reason. 1242 o Added a requirement for a random delay before sending Neighbor 1243 Solicitations for Duplicate Address Detection if the address being 1244 checked is configured by a multicasted Router Advertisements. 1245 o Clarified that on failure of Duplicate Address Detection, IP 1246 network operation should be disabled and that the rule should 1247 apply when the hardware address is supposed to be unique. 1249 Major clarifications: 1251 o Clarified how the length of interface identifiers should be 1252 determined, described the relationship with the prefix length 1253 advertised in Router Advertisements, and avoided using a 1254 particular length hard-coded in this document. 1255 o Clarified that the "stateful" protocols for address configuration 1256 and other information configuration are RFC 3315 and RFC 3736, 1257 respectively. 1258 o Clarified the semantics of the M and O flags based on the latest 1259 standard and operational status. In particular, clarified that 1260 these flags show the availability of the stateful protocol instead 1261 of a trigger to invoke the stateful protocol. ManagedFlag and 1262 OtherConfigFlag, which were implementation-internal variables, 1263 were removed accordingly. 1264 o Recommended to perform Duplicate Address Detection for all unicast 1265 addresses more strongly, considering a variety of different 1266 interface identifiers, while keeping care of existing 1267 implementations. 1268 o Clarified wording in Section 5.5.4 to make clear that a deprecated 1269 address specified by an application should be used for any 1270 communication. 1271 o Revised the Security Considerations section with a reference to 1272 RFC 3756 and a note that the use of IP security is not always 1273 feasible. 1275 o Added a note when an implementation uses stable storage for 1276 autoconfigured addresses. 1278 Other miscellaneous clarifications: 1280 o Removed references to site-local and revised wording around the 1281 keyword. 1282 o Removed redundant code in denial of service protection in Section 1283 5.5.3. 1284 o Clarified that a unicasted Neighbor Solicitation or Advertisement 1285 should be discarded while performing Duplicate Address Detection. 1287 Appendix D. CHANGE HISTORY 1289 [NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION UPON PUBLICATION.] 1291 Changes in draft-ietf-ipv6-rfc2462bis-00.txt since RFC 2462 are: 1293 o Fixed a typo in Section 2. 1294 o Updated references and categorized them into normative and 1295 informative ones. 1296 o Removed redundant code in denial of service protection in Section 1297 5.5.3. 1298 o Clarified that a unicasted NS or NA should be discarded while 1299 performing Duplicate Address Detection. 1300 o Replaced the word "StoredLifetime" with "RemainingLifetime" with a 1301 precise definition to avoid confusion. 1302 o Removed references to site-local and revised wording around the 1303 keyword. 1304 o Added a note about source address selection with regards to 1305 deprecated vs insufficient-scope addresses, etc. Added a 1306 reference to RFC 3484 for further details. 1307 o Clarified what "new communication" means in Section 5.5.4. 1308 o Added a new subsection (5.7) to mention the possibility to use 1309 stable storage to retain configured addresses for stability. 1310 o Revised the Security Considerations section with a reference to 1311 RFC 3756 and a note that the use of IP security is not always 1312 feasible. 1313 o Added a note with a reference in Appendix A about the case where a 1314 link-layer filtering conflicts with a condition to make Duplicate 1315 Address Detection work correctly. 1316 o Specified that a node performing Duplicate Address Detection delay 1317 joining the solicited-node multicast group, not just delay sending 1318 Neighbor Solicitations, explaining the detailed reason. 1319 o Clarified the reason why the interface should be disabled after an 1320 address duplicate is detected. Also clarified that the interface 1321 may continue to be used if the interface identifier is not based 1322 on the hardware address. 1324 o Clarified that the preferred lifetime for an existing configured 1325 address is always reset to the advertised value by Router 1326 Advertisement. 1327 o Updated the description of interface identifier considering the 1328 latest format. 1330 Changes since draft-ietf-ipv6-rfc2462bis-00.txt are: 1332 o Clarified how the length of interface identifiers should be 1333 determined, described the relationship with the prefix length 1334 advertised in Router Advertisements, and avoided using a 1335 particular length hard-coded in this document. 1336 o Added a note when an implementation uses stable storage for 1337 autoconfigured addresses. 1338 o Resolved conflict with the Multicast Listener Discovery 1339 specification about random delay for the first packet from the 1340 host. 1341 o Clarified the semantics of the M and O flags based on the latest 1342 standard and operational status. In particular, clarified that 1343 these flags show the availability of the stateful protocol instead 1344 of a trigger to invoke the stateful protocol. ManagedFlag and 1345 OtherConfigFlag, which were implementation-internal variables, 1346 were removed accordingly. 1347 o Recommended to perform Duplicate Address Detection for all unicast 1348 addresses more strongly, considering a variety of different 1349 interface identifiers, while keeping care of existing 1350 implementations. 1351 o Added a requirement for a random delay before sending Neighbor 1352 Solicitations for Duplicate Address Detection if the address being 1353 checked is configured by a multicasted Router Advertisements. 1354 o Clarified that the prefix comparison in Section 5.5.3 is based on 1355 exact match. Also clarified the comparison described in this 1356 document concentrates on addresses configured by the stateless 1357 mechanism. 1358 o Revisited the author list. 1359 o Added IANA Considerations Section. 1361 Changes since draft-ietf-ipv6-rfc2462bis-02.txt are: 1363 o Updated the I-D / IPR boilerplate to the latest ones. Applied 1364 other editorial changes to conform to I-D nits. 1365 o Clarified that it is IP network operation that should be disabled 1366 on failure of Duplicate Address Detection, and that the rule 1367 should apply when the hardware address is supposed to be unique. 1368 o Changed the reference on the algorithm of computing solicited-node 1369 multicast addresses to [RFC3513]. 1370 o Made the intent clearer in the clarification that unicasted NS or 1371 NA should be discarded during Duplicate Address Detection. 1373 Changes since draft-ietf-ipv6-rfc2462bis-03.txt are: 1375 o Added an informative reference to [RFC3590]. 1376 o Summarized major changes since RFC 2462 to prepare for 1377 publication. 1379 Intellectual Property Statement 1381 The IETF takes no position regarding the validity or scope of any 1382 Intellectual Property Rights or other rights that might be claimed to 1383 pertain to the implementation or use of the technology described in 1384 this document or the extent to which any license under such rights 1385 might or might not be available; nor does it represent that it has 1386 made any independent effort to identify any such rights. Information 1387 on the procedures with respect to rights in RFC documents can be 1388 found in BCP 78 and BCP 79. 1390 Copies of IPR disclosures made to the IETF Secretariat and any 1391 assurances of licenses to be made available, or the result of an 1392 attempt made to obtain a general license or permission for the use of 1393 such proprietary rights by implementers or users of this 1394 specification can be obtained from the IETF on-line IPR repository at 1395 http://www.ietf.org/ipr. 1397 The IETF invites any interested party to bring to its attention any 1398 copyrights, patents or patent applications, or other proprietary 1399 rights that may cover technology that may be required to implement 1400 this standard. Please address the information to the IETF at 1401 ietf-ipr@ietf.org. 1403 Disclaimer of Validity 1405 This document and the information contained herein are provided on an 1406 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1407 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1408 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1409 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1410 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1411 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1413 Copyright Statement 1415 Copyright (C) The Internet Society (2004). This document is subject 1416 to the rights, licenses and restrictions contained in BCP 78, and 1417 except as set forth therein, the authors retain all their rights. 1419 Acknowledgment 1421 Funding for the RFC Editor function is currently provided by the 1422 Internet Society.