idnits 2.17.1 draft-ietf-ipv6-rfc2462bis-06.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 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1455. ** 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, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (September 3, 2004) is 7175 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) == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-00 -- 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: 7 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF IPv6 Working Group S. Thomson 2 Internet-Draft Cisco 3 Expires: March 4, 2005 T. Narten 4 IBM 5 T. Jinmei 6 Toshiba 7 September 3, 2004 9 IPv6 Stateless Address Autoconfiguration 10 draft-ietf-ipv6-rfc2462bis-06.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of 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 March 4, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 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 are specified in RFC 54 3315; an alternative way of using the stateful protocol to deliver 55 'other information' only is specified in 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 . . . . . . . . . . . . . . . . . . . . . 11 65 5. PROTOCOL SPECIFICATION . . . . . . . . . . . . . . . . . . . . 11 66 5.1 Node Configuration Variables . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . 15 71 5.4.2 Sending Neighbor Solicitation Messages . . . . . . . . 15 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 . . . . . . . . . . . 19 79 5.5.4 Address Lifetime Expiry . . . . . . . . . . . . . . . 21 80 5.6 Configuration Consistency . . . . . . . . . . . . . . . . 22 81 5.7 Retaining Configured Addresses for Stability . . . . . . . 22 82 6. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . 23 83 7. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . 23 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 87 9.2 Informative References . . . . . . . . . . . . . . . . . . . 24 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 89 A. LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION . . . . . . 25 90 B. CHANGES SINCE RFC 1971 . . . . . . . . . . . . . . . . . . . . 27 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 [I-D.ietf-ipv6-2461bis]. 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. The protocol 216 described in this document will be used on all types of links 217 unless specified otherwise in the link type specific document 218 describing how to operate IP on the link in line with 219 [I-D.ietf-ipv6-2461bis]. 221 interface - a node's attachment to a link. 223 packet - an IP header plus payload. 225 address - an IP-layer identifier for an interface or a set of 226 interfaces. 228 unicast address - an identifier for a single interface. A packet 229 sent to a unicast address is delivered to the interface identified 230 by that address. 232 multicast address - an identifier for a set of interfaces (typically 233 belonging to different nodes). A packet sent to a multicast 234 address is delivered to all interfaces identified by that address. 236 anycast address - an identifier for a set of interfaces (typically 237 belonging to different nodes). A packet sent to an anycast 238 address is delivered to one of the interfaces identified by that 239 address (the "nearest" one, according to the routing protocol's 240 measure of distance). See [RFC3513]. 242 solicited-node multicast address - a multicast address to which 243 Neighbor Solicitation messages are sent. The algorithm for 244 computing the address is given in [RFC3513]. 246 link-layer address - a link-layer identifier for an interface. 247 Examples include IEEE 802 addresses for Ethernet links and E.164 248 addresses for ISDN links. 250 link-local address - an address having link-only scope that can be 251 used to reach neighboring nodes attached to the same link. All 252 interfaces have a link-local unicast address. 254 global address - an address with unlimited scope. 256 communication - any packet exchange among nodes that requires that 257 the address of each node used in the exchange remain the same for 258 the duration of the packet exchange. Examples are a TCP 259 connection or a UDP request-response. 261 tentative address - an address whose uniqueness on a link is being 262 verified, prior to its assignment to an interface. A tentative 263 address is not considered assigned to an interface in the usual 264 sense. An interface discards received packets addressed to a 265 tentative address, but accepts Neighbor Discovery packets related 266 to Duplicate Address Detection for the tentative address. 268 preferred address - an address assigned to an interface whose use by 269 upper layer protocols is unrestricted. Preferred addresses may be 270 used as the source (or destination) address of packets sent from 271 (or to) the interface. 273 deprecated address - An address assigned to an interface whose use is 274 discouraged, but not forbidden. A deprecated address should no 275 longer be used as a source address in new communications, but 276 packets sent from or to deprecated addresses are delivered as 277 expected. A deprecated address may continue to be used as a 278 source address in communications where switching to a preferred 279 address causes hardship to a specific upper-layer activity (e.g., 280 an existing TCP connection). 282 valid address - a preferred or deprecated address. A valid address 283 may appear as the source or destination address of a packet, and 284 the internet routing system is expected to deliver packets sent to 285 a valid address to their intended recipients. 287 invalid address - an address that is not assigned to any interface. 288 A valid address becomes invalid when its valid lifetime expires. 289 Invalid addresses should not appear as the destination or source 290 address of a packet. In the former case, the internet routing 291 system will be unable to deliver the packet, in the latter case 292 the recipient of the packet will be unable to respond to it. 294 preferred lifetime - the length of time that a valid address is 295 preferred (i.e., the time until deprecation). When the preferred 296 lifetime expires, the address becomes deprecated. 298 valid lifetime - the length of time an address remains in the valid 299 state (i.e., the time until invalidation). The valid lifetime 300 must be greater than or equal to the preferred lifetime. When the 301 valid lifetime expires, the address becomes invalid. 303 interface identifier - a link-dependent identifier for an interface 304 that is (at least) unique per link [RFC3513]. Stateless address 305 autoconfiguration combines an interface identifier with a prefix 306 to form an address. From address autoconfiguration's perspective, 307 an interface identifier is a bit string of known length. The 308 exact length of an interface identifier and the way it is created 309 is defined in a separate link-type specific document that covers 310 issues related to the transmission of IP over a particular link 311 type (e.g., [RFC2464]). Note that the address architecture 312 [RFC3513] also defines the length of the interface identifiers for 313 some set of addresses, but the two sets of definitions must be 314 consistent. In many cases, the identifier will be derived from 315 the interface's link-layer address. 317 2.1 Requirements 319 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 320 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 321 document, are to be interpreted as described in [RFC2119]. 323 3. DESIGN GOALS 325 Stateless autoconfiguration is designed with the following goals in 326 mind: 328 o Manual configuration of individual machines before connecting them 329 to the network should not be required. Consequently, a mechanism 330 is needed that allows a host to obtain or create unique addresses 331 for each of its interfaces. Address autoconfiguration assumes 332 that each interface can provide a unique identifier for that 333 interface (i.e., an "interface identifier"). In the simplest 334 case, an interface identifier consists of the interface's 335 link-layer address. An interface identifier can be combined with 336 a prefix to form an address. 338 o Small sites consisting of a set of machines attached to a single 339 link should not require the presence of a stateful server or 340 router as a prerequisite for communicating. Plug-and-play 341 communication is achieved through the use of link-local addresses. 342 Link-local addresses have a well-known prefix that identifies the 343 (single) shared link to which a set of nodes attach. A host forms 344 a link-local address by appending its interface identifier to the 345 link-local prefix. 347 o A large site with multiple networks and routers should not require 348 the presence of a stateful address configuration server. In order 349 to generate global addresses, hosts must determine the prefixes 350 that identify the subnets to which they attach. Routers generate 351 periodic Router Advertisements that include options listing the 352 set of active prefixes on a link. 354 o Address configuration should facilitate the graceful renumbering 355 of a site's machines. For example, a site may wish to renumber 356 all of its nodes when it switches to a new network service 357 provider. Renumbering is achieved through the leasing of 358 addresses to interfaces and the assignment of multiple addresses 359 to the same interface. Lease lifetimes provide the mechanism 360 through which a site phases out old prefixes. The assignment of 361 multiple addresses to an interface provides for a transition 362 period during which both a new address and the one being phased 363 out work simultaneously. 365 o System administrators need the ability to specify whether 366 stateless autoconfiguration, stateful autoconfiguration, or both 367 are available. Router Advertisements include flags which can be 368 used to indicate which mechanisms are available. 370 4. PROTOCOL OVERVIEW 372 This section provides an overview of the typical steps that take 373 place when an interface autoconfigures itself. Autoconfiguration is 374 performed only on multicast-capable links and begins when a 375 multicast-capable interface is enabled, e.g., during system startup. 376 Nodes (both hosts and routers) begin the autoconfiguration process by 377 generating a link-local address for the interface. A link-local 378 address is formed by appending the interface's identifier to the 379 well-known link-local prefix. 381 Before the link-local address can be assigned to an interface and 382 used, however, a node must attempt to verify that this "tentative" 383 address is not already in use by another node on the link. 384 Specifically, it sends a Neighbor Solicitation message containing the 385 tentative address as the target. If another node is already using 386 that address, it will return a Neighbor Advertisement saying so. If 387 another node is also attempting to use the same address, it will send 388 a Neighbor Solicitation for the target as well. The exact number of 389 times the Neighbor Solicitation is (re)transmitted and the delay time 390 between consecutive solicitations is link-specific and may be set by 391 system management. 393 If a node determines that its tentative link-local address is not 394 unique, autoconfiguration stops and manual configuration of the 395 interface is required. To simplify recovery in this case, it should 396 be possible for an administrator to supply an alternate interface 397 identifier that overrides the default identifier in such a way that 398 the autoconfiguration mechanism can then be applied using the new 399 (presumably unique) interface identifier. Alternatively, link-local 400 and other addresses will need to be configured manually. 402 Once a node ascertains that its tentative link-local address is 403 unique, it assigns the address to the interface. At this point, the 404 node has IP-level connectivity with neighboring nodes. The remaining 405 autoconfiguration steps are performed only by hosts; the 406 (auto)configuration of routers is beyond the scope of this document. 408 The next phase of autoconfiguration involves obtaining a Router 409 Advertisement or determining that no routers are present. If routers 410 are present, they will send Router Advertisements that specify what 411 sort of autoconfiguration a host can do. Note that stateful 412 autoconfiguration may still be available even if no routers are 413 present. 415 Routers send Router Advertisements periodically, but the delay 416 between successive advertisements will generally be longer than a 417 host performing autoconfiguration will want to wait 418 [I-D.ietf-ipv6-2461bis]. To obtain an advertisement quickly, a host 419 sends one or more Router Solicitations to the all-routers multicast 420 group. Router Advertisements contain two flags indicating what type 421 of stateful autoconfiguration (if any) is available. A "managed 422 address configuration (M)" flag indicates whether hosts can use 423 stateful autoconfiguration [RFC3315] to obtain addresses. An "other 424 stateful configuration (O)" flag indicates whether hosts can use 425 stateful autoconfiguration [RFC3736] to obtain additional information 426 (excluding addresses). 428 The details of how a host may use the M flag, including any use of 429 the "on" and "off" transitions for this flag, to control the use of 430 the stateful protocol for address assignment will be described in a 431 separate document. Similarly, the details of how a host may use the 432 O flag, including any use of the "on" and "off" transitions for this 433 flag, to control the use of the stateful protocol for getting other 434 configuration information will be described in a separate document. 435 However a host uses the M and O flags, and local configuration to 436 control autoconfiguration, the default setting will result in 437 received Router Advertisements being processed for stateless address 438 autoconfiguration. 440 Router Advertisements also contain zero or more Prefix Information 441 options that contain information used by stateless address 442 autoconfiguration to generate global addresses. It should be noted 443 that the stateless and stateful address autoconfiguration fields in 444 Router Advertisements are processed independently of one another, and 445 a host may use both stateful and stateless address autoconfiguration 446 simultaneously. One Prefix Information option field, the "autonomous 447 address-configuration flag", indicates whether or not the option even 448 applies to stateless autoconfiguration. If it does, additional 449 option fields contain a subnet prefix together with lifetime values 450 indicating how long addresses created from the prefix remain 451 preferred and valid. 453 Because routers generate Router Advertisements periodically, hosts 454 will continually receive new advertisements. Hosts process the 455 information contained in each advertisement as described above, 456 adding to and refreshing information received in previous 457 advertisements. 459 For safety, all addresses must be tested for uniqueness prior to 460 their assignment to an interface. The test should individually be 461 performed on all addresses obtained manually, via stateless address 462 autoconfiguration, or via stateful address autoconfiguration. To 463 accommodate sites that believe the overhead of performing Duplicate 464 Address Detection outweighs its benefits, the use of Duplicate 465 Address Detection can be disabled through the administrative setting 466 of a per-interface configuration flag. 468 To speed the autoconfiguration process, a host may generate its 469 link-local address (and verify its uniqueness) in parallel with 470 waiting for a Router Advertisement. Because a router may delay 471 responding to a Router Solicitation for a few seconds, the total time 472 needed to complete autoconfiguration can be significantly longer if 473 the two steps are done serially. 475 4.1 Site Renumbering 477 Address leasing facilitates site renumbering by providing a mechanism 478 to time-out addresses assigned to interfaces in hosts. At present, 479 upper layer protocols such as TCP provide no support for changing 480 end-point addresses while a connection is open. If an end-point 481 address becomes invalid, existing connections break and all 482 communication to the invalid address fails. Even when applications 483 use UDP as a transport protocol, addresses must generally remain the 484 same during a packet exchange. 486 Dividing valid addresses into preferred and deprecated categories 487 provides a way of indicating to upper layers that a valid address may 488 become invalid shortly and that future communication using the 489 address will fail, should the address's valid lifetime expire before 490 communication ends. To avoid this scenario, higher layers should use 491 a preferred address (assuming one of sufficient scope exists) to 492 increase the likelihood that an address will remain valid for the 493 duration of the communication. It is up to system administrators to 494 set appropriate prefix lifetimes in order to minimize the impact of 495 failed communication when renumbering takes place. The deprecation 496 period should be long enough that most, if not all, communications 497 are using the new address at the time an address becomes invalid. 499 The IP layer is expected to provide a means for upper layers 500 (including applications) to select the most appropriate source 501 address given a particular destination and possibly other 502 constraints. An application may choose to select the source address 503 itself before starting a new communication or may leave the address 504 unspecified, in which case the upper networking layers will use the 505 mechanism provided by the IP layer to choose a suitable address on 506 the application's behalf. 508 Detailed address selection rules are beyond the scope of this 509 document and are described in [RFC3484]. 511 5. PROTOCOL SPECIFICATION 513 Autoconfiguration is performed on a per-interface basis on 514 multicast-capable interfaces. For multihomed hosts, 515 autoconfiguration is performed independently on each interface. 516 Autoconfiguration applies primarily to hosts, with two exceptions. 517 Routers are expected to generate a link-local address using the 518 procedure outlined below. In addition, routers perform Duplicate 519 Address Detection on all addresses prior to assigning them to an 520 interface. 522 5.1 Node Configuration Variables 524 A node MUST allow the following autoconfiguration-related variable to 525 be configured by system management for each multicast-capable 526 interface: 528 DupAddrDetectTransmits 530 The number of consecutive Neighbor Solicitation messages sent 531 while performing Duplicate Address Detection on a tentative 532 address. A value of zero indicates that Duplicate Address 533 Detection is not performed on tentative addresses. A value of one 534 indicates a single transmission with no follow up retransmissions. 536 Default: 1, but may be overridden by a link-type specific value in 537 the document that covers issues related to the transmission of IP 538 over a particular link type (e.g., [RFC2464]). 540 Autoconfiguration also assumes the presence of the variable 541 RetransTimer as defined in [I-D.ietf-ipv6-2461bis]. For 542 autoconfiguration purposes, RetransTimer specifies the delay 543 between consecutive Neighbor Solicitation transmissions performed 544 during Duplicate Address Detection (if DupAddrDetectTransmits is 545 greater than 1), as well as the time a node waits after sending 546 the last Neighbor Solicitation before ending the Duplicate Address 547 Detection process. 549 5.2 Autoconfiguration-Related Structures 551 Beyond the formation of a link-local address and using Duplicate 552 Address Detection, how routers (auto)configure their interfaces is 553 beyond the scope of this document. 555 A host maintains a list of addresses together with their 556 corresponding lifetimes. The address list contains both 557 autoconfigured addresses and those configured manually. 559 5.3 Creation of Link-Local Addresses 561 A node forms a link-local address whenever an interface becomes 562 enabled. An interface may become enabled after any of the following 563 events: 565 - The interface is initialized at system startup time. 567 - The interface is reinitialized after a temporary interface failure 568 or after being temporarily disabled by system management. 570 - The interface attaches to a link for the first time. 572 - The interface becomes enabled by system management after having 573 been administratively disabled. 575 A link-local address is formed by combining the well-known link-local 576 prefix FE80::0 [RFC3513] (of appropriate length) with the interface 577 identifier as follows: 579 1. The left-most 'prefix length' bits of the address are those of 580 the link-local prefix. 582 2. The bits in the address to the right of the link-local prefix are 583 set to all zeroes. 585 3. If the length of the interface identifier is N bits, the 586 right-most N bits of the address are replaced by the interface 587 identifier. 589 If the sum of the link-local prefix length and N is larger than 128, 590 autoconfiguration fails and manual configuration is required. The 591 length of the interface identifier is defined in a separate link-type 592 specific document, which should also be consistent with the address 593 architecture [RFC3513] (see Section 2). These documents will 594 carefully define the length so that link-local addresses can be 595 autoconfigured on the link. 597 A link-local address has an infinite preferred and valid lifetime; it 598 is never timed out. 600 5.4 Duplicate Address Detection 602 Duplicate Address Detection MUST be performed on all unicast 603 addresses prior to assigning them to an interface, regardless of 604 whether they are obtained through stateful, stateless or manual 605 configuration, with the following exceptions: 607 - An interface whose DupAddrDetectTransmits variable is set to zero 608 does not perform Duplicate Address Detection, 610 - Duplicate Address Detection MUST NOT be performed on anycast 611 addresses (note that anycast addresses cannot syntactically be 612 distinguished from unicast addresses), and 614 - Each individual unicast address SHOULD be tested for uniqueness. 615 Note that there are implementations deployed that only perform 616 Duplicate Address Detection for the link-local address and skip 617 the test for the global address using the same interface 618 identifier as that of the link-local address. Whereas this 619 document does not invalidate such implementations, this kind of 620 "optimization" is NOT RECOMMENDED, and new implementations MUST 621 NOT do that optimization. This optimization came from the 622 assumption that all of an interface's addresses are generated from 623 the same identifier. However, the assumption does actually not 624 stand; new types of addresses have been introduced where the 625 interface identifiers are not necessarily the same for all unicast 626 addresses on a single interface [RFC3041][I-D.ietf-send-cga]. 627 Requiring to perform Duplicate Address Detection for all unicast 628 addresses will make the algorithm robust for the current and 629 future such special interface identifiers. 631 The procedure for detecting duplicate addresses uses Neighbor 632 Solicitation and Advertisement messages as described below. If a 633 duplicate address is discovered during the procedure, the address 634 cannot be assigned to the interface. If the address is derived from 635 an interface identifier, a new identifier will need to be assigned to 636 the interface, or all IP addresses for the interface will need to be 637 manually configured. Note that the method for detecting duplicates 638 is not completely reliable, and it is possible that duplicate 639 addresses will still exist (e.g., if the link was partitioned while 640 Duplicate Address Detection was performed). 642 An address on which the Duplicate Address Detection procedure is 643 applied is said to be tentative until the procedure has completed 644 successfully. A tentative address is not considered "assigned to an 645 interface" in the traditional sense. That is, the interface must 646 accept Neighbor Solicitation and Advertisement messages containing 647 the tentative address in the Target Address field, but processes such 648 packets differently from those whose Target Address matches an 649 address assigned to the interface. Other packets addressed to the 650 tentative address should be silently discarded. Note that the "other 651 packets" include Neighbor Solicitation and Advertisement messages 652 which have the tentative (i.e., unicast) address as the IP 653 destination address and contain the tentative address in the Target 654 Address field. Such a case should not happen in normal operation, 655 though, since these messages are multicasted in the Duplicate Address 656 Detection procedure. 658 It should also be noted that Duplicate Address Detection must be 659 performed prior to assigning an address to an interface in order to 660 prevent multiple nodes from using the same address simultaneously. 661 If a node begins using an address in parallel with Duplicate Address 662 Detection, and another node is already using the address, the node 663 performing Duplicate Address Detection will erroneously process 664 traffic intended for the other node, resulting in such possible 665 negative consequences as the resetting of open TCP connections. 667 The following subsections describe specific tests a node performs to 668 verify an address's uniqueness. An address is considered unique if 669 none of the tests indicate the presence of a duplicate address within 670 RetransTimer milliseconds after having sent DupAddrDetectTransmits 671 Neighbor Solicitations. Once an address is determined to be unique, 672 it may be assigned to an interface. 674 5.4.1 Message Validation 676 A node MUST silently discard any Neighbor Solicitation or 677 Advertisement message that does not pass the validity checks 678 specified in [I-D.ietf-ipv6-2461bis]. A Neighbor Solicitation or 679 Advertisement message that passes these validity checks is called a 680 valid solicitation or valid advertisement, respectively. 682 5.4.2 Sending Neighbor Solicitation Messages 684 Before sending a Neighbor Solicitation, an interface MUST join the 685 all-nodes multicast address and the solicited-node multicast address 686 of the tentative address. The former ensures that the node receives 687 Neighbor Advertisements from other nodes already using the address; 688 the latter ensures that two nodes attempting to use the same address 689 simultaneously should detect each other's presence. 691 To check an address, a node sends DupAddrDetectTransmits Neighbor 692 Solicitations, each separated by RetransTimer milliseconds. The 693 solicitation's Target Address is set to the address being checked, 694 the IP source is set to the unspecified address and the IP 695 destination is set to the solicited-node multicast address of the 696 target address. 698 If the Neighbor Solicitation is going to be the first message to be 699 sent from an interface after interface (re)initialization, the node 700 SHOULD delay joining the solicited-node multicast address by a random 701 delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in 702 [I-D.ietf-ipv6-2461bis]. This serves to alleviate congestion when 703 many nodes start up on the link at the same time, such as after a 704 power failure, and may help to avoid race conditions when more than 705 one node is trying to solicit for the same address at the same time. 707 Even if the Neighbor Solicitation is not going to be the first 708 message to be sent, the node SHOULD delay joining the solicited-node 709 multicast address by a random delay between 0 and 710 MAX_RTR_SOLICITATION_DELAY if the address being checked is configured 711 by a router advertisement message sent to a multicast address. The 712 delay will avoid similar congestion when multiple nodes are going to 713 configure addresses by receiving the same single multicast router 714 advertisement. 716 Note that when a node joins a multicast address, it typically sends a 717 Multicast Listener Discovery (MLD) report message [RFC2710][RFC3810] 718 for the multicast address. In the case of Duplicate Address 719 Detection, the MLD report message is required in order to inform 720 MLD-snooping switches, rather than routers, to forward multicast 721 packets. In the above description, the delay for joining the 722 multicast address thus means delaying transmission of the 723 corresponding MLD report message. Since the MLD specifications do 724 not request a random delay to avoid race conditions, just delaying 725 Neighbor Solicitation would cause congestion by the MLD report 726 messages. The congestion would then prevent the MLD-snooping 727 switches from working correctly, and, as a result, prevent Duplicate 728 Address Detection from working. The requirement to include the delay 729 for the MLD report in this case avoids this scenario. [RFC3590] also 730 talks about some interaction issues between Duplicate Address 731 Detection and MLD, and specifies which source address should be used 732 for the MLD report in this case. 734 In order to improve the robustness of the Duplicate Address Detection 735 algorithm, an interface MUST receive and process datagrams sent to 736 the all-nodes multicast address or solicited-node multicast address 737 of the tentative address during the delay period. This does not 738 necessarily conflict with the requirement that joining the multicast 739 group be delayed. In fact, in some cases it is possible for a node 740 to start listening to the group during the delay period before MLD 741 report transmission. It should be noted, however, that in some 742 link-layer environments, particularly with MLD-snooping switches, no 743 multicast reception will be available until the MLD report is sent. 745 5.4.3 Receiving Neighbor Solicitation Messages 747 On receipt of a valid Neighbor Solicitation message on an interface, 748 node behavior depends on whether the target address is tentative or 749 not. If the target address is not tentative (i.e., it is assigned to 750 the receiving interface), the solicitation is processed as described 751 in [I-D.ietf-ipv6-2461bis]. If the target address is tentative, and 752 the source address is a unicast address, the solicitation's sender is 753 performing address resolution on the target; the solicitation should 754 be silently ignored. Otherwise, processing takes place as described 755 below. In all cases, a node MUST NOT respond to a Neighbor 756 Solicitation for a tentative address. 758 If the source address of the Neighbor Solicitation is the unspecified 759 address, the solicitation is from a node performing Duplicate Address 760 Detection. If the solicitation is from another node, the tentative 761 address is a duplicate and should not be used (by either node). If 762 the solicitation is from the node itself (because the node loops back 763 multicast packets), the solicitation does not indicate the presence 764 of a duplicate address. 766 Implementor's Note: many interfaces provide a way for upper layers to 767 selectively enable and disable the looping back of multicast packets. 768 The details of how such a facility is implemented may prevent 769 Duplicate Address Detection from working correctly. See the Appendix 770 A for further discussion. 772 The following tests identify conditions under which a tentative 773 address is not unique: 775 - If a Neighbor Solicitation for a tentative address is received 776 prior to having sent one, the tentative address is a duplicate. 777 This condition occurs when two nodes run Duplicate Address 778 Detection simultaneously, but transmit initial solicitations at 779 different times (e.g., by selecting different random delay values 780 before joining the solicited-node multicast address and 781 transmitting an initial solicitation). 783 - If the actual number of Neighbor Solicitations received exceeds 784 the number expected based on the loopback semantics (e.g., the 785 interface does not loopback packet, yet one or more solicitations 786 was received), the tentative address is a duplicate. This 787 condition occurs when two nodes run Duplicate Address Detection 788 simultaneously and transmit solicitations at roughly the same 789 time. 791 5.4.4 Receiving Neighbor Advertisement Messages 793 On receipt of a valid Neighbor Advertisement message on an interface, 794 node behavior depends on whether the target address is tentative or 795 matches a unicast or anycast address assigned to the interface. If 796 the target address is assigned to the receiving interface, the 797 solicitation is processed as described in [I-D.ietf-ipv6-2461bis]. 798 If the target address is tentative, the tentative address is not 799 unique. 801 5.4.5 When Duplicate Address Detection Fails 803 A tentative address that is determined to be a duplicate as described 804 above MUST NOT be assigned to an interface and the node SHOULD log a 805 system management error. 807 If the address is a link-local address formed from an interface 808 identifier based on the hardware address which is supposed to be 809 uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP 810 operation on the interface SHOULD be disabled. By disabling IP 811 operation, the node will then 813 - not send any IP packets from the interface 814 - silently drop any IP packets received on the interface 815 - not forward any IP packets to the interface (when acting as a 816 router or processing a packet with a Routing header) 818 In this case, the IP address duplication probably means duplicate 819 hardware addresses are in use, and trying to recover from it by 820 configuring another IP address will not result in a usable network. 821 In fact, it probably makes things worse by creating problems that are 822 harder to diagnose than just disabling network operation on the 823 interface; the user will see a partially working network where some 824 things work, and other things will not. 826 On the other hand, if the duplicate link-local address is not formed 827 from an interface identifier based on the hardware address which is 828 supposed to be uniquely assigned, IP operation on the interface MAY 829 be continued. 831 Note: as specified in Section 2, "IP" means "IPv6" in the above 832 description. While the background rationale about hardware address 833 is independent of particular network protocols, its effect on other 834 protocols is beyond the scope of this document. 836 5.5 Creation of Global Addresses 838 Global addresses are formed by appending an interface identifier to a 839 prefix of appropriate length. Prefixes are obtained from Prefix 840 Information options contained in Router Advertisements. Creation of 841 global addresses and configuration of other parameters as described 842 in this section SHOULD be locally configurable. However, the 843 processing described below MUST be enabled by default. 845 5.5.1 Soliciting Router Advertisements 847 Router Advertisements are sent periodically to the all-nodes 848 multicast address. To obtain an advertisement quickly, a host sends 849 out Router Solicitations as described in [I-D.ietf-ipv6-2461bis]. 851 5.5.2 Absence of Router Advertisements 853 Even if a link has no routers, stateful autoconfiguration to obtain 854 addresses and other configuration information may still be available, 855 and hosts may want to use the mechanism. From the perspective of 856 autoconfiguration, a link has no routers if no Router Advertisements 857 are received after having sent a small number of Router Solicitations 858 as described in [I-D.ietf-ipv6-2461bis]. 860 Note that it is possible that there is no router on the link in this 861 sense but there is a node that has the ability to forward packets. 862 In this case, the forwarding node's address must be manually 863 configured in hosts to be able to send packets off-link, since the 864 only mechanism to configure the default router's address 865 automatically is the one using Router Advertisements. 867 5.5.3 Router Advertisement Processing 869 For each Prefix-Information option in the Router Advertisement: 871 a) If the Autonomous flag is not set, silently ignore the Prefix 872 Information option. 874 b) If the prefix is the link-local prefix, silently ignore the 875 Prefix Information option. 877 c) If the preferred lifetime is greater than the valid lifetime, 878 silently ignore the Prefix Information option. A node MAY wish to 879 log a system management error in this case. 881 d) If the prefix advertised is not equal to the prefix of an address 882 configured by stateless autoconfiguration already in the list of 883 addresses associated with the interface (where "equal" means the 884 two prefix lengths are the same and the first prefix-length bits 885 of the prefixes are identical), and the Valid Lifetime is not 0, 886 form an address (and add it to the list) by combining the 887 advertised prefix with the link's interface identifier as follows: 889 | 128 - N bits | N bits | 890 +---------------------------------------+------------------------+ 891 | link prefix | interface identifier | 892 +----------------------------------------------------------------+ 894 If the sum of the prefix length and interface identifier length 895 does not equal 128 bits, the Prefix Information option MUST be 896 ignored. An implementation MAY wish to log a system management 897 error in this case. The length of the interface identifier is 898 defined in a separate link-type specific document, which should 899 also be consistent with the address architecture [RFC3513] (see 900 Section 2). 902 It is the responsibility of the system administrator to insure 903 that the lengths of prefixes contained in Router Advertisements 904 are consistent with the length of interface identifiers for that 905 link type. It should be noted, however, that this does not mean 906 the advertised prefix length is meaningless. In fact, the 907 advertised length has non trivial meaning for on-link 908 determination in [I-D.ietf-ipv6-2461bis] where the sum of the 909 prefix length and the interface identifier length may not be equal 910 to 128. Thus, it should be safe to validate the advertised prefix 911 length here, in order to detect and avoid a configuration error 912 specifying an invalid prefix length in the context of address 913 autoconfiguration. 915 Note that a future revision of the address architecture [RFC3513] 916 and a future link-type specific document, which will still be 917 consistent with each other, could potentially allow for an 918 interface identifier of length other than the value defined in the 919 current documents. Thus, an implementation should not assume a 920 particular constant. Rather, it should expect any lengths of 921 interface identifiers. 923 If an address is formed successfully, the host adds it to the list 924 of addresses assigned to the interface, initializing its preferred 925 and valid lifetime values from the Prefix Information option. 927 e) If the advertised prefix is equal to the prefix of an address 928 configured by stateless autoconfiguration in the list, the 929 preferred lifetime of the address is reset to the Preferred 930 Lifetime in the received advertisement. The specific action to 931 perform for the valid lifetime of the address depends on the Valid 932 Lifetime in the received advertisement and the remaining time to 933 the valid lifetime expiration of the previously autoconfigured 934 address. We call the remaining time "RemainingLifetime" in the 935 following discussion: 937 1. If the received Valid Lifetime is greater than 2 hours or 938 greater than RemainingLifetime, set the valid lifetime of the 939 corresponding address to the advertised Valid Lifetime. 941 2. If RemainingLifetime is less than or equal to 2 hours, ignore 942 the Prefix Information option with regards to the valid 943 lifetime, unless the Router Advertisement from which this 944 option was obtained has been authenticated (e.g., via IP 945 security [RFC2402]). If the Router Advertisement was 946 authenticated, the valid lifetime of the corresponding address 947 should be set to the Valid Lifetime in the received option. 949 3. Otherwise, reset the valid lifetime of the corresponding 950 address to two hours. 952 The above rules address a specific denial of service attack in 953 which a bogus advertisement could contain prefixes with very small 954 Valid Lifetimes. Without the above rules, a single 955 unauthenticated advertisement containing bogus Prefix Information 956 options with short Valid Lifetimes could cause all of a node's 957 addresses to expire prematurely. The above rules ensure that 958 legitimate advertisements (which are sent periodically) will 959 "cancel" the short Valid Lifetimes before they actually take 960 effect. 962 Note that the preferred lifetime of the corresponding address is 963 always reset to the Preferred Lifetime in the received Prefix 964 Information option, regardless of whether the valid lifetime is 965 also reset or ignored. The difference comes from the fact that 966 the possible attack for the preferred lifetime is relatively 967 minor. Additionally, it is even undesirable to ignore the 968 preferred lifetime when a valid administrator wants to deprecate a 969 particular address by sending a short preferred lifetime (and the 970 valid lifetime is ignored by accident). 972 5.5.4 Address Lifetime Expiry 974 A preferred address becomes deprecated when its preferred lifetime 975 expires. A deprecated address SHOULD continue to be used as a source 976 address in existing communications, but SHOULD NOT be used to 977 initiate new communications if an alternate (non-deprecated) address 978 of sufficient scope can easily be used instead. 980 Note that the feasibility of initiating new communication using a 981 non-deprecated address may be an application-specific decision, as 982 only the application may have knowledge about whether the (now) 983 deprecated address was (or still is) in use by the application. For 984 example, if an application explicitly specifies the protocol stack to 985 use a deprecated address as a source address, the protocol stack must 986 accept that; the application might request it because that IP address 987 is used for in higher-level communication and there might be a 988 requirement that the multiple connections in such a grouping use the 989 same pair of IP addresses. 991 IP and higher layers (e.g., TCP, UDP) MUST continue to accept and 992 process datagrams destined to a deprecated address as normal since a 993 deprecated address is still a valid address for the interface. In 994 the case of TCP, this means TCP SYN segments sent to a deprecated 995 address are responded to using the deprecated address as a source 996 address in the corresponding SYN-ACK (if the connection would 997 otherwise be allowed). 999 An implementation MAY prevent any new communication from using a 1000 deprecated address, but system management MUST have the ability to 1001 disable such a facility, and the facility MUST be disabled by 1002 default. 1004 Other subtle cases should also be noted about source address 1005 selection. For example, the above description does not clarify which 1006 address should be used between a deprecated, smaller-scope address 1007 and a non-deprecated, enough scope address. The details of the 1008 address selection including this case are described in [RFC3484] and 1009 beyond the scope of this document. 1011 An address (and its association with an interface) becomes invalid 1012 when its valid lifetime expires. An invalid address MUST NOT be used 1013 as a source address in outgoing communications and MUST NOT be 1014 recognized as a destination on a receiving interface. 1016 5.6 Configuration Consistency 1018 It is possible for hosts to obtain address information using both 1019 stateless and stateful protocols since both may be enabled at the 1020 same time. It is also possible that the values of other 1021 configuration parameters such as MTU size and hop limit will be 1022 learned from both Router Advertisements and the stateful 1023 autoconfiguration protocol. If the same configuration information is 1024 provided by multiple sources, the value of this information should be 1025 consistent. However, it is not considered a fatal error if 1026 information received from multiple sources is inconsistent. Hosts 1027 accept the union of all information received via the stateless and 1028 stateful protocols. If inconsistent information is learned from 1029 different sources, the most recently obtained values always have 1030 precedence over information learned earlier. 1032 5.7 Retaining Configured Addresses for Stability 1034 An implementation that has stable storage may want to retain 1035 addresses in the storage when the addresses were acquired using 1036 stateless address autoconfiguration. Assuming the lifetimes used are 1037 reasonable, this technique implies that a temporary outage (less than 1038 the valid lifetime) of a router will never result in the node losing 1039 its global address even if the node were to reboot. When this 1040 technique is used, it should also be noted that the expiration times 1041 of the preferred and valid lifetimes must be retained, in order to 1042 prevent the use of an address after it has become deprecated or 1043 invalid. 1045 Further details on this kind of extension are beyond the scope of 1046 this document. 1048 6. SECURITY CONSIDERATIONS 1050 Stateless address autoconfiguration allows a host to connect to a 1051 network, configure an address and start communicating with other 1052 nodes without ever registering or authenticating itself with the 1053 local site. Although this allows unauthorized users to connect to 1054 and use a network, the threat is inherently present in the Internet 1055 architecture. Any node with a physical attachment to a network can 1056 generate an address (using a variety of ad hoc techniques) that 1057 provides connectivity. 1059 The use of stateless address autoconfiguration and Duplicate Address 1060 Detection opens up the possibility of several denial of service 1061 attacks. For example, any node can respond to Neighbor Solicitations 1062 for a tentative address, causing the other node to reject the address 1063 as a duplicate. A separate document [RFC3756] discusses details 1064 about these attacks. These attacks can be addressed by requiring 1065 that Neighbor Discovery packets be authenticated with IP security 1066 [RFC2402]. However, it should be noted that [RFC3756] points out the 1067 use of IP security is not always feasible depending on network 1068 environments. 1070 7. IANA CONSIDERATIONS 1072 This document has no actions for IANA. 1074 8. Acknowledgements 1076 The authors would like to thank the members of both the IPNG (which 1077 is now IPV6) and ADDRCONF working groups for their input. In 1078 particular, thanks to Jim Bound, Steve Deering, Richard Draves, and 1079 Erik Nordmark. Thanks also goes to John Gilmore for alerting the WG 1080 of the "0 Lifetime Prefix Advertisement" denial of service attack 1081 vulnerability; this document incorporates changes that address this 1082 vulnerability. 1084 A number of people have contributed to identifying issues on a 1085 previous version of this document and to proposing resolutions to the 1086 issues, on which this version is based. In addition to those listed 1087 above, the contributors include Jari Arkko, Brian E Carpenter, 1088 Gregory Daley, Elwyn Davies, Ralph Droms, Jun-ichiro itojun Hagino, 1089 Christian Huitema, Suresh Krishnan, Soohong Daniel Park, Markku 1090 Savela, and Pekka Savola. 1092 9. References 1093 9.1 Normative References 1095 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 1096 2402, November 1998. 1098 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1099 Networks", RFC 2464, December 1998. 1101 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1102 Requirement Levels", BCP 14, RFC 2119, March 1997. 1104 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1105 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1107 [I-D.ietf-ipv6-2461bis] 1108 Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 1109 "Neighbor Discovery for IP version 6 (IPv6)", 1110 draft-ietf-ipv6-2461bis-00 (work in progress), July 2004. 1112 Note: this reference is expected to be published in 1113 parallel with the referring document, both of which will 1114 be recycled as a draft standard. Upon publication the 1115 reference will be updated and this note will be removed. 1117 9.2 Informative References 1119 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 1120 M. Carney, "Dynamic Host Configuration Protocol for IPv6 1121 (DHCPv6)", RFC 3315, July 2003. 1123 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1124 (DHCP) Service for IPv6", RFC 3736, April 2004. 1126 [RFC3484] Draves, R., "Default Address Selection for Internet 1127 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1129 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 1130 Stateless Address Autoconfiguration in IPv6", RFC 3041, 1131 January 2001. 1133 [I-D.ietf-send-cga] 1134 Aura, T., "Cryptographically Generated Addresses (CGA)", 1135 draft-ietf-send-cga-06 (work in progress), April 2004. 1137 [RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast 1138 Listener Discovery (MLD) for IPv6", RFC 2710, October 1139 1999. 1141 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1142 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1144 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 1145 Listener Discovery (MLD) Protocol", RFC 3590, September 1146 2003. 1148 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 1149 Discovery (ND) Trust Models and Threats", RFC 3756, May 1150 2004. 1152 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1153 RFC 1112, August 1989. 1155 [IEEE802.11] 1156 IEEE, "Wireless LAN Medium Access Control (MAC) and 1157 Physical Layer (PHY) Specifications", ANSI/IEEE STd 1158 802.11, August 1999. 1160 Authors' Addresses 1162 Susan Thomson 1163 Cisco Systems 1165 EMail: sethomso@cisco.com 1167 Thomas Narten 1168 IBM Corporation 1169 P.O. Box 12195 1170 Research Triangle Park, NC 27709-2195 1171 USA 1173 Phone: +1 919-254-7798 1174 EMail: narten@us.ibm.com 1176 Tatuya Jinmei 1177 Corporate Research & Development Center, Toshiba Corporation 1178 1 Komukai Toshiba-cho, Saiwai-ku 1179 Kawasaki-shi, Kanagawa 212-8582 1180 Japan 1182 Phone: +81 44-549-2230 1183 EMail: jinmei@isl.rdc.toshiba.co.jp 1185 Appendix A. LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION 1187 Determining whether a received multicast solicitation was looped back 1188 to the sender or actually came from another node is implementation- 1189 dependent. A problematic case occurs when two interfaces attached to 1190 the same link happen to have the same identifier and link-layer 1191 address, and they both send out packets with identical contents at 1192 roughly the same time (e.g., Neighbor Solicitations for a tentative 1193 address as part of Duplicate Address Detection messages). Although a 1194 receiver will receive both packets, it cannot determine which packet 1195 was looped back and which packet came from the other node by simply 1196 comparing packet contents (i.e., the contents are identical). In 1197 this particular case, it is not necessary to know precisely which 1198 packet was looped back and which was sent by another node; if one 1199 receives more solicitations than were sent, the tentative address is 1200 a duplicate. However, the situation may not always be this 1201 straightforward. 1203 The IPv4 multicast specification [RFC1112] recommends that the 1204 service interface provide a way for an upper-layer protocol to 1205 inhibit local delivery of packets sent to a multicast group that the 1206 sending host is a member of. Some applications know that there will 1207 be no other group members on the same host, and suppressing loopback 1208 prevents them from having to receive (and discard) the packets they 1209 themselves send out. A straightforward way to implement this 1210 facility is to disable loopback at the hardware level (if supported 1211 by the hardware), with packets looped back (if requested) by 1212 software. On interfaces in which the hardware itself suppresses 1213 loopbacks, a node running Duplicate Address Detection simply counts 1214 the number of Neighbor Solicitations received for a tentative address 1215 and compares them with the number expected. If there is a mismatch, 1216 the tentative address is a duplicate. 1218 In those cases where the hardware cannot suppress loopbacks, however, 1219 one possible software heuristic to filter out unwanted loopbacks is 1220 to discard any received packet whose link-layer source address is the 1221 same as the receiving interface's. There is even a link-layer 1222 specification that requires to discard any such packets [IEEE802.11]. 1223 Unfortunately, use of that criteria also results in the discarding of 1224 all packets sent by another node using the same link-layer address. 1225 Duplicate Address Detection will fail on interfaces that filter 1226 received packets in this manner: 1228 o If a node performing Duplicate Address Detection discards received 1229 packets having the same source link-layer address as the receiving 1230 interface, it will also discard packets from other nodes also 1231 using the same link-layer address, including Neighbor 1232 Advertisement and Neighbor Solicitation messages required to make 1233 Duplicate Address Detection work correctly. This particular 1234 problem can be avoided by temporarily disabling the software 1235 suppression of loopbacks while a node performs Duplicate Address 1236 Detection, if it is possible to disable the suppression. 1238 o If a node that is already using a particular IP address discards 1239 received packets having the same link-layer source address as the 1240 interface, it will also discard Duplicate Address 1241 Detection-related Neighbor Solicitation messages sent by another 1242 node also using the same link-layer address. Consequently, 1243 Duplicate Address Detection will fail, and the other node will 1244 configure a non-unique address. Since it is generally impossible 1245 to know when another node is performing Duplicate Address 1246 Detection, this scenario can be avoided only if software 1247 suppression of loopback is permanently disabled. 1249 Thus, to perform Duplicate Address Detection correctly in the case 1250 where two interfaces are using the same link-layer address, an 1251 implementation must have a good understanding of the interface's 1252 multicast loopback semantics, and the interface cannot discard 1253 received packets simply because the source link-layer address is the 1254 same as the interface's. It should also be noted that a link-layer 1255 specification can conflict with the condition necessary to make 1256 Duplicate Address Detection work. 1258 Appendix B. CHANGES SINCE RFC 1971 1260 o Changed document to use term "interface identifier" rather than 1261 "interface token" for consistency with other IPv6 documents. 1262 o Clarified definition of deprecated address to make clear it is OK 1263 to continue sending to or from deprecated addresses. 1264 o Added rules to Section 5.5.3 Router Advertisement processing to 1265 address potential denial-of-service attack when prefixes are 1266 advertised with very short Lifetimes. 1267 o Clarified wording in Section 5.5.4 to make clear that all upper 1268 layer protocols must process (i.e., send and receive) packets sent 1269 to deprecated addresses. 1271 Appendix C. CHANGES SINCE RFC 2462 1273 Major changes that can affect existing implementations: 1275 o Specified that a node performing Duplicate Address Detection delay 1276 joining the solicited-node multicast group, not just delay sending 1277 Neighbor Solicitations, explaining the detailed reason. 1278 o Added a requirement for a random delay before sending Neighbor 1279 Solicitations for Duplicate Address Detection if the address being 1280 checked is configured by a multicasted Router Advertisements. 1282 o Clarified that on failure of Duplicate Address Detection, IP 1283 network operation should be disabled and that the rule should 1284 apply when the hardware address is supposed to be unique. 1286 Major clarifications: 1288 o Clarified how the length of interface identifiers should be 1289 determined, described the relationship with the prefix length 1290 advertised in Router Advertisements, and avoided using a 1291 particular length hard-coded in this document. 1292 o Clarified that the "stateful" protocols for address configuration 1293 and other information configuration are RFC 3315 and RFC 3736, 1294 respectively. 1295 o Clarified the semantics of the M and O flags based on the latest 1296 standard and operational status. In particular, clarified that 1297 these flags show the availability of the stateful protocol instead 1298 of a trigger to invoke the stateful protocol. ManagedFlag and 1299 OtherConfigFlag, which were implementation-internal variables, 1300 were removed accordingly. 1301 o Recommended to perform Duplicate Address Detection for all unicast 1302 addresses more strongly, considering a variety of different 1303 interface identifiers, while keeping care of existing 1304 implementations. 1305 o Clarified wording in Section 5.5.4 to make clear that a deprecated 1306 address specified by an application should be used for any 1307 communication. 1308 o Revised the Security Considerations section with a reference to 1309 RFC 3756 and a note that the use of IP security is not always 1310 feasible. 1311 o Added a note when an implementation uses stable storage for 1312 autoconfigured addresses. 1314 Other miscellaneous clarifications: 1316 o Removed references to site-local and revised wording around the 1317 keyword. 1318 o Removed redundant code in denial of service protection in Section 1319 5.5.3. 1320 o Clarified that a unicasted Neighbor Solicitation or Advertisement 1321 should be discarded while performing Duplicate Address Detection. 1323 Appendix D. CHANGE HISTORY 1325 [NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION UPON PUBLICATION.] 1327 Changes in draft-ietf-ipv6-rfc2462bis-00.txt since RFC 2462 are: 1329 o Fixed a typo in Section 2. 1330 o Updated references and categorized them into normative and 1331 informative ones. 1332 o Removed redundant code in denial of service protection in Section 1333 5.5.3. 1334 o Clarified that a unicasted NS or NA should be discarded while 1335 performing Duplicate Address Detection. 1336 o Replaced the word "StoredLifetime" with "RemainingLifetime" with a 1337 precise definition to avoid confusion. 1338 o Removed references to site-local and revised wording around the 1339 keyword. 1340 o Added a note about source address selection with regards to 1341 deprecated vs insufficient-scope addresses, etc. Added a 1342 reference to RFC 3484 for further details. 1343 o Clarified what "new communication" means in Section 5.5.4. 1344 o Added a new subsection (5.7) to mention the possibility to use 1345 stable storage to retain configured addresses for stability. 1346 o Revised the Security Considerations section with a reference to 1347 RFC 3756 and a note that the use of IP security is not always 1348 feasible. 1349 o Added a note with a reference in Appendix A about the case where a 1350 link-layer filtering conflicts with a condition to make Duplicate 1351 Address Detection work correctly. 1352 o Specified that a node performing Duplicate Address Detection delay 1353 joining the solicited-node multicast group, not just delay sending 1354 Neighbor Solicitations, explaining the detailed reason. 1355 o Clarified the reason why the interface should be disabled after an 1356 address duplicate is detected. Also clarified that the interface 1357 may continue to be used if the interface identifier is not based 1358 on the hardware address. 1359 o Clarified that the preferred lifetime for an existing configured 1360 address is always reset to the advertised value by Router 1361 Advertisement. 1362 o Updated the description of interface identifier considering the 1363 latest format. 1365 Changes since draft-ietf-ipv6-rfc2462bis-00.txt are: 1367 o Clarified how the length of interface identifiers should be 1368 determined, described the relationship with the prefix length 1369 advertised in Router Advertisements, and avoided using a 1370 particular length hard-coded in this document. 1371 o Added a note when an implementation uses stable storage for 1372 autoconfigured addresses. 1373 o Resolved conflict with the Multicast Listener Discovery 1374 specification about random delay for the first packet from the 1375 host. 1377 o Clarified the semantics of the M and O flags based on the latest 1378 standard and operational status. In particular, clarified that 1379 these flags show the availability of the stateful protocol instead 1380 of a trigger to invoke the stateful protocol. ManagedFlag and 1381 OtherConfigFlag, which were implementation-internal variables, 1382 were removed accordingly. 1383 o Recommended to perform Duplicate Address Detection for all unicast 1384 addresses more strongly, considering a variety of different 1385 interface identifiers, while keeping care of existing 1386 implementations. 1387 o Added a requirement for a random delay before sending Neighbor 1388 Solicitations for Duplicate Address Detection if the address being 1389 checked is configured by a multicasted Router Advertisements. 1390 o Clarified that the prefix comparison in Section 5.5.3 is based on 1391 exact match. Also clarified the comparison described in this 1392 document concentrates on addresses configured by the stateless 1393 mechanism. 1394 o Revisited the author list. 1395 o Added IANA Considerations Section. 1397 Changes since draft-ietf-ipv6-rfc2462bis-02.txt are: 1399 o Updated the I-D / IPR boilerplate to the latest ones. Applied 1400 other editorial changes to conform to I-D nits. 1401 o Clarified that it is IP network operation that should be disabled 1402 on failure of Duplicate Address Detection, and that the rule 1403 should apply when the hardware address is supposed to be unique. 1404 o Changed the reference on the algorithm of computing solicited-node 1405 multicast addresses to [RFC3513]. 1406 o Made the intent clearer in the clarification that unicasted NS or 1407 NA should be discarded during Duplicate Address Detection. 1409 Changes since draft-ietf-ipv6-rfc2462bis-03.txt are: 1411 o Added an informative reference to [RFC3590]. 1412 o Summarized major changes since RFC 2462 to prepare for 1413 publication. 1415 Changes since draft-ietf-ipv6-rfc2462bis-05.txt are: 1417 o Clarified the role of RFC 3736 in the abstract. 1418 o Clarified that the default configuration method is the one 1419 described in this document. 1420 o Changed the reference for the Neighbor Discovery protocol to 1421 [I-D.ietf-ipv6-2461bis]. 1422 o Reorganized the conditions at the beginning of Section 5.4 with an 1423 additional note to avoid confusion. 1425 o Clarified the role of the link-local prefix in Section 5.3. 1426 o Added a reference to RFC 3810 as well as to RFC 2710. 1427 o Clarified the MLD issues a bit more. 1428 o Replaced "multicast interface" with "multicast-capable interface". 1429 o Clarified that the autoconfiguration protocol would basically be 1430 used on all types of links in line with the Neighbor Discovery 1431 protocol. 1433 Intellectual Property Statement 1435 The IETF takes no position regarding the validity or scope of any 1436 Intellectual Property Rights or other rights that might be claimed to 1437 pertain to the implementation or use of the technology described in 1438 this document or the extent to which any license under such rights 1439 might or might not be available; nor does it represent that it has 1440 made any independent effort to identify any such rights. Information 1441 on the procedures with respect to rights in RFC documents can be 1442 found in BCP 78 and BCP 79. 1444 Copies of IPR disclosures made to the IETF Secretariat and any 1445 assurances of licenses to be made available, or the result of an 1446 attempt made to obtain a general license or permission for the use of 1447 such proprietary rights by implementers or users of this 1448 specification can be obtained from the IETF on-line IPR repository at 1449 http://www.ietf.org/ipr. 1451 The IETF invites any interested party to bring to its attention any 1452 copyrights, patents or patent applications, or other proprietary 1453 rights that may cover technology that may be required to implement 1454 this standard. Please address the information to the IETF at 1455 ietf-ipr@ietf.org. 1457 Disclaimer of Validity 1459 This document and the information contained herein are provided on an 1460 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1461 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1462 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1463 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1464 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1465 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1467 Copyright Statement 1469 Copyright (C) The Internet Society (2004). This document is subject 1470 to the rights, licenses and restrictions contained in BCP 78, and 1471 except as set forth therein, the authors retain all their rights. 1473 Acknowledgment 1475 Funding for the RFC Editor function is currently provided by the 1476 Internet Society.