RFC1293 日本語訳

Network Working Group                                         T. Bradley
Request for Comments: 1293                                      C. Brown
                                          Wellfleet Communications, Inc.
                                                            January 1992

コメントを求めるワーキンググループT.ブラッドリーの要求をネットワークでつないでください: 1293 C.ブラウンWellfleetコミュニケーションInc.1992年1月

                  Inverse Address Resolution Protocol

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

1.  Status of this Memo

1. このMemoの状態

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

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

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ステーションに適用されます。 また、それは他のネットワークに同様の事情で適用されるでしょう。

3.  Conventions

3. コンベンション

   The following language conventions are used in the items of
   specification in this document:

以下の言語コンベンションは仕様に関する条項で本書では使用されます:

     o Must, Will, Shall or Mandatory -- the item is an absolute
       requirement of the specification.

o 必須、ウィル、ShallまたはMandatory--項目は仕様に関する絶対条件です。

     o Should or Recommended -- the item should generally be
       followed for all but exceptional circumstances.

o または、Recommended--一般に、商品はほとんど例外的な事情のために従われるべきです。

     o May or Optional -- the item is truly optional and may be
       followed or ignored according to the needs of the
       implementor.

o 5月かOptional--作成者の必要性に従って、商品は、本当に、任意であり、従われているか、または無視されるかもしれません。

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

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

Bradley, Brown                                                  [Page 1]

RFC 1293                      Inverse ARP                   January 1992

ブラッドリー、ブラウン[1ページ]RFC1293の逆さのARP1992年1月

   addresses.

アドレス。

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 are the
   Frame Relay equivalent to a hardware address.  Periodically, through
   the exchange of signalling 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 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 as we
   wanted.  IP specific mechanisms were limiting since we wished to
   allow protocol address resolution of many protocols.  For this
   reason, we expanded the ARP protocol.

他の解決メソッドは、問題を解決すると考えられましたが、拒絶されました。 例えば、逆のARP[4]は良い候補のように見えましたが、要求への応答はステーションではなく、私たちが欲しかったときに要求を受け取る要求ステーションのプロトコルアドレスです。 私たちが多くのプロトコルのプロトコルアドレス解決を許したかったので、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 efficiently than simulating a
   broadcast with multiple copies of the same message and it is more
   flexible than relying on static configuration.

逆さのAddress Resolutionプロトコル(InARP)で、Frame Relayステーションは仮想の回路に関連しているステーションのプロトコルアドレスを発見できるでしょう。 それは複本の同じメッセージとそれで放送をシミュレートするのが静的な構成を当てにするよりフレキシブルであるより効率的にそうです。

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をタイプします。

Bradley, Brown                                                  [Page 2]

RFC 1293                      Inverse ARP                   January 1992

ブラッドリー、ブラウン[2ページ]RFC1293の逆さのARP1992年1月

   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 between 2 and 4, and
   the protocol address length is 4.

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

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

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

      InARP request  = 8
      InARP reply = 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. A requesting
   station simply formats a request by inserting its source hardware and
   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がする例外があるARPが要求を放送しないとき、基本的なInARPは本質的には同じように作動します。 これは目的地ステーションのハードウェア・アドレスが既に知られているからです。 要求ステーションは、ソースハードウェア、プロトコルアドレス、および知られている目標ハードウェアアドレスを挿入することによって、単に要求をフォーマットします。 そして、それは目標プロトコルアドレスがさばく中詰めのゼロに合っています。 最終的に、それは、特定のネットワークのためにパケットをカプセルに入れって、直接目標ステーションにそれを送るでしょう。

   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 may
   format a proper reply using the source addresses from the request as
   the target addresses of the reply.  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 reply, 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

この議論の文脈では、Multiによって扱われたホストは複数のプロトコルアドレスを単一のインタフェースに割り当てさせるホストについて言及するでしょう。 そのようなステーションがInARP要求を受け取るなら、それは応じる1つのアドレスを選ばなければなりません。 そのような選択、ステーションが最初にプロトコルアドレスを見なければならない受信を作ります。

Bradley, Brown                                                  [Page 3]

RFC 1293                      Inverse ARP                   January 1992

ブラッドリー、ブラウン[3ページ]RFC1293の逆さのARP1992年1月

   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.

