idnits 2.17.1 draft-ietf-zeroconf-ipv4-linklocal-04.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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2131]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2001) is 8319 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1394' ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) -- Possible downref: Non-RFC (?) normative reference: ref. 'USB' -- Possible downref: Non-RFC (?) normative reference: ref. 'X10' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Stuart Cheshire 2 Document: draft-ietf-zeroconf-ipv4-linklocal-04.txt Apple Computer 3 Expires 19th January 2002 Bernard Aboba 4 Microsoft 5 19th July 2001 7 Dynamic Configuration of IPv4 Link-Local Addresses 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), 16 its areas, and its working groups. Note that other groups may 17 also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Distribution of this memo is unlimited. 32 Abstract 34 As the Internet Protocol continues to grow in popularity, it becomes 35 increasingly valuable to be able to use familiar IP tools such as ftp 36 not only for global communication, but for local communication as 37 well. For example, two people with laptop computers with built-in 38 wireless Ethernet may meet and wish to exchange files. It is 39 desirable for these people to be able to use IP application software 40 without the inconvenience of having to manually configure static IP 41 addresses or set up a DHCP server [RFC 2131]. 43 This document describes a method by which a host may automatically 44 configure an interface with an IPv4 address in the 169.254/16 prefix 45 that is valid for link-local communication on that interface. This 46 is especially valuable in environments where no other configuration 47 mechanism is available. 49 Microsoft Windows 98 (and later) and Mac OS 8.5 (and later) already 50 implement versions of this functionality. This document standardizes 51 this protocol and simplifies it in one important way -- in previous 52 implementations, link-local addresses were only available after a 53 host had tried and failed to contact a DHCP server. This standard 54 removes that restriction, making link-local addresses available all 55 the time, independent of DHCP. 57 Table of Contents 59 1. Introduction..................................................2 60 1.1 Conventions and Terminology Used in this Document.............3 61 1.2 Applicability.................................................3 62 1.3 Issues with Autoconfiguration.................................4 63 1.4 169.254/16 Not To Be Used for Other Purposes..................4 64 1.5 Supporting Multiple Addresses per Interface...................5 65 1.6 Supporting Multiple Interfaces................................5 66 2. IPv4 Link-Local Address Selection, Defense and Delivery.......6 67 2.1 Selecting a Link-Local Address................................6 68 2.2 Claiming a Link-Local Address.................................7 69 2.3 Address Collision Detection and Address Defense...............8 70 2.4 Source Address Selection......................................9 71 2.5 Link-Local Addresses Are Not Forwarded.......................10 72 3. Considerations for Multiple Interfaces.......................11 73 3.1 Link-Local Addressing on Only One Interface..................11 74 3.2 Single Shared Link-Local Address.............................12 75 3.3 Different Link-Local Address for Each Interface..............12 76 3.4 Collision Detection for Multi-Homed Hosts....................14 77 4. Considerations for Joining of Previously Separate Networks...15 78 5. Security Considerations......................................16 79 6. IANA Considerations..........................................16 80 7. Acknowledgements.............................................16 81 8. Intellectual Property.........................................17 82 9. Copyright....................................................17 83 10. References...................................................18 84 11. Authors' Addresses...........................................19 85 Appendix. Prior Implementations..................................19 86 A.1 Apple Mac OS 8.x and 9.x.....................................19 87 A.2 Microsoft Windows 98/98SE....................................20 88 A.3 Windows 2000 and Windows ME..................................21 90 1. Introduction 92 As the Internet Protocol continues to grow in popularity, it becomes 93 increasingly valuable to be able to use familiar IP tools such as ftp 94 not only for global communication, but for local communication as 95 well. For example, two people with laptop computers with built-in 96 wireless Ethernet may meet and wish to exchange files. It is 97 desirable for these people to be able to use IP application software 98 without the inconvenience of having to manually configure static IP 99 addresses or set up a DHCP server [RFC 2131]. 101 This document describes a method by which a host may automatically 102 configure an interface with an IPv4 address in the 169.254/16 prefix 103 that is valid for link-local communication on that interface. This 104 is especially valuable in environments where no other configuration 105 mechanism is available. The IPv4 network 169.254/16 is registered 106 with the IANA for this purpose. Allocation of link-local IPv6 107 addresses is described in "IPv6 Stateless Address Autoconfiguration" 108 [RFC 2462]. 110 Microsoft Windows 98 (and later) and Mac OS 8.5 (and later) already 111 implement versions of this functionality. This document standardizes 112 this protocol and simplifies it in one important way -- in previous 113 implementations, link-local addresses were only available after a 114 host had tried and failed to contact a DHCP server. This standard 115 removes that restriction, making link-local addresses available all 116 the time, independent of DHCP. A host need not implement a DHCP 117 client in order to use a link-local address. Even for hosts that 118 do implement a DHCP client, information received from DHCP servers 119 has no bearing on a host's link-local address configuration. 121 This document prescribes rules for how IPv4 link-local addresses 122 MUST be treated by hosts and routers. In particular, it describes 123 how routers MUST behave when receiving packets with IPv4 link-local 124 addresses in the source or destination address. With respects to 125 hosts, it discusses claiming and defending addresses, maintaining 126 a link-local address and routable addresses on the same interface, 127 and multihoming issues. 129 1.1. Conventions and Terminology Used in this Document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in "Key words for use in 134 RFCs to Indicate Requirement Levels" [RFC 2119]. 136 This document uses the term "routable address" to refer to all 137 unicast addresses outside the 169.254/16 prefix, including global 138 addresses and private addresses such as Net 10/8 [RFC 1918], all of 139 which may be forwarded via routers. 141 Wherever this document uses the term "host" when describing use of 142 link-local addresses, the text applies equally to routers using 143 link-local addresses on any or all interfaces. 145 Wherever this document uses the term "ARP packet" or "ARP packets", 146 [RFC 826] the text applies uniformly to both ARP request and ARP 147 reply packets. Anywhere that the text applies only to one or 148 other kind of ARP packet, this document explicitly states either 149 "ARP request" or "ARP reply". 151 Wherever this document uses the term "sender IP address" or 152 "target IP address" it is referring to the fields of the ARP 153 packet identified in the ARP specification [RFC 826] as "ar$spa" 154 (Sender Protocol Address) and "ar$tpa" (Target Protocol Address) 155 respectively. For the usage of ARP described in this document, 156 these fields always contain an IP address. 158 1.2. Applicability 160 The specifications in this document apply to any IEEE 802 media 161 [IEEE802] including Ethernet, and other similar link-layer network 162 technologies that operate at data rates of at least 1Mb/s, have a 163 round-trip latency of at most one second, and support ARP [RFC 826]. 164 Wherever this document uses the term "Ethernet", the text applies 165 equally to any of these network technologies. 167 Link-layer network technologies that support ARP but operate at rates 168 below 1Mb/s or latencies above one second may need to specify 169 different values for the following parameters described in Sections 170 2.2 and 2.3: 171 (a) the number of, and interval between, ARP probes, 172 (b) the number of, and interval between, gratuitous ARPs, 173 (c) the maximum rate at which address claiming may be attempted, and 174 (d) the time interval between conflicting ARPs below which a host 175 MUST reconfigure instead of attempting to defend its address. 177 Link-layer network technologies that do not support ARP may be able 178 to use other techniques for determining whether a particular IP 179 address is currently in use. However, the application of claim-and- 180 defend mechanisms to such networks is left to a future document. 182 This document describes link-local addressing, for IP communication 183 between two hosts on a single link. Two hosts are considered to be 184 on the same link if, when one host sends packets to the other, the 185 entire link-layer packet payload arrives unmodified. In particular, 186 any device forwarding a packet whose source and/or destination 187 address is in the 169.254/16 prefix MUST NOT modify any part of the 188 IP header. This means that the packet may pass through devices such 189 as Ethernet switches, bridges, hubs or repeaters, but not through 190 devices like IP routers that modify the IP header. 192 1.3. Issues with Autoconfiguration 194 Implementations of IPv4 link-local address autoconfiguration MUST 195 expect address collisions, and MUST be prepared to handle them 196 gracefully by automatically selecting a new address whenever a 197 collision is detected, as described in Section 2. This requirement to 198 detect and handle address collisions applies during the entire period 199 that a host is using a 169.254/16 link-local address, not just during 200 initial interface configuration. For example, address collisions can 201 occur well after a host has completed booting if two previously 202 separate networks are joined, as described in Section 4. 204 1.4. 169.254/16 Not To Be Used for Other Purposes 206 Note that addresses in the 169.254/16 prefix SHOULD NOT be configured 207 manually or by a DHCP server. Manual or DHCP configuration may cause 208 a host to use an address in the 169.254/16 prefix without following 209 the special rules regarding duplicate detection and automatic 210 configuration that pertain to addresses in this prefix. While RFC 211 2131 indicates that a DHCP client SHOULD probe a newly received 212 address with ARP, this is not mandatory. Similarly, while RFC 2131 213 recommends that a DHCP server SHOULD probe an address using an ICMP 214 Echo Request before allocating it, this is also not mandatory, and 215 even if the server does this, link-local addresses are not routable, 216 so a DHCP server not directly connected to a link cannot detect 217 whether a host on that link is already using the desired IPv4 218 link-local address. 220 Administrators wishing to configure their own local addresses 221 (using manual configuration, a DHCP server, or any other mechanism 222 not described in this document) should use one of the existing 223 private address prefixes [RFC 1918], not the 169.254/16 prefix. 225 1.5. Supporting Multiple Addresses per Interface 227 IPv4 link-local addresses are independent from any other IPv4 228 addresses that a host may have. Each interface on a host may have 229 a link-local address in addition to zero or more other addresses 230 configured by other means (e.g. manually or via a DHCP server). 231 Under normal circumstances, there is no reason to configure more 232 than one link-local address on any given physical interface. 234 There are several reasons why it is beneficial for hosts to maintain 235 a link-local address in addition to any other addresses they may 236 have. For example, a DHCP server may appear on a network where hosts 237 are already communicating using link-local addresses, and it is 238 beneficial for already-established link-local TCP connections to 239 continue working even after the hosts have contacted the DHCP server 240 and configured additional routable addresses. 242 Another example of why it is beneficial for hosts to maintain a link- 243 local address in addition to other addresses is that there may be 244 networks where some of the hosts have only a link-local address. 245 For example, a user with a wireless home network may have a laptop 246 computer and an IP printer. The laptop computer may have both a 247 self-configured link-local address and a DHCP-configured global 248 address. The printer, in contrast, may have only a link-local 249 address, because the user does not need (or want) the printer to be 250 globally addressable. In this case, the laptop computer would access 251 pages on the World Wide Web using its globally-routable address to 252 communicate with servers world-wide, but print those web pages using 253 its link-local address to communicate with its local printer. 255 This does not necessarily require that a host implement an arbitrary 256 number of addresses per interface. A simple host may implement just 257 the special case of a single link-local address and a single 'other' 258 address. (Note that any host running IPv6 is already required to have 259 the ability to maintain multiple IPv6 addresses per interface.) 261 1.6. Supporting Multiple Interfaces 263 Hosts that support multi-homing have additional considerations if 264 they wish to use IPv4 link-local addresses on more than one interface 265 at a time. These are discussed in Section 3. 267 2. IPv4 Link-Local Address Selection, Defense and Delivery 269 The following section explains the link-local address selection 270 algorithm, how link-local addresses are defended, and how IPv4 271 packets with link-local addresses are delivered. 273 Windows and Mac OS hosts that already implement IPv4 address auto- 274 configuration are compatible with the rules presented in this 275 section. However, should any interoperability problem be discovered, 276 this document, not any prior implementation, defines the standard. 278 Note that the probing and collision detection procedures described in 279 Sections 2.2 and 2.3, mandatory for IPv4 link-local addresses, are 280 highly advisable for all IPv4 addresses, regardless of how they are 281 configured. Detecting collisions on manually configured addresses 282 allows the operating system to display an error message to the user, 283 potentially saving hours of network troubleshooting time. Detecting 284 collisions on DHCP-configured addresses allows the DHCP client to 285 send a DHCP DECLINE [RFC 2131] to the server and obtain a new, 286 reliable, IP address. Collision detection therefore should not be 287 unique to link-local addresses. This document recommends that 288 operating systems should implement probing and collision detection 289 for all IPv4 addresses; only the action taken in response to an 290 address collision varies according to the method used to configure 291 that address. 293 2.1 Selecting a Link-Local Address 295 When a host wishes to configure a link-local address, it selects 296 an address using a pseudo-random number generator with a uniform 297 distribution in the range from 169.254.1.0 to 169.254.254.255. The 298 IPv4 network 169.254/16 is registered with the IANA for this purpose. 299 The first 256 and last 256 addresses in the 169.254/16 network are 300 reserved for use by future IETF-Standard protocols and MUST NOT be 301 selected by a host using this dynamic configuration mechanism. 303 The pseudo-random number generation algorithm should be chosen so 304 that different hosts do not generate the same sequence of numbers. 305 Issues with pseudo-random number generators are discussed in 306 "Randomness Recommendations for Security" [RFC 1750]. If the host has 307 access to persistent information that is different for each host, 308 such as its burned-in Ethernet hardware address, then the 309 pseudo-random number generator SHOULD be seeded using a value derived 310 from this information. This means that even without using any other 311 persistent storage, a host will usually select the same link-local 312 address each time it is booted, which can be convenient for debugging 313 and other operational reasons. Seeding the pseudo-random number 314 generator using the real-time clock is NOT suitable for this purpose, 315 since a group of hosts that are all powered on at the same time might 316 then all generate the same sequence. 318 2.2 Claiming a Link-Local Address 320 After it has selected an address, a host MUST test to see if the 321 address is already in use before beginning to use it. On a network 322 such as Ethernet that supports ARP, this test is done using ARP 323 probes. On link-layer network technologies that do not support ARP 324 other techniques may be available for determining whether a 325 particular IP address is currently in use. However, the application 326 of claim-and-defend mechanisms to such networks is left to a future 327 document. 329 A host probes to see if an address is already in use by broadcasting 330 an ARP request for the desired address. The client MUST fill in the 331 'sender hardware address' field of the ARP packet with the hardware 332 address of the interface through which it is sending the packet. 333 The 'sender IP address' field MUST be set to all zeroes, to avoid 334 polluting ARP caches in other hosts on the same link in the case 335 where the address turns out to be already in use by another host. 336 The 'target hardware address' field is ignored and SHOULD be set to 337 all zeroes. The 'target IP address' field MUST be set to the address 338 being probed. An ARP request constructed this way with an all-zero 339 'sender IP address' is referred to as an "ARP probe". 341 On Ethernet four such probes should be sent, with a two-second wait 342 after each probe (a total of eight seconds). If during this period 343 the host receives any ARP packet where the packet's 'sender IP 344 address' is the address being probed for, then the host MUST treat 345 this address as being in use by some other host, and MUST select 346 a new pseudo-random address and repeat the process. In addition, 347 if during this period the host receives any ARP probe where the 348 packet's 'target IP address' is the address being probed for, and 349 the packet's 'sender hardware address' is not the hardware address 350 of any of the host's interfaces, then the host MUST similarly treat 351 this as an address collision and select a new address as above. This 352 can occur if two (or more) hosts attempt to configure the same link- 353 local address at the same time. 355 A host should maintain a counter of the number of address collisions 356 it has experienced in the process of trying to acquire an address, 357 and if the number of collisions exceeds ten then the host MUST limit 358 the rate at which it probes for new addresses to no more than one new 359 address per minute. This is to prevent catastrophic ARP storms in 360 pathological failure cases, such as a rogue host that answers all 361 ARP probes, causing legitimate hosts to go into an infinite loop 362 attempting to select a usable address. 364 After successfully configuring a link-local address, a host on 365 Ethernet SHOULD broadcast two gratuitous ARPs, spaced two seconds 366 apart. A gratuitous ARP is identical to the ARP probe described 367 above, except that now the sender and target IP addresses are both 368 set to the host's newly selected IP address. The purpose of these 369 gratuitous ARPs is to make sure that other hosts on the link do not 370 have stale ARP cache entries left over from some other host that may 371 previously have been using the same address. 373 Hosts that are equipped with persistent storage MAY, for each 374 interface, record the IP address they have selected. On booting, 375 hosts with a previously recorded address SHOULD use that address as 376 their first candidate when probing. This increases the stability of 377 addresses. For example, if a group of hosts are powered off at night, 378 then when they are powered on the next morning they will all resume 379 using the same addresses, instead of picking different addresses and 380 potentially having to resolve conflicts that arise. 382 2.3 Address Collision Detection and Address Defense 384 Address collision detection is not limited to the address selection 385 phase, when a host is sending ARP probes. Address collision 386 detection is an ongoing process that is in effect for as long as a 387 host is using a link-local IPv4 address. At any time, if a host 388 receives an ARP packet where the 'sender IP address' is the host's 389 own IP address, but the 'sender hardware address' does not match any 390 of the host's own interface addresses, then this is a conflicting ARP 391 packet, indicating an address collision. A host MUST respond to a 392 conflicting ARP packet as described in either (a) or (b) below: 394 (a) Upon receiving a conflicting ARP packet, a host MAY elect to 395 immediately configure a new link-local IP address as described above, 396 or 398 (b) If a host currently has active TCP connections or other reasons 399 to prefer to keep the same IP address, and it has not seen any other 400 conflicting ARP packets recently (for Ethernet, within the last ten 401 seconds) then it MAY elect to attempt to defend its address, by 402 recording the time that the conflicting ARP packet was received, and 403 then broadcasting one single gratuitous ARP request, giving its own 404 IP and hardware addresses as the sender addresses of the ARP. Having 405 done this, the host can then continue to use the address normally 406 without any further special action. However, if this is not the first 407 conflicting ARP packet the host has seen, and the time recorded for 408 the previous conflicting ARP packet is recent (within ten seconds for 409 Ethernet) then the host MUST immediately cease using this address and 410 configure a new link-local IP address as described above. This is 411 necessary to ensure that two hosts do not get stuck in an endless 412 loop with both hosts trying to defend the same address. 414 A host MUST respond to conflicting ARP packets as described in either 415 (a) or (b) above. A host MUST NOT ignore conflicting ARP packets. 417 Forced address reconfiguration may be disruptive, causing TCP 418 connections to be broken. However, it is expected that such 419 disruptions will be rare, and if inadvertent address duplication 420 happens, then disruption of communication is inevitable, no matter 421 how the addresses were assigned. It is not possible for two different 422 hosts using the same IP address on the same network to operate 423 reliably. 425 Immediately configuring a new address as soon as the conflict is 426 detected is the best way to restore useful communication as quickly 427 as possible. The mechanism described above of broadcasting a single 428 gratuitous ARP to defend the address mitigates the problem somewhat, 429 by helping to improve the chance that one of the two conflicting 430 hosts may be able to retain its address. 432 All ARP packets (*replies* as well as requests) that contain a link- 433 local sender IP address MUST be sent using link-level broadcast 434 instead of link-level unicast. This aids timely detection of 435 duplicate addresses. An example illustrating how this helps is 436 given in Section 4. 438 2.4 Source Address Selection 440 Since each interface on a host may have a link-local address in 441 addition to zero or more other addresses configured by other means 442 (e.g. manually or via a DHCP server), a host may have to make a 443 choice about what source address to use when it sends a packet or 444 initiates a TCP connection. 446 If the destination address is in the 169.254/16 prefix (including the 447 169.254.255.255 broadcast address), the host SHOULD use its link- 448 local source address, if it has one. If the host does not have a 449 link-local source address, then it MAY choose to ARP for the 450 destination address and then send its packet, with a routable source 451 IP address and a link-local destination IP address, directly to its 452 destination on the same physical link. The host MUST NOT send the 453 packet to any router for forwarding. 455 If the destination address is the 255.255.255.255 broadcast address 456 or a multicast address, then the host may use either its link-local 457 source address or a routable address, as appropriate. 459 If the destination address is a unicast address outside the 460 169.254/16 prefix, or then the host SHOULD use an appropriate 461 routable source address, if it has one. If the host does not have a 462 routable source address, then it MAY choose to ARP for the 463 destination address and then send its packet, with a link-local 464 source IP address and a routable destination IP address, directly to 465 its destination on the same physical link. The host MUST NOT send the 466 packet to any router for forwarding. 468 In the case where two hosts on the same link each have both a link- 469 local address and another address configured via some other means, 470 the host may use either its link-local source address or a routable 471 address, depending on which is expected to be more likely to remain 472 stable for the expected lifetime of the connection. Note that link- 473 local addresses may be forced to change over time, as described in 474 Section 2.3. 476 2.5 Link-Local Addresses Are Not Forwarded 478 Any host sending an IPv4 packet with a source and/or destination 479 address in the 169.254/16 prefix MUST set the TTL in the IP header 480 to 255. 482 Any host receiving an IPv4 packet whose source and/or destination 483 address is in the 169.254/16 prefix MUST discard the packet if the 484 TTL in the IP header is not 255. 486 This is to guard against misconfigured routers which may allow 487 packets to leak in from outside the local link. Since even the most 488 dysfunctional router will decrement the TTL in the IP header, a host 489 receiving a packet with a TTL less than 255 can detect that it 490 originated outside the local link. 492 An IPv4 packet whose source and/or destination address is in the 493 169.254/16 prefix MUST NOT be sent to any router for forwarding, and 494 any network device receiving such a packet MUST NOT forward it, 495 regardless of the TTL in the IP header. 497 This restriction also applies to multicast packets. IP packets with 498 a link-local source address MUST NOT be forwarded off the local link 499 even if they have a multicast destination address. 501 Similar considerations apply at layers above IP. For example, DNS 502 Resource Records containing link-local addresses SHOULD NOT be sent 503 to hosts outside the link to which those link-local addresses apply. 504 Automatically generated web pages SHOULD NOT contain links with 505 embedded link-local addresses if those pages are viewable from hosts 506 outside the local link where the addresses are valid. Since DNS 507 treats Resource Record Sets [RFC 2181] as indivisible units (e.g. for 508 generating DNS reply packets, signatures, etc.), RRSets SHOULD only 509 contain A records where all the addresses have the same scope. Link- 510 local and routable addresses SHOULD NOT be mixed in a single set. 512 The non-forwarding rule means that hosts may assume that all 513 169.254/16 destination addresses are "on-link" and directly 514 reachable. The 169.254/16 address prefix MUST NOT be subnetted. 515 This specification utilizes ARP-based address collision detection, 516 which functions by broadcasting on the local subnet. Since such 517 broadcasts are not forwarded, were subnetting to be allowed then 518 address conflicts could remain undetected. 520 The non-forwarding rule is important because it is expected that many 521 link-local-only devices will be extremely simple devices of the kind 522 that currently use X10 [X10], USB [USB] or FireWire [IEEE1394]. 523 The designers of these devices assume that they will communicate 524 only with other local devices, and implement a degree of security 525 appropriate for that expected environment. (For example, a typical 526 USB mouse does not have a password, nor does it encrypt its mouse- 527 movement data, and in most environments this is acceptable.) 528 Any network gateway device that blindly forwards the contents of 529 link-local IP packets off the local network (or vice-versa) exposes 530 these link-local-only devices to a much greater degree of risk than 531 their designers may have planned for. 533 This does not mean that link-local devices are forbidden from 534 communicating outside the local link. IP hosts that implement both 535 link-local and conventional routable IP addresses may still use 536 their routable addresses without restriction as they do today. 537 Extremely simple IP devices that implement only a link-local address 538 may also communicate with hosts outside the local link, provided that 539 such communication is mediated through a device capable of enforcing 540 appropriate security controls. For example, a home heating system 541 could be controlled via a Web server on the local network, where the 542 Web server uses cryptographic methods to verify the authority of the 543 remote user, and then uses link-local communication on the local 544 network to communicate commands to the heating system's thermostat. 546 It should be understood that this mediated communication is not 547 mandatory; it is an option afforded to designers of very simple 548 devices who wish to implement only a link-local address and thereby 549 simplify their security assumptions. Any designer of a device 550 desiring unmediated communication outside the local link need only 551 implement today's conventional IP host software (e.g. a DHCP client) 552 in order to enjoy the same degree of global addressability available 553 to other conventional IP hosts. 555 3. Considerations for Multiple Interfaces 557 This section does not specify protocol requirements; it offers 558 implementation advice. Implementers of multi-homed hosts have three 559 basic choices: (1) configure a link-local address on only one active 560 interface at a time, (2) adopt networking APIs that include interface 561 identifiers, and configure a single shared link-local address used by 562 all active interfaces, or (3) provide networking APIs that identify 563 interfaces by IP address (the norm) and maintain some additional 564 address uniqueness properties in order to support the use of IP 565 addresses as unambiguous interface identifiers. This section 566 discusses these three choices. 568 3.1 Link-Local Addressing on Only One Interface 570 A multi-homed host may elect to configure an IPv4 link-local address 571 on only one of its active interfaces. In some situations this will 572 be adequate. Implementers who are not planning to support IPv4 link- 573 local addresses simultaneously on multiple interfaces may skip the 574 remainder of this section. 576 3.2 Single Shared Link-Local Address 578 Some operating systems have networking APIs that allow applications 579 to specify network interfaces by name, index value, or other local 580 identifier, and to identify interfaces this way both for incoming 581 and outgoing packets/connections. For operating systems that have 582 this capability (and have application software that makes use of it) 583 it is sufficient to configure all interfaces with a single common 584 IPv4 link-local address, and defend that address on all interfaces. 586 3.3 Different Link-Local Address for Each Interface 588 Many operating systems have networking APIs that allow applications 589 to bind endpoints only to a desired source IP address, or similarly 590 when a packet is received, identify the interface on which it arrived 591 only by its IP address, not by its name or other identifier. A multi- 592 homed host in this situation should ensure that each of its 593 interfaces is configured with a different link-local address, to 594 enable use of the source address as an unambiguous interface 595 identifier. To provide this property, if the selection algorithm 596 chooses an address that is already in use on one of the host's other 597 interfaces, then the process should be repeated until a unique 598 address is selected. 600 In addition, this kind of host should probe for, and defend, all of 601 its link-local addresses on all of its active interfaces that are 602 using link-local addresses. 604 When bringing up a new interface, the host SHOULD first probe for all 605 of its existing link-local addresses on that new interface. If any of 606 the addresses are found to be already in use by some other host on 607 that new link, then the interfaces in question MUST be reconfigured 608 to select new unique link-local addresses. The host should then 609 select a link-local address for the new interface, and probe on all 610 of its active interfaces to verify that this new address is unique 611 on all the links that the host has connections to. 613 This uniqueness requirement simplifies host software layers above 614 IP (application software and transport protocols) by allowing them 615 to identify connections using only the source and destination IP 616 addresses, without also needing interface identifiers. Since link- 617 local addresses are only unique per-link, hosts on different links 618 could be using the same link-local address. Uniqueness of source 619 addresses on the multi-homed host allows connections to the same 620 destination address on different links to be disambiguated by their 621 different source addresses. 623 Note that this also requires that the multi-homed host using 624 different link-local addresses on multiple interfaces MUST 625 implement the "strong end system" model [RFC 1122] for packets 626 from link-local source addresses, so that packets are only sent out 627 from the interface that matches the source address in the packet. 628 (The "weak end system" model may still be used for other packets.) 630 When bringing up multiple interfaces simultaneously (e.g. at system 631 boot time) the process can be streamlined by configuring all 632 interfaces concurrently. First all interfaces should be brought up in 633 an un-numbered state. Once this is done, all interfaces can then 634 concurrently go through the process of selecting a locally unique 635 address and probing for that address simultaneously on all active 636 interfaces (including all other interfaces that are themselves 637 currently in the process of selecting and probing for an address). 639 3.3.1 Example Illustrating (Incorrect) Ambiguous Address Re-Use 641 Figure 1 shows a network topology where host A has an interface on 642 link X with link-local address P, and host B, also on link X, has 643 address Q. If we allow host A to have another interface on a 644 different link that also has address Q, then although there are 645 no conflicts strictly within the scope of either link, there is 646 potential for confusion. When host A sends a UDP packet from source 647 address P to destination address Q without specifying an explicit 648 outgoing interface identifier, it is ambiguous whether A intends 649 to talk to itself, or to host B. By ensuring that all of a host's 650 link-local addresses are distinct not only from each other, but also 651 from all addresses currently active on all links that the host is 652 connected to, we remove this ambiguity. 654 | | 655 | P ----- Q? | 656 |-----| A |-----| 657 | ----- | 658 | | 659 | | 660 X| |Y 661 | | 662 | | 663 ----- | | 664 | B |-----| | 665 ----- Q | | 666 | | 668 Figure 1. (Incorrect) Ambiguous Re-Use of Address Q 670 3.3.2 Example Illustrating Acceptable Address Re-Use 672 Note that it is acceptable for different hosts on separate links to 673 be using the same link-local address on their respective separate 674 links. Figure 2 shows a network topology where host B on link X is 675 using address Q, while at the same time, host C on link Y is also 676 using address Q. This is entirely in keeping with the concept of 677 link-local addresses. Link-local addresses are only unique amongst 678 the member hosts of a single link. Hosts B and C are not on the same 679 link, hence there is no requirement for them to have distinct 680 addresses. Note that in this case, host A is still able to 681 communicate with both hosts B and C, because a packet sent from 682 source address P to destination address Q travels on link X to host 683 B, and a packet sent from source address R to destination address Q 684 travels on link Y to host C. TCP connections are uniquely identified 685 by the source and destination addresses and port numbers, not just by 686 the destination address and port number alone. To support link-local 687 addressing on multiple interfaces simultaneously, the network 688 software API must allow applications to bind endpoints to a desired 689 source interface as well as specifying the desired destination 690 address for a TCP connection. Networking implementations that only 691 allow the destination address to be specified should limit themselves 692 to configuring only one interface for link-local addressing. 694 | | 695 | P ----- R | 696 |-----| A |-----| 697 | ----- | 698 | | 699 | | 700 X| |Y 701 | | 702 | | 703 ----- | | ----- 704 | B |-----| |-----| C | 705 ----- Q | | Q ----- 706 | | 708 Figure 2. Acceptable Re-Use of Address Q 710 3.4 Collision Detection for Multi-Homed Hosts 712 If a host receives an ARP packet on an interface that's using a link- 713 local address, where the 'sender IP address' in the ARP packet is 714 equal to *any* of the host's current link-local addresses, and the 715 'sender hardware address' in the ARP packet is equal to *none* of the 716 host's active interfaces, then this is a conflicting ARP packet and 717 must be handled as such. 719 If a host receives an ARP packet where the 'sender hardware address' 720 in the ARP packet is equal to *any* of the host's active interfaces, 721 then this is not a conflicting ARP packet, and should be silently 722 discarded. This is because a user of a multi-homed host with two 723 Ethernet interfaces may connect both interfaces to the same Ethernet 724 hub, in which case the two interfaces will see each other's packets, 725 and if it did not check and realize that the apparently conflicting 726 ARP packets were coming from itself the host could erroneously 727 conclude that all its addresses were in conflict. Another common 728 example is a host with both wired and wireless Ethernet interfaces, 729 in an environment where a wireless gateway is available, but (perhaps 730 unknown to the user) is bridged onto the same wired Ethernet. 732 4. Considerations for Joining of Previously Separate Networks 734 Hosts on disjoint network links may configure the same link-local 735 address. If these separate network links are later joined or 736 bridged together, then there may be two hosts which are now on the 737 same link, trying to use the same address. When either host attempts 738 to communicate with any other host on the network, it will at some 739 point broadcast an ARP packet which will enable the hosts in question 740 to detect that there is an address conflict. 742 When these address conflicts are detected, the subsequent forced 743 reconfiguration may be disruptive, causing TCP connections to be 744 broken. However, it is expected that such disruptions will be rare. 745 It should be relatively uncommon for networks to be joined while 746 hosts on those networks are active. Also, 65024 addresses are 747 available for link-local use, so even when two small networks are 748 joined, the chance of collision for any given host is fairly small. 750 When joining two large networks (defined as networks with a 751 substantial number of hosts per segment) there is a greater chance 752 of collision. In such networks, it is likely that the joining of 753 previously separated segments will result in one or more hosts 754 needing to change their IPv4 link-local address, with subsequent 755 loss of TCP connections. In cases where separation and re-joining 756 is frequent, as in remotely bridged networks, this could prove 757 disruptive. However, unless the number of hosts on the joined 758 segments is very large, the traffic resulting from the join and 759 subsequent address conflict resolution will be small. 761 Sending ARP replies that have link-local sender IP addresses via 762 broadcast instead of unicast ensures that these conflicts can be 763 detected as soon as they become potential problems, but no sooner. 764 For example, if two disjoint network links are joined, where hosts 765 A and B have both configured the same link-local address, X, they 766 can remain in this state until A, B or some other host attempts to 767 initiate communication. If some other host C now sends an ARP request 768 for address X, and hosts A and B were to both reply with conventional 769 unicast ARP replies, then host C might be confused, but A and B still 770 wouldn't know there is a problem because neither would have seen the 771 other's packet. Sending these replies via broadcast allows A and B 772 see each other's conflicting ARP packets and respond accordingly. 774 Note that sending periodic gratuitous ARPs in an attempt to detect 775 these conflicts sooner is not necessary, wastes network bandwidth, 776 and may actually be detrimental. For example, if the network links 777 were joined only briefly, and were separated again before any new 778 communication involving A or B were initiated, then the temporary 779 conflict would have been benign and no forced reconfiguration would 780 have been required. Triggering an unnecessary forced reconfiguration 781 in this case would not serve any useful purpose. Hosts SHOULD NOT 782 send periodic gratuitous ARPs. 784 5. Security Considerations 786 The use of this functionality may open a network host to new attacks. 787 In particular, a host that previously did not have an IP address, 788 and no IP stack running, was not susceptible to IP-based attacks. 789 By configuring a working address, the host may now be vulnerable 790 to IP-based attacks. 792 The ARP protocol [RFC 826] is insecure. A malicious host may send 793 fraudulent ARP packets on the network, interfering with the correct 794 operation of other hosts. For example, it is easy for a host to 795 answer all ARP requests with responses giving its own hardware 796 address, thereby claiming ownership of every address on the network. 798 6. IANA Considerations 800 The IANA has allocated the network prefix 169.254/16 for the use 801 described in this document. The first and last 256 addresses in this 802 range (169.254.0.x and 169.254.255.x) are reserved for future IETF 803 Standards actions. No other IANA services are required by this 804 document. 806 7. Acknowledgements 808 We would like to thank (in alphabetical order) Jim Busse, 809 Pavani Diwanji, Donald Eastlake 3rd, Peter Ford, Spencer Giacalone, 810 Josh Graessley, Erik Guttman, Myron Hattig, Hugh Holbrook, 811 Richard Johnson, Kim Yong-Woon, Rod Lopez, Satish Mundra, 812 Thomas Narten, Erik Nordmark, Howard Ridenour, Daniel Senie, 813 Dieter Siegmund, Valery Smyslov and Ryan Troll for their 814 contributions. 816 8. Intellectual Property 818 The IETF takes no position regarding the validity or scope of any 819 intellectual property or other rights that might be claimed to 820 pertain to the implementation or use of the technology described in 821 this document or the extent to which any license under such rights 822 might or might not be available; neither does it represent that it 823 has made any effort to identify any such rights. Information on the 824 IETF's procedures with respect to rights in standards-track and 825 standards-related documentation can be found in BCP-11. Copies of 826 claims of rights made available for publication and any assurances of 827 licenses to be made available, or the result of an attempt made to 828 obtain a general license or permission for the use of such 829 proprietary rights by implementors or users of this specification 830 can be obtained from the IETF Secretariat." 832 The IETF has been notified of intellectual property rights claimed 833 in regard to some or all of the specification contained in this 834 document. For more information consult the online list of claimed 835 rights. 837 9. Copyright 839 Copyright (C) The Internet Society 8th March 2000. 840 All Rights Reserved. 842 This document and translations of it may be copied and furnished to 843 others, and derivative works that comment on or otherwise explain it 844 or assist in its implementation may be prepared, copied, published 845 and distributed, in whole or in part, without restriction of any 846 kind, provided that the above copyright notice and this paragraph are 847 included on all such copies and derivative works. However, this 848 document itself may not be modified in any way, such as by removing 849 the copyright notice or references to the Internet Society or other 850 Internet organizations, except as needed for the purpose of 851 developing Internet standards in which case the procedures for 852 copyrights defined in the Internet Standards process must be 853 followed, or as required to translate it into languages other than 854 English. 856 The limited permissions granted above are perpetual and will not be 857 revoked by the Internet Society or its successors or assigns. 859 This document and the information contained herein is provided on an 860 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 861 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 862 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 863 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 864 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 866 10. References 868 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 869 Overview and Architecture. 870 Institute of Electrical and Electronic Engineers, 871 IEEE Standard 802, 1990. 873 [IEEE1394] Standard for a High Performance Serial Bus. 874 Institute of Electrical and Electronic Engineers, 875 IEEE Standard 1394-1995, 1995. 877 [RFC 826] D. Plummer, "An Ethernet Address Resolution Protocol -or- 878 Converting Network Addresses to 48-bit Ethernet Address 879 for Transmission on Ethernet Hardware", STD 37, RFC 826, 880 November 1982. 882 [RFC 1122] R. Braden, "Requirements for Internet Hosts -- 883 Communication Layers", RFC 1122, October 1989. 885 [RFC 1750] D. Eastlake 3rd, S. Crocker and J. Schiller, "Randomness 886 Recommendations for Security", RFC 1750, December 1994. 888 [RFC 1918] Y. Rekhter et.al., "Address Allocation for Private 889 Internets", RFC 1918, February 1996. 891 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 892 Requirement Levels", RFC 2119, March 1997. 894 [RFC 2131] R. Droms, "Dynamic Host Configuration Protocol", 895 RFC 2131, March 1997. 897 [RFC 2181] R. Elz and R. Bush, "Clarifications to the DNS 898 Specification", RFC 2181, July 1997. 900 [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address 901 Autoconfiguration", RFC 2462, December 1998. 903 [USB] Universal Serial Bus Implementers Forum 904 906 [X10] X10 Ltd. 908 11. Authors' Addresses 910 Stuart Cheshire 911 Apple Computer, Inc. 912 1 Infinite Loop 913 Cupertino 914 California 95014 915 USA 917 Phone: +1 408 974 3207 918 EMail: rfc@stuartcheshire.org 920 Bernard Aboba 921 Microsoft Corporation 922 One Microsoft Way 923 Redmond, WA 98052 924 USA 926 Phone: +1 425 936 6605 927 Fax: +1 425 936 7329 928 EMail: bernarda@microsoft.com 930 Appendix. Behavior of Legacy Implementations 932 A.1. Apple Mac OS 8.x and 9.x. 934 Mac OS chooses the IP address on a pseudo-random basis. The selected 935 address is saved in persistent storage for continued use after 936 reboot, when possible. 938 Mac OS sends four DHCPDISCOVER packets, with timeouts of 1, 2, 4, 939 and then 8 seconds. When no response is received from any of these 940 requests (15 seconds), it will autoconfigure. 942 Upon finding that a selected address is in use, Mac OS will select a 943 new random address and try again, at a rate limited to no more than 944 one attempt every two seconds. 946 Autoconfigured Mac OS systems check for the presence of a DHCP 947 server every five minutes. If a DHCP server is found but Mac OS 948 is not successful in obtaining a new lease, it keeps the existing 949 autoconfigured IP address. If Mac OS is successful at obtaining a 950 new lease, it drops all existing connections without warning. This 951 may cause users to lose sessions in progress. Once a new lease is 952 obtained, Mac OS will not allocate further connections using the 953 autoconfigured IP address. 955 Mac OS systems do not send packets addressed to a link-local address 956 to the default gateway if one is present; these addresses are always 957 resolved on the local segment. 959 Mac OS implements media sense where the hardware (and driver 960 software) supports this. As soon as network connectivity is detected, 961 a DHCPDISCOVER will be sent on the interface. This means that systems 962 will immediately transition out of autoconfigured mode as soon as 963 connectivity is restored. 965 A.2. Microsoft Windows 98/98SE 967 Windows 98/98SE systems choose their IP address on a pseudo- 968 random basis. This ensures that systems rebooting will obtain the 969 same autoconfigured address, unless a conflict is detected. The 970 address selection algorithm is based on computing a hash on the 971 interface's MAC address, so that a large collection of hosts should 972 obey the uniform probability distribution in choosing addresses 973 within the 169.254/16 address space. 975 The Windows 98/98SE DHCP Client sends out a total of 4 DHCPDISCOVERs, 976 with an inter-packet interval of 6 seconds. When no response is 977 received after all 4 packets (24 seconds), it will autoconfigure an 978 address. 980 The autoconfigure retry count for Windows 98/98SE systems is 10. 981 After trying 10 autoconfigured IP addresses, and finding all are 982 taken, the host will boot without an IP address. 984 Autoconfigured Windows 98/98SE systems check for the presence of a 985 DHCP server every five minutes. If a DHCP server is found but Windows 986 98 is not successful in obtaining a new lease, it keeps the existing 987 autoconfigured IP address. If Windows 98/98SE is successful at 988 obtaining a new lease, it drops all existing connections without 989 warning. This may cause users to lose sessions in progress. Once 990 a new lease is obtained, Windows 98/98SE will not allocate further 991 connections using the autoconfigured IP address. 993 Windows 98/98SE systems do not send packets addressed to a link-local 994 address to the default gateway if one is present; these addresses are 995 always resolved on the local segment. 997 Windows 98/98SE systems do not implement media sense. This means that 998 network connectivity issues (such as a loose cable) may prevent a 999 system from contacting the DHCP server, thereby causing it to auto- 1000 configure. When the connectivity problem is fixed (such as when the 1001 cable is re-connected) the situation will not immediately correct 1002 itself. Since the system will not sense the re-connection, it will 1003 remain in autoconfigured mode until an attempt is made to reach the 1004 DHCP server. 1006 The mini-DHCP server included with Windows 98SE Internet Connection 1007 Sharing (ICS), which functions as a NAT, allocates out of the 1008 192.168/16 private address space by default. 1010 However, it is possible to change the allocation prefix via a 1011 registry key, and no checks are made to prevent allocation out of the 1012 link-local prefix. When configured to do so, Windows 98SE ICS will 1013 NAT packets from the link-local prefix off the local link. Windows 1014 98SE ICS does not automatically route for the link-local prefix, so 1015 that hosts obtaining addresses via DHCP cannot communicate with 1016 autoconfigured-only devices. 1018 Other home gateways exist that allocate addresses out of the link- 1019 local prefix by default. Windows 98/98SE systems can use a 169.254/16 1020 link-local address as the source address when communicating with 1021 non-link-local hosts. However, Windows 98/98SE does not support 1022 router solicitation/advertisement. This means that Windows 98/98SE 1023 systems will typically not be able to discover a default gateway when 1024 in autoconfigured mode. 1026 A.3. Windows 2000 and Windows ME 1028 The autoconfiguration behavior of Windows 2000 and Windows ME systems 1029 is identical to Windows 98/98SE except in the following respects: 1031 Media Sense 1032 Router Discovery 1033 Silent RIP 1035 Windows 2000 and ME implement media sense. As soon as network 1036 connectivity is detected, a DHCPDISCOVER will be sent on the 1037 interface. This means that systems will immediately transition 1038 out of autoconfigured mode as soon as connectivity is restored. 1040 Windows 2000 and ME also support router discovery, although it is 1041 turned off by default. Windows 2000 also supports a RIP listener. 1042 This means that it is possible to discover a default gateway while 1043 in autoconfigured mode. 1045 ICS on Windows 2000/ME behaves identically to Windows 98SE with 1046 respect to address allocation and NATing of link-local prefixes.