RFC2390 日本語訳

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

コメントを求めるワーキンググループT.ブラッドリーの要求をネットワークでつないでください: Inc.が時代遅れにする2390台のAviciシステム: 1293年のC.ブラウンカテゴリ: 標準化過程コンサルタントA.MalisはコミュニケーションInc.1998年9月に昇ります。

                  Inverse Address Resolution Protocol

逆さのアドレス解決プロトコル

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

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

Copyright(C)インターネット協会(1998)。 All rights reserved。

2.  Abstract

2. 要約

   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.

このメモはステーションに与えられたハードウェア・アドレスに対応するプロトコルアドレスを要求させるARPに追加について説明します。 明確に、これはData Link Connection Identifier(DLCI)、確立したPermanent Virtual Circuit(PVC)に関連づけられたハードウェア・アドレスのFrame Relay同等物を持っているかもしれませんが、この接続の反対側の上のステーションのプロトコルアドレスを知らないFrame Relayステーションに適用されます。 また、それは他のネットワークに同様の事情で適用されるでしょう。

   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.

このメモはRFC1293を取り替えます。 RFC1293からの変化は、言語を正式にするマイナーチェンジとパケットダイヤグラムの追加とセクション7.2、および新しいセキュリティ部の例です。

3.  Conventions

3. コンベンション

   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].

キーワードが解釈しなければならない、本書では現れるとき、[5]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?

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

RFC 2390          Inverse Address Resolution Protocol     September 1998

etブラッドリー、アル。 規格は逆さのアドレス解決プロトコル1998年9月にRFC2390を追跡します[1ページ]。

4.  Introduction

4. 序論

   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.

このドキュメントはInverse Address Resolutionプロトコル(InARP)がどう役に立つ場合があるかに関する例として大いにFrame Relayを当てにするでしょう。 しかしながら、InARPが排他的なFrame Relayと共に使用されることを意図しません。 InARPは対応するプロトコルアドレスを示さないで目的地ハードウェア・アドレスを提供するどんなネットワークにも使用されるかもしれません。

5.  Motivation

5. 動機

   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.

Inverse ARPの開発に関する動機はFrame Relayの中のダイナミックなアドレス解決を可能で、かつ効率的にする願望の結果です。 相手固定接続(PVCs)と結局交換仮想回路(SVCs)はData Link Connection Identifier(DLCI)によって特定されます。 これらのDLCIsは広域ネットワーク(WAN)を通して単独の仮想接続を定義して、ハードウェア・アドレスに同等なFrame Relayとして考えられるかもしれません。 シグナリングメッセージの交換を通して、定期的に、ネットワークは対応するDLCIと共に新しい仮想の回路を発表するかもしれません。 残念ながら、プロトコルアドレシングは発表に含まれていません。 そのような指示を受けるステーションは、新しい接続を知りますが、反対側を扱うことができないでしょう。 反対側のプロトコルアドレスを発見するための新しい構成もメカニズムがなければ、この新しい仮想の回路は使用不可能です。

   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.

他の解決メソッドは、問題を解決すると考えられましたが、拒絶されました。 例えば、逆のARP[4]は良い候補のように見えましたが、要求への応答は要求を受け取るステーションではなく、要求ステーションのプロトコルアドレスです。 IP以外の他のプロトコルの解決を許さないでしょう、したがって、IPの特定のメカニズムは制限でした。 この理由で、ARPプロトコルは広げられました。

   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.

逆さのAddress Resolutionプロトコル(InARP)で、Frame Relayステーションは仮想の回路に関連しているステーションのプロトコルアドレスを発見できるでしょう。 それはシステムが決議したがっているあらゆるアドレスとそれのためにあらゆるVCでメッセージをARPに送るのが静的な構成を当てにするよりフレキシブルであるというよりも効率的です。

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

RFC 2390          Inverse Address Resolution Protocol     September 1998

etブラッドリー、アル。 規格は逆さのアドレス解決プロトコル1998年9月にRFC2390を追跡します[2ページ]。

