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