File: rfc2390.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (563 lines) | stat: -rw-r--r-- 20,849 bytes parent folder | download | duplicates (7)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563






Network Working Group                                         T. Bradley
Request for Comments: 2390                           Avici Systems, Inc.
Obsoletes: 1293                                                 C. Brown
Category: Standards Track                                     Consultant
                                                                A. Malis
                                             Ascend Communications, Inc.
                                                          September 1998


                  Inverse Address Resolution Protocol

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

2.  Abstract

   This memo describes additions to ARP that will allow a station to
   request a protocol address corresponding to a given hardware address.
   Specifically, this applies to Frame Relay stations that may have a
   Data Link Connection Identifier (DLCI), the Frame Relay equivalent of
   a hardware address, associated with an established Permanent Virtual
   Circuit (PVC), but do not know the protocol address of the station on
   the other side of this connection.  It will also apply to other
   networks with similar circumstances.

   This memo replaces RFC 1293.  The changes from RFC 1293 are minor
   changes to formalize the language, the additions of a packet diagram
   and an example in section 7.2, and a new security section.

3.  Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [5].








Bradley, et. al.            Standards Track                     [Page 1]

RFC 2390          Inverse Address Resolution Protocol     September 1998


4.  Introduction

   This document will rely heavily on Frame Relay as an example of how
   the Inverse Address Resolution Protocol (InARP) can be useful. It is
   not, however, intended that InARP be used exclusively with Frame
   Relay.  InARP may be used in any network that provides destination
   hardware addresses without indicating corresponding protocol
   addresses.

5.  Motivation

   The motivation for the development of Inverse ARP is a result of the
   desire to make dynamic address resolution within Frame Relay both
   possible and efficient.  Permanent virtual circuits (PVCs) and
   eventually switched virtual circuits (SVCs) are identified by a Data
   Link Connection Identifier (DLCI).  These DLCIs define a single
   virtual connection through the wide area network (WAN) and may be
   thought of as the Frame Relay equivalent to a hardware address.
   Periodically, through the exchange of signaling messages, a network
   may announce a new virtual circuit with its corresponding DLCI.
   Unfortunately, protocol addressing is not included in the
   announcement.  The station receiving such an indication will learn of
   the new connection, but will not be able to address the other side.
   Without a new configuration or a mechanism for discovering the
   protocol address of the other side, this new virtual circuit is
   unusable.

   Other resolution methods were considered to solve the problems, but
   were rejected.  Reverse ARP [4], for example, seemed like a good
   candidate, but the response to a request is the protocol address of
   the requesting station, not the station receiving the request.  IP
   specific mechanisms were limiting since they would not allow
   resolution of other protocols other than IP. For this reason, the ARP
   protocol was expanded.

   Inverse Address Resolution Protocol (InARP) will allow a Frame Relay
   station to discover the protocol address of a station associated with
   the virtual circuit.  It is more efficient than sending ARP messages
   on every VC for every address the system wants to resolve and it is
   more flexible than relying on static configuration.











Bradley, et. al.            Standards Track                     [Page 2]

RFC 2390          Inverse Address Resolution Protocol     September 1998


6.  Packet Format

   Inverse ARP is an extension of the existing ARP.  Therefore, it has
   the same format as standard ARP.

      ar$hrd   16 bits         Hardware type
      ar$pro   16 bits         Protocol type
      ar$hln    8 bits         Byte length of each hardware address (n)
      ar$pln    8 bits         Byte length of each protocol address (m)
      ar$op    16 bits         Operation code
      ar$sha    nbytes         source hardware address
      ar$spa    mbytes         source protocol address
      ar$tha    nbytes         target hardware address
      ar$tpa    mbytes         target protocol address

   Possible values for hardware and protocol types are the same as those
   for ARP and may be found in the current Assigned Numbers RFC [2].

   Length of the hardware and protocol address are dependent on the
   environment in which InARP is running.  For example, if IP is running
   over Frame Relay, the hardware address length is either 2, 3, or 4,
   and the protocol address length is 4.

   The operation code indicates the type of message, request or
   response.

      InARP request  = 8
      InARP response = 9

   These values were chosen so as not to conflict with other ARP
   extensions.

7.  Protocol Operation

   Basic InARP operates essentially the same as ARP with the exception
   that InARP does not broadcast requests.  This is because the hardware
   address of the destination station is already known.

   When an interface supporting InARP becomes active, it should initiate
   the InARP protocol and format InARP requests for each active PVC for
   which InARP is active.  To do this, a requesting station simply
   formats a request by inserting its source hardware, source protocol
   addresses and the known target hardware address.  It then zero fills
   the target protocol address field.  Finally, it will encapsulate the
   packet for the specific network and send it directly to the target
   station.





Bradley, et. al.            Standards Track                     [Page 3]

