idnits 2.17.1 draft-cheshire-ipv4-acd-03.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. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (December 2002) is 7774 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) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 0 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Document: draft-cheshire-ipv4-acd-03.txt Stuart Cheshire 2 Category: Standards Track Apple Computer 3 Expires 9th June 2003 9th December 2002 5 IPv4 Address Conflict Detection 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are 12 working documents of the Internet Engineering Task Force (IETF), 13 its areas, and its working groups. Note that other groups may 14 also distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet-Drafts as 19 reference material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html 27 Distribution of this memo is unlimited. 29 Abstract 31 When two hosts on the same link attempt to use the same IPv4 address 32 at the same time (except in rare special cases where this has been 33 arranged by prior coordination) problems ensue for one or both hosts. 34 This document describes (i) a simple precaution that a host can take 35 in advance to help prevent this misconfiguration from happening, and 36 (ii) if this misconfiguration does occur, a simple mechanism by which 37 a host can passively detect after-the-fact that it has happened, so 38 that the host may respond to rectify the problem. 40 Table of Contents 42 1. Introduction....................................................2 43 1.1 Conventions and Terminology Used in this Document...............4 44 1.2 Relationship to RFC 826.........................................4 45 1.3 Applicability...................................................6 46 2. Address Probing, Announcing, Conflict Detection and Defense.....6 47 2.1 Probing an Address..............................................6 48 2.2 Shorter Timeouts on Appropriate Network Technologies............7 49 2.3 Announcing an Address...........................................8 50 2.4 Ongoing Address Conflict Detection and Address Defense..........8 51 2.5 Broadcast ARP Replies...........................................9 52 3. Security Considerations........................................10 53 4. Historical Note................................................11 54 5. IANA Considerations............................................11 55 6. Acknowledgements...............................................11 56 7. Copyright......................................................11 57 8. Normative References...........................................12 58 9. Informative References.........................................12 59 10. Author's Address...............................................12 61 1. Introduction 63 Historically, accidentally configuring two Internet hosts with the 64 same IP address has often been an annoying and hard-to-diagnose 65 problem. 67 This is unfortunate, because the existing ARP protocol provides 68 an easy way for a host to detect this kind of misconfiguration and 69 report it to the user. The DHCP specification [RFC 2131] briefly 70 mentions the role of ARP in detecting misconfiguration, as 71 illustrated in the following three excerpts from RFC 2131: 73 o the client SHOULD probe the newly received address, 74 e.g., with ARP. 76 o The client SHOULD perform a final check on the parameters 77 (e.g., ARP for allocated network address) 79 o If the client detects that the address is already in use 80 (e.g., through the use of ARP), the client MUST send 81 a DHCPDECLINE message to the server 83 Unfortunately, the DHCP specification does not give any guidance to 84 implementers concerning the number of ARP packets to send, the 85 interval between packets, the total time to wait before concluding 86 that an address may safely be used, or indeed even which kinds of 87 packets a host should be listening for, in order to make this 88 determination. It leaves unspecified the action a host should take 89 if, after concluding that an address may safely be used, it 90 subsequently discovers that it was wrong. It also fails to specify 91 what precautions a DHCP client should take to guard against 92 pathological failure cases, such as DHCP server that repeatedly 93 OFFERs the same address, even though it has been DECLINEd multiple 94 times. 96 The authors of the DHCP specification may have thought the answers to 97 these questions too obvious to mention, but unfortunately this leaves 98 some of the burden of protocol design to each individual implementer. 99 This document seeks to remedy this omission by clearly specifying the 100 required actions for: 102 1. Determining whether use of an address is likely to lead to an 103 addressing conflict. This includes (a) the case where the address 104 is already actively in use by another host on the same link, and 105 (b) the case where two hosts are inadvertently about to begin 106 using the same address, and both are simultaneously in the process 107 of probing to determine whether the address may safely be used. 109 2. Subsequent passive detection that another host on the network is 110 inadvertently using the same address. Even if all hosts observe 111 precautions to avoid using an address that is already in use, 112 conflicts can still occur if two hosts are out of communication at 113 the time of initial interface configuration. This could occur with 114 wireless network interfaces if the hosts are temporarily out of 115 range, or with Ethernet interfaces if the link between two 116 Ethernet hubs is not functioning at the time of address 117 configuration. A well-designed host will handle not only conflicts 118 detected during interface configuration, but also conflicts 119 detected later, for the entire duration of the time that the host 120 is using the address. 122 3. Rate-limiting of address acquisition attempts in the case of an 123 excessive number of repeated conflicts. 125 The utility of IPv4 Address Conflict Detection is not limited to DHCP 126 clients. No matter how an address was configured, whether via manual 127 entry by a human user, via information received from a DHCP server, 128 or via any other source of configuration information, detecting 129 conflicts is useful. Upon detecting a conflict, the configuring agent 130 should be notified of the error. In the case where the configuring 131 agent is a human user, that notification may take the form of an 132 error message on a screen, an SNMP trap, or an error message sent via 133 pager. In the case of a DHCP server, that notification takes the form 134 of a DHCP DECLINE message sent to the server. In the case of 135 configuration by some other kind of software, that notification takes 136 the form of an error indication to the software in question, to 137 inform it that the address it selected is in conflict with some other 138 host on the network. The configuring software may choose to cease 139 network operation, or it may automatically select a new address so 140 that the host may re-establish IP connectivity as soon as possible. 142 1.1. Conventions and Terminology Used in this Document 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in "Key words for use in 147 RFCs to Indicate Requirement Levels" [RFC 2119]. 149 Wherever this document uses the term "sender IP address" or "target 150 IP address" in the context of an ARP packet, it is referring to the 151 fields of the ARP packet identified in the ARP specification [RFC 152 826] as "ar$spa" (Sender Protocol Address) and "ar$tpa" (Target 153 Protocol Address) respectively. For the usage of ARP described in 154 this document, each of these fields always contains an IP address. 156 In this document, the term "ARP Probe" is used to refer to an ARP 157 request packet, broadcast on the local link, with an all-zero 'sender 158 IP address'. The 'sender hardware address' MUST contain the hardware 159 address of the interface sending the packet. The 'sender IP address' 160 field MUST be set to all zeroes, to avoid polluting ARP caches in 161 other hosts on the same link in the case where the address turns out 162 to be already in use by another host. The 'target hardware address' 163 field is ignored and SHOULD be set to all zeroes. The 'target IP 164 address' field MUST be set to the address being probed. 166 In this document, the term "ARP Announcement" is used to refer to 167 an ARP request packet, broadcast on the local link, identical to 168 the ARP probe described above, except that both the sender and 169 target IP address fields contain the IP address being announced. 171 1.2 Relationship to RFC 826 173 This document does not modify any of the protocol rules in RFC 826. 174 It does not modify the packet format, or the meaning of any 175 of the fields. The existing rules for "Packet Generation" and 176 "Packet Reception" still apply exactly as specified in RFC 826. 178 This document expands on RFC 826 by specifying some additional ARP 179 packets that should be generated when an interface is configured, and 180 an additional check that should be performed on each ARP packet that 181 is received. This additional check does not impose a significant 182 additional CPU burden on hosts, since every host implementing ARP 183 is already required to process every received ARP packet according 184 to the "Packet Reception" rules specified in RFC 826. 186 As specified in RFC 826, an ARP Request packet serves two functions, 187 an assertion and a question: 189 * Assertion: 190 The fields "ar$sha" (Sender Hardware Address) and "ar$spa" (Sender 191 Protocol Address) together serve as an assertion of a fact, that 192 the stated Protocol Address is mapped to the stated Hardware 193 Address. 195 * Question: 196 The fields "ar$tha" (Target Hardware Address, zero) and "ar$tpa" 197 (Target Protocol Address) serve as a question, asking, for the 198 stated Protocol Address, to which Hardware Address it is mapped. 200 This document clarifies what it means to have one without the other. 202 1.2.1 ARP Probe 204 This document standardizes the widely-used natural interpretation of 205 an ARP Request where the Target Protocol Address is non-zero but the 206 Sender Protocol Address is zero, namely that it is a question without 207 an associated assertion (an "ARP Probe"). 209 1.2.2 ARP Announcement 211 This document standardizes the widely-used natural interpretation of 212 an ARP Request where the Sender and Target Protocol Address fields 213 contain the same address, namely that it is an assertion without an 214 associated question (an "ARP Announcement"). 216 1.2.3 Broadcast Replies 218 In some applications of IPv4 Address Conflict Detection, it may be 219 advantageous to deliver ARP replies using broadcast instead of 220 unicast because this allows address conflicts to be detected sooner 221 than might otherwise happen. This is not needed in most situations, 222 but certain specialized uses of Address Conflict Detection such as 223 "Dynamic Configuration of IPv4 Link-Local Addresses" [v4LL] can 224 benefit from this optional capability. 226 RFC 826 implies that replies to ARP requests are usually delivered 227 using unicast, but it is also acceptable to deliver ARP replies using 228 broadcast. The "Packet Reception" rules in RFC 826 specify that the 229 content of the "ar$spa" field should be processed *before* examining 230 the "ar$op" field, so any host that correctly implements the Packet 231 Reception algorithm specified in RFC 826 will correctly handle ARP 232 replies delivered via link-layer broadcast. 234 1.3. Applicability 236 The specifications in this document apply to any link-layer network 237 technology that uses ARP [RFC 826] to map from IP addresses to 238 link-layer hardware addresses. 240 For the specifications in this document to be effective at detecting 241 address conflicts, the other hosts on the link must correctly 242 implement the ARP protocol as given in RFC 826. In particular, when 243 a host receives an ARP Request where the Target Protocol Address of 244 the ARP Request matches (one of) the host's IP address(es), then the 245 host MUST reply with a properly formatted ARP reply. 247 If a particular host fails to implement the ARP specification 248 correctly, then that host is liable to be at greater risk of 249 undetected address conflicts. 251 2. Address Probing, Announcing, Conflict Detection and Defense 253 This section describes initial probing to safely determine whether 254 an address is already in use, ongoing conflict checking, and optional 255 use of broadcast ARP replies to provide faster conflict detection. 257 2.1 Probing an Address 259 Before beginning to use an IP address (whether received from manual 260 configuration, DHCP, or some other means), a host implementing this 261 specification MUST test to see if the address is already in use, 262 by broadcasting ARP Probe packets, as defined in Section 1.1. 264 When ready to begin probing, the host should first wait for a random 265 time interval selected uniformly in the range zero to two seconds, 266 and should then send four probe packets, spaced two seconds apart. 267 This initial random delay helps ensure that a large number of hosts 268 powered on at the same time do not all send their initial probe 269 packets simultaneously. 271 If during this period, from the beginning of the probing process 272 until two seconds after the last probe packet is sent, the host 273 receives any ARP packet (request *or* reply) where the packet's 274 'sender IP address' is the address being probed for, then the host 275 MUST treat this address as being in use by some other host, and 276 should indicate to the configuring agent (human operator, DHCP 277 server, etc.) that the proposed address is not acceptable. In 278 addition, if during this period the host receives any ARP probe where 279 the packet's 'target IP address' is the address being probed for, and 280 the packet's 'sender hardware address' is not the hardware address of 281 any of the host's interfaces, then the host MUST similarly treat this 282 as an address conflict and signal an error to the configuring agent 283 as above. This can occur if two (or more) hosts have, for whatever 284 reason, been inadvertently configured with the same address, and both 285 are simultaneously in the process of probing that address to see if 286 it can safely be used. 288 A host implementing this specification MUST maintain a counter of the 289 number of conflicts it has experienced in the process of trying to 290 configure an interface, and if the number of conflicts exceeds ten 291 then the host MUST limit the rate at which it probes for new 292 addresses to no more than one new address per minute. This is to 293 prevent catastrophic ARP storms in pathological failure cases, such 294 as a defective DHCP server that repeatedly assigns the same address 295 to every host that asks for one. 297 If, by two seconds after the transmission of the last ARP probe 298 no conflicting ARP reply has been received, then the host has 299 successfully determined that the desired address may be used safely. 301 2.2 Shorter Timeouts on Appropriate Network Technologies 303 The time values specified above are intended for use on technologies 304 such as Ethernet, where switches that implement Spanning Tree 305 [802.1d] often silently discard all packets for several seconds. The 306 time values specified above result in a delay of 8-10 seconds before 307 a chosen IP address may be used. For a desktop machine using DHCP, 308 this may not be a great problem, but for other types of device, 309 particularly hand-held portable devices, a ten-second delay before 310 networking services becomes available may not be acceptable. For this 311 reason, shorter time values may be used on network technologies that 312 allow the device to determine when the link has become active and can 313 be reasonably trusted to deliver packets reliably. On these network 314 technologies the recommended time values are: The host should first 315 wait for a random time interval selected uniformly in the range 0-200 316 milliseconds, and then send four probe packets, waiting 200 317 milliseconds after each probe, making a total delay of 800-1000ms 318 before a chosen IP address may be used. 320 Should future versions of the IEEE Spanning Tree Protocol be enhanced 321 to inform clients when the link is ready to begin forwarding packets, 322 then the shorter time values may be used on these networks too. 324 If the situation arises where some hosts on a network are using the 325 optional shorter timeouts and others are not, this does not cause any 326 problems. It simply means that some hosts will be able to configure 327 their interfaces quicker than others. In the unlikely event that an 328 address conflict is not detected during the short address probing 329 phase, the conflict will still be detected by the Ongoing Address 330 Conflict Detection described below in Section 2.4. 332 2.3 Announcing an Address 334 Having determined that a desired address may be used safely, a host 335 implementing this specification MUST then announce that it is 336 commencing to use this address by broadcasting two ARP announcements, 337 spaced two seconds apart. This time interval is not modified by the 338 shorter timeouts described above in Section 2.2. An ARP announcement 339 is identical to the ARP probe described above, except that now the 340 sender and target IP addresses are both set to the host's newly 341 selected IP address. The purpose of these ARP announcements is to 342 make sure that other hosts on the link do not have stale ARP cache 343 entries left over from some other host that may previously have been 344 using the same address. The host may begin legitimately using the IP 345 address immediately after sending the first of the two ARP 346 announcements, and the sending of the second ARP announcement may be 347 completed asynchronously, concurrent with other networking operations 348 the host may wish to perform. 350 2.4 Ongoing Address Conflict Detection and Address Defense 352 Address conflict detection should not be limited to only the time of 353 initial interface configuration, when a host is sending ARP probes. 354 Address conflict detection is an ongoing process that is in effect 355 for as long as a host is using an address. At any time, if a host 356 receives an ARP packet (request *or* reply) where the 'sender IP 357 address' is (one of) the host's own IP address(es), but the 'sender 358 hardware address' does not match any of the host's own interface 359 addresses, then this is a conflicting ARP packet, indicating some 360 other host also thinks it is validly using this address. To resolve 361 the address conflict, a host must respond to a conflicting ARP packet 362 as described in either (a), (b) or (c) below: 364 (a) Upon receiving a conflicting ARP packet, a host MAY elect to 365 immediately cease using the address, and signal an error to the 366 configuring agent as described above, or 368 (b) If a host currently has active TCP connections or other reasons 369 to prefer to keep the same IP address, and it has not seen any other 370 conflicting ARP packets recently (for Ethernet, within the last ten 371 seconds) then it MAY elect to attempt to defend its address. 372 To defend its address, the host first records the time that the 373 conflicting ARP packet was received, and then broadcasts one single 374 ARP announcement, giving its own IP and hardware addresses. Having 375 done this, the host can then continue to use the address normally 376 without any further special action. However, if this is not the first 377 conflicting ARP packet the host has seen, and the time recorded for 378 the previous conflicting ARP packet is recent (within ten seconds for 379 Ethernet) then the host MUST immediately cease using this address and 380 signal an error to the configuring agent as described above. This is 381 necessary to ensure that two hosts do not get stuck in an endless 382 loop with both hosts trying to defend the same address. 384 (c) If a host has been configured such that it should not give up 385 its address under any circumstances (perhaps because it is the kind 386 of device that needs to have a well-known stable IP address, such 387 as a link's default router, or a DNS server) then it MAY elect 388 to defend its address indefinitely. If such a host receives a 389 conflicting ARP packet, then it should take appropriate steps to 390 log useful information such as source Ethernet address from the ARP 391 packet, and inform an administrator of the problem. The number of 392 such notifications should be appropriately controlled to prevent an 393 excessive number of error reports being generated. If the host has 394 not seen any other conflicting ARP packets recently (for Ethernet, 395 within the last ten seconds) then it MUST record the time that the 396 conflicting ARP packet was received, and then broadcast one single 397 ARP announcement, giving its own IP and hardware addresses. Having 398 done this, the host can then continue to use the address normally 399 without any further special action. However, if this is not the first 400 conflicting ARP packet the host has seen, and the time recorded for 401 the previous conflicting ARP packet is recent (within ten seconds for 402 Ethernet) then the host MUST NOT send another defensive ARP 403 announcement. This is necessary to ensure that two misconfigured 404 hosts do not get stuck in an endless loop flooding the network with 405 broadcast traffic while they both try to defend the same address. 407 A host wishing to provide reliable network operation must respond to 408 conflicting ARP packets as described in (a), (b) or (c) above. 409 Ignoring conflicting ARP packets results in seemingly random network 410 failures which can be hard to diagnose and very frustrating for human 411 users. 413 Forced address reconfiguration may be disruptive, causing TCP 414 connections to be broken. However, it is such disruptions should be 415 exceedingly rare, and if inadvertent address duplication happens, 416 then disruption of communication is inevitable. It is not possible 417 for two different hosts using the same IP address on the same network 418 to operate reliably. For most client machines that do not need a 419 fixed IP address, immediately requesting the configuring agent (human 420 user, DHCP client, etc.) to configure a new address as soon as the 421 conflict is detected is the best way to restore useful communication 422 as quickly as possible. The mechanism described above of broadcasting 423 a single ARP announcement to defend the address mitigates the problem 424 somewhat, by helping to improve the chance that one of the two 425 conflicting hosts may be able to retain its address. 427 2.5 Broadcast ARP Replies 429 In a carefully-run network with manually-assigned addresses, or 430 a network with a reliable DHCP server and reliable DHCP clients, 431 address conflicts should occur only in rare failure scenarios, 432 so the passive monitoring described above in Section 2.4 is adequate. 433 If two hosts are using the same IP address, then sooner or later one 434 or other host will broadcast an ARP request, which the other will 435 see, allowing the conflict to be detected and consequently resolved. 437 It is possible however, that a conflicting configuration may persist 438 for a short time before it is detected. Suppose that two hosts A and 439 B have been inadvertently assigned the same IP address X. Suppose 440 further that at the time they were both probing to determine whether 441 the address could safely be used, the communication link between them 442 was non-functional for some reason, so neither detected the conflict 443 at interface-configuration time. Suppose now that the communication 444 link is restored, and a third host C broadcasts an ARP request for 445 address X. Unaware of any conflict, both hosts A and B will send 446 unicast ARP replies to host C. Host C will see both replies, and may 447 be a little confused, but neither host A nor B will see the other's 448 reply, and neither will immediately detect that there is a conflict 449 to be resolved. Hosts A and B will continue to be unaware of the 450 conflict until one or other broadcasts an ARP request of their own. 452 If quicker conflict detection is desired, this MAY be achieved by 453 having hosts send ARP replies using link-level broadcast, instead 454 of sending only ARP requests via broadcast, and replies via unicast. 455 This is not recommended for general use, but "Dynamic Configuration 456 of IPv4 Link-Local Addresses" [v4LL] makes use of this optional 457 capability, since in that case, detection of address conflicts using 458 ARP is not merely a backup precaution to detect failures of some 459 other configuration mechanism; detection of address conflicts using 460 ARP is the sole configuration mechanism. 462 Sending both requests and replies via broadcast potentially doubles 463 the ARP traffic load on each host on the network. On many networks, 464 ARP traffic is such an insignificant proportion of the total traffic 465 that doubling it makes no practical difference. However, this may not 466 be true of all networks, so broadcast ARP replies should not be used 467 universally. Broadcast ARP replies should be used where the benefit 468 of faster conflict detection outweighs the cost of slightly increased 469 packet processing load on the participant network hosts. 471 3. Security Considerations 473 The ARP protocol [RFC 826] is insecure. A malicious host may send 474 fraudulent ARP packets on the network, interfering with the correct 475 operation of other hosts. For example, it is easy for a host to 476 answer all ARP requests with replies giving its own hardware address, 477 thereby claiming ownership of every address on the network. 479 This specification makes this existing ARP vulnerability no worse, 480 and in some ways makes it better: Instead of failing silently with no 481 indication why, hosts implementing this specification are required to 482 either attempt to reconfigure automatically, or if not that, at least 483 inform the human user of what is happening. 485 4. Historical Note 487 A widely-known, but ineffective, duplicate address detection 488 technique called "gratuitous ARP" is found in many deployed systems 489 [Ste94]. This traditional gratuitous ARP implementation sends only 490 an ARP Announcement per Section 2.3 of this document when an 491 interface is first configured. The result is that the victim (the 492 existing address holder) logs an error, and the offender continues 493 operation, often without even detecting the problem. The 494 administrator is expected to note the log message on the victim and 495 repair the damage after the fact. 497 Implementers of this specification should be aware that this flaw is, 498 as of this writing, very widely deployed, and should take steps as 499 described in Sections 2.1 and 2.4 to mitigate the problem. 501 5. IANA Considerations 503 This document has no IANA-related considerations. 505 6. Acknowledgements 507 This document arose as a result of discussions on link-local 508 addressing, where it was not clear to many readers which elements of 509 link-local address management were specific to that particular 510 problem, and which elements were generic and applicable to all IPv4 511 address configuration mechanisms. The following people made valuable 512 comments in the course of that work and/or the subsequent editing 513 of this document: Bernard Aboba, Randy Bush, Jim Busse, James 514 Carlson, Pavani Diwanji, Ralph Droms, Donald Eastlake 3rd, Peter 515 Ford, Spencer Giacalone, Josh Graessley, Erik Guttman, Myron Hattig, 516 Hugh Holbrook, Richard Johnson, Kim Yong-Woon, Rod Lopez, Satish 517 Mundra, Thomas Narten, Erik Nordmark, Howard Ridenour, Pekka Savola, 518 Daniel Senie, Dieter Siegmund, Valery Smyslov and Ryan Troll. 520 7. Copyright 522 Copyright (C) The Internet Society 2001-2002. 523 All Rights Reserved. 525 This document and translations of it may be copied and furnished to 526 others, and derivative works that comment on or otherwise explain it 527 or assist in its implementation may be prepared, copied, published 528 and distributed, in whole or in part, without restriction of any 529 kind, provided that the above copyright notice and this paragraph are 530 included on all such copies and derivative works. However, this 531 document itself may not be modified in any way, such as by removing 532 the copyright notice or references to the Internet Society or other 533 Internet organizations, except as needed for the purpose of 534 developing Internet standards in which case the procedures for 535 copyrights defined in the Internet Standards process must be 536 followed, or as required to translate it into languages other than 537 English. 539 The limited permissions granted above are perpetual and will not be 540 revoked by the Internet Society or its successors or assigns. 542 This document and the information contained herein is provided on an 543 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 544 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 545 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 546 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 547 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 549 8. Normative References 551 [RFC 826] D. Plummer, "An Ethernet Address Resolution Protocol -or- 552 Converting Network Addresses to 48-bit Ethernet Address 553 for Transmission on Ethernet Hardware", STD 37, RFC 826, 554 November 1982. 556 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 557 Requirement Levels", RFC 2119, March 1997. 559 9. Informative References 561 [802.1d] ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC Bridges". 563 [RFC 2131] R. Droms, "Dynamic Host Configuration Protocol", 564 RFC 2131, March 1997. 566 [Ste94] W. Stevens, "TCP/IP Illustrated, Volume 1: The Protocols", 567 Addison-Wesley, 1994. 569 [v4LL] S. Cheshire, B. Aboba, E. Guttman, 570 "Dynamic Configuration of IPv4 Link-Local Addresses", 571 draft-ietf-zeroconf-ipv4-linklocal-07.txt, 572 Work in Progress, August 2002. 574 10. Author's Address 576 Stuart Cheshire 577 Apple Computer, Inc. 578 1 Infinite Loop 579 Cupertino 580 California 95014 581 USA 583 Phone: +1 408 974 3207 584 EMail: rfc@stuartcheshire.org