[要約] RFC 3378は、EtherIPと呼ばれるプロトコルに関するもので、EthernetフレームをIPデータグラムにトンネリングするための仕様を提供しています。このRFCの目的は、異なるネットワーク間でEthernetフレームを転送するための効果的な方法を提供することです。
Network Working Group R. Housley
Request for Comments: 3378 RSA Laboratories
Category: Informational S. Hollenbeck
VeriSign, Inc.
September 2002
EtherIP: Tunneling Ethernet Frames in IP Datagrams
etherip：IPデータグラムのイーサネットフレームをトンネリングします
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティに関する情報を提供します。インターネット規格はあらゆる種類の標準を指定していません。このメモの分布は無制限です。
Abstract
概要
This document describes the EtherIP, an early tunneling protocol, to provide informational and historical context for the assignment of IP protocol 97. EtherIP tunnels Ethernet and IEEE 802.3 media access control frames in IP datagrams so that non-IP traffic can traverse an IP internet. The protocol is very lightweight, and it does not provide protection against infinite loops.
この文書では、IPプロトコル97の割り当てのための情報と履歴コンテキストを提供するためのEtherip、早期トンネリングプロトコルについて説明します。プロトコルは非常に軽量で、無限ループに対する保護はありません。
EtherIP was first designed and developed in 1991. This document was written to document the protocol for informational purposes and to provide historical context for the assignment of IP protocol 97 by IANA.
Etheripは1991年に最初に設計され開発されました。この文書は、情報提供のためのプロトコルを文書化し、IANAによってIPプロトコル97の割り当てのための歴史的な文脈を提供するために書かれました。
The IETF Layer Two Tunneling Protocol Extensions (L2TPEXT) Working Group and IETF Pseudo Wire Emulation Edge-to-Edge (PWE3) Working Group are developing protocols that overcome the deficiencies of EtherIP. In general, the standards track protocols produced by these IETF working groups should be used instead of EtherIP.
IETFレイヤ2トンネリングプロトコル拡張（L2TPEXT）ワーキンググループおよびIETF疑似ワイヤエミュレーションエッジツーエッジ（PWE3）ワーキンググループは、EtherIPの欠陥を克服するプロトコルを開発しています。一般に、これらのIETFワーキンググループによって生成された標準トラックプロトコルをEtherIPの代わりに使用する必要があります。
The EtherIP protocol is used to tunnel Ethernet [DIX] and IEEE 802.3 [CSMA/CD] media access control (MAC) frames (including IEEE 802.1Q [VLAN] datagrams) across an IP internet. Tunneling is usually performed when the layer three protocol carried in the MAC frames is not IP or when encryption obscures the layer three protocol control information needed for routing. EtherIP may be implemented in an end station to enable tunneling for that single station, or it may be implemented in a bridge-like station to enable tunneling for multiple stations connected to a particular local area network (LAN) segment.
EtherIPプロトコルは、IPインターネット全体のイーサネット[DIX]およびIEEE 802.3 [CSMA / CD]メディアアクセス制御（MAC）フレーム（MAC）フレーム（IEEE 802.1Q [VLAN]データグラムを含む）に使用されます。トンネリングは通常、MACフレーム内で搭載されているレイヤ3プロトコルがIPでない場合、または暗号化がルーティングに必要な3つのプロトコル制御情報を曖昧にした場合に実行されます。Etheripは、その単一ステーションのトンネリングを可能にするためにエンドステーションで実装されてもよく、あるいは、特定のローカルエリアネットワーク（LAN）セグメントに接続された複数のステーションのトンネリングを可能にするためにブリッジ様ステーションで実装されてもよい。
EtherIP may be used to enable communications between stations that implement Ethernet or IEEE 802.3 with a layer three protocol other than IP. For example, two stations connected to different Ethernet LANs using the Xerox Network Systems Internetwork Datagram Protocol (IDP) [XNS] could employ EtherIP to enable communications across the Internet.
EtherIPを使用して、イーサネットまたはIEEE 802.3を実装するステーション間の通信をIP以外のレイヤ3プロトコルで有効にすることができます。たとえば、Xerox Network Systems Internetwork Datagram Protocol（IDP）[XNS]を使用して、異なるイーサネットLANに接続された2つのステーションがEtheripを使用してインターネット全体の通信を可能にします。
EtherIP may be used to enable communications between stations that encrypt the Ethernet or IEEE 802.3 payload. Regardless of the layer three protocol used, encryption obscures the layer three protocol control information, making routing impossible. For example, two stations connected to different Ethernet LANs using IEEE 802.10b [SDE] could employ EtherIP to enable encrypted communications across the Internet.
EtherIPは、イーサネットまたはIEEE 802.3ペイロードを暗号化するステーション間の通信を可能にするために使用されます。使用されるレイヤ3プロトコルに関係なく、暗号化はレイヤ3プロトコル制御情報を隠してルーティングを不可能にします。たとえば、IEEE 802.10b [SDE]を使用して異なるイーサネットLANに接続された2つのステーションは、インターネット全体で暗号化された通信を可能にするためにEtherIPを使用することができます。
EtherIP may be implemented in a single station to provide tunneling of Ethernet or IEEE 802.3 frames for either of the reasons stated above. Such implementations require processing rules to determine which MAC frames to tunnel and which MAC frames to ignore. Most often, these processing rules are based on the destination address or the EtherType.
EtherIPは、上記の理由のいずれかに対してイーサネットまたはIEEE 802.3フレームのトンネリングを提供するために単一のステーションで実装されてもよい。そのような実装は、どのMACフレームをトンネル化し、どのMACフレームを無視するかを決定するための処理規則を必要とする。ほとんどの場合、これらの処理規則は宛先アドレスまたはEtherTypeに基づいています。
EtherIP may be implemented in a bridge-like station to provide tunneling services for all stations connected to a particular LAN segment. Such implementations promiscuously listen to all of the traffic on the LAN segment, then apply processing rules to determine which MAC frames to tunnel and which MAC frames to ignore. MAC frames that require tunneling are encapsulated with EtherIP and IP, then transmitted to the local IP router for delivery to the bridge-like station serving the remote LAN. Most often, these processing rules are based on the source address, the destination address, or the EtherType. Care in establishing these rules must be exercised to ensure that the same MAC frame does not get transmitted endlessly between several bridge-like stations, especially when broadcast or multicast destination MAC addresses are used as selection criteria. Infinite loops can result if the topology is not restricted to a tree, but the construction of the tree is left to the human that is configuring the bridge-like stations.
EtherIPは、特定のLANセグメントに接続されたすべての局にトンネリングサービスを提供するためにブリッジ様ステーションに実装されてもよい。そのような実装は、LANセグメント上のすべてのトラフィックを無差別に聴き、次に処理規則を適用して、どのMACフレームをトンネルするか、どのMACフレームを無視するかを決定する。トンネリングを必要とするMACフレームは、EtherIPおよびIPでカプセル化され、次にリモートLANにサービスを提供するブリッジのような局への配信のためにローカルIPルータに送信されます。ほとんどの場合、これらの処理規則は、送信元アドレス、宛先アドレス、またはEtherTypeに基づいています。特にブロードキャストまたはマルチキャストの宛先MACアドレスが選択基準として使用されている場合、同じMACフレームが複数のブリッジのようなステーション間で際限なく送信されないようにするために、これらの規則を確立するための注意を払う必要があります。トポロジーが木に制限されていないが、無限ループは生じる可能性がありますが、木の建設は橋のようなステーションを構成している人間に残されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「必須」、「必要ではない」、「しない」、「推奨する」、「推奨する」、「5月」、および「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、[RFC2119]に記載されているように解釈されること。
EtherIP segments are sent and received as internet datagrams. An Internet Protocol (IP) header carries several information fields, including an identifier for the next level protocol. An EtherIP header follows the internet header, providing information specific to the EtherIP protocol.
Etheripセグメントはインターネットデータグラムとして送受信されます。インターネットプロトコル（IP）ヘッダは、次のレベルプロトコルの識別子を含むいくつかの情報フィールドを搬送します。Etheripヘッダーがインターネットヘッダーに従い、Etheripプロトコルに固有の情報を提供します。
Internet Protocol version 4 (IPv4) [RFC791] defines an 8-bit field called "Protocol" to identify the next level protocol. The value of this field MUST be set to 97 decimal (141 octal, 61 hex) to identify an EtherIP datagram.
インターネットプロトコルバージョン4（IPv4）[RFC791]は、次のレベルプロトコルを識別するための「プロトコル」という8ビットフィールドを定義します。このフィールドの値は、EtherIPデータグラムを識別するために97 DECIMAL（141 OCTAL、61 HEX）に設定する必要があります。
EtherIP datagrams contain a 16-bit header and a variable-length encapsulated Ethernet or IEEE 802.3 frame that immediately follows IP fields.
Etheripデータグラムには、16ビットのヘッダーと可変長のカプセル化されたイーサネットまたはIEEE 802.3フレームが含まれています。
+-----------------------+-----------------------------+
| | | |
| IP | EtherIP Header | Encapsulated Ethernet Frame |
| | | |
+-----------------------+-----------------------------+
Figure 1: EtherIP Datagram Description
図1：Etheripデータグラムの説明
The 16-bit EtherIP header field consists of two parts: a 4-bit version field that identifies the EtherIP protocol version and a 12-bit field reserved for future use. The value of the version field MUST be 3 (three, '0011' binary). The value of the reserved field MUST be 0 (zero). Earlier versions of this protocol used an 8-bit header field. The Xerox Ethernet Tunnel (XET) employed the 8-bit header. The 16-bit header field provides memory alignment advantages in some implementation environments.
16ビットEtheripヘッダーフィールドは、2つの部分で構成されています。バージョンフィールドの値は3（3、 '0011' '）でなければなりません。予約フィールドの値は0（ゼロ）でなければなりません。このプロトコルの以前のバージョンは8ビットのヘッダーフィールドを使用しました。ゼロックスイーサネットトンネル（XET）は8ビットヘッダーを使用しました。16ビットヘッダーフィールドは、一部の実装環境ではメモリアライメントの利点を提供します。
In summary, the EtherIP Header has two fields:
要約すると、Etheripヘッダーには2つのフィールドがあります。
Bits 0-3: Protocol version Bits 4-15: Reserved for future use
ビット0-3：プロトコルバージョンビット4-15：将来の使用のために予約済み
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | |
| VERSION | RESERVED |
| | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 2: EtherIP Header Format (in bits)
図2：EtherIPヘッダーフォーマット（ビット単位）
The encapsulated Ethernet frame field contains a complete Ethernet or IEEE 802.3 frame of any type less the frame check sequence (FCS) value. The IP checksum does not provide integrity protection for the Ethernet/IEEE 802.3 frame, so some higher-layer protocol encapsulated by the Ethernet/IEEE 802.3 frame is expected to provide the integrity protection.
カプセル化されたイーサネットフレームフィールドは、フレームチェックシーケンス（FCS）値の任意の型の完全なイーサネットまたはIEEE 802.3フレームを含みます。IPチェックサムは、イーサネット/ IEEE 802.3フレームの整合性保護を提供していないため、Ethernet / IEEE 802.3フレームによってカプセル化されているいくつかの上位プロトコルが完全性保護を提供すると予想されます。
This section describes the processing to encapsulate an Ethernet or IEEE 802.3 MAC frame in an EtherIP datagram. First, the implementation determines whether the MAC frame requires tunneling. Then, if tunneling is required, the MAC frame is processed according to the steps provided in this section. Stations processing VLAN datagrams MAY need to examine the VLAN header to make appropriate tunneling decisions.
このセクションでは、EthernetデータグラムのイーサネットまたはIEEE 802.3 MACフレームをカプセル化する処理について説明します。第1に、実装は、MACフレームがトンネリングを必要とするかどうかを決定する。そして、トンネリングが必要な場合は、このセクションで提供されている手順に従ってMACフレームを処理する。ステーションの処理VLANデータグラムは、VLANヘッダーを調べて適切なトンネリングの決定を下す必要があるかもしれません。
An end station that implements EtherIP may tunnel some traffic, but not all traffic. Thus, the first step in processing a MAC frame is to determine if the frame needs to be tunneled or not. If the recipient station is connected to the same LAN as the source station, then tunneling is not needed. If the network connecting the stations can route the layer three protocol, then tunneling is not needed. Other environment specific criteria MAY also be applied. If tunneling is not needed, skip all EtherIP processing and perform normal data link layer processing to transmit the MAC frame. Otherwise, follow the steps described below.
Etheripを実装するエンドステーションは、一部のトラフィックをトンネリングすることがありますが、すべてのトラフィックはトンネットできません。したがって、MACフレームを処理する際の最初のステップは、フレームをトンネリングする必要があるかどうかを判断することである。受信側ステーションがソースステーションと同じLANに接続されている場合は、トンネリングは必要ありません。ステーションを接続するネットワークがレイヤ3プロトコルをルーティングできる場合は、トンネリングは必要ありません。他の環境特有の基準も適用され得る。トンネリングが不要な場合は、すべてのEtherip処理をスキップして、MACフレームを送信するために通常のデータリンクレイヤ処理を実行します。それ以外の場合は、以下の手順に従ってください。
A bridge-like station promiscuously listens to all of the MAC frames on the LAN. Each MAC frame read from the LAN is examined to determine if it needs to be tunneled. If the recipient station is connected to the same LAN as the source station, then tunneling is not needed. If the destination MAC address is a router serving the LAN, then tunneling is not needed. Other environment specific criteria MAY also be applied. If tunneling is not needed, then discard the MAC frame. Otherwise, follow the steps described below.
橋のような駅はLAN上のすべてのMACフレームを無差別に耳を傾ける。LANから読み取られた各MACフレームは、それがトンネリングされる必要があるかどうかを判断するために検査されます。受信側ステーションがソースステーションと同じLANに接続されている場合は、トンネリングは必要ありません。宛先MACアドレスがLANにサービスを提供するルータの場合は、トンネリングは不要です。他の環境特有の基準も適用され得る。トンネリングが不要な場合は、MACフレームを破棄します。それ以外の場合は、以下の手順に従ってください。
The EtherIP encapsulation process is as follows:
Etheripカプセル化プロセスは次のとおりです。
1. Prepend the 16-bit EtherIP header to the MAC frame. The EtherIP Version field MUST be set to 3 (three), and the EtherIP Reserved field MUST be set to 0 (zero). The MAC frame MUST NOT include the FCS.
1. 16ビットEtheripヘッダーをMACフレームに追加します。Etheripバージョンフィールドは3（3）に設定する必要があり、Etherip予約フィールドは0（ゼロ）に設定する必要があります。MACフレームにはFCSを含めてはいけません。
2. Determine the destination IP address of the remote EtherIP station. This address is usually determined from the destination MAC address.
2. リモートEtherIPステーションの宛先IPアドレスを決定します。このアドレスは通常、宛先MACアドレスから決定されます。
3. Encapsulate the EtherIP datagram in an IP datagram with the destination IP address determined in the previous step, and the IPv4 Protocol field MUST be set to 97 (decimal).
3. 前の手順で決定された宛先IPアドレスを使用してIPデータグラムにEtheripデータグラムをカプセル化し、IPv4プロトコルフィールドを97（10進数）に設定する必要があります。
4. Transmit the resulting IP datagram to the remote EtherIP station via the IP router serving the LAN.
4. 結果のIPデータグラムをLANに提供するIPルータを介してリモートのEtheripステーションに送信します。
This section describes the processing to decapsulate an Ethernet or IEEE 802.3 MAC frame from an EtherIP datagram.
このセクションでは、EthernetデータグラムからイーサネットまたはIEEE 802.3 MACフレームをカプセル化する処理について説明します。
Since a bridge-like station promiscuously listens to all of the MAC frames on the LAN, it may need to separate the MAC frames that encapsulate IP datagrams addressed to it from MAC frames that are candidates for decapsulation. The process for identifying MAC frames that are candidates for decapsulation is as follows:
ブリッジのようなステーションはLAN上のすべてのMACフレームを無差別に台無しにしているため、デカプセル化の候補であるMACフレームからアドレス指定されたIPデータグラムをカプセル化するMACフレームを分離する必要があるかもしれません。カプセル化の候補であるMACフレームを識別するプロセスは次のとおりです。
1. Perform normal data link layer processing to receive a suspected EtherIP datagram.
1. 疑わしいEtheripデータグラムを受信するために通常のデータリンク層処理を実行します。
2. If the recipient station is connected to the same LAN as the source station, then ignore the frame. In most environments, frames with a source MAC address other than the IP router serving the LAN are ignored.
2. 受信側ステーションがソースステーションと同じLANに接続されている場合は、フレームを無視してください。ほとんどの環境では、LANを提供するIPルータ以外の送信元MACアドレスを持つフレームは無視されます。
3. If the network connecting the stations can route the layer three protocol, then decapsulation is not needed, and the frame is ignored.
3. 局を接続するネットワークがレイヤ3プロトコルをルーティングすることができれば、カプセル化は不要で、フレームは無視されます。
4. Ignore frames that do not contain an IP datagram.
4. IPデータグラムを含まないフレームを無視します。
5. Examine the IPv4 protocol field to confirm that the value of the field is 97 (decimal). If not, ignore the frame.
5. IPv4プロトコルフィールドを調べて、フィールドの値が97（10進数）であることを確認します。そうでない場合は、フレームを無視してください。
Other environment specific criteria MAY also be applied.
他の環境特有の基準も適用され得る。
Upon reception of an IPv4 datagram with the Protocol field set to 97 (decimal), the MAC frame is processed as follows:
プロトコルフィールドが97（10進数）に設定されたIPv4データグラムを受信すると、MACフレームは次のように処理されます。
1. Examine the 16-bit EtherIP header. Confirm that the value of the version field is 3 (three), and that the value of the Reserved field is 0 (zero). Frames with other values MUST be discarded.
1. 16ビットのEtheripヘッダーを調べます。バージョンフィールドの値が3（3）で、予約フィールドの値が0（ゼロ）であることを確認してください。他の値を持つフレームは破棄されなければなりません。
2. Extract the encapsulated MAC frame from the EtherIP datagram. Note that the extracted frame MUST NOT include a FCS value.
2. Etheripデータグラムからカプセル化されたMACフレームを抽出します。抽出されたフレームはFCS値を含めてはいけません。
3. Perform normal data link layer processing to transmit the extracted MAC frame to the destination station on the LAN. The FCS MUST be calculated and appended to the frame as part of the data link layer transmission processing.
3. 通常のデータリンクレイヤ処理を実行して、抽出したMACフレームをLAN上の宛先ステーションに送信します。FCSは、データリンクレイヤ送信処理の一部として、フレームに計算されて添付されなければならない。
IANA has assigned IP protocol value 97 (decimal) for EtherIP. No further action or review is required.
IANAはEtherIPのIPプロトコル値97（10進数）を割り当てました。それ以上の行動やレビューは必要ありません。
EtherIP can be used to enable the transfer of encrypted Ethernet or IEEE 802.3 frame payloads. In this regard, EtherIP can improve security. However, if a firewall permits EtherIP traffic to pass in and out of a protected enclave, arbitrary communications are enabled. Therefore, if a firewall is configured to permit communication using EtherIP, then additional checking of each frame is probably necessary to ensure that the security policy that the firewall is installed to enforce is not violated.
Etheripは、暗号化されたイーサネットまたはIEEE 802.3フレームペイロードの転送を可能にするために使用できます。これに関して、Etheripはセキュリティを向上させることができます。ただし、ファイアウォールがEtherIPトラフィックが保護されたエンクレーブの出入りを許可する場合は、任意の通信が有効になります。したがって、EtherIPを使用して通信を許可するようにファイアウォールが構成されている場合、ファイアウォールがインストールされているセキュリティポリシーが強制されていないことを確認するためにおそらく追加の各フレームのチェックが必要です。
Further, the addition of EtherIP can expose a particular environment to additional security threats. Assumptions that might be appropriate when all communicating nodes are attached to one Ethernet segment or switch may no longer hold when nodes are attached to different Ethernet segments or switches are bridged together with EtherIP. It is outside the scope of this specification, which documents an existing practice, to fully analyze and review the risks of Ethernet tunneling. The IETF Pseudo-wire Emulation Working Group is doing work in this area, and this group is expected to provide information about general layering as well as specific Ethernet over IP documents. An example should make the concern clear. A number of IETF standards employ relatively weak security mechanisms when communicating nodes are expected to be connected to the same local area network. The Virtual Router Redundancy Protocol [RFC2338] is one instance. The relatively weak security mechanisms represent a greater vulnerability in an emulated Ethernet. One solution is to protect the IP datagrams that carry EtherIP with IPsec [RFC2401].
さらに、Etheripの追加は、特定の環境を追加のセキュリティ上の脅威にさらす可能性があります。すべての通信ノードが1つのイーサネットセグメントまたはスイッチに接続されている場合に適切である可能性がある仮定は、ノードが異なるイーサネットセグメントに接続されているときには、EtherIPと一緒にブリッジされている場合には、適切である可能性があります。これは、既存の慣習を文書化し、イーサネットトンネリングのリスクを完全に分析してレビューすることは、この仕様の範囲外です。 IETF疑似ワイヤエミュレーションワーキンググループはこの分野で作業を行っており、このグループは一般的な階層化に関する情報とIP文書を介した特定のイーサネットに関する情報を提供すると予想されます。例は心配を明確にするべきです。コミュニケーションノードが同じローカルエリアネットワークに接続されると予想される場合、多くのIETF規格が比較的弱いセキュリティメカニズムを使用します。仮想ルータ冗長プロトコル[RFC2338]は1つのインスタンスです。比較的弱いセキュリティメカニズムは、エミュレートされたイーサネットのより大きな脆弱性を表します。 1つの解決策は、EtherIPをIPsec [RFC2401]で持つIPデータグラムを保護することです。
The IETF Pseudo-wire Emulation Working Group may document other security mechanisms as well.
IETF疑似ワイヤエミュレーションワーキンググループは、他のセキュリティメカニズムも文書化できます。
This document describes a protocol that was originally designed and implemented by Xerox Special Information Systems in 1991 and 1992. An earlier version of the protocol was provided as part of the Xerox Ethernet Tunnel (XET).
この文書では、1991年と1992年にXerox特別情報システムによってもともと設計され実装されたプロトコルについて説明します。以前のバージョンのプロトコルは、XERoxイーサネットトンネル（XET）の一部として提供されていました。
[CSMA/CD] Institute of Electrical and Electronics Engineers: "Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", ANSI/IEEE Std 802.3-1985, 1985.
[CSMA / CD]電気電子機器技術研究所：「衝突検出（CSMA / CD）アクセス方法と物理層仕様とのキャリアセンスマルチアクセス」、ANSI / IEEE STD 802.3-1985,1985。
[DIX] Digital Equipment Corporation, Intel Corporation, and Xerox Corporation: "The Ethernet -- A Local Area Network: Data Link Layer and Physical Layer (Version 2.0)", November 1982.
[DIS]デジタル機器株式会社、Intel Corporation、およびXerox Corporation：「イーサネット - ローカルエリアネットワーク：データリンク層と物理層（バージョン2.0）」、1982年11月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J.、「インターネットプロトコル」、STD 5、RFC 791、9月1981日。
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2338] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, D., Hunt, P., Higginson, P., Shand, M. and A. Lindem, "Virtual Router Redundancy Protocol", RFC 2338, April 1998.
[RFC2338]ナイト、S、Weaver、D.、Whipple、D.、Hinden、R.、Mitzel、D.、Hunt、P.、Higginson、P.、Shand、M.およびA. Lindem、 "Virtual Router"冗長性プロトコル「RFC 2338、1998年4月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.およびR.Atkinson、1998年11月、RFC 2401、RFC 2401。
[SDE] Institute of Electrical and Electronics Engineers: "Interoperable LAN/MAN Security (SILS) Secure Data Exchange (SDE) (Clause 2)", IEEE Std 802.10b-1992, 1992.
[SDE]電気および電子機器の技術者研究所：「相互運用可能なLAN / MANセキュリティ（SILS）安全データ交換（SDE）（第2条）」、IEEE STD 802.10B-1992,1992。
[XNS] Xerox Corporation: "Internet Transport Protocols", XSIS 028112, December 1981.
[XNS]ゼロックス株式会社：「インターネット輸送プロトコル」、XSIS 028112、1981年12月。
[VLAN] Institute of Electrical and Electronics Engineers: "IEEE Standard for Local and Metropolitan Area Networks: Virtual Bridge Local Area Networks", ANSI/IEEE Std 802.1Q-1998, 1998.
[VLAN]電気および電子機器技術者研究所：「地方および首都圏ネットワークのIEEE規格：バーチャルブリッジローカルエリアネットワーク」、ANSI / IEEE STD 802.1Q-1998,1998。
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon、VA 20170 USA
EMail: rhousley@rsasecurity.com
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
Scott Hollenbeck Verisign、Inc。21345 Ridgetop Circle Dulles、VA 20166-6503 USA
EMail: shollenbeck@verisign.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（c）インターネット社会（2002）。全著作権所有。
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.
この文書と本明細書に含まれる情報は、「現状」ベースで提供されており、インターネット社会とインターネットエンジニアリングのタスクフォースは、本明細書の情報の使用が含まれないことを含むが、これに限定されない、またはこれに限定されないすべての保証を損なう。特定の目的のための商品性または適合性の権利または黙示的な保証を侵害する。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディタ機能のための資金は、現在インターネット社会によって提供されています。