[要約] RFC 7756は、IPv6インターネットデータセンター環境での状態を持たないIP/ICMP変換（SIIT-DC）のデュアル変換モードに関するものです。このRFCの目的は、IPv6とIPv4の相互運用性を向上させるために、デュアルスタック環境でのトラフィック変換を提供することです。
Internet Engineering Task Force (IETF) T. Anderson
Request for Comments: 7756 Redpill Linpro
Category: Informational S. Steffann
ISSN: 2070-1721 S.J.M. Steffann Consultancy
February 2016
Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode
IPv6インターネットデータセンター環境用のステートレスIP / ICMP変換（SIIT-DC）：デュアル変換モード
Abstract
概要
This document describes an extension of the Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC) architecture, which allows applications, protocols, or nodes that are incompatible with IPv6 and/or Network Address Translation to operate correctly with SIIT-DC. This is accomplished by introducing a new component called an SIIT-DC Edge Relay, which reverses the translations made by an SIIT-DC Border Relay. The application and/or node is thus provided with seemingly native IPv4 connectivity that provides end-to-end address transparency.
このドキュメントでは、IPv6インターネットネットワーク変換（SIIT-DC）アーキテクチャのステートレスIP / ICMP変換の拡張について説明します。これにより、IPv6と互換性のないアプリケーション、プロトコル、またはノードがSIIT- DC。これは、SIIT-DCボーダーリレーによって行われた変換を逆にするSIIT-DCエッジリレーと呼ばれる新しいコンポーネントを導入することによって実現されます。したがって、アプリケーションまたはノード、あるいはその両方には、エンドツーエンドのアドレス透過性を提供する一見ネイティブのIPv4接続が提供されます。
The reader is expected to be familiar with the SIIT-DC architecture described in RFC 7755.
読者は、RFC 7755で説明されているSIIT-DCアーキテクチャに精通していることが求められます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc7756.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7756で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Edge Relay Description . . . . . . . . . . . . . . . . . . . 5
3.1. Node-Based Edge Relay . . . . . . . . . . . . . . . . . . 6
3.2. Network-Based Edge Relay . . . . . . . . . . . . . . . . 7
3.2.1. Edge Relay "on a Stick" . . . . . . . . . . . . . . . 8
3.2.2. Edge Relay That Bridges IPv6 Packets . . . . . . . . 9
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 9
4.1. IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . . 9
4.2. IPv4 MTU . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. IPv4 Identification Header . . . . . . . . . . . . . . . 10
5. Intra-IDC IPv4 Communication . . . . . . . . . . . . . . . . 10
5.1. Hairpinning by the SIIT-DC Border Relay . . . . . . . . . 11
5.2. Additional EAMs Configured in Edge Relay . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Examples: Network-Based IPv4 Connectivity . . . . . 16
A.1. Subnet with IPv4 Service Addresses . . . . . . . . . . . 16
A.2. Subnet with Unrouted IPv4 Addresses . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
SIIT-DC [RFC7755] describes an architecture where IPv4-only users can access IPv6-only services through a stateless translator called an SIIT-DC Border Relay (BR). This approach has certain limitations, however. In particular, the following cases will work poorly or not at all:
SIIT-DC [RFC7755]は、IPv4のみのユーザーが、SIIT-DCボーダーリレー（BR）と呼ばれるステートレストランスレータを介してIPv6のみのサービスにアクセスできるアーキテクチャについて説明しています。ただし、このアプローチには一定の制限があります。特に、次の場合はうまく機能しないか、まったく機能しません。
o Application protocols that do not support NAT (i.e., the lack of end-to-end transparency of IP addresses).
o NATをサポートしないアプリケーションプロトコル（つまり、IPアドレスのエンドツーエンドの透過性の欠如）。
o Nodes that cannot connect to IPv6 networks at all or that can only connect such networks if they also provide IPv4 connectivity (i.e., dual-stacked networks).
o IPv6ネットワークにまったく接続できないノード、またはIPv4接続も提供する場合にのみそのようなネットワークに接続できるノード（つまり、デュアルスタックネットワーク）。
o Application software that makes use of legacy IPv4-only APIs or otherwise makes assumptions that IPv4 connectivity is available.
o レガシーIPv4のみのAPIを利用するか、IPv4接続が利用可能であると想定するアプリケーションソフトウェア。
By extending the SIIT-DC architecture with a new component called an Edge Relay (ER), all of the above can be made to work correctly in an otherwise IPv6-only network environment using SIIT-DC.
エッジリレー（ER）と呼ばれる新しいコンポーネントでSIIT-DCアーキテクチャを拡張することにより、SIIT-DCを使用して、IPv6のみのネットワーク環境で上記のすべてを正しく機能させることができます。
The purpose of the ER is to reverse the IPv4-to-IPv6 packet translations previously done by the BR for traffic arriving from IPv4 clients and forward this as "native" IPv4 to the node or application. In the reverse direction, IPv4 packets transmitted by the node or application are intercepted by the ER, which translates them to IPv6 before they are forwarded to the BR, which in turn will reverse the translations and forward them to the IPv4 client. The node or application is thus provided with "virtual" IPv4 Internet connectivity that retains end-to-end transparency for the IPv4 addresses.
ERの目的は、BRによってIPv4クライアントから到着するトラフィックに対して以前に行われたIPv4-to-IPv6パケット変換を逆にし、これを「ネイティブ」IPv4としてノードまたはアプリケーションに転送することです。逆方向では、ノードまたはアプリケーションによって送信されたIPv4パケットがERによってインターセプトされ、BRに転送される前にERによってIPv6に変換されます。これにより、BRに転送され、逆に変換されてIPv4クライアントに転送されます。したがって、ノードまたはアプリケーションには、IPv4アドレスのエンドツーエンドの透過性を保持する「仮想」IPv4インターネット接続が提供されます。
This document makes use of the following terms:
このドキュメントでは、次の用語を使用しています。
SIIT-DC Border Relay (BR): A device or a logical function that performs stateless protocol translation between IPv4 and IPv6. It MUST do so in accordance with [RFC6145] and [RFC7757].
SIIT-DCボーダーリレー（BR）：IPv4とIPv6の間でステートレスプロトコル変換を実行するデバイスまたは論理機能。それは[RFC6145]と[RFC7757]に従ってそうしなければなりません。
SIIT-DC Edge Relay (ER): A device or logical function that provides "native" IPv4 connectivity to IPv4-only devices or application software. It is very similar in function to a BR but is typically located close to the IPv4-only component(s) it is supporting rather than on the outer network border of the Internet Data Center (IDC). An ER may be either node based (Section 3.1) or network based (Section 3.2).
SIIT-DCエッジリレー（ER）：IPv4専用デバイスまたはアプリケーションソフトウェアへの「ネイティブ」IPv4接続を提供するデバイスまたは論理機能。機能はBRと非常に似ていますが、通常は、インターネットデータセンター（IDC）の外部ネットワーク境界ではなく、サポートしているIPv4のみのコンポーネントの近くにあります。 ERはノードベース（セクション3.1）またはネットワークベース（セクション3.2）のいずれかです。
IPv4 Service Address: An IPv4 address representing a node or service located in an IPv6 network. It is coupled with an IPv6 Service Address using an Explicit Address Mapping (EAM). Packets sent to this address are translated to IPv6 by the BR, and possibly back to IPv4 by an ER, before reaching the node or service.
IPv4サービスアドレス：IPv6ネットワークにあるノードまたはサービスを表すIPv4アドレス。明示的アドレスマッピング（EAM）を使用してIPv6サービスアドレスと結合されます。このアドレスに送信されたパケットは、ノードまたはサービスに到達する前に、BRによってIPv6に変換され、ERによってIPv4に戻される可能性があります。
IPv6 Service Address: An IPv6 address assigned to an application, node, or service either directly or indirectly (through an ER). It is coupled with an IPv4 Service Address using an EAM. IPv4-only clients communicate with the IPv6 Service Address through SIIT-DC.
IPv6サービスアドレス：アプリケーション、ノード、またはサービスに直接または（ERを介して）間接的に割り当てられたIPv6アドレス。 EAMを使用してIPv4サービスアドレスと結合されます。 IPv4のみのクライアントは、SIIT-DCを介してIPv6サービスアドレスと通信します。
Explicit Address Mapping (EAM): A bidirectional coupling between an IPv4 Service Address and an IPv6 Service Address configured in a BR or ER. When translating between IPv4 and IPv6, the BR/ER changes the address fields in the translated packet's IP header according to any matching EAM. The EAM algorithm is specified in [RFC7757].
明示アドレスマッピング（EAM）：BRまたはERで構成されたIPv4サービスアドレスとIPv6サービスアドレス間の双方向結合。 IPv4とIPv6の間で変換する場合、BR / ERは、一致するEAMに従って、変換されたパケットのIPヘッダーのアドレスフィールドを変更します。 EAMアルゴリズムは[RFC7757]で指定されています。
Translation Prefix: An IPv6 prefix into which the entire IPv4 address space is mapped, according to the algorithm in [RFC6052]. The translation prefix is routed to the BR's IPv6 interface. When translating between IPv4 and IPv6, a BR/ER will insert/remove the translation prefix into/from the address fields in the translated packet's IP header, unless an EAM exists for the IP address that is being translated.
変換プレフィックス：[RFC6052]のアルゴリズムに従って、IPv4アドレス空間全体がマップされるIPv6プレフィックス。変換プレフィックスは、BRのIPv6インターフェイスにルーティングされます。 IPv4とIPv6の間で変換する場合、BR / ERは、変換されるIPアドレスにEAMが存在しない限り、変換されたパケットのIPヘッダーのアドレスフィールドに変換プレフィックスを挿入/削除します。
IPv4-Converted IPv6 Addresses: As defined in Section 1.3 of [RFC6052].
IPv4-Converted IPv6 Addresses：[RFC6052]のセクション1.3で定義されています。
IDC: Short for "Internet Data Center"; a data center whose main purpose is to deliver services to the public Internet. SIIT-DC is primarily targeted at being deployed in an IDC. An IDC is typically operated by an Internet Content Provider or a Managed Services Provider.
IDC：「インターネットデータセンター」の略。公共のインターネットにサービスを提供することを主な目的とするデータセンター。 SIIT-DCは、主にIDCでの展開を対象としています。 IDCは通常、インターネットコンテンツプロバイダーまたはマネージドサービスプロバイダーによって運営されています。
SIIT: The Stateless IP/ICMP Translation Algorithm, as specified in [RFC6145].
SIIT：[RFC6145]で指定されているステートレスIP / ICMP変換アルゴリズム。
XLAT: Short for "Translation". Used in figures to indicate where a BR/ ER uses SIIT [RFC6145] to translate IPv4 packets to IPv6 and vice versa.
XLAT：「Translation」の略。図で使用され、BR / ERがSIIT [RFC6145]を使用して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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
An ER is at its core an implementation of the Stateless IP/ICMP Translation Algorithm [RFC6145] that supports Explicit Address Mappings [RFC7757]. It provides virtual IPv4 connectivity for nodes or applications that require this to operate correctly with SIIT-DC.
ERは、中核として、明示的なアドレスマッピング[RFC7757]をサポートするステートレスIP / ICMP変換アルゴリズム[RFC6145]の実装です。これは、SIIT-DCで正しく動作するためにこれを必要とするノードまたはアプリケーションに仮想IPv4接続を提供します。
Packets from the IPv4 Internet destined for an IPv4 Service Address are first translated to IPv6 by a BR. The resulting IPv6 packets are subsequently forwarded to the ER that owns the IPv6 Service Address the translated packets are addressed to. The ER then translates them back to IPv4 before forwarding them to the IPv4 application or node. In the other direction, the exact same translations happen, only in reverse. This process provides end-to-end transparency of IPv4 addresses.
IPv4サービスアドレス宛てのIPv4インターネットからのパケットは、最初にBRによってIPv6に変換されます。結果のIPv6パケットは、その後、変換されたパケットの宛先であるIPv6サービスアドレスを所有するERに転送されます。次に、ERはそれらをIPv4に変換してから、IPv4アプリケーションまたはノードに転送します。反対方向では、まったく同じ変換が逆方向にのみ行われます。このプロセスは、IPv4アドレスのエンドツーエンドの透過性を提供します。
An ER may handle an arbitrary number of IPv4/IPv6 Service Addresses. All the EAMs configured in the BR that involve the IPv4/IPv6 Service Addresses handled by an ER MUST also be present in the ER's configuration.
ERは、任意の数のIPv4 / IPv6サービスアドレスを処理できます。 ERによって処理されるIPv4 / IPv6サービスアドレスを含む、BRで構成されたすべてのEAMも、ERの構成に存在する必要があります。
An ER may be implemented in two distinct ways: as a software-based service residing inside an otherwise IPv6-only node or as a network-based service that provides an isolated IPv4 network segment to which nodes that require IPv4 can connect. In both cases, native IPv6 connectivity may be provided simultaneously with the virtual IPv4 connectivity. Thus, dual-stack connectivity is facilitated in case the node or application supports it.
ERは2つの異なる方法で実装できます。それ以外の場合はIPv6のみのノード内にあるソフトウェアベースのサービスとして、またはIPv4を必要とするノードが接続できる分離されたIPv4ネットワークセグメントを提供するネットワークベースのサービスとして。どちらの場合も、ネイティブIPv6接続は、仮想IPv4接続と同時に提供されます。したがって、ノードまたはアプリケーションでサポートされている場合、デュアルスタック接続が容易になります。
The choice between a node- or network-based ER is made on a per-service or per-node basis. An arbitrary number of each type of ER may co-exist in an SIIT-DC architecture.
ノードベースまたはネットワークベースのERの選択は、サービスごとまたはノードごとに行われます。 SIIT-DCアーキテクチャでは、ERの各タイプの任意の数が共存できます。
This section describes the different approaches and discusses which approach fits best for the various use cases.
このセクションでは、さまざまなアプローチについて説明し、さまざまなユースケースに最適なアプローチについて説明します。
[IPv4 Internet] [IPv6 Internet]
| |
+-----|-----+ |
| (BR/XLAT) | |
+-----|-----+ |
| | +-----<IPv6-only node/server>----------+
[IPv6-only IDC network] | +----------------+|
| | /--(ER/XLAT)--AF_INET Dual-stack ||
\-------------------------+ | application ||
| \------------AF_INET6 software ||
| +----------------+|
+--------------------------------------+
Figure 1: A Node-Based Edge Relay
図1：ノードベースのエッジリレー
A node-based ER is typically implemented as a logical software function that runs inside the operating system of an IPv6 node. It provides applications running on the same node with IPv4 connectivity. Its IPv4 Service Address SHOULD be considered a regular local address that allows applications running on the same node to use it with IPv4-only API calls, e.g., to create AF_INET sockets that listen for and accept incoming connections to its IPv4 Service Address. An ER may accomplish this by creating a virtual network adapter to which it assigns the IPv4 Service Address and points a default IPv4 route. This approach is similar to the "Bump-in-the-Stack" approach discussed in [RFC6535]; however, it does not include an Extension Name Resolver.
ノードベースのERは通常、IPv6ノードのオペレーティングシステム内で実行される論理ソフトウェア機能として実装されます。同じノードで実行されるアプリケーションにIPv4接続を提供します。そのIPv4サービスアドレスは、同じノード上で実行されているアプリケーションがIPv4のみのAPI呼び出しでそれを使用できるようにする通常のローカルアドレスと見なされるべきです（SHOULD）。 ERは、IPv4サービスアドレスを割り当て、デフォルトのIPv4ルートをポイントする仮想ネットワークアダプターを作成することで、これを実現できます。このアプローチは、[RFC6535]で説明されている「Bump-in-the-Stack」アプローチに似ています。ただし、Extension Name Resolverは含まれていません。
As shown in Figure 1, if the application supports dual-stack operation, IPv6 clients will be able to communicate with it directly using native IPv6. Neither the BR nor the ER will intercept this communication. Support for IPv6 in the application is, however, not a requirement; the application may opt not to establish any IPv6 sockets. Foregoing IPv6 in this manner will simply preclude connectivity to the service from IPv6-only clients; connectivity to the service from IPv4 clients (through the BR) will continue work in the same way.
図1に示すように、アプリケーションがデュアルスタック操作をサポートしている場合、IPv6クライアントはネイティブIPv6を使用して直接アプリケーションと通信できます。 BRもERもこの通信を傍受しません。ただし、アプリケーションでのIPv6のサポートは必須ではありません。アプリケーションは、IPv6ソケットを確立しないことを選択できます。この方法でIPv6を回避すると、IPv6のみのクライアントからサービスへの接続が拒否されます。 IPv4クライアントから（BRを介して）サービスへの接続は、引き続き同じように機能します。
The ER requires a dedicated IPv6 Service Address for each IPv4 Service Address it has configured. The IPv6 network MUST forward traffic to these IPv6 Service Addresses to the node, whose operating system MUST in turn forward them to the ER. This document does not attempt to fully explore the multitude of ways this could be accomplished; however, considering that the IPv6 protocol is designed for having multiple addresses assigned to a single node, one particularly straight-forward way would be to assign the ER's IPv6 Service Addresses as secondary IPv6 addresses on the node itself so that the upstream router learns of their location using the IPv6 Neighbor Discovery Protocol [RFC4861].
ERでは、ERが構成したIPv4サービスアドレスごとに専用のIPv6サービスアドレスが必要です。 IPv6ネットワークは、これらのIPv6サービスアドレスへのトラフィックをノードに転送する必要があります。そのオペレーティングシステムは、それらをERに転送する必要があります。このドキュメントでは、これを実現するさまざまな方法を完全に探求することは試みていません。ただし、IPv6プロトコルが単一のノードに割り当てられた複数のアドレスを持つように設計されていることを考えると、1つの特に簡単な方法は、ERのIPv6サービスアドレスをノード自体のセカンダリIPv6アドレスとして割り当て、上流のルーターがIPv6近隣探索プロトコル[RFC4861]を使用した場所。
[IPv4 Internet] [IPv6 Internet]
| |
+-----|-----+ |
| (BR/XLAT) | |
+-----|-----+ |
| |
[IPv6-only IDC network] +--<IPv4-only node/server>--+
| | +----------------+|
+-----|-----+ [v4-only] | | IPv4-only ||
| (ER/XLAT)-----[network]--------AF_INET application ||
+-----------+ [segment] | | software ||
| +----------------+|
+---------------------------+
Figure 2: A Basic Network-Based Edge Relay
図2：基本的なネットワークベースのエッジリレー
A network-based ER functions the exact same way as a node-based ER does, only that instead of assigning the IPv4 Service Addresses to an internal-only virtual network adapter, traffic destined for them are forwarded onto a network segment to which nodes that require IPv4 connectivity connect to. The ER also functions as the default IPv4 router for the nodes on this network segment.
ネットワークベースのERは、ノードベースのERとまったく同じように機能します。IPv4サービスアドレスを内部専用の仮想ネットワークアダプターに割り当てる代わりに、それらを宛先とするトラフィックが、ノードが接続するネットワークセグメントに転送されます。 IPv4接続が必要です。 ERは、このネットワークセグメント上のノードのデフォルトIPv4ルーターとしても機能します。
Each node on the IPv4 network segment MUST acquire and assign an IPv4 Service Address to a local network interface. While this document does not attempt to explore all the various methods by which this could be accomplished, some examples are provided in Appendix A.
IPv4ネットワークセグメント上の各ノードは、IPv4サービスアドレスを取得してローカルネットワークインターフェイスに割り当てる必要があります。このドキュメントでは、これを実現するためのさまざまな方法をすべて探求することはしませんが、いくつかの例を付録Aに示します。
The basic ER illustrated in Figure 2 establishes an IPv4-only network segment between itself and the IPv4-only nodes it serves. This is fine if the nodes it provides IPv4 access to have no support for IPv6 whatsoever; however, if they are dual-stack capable, it would not be ideal to take away their IPv6 connectivity in this manner. While it is RECOMMENDED to use a node-based ER in this case, appropriate implementations of a node-based ER might not be available for every node. If the application protocol in question does not work correctly in a NAT environment, standard SIIT-DC cannot be used either, which leaves a network-based ER as the only remaining solution. The following subsections contain examples on how the ER could be implemented in a way that provides IPv6 connectivity for dual-stack capable nodes.
図2に示されている基本的なERは、自身とそれがサービスを提供するIPv4専用ノードとの間にIPv4専用ネットワークセグメントを確立します。 IPv4アクセスを提供するノードがIPv6をまったくサポートしない場合、これは問題ありません。ただし、それらがデュアルスタック対応である場合、この方法でIPv6接続を削除することは理想的ではありません。この場合、ノードベースのERを使用することをお勧めしますが、ノードベースのERの適切な実装がすべてのノードで利用できるとは限りません。問題のアプリケーションプロトコルがNAT環境で正しく機能しない場合、標準のSIIT-DCも使用できず、ネットワークベースのERが唯一の残りのソリューションとして残ります。次のサブセクションには、デュアルスタック対応ノードにIPv6接続を提供する方法でERを実装する方法の例が含まれています。
[IPv4 Internet] [IPv6 Internet]
| |
+-----|-----+ |
| (BR/XLAT) | |
+-----|-----+ |
| |
[IPv6-only IDC network]
|
| +-------------+
| | _IPv6_ |
| | / \ |
+==== (ER/XLAT) |
| | \_ _/ |
| | IPv4 | +--<Dual-stack node/server>--+
| +-------------+ | +----------------+|
| | /---AF_INET Dual-stack ||
[Dual-stack network segment]----< | application ||
| \--AF_INET6 software ||
| +----------------+|
+----------------------------+
Figure 3: A Network-Based Edge Relay "on a Stick"
図3：「スティック上の」ネットワークベースのエッジリレー
The ER "on a stick" approach illustrated in Figure 3 ensures that the dual-stack capable node retains native IPv6 connectivity by connecting the ER's IPv4 and IPv6 interfaces to the same network segment, alternatively by using a single dual-stacked interface. Native IPv6 traffic between the IDC network and the node bypasses the ER entirely, while IPv4 traffic from the node will be routed directly to the ER (because it acts as its default IPv4 router), where it is translated to IPv6 before being transmitted to the upstream default IPv6 router. The ER could attract inbound traffic to the IPv6 Service Addresses by responding to the upstream router's IPv6 Neighbor Discovery [RFC4861] messages for them.
図3に示すERの「オンスティック」アプローチでは、ERのIPv4およびIPv6インターフェイスを同じネットワークセグメントに接続するか、単一のデュアルスタックインターフェイスを使用することで、デュアルスタック対応ノードがネイティブIPv6接続を確実に保持します。 IDCネットワークとノード間のネイティブIPv6トラフィックはERを完全にバイパスしますが、ノードからのIPv4トラフィックはERに直接ルーティングされます（デフォルトのIPv4ルーターとして機能するため）。そこで、IPv6に変換されてから、アップストリームのデフォルトIPv6ルーター。 ERは、上流のルーターのIPv6近隣探索[RFC4861]メッセージに応答することにより、受信トラフィックをIPv6サービスアドレスに引き寄せることができます。
[IPv4 Internet] [IPv6 Internet]
| |
+-----|-----+ |
| (BR/XLAT) | |
+-----|-----+ |
| |
[IPv6-only IDC network]
|
+-----------|--------------+
| ____/ \_IPv6_ |
| / \ |
| (IPv6 Bridge) (ER/XLAT) |
| \____ _ _/ |
| \ / IPv4 | +--<Dual-stack node/server>--+
+-----------|--------------+ | +----------------+|
| | /---AF_INET Dual-stack ||
[Dual-stack network segment]----< | application ||
| \--AF_INET6 software ||
| +----------------+|
+----------------------------+
Figure 4: A Network-Based Edge Relay Containing an IPv6 Bridge
図4：IPv6ブリッジを含むネットワークベースのエッジリレー
The ER illustrated in Figure 4 will transparently bridge IPv6 frames between its upstream and downstream interfaces. IPv6 packets sent from the upstream IDC network to an IPv6 Service Address are intercepted by the ER (e.g., by responding to IPv6 Neighbor Discovery [RFC4861] messages for them) and routed through the translation function before being forwarded out the ER's downstream interface as IPv4 packets. The downstream network segment thus becomes dual stacked.
図4に示されているERは、アップストリームインターフェイスとダウンストリームインターフェイスの間でIPv6フレームを透過的にブリッジします。アップストリームIDCネットワークからIPv6サービスアドレスに送信されたIPv6パケットはERによって傍受され（たとえば、IPv6ネイバー探索[RFC4861]メッセージに応答することにより）、変換機能を通じてルーティングされてから、ERのダウンストリームインターフェイスからIPv4として転送されます。パケット。したがって、ダウンストリームネットワークセグメントはデュアルスタックになります。
The IPv6 Path MTU between the ER and the BR will typically be larger than the default value defined in Section 4 of [RFC6145] (1280 bytes), as it will typically be contained within a single administrative domain. Therefore, it is RECOMMENDED that the IPv6 Path MTU configured in the ER be raised accordingly. It is RECOMMENDED that the ER and the BR use identical configured IPv6 Path MTU values.
ERとBRの間のIPv6パスMTUは、通常、単一の管理ドメイン内に含まれるため、[RFC6145]のセクション4で定義されているデフォルト値（1280バイト）よりも大きくなります。したがって、ERで構成されたIPv6パスMTUをそれに応じて上げることをお勧めします。 ERとBRが同一の構成済みIPv6パスMTU値を使用することをお勧めします。
In order to avoid IPv6 fragmentation, an ER SHOULD ensure that the IPv4 MTU used by applications or nodes is equal to the configured IPv6 Path MTU - 20 so that a maximum-sized IPv4 packet can fit in an unfragmented IPv6 packet. This ensures that the application may do its part in avoiding IP-level fragmentation from occurring, e.g., by segmenting/fragmenting outbound packets at the application layer, and advertising the maximum size its peer may use for inbound packets (e.g., through the use of the TCP Maximum Segment Size (MSS) option).
IPv6の断片化を回避するために、ERは、最大サイズのIPv4パケットが断片化されていないIPv6パケットに収まるように、アプリケーションまたはノードで使用されるIPv4 MTUが構成済みのIPv6パスMTU-20と等しいことを確認する必要があります。これにより、アプリケーションは、たとえば、アプリケーション層で送信パケットをセグメント化/フラグメント化し、ピアが受信パケットに使用できる最大サイズをアドバタイズすることによって（たとえば、 TCP最大セグメントサイズ（MSS）オプション）。
A node-based ER could accomplish this by configuring this MTU value on the virtual network adapter, while a network-based ER could do so by advertising the MTU to its downstream nodes using the DHCPv4 Interface MTU option [RFC2132].
ノードベースのERは、仮想ネットワークアダプターでこのMTU値を構成することでこれを実現できますが、ネットワークベースのERは、DHCPv4インターフェイスMTUオプション[RFC2132]を使用してMTUをそのダウンストリームノードにアドバタイズすることで実現できます。
If the generation of IPv6 Atomic Fragments is disabled, the value of the IPv4 Identification header will be lost during the translation. Conversely, enabling the generation of IPv6 Atomic Fragments will ensure that the IPv4 Identification header will be carried end to end. Note that for this to work bidirectionally, IPv6 Atomic Fragment generation MUST be enabled on both the BR and the ER.
IPv6 Atomic Fragmentsの生成が無効になっている場合、IPv4識別ヘッダーの値は変換中に失われます。逆に、IPv6 Atomic Fragmentsの生成を有効にすると、IPv4 Identificationヘッダーがエンドツーエンドで確実に送信されます。これが双方向で機能するためには、BRとERの両方でIPv6 Atomic Fragment生成を有効にする必要があることに注意してください。
Apart from certain diagnostic tools, there are few (if any) application protocols that make use of the IPv4 Identification header. Therefore, the loss of the IPv4 Identification value will generally not cause any problems.
特定の診断ツールを除いて、IPv4識別ヘッダーを利用するアプリケーションプロトコルは（もしあれば）いくつかあります。したがって、IPv4識別値が失われても問題は発生しません。
IPv6 Atomic Fragments and their impact on the IPv4 Identification header is further discussed in Section 4.9.2 of [RFC7755].
IPv6 Atomic FragmentsとIPv4 Identificationヘッダーへの影響については、[RFC7755]のセクション4.9.2で詳しく説明しています。
Although SIIT-DC is primarily intended to facilitate communication between IPv4-only nodes on the Internet and services located in an IPv6-only IDC network, an IPv4-only node or application located behind an ER might need to communicate with other nodes or services in the IDC. The IPv4-only node or application will need to go through the ER, as it will typically be incapable of contacting IPv6 destinations directly. The following subsections discuss various methods on how to facilitate such communication.
SIIT-DCは主に、インターネット上のIPv4専用ノードとIPv6専用IDCネットワークにあるサービス間の通信を容易にすることを目的としていますが、ERの背後にあるIPv4専用ノードまたはアプリケーションは、他のノードまたはサービスと通信する必要がある場合があります。 IDC。 IPv4のみのノードまたはアプリケーションは、通常IPv6宛先に直接接続できないため、ERを通過する必要があります。以下のサブセクションでは、そのようなコミュニケーションを促進する方法に関するさまざまな方法について説明します。
If the BR supports hairpinning as described in Section 4.2 of [RFC7757], the easiest solution is to make the target service available through SIIT-DC in the normal way; that is, by provisioning an EAM to the BR that assigns an IPv4 Service Address with the target service's IPv6 Service Address.
[RFC7757]のセクション4.2で説明されているように、BRがヘアピニングをサポートしている場合、最も簡単な解決策は、SIIT-DCを通じて通常の方法でターゲットサービスを利用できるようにすることです。つまり、EAMをBRにプロビジョニングして、IPv4サービスアドレスをターゲットサービスのIPv6サービスアドレスに割り当てます。
This allows the IPv4-only node or application to transmit packets destined for the target service's IPv4 Service Address, which the ER will then translate to a corresponding IPv4-converted IPv6 address by inserting the translation prefix [RFC6052]. When this IPv6 packet reaches the BR, it will be hairpinned and transmitted back to the target service's IPv6 Service Address (where it could possibly pass through another ER before reaching the target service). Return traffic from the target service will be hairpinned in the same fashion.
これにより、IPv4専用ノードまたはアプリケーションは、ターゲットサービスのIPv4サービスアドレス宛てのパケットを送信できます。ERは、変換プレフィックス[RFC6052]を挿入することにより、対応するIPv4変換IPv6アドレスに変換します。このIPv6パケットがBRに到達すると、ヘアピンされてターゲットサービスのIPv6サービスアドレスに送信されます（ターゲットサービスに到達する前に別のERを通過する可能性があります）。ターゲットサービスからのリターントラフィックは、同じ方法でヘアピンされます。
+-[Pkt#1: IPv4]-+ +--[Pkt#2: IPv6]-------------+
| SRC 192.0.2.1 | (XLAT#1) | SRC 2001:db8:a:: |
| DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:46::192.0.2.2 |---\
+---------------+ +----------------------------+ |
(XLAT#2)
+-[Pkt#4: IPv4]-+ +--[Pkt#3: IPv6]-------------+ ( @ BR )
| SRC 192.0.2.1 | (XLAT#3) | SRC 2001:db8:46::192.0.2.1 | |
| DST 192.0.2.2 |<--(@ ER B)--| DST 2001:db8:b:: |<--/
+---------------+ +----------------------------+
Figure 5: Hairpinned IPv4-IPv4 Packet Flow
図5：ヘアピンされたIPv4-IPv4パケットフロー
Figure 5 illustrates the flow of a hairpinned packet sent from the IPv4-only node/app behind ER A towards an IPv6-only node/app behind ER B. ER A is configured with the EAM {192.0.2.1,2001:db8:a::} and ER B with {192.0.2.2,2001:db8:b::}. The BR is configured with both EAMs and supports hairpinning. Note that if the target service had not been located behind an ER, the third and final translation (XLAT#3) would not have happened, i.e., the target service/node would have received and responded to packet #3 directly.
図5は、ER Aの背後にあるIPv4のみのノード/アプリからER Bの背後にあるIPv6のみのノード/アプリに向けて送信されたヘアピンパケットのフローを示しています。ERAはEAM {192.0.2.1,2001：db8：aで構成されています。 ::}およびER Bと{192.0.2.2,2001：db8：b ::}。 BRは両方のEAMで構成され、ヘアピニングをサポートします。ターゲットサービスがERの背後に配置されていなかった場合、3番目および最後の変換（XLAT＃3）は行われなかったことに注意してください。つまり、ターゲットサービス/ノードはパケット＃3を直接受信して応答します。
If the IPv4-only nodes/services do not need connectivity with the public IPv4 Internet, private IPv4 addresses [RFC1918] could be used as their IPv4 Service Addresses in order to conserve the IDC operator's pool of public IPv4 addresses.
IPv4のみのノード/サービスがパブリックIPv4インターネットとの接続を必要としない場合、プライベートIPv4アドレス[RFC1918]をIPv4サービスアドレスとして使用して、IDCオペレーターのパブリックIPv4アドレスのプールを節約できます。
If the BR does not support hairpinning, or if the hairpinning solution is not desired for some other reason, intra-IDC IPv4 traffic may be facilitated by configuring additional EAMs on the ER for each service the IPv4-only node or application needs to communicate with. This makes the IPv6 traffic between the ER and the target service's IPv6 Service Address follow the direct path through the IPv6 network. The traffic does not pass the BR, which means that this solution might yield better latency than the hairpinning approach.
BRがヘアピニングをサポートしていない場合、または他の理由でヘアピニングソリューションが望ましくない場合は、IPv4専用ノードまたはアプリケーションが通信する必要がある各サービスのERに追加のEAMを構成することにより、IDC内IPv4トラフィックを促進できます。 。これにより、ERとターゲットサービスのIPv6サービスアドレス間のIPv6トラフィックは、IPv6ネットワークを介した直接パスに従います。トラフィックはBRを通過しません。つまり、このソリューションはヘアピニングアプローチよりも優れたレイテンシをもたらす可能性があります。
The additional EAM configured in the ER consists of the target's IPv6 Service Address and an IPv4 Service Address. The IPv4-only node or application will contact the target's assigned IPv4 Service Address using its own IPv4 Service Address as the source. The ER will then proceed to translate the original IPv4 packet to an IPv6 packet. The source address of the resulting IPv6 packet will be the IPv6 Service Address of the local node or application, while the destination address will be the IPv6 Service Address of the target. Any replies from the target will undergo identical translation, only in reverse.
ERで構成された追加のEAMは、ターゲットのIPv6サービスアドレスとIPv4サービスアドレスで構成されます。 IPv4のみのノードまたはアプリケーションは、独自のIPv4サービスアドレスをソースとして使用して、ターゲットに割り当てられたIPv4サービスアドレスにアクセスします。その後、ERは元のIPv4パケットをIPv6パケットに変換します。結果のIPv6パケットのソースアドレスはローカルノードまたはアプリケーションのIPv6サービスアドレスであり、宛先アドレスはターゲットのIPv6サービスアドレスです。ターゲットからの応答は、逆方向にのみ、同じ変換を受けます。
If the target service is located behind another ER, that other ER MUST also be provisioned with an additional EAM that contains the IPv4 and IPv6 Service Addresses of the origin IPv4-only node or application. Otherwise, the target service's ER will be unable to translate the source address of the incoming packets.
ターゲットサービスが別のERの背後にある場合、その別のERも、元のIPv4専用ノードまたはアプリケーションのIPv4およびIPv6サービスアドレスを含む追加のEAMでプロビジョニングする必要があります。そうでない場合、ターゲットサービスのERは、着信パケットのソースアドレスを変換できません。
+-[Pkt#1: IPv4]-+ +--[Pkt#2: IPv6]---+
| SRC 192.0.2.1 | (XLAT#1) | SRC 2001:db8:a:: |
| DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:b:: |
+---------------+ +------------------+
|
+-[Pkt#3: IPv4]-+ |
| SRC 192.0.2.1 | (XLAT#2) |
| DST 192.0.2.2 |<-------(@ ER B)------/
+---------------+
Figure 6: Non-hairpinned IPv4-IPv4 Packet Flow
図6：ヘアピン接続されていないIPv4-IPv4パケットフロー
Figure 6 illustrates the flow of a packet carrying intra-IDC IPv4 traffic between two IPv4-only nodes/applications that are both located behind ERs. Both ER A and ER B are configured with two EAMs: {192.0.2.1,2001:db8:a::} and {192.0.2.2,2001:db8:b::}. The packet will follow the regular routing path through the IPv6 IDC network; the BR is not involved, and the packet will not be hairpinned.
図6は、両方がERの背後にある2つのIPv4専用ノード/アプリケーション間でIDC内IPv4トラフィックを運ぶパケットのフローを示しています。 ER AとER Bの両方が2つのEAMで構成されています：{192.0.2.1,2001：db8：a ::}および{192.0.2.2,2001：db8：b ::}。パケットは、IPv6 IDCネットワークを介して通常のルーティングパスに従います。 BRは関係せず、パケットはヘアピンされません。
The above approach is not mutually exclusive with the hairpinning approach described in Section 5.1: If both EAMs above are also configured on the BR, both 192.0.2.1 and 192.0.2.2 would be reachable from other IPv4-only services/nodes using the hairpinning approach. They would also be reachable from the IPv4 Internet.
上記のアプローチは、セクション5.1で説明したヘアピニングアプローチと相互に排他的ではありません。上記の両方のEAMがBRでも構成されている場合、ヘアピニングアプローチを使用して他のIPv4専用サービス/ノードから192.0.2.1と192.0.2.2の両方に到達できます。 。それらはIPv4インターネットからも到達可能です。
Note that if the target service in this example was not located behind an ER, but instead was a native IPv6 service listening on 2001:db8:b::, the second translation step in Figure 6 would not occur; the target service would receive and respond to packet #2 directly.
この例のターゲットサービスがERの背後になく、2001：db8：b ::でリッスンしているネイティブIPv6サービスの場合、図6の2番目の変換ステップは発生しません。ターゲットサービスは、パケット＃2を直接受信して応答します。
As with the hairpinning approach, if the IPv4-only nodes/services do not need connectivity to/from the public IPv4 Internet, private IPv4 addresses [RFC1918] could be used as their IPv4 Service Addresses. Alternatively, in the case where the target service is on native IPv6, the target's assigned IPv4 Service Address has only local significance behind the ER. It could therefore be assigned from the IPv4 Service Continuity Prefix [RFC7335].
ヘアピニングアプローチと同様に、IPv4のみのノード/サービスがパブリックIPv4インターネットとの間の接続を必要としない場合、プライベートIPv4アドレス[RFC1918]をIPv4サービスアドレスとして使用できます。または、ターゲットサービスがネイティブIPv6上にある場合、ターゲットに割り当てられたIPv4サービスアドレスは、ERの背後でローカルな意味のみを持ちます。したがって、IPv4 Service Continuity Prefix [RFC7335]から割り当てることができます。
This section discusses security considerations specific to the use of an ER. See the Security Considerations section in [RFC7755] for security considerations applicable to the SIIT-DC architecture in general.
このセクションでは、ERの使用に固有のセキュリティの考慮事項について説明します。 SIIT-DCアーキテクチャ全般に適用可能なセキュリティの考慮事項については、[RFC7755]のセキュリティの考慮事項のセクションを参照してください。
If the ER receives an IPv4 packet from the application/node from a source address it does not have an EAM for, both the source and destination addresses will be rewritten according to [RFC6052]. After undergoing the reverse translation in the BR, the resulting IPv4 packet routed to the IPv4 network will have a spoofed IPv4 source address. The ER SHOULD therefore ensure that ingress filtering [RFC2827] is used on the ER's IPv4 interface so that such packets are immediately discarded.
ERがEAMを持たないソースアドレスからアプリケーション/ノードからIPv4パケットを受信すると、[RFC6052]に従ってソースアドレスと宛先アドレスの両方が書き換えられます。 BRで逆変換が行われた後、IPv4ネットワークにルーティングされたIPv4パケットには、スプーフィングされたIPv4送信元アドレスが含まれます。したがって、ERは、そのようなパケットがすぐに破棄されるように、ERのIPv4インターフェイスで入力フィルタリング[RFC2827]が使用されることを保証する必要があります（SHOULD）。
If the ER receives an IPv6 packet with both the source and destination address equal to one of its local IPv6 Service Addresses, the resulting packet would appear to the IPv4-only application/node as locally generated, as both the source address and the destination address will be the same address. This could trick the application into believing the packet came from a trusted source (itself). To prevent this, the ER SHOULD discard any received IPv6 packets that have a source address that is either 1) equal to any of its local IPv6 Service Addresses or 2) after translation from IPv6 to IPv4, equal to any of its local IPv4 Service Addresses.
ERがソースと宛先の両方のアドレスがローカルIPv6サービスアドレスの1つと等しいIPv6パケットを受信した場合、結果のパケットは、ソースアドレスと宛先アドレスの両方として、ローカルで生成されたものとしてIPv4専用アプリケーション/ノードに表示されます。同じ住所になります。これにより、アプリケーションをだまして、パケットが信頼できるソース（それ自体）から送信されたものと信じ込ませることができます。これを防ぐために、ERは、1）ローカルIPv6サービスアドレスのいずれかに等しい、または2）IPv6からIPv4に変換された、ローカルIPv4サービスアドレスのいずれかに等しいソースアドレスを持つ受信したIPv6パケットを破棄する必要があります（SHOULD）。 。
[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>。
[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>。
[RFC7757] Anderson, T. and A. Leiva, "Explicit Address Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI 10.17487/RFC7757, February 2016, <http://www.rfc-editor.org/info/rfc7757>.
[RFC7757]アンダーソン、T。およびA.リーバ、「ステートレスIP / ICMP変換のための明示的なアドレスマッピング」、RFC 7757、DOI 10.17487 / RFC7757、2016年2月、<http://www.rfc-editor.org/info/ rfc7757>。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[RFC826] Plummer、D。、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスを48ビットイーサネットアドレスに変換してイーサネットハードウェアで送信する」、STD 37、RFC 826、DOI 10.17487 / RFC0826、1982年11月、<http：/ /www.rfc-editor.org/info/rfc826>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<http://www.rfc-editor.org/info/rfc1918>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<http://www.rfc-editor.org/info/rfc2131>。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <http://www.rfc-editor.org/info/rfc2132>.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、DOI 10.17487 / RFC2132、1997年3月、<http://www.rfc-editor.org/info/rfc2132>。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを使用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、DOI 10.17487 / RFC2827、2000年5月、<http：// www .rfc-editor.org / info / rfc2827>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<http：/ /www.rfc-editor.org/info/rfc4861>。
[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>。
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", RFC 6535, DOI 10.17487/RFC6535, February 2012, <http://www.rfc-editor.org/info/rfc6535>.
[RFC6535] Huang、B.、Deng、H。、およびT. Savolainen、「Bump-in-the-Host（BIH）を使用したデュアルスタックホスト」、RFC 6535、DOI 10.17487 / RFC6535、2012年2月、< http://www.rfc-editor.org/info/rfc6535>。
[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>。
[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>。
Appendix A. Examples: Network-Based IPv4 Connectivity
付録A.例：ネットワークベースのIPv4接続
One relatively straight-forward way to provide IPv4 connectivity between a network-based ER and the IPv4 node(s) it serves is to ensure the IPv4 Service Address(es) can be enclosed within a larger IPv4 prefix. The ER may then claim one address in this prefix for itself and use it to provide an IPv4 default router address and assign the IPv4 Service Address(es) to its downstream node(s) using DHCPv4 [RFC2131]. For example, if the IPv4 Service Addresses are 192.0.2.26 and 192.0.2.27, the ER would configure the address 192.0.2.25/29 on its IPv4-facing interface and would add the two IPv4 Service Addresses to its DHCPv4 pool.
ネットワークベースのERとそれが提供するIPv4ノードの間にIPv4接続を提供する比較的簡単な方法の1つは、IPv4サービスアドレスをより大きなIPv4プレフィックスで囲むことができるようにすることです。次に、ERはこのプレフィックスに1つのアドレスを要求し、それを使用してIPv4デフォルトルーターアドレスを提供し、DHCPv4 [RFC2131]を使用してIPv4サービスアドレスをそのダウンストリームノードに割り当てます。たとえば、IPv4サービスアドレスが192.0.2.26と192.0.2.27の場合、ERはIPv4に面するインターフェイスにアドレス192.0.2.25/29を構成し、2つのIPv4サービスアドレスをDHCPv4プールに追加します。
One disadvantage of this method is that IPv4 communication between the IPv4 node(s) behind the ER and other services made available through SIIT-DC becomes impossible, if those other services are assigned IPv4 Service Addresses that also are covered by the same IPv4 prefix (e.g., 192.0.2.28). This happens because the IPv4 nodes will mistakenly believe they have an on-link route to the entire prefix and attempt to resolve the addresses using ARP [RFC826], instead of sending them to the ER for translation to IPv6. This problem could, however, be overcome by avoiding assigning IPv4 Service Addresses that overlap with an IPv4 prefix handled by an ER (at the expense of wasting some potential IPv4 Service Addresses) or by ensuring that the overlapping IPv4 Service Addresses are only assigned to services that do not need to communicate with the IPv4 node(s) behind the ER. A third way to avoid this problem is discussed in Appendix A.2.
この方法の1つの欠点は、ERの背後にあるIPv4ノードとSIIT-DCを介して提供される他のサービスとの間のIPv4通信が不可能になることです。これらのサービスに、同じIPv4プレフィックス（例：192.0.2.28）。これは、IPv4ノードがIPv6への変換のためにERに送信する代わりに、プレフィックス全体へのオンリンクルートがあると誤って認識し、ARP [RFC826]を使用してアドレスを解決しようとするためです。ただし、この問題は、ERによって処理されるIPv4プレフィックスと重複するIPv4サービスアドレスの割り当てを回避することによって（一部の潜在的なIPv4サービスアドレスを浪費することで）、または重複するIPv4サービスアドレスがサービスにのみ割り当てられるようにすることで解決できますERの背後にあるIPv4ノードと通信する必要はありません。この問題を回避する3番目の方法については、付録A.2で説明します。
In order to avoid the problem discussed in Appendix A.1, a private unrouted IPv4 network that does not encompass the IPv4 Service Address(es) could be used to provide connectivity between the ER and the IPv4-only node(s) it serves. An IPv4-only node must then assign its IPv4 Service Address as a secondary local address, while the ER routes each of the IPv4 Service Addresses to its assigned node using that node's private on-link IPv4 address as the next hop. This approach would ensure there are no overlaps with IPv4 Service Addresses elsewhere in the infrastructure, but on the other hand, it would preclude the use of DHCPv4 [RFC2131] for assigning the IPv4 Service Addresses.
付録A.1で説明した問題を回避するために、IPv4サービスアドレスを含まないプライベートのルーティングされていないIPv4ネットワークを使用して、ERとそれが提供するIPv4専用ノード間の接続を提供できます。次に、IPv4のみのノードは、IPv4サービスアドレスをセカンダリローカルアドレスとして割り当てる必要があります。一方、ERは、そのノードのプライベートオンリンクIPv4アドレスをネクストホップとして使用して、割り当てられたノードに各IPv4サービスアドレスをルーティングします。このアプローチは、インフラストラクチャの他の場所でIPv4サービスアドレスとの重複がないことを保証しますが、一方で、IPv4サービスアドレスを割り当てるためのDHCPv4 [RFC2131]の使用を排除します。
This approach creates a need to ensure that the IPv4 application is selecting the IPv4 Service Address (as opposed to its private on-link IPv4 address) as its source address when initiating outbound connections. This could be accomplished by altering the Default Address Selection Policy Table [RFC6724] on the IPv4 node.
このアプローチでは、アウトバウンド接続を開始するときに、IPv4アプリケーションが（プライベートオンリンクIPv4アドレスではなく）IPv4サービスアドレスをソースアドレスとして選択していることを確認する必要があります。これは、IPv4ノードのデフォルトアドレス選択ポリシーテーブル[RFC6724]を変更することで実現できます。
Acknowledgements
謝辞
The authors would like to especially thank the authors of 464XLAT [RFC6877]: Masataka Mawatari, Masanobu Kawashima, and Cameron Byrne. The architecture described by this document is merely an adaptation of their work to a data center environment and could not have happened without them.
著者は特に464XLAT [RFC6877]の著者、馬渡正孝、川島正信、キャメロン・バーンに感謝します。このドキュメントで説明するアーキテクチャは、データセンター環境への彼らの仕事の単なる適応であり、それらなしでは実現できなかったでしょう。
The authors would like also to thank the following individuals for their contributions, suggestions, corrections, and criticisms: Fred Baker, Tobias Brox, Olafur Gudmundsson, Christer Holmberg, Ray Hunter, Shucheng LIU (Will), and Andrew Yourtchenko.
著者らはまた、貢献、提案、修正、および批判に対して、フレッドベイカー、トビアスブロックス、オラファーグドマンズソン、クリスターホルムバーグ、レイハンター、シュチェンLIU（ウィル）、アンドリューユアチェンコの各個人に感謝します。
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
Sander Steffann S.J.M. Steffann Consultancy Tienwoningenweg 46 Apeldoorn, Gelderland 7312 DN The Netherlands
サンダーステファンS.J.M. Steffann Consultancy Tienwoningenweg 46アペルドールンヘルダーラントオランダ7312 DN
Email: sander@steffann.nl