IPv6ホストとルーターの基本的な移行メカニズム
英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。
日本語訳
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を廃止します。
Nordmark & Gilligan Standards Track [Page 1]
RFC 4213 Basic IPv6 Transition Mechanisms October 2005
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
1.はじめに............................................... ..... 2
1.1.用語................................................ 3
2.デュアルIPレイヤー操作......................................... 4
2.1.アドレス構成................................................ 5
2.2. DNS ................................................. ....... 5
3.設定されたトンネリングメカニズム............................... 6
3.1.カプセル化........................................................ 7
3.2.トンネルMTUとフラグメンテーション............................... 8
3.2.1.静的トンネルMTU ................................... 9
3.2.2.動的トンネルMTU ................................................ 9
3.3.ホップ限界................................................ .11
3.4. ICMPv4エラーの処理.................................... 11
3.5. IPv4ヘッダーの構成.................................................. 13
3.6.カプセル開放....................................................... 14
3.7.リンクローカルアドレス...................................... 17
3.8トンネルを介した近隣探索........................... 18
4.発信元アドレスのなりすましに関連する脅威...................... 18
5.セキュリティに関する考慮事項................................ 19
6.謝辞............................................... 21
7.参考資料......................................................... ...... 21
7.1.規範的な参照................................................ 21
7.2.有益な参照................................................. 21
8. RFC 2893からの変更点.......................................... 23
1. Introduction
1.はじめに
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）の両方を完全にサポートするための手法。
Nordmark & Gilligan Standards Track [Page 2]
RFC 4213 Basic IPv6 Transition Mechanisms October 2005
- 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.
このドキュメントでは、移行メカニズムの基本セットを定義していますが、利用可能なツールはこれらだけではありません。 追加の移行および互換性メカニズムは、他のドキュメントで指定されています。
1.1. Terminology
1.1。 用語
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:
IPv6ノード：
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ノードです。
Nordmark & Gilligan Standards Track [Page 3] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 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].
このドキュメントに記載されているキーワードは、必須、必須、必須、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、およびOPTIONALであり、[RFC2119]で説明されているように解釈されます。
2. Dual IP Layer Operation
2.デュアルIPレイヤー操作
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 Nordmark & Gilligan Standards Track [Page 4] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 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レイヤー操作に加えて使用することも、使用しないこともあります。
2.1. Address Configuration
2.1。 アドレス構成
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アドレスを取得します。
2.2. DNS
2.2。 DNS
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バージョンの「設定」に影響を与える可能性があります。
Nordmark & Gilligan Standards Track [Page 5] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 The actual ordering mechanisms are out of scope of this memo. Address selection is described at more length in [RFC3484].
実際の順序付けメカニズムはこのメモの範囲外です。 アドレス選択については、[RFC3484]で詳しく説明しています。
3. Configured Tunneling Mechanisms
3.設定されたトンネリングメカニズム
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パケットを処理します。
Nordmark & Gilligan Standards Track [Page 6]
RFC 4213 Basic IPv6 Transition Mechanisms October 2005
- 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アドレス構成がカプセル化装置とカプセル開放装置の両方で同じであることを確認する必要があります。
3.1. Encapsulation
3.1。 カプセル化
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のカプセル化
Nordmark & Gilligan Standards Track [Page 7] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 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.
これらの問題については、次のセクションで説明します。
3.2. Tunnel MTU and Fragmentation
3.2。 トンネルMTUとフラグメンテーション
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（最大65535-20バイト、カプセル化IPv4ヘッダーには20バイトの「追加」が必要）を持つリンク層としてIPv4を使用して、カプセル化をIPv6として表示できます。 カプセル化装置は、このMTUを超えるパケットについて、ICMPv6の「パケットが大きすぎる」エラーを送信元に報告するだけで済みます。 ただし、このようなスキームは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を持つインターフェースとして扱わないでください。代わりに、固定静的MTUまたはトンネルエンドポイントへのIPv4パスMTUに基づくオプションの動的MTU決定を使用してください。
If both the mechanisms are implemented, the decision of which to use SHOULD be configurable on a per-tunnel endpoint basis.
両方のメカニズムが実装されている場合、どちらを使用するかの決定は、トンネルエンドポイントごとに構成可能である必要があります。
Nordmark & Gilligan Standards Track [Page 8] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 3.2.1. Static Tunnel MTU
3.2.1。 静的トンネルMTU
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ビットを設定しないでください。 その結果、カプセル化されたパケットの結果として、カプセル化プログラムはICMPv4の「パケットが大きすぎます」メッセージを受信しません。
3.2.2. Dynamic Tunnel MTU
3.2.2。 動的トンネルMTU
The dynamic MTU determination is OPTIONAL. However, if it is implemented, it SHOULD have the behavior described in this document.
動的MTUの決定はオプションです。 ただし、実装されている場合は、このドキュメントで説明されている動作を行う必要があります。
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 Nordmark & Gilligan Standards Track [Page 9] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 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発見プロトコル[RFC1191]を使用し、結果のパスMTUを記録して、カプセル化装置にトンネル全体のIPv4パス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レイヤーはMTUが1280バイトのリンクレイヤーを「確認」する必要があり、カプセル化機能は1280バイトのIPv6パケットを転送するためにIPv4フラグメンテーションを使用する必要があります。
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].
ダイナミックトンネルMTUの使用は、ファイアウォールによってICMPv4の「パケットが大きすぎる」メッセージがドロップされたり、ルーターによって生成されなかったりした場合にIPv4パスMTUブラックホールの影響を受けることに注意してください[RFC1435、RFC2923]。
Nordmark & Gilligan Standards Track [Page 10] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 3.3. Hop Limit
3.3。 ホップ制限
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は、実装依存の方法で選択されます。 現在の推奨値は、「割り当て番号」RFC [RFC3232] [ASSIGNED]で公開されています。 実装は、管理者がIPv4 TTLをIPトンネルMIB [RFC4087]として構成できるようにするメカニズムを提供してもよい（MAY）。
3.4. Handling ICMPv4 Errors
3.4。 ICMPv4エラーの処理
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]を参照してください。
Nordmark & Gilligan Standards Track [Page 11] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 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エラーを受信し、エラーが「パケットが大きすぎない」場合、トンネルに関連するエラーとしてエラーを記録すると便利です。 また、十分なヘッダーが利用可能な場合、発信ノードは、コード「address unreachable」でタイプ「unreachable」の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 Nordmark & Gilligan Standards Track [Page 12] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 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を学習する必要があります。 それでも、複数の大きなパケットが同時に飛行している場合は、すべてのケースで複数のパケット損失が発生する可能性があります。
3.5. IPv4 Header Construction
3.5。 IPv4ヘッダーの構築
When encapsulating an IPv6 packet in an IPv4 datagram, the IPv4 header fields are set as follows:
IPv6パケットをIPv4データグラムにカプセル化する場合、IPv4ヘッダーフィールドは次のように設定されます。
Version:
バージョン：
4
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で説明されているように、実装固有の方法で設定します。
Nordmark & Gilligan Standards Track [Page 13]
RFC 4213 Basic IPv6 Transition Mechanisms October 2005
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で説明されているように、パケットがデカプセル化装置に受け入れられるように、正しい送信元アドレスを使用することを確認する必要があります。 送信元アドレスの設定は、送信元アドレスの自動選択が一定の期間内に異なる結果を生成する可能性がある場合に特に適しています。 これは、複数のアドレス、複数のインターフェース、またはルートが頻繁に変更される場合によく見られます。 したがって、管理者がトンネルの送信元アドレスを指定できるようにする必要があります。
3.6. Decapsulation
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）。
Nordmark & Gilligan Standards Track [Page 14] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 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]。 これにより、複数のリンクを介してルーティングされるトンネルで問題が発生する可能性があるため、このチェックを行う場合、デフォルトで無効にすることをお勧めします。 このチェックでキャッチされたパケットは破棄する必要があります。 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を利用できます。 実装は、上記の数よりも大きなトンネル再構成バッファーの値を設定するために使用できる構成ノブを持つことができます（MAY）が、上記の数より下に設定してはなりません（MUST NOT）。
Nordmark & Gilligan Standards Track [Page 15] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 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)
すべてのIPv4マップIPv6アドレス（:: ffff：0：0/96）
Nordmark & Gilligan Standards Track [Page 16] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 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.:
さらに、ノードは、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.
実装が単一のノブを提供して、管理者がエッジネットワークへの厳密な入力フィルタリングを簡単に有効にできるようにすることをお勧めします。
3.7. Link-Local Addresses
3.7。 リンクローカルアドレス
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 Nordmark & Gilligan Standards Track [Page 17] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 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 |
+-------+-------+-------+-------+-------+-------+------+------+
3.8. Neighbor Discovery over Tunnels
3.8 トンネルを介した近隣探索
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.
リンク層アドレスオプションを使用しないことは、他のポイントツーポイントリンクでの近隣探索の使用方法と一致しています。
4. Threat Related to Source Address Spoofing
4.送信元アドレスのなりすましに関連する脅威
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で入力フィルタリングを使用するかどうかに基づいて導出されます。トンネリングを使用しても、フィルタリングを回避する簡単な方法は提供されません。
Nordmark & Gilligan Standards Track [Page 18] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 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節で指定されているように、明示的に構成されたソースアドレス（つまり、トンネルのもう一方の端）からカプセル化されたパケットのみをカプセル化解除者に受け入れさせることです。 これは、イングレスフィルタリングが展開されていない場合に完全な保護を提供するわけではありませんが、セキュリティを大幅に向上させます。 この問題と残りの脅威については、セキュリティに関する考慮事項で詳しく説明します。
5. Security Considerations
5.セキュリティに関する考慮事項
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パケットがカプセル化解除されない限り、構成されたトンネルインターフェイスに注入されるためです チェックは、そのような方法で注入されたパケットを破棄できます。
Nordmark & Gilligan Standards Track [Page 19] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 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 [RFC2401]（推奨）または事前構成された秘密鍵を使用したGeneric Routing Encapsulation [RFC2890]などです。 設定されたトンネルは多かれ少なかれ手動で設定されるため、キー情報の設定はおそらく問題ではありません。 ただし、安全な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 Nordmark & Gilligan Standards Track [Page 20] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 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トンネリング処理）が有効になっていることが示唆される可能性があります。 調査に対して透過的です。
6. Acknowledgements
6.謝辞
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.
7. References
7.リファレンス
7.1. Normative References
7.1。 規範的な参考文献
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2463] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
7.2. Informative References
7.2。 参考情報
[ASSIGNED] IANA, "Assigned numbers online database",
http://www.iana.org/numbers.html
Nordmark & Gilligan Standards Track [Page 21]
RFC 4213 Basic IPv6 Transition Mechanisms October 2005
[DNSOPV6] Durand, A., Ihren, J., and Savola P., "Operational
Considerations and Issues with IPv6 DNS", Work in
Progress, October 2004.
[KM97] Kent, C., and J. Mogul, "Fragmentation Considered
Harmful". In Proc. SIGCOMM '87 Workshop on Frontiers in
Computer Communications Technology. August 1987.
[V6SEC] Savola, P., "IPv6 Transition/Co-existence Security
Considerations", Work in Progress, October 2004.
[V64IPSEC] Graveman, R., et al., "Using IPsec to Secure IPv6-over-
IPv4 Tunnels", Work in Progress, December 2004.
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[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.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
Nordmark & Gilligan Standards Track [Page 22]
RFC 4213 Basic IPv6 Transition Mechanisms October 2005
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC
3493, February 2003.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005.
8. Changes from RFC 2893
8. RFC 2893からの変更
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の簡単な説明を削除しました。
Nordmark & Gilligan Standards Track [Page 23]
RFC 4213 Basic IPv6 Transition Mechanisms October 2005
- 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要件を削除しました。
Nordmark & Gilligan Standards Track [Page 24]
RFC 4213 Basic IPv6 Transition Mechanisms October 2005
- 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.
さまざまな編集上の整理を行いました。
Nordmark & Gilligan Standards Track [Page 25] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 Authors' Addresses 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 Phone : +1 408 678 8600 Fax : +1 408 678 8800 EMail: bob.gilligan@acm.org Nordmark & Gilligan Standards Track [Page 26] RFC 4213 Basic IPv6 Transition Mechanisms October 2005 Full Copyright Statement 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. 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. 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. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Nordmark & Gilligan Standards Track [Page 27]