リクエスタのネットワークに対応するプロトコルアドレスで配置して、その時応じるよう要求します。 例えば、要求ステーションがIPアドレスのために調べられているなら、応じることのマルチ扱われたステーションは要求ステーションと同じサブネットに一致しているIPアドレスで応じるべきです。 ステーションに要求に、適切なアドレスがないなら、それは応じるべきではありません。 IPの例では、受入れステーションが要求されたサブネットの一部であるインタフェースにIPアドレスを割り当てさせないなら、受入れステーションは応じないでしょう。

   A multi-addressed host may choose to 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 when a new virtual circuit
   is signalled.  The Frame Relay station may format an InARP request
   addressed to the new virtual circuit.  If the other side supports
   InARP, it may return a reply indicating the protocol address
   requested.

Inverse ARPを使用できる1つのケースが新しい仮想の回路が合図される時です。 Frame Relayステーションは新しい仮想の回路に扱われたInARP要求をフォーマットするかもしれません。 反対側がInARPを支えるなら、それはアドレスが要求したプロトコルを示す回答を返すかもしれません。

   The format for an InARP request is a follows:

形式はInARP要求がaであるので、続きます:

      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 address of requesting station
      ar$spa - protocol address of requesting station
      ar$tha - Q.922 addressed of newly announced virtual circuit
      ar$tpa - 0; This is what we're looking for

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

Bradley, Brown                                                  [Page 4]

RFC 1293                      Inverse ARP                   January 1992

ブラッドリー、ブラウン[4ページ]RFC1293の逆さのARP1992年1月

   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ビットをゼロにセットさせることに注意してください。

   Procedures for using InARP over a Frame Relay network are identical
   to those for using ARP and RARP discussed in section 10 of the
   Multiprotocol Interconnect over Frame Relay Networks document [3].

Frame Relay Networksドキュメント[3]の上にMultiprotocol Interconnectのセクション10で議論したARPとRARPを使用するのに、Frame Relayネットワークの上でInARPを使用するための手順はそれらと同じです。

8.  References

8. 参照

   [1]  Plummer, David C., "An Ethernet Address Resolution Protocol",
        RFC-826, November 1982.

1982年11月の[1] プラマー、デヴィッドC.、「イーサネットアドレス解決プロトコル」RFC-826。

   [2]   Reynolds, J. and Postel, J., "Assigned Numbers", RFC-1060, ISI,
        March 1990.

[2] レイノルズとJ.とポステル、J.、「規定番号」、RFC-1060、ISI、1990年3月。

   [3]  Bradley, T., Brown, C., Malis, A.,   "Multiprotocol Interconnect
        over Frame Relay Networks", RFC-1294, January 1992.

[3]ブラッドリー、T.、ブラウン、C.、Malis、A.、「Multiprotocolはフレームリレーネットワークの上で内部連絡する」RFC-1294、1992年1月。

   [4]  Finlayson, Mann, Mogul, Theimer, "A Reverse Address Resolution
        Protocol", RFC-903, Stanford University, June 1984.

[4] フィンリースン、マン、ムガール人、Theimer、「逆アドレス解決プロトコル」、RFC-903、スタンフォード大学、1984年6月。

9.  Security Considerations

9. セキュリティ問題

   Security issues are not addressed in this memo.

安全保障問題はこのメモで扱われません。

Bradley, Brown                                                  [Page 5]

RFC 1293                      Inverse ARP                   January 1992

ブラッドリー、ブラウン[5ページ]RFC1293の逆さのARP1992年1月

10.  Authors' Addresses

10. 作者のアドレス

      Terry Bradley
      Wellfleet Communications, Inc.
      15 Crosby Drive
      Bedford, MA  01730

Inc.15クロズビー・Driveベッドフォード、タオルブラッドリーWellfleet Communications MA 01730

      Phone:  (617) 275-2400

以下に電話をしてください。 (617) 275-2400

      Email:  tbradley@wellfleet.com

メール: tbradley@wellfleet.com

      Caralyn Brown
      Wellfleet Communications, Inc.
      15 Crosby Drive
      Bedford, MA  01730

Inc.15クロズビー・Driveベッドフォード、CaralynブラウンWellfleet Communications MA 01730

      Phone:  (617) 275-2400

以下に電話をしてください。 (617) 275-2400

      Email:  cbrown@wellfleet.com

メール: cbrown@wellfleet.com

Bradley, Brown                                                  [Page 6]

ブラッドリー、ブラウン[6ページ]