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