idnits 2.17.1 draft-ietf-ipv6-rfc2462bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (February 9, 2004) is 7372 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 (ref. '1') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 3513 (ref. '4') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2461 (ref. '5') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '7') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '8') (Obsoleted by RFC 6724) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 4 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: August 9, 2004 T. Narten 5 IBM 6 T. Jinmei 7 Toshiba 8 H. Soliman 9 Flarion Technologies 10 February 9, 2004 12 IPv6 Stateless Address Autoconfiguration 13 draft-ietf-ipv6-rfc2462bis-00.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as 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 http:// 30 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 August 9, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This document specifies the steps a host takes in deciding how to 44 autoconfigure its interfaces in IP version 6. The autoconfiguration 45 process includes creating a link-local address and verifying its 46 uniqueness on a link, determining what information should be 47 autoconfigured (addresses, other information, or both), and in the 48 case of addresses, whether they should be obtained through the 49 stateless mechanism, the stateful mechanism, or both. This document 50 defines the process for generating a link-local address, the process 51 for generating global addresses via stateless address 52 autoconfiguration, and the Duplicate Address Detection procedure. The 53 details of autoconfiguration using the stateful protocol are 54 specified elsewhere. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. TERMINOLOGY . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3. DESIGN GOALS . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. PROTOCOL OVERVIEW . . . . . . . . . . . . . . . . . . . . . 8 63 4.1 Site Renumbering . . . . . . . . . . . . . . . . . . . . . . 10 64 5. PROTOCOL SPECIFICATION . . . . . . . . . . . . . . . . . . . 11 65 5.1 Node Configuration Variables . . . . . . . . . . . . . . . . 11 66 5.2 Autoconfiguration-Related Variables . . . . . . . . . . . . 12 67 5.3 Creation of Link-Local Addresses . . . . . . . . . . . . . . 12 68 5.4 Duplicate Address Detection . . . . . . . . . . . . . . . . 13 69 5.4.1 Message Validation . . . . . . . . . . . . . . . . . . . . . 14 70 5.4.2 Sending Neighbor Solicitation Messages . . . . . . . . . . . 15 71 5.4.3 Receiving Neighbor Solicitation Messages . . . . . . . . . . 15 72 5.4.4 Receiving Neighbor Advertisement Messages . . . . . . . . . 16 73 5.4.5 When Duplicate Address Detection Fails . . . . . . . . . . . 17 74 5.5 Creation of Global Addresses . . . . . . . . . . . . . . . . 17 75 5.5.1 Soliciting Router Advertisements . . . . . . . . . . . . . . 17 76 5.5.2 Absence of Router Advertisements . . . . . . . . . . . . . . 17 77 5.5.3 Router Advertisement Processing . . . . . . . . . . . . . . 18 78 5.5.4 Address Lifetime Expiry . . . . . . . . . . . . . . . . . . 20 79 5.6 Configuration Consistency . . . . . . . . . . . . . . . . . 21 80 5.7 Retaining Configured Addresses for Stability . . . . . . . . 21 81 6. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . 21 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 83 Normative References . . . . . . . . . . . . . . . . . . . . 22 84 Informative References . . . . . . . . . . . . . . . . . . . 22 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 86 A. LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION . . . . . 24 87 B. CHANGES SINCE RFC 1971 . . . . . . . . . . . . . . . . . . . 25 88 C. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . . . . . 26 89 D. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . . 27 90 Intellectual Property and Copyright Statements . . . . . . . 28 92 1. Introduction 94 This document specifies the steps a host takes in deciding how to 95 autoconfigure its interfaces in IP version 6. The autoconfiguration 96 process includes creating a link-local address and verifying its 97 uniqueness on a link, determining what information should be 98 autoconfigured (addresses, other information, or both), and in the 99 case of addresses, whether they should be obtained through the 100 stateless mechanism, the stateful mechanism, or both. This document 101 defines the process for generating a link-local address, the process 102 for generating global addresses via stateless address 103 autoconfiguration, and the Duplicate Address Detection procedure. The 104 details of autoconfiguration using the stateful protocol are 105 specified elsewhere. 107 IPv6 defines both a stateful and stateless address autoconfiguration 108 mechanism. Stateless autoconfiguration requires no manual 109 configuration of hosts, minimal (if any) configuration of routers, 110 and no additional servers. The stateless mechanism allows a host to 111 generate its own addresses using a combination of locally available 112 information and information advertised by routers. Routers advertise 113 prefixes that identify the subnet(s) associated with a link, while 114 hosts generate an "interface identifier" that uniquely identifies an 115 interface on a subnet. An address is formed by combining the two. In 116 the absence of routers, a host can only generate link-local 117 addresses. However, link-local addresses are sufficient for allowing 118 communication among nodes attached to the same link. 120 In the stateful autoconfiguration model, hosts obtain interface 121 addresses and/or configuration information and parameters from a 122 server. Servers maintain a database that keeps track of which 123 addresses have been assigned to which hosts. The stateful 124 autoconfiguration protocol allows hosts to obtain addresses, other 125 configuration information or both from a server. Stateless and 126 stateful autoconfiguration complement each other. For example, a host 127 can use stateless autoconfiguration to configure its own addresses, 128 but use stateful autoconfiguration to obtain other information. 129 Stateful autoconfiguration for IPv6 is the subject of DHCPv6 [7]. 131 The stateless approach is used when a site is not particularly 132 concerned with the exact addresses hosts use, so long as they are 133 unique and properly routable. The stateful approach is used when a 134 site requires tighter control over exact address assignments. Both 135 stateful and stateless address autoconfiguration may be used 136 simultaneously. The site administrator specifies which type of 137 autoconfiguration to use through the setting of appropriate fields in 138 Router Advertisement messages [5]. 140 IPv6 addresses are leased to an interface for a fixed (possibly 141 infinite) length of time. Each address has an associated lifetime 142 that indicates how long the address is bound to an interface. When a 143 lifetime expires, the binding (and address) become invalid and the 144 address may be reassigned to another interface elsewhere in the 145 Internet. To handle the expiration of address bindings gracefully, an 146 address goes through two distinct phases while assigned to an 147 interface. Initially, an address is "preferred", meaning that its use 148 in arbitrary communication is unrestricted. Later, an address becomes 149 "deprecated" in anticipation that its current interface binding will 150 become invalid. While in a deprecated state, the use of an address is 151 discouraged, but not strictly forbidden. New communication (e.g., 152 the opening of a new TCP connection) should use a preferred address 153 when possible. A deprecated address should be used only by 154 applications that have been using it and would have difficulty 155 switching to another address without a service disruption. 157 To ensure that all configured addresses are likely to be unique on a 158 given link, nodes run a "duplicate address detection" algorithm on 159 addresses before assigning them to an interface. The Duplicate 160 Address Detection algorithm is performed on all addresses, 161 independent of whether they are obtained via stateless or stateful 162 autoconfiguration. This document defines the Duplicate Address 163 Detection algorithm. 165 The autoconfiguration process specified in this document applies only 166 to hosts and not routers. Since host autoconfiguration uses 167 information advertised by routers, routers will need to be configured 168 by some other means. However, it is expected that routers will 169 generate link-local addresses using the mechanism described in this 170 document. In addition, routers are expected to successfully pass the 171 Duplicate Address Detection procedure described in this document on 172 all addresses prior to assigning them to an interface. 174 Section 2 provides definitions for terminology used throughout this 175 document. Section 3 describes the design goals that lead to the 176 current autoconfiguration procedure. Section 4 provides an overview 177 of the protocol, while Section 5 describes the protocol in detail. 179 2. TERMINOLOGY 181 IP - Internet Protocol Version 6. The terms IPv4 and IPv6 are used 182 only in contexts where necessary to avoid ambiguity. 184 node - a device that implements IP. 186 router - a node that forwards IP packets not explicitly addressed to 187 itself. 189 host - any node that is not a router. 191 upper layer - a protocol layer immediately above IP. Examples are 192 transport protocols such as TCP and UDP, control protocols such as 193 ICMP, routing protocols such as OSPF, and internet or lower-layer 194 protocols being "tunneled" over (i.e., encapsulated in) IP such as 195 IPX, AppleTalk, or IP itself. 197 link - a communication facility or medium over which nodes can 198 communicate at the link layer, i.e., the layer immediately below 199 IP. Examples are Ethernets (simple or bridged); PPP links; X.25, 200 Frame Relay, or ATM networks; and internet (or higher) layer 201 "tunnels", such as tunnels over IPv4 or IPv6 itself. 203 interface - a node's attachment to a link. 205 packet - an IP header plus payload. 207 address - an IP-layer identifier for an interface or a set of 208 interfaces. 210 unicast address - an identifier for a single interface. A packet sent 211 to a unicast address is delivered to the interface identified by 212 that address. 214 multicast address - an identifier for a set of interfaces (typically 215 belonging to different nodes). A packet sent to a multicast 216 address is delivered to all interfaces identified by that address. 218 anycast address - an identifier for a set of interfaces (typically 219 belonging to different nodes). A packet sent to an anycast 220 address is delivered to one of the interfaces identified by that 221 address (the "nearest" one, according to the routing protocol's 222 measure of distance). See the IPv6 addressing architecture [4]. 224 solicited-node multicast address - a multicast address to which 225 Neighbor Solicitation messages are sent. The algorithm for 226 computing the address is given in RFC 2461 [5]. 228 link-layer address - a link-layer identifier for an interface. 229 Examples include IEEE 802 addresses for Ethernet links and E.164 230 addresses for ISDN links. 232 link-local address - an address having link-only scope that can be 233 used to reach neighboring nodes attached to the same link. All 234 interfaces have a link-local unicast address. 236 global address - an address with unlimited scope. 238 communication - any packet exchange among nodes that requires that 239 the address of each node used in the exchange remain the same for 240 the duration of the packet exchange. Examples are a TCP 241 connection or a UDP request-response. 243 tentative address - an address whose uniqueness on a link is being 244 verified, prior to its assignment to an interface. A tentative 245 address is not considered assigned to an interface in the usual 246 sense. An interface discards received packets addressed to a 247 tentative address, but accepts Neighbor Discovery packets related 248 to Duplicate Address Detection for the tentative address. 250 preferred address - an address assigned to an interface whose use by 251 upper layer protocols is unrestricted. Preferred addresses may be 252 used as the source (or destination) address of packets sent from 253 (or to) the interface. 255 deprecated address - An address assigned to an interface whose use is 256 discouraged, but not forbidden. A deprecated address should no 257 longer be used as a source address in new communications, but 258 packets sent from or to deprecated addresses are delivered as 259 expected. A deprecated address may continue to be used as a 260 source address in communications where switching to a preferred 261 address causes hardship to a specific upper-layer activity (e.g., 262 an existing TCP connection). 264 valid address - a preferred or deprecated address. A valid address 265 may appear as the source or destination address of a packet, and 266 the internet routing system is expected to deliver packets sent to 267 a valid address to their intended recipients. 269 invalid address - an address that is not assigned to any interface. A 270 valid address becomes invalid when its valid lifetime expires. 271 Invalid addresses should not appear as the destination or source 272 address of a packet. In the former case, the internet routing 273 system will be unable to deliver the packet, in the later case the 274 recipient of the packet will be unable to respond to it. 276 preferred lifetime - the length of time that a valid address is 277 preferred (i.e., the time until deprecation). When the preferred 278 lifetime expires, the address becomes deprecated. 280 valid lifetime - the length of time an address remains in the valid 281 state (i.e., the time until invalidation). The valid lifetime must 282 be greater then or equal to the preferred lifetime. When the 283 valid lifetime expires, the address becomes invalid. 285 interface identifier - a link-dependent identifier for an interface 286 that is (at least) unique per link [4]. Stateless address 287 autoconfiguration combines an interface identifier with a prefix 288 to form an address. From address autoconfiguration's perspective, 289 an interface identifier is a bit string of known length. The 290 exact length of an interface identifier and the way it is created 291 is defined in a separate link-type specific document that covers 292 issues related to the transmission of IP over a particular link 293 type (e.g., IPv6 over Ethernet [2]). In many cases, the identifier 294 will be derived from the interface's link-layer address. 296 2.1 Requirements 298 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 299 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 300 document, are to be interpreted as described in RFC 2119 [3]. 302 3. DESIGN GOALS 304 Stateless autoconfiguration is designed with the following goals in 305 mind: 307 o Manual configuration of individual machines before connecting them 308 to the network should not be required. Consequently, a mechanism 309 is needed that allows a host to obtain or create unique addresses 310 for each of its interfaces. Address autoconfiguration assumes that 311 each interface can provide a unique identifier for that interface 312 (i.e., an "interface identifier"). In the simplest case, an 313 interface identifier consists of the interface's link-layer 314 address. An interface identifier can be combined with a prefix to 315 form an address. 317 o Small sites consisting of a set of machines attached to a single 318 link should not require the presence of a stateful server or 319 router as a prerequisite for communicating. Plug-and-play 320 communication is achieved through the use of link-local addresses. 321 Link-local addresses have a well-known prefix that identifies the 322 (single) shared link to which a set of nodes attach. A host forms 323 a link-local address by appending its interface identifier to the 324 link-local prefix. 326 o A large site with multiple networks and routers should not require 327 the presence of a stateful address configuration server. In order 328 to generate global addresses, hosts must determine the prefixes 329 that identify the subnets to which they attach. Routers generate 330 periodic Router Advertisements that include options listing the 331 set of active prefixes on a link. 333 o Address configuration should facilitate the graceful renumbering 334 of a site's machines. For example, a site may wish to renumber all 335 of its nodes when it switches to a new network service provider. 336 Renumbering is achieved through the leasing of addresses to 337 interfaces and the assignment of multiple addresses to the same 338 interface. Lease lifetimes provide the mechanism through which a 339 site phases out old prefixes. The assignment of multiple 340 addresses to an interface provides for a transition period during 341 which both a new address and the one being phased out work 342 simultaneously. 344 o System administrators need the ability to specify whether 345 stateless autoconfiguration, stateful autoconfiguration, or both 346 should be used. Router Advertisements include flags specifying 347 which mechanisms a host should use. 349 4. PROTOCOL OVERVIEW 351 This section provides an overview of the typical steps that take 352 place when an interface autoconfigures itself. Autoconfiguration is 353 performed only on multicast-capable links and begins when a 354 multicast-capable interface is enabled, e.g., during system startup. 355 Nodes (both hosts and routers) begin the autoconfiguration process by 356 generating a link-local address for the interface. A link-local 357 address is formed by appending the interface's identifier to the 358 well-known link-local prefix. 360 Before the link-local address can be assigned to an interface and 361 used, however, a node must attempt to verify that this "tentative" 362 address is not already in use by another node on the link. 363 Specifically, it sends a Neighbor Solicitation message containing the 364 tentative address as the target. If another node is already using 365 that address, it will return a Neighbor Advertisement saying so. If 366 another node is also attempting to use the same address, it will send 367 a Neighbor Solicitation for the target as well. The exact number of 368 times the Neighbor Solicitation is (re)transmitted and the delay time 369 between consecutive solicitations is link-specific and may be set by 370 system management. 372 If a node determines that its tentative link-local address is not 373 unique, autoconfiguration stops and manual configuration of the 374 interface is required. To simplify recovery in this case, it should 375 be possible for an administrator to supply an alternate interface 376 identifier that overrides the default identifier in such a way that 377 the autoconfiguration mechanism can then be applied using the new 378 (presumably unique) interface identifier. Alternatively, link-local 379 and other addresses will need to be configured manually. 381 Once a node ascertains that its tentative link-local address is 382 unique, it assigns the address to the interface. At this point, the 383 node has IP-level connectivity with neighboring nodes. The remaining 384 autoconfiguration steps are performed only by hosts; the 385 (auto)configuration of routers is beyond the scope of this document. 387 The next phase of autoconfiguration involves obtaining a Router 388 Advertisement or determining that no routers are present. If routers 389 are present, they will send Router Advertisements that specify what 390 sort of autoconfiguration a host should do. If no routers are 391 present, stateful autoconfiguration should be invoked. 393 Routers send Router Advertisements periodically, but the delay 394 between successive advertisements will generally be longer than a 395 host performing autoconfiguration will want to wait [5]. To obtain an 396 advertisement quickly, a host sends one or more Router Solicitations 397 to the all-routers multicast group. Router Advertisements contain 398 two flags indicating what type of stateful autoconfiguration (if any) 399 should be performed. A "managed address configuration" flag indicates 400 whether hosts should use stateful autoconfiguration to obtain 401 addresses. An "other stateful configuration" flag indicates whether 402 hosts should use stateful autoconfiguration to obtain additional 403 information (excluding addresses). 405 Router Advertisements also contain zero or more Prefix Information 406 options that contain information used by stateless address 407 autoconfiguration to generate global addresses. It should be noted 408 that the stateless and stateful address autoconfiguration fields in 409 Router Advertisements are processed independently of one another, and 410 a host may use both stateful and stateless address autoconfiguration 411 simultaneously. One Prefix Information option field, the "autonomous 412 address-configuration flag", indicates whether or not the option even 413 applies to stateless autoconfiguration. If it does, additional 414 option fields contain a subnet prefix together with lifetime values 415 indicating how long addresses created from the prefix remain 416 preferred and valid. 418 Because routers generate Router Advertisements periodically, hosts 419 will continually receive new advertisements. Hosts process the 420 information contained in each advertisement as described above, 421 adding to and refreshing information received in previous 422 advertisements. 424 For safety, all addresses must be tested for uniqueness prior to 425 their assignment to an interface. In the case of addresses created 426 through stateless autoconfiguration, however, the uniqueness of an 427 address is determined primarily by the portion of the address formed 428 from an interface identifier. Thus, if a node has already verified 429 the uniqueness of a link-local address, additional addresses created 430 from the same interface identifier need not be tested individually. 431 In contrast, all addresses obtained manually or via stateful address 432 autoconfiguration should be tested for uniqueness individually. To 433 accommodate sites that believe the overhead of performing Duplicate 434 Address Detection outweighs its benefits, the use of Duplicate 435 Address Detection can be disabled through the administrative setting 436 of a per-interface configuration flag. 438 To speed the autoconfiguration process, a host may generate its 439 link-local address (and verify its uniqueness) in parallel with 440 waiting for a Router Advertisement. Because a router may delay 441 responding to a Router Solicitation for a few seconds, the total time 442 needed to complete autoconfiguration can be significantly longer if 443 the two steps are done serially. 445 4.1 Site Renumbering 447 Address leasing facilitates site renumbering by providing a mechanism 448 to time-out addresses assigned to interfaces in hosts. At present, 449 upper layer protocols such as TCP provide no support for changing 450 end-point addresses while a connection is open. If an end-point 451 address becomes invalid, existing connections break and all 452 communication to the invalid address fails. Even when applications 453 use UDP as a transport protocol, addresses must generally remain the 454 same during a packet exchange. 456 Dividing valid addresses into preferred and deprecated categories 457 provides a way of indicating to upper layers that a valid address may 458 become invalid shortly and that future communication using the 459 address will fail, should the address's valid lifetime expire before 460 communication ends. To avoid this scenario, higher layers should use 461 a preferred address (assuming one of sufficient scope exists) to 462 increase the likelihood that an address will remain valid for the 463 duration of the communication. It is up to system administrators to 464 set appropriate prefix lifetimes in order to minimize the impact of 465 failed communication when renumbering takes place. The deprecation 466 period should be long enough that most, if not all, communications 467 are using the new address at the time an address becomes invalid. 469 The IP layer is expected to provide a means for upper layers 470 (including applications) to select the most appropriate source 471 address given a particular destination and possibly other 472 constraints. An application may choose to select the source address 473 itself before starting a new communication or may leave the address 474 unspecified, in which case the upper networking layers will use the 475 mechanism provided by the IP layer to choose a suitable address on 476 the application's behalf. 478 Detailed address selection rules are beyond the scope of this 479 document. 481 5. PROTOCOL SPECIFICATION 483 Autoconfiguration is performed on a per-interface basis on 484 multicast-capable interfaces. For multihomed hosts, 485 autoconfiguration is performed independently on each interface. 486 Autoconfiguration applies primarily to hosts, with two exceptions. 487 Routers are expected to generate a link-local address using the 488 procedure outlined below. In addition, routers perform Duplicate 489 Address Detection on all addresses prior to assigning them to an 490 interface. 492 5.1 Node Configuration Variables 494 A node MUST allow the following autoconfiguration-related variable to 495 be configured by system management for each multicast interface: 497 DupAddrDetectTransmits 499 The number of consecutive Neighbor Solicitation messages sent 500 while performing Duplicate Address Detection on a tentative 501 address. A value of zero indicates that Duplicate Address 502 Detection is not performed on tentative addresses. A value of one 503 indicates a single transmission with no follow up retransmissions. 505 Default: 1, but may be overridden by a link-type specific value in 506 the document that covers issues related to the transmission of IP 507 over a particular link type (e.g., IPv6 over Ethernet [2]). 509 Autoconfiguration also assumes the presence of the variable 510 RetransTimer as defined in RFC 2461 [5]. For autoconfiguration 511 purposes, RetransTimer specifies the delay between consecutive 512 Neighbor Solicitation transmissions performed during Duplicate 513 Address Detection (if DupAddrDetectTransmits is greater than 1), 514 as well as the time a node waits after sending the last Neighbor 515 Solicitation before ending the Duplicate Address Detection 516 process. 518 5.2 Autoconfiguration-Related Variables 520 A host maintains a number of data structures and flags related to 521 autoconfiguration. In the following, we present conceptual variables 522 and show how they are used to perform autoconfiguration. The specific 523 variables are used for demonstration purposes only, and an 524 implementation is not required to have them, so long as its external 525 behavior is consistent with that described in this document. 527 Beyond the formation of a link-local address and using Duplicate 528 Address Detection, how routers (auto)configure their interfaces is 529 beyond the scope of this document. 531 Hosts maintain the following variables on a per-interface basis: 533 ManagedFlag 535 Copied from the M flag field (i.e., the "managed address 536 configuration" flag) of the most recently received Router 537 Advertisement message. The flag indicates whether or not addresses 538 are to be configured using the stateful autoconfiguration 539 mechanism. It starts out in a FALSE state. 541 OtherConfigFlag 543 Copied from the O flag field (i.e., the "other stateful 544 configuration" flag) of the most recently received Router 545 Advertisement message. The flag indicates whether or not 546 information other than addresses is to be obtained using the 547 stateful autoconfiguration mechanism. It starts out in a FALSE 548 state. 550 In addition, when the value of the ManagedFlag is TRUE, the value 551 of OtherConfigFlag is implicitly TRUE as well. It is not a valid 552 configuration for a host to use stateful address autoconfiguration 553 to request addresses only, without also accepting other 554 configuration information. 556 A host also maintains a list of addresses together with their 557 corresponding lifetimes. The address list contains both 558 autoconfigured addresses and those configured manually. 560 5.3 Creation of Link-Local Addresses 562 A node forms a link-local address whenever an interface becomes 563 enabled. An interface may become enabled after any of the following 564 events: 566 - The interface is initialized at system startup time. 568 - The interface is reinitialized after a temporary interface failure 569 or after being temporarily disabled by system management. 571 - The interface attaches to a link for the first time. 573 - The interface becomes enabled by system management after having 574 been administratively disabled. 576 A link-local address is formed by prepending the well-known link- 577 local prefix FE80::0 [4] (of appropriate length) to the interface 578 identifier. If the interface identifier has a length of N bits, the 579 interface identifier replaces the right-most N zero bits of the 580 link-local prefix. If the interface identifier is more than 118 bits 581 in length, autoconfiguration fails and manual configuration is 582 required. Note that interface identifiers will typically be 64-bits 583 long and based on EUI-64 identifiers as described in [4]. 585 5.4 Duplicate Address Detection 587 Duplicate Address Detection is performed on unicast addresses prior 588 to assigning them to an interface whose DupAddrDetectTransmits 589 variable is greater than zero. Duplicate Address Detection MUST take 590 place on all unicast addresses, regardless of whether they are 591 obtained through stateful, stateless or manual configuration, with 592 the exception of the following cases: 594 - Duplicate Address Detection MUST NOT be performed on anycast 595 addresses. 597 - Each individual unicast address SHOULD be tested for uniqueness. 598 However, when stateless address autoconfiguration is used, address 599 uniqueness is determined solely by the interface identifier, 600 assuming that subnet prefixes are assigned correctly (i.e., if all 601 of an interface's addresses are generated from the same 602 identifier, either all addresses or none of them will be 603 duplicates). Thus, for a set of addresses formed from the same 604 interface identifier, it is sufficient to check that the link- 605 local address generated from the identifier is unique on the link. 606 In such cases, the link-local address MUST be tested for 607 uniqueness, and if no duplicate address is detected, an 608 implementation MAY choose to skip Duplicate Address Detection for 609 additional addresses derived from the same interface identifier. 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 to 632 the tentative address containing the tentative address in the Target 633 Address field. Such a case should not happen in normal operation, 634 though, since these messages are multicasted in the Duplicate Address 635 Detection Procedure. 637 It should also be noted that Duplicate Address Detection must be 638 performed prior to assigning an address to an interface in order to 639 prevent multiple nodes from using the same address simultaneously. If 640 a node begins using an address in parallel with Duplicate Address 641 Detection, and another node is already using the address, the node 642 performing Duplicate Address Detection will erroneously process 643 traffic intended for the other node, resulting in such possible 644 negative consequences as the resetting of open TCP connections. 646 The following subsections describe specific tests a node performs to 647 verify an address's uniqueness. An address is considered unique if 648 none of the tests indicate the presence of a duplicate address within 649 RetransTimer milliseconds after having sent DupAddrDetectTransmits 650 Neighbor Solicitations. Once an address is determined to be unique, 651 it may be assigned to an interface. 653 5.4.1 Message Validation 655 A node MUST silently discard any Neighbor Solicitation or 656 Advertisement message that does not pass the validity checks 657 specified in RFC 2461 [5]. A Neighbor Solicitation or Advertisement 658 message that passes these validity checks is called a valid 659 solicitation or valid advertisement, respectively. 661 5.4.2 Sending Neighbor Solicitation Messages 663 Before sending a Neighbor Solicitation, an interface MUST join the 664 all-nodes multicast address and the solicited-node multicast address 665 of the tentative address. The former ensures that the node receives 666 Neighbor Advertisements from other nodes already using the address; 667 the latter ensures that two nodes attempting to use the same address 668 simultaneously detect each other's presence. 670 To check an address, a node sends DupAddrDetectTransmits Neighbor 671 Solicitations, each separated by RetransTimer milliseconds. The 672 solicitation's Target Address is set to the address being checked, 673 the IP source is set to the unspecified address and the IP 674 destination is set to the solicited-node multicast address of the 675 target address. 677 If the Neighbor Solicitation is going to be the first message to be 678 sent from an interface after interface (re)initialization, the node 679 should delay joining the solicited-node multicast address by a random 680 delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in RFC 681 2461 [5]. This serves to alleviate congestion when many nodes start 682 up on the link at the same time, such as after a power failure, and 683 may help to avoid race conditions when more than one node is trying 684 to solicit for the same address at the same time. 686 Note that the delay for joining the multicast address implicitly 687 means delaying transmission of the corresponding MLD report message 688 [9]. Since RFC 2710 [9] does not request a random delay to avoid race 689 conditions, just delaying Neighbor Solicitation would cause 690 congestion by the MLD report messages. The congestion would then 691 prevent MLD-snooping switches from working correctly, and, as a 692 result, prevent Duplicate Address Detection from working. The 693 requirement to include the delay for the MLD report in this case 694 avoids this scenario. 696 In order to improve the robustness of the Duplicate Address Detection 697 algorithm, an interface MUST receive and process datagrams sent to 698 the all-nodes multicast address or solicited-node multicast address 699 of the tentative address while the delaying period. This does not 700 necessarily conflict with the requirement that joining the multicast 701 group be delayed. In fact, in some cases it is possible for a node to 702 start listening to the group during the delay period before MLD 703 report transmission. It should be noted, however, that in some 704 link-layer environments, particularly with MLD-snooping switches, no 705 multicast reception will be available until the MLD report is sent. 707 5.4.3 Receiving Neighbor Solicitation Messages 708 On receipt of a valid Neighbor Solicitation message on an interface, 709 node behavior depends on whether the target address is tentative or 710 not. If the target address is not tentative (i.e., it is assigned to 711 the receiving interface), the solicitation is processed as described 712 in RFC 2461 [5]. If the target address is tentative, and the source 713 address is a unicast address, the solicitation's sender is performing 714 address resolution on the target; the solicitation should be silently 715 ignored. Otherwise, processing takes place as described below. In 716 all cases, a node MUST NOT respond to a Neighbor Solicitation for a 717 tentative address. 719 If the source address of the Neighbor Solicitation is the unspecified 720 address, the solicitation is from a node performing Duplicate Address 721 Detection. If the solicitation is from another node, the tentative 722 address is a duplicate and should not be used (by either node). If 723 the solicitation is from the node itself (because the node loops back 724 multicast packets), the solicitation does not indicate the presence 725 of a duplicate address. 727 Implementor's Note: many interfaces provide a way for upper layers to 728 selectively enable and disable the looping back of multicast packets. 729 The details of how such a facility is implemented may prevent 730 Duplicate Address Detection from working correctly. See the Appendix 731 A for further discussion. 733 The following tests identify conditions under which a tentative 734 address is not unique: 736 - If a Neighbor Solicitation for a tentative address is received 737 prior to having sent one, the tentative address is a duplicate. 738 This condition occurs when two nodes run Duplicate Address 739 Detection simultaneously, but transmit initial solicitations at 740 different times (e.g., by selecting different random delay values 741 before joining the solicited-node multicast address and 742 transmitting an initial solicitation). 744 - If the actual number of Neighbor Solicitations received exceeds 745 the number expected based on the loopback semantics (e.g., the 746 interface does not loopback packet, yet one or more solicitations 747 was received), the tentative address is a duplicate. This 748 condition occurs when two nodes run Duplicate Address Detection 749 simultaneously and transmit solicitations at roughly the same 750 time. 752 5.4.4 Receiving Neighbor Advertisement Messages 754 On receipt of a valid Neighbor Advertisement message on an interface, 755 node behavior depends on whether the target address is tentative or 756 matches a unicast or anycast address assigned to the interface. If 757 the target address is assigned to the receiving interface, the 758 solicitation is processed as described in RFC 2461 [5]. If the target 759 address is tentative, the tentative address is not unique. 761 5.4.5 When Duplicate Address Detection Fails 763 A tentative address that is determined to be a duplicate as described 764 above MUST NOT be assigned to an interface and the node SHOULD log a 765 system management error. If the address is a link-local address 766 formed from an interface identifier based on the hardware address 767 (e.g., EUI-64), the interface SHOULD be disabled. In this case, the 768 IP address duplication probably means duplicate hardware addresses 769 are in use, and trying to recover from it by configuring another IP 770 address will not result in a usable network. In fact, it probably 771 makes things worse by creating problems that are harder to diagnose 772 than just shutting down the interface; the user will see a partially 773 working network where some things work, and other things will not. On 774 the other hand, if the duplicated link-local address is not formed 775 from an interface identifier based on the hardware address, the 776 interface MAY continue to be used. 778 5.5 Creation of Global Addresses 780 Global addresses are formed by appending an interface identifier to a 781 prefix of appropriate length. Prefixes are obtained from Prefix 782 Information options contained in Router Advertisements. Creation of 783 global addresses and configuration of other parameters as described 784 in this section SHOULD be locally configurable. However, the 785 processing described below MUST be enabled by default. 787 5.5.1 Soliciting Router Advertisements 789 Router Advertisements are sent periodically to the all-nodes 790 multicast address. To obtain an advertisement quickly, a host sends 791 out Router Solicitations as described in RFC 2461 [5]. 793 5.5.2 Absence of Router Advertisements 795 If a link has no routers, a host MUST attempt to use stateful 796 autoconfiguration to obtain addresses and other configuration 797 information. An implementation MAY provide a way to disable the 798 invocation of stateful autoconfiguration in this case, but the 799 default SHOULD be enabled. From the perspective of 800 autoconfiguration, a link has no routers if no Router Advertisements 801 are received after having sent a small number of Router Solicitations 802 as described in RFC 2461 [5]. 804 5.5.3 Router Advertisement Processing 806 On receipt of a valid Router Advertisement (as defined in RFC 2461 807 [5]), a host copies the value of the advertisement's M bit into 808 ManagedFlag. If the value of ManagedFlag changes from FALSE to TRUE, 809 and the host is not already running the stateful address 810 autoconfiguration protocol, the host should invoke the stateful 811 address autoconfiguration protocol, requesting both address 812 information and other information. If the value of the ManagedFlag 813 changes from TRUE to FALSE, the host should continue running the 814 stateful address autoconfiguration, i.e., the change in the value of 815 the ManagedFlag has no effect. If the value of the flag stays 816 unchanged, no special action takes place. In particular, a host MUST 817 NOT reinvoke stateful address configuration if it is already 818 participating in the stateful protocol as a result of an earlier 819 advertisement. 821 An advertisement's O flag field is processed in an analogous manner. 822 A host copies the value of the O flag into OtherConfigFlag. If the 823 value of OtherConfigFlag changes from FALSE to TRUE, the host should 824 invoke the stateful autoconfiguration protocol, requesting 825 information (excluding addresses if ManagedFlag is set to FALSE). If 826 the value of the OtherConfigFlag changes from TRUE to FALSE, the host 827 should continue running the stateful address autoconfiguration 828 protocol, i.e., the change in the value of OtherConfigFlag has no 829 effect. If the value of the flag stays unchanged, no special action 830 takes place. In particular, a host MUST NOT reinvoke stateful 831 configuration if it is already participating in the stateful protocol 832 as a result of an earlier advertisement. 834 For each Prefix-Information option in the Router Advertisement: 836 a) If the Autonomous flag is not set, silently ignore the Prefix 837 Information option. 839 b) If the prefix is the link-local prefix, silently ignore the 840 Prefix Information option. 842 c) If the preferred lifetime is greater than the valid lifetime, 843 silently ignore the Prefix Information option. A node MAY wish to 844 log a system management error in this case. 846 d) If the prefix advertised does not match the prefix of an address 847 already in the list, and the Valid Lifetime is not 0, form an 848 address (and add it to the list) by combining the advertised 849 prefix with the link's interface identifier as follows: 851 | 128 - N bits | N bits | 852 +---------------------------------------+------------------------+ 853 | link prefix | interface identifier | 854 +----------------------------------------------------------------+ 856 e) If the advertised prefix matches the prefix of an autoconfigured 857 address (i.e., one obtained via stateless or stateful address 858 autoconfiguration) in the list of addresses associated with the 859 interface, the preferred lifetime of the address is reset to the 860 Preferred Lifetime in the received advertisement. The specific 861 action to perform for the valid lifetime of the address depends on 862 the Valid Lifetime in the received advertisement and the remaining 863 time to the valid lifetime expiration of the previously 864 autoconfigured address. We call the remaining time 865 "RemainingLifetime" in the following discussion: 867 1. If the received Valid Lifetime is greater than 2 hours or 868 greater than RemainingLifetime, set the valid lifetime of the 869 corresponding address to the advertised Valid Lifetime. 871 2. If RemainingLifetime is less than or equal to 2 hours, ignore 872 the Prefix Information option with regards to the valid 873 lifetime, unless the Router Advertisement from which this 874 option was obtained has been authenticated (e.g., via IP 875 security [1]). If the Router Advertisement was authenticated, 876 the valid lifetime of the corresponding address should be set 877 to the Valid Lifetime in the received option. 879 3. Otherwise, reset the valid lifetime of the corresponding 880 address to two hours. 882 The above rules address a specific denial of service attack in 883 which a bogus advertisement could contain prefixes with very small 884 Valid Lifetimes. Without the above rules, a single unauthenticated 885 advertisement containing bogus Prefix Information options with 886 short Valid Lifetimes could cause all of a node's addresses to 887 expire prematurely. The above rules ensure that legitimate 888 advertisements (which are sent periodically) will "cancel" the 889 short Valid Lifetimes before they actually take effect. 891 Note that the preferred lifetime of the corresponding address is 892 always reset to the Preferred Lifetime in the received Prefix 893 Information option, regardless of whether the valid lifetime is 894 also reset or ignored. The difference comes from the fact that the 895 possible attack for the preferred lifetime is relatively minor. 896 Additionally, it is even undesirable to ignore the preferred 897 lifetime when a valid administrator wants to deprecate a 898 particular address by sending a short preferred lifetime (and the 899 valid lifetime is ignored by accident). 901 5.5.4 Address Lifetime Expiry 903 A preferred address becomes deprecated when its preferred lifetime 904 expires. A deprecated address SHOULD continue to be used as a source 905 address in existing communications, but SHOULD NOT be used to 906 initiate new communications if an alternate (non-deprecated) address 907 of sufficient scope can easily be used instead. 909 Note that the feasibility of initiating new communication using a 910 non-deprecated address may be an application-specific decision, as 911 only the application may have knowledge about whether the (now) 912 deprecated address was (or still is) in use by the application. For 913 example, if an application explicitly specifies the protocol stack to 914 use a deprecated address as a source address, the protocol stack must 915 accept that; the application might request it because that IP address 916 is used for in higher-level communication and there might be a 917 requirement that the multiple connections in such a grouping use the 918 same pair of IP addresses. 920 IP and higher layers (e.g., TCP, UDP) MUST continue to accept and 921 process datagrams destined to a deprecated address as normal since a 922 deprecated address is still a valid address for the interface. In the 923 case of TCP, this means TCP SYN segments sent to a deprecated address 924 are responded to using the deprecated address as a source address in 925 the corresponding SYN-ACK (if the connection would otherwise be 926 allowed). 928 An implementation MAY prevent any new communication from using a 929 deprecated address, but system management MUST have the ability to 930 disable such a facility, and the facility MUST be disabled by 931 default. 933 Other subtle cases should also be noted about source address 934 selection. For example, the above description does not clarify which 935 address should be used between a deprecated, smaller-scope address 936 and a non-deprecated, enough scope address. The details of the 937 address selection including this case is described in RFC 3484 [8] 938 and beyond the scope of this document. 940 An address (and its association with an interface) becomes invalid 941 when its valid lifetime expires. An invalid address MUST NOT be used 942 as a source address in outgoing communications and MUST NOT be 943 recognized as a destination on a receiving interface. 945 5.6 Configuration Consistency 947 It is possible for hosts to obtain address information using both 948 stateless and stateful protocols since both may be enabled at the 949 same time. It is also possible that the values of other 950 configuration parameters such as MTU size and hop limit will be 951 learned from both Router Advertisements and the stateful 952 autoconfiguration protocol. If the same configuration information is 953 provided by multiple sources, the value of this information should be 954 consistent. However, it is not considered a fatal error if 955 information received from multiple sources is inconsistent. Hosts 956 accept the union of all information received via the stateless and 957 stateful protocols. If inconsistent information is learned different 958 sources, the most recently obtained values always have precedence 959 over information learned earlier. 961 5.7 Retaining Configured Addresses for Stability 963 It is reasonable that implementations that have stable storage retain 964 their addresses and the preferred and valid lifetimes if the 965 addresses were acquired using stateless address autoconfiguration. 966 Assuming the lifetimes used are reasonable, this technique implies 967 that a temporary outage (less than the valid lifetime) of a router 968 will never result in the node losing its global address even if the 969 node were to reboot. This will particularly be useful in "zeroconf" 970 environments where nodes are configuring their addresses by stateless 971 address autoconfiguration but all communication is limited within a 972 single link. In such a case, the failure of a "router" (that provides 973 the prefix for address configuration) is not significant, but losing 974 the global addresses might be a pain; it is true that the node can 975 still use link-local addresses for communication within the link, but 976 the node may want to use global addresses when possible, especially 977 when the other nodes use global addresses. 979 When an implementation tries to reuse a retained address after 980 rebooting, it MUST first try to obtain Router Advertisements as 981 described in RFC 2461[5] and use the retained address only after 982 concluding there are no routers on the link. Additionally, the 983 implementation MUST run Duplicate Address Detection for the address 984 under the criteria described in Section 5.4, as though the address 985 were just configured by stateless address autoconfiguration. The 986 reason for this is because a different host may have started using 987 the address while the rebooting host cannot respond to Duplicate 988 Address Detection from the other host. 990 6. SECURITY CONSIDERATIONS 992 Stateless address autoconfiguration allows a host to connect to a 993 network, configure an address and start communicating with other 994 nodes without ever registering or authenticating itself with the 995 local site. Although this allows unauthorized users to connect to 996 and use a network, the threat is inherently present in the Internet 997 architecture. Any node with a physical attachment to a network can 998 generate an address (using a variety of ad hoc techniques) that 999 provides connectivity. 1001 The use of stateless address autoconfiguration and Duplicate Address 1002 Detection opens up the possibility of several denial of service 1003 attacks. For example, any node can respond to Neighbor Solicitations 1004 for a tentative address, causing the other node to reject the address 1005 as a duplicate. A separate document [10] discusses details about 1006 these attacks. These attacks can be addressed by requiring that 1007 Neighbor Discovery packets be authenticated [1]. However, it should 1008 be noted that [10] points out the use of IP security is not always 1009 feasible depending on network environments. 1011 7. Acknowledgements 1013 The authors would like to thank the members of both the IPNG (which 1014 is now IPV6) and ADDRCONF working groups for their input. In 1015 particular, thanks to Jim Bound, Steve Deering, Richard Draves, and 1016 Erik Nordmark. Thanks also goes to John Gilmore for alerting the WG 1017 of the "0 Lifetime Prefix Advertisement" denial of service attack 1018 vulnerability; this document incorporates changes that address this 1019 vulnerability. 1021 Normative References 1023 [1] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1024 November 1998. 1026 [2] Crawford, M., "A Method for the Transmission of IPv6 Packets 1027 over Ethernet Networks", RFC 2464, December 1998. 1029 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1030 Levels", RFC 2119, March 1997. 1032 [4] Hinden, R. and S. Deering, "Internet Protocol Version (IPv6) 1033 Addressing Architecture", RFC 3513, April 2003. 1035 [5] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 1036 IP Version 6 (IPv6)", RFC 2461, December 1998. 1038 Informative References 1040 [6] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 1041 August 1989. 1043 [7] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 1044 Carney, "Dynamic Host Configuration Protocol for IPv6 1045 (DHCPv6)", RFC 3315, July 2003. 1047 [8] Draves, R., "Default Address Selection for Internet Protocol 1048 version 6 (IPv6)", RFC 3484, February 2003. 1050 [9] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener 1051 Discovery (MLD) for IPv6", RFC 2710, October 1999. 1053 [10] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 1054 Discovery trust models and threats", 1055 draft-ietf-send-psreq-04.txt (work in progress), October 2003. 1057 [11] Park, S., Madanapalli, S. and O. Rao, "IPv6 DAD Consideration 1058 for 802.11 Environment", 1059 draft-park-ipv6-dad-problem-wlan-00.txt (work in progress), 1060 July 2003. 1062 Authors' Addresses 1064 Susan Thomson 1065 Cisco Systems 1067 EMail: sethomso@cisco.com 1069 Thomas Narten 1070 IBM Corporation 1071 P.O. Box 12195 1072 Research Triangle Park, NC 27709-2195 1073 USA 1075 Phone: +1 919-254-7798 1076 EMail: narten@us.ibm.com 1078 Tatuya Jinmei 1079 Corporate Research & Development Center, Toshiba Corporation 1080 1 Komukai Toshiba-cho, Saiwai-ku 1081 Kawasaki-shi, Kanagawa 212-8582 1082 Japan 1084 Phone: +81 44-549-2230 1085 EMail: jinmei@isl.rdc.toshiba.co.jp 1086 Hesham Soliman 1087 Flarion Technologies 1089 EMail: H.Soliman@flarion.com 1091 Appendix A. LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION 1093 Determining whether a received multicast solicitation was looped back 1094 to the sender or actually came from another node is implementation- 1095 dependent. A problematic case occurs when two interfaces attached to 1096 the same link happen to have the same identifier and link-layer 1097 address, and they both send out packets with identical contents at 1098 roughly the same time (e.g., Neighbor Solicitations for a tentative 1099 address as part of Duplicate Address Detection messages). Although a 1100 receiver will receive both packets, it cannot determine which packet 1101 was looped back and which packet came from the other node by simply 1102 comparing packet contents (i.e., the contents are identical). In this 1103 particular case, it is not necessary to know precisely which packet 1104 was looped back and which was sent by another node; if one receives 1105 more solicitations than were sent, the tentative address is a 1106 duplicate. However, the situation may not always be this 1107 straightforward. 1109 The IPv4 multicast specification [6] recommends that the service 1110 interface provide a way for an upper-layer protocol to inhibit local 1111 delivery of packets sent to a multicast group that the sending host 1112 is a member of. Some applications know that there will be no other 1113 group members on the same host, and suppressing loopback prevents 1114 them from having to receive (and discard) the packets they themselves 1115 send out. A straightforward way to implement this facility is to 1116 disable loopback at the hardware level (if supported by the 1117 hardware), with packets looped back (if requested) by software. On 1118 interfaces in which the hardware itself suppresses loopbacks, a node 1119 running Duplicate Address Detection simply counts the number of 1120 Neighbor Solicitations received for a tentative address and compares 1121 them with the number expected. If there is a mismatch, the tentative 1122 address is a duplicate. 1124 In those cases where the hardware cannot suppress loopbacks, however, 1125 one possible software heuristic to filter out unwanted loopbacks is 1126 to discard any received packet whose link-layer source address is the 1127 same as the receiving interface's. There is even a link-layer 1128 specification that requires to discard any such packets [11]. 1129 Unfortunately, use of that criteria also results in the discarding of 1130 all packets sent by another node using the same link-layer address. 1131 Duplicate Address Detection will fail on interfaces that filter 1132 received packets in this manner: 1134 o If a node performing Duplicate Address Detection discards received 1135 packets having the same source link-layer address as the receiving 1136 interface, it will also discard packets from other nodes also 1137 using the same link-layer address, including Neighbor 1138 Advertisement and Neighbor Solicitation messages required to make 1139 Duplicate Address Detection work correctly. This particular 1140 problem can be avoided by temporarily disabling the software 1141 suppression of loopbacks while a node performs Duplicate Address 1142 Detection, if it is possible to disable the suppression. 1144 o If a node that is already using a particular IP address discards 1145 received packets having the same link-layer source address as the 1146 interface, it will also discard Duplicate Address 1147 Detection-related Neighbor Solicitation messages sent by another 1148 node also using the same link-layer address. Consequently, 1149 Duplicate Address Detection will fail, and the other node will 1150 configure a non-unique address. Since it is generally impossible 1151 to know when another node is performing Duplicate Address 1152 Detection, this scenario can be avoided only if software 1153 suppression of loopback is permanently disabled. 1155 Thus, to perform Duplicate Address Detection correctly in the case 1156 where two interfaces are using the same link-layer address, an 1157 implementation must have a good understanding of the interface's 1158 multicast loopback semantics, and the interface cannot discard 1159 received packets simply because the source link-layer address is the 1160 same as the interfaces. It should also be noted that a link-layer 1161 specification can conflict with the condition necessary to make 1162 Duplicate Address Detection work. 1164 Appendix B. CHANGES SINCE RFC 1971 1166 o Changed document to use term "interface identifier" rather than 1167 "interface token" for consistency with other IPv6 documents. 1169 o Clarified definition of deprecated address to make clear it is OK 1170 to continue sending to or from deprecated addresses. 1172 o Added rules to Section 5.5.3 Router Advertisement processing to 1173 address potential denial-of-service attack when prefixes are 1174 advertised with very short Lifetimes. 1176 o Clarified wording in Section 5.5.4 to make clear that all upper 1177 layer protocols must process (i.e., send and receive) packets sent 1178 to deprecated addresses. 1180 Appendix C. CHANGE HISTORY 1182 Changes since RFC 2462 are: 1184 o Fixed a typo in Section 2. 1186 o Updated references and categorized them into normative and 1187 informative ones. 1189 o Removed redundant code in denial of service protection in Section 1190 5.5.3. 1192 o Clarified that a unicasted NS or NA should be discarded while 1193 performing Duplicate Address Detection. 1195 o Replaced the word "StoredLifetime" with "RemainingLifetime" with a 1196 precise definition to avoid confusion. 1198 o Removed references to site-local and revise wording around the 1199 keyword. 1201 o Added a note about source address selection with regards to 1202 deprecated vs insufficient-scope addresses, etc. Added a reference 1203 to RFC 3484 for further details. 1205 o Clarified what "new communication" means in Section 5.5.4. 1207 o Added a new subsection (5.7) to mention the possibility to use 1208 stable storage to retain configured addresses for stability. 1210 o Revised the Security Considerations section with a refence to the 1211 send requirement document and a note that the use of IP security 1212 is not always feasible. 1214 o Added a note with a reference in Appendix A about the case where a 1215 link-layer filtering conflicts with a condition to make DAD work 1216 correctly. 1218 o Specified that a node performing Duplicate Address Detection delay 1219 joining the solicited-node multicast group, not just delay sending 1220 Neighbor Solicitations, explaining the detailed reason. 1222 o Clarified the reason why the interface should be disabled after an 1223 address duplicate is detected. Also clarified that the interface 1224 may continue to be used if the interface identifier is not based 1225 on the hardware address. 1227 o Clarified that the preferred lifetime for an existing configured 1228 address is always reset to the advertised value by Router 1229 Advertisement. 1231 o Updated the description of interface identifier considering the 1232 latest format. 1234 Appendix D. OPEN ISSUES 1236 Semi-Open Issues (resolutions were proposed, but they may need 1237 further discussions): 1239 o [2462bis issue 271] An implementation may want to use stable 1240 storage for autoconfigured addresses. 1242 o [2462bis issue 274] There is conflict with the Multicast Listener 1243 Discovery specification about random delay for the first packet. 1245 o [2462bis issue 278] Whether a router (not a host) can 1246 autoconfigure itself using the stateless autoconfiguration 1247 protocol may need to be discussed. 1249 Open Issues (resolutions have not been proposed yet): 1251 o [2462bis issue 275] Many DAD related issues have been discussed, 1252 including whether it is okay to omit DAD in some environments or 1253 whether DAD can be replaced with DIID (duplicate interface ID 1254 detection). 1256 o [2462bis issue 277] The semantics of the M/O flags is not very 1257 clear. 1259 1. the text needs to be updated to use RFC 2119 keywords 1261 2. which keywords? 1263 3. what is "the stateful configuration protocol"? 1265 4. if the answer to the previous question is DHCPv6, should this 1266 specification more explicitly reference the configuration-only 1267 version of DHCPv6 in the description of the 'O'flag? 1269 o [2462bis issue 281] It is not very clear whether this document 1270 always require a 64-bit Interface ID. 1272 Intellectual Property Statement 1274 The IETF takes no position regarding the validity or scope of any 1275 intellectual property or other rights that might be claimed to 1276 pertain to the implementation or use of the technology described in 1277 this document or the extent to which any license under such rights 1278 might or might not be available; neither does it represent that it 1279 has made any effort to identify any such rights. Information on the 1280 IETF's procedures with respect to rights in standards-track and 1281 standards-related documentation can be found in BCP-11. Copies of 1282 claims of rights made available for publication and any assurances of 1283 licenses to be made available, or the result of an attempt made to 1284 obtain a general license or permission for the use of such 1285 proprietary rights by implementors or users of this specification can 1286 be obtained from the IETF Secretariat. 1288 The IETF invites any interested party to bring to its attention any 1289 copyrights, patents or patent applications, or other proprietary 1290 rights which may cover technology that may be required to practice 1291 this standard. Please address the information to the IETF Executive 1292 Director. 1294 Full Copyright Statement 1296 Copyright (C) The Internet Society (2004). All Rights Reserved. 1298 This document and translations of it may be copied and furnished to 1299 others, and derivative works that comment on or otherwise explain it 1300 or assist in its implementation may be prepared, copied, published 1301 and distributed, in whole or in part, without restriction of any 1302 kind, provided that the above copyright notice and this paragraph are 1303 included on all such copies and derivative works. However, this 1304 document itself may not be modified in any way, such as by removing 1305 the copyright notice or references to the Internet Society or other 1306 Internet organizations, except as needed for the purpose of 1307 developing Internet standards in which case the procedures for 1308 copyrights defined in the Internet Standards process must be 1309 followed, or as required to translate it into languages other than 1310 English. 1312 The limited permissions granted above are perpetual and will not be 1313 revoked by the Internet Society or its successors or assignees. 1315 This document and the information contained herein is provided on an 1316 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1317 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1318 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1319 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1320 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1322 Acknowledgement 1324 Funding for the RFC Editor function is currently provided by the 1325 Internet Society.