RFC 2390          Inverse Address Resolution Protocol     September 1998


   Upon receiving an InARP request, a station may put the requester's
   protocol address/hardware address mapping into its ARP cache as it
   would any ARP request.  Unlike other ARP requests, however, the
   receiving station may assume that any InARP request it receives is
   destined for it.  For every InARP request, the receiving station
   should format a proper response using the source addresses from the
   request as the target addresses of the response.  If the station is
   unable or unwilling to reply, it ignores the request.

   When the requesting station receives the InARP response, it may
   complete the ARP table entry and use the provided address
   information.  Note: as with ARP, information learned via InARP may be
   aged or invalidated under certain circumstances.

7.1.  Operation with Multi-Addressed Hosts

   In the context of this discussion, a multi-addressed host will refer
   to a host that has multiple protocol addresses assigned to a single
   interface.  If such a station receives an InARP request, it must
   choose one address with which to respond.  To make such a selection,
   the receiving station must first look at the protocol address of the
   requesting station, and then respond with the protocol address
   corresponding to the network of the requester.  For example, if the
   requesting station is probing for an IP address, the responding
   multi-addressed station should respond with an IP address which
   corresponds to the same subnet as the requesting station.  If the
   station does not have an address that is appropriate for the request
   it should not respond.  In the IP example, if the receiving station
   does not have an IP address assigned to the interface that is a part
   of the requested subnet, the receiving station would not respond.

   A multi-addressed host should send an InARP request for each of the
   addresses defined for the given interface.  It should be noted,
   however, that the receiving side may answer some or none of the
   requests depending on its configuration.

7.2.  Protocol Operation Within Frame Relay

   One case where Inverse ARP can be used is on a frame relay interface
   which supports signaling of DLCIs via a data link management
   interface.  An InARP equipped station connected to such an interface
   will format an InARP request and address it to the new virtual
   circuit.  If the other side supports InARP, it may return a response
   indicating the protocol address requested.

   In a frame relay environment, InARP packets are encapsulated using
   the NLPID/SNAP format defined in [3] which indicates the ARP
   protocol.  Specifically, the packet encapsulation will be as follows:



Bradley, et. al.            Standards Track                     [Page 4]

RFC 2390          Inverse Address Resolution Protocol     September 1998


               +----------+----------+
               |    Q.922 address    |
               +----------+----------+
               |ctrl 0x03 | pad 00   |
               +----------+----------+
               |nlpid 0x80| oui 0x00 |
               +----------+          +
               | oui (cont) 0x00 00  |
               +----------+----------+
               | pid 0x08 06         |
               +----------+----------+
               |          .          |
               |          .          |


   The format for an InARP request itself is defined by the following:

      ar$hrd - 0x000F the value assigned to Frame Relay
      ar$pro - protocol type for which you are searching
                  (i.e.  IP = 0x0800)
      ar$hln - 2,3, or 4 byte addressing length
      ar$pln - byte length of protocol address for which you
                  are searching (for IP = 4)
      ar$op  - 8; InARP request
      ar$sha - Q.922 [6] address of requesting station
      ar$spa - protocol address of requesting station
      ar$tha - Q.922 address of newly announced virtual circuit
      ar$tpa - 0; This is what is being requested

   The InARP response will be completed similarly.

      ar$hrd - 0x000F the value assigned to Frame Relay
      ar$pro - protocol type for which you are searching
                 (i.e.  IP = 0x0800)
      ar$hln - 2,3, or 4 byte addressing length
      ar$pln - byte length of protocol address for which you
                 are searching (for IP = 4)
      ar$op  - 9; InARP response
      ar$sha - Q.922 address of responding station
      ar$spa - protocol address requested
      ar$tha - Q.922 address of requesting station
      ar$tpa - protocol address of requesting station

   Note that the Q.922 addresses specified have the C/R, FECN, BECN, and
   DE bits set to zero.






Bradley, et. al.            Standards Track                     [Page 5]

RFC 2390          Inverse Address Resolution Protocol     September 1998


   Procedures for using InARP over a Frame Relay network are as follows:

   Because DLCIs within most Frame Relay networks have only local
   significance, an end station will not have a specific DLCI assigned
   to itself.  Therefore, such a station does not have an address to put
   into the InARP request or response.  Fortunately, the Frame Relay
   network does provide a method for obtaining the correct DLCIs. The
   solution proposed for the locally addressed Frame Relay network below
   will work equally well for a network where DLCIs have global
   significance.

   The DLCI carried within the Frame Relay header is modified as it
   traverses the network.  When the packet arrives at its destination,
   the DLCI has been set to the value that, from the standpoint of the
   receiving station, corresponds to the sending station.  For example,
   in figure 1 below, if station A were to send a message to station B,
   it would place DLCI 50 in the Frame Relay header.  When station B
   received this message, however, the DLCI would have been modified by
   the network and would appear to B as DLCI 70.

                           ~~~~~~~~~~~~~~~
                          (                )
        +-----+          (                  )             +-----+
        |     |-50------(--------------------)---------70-|     |
        |  A  |        (                      )           |  B  |
        |     |-60-----(---------+            )           |     |
        +-----+         (        |           )            +-----+
                         (       |          )
                          (      |         )  <---Frame Relay
                           ~~~~~~~~~~~~~~~~         network
                                 80
                                 |
                              +-----+
                              |     |
                              |  C  |
                              |     |
                              +-----+

                              Figure 1

      Lines between stations represent data link connections (DLCs).
      The numbers indicate the local DLCI associated with each
      connection.