6.  Packet Format

6. パケット・フォーマット

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

逆さのARPは既存のARPの拡大です。 したがって、それには、標準の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

ar$のhrdの16ビットのHardwareはそれぞれのハードウェア・アドレス(n)arのhln8ドルのビットByteの長さにそれぞれの16ビットのプロトコルアドレス(m)ar$オプアートOperationコードar$sha nbytesソースハードウェア・アドレスar$鉱泉mbytesソースプロトコルアドレスar$tha nbytes目標ハードウェア・アドレスar$tpa mbytes目標プロトコルアドレスのpln8ドルのビットByteの長さにar$プロの16ビットのプロトコルタイプarをタイプします。

   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].

ハードウェアのための可能な値とプロトコルタイプは、ARPのためのそれらと同じであり、現在のAssigned民数記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.

長さのハードウェアとプロトコルアドレスはInARPが稼働する予定である環境に依存しています。 例えば、IPがFrame Relayをひいているなら、ハードウェア・アドレスの長さは、2、3、または4です、そして、プロトコルアドレスの長さは4です。

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

命令コードはメッセージ、要求または応答のタイプを示します。

      InARP request  = 8
      InARP response = 9

InARPは=8InARP応答=9を要求します。

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

これらの値は、他のARP拡張子と衝突しないように選ばれました。

7.  Protocol Operation

7. プロトコル操作

   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.

InARPがする例外があるARPが要求を放送しないとき、基本的なInARPは本質的には同じように作動します。 これは目的地ステーションのハードウェア・アドレスが既に知られているからです。

   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.

InARPをサポートするインタフェースがアクティブになると、それはInARPがアクティブであるそれぞれのアクティブなPVCを求めるInARPプロトコルと形式InARP要求を開始するべきです。 これをするために、要求ステーションはソースハードウェア、ソースプロトコルアドレス、および知られている目標ハードウェアアドレスを挿入することによって、単に要求をフォーマットします。 そして、それは目標プロトコルアドレスがさばく中詰めのゼロに合っています。 最終的に、それは、特定のネットワークのためにパケットをカプセルに入れって、直接目標ステーションにそれを送るでしょう。

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

RFC 2390          Inverse Address Resolution Protocol     September 1998

etブラッドリー、アル。 規格は逆さのアドレス解決プロトコル1998年9月にRFC2390を追跡します[3ページ]。

   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.

InARP要求を受け取ると、ARPが要求するいずれも置くようにステーションはリクエスタのプロトコルアドレス/ハードウェアアドレス・マッピングをARPキャッシュに置くかもしれません。 しかしながら、他のARP要求と異なって、受入れステーションは、それが受け取るどんなInARP要求もそれのために運命づけられていると仮定するかもしれません。 あらゆるInARP要求のために、受入れステーションは、応答のあて先アドレスとして要求からソースアドレスを使用することで適切な応答をフォーマットするべきです。 ステーションが返答したがっていないなら、それは要求を無視します。

   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.

要求ステーションがInARP応答を受けるとき、それは、ARPテーブル項目を終了して、提供されたアドレス情報を使用するかもしれません。 以下に注意してください。 ARPなら、InARPを通して学習された情報は、ある状況で熟成するか、または無効にされるかもしれません。

7.1.  Operation with Multi-Addressed Hosts

7.1. マルチ扱われたホストとの操作

   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.

この議論の文脈では、マルチ扱われたホストは複数のプロトコルアドレスを単一のインタフェースに割り当てさせるホストについて言及するでしょう。 そのようなステーションがInARP要求を受け取るなら、それは応じる1つのアドレスを選ばなければなりません。 受入れステーションは、そのような選択をするように、最初に要求ステーションのプロトコルアドレスを見て、次に、リクエスタのネットワークに対応するプロトコルアドレスで応じなければなりません。 例えば、要求ステーションがIPアドレスのために調べられているなら、応じることのマルチ扱われたステーションは要求ステーションと同じサブネットに一致しているIPアドレスで応じるべきです。 ステーションに要求に、適切なアドレスがないなら、それは応じるべきではありません。 IPの例では、受入れステーションが要求されたサブネットの一部であるインタフェースにIPアドレスを割り当てさせないなら、受入れステーションは応じないでしょう。

   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.

