idnits 2.17.1 draft-ietf-addrconf-ipv6-auto-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 216: '... MUST...' RFC 2119 keyword, line 220: '... MUST NOT...' RFC 2119 keyword, line 224: '... SHOULD...' RFC 2119 keyword, line 230: '... SHOULD NOT...' RFC 2119 keyword, line 237: '... MAY...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 49 has weird spacing: '...list of addre...' == Line 345 has weird spacing: '... is never d...' == Line 498 has weird spacing: '...ifetime and t...' == Line 531 has weird spacing: '...be used as a...' == Line 710 has weird spacing: '...address with ...' -- 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 7, 1995) is 10521 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) ** Downref: Normative reference to an Historic draft: draft-ietf-ipngwg-addr-arch (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADDRCONF Working Group Susan Thomson (Bellcore) 3 INTERNET-DRAFT July 7, 1995 4 6 IPv6 Stateless Address Autoconfiguration 8 Status of this Memo 10 This document is a submission to the ADDRCONF Working Group of the 11 Internet Engineering Task Force (IETF). Comments should be submitted 12 to the addrconf@cisco.com mailing list. 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a "working 23 draft" or "work in progress." 25 To learn the current status of any Internet Draft. please check the 26 1id-abstracts.txt listing contained in the Internet Drafts Shadow 27 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com or 28 munnari.oz.au. 30 Abstract 32 This document specifies how a node configures a link-local address 33 per interface, and how a host configures a list of global or site- 34 local addresses per interface, without any manual configuration. 35 Stateless address autoconfiguration is only one mechanism available 36 to hosts; stateful address configuration is also available. While 37 stateful address configuration is outside the scope of this document, 38 it is specified how hosts determine which configuration method must 39 be used. The document also specifies a protocol for detecting 40 whether an address is a duplicate when it is initially configured. 42 1. INTRODUCTION 44 In IPv6, a host has two mechanisms available to form a global or 45 site-local address that require no manual configuration: the state- 46 less method and the stateful method. In the stateless method, no 47 external state is maintained for the purpose of indicating to a host 48 the list of addresses to use for an interface. Rather, a host forms a 49 list of addresses algorithmically by concatenating each of the net- 50 work prefixes of the attached link to an interface token unique per 51 link. The interface token is defined to be link-dependent and may be 52 the hardware address, for example. In contrast, state is maintained 53 in the stateful address configuration, typically in a server. For 54 example, the IPv6 Dynamic Host Configuration Protocol is an example 55 of stateful address autoconfiguration. 57 Stateless autoconfiguration is designed to make address configuration 58 very simple to use and implement, and is suitable for environments 59 with simple topologies, e.g. routerless networks, and for environ- 60 ments where system administrative control is not desired, e.g. plug- 61 and-play environments. In contrast, stateful address configuration 62 is designed to support flexible address assignment and is suitable 63 for more sophisticated topologies and for environments where system 64 administrative control is desired, e.g. corporate networks. 66 Any node can use stateless address autoconfiguration to form a link- 67 local address per interface. A host can use either stateless or 68 stateful autoconfiguration (or both) to configure global or site- 69 local addresses for an interface. The choice of mechanism for confi- 70 guring global or site-local addresses is itself configurable, and 71 requires no manual configuration per host. 73 One of the basic assumptions of stateless autoconfiguration is that 74 the token used to form addresses per interface is at least unique per 75 link. However, whatever the type of tokens used, interface tokens are 76 not guaranteed to always be unique in practice because of errors in 77 assignment. Thus, it is possible that IPv6 addresses formed using 78 stateless autoconfiguration are not unique among all nodes on a link. 79 Since duplicate IPv6 addresses are very difficult to track down when 80 they occur, this document also specifies a procedure for detecting 81 duplicate addresses. Note that the algorithm does not only apply to 82 addresses autoconfigured using the stateless mode. It should be used 83 to verify the uniqueness of any address, for example, addresses con- 84 figured using the stateful mode or manually configured addresses. 86 This document describes how a node configures a link-local address 87 per interface using stateless address autoconfiguration, and how a 88 host configures global or site-local unicast addresses per interface 89 using stateless address autoconfiguration. Stateful address autocon- 90 figuration is outside the scope of this document. However, the docu- 91 ment does specify how a host determines whether to use the stateless 92 mechanism or the stateful mechanism for configuring global or site- 93 local addresses. 95 The document also describes the algorithm used by a node to detect if 96 an address is a duplicate when initially configured. 98 2. TERMINOLOGY 100 node - a device that implements IPv6. 102 router - a node that forwards IPv6 packets not explicitly 103 addressed to itself. 105 host - any node that is not a router. 107 upper layer - a protocol layer immediately above IPv6. Examples are 108 transport protocols such as TCP and UDP, control 109 protocols such as ICMP, routing protocols such as OSPF, 110 and internet or lower-layer protocols being "tunneled" 111 over (i.e., encapsulated in) IPv6 such as IPX, 112 AppleTalk, or IPv6 itself. 114 link - a communication facility or medium over which nodes can 115 communicate at the link layer, i.e., the layer 116 immediately below IPv6. Examples are Ethernets (simple 117 or bridged); PPP links; X.25, Frame Relay, or ATM 118 networks; and internet (or higher) layer "tunnels", 119 such as tunnels over IPv4 or IPv6 itself. 121 neighbors - nodes attached to the same link. 123 interface - a node's attachment to a link. 125 packet - an IPv6 header plus payload. 127 link MTU - the maximum transmission unit, i.e., maximum packet 128 size in octets, that can be conveyed in one piece over 129 a link. 131 target - a node about which address resolution information is 132 sought, or a node which is the new first-hop when being 133 redirected. 135 address - an IPv6-layer identifier for an interface or a set of 136 interfaces. 138 unicast address 139 - an identifier for a single interface. A packet sent 140 to a unicast address is delivered to the interface 141 identified by that address. 143 anycast address 144 - an identifier for a set of interfaces (typically 145 belonging to different nodes). A packet sent to an 146 anycast address is delivered to one of the interfaces 147 identified by that address (the "nearest" one, 148 according to the routing protocols' measure of 149 distance). 151 multicast address 152 - an identifier for a set of interfaces (typically 153 belonging to different nodes). A packet sent to a 154 multicast address is delivered to all interfaces 155 identified by that address. 157 link-layer address 158 - a link-layer identifier for an interface. Examples are 159 IEEE 802 addresses for Ethernet links, E.164 addresses 160 for ISDN links. 162 link-local address 163 - an address with a scope that is limited to 164 the locally attached link. 166 site-local address 167 - an address with a scope that is limited to the 168 local site. 170 global address 171 - an address with unlimited scope. 173 communication 174 - any packet exchange between nodes that requires 175 or recommends that the address of each node used in the 176 exchange remain the same for the duration of the 177 packet exchange. Examples are a TCP connection or a 178 UDP request-response. 180 deprecation lifetime 181 - indicates the time at which an address should no 182 longer be used as a source address in new 183 communications. The deprecation lifetime must be 184 less than or equal to the invalidation lifetime 185 of the address. 187 invalidation lifetime 188 - indicates the time at which an address no longer 189 identifies an interface or set of interfaces. 190 The invalidation lifetime must be greater than 191 or equal to the deprecation lifetime of the address. 193 valid address 194 - an address whose deprecation lifetime has not yet 195 expired. 197 deprecated address 198 - an address whose deprecation lifetime has expired, 199 but whose invalidation lifetime has not. 201 invalid address 202 - an address whose invalidation lifetime has 203 expired. 205 interface token 206 - a link-dependent identifier for an interface that is 207 (at least) unique per link. An example is an IEEE 802 208 address. 210 2.1. Requirements 212 Throughout this document, the words that are used to define the sig- 213 nificance of the particular requirements are capitalized. These 214 words are: 216 MUST 217 This word or the adjective "REQUIRED" means that the item is an 218 absolute requirement of this specification. 220 MUST NOT 221 This phrase means the item is an absolute prohibition of this 222 specification. 224 SHOULD 225 This word or the adjective "RECOMMENDED" means that there may 226 exist valid reasons in particular circumstances to ignore this 227 item, but the full impliciations should be understood and the 228 case carefully weighed before choosing a different course. 230 SHOULD NOT 231 This phrase means that there may exist valid reasons in particu- 232 lar circumstances when the listed behavior is acceptable or even 233 useful, but the full implications should be understood and the 234 case carefully weighted before implementing any behavior 235 described with this label. 237 MAY 238 This word or the adjective "OPTIONAL" means that this item is 239 truly optional. One vendor may choose to include the item 240 because a particular marketplace requires it or because it 241 enhances the product, for example, another vendor may omit the 242 same item. 244 3. CONCEPTUAL MODEL OF HOST BEHAVIOR 246 Conceptually, a host maintains three data structures: a list of 247 addresses per interface and two flags. One flag, called the "address 248 mode" flag, indicates whether the stateful protocol is to be used for 249 address configuration (possibly in addition to the stateless proto- 250 col). The other flag, called the "other configuration mode" flag, 251 indicates whether the stateful protocol is to be used for configura- 252 tion of other information besides addresses. 254 The address list always includes at least one address, the host's 255 link-local address, which is an address that can only be used in com- 256 munications between nodes attached to the link. In addition, the 257 address list includes any global or site-local addresses that have 258 been manually or automatically configured. 260 Note that stateless address autoconfiguration applies only to the 261 formation of unicast addresses. A node may, however, have anycast and 262 multicast addresses associated with an interface. In particular, a 263 host must join the all-nodes multicast address on any multicast 264 interface, and the solicited-node multicast address corresponding to 265 each unicast address on any multicast interface. 267 3.1. Address Configuration 269 3.1.1. Link-Local Address 271 On initialization of an interface, a host must form a link-local 272 address by concatenating a well-known link-local prefix[1] to an 273 interface token that is unique per link. The definition of the 274 tokens used are link-dependent. For example, in the case of a host 275 attached to a link that uses IEEE 802 addresses, the token is the 276 48-bit IEEE 802 link-layer address of the interface. Tokens for a 277 specific link are defined in link-specific IPv6 documents and are 278 outside the scope of this document. 280 Note that a host is able to autoconfigure a link-local address 281 completely autonomously. In particular, a host can form a link-local 282 address without a router present on the link. 284 3.1.2. Global/Site-Local Address 286 A host forms a new global/site-local address whenever a new prefix is 287 advertised by a router and stateless address configuration is 288 enabled. The address is formed by concatenating the network prefix 289 to the interface token that is unique per link in the same way as a 290 link-local address described above. 292 The mechanism used to advertise network prefixes for the purposes of 293 address configuration is the same as that used in Neighbor Discovery 294 for the purposes of prefix discovery. A router advertises prefix 295 information periodically and a host uses this information to config- 296 ure and reconfigure addresses. 298 3.2. Address Reconfiguration 300 One of the goals of IPv6 address autoconfiguration is not only to be 301 able to autoconfigure a list of addresses on initialization of an 302 interface, but to be able to change the address list dynamically. 303 Note that the link-local address never changes (except possibly on 304 interface re-initialization). Host addresses may need to change for a 305 number of reasons. For example, if the address assignment scheme is 306 provider-based, hosts may need to change addresses when hosts change 307 provider. Hosts may also need to change addresses when they are 308 disconnected from one link and connected to another. Reconfiguration 309 must not only allow a host to acquire a new address, but must also 310 allow hosts to time-out an old address. 312 Current networking protocols have not been designed to maintain 313 existing communications during an address change. For example, a TCP 314 connection will no longer work if one of the hosts changes its 315 address in the middle of a connection. Even in a UDP exchange, a host 316 is expected to be able to identify itself using the same address for 317 the length of the exchange. 319 To minimise disruption caused by an address change, an address is 320 configured with two lifetimes : a deprecation lifetime and an invali- 321 dation lifetime. The deprecation lifetime must be less than or equal 322 to the invalidation lifetime. Before expiry of the deprecation life- 323 time, the address is valid and may be used as the source and destina- 324 tion in any communications. At and after expiry of the deprecation 325 lifetime, but before the invalidation lifetime has expired, the 326 address is considered to be deprecated. A deprecated address can 327 still be used as the source and destination in packets legitimately, 328 but the deprecated address should not be used as a source address in 329 new communications if other valid addresses exist and these addresses 330 have sufficient scope. If no valid addresses of sufficient scope 331 exist, then the deprecated address should still be used. (Note that 332 there will always be at least one valid address in the address list, 333 the link-local address (see below), but this address is only useful 334 for communications on the local link, and thus cannot be used in 335 place of a deprecated address for non-local link communications). 337 An address becomes invalid when the invalidation lifetime expires. 338 Such an address must not be used as a source address in outgoing com- 339 munications or accepted as a destination address in incoming communi- 340 cations. An invalid address is removed from the address list of the 341 interface. 343 Note that the deprecation lifetimes and invalidation lifetimes of the 344 link-local address are set to infinity. Thus, the link-local address 345 is never deprecated. 347 The intention of the two lifetimes per address is to allow system 348 administrators to specify a graceful transition period during 349 renumbering. The purpose of the deprecation time is to indicate to 350 the host to start using another (presumably longer lasting) address 351 in new communications to minimise the risk of breaking communications 352 when the old one times out. A system administrator should set the 353 deprecation period long enough so that most, if not all, communica- 354 tions have switched over to using the new address by the time the old 355 one becomes invalid. The length of the deprecation period will be 356 environment-dependent as it depends on the expected length of commun- 357 ications. 359 The fact that addresses have a deprecation lifetime does not need to 360 affect the implementation of applications, i.e. an application is 361 not expected to react when an address it is using becomes deprecated. 362 The purpose of the deprecation lifetime is to help applications or 363 networking software to select a sufficiently long-lasting source 364 address at the beginning of a new communication. The IP layer is 365 expected to provide a means for upper layers or applications to 366 select the most appropriate source address given a particular desti- 367 nation. An application may choose to select the source address 368 itself before starting a new communication or may leave the address 369 unspecified, in which case the upper networking layers will use the 370 mechanism provided by the IP layer to choose a suitable address on 371 the application's behalf. 373 4. ROUTER SPECIFICATION 375 The stateless address autoconfiguration mechanism relies on the pre- 376 fix discovery mechanism specified in [2] for advertising network pre- 377 fixes required for the formation of addresses with site-local or glo- 378 bal scope. 380 A prefix is advertised in a Prefix Information option of a Router 381 Advertisement. Prefix Information includes 383 1. the prefix itself 385 2. the prefix length 387 3. a flag indicating whether the prefix is to be used for prefix 388 discovery[2]. 390 4. a flag indicating whether the prefix is to be used for stateless 391 address autoconfiguration 393 5. the deprecation lifetime of the prefix in seconds for the pur- 394 pose of address deprecation 396 6 the invalidation lifetime of the prefix for the purpose of 397 address invalidation. This field is also used by prefix 398 discovery[2]. 400 Router Advertisement processing is specified completely in [2] along 401 with the message formats and configuration variables. 403 5. HOST SPECIFICATION 405 This section specifies host address autoconfiguration behavior on 406 receiving a Router Advertisement. 408 5.1. Host Configuration Variables 410 A host SHOULD allow the following variable to be configured per mul- 411 ticast interface: 413 Perform_Addr_Config 415 If set, the host MUST use either stateless or stateful mechanisms 416 to configure global or site-local addresses and to acquire other 417 configuration information as specified in this document. 419 Default: TRUE 421 An interface that has the Perform_Addr_Config flag set is called an 422 "autoconfigurable interface". 424 5.2. Message Validation 426 A host MUST silently discard any Router Advertisement that does not 427 specify the validity checks as specified in [2]. An advertisement 428 that passes these validity checks is called a valid advertisement. 430 5.3. Router Advertisement Processing 432 To receive a Router Advertisement, a host joins the all-nodes multi- 433 cast address over all multicast-capable interfaces. 435 A host performs the following address configuration processing when a 436 valid solicited or unsolicited Router Advertisement is received over 437 an autoconfigurable interface: 439 For each valid Router Advertisement: 441 The host stores the current value of the Address Mode and then 442 sets the Address Mode to the value of the Managed flag (M bit). 443 If the new value is set, the host MUST use stateful address confi- 444 guration to configure and maintain a list of site-local or global 445 addresses per interface. 447 Note that this does not mean that the stateful protocol is neces- 448 sarily invoked each time a Router Advertisement arrives with the M 449 bit set. The host uses the flag only to indicate whether the 450 stateful protocol is to be used to configure addresses. The state- 451 ful protocol is enabled as soon as the Address Mode changes from 452 FALSE to TRUE. The protocol is disabled as soon as the flag 453 changes from TRUE to FALSE. The actual times at which the proto- 454 col is invoked, for example, to request a list of addresses or 455 renew a list of addresses, are specified by the protocol itself. 457 The host stores the current value of the Other Configuration flag 458 and then sets the Other Configuration Mode flag to that in the 459 Router Advertisement (O bit). If the new value is set, the host 460 MUST use stateful autoconfiguration to acquire other configuration 461 information besides the address. 463 The above disclaimer applies here as well. The O bit indicates 464 whether the host must use the stateful mode to acquire other con- 465 figuration information. The stateful protocol is enabled for this 466 purpose as soon as the Other Configuration Mode changes from FALSE 467 to TRUE. The protocol is disabled as soon as the mode changes from 468 TRUE to FALSE. The mode does not indicate the timing of frequency 469 of acquiring that information. This is defined by the stateful 470 protocol itself. 472 For each Prefix-Information extension in the Router Advertisement 473 that has the Autonomous flag set: 475 - If the prefix advertised matches the prefix of an 476 autoconfigured address already in the list, then set the 477 deprecation timer to that of the deprecation lifetime speci- 478 fied in the extension and the invalidation timer to that of 479 the invalidation lifetime. 481 Note that this processing MUST NOT be applied to the link- 482 local address. That is, if the well-known link-local prefix 483 is advertised for some reason (probably a configuration 484 error), then the prefix should be ignored and a system 485 management error logged. 487 - If the prefix advertised does not match the prefix of an 488 address already in the list, then form an address using this 489 network prefix and the interface token. Definitions of the 490 interface token to be used on a specific link are documented 491 elsewhere. 493 If the prefix advertised is too short or too long to form a 494 128-bit address, given the interface token, the prefix is 495 ignored and an error is logged. 497 Add this address to the list with the deprecation timer set 498 to that of the deprecation lifetime and the invalidation 499 timer to that of the invalidation lifetime. 501 Note: The address list should be variable-length. Hosts 502 should be able to store the link-local address as well as all 503 addresses configured using both the stateless and stateful 504 modes. If the implementation cannot store all addresses, the 505 host should log a system management error. 507 Note that if the deprecation lifetime is zero, the address with 508 that prefix is immediately deprecated. Similarly, if the invalida- 509 tion lifetime is zero, the address with that prefix is immediately 510 made invalid. (The invalidation lifetime is defined to be no less 511 than the deprecation lifetime.) If the deprecation lifetime is 512 infinity, the address is never deprecated. Similarly, if the 513 invalidation lifetime is infinity, the address is never invali- 514 dated. The value of infinity is defined in [2]. 516 An address is valid until the deprecation timer expires. A valid 517 address can be used as a source address in all outgoing 518 communications and is accepted as a destination address in all 519 incoming communications. 521 When the deprecation lifetime of an address expires, the address 522 SHOULD continue to be used as a source address if it is in use in 523 existing communications, but SHOULD NOT be used in new communica- 524 tions if a valid address is available and it has sufficient scope. 525 The IP layer MUST continue to accept datagrams destined to a 526 deprecated address since a deprecated address is still defined to 527 identify the interface. 529 An address remains deprecated until its invalidation timer expires 530 at which point the address becomes invalid and is removed from the 531 address list. An invalid address can no longer be used as a 532 source address in outgoing communications and is not recognised as 533 a valid destination address in incoming communications since the 534 address is defined to no longer identify the interface. 536 On initialisation of an interface, if a host determines that there 537 are no IPv6 routers on a link, a host MUST attempt to use stateful 538 autoconfiguration to acquire addresses and other configuration 539 information. This is needed to support networks with no IPv6 540 routers. The host determines that there are no routers on the 541 link after startup if no Router Advertisements are heard in the 542 time that it would take to send MAX_ROUTER_SOLICITATIONs and wait 543 for a response[2]. If a router comes up on the link and Router 544 Advertisements begin to be received, a host MUST start to use 545 Router Advertisements in the normal way, and, in particular, use 546 advertisements to determine whether stateless or stateful address 547 configuration should be in use. 549 Note that it is possible for hosts to get address information 550 using both stateless and stateful protocols since both may be 551 enabled at the same time. Even if only stateless address autocon- 552 figuration mode is enabled, it is still possible for hosts to get 553 information from multiple sources since multiple routers may be 554 advertising prefix information. The rules for handling this is as 555 follows: hosts accept the union of all information received using 556 the stateless and stateful protocols. If different sources config- 557 ure the same address, then the address is updated with the most 558 recently advertised lifetime. 560 It is also possible for hosts to contain address information from 561 different sources, when changing from one mechanism to the other, 562 i.e. when changing from stateless mode to stateful mode, and vice 563 versa. In this case, the rules are no different from above. If the 564 newly enabled mode is configured to hand out different addresses 565 than the mode just disabled, then the host contains the union of 566 addresses from both sources until the addresses configured using 567 the old protocol timeout. If both the old and new modes are con- 568 figured to hand out the same address, then the address is updated 569 with the most recently advertised lifetime. NOTE: The above 570 assumes that the stateless and stateful modes have the same life- 571 time semantics. 573 6. NODE SPECIFICATION 575 This section specifies the rules for forming a link-local address. It 576 also specifies the protocol to be used for duplicate address detec- 577 tion. 579 6.1. Forming a Link-Local Address 581 A node MUST have a link-local address. A node forms a link-local 582 address whenever an interface is initialised. The method for forming 583 a link-local address is link-dependent and is outside the scope of 584 this document. 586 An interface may be initialised or become autoconfigurable after any 587 of the following events: 589 - The interface is initialized at system startup time. 591 - The interface is reinitialized after a temporary interface 592 failure or after being temporarily disabled by system manage- 593 ment. 595 - The node is re-attached to a link after being detached for some 596 time. 598 The link-local address is highly likely to need to be one of the 599 first events in the interface initialisation process. Clearly, it 600 must be formed before any duplicate detection processing is performed 601 for this address (Section 6.2). In hosts, a link-local address is 602 also required before a sends out a Router Solicitation, assuming the 603 node chooses to do this[2]. This is because a solicitation is only 604 sent if an advertisement has not yet been heard (and hence no non- 605 link local address can be formed), and the unspecified address cannot 606 be used as a source address in a Router Solicitation. 608 6.2. Detecting Duplicate Addresses 610 The procedure to detect a duplicate address MUST be enabled by 611 default in nodes and SHOULD be used. 613 In principle, the duplicate address detection procedure is applied to 614 each new address configured for an interface, whether it be manually 615 configured or configured automatically using either the stateless or 616 stateful mode. However, if the addresses belonging to an interface 617 are formed using the same interface token (as is the case in state- 618 less autoconfiguration and may be the case in other forms of confi- 619 guration), then it is only necessary to check that one of the 620 addresses is unique on the link. In the stateless mechanism, it is 621 recommended that the link-local address be the address checked for 622 two reasons. First, it makes the implementation simpler, since the 623 link-local address is guaranteed to always exist in all nodes, 624 whereas global and site-local addresses are not. Second, in hosts, 625 there will be less delay in performing duplicate address detection. 626 Address validation can be done as soon as a link-local address is 627 formed (this can be done immediately on initialisation of an inter- 628 face), whereas checking a global or site-local address involves wait- 629 ing until a host hears a Router Advertisement containing address pre- 630 fixes, and there is the possibility that no advertisement will be 631 heard at all. 633 The procedure for duplicate address detection uses Neighbor Solicita- 634 tion and Advertisement messages specified in [2] to validate an 635 address as specified below. Note that before carrying out this pro- 636 cedure, a node joins the all-nodes multicast address. Also, this 637 mechanism is not completely reliable, and so it is possible that 638 duplicate addresses will still exist. If a duplicate address is 639 discovered after carrying out this procedure, the node will need to 640 be configured with a new token, or if this is not possible, the IPv6 641 addresses will need to be manually configured. 643 6.2.1. Soliciting Node Behavior 645 An address is checked for uniqueness only once, when the address is 646 initially configured. 648 Once the address is configured, the node sends a Neighbor Solicita- 649 tion with a target address containing the address to be validated. 650 The source is set to the unspecified address and the destination is 651 set to the solicited-node multicast address. The Source Link Layer 652 Address extension SHOULD NOT be sent (as it will be ignored by the 653 destination node[2]). Loopback of the Neighbor Solicitation MUST NOT 654 be disabled. 656 NOTE: If the Neighbor Solicitation is the first message to be sent 657 from an interface on interface initialisation, the node should delay 658 a random amount of time between 0 and MAX_INITIALIZATION_DELAY 659 seconds before sending the solicitation. This serves to alleviate 660 congestion when many nodes start up on the link at the same time, 661 such as after a power failure, and helps to avoid race conditions 662 when more than one node is trying to solicit for the same address at 663 the same time. (It is recommended that nodes include some unique 664 value in the seed used to initialise their pseudo-random number gen- 665 erators. Note that using only the node token as a unique value is not 666 sufficient to avoid race conditions since the token cannot be relied 667 upon to be unique. Although the randomization range is specified in 668 units of seconds, the actual randomly-chosen value should not be in 669 units of whole seconds, but rather in units of the highest available 670 timer resolution.) 672 If after sending a solicitation, no Neighbor Advertisement is 673 received from the target, the node SHOULD retransmit the solicitation 674 at most every DUPL_ADDR_RETRANS_TIMER seconds until either an adver- 675 tisement is received or the solicitation has been retransmitted 676 MAX_DUPL_ADDR_RETRANS times. If an advertisement is received with a 677 target address the same as the address being validated in the time it 678 takes to send and wait for MAX_DUPL_ADDR_RETRANS solicitations, it 679 must disable that interface and log a system management error. If no 680 such advertisement is received within the time specified, the address 681 is considered to be valid. 683 6.2.2. Solicited Node Behavior 685 A node is in the process of validating an address when a Neighbor 686 Solicitation has been sent for the address and no Neighbor Advertise- 687 ment advertising that address has been received in the time it takes 688 to send out MAX_DUPL_ADDR_RETRANS solicitations and wait for an 689 advertisement (DUPL_ADDR_IGNORE_TIMER seconds). 691 A node must follow special rules when it receives a Neighbor Solici- 692 tation for an address that it is in the process of validating. This 693 is done to help avoid the race condition where more than one node is 694 attempting to validate the address at the same time, i.e. each node 695 sends out a Neighbor Solicitation and waits to hear a Neighbor Adver- 696 tisement for the address, but no node actually sends an advertisement 697 since the address has not yet been validated. 699 The special rules are as follows: When a node is in the process of 700 validating an address and receives a Neighbor Solicitation for that 701 address, it MUST NOT send any advertisement in response to a solici- 702 tation for that address. Rather, the node silently discards the sol- 703 icitation unless the source address is the unspecified address. In 704 the latter case, the first such solicitation received is noted, but 705 otherwise silently discarded (see NOTE below). Any subsequent such 706 solicitations cause the node to disable the interface and log a sys- 707 tem management error. 709 NOTE: The above behavior is required because nodes send out Neighbor 710 Solicitations for their own address with loopback enabled. Thus, a 711 node will always receive at least one solicitation for its own 712 address. However, there is no way for the node to determine, in gen- 713 eral, whether the solicitation comes from itself or another node 714 since the source of the packet is the unspecified address. Hence, the 715 above rules specify that a duplicate address is detected only if the 716 node receives more than one solicitation for the address. 718 Once a node has validated its address, it responds to a Neighbor Sol- 719 icitation with a Neighbor Advertisement as specified in [2]. 721 6.2.3. Constants 723 MAX_INITIALIZATION_DELAY 3 seconds 724 DUPL_ADDR_RETRANS_TIMER 3 seconds 725 MAX_DUPL_ADDR_RETRANS 1 transmission 727 7. SECURITY CONSIDERATIONS 729 To be completed. 731 8. REFERENCES 733 [1] R. Hinden and S. Deering, "Internet Protocol Version (IPv6) 734 Addressing Architecture", Internet Draft, May 1995, draft-ietf- 735 ipngwg-addr-arch-02.txt 737 [2] T. Narten, E. Nordmark and W. A. Simpson, "IPv6 Neighbor 738 Discovery", Internet Draft, July 1995, 741 Acknowledgements 743 The author would like to thank the members of both the IPNG and ADDRCONF 744 working groups for their input. In particular, thanks to Jim Bound, 745 Steve Deering, Erik Nordmark and Bill Simpson. 747 Author's Addresses 749 Susan Thomson 750 Bellcore 751 445 South Street 752 Morristown, NJ 07960 753 U.S.A. 755 Phone: +1 201-829-4514 756 Email: set@thumper.bellcore.com