idnits 2.17.1 draft-ietf-ion-inarp-update-02.txt: ** The Abstract section seems to be numbered 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-26) 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 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 Introduction section. ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 109 has weird spacing: '... ar$sha nby...' == Line 110 has weird spacing: '... ar$spa mby...' == Line 111 has weird spacing: '... ar$tha nby...' == Line 112 has weird spacing: '... ar$tpa mby...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (September 10, 1998) is 9360 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) == Unused Reference: '1' is defined on line 254, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (ref. '2') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1490 (ref. '3') (Obsoleted by RFC 2427) Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Bradley 3 INTERNET-DRAFT Avici Systems, Inc. 4 Obsoletes: 1293 C. Brown 5 Fore Systems, Inc. 6 A. Malis 7 Ascend Communications, Inc. 8 March 11, 1998 9 Expires September 10, 1998 11 Inverse Address Resolution Protocol 13 1. Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 27 Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 29 Rim). 31 This draft specifies an IAB standards track protocol for the Internet 32 community, and requests discussion and suggestions for improvements. 33 Please refer to the current edition of the "IAB Official Protocol 34 Standards" for the standardization state and status of this protocol. 35 Distribution of this memo is unlimited. 37 2. Abstract 39 This memo describes additions to ARP that will allow a station to 40 request a protocol address corresponding to a given hardware address. 41 Specifically, this applies to Frame Relay stations that may have a 42 Data Link Connection Identifier (DLCI), the Frame Relay equivalent of 43 a hardware address, associated with an established Permanent Virtual 44 Circuit (PVC), but do not know the protocol address of the station on 45 the other side of this connection. It will also apply to other 46 networks with similar circumstances. 48 This memo replaces RFC 1293. The changes from RFC 1293 are minor 49 changes to formalize the language, and the additions of a packet 50 diagram in section 7.2 and a new security section. 52 3. Conventions 54 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 55 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 56 document, are to be interpreted as described in [5]. 58 4. Introduction 60 This document will rely heavily on Frame Relay as an example of how 61 the Inverse Address Resolution Protocol (InARP) can be useful. It is 62 not, however, intended that InARP be used exclusively with Frame 63 Relay. InARP may be used in any network that provides destination 64 hardware addresses without indicating corresponding protocol 65 addresses. 67 5. Motivation 69 The motivation for the development of Inverse ARP is a result of the 70 desire to make dynamic address resolution within Frame Relay both 71 possible and efficient. Permanent virtual circuits (PVCs) and 72 eventually switched virtual circuits (SVCs) are identified by a Data 73 Link Connection Identifier (DLCI). These DLCIs define a single 74 virtual connection through the wide area network (WAN) and may be 75 thought of as the Frame Relay equivalent to a hardware address. 76 Periodically, through the exchange of signaling messages, a network 77 may announce a new virtual circuit with its corresponding DLCI. 78 Unfortunately, protocol addressing is not included in the 79 announcement. The station receiving such an indication will learn of 80 the new connection, but will not be able to address the other side. 81 Without a new configuration or a mechanism for discovering the 82 protocol address of the other side, this new virtual circuit is 83 unusable. 85 Other resolution methods were considered to solve the problems, but 86 were rejected. Reverse ARP [4], for example, seemed like a good 87 candidate, but the response to a request is the protocol address of 88 the requesting station, not the station receiving the request. IP 89 specific mechanisms were limiting since they would not allow 90 resolution of other protocols other than IP. For this reason, the ARP 91 protocol was expanded. 93 Inverse Address Resolution Protocol (InARP) will allow a Frame Relay 94 station to discover the protocol address of a station associated with 95 the virtual circuit. It is more efficient than sending ARP messages 96 on every VC for every address the system wants to resolve and it is 97 more flexible than relying on static configuration. 99 6. Packet Format 101 Inverse ARP is an extension of the existing ARP. Therefore, it has 102 the same format as standard ARP. 104 ar$hrd 16 bits Hardware type 105 ar$pro 16 bits Protocol type 106 ar$hln 8 bits Byte length of each hardware address (n) 107 ar$pln 8 bits Byte length of each protocol address (m) 108 ar$op 16 bits Operation code 109 ar$sha nbytes source hardware address 110 ar$spa mbytes source protocol address 111 ar$tha nbytes target hardware address 112 ar$tpa mbytes target protocol address 114 Possible values for hardware and protocol types are the same as those 115 for ARP and may be found in the current Assigned Numbers RFC [2]. 117 Length of the hardware and protocol address are dependent on the 118 environment in which InARP is running. For example, if IP is running 119 over Frame Relay, the hardware address length is either 2, 3, or 4, 120 and the protocol address length is 4. 122 The operation code indicates the type of message, request or reply. 124 InARP request = 8 125 InARP reply = 9 127 These values were chosen so as not to conflict with other ARP 128 extensions. 130 7. Protocol Operation 132 Basic InARP operates essentially the same as ARP with the exception 133 that InARP does not broadcast requests. This is because the hardware 134 address of the destination station is already known. 136 When an interface supporting InARP becomes active, it should initiate 137 the InARP protocol and format InARP requests for each active PVC for 138 which InARP is active. To do this, a requesting station simply 139 formats a request by inserting its source hardware, source protocol 140 addresses and the known target hardware address. It then zero fills 141 the target protocol address field. Finally, it will encapsulate the 142 packet for the specific network and send it directly to the target 143 station. 145 Upon receiving an InARP request, a station may put the requester's 146 protocol address/hardware address mapping into its ARP cache as it 147 would any ARP request. Unlike other ARP requests, however, the 148 receiving station may assume that any InARP request it receives is 149 destined for it. For every InARP request, the receiving station 150 should format a proper reply using the source addresses from the 151 request as the target addresses of the reply. If the station is 152 unable or unwilling to reply, it ignores the request. 154 When the requesting station receives the InARP reply, it may complete 155 the ARP table entry and use the provided address information. Note: 156 as with ARP, information learned via InARP may be aged or invalidated 157 under certain circumstances. 159 7.1. Operation with Multi-Addressed Hosts 161 In the context of this discussion, a multi-addressed host will refer 162 to a host that has multiple protocol addresses assigned to a single 163 interface. If such a station receives an InARP request, it must 164 choose one address with which to respond. To make such a selection, 165 the receiving station must first look at the protocol address of the 166 requesting station, and then respond with the protocol address 167 corresponding to the network of the requester. For example, if the 168 requesting station is probing for an IP address, the responding 169 multi-addressed station should respond with an IP address which 170 corresponds to the same subnet as the requesting station. If the 171 station does not have an address that is appropriate for the request 172 it should not respond. In the IP example, if the receiving station 173 does not have an IP address assigned to the interface that is a part 174 of the requested subnet, the receiving station would not respond. 176 A multi-addressed host should send an InARP request for each of the 177 addresses defined for the given interface. It should be noted, 178 however, that the receiving side may answer some or none of the 179 requests depending on its configuration. 181 7.2. Protocol Operation Within Frame Relay 183 One case where Inverse ARP can be used is on a frame relay interface 184 which supports signaling of DLCIs via a data link management 185 interface. An InARP equipped station connected to such an interface 186 will format an InARP request and address it to the new virtual 187 circuit. If the other side supports InARP, it may return a reply 188 indicating the protocol address requested. 190 In a frame relay environment, InARP packets are encapsulated using 191 the NLPID/SNAP format defined in [3] which indicates the ARP 192 protocol. Specifically, the packet encapsulation will be as follows: 194 +----------+----------+ 195 | Q.922 address | 196 +----------+----------+ 197 |ctrl 0x03 | pad 00 | 198 +----------+----------+ 199 |nlpid 0x80| oui 0x00 | 200 +----------+ + 201 | oui (cont) 0x00 00 | 202 +----------+----------+ 203 | pid 0x08 06 | 204 +----------+----------+ 205 | . | 206 | . | 208 The format for an InARP request itself is defined by the following: 210 ar$hrd - 0x000F the value assigned to Frame Relay 211 ar$pro - protocol type for which you are searching 212 (i.e. IP = 0x0800) 213 ar$hln - 2,3, or 4 byte addressing length 214 ar$pln - byte length of protocol address for which you 215 are searching (for IP = 4) 216 ar$op - 8; InARP request 217 ar$sha - Q.922 address of requesting station 218 ar$spa - protocol address of requesting station 219 ar$tha - Q.922 addressed of newly announced virtual circuit 220 ar$tpa - 0; This is what is being requested 222 The InARP response will be completed similarly. 224 ar$hrd - 0x000F the value assigned to Frame Relay 225 ar$pro - protocol type for which you are searching 226 (i.e. IP = 0x0800) 227 ar$hln - 2,3, or 4 byte addressing length 228 ar$pln - byte length of protocol address for which you 229 are searching (for IP = 4) 230 ar$op - 9; InARP response 231 ar$sha - Q.922 address of responding station 232 ar$spa - protocol address requested 233 ar$tha - Q.922 address of requesting station 234 ar$tpa - protocol address of requesting station 236 Note that the Q.922 addresses specified have the C/R, FECN, BECN, and 237 DE bits set to zero. 239 Procedures for using InARP over a Frame Relay network are identical 240 to those for using ARP and RARP discussed in [3]. 242 8. Security Considerations 244 This document specifies a functional enhancement to the ARP family of 245 protocols, and is subject to the same security constraints that 246 affect ARP and similar address resolution protocols. Because 247 authentication is not a part of ARP, there are known security issues 248 relating to its use (e.g., host impersonation). No additional 249 security mechanisms have been added to the ARP family of protocols by 250 this document. 252 9. References 254 [1] Plummer, D., "An Ethernet Address Resolution Protocol - or - 255 Converting Network Protocol Addresses to 48.bit Ethernet Address 256 for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT, 257 November 1982. 259 [2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 260 USC/Information Sciences Institute, October 1994 262 [3] Brown, C., Malis, A., "Multiprotocol Interconnect over Frame 263 Relay", RFC 1490, July 1993. 265 [4] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "A Reverse 266 Address Resolution Protocol", STD 38, RFC 903, Stanford 267 University, June 1984. 269 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 270 Levels", BCP 14, RFC 2119, Harvard University, March 1997. 272 10. Authors' Addresses 274 Terry Bradley 275 Avici Systems, Inc. 276 12 Elizabeth Drive 277 Chelmsford, MA 01824 278 Phone: (978) 250-3344 279 Email: tbradley@avici.com 280 Caralyn Brown 281 FORE Systems, Inc. 282 1 Corporate Drive 283 Andover, MA 01810 284 Phone: (978) 689-2400 x133 285 Email: cbrown@fore.com 287 Andrew Malis 288 Ascend Communications, Inc. 289 1 Robbins Road 290 Westford, MA 01886 291 Phone: (978) 952-7414 292 Email: malis@ascend.com