[要約] RFC 6052は、IPv4/IPv6トランスレータのIPv6アドレッシングに関するガイドラインです。その目的は、IPv4と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.
これは、インターネット標準トラックドキュメントです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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では、プレフィックスの選択、それらを使用できる条件、およびSTATLESTENTおよびSTATEFUL翻訳を使用した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つの特定の設計上の決定の背後にある議論の要約、null接尾辞の選択と選択したプレフィックスの特定の値を示します。
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.
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 Translator：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-Translatable IPv6アドレス：Stateless Translationで使用するために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
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アドレスは、PLがプレフィックスの長さを指定する次の図に示されているように、可変長のプレフィックス、埋め込み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.)
これらのアドレスでは、プレフィックスは、アドレス翻訳者を展開する組織に固有の「よく知られているプレフィックス」または「ネットワーク固有のプレフィックス」のいずれかでなければなりません。接頭辞には、次の長さのうちの1つのみができます：32、40、48、56、64、または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]で定義されているホスト識別子形式との互換性のために予約されています。これらのビットはゼロに設定する必要があります。A /96ネットワーク固有のプレフィックスを使用する場合、管理者は、BITS 64〜71がゼロに設定されていることを確認する必要があります。それを達成する簡単な方法は、A /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.
o 接頭辞の長さは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.
o 接頭辞の長さは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.
o 接頭辞の長さは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.
o プレフィックスの長さが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.
o 接頭辞の長さは64ビットの場合、IPv4アドレスは位置72〜103にエンコードされます。
o When the prefix is 96 bits long, the IPv4 address is encoded in positions 96 to 127.
o 接頭辞の長さは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アドレスを受け取ったアドレス翻訳者は、ビットの値を無視し、ビットの値がゼロであるかのように進行する必要があります。（将来の拡張機能は、異なる動作を指定する場合があります。）
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.
o 接頭辞の長さが96ビット未満の場合は、図1に記載されているように、適切な位置（ビット64〜71）にnullオクテット「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;
o 接頭辞の長さが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.
o 他のプレフィックスの長さについては、「u」オクテットを削除して、120ビットシーケンス（効果的にビット72-127を位置64-119にシフトする）を取得し、プレフィックスに続いて32ビットを抽出します。
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-BeddedのIPv6アドレスは、[RFC4291]のセクション2.2に準拠してテキストで表されます。よく知られているプレフィックスまたはA /96ネットワーク固有のプレフィックスを使用して構築されたIPv4-埋め込みIPv6アドレスは、[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/IPv6の翻訳がよく知られているプレフィックスに依存している場合、IPv4よりも長いIPv4-埋め込みIPv6プレフィックスは、BGP（特に外部BGP）[RFC4271]で宣伝されてはなりません。IPv6のものであるため、グローバル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.
Stateless IPv4/IPv6翻訳を展開する組織は、IPv4/IPv6翻訳サービスにネットワーク固有のプレフィックスを割り当てる必要があります。IPv4翻訳可能およびIPv4変換IPv6アドレスは、セクション2.2で指定されているように構築する必要があります。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：DB8：122 ::/48を備えたIPv6ネットワークを検討します。ネットワーク管理者は、ステートレスIPv4/ IPv6翻訳を管理するために、ネットワーク固有のプレフィックス2001：DB8：122：344 ::/ 64を選択しました。IPv4サブネット192.0.2.0/24のIPv4翻訳可能なアドレスブロックは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年にバインドされたパケットに転送するように構成されています：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を組み合わせることで宛先アドレスを作成できます。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.
A /32プレフィックスを使用すると、すべてのルーティングビットがIPv6アドレスの上位64ビットに含まれており、優れたルーティングプロパティになります。ただし、これらの接頭辞を取得するのは難しい場合があり、A /32の小さなセットのIPv4翻訳可能なIPv6アドレスへの割り当ては無駄と見なされる場合があります。さらに、 /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はA /40プレフィックスを翻訳サービスに専用できます。A /48割り当てを備えたエンドサイトは、A /56プレフィックスを翻訳サービスに専用できます。すべてのIPv4-翻訳可能なIPv6アドレスが同じリンクにある場合、A /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フレームワーク]で定義されているシナリオ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.
o シナリオ1（IPv4インターネットへのIPv6ネットワーク）およびシナリオ2（IPv4インターネットへのIPv6ネットワークへ）の場合、A /32割り当てを保持しているISPはA /40プレフィックスを使用し、A /48割り当てを保持するサイトはAを使用する必要があります。/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（IPv4ネットワークへのIPv4ネットワーク）の場合、展開はA /64またはA /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.
組織は、ステートフルな翻訳技術に基づいて翻訳サービスを展開する場合があります。組織は、Stateful 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.
これらのサービスを使用すると、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フレームワーク]で定義されているシナリオで使用できます。よく知られているプレフィックスは、これらのシナリオで使用する必要がありますが、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.
o よく知られているプレフィックスは、シナリオ3（IPv6インターネットからIPv4ネットワークへ）に使用しないでください。つまり、ネットワーク固有のプレフィックス（たとえば、A /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つのデザインの選択肢、ヌル接尾辞と特定の値を反映しています。ここでは、これらの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アドレスの両方が「チェックサム中立」の方法で構築された場合、つまり、つまり、つまり、つまり、つまり、つまり、つまり、補完的なチェックサムを再計算する必要はありません。IPv6アドレスは、埋め込まれたIPv4アドレスと同じ補完チェックサムを持っています。ステートフル翻訳の場合、チェックサムの中立性は、翻訳中のチェックサム計算を排除しません。2つのアドレスのうち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.
ポートレンジ機能を使用して、ステートレス翻訳を補完する提案がありました。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.
A /32プレフィックスを使用すると、全ゼロの接尾辞がゼロインターフェイス識別子になります。RFC4291のセクション2.6.1との競合を理解しています。これは、すべてのゼロがサブネットルーターのAnycastアドレスに使用されることを指定しています。ただし、仕様には、 /64サブネットにIPv4翻訳可能なIPv6アドレスを持つ1つのノードのみがあるため、Anycastセマンティックは混乱を引き起こしません。したがって、私たちは今のところヌルの接尾辞を保持することにしました。この問題は、セクション3.3で推奨される /40、 /56、 /64、 /96のプレフィックスなど、32ビットを超える接頭辞には存在しません。
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 RFC 2765、セクション2.1で指定されているように、IPv4-Mappedプレフィックス:: FFFF：0：0/96を再利用します。
o request IANA to allocate a /32 prefix, or
o IANAにA /32プレフィックスを割り当てるように要求するか、
o request allocation of a new /96 prefix.
o 新しい /96プレフィックスの割り当てをリクエストします。
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-Mappedプレフィックスの主な利点は、既に定義されていることです。そのプレフィックスを再利用するには、最小限の標準化努力が必要です。ただし、現在の実装の副作用がある可能性があるため、すでに定義されていることは単なる利点ではありません。IPv4-Mappedプレフィックスが表示された場合、WindowsとMac OSの現在のバージョンはIPv4パケットを生成しますが、IPv6パケットは送信されません。IPv4-Mappedプレフィックスを使用した場合、これらのノードは変更なしで翻訳をサポートできません。これは、翻訳技術の主な目的を打ち負かします。したがって、最初の選択肢を排除しました。つまり、IPv4マッピングのプレフィックスを再利用しないことを決定しました:: FFFF：0：0/96。
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.
A /32プレフィックスは、埋め込まれたIPv4アドレスをIPv6アドレスの上位64ビットに収めることができました。これにより、組織が複数の翻訳者を展開すると、ルーティングとロードバランスが促進されます。ただし、このような目的地とアドレスベースの負荷分散は望ましくない場合があります。複数のステートフル翻訳者が関与する展開におけるNAT（STUN）[RFC5389]のセッショントラバーサルユーティリティと互換性はありません。それぞれがIPv4アドレスの異なるプールを持っています。スタン互換性は、翻訳者がIPv4アドレスの同じプールを管理し、翻訳状態を調整できる場合にのみ達成されます。その場合、A /96プレフィックスではなくA /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アドレスの法的テキスト表現では、点線の小数は最後にのみ表示できます。/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」、つまり、補完算術のゼロに等しい値です。このプレフィックスで構築されたIPv4-埋め込みIPv6アドレスは、埋め込まれたIPv4アドレスと同じ補体チェックサムを持ちます。
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ノードによって使用され、IPv6/IPv4翻訳者にパケットを送信します。攻撃者は、ノード、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] IPv4からIPv6アドレス間のアルゴリズムマッピングで使用されている「よく知られているプレフィックス」64：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.
Andrew Sullivan、Andrew Yourtchenko、Ari Keranen、Brian Carpenter、Charlie Kaufman、Dan Wing、Dave Thaler、David Harrington、David Harrington、Ed Jankiewicz、Fred Baker、Hiroshi Miyataataataataataataataataなど、Andrew Sullivan、Andrew Youtchenko、Ari Keranen、Brian Carpenter、Brian Carpenter、Brian Carpenterなど、この文書につながった議論に貢献しています。、Iljitsch Van Beijnum、John Schnizlein、Keith Moore、Kevin Yin、Magnus Westerlund、Margaret Wasserman、Masahito Endo、Phil Roberts、Philip Matthews、Remi Denis-Courmont、Remi Despres、William Waites。
Marcelo Bagnulo is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program.
Marcelo Bagnuloは、第7回のフレームワークプログラムに基づいて欧州委員会がサポートする研究プロジェクトであるTrilogyによって部分的に資金提供されています。
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
Dave Thaler Microsoft Corporation One Microsoft Way Redmond、WA 98052 USA電話：1 425 703 8835メール：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メール：fred@cisco.com
Hiroshi Miyata Yokogawa Electric Corporation 2-9-32 Nakacho Musashino-shi, Tokyo 180-8750 JAPAN EMail: h.miyata@jp.yokogawa.com
hiroshi miyata yokogawa Electric Corporation 2-9-32 Nakacho Musashino-Shi、東京180-8750日本メール：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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Deering、「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.、Sullivan、A.、Matthews、P。、およびI. Beijnum、「DNS64：DNS拡張機能IPv6クライアントからIPv4サーバーへのネットワークアドレス変換のための拡張」、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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004.
[RFC3849] Huston、G.、Lord、A。、およびP. Smith、「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.、Li、T。、およびS. Hares、「A Border Gateway Protocol 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] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NATのセッショントラバーサルユーティリティ（STUN）」、RFC 5389、2008年10月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735] Cotton、M。およびL. Vegoda、「Special Use 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] Kawamura、S。およびM. Kawashima、「IPv6アドレステキスト表現の推奨」、RFC 5952、2010年8月。
[v4v6-FRAMEWORK] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", Work in Progress, August 2010.
[V4v6-Framework] Baker、F.、Li、X.、Bao、C。、およびK. Yin、「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 BAO CERNET CENTER/Tsinghua University Room 225、メインビル、Tsinghua University北京、100084中国電話：86 10-62785983電子メール：congxiao@cernet.edu.cn
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 U.S.A. EMail: huitema@microsoft.com
Christian Huitema Microsoft Corporation One Microsoft Way Redmond、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
Marcelo Bagnulo UC3M AV。Universidad 30 Leganes、Madrid 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
Mohamed Boucadair France Telecom 3、Av Francois Chateaux Rennes 350000 Franceメール：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
Xing Li Cernet Center/Tsinghua University Room 225、メインビル、Tsinghua University Beijing、100084 China Phone：86 10-62785983メール：xing@cernet.edu.cn