RFC1853 日本語訳
1853 IP in IP Tunneling. W. Simpson. October 1995. (Format: TXT=14803 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Simpson Request for Comments: 1853 Daydreamer Category: Informational October 1995
コメントを求めるワーキンググループW.シンプソン要求をネットワークでつないでください: 1853年の空想家カテゴリ: 情報の1995年10月
IP in IP Tunneling
IPトンネリングにおけるIP
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
IESG Note:
IESGは以下に注意します。
Note that this memo is an individual effort of the author. This document reflects a current informal practice in the internet. There is an effort underway within the IETF Mobile-IP Working Group to provide an appropriate proposed standard to address this issue.
このメモが作者の個々の取り組みであることに注意してください。 このドキュメントは現在の非公式の習慣をインターネットに反映します。 この問題を扱うために適切な提案された標準を提供するために、IETFモバイルIP作業部会の中の進行中の取り組みがあります。
Abstract
要約
This document discusses implementation techniques for using IP Protocol/Payload number 4 Encapsulation for tunneling with IP Security and other protocols.
このドキュメントはIPを使用するためのプロトコル/有効搭載量がIP Securityと共にトンネルを堀りながら4Encapsulationに付番する実装のテクニックと他のプロトコルについて議論します。
Table of Contents
目次
1. Introduction .......................................... 2
1. 序論… 2
2. Encapsulation ......................................... 3
2. カプセル化… 3
3. Tunnel Management ..................................... 5
3.1 Tunnel MTU Discovery ............................ 5
3.2 Congestion ...................................... 6
3.3 Routing Failures ................................ 6
3.4 Other ICMP Messages ............................. 6
3. 管理にトンネルを堀ってください… 5 3.1 MTU発見にトンネルを堀ってください… 5 3.2混雑… 6 3.3 ルート設定失敗… 6 3.4 他のICMPメッセージ… 6
SECURITY CONSIDERATIONS ...................................... 7
REFERENCES ................................................... 7
ACKNOWLEDGEMENTS ............................................. 8
AUTHOR'S ADDRESS ............................................. 8
セキュリティ問題… 7つの参照箇所… 7つの承認… 8作者のアドレス… 8
Simpson Informational [Page 1] RFC 1853 IP Tunnelling October 1995
1995年10月にトンネルを堀るシンプソン情報[1ページ]のRFC1853IP
1. Introduction
1. 序論
The IP in IP encapsulation Protocol/Payload number 4 [RFC-1700] has long been used to bridge portions of the Internet which have disjoint capabilities or policies. This document describes implementation techniques used for many years by the Amateur Packet Radio network for joining a large mobile network, and also by early implementations of IP Security protocols.
IPカプセル化プロトコル/有効搭載量No.4[RFC-1700]におけるIPによる使用されて、そうしたインターネットのブリッジ部分に能力か方針がばらばらになっているという長い間のことでした。 このドキュメントは何年間も大きいモバイルネットワークに加わるためのAmateur Packet Radioネットワーク、およびIP Securityプロトコルの早めの実装によっても使用される実装のテクニックについて説明します。
Use of IP in IP encapsulation differs from later tunneling techniques (for example, protocol numbers 98 [RFC-1241], 94 [IDM91a], 53 [swIPe], and 47 [RFC-1701]) in that it does not insert its own special glue header between IP headers. Instead, the original unadorned IP Header is retained, and simply wrapped in another standard IP header.
IPカプセル化におけるIPの使用は、それ自身の特別な接着剤ヘッダーをIPヘッダーの間に挿入しないので、後でテクニック(例えば、No.98[RFC-1241]、94[IDM91a]、53[swIPe]、および47[RFC-1701]について議定書の中で述べる)にトンネルを堀るので、異なります。 代わりに、オリジナルの簡素なIP Headerは保有されて、別の標準のIPヘッダーで単に包装されます。
This information applies principally to encapsulation of IP version 4. Other IP versions will be described in separate documents.
この情報は主にIPバージョン4のカプセル化に適用されます。 他のIPバージョンは別々のドキュメントで説明されるでしょう。
Simpson Informational [Page 2] RFC 1853 IP Tunnelling October 1995
1995年10月にトンネルを堀るシンプソン情報[2ページ]のRFC1853IP
2. Encapsulation
2. カプセル化
The encapsulation technique is fairly simple. An outer IP header is added before the original IP header. Between them are any other headers for the path, such as security headers specific to the tunnel configuration.
カプセル化技術はかなり簡単です。 外側のIPヘッダーはオリジナルのIPヘッダーの前で加えられます。 それらの間に、トンネル構成に特定のセキュリティヘッダーなどの経路へのいかなる他のヘッダーもあります。
The outer IP header Source and Destination identify the "endpoints" of the tunnel. The inner IP header Source and Destination identify the original sender and recipient of the datagram.
外側のIPのヘッダーSourceとDestinationはトンネルの「終点」を特定します。 内側のIPのヘッダーSourceとDestinationはデータグラムの元の送り主と受取人を特定します。
Each header chains to the next using IP Protocol values [RFC-1700].
各ヘッダーはIPプロトコルが評価する次の使用[RFC-1700]に鎖を作ります。
+---------------------------+
| Outer IP Header |
+---------------------------+
| Tunnel Headers |
+---------------------------+ +---------------------------+
| IP Header | | Inner IP Header |
+---------------------------+ ====> +---------------------------+
| | | |
| IP Payload | | IP Payload |
| | | |
+---------------------------+ +---------------------------+
+---------------------------+ | 外側のIPヘッダー| +---------------------------+ | トンネルヘッダー| +---------------------------+ +---------------------------+ | IPヘッダー| | 内側のIPヘッダー| +---------------------------+ ====>+---------------------------+ | | | | | IP有効搭載量| | IP有効搭載量| | | | | +---------------------------+ +---------------------------+
The format of IP headers is described in [RFC-791].
IPヘッダーの形式は[RFC-791]で説明されます。
Type Of Service copied from the inner IP header. Optionally,
another TOS may be used between cooperating peers.
内側のIPヘッダーからコピーされたOf Serviceをタイプしてください。 任意に、別のTOSは協力関係を持っている同輩の間で使用されるかもしれません。
This is in keeping with the transparency principle
that if the user was expecting a given level of
service, then the tunnel should provide the same
service. However, some tunnels may be constructed
specifically to provide a different level of service
as a matter of policy.
これはユーザが与えられたレベルのサービスを予想しているならトンネルが同じサービスを提供するという透明原則に従っています。 しかしながら、いくつかのトンネルが、特に政策の問題として異なったレベルのサービスを提供するために建築されるかもしれません。
Identification A new number is generated for each outer IP header.
識別のA新しい番号はそれぞれの外側のIPヘッダーのために生成されます。
The encapsulated datagram may have already been
fragmented, and another level of fragmentation may
occur due to the tunnel encapsulation. These tunnel
fragments will be reassembled by the decapsulator,
rather than the final destination.
カプセル化されたデータグラムは既に断片化されたかもしれません、そして、別のレベルの断片化はトンネルカプセル化のため起こるかもしれません。 これらのトンネル断片は最終的な目的地よりむしろdecapsulatorによって組み立て直されるでしょう。
Reserved
ignored (set to zero).
無視されていた状態で、予約されます(ゼロに設定します)。
Simpson Informational [Page 3] RFC 1853 IP Tunnelling October 1995
1995年10月にトンネルを堀るシンプソン情報[3ページ]のRFC1853IP
This unofficial flag has seen experimental use, and
while it remains in the inner IP header, does not
affect the tunnel.
それは、内側のIPヘッダーに残っていて、トンネルに影響しませんが、この非公式の旗は実験用を見ました。
Don't Fragment copied from the inner IP header. This allows the
originator to control the level of performance
tradeoffs. See "Tunnel MTU Discovery".
内側のIPヘッダーからコピーされたFragmentはそうしませんか? これで、創始者は技量見返りを制御できます。 「トンネルMTU発見」を見てください。
More Fragments set as required when fragmenting.
断片化するとき、より多くのFragmentsが必要に応じてセットしました。
The flag is not copied for the same reason that a
separate Identification is used.
旗は別々のIdentificationが使用されている同じ理由でコピーされません。
Time To Live the default value specified in the most recent
"Assigned Numbers" [RFC-1700]. This ensures that
long unanticipated tunnels do not interrupt the flow
of datagrams between endpoints.
デフォルト値が最新の「規定番号」[RFC-1700]で指定した時間To Live。 これは、長い思いがけないトンネルが終点の間のデータグラムの流れを中断しないのを確実にします。
The inner TTL is decremented once before
encapsulation, and is not affected by decapsulation.
内側のTTLはカプセル化の前に一度減少して、被膜剥離術で影響を受けません。
Protocol the next header; 4 for the inner IP header, when no
intervening tunnel headers are in use.
次のヘッダーについて議定書の中で述べてください。 4 介入しないとき、内側のIPヘッダーにおいて、トンネルヘッダーは使用中です。
Source an IP address associated with the interface used to
send the datagram.
IPアドレスがインタフェースに関連づけたソースは以前はよくデータグラムを送りました。
Destination an IP address of the tunnel decapsulator.
IPが扱うトンネルdecapsulatorの目的地。
Options not copied from the inner IP header. However, new
options particular to the path MAY be added.
オプションは内側のIPヘッダーからコピーされませんでした。 しかしながら、経路に特定の新しいオプションは加えられるかもしれません。
Timestamp, Loose Source Route, Strict Source Route,
and Record Route are deliberately hidden within the
tunnel. Often, tunnels are constructed to overcome
the inadequacies of these options.
タイムスタンプ、Loose Source Route、Strict Source Route、およびRecord Routeは故意にトンネルの中に隠されます。 しばしば、トンネルは、これらのオプションの不適当を克服するために建築されます。
Any supported flavors of security options of the
inner IP header MAY affect the choice of security
options for the tunnel. It is not expected that
there be a one-to-one mapping of such options to the
options or security headers selected for the tunnel.
内側のIPヘッダーのセキュリティオプションのどんなサポートしている風味もトンネルのためのセキュリティオプションの選択に影響するかもしれません。 それはそうではありません。トンネルに選択されて、オプションかセキュリティへのそのようなオプションに関する1〜1つのマッピングがヘッダーであったならそこでそれを予想しました。
Simpson Informational [Page 4] RFC 1853 IP Tunnelling October 1995
1995年10月にトンネルを堀るシンプソン情報[4ページ]のRFC1853IP
3. Tunnel Management
3. トンネル管理
It is possible that one of the routers along the tunnel interior might encounter an error while processing the datagram, causing it to return an ICMP [RFC-792] error message to the encapsulator at the IP Source of the tunnel. Unfortunately, ICMP only requires IP routers to return 8 bytes (64 bits) of the datagram beyond the IP header. This is not enough to include the entire encapsulated header. Thus, it is not generally possible for an encapsulating router to immediately reflect an ICMP message from the interior of a tunnel back to the originating host.
トンネルの内部に沿ったルータの1つがデータグラムを処理している間誤りに遭遇するのは、可能です、トンネルのIP SourceでICMP[RFC-792]エラーメッセージをencapsulatorに返すことを引き起こして。 残念ながら、ICMPはIPヘッダーを超えてデータグラムの復帰8バイト(64ビット)へのIPルータを必要とするだけです。 これは、全体のカプセル化されたヘッダーを含むように十分ではありません。 したがって、一般に、要約ルータがすぐにトンネルの内陸部から送信元ホストまでICMPメッセージを反映するのは、可能ではありません。
However, by carefully maintaining "soft state" about its tunnels, the encapsulator can return accurate ICMP messages in most cases. The router SHOULD maintain at least the following soft state information about each tunnel:
しかしながら、多くの場合、トンネルに関して慎重に「軟性国家」を維持することによって、encapsulatorは正確なICMPメッセージを返すことができます。 ルータSHOULDは少なくとも各トンネルの以下の軟性国家情報を保守します:
- Reachability of the end of the tunnel.
- Congestion of the tunnel.
- MTU of the tunnel.
- トンネルの端の可到達性。 - トンネルの混雑。 - トンネルのMTU。
The router uses the ICMP messages it receives from the interior of a tunnel to update the soft state information for that tunnel. When subsequent datagrams arrive that would transit the tunnel, the router checks the soft state for the tunnel. If the datagram would violate the state of the tunnel (such as the MTU is greater than the tunnel MTU when Don't Fragment is set), the router sends an appropriate ICMP error message back to the originator, but also forwards the datagram into the tunnel. Forwarding the datagram despite returning the error message ensures that changes in tunnel state will be learned.
ルータはそのトンネルにそれが軟性国家情報をアップデートするためにトンネルの内陸部から受け取るICMPメッセージを使用します。 トンネルを通過するその後のデータグラムが届くと、ルータはトンネルがないかどうか軟性国家をチェックします。 データグラムがトンネルの状態に違反するなら(Fragmentではなく、ドンがすばらしいときに、MTUがトンネルMTUよりすばらしいので、そのようなものはセットしました)、ルータは、適切なICMPエラーメッセージを創始者に送り返しますが、データグラムをトンネルにまた送ります。 エラーメッセージを返しますが、データグラムを進めるのは、トンネル州の変化が学習されるのを確実にします。
Using this technique, the ICMP error messages from encapsulating routers will not always match one-to-one with errors encountered within the tunnel, but they will accurately reflect the state of the network.
このテクニックを使用して、ルータをカプセル化するのからのICMPエラーメッセージはトンネルの中で遭遇した誤りにいつも1〜1に合わせるというわけではないでしょうが、それらは正確にネットワークの事情を反映するでしょう。
3.1. Tunnel MTU Discovery
3.1. トンネルMTU発見
When the Don't Fragment bit is set by the originator and copied into the outer IP header, the proper MTU of the tunnel will be learned from ICMP (Type 3 Code 4) "Datagram Too Big" errors reported to the encapsulator. To support originating hosts which use this capability, all implementations MUST support Path MTU Discovery [RFC-1191, RFC-1435] within their tunnels.
どんなFragmentも噛み付かなかったドンが創始者が用意ができて、外側のIPヘッダーにコピーされるとき、トンネルの適切なMTUがICMPから学習される、(3Code4をタイプしてください)「データグラム、大き過ぎる、」 誤りはencapsulatorに報告しました。 送信元ホストをサポートするために、この能力、すべての実装はどの使用がそうしなければならないかがそれらのトンネルの中でPath MTUがディスカバリー[RFC-1191、RFC-1435]であるとサポートします。
Simpson Informational [Page 5] RFC 1853 IP Tunnelling October 1995
1995年10月にトンネルを堀るシンプソン情報[5ページ]のRFC1853IP
As a benefit of Tunnel MTU Discovery, any fragmentation which occurs because of the size of the encapsulation header is done only once after encapsulation. This prevents more than one fragmentation of a single datagram, which improves processing efficiency of the path routers and tunnel decapsulator.
Tunnel MTUディスカバリーの利益として、カプセル化の後に一度だけカプセル化ヘッダーのサイズで起こるどんな断片化もします。 これは単一のデータグラムの1つ以上の断片化を防ぎます。(データグラムは経路ルータとトンネルdecapsulatorの処理効率を高めます)。
3.2. Congestion
3.2. 混雑
Tunnel soft state will collect indications of congestion, such as an ICMP (Type 4) Source Quench in datagrams from the decapsulator (tunnel peer). When forwarding another datagram into the tunnel, it is appropriate to send Source Quench messages to the originator.
トンネル軟性国家は混雑のしるしを集めるでしょう、decapsulator(トンネル同輩)からのデータグラムのICMP(4をタイプする)ソースQuenchのように。 別のデータグラムをトンネルに送るとき、創始者へのメッセージをSource Quenchに送るのは適切です。
3.3. Routing Failures
3.3. ルート設定失敗
Because the TTL is reset each time that a datagram is encapsulated, routing loops within a tunnel are particularly dangerous when they arrive again at the encapsulator. If the IP Source matches any of its interfaces, an implementation MUST NOT further encapsulate. Instead, the datagram is forwarded normally.
TTLが各回データグラムがカプセル化されるリセットであるので、再びencapsulatorに到着するとき、トンネルの中のルーティング輪は特に危険です。 IP Sourceがインタフェースのどれかに合っているなら、実装はさらに要約されてはいけません。 代わりに、通常、データグラムを進めます。
ICMP (Type 11) Time Exceeded messages report routing loops within the tunnel itself. ICMP (Type 3) Destination Unreachable messages report delivery failures to the decapsulator. This soft state MUST be reported to the originator as (Type 3 Code 0) Network Unreachable.
ICMP(11をタイプする)時間Exceededメッセージは、ルーティングがトンネル自体の中で輪にされると報告します。 ICMP(3をタイプする)目的地Unreachableメッセージは配信障害をdecapsulatorに報告します。 (タイプ3Code0)ネットワークUnreachableとしてこの軟性国家を創始者に報告しなければなりません。
3.4. Other ICMP Messages
3.4. 他のICMPメッセージ
Most ICMP error messages are not relevant to the use of the tunnel. In particular, parameter problems are likely to be a result of misconfiguration of the encapsulator, and MUST NOT be reported to the originator.
ほとんどのICMPエラーメッセージはトンネルの使用に関連していません。 パラメタ問題は、特に、encapsulatorのmisconfigurationの結果であることがありそうであり、創始者に報告されてはいけません。
Simpson Informational [Page 6] RFC 1853 IP Tunnelling October 1995
1995年10月にトンネルを堀るシンプソン情報[6ページ]のRFC1853IP
Security Considerations
セキュリティ問題
Security issues are briefly discussed in this memo. The use of tunneling may obviate some older IP security options (labelling), but will better support newer IP Security headers.
このメモで簡潔に安全保障問題について議論します。 トンネリングの使用は、いくつかの、より古いIPセキュリティオプション(ラベルする)を取り除くかもしれませんが、より新しいIPがSecurityヘッダーであると、よりよくサポートするでしょう。
References
参照
[IDM91a] Ioannidis, J., Duchamp, D., Maguire, G., "IP-based
protocols for mobile internetworking", Proceedings of
SIGCOMM '91, ACM, September 1991.
[IDM91a] Ioannidis、J.、デュシャン、D.、マグワイア、G.、「モバイルインターネットワーキングのためのIPベースのプロトコル」、SIGCOMM91年、ACM、1991年9月のProceedings。
[RFC-791]
Postel, J., "Internet Protocol", STD 5, RFC 791,
USC/Information Sciences Institute, September 1981.
[RFC-791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、科学が1981年9月に設けるUSC/情報。
[RFC-792]
Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, USC/Information Sciences Institute, September
1981.
[RFC-792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、科学が1981年9月に設けるUSC/情報。
[RFC-1191]
Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
DECWRL, Stanford University, November 1990.
[RFC-1191] ムガール人、J.とS.デアリング、「経路MTU発見」、RFC1191、DECWRL、スタンフォード大学、1990年11月。
[RFC-1241]
Mills, D., and R. Woodburn, "A Scheme for an Internet
Encapsulation Protocol: Version 1", UDEL, July 1991.
[RFC-1241] 工場、D.、およびR.Woodburn、「インターネットカプセル化の体系は議定書を作ります」。 バージョン1インチ、UDEL、1991年7月。
[RFC-1435]
Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, FTP Software, March 1993.
[RFC-1435] ノウルズ、S.、「経路MTU発見の経験からのIESGアドバイス」、RFC1435、FTPソフトウェア、1993年3月。
[RFC-1700]
Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, USC/Information Sciences Institute, October 1994.
[RFC-1700] USC/情報科学が1994年10月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1700。
[RFC-1701]
Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994.
1994年10月の[RFC-1701]ハンクスとS.と李とT.とファリナッチ、D.とP.Traina、「一般ルーティングのカプセル化(GRE)」RFC1701。
[swIPe] Ioannidis, J., and Blaze, M., "The Architecture and
Implementation of Network-Layer Security Under Unix", Fourth
Usenix Security Symposium Proceedings, October 1993.
[強打します] Ioannidis、J.、炎、M.、および「ネットワーク層セキュリティ下のunixのアーキテクチャと実装」、第4Usenixセキュリティシンポジウム議事(1993年10月)
Simpson Informational [Page 7] RFC 1853 IP Tunnelling October 1995
1995年10月にトンネルを堀るシンプソン情報[7ページ]のRFC1853IP
Acknowledgements
承認
These implementation details of IP Tunneling are derived in large part from independent work in 1990 by Phil Karn and the TCP-Group hams using KA9Q NOS.
フィルKarnとTCP-グループハムは、1990年に独立している仕事からKA9Q NOSを使用することでIP Tunnelingのこれらの実装細部を主に得ます。
Special thanks to John Ioannidis (then of Columbia University) for inspiration and experimentation which began this most recent round of IP Mobility and IP Security development. Some of this text was derived from [IDM91a] and [swIPe].
インスピレーションのためのジョンIoannidis(次にコロンビア大学について)への特別な感謝とIP MobilityとIP Security開発のこの最新のラウンドを始めた実験。 [IDM91a]と[swIPe]からこのテキストのいくつかを得ました。
The chaining of headers was also described in "Simple Internet Protocol", by Steve Deering (Xerox PARC).
また、ヘッダーの推論は「簡単なインターネットプロトコル」でスティーブ・デアリング(ゼロックスPARC)によって説明されました。
The overall organization and some of this text was derived from [RFC-1241], by David Mills (U Delaware) and Robert Woodburn (SAIC).
[RFC-1241]から総合的な組織とこのテキストのいくつかを得ました、デヴィッド・ミルズ(Uデラウェア)とロバートWoodburn(SAIC)。
Some of the text on tunnel soft state was derived from "IP Address Encapsulation (IPAE)", by Robert E. Gilligan, Erik Nordmark, and Bob Hinden (all of Sun Microsystems).
トンネルのロバートが「IPアドレスカプセル化(IPAE)」から派生している柔らかい州のE.ギリガン、エリックNordmark、およびボブHinden(サン・マイクロシステムズのすべて)に関するテキストのいくつか。
Author's Address
作者のアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
ミシガン ウィリアムアレンのシンプソン空想家コンピュータシステムズのコンサルタント業務1384フォンテーヌマディソンの高さ、48071
Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com
Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com
Simpson Informational [Page 8]
シンプソンInformationalです。[8ページ]
一覧
スポンサーリンク
