idnits 2.17.1 draft-ietf-addrconf-ipv6-auto-06.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-19) 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. ** 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 540: '...A node MUST allow the following autoco...' RFC 2119 keyword, line 623: '...ddress Detection MUST be performed on ...' RFC 2119 keyword, line 628: '...Detection MUST NOT be performed on any...' RFC 2119 keyword, line 629: '...unicast address SHOULD be tested for u...' RFC 2119 keyword, line 637: '...local address MUST be tested for uniqu...' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 563 has weird spacing: '...waits after s...' == Line 969 has weird spacing: '...ore.com email...' == Line 1094 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 15, 1995) is 10383 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: 11 errors (**), 0 flaws (~~), 4 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 15, 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 15, 1996. 33 Abstract 35 This document specifies the steps a host takes in deciding how to 36 autoconfigure its interfaces in IP version 6. The autoconfiguration 37 process includes creating a link-local address and verifying its 38 uniqueness on a link, determining what information should be 39 autoconfigured (addresses, other information, or both), and in the 40 case of addresses, whether they should be obtained through the 41 stateless mechanism, the stateful mechanism, or both. This document 42 defines the process for generating a link-local address, the process 43 for generating site-local and global addresses via stateless address 44 autoconfiguration, and the Duplicate Address Detection procedure. The 45 details of autoconfiguration using the stateful protocol are 46 specified elsewhere. 48 Contents 50 Status of this Memo.......................................... 1 52 1. INTRODUCTION............................................. 4 54 2. TERMINOLOGY.............................................. 5 55 2.1. Requirements........................................ 8 57 3. DESIGN GOALS............................................. 9 59 4. PROTOCOL OVERVIEW........................................ 10 60 4.1. Site Renumbering.................................... 12 62 5. PROTOCOL SPECIFICATION................................... 13 63 5.1. Node Configuration Variables........................ 13 64 5.2. Autoconfiguration-Related Variables................. 14 65 5.3. Creation of Link-Local Addresses.................... 14 66 5.4. Duplicate Address Detection......................... 15 67 5.4.1. Message Validation............................. 16 68 5.4.2. Sending Neighbor Solicitation Messages......... 16 69 5.4.3. Receiving Neighbor Solicitation Messages....... 17 70 5.4.4. Receiving Neighbor Advertisement Messages...... 18 71 5.4.5. When Duplicate Address Detection Fails......... 18 72 5.5. Creation of Global- and Site-Local Addresses........ 18 73 5.5.1. Soliciting Router Advertisements............... 18 74 5.5.2. Absence of Router Advertisements............... 19 75 5.5.3. Router Advertisement Processing................ 19 76 5.5.4. Address Lifetime Expiry........................ 20 77 5.6. Configuration Consistency........................... 21 79 OPEN ISSUES/TODO............................................. 21 81 SECURITY CONSIDERATIONS...................................... 21 83 REFERENCES................................................... 22 85 AUTHORS' ADDRESSES........................................... 22 87 APPENDIX: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION. 23 89 CHANGES SINCE PREVIOUS DOCUMENT.............................. 24 91 1. INTRODUCTION 93 This document specifies the steps a host takes in deciding how to 94 autoconfigure its interfaces in IP version 6. The autoconfiguration 95 process includes creating a link-local address and verifying its 96 uniqueness on a link, determining what information should be 97 autoconfigured (addresses, other information, or both), and in the case 98 of addresses, whether they should be obtained through the stateless 99 mechanism, the stateful mechanism, or both. This document defines the 100 process for generating a link-local address, the process for generating 101 site-local and global addresses via stateless address autoconfiguration, 102 and the Duplicate Address Detection procedure. The details of 103 autoconfiguration using the stateful protocol are specified elsewhere. 105 IPv6 defines both a stateful and stateless address autoconfiguration 106 mechanism. Stateless autoconfiguration requires no manual configuration 107 of hosts, minimal (if any) configuration of routers, and no additional 108 servers. The stateless mechanism allows a host to generate its own 109 addresses using a combination of locally available information and 110 information advertised by routers. Routers advertise prefixes that 111 identify the subnet(s) associated with a link, while hosts generate an 112 "interface token" that uniquely identifies an interface on a subnet. An 113 address is formed by combining the two. In the absence of routers, a 114 host can only generate link-local addresses. However, link-local 115 addresses are sufficient for allowing communication among nodes attached 116 to the same link. 118 In the stateful autoconfiguration model, hosts obtain interface 119 addresses and/or configuration information and parameters from a server. 120 Servers maintain a database that keeps track of which addresses have 121 been assigned to which hosts. The stateful autoconfiguration protocol 122 allows hosts to obtain addresses, other configuration information or 123 both from a server. Stateless and stateful autoconfiguration complement 124 each other. For example, a host can use stateless autoconfiguration to 125 configure its own addresses, but use stateful autoconfiguration to 126 obtain other information. Stateful autoconfiguration is described in 127 [DHCPv6]. 129 The stateless approach is used when a site is not particularly concerned 130 with the exact addresses hosts use, so long as they are unique and 131 properly routable. The stateful approach is used when a site requires 132 tighter control over exact address assignments. Both stateful and 133 stateless address autoconfiguration may be used simultaneously. The 134 site administrator specifies which type of autoconfiguration to use 135 through the setting of appropriate fields in Router Advertisement 136 messages [DISCOVERY]. 138 IPv6 addresses are leased to an interface for a fixed (possibly 139 infinite) length of time. Each address has an associated lifetime that 140 indicates how long the address is bound to an interface. When a lifetime 141 expires, the binding (and address) become invalid and the address may be 142 reassigned to another interface elsewhere in the Internet. To handle the 143 expiration of address bindings gracefully, an address goes through two 144 distinct phases while assigned to an interface. Initially, an address is 145 "preferred", meaning that its use in arbitrary communication is 146 unrestricted. Later, an address becomes "deprecated" in anticipation 147 that its current interface binding will become invalid. While in a 148 deprecated state, the use of an address is discouraged, but not strictly 149 forbidden. New communication (e.g., the opening of a new TCP 150 connection) should use a preferred address when possible. A deprecated 151 address should be used only by applications that have been using it and 152 would have difficulty switching to another address without a service 153 disruption. 155 To insure that all configured addresses are likely to be unique on a 156 given link, nodes run a "duplicate address detection" algorithm on 157 addresses before assigning them to an interface. The Duplicate Address 158 Detection algorithm is performed on all addresses, independent of 159 whether they are obtained via stateless or stateful autoconfiguration. 160 This document defines the Duplicate Address Detection algorithm. 162 The autoconfiguration process specified in this document applies only to 163 hosts and not routers. Since host autoconfiguration uses information 164 advertised by routers, routers will need to be configured by some other 165 means. However, it is expected that routers will generate link-local 166 addresses using the mechanism described in this document. In addition, 167 routers are expected to successfully pass the Duplicate Address 168 Detection procedure described in this document on all addresses prior to 169 assigning them to an interface. 171 Section 2 provides definitions for terminology used throughout this 172 document. Section 3 describes the design goals that lead to the current 173 autoconfiguration procedure. Section 4 provides an overview of the 174 protocol, while Section 5 describes the protocol in detail. 176 2. TERMINOLOGY 178 IP - Internet Protocol Version 6. The terms IPv4 and IPv6 179 are used only in contexts where necessary to avoid 180 ambiguity. 182 node - a device that implements IP. 184 router - a node that forwards IP packets not explicitly 185 addressed to itself. 187 host - any node that is not a router. 189 upper layer - a protocol layer immediately above IP. Examples are 190 transport protocols such as TCP and UDP, control 191 protocols such as ICMP, routing protocols such as OSPF, 192 and internet or lower-layer protocols being "tunneled" 193 over (i.e., encapsulated in) IP such as IPX, AppleTalk, 194 or IP itself. 196 link - a communication facility or medium over which nodes can 197 communicate at the link layer, i.e., the layer 198 immediately below IP. Examples are Ethernets (simple 199 or bridged); PPP links; X.25, Frame Relay, or ATM 200 networks; and internet (or higher) layer "tunnels", 201 such as tunnels over IPv4 or IPv6 itself. 203 interface - a node's attachment to a link. 205 packet - an IP header plus payload. 207 address - an IP-layer identifier for an interface or a set of 208 interfaces. 210 unicast address 211 - an identifier for a single interface. A packet sent to 212 a unicast address is delivered to the interface 213 identified by that address. 215 multicast address 216 - an identifier for a set of interfaces (typically 217 belonging to different nodes). A packet sent to a 218 multicast address is delivered to all interfaces 219 identified by that address. 221 anycast address 222 - an identifier for a set of interfaces (typically 223 belonging to different nodes). A packet sent to an 224 anycast address is delivered to one of the interfaces 225 identified by that address (the "nearest" one, 226 according to the routing protocol's measure of 227 distance). See [ADDR-ARCH]. 229 solicited-node multicast address 230 - a multicast address to which Neighbor Solicitation 231 messages are sent. The algorithm for computing the 232 address is given in [DISCOVERY]. 234 link-layer address 235 - a link-layer identifier for an interface. Examples 236 include IEEE 802 addresses for Ethernet links and E.164 237 addresses for ISDN links. 239 link-local address 240 - an address having link-only scope that can be used to 241 reach neighboring nodes attached to the same link. All 242 interfaces have a link-local unicast address. 244 site-local address 245 - an address having scope that is limited to the local 246 site. 248 global address 249 - an address with unlimited scope. 251 communication 252 - any packet exchange among nodes that requires that the 253 address of each node used in the exchange remain the 254 same for the duration of the packet exchange. Examples 255 are a TCP connection or a UDP request-response. 257 tentative address 258 - an address whose uniqueness on a link is being 259 verified, prior to its assignment to an interface. A 260 tentative address is not considered assigned to an 261 interface in the usual sense. An interface discards 262 received packets addressed to a tentative address, but 263 accepts Neighbor Discovery packets related to Duplicate 264 Address Detection for the tentative address. 266 preferred address 267 - an address assigned to an interface whose use by upper 268 layer protocols is unrestricted. Preferred addresses 269 may be used as the source (or destination) address of 270 packets sent from (or to) the interface. 272 deprecated address 273 - An address assigned to an interface whose use is 274 discouraged, but not forbidden. A deprecated address 275 should no longer be used as a source address in new 276 communications, but packets sent to deprecated 277 addresses are delivered as expected. A deprecated 278 address may continue to be used as a source address in 279 communications where switching to a preferred address 280 causes hardship to a specific upper-layer activity 281 (e.g., an existing TCP connection). 283 valid address 284 - a preferred or deprecated address. A valid address may 285 appear as the source or destination address of a 286 packet, and the internet routing system is expected to 287 deliver packets sent to a valid address. 289 invalid address 290 - an address that is not assigned to any interface. A 291 valid address becomes invalid when its valid lifetime 292 expires. Invalid addresses should not appear as the 293 destination or source address of a packet. In the 294 former case, the internet routing system will be unable 295 to deliver the packet, in the later case the recipient 296 of the packet will be unable to respond to it. 298 preferred lifetime 299 - the length of time that a valid address is preferred 300 (i.e., the time until deprecation). When the preferred 301 lifetime expires, the address becomes deprecated. 303 valid lifetime 304 - the length of time an address remains in the valid 305 state (i.e., the time until invalidation). The valid 306 lifetime must be greater then or equal to the preferred 307 lifetime. When the valid lifetime expires, the address 308 becomes invalid. 310 interface token 311 - a link-dependent identifier for an interface that is 312 (at least) unique per link. Stateless address 313 autoconfiguration combines an interface token with a 314 prefix to form an address. From address 315 autoconfiguration's perspective, an interface token is 316 a bit string of known length. The exact length of an 317 interface token and the way it is created is defined in 318 a separate link-type specific document that covers 319 issues related to the transmission of IP over a 320 particular link type (e.g., [IPv6-ETHER]). In many 321 cases, the token will be the same as the interface's 322 link-layer address. 324 2.1. Requirements 326 Throughout this document, the words that are used to define the 327 significance of the particular requirements are capitalized. These 328 words are: 330 MUST 331 This word or the adjective "REQUIRED" means that the item is an 332 absolute requirement of this specification. 334 MUST NOT 335 This phrase means the item is an absolute prohibition of this 336 specification. 338 SHOULD 339 This word or the adjective "RECOMMENDED" means that there may exist 340 valid reasons in particular circumstances to ignore this item, but 341 the full implications should be understood and the case carefully 342 weighed before choosing a different course. 344 SHOULD NOT 345 This phrase means that there may exist valid reasons in particular 346 circumstances when the listed behavior is acceptable or even 347 useful, but the full implications should be understood and the case 348 carefully weighed before implementing any behavior described with 349 this label. 351 MAY 352 This word or the adjective "OPTIONAL" means that this item is truly 353 optional. One vendor may choose to include the item because a 354 particular marketplace requires it or because it enhances the 355 product, for example, another vendor may omit the same item. 357 3. DESIGN GOALS 359 Stateless autoconfiguration is designed with the following goals in 360 mind: 362 o Manual configuration of individual machines before connecting them 363 to the network should not be required. Consequently, a mechanism is 364 needed that allows a host to obtain or create unique addresses for 365 each of its interfaces. Address autoconfiguration assumes that each 366 interface can provide a unique identifier for that interface (i.e., 367 an "interface token"). In the simplest case, an interface token 368 consists of the interface's link-layer address. An interface token 369 can be combined with a prefix to form an address. 371 o Small sites consisting of a set of machines attached to a single 372 link should not require the presence of a stateful server or router 373 as a prerequisite for communicating. Plug-and-play communication 374 is achieved through the use of link-local addresses. Link-local 375 addresses have a well-known prefix that identifies the (single) 376 shared link to which a set of nodes attach. A host forms a link- 377 local address by appending its interface token to the link-local 378 prefix. 380 o A large site with multiple networks and routers should not require 381 the presence of a stateful address configuration server. In order 382 to generate site-local or global addresses, hosts must determine 383 the prefixes that identify the subnets to which they attach. 384 Routers generate periodic Router Advertisements that include 385 options listing the set of active prefixes on a link. 387 o Address configuration should facilitate the graceful renumbering of 388 a site's machines. For example, a site may wish to renumber all of 389 its nodes when it switches to a new network service provider. 390 Renumbering is achieved through the leasing of addresses to 391 interfaces and the assignment of multiple addresses to the same 392 interface. Lease lifetimes provide the mechanism through which a 393 site phases out old prefixes. The assignment of multiple addresses 394 to an interface provides for a transition period during which both 395 a new address and the one being phased out work simultaneously. 397 o System administrators need the ability to specify whether stateless 398 autoconfiguration, stateful autoconfiguration, or both should be 399 used. Router Advertisements include flags specifying which 400 mechanisms a host should use. 402 4. PROTOCOL OVERVIEW 404 This section provides an overview of the typical steps that take place 405 when an interface autoconfigures itself. Autoconfiguration is performed 406 only on multicast-capable links and begins when a multicast-capable 407 interface is enabled, e.g., during system startup. Nodes (both hosts 408 and routers) begin the autoconfiguration process by generating a link- 409 local address for the interface. A link-local address is formed by 410 appending the interface's token to the well-known link-local prefix. 412 Before the link-local address can be assigned to an interface and used, 413 however, a node must attempt to verify that this "tentative" address is 414 not already in use by another node on the link. Specifically, it sends a 415 Neighbor Solicitation message containing the tentative address as the 416 target. If another node is already using that address, it will return a 417 Neighbor Advertisement saying so. If another node is also attempting to 418 use the same address, it will send a Neighbor Solicitation for the 419 target as well. The exact number of times the Neighbor Solicitation is 420 (re)transmitted and the delay time between consecutive solicitations is 421 link-specific and may be set by system management. 423 If a node determines that its tentative link-local address is not 424 unique, autoconfiguration stops and manual configuration of the machine 425 is required. To simplify recovery in this case, it should be possible 426 for an administrator to supply an alternate interface token that 427 overrides the default token in such a way that the autoconfiguration 428 mechanism can then be applied using the new (presumably unique) 429 interface token. Alternatively, link-local and other addresses will 430 need to be configured manually. 432 Once a node ascertains that its tentative link-local address is unique, 433 it assigns it to the interface. At this point, the node has IP-level 434 connectivity with neighboring nodes. The remaining autoconfiguration 435 steps are performed only by hosts; the (auto)configuration of routers is 436 beyond the scope of this document. 438 The next phase of autoconfiguration involves obtaining a Router 439 Advertisement or determining that no routers are present. If routers are 440 present, they will send Router Advertisements that specify what sort of 441 autoconfiguration a host should do. If no routers are present, stateful 442 autoconfiguration should be invoked. 444 Routers send Router Advertisements periodically, but the delay between 445 successive advertisements will generally be longer than a host 446 performing autoconfiguration will want to wait [DISCOVERY]. To obtain 447 an advertisement quickly, a host sends one or more Router Solicitations 448 to the all-routers multicast group. Router Advertisements contain two 449 flags indicating what type of stateful autoconfiguration (if any) should 450 be performed. A "managed address configuration" flag indicates whether 451 hosts should use stateful autoconfiguration to obtain addresses. An 452 "other stateful configuration" flag indicates whether hosts should use 453 stateful autoconfiguration to obtain additional information (excluding 454 addresses). 456 Router Advertisements also contain zero or more Prefix Information 457 options that contain information used by stateless address 458 autoconfiguration to generate site-local and global addresses. It 459 should be noted that the stateless and stateful address 460 autoconfiguration fields in Router Advertisements are processed 461 independently of one another, and a host may use both stateful and 462 stateless address autoconfiguration simultaneously. One Prefix 463 Information option field, the "autonomous address-configuration flag", 464 indicates whether or not the option even applies to stateless 465 autoconfiguration. If it does, additional option fields contain a 466 subnet prefix together with lifetime values indicating how long 467 addresses created from the prefix remain preferred and valid. 469 Because routers generate Router Advertisements periodically, hosts will 470 continually receive new advertisements. Hosts process the information 471 contained in each advertisement as described above, adding to and 472 refreshing information received in previous advertisements. 474 For safety, all addresses must be tested for uniqueness prior to their 475 assignment to an interface. In the case of addresses created through 476 stateless autoconfig, however, the uniqueness of an address is 477 determined primarily by the portion of the address formed from an 478 interface token. Thus, if a node has already verified the uniqueness of 479 a link-local address, additional addresses created from the same 480 interface token need not be tested individually. In contrast, all 481 addresses obtained manually or via stateful address autoconfiguration 482 should be tested for uniqueness individually. To accommodate sites that 483 believe the overhead of performing Duplicate Address Detection outweighs 484 its benefits, the use of Duplicate Address Detection can be disabled 485 through the administrative setting of a per-interface configuration 486 flag. 488 To speed the autoconfiguration process, a host may generate its link- 489 local address (and verify its uniqueness) in parallel with waiting for a 490 Router Advertisement. Because a router may delay responding to a Router 491 Solicitation for a few seconds, the total time needed to complete 492 autoconfiguration can be significantly longer if the two steps are done 493 serially. 495 4.1. Site Renumbering 497 Address leasing facilitates site renumbering by providing a mechanism to 498 time-out addresses in hosts. At present, upper layer protocols such as 499 TCP provide no support for changing endpoint addresses while a 500 connection is open. If an end-point address becomes invalid, existing 501 connections break and all communication to the invalid address fails. 502 Even when applications use UDP as a transport protocol, addresses must 503 generally remain the same during a packet exchange. 505 Dividing valid addresses into preferred and deprecated categories 506 provides a way of indicating to upper layers that a valid address may 507 become invalid shortly and that future communication using the address 508 will fail, should the address's valid lifetime expire before 509 communication ends. To avoid this scenario, higher layers should use a 510 preferred address (assuming one of sufficient scope exists) to increase 511 the likelihood that an address will remain valid for the duration of the 512 communication. It is up to system administrators to set appropriate 513 prefix lifetimes in order to minimize the impact of failed communication 514 when renumbering takes place. The deprecation period should be long 515 enough that most, if not all, communications are using the new address 516 at the time an address becomes invalid. 518 The IP layer is expected to provide a means for upper layers (including 519 applications) to select the most appropriate source address given a 520 particular destination and possibly other constraints. An application 521 may choose to select the source address itself before starting a new 522 communication or may leave the address unspecified, in which case the 523 upper networking layers will use the mechanism provided by the IP layer 524 to choose a suitable address on the application's behalf. 526 Detailed address selection rules are beyond the scope of this document. 528 5. PROTOCOL SPECIFICATION 530 Autoconfiguration is performed on a per-interface basis on multicast- 531 capable interfaces. For multihomed hosts, autoconfiguration is 532 performed independently on each interface. Autoconfiguration applies 533 primarily to hosts, with two exceptions. Routers are expected to 534 generate a link-local address using the procedure outlined below. In 535 addition, routers perform Duplicate Address Detection on all addresses 536 prior to assigning them to an interface. 538 5.1. Node Configuration Variables 540 A node MUST allow the following autoconfiguration-related variable to be 541 configured by system management for each multicast interface: 543 DupAddrDetectTransmits 545 The number of consecutive Neighbor Solicitation 546 messages sent while performing Duplicate Address 547 Detection on a tentative address. A value of zero 548 indicates that Duplicate Address Detection is not 549 performed on tentative addresses. A value of one 550 indicates a single transmission with no follow up 551 retransmissions. 553 Default: 1, but may be overridden by a link-type 554 specific value in the document that covers issues 555 related to the transmission of IP over a particular 556 link type (e.g., [IPv6-ETHER]). 558 Autoconfiguration also assumes the presence of the variable RetransTimer 559 as defined in [DISCOVERY]. For autoconfiguration purposes, RetransTimer 560 specifies the delay between consecutive Neighbor Solicitation 561 transmissions performed during Duplicate Address Detection (if 562 DupAddrDetectTransmits is greater than 1), as well as the time a node 563 waits after sending the last Neighbor Solicitation before ending the 564 Duplicate Address Detection process. 566 5.2. Autoconfiguration-Related Variables 568 A host maintains a number of data structures and flags related to 569 autoconfiguration. In the following, we present conceptual variables and 570 show how they are used to perform autoconfiguration. The specific 571 variables are used for demonstration purposes only, and an 572 implementation is not required to have them, so long as its external 573 behavior is consistent with that described in this document. 575 Beyond the formation of a link-local address and using Duplicate Address 576 Detection, how routers (auto)configure their interfaces is beyond the 577 scope of this document. 579 ManagedFlag Copied from the Managed field of the most recently 580 received Router Advertisement message. The flag 581 indicates whether or not addresses are to be 582 configured using the stateful autoconfiguration 583 mechanism. It starts out in a FALSE state. 585 OtherConfigFlag Copied from the Other field of the most recently 586 received Router Advertisement message. The flag 587 indicates whether or not information other than 588 addresses are to be obtained using the stateful 589 autoconfiguration mechanism. It starts out in a 590 FALSE state. 592 A host also maintains a list of addresses together with their 593 corresponding lifetimes. The address list contains both autoconfigured 594 addresses and those configured manually. 596 5.3. Creation of Link-Local Addresses 598 A node forms a link-local address whenever an interface becomes enabled. 599 An interface may become enabled after any of the following events: 601 - The interface is initialized at system startup time. 603 - The interface is reinitialized after a temporary interface failure 604 or after being temporarily disabled by system management. 606 - The interface attaches to a link for the first time. 608 - The interface becomes enabled by system management after having 609 been administratively disabled. 611 A link-local address is formed by prepending the well-known link-local 612 prefix FE80::0 [ADDR-ARCH] (of appropriate length) to the interface 613 token. If the interface token has a length of N bits, the interface 614 token replaces the right-most N zero bits of the link-local prefix. If 615 the interface token is more than 118 bits in length, autoconfiguration 616 fails and manual configuration is required. 618 A link-local address has an infinite preferred and valid lifetime; it is 619 never timed out. 621 5.4. Duplicate Address Detection 623 Duplicate Address Detection MUST be performed on unicast addresses prior 624 to assigning them to an interface whose DupAddrDetectTransmits variable 625 is greater than zero. Duplicate Address Detection takes place on all 626 unicast addresses, regardless of whether they are obtained through 627 stateful, stateless or manual configuration. (Duplicate Address 628 Detection MUST NOT be performed on anycast addresses.) Each individual 629 unicast address SHOULD be tested for uniqueness. However, when stateless 630 address autoconfiguration is used, address uniqueness is determined 631 solely by the interface token, assuming that subnet prefixes are 632 assigned correctly (i.e., if all of an interface's addresses are 633 generated from the same token, either all addresses or none of them will 634 be duplicates). Thus, for a set of addresses formed from the same 635 interface token, it is sufficient to check that the link-local address 636 generated from the token is unique on the link. In such cases, the link- 637 local address MUST be tested for uniqueness before any of the other 638 addresses can be assigned to an interface. 640 The procedure for detecting duplicate addresses uses Neighbor 641 Solicitation and Advertisement messages as described below. If a 642 duplicate address is discovered during the procedure, the address cannot 643 be assigned to the interface. If the address is derived from an 644 interface token, a new token will need to be assigned to the interface, 645 or all IP addresses for the interface will need to be manually 646 configured. Note that the method for detecting duplicates is not 647 completely reliable, and it is possible that duplicate addresses will 648 still exist (e.g., if the link was partitioned while Duplicate Address 649 Detection was performed). 651 An address on which the duplicate Address Detection Procedure is applied 652 is said to be tentative until the procedure has completed successfully. 653 A tentative address is not considered "assigned to an interface" in the 654 traditional sense. That is, the interface must accept Neighbor 655 Solicitation and Advertisement messages containing the tentative address 656 in the Target Address field, but processes such packets differently from 657 those whose Target Address matches an address assigned to the interface. 658 Other packets addressed to the tentative address should be silently 659 discarded. 661 It should also be noted that Duplicate Address Detection must be 662 performed prior to assigning an address to an interface in order to 663 prevent multiple nodes from using the same address simultaneously. If a 664 node begins using an address in parallel with Duplicate Address 665 Detection, and another node is already using the address, the node 666 performing Duplicate Address Detection will erroneously process traffic 667 intended for the other node, resulting in such possible negative 668 consequences as the resetting of open TCP connections. 670 The following subsections describe specific tests a node performs to 671 verify an address's uniqueness. An address is considered unique if none 672 of the tests indicate the presence of a duplicate address within 673 RetransTimer milliseconds after having sent DupAddrDetectTransmits 674 Neighbor Solicitations. Once an address is determined to be unique, it 675 may be assigned to an interface. 677 5.4.1. Message Validation 679 A node MUST silently discard any Neighbor Solicitation or Advertisement 680 message that does not pass the validity checks specified in [DISCOVERY]. 681 A solicitation that passes these validity checks is called a valid 682 solicitation or valid advertisement. 684 5.4.2. Sending Neighbor Solicitation Messages 686 Before sending a Neighbor Solicitation, an interface MUST join the all- 687 nodes multicast address and the solicited-node multicast address of the 688 tentative address. The former insures that the node receives Neighbor 689 Advertisements from other nodes already using the address; the latter 690 insures that two nodes attempting to use the same address simultaneously 691 detect each other's presence. 693 To check an address, a node sends DupAddrDetectTransmits Neighbor 694 Solicitations, each separated by RetransTimer milliseconds. The 695 solicitation's Target Address is set to the address being checked, the 696 IP source is set to the unspecified address and the IP destination is 697 set to the solicited-node multicast address of the target address. 699 If the Neighbor Solicitation is the first message to be sent from an 700 interface after interface (re)initialization, the node should delay 701 sending the message by a random delay between 0 and 702 MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY]. This serves to 703 alleviate congestion when many nodes start up on the link at the same 704 time, such as after a power failure, and may help to avoid race 705 conditions when more than one node is trying to solicit for the same 706 address at the same time. In order to improve the robustness of the 707 Duplicate Address Detection algorithm, an interface MUST receive and 708 process datagrams sent to the all-nodes multicast address or solicited- 709 node multicast address of the tentative address while delaying 710 transmission of the initial Neighbor Solicitation. 712 5.4.3. Receiving Neighbor Solicitation Messages 714 On receipt of a valid Neighbor Solicitation message on an interface, 715 node behavior depends on whether the target address is tentative or not. 716 If the target address is not tentative (i.e., it is assigned to the 717 receiving interface), the solicitation is processed in the normal way 718 [DISCOVERY]. If the target address is tentative, and the source address 719 is a unicast address, the solicitation's sender is performing address 720 resolution on the target; the solicitation should be silently ignored. 721 Otherwise, processing takes place as described below. In all cases, a 722 node MUST NOT respond to a Neighbor Solicitation for a tentative 723 address. 725 If the source address of the Neighbor Solicitation is the unspecified 726 address, the solicitation is from a node performing Duplicate Address 727 Detection. If the solicitation is from another node, the tentative 728 address is a duplicate and should not be used (by either node). If the 729 solicitation is from the node itself (because the node loops back 730 multicast packets), the solicitation does not indicate the presence of a 731 duplicate address. 733 Implementor's Note: many interfaces provide a way for upper layers to 734 selectively enable and disable the looping back of multicast packets. 735 The details of how such a facility is implemented may prevent Duplicate 736 Address Detection from working correctly. See the Appendix for further 737 discussion. 739 The following tests identify conditions under which a tentative address 740 is not unique: 742 - If a Neighbor Solicitation for a tentative address is received 743 prior to having sent one, the tentative address is a duplicate. 744 This condition occurs when two nodes run Duplicate Address 745 Detection simultaneously, but transmit initial solicitations at 746 different times (e.g., by selecting different random delay values 747 before transmitting an initial solicitation). 749 - If the actual number of Neighbor Solicitations received exceeds the 750 number expected based on the loopback semantics (e.g., the 751 interface does not loopback packet, yet one or more solicitations 752 was received), the tentative address is a duplicate. This condition 753 occurs when two nodes run Duplicate Address Detection 754 simultaneously and transmit solicitations at roughly the same time. 756 5.4.4. Receiving Neighbor Advertisement Messages 758 On receipt of a valid Neighbor Advertisement message on an interface, 759 node behavior depends on whether the target address is tentative or 760 matches a unicast or anycast address assigned to the interface. If the 761 target address is assigned to the receiving interface, the solicitation 762 is processed in the normal way [DISCOVERY]. If the target address is 763 tentative, the tentative address is not unique. 765 5.4.5. When Duplicate Address Detection Fails 767 A tentative address that is determined to be a duplicate as described 768 above, MUST NOT be assigned to an interface and the node SHOULD log a 769 system management error. If the address is a link-local address formed 770 from an interface token, the interface SHOULD be disabled. 772 5.5. Creation of Global- and Site-Local Addresses 774 Global- and site-local addresses are formed by appending an interface 775 token to a prefix of appropriate length. Prefixes are obtained from 776 Prefix Information options contained in Router Advertisements. Creation 777 of global and site-local addresses and configuration of other parameters 778 as described in this section SHOULD be locally configurable. However, 779 this processing MUST be enabled by default. 781 5.5.1. Soliciting Router Advertisements 783 Router Advertisements are sent periodically to the all-nodes multicast 784 address. To obtain an advertisement quickly, a host sends out Router 785 Solicitations as described in [DISCOVERY]. 787 5.5.2. Absence of Router Advertisements 789 If a link has no routers, a host MUST attempt to use stateful 790 autoconfiguration to obtain addresses and other configuration 791 information. An implementation MAY provide a way to disable the 792 invocation of stateful autoconfiguration in this case, but the default 793 SHOULD be enabled. From the perspective of autoconfiguration, a link 794 has no routers if no Router Advertisements are received after having 795 sent a small number of Router Solicitations as described in [DISCOVERY]. 797 5.5.3. Router Advertisement Processing 799 On receipt of a valid Router Advertisement (as defined in [DISCOVERY]), 800 a host copies the value of the advertisement's Managed bit into 801 ManagedFlag. If the value of ManagedFlag changes from FALSE to TRUE, the 802 host should invoke the stateful address autoconfiguration protocol, 803 requesting address information. If the value of the ManagedFlag changes 804 from TRUE to FALSE, the host should terminate the stateful address 805 autoconfiguration protocol (i.e., stop requesting addresses and ignore 806 subsequent responses to in-progress transactions). If the value of the 807 flag stays unchanged, no special action takes place. In particular, a 808 host MUST NOT reinvoke stateful address configuration if it is already 809 participating in the stateful protocol as a result of an earlier 810 advertisement. 812 An advertisement's Other bit is processed in an analogous manner. A host 813 copies the value of the Other bit into OtherConfigFlag. If the value of 814 OtherConfigFlag changes from FALSE to TRUE, the host should invoke the 815 stateful autoconfiguration protocol, requesting information (excluding 816 addresses). If the value of the OtherConfigFlag changes from TRUE to 817 FALSE, any activity related to stateful autoconfiguration for parameters 818 other than addresses should be halted. If the value of the flag stays 819 unchanged, no special action takes place. In particular, a host MUST NOT 820 reinvoke stateful configuration if it is already participating in the 821 stateful protocol as a result of an earlier advertisement. 823 For each Prefix-Information option in the Router Advertisement: 825 a) If the Autonomous flag is not set, silently ignore the Prefix 826 Information option. 828 b) If the prefix is the link-local prefix, silently ignore the Prefix 829 Information option. 831 c) If the preferred lifetime is greater than the valid lifetime, 832 silently ignore the Prefix Information option. A node MAY wish to 833 log a system management error in this case. 835 d) If the advertised prefix matches the prefix of an autoconfigured 836 address in the list of addresses associated with the interface, set 837 the preferred timer to that of the option's preferred lifetime, and 838 set the valid lifetime to that of the option's valid lifetime. 840 e) If the prefix advertised does not match the prefix of an address 841 already in the list, then form an address (and add it to the list) 842 by appending the interface token to the prefix as follows: 844 | 128 - N bits | N bits | 845 +---------------------------------------+------------------------+ 846 | link prefix | interface token | 847 +----------------------------------------------------------------+ 849 If the sum of the prefix length and interface token length does not 850 equal 128 bits, the Prefix Information option MUST be ignored. An 851 implementation MAY wish to log a system management error in this 852 case. It is the responsibility of the system administrator to insure 853 that the lengths of prefixes contained in Router Advertisements are 854 consistent with the length of interface tokens for that link type. 856 In those cases where a site requires the use of longer prefixes than 857 can be accommodated by the interface token, stateful 858 autoconfiguration can be used. 860 If an address is formed successfully, the host adds it to 861 AddressList, initializing its preferred and valid lifetime values 862 from the Prefix Information option. 864 5.5.4. Address Lifetime Expiry 866 A preferred address becomes deprecated when its preferred lifetime 867 expires. A deprecated address SHOULD continue to be used as a source 868 address in existing communications, but SHOULD NOT be used in new 869 communications if an alternate (non-deprecated) address is available and 870 has sufficient scope. The IP layer MUST continue to accept datagrams 871 destined to a deprecated address since a deprecated address is still a 872 valid address for the interface. An implementation MAY prevent any new 873 communication from using a deprecated address, but system management 874 MUST have the ability to disable such a facility. 876 An address (and its association with an interface) becomes invalid when 877 its valid lifetime expires. An invalid address MUST NOT be used as a 878 source address in outgoing communications and MUST NOT be recognized as 879 a destination on a receiving interface. 881 Note that if a Prefix Information option is received with a preferred 882 lifetime of zero, any addresses generated from that prefix are 883 immediately deprecated. Similarly, if both the advertised deprecated and 884 valid lifetimes are zero, any addresses generated from that prefix 885 become invalid immediately. 887 5.6. Configuration Consistency 889 It is possible for hosts to obtain address information using both 890 stateless and stateful protocols since both may be enabled at the same 891 time. It is also possible that the values of other configuration 892 parameters such as MTU size and hop limit will be learned from both 893 Router Advertisements and the stateful autoconfiguration protocol. If 894 the same configuration information is provided by multiple sources, the 895 value of this information should be consistent. However, it is not 896 considered a fatal error if information received from multiple sources 897 is inconsistent. Hosts accept the union of all information received via 898 the stateless and stateful protocols. If inconsistent information is 899 learned from different sources, the most recently obtained values always 900 have precedence over information learned earlier. 902 OPEN ISSUES/TODO 904 o figure out how to do appendices in nroff 906 o add wording that indicates that addrconf is required to be turned on 907 by default? 909 o Add wording suggesting DAD and waiting for RAs be done in parallel. 911 SECURITY CONSIDERATIONS 913 Stateless address autoconfiguration allows a host to connect to a 914 network, configure an address and start communicating with other nodes 915 without ever registering or authenticating itself with the local site. 916 Although this allows unauthorized users to connect to and use a network, 917 the threat is inherently present in the Internet architecture. Any node 918 with a physical attachment to a network can generate an address (using a 919 variety of ad hoc techniques) that provides connectivity. 921 The use of Duplicate Address Detection opens up the possibility of 922 denial of service attacks. Any node can respond to Neighbor 923 Solicitations for a tentative address, causing the other node to reject 924 the address as a duplicate. This attack is similar to other attacks 925 involving the spoofing of Neighbor Discovery messages and can be 926 addressed by requiring that Neighbor Discovery packets be authenticated 927 [RFC1826]. 929 REFERENCES 931 [RFC1826] 932 R. Atkinson. "IP Authentication Header", RFC 1826, August 1995. 934 [IPv6-ETHER] 935 M. Crawford. "A Method for the Transmission of IPv6 Packets over 936 Ethernet Networks", Internet Draft. 938 [RFC1112] 939 S. Deering, "Host Extensions for IP Multicasting", RFC 1112, 940 August, 1989. 942 [ADDR-ARCH] 943 R. Hinden and S. Deering, "Internet Protocol Version (IPv6) 944 Addressing Architecture", Internet Draft, May 1995, draft-ietf- 945 ipngwg-addr-arch-03.txt 947 [DHCPv6] 948 Internet Draft, Work in Progress. 950 [DISCOVERY] 951 T. Narten, E. Nordmark and W. A. Simpson, "Neighbor Discovery 952 for IP Version 6 (IPv6)", Internet Draft, September 1995, 953 955 Acknowledgements 957 The authors would like to thank the members of both the IPNG and 958 ADDRCONF working groups for their input. In particular, thanks to Jim 959 Bound, Steve Deering, and Erik Nordmark. 961 AUTHORS' ADDRESSES 962 Susan Thomson Thomas Narten 963 Bellcore IBM Corporation 964 445 South Street P.O. Box 12195 965 Morristown, NJ 07960 Research Triangle Park, NC 27709-2195 966 USA USA 968 phone: +1 201-829-4514 phone: +1 919 254 7798 969 email: set@thumper.bellcore.com email: narten@vnet.ibm.com 971 APPENDIX: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION 973 Determining whether a multicast solicitation was looped back to the 974 sender or actually came from another node is implementation-dependent. 975 A problematic case occurs when two interfaces attached to the same link 976 happen to have the same token and link-layer address, and they both send 977 out packets with identical contents at roughly the same time (e.g., 978 Neighbor Solicitations for a tentative address as part of Duplicate 979 Address Detection messages). Although a receiver will receive both 980 packets, it cannot determine which packet was looped back and which 981 packet came from the other node by simply comparing packet contents 982 (i.e., the contents are identical). In this particular case, it is not 983 necessary to know precisely which packet was looped back and which was 984 sent by another node; if one receives more solicitations than were sent, 985 the tentative address is a duplicate. However, the situation may not 986 always be this straightforward. 988 The IPv4 multicast specification [RFC1112] recommends that the service 989 interface provide a way for an upper-layer protocol to inhibit local 990 delivery of packets sent to a multicast group that the sending host is a 991 member of. Some applications know that there will be no other group 992 members on the same host, and suppressing loopback prevents them from 993 having to receive (and discard) the packets they themselves send out. A 994 straightforward way to implement this facility is to disable loopback at 995 the hardware level (if supported by the hardware), with packets looped 996 back (if requested) by software. On interfaces in which the hardware 997 itself suppresses loopbacks, a node running Duplicate Address Detection 998 simply counts the number of Neighbor Solicitations received for a 999 tentative address and compares them with the number expected. If there 1000 is a mismatch, the tentative address is a duplicate. 1002 In those cases where the hardware cannot suppress loopbacks, however, 1003 one possible software heuristic to filter out unwanted loopbacks is to 1004 discard any received packet whose link-layer source address is the same 1005 as the receiving interface's. Unfortunately, use of that criteria also 1006 results in the discarding of all packets sent by another node using the 1007 same link-layer address. Duplicate Address Detection will fail on 1008 interfaces that filter received packets in this manner: 1010 o If a node performing Duplicate Address Detection discards received 1011 packets having the same source link-layer address as the receiving 1012 interface, it will also discard packets from other nodes also using 1013 the same link-layer address, including Neighbor Advertisement and 1014 Neighbor Solicitation messages required to make Duplicate Address 1015 Detection work correctly. This particular problem can be avoided 1016 by temporarily disabling the software suppression of loopbacks 1017 while a node performs Duplicate Address Detection. 1019 o If a node that is already using a particular IP address discards 1020 received packets having the same link-layer source address as the 1021 interface, it will also discard Duplicate Address Detection-related 1022 Neighbor Solicitation messages sent by another node also using the 1023 same link-layer address. Consequently, Duplicate Address Detection 1024 will fail, and the other node will configure a non-unique address. 1025 Since it is generally impossible to know when another node is 1026 performing Duplicate Address Detection, this scenario can be 1027 avoided only if software suppression of loopback is permanently 1028 disabled. 1030 Thus, to perform Duplicate Address Detection correctly in the case where 1031 two interfaces are using the same link-layer address, an implementation 1032 must have a good understanding of the interface's multicast loopback 1033 semantics, and the interface cannot discard received packets simply 1034 because the source link-layer address is the same as the interfaces. 1036 CHANGES SINCE PREVIOUS DOCUMENT 1038 Changes since based on feedback 1039 from the working group: 1041 o minor wordsmithing 1043 o made explicit that DAD could be turned off by system management. 1045 o Fixed references to link-type specific where they had been written 1046 as link-specific. 1048 o clarified DAD should not be performed on anycast addresses 1050 o allow an implementation to provide a switch that disables the use 1051 of deprecated addresses for any new communications. 1053 o Fixed two typos where "deprecation lifetime" was used rather than 1054 "valid lifetime" 1056 o made abstract more accurate 1058 Changes since based on 1059 feedback from the working group: 1061 o modified DAD text re loopback suppression and added appendix 1062 describing how DAD breaks if an interface discards all 1063 received packets having the same source link-layer address as 1064 the receiving interface. Added that DAD must be applied to 1065 link-layer address for stateless. 1067 o Numerous editorial/wordsmithing changes. 1069 o security section added 1071 o loosened requirement that interface be disabled if DAD fails. 1072 Now say address shouldn't be assigned to interface. However, 1073 if address was derived from interface token (e.g., link-layer 1074 address), then interface should be disabled since its 1075 effectively disabled in any case (no autoconfigured addresses 1076 can be formed on this interface.) 1078 o Use term "link-layer address" rather than "hardware address". 1080 o Corrected typo in definition of link-local prefix (E8 -> 1081 FE80). 1083 o Removed AutoConfig variable, left as implementation issue how 1084 user selects what type of autoconfig is desired, though 1085 default is enabled 1087 o Added DupAddrDetectTransmits variable specifying how many 1088 transmissions to perform as part of DAD (defaults to 1, may be 1089 0), and specify that ND's RetransTimer as the retransmit timer 1090 between consecutive NSs. 1092 o defined interface token to be a bit string. 1094 o added text indicating that autoconfiguration only applies to 1095 multicast-capable interfaces. 1097 o changed name of OtherFlag variable to OtherConfigFlag