idnits 2.17.1 draft-ietf-ipngwg-addrconf-v2-00.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. ** There are 148 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 298 has weird spacing: '... as the dest...' == Line 556 has weird spacing: '...e waits after...' == Line 998 has weird spacing: '...ore.com email...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 30, 1997) is 9760 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' ** Obsolete normative reference: RFC 1884 (ref. 'ADDR-ARCH') (Obsoleted by RFC 2373) -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCPv6' ** Obsolete normative reference: RFC 1970 (ref. 'DISCOVERY') (Obsoleted by RFC 2461) Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Susan Thomson, Bellcore 2 July 30, 1997 Thomas Narten, IBM 3 July 30, 1997 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 February 28, 1998. 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............................................. 3 | 54 2. TERMINOLOGY.............................................. 5 | 55 2.1. Requirements........................................ 9 | 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................. 13 | 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............... 19 | 74 5.5.2. Absence of Router Advertisements............... 19 | 75 5.5.3. Router Advertisement Processing................ 19 | 76 5.5.4. Address Lifetime Expiry........................ 21 | 77 5.6. Configuration Consistency........................... 21 | 79 6. SECURITY CONSIDERATIONS.................................. 22 | 81 7. References............................................... 22 | 83 8. Acknowledgements......................................... 23 | 85 9. APPENDIX A: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION 23| 87 10. APPENDIX B: CHANGES SINCE RFC 1971...................... 25 | 89 1. INTRODUCTION 91 This document specifies the steps a host takes in deciding how to 92 autoconfigure its interfaces in IP version 6. The autoconfiguration 93 process includes creating a link-local address and verifying its 94 uniqueness on a link, determining what information should be 95 autoconfigured (addresses, other information, or both), and in the 96 case of addresses, whether they should be obtained through the 97 stateless mechanism, the stateful mechanism, or both. This document 98 defines the process for generating a link-local address, the process 99 for generating site-local and global addresses via stateless address 100 autoconfiguration, and the Duplicate Address Detection procedure. The 101 details of autoconfiguration using the stateful protocol are 102 specified elsewhere. 104 IPv6 defines both a stateful and stateless address autoconfiguration 105 mechanism. Stateless autoconfiguration requires no manual 106 configuration of hosts, minimal (if any) configuration of routers, 107 and no additional servers. The stateless mechanism allows a host to 108 generate its own addresses using a combination of locally available 109 information and information advertised by routers. Routers advertise 110 prefixes that identify the subnet(s) associated with a link, while | 111 hosts generate an "interface identifier" that uniquely identifies an 112 interface on a subnet. An address is formed by combining the two. In 113 the absence of routers, a host can only generate link-local 114 addresses. However, link-local addresses are sufficient for allowing 115 communication among nodes attached to the same link. 117 In the stateful autoconfiguration model, hosts obtain interface 118 addresses and/or configuration information and parameters from a 119 server. Servers maintain a database that keeps track of which 120 addresses have been assigned to which hosts. The stateful 121 autoconfiguration protocol allows hosts to obtain addresses, other 122 configuration information or both from a server. Stateless and 123 stateful autoconfiguration complement each other. For example, a host 124 can use stateless autoconfiguration to configure its own addresses, 125 but use stateful autoconfiguration to obtain other information. 126 Stateful autoconfiguration is described in [DHCPv6]. 128 The stateless approach is used when a site is not particularly 129 concerned with the exact addresses hosts use, so long as they are 130 unique and properly routable. The stateful approach is used when a 131 site requires tighter control over exact address assignments. Both 132 stateful and stateless address autoconfiguration may be used 133 simultaneously. The site administrator specifies which type of 134 autoconfiguration to use through the setting of appropriate fields in 135 Router Advertisement messages [DISCOVERY]. 137 IPv6 addresses are leased to an interface for a fixed (possibly 138 infinite) length of time. Each address has an associated lifetime 139 that indicates how long the address is bound to an interface. When a 140 lifetime expires, the binding (and address) become invalid and the 141 address may be reassigned to another interface elsewhere in the 142 Internet. To handle the expiration of address bindings gracefully, an 143 address goes through two distinct phases while assigned to an 144 interface. Initially, an address is "preferred", meaning that its use 145 in arbitrary communication is unrestricted. Later, an address becomes 146 "deprecated" in anticipation that its current interface binding will 147 become invalid. While in a deprecated state, the use of an address is 148 discouraged, but not strictly forbidden. New communication (e.g., 149 the opening of a new TCP connection) should use a preferred address 150 when possible. A deprecated address should be used only by 151 applications that have been using it and would have difficulty 152 switching to another address without a service disruption. 154 To insure that all configured addresses are likely to be unique on a 155 given link, nodes run a "duplicate address detection" algorithm on 156 addresses before assigning them to an interface. The Duplicate 157 Address Detection algorithm is performed on all addresses, 158 independent of whether they are obtained via stateless or stateful 159 autoconfiguration. This document defines the Duplicate Address 160 Detection algorithm. 162 The autoconfiguration process specified in this document applies only 163 to hosts and not routers. Since host autoconfiguration uses 164 information advertised by routers, routers will need to be configured 165 by some other means. However, it is expected that routers will 166 generate link-local addresses using the mechanism described in this 167 document. In addition, routers are expected to successfully pass the 168 Duplicate Address Detection procedure described in this document on 169 all addresses prior to 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 173 current autoconfiguration procedure. Section 4 provides an overview 174 of the protocol, while Section 5 describes the protocol in detail. 176 2. TERMINOLOGY 178 IP - Internet Protocol Version 6. The terms IPv4 and 179 IPv6 are used only in contexts where necessary to 180 avoid 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 192 OSPF, and internet or lower-layer protocols being 193 "tunneled" over (i.e., encapsulated in) IP such as 194 IPX, AppleTalk, or IP itself. 196 link - a communication facility or medium over which nodes 197 can communicate at the link layer, i.e., the layer 198 immediately below IP. Examples are Ethernets 199 (simple or bridged); PPP links; X.25, Frame Relay, 200 or ATM networks; and internet (or higher) layer 201 "tunnels", such as tunnels over IPv4 or IPv6 itself. 203 interface - a node's attachment to a link. 205 packet - an IP header plus payload. 207 address - an IP-layer identifier for an interface or a set of 208 interfaces. 210 unicast address 211 - an identifier for a single interface. A packet sent 212 to 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 225 interfaces identified by that address (the "nearest" 226 one, 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 237 E.164 addresses for ISDN links. 239 link-local address 240 - an address having link-only scope that can be used 241 to reach neighboring nodes attached to the same 242 link. All interfaces have a link-local unicast 243 address. 245 site-local address 246 - an address having scope that is limited to the local 247 site. 249 global address 250 - an address with unlimited scope. 252 communication 253 - any packet exchange among nodes that requires that 254 the address of each node used in the exchange remain 255 the same for the duration of the packet exchange. 256 Examples are a TCP connection or a UDP request- 257 response. 259 tentative address 260 - an address whose uniqueness on a link is being 261 verified, prior to its assignment to an interface. 262 A tentative address is not considered assigned to an 263 interface in the usual sense. An interface discards 264 received packets addressed to a tentative address, 265 but accepts Neighbor Discovery packets related to 266 Duplicate Address Detection for the tentative 267 address. 269 preferred address 270 - an address assigned to an interface whose use by 271 upper layer protocols is unrestricted. Preferred 272 addresses may be used as the source (or destination) 273 address of packets sent from (or to) the interface. 275 deprecated address 276 - An address assigned to an interface whose use is 277 discouraged, but not forbidden. A deprecated 278 address should no longer be used as a source address | 279 in new communications, but packets sent from or to | 280 deprecated addresses are delivered as expected. A 281 deprecated address may continue to be used as a 282 source address in communications where switching to 283 a preferred address causes hardship to a specific 284 upper-layer activity (e.g., an existing TCP 285 connection). 287 valid address 288 - a preferred or deprecated address. A valid address 289 may appear as the source or destination address of a 290 packet, and the internet routing system is expected | 291 to deliver packets sent to a valid address to their | 292 intended recipients. 294 invalid address 295 - an address that is not assigned to any interface. A 296 valid address becomes invalid when its valid 297 lifetime expires. Invalid addresses should not 298 appear as the destination or source address of a 299 packet. In the former case, the internet routing 300 system will be unable to deliver the packet, in the 301 later case the recipient of the packet will be 302 unable to respond to it. 304 preferred lifetime 305 - the length of time that a valid address is preferred 306 (i.e., the time until deprecation). When the 307 preferred lifetime expires, the address becomes 308 deprecated. 310 valid lifetime 311 - the length of time an address remains in the valid 312 state (i.e., the time until invalidation). The valid 313 lifetime must be greater then or equal to the 314 preferred lifetime. When the valid lifetime 315 expires, the address becomes invalid. 317 interface identifier | 318 - a link-dependent identifier for an interface that is 319 (at least) unique per link [ADDR-ARCH]. Stateless | 320 address autoconfiguration combines an interface | 321 identifier with a prefix to form an address. From | 322 address autoconfiguration's perspective, an | 323 interface identifier is a bit string of known | 324 length. The exact length of an interface identifier | 325 and the way it is created is defined in a separate | 326 link-type specific document that covers issues | 327 related to the transmission of IP over a particular | 328 link type (e.g., [IPv6-ETHER]). In many cases, the | 329 identifier will be the same as the interface's | 330 link-layer address. 332 2.1. Requirements * 334 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, | 335 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this | 336 document, are to be interpreted as described in [KEYWORDS]. 338 3. DESIGN GOALS 340 Stateless autoconfiguration is designed with the following goals in 341 mind: 343 o Manual configuration of individual machines before connecting 344 them to the network should not be required. Consequently, a 345 mechanism is needed that allows a host to obtain or create 346 unique addresses for each of its interfaces. Address 347 autoconfiguration assumes that each interface can provide a 348 unique identifier for that interface (i.e., an "interface | 349 identifier"). In the simplest case, an interface identifier | 350 consists of the interface's link-layer address. An interface | 351 identifier can be combined with a prefix to form an address. 353 o Small sites consisting of a set of machines attached to a single 354 link should not require the presence of a stateful server or 355 router as a prerequisite for communicating. Plug-and-play 356 communication is achieved through the use of link-local 357 addresses. Link-local addresses have a well-known prefix that 358 identifies the (single) shared link to which a set of nodes 359 attach. A host forms a link-local address by appending its | 360 interface identifier to the link-local prefix. 362 o A large site with multiple networks and routers should not 363 require the presence of a stateful address configuration server. 364 In order to generate site-local or global addresses, hosts must 365 determine the prefixes that identify the subnets to which they 366 attach. Routers generate periodic Router Advertisements that 367 include options listing the set of active prefixes on a link. 369 o Address configuration should facilitate the graceful renumbering 370 of a site's machines. For example, a site may wish to renumber 371 all of its nodes when it switches to a new network service 372 provider. Renumbering is achieved through the leasing of 373 addresses to interfaces and the assignment of multiple addresses 374 to the same interface. Lease lifetimes provide the mechanism 375 through which a site phases out old prefixes. The assignment of 376 multiple addresses to an interface provides for a transition 377 period during which both a new address and the one being phased 378 out work simultaneously. 380 o System administrators need the ability to specify whether 381 stateless autoconfiguration, stateful autoconfiguration, or both 382 should be used. Router Advertisements include flags specifying 383 which mechanisms a host should use. 385 4. PROTOCOL OVERVIEW 387 This section provides an overview of the typical steps that take 388 place when an interface autoconfigures itself. Autoconfiguration is 389 performed only on multicast-capable links and begins when a 390 multicast-capable interface is enabled, e.g., during system startup. 391 Nodes (both hosts and routers) begin the autoconfiguration process by 392 generating a link-local address for the interface. A link-local | 393 address is formed by appending the interface's identifier to the 394 well-known link-local prefix. 396 Before the link-local address can be assigned to an interface and 397 used, however, a node must attempt to verify that this "tentative" 398 address is not already in use by another node on the link. 399 Specifically, it sends a Neighbor Solicitation message containing the 400 tentative address as the target. If another node is already using 401 that address, it will return a Neighbor Advertisement saying so. If 402 another node is also attempting to use the same address, it will send 403 a Neighbor Solicitation for the target as well. The exact number of 404 times the Neighbor Solicitation is (re)transmitted and the delay time 405 between consecutive solicitations is link-specific and may be set by 406 system management. 408 If a node determines that its tentative link-local address is not 409 unique, autoconfiguration stops and manual configuration of the 410 interface is required. To simplify recovery in this case, it should 411 be possible for an administrator to supply an alternate interface | 412 identifier that overrides the default identifier in such a way that | 413 the autoconfiguration mechanism can then be applied using the new | 414 (presumably unique) interface identifier. Alternatively, link-local | 415 and other addresses will need to be configured manually. 417 Once a node ascertains that its tentative link-local address is 418 unique, it assigns it to the interface. At this point, the node has 419 IP-level connectivity with neighboring nodes. The remaining 420 autoconfiguration steps are performed only by hosts; the 421 (auto)configuration of routers is beyond the scope of this document. 423 The next phase of autoconfiguration involves obtaining a Router 424 Advertisement or determining that no routers are present. If routers 425 are present, they will send Router Advertisements that specify what 426 sort of autoconfiguration a host should do. If no routers are 427 present, stateful autoconfiguration should be invoked. 429 Routers send Router Advertisements periodically, but the delay 430 between successive advertisements will generally be longer than a 431 host performing autoconfiguration will want to wait [DISCOVERY]. To 432 obtain an advertisement quickly, a host sends one or more Router 433 Solicitations to the all-routers multicast group. Router 434 Advertisements contain two flags indicating what type of stateful 435 autoconfiguration (if any) should be performed. A "managed address 436 configuration" flag indicates whether hosts should use stateful 437 autoconfiguration to obtain addresses. An "other stateful 438 configuration" flag indicates whether hosts should use stateful 439 autoconfiguration to obtain additional information (excluding 440 addresses). 442 Router Advertisements also contain zero or more Prefix Information 443 options that contain information used by stateless address 444 autoconfiguration to generate site-local and global addresses. It 445 should be noted that the stateless and stateful address 446 autoconfiguration fields in Router Advertisements are processed 447 independently of one another, and a host may use both stateful and 448 stateless address autoconfiguration simultaneously. One Prefix 449 Information option field, the "autonomous address-configuration 450 flag", indicates whether or not the option even applies to stateless 451 autoconfiguration. If it does, additional option fields contain a 452 subnet prefix together with lifetime values indicating how long 453 addresses created from the prefix remain preferred and valid. 455 Because routers generate Router Advertisements periodically, hosts 456 will continually receive new advertisements. Hosts process the 457 information contained in each advertisement as described above, 458 adding to and refreshing information received in previous 459 advertisements. 461 For safety, all addresses must be tested for uniqueness prior to 462 their assignment to an interface. In the case of addresses created 463 through stateless autoconfig, however, the uniqueness of an address 464 is determined primarily by the portion of the address formed from an | 465 interface identifier. Thus, if a node has already verified the | 466 uniqueness of a link-local address, additional addresses created from 467 the same interface identifier need not be tested individually. In | 468 contrast, all addresses obtained manually or via stateful address 469 autoconfiguration should be tested for uniqueness individually. To 470 accommodate sites that believe the overhead of performing Duplicate 471 Address Detection outweighs its benefits, the use of Duplicate 472 Address Detection can be disabled through the administrative setting 473 of a per-interface configuration flag. 475 To speed the autoconfiguration process, a host may generate its 476 link-local address (and verify its uniqueness) in parallel with 477 waiting for a Router Advertisement. Because a router may delay 478 responding to a Router Solicitation for a few seconds, the total time 479 needed to complete autoconfiguration can be significantly longer if 480 the two steps are done serially. 482 4.1. Site Renumbering 484 Address leasing facilitates site renumbering by providing a mechanism 485 to time-out addresses assigned to interfaces in hosts. At present, 486 upper layer protocols such as TCP provide no support for changing 487 end-point addresses while a connection is open. If an end-point 488 address becomes invalid, existing connections break and all 489 communication to the invalid address fails. Even when applications 490 use UDP as a transport protocol, addresses must generally remain the 491 same during a packet exchange. 493 Dividing valid addresses into preferred and deprecated categories 494 provides a way of indicating to upper layers that a valid address may 495 become invalid shortly and that future communication using the 496 address will fail, should the address's valid lifetime expire before 497 communication ends. To avoid this scenario, higher layers should use 498 a preferred address (assuming one of sufficient scope exists) to 499 increase the likelihood that an address will remain valid for the 500 duration of the communication. It is up to system administrators to 501 set appropriate prefix lifetimes in order to minimize the impact of 502 failed communication when renumbering takes place. The deprecation 503 period should be long enough that most, if not all, communications 504 are using the new address at the time an address becomes invalid. 506 The IP layer is expected to provide a means for upper layers 507 (including applications) to select the most appropriate source 508 address given a particular destination and possibly other 509 constraints. An application may choose to select the source address 510 itself before starting a new communication or may leave the address 511 unspecified, in which case the upper networking layers will use the 512 mechanism provided by the IP layer to choose a suitable address on 513 the application's behalf. 515 Detailed address selection rules are beyond the scope of this 516 document. 518 5. PROTOCOL SPECIFICATION 520 Autoconfiguration is performed on a per-interface basis on 521 multicast-capable interfaces. For multihomed hosts, 522 autoconfiguration is performed independently on each interface. 523 Autoconfiguration applies primarily to hosts, with two exceptions. 524 Routers are expected to generate a link-local address using the 525 procedure outlined below. In addition, routers perform Duplicate 526 Address Detection on all addresses prior to assigning them to an 527 interface. 529 5.1. Node Configuration Variables 531 A node MUST allow the following autoconfiguration-related variable to 532 be configured by system management 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-type 545 specific value in the document that covers issues 546 related to the transmission of IP over a 547 particular link type (e.g., [IPv6-ETHER]). 549 Autoconfiguration also assumes the presence of 550 the variable RetransTimer as defined in 551 [DISCOVERY]. For autoconfiguration purposes, 552 RetransTimer specifies the delay between 553 consecutive Neighbor Solicitation transmissions 554 performed during Duplicate Address Detection (if 555 DupAddrDetectTransmits is greater than 1), as 556 well as the time a node waits after sending the 557 last Neighbor Solicitation before ending the 558 Duplicate Address Detection process. 560 5.2. Autoconfiguration-Related Variables 562 A host maintains a number of data structures and flags related to 563 autoconfiguration. In the following, we present conceptual variables 564 and show how they are used to perform autoconfiguration. The specific 565 variables are used for demonstration purposes only, and an 566 implementation is not required to have them, so long as its external 567 behavior is consistent with that described in this document. 569 Beyond the formation of a link-local address and using Duplicate 570 Address Detection, how routers (auto)configure their interfaces is 571 beyond the scope of this document. 573 Hosts maintain the following variables on a per-interface basis: 575 ManagedFlag Copied from the M flag field (i.e., the "managed 576 address configuration" flag) of the most recently 577 received Router Advertisement message. The flag 578 indicates whether or not addresses are to be 579 configured using the stateful autoconfiguration 580 mechanism. It starts out in a FALSE state. 582 OtherConfigFlag Copied from the O flag field (i.e., the "other 583 stateful configuration" flag) of the most 584 recently received Router Advertisement message. 585 The flag indicates whether or not information 586 other than addresses are to be obtained using the 587 stateful autoconfiguration mechanism. It starts 588 out in a FALSE state. 590 A host also maintains a list of addresses together with their 591 corresponding lifetimes. The address list contains both 592 autoconfigured addresses and those configured manually. 594 5.3. Creation of Link-Local Addresses 596 A node forms a link-local address whenever an interface becomes 597 enabled. An interface may become enabled after any of the following 598 events: 600 - The interface is initialized at system startup time. 602 - The interface is reinitialized after a temporary interface 603 failure or after being temporarily disabled by system 604 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- 612 local prefix FE80::0 [ADDR-ARCH] (of appropriate length) to the 613 interface identifier. If the interface identifier has a length of N | 614 bits, the interface identifier replaces the right-most N zero bits of | 615 the link-local prefix. If the interface identifier is more than 118 | 616 bits in length, autoconfiguration fails and manual configuration is 617 required. 619 A link-local address has an infinite preferred and valid lifetime; it 620 is never timed out. 622 5.4. Duplicate Address Detection 624 Duplicate Address Detection is performed on unicast addresses prior | 625 to assigning them to an interface whose DupAddrDetectTransmits | 626 variable is greater than zero. Duplicate Address Detection MUST take | 627 place on on all unicast addresses, regardless of whether they are 628 obtained through stateful, stateless or manual configuration, with | 629 the exception of the following cases: | 630 - Duplicate Address Detection MUST NOT be performed on anycast | 631 addresses. | 632 - Each individual unicast address SHOULD be tested for uniqueness. | 633 However, when stateless address autoconfiguration is used, | 634 address uniqueness is determined solely by the interface | 635 identifier, assuming that subnet prefixes are assigned correctly | 636 (i.e., if all of an interface's addresses are generated from the | 637 same identifier, either all addresses or none of them will be | 638 duplicates). Thus, for a set of addresses formed from the same | 639 interface identifier, it is sufficient to check that the link- | 640 local address generated from the identifier is unique on the | 641 link. In such cases, the link-local address MUST be tested for | 642 uniqueness, and if no duplicate address is detected, an | 643 implementation MAY choose to skip Duplicate Address Detection | 644 for additional addresses derived from the same interface | 645 identifier. | 647 The procedure for detecting duplicate addresses uses Neighbor 648 Solicitation and Advertisement messages as described below. If a 649 duplicate address is discovered during the procedure, the address 650 cannot be assigned to the interface. If the address is derived from 651 an interface identifier, a new identifier will need to be assigned to | 652 the interface, or all IP addresses for the interface will need to be 653 manually configured. Note that the method for detecting duplicates 654 is not completely reliable, and it is possible that duplicate 655 addresses will still exist (e.g., if the link was partitioned while 656 Duplicate Address Detection was performed). 658 An address on which the duplicate Address Detection Procedure is 659 applied is said to be tentative until the procedure has completed 660 successfully. A tentative address is not considered "assigned to an 661 interface" in the traditional sense. That is, the interface must 662 accept Neighbor Solicitation and Advertisement messages containing 663 the tentative address in the Target Address field, but processes such 664 packets differently from those whose Target Address matches an 665 address assigned to the interface. Other packets addressed to the 666 tentative address should be silently discarded. 668 It should also be noted that Duplicate Address Detection must be 669 performed prior to assigning an address to an interface in order to 670 prevent multiple nodes from using the same address simultaneously. 671 If a node begins using an address in parallel with Duplicate Address 672 Detection, and another node is already using the address, the node 673 performing Duplicate Address Detection will erroneously process 674 traffic intended for the other node, resulting in such possible 675 negative consequences as the resetting of open TCP connections. 677 The following subsections describe specific tests a node performs to 678 verify an address's uniqueness. An address is considered unique if 679 none of the tests indicate the presence of a duplicate address within 680 RetransTimer milliseconds after having sent DupAddrDetectTransmits 681 Neighbor Solicitations. Once an address is determined to be unique, 682 it may be assigned to an interface. 684 5.4.1. Message Validation 686 A node MUST silently discard any Neighbor Solicitation or 687 Advertisement message that does not pass the validity checks 688 specified in [DISCOVERY]. A solicitation that passes these validity 689 checks is called a valid solicitation or valid advertisement. 691 5.4.2. Sending Neighbor Solicitation Messages 693 Before sending a Neighbor Solicitation, an interface MUST join the 694 all-nodes multicast address and the solicited-node multicast address 695 of the tentative address. The former insures that the node receives 696 Neighbor Advertisements from other nodes already using the address; 697 the latter insures that two nodes attempting to use the same address 698 simultaneously detect each other's presence. 700 To check an address, a node sends DupAddrDetectTransmits Neighbor 701 Solicitations, each separated by RetransTimer milliseconds. The 702 solicitation's Target Address is set to the address being checked, 703 the IP source is set to the unspecified address and the IP 704 destination is set to the solicited-node multicast address of the 705 target address. 707 If the Neighbor Solicitation is the first message to be sent from an 708 interface after interface (re)initialization, the node should delay 709 sending the message by a random delay between 0 and 710 MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY]. This serves 711 to alleviate congestion when many nodes start up on the link at the 712 same time, such as after a power failure, and may help to avoid race 713 conditions when more than one node is trying to solicit for the same 714 address at the same time. In order to improve the robustness of the 715 Duplicate Address Detection algorithm, an interface MUST receive and 716 process datagrams sent to the all-nodes multicast address or 717 solicited-node multicast address of the tentative address while 718 delaying transmission of the initial Neighbor Solicitation. 720 5.4.3. Receiving Neighbor Solicitation Messages 722 On receipt of a valid Neighbor Solicitation message on an interface, 723 node behavior depends on whether the target address is tentative or 724 not. If the target address is not tentative (i.e., it is assigned to 725 the receiving interface), the solicitation is processed as described 726 in [DISCOVERY]. If the target address is tentative, and the source 727 address is a unicast address, the solicitation's sender is performing 728 address resolution on the target; the solicitation should be silently 729 ignored. Otherwise, processing takes place as described below. In 730 all cases, a node MUST NOT respond to a Neighbor Solicitation for a 731 tentative address. 733 If the source address of the Neighbor Solicitation is the unspecified 734 address, the solicitation is from a node performing Duplicate Address 735 Detection. If the solicitation is from another node, the tentative 736 address is a duplicate and should not be used (by either node). If 737 the solicitation is from the node itself (because the node loops back 738 multicast packets), the solicitation does not indicate the presence 739 of a duplicate address. 741 Implementor's Note: many interfaces provide a way for upper layers to 742 selectively enable and disable the looping back of multicast packets. 743 The details of how such a facility is implemented may prevent 744 Duplicate Address Detection from working correctly. See the Appendix 745 for further discussion. 747 The following tests identify conditions under which a tentative 748 address is not unique: 750 - If a Neighbor Solicitation for a tentative address is received 751 prior to having sent one, the tentative address is a duplicate. 752 This condition occurs when two nodes run Duplicate Address 753 Detection simultaneously, but transmit initial solicitations at 754 different times (e.g., by selecting different random delay 755 values before transmitting an initial solicitation). 757 - If the actual number of Neighbor Solicitations received exceeds 758 the number expected based on the loopback semantics (e.g., the 759 interface does not loopback packet, yet one or more 760 solicitations was received), the tentative address is a 761 duplicate. This condition occurs when two nodes run Duplicate 762 Address Detection simultaneously and transmit solicitations at 763 roughly the same time. 765 5.4.4. Receiving Neighbor Advertisement Messages 767 On receipt of a valid Neighbor Advertisement message on an interface, 768 node behavior depends on whether the target address is tentative or 769 matches a unicast or anycast address assigned to the interface. If 770 the target address is assigned to the receiving interface, the 771 solicitation is processed as described in [DISCOVERY]. If the target 772 address is tentative, the tentative address is not unique. 774 5.4.5. When Duplicate Address Detection Fails 776 A tentative address that is determined to be a duplicate as described 777 above, MUST NOT be assigned to an interface and the node SHOULD log a 778 system management error. If the address is a link-local address | 779 formed from an interface identifier, the interface SHOULD be | 780 disabled. 782 5.5. Creation of Global and Site-Local Addresses 784 Global and site-local addresses are formed by appending an interface | 785 identifier to a prefix of appropriate length. Prefixes are obtained | 786 from Prefix Information options contained in Router Advertisements. 787 Creation of global and site-local addresses and configuration of 788 other parameters as described in this section SHOULD be locally 789 configurable. However, the processing described below MUST be enabled 790 by default. 792 5.5.1. Soliciting Router Advertisements 794 Router Advertisements are sent periodically to the all-nodes 795 multicast address. To obtain an advertisement quickly, a host sends 796 out Router Solicitations as described in [DISCOVERY]. 798 5.5.2. Absence of Router Advertisements 800 If a link has no routers, a host MUST attempt to use stateful 801 autoconfiguration to obtain addresses and other configuration 802 information. An implementation MAY provide a way to disable the 803 invocation of stateful autoconfiguration in this case, but the 804 default SHOULD be enabled. From the perspective of 805 autoconfiguration, a link has no routers if no Router Advertisements 806 are received after having sent a small number of Router Solicitations 807 as described in [DISCOVERY]. 809 5.5.3. Router Advertisement Processing 811 On receipt of a valid Router Advertisement (as defined in 812 [DISCOVERY]), a host copies the value of the advertisement's M bit 813 into ManagedFlag. If the value of ManagedFlag changes from FALSE to 814 TRUE, the host should invoke the stateful address autoconfiguration 815 protocol, requesting address information. If the value of the 816 ManagedFlag changes from TRUE to FALSE, the host should terminate the 817 stateful address autoconfiguration protocol (i.e., stop requesting 818 addresses and ignore subsequent responses to in-progress 819 transactions). If the value of the flag stays unchanged, no special 820 action takes place. In particular, a host MUST NOT reinvoke stateful 821 address configuration if it is already participating in the stateful 822 protocol as a result of an earlier advertisement. 824 An advertisement's O flag field is processed in an analogous manner. 825 A host copies the value of the O flag into OtherConfigFlag. If the 826 value of OtherConfigFlag changes from FALSE to TRUE, the host should 827 invoke the stateful autoconfiguration protocol, requesting 828 information (excluding addresses). If the value of the 829 OtherConfigFlag changes from TRUE to FALSE, any activity related to 830 stateful autoconfiguration for parameters other than addresses should 831 be halted. If the value of the flag stays unchanged, no special 832 action takes place. In particular, a host MUST NOT reinvoke stateful 833 configuration if it is already participating in the stateful protocol 834 as a result of an earlier advertisement. 836 For each Prefix-Information option in the Router Advertisement: 838 a) If the Autonomous flag is not set, silently ignore the Prefix 839 Information option. 841 b) If the prefix is the link-local prefix, silently ignore the 842 Prefix Information option. 844 c) If the preferred lifetime is greater than the valid lifetime, 845 silently ignore the Prefix Information option. A node MAY wish to 846 log a system management error in this case. 848 d) If the prefix advertised matches the prefix of an autoconfigured | 849 address (i.e., one obtained previously via stateless or stateful | 850 autoconfiguration) in the list of addresses associated with the | 851 interface, and the valid lifetime in the received RA is both less | 852 than 2 hours and less than the remaining valid Lifetime in the | 853 cached entry, ignore the Prefix Information option for the | 854 purpose of stateless address autoconfiguration. | 856 f) If the prefix advertised matches the prefix of an autoconfigured | 857 address (i.e., one obtained previously via stateless or stateful | 858 autoconfiguration) in the list of addresses associated with the | 859 interface, and the preferred lifetime in the received RA is both | 860 less than 2 hours and less than the remaining preferred Lifetime | 861 in the cached entry, ignore the Prefix Information option for the | 862 purpose of stateless address autoconfiguration. | 864 g) If the advertised prefix matches the prefix of an autoconfigured 865 address (i.e., obtained via stateless or stateful address 866 autoconfiguration) in the list of addresses associated with the 867 interface, set the preferred timer to that of the option's 868 preferred lifetime, and set the valid lifetime to that of the 869 option's valid lifetime. 871 h) If the prefix advertised does not match the prefix of an address | 872 already in the list, then form an address (and add it to the 873 list) by appending the interface identifier to the prefix as | 874 follows: 876 | 128 - N bits | N bits | 877 +---------------------------------------+------------------------+ 878 | link prefix | interface identifier | | 879 +----------------------------------------------------------------+ 881 If the sum of the prefix length and interface identifier length | 882 does not equal 128 bits, the Prefix Information option MUST be 883 ignored. An implementation MAY wish to log a system management 884 error in this case. It is the responsibility of the system 885 administrator to insure that the lengths of prefixes contained in 886 Router Advertisements are consistent with the length of interface | 887 identifiers for that link type. 889 In those cases where a site requires the use of longer prefixes 890 than can be accommodated by the interface identifier, stateful | 891 autoconfiguration can be used. | 893 If an address is formed successfully, the host adds it to the 894 list of addresses assigned to the interface, initializing its 895 preferred and valid lifetime values from the Prefix Information 896 option. 898 5.5.4. Address Lifetime Expiry 900 A preferred address becomes deprecated when its preferred lifetime 901 expires. A deprecated address SHOULD continue to be used as a source 902 address in existing communications, but SHOULD NOT be used in new 903 communications if an alternate (non-deprecated) address is available | 904 and has sufficient scope. IP and higher layers (e.g., TCP, UDP) MUST | 905 continue to accept datagrams destined to a deprecated address since a 906 deprecated address is still a valid address for the interface. An 907 implementation MAY prevent any new communication from using a 908 deprecated address, but system management MUST have the ability to | 909 disable such a facility, and the facility MUST be disabled by | 910 default. 912 An address (and its association with an interface) becomes invalid 913 when its valid lifetime expires. An invalid address MUST NOT be used 914 as a source address in outgoing communications and MUST NOT be 915 recognized as a destination on a receiving interface. 917 Note that if a Prefix Information option is received with a preferred 918 lifetime of zero, any addresses generated from that prefix are 919 immediately deprecated. Similarly, if both the advertised deprecated 920 and valid lifetimes are zero, any addresses generated from that 921 prefix become invalid immediately. 923 5.6. Configuration Consistency 925 It is possible for hosts to obtain address information using both 926 stateless and stateful protocols since both may be enabled at the 927 same time. It is also possible that the values of other 928 configuration parameters such as MTU size and hop limit will be 929 learned from both Router Advertisements and the stateful 930 autoconfiguration protocol. If the same configuration information is 931 provided by multiple sources, the value of this information should be 932 consistent. However, it is not considered a fatal error if 933 information received from multiple sources is inconsistent. Hosts 934 accept the union of all information received via the stateless and 935 stateful protocols. If inconsistent information is learned from 936 different sources, the most recently obtained values always have 937 precedence over information learned earlier. 939 6. SECURITY CONSIDERATIONS 941 Stateless address autoconfiguration allows a host to connect to a 942 network, configure an address and start communicating with other 943 nodes without ever registering or authenticating itself with the 944 local site. Although this allows unauthorized users to connect to and 945 use a network, the threat is inherently present in the Internet 946 architecture. Any node with a physical attachment to a network can 947 generate an address (using a variety of ad hoc techniques) that 948 provides connectivity. 950 The use of Duplicate Address Detection opens up the possibility of 951 denial of service attacks. Any node can respond to Neighbor 952 Solicitations for a tentative address, causing the other node to 953 reject the address as a duplicate. This attack is similar to other 954 attacks involving the spoofing of Neighbor Discovery messages and can 955 be addressed by requiring that Neighbor Discovery packets be 956 authenticated [RFC1826]. 958 7. References 960 [RFC1826] R. Atkinson. "IP Authentication Header", RFC 1826, August | 961 1995. 963 [IPv6-ETHER] M. Crawford. "A Method for the Transmission of IPv6 964 Packets over Ethernet Networks", Internet Draft. 966 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate | 967 Requirement Levels", RFC 2119, March 1997. | 969 [RFC1112] S. Deering, "Host Extensions for IP Multicasting", RFC 970 1112, August, 1989. 972 [ADDR-ARCH] Hinden, R., and S. Deering, "Internet Protocol Version | 973 (IPv6) Addressing Architecture", RFC 1884, December 1995. 975 [DHCPv6] Internet Draft, Work in Progress. 977 [DISCOVERY] Narten, T., Nordmark, E., and W. Simpson, "Neighbor | 978 Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996. | 980 8. Acknowledgements 982 The authors would like to thank the members of both the IPNG and | 983 ADDRCONF working groups for their input. In particular, thanks to Jim | 984 Bound, Steve Deering, and Erik Nordmark. In addition, thanks goes to | 985 John Gilmore for alerting the WG of the "0 Lifetime Prefix | 986 Advertisement" denial of service attack vulnerability; this document | 987 incorporates changes that address this vulnerability. 989 AUTHORS' ADDRESSES 991 Susan Thomson Thomas Narten 992 Bellcore IBM Corporation 993 445 South Street P.O. Box 12195 994 Morristown, NJ 07960 Research Triangle Park, NC 27709-2195 995 USA USA 997 phone: +1 201-829-4514 phone: +1 919 254 7798 998 email: set@thumper.bellcore.com email: narten@raleigh.ibm.com | 1000 9. APPENDIX A: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION | 1002 Determining whether a received multicast solicitation was looped back 1003 to the sender or actually came from another node is implementation- 1004 dependent. A problematic case occurs when two interfaces attached to 1005 the same link happen to have the same identifier and link-layer | 1006 address, and they both send out packets with identical contents at 1007 roughly the same time (e.g., Neighbor Solicitations for a tentative 1008 address as part of Duplicate Address Detection messages). Although a 1009 receiver will receive both packets, it cannot determine which packet 1010 was looped back and which packet came from the other node by simply 1011 comparing packet contents (i.e., the contents are identical). In this 1012 particular case, it is not necessary to know precisely which packet 1013 was looped back and which was sent by another node; if one receives 1014 more solicitations than were sent, the tentative address is a 1015 duplicate. However, the situation may not always be this 1016 straightforward. 1018 The IPv4 multicast specification [RFC1112] recommends that the 1019 service interface provide a way for an upper-layer protocol to 1020 inhibit local delivery of packets sent to a multicast group that the 1021 sending host is a member of. Some applications know that there will 1022 be no other group members on the same host, and suppressing loopback 1023 prevents them from having to receive (and discard) the packets they 1024 themselves send out. A straightforward way to implement this 1025 facility is to disable loopback at the hardware level (if supported 1026 by the hardware), with packets looped back (if requested) by 1027 software. On interfaces in which the hardware itself suppresses 1028 loopbacks, a node running Duplicate Address Detection simply counts 1029 the number of Neighbor Solicitations received for a tentative address 1030 and compares them with the number expected. If there is a mismatch, 1031 the tentative address is a duplicate. 1033 In those cases where the hardware cannot suppress loopbacks, however, 1034 one possible software heuristic to filter out unwanted loopbacks is 1035 to discard any received packet whose link-layer source address is the 1036 same as the receiving interface's. Unfortunately, use of that 1037 criteria also results in the discarding of all packets sent by 1038 another node using the same link-layer address. Duplicate Address 1039 Detection will fail on interfaces that filter received packets in 1040 this manner: 1042 o If a node performing Duplicate Address Detection discards 1043 received packets having the same source link-layer address as 1044 the receiving interface, it will also discard packets from other 1045 nodes also using the same link-layer address, including Neighbor 1046 Advertisement and Neighbor Solicitation messages required to 1047 make Duplicate Address Detection work correctly. This 1048 particular problem can be avoided by temporarily disabling the 1049 software suppression of loopbacks while a node performs 1050 Duplicate Address Detection. 1052 o If a node that is already using a particular IP address discards 1053 received packets having the same link-layer source address as 1054 the interface, it will also discard Duplicate Address 1055 Detection-related Neighbor Solicitation messages sent by another 1056 node also using the same link-layer address. Consequently, 1057 Duplicate Address Detection will fail, and the other node will 1058 configure a non-unique address. Since it is generally impossible 1059 to know when another node is performing Duplicate Address 1060 Detection, this scenario can be avoided only if software 1061 suppression of loopback is permanently disabled. 1063 Thus, to perform Duplicate Address Detection correctly in the case 1064 where two interfaces are using the same link-layer address, an 1065 implementation must have a good understanding of the interface's 1066 multicast loopback semantics, and the interface cannot discard 1067 received packets simply because the source link-layer address is the 1068 same as the interfaces. | 1070 10. APPENDIX B: CHANGES SINCE RFC 1971 | 1072 The following changes, which are also marked with change bars ('|' or | 1073 '*') in the right margin, have been made since RFC 1970: | 1075 o Changed document to use term "interface identifer" rather than | 1076 "interface token" for consistency with other IPv6 documents. | 1078 o Clarified definition of deprecated address to make clear it is OK | 1079 to continue sending to or from deprecated addresses. | 1081 o Reworded section 5.4 for clarity (no substantive change). | 1083 o Added rules to Section 5.5.3 Router Advertisement processing to | 1084 address potential denial-of-service attack when prefixes are | 1085 advertised with very short Lifetimes. | 1087 o Clarified wording in Section 5.5.4 to make clear that all upper | 1088 layer protocols must process (i.e., send and receive) packets sent | 1089 to deprecated addresses. |