マルチ扱われたホストは与えられたインタフェースと定義されたそれぞれのアドレスを求めるInARP要求を送るべきです。 しかしながら、受信側が構成に依存する要求のいくつかかいずれにも答えないかもしれないことに注意されるべきです。

7.2.  Protocol Operation Within Frame Relay

7.2. フレームリレーの中のプロトコル操作

   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.

Inverse ARPを使用できる1つのケースがデータ・リンク管理インタフェースを通してDLCIsのシグナリングをサポートするフレームリレーインタフェースにあります。 備えられているステーションがそのようなインタフェースに接続したInARPはInARP要求をフォーマットして、新しい仮想の回路にそれを扱うでしょう。 反対側がInARPを支えるなら、それはアドレスが要求したプロトコルを示す応答を返すかもしれません。

   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:

フレームリレー環境で、InARPパケットは、ARPプロトコルを示す[3]で定義されたNLPID/SNAP書式を使用することでカプセルに入れられます。 明確に、パケットカプセル化は以下の通りになるでしょう:

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

RFC 2390          Inverse Address Resolution Protocol     September 1998

etブラッドリー、アル。 規格は逆さのアドレス解決プロトコル1998年9月にRFC2390を追跡します[4ページ]。

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

+----------+----------+ | Q.922アドレス| +----------+----------+ |ctrl0x03| パッド00| +----------+----------+ |nlpid0x80| oui0x00| +----------+ + | oui(cont)0x00 00| +----------+----------+ | pid0x08 06| +----------+----------+ | . | | . |

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

InARP要求自体のための書式は以下によって定義されます:

      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

ar$hrd(値がFrame Relay ar$に賛成して割り当てた0x000F)はあなたが(すなわち、IP=0x0800)ar$hln--2バイトか3バイトか4バイトアドレシング長さのar$pln--あなたが(IP=4のための)ar$オプアートを捜しているプロトコルアドレスのバイトの長さを捜しているタイプについて議定書の中で述べます--8 InARPはar$shaを要求します--ステーションar$鉱泉--ステーションar$tha--新たに発表された仮想の回路ar$tpaのQ.922アドレス--0を要求するアドレスについて議定書の中で述べるよう要求するQ.922[6]アドレス これは要求されていることです。

   The InARP response will be completed similarly.

InARP応答は同様に終了するでしょう。

      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

ar$hrd(値がFrame Relay ar$に賛成して割り当てた0x000F)はあなたが(すなわち、IP=0x0800)ar$hln--2バイトか3バイトか4バイトアドレシング長さのar$pln--あなたが(IP=4のための)ar$オプアートを捜しているプロトコルアドレスのバイトの長さを捜しているタイプについて議定書の中で述べます--9 InARP応答ar$sha--鉱泉--プロトコルアドレス要求されたar$tha--ステーションar$Q.922が扱うステーションar$tpaを要求するのについて応じることのQ.922アドレス--要求ステーションのプロトコルアドレス

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

アドレスが指定したQ.922がC/R、FECN、BECN、およびDEビットをゼロにセットさせることに注意してください。

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

RFC 2390          Inverse Address Resolution Protocol     September 1998

etブラッドリー、アル。 規格は逆さのアドレス解決プロトコル1998年9月にRFC2390を追跡します[5ページ]。

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

Frame Relayネットワークの上でInARPを使用するための手順は以下の通りです:

   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.

