idnits 2.17.1 draft-ietf-addrconf-ipv6-auto-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 531: '...A node MUST allow the following autoco...' RFC 2119 keyword, line 613: '...ddress Detection MUST be performed on ...' RFC 2119 keyword, line 626: '...address MUST be tested for uniqueness ...' RFC 2119 keyword, line 667: '...A node MUST silently discard any Neigh...' RFC 2119 keyword, line 674: '...ation, an interface MUST join the all-...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 282 has weird spacing: '... as the dest...' == Line 554 has weird spacing: '...waits after s...' == Line 1017 has weird spacing: '...ore.com email...' == Line 1054 has weird spacing: '...icating that ...' -- 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 (November 3, 1995) is 10402 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 1826 (Obsoleted by RFC 2402) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-ETHER' -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-addr-arch is -02, but you're referring to -03. ** Downref: Normative reference to an Historic draft: draft-ietf-ipngwg-addr-arch (ref. 'ADDR-ARCH') -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCPv6' -- Possible downref: Non-RFC (?) normative reference: ref. 'DISCOVERY' Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ADDRCONF Working Group Susan Thomson, Bellcore 2 INTERNET-DRAFT Thomas Narten, IBM 3 November 3, 1995 5 IPv6 Stateless Address Autoconfiguration 7 Status of this Memo 9 This document is a submission to the ADDRCONF Working Group of the 10 Internet Engineering Task Force (IETF). Comments should be submitted 11 to the addrconf@cisco.com mailing list. 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material or to cite them other than as a "working 22 draft" or "work in progress." 24 To learn the current status of any Internet Draft. please check the 25 1id-abstracts.txt listing contained in the Internet Drafts Shadow 26 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com or 27 munnari.oz.au. 29 Distribution of this memo is unlimited. 31 This Internet Draft expires May 3, 1996. 33 Abstract 35 This document specifies how hosts autoconfigure their interfaces in 36 IP version 6. The autoconfiguration process includes creating a 37 link-local address and verifying its uniqueness on a link, 38 determining what information should be autoconfigured (addresses, 39 other information, or both), and in the case of addresses, whether 40 they should be obtained through the stateless mechanism, the stateful 41 mechanism, or both. This document defines the process for generating 42 a link-local address, the process for generating site-local and 43 global addresses, and Duplicate Address Detection. Stateful address 44 autoconfiguration is specified elsewhere. 46 Contents 48 Status of this Memo....................................... 1 50 1. INTRODUCTION.......................................... 3 52 2. TERMINOLOGY........................................... 4 53 2.1. Requirements..................................... 7 55 3. DESIGN GOALS.......................................... 8 57 4. PROTOCOL OVERVIEW..................................... 9 58 4.1. Site Renumbering................................. 11 60 5. PROTOCOL SPECIFICATION................................ 12 61 5.1. Node Configuration Variables..................... 12 62 5.2. Autoconfiguration-Related Variables.............. 12 63 5.3. Creation of Link-Local Addresses................. 13 64 5.4. Duplicate Address Detection...................... 14 65 5.4.1. Message Validation.......................... 15 66 5.4.2. Sending Neighbor Solicitation Messages...... 15 67 5.4.3. Receiving Neighbor Solicitation Messages.... 16 68 5.4.4. Receiving Neighbor Advertisement Messages... 16 69 5.4.5. When Duplicate Address Detection Fails...... 17 70 5.5. Creation of Global- and Site-Local Addresses..... 17 71 5.5.1. Soliciting Router Advertisements............ 17 72 5.5.2. Absence of Router Advertisements............ 17 73 5.5.3. Router Advertisement Processing............. 17 74 5.5.4. Address Lifetime Expiry..................... 19 75 5.6. Configuration Consistency........................ 19 77 6. OPEN ISSUES/TODO...................................... 20 79 7. SECURITY CONSIDERATIONS............................... 20 81 8. APPENDIX: LOOPBACK SUPPRESSION AND DUPLICATE ADDRESS DETECTION 20 83 9. REFERENCES............................................ 22 85 AUTHORS' ADDRESSES........................................ 22 87 CHANGES SINCE PREVIOUS DOCUMENT........................... 24 89 1. INTRODUCTION 91 This document specifies how hosts autoconfigure their interfaces in IP 92 version 6. The autoconfiguration process includes creating a link-local 93 address and verifying its uniqueness on a link, determining what 94 information should be autoconfigured (addresses, other information, or 95 both), and in the case of addresses, whether they should be obtained 96 through the stateless mechanism, the stateful mechanism, or both. This 97 document defines the process for generating a link-local address, the 98 process for generating site-local and global addresses, and Duplicate 99 Address Detection. Stateful address autoconfiguration is specified 100 elsewhere. 102 IPv6 defines both a stateful and stateless address autoconfiguration 103 mechanism. Stateless autoconfiguration requires no manual configuration 104 of hosts, minimal (if any) configuration of routers, and no additional 105 servers. The stateless mechanism allows a host to generate its own 106 addresses using a combination of locally available information and 107 information advertised by routers. Routers advertise prefixes that 108 identify the subnet(s) associated with a link, while hosts generate an 109 "interface token" that uniquely identifies an interface on a subnet. An 110 address is formed by combining the two. In the absence of routers, a 111 host can only generate link-local addresses. However, link-local 112 addresses are sufficient for allowing communication among nodes attached 113 to the same link. 115 In the stateful autoconfiguration model, hosts obtain interface 116 addresses and/or configuration information and parameters from a server. 117 Servers maintain a database that keeps track of which addresses have 118 been assigned to which hosts. The stateful autoconfiguration protocol 119 allows hosts to obtain addresses, other configuration information or 120 both from a server. Stateless and stateful autoconfiguration complement 121 each other. For example, a host can use stateless autoconfiguration to 122 configure its own addresses, but use stateful autoconfiguration to 123 obtain other information. Stateful autoconfiguration is described in 124 [DHCPv6]. 126 The stateless approach is used when a site is not particularly concerned 127 with the exact addresses hosts use, so long as they are unique and 128 properly routable. The stateful approach is used when a site requires 129 tighter control over exact address assignments. Both stateful and 130 stateless address autoconfiguration may be used simultaneously. The 131 site administrator specifies which type of autoconfiguration to use 132 through the setting of appropriate fields in Router Advertisement 133 messages [DISCOVERY]. 135 IPv6 addresses are leased to an interface for a fixed (possibly 136 infinite) length of time. Each address has an associated lifetime that 137 indicates how long the address is bound to an interface. When a lifetime 138 expires, the binding (and address) become invalid and the address may be 139 reassigned to another interface elsewhere in the Internet. To handle the 140 expiration of address bindings gracefully, an address goes through two 141 distinct phases while assigned to an interface. Initially, an address is 142 "preferred", meaning that its use in arbitrary communication is 143 unrestricted. Later, an address becomes "deprecated" in anticipation 144 that its current interface binding will become invalid. While in a 145 deprecated state, the use of an address is discouraged, but not strictly 146 forbidden. New communication (e.g., the opening of a new TCP 147 connection) should use a preferred address when possible. A deprecated 148 address should be used only by applications that have been using it and 149 would have difficulty switching to another address without a service 150 disruption. 152 To insure that all configured addresses are unique, nodes run a 153 "duplicate address detection" algorithm on addresses before assigning 154 them to an interface. The Duplicate Address Detection algorithm is 155 performed on all addresses, independent of whether they are obtained via 156 stateless or stateful autoconfiguration. This document defines the 157 Duplicate Address Detection algorithm. 159 The autoconfiguration process specified in this document applies only to 160 hosts and not routers. Since host autoconfiguration uses information 161 advertised by routers, routers will need to be configured by some other 162 means. However, it is expected that routers will generate link-local 163 addresses using the mechanism described in this document. In addition, 164 routers are expected to successfully pass the Duplicate Address 165 Detection procedure described in this document on all addresses prior to 166 assigning them to an interface. 168 Section 2 provides definitions for terminology used throughout this 169 document. Section 3 describes the design goals that lead to the current 170 autoconfiguration procedure. Section 4 provides an overview of the 171 protocol, while Section 5 describes the protocol in detail. 173 2. TERMINOLOGY 175 IP - Internet Protocol Version 6. The terms IPv4 and IPv6 176 are used only in contexts where necessary to avoid 177 ambiguity. 179 node - a device that implements IP. 181 router - a node that forwards IP packets not explicitly 182 addressed to itself. 184 host - any node that is not a router. 186 upper layer - a protocol layer immediately above IP. Examples are 187 transport protocols such as TCP and UDP, control 188 protocols such as ICMP, routing protocols such as OSPF, 189 and internet or lower-layer protocols being "tunneled" 190 over (i.e., encapsulated in) IP such as IPX, AppleTalk, 191 or IP itself. 193 link - a communication facility or medium over which nodes can 194 communicate at the link layer, i.e., the layer 195 immediately below IP. Examples are Ethernets (simple 196 or bridged); PPP links; X.25, Frame Relay, or ATM 197 networks; and internet (or higher) layer "tunnels", 198 such as tunnels over IPv4 or IPv6 itself. 200 interface - a node's attachment to a link. 202 packet - an IP header plus payload. 204 address - an IP-layer identifier for an interface or a set of 205 interfaces. 207 unicast address 208 - an identifier for a single interface. A packet sent to 209 a unicast address is delivered to the interface 210 identified by that address. 212 multicast address 213 - an identifier for a set of interfaces (typically 214 belonging to different nodes). A packet sent to a 215 multicast address is delivered to all interfaces 216 identified by that address. 218 solicited-node multicast address 219 - a multicast address to which Neighbor Solicitation 220 messages are sent. The algorithm for computing the 221 address is given in [DISCOVERY]. 223 link-layer address 224 - a link-layer identifier for an interface. Examples 225 include IEEE 802 addresses for Ethernet links and E.164 226 addresses for ISDN links. 228 link-local address 229 - an address having link-only scope that can be used to 230 reach neighboring nodes attached to the same link. All 231 interfaces have a link-local unicast address. 233 site-local address 234 - an address having scope that is limited to the local 235 site. 237 global address 238 - an address with unlimited scope. 240 communication 241 - any packet exchange among nodes that requires that the 242 address of each node used in the exchange remain the 243 same for the duration of the packet exchange. Examples 244 are a TCP connection or a UDP request-response. 246 tentative address 247 - an address whose uniqueness on a link is being 248 verified, prior to its assignment to an interface. A 249 tentative address is not considered assigned to an 250 interface in the usual sense. An interface discards 251 received packets addressed to a tentative address, but 252 accepts Neighbor Discovery packets related to Duplicate 253 Address Detection for the tentative address. 255 preferred address 256 - an address assigned to an interface whose use by upper 257 layer protocols is unrestricted. Preferred addresses 258 may be used as the source (or destination) address of 259 packets sent from (or to) the interface. 261 deprecated address 262 - An address assigned to an interface whose use is 263 discouraged, but not forbidden. A deprecated address 264 should no longer be used as a source address in new 265 communications, but packets sent to deprecated 266 addresses are delivered as expected. A deprecated 267 address may continue to be used as a source address in 268 communications where switching to a preferred address 269 causes hardship to a specific upper-layer activity 270 (e.g., an existing TCP connection). 272 valid address 273 - a preferred or deprecated address. A valid address may 274 appear as the source or destination address of a 275 packet, and the internet routing system is expected to 276 deliver packets sent to a valid address. 278 invalid address 279 - an address that is not assigned to any interface. A 280 valid address becomes invalid when its deprecation 281 lifetime expires. Invalid addresses should not appear 282 as the destination or source address of a packet. In 283 the former case, the internet routing system will be 284 unable to deliver the packet, in the later case the 285 recipient of the packet will be unable to respond to 286 it. 288 preferred lifetime 289 - the length of time that a valid address is preferred 290 (i.e., the time until deprecation). When the preferred 291 lifetime expires, the address becomes deprecated. 293 valid lifetime 294 - the length of time an address remains in the valid 295 state (i.e., the time until invalidation). The valid 296 lifetime must be greater then or equal to the preferred 297 lifetime. When the valid lifetime expires, the address 298 becomes invalid. 300 interface token 301 - a link-dependent identifier for an interface that is 302 (at least) unique per link. Stateless address 303 autoconfiguration combines an interface token with a 304 prefix to form an address. From address 305 autoconfiguration's perspective, an interface token is 306 a bit string of known length. The exact length of an 307 interface token and the way it is created is defined in 308 a separate link-specific document that covers issues 309 related to the transmission of IP over a particular 310 link type (e.g., [IPv6-ETHER]). In many cases, the 311 token will be the same as the interface's link-layer 312 address. 314 2.1. Requirements 316 Throughout this document, the words that are used to define the 317 significance of the particular requirements are capitalized. These 318 words are: 320 MUST 321 This word or the adjective "REQUIRED" means that the item is an 322 absolute requirement of this specification. 324 MUST NOT 325 This phrase means the item is an absolute prohibition of this 326 specification. 328 SHOULD 329 This word or the adjective "RECOMMENDED" means that there may exist 330 valid reasons in particular circumstances to ignore this item, but 331 the full implications should be understood and the case carefully 332 weighed before choosing a different course. 334 SHOULD NOT 335 This phrase means that there may exist valid reasons in particular 336 circumstances when the listed behavior is acceptable or even 337 useful, but the full implications should be understood and the case 338 carefully weighed before implementing any behavior described with 339 this label. 341 MAY 342 This word or the adjective "OPTIONAL" means that this item is truly 343 optional. One vendor may choose to include the item because a 344 particular marketplace requires it or because it enhances the 345 product, for example, another vendor may omit the same item. 347 3. DESIGN GOALS 349 Stateless autoconfiguration is designed with the following goals in 350 mind: 352 o Manual configuration of individual machines before connecting them 353 to the network should not be required. Consequently, a mechanism is 354 needed that allows a host to obtain or create unique addresses for 355 each of its interfaces. Address autoconfiguration assumes that each 356 interface can provide a unique identifier for that interface (i.e., 357 an "interface token"). In the simplest case, an interface token 358 consists of the interface's link-layer address. An interface token 359 can be combined with a prefix to form an address. 361 o Small sites consisting of a set of machines attached to a single 362 link should not require the presence of a stateful server or router 363 as a prerequisite for communicating. Plug-and-play communication 364 is achieved through the use of link-local addresses. Link-local 365 addresses have a well-known prefix that identifies the (single) 366 shared link to which a set of nodes attach. A host forms a link- 367 local address by appending its interface token to the link-local 368 prefix. 370 o A large site with multiple networks and routers should not require 371 the presence of a stateful address configuration server. In order 372 to generate site-local or global addresses, hosts must determine 373 the prefixes that identify the subnets to which they attach. 375 Routers generate periodic Router Advertisements that include 376 options listing the set of active prefixes on a link. 378 o Address configuration should facilitate the graceful renumbering of 379 a site's machines. For example, a site may wish to renumber all of 380 its nodes when it switches to a new network service provider. 381 Renumbering is achieved through the leasing of addresses to 382 interfaces and the assignment of multiple addresses to the same 383 interface. Lease lifetimes provide the mechanism through which a 384 site phases out old prefixes. The assignment of multiple addresses 385 to an interface provides for a transition period during which both 386 a new address and the one being phased out work simultaneously. 388 o System administrators need the ability to specify whether stateless 389 autoconfiguration, stateful autoconfiguration, or both should be 390 used. Router Advertisements include flags specifying which 391 mechanisms a host should use. 393 4. PROTOCOL OVERVIEW 395 This section provides an overview of the typical steps that take place 396 when an interface autoconfigures itself. Autoconfiguration is performed 397 only on multicast-capable links and begins when a multicast-capable 398 interface is enabled, e.g., during system startup. Nodes (both hosts 399 and routers) begin the autoconfiguration process by generating a link- 400 local address for the interface. A link-local address is formed by 401 appending the interface's token to the well-known link-local prefix. 403 Before the link-local address can be assigned to an interface and used, 404 however, a node must attempt to verify that this "tentative" address is 405 not already in use by another node on the link. Specifically, it sends a 406 Neighbor Solicitation message containing the tentative address as the 407 target. If another node is already using that address, it will return a 408 Neighbor Advertisement saying so. If another node is also attempting to 409 use the same address, it will send a Neighbor Solicitation for the 410 target as well. The exact number of times the Neighbor Solicitation is 411 (re)transmitted and the delay time between consecutive solicitations is 412 link-specific and may be set by system management. 414 If a node determines that its tentative link-local address is not 415 unique, autoconfiguration stops and manual configuration of the machine 416 is required. To simplify recovery in this case, it should be possible 417 for an administrator to supply an alternate interface token that 418 overrides the default token in such a way that the autoconfiguration 419 mechanism can then be applied using the new (presumably unique) 420 interface token. Alternatively, link-local and other addresses will 421 need to be configured manually. 423 Once a node ascertains that its tentative link-local address is unique, 424 it assigns it to the interface. At this point, the node has IP-level 425 connectivity with neighboring nodes. The remaining autoconfiguration 426 steps are performed only by hosts; the (auto)configuration of routers is 427 beyond the scope of this document. 429 The next phase of autoconfiguration involves obtaining a Router 430 Advertisement or determining that no routers are present. If routers are 431 present, they will send Router Advertisements that specify what sort of 432 autoconfiguration a host should do. If no routers are present, stateful 433 autoconfiguration should be invoked. 435 Routers send Router Advertisements periodically, but the delay between 436 successive advertisements will generally be longer than a host 437 performing autoconfiguration will want to wait [DISCOVERY]. To obtain 438 an advertisement quickly, a host sends one or more Router Solicitations 439 to the all-routers multicast group. Router Advertisements contain two 440 flags indicating what type of stateful autoconfiguration (if any) should 441 be performed. A "managed address configuration" flag indicates whether 442 hosts should use stateful autoconfiguration to obtain addresses. An 443 "other stateful configuration" flag indicates whether hosts should use 444 stateful autoconfiguration to obtain additional information (excluding 445 addresses). 447 Router Advertisements also contain zero or more Prefix Information 448 options that contain information used by stateless address 449 autoconfiguration to generate site-local and global addresses. It 450 should be noted that the stateless and stateful address 451 autoconfiguration fields in Router Advertisements are processed 452 independently of one another, and a host may use both stateful and 453 stateless address autoconfiguration simultaneously. One Prefix 454 Information option field, the "autonomous address-configuration flag", 455 indicates whether or not the option even applies to stateless 456 autoconfiguration. If it does, additional option fields contain a 457 subnet prefix together with lifetime values indicating how long 458 addresses created from the prefix remain preferred and valid. 460 Because routers generate Router Advertisements periodically, hosts will 461 continually receive new advertisements. Hosts process the information 462 contained in each advertisement as described above, adding to and 463 refreshing information received in previous advertisements. 465 For safety, all addresses must be tested for uniqueness prior to their 466 assignment to an interface. In the case of addresses created through 467 stateless autoconfig, however, the uniqueness of an address is 468 determined primarily by the portion of the address formed from an 469 interface token. Thus, if a node has already verified the uniqueness of 470 a link-local address, additional addresses created from the same 471 interface token need not be tested individually. In contrast, all 472 addresses obtained manually or via stateful address autoconfiguration 473 should be tested for uniqueness individually. To accommodate sites that 474 believe the overhead of performing Duplicate Address Detection outweighs 475 its benefits, the use of Duplicate Address Detection can be disabled 476 through the administrative setting of a per-interface configuration 477 flag. 479 To speed the autoconfiguration process, a host may generate its link- 480 local address (and verify its uniqueness) in parallel with waiting for a 481 Router Advertisement. Because a router may delay responding to a Router 482 Solicitation for a few seconds, the total time needed to complete 483 autoconfiguration can be significantly longer if the two steps are done 484 serially. 486 4.1. Site Renumbering 488 Address leasing facilitates site renumbering by providing a mechanism to 489 time-out addresses in hosts. At present, upper layer protocols such as 490 TCP provide no support for changing endpoint addresses while a 491 connection is open. If an end-point address becomes invalid, existing 492 connections break and all communication to the invalid address fails. 493 Even when applications use UDP as a transport protocol, addresses must 494 generally remain the same during a packet exchange. 496 Dividing valid addresses into preferred and deprecated categories 497 provides a way of indicating to upper layers that a valid address may 498 become invalid shortly and that future communication using the address 499 will fail, should the address's deprecation lifetime expire before 500 communication ends. To avoid this scenario, higher layers should use a 501 preferred address (assuming one of sufficient scope exists) to increase 502 the likelihood that an address will remain valid for the duration of the 503 communication. It is up to system administrators to set appropriate 504 prefix lifetimes in order to minimize the impact of failed communication 505 when renumbering takes place. The deprecation period should be long 506 enough that most, if not all, communications are using the new address 507 at the time an address becomes invalid. 509 The IP layer is expected to provide a means for upper layers (including 510 applications) to select the most appropriate source address given a 511 particular destination and possibly other constraints. An application 512 may choose to select the source address itself before starting a new 513 communication or may leave the address unspecified, in which case the 514 upper networking layers will use the mechanism provided by the IP layer 515 to choose a suitable address on the application's behalf. 517 Detailed address selection rules are beyond the scope of this document. 519 5. PROTOCOL SPECIFICATION 521 Autoconfiguration is performed on a per-interface basis on multicast- 522 capable interfaces. For multihomed hosts, autoconfiguration is 523 performed independently on each interface. Autoconfiguration applies 524 primarily to hosts, with two exceptions. Routers are expected to 525 generate a link-local address using the procedure outlined below. In 526 addition, routers perform Duplicate Address Detection on all addresses 527 prior to assigning them to an interface. 529 5.1. Node Configuration Variables 531 A node MUST allow the following autoconfiguration-related variable to be 532 configured for each multicast interface: 534 DupAddrDetectTransmits 536 The number of consecutive Neighbor Solicitation 537 messages sent while performing Duplicate Address 538 Detection on a tentative address. A value of zero 539 indicates that Duplicate Address Detection is not 540 performed on tentative addresses. A value of one 541 indicates a single transmission with no follow up 542 retransmissions. 544 Default: 1, but may be overridden by a link-specific 545 value in the document that covers issues related to 546 the transmission of IP over a particular link type 547 (e.g., [IPv6-ETHER]). 549 Autoconfiguration also assumes the presence of the variable RetransTimer 550 as defined in [DISCOVERY]. For autoconfiguration purposes, RetransTimer 551 specifies the delay between consecutive Neighbor Solicitation 552 transmissions performed during Duplicate Address Detection (if 553 DupAddrDetectTransmits is greater than 1), as well as the time a node 554 waits after sending the last Neighbor Solicitation before ending the 555 Duplicate Address Detection process. 557 5.2. Autoconfiguration-Related Variables 559 A host maintains a number of data structures and flags related to 560 autoconfiguration. In the following, we present conceptual variables and 561 show how they are used to perform autoconfiguration. The specific 562 variables are used for demonstration purposes only, and an 563 implementation is not required to have them, so long as its external 564 behavior is consistent with that described in this document. 566 How routers (auto)configure their interfaces is beyond the scope of this 567 document. 569 ManagedFlag Copied from the Managed field of the most recently 570 received Router Advertisement message. The flag 571 indicates whether or not addresses are to be 572 configured using the stateful autoconfiguration 573 mechanism. It starts out in a FALSE state. 575 OtherConfigFlag Copied from the Other field of the most recently 576 received Router Advertisement message. The flag 577 indicates whether or not information other than 578 addresses are to be obtained using the stateful 579 autoconfiguration mechanism. It starts out in a 580 FALSE state. 582 A host also maintains a list of addresses together with their 583 corresponding lifetimes. The address list contains both autoconfigured 584 addresses and those configured manually. 586 5.3. Creation of Link-Local Addresses 588 A node forms a link-local address whenever an interface becomes enabled. 589 An interface may become enabled after any of the following events: 591 - The interface is initialized at system startup time. 593 - The interface is reinitialized after a temporary interface failure 594 or after being temporarily disabled by system management. 596 - The interface attaches to a link for the first time. 598 - The interface becomes enabled by system management after having 599 been administratively disabled. 601 A link-local address is formed by prepending the well-known link-local 602 prefix FE80::0 [ADDR-ARCH] (of appropriate length) to the interface 603 token. If the interface token has a length of N bits, the interface 604 token replaces the right-most N zero bits of the link-local prefix. If 605 the interface token is more than 118 bits in length, autoconfiguration 606 fails and manual configuration is required. 608 A link-local address has an infinite preferred and valid lifetime; it is 609 never timed out. 611 5.4. Duplicate Address Detection 613 Duplicate Address Detection MUST be performed on unicast addresses prior 614 to assigning them to an interface whose DupAddrDetectTransmits variable 615 is greater than zero. Duplicate Address Detection takes place on all 616 unicast addresses, regardless of whether they are obtained through 617 stateful, stateless or manual configuration. Each individual address 618 SHOULD be tested for uniqueness. However, when stateless address 619 autoconfiguration is used, address uniqueness is determined solely by 620 the interface token, assuming that subnet prefixes are assigned 621 correctly (i.e., if all of an interface's addresses are generated from 622 the same token, either all addresses or none of them will be 623 duplicates). Thus, for a set of addresses formed from the same interface 624 token, it is sufficient to check that the link-local address generated 625 from the token is unique on the link. In such cases, the link-local 626 address MUST be tested for uniqueness before any of the other addresses 627 can be assigned to an interface. 629 The procedure for detecting duplicate addresses uses Neighbor 630 Solicitation and Advertisement messages as described below. If a 631 duplicate address is discovered during the procedure, the address cannot 632 be assigned to the interface. If the address is derived from an 633 interface token, a new token will need to be assigned to the interface, 634 or all IP addresses for the interface will need to be manually 635 configured. Note that the method for detecting duplicates is not 636 completely reliable, and it is possible that duplicate addresses will 637 still exist. 639 An address on which the duplicate Address Detection Procedure is applied 640 is said to be tentative until the procedure has completed successfully. 641 A tentative address is not considered "assigned to an interface" in the 642 traditional sense. That is, the interface must accept Neighbor 643 Solicitation and Advertisement messages containing the tentative address 644 in the Target Address field, but processes such packets differently from 645 those whose Target Address matches an address assigned to the interface. 646 Other packets addressed to the tentative address should be silently 647 discarded. 649 It should also be noted that Duplicate Address Detection must be 650 performed prior to assigning an address to an interface in order to 651 prevent multiple nodes from using the same address simultaneously. If a 652 node begins using an address in parallel with Duplicate Address 653 Detection, and another node is already using the address, the node 654 performing Duplicate Address Detection will erroneously process traffic 655 intended for the other node, resulting in such possible negative 656 consequences as the resetting of open TCP connections. 658 The following subsections describe specific tests a node performs to 659 verify an address's uniqueness. An address is considered unique if none 660 of the tests indicate the presence of a duplicate address within 661 RetransTimer milliseconds after having sent DupAddrDetectTransmits 662 Neighbor Solicitations. Once an address is determined to be unique, it 663 may be assigned to an interface. 665 5.4.1. Message Validation 667 A node MUST silently discard any Neighbor Solicitation or Advertisement 668 message that does not pass the validity checks specified in [DISCOVERY]. 669 A solicitation that passes these validity checks is called a valid 670 solicitation or valid advertisement. 672 5.4.2. Sending Neighbor Solicitation Messages 674 Before sending a Neighbor Solicitation, an interface MUST join the all- 675 nodes multicast address and the solicited-node multicast address of the 676 tentative address. The former insures that the node receives Neighbor 677 Advertisements from other nodes already using the address; the latter 678 insures that two nodes attempting to use the same address simultaneously 679 detect each other's presence. 681 To check an address, a node sends DupAddrDetectTransmits Neighbor 682 Solicitations, each separated by RetransTimer milliseconds. The 683 solicitation's Target Address is set to the address being checked, the 684 IP source is set to the unspecified address and the IP destination is 685 set to the solicited-node multicast address of the target address. 687 If the Neighbor Solicitation is the first message to be sent from an 688 interface after interface (re)initialization, the node should delay 689 sending the message by a random delay between 0 and 690 MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY]. This serves to 691 alleviate congestion when many nodes start up on the link at the same 692 time, such as after a power failure, and may help to avoid race 693 conditions when more than one node is trying to solicit for the same 694 address at the same time. In order to improve the robustness of the 695 Duplicate Address Detection algorithm, an interface MUST receive and 696 process datagrams sent to the all-nodes multicast address or solicited- 697 node multicast address of the tentative address while delaying 698 transmission of the initial Neighbor Solicitation. 700 5.4.3. Receiving Neighbor Solicitation Messages 702 On receipt of a valid Neighbor Solicitation message on an interface, 703 node behavior depends on whether the target address is tentative or not. 704 If the target address is not tentative (i.e., it is assigned to the 705 receiving interface), the solicitation is processed in the normal way 706 [DISCOVERY]. If the target address is tentative, and the source address 707 is a unicast address, the solicitation's sender is performing address 708 resolution on the target; the solicitation should be silently ignored. 709 Otherwise, processing takes place as described below. In all cases, a 710 node MUST NOT respond to a Neighbor Solicitation for a tentative 711 address. 713 If the source address of the Neighbor Solicitation is the unspecified 714 address, the solicitation is from a node performing Duplicate Address 715 Detection. If the solicitation is from another node, the tentative 716 address is a duplicate and should not be used (by either node). If the 717 solicitation is from the node itself (because the node loops back 718 multicast packets), the solicitation does not indicate the presence of a 719 duplicate address. 721 Implementor's Note: many interfaces provide a way for upper layers to 722 selectively enable and disable the looping back of multicast packets. 723 The details of how such a facility is implemented may prevent Duplicate 724 Address Detection from working correctly. See Appendix XXX for further 725 discussion. 727 The following tests identify conditions under which a tentative address 728 is not unique: 730 - If a Neighbor Solicitation for a tentative address is received 731 prior to having sent one, the tentative address is a duplicate. 732 This condition occurs when two nodes run Duplicate Address 733 Detection simultaneously, but transmit initial solicitations at 734 different times (e.g., by selecting different random delay values 735 before transmitting an initial solicitation). 737 - If the actual number of Neighbor Solicitations received exceeds the 738 number expected based on the loopback semantics (e.g., the 739 interface does not loopback packet, yet one or more solicitations 740 was received), the tentative address is a duplicate. This condition 741 occurs when two nodes run Duplicate Address Detection 742 simultaneously and transmit solicitations at roughly the same time. 744 5.4.4. Receiving Neighbor Advertisement Messages 746 On receipt of a valid Neighbor Advertisement message on an interface, 747 node behavior depends on whether the target address is tentative or not. 748 If the target address is not tentative, the solicitation is processed in 749 the normal way [DISCOVERY]. If the target address is tentative, the 750 tentative address is not unique. 752 5.4.5. When Duplicate Address Detection Fails 754 A tentative address that is determined to be a duplicate as described 755 above, MUST NOT be assigned to an interface and the node SHOULD log a 756 system management error. If the address is a link-local address formed 757 from an interface token, the interface SHOULD be disabled. 759 5.5. Creation of Global- and Site-Local Addresses 761 Global- and site-local addresses are formed by appending an interface 762 token to a prefix of appropriate length. Prefixes are obtained from 763 Prefix Information options contained in Router Advertisements. Creation 764 of global and site-local addresses and configuration of other parameters 765 as described in this section SHOULD be locally configurable. However, 766 this processing MUST be enabled by default. 768 5.5.1. Soliciting Router Advertisements 770 Router Advertisements are sent periodically to the all-nodes multicast 771 address. To obtain an advertisement quickly, a host sends out Router 772 Solicitations as described in [DISCOVERY]. 774 5.5.2. Absence of Router Advertisements 776 If a link has no routers, a host MUST attempt to use stateful 777 autoconfiguration to obtain addresses and other configuration 778 information. An implementation MAY provide a way to disable the 779 invocation of stateful autoconfiguration in this case, but the default 780 SHOULD be enabled. From the perspective of autoconfiguration, a link 781 has no routers if no Router Advertisements are received after having 782 sent a small number of Router Solicitations as described in [DISCOVERY]. 784 5.5.3. Router Advertisement Processing 786 On receipt of a valid Router Advertisement (as defined in [DISCOVERY]), 787 a host copies the value of the advertisement's Managed bit into 788 ManagedFlag. If the value of ManagedFlag changes from FALSE to TRUE, the 789 host should invoke the stateful address autoconfiguration protocol, 790 requesting address information. If the value of the ManagedFlag changes 791 from TRUE to FALSE, any activity related to stateful address 792 autoconfiguration should be halted. If the value of the flag stays 793 unchanged, no special action takes place. In particular, a host MUST NOT 794 reinvoke stateful address configuration if it is already participating 795 in the stateful protocol as a result of an earlier advertisement. 797 An advertisement's Other bit is processed in an analogous manner. A host 798 copies the value of the Other bit into OtherConfigFlag. If the value of 799 OtherConfigFlag changes from FALSE to TRUE, the host should invoke the 800 stateful autoconfiguration protocol, requesting information (excluding 801 addresses). If the value of the OtherConfigFlag changes from TRUE to 802 FALSE, any activity related to stateful autoconfiguration for parameters 803 other than addresses should be halted. If the value of the flag stays 804 unchanged, no special action takes place. In particular, a host MUST NOT 805 reinvoke stateful configuration if it is already participating in the 806 stateful protocol as a result of an earlier advertisement. 808 For each Prefix-Information option in the Router Advertisement: 810 a) If the Autonomous flag is not set, silently ignore the Prefix 811 Information option. 813 b) If the prefix is the link-local prefix, silently ignore the Prefix 814 Information option. 816 c) If the preferred lifetime is greater than the valid lifetime, 817 silently ignore the Prefix Information option. A node MAY wish to 818 log a system management error in this case. 820 d) If the advertised prefix matches the prefix of an autoconfigured 821 address in the list of addresses associated with the interface, set 822 the preferred timer to that of the option's preferred lifetime, and 823 set the valid lifetime to that of the option's valid lifetime. 825 e) If the prefix advertised does not match the prefix of an address 826 already in the list, then form an address (and add it to the list) 827 by appending the interface token to the prefix as follows: 829 | 128 - N bits | N bits | 830 +---------------------------------------+------------------------+ 831 | link prefix | interface token | 832 +----------------------------------------------------------------+ 834 If the sum of the prefix length and interface token length does not 835 equal 128 bits, the Prefix Information option MUST be ignored. An 836 implementation MAY wish to log a system management error in this 837 case. It is the responsibility of the system administrator to insure 838 that the lengths of prefixes contained in Router Advertisements are 839 consistent with the length of interface tokens for that link type. 841 In those cases where a site requires the use of longer prefixes than 842 can be accommodated by the interface token, stateful 843 autoconfiguration can be used. 845 If an address is formed successfully, the host adds it to 846 AddressList, initializing its preferred and valid lifetime values 847 from the Prefix Information option. 849 5.5.4. Address Lifetime Expiry 851 A preferred address becomes deprecated when its preferred lifetime 852 expires. A deprecated address SHOULD continue to be used as a source 853 address in existing communications, but SHOULD NOT be used in new 854 communications if an alternate (non-deprecated) address is available and 855 has sufficient scope. The IP layer MUST continue to accept datagrams 856 destined to a deprecated address since a deprecated address is still a 857 valid address for the interface. 859 An address (and its association with an interface) becomes invalid when 860 its valid lifetime expires. An invalid address MUST NOT be used as a 861 source address in outgoing communications and MUST NOT be recognized as 862 a destination on a receiving interface. 864 Note that if a Prefix Information option is received with a preferred 865 lifetime of zero, any addresses generated from that prefix are 866 immediately deprecated. Similarly, if both the advertised deprecated and 867 valid lifetimes are zero, any addresses generated from that prefix 868 immediately become invalid immediately. 870 5.6. Configuration Consistency 872 It is possible for hosts to obtain address information using both 873 stateless and stateful protocols since both may be enabled at the same 874 time. It is also possible that the values of other configuration 875 parameters such as MTU size and hop limit will be learned from both 876 Router Advertisements and the stateful autoconfiguration protocol. If 877 the same configuration information is provided by multiple sources, the 878 value of this information should be consistent. However, it is not 879 considered a fatal error if information received from multiple sources 880 is inconsistent. Hosts accept the union of all information received via 881 the stateless and stateful protocols. If inconsistent information is 882 learned from different sources, the most recently obtained values always 883 have precedence over information learned earlier. 885 6. OPEN ISSUES/TODO 887 o figure out how to do appendices in nroff 889 o add wording that indicates that addrconf is required to be turned on 890 by default? 892 o Add wording suggesting DAD and waiting for RAs be done in parallel. 894 7. SECURITY CONSIDERATIONS 896 Stateless address autoconfiguration allows a host to connect to a 897 network, configure an address and start communicating with other nodes 898 without ever registering or authenticating itself with the local site. 899 Although this allows unauthorized users to connect to and use a network, 900 the threat is inherently present in the Internet architecture. Any node 901 with a physical attachment to a network can generate an address (using a 902 variety of ad hoc techniques) that provides connectivity. 904 The use of Duplicate Address Detection opens up the possibility of 905 denial of service attacks. Any node can respond to Neighbor 906 Solicitations for a tentative address, causing the other node to reject 907 the address as a duplicate. This attack is similar to other attacks 908 involving the spoofing of Neighbor Discovery messages and can be 909 addressed by requiring that Neighbor Discovery packets be authenticated 910 [RFC1826]. 912 8. APPENDIX: LOOPBACK SUPPRESSION AND DUPLICATE ADDRESS DETECTION 914 Determining whether a multicast solicitation was looped back to the 915 sender or actually came from another node is implementation-dependent. 916 A problematic case occurs when two interfaces attached to the same link 917 happen to have the same token and link-layer address, and they both send 918 out packets with identical contents at roughly the same time (e.g., 919 Neighbor Solicitations for a tentative address as part of Duplicate 920 Address Detection messages). Although a receiver will receive both 921 packets, it cannot determine which packet was looped back and which 922 packet came from the other node by simply comparing packet contents 923 (i.e., the contents are identical). In this particular case, it is not 924 necessary to know precisely which packet was looped back and which was 925 sent by another node; if one receives more solicitations than were sent, 926 the tentative address is a duplicate. However, the situation may not 927 always be this straightforward. 929 The IPv4 multicast specification [RFC1112] recommends that the service 930 interface provide a way for an upper-layer protocol to inhibit local 931 delivery of packets sent to a multicast group that the sending host is a 932 member of. Some applications know that there will be no other group 933 members on the same host, and suppressing loopback prevents them from 934 having to receive (and discard) the packets they themselves send out. A 935 straightforward way to implement this facility is to disable loopback at 936 the hardware level (if supported by the hardware), with packets looped 937 back (if requested) by software. On interfaces in which the hardware 938 itself suppresses loopbacks, a node running Duplicate Address Detection 939 simply counts the number of Neighbor Solicitations received for a 940 tentative address and compares them with the number expected. If there 941 is a mismatch, the tentative address is a duplicate. 943 In those cases where the hardware cannot suppress loopbacks, however, 944 one possible software heuristic to filter out unwanted loopbacks is to 945 discard any received packet whose link-layer source address is the same 946 as the receiving interface's. Unfortunately, use of that criteria also 947 results in the discarding of all packets sent by another node using the 948 same link-layer address. Duplicate Address Detection will fail on 949 interfaces that filter received packets in this manner: 951 o If a node performing Duplicate Address Detection discards received 952 packets having the same source link-layer address as the receiving 953 interface, it will also discard packets from other nodes also using 954 the same link-layer address, including Neighbor Advertisement and 955 Neighbor Solicitation messages required to make Duplicate Address 956 Detection work correctly. This particular problem can be avoided 957 by temporarily disabling the software suppression of loopbacks 958 while a node performs Duplicate Address Detection. 960 o If a node that is already using a particular IP address discards 961 received packets having the same link-layer source address as the 962 interface, it will also discard Duplicate Address Detection-related 963 Neighbor Solicitation messages sent by another node also using the 964 same link-layer address. Consequently, Duplicate Address Detection 965 will fail, and the other node will configure a non-unique address. 966 Since it is generally impossible to know when another node is 967 performing Duplicate Address Detection, this scenario can be 968 avoided only if software suppression of loopback is permanently 969 disabled. 971 Thus, to perform Duplicate Address Detection correctly in the case where 972 two interfaces are using the same link-layer address, an implementation 973 must have a good understanding of the interface's multicast loopback 974 semantics, and the interface cannot discard received packets simply 975 because the source link-layer address is the same as the interfaces. 977 9. REFERENCES 979 [RFC1826] 980 R. Atkinson. "IP Authentication Header", RFC 1826, August 1995. 982 [IPv6-ETHER] 983 M. Crawford. "A Method for the Transmission of IPv6 Packets over 984 Ethernet Networks", Internet Draft. 986 [RFC1112] 987 S. Deering, "Host Extensions for IP Multicasting", RFC 1112, 988 August, 1989. 990 [ADDR-ARCH] 991 R. Hinden and S. Deering, "Internet Protocol Version (IPv6) 992 Addressing Architecture", Internet Draft, May 1995, draft-ietf- 993 ipngwg-addr-arch-03.txt 995 [DHCPv6] 996 Internet Draft, Work in Progress. 998 [DISCOVERY] 999 T. Narten, E. Nordmark and W. A. Simpson, "Neighbor Discovery 1000 for IP Version 6 (IPv6)", Internet Draft, September 1995, 1001 1003 Acknowledgements 1005 The authors would like to thank the members of both the IPNG and 1006 ADDRCONF working groups for their input. In particular, thanks to Jim 1007 Bound, Steve Deering, and Erik Nordmark. 1009 AUTHORS' ADDRESSES 1010 Susan Thomson Thomas Narten 1011 Bellcore IBM Corporation 1012 445 South Street P.O. Box 12195 1013 Morristown, NJ 07960 Research Triangle Park, NC 27709-2195 1014 USA USA 1016 phone: +1 201-829-4514 phone: +1 919 254 7798 1017 email: set@thumper.bellcore.com email: narten@vnet.ibm.com 1018 CHANGES SINCE PREVIOUS DOCUMENT 1020 Changes since based on feedback 1021 from the working group: 1023 o modified DAD text re loopback suppression and added appendix 1024 describing how DAD breaks if an interface discards all received 1025 packets having the same source link-layer address as the receiving 1026 interface. Added that DAD must be applied to link-layer address for 1027 stateless. 1029 o Numerous editorial/wordsmithing changes. 1031 o security section added 1033 o loosened requirement that interface be disabled if DAD fails. Now 1034 say address shouldn't be assigned to interface. However, if address 1035 was derived from interface token (e.g., link-layer address), then 1036 interface should be disabled since its effectively disabled in any 1037 case (no autoconfigured addresses can be formed on this interface.) 1039 o Use term "link-layer address" rather than "hardware address". 1041 o Corrected typo in definition of link-local prefix (E8 -> FE80). 1043 o Removed AutoConfig variable, left as implementation issue how user 1044 selects what type of autoconfig is desired, though default is 1045 enabled 1047 o Added DupAddrDetectTransmits variable specifying how many 1048 transmissions to perform as part of DAD (defaults to 1, may be 0), 1049 and specify that ND's RetransTimer as the retransmit timer between 1050 consecutive NSs. 1052 o defined interface token to be a bit string. 1054 o added text indicating that autoconfiguration only applies to 1055 multicast-capable interfaces. 1057 o changed name of OtherFlag variable to OtherConfigFlag