====================================================================== 本文章は RFC1853 を日本語に訳したものであり、原文と語彙あるいは解釈の 相違が生じる場合は原文を正しいものとする。訳者および日本語訳に関わった 全ての関係者は、本文書によって読者が被り得る如何なる損害の責任をも負わ ない。 近藤 邦昭 kuniaki@iij.ad.jp IIJ ===================================================================== Network Working Group W. Simpson Request for Comments: 1853 Daydreamer Category: Informational October 1995 IP in IP Tunneling Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. IESG Note: 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. 概要 本文書は、IP Protocol/Payload番号4を使ってIP Securityと他のプロトコル 　 をカプセル化しトンネルするための実装技術について記述してある。 目次 1. イントロダクション 2. カプセル化 3. トンネルの管理 3.1 Tunnel MTU Discovery 3.2 輻輳 3.3 経路制御異常 3.4 他のICMPメッセージ セキュリティに関する考察 REFERENCES ACKNOWLEDGEMENTS AUTHOR'S ADDRESS 1. イントロダクション 　IP in IP カプセル化プロトコル番号4番[RFC1700]は、互いに交わることの 　ないポリシや能力を持つインターネットの溝を埋めるために長い間使われて 　来た。この文書では、巨大なモバイルネットワークを接続するというアマチ 　ュア無線を利用したパケット通信によって長年使われてきた実装技術につい 　て記述し、IPのセキュリティプロトコルの初期の実装についても触れる。 　IP in IPカプセル化の利用は、IPヘッダの間にそれ自身の特別な接着剤のよ 　うなヘッダを挿入しないという点において、以降のトンネリング技術（例え 　ば、プロトコル番号98[RFC-1241]、94[IDM91a]、53[swIPe]そして47 [RFC-1701]である。）とは異なる。その代わり、オリジナルそのままのIP 　ヘッダは他の標準的なIPヘッダに単純に包まれ、保持される。 　この情報は、主にIP Version 4のカプセル化に適用する。他のバージョンの 　IPは別の文書に記述されるだろう。 2. カプセル化 　カプセル化技術は極めて単純である。外部IPヘッダはオリジナルのIPヘッダの 　前に追加される。これらの間にはトンネルの詳細を定義するセキュリティヘッ 　ダのような指針を示すために他のいくつかのヘッダがある。 　外部IPヘッダのソースとディスティネーションはトンネルの「端点」を識別 　する。内部IPヘッダのソースとディスティネーションは実際のデータグラム 　の送信者と受信者を識別する。 　それぞれのヘッダは、IPプロトコルの値[RFC-1700]を利用して次へ結びつける。 +---------------------------+ | Outer IP Header | +---------------------------+ | Tunnel Headers | +---------------------------+ +---------------------------+ | IP Header | | Inner IP Header | +---------------------------+ ====> +---------------------------+ | | | | | IP Payload | | IP Payload | | | | | +---------------------------+ +---------------------------+ 　IPヘッダのフォーマットは[RFC-791]に記述されている。 　Type Of Service 内部IPヘッダよりコピーされる。他のTOSは任意でPeer同 　　　　　　　　　　士の協調のために使われるかもしれない。 　　　　　　　　　　これは、もしユーザがあるサービスレベルを期待している 　　　　　　　　　　ならば、トンネルはそれと同じサービスを提供するべきで 　　　　　　　　　　あるという透過性の原則に一致する。しかし、いくつかの 　　トンネルは、あるポリシに則した特定の異なるレベルのサ 　　ービスを提供するために構成されるかもしれない。 Identification それぞれの外部IPヘッダごとに生成される新しい数値。 　　カプセル化されたデータグラムは、すでにフラグメントさ 　　されているかもしれない、また、トンネルにカプセル化す 　　ることによって他のレベルでフラグメントされるかもしれ 　　ない。これらのトンネルによるフラグメントは最終到達点 　　よりも、カプセル化を解く部分で再構成される。 Reserved 　　無視(0にセットする) 　　この非正式なフラグは実験のために利用されており、内部 　　IPヘッダに残っているものはトンネルに影響を与えない。 Don't Fragment このフィールドの値は内部IPヘッダよりコピーされる。 　　これはパケットの送信者にパフォーマンスレベルのトレー 　　ドオフを制御することを許します。 　　"Tunnel MTU Discovery"を参照。 More Fragments フラグメントされているときにセットされる。 　　このフラグは別個のIdentificationが使われるのと同じ理 　　由でコピーされない。 Time To Live デフォルト値は最新の"Assigned Numbers"[RFC-1700]に定義 　　されている。これは、予測不可能なほど長いトンネルが両端 　　の間に流れるデータグラムのフローをまたげないようにする 　　ためである。 　　内部TTLはカプセル化する前に一度デクリメントされ、そし 　　てカプセル化が解かれる時は影響されない。 Protocol Next Headerを意味し、非干渉トンネルヘッダとして利用 　　するとき、内部IPヘッダに対して4を利用する。 Source インタフェースに割り当てられているIPアドレスがデータ 　　グラム送信時に利用される。 Destination トンネルのカプセル化を解くIPアドレスである。 Options 内部IPヘッダからコピーされない。しかし、パスに関連す 　　る特有な新しいオプションは追加されるかも知れない。 Timestamp, Loose Source Route, Strict Source Route, and Record Routeは、トンネルの中では意図的に隠される。 　　しばしば、トンネルはこれらのオプションの欠点を切り抜 　　けるために構成される。 　　トンネルに対して、サポートしているセキュリティオプショ 　　ンを選択し、影響を与えるために内部IPヘッダを利用しても 　　よい。トンネルに対して選択されたオプションやセキュリテ 　　ィヘッダがそれらのオプションに対して１対１に割り当てが 　　あることは期待できない。 3. トンネルの管理 　トンネルを構成するルータの一部でデータグラムを処理するときエラーが発生 　する可能性があり、これはパケットをカプセル化を行ったトンネルのソースIP 　に対してICMP[RFC-792]のエラーメッセージを返すということを引き起こす。 　不幸にも、ICMPはIPルータにIPヘッダ以降のデータグラムの8バイト(64ビット) しか返さない。これでは、カプセル化されたヘッダすべてを含むのに十分では 　ない。このため、一般的にトンネル内部から帰ってきたICMPメッセージを送信 　元ホストに即座に返すことは、カプセル化を行うルータにとって不可能である。 　しかし、それらトンネルに対して注意深く且つ柔軟に対応することにより、カ 　プセル化を行うルータは、ほとんどの場合ICMPメッセージを正しく返すことが 　できる。ルータは少なくともそれぞれのトンネル関する変動性のある情報を少 　なくとも保持するべきである。 　　- トンネルの出口までの到達性 　　- トンネルの輻輳 　　- トンネルのMTU 　ルータは、先のトンネルの変動性のある情報を更新するためにトンネルの内部 　から受信するICMPメッセージを利用する。以降にそのトンネルを利用して転送 　されるデータグラムが続く場合、ルータはこのトンネルに対する変動性のある 　情報を確認する。もし、データグラムがトンネルの状態に合わない場合（たと 　えば、MTUがトンネルのMTUより大きくDon't Fragmentがセットされている場合) は、ルータは適切なICMPメッセージを送信元に返送する。しかし、そのデータ 　グラムはトンネルにも転送される。エラーメッセージを返しているにもかかわ 　らずデータグラムを転送するのは、トンネルの状態が変更かれたかどうかを知 　るためである。 　このテクニックを使うと、カプセル化を行っているルータからのICMPエラーメ 　ッセージは、トンネル内で発生するエラーに常に一致しない。しかし、ネット 　ワークの状態は正しく反映されるだろう。 3.1. Tunnel MTU Discovery 　Don't Fragmentビットが送信元によってセットされ、外部IPヘッダにコピー 　されたとき、トンネルの適切なMTUはカプセル化を行うルータからレポート 　されるICMP (Type 3 Code 4) "Datagram Too Big"エラーから知る事ができる。 　この昨日を利用している送信元ホストをサポートするために、トンネル内部の 　すべての実装はPath MTU Discoveryをサポートしなくてはならない。 　Tunnel MTU Discoveryの利点としては、カプセル化ヘッダのサイズが原因で発 　生するフラグメントは、カプセル化後にはたった１度しか発生しないという点 　である。これは、一つのデータグラムのフラグメントを１回以上の発生させず、 　経路上のルータとトンネルのカプセル化を解くルータの処理効率を改善させる。 3.2. 輻輳 　トンネルの変動状態は、ICMP(Type 4)のカプセル化を解くルータ(トンネルピ 　ア)から受け取る"Source Quench in datagrams"のような輻輳の兆候から知る 　ことができる。他のデータグラムをトンネルに向けて転送するとき、送信元に 　対して適切な"Source Quench"メッセージを送信する。 3.3. 経路制御異常 　データグラムがカプセル化されるたびにTTLの値がリセットされるため、デー 　タグラムが再度カプセル化を行うルータに到着するときなどは、トンネル内で 　の経路ループは非常に危険である。もし、データグラムのソースIPアドレスが 　インターフェースのどれかに適合するような場合、さらにカプセル化を行うよ 　うな実装をしてはならない。 　ICMP(Type 11) "Time Exceeded"メッセージは、トンネル自身の経路ループを 　レポートする。ICMP(Type 3) "Destination Unreachable"メッセージは、カプ 　セル化を解くルータにへのパケット送達の失敗をレポートする。この変動情報 　は、(Type 3 Code 0) "Network Unreachable"として送信元にレポートされなく 　てはならない。 3.4. 他のICMPメッセージ 　ほとんどのICMPエラーメッセージは、トンネルを利用することに関連性がない。 　とりわけ、パラメータの問題は、カプセル化を行うルータの設定ミスの結果と 　して起こる可能性があり、これらは送信元にレポートしてはならない。 セキュリティに関する考察 　セキュリティに関しては、ごく簡単にこの文書で議論されている。トンネルの 　利用は、いくつかの古いセキュリティオプション（ラベリング)を未然に防ぐか 　もしれない。しかし、トンネルの利用はより新しいIPのセキュリティヘッダの 　サポートを良くする。 References [IDM91a] Ioannidis, J., Duchamp, D., Maguire, G., "IP-based protocols for mobile internetworking", Proceedings of SIGCOMM '91, ACM, September 1991. [RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981. [RFC-792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, USC/Information Sciences Institute, September 1981. [RFC-1191] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, DECWRL, Stanford University, November 1990. [RFC-1241] Mills, D., and R. Woodburn, "A Scheme for an Internet Encapsulation Protocol: Version 1", UDEL, July 1991. [RFC-1435] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, FTP Software, March 1993. [RFC-1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [RFC-1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [swIPe] Ioannidis, J., and Blaze, M., "The Architecture and Implementation of Network-Layer Security Under Unix", Fourth Usenix Security Symposium Proceedings, October 1993. 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. 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]. The chaining of headers was also described in "Simple Internet Protocol", by Steve Deering (Xerox PARC). The overall organization and some of this text was derived from [RFC-1241], by David Mills (U Delaware) and Robert 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). 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 Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com