この文書はRFC3378の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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：ＩＰデータグラム内のトンネルイーサネットフレーム
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.
この文書はEtherIP 、初期のトンネルプロトコル、ＩＰプロトコル９７の割
当ての情報と歴史的内容を提供します。EtherIPトンネルは、イーサネット
とＩＥＥＥ８０２.３メディアアクセスコントロールフレームをＩＰデータ
グラム内にトンネルし、非ＩＰのトラフィックをＩＰインターネット上で転
送できるようにします。プロトコルは非常に軽量で、無限ループに対する保
護を供給しません。
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年に最初の設計と開発がされました。この文書は情報的な目的
のためのプロトコルを文書化して、ＩＡＮＡによって割当てられたＩＰプロ
トコル９７の歴史状況を提供するよう書かれました。
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.
ＩＥＴＦレイヤ２トンネルプロトコル拡張（L2TPEX）ワーキンググループと
ＩＥＴＦ擬似ワイヤエミュレーションエッジエッジ（PWE3）ワーキンググ
ループはEtherIPの欠陥を克服するプロトコルを開発しています。一般に、
これらのＩＥＴＦワーキンググループによって作り出された標準トラックプ
ロトコルは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プロトコルはイーサネット[DIX]とＩＥＥＥ８０２.３[CSMA/CD]メディ
アアクセス制御（ＭＡＣ）フレーム（ＩＥＥＥ８０２.１Q[VLAN]データグラ
ムを含めて）をＩＰインターネット上にトンネルするのに使われます。トン
ネルは、ＭＡＣフレームで運ばれたレイヤ３プロトコルがＩＰでないか、Ｉ
Ｐあるいは暗号化がルーティングに必要なレイヤ３プロトコル制御情報を不
明瞭にしてる場合に、通常使われます。EtherIPは１つの装置のためにその
装置で愁嘆するトンネルを作りかもしれないし、特定のローカルエリア・ネッ
トワーク（ＬＡＮ）セグメントに関係した多数の装置のためにブリッジ装置
でトンネルを作るかもしれません。
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は、イーサネットやＩＥＥＥ８０２.３装置間をＩＰ以外のレイヤ３
プロトコルで通信を可能にするために使われるかもしれません。例えば、ゼ
ロックスネットワークシステムインターネットワークデータグラムプロトコ
ル（ＩＤＰ）[XNS]を使っている異なるイーサネットＬＡＮに接続した２つ
の装置がインターネットを超えて通信を可能にするために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はイーサネットかＩＥＥＥ８０２.３ペイロードを暗号化する装置間
で通信を可能にするために使われるかもしれません。使われたレイヤ３つの
プロトコルにかかわらず、暗号化がルーティングを不可能にし、レイヤ３プ
ロトコル制御情報を不明瞭にします。例えば、ＩＥＥＥ８０２.１０ｂ[SDE]
を使っている異なったイーサネットＬＡＮに接続した２つの装置ステーショ
ンがインターネットを超えて暗号化された通信を可能にするために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は上記の理由のどれかで、イーサネットやＩＥＥＥ８０２.３フレー
ムのトンネルを供給するため、ひとつの装置に実装されるかもしれません。
このような実装は、どのＭＡＣフレームをトンネル化し、どのマックフレー
ムを無視するか決定する処理規則を要求されます。しばしば、これらの処理
規則は宛先アドレスや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はあるＬＡＮに接続するすべての装置にトンネルサービスを供給する
のためにブリッジのような装置に実装されるかもしれません。このような実
装はＬＡＮセグメント上で無差別にトラフィックのすべてを聞き、のＭＡＣ
フレームをトンネル化し、どのマックフレームを無視するか決定する処理規
則を適用します。トンネルを必要とするＭＡＣフレームがEtherIPとＩＰの
カプセルに入れられて、遠隔地のＬＡＮをサポートするブリッジのような装
置に配達するため、ローカルＩＰルーターに送られます。しばしば、これら
の処理規則はソースアドレスや宛先アドレスやEtherTypeに基づいています。
これらの規則を作る際に同じＭＡＣフレームがあるブリッジのような装置間
で際限なく送りあう事がないことを確かにして下さい、特にブロードキャス
トやマルチキャストが宛先ＭＡＣアドレスが選択基準に使われる場合に注意
してください。もしトポロジーツリーに制限がないなら、結果として無限ルー
プを生じることができますが、ツリーの設定はブリッジのような装置を設定
する人に任せられます。
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"と"MUST NOT"と"REQUIRED"と"SHALL"
と"SHALL NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と
"OPTIONAL"は[RFC2119]で記述されるように解釈されるはずです。
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セグメントがインターネットデータグラムとして送受信されます。イ
ンターネット・プロトコル（ＩＰ）ヘッダーが、次のレベルのプロトコルの
識別子を含めて、いくつかの情報フィールドを運びます。インターネットヘッ
ダーに続く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.
インターネット・プロトコルバージョン４（ＩＰｖ４）[RFC791]が次のレベ
ルのプロトコルを識別するために「プロトコル」と呼ばれる８ビットのフィー
ルドを定義します。このフィールドの値はEtherIPデータグラムを識別する
ため１０進数で９７（８進数で１４１、１６進数で６１）に設定されます
(MUST)。
EtherIP datagrams contain a 16-bit header and a variable-length
encapsulated Ethernet or IEEE 802.3 frame that immediately follows IP
fields.
EtherIPデータグラムがＩＰフィールドに続いて１６ビットのヘッダーと可変
長のカプセル化したイーサネットやＩＥＥＥ８０２.３フレームを含みます。
+-----------------------+-----------------------------+
| | | |
| IP | EtherIP Header | Encapsulated Ethernet Frame |
| | | |
+-----------------------+-----------------------------+
Figure 1: EtherIP Datagram Description
図１：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.
１６ビットのEtherIPヘッダーフィールドは２つの部分から成り立ちます：
EtherIPプロトコルバージョンを識別する４ビットのバージョンフィールド
と将来の使用のために確保された１２ビットのフィールド。バージョンフィー
ルドの値は３（３、２進数で「００１１」）に違いありません(MUST)。予約
のフィールドの値は０（ゼロ）に違いありません(MUST)。このプロトコルの
初期のバージョンが８ビットのヘッダーフィールドを使いました。ゼロック
スイーサネットトンネル（XET）は８ビットのヘッダーを使用しました。
１６ビットのヘッダーフィールドはある実行環境でのメモリ整列の利点があ
ります。
In summary, the EtherIP Header has two fields:
まとめるとEtherIPヘッダーは２つのフィールドを持ちます：
Bits 0-3: Protocol version
プロトコルバージョン
Bits 4-15: Reserved for future use
将来の使用のために予約
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)
図２：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）を除き、任意の種類の完全なイーサネットやＩＥＥＥ８０２.３フ
レームを含みます。ＩＰチェックサムはイーサネット／ＩＥＥＥ８０２.３
フレームの完全性保護を提供しないので、それでイーサネット／ＩＥＥＥ
８０２.３フレームによってカプセル化される上位レイヤプロトコルが完全
性保護を供給することを期待されます。
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データグラムにイーサネットやＩＥＥＥ８０２.３のＭＡＣ
フレームをカプセル化する処理を記述します。最初に、実装はＭＡＣフレー
ムをトンネルする必要があるかどうか決定します。もしトンネルが必要なら、
ＭＡＣフレームはこの章で示す手順で処理されます。ＶＬＡＮデータグラム
を処理している装置が適切なトンネルを決定をするためにＶＬＡＮヘッダを
調べる必要があるかもしれません(MAY)。
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を実行するエンド装置があるトラヒックをトンネルするかもしれない
が、すべてのトラフィックではありません。それで、ＭＡＣフレームを処理
する最初のステップはフレームがトンネルする必要があるか決定することで
す。もし受信装置が送信装置と同じＬＡＮに接続しているなら、トンネルを
堀る必要はありません。もし装置の接続したネットワークがレイヤ３プロト
コルの経路決定ができるなら、トンネルは必要ありません。他の環境に依存
した基準が適用されるかもしれません(MAY)。もしトンネルが必要ないなら、
すべてのEtherIP処理を省略し、ＭＡＣフレームを送るための標準的なデータ
リンクレイヤ処理を行ってください。さもなければ、下記の手順に従ってく
ださい。
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.
ブリッジのような装置がＬＡＮ上で無差別にＭＡＣフレームのすべてを見ま
す。ＬＡＮから読み込まれた各ＭＡＣフレームがトンネルが必要か決定する
ために調べられます。もし受信装置が送信装置と同じＬＡＮに接続している
なら、トンネルは必要ありません。もし宛先ＭＡＣアドレスがＬＡＮをサポー
トするルーターなら、トンネルは必要ありません。他の環境に依存した基準
が適用されるかもしれません(MAY)。もしトンネルが必要ないなら、ＭＡＣ
フレームを捨ててください。さもなければ、下記手順に従ってください。
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. ＭＡＣフレームの前に１６ビットのEtherIPヘッダーを付けてください。
EtherIPバージョンフィールドは３を設定し(MUST)、EtherIP予約フィー
ルドは０を設定します(MUST)。ＭＡＣフレームはＦＣＳを含みません
(MUST NOT)。
2. Determine the destination IP address of the remote EtherIP
station. This address is usually determined from the destination
MAC address.
2. 遠隔EtherIP装置の宛先ＩＰアドレスを決定してください。このアドレ
スは通常宛先ＭＡＣアドレスから決定します。
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. 前の手順で決定した宛先ＩＰアドレスのＩＰデータグラムにEtherIPデー
タグラムをカプセル化します、ＩＰｖ４プロトコルフィールドは９７
（１０進数）を設定します(MUST)。
4. Transmit the resulting IP datagram to the remote EtherIP station
via the IP router serving the LAN.
4. ＬＡＮ内のＩＰルータによって遠隔EtherIP装置に作り上げたＩＰデータ
グラムを送ってください。
4. Receiving Procedures
4. 受信手順
This section describes the processing to decapsulate an Ethernet or
IEEE 802.3 MAC frame from an EtherIP datagram.
この章はEtherIPデータグラムからカプセルを解いてイーサネットやＩＥＥＥ
８０２.３のＭＡＣフレームを戻す処理を記述します。
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:
ブリッジのような装置がＬＡＮ上で無差別にＭＡＣフレームのすべてを聞く
ので、自分宛てのＩＰデータグラムをカプセル化したＭＡＣフレームと、カ
プセル解除の候補であるＭＡＣフレームを分離する必要があるかもしれませ
ん。カプセル解除の候補であるＭＡＣフレームを識別する処理は次の通りで
す：
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. もし受信装置が送信装置と同じＬＡＮに接続しているなら、フレームを無
視してください。たいていの環境で、ＬＡＮ上のＩＰルータ以外のソース
ＭＡＣアドレスのフレームが無視されます。
3. If the network connecting the stations can route the layer three
protocol, then decapsulation is not needed, and the frame is
ignored.
3. もし装置が接続してるネットワークがレイヤ３プロトコルの経路決定がで
きるなら、カプセル解除が必要なくフレームは無視されます。
4. Ignore frames that do not contain an IP datagram.
4. ＩＰデータグラムを含まないフレームを無視します。
5. Examine the IPv4 protocol field to confirm that the value of the
field is 97 (decimal). If not, ignore the frame.
5. フィールドの値が９７（１０進数）であることを確認するためにＩＰｖ４
プロトコルフィールドを調べます。もしそうでなければフレームを無視し
ます。
Other environment specific criteria MAY also be applied.
他の環境特有の基準が適用されるかもしれません(MAY)。
Upon reception of an IPv4 datagram with the Protocol field set to 97
(decimal), the MAC frame is processed as follows:
プロトコルフィールドが９７（１０進数）のＩＰｖ４データグラムを受信し
たら、ＭＡＣフレームは次のように処理されます：
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. １６ビットのEtherIPヘッダーを調べます。バージョンフィールドの値が
３であり、予約フィールド値が０であることを確認します。他の値を持
つフレームが捨てられます(MUST)。
2. Extract the encapsulated MAC frame from the EtherIP datagram.
Note that the extracted frame MUST NOT include a FCS value.
2. EtherIPデータグラムからカプセル化されたＭＡＣフレームを抽出します。
引き抜かれたフレームがＦＣＳ値を含まないことに注意してください
(MUST NOT)。
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. 宛先ステーションにＭＡＣフレームを送るため、ＬＡＮ上の標準的なデー
タリンクレイヤ処理を行います。ＦＣＳは計算され、データリンクレイ
ヤ送信処理の一部としてフレームに付け加えなければなりません(MUST)。
5. IANA Considerations
5. ＩＡＮＡの考慮
IANA has assigned IP protocol value 97 (decimal) for EtherIP. No
further action or review is required.
ＩＡＮＡはEtherIPのためにＩＰプロトコル値９７（１０進数）を割り当て
ました。それ以上の行動や再調査は必要ありません。
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.
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でブリッジされるときには適切でないか
もしれません。完全にトンネルイーサネットの危険を分析して再検討するこ
とは、既存の実態を文書化するこの仕様書の範囲外です。ＩＥＴＦ疑似ワイ
ヤエミュレーションワーキンググループはこのエリアにおける仕事をしてい
て、このグループは一般的なレイヤでの情報とＩＰ上のイーサーネット文書
の供給を期待されます。例が懸念を明らかにするべきです。多くのＩＥＴＦ
標準が通信しているノードが同じローカルエリア・ネットワークに接続して
いることを期待される時に比較的弱いセキュリティ機構を使用します。仮想
のルータ冗長プロトコル[RFC2338]は１例です。比較的弱いセキュリティ機構
はエミュレートされたイーサネットで大きい弱点を表します。１つの解決策
がＩＰｓｅｃ［RFC2401］でEtherIPを運ぶＩＰデータグラムを守ることです。
The IETF Pseudo-wire Emulation Working Group may document other
security mechanisms as well.
ＩＥＴＦ疑似ワイヤエミュレーションワーキンググループが同様に他のセ
キュリティ機構を文書化するかもしれません。
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).
この文書は１９９１年と１９９２年に元々ゼロックススペシャルインフォメー
ションシステムによって設計され実装されたプロトコルを記述します。プロ
トコルの初期のバージョンがゼロックスイーサネットトンネル（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.
[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.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[SDE] Institute of Electrical and Electronics Engineers:
"Interoperable LAN/MAN Security (SILS) Secure Data Exchange
(SDE) (Clause 2)", IEEE Std 802.10b-1992, 1992.
[XNS] Xerox Corporation: "Internet Transport Protocols", XSIS
028112, December 1981.
[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.
9. Authors' Addresses
9. 著者のアドレス
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
EMail: shollenbeck@verisign.com
10. Full Copyright Statement
10. 著作権表示全文
Copyright (C) The Internet Society (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.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。