[要約] RFC 4213は、IPv6ホストとルーターのための基本的な移行メカニズムについての要約です。このRFCの目的は、IPv6の導入とIPv4からの移行を容易にするためのガイドラインを提供することです。
Network Working Group E. Nordmark
Request for Comments: 4213 Sun Microsystems, Inc.
Obsoletes: 2893 R. Gilligan
Category: Standards Track Intransa, Inc.
October 2005
Basic 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 (2005).
Copyright（C）The Internet Society（2005）。
Abstract
概要
This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures.
このドキュメントでは、IPv6ホストとルーターによって実装できるIPv4互換性メカニズムを指定します。デュアルスタックと構成済みトンネリングという2つのメカニズムが指定されています。デュアルスタックは、インターネットプロトコル（IPv4およびIPv6）の両方のバージョンの完全な実装を提供することを意味し、構成されたトンネリングは、変更されていないIPv4ルーティングインフラストラクチャ上でIPv6パケットを伝送する手段を提供します。
This document obsoletes RFC 2893.
このドキュメントはRFC 2893を廃止します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Dual IP Layer Operation .........................................4
2.1. Address Configuration ......................................5
2.2. DNS ........................................................5
3. Configured Tunneling Mechanisms .................................6
3.1. Encapsulation ..............................................7
3.2. Tunnel MTU and Fragmentation ...............................8
3.2.1. Static Tunnel MTU ...................................9
3.2.2. Dynamic Tunnel MTU ..................................9
3.3. Hop Limit .................................................11
3.4. Handling ICMPv4 Errors ....................................11
3.5. IPv4 Header Construction ..................................13
3.6. Decapsulation .............................................14
3.7. Link-Local Addresses ......................................17
3.8. Neighbor Discovery over Tunnels ...........................18
4. Threat Related to Source Address Spoofing ......................18
5. Security Considerations ........................................19
6. Acknowledgements ...............................................21
7. References .....................................................21
7.1. Normative References ......................................21
7.2. Informative References ....................................21
8. Changes from RFC 2893 ..........................................23
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 two 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ホストとルーターと互換性を持つために実装できる2つのメカニズムを定義しています。
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ホストとルーターで使用されるように設計されています。インターネットのほとんどのノードには、このような互換性が長い間、おそらくは無期限に必要になると予想されます。
The mechanisms specified here are:
ここで指定されるメカニズムは次のとおりです。
- 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: A technique for establishing point-to-point tunnels by encapsulating IPv6 packets within IPv4 headers to carry them over IPv4 routing infrastructures.
- IPv6 over IPv4の構成済みトンネリング：IPv6パケットをIPv4ヘッダー内にカプセル化してIPv4ルーティングインフラストラクチャ上で運ぶことにより、ポイントツーポイントトンネルを確立するための手法。
The mechanisms defined here are intended to be the core of a "transition toolbox" -- a growing collection of techniques that 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 basic set of transition mechanisms, but these are not the only tools available. Additional transition and compatibility mechanisms are specified in other documents.
このドキュメントでは、移行メカニズムの基本セットを定義していますが、利用可能なツールはこれらだけではありません。追加の移行および互換性メカニズムは、他のドキュメントで指定されています。
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 in this memo.
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ノードです。
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(es) are determined by configuration information on tunnel endpoints. All tunnels are assumed to be bidirectional. The tunnel provides a (virtual) point-to-point link to the IPv6 layer, using the configured IPv4 addresses as the lower-layer endpoint addresses.
IPv6-over-IPv4トンネリング。IPv4トンネルエンドポイントアドレスは、トンネルエンドポイントの構成情報によって決定されます。すべてのトンネルは双方向であると想定されています。トンネルは、構成されたIPv4アドレスを下位層のエンドポイントアドレスとして使用して、IPv6層への（仮想）ポイントツーポイントリンクを提供します。
Other transition mechanisms, including other tunneling mechanisms, are outside the scope of this document.
他のトンネリングメカニズムを含む他の移行メカニズムは、このドキュメントの範囲外です。
The key words 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 [RFC2119].
このドキュメントに記載されているキーワードは、必須、必須ではない、必須、必須、必須ではない、推奨、推奨ではない場合がありますが、[RFC2119]で説明されているように解釈されます。
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 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. Here we use a rather loose notion of "stack". A stack being enabled has IP addresses assigned, but whether or not any particular application is available on the stacks is explicitly not defined. Thus, IPv6/IPv4 nodes may be operated in one of three modes:
ノードが両方のプロトコルをサポートするように装備されている場合でも、運用上の理由で一方または他方のスタックが無効になっている可能性があります。ここでは、「スタック」というややルーズな概念を使用しています。有効になっているスタックにはIPアドレスが割り当てられていますが、特定のアプリケーションがスタックで使用できるかどうかは明示的に定義されていません。したがって、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 configured tunneling technique, which is described in Section 3, may or may not be used in addition to the dual IP layer operation.
セクション3で説明する構成済みのトンネリング技術は、デュアルIPレイヤー操作に加えて、使用することもしないこともできます。
Because the nodes 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 [RFC2462] and/or DHCPv6) to acquire their IPv6 addresses.
ノードは両方のプロトコルをサポートしているため、IPv6 / IPv4ノードはIPv4とIPv6の両方のアドレスで構成できます。 IPv6 / IPv4ノードは、IPv4メカニズム（DHCPなど）を使用してIPv4アドレスを取得し、IPv6プロトコルメカニズム（ステートレスアドレス自動構成[RFC2462]やDHCPv6など）を使用して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 "AAAA" has been defined for IPv6 addresses [RFC3596]. 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 "AAAA" records. Note that the lookup of A versus AAAA records is independent of whether the DNS packets are carried in IPv4 or IPv6 packets and that there is no assumption that the DNS servers know the IPv4/IPv6 capabilities of the requesting node.
ドメインネームシステム（DNS）は、ホスト名とIPアドレス間のマッピングにIPv4とIPv6の両方で使用されます。 「AAAA」という名前の新しいリソースレコードタイプがIPv6アドレス[RFC3596]に定義されました。 IPv6 / IPv4ノードはIPv4ノードとIPv6ノードの両方と直接相互運用できる必要があるため、IPv4 "A"レコードとIPv6 "AAAA"レコードを処理できるリゾルバーライブラリを提供する必要があります。 AレコードとAAAAレコードの検索は、DNSパケットがIPv4パケットで送信されるかIPv6パケットで送信されるかとは無関係であり、DNSサーバーが要求側ノードのIPv4 / IPv6機能を知っているという前提はありません。
The issues and operational guidelines for using IPv6 with DNS are described at more length in other documents, e.g., [DNSOPV6].
DNSでIPv6を使用するための問題と運用ガイドラインは、[DNSOPV6]などの他のドキュメントで詳しく説明されています。
DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling both AAAA and A records. However, when a query locates an AAAA record holding an IPv6 address, and an A record holding an IPv4 address, the resolver library MAY order the results returned to the application in order to influence the version of IP packets used to communicate with that specific node -- IPv6 first, or IPv4 first.
IPv6 / IPv4ノード上のDNSリゾルバーライブラリは、AAAAとAレコードの両方を処理できる必要があります。ただし、クエリがIPv6アドレスを保持するAAAAレコード、およびIPv4アドレスを保持するAレコードを見つけると、リゾルバーライブラリは、その特定のノードとの通信に使用されるIPパケットのバージョンに影響を与えるために、アプリケーションに返される結果を並べる場合があります。 -IPv6ファースト、またはIPv4ファースト。
The applications SHOULD be able to specify whether they want IPv4, IPv6, or both records [RFC3493]. That defines which address families the resolver looks up. If there is not an application choice, or if the application has requested both, the resolver library MUST NOT filter out any records.
アプリケーションは、IPv4、IPv6、または両方のレコードが必要かどうかを指定できる必要があります[RFC3493]。これは、リゾルバが検索するアドレスファミリを定義します。アプリケーションの選択肢がない場合、またはアプリケーションが両方を要求した場合、リゾルバーライブラリはレコードをフィルターで除外してはなりません（MUST NOT）。
Since most applications try the addresses in the order they are returned by the resolver, this can affect the IP version "preference" of applications.
ほとんどのアプリケーションは、リゾルバーから返された順序でアドレスを試行するため、アプリケーションのIPバージョンの「設定」に影響を与える可能性があります。
The actual ordering mechanisms are out of scope of this memo. Address selection is described at more length in [RFC3484].
実際の順序付けメカニズムはこのメモの範囲外です。アドレス選択については、[RFC3484]で詳しく説明しています。
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ホストにトンネルできます。このトンネルは、エンドツーエンドパスの最後のセグメントだけに及びます。
Configured tunneling can be used in all of the above cases, but it is most likely to be used router-to-router due to the need to explicitly configure the tunneling endpoints.
構成されたトンネリングは上記のすべてのケースで使用できますが、トンネリングエンドポイントを明示的に構成する必要があるため、ルーター間で使用される可能性が最も高くなります。
The underlying mechanisms for tunneling are:
トンネリングの基本的なメカニズムは次のとおりです。
- The entry node of the tunnel (the encapsulator) creates an encapsulating IPv4 header and transmits the encapsulated packet.
- トンネルのエントリノード（カプセル化装置）はカプセル化IPv4ヘッダーを作成し、カプセル化されたパケットを送信します。
- The exit node of the tunnel (the decapsulator) receives the encapsulated packet, reassembles the packet if needed, removes the IPv4 header, and processes the received IPv6 packet.
- トンネルの出口ノード（カプセル開放装置）は、カプセル化されたパケットを受信し、必要に応じてパケットを再構成し、IPv4ヘッダーを削除して、受信したIPv6パケットを処理します。
- The encapsulator 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.
- カプセル化装置は、トンネルに転送されたIPv6パケットを処理するために、トンネルのMTUなどのパラメータを記録する各トンネルのソフト状態情報を維持する必要がある場合があります。
In configured tunneling, the tunnel endpoint addresses are determined in the encapsulator from configuration information stored for each tunnel. When an IPv6 packet is transmitted over a tunnel, the destination and source addresses for the encapsulating IPv4 header are set as described in Section 3.5.
設定されたトンネリングでは、トンネルエンドポイントアドレスは、各トンネルに格納された設定情報からカプセル化装置で決定されます。 IPv6パケットがトンネルを介して送信されるとき、カプセル化IPv4ヘッダーの宛先および送信元アドレスは、セクション3.5で説明されているように設定されます。
The determination of which packets to tunnel is usually made by routing information on the encapsulator. This is usually done via a routing table, which directs packets based on their destination address using the prefix mask and match technique.
トンネリングするパケットの決定は、通常、カプセル化装置のルーティング情報によって行われます。これは通常、ルーティングテーブルを介して行われます。ルーティングテーブルは、プレフィックスマスクと一致技術を使用して、宛先アドレスに基づいてパケットを転送します。
The decapsulator matches the received protocol-41 packets to the tunnels it has configured, and allows only the packets in which IPv4 source addresses match the tunnels configured on the decapsulator. Therefore, the operator must ensure that the tunnel's IPv4 address configuration is the same both at the encapsulator and the decapsulator.
カプセル開放装置は、受信したprotocol-41パケットを構成済みのトンネルと照合し、IPv4送信元アドレスがカプセル開放装置で構成されたトンネルと一致するパケットのみを許可します。したがって、オペレーターは、トンネルのIPv4アドレス構成がカプセル化装置とカプセル開放装置の両方で同じであることを確認する必要があります。
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 encapsulator also has to handle some more complex issues:
IPv4ヘッダーを追加することに加えて、カプセル化プログラムはさらに複雑な問題を処理する必要があります。
- Determine when to fragment and when to report an ICMPv6 "packet too big" error back to the source.
- フラグメント化するタイミングと、ICMPv6の「パケットが大きすぎる」エラーをソースに報告するタイミングを決定します。
- How to reflect ICMPv4 errors from routers along the tunnel path back to the source as ICMPv6 errors.
- ルーターからのICMPv4エラーをトンネルパスに沿ってICMPv6エラーとしてソースに戻す方法。
Those issues are discussed in the following sections.
これらの問題については、次のセクションで説明します。
Naively, the encapsulator could view encapsulation as IPv6 using IPv4 as a link layer with a very large MTU (65535-20 bytes at most; 20 bytes "extra" are needed for the encapsulating IPv4 header). The encapsulator would only need to report ICMPv6 "packet too big" errors back to the source for packets that exceed this MTU. However, such a scheme would be inefficient or non-interoperable for three reasons and therefore MUST NOT be used:
単純に、カプセル化装置は、非常に大きなMTUを持つリンク層としてIPv4を使用して、カプセル化をIPv6と見なすことができます（最大で65535-20バイト。カプセル化するIPv4ヘッダーには「追加」20バイトが必要です）。カプセル化装置は、このMTUを超えるパケットについて、ソースにICMPv6 "packet too big"エラーを報告するだけで済みます。ただし、このようなスキームは3つの理由で非効率的または相互運用できないため、使用してはなりません。
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 [KM97].
1）必要以上に断片化が発生します。損失単位が再送信単位[KM97]よりも小さいために発生するパフォーマンスの問題のため、IPv4レイヤーの断片化は避けてください。
2) Any IPv4 fragmentation occurring inside the tunnel, i.e., between the encapsulator and the decapsulator, would have to be reassembled at the tunnel endpoint. For tunnels that terminate at a router, this would require additional memory and other resources to reassemble the IPv4 fragments into a complete IPv6 packet before that packet could be forwarded.
2）トンネル内、つまりカプセル化装置とカプセル開放装置の間で発生するIPv4断片化は、トンネルエンドポイントで再構成する必要があります。ルーターで終端するトンネルの場合、パケットを転送する前に、IPv4フラグメントを完全なIPv6パケットに再構成するために、追加のメモリとその他のリソースが必要になります。
3) The encapsulator has no way of knowing that the decapsulator is able to defragment such IPv4 packets (see Section 3.6 for details), and has no way of knowing that the decapsulator is able to handle such a large IPv6 Maximum Receive Unit (MRU).
3）カプセル化装置は、カプセル化解除装置がそのようなIPv4パケットをデフラグできることを知る方法がなく（詳細はセクション3.6を参照）、カプセル化解除装置がそのような大きなIPv6最大受信ユニット（MRU）を処理できることを知る方法がありません。
Hence, the encapsulator MUST NOT treat the tunnel as an interface with an MTU of 64 kilobytes, but instead either use the fixed static MTU or OPTIONAL dynamic MTU determination based on the IPv4 path MTU to the tunnel endpoint.
したがって、カプセル化装置はトンネルを64キロバイトのMTUを持つインターフェースとして扱わないでください。代わりに、トンネルエンドポイントへのIPv4パスMTUに基づいて、固定の静的MTUまたはオプションの動的MTUの決定を使用してください。
If both the mechanisms are implemented, the decision of which to use SHOULD be configurable on a per-tunnel endpoint basis.
両方のメカニズムが実装されている場合、どちらを使用するかの決定は、トンネルエンドポイントごとに構成可能である必要があります。
A node using static tunnel MTU treats the tunnel interface as having a fixed-interface MTU. By default, the MTU MUST be between 1280 and 1480 bytes (inclusive), but it SHOULD be 1280 bytes. If the default is not 1280 bytes, the implementation MUST have a configuration knob that can be used to change the MTU value.
静的トンネルMTUを使用するノードは、トンネルインターフェイスを固定インターフェイスMTUを持つものとして扱います。デフォルトでは、MTUは1280〜1480バイト（両端を含む）でなければなりませんが、1280バイトにする必要があります。デフォルトが1280バイトでない場合、実装にはMTU値を変更するために使用できる設定ノブが必要です。
A node must be able to accept a fragmented IPv6 packet that, after reassembly, is as large as 1500 octets [RFC2460]. This memo also includes requirements (see Section 3.6) for the amount of IPv4 reassembly and IPv6 MRU that MUST be supported by all the decapsulators. These ensure correct interoperability with any fixed MTUs between 1280 and 1480 bytes.
ノードは、再組み立て後、1500オクテット[RFC2460]と同じ大きさの断片化されたIPv6パケットを受け入れることができる必要があります。このメモには、すべてのカプセル化解除者がサポートしなければならないIPv4再構成とIPv6 MRUの量に関する要件（セクション3.6を参照）も含まれています。これらにより、1280〜1480バイトの固定MTUとの正しい相互運用性が保証されます。
A larger fixed MTU than supported by these requirements must not be configured unless it has been administratively ensured that the decapsulator can reassemble or receive packets of that size.
カプセル化解除装置がそのサイズのパケットを再構成または受信できることが管理上保証されていない限り、これらの要件でサポートされるよりも大きな固定MTUを構成しないでください。
The selection of a good tunnel MTU depends on many factors, at least:
適切なトンネルMTUの選択は、少なくとも次のような多くの要因に依存します。
- Whether the IPv4 protocol-41 packets will be transported over media that may have a lower path MTU (e.g., IPv4 Virtual Private Networks); then picking too high a value might lead to IPv4 fragmentation.
- IPv4プロトコル41パケットが、パスMTUがより低い可能性があるメディア（IPv4仮想プライベートネットワークなど）を介して転送されるかどうか。あまりに高い値を選択すると、IPv4フラグメンテーションが発生する可能性があります。
- Whether the tunnel is used to transport IPv6 tunneled packets (e.g., a mobile node with an IPv6-in-IPv4 configured tunnel, and an IPv6-in-IPv6 tunnel interface); then picking too low a value might lead to IPv6 fragmentation.
- トンネルを使用してIPv6トンネルパケットを転送するかどうか（たとえば、IPv6-in-IPv4構成のトンネルを備えたモバイルノード、およびIPv6-in-IPv6トンネルインターフェイス）;選択した値が小さすぎると、IPv6フラグメンテーションが発生する可能性があります。
If layered encapsulation is believed to be present, it may be prudent to consider supporting dynamic MTU determination instead as it is able to minimize fragmentation and optimize packet sizes.
階層化されたカプセル化が存在すると思われる場合は、断片化を最小限に抑え、パケットサイズを最適化できるため、代わりに動的MTU決定のサポートを検討することをお勧めします。
When using the static tunnel MTU, the Don't Fragment bit MUST NOT be set in the encapsulating IPv4 header. As a result, the encapsulator should not receive any ICMPv4 "packet too big" messages as a result of the packets it has encapsulated.
静的トンネルMTUを使用する場合は、カプセル化IPv4ヘッダーでDo n't Fragmentビットを設定してはなりません（MUST NOT）。その結果、カプセル化されたパケットの結果として、カプセル化プログラムはICMPv4の「パケットが大きすぎます」メッセージを受信しません。
The dynamic MTU determination is OPTIONAL. However, if it is implemented, it SHOULD have the behavior described in this document.
動的MTUの決定はオプションです。ただし、実装されている場合は、このドキュメントで説明されている動作を行う必要があります（SHOULD）。
The fragmentation inside the tunnel can be reduced to a minimum by having the encapsulator track the IPv4 path MTU across the tunnel, using the IPv4 Path MTU Discovery Protocol [RFC1191] and recording the resulting path MTU. The IPv6 layer in the encapsulator 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発見プロトコル[RFC1191]を使用して、結果のパスMTUを記録することにより、最小限に抑えることができます。カプセル化装置のIPv6層は、トンネルを、IPv4パスMTUからカプセル化IPv4ヘッダーのサイズを引いた値に等しいMTUを持つリンク層として表示できます。
Note that this does not 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 [RFC2460].) In this case, the IPv6 layer has to "see" a link layer with an MTU of 1280 bytes and the encapsulator has to use IPv4 fragmentation in order to forward the 1280 byte IPv6 packets.
これは、IPv4パスMTUの結果としてIPv6 MTUが1280バイト未満になる場合にIPv4フラグメンテーションを排除しないことに注意してください。 （IPv6で使用されるリンク層は、少なくとも1280バイトのMTUが必要です[RFC2460]。）この場合、IPv6層は1280バイトのMTUを持つリンク層を「参照」する必要があり、カプセル化装置はIPv4を使用する必要があります1280バイトのIPv6パケットを転送するためのフラグメンテーション。
The encapsulator SHOULD 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 ICMPv6 "packet too big" message per [RFC1981]:
カプセル化装置は、次のアルゴリズムを使用して、IPv4フラグメンテーションを使用してトンネルのパスMTUより大きいIPv6パケットをいつ転送するか、および[RFC1981]に従ってICMPv6 "packet too big"メッセージをいつ返すかを決定します。
if (IPv4 path MTU - 20) is less than 1280
if packet is larger than 1280 bytes
Send ICMPv6 "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 encapsulator or by some router along
the IPv4 path.
endif
else
if packet is larger than (IPv4 path MTU - 20)
Send ICMPv6 "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
Encapsulators that have a large number of tunnels may choose between dynamic versus static tunnel MTUs on a per-tunnel endpoint basis. In cases where the number of tunnels that any one node is using is large, it is helpful to observe that this state information can be cached and discarded when not in use.
多数のトンネルを持つカプセル化装置は、トンネルエンドポイントごとに動的トンネルMTUと静的トンネルMTUのどちらかを選択できます。 1つのノードが使用しているトンネルの数が多い場合、この状態情報が使用されていないときにキャッシュおよび破棄できることを確認すると役立ちます。
Note that using dynamic tunnel MTU is subject to IPv4 path MTU blackholes should the ICMPv4 "packet too big" messages be dropped by firewalls or not generated by the routers [RFC1435, RFC2923].
ICMPv4の「パケットが大きすぎる」メッセージがファイアウォールによってドロップされたり、ルーターによって生成されなかったりした場合、動的トンネルMTUの使用はIPv4パスMTUブラックホールの影響を受けることに注意してください[RFC1435、RFC2923]。
IPv6-over-IPv4 tunnels are modeled as "single-hop" from the IPv6 perspective. The tunnel is opaque to users of the network, and it is not detectable by network diagnostic tools such as traceroute.
IPv6-over-IPv4トンネルは、IPv6の観点から「シングルホップ」としてモデル化されます。トンネルはネットワークのユーザーに対して不透明であり、tracerouteなどのネットワーク診断ツールでは検出できません。
The single-hop model is implemented by having the encapsulators and decapsulators 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 [RFC3232][ASSIGNED]. Implementations MAY provide a mechanism to allow the administrator to configure the IPv4 TTL as the IP Tunnel MIB [RFC4087].
カプセル化IPv4ヘッダーのTTLは、実装に依存する方法で選択されます。現在の推奨値は、「Assigned Numbers」RFC [RFC3232] [ASSIGNED]で公開されています。実装は、管理者がIPv4 TTLをIPトンネルMIB [RFC4087]として構成できるようにするメカニズムを提供してもよい（MAY）。
In response to encapsulated packets it has sent into the tunnel, the encapsulator might receive ICMPv4 error messages from IPv4 routers inside the tunnel. These packets are addressed to the encapsulator because it is the IPv4 source of the encapsulated packet.
カプセル化されたパケットがトンネルに送信したことに応答して、カプセル化装置は、トンネル内のIPv4ルーターからICMPv4エラーメッセージを受信する場合があります。これらのパケットは、カプセル化されたパケットのIPv4送信元であるため、カプセル化先に送信されます。
ICMPv4 error handling is only applicable to dynamic MTU determination, even though the functions could be used with static MTU tunnels as well.
ICMPv4エラー処理は、静的MTUトンネルでも機能を使用できる場合でも、動的MTU決定にのみ適用できます。
The ICMPv4 "packet too big" error messages are handled according to IPv4 Path MTU Discovery [RFC1191] and the resulting path MTU is recorded in the IPv4 layer. The recorded path MTU is used by IPv6 to determine if an ICMPv6 "packet too big" error has to be generated as described in Section 3.2.2.
ICMPv4の「パケットが大きすぎます」エラーメッセージは、IPv4パスMTU検出[RFC1191]に従って処理され、結果のパスMTUはIPv4レイヤーに記録されます。記録されたパスMTUは、IPv6で使用され、セクション3.2.2で説明されているように、ICMPv6の「パケットが大きすぎる」エラーを生成する必要があるかどうかを判断します。
The handling of other types of ICMPv4 error messages depends on how much information is available from the encapsulated packet that caused the error.
他のタイプのICMPv4エラーメッセージの処理は、エラーの原因となったカプセル化されたパケットから利用可能な情報の量によって異なります。
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. See [RFC1812].
多くの古いIPv4ルーターは、エラーのあるパケットのIPv4ヘッダーを超えて8バイトのデータのみを返します。これは、IPv6ヘッダーのアドレスフィールドを含めるには不十分です。より最近のIPv4ルーターは、IPv4ヘッダーを超えて十分なデータを返し、IPv6ヘッダー全体、さらにはそれを超えるデータを返す可能性があります。 [RFC1812]を参照してください。
If sufficient data bytes from the offending packet are available, the encapsulator MAY extract the encapsulated IPv6 packet and use it to generate an ICMPv6 message directed back to the originating IPv6 node, as shown below:
問題のパケットから十分なデータバイトが利用できる場合、カプセル化装置はカプセル化されたIPv6パケットを抽出して、以下に示すように、発信元のIPv6ノードに向けられたICMPv6メッセージを生成することができます：
+--------------+
| IPv4 Header |
| dst = encaps |
| node |
+--------------+
| ICMPv4 |
| Header |
- - +--------------+
| IPv4 Header |
| src = encaps |
IPv4 | node |
+--------------+ - -
Packet | IPv6 |
| Header | Original IPv6
in +--------------+ Packet -
| Transport | Can be used to
Error | Header | generate an
+--------------+ ICMPv6
| | error message
~ Data ~ back to the source.
| |
- - +--------------+ - -
ICMPv4 Error Message Returned to Encapsulating Node
ICMPv4エラーメッセージがカプセル化ノードに返される
When receiving ICMPv4 errors as above and the errors are not "packet too big", it would be useful to log the error as an error related to the tunnel. Also, if sufficient headers are available, then the originating node MAY send an ICMPv6 error of type "unreachable" with code "address unreachable" to the IPv6 source. (The "address unreachable" code is appropriate since, from the perspective of IPv6, the tunnel is a link and that code is used for link-specific errors [RFC2463]).
上記のようにICMPv4エラーを受信し、エラーが「パケットが大きすぎない」場合、トンネルに関連するエラーとしてエラーを記録すると便利です。また、十分なヘッダーが利用可能な場合、発信ノードは、「アドレス到達不能」というコードの「到達不能」タイプのICMPv6エラーをIPv6ソースに送信してもよい（MAY）。 （IPv6の観点から見ると、トンネルはリンクであり、そのコードはリンク固有のエラーに使用されるため、「アドレス到達不能」コードが適切です[RFC2463]）。
Note that when the IPv4 path MTU is exceeded, and sufficient bytes of payload associated with the ICMPv4 errors are not available, or ICMPv4 errors do not cause the generation of ICMPv6 errors in case there is enough payload, there will be at least two packet drops instead of at least one (the case of a single layer of MTU discovery). Consider a case where an IPv6 host is connected to an IPv4/IPv6 router, which is connected to a network where an ICMPv4 error about too big packet size is generated. First, the router needs to learn the tunnel (IPv4) MTU that causes at least one packet loss, and then the host needs to learn the (IPv6) MTU from the router that causes at least one packet loss. Still, in all cases there can be more than one packet loss if there are multiple large packets in flight at the same time.
IPv4パスMTUを超え、ICMPv4エラーに関連付けられた十分なバイトのペイロードが利用できない場合、または十分なペイロードがある場合にICMPv4エラーが原因でICMPv6エラーが発生しないことに注意してください。少なくとも2つのパケットドロップがあります。少なくとも1つではなく（MTU検出の単一層の場合）。 IPv6ホストがIPv4 / IPv6ルーターに接続されている場合を考えてください。IPv4/ IPv6ルーターは、パケットサイズが大きすぎるというICMPv4エラーが生成されるネットワークに接続されています。最初に、ルーターは少なくとも1つのパケット損失を引き起こすトンネル（IPv4）MTUを学習する必要があり、次にホストは少なくとも1つのパケット損失を引き起こすルーターから（IPv6）MTUを学習する必要があります。それでも、複数の大きなパケットが同時に飛行している場合、すべてのケースで複数のパケット損失が発生する可能性があります。
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 unless otherwise specified. (See [RFC2983] and [RFC3168] Section 9.1 for issues relating to the Type-of-Service byte and tunneling.)
特に指定のない限り、0。 （Type-of-Serviceバイトとトンネリングに関する問題については、[RFC2983]および[RFC3168]セクション9.1をご覧ください）。
Total Length:
全長：
Payload length from IPv6 header plus length of IPv6 and IPv4 headers (i.e., IPv6 payload length plus a constant 60 bytes).
IPv6ヘッダーからのペイロードの長さと、IPv6およびIPv4ヘッダーの長さ（つまり、IPv6ペイロードの長さと一定の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 an implementation-specific manner, as described in Section 3.3.
セクション3.3で説明されているように、実装固有の方法で設定します。
Protocol:
プロトコル：
41 (Assigned payload type number for IPv6).
41（IPv6の割り当てられたペイロードタイプ番号）。
Header Checksum:
ヘッダーチェックサム：
Calculate the checksum of the IPv4 header [RFC791].
IPv4ヘッダーのチェックサムを計算します[RFC791]。
Source Address:
送信元アドレス：
An IPv4 address of the encapsulator: either configured by the administrator or an address of the outgoing interface.
カプセル化装置のIPv4アドレス：管理者が構成するか、発信インターフェイスのアドレス。
Destination Address:
宛先アドレス：
IPv4 address of the tunnel endpoint.
トンネルエンドポイントのIPv4アドレス。
When encapsulating the packets, the node must ensure that it will use the correct source address so that the packets are acceptable to the decapsulator as described in Section 3.6. Configuring the source address is appropriate particularly in cases in which automatic selection of source address may produce different results in a certain period of time. This is often the case with multiple addresses, and multiple interfaces, or when routes may change frequently. Therefore, it SHOULD be possible to administratively specify the source address of a tunnel.
パケットをカプセル化するとき、ノードは、セクション3.6で説明するように、パケットがデカプセル化装置に受け入れられるように、正しい送信元アドレスを使用することを確認する必要があります。送信元アドレスの設定は、送信元アドレスの自動選択が特定の期間に異なる結果を生成する可能性がある場合に特に適しています。これは、複数のアドレス、複数のインターフェース、またはルートが頻繁に変更される場合によく見られます。したがって、管理者がトンネルの送信元アドレスを指定できるようにする必要があります。
When an IPv6/IPv4 host or a router receives an IPv4 datagram that is addressed to one of its own IPv4 addresses or a joined multicast group address, and the value of the protocol field is 41, the packet is potentially a tunnel packet and needs to be verified to belong to one of the configured tunnel interfaces (by checking source/destination addresses), reassembled (if fragmented at the IPv4 level), and have the IPv4 header removed and the resulting IPv6 datagram be submitted to the IPv6 layer code on the node.
IPv6 / IPv4ホストまたはルーターが、自身のIPv4アドレスまたは参加マルチキャストグループアドレスの1つにアドレス指定されたIPv4データグラムを受信し、プロトコルフィールドの値が41である場合、パケットは潜在的にトンネルパケットであり、 （送信元/宛先アドレスをチェックすることにより）構成されたトンネルインターフェイスの1つに属していることを確認し、再構成（IPv4レベルでフラグメント化されている場合）して、IPv4ヘッダーを削除し、結果のIPv6データグラムをIPv6レイヤーコードに送信するノード。
The decapsulator MUST verify that the tunnel source address is correct before further processing packets, to mitigate the problems with address spoofing (see Section 4). This check also applies to packets that are delivered to transport protocols on the decapsulator. This is done by verifying that the source address is the IPv4 address of the encapsulator, as configured on the decapsulator. Packets for which the IPv4 source address does not match MUST be discarded and an ICMP message SHOULD NOT be generated;
カプセル化解除者は、パケットをさらに処理する前に、トンネル送信元アドレスが正しいことを確認して、アドレススプーフィングの問題を軽減する必要があります（セクション4を参照）。このチェックは、カプセル開放装置のトランスポートプロトコルに配信されるパケットにも適用されます。これは、送信元アドレスが、カプセル化解除装置で構成されているカプセル化装置のIPv4アドレスであることを確認することによって行われます。 IPv4送信元アドレスが一致しないパケットは破棄しなければならず（MUST）、ICMPメッセージを生成してはなりません（SHOULD NOT）。
however, if the implementation normally sends an ICMP message when receiving an unknown protocol packet, such an error message MAY be sent (e.g., ICMPv4 Protocol 41 Unreachable).
ただし、実装が不明なプロトコルパケットを受信したときに通常ICMPメッセージを送信する場合、そのようなエラーメッセージが送信される場合があります（例：ICMPv4 Protocol 41 Unreachable）。
A side effect of this address verification is that the node will silently discard packets with a wrong source address and packets that were received by the node but not directly addressed to it (e.g., broadcast addresses).
このアドレス検証の副作用は、ノードが間違った送信元アドレスを持つパケットと、ノードによって受信されたが直接アドレス指定されていないパケット（ブロードキャストアドレスなど）を静かに破棄することです。
Independent of any other forms of IPv4 ingress filtering the administrator of the node may have configured, the implementation MAY perform ingress filtering, i.e., check that the packet is arriving from the interface in the direction of the route toward the tunnel end-point, similar to a Strict Reverse Path Forwarding (RPF) check [RFC3704]. As this may cause problems on tunnels that are routed through multiple links, it is RECOMMENDED that this check, if done, is disabled by default. The packets caught by this check SHOULD be discarded; an ICMP message SHOULD NOT be generated by default.
ノードの管理者が構成したIPv4イングレスフィルタリングの他の形式とは無関係に、実装はイングレスフィルタリングを実行することができます。つまり、パケットがトンネルのエンドポイントに向かうルートの方向にインターフェイスから到着していることを確認します。 Strict Reverse Path Forwarding（RPF）チェック[RFC3704]。これにより、複数のリンクを介してルーティングされるトンネルで問題が発生する可能性があるため、このチェックを行う場合、デフォルトで無効にすることをお勧めします。このチェックでキャッチされたパケットは破棄する必要があります（SHOULD）。 ICMPメッセージはデフォルトでは生成されるべきではない（SHOULD NOT）。
The decapsulator MUST be capable of having, on the tunnel interfaces, an IPv6 MRU of at least the maximum of 1500 bytes and the largest (IPv6) interface MTU on the decapsulator.
カプセル開放装置は、トンネルインターフェース上で、少なくとも最大1500バイトのIPv6 MRUとカプセル開放装置の最大（IPv6）インターフェースMTUを持つことができなければなりません（MUST）。
The decapsulator MUST be capable of reassembling an IPv4 packet that is (after the reassembly) the maximum of 1500 bytes and the largest (IPv4) interface MTU on the decapsulator. The 1500-byte number is a result of encapsulators that use the static MTU scheme in Section 3.2.1, while encapsulators that use the dynamic scheme in Section 3.2.2 can cause up to the largest interface MTU on the decapsulator to be received. (Note that it is strictly the interface MTU on the last IPv4 router *before* the decapsulator that matters, but for most links the MTU is the same between all neighbors.)
カプセル開放装置は、（再組み立て後）最大1500バイトで、カプセル開放装置の最大（IPv4）インターフェースMTUであるIPv4パケットを再組み立てできなければなりません（MUST）。 1500バイトの数値は、セクション3.2.1の静的MTUスキームを使用するカプセル化装置の結果ですが、セクション3.2.2の動的スキームを使用するカプセル化装置は、最大で最大のインターフェイスMTUをカプセル化解除装置で受信する可能性があります。 （重要なのは、カプセル化解除装置の「前」の最後のIPv4ルーター上のインターフェースMTUですが、ほとんどのリンクでは、MTUはすべてのネイバー間で同じであることに注意してください。
This reassembly limit allows dynamic tunnel MTU determination by the encapsulator to take advantage of larger IPv4 path MTUs. An implementation MAY have a configuration knob that can be used to set a larger value of the tunnel reassembly buffers than the above number, but it MUST NOT be set below the above number.
この再構成の制限により、カプセル化装置による動的トンネルMTUの決定で、より大きなIPv4パスMTUを利用できます。実装は、上記の数よりも大きなトンネル再構成バッファーの値を設定するために使用できる構成ノブを持っている場合がありますが、上記の数を下回って設定してはなりません（MUST NOT）。
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のカプセル化解除
The decapsulator performs IPv4 reassembly before decapsulating the IPv6 packet.
カプセル開放装置は、IPv6パケットをカプセル開放する前にIPv4再構成を実行します。
When decapsulating the packet, the IPv6 header is not modified. (However, see [RFC2983] and [RFC3168] section 9.1 for issues relating to the Type of Service byte and tunneling.) If the packet is subsequently forwarded, its hop limit is decremented by one.
パケットのカプセル化を解除するとき、IPv6ヘッダーは変更されません。 （ただし、タイプオブサービスのバイトとトンネリングに関する問題については、[RFC2983]と[RFC3168]のセクション9.1をご覧ください。）その後、パケットが転送されると、そのホップ制限は1つ減少します。
The encapsulating IPv4 header is discarded, and the resulting packet is checked for validity when submitted to the IPv6 layer. When reconstructing the IPv6 packet, the length MUST be determined from the IPv6 payload length since the IPv4 packet might be padded (thus have a length that is larger than the IPv6 packet plus the IPv4 header being removed).
カプセル化しているIPv4ヘッダーは破棄され、結果のパケットはIPv6層に送信されるときに有効性がチェックされます。 IPv6パケットを再構築する場合、IPv4パケットはパディングされる可能性があるため、長さはIPv6ペイロード長から決定する必要があります（したがって、IPv6パケットと削除されるIPv4ヘッダーよりも長い長さになります）。
After the decapsulation, the node MUST silently discard a packet with an invalid IPv6 source address. The list of invalid source addresses SHOULD include at least:
カプセル化解除後、ノードは無効なIPv6送信元アドレスを持つパケットを暗黙のうちに破棄する必要があります。無効な送信元アドレスのリストには、少なくとも以下を含める必要があります。
- all multicast addresses (FF00::/8)
- すべてのマルチキャストアドレス（FF00 :: / 8）
- the loopback address (::1)
- ループバックアドレス（:: 1）
- all the IPv4-compatible IPv6 addresses [RFC3513] (::/96), excluding the unspecified address for Duplicate Address Detection (::/128)
- すべてのIPv4互換IPv6アドレス[RFC3513]（:: / 96）、重複アドレス検出用の未指定アドレスを除く（:: / 128）
- all the IPv4-mapped IPv6 addresses (::ffff:0:0/96) In addition, the node should be configured to perform ingress filtering [RFC2827][RFC3704] on the IPv6 source address, similar to on any of its interfaces, e.g.:
-すべてのIPv4にマップされたIPv6アドレス（:: ffff：0：0/96）さらに、ノードは、そのインターフェイスのいずれかと同様に、IPv6送信元アドレスで入力フィルタリング[RFC2827] [RFC3704]を実行するように構成する必要があります、例：
1) if the tunnel is toward the Internet, the node should be configured to check that the site's IPv6 prefixes are not used as the source addresses, or
1）トンネルがインターネットに向けられている場合、ノードは、サイトのIPv6プレフィックスがソースアドレスとして使用されていないことを確認するように構成する必要があります。
2) if the tunnel is toward an edge network, the node should be configured to check that the source address belongs to that edge network.
2）トンネルがエッジネットワークに向かう場合、ノードは、送信元アドレスがそのエッジネットワークに属していることを確認するように構成する必要があります。
The prefix lists in the former typically need to be manually configured; the latter could be verified automatically, e.g., by using a strict unicast RPF check, as long as an interface can be designated to be toward an edge.
前者のプレフィックスリストは通常、手動で構成する必要があります。後者は、インターフェイスをエッジに向けて指定できる限り、厳密なユニキャストRPFチェックを使用するなどして、自動的に検証できます。
It is RECOMMENDED that the implementations provide a single knob to make it easier to for the administrators to enable strict ingress filtering toward edge networks.
実装が単一のノブを提供して、管理者がエッジネットワークへの厳密な入力フィルタリングを簡単に有効にできるようにすることをお勧めします。
The configured tunnels are IPv6 interfaces (over the IPv4 "link layer") and thus MUST have link-local addresses. The link-local addresses are used by, e.g., routing protocols operating over the tunnels.
構成されたトンネルはIPv6インターフェース（IPv4「リンク層」を介して）であり、したがってリンクローカルアドレスを持っている必要があります。リンクローカルアドレスは、たとえば、トンネル上で動作するルーティングプロトコルによって使用されます。
The interface identifier [RFC3513] for such an interface may be based on the 32-bit IPv4 address of an underlying interface, or formed using some other means, as long as it is unique from the other tunnel endpoint with a reasonably high probability.
そのようなインターフェースのインターフェース識別子[RFC3513]は、かなり高い確率で他のトンネルエンドポイントから一意である限り、基になるインターフェースの32ビットIPv4アドレスに基づくか、または他の手段を使用して形成されます。
Note that it may be desirable to form the link-local address in a fashion that minimizes the probability and the effect of having to renumber the link-local address in the event of a topology or hardware change.
トポロジまたはハードウェアが変更された場合にリンクローカルアドレスを再番号付けする確率と効果を最小限に抑える方法でリンクローカルアドレスを形成することが望ましい場合があることに注意してください。
If an IPv4 address is used for forming the IPv6 link-local address, the interface identifier is the IPv4 address, prepended by zeros. Note that the "Universal/Local" bit is zero, indicating that the interface identifier is not globally unique. The link-local address is formed by appending the interface identifier to the prefix FE80::/64.
IPv4アドレスを使用してIPv6リンクローカルアドレスを形成する場合、インターフェイス識別子は、先頭にゼロが付加されたIPv4アドレスです。 「Universal / Local」ビットはゼロであることに注意してください。これは、インターフェイス識別子がグローバルに一意ではないことを示しています。リンクローカルアドレスは、インターフェイス識別子をプレフィックスFE80 :: / 64に追加することによって形成されます。
When the host has more than one IPv4 address in use on the physical interface concerned, a choice of one of these IPv4 addresses is made by the administrator or the implementation when forming the link-local address.
ホストが関連する物理インターフェイスで複数のIPv4アドレスを使用している場合、リンクローカルアドレスを形成するときに、管理者または実装によって、これらのIPv4アドレスの1つが選択されます。
+-------+-------+-------+-------+-------+-------+------+------+
| FE 80 00 00 00 00 00 00 |
+-------+-------+-------+-------+-------+-------+------+------+
| 00 00 00 00 | IPv4 Address |
+-------+-------+-------+-------+-------+-------+------+------+
Configured tunnel implementations MUST at least accept and respond to the probe packets used by Neighbor Unreachability Detection (NUD) [RFC2461]. The 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.
設定されたトンネル実装は、少なくとも近隣到達不能検出（NUD）[RFC2461]によって使用されるプローブパケットを受け入れて応答する必要があります。また、実装はNUDプローブパケットを送信して、設定されたトンネルが失敗したときに検出し、その時点で実装は代替パスを使用して宛先に到達できます。近隣探索では、ルーティングプロトコルが双方向の到達可能性を追跡する場合、ルーター間リンクのNUDプローブの送信を省略できることに注意してください。
For the purposes of Neighbor Discovery, the configured tunnels specified in this document are assumed to NOT have a link-layer address, even though the link-layer (IPv4) does have an address. This means that:
近隣探索の目的で、このドキュメントで指定されている構成済みのトンネルは、リンク層（IPv4）にアドレスがある場合でも、リンク層アドレスを持たないと想定されています。この意味は：
- the sender of Neighbor Discovery packets SHOULD NOT include Source Link Layer Address options or Target Link Layer Address options on the tunnel link.
- 近隣探索パケットの送信者には、トンネルリンクのソースリンクレイヤーアドレスオプションまたはターゲットリンクレイヤーアドレスオプションを含めないでください。
- the receiver MUST, while otherwise processing the Neighbor Discovery packet, silently ignore the content of any Source Link Layer Address options or Target Link Layer Address options received on the tunnel link.
- 受信者は、近隣探索パケットを処理している間、トンネルリンクで受信したソースリンクレイヤーアドレスオプションまたはターゲットリンクレイヤーアドレスオプションの内容を無視します。
Not using link-layer address options is consistent with how Neighbor Discovery is used on other point-to-point links.
リンク層アドレスオプションを使用しないことは、他のポイントツーポイントリンクでの近隣探索の使用方法と一致しています。
The specification above contains rules that apply tunnel source address verification in particular and ingress filtering [RFC2827][RFC3704] in general to packets before they are decapsulated. When IP-in-IP tunneling (independent of IP versions) is used, it is important that this not be used to bypass any ingress filtering in use for non-tunneled packets. Thus, the rules in this document are derived based on should ingress filtering be used for IPv4 and IPv6, the use of tunneling should not provide an easy way to circumvent the filtering.
上記の仕様には、パケットのカプセル化を解除する前に、特にパケットのトンネル送信元アドレス検証と入力フィルタリング[RFC2827] [RFC3704]をパケットに適用するルールが含まれています。 IP-in-IPトンネリング（IPバージョンに依存しない）を使用する場合、これを使用して、トンネリングされていないパケットに使用されている入力フィルタリングをバイパスしないことが重要です。したがって、このドキュメントのルールは、IPv4およびIPv6で入力フィルタリングを使用する必要があるかどうかに基づいて導出されます。トンネリングを使用しても、フィルタリングを回避する簡単な方法は提供されません。
In this case, without specific ingress filtering checks in the decapsulator, it would be possible for an attacker to inject a packet with:
この場合、カプセル開放装置で特定の入力フィルタリングチェックを行わないと、攻撃者が次のようにパケットを注入する可能性があります。
- Outer IPv4 source: real IPv4 address of attacker
- 外部IPv4ソース：攻撃者の実際のIPv4アドレス
- Outer IPv4 destination: IPv4 address of decapsulator
- 外部IPv4宛先：カプセル化解除装置のIPv4アドレス
- Inner IPv6 source: Alice, which is either the decapsulator or a node close to it
- 内部IPv6ソース：アリス（カプセル化解除装置またはそれに近いノード）
- Inner IPv6 destination: Bob
- 内部IPv6宛先：ボブ
Even if all IPv4 routers between the attacker and the decapsulator implement IPv4 ingress filtering, and all IPv6 routers between the decapsulator and Bob implement IPv6 ingress filtering, the above spoofed packets will not be filtered out. As a result, Bob will receive a packet that looks like it was sent from Alice even though the sender was some unrelated node.
攻撃者とカプセル開放装置間のすべてのIPv4ルーターがIPv4入力フィルタリングを実装し、カプセル開放装置とボブ間のすべてのIPv6ルーターがIPv6入力フィルタリングを実装する場合でも、上記のスプーフィングされたパケットはフィルタリングされません。その結果、送信者が無関係のノードであったとしても、ボブはアリスから送信されたように見えるパケットを受信します。
The solution to this is to have the decapsulator accept only encapsulated packets from the explicitly configured source address (i.e., the other end of the tunnel) as specified in Section 3.6. While this does not provide complete protection in the case ingress filtering has not been deployed, it does provide a significant increase in security. The issue and the remainder threats are discussed at more length in Security Considerations.
これに対する解決策は、3.6節で指定されているように、明示的に構成された送信元アドレス（つまり、トンネルのもう一方の端）からカプセル化されたパケットのみをカプセル化解除装置に受け入れさせることです。これは、イングレスフィルタリングが導入されていない場合の完全な保護を提供しませんが、セキュリティを大幅に向上させます。この問題と残りの脅威については、セキュリティに関する考慮事項で詳しく説明します。
Generic security considerations of using IPv6 are discussed in a separate document [V6SEC].
IPv6の使用に関する一般的なセキュリティの考慮事項は、別のドキュメント[V6SEC]で説明されています。
An implementation of tunneling needs to be aware that although a tunnel is a link (as defined in [RFC2460]), the threat model for a tunnel might be rather different than for other links, since the tunnel potentially includes all of the Internet.
トンネリングの実装では、トンネルはリンク（[RFC2460]で定義）ですが、トンネルにはすべてのインターネットが含まれている可能性があるため、トンネルの脅威モデルは他のリンクとはかなり異なる可能性があることに注意する必要があります。
Several mechanisms (e.g., Neighbor Discovery) depend on Hop Count being 255 and/or the addresses being link local for ensuring that a packet originated on-link, in a semi-trusted environment. Tunnels are more vulnerable to a breach of this assumption than physical links, as an attacker anywhere in the Internet can send an IPv6-in-IPv4 packet to the tunnel decapsulator, causing injection of an encapsulted IPv6 packet to the configured tunnel interface unless the decapsulation checks are able to discard packets injected in such a manner.
いくつかのメカニズム（たとえば、近隣探索）は、ホップ数が255であるか、パケットがリンク上で発信されたかを半信頼環境で確認するために、リンクローカルであるアドレスに依存します。トンネルは、物理リンクよりもこの想定の違反に対して脆弱です。これは、攻撃者がインターネットのどこでもIPv6-in-IPv4パケットをトンネルデカプセル化装置に送信できるため、カプセル化されていないIPv6パケットが、カプセル化解除されない限り、構成されたトンネルインターフェイスに注入されるためです。チェックは、そのような方法で注入されたパケットを破棄できます。
Therefore, this memo specifies that the decapsulators make these steps (as described in Section 3.6) to mitigate this threat:
したがって、このメモは、カプセル開放者がこの脅威を軽減するためにこれらの手順を実行することを指定しています（セクション3.6で説明）。
- IPv4 source address of the packet MUST be the same as configured for the tunnel end-point;
- パケットのIPv4送信元アドレスは、トンネルエンドポイント用に構成されたものと同じでなければなりません。
- Independent of any IPv4 ingress filtering the administrator may have configured, the implementation MAY perform IPv4 ingress filtering to check that the IPv4 packets are received from an expected interface (but as this may cause some problems, it may be disabled by default);
- 管理者が構成したIPv4イングレスフィルタリングとは関係なく、実装はIPv4イングレスフィルタリングを実行して、予想されるインターフェイスからIPv4パケットを受信したことを確認できます（ただし、これにより問題が発生する可能性があるため、デフォルトで無効になっている可能性があります）;
- IPv6 packets with several, obviously invalid IPv6 source addresses received from the tunnel MUST be discarded (see Section 3.6 for details); and
- トンネルから受信した、明らかに無効なIPv6送信元アドレスがいくつかあるIPv6パケットは、破棄する必要があります（詳細については、セクション3.6を参照）。そして
- IPv6 ingress filtering should be performed (typically requiring configuration from the operator), to check that the tunneled IPv6 packets are received from an expected interface.
- IPv6入力フィルタリングを実行して（通常はオペレーターからの構成が必要）、トンネル化されたIPv6パケットが予期されたインターフェースから受信されたことを確認する必要があります。
Especially the first verification is vital: to avoid this check, the attacker must be able to know the source of the tunnel (ranging from difficult to predictable) and be able to spoof it (easier).
特に最初の検証は非常に重要です。このチェックを回避するには、攻撃者はトンネルのソースを（困難から予測可能までの範囲で）知り、偽装（簡単）できる必要があります。
If the remainder threats of tunnel source verification are considered to be significant, a tunneling scheme with authentication should be used instead, e.g., IPsec [RFC2401] (preferable) or Generic Routing Encapsulation with a pre-configured secret key [RFC2890]. As the configured tunnels are set up more or less manually, setting up the keying material is probably not a problem. However, setting up secure IPsec IPv6-in-IPv4 tunnels is described in another document [V64IPSEC].
トンネルソース検証の残りの脅威が重要であると考えられる場合は、代わりに認証付きのトンネリングスキームを使用する必要があります。設定されたトンネルは多かれ少なかれ手動で設定されるため、キー情報の設定はおそらく問題ではありません。ただし、安全なIPsec IPv6-in-IPv4トンネルの設定については、別のドキュメント[V64IPSEC]で説明されています。
If the tunneling is done inside an administrative domain, proper ingress filtering at the edge of the domain can also eliminate the threat from outside of the domain. Therefore, shorter tunnels are preferable to longer ones, possibly spanning the whole Internet.
トンネリングが管理ドメイン内で行われる場合、ドメインのエッジで適切な入力フィルタリングを行うと、ドメイン外からの脅威も排除できます。したがって、インターネット全体に及ぶ可能性のある長いトンネルよりも短いトンネルの方が望ましいです。
In addition, an implementation MUST treat interfaces to different links as separate, e.g., to ensure that Neighbor Discovery packets arriving on one link do not affect other links. This is especially important for tunnel links.
さらに、実装では、異なるリンクへのインターフェースを別々に扱う必要があります。たとえば、1つのリンクに到着する近隣探索パケットが他のリンクに影響を与えないようにする必要があります。これは、トンネルリンクでは特に重要です。
When dropping packets due to failing to match the allowed IPv4 source addresses for a tunnel the node should not "acknowledge" the existence of a tunnel, otherwise this could be used to probe the acceptable tunnel endpoint addresses. For that reason, the specification says that such packets MUST be discarded, and an ICMP error message SHOULD NOT be generated, unless the implementation normally sends ICMP destination unreachable messages for unknown protocols; in such a case, the same code MAY be sent. As should be obvious, not returning the same ICMP code if an error is returned for other protocols may hint that the IPv6 stack (or the protocol 41 tunneling processing) has been enabled -- the behaviour should be consistent on how the implementation otherwise behaves to be transparent to probing.
トンネルの許可されたIPv4送信元アドレスとの一致に失敗したためにパケットをドロップする場合、ノードはトンネルの存在を「確認」してはなりません。それ以外の場合は、これを使用して、許容できるトンネルエンドポイントアドレスをプローブできます。そのため、仕様では、そのようなパケットは破棄する必要があるとし、実装が通常は不明なプロトコルのICMP宛先到達不能メッセージを送信しない限り、ICMPエラーメッセージを生成してはならない（SHOULD NOT）。このような場合、同じコードが送信される場合があります。明らかなように、他のプロトコルでエラーが返された場合に同じICMPコードを返さないと、IPv6スタック（またはプロトコル41トンネリング処理）が有効になっていることが示唆される可能性があります。調査に対して透過的です。
We would like to thank the members of the IPv6 working group, the Next Generation Transition (ngtrans) working group, and the v6ops working group for their many contributions and extensive review of this document. Special thanks are due to (in alphabetical order) Jim Bound, Ross Callon, Tim Chown, Alex Conta, Bob Hinden, Bill Manning, John Moy, Mohan Parthasarathy, Chirayu Patel, Pekka Savola, and Fred Templin for many helpful suggestions. Pekka Savola helped in editing the final revisions of the specification.
IPv6ワーキンググループ、Next Generation Transition（ngtrans）ワーキンググループ、およびv6opsワーキンググループのメンバーに、このドキュメントの多くの貢献と広範なレビューに感謝します。ジムバウンド、ロスキャロン、ティムチョウ、アレックスコンタ、ボブヒンデン、ビルマニング、ジョンモイ、モハンパルタサラシー、チラユパテル、ペッカサボラ、フレッドテンプリンの多くの有益な提案に特に感謝します。 Pekka Savolaは、仕様の最終リビジョンの編集を支援しました。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[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月。
[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月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[RFC2463] Conta、A。およびS. Deering、「インターネット制御メッセージプロトコル（ICMPv6）、インターネットプロトコルバージョン6（IPv6）仕様」、RFC 2463、1998年12月。
[ASSIGNED] IANA, "Assigned numbers online database",
http://www.iana.org/numbers.html
[DNSOPV6] Durand, A., Ihren, J., and Savola P., "Operational Considerations and Issues with IPv6 DNS", Work in Progress, October 2004.
[DNSOPV6] Durand、A.、Ihren、J。、およびSavola P.、「運用上の考慮事項とIPv6 DNSに関する問題」、Work in Progress、2004年10月。
[KM97] Kent, C., and J. Mogul, "Fragmentation Considered Harmful". In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology. August 1987.
[KM97]ケント、C、およびJ.モーグル、「フラグメンテーションは有害と見なされる」。手続き中コンピュータ通信技術のフロンティアに関するSIGCOMM '87ワークショップ。 1987年8月。
[V6SEC] Savola, P., "IPv6 Transition/Co-existence Security Considerations", Work in Progress, October 2004.
[V6SEC] Savola、P。、「IPv6移行/共存セキュリティの考慮事項」、作業中、2004年10月。
[V64IPSEC] Graveman, R., et al., "Using IPsec to Secure IPv6-over-IPv4 Tunnels", Work in Progress, December 2004.
[V64IPSEC] Graveman、R.、et al。、「Using IPsec to Secure IPv6-over-IPv4 Tunnels」、Work in Progress、2004年12月。
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
[RFC1435] Knowles、S。、「Path MTU Discoveryの経験からのIESGアドバイス」、RFC 1435、1993年3月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S。、およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten、T.、Nordmark、E。、およびW. Simpson、「Neighbor Discovery for IP Version 6（IPv6）」、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462] Thomson、S.およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[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月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890] Dommety、G。、「GREのキーとシーケンス番号の拡張」、RFC 2890、2000年9月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923] Lahey、K。、「Path MTU Discoveryに関するTCPの問題」、RFC 2923、2000年9月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、D。、「Differentiated Services and Tunnels」、RFC 2983、2000年10月。
[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月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232] Reynolds、J。、「割り当てられた番号：RFC 1700はオンラインデータベースに置き換えられました」、RFC 3232、2002年1月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J.、and W. Stevens、 "Basic Socket Interface Extensions for IPv6"、RFC 3493、2003年2月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513] Hinden、R。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「DNS Extensions to Support IP Version 6」、RFC 3596、2003年10月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F。、およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、2004年3月。
[RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005.
[RFC4087]ターラー、D。、「IPトンネルMIB」、RFC 4087、2005年6月。
The motivation for the bulk of these changes are to simplify the document to only contain the mechanisms of wide-spread use.
これらの変更の大部分の動機は、広範囲に使用されるメカニズムのみを含むようにドキュメントを簡略化することです。
RFC 2893 contains a mechanism called automatic tunneling. But a much more general mechanism is specified in RFC 3056 [RFC3056] which gives each node with a (global) IPv4 address a /48 IPv6 prefix i.e., enough for a whole site.
RFC 2893には、自動トンネリングと呼ばれるメカニズムが含まれています。しかし、はるかに一般的なメカニズムがRFC 3056 [RFC3056]で指定されており、（グローバル）IPv4アドレスを持つ各ノードに/ 48 IPv6プレフィックス、つまりサイト全体に十分なものを与えます。
The following changes have been performed since RFC 2893:
RFC 2893以降、次の変更が行われています。
- Removed references to A6 and retained AAAA.
- A6への参照を削除し、AAAAを保持。
- Removed automatic tunneling and use of IPv4-compatible addresses.
- 自動トンネリングとIPv4互換アドレスの使用を削除しました。
- Removed default Configured Tunnel using IPv4 "Anycast Address"
- IPv4「エニーキャストアドレス」を使用してデフォルトの構成済みトンネルを削除しました
- Removed Source Address Selection section since this is now covered by another document ([RFC3484]).
- これは別のドキュメント（[RFC3484]）でカバーされているため、送信元アドレス選択セクションを削除しました。
- Removed brief mention of 6over4.
- 6over4の簡単な説明を削除しました。
- Split into normative and non-normative references and other reference cleanup.
- 規範的および非規範的参照に分割し、その他の参照クリーンアップ。
- Dropped "or equal" in if (IPv4 path MTU - 20) is less than or equal to 1280.
- （IPv4パスMTU-20）が1280以下の場合、「または等しい」は削除されました。
- Dropped this: 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.
- これを削除：ただし、IPv6は、IPv4との相互運用性が不要な一部の環境で使用される場合があります。このような環境で使用するように設計されたIPv6ノードは、これらのメカニズムを使用したり、実装したりする必要はありません。
- Described Static MTU and Dynamic MTU cases separately; clarified that the dynamic path MTU mechanism is OPTIONAL but if it is implemented it should follow the rules in section 3.2.2.
- 静的MTUと動的MTUのケースを個別に説明しました。ダイナミックパスMTUメカニズムはオプションであることを明確にしましたが、実装する場合は、セクション3.2.2のルールに従う必要があります。
- Specified Static MTU to default to a MTU of 1280 to 1480 bytes, and that this may be configurable. Discussed the issues with using Static MTU at more length.
- デフォルトで1280から1480バイトのMTUになるように静的MTUを指定しました。これは構成可能である可能性があります。静的MTUをより長く使用する場合の問題について説明しました。
- Specified minimal rules for IPv4 reassembly and IPv6 MRU to enhance interoperability and to minimize blacholes.
- 相互運用性を高め、ブラコレスを最小限に抑えるために、IPv4の再構成とIPv6 MRUに指定された最小限のルール。
- Restated the "currently underway" language about Type-of-Service, and loosely point at [RFC2983] and [RFC3168].
- Type-of-Serviceに関する「現在進行中の」言語を再表現し、[RFC2983]と[RFC3168]を大まかにポイントしました。
- Fixed reference to Assigned Numbers to be to online version (with proper pointer to "Assigned Numbers is obsolete" RFC).
- オンラインバージョンに割り当てられた番号への参照が修正されました（「割り当てられた番号は廃止されました」RFCへの適切なポインタを使用）。
- Clarified text about ingress filtering e.g., that it applies to packet delivered to transport protocols on the decapsulator as well as packets being forwarded by the decapsulator, and how the decapsulator's checks help when IPv4 and IPv6 ingress filtering is in place.
- イングレスフィルタリングに関する説明を明確にしました。たとえば、カプセル化解除装置のトランスポートプロトコルに配信されるパケットと、カプセル化解除装置によって転送されるパケットに適用されること、およびIPv4およびIPv6の入力フィルタリングが行われているときにカプセル化解除装置のチェックがどのように役立つかを説明しました。
- Removed unidirectional tunneling; assume all tunnels are bidirectional, between endpoint addresses (not nodes).
- 単方向トンネリングが削除されました。 （ノードではなく）エンドポイントアドレス間ですべてのトンネルが双方向であると想定します。
- Removed the guidelines for advertising addresses in DNS as slightly out of scope, referring to another document for the details.
- 詳細については別のドキュメントを参照して、DNSでアドレスをわずかに範囲外としてアドバタイズするためのガイドラインを削除しました。
- Removed the SHOULD requirement that the link-local addresses should be formed based on IPv4 addresses.
- リンクローカルアドレスをIPv4アドレスに基づいて形成する必要があるというSHOULD要件を削除しました。
- Added a SHOULD for implementing a knob to be able to set the source address of the tunnel, and add discussion why this is useful.
- トンネルの送信元アドレスを設定できるようにノブを実装するためのSHOULDを追加し、これが役立つ理由についての説明を追加しました。
- Added stronger wording for source address checks: both IPv4 and IPv6 source addresses MUST be checked, and RPF-like ingress filtering is optional.
- 送信元アドレスチェックの表現を強化しました。IPv4とIPv6の両方の送信元アドレスを確認する必要があり、RPFのような入力フィルタリングはオプションです。
- Rewrote security considerations to be more precise about the threats of tunneling.
- セキュリティの考慮事項を書き直し、トンネリングの脅威についてより正確にしました。
- Added a note about considering using TTL=255 when encapsulating.
- カプセル化時にTTL = 255の使用を検討することに関するメモを追加しました。
- Added more discussion in Section 3.2 why using an "infinite" IPv6 MTU leads to likely interoperability problems.
- セクション3.2に、「無限」のIPv6 MTUを使用すると相互運用性の問題が発生する可能性がある理由についての説明を追加しました。
- Added an explicit requirement that if both MTU determination methods are used, choosing one should be possible on a per-tunnel basis.
- 両方のMTU決定方法を使用する場合、トンネルごとに1つを選択できるようにする必要があるという明示的な要件を追加しました。
- Clarified that ICMPv4 error handling is only applicable to dynamic MTU determination.
- ICMPv4エラー処理は動的MTU決定にのみ適用できることを明確にしました。
- Removed/clarified DNS record filtering; an API is a SHOULD and if it does not exist, MUST NOT filter anything. Decree ordering out of scope, but refer to RFC3484.
- 削除/明確化されたDNSレコードフィルタリング。 APIはSHOULDであり、存在しない場合は何もフィルタリングしてはなりません（MUST NOT）。命令は範囲外ですが、RFC3484を参照してください。
- Add a note that the destination IPv4 address could also be a multicast address.
- 宛先IPv4アドレスがマルチキャストアドレスである可能性があるというメモを追加します。
- Make it RECOMMENDED to provide a toggle to perform strict ingress filtering on an interface.
- インターフェイスで厳密な入力フィルタリングを実行するためのトグルを提供することをお勧めします。
- Generalize the text on the data in ICMPv4 messages.
- ICMPv4メッセージ内のデータに関するテキストを一般化します。
- Made a lot of miscellaneous editorial cleanups.
- さまざまな編集上の整理を行いました。
Authors' Addresses
著者のアドレス
Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park, CA 94025 USA
Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park、CA 94025 USA
Phone: +1 650 786 2921
EMail: erik.nordmark@sun.com
Robert E. Gilligan Intransa, Inc. 2870 Zanker Rd., Suite 100 San Jose, CA 95134 USA
Robert E. Gilligan Intransa、Inc. 2870 Zanker Rd。、Suite 100 San Jose、CA 95134 USA
Phone : +1 408 678 8600
Fax : +1 408 678 8800
EMail: bob.gilligan@acm.org
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
Copyright（C）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または組織（ある場合）、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に後援します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。