idnits 2.17.1 draft-malkin-unarp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC826, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- (Using the creation date from RFC826, updated by this document, for RFC5378 checks: 1982-11-01) -- 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 (November 1994) is 10753 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: 8 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 draft-malkin-unarp-00.txt G. Malkin 3 ARP Extension - UNARP Xylogics, Inc. 4 Updates: RFC 826 November 1994 6 ARP Extension - UNARP 8 Abstract 10 The Address Resolution Protocol allows an IP node to determine the 11 hardware (datalink) address of a neighboring node on a broadcast 12 network. The protocol depends on timers to age away old ARP entries. 13 This document specifies a trivial modification to the ARP mechanism, 14 not the packet format, which allows a node to announce that it is 15 leaving the network and that all other nodes should modify their ARP 16 tables accordingly. 18 Status of this Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 To learn the current status of any Internet-Draft, please check the 31 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 32 Directories on ds.internic.net (US East Coast), nic.nordu.net 33 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 34 Rim). 36 Acknowledgements 38 Thanks to James Carlson/Xylogics for reviewing this document and 39 proposing the backwards compatibility mechanism. 41 1. Introduction 43 The primary purpose of the Address Resolution Protocol, as defined in 44 [1], is to determine a node's hardware address based on its network 45 address (protocol address in ARPspeak). The ARP protocol 46 specifically states that nodes should not periodically advertise 47 their existence for two reasons: first, this would generate a lot of 48 network traffic and table maintenance overhead; second, it is highly 49 unlikely that all nodes will need to communicate to all other nodes. 50 Since a node does not advertise its existence, neither does it 51 advertise its imminent departure. This is not a serious problem 52 since most ARP implementations maintain timers to age away old 53 entries, and departing nodes seldom depart gracefully in any case. 55 Over time, an additional use has been found for ARP: Proxy ARP. 56 While there are those who believe Proxy ARP is an evil thing, it does 57 serve a purpose; that is, it allows for communication in ways never 58 considered in the original IP architecture. For example, allows 59 dial-in hosts to connect to a network without consuming a large 60 amount of the IP address space (i.e., all of the hosts contain 61 addresses on the same subnet, even though they are not directly 62 attached to the physical network associated with that subnet address. 63 It is this use of Proxy ARP which produces the problem addressed by 64 this document. 66 2. The Problem 68 Consider the following topology: 70 +--------+ 71 | Host A | 72 +--------+ 73 | 74 ======================================== LAN 75 | | 76 +--------+ +--------+ 77 | CS1 | comm. servers | CS2 | 78 +--------+ +--------+ 79 | | | | 80 +-+ +-+ +-+ +-+ 81 | | | | modems | | | | 82 +-+ +-+ +-+ +-+ 84 Assume that all of the modems are on the same rotary; that is, when a 85 remote host dials in, it may be assigned a modem on either of the 86 communication servers. Further assume that all of the remote hosts' 87 IP addresses have the same subnet address as the servers and Host A, 88 this in order to conserve address space. 90 To begin, a remote host dials into CS1 and attempts to communicate 91 with Host A. Host A will assume, based on the subnet mask, that the 92 remote host is actually attached to the LAN and will issue an ARP 93 Request to determine its hardware address. Naturally, the remote 94 host will not hear this request. CS1, knowing this, will respond in 95 the remote host's place with its own hardware address. Host A, on 96 receiving the ARP Reply, will then communicate with the remote host, 97 transparently through CS1. So far everything is just fine. 99 Now, the remote host disconnects and, before Host A can age its ARP 100 cache, reconnects through CS2. Herein lies the problem. Whenever 101 Host A attempts to send a packet to the remote host, it will send it 102 to CS1 because it cannot know that its ARP cache entry is invalid. 103 If, when the remote host disconnects, the server to which it was 104 attached could inform other nodes on the LAN that the protocol 105 address/hardware address mapping was no longer valid, the problem 106 would not occur. 108 3. The Solution 110 When a server, as described above, disconnects from a remote host for 111 which it has responded to a Proxy ARP, it broadcasts an UNARP. An 112 UNARP is an unsolicited ARP Reply with the following field values: 114 Hardware Address Space as appropriate 115 Protocol Address Space 0x800 (IP) 116 Hardware Address Length 0 (see Backwards Compatibility) 117 Protocol Address Length 4 (length of an IP address) 118 Opcode 2 (Reply) 119 Source Hardware Address Not Included 120 Source Protocol Address IP address of detaching host 121 Target Hardware Address Not Included 122 Target Protocol Address 255.255.255.255 (IP broadcast) 124 NOTE: this is a 16-byte packet (not including MAC header) 126 On receiving an UNARP, a node deletes the ARP cache entry associated 127 with the IP address. 129 It is not strictly necessary that a server keep state information 130 about whether or not it has actually sent a Proxy ARP Reply; it would 131 be sufficient if a server always sends an UNARP when a remote host 132 disconnects. 134 Of course, there is no reason why a host which gracefully detaches 135 from a LAN cannot also send an UNARP for itself. This would be 136 especially useful if, upon re-attaching, it might have a different 137 hardware address. 139 4. Backwards Compatibility 141 The modifications to support UNARP are trivial, so there is every 142 expectation that it will be widely supported. Of course, there will 143 be a period of time during which nodes which support UNARP will 144 coexist with nodes which do not support UNARP. To prevent 145 unenlightened nodes from adding spurious ARP cache entries with 146 hardware addresses of zero, UNARP packets specify a hardware address 147 length of zero. This should be rejected by nodes which do not 148 support UNARP. As a consequence of this, the source and target 149 hardware address fields do not exist in UNARP packets (as previously 150 described). 152 5. Security Considerations 154 Security issues are not discussed in this memo. 156 References 158 [1] Plummer, David C., "An Ethernet Address Resolution Protocol", 159 Request for Comments 826 (STD 37), November 1982. 161 Author's Address 163 Gary Scott Malkin 164 Xylogics, Inc. 165 53 Third Avenue 166 Burlington, MA 01803 168 Phone: (617) 272-8140 169 EMail: gmalkin@xylogics.com