[要約] RFC 7059は、IPv6-over-IPv4トンネルメカニズムの比較に関するドキュメントです。このRFCの目的は、異なるトンネルメカニズムの特徴と利点を説明し、IPv6ネットワークの展開に役立つ情報を提供することです。
Independent Submission S. Steffann
Request for Comments: 7059 S.J.M. Steffann Consultancy
Category: Informational I. van Beijnum
ISSN: 2070-1721 Institute IMDEA Networks
R. van Rein
OpenFortress
November 2013
A Comparison of IPv6-over-IPv4 Tunnel Mechanisms
IPv6-over-IPv4トンネルメカニズムの比較
Abstract
概要
This document provides an overview of various ways to tunnel IPv6 packets over IPv4 networks. It covers mechanisms in current use, touches on several mechanisms that are now only of historic interest, and discusses some newer tunnel mechanisms that are not widely used at the time of publication. The goal of the document is helping people with an IPv6-in-IPv4 tunneling need to select the mechanisms that may apply to them.
このドキュメントでは、IPv4ネットワークを介してIPv6パケットをトンネリングするさまざまな方法の概要を説明します。現在使用されているメカニズムについて説明し、現在は歴史的にのみ関心のあるいくつかのメカニズムに触れ、公開時には広く使用されていないいくつかの新しいトンネルメカニズムについて説明します。このドキュメントの目的は、IPv6-in-IPv4トンネリングを使用するユーザーが、適用されるメカニズムを選択する必要があることを支援することです。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7059.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7059で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Tunnel Mechanisms . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Configured Tunnels (Manual Tunnels / 6in4) . . . . . . . . 7
3.2. Automatic Tunneling . . . . . . . . . . . . . . . . . . . 8
3.3. IPv6 over IPv4 without Explicit Tunnels (6over4) . . . . . 9
3.4. Generic Routing Encapsulation (GRE) . . . . . . . . . . . 10
3.5. Connection of IPv6 Domains via IPv4 Clouds (6to4) . . . . 10
3.5.1. 6to4 Provider Managed Tunnels . . . . . . . . . . . . 11
3.6. Anything In Anything (AYIYA) . . . . . . . . . . . . . . . 12
3.7. Intra-Site Automatic Tunnel Addressing (ISATAP) . . . . . 13
3.8. Tunneling IPv6 over UDP through NATs (Teredo) . . . . . . 14
3.9. IPv6 Rapid Deployment (6rd) . . . . . . . . . . . . . . . 15
3.10. Native IPv6 behind NAT44 CPEs (6a44) . . . . . . . . . . . 16
3.11. Locator/ID Separation Protocol (LISP) . . . . . . . . . . 16
3.12. Subnetwork Encapsulation and Adaptation Layer (SEAL) . . . 18
3.13. Peer-to-Peer IPv6 on Any Internetwork (6bed4) . . . . . . 19
4. Related Protocols . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Tunnel Setup Protocol (TSP) . . . . . . . . . . . . . . . 20
4.2. SixXS Heartbeat Protocol . . . . . . . . . . . . . . . . . 20
4.3. Tunnel Information and Control Protocol (TIC) . . . . . . 21
5. Common Aspects . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Protocol 41 Encapsulation . . . . . . . . . . . . . . . . 22
5.2. NAT and Firewalls . . . . . . . . . . . . . . . . . . . . 22
5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . . 24
5.4. IPv4 Addresses Embedded in IPv6 Addresses . . . . . . . . 25
6. Evaluation of Tunnel Mechanisms . . . . . . . . . . . . . . . 28
6.1. Efficiency of IPv4 Address Use . . . . . . . . . . . . . . 28
6.2. Supported Network Topologies . . . . . . . . . . . . . . . 29
6.3. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 30
6.4. Gateway State . . . . . . . . . . . . . . . . . . . . . . 32
6.5. Performance . . . . . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
10. Informative References . . . . . . . . . . . . . . . . . . . . 35
Appendix A. Evaluation Criteria . . . . . . . . . . . . . . . . . 40
During the transition from IPv4 to IPv6, IPv6 islands are separated by a sea of IPv4. Tunnels provide connectivity between these IPv6 islands. Tunnels work by encapsulating IPv6 packets inside IPv4 packets, as shown in the figure.
IPv4からIPv6への移行中、IPv6アイランドはIPv4の海によって分離されます。トンネルは、これらのIPv6アイランド間の接続を提供します。図に示すように、トンネルはIPv4パケット内にIPv6パケットをカプセル化することによって機能します。
+---------------+
| IPv4 |
| Header |
+---------------+
: Optional :
: Encapsulation :
: Header :
+---------------+ +---------------+
| IPv6 | | IPv6 |
| Header | | Header |
+---------------+ +---------------+
| Transport | | Transport |
| Layer | ===> | Layer |
| Header | | Header |
+---------------+ +---------------+
| | | |
~ Data ~ ~ Data ~
| | | |
+---------------+ +---------------+
Encapsulating IPv6 in IPv4
IPv4でのIPv6のカプセル化
Various tunnel mechanisms have been proposed over time. So many, in fact, that it is difficult to get an overview. Some tunnel mechanisms have been abandoned by the community, others have known problems, and yet others have shown to be reliable. Some tunnel mechanisms were designed with a particular use case in mind; others are generic. There may be documented limitations as well as limitations that have cropped up in deployment.
時間の経過とともに、さまざまなトンネルメカニズムが提案されてきました。実際には非常に多く、概要を把握するのは困難です。コミュニティによって放棄されたトンネルメカニズムもあれば、既知の問題があるトンネルメカニズムもありますが、信頼できるメカニズムもいくつかあります。一部のトンネルメカニズムは、特定のユースケースを考慮して設計されています。その他はジェネリックです。文書化された制限や、展開で発生した制限がある場合があります。
This document provides an overview of available and/or noteworthy tunnel mechanisms, with the intention to guide selection of the best mechanism for a particular purpose. As such, the discussion of the different tunnel mechanisms is limited to the working principles of the different mechanisms and a few important details.
このドキュメントでは、特定の目的に最適なメカニズムの選択をガイドすることを目的として、使用可能なトンネルメカニズムの概要を説明します。そのため、さまざまなトンネルメカニズムの説明は、さまざまなメカニズムの動作原理といくつかの重要な詳細に限定されます。
Please use the references to learn the full details of each mechanism. For brevity, only the most relevant documents are referenced. Refer to these for additional specifications, updates, and links to older versions of protocol specifications, as well as links to more general background information.
各メカニズムの詳細については、リファレンスをご覧ください。簡潔にするために、最も関連性の高いドキュメントのみを参照しています。追加の仕様、更新、プロトコル仕様の古いバージョンへのリンク、およびより一般的な背景情報へのリンクについては、これらを参照してください。
The intended audience for this document is everyone who needs a connection to the IPv6 Internet at large, but is not in the position to use native (untunneled) IPv6 connectivity, and thus needs to select an appropriate tunnel mechanism. However, when native IPv6 connectivity is available, this should be preferred over tunneled connectivity as per rule 7 in Section 6 of [RFC6724]. This document is also intended as a quick reference to tunnel mechanisms for the IETF community.
このドキュメントの対象読者は、IPv6インターネットへの接続全般が必要だが、ネイティブ（トンネル化されていない）IPv6接続を使用する立場にないため、適切なトンネルメカニズムを選択する必要があるすべての人です。ただし、ネイティブIPv6接続が使用可能な場合は、[RFC6724]のセクション6のルール7に従って、トンネル接続よりも優先する必要があります。このドキュメントは、IETFコミュニティのトンネルメカニズムのクイックリファレンスとしても意図されています。
The scope of this document is limited to tunnel mechanisms for providing IPv6 connectivity over an IPv4 infrastructure. Mechanisms for Virtual Private Networks (VPNs) and security architectures such as IPsec [RFC4301], as well as IPv4-over-IPv6 tunneling, are out of scope for this document as they serve a different purpose, even if they could technically be used to provide IPv6 connectivity.
このドキュメントの範囲は、IPv4インフラストラクチャ上でIPv6接続を提供するためのトンネルメカニズムに限定されています。仮想プライベートネットワーク（VPN）のメカニズムとIPsec [RFC4301]などのセキュリティアーキテクチャ、およびIPv4-over-IPv6トンネリングは、技術的には使用できるとしても、このドキュメントの範囲外です。 IPv6接続を提供します。
Anycast: Mechanism to provide a service, in multiple locations and/or using multiple servers, by configuring each server with the same IP address.
エニーキャスト：各サーバーを同じIPアドレスで構成することにより、複数の場所で、または複数のサーバーを使用して、サービスを提供するメカニズム。
Carrier-Grade NAT (CGN): A Network Address Translation (see NAT) device used by an ISP so multiple subscribers can be served using a single IPv4 address.
キャリアグレードNAT（CGN）：ISPが使用するネットワークアドレス変換（NATを参照）デバイス。これにより、単一のIPv4アドレスを使用して複数の加入者にサービスを提供できます。
Dual stack: Also known as "dual IP layer". Nodes run IPv4 and IPv6 side by side, and can communicate with other dual stack nodes (using IPv4 or IPv6), as well as IPv4-only nodes (using IPv4) and IPv6-only nodes (using IPv6). Most current operating systems are set up to use IPv4 when available as well as use IPv6 when available, allowing them to run in IPv4-only, IPv6-only, or dual stack mode as circumstances permit. Except for a few things concerning the Domain Name System (DNS), there is no separate specification for dual stack beyond the specifications relevant to running IPv4 and IPv6. Dual stack is one of the three IPv4-to-IPv6 transition tools; the others are translation and tunnels.
デュアルスタック：「デュアルIPレイヤー」とも呼ばれます。ノードはIPv4とIPv6を並行して実行し、他のデュアルスタックノード（IPv4またはIPv6を使用）、およびIPv4のみのノード（IPv4を使用）およびIPv6のみのノード（IPv6を使用）と通信できます。現在のほとんどのオペレーティングシステムは、利用可能な場合はIPv4を使用し、利用可能な場合はIPv6を使用するように設定されているため、状況に応じて、IPv4のみ、IPv6のみ、またはデュアルスタックモードで実行できます。ドメインネームシステム（DNS）に関するいくつかの点を除いて、IPv4およびIPv6の実行に関連する仕様を超えるデュアルスタックの個別の仕様はありません。デュアルスタックは、3つのIPv4-to-IPv6移行ツールの1つです。その他は、変換とトンネルです。
Encapsulation: Transporting a packet as data inside another packet. For instance, an IPv6 packet inside an IPv4 packet.
カプセル化：パケットを別のパケット内のデータとして転送します。たとえば、IPv4パケット内のIPv6パケット。
Firewall: A device that selectively filters IP packets, allowing some protocols through but not others. A firewall may act as a switch, operating below the IP layer, or as a router.
ファイアウォール：IPパケットを選択的にフィルタリングするデバイスで、一部のプロトコルのみを通過させ、他のプロトコルは通過させません。ファイアウォールは、IP層の下で動作するスイッチまたはルーターとして機能します。
Host: A device that communicates using the Internet Protocol and only transmits packets from its own address.
ホスト：インターネットプロトコルを使用して通信し、自身のアドレスからのみパケットを送信するデバイス。
ISP: Internet Service Provider; the party connecting the outside of the local network's perimeter to the public Internet.
ISP：インターネットサービスプロバイダー。ローカルネットワークの境界の外側をパブリックインターネットに接続する当事者。
MTU: Maximum Transmission Unit, the maximum size of a packet that can be transmitted over a link (or tunnel) without splitting it into multiple fragments.
MTU：最大転送単位。複数のフラグメントに分割せずにリンク（またはトンネル）を介して転送できるパケットの最大サイズ。
NAT: Network Address Translation or Network Address Translator. NAT makes it possible for a number of hosts to share a single IP address. TCP and UDP port numbers are used to distinguish the traffic to/from different hosts served by the NAT; protocols other than TCP and UDP may be incompatible with NAT due to lack of port numbers. NAT also breaks protocols that depend on the IP addresses used in some way. Typically, NAT devices behave as a host towards the public Internet, and as a router towards the internal network.
NAT：Network Address TranslationまたはNetwork Address Translator。 NATを使用すると、複数のホストが単一のIPアドレスを共有できます。 TCPおよびUDPポート番号は、NATがサービスを提供する異なるホストとの間のトラフィックを区別するために使用されます。 TCPとUDP以外のプロトコルは、ポート番号がないため、NATと互換性がない場合があります。 NATは、何らかの方法で使用されるIPアドレスに依存するプロトコルも破壊します。通常、NATデバイスはパブリックインターネットへのホストとして、および内部ネットワークへのルーターとして動作します。
NBMA: Non-Broadcast Multi-Access. This is a network configuration in which nodes can exchange packets directly by addressing them at the desired destination. However, broadcasts or multicasts are not supported, so autodiscovery mechanisms such as IPv6 Neighbour Discovery must be modified to use unicast to work.
NBMA：非ブロードキャストマルチアクセス。これは、ノードがパケットを目的の宛先でアドレス指定することによって直接交換できるネットワーク構成です。ただし、ブロードキャストまたはマルチキャストはサポートされないため、ユニキャストを使用して機能するように、IPv6近隣探索などの自動検出メカニズムを変更する必要があります。
Node: A device that implements IP, either a host or a router; also known as a system. See note at "NAT".
ノード：ホストまたはルーターのIPを実装するデバイス。システムとも呼ばれます。 「NAT」の注記を参照してください。
Path stretch: The difference between the shortest path through the network and the path (tunneled) packets actually take.
パスストレッチ：ネットワークを通る最短パスとパケット（トンネル）が実際に通るパスの差。
PMTUD: Path MTU Discovery, a method to determine the smallest MTU on the path between two nodes. There are separate specifications for PMTUD over IPv4 [RFC1191] and IPv6 [RFC1981].
PMTUD：パスMTUディスカバリー。2つのノード間のパス上の最小MTUを判別する方法。 PMTUD over IPv4 [RFC1191]とIPv6 [RFC1981]には個別の仕様があります。
Router: A device that forwards IP packets that it didn't generate itself. See note at "NAT".
ルーター：自分で生成しなかったIPパケットを転送するデバイス。 「NAT」の注記を参照してください。
System: A device that implements IP, either a host or a router; a network node.
システム：IPを実装するデバイス（ホストまたはルーター）。ネットワークノード。
Translation: The IPv6 and IPv4 headers are similar enough that it is possible to translate between them. This allows IPv6-only hosts to communicate with IPv4-only hosts. The original specification for translating between IPv6 and IPv4 was heavily criticised by the Internet Architecture Board, but new specifications for translating between IPv6 and IPv4 were later published [RFC6145]. Translation is one of the three IPv4-to-IPv6 transition tools; the others are dual stack and tunnels.
変換：IPv6ヘッダーとIPv4ヘッダーは、それらの間で変換できるほど十分に類似しています。これにより、IPv6のみのホストはIPv4のみのホストと通信できます。 IPv6とIPv4の間の変換に関する元の仕様は、インターネットアーキテクチャボードによって強く批判されましたが、IPv6とIPv4の間の変換に関する新しい仕様が後で公開されました[RFC6145]。変換は、IPv4からIPv6への3つの移行ツールの1つです。その他はデュアルスタックとトンネルです。
Tunnel: By encapsulating IPv6 packets inside IPv4 packets, IPv6- capable hosts and IPv6-capable networks isolated from other IPv6- capable systems or the IPv6 Internet at large can exchange IPv6 packets over IPv4-only infrastructure. There are numerous ways to tunnel IPv6 over IPv4. This document compares these mechanisms. Tunneling is one of the three IPv4-to-IPv6 transition tools; the others are translation and dual stack.
トンネル：IPv4パケット内にIPv6パケットをカプセル化することにより、他のIPv6対応システムまたはIPv6インターネット全体から分離されたIPv6対応ホストおよびIPv6対応ネットワークは、IPv4のみのインフラストラクチャ上でIPv6パケットを交換できます。 IPv4を介してIPv6をトンネリングする方法は多数あります。このドキュメントでは、これらのメカニズムを比較します。トンネリングは、3つのIPv4-to-IPv6移行ツールの1つです。他は翻訳とデュアルスタックです。
Tunnel broker: A service that provides tunneled connectivity to the IPv6 Internet, such as SixXS [SIXXS], tunnelbroker.net [TUNBROKER], and gogo6 [GOGO6].
トンネルブローカー：IPv6インターネットへのトンネル接続を提供するサービス。SixXS[SIXXS]、tunnelbroker.net [TUNBROKER]、gogo6 [GOGO6]など。
Automatic tunnels (Section 3.2), configured tunnels (Section 3.1), 6over4 (Section 3.3), 6to4 (Section 3.5), the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (Section 3.7), and 6rd (Section 3.9) solve similar problems at different scales. They all encapsulate IPv6 packets immediately inside an IPv4 packet, without using additional headers. This is called "protocol 41 encapsulation" (see Section 5.1), as the Protocol field in the IPv4 header is set to 41 to indicate that what follows is an IPv6 packet.
自動トンネル（セクション3.2）、構成済みトンネル（セクション3.1）、6over4（セクション3.3）、6to4（セクション3.5）、サイト内自動トンネルアドレス指定プロトコル（ISATAP）（セクション3.7）、および6番目（セクション3.9）は同様に解決します異なるスケールでの問題。これらはすべて、追加のヘッダーを使用せずに、IPv4パケットのすぐ内側にIPv6パケットをカプセル化します。これは「プロトコル41カプセル化」と呼ばれます（セクション5.1を参照）。これは、IPv4ヘッダーのプロトコルフィールドが41に設定され、IPv6パケットが続くことを示すためです。
6to4, 6rd, ISATAP, and automatic tunneling each generate an IPv6 address or range of IPv6 addresses for the host or router running the protocol based on the system's IPv4 address in one way or another (see Section 5.4). This lets 6to4, 6rd, ISATAP, and automatic tunnels determine the IPv4 destination address in the outer IPv4 header from the IPv6 address of the destination, allowing for automatic operation without the need to administratively configure the remote tunnel endpoint.
6to4、6rd、ISATAP、および自動トンネリングはそれぞれ、何らかの方法でシステムのIPv4アドレスに基づいて、プロトコルを実行しているホストまたはルーターのIPv6アドレスまたはIPv6アドレスの範囲を生成します（セクション5.4を参照）。これにより、6to4、6rd、ISATAP、および自動トンネルは、宛先のIPv6アドレスから外部IPv4ヘッダー内のIPv4宛先アドレスを判別できるため、リモートトンネルエンドポイントを管理上構成する必要なく、自動操作が可能になります。
6over4 and ISATAP provide IPv6 connectivity between IPv6-capable systems within a single organisation's network that is otherwise IPv4 only. 6rd allows ISPs to provide IPv6 connectivity to their customers over IPv4-only last-mile infrastructures. 6to4 directly provides connectivity to the global IPv6 Internet without involving an ISP.
6over4とISATAPは、単一の組織のネットワーク内にあるIPv6対応システム間のIPv6接続を提供します。 6rdにより、ISPはIPv4のみのラストマイルインフラストラクチャを介して顧客にIPv6接続を提供できます。 6to4は、ISPを介さずにグローバルIPv6インターネットへの接続を直接提供します。
Configured tunnels (Section 3.1) also use protocol 41 encapsulation but rely on manual configuration of the remote tunnel endpoint. (The Heartbeat Protocol (Section 4.2) solves this.) Configured tunnels can be used within an organisation's network but are typically used by tunnel-broker services to provide connectivity to the IPv6 Internet. GRE (Section 3.4) is similar to configured tunnels, but also supports encapsulating protocols other than IPv6.
構成済みトンネル（セクション3.1）もプロトコル41カプセル化を使用しますが、リモートトンネルエンドポイントの手動構成に依存しています。 （ハートビートプロトコル（セクション4.2）はこれを解決します。）構成されたトンネルは組織のネットワーク内で使用できますが、通常はトンネルブローカーサービスがIPv6インターネットへの接続を提供するために使用します。 GRE（セクション3.4）は構成済みトンネルに似ていますが、IPv6以外のカプセル化プロトコルもサポートしています。
AYIYA (Section 3.6) is similar to configured tunnels and GRE but typically uses a UDP header for better compatibility with NATs and is generally used with the Tunnel Information and Control (TIC) protocol (Section 4.3) to set up the tunnel rather than rely on manual configuration. Teredo (Section 3.8), 6a44 (Section 3.10), and 6bed4 (Section 3.13) are similar to 6to4, except that they are designed to work through NATs by running over UDP. Of these, Teredo and 6bed4 assume no ISP involvement and 6a44 does; 6bed4 is designed to work over direct IPv4 paths between peers whenever possible.
AYIYA（セクション3.6）は構成済みトンネルおよびGREに似ていますが、通常はNATとの互換性を高めるためにUDPヘッダーを使用し、一般にトンネル情報と制御（TIC）プロトコル（セクション4.3）と共に使用して、トンネルに依存せずにセットアップします手動構成。 Teredo（セクション3.8）、6a44（セクション3.10）、および6bed4（セクション3.13）は、UDP経由で実行することによりNATを介して動作するように設計されていることを除いて、6to4と同様です。これらのうち、Teredoと6bed4はISPの関与を想定しておらず、6a44は想定しています。 6bed4は、可能な限り、ピア間の直接IPv4パスで機能するように設計されています。
The Locator/ID Separation Protocol (LISP) (Section 3.11) is a system for abstracting the identifying function from the location function of IP addresses; this allows for the use of IPv6 for the former and IPv4 for the latter.
ロケーター/ ID分離プロトコル（LISP）（セクション3.11）は、IPアドレスのロケーション機能から識別機能を抽象化するシステムです。これにより、前者にはIPv6を、後者にはIPv4を使用できます。
The Subnetwork Encapsulation and Adaptation Layer (SEAL) (Section 3.12) and its companion technologies (Virtual Enterprise Traversal (VET), Asymmetric Extended Route Optimization (AERO), Internet Routing Overlay Network (IRON), and Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)) provide a configured tunnel system for IPv6-in-IPv4 tunneling to default routers as well as automatic tunnel endpoint discovery for optimisation of more-specific routes.
サブネットワークカプセル化および適応層（SEAL）（セクション3.12）とその関連テクノロジ（仮想エンタープライズトラバーサル（VET）、非対称拡張ルート最適化（AERO）、インターネットルーティングオーバーレイネットワーク（IRON）、およびグローバルエンタープライズネットワークのルーティングとアドレッシング再帰（RANGER））は、デフォルトルーターへのIPv6-in-IPv4トンネリング用の構成済みトンネルシステムと、より具体的なルートの最適化のための自動トンネルエンドポイント検出を提供します。
Dual-Stack Lite [RFC6333] and MAP [MAP], both developed by the IETF Softwire working group, often come up in discussions about IPv6 tunneling. However, they are _not_ IPv6-in-IPv4 tunnel mechanisms. They are IPv4-in-IPv6 mechanisms for providing IPv4 connectivity over an IPv6 infrastructure.
IETF Softwireワーキンググループによって開発されたDual-Stack Lite [RFC6333]とMAP [MAP]は、IPv6トンネリングについての議論でよく取り上げられます。ただし、これらはIPv6-in-IPv4トンネルメカニズムではありません。これらは、IPv6インフラストラクチャ上でIPv4接続を提供するためのIPv4-in-IPv6メカニズムです。
Please refer to Section 5 for more information about issues common to many tunnel mechanisms; those issues are not discussed separately for each mechanism. The mechanisms are discussed below in roughly chronological order.
多くのトンネルメカニズムに共通する問題の詳細については、セクション5を参照してください。これらの問題は、メカニズムごとに個別に説明されていません。メカニズムについては、大まかに年代順に以下で説明します。
Configured and automatic tunnels are the two oldest tunnel mechanisms, originally published in "Transition Mechanisms for IPv6 Hosts and Routers" [RFC1933] in 1996. The latest specification of configured tunnels is "Basic Transition Mechanisms for IPv6 Hosts and Routers" [RFC4213], published in 2005. The mechanism is sometimes called "manual tunnels", "static tunnels", "protocol 41 tunnels", or "6in4".
構成済みトンネルと自動トンネルは、1996年に「IPv6ホストとルーターの移行メカニズム」[RFC1933]で最初に公開された2つの最も古いトンネルメカニズムです。構成済みトンネルの最新の仕様は、「IPv6ホストとルーターの基本的な移行メカニズム」[RFC4213]です。このメカニズムは、「手動トンネル」、「静的トンネル」、「プロトコル41トンネル」、または「6in4」と呼ばれることもあります。
Configured tunnels connect two systems in point-to-point fashion using protocol 41 encapsulation. The configuration that the name of the mechanism alludes to consists of a remote "tunnel endpoint".
設定されたトンネルは、プロトコル41カプセル化を使用して、ポイントツーポイント方式で2つのシステムを接続します。メカニズムの名前が示す構成は、リモートの「トンネルエンドポイント」で構成されています。
This is the IPv4 address of the system on the other side of the tunnel. When a system (potentially) has multiple IPv4 addresses, the local tunnel endpoint address may also need to be configured.
これは、トンネルの反対側にあるシステムのIPv4アドレスです。システムに（潜在的に）複数のIPv4アドレスがある場合、ローカルトンネルエンドポイントアドレスも構成する必要がある場合があります。
The need to explicitly set up configured tunnels makes them more difficult to deploy than automatic mechanisms. However, because there is a fixed, single remote tunnel endpoint, performance is predictable and the tunnel is easy to debug.
構成済みトンネルを明示的にセットアップする必要があるため、自動メカニズムよりも展開が困難になります。ただし、固定された単一のリモートトンネルエンドポイントがあるため、パフォーマンスは予測可能であり、トンネルのデバッグは簡単です。
In the early days, it was not unheard of for a small network to get IPv6 connectivity from another continent. This excessive path stretch makes communication over short geographic distances much less efficient because the distance travelled by packets may be larger than the geographic distance by an order of magnitude or more.
初期の頃、小規模なネットワークが別の大陸からIPv6接続を取得することは前例がありませんでした。パケットが移動する距離は地理的な距離よりも1桁以上長い場合があるため、この過度のパスストレッチにより、地理的に短い距離での通信の効率が大幅に低下します。
Configured tunnels are widely implemented. Common operating systems can terminate configured tunnels, as well as IPv6-capable routers and home gateways. The mechanism is versatile but is mostly used between isolated smaller IPv6-capable networks and the IPv6 Internet, often through a "tunnel broker" such as tunnelbroker.net [TUNBROKER], SixXS [SIXXS], or gogo6 [GOGO6].
構成されたトンネルは広く実装されています。一般的なオペレーティングシステムは、構成されたトンネルだけでなく、IPv6対応のルーターやホームゲートウェイも終端できます。このメカニズムは汎用性がありますが、ほとんどの場合、孤立した小規模なIPv6対応ネットワークとIPv6インターネットの間で、多くの場合、tunnelbroker.net [TUNBROKER]、SixXS [SIXXS]、gogo6 [GOGO6]などの「トンネルブローカー」を通じて使用されます。
[RFC4891] discusses the use of IPsec to protect the confidentiality and integrity of IPv6 traffic exchanged over configured tunnels.
[RFC4891]は、構成されたトンネルを介して交換されるIPv6トラフィックの機密性と整合性を保護するためのIPsecの使用について説明しています。
Automatic tunneling is described in [RFC2893], "Transition Mechanisms for IPv6 Hosts and Routers", but removed in [RFC4213], which is a replacement of RFC 2893. Configured tunnels (Section 3.1) are closely related to automatic tunnels and are specified in RFCs 2893 and 4213, too. Both use protocol 41 encapsulation.
自動トンネリングは[RFC2893]の「IPv6ホストとルーターの移行メカニズム」で説明されていますが、RFC 2893に代わる[RFC4213]で削除されています。構成済みトンネル（セクション3.1）は自動トンネルに密接に関連しており、 RFC 2893および4213も。どちらもプロトコル41カプセル化を使用します。
Hosts that are capable of automatic tunneling use special IPv6 addresses: IPv4-compatible addresses. An IPv4-compatible IPv6 address consists of 96 zero bits followed by the system's IPv4 address. When sending packets to destinations within the IPv4- compatible ::/96 prefix, the IPv4 destination address in the outer IPv4 header is taken from the IPv4 address in the IPv4-compatible IPv6 destination address.
自動トンネリングが可能なホストは、特別なIPv6アドレス（IPv4互換アドレス）を使用します。 IPv4互換IPv6アドレスは、システムのIPv4アドレスが後に続く96個のゼロビットで構成されます。 IPv4互換:: / 96プレフィックス内の宛先にパケットを送信する場合、外部IPv4ヘッダーのIPv4宛先アドレスは、IPv4互換IPv6宛先アドレスのIPv4アドレスから取得されます。
Automatic tunneling has a big limitation: it only allows for communication between IPv6-capable systems that both support automatic tunneling. There are no provisions for communicating with the native IPv6 Internet. As such, the mechanism is of almost no practical use and is not implemented in current operating systems, as 6to4 (Section 3.5) does what automatic tunneling was supposed to do, but it also provides connectivity to the rest of the IPv6 Internet.
自動トンネリングには大きな制限があります。自動トンネリングをサポートするIPv6対応システム間の通信のみが可能です。ネイティブIPv6インターネットと通信するための規定はありません。そのため、6to4（セクション3.5）が自動トンネリングで行われるはずの機能を実行するため、このメカニズムはほとんど実用的ではなく、現在のオペレーティングシステムには実装されていませんが、IPv6インターネットの他の部分への接続も提供します。
"Transmission of IPv6 over IPv4 Domains without Explicit Tunnels" [RFC2529] was published in 1999. The mechanism is commonly known as "6over4".
「明示的なトンネルのないIPv4ドメインを介したIPv6の転送」[RFC2529]は1999年に公開されました。このメカニズムは一般に「6over4」として知られています。
6over4 is designed to work within a single organisation's IPv4 network, where IPv6-capable hosts and routers are separated by IPv4- only routers. 6over4 treats the IPv4 network as a "virtual Ethernet" for the purpose of IPv6 communication. It uses IPv4 multicast to tunnel IPv6 multicast packets. A node's IPv4 address is included in the Interface Identifier used on the virtual 6over4 interface, allowing the exchange of protocol 41 encapsulated packets between 6over4 nodes without prior administrative configuration.
6over4は、単一組織のIPv4ネットワーク内で動作するように設計されており、IPv6対応のホストとルーターはIPv4のみのルーターによって分離されています。 6over4は、IPv6通信の目的で、IPv4ネットワークを「仮想イーサネット」として扱います。 IPv4マルチキャストを使用して、IPv6マルチキャストパケットをトンネリングします。ノードのIPv4アドレスは、仮想6over4インターフェイスで使用されるインターフェイス識別子に含まれているため、事前の管理構成なしで6over4ノード間でプロトコル41カプセル化パケットを交換できます。
Because multicast is supported, standard IPv6 Neighbour Discovery and Stateless Address Autoconfiguration [RFC4862] can be used. Although, like automatic tunnels (Section 3.2) and other mechanisms, 6over4 embeds the IPv4 address of the host in the IPv6 address, the destination IPv4 address in the outer IPv4 header is *not* derived from the IPv6 address embedded in the inner IPv6 header, but learnt through Neighbour Discovery [RFC4861]. In effect, the IPv4 addresses of the hosts are used as link-layer addresses in the same way that Media Access Control (MAC) addresses are used on Ethernet networks.
マルチキャストがサポートされているため、標準のIPv6近隣探索およびステートレスアドレス自動構成[RFC4862]を使用できます。自動トンネル（セクション3.2）やその他のメカニズムと同様に、6over4はホストのIPv4アドレスをIPv6アドレスに埋め込みますが、外部IPv4ヘッダーの宛先IPv4アドレスは、内部IPv6ヘッダーに埋め込まれたIPv6アドレスから導出されたものではありません、しかし近隣発見[RFC4861]を通して学んだ。実際には、ホストのIPv4アドレスは、メディアアクセス制御（MAC）アドレスがイーサネットネットワークで使用されるのと同じ方法でリンク層アドレスとして使用されます。
One or more routers with connectivity to the global IPv6 Internet send out Router Advertisements to provide 6over4 hosts with connectivity to the rest of the IPv6 Internet.
グローバルIPv6インターネットへの接続を備えた1つ以上のルーターがルーターアドバタイズメントを送信して、6over4ホストに残りのIPv6インターネットへの接続を提供します。
6over4 has the minimal overhead for protocol 41 encapsulation and doesn't require manual configuration. Hosts can only take advantage of 6over4 if they run the mechanism themselves. 6over4 packets can't pass through a NAT successfully, as the IPv4 address exchanged through Neighbour Discovery will be different from the one needed to reach the host in question, and because, without port numbers, protocol 41 doesn't allow for multiplexing multiple hosts using this encapsulation behind a single IPv4 address. However, 6over4 works within IPv4 domains that reside behind a NAT in their entirety and use RFC 1918 addressing.
6over4は、プロトコル41カプセル化のオーバーヘッドが最小限であり、手動で構成する必要はありません。ホストがメカニズムを自分で実行する場合にのみ、ホストは6over4を利用できます。近隣探索を通じて交換されるIPv4アドレスは、問題のホストに到達するために必要なアドレスとは異なるため、6over4パケットはNATを正常に通過できません。ポート番号がないと、プロトコル41では複数のホストを多重化できません。単一のIPv4アドレスの背後でこのカプセル化を使用します。ただし、6over4は、全体がNATの背後にあるIPv4ドメイン内で機能し、RFC 1918アドレス指定を使用します。
Because of its reliance on IPv4 multicast and because local IPv6 communication is relatively easy to facilitate using IPv6 routers, 6over4 is not supported in current operating systems. ISATAP (Section 3.7) provides very similar functionality without requiring IPv4 multicast capability and is implemented more widely.
IPv4マルチキャストへの依存と、ローカルIPv6通信はIPv6ルーターの使用を容易にするために比較的容易であるため、6over4は現在のオペレーティングシステムではサポートされていません。 ISATAP（セクション3.7）は、IPv4マルチキャスト機能を必要としない非常に類似した機能を提供し、より広く実装されています。
Generic Routing Encapsulation (GRE) [RFC2784] is a generic point-to-point tunnel mechanism that allows many other protocols to be encapsulated in IP.
Generic Routing Encapsulation（GRE）[RFC2784]は、他の多くのプロトコルをIPにカプセル化できるようにする、一般的なポイントツーポイントトンネルメカニズムです。
GRE is a simple protocol that is similar to configured tunnels (Section 3.1) when used for IPv6-in-IPv4 tunneling. The main benefit of GRE is that it can encapsulate any protocol's packets, not only IPv6 packets. The GRE header causes an extra overhead of 8 to 16 bytes depending on which options are used. GRE sets the Protocol field in the IP header to 47.
GREは、IPv6-in-IPv4トンネリングに使用する場合の構成済みトンネル（セクション3.1）に類似した単純なプロトコルです。 GREの主な利点は、IPv6パケットだけでなく、あらゆるプロトコルのパケットをカプセル化できることです。 GREヘッダーでは、使用するオプションに応じて、8〜16バイトの追加オーバーヘッドが発生します。 GREは、IPヘッダーのプロトコルフィールドを47に設定します。
The GRE header can optionally contain a checksum, a key to separate different traffic flows (for example, different tunnels) between the same endpoints, and a sequence number that can be used to prevent packets from being processed out of order.
GREヘッダーには、オプションでチェックサム、同じエンドポイント間の異なるトラフィックフロー（異なるトンネルなど）を分離するためのキー、シーケンス番号が含まれ、パケットが順序どおりに処理されないようにすることができます。
GRE is implemented in many routers but not in most consumer-level home gateways or desktop operating systems.
GREは多くのルーターに実装されていますが、ほとんどの消費者レベルのホームゲートウェイやデスクトップオペレーティングシステムには実装されていません。
6to4 is specified in "Connection of IPv6 Domains via IPv4 Clouds" [RFC3056]. It creates a block of IPv6 addresses from a locally configured IPv4 address by concatenating that IPv4 address to the prefix 2002::/16, resulting in a /48 IPv6 prefix. Addresses in 2002::/16 are considered reachable through the tunnel interface, so the 6to4 network functions as a Non-Broadcast Multi-Access (NBMA) network through which 6to4 users can communicate. IPv6 packets are encapsulated by adding an IPv4 header with the Protocol field set to 41.
6to4は、「IPv4クラウドを介したIPv6ドメインの接続」[RFC3056]で指定されています。 IPv4アドレスをプレフィックス2002 :: / 16に連結することにより、ローカルに構成されたIPv4アドレスからIPv6アドレスのブロックを作成し、/ 48 IPv6プレフィックスを生成します。 2002 :: / 16のアドレスはトンネルインターフェイスを介して到達可能と見なされるため、6to4ネットワークは、6to4ユーザーが通信できる非ブロードキャストマルチアクセス（NBMA）ネットワークとして機能します。 IPv6パケットは、プロトコルフィールドが41に設定されたIPv4ヘッダーを追加することによってカプセル化されます。
The /48 prefix allows a single system running 6to4 to act as a gateway or router for a large number of IPv6 hosts. Alternatively, an individual host may run 6to4 and not act as a gateway or router. The system running 6to4 must have a globally reachable IPv4 address. Using 6to4 with a private IPv4 address [RFC1918] is not possible.
/ 48プレフィックスを使用すると、6to4を実行している単一のシステムを多数のIPv6ホストのゲートウェイまたはルーターとして機能させることができます。または、個々のホストが6to4を実行し、ゲートウェイまたはルーターとして機能しない場合もあります。 6to4を実行しているシステムには、グローバルに到達可能なIPv4アドレスが必要です。プライベートIPv4アドレス[RFC1918]で6to4を使用することはできません。
"An Anycast Prefix for 6to4 Relay Routers" [RFC3068] specifies an anycast mechanism for 6to4 relays that provide connectivity between the 6to4 network and the regular IPv6 Internet. All public relays share the IPv4 address 192.88.99.1, which corresponds to 2002:c058: 6301::. Relays advertise reachability towards 2002::/16 to the native IPv6 Internet, so packets addressed to systems using 6to4 addresses are routed to the closest gateway. The gateway encapsulates these packets and forwards them to the IPv4 address included in the IPv6 address. Systems running 6to4 have a default route pointing to 2002:c058:6301::, so they tunnel packets addressed to non-6to4 IPv6 destinations to the closest relay, which decapsulates the packet and forwards them as IPv6 packets.
「6to4リレールーターのエニーキャストプレフィックス」[RFC3068]は、6to4ネットワークと通常のIPv6インターネット間の接続を提供する6to4リレーのエニーキャストメカニズムを指定します。すべてのパブリックリレーはIPv4アドレス192.88.99.1を共有します。これは2002：c058：6301 ::に対応します。リレーは2002 :: / 16への到達可能性をネイティブIPv6インターネットにアドバタイズするため、6to4アドレスを使用するシステム宛てのパケットは最も近いゲートウェイにルーティングされます。ゲートウェイはこれらのパケットをカプセル化し、IPv6アドレスに含まれるIPv4アドレスに転送します。 6to4を実行しているシステムには2002：c058：6301 ::を指すデフォルトルートがあるため、6to4以外のIPv6宛先にアドレス指定されたパケットを最も近いリレーにトンネリングし、パケットをカプセル化解除してIPv6パケットとして転送します。
The 6to4 protocol adds minimal overhead for protocol 41 encapsulation and requires no manual configuration from users. The biggest problem specific to 6to4 is that it is unpredictable which 6to4 anycast relay is used. These relays are often provided by third parties on a best-effort basis. In practice, this has caused unpredictable performance. Traffic from the 6to4 network to the regular IPv6 Internet will likely use a different 6to4 relay than the traffic in the opposite direction. If either of those relays is not reliable, then the communication between those networks is affected. Especially the lack of control over the relay used for return traffic is considered to be a problem with 6to4.
6to4プロトコルは、プロトコル41カプセル化のオーバーヘッドを最小限に抑え、ユーザーが手動で構成する必要はありません。 6to4に固有の最大の問題は、どの6to4エニーキャストリレーが使用されるか予測できないことです。これらのリレーは、多くの場合、サードパーティによってベストエフォートで提供されます。実際には、これは予測できないパフォーマンスを引き起こしています。 6to4ネットワークから通常のIPv6インターネットへのトラフィックは、反対方向のトラフィックとは異なる6to4リレーを使用する可能性があります。これらのリレーのいずれかが信頼できない場合、それらのネットワーク間の通信が影響を受けます。特に、戻りトラフィックに使用されるリレーを制御できないことは、6to4の問題と考えられています。
To avoid problems with 6to4, the IPv6 Default Address Selection algorithm [RFC6724] gives IPv4 addresses a higher preference than 6to4 addresses. When making a connection, a system will prefer native IPv6 over IPv4, and IPv4 over 6to4 IPv6. This causes 6to4 to be used only when a destination is not reachable over IPv4 and no other IPv6 connectivity is available.
6to4の問題を回避するために、IPv6デフォルトアドレス選択アルゴリズム[RFC6724]は、IPv4アドレスを6to4アドレスよりも優先します。接続を行う場合、システムはIPv4よりもネイティブIPv6を、6to4 IPv6よりもIPv4を優先します。これにより、宛先がIPv4経由で到達できず、他のIPv6接続が利用できない場合にのみ、6to4が使用されます。
For more information about 6to4, see "Advisory Guidelines for 6to4 Deployment" [RFC6343].
6to4の詳細については、「6to4配置に関する勧告ガイドライン」[RFC6343]を参照してください。
*Warning*:
*警告*：
Although many, if not all, 6to4 implementations disable the mechanism when the system only has an RFC 1918 address, recently a block of IPv4 addresses has been set aside for use in service-provider-operated Network Address Translators, also known as Carrier-Grade NATs (CGNs). [RFC6598] sets aside the block 100.64.0.0/10 for the use between CGNs and subscriber devices. As 100.64.0.0/10 is not an RFC 1918 address block, systems implementing 6to4 may fail to disable the mechanism, but due to the shared nature of the 100.64.0.0/10 prefix, 6to4 cannot work using these addresses. The same issue is present if an ISP decides to use regular global unicast IPv4 address space behind a CGN.
すべてではないにしても、多くの6to4実装は、システムにRFC 1918アドレスしかない場合にこのメカニズムを無効にしますが、最近、キャリアグレードとも呼ばれる、サービスプロバイダーが運営するネットワークアドレストランスレーターで使用するためにIPv4アドレスのブロックが確保されましたNAT（CGN）。 [RFC6598]は、CGNと加入者デバイス間の使用のためにブロック100.64.0.0/10を確保します。 100.64.0.0/10はRFC 1918アドレスブロックではないため、6to4を実装するシステムはメカニズムの無効化に失敗する可能性がありますが、100.64.0.0 / 10プレフィックスの共有の性質により、6to4はこれらのアドレスを使用して機能できません。同じ問題は、ISPがCGNの背後にある通常のグローバルユニキャストIPv4アドレス空間を使用することを決定した場合にも存在します。
[RFC6732] describes "6to4 provider managed tunnels", which are a way to make 6to4 work behind a CGN. This is accomplished by running a 6to4 gateway at the 6to4 gateway anycast address, and then translating the IPv6 addresses used by 6to4 users behind the CGN to IPv6 addresses from the ISP's range. Unlike IPv4 NAT, where multiple internal hosts share a single public IPv4 address, prefix translation maps entire prefixes, so each host has its own public IPv6 address and can receive incoming packets as usual.
[RFC6732]は、「6to4プロバイダーが管理するトンネル」について説明しています。これは、6to4をCGNの背後で動作させる方法です。これは、6to4ゲートウェイのエニーキャストアドレスで6to4ゲートウェイを実行し、CGNの背後にある6to4ユーザーが使用するIPv6アドレスをISPの範囲のIPv6アドレスに変換することで実現されます。複数の内部ホストが単一のパブリックIPv4アドレスを共有するIPv4 NATとは異なり、プレフィックス変換はプレフィックス全体をマッピングするため、各ホストは独自のパブリックIPv6アドレスを持ち、通常どおり着信パケットを受信できます。
However, if IPv6 applications are not aware that translation is happening (and they have no reason to expect that it is), they may not use their externally visible address in referrals, so applications that use referrals are likely to fail. Additionally, the translation is only specified for packets that flow through the 6to4 gateway, not for packets sent directly to other 6to4 users. So, communication with other 6to4 users is not possible. As such, the use of 6to4 provider managed tunnels is discouraged except as a very last resort.
ただし、IPv6アプリケーションが変換が行われていることを認識していない場合（そうであると予期する理由がない場合）、外部から見えるアドレスを参照に使用しない可能性があるため、参照を使用するアプリケーションは失敗する可能性があります。さらに、変換は6to4ゲートウェイを通過するパケットに対してのみ指定され、他の6to4ユーザーに直接送信されるパケットには指定されません。したがって、他の6to4ユーザーとの通信はできません。そのため、最後の手段として使用する場合を除いて、6to4プロバイダーが管理するトンネルの使用はお勧めしません。
AYIYA [AYIYA] is designed for use by the SixXS [SIXXS] tunnel-broker service. For more information, see the specification [MASSAR].
AYIYA [AYIYA]は、SixXS [SIXXS]トンネルブローカーサービスで使用するために設計されています。詳細については、仕様[MASSAR]を参照してください。
The AYIYA protocol defines a method for encapsulating any protocol in any other protocol. The most common way of deploying AYIYA is to use the following sequence of headers: IPv4-UDP-AYIYA-IPv6, although other combinations like IPv4-AYIYA-IPv6 or IPv6-SCTP-AYIYA-IPv4 are also possible. That document does not limit the contents nor the protocol that carries the AYIYA packets. In this document, we only look at the most common usage (IPv4-UDP-AYIYA-IPv6) that is deployed on the SixXS tunnel brokers to provide IPv6 access to clients behind NAT devices.
AYIYAプロトコルは、他のプロトコルにプロトコルをカプセル化する方法を定義します。 AYIYAをデプロイする最も一般的な方法は、ヘッダーの次のシーケンスを使用することです：IPv4-UDP-AYIYA-IPv6。ただし、IPv4-AYIYA-IPv6またはIPv6-SCTP-AYIYA-IPv4などの他の組み合わせも可能です。そのドキュメントは、AYIYAパケットを運ぶコンテンツやプロトコルを制限しません。このドキュメントでは、SixXSトンネルブローカーに展開されてNATデバイスの背後にあるクライアントにIPv6アクセスを提供する最も一般的な使用法（IPv4-UDP-AYIYA-IPv6）のみを取り上げます。
AYIYA specifies the encapsulation, identification, checksum, security, and certain management operations that can be used once the tunnel is established. It does not specify how the tunnel configuration parameters can be negotiated. Typically, the TIC protocol described in Section 4.3 is used for that part of the tunnel setup, although the Tunnel Setup Protocol (TSP) (Section 4.1) could just as well be used.
AYIYAは、トンネルの確立後に使用できるカプセル化、識別、チェックサム、セキュリティ、および特定の管理操作を指定します。トンネル構成パラメーターのネゴシエート方法は指定されていません。通常、セクション4.3で説明されているTICプロトコルがトンネルセットアップのその部分に使用されますが、トンネルセットアッププロトコル（TSP）（セクション4.1）も使用できます。
AYIYA provides a point-to-point tunnel, over which the endpoints can route traffic for any source and destination. When using SHA-1 hashing for authentication, as is common when using the Automatic IPv6 Connectivity Client Utility (AICCU) client with a SixXS tunnel server, the total packet overhead is 72 bytes (20 for the IPv4 header, 8 for UDP, and 44 for AYIYA).
AYIYAは、ポイントツーポイントトンネルを提供します。このトンネルを経由して、エンドポイントは任意の送信元と宛先のトラフィックをルーティングできます。認証にSHA-1ハッシュを使用する場合、SixXSトンネルサーバーで自動IPv6接続クライアントユーティリティ（AICCU）クライアントを使用する場合と同様に、パケットオーバーヘッドの合計は72バイトです（IPv4ヘッダーに20、UDPに8、44 AYIYA）。
AYIYA provides operational commands for querying the hostname, address, contact information, software version, and last error message. An operational command to ask the other side of the tunnel to shut down is also available. These commands in the protocol can make debugging of AYIYA tunnels easier if the tools support them.
AYIYAは、ホスト名、アドレス、連絡先情報、ソフトウェアバージョン、および最新のエラーメッセージを照会するための操作コマンドを提供します。トンネルの反対側にシャットダウンを要求する操作コマンドも使用できます。プロトコルのこれらのコマンドは、ツールがサポートしている場合、AYIYAトンネルのデバッグを容易にすることができます。
The main advantage of AYIYA is that it can provide a stable tunnel through an IPv4 NAT. The UDP port numbers allow multiple AYIYA users to share a single IPv4 address behind a NAT.
AYIYAの主な利点は、IPv4 NATを介して安定したトンネルを提供できることです。 UDPポート番号により、複数のAYIYAユーザーがNATの背後で単一のIPv4アドレスを共有できます。
The client will contact the tunnel server at regular intervals, and the tunnel server will automatically adapt to changing IPv4 addresses and/or UDP port numbers. To prevent a third party from injecting rogue packets into the tunnel, the client can optionally be authenticated by using the identity and signature fields. A timestamp is included in the AYIYA header to guard against replay attacks.
クライアントは定期的にトンネルサーバーに接続し、トンネルサーバーはIPv4アドレスやUDPポート番号の変更に自動的に適応します。第三者が不正なパケットをトンネルに注入するのを防ぐために、クライアントはオプションでIDおよび署名フィールドを使用して認証できます。タイムスタンプはAYIYAヘッダーに含まれており、リプレイ攻撃から保護します。
There is currently a single implementation of this protocol: the AICCU [AICCU] client software used with the SixXS [SIXXS] tunnel-broker service.
現在、このプロトコルの単一の実装があります。SixXS[SIXXS]トンネルブローカーサービスで使用されるAICCU [AICCU]クライアントソフトウェアです。
ISATAP [RFC5214] uses protocol 41 encapsulation to provide connectivity between isolated IPv6-capable nodes within an organisation's internal network. It is similar to 6over4 (Section 3.3), but without the requirement that the IPv4 network supports multicast; unlike 6over4, ISATAP uses a Non-Broadcast Multi-Access (NBMA) communication model and thus doesn't support multicasts. The mechanism assigns IPv6 addresses whose Interface Identifier is solely defined by a node's IPv4 address, which is assumed to be unique.
ISATAP [RFC5214]はプロトコル41カプセル化を使用して、組織の内部ネットワーク内の分離されたIPv6対応ノード間の接続を提供します。これは6over4（セクション3.3）に似ていますが、IPv4ネットワークがマルチキャストをサポートする必要はありません。 6over4とは異なり、ISATAPはNon-Broadcast Multi-Access（NBMA）通信モデルを使用しているため、マルチキャストをサポートしていません。このメカニズムは、一意であると想定されるノードのIPv4アドレスによってのみインターフェイス識別子が定義されるIPv6アドレスを割り当てます。
In order to obtain a /64 prefix, an ISATAP host needs to send a unicast Router Solicitation to receive a unicast Router Advertisement from an ISATAP router. Without the ability to send and receive IPv6 multicasts, an ISATAP host must be configured with a Potential Router List through an all-IPv4 mechanism, such as manual setup, DHCP, or the DNS. Site administrators are encouraged to use a DNS Fully Qualified Domain Name using the convention "isatap.domainname" (e.g., isatap.example.com). Hosts will accept packets with IPv4 sender addresses that are either on the Potential Router List or embedded in the IPv6 sender address.
/ 64プレフィックスを取得するには、ISATAPホストがユニキャストルーター要請を送信して、ISATAPルーターからユニキャストルーターアドバタイズを受信する必要があります。 IPv6マルチキャストを送受信する機能がない場合、ISATAPホストは、手動セットアップ、DHCP、DNSなどのすべてのIPv4メカニズムを通じて、潜在的なルーターリストを使用して構成する必要があります。サイト管理者は、「isatap.domainname」という規則（isatap.example.comなど）を使用してDNS完全修飾ドメイン名を使用することをお勧めします。ホストは、潜在的ルーターリストにあるか、IPv6送信者アドレスに埋め込まれているIPv4送信者アドレスを持つパケットを受け入れます。
The router's prefix and the IPv4 address together define the IPv6 address for the ISATAP interface. This means that precisely one ISATAP address is available for each IPv4 address. As such, each host needs to run ISATAP itself in order to enjoy ISATAP IPv6 connectivity. The IPv4 address in the destination IPv6 address is used to bootstrap Neighbour Discovery.
ルーターのプレフィックスとIPv4アドレスを組み合わせて、ISATAPインターフェイスのIPv6アドレスを定義します。つまり、IPv4アドレスごとに1つのISATAPアドレスを使用できます。そのため、ISATAP IPv6接続を楽しむために、各ホストはISATAP自体を実行する必要があります。宛先IPv6アドレスのIPv4アドレスは、近隣探索をブートストラップするために使用されます。
[RFC5214] doesn't explicitly address the use of ISATAP using private RFC 1918 addresses. Despite that, the mechanism seems compatible with private addresses. NAT, however, breaks the relationship between the IPv4 address embedded in the IPv6 address and would therefore make communication between ISATAP hosts impossible. Any device that can communicate with the ISATAP hosts over IPv4 using protocol 41 can participate in the IPv6 subnet.
[RFC5214]は、プライベートRFC 1918アドレスを使用してISATAPの使用に明示的に対処していません。それにもかかわらず、このメカニズムはプライベートアドレスと互換性があるようです。ただし、NATはIPv6アドレスに埋め込まれたIPv4アドレス間の関係を破壊するため、ISATAPホスト間の通信が不可能になります。プロトコル41を使用してIPv4を介してISATAPホストと通信できるすべてのデバイスは、IPv6サブネットに参加できます。
ISATAP is available in Windows, Linux, and Cisco IOS.
ISATAPは、Windows、Linux、およびCisco IOSで使用できます。
Teredo is specified in [RFC4380] and a few updates; it is designed as an automatic tunnel mechanism of last resort. It can configure an IPv6 address behind most NAT devices, but not all. Because Teredo uses encapsulation in UDP, multiple Teredo clients can be simultaneously active behind the same NAT. For each Teredo client, a single IPv6 address is then created at the expense of a single external UDP port.
Teredoは[RFC4380]といくつかの更新で指定されています。それは最後の手段の自動トンネルメカニズムとして設計されています。ほとんどのNATデバイスの背後でIPv6アドレスを構成できますが、すべてではありません。 TeredoはUDPでカプセル化を使用するため、複数のTeredoクライアントを同じNATの背後で同時にアクティブにすることができます。 Teredoクライアントごとに、単一の外部UDPポートを犠牲にして単一のIPv6アドレスが作成されます。
The operation of Teredo is based on a classification of NAT [RFC3489] as established during an interaction with a Teredo server. This classification has since been obsoleted (by [RFC5389]) because it assigns more properties to NAT than achieved in reality.
Teredoの操作は、Teredoサーバーとの対話中に確立されたNAT [RFC3489]の分類に基づいています。この分類は（[RFC5389]によって）廃止されました。これは、実際に達成されるよりも多くのプロパティをNATに割り当てるためです。
Teredo is present in Windows XP and later and is enabled by default in Windows Vista and later. However, if IPv6 connectivity is only possible through Teredo, then Windows will not look up AAAA records when resolving domain names. This means that Teredo is only used to connect to explicit IPv6 addresses obtained through another mechanism than DNS. An open-source implementation named Miredo exists for other platforms.
TeredoはWindows XP以降にあり、Windows Vista以降ではデフォルトで有効になっています。ただし、IPv6接続がTeredo経由でのみ可能である場合、Windowsはドメイン名を解決するときにAAAAレコードを検索しません。つまり、Teredoは、DNS以外のメカニズムを通じて取得された明示的なIPv6アドレスへの接続にのみ使用されます。他のプラットフォーム用に、Miredoという名前のオープンソース実装が存在します。
The performance of Teredo falls noticeably short of that of IPv4. The setup time of a connection involves finding a Teredo relay nearby the native address to encapsulate and decapsulate traffic, and finding this relay can take in the order of seconds. This process is not sufficiently reliable; Teredo fails in about 37% [TERTST] of its attempts to connect to native IPv6 destinations. The roundtrip time of traffic can add tenths of a second, and jitter generally worsens if it is dependent on a public relay.
Teredoのパフォーマンスは、IPv4のパフォーマンスを著しく下回っています。接続のセットアップ時間には、ネイティブアドレスの近くにあるTeredoリレーを見つけてトラフィックをカプセル化およびカプセル化解除し、このリレーを見つけるのに数秒かかる場合があります。このプロセスは十分に信頼できません。 Teredoは、ネイティブIPv6宛先への接続試行の約37％[TERTST]で失敗します。トラフィックの往復時間は10分の1秒を追加する可能性があり、パブリックリレーに依存している場合、ジッターは一般に悪化します。
Teredo clients need to be configured with a Teredo server when setting up their local IPv6 address and when initiating a connection to a native IPv6 destination. The hostnames of the Teredo servers are usually preconfigured by the vendor of the Teredo implementation. All Microsoft Windows implementations use Teredo servers provided by Microsoft by default.
Teredoクライアントは、ローカルIPv6アドレスを設定するとき、およびネイティブIPv6宛先への接続を開始するときに、Teredoサーバーで構成する必要があります。 Teredoサーバーのホスト名は通常、Teredo実装のベンダーによって事前構成されています。すべてのMicrosoft Windows実装は、デフォルトでMicrosoftが提供するTeredoサーバーを使用します。
6rd [RFC5969] is used by service providers to connect customer networks behind a CPE (Customer Premises Equipment) to the IPv6 Internet.
6rd [RFC5969]は、サービスプロバイダーがCPE（Customer Premises Equipment）の背後にある顧客ネットワークをIPv6インターネットに接続するために使用されます。
The structure of the 6rd protocol is based on 6to4, and it has the same minimal overhead as all protocols that use protocol 41 encapsulation. The main differences between 6rd and 6to4 are that 6rd is meant to be used inside a service provider's network and does not use a special IPv6 prefix but one or more prefixes routed to the service provider. As such, 6rd users aren't immediately recognisable by their IPv6 address the way 6to4 users are. Where 6to4 uses relays based on global anycast routing, 6rd uses relays provided and maintained by the service provider. Because of this architecture, the tunnel does not traverse unknown networks; this makes any debugging much easier.
6番目のプロトコルの構造は6to4に基づいており、プロトコル41カプセル化を使用するすべてのプロトコルと同じ最小限のオーバーヘッドがあります。 6rdと6to4の主な違いは、6rdはサービスプロバイダーのネットワーク内で使用されることを意図しており、特別なIPv6プレフィックスではなく、サービスプロバイダーにルーティングされる1つ以上のプレフィックスを使用することです。そのため、6to4ユーザーのように、6番目のユーザーはIPv6アドレスですぐに認識されません。 6to4がグローバルエニーキャストルーティングに基づくリレーを使用する場合、6rdはサービスプロバイダーによって提供および維持されるリレーを使用します。このアーキテクチャのため、トンネルは未知のネットワークを通過しません。これにより、デバッグがはるかに簡単になります。
6rd is completely stateless once it is configured. The tunnel endpoints can therefore be deployed using anycast. This is commonly done for the 6rd border relays deployed by the service provider to provide redundancy.
一度設定すると、6rdは完全にステートレスになります。したがって、トンネルエンドポイントはエニーキャストを使用して展開できます。これは通常、冗長性を提供するためにサービスプロバイダーによって展開された6番目のボーダーリレーに対して行われます。
Because of the different prefix, the device used as the 6rd client cannot use the hard-coded IPv6 prefix calculation and relay addresses of 6to4. Instead, the 6rd client needs to receive configuration information to work. In principle, 6rd nodes may be configured in a variety of ways, the most common one being through DHCP. If the client receives its IPv4 address from a DHCPv4 server, then the 6rd configuration can be included in the DHCP message exchange using the 6rd DHCPv4 Option defined in [RFC5969]. Manual configuration of 6rd options and configuration using [TR-069] is also possible.
プレフィックスが異なるため、6番目のクライアントとして使用されるデバイスは、ハードコーディングされたIPv6プレフィックス計算と6to4のリレーアドレスを使用できません。代わりに、6番目のクライアントが機能するには、構成情報を受信する必要があります。原則として、6番目のノードはさまざまな方法で構成できますが、最も一般的なものはDHCPを介したものです。クライアントがDHCPv4サーバーからIPv4アドレスを受信する場合、[RFC5969]で定義されている6rd DHCPv4オプションを使用して、6番目の構成をDHCPメッセージ交換に含めることができます。 6番目のオプションの手動構成と[TR-069]を使用した構成も可能です。
The main advantage of using 6rd is that it allows service providers to deploy IPv6 on last-mile access networks that for some reason cannot provide native IPv6 connectivity. It does not share the lack of predictable routing that 6to4 suffers from because all routing, encapsulation, and decapsulation are done by the service provider.
6rdを使用する主な利点は、サービスプロバイダーが何らかの理由でネイティブIPv6接続を提供できないラストマイルアクセスネットワークにIPv6を展開できることです。すべてのルーティング、カプセル化、およびカプセル化解除はサービスプロバイダーによって行われるため、6to4が被る予測可能なルーティングの欠如は共有されません。
6rd is intended to be a service managed by an ISP or enterprise IT department that must explicitly make 6rd available for clients to be able to use it.
6rdは、ISPまたはエンタープライズIT部門が管理するサービスであり、クライアントが6rdを使用できるように明示的に使用可能にする必要があります。
Inspired by Teredo, the 6a44 tunnel is described in "Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)" [RFC6751]. Its purpose is to enable Internet Service Providers to establish IPv6 connectivity for their customers, in spite of the use of a CPE or home gateway that is not prepared for IPv6. The infrastructure required for this is a 6a44 relay in the ISP's network and a 6a44 client in the customer's internal network.
Teredoに触発された6a44トンネルは、「IPv4-to-IPv4 NAT顧客宅内機器（6a44）の背後にあるネイティブIPv6」[RFC6751]で説明されています。その目的は、IPv6に対応していないCPEまたはホームゲートウェイを使用しているにもかかわらず、インターネットサービスプロバイダーが顧客のIPv6接続を確立できるようにすることです。これに必要なインフラストラクチャは、ISPのネットワーク内の6a44リレーと顧客の内部ネットワーク内の6a44クライアントです。
6a44 was explicitly designed to overcome the noted problems with Teredo. Where Teredo was designed as a global solution without dependency on ISP cooperation, the 6a44 tunnel explicitly assumes ISP cooperation. Instead of using Teredo's well-known prefix, a /48 prefix out of the ISP's address space is used. A well-known (anycast) IPv4 address has been assigned for the 6a44 relay to be run inside the ISP network without client configuration. This well-known address is allocated from the same IPv4 /24 as 6to4.
6a44は、Teredoで指摘された問題を克服するために明示的に設計されました。 TeredoがISPの協力に依存しないグローバルソリューションとして設計された場合、6a44トンネルは明示的にISPの協力を前提としています。 Teredoの既知のプレフィックスを使用する代わりに、ISPのアドレス空間からの/ 48プレフィックスが使用されます。クライアント構成なしでISPネットワーク内で実行される6a44リレーに、よく知られている（エニーキャスト）IPv4アドレスが割り当てられています。この既知のアドレスは、6to4と同じIPv4 / 24から割り当てられます。
As part of its bootstrapping, a 6a44 client requests an address from the 6a44 relay, and a regular keepalive sent by the 6a44 client to the 6a44 relay keeps mapping state in NATs and firewalls on the path alive. Traffic passed from the native IPv6 Internet to 6a44 is encapsulated in UDP and IPv4 by the relay and decapsulated by the 6a44 client; the opposite is done in the other direction.
ブートストラップの一部として、6a44クライアントは6a44リレーにアドレスを要求し、6a44クライアントから6a44リレーに送信される通常のキープアライブは、NATのマッピング状態とパス上のファイアウォールを有効に保ちます。ネイティブIPv6インターネットから6a44に渡されるトラフィックは、リレーによってUDPおよびIPv4にカプセル化され、6a44クライアントによってカプセル化解除されます。反対は反対方向に行われます。
The Locator/ID Separation Protocol (LISP) [RFC6830] is a protocol to separate the identity of systems from their location on the Internet and/or internal network. The addresses of the systems are called Endpoint Identifiers (EIDs), and the addresses of the gateways are called Routing Locators (RLOCs). It is possible to use IPv6 EIDs with IPv4 RLOCs and thereby use LISP for tunneling IPv6 over IPv4.
Locator / ID Separation Protocol（LISP）[RFC6830]は、インターネットや内部ネットワーク上の場所からシステムのIDを分離するためのプロトコルです。システムのアドレスはエンドポイント識別子（EID）と呼ばれ、ゲートウェイのアドレスはルーティングロケーター（RLOC）と呼ばれます。 IPv4 RLOCでIPv6 EIDを使用して、IPv4を介したIPv6のトンネリングにLISPを使用することが可能です。
LISP defines its own packet formats for encapsulation of data packets and for control messages. All such packets are then encapsulated in UDP. Data packets use port 4341, and control packets use port 4342.
LISPは、データパケットのカプセル化と制御メッセージ用に独自のパケット形式を定義しています。そのようなパケットはすべて、UDPでカプセル化されます。データパケットはポート4341を使用し、制御パケットはポート4342を使用します。
The LISP specification consists of several RFCs. The relevant ones for IPv6-in-IPv4 tunneling are the base specification [RFC6830], "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites" [RFC6832], and "Locator/ID Separation Protocol (LISP) Map-Server Interface" [RFC6833].
LISP仕様は、いくつかのRFCで構成されています。 IPv6-in-IPv4トンネリングに関連するものは、基本仕様[RFC6830]、「ロケーター/ ID分離プロトコル（LISP）と非LISPサイト間のインターワーキング」[RFC6832]、および「ロケーター/ ID分離プロトコル（LISP）マップです。 -Server Interface」[RFC6833]。
+----+ +----+
| MS | | MR |
+----+ +----+ +-----+ /-----------\
| | /---| xTR |---| LISP site |
+------+ /------------\---/ +-----+ \-----------/
| PxTR |---| IP network |
+------+ \------------/---\ +-----+ /-----------\
| \---| xTR |---| LISP site |
/---------------\ +-----+ \-----------/
| Non-LISP site |
\---------------/
An Example of a LISP Deployment
LISP配置の例
LISP introduces new terminology and new concepts. The relevant ones for this document are:
LISPは新しい用語と新しい概念を導入しています。このドキュメントに関連するものは次のとおりです。
ITR: Ingress Tunnel Router, a router encapsulating data packets at the border of a LISP site
ITR：入力トンネルルーター、LISPサイトの境界でデータパケットをカプセル化するルーター
ETR: Egress Tunnel Router, a router decapsulating data packets at the border of a LISP site
ETR：出力トンネルルーター、LISPサイトの境界でデータパケットのカプセル化を解除するルーター
xTR: A router performing both the ITR and the ETR functions
xTR：ITR機能とETR機能の両方を実行するルーター
PITR: Proxy ITR, a router accepting traffic from non-LISP sites, encapsulating it, and tunneling it to the LISP sites
PITR：プロキシITR、非LISPサイトからのトラフィックを受け入れ、それをカプセル化し、LISPサイトにトンネリングするルーター
PETR: Proxy ETR, a router accepting traffic from LISP sites to send it to non-LISP sites
PETR：プロキシETR、LISPサイトからのトラフィックを受け入れて非LISPサイトに送信するルーター
PxTR: A router performing both the PITR and the PETR functions
PxTR：PITR機能とPETR機能の両方を実行するルーター
MS: Map Server, a server accepting RLOC registrations from ETRs
MS：Map Server、ETRからのRLOC登録を受け入れるサーバー
MR: Map Resolver, a server that can resolve queries for RLOCs from ITRs
MR：Map Resolver、ITRからのRLOCのクエリを解決できるサーバー
LISP ETRs register the EID prefixes for which they can handle traffic with one or more Map Servers. ITRs and PITRs can then query Map Resolvers to determine which RLOCs to use when sending traffic to a LISP site. PITRs advertise aggregates of EID prefixes to the global routing table and provide tunneling services for them so that non-LISP sites can reach LISP sites. PETRs provide a way for LISP sites to send traffic to non-LISP sites.
LISP ETRは、1つ以上のマップサーバーでトラフィックを処理できるEIDプレフィックスを登録します。 ITRおよびPITRはマップリゾルバーにクエリを送信して、LISPサイトにトラフィックを送信するときに使用するRLOCを決定できます。 PITRは、EIDプレフィックスの集約をグローバルルーティングテーブルにアドバタイズし、それらにトンネリングサービスを提供して、非LISPサイトがLISPサイトに到達できるようにします。 PETRは、LISPサイトが非LISPサイトにトラフィックを送信する方法を提供します。
LISP is a complex protocol if only used for tunneling. Features of LISP are that ETRs can advertise their own RLOC addresses, that one site can have multiple xTRs with independent RLOCs, and that the LISP site administrator can specify priorities and weights for those RLOCs. This provides redundancy and explicit load balancing between RLOCs. It also allows for automatic tunneling between different sites without using a PxTR if both sites use Map Servers and Map Resolvers that are interconnected, for example, by participating in the LISP Beta Network [LISPBETA]. To facilitate these interconnections, the LISP Delegated Database Tree (DDT) system is available.
LISPは、トンネリングにのみ使用される場合、複雑なプロトコルです。 LISPの機能は、ETRが独自のRLOCアドレスをアドバタイズできること、1つのサイトが独立したRLOCを持つ複数のxTRを持つことができること、およびLISPサイト管理者がそれらのRLOCの優先度と重みを指定できることです。これにより、RLOC間の冗長性と明示的なロードバランシングが提供されます。また、LISPベータネットワーク[LISPBETA]に参加するなどして相互接続されているマップサーバーとマップリゾルバーを両方のサイトが使用している場合、PxTRを使用せずに異なるサイト間の自動トンネリングも可能です。これらの相互接続を容易にするために、LISP委任データベースツリー（DDT）システムが利用可能です。
LISP is implemented on most Cisco devices. There are implementations available for FreeBSD and Linux, as well as a platform-independent implementation in the Python programming language. Note that for LISP to work, a mapping service not unlike the DNS must be in place.
LISPはほとんどのシスコデバイスに実装されています。 FreeBSDとLinuxで利用できる実装と、Pythonプログラミング言語でのプラットフォームに依存しない実装があります。 LISPが機能するには、DNSと同様のマッピングサービスが配置されている必要があります。
The Subnetwork Encapsulation and Adaptation Layer (SEAL) [SEAL] (along with its companion technologies cited therein) provides a hybrid configured/automatic tunneling system. SEAL itself provides a mid-layer of encapsulation between the inner IPv6 header and the outer IPv4 header, i.e., as IPv4-SEAL-IPv6. SEAL can also be used in conjunction with an outer UDP encapsulation header, e.g., if NAT traversal is necessary.
サブネットワークカプセル化および適応層（SEAL）[SEAL]（そこに引用されているそのコンパニオンテクノロジーとともに）は、ハイブリッド構成/自動トンネリングシステムを提供します。 SEAL自体は、内部IPv6ヘッダーと外部IPv4ヘッダーの間にカプセル化の中間層を提供します。つまり、IPv4-SEAL-IPv6として提供されます。また、NATトラバーサルが必要な場合など、SEALを外部UDPカプセル化ヘッダーと組み合わせて使用することもできます。
The SEAL tunnel endpoint creates bidirectional configured tunnels to reach default IPv6 routers, and it discovers unidirectional automatic tunnels. SEAL tunnels can be configured over multiple underlying IPv4 links whether the addresses are provisioned from public or private IPv4 addressing domains. In that case, multihoming and traffic engineering are naturally supported.
SEALトンネルエンドポイントは、デフォルトのIPv6ルーターに到達するための双方向構成トンネルを作成し、単方向自動トンネルを検出します。 SEALトンネルは、アドレスがパブリックまたはプライベートIPv4アドレス指定ドメインからプロビジョニングされているかどうかに関係なく、複数の基盤となるIPv4リンク上に構成できます。その場合、マルチホーミングとトラフィックエンジニアリングは自然にサポートされます。
SEAL provides an optional 32-bit identifier and variable-length Integrity Check Vector that can be used for packet identification, message origin authentication, anti-replay, and a mid-layer segmentation and reassembly capability. SEAL also provides a SEAL Control Message Protocol (SCMP) used for neighbour coordinations between tunnel endpoints. These coordinations are used for functions such as tunnel MTU signalling, route optimisations, neighbour reachability testing, and so on.
SEALは、オプションの32ビットの識別子と可変長の整合性チェックベクトルを提供します。これらは、パケットの識別、メッセージの発信元の認証、リプレイ防止、中間層のセグメント化と再構成の機能に使用できます。 SEALは、トンネルエンドポイント間のネイバー調整に使用されるSEAL制御メッセージプロトコル（SCMP）も提供します。これらの調整は、トンネルMTUシグナリング、ルート最適化、ネイバー到達可能性テストなどの機能に使用されます。
SEAL ensures that packets that are no larger than 1500 bytes can be transported through the tunnel by using a tunnel segmentation function. IPv6 packets that are too large to transport through the tunnel whole are split into segments. The segments are encapsulated in IPv4 and reassembled into the original IPv6 packets at the remote tunnel endpoint. SEAL also admits packets larger than 1500 bytes into the tunnel on a best-effort basis in case the path between the tunnel endpoints can support the larger size.
SEALは、トンネルセグメンテーション機能を使用して、1500バイト以下のパケットを確実にトンネル経由で転送できるようにします。トンネル全体を転送するには大きすぎるIPv6パケットは、セグメントに分割されます。セグメントはIPv4でカプセル化され、リモートトンネルエンドポイントで元のIPv6パケットに再構成されます。また、SEALは、トンネルエンドポイント間のパスがより大きなサイズをサポートできる場合に備えて、1500バイトを超えるパケットをベストエフォートベースでトンネルに許可します。
When SEAL is used alone without its companion technologies, it can be used in the same scenarios as for GRE. However, SEAL provides advanced capabilities that make it better suited than GRE for many use cases. There is currently an experimental open-source implementation of SEAL.
SEALをその関連テクノロジーなしで単独で使用すると、GREと同じシナリオで使用できます。ただし、SEALは、GREよりも多くの使用例に適した高度な機能を提供します。現在、SEALの実験的なオープンソース実装があります。
The 6bed4 tunnel is specified in "6bed4: Peer-to-Peer IPv6 on Any Internetwork" [6BED4]. A specific goal of 6bed4 is to achieve direct communication between peers when the intermediate infrastructure does not prohibit it. The advantage of direct communication is to get a performance level similar to IPv4. The address of a 6bed4 peer is formed from the publicly visible IPv4 address and UDP port. The tunnel service used for fallback connectivity can run anywhere -- perhaps at the local ISP or with a third-party service provider for 6bed4, or even on a well-known address. It is currently an NBMA protocol; there are openings for expansion with multicast.
6bed4トンネルは、「6bed4：ピアツーピアIPv6 on Any Internetwork」[6BED4]で指定されています。 6bed4の具体的な目標は、中間インフラストラクチャが禁止していない場合に、ピア間の直接通信を実現することです。直接通信の利点は、IPv4と同様のパフォーマンスレベルが得られることです。 6bed4ピアのアドレスは、公開されているIPv4アドレスとUDPポートから形成されます。フォールバック接続に使用されるトンネルサービスは、ローカルISPや6bed4のサードパーティサービスプロバイダー、またはよく知られたアドレスなど、どこでも実行できます。これは現在NBMAプロトコルです。マルチキャストによる拡張の余地があります。
The setup of 6bed4 is somewhat similar to 6to4, except that it employs UDP so it can be used behind NAT. It also has elements found in Teredo but without a need to classify NATs and induce behaviour from that. The 6bed4 tunnel makes no assumptions about the capabilities of NAT devices beyond being able to do straightforward NAT on UDP packets. Given this, 6bed4 can create reliable IPv6 tunnels.
6bed4の設定は、NATの背後で使用できるようにUDPを使用することを除いて、6to4にいくらか似ています。 Teredoに含まれる要素もありますが、NATを分類してそこから動作を誘導する必要はありません。 6bed4トンネルは、UDPパケットで単純なNATを実行できることを超えて、NATデバイスの機能を想定していません。このため、6bed4は信頼できるIPv6トンネルを作成できます。
In environments where direct connections between 6bed4 peers are possible, additional path stretch compared to IPv4 communication is avoided, so 6bed4 performance comes close to IPv4 performance. In situations where it is not possible to run over the direct path between two peers because a NAT that does not conform to [RFC4787] is on the path, a fallback to a tunnel server is used. This increases path stretch and affects scalability through its impact on roundtrip times and jitter.
6bed4ピア間の直接接続が可能な環境では、IPv4通信と比較して追加のパスストレッチが回避されるため、6bed4のパフォーマンスはIPv4のパフォーマンスに近くなります。 [RFC4787]に準拠していないNATがパス上にあるために2つのピア間の直接パスを介して実行できない状況では、トンネルサーバーへのフォールバックが使用されます。これにより、パスストレッチが増加し、往復時間とジッターへの影響を通じてスケーラビリティに影響します。
Another area where the tunnel server is needed is for connectivity between 6bed4 peers and native IPv6 hosts. For reasons of performance and scalability, connections between 6bed4 peers are preferred over connections between a 6bed4 peer and a native IPv6 host. A default address exists to support zero-config operation, but it is possible to locally configure a tunnel server as a fallback route, which then also defines the tunnel server for the return path.
トンネルサーバーが必要なもう1つの領域は、6bed4ピアとネイティブIPv6ホスト間の接続用です。パフォーマンスとスケーラビリティの理由から、6bed4ピアとネイティブIPv6ホスト間の接続よりも6bed4ピア間の接続が優先されます。 zero-config操作をサポートするデフォルトのアドレスが存在しますが、トンネルサーバーをフォールバックルートとしてローカルに構成することも可能です。これにより、リターンパスのトンネルサーバーも定義されます。
6bed4 has been specifically designed to support real-time interactive traffic streams, such as SIP calls, between 6bed4-supporting end points, assuming that each prefers 6bed4-to-6bed4 traffic over 6bed4- to-native traffic. Under that premise, the only hosts that need to go through a tunnel server are those that are behind a NAT with Address-Dependent Mapping or Address and Port-Dependent Mapping. A number of different implementations of 6bed4 have been constructed [6BED4] during the ongoing development of its specification.
6bed4は、6bed4-to-nativeトラフィックよりも6bed4-to-6bed4トラフィックを優先すると想定して、6bed4をサポートするエンドポイント間で、SIPコールなどのリアルタイムのインタラクティブトラフィックストリームをサポートするように特別に設計されています。その前提の下で、トンネルサーバーを通過する必要があるホストは、アドレス依存マッピングまたはアドレスおよびポート依存マッピングを使用するNATの背後にあるホストのみです。 6bed4の多くの異なる実装は、その仕様の継続的な開発中に構築されました[6BED4]。
The following protocols are not tunnel mechanisms, but they can be used in the configuration and/or setup phase of such protocols.
次のプロトコルはトンネルメカニズムではありませんが、これらのプロトコルの構成および/またはセットアップフェーズで使用できます。
The Tunnel Setup Protocol [RFC5572] specifies a protocol for negotiating the setup of a variety of tunnel encapsulations. In this document, we are only interested in the encapsulation of IPv6 in IPv4. The Tunnel Setup Protocol can negotiate these as a protocol 41 encapsulated tunnel or as a UDP-encapsulated tunnel. The tunnel negotiation is performed as an XML exchange over UDP or TCP.
トンネルセットアッププロトコル[RFC5572]は、さまざまなトンネルカプセル化のセットアップをネゴシエートするためのプロトコルを指定します。このドキュメントでは、IPv4でのIPv6のカプセル化にのみ関心があります。トンネルセットアッププロトコルは、プロトコル41カプセル化トンネルまたはUDPカプセル化トンネルとしてこれらをネゴシエートできます。トンネルネゴシエーションは、UDPまたはTCPを介したXML交換として実行されます。
As a TSP client exchanges all IPv6 traffic with the same tunnel server, there are no concerns caused by NAT implementations. The only concern is to send regular keepalives, for which ICMPv6 ping messages to the tunnel server are suggested. When encapsulating IPv6 packets directly in IPv4, all protocol 41 limitations apply. To avoid these, an additional UDP header may be used.
TSPクライアントはすべてのIPv6トラフィックを同じトンネルサーバーと交換するため、NAT実装による問題はありません。唯一の懸念は、定期的なキープアライブを送信することです。このため、ICMPv6 pingメッセージがトンネルサーバーに提示されます。 IPv6パケットをIPv4に直接カプセル化する場合、プロトコル41のすべての制限が適用されます。これらを回避するには、追加のUDPヘッダーを使用できます。
The Tunnel Setup Protocol treats all protocols and ports for one IPv4 client address as equivalent. This suffices when protocol 41 is used, but for UDP it creates a situation where one user can set up a tunnel behind NAT, and another user could hijack the tunnel privileges.
トンネルセットアッププロトコルは、1つのIPv4クライアントアドレスのすべてのプロトコルとポートを同等のものとして扱います。プロトコル41を使用する場合はこれで十分ですが、UDPの場合、1人のユーザーがNATの背後にトンネルを設定でき、別のユーザーがトンネル特権をハイジャックする可能性があります。
Open-source clients for the Tunnel Setup Protocol and a matching tunnel infrastructure are provided from the Freenet6 tunnel service [GOGO6].
トンネルセットアッププロトコルのオープンソースクライアントと対応するトンネルインフラストラクチャは、Freenet6トンネルサービス[GOGO6]から提供されます。
The SixXS Heartbeat Protocol [HEARTBEAT] allows nodes that have intermittent connectivity or a dynamic IPv4 address that changes from time to time to have continuing tunneled IPv6 connectivity. One of the goals of the protocol is to determine when a node is no longer present at its previous IPv4 address and then stop sending tunneled packets to prevent them from being delivered to the wrong node. The Heartbeat Protocol then allows a tunnel broker to determine a client's new IPv4 address and continue sending tunneled packets with minimal interruption.
SixXSハートビートプロトコル[HEARTBEAT]を使用すると、断続的な接続または時々刻々と変化する動的IPv4アドレスを持つノードが、トンネル化されたIPv6接続を継続できます。このプロトコルの目標の1つは、ノードが以前のIPv4アドレスに存在しなくなった時期を特定し、トンネルパケットの送信を停止して、誤ったノードに配信されないようにすることです。その後、ハートビートプロトコルにより、トンネルブローカーはクライアントの新しいIPv4アドレスを決定し、中断を最小限に抑えてトンネルパケットを送信し続けることができます。
To accomplish this, a node sends periodic heartbeat packets to the tunnel broker. If the tunnel broker fails to receive valid heartbeat packets, it shuts down the tunnel in question. Heartbeat packets contain an MD5 message authentication code and a timestamp to avoid replay attacks. The Heartbeat Protocol can work with different tunnel mechanisms, but it is often used with configured tunnels (Section 3.1).
これを実現するために、ノードは定期的なハートビートパケットをトンネルブローカーに送信します。トンネルブローカーは、有効なハートビートパケットの受信に失敗すると、問題のトンネルをシャットダウンします。ハートビートパケットには、MD5メッセージ認証コードとタイムスタンプが含まれており、リプレイアタックを回避します。ハートビートプロトコルはさまざまなトンネルメカニズムで機能しますが、設定されたトンネル（セクション3.1）でよく使用されます。
The protocol is implemented in the SixXS tunnel broker; client implementations are available for common operating systems. AYIYA can be considered the successor of the Heartbeat Protocol.
プロトコルは、SixXSトンネルブローカーに実装されています。クライアントの実装は、一般的なオペレーティングシステムで利用できます。 AYIYAはハートビートプロトコルの後継と見なすことができます。
The Tunnel Information and Control (TIC) protocol [TIC] is the setup protocol for the [SIXXS] tunnel-broker service.
トンネル情報と制御（TIC）プロトコル[TIC]は、[SIXXS]トンネルブローカーサービスのセットアッププロトコルです。
With the TIC protocol, a tunnel-broker user can request a list of available tunnels and points of presence (POPs) from the tunnel-broker service. When the user chooses one of the tunnels, the configuration parameters for that tunnel can then be requested through TIC. TIC also provides commands to control the tunnel, for example, to change the tunnel endpoints or to enable or disable the tunnel.
TICプロトコルを使用すると、トンネルブローカーユーザーは、トンネルブローカーサービスから利用可能なトンネルとPOP（Point of Presence）のリストを要求できます。ユーザーがいずれかのトンネルを選択すると、そのトンネルの構成パラメーターをTICを介して要求できます。 TICには、トンネルのエンドポイントを変更したり、トンネルを有効または無効にするなど、トンネルを制御するコマンドも用意されています。
Authentication of users is done based on username and password. Certain tunnel mechanisms, such as AYIYA (Section 3.6) and configured tunnels (Section 3.1) with heartbeat (Section 4.2), need a synchronised clock between the tunnel server and the client. TIC facilitates this by providing a server timestamp on request. The client can use that to verify that its clock is synchronised with the server and show an error message to the user if it is not.
ユーザーの認証は、ユーザー名とパスワードに基づいて行われます。 AYIYA（セクション3.6）やハートビート（セクション4.2）を使用して構成されたトンネル（セクション3.1）などの特定のトンネルメカニズムでは、トンネルサーバーとクライアント間で同期クロックが必要です。 TICは、リクエストに応じてサーバーのタイムスタンプを提供することで、これを容易にします。クライアントはそれを使用して、クロックがサーバーと同期されていることを確認し、同期されていない場合はユーザーにエラーメッセージを表示できます。
The TIC protocol is implemented in the AICCU client software (see [AICCU]) and in AVM Fritz!Box home routers.
TICプロトコルは、AICCUクライアントソフトウェア（[AICCU]を参照）およびAVM Fritz！Boxホームルーターに実装されています。
The following are aspects common to many or all tunnel mechanisms.
以下は、多くまたはすべてのトンネルメカニズムに共通する側面です。
The most straightforward way to encapsulate an IPv6 packet inside an IPv4 packet is by simply adding an IPv4 header in front of the IPv6 header. In this case, the Protocol field in the IPv4 header is set to the value 41. This encapsulation is also known as "IPv6 in IPv4" and "IP6 Encapsulation".
IPv6パケットをIPv4パケット内にカプセル化する最も簡単な方法は、IPv6ヘッダーの前にIPv4ヘッダーを追加することです。この場合、IPv4ヘッダーのプロトコルフィールドは値41に設定されます。このカプセル化は、「IPv4 in IPv4」および「IP6カプセル化」とも呼ばれます。
This simple "protocol 41" encapsulation is used by a number of tunnel mechanisms:
この単純な「プロトコル41」カプセル化は、いくつかのトンネルメカニズムで使用されます。
configured tunnels (Section 3.1)
構成済みトンネル（セクション3.1）
automatic tunneling (Section 3.2)
自動トンネリング（セクション3.2）
6over4 (Section 3.3)
6over4（セクション3.3）
6to4 (Section 3.5)
6to4（セクション3.5）
ISATAP (Section 3.7)
ISATAP（セクション3.7）
6rd (Section 3.9)
6位（3.9節）
It is not uncommon for NATs and firewalls to block protocol 41 encapsulated packets, especially at the boundary between an organisation's internal network and the public Internet. Tunnel mechanisms that don't use protocol 41 encapsulation typically employ a UDP header and are somewhat less likely to be filtered, assuming that tunneling is initiated on the LAN side. UDP is usually subjected to Network Address Port Translation (NAPT) [RFC2663], which additionally translates between internal and external port numbers. (Often, the term "NAT" is used where "NAPT" may be more appropriate.)
特に組織の内部ネットワークと公衆インターネットの間の境界で、NATとファイアウォールがプロトコル41カプセル化パケットをブロックすることは珍しくありません。プロトコル41カプセル化を使用しないトンネルメカニズムは、通常、UDPヘッダーを使用し、LAN側でトンネリングが開始されていると仮定して、フィルター処理される可能性が少し低くなります。 UDPは通常、ネットワークアドレスポート変換（NAPT）[RFC2663]の影響を受けます。これは、内部ポート番号と外部ポート番号の間でさらに変換を行います。 （多くの場合、「NAT」という用語は、「NAPT」がより適切な場合に使用されます。）
Although protocol 41 can in principle work through NAT, there are two issues. First, when the IPv6 address is derived from the IPv4 address (see Section 5.4), NATing of the outer IPv4 header breaks the relationship between the IPv4 and IPv6 addresses. Second, because protocol 41 does not use port numbers, the number of protocol 41 tunnel endpoints that can be supported behind a NAT device is equal to its number of external IPv4 addresses (see Section 6.1). This limitation also applies to GRE.
プロトコル41は原則としてNATを通じて機能しますが、2つの問題があります。第1に、IPv6アドレスがIPv4アドレスから派生した場合（セクション5.4を参照）、外部IPv4ヘッダーのNAT処理により、IPv4アドレスとIPv6アドレスの関係が壊れます。次に、プロトコル41はポート番号を使用しないため、NATデバイスの背後でサポートできるプロトコル41トンネルエンドポイントの数は、外部IPv4アドレスの数と同じです（セクション6.1を参照）。この制限はGREにも適用されます。
Tunnels that pass through a NAT device or stateful firewall need to generate traffic at regular intervals to refresh the NAT or firewall mapping. If the mapping is lost, tunneled packets from the outside won't be able to pass through the NAT or firewall until a system behind the NAT or firewall sends a tunneled packet and the mapping is re-created. Alternatively, a static mapping (often in the form of a "default" or "DMZ" host) may be configured manually.
NATデバイスまたはステートフルファイアウォールを通過するトンネルは、NATまたはファイアウォールのマッピングを更新するために、定期的にトラフィックを生成する必要があります。マッピングが失われると、外部からのトンネルパケットは、NATまたはファイアウォールの背後にあるシステムがトンネルパケットを送信してマッピングが再作成されるまで、NATまたはファイアウォールを通過できません。あるいは、静的マッピング（多くの場合「デフォルト」または「DMZ」ホストの形式）を手動で構成することもできます。
The following tunnel mechanisms are incompatible with NAT because their addresses must be derived from a globally unique IPv4 address:
次のトンネルメカニズムは、アドレスがグローバルに一意のIPv4アドレスから派生する必要があるため、NATと互換性がありません。
automatic tunneling (Section 3.2)
自動トンネリング（セクション3.2）
6to4 (Section 3.5)
6to4（セクション3.5）
6rd (Section 3.9)
6位（3.9節）
LISP (Section 3.11)
LISP（セクション3.11）
Note that it is common to run 6to4 or 6rd on a home gateway device that also performs IPv4 NAT. In this configuration, NAT is not applied to tunneled packets, so NAT and 6to4/6rd can coexist.
IPv4 NATも実行するホームゲートウェイデバイスで6to4または6rdを実行するのが一般的であることに注意してください。この構成では、NATはトンネルパケットに適用されないため、NATと6to4 / 6rdは共存できます。
The following tunnel mechanisms cannot operate between nodes on opposing sides of a NAT, but they do work if _all_ nodes are behind a NAT (where RFC 1918 addresses are often used):
次のトンネルメカニズムは、NATの反対側にあるノード間で動作できませんが、_all_ノードがNATの背後にある場合に機能します（RFC 1918アドレスがよく使用されます）。
6over4 (Section 3.3)
6over4（セクション3.3）
ISATAP (Section 3.7)
ISATAP（セクション3.7）
The following tunnel mechanisms may work through NAT in some circumstances, but are not designed for NAT compatibility:
次のトンネルメカニズムは、状況によってはNATを介して機能する場合がありますが、NAT互換性のために設計されていません。
configured tunnels (Section 3.1)
構成済みトンネル（セクション3.1）
GRE (Section 3.4)
GRE（セクション3.4）
The following tunnel mechanisms are designed for NAT compatibility:
次のトンネルメカニズムは、NAT互換性のために設計されています。
AYIYA (Section 3.6)
AYIYA（セクション3.6）
Teredo (Section 3.8); but it is unreliable
Teredo（セクション3.8）;しかし、それは信頼できません
6a44 (Section 3.10)
6a44（セクション3.10）
SEAL (Section 3.12)
シール（3.12節）
6bed4 (Section 3.13)
6bed4（セクション3.13）
The LISP specification requires that locator addresses (the addresses in the outer IPv4 header) are globally routable public addresses.
LISP仕様では、ロケーターアドレス（外部IPv4ヘッダーのアドレス）がグローバルにルーティング可能なパブリックアドレスである必要があります。
A tunnel built over UDP makes a claim on a resource, namely, an external UDP port. This may impact how well a tunnel will scale in an organisation; for instance, if every desktop runs its own tunnel client over UDP, then the claim on this resource may have some impact.
UDPを介して構築されたトンネルは、リソース、つまり外部UDPポートを要求します。これは、組織内でのトンネルの拡張性に影響を与える可能性があります。たとえば、すべてのデスクトップがUDPを介して独自のトンネルクライアントを実行している場合、このリソースに対する要求が何らかの影響を与える可能性があります。
Note that ISPs may have multiple subscribers share a public IPv4 address by performing NAT (Carrier-Grade NAT in this context). In this case, the subscribers' home gateways may receive an address in the 100.64.0.0/10 block [RFC6598]. For the purposes of tunnel mechanisms, this address block is similar to the RFC 1918 address blocks. However, tunnel implementations that are aware of NAT and RFC 1918 addresses may not recognise 100.64.0.0/10 as non-public addresses and fail to operate successfully. The same issue is present if an ISP decides to use regular global unicast IPv4 address space behind a CGN.
ISPは、NAT（この場合、キャリアグレードNAT）を実行することにより、複数のサブスクライバーでパブリックIPv4アドレスを共有する場合があることに注意してください。この場合、加入者のホームゲートウェイは、100.64.0.0 / 10ブロック[RFC6598]でアドレスを受け取ることがあります。トンネルメカニズムの目的では、このアドレスブロックはRFC 1918アドレスブロックに似ています。ただし、NATおよびRFC 1918アドレスを認識するトンネル実装は、100.64.0.0 / 10を非パブリックアドレスとして認識せず、正常に動作しない場合があります。同じ問題は、ISPがCGNの背後にある通常のグローバルユニキャストIPv4アドレス空間を使用することを決定した場合にも存在します。
Because of the extra IPv4 header and possible additional headers between the IPv4 and IPv6 headers, tunnels experience a reduced maximum packet size (MTU) compared to native IPv6 communication.
追加のIPv4ヘッダーと、IPv4ヘッダーとIPv6ヘッダーの間に追加のヘッダーが存在する可能性があるため、ネイティブのIPv6通信と比較して、トンネルの最大パケットサイズ（MTU）が減少します。
Path MTU discovery (PMTUD) should handle this in nearly all cases, but filtering of ICMPv6 "packet too big" messages may lead to an inability to communicate because senders of large packets fail to perform PMTUD successfully. However, when a tunnel terminates directly on the host using it, the TCP maximum segment size (MSS) option communicates the maximum packet size to the remote endpoint, so TCP-based communication may still succeed. If not, the initial TCP SYN/ACK exchange happens without issue, but then the session stalls as the larger packets containing data are lost.
パスMTUディスカバリー（PMTUD）は、ほとんどすべての場合にこれを処理しますが、大きなパケットの送信者がPMTUDを正常に実行できないため、ICMPv6の「パケットが大きすぎます」メッセージをフィルタリングすると、通信できなくなる可能性があります。ただし、トンネルを使用するホストでトンネルが直接終了する場合、TCP最大セグメントサイズ（MSS）オプションは最大パケットサイズをリモートエンドポイントに伝達するため、TCPベースの通信は引き続き成功する可能性があります。そうでない場合、最初のTCP SYN / ACK交換は問題なく行われますが、データを含むより大きなパケットが失われると、セッションが停止します。
With tunnel mechanisms where the MTU is left unspecified, it is possible for the two endpoints to have different MTUs: typically, one uses the IPv6 minimum (1280 bytes), while the other uses the physical MTU minus tunnel overhead (often 1480 bytes). In theory, this should lead to PMTUD failures because the "big" side unknowingly sends packets that the "small" side can't handle. However, in practice, implementations handle incoming packets larger than their own MTU without issue.
MTUが指定されていないままのトンネルメカニズムでは、2つのエンドポイントが異なるMTUを持つ可能性があります。通常、1つはIPv6最小（1280バイト）を使用し、もう1つは物理MTUマイナストンネルオーバーヘッド（多くの場合1480バイト）を使用します。理論的には、「大きい」側が無意識のうちに「小さい」側が処理できないパケットを送信するため、これはPMTUD障害を引き起こすはずです。ただし、実際には、実装は自身のMTUよりも大きい着信パケットを問題なく処理します。
Only when the IPv4 MTU is reduced below 1500 bytes, for instance, when using PPP over Ethernet (PPPoE, [RFC2516]), issues are more likely to arise. So, when the possibility exists that tunneled packets encounter a PPPoE link, it is prudent to set the MTU of a tunnel to no more than 1472 bytes, so that tunneled packets don't have to be fragmented. Additionally, Section 3.2.1 of [RFC4213] recommends limiting the MTU of tunnels to a minimum of 1280 bytes.
PPP over Ethernet（PPPoE、[RFC2516]）を使用する場合など、IPv4 MTUが1500バイト未満に減少した場合のみ、問題が発生する可能性が高くなります。したがって、トンネルパケットがPPPoEリンクに遭遇する可能性がある場合は、トンネルのMTUを1472バイト以下に設定して、トンネルパケットをフラグメント化する必要がないようにするのが賢明です。さらに、[RFC4213]のセクション3.2.1は、トンネルのMTUを最低1280バイトに制限することを推奨しています。
SEAL was specifically designed to overcome these limitations by adding the capability to fragment IPv6 packets prior to encapsulation in IPv4 and then to reassemble the fragments at the remote tunnel endpoint. This way, the SEAL tunnel ensures that packets that are no larger than 1500 bytes will be transported to the tunnel far end even if there are restricting links in the path. SEAL can also admit larger packets into the tunnel on a best-effort basis in case the path between the tunnel endpoints can support this larger size.
SEALは、IPv4でカプセル化する前にIPv6パケットをフラグメント化し、リモートトンネルエンドポイントでフラグメントを再構成する機能を追加することにより、これらの制限を克服するように特別に設計されました。このようにして、SEALトンネルは、パスに制限リンクがある場合でも、1500バイト以下のパケットがトンネルの遠端に確実に転送されるようにします。トンネルエンドポイント間のパスがこのより大きなサイズをサポートできる場合、SEALは、より大きなパケットをベストエフォートベースでトンネルに許可することもできます。
Many tunnel mechanisms embed IPv4 addresses or further information in the IPv6 addresses they use. There are two possible reasons for this. First, with an IPv4 address embedded in the IPv6 address, the outer IPv4 header can be derived without a need to explicitly configure tunnel endpoints. Automatic tunneling, 6to4, ISATAP, 6bed4, and Teredo do this. 6over4 embeds the IPv4 address for the second reason; it is embedded in the Interface Identifier and thus the IPv6 address because, that way, a (presumably) globally unique Interface Identifier can be generated.
多くのトンネルメカニズムは、IPv4アドレスまたはそれが使用するIPv6アドレスに詳細情報を埋め込みます。これには2つの理由が考えられます。まず、IPv6アドレスにIPv4アドレスが埋め込まれているため、トンネルエンドポイントを明示的に構成する必要なく、外部IPv4ヘッダーを導出できます。自動トンネリング、6to4、ISATAP、6bed4、およびTeredoがこれを行います。 6over4は2番目の理由でIPv4アドレスを埋め込みます。これにより、インターフェイス識別子、したがってIPv6アドレスに埋め込まれます。これにより、（おそらく）グローバルに一意のインターフェイス識別子を生成できるためです。
Automatic tunneling uses IPv4-compatible addresses in the prefix ::/96 (i.e., the first 96 bits are all zero).
自動トンネリングは、プレフィックス:: / 96でIPv4互換アドレスを使用します（つまり、最初の96ビットはすべてゼロです）。
| 96 bits | 32 |
+------------------------------------------------+-----------------+
| 0:0:0:0:0:0 | IPv4 address |
+------------------------------------------------+-----------------+
The IPv4-Compatible Address Structure
IPv4互換アドレス構造
Systems running 6to4 have addresses in the 6to4 prefix 2002::/16.
6to4を実行しているシステムには、6to4プレフィックス2002 :: / 16のアドレスがあります。
| 16 bits | 32 | 16 | 64 |
+---------+----------------+--------+------------------------------+
| 2002 | IPv4 address | Subnet | Interface ID |
+---------+----------------+--------+------------------------------+
The 6to4 Address Structure
6to4アドレス構造
Because a 6rd domain might share a common IPv4 prefix, it is not always necessary to encode all 32 bits of the IPv4 address in the 6rd delegated prefix. The bits that become available because of this optimisation can be used to provide more subnet IDs to the user and/or to use a smaller address block for the 6rd prefix.
6rdドメインは共通のIPv4プレフィックスを共有する可能性があるため、6番目の委任されたプレフィックスでIPv4アドレスの32ビットすべてを常にエンコードする必要はありません。この最適化のために使用可能になるビットを使用して、ユーザーにより多くのサブネットIDを提供したり、6番目のプレフィックスにより小さいアドレスブロックを使用したりできます。
| n bits | o bits | m bits | 128-n-o-m bits |
+---------------+--------------+-----------+-----------------------+
| 6rd prefix | IPv4 prefix | Subnet ID | Interface ID |
+---------------+--------------+-----------+-----------------------+
|<--- 6rd delegated prefix --->|
The 6rd Address Structure
6番目のアドレス構造
6over4 uses the IPv4 address to generate a 64-bit Interface Identifier, which can then be used to create a 128-bit IPv6 address through Stateless Address Autoconfiguration.
6over4はIPv4アドレスを使用して64ビットのインターフェイス識別子を生成します。これを使用して、ステートレスアドレス自動構成を通じて128ビットのIPv6アドレスを作成できます。
| 48 bits | 16 | 32 | 32 |
+---------------------+--------+-----------------+-----------------+
| Organisation prefix | Subnet | 0:0 | IPv4 address |
+---------------------+--------+-----------------+-----------------+
The 6over4 Address Structure
6over4アドレス構造
The ISATAP address structure is similar to the 6over4 address structure, except that the unique/local (u) bit signifies whether the IPv4 address in the Interface Identifier is unique. Presumably, this is the case for any IPv4 address that is not as defined in RFC 1918. The group (g) bit is set to zero, and the remaining bits are set to 0x00005EFE.
ISATAPアドレス構造は、一意/ローカル（u）ビットがインターフェイス識別子のIPv4アドレスが一意かどうかを示すことを除いて、6over4アドレス構造と似ています。おそらく、これはRFC 1918で定義されていないIPv4アドレスの場合です。グループ（g）ビットはゼロに設定され、残りのビットは0x00005EFEに設定されます。
| 48 bits | 16 | 32 | 32 |
+---------------------+--------+-----------------+-----------------+
| Organisation prefix | Subnet | ug00:5EFE | IPv4 address |
+---------------------+--------+-----------------+-----------------+
The ISATAP Address Structure
ISATAPアドレス構造
Teredo embeds the Teredo server's IPv4 address, a number of flags, and a UDP port number, as well as the Teredo client's IPv4 address in the IPv6 addresses it creates. For good measure, the UDP port and client IPv4 address are "obfuscated" by flipping their bits.
Teredoは、TeredoサーバーのIPv4アドレス、いくつかのフラグ、UDPポート番号、およびTeredoクライアントのIPv4アドレスを、サーバーが作成するIPv6アドレスに埋め込みます。適切な対策として、UDPポートとクライアントのIPv4アドレスは、ビットを反転することによって「難読化」されています。
| 32 bits | 32 | 16 | 16 | 32 |
+----------------+---------------+-------+-------+-----------------+
| 2001:0 | Server IPv4 | Flags | Port | Client IPv4 |
+----------------+---------------+-------+-------+-----------------+
The Teredo Address Structure
Teredoアドレス構造
6a44 can be seen as a combination of 6rd and Teredo. The 6a44 prefix is given out by an ISP. Both the customer site (home gateway) IPv4 address as well as the host's/client's RFC 1918 IPv4 address and a port number are embedded in the IPv6 address.
6a44は6rdとTeredoの組み合わせとして見ることができます。 6a44プレフィックスはISPから提供されます。 IPv6アドレスには、カスタマーサイト（ホームゲートウェイ）のIPv4アドレスと、ホスト/クライアントのRFC 1918 IPv4アドレスおよびポート番号の両方が埋め込まれています。
| 48 bits | 32 | 16 | 32 |
+----------------------+-----------------+-------+-----------------+
| 6a44 prefix | Cust. site IPv4 | Port | Client IPv4 |
+----------------------+-----------------+-------+-----------------+
The 6a44 Address Structure
6a44アドレス構造
6bed4 embeds two combinations of an IPv4 address and UDP port (together acting as a "6bed4 address") in the IPv6 address. The first address is for a tunnel server that everyone is certain to reach; the other is for the direct address that most peers should be able to reach directly. The tunnel server, however, is the only one with guaranteed access to the direct address.
6bed4は、IPv6アドレスにIPv4アドレスとUDPポートの2つの組み合わせ（「6bed4アドレス」として機能する）を埋め込みます。最初のアドレスは、誰もが確実に到達できるトンネルサーバー用です。もう1つは、ほとんどのピアが直接到達できる直接アドレス用です。ただし、直接アドレスへのアクセスが保証されているのはトンネルサーバーだけです。
| 32 bits | 32 | 50 | 14 |
+----------+---------------------+-------------------------+-------+
| prefix |general 6bed4 address| direct 6bed4 address | lanIP |
+----------+---------------------+-------------------------+-------+
The 6bed4 Address Structure
6bed4アドレス構造
The general 6bed4 address field conceals the well-known UDP port for the 6bed4 service. The direct 6bed4 address field includes two extra bits to adhere to the EUI-64 address format. The lanIP bits are free for local purposes, such as creating a DHCPv6 range.
一般的な6bed4アドレスフィールドは、6bed4サービスの既知のUDPポートを隠します。直接6bed4アドレスフィールドには、EUI-64アドレス形式に準拠する2つの追加ビットが含まれています。 lanIPビットは、DHCPv6範囲の作成など、ローカルの目的で使用できません。
The following subsections deal with various aspects of tunnels that guide their selection.
以下のサブセクションでは、トンネルの選択をガイドするトンネルのさまざまな側面を扱います。
With the depletion of the IPv4 address space, the ability to deploy a tunnel mechanism behind NAT as well as the number of IPv6 subscribers, subnets, and individual hosts that can be supported behind a single IPv4 address have become important considerations.
IPv4アドレス空間の枯渇により、NATの背後にトンネルメカニズムを展開する機能、および単一のIPv4アドレスの背後でサポートできるIPv6サブスクライバー、サブネット、および個々のホストの数が重要な考慮事項になりました。
These issues are irrelevant to tunnel mechanisms that provide IPv6 connectivity between hosts within the same administrative domain, such as ISATAP or 6over4, as they can use private IPv4 addresses. This is also true for 6rd; it is used between an ISP and its customers' home gateways when the ISP has implemented NAT.
これらの問題は、プライベートIPv4アドレスを使用できるため、ISATAPや6over4などの同じ管理ドメイン内のホスト間のIPv6接続を提供するトンネルメカニズムには関係ありません。これは6日にも当てはまります。 ISPがNATを実装している場合、ISPとその顧客のホームゲートウェイの間で使用されます。
6to4 cannot work behind any kind of NAT. Most other mechanisms based on protocol 41 can work behind NAT, at least in principle. In practice, this difference is not as big because the protocol 41 encapsulation doesn't provide any fields that allow a NAT to demultiplex tunneled packets. This means that only a single protocol 41 tunnel endpoint can be supported for each public IPv4 address.
6to4は、あらゆる種類のNATの背後では機能しません。プロトコル41に基づく他のほとんどのメカニズムは、少なくとも原則として、NATの背後で機能します。実際には、プロトコル41のカプセル化では、NATがトンネルパケットを逆多重化できるようにするフィールドが提供されていないため、この違いはそれほど大きくありません。つまり、パブリックIPv4アドレスごとにサポートできるプロトコル41トンネルエンドポイントは1つだけです。
This makes configured tunnels (as well as 6to4) incompatible with service-provider-operated NATs, where multiple subscribers share an IPv4 address.
これにより、構成されたトンネル（および6to4）は、複数のサブスクライバーがIPv4アドレスを共有するサービスプロバイダーが操作するNATと互換性がなくなります。
Teredo, 6a44, 6bed4, AYIYA, SEAL, and TSP are designed to work through NATs and use a UDP header, so multiple tunnel endpoints can be hosted behind a single IPv4 address. On the other hand, Teredo only provides IPv6 connectivity to a single host.
Teredo、6a44、6bed4、AYIYA、SEAL、およびTSPは、NATを介して機能し、UDPヘッダーを使用するように設計されているため、複数のトンネルエンドポイントを単一のIPv4アドレスの背後でホストできます。一方、Teredoは単一のホストへのIPv6接続のみを提供します。
The following table shows how many IPv4 addresses each tunnel mechanism requires and how many IPv6 hosts it can connect. The mechanisms are listed in order of increasing numbers of supported IPv6 hosts per IPv4 address.
次の表は、各トンネルメカニズムに必要なIPv4アドレスの数と、接続できるIPv6ホストの数を示しています。メカニズムは、IPv4アドレスごとにサポートされるIPv6ホストの数が増える順にリストされています。
+------------+-------------+-------------+-------------+------------+
| Mechanism | Tunnels per | IPv6 hosts | Public IPv4 | NAT |
| | IPv4 addr. | per tunnel | address | compatible |
+------------+-------------+-------------+-------------+------------+
| Auto. tun. | one | one | required | no |
| 6to4 | one | multiple | required | no |
| LISP | one | multiple | required | no |
| 6rd | one | multiple | not needed | no |
| Conf. tun. | one | multiple | not needed | limited |
| GRE | one | multiple | not needed | limited |
| Teredo | multiple | one | not needed | yes (*) |
| 6bed4 | multiple | multiple | not needed | yes |
| 6a44 | multiple | multiple | not needed | yes |
| AYIYA | multiple | multiple | not needed | yes |
| SEAL | multiple | multiple | not needed | yes |
+------------+-------------+-------------+-------------+------------+
Tunneled IPv6 Hosts per IPv4 Address
IPv4アドレスごとのトンネルIPv6ホスト
(*) Although Teredo is designed for NAT compatibility, it doesn't work through all existing NATs.
（*）TeredoはNAT互換性のために設計されていますが、既存のすべてのNATでは機能しません。
There are two ways to use an IPv6-in-IPv4 tunnel to connect to the IPv6 Internet: using a point-to-point tunnel to a tunnel broker or an ISP-operated gateway, or using a Non-Broadcast Multi-Access (NBMA) tunnel and anycasted public gateways or relays.
IPv6-in-IPv4トンネルを使用してIPv6インターネットに接続するには、トンネルブローカーまたはISPが動作するゲートウェイへのポイントツーポイントトンネルを使用する方法と、非ブロードキャストマルチアクセス（NBMA）を使用する方法の2つがあります。 ）トンネルおよびエニーキャストされたパブリックゲートウェイまたはリレー。
The advantages of the point-to-point model are predictable performance and flexibility regarding the IPv6 addresses used. The advantage of the NBMA model is that traffic between two hosts or networks that both use the mechanism can flow directly without passing through a gateway (direct peer-to-peer communication). An extra advantage of the NBMA model with public gateways is automatic configuration and no involvement from an ISP.
ポイントツーポイントモデルの利点は、使用されるIPv6アドレスに関する予測可能なパフォーマンスと柔軟性です。 NBMAモデルの利点は、両方のメカニズムを使用する2つのホストまたはネットワーク間のトラフィックが、ゲートウェイを経由せずに直接流れることができることです（直接ピアツーピア通信）。パブリックゲートウェイを使用したNBMAモデルの追加の利点は、自動構成であり、ISPからの関与がないことです。
Unfortunately, the advantages of this NBMA public anycast model come at a price: both the peer-to-peer connectivity between tunnel users and the connectivity towards the native IPv6 Internet may suffer from reliability and performance issues.
残念ながら、このNBMAパブリックエニーキャストモデルの利点は高くつきます。トンネルユーザー間のピアツーピア接続とネイティブIPv6インターネットへの接続の両方が、信頼性とパフォーマンスの問題に悩まされる可能性があります。
The anycast mechanism allows tunnel users to utilise the nearest gateway to connect to the IPv6 Internet by simply giving each gateway the same address. Routing protocols then select the lowest-cost (and presumably, shortest) path towards a gateway. However, this makes the path taken by tunneled packets hard to predict or influence. It is common for traffic in two directions to use different gateways, complicating debugging even further. Because nobody is in charge or gets paid for operating a gateway, the number of public gateways is lower than would be ideal. This increases the distance to the nearest gateway for some users. There is also the possibility that gateways encounter more traffic than they can handle.
エニーキャストメカニズムを使用すると、トンネルユーザーは最も近いゲートウェイを利用して、各ゲートウェイに同じアドレスを与えるだけでIPv6インターネットに接続できます。次に、ルーティングプロトコルは、ゲートウェイに向かう最も低コストの（そしておそらく最短の）パスを選択します。ただし、これにより、トンネルパケットがたどるパスが予測または影響を受けにくくなります。 2方向のトラフィックが異なるゲートウェイを使用することは一般的であり、デバッグはさらに複雑になります。ゲートウェイの運用に対して誰も責任を負ったり支払いを受けたりしないため、パブリックゲートウェイの数は理想的な数よりも少なくなります。これにより、一部のユーザーにとって最も近いゲートウェイまでの距離が長くなります。ゲートウェイが処理できるよりも多くのトラフィックがゲートウェイで発生する可能性もあります。
The advantage of a tunnel provided by an ISP or tunnel broker is that there is a clear responsibility for providing a good service with well-maintained gateways.
ISPまたはトンネルブローカーによって提供されるトンネルの利点は、適切に管理されたゲートウェイで優れたサービスを提供する責任があることです。
+------------+---------------+--------------------------------+
| Mechanism | Peer-to-peer | Gateway provided by |
+------------+---------------+--------------------------------+
| Conf. tun. | No | ISP or tunnel broker |
| AYIYA | No | ISP or tunnel broker |
| GRE | No | N/A |
| 6a44 | Within domain | ISP |
| 6rd | Within domain | ISP |
| 6over4 | Globally | N/A |
| ISATAP | Within domain | Own organisation |
| Teredo | Globally | Public |
| 6to4 | Globally | Public or ISP |
| 6bed4 | Globally | Public or ISP or tunnel broker |
| Auto. tun. | Globally | N/A |
| LISP | Configurable | ISP or tunnel broker |
| SEAL | Configurable | ISP or tunnel broker |
+------------+---------------+--------------------------------+
Topologies Supported per Tunnel Mechanism
トンネルメカニズムごとにサポートされるトポロジ
Tunnels may fail for three main reasons: when tunneled packets are filtered, typically by a firewall; when a tunnel endpoint IPv4 address changes; or when tunneled packets are filtered or because of NAT issues.
トンネルは、主に次の3つの理由で失敗する可能性があります。トンネルエンドポイントIPv4アドレスが変更されたとき。または、トンネル化されたパケットがフィルタリングされたとき、またはNATの問題が原因です。
If a tunnel endpoint gets a new address, the other side of the tunnel needs to know to send packets to the new address. With mechanisms that derive IPv6 addresses from the IPv4 address, the previous IPv6 addresses become unreachable, and new IPv6 addresses must be configured.
トンネルエンドポイントが新しいアドレスを取得した場合、トンネルの反対側は、新しいアドレスにパケットを送信することを認識する必要があります。 IPv4アドレスからIPv6アドレスを取得するメカニズムを使用すると、以前のIPv6アドレスに到達できなくなり、新しいIPv6アドレスを構成する必要があります。
Some tunnel mechanisms don't work through NAT, or are limited when working through NAT. NAT mappings can typically only be created by traffic from the "inside" to the "outside", not by traffic from outside the NAT to the network behind the NAT.
一部のトンネルメカニズムは、NATを介して機能しないか、NATを介して機能する場合に制限されます。 NATマッピングは通常、「内部」から「外部」へのトラフィックによってのみ作成でき、NAT外からNATの背後にあるネットワークへのトラフィックでは作成できません。
Point-to-point tunnel mechanisms either work consistently or they always fail. As such, a simple ping to the other side of the tunnel is sufficient to learn its state. Also, point-to-point tunnels may support routing protocols, which can automatically reroute traffic around a failed tunnel.
ポイントツーポイントトンネルメカニズムは、一貫して機能するか、常に失敗します。そのため、トンネルの反対側への単純なpingでその状態を確認できます。また、ポイントツーポイントトンネルはルーティングプロトコルをサポートしている場合があり、障害が発生したトンネルを迂回してトラフィックを自動的に再ルーティングできます。
Some tunnel mechanisms use a public gateway to reach the native IPv6 Internet. Public gateways may or may not be operational and/or reachable, and they may have limited performance, depending on distance and usage.
一部のトンネルメカニズムは、パブリックゲートウェイを使用してネイティブIPv6インターネットに到達します。パブリックゲートウェイは、動作している場合や到達できない場合があります。また、距離や使用状況によっては、パフォーマンスが制限される場合があります。
Tunnel mechanisms that use a broadcast or Non-Broadcast Multi-Access (NBMA) communication model may experience failures between some combinations of tunnel endpoints and not others.
ブロードキャストまたは非ブロードキャストマルチアクセス（NBMA）通信モデルを使用するトンネルメカニズムでは、トンネルエンドポイントの組み合わせによっては、他の組み合わせでは失敗しない場合があります。
The following table lists tunnel mechanisms that provide connectivity to the IPv6 Internet in order of decreasing robustness. (However, even less-robust mechanisms may function well in suitable environments.)
次の表は、堅牢性の低い順にIPv6インターネットへの接続を提供するトンネルメカニズムの一覧です。 （ただし、堅牢性の低いメカニズムであっても、適切な環境ではうまく機能する可能性があります。）
+------------+---------------+--------------------------------------+
| Mechanism | Endpoint | Main issues |
| | address | |
| | change | |
+------------+---------------+--------------------------------------+
| LISP | automatic | None |
| 6rd | interrupt | None |
| AYIYA | automatic | Transient NAT mapping issues |
| Conf. + | interrupt | Proto 41 filtering, competition for |
| Heartbeat | | NAT mappings (1) |
| Conf. tun. | failure | Proto 41 filtering, competition for |
| | | NAT mappings, address change (1) |
| GRE | failure | Proto 47 filtering, address change |
| 6a44 | interrupt | NAT mapping towards peers |
| 6bed4 | interrupt | NAT mapping towards peers |
| 6to4 | interrupt | Enabled out of the box but filtered, |
| | | gateway performance (2) |
| Teredo | interrupt | NAT compatibility, mapping towards |
| | | peers (3) |
+------------+---------------+--------------------------------------+
Susceptibility of Tunnel Mechanisms to Problems
問題に対するトンネルメカニズムの感受性
Notes:
ノート：
(1): Only one protocol 41 tunnel endpoint can receive a NAT mapping behind a NAT using a single public IPv4 address. Additional endpoints will not receive incoming packets. When a tunnel endpoint changes its internal address, the old NAT mapping needs to time out before a new one can be created.
（1）：1つのプロトコル41トンネルエンドポイントのみが、単一のパブリックIPv4アドレスを使用するNATの背後でNATマッピングを受信できます。追加のエンドポイントは着信パケットを受信しません。トンネルエンドポイントが内部アドレスを変更すると、新しいNATマッピングを作成する前に、古いNATマッピングがタイムアウトする必要があります。
(2): 6to4 implementations automatically disable the mechanism when the system has an RFC 1918 address. However, 6to4 may remain enabled and be non-operational when ISPs apply NAT using addresses that are not as defined in RFC 1918 [RFC6598].
（2）：システムにRFC 1918アドレスがある場合、6to4実装はメカニズムを自動的に無効にします。ただし、RFC 1918 [RFC6598]で定義されていないアドレスを使用してISPがNATを適用する場合、6to4は有効のままになり、動作しないことがあります。
(3): Whether Teredo can obtain an address depends on the type of NAT it detects. Whether Teredo functions at such an address depends on the accuracy of that determination, which is founded on an incomplete model of NAT.
（3）：Teredoがアドレスを取得できるかどうかは、Teredoが検出するNATのタイプによって異なります。 Teredoがそのようなアドレスで機能するかどうかは、NATの不完全なモデルに基づいているその決定の精度に依存します。
On some widely used implementations, 6to4 has been enabled by default without checking whether there was connectivity to the anycasted public gateway address. As a result, 6to4-derived connectivity to the IPv6 Internet was often found to be broken because of protocol 41 filtering. Because of this, many operating systems now try to avoid using IPv6 over 6to4. See [RFC6343].
一部の広く使用されている実装では、エニーキャストされたパブリックゲートウェイアドレスへの接続があったかどうかをチェックせずに、6to4がデフォルトで有効になっています。その結果、IPv4インターネットへの6to4派生の接続は、プロトコル41フィルタリングが原因で壊れていることがよくありました。このため、今では多くのオペレーティングシステムがIPv6 over 6to4の使用を避けようとしています。 [RFC6343]を参照してください。
Also see [TERTST] for more information about the robustness of Teredo.
Teredoの堅牢性の詳細については、[TERTST]も参照してください。
There is not a single tunnel mechanism that is more robust in all possible ways than every other tunnel mechanism. However, in general, mechanisms that use public gateways and peer-to-peer tunneling tend to have the most issues. Configured tunnels, on the other hand, often work very well, especially if there is no NAT on the path, but they may need administrative intervention when a tunnel endpoint address changes.
他のすべてのトンネルメカニズムよりもあらゆる方法でより堅牢な単一のトンネルメカニズムはありません。ただし、一般に、パブリックゲートウェイとピアツーピアトンネリングを使用するメカニズムには、最も問題がある傾向があります。一方、設定されたトンネルは、特にパスにNATがない場合は非常によく機能しますが、トンネルエンドポイントアドレスが変更されたときに管理者の介入が必要になる場合があります。
There is an additional consideration that is important to operators of gateways that connect IPv6-in-IPv4 tunnels to the IPv6 Internet: how much state a tunnel mechanism requires.
IPv6-in-IPv4トンネルをIPv6インターネットに接続するゲートウェイのオペレーターにとって重要な追加の考慮事項があります。トンネルメカニズムが必要とする状態の量です。
6to4, 6rd, 6a44 and 6bed4 require no state at all: when encapsulating IPv6 packets inside an IPv4 packet, the IPv4 destination address is directly copied from bits in the IPv6 destination address. This makes all possible tunneled destinations directly reachable through a single virtual interface.
6to4、6rd、6a44、および6bed4は状態をまったく必要としません。IPv4パケット内にIPv6パケットをカプセル化する場合、IPv4宛先アドレスはIPv6宛先アドレスのビットから直接コピーされます。これにより、すべての可能なトンネル宛先が単一の仮想インターフェースを介して直接到達可能になります。
Teredo relays maintain a list of peers and are intended to service a limited number of hosts. The Teredo server, however, is a stateless gateway component.
Teredoリレーはピアのリストを維持し、限られた数のホストにサービスを提供することを目的としています。ただし、Teredoサーバーはステートレスゲートウェイコンポーネントです。
With configured tunnels, GRE, AYIYA, and SEAL, there is no direct mapping from (part of) the IPv6 destination address to the IPv4 destination address. A typical implementation of these mechanisms has a virtual tunnel interface for each tunnel. Packets are forwarded to the correct virtual interface through a routing table lookup. Routing tables can grow very large and remain fast, so the number of virtual interfaces tends to be the limiting factor for tunnel gateways. AYIYA and the SixXS Heartbeat Protocol also keep track of the reachability status of each tunnel.
トンネル、GRE、AYIYA、およびSEALが構成されている場合、IPv6宛先アドレス（の一部）からIPv4宛先アドレスへの直接のマッピングはありません。これらのメカニズムの一般的な実装には、各トンネルに仮想トンネルインターフェイスがあります。パケットは、ルーティングテーブルのルックアップを通じて正しい仮想インターフェイスに転送されます。ルーティングテーブルは非常に大きく、高速のままである可能性があるため、仮想インターフェイスの数がトンネルゲートウェイの制限要因になる傾向があります。 AYIYAとSixXSハートビートプロトコルは、各トンネルの到達可能性ステータスも追跡します。
There are several reasons why tunneled connectivity may perform inferior to native, untunneled connectivity. Inherently, tunnels add one or more extra headers, and therefore increase overhead. However, for an Ethernet packet of maximum size (1500 bytes), the additional overhead of an IPv4 header is only 1.3%.
トンネル接続がネイティブの非トンネル接続よりもパフォーマンスが低い理由はいくつかあります。本質的に、トンネルは1つ以上の追加ヘッダーを追加するため、オーバーヘッドが増加します。ただし、最大サイズ（1500バイト）のイーサネットパケットの場合、IPv4ヘッダーの追加オーバーヘッドはわずか1.3％です。
The process of encapsulation is not inherently slow, but in some implementations, it may be. Larger routers that normally forward packets using special-purpose hardware often don't have high-performance CPUs. If tunnel encapsulation must then be done by that relatively slow CPU, performance will be worse than regular hardware-based packet forwarding.
カプセル化のプロセスは本質的に遅いわけではありませんが、実装によっては遅い場合があります。通常、専用のハードウェアを使用してパケットを転送する大規模なルーターには、高性能のCPUがないことがよくあります。その比較的遅いCPUでトンネルのカプセル化を行う必要がある場合、パフォーマンスは通常のハードウェアベースのパケット転送よりも悪くなります。
The path that tunneled packets take can be longer than the path that untunneled packets would take (i.e., increased path stretch can occur). This may or may not lead to decreased performance.
トンネリングされたパケットが通るパスは、トンネリングされていないパケットが通るパスよりも長くなる可能性があります（つまり、パスストレッチが増加する可能性があります）。これにより、パフォーマンスが低下する場合とそうでない場合があります。
+------------+-----------------+----------------------+-------------+
| Mechanism | Overhead | Increased path | Variability |
| | (bytes) | stretch | |
+------------+-----------------+----------------------+-------------+
| Conf. tun. | 20 | may be large | none |
| Auto. tun. | 20 | none | none |
| 6over4 | 20 | none | none |
| GRE | 28 - 36 | may be large | none |
| 6to4 | 20 | may be large | high |
| AYIYA | 72 | may be large | low |
| ISATAP | 20 | none | none |
| Teredo | 28 - 36 | may be large | high |
| 6rd | 20 | small | low |
| 6a44 | 20 - 28 | small | low |
| 6bed4 | 28 | may be large | high |
| LISP | 36 | small | low |
| SEAL | 24 - variable | small | low |
+------------+-----------------+----------------------+-------------+
Typical Tunnel Performance
一般的なトンネルパフォーマンス
There are many security considerations with tunneling. An important one is that through a tunnel, connectivity to the IPv6 Internet may exist even though network administrators did not intend for it to be there. "Security Concerns with IP Tunneling" [RFC6169] discusses this issue in detail.
トンネリングには、セキュリティに関する多くの考慮事項があります。重要なのは、トンネルを通じて、ネットワーク管理者がそこにいることを意図していなくても、IPv6インターネットへの接続が存在する可能性があることです。 「IPトンネリングに関するセキュリティ上の懸念」[RFC6169]では、この問題について詳しく説明しています。
Although, in principle, ingress filtering (BCP 38, [RFC2827]) is possible with tunnels, in practice, it is relatively easy for spoofed packets to make their way through a tunnel. Not only is it often easy to spoof the outer IPv4 header and make false IPv6 packets seem to originate from a tunnel broker or gateway, it may also be possible for an attacker to route false IPv6 packets through a legitimate tunnel broker or gateway. Many tunneling protocols have various means of detecting and rejecting such packets, while others have limited or no such provisions. For instance, see [RFC3964] for how this can be addressed with 6to4.
原則として、トンネルでは入口フィルタリング（BCP 38、[RFC2827]）が可能ですが、実際には、スプーフィングされたパケットがトンネルを通過するのは比較的簡単です。多くの場合、外側のIPv4ヘッダーを偽装し、偽のIPv6パケットがトンネルブローカーまたはゲートウェイから発信されたように見せかけるだけでなく、攻撃者が偽のIPv6パケットを正当なトンネルブローカーまたはゲートウェイ経由でルーティングする可能性もあります。多くのトンネリングプロトコルには、そのようなパケットを検出して拒否するさまざまな手段がありますが、他のトンネリングプロトコルにはそのようなプロビジョニングが制限されているか、まったくありません。たとえば、6to4でこれに対処する方法については、[RFC3964]を参照してください。
So it is important to recognise that unless special measures are taken (like [RFC4301]), both IPv4 and IPv6 addresses in tunnel packets may be spoofed and cannot be relied upon for access controls. Such spoofing was used successfully to discover IPv6-in-IPv4 tunnels in [TUNDISC].
したがって、（[RFC4301]のような）特別な対策を講じない限り、トンネルパケットのIPv4アドレスとIPv6アドレスの両方が偽装され、アクセス制御に依存できないことを認識することが重要です。そのようななりすましは、[TUNDISC]でIPv6-in-IPv4トンネルを発見するためにうまく使用されました。
Tunnels may also be used by third parties to obfuscate their activities or perform amplification attacks. To avoid contributing to this problem, it is important to make sure only locally generated packets with legitimate addresses are sent out over tunnels.
トンネルは、第三者がアクティビティを難読化したり、増幅攻撃を実行したりするためにも使用されます。この問題の原因となるのを避けるために、正当なアドレスを持つローカルで生成されたパケットのみがトンネルを介して送信されることを確認することが重要です。
Job Snijders contributed text to the points of comparison. Fred Templin provided the text for SEAL and contributed to the security considerations. Jeroen Massar, Brian Carpenter, Tina Tsou, John Mann, Suresh Krishnan, Victor Kuarsingh, Dan Jones, Nejc Skoberne, and Fred Baker reviewed the document and/or offered suggestions for improvement.
Job Snijdersは、比較のポイントにテキストを提供しました。 Fred TemplinがSEALにテキストを提供し、セキュリティの考慮事項に貢献しました。 Jeroen Massar、Brian Carpenter、Tina Tsou、John Mann、Suresh Krishnan、Victor Kuarsingh、Dan Jones、Nec Skoberne、およびFred Bakerがドキュメントをレビューし、改善のための提案を行いました。
We wish to thank SURFnet and Rogier Spoor for commissioning this work; both their initiative and funding have helped this document to be written.
この作業を委託してくれたSURFnetとRogier Spoorに感謝します。彼らのイニシアチブと資金調達の両方が、このドキュメントの作成に役立っています。
[6BED4] Van Rein, R., "6bed4: Peer-to-Peer IPv6 on Any Internetwork", Work in Progress, July 2013.
[6BED4] Van Rein、R。、「6bed4：Peer-to-Peer IPv6 on Any Internetwork」、Work in Progress、2013年7月。
[AICCU] SixXS, "Automatic IPv6 Connectivity Client Utility (AICCU)", <http://www.sixxs.net/tools/aiccu/>.
[AICCU] SixXS、「自動IPv6接続クライアントユーティリティ（AICCU）」、<http://www.sixxs.net/tools/aiccu/>。
[AYIYA] SixXS, "Anything In Anything (AYIYA)", <http://www.sixxs.net/tools/ayiya/>.
[AYYYA] SixXS、「Anything In Anything（AYIYA）」、<http://www.sixxs.net/tools/ayiya/>。
[GOGO6] gogo6, "Freenet6: Free and Easy IPv6 Connectivity", <http://www.gogo6.com/freenet6>.
[GOGO6] gogo6、 "Freenet6：Free and Easy IPv6 Connectivity"、<http://www.gogo6.com/freenet6>。
[HEARTBEAT] Massar, J., "SixXS Heartbeat Protocol", Work in Progress, June 2005.
[ハートビート]マサーJ。、「SixXSハートビートプロトコル」、進行中の作業、2005年6月。
[LISPBETA] LISP4/LISP6.net, "LISP Beta Network", <http://www.lisp4.net/beta-network/>.
[LISPBETA] LISP4 / LISP6.net、「LISP Beta Network」、<http://www.lisp4.net/beta-network/>。
[MAP] Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, "Mapping of Address and Port with Encapsulation (MAP)", Work in Progress, August 2013.
[MAP] Troan、O.、Dec、W.、Li、X.、Bao、C.、Matsushima、S.、Murakami、T.、and T. Taylor、 "Mapping of Address and Port with Encapsulation（MAP）" 、Work in Progress、2013年8月。
[MASSAR] Massar, J., "AYIYA: Anything In Anything", Work in Progress, July 2004.
[MASSAR] Massar、J。、「AYIYA：Anything In Anything」、進行中の作業、2004年7月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU discovery」、RFC 1191、1990年11月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC1933] Gilligan、R. and E. Nordmark、 "Transition Mechanisms for IPv6 Hosts and Routers"、RFC 1933、April 1996。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のパスMTUディスカバリ」、RFC 1981、1996年8月。
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2516] Mamakos、L.、Lidl、K.、Evarts、J.、Carrel、D.、Simone、D.、R。Wheeler、「A Method for Transmitting PPP over Ethernet（PPPoE）」、RFC 2516、2月1999
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2529] Carpenter、B。およびC. Jung、「明示的なトンネルのないIPv4ドメインを介したIPv6の転送」、RFC 2529、1999年3月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス変換（NAT）の用語と考慮事項」、RFC 2663、1999年8月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 2784、2000年3月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを利用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、2000年5月。
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC2893] Gilligan、R. and E. Nordmark、 "Transition Mechanisms for IPv6 Hosts and Routers"、RFC 2893、August 2000。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B。およびK.ムーア、「IPv4クラウドを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068] Huitema、C。、「Antocast Prefix for 6to4 Relay Routers」、RFC 3068、2001年6月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[RFC3489] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「STUN-Simple Data Traversal of User Datagram Protocol（UDP）Through Network Address Translators（NATs）」、RFC 3489、2003年3月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964] Savola、P。およびC. Patel、「6to4のセキュリティに関する考慮事項」、RFC 3964、2004年12月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストおよびルーターの基本的な移行メカニズム」、RFC 4213、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380] Huitema、C。、「Teredo：Tunneling IPv6 over UDP through Network Address Translations（NATs）」、RFC 4380、2006年2月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]オーデットF.およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、2007年1月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", RFC 4891, May 2007.
[RFC4891] Graveman、R.、Parthasarathy、M.、Savola、P。、およびH. Tschofenig、「Using IPsec to Secure IPv6-in-IPv4 Tunnels」、RFC 4891、2007年5月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214] Templin、F.、Gleeson、T。、およびD. Thaler、「Intra-Site Automatic Tunnel Addressing Protocol（ISATAP）」、RFC 5214、2008年3月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、2008年10月。
[RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", RFC 5572, February 2010.
[RFC5572] Blanchet、M。、およびF. Parent、「IPv6 Tunnel Broker with the Tunnel Setup Protocol（TSP）」、RFC 5572、2010年2月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969] Townsley、W.およびO. Troan、「IPv4 Infrastructures on IPv4 Infrastructures（6rd）-Protocol Specification」、RFC 5969、2010年8月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145] Li、X.、Bao、C。、およびF. Baker、「IP / ICMP変換アルゴリズム」、RFC 6145、2011年4月。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6169] Krishnan、S.、Thaler、D。、およびJ. Hoagland、「IPトンネリングに関するセキュリティ上の懸念」、RFC 6169、2011年4月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、2011年8月。
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.
[RFC6343]カーペンター、B。、「6to4展開に関する勧告ガイドライン」、RFC 6343、2011年8月。
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012.
[RFC6598] Weil、J.、Kuarsingh、V.、Donley、C.、Liljenstolpe、C。、およびM. Azinger、「IANA-Reserved IPv4 Prefix for Shared Address Space」、BCP 153、RFC 6598、2012年4月。
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724] Thaler、D.、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、2012年9月。
[RFC6732] Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider Managed Tunnels", RFC 6732, September 2012.
[RFC6732] Kuarsingh、V.、Lee、Y。、およびO. Vautrin、「6to4 Provider Managed Tunnels」、RFC 6732、2012年9月。
[RFC6751] Despres, R., Carpenter, B., Wing, D., and S. Jiang, "Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)", RFC 6751, October 2012.
[RFC6751] Despres、R.、Carpenter、B.、Wing、D。、およびS. Jiang、「IPv4-to-IPv4 NAT Customer Premises Equipment（6a44）の背後にあるネイティブIPv6」、RFC 6751、2012年10月。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013.
[RFC6830] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator / ID Separation Protocol（LISP）」、RFC 6830、2013年1月。
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6832] Lewis、D.、Meyer、D.、Farinacci、D。、およびV. Fuller、「Locator / ID Separation Protocol（LISP）and Non-LISP Sites between Interworking」、RFC 6832、2013年1月。
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013.
[RFC6833] Fuller、V。およびD. Farinacci、「Locator / ID Separation Protocol（LISP）Map-Server Interface」、RFC 6833、2013年1月。
[SEAL] Templin, F., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Work in Progress, October 2013.
[SEAL] Templin、F。、「サブネットワークカプセル化および適応層（SEAL）」、作業中、2013年10月。
[SIXXS] Massar, J. and P. van Pelt, "IPv6 Deployment & Tunnel Broker", <http://www.sixxs.net/>.
[SIXXS] Massar、J。およびP. van Pelt、「IPv6 Deployment＆Tunnel Broker」、<http://www.sixxs.net/>。
[TERTST] Huston, G., "Testing Teredo", April 2011, <http://www.potaroo.net/ispcol/2011-04/teredo.html>.
[TERTST] Huston、G。、「Testing Teredo」、2011年4月、<http://www.potaroo.net/ispcol/2011-04/teredo.html>。
[TIC] SixXS, "Tunnel Information and Control protocol (TIC)", <http://www.sixxs.net/tools/tic/>.
[TIC] SixXS、「トンネル情報および制御プロトコル（TIC）」、<http://www.sixxs.net/tools/tic/>。
[TR-069] The Broadband Forum, "CPE WAN Management Protocol", July 2011, <http://www.broadband-forum.org/technical/ download/TR-069_Amendment-4.pdf>.
[TR-069]ブロードバンドフォーラム、「CPE WAN管理プロトコル」、2011年7月、<http://www.broadband-forum.org/technical/download/TR-069_Amendment-4.pdf>。
[TUNBROKER] Hurricane Electric, "Hurricane Electric Free IPv6 Tunnel Broker", <http://www.tunnelbroker.net/>.
[TUNBROKER]ハリケーンエレクトリック、「Hurricane Electric Free IPv6 Tunnel Broker」、<http://www.tunnelbroker.net/>。
[TUNDISC] Colitti, L., Di Battista, G., and M. Patrignani, "IPv6-in-IPv4 tunnel discovery: methods and experimental results", IEEE eTransactions on Network and Service Management (eTNSM), vol. 1, no. 1, p. 2-10, April 2004.
[TUNDISC] Colitti、L.、Di Battista、G。、およびM. Patrignani、「IPv6-in-IPv4トンネル発見：方法と実験結果」、IEEE eTransactions on Network and Service Management（eTNSM）、vol。 1、いいえ。 1、p。 2004年4月2-10日。
Each type of tunnel has specific advantages and disadvantages. We have considered the following points when evaluating the different protocols. Not every point is mentioned in each section where a protocol is described, only those that are specifically relevant to that protocol.
各タイプのトンネルには、特定の利点と欠点があります。さまざまなプロトコルを評価するときは、次の点を考慮しました。プロトコルが説明されている各セクションですべてのポイントが言及されているわけではなく、そのプロトコルに特に関連するものだけが言及されています。
Protocol overhead: How much overhead does the tunneling protocol cause? There are two factors that play a role: the number of interactions to set up the tunnel and the packet header size causing a lower MTU and/or fragmentation.
プロトコルのオーバーヘッド：トンネリングプロトコルはどのくらいのオーバーヘッドを引き起こしますか？役割を果たす2つの要因があります。トンネルをセットアップするための相互作用の数と、MTUの低下やフラグメント化を引き起こすパケットヘッダーサイズです。
Automatic configuration: Does this protocol require manual configuration at the endpoints?
自動構成：このプロトコルでは、エンドポイントで手動構成が必要ですか？
Predictability: How predictable is the functioning of the protocol?
予測可能性：プロトコルの機能はどの程度予測可能ですか？
Single host or network: Is this protocol intended to be used by a single host or by a router that then provides IPv6 connectivity to multiple hosts?
単一のホストまたはネットワーク：このプロトコルは、単一のホスト、または複数のホストにIPv6接続を提供するルーターによって使用されることを意図していますか？
Load balancing: Does the tunnel traffic have enough entropy and/or "hashability" to be able to be load-balanced over multiple links, or do all tunnel packets have the same outer 5-tuple?
負荷分散：トンネルトラフィックには、複数のリンクで負荷分散できる十分なエントロピーまたは「ハッシュ可能性」がありますか、それともすべてのトンネルパケットに同じ外側の5タプルがありますか？
Path stretch: Does the tunnel optimise the route, or is there a big potential for a much longer path when using the tunnel?
パスストレッチ：トンネルはルートを最適化しますか、それともトンネルを使用するときにパスがはるかに長くなる可能性がありますか？
NAT traversal: Can the tunnel pass through a NAT gateway, and does it require configuration on that NAT gateway?
NATトラバーサル：トンネルはNATゲートウェイを通過でき、そのNATゲートウェイでの構成が必要ですか？
Tunnel endpoint mobility: Are the IPv4 addresses of the tunnel fixed, or do they adjust automatically when an endpoint moves?
トンネルエンドポイントモビリティ：トンネルのIPv4アドレスは固定されていますか、それともエンドポイントが移動したときに自動的に調整されますか？
State: Are the endpoints required to keep state for the tunnel, or is the tunnel stateless?
状態：エンドポイントはトンネルの状態を維持する必要がありますか、それともトンネルはステートレスですか？
Network type: Is this network a point-to-point or NBMA type of network?
ネットワークタイプ：このネットワークはポイントツーポイントまたはNBMAタイプのネットワークですか？
Purpose: What is the intended purpose of this tunnel protocol?
目的：このトンネルプロトコルの目的は何ですか？
Related protocols: To which protocols is this tunnel protocol related? Are there alternatives?
関連プロトコル：このトンネルプロトコルはどのプロトコルに関連していますか？代わりはありますか？
Implementations: Is this protocol supported on the major operating systems, routers, and firewalls?
実装：このプロトコルは主要なオペレーティングシステム、ルーター、ファイアウォールでサポートされていますか？
Limitations: What are the known limitations of this protocol?
制限：このプロトコルの既知の制限は何ですか？
Authors' Addresses
著者のアドレス
Sander Steffann S.J.M. Steffann Consultancy Tienwoningenweg 46 Apeldoorn, Gelderland 7312 DN The Netherlands
サンダーステファンS.J.M. Steffann Consultancy Tienwoningenweg 46アペルドールンヘルダーラントオランダ7312 DN
EMail: sander@steffann.nl
Iljitsch van Beijnum Institute IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain
Iljitsch van Beijnum Institute IMDEA Networks Avda。 del Mar Mediterraneo、22 Leganes、マドリード28918スペイン
EMail: iljitsch@muada.com
Rick van Rein OpenFortress Haarlebrink 5 Enschede, Overijssel 7544 WP The Netherlands
Rick van Rein OpenFortress Haarlebrink 5エンスヘーデ、オーフェルアイセル7544 WPオランダ
EMail: rick@openfortress.nl