1 2 3 4 5 6 7Network Working Group S. Cheshire 8Request for Comments: 3927 Apple Computer 9Category: Standards Track B. Aboba 10 Microsoft Corporation 11 E. Guttman 12 Sun Microsystems 13 May 2005 14 15 16 Dynamic Configuration of IPv4 Link-Local Addresses 17 18Status of This Memo 19 20 This document specifies an Internet standards track protocol for the 21 Internet community, and requests discussion and suggestions for 22 improvements. Please refer to the current edition of the "Internet 23 Official Protocol Standards" (STD 1) for the standardization state 24 and status of this protocol. Distribution of this memo is unlimited. 25 26Copyright Notice 27 28 Copyright (C) The Internet Society (2005). 29 30 31Abstract 32 33 To participate in wide-area IP networking, a host needs to be 34 configured with IP addresses for its interfaces, either manually by 35 the user or automatically from a source on the network such as a 36 Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, 37 such address configuration information may not always be available. 38 It is therefore beneficial for a host to be able to depend on a 39 useful subset of IP networking functions even when no address 40 configuration is available. This document describes how a host may 41 automatically configure an interface with an IPv4 address within the 42 169.254/16 prefix that is valid for communication with other devices 43 connected to the same physical (or logical) link. 44 45 IPv4 Link-Local addresses are not suitable for communication with 46 devices not directly connected to the same physical (or logical) 47 link, and are only used where stable, routable addresses are not 48 available (such as on ad hoc or isolated networks). This document 49 does not recommend that IPv4 Link-Local addresses and routable 50 addresses be configured simultaneously on the same interface. 51 52 53 54 55 56 57 58Cheshire, et al. Standards Track [Page 1] 59 60RFC 3927 IPv4 Link-Local May 2005 61 62 63Table of Contents 64 65 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements. . . . . . . . . . . . . . . . . . . . . . 3 67 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 3 68 1.3. Applicability . . . . . . . . . . . . . . . . . . . . . 5 69 1.4. Application Layer Protocol Considerations . . . . . . . 6 70 1.5. Autoconfiguration Issues. . . . . . . . . . . . . . . . 7 71 1.6. Alternate Use Prohibition . . . . . . . . . . . . . . . 7 72 1.7. Multiple Interfaces . . . . . . . . . . . . . . . . . . 8 73 1.8. Communication with Routable Addresses . . . . . . . . . 8 74 1.9. When to configure an IPv4 Link-Local Address. . . . . . 8 75 2. Address Selection, Defense and Delivery . . . . . . . . . . . 9 76 2.1. Link-Local Address Selection. . . . . . . . . . . . . . 10 77 2.2. Claiming a Link-Local Address . . . . . . . . . . . . . 11 78 2.3. Shorter Timeouts. . . . . . . . . . . . . . . . . . . . 13 79 2.4. Announcing an Address . . . . . . . . . . . . . . . . . 13 80 2.5. Conflict Detection and Defense. . . . . . . . . . . . . 13 81 2.6. Address Usage and Forwarding Rules. . . . . . . . . . . 14 82 2.7. Link-Local Packets Are Not Forwarded. . . . . . . . . . 16 83 2.8. Link-Local Packets are Local. . . . . . . . . . . . . . 16 84 2.9. Higher-Layer Protocol Considerations. . . . . . . . . . 17 85 2.10. Privacy Concerns. . . . . . . . . . . . . . . . . . . . 17 86 2.11. Interaction between DHCPv4 and IPv4 Link-Local 87 State Machines. . . . . . . . . . . . . . . . . . . . . 17 88 3. Considerations for Multiple Interfaces. . . . . . . . . . . . 18 89 3.1. Scoped Addresses. . . . . . . . . . . . . . . . . . . . 18 90 3.2. Address Ambiguity . . . . . . . . . . . . . . . . . . . 19 91 3.3. Interaction with Hosts with Routable Addresses. . . . . 20 92 3.4. Unintentional Autoimmune Response . . . . . . . . . . . 21 93 4. Healing of Network Partitions . . . . . . . . . . . . . . . . 22 94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 95 6. Application Programming Considerations. . . . . . . . . . . . 24 96 6.1. Address Changes, Failure and Recovery . . . . . . . . . 24 97 6.2. Limited Forwarding of Locators. . . . . . . . . . . . . 24 98 6.3. Address Ambiguity . . . . . . . . . . . . . . . . . . . 25 99 7. Router Considerations . . . . . . . . . . . . . . . . . . . . 25 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 101 9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 26 102 10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 26 103 10.1. Normative References. . . . . . . . . . . . . . . . . . 26 104 10.2. Informative References. . . . . . . . . . . . . . . . . 26 105 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27 106 Appendix A - Prior Implementations. . . . . . . . . . . . . . . . 28 107 108 109 110 111 112 113 114Cheshire, et al. Standards Track [Page 2] 115 116RFC 3927 IPv4 Link-Local May 2005 117 118 1191. Introduction 120 121 As the Internet Protocol continues to grow in popularity, it becomes 122 increasingly valuable to be able to use familiar IP tools such as FTP 123 not only for global communication, but for local communication as 124 well. For example, two people with laptop computers supporting IEEE 125 802.11 Wireless LANs [802.11] may meet and wish to exchange files. 126 It is desirable for these people to be able to use IP application 127 software without the inconvenience of having to manually configure 128 static IP addresses or set up a DHCP server [RFC2131]. 129 130 This document describes a method by which a host may automatically 131 configure an interface with an IPv4 address in the 169.254/16 prefix 132 that is valid for Link-Local communication on that interface. This 133 is especially valuable in environments where no other configuration 134 mechanism is available. The IPv4 prefix 169.254/16 is registered 135 with the IANA for this purpose. Allocation of IPv6 Link-Local 136 addresses is described in "IPv6 Stateless Address Autoconfiguration" 137 [RFC2462]. 138 139 Link-Local communication using IPv4 Link-Local addresses is only 140 suitable for communication with other devices connected to the same 141 physical (or logical) link. Link-Local communication using IPv4 142 Link-Local addresses is not suitable for communication with devices 143 not directly connected to the same physical (or logical) link. 144 145 Microsoft Windows 98 (and later) and Mac OS 8.5 (and later) already 146 support this capability. This document standardizes usage, 147 prescribing rules for how IPv4 Link-Local addresses are to be treated 148 by hosts and routers. In particular, it describes how routers are to 149 behave when receiving packets with IPv4 Link-Local addresses in the 150 source or destination address. With respect to hosts, it discusses 151 claiming and defending addresses, maintaining Link-Local and routable 152 IPv4 addresses on the same interface, and multi-homing issues. 153 1541.1. Requirements 155 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in "Key words for use in 159 RFCs" [RFC2119]. 160 1611.2. Terminology 162 163 This document describes Link-Local addressing, for IPv4 communication 164 between two hosts on a single link. A set of hosts is considered to 165 be "on the same link", if: 166 167 168 169 170Cheshire, et al. Standards Track [Page 3] 171 172RFC 3927 IPv4 Link-Local May 2005 173 174 175 - when any host A from that set sends a packet to any other host B 176 in that set, using unicast, multicast, or broadcast, the entire 177 link-layer packet payload arrives unmodified, and 178 179 - a broadcast sent over that link by any host from that set of hosts 180 can be received by every other host in that set 181 182 The link-layer *header* may be modified, such as in Token Ring Source 183 Routing [802.5], but not the link-layer *payload*. In particular, if 184 any device forwarding a packet modifies any part of the IP header or 185 IP payload then the packet is no longer considered to be on the same 186 link. This means that the packet may pass through devices such as 187 repeaters, bridges, hubs or switches and still be considered to be on 188 the same link for the purpose of this document, but not through a 189 device such as an IP router that decrements the TTL or otherwise 190 modifies the IP header. 191 192 This document uses the term "routable address" to refer to all valid 193 unicast IPv4 addresses outside the 169.254/16 prefix that may be 194 forwarded via routers. This includes all global IP addresses and 195 private addresses such as Net 10/8 [RFC1918], but not loopback 196 addresses such as 127.0.0.1. 197 198 Wherever this document uses the term "host" when describing use of 199 IPv4 Link-Local addresses, the text applies equally to routers when 200 they are the source of or intended destination of packets containing 201 IPv4 Link-Local source or destination addresses. 202 203 Wherever this document uses the term "sender IP address" or "target 204 IP address" in the context of an ARP packet, it is referring to the 205 fields of the ARP packet identified in the ARP specification [RFC826] 206 as "ar$spa" (Sender Protocol Address) and "ar$tpa" (Target Protocol 207 Address) respectively. For the usage of ARP described in this 208 document, each of these fields always contains an IP address. 209 210 In this document, the term "ARP Probe" is used to refer to an ARP 211 Request packet, broadcast on the local link, with an all-zero 'sender 212 IP address'. The 'sender hardware address' MUST contain the hardware 213 address of the interface sending the packet. The 'target hardware 214 address' field is ignored and SHOULD be set to all zeroes. The 215 'target IP address' field MUST be set to the address being probed. 216 217 In this document, the term "ARP Announcement" is used to refer to an 218 ARP Request packet, broadcast on the local link, identical to the ARP 219 Probe described above, except that both the sender and target IP 220 address fields contain the IP address being announced. 221 222 223 224 225 226Cheshire, et al. Standards Track [Page 4] 227 228RFC 3927 IPv4 Link-Local May 2005 229 230 231 Constants are introduced in all capital letters. Their values are 232 given in Section 9. 233 2341.3. Applicability 235 236 This specification applies to all IEEE 802 Local Area Networks (LANs) 237 [802], including Ethernet [802.3], Token-Ring [802.5] and IEEE 802.11 238 wireless LANs [802.11], as well as to other link-layer technologies 239 that operate at data rates of at least 1 Mbps, have a round-trip 240 latency of at most one second, and support ARP [RFC826]. Wherever 241 this document uses the term "IEEE 802", the text applies equally to 242 any of these network technologies. 243 244 Link-layer technologies that support ARP but operate at rates below 1 245 Mbps or latencies above one second may need to specify different 246 values for the following parameters: 247 248 (a) the number of, and interval between, ARP probes, see PROBE_NUM, 249 PROBE_MIN, PROBE_MAX defined in Section 2.2.1 250 251 (b) the number of, and interval between, ARP announcements, see 252 ANNOUNCE_NUM and ANNOUNCE_INTERVAL defined in Section 2.4 253 254 (c) the maximum rate at which address claiming may be attempted, see 255 RATE_LIMIT_INTERVAL and MAX_CONFLICTS defined in Section 2.2.1 256 257 (d) the time interval between conflicting ARPs below which a host 258 MUST reconfigure instead of attempting to defend its address, see 259 DEFEND_INTERVAL defined in Section 2.5 260 261 Link-layer technologies that do not support ARP may be able to use 262 other techniques for determining whether a particular IP address is 263 currently in use. However, the application of claim-and-defend 264 mechanisms to such networks is outside the scope of this document. 265 266 This specification is intended for use with small ad hoc networks -- 267 a single link containing only a few hosts. Although 65024 IPv4 268 Link-Local addresses are available in principle, attempting to use 269 all those addresses on a single link would result in a high 270 probability of address conflicts, requiring a host to take an 271 inordinate amount of time to find an available address. 272 273 Network operators with more than 1300 hosts on a single link may want 274 to consider dividing that single link into two or more subnets. A 275 host connecting to a link that already has 1300 hosts, selecting an 276 IPv4 Link-Local address at random, has a 98% chance of selecting an 277 unused IPv4 Link-Local address on the first try. A host has a 99.96% 278 279 280 281 282Cheshire, et al. Standards Track [Page 5] 283 284RFC 3927 IPv4 Link-Local May 2005 285 286 287 chance of selecting an unused IPv4 Link-Local address within two 288 tries. The probability that it will have to try more than ten times 289 is about 1 in 10^17. 290 2911.4. Application Layer Protocol Considerations 292 293 IPv4 Link-Local addresses and their dynamic configuration have 294 profound implications upon applications which use them. This is 295 discussed in Section 6. Many applications fundamentally assume that 296 addresses of communicating peers are routable, relatively unchanging 297 and unique. These assumptions no longer hold with IPv4 Link-Local 298 addresses, or a mixture of Link-Local and routable IPv4 addresses. 299 300 Therefore while many applications will work properly with IPv4 Link- 301 Local addresses, or a mixture of Link-Local and routable IPv4 302 addresses, others may do so only after modification, or will exhibit 303 reduced or partial functionality. 304 305 In some cases it may be infeasible for the application to be modified 306 to operate under such conditions. 307 308 IPv4 Link-Local addresses should therefore only be used where stable, 309 routable addresses are not available (such as on ad hoc or isolated 310 networks) or in controlled situations where these limitations and 311 their impact on applications are understood and accepted. This 312 document does not recommend that IPv4 Link-Local addresses and 313 routable addresses be configured simultaneously on the same 314 interface. 315 316 Use of IPv4 Link-Local addresses in off-link communication is likely 317 to cause application failures. This can occur within any application 318 that includes embedded addresses, if an IPv4 Link-Local address is 319 embedded when communicating with a host that is not on the link. 320 Examples of applications that embed addresses include IPsec, Kerberos 321 4/5, FTP, RSVP, SMTP, SIP, X-Windows/Xterm/Telnet, Real Audio, H.323, 322 and SNMP [RFC3027]. 323 324 To preclude use of IPv4 Link-Local addresses in off-link 325 communication, the following cautionary measures are advised: 326 327 a. IPv4 Link-Local addresses MUST NOT be configured in the DNS. 328 Mapping from IPv4 addresses to host names is conventionally done 329 by issuing DNS queries for names of the form, 330 "x.x.x.x.in-addr.arpa." When used for link-local addresses, which 331 have significance only on the local link, it is inappropriate to 332 send such DNS queries beyond the local link. DNS clients MUST NOT 333 send DNS queries for any name that falls within the 334 "254.169.in-addr.arpa." domain. 335 336 337 338Cheshire, et al. Standards Track [Page 6] 339 340RFC 3927 IPv4 Link-Local May 2005 341 342 343 DNS recursive name servers receiving queries from non-compliant 344 clients for names within the "254.169.in-addr.arpa." domain MUST 345 by default return RCODE 3, authoritatively asserting that no such 346 name exists in the Domain Name System. 347 348 b. Names that are globally resolvable to routable addresses should be 349 used within applications whenever they are available. Names that 350 are resolvable only on the local link (such as through use of 351 protocols such as Link Local Multicast Name Resolution [LLMNR]) 352 MUST NOT be used in off-link communication. IPv4 addresses and 353 names that can only be resolved on the local link SHOULD NOT be 354 forwarded beyond the local link. IPv4 Link-Local addresses SHOULD 355 only be sent when a Link-Local address is used as the source 356 and/or destination address. This strong advice should hinder 357 limited scope addresses and names from leaving the context in 358 which they apply. 359 360 c. If names resolvable to globally routable addresses are not 361 available, but the globally routable addresses are, they should be 362 used instead of IPv4 Link-Local addresses. 363 3641.5. Autoconfiguration Issues 365 366 Implementations of IPv4 Link-Local address autoconfiguration MUST 367 expect address conflicts, and MUST be prepared to handle them 368 gracefully by automatically selecting a new address whenever a 369 conflict is detected, as described in Section 2. This requirement to 370 detect and handle address conflicts applies during the entire period 371 that a host is using a 169.254/16 IPv4 Link-Local address, not just 372 during initial interface configuration. For example, address 373 conflicts can occur well after a host has completed booting if two 374 previously separate networks are joined, as described in Section 4. 375 3761.6. Alternate Use Prohibition 377 378 Note that addresses in the 169.254/16 prefix SHOULD NOT be configured 379 manually or by a DHCP server. Manual or DHCP configuration may cause 380 a host to use an address in the 169.254/16 prefix without following 381 the special rules regarding duplicate detection and automatic 382 configuration that pertain to addresses in this prefix. While the 383 DHCP specification [RFC2131] indicates that a DHCP client SHOULD 384 probe a newly received address with ARP, this is not mandatory. 385 Similarly, while the DHCP specification recommends that a DHCP server 386 SHOULD probe an address using an ICMP Echo Request before allocating 387 it, this is also not mandatory, and even if the server does this, 388 IPv4 Link-Local addresses are not routable, so a DHCP server not 389 directly connected to a link cannot detect whether a host on that 390 link is already using the desired IPv4 Link-Local address. 391 392 393 394Cheshire, et al. Standards Track [Page 7] 395 396RFC 3927 IPv4 Link-Local May 2005 397 398 399 Administrators wishing to configure their own local addresses (using 400 manual configuration, a DHCP server, or any other mechanism not 401 described in this document) should use one of the existing private 402 address prefixes [RFC1918], not the 169.254/16 prefix. 403 4041.7. Multiple Interfaces 405 406 Additional considerations apply to hosts that support more than one 407 active interface where one or more of these interfaces support IPv4 408 Link-Local address configuration. These considerations are discussed 409 in Section 3. 410 4111.8. Communication with Routable Addresses 412 413 There will be cases when devices with a configured Link-Local address 414 will need to communicate with a device with a routable address 415 configured on the same physical link, and vice versa. The rules in 416 Section 2.6 allow this communication. 417 418 This allows, for example, a laptop computer with only a routable 419 address to communicate with web servers world-wide using its 420 globally-routable address while at the same time printing those web 421 pages on a local printer that has only an IPv4 Link-Local address. 422 4231.9. When to configure an IPv4 Link-Local address 424 425 Having addresses of multiple different scopes assigned to an 426 interface, with no adequate way to determine in what circumstances 427 each address should be used, leads to complexity for applications and 428 confusion for users. A host with an address on a link can 429 communicate with all other devices on that link, whether those 430 devices use Link-Local addresses, or routable addresses. For these 431 reasons, a host SHOULD NOT have both an operable routable address and 432 an IPv4 Link-Local address configured on the same interface. The 433 term "operable address" is used to mean an address which works 434 effectively for communication in the current network context (see 435 below). When an operable routable address is available on an 436 interface, the host SHOULD NOT also assign an IPv4 Link-Local address 437 on that interface. However, during the transition (in either 438 direction) between using routable and IPv4 Link-Local addresses both 439 MAY be in use at once subject to these rules: 440 441 1. The assignment of an IPv4 Link-Local address on an interface is 442 based solely on the state of the interface, and is independent 443 of any other protocols such as DHCP. A host MUST NOT alter its 444 behavior and use of other protocols such as DHCP because the 445 host has assigned an IPv4 Link-Local address to an interface. 446 447 448 449 450Cheshire, et al. Standards Track [Page 8] 451 452RFC 3927 IPv4 Link-Local May 2005 453 454 455 2. If a host finds that an interface that was previously 456 configured with an IPv4 Link-Local address now has an operable 457 routable address available, the host MUST use the routable 458 address when initiating new communications, and MUST cease 459 advertising the availability of the IPv4 Link-Local address 460 through whatever mechanisms that address had been made known to 461 others. The host SHOULD continue to use the IPv4 Link-Local 462 address for communications already underway, and MAY continue 463 to accept new communications addressed to the IPv4 Link-Local 464 address. Ways in which an operable routable address might 465 become available on an interface include: 466 467 * Manual configuration 468 * Address assignment through DHCP 469 * Roaming of the host to a network on which a previously 470 assigned address becomes operable 471 472 3. If a host finds that an interface no longer has an operable 473 routable address available, the host MAY identify a usable IPv4 474 Link-Local address (as described in section 2) and assign that 475 address to the interface. Ways in which an operable routable 476 address might cease to be available on an interface include: 477 478 * Removal of the address from the interface through 479 manual configuration 480 * Expiration of the lease on the address assigned through 481 DHCP 482 * Roaming of the host to a new network on which the 483 address is no longer operable. 484 485 The determination by the system of whether an address is "operable" 486 is not clear cut and many changes in the system context (e.g., 487 router changes) may affect the operability of an address. In 488 particular roaming of a host from one network to another is likely -- 489 but not certain -- to change the operability of a configured address 490 but detecting such a move is not always trivial. 491 492 "Detection of Network Attachment (DNA) in IPv4" [DNAv4] provides 493 further discussion of address assignment and operability 494 determination. 495 4962. Address Selection, Defense and Delivery 497 498 The following section explains the IPv4 Link-Local address selection 499 algorithm, how IPv4 Link-Local addresses are defended, and how IPv4 500 packets with IPv4 Link-Local addresses are delivered. 501 502 503 504 505 506Cheshire, et al. Standards Track [Page 9] 507 508RFC 3927 IPv4 Link-Local May 2005 509 510 511 Windows and Mac OS hosts that already implement Link-Local IPv4 512 address auto-configuration are compatible with the rules presented in 513 this section. However, should any interoperability problem be 514 discovered, this document, not any prior implementation, defines the 515 standard. 516 5172.1. Link-Local Address Selection 518 519 When a host wishes to configure an IPv4 Link-Local address, it 520 selects an address using a pseudo-random number generator with a 521 uniform distribution in the range from 169.254.1.0 to 169.254.254.255 522 inclusive. 523 524 The IPv4 prefix 169.254/16 is registered with the IANA for this 525 purpose. The first 256 and last 256 addresses in the 169.254/16 526 prefix are reserved for future use and MUST NOT be selected by a host 527 using this dynamic configuration mechanism. 528 529 The pseudo-random number generation algorithm MUST be chosen so that 530 different hosts do not generate the same sequence of numbers. If the 531 host has access to persistent information that is different for each 532 host, such as its IEEE 802 MAC address, then the pseudo-random number 533 generator SHOULD be seeded using a value derived from this 534 information. This means that even without using any other persistent 535 storage, a host will usually select the same IPv4 Link-Local address 536 each time it is booted, which can be convenient for debugging and 537 other operational reasons. Seeding the pseudo-random number 538 generator using the real-time clock or any other information which is 539 (or may be) identical in every host is NOT suitable for this purpose, 540 because a group of hosts that are all powered on at the same time 541 might then all generate the same sequence, resulting in a never- 542 ending series of conflicts as the hosts move in lock-step through 543 exactly the same pseudo-random sequence, conflicting on every address 544 they probe. 545 546 Hosts that are equipped with persistent storage MAY, for each 547 interface, record the IPv4 address they have selected. On booting, 548 hosts with a previously recorded address SHOULD use that address as 549 their first candidate when probing. This increases the stability of 550 addresses. For example, if a group of hosts are powered off at 551 night, then when they are powered on the next morning they will all 552 resume using the same addresses, instead of picking different 553 addresses and potentially having to resolve conflicts that arise. 554 555 556 557 558 559 560 561 562Cheshire, et al. Standards Track [Page 10] 563 564RFC 3927 IPv4 Link-Local May 2005 565 566 5672.2. Claiming a Link-Local Address 568 569 After it has selected an IPv4 Link-Local address, a host MUST test to 570 see if the IPv4 Link-Local address is already in use before beginning 571 to use it. When a network interface transitions from an inactive to 572 an active state, the host does not have knowledge of what IPv4 Link- 573 Local addresses may currently be in use on that link, since the point 574 of attachment may have changed or the network interface may have been 575 inactive when a conflicting address was claimed. 576 577 Were the host to immediately begin using an IPv4 Link-Local address 578 which is already in use by another host, this would be disruptive to 579 that other host. Since it is possible that the host has changed its 580 point of attachment, a routable address may be obtainable on the new 581 network, and therefore it cannot be assumed that an IPv4 Link-Local 582 address is to be preferred. 583 584 Before using the IPv4 Link-Local address (e.g., using it as the 585 source address in an IPv4 packet, or as the Sender IPv4 address in an 586 ARP packet) a host MUST perform the probing test described below to 587 achieve better confidence that using the IPv4 Link-Local address will 588 not cause disruption. 589 590 Examples of events that involve an interface becoming active include: 591 592 Reboot/startup 593 Wake from sleep (if network interface was inactive during sleep) 594 Bringing up previously inactive network interface 595 IEEE 802 hardware link-state change (appropriate for the 596 media type and security mechanisms which apply) indicates 597 that an interface has become active. 598 Association with a wireless base station or ad hoc network. 599 600 A host MUST NOT perform this check periodically as a matter of 601 course. This would be a waste of network bandwidth, and is 602 unnecessary due to the ability of hosts to passively discover 603 conflicts, as described in Section 2.5. 604 6052.2.1. Probe details 606 607 On a link-layer such as IEEE 802 that supports ARP, conflict 608 detection is done using ARP probes. On link-layer technologies that 609 do not support ARP other techniques may be available for determining 610 whether a particular IPv4 address is currently in use. However, the 611 application of claim-and-defend mechanisms to such networks is 612 outside the scope of this document. 613 614 615 616 617 618Cheshire, et al. Standards Track [Page 11] 619 620RFC 3927 IPv4 Link-Local May 2005 621 622 623 A host probes to see if an address is already in use by broadcasting 624 an ARP Request for the desired address. The client MUST fill in the 625 'sender hardware address' field of the ARP Request with the hardware 626 address of the interface through which it is sending the packet. The 627 'sender IP address' field MUST be set to all zeroes, to avoid 628 polluting ARP caches in other hosts on the same link in the case 629 where the address turns out to be already in use by another host. 630 The 'target hardware address' field is ignored and SHOULD be set to 631 all zeroes. The 'target IP address' field MUST be set to the address 632 being probed. An ARP Request constructed this way with an all-zero 633 'sender IP address' is referred to as an "ARP Probe". 634 635 When ready to begin probing, the host should then wait for a random 636 time interval selected uniformly in the range zero to PROBE_WAIT 637 seconds, and should then send PROBE_NUM probe packets, each of these 638 probe packets spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. 639 If during this period, from the beginning of the probing process 640 until ANNOUNCE_WAIT seconds after the last probe packet is sent, the 641 host receives any ARP packet (Request *or* Reply) on the interface 642 where the probe is being performed where the packet's 'sender IP 643 address' is the address being probed for, then the host MUST treat 644 this address as being in use by some other host, and MUST select a 645 new pseudo-random address and repeat the process. In addition, if 646 during this period the host receives any ARP Probe where the packet's 647 'target IP address' is the address being probed for, and the packet's 648 'sender hardware address' is not the hardware address of the 649 interface the host is attempting to configure, then the host MUST 650 similarly treat this as an address conflict and select a new address 651 as above. This can occur if two (or more) hosts attempt to configure 652 the same IPv4 Link-Local address at the same time. 653 654 A host should maintain a counter of the number of address conflicts 655 it has experienced in the process of trying to acquire an address, 656 and if the number of conflicts exceeds MAX_CONFLICTS then the host 657 MUST limit the rate at which it probes for new addresses to no more 658 than one new address per RATE_LIMIT_INTERVAL. This is to prevent 659 catastrophic ARP storms in pathological failure cases, such as a 660 rogue host that answers all ARP probes, causing legitimate hosts to 661 go into an infinite loop attempting to select a usable address. 662 663 If, by ANNOUNCE_WAIT seconds after the transmission of the last ARP 664 Probe no conflicting ARP Reply or ARP Probe has been received, then 665 the host has successfully claimed the desired IPv4 Link-Local 666 address. 667 668 669 670 671 672 673 674Cheshire, et al. Standards Track [Page 12] 675 676RFC 3927 IPv4 Link-Local May 2005 677 678 6792.3. Shorter Timeouts 680 681 Network technologies may emerge for which shorter delays are 682 appropriate than those required by this document. A subsequent IETF 683 publication may be produced providing guidelines for different values 684 for PROBE_WAIT, PROBE_NUM, PROBE_MIN and PROBE_MAX on those 685 technologies. 686 6872.4. Announcing an Address 688 689 Having probed to determine a unique address to use, the host MUST 690 then announce its claimed address by broadcasting ANNOUNCE_NUM ARP 691 announcements, spaced ANNOUNCE_INTERVAL seconds apart. An ARP 692 announcement is identical to the ARP Probe described above, except 693 that now the sender and target IP addresses are both set to the 694 host's newly selected IPv4 address. The purpose of these ARP 695 announcements is to make sure that other hosts on the link do not 696 have stale ARP cache entries left over from some other host that may 697 previously have been using the same address. 698 6992.5. Conflict Detection and Defense 700 701 Address conflict detection is not limited to the address selection 702 phase, when a host is sending ARP probes. Address conflict detection 703 is an ongoing process that is in effect for as long as a host is 704 using an IPv4 Link-Local address. At any time, if a host receives an 705 ARP packet (request *or* reply) on an interface where the 'sender IP 706 address' is the IP address the host has configured for that 707 interface, but the 'sender hardware address' does not match the 708 hardware address of that interface, then this is a conflicting ARP 709 packet, indicating an address conflict. 710 711 A host MUST respond to a conflicting ARP packet as described in 712 either (a) or (b) below: 713 714 (a) Upon receiving a conflicting ARP packet, a host MAY elect to 715 immediately configure a new IPv4 Link-Local address as described 716 above, or 717 718 (b) If a host currently has active TCP connections or other reasons 719 to prefer to keep the same IPv4 address, and it has not seen any 720 other conflicting ARP packets within the last DEFEND_INTERVAL 721 seconds, then it MAY elect to attempt to defend its address by 722 recording the time that the conflicting ARP packet was received, and 723 then broadcasting one single ARP announcement, giving its own IP and 724 hardware addresses as the sender addresses of the ARP. Having done 725 this, the host can then continue to use the address normally without 726 any further special action. However, if this is not the first 727 728 729 730Cheshire, et al. Standards Track [Page 13] 731 732RFC 3927 IPv4 Link-Local May 2005 733 734 735 conflicting ARP packet the host has seen, and the time recorded for 736 the previous conflicting ARP packet is recent, within DEFEND_INTERVAL 737 seconds, then the host MUST immediately cease using this address and 738 configure a new IPv4 Link-Local address as described above. This is 739 necessary to ensure that two hosts do not get stuck in an endless 740 loop with both hosts trying to defend the same address. 741 742 A host MUST respond to conflicting ARP packets as described in either 743 (a) or (b) above. A host MUST NOT ignore conflicting ARP packets. 744 745 Forced address reconfiguration may be disruptive, causing TCP 746 connections to be broken. However, it is expected that such 747 disruptions will be rare, and if inadvertent address duplication 748 happens, then disruption of communication is inevitable, no matter 749 how the addresses were assigned. It is not possible for two 750 different hosts using the same IP address on the same network to 751 operate reliably. 752 753 Before abandoning an address due to a conflict, hosts SHOULD actively 754 attempt to reset any existing connections using that address. This 755 mitigates some security threats posed by address reconfiguration, as 756 discussed in Section 5. 757 758 Immediately configuring a new address as soon as the conflict is 759 detected is the best way to restore useful communication as quickly 760 as possible. The mechanism described above of broadcasting a single 761 ARP announcement to defend the address mitigates the problem 762 somewhat, by helping to improve the chance that one of the two 763 conflicting hosts may be able to retain its address. 764 765 All ARP packets (*replies* as well as requests) that contain a Link- 766 Local 'sender IP address' MUST be sent using link-layer broadcast 767 instead of link-layer unicast. This aids timely detection of 768 duplicate addresses. An example illustrating how this helps is given 769 in Section 4. 770 7712.6. Address Usage and Forwarding Rules 772 773 A host implementing this specification has additional rules to 774 conform to, whether or not it has an interface configured with an 775 IPv4 Link-Local address. 776 7772.6.1. Source Address Usage 778 779 Since each interface on a host may have an IPv4 Link-Local address in 780 addition to zero or more other addresses configured by other means 781 (e.g., manually or via a DHCP server), a host may have to make a 782 783 784 785 786Cheshire, et al. Standards Track [Page 14] 787 788RFC 3927 IPv4 Link-Local May 2005 789 790 791 choice about what source address to use when it sends a packet or 792 initiates a TCP connection. 793 794 Where both an IPv4 Link-Local and a routable address are available on 795 the same interface, the routable address should be preferred as the 796 source address for new communications, but packets sent from or to 797 the IPv4 Link-Local address are still delivered as expected. The 798 IPv4 Link-Local address may continue to be used as a source address 799 in communications where switching to a preferred address would cause 800 communications failure because of the requirements of an upper-layer 801 protocol (e.g., an existing TCP connection). For more details, see 802 Section 1.7. 803 804 A multi-homed host needs to select an outgoing interface whether or 805 not the destination is an IPv4 Link-Local address. Details of that 806 process are beyond the scope of this specification. After selecting 807 an interface, the multi-homed host should send packets involving IPv4 808 Link-Local addresses as specified in this document, as if the 809 selected interface were the host's only interface. See Section 3 for 810 further discussion of multi-homed hosts. 811 8122.6.2. Forwarding Rules 813 814 Whichever interface is used, if the destination address is in the 815 169.254/16 prefix (excluding the address 169.254.255.255, which is 816 the broadcast address for the Link-Local prefix), then the sender 817 MUST ARP for the destination address and then send its packet 818 directly to the destination on the same physical link. This MUST be 819 done whether the interface is configured with a Link-Local or a 820 routable IPv4 address. 821 822 In many network stacks, achieving this functionality may be as simple 823 as adding a routing table entry indicating that 169.254/16 is 824 directly reachable on the local link. This approach will not work 825 for routers or multi-homed hosts. Refer to section 3 for more 826 discussion of multi-homed hosts. 827 828 The host MUST NOT send a packet with an IPv4 Link-Local destination 829 address to any router for forwarding. 830 831 If the destination address is a unicast address outside the 832 169.254/16 prefix, then the host SHOULD use an appropriate routable 833 IPv4 source address, if it can. If for any reason the host chooses 834 to send the packet with an IPv4 Link-Local source address (e.g., no 835 routable address is available on the selected interface), then it 836 MUST ARP for the destination address and then send its packet, with 837 838 839 840 841 842Cheshire, et al. Standards Track [Page 15] 843 844RFC 3927 IPv4 Link-Local May 2005 845 846 847 an IPv4 Link-Local source address and a routable destination IPv4 848 address, directly to its destination on the same physical link. The 849 host MUST NOT send the packet to any router for forwarding. 850 851 In the case of a device with a single interface and only an Link- 852 Local IPv4 address, this requirement can be paraphrased as "ARP for 853 everything". 854 855 In many network stacks, achieving this "ARP for everything" behavior 856 may be as simple as having no primary IP router configured, having 857 the primary IP router address configured to 0.0.0.0, or having the 858 primary IP router address set to be the same as the host's own Link- 859 Local IPv4 address. For suggested behavior in multi-homed hosts, see 860 Section 3. 861 8622.7. Link-Local Packets Are Not Forwarded 863 864 A sensible default for applications which are sending from an IPv4 865 Link-Local address is to explicitly set the IPv4 TTL to 1. This is 866 not appropriate in all cases as some applications may require that 867 the IPv4 TTL be set to other values. 868 869 An IPv4 packet whose source and/or destination address is in the 870 169.254/16 prefix MUST NOT be sent to any router for forwarding, and 871 any network device receiving such a packet MUST NOT forward it, 872 regardless of the TTL in the IPv4 header. Similarly, a router or 873 other host MUST NOT indiscriminately answer all ARP Requests for 874 addresses in the 169.254/16 prefix. A router may of course answer 875 ARP Requests for one or more IPv4 Link-Local address(es) that it has 876 legitimately claimed for its own use according to the claim-and- 877 defend protocol described in this document. 878 879 This restriction also applies to multicast packets. IPv4 packets 880 with a Link-Local source address MUST NOT be forwarded outside the 881 local link even if they have a multicast destination address. 882 8832.8. Link-Local Packets are Local 884 885 The non-forwarding rule means that hosts may assume that all 886 169.254/16 destination addresses are "on-link" and directly 887 reachable. The 169.254/16 address prefix MUST NOT be subnetted. 888 This specification utilizes ARP-based address conflict detection, 889 which functions by broadcasting on the local subnet. Since such 890 broadcasts are not forwarded, were subnetting to be allowed then 891 address conflicts could remain undetected. 892 893 894 895 896 897 898Cheshire, et al. Standards Track [Page 16] 899 900RFC 3927 IPv4 Link-Local May 2005 901 902 903 This does not mean that Link-Local devices are forbidden from any 904 communication outside the local link. IP hosts that implement both 905 Link-Local and conventional routable IPv4 addresses may still use 906 their routable addresses without restriction as they do today. 907 9082.9. Higher-Layer Protocol Considerations 909 910 Similar considerations apply at layers above IP. 911 912 For example, designers of Web pages (including automatically 913 generated web pages) SHOULD NOT contain links with embedded IPv4 914 Link-Local addresses if those pages are viewable from hosts outside 915 the local link where the addresses are valid. 916 917 As IPv4 Link-Local addresses may change at any time and have limited 918 scope, IPv4 Link-Local addresses MUST NOT be stored in the DNS. 919 9202.10. Privacy Concerns 921 922 Another reason to restrict leakage of IPv4 Link-Local addresses 923 outside the local link is privacy concerns. If IPv4 Link-Local 924 addresses are derived from a hash of the MAC address, some argue that 925 they could be indirectly associated with an individual, and thereby 926 used to track that individual's activities. Within the local link 927 the hardware addresses in the packets are all directly observable, so 928 as long as IPv4 Link-Local addresses don't leave the local link they 929 provide no more information to an intruder than could be gained by 930 direct observation of hardware addresses. 931 9322.11. Interaction between DHCPv4 client and IPv4 Link-Local State 933 Machines 934 935 As documented in Appendix A, early implementations of IPv4 Link-Local 936 have modified the DHCP state machine. Field experience shows that 937 these modifications reduce the reliability of the DHCP service. 938 939 A device that implements both IPv4 Link-Local and a DHCPv4 client 940 should not alter the behavior of the DHCPv4 client to accommodate 941 IPv4 Link-Local configuration. In particular configuration of an 942 IPv4 Link-Local address, whether or not a DHCP server is currently 943 responding, is not sufficient reason to unconfigure a valid DHCP 944 lease, to stop the DHCP client from attempting to acquire a new IP 945 address, to change DHCP timeouts or to change the behavior of the 946 DHCP state machine in any other way. 947 948 Further discussion of this issue is provided in "Detection of Network 949 Attachment (DNA) in IPv4" [DNAv4]. 950 951 952 953 954Cheshire, et al. Standards Track [Page 17] 955 956RFC 3927 IPv4 Link-Local May 2005 957 958 9593. Considerations for Multiple Interfaces 960 961 The considerations outlined here also apply whenever a host has 962 multiple IP addresses, whether or not it has multiple physical 963 interfaces. Other examples of multiple interfaces include different 964 logical endpoints (tunnels, virtual private networks etc.) and 965 multiple logical networks on the same physical medium. This is often 966 referred to as "multi-homing". 967 968 Hosts which have more than one active interface and elect to 969 implement dynamic configuration of IPv4 Link-Local addresses on one 970 or more of those interfaces will face various problems. This section 971 lists these problems but does no more than indicate how one might 972 solve them. At the time of this writing, there is no silver bullet 973 which solves these problems in all cases, in a general way. 974 Implementors must think through these issues before implementing the 975 protocol specified in this document on a system which may have more 976 than one active interface as part of a TCP/IP stack capable of 977 multi-homing. 978 9793.1. Scoped Addresses 980 981 A host may be attached to more than one network at the same time. It 982 would be nice if there was a single address space used in every 983 network, but this is not the case. Addresses used in one network, be 984 it a network behind a NAT or a link on which IPv4 Link-Local 985 addresses are used, cannot be used in another network and have the 986 same effect. 987 988 It would also be nice if addresses were not exposed to applications, 989 but they are. Most software using TCP/IP which await messages 990 receives from any interface at a particular port number, for a 991 particular transport protocol. Applications are generally only aware 992 (and care) that they have received a message. The application knows 993 the address of the sender to which the application will reply. 994 995 The first scoped address problem is source address selection. A 996 multi-homed host has more than one address. Which address should be 997 used as the source address when sending to a particular destination? 998 This question is usually answered by referring to a routing table, 999 which expresses on which interface (with which address) to send, and 1000 how to send (should one forward to a router, or send directly). The 1001 choice is made complicated by scoped addresses because the address 1002 range in which the destination lies may be ambiguous. The table may 1003 not be able to yield a good answer. This problem is bound up with 1004 next-hop selection, which is discussed in Section 3.2. 1005 1006 1007 1008 1009 1010Cheshire, et al. Standards Track [Page 18] 1011 1012RFC 3927 IPv4 Link-Local May 2005 1013 1014 1015 The second scoped address problem arises from scoped parameters 1016 leaking outside their scope. This is discussed in Section 7. 1017 1018 It is possible to overcome these problems. One way is to expose 1019 scope information to applications such that they are always aware of 1020 what scope a peer is in. This way, the correct interface could be 1021 selected, and a safe procedure could be followed with respect to 1022 forwarding addresses and other scoped parameters. There are other 1023 possible approaches. None of these methods have been standardized 1024 for IPv4 nor are they specified in this document. A good API design 1025 could mitigate the problems, either by exposing address scopes to 1026 'scoped-address aware' applications or by cleverly encapsulating the 1027 scoping information and logic so that applications do the right thing 1028 without being aware of address scoping. 1029 1030 An implementer could undertake to solve these problems, but cannot 1031 simply ignore them. With sufficient experience, it is hoped that 1032 specifications will emerge explaining how to overcome scoped address 1033 multi-homing problems. 1034 10353.2. Address Ambiguity 1036 1037 This is a core problem with respect to IPv4 Link-Local destination 1038 addresses being reachable on more than one interface. What should a 1039 host do when it needs to send to Link-Local destination L and L can 1040 be resolved using ARP on more than one link? 1041 1042 Even if a Link-Local address can be resolved on only one link at a 1043 given moment, there is no guarantee that it will remain unambiguous 1044 in the future. Additional hosts on other interfaces may claim the 1045 address L as well. 1046 1047 One possibility is to support this only in the case where the 1048 application specifically expresses which interface to send from. 1049 1050 There is no standard or obvious solution to this problem. Existing 1051 application software written for the IPv4 protocol suite is largely 1052 incapable of dealing with address ambiguity. This does not preclude 1053 an implementer from finding a solution, writing applications which 1054 are able to use it, and providing a host which can support dynamic 1055 configuration of IPv4 Link-Local addresses on more than one 1056 interface. This solution will almost surely not be generally 1057 applicable to existing software and transparent to higher layers, 1058 however. 1059 1060 Given that the IP stack must have the outbound interface associated 1061 with a packet that needs to be sent to a Link-Local destination 1062 address, interface selection must occur. The outbound interface 1063 1064 1065 1066Cheshire, et al. Standards Track [Page 19] 1067 1068RFC 3927 IPv4 Link-Local May 2005 1069 1070 1071 cannot be derived from the packet's header parameters such as source 1072 or destination address (e.g., by using the forwarding table lookup). 1073 Therefore, outbound interface association must be done explicitly 1074 through other means. The specification does not stipulate those 1075 means. 1076 10773.3. Interaction with Hosts with Routable Addresses 1078 1079 Attention is paid in this specification to transition from the use of 1080 IPv4 Link-Local addresses to routable addresses (see Section 1.5). 1081 The intention is to allow a host with a single interface to first 1082 support Link-Local configuration then gracefully transition to the 1083 use of a routable address. Since the host transitioning to the use 1084 of a routable address may temporarily have more than one address 1085 active, the scoped address issues described in Section 3.1 will 1086 apply. When a host acquires a routable address, it does not need to 1087 retain its Link-Local address for the purpose of communicating with 1088 other devices on the link that are themselves using only Link-Local 1089 addresses: any host conforming to this specification knows that 1090 regardless of source address an IPv4 Link-Local destination must be 1091 reached by forwarding directly to the destination, not via a router; 1092 it is not necessary for that host to have a Link-Local source address 1093 in order to send to a Link-Local destination address. 1094 1095 A host with an IPv4 Link-Local address may send to a destination 1096 which does not have an IPv4 Link-Local address. If the host is not 1097 multi-homed, the procedure is simple and unambiguous: Using ARP and 1098 forwarding directly to on-link destinations is the default route. If 1099 the host is multi-homed, however, the routing policy is more complex, 1100 especially if one of the interfaces is configured with a routable 1101 address and the default route is (sensibly) directed at a router 1102 accessible through that interface. The following example illustrates 1103 this problem and provides a common solution to it. 1104 1105 i1 +---------+ i2 i3 +-------+ 1106 ROUTER-------= HOST1 =---------= HOST2 | 1107 link1 +---------+ link2 +-------+ 1108 1109 In the figure above, HOST1 is connected to link1 and link2. 1110 Interface i1 is configured with a routable address, while i2 is an 1111 IPv4 Link-Local address. HOST1 has its default route set to ROUTER's 1112 address, through i1. HOST1 will route to destinations in 169.254/16 1113 to i2, sending directly to the destination. 1114 1115 HOST2 has a configured (non-Link-Local) IPv4 address assigned to i3. 1116 1117 1118 1119 1120 1121 1122Cheshire, et al. Standards Track [Page 20] 1123 1124RFC 3927 IPv4 Link-Local May 2005 1125 1126 1127 Using a name resolution or service discovery protocol HOST1 can 1128 discover HOST2's address. Since HOST2's address is not in 1129 169.254/16, HOST1's routing policy will send datagrams to HOST2 via 1130 i1, to the ROUTER. Unless there is a route from ROUTER to HOST2, the 1131 datagrams sent from HOST1 to HOST2 will not reach it. 1132 1133 One solution to this problem is for a host to attempt to reach any 1134 host locally (using ARP) for which it receives an unreachable ICMP 1135 error message (ICMP message codes 0, 1, 6 or 7 [RFC792]). The host 1136 tries all its attached links in a round robin fashion. This has been 1137 implemented successfully for some IPv6 hosts, to circumvent exactly 1138 this problem. In terms of this example, HOST1 upon failing to reach 1139 HOST2 via the ROUTER, will attempt to forward to HOST2 via i2 and 1140 succeed. 1141 1142 It may also be possible to overcome this problem using techniques 1143 described in section 3.2, or other means not discussed here. This 1144 specification does not provide a standard solution, nor does it 1145 preclude implementers from supporting multi-homed configurations, 1146 provided that they address the concerns in this section for the 1147 applications which will be supported on the host. 1148 11493.4. Unintentional Autoimmune Response 1150 1151 Care must be taken if a multi-homed host can support more than one 1152 interface on the same link, all of which support IPv4 Link-Local 1153 autoconfiguration. If these interfaces attempt to allocate the same 1154 address, they will defend the host against itself -- causing the 1155 claiming algorithm to fail. The simplest solution to this problem is 1156 to run the algorithm independently on each interface configured with 1157 IPv4 Link-Local addresses. 1158 1159 In particular, ARP packets which appear to claim an address which is 1160 assigned to a specific interface, indicate conflict only if they are 1161 received on that interface and their hardware address is of some 1162 other interface. 1163 1164 If a host has two interfaces on the same link, then claiming and 1165 defending on those interfaces must ensure that they end up with 1166 different addresses just as if they were on different hosts. Note 1167 that some of the ways a host may find itself with two interfaces on 1168 the same link may be unexpected and non-obvious, such as when a host 1169 has Ethernet and 802.11 wireless, but those two links are (possibly 1170 even without the knowledge of the host's user) bridged together. 1171 1172 1173 1174 1175 1176 1177 1178Cheshire, et al. Standards Track [Page 21] 1179 1180RFC 3927 IPv4 Link-Local May 2005 1181 1182 11834. Healing of Network Partitions 1184 1185 Hosts on disjoint network links may configure the same IPv4 Link- 1186 Local address. If these separate network links are later joined or 1187 bridged together, then there may be two hosts which are now on the 1188 same link, trying to use the same address. When either host attempts 1189 to communicate with any other host on the network, it will at some 1190 point broadcast an ARP packet which will enable the hosts in question 1191 to detect that there is an address conflict. 1192 1193 When these address conflicts are detected, the subsequent forced 1194 reconfiguration may be disruptive, causing TCP connections to be 1195 broken. However, it is expected that such disruptions will be rare. 1196 It should be relatively uncommon for networks to be joined while 1197 hosts on those networks are active. Also, 65024 addresses are 1198 available for IPv4 Link-Local use, so even when two small networks 1199 are joined, the chance of conflict for any given host is fairly 1200 small. 1201 1202 When joining two large networks (defined as networks with a 1203 substantial number of hosts per segment) there is a greater chance of 1204 conflict. In such networks, it is likely that the joining of 1205 previously separated segments will result in one or more hosts 1206 needing to change their IPv4 Link-Local address, with subsequent loss 1207 of TCP connections. In cases where separation and re-joining is 1208 frequent, as in remotely bridged networks, this could prove 1209 disruptive. However, unless the number of hosts on the joined 1210 segments is very large, the traffic resulting from the join and 1211 subsequent address conflict resolution will be small. 1212 1213 Sending ARP replies that have IPv4 Link-Local sender addresses via 1214 broadcast instead of unicast ensures that these conflicts can be 1215 detected as soon as they become potential problems, but no sooner. 1216 For example, if two disjoint network links are joined, where hosts A 1217 and B have both configured the same Link-Local address, X, they can 1218 remain in this state until A, B or some other host attempts to 1219 initiate communication. If some other host C now sends an ARP 1220 request for address X, and hosts A and B were to both reply with 1221 conventional unicast ARP replies, then host C might be confused, but 1222 A and B still wouldn't know there is a problem because neither would 1223 have seen the other's packet. Sending these replies via broadcast 1224 allows A and B to see each other's conflicting ARP packets and 1225 respond accordingly. 1226 1227 Note that sending periodic gratuitous ARPs in an attempt to detect 1228 these conflicts sooner is not necessary, wastes network bandwidth, 1229 and may actually be detrimental. For example, if the network links 1230 were joined only briefly, and were separated again before any new 1231 1232 1233 1234Cheshire, et al. Standards Track [Page 22] 1235 1236RFC 3927 IPv4 Link-Local May 2005 1237 1238 1239 communication involving A or B were initiated, then the temporary 1240 conflict would have been benign and no forced reconfiguration would 1241 have been required. Triggering an unnecessary forced reconfiguration 1242 in this case would not serve any useful purpose. Hosts SHOULD NOT 1243 send periodic gratuitous ARPs. 1244 12455. Security Considerations 1246 1247 The use of IPv4 Link-Local Addresses may open a network host to new 1248 attacks. In particular, a host that previously did not have an IP 1249 address, and no IP stack running, was not susceptible to IP-based 1250 attacks. By configuring a working address, the host may now be 1251 vulnerable to IP-based attacks. 1252 1253 The ARP protocol [RFC826] is insecure. A malicious host may send 1254 fraudulent ARP packets on the network, interfering with the correct 1255 operation of other hosts. For example, it is easy for a host to 1256 answer all ARP requests with replies giving its own hardware address, 1257 thereby claiming ownership of every address on the network. 1258 1259 NOTE: There are certain kinds of local links, such as wireless LANs, 1260 that provide no physical security. Because of the existence of these 1261 links it would be very unwise for an implementer to assume that when 1262 a device is communicating only on the local link it can dispense with 1263 normal security precautions. Failure to implement appropriate 1264 security measures could expose users to considerable risks. 1265 1266 A host implementing IPv4 Link-Local configuration has an additional 1267 vulnerability to selective reconfiguration and disruption. It is 1268 possible for an on-link attacker to issue ARP packets which would 1269 cause a host to break all its connections by switching to a new 1270 address. The attacker could force the host implementing IPv4 Link- 1271 Local configuration to select certain addresses, or prevent it from 1272 ever completing address selection. This is a distinct threat from 1273 that posed by spoofed ARPs, described in the preceding paragraph. 1274 1275 Implementations and users should also note that a node that gives up 1276 an address and reconfigures, as required by section 2.5, allows the 1277 possibility that another node can easily and successfully hijack 1278 existing TCP connections. 1279 1280 Implementers are advised that the Internet Protocol architecture 1281 expects every networked device or host must implement security which 1282 is adequate to protect the resources to which the device or host has 1283 access, including the network itself, against known or credible 1284 threats. Even though use of IPv4 Link-Local addresses may reduce the 1285 1286 1287 1288 1289 1290Cheshire, et al. Standards Track [Page 23] 1291 1292RFC 3927 IPv4 Link-Local May 2005 1293 1294 1295 number of threats to which a device is exposed, implementers of 1296 devices supporting the Internet Protocol must not assume that a 1297 customer's local network is free from security risks. 1298 1299 While there may be particular kinds of devices, or particular 1300 environments, for which the security provided by the network is 1301 adequate to protect the resources that are accessible by the device, 1302 it would be misleading to make a general statement to the effect that 1303 the requirement to provide security is reduced for devices using IPv4 1304 Link-Local addresses as a sole means of access. 1305 1306 In all cases, whether or not IPv4 Link-Local addresses are used, it 1307 is necessary for implementers of devices supporting the Internet 1308 Protocol to analyze the known and credible threats to which a 1309 specific host or device might be subjected, and to the extent that it 1310 is feasible, to provide security mechanisms which ameliorate or 1311 reduce the risks associated with such threats. 1312 13136. Application Programming Considerations 1314 1315 Use of IPv4 Link-Local autoconfigured addresses presents additional 1316 challenges to writers of applications and may result in existing 1317 application software failing. 1318 13196.1. Address Changes, Failure and Recovery 1320 1321 IPv4 Link-Local addresses used by an application may change over 1322 time. Some application software encountering an address change will 1323 fail. For example, existing client TCP connections will be aborted, 1324 servers whose addresses change will have to be rediscovered, blocked 1325 reads and writes will exit with an error condition, and so on. 1326 1327 Vendors producing application software which will be used on IP 1328 implementations supporting IPv4 Link-Local address configuration 1329 SHOULD detect and cope with address change events. Vendors producing 1330 IPv4 implementations supporting IPv4 Link-Local address configuration 1331 SHOULD expose address change events to applications. 1332 13336.2. Limited Forwarding of Locators 1334 1335 IPv4 Link-Local addresses MUST NOT be forwarded via an application 1336 protocol (for example in a URL), to a destination that is not on the 1337 same link. This is discussed further in Sections 2.9 and 3. 1338 1339 Existing distributed application software that forwards address 1340 information may fail. For example, FTP [RFC959] (when not using 1341 passive mode) transmits the IP address of the client. Suppose a 1342 client starts up and obtains its IPv4 configuration at a time when it 1343 1344 1345 1346Cheshire, et al. Standards Track [Page 24] 1347 1348RFC 3927 IPv4 Link-Local May 2005 1349 1350 1351 has only a Link-Local address. Later, the host gets a global IP 1352 address, and the client contacts an FTP server outside the local 1353 link. If the FTP client transmits its old Link-Local address instead 1354 of its new global IP address in the FTP "port" command, then the FTP 1355 server will be unable to open a data connection back to the client, 1356 and the FTP operation will fail. 1357 13586.3. Address Ambiguity 1359 1360 Application software run on a multi-homed host that supports IPv4 1361 Link-Local address configuration on more than one interface may fail. 1362 1363 This is because application software assumes that an IPv4 address is 1364 unambiguous, that it can refer to only one host. IPv4 Link-Local 1365 addresses are unique only on a single link. A host attached to 1366 multiple links can easily encounter a situation where the same 1367 address is present on more than one interface, or first on one 1368 interface, later on another; in any case associated with more than 1369 one host. Most existing software is not prepared for this ambiguity. 1370 In the future, application programming interfaces could be developed 1371 to prevent this problem. This issue is discussed in Section 3. 1372 13737. Router Considerations 1374 1375 A router MUST NOT forward a packet with an IPv4 Link-Local source or 1376 destination address, irrespective of the router's default route 1377 configuration or routes obtained from dynamic routing protocols. 1378 1379 A router which receives a packet with an IPv4 Link-Local source or 1380 destination address MUST NOT forward the packet. This prevents 1381 forwarding of packets back onto the network segment from which they 1382 originated, or to any other segment. 1383 13848. IANA Considerations 1385 1386 The IANA has allocated the prefix 169.254/16 for the use described in 1387 this document. The first and last 256 addresses in this range 1388 (169.254.0.x and 169.254.255.x) are allocated by Standards Action, as 1389 defined in "Guidelines for Writing an IANA" (BCP 26) [RFC2434]. No 1390 other IANA services are required by this document. 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402Cheshire, et al. Standards Track [Page 25] 1403 1404RFC 3927 IPv4 Link-Local May 2005 1405 1406 14079. Constants 1408 1409 The following timing constants are used in this protocol; they are 1410 not intended to be user configurable. 1411 1412 PROBE_WAIT 1 second (initial random delay) 1413 PROBE_NUM 3 (number of probe packets) 1414 PROBE_MIN 1 second (minimum delay till repeated probe) 1415 PROBE_MAX 2 seconds (maximum delay till repeated probe) 1416 ANNOUNCE_WAIT 2 seconds (delay before announcing) 1417 ANNOUNCE_NUM 2 (number of announcement packets) 1418 ANNOUNCE_INTERVAL 2 seconds (time between announcement packets) 1419 MAX_CONFLICTS 10 (max conflicts before rate limiting) 1420 RATE_LIMIT_INTERVAL 60 seconds (delay between successive attempts) 1421 DEFEND_INTERVAL 10 seconds (minimum interval between defensive 1422 ARPs). 1423 142410. References 1425 142610.1. Normative References 1427 1428 [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 1429 792, September 1981. 1430 1431 [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1432 converting network protocol addresses to 48.bit Ethernet 1433 address for transmission on Ethernet hardware", STD 37, RFC 1434 826, November 1982. 1435 1436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1437 Requirement Levels", BCP 14, RFC 2119, March 1997. 1438 1439 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1440 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1441 October 1998. 1442 144310.2. Informative References 1444 1445 [802] IEEE Standards for Local and Metropolitan Area Networks: 1446 Overview and Architecture, ANSI/IEEE Std 802, 1990. 1447 1448 [802.3] ISO/IEC 8802-3 Information technology - Telecommunications 1449 and information exchange between systems - Local and 1450 metropolitan area networks - Common specifications - Part 1451 3: Carrier Sense Multiple Access with Collision Detection 1452 (CSMA/CD) Access Method and Physical Layer Specifications, 1453 (also ANSI/IEEE Std 802.3- 1996), 1996. 1454 1455 1456 1457 1458Cheshire, et al. Standards Track [Page 26] 1459 1460RFC 3927 IPv4 Link-Local May 2005 1461 1462 1463 [802.5] ISO/IEC 8802-5 Information technology - Telecommunications 1464 and information exchange between systems - Local and 1465 metropolitan area networks - Common specifications - Part 1466 5: Token ring access method and physical layer 1467 specifications, (also ANSI/IEEE Std 802.5-1998), 1998. 1468 1469 [802.11] Information technology - Telecommunications and information 1470 exchange between systems - Local and metropolitan area 1471 networks - Specific Requirements Part 11: Wireless LAN 1472 Medium Access Control (MAC) and Physical Layer (PHY) 1473 Specifications, IEEE Std. 802.11-1999, 1999. 1474 1475 [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 1476 9, RFC 959, October 1985. 1477 1478 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1479 and E. Lear, "Address Allocation for Private Internets", 1480 BCP 5, RFC 1918, February 1996. 1481 1482 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 1483 March 1997. 1484 1485 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1486 Autoconfiguration", RFC 2462, December 1998. 1487 1488 [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with 1489 the IP Network Address Translator", RFC 3027, January 2001. 1490 1491 [DNAv4] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", 1492 Work in Progress, July 2004. 1493 1494 [LLMNR] Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast 1495 Name Resolution (LLMNR)", Work in Progress, June 2004. 1496 1497Acknowledgments 1498 1499 We would like to thank (in alphabetical order) Jim Busse, Pavani 1500 Diwanji, Donald Eastlake 3rd, Robert Elz, Peter Ford, Spencer 1501 Giacalone, Josh Graessley, Brad Hards, Myron Hattig, Hugh Holbrook, 1502 Christian Huitema, Richard Johnson, Kim Yong-Woon, Mika Liljeberg, 1503 Rod Lopez, Keith Moore, Satish Mundra, Thomas Narten, Erik Nordmark, 1504 Philip Nye, Howard Ridenour, Daniel Senie, Dieter Siegmund, Valery 1505 Smyslov, and Ryan Troll for their contributions. 1506 1507 1508 1509 1510 1511 1512 1513 1514Cheshire, et al. Standards Track [Page 27] 1515 1516RFC 3927 IPv4 Link-Local May 2005 1517 1518 1519Appendix A - Prior Implementations 1520 1521A.1. Apple Mac OS 8.x and 9.x. 1522 1523 Mac OS chooses the IP address on a pseudo-random basis. The selected 1524 address is saved in persistent storage for continued use after 1525 reboot, when possible. 1526 1527 Mac OS sends nine DHCPDISCOVER packets, with an interval of two 1528 seconds between packets. If no response is received from any of 1529 these requests (18 seconds), it will autoconfigure. 1530 1531 Upon finding that a selected address is in use, Mac OS will select a 1532 new random address and try again, at a rate limited to no more than 1533 one attempt every two seconds. 1534 1535 Autoconfigured Mac OS systems check for the presence of a DHCP server 1536 every five minutes. If a DHCP server is found but Mac OS is not 1537 successful in obtaining a new lease, it keeps the existing 1538 autoconfigured IP address. If Mac OS is successful at obtaining a 1539 new lease, it drops all existing connections without warning. This 1540 may cause users to lose sessions in progress. Once a new lease is 1541 obtained, Mac OS will not allocate further connections using the 1542 autoconfigured IP address. 1543 1544 Mac OS systems do not send packets addressed to a Link-Local address 1545 to the default gateway if one is present; these addresses are always 1546 resolved on the local segment. 1547 1548 Mac OS systems by default send all outgoing unicast packets with a 1549 TTL of 255. All multicast and broadcast packets are also sent with a 1550 TTL of 255 if they have a source address in the 169.254/16 prefix. 1551 1552 Mac OS implements media sense where the hardware (and driver 1553 software) supports this. As soon as network connectivity is 1554 detected, a DHCPDISCOVER will be sent on the interface. This means 1555 that systems will immediately transition out of autoconfigured mode 1556 as soon as connectivity is restored. 1557 1558A.2. Apple Mac OS X Version 10.2 1559 1560 Mac OS X chooses the IP address on a pseudo-random basis. The 1561 selected address is saved in memory so that it can be re-used during 1562 subsequent autoconfiguration attempts during a single boot of the 1563 system. 1564 1565 1566 1567 1568 1569 1570Cheshire, et al. Standards Track [Page 28] 1571 1572RFC 3927 IPv4 Link-Local May 2005 1573 1574 1575 Autoconfiguration of a Link-Local address depends on the results of 1576 the DHCP process. DHCP sends two packets, with timeouts of one and 1577 two seconds. If no response is received (three seconds), it begins 1578 autoconfiguration. DHCP continues sending packets in parallel for a 1579 total time of 60 seconds. 1580 1581 At the start of autoconfiguration, it generates 10 unique random IP 1582 addresses, and probes each one in turn for 2 seconds. It stops 1583 probing after finding an address that is not in use, or the list of 1584 addresses is exhausted. 1585 1586 If DHCP is not successful, it waits five minutes before starting over 1587 again. Once DHCP is successful, the autoconfigured Link-Local 1588 address is given up. The Link-Local subnet, however, remains 1589 configured. 1590 1591 Autoconfiguration is only attempted on a single interface at any 1592 given moment in time. 1593 1594 Mac OS X ensures that the connected interface with the highest 1595 priority is associated with the Link-Local subnet. Packets addressed 1596 to a Link-Local address are never sent to the default gateway, if one 1597 is present. Link-local addresses are always resolved on the local 1598 segment. 1599 1600 Mac OS X implements media sense where the hardware and driver support 1601 it. When the network media indicates that it has been connected, the 1602 autoconfiguration process begins again, and attempts to re-use the 1603 previously assigned Link-Local address. When the network media 1604 indicates that it has been disconnected, the system waits four 1605 seconds before de-configuring the Link-Local address and subnet. If 1606 the connection is restored before that time, the autoconfiguration 1607 process begins again. If the connection is not restored before that 1608 time, the system chooses another interface to autoconfigure. 1609 1610 Mac OS X by default sends all outgoing unicast packets with a TTL of 1611 255. All multicast and broadcast packets are also sent with a TTL of 1612 255 if they have a source address in the 169.254/16 prefix. 1613 1614A.3. Microsoft Windows 98/98SE 1615 1616 Windows 98/98SE systems choose their IPv4 Link-Local address on a 1617 pseudo-random basis. The address selection algorithm is based on 1618 computing a hash on the interface's MAC address, so that a large 1619 collection of hosts should obey the uniform probability distribution 1620 in choosing addresses within the 169.254/16 address space. Deriving 1621 1622 1623 1624 1625 1626Cheshire, et al. Standards Track [Page 29] 1627 1628RFC 3927 IPv4 Link-Local May 2005 1629 1630 1631 the initial IPv4 Link-Local address from the interface's MAC address 1632 also ensures that systems rebooting will obtain the same 1633 autoconfigured address, unless a conflict is detected. 1634 1635 When in INIT state, the Windows 98/98SE DHCP Client sends out a total 1636 of 4 DHCPDISCOVERs, with an inter-packet interval of 6 seconds. When 1637 no response is received after all 4 packets (24 seconds), it will 1638 autoconfigure an address. 1639 1640 The autoconfigure retry count for Windows 98/98SE systems is 10. 1641 After trying 10 autoconfigured IPv4 addresses, and finding all are 1642 taken, the host will boot without an IPv4 address. 1643 1644 Autoconfigured Windows 98/98SE systems check for the presence of a 1645 DHCP server every five minutes. If a DHCP server is found but 1646 Windows 98 is not successful in obtaining a new lease, it keeps the 1647 existing autoconfigured IPv4 Link-Local address. If Windows 98/98SE 1648 is successful at obtaining a new lease, it drops all existing 1649 connections without warning. This may cause users to lose sessions 1650 in progress. Once a new lease is obtained, Windows 98/98SE will not 1651 allocate further connections using the autoconfigured IPv4 Link-Local 1652 address. 1653 1654 Windows 98/98SE systems with an IPv4 Link-Local address do not send 1655 packets addressed to an IPv4 Link-Local address to the default 1656 gateway if one is present; these addresses are always resolved on the 1657 local segment. 1658 1659 Windows 98/98SE systems by default send all outgoing unicast packets 1660 with a TTL of 128. TTL configuration is performed by setting the 1661 Windows Registry Key 1662 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services:\Tcpip\ 1663 Parameters\DefaultTTL of type REG_DWORD to the appropriate value. 1664 However, this default TTL will apply to all packets. While this 1665 facility could be used to set the default TTL to 255, it cannot be 1666 used to set the default TTL of IPv4 Link-Local packets to one (1), 1667 while allowing other packets to be sent with a TTL larger than one. 1668 1669 Windows 98/98SE systems do not implement media sense. This means 1670 that network connectivity issues (such as a loose cable) may prevent 1671 a system from contacting the DHCP server, thereby causing it to 1672 auto-configure. When the connectivity problem is fixed (such as when 1673 the cable is re-connected) the situation will not immediately correct 1674 itself. Since the system will not sense the re-connection, it will 1675 remain in autoconfigured mode until an attempt is made to reach the 1676 DHCP server. 1677 1678 1679 1680 1681 1682Cheshire, et al. Standards Track [Page 30] 1683 1684RFC 3927 IPv4 Link-Local May 2005 1685 1686 1687 The DHCP server included with Windows 98SE Internet Connection 1688 Sharing (ICS) (a NAT implementation) allocates out of the 192.168/16 1689 private address space by default. 1690 1691 However, it is possible to change the allocation prefix via a 1692 registry key, and no checks are made to prevent allocation out of the 1693 IPv4 Link-Local prefix. When configured to do so, Windows 98SE ICS 1694 will rewrite packets from the IPv4 Link-Local prefix and forward them 1695 beyond the local link. Windows 98SE ICS does not automatically route 1696 for the IPv4 Link-Local prefix, so that hosts obtaining addresses via 1697 DHCP cannot communicate with autoconfigured-only devices. 1698 1699 Other home gateways exist that allocate addresses out of the IPv4 1700 Link-Local prefix by default. Windows 98/98SE systems can use a 1701 169.254/16 IPv4 Link-Local address as the source address when 1702 communicating with non-Link-Local hosts. Windows 98/98SE does not 1703 support router solicitation/advertisement. Windows 98/98SE systems 1704 will not automatically discover a default gateway when in 1705 autoconfigured mode. 1706 1707A.4. Windows XP, 2000, and ME 1708 1709 The autoconfiguration behavior of Windows XP, Windows 2000, and 1710 Windows ME systems is identical to Windows 98/98SE except in the 1711 following respects: 1712 1713 Media Sense 1714 Router Discovery 1715 Silent RIP 1716 1717 Windows XP, 2000, and ME implement media sense. As soon as network 1718 connectivity is detected, a DHCPREQUEST or DHCPDISCOVER will be sent 1719 on the interface. This means that systems will immediately 1720 transition out of autoconfigured mode as soon as connectivity is 1721 restored. 1722 1723 Windows XP, 2000, and ME also support router discovery, although it 1724 is turned off by default. Windows XP and 2000 also support a RIP 1725 listener. This means that they may inadvertently discover a default 1726 gateway while in autoconfigured mode. 1727 1728 ICS on Windows XP/2000/ME behaves identically to Windows 98SE with 1729 respect to address allocation and NATing of Link-Local prefixes. 1730 1731 1732 1733 1734 1735 1736 1737 1738Cheshire, et al. Standards Track [Page 31] 1739 1740RFC 3927 IPv4 Link-Local May 2005 1741 1742 1743Authors' Addresses 1744 1745 Stuart Cheshire 1746 Apple Computer, Inc. 1747 1 Infinite Loop 1748 Cupertino 1749 California 95014, USA 1750 1751 Phone: +1 408 974 3207 1752 EMail: rfc@stuartcheshire.org 1753 1754 1755 Bernard Aboba 1756 Microsoft Corporation 1757 One Microsoft Way 1758 Redmond, WA 98052 1759 1760 Phone: +1 425 818 4011 1761 EMail: bernarda@microsoft.com 1762 1763 1764 Erik Guttman 1765 Sun Microsystems 1766 Eichhoelzelstr. 7 1767 74915 Waibstadt Germany 1768 1769 Phone: +49 7263 911 701 1770 EMail: erik@spybeam.org 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794Cheshire, et al. Standards Track [Page 32] 1795 1796RFC 3927 IPv4 Link-Local May 2005 1797 1798 1799Full Copyright Statement 1800 1801 Copyright (C) The Internet Society (2005). 1802 1803 This document is subject to the rights, licenses and restrictions 1804 contained in BCP 78, and except as set forth therein, the authors 1805 retain all their rights. 1806 1807 This document and the information contained herein are provided on an 1808 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1809 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1810 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1811 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1812 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1813 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1814 1815Intellectual Property 1816 1817 The IETF takes no position regarding the validity or scope of any 1818 Intellectual Property Rights or other rights that might be claimed to 1819 pertain to the implementation or use of the technology described in 1820 this document or the extent to which any license under such rights 1821 might or might not be available; nor does it represent that it has 1822 made any independent effort to identify any such rights. Information 1823 on the procedures with respect to rights in RFC documents can be 1824 found in BCP 78 and BCP 79. 1825 1826 Copies of IPR disclosures made to the IETF Secretariat and any 1827 assurances of licenses to be made available, or the result of an 1828 attempt made to obtain a general license or permission for the use of 1829 such proprietary rights by implementers or users of this 1830 specification can be obtained from the IETF on-line IPR repository at 1831 http://www.ietf.org/ipr. 1832 1833 The IETF invites any interested party to bring to its attention any 1834 copyrights, patents or patent applications, or other proprietary 1835 rights that may cover technology that may be required to implement 1836 this standard. Please address the information to the IETF at ietf- 1837 ipr@ietf.org. 1838 1839Acknowledgement 1840 1841 Funding for the RFC Editor function is currently provided by the 1842 Internet Society. 1843 1844 1845 1846 1847 1848 1849 1850Cheshire, et al. Standards Track [Page 33] 1851 1852