[要約] RFC 7040は、IPv6上のIPv4アクセスネットワークに関する標準化されたガイドラインです。その目的は、IPv6ネットワーク上でIPv4アクセスを提供するための方法と手順を定義することです。
Internet Engineering Task Force (IETF) Y. Cui
Request for Comments: 7040 J. Wu
Category: Informational P. Wu
ISSN: 2070-1721 Tsinghua University
O. Vautrin
Juniper Networks
Y. Lee
Comcast
November 2013
Public IPv4-over-IPv6 Access Network
パブリックIPv4-over-IPv6アクセスネットワーク
Abstract
概要
This document describes a mechanism called Public 4over6, which is designed to provide IPv4 Internet connectivity over an IPv6 access network using global IPv4 addresses. Public 4over6 was developed in the IETF and is in use in some existing deployments but is not recommended for new deployments. Future deployments of similar scenarios should use Lightweight 4over6. Public 4over6 follows the Hub and Spoke softwire model and uses an IPv4-in-IPv6 tunnel to forward IPv4 packets over an IPv6 access network. The bidirectionality of the IPv4 communication is achieved by explicitly allocating global non-shared IPv4 addresses to end users and by maintaining IPv4-IPv6 address binding on the border relay. Public 4over6 aims to provide uninterrupted IPv4 services to users, like Internet Content Providers (ICPs), etc., while an operator makes the access network transition to an IPv6-only access network.
このドキュメントでは、パブリック4over6と呼ばれるメカニズムについて説明します。これは、グローバルIPv4アドレスを使用して、IPv6アクセスネットワーク上でIPv4インターネット接続を提供するように設計されています。パブリック4over6はIETFで開発され、一部の既存の展開で使用されていますが、新しい展開にはお勧めしません。同様のシナリオの今後の展開では、Lightweight 4over6を使用する必要があります。パブリック4over6は、ハブアンドスポークソフトワイヤーモデルに従い、IPv4-in-IPv6トンネルを使用して、IPv6アクセスネットワーク上でIPv4パケットを転送します。 IPv4通信の双方向性は、グローバルな非共有IPv4アドレスをエンドユーザーに明示的に割り当て、境界リレーでIPv4-IPv6アドレスバインディングを維持することによって実現されます。 Public 4over6は、インターネットコンテンツプロバイダー（ICP）などのユーザーに中断のないIPv4サービスを提供することを目的としています。一方、オペレーターはアクセスネットワークをIPv6のみのアクセスネットワークに移行します。
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/rfc7040.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7040で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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
2. Terminology .....................................................4
3. Scenario and Use Cases ..........................................4
4. Public 4over6 Address Provisioning ..............................6
4.1. Basic Provisioning Steps ...................................6
4.2. Public IPv4 Address Allocation .............................7
5. 4over6 CE Behavior ..............................................7
6. 4over6 BR Behavior ..............................................8
7. Fragmentation and Reassembly ....................................9
8. DNS .............................................................9
9. Security Considerations ........................................10
10. Contributors ..................................................11
11. References ....................................................12
11.1. Normative References .....................................12
11.2. Informative References ...................................12
When operators make the access network transition to an IPv6-only access network, they must continue to provide IPv4 services to their users to access IPv4 contents. IPv4 connectivity is required when communicating with the IPv4-only Internet. This document describes a mechanism called Public 4over6 for providing IPv4 connectivity over a native IPv6-only access network. This memo focuses on interactions between Public 4over6 elements as well as the deployment architecture.
オペレーターがアクセスネットワークをIPv6のみのアクセスネットワークに移行する場合、オペレーターは引き続きIPv4サービスをユーザーに提供してIPv4コンテンツにアクセスする必要があります。 IPv4のみのインターネットと通信する場合は、IPv4接続が必要です。このドキュメントでは、ネイティブIPv6のみのアクセスネットワークでIPv4接続を提供するためのPublic 4over6と呼ばれるメカニズムについて説明します。このメモは、パブリック4over6要素間の相互作用と配備アーキテクチャに焦点を当てています。
Public 4over6 is in active deployment in some environments, particularly in China Next Generation Internet (CNGI) and China Education and Research Network 2 (CERNET2), but it is not recommended for new deployments. Documenting this approach is intended to benefit users and operators of existing deployments as well as readers of other IPv4-over-IPv6 documents.
パブリック4over6は、一部の環境、特に中国次世代インターネット（CNGI）と中国教育研究ネットワーク2（CERNET2）でアクティブに配備されていますが、新しい配備にはお勧めしません。このアプローチを文書化することは、既存の展開のユーザーとオペレーターだけでなく、他のIPv4-over-IPv6文書の読者にも役立つことを目的としています。
In addition to Public 4over6 and its deployment architecture as described in this memo, the IETF is currently working on a more generic solution called Lightweight 4over6 [SOFTWIRE-LW46], which is classified as a binding approach in the Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE) [SOFTWIRE-CPE]. Lightweight 4over6 covers both sharing and non-sharing global IPv4 addresses in the Hub and Spoke model. Future deployments should use [SOFTWIRE-LW46].
このメモに記載されているPublic 4over6とその展開アーキテクチャに加えて、IETFは現在、Lightweight 4over6 [SOFTWIRE-LW46]と呼ばれるより一般的なソリューションに取り組んでいます。これは、Unified IPv4-in-IPv6 Softwireのバインディングアプローチとして分類されます顧客宅内機器（CPE）[SOFTWIRE-CPE]。軽量4over6は、ハブアンドスポークモデルの共有IPv4アドレスと非共有グローバルIPv4アドレスの両方をカバーします。今後の展開では[SOFTWIRE-LW46]を使用する必要があります。
Public 4over6 utilizes the IPv4-in-IPv6 tunnel technique defined in [RFC2473], which enables IPv4 datagrams to traverse through native IPv6 networks. IPv4 nodes connect to the Tunnel Entry-Point Node and Tunnel Exit-Point Node to communicate over the IPv6-only network. Therefore, the Internet Service Providers (ISPs) can run an IPv6-only infrastructure instead of a fully dual-stack network as well as avoid the need to deploy scarce IPv4 address resources throughout the network.
Public 4over6は、[RFC2473]で定義されているIPv4-in-IPv6トンネルテクニックを利用して、IPv4データグラムがネイティブIPv6ネットワークを通過できるようにします。 IPv4ノードは、トンネルエントリポイントノードとトンネル出口ポイントノードに接続して、IPv6のみのネットワークを介して通信します。したがって、インターネットサービスプロバイダー（ISP）は、完全なデュアルスタックネットワークの代わりにIPv6のみのインフラストラクチャを実行でき、ネットワーク全体に希少なIPv4アドレスリソースを展開する必要を回避できます。
This mechanism focuses on providing full end-to-end transparency to the user side. Therefore, global IPv4 addresses are expected to be provisioned to end users, and carrier-side address translation can be avoided. Furthermore, global non-shared IPv4 addresses are preferable to shared IPv4 addresses, so that user-side address translation is not necessary either. It is important, in particular, to users that are required to run their applications on an IP protocol different from TCP and UDP (e.g., IPsec, L2TP) or on certain well-known TCP/UDP ports (e.g., HTTP, SMTP). For many ISPs that are actually capable of provisioning non-shared unique IPv4 addresses, the mechanism provides a pure, suitable solution.
このメカニズムは、ユーザー側に完全なエンドツーエンドの透過性を提供することに重点を置いています。したがって、グローバルIPv4アドレスがエンドユーザーにプロビジョニングされることが期待され、キャリア側のアドレス変換を回避できます。さらに、グローバルな非共有IPv4アドレスは共有IPv4アドレスよりも望ましいため、ユーザー側のアドレス変換も必要ありません。特に、TCPおよびUDPとは異なるIPプロトコル（IPsec、L2TPなど）または特定の既知のTCP / UDPポート（HTTP、SMTPなど）でアプリケーションを実行する必要があるユーザーにとって重要です。非共有の一意のIPv4アドレスを実際にプロビジョニングできる多くのISPに対して、このメカニズムは純粋で適切なソリューションを提供します。
Another focus of this mechanism is deployment and operational flexibility. Public 4over6 allows IPv4 and IPv6 address architectures to be totally independent of each other; the end user's IPv4 address is not embedded in its IPv6 address. Therefore, IPv4 address planning has no implication for IPv6 address planning. Operators can manage the IPv4 address resources in a flat, centralized manner. This requires that the tunnel concentrator [RFC4925] maintain the binding between an IPv4 address and an IPv6 address, i.e., maintaining per-subscriber binding state.
このメカニズムのもう1つの焦点は、展開と運用の柔軟性です。パブリック4over6では、IPv4およびIPv6アドレスアーキテクチャを互いに完全に独立させることができます。エンドユーザーのIPv4アドレスは、IPv6アドレスに埋め込まれていません。したがって、IPv4アドレス計画は、IPv6アドレス計画に影響を与えません。オペレーターは、IPv4アドレスリソースをフラットで集中管理できます。これには、トンネルコンセントレータ[RFC4925]がIPv4アドレスとIPv6アドレス間のバインディングを維持すること、つまりサブスクライバごとのバインディング状態を維持することが必要です。
The mechanism follows the Hub and Spoke softwire model [RFC4925] and uses IPv4-in-IPv6 tunneling as the basic data-plane method. Global non-shared IPv4 addresses are allocated from the ISP to end hosts or CPEs over an IPv6 network. Simultaneously, the binding between the allocated IPv4 address and the end user's IPv6 address is maintained on the tunnel concentrator for encapsulation usage.
このメカニズムは、ハブアンドスポークソフトワイヤーモデル[RFC4925]に従い、基本的なデータプレーン方式としてIPv4-in-IPv6トンネリングを使用します。グローバルな非共有IPv4アドレスは、IPv6ネットワークを介してISPからエンドホストまたはCPEに割り当てられます。同時に、割り当てられたIPv4アドレスとエンドユーザーのIPv6アドレスの間のバインディングは、カプセル化の使用のためにトンネルコンセントレーターで維持されます。
Public 4over6: A per-subscriber, stateful IPv4-in-IPv6 tunnel mechanism. Public 4over6 supports bidirectional communication between the global IPv4 Internet and IPv4 hosts or customer networks via an IPv6 access network by leveraging IPv4-in-IPv6 tunneling [RFC2473] and global IPv4 address allocation over IPv6. The term 'Public' means the allocated IPv4 address is globally routable.
パブリック4over6：サブスクライバーごとのステートフルIPv4-in-IPv6トンネルメカニズム。パブリック4over6は、IPv4-in-IPv6トンネリング[RFC2473]とIPv6を介したグローバルIPv4アドレス割り当てを活用することにより、IPv6アクセスネットワークを介したグローバルIPv4インターネットとIPv4ホストまたはカスタマーネットワーク間の双方向通信をサポートします。 「パブリック」という用語は、割り当てられたIPv4アドレスがグローバルにルーティング可能であることを意味します。
Full IPv4 address: An IPv4 address that is not shared by multiple users. The user with this IPv4 address has full access to all the available TCP/UDP ports, including the well-known TCP/UDP ports.
完全なIPv4アドレス：複数のユーザーによって共有されないIPv4アドレス。このIPv4アドレスを持つユーザーは、既知のTCP / UDPポートを含む、使用可能なすべてのTCP / UDPポートへのフルアクセスを持っています。
4over6 Customer Edge (CE): A device functioning as the Customer Edge equipment in a Public 4over6 environment. A 4over6 CE can be either a dual-stack capable host or a dual-stack CPE device, both of which have a tunnel interface to support IPv4-in-IPv6 encapsulation. In the former case, the host supports both IPv4 and IPv6 stacks but its uplink is IPv6 only. In the latter case, the CPE has an IPv6 interface connecting to the ISP network and an IPv4 or dual-stack interface connecting to the customer network; hosts in the customer network can be IPv4 only or dual stack.
4over6 Customer Edge（CE）：パブリック4over6環境でCustomer Edge機器として機能するデバイス。 4over6 CEは、デュアルスタック対応ホストまたはデュアルスタックCPEデバイスのいずれかで、どちらもIPv4-in-IPv6カプセル化をサポートするトンネルインターフェイスを備えています。前者の場合、ホストはIPv4スタックとIPv6スタックの両方をサポートしますが、そのアップリンクはIPv6のみです。後者の場合、CPEには、ISPネットワークに接続するIPv6インターフェイスと、顧客ネットワークに接続するIPv4またはデュアルスタックインターフェイスがあります。カスタマーネットワークのホストは、IPv4のみまたはデュアルスタックにすることができます。
4over6 Border Relay (BR): A router deployed in the edge of the operator's IPv6 access network that supports IPv4-in-IPv6 tunnel termination. A 4over6 BR is a dual-stack router that connects to both the IPv6 access network and the IPv4 Internet. The 4over6 BR can also work as a DHCPv4-over-IPv6 [DHCPv4-IPv6] server/relay for assigning and distributing global IPv4 addresses to 4over6 CEs.
4over6ボーダーリレー（BR）：オペレーターのIPv6アクセスネットワークのエッジに配置され、IPv4-in-IPv6トンネル終端をサポートするルーター。 4over6 BRは、IPv6アクセスネットワークとIPv4インターネットの両方に接続するデュアルスタックルーターです。 4over6 BRは、DHCPv4-over-IPv6 [DHCPv4-IPv6]サーバー/リレーとしても機能し、グローバルIPv4アドレスを4over6 CEに割り当てて配布します。
The general Public 4over6 scenario is shown in Figure 1. Users in an IPv6 network take IPv6 as their native service. Some users are end hosts that face the ISP network directly, while others are in private networks behind CPEs, such as a home Local Area Network (LAN), an enterprise network, etc. The ISP network is IPv6 only rather than dual stack, which means the ISP cannot provide native IPv4 service to users. In order to support legacy IPv4 transport, some routers on the carrier side are dual stack and are connected to the IPv4 Internet. These routers act as 4over6 BRs. Network users that require IPv4 connectivity obtain it through these routers.
一般的なパブリック4over6シナリオを図1に示します。IPv6ネットワークのユーザーは、IPv6をネイティブサービスとして使用します。一部のユーザーはISPネットワークに直接直面するエンドホストですが、他のユーザーは、ホームローカルエリアネットワーク（LAN）、エンタープライズネットワークなどのCPEの背後にあるプライベートネットワークにあります。ISPネットワークはデュアルスタックではなくIPv6のみであり、 ISPがユーザーにネイティブIPv4サービスを提供できないことを意味します。レガシーIPv4トランスポートをサポートするために、キャリア側の一部のルーターはデュアルスタックであり、IPv4インターネットに接続されています。これらのルーターは4over6 BRとして機能します。 IPv4接続を必要とするネットワークユーザーは、これらのルーターを通じてそれを取得します。
+-------------------------+
| IPv6 ISP Network |
| |
+------+ |
|4over6|Host +-------+ +-----------+
| CE |=================| | | |
+------+ | | | |
| |4over6 | | IPv4 |
+--------------+ +------+ IPv4-in-IPv6 | BR |---| Internet |
| Customer | |4over6| | | | |
| Private IPv4 |--| CE |=================| | | |
| Network | | |CPE +-------+ +-----------+
+--------------+ +------+ |
| |
| |
+-------------------------+
Figure 1: Public 4over6 Scenario
図1：パブリック4over6シナリオ
Public 4over6 can be applicable in several use cases. If an ISP that switches to IPv6 still has plenty of global IPv4 address resources, it can deploy Public 4over6 to provide transparent IPv4 service for all its customers. If the ISP does not have enough IPv4 addresses, it can deploy Dual-Stack Lite [RFC6333] as the basic IPv4-over-IPv6 service. Along with Dual-Stack Lite, Public 4over6 can be deployed as a value-added service, overcoming the service degradation caused by the Carrier Grade NAT (CGN). An IPv4 application server is a typical high-end user of Public 4over6. Using a full, global IPv4 address brings significant advantages in this case and is important for Internet Content Providers (ICPs) making the transition to IPv6:
Public 4over6は、いくつかのユースケースに適用できます。 IPv6に切り替えるISPにまだグローバルIPv4アドレスリソースがたくさんある場合は、パブリック4over6を展開して、すべての顧客に透過的なIPv4サービスを提供できます。 ISPに十分なIPv4アドレスがない場合、ISPは基本的なIPv4-over-IPv6サービスとしてDual-Stack Lite [RFC6333]を展開できます。 Dual-Stack Liteとともに、Public 4over6は付加価値サービスとして展開でき、Carrier Grade NAT（CGN）によって引き起こされるサービスの低下を克服します。 IPv4アプリケーションサーバーは、パブリック4over6の典型的なハイエンドユーザーです。完全なグローバルIPv4アドレスを使用すると、この場合に大きな利点がもたらされ、IPv6に移行するインターネットコンテンツプロバイダー（ICP）にとって重要です。
o The DNS registration can be direct, using a dedicated address;
o DNS登録は、専用アドレスを使用して直接行うことができます。
o Accessing the application service can be straightforward, with no translation involved;
o アプリケーションサービスへのアクセスは簡単で、翻訳は必要ありません。
o There will be no need to provide NAT traversal mechanisms for incoming traffic, and no special handling is required for the well-known TCP/UDP ports.
o 着信トラフィックにNATトラバーサルメカニズムを提供する必要はなく、既知のTCP / UDPポートに特別な処理は必要ありません。
Figure 2 shows the basic provisioning steps for Public 4over6.
図2は、パブリック4over6の基本的なプロビジョニング手順を示しています。
4over6 DHCPv6 4over6 DHCPv4
CE Server BR Server
|Assign IPv6 Addr/Pref +| | |
| BR's IPv6 Addr Info | | |
|<----------------------| | |
| DHCPv6/Other | | |
WAN | |
IPv6 Configure | |
| | |
| Assign Public IPv4 Addr (DHCPv4 over v6/Static Conf) |
|<--------------------------------------|<-------------|
| | IPv4-IPv6 |
| | Binding SYN |
Tunnel |
IPv4 Configure Binding Update
| |
| IPv4-in-IPv6 Tunnel |
|<------------------------------------->|
| |
Figure 2: Public 4over6 Address Provisioning
図2：パブリック4over6アドレスプロビジョニング
The main steps are:
主な手順は次のとおりです。
o IPv6 address/prefix is provisioned to 4over6 CE, along with knowledge of 4over6 BR's IPv6 address, using DHCPv6 or other means.
o DHCPv6またはその他の手段を使用して、4over6 BRのIPv6アドレスに関する知識とともに、IPv6アドレス/プレフィックスが4over6 CEにプロビジョニングされます。
o 4over6 CE configures its WAN interface with a globally unique IPv6 address, which is a result of IPv6 provisioning, including DHCPv6, Stateless Address Autoconfiguration (SLAAC), or manual configuration.
o 4over6 CEは、DHCPv6、ステートレスアドレス自動構成（SLAAC）、または手動構成を含むIPv6プロビジョニングの結果であるグローバルに一意のIPv6アドレスでWANインターフェイスを構成します。
o IPv4 address is provisioned to 4over6 CE by DHCPv4 over IPv6 or static configuration.
o IPv4アドレスは、IPv6経由のDHCPv4または静的構成によって4over6 CEにプロビジョニングされます。
o 4over6 BR obtains the IPv4 and IPv6 addresses of the 4over6 CE using information provided by the DHCPv4 server.
o 4over6 BRは、DHCPv4サーバーから提供された情報を使用して、4over6 CEのIPv4アドレスとIPv6アドレスを取得します。
o 4over6 CE configures its tunnel interface as a result of IPv4 provisioning.
o 4over6 CEは、IPv4プロビジョニングの結果としてそのトンネルインターフェイスを設定します。
o 4over6 BR updates the IPv4-IPv6 address-binding table according to the address-binding information acquired from the DHCPv4 server.
o 4over6 BRは、DHCPv4サーバーから取得したアドレスバインディング情報に従ってIPv4-IPv6アドレスバインディングテーブルを更新します。
Usually, each CE is provisioned with one global IPv4 address. However, it is possible that a CE would require an IPv4 prefix. The key problem here is the mechanism for IPv4 address provisioning over IPv6 networks.
通常、各CEには1つのグローバルIPv4アドレスがプロビジョニングされます。ただし、CEがIPv4プレフィックスを必要とする可能性があります。ここでの主要な問題は、IPv6ネットワークを介したIPv4アドレスのプロビジョニングのメカニズムです。
There are two possibilities: DHCPv4 over IPv6, and static configuration. Public 4over6 supports both these methods. DHCPv4 over IPv6 allows DHCPv4 messages to be transported in IPv6 rather than IPv4; therefore, the DHCPv4 process can be performed over an IPv6 network between the BR and the relevant CE. [DHCPv4-IPv6] describes the DHCP protocol extensions needed to support this operation. For static configuration, Public 4over6 users and ISP operators negotiate beforehand to authorize the IPv4 address(es). Then the tunnel interface and the address binding are configured by the user and the ISP, respectively.
DHCPv4 over IPv6と静的構成の2つの可能性があります。 Public 4over6はこれらの両方の方法をサポートしています。 DHCPv4 over IPv6では、DHCPv4メッセージをIPv4ではなくIPv6で転送できます。したがって、BRと関連するCEの間のIPv6ネットワークを介してDHCPv4プロセスを実行できます。 [DHCPv4-IPv6]は、この操作をサポートするために必要なDHCPプロトコル拡張について説明しています。静的構成の場合、パブリック4over6ユーザーとISPオペレーターは、IPv4アドレスを承認するために事前に交渉します。次に、トンネルインターフェイスとアドレスバインディングは、それぞれユーザーとISPによって構成されます。
While regular users would probably opt for DHCPv4 over IPv6, the static configuration is particularly applicable in two cases: for application servers, which require a stable IPv4 address; and for enterprise networks, which usually require an IPv4 prefix rather than one single address. (Note that DHCPv4 does not support prefix allocation.)
通常のユーザーはおそらくIPv6上のDHCPv4を選択しますが、静的構成は特に次の2つの場合に適用できます。安定したIPv4アドレスを必要とするアプリケーションサーバー。また、エンタープライズネットワークの場合、通常は単一のアドレスではなくIPv4プレフィックスが必要です。 （DHCPv4はプレフィックスの割り当てをサポートしていないことに注意してください。）
A CE is provisioned with IPv6 before the Public 4over6 process. It also learns the BR's IPv6 address beforehand. This IPv6 address can be configured using a variety of methods, ranging from an out-of-band mechanism, manual configuration, or via a DHCPv6 option. In order to guarantee interoperability, the CE element implements the AFTR-Name DHCPv6 option defined in [RFC6334].
CEは、パブリック4over6プロセスの前にIPv6でプロビジョニングされます。また、BRのIPv6アドレスも事前に学習します。このIPv6アドレスは、アウトオブバンドメカニズム、手動構成、またはDHCPv6オプションを介したさまざまな方法を使用して構成できます。相互運用性を保証するために、CE要素は[RFC6334]で定義されているAFTR-Name DHCPv6オプションを実装します。
A CE supports DHCPv4 over IPv6 [DHCPv4-IPv6] to dynamically acquire an IPv4 address over IPv6 and assign it to the IPv4-in-IPv6 tunnel interface. The CE regards the BR as its DHCPv4-over-IPv6 server/relay, which is used to obtain its global IPv4 address allocation; its IPv6 address is learned by the CE as described above.
CEはIPv6上のDHCPv4 [DHCPv4-IPv6]をサポートし、IPv6を介してIPv4アドレスを動的に取得し、IPv4-in-IPv6トンネルインターフェイスに割り当てます。 CEは、BRをDHCPv4-over-IPv6サーバー/リレーと見なします。これは、グローバルIPv4アドレス割り当てを取得するために使用されます。前述のように、そのIPv6アドレスはCEによって学習されます。
A CE also supports static configuration of the tunnel interface. In the case of prefix provisioning, the tunnel interface is assigned with the well-known IPv4 address defined in Section 5.7 of [RFC6333], rather than using an address from the prefix. If the CE has multiple IPv6 addresses on its WAN interface, it uses one of the IPv6 addresses for DHCPv4 over IPv6 or negotiation of static configuration. The CE then uses the same IPv6 address for data-plane encapsulation.
CEは、トンネルインターフェイスの静的設定もサポートしています。プレフィックスプロビジョニングの場合、トンネルインターフェースには、プレフィックスのアドレスを使用するのではなく、[RFC6333]のセクション5.7で定義された既知のIPv4アドレスが割り当てられます。 CEのWANインターフェイスに複数のIPv6アドレスがある場合は、DHCPv4 over IPv6または静的構成のネゴシエーションにIPv6アドレスの1つを使用します。 CEは、データプレーンのカプセル化に同じIPv6アドレスを使用します。
A CE performs IPv4-in-IPv6 encapsulation and decapsulation on the tunnel interface. When sending out an IPv4 packet, it performs the encapsulation using the IPv6 address of the 4over6 BR as the IPv6 destination address and its own IPv6 address as the IPv6 source address. The decapsulation on the 4over6 CE is simple. When receiving an IPv4-in-IPv6 packet, the CE just removes the IPv6 header and either hands it to a local upper layer or forwards it to the customer network according to the IPv4 destination address.
CEは、トンネルインターフェイスでIPv4-in-IPv6カプセル化およびカプセル開放を実行します。 IPv4パケットを送信するとき、4over6 BRのIPv6アドレスをIPv6宛先アドレスとして使用し、自身のIPv6アドレスをIPv6送信元アドレスとして使用して、カプセル化を実行します。 4over6 CEでのカプセル開放は簡単です。 IPv4-in-IPv6パケットを受信すると、CEはIPv6ヘッダーを削除し、それをローカルの上位層に渡すか、IPv4宛先アドレスに従ってカスタマーネットワークに転送します。
A CE runs a regular IPv4 Network Address and Port Translation (NAPT) for its customer network when it is provisioned with one single IPv4 address. In that case, the assigned IPv4 address of the tunnel interface would be the external IPv4 address of the NAPT. Then the CE performs IPv4 private-to-public translation before encapsulation of IPv4 packets from the customer network and IPv4 public-to-private translation after decapsulation of IPv4-in-IPv6 packets.
CEは、単一のIPv4アドレスがプロビジョニングされている場合、カスタマーネットワークに対して通常のIPv4ネットワークアドレスおよびポート変換（NAPT）を実行します。その場合、トンネルインターフェイスに割り当てられたIPv4アドレスは、NAPTの外部IPv4アドレスになります。次に、CEは、カスタマーネットワークからのIPv4パケットのカプセル化前にIPv4プライベートからパブリックへの変換を実行し、IPv4-in-IPv6パケットのカプセル化解除後にIPv4パブリックからプライベートへの変換を実行します。
IPv4 NAPT is not necessary when the CE is provisioned with an IPv4 prefix. In this case, detailed customer network planning is out of scope for this document.
CEにIPv4プレフィックスがプロビジョニングされている場合、IPv4 NAPTは必要ありません。この場合、詳細な顧客ネットワーク計画はこのドキュメントの範囲外です。
The 4over6 CE supports backward compatibility with DS-Lite. A CE can employ the well-known IPv4 address for the Basic Bridging BroadBand (B4) element [RFC6333] and switch to Dual-Stack Lite for IPv4 communications if it can't get a global IPv4 address from the DHCPv4 server (for instance, if the DHCPv4-over-IPv6 process fails or the DHCPv4 server refuses to allocate a global IPv4 address to it, etc.).
4over6 CEは、DS-Liteとの下位互換性をサポートしています。 CEは、Basic Bridging BroadBand（B4）要素に既知のIPv4アドレスを採用し[RFC6333]、DHCPv4サーバーからグローバルIPv4アドレスを取得できない場合（たとえば、 DHCPv4-over-IPv6プロセスが失敗した場合、またはDHCPv4サーバーがグローバルIPv4アドレスの割り当てを拒否した場合など）。
The 4over6 BR maintains the bindings between the CE IPv6 address and CE IPv4 address (prefixes). The bindings are used to provide the correct encapsulation destination address for inbound IPv4 packets and also to validate the IPv6-IPv4 source of the outbound IPv4-in-IPv6 packets.
4over6 BRは、CE IPv6アドレスとCE IPv4アドレス（プレフィックス）間のバインディングを維持します。バインディングは、インバウンドIPv4パケットに正しいカプセル化宛先アドレスを提供し、アウトバウンドIPv4-in-IPv6パケットのIPv6-IPv4ソースを検証するためにも使用されます。
The BR acquires the binding information through the IPv4 address provisioning process. For static configuration, the operator manually configures the BR using the binding information obtained through negotiation with the customer. As for DHCPv4 over IPv6, there are multiple possibilities, which are deployment-specific:
BRは、IPv4アドレスプロビジョニングプロセスを通じてバインディング情報を取得します。静的構成の場合、オペレーターは、顧客との交渉を通じて取得したバインディング情報を使用して手動でBRを構成します。 IPv6を介したDHCPv4に関しては、展開固有の複数の可能性があります。
o The BR can be co-located with the DHCPv4-over-IPv6 server. Then the synchronization happens within the BR. It installs a binding when sending out an ACK for a DHCP lease and deletes it when the lease expires or a DHCP RELEASE message is received.
o BRはDHCPv4-over-IPv6サーバーと同じ場所に配置できます。次に、BR内で同期が行われます。 DHCPリースのACKを送信するときにバインディングをインストールし、リースが期限切れになるか、DHCP RELEASEメッセージを受信すると、バインディングを削除します。
o The BR can play the role of IPv6-Transport Relay Agent (TRA) as described in [DHCPv4-IPv6] and snoop for the DHCPv4 ACK and RELEASE messages as well as keep a timer for each binding according to the DHCP lease time.
o BRは、[DHCPv4-IPv6]で説明されているようにIPv6-Transport Relay Agent（TRA）の役割を果たすことができ、DHCPv4 ACKおよびRELEASEメッセージをスヌープし、DHCPリース時間に従って各バインディングのタイマーを維持します。
On the IPv6 side, the BR decapsulates IPv4-in-IPv6 packets coming from 4over6 CEs. It removes the IPv6 header of every IPv4-in-IPv6 packet and forwards it to the IPv4 Internet. Before the decapsulation, the BR checks the inner IPv4 source address against the outer IPv6 source address by matching such a binding entry in the binding table. If no binding is found, the BR silently drops the packet. On the IPv4 side, the BR encapsulates the IPv4 packets destined to 4over6 CEs. When performing the IPv4-in-IPv6 encapsulation, the BR uses its own IPv6 address as the IPv6 source address and uses the IPv4 destination address in the packet to look up the IPv6 destination address in the address-binding table. After the encapsulation, the BR sends the IPv6 packet on its IPv6 interface to reach a CE.
IPv6側では、BRは4over6 CEからのIPv4-in-IPv6パケットのカプセル化を解除します。すべてのIPv4-in-IPv6パケットのIPv6ヘッダーを削除し、それをIPv4インターネットに転送します。カプセル化解除の前に、BRは、バインディングテーブルのそのようなバインディングエントリを照合することにより、内部IPv4送信元アドレスを外部IPv6送信元アドレスと照合します。バインディングが見つからない場合、BRは暗黙的にパケットをドロップします。 IPv4側では、BRは4over6 CE宛てのIPv4パケットをカプセル化します。 IPv4-in-IPv6カプセル化を実行する場合、BRは独自のIPv6アドレスをIPv6送信元アドレスとして使用し、パケット内のIPv4宛先アドレスを使用して、アドレスバインディングテーブルでIPv6宛先アドレスを検索します。カプセル化後、BRはIPv6パケットを送信してCEに到達します。
The BR supports the hairpinning of traffic between two CEs by performing decapsulation and re-encapsulation of packets.
BRは、パケットのカプセル化解除と再カプセル化を実行することにより、2つのCE間のトラフィックのヘアピニングをサポートします。
In cases where the BR manages the global IPv4 address pool, the BR advertises the routing information of IPv4 addresses to the IPv4 Internet.
BRがグローバルIPv4アドレスプールを管理する場合、BRはIPv4アドレスのルーティング情報をIPv4インターネットにアドバタイズします。
The same considerations as those described in Sections 5.3 and 6.3 of [RFC6333] are taken into account for the CE and the BR, respectively.
[RFC6333]のセクション5.3および6.3で説明されているものと同じ考慮事項が、それぞれCEおよびBRで考慮されます。
The procedure described in Sections 5.5 and 6.4 of [RFC6333] is followed by the CE and the BR, respectively.
[RFC6333]のセクション5.5と6.4で説明されている手順の後に、それぞれCEとBRが続きます。
The 4over6 BR implements methods to limit service only to registered customers. On the control plane, the BR allocates IPv4 addresses only to registered customers. The BR can filter on the IPv6 source addresses of incoming DHCP requests and only respond to the ones that are conveyed by registered IPv6 source addresses. But this doesn't work in situations where multi-homing is present. In the networks where Public 4over6 is deployed, multi-homing is disallowed to avoid this issue.
4over6 BRは、登録された顧客にのみサービスを制限するメソッドを実装しています。コントロールプレーンでは、BRはIPv4アドレスを登録済みの顧客にのみ割り当てます。 BRは、着信DHCP要求のIPv6送信元アドレスをフィルタリングして、登録されたIPv6送信元アドレスによって伝達されるものにのみ応答できます。しかし、これはマルチホーミングが存在する状況では機能しません。 Public 4over6が展開されているネットワークでは、この問題を回避するためにマルチホーミングは許可されていません。
Alternatively, the BR can filter out the unregistered CE's requests during the DHCP process. For data packets, the BR does ingress filtering by looking up addresses in the IPv4-IPv6 address-binding table for the related matches as described in Section 6.
または、BRは、DHCPプロセス中に未登録のCEの要求を除外できます。データパケットの場合、BRは、セクション6で説明されているように、関連する一致についてIPv4-IPv6アドレスバインディングテーブルでアドレスを検索することにより、入力フィルタリングを行います。
In the case of fallback to DS-Lite, security considerations in Section 11 of [RFC6333] are followed.
DS-Liteへのフォールバックの場合、[RFC6333]のセクション11のセキュリティに関する考慮事項に従います。
The following are those who have made contributions to the effort:
以下は、その取り組みに貢献した人々です。
Huiling Zhao China Telecom Room 502, No.118, Xizhimennei Street Beijing 100035 P.R.China Phone: +86-10-58552002 Email: zhaohl@ctbri.com.cn
Huiling Zhao China Telecom Room 502、No.118、Xizhimennei Street Beijing 100035 P.R.China電話：+ 86-10-58552002メール：zhaohl@ctbri.com.cn
Chongfeng Xie China Telecom Room 708, No.118, Xizhimennei Street Beijing 100035 P.R.China Phone: +86-10-58552116 Email: xiechf@ctbri.com.cn
C Red Maple X IE Chinaテレコムルーム708、No.118、、zhimen通り内北京100035 P.R.中国電話：+ 86-10-58552116メール：Xie Chunfeng @参天揭日.com。Talent
Qiong Sun China Telecom Room 708, No.118, Xizhimennei Street Beijing 100035 P.R.China Phone: +86-10-58552936 Email: sunqiong@ctbri.com.cn
Qiong Sun China Telecom Room 708、No.118、Xizhimennei Street Beijing 100035 P.R.China電話：+ 86-10-58552936メール：sunqiong@ctbri.com.cn
Qi Sun Tsinghua University Beijing 100084 P.R.China Phone: +86-10-62785822 Email: sunqi@csnet1.cs.tsinghua.edu.cn
Qi Sun Tsinghua University Beijing 100084 P.R.China電話：+ 86-10-62785822メール：sunqi@csnet1.cs.tsinghua.edu.cn
Chris Metz Cisco Systems 3700 Cisco Way San Jose, CA 95134 USA Email: chmetz@cisco.com
Chris Metz Cisco Systems 3700 Cisco Way San Jose、CA 95134 USA Eメール：chmetz@cisco.com
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473] Conta、A。およびS. Deering、「Generic Packet Tunneling in IPv6 Specification」、RFC 2473、1998年12月。
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007.
[RFC4925] Li、X.、Dawkins、S.、Ward、D。、およびA. Durand、「Softwire Problem Statement」、RFC 4925、2007年7月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、2011年8月。
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, August 2011.
[RFC6334] Hankins、D。およびT. Mrugalski、「Dynamic Host Configuration Protocol for IPv6（DHCPv6）Option for Dual-Stack Lite」、RFC 6334、2011年8月。
[DHCPv4-IPv6] Cui, Y., Wu, P., Wu, J., Lemon, T., and Q. Sun, "DHCPv4 over IPv6 Transport", Work in Progress, October 2013.
[DHCPv4-IPv6] Cui、Y.、Wu、P.、Wu、J.、Lemon、T.、Q。Sun、「DHCPv4 over IPv6 Transport」、Work in Progress、2013年10月。
[SOFTWIRE-CPE] Boucadair, M., Farrer, I., Perreault, S., Ed., and S. Sivakumar, Ed., "Unified IPv4-in-IPv6 Softwire CPE", Work in Progress, May 2013.
[SOFTWIRE-CPE] Boucadair、M.、Farrer、I.、Perreault、S。、編、およびS. Sivakumar、編、「Unified IPv4-in-IPv6 Softwire CPE」、Work in Progress、2013年5月。
[SOFTWIRE-LW46] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the DS-Lite Architecture", Work in Progress, November 2013.
[SOFTWIRE-LW46] Cui、Y.、Sun、Q.、Boucadair、M.、Tsou、T.、Lee、Y.、I。Farrer、「Lightweight 4over6：An Extension to the DS-Lite Architecture」、Work進行中、2013年11月。
Authors' Addresses
著者のアドレス
Yong Cui Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6260-3059 EMail: yong@csnet1.cs.tsinghua.edu.cn
Yong Cu ITS inghuauniversity Beijing 100084 P.R.China電話：+ 86-10-6260-3059メール：@CS net1。現在、彼の4年間の計画。クォータ。才能
Jianping Wu Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5983 EMail: jianping@cernet.edu.cn
Jianping Wu Tsinghua University Beijing 100084 P.R.China電話：+ 86-10-6278-5983メール：jianping@cernet.edu.cn
Peng Wu Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 EMail: pengwu.thu@gmail.com
Peng Wu Tsinghua University Beijing 100084 P.R.China電話：+ 86-10-6278-5822メール：pengwu.thu@gmail.com
Olivier Vautrin Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 USA EMail: Olivier@juniper.net
Olivier Vautrin Juniper Networks 1194 N. Mathilda Avenue Sunnyvale、CA 94089 USA Eメール：Olivier@juniper.net
Yiu L. Lee Comcast One Comcast Center Philadelphia, PA 19103 USA EMail: yiu_lee@cable.comcast.com
Yiu L. Lee Comcast One Comcast Center Philadelphia、PA 19103 USA Eメール：yiu_lee@cable.comcast.com