idnits 2.17.1 draft-ietf-zeroconf-ipv4-linklocal-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 page length should not exceed 58 lines per page, but there was 29 longer pages, the longest (page 2) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 30 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 575 has weird spacing: '...) on an inter...' == Line 576 has weird spacing: '...ost has confi...' == Line 577 has weird spacing: '...oes not match...' == Line 756 has weird spacing: '... alter the b...' == Line 757 has weird spacing: '... Local confi...' == (4 more instances...) == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 959' is mentioned on line 1079, but not defined == Unused Reference: 'RFC2434' is defined on line 1150, but no explicit reference was found in the text == Unused Reference: '1394' is defined on line 1184, but no explicit reference was found in the text == Unused Reference: 'USB' is defined on line 1208, but no explicit reference was found in the text == Unused Reference: 'X10' is defined on line 1210, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) == Outdated reference: A later version (-18) exists of draft-ietf-dhc-dna-ipv4-05 == Outdated reference: A later version (-47) exists of draft-ietf-dnsext-mdns-29 Summary: 3 errors (**), 0 flaws (~~), 18 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ZEROCONF Working Group Stuart Cheshire 2 INTERNET-DRAFT Apple Computer 3 Category: Standards Track Bernard Aboba 4 Microsoft Corporation 5 24 January 2004 Erik Guttman 6 Sun Microsystems 8 Dynamic Configuration of Link-Local IPv4 Addresses 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) The Internet Society (2004). All Rights Reserved. 32 Abstract 34 To participate in wide-area IP networking, a host needs to be 35 configured with IP addresses for its interfaces, either manually by 36 the user or automatically from a source on the network such as a DHCP 37 server. Unfortunately, such address configuration information may not 38 always be available. It is therefore beneficial for a host to be able 39 to depend on a useful subset of IP networking functions even when no 40 address configuration is available. This document describes how a 41 host may automatically configure an interface with an IPv4 address 42 within the 169.254/16 prefix that is valid for communication with 43 other devices connected to the same physical (or logical) link. 45 Link-Local IPv4 addresses are not suitable for communication with 46 devices not directly connected to the same physical (or logical) 47 link, and are only used where stable, routable addresses are not 48 available (such as on ad hoc or isolated networks). This document 49 does not recommend that Link-Local IPv4 addresses and routable 50 addresses be configured simultaneously on the same interface. 52 Table of Contents 54 1. Introduction.............................................. 3 55 1.1 Requirements ....................................... 3 56 1.2 Terminology ........................................ 3 57 1.3 Applicability....................................... 4 58 1.4 Application Layer Protocol Considerations........... 5 59 1.5 Autoconfiguration Issues ........................... 6 60 1.6 Alternate Use Prohibition .......................... 6 61 1.7 Multiple Interfaces ................................ 7 62 1.8 Communication with Routable Addresses............... 7 63 1.9 When to configure a Link-Local IPv4 Address ........ 7 64 2. Address Selection, Defense and Delivery................... 9 65 2.1 Link-Local Address Selection........................ 9 66 2.2 Claiming a Link-Local Address....................... 10 67 2.3 Shorter Timeouts ................................... 11 68 2.4 Announcing an Address............................... 12 69 2.5 Conflict Detection and Defense...................... 12 70 2.6 Address Usage and Forwarding Rules.................. 13 71 2.7 Link-Local Packets Are Not Forwarded................ 14 72 2.8 Link-Local Packets are Local........................ 15 73 2.9 Higher-Layer Protocol Considerations................ 15 74 2.10 Privacy Concerns.................................... 15 75 2.11 Interaction between DHCP4 and IPv4LL State 76 Machines ........................................... 15 77 3. Considerations for Multiple Interfaces.................... 16 78 3.1 Scoped Addresses.................................... 16 79 3.2 Address Ambiguity................................... 17 80 3.3 Interaction with Hosts with Routable Addresses...... 18 81 3.4 Unintentional Autoimmunity.......................... 19 82 4. Healing of Network Partitions ............................ 19 83 5. Security Considerations................................... 20 84 6. Application Programming Considerations.................... 21 85 6.1 Address Changes, Failure and Recovery............... 21 86 6.2 Limited Forwarding of Locators...................... 22 87 6.3 Address Ambiguity................................... 22 88 7. Router Considerations..................................... 22 89 8. IANA Considerations....................................... 23 90 9. Constants ................................................ 23 91 10. References ............................................... 23 92 10.1 Normative References ............................... 23 93 10.2 Informative References ............................. 23 94 Acknowledgments .............................................. 24 95 Authors' Addresses ........................................... 25 96 Appendix A - Prior Implementations............................ 26 97 Intellectual Property Statement .............................. 29 98 Full Copyright Statement ..................................... 30 99 1. Introduction 101 As the Internet Protocol continues to grow in popularity, it becomes 102 increasingly valuable to be able to use familiar IP tools such as FTP 103 not only for global communication, but for local communication as 104 well. For example, two people with laptop computers supporting IEEE 105 802.11 Wireless LANs [802.11] may meet and wish to exchange files. 106 It is desirable for these people to be able to use IP application 107 software without the inconvenience of having to manually configure 108 static IP addresses or set up a DHCP server [RFC2131]. 110 This document describes a method by which a host may automatically 111 configure an interface with an IPv4 address in the 169.254/16 prefix 112 that is valid for Link-Local communication on that interface. This 113 is especially valuable in environments where no other configuration 114 mechanism is available. The IPv4 prefix 169.254/16 is registered 115 with the IANA for this purpose. Allocation of Link-Local IPv6 116 addresses is described in "IPv6 Stateless Address Autoconfiguration" 117 [RFC2462]. 119 Link-Local communication using Link-Local IPv4 addresses is only 120 suitable for communication with other devices connected to the same 121 physical (or logical) link. Link-Local communication using Link- 122 Local IPv4 addresses is not suitable for communication with devices 123 not directly connected to the same physical (or logical) link. 125 Microsoft Windows 98 (and later) and Mac OS 8.5 (and later) already 126 support this capability. This document standardizes usage, 127 prescribing rules for how Link-Local IPv4 addresses MUST be treated 128 by hosts and routers. In particular, it describes how routers MUST 129 behave when receiving packets with IPv4 Link-Local addresses in the 130 source or destination address. With respect to hosts, it discusses 131 claiming and defending addresses, maintaining Link-Local and routable 132 IPv4 addresses on the same interface, and multihoming issues. 134 1.1. Requirements 136 In this document, several words are used to signify the requirements 137 of the specification. These words are often capitalized. The key 138 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 139 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 140 are to be interpreted as described in [RFC2119]. 142 1.2. Terminology 144 This document describes Link-Local addressing, for IPv4 communication 145 between two hosts on a single link. A set of hosts is considered to 146 be "on the same link", if: 148 - when any host A from that set sends a packet to any other 149 host B in that set, using unicast, multicast, or broadcast, 150 the entire link-layer packet payload arrives unmodified, 151 and 153 - a broadcast sent over that link by any host from that set 154 of hosts can be received by every other host in that set 156 The link-layer *header* may be modified, such as in Token Ring Source 157 Routing [802.5], but not the link-layer *payload*. In particular, if 158 any device forwarding a packet modifies any part of the IP header or 159 IP payload then the packet is no longer considered to be on the same 160 link. This means that the packet may pass through devices such as 161 repeaters, bridges, hubs or switches and still be considered to be on 162 the same link for the purpose of this document, but not through a 163 device such as an IP router that decrements the TTL or otherwise 164 modifies the IP header. 166 This document uses the term "routable address" to refer to all 167 unicast IPv4 addresses outside the 169.254/16 prefix, including 168 global addresses and private addresses such as Net 10/8 [RFC1918], 169 all of which may be forwarded via routers. 171 Wherever this document uses the term "host" when describing use of 172 Link-Local IPv4 addresses, the text applies equally to routers when 173 they are the source of or intended destination of packets containing 174 Link-Local IPv4 source or destination addresses. 176 Wherever this document uses the term "sender IP address" or "target 177 IP address" in the context of an ARP packet, it is referring to the 178 fields of the ARP packet identified in the ARP specification [RFC826] 179 as "ar$spa" (Sender Protocol Address) and "ar$tpa" (Target Protocol 180 Address) respectively. For the usage of ARP described in this 181 document, each of these fields always contains an IP address. 183 In this document, the term "ARP Probe" is used to refer to an ARP 184 Request packet, broadcast on the local link, with an all-zero 'sender 185 IP address'. The 'sender hardware address' MUST contain the hardware 186 address of the interface sending the packet. The 'target hardware 187 address' field is ignored and SHOULD be set to all zeroes. The 188 'target IP address' field MUST be set to the address being probed. 190 In this document, the term "ARP Announcement" is used to refer to an 191 ARP Request packet, broadcast on the local link, identical to the ARP 192 probe described above, except that both the sender and target IP 193 address fields contain the IP address being announced. 195 1.3. Applicability 197 This specification applies to all IEEE 802 Local Area Networks (LANs) 198 [802], including Ethernet [802.3], Token-Ring [802.5] and IEEE 802.11 199 wireless LANs [802.11], as well as to other link-layer technologies 200 that operate at data rates of at least 1 Mbps, have a round-trip 201 latency of at most one second, and support ARP [RFC826]. Wherever 202 this document uses the term "IEEE 802", the text applies equally to 203 any of these network technologies. 205 Link-layer technologies that support ARP but operate at rates below 1 206 Mbps or latencies above one second may need to specify different 207 values for the following parameters described in Sections 2.2, 2.3 208 and 2.4: 210 (a) the number of, and interval between, ARP probes, 211 (b) the number of, and interval between, ARP announcements, 212 (c) the maximum rate at which address claiming may be attempted, and 213 (d) the time interval between conflicting ARPs below which a host 214 MUST reconfigure instead of attempting to defend its address. 216 Link-layer technologies that do not support ARP may be able to use 217 other techniques for determining whether a particular IP address is 218 currently in use. However, the application of claim-and-defend 219 mechanisms to such networks is outside the scope of this document. 221 This specification is intended for use with small ad-hoc networks - a 222 single link containing only a few hosts. Although 65024 Link-Local 223 IPv4 addresses are available in principle, attempting to use all 224 those addresses on a single link would result a high probability of 225 an address conflict, requiring a host to take an inordinate amount of 226 time to find an available address. 228 Network operators with more than 1300 hosts on a single link may want 229 to consider dividing that single link into two or more subnets. A 230 host connecting to a link that already has 1300 hosts, selecting a 231 Link-Local IPv4 address at random, has a 98% chance of selecting an 232 unused Link-Local IPv4 address on the first try. A host has a 99.96% 233 chance of selecting an unused Link-Local IPv4 address within two 234 tries. The probability that it will have to try more than ten times 235 is about 1 in 10^17. 237 1.4. Application Layer Protocol Considerations 239 Link-Local IPv4 addresses and their dynamic configuration have 240 profound implications upon applications which use them. This is 241 discussed in Section 6. Many applications fundamentally assume that 242 addresses of communicating peers are routable, relatively unchanging 243 and unique. These assumptions no longer hold with Link-Local IPv4 244 addresses, or a mixture of Link-Local and routable IPv4 addresses. 245 Therefore while many applications will work properly with Link-Local 246 IPv4 addresses, or a mixture of Link-Local and routable IPv4 247 addresses, others may do so only after modification, or will exhibit 248 reduced or partial functionality. 250 In some cases it may be infeasible for the application to be modified 251 to operate under such conditions. 253 Link-Local IPv4 addresses should therefore only be used where stable, 254 routable addresses are not available (such as on ad hoc or isolated 255 networks) or in controlled situations where these limitations and 256 their impact on applications are understood and accepted. This 257 document does not recommend that Link-Local IPv4 addresses and 258 routable addresses be configured simultaneously on the same 259 interface. 261 Use of Link-Local IPv4 addresses in off-link communication is likely 262 to cause application failures. This can occur within any application 263 that includes embedded addresses, if a Link-Local IPv4 address is 264 embedded when communicating with a host that is not on the link. 265 Examples of applications that include embedded addresses are found in 266 [RFC3027]. This includes IPsec, Kerberos 4/5, X- 267 Windows/Xterm/Telnet, FTP, RSVP, SMTP, SIP, Real Audio, H.323, and 268 SNMP. 270 In order to prevent use of Link-Local IPv4 addresses in off-link 271 communication, the following cautionary measures are advised: 273 a. Routable addresses should be used within applications whenever 274 they are available. 276 b. Names that are globally resolvable to routable addresses should be 277 used within applications whenever they are available. Names that are 278 resolvable only on the local link (such as through use of protocols 279 such as Link Local Multicast Name Resolution [LLMNR]) MUST NOT be 280 used in off-link communication. IPV4 addresses and names which can 281 only be resolved on the local link SHOULD NOT be forwarded, they 282 SHOULD only be sent when a Link-Local address is used as the source 283 address. This strong advice should hinder limited scope addresses 284 and names from leaving the context in which they apply. 286 c. Link-Local IPv4 addresses MUST NOT be configured in the DNS. 288 1.5. Autoconfiguration Issues 290 Implementations of Link-Local IPv4 address autoconfiguration MUST 291 expect address collisions, and MUST be prepared to handle them 292 gracefully by automatically selecting a new address whenever a 293 collision is detected, as described in Section 2. This requirement 294 to detect and handle address collisions applies during the entire 295 period that a host is using a 169.254/16 Link-Local IPv4 address, not 296 just during initial interface configuration. For example, address 297 collisions can occur well after a host has completed booting if two 298 previously separate networks are joined, as described in Section 4. 300 1.6. Alternate Use Prohibition 302 Note that addresses in the 169.254/16 prefix SHOULD NOT be configured 303 manually or by a DHCP server. Manual or DHCP configuration may cause 304 a host to use an address in the 169.254/16 prefix without following 305 the special rules regarding duplicate detection and automatic 306 configuration that pertain to addresses in this prefix. While 307 [RFC2131] indicates that a DHCP client SHOULD probe a newly received 308 address with ARP, this is not mandatory. Similarly, while [RFC2131] 309 recommends that a DHCP server SHOULD probe an address using an ICMP 310 Echo Request before allocating it, this is also not mandatory, and 311 even if the server does this, Link-Local IPv4 addresses are not 312 routable, so a DHCP server not directly connected to a link cannot 313 detect whether a host on that link is already using the desired Link- 314 Local IPv4 address. 316 Administrators wishing to configure their own local addresses (using 317 manual configuration, a DHCP server, or any other mechanism not 318 described in this document) should use one of the existing private 319 address prefixes [RFC1918], not the 169.254/16 prefix. 321 1.7. Multiple Interfaces 323 Additional considerations apply to hosts that support more than one 324 active interface where one or more of these interfaces support Link- 325 Local IPv4 address configuration. These considerations are 326 discussed in Section 3. 328 1.8. Communication with Routable Addresses 330 There will be cases when devices with a configured Link-Local address 331 will need to communicate with a device with a routable address 332 configured on the same physical link, and vice versa. The rules in 333 Section 2.6 allow this communication. 335 This allows, for example, a laptop computer with only a routable 336 address to communicate with web servers world-wide using its 337 globally-routable address while at the same time printing those web 338 pages on a local printer that has only a Link-Local IPv4 address. 340 1.9. When to configure a Link-Local IPv4 address 342 Having addresses of multiple different scopes assigned to an 343 interface, with no adequate way to determine in what circumstances 344 each address should be used, leads to complexity for applications and 345 confusion for users. A host with an address on a link can 346 communicate with all other devices on that link, whether those 347 devices use Link-Local addresses, or routable addresses. For these 348 reasons, a host SHOULD NOT have both a valid routable address and a 349 Link-Local IPv4 address configured on the same interface. 351 A routable address is any address that is: 353 * a unicast address 354 * not a loopback address 355 * not contained within the 169.254/16 prefix reserved for Link-Local 356 IPv4 addresses 358 A "valid routable address" is a routable address that passes the 359 reachability test described in section 2 of "Detection of Network 360 Attachment (DNA) in IPv4" [DNAv4]. 362 The assignment and use of a Link-Local IPv4 address on an interface 363 is based solely on the state of the interface, and is independent of 364 any other protocols such as DHCP. A host MUST NOT alter its behavior 365 and use of other protocols such as DHCP because the host has assigned 366 a Link-Local IPv4 address to an interface. 368 When an interface has a valid routable address configured on an 369 interface, the host SHOULD NOT also assign a Link-Local IPv4 address 370 to that interface. 372 If a host finds that an interface that was previous configured with a 373 Link-Local IPv4 address is now configured with a valid routable 374 address, the host MUST always use the routable address when 375 initiating new communications, and MUST cease advertising the 376 availability of the Link-Local IPv4 address through whatever 377 mechanisms that address had been made known to others. The host 378 SHOULD continue to use the Link-Local IPv4 address for communications 379 underway when the routable address was configured, and MAY continue 380 to accept new communications addressed to the Link-Local IPv4 381 address. Ways in which a valid routable address might be configured 382 for the interface include: 384 * Manual configuration 385 * Address assignment through DHCP 386 * Roaming of the host to a network on which a routable address 387 assigned to the interface is valid 389 If a host finds that an interface that was previously configured with 390 a valid routable address no longer has a valid routable address, the 391 host MAY identify a usable Link-Local IPv4 address (as described in 392 section 2) and assign that address to the interface. Ways in which a 393 valid routable address might no longer be assigned to an interface 394 include: 396 * Removal of the address from the interface through manual 397 configuration 398 * Expiration of the lease on the address assigned through DHCP 399 * Roaming of the host to a new network on which the address is no 400 longer valid. 402 Further discussion of the issues in detection of transient failures 403 and the use of DHCP in response to network attachment failure is 404 provided in "Detection of Network Attachment (DNA) in IPv4". [DNAv4] 406 2. Address Selection, Defense and Delivery 408 The following section explains the Link-Local IPv4 address selection 409 algorithm, how Link-Local IPv4 addresses are defended, and how IPv4 410 packets with Link-Local IPv4 addresses are delivered. 412 Windows and Mac OS hosts that already implement Link-Local IPv4 413 address auto-configuration are compatible with the rules presented in 414 this section. However, should any interoperability problem be 415 discovered, this document, not any prior implementation, defines the 416 standard. 418 2.1. Link-Local Address Selection 420 When a host wishes to configure a Link-Local IPv4 address, it selects 421 an address using a pseudo-random number generator with a uniform 422 distribution in the range from 169.254.1.0 to 169.254.254.255. The 423 IPv4 prefix 169.254/16 is registered with the IANA for this purpose. 424 The first 256 and last 256 addresses in the 169.254/16 prefix are 425 reserved for future use and MUST NOT be selected by a host using this 426 dynamic configuration mechanism. 428 The pseudo-random number generation algorithm MUST be chosen so that 429 different hosts do not generate the same sequence of numbers. If the 430 host has access to persistent information that is different for each 431 host, such as its IEEE 802 MAC address, then the pseudo-random number 432 generator SHOULD be seeded using a value derived from this 433 information. This means that even without using any other persistent 434 storage, a host will usually select the same Link-Local IPv4 address 435 each time it is booted, which can be convenient for debugging and 436 other operational reasons. Seeding the pseudo-random number 437 generator using the real-time clock or any other information which is 438 (or may be) identical in every host is NOT suitable for this purpose, 439 because a group of hosts that are all powered on at the same time 440 might then all generate the same sequence, resulting in a never- 441 ending series of conflicts as the hosts move in lock-step though 442 exactly the same pseudo-random sequence, conflicting on every address 443 they probe. 445 Hosts that are equipped with persistent storage MAY, for each 446 interface, record the IPv4 address they have selected. On booting, 447 hosts with a previously recorded address SHOULD use that address as 448 their first candidate when probing. This increases the stability of 449 addresses. For example, if a group of hosts are powered off at 450 night, then when they are powered on the next morning they will all 451 resume using the same addresses, instead of picking different 452 addresses and potentially having to resolve conflicts that arise. 454 2.2. Claiming a Link-Local Address 456 After it has selected a Link-Local IPv4 address, a host MUST test to 457 see if the Link-Local IPv4 address is already in use before beginning 458 to use it. When a network interface transitions from an inactive to 459 an active state, the host does not have knowledge of what Link-Local 460 IPv4 addresses may currently be in use on that link, since the point 461 of attachment may have changed or the network interface may have been 462 inactive when a conflicting address was claimed. 464 Were the host to immediately begin using a Link-Local IPv4 address 465 which is already in use by another host, this would be disruptive to 466 that other host. Since it is possible that the host has changed its 467 point of attachment, a routable address may be obtainable on the new 468 network, and therefore it cannot be assumed that a Link-Local IPv4 469 address is to be preferred. 471 Before using the Link-Local IPv4 address (e.g. using it as the source 472 address in an IPv4 packet, or as the Sender IPv4 address in an ARP 473 packet) a host MUST perform the probing test described below to 474 achieve better confidence that using the Link-Local IPv4 address will 475 not cause disruption. 477 Examples of events that involve an interface becoming active include: 479 Reboot/startup 480 Wake from sleep (if network interface was inactive during sleep) 481 Bringing up previously inactive network interface 482 IEEE 802 hardware link-state change that indicates that a 483 cable was attached. 484 Association with a wireless base station. 486 A host MUST NOT perform this check periodically as a matter of 487 course. This would be a waste of network bandwidth, and is 488 unnecessary due to the ability of hosts to passively discover 489 conflicts, as described in Section 2.5. 491 2.2.1. Probe details 493 On a link-layer such as IEEE 802 that supports ARP, conflict 494 detection is done using ARP probes. On link-layer technologies that 495 do not support ARP other techniques may be available for determining 496 whether a particular IPv4 address is currently in use. However, the 497 application of claim-and-defend mechanisms to such networks is left 498 to a future document. 500 A host probes to see if an address is already in use by broadcasting 501 an ARP Request for the desired address. The client MUST fill in the 502 'sender hardware address' field of the ARP Request with the hardware 503 address of the interface through which it is sending the packet. The 504 'sender IP address' field MUST be set to all zeroes, to avoid 505 polluting ARP caches in other hosts on the same link in the case 506 where the address turns out to be already in use by another host. 507 The 'target hardware address' field is ignored and SHOULD be set to 508 all zeroes. The 'target IP address' field MUST be set to the address 509 being probed. An ARP Request constructed this way with an all-zero 510 'sender IP address' is referred to as an "ARP probe". 512 When ready to begin probing, the host should then wait for a random 513 time interval selected uniformly in the range PROBE_MIN to PROBE_MAX 514 seconds, and should then send three probe packets, spaced randomly, 515 PROBE_MIN to PROBE_MAX seconds apart. 517 When ready to begin probing, the host should then wait for a random 518 time interval selected uniformly in the range PROBE_MIN to PROBE_MAX 519 seconds, and should then send NUM_PROBES probe packets, spaced 520 randomly, PROBE_MIN to PROBE_MAX seconds apart. 522 If during this period, from the beginning of the probing process 523 until PROBE_MAX seconds after the last probe packet is sent, the host 524 receives any ARP packet (Request *or* Reply) on the interface where 525 the probe is being performed where the packet's 'sender IP address' 526 is the address being probed for, then the host MUST treat this 527 address as being in use by some other host, and MUST select a new 528 pseudo-random address and repeat the process. In addition, if during 529 this period the host receives any ARP probe where the packet's 530 'target IP address' is the address being probed for, and the packet's 531 'sender hardware address' is not the hardware address of the 532 interfaces the host is attempting to configure, then the host MUST 533 similarly treat this as an address collision and select a new address 534 as above. This can occur if two (or more) hosts attempt to configure 535 the same Link-Local IPv4 address at the same time. 537 A host should maintain a counter of the number of address collisions 538 it has experienced in the process of trying to acquire an address, 539 and if the number of collisions exceeds MAX_COLLISIONS then the host 540 MUST limit the rate at which it probes for new addresses to no more 541 than one new address per RATE_LIMIT_INTERVAL. This is to prevent 542 catastrophic ARP storms in pathological failure cases, such as a 543 rogue host that answers all ARP probes, causing legitimate hosts to 544 go into an infinite loop attempting to select a usable address. 546 If, by PROBE_MAX seconds after the transmission of the last ARP probe 547 no conflicting ARP Reply or ARP probe has been received, then the 548 host has successfully claimed the desired Link-Local IPv4 address. 550 2.3. Shorter timeouts 552 Network technologies may emerge for which shorter delays are 553 appropriate than those required by this document. A subsequent IETF 554 publication may be produced providing guidelines for different timer 555 settings for PROBE_MIN and PROBE_MAX on those technologies. 557 2.4. Announcing an Address 559 The host MUST then announce its claimed address by broadcasting two 560 ARP announcements, spaced PROBE_MAX seconds apart. This time 561 interval is not modified by the shorter timeouts described above in 562 Section 2.3. An ARP announcement is identical to the ARP probe 563 described above, except that now the sender and target IP addresses 564 are both set to the host's newly selected IPv4 address. The purpose 565 of these ARP announcements is to make sure that other hosts on the 566 link do not have stale ARP cache entries left over from some other 567 host that may previously have been using the same address. 569 2.5. Conflict Detection and Defense 571 Address collision detection is not limited to the address selection 572 phase, when a host is sending ARP probes. Address collision 573 detection is an ongoing process that is in effect for as long as a 574 host is using a Link-Local IPv4 address. At any time, if a host 575 receives an ARP packet (request *or* reply) on an interface where 576 the 'sender IP address' is the IP address the host has configured 577 for that interface, but the 'sender hardware address' does not match 578 the hardware address of that interface, then this is a conflicting 579 ARP packet, indicating an address collision. 581 A host MUST respond to a conflicting ARP packet as described in 582 either (a) or (b) below: 584 (a) Upon receiving a conflicting ARP packet, a host MAY elect to 585 immediately configure a new Link-Local IPv4 address as described 586 above, or 588 (b) If a host currently has active TCP connections or other reasons 589 to prefer to keep the same IPv4 address, and it has not seen any 590 other conflicting ARP packets recently (for IEEE 802, within the last 591 ten seconds) then it MAY elect to attempt to defend its address, by 592 recording the time that the conflicting ARP packet was received, and 593 then broadcasting one single ARP announcement, giving its own IP and 594 hardware addresses as the sender addresses of the ARP. Having done 595 this, the host can then continue to use the address normally without 596 any further special action. However, if this is not the first 597 conflicting ARP packet the host has seen, and the time recorded for 598 the previous conflicting ARP packet is recent (within ten seconds for 599 IEEE 802) then the host MUST immediately cease using this address and 600 configure a new Link-Local IPv4 address as described above. This is 601 necessary to ensure that two hosts do not get stuck in an endless 602 loop with both hosts trying to defend the same address. 604 A host MUST respond to conflicting ARP packets as described in either 605 (a) or (b) above. A host MUST NOT ignore conflicting ARP packets. 607 Forced address reconfiguration may be disruptive, causing TCP 608 connections to be broken. However, it is expected that such 609 disruptions will be rare, and if inadvertent address duplication 610 happens, then disruption of communication is inevitable, no matter 611 how the addresses were assigned. It is not possible for two 612 different hosts using the same IP address on the same network to 613 operate reliably. 615 Immediately configuring a new address as soon as the conflict is 616 detected is the best way to restore useful communication as quickly 617 as possible. The mechanism described above of broadcasting a single 618 ARP announcement to defend the address mitigates the problem 619 somewhat, by helping to improve the chance that one of the two 620 conflicting hosts may be able to retain its address. 622 All ARP packets (*replies* as well as requests) that contain a Link- 623 Local 'sender IP address' MUST be sent using link-layer broadcast 624 instead of link-layer unicast. This aids timely detection of 625 duplicate addresses. An example illustrating how this helps is given 626 in Section 4. 628 2.6. Address Usage and Forwarding Rules 630 A host implementing this specification has additional rules to 631 conform to, whether or not it has an interface configured with a 632 Link-Local IPv4 address. 634 2.6.1. Source Address Usage 636 Since each interface on a host may have a Link-Local IPv4 address in 637 addition to zero or more other addresses configured by other means 638 (e.g. manually or via a DHCP server), a host may have to make a 639 choice about what source address to use when it sends a packet or 640 initiates a TCP connection. 642 The host SHOULD use a routable address in preference to a Link-Local 643 IPv4 address except for communication to peers for which the host has 644 an existing TCP connection at the time in which the host obtained a 645 routable address configuration. For more details, see Section 1.7. 647 A multi-homed host needs to select an outgoing interface whether or 648 not the destination is a Link-Local IPv4 address. Details of that 649 process are beyond the scope of this specification. After selecting 650 an interface, the multi-homed host should send packets involving 651 Link-Local IPv4 addresses as specified in this document, as if the 652 selected interface were the host's only interface. See Section 3 for 653 further discussion of multi-homed hosts. 655 2.6.2. Forwarding Rules 657 Whichever interface is used, if the destination address is in the 658 169.254/16 prefix (including the 169.254.255.255 broadcast address), 659 then the sender MUST ARP for the destination address and then send 660 its packet directly to the destination on the same physical link. 661 This MUST be done whether the interface is configured with a Link- 662 Local or a routable IPv4 address. 664 In many network stacks, achieving this functionality may be as simple 665 as adding a routing table entry indicating that 169.254/16 is 666 directly reachable on the local link. 668 The host MUST NOT send a packet with a Link-Local IPv4 destination 669 address to any router for forwarding. 671 If the destination address is a unicast address outside the 672 169.254/16 prefix, then the host SHOULD use an appropriate routable 673 IPv4 source address, if it can. If for any reason the host chooses to 674 send the packet with a Link-Local IPv4 source address (e.g. no 675 routable address is available on the selected interface), then it 676 MUST ARP for the destination address and then send its packet, with a 677 Link-Local IPv4 source address and a routable destination IPv4 678 address, directly to its destination on the same physical link. The 679 host MUST NOT send the packet to any router for forwarding. 681 In the case of a device with a single interface and only a Link-Local 682 IPv4 address, this requirement can be paraphrased as "ARP for 683 everything". 685 In many network stacks, achieving this "ARP for everything" behaviour 686 may be as simple as having no primary IP router configured, having 687 the primary IP router address configured to 0.0.0.0, or having the 688 primary IP router address set to be the same as the host's own Link- 689 Local IPv4 address. For suggested behavior in multi-homed hosts, see 690 Section 3. 692 2.7. Link-Local Packets Are Not Forwarded 694 A sensible default for applications which are sending from a Link- 695 Local IPv4 address is to explicitly set the IPv4 TTL to 1. This is 696 not appropriate in all cases as some applications may require that 697 the IPv4 TTL be set to other values. 699 An IPv4 packet whose source and/or destination address is in the 700 169.254/16 prefix MUST NOT be sent to any router for forwarding, and 701 any network device receiving such a packet MUST NOT forward it, 702 regardless of the TTL in the IPv4 header. Similarly, a router or 703 other host MUST NOT indiscriminately answer all ARP Requests for 704 addresses in the 169.254/16 prefix. A router may of course answer 705 ARP Requests for one or more Link-Local IPv4 address(es) that it has 706 legitimately claimed for its own use according to the claim-and- 707 defend protocol described in this document. 709 This restriction also applies to multicast packets. IPv4 packets with 710 a Link-Local source address MUST NOT be forwarded off the local link 711 even if they have a multicast destination address. 713 2.8. Link-Local Packets are Local 715 The non-forwarding rule means that hosts may assume that all 716 169.254/16 destination addresses are "on-link" and directly 717 reachable. The 169.254/16 address prefix MUST NOT be subnetted. 718 This specification utilizes ARP-based address collision detection, 719 which functions by broadcasting on the local subnet. Since such 720 broadcasts are not forwarded, were subnetting to be allowed then 721 address conflicts could remain undetected. 723 This does not mean that Link-Local devices are forbidden from any 724 communication outside the local link. IP hosts that implement both 725 Link-Local and conventional routable IPv4 addresses may still use 726 their routable addresses without restriction as they do today. 728 2.9. Higher-Layer Protocol Considerations 730 Similar considerations apply at layers above IP. 732 For example, designers of Web pages (including automatically 733 generated web pages) SHOULD NOT contain links with embedded Link- 734 Local IPv4 addresses if those pages are viewable from hosts outside 735 the local link where the addresses are valid. 737 As Link-Local IPv4 addresses may change at any time and have limited 738 scope, storing Link-Local IPv4 addresses in the DNS is not well 739 understood and is NOT RECOMMENDED. 741 2.10. Privacy Concerns 743 Another reason to restrict leakage of Link-Local IPv4 addresses 744 outside the local link is privacy concerns. If Link-Local IPv4 745 addresses are derived from a hash of the MAC address, some argue that 746 they could be indirectly associated with an individual, and thereby 747 used to track that individual's activities. Within the local link 748 the hardware addresses in the packets are all directly observable, so 749 as long as Link-Local IPv4 addresses don't leave the local link they 750 provide no more information to an intruder than could be gained by 751 direct observation of hardware addresses. 753 2.11. Interaction between DHCPv4 client and IPv4ll state machines 755 A device that implements both IPv4ll and a DHCPv4 client should not 756 alter the behavior of the DHCPv4 client to accommodate IPv4 Link- 757 Local configuration. In particular configuration of an IPv4 Link- 758 Local address, whether or not a DHCP server is currently responding, 759 is not sufficient reason to unconfigure a valid DHCP lease, to stop 760 the DHCP client from attempting to acquire a new IP address, to 761 change DHCP timeouts or to change the behaviour of the DHCP state 762 machine in any other way. 764 Several early implementations of IPv4 link-local have modified the 765 DHCP state machine in an attempt to make IPv4 link-local more 766 reliable, and the field experience we have gained from this has 767 shown that it does not work - reliability of DHCP service is 768 significantly reduced. If increased reliability of IPv4 link-local 769 is desired, we recommend that the IPv4 link-local state machine track 770 the DHCP client state machine and, in cases where it is not certain 771 that the DHCP-assigned address is correct, the IPv4ll state machine 772 acquire an IPv4ll address without causing the DHCP state machine to 773 relinquish its address. 775 Further discussion of this issue is provided in [DNAv4]. 777 3. Considerations for Multiple Interfaces 779 These considerations apply whenever a host has multiple IP addresses 780 whether or not it has multiple physical interfaces. Other examples 781 of multiple interfaces include different logical endpoints (tunnels, 782 virtual private networks etc.) and multiple logical networks on the 783 same physical medium. This is often referred to as "multihoming". 785 Hosts which have more than one active interface and elect to 786 implement dynamic configuration of Link-Local IPv4 addresses on one 787 or more of those interfaces will face various problems. This section 788 lists these problems but does no more than indicate how one might 789 solve them. At the time of this writing, there is no silver bullet 790 which solves these problems in all cases, in a general way. 791 Implementors must think through these issues before implementing the 792 protocol specified in this document on a system which may have more 793 than one active interface as part of a TCP/IP stack capable of 794 multihoming. 796 3.1. Scoped addresses 798 A host may be attached to more than one network at the same time. It 799 would be nice if there was a single address space used in every 800 network, but this is not the case. Addresses used in one network, be 801 it a network behind a NAT or a link on which Link-Local IPv4 802 addresses are used, cannot be used in another network and have the 803 same effect. 805 It would also be nice if addresses were not exposed to applications, 806 but they are. Most software using TCP/IP which await messages 807 receives from any interface at a particular port number, for a 808 particular transport protocol. Applications are generally only aware 809 (and care) that they have received a message. The application knows 810 the source address of the sender to whom the application will reply. 812 The first scoped address problem is source address selection. A 813 multihomed host has more than one address. Which address should be 814 used as the source address when sending to a particular destination? 815 This answer is usually answered by referring to a routing table, 816 which expresses which interface (with which address) to send, and how 817 to send (should one forward to a router, or send directly). The 818 choice is made complicated by scoped addresses because the address 819 range in which the destination lies may be ambiguous. The table may 820 not be able to yield a good answer. This problem is bound up with 821 next-hop selection, which is discussed in Section 3.2. 823 The second scoped address problem arises from scoped parameters 824 leaking outside their scope. This is discussed in Section 7. 826 It is possible to overcome these problems. One way is to expose scope 827 information to applications such that they are always aware of what 828 scope a peer is in. This way, the correct interface could be 829 selected, and a safe procedure could be followed with respect to 830 forwarding addresses and other scoped parameters. There are other 831 possible approaches. None of these methods have been standardized for 832 IPv4 nor are they specified in this document. A good API design 833 could mitigate the problems, either by exposing address scopes to 834 'scoped-address aware' applications or by cleverly encapsulating the 835 scoping information and logic so that applications do the right thing 836 without being aware of address scoping. 838 An implementer could undertake to solve these problems, but cannot 839 simply ignore them. With sufficient experience, it is hoped that 840 specifications will emerge explaining how to overcome scoped address 841 multihoming problems. 843 3.2. Address Ambiguity 845 This is a core problem with respect to Link-Local IPv4 addresses 846 configured on more than one interface. What should a host do when it 847 needs to send to Link-Local destination L and L can be resolved using 848 ARP on more than one link? 850 One possibility is to support this only in the case where the 851 application specifically expresses which interface to send from. 853 There no standard or obvious solution to this problem. Existing 854 application software written for the Internet protocol suite is 855 largely incapable of dealing with address ambiguity. This does not 856 preclude an implementer from finding a solution, writing applications 857 which are able to use it, and providing a host which can support 858 dynamic configuration of Link-Local IPv4 addresses on more than one 859 interface. This solution will almost surely not be generally 860 applicable to existing software and transparent to higher layers, 861 however. 863 3.3. Interaction with Hosts with Routable Addresses 865 Attention is paid in this specification to transition from the use of 866 Link-Local IPv4 addresses to routable addresses (see Section 1.5). 867 The intention is to allow a host with a single interface to first 868 support Link-Local configuration then gracefully transition to the 869 use of a routable address. Since the host transitioning to the use of 870 a routable address will not advertise scoped address information, the 871 scoped address issues described in Section 3.1 will apply. A host 872 which conforms to this specification will know that a Link-Local IPv4 873 destination must be reached by forwarding to the destination, not to 874 a router, even if the host is sending from a routable address. 876 A host with a Link-Local IPv4 address may send to a destination which 877 does not have a Link-Local IPv4 address. If the host is not 878 multihomed, the procedure is simple and unambiguous: Using ARP and 879 forwarding directly to on-link destinations is the default route. If 880 the host is multihomed, however, the routing policy is more complex, 881 especially if one of the interfaces is configured with a routable 882 address and the default route is (sensibly) directed at a router 883 accessible through that interface. The following example illustrates 884 this problem and provides a common solution to it. 886 i1 +---------+ i2 i3 +-------+ 887 ROUTER-------= HOST1 =---------= HOST2 | 888 link1 +-------=-+ link2 +-------+ 890 In the figure above, HOST1 is connected to link1 and link2. Interface 891 i1 is configured with a routable address, while i2 is a Link-Local 892 IPv4 address. HOST1 has its default route set to ROUTER's address, 893 through i1. HOST1 will route to destinations in 169.254/16 to i2, 894 sending directly to the destination. 896 HOST2 has a configured (non-Link-Local) IPv4 address assigned to i3. 898 Using a name resolution or service discovery protocol HOST1 can 899 discover HOST2's address. Since HOST2's address is not in 169.254/16, 900 HOST1's routing policy will send datagrams to HOST2 via i1, to the 901 ROUTER. Unless there is a route from ROUTER to HOST2, the datagrams 902 sent from HOST1 to HOST2 will not reach it. 904 One solution to this problem is for a host to attempt to reach any 905 host locally (using ARP) for which it receives an unreachable ICMP 906 error message (ICMP message codes 0, 1, 6 or 7, see [RFC792]). The 907 host tries all its attached links in a round robin fashion. This has 908 been implemented successfully for some IPv6 hosts, to circumvent 909 exactly this problem. In terms of this example, HOST1 upon failing to 910 reach HOST2 via the ROUTER, will attempt to forward to HOST2 via i2 911 and succeed. 913 It may also be possible to overcome this problem using techniques 914 described in section 3.2, or other means not discussed here. This 915 specification does not provide a standard solution, nor does it 916 preclude implementers from supporting multihomed configurations, 917 provided that they address the concerns in this section for the 918 applications which will be supported on the host. 920 3.4. Unintentional Autoimmunity 922 Care must be taken if a multihomed host can support more than one 923 interface on the same link, all of which support Link-Local IPv4 924 autoconfiguration. If these interfaces attempt to allocate the same 925 address, they will defend the host against itself - causing the 926 claiming algorithm to fail. The simplest solution to this problem is 927 to run the algorithm independently on each interface configured with 928 Link-Local IPv4 addresses. 930 In particular, ARP packets which appear to claim an address which is 931 assigned to a specific interface, indicate conflict only if they are 932 received on that interface and their hardware address is of some 933 other interface. 935 If a host has two interfaces on the same network, then claiming and 936 defending on those interfaces must ensure that they end up with 937 different addresses just as if they were on different hosts. 939 4. Healing of Network Partitions 941 Hosts on disjoint network links may configure the same Link-Local 942 IPv4 address. If these separate network links are later joined or 943 bridged together, then there may be two hosts which are now on the 944 same link, trying to use the same address. When either host attempts 945 to communicate with any other host on the network, it will at some 946 point broadcast an ARP packet which will enable the hosts in question 947 to detect that there is an address conflict. 949 When these address conflicts are detected, the subsequent forced 950 reconfiguration may be disruptive, causing TCP connections to be 951 broken. However, it is expected that such disruptions will be rare. 952 It should be relatively uncommon for networks to be joined while 953 hosts on those networks are active. Also, 65024 addresses are 954 available for Link-Local IPv4 use, so even when two small networks 955 are joined, the chance of collision for any given host is fairly 956 small. 958 When joining two large networks (defined as networks with a 959 substantial number of hosts per segment) there is a greater chance of 960 collision. In such networks, it is likely that the joining of 961 previously separated segments will result in one or more hosts 962 needing to change their Link-Local IPv4 address, with subsequent loss 963 of TCP connections. In cases where separation and re-joining is 964 frequent, as in remotely bridged networks, this could prove 965 disruptive. However, unless the number of hosts on the joined 966 segments is very large, the traffic resulting from the join and 967 subsequent address conflict resolution will be small. 969 Sending ARP replies that have Link-Local sender IPv4 addresses via 970 broadcast instead of unicast ensures that these conflicts can be 971 detected as soon as they become potential problems, but no sooner. 972 For example, if two disjoint network links are joined, where hosts A 973 and B have both configured the same Link-Local address, X, they can 974 remain in this state until A, B or some other host attempts to 975 initiate communication. If some other host C now sends an ARP request 976 for address X, and hosts A and B were to both reply with conventional 977 unicast ARP replies, then host C might be confused, but A and B still 978 wouldn't know there is a problem because neither would have seen the 979 other's packet. Sending these replies via broadcast allows A and B 980 see each other's conflicting ARP packets and respond accordingly. 982 Note that sending periodic gratuitous ARPs in an attempt to detect 983 these conflicts sooner is not necessary, wastes network bandwidth, 984 and may actually be detrimental. For example, if the network links 985 were joined only briefly, and were separated again before any new 986 communication involving A or B were initiated, then the temporary 987 conflict would have been benign and no forced reconfiguration would 988 have been required. Triggering an unnecessary forced reconfiguration 989 in this case would not serve any useful purpose. Hosts SHOULD NOT 990 send periodic gratuitous ARPs. 992 5. Security Considerations 994 The use of IPv4 Link-Local Addresses may open a network host to new 995 attacks. In particular, a host that previously did not have an IP 996 address, and no IP stack running, was not susceptible to IP-based 997 attacks. By configuring a working address, the host may now be 998 vulnerable to IP-based attacks. 1000 The ARP protocol [RFC826] is insecure. A malicious host may send 1001 fraudulent ARP packets on the network, interfering with the correct 1002 operation of other hosts. For example, it is easy for a host to 1003 answer all ARP requests with replies giving its own hardware address, 1004 thereby claiming ownership of every address on the network. 1006 NOTE: The existence of local links without physical security, such as 1007 LANs with attached wireless base stations, means that expecting all 1008 local links to be secure enough that normal precautions can be 1009 dispensed with is an extremely dangerous practice, which will expose 1010 users to considerable risks. 1012 A host implementing Link-Local IPv4 configuration has the additional 1013 vulnerability to selective reconfiguration and disruption. It is 1014 possible for an on-link attacker to issue ARP packets which would 1015 cause a host to break all its connections by switching to a new 1016 address. The attacker could force the host implementing Link-Local 1017 IPv4 configuration to select certain addresses, or prevent it from 1018 ever completing address selection. This is a distinct threat from 1019 that posed by spoofed ARPs, described in the preceding paragraph. 1021 Implementations and users should also note that a node that gives up 1022 an address and reconfigures, as required by section 2.5, allows the 1023 possibility that another node can easily successfully hijack existing 1024 TCP connections. Before abandoning an address due to a conflict, 1025 hosts SHOULD actively attempt to reset any existing connections using 1026 that address. 1028 Implementers are advised that the Internet Protocol architecture 1029 expects every networked device or host must implement security which 1030 is adequate to protect the resources to which the device or host has 1031 access, including the network itself, against known or credible 1032 threats. Even though use of Link-Local IPv4 addresses may reduce the 1033 number of threats to which a device is exposed, implementers of 1034 devices supporting the Internet Protocol must not assume that a 1035 customer's local network is free from security risks. 1037 While there may be particular kinds of devices, or particular 1038 environments, for which the security provided by the network is 1039 adequate to protect the resources that are accessible by the device, 1040 it would be misleading to make a general statement to the effect that 1041 the requirement to provide security is reduced for devices using 1042 Link-Local IPv4 addresses as a sole means of access. 1044 In all cases, whether or not Link-Local IPv4 addresses are used, it 1045 is necessary for implementers of devices supporting the Internet 1046 Protocol to analyze the known and credible threats to which a 1047 specific host or device might be subjected, and to the extent that it 1048 is feasible, to provide security mechanisms which ameliorate or 1049 reduce the risks associated with such threats. 1051 6. Application Programming Considerations 1053 Use of Link-Local IPv4 autoconfigured addresses presents additional 1054 challenges to writers of applications and may result in existing 1055 application software failing. 1057 6.1. Address Changes, Failure and Recovery 1059 Link-Local IPv4 addresses used by an application may change over 1060 time. Some application software encountering an address change will 1061 completely fail. For example, client TCP connections will fail, 1062 servers whose addresses change will have to be rediscovered, blocked 1063 reads and writes will exit with an error condition, and so on. 1065 Vendors producing application software which will be used on IP 1066 implementations supporting Link-Local IPv4 address configuration 1067 SHOULD detect and cope with address change events. Vendors producing 1068 IPv4 implementations supporting Link-Local IPv4 address configuration 1069 SHOULD expose address change events to applications. 1071 6.2. Limited Forwarding of Locators 1073 Link-Local IPv4 addresses MUST NOT be forwarded via an application 1074 protocol (for example in a URL), to a destination which is not Link- 1075 Local, on the same link. This is discussed further in Section 2.9 and 1076 3. 1078 Existing distributed application software which forwards address 1079 information may fail. For example, FTP [RFC 959] passive mode 1080 transmits the IPv4 address of the client. Assume a client starts up 1081 and obtains its *passive* IPv4 configuration at a time when the host 1082 has only a Link-Local address. Later, the host gets a global IP 1083 address configuration (for one of its interfaces). The client uses 1084 this global IPv4 address to contact an FTP server off of the local 1085 link for which it had (or still has) a Link-Local IPv4 address 1086 configured. If the FTP client transmits its passive IPv4 1087 configuration to the FTP server, the FTP server will be unable to 1088 reach the FTP client. The passive FTP operation will fail. 1090 6.3. Address Ambiguity 1092 Application software run on a multihomed host which supports Link- 1093 Local IPv4 address configuration on more than one interface may fail. 1094 This is because application software assumes that an IPv4 address is 1095 unambiguous, that it can refer to only one host. Link-Local IPv4 1096 addresses are unique only on a single link. A host attached to 1097 multiple links can easily encounter a situation where the same 1098 address is present on more than one interface, or first on one 1099 interface, later on another; in any case associated with more than 1100 one host. Most existing software is not prepared for this ambiguity. 1101 In the future, application programming interfaces could be developed 1102 to prevent this problem. This issue is discussed in Section 3. 1104 7. Router Considerations 1106 A router MUST NOT forward a packet with a Link-Local IPv4 source or 1107 destination address, irrespective of the router's default route 1108 configuration or routes obtained from dynamic routing protocols. 1110 A router which receives a packet with a Link-Local IPv4 destination 1111 address on an interface which either has no Link-Local IPv4 address 1112 configured or is configured with a different address than the 1113 destination of the packet MUST NOT forward the packet. This prevents 1114 forwarding of packets back onto the network segment from which they 1115 originated, or to any other segment. 1117 8. IANA Considerations 1119 The IANA has allocated the prefix 169.254/16 for the use described in 1120 this document. The first and last 256 addresses in this range 1121 (169.254.0.x and 169.254.255.x) are allocated by Standards Action, as 1122 defined in BCP 26. No other IANA services are required by this 1123 document. 1125 9. Constants 1127 The following timing constants are used in this protocol. 1129 PROBE_MIN 1 second 1130 PROBE_MAX 2 seconds 1131 NUM_PROBES 3 1132 MAX_COLLISIONS 10 1133 RATE_LIMIT_INTERVAL 60 seconds 1135 10. References 1137 10.1. Normative References 1139 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 1140 September 1981. 1142 [RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or- 1143 Converting Network Addresses to 48-bit Ethernet Address for 1144 Transmission on Ethernet Hardware", STD 37, RFC 826, November 1145 1982. 1147 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1148 Levels", RFC 2119, March 1997. 1150 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 1151 Considerations Section in RFCs", BCP 26, RFC 2434, October 1152 1998. 1154 10.2. Informative References 1156 [802] IEEE Standards for Local and Metropolitan Area Networks: 1157 Overview and Architecture, ANSI/IEEE Std 802, 1990. 1159 [802.1d] ISO/IEC 15802-3 Information technology - Telecommunications 1160 and information exchange between systems - Local and 1161 metropolitan area networks - Common specifications - Part 3: 1162 Media access Control (MAC) Bridges, (also ANSI/IEEE Std 1163 802.1D-1998), 1998. 1165 [802.3] ISO/IEC 8802-3 Information technology - Telecommunications and 1166 information exchange between systems - Local and metropolitan 1167 area networks - Common specifications - Part 3: Carrier Sense 1168 Multiple Access with Collision Detection (CSMA/CD) Access 1169 Method and Physical Layer Specifications, (also ANSI/IEEE Std 1170 802.3- 1996), 1996. 1172 [802.5] ISO/IEC 8802-5 Information technology - Telecommunications and 1173 information exchange between systems - Local and metropolitan 1174 area networks - Common specifications - Part 5: Token ring 1175 access method and physical layer specifications, (also 1176 ANSI/IEEE Std 802.5-1998), 1998. 1178 [802.11] Information technology - Telecommunications and information 1179 exchange between systems - Local and metropolitan area 1180 networks - Specific Requirements Part 11: Wireless LAN Medium 1181 Access Control (MAC) and Physical Layer (PHY) Specifications, 1182 IEEE Std. 802.11-1999, 1999. 1184 [1394] Standard for a High Performance Serial Bus. Institute of 1185 Electrical and Electronic Engineers, IEEE Standard 1394-1995, 1186 1995. 1188 [RFC1918] Y. Rekhter et.al., "Address Allocation for Private Internets", 1189 RFC 1918, February 1996. 1191 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 1192 March 1997. 1194 [RFC2462] S. Thomson and T. Narten, "IPv6 Stateless Address 1195 Autoconfiguration", RFC 2462, December 1998. 1197 [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with 1198 the IP Network Address Translator", RFC 3027, January 2001. 1200 [DNAv4] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", 1201 draft-ietf-dhc-dna-ipv4-05.txt, Internet draft (work in 1202 progress), February 2004. 1204 [LLMNR] Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast Name 1205 Resolution (LLMNR)", draft-ietf-dnsext-mdns-29.txt, Internet 1206 draft (work in progress), January 2004. 1208 [USB] Universal Serial Bus Implementers Forum 1210 [X10] X10 Ltd. 1212 Acknowledgments 1214 We would like to thank (in alphabetical order) Jim Busse, Pavani 1215 Diwanji, Donald Eastlake 3rd, Robert Elz, Peter Ford, Spencer 1216 Giacalone, Josh Graessley, Myron Hattig, Hugh Holbrook, Christian 1217 Huitema, Richard Johnson, Kim Yong-Woon, Mika Liljeberg, Rod Lopez, 1218 Keith Moore, Satish Mundra, Thomas Narten, Erik Nordmark, Philip Nye, 1219 Howard Ridenour, Daniel Senie, Dieter Siegmund, Valery Smyslov and 1220 Ryan Troll for their contributions. 1222 Authors' Addresses 1224 Stuart Cheshire 1225 Apple Computer, Inc. 1226 1 Infinite Loop 1227 Cupertino 1228 California 95014, USA 1230 Phone: +1 408 974 3207 1231 EMail: rfc@stuartcheshire.org 1233 Bernard Aboba 1234 Microsoft Corporation 1235 One Microsoft Way 1236 Redmond, WA 98052 1238 Phone: +1 425 706 6605 1239 EMail: bernarda@microsoft.com 1241 Erik Guttman 1242 Sun Microsystems 1243 Eichhoelzelstr. 7 1244 74915 Waibstadt Germany 1246 Phone: +49 7263 911 701 1247 Email: erik.guttman@sun.com 1249 Appendix A - Prior Implementations 1251 A.1. Apple Mac OS 8.x and 9.x. 1253 Mac OS chooses the IP address on a pseudo-random basis. The selected 1254 address is saved in persistent storage for continued use after 1255 reboot, when possible. 1257 Mac OS sends nine DHCPDISCOVER packets, with an interval of two 1258 seconds between packets. If no response is received from any of these 1259 requests (18 seconds), it will autoconfigure. 1261 Upon finding that a selected address is in use, Mac OS will select a 1262 new random address and try again, at a rate limited to no more than 1263 one attempt every two seconds. 1265 Autoconfigured Mac OS systems check for the presence of a DHCP server 1266 every five minutes. If a DHCP server is found but Mac OS is not 1267 successful in obtaining a new lease, it keeps the existing 1268 autoconfigured IP address. If Mac OS is successful at obtaining a 1269 new lease, it drops all existing connections without warning. This 1270 may cause users to lose sessions in progress. Once a new lease is 1271 obtained, Mac OS will not allocate further connections using the 1272 autoconfigured IP address. 1274 Mac OS systems do not send packets addressed to a Link-Local address 1275 to the default gateway if one is present; these addresses are always 1276 resolved on the local segment. 1278 Mac OS systems by default send all outgoing unicast packets with a 1279 TTL of 255. All multicast and broadcast packets are also sent with a 1280 TTL of 255 if they have a source address in the 169.254/16 prefix. 1282 Mac OS implements media sense where the hardware (and driver 1283 software) supports this. As soon as network connectivity is 1284 detected, a DHCPDISCOVER will be sent on the interface. This means 1285 that systems will immediately transition out of autoconfigured mode 1286 as soon as connectivity is restored. 1288 A.2. Apple Mac OS X Version 10.2 1290 Mac OS X chooses the IP address on a pseudo-random basis. The 1291 selected address is saved in memory so that it can be re-used during 1292 subsequent autoconfiguration attempts during a single boot of the 1293 system. 1295 Autoconfiguration of a Link-Local address depends on the results of 1296 the DHCP process. DHCP sends two packets, with timeouts of one and 1297 two seconds. If no response is received (three seconds), it begins 1298 autoconfiguration. DHCP continues sending packets in parallel for a 1299 total time of 60 seconds. 1301 At the start of autoconfiguration, it generates 10 unique random IP 1302 addresses, and probes each one in turn for 2 seconds. It stops 1303 probing after finding an address that is not in use, or the list of 1304 addresses is exhausted. 1306 If DHCP is not successful, it waits five minutes before starting over 1307 again. Once DHCP is successful, the autoconfigured Link-Local 1308 address is given up. The Link-Local subnet, however, remains 1309 configured. 1311 Autoconfiguration is only attempted on a single interface at any 1312 given moment in time. 1314 Mac OS X ensures that the connected interface with the highest 1315 priority is associated with the Link-Local subnet. Packets addressed 1316 to a Link-Local address are never sent to the default gateway, if one 1317 is present. Link-local addresses are always resolved on the local 1318 segment. 1320 Mac OS X implements media sense where the hardware and driver support 1321 it. When the network media indicates that it has been connected, the 1322 autoconfiguration process begins again, and attempts to re-use the 1323 previously assigned Link-Local address. When the network media 1324 indicates that it has been disconnected, the system waits four 1325 seconds before de-configuring the Link-Local address and subnet. If 1326 the connection is restored before that time, the autoconfiguration 1327 process begins again. If the connection is not restored before that 1328 time, the system chooses another interface to autoconfigure. 1330 Mac OS X by default sends all outgoing unicast packets with a TTL of 1331 255. All multicast and broadcast packets are also sent with a TTL of 1332 255 if they have a source address in the 169.254/16 prefix. 1334 A.3. Microsoft Windows 98/98SE 1336 Windows 98/98SE systems choose their Link-Local IPv4 address on a 1337 pseudo-random basis. This ensures that systems rebooting will obtain 1338 the same autoconfigured address, unless a conflict is detected. The 1339 address selection algorithm is based on computing a hash on the 1340 interface's MAC address, so that a large collection of hosts should 1341 obey the uniform probability distribution in choosing addresses 1342 within the 169.254/16 address space. 1344 When in INIT state, the Windows 98/98SE DHCP Client sends out a total 1345 of 4 DHCPDISCOVERs, with an inter-packet interval of 6 seconds. When 1346 no response is received after all 4 packets (24 seconds), it will 1347 autoconfigure an address. 1349 The autoconfigure retry count for Windows 98/98SE systems is 10. 1350 After trying 10 autoconfigured IPv4 addresses, and finding all are 1351 taken, the host will boot without an IPv4 address. 1353 Autoconfigured Windows 98/98SE systems check for the presence of a 1354 DHCP server every five minutes. If a DHCP server is found but 1355 Windows 98 is not successful in obtaining a new lease, it keeps the 1356 existing autoconfigured Link-Local IPv4 address. If Windows 98/98SE 1357 is successful at obtaining a new lease, it drops all existing 1358 connections without warning. This may cause users to lose sessions in 1359 progress. Once a new lease is obtained, Windows 98/98SE will not 1360 allocate further connections using the autoconfigured Link-Local IPv4 1361 address. 1363 Windows 98/98SE systems with a Link-Local IPv4 address do not send 1364 packets addressed to a Link-Local IPv4 address to the default gateway 1365 if one is present; these addresses are always resolved on the local 1366 segment. 1368 Windows 98/98SE systems by default send all outgoing unicast packets 1369 with a TTL of 128. TTL configuration is performed by setting the 1370 Windows Registry Key 1371 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services:\Tcpip\ 1372 Parameters\DefaultTTL of type REG_DWORD to the appropriate value. 1373 However, this default TTL will apply to all packets. While this 1374 facility could be used to set the default TTL to 255, it cannot be 1375 used to set the default TTL of Link-Local IPv4 packets to one (1), 1376 while allowing other packets to be sent with a TTL larger than one. 1378 Windows 98/98SE systems do not implement media sense. This means that 1379 network connectivity issues (such as a loose cable) may prevent a 1380 system from contacting the DHCP server, thereby causing it to auto- 1381 configure. When the connectivity problem is fixed (such as when the 1382 cable is re-connected) the situation will not immediately correct 1383 itself. Since the system will not sense the re-connection, it will 1384 remain in autoconfigured mode until an attempt is made to reach the 1385 DHCP server. 1387 The DHCP server included with Windows 98SE Internet Connection 1388 Sharing (ICS) (a NAT implementation) allocates out of the 192.168/16 1389 private address space by default. 1391 However, it is possible to change the allocation prefix via a 1392 registry key, and no checks are made to prevent allocation out of the 1393 Link-Local IPv4 prefix. When configured to do so, Windows 98SE ICS 1394 will NAT packets from the Link-Local IPv4 prefix off the local link. 1395 Windows 98SE ICS does not automatically route for the Link-Local IPv4 1396 prefix, so that hosts obtaining addresses via DHCP cannot communicate 1397 with autoconfigured-only devices. 1399 Other home gateways exist that allocate addresses out of the Link- 1400 Local IPv4 prefix by default. Windows 98/98SE systems can use a 1401 169.254/16 Link-Local IPv4 address as the source address when 1402 communicating with non-Link-Local hosts. However, Windows 98/98SE 1403 does not support router solicitation/advertisement. This means that 1404 Windows 98/98SE systems will typically not be able to discover a 1405 default gateway when in autoconfigured mode. 1407 A.4. Windows XP, 2000 and ME 1409 The autoconfiguration behavior of Windows XP, Windows 2000 and 1410 Windows ME systems is identical to Windows 98/98SE except in the 1411 following respects: 1413 Media Sense 1414 Router Discovery 1415 Silent RIP 1417 Windows XP, 2000 and ME implement media sense. As soon as network 1418 connectivity is detected, a DHCPREQUEST or DHCPDISCOVER will be sent 1419 on the interface. This means that systems will immediately 1420 transition out of autoconfigured mode as soon as connectivity is 1421 restored. 1423 Windows XP, 2000 and ME also support router discovery, although it is 1424 turned off by default. Windows XP and 2000 also support a RIP 1425 listener. This means that it is possible to discover a default 1426 gateway while in autoconfigured mode. 1428 ICS on Windows XP/2000/ME behaves identically to Windows 98SE with 1429 respect to address allocation and NATing of Link-Local prefixes. 1431 Intellectual Property Statement 1433 The IETF has been notified of intellectual property rights claimed in 1434 regard to some or all of the specification contained in this 1435 document. For more information consult the online list of claimed 1436 rights. 1438 The IETF takes no position regarding the validity or scope of any 1439 intellectual property or other rights that might be claimed to 1440 pertain to the implementation or use of the technology described in 1441 this document or the extent to which any license under such rights 1442 might or might not be available; neither does it represent that it 1443 has made any effort to identify any such rights. Information on the 1444 IETF's procedures with respect to rights in standards-track and 1445 standards-related documentation can be found in BCP-11. Copies of 1446 claims of rights made available for publication and any assurances of 1447 licenses to be made available, or the result of an attempt made to 1448 obtain a general license or permission for the use of such 1449 proprietary rights by implementers or users of this specification can 1450 be obtained from the IETF Secretariat. 1452 The IETF invites any interested party to bring to its attention any 1453 copyrights, patents or patent applications, or other proprietary 1454 rights which may cover technology that may be required to practice 1455 this standard. Please address the information to the IETF Executive 1456 Director. 1458 Full Copyright Statement 1460 Copyright (C) The Internet Society (2004). All Rights Reserved. 1461 This document and translations of it may be copied and furnished to 1462 others, and derivative works that comment on or otherwise explain it 1463 or assist in its implementation may be prepared, copied, published 1464 and distributed, in whole or in part, without restriction of any 1465 kind, provided that the above copyright notice and this paragraph are 1466 included on all such copies and derivative works. However, this 1467 document itself may not be modified in any way, such as by removing 1468 the copyright notice or references to the Internet Society or other 1469 Internet organizations, except as needed for the purpose of 1470 developing Internet standards in which case the procedures for 1471 copyrights defined in the Internet Standards process must be 1472 followed, or as required to translate it into languages other than 1473 English. The limited permissions granted above are perpetual and 1474 will not be revoked by the Internet Society or its successors or 1475 assigns. This document and the information contained herein is 1476 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1477 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1478 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1479 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1480 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1482 Open Issues 1484 Open issues with this specification are tracked on the following web 1485 site: 1487 http://www.drizzle.com/~aboba/ZEROCONF/issues.html 1489 Expiration Date 1491 This memo is filed as , and 1492 expires August 24, 2004.