RFC1241 日本語訳
1241 Scheme for an internet encapsulation protocol: Version 1. R.A.Woodburn, D.L. Mills. July 1991. (Format: TXT=42468, PS=128921, PDF=44593 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Woodburn
Request for Comments: 1241 SAIC
D. Mills
University of Delaware
July 1991
Woodburnがコメントのために要求するワーキンググループR.をネットワークでつないでください: 1241SAIC D.はデラウエア大学1991年7月にかけめぐります。
A Scheme for an Internet Encapsulation Protocol:
Version 1
インターネットカプセル化プロトコルの計画: バージョン1
1. Status of this Memo
1. このMemoの状態
This memo defines an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
2. Glossary
2. 用語集
Clear Datagram -
The unmodified IP datagram in the User Space before
Encapsulation.
データグラムをクリアしてください--Encapsulationの前のUser Spaceの変更されていないIPデータグラム。
Clear Header -
The header portion of the Clear Datagram before
Encapsulation. This header includes the IP header and
possibly part or all of the next layer protocol header,
i.e., the TCP header.
Headerをきれいにしてください--Encapsulationの前のClearデータグラムのヘッダー部分。 このヘッダーは次の層のプロトコルヘッダー(すなわち、TCPヘッダー)のIPヘッダーとことによると部分かすべてを入れます。
Decapsulation -
The stripping of the Encapsulation Header and forwarding
of the Clear Datagram by the Decapsulator.
被膜剥離術--Encapsulation HeaderのストリップとDecapsulatorによるClearデータグラムの推進。
Decapsulator -
The entity responsible for receiving an Encapsulated
Datagram, decapsulating it, and delivering it to the
destination User Space. Delivery may be direct, or via
Encapsulation. A Decapsulator may be a host or a gateway.
Decapsulator--それをdecapsulatingして、Encapsulatedデータグラムを受けるのに原因となって、目的地User Spaceにそれを渡している実体。 ダイレクトにかEncapsulationを通して配送があるかもしれません。 Decapsulatorはホストかゲートウェイであるかもしれません。
Encapsulated Datagram -
The datagram consisting of a Clear Datagram prepended with
an Encapsulation Header.
要約のデータグラム--Clearデータグラムから成るデータグラムはEncapsulation Headerと共にprependedされました。
Encapsulation -
The process of mapping a Clear Datagram to the
Encapsulation Space, prepending an Encapsulation Header to
the Clear Datagram and routing the Encapsulated Datagram
カプセル化--ClearデータグラムとEncapsulatedデータグラムを発送することへのEncapsulation Headerをprependingして、ClearデータグラムをEncapsulation Spaceに写像する過程
Woodburn & Mills [Page 1] RFC 1241 Internet Encapsulation July 1991
Woodburnと工場[1ページ]RFC1241インターネットカプセル化1991年7月
to a Decapsulator.
Decapsulatorに。
Encapsulation Header -
The header for the Encapsulation Protocol prepended to the
Clear Datagram during Encapsulation. This header consists
of an IP header followed by an Encapsulation Protocol
Header.
カプセル化Header--EncapsulationプロトコルのためのヘッダーはEncapsulationの間、Clearデータグラムにprependedしました。 このヘッダーはEncapsulationプロトコルHeaderによって続かれたIPヘッダーから成ります。
Encapsulation Protocol Header -
The Encapsulation Protocol specific portion of the
Encapsulation Header.
カプセル化プロトコルHeader--Encapsulation HeaderのEncapsulationプロトコル特定部位。
Encapsulation Space -
The address and routing space within which the
Encapsulators and Decapsulators reside. Routing within
this space is accomplished via Flows. Encapsulation
Spaces do not overlap, that is, the address of any
Encapsulator or Decapsulator is unique for all
Encapsulation Spaces.
カプセル化Space--EncapsulatorsとDecapsulatorsが住んでいるアドレスとルーティングスペース。 このスペースの中のルート設定はFlowsを通して実行されます。 カプセル化Spacesは重なりません、すなわち、すべてのEncapsulation Spacesに、どんなEncapsulatorやDecapsulatorのアドレスもユニークです。
Encapsulator -
The entity responsible for mapping a given User Space
datagram to the Encapsulation Space, encapsulating the
datagram, and forwarding the Encapsulated Datagram to a
Decapsulator. An Encapsulator may be a host or a gateway.
Encapsulator--データグラムを要約して、与えられたUser SpaceデータグラムをEncapsulation Spaceに写像するのに原因となる実体と、EncapsulatedデータグラムをDecapsulatorに送ること。 Encapsulatorはホストかゲートウェイであるかもしれません。
Flow -
Also called a "tunnel." A flow is the end-to-end path in
the Encapsulation Space over which Encapsulated Datagrams
travel. There may be several Encapsulator/Decapsulator
pairs along a given flow. Note that a Flow does not
denote what User Space gateways are traversed along the
path.
流れてください--また、「トンネル」と呼ばれます。 流れは終わりから端へのEncapsulatedデータグラムが移動するEncapsulation Spaceの経路です。 与えられた流れに沿って数個のEncapsulator/Decapsulator組があるかもしれません。 Flowが、User Spaceゲートウェイが経路に沿って横断されるものであることを指示しないことに注意してください。
Flow ID -
A 32-bit identifier which uniquely distinguishes a flow in
a given Encapsulator or Decapsulator. Flow IDs are
specific to a single Encapsulator/Decapsulator Entity and
are not global quantities.
流れID--唯一与えられたEncapsulatorかDecapsulatorの流れを区別する32ビットの識別子。 流れIDは、独身のEncapsulator/Decapsulator Entityに特定であり、グローバルな量ではありません。
Mapping Function -
This is the function of mapping a Clear Header to a
particular Flow. All encapsulators along a given Flow are
required to map a given Clear Header to the same Flow.
Functionを写像します--これは特定のFlowにClear Headerを写像する機能です。 与えられたFlowに沿ったすべてのencapsulatorsが、与えられたClear Headerを同じFlowに写像するのに必要です。
User Address -
The address or identifier uniquely identifying an entity
within a User Space.
ユーザAddress--User Spaceの中で唯一実体を特定するアドレスか識別子。
Woodburn & Mills [Page 2] RFC 1241 Internet Encapsulation July 1991
Woodburnと工場[2ページ]RFC1241インターネットカプセル化1991年7月
Source Route -
A complete end-to-end route which is computed at the
source and enumerates transit gateways.
ソースRoute--終わりから終わりへのソースで計算されて、トランジットゲートウェイを数え上げる完全なルート。
User Space -
The address and routing space within which the users
reside. Routing within this space provides reachability
between all address pairs within the space. User Spaces
do not overlap, that is, a given User Address is unique in
all User Spaces.
ユーザSpace--ユーザが住んでいるアドレスとルーティングスペース。 このスペースの中のルート設定はスペースの中ですべてのアドレス組の間に可到達性を提供します。 ユーザSpacesは重なりません、すなわち、与えられたUser AddressがすべてのUser Spacesでユニークです。
3. Background
3. バックグラウンド
For several years researchers in the Internet community have needed a means of "tunneling" between networks. A tunnel is essentially a Source Route that circumvents conventional routing mechanisms. Tunnels provide the means to bypass routing failures, avoid broken gateways and routing domains, or establish deterministic paths for experimentation.
数年間、インターネットコミュニティの研究者はネットワークの間で「トンネル」である手段を必要としています。 トンネルは本質的には従来のルーティングメカニズムを回避するSource Routeです。トンネルは、実験のためにルーティング失敗を迂回させる手段を提供するか、壊れているゲートウェイと経路ドメインを避けるか、または決定論的な経路を確立します。
There are several means of accomplishing tunneling. In the past, tunneling has been accomplished through source routing options in the IP header which allow gateways along a given path to be enumerated. The disadvantage of source routing in the IP header is that it requires the source to know something about the networks traversed to reach the destination. The source must then modify outgoing packets to reflect the source route. Current routing implementations generally don't support source routes in their routing tables as a means of reaching an IP address, nor do current routing protocols.
トンネリングを達成するいくつかの手段があります。 過去に、トンネリングはIPヘッダーの与えられた経路に沿ったゲートウェイが数え上げられるのを許容するソースルーティングオプションで達成されました。 IPヘッダーのソースルーティングの不都合は目的地に達するように横断されたネットワークに関して何かを知るのがソースを必要とするということです。 そして、ソースは、送信元経路を反映するように出発しているパケットを変更しなければなりません。 一般に、現在のルーティング実現は、IPアドレスに達する手段としてそれらの経路指定テーブルの送信元経路を支えて、現在のルーティング・プロトコルをしません。
Another means of tunneling would be to develop a new IP option. This option field would be part of a separate IP header that could be prepended to an IP datagram. The IP option would indicate information about the original datagram. This tunneling option has the disadvantage of significantly modifying existing IP implementations to handle a new IP option. It also would be less flexible in permitting the tunneling of other protocols, such as ISO protocols, through an IP environment. An even less palatable alternative would be to replace IP with a new networking protocol or a new version of IP with tunneling built in as part of its functionality.
トンネリングの別の手段は新しいIPオプションを開発するだろうことです。 このオプション・フィールドはIPデータグラムにprependedされることができた別々のIPヘッダーの一部でしょう。 IPオプションはオリジナルのデータグラムの情報を示すでしょう。 このトンネリングオプションには、新しいIPオプションを扱うように既存のIP実現をかなり変更する不都合があります。 また、それも他のプロトコルのトンネリングを可能にするのにおいてそれほどフレキシブルでないでしょう、ISOプロトコルなどのように、IP環境を通して。 それほどおいしくない代替手段さえ中に新しいネットワーク・プロトコルかトンネリングが築き上げられているIPの新しいバージョンがある状態で機能性の一部としてIPに取って代わるだろうことです。
A final alternative is to create a new IP encapsulation protocol which uses the current IP header format. By using encapsulation, a destination can be reached transparently without the source having to know topology specifics. Virtual networks can be created by tying otherwise unconnected machines together with flows through an encapsulation space.
最終的な代替手段は現在のIPヘッダー形式を使用する新しいIPカプセル化プロトコルを作成することです。 カプセル化を使用することによって、目的地にトポロジー詳細を知らなければならない情報筋なしで透明に達することができます。 流れと共にカプセル化スペースを通してそうでなければ、無関係のマシンを接続することによって、仮想ネットワークを創設できます。
Woodburn & Mills [Page 3] RFC 1241 Internet Encapsulation July 1991
Woodburnと工場[3ページ]RFC1241インターネットカプセル化1991年7月
++++++ Clear Datagram
****** Encapsulated
Datagram
#
Encapsulator/Decapsulator
& User Space Host
+ + + + + + 明確なデータグラム******要約のデータグラム#Encapsulator/Decapsulatorとユーザ宇宙ホスト
User Space A User Space C
ユーザスペースはユーザスペースCです。
-------------- -----------
/ \ / \
/ \ / \
| | | |
| & | | |
| + +++++ | | ***** |
| +++++ + | | * * |
| + | | ***** * |
\ + / ----------- \ * * / ----------
\ ++> # * **> # * ***> # ++++ \
-------------- / * * \ ------------ / + \
| * * | | + |
| * * | | + |
| ***** * | | +++++++ |
| ***** | | V |
| | | & |
\ / \ /
\ / \ /
----------- ----------
Encapsulation User
Space B Space D
-------------- ----------- / \ / \ / \ / \ | | | | | & | | | | + +++++ | | ***** | | +++++ + | | * * | | + | | ***** * | \ + / ----------- \ * * / ---------- \++>#***>#****>#++++\-------------- / * * \ ------------ / + \ | * * | | + | | * * | | + | | ***** * | | +++++++ | | ***** | | V| | | | & | \ / \ / \ / \ / ----------- ---------- カプセル化ユーザスペースBスペースD
Fig. 1. Encapsulation Architectural Model
図1。 カプセル化の建築モデル
Up until now, there has been no standard for an encapsulation protocol. This RFC provides a means of performing encapsulation in the Internet environment.
現在まで、カプセル化プロトコルの規格が全くありませんでした。 このRFCはカプセル化を実行する手段をインターネット環境に提供します。
4. Architecture and Approach
4. 構造とアプローチ
The architecture for encapsulation is based on two entities -- an Encapsulator and a Decapsulator. These entities and the associated spaces are shown in Fig. 1.
カプセル化のための構造は2つの実体に基づいています--EncapsulatorとDecapsulator。 これらの実体と関連空間は図1に示されます。
Encapsulators and Decapsulators have addresses in the User Spaces to which they belong, as well as addresses in the Encapsulation Spaces to which they belong. An encapsulator will receive a Clear Datagram
EncapsulatorsとDecapsulatorsは彼らが属するUser Spacesにアドレスを持っています、彼らが属するEncapsulation Spacesのアドレスと同様に。 encapsulatorはClearデータグラムを受けるでしょう。
Woodburn & Mills [Page 4] RFC 1241 Internet Encapsulation July 1991
Woodburnと工場[4ページ]RFC1241インターネットカプセル化1991年7月
from its User Space, and after determining that encapsulation should be used, perform a mapping function which translates the User Space information in the Clear Header to an Encapsulation Header. This Encapsulation Header is then prepended to the Clear Datagram to form the Encapsulated Datagram, as in Fig 2. It is desirable that the encapsulation process be transparent to entities in the User Space. Only the Encapsulator need know that encapsulation is occurring.
User Spaceと、カプセル化が使用されるべきであることを決定した後に、Clear HeaderのUser Space情報をEncapsulation Headerに翻訳するマッピング機能を実行してください。 そして、このEncapsulation Headerは、Encapsulatedデータグラムを形成するために図2のようにClearデータグラムにprependedされます。 カプセル化の過程がUser Spaceの実体に見え透いているのは、望ましいです。 Encapsulatorだけが、カプセル化が起こっているのを知らなければなりません。
+---------------+-----------------+--------+----------------+
| Encapsulating | Encapsulation | Clear | Remainder of |
| IP Header | Protocol Header | Header | Clear Datagram |
+---------------+-----------------+--------+----------------+
+---------------+-----------------+--------+----------------+ | 要約します。| カプセル化| クリアしてください。| 残り| | IPヘッダー| プロトコルヘッダー| ヘッダー| 明確なデータグラム| +---------------+-----------------+--------+----------------+
| | |
| Encapsulation Header | Clear Datagram |
| | |
| | | | カプセル化ヘッダー| 明確なデータグラム| | | |
Fig. 2. Example of an Encapsulated Datagram
図2。 要約のデータグラムに関する例
The Encapsulator forwards the datagram to a Decapsulator whose identity is determined at the time of encapsulation. The Decapsulator receives the Encapsulated Datagram and removes the Encapsulation Header and treats the Clear Datagram as if it were received locally. The requirement for the address of the Decapsulator is that it be reachable from the Encapsulator's Encapsulation Space address.
Encapsulatorはアイデンティティがカプセル化時点で決定しているDecapsulatorにデータグラムを送ります。 Decapsulatorはまるで局所的にそれを受け取るかのようにEncapsulatedデータグラムを受けて、Encapsulation Headerを取り外して、Clearデータグラムを扱います。 Decapsulatorのアドレスのための要件はそれにEncapsulatorのEncapsulation Spaceアドレスから届いているということです。
5. Generation of the Encapsulation Header
5. カプセル化ヘッダーの世代
The contents of the Encapsulation Header are generated by performing a mapping function from the Clear Header to the contents of the Encapsulation Header. This mapping function could take many forms, but the end result should be the same. The following paragraphs describe one method of performing the mapping. The process is illustrated in Fig. 3.
Encapsulation Headerの内容は、Clear HeaderからEncapsulation Headerのコンテンツまでマッピング機能を実行することによって、発生します。 このマッピング機能は多くの形を取るかもしれませんが、結末は同じであるべきです。 以下のパラグラフはマッピングを実行する1つの方法を説明します。 過程は図3で例証されます。
In the first part of the mapping function, the Clear Header is matched with stored headers and masks to determine a Flow ID. This is essentially a "mask-and-match" table look up, where the lookup table holds three entries, a Clear Header, a header mask, and a corresponding Flow ID. The mask can be used for allowing a range of source and destination addresses to map to a given flow. Other fields, such as the IP TOS bits or even the TCP source or destination port addresses could also be used to discriminate between Flows. This flexibility allows many possibilities for using the mapping function. Not only can a given network be associated with a particular flow, but even a particular TCP protocol or connection
マッピング機能の最初の部分では、Clear Headerが、Flow IDを決定するために格納されたヘッダーとマスクに合わせられています。 これは本質的にはルックアップ表が3つのエントリーを保持するところのClear Header、ヘッダーマスク、および対応するFlow IDへの「マスクとマッチ」テーブル一見です。 与えられた流れに写像するアドレスをさまざまなソースと目的地に許容するのにマスクを使用できます。 また、Flowsを区別するのにIP TOSビット、TCPソースまたは仕向港アドレスなどさえの他の分野を使用できました。 この柔軟性はマッピング機能を使用するための多くの可能性を許容します。 唯一でない、当然のことのネットワークは、特定の流れに関連していますが、同等のa特定のTCPプロトコルか接続であるかもしれません。
Woodburn & Mills [Page 5] RFC 1241 Internet Encapsulation July 1991
Woodburnと工場[5ページ]RFC1241インターネットカプセル化1991年7月
could be distinguished from another.
別のものと区別できました。
How the lookup table is built and maintained is not part of this protocol. It is assumed that it is managed by some higher layer entity. It would be sufficient to configure the tables from ascii text files if necessary.
ルックアップ表がどう組立てられて、維持されるかは、このプロトコルの一部ではありません。 それが何らかのより高い層の実体によって管理されると思われます。 必要なら、ASCIIテキストファイルからテーブルを構成するのは十分でしょう。
+--------+
| |
+->| Encap. |--+
| | Info. | |
+-------+ | | Table | |
| Mask | +---------+ | | | |
Clear --+-->| & |-->| Flow ID |---+ | | |
Header | | Match | +---------+ +--------+ |
| +-------+ |
| +--> Encap
+-----------------------------------------------> Header
+--------+ | | +->| Encap。 |--+ | | インフォメーション。 | | +-------+ | | テーブル| | | マスク| +---------+ | | | | クリアしてください(+)。>| & | -->、| 流れID|---+ | | | ヘッダー| | マッチ| +---------+ +--------+ | | +-------+ | | +-->Encap+----------------------------------------------->ヘッダー
Fig. 3. Generation of the Encapsulation Header
図3。 カプセル化ヘッダーの世代
The Flow IDs are managed at a higher layer as well. An example of how Flow IDs can be managed is found in the Setup protocol of the Inter-Domain Policy Sensitive Routing Protocol (IDPR). [4] The upper layer protocol would be responsible for maintaining information not carried in the encapsulation protocol related to the flow. This could include the information necessary to construct the Encapsulation Header (described below) as well as information such as the type of data being encapsulated (currently only IP is defined), and the type of authentication used if any. Note that IDPR Setup requires the use of a longer Flow ID which is unique for the entire universe of Encapsulators and is the same at every Encapsulator.
Flow IDはまた、より高い層で管理されます。 どうFlow IDに対処できるかに関する例はInter-ドメインPolicy Sensitiveルート設定プロトコル(IDPR)のSetupプロトコルで見つけられます。 [4] 上側の層のプロトコルは流れに関連するカプセル化プロトコルで運ばれなかった情報を保守するのに原因となるでしょう。 これは、要約されている(現在のIPだけが定義されます)データのタイプや、もしあれば使用される認証のタイプなどの情報と同様にEncapsulation Headerを組み立てる(以下で、説明される)ために必要情報を含むかもしれません。 IDPR SetupがEncapsulatorsの宇宙全体にユニークな、そして、あらゆるEncapsulatorで同じより長いFlow IDの使用を必要とすることに注意してください。
The Flow ID that results from the mapping of a Clear Header is a 32 bit quantity and identifies the Flow as it is seen by the Encapsulator. If a Clear Datagram must be encapsulated and decapsulated several times in order reach the destination, the Flow ID may be different at each Encapsulator, but need not be. The Flow ID acts as an index into a table of Encapsulation Header information that is used to build the Encapsulation Header. Note that the decision to make the Flow ID local to the Encapsulator is due to the difficulty in choosing and maintaining globally unique identifiers.
Clear Headerに関するマッピングから生じるFlow IDは、32ビットの量であり、それがEncapsulatorによって見られるようなFlowを特定します。 目的地に達するように何度かClearデータグラムを要約されて、decapsulatedしなければならないなら、Flow IDは、各Encapsulatorで異なるかもしれませんが、ある必要はありません。 Flow IDはインデックスとしてEncapsulation Headerを造るのに使用されるEncapsulation Header情報のテーブルに機能します。 Flow IDをEncapsulatorにローカルにするという決定がグローバルにユニークな識別子を選んで、維持することにおける苦労のためであることに注意してください。
The intermediate step of using a Flow ID entirely optional. The important requirement is that all Encapsulators along a Flow map the same Clear Header to the same Flow (which could be identified by different identifiers along the way). However, by allowing for a
中間介在物は完全に任意の状態でFlow IDを使用するのを踏みます。 重要な要件はFlowに沿ったすべてのEncapsulatorsが同じFlow(異なった識別子は道に沿って特定できた)に同じClear Headerを写像するということです。 aを考慮します。
Woodburn & Mills [Page 6] RFC 1241 Internet Encapsulation July 1991
Woodburnと工場[6ページ]RFC1241インターネットカプセル化1991年7月
Flow ID in the protocol, a more efficient implementation of the mapping function becomes possible. This is discussed in more detail when we consider the Decapsulator.
プロトコルの流れID、マッピング機能の、より効率的な実現は可能になります。 私たちがDecapsulatorを考えると、さらに詳細にこれについて議論します。
The following information is required to construct the Encapsulation Header:
以下の情報がEncapsulation Headerを組み立てるのに必要です:
Flow ID -
This is the key for this table of information and
represents the Flow ID relative to the current
Encapsulator.
流れID--これは、情報のこのテーブルのためのキーであり、現在のEncapsulatorに比例してFlow IDを表します。
Decapsulator Address -
The IP address of the Decapsulator in the Encapsulation
Space must be known to build the IP portion of the
Encapsulation Header.
Decapsulator Address--Encapsulation HeaderのIP部分を築き上げるのをEncapsulation SpaceのDecapsulatorのIPアドレスを知らなければなりません。
Decapsulator's Flow ID -
The Flow ID, if any, for the Flow as seen by the
Decapsulator must be known.
DecapsulatorのFlow ID--Decapsulatorによって見られるFlowのためのもしあればFlow IDを知っていなければなりません。
Previous Encapsulator's Address -
If this is not the first Encapsulator along the Flow, the
previous Encapsulator's address must be known for error
reporting.
前のEncapsulatorのAddress--これがFlowに沿った最初のEncapsulatorでないなら、誤り報告で前のEncapsulatorのアドレスを知っていなければなりません。
Previous Encapsulator's Flow ID -
In addition to the previous Encapsulator's address, the
Flow ID of the Flow relative to the previous Encapsulator
must be known.
前のEncapsulatorのアドレスに加えた前のEncapsulatorのFlow ID、前のEncapsulatorに比例したFlowのFlow IDを知っていなければなりません。
The Encapsulation Header consists of an IP Header as well as an Encapsulation Protocol Header. The two pieces of information required for the Encapsulation Protocol Header which must be determined at the time of encapsulation are the protocol which is being encapsulated and the Flow ID to send to the Decapsulator. The generation of the IP header is more complicated.
Encapsulation HeaderはEncapsulationプロトコルHeaderと同様にIP Headerから成ります。 カプセル化時点で断固とするに違いないEncapsulationプロトコルHeaderに必要である情報の2つの断片が、要約されているプロトコルとDecapsulatorに送るFlow IDです。 IPヘッダーの世代は、より複雑です。
There are two possible ways each field in the Clear Header could related to the new IP header.
新しいIPヘッダーに関係づけられて、それぞれがClear Headerでさばく道がそうすることができたのが可能な2があります。
Copy -
Copy the existing field from the Clear Header to the IP
header in the Encapsulation Header.
コピー--Encapsulation HeaderにClear HeaderからIPヘッダーまで既存の分野をコピーしてください。
Ignore -
The field may or may not have existed in the Clear Header,
but does not apply to the new IP header.
無視、--分野は、Clear Headerに存在したかもしれませんが、新しいIPヘッダーに適用されません。
Woodburn & Mills [Page 7] RFC 1241 Internet Encapsulation July 1991
Woodburnと工場[7ページ]RFC1241インターネットカプセル化1991年7月
The IP header has a fixed portion and a variable portion, the options list. A summary of all possible IP fields and the relation to the Clear Header follows in Table 1. [2]
オプションは、IPヘッダーには固定部分と可変部分があると記載します。 すべての可能なIP分野の概要とClear Headerとの関係はTable1で従います。 [2]
Note that most of the fields in the Clear Header are simply ignored. Fields such as the Header Length in the Clear Header have no effect on the Header Length of the new IP header. The fields which are more interesting and require some thought are now discussed.
Clear Headerの分野の大部分が単に無視されることに注意してください。 Clear HeaderのHeader Lengthなどの分野は新しいIPヘッダーのHeader Lengthで効き目がありません。 現在、よりおもしろく、何らかの考えを必要とする分野について議論します。
The Quality of Service bits should be copied from the Clear Header to the new IP header. This is in keeping with the transparency principle that if the User Space was providing a given service, then the Encapsulation Space must provide the same service.
ServiceビットのQualityはClear Headerから新しいIPヘッダーまでコピーされるべきです。 これはUser Spaceが与えられたサービスを提供していたならEncapsulation Spaceが同じサービスを提供しなければならないという透明原則に従っています。
The More Fragments bit and Fragment Offset should not be copied, since the datagram being built is a complete datagram, regardless of the status of the encapsulated datagram. If the completed datagram is too large for the interface, it will be fragmented for transmission to the decapsulator by the normal IP fragmentation mechanism.
More FragmentsビットとFragment Offsetをコピーするべきではありません、組立てられるデータグラムが完全なデータグラムであるので、要約のデータグラムの状態にかかわらず。 インタフェースには、完成したデータグラムが大き過ぎるなら、それは正常なIP断片化メカニズムによるdecapsulatorへの伝送のため断片化されるでしょう。
The Don't Fragment bit should not be copied into the Encapsulation Header. The transparency principle would again be violated. It should be up to the Encapsulator to decide whether fragmentation should be allowed across the Encapsulation Space. If it is decided that the DF bit should be used, then ICMP message would be returned if the Encapsulated Datagram required fragmentation across the Encapsulation Space The mechanism for returning an ICMP message to the source in the User space will have to be modified, however, and this is discussed in the Appendix B.
どんなFragmentも噛み付かなかったドンをEncapsulation Headerにコピーするべきではありません。 透明原則は再び違反されるでしょう。 断片化がEncapsulation Spaceの向こう側に許されるべきであるかどうか決めるのは、Encapsulator次第であるべきです。 DFビットが使用されるべきであると決めるなら、Encapsulatedデータグラムが、しかしながら、UserスペースのソースにICMPメッセージを返すためのメカニズムが持っているEncapsulation Spaceの向こう側の断片化が変更されるのを必要とするなら、ICMPメッセージを返すでしょうに、そして、Appendix Bでこれについて議論します。
Regarding the Time To Live (TTL) field, the easiest thing to do is to ignore the TTL from the Clear Header. If this field were copied from the Clear Header to the new IP header, the packet life might be prematurely exceeded during transit in the Encapsulation Space. This breaks the transparency rule of encapsulation as seen from the User Space. The TTL of the Clear Header is decremented before encapsulation by the IP forwarding function, so there is no chance of a packet looping forever if the links of a Flow form a loop.
Time To Live(TTL)分野に関して、する中で最も簡単なことはClear HeaderからTTLを無視することです。 この分野がClear Headerから新しいIPヘッダーまでコピーされるなら、パケット人生は早まって、トランジットの間、Encapsulation Spaceで超えられているでしょうに。 これはUser Spaceから見られるようにカプセル化の透明規則を破ります。 Clear HeaderのTTLがカプセル化の前にIP推進機能で減少するので、Flowのリンクが輪を形成するなら、いつまでも、パケットループの見込みが全くありません。
Woodburn & Mills [Page 8] RFC 1241 Internet Encapsulation July 1991
Woodburnと工場[8ページ]RFC1241インターネットカプセル化1991年7月
+---------------------+---------+
| Field | Mapping |
+---------------------+---------+
| Version | Ignore |
| Header Length | Ignore |
| Precedence | Copy |
| QoS bits | Copy |
| Total Length | Ignore |
| Identification | Ignore |
| Don't Fragment Bit | Ignore |
| More Fragments Bit | Ignore |
| Fragment Offset | Ignore |
| Time to Live | Ignore |
| Protocol | Ignore |
| Header Checksum | Ignore |
| Source Address | Ignore |
| Destination Address | Ignore |
| End of Option List | Ignore |
| NOP Option | Ignore |
| Security Option | Copy |
| LSR Option | Ignore |
| SSR Option | Ignore |
| RR Option | Ignore |
| Stream ID Option | Ignore |
| Timestamp Option | Ignore |
+---------------------+---------+
+---------------------+---------+ | 分野| マッピング| +---------------------+---------+ | バージョン| 無視します。| | ヘッダ長| 無視します。| | 先行| コピー| | QoSビット| コピー| | 全長| 無視します。| | 識別| 無視します。| | ビットを断片化しないでください。| 無視します。| | 以上はビットを断片化します。| 無視します。| | 断片オフセット| 無視します。| | 生きる時間| 無視します。| | プロトコル| 無視します。| | ヘッダーチェックサム| 無視します。| | ソースアドレス| 無視します。| | 送付先アドレス| 無視します。| | オプションリストの終わり| 無視します。| | NOPオプション| 無視します。| | セキュリティオプション| コピー| | LSRオプション| 無視します。| | SSRオプション| 無視します。| | RRオプション| 無視します。| | 流れのIDオプション| 無視します。| | タイムスタンプオプション| 無視します。| +---------------------+---------+
Table 1. Summary of IP Header Mappings
1を見送ってください。 IPヘッダーマッピングの概要
The protocol field for the new IP header should be filled with the protocol number of the encapsulation protocol.
新しいIPヘッダーのためのプロトコル分野はカプセル化プロトコルのプロトコル番号で満たされるべきです。
The source address in the new IP header becomes the IP address of the Encapsulator in the Encapsulation Domain. The destination address becomes the IP address of the Decapsulator as found in the encapsulation table.
新しいIPヘッダーのソースアドレスはEncapsulation DomainでEncapsulatorのIPアドレスになります。 送付先アドレスはカプセル化テーブルで見つけられるようにDecapsulatorのIPアドレスになります。
IP Options are generally not copied because most don't make sense in the context of the Encapsulation Space, as the transparency principle would indicate. The security option is probably the one option that should get copied for the same reason QOS and precedence fields are copied, the Encapsulation Space must provide the expected service. Timestamp, Loose Source Route, Strict Source Route, and Record Route are not copied during encapsulation.
大部分がEncapsulation Spaceの文脈で理解できないので、一般に、IP Optionsはコピーされません、透明原則が示すように。 セキュリティオプションはたぶんQOSと先行分野がコピーされる同じ理由で記事をとるべきである1つのオプションです、とEncapsulation Spaceは予想されたサービスを前提としなければなりません。 タイムスタンプ、Loose Source Route、Strict Source Route、およびRecord Routeはカプセル化の間、コピーされません。
6. Decapsulation
6. 被膜剥離術
In the ideal situation, a Decapsulator receives an Encapsulated
理想的な状況で、DecapsulatorはEncapsulatedを受けます。
Woodburn & Mills [Page 9] RFC 1241 Internet Encapsulation July 1991
Woodburnと工場[9ページ]RFC1241インターネットカプセル化1991年7月
Datagram, strips off the Encapsulation Header and sends the Clear Datagram back into IP so that it is forwarded from that point. However, if the Clear Datagram has not reached the destination User Space, it must again be encapsulated to move it close to the destination User Space. In this latter case the Decapsulator would become an Encapsulator and would perform the same calculation to generate the Encapsulation Header as did the previous Encapsulator. In order to make this process more efficient, the use of Flow IDs have been incorporated into the protocol.
データグラム、そのポイントからそれを進めるようにIPにEncapsulation Headerで剥取って、Clearデータグラムを返送します。 しかしながら、Clearデータグラムが目的地User Spaceに達していないなら、目的地User Spaceの近くでそれを動かすために再びそれを要約しなければなりません。 この後者の場合では、Decapsulatorは、Encapsulatorになって、前のEncapsulatorのようにEncapsulation Headerを発生させるように同じ計算を実行するでしょう。 この過程をより効率的にするように、Flow IDの使用をプロトコルに組み入れてあります。
When Flow IDs are used, the Flow ID received in the Encapsulation Header corresponds to a stored Flow ID in the Decapsulator. At this point the Decapsulator has the option of bypassing the mask and match operation on the Clear Header. The received Flow ID can be used to point directly into the local Encapsulator tables for the construction of the next Encapsulation Header. If the Flow ID is unknown, an error message is sent back to the previous Encapsulator to that effect and a signal is sent to upper layer entity managing the encapsulation tables.
Flow IDが使用されているとき、Encapsulation Headerに受け取られたFlow IDはDecapsulatorの格納されたFlow IDに対応しています。 ここに、Decapsulatorには、Clear Headerでマスクとマッチ操作を迂回させるオプションがあります。 直接次のEncapsulation Headerの構造のための地方のEncapsulatorテーブルに指すのに容認されたFlow IDを使用できます。 Flow IDが未知であるなら、その趣旨で前のEncapsulatorにエラーメッセージを返送します、そして、カプセル化がテーブルの上に置く上側の層の実体管理に信号を送ります。
Because the normal IP forwarding mechanism is being bypassed when Flow IDs are used, certain mechanisms normally handled by IP must be taken care of by the Decapsulator before encapsulation. The Decapsulator must decrement the TTL before the next encapsulation occurs. If a Time Exceeded error occurs, then an ICMP message is sent to the source indicated in the Clear Header.
Flow IDが使用されているとき、正常なIP推進メカニズムが迂回しているので、Decapsulatorはカプセル化の前に通常、IPによって扱われたあるメカニズムの世話をしなければなりません。 次のカプセル化が起こる前にDecapsulatorはTTLを減少させなければなりません。 Time Exceeded誤りが発生するなら、Clear Headerで示されたソースにICMPメッセージを送ります。
7. Error Messages
7. エラーメッセージ
There are two kinds of error message built into the encapsulation protocol. The first is used to report unknown flow identifiers seen by a Decapsulator and the second is for the forwarding of ICMP messages.
カプセル化プロトコルが組み込まれた2種類のエラーメッセージがあります。 1番目は、Decapsulatorによって見られた未知の流れ識別子と秒がICMPメッセージの推進のためのものであると報告するのに使用されます。
When a Decapsulator is using the received Flow ID in an Encapsulation Header to forward a datagram to the next Decapsulator in a Flow, it is possible that the Flow ID may not be known. For this case the Decapsulator will notify the previous Encapsulator that the Flow was not known so that the problem may be reported to the layer responsible for the programming of the Flow tables. This is accomplished through an encapsulation error message.
DecapsulatorがFlowの次のDecapsulatorにデータグラムを送るのにEncapsulation Headerで容認されたFlow IDを使用しているとき、Flow IDが知られていないのは、可能です。 このような場合、Decapsulatorは、FlowがFlowテーブルのプログラミングに原因となる層に問題を報告できるように知られていなかったことを前のEncapsulatorに通知するでしょう。 これはカプセル化エラーメッセージを通して達成されます。
If an Encapsulator receives an ICMP messages regarding a given flow, this message should be forwarded backwards along the flow to the source Encapsulator. This is accomplished by the second kind of error message. The ICMP message will contain the Flow ID of the message which caused the error. This Flow ID must be translated to the Flow ID relative to the Encapsulator to which the error message
Encapsulatorが与えられた流れに関するICMPメッセージを受け取るなら、流れに沿って後方にこのメッセージをソースEncapsulatorに転送するべきです。 これは2番目の種類に関するエラーメッセージによって達成されます。 ICMPメッセージは誤りを引き起こしたメッセージのFlow IDを含むでしょう。 Encapsulatorに比例してこのFlow IDをFlow IDに翻訳しなければならない、どれ、エラーメッセージ
Woodburn & Mills [Page 10] RFC 1241 Internet Encapsulation July 1991
Woodburnと工場[10ページ]RFC1241インターネットカプセル化1991年7月
is sent.
送ります。
If an error occurs while sending any error message, no further error message are generated.
誤りが発信している間、発生するなら、どんなエラーメッセージ、さらなるエラーメッセージも全く発生しません。
8. References
8. 参照
[1] J. Postel, Internet Control Message Protocol, RFC 792,
September 1981.
[1] J.ポステル、インターネット・コントロール・メッセージ・プロトコル、RFC792、1981年9月。
[2] J. Postel, Internet Protocol, RFC 791, September 1981.
[2] J.ポステル、インターネットプロトコル、RFC791、1981年9月。
[3] J. Postel, Transmission Control Protocol, RFC 793, September
1981.
[3] J.ポステル、通信制御プロトコル、RFC793、1981年9月。
[4] ORWG, Inter-Domain Policy Routing Protocol Specification and
Usage, Draft, August 1990
ORWG、相互ドメイン方針ルート設定プロトコル仕様、および用法が1990年8月に作成する[4]
A. Packet Formats
A。 パケット・フォーマット
This section describes the packet formats for the encapsulation protocol.
このセクションはカプセル化プロトコルのためにパケット・フォーマットについて説明します。
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | HL | MT | RC | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 8 16 24 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers| hl| MT| RC| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 流れID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. A.1. Encapsulation Protocol Header Example
図A.1。 カプセル化プロトコルヘッダーの例
Vers 4 bits The version number of the encapsulation
protocol. The version of the protocol
described by this document is 1.
カプセル化プロトコルのバージョン番号を4ビットVersします。 このドキュメントによって説明されたプロトコルのバージョンは1です。
HL 4 bits The header length of the Encapsulation
Protocol Header in octets.
HL4ビット、八重奏におけるEncapsulationプロトコルHeaderのヘッダ長。
MT 4 bits The message type of the Encapsulation
Protocol message. A data message has a
message type of 1. An error message has a
message type of 2.
EncapsulationプロトコルメッセージのメッセージタイプのMT4ビット。 データメッセージには、1人のメッセージタイプがあります。 エラーメッセージには、2人のメッセージタイプがあります。
RC 4 bits The reason code. This field is unused in the
Data Message and must have a value of 0. In
the Error Message it contains the reason code
for the Error Message. Defined reason code
RC、理由がコード化する4ビット。 この分野は、Data Messageで未使用であり、0の値を持たなければなりません。 Error Messageでは、それはError Messageのための理由コードを含んでいます。 定義された理由コード
Woodburn & Mills [Page 11] RFC 1241 Internet Encapsulation July 1991
Woodburnと工場[11ページ]RFC1241インターネットカプセル化1991年7月
values are:
値は以下の通りです。
1 Unknown Flow ID
2 ICMP returned
1 未知のFlow ID2ICMPは戻りました。
Checksum 16 bits A one's complement checksum for the
Encapsulation Protocol Header. This field is
set to 0 upon calculation of the checksum and
is filled with the checksum calculation
result before the data message is sent.
EncapsulationプロトコルHeaderのためのチェックサム16ビットA1の補数チェックサム。 この分野をチェックサムの計算のときに0に設定して、データメッセージを送る前にチェックサム計算結果で満たします。
Flow ID 32 bits The Flow ID as seen by the Decapsulator or
Encapsulator to which this message is being
sent. In the case of an Unknown Flow ID
error, the Flow ID causing the error is used.
このメッセージが送られる流れID32のビットのDecapsulatorによって見られるFlow IDかEncapsulator。 Unknown Flow ID誤りの場合誤りを引き起こすFlow IDは使用されています。
For Data Messages, the Encapsulation Protocol Header is followed by the Clear Datagram. For Error Messages, the header is followed by the ICMP message being forwarded along a flow.
Data Messagesに関しては、ClearデータグラムはEncapsulationプロトコルHeaderのあとに続いています。 Error Messagesに関しては、流れに沿って転送されるICMPメッセージはヘッダーのあとに続いています。
B. Encapsulation and Existing IP Mechanisms
B。 カプセル化と既存のIPメカニズム
This section discusses in detail the effect of this encapsulation protocol upon the existing mechanisms available with IP and some the possible effects of IP mechanisms upon this protocol. Specifically these are Fragmentation and ICMP messages.
このセクションは詳細にIPと共に利用可能な既存のメカニズムへのこのカプセル化プロトコルの効果について検討します、そして、数人はこのプロトコルへのIPメカニズムの可能な効果について検討します。 明確にこれらは、FragmentationとICMPメッセージです。
B.1 Fragmentation and Maximum Transmission Unit
B.1断片化とマキシマム・トランスミッション・ユニット
An immediate concern of using an encapsulation mechanism is that of restrictions based upon MTU size. The source of a Clear Datagram is going to generate packets consistent with MTU of the interface over which datagram is transmitted. If these packets reach an Encapsulator and are encapsulated, they may be fragmented if they are larger than the MTU of the Encapsulator, even though the physical interfaces of the source and Encapsulator may have the same MTU. Because the Encapsulated Datagram is sent to the Decapsulator using IP, there is no problem in allowing IP to perform fragmentation and reassembly. However, fragmentation is known to be inefficient and is generally avoided. Because a new header is being prepended to the Clear Datagram by the encapsulation process, the likelihood of fragmentation occurring is increased. If the Encapsulator decides to disallow fragmentation through the Encapsulation Space, it must send an ICMP message back to the source. This means that the MTU of the interface in the encapsulation space is effectively smaller than that of the physical MTU of the interface.
カプセル化メカニズムを使用する目前の課題はMTUサイズに基づく制限のものです。 Clearデータグラムの源はデータグラムが送られるインタフェースのMTUと一致したパケットを生成するでしょう。 これらのパケットがEncapsulatorに達して、カプセルに入れられるなら、EncapsulatorのMTUより大きいなら、それらは断片化されるかもしれません、ソースとEncapsulatorの物理インターフェースには同じMTUがあるかもしれませんが。 IPを使用することでEncapsulatedデータグラムをDecapsulatorに送るので、IPが断片化を実行して、再アセンブリされるのを許容するのにおいて問題が全くありません。 しかしながら、断片化は、効率が悪いのが知られて、一般に、避けられます。 新しいヘッダーがカプセル化プロセスによるClearデータグラムにprependedされているので、断片化発生の可能性は広げられます。 Encapsulatorが、Encapsulation Spaceを通した断片化を禁じると決めるなら、それはICMPメッセージをソースに送り返さなければなりません。 これは、事実上、カプセル化スペースのインタフェースのMTUがインタフェースの物理的なMTUのものより小さいことを意味します。
Fragmentation by intermediate User Space Gateways introduces another
中間的User Space Gatewaysによる断片化は別のものを導入します。
Woodburn & Mills [Page 12] RFC 1241 Internet Encapsulation July 1991
Woodburnと工場[12ページ]RFC1241インターネットカプセル化1991年7月
problem. Fragmentation occurs at the IP level. If a TCP protocol is in use and fragmentation occurs, the TCP header is contained in the first fragment, but not the following fragments. [3] If these fragments are forwarded by an Encapsulator, discrimination of the Clear Header for a given flow will only be able to occur on the IP header portion of the Clear Header. If discrimination is attempted on the TCP portion of the header, then only the first fragment will be matched, while remaining fragments will not.
問題。 断片化はIPレベルで起こります。 TCPプロトコルが使用中であり、断片化が起こるなら、TCPヘッダーは以下の断片ではなく、最初の断片に含まれています。 [3] これらの断片がEncapsulatorによって進められると、与えられた流れのためのClear Headerの区別はClear HeaderのIPヘッダー部分に起こることができるだけでしょう。 区別がヘッダーのTCP部分で試みられると、最初の断片だけが合わせられるでしょう、残っている断片はそうしないでしょうが。
B.2 ICMP Messages
B.2 ICMPメッセージ
The most controversial aspect of encapsulation is the handling of ICMP messages. [1] Because the Encapsulation Header contains the source address of the Encapsulator in the Encapsulation Space, ICMP messages which occur within the Encapsulation Space will be sent back to the Encapsulator. Once the Encapsulator receives the ICMP message, the question is what should the next action be. Since the original source of the Clear Datagram knows nothing about the Encapsulation Space, it does not make sense to forward an ICMP message on to it and ICMP message are not supposed to beget ICMP messages. Yet not sending the original source something may break some important mechanisms.
カプセル化の最も論議を呼んだ局面はICMPメッセージの取り扱いです。 [1] Encapsulation HeaderがEncapsulation SpaceにEncapsulatorのソースアドレスを含んでいるので、EncapsulatorはEncapsulation Spaceの中に現れるICMPメッセージに送り返されるでしょう。 EncapsulatorがいったんICMPメッセージを受け取ると、質問が受け取る、次の動作は何であるべきですか? Clearデータグラムの一次資料がEncapsulation Spaceに関して何も知らないので、それはそれとICMPメッセージがICMPを生み出すべきでないようにオンなICMPメッセージを転送する意味をメッセージにしません。 しかし、何かを一次資料に送らないと、いくつかの重要なメカニズムが壊れるかもしれません。
In addition to deciding what to forward to the source of the Clear Datagram, there is the problem of possibly not having enough information to send anything at all back to the source. An ICMP message returns the header of the offending message and the first eight octets of the data after the header. For the case of the encapsulation protocol, this translates to the IP portion of the Encapsulation Header, the first eight octets of the Encapsulation Protocol Header, and nothing else. The contents of the Clear Datagram are completely lost. Therefore, for the Encapsulator to send an ICMP message back to the source it has to reconstruct the Clear Header. However, it is essentially impossible to reproduce the exact header.
Clearデータグラムの源に何を送ったらよいかを決めることに加えて、ことによると何もソースに全く送り返すことができるくらいの情報を持っていないという問題があります。 ICMPメッセージは腹立たしいメッセージのヘッダーとデータの最初の8つの八重奏をヘッダーの後に返します。 カプセル化プロトコルに関するケースのために、これはEncapsulation Header、EncapsulationプロトコルHeaderの最初の8つの八重奏、および他に何ものIP部分に翻訳されます。 Clearデータグラムの内容は完全に失われています。 したがって、EncapsulatorがICMPメッセージをソースに送り返すように、それはClear Headerを再建しなければなりません。 しかしながら、正確なヘッダーを再生させるのは本質的には不可能です。
For the purpose of this specification, the Flow ID has been assumed to be a unique one way mapping from a Clear Header. There is no guarantee that the Flow ID could be used to map back to the Clear Header, since several headers potentially map to the same flow. With there being no effective way to regenerate the original datagram, some compromises must be examined.
この仕様の目的のために、Flow IDはClear Headerからのユニークな一方通行のマッピングであると思われました。 Clear Headerへの後部を写像するのにFlow IDを使用できたという保証が全くありません、数個のヘッダーが潜在的に流れを同じくらいに写像するので。 そこで、オリジナルのデータグラムを作り直す効果的な方法でないことで、いくつかの感染を調べなければなりません。
For each of the possible ICMP messages, the alternatives and impact will be assessed. There are three categories of ICMP message involved. The first is those ICMP messages which are not applicable in the context of Encapsulation. These are: Echo/Echo Reply and Timestamp/Timestamp Reply.
それぞれの可能なICMPメッセージに関しては、代替手段と影響は評価されるでしょう。 ICMPメッセージのかかわった3つのカテゴリがあります。 1番目はそれらのEncapsulationの文脈で適切でないICMPメッセージです。 これらは以下の通りです。 エコー/エコー・リプライとタイムスタンプ/タイムスタンプは返答します。
Woodburn & Mills [Page 13] RFC 1241 Internet Encapsulation July 1991
Woodburnと工場[13ページ]RFC1241インターネットカプセル化1991年7月
The second category are those ICMP messages which concern mechanisms local to the encapsulation domain. These are messages which would not make sense to the original source if it did receive them. In these cases the encapsulator will have to decide what to do, but no ICMP message need be sent back to the original source. The datagram will simply be lost, IP is not meant to be a reliable protocol. Subsequent messages received for encapsulation may cause the encapsulator to generate ICMP Destination Unreachable messages back to the original source if the encapsulator can no longer send messages to the destination decapsulator. This requires that ICMP messages inside the encapsulation domain affect the mapping from the Flow ID. ICMP messages in the second category are: Parameter Problem, Redirect, Destination Unreachable, Time Exceeded.
2番目のカテゴリはカプセル化ドメインへのローカルのメカニズムに関するそれらのICMPメッセージです。 これらはそれらを受けるなら一次資料に理解できないメッセージです。 これらの場合では、encapsulatorは、何をしたらよいかを決めなければならないでしょうが、ICMPメッセージは全く一次資料に送り返される必要はありません。 データグラムは単になくされて、IPは信頼できるプロトコルであることが意味されません。 カプセル化のために受け取られたその後のメッセージで、encapsulatorがもう目的地decapsulatorにメッセージを送ることができないなら、encapsulatorは一次資料へのメッセージをICMP Destination Unreachableに生成するかもしれません。 これは、カプセル化ドメインの中のICMPメッセージがFlow IDからマッピングに影響するのを必要とします。 2番目のカテゴリにおけるICMPメッセージは以下の通りです。 時間が超えていた再直接の、そして、目的地手の届かないパラメタ問題。
Finally there is one ICMP message which has direct bearing on the operation of the original source of datagrams destined for encapsulation, the ICMP Source Quench message. The only possible mechanism available to the Encapsulator to handle this message is for the source quench message set a flag for the offending Flow ID such that subsequent messages that map the Flow cause the generation of a source quench back to the original source before the datagram is encapsulated.
最終的に、カプセル化(ICMP Source Quenchメッセージ)のために運命づけられたデータグラムの一次資料の操作に直接の関係を持っている1つのICMPメッセージがあります。 このメッセージを扱うEncapsulatorに利用可能な唯一の可能なメカニズムがソース焼き入れメッセージが怒っているFlow IDに旗を設定したので、データグラムがカプセル化される前に、Flowを写像するその後のメッセージがソース焼き入れの世代を一次資料に引き起こして戻すからです。
This last mechanism may be a solution for the more general problem. The rule of thumb could be that when an ICMP message is received for a given flow, then flag the Flow so that then next message encapsulated will cause the next message encapsulated on that flow to force an ICMP message to the source. After the ICMP message is sent to the source, the mechanism could be reset. This would effectively cause every other packet to receive an ICMP message if there were a persistent problem. This mechanism is probably only safe for Unreachable messages and Source Quench.
この最後のメカニズムは、より一般的な問題のためのソリューションであるかもしれません。 経験則はその時与えられた流れのためにICMPメッセージを受け取るとき、次に、カプセル化された次のメッセージがICMPメッセージをソースに強制するためにその流れでカプセル化された次のメッセージを引き起こすようにFlowが弛むということであるかもしれません。 ICMPメッセージをソースに送った後に、メカニズムをリセットできました。 これで、永続的な問題があれば、事実上、他のあらゆるパケットがICMPメッセージを受け取るでしょうに。 UnreachableメッセージとSource Quenchだけには、このメカニズムはたぶん安全です。
C. Reception of Clear Datagrams
C。 明確なデータグラムのレセプション
In order to use the encapsulation protocol a modification is required to IP forwarding. There must be some way for the IP module in a system to pass Clear Datagrams to the encapsulation protocol. A suggested means of doing this is to make an addition to a system's routing table structures. A flag could be added to a route that tells the forwarding function to use encapsulation. Note that the default route could also be set to use encapsulation.
カプセル化プロトコルを使用するために、変更がIP推進に必要です。 システムのIPモジュールがカプセル化プロトコルへのデータグラムをClearに通過する何らかの方法があるに違いありません。 これをする提案された手段はシステムの経路指定テーブル構造に加えることです。 カプセル化を使用するように推進機能に言うルートに旗を追加できました。 また、デフォルトルートがカプセル化を使用するように設定できたことに注意してください。
With this mechanism in place, a system's IP forwarding mechanism would examine its routing tables to try and match the IP destination to a specific route. If a route was found, it would be then checked to see if encapsulation should be used. If not the packet would be handled normally. If encapsulation was turned on for the route, then
このメカニズムが適所にある場合、システムのIP推進メカニズムは、IPの目的地を特定のルートに合わせてみるために経路指定テーブルを調べるでしょう。 ルートが見つけられるなら、それは、カプセル化が使用されるべきであるかどうか確認するためにチェックされるでしょうに。 そうでなければ、通常、パケットは扱われるでしょう。 次に、カプセル化がルートにつけられたなら
Woodburn & Mills [Page 14] RFC 1241 Internet Encapsulation July 1991
Woodburnと工場[14ページ]RFC1241インターネットカプセル化1991年7月
the datagram would be sent to encapsulation for forwarding.
推進のためにデータグラムをカプセル化に送るでしょう。
In addition to snagging packets as they are forwarded, something must be done at the last Decapsulator on a given flow so that packets that are decapsulated are properly dumped into the IP module for delivery. Because the packets are encapsulated just before forwarding, it should be a simple matter for decapsulated datagrams to be injected into the output portion of IP. However, the source address in the Clear Header must not change. The address must remain the address of the source in the source User Space and not be overwritten with that of the Decapsulator.
それらを進めるのでパケットを引っかけることに加えて、decapsulatedされるパケットが適切に配送のためのIPモジュールにどさっと落とされるように、与えられた流れで最後のDecapsulatorに何かをしなければなりません。 パケットが推進のすぐ前にカプセルに入れられるので、decapsulatedデータグラムがIPの出力一部に注がれるのは、簡単な事柄であるべきです。 しかしながら、Clear Headerのソースアドレスは変化してはいけません。 アドレスは、ソースUser Spaceにソースのアドレスのままで残っていて、Decapsulatorのもので上書きされてはいけません。
D. Construction of Virtual Networks with Encapsulation
D。 カプセル化との仮想ネットワークの工事
Because of the modification to the routing table to permit encapsulation, it becomes possible to specify a virtual interface whose sole purpose is encapsulation. Using this mechanism, it would become possible to link topologically distant entities with Flows. This would allow the construction of a Virtual Network which would overlay the actual routing topology. An example of such a virtual network is shown in Fig. 4.
カプセル化を可能にする経路指定テーブルへの変更のために、唯一の目的がカプセル化である仮想インターフェースを指定するのは可能になります。 このメカニズムを使用して、遠方の実体をFlowsに位相的にリンクするのは可能になるでしょう。 これはそうするVirtual Networkの構造を許容するでしょう。実際のルーティングトポロジーをかぶせました。 そのような仮想ネットワークに関する例は図4に示されます。
Woodburn & Mills [Page 15] RFC 1241 Internet Encapsulation July 1991
Woodburnと工場[15ページ]RFC1241インターネットカプセル化1991年7月
++++++ Virtual Network A
****** Virtual Network B
# Encapsulator/Decapsulator
------ Common Routing Space
+ + + + + + 仮想ネットワークは******仮想のネットワークB#Encapsulator/Decapsulatorです。------ 一般的なルート設定スペース
------------ ------------
/ \ / \
/ +++ # \ / \
| # +++ + | | # ***** # |
| + + | | * * |
| + + | | * * |
| + + | | * * |
| # ++++ # + | | * * |
\ + / ------------- \ # ** / ---------
\ + # ++ \ # ****** *** # ** \
------------ / +++ * ------------ / *** \
| # * | | # *** #|
| + ** | | * *|
| + # | | * ** |
| + ++++ * | | * * |
| #+ * | | * * |
------------ \ ++++ */ ------------ \ * # /
/ \ # + # ** * # ***** /
/ + ------------- / # ****** # *\ --------
| # +++++++ +| | * * |
| + + + | | * * |
| + # | | * * |
| + ++ | | * # |
| # ++++++ | | * ********* |
\ / \ # /
\ / \ /
------------ ------------
------------ ------------ / \ / \ / +++ # \ / \ | # +++ + | | # ***** # | | + + | | * * | | + + | | * * | | + + | | * * | | # ++++ # + | | * * | \ + / ------------- \ # ** / --------- \ + # ++ \ # ****** *** # ** \ ------------ / +++ * ------------ / *** \ | # * | | # *** #| | + ** | | * *| | + # | | * ** | | + ++++ * | | * * | | #+ * | | * * | ------------ \ ++++ */ ------------ \ * # / / \ # + # ** * # ***** / / + ------------- / # ****** # *\ -------- | # +++++++ +| | * * | | + + + | | * * | | + # | | * * | | + ++ | | * # | | # ++++++ | | * ********* | \ / \ # / \ / \ / ------------ ------------
Fig. 4. Virtual Networks Example
図4。 仮想ネットワークの例
Each Encapsulator shown has an virtual interface on one of the virtual networks. The lines represent individual links in the flows that connect each member of the virtual network. Note that new links could be added between any points as long as the two entities are visible to each other in a common Encapsulation Space. The routing within the virtual network would be handled by the encapsulation mechanism. The programming of the routing tables could be a variant of any of the currently existing routing protocols, an encapsulated OSPF for example.
見せられた各Encapsulatorは仮想ネットワークの1つに仮想インターフェースを持っています。 系列は仮想ネットワークの各メンバーに接する流れで個々のリンクを表します。 互いにおいて、2つの実体が一般的なEncapsulation Spaceで目に見える限り、任意な点の間で新しいリンクを加えることができたことに注意してください。 仮想ネットワークの中のルーティングはカプセル化メカニズムによって扱われるでしょう。 経路指定テーブルのプログラミングは現在既存のルーティング・プロトコル(例えば、カプセル化されたOSPF)のいずれの異形であるかもしれません。
With this in mind, it would be possible to have special encapsulation gateways with virtual interfaces on two virtual networks to form an
これが念頭にある場合、仮想インターフェースが形成する2つの仮想ネットワークにある状態で特別なカプセル化ゲートウェイを持っているのは可能でしょう。
Woodburn & Mills [Page 16] RFC 1241 Internet Encapsulation July 1991
Woodburnと工場[16ページ]RFC1241インターネットカプセル化1991年7月
entire virtual internet. This is the role of the Encapsulators joining Virtual Network A and Virtual Network B.
全体の仮想のインターネット。 これはVirtual Network AとVirtual Network Bを接合するEncapsulatorsの役割です。
E. Encapsulation and OSI
E。 カプセル化とOSI
It is intended that the encapsulation mechanism described in the memo be extensible to other environments outside of the Internet. It should be possible to encapsulate many different protocols within IP and IP within many other protocols.
メモで説明されたカプセル化メカニズムがインターネットの外で他の環境に広げることができることを意図します。 他の多くのプロトコルの中でIPとIPの中の多くの異なったプロトコルをカプセル化するのは可能であるべきです。
The key concepts defined in this memo are the mapping of a header to a Flow ID and the mapping of fields in the original header to the encapsulating header. Special mappings between protocols would have to be defined, i.e. for the QoS bits, and some sort of translation of meanings carefully crafted, but it would be possible, none the less.
このメモで定義された重要な考えは、Flow IDへのヘッダーに関するマッピングと要約のヘッダーへのオリジナルのヘッダーの分野に関するマッピングです。 プロトコルの間の特別なマッピングはすなわち、意味に関するビット、およびある種の翻訳が慎重に作ったQoSのために定義されなければならないでしょうが、それはやはり可能でしょう。
F. Security Considerations
F。 セキュリティ問題
No means of authentication or integrity checking is specifically defined for this protocol apart from the checksum for the header information. However for authentication or integrity checking to be used with this protocol, it is suggested that the authentication information be appended to the Encapsulated Datagram. Information regarding the type of authentication or integrity check in use would have to be included in the flow management protocol which is used to distribute the flow information.
ヘッダー情報のためのチェックサムは別として、認証か保全の照合の手段は全くこのプロトコルのために明確に定義されません。 しかしながら、このプロトコルと共に使用されるためにチェックする認証か保全において、認証情報がEncapsulatedデータグラムに追加されることが提案されます。 認証のタイプに関する情報か使用中である保全チェックが流れ情報を分配するのに使用される流れ管理プロトコルに含まれなければならないでしょう。
G. Authors' Addresses
G。 作者のアドレス
Robert A. Woodburn SAIC 8619 Westwood Center Drive Vienna, VA 22182
Driveウィーン、ロバートA.Woodburn SAIC8619ウエストウッドのセンターヴァージニア 22182
Phone: (703) 734-9000 or (703) 448-0210 EMail: woody@cseic.saic.com
以下に電話をしてください。 (703) 734-9000か(703)448-0210メール: woody@cseic.saic.com
David L. Mills Electrical Engineering Department University of Delaware Newark, DE 19716
デヴィッドL.はデラウエア大学ニューアーク、電気工学部のDE 19716を製粉します。
Phone: (302) 451-8247 EMail: mills@udel.edu
以下に電話をしてください。 (302) 451-8247 メールしてください: mills@udel.edu
Woodburn & Mills [Page 17]
Woodburnと工場[17ページ]
一覧
スポンサーリンク