ほとんどのFrame Relayネットワークの中のDLCIsにはローカルの意味しかないので、端のステーションは特定のDLCIをそれ自体に割り当てさせないでしょう。 したがって、そのようなステーションには、InARP要求か応答に置くアドレスがありません。 幸い、Frame Relayネットワークは正しいDLCIsを入手するためのメソッドを提供します。 以下の局所的に扱われたFrame Relayネットワークのために提案されたソリューションはDLCIsがグローバルな意味を持っているネットワークに等しくうまくいくでしょう。

   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.

ネットワークを横断するとき、Frame Relayヘッダーの中に運ばれたDLCIは変更されています。 パケットが目的地に到着するとき、DLCIは受入れステーションの見地から送付ステーションに対応する値に用意ができていました。 例えば、以下の1図では、ステーションAがステーションBにメッセージを送るなら、それはDLCI50をFrame Relayヘッダーに置くでしょうに。 ステーションBがこのメッセージを受け取ったとき、しかしながら、DLCIはネットワークによって変更されて、DLCI70としてBに見えるでしょう。

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

~~~~~~~~~~~~~~~ ( ) +-----+ ( ) +-----+ | |-50------(--------------------)---------70-| | | A| ( ) | B| | |-60-----(---------+ ) | | +-----+ ( | ) +-----+、(|、)、(|、)、<。---フレームリレー~~~~~~~~~~~~~~~~ ネットワーク80| +-----+ | | | C| | | +-----+

                              Figure 1

図1

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

ステーションの間の線はデータリンク接続(DLCs)の代理をします。 数は各接続に関連している地方のDLCIを示します。

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

RFC 2390          Inverse Address Resolution Protocol     September 1998

etブラッドリー、アル。 規格は逆さのアドレス解決プロトコル1998年9月にRFC2390を追跡します[6ページ]。

              DLCI to Q.922 Address Table for Figure 1

図1のためのQ.922アドレス・テーブルへのDLCI

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

DLCIの(10進)のQ.922が、(十六進法)50 0x0C21 60 0x0CC1 70が0×1061であると扱う、80、0×1401

      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:

DLCIとQ.922[6]アドレスの間の相関関係の正式の記述のために、読者はその仕様に相談するべきです。 相関関係の概要は便宜のためにここに含まれています。 DLCIとQ.922アドレスの間の翻訳は、Q.922コード化形式を使用することで2バイト・アドレスの長さに基づいています。 形式は以下の通りです。

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

8 7 6 5 4 3 2 1 +------------------------+---+--+ | DLCI(高位)|C/R|EA| +--------------+----+----+---+--+ | DLCI(下側の)|FECN|BECN|DE|EA| +--------------+----+----+---+--+

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

InARPに関しては、FECN、BECN、C/R、およびDEビットは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.

InARPメッセージが目的地に達するとき、すべてのハードウェア・アドレスが無効になるでしょう。 しかしながら、フレームヘッダーで見つけられたアドレスは正しくなるでしょう。 レイヤリングの純粋さに違反しますが、Frame Relayは送付者ハードウェア・アドレスとしてヘッダーでアドレスを使用するかもしれません。 また、また、目標ハードウェアアドレスがInARPが要求する両方と応答で無効になることに注意されるべきです。 InARPがこれらの分野を当てにしないのでこれが問題を起こすべきでなくて、事実上、実装は、中詰めのゼロを合わせるか、または目標ハードウェアアドレス・フィールドを完全に無視するかもしれません。

   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:

図を例としての1、AがInverse ARPを使用するかもしれないステーションが、ステーションのプロトコルアドレスがDLCI50に関連づけたと発見する使用すること。 Inverse ARP要求は以下の通りでしょう:

              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

未知のA(DLCI50)ar$未知の8オプアート(InARP要求)ar$sha arドルの鉱泉pA ar$tha 0x0C21(DLCI50)ar$tpaからのInARP Request

   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:

駅Bがこのパケットを受けるとき、それはFrame RelayヘッダーからのQ.922アドレスでソースハードウェア・アドレスを変更するでしょう。 このように、AからのInARP要求はなるでしょう:

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

