rfc2473
和訳追加：寺岡
Network Working Group A. Conta
Request for Comments: 2473 Lucent Technologies Inc.
Category: Standards Track S. Deering
Cisco Systems
December 1998
Generic Packet Tunneling in IPv6
Specification
IPv6の中の総括的なパケット・トンネリング
明細
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.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This document defines the model and generic mechanisms for IPv6
encapsulation of Internet packets, such as IPv6 and IPv4. The model
and mechanisms can be applied to other protocol packets as well, such
as AppleTalk, IPX, CLNP, or others.
このドキュメントは、IPv6とIPv4のようなインターネットパケットのIPv6カプセル化
のためのモデルおよび総括的なメカニズムを定義します。
モデルおよびメカニズムは、アップル・トーク、IPX、CLNP、その他のもののように、
他のプロトコル・パケットに同様に適用することができます。
Table of Contents
1. Introduction..................................................2
2. Terminology...................................................2
3. IPv6 Tunneling................................................4
3.1 IPv6 Encapsulation.......................................6
3.2 IPv6 Packet Processing in Tunnels........................7
3.3 IPv6 Decapsulation.......................................7
3.4 IPv6 Tunnel Protocol Engine..............................8
4. Nested Encapsulation.........................................11
4.1 Limiting Nested Encapsulation..........................12
4.1.1 Tunnel Encapsulation Limit Option................13
4.1.2 Loopback Encapsulation...........................15
4.1.3 Routing Loop Nested Encapsulation................15
5. Tunnel IPv6 Header...........................................16
5.1 Tunnel IPv6 Extension Headers...........................17
6. IPv6 Tunnel State Variables..................................19
6.1 IPv6 Tunnel Entry-Point Node............................19
6.2 IPv6 Tunnel Exit-Point Node.............................19
Conta & Deering Standards Track [Page 1]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
6.3 IPv6 Tunnel Hop Limit...................................19
6.4 IPv6 Tunnel Packet Traffic Class........................20
6.5 IPv6 Tunnel Flow Label..................................20
6.6 IPv6 Tunnel Encapsulation Limit.........................20
6.7 IPv6 Tunnel MTU.........................................20
7. IPv6 Tunnel Packet Size Issues...............................21
7.1 IPv6 Tunnel Packet Fragmentation........................21
7.2 IPv4 Tunnel Packet Fragmentation........................22
8. IPv6 Tunnel Error Reporting and Processing...................22
8.1 Tunnel ICMP Messages....................................27
8.2 ICMP Messages for IPv6 Original Packets.................28
8.3 ICMP Messages for IPv4 Original Packets.................29
8.4 ICMP Messages for Nested Tunnel Packets.................30
9. Security Considerations......................................30
10. Acknowledgments.............................................31
11. References..................................................31
Authors' Addresses..............................................32
Appendix A. Risk Factors in Recursive Encapsulation.............33
Full Copyright Statement........................................36
1. Introduction
This document specifies a method and generic mechanisms by which a
packet is encapsulated and carried as payload within an IPv6 packet.
The resulting packet is called an IPv6 tunnel packet. The forwarding
path between the source and destination of the tunnel packet is
called an IPv6 tunnel. The technique is called IPv6 tunneling.
このドキュメントは、IPv6パケット内のペイロードとしてパケットがカプセルに
入れられ運ばれる方法および総括的なメカニズムを記述します。
発生するパケットはIPv6トンネル・パケットと呼ばれます。
トンネル・パケットのソースおよびディスティネーションの間の
フォワーディング・パスは、「IPv6トンネル」と呼ばれます。
このテクニックを「IPv6トンネリング」と呼ばれます。
A typical scenario for IPv6 tunneling is the case in which an
intermediate node exerts explicit routing control by specifying
particular forwarding paths for selected packets. This control is
achieved by prepending IPv6 headers to each of the selected original
packets. These prepended headers identify the forwarding paths.
IPv6トンネリングのための典型的なシナリオは、
選択されたパケットに対して、特別のフォワーディング・パスの指定をすることで、
中間のノードが明示的なルーティングコントロールをするケースです。
このコントロールは、選択されたオリジナルのパケットの個々のIPv6ヘッダーを
prependすることによって達成されます。
prependされたヘッダーは、フォワーディング・パスを識別します。
In addition to the description of generic IPv6 tunneling mechanisms,
which is the focus of this document, specific mechanisms for
tunneling IPv6 and IPv4 packets are also described herein.
総括的なIPv6トンネリング・メカニズムの記述に加えて、
IPv6とIPv4のパケットにトンネルを掘るためのメカニズムも
このドキュメントの焦点である。
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined
in RFC 2119.
キーワードMUST、MUST NOT, MAY, OPTIONAL、REQUIRED、RECOMMENDED、SHALL,
SHALL NOT, SHOULD、SHOULD NOTは、RFC2119の定義により解釈すること。
2. Terminology
original packet
a packet that undergoes encapsulation.
カプセル化されるパケット。
Conta & Deering Standards Track [Page 2]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
original header
the header of an original packet.
オリジナルのパケットのヘッダー
tunnel
a forwarding path between two nodes on which the payloads of
packets are original packets.
パケットのペイロードが、オリジナルのパケットである、
2つのノード間のフォワーディング・パスのこと。
tunnel end-node
a node where a tunnel begins or ends.
トンネルが始まるもしくは終わるノードのこと。
tunnel header
the header prepended to the original packet during
encapsulation. It specifies the tunnel end-points as source and
destination.
カプセル化中のオリジナルのパケットへのprependヘッダー。
これはソースおよびディスティネーションとしてトンネル終点を指定します。
tunnel packet
a packet that encapsulates an original packet.
オリジナルのパケットをカプセル化したパケット。
tunnel entry-point
the tunnel end-node where an original packet is encapsulated.
オリジナルのパケットがカプセル化される、トンネル・エンド・ノード。
tunnel exit-point
the tunnel end-node where a tunnel packet is decapsulated.
トンネル・パケットがカプセル化解除される、トンネル・エンド・ノード。
IPv6 tunnel
a tunnel configured as a virtual link between two IPv6 nodes, on
which the encapsulating protocol is IPv6.
IPv6のカプセル化するプロトコルにおいて、
2つのIPv6ノード間を仮想リンクとして形成されたトンネル。
tunnel MTU
the maximum size of a tunnel packet payload without requiring
fragmentation, that is, the Path MTU between the tunnel entry-
point and the tunnel exit-point nodes minus the size of the
tunnel header.
フラグメント部分を除いたトンネル・パケット・ペイロードの最大の
サイズ。
すなわち、トンネル・ヘッダーのサイズを引いた、
トンネル・エントリーポイントとトンネル出口ポイントノードの間の
パスMTUである。
tunnel hop limit
the maximum number of hops that a tunnel packet can travel from
the tunnel entry-point to the tunnel exit-point.
トンネル・エントリーポイントからトンネル出口ポイントまで
トンネル・パケットが配信することができる最大ホップ数。
Conta & Deering Standards Track [Page 3]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
inner tunnel
a tunnel that is a hop (virtual link) of another tunnel.
別トンネルのホップ(仮想リンク)であるトンネル
outer tunnel
a tunnel containing one or more inner tunnels.
1本以上の内部トンネルを含んでいるトンネル。
nested tunnel packet
a tunnel packet that has as payload a tunnel packet.
ペイロードとしてトンネル・パケットを持っているトンネル・パケット。
nested tunnel header
the tunnel header of a nested tunnel packet.
入れ子のトンネル・パケットのトンネル・ヘッダー。
nested encapsulation
encapsulation of an encapsulated packet.
カプセル化されたパケットのカプセル化。
recursive encapsulation
encapsulation of a packet that reenters a tunnel before exiting
it.
脱出する前に再びトンネルに入るカプセル化パケット
tunnel encapsulation limit
the maximum number of nested encapsulations of a packet.
入れ子のカプセル化パケットの最大数
3. IPv6 Tunneling
IPv6 tunneling is a technique for establishing a "virtual link"
between two IPv6 nodes for transmitting data packets as payloads of
IPv6 packets (see Fig.1). From the point of view of the two nodes,
this "virtual link", called an IPv6 tunnel, appears as a point to
point link on which IPv6 acts like a link-layer protocol. The two
IPv6 nodes play specific roles. One node encapsulates original
packets received from other nodes or from itself and forwards the
resulting tunnel packets through the tunnel. The other node
decapsulates the received tunnel packets and forwards the resulting
original packets towards their destinations, possibly itself. The
encapsulator node is called the tunnel entry-point node, and it is
the source of the tunnel packets. The decapsulator node is called the
tunnel exit-point, and it is the destination of the tunnel packets.
IPv6トンネリングは、IPv6パケットのペイロードとしてデータ・パケットを
送信するために、2つのIPv6ノード間で「仮想リンク」を確立するための
技術です(Fig.1を参照)。
2つのノードの視点から見て、IPv6トンネルと呼ばれるこの「仮想リンク」は、
IPv6はリンク層プロトコルのようにはたらくポイントtoポイントリンクの
ように見えます。
2つのIPv6ノードは特定の役割を担う。
1つのノードは、他のノードあるいはそれ自体から受け取られたオリジナルの
パケットをカプセル化して、トンネルを通ってトンネル・パケットを転送する。
他方のノードは、受信したトンネル・パケットをカプセル解除して、
目的地(恐らく自分自身)にオリジナルのパケットを転送する。
カプセル化するノードはトンネル・エントリーポイントノードと呼ばれる。
また、それはトンネル・パケットの発生源です。
カプセル解除するノードはトンネル出口ポイントと呼ばれる。
それはトンネル・パケットの目的地である。
Conta & Deering Standards Track [Page 4]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Note:
This document refers in particular to tunnels between two nodes
identified by unicast addresses - such tunnels look like "virtual
point to point links". The mechanisms described herein apply also to
tunnels in which the exit-point nodes are identified by other types
of addresses, such as anycast or multicast. These tunnels may look
like "virtual point to multipoint links". At the time of writing this
document, IPv6 anycast addresses are a subject of ongoing
specification and experimental work.
注:
このドキュメントは、ユニキャスト・アドレスによって識別された2つのノード間の
トンネルを特に参照します。そのようなトンネルは、仮想ポイントtoポイントリンク
のように見えます。
ここで記述されたメカニズムは、エニキャストまたはマルチキャストのような
他のタイプのアドレスにより、出口ポイントのノードが識別されるトンネルにも
当てはまります。
これらのトンネルは「multipointリンクへの仮想ポイント」として見えるであろう。
このドキュメントの記述時は、IPv6のエニキャストアドレスは、実験が進行中です。
Tunnel from node B to node C
<---------------------->
Tunnel Tunnel
Entry-Point Exit-Point
Node Node
+-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>=====//=====>=====|C|-->--//-->--|D|
+-+ +-+ +-+ +-+
Original Original
Packet Packet
Source Destination
Node Node
Fig.1 Tunnel
An IPv6 tunnel is a unidirectional mechanism - tunnel packet flow
takes place in one direction between the IPv6 tunnel entry-point and
exit-point nodes (see Fig.1).
IPv6トンネルは一方向のメカニズムです。トンネル・パケット・フローは、
IPv6トンネル・エントリーポイントと出口ポイントのノード(Fig.1を参照)の間の
1つの方向に起こる。
Tunnel from Node B to Node C
<------------------------>
Tunnel Tunnel
Original Entry-Point Exit-Point Original
Packet Node Node Packet
Source Destination
Node Node
+-+ +-+ +-+ +-+
| |-->--//-->--| |=====>=====//=====>======| |-->--//-->--| |
|A| |B| |C| |D|
| |--<--//--<--| |=====<=====//=====<======| |--<--//--<--| |
+-+ +-+ +-+ +-+
Original Original
Packet Packet
Destination Tunnel Tunnel Source
Node Exit-Point Entry-Point Node
Node Node
<------------------------->
Tunnel from Node C to Node B
Fig.2 Bi-directional Tunneling Mechanism
Conta & Deering Standards Track [Page 5]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Bi-directional tunneling is achieved by merging two unidirectional
mechanisms, that is, configuring two tunnels, each in opposite
direction to the other - the entry-point node of one tunnel is the
exit-point node of the other tunnel (see Fig.2).
双方向トンネリングは一方向の2つのメカニズムの合併によって達成されます。
すなわち、双方向に2本のトンネルを各々形成することとなります。
1本のトンネルのエントリーポイントのノードは、他方のトンネルの出口ポイント
のノードです。
3.1 IPv6 Encapsulation
IPv6 encapsulation consists of prepending to the original packet an
IPv6 header and, optionally, a set of IPv6 extension headers (see
Fig.3), which are collectively called tunnel IPv6 headers. The
encapsulation takes place in an IPv6 tunnel entry-point node, as the
result of an original packet being forwarded onto the virtual link
represented by the tunnel. The original packet is processed during
forwarding according to the forwarding rules of the protocol of that
packet. For instance if the original packet is an:
IPv6カプセル化は、オリジナルのパケットにIPv6ヘッダーおよびIPv6拡張
ヘッダーをprependingすることから成る。
それらは集合体として「トンネルIPv6ヘッダー」と呼ばれる。
カプセル化は、IPv6トンネル・エントリーポイントノードに起こり、
トンネルによって表わされる仮想のリンク上で転送される。
オリジナルのパケットは、プロトコルのフォワーディングルールにより、フォワー
ディング処理される。
例えば、オリジナルパケットが
(a) IPv6 packet, the IPv6 original header hop limit is decremented
by one.
(a) IPv6パケット、IPv6オリジナルのヘッダー・ホップ限界は1だけディクリメン
(b) IPv4 packet, the IPv4 original header time to live field (TTL)
is decremented by one.
(b) IPv4パケット、IPv4オリジナルヘッダーtime to liveフィールド(TTL)
は1だけディクリメントされる。
At encapsulation, the source field of the tunnel IPv6 header is
filled with an IPv6 address of the tunnel entry-point node, and the
destination field with an IPv6 address of the tunnel exit-point.
Subsequently, the tunnel packet resulting from encapsulation is sent
towards the tunnel exit-point node.
カプセル化では、トンネルIPv6ヘッダーのソースフィールドが、トンネル・
エントリーポイントノードのIPv6アドレス、およびトンネル出口ポイントの
IPv6アドレスを備えた目的地フィールドとなる。
続いて、カプセル化に起因するトンネル・パケットは、トンネル出口ポイント
ノードに向かって送られる。
+----------------------------------//-----+
| Original | |
| | Original Packet Payload |
| Header | |
+----------------------------------//-----+
< Original Packet >
|
v
< Original Packet >
+---------+ - - - - - +-------------------------//--------------+
| IPv6 | IPv6 | |
| | Extension | Original Packet |
| Header | Headers | |
+---------+ - - - - - +-------------------------//--------------+
< Tunnel IPv6 Packet >
Fig.3 Encapsulating a Packet
Conta & Deering Standards Track [Page 6]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Tunnel extension headers should appear in the order recommended by
the specifications that define the extension headers, such as [IPv6-
Spec].
A source of original packets and a tunnel entry-point that
encapsulates those packets can be the same node.
トンネル拡張ヘッダーは、[IPv6スペック(IPv6 Spec)]のような拡張ヘッダーを
定義する仕様書によって勧められた順になるべきです。
パケット発生源およびトンネル化するトンネル・エントリーポイントは、同じ
ノードになりえる。
3.2 Packet Processing in Tunnels
The intermediate nodes in the tunnel process the IPv6 tunnel packets
according to the IPv6 protocol. For example, a tunnel Hop by Hop
Options extension header is processed by each receiving node in the
tunnel; a tunnel Routing extension header identifies the intermediate
processing nodes, and controls at a finer granularity the forwarding
path of the tunnel packet through the tunnel; a tunnel Destination
Options extension header is processed at the tunnel exit-point node.
トンネル中の中間のノードは、IPv6プロトコルによってIPv6トンネル・パケット
を処理する。
例えば、Hop Options拡張ヘッダーによるトンネル・ホップは、トンネル中の
各受信ノードによって処理される;
トンネルルーティング拡張ヘッダーは中間の処理ノードを識別し、トンネルを
通ってよりよい状態でトンネル・パケットのフォワーディング・パスを
コントロールする;
トンネルDestination拡張ヘッダーは、トンネル出口ポイントノードで処理される。
3.3 IPv6 Decapsulation
Decapsulation is graphically shown in Fig.4:
+---------+- - - - - -+----------------------------------//-----+
| IPv6 | IPv6 | |
| | Extension | Original Packet |
| Header | Headers | |
+---------+- - - - - -+----------------------------------//-----+
< Tunnel IPv6 Packet >
|
v
+----------------------------------//-----+
| Original | |
| | Original Packet Payload |
| Headers | |
+----------------------------------//-----+
< Original Packet >
Fig.4 Decapsulating a Packet
Upon receiving an IPv6 packet destined to an IPv6 address of a tunnel
exit-point node, its IPv6 protocol layer processes the tunnel
headers. The strict left-to-right processing rules for extension
headers is applied. When processing is complete, control is handed to
the next protocol engine, which is identified by the Next Header
field value in the last header processed. If this is set to a tunnel
protocol value, the tunnel protocol engine discards the tunnel
headers and passes the resulting original packet to the Internet or
lower layer protocol identified by that value for further processing.
トンネル出口ポイントノードのIPv6アドレスへ予定されたIPv6パケットを
受け取る際、そのIPv6プロトコル層はトンネル・ヘッダーを処理します。
拡張ヘッダーの厳密な左から右への処理規則は、適用される。
処理が完全な場合、コントロールは、最終ヘッダーの処理中の次ヘッダーフィールド
値によって識別される、次のプロトコル・エンジンに渡されます。
これがトンネル・プロトコル値にセットされる場合、トンネル・プロトコル・
エンジンはトンネル・ヘッダーを廃棄し、生じるオリジナルパケットを、
一層の処理に対するその等価物によって識別されたインターネットもしくはより
下位層プロトコルへ渡す。
Conta & Deering Standards Track [Page 7]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
For example, in the case the Next Header field has the IPv6 Tunnel
Protocol value, the resulting original packet is passed to the IPv6
protocol layer.
The tunnel exit-point node, which decapsulates the tunnel packets,
and the destination node, which receives the resulting original
packets can be the same node.
例えば、次ヘッダーフィールドがIPv6トンネル・プロトコル値を持っている場合では、
発生するオリジナルのパケットは、IPv6プロトコル層に渡されます。
トンネル出口ポイントノード、トンネルパケットのカプセル解除、また、
オリジナルのパケットを受け取る目的地ノードは、同じノードになることができる。
3.4 IPv6 Tunnel Protocol Engine
Packet flow (paths #1-7) through the IPv6 Tunnel Protocol Engine on a
node is graphically shown in Fig.5:
ノード上のIPv6トンネル・プロトコル・エンジンによるパケット・フロー(パス#1-7)
は、Fig.5の中でグラフ式に示されます:
Note:
In Fig.5, the Upper-Layer Protocols box represents transport
protocols such as TCP, UDP, control protocols such as ICMP, routing
protocols such as OSPF, and internet or lower-layer protocol being
"tunneled" over IPv6, such as IPv4, IPX, etc. The Link-Layer
Protocols box represents Ethernet, Token Ring, FDDI, PPP, X.25, Frame
Relay, ATM, etc..., as well as internet layer "tunnels" such as IPv4
tunnels.
The IPv6 tunnel protocol engine acts as both an "upper-layer" and a
"link-layer", each with a specific input and output as follows:
IPv6トンネル・プロトコル・エンジンは、「上位層」および「リンク層」の
各々特定の入力および出力において、以下の役割となる
(u.i) "tunnel upper-layer input" - consists of tunnel IPv6 packets
that are going to be decapsulated. The tunnel packets are
incoming through the IPv6 layer from:
"tunnel upper-layer input"は、カプセル解除されるトンネルIPv6パケット
から成る。
トンネル・パケットはIPv6層以下によりなる
(u.i.1) a link-layer - (path #1, Fig.5)
These are tunnel packets destined to this node and will
undergo decapsulation.
これらはこのノードに予定されたトンネル・パケットであり、
カプセル解除される。
(u.i.2) a tunnel link-layer - (path #7, Fig.5)
These are tunnel packets that underwent one or more
decapsulations on this node, that is, the packets had
one or more nested tunnel headers and one nested tunnel
header was just discarded. This node is the exit-point
of both an outer tunnel and one or more of its inner
tunnels.
これらはこのノード上の1以上decapsulationsを経験したトンネル・
パケットである、すなわち、パケットは1つ以上の入れ子のトンネル
・ヘッダーおよび1つの入れ子のトンネル・ヘッダーを持っていた、
ちょうど廃棄された。
このノードは外部のトンネルおよびその内部のトンネルの1つ以上
の両方の出口ポイントである。
For both above cases the resulting original packets are passed
back to the IPv6 layer as "tunnel link-layer" output for
further processing (see b.2).
両方については、ケース上に、生じるオリジナルのパケットが、
一層の処理のための「トンネル・リンク層」出力としてIPv6層に渡される。
Conta & Deering Standards Track [Page 8]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
+-----------------------+ +-----------------------------------+
| Upper-Layer Protocols | | IPv6 Tunnel Upper-Layer |
| | | 上位層 |
| | | ---<-------------------<------- |
| | | | ---->---|------>--------- | |
| | | | | | | | | |
+-----------------------+ +-----------------------+ | | |
| | | | | | | | | v ^ |
v ^ v ^ v ^ v ^ Tunnel | | | |
| | | | | | | | Packets| | | |
+---------------------------------------------+ | | | |
| | | | | / / | | | | D E |
| v ^ IPv6 | --<-3--/-/--<---- | | | | E N |
| | | Layer ---->-4-/-/--->-- | | | | | C C |
| v ^ / / | | | | | | A A |
| | | 2 1 | | | | | | P P |
| v ^ -----<---5---/-/-<---- v ^ v ^ | | S S |
| | | | -->---6---/-/-->-- | | | | | | | U U |
| v ^ | | / / 6 5 4 3 8 7 | | L L |
| | | | | / / | | | | | | | | A A |
| v ^ v ^ / / v ^ | | | | | | T T |
+---------------------------------------------+ | E E |
| | | | | | | | | | | | | | | |
v ^ v ^ v ^ v ^ v ^ v ^ Original| | | |
| | | | | | | | | | | | Packets | v ^ |
+-----------------------+ +-----------------------+ | | |
| | | | | | | | | | | |
| | | | ---|----|-------<-------- | |
| | | --->--------------->------>---- |
| | | リンク層 |
| Link-Layer Protocols | | IPv6 Tunnel Link-Layer |
+-----------------------+ +-----------------------------------+
Fig.5 Packet Flow in the IPv6 Tunneling Protocol Engine on a Node
(u.o) "tunnel upper-layer output" - consists of tunnel IPv6 packets
that are passed through the IPv6 layer down to:
IPv6を通して渡されるIPv6パケットが下へ層になるトンネルから成る
(u.o.1) a link-layer - (path #2, Fig.5)
These packets underwent encapsulation and are sent
towards the tunnel exit-point
これらのパケットはカプセル化され、トンネル出口ポイントに
向かって送られる。
(u.o.2) a tunnel link-layer - (path #8, Fig.5)
These tunnel packets undergo nested encapsulation.
This node is the entry-point node of both an outer
tunnel and one or more of its inner tunnel.
これらのトンネル・パケットは入れ子のカプセル化になる。
このノードは外部のトンネルおよびその内部のトンネルの1つ以上
の両方のエントリーポイントのノードである。
Conta & Deering Standards Track [Page 9]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Implementation Note:
The tunnel upper-layer input and output can be implemented similar
to the input and output of the other upper-layer protocols.
トンネル上位層の入力および出力は、異なる上位層プロトコルの入力および出力に
似ている
The tunnel link-layer input and output are as follows:
トンネル・リンク層入力および出力は以下のとおりである:
(l.i) "tunnel link-layer input" - consists of original IPv6 packets
that are going to be encapsulated.
カプセルに入れられるオリジナルのIPv6パケットから成る
The original packets are incoming through the IPv6 layer from:
オリジナルのパケットは、以下のIPv6層によって入ってくる
(l.i.1) an upper-layer - (path #4, Fig.5)
These are original packets originating on this node
that undergo encapsulation. The original packet source
and tunnel entry-point are the same node.
このノードで発生するオリジナルパケットは、カプセル化される。
オリジナルのパケット出所およびトンネル・エントリーポイントは
同じノードである。
(l.i.2) a link-layer - (path #6, Fig.5)
These are original packets incoming from a different
node that undergo encapsulation on this tunnel entry-
point node.
異なるノードから入って来るオリジナルのパケットは、このトン
ネル・エントリー・ポイントノード上でカプセル化される。
(l.i.3) a tunnel upper-layer - (path #8, Fig.5)
These packets are tunnel packets that undergo nested
encapsulation. This node is the entry-point node of
both an outer tunnel and one or more of its inner
tunnels.
パケットは入れ子のカプセル化となるトンネル・パケットである。
このノードは、外部のトンネルおよび一つ以上の内部のトンネルの
エントリーポイントノードです。
The resulting tunnel packets are passed as tunnel upper-layer
output packets through the IPv6 layer (see u.o) down to:
生じるトンネル・パケットは、IPv6層を通るトンネル上位層出力パケット
として
(l.o) "tunnel link-layer output" - consists of original IPv6 packets
resulting from decapsulation. These packets are passed through the
IPv6 layer to:
(l.o.1) an upper-layer - (path #3, Fig.5)
These original packets are destined to this node.
これらのオリジナルのパケットはこのノードに設定される。
(l.o.2) a link-layer - (path #5, Fig.5)
These original packets are destined to another node;
they are transmitted on a link towards their
destination.
これらのオリジナルのパケットは別のノードに設定される;
それらは目的地に向かってリンク上で送信される。
Conta & Deering Standards Track [Page 10]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
(l.o.3) a tunnel upper-layer - (path #7, Fig.5)
These packets undergo another decapsulation; they were
nested tunnel packets. This node is both the exit-
point node of an outer tunnel and one or more inner
tunnels.
これらのパケットは別のdecapsulationを設定する;
それらは入れ子のトンネル・パケットだった。
このノードは外部トンネルと一つ以上の内部トンネルの両方の
出口ポイントである。
Implementation Note:
The tunnel link-layer input and output can be implemented similar
to the input and output of other link-layer protocols, for
instance, associating an interface or pseudo-interface with the
IPv6 tunnel.
The selection of the "IPv6 tunnel link" over other links results
from the packet forwarding decision taken based on the content of
the node's routing table.
トンネル・リンク層入力および出力はインプリメントできる、例えば他の
リンク層プロトコルの入力および出力、IPv6トンネルにインターフェースを
関連させること、あるいは偽りのインターフェースに似ている
他のリンク上の「IPv6トンネル・リンク」の選択は、ノードのルーティング・
テーブルの内容に基づいたので、得られた決定を進めるパケットに起因する。
4. Nested Encapsulation
Nested IPv6 encapsulation is the encapsulation of a tunnel packet.
It takes place when a hop of an IPv6 tunnel is a tunnel. The tunnel
containing a tunnel is called an outer tunnel. The tunnel contained
in the outer tunnel is called an inner tunnel - see Fig.6. Inner
tunnels and their outer tunnels are nested tunnels.
The entry-point node of an "inner IPv6 tunnel" receives tunnel IPv6
packets encapsulated by the "outer IPv6 tunnel" entry-point node. The
"inner tunnel entry-point node" treats the receiving tunnel packets
as original packets and performs encapsulation. The resulting
packets are "tunnel packets" for the "inner IPv6 tunnel", and "nested
tunnel packets" for the "outer IPv6 tunnel".
入れ子のIPv6(Nested IPv6)カプセル化はトンネル・パケットのカプセル化である。
IPv6トンネルのホップがトンネルである場合、それは起こる。
トンネルを含んでいるトンネルは外部のトンネルと呼ばれる。
外部のトンネルに含まれていたトンネルは内部のトンネルと呼ばれる。
内部のトンネルおよびそれらの外部のトンネルは入れ子のトンネルである。
「内部のIPv6トンネル」のエントリーポイントのノードは、
「外部のIPv6トンネル」エントリーポイントノードによってカプセルに入れられた
トンネルIPv6パケットを受け取る。
「内部のトンネル・エントリーポイントノード」はオリジナルのパケットとして
受信トンネル・パケットを扱い、カプセル化を実行する。
生じるパケットは、「外部のIPv6トンネル」用に「内部のIPv6トンネル」の
ための「トンネル・パケット」、および「入れ子のトンネル・パケット」である。
Conta & Deering Standards Track [Page 11]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Outer Tunnel
<------------------------------------->
<--links--><-virtual link-><--links--->
Inner Tunnel
Outer Tunnel Outer Tunnel
Entry-Point Exit-Point
Node Node
+-+ +-+ +-+ +-+ +-+ +-+
| | | | | | | | | | | |
| |->-//->-| |=>=//=>=| |**>**//**>**| |=>=//=>==| |->-//->-| |
| | | | | | | | | | | |
+-+ +-+ +-+ +-+ +-+ +-+
Original Inner Tunnel Inner Tunnel Original
Packet Entry-Point Exit-Point Packet
Source Node Node Destination
Node Node
Fig.6. Nested Encapsulation
4.1 Limiting Nested Encapsulation
A tunnel IPv6 packet is limited to the maximum IPv6 packet size
[IPv6-Spec]. Each encapsulation adds to the size of an encapsulated
packet the size of the tunnel IPv6 headers. Consequently, the number
of tunnel headers, and therefore, the number of nested encapsulations
is limited by the maximum packet size. However this limit is so
large (more than 1600 encapsulations for an original packet of
minimum size) that it is not an effective limit in most cases.
トンネルIPv6パケットは、最大のIPv6パケット・サイズ[IPv6スペック(IPv6-Spec)]
に制限されている。
各カプセル化は、カプセルに入れられたパケットのサイズにトンネルIPv6ヘッダー
のサイズを加える。
従って、トンネル・ヘッダーの数、また、したがって、入れ子のカプセル化の数は
最大のパケット・サイズによって制限されている。
しかし、この限界が非常に大きいので、(最小のサイズのオリジナルのパケットの
ための1600を越えるカプセル化)ほとんどの場合有効な限界ではない。
The increase in the size of a tunnel IPv6 packet due to nested
encapsulations may require fragmentation [IPv6-Spec] at a tunnel
entry point - see section 7. Furthermore, each fragmentation, due to
nested encapsulation, of an already fragmented tunnel packet results
in a doubling of the number of fragments. Moreover, it is probable
that once this fragmentation begins, each new nested encapsulation
results in yet additional fragmentation. Therefore limiting nested
encapsulation is recommended.
The proposed mechanism for limiting excessive nested encapsulation is
a "Tunnel Encapsulation Limit" option, which is carried in an IPv6
Destination Options extension header accompanying an encapsulating
IPv6 header.
Conta & Deering Standards Track [Page 12]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
4.1.1 Tunnel Encapsulation Limit Option
A tunnel entry-point node may be configured to include a Tunnel
Encapsulation Limit option as part of the information prepended to
all packets entering a tunnel at that node. The Tunnel Encapsulaton
Limit option is carried in a Destination Options extension header
[IPv6-Spec] placed between the encapsulating IPv6 header and the IPv6
header of the original packet. (Other IPv6 extension headers may
also be present preceding or following the Destination Options
extension header, depending on configuration information at the
tunnel entry-point node.)
The Tunnel Encapsulation Limit option specifies how many additional
levels of encapsulation are permitted to be prepended to the packet
-- or, in other words, how many further levels of nesting the packet
is permitted to undergo -- not counting the encapsulation in which
the option itself is contained. For example, a Tunnel Encapsulation
Limit option containing a limit value of zero means that a packet
carrying that option may not enter another tunnel before exiting the
current tunnel.
The Tunnel Encapsulation Limit option has the following format:
トンネル・カプセル化限界(Tunnel Encapsulation Limit)オプションは次の
フォーマットです。
Option Type Opt Data Len Opt Data Len
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| 1 | Tun Encap Lim |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type decimal value 4
- the highest-order two bits - set to 00 -
indicate "skip over this option if the option is
not recognized".
- 最初の2bitは00とし、「オプションが認識されない場合、
このオプションをスキップすること」を意味する。
- the third-highest-order bit - set to 0 -
indicates that the option data in this option
does not change en route to the packet's
destination [IPv6-Spec].
- 3bit目は0とし、パケットの目的地[IPv6スペック
(IPv6-Spec)]に、このオプションの中のオプション・データ
が途中で変わらないことを示します。
Opt Data Len value 1 - the data portion of the Option is one octet
long.
オプションのデータ部分は1オクテット長です。
Opt Data Value the Tunnel Encapsulation Limit value - 8-bit
unsigned integer specifying how many further
levels of encapsulation are permitted for the
Conta & Deering Standards Track [Page 13]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Tunnel Encapsulation Limit options are of interest only to tunnel
entry points. A tunnel entry-point node is required to execute the
following procedure for every packet entering a tunnel at that node:
(a) Examine the packet to see if a Tunnel Encapsulation Limit
option is present following its IPv6 header. The headers
following the IPv6 header must be examined in strict
"left-to-right" order, with the examination stopping as
soon as any one of the following headers is encountered:
(i) a Destination Options extension header containing a
Tunnel Encapsulation Limit, (ii) another IPv6 header, (iii)
a non-extension header, such as TCP, UDP, or ICMP, or (iv)
a header that cannot be parsed because it is encrypted or
its type is unknown. (Note that this requirment is an
exception to the general IPv6 rule that a Destination
Options extension header need only be examined by a
packet's destination node. An alternative and "cleaner"
approach would have been to use a Hop-by-Hop extension
header for this purpose, but that would have imposed an
undesirable extra processing burden, and possible
consequent extra delay, at every IPv6 node along the path
of a tunnel.)
(b) If a Tunnel Encapsulation Limit option is found in the
packet entering the tunnel and its limit value is zero, the
packet is discarded and an ICMP Parameter Problem message
[ICMP-Spec] is sent to the source of the packet, which is
the previous tunnel entry-point node. The Code field of
the Parameter Problem message is set to zero ("erroneous
header field encountered") and the Pointer field is set to
point to the third octet of the Tunnel Encapsulation Limit
option (i.e., the octet containing the limit value of
zero).
(c) If a Tunnel Encapsulation Limit option is found in the
packet entering the tunnel and its limit value is non-zero,
an additional Tunnel Encapsulation Limit option must be
included as part of the encapsulating headers being added
at this entry point. The limit value in the encapsulating
option is set to one less than the limit value found in the
packet being encapsulated.
(d) If a Tunnel Encapsulation Limit option is not found in the
packet entering the tunnel and if an encapsulation limit
has been configured for this tunnel, a Tunnel Encapsulation
Limit option must be included as part of the encapsulating
headers being added at this entry point. The limit value
in the option is set to the configured limit.
Conta & Deering Standards Track [Page 14]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
(e) If a Tunnel Encapsulation Limit option is not found in the
packet entering the tunnel and if no encapsulation limit
has been configured for this tunnel, then no Tunnel
Encapsulation Limit option is included as part of the
encapsulating headers being added at this entry point.
A Tunnel Encapsulation Limit option added at a tunnel entry-point
node is removed as part of the decapsulation process at that tunnel's
exit-point node.
Two cases of encapsulation that should be avoided are described
below:
4.1.2 Loopback Encapsulation
A particular case of encapsulation which must be avoided is the
loopback encapsulation. Loopback encapsulation takes place when a
tunnel IPv6 entry-point node encapsulates tunnel IPv6 packets
originated from itself, and destined to itself. This can generate an
infinite processing loop in the entry-point node.
回避されなければならないカプセル化の特別のケースは、loopbackカプセル化である
(MUST)。トンネルIPv6エントリーポイントノードがそれ自体から起こされ、
それ自体に予定されたトンネルIPv6パケットをカプセルに入れる場合、
Loopbackカプセル化は起こる。
これは、エントリーポイントノードで無限ループになる。
To avoid such a case, it is recommended that an implementation have a
mechanism that checks and rejects the configuration of a tunnel in
which both the entry-point and exit-point node addresses belong to
the same node. It is also recommended that the encapsulating engine
check for and reject the encapsulation of a packet that has the pair
of tunnel entry-point and exit-point addresses identical with the
pair of original packet source and final destination addresses.
そのような場合を回避するために、インプリメンテーションにエントリーポイント
および出口ポイントのノード・アドレスの両方が同じノードに属するトンネルの
配置をチェックするおよび拒絶するメカニズムがあることは勧められる。
それはさらにそれを推薦される、カプセルに入れるエンジン・チェック、
のために、またペアのトンネルペアのオリジナルのパケット出所および最終終点
アドレスと同一のエントリーポイントおよび出口ポイントのアドレスを持っている
パケットのカプセル化を拒絶する。
4.1.3 Routing-Loop Nested Encapsulation
In the case of a forwarding path with multiple-level nested tunnels,
a routing-loop from an inner tunnel to an outer tunnel is
particularly dangerous when packets from the inner tunnels reenter an
outer tunnel from which they have not yet exited. In such a case, the
nested encapsulation becomes a recursive encapsulation with the
negative effects described in 4.1. Because each nested encapsulation
adds a tunnel header with a new hop limit value, the IPv6 hop limit
mechanism cannot control the number of times the packet reaches the
outer tunnel entry-point node, and thus cannot control the number of
recursive encapsulations.
When the path of a packet from source to final destination includes
tunnels, the maximum number of hops that the packet can traverse
should be controlled by two mechanisms used together to avoid the
negative effects of recursive encapsulation in routing loops:
Conta & Deering Standards Track [Page 15]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
(a) the original packet hop limit.
It is decremented at each forwarding operation performed on
an original packet. This includes each encapsulation of the
original packet. It does not include nested encapsulations
of the original packet
(b) the tunnel IPv6 packet encapsulation limit.
It is decremented at each nested encapsulation of the
packet.
For a discussion of the excessive encapsulation risk factors in
nested encapsulation see Appendix A.
5. Tunnel IPv6 Header
The tunnel entry-point node fills out a tunnel IPv6 main header
[IPv6-Spec] as follows:
Version:
value 6
Traffic Class:
Depending on the entry-point node tunnel configuration, the
traffic class can be set to that of either the original
packet or a pre-configured value - see section 6.4.
エントリーポイントのノードトンネル配置により、交通クラスは、
オリジナルのパケットあるいはあらかじめ形成された値の
いずれかをセットできる。
セクション6.4参照。
Flow Label:
Depending on the entry-point node tunnel configuration, the
flow label can be set to a pre-configured value. The typical
value is zero - see section 6.5.
エントリーポイントのノードトンネル配置により、フローラベルは
あらかじめ形成された値にセットできる。
典型的な値は0である。セクション6.5を参照。
Payload Length:
The original packet length, plus the length of the
encapsulating (prepended) IPv6 extension headers, if any.
カプセルに入れる(prepended)IPv6拡張ヘッダーの長さとオリジナルの
パケット長さ。
Next Header:
The next header value according to [IPv6-Spec] from the
Assigned Numbers RFC [RFC-1700 or its successors].
次のヘッダー値[RFC-1700]。
For example, if the original packet is an IPv6 packet, this
is set to:
Conta & Deering Standards Track [Page 16]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
- decimal value 41 (Assigned Next Header number for
IPv6) - if there are no tunnel extension headers.
- value 0 (Assigned Next Header number for IPv6 Hop by
Hop Options extension header) - if a hop by hop options
extension header immediately follows the tunnel IPv6
header.
- decimal value 60 (Assigned Next Header number for
IPv6 Destination Options extension header) - if a
destination options extension header immediately
follows the tunnel IPv6 header.
Hop Limit:
The tunnel IPv6 header hop limit is set to a pre-configured
value - see section 6.3.
トンネルIPv6ヘッダーホップ限界はあらかじめ形成された値に
セットされる。
The default value for hosts is the Neighbor Discovery
advertised hop limit [ND-Spec]. The default value for
routers is the default IPv6 Hop Limit value from the
Assigned Numbers RFC (64 at the time of writing this
document).
Source Address:
An IPv6 address of the outgoing interface of the tunnel
entry-point node. This address is configured as the tunnel
entry-point node address - see section 6.1.
トンネルエントリーポイントノードの出発のインターフェースの
IPv6アドレス。
このアドレスはトンネルエントリーポイントノードアドレスとして
形成される。
Destination Address:
An IPv6 address of the tunnel exit-point node. This address
is configured as the tunnel exit-point node address - see
section 6.2.
5.1 Tunnel IPv6 Extension Headers
Depending on IPv6 node configuration parameters, a tunnel entry-point
node may append to the tunnel IPv6 main header one or more IPv6
extension headers, such as a Hop-by-Hop Options header, a Routing
header, or others.
トンネルエントリーポイントノードは、IPv6ノード配置パラメーターにより
HopごとのOptionsのヘッダー、ルーティング・ヘッダーあるいは
他のように、トンネルIPv6主要なヘッダーに1つ以上のIPv6拡張ヘッダーを
追加することがある。
Conta & Deering Standards Track [Page 17]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
To limit the number of nested encapsulations of a packet, if it was
configured to do so - see section 6.6 - a tunnel entry-point includes
a Destination Options extension header containing a Tunnel
Encapsulation Limit option. If that option is the only option present
in the Destination Options header, the header has the following
format:
パケットの入れ子のカプセル化の数を制限するために、
トンネルエントリーポイントはトンネルカプセル化限界オプションを
含んでいる目的地Options拡張ヘッダーを含んでいる。
そのオプションが目的地Optionsのヘッダーの中に唯一のオプションである場合、
ヘッダーは次のフォーマットを持っている:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header |Hdr Ext Len = 0| Opt Type = 4 |Opt Data Len=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tun Encap Lim |PadN Opt Type=1|Opt Data Len=1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header:
Identifies the type of the original packet header. For
example, if the original packet is an IPv6 packet, the next
header protocol value is set to decimal value 41 (Assigned
payload type number for IPv6).
オリジナルのパケットヘッダーのタイプを識別する。
例えば、オリジナルのパケットがIPv6パケットである場合、
次のヘッダープロトコル値は、10進の値41(IPv6のための割り当てられた
ペイロード型番号)にセットされる。
Hdr Ext Len:
Length of the Destination Options extension header in 8-
octet units, not including the first 8 octets. Set to value
0, if no other options are present in this destination
options header.
Option Type:
value 4 - see section 4.1.1.
Opt Data Len:
value 1 - see section 4.1.1.
Tun Encap Lim:
8 bit unsigned integer - see section 4.1.1.
Option Type:
value 1 - PadN option, to align the header following
this header.
Opt Data Len:
value 1 - one octet of option data.
Conta & Deering Standards Track [Page 18]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Option Data:
value 0 - one zero-valued octet.
6. IPv6 Tunnel State Variables
The IPv6 tunnel state variables, some of which are or may be
configured on the tunnel entry-point node, are:
IPv6トンネル状態変数は、次のとおりです:
6.1 IPv6 Tunnel Entry-Point Node Address
The tunnel entry-point node address is one of the valid IPv6 unicast
addresses of the entry-point node - the validation of the address at
tunnel configuration time is recommended.
トンネルエントリーポイントノードアドレスは、エントリーポイントの
ノードの有効なIPv6ユニキャスト・アドレスのうちの1つである。
トンネル配置時のアドレスの確認が推薦される。
The tunnel entry-point node address is copied to the source address
field in the tunnel IPv6 header during packet encapsulation.
トンネルエントリーポイントノードアドレスは、パケットカプセル化中に、
トンネルIPv6ヘッダーの中のソースアドレスフィールドにコピーする。
6.2 IPv6 Tunnel Exit-Point Node Address
The tunnel exit-point node address is used as IPv6 destination
address for the tunnel IPv6 header. A tunnel acts like a virtual
point to point link between the entry-point node and exit-point node.
The tunnel exit-point node address is copied to the destination
address field in the tunnel IPv6 header during packet encapsulation.
The configuration of the tunnel entry-point and exit-point addresses
is not subject to IPv6 Autoconfiguration or IPv6 Neighbor Discovery.
6.3 IPv6 Tunnel Hop Limit
An IPv6 tunnel is modeled as a "single-hop virtual link" tunnel, in
which the passing of the original packet through the tunnel is like
the passing of the original packet over a one hop link, regardless of
the number of hops in the IPv6 tunnel.
IPv6トンネルは、IPv6トンネル中のホップの数にかかわらず、
「単一のホップ事実上のリンク」トンネルとしてモデル化される。
The "single-hop" mechanism should be implemented by having the tunnel
entry point node set a tunnel IPv6 header hop limit independently of
the hop limit of the original header.
「単一のホップ」メカニズムは、オリジナルのヘッダーのホップ限界と
無関係にトンネル・エントリー・ポイントノードにトンネルIPv6ヘッダーホップ
限界をセットさせることによってインプリメントされるべきである。
The "single-hop" mechanism hides from the original IPv6 packets the
number of IPv6 hops of the tunnel.
It is recommended that the tunnel hop limit be configured with a
value that ensures:
Conta & Deering Standards Track [Page 19]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
(a) that tunnel IPv6 packets can reach the tunnel exit-point
node
(b) a quick expiration of the tunnel packet if a routing loop
occurs within the IPv6 tunnel.
The tunnel hop limit default value for hosts is the IPv6 Neighbor
Discovery advertised hop limit [ND-Spec]. The tunnel hop limit
default value for routers is the default IPv6 Hop Limit value from
the Assigned Numbers RFC (64 at the time of writing this document).
The tunnel hop limit is copied into the hop limit field of the tunnel
IPv6 header of each packet encapsulated by the tunnel entry-point
node.
6.4 IPv6 Tunnel Packet Traffic Class
The IPv6 Tunnel Packet Traffic Class indicates the value that a
tunnel entry-point node sets in the Traffic Class field of a tunnel
header. The default value is zero. The configured Packet Traffic
Class can also indicate whether the value of the Traffic Class field
in the tunnel header is copied from the original header, or it is set
to the pre-configured value.
IPv6トンネル・パケットトラフィック交通クラスは、トンネルヘッダーの
トラフィッククラス分野でトンネルエントリーポイントノードがセットする
値を示す。デフォルト値は0である。
形成されたパケットトラフィッククラスは、さらにトンネルヘッダーの中の
交通クラスフィールドの値がオリジナルのヘッダーからコピーされるか
どうか示すことができる。
あるいは、それはあらかじめ設定された値にセットされる。
6.5 IPv6 Tunnel Flow Label
The IPv6 Tunnel Flow Label indicates the value that a tunnel entry-
point node sets in the flow label of a tunnel header. The default
value is zero.
IPv6トンネルフローラベルは、トンネルエントリーのトンネルヘッダーのフ
ローラベル中のポイントノードセットの値を示す。
デフォルトは0である。
6.6 IPv6 Tunnel Encapsulation Limit
The Tunnel Encapsulation Limit value can indicate whether the entry-
point node is configured to limit the number of encapsulations of
tunnel packets originating on that node. The IPv6 Tunnel
Encapsulation Limit is the maximum number of additional
encapsulations permitted for packets undergoing encapsulation at that
entry-point node. recommended default value is 4. An entry-point node
configured to limit the number of nested encapsulations prepends a
Destination Options extension header containing a Tunnel
Encapsulation Limit option to an original packet undergoing
encapsulation - see sections 4.1 and 4.1.1.
トンネルカプセル化限界値は、エントリーポイントノードで、
そのノード上で親トンネル・パケットのカプセル化の数を制限するために
設定される。
IPv6トンネル・カプセル化限界はそのエントリーポイントのノードで
パケットのカプセル化を行える、カプセル化の最大の数である。
推薦するデフォルトは4である。
6.7 IPv6 Tunnel MTU
The tunnel MTU is set dynamically to the Path MTU between the tunnel
entry-point and the tunnel exit-point nodes, minus the size of the
tunnel headers: the maximum size of a tunnel packet payload that can
Conta & Deering Standards Track [Page 20]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
be sent through the tunnel without fragmentation [IPv6-Spec]. The
tunnel entry-point node performs Path MTU discovery on the path
between the tunnel entry-point and exit-point nodes [PMTU-Spec],
[ICMP-Spec]. The tunnel MTU of a nested tunnel is the tunnel MTU of
the outer tunnel minus the size of the nested tunnel headers.
トンネルMTUは、トンネルヘッダーのサイズを引いて、トンネルエントリーポイント
とトンネル出口ポイントノードの間のパスMTUにダイナミックにセットされる
分割ないトンネルを通って送ることができるトンネルパケットペイロードの
最大のサイズ。
トンネルエントリーポイントノードは、トンネルエントリーポイントおよび
出口ポイントのノードの間のパス上でパスMTUを発見する。
入れ子のトンネルのトンネルMTUは入れ子のトンネル・ヘッダーのサイズを
引いた外部のトンネルのトンネルMTUである。
7. IPv6 Tunnel Packet Size Issues
Prepending a tunnel header increases the size of a packet, therefore
a tunnel packet resulting from the encapsulation of an IPv6 original
packet may require fragmentation.
A tunnel IPv6 packet resulting from the encapsulation of an original
packet is considered an IPv6 packet originating from the tunnel
entry-point node. Therefore, like any source of an IPv6 packet, a
tunnel entry-point node must support fragmentation of tunnel IPv6
packets.
オリジナルのパケットのカプセル化に起因するトンネルIPv6パケットは、トンネル
エントリーポイントノードから起こるIPv6パケットと考えられる。
したがって、IPv6パケットの任意のソースのように、トンネルエントリーポイント
ノードは、トンネルIPv6パケットの分割を支援しなければならない。
A tunnel intermediate node that forwards a tunnel packet to another
node in the tunnel follows the general IPv6 rule that it must not
fragment a packet undergoing forwarding.
A tunnel exit-point node receiving tunnel packets at the end of the
tunnel for decapsulation applies the strict left-to-right processing
rules for extension headers. In the case of a fragmented tunnel
packet, the fragments are reassembled into a complete tunnel packet
before determining that an embedded packet is present.
Note:
A particular problem arises when the destination of a fragmented
tunnel packet is an exit-point node identified by an anycast address.
The problem, which is similar to that of original fragmented IPv6
packets destined to nodes identified by an anycast address, is that
all the fragments of a packet must arrive at the same destination
node for that node to be able to perform a successful reassembly, a
requirement that is not necessarily satisfied by packets sent to an
anycast address.
7.1 IPv6 Tunnel Packet Fragmentation
When an IPv6 original packet enters a tunnel, if the original packet
size exceeds the tunnel MTU (i.e., the Path MTU between the tunnel
entry-point and the tunnel exit-point, minus the size of the tunnel
header(s)), it is handled as follows:
IPv6オリジナルパケットがトンネルに入る時、オリジナルのパケットサイズが、
トンネルMTU(トンネルヘッダのサイズを引いた、トンネルエントリーポイント
とトンネル出口ポイントの間のパスMTU)を超えると、以下のように扱われます:
Conta & Deering Standards Track [Page 21]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
(a) if the original IPv6 packet size is larger than the IPv6
minimum link MTU [IPv6-Spec], the entry-point node discards
the packet and sends an ICMPv6 "Packet Too Big" message to
the source address of the original packet with the
recommended MTU size field set to the tunnel MTU or the
IPv6 minimum link MTU, whichever is larger, i.e. max
(tunnel MTU, IPv6 minimum link MTU). Also see sections 6.7
and 8.2.
(a)、オリジナルIPv6パケットサイズが、IPv6最小リンクMTUより大きい場合、
エントリーポイントのノードはパケットを廃棄し、
ICMPv6を送ります。
(b) if the original IPv6 packet is equal or smaller than the
IPv6 minimum link MTU, the tunnel entry-point node
encapsulates the original packet, and subsequently
fragments the resulting IPv6 tunnel packet into IPv6
fragments that do not exceed the Path MTU to the tunnel
exit-point.
(b) オリジナルのIPv6パケットが等しいか、IPv6最小リンクMTUより
小さい場合、トンネルエントリーポイントノードはオリジナルパケット
をカプセル化し、トンネル出口ポイントのパスMTUを超えない
IPv6トンネル・パケットをフラグメントします。
7.2 IPv4 Tunnel Packet Fragmentation
When an IPv4 original packet enters a tunnel, if the original packet
size exceeds the tunnel MTU (i.e., the Path MTU between the tunnel
entry-point and the tunnel exit-point, minus the size of the tunnel
header(s)), it is handled as follows:
IPv4オリジナルパケットがトンネルに入る場合、オリジナルパケットサイズが
トンネルMTUを超過すれば、以下のように扱われる
(a) if in the original IPv4 packet header the Don't Fragment -
DF - bit flag is SET, the entry-point node discards the
packet and returns an ICMP message. The ICMP message has
the type = "unreachable", the code = "packet too big", and
the recommended MTU size field set to the size of the
tunnel MTU - see sections 6.7 and 8.3.
(b) if in the original packet header the Don't Fragment - DF -
bit flag is CLEAR, the tunnel entry-point node encapsulates
the original packet, and subsequently fragments the
resulting IPv6 tunnel packet into IPv6 fragments that do
not exceed the Path MTU to the tunnel exit-point.
8. IPv6 Tunnel Error Processing and Reporting
IPv6 Tunneling follows the general rule that an error detected during
the processing of an IPv6 packet is reported through an ICMP message
to the source of the packet.
IPv6トンネリングは、ICMPメッセージによって、パケットのソースに
IPv6パケットの処理中のエラーが報告される。
On a forwarding path that includes IPv6 tunnels, an error detected by
a node that is not in any tunnel is directly reported to the source
of the original IPv6 packet.
IPv6トンネルを含んでいるフォワーディングパス上で、任意のトンネルの中
にないノードによって検知されたエラーは、オリジナルのIPv6パケットの
ソースに直接報告される。
Conta & Deering Standards Track [Page 22]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
An error detected by a node inside a tunnel is reported to the source
of the tunnel packet, that is, the tunnel entry-point node. The ICMP
message sent to the tunnel entry-point node has as ICMP payload the
tunnel IPv6 packet that has the original packet as its payload.
The cause of a packet error encountered inside a tunnel can be a
problem with:
トンネル内部のノードによって検知されたエラーは、トンネルパケットの
ソース(トンネルエントリーポイントノード)に報告される。
トンネルエントリーポイントノードに送られたICMPメッセージは、
ICMPペイロードとしてそのペイロードとしてオリジナルのパケットを
持っている。
(a) the tunnel header, or
(b) the tunnel packet.
Both tunnel header and tunnel packet problems are reported to the
tunnel entry-point node.
トンネル・ヘッダー、トンネル・パケットの両方の問題は、
トンネルエントリーポイントノードに報告される。
If a tunnel packet problem is a consequence of a problem with the
original packet, which is the payload of the tunnel packet, then the
problem is also reported to the source of the original packet.
トンネルパケットの問題が、オリジナルのパケットに関する問題である場合、
その問題はオリジナルのパケットのソースに報告される。
To report a problem detected inside the tunnel to the source of an
original packet, the tunnel entry point node must relay the ICMP
message received from inside the tunnel to the source of that
original IPv6 packet.
オリジナルのパケットのソースへのトンネルの内部で問題が検知したと報告
するために、トンネルエントリーポイントノードは、オリジナルのIPv6パケットを
内部から受け取られたICMPメッセージを中継しなければならない。
An example of the processing that can take place in the error
reporting mechanism of a node is illustrated in Fig.7, and Fig.8:
Fig.7 path #0 and Fig.8 (a) - The IPv6 tunnel entry-point receives an
ICMP packet from inside the tunnel, marked Tunnel ICMPv6 Message in
Fig.7. The tunnel entry-point node IPv6 layer passes the received
ICMP message to the ICMPv6 Input. The ICMPv6 Input, based on the ICMP
type and code [ICMP-Spec] generates an internal "error code".
Fig.7 path #1 - The internal error code, is passed with the "ICMPv6
message payload" to the upper-layer protocol - in this case the IPv6
tunnel upper-layer error input.
Conta & Deering Standards Track [Page 23]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
+-------+ +-------+ +-----------------------+
| Upper | | Upper | | Upper |
| Layer | | Layer | | Layer |
| Proto.| | Proto | | IPv6 Tunnel |
| Error | | Error | | Error |
| Input | | Input | | Input |
| | | | | Decapsulate |
| | | | | -->--ICMPv6--#2->-- |
| | | | | | Payload | |
+-------+ +-------+ +--|-----------------|--+
| | | |
^ ^ ^ v
| | | |
--------------------#1-- -----Orig.Packet?--- - - - - - - -
#1 #3 Int.Error Code, #5 |
Int.Error Code,^ v Source Address, v v
ICMPv6 Payload | IPv6 | Orig. Packet | IPv4 |
+--------------+ +------------+ +------------+ + - - +
| | | | | |
| ICMP v6 | | ICMP v6 | | ICMP v4 | | |
| Input | | Err Report | | Err Report |
| - - - - +----+ - - - -| + - - - -+ + - - +
| | | |
| IPv6 Layer | | IPv4 Layer | | |
| | | |
+--------------------------------+ +------------+ + - - +
| | |
^ V V
#0 #4 #6
| | |
Tunnel ICMPv6 ICMPv6 ICMPv4
Message Message Message
| | |
Fig.7 Error Reporting Flow in a Node (IPv6 Tunneling Protocol Engine)
Fig.7 path #2 and Fig.8 (b) - The IPv6 tunnel error input
decapsulates the tunnel IPv6 packet, which is the ICMPv6 message
payload, obtaining the original packet, and thus the original headers
and dispatches the "internal error code", the source address from the
original packet header, and the original packet, down to the error
report block of the protocol identified by the Next Header field in
the tunnel header immediately preceding the original packet in the
ICMP message payload.
From here the processing depends on the protocol of the original
packet:
Conta & Deering Standards Track [Page 24]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
(a) - for an IPv6 original packet
Fig.7 path #3 and Fig.8 (c.1)- for an IPv6 original packet, the
ICMPv6 error report builds an ICMP message of a type and code
according to the "internal error code", containing the "original
packet" as ICMP payload.
Fig.7 path #4 and Fig.8 (d.1)- The ICMP message has the tunnel
entry-point node address as source address, and the original packet
source node address as destination address. The tunnel entry-point
node sends the ICMP message to the source node of the original
packet.
(b) - for an IPv4 original packet
Fig.7 path #5 and Fig.8 (c.2) - for an IPv4 original packet, the
ICMPv4 error report builds an ICMP message of a type and code
derived from the the "internal error code", containing the
"original packet" as ICMP payload.
Fig.7 path #6 and Fig.8 (d.2) - The ICMP message has the tunnel
entry-point node IPv4 address as source address, and the original
packet IPv4 source node address as destination address. The tunnel
entry-point node sends the ICMP message to the source node of the
original packet.
A graphical description of the header processing taking place is the
following:
ヘッダー処理は下記の通り
Conta & Deering Standards Track [Page 25]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
< Tunnel Packet >
+--------+- - - - - -+--------+------------------------------//------+
| IPv6 | IPv6 | ICMP | Tunnel |
(a)| | Extension | | IPv6 |
| Header | Headers | Header | Packet in error |
+--------+- - - - - -+--------+------------------------------//------+
< Tunnel Headers > < Tunnel ICMP Message >
< ICMPv6 Message Payload >
|
v
< Tunnel ICMP Message >
< Tunnel IPv6 Packet in Error >
+--------+ +---------+ +----------+--------//------+
| ICMP | | Tunnel | | Original | Original |
(b) | | + | IPv6 | + | | Packet |
| Header | | Headers | | Headers | Payload |
+--------+ +---------+ +----------+--------//------+
|
----------------- |
| |
--------------|---------------
| |
V V
+---------+ +--------+ +-------------------//------+
| New | | ICMP | | |
(c.1) | IPv6 | + | | + | Orig. Packet in Error |
| Headers | | Header | | |
+---------+ +--------+ +-------------------//------+
|
v
+---------+--------+-------------------//------+
| New | ICMP | Original |
(d.1) | IPv6 | | |
| Headers | Header | Packet in Error |
+---------+--------+-------------------//------+
< New ICMP Message >
Conta & Deering Standards Track [Page 26]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
or for an IPv4 original packet
+---------+ +--------+ +-------------------//------+
| New | | ICMP | | |
(c.2) | IPv4 | + | | + | Orig. Packet in Error |
| Header | | Header | | |
+---------+ +--------+ +-------------------//------+
|
v
+---------+--------+-------------------//------+
| New | ICMP | Original |
(d.2) | IPv4 | | |
| Header | Header | Packet in Error |
+---------+--------+-------------------//------+
< New ICMP Message >
Fig.8 ICMP Error Reporting and Processing
8.1 Tunnel ICMP Messages
The tunnel ICMP messages that are reported to the source of the
original packet are:
hop limit exceeded
The tunnel has a misconfigured hop limit, or contains a
routing loop, and packets do not reach the tunnel exit-
point node. This problem is reported to the tunnel entry-
point node, where the tunnel hop limit can be reconfigured
to a higher value. The problem is further reported to the
source of the original packet as described in section 8.2,
or 8.3.
トンネルは誤形成されたホップ限界を持っているか
ルーティングループを含んでいる。パケットはトンネル出口
ポイントノードに到着していない。
この問題はトンネルエントリーへ報告される。
より高い値にトンネル・ホップ限界を再構成できる場合、
ノードを指示する。
unreachable node
One of the nodes in the tunnel is not or is no longer
reachable. This problem is reported to the tunnel entry-
point node, which should be reconfigured with a valid and
active path between the entry and exit-point of the tunnel.
到達可能ではないトンネル中のノード。
この問題は、トンネルエントリーポイントノードへ報告される。
The problem is further reported to the source of the
original packet as described in section 8.2, or 8.3.
parameter problem
A Parameter Problem ICMP message pointing to a valid Tunnel
Encapsulation Limit Destination header with a Tun Encap Lim
field value set to one is an indication that the tunnel
Conta & Deering Standards Track [Page 27]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
packet exceeded the maximum number of encapsulations
allowed. The problem is further reported to the source of
the original packet as described in section 8.2, or 8.3.
フィールド値セットを備えた有効なトンネル・カプセル化限界目的地
ヘッダーを指すパラメーター問題メッセージは、トンネルパケットが
許可されたカプセル化の最大の数を超過したという徴候である。
The above three problems detected inside the tunnel, which are a
tunnel configuration and a tunnel topology problem, are reported to
the source of the original IPv6 packet, as a tunnel generic
"unreachable" problem caused by a "link problem" - see section 8.2
and 8.3.
packet too big
The tunnel packet exceeds the tunnel Path MTU.
トンネル・パケットはトンネルパスMTUを超過する。
The information carried by this type of ICMP message is
used as follows:
- by a receiving tunnel entry-point node to set or adjust
the tunnel MTU
- by a sending tunnel entry-point node to indicate to the
source of an original packet the MTU size that should be
used in sending IPv6 packets towards the tunnel entry-point
node.
8.2 ICMP Messages for IPv6 Original Packets
The tunnel entry-point node builds the ICMP and IPv6 headers of the
ICMP message that is sent to the source of the original packet as
follows:
トンネルエントリーポイントノードは、ICMPとICMPメッセージのIPv6のヘッダーを
構築し、以下のようにオリジナルのパケットのソース送られる。
IPv6 Fields:
Source Address
A valid unicast IPv6 address of the outgoing
interface.
Destination Address
Copied from the Source Address field of the Original
IPv6 header.
ICMP Fields:
For any of the following tunnel ICMP error messages:
"hop limit exceeded"
Conta & Deering Standards Track [Page 28]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
"unreachable node"
"parameter problem" - pointing to a valid Tunnel Encapsulation
Limit destination header with the Tun Encap Lim field set to a
value zero:
Type 1 - unreachable node
Code 3 - address unreachable
For tunnel ICMP error message "packet too big":
Type 2 - packet too big
Code 0
MTU The MTU field from the tunnel ICMP message minus
the length of the tunnel headers.
According to the general rules described in 7.1, an ICMP "packet too
big" message is sent to the source of the original packet only if the
original packet size is larger than the minimum link MTU size
required for IPv6 [IPv6-Spec].
7.1に記述された規則により、ICMP「パケット too big」オリジナルの
パケットサイズがIPv6のために必要になった最小のリンクMTUサイズより
大きい場合のみ、メッセージはオリジナルのパケットのソースに送られる
8.3 ICMP Messages for IPv4 Original Packets
The tunnel entry-point node builds the ICMP and IPv4 header of the
ICMP message that is sent to the source of the original packet as
follows:
トンネルエントリーポイントノードは、オリジナルのパケットのソースに
ICMPおよびICMPメッセージのIPv4ヘッダーを
構築し、以下のようにオリジナルのパケットのソース送られる。
IPv4 Fields:
Source Address
A valid unicast IPv4 address of the outgoing
interface.
Destination Address
Copied from the Source Address field of the Original
IPv4 header.
ICMP Fields:
For any of the following tunnel ICMP error messages:
"hop limit exceeded"
Conta & Deering Standards Track [Page 29]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
"unreachable node"
"parameter problem" - pointing to a valid Tunnel Enacpsulation
Limit destination header with the Tun Encap Lim field set to a
value zero:
Type 3 - destination unreachable
Code 1 - host unreachable
For a tunnel ICMP error message "packet too big":
Type 3 - destination unreachable
Code 4 - packet too big
MTU The MTU field from the tunnel ICMP message minus
the length of the tunnel headers.
According to the general rules described in section 7.2, an ICMP
"packet too big" message is sent to the original IPv4 packet source
node if the the original IPv4 header has the DF - don't fragment -
bit flag SET.
7.2に記述された規則により、ICMP「パケット too big」メッセージは、
オリジナルのIPv4パケット出所ノードに送られる、オリジナルのIPv4ヘッダーは
DF(フラグメントしない）ビットフラグSETを持っている。
8.4 ICMP Messages for Nested Tunnel Packets
In case of an error uncovered with a nested tunnel packet, the inner
tunnel entry-point, which receives the ICMP error message from the
inner tunnel reporting node, relays the ICMP message to the outer
tunnel entry-point following the mechanisms described in sections
8.,8.1, 8.2, and 8.3. Further, the outer tunnel entry-point relays
the ICMP message to the source of the original packet, following the
same mechanisms.
入れ子のトンネルパケットを許可しないエラーの場合には、
内部のトンネルエントリーポイントが、外部のトンネルエントリーポイントへ
のICMPメッセージを中継する。
さらに、外部のトンネルエントリーポイントは、同じメカニズムなので
オリジナルのパケットのソースへICMPメッセージを中継する。
9. Security Considerations
An IPv6 tunnel can be secured by securing the IPv6 path between the
tunnel entry-point and exit-point node. The security architecture,
mechanisms, and services are described in [RFC2401], [RFC2402], and
[RFC2406]. A secure IPv6 tunnel may act as a gateway-to-gateway
secure path as described in [RFC2401].
IPv6トンネルは、トンネル・エントリーポイントおよび出口ポイントのノードの
間のIPv6パスを安全にすることことができる。
セキュリティアーキテクチャー、メカニズムおよびサービスは[RFC2401]、
[RFC2402]および[RFC2406]に記述される。
安全なIPv6トンネルは、[RFC2401]に記述されるような通路から通路への安全な
パスの役割をすることがある。
For a secure IPv6 tunnel, in addition to the mechanisms described
earlier in this document, the entry-point node of the tunnel performs
security algorithms on the packet and prepends as part of the tunnel
headers one or more security headers in conformance with [IPv6-Spec],
[RFC2401], and [RFC2402], or [RFC2406].
安全なIPv6トンネルについては、このドキュメント以前に記述された下記を参照。
トンネルのエントリーポイントのノードがトンネルヘッダーの一部として
パケットおよびprepends上でのセキュリティアルゴリズム[IPv6スペック(IPv6-Spec)]
[RFC2401]および[RFC2402]あるいは[RFC2406]の中のセキュリティ・ヘッダ。
Conta & Deering Standards Track [Page 30]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
The exit-point node of a secure IPv6 tunnel performs security
algorithms and processes the tunnel security header[s] as part of the
tunnel headers processing described earlier, and in conformance with
[RFC2401], and [RFC2402], or [RFC2406]. The exit-point node discards
the tunnel security header[s] with the rest of the tunnel headers
after tunnel headers processing completion.
The degree of integrity, authentication, and confidentiality and the
security processing performed on a tunnel packet at the entry-point
and exit-point node of a secure IPv6 tunnel depend on the type of
security header - authentication (AH) or encryption (ESP) - and
parameters configured in the Security Association for the tunnel.
There is no dependency or interaction between the security level and
mechanisms applied to the tunnel packets and the security applied to
the original packets which are the payloads of the tunnel packets.
In case of nested tunnels, each inner tunnel may have its own set of
security services, independently from those of the outer tunnels, or
of those between the source and destination of the original packet.
完全、認証および機密性の程度、および、安全なIPv6トンネルの
エントリーポイントおよび出口ポイントのノードでトンネル・パケット上で
実行されたセキュリティ処理は、トンネルをセキュリティ協会
(Security Association)で形成されたセキュリティ・ヘッダー(認証(AH)
あるいは暗号化(ESP))およびパラメーターのタイプに依存する。
トンネル・パケットのペイロードである、オリジナルのパケットに適用された、
トンネル・パケットおよびセキュリティに適用されたセキュリティレベルと
メカニズムの間に依存性か相互作用はいない。
入れ子のトンネルの場合には、個々の内部のトンネルが、外部のトンネル、
あるいはオリジナルのパケットのソースおよび目的地の間のもののものから
セキュリティ・サービスを独立して持つ。
10. Acknowledgments
This document is partially derived from several discussions about
IPv6 tunneling on the IPng Working Group Mailing List and from
feedback from the IPng Working Group to an IPv6 presentation that
focused on IPv6 tunneling at the 33rd IETF, in Stockholm, in July
1995.
Additionally, the following documents that focused on tunneling or
encapsulation were helpful references: RFC 1933 (R. Gilligan, E.
Nordmark), RFC 1241 (R. Woodburn, D. Mills), RFC 1326 (P. Tsuchiya),
RFC 1701, RFC 1702 (S. Hanks, D. Farinacci, P. Traina), RFC 1853 (W.
Simpson), as well as RFC 2003 (C. Perkins).
Brian Carpenter, Richard Draves, Bob Hinden, Thomas Narten, Erik
Nordmark (in alphabetical order) gave valuable reviewing comments and
suggestions for the improvement of this document. Scott Bradner, Ross
Callon, Dimitry Haskin, Paul Traina, and James Watt (in alphabetical
order) shared their view or experience on matters of concern in this
document. Judith Grossman provided a sample of her many years of
editorial and writing experience as well as a good amount of probing
technical questions.
11. References
[IPv6-Spec] Deering, S. and R. Hinden, "Internet Protocol
Version 6 (IPv6) Specification", RFC 2460, December 1998.
Conta & Deering Standards Track [Page 31]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
[ICMP-Spec] Conta, A. and S. Deering "Internet Control Message
Protocol for the Internet Protocol Version 6 (IPv6)", RFC
2463, December 1998.
[ND-Spec] Narten, T., Nordmark, E., and W. Simpson "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[PMTU-Spec] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery
for IP Version 6 (IPv6)", RFC 1981, August 1996.
[RFC2401] Atkinson, R., "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[RFC2402] Atkinson, R., "IP Authentication Header", RFC 2402,
November 1998.
[RFC2406] Atkinson, R., "IP Encapsulation Security Payload (ESP)",
RFC 2406, November 1998.
[RFC-1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October
1995.
[Assign-Nr] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. See also:
http://www.iana.org/numbers.html
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Alex Conta
Lucent Technologies Inc.
300 Baker Ave
Concord, MA 01742-2168
+1-978-287-2842
EMail: aconta@lucent.com
Stephen Deering
Cisco Systems
170 West Tasman Dr
San Jose, CA 95132-1706
Phone: +1-408-527-8213
EMail: deering@cisco.com
Conta & Deering Standards Track [Page 32]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Appendix A
A.1 Risk Factors in Nested Encapsulation
Nested encapsulations of a packet become a recursive encapsulation if
the packet reenters an outer tunnel before exiting it. The cases
which present a high risk of recursive encapsulation are those in
which a tunnel entry-point node cannot determine whether a packet
that undergoes encapsulation reenters the tunnel before exiting it.
Routing loops that cause tunnel packets to reenter a tunnel before
exiting it are certainly the major cause of the problem. But since
routing loops exist, and happen, it is important to understand and
describe, the cases in which the risk for recursive encapsulation is
higher.
There are two significant elements that determine the risk factor of
routing loop recursive encapsulation:
(a) the type of tunnel,
(b) the type of route to the tunnel exit-point, which
determines the packet forwarding through the tunnel, that
is, over the tunnel virtual-link.
A.1.1 Risk Factor in Nested Encapsulation
- type of tunnel.
The type of tunnels which were identified as a high risk factor for
recursive encapsulation in routing loops are:
"inner tunnels with identical exit-points".
ループのルーティングさせる際の、再帰的なカプセル化における
高い危険要因のトンネルのタイプは次のとおりである
「同一の出口ポイントを備えた内部のトンネル。」
Since the source and destination of an original packet is the main
information used to decide whether to forward a packet through a
tunnel or not, a recursive encapsulation can be avoided in case of a
single tunnel (non-inner), by checking that the packet to be
encapsulated is not originated on the entry-point node. This
mechanism is suggested in [RFC-1853].
オリジナルのパケットのソースおよび目的地が、
トンネルを通ってパケットを転送するべきかどうか決定するために
使用される主要な情報であるので、再帰的なカプセル化は、
カプセルに入れられるパケットがエントリーポイントのノード上で
起こされないことをチェックすることによって、
単一のトンネルの場合には回避できる。
このメカニズムは[RFC-1853]の中で示唆される。
However, this type of protection does not seem to work well in case
of inner tunnels with different entry-points, and identical exit-
points.
しかし、この種のプロテクトは、異なるエントリーポイントを備えた
内部トンネル、および同一の出口ポイントの場合にはうまくいかない。
Inner tunnels with different entry-points and identical exit-points
introduce ambiguity in deciding whether to encapsulate a packet, when
a packet encapsulated in an inner tunnel reaches the entry-point node
of an outer tunnel by means of a routing loop. Because the source of
the tunnel packet is the inner tunnel entry-point node which is
different than the entry-point node of the outer tunnel, the source
Conta & Deering Standards Track [Page 33]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
address checking (mentioned above) fails to detect an invalid
encapsulation, and as a consequence the tunnel packet gets
encapsulated at the outer tunnel each time it reaches it through the
routing loop.
トンネルパケットのソースが外部のトンネルのエントリーポイントのノードと
異なる内部のトンネル・エントリーポイントノードなので、
ソースアドレスチェックは無効のカプセル化を検知しない。
結果、それがルーティング・ループによってそれに達するごとに、
トンネルパケットは外部のトンネルでカプセルに入れられる。
A.1.2 Risk Factor in Nested Encapsulation
- type of route.
The type of route to a tunnel exit-point node has been also
identified as a high risk factor of recursive encapsulation in
routing loops.
One type of route to a tunnel exit-point node is a route to a
specified destination node, that is, the destination is a valid
specified IPv6 address (route to node). Such a route can be selected
based on the longest match of an original packet destination address
with the destination address stored in the tunnel entry-point node
routing table entry for that route. The packet forwarded on such a
route is first encapsulated and then forwarded towards the tunnel
exit-point node.
Another type of route to a tunnel exit-point node is a route to a
specified prefix-net, that is, the destination is a valid specified
IPv6 prefix (route to net). Such a route can be selected based on the
longest path match of an original packet destination address with the
prefix destination stored in the tunnel entry-point node routing
table entry for that route. The packet forwarded on such a route is
first encapsulated and then forwarded towards the tunnel exit-point
node.
And finally another type of route to a tunnel exit-point is a default
route, or a route to an unspecified destination. This route is
selected when no-other match for the destination of the original
packet has been found in the routing table. A tunnel that is the
first hop of a default route is a "default tunnel".
If the route to a tunnel exit-point is a route to node, the risk
factor for recursive encapsulation is minimum.
If the route to a tunnel exit-point is a route to net, the risk
factor for recursive encapsulation is medium. There is a range of
destination addresses that will match the prefix the route is
associated with. If one or more inner tunnels with different tunnel
entry-points have exit-point node addresses that match the route to
net of an outer tunnel exit-point, then a recursive encapsulation may
occur if a tunnel packet gets diverted from inside such an inner
tunnel to the entry-point of the outer tunnel that has a route to its
exit-point that matches the exit-point of an inner tunnel.
Conta & Deering Standards Track [Page 34]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
If the route to a tunnel exit-point is a default route, the risk
factor for recursive encapsulation is maximum. Packets are forwarded
through a default tunnel for lack of a better route. In many
situations, forwarding through a default tunnel can happen for a wide
range of destination addresses which at the maximum extent is the
entire Internet minus the node's link. As consequence, it is likely
that in a routing loop case, if a tunnel packet gets diverted from an
inner tunnel to an outer tunnel entry-point in which the tunnel is a
default tunnel, the packet will be once more encapsulated, because
the default routing mechanism will not be able to discern
differently, based on the destination.
Conta & Deering Standards Track [Page 35]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Conta & Deering Standards Track [Page 36]