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
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.
この文書は、静的に構成された情報を使用して、アルゴリズムに対応するIPv4アドレスのIPv6アドレスの変換、およびその逆を論じています。適切な場合、組織は、ネットワーク固有の接頭辞を使用することを可能にしながら、これは、アルゴリズムの翻訳に使用するためのよく知られている接頭辞を定義しています。アルゴリズムの翻訳はのIPv4 / IPv6のシナリオで使用のIPv4 / IPv6のトランスレータ、ならびに（DNS用たとえば、）プロキシ及びゲートウェイの他のタイプに使用されます。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
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）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（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で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
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
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]、紹介、またはその他の理由により発生することができます。デュアルスタックホストに対してこれらのシナリオを最適化することは、今後の検討課題です。
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アドレスの彼らの特定の使用を文書化することを期待しています。
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]に記載されているように解釈されます。
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).
アドレス変換：IPv6アドレス、またはその逆からIPv4アドレスを導き出すために持っている任意のエンティティ。これは、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.
IPv6はIPv4アドレスは変換：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トランスレータ：IPv6パケットをIPv4パケットを変換エンティティ、およびその逆。それは何のフローごとの必要な状態、またはフローの最初のパケットを受信したとき、フローごとの状態が作成されたことを意味する「ステートフル」の翻訳は、存在しないことを意味し、「ステートレス」の翻訳を行うことができます。
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.
アルゴリズムのマッピングで使用するために、この文書で定義されたIPv6プレフィックス：プレフィックスよく知られています。
This document reserves a "Well-Known Prefix" for use in an algorithmic mapping. The value of this IPv6 prefix is:
この文書では、アルゴリズムのマッピング用の「既知のプレフィックスを」留保します。このIPv6プレフィックスの値は次のとおりです。
64:ff9b::/96
64：ff9b :: / 96
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アドレスのフォーマットとして、ここで説明します。 PLは、プレフィックス長を指定する以下の図に提示されたIPv4埋め込みIPv6アドレスは、可変長の接頭辞、埋め込まれたIPv4アドレス、および可変長サフィックスで構成されています。
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|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に記載されています。
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プレフィックスをピッキングし、その後ゼロに設定4つのオクテットを追加することにより、/ 96ネットワーク固有のプレフィックスを構築することです。
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つのオクテットは、その8ビットをゼロに設定しなければならない予約オクテット「U」によって分離することができます。特に：
o When the prefix is 32 bits long, the IPv4 address is encoded in positions 32 to 63.
プレフィックスは32ビット長である場合、O、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ビット長である場合、O、IPv4アドレスの24ビットは79に位置72で残りの8ビットと、40〜63の位置に符号化されます。
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ビット長である場合、O、IPv4アドレスの16ビットは87に位置72で、残りの16ビットで、48〜63の位置に符号化されます。
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ビット長である場合、O、IPv4アドレスの8ビットは95に位置72で、残りの24ビットで、56〜63の位置に符号化されます。
o When the prefix is 64 bits long, the IPv4 address is encoded in positions 72 to 103.
プレフィックスは64ビット長である場合、O、IPv4アドレスは72〜103の位置に符号化されます。
o When the prefix is 96 bits long, the IPv4 address is encoded in positions 96 to 127.
プレフィックスは96ビット長である場合、O、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アドレスをアドレス変換は、ビットの値をとビットかのように進んで無視値がゼロだったべきです。 （将来の拡張機能は、異なる動作を指定することもできます。）
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.
Oプレフィックス、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ビットである場合、O、図1に記載されているように、したがって、除外される最下位オクテットを引き起こし、適切な位置（ビット64〜71）に「U」をヌルオクテットを挿入します。
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ビット長である場合、O、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.
O他のプレフィックス長は、120ビットのシーケンスを得るために「U」オクテットを削除し、その後プレフィックス以下の32ビットを抽出し、（有効ビット位置64から119に72から127を移動させます）。
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に準拠したテキストで表されます。よく知られている接頭辞または/ 96ネットワーク固有のプレフィックスを使用して構築IPv4に埋め込まれたIPv6アドレスは、ドット十進表記で表される埋め込みIPv4アドレスを用いて、[RFC4291]のセクション2.2に提示別の形態を使用して表すことができます。そのような表現の例は、表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アドレスのテキスト表現
+-------------------+--------------+----------------------------+
| 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]と互換性があります。
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アドレスを表すために使用してはいけません。アドレス変換は、アドレスは、周知のプレフィックスと非グローバルIPv4アドレスで構成されているパケットを変換てはなりません。彼らはこれらのパケットをドロップしなければなりません。
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節で説明したようにネットワーク固有のプレフィックスは、これらのシナリオで使用されるべきです。
The Well-Known Prefix MAY be used by organizations deploying translation services, as explained in Section 3.4.
3.4節で説明したような公知のプレフィックスは、翻訳サービスを展開組織によって使用されるかもしれません。
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 configuration of BGP [RFC4271]. Organizations that advertise the Well-Known Prefix in inter-domain routing MUST be able to provide IPv4/IPv6 translation service.
サービスプロバイダーは、ピアへのIPv6-IPv4の相互接続サービスを提供することを決定した場合によく知られているプレフィックスは、ドメイン間ルーティングテーブルに表示されることがあります。よく知られているプレフィックスの広告は、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ルーティングテーブルをインポートするにつながるためのIPv4 / IPv6変換は、よく知られているプレフィックス、IPv4-よく知られているプレフィックスは、BGP（特に外部BGP）でアドバタイズしてはならないよりも長い埋め込まれたIPv6プレフィックス[RFC4271]に依存している場合にはしたがって、IPv6の1とは、グローバルIPv6ルーティングテーブルにスケーラビリティの問題を紹介します。 BGPノードの管理者は、よく知られているプレフィックスより長い埋め込まれたIPv6プレフィックスの広告を破棄するフィルタを設定する必要があります。
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インターネットに通知しなければなりません。
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ノードがアクセスすることを可能IPv4に翻訳可能なIPv6アドレスを用いてアドレス指定されます。これらの外部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変換サービスにネットワーク固有のプレフィックスを割り当てる必要があります。セクション2.2で指定されたIPv4-並進とIPv4変換IPv6アドレスを構成しなければなりません。 IPv4に翻訳可能なIPv6アドレスは、選択したネットワーク固有の接頭辞を使用しなければなりません。 IPv4-翻訳可能なIPv6アドレスとIPv4変換IPv6アドレスの両方が同じプレフィックスを使用すべきです。
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パケットを翻訳者がパケットを受信した後、彼らが来た方向にそれらを返すことを必要とせずに、直接配信されることを保証します。
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でIPv6ネットワークを検討します：DB8：122 :: / 48。ステートレスのIPv4 / IPv6変換を管理するための344 :: / 64：DB8：：122ネットワーク管理者は、ネットワーク固有のプレフィックス2001を選択しました。 DB8：122：344：C0：2 :: / 96 IPv4サブネット192.0.2.0/24のIPv4-並進アドレスブロック2001です。 DB8：122：344：C0：2：2100 ::、IPv4アドレス192.0.2.33に対応し、このネットワークでは、ホストAは、IPv4-並進IPv6アドレス2001が割り当てられます。 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に結合されたパケットを転送するように構成されている：DB8：122：344：C0：2： 2100 ::。リンク上の多くのホストがIPv4を持っている場合、または、おそらくより短いプレフィックス - ドメイン内ルーティングプロトコル2100 :: / 104：DB8：122：344：C0：2これらのパケットを受信するように、Rは、プレフィックス2001到達可能性をアドバタイズします同じIPv4サブネットに由来-translatable IPv6アドレス。 :: 2100、およびパケットがRに向けてルーティングされ、その後、Aになります：2：C0：344：DB8：：122 192.0.2.33にバインドされたパケットは、翻訳者に到達した場合は、宛先アドレスが2001に変換されます
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アドレスを学習していることになりましたとしましょう。 DB8：344 :: / 64とアドレス2001年に得られたIPv4アドレス192.0.2.33、：122 B翻訳認識ソフトウェアを有する場合、Bは、ネットワーク固有のプレフィックス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ビットが遅いよりも大きなプレフィクスにルーティングするためのルータが存在してもよいです。しかし、ルーティング効率はプレフィックス長の選択にのみ考慮事項ではありません。組織はまた、接頭辞の可用性、およびすべてゼロの識別子の潜在的な影響を考慮する必要があります。
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の割り当ててもよいです。我々は4.1節で議論する問題であり、すべてゼロインタフェース識別子に加えて、/ 32プレフィックスとゼロサフィックスリード。
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の割り当てをエンドサイトには、翻訳サービス、またはすべてのIPv4-翻訳可能なIPv6アドレスが同じリンク上に配置されている場合は、おそらく/ 96プレフィックスに/ 56のプレフィックスを捧げることができました。
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:
推奨プレフィックス長も展開シナリオの関数です。ステートレス翻訳はシナリオ1、シナリオ2、シナリオ5、及び[v4v6-FRAMEWORK]で定義されたシナリオ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.
O（IPv6ネットワークにIPv4インターネット）シナリオ1（IPv4インターネットへのIPv6ネットワーク）とシナリオ2の場合、ISP / 32を保持割り当てが/ 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.
Oシナリオ5（IPv4ネットワークにIPv6ネットワーク）とシナリオ6（IPv6ネットワークにIPv4ネットワーク）の場合、配備は/ 64または/ 96プレフィックスを使用すべきです。
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変換サービスのための周知のプレフィックスのいずれかを使用することもできます。
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.
これらのサービスが使用される場合のIPv4ノードはIPv4-で表されているが、IPv6ノードは、標準的なIPv6アドレスを介してアドレス指定されるセクション2.2で指定されるように、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つの例外を除いて、これらのシナリオで使用する必要があります。
o In all scenarios, the translation MAY use a Network-Specific Prefix, if deemed appropriate for management reasons.
Oすべてのシナリオでは、翻訳は、管理上の理由から、適切とみなされる場合は、ネットワーク固有のプレフィックスを使用するかもしれません。
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.
これは非グローバルIPv4アドレスとよく知られているプレフィックスを使用してにつながるとして、Oよく知られているプレフィックスは、（IPv4ネットワークにIPv6インターネット）シナリオ3のために使用してはいけません。つまり、このシナリオで使用されなければならない（例えば、/ 96プレフィックス）ネットワーク固有のプレフィックスを意味します。
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つの設計の選択肢、ヌルサフィックス、有名プレフィックスの特定の値を反映しています。ここでは、これらの二つの選択肢につながる議論の要約を提供します。
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 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-翻訳可能とIPv4-IPv6の変換アドレスは、つまり、「チェックサム・ニュートラル」のように構成された場合にステートレス翻訳の場合は、1の補数チェックサムを再計算する翻訳者は必要ないでしょうIPv6アドレスは、埋め込まれたIPv4アドレスと同じ1の補数チェックサムを持っているでしょう。二つのアドレスの一方のみが中立のチェックサムであるように、ステートフル翻訳の場合は、チェックサムの中立性は、翻訳時のチェックサム計算がなくなるわけではありません。私たちは、その1の補数プレフィックスを選択する、すなわち、チェックサムの中立性を保証するために、接尾辞で16ビットを予約すると考えられ、それはステートフル翻訳を助けないためとチェックサムの中立性もネットワーク固有のプレフィックスを適切に選択することによって達成することができるため、減少しましたチェックサムは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.
ポート範囲機能を持つステートレスな翻訳を補完する提案がなされています。代わりに、正確に1つのIPv6プレフィックス、オプションは、各ノードは、ポートの異なる範囲を管理して、いくつかのIPv6ノードがIPv4アドレスを共有することを可能にするためにIPv4アドレスをマッピングします。ポート範囲の拡張が必要な場合、それは現在サフィックスにヌルとして予約ビットを使用して、後に定義することができます。
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との競合を、理解しています。しかし、私たちの仕様では、そこに/ 64サブネット内のIPv4-翻訳可能IPv6アドレスを持つノードは1つだけなので、エニーキャストセマンティックは混乱を作成しません。そこで我々は、今のヌルサフィックスを維持することを決めました。この問題は、/ 40などの32ビット/ 56、/ 64よりも大きいプレフィクスのために存在し、そして我々は、セクション3.3にお勧め/ 96プレフィックスありません。
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;
O IPv4マッププレフィックスを再利用し、:: FFFF：0：0/96、RFC 2765で指定されるように、セクション2.1。
o request IANA to allocate a /32 prefix, or
O / 32プレフィックスを割り当てるようにIANAを要求する、または
o request allocation of a new /96 prefix.
新しい/ 96プレフィックスのO要求の割り当て。
We weighted the pros and cons of these choices before settling on the recommended /96 Well-Known Prefix.
私たちはお勧め/ 96よく知られているプレフィックスにセトリングする前にこれらの選択肢の長所と短所を加重します。
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マップの接頭辞を使用した場合、これらのノードは変更せずに変換をサポートすることはできません。これは、翻訳技術の主な目的を打ち負かします。 0：0/96我々は、このように、すなわち、IPv4-は接頭辞、:: FFFFをマッピングされて再使用しないことを決めた、最初の選択肢を排除しました。
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ビットに収まるように許可されたであろう。組織は、いくつかの翻訳者を展開するときに、ルーティングと負荷分散を容易にしているだろう。しかし、そのような送信先アドレスベースのロードバランシングは望ましくないかもしれません。これは、複数のステートフルな翻訳を含む展開でIPv4アドレスの異なるプールを有するそれぞれのNATのためのセッショントラバーサルユーティリティ（STUN）[RFC5389]と互換性がありません。翻訳者は、IPv4アドレスの同じプールを管理し、/ 32プレフィックスではなく/ 96プレフィックスを使用することには大きな利点がありません、その場合、それらの変換状態を、調整することができた場合はSTUNの互換性は、達成されるであろう。
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アドレスの法的なテキスト表現では、ドット十進は最後に表示することができます。 / 96プレフィックスは、その要件と互換性があります。それは、[RFC4291]に更新を必要とすることなく、ドット十進表記を可能にします。この表現は、読み取りに使用するアドレス形式を容易とログファイルが容易になります。
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アドレスと同じ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.
緩和は、リバースパスチェックを実装するために、パケットが許可された場所から来ているネットワーク全体を確認することです。
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 / IPv4のトランスレータにパケットを送信するためにIPv6ノードによって使用されています。攻撃者がネットワークの中断、サービスの拒否、および可能な情報開示、その結果、これらのパラメータの間違った値を使用してノードに、DNSゲートウェイ、とIPv4 / IPv6のトランスレータを欺くしようとする可能性があります。このような攻撃を軽減するために、ネットワーク管理者は、接頭辞が安全な方法で構成されていることを確認する必要があります。
The mechanisms for achieving secure configuration of prefixes are beyond the scope of this document.
接頭辞の安全な構成を実現するためのメカニズムは、このドキュメントの範囲を超えています。
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.
このフィルタリングを達成するために、ファイアウォールやセキュリティデバイスを構成するためのメカニズムは、このドキュメントの範囲を超えています。
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]「既知プレフィックス」64：IPv6アドレスにIPv4の間のアルゴリズムのマッピングに使用ff9b :: / 96は、RFC 6052あたり0000 :: / 8アドレスブロックの外に定義されています。
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.
BEHAVE WGでの多くの人々はアンドリュー・サリバン、アンドリューYourtchenko、アリKeranen、ブライアン・カーペンター、チャーリー・カウフマン、ダン・ウィング、デーブターラー、デヴィッド・ハリントン、エドJankiewicz、フレッド・ベイカー、宮田宏含め、本文書につながった議論に貢献してきました、IljitschバンBeijnum、ジョンSchnizlein、キースムーア、ケビン・殷、マグヌスウェスター、マーガレットワッサーマン、正人遠藤、フィル・ロバーツ、フィリップ・マシューズ、レミデニス・Courmont、レミ・デプレ、およびウィリアムWaites。
Marcelo Bagnulo is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program.
マルセロBagnuloの一部トリロジー、その第七次フレームワーク計画の下で、欧州委員会でサポートされている研究プロジェクトによって資金を供給されます。
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
フレッドベイカーシスコシステムズサンタバーバラ、カリフォルニア93117 USA電話：+ 1-408-526-4257ファックス：+ 1-413-473-2403 Eメール：fred@cisco.com
Hiroshi Miyata Yokogawa Electric Corporation 2-9-32 Nakacho Musashino-shi, Tokyo 180-8750 JAPAN EMail: h.miyata@jp.yokogawa.com
ひろし みやた よこがわ えぇｃｔりｃ こｒぽらちおん ２ー９ー３２ なかちょ むさしのーし、 ときょ １８０ー８７５０ じゃぱん えまいｌ： ｈ。みやた＠ｊｐ。よこがわ。こｍ
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年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.
[DNS64] Bagnulo、M.、サリバン、A.、マシューズ、P.、およびI. Beijnum、 "DNS64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレス変換のためのDNSの拡張"、進歩、2010年10月の作業。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004.
[RFC3849]ヒューストン、G.、主よ、A.、およびP.スミス、 "ドキュメンテーションのためのIPv6アドレスプレフィックス予約"、RFC 3849、2004年7月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "NAT（STUN）のセッショントラバーサルユーティリティ"、RFC 5389、2008年10月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]コットン、M.およびL. Vegoda、 "特別の使用のIPv4アドレス"、BCP 153、RFC 5735、2010年1月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952]川村、S.とM.川島、RFC 5952、2010年8月、 "IPv6アドレスのテキスト表現のための勧告"。
[v4v6-FRAMEWORK] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", Work in Progress, August 2010.
[v4v6-FRAMEWORK]ベーカー、F.はLi、X.、バオ、C.、およびK.陰陽 "のIPv4 / IPv6変換のためのフレームワーク" が進歩、2010年8月ワーク。
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
CongxiaoバオCERNETセンター/清華大学ルーム225、本館、清華大学、北京、100084中国電話：+86 10から62785983 Eメール：congxiao@cernet.edu.cn
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 U.S.A. EMail: huitema@microsoft.com
クリスチャンのHuitemaマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052-6399 U.S.A.メール：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
マルセロBagnulo UC3MのAv。大学30のレガネス、マドリード28911スペイン電話：+ 34-91-6249500電子メール：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
モハメド・Boucadairフランステレコム3のAvフランソワ・シャトー350000レンヌフランスメール：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
興李CERNETセンター/清華大学ルーム225、本館、清華大学、北京、100084中国電話：+86 10から62785983 Eメール：xing@cernet.edu.cn