Bradley, et. al.            Standards Track                     [Page 6]

RFC 2390          Inverse Address Resolution Protocol     September 1998


              DLCI to Q.922 Address Table for Figure 1

              DLCI (decimal)  Q.922 address (hex)
                   50              0x0C21
                   60              0x0CC1
                   70              0x1061
                   80              0x1401

      For authoritative description of the correlation between DLCI and
      Q.922 [6] addresses, the reader should consult that specification.
      A summary of the correlation is included here for convenience. The
      translation between DLCI and Q.922 address is based on a two byte
      address length using the Q.922 encoding format.  The format is:

                8   7   6   5   4   3    2   1
              +------------------------+---+--+
              |  DLCI (high order)     |C/R|EA|
              +--------------+----+----+---+--+
              | DLCI (lower) |FECN|BECN|DE |EA|
              +--------------+----+----+---+--+

      For InARP, the FECN, BECN, C/R and DE bits are assumed to be 0.

   When an InARP message reaches a destination, all hardware addresses
   will be invalid.  The address found in the frame header will,
   however, be correct. Though it does violate the purity of layering,
   Frame Relay may use the address in the header as the sender hardware
   address.  It should also be noted that the target hardware address,
   in both the InARP request and response, will also be invalid.  This
   should not cause problems since InARP does not rely on these fields
   and in fact, an implementation may zero fill or ignore the target
   hardware address field entirely.

   Using figure 1 as an example, station A may use Inverse ARP to
   discover the protocol address of the station associated with its DLCI
   50.  The Inverse ARP request would be as follows:

              InARP Request from A (DLCI 50)
              ar$op   8       (InARP request)
              ar$sha  unknown
              ar$spa  pA
              ar$tha  0x0C21  (DLCI 50)
              ar$tpa  unknown

   When Station B receives this packet, it will modify the source
   hardware address with the Q.922 address from the Frame Relay header.
   This way, the InARP request from A will become:




Bradley, et. al.            Standards Track                     [Page 7]

RFC 2390          Inverse Address Resolution Protocol     September 1998


              ar$op   8       (InARP request)
              ar$sha  0x1061  (DLCI 70)
              ar$spa  pA
              ar$tha  0x0C21  (DLCI 50)
              ar$tpa  unknown.

   Station B will format an Inverse ARP response and send it to station
   A:

              ar$op   9       (InARP response)
              ar$sha  unknown
              ar$spa  pB
              ar$tha  0x1061  (DLCI 70)
              ar$tpa  pA

   The source hardware address is unknown and when the response is
   received, station A will extract the address from the Frame Relay
   header and place it in the source hardware address field.  Therefore,
   the response will become:

              ar$op   9       (InARP response)
              ar$sha  0x0C21  (DLCI 50)
              ar$spa  pB
              ar$tha  0x1061  (DLCI 70)
              ar$tpa  pA

   This means that the Frame Relay interface must only intervene in the
   processing of incoming packets.

   Also, see [3] for a description of similar procedures for using ARP
   [1] and RARP [4] with Frame Relay.

8.  Security Considerations

   This document specifies a functional enhancement to the ARP family of
   protocols, and is subject to the same security constraints that
   affect ARP and similar address resolution protocols.  Because
   authentication is not a part of ARP, there are known security issues
   relating to its use (e.g., host impersonation).  No additional
   security mechanisms have been added to the ARP family of protocols by
   this document.










Bradley, et. al.            Standards Track                     [Page 8]

RFC 2390          Inverse Address Resolution Protocol     September 1998


9.  References

   [1] Plummer, D., "An Ethernet Address Resolution Protocol - or -
       Converting Network Protocol Addresses to 48.bit Ethernet Address
       for Transmission on Ethernet Hardware", STD 37, RFC 826, November
       1982.

   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
       October 1994.  See also: http://www.iana.org/numbers.html

   [3] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect
       over Frame Relay", RFC 1490, July 1993.

   [4] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "A Reverse
       Address Resolution Protocol", STD 38, RFC 903, June 1984.

   [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

   [6] Information technology - Telecommunications and Information
       Exchange between systems - Protocol Identification in the Network
       Layer, ISO/IEC TR 9577: 1992.

10.  Authors' Addresses

   Terry Bradley
   Avici Systems, Inc.
   12 Elizabeth Drive
   Chelmsford, MA  01824

   Phone: (978) 250-3344
   EMail: tbradley@avici.com


   Caralyn Brown
   Consultant

   EMail:  cbrown@juno.com


   Andrew Malis
   Ascend Communications, Inc.
   1 Robbins Road
   Westford, MA  01886

   Phone:  (978) 952-7414
   EMail:  malis@ascend.com




Bradley, et. al.            Standards Track                     [Page 9]

RFC 2390          Inverse Address Resolution Protocol     September 1998


11.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Bradley, et. al.            Standards Track                    [Page 10]