[要約] RFC 2893は、IPv6ホストとルーターのための移行メカニズムに関する規格です。このRFCの目的は、IPv6への移行を容易にするためのメカニズムを提供することです。
Network Working Group R. Gilligan
Request for Comments: 2893 FreeGate Corp.
Obsoletes: 1933 E. Nordmark
Category: Standards Track Sun Microsystems, Inc.
August 2000
Transition Mechanisms for IPv6 Hosts and Routers
IPv6ホストとルーターの移行メカニズム
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（C）The Internet Society（2000）。全著作権所有。
Abstract
概要
This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. This document obsoletes RFC 1933.
このドキュメントでは、IPv6ホストとルーターによって実装できるIPv4互換性メカニズムを指定します。これらのメカニズムには、インターネットプロトコル（IPv4およびIPv6）の両方のバージョンの完全な実装の提供、およびIPv4ルーティングインフラストラクチャを介したIPv6パケットのトンネリングが含まれます。それらは、IPv6ノードがIPv4との完全な互換性を維持できるように設計されています。これにより、インターネットでのIPv6の展開が大幅に簡略化され、最終的にインターネット全体がIPv6に移行しやすくなります。このドキュメントはRFC 1933を廃止します。
Table of Contents
目次
1. Introduction............................................. 2
1.1. Terminology......................................... 3
1.2. Structure of this Document.......................... 5
2. Dual IP Layer Operation.................................. 6
2.1. Address Configuration............................... 7
2.2. DNS................................................. 7
2.3. Advertising Addresses in the DNS.................... 8
3. Common Tunneling Mechanisms.............................. 9
3.1. Encapsulation....................................... 11
3.2. Tunnel MTU and Fragmentation........................ 11
3.3. Hop Limit........................................... 13
3.4. Handling IPv4 ICMP errors........................... 13
3.5. IPv4 Header Construction............................ 15
3.6. Decapsulation....................................... 16
3.7. Link-Local Addresses................................ 17
3.8. Neighbor Discovery over Tunnels..................... 18
4. Configured Tunneling..................................... 18
4.1. Default Configured Tunnel........................... 19
4.2. Default Configured Tunnel using IPv4 "Anycast Address" 19
4.3. Ingress Filtering................................... 20
5. Automatic Tunneling...................................... 20
5.1. IPv4-Compatible Address Format...................... 20
5.2. IPv4-Compatible Address Configuration............... 21
5.3. Automatic Tunneling Operation....................... 22
5.4. Use With Default Configured Tunnels................. 22
5.5. Source Address Selection............................ 23
5.6. Ingress Filtering................................... 23
6. Acknowledgments.......................................... 24
7. Security Considerations.................................. 24
8. Authors' Addresses....................................... 24
9. References............................................... 25
10. Changes from RFC 1933................................... 26
11. Full Copyright Statement................................ 29
The key to a successful IPv6 transition is compatibility with the large installed base of IPv4 hosts and routers. Maintaining compatibility with IPv4 while deploying IPv6 will streamline the task of transitioning the Internet to IPv6. This specification defines a set of mechanisms that IPv6 hosts and routers may implement in order to be compatible with IPv4 hosts and routers.
IPv6への移行を成功させる鍵は、IPv4ホストとルーターの大規模なインストールベースとの互換性です。 IPv6の展開中にIPv4との互換性を維持すると、インターネットをIPv6に移行するタスクが合理化されます。この仕様は、IPv6ホストとルーターがIPv4ホストとルーターとの互換性のために実装できる一連のメカニズムを定義しています。
The mechanisms in this document are designed to be employed by IPv6 hosts and routers that need to interoperate with IPv4 hosts and utilize IPv4 routing infrastructures. We expect that most nodes in the Internet will need such compatibility for a long time to come, and perhaps even indefinitely.
このドキュメントのメカニズムは、IPv4ホストと相互運用し、IPv4ルーティングインフラストラクチャを利用する必要があるIPv6ホストとルーターで使用されるように設計されています。インターネットのほとんどのノードには、このような互換性が長い間、おそらくは無期限に必要になると予想されます。
However, IPv6 may be used in some environments where interoperability with IPv4 is not required. IPv6 nodes that are designed to be used in such environments need not use or even implement these mechanisms.
ただし、IPv4との相互運用性が不要な一部の環境では、IPv6を使用できます。このような環境で使用するように設計されたIPv6ノードは、これらのメカニズムを使用したり、実装したりする必要はありません。
The mechanisms specified here include:
ここで指定されたメカニズムは次のとおりです。
- Dual IP layer (also known as Dual Stack): A technique for providing complete support for both Internet protocols -- IPv4 and IPv6 -- in hosts and routers.
- デュアルIPレイヤー（デュアルスタックとも呼ばれます）：ホストとルーターで、IPv4とIPv6の両方のインターネットプロトコルを完全にサポートするための手法。
- Configured tunneling of IPv6 over IPv4: Point-to-point tunnels made by encapsulating IPv6 packets within IPv4 headers to carry them over IPv4 routing infrastructures.
- IPv6 over IPv4の構成済みトンネリング：IPv6パケットをIPv4ヘッダー内にカプセル化してIPv4ルーティングインフラストラクチャ経由で伝送することにより作成されたポイントツーポイントトンネル。
- IPv4-compatible IPv6 addresses: An IPv6 address format that employs embedded IPv4 addresses.
- IPv4互換IPv6アドレス：埋め込みIPv4アドレスを使用するIPv6アドレス形式。
- Automatic tunneling of IPv6 over IPv4: A mechanism for using IPv4-compatible addresses to automatically tunnel IPv6 packets over IPv4 networks.
- IPv6 over IPv4の自動トンネリング：IPv4互換アドレスを使用してIPv6ネットワーク上でIPv6パケットを自動的にトンネリングするメカニズム。
The mechanisms defined here are intended to be part of a "transition toolbox" -- a growing collection of techniques which implementations and users may employ to ease the transition. The tools may be used as needed. Implementations and sites decide which techniques are appropriate to their specific needs. This document defines the initial core set of transition mechanisms, but these are not expected to be the only tools available. Additional transition and compatibility mechanisms are expected to be developed in the future, with new documents being written to specify them.
ここで定義されているメカニズムは、「移行ツールボックス」の一部となることを目的としています。これは、実装とユーザーが移行を容易にするために採用する可能性のある技術の集まりです。ツールは必要に応じて使用できます。実装とサイトは、特定のニーズに適した手法を決定します。このドキュメントは移行メカニズムの初期のコアセットを定義していますが、これらが利用可能な唯一のツールであるとは想定されていません。追加の移行メカニズムと互換性メカニズムが将来開発され、それらを指定する新しいドキュメントが作成される予定です。
The following terms are used in this document:
このドキュメントでは、次の用語が使用されています。
Types of Nodes
ノードのタイプ
IPv4-only node:
IPv4のみのノード：
A host or router that implements only IPv4. An IPv4-only node does not understand IPv6. The installed base of IPv4 hosts and routers existing before the transition begins are IPv4-only nodes.
IPv4のみを実装するホストまたはルーター。 IPv4のみのノードはIPv6を認識しません。移行が始まる前に存在するIPv4ホストとルーターのインストールベースは、IPv4のみのノードです。
IPv6/IPv4 node:
IPv6 / IPv4ノード：
A host or router that implements both IPv4 and IPv6.
IPv4とIPv6の両方を実装するホストまたはルーター。
IPv6-only node:
IPv6のみのノード：
A host or router that implements IPv6, and does not implement IPv4. The operation of IPv6-only nodes is not addressed here.
IPv6を実装し、IPv4を実装しないホストまたはルーター。 IPv6のみのノードの操作については、ここでは扱いません。
IPv6 node:
いＰｖ６ ので：
Any host or router that implements IPv6. IPv6/IPv4 and IPv6- only nodes are both IPv6 nodes.
IPv6を実装するホストまたはルーター。 IPv6 / IPv4およびIPv6-のみのノードはどちらもIPv6ノードです。
IPv4 node:
IPv4ノード：
Any host or router that implements IPv4. IPv6/IPv4 and IPv4- only nodes are both IPv4 nodes.
IPv4を実装するホストまたはルーター。 IPv6 / IPv4とIPv4のみのノードはどちらもIPv4ノードです。
Types of IPv6 Addresses
IPv6アドレスのタイプ
IPv4-compatible IPv6 address:
IPv4互換IPv6アドレス：
An IPv6 address bearing the high-order 96-bit prefix 0:0:0:0:0:0, and an IPv4 address in the low-order 32-bits. IPv4-compatible addresses are used by IPv6/IPv4 nodes which perform automatic tunneling,
上位96ビットのプレフィックス0：0：0：0：0：0を含むIPv6アドレス、および下位32ビットのIPv4アドレス。 IPv4互換アドレスは、自動トンネリングを実行するIPv6 / IPv4ノードで使用されます。
IPv6-native address:
IPv6ネイティブアドレス：
The remainder of the IPv6 address space. An IPv6 address that bears a prefix other than 0:0:0:0:0:0.
IPv6アドレス空間の残り。 0：0：0：0：0：0：0以外のプレフィックスを持つIPv6アドレス。
Techniques Used in the Transition
移行で使用される手法
IPv6-over-IPv4 tunneling:
IPv6-over-IPv4トンネリング：
The technique of encapsulating IPv6 packets within IPv4 so that they can be carried across IPv4 routing infrastructures.
IPv6パケットをIPv4内にカプセル化して、IPv4ルーティングインフラストラクチャ全体で伝送できるようにする手法。
Configured tunneling:
設定されたトンネリング：
IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address is determined by configuration information on the encapsulating node. The tunnels can be either unidirectional or bidirectional. Bidirectional configured tunnels behave as virtual point-to-point links.
IPv6-over-IPv4トンネリング。IPv4トンネルエンドポイントアドレスは、カプセル化ノードの構成情報によって決定されます。トンネルは、単方向または双方向のいずれかです。双方向に設定されたトンネルは、仮想ポイントツーポイントリンクとして動作します。
Automatic tunneling:
自動トンネリング：
IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address is determined from the IPv4 address embedded in the IPv4- compatible destination address of the IPv6 packet being tunneled.
IPv6-over-IPv4トンネリング。IPv4トンネルエンドポイントアドレスは、トンネリングされるIPv6パケットのIPv4互換宛先アドレスに埋め込まれたIPv4アドレスから決定されます。
IPv4 multicast tunneling:
IPv4マルチキャストトンネリング：
IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address is determined using Neighbor Discovery [7]. Unlike configured tunneling this does not require any address configuration and unlike automatic tunneling it does not require the use of IPv4-compatible addresses. However, the mechanism assumes that the IPv4 infrastructure supports IPv4 multicast. Specified in [3] and not further discussed in this document.
IPv6-over-IPv4トンネリング。IPv4トンネルエンドポイントアドレスは、近隣探索[7]を使用して決定されます。構成されたトンネリングとは異なり、これはアドレス構成を必要とせず、自動トンネリングとは異なり、IPv4互換アドレスの使用を必要としません。ただし、このメカニズムでは、IPv4インフラストラクチャがIPv4マルチキャストをサポートしていることを前提としています。 [3]で指定されており、このドキュメントではこれ以上説明しません。
Other transition mechanisms, including other tunneling mechanisms, are outside the scope of this document.
他のトンネリングメカニズムを含む他の移行メカニズムは、このドキュメントの範囲外です。
Modes of operation of IPv6/IPv4 nodes
IPv6 / IPv4ノードの動作モード
IPv6-only operation:
IPv6のみの操作：
An IPv6/IPv4 node with its IPv6 stack enabled and its IPv4 stack disabled.
IPv6スタックが有効で、IPv4スタックが無効になっているIPv6 / IPv4ノード。
IPv4-only operation:
IPv4のみの操作：
An IPv6/IPv4 node with its IPv4 stack enabled and its IPv6 stack disabled.
IPv4スタックが有効で、IPv6スタックが無効になっているIPv6 / IPv4ノード。
IPv6/IPv4 operation:
IPv6 / IPv4オペレーション：
An IPv6/IPv4 node with both stacks enabled.
両方のスタックが有効になっているIPv6 / IPv4ノード。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [16].
このドキュメントに記載されているキーワードは、必須、必須、必須、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、およびOPTIONALであり、[16]で説明されているように解釈されます。
The remainder of this document is organized as follows:
このドキュメントの残りの部分は、次のように構成されています。
- Section 2 discusses the operation of nodes with a dual IP layer, IPv6/IPv4 nodes.
- セクション2では、デュアルIPレイヤー、IPv6 / IPv4ノードを持つノードの操作について説明します。
- Section 3 discusses the common mechanisms used in both of the IPv6-over-IPv4 tunneling techniques.
- セクション3では、IPv6-over-IPv4トンネリング技術の両方で使用される一般的なメカニズムについて説明します。
- Section 4 discusses configured tunneling.
- セクション4では、設定されたトンネリングについて説明します。
- Section 5 discusses automatic tunneling and the IPv4-compatible IPv6 address format.
- セクション5では、自動トンネリングとIPv4互換IPv6アドレス形式について説明します。
The most straightforward way for IPv6 nodes to remain compatible with IPv4-only nodes is by providing a complete IPv4 implementation. IPv6 nodes that provide a complete IPv4 and IPv6 implementations are called "IPv6/IPv4 nodes." IPv6/IPv4 nodes have the ability to send and receive both IPv4 and IPv6 packets. They can directly interoperate with IPv4 nodes using IPv4 packets, and also directly interoperate with IPv6 nodes using IPv6 packets.
IPv6ノードがIPv4のみのノードとの互換性を維持する最も簡単な方法は、完全なIPv4実装を提供することです。完全なIPv4およびIPv6実装を提供するIPv6ノードは、「IPv6 / IPv4ノード」と呼ばれます。 IPv6 / IPv4ノードには、IPv4パケットとIPv6パケットの両方を送受信する機能があります。 IPv4パケットを使用してIPv4ノードと直接相互運用でき、IPv6パケットを使用してIPv6ノードと直接相互運用できます。
Even though a node may be equipped to support both protocols, one or the other stack may be disabled for operational reasons. Thus IPv6/IPv4 nodes may be operated in one of three modes:
ノードが両方のプロトコルをサポートするように装備されている場合でも、運用上の理由で一方または他方のスタックが無効になっている可能性があります。したがって、IPv6 / IPv4ノードは次の3つのモードのいずれかで動作します。
- With their IPv4 stack enabled and their IPv6 stack disabled.
- IPv4スタックを有効にし、IPv6スタックを無効にします。
- With their IPv6 stack enabled and their IPv4 stack disabled.
- IPv6スタックを有効にし、IPv4スタックを無効にします。
- With both stacks enabled.
- 両方のスタックを有効にします。
IPv6/IPv4 nodes with their IPv6 stack disabled will operate like IPv4-only nodes. Similarly, IPv6/IPv4 nodes with their IPv4 stacks disabled will operate like IPv6-only nodes. IPv6/IPv4 nodes MAY provide a configuration switch to disable either their IPv4 or IPv6 stack.
IPv6スタックが無効になっているIPv6 / IPv4ノードは、IPv4のみのノードのように動作します。同様に、IPv4スタックが無効になっているIPv6 / IPv4ノードは、IPv6のみのノードのように動作します。 IPv6 / IPv4ノードは、IPv4またはIPv6スタックを無効にする構成スイッチを提供する場合があります。
The dual IP layer technique may or may not be used in conjunction with the IPv6-over-IPv4 tunneling techniques, which are described in sections 3, 4 and 5. An IPv6/IPv4 node that supports tunneling MAY support only configured tunneling, or both configured and automatic tunneling. Thus three modes of tunneling support are possible:
デュアルIPレイヤー技術は、セクション6、4、5で説明されているIPv6-over-IPv4トンネリング技術と併用する場合としない場合があります。トンネリングをサポートするIPv6 / IPv4ノードは、構成済みのトンネリングのみ、またはその両方をサポートする場合があります。構成済みおよび自動トンネリング。したがって、3つのトンネリングサポートモードが可能です。
- IPv6/IPv4 node that does not perform tunneling.
- トンネリングを実行しないIPv6 / IPv4ノード。
- IPv6/IPv4 node that performs configured tunneling only.
- 設定されたトンネリングのみを実行するIPv6 / IPv4ノード。
- IPv6/IPv4 node that performs configured tunneling and automatic tunneling.
- 構成済みトンネリングと自動トンネリングを実行するIPv6 / IPv4ノード。
Because they support both protocols, IPv6/IPv4 nodes may be configured with both IPv4 and IPv6 addresses. IPv6/IPv4 nodes use IPv4 mechanisms (e.g. DHCP) to acquire their IPv4 addresses, and IPv6 protocol mechanisms (e.g. stateless address autoconfiguration) to acquire their IPv6-native addresses. Section 5.2 describes a mechanism by which IPv6/IPv4 nodes that support automatic tunneling MAY use IPv4 protocol mechanisms to acquire their IPv4-compatible IPv6 address.
IPv6 / IPv4ノードは両方のプロトコルをサポートしているため、IPv4アドレスとIPv6アドレスの両方で構成できます。 IPv6 / IPv4ノードは、IPv4メカニズム（DHCPなど）を使用してIPv4アドレスを取得し、IPv6プロトコルメカニズム（ステートレスアドレス自動構成など）を使用してIPv6ネイティブアドレスを取得します。セクション5.2では、自動トンネリングをサポートするIPv6 / IPv4ノードがIPv4プロトコルメカニズムを使用してIPv4互換IPv6アドレスを取得するメカニズムについて説明しています。
The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map between hostnames and IP addresses. A new resource record type named "A6" has been defined for IPv6 addresses [6] with support for an earlier record named "AAAA". Since IPv6/IPv4 nodes must be able to interoperate directly with both IPv4 and IPv6 nodes, they must provide resolver libraries capable of dealing with IPv4 "A" records as well as IPv6 "A6" and "AAAA" records.
ドメインネームシステム（DNS）は、ホスト名とIPアドレス間のマッピングにIPv4とIPv6の両方で使用されます。 「A6」という新しいリソースレコードタイプがIPv6アドレス[6]に定義され、「AAAA」という以前のレコードがサポートされました。 IPv6 / IPv4ノードは、IPv4ノードとIPv6ノードの両方と直接相互運用できる必要があるため、IPv4 "A"レコードとIPv6 "A6"および "AAAA"レコードを処理できるリゾルバーライブラリを提供する必要があります。
DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling both A6/AAAA and A records. However, when a query locates an A6/AAAA record holding an IPv6 address, and an A record holding an IPv4 address, the resolver library MAY filter or order the results returned to the application in order to influence the version of IP packets used to communicate with that node. In terms of filtering, the resolver library has three alternatives:
IPv6 / IPv4ノード上のDNSリゾルバーライブラリは、A6 / AAAAとAレコードの両方を処理できる必要があります。ただし、クエリがIPv6アドレスを保持するA6 / AAAAレコード、およびIPv4アドレスを保持するAレコードを見つけると、リゾルバーライブラリは、通信に使用されるIPパケットのバージョンに影響を与えるために、アプリケーションに返される結果をフィルターまたは順序付けできます（MAY）。そのノードで。フィルタリングに関して、リゾルバーライブラリには3つの選択肢があります。
- Return only the IPv6 address to the application.
- アプリケーションにIPv6アドレスのみを返します。
- Return only the IPv4 address to the application.
- アプリケーションにIPv4アドレスのみを返します。
- Return both addresses to the application.
- 両方のアドレスをアプリケーションに返します。
If it returns only the IPv6 address, the application will communicate with the node using IPv6. If it returns only the IPv4 address, the application will communicate with the node using IPv4. If it returns both addresses, the application will have the choice which address to use, and thus which IP protocol to employ.
IPv6アドレスのみを返す場合、アプリケーションはIPv6を使用してノードと通信します。 IPv4アドレスのみを返す場合、アプリケーションはIPv4を使用してノードと通信します。両方のアドレスを返す場合、アプリケーションは使用するアドレス、つまり使用するIPプロトコルを選択できます。
If it returns both, the resolver MAY elect to order the addresses -- IPv6 first, or IPv4 first. Since most applications try the addresses in the order they are returned by the resolver, this can affect the IP version "preference" of applications.
両方を返す場合、リゾルバーはアドレスを順序付けすることを選択できます-最初にIPv6、または最初にIPv4。ほとんどのアプリケーションは、リゾルバーから返された順序でアドレスを試行するため、アプリケーションのIPバージョンの「設定」に影響を与える可能性があります。
The decision to filter or order DNS results is implementation specific. IPv6/IPv4 nodes MAY provide policy configuration to control filtering or ordering of addresses returned by the resolver, or leave the decision entirely up to the application.
DNSの結果をフィルタリングまたは順序付ける決定は、実装固有です。 IPv6 / IPv4ノードは、リゾルバから返されたアドレスのフィルタリングまたは順序付けを制御するためのポリシー構成を提供するか、または完全にアプリケーションに決定を任せます。
An implementation MUST allow the application to control whether or not such filtering takes place.
実装では、そのようなフィルタリングが行われるかどうかをアプリケーションが制御できるようにする必要があります。
There are some constraint placed on the use of the DNS during transition. Most of these are obvious but are stated here for completeness.
移行中のDNSの使用にはいくつかの制約があります。これらのほとんどは明白ですが、完全を期すためにここで説明します。
The recommendation is that A6/AAAA records for a node should not be added to the DNS until all of these are true:
これらのすべてが当てはまるまで、ノードのA6 / AAAAレコードをDNSに追加しないことをお勧めします。
1) The address is assigned to the interface on the node.
1）アドレスはノードのインターフェースに割り当てられます。
2) The address is configured on the interface.
2）アドレスはインターフェースで設定されます。
3) The interface is on a link which is connected to the IPv6 infrastructure.
3）インターフェイスはIPv6インフラストラクチャに接続されているリンク上にあります。
If an IPv6 node is isolated from an IPv6 perspective (e.g. it is not connected to the 6bone to take a concrete example) constraint #3 would mean that it should not have an address in the DNS.
IPv6ノードがIPv6の観点から分離されている場合（たとえば、具体的な例を示すために6boneに接続されていない場合）制約＃3は、DNSにアドレスが含まれていないことを意味します。
This works great when other dual stack nodes tries to contact the isolated dual stack node. There is no IPv6 address in the DNS thus the peer doesn't even try communicating using IPv6 but goes directly to IPv4 (we are assuming both nodes have A records in the DNS.)
これは、他のデュアルスタックノードが分離されたデュアルスタックノードに接続しようとするときにうまく機能します。 DNSにはIPv6アドレスがないため、ピアはIPv6を使用して通信しようとはせず、直接IPv4に移動します（両方のノードがDNSにAレコードを持っていると想定しています）。
However, this does not work well when the isolated node is trying to establish communication. Even though it does not have an IPv6 address in the DNS it will find A6/AAAA records in the DNS for the peer. Since the isolated node has IPv6 addresses assigned to at least one interface it will try to communicate using IPv6. If it has no IPv6 route to the 6bone (e.g. because the local router was upgraded to advertise IPv6 addresses using Neighbor Discovery but that router doesn't have any IPv6 routes) this communication will fail. Typically this means a few minutes of delay as TCP times out. The TCP specification says that ICMP unreachable messages could be due to routing transients thus they should not immediately terminate the TCP connection. This means that the normal TCP timeout of a few minutes apply. Once TCP times out the application will hopefully try the IPv4 addresses based on the A records in the DNS, but this will be painfully slow.
ただし、分離されたノードが通信を確立しようとしている場合、これはうまく機能しません。 DNSにIPv6アドレスがない場合でも、ピアのDNSでA6 / AAAAレコードを検索します。分離されたノードには少なくとも1つのインターフェイスに割り当てられたIPv6アドレスがあるため、IPv6を使用して通信しようとします。 6boneへのIPv6ルートがない場合（たとえば、ローカルルーターが近隣探索を使用してIPv6アドレスをアドバタイズするようにアップグレードされたが、そのルーターにIPv6ルートがない場合）、この通信は失敗します。通常、これはTCPがタイムアウトするのに数分の遅延を意味します。 TCP仕様では、ICMP到達不能メッセージは一時的なルーティングが原因である可能性があるため、TCP接続をすぐに終了しないようにする必要があると記載されています。つまり、数分の通常のTCPタイムアウトが適用されます。 TCPがタイムアウトすると、アプリケーションはDNSのAレコードに基づいてIPv4アドレスを試すことができますが、これは非常に遅くなります。
A possible implication of the recommendations above is that, if one enables IPv6 on a node on a link without IPv6 infrastructure, and choose to add A6/AAAA records to the DNS for that node, then external IPv6 nodes that might see these A6/AAAA records will possibly try to reach that node using IPv6 and suffer delays or communication failure due to unreachability. (A delay is incurred if the application correctly falls back to using IPv4 if it can not establish communication using IPv6 addresses. If this fallback is not done the application would fail to communicate in this case.) Thus it is suggested that either the recommendations be followed, or care be taken to only do so with nodes that will not be impacted by external accessing delays and/or communication failure.
上記の推奨事項の考えられる影響は、IPv6インフラストラクチャのないリンク上のノードでIPv6を有効にし、そのノードのDNSにA6 / AAAAレコードを追加することを選択した場合、これらのA6 / AAAAを参照する可能性のある外部IPv6ノードレコードは、IPv6を使用してそのノードに到達しようとする可能性があり、到達不能による遅延または通信障害が発生します。 （IPv6アドレスを使用して通信を確立できない場合に、アプリケーションがIPv4の使用に正しくフォールバックすると、遅延が発生します。このフォールバックが行われない場合、この場合、アプリケーションは通信に失敗します。）したがって、次のいずれかの推奨事項を推奨します。または、外部アクセスの遅延や通信障害の影響を受けないノードでのみそうするように注意してください。
In the future when a site or node removes the support for IPv4 the above recommendations apply to when the A records for the node(s) should be removed from the DNS.
将来、サイトまたはノードがIPv4のサポートを削除すると、上記の推奨事項がノードのAレコードをDNSから削除する必要がある場合に適用されます。
In most deployment scenarios, the IPv6 routing infrastructure will be built up over time. While the IPv6 infrastructure is being deployed, the existing IPv4 routing infrastructure can remain functional, and can be used to carry IPv6 traffic. Tunneling provides a way to utilize an existing IPv4 routing infrastructure to carry IPv6 traffic.
ほとんどの展開シナリオでは、IPv6ルーティングインフラストラクチャは徐々に構築されます。 IPv6インフラストラクチャが展開されている間、既存のIPv4ルーティングインフラストラクチャは引き続き機能し、IPv6トラフィックの伝送に使用できます。トンネリングは、既存のIPv4ルーティングインフラストラクチャを利用してIPv6トラフィックを伝送する方法を提供します。
IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of IPv4 routing topology by encapsulating them within IPv4 packets. Tunneling can be used in a variety of ways:
IPv6 / IPv4ホストとルーターは、IPv4パケット内にカプセル化することにより、IPv4ルーティングトポロジの領域でIPv6データグラムをトンネリングできます。トンネリングはさまざまな方法で使用できます。
- Router-to-Router. IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans one segment of the end-to-end path that the IPv6 packet takes.
- ルーター間。 IPv4インフラストラクチャによって相互接続されたIPv6 / IPv4ルーターは、IPv6パケットをそれらの間でトンネリングできます。この場合、トンネルは、IPv6パケットが通過するエンドツーエンドパスの1つのセグメントにまたがります。
- Host-to-Router. IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4 router that is reachable via an IPv4 infrastructure. This type of tunnel spans the first segment of the packet's end-to-end path.
- ホストからルーター。 IPv6 / IPv4ホストは、IPv4インフラストラクチャを介して到達可能な中間IPv6 / IPv4ルーターにIPv6パケットをトンネルできます。このタイプのトンネルは、パケットのエンドツーエンドパスの最初のセグメントに広がります。
- Host-to-Host. IPv6/IPv4 hosts that are interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans the entire end-to-end path that the packet takes.
- ホストツーホスト。 IPv4インフラストラクチャによって相互接続されているIPv6 / IPv4ホストは、ホスト間でIPv6パケットをトンネリングできます。この場合、トンネルは、パケットが通過するエンドツーエンドパス全体に及びます。
- Router-to-Host. IPv6/IPv4 routers can tunnel IPv6 packets to their final destination IPv6/IPv4 host. This tunnel spans only the last segment of the end-to-end path.
- ルーターからホスト。 IPv6 / IPv4ルーターは、IPv6パケットを最終的な宛先IPv6 / IPv4ホストにトンネルできます。このトンネルは、エンドツーエンドパスの最後のセグメントだけに及びます。
Tunneling techniques are usually classified according to the mechanism by which the encapsulating node determines the address of the node at the end of the tunnel. In the first two tunneling methods listed above -- router-to-router and host-to-router -- the IPv6 packet is being tunneled to a router. The endpoint of this type of tunnel is an intermediary router which must decapsulate the IPv6 packet and forward it on to its final destination. When tunneling to a router, the endpoint of the tunnel is different from the destination of the packet being tunneled. So the addresses in the IPv6 packet being tunneled can not provide the IPv4 address of the tunnel endpoint. Instead, the tunnel endpoint address must be determined from configuration information on the node performing the tunneling. We use the term "configured tunneling" to describe the type of tunneling where the endpoint is explicitly configured.
トンネリング技術は通常、カプセル化ノードがトンネルの終わりにあるノードのアドレスを決定するメカニズムに従って分類されます。上記の最初の2つのトンネリング方法（ルーターからルーターおよびホストからルーター）では、IPv6パケットがルーターにトンネリングされます。このタイプのトンネルのエンドポイントは、IPv6パケットのカプセル化を解除して最終的な宛先に転送する必要がある中間ルーターです。ルータにトンネリングする場合、トンネルのエンドポイントは、トンネリングされるパケットの宛先とは異なります。そのため、トンネリングされるIPv6パケットのアドレスは、トンネルエンドポイントのIPv4アドレスを提供できません。代わりに、トンネルエンドポイントアドレスは、トンネリングを実行するノードの構成情報から決定する必要があります。 「構成済みトンネリング」という用語は、エンドポイントが明示的に構成されているトンネリングのタイプを表すために使用します。
In the last two tunneling methods -- host-to-host and router-to-host -- the IPv6 packet is tunneled all the way to its final destination. In this case, the destination address of both the IPv6 packet and the encapsulating IPv4 header identify the same node! This fact can be exploited by encoding information in the IPv6 destination address that will allow the encapsulating node to determine tunnel endpoint IPv4 address automatically. Automatic tunneling employs this technique, using an special IPv6 address format with an embedded IPv4 address to allow tunneling nodes to automatically derive the tunnel endpoint IPv4 address. This eliminates the need to explicitly configure the tunnel endpoint address, greatly simplifying configuration.
最後の2つのトンネリング方式（ホストからホストとルーターからホスト）では、IPv6パケットは最終的な宛先に至るまでトンネリングされます。この場合、IPv6パケットとカプセル化IPv4ヘッダーの両方の宛先アドレスが同じノードを識別します！この事実は、カプセル化ノードがトンネルエンドポイントIPv4アドレスを自動的に決定できるようにするIPv6宛先アドレスの情報をエンコードすることで利用できます。自動トンネリングはこの手法を採用し、IPv4アドレスが埋め込まれた特別なIPv6アドレス形式を使用して、トンネリングノードがトンネルエンドポイントIPv4アドレスを自動的に導出できるようにします。これにより、トンネルエンドポイントアドレスを明示的に構成する必要がなくなり、構成が大幅に簡素化されます。
The two tunneling techniques -- automatic and configured -- differ primarily in how they determine the tunnel endpoint address. Most of the underlying mechanisms are the same:
自動と設定の2つのトンネリング手法は、主にトンネルエンドポイントアドレスを決定する方法が異なります。基本的なメカニズムのほとんどは同じです：
- The entry node of the tunnel (the encapsulating node) creates an encapsulating IPv4 header and transmits the encapsulated packet.
- トンネルのエントリノード（カプセル化ノード）は、カプセル化IPv4ヘッダーを作成し、カプセル化されたパケットを送信します。
- The exit node of the tunnel (the decapsulating node) receives the encapsulated packet, reassembles the packet if needed, removes the IPv4 header, updates the IPv6 header, and processes the received IPv6 packet.
- トンネルの出口ノード（カプセル化解除ノード）は、カプセル化されたパケットを受信し、必要に応じてパケットを再構成し、IPv4ヘッダーを削除し、IPv6ヘッダーを更新し、受信したIPv6パケットを処理します。
- The encapsulating node MAY need to maintain soft state information for each tunnel recording such parameters as the MTU of the tunnel in order to process IPv6 packets forwarded into the tunnel. Since the number of tunnels that any one host or router may be using may grow to be quite large, this state information can be cached and discarded when not in use.
- カプセル化ノードは、トンネルに転送されたIPv6パケットを処理するために、トンネルのMTUなどのパラメータを記録する各トンネルのソフト状態情報を維持する必要があります。 1つのホストまたはルーターが使用している可能性のあるトンネルの数は非常に多くなる可能性があるため、この状態情報は使用していないときにキャッシュして破棄できます。
The remainder of this section discusses the common mechanisms that apply to both types of tunneling. Subsequent sections discuss how the tunnel endpoint address is determined for automatic and configured tunneling.
このセクションの残りの部分では、両方のタイプのトンネリングに適用される一般的なメカニズムについて説明します。以降のセクションでは、自動および構成済みトンネリング用にトンネルエンドポイントアドレスがどのように決定されるかについて説明します。
The encapsulation of an IPv6 datagram in IPv4 is shown below:
IPv4でのIPv6データグラムのカプセル化を以下に示します。
+-------------+
| IPv4 |
| Header |
+-------------+ +-------------+
| IPv6 | | IPv6 |
| Header | | Header |
+-------------+ +-------------+
| Transport | | Transport |
| Layer | ===> | Layer |
| Header | | Header |
+-------------+ +-------------+
| | | |
~ Data ~ ~ Data ~
| | | |
+-------------+ +-------------+
Encapsulating IPv6 in IPv4
IPv4でのIPv6のカプセル化
In addition to adding an IPv4 header, the encapsulating node also has to handle some more complex issues:
IPv4ヘッダーを追加することに加えて、カプセル化ノードはさらに複雑な問題を処理する必要があります。
- Determine when to fragment and when to report an ICMP "packet too big" error back to the source.
- フラグメント化するタイミングと、ICMPの「パケットが大きすぎる」エラーをソースに報告するタイミングを決定します。
- How to reflect IPv4 ICMP errors from routers along the tunnel path back to the source as IPv6 ICMP errors.
- トンネルパスに沿ったルーターからのIPv4 ICMPエラーをIPv6 ICMPエラーとしてソースに戻す方法。
Those issues are discussed in the following sections.
これらの問題については、次のセクションで説明します。
The encapsulating node could view encapsulation as IPv6 using IPv4 as a link layer with a very large MTU (65535-20 bytes to be exact; 20 bytes "extra" are needed for the encapsulating IPv4 header). The encapsulating node would need only to report IPv6 ICMP "packet too big" errors back to the source for packets that exceed this MTU. However, such a scheme would be inefficient for two reasons: 1) It would result in more fragmentation than needed. IPv4 layer fragmentation SHOULD be avoided due to the performance problems caused by the loss unit being smaller than the retransmission unit [11].
カプセル化ノードは、MTUが非常に大きいリンクレイヤーとしてIPv4を使用して、カプセル化をIPv6として表示できます（正確には65535〜20バイト。カプセル化IPv4ヘッダーには20バイトの「追加」が必要です）。カプセル化ノードは、このMTUを超えるパケットについて、IPv6 ICMPの「パケットが大きすぎる」エラーを送信元に報告するだけで済みます。ただし、このようなスキームは2つの理由で非効率的です。1）必要以上に断片化が発生します。損失単位が再送信単位よりも小さいために発生するパフォーマンスの問題のため、IPv4レイヤーの断片化は回避する必要があります[11]。
2) Any IPv4 fragmentation occurring inside the tunnel would have to be reassembled at the tunnel endpoint. For tunnels that terminate at a router, this would require additional memory to reassemble the IPv4 fragments into a complete IPv6 packet before that packet could be forwarded onward.
2）トンネル内で発生するIPv4フラグメンテーションは、トンネルエンドポイントで再構成する必要があります。ルーターで終端するトンネルの場合、パケットを転送する前に、IPv4フラグメントを完全なIPv6パケットに再構成するために追加のメモリが必要になります。
The fragmentation inside the tunnel can be reduced to a minimum by having the encapsulating node track the IPv4 Path MTU across the tunnel, using the IPv4 Path MTU Discovery Protocol [8] and recording the resulting path MTU. The IPv6 layer in the encapsulating node can then view a tunnel as a link layer with an MTU equal to the IPv4 path MTU, minus the size of the encapsulating IPv4 header.
カプセル化ノードにトンネル全体のIPv4パスMTUを追跡させ、IPv4パスMTU発見プロトコル[8]を使用して、結果のパスMTUを記録することにより、トンネル内の断片化を最小限に抑えることができます。カプセル化ノードのIPv6層は、IPv4パスMTUからカプセル化IPv4ヘッダーのサイズを引いた値に等しいMTUを持つリンク層としてトンネルを表示できます。
Note that this does not completely eliminate IPv4 fragmentation in the case when the IPv4 path MTU would result in an IPv6 MTU less than 1280 bytes. (Any link layer used by IPv6 has to have an MTU of at least 1280 bytes [4].) In this case the IPv6 layer has to "see" a link layer with an MTU of 1280 bytes and the encapsulating node has to use IPv4 fragmentation in order to forward the 1280 byte IPv6 packets.
これは、IPv4パスMTUの結果、IPv6 MTUが1280バイト未満になる場合にIPv4フラグメンテーションを完全になくすわけではないことに注意してください。 （IPv6で使用されるすべてのリンクレイヤーは、少なくとも1280バイトのMTUを持っている必要があります。） 1280バイトのIPv6パケットを転送するためのフラグメンテーション。
The encapsulating node can employ the following algorithm to determine when to forward an IPv6 packet that is larger than the tunnel's path MTU using IPv4 fragmentation, and when to return an IPv6 ICMP "packet too big" message:
カプセル化ノードは、次のアルゴリズムを使用して、IPv4フラグメンテーションを使用してトンネルのパスMTUより大きいIPv6パケットを転送するタイミングと、IPv6 ICMPの「パケットが大きすぎる」メッセージを返すタイミングを決定できます。
if (IPv4 path MTU - 20) is less than or equal to 1280
if packet is larger than 1280 bytes
Send IPv6 ICMP "packet too big" with MTU = 1280.
Drop packet.
else
Encapsulate but do not set the Don't Fragment
flag in the IPv4 header. The resulting IPv4
packet might be fragmented by the IPv4 layer on
the encapsulating node or by some router along
the IPv4 path.
endif
else
if packet is larger than (IPv4 path MTU - 20)
Send IPv6 ICMP "packet too big" with
MTU = (IPv4 path MTU - 20).
Drop packet.
else
Encapsulate and set the Don't Fragment flag in the IPv4 header. endif endif
カプセル化し、IPv4ヘッダーのフラグメントしないフラグを設定します。 endif endif
Encapsulating nodes that have a large number of tunnels might not be able to store the IPv4 Path MTU for all tunnels. Such nodes can, at the expense of additional fragmentation in the network, avoid using the IPv4 Path MTU algorithm across the tunnel and instead use the MTU of the link layer (under IPv4) in the above algorithm instead of the IPv4 path MTU.
トンネルの数が多いカプセル化ノードは、すべてのトンネルのIPv4パスMTUを格納できない場合があります。そのようなノードは、ネットワークでの追加の断片化を犠牲にして、トンネル全体でのIPv4パスMTUアルゴリズムの使用を回避し、代わりにIPv4パスMTUの代わりに上記のアルゴリズムでリンク層（IPv4の下）のMTUを使用できます。
In this case the Don't Fragment bit MUST NOT be set in the encapsulating IPv4 header.
この場合、カプセル化IPv4ヘッダーでDo n't Fragmentビットを設定しないでください。
IPv6-over-IPv4 tunnels are modeled as "single-hop". That is, the IPv6 hop limit is decremented by 1 when an IPv6 packet traverses the tunnel. The single-hop model serves to hide the existence of a tunnel. The tunnel is opaque to users of the network, and is not detectable by network diagnostic tools such as traceroute.
IPv6-over-IPv4トンネルは「シングルホップ」としてモデル化されます。つまり、IPv6ホップ制限は、IPv6パケットがトンネルを通過するときに1ずつ減少します。シングルホップモデルは、トンネルの存在を隠す役割を果たします。トンネルはネットワークのユーザーには不透明であり、tracerouteなどのネットワーク診断ツールでは検出できません。
The single-hop model is implemented by having the encapsulating and decapsulating nodes process the IPv6 hop limit field as they would if they were forwarding a packet on to any other datalink. That is, they decrement the hop limit by 1 when forwarding an IPv6 packet. (The originating node and final destination do not decrement the hop limit.)
シングルホップモデルは、カプセル化ノードとカプセル化解除ノードがIPv6ホップ制限フィールドを処理して、他のデータリンクにパケットを転送する場合と同じように実装されます。つまり、IPv6パケットを転送するときに、ホップ制限を1だけ減らします。 （発信元ノードと最終宛先は、ホップ制限を減少させません。）
The TTL of the encapsulating IPv4 header is selected in an implementation dependent manner. The current suggested value is published in the "Assigned Numbers RFC. Implementations MAY provide a mechanism to allow the administrator to configure the IPv4 TTL such as the one specified in the IP Tunnel MIB [17].
カプセル化IPv4ヘッダーのTTLは、実装に依存する方法で選択されます。現在の推奨値は、「割り当てられた番号のRFCで公開されています。実装は、管理者がIPトンネルMIB [17]で指定されているようなIPv4 TTLを構成できるようにするメカニズムを提供できます。
In response to encapsulated packets it has sent into the tunnel, the encapsulating node might receive IPv4 ICMP error messages from IPv4 routers inside the tunnel. These packets are addressed to the encapsulating node because it is the IPv4 source of the encapsulated packet.
カプセル化されたパケットがトンネルに送信した応答として、カプセル化ノードは、トンネル内のIPv4ルーターからIPv4 ICMPエラーメッセージを受信する場合があります。これらのパケットは、カプセル化されたパケットのIPv4ソースであるため、カプセル化ノードにアドレス指定されます。
The ICMP "packet too big" error messages are handled according to IPv4 Path MTU Discovery [8] and the resulting path MTU is recorded in the IPv4 layer. The recorded path MTU is used by IPv6 to determine if an IPv6 ICMP "packet too big" error has to be generated as described in section 3.2.
ICMPの「パケットが大きすぎます」エラーメッセージはIPv4パスMTU発見[8]に従って処理され、結果のパスMTUはIPv4レイヤーに記録されます。記録されたパスMTUはIPv6で使用され、セクション3.2で説明されているように、IPv6 ICMPの「パケットが大きすぎます」エラーを生成する必要があるかどうかを判断します。
The handling of other types of ICMP error messages depends on how much information is included in the "packet in error" field, which holds the encapsulated packet that caused the error.
他のタイプのICMPエラーメッセージの処理は、エラーの原因となったカプセル化されたパケットを保持する「エラーのパケット」フィールドに含まれる情報の量によって異なります。
Many older IPv4 routers return only 8 bytes of data beyond the IPv4 header of the packet in error, which is not enough to include the address fields of the IPv6 header. More modern IPv4 routers are likely to return enough data beyond the IPv4 header to include the entire IPv6 header and possibly even the data beyond that.
多くの古いIPv4ルーターは、エラーのあるパケットのIPv4ヘッダーを超えて8バイトのデータのみを返します。これは、IPv6ヘッダーのアドレスフィールドを含めるには不十分です。より最近のIPv4ルーターは、IPv4ヘッダーを超えて十分なデータを返し、IPv6ヘッダー全体、さらにはそれを超えるデータを返す可能性があります。
If the offending packet includes enough data, the encapsulating node MAY extract the encapsulated IPv6 packet and use it to generate an IPv6 ICMP message directed back to the originating IPv6 node, as shown below:
問題のパケットに十分なデータが含まれている場合、カプセル化ノードはカプセル化されたIPv6パケットを抽出して、以下に示すように、元のIPv6ノードに送信されるIPv6 ICMPメッセージを生成できます（MAY）。
+--------------+
| IPv4 Header |
| dst = encaps |
| node |
+--------------+
| ICMP |
| Header |
- - +--------------+
| IPv4 Header |
| src = encaps |
IPv4 | node |
+--------------+ - -
Packet | IPv6 |
| Header | Original IPv6
in +--------------+ Packet -
| Transport | Can be used to
Error | Header | generate an
+--------------+ IPv6 ICMP
| | error message
~ Data ~ back to the source.
| |
- - +--------------+ - -
IPv4 ICMP Error Message Returned to Encapsulating Node
カプセル化ノードに返されるIPv4 ICMPエラーメッセージ
When encapsulating an IPv6 packet in an IPv4 datagram, the IPv4 header fields are set as follows:
IPv6パケットをIPv4データグラムにカプセル化する場合、IPv4ヘッダーフィールドは次のように設定されます。
Version:
バージョン：
4
４
IP Header Length in 32-bit words:
32ビットワードのIPヘッダー長：
5 (There are no IPv4 options in the encapsulating header.)
5（カプセル化ヘッダーにIPv4オプションはありません。）
Type of Service:
サービスの種類：
0. [Note that work underway in the IETF is redefining the Type of Service byte and as a result future RFCs might define a different behavior for the ToS byte when tunneling.]
0. [IETFで進行中の作業はType of Serviceバイトの再定義であり、その結果、将来のRFCはトンネリング時にToSバイトの異なる動作を定義する可能性があることに注意してください。]
Total Length:
全長：
Payload length from IPv6 header plus length of IPv6 and IPv4 headers (i.e. a constant 60 bytes).
IPv6ヘッダーからのペイロードの長さと、IPv6およびIPv4ヘッダーの長さ（つまり、60バイトの定数）。
Identification:
識別：
Generated uniquely as for any IPv4 packet transmitted by the system.
システムによって送信されるIPv4パケットに関して一意に生成されます。
Flags:
フラグ：
Set the Don't Fragment (DF) flag as specified in section 3.2. Set the More Fragments (MF) bit as necessary if fragmenting.
セクション3.2で指定されているように、フラグメント禁止（DF）フラグを設定します。フラグメント化する場合は、必要に応じてMore Fragments（MF）ビットを設定します。
Fragment offset:
フラグメントオフセット：
Set as necessary if fragmenting.
断片化する場合は、必要に応じて設定してください。
Time to Live:
有効期間：
Set in implementation-specific manner.
実装固有の方法で設定します。
Protocol:
プロトコル：
41 (Assigned payload type number for IPv6)
41（IPv6の割り当てられたペイロードタイプ番号）
Header Checksum:
ヘッダーチェックサム：
Calculate the checksum of the IPv4 header.
IPv4ヘッダーのチェックサムを計算します。
Source Address:
送信元アドレス：
IPv4 address of outgoing interface of the encapsulating node.
カプセル化ノードの発信インターフェイスのIPv4アドレス。
Destination Address:
宛先アドレス：
IPv4 address of tunnel endpoint.
トンネルエンドポイントのIPv4アドレス。
Any IPv6 options are preserved in the packet (after the IPv6 header).
IPv6オプションはすべてパケットに保持されます（IPv6ヘッダーの後）。
When an IPv6/IPv4 host or a router receives an IPv4 datagram that is addressed to one of its own IPv4 address, and the value of the protocol field is 41, it reassembles if the packet if it is fragmented at the IPv4 level, then it removes the IPv4 header and submits the IPv6 datagram to its IPv6 layer code.
IPv6 / IPv4ホストまたはルーターが自身のIPv4アドレスの1つにアドレス指定されたIPv4データグラムを受信し、プロトコルフィールドの値が41の場合、IPv4レベルでフラグメント化されている場合、パケットは再構築され、その後IPv4ヘッダーを削除し、IPv6データグラムをそのIPv6レイヤーコードに送信します。
The decapsulating node MUST be capable of reassembling an IPv4 packet that is 1300 bytes (1280 bytes plus IPv4 header).
カプセル開放ノードは、1300バイト（1280バイトとIPv4ヘッダー）のIPv4パケットを再構成できる必要があります。
The decapsulation is shown below:
カプセル化解除を以下に示します。
+-------------+
| IPv4 |
| Header |
+-------------+ +-------------+
| IPv6 | | IPv6 |
| Header | | Header |
+-------------+ +-------------+
| Transport | | Transport |
| Layer | ===> | Layer |
| Header | | Header |
+-------------+ +-------------+
| | | |
~ Data ~ ~ Data ~
| | | |
+-------------+ +-------------+
Decapsulating IPv6 from IPv4
IPv4からのIPv6のカプセル化解除
When decapsulating the packet, the IPv6 header is not modified. [Note that work underway in the IETF is redefining the Type of Service byte and as a result future RFCs might define a different behavior for the ToS byte when decapsulating a tunneled packet.] If the packet is subsequently forwarded, its hop limit is decremented by one.
パケットのカプセル化を解除するとき、IPv6ヘッダーは変更されません。 [IETFで進行中の作業はType of Serviceバイトの再定義であり、その結果、将来のRFCはトンネルパケットのカプセル化解除時にToSバイトの異なる動作を定義する可能性があることに注意してください。]パケットがその後転送される場合、そのホップ制限は次のように減少します。 1。
As part of the decapsulation the node SHOULD silently discard a packet with an invalid IPv4 source address such as a multicast address, a broadcast address, 0.0.0.0, and 127.0.0.1. In general it SHOULD apply the rules for martian filtering in [18] and ingress filtering [13] on the IPv4 source address.
カプセル化解除の一部として、ノードは、マルチキャストアドレス、ブロードキャストアドレス、0.0.0.0、127.0.0.1などの無効なIPv4送信元アドレスを持つパケットをサイレントに破棄する必要があります（SHOULD）。一般に、[18]の火星フィルタリングとIPv4送信元アドレスの入力フィルタリング[13]のルールを適用する必要があります（SHOULD）。
The encapsulating IPv4 header is discarded.
カプセル化しているIPv4ヘッダーは破棄されます。
After the decapsulation the node SHOULD silently discard a packet with an invalid IPv6 source address. This includes IPv6 multicast addresses, the unspecified address, and the loopback address but also IPv4-compatible IPv6 source addresses where the IPv4 part of the address is an (IPv4) multicast address, broadcast address, 0.0.0.0, or 127.0.0.1. In general it SHOULD apply the rules for martian filtering in [18] and ingress filtering [13] on the IPv4-compatible source address.
カプセル化を解除した後、ノードは無効なIPv6送信元アドレスを持つパケットを静かに破棄する必要があります（SHOULD）。これには、IPv6マルチキャストアドレス、未指定アドレス、ループバックアドレスだけでなく、IPv4互換IPv6送信元アドレスも含まれます。アドレスのIPv4部分は、（IPv4）マルチキャストアドレス、ブロードキャストアドレス、0.0.0.0、または127.0.0.1です。一般的には、IPv4互換の送信元アドレスに[18]の火星フィルタリングと入力フィルタリング[13]のルールを適用する必要があります。
The decapsulating node performs IPv4 reassembly before decapsulating the IPv6 packet. All IPv6 options are preserved even if the encapsulating IPv4 packet is fragmented.
カプセル開放ノードは、IPv6パケットをカプセル開放する前にIPv4再構成を実行します。カプセル化IPv4パケットがフラグメント化されている場合でも、すべてのIPv6オプションが保持されます。
After the IPv6 packet is decapsulated, it is processed almost the same as any received IPv6 packet. The only difference being that a decapsulated packet MUST NOT be forwarded unless the node has been explicitly configured to forward such packets for the given IPv4 source address. This configuration can be implicit in e.g., having a configured tunnel which matches the IPv4 source address. This restriction is needed to prevent tunneling to be used as a tool to circumvent ingress filtering [13].
IPv6パケットのカプセル化が解除されると、受信したIPv6パケットとほぼ同じように処理されます。唯一の違いは、ノードが特定のIPv4送信元アドレスに対してそのようなパケットを転送するように明示的に構成されていない限り、カプセル化解除されたパケットは転送してはならないことです。この構成は、たとえば、IPv4送信元アドレスと一致する構成済みトンネルを持っている場合に暗黙的である可能性があります。この制限は、イングレスフィルタリングを回避するためのツールとして使用されるトンネリングを防ぐために必要です[13]。
Both the configured and automatic tunnels are IPv6 interfaces (over the IPv4 "link layer") thus MUST have link-local addresses. The link-local addresses are used by routing protocols operating over the tunnels.
構成済みトンネルと自動トンネルはどちらもIPv6インターフェース（IPv4「リンク層」を介する）であるため、リンクローカルアドレスが必要です。リンクローカルアドレスは、トンネル上で動作するルーティングプロトコルによって使用されます。
The Interface Identifier [14] for such an Interface SHOULD be the 32-bit IPv4 address of that interface, with the bytes in the same order in which they would appear in the header of an IPv4 packet, padded at the left with zeros to a total of 64 bits. Note that the
そのようなインターフェースのインターフェース識別子[14]は、そのインターフェースの32ビットIPv4アドレスである必要があり、バイトは、IPv4パケットのヘッダーに表示されるのと同じ順序で、左側にゼロが埋め込まれます。合計64ビット。ことに注意してください
"Universal/Local" bit is zero, indicating that the Interface Identifier is not globally unique. When the host has more than one IPv4 address in use on the physical interface concerned, an administrative choice of one of these IPv4 addresses is made.
「ユニバーサル/ローカル」ビットはゼロであり、インターフェイス識別子がグローバルに一意ではないことを示します。ホストが関連する物理インターフェイス上で複数のIPv4アドレスを使用している場合、これらのIPv4アドレスの1つを管理上選択します。
The IPv6 Link-local address [14] for an IPv4 virtual interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64.
IPv4仮想インターフェースのIPv6リンクローカルアドレス[14]は、上記で定義したインターフェース識別子を接頭辞FE80 :: / 64に追加することによって形成されます。
+-------+-------+-------+-------+-------+-------+------+------+
| FE 80 00 00 00 00 00 00 |
+-------+-------+-------+-------+-------+-------+------+------+
| 00 00 | 00 | 00 | IPv4 Address |
+-------+-------+-------+-------+-------+-------+------+------+
Automatic tunnels and unidirectional configured tunnels are considered to be unidirectional. Thus the only aspects of Neighbor Discovery [7] and Stateless Address Autoconfiguration [5] that apply to these tunnels is the formation of the link-local address.
自動トンネルおよび単方向構成トンネルは、単方向と見なされます。したがって、これらのトンネルに適用される近隣探索[7]とステートレスアドレス自動構成[5]の唯一の側面は、リンクローカルアドレスの形成です。
If an implementation provides bidirectional configured tunnels it MUST at least accept and respond to the probe packets used by Neighbor Unreachability Detection [7]. Such implementations SHOULD also send NUD probe packets to detect when the configured tunnel fails at which point the implementation can use an alternate path to reach the destination. Note that Neighbor Discovery allows that the sending of NUD probes be omitted for router to router links if the routing protocol tracks bidirectional reachability.
実装が双方向に構成されたトンネルを提供する場合、少なくとも近隣到達不能検出[7]で使用されるプローブパケットを受け入れて応答する必要があります。そのような実装は、NUDプローブパケットを送信して、設定されたトンネルが失敗したときに検出することもできます。近隣探索では、ルーティングプロトコルが双方向の到達可能性を追跡する場合、ルーター間リンクのNUDプローブの送信を省略できることに注意してください。
For the purposes of Neighbor Discovery the automatic and configured tunnels specified in this document as assumed to NOT have a link-layer address, even though the link-layer (IPv4) does have address. This means that a sender of Neighbor Discovery packets
近隣探索の目的のために、リンク層（IPv4）がアドレスを持っている場合でも、このドキュメントで指定されている自動構成されたトンネルはリンク層アドレスを持たないと想定されています。これは、近隣探索パケットの送信者が
- SHOULD NOT include Source Link Layer Address options or Target Link Layer Address options on the tunnel link.
- トンネルリンクにソースリンクレイヤーアドレスオプションまたはターゲットリンクレイヤーアドレスオプションを含めないでください。
- MUST silently ignore any received SLLA or TLLA options on the tunnel link.
- トンネルリンクで受信したSLLAオプションまたはTLLAオプションを通知なく無視する必要があります。
In configured tunneling, the tunnel endpoint address is determined from configuration information in the encapsulating node. For each tunnel, the encapsulating node must store the tunnel endpoint address. When an IPv6 packet is transmitted over a tunnel, the tunnel endpoint address configured for that tunnel is used as the destination address for the encapsulating IPv4 header.
構成済みトンネリングでは、トンネルエンドポイントアドレスは、カプセル化ノードの構成情報から決定されます。トンネルごとに、カプセル化ノードはトンネルエンドポイントアドレスを格納する必要があります。 IPv6パケットがトンネルを介して送信される場合、そのトンネル用に構成されたトンネルエンドポイントアドレスは、カプセル化IPv4ヘッダーの宛先アドレスとして使用されます。
The determination of which packets to tunnel is usually made by routing information on the encapsulating node. This is usually done via a routing table, which directs packets based on their destination address using the prefix mask and match technique.
トンネリングするパケットの決定は、通常、カプセル化ノードのルーティング情報によって行われます。これは通常、ルーティングテーブルを介して行われます。ルーティングテーブルは、プレフィックスマスクと一致技術を使用して、宛先アドレスに基づいてパケットを転送します。
IPv6/IPv4 hosts that are connected to datalinks with no IPv6 routers MAY use a configured tunnel to reach an IPv6 router. This tunnel allows the host to communicate with the rest of the IPv6 Internet (i.e. nodes with IPv6-native addresses). If the IPv4 address of an IPv6/IPv4 router bordering the IPv6 backbone is known, this can be used as the tunnel endpoint address. This tunnel can be configured into the routing table as an IPv6 "default route". That is, all IPv6 destination addresses will match the route and could potentially traverse the tunnel. Since the "mask length" of such a default route is zero, it will be used only if there are no other routes with a longer mask that match the destination. The default configured tunnel can be used in conjunction with automatic tunneling, as described in section 5.4.
IPv6ルーターのないデータリンクに接続されているIPv6 / IPv4ホストは、構成されたトンネルを使用してIPv6ルーターに到達する場合があります。このトンネルにより、ホストはIPv6インターネットの残りの部分（つまり、IPv6ネイティブアドレスを持つノード）と通信できます。 IPv6バックボーンに隣接するIPv6 / IPv4ルーターのIPv4アドレスがわかっている場合、これをトンネルエンドポイントアドレスとして使用できます。このトンネルは、IPv6の「デフォルトルート」としてルーティングテーブルに設定できます。つまり、すべてのIPv6宛先アドレスがルートと一致し、トンネルを通過する可能性があります。そのようなデフォルトルートの「マスク長」はゼロであるため、宛先と一致するより長いマスクを持つ他のルートがない場合にのみ使用されます。セクション5.4で説明されているように、デフォルト設定のトンネルは自動トンネリングと組み合わせて使用できます。
The tunnel endpoint address of such a default tunnel could be the IPv4 address of one IPv6/IPv4 router at the border of the IPv6 backbone. Alternatively, the tunnel endpoint could be an IPv4 "anycast address". With this approach, multiple IPv6/IPv4 routers at the border advertise IPv4 reachability to the same IPv4 address. All of these routers accept packets to this address as their own, and will decapsulate IPv6 packets tunneled to this address. When an IPv6/IPv4 node sends an encapsulated packet to this address, it will be delivered to only one of the border routers, but the sending node will not know which one. The IPv4 routing system will generally carry the traffic to the closest router.
このようなデフォルトトンネルのトンネルエンドポイントアドレスは、IPv6バックボーンの境界にある1つのIPv6 / IPv4ルーターのIPv4アドレスにすることができます。または、トンネルエンドポイントはIPv4の「エニーキャストアドレス」にすることもできます。このアプローチでは、境界にある複数のIPv6 / IPv4ルーターが同じIPv4アドレスへのIPv4到達可能性を通知します。これらのルーターはすべて、このアドレスへのパケットを独自のものとして受け入れ、このアドレスにトンネルされるIPv6パケットのカプセル化を解除します。 IPv6 / IPv4ノードがカプセル化されたパケットをこのアドレスに送信すると、それは境界ルーターの1つだけに配信されますが、送信ノードはどちらを認識するかはわかりません。 IPv4ルーティングシステムは通常、最も近いルーターにトラフィックを伝送します。
Using a default tunnel to an IPv4 "anycast address" provides a high degree of robustness since multiple border router can be provided, and, using the normal fallback mechanisms of IPv4 routing, traffic will automatically switch to another router when one goes down. However, care must be taking when using such a default tunnel to prevent different IPv4 fragments from arriving at different routers for reassembly. This can be prevented by either avoiding fragmentation of the encapsulated packets (by ensuring an IPv4 MTU of at least 1300 bytes) or by preventing frequent changes to IPv4 routing.
IPv4の「エニーキャストアドレス」へのデフォルトトンネルを使用すると、複数の境界ルーターを提供できるため、高度な堅牢性が提供されます。IPv4ルーティングの通常のフォールバックメカニズムを使用すると、トラフィックがダウンすると、トラフィックは自動的に別のルーターに切り替わります。ただし、このようなデフォルトトンネルを使用する場合は、再構築のために異なるルーターに異なるIPv4フラグメントが到達しないように注意する必要があります。これは、カプセル化されたパケットの断片化を回避する（IPv4 MTUを少なくとも1300バイト確保する）か、またはIPv4ルーティングへの頻繁な変更を防止することによって防止できます。
The decapsulating node MUST verify that the tunnel source address is acceptable before forwarding decapsulated packets to avoid circumventing ingress filtering [13]. Note that packets which are delivered to transport protocols on the decapsulating node SHOULD NOT be subject to these checks. For bidirectional configured tunnels this is done by verifying that the source address is the IPv4 address of the other end of the tunnel. For unidirectional configured tunnels the decapsulating node MUST be configured with a list of source IPv4 address prefixes that are acceptable. Such a list MUST default to not having any entries i.e. the node has to be explicitly configured to forward decapsulated packets received over unidirectional configured tunnels.
カプセル化解除ノードは、カプセル化解除されたパケットを転送する前に、トンネル送信元アドレスが受け入れ可能であることを確認して、入力フィルタリングの迂回を回避する必要があります[13]。カプセル開放ノードのトランスポートプロトコルに配信されるパケットは、これらのチェックの対象にならないことに注意してください。双方向構成のトンネルの場合、これは、送信元アドレスがトンネルのもう一方の端のIPv4アドレスであることを確認することによって行われます。単方向構成のトンネルの場合、カプセル化解除ノードは、受け入れ可能なソースIPv4アドレスプレフィックスのリストを使用して構成する必要があります。このようなリストは、デフォルトではエントリを持たないようにする必要があります。つまり、ノードは、単方向構成のトンネルを介して受信したカプセル化解除されたパケットを転送するように明示的に構成する必要があります。
In automatic tunneling, the tunnel endpoint address is determined by the IPv4-compatible destination address of the IPv6 packet being tunneled. Automatic tunneling allows IPv6/IPv4 nodes to communicate over IPv4 routing infrastructures without pre-configuring tunnels.
自動トンネリングでは、トンネルエンドポイントアドレスは、トンネリングされるIPv6パケットのIPv4互換宛先アドレスによって決定されます。自動トンネリングにより、IPv6 / IPv4ノードはトンネルを事前に構成しなくてもIPv4ルーティングインフラストラクチャを介して通信できます。
IPv6/IPv4 nodes that perform automatic tunneling are assigned IPv4- compatible address. An IPv4-compatible address is identified by an all-zeros 96-bit prefix, and holds an IPv4 address in the low-order 32-bits. IPv4-compatible addresses are structured as follows:
自動トンネリングを実行するIPv6 / IPv4ノードには、IPv4互換アドレスが割り当てられます。 IPv4互換アドレスは、すべてゼロの96ビットプレフィックスで識別され、下位32ビットでIPv4アドレスを保持します。 IPv4互換アドレスは次のように構成されています。
| 96-bits | 32-bits |
+--------------------------------------+--------------+
| 0:0:0:0:0:0 | IPv4 Address |
+--------------------------------------+--------------+
IPv4-Compatible IPv6 Address Format
IPv4-compatible addresses are assigned exclusively to nodes that support automatic tunneling. A node SHOULD be configured with an IPv4-compatible address only if it is prepared to accept IPv6 packets destined to that address encapsulated in IPv4 packets destined to the embedded IPv4 address.
IPv4互換アドレスは、自動トンネリングをサポートするノードにのみ割り当てられます。ノードは、埋め込まれたIPv4アドレス宛てのIPv4パケットにカプセル化された、そのアドレス宛てのIPv6パケットを受け入れる準備ができている場合にのみ、IPv4互換アドレスで構成する必要があります。
An IPv4-compatible address is globally unique as long as the IPv4 address is not from the private IPv4 address space [15]. An implementation SHOULD behave as if its IPv4-compatible address(es) are assigned to the node's automatic tunneling interface, even if the implementation does not implement automatic tunneling using a concept of interfaces. Thus the IPv4-compatible address SHOULD NOT be viewed as being attached to e.g. an Ethernet interface i.e. implications should not use the Neighbor Discovery mechanisms like NUD [7] at the Ethernet. Any such interactions should be done using the encapsulated packets i.e. over the automatic tunneling (conceptual) interface.
IPv4互換アドレスは、IPv4アドレスがプライベートIPv4アドレス空間からのものでない限り、グローバルに一意です[15]。実装は、インターフェイスの概念を使用して自動トンネリングを実装していない場合でも、IPv4互換アドレスがノードの自動トンネリングインターフェイスに割り当てられているかのように動作する必要があります（SHOULD）。したがって、IPv4互換アドレスは、たとえば、イーサネットインターフェイス、つまり、イーサネットでNUD [7]のような近隣探索メカニズムを使用しないでください。そのような相互作用は、カプセル化されたパケットを使用して、つまり自動トンネリング（概念）インターフェースを介して行う必要があります。
An IPv6/IPv4 node with an IPv4-compatible address uses that address as one of its IPv6 addresses, while the IPv4 address embedded in the low-order 32-bits serves as the IPv4 address for one of its interfaces.
IPv4互換アドレスを持つIPv6 / IPv4ノードは、そのアドレスをそのIPv6アドレスの1つとして使用しますが、下位32ビットに埋め込まれたIPv4アドレスは、そのインターフェースの1つのIPv4アドレスとして機能します。
An IPv6/IPv4 node MAY acquire its IPv4-compatible IPv6 addresses via IPv4 address configuration protocols. It MAY use any IPv4 address configuration mechanism to acquire its IPv4 address, then "map" that address into an IPv4-compatible IPv6 address by pre-pending it with the 96-bit prefix 0:0:0:0:0:0. This mode of configuration allows IPv6/IPv4 nodes to "leverage" the installed base of IPv4 address configuration servers.
IPv6 / IPv4ノードは、IPv4アドレス構成プロトコルを介してIPv4互換IPv6アドレスを取得してもよい（MAY）。任意のIPv4アドレス構成メカニズムを使用してIPv4アドレスを取得し、96ビットのプレフィックス0：0：0：0：0：0を前に付加することにより、そのアドレスをIPv4互換IPv6アドレスに「マッピング」できます。この構成モードでは、IPv6 / IPv4ノードがIPv4アドレス構成サーバーのインストール済みベースを「活用」できます。
The specific algorithm for acquiring an IPv4-compatible address using IPv4-based address configuration protocols is as follows:
IPv4ベースのアドレス構成プロトコルを使用してIPv4互換アドレスを取得するための特定のアルゴリズムは、次のとおりです。
1) The IPv6/IPv4 node uses standard IPv4 mechanisms or protocols to acquire the IPv4 address for one of its interfaces. These include:
1）IPv6 / IPv4ノードは、標準のIPv4メカニズムまたはプロトコルを使用して、そのインターフェースの1つのIPv4アドレスを取得します。これらには以下が含まれます：
- The Dynamic Host Configuration Protocol (DHCP) [2]
- 動的ホスト構成プロトコル（DHCP）[2]
- The Bootstrap Protocol (BOOTP) [1]
- ブートストラッププロトコル（BOOTP）[1]
- The Reverse Address Resolution Protocol (RARP) [9]
- 逆アドレス解決プロトコル（RARP）[9]
- Manual configuration
- 手動設定
- Any other mechanism which accurately yields the node's own IPv4 address
- ノード自身のIPv4アドレスを正確に生成するその他のメカニズム
2) The node uses this address as the IPv4 address for this interface.
2）ノードはこのアドレスをこのインターフェースのIPv4アドレスとして使用します。
3) The node prepends the 96-bit prefix 0:0:0:0:0:0 to the 32-bit IPv4 address that it acquired in step (1). The result is an IPv4- compatible IPv6 address with one of the node's IPv4-addresses embedded in the low-order 32-bits. The node uses this address as one of its IPv6 addresses.
3）ノードは、ステップ（1）で取得した32ビットのIPv4アドレスの前に、96ビットのプレフィックス0：0：0：0：0：0を付加します。結果は、下位32ビットに埋め込まれたノードのIPv4-アドレスの1つを持つIPv4互換IPv6アドレスです。ノードはこのアドレスをIPv6アドレスの1つとして使用します。
In automatic tunneling, the tunnel endpoint address is determined from the packet being tunneled. If the destination IPv6 address is IPv4-compatible, then the packet can be sent via automatic tunneling. If the destination is IPv6-native, the packet can not be sent via automatic tunneling.
自動トンネリングでは、トンネルエンドポイントアドレスは、トンネリングされるパケットから決定されます。宛先IPv6アドレスがIPv4互換である場合、パケットは自動トンネリングを介して送信できます。宛先がIPv6ネイティブの場合、パケットは自動トンネリング経由で送信できません。
A routing table entry can be used to direct automatic tunneling. An implementation can have a special static routing table entry for the prefix 0:0:0:0:0:0/96. (That is, a route to the all-zeros prefix with a 96-bit mask.) Packets that match this prefix are sent to a pseudo-interface driver which performs automatic tunneling. Since all IPv4-compatible IPv6 addresses will match this prefix, all packets to those destinations will be auto-tunneled.
ルーティングテーブルエントリを使用して、自動トンネリングを指示できます。実装には、プレフィックス0：0：0：0：0：0/96の特別な静的ルーティングテーブルエントリを含めることができます。 （つまり、96ビットマスクのすべて0のプレフィックスへのルート。）このプレフィックスに一致するパケットは、自動トンネリングを実行する疑似インターフェイスドライバーに送信されます。すべてのIPv4互換IPv6アドレスがこのプレフィックスと一致するため、それらの宛先へのすべてのパケットは自動トンネリングされます。
Once it is delivered to the automatic tunneling module, the IPv6 packet is encapsulated within an IPv4 header according to the rules described in section 3. The source and destination addresses of the encapsulating IPv4 header are assigned as follows:
自動トンネリングモジュールに配信されると、IPv6パケットは、セクション3で説明したルールに従ってIPv4ヘッダー内にカプセル化されます。カプセル化するIPv4ヘッダーの送信元アドレスと宛先アドレスは、次のように割り当てられます。
Destination IPv4 address:
宛先IPv4アドレス：
Low-order 32-bits of IPv6 destination address
IPv6宛先アドレスの下位32ビット
Source IPv4 address:
ソースIPv4アドレス：
IPv4 address of interface the packet is sent via
パケットが送信されるインターフェースのIPv4アドレス
The automatic tunneling module always sends packets in this encapsulated form, even if the destination is on an attached datalink.
自動トンネリングモジュールは、宛先が接続されたデータリンク上にある場合でも、常にこのカプセル化された形式でパケットを送信します。
The automatic tunneling module MUST NOT send to IPv4 broadcast or multicast destinations. It MUST drop all IPv6 packets destined to IPv4-compatible destinations when the embedded IPv4 address is broadcast, multicast, the unspecified (0.0.0.0) address, or the loopback address (127.0.0.1). Note that the sender can only tell if an address is a network or subnet broadcast for broadcast addresses assigned to directly attached links.
自動トンネリングモジュールは、IPv4ブロードキャストまたはマルチキャストの宛先に送信してはいけません。埋め込まれたIPv4アドレスがブロードキャスト、マルチキャスト、未指定（0.0.0.0）アドレス、またはループバックアドレス（127.0.0.1）である場合、IPv4互換の宛先を宛先とするすべてのIPv6パケットをドロップする必要があります。送信者は、アドレスが、直接接続されたリンクに割り当てられたブロードキャストアドレスのネットワークまたはサブネットブロードキャストであるかどうかしか判別できないことに注意してください。
Automatic tunneling is often used in conjunction with the default configured tunnel technique. "Isolated" IPv6/IPv4 hosts -- those with no on-link IPv6 routers -- are configured to use automatic tunneling and IPv4-compatible IPv6 addresses, and have at least one default configured tunnel to an IPv6 router. That IPv6 router is configured to perform automatic tunneling as well. These isolated hosts send packets to IPv4-compatible destinations via automatic tunneling and packets for IPv6-native destinations via the default configured tunnel. IPv4-compatible destinations will match the 96- bit all-zeros prefix route discussed in the previous section, while IPv6-native destinations will match the default route via the configured tunnel. Reply packets from IPv6-native destinations are routed back to the an IPv6/IPv4 router which delivers them to the original host via automatic tunneling. Further examples of the combination of tunneling techniques are discussed in [12].
自動トンネリングは、多くの場合、デフォルトの設定済みトンネルテクニックと組み合わせて使用されます。 「分離された」IPv6 / IPv4ホスト（リンク上にIPv6ルーターがないホスト）は、自動トンネリングとIPv4互換IPv6アドレスを使用するように構成されており、IPv6ルーターへのデフォルトのトンネルが少なくとも1つ構成されています。そのIPv6ルーターは、自動トンネリングも実行するように構成されています。これらの分離されたホストは、自動トンネリングを介してIPv4互換の宛先にパケットを送信し、デフォルトの構成済みトンネルを介してIPv6ネイティブ宛先のパケットを送信します。 IPv4互換の宛先は、前のセクションで説明した96ビットのすべて0のプレフィックスルートと一致しますが、IPv6ネイティブの宛先は、構成されたトンネルを介したデフォルトルートと一致します。 IPv6ネイティブの宛先からの応答パケットは、IPv6 / IPv4ルーターにルーティングされ、自動トンネリングを介して元のホストに配信されます。トンネリング技術の組み合わせのさらなる例は、[12]で説明されています。
When an IPv6/IPv4 node originates an IPv6 packet, it must select the source IPv6 address to use. IPv6/IPv4 nodes that are configured to perform automatic tunneling may be configured with global IPv6-native addresses as well as IPv4-compatible addresses. The selection of which source address to use will determine what form the return traffic is sent via. If the IPv4-compatible address is used, the return traffic will have to be delivered via automatic tunneling, but if the IPv6-native address is used, the return traffic will not be automatic-tunneled. In order to make traffic as symmetric as possible, the following source address selection preference is RECOMMENDED:
IPv6 / IPv4ノードがIPv6パケットを発信するとき、使用するソースIPv6アドレスを選択する必要があります。自動トンネリングを実行するように構成されているIPv6 / IPv4ノードは、グローバルIPv6ネイティブアドレスとIPv4互換アドレスで構成できます。どの送信元アドレスを使用するかを選択することで、リターントラフィックの送信形態が決まります。 IPv4互換アドレスを使用する場合、戻りトラフィックは自動トンネリングを介して配信する必要がありますが、IPv6ネイティブアドレスを使用する場合、戻りトラフィックは自動トンネリングされません。トラフィックをできるだけ対称にするために、次の送信元アドレス選択設定をお勧めします。
Destination is IPv4-compatible:
宛先はIPv4互換です。
Use IPv4-compatible source address associated with IPv4 address of outgoing interface
発信インターフェイスのIPv4アドレスに関連付けられたIPv4互換の送信元アドレスを使用する
Destination is IPv6-native:
宛先はIPv6ネイティブです。
Use IPv6-native address of outgoing interface
発信インターフェイスのIPv6ネイティブアドレスを使用する
If an IPv6/IPv4 node has no global IPv6-native address, but is originating a packet to an IPv6-native destination, it MAY use its IPv4-compatible address as its source address.
IPv6 / IPv4ノードがグローバルIPv6-nativeアドレスを持たないが、IPv6-native宛先へのパケットを発信している場合、そのIPv4互換アドレスを送信元アドレスとして使用してもよい（MAY）。
The decapsulating node MUST verify that the encapsulated packets are acceptable before forwarding decapsulated packets to avoid circumventing ingress filtering [13]. Note that packets which are delivered to transport protocols on the decapsulating node SHOULD NOT be subject to these checks. Since automatic tunnels always encapsulate to the destination (i.e. the IPv4 destination will be the destination) any packet received over an automatic tunnel SHOULD NOT be forwarded.
カプセル開放ノードは、イングレスフィルタリングの回避を回避するために、カプセル開放されたパケットを転送する前に、カプセル化されたパケットが受け入れ可能であることを確認する必要があります[13]。カプセル開放ノードのトランスポートプロトコルに配信されるパケットは、これらのチェックの対象にならないことに注意してください。自動トンネルは常に宛先にカプセル化されるため（つまり、IPv4宛先が宛先になります）、自動トンネルを介して受信されたパケットは転送されるべきではありません（SHOULD NOT）。
We would like to thank the members of the IPng working group and the Next Generation Transition (ngtrans) working group for their many contributions and extensive review of this document. Special thanks are due to Jim Bound, Ross Callon, and Bob Hinden for many helpful suggestions and to John Moy for suggesting the IPv4 "anycast address" default tunnel technique.
IPngワーキンググループとNext Generation Transition（ngtrans）ワーキンググループのメンバーに、このドキュメントに対する多くの貢献と広範なレビューを提供していただき、ありがとうございます。多くの役立つ提案をしてくれたJim Bound、Ross Callon、Bob Hindenに感謝し、IPv4の「エニーキャストアドレス」のデフォルトトンネル技術を提案してくれたJohn Moyに感謝します。
Tunneling is not known to introduce any security holes except for the possibility to circumvent ingress filtering [13]. This is prevented by requiring that decapsulating routers only forward packets if they have been configured to accept encapsulated packets from the IPv4 source address in the receive packet. Additionally, in the case of automatic tunneling, nodes are required by not forwarding the decapsulated packets since automatic tunneling ends the tunnel and the destination.
進入フィルタリングを回避する可能性を除いて、トンネリングがセキュリティホールをもたらすことは知られていない[13]。これは、受信パケットのIPv4送信元アドレスからカプセル化されたパケットを受け入れるように構成されている場合にのみ、カプセル化解除ルーターがパケットを転送することを要求することで防止されます。さらに、自動トンネリングの場合、自動トンネリングによってトンネルと宛先が終了するため、カプセル化解除されたパケットを転送しないようにする必要があります。
Robert E. Gilligan FreeGate Corp 1208 E. Arques Ave Sunnyvale, CA 94086 USA
Robert E. Gilligan FreeGate Corp 1208 E. Arques Ave Sunnyvale、CA 94086 USA
Phone: +1-408-617-1004
Fax: +1-408-617-1010
EMail: gilligan@freegate.com
Erik Nordmark Sun Microsystems, Inc. 901 San Antonio Rd. Palo Alto, CA 94303 USA
Erik Nordmark Sun Microsystems、Inc. 901 San Antonio Rd。パロアルト、カリフォルニア州94303米国
Phone: +1-650-786-5166
Fax: +1-650-786-5896
EMail: nordmark@eng.sun.com
[1] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[1] Croft、W.およびJ. Gilmore、「Bootstrap Protocol」、RFC 951、1985年9月。
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, October 1993.
[2] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 1541、1993年10月。
[3] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[3] Carpenter、B。およびC. Jung、「明示的なトンネルのないIPv4ドメインを介したIPv6の転送」、RFC 2529、1999年3月。
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[4] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[5] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration," RFC 2462, December 1998.
[5] Thomson、S.およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[6] Crawford, M., Thomson, S., and C. Huitema. "DNS Extensions to Support IPv6 Address Allocation and Renumbering", RFC 2874, July 2000.
[6] Crawford、M.、Thomson、S。、およびC. Huitema。 「IPv6アドレスの割り当てと再番号付けをサポートするDNS拡張機能」、RFC 2874、2000年7月。
[7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[7] Narten、T.、Nordmark、E。およびW. Simpson、「Neighbor Discovery for IP Version 6（IPv6）」、RFC 2461、1998年12月。
[8] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[8] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[9] Finlayson, R., Mann, T., Mogul, J. and M. Theimer, "Reverse Address Resolution Protocol", STD 38, RFC 903, June 1984.
[9] Finlayson、R.、Mann、T.、Mogul、J. and M. Theimer、 "Reverse Address Resolution Protocol"、STD 38、RFC 903、June 1984。
[10] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[10] ブレーデン、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[11] Kent, C. and J. Mogul, "Fragmentation Considered Harmful". In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology. August 1987.
[11] ケントC.およびJ.モーグル、「フラグメンテーションは有害と見なされる」。手続き中コンピュータ通信技術のフロンティアに関するSIGCOMM '87ワークショップ。 1987年8月。
[12] Callon, R. and D. Haskin, "Routing Aspects of IPv6 Transition", RFC 2185, September 1997.
[12] Callon、R。およびD. Haskin、「IPv6移行のルーティングの側面」、RFC 2185、1997年9月。
[13] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, January 1998.
[13] ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の打破」、RFC 2267、1998年1月。
[14] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[14] Hinden、R. and S. Deering、「IP Version 6 Addressing Architecture」、RFC 2373、1998年7月。
[15] Rechter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[15] Rechter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G.J。 E.リア、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[16] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[16] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[17] Thaler, D., "IP Tunnel MIB", RFC 2667, August 1999.
[17] ターラー、D。、「IPトンネルMIB」、RFC 2667、1999年8月。
[18] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[18] ベイカー、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
- Deleted section 3.1.1 (IPv4 loopback address) in order to prevent it from being mis-construed as requiring routers to filter the address ::127.0.0.1, which would put another test in the forwarding path for IPv6 routers.
- セクション3.1.1（IPv4ループバックアドレス）を削除して、ルーターがアドレス:: 127.0.0.1をフィルターする必要があると誤解されないようにして、IPv6ルーターの転送パスに別のテストを配置しました。
- Deleted section 4.4 (Default Sending Algorithm). This section allowed nodes to send packets in "raw form" to IPv4-compatible destinations on the same datalink. Implementation experience has shown that this adds complexity which is not justified by the minimal savings in header overhead.
- セクション4.4（デフォルトの送信アルゴリズム）を削除しました。このセクションにより、ノードはパケットを「生の形式」で同じデータリンク上のIPv4互換の宛先に送信できました。実装の経験から、これにより複雑さが増すことが示されていますが、これはヘッダーのオーバーヘッドの最小の節約では正当化されません。
- Added definitions for operating modes for IPv6/IPv4 nodes.
- IPv6 / IPv4ノードの動作モードの定義を追加しました。
- Revised DNS section to clarify resolver filtering and ordering options.
- DNSセクションを改訂して、リゾルバーのフィルタリングと順序付けのオプションを明確にしました。
- Re-wrote the discussion of IPv4-compatible addresses to clarify that they are used exclusively in conjunction with the automatic tunneling mechanism. Re-organized document to place definition of IPv4-compatible address format with description of automatic tunneling.
- IPv4互換アドレスの説明を書き直して、自動トンネリングメカニズムと組み合わせてのみ使用されることを明確にしました。自動トンネリングの説明を含むIPv4互換アドレス形式の定義を配置するためにドキュメントを再編成しました。
- Changed the term "IPv6-only address" to "IPv6-native address" per current usage.
- 現在の使用量ごとに「IPv6専用アドレス」という用語を「IPv6ネイティブアドレス」に変更しました。
- Updated to algorithm for determining tunnel MTU to reflect the change in the IPv6 minimum MTU from 576 to 1280 bytes [4].
- IPv6最小MTUの576バイトから1280バイトへの変更を反映するようにトンネルMTUを決定するアルゴリズムに更新されました[4]。
- Deleted the definition for the term "IPv6-in-IPv4 encapsulation." It has not been widely used.
- 「IPv6-in-IPv4カプセル化」という用語の定義を削除しました。それは広く使用されていません。
- Revised IPv4-compatible address configuration section (5.2) to recognize multiple interfaces.
- 複数のインターフェースを認識するようにIPv4互換アドレス構成セクション（5.2）を改訂。
- Added discussion of source address selection when using IPv4- compatible addresses.
- IPv4互換アドレスを使用する場合のソースアドレス選択の説明を追加しました。
- Added section on the combination of the default configured tunneling technique with hosts using automatic tunneling.
- デフォルトの設定済みトンネリング技術と自動トンネリングを使用するホストの組み合わせに関するセクションを追加しました。
- Added prohibition against automatic tunneling to IPv4 broadcast or multicast destinations.
- IPv4ブロードキャストまたはマルチキャスト宛先への自動トンネリングに対する禁止が追加されました。
- Clarified that configured tunnels can be unidirectional or bidirectional.
- 設定されたトンネルが単方向または双方向である可能性があることを明確にしました。
- Added description of bidirectional virtual links as another type of tunnels. Nodes MUST respond to NUD probes on such links and SHOULD send NUD probes.
- 別のタイプのトンネルとして双方向仮想リンクの説明を追加しました。ノードはそのようなリンク上のNUDプローブに応答しなければならず（MUST）、NUDプローブを送信する必要があります（SHOULD）。
- Added reference to [16] specification as an alternative for tunneling over a multicast capable IPv4 cloud.
- マルチキャスト対応IPv4クラウドを介したトンネリングの代替手段として、[16]仕様への参照を追加しました。
- Clarified that IPv4-compatible addresses are assigned exclusively to nodes that support automatic tunnels i.e. nodes that can receive such packets.
- IPv4互換アドレスが、自動トンネルをサポートするノード、つまりそのようなパケットを受信できるノードに排他的に割り当てられることを明確にしました。
- Added text about formation of link-local addresses and use of Neighbor Discovery on tunnels.
- リンクローカルアドレスの形成とトンネルでの近隣探索の使用に関するテキストを追加しました。
- Added restriction that decapsulated packets not be forwarded unless the source address is acceptable to the decapsulating router.
- 送信元アドレスがカプセル化解除ルーターに受け入れられない限り、カプセル化解除されたパケットは転送されないという制限が追加されました。
- Clarified that decapsulating nodes MUST be capable of reassembling an IPv4 packet that is 1300 bytes (1280 bytes plus IPv4 header).
- ノードのカプセル開放は、1300バイト（1280バイトとIPv4ヘッダー）のIPv4パケットを再構成できる必要があることを明確にしました。
- Clarified that when using a default tunnel to an IPv4 "anycast address" the network must either have an IPv4 MTU of least 1300 bytes (to avoid fragmentation of minimum size IPv6 packets) or be configured to avoid frequent changes to IPv4 routing to the "anycast address" (to avoid different IPv4 fragments arriving at different tunnel endpoints).
- IPv4「エニーキャストアドレス」へのデフォルトトンネルを使用する場合、ネットワークはIPv4 MTUが少なくとも1300バイトである（最小サイズのIPv6パケットの断片化を回避する）か、「エニーキャスト」へのIPv4ルーティングへの頻繁な変更を回避するように構成する必要があることを明確にしました。アドレス」（異なるトンネルエンドポイントに到達する異なるIPv4フラグメントを回避するため）。
- Using A6/AAAA instead of AAAA to reference IPv6 address records in the DNS.
- DNS内のIPv6アドレスレコードを参照するために、AAAAの代わりにA6 / AAAAを使用します。
- Specified when to put IPv6 addresses in the DNS.
- DNSにIPv6アドレスを配置するタイミングを指定しました。
- Added reference to the tunnel mib for TTL specification for the tunnels.
- トンネルのTTL仕様のトンネルmibへの参照を追加しました。
- Added a table of contents.
- 目次を追加しました。
- Added recommendations for use of source and target link layer address options for the tunnel links.
- トンネルリンクのソースおよびターゲットリンクレイヤーアドレスオプションの使用に関する推奨事項を追加しました。
- Added checks in the decapsulation checking both an IPv4-compatible IPv6 source address and the outer IPv4 source addresses for multicast, broadcast, all-zeros etc.
- マルチキャスト、ブロードキャスト、すべてゼロなどのIPv4互換IPv6送信元アドレスと外部IPv4送信元アドレスの両方をチェックするカプセル化解除のチェックを追加しました。
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（C）The Internet Society（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、この文書自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。