idnits 2.17.1 draft-cheshire-ipv4-linklocal-00.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 (March 2000) is 8808 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Stuart Cheshire 2 Document: draft-cheshire-ipv4-linklocal-00.txt Apple Computer 3 Expires 8th September 2000 8th March 2000 5 Dynamic Configuration of IPv4 link-local addresses 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are 13 working documents of the Internet Engineering Task Force (IETF), 14 its areas, and its working groups. Note that other groups may 15 also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Distribution of this memo is unlimited. 30 Abstract 32 As the Internet Protocol continues to increase in popularity as a 33 global communication system, it becomes increasingly valuable to be 34 able to use familiar IP tools such as ftp for local communication as 35 well. For example, two people with laptop computers with built-in 36 wireless Ethernet may meet and wish to exchange files. It is 37 desirable for these people to be able to use IP application software 38 without the inconvenience of having to manually configure static IP 39 addresses or set up a DHCP [RFC 2131] server. 41 This draft describes a method by which a host may automatically 42 configure an interface with an IP address in the 169.254/16 range 43 that is valid for link-local communication on that interface. This 44 is especially valuable in environments where no other configuration 45 mechanism is available. 47 1. Introduction 49 As the Internet Protocol continues to increase in popularity as a 50 global communication system, it becomes increasingly valuable to be 51 able to use familiar IP tools such as ftp for local communication as 52 well. For example, two people with laptop computers with built-in 53 wireless Ethernet may meet and wish to transfer files. It is 54 desirable for these people to be able to use IP application software 55 without the inconvenience of having to manually configure static IP 56 addresses or set up a DHCP [RFC 2131] server. 58 This draft describes a method by which a host may automatically 59 configure an interface with an IP address in the 169.254/16 range 60 that is valid for link-local communication on that interface. This 61 is especially valuable in environments where no other configuration 62 mechanism is available. 64 IP datagrams whose source or destination addresses are in the 65 169.254/16 range MUST NOT be sent to any router for forwarding, and 66 any network device receiving such datagrams MUST NOT forward them. 67 Link local address are, by definition, restricted to the local 68 network segment. Allocation of link-local addresses in an IPv6 69 network is described in [RFC 2462]. Similar considerations apply at 70 layers above IP. For example, DNS Resource Records containing 71 link-local address SHOULD NOT be sent to hosts outside the link to 72 which those link-local address apply. Similarly, automatically 73 generated web pages SHOULD NOT contain links with embedded link-local 74 addresses if those pages are viewable from hosts outside the local 75 link where the addresses are valid. 77 IPv4 link-local addresses are independent from any other IPv4 78 addresses that a host may have. Each interface on a host MAY have 79 a link-local address in addition to zero or more other addresses 80 configured by other means (e.g. manually or via a DHCP server). 82 There are several reasons why it is beneficial for a host to maintain 83 link-local addresses in addition to any other addresses it may have. 84 For example, a DHCP server may appear on a network where hosts 85 are already communicating using link-local addresses, and it is 86 beneficial for those already-established link-local TCP connections 87 to continue working even after the hosts have configured additional 88 global addresses assigned by the DHCP server. 90 Another example is that there may be networks where not all of the 91 hosts have externally configured addresses. For example, a user with 92 a wireless home network may have a laptop computer and an IP printer. 93 The laptop computer may have both a self-configured link-local 94 address and a DHCP-configured global address. The printer, in 95 contrast, may have only a link-local address, because the user does 96 not want the printer to be globally addressable. In this case, the 97 laptop computer would access pages on the World Wide Web using its 98 globally-routable address to communicate with servers world-wide, but 99 print those web pages using its link-local address to communicate 100 with its local printer. 102 In the case where two hosts on the same link have both link-local 103 addresses and global addresses, they SHOULD prefer the global 104 addresses when establishing new communications (e.g. TCP connections) 105 because their global addresses are likely to remain stable whereas 106 their link-local addresses could change over time, as described in 107 Section 2 below. 109 A host SHOULD NOT establish communications from a global source 110 address to a link-local destination address, or vice versa. 111 Link-local addresses should only be used for communication with other 112 link-local addresses on the same link. 114 1.1. Conventions Used in the Document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC 2119]. 120 2. Choosing an IPv4 link-local address. 122 When a host wishes to configure a link-local address, it selects an 123 address at random, uniformly distributed in the range 169.254.1.0 to 124 169.254.254.255. The IPv4 network 169.254/16 is registered with the 125 IANA for this purpose. The first 256 and last 256 addresses in this 126 network are reserved for future use and SHOULD NOT be selected by a 127 host using this dynamic configuration mechanism. 129 The random number generator algorithm should be chosen so that 130 different hosts do not generate the same sequence of random numbers. 131 For example, the random number generator could be seeded using 132 information derived from the host's Ethernet hardware address, or 133 some other information unique to each host. Seeding the random number 134 generator using the real-time clock is NOT suitable for this purpose, 135 since a group of hosts that are all powered on at the same time might 136 then all generate the same random sequence. 138 After it has selected an address, the host MUST test to see if the 139 address is already in use. This test is done using ARP [RFC 826] 140 probes. On link-layer network technologies that do not support ARP 141 there may be equivalent mechanisms for determining whether a 142 particular IP address is currently in use, but these kinds of network 143 are not discussed in this draft. 145 The host tests to see if the address is already in use by 146 broadcasting an ARP request for the desired address. The client MUST 147 fill in its own hardware address as the sender's hardware address, 148 and all zeroes as the sender's IP address, to avoid polluting ARP 149 caches in other hosts on the same link in the case where the address 150 turns out to already be in use by another host. This ARP request with 151 a sender IP address of all zeroes is referred to as an "ARP probe". 153 The appropriate number of ARP probes and the interval between them 154 may be implementation-dependent. For 10Mb/s Ethernet, four probes 155 with a two-second interval is recommended. If the host receives an 156 ARP response indicating that the address is currently in use, then 157 the host should select a new address at random and repeat the process. 159 While waiting for a possible response to this request, the client 160 MUST also listen for other ARP probes for the same address 161 originating from a different hardware address. This will occur if two 162 (or more) hosts are attempting to configure the same link-local 163 address. If the client receives a response to the ARP request, or 164 sees another ARP probe for the same address, it MUST consider the 165 address as being in use, and move on. 167 A host SHOULD keep a counter of the number of address collisions it 168 has experienced in the process of trying to acquire an address, and 169 if the count becomes too high it should cease attempting to acquire 170 an address. This is to prevent infinite loops in pathological failure 171 cases. On 10Mb/s Ethernet, fifty consecutive failed attempts should 172 be considered "too high". 174 After successfully configuring a link-local address, a host on 10Mb/s 175 Ethernet SHOULD send two gratuitous ARPs, spaced two seconds apart, 176 this time filling in the sender IP address. The purpose of these 177 gratuitous ARPs is to make sure that other hosts on the net do not 178 have stale ARP cache entries left over from some other host that may 179 previously have been using the same address. 181 Address collision detection is not limited to the address selection 182 phase, when the host is sending ARP probes and listening for replies. 183 Address collision detection is an ongoing process that is in effect 184 for as long as the host is using a link-local IP address. At any 185 time, if a host receives an ARP packet with its own IP address given 186 as the sender IP address, but a different sender hardware address, 187 then the host MUST treat this as an address collision and configure a 188 new link-local IP address as described above. This forced 189 reconfiguration may be disruptive, causing TCP connections to be 190 broken. However, it is expected that such disruptions will be rare, 191 and if an inadvertent address duplication happens, then disruption of 192 communication is inevitable, no matter how the addresses were 193 assigned. It is not possible for two different hosts using the same 194 IP address on the same network to operate reliably. Immediately 195 configuring a new address as soon as the conflict is detected is the 196 best way to restore useful communication as quickly as possible. 198 After successfully configuring a link-local address, all subsequent 199 ARP packets (replies as well as requests) containing a link-local 200 source address MUST be sent using link-level broadcast instead of 201 link-level unicast. This is important to enable timely detection of 202 duplicate addresses, as described above. 204 Hosts which are equipped with persistent storage should, for each 205 interface, record the IP address they have selected, and on the next 206 boot should use that address as their first candidate when probing. 207 This increases the stability of addresses. For example, if a group 208 of hosts on an isolated IP network are powered off at night, then 209 when they are powered on the next morning they will all resume using 210 the same addresses, instead of all picking new random addresses and 211 potentially having to resolve conflicts which arise. 213 3. Considerations for single-homed hosts 215 Some operating systems do not support a host having more than one 216 active IP address at a time. These hosts may have one externally 217 configured (e.g. manual or DHCP) IP address, or one self-configured 218 link-local address, but not both at the same time. 220 These hosts should only configure a link-local address on their 221 interface when other means of configuring an address have failed. For 222 example, if a host is set to obtain its address via DHCP, then after 223 attempting to contact a DHCP server for a reasonable period of time 224 and failing, it may elect instead to configure a link-local address. 226 Having elected to configure a link-local address, these hosts MUST 227 continue attempting to contact a DHCP server by sending periodic DHCP 228 DISCOVER packets. The host has no way of knowing whether it is on a 229 network with no DHCP service, or on a network where the DHCP server 230 was temporarily inaccessible or unresponsive. If the host receives a 231 response to one of its periodic DHCP DISCOVER packets, then a host 232 which is incapable of supporting more than one IP address at a time 233 should immediately cease using its link-local address and revert 234 to normal DHCP processing to configure a server-assigned address. 236 Immediate cessation of use of the link-local address may break active 237 TCP connections with other link-local peers, possibly causing user 238 data loss. This is why it is extremely beneficial for a host, even 239 if it cannot support true multi-homing, to at least support multiple 240 IP addresses on a single physical interface, so that it may maintain 241 its link-local address in addition to other addresses configured 242 by other means such as DHCP. 244 4. Considerations for multi-homed hosts 246 A multi-homed host may elect to configure an IPv4 link-local address 247 on only one of its active interfaces. In many situations this will be 248 adequate. However, should a host wish to configure IPv4 link-local 249 addresses on more than one of its active interfaces, there are some 250 additional precautions it should take. Implementers who are not 251 planning to support IPv4 link-local addresses on more than one 252 interface at a time may skip this section. 254 A multi-homed host MUST NOT forward IP datagrams it receives that 255 have source or destination addresses in the 169.254/16 range. 257 A multi-homed host should ensure that all of its links are configured 258 with different link-local addresses. If the random number generator 259 selects an address which is already in use on one of the host's other 260 interfaces, then another address should be selected. 262 A multi-homed host should also probe for, and defend, all of its 263 link-local addresses on all of its active interfaces that are using 264 link-local addresses. When bringing up a new interface, the host 265 should first probe for all of its existing link-local addresses on 266 that new interface. If any of the addresses are found to be in use 267 already on the new link, then the interfaces in question must be 268 reconfigured to select new unique link-local addresses. The host 269 should then select a link-local address for the new interface, and 270 probe on all of its active interfaces to verify that the address is 271 unique. This uniqueness requirement is in order to simplify host 272 application software, which typically identifies connections using 273 source and destination IP addresses, not interface names. Since 274 link-local addresses are only unique per-link, hosts on different 275 links could be using the same link-local address. By requiring 276 uniqueness of source addresses on the multi-homed host, this ensures 277 that TCP connections to hosts using the same link-local destination 278 addresses on different links can be disambiguated by their different 279 source addresses. 281 Figure 1 shows a network topology where host A has an interface on 282 link X with link-local address P, and another interface on link Y 283 with link-local address Q. If we allowed there to be another host, B, 284 on link X which also has address Q, then when host A sends a UDP 285 packet from source address P to destination address Q, it is 286 ambiguous whether A intends to talk to itself, or to host B. By 287 ensuring that all of a host's link-local addresses are distinct not 288 only from each other, but also from all addresses currently active on 289 all links that the host is connected to, we remove this ambiguity. 291 | | 292 | P ----- Q | 293 |-----| A |-----| 294 | ----- | 295 X | | Y 296 | | 297 ----- | | 298 | B |-----| | 299 ----- Q | | 300 | | 302 Figure 1. Ambiguous addressing 304 Note that it is acceptable for different hosts on different links to 305 be using the same link-local address on their respective separate 306 links. Figure 2 shows a network topology where host C on link X is 307 using address R, while at the same time, host D on link Y is also 308 using address R. This is entirely in keeping with the concept of 309 link-local addresses. Link-local addresses are only unique amongst 310 the member hosts of a single link. Hosts C and D are not on the same 311 link, hence there is no requirement for them to have distinct 312 addresses. Note that in this case, host A is still able to 313 communicate with both hosts C and D, because a packet sent from 314 source address P to destination address R travels on link X to host 315 C, and a packet sent from source address Q to destination address R 316 travels on link Y to host D. TCP connections are uniquely identified 317 by the source and destination addresses and port numbers, not just by 318 the destination address and port number alone. To support link-local 319 addressing on multiple interfaces simultaneously, the network 320 software API must allow applications to bind endpoints to a desired 321 source address as well as specifying the desired destination address 322 for a TCP connection. Networking implementations that only allow the 323 destination address to be specified should limit themselves to 324 configuring only one interface for link-local addressing. 326 | | 327 | P ----- Q | 328 |-----| A |-----| 329 | ----- | 330 X | | Y 331 | | 332 ----- | | ----- 333 | C |-----| |-----| D | 334 ----- R | | R ----- 335 | | 337 Figure 2. Acceptable addressing 339 5. Considerations for joining of previously separate networks 341 Hosts on disjoint network links may unknowingly configure the same 342 link-local addresses. If these separate network links are later 343 joined or bridged together, then there may be two hosts which are now 344 on the same link, trying to use the same address. When either host 345 attempts to communicate with any other host on the network, it will 346 at some point broadcast an ARP packet which will enable the hosts in 347 question to detect that there is a duplicate address. 349 If a host receives an ARP packet with its own IP address given as the 350 sender IP address, but a different sender hardware address, then the 351 host must treat this as an address collision and configure a new 352 link-local IP address as described in Section 2 above. 354 This forced reconfiguration may be disruptive, causing TCP 355 connections to be broken. However, it is expected that such 356 disruptions will be rare. It should be relatively uncommon for 357 networks to be joined while hosts on those networks are active. Also, 358 65024 addresses are available for link-local use, so even when two 359 small networks are joined, the chance of collision for any given host 360 is fairly small. When joining two large networks there is a greater 361 chance of collision, but large networks are not expected to rely 362 heavily on link-local addresses for normal communication. Large 363 networks are better managed by using existing mechanisms such as DHCP 364 servers to allocate addresses. 366 6. Current Vendor Implementations 368 As of this writing, Microsoft and Apple have operating systems that 369 contain this functionality. Descriptions of the implementations are 370 listed below. 372 6.1. Apple Mac OS 8.5 and later. 374 Mac OS versions up to and including Mac OS 9 are single-homed 375 systems. They support one externally configured IP address, or one 376 self-configured link-local address, but not both at the same time. As 377 a result, they will give up their link-local address when a working 378 DHCP server is found on the network. 380 Mac OS sends four DHCP DISCOVER packets, with timeouts of 1, 2, 4, 8, 381 seconds. When no response is received from all of these requests (15 382 seconds), it will self-configure a link-local address. After 383 successfully configuring a link-local address, Mac OS continues to 384 attempt to locate a DHCP server, sending DHCP DISCOVER packets every 385 five minutes. 387 6.2. Microsoft Windows 98 and later. 389 Windows 98 is a single-homed system. It supports one externally 390 configured IP address, or one self-configured link-local address, but 391 not both at the same time. As a result, it will give up its 392 link-local address when a working DHCP server is found on the 393 network. 395 Windows 98 sends four DHCP DISCOVER packets, with an inter-packet 396 interval of 6 seconds. When no response is received after all 4 397 packets (24 seconds), it will self-configure a link-local address. 398 After successfully configuring a link-local address, Windows 98 399 continues to attempt to locate a DHCP server, sending DHCP DISCOVER 400 packets every five minutes. 402 7. Security Considerations 404 The use of this functionality may open a network host to new attacks. 405 In particular, a host that previously did not have an IP address, and 406 no IP stack running, was not susceptible to IP-based attacks. By 407 configuring a working address, the host may now be vulnerable to 408 IP-based attacks. 410 The ARP protocol [RFC 826] is insecure. A malicious host may send 411 fraudulent ARP packets on the network, interfering with the correct 412 operation of other hosts. For example, it is easy for a host to 413 answer all ARP requests with responses giving its own hardware 414 address, thereby claiming ownership of every address on the network. 416 8. Acknowledgements 418 I'd like to thank Ryan Troll for his help in this process of 419 documenting the use of link-local addresses by Mac OS and Microsoft 420 Windows. 422 I'd like to thank Peter Ford for his contributions, implementing IPv4 423 link-local addresses in Microsoft Windows, and making the 424 implementation information available in this document. 426 I'd like to thank Erik Guttman for his comments on the draft. 428 9. Copyright 430 Copyright (C) The Internet Society 8th March 2000. 431 All Rights Reserved. 433 This document and translations of it may be copied and furnished to 434 others, and derivative works that comment on or otherwise explain it 435 or assist in its implementation may be prepared, copied, published and 436 distributed, in whole or in part, without restriction of any kind, 437 provided that the above copyright notice and this paragraph are 438 included on all such copies and derivative works. However, this 439 document itself may not be modified in any way, such as by removing 440 the copyright notice or references to the Internet Society or other 441 Internet organizations, except as needed for the purpose of 442 developing Internet standards in which case the procedures for 443 copyrights defined in the Internet Standards process must be 444 followed, or as required to translate it into languages other than 445 English. 447 The limited permissions granted above are perpetual and will not be 448 revoked by the Internet Society or its successors or assigns. 450 This document and the information contained herein is provided on an 451 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 452 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 453 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 454 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 455 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 457 10. References 459 [RFC 826] Plummer, D. "An Ethernet Address Resolution Protocol -or- 460 Converting Network Addresses to 48-bit Ethernet Address 461 for Transmission on Ethernet Hardware", STD 37, RFC 826, 462 November 1982. 464 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 465 Requirement Levels", RFC 2119, March 1997 467 [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 468 March 1997 470 [RFC 2462] Thomson, S. and Narten, T., "IPv6 Stateless Address 471 Autoconfiguration", RFC 2462, December 1998 473 11. Author's Address 475 Stuart Cheshire 476 Apple Computer, Inc. 477 1 Infinite Loop 478 Cupertino 479 California 95014 480 USA 482 Phone: +1 408 974 3207 483 EMail: cheshire@apple.com 485 Stuart Cheshire 486 * Web Page 487 * Wizard Without Portfolio, Apple Computer