RFC2473 日本語訳
2473 Generic Packet Tunneling in IPv6 Specification. A. Conta, S.Deering. December 1998. (Format: TXT=77956 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Conta
Request for Comments: 2473 Lucent Technologies Inc.
Category: Standards Track S. Deering
Cisco Systems
December 1998
コメントを求めるワーキンググループA.コンタの要求をネットワークでつないでください: 2473年のルーセントテクノロジーズ株式会社カテゴリ: 標準化過程S.デアリングシスコシステムズ1998年12月
Generic Packet Tunneling in IPv6
Specification
IPv6仕様によるジェネリックパケットトンネリング
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(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カプセル化のためにモデルとジェネリックメカニズムを定義します。 また、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
1. 序論…2 2. 用語…2 3. IPv6トンネリング…4 3.1 IPv6カプセル化…6 3.2 TunnelsでのIPv6パケット処理…7 3.3IPv6被膜剥離術…7 3.4 IPv6はプロトコルエンジンにトンネルを堀ります…8 4. カプセル化を入れ子にします…11 4.1 制限はカプセル化を入れ子にしました…12 4.1 .1 カプセル化限界オプションにトンネルを堀ってください…13 4.1 .2 ループバックカプセル化…15 4.1 .3ルート設定輪はカプセル化を入れ子にしました…15 5. IPv6ヘッダーにトンネルを堀ってください…16 5.1 IPv6拡張ヘッダーにトンネルを堀ってください…17 6. IPv6は州の変数にトンネルを堀ります…19 6.1 IPv6はエントリー・ポイントノードにトンネルを堀ります…19 6.2 IPv6はエキジットポイントノードにトンネルを堀ります…19
Conta & Deering Standards Track [Page 1] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[1ページ]RFC2473ジェネリックパケット
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
6.3 IPv6はホップ限界にトンネルを堀ります…19 6.4 IPv6はパケットトラフィックのクラスにトンネルを堀ります…20 6.5 IPv6は流れラベルにトンネルを堀ります…20 6.6 IPv6はカプセル化限界にトンネルを堀ります…20 6.7 IPv6はMTUにトンネルを堀ります…20 7. IPv6はパケットサイズ問題にトンネルを堀ります…21 7.1 IPv6はパケット断片化にトンネルを堀ります…21 7.2 IPv4はパケット断片化にトンネルを堀ります…22 8. IPv6は誤り報告と処理にトンネルを堀ります…22 8.1 ICMPメッセージにトンネルを堀ってください…27 8.2 IPv6のオリジナルのパケットへのICMPメッセージ…28 8.3 IPv4のオリジナルのパケットへのICMPメッセージ…29 8.4 入れ子にされたトンネルパケットへのICMPメッセージ…30 9. セキュリティ問題…30 10. 承認…31 11. 参照…31人の作者のアドレス…32付録A.は再帰的なカプセル化の要素を危険にさらします…33 完全な著作権宣言文…36
1. Introduction
1. 序論
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トンネリングのための典型的なシナリオは中間的ノードが特定の推進経路を選択されたパケットに指定することによって明白なルーティングコントロールを及ぼす場合です。 このコントロールはprepending IPv6ヘッダーによってそれぞれの選択されたオリジナルのパケットに達成されます。 これらのprependedヘッダーは推進経路を特定します。
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.
キーワードが解釈しなければならない、RFC2119で定義されるようにNOT、5月、OPTIONAL、REQUIRED、RECOMMENDED、SHALL、SHALL NOT、SHOULD、SHOULD NOTを解釈することになっていなければなりません。
2. Terminology
2. 用語
original packet
オリジナルのパケット
a packet that undergoes encapsulation.
カプセル化を受けるパケット。
Conta & Deering Standards Track [Page 2] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[2ページ]RFC2473ジェネリックパケット
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.
ヘッダーはカプセル化の間、オリジナルのパケットにprependedしました。 それはソースと目的地としてトンネルエンドポイントを指定します。
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.
トンネルパケットがdecapsulatedされるトンネル終わりノード。
IPv6 tunnel
IPv6トンネル
a tunnel configured as a virtual link between two IPv6 nodes, on
which the encapsulating protocol is IPv6.
トンネルは仮想のリンクとして2の間でIPv6ノードを構成しました。要約プロトコルはノードの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.
エントリーが指すトンネルとトンネルエキジットポイントノードの間でトンネルヘッダーのサイズを引いて断片化、すなわち、Path 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
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[3ページ]RFC2473ジェネリックパケット
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
3. IPv6トンネリング
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がリンク層プロトコルのように行動するポイント・ツー・ポイントリンクとして現れます。 2つのIPv6ノードが特定の役割を果たします。 1つのノードが、トンネルを通って他のノードかそれ自体から受け取られたオリジナルのパケットとフォワードが結果として起こるトンネルパケットであるとカプセル化します。 他の受け取られていることのノードdecapsulates自身はパケットにトンネルを堀って、ことによると結果として起こるオリジナルのパケットをそれらの目的地に向かって送ります。 encapsulatorノードはトンネルエントリー・ポイントノードと呼ばれます、そして、それはトンネルパケットの源です。 decapsulatorノードはトンネルエキジットポイントと呼ばれます、そして、それはトンネルパケットの目的地です。
Conta & Deering Standards Track [Page 4] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[4ページ]RFC2473ジェネリックパケット
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つのノードの間のトンネルについて特に言及します--そのようなトンネルは、「仮想のポイント・ツー・ポイントはリンクされます」ように見えます。 また、ここに説明されたメカニズムはエキジットポイントノードが他のタイプのアドレスによって特定されるトンネルに適用されます、anycastやマルチキャストのように。 これらのトンネルは「多点リンクへの仮想のポイント」のように見えるかもしれません。 このドキュメントを書く時点で、IPv6 anycastアドレスは進行中の仕様と実験研究の対象です。
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
ノードBからノードC<までトンネルを堀ってください。---------------------->トンネルトンネルエントリー・ポイントエキジットポイントノードノード++++++++|A|、-->--//(>)|B|===>===//===>===|C|、-->--//(>)|D| 元の元の++ソース目的地ノードノードFig.1++++++パケットパケットトンネル
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を見てください)。
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
ノードBからノードC<までトンネルを堀ってください。------------------------>のトンネルのトンネルのオリジナルのエントリー・ポイントエキジットポイントオリジナルのパケットノード+++++++ノードノードパケットソース目的地ノード+| |、-->--//(>)| |===>===//===>===| |、-->--//(>)| | |A| |B| |C| |D| | |、--<--//(<)| |===<===//===<===| |、--<--//(<)| | オリジナルのオリジナルの++ノードエキジットポイントエントリー・ポイントノードノード++++++パケットパケット目的地トンネルトンネルソースノード<。-------------------------ノードCから双方向のノードB Fig.2トンネリングメカニズムまでの>トンネル
Conta & Deering Standards Track [Page 5] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[5ページ]RFC2473ジェネリックパケット
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つのトンネルのエントリー・ポイントノードはもう片方のトンネルのエキジットポイントノード(Fig.2を見る)です。
3.1 IPv6 Encapsulation
3.1 IPv6カプセル化
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拡張ヘッダー(Fig.3を見ます)のIPv6ヘッダーと任意にセットをオリジナルのパケットにprependingするのから成ります。 カプセル化は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パケット、ライブ分野(TTL)へのIPv4の元のヘッダー時間は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 >
+----------------------------------//-----+ | オリジナル| | | | オリジナルのパケット有効搭載量| | ヘッダー| | +----------------------------------//-----+ <のオリジナルのパケット>。| <Tunnel IPv6 Headers><Original Packet>に対して
+---------+ - - - - - +-------------------------//--------------+
| IPv6 | IPv6 | |
| | Extension | Original Packet |
| Header | Headers | |
+---------+ - - - - - +-------------------------//--------------+
< Tunnel IPv6 Packet >
+---------+ - - - - - +-------------------------//--------------+ | IPv6| IPv6| | | | 拡大| オリジナルのパケット| | ヘッダー| ヘッダー| | +---------+ - - - - - +-------------------------//--------------+ <トンネルIPv6パケット>。
Fig.3 Encapsulating a Packet
パケットをカプセルに入れるFig.3
Conta & Deering Standards Track [Page 6] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[6ページ]RFC2473ジェネリックパケット
Tunnel extension headers should appear in the order recommended by the specifications that define the extension headers, such as [IPv6- Spec].
トンネル拡張ヘッダーは拡張ヘッダーを定義する仕様で推薦されたオーダーに現れるべきです、[IPv6仕様]などのように。
A source of original packets and a tunnel entry-point that encapsulates those packets can be the same node.
それらのパケットをカプセルに入れるオリジナルのパケットの源とトンネルエントリー・ポイントは同じノードであるかもしれません。
3.2 Packet Processing in Tunnels
3.2 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拡張ヘッダーによるトンネルHopはトンネルのそれぞれの受信ノードによって処理されます。 トンネルルート設定拡張ヘッダーは、中間的処理ノードを特定して、トンネルを通って、よりすばらしい粒状でトンネルパケットの推進経路を制御します。 トンネルDestination Options拡張ヘッダーはトンネルエキジットポイントノードを処理されます。
3.3 IPv6 Decapsulation
3.3 IPv6被膜剥離術
Decapsulation is graphically shown in Fig.4:
被膜剥離術はFig.4にグラフィカルに示されます:
+---------+- - - - - -+----------------------------------//-----+
| IPv6 | IPv6 | |
| | Extension | Original Packet |
| Header | Headers | |
+---------+- - - - - -+----------------------------------//-----+
< Tunnel IPv6 Packet >
|
v
+----------------------------------//-----+
| Original | |
| | Original Packet Payload |
| Headers | |
+----------------------------------//-----+
< Original Packet >
+---------+- - - - - -+----------------------------------//-----+ | IPv6| IPv6| | | | 拡大| オリジナルのパケット| | ヘッダー| ヘッダー| | +---------+- - - - - -+----------------------------------//-----+ <トンネルIPv6パケット>。| +に対して----------------------------------//-----+ | オリジナル| | | | オリジナルのパケット有効搭載量| | ヘッダー| | +----------------------------------//-----+ <のオリジナルのパケット>。
Fig.4 Decapsulating a Packet
Fig.4 Decapsulatingはパケットです。
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分野価値によって特定されるかは処理されました。 これがトンネルプロトコル価値に設定されるなら、トンネルプロトコルエンジンは、さらなる処理のためにその値によって特定されたインターネットか下位層プロトコルに、トンネルヘッダーを捨てて、結果として起こるオリジナルのパケットを向かわせます。
Conta & Deering Standards Track [Page 7] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[7ページ]RFC2473ジェネリックパケット
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.
例えば、場合では、Next Header分野はIPv6 Tunnelプロトコル価値を持って、結果として起こるオリジナルのパケットは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.
トンネルエキジットポイントノードと目的地ノード、結果として起こるオリジナルのパケットを受けるものは同じノードであるかもしれません。(それは、トンネルパケットをdecapsulatesします)。
3.4 IPv6 Tunnel Protocol Engine
3.4 IPv6トンネルプロトコルエンジン
Packet flow (paths #1-7) through the IPv6 Tunnel Protocol Engine on a node is graphically shown in Fig.5:
ノードの上のIPv6 TunnelプロトコルEngineを通したパケット流動(経路#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.
Fig.5では、Upper-層のプロトコル箱はTCP(UDP)がプロトコルを制御するトランスポート・プロトコルICMPを表します、OSPFや、インターネットやIPv6の上で「トンネルを堀られる」下位層プロトコルなどのプロトコルを発送して、IPv4、IPXなどのように Link-層のプロトコル箱はイーサネット、Token Ring、FDDI、PPP、X.25、Frame Relay、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. 私)は「上側の層の入力にトンネルを堀ります」--decapsulatedされるトンネルIPv6パケットから成ります。 トンネルパケットは以下からのIPv6層を通した入来です。
(u.i.1) a link-layer - (path #1, Fig.5)
(u.i.1)リンクレイヤ、-(経路#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)
(u.i.2)トンネルリンクレイヤ、-(経路#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つ以上の被膜剥離術を受けたトンネルパケットです、そして、すなわち、パケットには、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を見てください)。
Conta & Deering Standards Track [Page 8] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[8ページ]RFC2473ジェネリックパケット
+-----------------------+ +-----------------------------------+
| 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 |
+-----------------------+ +-----------------------------------+
+-----------------------+ +-----------------------------------+ | 上側の層のプロトコル| | IPv6のトンネルの上側の層| | | | | | | | ---<-------------------<------- | | | | | ---->--、|、-、-、-、-、--、>、-、-、-、-、-、-、-、--、|、|、|、|、|、|、|、|、|、|、|、| +-----------------------+ +-----------------------+ | | | | | | | | | | | | ^に対して| ^^v^v^対Tunnelに| | | | | | | | | | | | パケット| | | | +---------------------------------------------+ | | | | | | | | | / / | | | | D E| | ^IPv6に対して| --<。3--//--<。---- | | | | E N| | | | 層---->。4-/-/--->--、|、|、|、|、| C C| | ^//に対して| | | | | | A| | | | 2 1 | | | | | | P P| | ^に対して-----<--5---//-<。---- ^対^に| | S S| | | | | -->--6---//(>)| | | | | | | U U| | ^に対して| | / / 6 5 4 3 8 7 | | L L| | | | | | / / | | | | | | | | A| | ^^に対するv^//に対して| | | | | | T T| +---------------------------------------------+ | E E| | | | | | | | | | | | | | | | | ^^v^v^対^v^v Originalに| | | | | | | | | | | | | | | | パケット| ^に対して| +-----------------------+ +-----------------------+ | | | | | | | | | | | | | | | | | | | ---|、-、-、--、|、-、-、-、-、-、--、<、-、-、-、-、-、-、--、|、|、|、|、| --->--------------->------>---- | | | | | | リンク層プロトコル| | IPv6トンネルリンクレイヤ| +-----------------------+ +-----------------------------------+
Fig.5 Packet Flow in the IPv6 Tunneling Protocol Engine on a Node
ノードの上のIPv6トンネリングプロトコルエンジンでのFig.5パケット流動
(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、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)
(u.o.2)トンネルリンクレイヤ、-(経路#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
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[9ページ]RFC2473ジェネリックパケット
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. 私)は「リンクレイヤ入力にトンネルを堀ります」--カプセルに入れられるオリジナルの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、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)
(l.i.2)リンクレイヤ、-(経路#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)
(l.i.3)トンネル覚醒剤層、-(経路#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.
これらのパケットは入れ子にされたカプセル化を受けるトンネルパケットです。 このノードは外トンネルと内側のトンネルの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、Fig.5)
These original packets are destined to this node.
これらのオリジナルのパケットはこのノードに運命づけられています。
(l.o.2) a link-layer - (path #5, Fig.5)
(l.o.2)リンクレイヤ、-(経路#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
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[10ページ]RFC2473ジェネリックパケット
(l.o.3) a tunnel upper-layer - (path #7, Fig.5)
(l.o.3)トンネル覚醒剤層、-(経路#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.
これらのパケットは別の被膜剥離術を受けます。 それらは入れ子にされたトンネルパケットでした。 このノードは外トンネルの出口ポイントノードと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トンネルのリンク」の選択はノードの経路指定テーブルの内容に基づいて取られたパケット推進決定から生じます。
4. Nested Encapsulation
4. 入れ子にされたカプセル化
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トンネルのホップがトンネルであるときに、それは行われます。 トンネルを含むトンネルは外トンネルと呼ばれます。 外トンネルに保管されていたトンネルは内側のトンネルと呼ばれます--Fig.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トンネル」への「入れ子にされたトンネルパケット」です。
Conta & Deering Standards Track [Page 11] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[11ページ]RFC2473ジェネリックパケット
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
Fig.6。 入れ子にされたカプセル化
4.1 Limiting Nested Encapsulation
4.1 入れ子にされたカプセル化を制限すること。
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ヘッダーのサイズをカプセル化されたパケットのサイズに加えます。 その結果、トンネルヘッダーの数、およびしたがって、入れ子にされたカプセル化の数は最大のパケットサイズによって制限されます。 しかしながら、この限界がとても大きいので(最小規模のオリジナルのパケットのための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-仕様]を必要とするかもしれません--セクション7を見てください。 その上、各断片化、既に断片化しているトンネルパケットの入れ子にされたカプセル化への支払われるべきものは結果として生じます。断片の数の倍増で。 そのうえ、この断片化がいったん始まると、それぞれの新しい入れ子にされたカプセル化がまだ追加している断片化をもたらすのは、ありえそうです。 したがって、入れ子にされたカプセル化を制限するのはお勧めです。
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 Destination Options拡張ヘッダーで運ばれます)。
Conta & Deering Standards Track [Page 12] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[12ページ]RFC2473ジェネリックパケット
4.1.1 Tunnel Encapsulation Limit Option
4.1.1 トンネルカプセル化限界オプション
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.)
トンネルエントリー・ポイントノードは、情報の一部がそのノードでトンネルに入るすべてのパケットにprependedされたときTunnel Encapsulation Limitオプションを含むように構成されるかもしれません。 Tunnel Encapsulaton Limitオプションは要約のIPv6ヘッダーとオリジナルのパケットのIPv6ヘッダーの間に置かれたDestination Options拡張ヘッダー[IPv6-仕様]で運ばれます。 (また、Destination Options拡張ヘッダーに先行するか、または続いて、他の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オプションは、オプション自体が含まれているカプセル化を数えないことでいくつの追加レベルのカプセル化によってパケット(言い換えれば、受けるパケットが許可されている巣篭もりのさらなるいくつのレベル)にprependedされることが許可されているかを指定します。 例えば、ゼロの制限値を含む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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
オプションタイプが選ぶ、Dataレンはデータレン0 1 2 3 4 5 6 7+++++++++++++++++++++++++を選びます。|0 0 0 0 0 1 0 0| 1 | 大酒樽Encapリム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type decimal value 4
オプションTypeデシマル値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-仕様]に変わらせないのを示します。
Opt Data Len value 1 - the data portion of the Option is one octet
long.
Dataレン価値1を選んでください--長い間、Optionのデータ部は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ビットの符号のない整数が、カプセル化のさらなるレベルがいくつにおいて受入れられるかを指定して、Data Value Tunnel Encapsulation Limitは評価します。
Conta & Deering Standards Track [Page 13] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[13ページ]RFC2473ジェネリックパケット
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:
トンネルEncapsulation Limitオプションはトンネルエントリー・ポイントだけに興味があります。 トンネルエントリー・ポイントノードがそのノードでトンネルに入るあらゆるパケットのために以下の手順を実行するのに必要です:
(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ヘッダーに続いて、Tunnel Encapsulation Limitオプションが存在しているかどうか確認してください。 厳しい「左から右」オーダーでIPv6ヘッダーについて来るヘッダーを調べなければなりません、以下のヘッダーのどれかが遭遇するとすぐに、試験が止まっていて: (i) Tunnel Encapsulation Limitを含むDestination Options拡張ヘッダー、別の(ii)IPv6ヘッダー、TCP、UDP、またはICMPなどの(iii)非拡張ヘッダー、それが暗号化されているので分析できない(iv)ヘッダーまたはそのタイプが未知です。 (このrequirmentがDestination Options拡張ヘッダーがパケットの目的地ノードによって調べられるだけでよいという一般的なIPv6規則への例外であることに注意してください。 代替手段と「より清潔な」アプローチがこのためにホップによるHop拡張ヘッダーを使用するだろうことでしたが、それは望ましくない付加的な処理負担、および可能な結果の付加的な遅れを課したでしょう、トンネルの経路に沿ったあらゆる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) Tunnel Encapsulation Limitオプションがトンネルに入るパケットで見つけられて、制限値がゼロであるなら、パケットは捨てます、そして、ICMP Parameter Problemメッセージ[ICMP-仕様]をパケットの源に送ります。(パケットは前のトンネルエントリー・ポイントノードです)。 Parameter ProblemメッセージのCode分野が(「遭遇する誤ったヘッダーフィールド」)のゼロに合うように設定されて、Pointer分野がTunnel Encapsulation Limitオプション(すなわち、ゼロの制限値を含む八重奏)の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) Tunnel Encapsulation Limitオプションがトンネルに入るパケットで見つけられて、制限値が非ゼロであるなら、このエントリー・ポイントで加えられている要約のヘッダーの一部として追加Tunnel Encapsulation Limitオプションを含まなければなりません。 要約オプションにおける制限値はパケットで存在がカプセル化されるのが制限値によってわかったよりそれほど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) Tunnel Encapsulation Limitオプションがトンネルに入りながらパケットで見つけられないで、カプセル化限界がこのトンネルに構成されたなら、このエントリー・ポイントで加えられている要約のヘッダーの一部としてTunnel Encapsulation Limitオプションを含まなければなりません。 オプションにおける制限値は構成された限界に設定されます。
Conta & Deering Standards Track [Page 14] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[14ページ]RFC2473ジェネリックパケット
(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) Tunnel Encapsulation Limitオプションがトンネルに入りながらパケットで見つけられないで、またカプセル化限界が全くこのトンネルに構成されていないなら、Tunnel Encapsulation Limitオプションは全くこのエントリー・ポイントで加えられている要約のヘッダーの一部として含まれていません。
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.
被膜剥離術プロセスの一部としてそのトンネルのエキジットポイントノードでトンネルエントリー・ポイントノードで加えられたTunnel Encapsulation Limitオプションを取り除きます。
Two cases of encapsulation that should be avoided are described below:
避けられるべきである2つのケースのカプセル化は以下で説明されます:
4.1.2 Loopback Encapsulation
4.1.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.
そのような場合を避けるために、実装にはエントリー・ポイントとエキジットポイントノードアドレスの両方が同じノードに属するトンネルの構成をチェックして、拒絶するメカニズムがあるのは、お勧めです。 また、要約エンジンが元のパケットソースと最終的な送付先アドレスについてチェックして、トンネルエントリー・ポイントと組と同じエキジットポイントアドレスの組があるパケットのカプセル化を拒絶するのも、お勧めです。
4.1.3 Routing-Loop Nested Encapsulation
4.1.3 ルート設定輪の入れ子にされたカプセル化
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つのメカニズムによって制御されるべきです:
Conta & Deering Standards Track [Page 15] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[15ページ]RFC2473ジェネリックパケット
(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.
入れ子にされたカプセル化における、過度のカプセル化危険因子の議論に関しては、Appendix Aを見てください。
5. Tunnel IPv6 Header
5. トンネルIPv6ヘッダー
The tunnel entry-point node fills out a tunnel IPv6 main header [IPv6-Spec] as follows:
トンネルエントリー・ポイントノードは以下のトンネルIPv6主なヘッダー[IPv6-仕様]に書き込みます:
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.
もしあれば元のパケット長、および要約(prependedされる)のIPv6拡張ヘッダーの長さ
Next Header:
次のヘッダー:
The next header value according to [IPv6-Spec] from the
Assigned Numbers RFC [RFC-1700 or its successors].
Assigned民数記RFC[RFC-1700かその後継者]からの[IPv6-仕様]に従った次のヘッダー値。
For example, if the original packet is an IPv6 packet, this
is set to:
例えば、オリジナルのパケットがIPv6パケットであるなら、これによる以下のことように設定されます。
Conta & Deering Standards Track [Page 16] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[16ページ]RFC2473ジェネリックパケット
- decimal value 41 (Assigned Next Header number for
IPv6) - if there are no tunnel extension headers.
- デシマル値41(IPv6のNext Header番号は割り当てられます)--トンネル拡張ヘッダーが全くいなければ。
- 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.
- ホップオプション拡張ヘッダーによるホップがすぐにトンネルIPv6ヘッダーに続くなら、0(IPv6 HopのNext Header番号はHop Options拡張ヘッダーによって割り当てられる)を評価してください。
- 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.
- デシマル値60(IPv6 Destination Options拡張ヘッダーのNext Header番号は割り当てられます)--目的地オプション拡張ヘッダーがすぐにトンネル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).
ホストのためのデフォルト値はNeighborディスカバリーがホップ限界[ノースダコタ-仕様]の広告を出したということです。 ルータのためのデフォルト値はAssigned民数記RFC(このドキュメントを書く時点の64)からのデフォルトIPv6 Hop Limit価値です。
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を見てください。
5.1 Tunnel IPv6 Extension Headers
5.1 トンネルIPv6拡張ヘッダー
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ノード設定パラメータによって、トンネルエントリー・ポイントノードは、よりIPv6の主なより多くのヘッダー1IPv6拡張ヘッダーをトンネルに追加するかもしれません、ホップによるHop Optionsヘッダー、ルート設定ヘッダー、または他のものなどのように。
Conta & Deering Standards Track [Page 17] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[17ページ]RFC2473ジェネリックパケット
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を見てください)、トンネルエントリー・ポイントはTunnel Encapsulation Limitオプションを含むDestination Options拡張ヘッダーを含んでいます。 そのオプションが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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のヘッダー|Hdr Extレン=0| タイプ=4を選んでください。|Dataレン=1を選んでください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 大酒樽Encapリム|PadNはタイプ=1を選びます。|Dataレン=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パケットであるなら、次のヘッダープロトコル価値はデシマル値41に設定されます(IPv6のペイロード形式数を割り当てます)。
Hdr Ext Len:
Hdr Extレン:
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八重奏ユニットのDestination Options拡張ヘッダーの長さ。 どんな別の選択肢もこの目的地オプションヘッダーに存在していないならセットして、0を評価してください。
Option Type:
オプションタイプ:
value 4 - see section 4.1.1.
値4--セクション4.1.1を見てください。
Opt Data Len:
Dataレンを選んでください:
value 1 - see section 4.1.1.
値1--セクション4.1.1を見てください。
Tun Encap Lim:
大酒樽Encapリム:
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:
Dataレンを選んでください:
value 1 - one octet of option data.
オプションデータの1--1つの八重奏を評価してください。
Conta & Deering Standards Track [Page 18] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[18ページ]RFC2473ジェネリックパケット
Option Data:
オプションデータ:
value 0 - one zero-valued octet.
0--1つの無評価された八重奏を評価してください。
6. IPv6 Tunnel State Variables
6. IPv6トンネル州の変数
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
6.1 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ヘッダーのソースアドレス・フィールドにコピーされます。
6.2 IPv6 Tunnel Exit-Point Node Address
6.2 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 AutoconfigurationかIPv6 Neighborディスカバリーを受けることがありません。
6.3 IPv6 Tunnel Hop Limit
6.3 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トンネルのホップの数にかかわらず。
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:
トンネルのホップ限界がそれが確実にする値によって構成されるのは、お勧めです:
Conta & Deering Standards Track [Page 19] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[19ページ]RFC2473ジェネリックパケット
(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 Neighborディスカバリーがホップ限界[ノースダコタ-仕様]の広告を出したということです。 ルータのためのトンネルホップ限界デフォルト値はAssigned民数記RFC(このドキュメントを書く時点の64)からのデフォルトIPv6 Hop Limit価値です。
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ヘッダーのホップ限界分野にコピーされます。
6.4 IPv6 Tunnel Packet Traffic Class
6.4 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 Tunnel Packet Traffic Classはトンネルエントリー・ポイントノードがトンネルヘッダーのTraffic Class分野に設定する値を示します。 デフォルト値はゼロです。 また、構成されたPacket Traffic Classが、トンネルヘッダーのTraffic Class分野の値がオリジナルのヘッダーからコピーされるかどうかを示すことができますか、またはそれはあらかじめ設定された値に設定されます。
6.5 IPv6 Tunnel Flow Label
6.5 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 Tunnel Flow Labelはaトンネルエントリーポイントノードがトンネルヘッダーの流れラベルに設定する値を示します。 デフォルト値はゼロです。
6.6 IPv6 Tunnel Encapsulation Limit
6.6 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 Tunnel Encapsulation Limitはそのエントリー・ポイントノードでカプセル化を受けるパケットのために受入れられた追加カプセル化の最大数です。 お勧めのデフォルト値は4です。 エントリー・ポイントノードは、カプセル化を受けるオリジナルのパケットにTunnel Encapsulation Limitオプションを含むDestination Options拡張ヘッダー--入れ子にされたカプセル化prependsの数を制限するために、セクション4.1と4.1.1を見るように構成しました。
6.7 IPv6 Tunnel MTU
6.7 IPv6トンネル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
トンネルMTUはダイナミックにトンネルエントリー・ポイントとトンネルエキジットポイントノードの間のPath MTUに用意ができています、トンネルヘッダーのサイズを引いて: そうすることができるトンネルパケットペイロードの最大サイズ
Conta & Deering Standards Track [Page 20] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[20ページ]RFC2473ジェネリックパケット
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.
トンネルを通して断片化[IPv6-仕様]なしで送ってください。 トンネルエントリー・ポイントノードはトンネルエントリー・ポイントとエキジットポイントノード[PMTU-仕様]の間の経路、[ICMP-仕様]にPath MTU発見を実行します。 入れ子にされたトンネルのトンネルMTUは入れ子にされたトンネルヘッダーのサイズを引いた外トンネルのトンネルMTUです。
7. IPv6 Tunnel Packet Size Issues
7. IPv6トンネルパケットサイズ問題
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.
トンネルヘッダーをPrependingすると、パケットのサイズは増強されます、したがって、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.
断片化しているトンネルパケットの目的地がanycastアドレスによって特定されたエキジットポイントノードであるときに、特定の問題は起こります。 問題(anycastアドレスによって特定されたノードに運命づけられたオリジナルの断片化しているIPv6パケットのものと同様である)はそのノードがうまくいっている再アセンブリを実行できるようにパケットのすべての断片が同じ目的地ノードに届かなければならないということです、必ずanycastアドレスに送られたパケットによって満たされるというわけではない要件。
7.1 IPv6 Tunnel Packet Fragmentation
7.1 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オリジナルのパケットに入ると、aはトンネルを堀ります、元のパケットサイズがトンネルMTUを超えているなら。(すなわち、トンネルエントリー・ポイントの間のPath MTUとトンネルヘッダー(s))のサイズを引いたトンネルエキジットポイント、それは以下の通り扱われます:
Conta & Deering Standards Track [Page 21] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[21ページ]RFC2473ジェネリックパケット
(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-仕様]より大きいなら、エントリー・ポイントノードがパケットを捨てて、ICMPv6を送る、「パケット、大き過ぎる、」 お勧めのMTUサイズ分野があるオリジナルのパケットのソースアドレスへのメッセージはトンネルMTUかIPv6の最小のリンクMTUにセットしました、どれがさらに大きいかなら、すなわち、最大(MTUにトンネルを堀ってください、IPv6の最小のリンク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より等しいか、または小さいなら、トンネルエントリー・ポイントノードは、オリジナルのパケットをカプセルに入れって、次に、トンネルエキジットポイントにPath MTUを超えていないIPv6断片に結果として起こるIPv6トンネルパケットを断片化します。
7.2 IPv4 Tunnel Packet Fragmentation
7.2 IPv4トンネルパケット断片化
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オリジナルのパケットに入ると、aはトンネルを堀ります、元のパケットサイズがトンネルMTUを超えているなら。(すなわち、トンネルエントリー・ポイントの間のPath MTUとトンネルヘッダー(s))のサイズを引いたトンネルエキジットポイント、それは以下の通り扱われます:
(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) Fragmentではなく、ドン--DF--噛み付いている旗がオリジナルのIPv4パケットのヘッダーのSETであるなら、エントリー・ポイントノードは、パケットを捨てて、ICMPメッセージを返します。 ICMPメッセージには=「手が届きません」タイプがあって、コードが=である、「パケット、大き過ぎる、」 お勧めの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.
Fragmentではなく、ドン(DF)がオリジナルのパケットのヘッダーで旗に噛み付いたなら(b)がCLEARである、トンネルエントリー・ポイントノードはオリジナルのパケットをカプセルに入れります、そして、トンネルエキジットポイントにPath MTUを超えていないIPv6断片への結果として起こるIPv6トンネルパケットが次に、断片化します。
8. IPv6 Tunnel Error Processing and Reporting
8. IPv6トンネルエラー処理と報告
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 Tunnelingは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パケットの源に報告されます。
Conta & Deering Standards Track [Page 22] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[22ページ]RFC2473ジェネリックパケット
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.
トンネルの中にオリジナルのパケットの源まで検出された問題を報告するために、トンネルエントリーポイントノードはトンネルからそのオリジナルの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、および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経路#0とFig.8(a)--IPv6トンネルエントリー・ポイントはトンネル(Fig.7の著しいTunnel ICMPv6 Message)の中からICMPパケットを受けます。 トンネルエントリー・ポイントノードIPv6層は受信されたICMPメッセージをICMPv6 Inputに通過します。 タイプとコード[ICMP-仕様]が内部の「エラーコード」であると生成するICMPに基づいたICMPv6 Input。
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.
Fig.7経路#1--内部エラーコードは「ICMPv6メッセージペイロード」で上側の層に通過されて、議定書を作ってください--この場合IPv6が上側の層の誤り入力にトンネルを堀るということです。
Conta & Deering Standards Track [Page 23] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[23ページ]RFC2473ジェネリックパケット
+-------+ +-------+ +-----------------------+
| 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
| | |
+-------+ +-------+ +-----------------------+ | 上側| | 上側| | 上側| | 層| | 層| | 層| | プロト、|| プロト| | IPv6トンネル| | 誤り| | 誤り| | 誤り| | 入力| | 入力| | 入力| | | | | | Decapsulate| | | | | | -->--ICMPv6--2#>--| | | | | | | 有効搭載量| | +-------+ +-------+ +--|-----------------|--+ | | | | ^ ^ ^v| | | | --------------------#1-- -----Orig.Packet?--- - - - - - - - #1 #3 Int.Error Code、#5| Int.Error Code、Source Address対v ICMPv6有効搭載量への^| IPv6| Orig。 パケット| IPv4| +--------------+ +------------+ +------------+ + - - + | | | | | | | ICMP v6| | ICMP v6| | ICMP v4| | | | 入力| | 間違え、レポート| | 間違え、レポート| | - - - - +----+ - - - -| + - - - -+ + - - + | | | | | IPv6層| | IPv4層| | | | | | | +--------------------------------+ +------------+ + - - + | | | ^V V#0#4#6| | | トンネルICMPv6 ICMPv6 ICMPv4メッセージメッセージメッセージ| | |
Fig.7 Error Reporting Flow in a Node (IPv6 Tunneling Protocol Engine)
ノードにおける流れを報告するFig.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.
Fig.7経路#2とFig.8(b)--IPv6トンネル誤りはトンネルIPv6パケット(ICMPv6メッセージペイロードであり、オリジナルのパケットを得て、その結果、オリジナルのヘッダーを得て、「内部のエラーコード」、オリジナルのパケットのヘッダーからのソースアドレス、およびオリジナルのパケットを派遣する)がすぐにICMPメッセージペイロードでオリジナルのパケットに先行しながらトンネルヘッダーでNext Header分野によって特定されたプロトコルのエラー・レポートブロックに倒すdecapsulatesを入力しました。
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
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[24ページ]RFC2473ジェネリックパケット
(a) - for an IPv6 original packet
IPv6のオリジナルのパケットのための(a)
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経路#3とFig.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.
Fig.7経路#4とFig.8(d.1)--ICMPメッセージは、ソースアドレスとしてトンネルエントリー・ポイントノードアドレスを持っていて、送付先アドレスとしてオリジナルのパケットソースノードアドレスを持っています。 トンネルエントリー・ポイントノードはオリジナルのパケットのソースノードにICMPメッセージを送ります。
(b) - for an IPv4 original packet
IPv4のオリジナルのパケットのための(b)
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経路#5とFig.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.
Fig.7経路#6とFig.8(d.2)--ICMPメッセージは、ソースアドレスとしてトンネルエントリー・ポイントノードIPv4アドレスを持っていて、送付先アドレスとしてオリジナルのパケットIPv4ソースノードアドレスを持っています。 トンネルエントリー・ポイントノードはオリジナルのパケットのソースノードにICMPメッセージを送ります。
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
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[25ページ]RFC2473ジェネリックパケット
< 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 >
<トンネルパケット>+--------+- - - - - -+--------+------------------------------//------+ | IPv6| IPv6| ICMP| トンネル| (a)| | 拡大| | IPv6| | ヘッダー| ヘッダー| ヘッダー| 間違いパケット| +--------+- - - - - -+--------+------------------------------//------+ <トンネルヘッダー><トンネルICMPメッセージ><ICMPv6メッセージ有効搭載量>。| Error>+の<Tunnel ICMP Message><Tunnel IPv6 Packetに対して--------+ +---------+ +----------+--------//------+ | ICMP| | トンネル| | オリジナル| オリジナル| (b) | | + | IPv6| + | | パケット| | ヘッダー| | ヘッダー| | ヘッダー| 有効搭載量| +--------+ +---------+ +----------+--------//------+ | <のオリジナルのパケットの間違った>。----------------- | | | --------------|--------------- | | +に対するV---------+ +--------+ +-------------------//------+ | 新しい| | ICMP| | | (c.1) | IPv6| + | | + | Orig。 間違いパケット| | ヘッダー| | ヘッダー| | | +---------+ +--------+ +-------------------//------+ | +に対して---------+--------+-------------------//------+ | 新しい| ICMP| オリジナル| (d.1) | IPv6| | | | ヘッダー| ヘッダー| 間違いパケット| +---------+--------+-------------------//------+ <の新しいICMPメッセージ>。
Conta & Deering Standards Track [Page 26] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[26ページ]RFC2473ジェネリックパケット
or for an IPv4 original packet
または、IPv4のオリジナルのパケットのために
+---------+ +--------+ +-------------------//------+
| 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 >
+---------+ +--------+ +-------------------//------+ | 新しい| | ICMP| | | (c.2) | IPv4| + | | + | Orig。 間違いパケット| | ヘッダー| | ヘッダー| | | +---------+ +--------+ +-------------------//------+ | +に対して---------+--------+-------------------//------+ | 新しい| ICMP| オリジナル| (d.2) | IPv4| | | | ヘッダー| ヘッダー| 間違いパケット| +---------+--------+-------------------//------+ <の新しいICMPメッセージ>。
Fig.8 ICMP Error Reporting and Processing
Fig.8 ICMP誤り報告と処理
8.1 Tunnel ICMP Messages
8.1 トンネル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.
トンネルは、misconfiguredホップ限界を持っているか、またはルーティング輪を含んでいます、そして、パケットはトンネル出口が指すどんな範囲にもノードをしません。 この問題はトンネルに報告されて、エントリーがノードを指すということです、トンネルのホップ限界をより高い値に再構成できるところで。 問題はセクション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
Tun Encapリム分野選択値群で有効なTunnel Encapsulation Limit Destinationヘッダーを1つに示すParameter Problem ICMPメッセージが指示である、それ、トンネル
Conta & Deering Standards Track [Page 27] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[27ページ]RFC2473ジェネリックパケット
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.
パケットは許容されたカプセル化の最大数を超えていました。 問題はセクション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.
トンネルパケットはトンネルPath 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.
- MTUサイズをオリジナルのパケットの源まで示す送付トンネルエントリー・ポイントノードで、それは送付IPv6パケットでトンネルエントリー・ポイントノードに向かって使用されるべきです。
8.2 ICMP Messages for IPv6 Original Packets
8.2 IPv6のオリジナルのパケットへのICMPメッセージ
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.
Original IPv6ヘッダーのSource Address分野から、コピーされます。
ICMP Fields:
ICMP分野:
For any of the following tunnel ICMP error messages:
以下のどれかに関しては、ICMPエラーメッセージにトンネルを堀ってください:
"hop limit exceeded"
「超えられていたホップ限界」
Conta & Deering Standards Track [Page 28] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[28ページ]RFC2473ジェネリックパケット
"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リム分野がある有効なTunnel Encapsulation Limit目的地ヘッダーを示すのは値ゼロにセットしました:
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 MTUはトンネルICMPメッセージマイナスからトンネルヘッダーの長さをさばきます。
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で説明された総則、「パケット、大き過ぎる、」 元のパケットサイズが最小のリンクMTUサイズがIPv6[IPv6-仕様]に必要であるというよりも大きい場合にだけ、オリジナルのパケットの源にメッセージを送ります。
8.3 ICMP Messages for IPv4 Original Packets
8.3 IPv4のオリジナルのパケットへの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.
Original IPv4ヘッダーのSource Address分野から、コピーされます。
ICMP Fields:
ICMP分野:
For any of the following tunnel ICMP error messages:
以下のどれかに関しては、ICMPエラーメッセージにトンネルを堀ってください:
"hop limit exceeded"
「超えられていたホップ限界」
Conta & Deering Standards Track [Page 29] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[29ページ]RFC2473ジェネリックパケット
"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リム分野がある有効な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 MTUはトンネルICMPメッセージマイナスからトンネルヘッダーの長さをさばきます。
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で説明された総則、「パケット、大き過ぎる、」 オリジナルのIPv4ヘッダーがDFを持っているなら、オリジナルのIPv4パケットソースノードにメッセージを送ります--断片化しないでください--ビット旗のSET。
8.4 ICMP Messages for Nested Tunnel Packets
8.4 入れ子にされたトンネルパケットへのICMPメッセージ
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.
入れ子にされたトンネルパケットでむき出しである誤りの場合には、セクション8.で説明されたメカニズム、8.1、8.2、および8.3に続いて、内側のトンネルエントリー・ポイント(内側のトンネル報告ノードからICMPエラーメッセージを受け取る)は外トンネルエントリー・ポイントにICMPメッセージをリレーします。 さらに、同じメカニズムに従って、外トンネルエントリー・ポイントはオリジナルのパケットの源にICMPメッセージをリレーします。
9. Security Considerations
9. セキュリティ問題
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トンネルに関しては、より早く本書では説明されたメカニズムに加えて、トンネルのエントリー・ポイントノードは、よりトンネルより多くのヘッダー1セキュリティヘッダーの一部として[IPv6-仕様]か、[RFC2401]と、[RFC2402]か、[RFC2406]との順応でパケットとprependsにセキュリティアルゴリズムを実行します。
Conta & Deering Standards Track [Page 30] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[30ページ]RFC2473ジェネリックパケット
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.
[s] トンネルヘッダー処理の一部が、より早期、および[RFC2401]と、[RFC2402]か、[RFC2406]との順応で説明したように、安全なIPv6トンネルのエキジットポイントノードは、セキュリティアルゴリズムを実行して、トンネルセキュリティヘッダーを処理します。 エキジットポイントノードは次々とトンネルトンネルヘッダーの残りが完成を処理しているトンネルセキュリティヘッダー[s]を捨てます。
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)か暗号化(超能力))とSecurity Associationでトンネルに構成されたパラメタのタイプに頼っています。 トンネルパケットのペイロードであるオリジナルのパケットに適用されたトンネルパケットとセキュリティに適用されたセキュリティー・レベルとメカニズムとのどんな依存も相互作用もありません。 入れ子にされたトンネルの場合には、それぞれの内側のトンネルには、それ自身のセキュリティー・サービスのセットが外トンネル、またはオリジナルのパケットのソースと目的地の間のそれらのものから独自にあるかもしれません。
10. Acknowledgments
10. 承認
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作業部会Mailing ListとフィードバックからIPng作業部会から第33IETFでトンネルを堀るIPv6にそんなに集中しているIPv6プレゼンテーションまでトンネルを堀るIPv6についてのいくつかの議論からこのドキュメントを部分的に得ます、ストックホルムで、1995年7月に。
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).
さらに、トンネルを堀るのは焦点を合わせた以下のドキュメントかカプセル化が有用な参照でした: RFC1933(R.ギリガン、E.Nordmark)、RFC1241(R.Woodburn、D.ミルズ)、RFC1326(P.Tsuchiya)、RFC1701、RFC1702(S.ハンクス、D.ファリナッチ、P.Traina)、RFC1853(W.シンプソン)、およびRFC2003(C.パーキンス)。
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.
ブライアンCarpenter、リチャードDraves、ボブHinden、トーマスNarten、エリックNordmarkは(アルファベット順に)このドキュメントの改良のためのコメントと提案を貴重な論評に与えました。 スコット・ブラドナー、ロスCallon、ドミトリー・ハスキン、ポールTraina、およびジェームズ・ワットは懸念材料で(アルファベット順に)本書では彼らの視点か経験を共有しました。 彼女の何年も社説のサンプルを提供して、技術的に相当量の調べと同様に経験を書いているジュディス・グロースマンが質問します。
11. References
11. 参照
[IPv6-Spec] Deering, S. and R. Hinden, "Internet Protocol
Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6-仕様] デアリングとS.とR.Hinden、「インターネットプロトコルバージョン6(IPv6)仕様」、RFC2460、1998年12月。
Conta & Deering Standards Track [Page 31] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[31ページ]RFC2473ジェネリックパケット
[ICMP-Spec] Conta, A. and S. Deering "Internet Control Message
Protocol for the Internet Protocol Version 6 (IPv6)", RFC
2463, December 1998.
[ICMP-仕様] 「インターネットコントロールメッセージはインターネットプロトコルバージョン6(IPv6)のために議定書の中で述べる」コンタ、A.、およびS.デアリング、RFC2463(1998年12月)
[ND-Spec] Narten, T., Nordmark, E., and W. Simpson "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[ノースダコタ-仕様] Narten、T.、Nordmark、E.、およびW.シンプソンを「IPバージョン6(IPv6)のために発見を近所付き合いさせる」、RFC2461、12月1998日
[PMTU-Spec] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery
for IP Version 6 (IPv6)", RFC 1981, August 1996.
マッキャンとJ.とデアリングとS.とJ.ムガール人、「IPバージョン6(IPv6)のための経路MTU発見」という[PMTU-仕様]、RFC1981、1996年8月。
[RFC2401] Atkinson, R., "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[RFC2401] アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2402] Atkinson, R., "IP Authentication Header", RFC 2402,
November 1998.
[RFC2402] アトキンソン、R.、「IP認証ヘッダー」、RFC2402、1998年11月。
[RFC2406] Atkinson, R., "IP Encapsulation Security Payload (ESP)",
RFC 2406, November 1998.
[RFC2406] アトキンソン、R.、「IPカプセル化セキュリティ有効搭載量(超能力)」、RFC2406、1998年11月。
[RFC-1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October
1995.
[RFC-1853]シンプソン、1995年10月のW.、「IPトンネリングにおけるIP」RFC1853。
[Assign-Nr] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. See also:
http://www.iana.org/numbers.html
[Nrを割り当てている] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。 参照: 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] ブラドナー、S.、「使用のためのRequirement Levelsを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
Authors' Addresses
作者のアドレス
Alex Conta Lucent Technologies Inc. 300 Baker Ave Concord, MA 01742-2168 +1-978-287-2842
アレックスコンタルーセントテクノロジーズ株式会社300ベイカーAveコンコード、MA01742-2168+1-978-287-2842
EMail: aconta@lucent.com
メール: aconta@lucent.com
Stephen Deering Cisco Systems 170 West Tasman Dr San Jose, CA 95132-1706
西タスマン博士サンノゼ、スティーブンデアリングシスコシステムズ170カリフォルニア95132-1706
Phone: +1-408-527-8213 EMail: deering@cisco.com
以下に電話をしてください。 +1-408-527-8213 メールしてください: deering@cisco.com
Conta & Deering Standards Track [Page 32] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[32ページ]RFC2473ジェネリックパケット
Appendix A
付録A
A.1 Risk Factors in Nested Encapsulation
入れ子にされたカプセル化におけるA.1危険因子
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はNested EncapsulationでFactorを危険にさらします--トンネルのタイプ。
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
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[33ページ]RFC2473ジェネリックパケット
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はNested EncapsulationでFactorを危険にさらします--ルートのタイプ。
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つ以上の内側のトンネルに外トンネルエキジットポイントのネットにルートを合わせるエキジットポイントノードアドレスがあるなら、トンネルパケットがそのような内側のトンネルから内側のトンネルのエキジットポイントに合っているエキジットポイントにルートを持っている外トンネルのエントリー・ポイントに紛らされるなら、再帰的なカプセル化は起こるかもしれません。
Conta & Deering Standards Track [Page 34] RFC 2473 Generic Packet Tunneling in IPv6 December 1998
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[34ページ]RFC2473の一般的なパケット
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
IPv6 December 1998でトンネルを堀るコンタとデアリング標準化過程[35ページ]RFC2473の一般的なパケット
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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]
コンタとデアリング標準化過程[36ページ]
一覧
スポンサーリンク