RFC 2390          Inverse Address Resolution Protocol     September 1998

etブラッドリー、アル。 規格は逆さのアドレス解決プロトコル1998年9月にRFC2390を追跡します[7ページ]。

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

未知のar$8(InARP要求)オプアートar sha0×1061ドルの(DLCI70)ar$鉱泉pA arドルのtha 0x0C21(DLCI50)ar$tpa。

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

駅Bは、Inverse ARP応答をフォーマットして、ステーションA:にそれを送るでしょう。

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

ar$未知の9オプアート(InARP応答)ar$sha arドルの鉱泉pB ar tha0×1061ドル(DLCI70)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:

ソースハードウェア・アドレスが未知であり、応答が受け取られているとき、ステーションAは、Frame Relayヘッダーからアドレスを抜粋して、ソースハードウェアアドレス・フィールドにそれを置くでしょう。 したがって、応答はなるでしょう:

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

ar$9(InARP応答)オプアートarドルのsha 0x0C21(DLCI50)ar$鉱泉pB ar tha0×1061ドル(DLCI70)ar$tpa pA

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

これは、Frame Relayインタフェースが入って来るパケットの処理を干渉するだけでよいことを意味します。

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

また、Frame Relayと共にARP[1]とRARP[4]を使用するための同様の手順の記述のための[3]を見てください。

8.  Security Considerations

8. セキュリティ問題

   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.

このドキュメントは、プロトコルのARPファミリーに機能強化を指定して、ARPに影響する同じセキュリティ規制と同様のアドレス解決プロトコルを受けることがあります。 認証がARPの一部でないので、使用(例えば、ホストものまね)に関連する安全保障問題が知られています。 追加担保メカニズムは全くこのドキュメントによってプロトコルのARPファミリーに追加されていません。

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

RFC 2390          Inverse Address Resolution Protocol     September 1998

etブラッドリー、アル。 規格は逆さのアドレス解決プロトコル1998年9月にRFC2390を追跡します[8ページ]。

9.  References

9. 参照

   [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.

[1] プラマー、D.、「イーサネットは解決プロトコルを扱います--、イーサネットハードウェアの上でトランスミッションのための48.bitイーサネットアドレスにネットワーク・プロトコルアドレスを変換する、」、STD37、RFC826(1982年11月)

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

[2] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。 参照: http://www.iana.org/numbers.html

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

1993年7月の[3]ブラッドリーとT.とブラウン、C.とA.Malis、「Multiprotocolはフレームリレーの上で内部連絡する」RFC1490。

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

[4] フィンリースンとR.とマンとR.とムガール人、J.とM.Theimer、「逆アドレス解決プロトコル」STD38、RFC903(1984年6月)。

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

[5] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[6] 情報技術(システムの間のテレコミュニケーションと情報Exchange)はNetwork Layer、ISO/IEC TR9577でIdentificationについて議定書の中で述べます: 1992.

10.  Authors' Addresses

10. 作者のアドレス

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

タオルブラッドリーAviciシステムInc.12エリザベス・Driveチェルムズフォード、MA 01824

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

以下に電話をしてください。 (978) 250-3344 メールしてください: tbradley@avici.com

   Caralyn Brown
   Consultant

Caralynブラウンコンサルタント

   EMail:  cbrown@juno.com

メール: cbrown@juno.com

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

アンドリューMalisはInc.1ロビンス・Roadウェストフォード、Communications MA 01886を昇ります。

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

以下に電話をしてください。 (978) 952-7414 メールしてください: malis@ascend.com

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

RFC 2390          Inverse Address Resolution Protocol     September 1998

etブラッドリー、アル。 規格は逆さのアドレス解決プロトコル1998年9月にRFC2390を追跡します[9ページ]。

11.  Full Copyright Statement

11. 完全な著作権宣言文

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

Copyright(C)インターネット協会(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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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]

etブラッドリー、アル。 標準化過程[10ページ]