[要約] RFC 7757は、状態を持たないIP/ICMP変換のための明示的なアドレスマッピングに関するものです。その目的は、IPv4とIPv6の間での通信を可能にするために、アドレス変換の手法を提供することです。
Internet Engineering Task Force (IETF) T. Anderson
Request for Comments: 7757 Redpill Linpro
Updates: 6145 A. Leiva Popper
Category: Standards Track NIC Mexico
ISSN: 2070-1721 February 2016
Explicit Address Mappings for Stateless IP/ICMP Translation
ステートレスIP / ICMP変換の明示的なアドレスマッピング
Abstract
概要
This document extends the Stateless IP/ICMP Translation Algorithm (SIIT) with an Explicit Address Mapping (EAM) algorithm and formally updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP translation between arbitrary (non-IPv4-translatable) IPv6 endpoints and IPv4.
このドキュメントでは、ステートレスIP / ICMP変換アルゴリズム（SIIT）を明示的アドレスマッピング（EAM）アルゴリズムで拡張し、RFC 6145を正式に更新します。EAMアルゴリズムは、任意の（IPv4以外で変換可能な）IPv6エンドポイントとIPv4間のステートレスIP / ICMP変換を容易にします。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc7757.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7757で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Explicit Address Mapping Algorithm . . . . . . . . . . . . . 5
3.1. Explicit Address Mapping Table . . . . . . . . . . . . . 5
3.2. Explicit Address Mapping Specification . . . . . . . . . 6
3.3. IP Address Translation Procedure . . . . . . . . . . . . 6
3.3.1. Address Translation Steps: IPv4 to IPv6 . . . . . . . 7
3.3.2. Address Translation Steps: IPv6 to IPv4 . . . . . . . 7
4. Hairpinning of IPv6 Traffic . . . . . . . . . . . . . . . . . 8
4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 8
4.2. Recommendation . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Simple Hairpinning Support . . . . . . . . . . . . . 9
4.2.2. Intrinsic Hairpinning Support . . . . . . . . . . . . 9
5. Overlapping Explicit Address Mappings . . . . . . . . . . . . 10
6. Lack of Checksum Neutrality . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 14
A.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.2. IVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.3. SIIT-DC . . . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix B. Example IP Address Translations . . . . . . . . . . 15
B.1. Hairpinning Examples . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
The Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145] specifies that when translating IPv4 addresses to IPv6 and vice versa, all addresses must be translated using the algorithm specified in [RFC6052]. This document specifies an alternative to the algorithm specified in [RFC6052], where IP addresses are translated according to a table of Explicit Address Mappings configured on the stateless translator. This removes the previous constraint that IPv6 nodes that communicate with IPv4 nodes through SIIT must be configured with IPv4-translatable IPv6 addresses.
ステートレスIP / ICMP変換アルゴリズム（SIIT）[RFC6145]は、IPv4アドレスをIPv6に、またはその逆に変換する場合、[RFC6052]で指定されたアルゴリズムを使用してすべてのアドレスを変換する必要があることを指定します。このドキュメントは、[RFC6052]で指定されたアルゴリズムの代替を指定します。IPアドレスは、ステートレストランスレータで構成された明示的アドレスマッピングの表に従って変換されます。これにより、SIITを介してIPv4ノードと通信するIPv6ノードをIPv4変換可能なIPv6アドレスで構成する必要があるという以前の制約が取り除かれます。
Translation using the Explicit Address Mapping Table does not replace [RFC6052]. For most use cases, it is expected that both algorithms are used in concert. The Explicit Address Mapping algorithm is used only when a mapping matching the address to be translated exists. If no matching mapping exists, the algorithm specified in [RFC6052] will be used instead. Thus, when translating an individual IP packet, an SIIT implementation might translate one of the two IP address fields according to an EAM, while the other IP address field is translated according to [RFC6052].
明示的アドレスマッピングテーブルを使用した変換は、[RFC6052]に代わるものではありません。ほとんどの使用例では、両方のアルゴリズムが協調して使用されることが予想されます。明示的アドレスマッピングアルゴリズムは、変換されるアドレスと一致するマッピングが存在する場合にのみ使用されます。一致するマッピングが存在しない場合は、[RFC6052]で指定されたアルゴリズムが代わりに使用されます。したがって、個々のIPパケットを変換するとき、SIIT実装は2つのIPアドレスフィールドの1つをEAMに従って変換し、他のIPアドレスフィールドは[RFC6052]に従って変換する場合があります。
This document makes use of the following terms:
このドキュメントでは、次の用語を使用しています。
EAM: An Explicit Address Mapping, as specified in Section 3.2.
EAM：セクション3.2で指定されている明示的なアドレスマッピング。
EAMT: The Explicit Address Mapping Table, as specified in Section 3.1.
EAMT：セクション3.1で指定されている明示アドレスマッピングテーブル。
Inner (header or address): Refers to an IP header located inside the payload of an ICMP error packet or to an IP address within that header. Compare with "Outer".
内部（ヘッダーまたはアドレス）：ICMPエラーパケットのペイロード内にあるIPヘッダー、またはそのヘッダー内のIPアドレスを指します。 「アウター」と比較してください。
Outer (header or address): Refers to the first IP header in a packet or to an IP address within that header. In other words, an IP header or address that is NOT "Inner". If a reference is made to an IP header or address without the "Inner" or "Outer" qualifier, it should be considered as "Outer".
外部（ヘッダーまたはアドレス）：パケットの最初のIPヘッダー、またはそのヘッダー内のIPアドレスを指します。つまり、「内部」ではないIPヘッダーまたはアドレス。 「Inner」または「Outer」修飾子のないIPヘッダーまたはアドレスが参照されている場合、「Outer」と見なされます。
SIIT: The Stateless IP/ICMP Translation Algorithm, as specified in [RFC6145].
SIIT：[RFC6145]で指定されているステートレスIP / ICMP変換アルゴリズム。
XLAT: Short for "translation".
XLAT：「translation」の略。
IPv4-Converted IPv6 Addresses: As defined in Section 1.3 of [RFC6052].
IPv4-Converted IPv6 Addresses：[RFC6052]のセクション1.3で定義されています。
IPv4-Translatable IPv6 Addresses: As defined in Section 1.3 of [RFC6052].
IPv4-Translatable IPv6 Addresses：[RFC6052]のセクション1.3で定義されています。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Section 3.2.1 of [RFC6144] notes that "stateless translation mechanisms typically put constraints on what IPv6 addresses can be assigned to IPv6 nodes that want to communicate with IPv4 destinations using an algorithmic mapping." In practice, this means that the IPv6 nodes must be configured with IPv4-translatable IPv6 addresses. For the reasons discussed below, some environments may find that the use of IPv4-translatable IPv6 addresses is not desired or even possible.
[RFC6144]のセクション3.2.1は、「ステートレス変換メカニズムは通常、アルゴリズムマッピングを使用してIPv4宛先と通信したいIPv6ノードに割り当てることができるIPv6アドレスに制約を課す」と述べています。実際には、これは、IPv6ノードがIPv4で変換可能なIPv6アドレスで構成されている必要があることを意味します。以下で説明する理由により、一部の環境では、IPv4で変換可能なIPv6アドレスの使用が望ましくない、または不可能である場合もあります。
Limited availability: The number of IPv4-translatable IPv6 addresses available to an operator is equal to the number of IPv4 addresses that is assigned to the SIIT function. IPv4 addresses are scarce, and as a result, an operator might not have enough IPv4-translatable IPv6 addresses to number the entire IPv6 infrastructure.
限定的な可用性：オペレーターが使用できるIPv4変換可能なIPv6アドレスの数は、SIIT機能に割り当てられているIPv4アドレスの数と同じです。 IPv4アドレスは不足しており、その結果、オペレーターはIPv6インフラストラクチャ全体に番号を付けるのに十分なIPv4変換可能なIPv6アドレスを持っていない可能性があります。
Restricted format: IPv4-translatable IPv6 addresses must conform to the format specified in Section 2.2 of [RFC6052]. This format is not compatible with other common IPv6 address formats, such as the IPv6 address format based on the 64-bit Extended Unique Identifier (EUI-64) and used by IPv6 Stateless Address Autoconfiguration [RFC4862].
制限付きフォーマット：IPv4で変換可能なIPv6アドレスは、[RFC6052]のセクション2.2で指定されたフォーマットに準拠する必要があります。この形式は、64ビット拡張一意識別子（EUI-64）に基づくIPv6アドレス形式など、他の一般的なIPv6アドレス形式と互換性がなく、IPv6ステートレスアドレス自動構成[RFC4862]で使用されます。
An operator could overcome the above two problems by building an IPv6 network using regular (non-IPv4-translatable) IPv6 addresses and assigning IPv4-translatable IPv6 addresses as secondary addresses on the nodes that want to communicate with IPv4 nodes through SIIT only. However, doing so may result in a new set of undesired consequences:
オペレーターは、通常の（IPv4変換不可）IPv6アドレスを使用してIPv6ネットワークを構築し、IPv4変換可能IPv6アドレスをSIITのみを介してIPv4ノードと通信するノードのセカンダリアドレスとして割り当てることにより、上記の2つの問題を克服できます。ただし、これを行うと、望ましくない結果が新たに発生する可能性があります。
Routing complexity: The IPv4-translatable IPv6 addresses must be routed throughout the IPv6 network separately from the primary (non-IPv4-translatable) IPv6 addresses used by the nodes. It might be impossible to aggregate these routes, as two adjacent IPv4-translatable IPv6 addresses might not be assigned to two adjacent IPv6 nodes. As a result, in order to support SIIT, the IPv6 network might need to carry a large number of extraneous routes. These routes must be separately injected into the IPv6 routing topology somehow. Any intermediate devices in the IPv6 network such as a firewall might require special configuration in order to treat the IPv4-translatable IPv6 address the same as the primary IPv6 address, for example, by requiring that any Access Control List (ACL) entries involving the primary IPv6 address of a node must be duplicated.
ルーティングの複雑さ：IPv4で変換可能なIPv6アドレスは、ノードで使用されるプライマリ（IPv4で変換できない）IPv6アドレスとは別に、IPv6ネットワーク全体にルーティングする必要があります。 2つの隣接するIPv4変換可能なIPv6アドレスが2つの隣接するIPv6ノードに割り当てられていない可能性があるため、これらのルートを集約することは不可能である可能性があります。その結果、SIITをサポートするために、IPv6ネットワークは多数の無関係なルートを運ぶ必要があるかもしれません。これらのルートは、何らかの方法でIPv6ルーティングトポロジに個別に挿入する必要があります。ファイアウォールなどのIPv6ネットワークの中間デバイスでは、IPv4変換可能なIPv6アドレスをプライマリIPv6アドレスと同じように処理するために、たとえば、プライマリに関連するアクセス制御リスト（ACL）エントリを要求することにより、特別な構成が必要になる場合があります。ノードのIPv6アドレスは重複する必要があります。
Operational complexity: The IPv4-translatable IPv6 addresses not only have to be assigned to the IPv6 nodes participating in SIIT, but also all applications and services on those nodes must be configured to use them. For example, if the IPv6 node is a load balancer, it might require a separate virtual server definition using the IPv4-translatable IPv6 address in addition to one using the service's primary IPv6 address. A web server might require specific configuration to listen for connections on both the IPv4-translatable and the primary IPv6 address. A high-availability cluster service must be set up to fail over both addresses between cluster nodes, and depending on how the IPv6 network learns the location of the IPv4-translatable IPv6 address, the fail-over mechanism used for the two addresses might be completely different. Service monitoring must be done for both the IPv4-translatable and the primary IPv6 address, and any troubleshooting procedures must be extended to involve both addresses. Finally, the Default Address Selection Policy Table [RFC6724] on the IPv6 nodes might need to be altered in order to ensure that outbound sessions towards the IPv4 Internet are sourced from an IPv4-translatable IPv6 address.
運用の複雑さ：IPv4で変換可能なIPv6アドレスは、SIITに参加しているIPv6ノードに割り当てる必要があるだけでなく、それらのノード上のすべてのアプリケーションとサービスを使用するように構成する必要があります。たとえば、IPv6ノードがロードバランサーの場合、サービスのプライマリIPv6アドレスを使用する仮想サーバー定義に加えて、IPv4変換可能なIPv6アドレスを使用する個別の仮想サーバー定義が必要になる場合があります。 Webサーバーは、IPv4変換可能アドレスとプライマリIPv6アドレスの両方で接続をリッスンするために特定の構成を必要とする場合があります。高可用性クラスターサービスは、クラスターノード間で両方のアドレスをフェールオーバーするように設定する必要があり、IPv6ネットワークがIPv4変換可能なIPv6アドレスの場所を学習する方法によっては、2つのアドレスに使用されるフェールオーバーメカニズムが完全になる場合があります違う。 IPv4変換可能アドレスとプライマリIPv6アドレスの両方に対してサービスの監視を行う必要があり、トラブルシューティング手順を拡張して両方のアドレスを含める必要があります。最後に、IPv4インターネットへの発信セッションがIPv4変換可能なIPv6アドレスから供給されるようにするために、IPv6ノードのデフォルトアドレス選択ポリシーテーブル[RFC6724]を変更する必要がある場合があります。
In short, the use of IPv4-translatable IPv6 addresses in parallel with regular IPv6 addresses is in many ways analogous to the use of dual stack [RFC4213]. While no actual IPv4 packets are used, the IPv4-translatable IPv6 addresses create a secondary "stack" in the infrastructure that must be treated and operated separately from the primary one. This increases the complexity of the overall infrastructure, in turn increasing operational overhead and reducing reliability. An operator who for such reasons finds the use of dual stack unappealing might feel the same way about using SIIT with IPv4-translatable IPv6 addresses.
つまり、通常のIPv6アドレスと並行してIPv4変換可能なIPv6アドレスを使用することは、デュアルスタック[RFC4213]の使用と多くの点で類似しています。実際のIPv4パケットは使用されませんが、IPv4で変換可能なIPv6アドレスは、プライマリインフラストラクチャとは別に処理および操作する必要のあるインフラストラクチャにセカンダリスタックを作成します。これにより、インフラストラクチャ全体の複雑さが増し、運用オーバーヘッドが増加し、信頼性が低下します。このような理由でデュアルスタックの魅力がないと感じるオペレーターは、IPv4で変換可能なIPv6アドレスでSIITを使用するのと同じように感じるかもしれません。
This normative section defines the EAM algorithm and formally updates Sections 4.1 and 5.1 of [RFC6145]. Specifically, when the EAM algorithm is applied, it supplants the requirement in [RFC6145] that states that a translator operating in the stateless mode must translate the Source Address and Destination Address IP header fields according to Section 2.3 of [RFC6052].
この規範的なセクションはEAMアルゴリズムを定義し、[RFC6145]のセクション4.1および5.1を正式に更新します。具体的には、EAMアルゴリズムが適用されると、ステートレスモードで動作するトランスレーターは[RFC6052]のセクション2.3に従って送信元アドレスと宛先アドレスのIPヘッダーフィールドを変換する必要があるという[RFC6145]の要件に取って代わります。
An SIIT implementation includes an EAMT, a conceptual table in which each row represents an EAM. Each EAM describes a mapping between IPv4 and IPv6 prefixes/addresses. An operator populates the EAMT to provide the mappings between the two address families.
SIIT実装には、各行がEAMを表す概念表であるEAMTが含まれています。各EAMは、IPv4とIPv6のプレフィックス/アドレス間のマッピングを記述します。オペレーターはEAMTにデータを入力して、2つのアドレスファミリー間のマッピングを提供します。
The EAMT consists of the following columns:
EAMTは次の列で構成されています。
o IPv4 Prefix
o IPv4プレフィックス
o IPv6 Prefix
o IPv6プレフィックス
SIIT implementations MAY include other columns in order to support proprietary extensions to the EAM algorithm.
SIIT実装は、EAMアルゴリズムの独自の拡張をサポートするために、他の列を含めることができます。
Throughout this document, figures representing the EAMT contain an Index column using the pound sign as the header. This column is not a required part of this specification; it is included only as a convenience to the reader.
このドキュメント全体を通して、EAMTを表す図には、シャープ記号をヘッダーとして使用したインデックス列が含まれています。この列は、この仕様の必須部分ではありません。読者の便宜のためにのみ含まれています。
An EAM consists of an IPv4 prefix and an IPv6 prefix. The prefix length MAY be omitted, in which case the implementation MUST assume it to be 32 for IPv4 and 128 for IPv6. Figure 1 illustrates an EAMT containing examples of valid EAMs.
EAMは、IPv4プレフィックスとIPv6プレフィックスで構成されます。接頭辞の長さは省略できます。その場合、実装はIPv4の場合は32、IPv6の場合は128であると想定する必要があります。図1は、有効なEAMの例を含むEAMTを示しています。
+---+----------------+----------------------+
| # | IPv4 Prefix | IPv6 Prefix |
+---+----------------+----------------------+
| 1 | 192.0.2.1 | 2001:db8:aaaa:: |
| 2 | 192.0.2.2/32 | 2001:db8:bbbb::b/128 |
| 3 | 192.0.2.16/28 | 2001:db8:cccc::/124 |
| 4 | 192.0.2.128/26 | 2001:db8:dddd::/64 |
| 5 | 192.0.2.192/29 | 2001:db8:eeee:8::/62 |
| 6 | 192.0.2.224/31 | 64:ff9b::/127 |
+---+----------------+----------------------+
Figure 1: Example EAMT
図1：EAMTの例
An EAM's IPv4 prefix value MUST have an identical or smaller number of suffix bits than its corresponding IPv6 prefix value.
EAMのIPv4プレフィックス値は、対応するIPv6プレフィックス値と同じか、それよりも少ない数のサフィックスビットを持つ必要があります。
Unless otherwise specified in Section 4, an SIIT implementation MUST individually translate each IP address it encounters in the packet's IP headers (including any IP headers contained within ICMP errors) according to Section 3.3.
セクション4で特に指定されていない限り、SIIT実装は、セクション3.3に従って、パケットのIPヘッダー（ICMPエラーに含まれるIPヘッダーを含む）で遭遇する各IPアドレスを個別に変換する必要があります。
This section describes step by step how an SIIT implementation translates addresses between IPv4 and IPv6. Only the outcome of the algorithm described should be considered normative, that is, an SIIT implementation may implement the exact procedure differently than what is described here, but the outcome of the algorithm MUST be the same.
このセクションでは、SIIT実装がIPv4とIPv6の間でアドレスを変換する方法を段階的に説明します。記述されたアルゴリズムの結果のみが規範的であると見なされるべきです。つまり、SIIT実装は、ここで説明されたものとは異なる正確な手順を実装する可能性がありますが、アルゴリズムの結果は同じでなければなりません。
For concrete examples of IP address translations, refer to Appendix B.
IPアドレス変換の具体例については、付録Bを参照してください。
1. The IPv4 prefix column of the EAMT is searched for the EAM entry that shares the longest common prefix with the IPv4 address being translated. The IPv4 prefix and IPv6 prefix values of the EAM entry found is from now on referred to as EAM4 and EAM6, respectively.
1. EAMTのIPv4プレフィックス列で、変換されるIPv4アドレスと最も長い共通プレフィックスを共有するEAMエントリが検索されます。見つかったEAMエントリのIPv4プレフィックスとIPv6プレフィックスの値は、それぞれEAM4とEAM6と呼ばれます。
2. If no matching EAM entry is found, the EAM algorithm is aborted. The SIIT implementation MUST proceed to translate the address in accordance with [RFC6145] (and its updates).
2. 一致するEAMエントリが見つからない場合、EAMアルゴリズムは中止されます。 SIIT実装は、[RFC6145]（およびその更新）に従ってアドレスを変換する必要があります。
3. The prefix bits of EAM4 are removed from the IPv4 address being translated. The remaining suffix bits from the IPv4 address being translated are stored in a temporary buffer.
3. EAM4のプレフィックスビットは、変換されるIPv4アドレスから削除されます。変換されるIPv4アドレスの残りのサフィックスビットは、一時バッファーに格納されます。
4. The prefix bits of EAM6 are prepended to the temporary buffer.
4. EAM6のプレフィックスビットは、一時バッファの先頭に追加されます。
5. If the temporary buffer at this point does not contain a 128-bit value, it is padded with trailing zeros so that it reaches a length of 128 bits.
5. この時点の一時バッファーに128ビット値が含まれていない場合は、128ビットの長さに達するように後続ゼロが埋め込まれます。
6. The contents of the temporary buffer is the translated IPv6 address.
6. 一時バッファーの内容は、変換されたIPv6アドレスです。
1. The IPv6 prefix column of the EAMT is searched for the EAM entry that shares the longest common prefix with the IPv6 address being translated. The IPv4 prefix and IPv6 prefix values of the EAM entry found is from now on referred to as EAM4 and EAM6, respectively.
1. EAMTのIPv6プレフィックス列が検索され、変換されるIPv6アドレスと最も長い共通プレフィックスを共有するEAMエントリが検索されます。見つかったEAMエントリのIPv4プレフィックスとIPv6プレフィックスの値は、それぞれEAM4とEAM6と呼ばれます。
2. If no matching EAM entry is found, the EAM algorithm is aborted. The SIIT implementation MUST proceed to translate the address in accordance with [RFC6145] (and its updates).
2. 一致するEAMエントリが見つからない場合、EAMアルゴリズムは中止されます。 SIIT実装は、[RFC6145]（およびその更新）に従ってアドレスを変換する必要があります。
3. The prefix bits of EAM6 are removed from the IPv6 address being translated. The remaining suffix bits from the IPv6 address being translated are stored in a temporary buffer.
3. EAM6のプレフィックスビットは、変換されるIPv6アドレスから削除されます。変換されるIPv6アドレスの残りのサフィックスビットは、一時バッファーに格納されます。
4. The prefix bits of EAM4 are prepended to the temporary buffer.
4. EAM4のプレフィックスビットは、一時バッファの先頭に追加されます。
5. If the temporary buffer at this point does not contain a 32-bit value, any trailing bits are discarded so that the buffer is reduced to a length of 32 bits.
5. この時点の一時バッファーに32ビット値が含まれていない場合、後続のビットは破棄され、バッファーは32ビットの長さに縮小されます。
6. The contents of the temporary buffer is the translated IPv4 address.
6. 一時バッファーの内容は、変換されたIPv4アドレスです。
Two IPv6 nodes that are both covered by EAMs might in certain circumstances attempt to communicate through a stateless translator rather than using native IPv6 directly. This happens if one of the nodes initiates traffic towards the IPv4-converted IPv6 address whose embedded IPv4 address matches an EAM that covers the other node. Special consideration is required in order to make this communication pattern work in a bidirectional fashion. This is illustrated by the example below.
両方がEAMでカバーされている2つのIPv6ノードは、特定の状況で、ネイティブIPv6を直接使用するのではなく、ステートレストランスレーターを介して通信しようとする場合があります。これは、埋め込まれたIPv4アドレスが他のノードをカバーするEAMと一致するIPv4変換されたIPv6アドレスへのトラフィックをノードの1つが開始した場合に発生します。この通信パターンを双方向で機能させるには、特別な配慮が必要です。これを以下の例で示します。
Assume that a stateless translator is configured with a translation prefix of 64:ff9b::/96 (per [RFC6052]) and the EAMT shown in Figure 1. The IPv6 node 2001:db8:aaaa:: transmits an IPv6 packet towards 64:ff9b::192.0.2.2, which reaches the translator and is translated into an IPv4 packet with source address 192.0.2.1 and destination address 192.0.2.2. This destination address is found in the EAMT, so the packet loops back into the translation function and is translated back to an IPv6 packet with source address 2001:db8:aaaa:: and destination address 2001:db8:bbbb::b.
ステートレストランスレータが64：ff9b :: / 96の変換プレフィックス（[RFC6052]ごと）および図1に示すEAMTで構成されていると想定します。IPv6ノード2001：db8：aaaa ::はIPv6パケットを64に送信します。 ff9b :: 192.0.2.2。トランスレータに到達し、送信元アドレス192.0.2.1および宛先アドレス192.0.2.2のIPv4パケットに変換されます。この宛先アドレスはEAMTにあるため、パケットはループして変換機能に戻り、ソースアドレス2001：db8：aaaa ::および宛先アドレス2001：db8：bbbb :: bを持つIPv6パケットに変換されます。
While this packet will reach its destination just fine, a problem will occur when 2001:db8:bbbb::b responds to it. The response packet will have a source address of 2001:db8:bbbb::b and a destination address of 2001:db8:aaaa:: and will be routed directly to its destination without being subjected to any form of translation. Because the source address of this response packet (2001:db8:bbbb::b) is not equal to the destination address of the initial outgoing packet (64:ff9b::192.0.2.2), the packet will most likely be discarded by 2001:db8:aaaa::, and bidirectional communication will most likely fail.
このパケットは宛先に問題なく到達しますが、2001：db8：bbbb :: bがそれに応答すると問題が発生します。応答パケットの送信元アドレスは2001：db8：bbbb :: bであり、宛先アドレスは2001：db8：aaaa ::であり、いかなる形式の変換も受けずにその宛先に直接ルーティングされます。この応答パケットの送信元アドレス（2001：db8：bbbb :: b）は最初の発信パケットの宛先アドレス（64：ff9b :: 192.0.2.2）と等しくないため、パケットは2001年までに破棄される可能性が高い：db8：aaaa ::、そして双方向通信はおそらく失敗します。
The above scenario could be made to work by ensuring that the stateless translator is hairpinning the traffic in both directions. Section 4.2 describes how this is accomplished. The resulting address translations are demonstrated step by step in Appendix B.1.
上記のシナリオは、ステートレストランスレータが双方向でトラフィックをヘアピンしていることを確認することで機能するように作成できます。セクション4.2では、これがどのように行われるかについて説明します。結果のアドレス変換は、付録B.1で段階的に示されています。
An SIIT implementation SHOULD include a feature that ensures that hairpinned IPv6 traffic is supported. The feature SHOULD be enabled by default. The following two subsections describe two alternate ways to implement this feature. An implementation MAY support both approaches.
SIIT実装には、ヘアピンされたIPv6トラフィックがサポートされることを保証する機能が含まれる必要があります（SHOULD）。この機能はデフォルトで有効にする必要があります（SHOULD）。次の2つのサブセクションでは、この機能を実装する2つの代替方法について説明します。実装は両方のアプローチをサポートしてもよい（MAY）。
When the simple hairpinning feature is enabled, the translator employs the following rules when translating from IPv4 to IPv6:
シンプルヘアピニング機能が有効な場合、トランスレータはIPv4からIPv6への変換時に次のルールを使用します。
1. If the packet is not an ICMPv4 error: The EAM algorithm MUST NOT be used in order to translate the source address in the IPv4 header.
1. パケットがICMPv4エラーではない場合：IPv4ヘッダーの送信元アドレスを変換するために、EAMアルゴリズムを使用してはなりません（MUST NOT）。
2. If the packet is an ICMPv4 error: The EAM algorithm MUST NOT be used when translating the destination address in the inner IPv4 header.
2. パケットがICMPv4エラーの場合：内部IPv4ヘッダーの宛先アドレスを変換するときにEAMアルゴリズムを使用してはなりません（MUST NOT）。
3. If the packet is an ICMPv4 error whose outer IPv4 source address is equal to its inner IPv4 destination address: The EAM algorithm MUST NOT be used in order to translate the source address in the outer IPv4 header.
3. パケットが外部IPv4送信元アドレスが内部IPv4宛先アドレスと等しいICMPv4エラーの場合：外部IPv4ヘッダーの送信元アドレスを変換するためにEAMアルゴリズムを使用してはなりません（MUST NOT）。
Rules #2 and #3 are cumulative.
ルール＃2と＃3は累積的です。
The addresses in question MUST instead be translated according to [RFC6145], as if they did not match any EAM.
問題のアドレスは、代わりに、[RFC6145]に従って、EAMと一致しないかのように変換する必要があります。
When the intrinsic hairpinning feature is enabled, the translator employs the following rules after having translated an IPv6 packet to IPv4:
固有のヘアピニング機能が有効な場合、IPv6パケットをIPv4に変換した後、トランスレータは次のルールを採用します。
If all the conditions in either of the two sets below are true, the packet is to be hairpinned. The implementation MUST immediately (i.e., prior to forwarding it to the IPv4 network) translate the packet back to IPv6. During the second translation pass, the behavior specified in Section 4.2.1 MUST be applied, and the Hop Limit field SHOULD NOT be decremented.
以下の2つのセットのいずれかの条件がすべて当てはまる場合、パケットはヘアピンされます。実装はただちに（つまり、IPv4ネットワークに転送する前に）パケットをIPv6に変換する必要があります。 2番目の変換パスでは、セクション4.2.1で指定された動作を適用する必要があり、ホップ制限フィールドはデクリメントしてはなりません（SHOULD NOT）。
Condition set A:
条件セットA：
A1. The packet is not an ICMPv4 error.
A1。パケットはICMPv4エラーではありません。
A2. The destination address was translated using the algorithm in [RFC6052].
A2。宛先アドレスは、[RFC6052]のアルゴリズムを使用して変換されました。
A3. The destination address is found in the EAMT.
A3。宛先アドレスはEAMTにあります。
Condition set B:
条件セットB：
B1. The packet is an ICMPv4 error.
B1。パケットはICMPv4エラーです。
B2. The inner source address was translated using the algorithm in [RFC6052].
B2。内部送信元アドレスは、[RFC6052]のアルゴリズムを使用して変換されました。
B3. The inner source address is found in the EAMT.
B3。内部ソースアドレスはEAMTにあります。
The algorithm specified in Section 3 relies on making a lookup in the EAMT in order to find the EAM entry that shares the longest common prefix with the address being translated. Operators should note that configuring EAMs with overlapping or identical IPv4 or IPv6 prefixes in the EAMT may create configurations where the IPv4-to-IPv6 and IPv6-to-IPv4 address translations will not be symmetric. This may in some cases make bidirectional communication impossible.
セクション3で指定されたアルゴリズムは、変換されるアドレスと最長の共通プレフィックスを共有するEAMエントリを見つけるために、EAMTでルックアップを行うことに依存しています。オペレーターは、EAMTでIPv4またはIPv6プレフィックスの重複または同一のEAMを構成すると、IPv4-to-IPv6およびIPv6-to-IPv4アドレス変換が対称的でない構成を作成する場合があることに注意してください。これにより、双方向通信ができなくなる場合があります。
EAM #1 in the example EAMT (Figure 2) could be thought of as implementing IVI (Appendix A.2), while EAM #2 introduces a single exception in the style of SIIT-DC (Appendix A.3). The IPv4 prefixes of the two EAMs overlap, while the IPv6 prefixes do not. This results in a situation where the IPv6 address 2001:db8:ffc6:3364:4000:: will be translated (according to EAM #1) to the IPv4 address 198.51.100.64. However, when this IPv4 address is translated back to IPv6, it will be translated (according to EAM #2) to the IPv6 address 2001:db8::abcd. Because the IPv4-to-IPv6 translation in this example does not mirror the corresponding IPv6- to-IPv4 translation, bidirectional communication involving the IPv6 address 2001:db8:ffc6:3364:4000:: might fail. In order to help avoid such situations, implementations MAY warn the operator when a new EAM that overlaps with a previously existing one is inserted into the EAMT.
EAMTの例（図2）のEAM＃1はIVI（付録A.2）の実装と考えることができますが、EAM＃2はSIIT-DC（付録A.3）のスタイルで単一の例外を導入します。 2つのEAMのIPv4プレフィックスは重複しますが、IPv6プレフィックスは重複しません。この結果、IPv6アドレス2001：db8：ffc6：3364：4000 ::が（EAM＃1に従って）IPv4アドレス198.51.100.64に変換されます。ただし、このIPv4アドレスがIPv6に変換されると、（EAM＃2に従って）IPv6アドレス2001：db8 :: abcdに変換されます。この例のIPv4-to-IPv6変換は対応するIPv6-to-IPv4変換をミラーリングしないため、IPv6アドレス2001：db8：ffc6：3364：4000 ::を含む双方向通信は失敗する可能性があります。そのような状況を回避するのを助けるために、実装は、以前に存在するものとオーバーラップする新しいEAMがEAMTに挿入されるとき、オペレーターに警告するかもしれません。
+---+------------------+--------------------+
| # | IPv4 Prefix | IPv6 Prefix |
+---+------------------+--------------------+
| 1 | 0.0.0.0/0 | 2001:db8:ff00::/40 |
| 2 | 198.51.100.64/32 | 2001:db8::abcd/128 |
+---+------------------+--------------------+
Figure 2: EAMT Containing Overlapping IPv4 Prefixes
図2：重複するIPv4プレフィックスを含むEAMT
In Figure 3, the IPv6 prefixes of the two EAMs are identical. The behavior of the stateless translator when translating an IPv6 packet that contains the address 2001:db8::1 to IPv4 is in this case unspecified. In order to prevent this situation from occurring, implementations MAY refuse to insert a new EAM, whose IPv4 or IPv6 prefix value is identical to that of an already existing EAM, into the EAMT.
図3では、2つのEAMのIPv6プレフィックスは同じです。この場合、アドレス2001：db8 :: 1を含むIPv6パケットをIPv4に変換するときのステートレストランスレーターの動作は指定されていません。この状況の発生を防ぐために、実装は、IPv4またはIPv6プレフィックス値が既存のEAMと同じである新しいEAMをEAMTに挿入することを拒否してもよい（MAY）。
+---+-----------------+-----------------+
| # | IPv4 Prefix | IPv6 Prefix |
+---+-----------------+-----------------+
| 1 | 198.51.100.8/32 | 2001:db8::1/128 |
| 2 | 198.51.100.9/32 | 2001:db8::1/128 |
+---+-----------------+-----------------+
Figure 3: EAMT Containing Identical IPv6 Prefixes
図3：同一のIPv6プレフィックスを含むEAMT
When one or both of the address fields in an IP/ICMP packet are translated according to the EAM algorithm, the translation cannot be relied upon to be checksum neutral, even if the well-known prefix 64:ff9b::/96 is used. This consideration is discussed in more detail in Section 4.1 of [RFC6052].
IP / ICMPパケットのアドレスフィールドの一方または両方がEAMアルゴリズムに従って変換される場合、既知のプレフィックス64：ff9b :: / 96が使用されていても、変換はチェックサムニュートラルであるとは言えません。この考慮事項については、[RFC6052]のセクション4.1で詳しく説明しています。
The EAM algorithm does not introduce any new security issues beyond those that are already discussed in Section 7 of [RFC6145].
EAMアルゴリズムでは、[RFC6145]のセクション7ですでに説明されている問題以外に、新しいセキュリティ問題は発生しません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>.
[RFC6052] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M。、およびX. Li、「IPv4 / IPv6トランスレータのIPv6アドレッシング」、RFC 6052、DOI 10.17487 / RFC6052、2010年10月、< http://www.rfc-editor.org/info/rfc6052>。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, <http://www.rfc-editor.org/info/rfc6145>.
[RFC6145] Li、X.、Bao、C。、およびF. Baker、「IP / ICMP変換アルゴリズム」、RFC 6145、DOI 10.17487 / RFC6145、2011年4月、<http://www.rfc-editor.org/ info / rfc6145>。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, <http://www.rfc-editor.org/info/rfc4213>.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストおよびルーターの基本的な移行メカニズム」、RFC 4213、DOI 10.17487 / RFC4213、2005年10月、<http://www.rfc-editor.org/info/rfc4213 >。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<http://www.rfc-editor.org/info / rfc4862>。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, April 2011, <http://www.rfc-editor.org/info/rfc6144>.
[RFC6144] Baker、F.、Li、X.、Bao、C。、およびK. Yin、「IPv4 / IPv6変換のフレームワーク」、RFC 6144、DOI 10.17487 / RFC6144、2011年4月、<http：// www。 rfc-editor.org/info/rfc6144>。
[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition", RFC 6219, DOI 10.17487/RFC6219, May 2011, <http://www.rfc-editor.org/info/rfc6219>.
[RFC6219] Li、X.、Bao、C.、Chen、M.、Zhang、H.、J。Wu、「The China Education and Research Network（CERNET）IVI Translation Design and Deployment for the IPv4 / IPv6 Coexistence and移行」、RFC 6219、DOI 10.17487 / RFC6219、2011年5月、<http://www.rfc-editor.org/info/rfc6219>。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724] Thaler、D.、Ed。、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、DOI 10.17487 / RFC6724、2012年9月、<http://www.rfc-editor.org/info/rfc6724>。
[RFC6791] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G. Huston, "Stateless Source Address Mapping for ICMPv6 Packets", RFC 6791, DOI 10.17487/RFC6791, November 2012, <http://www.rfc-editor.org/info/rfc6791>.
[RFC6791] Li、X.、Bao、C.、Wing、D.、Vaithianathan、R。、およびG. Huston、「ICMPv6パケットのステートレスソースアドレスマッピング」、RFC 6791、DOI 10.17487 / RFC6791、2012年11月、< http://www.rfc-editor.org/info/rfc6791>。
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <http://www.rfc-editor.org/info/rfc6877>.
[RFC6877] Mawatari、M.、Kawashima、M。、およびC. Byrne、「464XLAT：Combination of Stateful and Stateless Translation」、RFC 6877、DOI 10.17487 / RFC6877、2013年4月、<http：//www.rfc-editor .org / info / rfc6877>。
[RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, DOI 10.17487/RFC7335, August 2014, <http://www.rfc-editor.org/info/rfc7335>.
[RFC7335] Byrne、C。、「IPv4 Service Continuity Prefix」、RFC 7335、DOI 10.17487 / RFC7335、2014年8月、<http://www.rfc-editor.org/info/rfc7335>。
[RFC7755] Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments", RFC 7755, DOI 10.17487/RFC7755, February 2016, <http://www.rfc-editor.org/info/rfc7755>.
[RFC7755] Anderson、T。、「SIIT-DC：Stateless IP / ICMP Translation for IPv6 Data Center Environments」、RFC 7755、DOI 10.17487 / RFC7755、2016年2月、<http://www.rfc-editor.org/info / rfc7755>。
The following subsections describe some use cases that at the time of writing leverage SIIT with the EAM algorithm.
以下のサブセクションでは、執筆時点でEAMアルゴリズムを使用してSIITを活用するいくつかの使用例について説明します。
When the customer-side translator (CLAT) component in the 464XLAT [RFC6877] architecture does not have a dedicated IPv6 prefix assigned, it may instead use "one interface IPv6 address that is claimed by the CLAT." This IPv6 address might not be IPv4-translatable. If this is the case, the CLAT essentially implements the EAM algorithm using an EAMT as follows (assuming the CLAT's IPv4 address is picked from the IPv4 Service Continuity Prefix [RFC7335]):
464XLAT [RFC6877]アーキテクチャのカスタマーサイドトランスレータ（CLAT）コンポーネントに専用のIPv6プレフィックスが割り当てられていない場合、代わりに「CLATが要求する1つのインターフェースIPv6アドレス」を使用できます。このIPv6アドレスはIPv4で変換できない場合があります。この場合、CLATは基本的にEAMTを使用してEAMアルゴリズムを次のように実装します（CLATのIPv4アドレスがIPv4 Service Continuity Prefix [RFC7335]から選択されていると想定）。
+---+--------------+-------------------------------+
| # | IPv4 Prefix | IPv6 Prefix |
+---+--------------+-------------------------------+
| 1 | 192.0.0.1/32 | CLAT_claimed_IPv6_address/128 |
+---+--------------+-------------------------------+
Figure 4: Example EAMT for a 464XLAT CLAT
図4：464XLAT CLATのEAMTの例
In this particular use case, the EAM algorithm is used to translate IPv6 destination addresses to IPv4, and conversely, IPv4 source addresses to IPv6. Other addresses are translated using [RFC6052].
この特定の使用例では、EAMアルゴリズムを使用してIPv6宛先アドレスをIPv4に変換し、逆にIPv4送信元アドレスをIPv6に変換します。他のアドレスは[RFC6052]を使用して変換されます。
IVI [RFC6219] describes a stateless translation model that embeds IPv4 addresses in a 40-bit translation prefix where bits 33-40 are required to be 1. The embedded IPv4 address is located in bits 41-72 of the IPv6 address. Bits 73-128 are required to be 0.
IVI [RFC6219]は、ビット33〜40を1にする必要がある40ビット変換プレフィックスにIPv4アドレスを埋め込むステートレス変換モデルについて説明しています。埋め込まれたIPv4アドレスは、IPv6アドレスのビット41〜72にあります。ビット73〜128は0である必要があります。
The location of the eight least significant IPv4 address bits makes the IVI address mapping differ from [RFC6052].
8つの最下位IPv4アドレスビットの位置により、IVIアドレスマッピングが[RFC6052]と異なります。
+---+-------------+--------------------+
| # | IPv4 Prefix | IPv6 Prefix |
+---+-------------+--------------------+
| 1 | 0.0.0.0/0 | 2001:db8:ff00::/40 |
+---+-------------+--------------------+
Figure 5: Example EAMT for IVI
図5：IVIのEAMTの例
In this particular use case, all addresses are translated according to the EAM algorithm. In other words, [RFC6052] mapping is not used at all.
この特定の使用例では、すべてのアドレスがEAMアルゴリズムに従って変換されます。つまり、[RFC6052]マッピングはまったく使用されません。
SIIT-DC [RFC7755] describes the use of SIIT to facilitate connectivity from the IPv4 Internet to services hosted in an IPv6-only data center. In order to avoid the constraints relating to the use of IPv4-translatable IPv6 addresses discussed in Section 2, the stateless IPv4/IPv6 translators are provisioned with an EAMT containing one entry per IPv6-only service that are to be made available from the IPv4 Internet, for example (assuming 2001:db8:aaaa::1 and 2001:db8:bbbb::1 are assigned to load balancers or servers that provide the IPv6-only services in question):
SIIT-DC [RFC7755]は、IPv4インターネットからIPv6のみのデータセンターでホストされているサービスへの接続を容易にするためのSIITの使用について説明しています。セクション2で説明したIPv4変換可能なIPv6アドレスの使用に関する制約を回避するために、ステートレスIPv4 / IPv6トランスレーターは、IPv4インターネットから利用可能になるIPv6のみのサービスごとに1つのエントリを含むEAMTでプロビジョニングされます。たとえば、（2001：db8：aaaa :: 1および2001：db8：bbbb :: 1が問題のIPv6のみのサービスを提供するロードバランサーまたはサーバーに割り当てられていると想定）：
+---+----------------+----------------------+
| # | IPv4 Prefix | IPv6 Prefix |
+---+----------------+----------------------+
| 1 | 203.0.113.1/32 | 2001:db8:aaaa::1/128 |
| 2 | 203.0.113.2/32 | 2001:db8:bbbb::1/128 |
+---+----------------+----------------------+
Figure 6: Example EAMT for SIIT-DC
図6：SIIT-DCのEAMTの例
In this particular use case, the EAM algorithm is used to translate IPv4 destination addresses to IPv6, and conversely, IPv6 source addresses to IPv4. Other addresses are translated using [RFC6052].
この特定の使用例では、EAMアルゴリズムを使用してIPv4宛先アドレスをIPv6に変換し、逆にIPv6送信元アドレスをIPv4に変換します。他のアドレスは[RFC6052]を使用して変換されます。
Figure 7 demonstrates how a set of example IP addresses are translated given the example EAMT in Figure 1. Implementors may use the examples given to develop test cases to validate correct operation. Note that the address translations are bidirectional, so a single row in the table describes two address translations: IPv4 to IPv6 and IPv6 to IPv4.
図7は、図1のEAMTの例でIPアドレスのセットがどのように変換されるかを示しています。実装者は、示された例を使用してテストケースを開発し、正しい動作を検証できます。アドレス変換は双方向であるため、表の1つの行は2つのアドレス変換（IPv4からIPv6およびIPv6からIPv4）を示しています。
It is also assumed that the translation prefix is configured to be 64:ff9b::/96 (per [RFC6052]).
また、変換プレフィックスが64：ff9b :: / 96（[RFC6052]ごと）に構成されていることも前提としています。
+--------------+------------------------+-----------------------+
| IPv4 Address | IPv6 Address | Comment |
+--------------+------------------------+-----------------------+
| 192.0.2.1 | 2001:db8:aaaa:: | According to EAM #1 |
| 192.0.2.2 | 2001:db8:bbbb::b | According to EAM #2 |
| 192.0.2.16 | 2001:db8:cccc:: | According to EAM #3 |
| 192.0.2.24 | 2001:db8:cccc::8 | According to EAM #3 |
| 192.0.2.31 | 2001:db8:cccc::f | According to EAM #3 |
| 192.0.2.128 | 2001:db8:dddd:: | According to EAM #4 |
| 192.0.2.152 | 2001:db8:dddd:0:6000:: | According to EAM #4 |
| 192.0.2.183 | 2001:db8:dddd:0:dc00:: | According to EAM #4 |
| 192.0.2.191 | 2001:db8:dddd:0:fc00:: | According to EAM #4 |
| 192.0.2.195 | 2001:db8:eeee:9:8000:: | According to EAM #5 |
| 192.0.2.225 | 64:ff9b::1 | According to EAM #6 |
| 192.0.2.248 | 64:ff9b::c000:2f8 | According to RFC 6052 |
+--------------+------------------------+-----------------------+
Figure 7: Example IP Address Translations
図7：IPアドレス変換の例
The following examples show how hairpinned IPv6 packets between the IPv6 nodes 2001:db8:aaaa:: and 2001:db8:bbbb::b are translated according to Section 4. As in Appendix B, the EAMT in Figure 1 is used, and the translation prefix is 64:ff9b::/96 (per [RFC6052]). In addition, the [RFC6791] pool is assumed to contain only the single address 198.51.100.1.
次の例は、IPv6ノード2001：db8：aaaa ::と2001：db8：bbbb :: bの間のヘアピンされたIPv6パケットがセクション4に従ってどのように変換されるかを示しています。付録Bと同様に、図1のEAMTが使用され、翻訳プレフィックスは64：ff9b :: / 96です（[RFC6052]ごと）。さらに、[RFC6791]プールには、単一のアドレス198.51.100.1のみが含まれていると想定されています。
+--------------+--------------------+---------------------+
| XLAT Stage | Source Address | Destination Address |
+--------------+--------------------+---------------------+
| Initial | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 |
+--------------+--------------------+---------------------+
| Intermediate | 192.0.2.1 | 192.0.2.2 |
+--------------+--------------------+---------------------+
| Final | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b |
+--------------+--------------------+---------------------+
Figure 8: Hairpinning of a Normal IPv6 Packet
図8：通常のIPv6パケットのヘアピニング
Figure 8 illustrates how a normal (i.e., not an ICMP error) IPv6 packet sent from 2001:db8:aaaa:: towards 64:ff9b::192.0.2.2 is hairpinned. In this example, rule #1 in Section 4.2.1 was applied in order to disable the EAM algorithm when translating the intermediate IPv4 source address to IPv6.
図8は、2001：db8：aaaa ::から64：ff9b :: 192.0.2.2に向けて送信された通常の（つまり、ICMPエラーではない）IPv6パケットがどのようにヘアピンされるかを示しています。この例では、中間IPv4送信元アドレスをIPv6に変換するときにEAMアルゴリズムを無効にするために、セクション4.2.1のルール＃1が適用されました。
+--------------+-------+-----------------------+--------------------+
| XLAT Stage | Loc. | Source Address | Destination Addr. |
+--------------+-------+-----------------------+--------------------+
| Initial | Outer | 2001:db8::1234 | 64:ff9b::192.0.2.1 |
| | Inner | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b |
+--------------+-------+-----------------------+--------------------+
| Intermediate | Outer | 198.51.100.1 | 192.0.2.1 |
| | Inner | 192.0.2.1 | 192.0.2.2 |
+--------------+-------+-----------------------+--------------------+
| Final | Outer | 64:ff9b::198.51.100.1 | 2001:db8:aaaa:: |
| | Inner | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 |
+--------------+-------+-----------------------+--------------------+
Figure 9: Hairpinning of a Router-Originated ICMPv6 Error
図9：ルーターに起因するICMPv6エラーのヘアピニング
Figure 9 illustrates the hairpinning of an ICMPv6 error sent by an arbitrary IPv6 router (2001:db8::1234) in response to the packet in Figure 8. In this example, rule #2 in Section 4.2.1 was applied in order to disable the EAM algorithm when translating the intermediate inner IPv4 destination address to IPv6.
図9は、図8のパケットに応答して任意のIPv6ルーター（2001：db8 :: 1234）によって送信されたICMPv6エラーのヘアピニングを示しています。この例では、セクション4.2.1のルール＃2が無効にするために適用されました。中間の内部IPv4宛先アドレスをIPv6に変換するときのEAMアルゴリズム。
+--------------+-------+--------------------+--------------------+
| XLAT Stage | Loc. | Source Address | Destination Addr. |
+--------------+-------+--------------------+--------------------+
| Initial | Outer | 2001:db8:bbbb::b | 64:ff9b::192.0.2.1 |
| | Inner | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b |
+--------------+-------+--------------------+--------------------+
| Intermediate | Outer | 192.0.2.2 | 192.0.2.1 |
| | Inner | 192.0.2.1 | 192.0.2.2 |
+--------------+-------+--------------------+--------------------+
| Final | Outer | 64:ff9b::192.0.2.2 | 2001:db8:aaaa:: |
| | Inner | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 |
+--------------+-------+--------------------+--------------------+
Figure 10: Hairpinning of a Host-Originated ICMPv6 Error
図10：ホストから発信されたICMPv6エラーのヘアピニング
Figure 10 illustrates the hairpinning of an ICMPv6 error sent by the original destination host itself in response to the packet in Figure 8. In this example, rules #2 and #3 in Section 4.2.1 were both applied in order to disable the EAM algorithm when translating the intermediate inner IPv4 destination address and the intermediate outer IPv4 source address to IPv6.
図10は、図8のパケットに応答して、元の宛先ホスト自体によって送信されたICMPv6エラーのヘアピニングを示しています。この例では、EAMアルゴリズムを無効にするために、セクション4.2.1のルール＃2と＃3の両方が適用されました中間の内部IPv4宛先アドレスと中間の外部IPv4送信元アドレスをIPv6に変換するとき。
+--------------+--------------------+---------------------+
| XLAT Stage | Source Address | Destination Address |
+--------------+--------------------+---------------------+
| Initial | 2001:db8:bbbb::b | 64:ff9b::192.0.2.1 |
+--------------+--------------------+---------------------+
| Intermediate | 192.0.2.2 | 192.0.2.1 |
+--------------+--------------------+---------------------+
| Final | 64:ff9b::192.0.2.2 | 2001:db8:aaaa:: |
+--------------+--------------------+---------------------+
Figure 11: Hairpinning of Normal Response Packet
図11：通常応答パケットのヘアピニング
Figure 11 illustrates how the response from 2001:db8:bbbb::b to the packet in Figure 8 is hairpinned in the exact same fashion as the initial packet. Again, rule #1 in Section 4.2.1 was applied in order to disable the EAM algorithm when translating the intermediate IPv4 source address to IPv6. The example is included in order to illustrate how the addresses in the packet initially sent by 2001:db8:aaaa:: match those in the translated response packet sent by 2001:db8:bbbb::b, thus facilitating bidirectional communication.
図11は、図8のパケットに対する2001：db8：bbbb :: bからの応答が、最初のパケットとまったく同じ方法でヘアピンされる方法を示しています。ここでも、中間IPv4送信元アドレスをIPv6に変換するときにEAMアルゴリズムを無効にするために、セクション4.2.1のルール＃1が適用されました。この例は、2001：db8：aaaa ::によって最初に送信されたパケットのアドレスが2001：db8：bbbb :: bによって送信された変換済み応答パケットのアドレスとどのように一致するかを示すために含まれているため、双方向通信が容易になります。
Acknowledgements
謝辞
This document was conceived due to comments made by Dave Thaler in the V6OPS session at IETF 91 as well as email discussions between Fred Baker and the authors.
この文書は、IETF 91のV6OPSセッションでDave Thalerが行ったコメントと、Fred Bakerと著者間の電子メールの議論により考案されました。
Valuable reviews, suggestions, and other feedback was given by Fred Baker, Mohamed Boucadair, Cameron Byrne, Brian E. Carpenter, Brian Haberman, Ray Hunter, Alvaro Retana, Michael Richardson, Dan Romascanu, Hemant Singh, and Andrew Yourtchenko.
貴重なレビュー、提案、その他のフィードバックは、フレッドベイカー、モハメドブーカデア、キャメロンバーン、ブライアンE.カーペンター、ブライアンハーバーマン、レイハンター、アルバロレタナ、マイケルリチャードソン、ダンローマスカヌ、ヘマントシン、アンドリューユアチェンコから寄せられました。
Authors' Addresses
著者のアドレス
Tore Anderson Redpill Linpro Vitaminveien 1A 0485 Oslo Norway
Tore Anderson Redpill Linpro Vitaminveien 1A 0485 Oslo Norway
Phone: +47 959 31 212
Email: tore@redpill-linpro.com
URI: http://www.redpill-linpro.com
Alberto Leiva Popper NIC Mexico Av. Eugenio Garza Sada 427 L4-6 Monterrey, Nuevo Leon 64840 Mexico
Alberto Leiva Popper NICメキシコAv。Eugenio Garza Sada 427 L4-6 Monterrey、Nuevo Leon 64840メキシコ
Email: ydahhrk@gmail.com
URI: http://www.nicmexico.mx/