RFC2004 日本語訳
2004 Minimal Encapsulation within IP. C. Perkins. October 1996. (Format: TXT=12202 bytes) (Status: PROPOSED STANDARD)
RFC一覧
英語原文
Network Working Group C. Perkins
Request for Comments: 2004 IBM
Category: Standards Track October 1996
Minimal Encapsulation within IP
IP 内の最小のカプセル化
Status of This Memo
このメモの位置づけ
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書は、Internet community のための Internet standards tarck
protocol を明細に述べ、改良のための審議と提案を要請する。標準化状態と
この protocol の状態について、"Internet Official Protocol Standards"
(STD 1) の最新版を参照してもらいたい。このメモの配付は、無制限である。
-------------------------------------------------------------------------
Abstract
要約
This document specifies a method by which an IP datagram may be
encapsulated (carried as payload) within an IP datagram, with less
overhead than "conventional" IP encapsulation that adds a second IP
header to each encapsulated datagram. Encapsulation is suggested as
a means to alter the normal IP routing for datagrams, by delivering
them to an intermediate destination that would otherwise not be
selected by the (network part of the) IP Destination Address field in
the original IP header. Encapsulation may be serve a variety of
purposes, such as delivery of a datagram to a mobile node using
Mobile IP.
この文書は、二番目の IP header をそれぞれのカプセル化される datagram
に追加する "conventional (従来型の)" IP カプセル化より overhead が小さ
く、IP datagram 内側に IP datagram が (payload として運ばれて) カプセ
ル化されることに関しての方法を明細に述べる。もともとの IP header 内の
IP Destination Address field (の network 部分) により別の方法で選択さ
れない中間終点に datagram を配送することにより、カプセル化は datagram
について通常の IP routing を変えるための方法として提案される。カプセル
化は、Mobile IP を使用して mobile node へ datagram の配送することのよ
うな、種々の目的に役立つかもしれない。
-------------------------------------------------------------------------
1. Introduction
1. 序論
This document specifies a method by which an IP datagram may be
encapsulated (carried as payload) within an IP datagram, with less
overhead than "conventional" IP encapsulation [4] that adds a second
IP header to each encapsulated datagram. Encapsulation is suggested
as a means to alter the normal IP routing for datagrams, by
delivering them to an intermediate destination that would otherwise
not be selected by the (network part of the) IP Destination Address
field in the original IP header. The process of encapsulation and
decapsulation of a datagram is frequently referred to as "tunneling"
the datagram, and the encapsulator and decapsulator are then
considered to be the the "endpoints" of the tunnel; the encapsulator
node is refered to as the "entry point" of the tunnel, and the
decapsulator node is refered to as the "exit point" of the tunnel.
この文書は、二番目の IP header をそれぞれのカプセル化される datagram
に追加する "conventional (従来型の)" IP カプセル化 [4] より overhead
が小さく、IP datagram 内側に IP datagram が (payload として運ばれて)
カプセル化されることに関しての方法を明細に述べる。もともとの IP header
内の IP Destination Address field (の network 部分) により別の方法で選
択されない中間終点に datagram を配送することにより、カプセル化は
datagram について通常の IP routing を変えるための方法として、提案され
る。datagram のカプセル化とカプセル化を外す処理は、しばしば datagram
を "tunneling (トンネルすること)" として参照される。そして、
encapsulator (カプセル化するもの) と decapsulator (カプセル化を外すも
の) は、それから tunnel の "endpoints" であると考えられる;
encapsulator node は、tunnel の "entry point (入口点)" として参照され
そして decapsulator node は、tunnel の "exit point (出口点)" として参
照される。
-------------------------------------------------------------------------
2. Motivation
2. 動機
The Mobile IP working group has specified the use of encapsulation as
a way to deliver packets from a mobile node's "home network" to an
agent that can deliver datagrams locally by conventional means to the
mobile node at its current location away from home [5]. The use of
encapsulation may also be indicated whenever the source (or an
intermediate router) of an IP datagram must influence the route by
which a datagram is to be delivered to its ultimate destination.
Other possible applications of encapsulation include multicasting,
preferential billing, choice of routes with selected security
attributes, and general policy routing.
Mobile IP working group は、mobile node の "home network" から agent
に packets を配送するための方法としてカプセル化の使用を明細に述べる。
ここで agent は、home から離れて現在の位置に mobile node へ典型的な方
法により局所的に datagrams を配送することが出来る [5]。カプセル化の使
用はまた、配送される IP datagram の source (もしくは、中間の router)
が、最終の終点に datagram が配送される経路に影響を与えなければならない
ときはいつでも、指し示されるかもしれない。カプセル化の他の可能な適用は
multicasting、優先権のある制御、選択された security 属性を持つ経路、と
全体的な policy 経路制御を含む。
See [4] for a discussion concerning the advantages of encapsulation
versus use of the IP loose source routing option. Using IP headers
to encapsulate IP datagrams requires the unnecessary duplication of
several fields within the inner IP header; it is possible to save
some additional space by specifying a new encapsulation mechanism
that eliminates the duplication. The scheme outlined here comes from
the Mobile IP Working Group (in earlier Internet Drafts), and is
similar to that which had been defined in [2].
カプセル化の利点 対 IP loose source routing option の使用の利点に関係
する審議について、[4] を参照しなさい。IP datagrams をカプセル化する IP
headers を使用することは、内側の IP header のいくつかの fields の不必
要な複製を必要とする; 複製を見積もる新しいカプセル化メカニズムを特定す
ることにより、ある追加の空間を取っておくことは可能である。ここで概要を
述べられる方法は、(初期の Internet Drafts での) Mobile IP Working
Group から来ていて、[2] で定義されているものと同じようである。
-------------------------------------------------------------------------
3. Minimal Encapsulation
3. 最小のカプセル化
A minimal forwarding header is defined for datagrams which are not
fragmented prior to encapsulation. Use of this encapsulating method
is optional. Minimal encapsulation MUST NOT be used when an original
datagram is already fragmented, since there is no room in the minimal
forwarding header to store fragmentation information. To encapsulate
an IP datagram using minimal encapsulation, the minimal forwarding
header is inserted into the datagram, as follows:
minimal forwarding header は、カプセル化より前に分割されない datagram
について定義される。このカプセル化する方法の使用は、option である。も
ともとの datagram が既に分割されている時、分割情報を保存する minimal
forwarding header の場所がないので、最小のカプセル化は決して使用されて
はならない (MUST NOT)。最小カプセル化を使用して IP datagram をカプセル
化するために、minimal forwarding header は、次の通りに datagram に挿入
される:
+---------------------------+ +---------------------------+
| | | |
| IP Header | | Modified IP Header |
| | | |
+---------------------------+ ====> +---------------------------+
| | | Minimal Forwarding Header |
| | +---------------------------+
| IP Payload | | |
| | | |
| | | IP Payload |
+---------------------------+ | |
| |
+---------------------------+
The IP header of the original datagram is modified, and the minimal
forwarding header is inserted into the datagram after the IP header,
followed by the unmodified IP payload of the original datagram (e.g.,
transport header and transport data). No additional IP header is
added to the datagram.
option である datagram の IP header は変更され、minimal forwarding
header は、もともとの datagram の変更されない IP payload (たとえば、
transport header と transport data) により続けられる、IP header の後の
datagram に挿入される。追加の IP header は、datagram に追加されない。
In encapsulating the datagram, the original IP header [6] is modified
as follows:
datagram のカプセル化で、もともとの IP header [6] は、次の通りに変更さ
れる:
- The Protocol field in the IP header is replaced by protocol
number 55 for the minimal encapsulation protocol.
- IP header の Protocol field は、最小カプセル化 protocol のための
protocol number 55 に置き換えられる。
- The Destination Address field in the IP header is replaced by the
IP address of the exit point of the tunnel.
- IP header の Destination Address field は、tunnel 出口の IP アドレ
スに置き換えられる。
- If the encapsulator is not the original source of the datagram,
the Source Address field in the IP header is replaced by the IP
address of the encapsulator.
- もし encapsulator が datagram のもともとの source でないなら、IP
header の Source Address field は、encapsulator の IP アドレスによ
り置き換えられる。
- The Total Length field in the IP header is incremented by the
size of the minimal forwarding header added to the datagram.
This incremental size is either 12 or 8 octets, depending on
whether or not the Original Source Address Present (S) bit is set
in the forwarding header.
- IP header の Total Length field は、datagram に追加される最小の
forwad する header のサイズにより増やされる。この増加のサイズは、
Original Source Address Present (S) bit が forward する header に
セットされるかどうかに依存して、12 もしくは 8 octets どちらかであ
る。
- The Header Checksum field in the IP header is recomputed [6] or
updated to account for the changes in the IP header described
here for encapsulation.
- IP header の Header Checksum field は、カプセル化のためにここで記
述される IP header の変更を明らかにするために、再計算 [6] されるか
更新される。
Note that unlike IP-in-IP encapsulation [4], the Time to Live
(TTL) field in the IP header is not modified during encapsulation;
if the encapsulator is forwarding the datagram, it will decrement
the TTL as a result of doing normal IP forwarding. Also, since
the original TTL remains in the IP header after encapsulation,
hops taken by the datagram within the tunnel are visible, for
example, to "traceroute".
IP 内の IP カプセル化 [4] と違って、IP header の Time to Live (TTL)
field は、カプセル化の間変更されない; もし encapsulator が datagram
を forwad するなら、通常の IP forwarding をおこなう結果として TTL を
減らす。また、もともとの TTL はカプセル化の後の IP header のままであ
るので、tunnel 内部の datagram により得られる hops は明らかである。た
とえば、"traceroute" にそのまま適用できる。
The format of the minimal forwarding header is as follows:
minimal forwarding header の形式は、次の通りである:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol |S| reserved | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (if present) Original Source Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| プロトコル |S| 予約 | ヘッダチェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| もともとの終点アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (もしあるなら) もともとの始点アドレス :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol
Copied from the Protocol field in the original IP header.
もともとの IP header の Protocol field から copy される。
Original Source Address Present (S)
0 The Original Source Address field is not present. The
length of the minimal tunneling header in this case is
8 octets.
0 Original Source Address field は、この header にない。この
case での最小 tunneling header 長は、8 octets である。
1 The Original Source Address field is present. The
length of the minimal tunneling header in this case is
12 octets.
1 Original Source Address field が、この header にある。この
case での最小 tunneling header 長は、12 octets である。
reserved
Sent as zero; ignored on reception.
zero として送信される; 受信で無視される。
Header Checksum
The 16-bit one's complement of the one's complement sum of all
16-bit words in the minimal forwarding header. For purposes of
computing the checksum, the value of the checksum field is 0.
The IP header and IP payload (after the minimal forwarding
header) are not included in this checksum computation.
minimal forwading header でのすべての 16-bit の 1 の補数合計の 1
の補数。checksum を計算する目的のために、(最初) checksum field
の値は 0 にしておく。IP header と (minimal forwarding header の
後の) IP payload は、この checksum 計算に含まれない。
Original Destination Address
Copied from the Destination Address field in the original IP
header.
もともとの IP header の Destination Address field から copy され
る。
Original Source Address
Copied from the Source Address field in the original IP header.
This field is present only if the Original Source Address
Present (S) bit is set.
もともとの IP header の Source Address field から copy される。
もし Original Source Address Present (S) bit がセットされるなら
そのときのみ、この field はある。
When decapsulating a datagram, the fields in the minimal forwarding
header are restored to the IP header, and the forwarding header is
removed from the datagram. In addition, the Total Length field in
the IP header is decremented by the size of the minimal forwarding
header removed from the datagram, and the Header Checksum field in
the IP header is recomputed [6] or updated to account for the changes
to the IP header described here for decapsulation.
datagram のカプセル化を外す時、minimal forwarding header の field は
IP header へ元へ戻す。そして forwarding header は、datagram から取り除
かれる。さらに、IP header の Total Length field は、datagram から取り
除かれる minimal forwarding header のサイズだけ減らされる。そして IP
header の Header Checksum field は、カプセル化を外すため、ここで記述さ
れる IP header の変更を明らかにするために、再計算 [6] されるか更新され
る。
The encapsulator may use existing IP mechanisms appropriate for
delivery of the encapsulated payload to the tunnel exit point. In
particular, use of IP options are allowed, and use of fragmentation
is allowed unless the "Don't Fragment" bit is set in the IP header.
This restriction on fragmentation is required so that nodes employing
Path MTU Discovery [3] can obtain the information they seek.
encapsulator は、tunnel 出口にカプセル化された payload の配送のために
存在する適した IP メカニズムを使用するかもしれない。特に、もし IP
header に "Don't Fragment" bit がセットされなければ、IP options の使用
は許され、分割の使用は許される。Path MTU Discovery [3] を使用する
nodes が捜す情報を得るように、分割のこの制限は必要とされる。
-------------------------------------------------------------------------
4. Routing Failures
4. 経路制御失敗
The use of any encapsulation method for routing purposes brings with
it increased susceptibility to routing loops. To cut down the
danger, a router should follow the same procedures outlined in [4].
経路制御目的のための何らかのカプセル化の方法の使用は、routing loop を
受けやすいことを増加させることでいっぱいである。危険を縮小するために、
router は、[4] で概要を述べられた同じ手続きに従うべきである。
-------------------------------------------------------------------------
5. ICMP Messages from within the Tunnel
5. トンネル内からの ICMP メッセージ
ICMP messages are to be handled as specified in [4], including the
maintenance of tunnel "soft state".
ICMP messages は、tunnel "soft state" の維持を含んで、[4] で特定された
ように扱われることである。
-------------------------------------------------------------------------
6. Security Considerations
6. セキュリティに関する考察
Security considerations are not addressed in this document, but are
generally similar to those outlined in [4].
セキュリティに関する考察は、この文書でいわれない。しかし [4] で概要を
述べられたものに、通例同様である。
-------------------------------------------------------------------------
7. Acknowledgements
7. 謝辞
The original text for much of Section 3 was taken from the Mobile IP
draft [1]. Thanks to David Johnson for improving consistency and
making many other improvements to the draft.
Section 3 の重要なものについてのもともとの text は、Mobile IP draft
[1] から得られた。一貫性の改善と draft への多くの他の改良をおこなった
David Johnson に感謝する。
-------------------------------------------------------------------------
References
参考文献
[1] Perkins, C., Editor, "IPv4 Mobility Support", Work in Progress,
May 1995.
[2] David B. Johnson. Scalable and Robust Internetwork Routing
for Mobile Hosts. In Proceedings of the 14th International
Conference on Distributed Computing Systems, pages 2--11, June
1994.
[3] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[4] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[5] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
October 1996.
[6] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
September 1981.
-------------------------------------------------------------------------
Author's Address
著者のアドレス
Questions about this memo can be directed to:
このメモについての質問は、(次のところに) 向けられることが出来る:
Charles Perkins
Room H3-D34
T. J. Watson Research Center
IBM Corporation
30 Saw Mill River Rd.
Hawthorne, NY 10532
Work: +1-914-784-7350
Fax: +1-914-784-6205
EMail: perk@watson.ibm.com
The working group can be contacted via the current chair:
working group は、現在の議長経由で連絡されることが出来る:
Jim Solomon
Motorola, Inc.
1301 E. Algonquin Rd.
Schaumburg, IL 60196
Work: +1-847-576-2753
EMail: solomon@comm.mot.com
一覧
スポンサーリンク
