[要約] RFC 2390は、逆アドレス解決プロトコル（Inverse Address Resolution Protocol）に関する仕様です。このRFCの目的は、IPアドレスからMACアドレスを逆に解決するためのプロトコルを定義することです。
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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への追加について説明します。具体的には、これはデータリンク接続識別子（DLCI）を持つフレームリレーステーションに適用されます。DLCIは、確立された固定仮想回路（PVC）に関連付けられたハードウェアアドレスに相当するフレームリレーですが、ステーションのプロトコルアドレスがわかりません。この接続の反対側。同様の状況の他のネットワークにも適用されます。
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.
このメモは、RFC 1293に代わるものです。RFC1293からの変更は、言語を正式化するためのマイナーな変更、パケット図の追加、セクション7.2の例、および新しいセキュリティセクションです。
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].
このドキュメントに記載されているキーワードは、必須、必須、必須、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、およびOPTIONALであり、[5]で説明されているように解釈されます。
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.
このドキュメントは、逆アドレス解決プロトコル（InARP）がどのように役立つかを示す例として、フレームリレーに大きく依存します。ただし、InARPがフレームリレーでのみ使用されることは意図されていません。 InARPは、対応するプロトコルアドレスを示さずに宛先ハードウェアアドレスを提供する任意のネットワークで使用できます。
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の開発の動機は、フレームリレー内で動的アドレス解決を可能かつ効率的にしたいという願望の結果です。相手先固定接続（PVC）および最終的には相手先選択接続（SVC）は、データリンク接続識別子（DLCI）によって識別されます。これらのDLCIは、広域ネットワーク（WAN）を介した単一の仮想接続を定義し、ハードウェアアドレスに相当するフレームリレーと考えることができます。定期的に、シグナリングメッセージの交換を通じて、ネットワークは対応する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.
他の解決方法が問題を解決するために検討されましたが、拒否されました。たとえば、Reverse 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.
逆アドレス解決プロトコル（InARP）を使用すると、フレームリレーステーションは、仮想回線に関連付けられたステーションのプロトコルアドレスを検出できます。これは、システムが解決する必要のあるすべてのアドレスのすべてのVCでARPメッセージを送信するよりも効率的であり、静的構成に依存するよりも柔軟性があります。
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ビットハードウェアタイプar $ pro 16ビットプロトコルタイプar $ hln 8ビット各ハードウェアアドレスのバイト長（n）ar $ pln 8ビット各プロトコルアドレスのバイト長（m）ar $ op 16ビットオペレーションコードar $ sha nbytesソースハードウェアアドレスar $ spa mbytesソースプロトコルアドレスar $ tha nbytesターゲットハードウェアアドレスar $ tpa mbytesターゲットプロトコルアドレス
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の値と同じであり、現在の割り当て番号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がフレームリレーで実行されている場合、ハードウェアアドレスの長さは2、3、または4のいずれかであり、プロトコルアドレスの長さは4です。
The operation code indicates the type of message, request or response.
オペレーションコードは、メッセージ、リクエスト、またはレスポンスのタイプを示します。
InARP request = 8 InARP response = 9
InARPリクエスト= 8 InARPレスポンス= 9
These values were chosen so as not to conflict with other ARP extensions.
これらの値は、他のARP拡張と競合しないように選択されています。
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は、InARPが要求をブロードキャストしないことを除いて、基本的にARPと同じように動作します。これは、宛先ステーションのハードウェアアドレスがすでにわかっているためです。
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プロトコルを開始し、InARPがアクティブであるアクティブなPVCごとに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 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を介して学習した情報は、特定の状況下で古くなったり無効になったりする場合があります。
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要求を送信する必要があります。ただし、受信側は、その構成に応じて一部またはすべての要求に応答しない場合があります。
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つのケースは、データリンク管理インターフェイスを介したDLCIのシグナリングをサポートするフレームリレーインターフェイス上です。このようなインターフェイスに接続された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フォーマットを使用してカプセル化されます。具体的には、パケットのカプセル化は次のようになります。
+----------+----------+
| 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:
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
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-0x000Fフレームリレーに割り当てられた値ar $ pro-検索するプロトコルタイプ（IP = 0x0800）ar $ hln-2、3、または4バイトのアドレッシング長ar $ pln-プロトコルアドレスのバイト長検索対象（IP = 4の場合）ar $ op-9; InARP応答ar $ sha-応答ステーションのQ.922アドレスar $ spa-要求されたプロトコルアドレスar $ tha-要求ステーションのQ.922アドレスar $ tpa-要求ステーションのプロトコルアドレス
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 as follows:
フレームリレーネットワークで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.
ほとんどのフレームリレーネットワーク内のDLCIはローカルでのみ重要であるため、エンドステーションには特定のDLCIが割り当てられません。したがって、そのようなステーションには、InARP要求または応答に含めるアドレスがありません。さいわい、フレームリレーネットワークは、正しいDLCIを取得する方法を提供します。以下でローカルにアドレス指定されたフレームリレーネットワーク用に提案されたソリューションは、DLCIがグローバルに重要であるネットワークでも同様に機能します。
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.
フレームリレーヘッダー内で伝送されるDLCIは、ネットワークを通過するときに変更されます。パケットが宛先に到着したとき、DLCIは、受信ステーションの観点から、送信ステーションに対応する値に設定されています。たとえば、下の図1で、ステーションAがステーションBにメッセージを送信する場合、フレームリレーヘッダーにDLCI 50を配置します。ただし、ステーションBがこのメッセージを受信すると、DLCIはネットワークによって変更され、BにはDLCI 70として表示されます。
~~~~~~~~~~~~~~~
( )
+-----+ ( ) +-----+
| |-50------(--------------------)---------70-| |
| A | ( ) | B |
| |-60-----(---------+ ) | |
+-----+ ( | ) +-----+
( | )
( | ) <---Frame Relay
~~~~~~~~~~~~~~~~ network
80
|
+-----+
| |
| C |
| |
+-----+
Figure 1
図1
Lines between stations represent data link connections (DLCs). The numbers indicate the local DLCI associated with each connection.
ステーション間の線は、データリンク接続（DLC）を表します。番号は、各接続に関連付けられているローカルDLCIを示します。
DLCI to Q.922 Address Table for Figure 1
DLCIから図1のQ.922アドレステーブル
DLCI (decimal) Q.922 address (hex) 50 0x0C21 60 0x0CC1 70 0x1061 80 0x1401
DLCI（10進数）Q.922アドレス（16進数）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:
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|
+--------------+----+----+---+--+
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メッセージが宛先に到達すると、すべてのハードウェアアドレスが無効になります。ただし、フレームヘッダーにあるアドレスは正しいです。レイヤリングの純粋さには違反しますが、フレームリレーはヘッダーのアドレスを送信側ハードウェアアドレスとして使用する場合があります。また、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を使用して、DLCI 50に関連付けられたステーションのプロトコルアドレスを検出できます。InverseARP要求は次のようになります。
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からのInARPリクエスト（DLCI 50）ar $ op 8（InARPリクエスト）ar $ sha不明ar $ spa pA ar $ tha 0x0C21（DLCI 50）ar $ tpa不明
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がこのパケットを受信すると、フレームリレーヘッダーのQ.922アドレスで送信元ハードウェアアドレスを変更します。このようにして、AからのInARP要求は次のようになります。
ar$op 8 (InARP request) ar$sha 0x1061 (DLCI 70) ar$spa pA ar$tha 0x0C21 (DLCI 50) ar$tpa unknown.
ar $ op 8（InARPリクエスト）ar $ sha 0x1061（DLCI 70）ar $ spa pA ar $ tha 0x0C21（DLCI 50）ar $ tpa不明。
Station B will format an Inverse ARP response and send it to station A:
ステーションBは逆ARP応答をフォーマットし、ステーションAに送信します。
ar$op 9 (InARP response) ar$sha unknown ar$spa pB ar$tha 0x1061 (DLCI 70) ar$tpa pA
ar $ op 9（InARP応答）ar $ sha不明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:
送信元ハードウェアアドレスは不明であり、応答を受信すると、ステーションAはフレームリレーヘッダーからアドレスを抽出し、送信元ハードウェアアドレスフィールドに配置します。したがって、応答は次のようになります。
ar$op 9 (InARP response) ar$sha 0x0C21 (DLCI 50) ar$spa pB ar$tha 0x1061 (DLCI 70) ar$tpa pA
ar $ op 9（InARP応答）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.
また、フレームリレーでARP [1]およびRARP [4]を使用するための同様の手順については、[3]を参照してください。
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ファミリに追加のセキュリティメカニズムは追加されていません。
[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] Plummer、D.、「イーサネットアドレス解決プロトコル-または-ネットワークプロトコルアドレスを48ビットイーサネットアドレスに変換してイーサネットハードウェアで送信する」、STD 37、RFC 826、1982年11月。
[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.
[3] Bradley、T.、Brown、C。、およびA. Malis、「Multiprotocol Interconnect over Frame Relay」、RFC 1490、1993年7月。
[4] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, June 1984.
[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.
[5] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] Information technology - Telecommunications and Information Exchange between systems - Protocol Identification in the Network Layer, ISO/IEC TR 9577: 1992.
[6] 情報技術-システム間のテレコミュニケーションと情報交換-ネットワーク層のプロトコル識別、ISO / IEC TR 9577：1992。
Terry Bradley Avici Systems, Inc. 12 Elizabeth Drive Chelmsford, MA 01824
Terry Bradley Avici Systems、Inc. 12 Elizabeth Drive Chelmsford、MA 01824
Phone: (978) 250-3344 EMail: tbradley@avici.com
電話：（978）250-3344メール：tbradley@avici.com
Caralyn Brown Consultant
カラリンブラウンコンサルタント
EMail: cbrown@juno.com
Andrew Malis Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886
Andrew Malis Ascend Communications、Inc. 1 Robbins Road Westford、MA 01886
Phone: (978) 952-7414 EMail: malis@ascend.com
電話：（978）952-7414メール：malis@ascend.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。