RFC3378 日本語訳
3378 EtherIP: Tunneling Ethernet Frames in IP Datagrams. R. Housley,S. Hollenbeck. September 2002. (Format: TXT=18803 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Housley
Request for Comments: 3378 RSA Laboratories
Category: Informational S. Hollenbeck
VeriSign, Inc.
September 2002
Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3378年のRSA研究所カテゴリ: 情報のS.HollenbeckベリサインInc.2002年9月
EtherIP: Tunneling Ethernet Frames in IP Datagrams
EtherIP: IPデータグラムでイーサネットフレームにトンネルを堀ります。
Status of this Memo
この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は、非IPトラフィックがIPインターネットを横断できるように、IPデータグラムでイーサネットとIEEE802.3メディアアクセス制御フレームにトンネルを堀ります。 プロトコルは非常に軽量です、そして、それは無限ループに対する保護を提供しません。
1. Introduction
1. 序論
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 Layer Two TunnelingプロトコルExtensions(L2TPEXT)作業部会と斜めに進むIETF Pseudo Wire Emulation Edge(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]とIEEE802.3[CSMA/CD]メディアアクセス制御(MAC)フレーム(IEEE 802.1Q[VLAN]データグラムを含んでいる)に使用されます。 MACフレームで運ばれた層threeのプロトコルがIPか暗号化がいつ3プロトコル制御情報がルーティングに必要とした層を見えなくするかということでないときに、通常、トンネリングは実行されます。 EtherIPがその単一のステーションにトンネルを堀りながら、可能にする端のステーションで実装されるかもしれませんか、またはそれは特定のローカル・エリア・ネットワーク(LAN)セグメントにつなげられた複数のステーションにトンネルを堀りながら、可能にするブリッジのようなステーションで実装されるかもしれません。
Housley & Hollenbeck Informational [Page 1] RFC 3378 EtherIP September 2002
[1ページ]RFC3378EtherIP2002年9月の情報のHousley&Hollenbeck
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は、IP以外の層threeのプロトコルでイーサネットを実装するステーションかIEEE802.3のコミュニケーションを可能にするのに使用されるかもしれません。 例えば、ゼロックスNetwork Systems Internetworkデータグラムプロトコル(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は、イーサネットを暗号化するステーションかIEEE802.3ペイロードのコミュニケーションを可能にするのに使用されるかもしれません。 3プロトコルが使用した層にかかわらず、ルーティングを不可能にして、暗号化は層threeのプロトコル制御情報をあいまいにします。 例えば、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は、イーサネットかIEEE802.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に役立つステーションのようにローカルアイピールータに伝えられます。 たいてい、これらの処理規則はソースアドレス、送付先アドレス、またはEtherTypeに基づいています。 同じMACフレームがいくつかのブリッジのようなステーションの間に際限なく送られないのを保証するためにこれらの規則を確立する際に注意しなければなりません、特に放送かマルチキャスト送付先MACアドレスが選択評価基準として使用されるとき。 トポロジーが木に制限されないなら、無限ループは結果として生じることができますが、木の工事はブリッジのようなステーションを構成している人間に任せます。
1.1. Conventions Used In This Document
1.1. 本書では使用されるコンベンション
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Housley & Hollenbeck Informational [Page 2] RFC 3378 EtherIP September 2002
[2ページ]RFC3378EtherIP2002年9月の情報のHousley&Hollenbeck
2. Protocol Format
2. プロトコル形式
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ビットの分野を定義します。 97小数(141 8進、61十六進法)にEtherIPデータグラムを特定するようにこの分野の値を設定しなければなりません。
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ビットのヘッダーとすぐにIP野原の後をつける可変長のカプセル化されたイーサネットかIEEE802.3フレームを含んでいます。
+-----------------------+-----------------------------+
| | | |
| IP | EtherIP Header | Encapsulated Ethernet Frame |
| | | |
+-----------------------+-----------------------------+
+-----------------------+-----------------------------+ | | | | | IP| EtherIPヘッダー| イーサネットフレームであるとカプセル化されます。| | | | | +-----------------------+-----------------------------+
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つの部品から成ります: EtherIPプロトコルバージョンを特定する4ビットのバージョン分野と今後の使用のために予約された12ビットの分野。 'バージョン分野の値は3でなければなりません(3、0011年の'バイナリー)。 予約された分野の値は0でなければなりません(ゼロ)。 このプロトコルの以前のバージョンは8ビットのヘッダーフィールドを使用しました。 ゼロックスイーサネットTunnel(XET)は8ビットのヘッダーを雇いました。 16ビットのヘッダーフィールドはメモリ整列利点をいくつかの実装環境に提供します。
In summary, the EtherIP Header has two fields:
概要では、EtherIP Headerは2つの分野を持っています:
Bits 0-3: Protocol version
Bits 4-15: Reserved for future use
ビット0-3: バージョンBits4-15について議定書の中で述べてください: 今後の使用のために、予約されます。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | |
| VERSION | RESERVED |
| | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | | バージョン| 予約されます。| | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 2: EtherIP Header Format (in bits)
図2: EtherIPヘッダー形式(ビットの)
Housley & Hollenbeck Informational [Page 3] RFC 3378 EtherIP September 2002
[3ページ]RFC3378EtherIP2002年9月の情報のHousley&Hollenbeck
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.
カプセル化されたイーサネットフレーム分野が完全なイーサネットを含んでいるか、またはIEEE802.3はフレームチェックシーケンス(FCS)が評価する以下をどんなタイプにも縁どっています。 IPチェックサムがイーサネット/IEEE802.3フレームのための保全保護を前提としないので、イーサネット/IEEE802.3フレームによってカプセル化された何らかの上位層プロトコルが保全保護を提供すると予想されます。
3. Sending Procedures
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.
このセクションは、EtherIPデータグラムでイーサネットかIEEE802.3MACフレームをカプセル化するために処理について説明します。 まず最初に、実装は、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につなげられるなら、トンネリングは必要ではありません。 ステーションをつなげるネットワークが層threeのプロトコルを発送できるなら、トンネリングは必要ではありません。 また、他の環境の特定の評価基準は適用されるかもしれません。 トンネリングは必要でないなら、すべての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. MACフレームへの16ビットのEtherIPヘッダーのPrepend。 3(3)にEtherIPバージョン分野を設定しなければなりません、そして、0(ゼロ)にEtherIP Reserved分野を設定しなければなりません。 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アドレスから決定しています。
Housley & Hollenbeck Informational [Page 4] RFC 3378 EtherIP September 2002
[4ページ]RFC3378EtherIP2002年9月の情報のHousley&Hollenbeck
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. 97へのセットが(小数)であったに違いないなら目的地があるIPデータグラムのEtherIPデータグラムが前のステップで決定しているIPアドレスと、IPv4プロトコル分野であるとカプセル化してください。
4. Transmit the resulting IP datagram to the remote EtherIP station
via the IP router serving the LAN.
4. LANに役立って、IPルータで結果として起こるIPデータグラムを遠く離れたEtherIPステーションに送ってください。
4. Receiving Procedures
4. 手順を受けます。
This section describes the processing to decapsulate an Ethernet or IEEE 802.3 MAC frame from an EtherIP datagram.
このセクションはイーサネットかIEEE802.3MACがEtherIPデータグラムから縁どるdecapsulateに処理について説明します。
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フレームのすべてを聞くので、それは、IPが被膜剥離術の候補であるMACフレームからそれに扱われたデータグラムであるとカプセル化する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につなげられるなら、フレームを無視してください。 ほとんどの環境で、IPルータ以外のソースMACアドレスがLANに役立っているフレームは無視されます。
3. If the network connecting the stations can route the layer three
protocol, then decapsulation is not needed, and the frame is
ignored.
3. ステーションをつなげるネットワークが層threeのプロトコルを発送できるなら、被膜剥離術は必要ではありません、そして、フレームは無視されます。
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)であり、Reserved分野の値が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値を含んではいけないことに注意してください。
Housley & Hollenbeck Informational [Page 5] RFC 3378 EtherIP September 2002
[5ページ]RFC3378EtherIP2002年9月の情報のHousley&Hollenbeck
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 MUST。
5. IANA Considerations
5. IANA問題
IANA has assigned IP protocol value 97 (decimal) for EtherIP. No further action or review is required.
IANAはEtherIPのためにIPプロトコル価値97の(小数)を割り当てました。 どんなさらなる動作もレビューも必要ではありません。
6. Security Considerations
6. セキュリティ問題
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.
暗号化されたイーサネットかIEEE802.3フレームペイロードの転送を可能にするのにEtherIPを使用できます。 この点で、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の追加は追加担保の脅威への特定の環境を暴露することができます。 ノードが異なったイーサネットセグメントに添付されるか、またはスイッチがEtherIPと共にブリッジされるとき、すべて交信しているノードが1個のイーサネットセグメントかスイッチに取り付けられるとき適切であるかもしれない仮定はもう成立しないかもしれません。 この仕様の範囲の外にそれはあります。範囲は、イーサネットトンネリングの危険を完全に分析して、見直すために既存の習慣を記録します。 作業部会がしているIETF Pseudo-ワイヤEmulationはこの領域で働いています、そして、このグループがIPドキュメントの上の特定のイーサネットと同様に一般的なレイヤリングの情報を提供すると予想されます。 例は関心を明らかにするべきです。 交信ノードによって同じローカル・エリア・ネットワークに関連づけられると予想されるとき、多くのIETF規格が比較的弱いセキュリティー対策を使います。 Virtual Router Redundancyプロトコル[RFC2338]は1つのインスタンスです。 比較的弱いセキュリティー対策は見習われたイーサネットにおける、よりすばらしい脆弱性を表します。 1つのソリューションはIPsec[RFC2401]と共にEtherIPを運ぶIPデータグラムを保護することです。
The IETF Pseudo-wire Emulation Working Group may document other security mechanisms as well.
IETF Pseudo-ワイヤEmulation作業部会はまた、他のセキュリティー対策を記録するかもしれません。
Housley & Hollenbeck Informational [Page 6] RFC 3378 EtherIP September 2002
[6ページ]RFC3378EtherIP2002年9月の情報のHousley&Hollenbeck
7. Acknowledgements
7. 承認
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年にゼロックスSpecial情報システムによって元々、設計されて、実装されたプロトコルについて説明します。 ゼロックスイーサネットTunnel(XET)の一部としてプロトコルの以前のバージョンを提供しました。
8. References
8. 参照
[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 Std802.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.
[DIX]ディジタルイクイップメント社、インテル社、およびゼロックス社: 「イーサネット--ローカル・エリア・ネットワーク:、」 1982年11月に「データ・リンク層と身体検査は(バージョン2.0)を層にします」。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、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.とウィーバーとD.とホイップルとD.とHindenとR.とMitzelとD.と狩りとP.とヒギンソンとP.とシャンドとM.とA.Lindem、「仮想のルータ冗長プロトコル」、RFC2338、1998年4月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[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/男性セキュリティ(SILS)の安全なデータ交換(SDE)(第2節)」、IEEE Std 802.10b-1992、1992。
[XNS] Xerox Corporation: "Internet Transport Protocols", XSIS
028112, December 1981.
[XNS]ゼロックス社: 「インターネットトランスポート・プロトコル」、XSIS028112、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。
Housley & Hollenbeck Informational [Page 7] RFC 3378 EtherIP September 2002
[7ページ]RFC3378EtherIP2002年9月の情報のHousley&Hollenbeck
9. Authors' Addresses
9. 作者のアドレス
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousley RSA研究所918は小山Driveヴァージニア20170ハーンドン(米国)を跳ばせます。
EMail: rhousley@rsasecurity.com
メール: rhousley@rsasecurity.com
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
スコットHollenbeckベリサインInc.21345屋根の頂円のヴァージニア20166-6503ダレス(米国)
EMail: shollenbeck@verisign.com
メール: shollenbeck@verisign.com
Housley & Hollenbeck Informational [Page 8] RFC 3378 EtherIP September 2002
[8ページ]RFC3378EtherIP2002年9月の情報のHousley&Hollenbeck
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Housley & Hollenbeck Informational [Page 9]
Housley&Hollenbeck情報です。[9ページ]
一覧
スポンサーリンク
