RFC2003 日本語訳
2003 IP Encapsulation within IP. C. Perkins. October 1996. (Format: TXT=30291 bytes) (Status: PROPOSED STANDARD)
RFC一覧
英語原文
Network Working Group C. Perkins
Request for Comment: 2003 IBM
Category: Standards Track October 1996
IP Encapsulation within IP
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.
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 serve a variety of purposes, such as delivery of a datagram to a
mobile node using Mobile IP.
この文書は、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.
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 based on the (network part of the) IP
Destination Address field in the original IP header. Once the
encapsulated datagram arrives at this intermediate destination node,
it is decapsulated, yielding the original IP datagram, which is then
delivered to the destination indicated by the original Destination
Address field. This use 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
"endpoints" of the tunnel.
この文書は、IP datagram 内側に IP datagram が (payload として運ばれて)
カプセル化される (ことによる) 方法を明細に述べる。もともとの IP header
内の IP Destination Address field (の network 部分) に基づいて別の方法
で選択されない中間終点に datagram を配送することにより、カプセル化は
datagram について通常の IP routing を変えるための方法として、提案され
る。いったん、カプセル化された datagram がこの中間終点 node に到着する
と、もともとの IP datagram を生むようにカプセル化が外れ、それはそれか
ら、もともとの Destination Address field により指し示された終点に配送
される。datagram のカプセル化とカプセル化を外すことの使用は、しばしば
datagram を "tunneling (トンネルすること)" として参照される。そして、
encapsulator (カプセル化するもの) と decapsulator (カプセル化を外すも
の) は、それから tunnel の "endpoints" であると考えられる。
In the most general tunneling case we have
最も多くの全体的な tunneling case で、
source ---> encapsulator --------> decapsulator ---> destination
始点 --> カプセル化するもの --> カプセル化を外すもの --> 終点
with the source, encapsulator, decapsulator, and destination being
separate nodes. The encapsulator node is considered the "entry
point" of the tunnel, and the decapsulator node is considered the
"exit point" of the tunnel. There in general may be multiple
source-destination pairs using the same tunnel between the
encapsulator and decapsulator.
われわれは別々の node である始点、encapsulator (カプセル化するもの)、
decapsulator (カプセル化を外すもの)、と終点をもつ上の図を持つ。
encapsulator node は、tunnel の "entry point (入口点)" と考えられる。
そして decapsulator node は、tunnel の "exit point (出口点)" と考えら
れる。一般に encapsulator と decapsulator の間に同じ tunnel を使用する
複数の source-destination pairs がある。
-------------------------------------------------------------------------
2. Motivation
2. 動機
The Mobile IP working group has specified the use of encapsulation as
a way to deliver datagrams 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 [8]. The use of
encapsulation may also be desirable 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
に datagram を配送する方法としてカプセル化の使用を明細に述べる。ここで
agent は、home から離れて現在の位置に mobile node へ、一般におこなわれ
ている方法により局所的に datagram を配送することが出来る [8]。カプセル
化の使用はまた、datagram がその最終の終点に配送されることによる経路に
IP datagram の始点 (や中間の router) が影響を与えなければならないとき
はいつでも、望ましいかもしれない。カプセル化の他の可能な application
は、multicasting、優先権のある請求、選択された security 属性を持つ経路
の選択、と全体的な policy 経路制御を含む。
It is generally true that encapsulation and the IP loose source
routing option [10] can be used in similar ways to affect the routing
of a datagram, but there are several technical reasons to prefer
encapsulation:
カプセル化と IP loose (ゆるやかな) source routing option [10] は、
datagram の routing に影響を与える同じような方法で使用されることが出来
るのは、通例ほんとうである。しかし、カプセル化を好む技術的な理由がいく
つかある:
- There are unsolved security problems associated with the use of
the IP source routing options.
- IP source routing options の使用に関連された未解決の security 問題
がある。
- Current Internet routers exhibit performance problems when
forwarding datagrams that contain IP options, including the IP
source routing options.
- IP source routing options を含んだ IP options を含む datagrams を
forward する時、現在の Internet routers は、パフォーマンス問題を示
す。
- Many current Internet nodes process IP source routing options
incorrectly.
- 多くの現在の Internet nodes は、間違えて IP source routing options
を処理する。
- Firewalls may exclude IP source-routed datagrams.
- firewalls は、IP source-routed datagrams を除外するかもしれない。
- Insertion of an IP source route option may complicate the
processing of authentication information by the source and/or
destination of a datagram, depending on how the authentication is
specified to be performed.
- IP source route option の挿入は、どのように認証がおこなわれるかを
特定されるかに依存して、datagram の始点 and/or 終点による認証情報
の処理を複雑にするかもしれない。
- It is considered impolite for intermediate routers to make
modifications to datagrams which they did not originate.
- 始まりでない datagrams に変更をもたらす中間の routers について失礼
だと考えられる。
These technical advantages must be weighed against the disadvantages
posed by the use of encapsulation:
これら技術的な長所は、カプセル化の使用により提出される不利に対して、よ
く考えられなければならない:
- Encapsulated datagrams typically are larger than source routed
datagrams.
- カプセル化された datagrams は、典型的に soure routed datagrams よ
り大きい。
- Encapsulation cannot be used unless it is known in advance that
the node at the tunnel exit point can decapsulate the datagram.
- もし前もって tunnel 出口での node が datagram のカプセル化を外すこ
とが出来ることを知られなければ、カプセル化は使用されることが出来な
い。
Since the majority of Internet nodes today do not perform well when
IP loose source route options are used, the second technical
disadvantage of encapsulation is not as serious as it might seem at
first.
IP loose source route options が使用される時、今日の Internet nodes の
大部分はうまく (その処理を) おこなわないので、カプセル化の二番目の技術
的な不利は、最初に思われたのと同じぐらい重要ではない。
-------------------------------------------------------------------------
3. IP in IP Encapsulation
3. IP の中の IP カプセル化
To encapsulate an IP datagram using IP in IP encapsulation, an outer
IP header [10] is inserted before the datagram's existing IP header,
as follows:
IP の中の IP カプセル化を使用して IP datagram をカプセル化するために、
outer (外側の) IP header [10] は、次のとおりに datagram の存在する IP
header の前に挿入される:
+---------------------------+
| |
| Outer IP Header |
| |
+---------------------------+ +---------------------------+
| | | |
| IP Header | | IP Header |
| | | |
+---------------------------+ ====> +---------------------------+
| | | |
| | | |
| IP Payload | | IP Payload |
| | | |
| | | |
+---------------------------+ +---------------------------+
The outer IP header Source Address and Destination Address identify
the "endpoints" of the tunnel. The inner IP header Source Address
and Destination Addresses identify the original sender and recipient
of the datagram, respectively. The inner IP header is not changed by
the encapsulator, except to decrement the TTL as noted below, and
remains unchanged during its delivery to the tunnel exit point. No
change to IP options in the inner header occurs during delivery of
the encapsulated datagram through the tunnel. If need be, other
protocol headers such as the IP Authentication header [1] may be
inserted between the outer IP header and the inner IP header. Note
that the security options of the inner IP header MAY affect the
choice of security options for the encapsulating (outer) IP header.
外側 IP header の Sourece Address と Destination Address は、tunnel の
"endpoints" を識別する。内側 IP header の Source Address と
Destination Address は、それぞれ datagram のもともとの送信者と受信者を
識別する。下で言及されるように TTL を減らすことを除いて、内側 IP
header は encapsulator により変更されず、tunnel 出口への配送の間、変更
されないままである。内側 IP header の IP option への変更は、tunnel を
通してカプセル化された datagram の配送の間、起こらない。もし必要がある
なら、IP Authentication header [1] のような他の protocol headers が、
外側の IP header と内側の IP header の間に挿入されるかもしれない。内側
IP header の security options は、カプセル化する (外側の) IP header に
ついて security options の選択に影響するかもしれない (MAY) ことに注意
しなさい。
3.1. IP Header Fields and Handling
3.1. IP ヘッダフィールドとその扱い
The fields in the outer IP header are set by the encapsulator as
follows:
外側 IP header の fields は、次の通りに encapsulator によりセットされ
る:
Version
4
IHL
The Internet Header Length (IHL) is the length of the outer IP
header measured in 32-bit words [10].
Internet Header Length (IHL) は、32-bit word で測られた外側 IP
header の長さである [10]。
TOS
The Type of Service (TOS) is copied from the inner IP header.
Type of Service (TOS) は、内側 IP header からコピーされる。
Total Length
The Total Length measures the length of the entire encapsulated
IP datagram, including the outer IP header, the inner IP
header, and its payload.
Total Length は、外側の IP header、内側の IP header、とその
payload を含んだ、全体のカプセル化された IP datagram の長さを測
る。
Identification, Flags, Fragment Offset
These three fields are set as specified in [10]. However, if
the "Don't Fragment" bit is set in the inner IP header, it MUST
be set in the outer IP header; if the "Don't Fragment" bit is
not set in the inner IP header, it MAY be set in the outer IP
header, as described in Section 5.1.
これら三つの fields は、[10] で特定されたとしてセットされる。し
かしながら、もし "Don't Fragment" bit が内側の IP header でセッ
トされるなら、外側の IP header に DF bit をセットしなければなら
ない (MUST); もし "Don't Fragment" bit が内側の IP header にセッ
トされないなら、Section 5.1 で記述されたとして、外側の IP header
にセットされるかもしれない (MAY)。
Time to Live
The Time To Live (TTL) field in the outer IP header is set to a
value appropriate for delivery of the encapsulated datagram to
the tunnel exit point.
外側 IP header の Time To Live (TTL) field は、tunnel 出口へカプ
セル化された datagram の配送するために、適した値にセットされる。
Protocol
4
Header Checksum
The Internet Header checksum [10] of the outer IP header.
外側 IP header の Internet Header checksum [10]。
Source Address
The IP address of the encapsulator, that is, the tunnel entry
point.
encapsulator の IP address、すなわち tunnel の入口。
Destination Address
The IP address of the decapsulator, that is, the tunnel exit
point.
decapsulator の IP address、すなわち tunnel の出口。
Options
Any options present in the inner IP header are in general NOT
copied to the outer IP header. However, new options specific
to the tunnel path MAY be added. In particular, any supported
types of security options of the inner IP header MAY affect the
choice of security options for the outer header. 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 header にあるなんらかの options は、一般に外側 IP header
にコピーされない (NOT)。しかしながら、tunnel 経路に明確な新しい
options は、追加されるかもしれない (MAY)。特に、内側 IP header
security option の何らかのサポートされた type は、外側 IP header
について security options の選択に影響するかもしれない (MAY)。
tunnel のために選択される options や security headers へのそのよ
うな options の 1 対 1 mapping があることは期待されない。
When encapsulating a datagram, the TTL in the inner IP header is
decremented by one if the tunneling is being done as part of
forwarding the datagram; otherwise, the inner header TTL is not
changed during encapsulation. If the resulting TTL in the inner IP
header is 0, the datagram is discarded and an ICMP Time Exceeded
message SHOULD be returned to the sender. An encapsulator MUST NOT
encapsulate a datagram with TTL = 0.
datagram をカプセル化する時、もし tunneling が datagram を forwarding
の一部分としておこなわれるのなら、内側 IP header の TTL は一つ減らされ
る; もしそうでなければ、内側 IP header の TTL は、カプセル化の間変更さ
れない。もし内側 IP header の TTL の結果が 0 なら、datagram は捨てられ
ICMP Time Exceeded messages が送信側に返されるべきである (SHOULD)。
encapsulator は、TTL = 0 を持つ datagram を決してカプセル化してはなら
ない (MUST NOT)。
The TTL in the inner IP header is not changed when decapsulating.
If, after decapsulation, the inner datagram has TTL = 0, the
decapsulator MUST discard the datagram. If, after decapsulation, the
decapsulator forwards the datagram to one of its network interfaces,
it will decrement the TTL as a result of doing normal IP forwarding.
See also Section 4.4.
カプセル化を外すとき、内側 IP header の TTL は変更されない。もしカプセ
ル化を外した後で内側の datagram が TTL = 0 を持っているなら、
decapsulator は datagram を捨てなければならない (MUST)。もしカプセル化
を外した後で decapsulator が network interface に一つに datagram を
forward するなら、通常の IP forwarding の結果として TTL を (一つ) 減ら
すだろう。Section 4.4 もまた参照しなさい。
The encapsulator may use any existing IP mechanisms appropriate for
delivery of the encapsulated payload to the tunnel exit point. In
particular, use of IP options is allowed, and use of fragmentation is
allowed unless the "Don't Fragment" bit is set in the inner IP
header. This restriction on fragmentation is required so that nodes
employing Path MTU Discovery [7] can obtain the information they
seek.
encapsulator は、tunnel 出口にカプセル化された payload の配送のために
何らかの存在する適した IP 機構を使用するかもしれない。特に、もし
"Don't Fragment" bit が内側 IP header にセットされなければ、IP options
の使用は許されるし分割の使用は許される。Path MTU Discovery [7] を使用
する nodes が捜す情報を得るように、分割のこの制限は必要とされる。
3.2. Routing Failures
3.2. 経路制御失敗
Routing loops within a tunnel are particularly dangerous when they
cause datagrams to arrive again at the encapsulator. Suppose a
datagram arrives at a router for forwarding, and the router
determines that the datagram has to be encapsulated before further
delivery. Then:
経路制御 loops が datagrams に encapsulator で再到着させる時、tunnel
内で経路制御 loops は特に危険である。datagram が forwarding のために
router に到着し、router は datagram がさらに進んで配送する前にカプセル
化されなければならないと決定する、と仮定しなさい。それから:
- If the IP Source Address of the datagram matches the router's own
IP address on any of its network interfaces, the router MUST NOT
tunnel the datagram; instead, the datagram SHOULD be discarded.
- もし datagram の IP Source Address が network interface の何かに
router 自身の IP address に match したなら、router は決して
datagram を tunnel してはならない (MUST NOT); 挿入された datagram
は捨てられるべきである (SHOULD)。
- If the IP Source Address of the datagram matches the IP address
of the tunnel destination (the tunnel exit point is typically
chosen by the router based on the Destination Address in the
datagram's IP header), the router MUST NOT tunnel the datagram;
instead, the datagram SHOULD be discarded.
- もし datagram の IP Source Address が tunnel 終点の IP address に
match するなら (tunnel 出口は典型的に、datagram の IP header 内の
Destination Address に基づく router により選択される)、router は決
して datagram を tunnel してはならない (MUST NOT); 挿入された
datagram は捨てられるべきである (SHOULD)。
See also Section 4.4.
Section 4.4 も参照しなさい。
-------------------------------------------------------------------------
4. ICMP Messages from within the Tunnel
4. トンネル内からの ICMP メッセージ
After an encapsulated datagram has been sent, the encapsulator may
receive an ICMP [9] message from any intermediate router within the
tunnel other than the tunnel exit point. The action taken by the
encapsulator depends on the type of ICMP message received. When the
received message contains enough information, the encapsulator MAY
use the incoming message to create a similar ICMP message, to be sent
to the originator of the original unencapsulated IP datagram (the
original sender). This process will be referred to as "relaying" the
ICMP message from the tunnel.
カプセル化された datagram が送信された後で、encapsulator は tunnel 出
口とは違った tunnel 内のなんらかの中間 router から ICMP [9] messages
を受信するかもしれない。encapsulator により得られる実行は、受信された
ICMP message の type に依存する。受信された message が十分な情報を含ん
でいる時、encapsulator は、もともとのカプセル化されていない IP
datagram の originator (もともとの送信者) に送信されるため、同じような
ICMP message を作り出すために、入ってくる message を使用するかもしれな
い (MAY)。この process は、tunnel から ICMP message を "relaying" とし
て参照される。
ICMP messages indicating an error in processing a datagram include a
copy of (a portion of) the datagram causing the error. Relaying an
ICMP message requires that the encapsulator strip off the outer IP
header from this returned copy of the original datagram. For cases
in which the received ICMP message does not contain enough data to
relay the message, see Section 5.
処理する datagram の error を指し示している ICMP messages は、error を
引き起こした datagram (の一部分) の copy を含む。ICMP message を relay
することは、encapsulator がもともとの datagram のこの返された copy か
ら外側 IP header を取り外すことを要求する。受信された ICMP message が
message を relay するための十分な data を含んでいない case について、
Section 5 を参照しなさい。
4.1. Destination Unreachable (Type 3)
4.1. 終点到達不可 (type 3)
ICMP Destination Unreachable messages are handled by the encapsulator
depending upon their Code field. The model suggested here allows the
tunnel to "extend" a network to include non-local (e.g., mobile)
nodes. Thus, if the original destination in the unencapsulated
datagram is on the same network as the encapsulator, certain
Destination Unreachable Code values may be modified to conform to the
suggested model.
ICMP Destination Unreachable messages は、messages の code field に依
存して encapsulator により扱われる。ここで提案される model は、tunnel
に local でない (たとえば、mobile) nodes を含む network を "extend (拡
張する)" のを許す。したがって、もしカプセル化されていない datagram の
もともとの終点が encapsulator と同じ network であるなら、確実な
Destination Unreachable Code 値は、提案された model に従うために変更さ
れるかもしれない。
Network Unreachable (Code 0)
ネットワーク到達不可 (code 0)
An ICMP Destination Unreachable message SHOULD be returned
to the original sender. If the original destination in
the unencapsulated datagram is on the same network as the
encapsulator, the newly generated Destination Unreachable
message sent by the encapsulator MAY have Code 1 (Host
Unreachable), since presumably the datagram arrived at the
correct network and the encapsulator is trying to create the
appearance that the original destination is local to that
network even if it is not. Otherwise, if the encapsulator
returns a Destination Unreachable message, the Code field MUST
be set to 0 (Network Unreachable).
ICMP Destination Unreachable message は、もともとの送信者に返さ
れるべきである (SHOULD)。もしカプセル化されていない datagram の
もともとの終点が encapsulator と同じ network 上であるなら、たぶ
ん正しい network で到着された datagram と、encapsulator はもとも
との終点がその network に local であること (たとえそうでないにし
ても) の見せかけを作りだそうとがんばるので、encapsulator により
送信されるあらためて生成された Destination Unreachable message
は、Code 1 (Host Unreachable) を持つかもしれない (MAY)。別の方法
で、もし encapsulator が Destination Unreachable message を返す
なら、Code field は 0 (Network Unreachable) にセットされなければ
ならない (MUST)。
Host Unreachable (Code 1)
ホスト到達不可 (code 1)
The encapsulator SHOULD relay Host Unreachable messages to the
sender of the original unencapsulated datagram, if possible.
encapsulator は、出来るなら、もともとのカプセル化されていない
datagram の送信者に Host Unreachable messages を relay すべきで
ある (SHOULD)。
Protocol Unreachable (Code 2)
プロトコル到達不可 (code 2)
When the encapsulator receives an ICMP Protocol Unreachable
message, it SHOULD send a Destination Unreachable message with
Code 0 or 1 (see the discussion for Code 0) to the sender of
the original unencapsulated datagram. Since the original
sender did not use protocol 4 in sending the datagram, it would
be meaningless to return Code 2 to that sender.
encapsulator が ICMP Protocol Unreachable message を受信した時、
もともとのカプセル化されていない datagram の送信者に Code 0 また
は 1 (Code 0 についての審議を参照しなさい) を持つ Destination
Unreachable message を送信すべきである (SHOULD)。もともとの送信
者は送信している datagram に protocol 4 を使用しないので、その送
信者に Code 2 を返すことは無意味だろう。
Port Unreachable (Code 3)
ポート到達不可 (code 3)
This Code should never be received by the encapsulator, since
the outer IP header does not refer to any port number. It MUST
NOT be relayed to the sender of the original unencapsulated
datagram.
外側 IP header は何らかの port number を参照しないので、この
Code は、encapsulator により決して受信されるべきでない。もともと
のカプセル化されていない datagram の送信者に決して relay されて
はならない (MUST NOT)。
Datagram Too Big (Code 4)
データグラムが大きすぎる (code 4)
The encapsulator MUST relay ICMP Datagram Too Big messages to
the sender of the original unencapsulated datagram.
encapsulator は、もともとのカプセル化されていない datagram の送
信者に ICMP Datagram Too Big messages を relay しなければならな
い (MUST)。
Source Route Failed (Code 5)
ソースルート失敗 (code 5)
This Code SHOULD be handled by the encapsulator itself.
It MUST NOT be relayed to the sender of the original
unencapsulated datagram.
この Code は、encapsulator それ自身により扱われるべきである
(SHOULD)。もともとのカプセル化されていない datagram の送信者に決
して relay されてはならない (MUST NOT)。
4.2. Source Quench (Type 4)
4.2. 始点抑制 (type 4)
The encapsulator SHOULD NOT relay ICMP Source Quench messages to the
sender of the original unencapsulated datagram, but instead SHOULD
activate whatever congestion control mechanisms it implements to help
alleviate the congestion detected within the tunnel.
encapsulator は、もともとのカプセル化されていない datagram の送信者に
ICMP Source Quench messages を送信すべきでない (SHOULD NOT)。しかしそ
のかわりに encapsulator は、tunnel 内で発見された輻輳を軽くするのを助
けるために、encapsulator が実装するどんな輻輳制御機構も活性化すべきで
ある (SHOULD)。
4.3. Redirect (Type 5)
4.3. リダイレクト (type 5)
The encapsulator MAY handle the ICMP Redirect messages itself. It
MUST NOT not relay the Redirect to the sender of the original
unencapsulated datagram.
encapsulator は、ICMP Redirect messages 自身を扱うかもしれない (MAY)。
もともとのカプセル化されていない datagram の送信者に決して relay して
はならない (MUST NOT)。
4.4. Time Exceeded (Type 11)
4.4. 時間超過 (type 11)
ICMP Time Exceeded messages report (presumed) routing loops within
the tunnel itself. Reception of Time Exceeded messages by the
encapsulator MUST be reported to the sender of the original
unencapsulated datagram as Host Unreachable (Type 3, Code 1). Host
Unreachable is preferable to Network Unreachable; since the datagram
was handled by the encapsulator, and the encapsulator is often
considered to be on the same network as the destination address in
the original unencapsulated datagram, then the datagram is considered
to have reached the correct network, but not the correct destination
node within that network.
ICMP Time Exceeded messages は、tunnel 自身内で routing loops を報告
(推定) する。encapsulator による Time Exceeded messages の受信は、Host
Unreachable (Type 3, Code 1) としてもともとのカプセル化されていない
datagram の送信者に報告されなければならない (MUST)。Host Unreachable
は、Network Unreachable より望ましい; datagram は encapsulator により
扱われ、encapsulator はしばしばもともとのカプセル化されていない
datagram の終点アドレスと同じ network 上であると考えられるので、それか
ら datagram は正しい network に届くと考えられる。しかしその network 内
の正しい終点 node ではない。
4.5. Parameter Problem (Type 12)
4.5. パラメータ問題 (type 12)
If the Parameter Problem message points to a field copied from the
original unencapsulated datagram, the encapsulator MAY relay the ICMP
message to the sender of the original unencapsulated datagram;
otherwise, if the problem occurs with an IP option inserted by the
encapsulator, then the encapsulator MUST NOT relay the ICMP message
to the original sender. Note that an encapsulator following
prevalent current practice will never insert any IP options into the
encapsulated datagram, except possibly for security reasons.
もし Parameter Problem message がもともとのカプセル化されていない
datagram から copy された field を指しているなら、encapsulator はもと
もとのカプセル化されていない datagram の送信者に ICMP message を relay
するかもしれない (MAY); 別の方法で、もし問題が encapsulator により挿入
された IP option で起こるなら、それから encapsulator はもともとの送信
者に ICMP message を決して relay してはならない (MUST NOT)。ひょっとし
たら security 理由の点を除いて、普及している現在の実行のあとで、
encapsulator は、カプセル化される datagram に何らかの IP options を決
して挿入しないことに注意しなさい。
4.6. Other ICMP Messages
4.6. 他の ICMP メッセージ
Other ICMP messages are not related to the encapsulation operations
described within this protocol specification, and should be acted on
by the encapsulator as specified in [9].
他の ICMP messages は、この protocol 仕様書内で記述されたカプセル化操
作に関連されなく、[9] で特定されたとして、encapsulator により作用され
るべきである。
-------------------------------------------------------------------------
5. Tunnel Management
5. トンネル管理
Unfortunately, ICMP only requires IP routers to return 8 octets (64
bits) of the datagram beyond the IP header. This is not enough to
include a copy of the encapsulated (inner) IP header, so it is not
always possible for the encapsulator to relay the ICMP message from
the interior of a tunnel back to the original sender. However, by
carefully maintaining "soft state" about tunnels into which it sends,
the encapsulator can return accurate ICMP messages to the original
sender in most cases. The encapsulator SHOULD maintain at least the
following soft state information about each tunnel:
不運にも、ICMP は IP routers に IP header の次の部分である datagram
の 8 octets (64 bits) を返すことをただ命じる。これは、カプセル化された
(内側の) IP header の copy を含むのに十分でなく、それで encapsulator
がもともとの送信者に、もとへ tunnel の内部から ICMP message を relay
するのは、いつも可能でない。しかしながら、router が送信する先の tunnel
について注意深く "soft state (柔らかな状態)" を維持することにより、
encapsulator は大部分の case でもともとの送信者に正確な ICMP messages
を返すことが出来る。encapsulator は、tunnel について次の soft state を
少なくとも維持すべきである (SHOULD):
- MTU of the tunnel (Section 5.1)
- TTL (path length) of the tunnel
- Reachability of the end of the tunnel
- tunnel の MTU (Section 5.1)
- tunnel の TTL (経路長)
- tunnel 終点の到達性
The encapsulator uses the ICMP messages it receives from the interior
of a tunnel to update the soft state information for that tunnel.
ICMP errors that could be received from one of the routers along the
tunnel interior include:
encapsulator は、tunnel のための soft state 情報を更新するために、
tunnel 内部から encapsulator が受信した ICMP messages を使用する。
tunnel 内部を沿った routers の一つから受信されることが出来る ICMP
errors は、次のものを含む:
- Datagram Too Big
- Time Exceeded
- Destination Unreachable
- Source Quench
- データグラムが大きすぎる
- 時間超過
- 終点到達不可
- 始点抑制
When subsequent datagrams arrive that would transit the tunnel, the
encapsulator checks the soft state for the tunnel. If the datagram
would violate the state of the tunnel (for example, the TTL of the
new datagram is less than the tunnel "soft state" TTL) the
encapsulator sends an ICMP error message back to the sender of the
original datagram, but also encapsulates the datagram and forwards it
into the tunnel.
あとの tunnel を通る datagrams が到着した時、encapsulator は tunnel の
soft state を check する。もし datagram が tunnel の状態を乱す (たとえ
ば、新しい datagram の TTL が tunnel "soft state" TTL より小さい) なら
encapsulator は、datagram をカプセル化もしてそれを tunnel に forward
しなければ、もともとの datagram の送信者に ICMP error message を送信す
る。
Using this technique, the ICMP error messages sent by the
encapsulator will not always match up one-to-one with errors
encountered within the tunnel, but they will accurately reflect the
state of the network.
この技術の使用で、encapsulator により送信される ICMP error messages は
常に tunnel 内でカプセル化された errors と 1 対 1 対応しないだろう。し
かし正確に network の状態に反映するだろう。
Tunnel soft state was originally developed for the IP Address
Encapsulation (IPAE) specification [4].
tunnel soft state は、もとは IP Address Encapsulation (IPAE) 仕様書
[4] のために開発された。
5.1. Tunnel MTU Discovery
5.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 Datagram Too Big (Type 3, Code 4) messages reported to the
encapsulator. To support sending nodes which use Path MTU Discovery,
all encapsulator implementations MUST support Path MTU Discovery [5,
7] soft state within their tunnels. In this particular application,
there are several advantages:
Don't Fragment bit がもともとの送信者によりセットされ、外側の IP
header に copy される時、tunnel のふさわしい MTU は encapsulator に報
告される ICMP Datagram Too Big (Type 3, Code 4) messages から学習され
るだろう。Path MTU Discovery を使用する送信する nodes をサポートするた
めに、すべての encapsulator 実装は、tunnels 内に Path MTU Discovery
[5, 7] soft state をサポートしなければならない (MUST)。この特定の適用
で、いくつかの利点がある:
- As a benefit of Path MTU Discovery within the tunnel, any
fragmentation which occurs because of the size of the
encapsulation header is performed only once after encapsulation.
This prevents multiple fragmentation of a single datagram, which
improves processing efficiency of the decapsulator and the
routers within the tunnel.
- tunnel 内の Path MTU Discovery の恩恵として、カプセル化 header の
サイズの理由で起こる何らかの分割は、カプセル化の後の一回のみ、おこ
なわれる。これはたった一つの datagram の複数の分割を防ぎ、そしてそ
れは tunnel 内部の decapsulator と routers の処理する効率を改善す
る。
- If the source of the unencapsulated datagram is doing Path MTU
Discovery, then it is desirable for the encapsulator to know
the MTU of the tunnel. Any ICMP Datagram Too Big messages from
within the tunnel are returned to the encapsulator, and as noted
in Section 5, it is not always possible for the encapsulator to
relay ICMP messages to the source of the original unencapsulated
datagram. By maintaining "soft state" about the MTU of the
tunnel, the encapsulator can return correct ICMP Datagram Too Big
messages to the original sender of the unencapsulated datagram to
support its own Path MTU Discovery. In this case, the MTU that
is conveyed to the original sender by the encapsulator SHOULD
be the MTU of the tunnel minus the size of the encapsulating
IP header. This will avoid fragmentation of the original IP
datagram by the encapsulator.
- もしカプセル化されていない datagram の始点が Path MTU Discovery を
するなら、それから encapsulator が tunnel の MTU を知ることは望ま
しい。tunnel 内部からどこからかの ICMP Datagram Too Big messages
が encapsulator に返されて、Section 5 で言及されるように、
encapsulator がもともとのカプセル化されていない datagram の始点に
ICMP messages を relay することはいつも可能ではない。 tunnel の
MTU について "soft state" を維持することにより、encapsulator はそ
の自分自身の Path MTU Discovery をサポートするために、カプセル化さ
れていない datagram のもともとの送信者に正しい ICMP Datagram Too
Big messages を返すことが出来る。この case で、encapsulator によっ
てもともとの送信者に伝えられる MTU は、カプセル化する IP header の
サイズを引いた tunnel の MTU であるべきである (SHOULD)。これは
encapsulator によるもともとの IP datagram の分割を避ける。
- If the source of the original unencapsulated datagram is
not doing Path MTU Discovery, it is still desirable for the
encapsulator to know the MTU of the tunnel. In particular, it is
much better to fragment the original datagram when encapsulating,
than to allow the encapsulated datagram to be fragmented.
Fragmenting the original datagram can be done by the encapsulator
without special buffer requirements and without the need to
keep reassembly state in the decapsulator. By contrast, if
the encapsulated datagram is fragmented, then the decapsulator
must reassemble the fragmented (encapsulated) datagram before
decapsulating it, requiring reassembly state and buffer space
within the decapsulator.
- もしもともとのカプセル化されていない datagram の始点が Path MTU
Discovery をしないなら、encapsulator が tunnel の MTU を知ることは
それでも望ましい。特に、カプセル化された datagram に分割されること
を許すよりも、カプセル化する時もともとの datagram を分割することが
非常によい。もともとの datagram を分割することは、特別の buffer 要
求と、再構成の状態を decapsulator にとどめておく必要なしに、
encapsulator によりおこなわれることが出来る。対比で、もしカプセル
化された datagram が分割されるなら、それから decapsulator はその
datagram のカプセル化を外す前に、decapsulator 内で再構成状態と
buffer 空間を要求して、分割された (そしてカプセル化された)
datagram を再構成しなければならない。
Thus, the encapsulator SHOULD normally do Path MTU Discovery,
requiring it to send all datagrams into the tunnel with the "Don't
Fragment" bit set in the outer IP header. However there are problems
with this approach. When the original sender sets the "Don't
Fragment" bit, the sender can react quickly to any returned ICMP
Datagram Too Big error message by retransmitting the original
datagram. On the other hand, suppose that the encapsulator receives
an ICMP Datagram Too Big message from within the tunnel. In that
case, if the original sender of the unencapsulated datagram had not
set the "Don't Fragment" bit, there is nothing sensible that the
encapsulator can do to let the original sender know of the error.
The encapsulator MAY keep a copy of the sent datagram whenever it
tries increasing the tunnel MTU, in order to allow it to fragment and
resend the datagram if it gets a Datagram Too Big response.
Alternatively the encapsulator MAY be configured for certain types of
datagrams not to set the "Don't Fragment" bit when the original
sender of the unencapsulated datagram has not set the "Don't
Fragment" bit.
したがって encapsulator は、外側の IP header に "Don't Fragment" bit
をセットしたすべての datagram を tunnel に送信することを要求して、通常
Path MTU Discovery をすべきである (SHOULD)。しかしながら、この方法に問
題がある。もともとの送信者が "Don't Fragment" bit をセットした時、送信
者は、もともとの datagram を再送することによるどこからか返された ICMP
Datagram Too Big error message に、すばやく反応することが出来る。それ
に反して、encapsulator が tunnel 内部から ICMP Datagram Too Big
message を受信すると仮定しなさい。その case で、もしカプセル化されてい
ない datagram のもともと送信者が "Don't Fragment" bit をセットしていな
いなら、encapsulator がもともとの送信者に error のことを知らせることが
できる賢明なことは何もない。もし encapsulator が Datagram Too Big 応答
を得るなら encapsulator に datagram を分割し再送することを許すために、
encapsulator が tunnel の MTU を増やすことを試してみるときはいつでも、
encapsulator は、送信された datagram の copy を保管するかもしれない
(MAY)。それの代わり、カプセル化されていない datagram のもともとの送信
者が "Don't Fragment" bit をセットしない時、encapsulator は "Don't
Fragment" bit をセットしない datagram の確実な types に設定されるかも
しれない (MAY)。
5.2. Congestion
5.2. 輻輳
An encapsulator might receive indications of congestion from the
tunnel, for example, by receiving ICMP Source Quench messages from
nodes within the tunnel. In addition, certain link layers and
various protocols not related to the Internet suite of protocols
might provide such indications in the form of a Congestion
Experienced [6] flag. The encapsulator SHOULD reflect conditions of
congestion in its "soft state" for the tunnel, and when subsequently
forwarding datagrams into the tunnel, the encapsulator SHOULD use
appropriate means for controlling congestion [3]; However, the
encapsulator SHOULD NOT send ICMP Source Quench messages to the
original sender of the unencapsulated datagram.
encapsulator は、tunnel から輻輳の兆候を受信するかもしれない。たとえば
tunnel 内部の nodes から ICMP Source Quench messages を受信することに
よってである。さらに、protocols の Internet suite に関連されない確実な
link layers と種々の protocols は、Congestion Experienced [6] flag 形
式でのそのような兆候を提供するかもしれない。encapsulator は、tunnel に
ついてその "soft state" での輻輳の状態を反映すべきであり (SHOULD)、
後に続いて tunnel に datagram を forward する時、encapsulator は輻輳を
制御するために適した方法を使用すべきである (SHOULD); しかしながら
encapsulator は、カプセル化されていない datagram のもともとの送信者に
ICMP Source Quench messages を送信すべきでない (SHOULD NOT)。
-------------------------------------------------------------------------
6. Security Considerations
6. セキュリティに関する考察
IP encapsulation potentially reduces the security of the Internet,
and care needs to be taken in the implementation and deployment of IP
encapsulation. For example, IP encapsulation makes it difficult for
border routers to filter datagrams based on header fields. In
particular, the original values of the Source Address, Destination
Address, and Protocol fields in the IP header, and the port numbers
used in any transport header within the datagram, are not located in
their normal positions within the datagram after encapsulation.
Since any IP datagram can be encapsulated and passed through a
tunnel, such filtering border routers need to carefully examine all
datagrams.
IP カプセル化は、潜在的に Internet の security を減らす。そして注意が
IP カプセル化の実装と配置に払われる必要がある。たとえば IP カプセル化
は、header fields に基づいて datagrams を filter する境界 routers につ
いて filter を難しくする。特に IP header の Source Address、
Destination Address、と Protocol fields のもともとの値、datagram 内の
何らかの transport layer で使用される port number は、カプセル化の後で
datagram 内の典型的な場所に位置されない。どんな IP datagram もカプセル
化されることが出来て tunnel を通すことが出来るので、そのような filter
する境界 routers は、すべての datagram を注意深く調査する必要がある。
6.1. Router Considerations
6.1. ルータに関する考察
Routers need to be aware of IP encapsulation protocols in order to
correctly filter incoming datagrams. It is desirable that such
filtering be integrated with IP authentication [1]. Where IP
authentication is used, encapsulated packets might be allowed to
enter an organization when the encapsulating (outer) packet or the
encapsulated (inner) packet is sent by an authenticated, trusted
source. Encapuslated packets containing no such authentication
represent a potentially large security risk.
routers は、入って来る datagrams を正しく filter するために、IP カプセ
ル化 protocols に気づく必要がある。そのような filtering が IP 認証 [1]
と統合されるのは望ましい。IP 認証が使用されるような場所で、カプセル化
する (外側の) packet やカプセル化された (内側の) packet が認証され信頼
される始点により送信される時、カプセル化された packets は組織に入るこ
とを許可されるかもしれない。そのような認証のないカプセル化された
packets は、潜在的に大きな security 危険を意味する。
IP datagrams which are encapsulated and encrypted [2] might also pose
a problem for filtering routers. In this case, the router can filter
the datagram only if it shares the security association used for the
encryption. To allow this sort of encryption in environments in
which all packets need to be filtered (or at least accounted for), a
mechanism must be in place for the receiving node to securely
communicate the security association to the border router. This
might, more rarely, also apply to the security association used for
outgoing datagrams.
カプセル化され暗号化 [2] される IP datagram は、また filtering routers
について問題を提出する。この case で router は、もし暗号化のための
security association を共有しているなら、このときのみ datagram を
filter することが出来る。すべての packets が filter される (または少な
くとも明らかにされる) 必要がある環境で、この一種の暗号化を許すために、
構造は境界 router への security association と安全に通信する受信する
nodes のための適所になければならない。これはまた、外行きの datagrams
のために使用される security association にめったに適用しないだろう。
6.2. Host Considerations
6.2. ホストに関する考察
Host implementations that are capable of receiving encapsulated IP
datagrams SHOULD admit only those datagrams fitting into one or more
of the following categories:
カプセル化された IP datagrams を受信することが出来る host 実装は、次の
カテゴリの一つか多くに fit する datagrams のみに許可すべきである
(SHOULD):
- The protocol is harmless: source address-based authentication is
not needed.
- protocol は無害である: 認証に基づく始点アドレスは必要ではない。
- The encapsulating (outer) datagram comes from an authentically
identified, trusted source. The authenticity of the source could
be established by relying on physical security in addition to
border router configuration, but is more likely to come from use
of the IP Authentication header [1].
- カプセル化する (外側の) datagram は、確実に識別され信頼された
source から来る。source の確実性は、境界 router 設定に加えて、物理
的な security を信頼することにより確立されることが出来る。しかし
source の確実性は、IP Authentication header [1] の使用からいっそう
来そうである。
- The encapuslated (inner) datagram includes an IP Authentication
header.
- カプセル化された (内側の) datagram は、IP Authentication header を
含む。
- The encapsulated (inner) datagram is addressed to a network
interface belonging to the decapsulator, or to a node with which
the decapsulator has entered into a special relationship for
delivering such encapsulated datagrams.
- カプセル化された (内側の) datagram は、decapsulator に属する
network interface にいわれるか、そのようなカプセル化された
datagrams を配送するための特別な関係に decapsulator が参加する
node にいわれる。
Some or all of this checking could be done in border routers rather
than the receiving node, but it is better if border router checks are
used as backup, rather than being the only check.
この check の一部またはすべては、datagrams を受信する node よりむしろ
境界 router でおこなわれることが出来る。しかしもし境界 router check が
backup として使用されるなら、check のみであることよりむしろよい。
-------------------------------------------------------------------------
7. Acknowledgements
7. 謝辞
Parts of Sections 3 and 5 of this document were taken from portions
(authored by Bill Simpson) of earlier versions of the Mobile IP
Internet Draft [8]. The original text for section 6 (Security
Considerations) was contributed by Bob Smart. Good ideas have also
been included from RFC 1853 [11], also authored by Bill Simpson.
Thanks also to Anders Klemets for finding mistakes and suggesting
improvements to the draft. Finally, thanks to David Johnson for
going over the draft with a fine-toothed comb, finding mistakes,
improving consistency, and making many other improvements to the
draft.
この文書の Section 3 と 5 の一部は、Mobile IP Internet Draft [8] の初
期の versions の (Bill Simpson により書かれた) 一部分から利用された。
section 6 (Security Considerations) のためのもともとの text は、Bob
Smart により寄与された。good idea もまた、Bill Simpson により書かれた
RFC 1853 [11] から含まれる。draft への誤りを見つけ改良を提案した
Anders Klemets にもまた感謝する。最後に、良い目の細かいくしと draft を
調べ、誤りを見つけ、一貫性を改良し、この draft に多くの他の改善をした
David Johnson に感謝したい。
-------------------------------------------------------------------------
References
参考文献
[1] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[2] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
August 1995.
[3] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[4] Gilligan, R., Nordmark, E., and B. Hinden, "IPAE: The SIPP
Interoperability and Transition Mechanism", Work in Progress.
[5] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
[6] Mankin, A., and K. Ramakrishnan, "Gateway Congestion Control
Survey", RFC 1254, August 1991.
[7] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[8] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
October 1996.
[9] Postel, J., Editor, "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[10] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
September 1981.
[11] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
-------------------------------------------------------------------------
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
一覧
スポンサーリンク
