IPv4 / IPv6トランスレータのIPv6アドレス指定
英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。
日本語訳
Internet Engineering Task Force (IETF) C. Bao
Request for Comments: 6052 CERNET Center/Tsinghua University
Updates: 4291 C. Huitema
Category: Standards Track Microsoft Corporation
ISSN: 2070-1721 M. Bagnulo
UC3M
M. Boucadair
France Telecom
X. Li
CERNET Center/Tsinghua University
October 2010
IPv6 Addressing of IPv4/IPv6 Translators
IPv4 / IPv6トランスレータのIPv6アドレス指定
Abstract
概要
This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios.
このドキュメントでは、静的に構成された情報のみを使用して、IPv6アドレスを対応するIPv4アドレスに、またはその逆にアルゴリズム変換する方法について説明します。 アルゴリズム変換で使用する既知のプレフィックスを定義し、必要に応じて組織がネットワーク固有のプレフィックスも使用できるようにします。 アルゴリズム変換は、IPv4 / IPv6トランスレーターで使用されるほか、IPv4 / IPv6シナリオで使用される他のタイプのプロキシおよびゲートウェイ（DNS用など）でも使用されます。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。 これは、IETFコミュニティのコンセンサスを表しています。 これは公開レビューを受けており、Internet Engineering Steering Group（IESG）による公開が承認されています。 インターネット標準の詳細については、RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6052.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6052で入手できます。
Bao, et al. Standards Track [Page 1] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよびドキュメントの作成者として識別された人物。 全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . . 5
2.1. Well-Known Prefix . . . . . . . . . . . . . . . . . . . . 5
2.2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . 5
2.3. Address Translation Algorithms . . . . . . . . . . . . . . 7
2.4. Text Representation . . . . . . . . . . . . . . . . . . . 7
3. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 8
3.1. Restrictions on the Use of the Well-Known Prefix . . . . . 8
3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8
3.3. Choice of Prefix for Stateless Translation Deployments . . 9
3.4. Choice of Prefix for Stateful Translation Deployments . . 11
4. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 12
4.2. Choice of the Well-Known Prefix . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Protection against Spoofing . . . . . . . . . . . . . . . 14
5.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 15
5.3. Firewall Configuration . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
1.はじめに. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.適用範囲. . . . . . . . . . . . . . . . . . . 3
1.2.規約. . . . . . . . . . . . . . . . . . . . . . . 4
1.3.用語. . . . . . . . . . . . . . . . . . . . . . . 4
2. IPv4-Embedded IPv6アドレスのプレフィックスと形式. . . . . . . . . 5
2.1.既知のプレフィックス. . . . . . . . . . . . . . . . . . . . 5
2.2. IPv4-Embedded IPv6 Address Format. . . . . . . . . . . . 5
2.3.アドレス変換アルゴリズム. . . . . . . . . . . . . . 7
2.4.テキスト表現. . . . . . . . . . . . . . . . . . . 7
3.導入ガイドライン. . . . . . . . . . . . . . . . . . . . 8
3.1.既知のプレフィックスの使用に関する制限. . . . . 8
3.2.ドメイン間ルーティングへの影響. . . . . . . . . . . . . . 8
3.3.ステートレスな翻訳展開のためのプレフィックスの選択. . 9
3.4.ステートフルな翻訳の展開のためのプレフィックスの選択. . 11
4.デザインの選択. . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.サフィックスの選択. . . . . . . . . . . . . . . . . . . . . 12
4.2.既知のプレフィックスの選択. . . . . . . . . . . . . 13
5.セキュリティに関する考慮事項. . . . . . . . . . . . . . . . . . . 14
5.1.なりすましに対する保護. . . . . . . . . . . . . . . 14
5.2.安全な構成. . . . . . . . . . . . . . . . . . . 15
5.3.ファイアウォール設定. . . . . . . . . . . . . . . . . . 15
6. IANAの考慮事項. . . . . . . . . . . . . . . . . . . . . 15
7.謝辞. . . . . . . . . . . . . . . . . . . . . . . 16
8.寄稿者. . . . . . . . . . . . . . . . . . . . . . . . . 16
9.参考資料. . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1.規範的な参照. . . . . . . . . . . . . . . . . . . 17
9.2.有益な参照. . . . . . . . . . . . . . . . . . 17
Bao, et al. Standards Track [Page 2] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 1. Introduction
1.はじめに
This document is part of a series of IPv4/IPv6 translation documents. A framework for IPv4/IPv6 translation is discussed in [v4v6-FRAMEWORK], including a taxonomy of scenarios that will be used in this document. Other documents specify the behavior of various types of translators and gateways, including mechanisms for translating between IP headers and other types of messages that include IP addresses. This document specifies how an individual IPv6 address is translated to a corresponding IPv4 address, and vice versa, in cases where an algorithmic mapping is used. While specific types of devices are used herein as examples, it is the responsibility of the specification of such devices to reference this document for algorithmic mapping of the addresses themselves.
このドキュメントは、一連のIPv4 / IPv6変換ドキュメントの一部です。 IPv4 / IPv6変換のフレームワークは、[v4v6-FRAMEWORK]で説明されており、このドキュメントで使用されるシナリオの分類法も含まれています。 他のドキュメントでは、IPヘッダーとIPアドレスを含む他のタイプのメッセージとの間の変換メカニズムを含む、さまざまなタイプのトランスレータおよびゲートウェイの動作を指定しています。 このドキュメントでは、アルゴリズムマッピングを使用する場合に、個々のIPv6アドレスを対応するIPv4アドレスに変換する方法、およびその逆の変換方法について説明します。 ここでは例として特定のタイプのデバイスを使用していますが、アドレス自体のアルゴリズムマッピングについてこのドキュメントを参照するのは、そのようなデバイスの仕様の責任です。
Section 2 describes the prefixes and the format of "IPv4-embedded IPv6 addresses", i.e., IPv6 addresses in which 32 bits contain an IPv4 address. This format is common to both "IPv4-converted" and "IPv4-translatable" IPv6 addresses. This section also defines the algorithms for translating addresses, and the text representation of IPv4-embedded IPv6 addresses.
セクション2では、「IPv4埋め込みIPv6アドレス」のプレフィックスと形式について説明します。つまり、32ビットにIPv4アドレスが含まれるIPv6アドレスです。 この形式は、「IPv4変換」および「IPv4変換可能」IPv6アドレスの両方に共通です。 このセクションでは、アドレスを変換するアルゴリズムと、IPv4埋め込みIPv6アドレスのテキスト表現も定義します。
Section 3 discusses the choice of prefixes, the conditions in which they can be used, and the use of IPv4-embedded IPv6 addresses with stateless and stateful translation.
セクション3では、プレフィックスの選択、プレフィックスを使用できる条件、およびステートレスおよびステートフル変換でのIPv4埋め込みIPv6アドレスの使用について説明します。
Section 4 provides a summary of the discussions behind two specific design decisions, the choice of a null suffix and the specific value of the selected prefix.
セクション4では、ヌルサフィックスの選択と選択したプレフィックスの特定の値という2つの特定の設計上の決定の背後にある議論の概要を示します。
Section 5 discusses security concerns.
セクション5では、セキュリティの問題について説明します。
In some scenarios, a dual-stack host will unnecessarily send its traffic through an IPv6/IPv4 translator. This can be caused by the host's default address selection algorithm [RFC3484], referrals, or other reasons. Optimizing these scenarios for dual-stack hosts is for future study.
一部のシナリオでは、デュアルスタックホストがIPv6 / IPv4トランスレータを介して不必要にトラフィックを送信します。 これは、ホストのデフォルトのアドレス選択アルゴリズム[RFC3484]、参照、またはその他の理由が原因である可能性があります。 これらのシナリオをデュアルスタックホスト用に最適化することは、将来の研究のためです。
1.1. Applicability Scope
1.1。 適用範囲
This document is part of a series defining address translation services. We understand that the address format could also be used by other interconnection methods between IPv6 and IPv4, e.g., methods based on encapsulation. If encapsulation methods are developed by the IETF, we expect that their descriptions will document their specific use of IPv4-embedded IPv6 addresses.
このドキュメントは、アドレス変換サービスを定義するシリーズの一部です。 アドレス形式は、カプセル化に基づく方法など、IPv6とIPv4の間の他の相互接続方法でも使用できることを理解しています。 カプセル化方式がIETFによって開発されている場合、その説明には、IPv4埋め込みIPv6アドレスの特定の使用法が記載されていると予想されます。
Bao, et al. Standards Track [Page 3] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 1.2. Conventions
1.2。 規約
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
1.3. Terminology
1.3。 用語
This document makes use of the following terms:
このドキュメントでは、次の用語を使用しています。
Address translator: any entity that has to derive an IPv4 address
from an IPv6 address or vice versa. This applies not only to
devices that do IPv4/IPv6 packet translation, but also to other
entities that manipulate addresses, such as name resolution
proxies (e.g., DNS64 [DNS64]) and possibly other types of
Application Layer Gateways (ALGs).
アドレストランスレータ：IPv4アドレスをIPv6アドレスから、またはその逆に導出する必要があるエンティティ。 これは、IPv4 / IPv6パケット変換を行うデバイスだけでなく、名前解決プロキシ（DNS64 [DNS64]など）や他のタイプのアプリケーションレイヤーゲートウェイ（ALG）など、アドレスを操作する他のエンティティにも適用されます。
IPv4-converted IPv6 addresses: IPv6 addresses used to represent IPv4
nodes in an IPv6 network. They are a variant of IPv4-embedded
IPv6 addresses and follow the format described in Section 2.2.
IPv4変換IPv6アドレス：IPv6ネットワークでIPv4ノードを表すために使用されるIPv6アドレス。 これらはIPv4埋め込みIPv6アドレスのバリアントであり、セクション2.2で説明されているフォーマットに従います。
IPv4-embedded IPv6 addresses: IPv6 addresses in which 32 bits
contain an IPv4 address. Their format is described in
Section 2.2.
IPv4埋め込みIPv6アドレス：32ビットにIPv4アドレスが含まれるIPv6アドレス。 その形式については、セクション2.2で説明します。
IPv4/IPv6 translator: an entity that translates IPv4 packets to IPv6
packets, and vice versa. It may do "stateless" translation,
meaning that there is no per-flow state required, or "stateful"
translation, meaning that per-flow state is created when the first
packet in a flow is received.
IPv4 / IPv6トランスレータ：IPv4パケットをIPv6パケットに、またはその逆に変換するエンティティ。 フローごとの状態が必要ないことを意味する「ステートレス」変換、またはフロー内の最初のパケットが受信されたときにフローごとの状態が作成されることを意味する「ステートフル」変換を行う場合があります。
IPv4-translatable IPv6 addresses: IPv6 addresses assigned to IPv6
nodes for use with stateless translation. They are a variant of
IPv4-embedded IPv6 addresses and follow the format described in
Section 2.2.
IPv4変換可能なIPv6アドレス：ステートレス変換で使用するためにIPv6ノードに割り当てられたIPv6アドレス。 これらはIPv4埋め込みIPv6アドレスのバリアントであり、セクション2.2で説明されているフォーマットに従います。
Network-Specific Prefix: an IPv6 prefix assigned by an organization
for use in algorithmic mapping. Options for the Network-Specific
Prefix are discussed in Sections 3.3 and 3.4.
ネットワーク固有のプレフィックス：アルゴリズムマッピングで使用するために組織によって割り当てられたIPv6プレフィックス。 ネットワーク固有のプレフィックスのオプションについては、セクション3.3および3.4で説明します。
Well-Known Prefix: the IPv6 prefix defined in this document for use
in an algorithmic mapping.
Well-Known Prefix：このドキュメントで定義されている、アルゴリズムマッピングで使用するためのIPv6プレフィックス。
Bao, et al. Standards Track [Page 4] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 2. IPv4-Embedded IPv6 Address Prefix and Format
2. IPv4-Embedded IPv6アドレスのプレフィックスと形式
2.1. Well-Known Prefix
2.1。 既知のプレフィックス
This document reserves a "Well-Known Prefix" for use in an algorithmic mapping. The value of this IPv6 prefix is:
このドキュメントでは、アルゴリズムマッピングで使用するための「既知のプレフィックス」を予約しています。 このIPv6プレフィックスの値は次のとおりです。
64:ff9b::/96
2.2. IPv4-Embedded IPv6 Address Format
2.2。 IPv4-Embedded IPv6アドレス形式
IPv4-converted IPv6 addresses and IPv4-translatable IPv6 addresses follow the same format, described here as the IPv4-embedded IPv6 address Format. IPv4-embedded IPv6 addresses are composed of a variable-length prefix, the embedded IPv4 address, and a variable- length suffix, as presented in the following diagram, in which PL designates the prefix length:
IPv4変換されたIPv6アドレスとIPv4変換可能なIPv6アドレスは、ここでIPv4埋め込みIPv6アドレス形式と同じ形式に従います。 次の図に示すように、IPv4埋め込みIPv6アドレスは、可変長プレフィックス、埋め込みIPv4アドレス、および可変長サフィックスで構成されます。PLはプレフィックス長を指定します。
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|32| prefix |v4(32) | u | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|40| prefix |v4(24) | u |(8)| suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|48| prefix |v4(16) | u | (16) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|56| prefix |(8)| u | v4(24) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|64| prefix | u | v4(32) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|96| prefix | v4(32) |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 1
図1
In these addresses, the prefix shall be either the "Well-Known Prefix" or a "Network-Specific Prefix" unique to the organization deploying the address translators. The prefixes can only have one of the following lengths: 32, 40, 48, 56, 64, or 96. (The Well-Known Prefix is 96 bits long, and can only be used in the last form of the table.)
これらのアドレスでは、プレフィックスは、アドレス変換器を展開する組織に固有の「既知のプレフィックス」または「ネットワーク固有のプレフィックス」のいずれかになります。 プレフィックスの長さは、32、40、48、56、64、または96のいずれかのみです。 （既知のプレフィックスは96ビット長であり、テーブルの最後の形式でのみ使用できます。）
Various deployments justify different prefix lengths with Network- Specific Prefixes. The trade-off between different prefix lengths are discussed in Sections 3.3 and 3.4.
さまざまな展開では、ネットワーク固有のプレフィックスで異なるプレフィックス長が正当化されます。 異なるプレフィックス長の間のトレードオフについては、セクション3.3および3.4で説明します。
Bao, et al. Standards Track [Page 5] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 Bits 64 to 71 of the address are reserved for compatibility with the host identifier format defined in the IPv6 addressing architecture [RFC4291]. These bits MUST be set to zero. When using a /96 Network-Specific Prefix, the administrators MUST ensure that the bits 64 to 71 are set to zero. A simple way to achieve that is to construct the /96 Network-Specific Prefix by picking a /64 prefix, and then adding 4 octets set to zero.
アドレスのビット64〜71は、IPv6アドレッシングアーキテクチャ[RFC4291]で定義されているホスト識別子形式との互換性のために予約されています。 これらのビットはゼロに設定する必要があります。 / 96ネットワーク固有の接頭辞を使用する場合、管理者はビット64〜71がゼロに設定されていることを確認する必要があります。 これを実現する簡単な方法は、/ 64プレフィックスを選択して/ 96ネットワーク固有のプレフィックスを作成し、ゼロに設定された4オクテットを追加することです。
The IPv4 address is encoded following the prefix, most significant bits first. Depending of the prefix length, the 4 octets of the address may be separated by the reserved octet "u", whose 8 bits MUST be set to zero. In particular:
IPv4アドレスは、最上位ビットが最初に、プレフィックスに従ってエンコードされます。 プレフィックス長に応じて、アドレスの4オクテットは予約オクテット "u"で区切ることができます。その8ビットはゼロに設定する必要があります。 特に：
o When the prefix is 32 bits long, the IPv4 address is encoded in
positions 32 to 63.
プレフィックスが32ビット長の場合、IPv4アドレスは32〜63桁目にエンコードされます。
o When the prefix is 40 bits long, 24 bits of the IPv4 address are
encoded in positions 40 to 63, with the remaining 8 bits in
position 72 to 79.
プレフィックスが40ビット長の場合、IPv4アドレスの24ビットは40〜63の位置にエンコードされ、残りの8ビットは72〜79の位置にエンコードされます。
o When the prefix is 48 bits long, 16 bits of the IPv4 address are
encoded in positions 48 to 63, with the remaining 16 bits in
position 72 to 87.
プレフィックスが48ビット長の場合、IPv4アドレスの16ビットは48〜63の位置にエンコードされ、残りの16ビットは72〜87の位置にエンコードされます。
o When the prefix is 56 bits long, 8 bits of the IPv4 address are
encoded in positions 56 to 63, with the remaining 24 bits in
position 72 to 95.
プレフィックスが56ビット長の場合、IPv4アドレスの8ビットは56から63の位置にエンコードされ、残りの24ビットは72から95の位置にエンコードされます。
o When the prefix is 64 bits long, the IPv4 address is encoded in
positions 72 to 103.
プレフィックスが64ビット長の場合、IPv4アドレスは72〜103桁目にエンコードされます。
o When the prefix is 96 bits long, the IPv4 address is encoded in
positions 96 to 127.
プレフィックスが96ビット長の場合、IPv4アドレスは96〜127の位置にエンコードされます。
There are no remaining bits, and thus no suffix, if the prefix is 96 bits long. In the other cases, the remaining bits of the address constitute the suffix. These bits are reserved for future extensions and SHOULD be set to zero. Address translators who receive IPv4- embedded IPv6 addresses where these bits are not zero SHOULD ignore the bits' value and proceed as if the bits' value were zero. (Future extensions may specify a different behavior.)
プレフィックスが96ビット長の場合、残りのビットはなく、したがってサフィックスはありません。 その他の場合、アドレスの残りのビットがサフィックスを構成します。 これらのビットは将来の拡張のために予約されており、ゼロに設定する必要があります。 これらのビットがゼロでないIPv4組み込みIPv6アドレスを受信するアドレス変換プログラムは、ビットの値を無視し、ビットの値がゼロであるかのように処理を行う必要があります。 （将来の拡張機能は別の動作を指定する可能性があります。）
Bao, et al. Standards Track [Page 6] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 2.3. Address Translation Algorithms
2.3。 アドレス変換アルゴリズム
IPv4-embedded IPv6 addresses are composed according to the following algorithm:
IPv4埋め込みIPv6アドレスは、次のアルゴリズムに従って構成されます。
o Concatenate the prefix, the 32 bits of the IPv4 address, and the
suffix (if needed) to obtain a 128-bit address.
プレフィックス、IPv4アドレスの32ビット、およびサフィックス（必要な場合）を連結して、128ビットアドレスを取得します。
o If the prefix length is less than 96 bits, insert the null octet
"u" at the appropriate position (bits 64 to 71), thus causing the
least significant octet to be excluded, as documented in Figure 1.
プレフィックス長が96ビット未満の場合は、ヌルオクテット "u"を適切な位置（ビット64〜71）に挿入します。これにより、図1に示すように、最下位オクテットが除外されます。
The IPv4 addresses are extracted from the IPv4-embedded IPv6 addresses according to the following algorithm:
IPv4アドレスは、次のアルゴリズムに従ってIPv4埋め込みIPv6アドレスから抽出されます。
o If the prefix is 96 bits long, extract the last 32 bits of the
IPv6 address;
プレフィックスが96ビット長の場合は、IPv6アドレスの最後の32ビットを抽出します。
o For the other prefix lengths, remove the "u" octet to obtain a
120-bit sequence (effectively shifting bits 72-127 to positions
64-119), then extract the 32 bits following the prefix.
他の接頭辞の長さについては、「u」オクテットを削除して120ビットシーケンスを取得し（ビット72〜127を64〜119の位置に効果的にシフト）、接頭辞に続く32ビットを抽出します。
2.4. Text Representation
2.4。 テキスト表現
IPv4-embedded IPv6 addresses will be represented in text in conformity with Section 2.2 of [RFC4291]. IPv4-embedded IPv6 addresses constructed using the Well-Known Prefix or a /96 Network- Specific Prefix may be represented using the alternative form presented in Section 2.2 of [RFC4291], with the embedded IPv4 address represented in dotted decimal notation. Examples of such representations are presented in Tables 1 and 2.
IPv4埋め込みIPv6アドレスは、[RFC4291]のセクション2.2に準拠してテキストで表されます。 Well-Known Prefixまたは/ 96 Network-Specific Prefixを使用して構築されたIPv4埋め込みIPv6アドレスは、[RFC4291]のセクション2.2に示されている代替形式を使用して表すことができ、埋め込みIPv4アドレスはドット付き10進表記で表されます。 そのような表現の例を表1および2に示します。
+-----------------------+------------+------------------------------+
| Network-Specific | IPv4 | IPv4-embedded IPv6 address |
| Prefix | address | |
+-----------------------+------------+------------------------------+
| 2001:db8::/32 | 192.0.2.33 | 2001:db8:c000:221:: |
| 2001:db8:100::/40 | 192.0.2.33 | 2001:db8:1c0:2:21:: |
| 2001:db8:122::/48 | 192.0.2.33 | 2001:db8:122:c000:2:2100:: |
| 2001:db8:122:300::/56 | 192.0.2.33 | 2001:db8:122:3c0:0:221:: |
| 2001:db8:122:344::/64 | 192.0.2.33 | 2001:db8:122:344:c0:2:2100:: |
| 2001:db8:122:344::/96 | 192.0.2.33 | 2001:db8:122:344::192.0.2.33 |
+-----------------------+------------+------------------------------+
Table 1: Text Representation of IPv4-Embedded IPv6 Addresses Using
Network-Specific Prefixes
表1：ネットワーク固有のプレフィックスを使用したIPv4埋め込みIPv6アドレスのテキスト表現
Bao, et al. Standards Track [Page 7]
RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
+-------------------+--------------+----------------------------+
| Well-Known Prefix | IPv4 address | IPv4-Embedded IPv6 address |
+-------------------+--------------+----------------------------+
| 64:ff9b::/96 | 192.0.2.33 | 64:ff9b::192.0.2.33 |
+-------------------+--------------+----------------------------+
Table 2: Text Representation of IPv4-Embedded IPv6 Addresses Using
the Well-Known Prefix
表2：既知のプレフィックスを使用したIPv4埋め込みIPv6アドレスのテキスト表現
The Network-Specific Prefix examples in Table 1 are derived from the IPv6 prefix reserved for documentation in [RFC3849]. The IPv4 address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for documentation in [RFC5735]. The representation of IPv6 addresses is compatible with [RFC5952].
表1のネットワーク固有のプレフィックスの例は、[RFC3849]のドキュメント用に予約されているIPv6プレフィックスから派生しています。 IPv4アドレス192.0.2.33は、[RFC5735]のドキュメント用に予約されているサブネット192.0.2.0/24の一部です。 IPv6アドレスの表現は[RFC5952]と互換性があります。
3. Deployment Guidelines
3.導入ガイドライン
3.1. Restrictions on the Use of the Well-Known Prefix
3.1。 既知のプレフィックスの使用に関する制限
The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, such as those defined in [RFC1918] or listed in Section 3 of [RFC5735]. Address translators MUST NOT translate packets in which an address is composed of the Well-Known Prefix and a non- global IPv4 address; they MUST drop these packets.
[RFC1918]で定義されている、または[RFC5735]のセクション3にリストされているような非グローバルIPv4アドレスを表すために、既知のプレフィックスを使用してはなりません（MUST NOT）。 アドレス変換プログラムは、アドレスが既知のプレフィックスと非グローバルIPv4アドレスで構成されるパケットを変換してはなりません（MUST NOT）。 これらのパケットをドロップする必要があります。
The Well-Known Prefix SHOULD NOT be used to construct IPv4- translatable IPv6 addresses. The nodes served by IPv4-translatable IPv6 addresses should be able to receive global IPv6 traffic bound to their IPv4-translatable IPv6 address without incurring intermediate protocol translation. This is only possible if the specific prefix used to build the IPv4-translatable IPv6 addresses is advertised in inter-domain routing, but the advertisement of more specific prefixes derived from the Well-Known Prefix is not supported, as explained in Section 3.2. Network-Specific Prefixes SHOULD be used in these scenarios, as explained in Section 3.3.
既知のプレフィックスは、IPv4で変換可能なIPv6アドレスの構築には使用しないでください。 IPv4変換可能なIPv6アドレスによって処理されるノードは、中間プロトコル変換を発生させることなく、IPv4変換可能なIPv6アドレスにバインドされたグローバルIPv6トラフィックを受信できる必要があります。 これは、IPv4変換可能なIPv6アドレスの構築に使用される特定のプレフィックスがドメイン間ルーティングでアドバタイズされる場合にのみ可能ですが、セクション3.2で説明されているように、既知のプレフィックスから派生したより具体的なプレフィックスのアドバタイズはサポートされません。 セクション3.3で説明するように、これらのシナリオではネットワーク固有のプレフィックスを使用する必要があります（SHOULD）。
The Well-Known Prefix MAY be used by organizations deploying translation services, as explained in Section 3.4.
既知のプレフィックスは、セクション3.4で説明されているように、翻訳サービスを展開している組織によって使用される場合があります。
3.2. Impact on Inter-Domain Routing
3.2。 ドメイン間ルーティングへの影響
The Well-Known Prefix MAY appear in inter-domain routing tables, if service providers decide to provide IPv6-IPv4 interconnection services to peers. Advertisement of the Well-Known Prefix SHOULD be controlled either by upstream and/or downstream service providers according to inter-domain routing policies, e.g., through
サービスプロバイダーがIPv6-IPv4相互接続サービスをピアに提供することを決定した場合、既知のプレフィックスがドメイン間ルーティングテーブルに表示される場合があります。 Well-Known Prefixのアドバタイズは、ドメイン間ルーティングポリシーに従って、アップストリームおよび/またはダウンストリームサービスプロバイダーによって、たとえば
Bao, et al. Standards Track [Page 8] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 configuration of BGP [RFC4271]. Organizations that advertise the Well-Known Prefix in inter-domain routing MUST be able to provide IPv4/IPv6 translation service.
BGP [RFC4271]の設定。 ドメイン間ルーティングで既知のプレフィックスをアドバタイズする組織は、IPv4 / IPv6変換サービスを提供できる必要があります。
When the IPv4/IPv6 translation relies on the Well-Known Prefix, IPv4- embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be advertised in BGP (especially External BGP) [RFC4271] because this leads to importing the IPv4 routing table into the IPv6 one and therefore introduces scalability issues to the global IPv6 routing table. Administrators of BGP nodes SHOULD configure filters that discard advertisements of embedded IPv6 prefixes longer than the Well-Known Prefix.
IPv4 / IPv6変換が既知のプレフィックスに依存している場合、既知のプレフィックスよりも長いIPv4埋め込みIPv6プレフィックスは、BGP（特に外部BGP）[RFC4271]でアドバタイズしてはなりません。これにより、IPv4ルーティングテーブルが IPv6の1つなので、グローバルIPv6ルーティングテーブルにスケーラビリティの問題が発生します。 BGPノードの管理者は、既知のプレフィックスよりも長い埋め込みIPv6プレフィックスのアドバタイズを破棄するフィルターを設定する必要があります（SHOULD）。
When the IPv4/IPv6 translation service relies on Network-Specific Prefixes, the IPv4-translatable IPv6 prefixes used in stateless translation MUST be advertised with proper aggregation to the IPv6 Internet. Similarly, if translators are configured with multiple Network-Specific Prefixes, these prefixes MUST be advertised to the IPv6 Internet with proper aggregation.
IPv4 / IPv6変換サービスがネットワーク固有のプレフィックスに依存している場合、ステートレス変換で使用されるIPv4変換可能なIPv6プレフィックスは、IPv6インターネットへの適切な集約でアドバタイズされる必要があります。 同様に、トランスレータが複数のネットワーク固有のプレフィックスで構成されている場合、これらのプレフィックスは適切な集約でIPv6インターネットにアドバタイズされる必要があります。
3.3. Choice of Prefix for Stateless Translation Deployments
3.3。 ステートレス翻訳展開のプレフィックスの選択
Organizations may deploy translation services using stateless translation. In these deployments, internal IPv6 nodes are addressed using IPv4-translatable IPv6 addresses, which enable them to be accessed by IPv4 nodes. The addresses of these external IPv4 nodes are then represented in IPv4-converted IPv6 addresses.
組織は、ステートレス翻訳を使用して翻訳サービスを展開できます。 これらの展開では、内部IPv6ノードはIPv4変換可能なIPv6アドレスを使用してアドレス指定され、IPv4ノードからアクセスできるようになります。 これらの外部IPv4ノードのアドレスは、IPv4変換されたIPv6アドレスで表されます。
Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a Network-Specific Prefix to their IPv4/IPv6 translation service. IPv4-translatable and IPv4-converted IPv6 addresses MUST be constructed as specified in Section 2.2. IPv4-translatable IPv6 addresses MUST use the selected Network-Specific Prefix. Both IPv4- translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD use the same prefix.
ステートレスIPv4 / IPv6変換を展開している組織は、ネットワーク固有のプレフィックスをIPv4 / IPv6変換サービスに割り当てる必要があります（SHOULD）。 IPv4-translatableおよびIPv4-converted IPv6アドレスは、セクション2.2で指定されているように構築する必要があります。 IPv4で変換可能なIPv6アドレスは、選択したネットワーク固有のプレフィックスを使用する必要があります。 IPv4で変換可能なIPv6アドレスとIPv4で変換されたIPv6アドレスの両方が同じプレフィックスを使用する必要があります（SHOULD）。
Using the same prefix ensures that IPv6 nodes internal to the organization will use the most efficient paths to reach the nodes served by IPv4-translatable IPv6 addresses. Specifically, if a node learns the IPv4 address of a target internal node without knowing that this target is in fact located behind the same translator that the node also uses, translation rules will ensure that the IPv6 address constructed with the Network-Specific Prefix is the same as the IPv4-translatable IPv6 address assigned to the target. Standard routing preference (i.e., "most specific match wins") will then ensure that the IPv6 packets are delivered directly, without requiring that translators receive the packets and then return them in the direction from which they came.
同じプレフィックスを使用することで、組織内部のIPv6ノードが最も効率的なパスを使用して、IPv4変換可能なIPv6アドレスによって処理されるノードに到達することが保証されます。 具体的には、ノードがターゲット内部ノードのIPv4アドレスを学習するときに、このターゲットが実際にノードも使用する同じトランスレーターの背後にあることを認識していない場合、変換ルールにより、ネットワーク固有のプレフィックスで構築されたIPv6アドレスが ターゲットに割り当てられたIPv4変換可能なIPv6アドレスと同じです。 標準のルーティング設定（つまり、「最も具体的な一致」）により、IPv6パケットが直接配信され、トランスレータがパケットを受信してから、それらを元の方向に返す必要がなくなります。
Bao, et al. Standards Track [Page 9] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 The intra-domain routing protocol must be able to deliver packets to the nodes served by IPv4-translatable IPv6 addresses. This may require routing on some or all of the embedded IPv4 address bits. Security considerations detailed in Section 5 require that routers check the validity of the IPv4-translatable IPv6 source addresses, using some form of reverse path check.
ドメイン内ルーティングプロトコルは、IPv4変換可能なIPv6アドレスによって処理されるノードにパケットを配信できる必要があります。 これには、埋め込みIPv4アドレスビットの一部またはすべてでのルーティングが必要な場合があります。 セクション5で詳述されているセキュリティの考慮事項では、ルーターが何らかの形式のリバースパスチェックを使用して、IPv4変換可能なIPv6送信元アドレスの有効性をチェックする必要があります。
The management of stateless address translation can be illustrated with a small example:
ステートレスアドレス変換の管理は、小さな例で説明できます。
We will consider an IPv6 network with the prefix 2001:db8:
122::/48. The network administrator has selected the Network-
Specific Prefix 2001:db8:122:344::/64 for managing stateless IPv4/
IPv6 translation. The IPv4-translatable address block for IPv4
subnet 192.0.2.0/24 is 2001:db8:122:344:c0:2::/96. In this
network, the host A is assigned the IPv4-translatable IPv6 address
2001:db8:122:344:c0:2:2100::, which corresponds to the IPv4
address 192.0.2.33. Host A's address is configured either
manually or through DHCPv6.
プレフィックス2001：db8：122 :: / 48のIPv6ネットワークを検討します。 ネットワーク管理者は、ステートレスIPv4 / IPv6変換を管理するために、ネットワーク固有のプレフィックス2001：db8：122：344 :: / 64を選択しました。 IPv4サブネット192.0.2.0/24のIPv4-translatableアドレスブロックは2001：db8：122：344：c0：2 :: / 96です。 このネットワークでは、ホストAにIPv4変換可能なIPv6アドレス2001：db8：122：344：c0：2：2100 ::が割り当てられています。これはIPv4アドレス192.0.2.33に対応しています。 ホストAのアドレスは、手動またはDHCPv6を介して構成されます。
In this example, host A is not directly connected to the
translator, but instead to a link managed by a router R. The
router R is configured to forward to A the packets bound to 2001:
db8:122:344:c0:2:2100::. To receive these packets, R will
advertise reachability of the prefix 2001:db8:122:344:c0:2:2100::/
104 in the intra-domain routing protocol -- or perhaps a shorter
prefix if many hosts on link have IPv4-translatable IPv6 addresses
derived from the same IPv4 subnet. If a packet bound to
192.0.2.33 reaches the translator, the destination address will be
translated to 2001:db8:122:344:c0:2:2100::, and the packet will be
routed towards R and then to A.
この例では、ホストAはトランスレータに直接接続されていませんが、代わりにルータRによって管理されているリンクに接続されています。 ルータRは、2001にバインドされたパケットをAに転送するように構成されています：db8：122：344：c0：2：2100 ::。 これらのパケットを受信するために、Rはドメイン内ルーティングプロトコルのプレフィックス2001：db8：122：344：c0：2：2100 :: / 104の到達可能性をアドバタイズします。リンク上の多くのホストがIPv4を持っている場合は、おそらくより短いプレフィックスです。 -同じIPv4サブネットから派生した翻訳可能なIPv6アドレス。 192.0.2.33にバインドされたパケットがトランスレータに到達すると、宛先アドレスは2001：db8：122：344：c0：2：2100 ::に変換され、パケットはRにルーティングされてからAにルーティングされます。
Let's suppose now that a host B of the same domain learns the IPv4
address of A, maybe through an application-specific referral. If
B has translation-aware software, B can compose a destination
address by combining the Network-Specific Prefix 2001:db8:122:
344::/64 and the IPv4 address 192.0.2.33, resulting in the address
2001:db8:122:344:c0:2:2100::. The packet sent by B will be
forwarded towards R, and then to A, avoiding protocol translation.
同じドメインのホストBがAのIPv4アドレスを、アプリケーション固有の紹介を介して学習するとします。 Bが変換対応ソフトウェアを持っている場合、Bはネットワーク固有のプレフィックス2001：db8：122：344 :: / 64とIPv4アドレス192.0.2.33を組み合わせて宛先アドレスを作成でき、その結果、アドレス2001：db8：122：になります。 344：c0：2：2100 ::。 Bから送信されたパケットはRに転送され、次にAに転送されるため、プロトコル変換は行われません。
Forwarding, and reverse path checks, are more efficient when performed on the combination of the prefix and the IPv4 address. In theory, routers are able to route on prefixes of any length, but in practice there may be routers for which routing on prefixes larger than 64 bits is slower. However, routing efficiency is not the only consideration in the choice of a prefix length. Organizations also need to consider the availability of prefixes, and the potential impact of all-zero identifiers.
転送とリバースパスチェックは、プレフィックスとIPv4アドレスの組み合わせで実行するとより効率的です。 理論上、ルーターは任意の長さのプレフィックスでルーティングできますが、実際には、64ビットを超えるプレフィックスでのルーティングが遅いルーターが存在する場合があります。 ただし、ルーティング効率は、プレフィックス長の選択における唯一の考慮事項ではありません。 組織はまた、プレフィックスの可用性、およびすべてゼロの識別子の潜在的な影響を考慮する必要があります。
Bao, et al. Standards Track [Page 10] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 If a /32 prefix is used, all the routing bits are contained in the top 64 bits of the IPv6 address, leading to excellent routing properties. These prefixes may however be hard to obtain, and allocation of a /32 to a small set of IPv4-translatable IPv6 addresses may be seen as wasteful. In addition, the /32 prefix and a zero suffix lead to an all-zero interface identifier, which is an issue that we discuss in Section 4.1.
/ 32プレフィックスを使用すると、すべてのルーティングビットがIPv6アドレスの上位64ビットに含まれるため、優れたルーティングプロパティが得られます。 ただし、これらのプレフィックスを取得するのは困難な場合があり、IPv4で変換可能なIPv6アドレスの小さなセットに/ 32を割り当てることは無駄に見えるかもしれません。 さらに、/ 32接頭辞とゼロの接尾辞は、すべてゼロのインターフェース識別子につながります。これは、セクション4.1で説明する問題です。
Intermediate prefix lengths such as /40, /48, or /56 appear as compromises. Only some of the IPv4 bits are part of the /64 prefixes. Reverse path checks, in particular, may have a limited efficiency. Reverse path checks limited to the most significant bits of the IPv4 address will reduce the possibility of spoofing external IPv4 addresses, but would allow IPv6 nodes to spoof internal IPv4- translatable IPv6 addresses.
/ 40、/ 48、/ 56などの中間のプレフィックス長は、妥協点として表示されます。 IPv4ビットの一部のみが/ 64プレフィックスの一部です。 特に、リバースパスチェックは効率が制限される場合があります。 IPv4アドレスの最上位ビットに制限されたリバースパスチェックは、外部IPv4アドレスのなりすましの可能性を減らしますが、IPv6ノードが内部IPv4変換可能なIPv6アドレスを偽装することを可能にします。
We propose a compromise, based on using no more than 1/256th of an organization's allocation of IPv6 addresses for the IPv4/IPv6 translation service. For example, if the organization is an Internet Service Provider with an allocated IPv6 prefix /32 or shorter, the ISP could dedicate a /40 prefix to the translation service. An end site with a /48 allocation could dedicate a /56 prefix to the translation service, or possibly a /96 prefix if all IPv4- translatable IPv6 addresses are located on the same link.
IPv4 / IPv6変換サービスに組織のIPv6アドレス割り当ての1/256以下を使用することに基づいて、妥協案を提案します。 たとえば、組織がIPv6プレフィックス/ 32以下が割り当てられたインターネットサービスプロバイダーである場合、ISPは/ 40プレフィックスを変換サービス専用にすることができます。 / 48割り当てのあるエンドサイトは、/ 56プレフィックスを変換サービス専用にするか、すべてのIPv4変換可能IPv6アドレスが同じリンク上にある場合は/ 96プレフィックスを専用にすることができます。
The recommended prefix length is also a function of the deployment scenario. The stateless translation can be used for Scenario 1, Scenario 2, Scenario 5, and Scenario 6 defined in [v4v6-FRAMEWORK]. For different scenarios, the prefix length recommendations are:
推奨されるプレフィックス長も、展開シナリオの関数です。 ステートレス変換は、[v4v6-FRAMEWORK]で定義されているシナリオ1、シナリオ2、シナリオ5、およびシナリオ6に使用できます。 さまざまなシナリオで、推奨されるプレフィックス長は次のとおりです。
o For Scenario 1 (an IPv6 network to the IPv4 Internet) and Scenario
2 (the IPv4 Internet to an IPv6 network), an ISP holding a /32
allocation SHOULD use a /40 prefix, and a site holding a /48
allocation SHOULD use a /56 prefix.
シナリオ1（IPv4インターネットへのIPv6ネットワーク）およびシナリオ2（IPv4インターネットへのIPv4インターネット）の場合、/ 32割り当てを保持するISPは/ 40プレフィックスを使用し、/ 48割り当てを保持するサイトは、 / 56プレフィックス。
o For Scenario 5 (an IPv6 network to an IPv4 network) and Scenario 6
(an IPv4 network to an IPv6 network), the deployment SHOULD use a
/64 or a /96 prefix.
シナリオ5（IPv6ネットワークからIPv4ネットワーク）およびシナリオ6（IPv4ネットワークからIPv6ネットワーク）の場合、展開では/ 64または/ 96プレフィックスを使用する必要があります（SHOULD）。
3.4. Choice of Prefix for Stateful Translation Deployments
3.4。 ステートフルな翻訳の展開のためのプレフィックスの選択
Organizations may deploy translation services based on stateful translation technology. An organization may decide to use either a Network-Specific Prefix or the Well-Known Prefix for its stateful IPv4/IPv6 translation service.
組織は、ステートフルな翻訳テクノロジーに基づいて翻訳サービスを展開できます。 組織は、そのステートフルIPv4 / IPv6変換サービスにネットワーク固有のプレフィックスまたは既知のプレフィックスを使用することを決定できます。
Bao, et al. Standards Track [Page 11] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 When these services are used, IPv6 nodes are addressed through standard IPv6 addresses, while IPv4 nodes are represented by IPv4- converted IPv6 addresses, as specified in Section 2.2.
これらのサービスを使用する場合、IPv6ノードは標準のIPv6アドレスでアドレス指定されますが、IPv4ノードは、セクション2.2で指定されているように、IPv4変換されたIPv6アドレスで表されます。
The stateful nature of the translation creates a potential stability issue when the organization deploys multiple translators. If several translators use the same prefix, there is a risk that packets belonging to the same connection may be routed to different translators as the internal routing state changes. This issue can be avoided either by assigning different prefixes to different translators or by ensuring that all translators using the same prefix coordinate their state.
翻訳のステートフルな性質により、組織が複数の翻訳者を配置するときに、安定性の問題が発生する可能性があります。 複数のトランスレータが同じプレフィックスを使用する場合、内部ルーティング状態が変化すると、同じ接続に属するパケットが異なるトランスレータにルーティングされるリスクがあります。 この問題は、異なるトランスレータに異なるプレフィックスを割り当てるか、同じプレフィックスを使用するすべてのトランスレータが状態を調整するようにすることで回避できます。
Stateful translation can be used in scenarios defined in [v4v6-FRAMEWORK]. The Well-Known Prefix SHOULD be used in these scenarios, with two exceptions:
ステートフル変換は、[v4v6-FRAMEWORK]で定義されたシナリオで使用できます。 よく知られているプレフィックスは、次の2つの例外を除いて、これらのシナリオで使用する必要があります（SHOULD）。
o In all scenarios, the translation MAY use a Network-Specific
Prefix, if deemed appropriate for management reasons.
すべてのシナリオで、管理上の理由から適切であると見なされる場合、変換はネットワーク固有のプレフィックスを使用する場合があります。
o The Well-Known Prefix MUST NOT be used for Scenario 3 (the IPv6
Internet to an IPv4 network), as this would lead to using the
Well-Known Prefix with non-global IPv4 addresses. That means a
Network-Specific Prefix (for example, a /96 prefix) MUST be used
in that scenario.
Well-Knownプレフィックスはシナリオ3（IPv6インターネットからIPv4ネットワークへ）では使用しないでください。これは、非グローバルIPv4アドレスでWell-Knownプレフィックスを使用することになるためです。 つまり、そのシナリオでは、ネットワーク固有のプレフィックス（たとえば、/ 96プレフィックス）を使用する必要があります。
4. Design Choices
4.デザインの選択
The prefix that we have chosen reflects two design choices, the null suffix and the specific value of the Well-Known Prefix. We provide here a summary of the discussions leading to those two choices.
私たちが選択した接頭辞は、2つの設計の選択肢、ヌル接尾辞と既知の接頭辞の特定の値を反映しています。 ここでは、これら2つの選択につながる議論の要約を提供します。
4.1. Choice of Suffix
4.1。 サフィックスの選択
The address format described in Section 2.2 recommends a zero suffix. Before making this recommendation, we considered different options: checksum neutrality, the encoding of a port range, and a value different than 0.
セクション2.2で説明するアドレス形式では、ゼロのサフィックスを推奨しています。 この推奨を行う前に、チェックサムの中立性、ポート範囲のエンコード、0以外の値など、さまざまなオプションを検討しました。
In the case of stateless translation, there would be no need for the translator to recompute a one's complement checksum if both the IPv4- translatable and the IPv4-converted IPv6 addresses were constructed in a "checksum-neutral" manner, that is, if the IPv6 addresses would have the same one's complement checksum as the embedded IPv4 address. In the case of stateful translation, checksum neutrality does not eliminate checksum computation during translation, as only one of the two addresses would be checksum neutral. We considered reserving 16 bits in the suffix to guarantee checksum neutrality, but declined Bao, et al. Standards Track [Page 12] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 because it would not help with stateful translation and because checksum neutrality can also be achieved by an appropriate choice of the Network-Specific Prefix, i.e., selecting a prefix whose one's complement checksum equals either 0 or 0xffff.
ステートレス変換の場合、IPv4変換可能なIPv6アドレスとIPv4変換されたIPv6アドレスの両方が「チェックサムニュートラル」な方法で構築されている場合、つまり、トランスレータが1の補数チェックサムを再計算する必要はありません。 IPv6アドレスは、埋め込まれたIPv4アドレスと同じ補数チェックサムを持ちます。 ステートフル変換の場合、2つのアドレスのうち1つだけがチェックサムニュートラルになるため、チェックサムニュートラルは変換中にチェックサム計算を排除しません。 チェックサムの中立性を保証するためにサフィックスで16ビットを予約することを検討しましたが、ステートフル変換に役立たないため、またチェックサムの中立性はネットワーク固有のプレフィックスの適切な選択（つまり、1を補うプレフィックスの選択）によっても達成できるため、拒否されました チェックサムは0または0xffffです。
There have been proposals to complement stateless translation with a port-range feature. Instead of mapping an IPv4 address to exactly one IPv6 prefix, the options would allow several IPv6 nodes to share an IPv4 address, with each node managing a different range of ports. If a port range extension is needed, it could be defined later, using bits currently reserved as null in the suffix.
ステートレス変換をポート範囲機能で補完する提案がありました。 IPv4アドレスを正確に1つのIPv6プレフィックスにマッピングする代わりに、オプションは複数のIPv6ノードがIPv4アドレスを共有できるようにし、各ノードは異なる範囲のポートを管理します。 ポート範囲の拡張が必要な場合は、サフィックスで現在nullとして予約されているビットを使用して、後で定義できます。
When a /32 prefix is used, an all-zero suffix results in an all-zero interface identifier. We understand the conflict with Section 2.6.1 of RFC4291, which specifies that all zeroes are used for the subnet- router anycast address. However, in our specification, there is only one node with an IPv4-translatable IPv6 address in the /64 subnet, so the anycast semantic does not create confusion. We thus decided to keep the null suffix for now. This issue does not exist for prefixes larger than 32 bits, such as the /40, /56, /64, and /96 prefixes that we recommend in Section 3.3.
/ 32プレフィックスが使用されている場合、すべてゼロのサフィックスはすべてゼロのインターフェース識別子になります。 RFC4291のセクション2.6.1（サブネットルーターのエニーキャストアドレスにはすべて0が使用される）との矛盾を理解しています。 ただし、私たちの仕様では、/ 64サブネットにIPv4で変換可能なIPv6アドレスを持つノードが1つしかないため、エニーキャストセマンティクスによって混乱が生じることはありません。 そのため、当面はnullサフィックスを保持することにしました。 この問題は、セクション3.3で推奨する/ 40、/ 56、/ 64、および/ 96プレフィックスなど、32ビットを超えるプレフィックスでは発生しません。
4.2. Choice of the Well-Known Prefix
4.2。 既知のプレフィックスの選択
Before making our recommendation of the Well-Known Prefix, we were faced with three choices:
既知のプレフィックスを推奨する前に、3つの選択肢に直面しました。
o reuse the IPv4-mapped prefix, ::ffff:0:0/96, as specified in RFC
2765, Section 2.1;
RFC 2765、セクション2.1で指定されているように、IPv4でマップされたプレフィックス:: ffff：0：0/96を再利用します。
o request IANA to allocate a /32 prefix, or
/ 32プレフィックスの割り当てをIANAに要求する、または
o request allocation of a new /96 prefix.
新しい/ 96プレフィックスの割り当てを要求します。
We weighted the pros and cons of these choices before settling on the recommended /96 Well-Known Prefix.
推奨される/ 96 Well-Knownプレフィックスを決定する前に、これらの選択肢の長所と短所を重み付けしました。
The main advantage of the existing IPv4-mapped prefix is that it is already defined. Reusing that prefix would require minimal standardization efforts. However, being already defined is not just an advantage, as there may be side effects of current implementations. When presented with the IPv4-mapped prefix, current versions of Windows and Mac OS generate IPv4 packets, but will not send IPv6 packets. If we used the IPv4-mapped prefix, these nodes would not be able to support translation without modification. This will defeat the main purpose of the translation techniques. We thus eliminated the first choice, i.e., decided to not reuse the IPv4- mapped prefix, ::ffff:0:0/96.
既存のIPv4マッププレフィックスの主な利点は、すでに定義されていることです。 その接頭辞を再利用すると、最小限の標準化作業が必要になります。 ただし、現在の実装には副作用がある可能性があるため、すでに定義されていることは単なる利点ではありません。 IPv4にマップされたプレフィックスが提示されると、現在のバージョンのWindowsおよびMac OSはIPv4パケットを生成しますが、IPv6パケットを送信しません。 IPv4でマップされたプレフィックスを使用した場合、これらのノードは変更なしでは変換をサポートできません。 これは、翻訳技術の主な目的を無効にします。 したがって、最初の選択肢を排除しました。つまり、IPv4にマップされたプレフィックス:: ffff：0：0/96を再利用しないことにしました。
Bao, et al. Standards Track [Page 13] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 A /32 prefix would have allowed the embedded IPv4 address to fit within the top 64 bits of the IPv6 address. This would have facilitated routing and load balancing when an organization deploys several translators. However, such destination-address-based load balancing may not be desirable. It is not compatible with Session Traversal Utilities for NAT (STUN) [RFC5389] in the deployments involving multiple stateful translators, each one having a different pool of IPv4 addresses. STUN compatibility would only be achieved if the translators managed the same pool of IPv4 addresses and were able to coordinate their translation state, in which case there is no big advantage to using a /32 prefix rather than a /96 prefix.
/ 32プレフィックスは、埋め込まれたIPv4アドレスがIPv6アドレスの上位64ビット内に収まるようにします。 これにより、組織が複数のトランスレータを展開する際のルーティングとロードバランシングが容易になります。 ただし、このような宛先アドレスベースのロードバランシングは望ましくない場合があります。 NATのセッショントラバーサルユーティリティ（STUN）[RFC5389]とは互換性がありません。それぞれがIPv4アドレスの異なるプールを持つ複数のステートフルトランスレーターを含む展開では。 STUNの互換性は、トランスレーターが同じIPv4アドレスのプールを管理し、変換状態を調整できた場合にのみ達成されます。この場合、/ 96プレフィックスではなく/ 32プレフィックスを使用しても大きな利点はありません。
According to Section 2.2 of [RFC4291], in the legal textual representations of IPv6 addresses, dotted decimal can only appear at the end. The /96 prefix is compatible with that requirement. It enables the dotted decimal notation without requiring an update to [RFC4291]. This representation makes the address format easier to use and the log files easier to read.
[RFC4291]のセクション2.2によると、IPv6アドレスの正当なテキスト表現では、ドット付き10進数は最後にのみ表示できます。 / 96プレフィックスはその要件と互換性があります。 [RFC4291]の更新を必要とせずにドット付き10進表記を有効にします。 この表現により、アドレス形式が使いやすくなり、ログファイルが読みやすくなります。
The prefix that we recommend has the particularity of being "checksum neutral". The sum of the hexadecimal numbers "0064" and "ff9b" is "ffff", i.e., a value equal to zero in one's complement arithmetic. An IPv4-embedded IPv6 address constructed with this prefix will have the same one's complement checksum as the embedded IPv4 address.
私たちが推奨するプレフィックスは、「チェックサムニュートラル」であるという特殊性を持っています。 16進数の「0064」と「ff9b」の合計は「ffff」です。つまり、1の補数演算でゼロに等しい値です。 このプレフィックスで構築されたIPv4埋め込みIPv6アドレスは、埋め込みIPv4アドレスと同じ補数チェックサムを持ちます。
5. Security Considerations
5.セキュリティに関する考慮事項
5.1. Protection against Spoofing
5.1。 なりすましに対する保護
IPv4/IPv6 translators can be modeled as special routers, are subject to the same risks, and can implement the same mitigations. (The discussion of generic threats to routers and their mitigations is beyond the scope of this document.) There is, however, a particular risk that directly derives from the practice of embedding IPv4 addresses in IPv6: address spoofing.
IPv4 / IPv6トランスレータは、特別なルーターとしてモデル化でき、同じリスクにさらされ、同じ緩和策を実装できます。 （ルーターに対する一般的な脅威とその緩和策についての説明は、このドキュメントの範囲を超えています。）ただし、IPv6アドレスにIPv4アドレスを埋め込む方法から直接派生する特定のリスクがあります。アドレススプーフィングです。
An attacker could use an IPv4-embedded IPv6 address as the source address of malicious packets. After translation, the packets will appear as IPv4 packets from the specified source, and the attacker may be hard to track. If left without mitigation, the attack would allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses.
攻撃者は悪意のあるパケットの送信元アドレスとしてIPv4埋め込みIPv6アドレスを使用する可能性があります。 変換後、パケットは指定されたソースからのIPv4パケットとして表示され、攻撃者が追跡するのが困難になる可能性があります。 緩和策がなければ、攻撃により悪意のあるIPv6ノードが任意のIPv4アドレスを偽装する可能性があります。
The mitigation is to implement reverse path checks and to verify throughout the network that packets are coming from an authorized location.
緩和策は、リバースパスチェックを実装し、許可された場所からパケットが送信されていることをネットワーク全体で確認することです。
Bao, et al. Standards Track [Page 14] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 5.2. Secure Configuration
5.2。 安全な構成
The prefixes used for address translation are used by IPv6 nodes to send packets to IPv6/IPv4 translators. Attackers could attempt to fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong values for these parameters, resulting in network disruption, denial of service, and possible information disclosure. To mitigate such attacks, network administrators need to ensure that prefixes are configured in a secure way.
アドレス変換に使用されるプレフィックスは、IPv6ノードがパケットをIPv6 / IPv4トランスレータに送信するために使用されます。 攻撃者は、ノード、DNSゲートウェイ、およびIPv4 / IPv6トランスレータをだましてこれらのパラメータに誤った値を使用することを試みる可能性があり、その結果、ネットワークの中断、サービス拒否、および情報漏えいの可能性があります。 このような攻撃を緩和するには、ネットワーク管理者は、プレフィックスが安全な方法で構成されていることを確認する必要があります。
The mechanisms for achieving secure configuration of prefixes are beyond the scope of this document.
プレフィックスの安全な構成を実現するメカニズムは、このドキュメントの範囲外です。
5.3. Firewall Configuration
5.3。 ファイアウォール構成
Many firewalls and other security devices filter traffic based on IPv4 addresses. Attackers could attempt to fool these firewalls by sending IPv6 packets to or from IPv6 addresses that translate to the filtered IPv4 addresses. If the attack is successful, traffic that was previously blocked might be able to pass through the firewalls disguised as IPv6 packets. In all such scenarios, administrators should assure that packets that send to or from IPv4-embedded IPv6 addresses are subject to the same filtering as those directly sent to or from the embedded IPv4 addresses.
多くのファイアウォールやその他のセキュリティデバイスは、IPv4アドレスに基づいてトラフィックをフィルタリングします。 攻撃者は、フィルタリングされたIPv4アドレスに変換されるIPv6アドレスとの間でIPv6パケットを送信することにより、これらのファイアウォールをだまそうとする可能性があります。 攻撃が成功すると、以前にブロックされたトラフィックが、IPv6パケットに偽装されたファイアウォールを通過できる可能性があります。 このようなすべてのシナリオで、管理者は、IPv4埋め込みIPv6アドレスとの間で送受信されるパケットが、埋め込みIPv4アドレスと直接送受信されるパケットと同じフィルタリングの対象となることを確認する必要があります。
The mechanisms for configuring firewalls and security devices to achieve this filtering are beyond the scope of this document.
このフィルタリングを実現するためにファイアウォールとセキュリティデバイスを構成するメカニズムは、このドキュメントの範囲外です。
6. IANA Considerations
6. IANAに関する考慮事項
IANA has made the following changes in the "Internet Protocol Version 6 Address Space" registry located at http://www.iana.org.
IANAは、http：//www.iana.orgにある「インターネットプロトコルバージョン6アドレススペース」レジストリに次の変更を加えました。
OLD:
古い：
IPv6 Prefix Allocation Reference Note
----------- ---------------- ------------ ----------------
0000::/8 Reserved by IETF [RFC4291] [1][5]
NEW:
新しい：
IPv6 Prefix Allocation Reference Note
----------- ---------------- ------------ ----------------
0000::/8 Reserved by IETF [RFC4291] [1][5][6]
[6] The "Well-Known Prefix" 64:ff9b::/96 used in an algorithmic
mapping between IPv4 to IPv6 addresses is defined out of the
0000::/8 address block, per RFC 6052.
[6] IPv4からIPv6アドレスへのアルゴリズムマッピングで使用される「既知のプレフィックス」64：ff9b :: / 96は、RFC 6052に従って、0000 :: / 8アドレスブロックの外で定義されています。
Bao, et al. Standards Track [Page 15] RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010 7. Acknowledgements
7.謝辞
Many people in the BEHAVE WG have contributed to the discussion that led to this document, including Andrew Sullivan, Andrew Yourtchenko, Ari Keranen, Brian Carpenter, Charlie Kaufman, Dan Wing, Dave Thaler, David Harrington, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, Iljitsch van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, Remi Denis-Courmont, Remi Despres, and William Waites. Marcelo Bagnulo is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program. 8. Contributors
8.貢献者
The following individuals co-authored documents from which text has
been incorporated, and are listed in alphabetical order.
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Hiroshi Miyata
Yokogawa Electric Corporation
2-9-32 Nakacho
Musashino-shi, Tokyo 180-8750
JAPAN
EMail: h.miyata@jp.yokogawa.com
Bao, et al. Standards Track [Page 16]
RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
9. References
9.リファレンス
9.1. Normative References
9.1。 規範的な参考文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
9.2. Informative References
9.2。 参考情報
[DNS64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
"DNS64: DNS extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers", Work in Progress,
October 2010.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
BCP 153, RFC 5735, January 2010.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010.
[v4v6-FRAMEWORK]
Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", Work in Progress, August 2010.
Bao, et al. Standards Track [Page 17]
RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators October 2010
Authors' Addresses
Congxiao Bao
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing, 100084
China
Phone: +86 10-62785983
EMail: congxiao@cernet.edu.cn
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
U.S.A.
EMail: huitema@microsoft.com
Marcelo Bagnulo
UC3M
Av. Universidad 30
Leganes, Madrid 28911
Spain
Phone: +34-91-6249500
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/marcelo
Mohamed Boucadair
France Telecom
3, Av Francois Chateaux
Rennes 350000
France
EMail: mohamed.boucadair@orange-ftgroup.com
Xing Li
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing, 100084
China
Phone: +86 10-62785983
EMail: xing@cernet.edu.cn
Bao, et al. Standards Track [Page 18]