[要約] RFC 2473は、IPv6での汎用パケットトンネリングの仕様を定めたものであり、IPv6パケットのトンネリングに関する手法とプロトコルを提供しています。このRFCの目的は、異なるネットワーク間でのIPv6パケットのトンネリングを可能にし、ネットワークの相互接続性を向上させることです。
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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カプセル化のモデルと一般的なメカニズムを定義します。モデルとメカニズムは、AppleTalk、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
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
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ヘッダーを付加することによって実現されます。これらの先頭に付加されたヘッダーは、転送パスを識別します。
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 NOT、MAY NOT、MAY、OPTIONAL、REQUIRED、RECOMMENDED、SHALL、SHALL NOT、SHOULD、SHOULD NOTは、RFC 2119で定義されているとおりに解釈されます。
original packet
元のパケット
a packet that undergoes encapsulation.
カプセル化されるパケット。
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.
カプセル化中に元のパケットの前に付加されるヘッダー。トンネルのエンドポイントをソースおよび宛先として指定します。
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
IPv6トンネル
a tunnel configured as a virtual link between two IPv6 nodes, on which the encapsulating protocol is IPv6.
カプセル化プロトコルがIPv6である2つのIPv6ノード間の仮想リンクとして構成されたトンネル。
tunnel MTU
トンネル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.
トンネルパケットがトンネルエントリポイントからトンネル出口ポイントに移動できる最大ホップ数。
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.
パケットのネストされたカプセル化の最大数。
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ノード間に「仮想リンク」を確立するための技術です（図1を参照）。 2つのノードから見ると、IPv6トンネルと呼ばれるこの「仮想リンク」は、IPv6がリンク層プロトコルのように機能するポイントツーポイントリンクとして表示されます。 2つのIPv6ノードは特定の役割を果たします。 1つのノードは、他のノードまたはそれ自体から受信した元のパケットをカプセル化し、結果のトンネルパケットをトンネル経由で転送します。もう一方のノードは、受信したトンネルパケットのカプセル化を解除し、結果の元のパケットを宛先（おそらくはそれ自体）に転送します。カプセル化ノードはトンネルエントリポイントノードと呼ばれ、トンネルパケットのソースです。カプセル開放ノードはトンネル出口ポイントと呼ばれ、トンネルパケットの宛先です。
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つのノード間のトンネルについて言及しています。このようなトンネルは、「仮想ポイントツーポイントリンク」のように見えます。ここで説明するメカニズムは、エニーキャストやマルチキャストなど、他のタイプのアドレスによって出口ポイントノードが識別されるトンネルにも適用されます。これらのトンネルは、「仮想ポイントツーマルチポイントリンク」のように見える場合があります。このドキュメントの執筆時点では、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トンネルのエントリポイントノードと出口ポイントノードの間で一方向に行われます（図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
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つのトンネルをそれぞれ反対方向に設定します。一方のトンネルのエントリポイントノードは、もう一方のトンネルの出口ポイントノードです（図2を参照）。 ）。
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拡張ヘッダーのセット（図3を参照）で構成されます。これらはまとめてトンネル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の元のヘッダー存続時間フィールド（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
<Tunnel IPv6 Headers> < Original Packet >
+---------+ - - - - - +-------------------------//--------------+
| IPv6 | IPv6 | |
| | Extension | Original Packet |
| Header | Headers | |
+---------+ - - - - - +-------------------------//--------------+
< Tunnel IPv6 Packet >
Fig.3 Encapsulating a Packet
図3パケットのカプセル化
Tunnel extension headers should appear in the order recommended by the specifications that define the extension headers, such as [IPv6- Spec].
トンネル拡張ヘッダーは、[IPv6- Spec]などの拡張ヘッダーを定義する仕様で推奨されている順序で表示される必要があります。
A source of original packets and a tunnel entry-point that encapsulates those packets can be the same node.
元のパケットのソースとそれらのパケットをカプセル化するトンネルエントリポイントは、同じノードにすることができます。
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トンネルパケットを処理します。たとえば、トンネルのホップバイホップオプション拡張ヘッダーは、トンネル内の各受信ノードによって処理されます。トンネルルーティング拡張ヘッダーは、中間処理ノードを識別し、トンネルを通過するトンネルパケットの転送パスをより細かく制御します。トンネルの宛先オプション拡張ヘッダーは、トンネル出口ポイントノードで処理されます。
Decapsulation is graphically shown in Fig.4:
カプセル開放は図4にグラフで示されています：
+---------+- - - - - -+----------------------------------//-----+
| IPv6 | IPv6 | |
| | Extension | Original Packet |
| Header | Headers | |
+---------+- - - - - -+----------------------------------//-----+
< Tunnel IPv6 Packet >
|
v
+----------------------------------//-----+
| Original | |
| | Original Packet Payload |
| Headers | |
+----------------------------------//-----+
< Original Packet >
Fig.4 Decapsulating a Packet
図4パケットのカプセル化解除
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プロトコルレイヤーがトンネルヘッダーを処理します。拡張ヘッダーには厳密な左から右への処理ルールが適用されます。処理が完了すると、制御は次のプロトコルエンジンに渡されます。これは、最後に処理されたヘッダーのNext Headerフィールドの値によって識別されます。これがトンネルプロトコル値に設定されている場合、トンネルプロトコルエンジンはトンネルヘッダーを破棄し、結果の元のパケットを、その値で識別されるインターネットまたは下位層プロトコルに渡してさらに処理します。
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.
たとえば、[次のヘッダー]フィールドにIPv6トンネルプロトコルの値がある場合、結果の元のパケットはIPv6プロトコルレイヤーに渡されます。
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.
トンネルパケットのカプセル化を解除するトンネル出口ポイントノードと、結果の元のパケットを受信する宛先ノードは、同じノードにすることができます。
Packet flow (paths #1-7) through the IPv6 Tunnel Protocol Engine on a node is graphically shown in Fig.5:
ノード上のIPv6トンネルプロトコルエンジンを通るパケットフロー（パス＃1〜7）を図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.
図5の上位層プロトコルボックスは、TCP、UDPなどのトランスポートプロトコル、ICMPなどの制御プロトコル、OSPFなどのルーティングプロトコル、およびIPv4などのIPv6で「トンネリング」されるインターネットまたは下位層プロトコルを表します。 IPXなど。リンク層プロトコルボックスは、イーサネット、トークンリング、FDDI、PPP、X.25、フレームリレー、ATMなど、およびIPv4トンネルなどのインターネット層の「トンネル」を表します。
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:
（u.i）「トンネル上位層入力」-カプセル化解除されるトンネルIPv6パケットで構成されます。トンネルパケットは、次のものからIPv6層を介して着信します。
(u.i.1) a link-layer - (path #1, Fig.5)
（u.i.1）リンク層-（パス＃1、図5）
These are tunnel packets destined to this node and will undergo decapsulation.
これらは、このノードを宛先とするトンネルパケットであり、カプセル化が解除されます。
(u.i.2) a tunnel link-layer - (path #7, Fig.5)
（u.i.2）トンネルリンク層-（パス＃7、図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つ以上のカプセル化解除が行われたトンネルパケットです。つまり、パケットには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層に戻され、さらに処理されます（b.2を参照）。
+-----------------------+ +-----------------------------------+
| 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
図5ノード上のIPv6トンネリングプロトコルエンジンのパケットフロー
(u.o) "tunnel upper-layer output" - consists of tunnel IPv6 packets that are passed through the IPv6 layer down to:
（u.o）「トンネル上位層出力」-IPv6層を経由して次の場所に渡されるトンネルIPv6パケットで構成されます。
(u.o.1) a link-layer - (path #2, Fig.5)
（u.o.1）リンク層-（パス＃2、図5）
These packets underwent encapsulation and are sent towards the tunnel exit-point
これらのパケットはカプセル化を受け、トンネル出口ポイントに向けて送信されます
(u.o.2) a tunnel link-layer - (path #8, Fig.5)
（u.o.2）トンネルリンク層-（パス＃8、図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つ以上の内部トンネルの両方のエントリポイントノードです。
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.
（l.i）「トンネルリンク層入力」-カプセル化される元のIPv6パケットで構成されます。
The original packets are incoming through the IPv6 layer from:
元のパケットは、IPv6レイヤーを介して次から着信します。
(l.i.1) an upper-layer - (path #4, Fig.5)
（l.i.1）上位層-（パス＃4、図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)
（l.i.2）リンク層-（パス＃6、図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)
（l.i.3）トンネルの上位層-（パス＃8、図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.
これらのパケットは、ネストされたカプセル化を受けるトンネルパケットです。このノードは、外部トンネルと1つ以上の内部トンネルの両方のエントリポイントノードです。
The resulting tunnel packets are passed as tunnel upper-layer output packets through the IPv6 layer (see u.o) down to:
結果のトンネルパケットは、IPv6層（u.oを参照）を経由して、トンネルの上位層出力パケットとして次の場所に渡されます。
(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）「トンネルリンク層出力」-カプセル化解除の結果としての元のIPv6パケットで構成されます。これらのパケットは、IPv6層を通過して次のことを行います。
(l.o.1) an upper-layer - (path #3, Fig.5)
（l.o.1）上位層-（パス＃3、図5）
These original packets are destined to this node.
これらの元のパケットは、このノードを宛先としています。
(l.o.2) a link-layer - (path #5, Fig.5)
（l.o.2）リンク層-（パス＃5、図5）
These original packets are destined to another node; they are transmitted on a link towards their destination.
これらの元のパケットは別のノードを宛先としています。それらは宛先に向けてリンクで送信されます。
(l.o.3) a tunnel upper-layer - (path #7, Fig.5)
（l.o.3）トンネルの上位層-（パス＃7、図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.
これらのパケットは別のカプセル化解除を受けます。それらはネストされたトンネルパケットでした。このノードは、外部トンネルの出口点ノードであり、1つ以上の内部トンネルでもあります。
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.
トンネルリンク層の入力と出力は、他のリンク層プロトコルの入力と出力と同様に実装できます。たとえば、インターフェースまたは疑似インターフェースをIPv6トンネルに関連付けます。
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トンネルリンク」の選択は、ノードのルーティングテーブルの内容に基づいて行われたパケット転送の決定に基づいて行われます。
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.
ネストされたIPv6カプセル化は、トンネルパケットのカプセル化です。 IPv6トンネルのホップがトンネルの場合に発生します。トンネルを含むトンネルは外部トンネルと呼ばれます。外側のトンネルに含まれるトンネルは、内側のトンネルと呼ばれます。図6を参照してください。内部トンネルとその外部トンネルはネストされたトンネルです。
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トンネル」のエントリポイントノードは、「外部IPv6トンネル」エントリポイントノードによってカプセル化されたトンネルIPv6パケットを受信します。 「内部トンネルエントリポイントノード」は、受信トンネルパケットを元のパケットとして扱い、カプセル化を実行します。結果のパケットは、「内部IPv6トンネル」の「トンネルパケット」と、「外部IPv6トンネル」の「ネストされたトンネルパケット」です。
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
図6。ネストされたカプセル化
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-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.
ネストされたカプセル化によるトンネルIPv6パケットのサイズの増加には、トンネルエントリポイントでのフラグメンテーション[IPv6-Spec]が必要になる場合があります。セクション7を参照してください。フラグメント数が2倍になります。さらに、この断片化が始まると、ネストされた新しいカプセル化ごとにさらに断片化が発生する可能性があります。したがって、ネストされたカプセル化を制限することをお勧めします。
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.
過剰なネストされたカプセル化を制限するために提案されているメカニズムは、「トンネルカプセル化制限」オプションです。これは、カプセル化IPv6ヘッダーに付随するIPv6宛先オプション拡張ヘッダーで運ばれます。
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.)
トンネルエントリポイントノードは、そのノードでトンネルに入るすべてのパケットに付加される情報の一部として、トンネルカプセル化制限オプションを含めるように構成できます。トンネルカプセル化制限オプションは、元のパケットのカプセル化IPv6ヘッダーとIPv6ヘッダーの間に配置された宛先オプション拡張ヘッダー[IPv6-Spec]に含まれています。 （他のIPv6拡張ヘッダーも、トンネルエントリポイントノードの構成情報に応じて、宛先オプション拡張ヘッダーの前または後に存在する場合があります。）
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.
Tunnel Encapsulation Limitオプションは、パケットの先頭に追加できるカプセル化の追加レベルの数を指定します。つまり、パケットのネストレベルの追加がいくつ許可されるかを指定します。オプションのカプセル化はカウントされません。それ自体が含まれています。たとえば、ゼロの制限値を含むトンネルカプセル化制限オプションは、そのオプションを伝送するパケットが現在のトンネルを出る前に別のトンネルに入ることができないことを意味します。
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
オプションタイプ10進数値4
- the highest-order two bits - set to 00 - indicate "skip over this option if the option is not recognized".
- 最上位の2ビット-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].
-3番目に上位のビット-0に設定-このオプションのオプションデータは、パケットの宛先[IPv6-Spec]への途中で変更されないことを示します。
Opt Data Len value 1 - the data portion of the Option is one octet long.
Opt Data Len値1-オプションのデータ部分は1オクテット長です。
Opt Data Value the Tunnel Encapsulation Limit value - 8-bit unsigned integer specifying how many further levels of encapsulation are permitted for the
最適化データ値トンネルカプセル化制限値-許可されるカプセル化のレベル数を指定する8ビットの符号なし整数
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.)
（a）パケットを調べて、IPv6ヘッダーの後にトンネルカプセル化制限オプションが存在するかどうかを確認します。 IPv6ヘッダーに続くヘッダーは、厳密な「左から右」の順序で検査する必要があります。検査は、次のヘッダーのいずれかが検出されるとすぐに停止します。（i）トンネルカプセル化制限を含む宛先オプション拡張ヘッダー、 （ii）別のIPv6ヘッダー、（iii）TCP、UDP、ICMPなどの非拡張ヘッダー、または（iv）暗号化されているかタイプが不明なため解析できないヘッダー。 （この要件は、宛先オプション拡張ヘッダーがパケットの宛先ノードによってのみ検査される必要があるという一般的なIPv6ルールの例外であることに注意してください。代替および「よりクリーンな」アプローチは、ホップバイホップ拡張ヘッダーを使用することでした。この目的ですが、トンネルのパスに沿ったすべてのIPv6ノードで、望ましくない追加の処理負荷と、その結果として追加の遅延が発生する可能性があります。
(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).
（b）トンネルに入るパケットにトンネルカプセル化制限オプションが見つかり、その制限値がゼロの場合、パケットは破棄され、ICMPパラメータ問題メッセージ[ICMP-Spec]がパケットの送信元に送信されます。以前のトンネルエントリポイントノード。パラメータ問題メッセージのコードフィールドはゼロに設定され（「誤ったヘッダーフィールドが検出されました」）、ポインタフィールドはトンネルカプセル化制限オプションの3番目のオクテット（つまり、ゼロの制限値を含むオクテット）を指すように設定されています。 。
(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.
（c）トンネルに入るパケットでトンネルカプセル化制限オプションが見つかり、その制限値がゼロ以外の場合、このエントリポイントで追加されるカプセル化ヘッダーの一部として、追加のトンネルカプセル化制限オプションを含める必要があります。カプセル化オプションの制限値は、カプセル化されているパケットで見つかった制限値よりも1小さい値に設定されています。
(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.
（d）トンネルに入るパケットにトンネルカプセル化制限オプションが見つからず、このトンネルにカプセル化制限が構成されている場合、このエントリポイントで追加されるカプセル化ヘッダーの一部として、トンネルカプセル化制限オプションを含める必要があります。 。オプションの制限値は、構成された制限に設定されます。
(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.
（e）トンネルに入るパケットにトンネルカプセル化制限オプションが見つからず、このトンネルにカプセル化制限が構成されていない場合、このエントリポイントに追加されるカプセル化ヘッダーの一部として、トンネルカプセル化制限オプションは含まれません。 。
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:
回避すべきカプセル化の2つのケースを以下に示します。
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.
回避する必要があるカプセル化の特定のケースは、ループバックカプセル化です。ループバックカプセル化は、トンネルIPv6エントリポイントノードが、自身から発信され、自分宛てのトンネルIPv6パケットをカプセル化するときに行われます。これにより、エントリポイントノードで無限処理ループが生成される可能性があります。
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.
このような場合を回避するには、エントリポイントと出口ポイントの両方のノードアドレスが同じノードに属するトンネルの構成をチェックして拒否するメカニズムを実装に含めることをお勧めします。また、カプセル化エンジンは、元のパケットの送信元アドレスと最終的な宛先アドレスのペアと同じトンネルエントリポイントと出口ポイントのアドレスのペアを持つパケットのカプセル化をチェックして拒否することをお勧めします。
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.
複数レベルのネストされたトンネルを含む転送パスの場合、内部トンネルからのパケットがまだ出ていない外部トンネルに再び入るときに、内部トンネルから外部トンネルへのルーティングループは特に危険です。このような場合、ネストされたカプセル化は、4.1で説明されているマイナスの影響を持つ再帰的なカプセル化になります。ネストされたカプセル化ごとに新しいホップ制限値を持つトンネルヘッダーが追加されるため、IPv6ホップ制限メカニズムは、パケットが外部トンネルエントリポイントノードに到達する回数を制御できず、再帰的なカプセル化の数を制御できません。
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:
送信元から最終宛先までのパケットのパスにトンネルが含まれている場合、パケットが通過できるホップの最大数は、ルーティングループでの再帰的なカプセル化の悪影響を回避するために、一緒に使用される2つのメカニズムによって制御する必要があります。
(a) the original packet hop limit.
（a）元のパケットホップ制限。
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.
（b）トンネルIPv6パケットのカプセル化制限。
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.
ネストされたカプセル化における過剰なカプセル化のリスク要因については、付録Aを参照してください。
The tunnel entry-point node fills out a tunnel IPv6 main header [IPv6-Spec] as follows:
トンネルエントリポイントノードは、トンネルIPv6メインヘッダー[IPv6-Spec]に次のように入力します。
Version:
バージョン：
value 6
値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.
エントリポイントノードのトンネル構成に応じて、フローラベルを事前構成された値に設定できます。通常の値はゼロです-セクション6.5を参照してください。
Payload Length:
ペイロードの長さ：
The original packet length, plus the length of the encapsulating (prepended) IPv6 extension headers, if any.
元のパケットの長さと、カプセル化（先頭に追加）されたIPv6拡張ヘッダーの長さ（ある場合）。
Next Header:
次のヘッダー：
The next header value according to [IPv6-Spec] from the Assigned Numbers RFC [RFC-1700 or its successors].
割当番号RFC [RFC-1700またはその後継]の[IPv6-Spec]に基づく次のヘッダー値。
For example, if the original packet is an IPv6 packet, this is set to:
たとえば、元のパケットがIPv6パケットの場合、これは次のように設定されます。
- decimal value 41 (Assigned Next Header number for IPv6) - if there are no tunnel extension headers.
- 10進数の値41（IPv6に割り当てられた次のヘッダー番号）-トンネル拡張ヘッダーがない場合。
- 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.
- 値0（IPv6ホップバイホップオプション拡張ヘッダーに割り当てられた次のヘッダー番号）-ホップバイホップオプション拡張ヘッダーがトンネルIPv6ヘッダーの直後に続く場合。
- 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.
- 10進値60（IPv6宛先オプション拡張ヘッダーに割り当てられた次のヘッダー番号）-宛先オプション拡張ヘッダーがトンネルIPv6ヘッダーの直後に続く場合。
Hop Limit:
ホップ制限：
The tunnel IPv6 header hop limit is set to a pre-configured value - see section 6.3.
トンネルIPv6ヘッダーホップ制限は、事前構成された値に設定されます-セクション6.3を参照してください。
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).
ホストのデフォルト値は、近隣探索でアドバタイズされたホップ制限[ND-Spec]です。ルーターのデフォルト値は、Assigned Numbers RFCのデフォルトのIPv6ホップ制限値です（このドキュメントの執筆時点では64）。
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アドレス。このアドレスは、トンネルエントリポイントノードアドレスとして構成されます-セクション6.1を参照してください。
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.
トンネル出口点ノードのIPv6アドレス。このアドレスは、トンネル出口ポイントノードアドレスとして構成されます-セクション6.2を参照してください。
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ノードの構成パラメーターに応じて、トンネルエントリポイントノードは、ホップバイホップオプションヘッダー、ルーティングヘッダーなど、1つ以上のIPv6拡張ヘッダーをトンネルIPv6メインヘッダーに追加する場合があります。
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:
パケットのネストされたカプセル化の数を制限するには、そのように構成されている場合-セクション6.6を参照-トンネルエントリポイントには、トンネルカプセル化制限オプションを含む宛先オプション拡張ヘッダーが含まれています。そのオプションがDestination 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:
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.
最初の8オクテットを含まない、8オクテット単位の宛先オプション拡張ヘッダーの長さ。この宛先オプションヘッダーに他のオプションが存在しない場合は、値0に設定します。
Option Type:
オプションタイプ：
value 4 - see section 4.1.1.
値4-セクション4.1.1を参照してください。
Opt Data Len:
データ長の最適化：
value 1 - see section 4.1.1.
値1-セクション4.1.1を参照してください。
Tun Encap Lim:
Tun Encap Lim：
8 bit unsigned integer - see section 4.1.1.
8ビット符号なし整数-セクション4.1.1を参照してください。
Option Type:
オプションタイプ：
value 1 - PadN option, to align the header following this header.
値1-PadNオプション。このヘッダーの後にヘッダーを配置します。
Opt Data Len:
データ長の最適化：
value 1 - one octet of option data.
値1-1オクテットのオプションデータ。
Option Data:
オプションデータ：
value 0 - one zero-valued octet.
値0-1つのゼロ値オクテット。
The IPv6 tunnel state variables, some of which are or may be configured on the tunnel entry-point node, are:
IPv6トンネル状態変数は、その一部はトンネルエントリポイントノードで構成されているか、構成されている可能性があります。
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ヘッダーの送信元アドレスフィールドにコピーされます。
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.
トンネル出口ポイントノードアドレスは、トンネルIPv6ヘッダーのIPv6宛先アドレスとして使用されます。トンネルは、入口点ノードと出口点ノード間のリンクの仮想ポイントツーポイントのように機能します。
The tunnel exit-point node address is copied to the destination address field in the tunnel IPv6 header during packet encapsulation.
トンネルの出口点ノードアドレスは、パケットのカプセル化時にトンネルIPv6ヘッダーの宛先アドレスフィールドにコピーされます。
The configuration of the tunnel entry-point and exit-point addresses is not subject to IPv6 Autoconfiguration or IPv6 Neighbor Discovery.
トンネルのエントリポイントおよび出口ポイントアドレスの設定は、IPv6自動設定またはIPv6ネイバー探索の対象ではありません。
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のホップ数に関係なく、1ホップリンクを介して元のパケットが通過するのと同じです。トンネル。
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.
「シングルホップ」メカニズムは、元のIPv6パケットからトンネルのIPv6ホップの数を隠します。
It is recommended that the tunnel hop limit be configured with a value that ensures:
トンネルホップ制限には、次のことを保証する値を設定することをお勧めします。
(a) that tunnel IPv6 packets can reach the tunnel exit-point node
（a）トンネルIPv6パケットがトンネル出口点ノードに到達できること
(b) a quick expiration of the tunnel packet if a routing loop occurs within the IPv6 tunnel.
（b）IPv6トンネル内でルーティングループが発生した場合のトンネルパケットの迅速な期限切れ。
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).
ホストのトンネルホップリミットのデフォルト値は、IPv6近隣探索アドバタイズホップリミット[ND-Spec]です。ルーターのトンネルホップリミットのデフォルト値は、割り当て番号RFCのデフォルトのIPv6ホップリミット値です（このドキュメントの執筆時点では64）。
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.
トンネルホップ制限は、トンネルエントリポイントノードによってカプセル化された各パケットのトンネルIPv6ヘッダーのホップ制限フィールドにコピーされます。
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トンネルパケットトラフィッククラスは、トンネルエントリポイントノードがトンネルヘッダーのトラフィッククラスフィールドに設定する値を示します。デフォルト値はゼロです。構成されたパケットトラフィッククラスは、トンネルヘッダーのトラフィッククラスフィールドの値が元のヘッダーからコピーされるのか、それとも事前構成された値に設定されるのかも示します。
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トンネルフローラベルは、トンネルエントリポイントノードがトンネルヘッダーのフローラベルに設定する値を示します。デフォルト値はゼロです。
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.
Tunnel Encapsulation Limit値は、エントリポイントノードがそのノードで発生するトンネルパケットのカプセル化の数を制限するように構成されているかどうかを示すことができます。 IPv6トンネルカプセル化制限は、そのエントリポイントノードでカプセル化を受けているパケットに許可される追加のカプセル化の最大数です。推奨されるデフォルト値は4です。ネストされたカプセル化の数を制限するように構成されたエントリポイントノードは、カプセル化を受けている元のパケットにトンネルカプセル化制限オプションを含む宛先オプション拡張ヘッダーを付加します。セクション4.1および4.1.1を参照してください。
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 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から動的に設定され、トンネルヘッダーのサイズから、フラグメンテーションなしでトンネルを介して送信できるトンネルパケットペイロードの最大サイズを引いた値[ IPv6-Spec]。トンネルエントリポイントノードは、トンネルエントリポイントノードと出口ポイントノード間のパスでパスMTUディスカバリを実行します[PMTU-Spec]、[ICMP-Spec]。ネストされたトンネルのトンネルMTUは、外側のトンネルのトンネルMTUからネストされたトンネルヘッダーのサイズを引いたものです。
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.
トンネルヘッダーを先頭に追加すると、パケットのサイズが大きくなるため、IPv6の元のパケットのカプセル化によって生じるトンネルパケットには、フラグメンテーションが必要になる場合があります。
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.
トンネルパケットをトンネル内の別のノードに転送するトンネル中間ノードは、転送中のパケットをフラグメント化してはならないという一般的なIPv6ルールに従います。
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.
フラグメント化されたトンネルパケットの宛先がエニーキャストアドレスで識別される出口ポイントノードである場合、特定の問題が発生します。エニーキャストアドレスによって識別されたノードに宛てられた元のフラグメント化されたIPv6パケットの問題と同様の問題は、パケットのすべてのフラグメントが同じ宛先ノードに到着して、そのノードが正常な再構成を実行できるようにする必要があることです。エニーキャストアドレスに送信されたパケットによって必ずしも満たされない要件。
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からトンネルヘッダーのサイズを引いたもの）を超えると、は次のように処理されます。
(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 [IPv6-Spec]より大きい場合、エントリポイントノードはパケットを破棄し、ICMPv6 "Packet Too Big"メッセージを元のパケットの送信元アドレスに送信します。トンネルMTUまたはIPv6最小リンクMTUのどちらか大きい方、つまり最大値（トンネルMTU、IPv6最小リンクMTU）に設定された推奨MTUサイズフィールド。セクション6.7および8.2も参照してください。
(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以下の場合、トンネルエントリポイントノードは元のパケットをカプセル化し、結果のIPv6トンネルパケットを、パスMTUを超えないIPv6フラグメントにフラグメント化します。トンネル出口点。
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（つまり、トンネルのエントリポイントとトンネルの出口ポイントの間のパス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.
（a）元のIPv4パケットヘッダーでフラグメント禁止-DF-ビットフラグが設定されている場合、エントリポイントノードはパケットを破棄し、ICMPメッセージを返します。 ICMPメッセージには、type = "unreachable"、code = "packet too big"、およびトンネルMTUのサイズに設定された推奨MTUサイズフィールドがあります-セクション6.7および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.
（b）元のパケットヘッダーのDo n't Fragment-DF-ビットフラグがCLEARの場合、トンネルエントリポイントノードは元のパケットをカプセル化し、結果のIPv6トンネルパケットを、パスを超えないIPv6フラグメントにフラグメント化します。トンネル出口ポイントへのMTU。
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トンネリングは、IPv6パケットの処理中に検出されたエラーがICMPメッセージを通じてパケットの送信元に報告されるという一般的なルールに従います。
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パケットの送信元に直接報告されます。
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.
トンネル内のノードによって検出されたエラーは、トンネルパケットの送信元、つまりトンネルエントリポイントノードに報告されます。トンネルエントリポイントノードに送信されるICMPメッセージには、ICMPペイロードとして、元のパケットをペイロードとするトンネルIPv6パケットがあります。
The cause of a packet error encountered inside a tunnel can be a problem with:
トンネル内で発生したパケットエラーの原因は、次の問題である可能性があります。
(a) the tunnel header, or
（a）トンネルヘッダー、または
(b) the tunnel packet.
（b）トンネルパケット。
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.
トンネル内で検出された問題を元のパケットの送信元に報告するには、トンネルエントリポイントノードが、トンネル内から受信したICMPメッセージを元のIPv6パケットの送信元に中継する必要があります。
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:
ノードのエラー報告メカニズムで実行できる処理の例を図7と図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".
図7パス＃0および図8（a）-IPv6トンネルエントリポイントは、図7で「トンネルICMPv6メッセージ」とマークされている、トンネル内からICMPパケットを受信します。トンネルエントリポイントノードのIPv6層は、受信したICMPメッセージをICMPv6入力に渡します。 ICMPタイプとコード[ICMP-Spec]に基づくICMPv6入力は、内部「エラーコード」を生成します。
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.
図7パス＃1-内部エラーコードは、「ICMPv6メッセージペイロード」と共に上位層プロトコルに渡されます。この場合は、IPv6トンネルの上位層エラー入力です。
+-------+ +-------+ +-----------------------+
| 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)
図7ノードのエラー報告フロー（IPv6トンネリングプロトコルエンジン）
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.
図7パス＃2および図8（b）-IPv6トンネルエラー入力は、ICMPv6メッセージペイロードであるトンネルIPv6パケットのカプセル化を解除し、元のパケットを取得して、元のヘッダーを取得し、「内部エラーコード」をディスパッチします。 、元のパケットヘッダーの送信元アドレス、および元のパケットから、ICMPメッセージペイロードの元のパケットの直前のトンネルヘッダーの次のヘッダーフィールドで識別されるプロトコルのエラーレポートブロックまで。
From here the processing depends on the protocol of the original packet:
ここから、処理は元のパケットのプロトコルに依存します。
(a) - for an IPv6 original packet
（a）-IPv6元のパケットの場合
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.
図7パス＃3および図8（c.1）-IPv6元のパケットの場合、ICMPv6エラーレポートは、「元のパケット」を含む「内部エラーコード」に従って、タイプとコードのICMPメッセージを作成します。 ICMPペイロードとして。
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.
図7パス＃4および図8（d.1）-ICMPメッセージには、トンネルのエントリポイントノードアドレスがソースアドレスとして、元のパケットのソースノードアドレスが宛先アドレスとして含まれています。トンネルエントリポイントノードは、元のパケットの送信元ノードにICMPメッセージを送信します。
(b) - for an IPv4 original packet
（b）-IPv4元のパケットの場合
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.
図7パス＃5および図8（c.2）-IPv4オリジナルパケットの場合、ICMPv4エラーレポートは、「内部エラーコード」から派生したタイプとコードのICMPメッセージを作成し、「元のパケット」を含みます。 "ICMPペイロードとして。
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.
図7パス＃6および図8（d.2）-ICMPメッセージには、トンネルエントリポイントノードのIPv4アドレスがソースアドレスとして、元のパケットのIPv4ソースノードアドレスが宛先アドレスとして含まれています。トンネルエントリポイントノードは、元のパケットの送信元ノードにICMPメッセージを送信します。
A graphical description of the header processing taking place is the following:
行われるヘッダー処理のグラフィカルな説明は次のとおりです。
< 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 |
+--------+ +---------+ +----------+--------//------+
| <Original Packet in Error >
----------------- |
| |
--------------|---------------
| |
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 >
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 ICMPエラーの報告と処理
The tunnel ICMP messages that are reported to the source of the original packet are:
元のパケットの送信元に報告されるトンネルICMPメッセージは次のとおりです。
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.
トンネルのホップ制限が正しく構成されていないか、ルーティングループが含まれており、パケットがトンネルの出口ポイントノードに到達しません。この問題はトンネルエントリポイントノードに報告され、トンネルホップ制限をより高い値に再構成できます。問題は、セクション8.2または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.
トンネル内のノードの1つに到達できないか、到達できません。この問題はトンネルエントリポイントノードに報告され、トンネルのエントリポイントと出口ポイントの間の有効でアクティブなパスで再構成する必要があります。
The problem is further reported to the source of the original packet as described in section 8.2, or 8.3.
問題は、セクション8.2または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 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.
Tun Encap Limフィールド値が1に設定された有効なトンネルカプセル化制限宛先ヘッダーを指すパラメーター問題ICMPメッセージは、トンネルパケットが許可されたカプセル化の最大数を超えたことを示しています。問題は、セクション8.2または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.
トンネル構成とトンネルトポロジの問題である、トンネル内で検出された上記の3つの問題は、「リンクの問題」によって引き起こされるトンネルの一般的な「到達不能」問題として、元のIPv6パケットのソースに報告されます。セクション8.2を参照してください。および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:
このタイプのICMPメッセージで伝達される情報は、次のように使用されます。
- by a receiving tunnel entry-point node to set or adjust the tunnel MTU
- トンネル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.
- トンネルエントリポイントノードにIPv6パケットを送信するときに使用する必要があるMTUサイズを元のパケットのソースに示す送信トンネルエントリポイントノード。
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:
IPv6フィールド：
Source Address
送信元アドレス
A valid unicast IPv6 address of the outgoing interface.
発信インターフェイスの有効なユニキャストIPv6アドレス。
Destination Address
宛先アドレス
Copied from the Source Address field of the Original IPv6 header.
元のIPv6ヘッダーの送信元アドレスフィールドからコピーされます。
ICMP Fields:
ICMPフィールド：
For any of the following tunnel ICMP error messages:
次のいずれかのトンネルICMPエラーメッセージの場合：
"hop limit exceeded"
「ホップ制限を超えました」
"unreachable node"
「到達不能ノード」
"parameter problem" - pointing to a valid Tunnel Encapsulation Limit destination header with the Tun Encap Lim field set to a value zero:
「パラメーターの問題」-Tun Encap Limフィールドが値0に設定された有効なトンネルカプセル化制限の宛先ヘッダーを指します。
Type 1 - unreachable node
タイプ1-到達不能ノード
Code 3 - address unreachable
コード3-到達不能なアドレス
For tunnel ICMP error message "packet too big":
トンネルICMPエラーメッセージ「パケットが大きすぎます」の場合：
Type 2 - packet too big
タイプ2-パケットが大きすぎます
Code 0
コード0
MTU The MTU field from the tunnel ICMP message minus the length of the tunnel headers.
MTUトンネルICMPメッセージからのMTUフィールドからトンネルヘッダーの長さを引いたもの。
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で説明されている一般的なルールに従って、元のパケットサイズがIPv6に必要な最小リンクMTUサイズ[IPv6-Spec]より大きい場合にのみ、ICMP "パケットが大きすぎます"メッセージが元のパケットのソースに送信されます。
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:
IPv4フィールド：
Source Address
送信元アドレス
A valid unicast IPv4 address of the outgoing interface.
発信インターフェイスの有効なユニキャストIPv4アドレス。
Destination Address
宛先アドレス
Copied from the Source Address field of the Original IPv4 header.
元のIPv4ヘッダーの送信元アドレスフィールドからコピーされます。
ICMP Fields:
ICMPフィールド：
For any of the following tunnel ICMP error messages:
次のいずれかのトンネルICMPエラーメッセージの場合：
"hop limit exceeded"
「ホップ制限を超えました」
"unreachable node"
「到達不能ノード」
"parameter problem" - pointing to a valid Tunnel Enacpsulation Limit destination header with the Tun Encap Lim field set to a value zero:
「パラメータの問題」-Tun Encap Limフィールドが値0に設定された有効なTunnel Enacpsulation Limit宛先ヘッダーを指している：
Type 3 - destination unreachable
タイプ3-宛先に到達できません
Code 1 - host unreachable
コード1-ホストに到達できない
For a tunnel ICMP error message "packet too big":
トンネルICMPエラーメッセージ「パケットが大きすぎます」の場合：
Type 3 - destination unreachable
タイプ3-宛先に到達できません
Code 4 - packet too big
コード4-パケットが大きすぎます
MTU The MTU field from the tunnel ICMP message minus the length of the tunnel headers.
MTUトンネルICMPメッセージからのMTUフィールドからトンネルヘッダーの長さを引いたもの。
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で説明されている一般的なルールに従って、元のIPv4ヘッダーにDF-フラグメント化しない-ビットフラグが設定されている場合、ICMP "パケットが大きすぎます"メッセージが元のIPv4パケットの送信元ノードに送信されます。
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エラーメッセージを受信する内部トンネルエントリポイントは、セクション8で説明されているメカニズムに従って、ICMPメッセージを外部トンネルエントリポイントに中継します。 。、8.1、8.2、および8.3。さらに、外部トンネルエントリポイントは、同じメカニズムに従って、ICMPメッセージを元のパケットの送信元に中継します。
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トンネルの場合、このドキュメントで前述したメカニズムに加えて、トンネルのエントリポイントノードはパケットに対してセキュリティアルゴリズムを実行し、トンネルヘッダーの一部として[IPv6に準拠した1つ以上のセキュリティヘッダーを付加しますSpec]、[RFC2401]、および[RFC2402]、または[RFC2406]。
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.
セキュアIPv6トンネルの出口点ノードは、セキュリティアルゴリズムを実行し、前述のトンネルヘッダー処理の一部として、[RFC2401]、[RFC2402]、または[RFC2406]に準拠して、トンネルセキュリティヘッダーを処理します。出口ポイントノードは、トンネルヘッダーの処理が完了した後、残りのトンネルヘッダーとともにトンネルセキュリティヘッダーを破棄します。
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トンネルのエントリポイントノードと出口ポイントノードでトンネルパケットに対して実行されるセキュリティ処理は、セキュリティヘッダーのタイプ-認証（AH）または暗号化（ESP）によって異なります。 -トンネルのセキュリティアソシエーションで構成されたパラメータ。トンネルパケットに適用されるセキュリティレベルとメカニズムと、トンネルパケットのペイロードである元のパケットに適用されるセキュリティとの間に依存関係や相互作用はありません。ネストされたトンネルの場合、各内部トンネルは、外部トンネルのサービス、または元のパケットの送信元と宛先の間のサービスとは無関係に、独自のセキュリティサービスのセットを持つことができます。
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.
このドキュメントは、IPngワーキンググループメーリングリストでのIPv6トンネリングに関するいくつかの議論と、1995年7月にストックホルムで開催された第33回IETFでのIPv6トンネリングに焦点を当てたIPv6プレゼンテーションへのIPngワーキンググループからのフィードバックから部分的に派生しています。
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).
さらに、トンネリングまたはカプセル化に焦点を当てた次のドキュメントは参考資料でした：RFC 1933（R.ギリガン、E。ノードマーク）、RFC 1241（R.ウッドバーン、D。ミルズ）、RFC 1326（P.ツチヤ）、RFC 1701 RFC 1702（S. Hanks、D。Farinacci、P。Traina）、RFC 1853（W. Simpson）、および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.
ブライアンカーペンター、リチャードドレーブス、ボブヒンデン、トーマスナーテン、エリックノードマーク（アルファベット順）は、このドキュメントの改善に関する貴重なレビューコメントと提案を行いました。 Scott Bradner、Ross Callon、Dimitry Haskin、Paul Traina、James Watt（アルファベット順）は、このドキュメントの懸念事項に関する見解または経験を共有しました。ジュディス・グロスマンは、長年にわたる編集および執筆の経験のサンプルと、十分な量の詳細な技術的な質問を提供しました。
[IPv6-Spec] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6-Spec] Deering、S。およびR. Hinden、「インターネットプロトコルバージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[ICMP-Spec] Conta, A. and S. Deering "Internet Control Message Protocol for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
[ICMP仕様]コンタ、A、およびS.ディアリング「インターネットプロトコルバージョン6（IPv6）のインターネット制御メッセージプロトコル」、RFC 2463、1998年12月。
[ND-Spec] Narten, T., Nordmark, E., and W. Simpson "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[ND-Spec] Narten、T.、Nordmark、E。、およびW. Simpsonの「Neighbor Discovery for IP Version 6（IPv6）」、RFC 2461、1998年12月。
[PMTU-Spec] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP Version 6 (IPv6)", RFC 1981, August 1996.
[PMTU仕様] McCann、J.、Deering、S.、J。Mogul、「IPバージョン6（IPv6）のパスMTU発見」、RFC 1981、1996年8月。
[RFC2401] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Atkinson、R。、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2402] Atkinson, R., "IP Authentication Header", RFC 2402, November 1998.
[RFC2402] Atkinson、R。、「IP Authentication Header」、RFC 2402、1998年11月。
[RFC2406] Atkinson, R., "IP Encapsulation Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406] Atkinson、R。、「IP Encapsulation Security Payload（ESP）」、RFC 2406、1998年11月。
[RFC-1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[RFC-1853] Simpson、W。、「IP in IP Tunneling」、RFC 1853、1995年10月。
[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.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
Authors' Addresses
著者のアドレス
Alex Conta Lucent Technologies Inc. 300 Baker Ave Concord, MA 01742-2168 +1-978-287-2842
Alex Conta Lucent Technologies Inc.300 MA Bakery 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
Stephen Deering Cisco Systems 170 West Tasman Dr San Jose、CA 95132-1706
Phone: +1-408-527-8213
EMail: deering@cisco.com
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:
ルーティングループの再帰的カプセル化のリスク要因を決定する2つの重要な要素があります。
(a) the type of tunnel,
（a）トンネルのタイプ
(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.
（b）トンネル出口ポイントへのルートのタイプ。これは、トンネルを介した、つまりトンネル仮想リンクを介したパケット転送を決定します。
A.1.1 Risk Factor in Nested Encapsulation - type of tunnel.
A.1.1 ネストされたカプセル化のリスク要因-トンネルのタイプ。
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 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.
A.1.2 ネストされたカプセル化の危険因子-ルートのタイプ。
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.
トンネル出口点ノードへのルートの1つのタイプは、指定された宛先ノードへのルートです。つまり、宛先は、指定された有効なIPv6アドレス（ノードへのルート）です。このようなルートは、元のパケットの宛先アドレスと、そのルートのトンネルエントリポイントノードルーティングテーブルエントリに格納されている宛先アドレスとの最長一致に基づいて選択できます。このようなルートで転送されたパケットは、最初にカプセル化されてから、トンネル出口ポイントノードに向けて転送されます。
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.
トンネル出口ポイントノードへの別のタイプのルートは、指定されたプレフィックスネットへのルートです。つまり、宛先は、指定された有効なIPv6プレフィックス（ネットへのルート）です。このようなルートは、元のパケット宛先アドレスと、そのルートのトンネルエントリポイントノードルーティングテーブルエントリに格納されているプレフィックス宛先との最長パス一致に基づいて選択できます。このようなルートで転送されたパケットは、最初にカプセル化されてから、トンネル出口ポイントノードに向けて転送されます。
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.
トンネルの出口点へのルートがネットへのルートである場合、再帰的なカプセル化のリスク要因は中程度です。ルートが関連付けられているプレフィックスと一致する宛先アドレスの範囲があります。異なるトンネルエントリポイントを持つ1つ以上の内部トンネルに、外部トンネルの出口ポイントのネットへのルートと一致する出口ポイントノードアドレスがある場合、トンネルパケットがそのような内部トンネルの内部から迂回されると、再帰的なカプセル化が発生する可能性があります内部トンネルの出口ポイントと一致する出口ポイントへのルートを持つ外部トンネルの入口ポイントに。
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.
トンネルの出口ポイントへのルートがデフォルトルートである場合、再帰的なカプセル化のリスク要因は最大です。より良いルートがないため、パケットはデフォルトのトンネルを介して転送されます。多くの状況で、デフォルトのトンネルを介した転送は、最大範囲でインターネット全体からノードのリンクを除いた広範囲の宛先アドレスに対して発生する可能性があります。その結果、ルーティングループの場合、トンネルパケットが内部トンネルから、トンネルがデフォルトトンネルである外部トンネルエントリポイントに迂回されると、パケットはもう一度カプセル化されます。ルーティングメカニズムは、宛先に基づいて異なる方法で識別できません。
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。