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