[要約] RFC 8585は、IPv6カスタマーエッジルータがIPv4-as-a-Serviceをサポートするための要件を定義しています。その目的は、IPv6ネットワーク上でIPv4トラフィックをサポートするためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) J. Palet Martinez
Request for Comments: 8585 The IPv6 Company
Category: Informational H. M.-H. Liu
ISSN: 2070-1721 D-Link Systems, Inc.
M. Kawashima
NEC Platforms, Ltd.
May 2019
Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service
IPv4-as-a-ServiceをサポートするためのIPv6カスタマーエッジルーターの要件
Abstract
概要
This document specifies the IPv4 service continuity requirements for IPv6 Customer Edge (CE) routers that are provided either by the service provider or by vendors who sell through the retail market.
このドキュメントでは、サービスプロバイダーまたは小売市場を通じて販売するベンダーによって提供されるIPv6カスタマーエッジ（CE）ルーターのIPv4サービス継続性要件を指定します。
Specifically, this document extends the basic requirements for IPv6 CE routers as described in RFC 7084 to allow the provisioning of IPv6 transition services for the support of IPv4-as-a-Service (IPv4aaS) by means of new transition mechanisms. The document only covers IPv4aaS, i.e., transition technologies for delivering IPv4 in IPv6-only access networks. IPv4aaS is necessary because there aren't sufficient IPv4 addresses available for every possible customer/ device. However, devices or applications in the customer Local Area Networks (LANs) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services on the Internet.
具体的には、このドキュメントは、RFC 7084で説明されているIPv6 CEルーターの基本要件を拡張して、新しい移行メカニズムによるIPv4-as-a-Service（IPv4aaS）のサポートのためのIPv6移行サービスのプロビジョニングを可能にします。このドキュメントでは、IPv4aaS、つまりIPv6のみのアクセスネットワークでIPv4を提供するための移行テクノロジーのみを対象としています。 IPv4aaSが必要なのは、考えられるすべての顧客/デバイスが利用できるIPv4アドレスが十分にないためです。ただし、お客様のローカルエリアネットワーク（LAN）内のデバイスまたはアプリケーションはIPv4専用またはIPv6専用であり、インターネット上のIPv4専用サービスと通信する必要があります。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8585.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8585で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. LAN-Side Configuration . . . . . . . . . . . . . . . . . 5
3.2. Transition Technologies Support for IPv4 Service
Continuity (IPv4-as-a-Service) . . . . . . . . . . . . . 5
3.2.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 8
3.2.3. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . 9
3.2.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . 10
4. IPv4 Multicast Support . . . . . . . . . . . . . . . . . . . 11
5. UPnP Support . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Comparison to RFC 7084 . . . . . . . . . . . . . . . . . . . 12
7. Code Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Usage Scenarios . . . . . . . . . . . . . . . . . . 17
Appendix B. End-User Network Architecture . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
This document defines IPv4 service continuity features over an IPv6-only network for residential or small office routers (referred to as "IPv6 Transition CE Routers") in order to establish an industry baseline for transition features to be implemented on such routers.
このドキュメントでは、このようなルーターに実装される移行機能の業界ベースラインを確立するために、住宅または小規模オフィスルーター（「IPv6移行CEルーター」と呼ばれます）のIPv6専用ネットワーク上のIPv4サービス継続性機能を定義します。
These routers rely upon requirements for IPv6 CE routers defined in [RFC7084]. The scope of this document is to ensure IPv4 service continuity support for devices in the LAN side. This ensures that remote IPv4-only services continue to be accessible, for both IPv4-only and IPv6-only applications and devices, located in the LAN side behind an IPv6 Transition CE Router connected to an IPv6-only access network. These ISP access networks are typically referred to as Wide Area Networks (WANs), even if they may be metropolitan or regional in some cases. Figure 1 presents a simplified view of this architecture.
これらのルーターは、[RFC7084]で定義されているIPv6 CEルーターの要件に依存しています。このドキュメントの範囲は、LAN側のデバイスのIPv4サービス継続性サポートを保証することです。これにより、IPv4のみのアクセスネットワークに接続されたIPv6移行CEルーターの背後のLAN側にある、IPv4のみのアプリケーションとIPv6のみのアプリケーションとデバイスの両方に対して、リモートIPv4のみのサービスに引き続きアクセスできます。これらのISPアクセスネットワークは、大都市圏または地域的な場合もありますが、通常、ワイドエリアネットワーク（WAN）と呼ばれます。図1は、このアーキテクチャの簡略図を示しています。
+------------+ +------------+ \
| IPv4-only | | IPv4/IPv6 | \
| Remote | | Remote | |
| Host | | Host | | Internet
+--------+---+ +---+--------+ |
| | /
| | /
+-+-----------+-+ \
| Service | \
| Provider | \
| Router | | Service
+-------+-------+ | Provider
| IPv6-only | Network
| Customer /
| Internet Connection /
| /
+------+--------+ \
| IPv6 | \
| Transition CE | \
| Router | |
+---+-------+---+ |
LAN A | | LAN B | End-User
-+----------------+- -+-----+-------------+- | Network(s)
| | | |
+---+------+ +----+-----+ +-----+----+ |
| IPv6-only| | IPv4-only| |IPv4/IPv6 | /
| Host | | Host | | Host | /
+----------+ +----------+ +----------+ /
Figure 1: Simplified Typical IPv6-Only Access Network
図1：簡略化された一般的なIPv6のみのアクセスネットワーク
This document covers a set of IP transition techniques required when ISPs have, or want to have, an IPv6-only access network. This is a common situation when sufficient IPv4 addresses are no longer available for every possible customer and device, which causes IPv4 addresses to become prohibitively expensive. This, in turn, may result in service providers provisioning IPv6-only WAN access. At the same time, they need to ensure that both IPv4-only and IPv6-only devices and applications in the customer networks can still reach IPv4-only devices and applications on the Internet.
このドキュメントでは、ISPがIPv6のみのアクセスネットワークを所有している、または所有したい場合に必要な一連のIP移行手法について説明します。これは、考えられるすべての顧客とデバイスで十分なIPv4アドレスを利用できなくなった場合によく見られる状況であり、IPv4アドレスのコストが非常に高くなります。これにより、サービスプロバイダーがIPv6のみのWANアクセスをプロビジョニングする可能性があります。同時に、顧客ネットワークのIPv4専用デバイスとIPv6専用デバイスとアプリケーションの両方が、インターネット上のIPv4専用デバイスとアプリケーションに引き続きアクセスできることを確認する必要があります。
This document specifies the IPv4 service continuity mechanisms to be supported by an IPv6 Transition CE Router and relevant provisioning or configuration information differences from [RFC7084].
このドキュメントでは、IPv6移行CEルーターでサポートされるIPv4サービス継続性メカニズムと、[RFC7084]との関連するプロビジョニングまたは構成情報の違いについて説明します。
This document is not a recommendation for service providers to use any specific transition mechanism.
このドキュメントは、サービスプロバイダーが特定の移行メカニズムを使用することを推奨するものではありません。
Automatic provisioning of more complex topology than a single router with multiple LAN interfaces may be handled by means of the Home Networking Control Protocol (HNCP) [RFC7788], which is out of the scope of this document.
複数のLANインターフェイスを持つ単一のルーターよりも複雑なトポロジの自動プロビジョニングは、このドキュメントの範囲外であるホームネットワークコントロールプロトコル（HNCP）[RFC7788]を使用して処理できます。
Since it is impossible to know prior to sale which transition mechanism a device will need over its lifetime, an IPv6 Transition CE Router intended for the retail market MUST support all the IPv4aaS transition mechanisms listed in this document. Service providers that specify feature sets for the IPv6 Transition CE Router may define a different set of features from those included in this document, for example, features that support only some of the transition mechanisms enumerated in this document.
販売前に、デバイスがその存続期間中に必要とする移行メカニズムを知ることは不可能であるため、小売市場向けのIPv6移行CEルーターは、このドキュメントに記載されているすべてのIPv4aaS移行メカニズムをサポートする必要があります。 IPv6移行CEルーターの機能セットを指定するサービスプロバイダーは、このドキュメントに含まれているものとは異なる機能セットを定義する場合があります。たとえば、このドキュメントで列挙されている一部の移行メカニズムのみをサポートする機能などです。
Appendices A and B contain a complete description of the usage scenarios and end-user network architecture, respectively. These appendices, along with [RFC7084], will facilitate a clearer understanding of this document.
付録AとBには、それぞれ使用シナリオとエンドユーザーネットワークアーキテクチャの完全な説明が含まれています。これらの付録は、[RFC7084]とともに、このドキュメントのより明確な理解を促進します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document uses the same terms as in [RFC7084], with minor clarifications.
このドキュメントでは、[RFC7084]と同じ用語を使用していますが、多少の明確化が必要です。
"IPv4aaS" stands for "IPv4-as-a-Service", meaning transition technologies for delivering IPv4 in IPv6-only connectivity.
「IPv4aaS」は「IPv4-as-a-Service」の略で、IPv6のみの接続でIPv4を配信するための移行テクノロジーを意味します。
The term "IPv6 transition Customer Edge Router with IPv4aaS" (shortened as "IPv6 Transition CE Router") is defined as an IPv6 Customer Edge Router that provides features for the delivery of IPv4 services over an IPv6-only WAN network, including IPv6-IPv4 communications.
「IPv4を使用したIPv6移行カスタマーエッジルーター」（「IPv6移行CEルーター」と略される）という用語は、IPv6-IPv4を含むIPv6のみのWANネットワークを介してIPv4サービスを配信する機能を提供するIPv6カスタマーエッジルーターとして定義されます。コミュニケーション。
The term "WAN Interface" as used in this document is defined as an IPv6 Transition CE Router attachment to an IPv6-only link used to provide connectivity to a service provider network, including link Internet-layer (or higher layers) tunnels, such as IPv4-in-IPv6 tunnels.
このドキュメントで使用されている「WANインターフェイス」という用語は、サービスプロバイダーネットワークへの接続を提供するために使用されるIPv6のみのリンクへのIPv6トランジションCEルーター接続として定義されています。 IPv4-in-IPv6トンネル。
The IPv6 Transition CE Router MUST comply with [RFC7084] ("Basic Requirements for IPv6 Customer Edge Routers"). This document adds new requirements, as described in the following subsections.
IPv6移行CEルーターは、[RFC7084]（「IPv6カスタマーエッジルーターの基本要件」）に準拠する必要があります。このドキュメントでは、次のサブセクションで説明するように、新しい要件を追加しています。
A new LAN requirement is added, which is, in fact, common in regular IPv6 Transition CE Routers, and is required by most of the transition mechanisms:
新しいLAN要件が追加されました。これは、実際には通常のIPv6 Transition CEルーターで一般的であり、ほとんどの移行メカニズムで必要です。
L-1: The IPv6 Transition CE Router MUST implement a DNS proxy as described in [RFC5625] ("DNS Proxy Implementation Guidelines").
L-1：[RFC5625]（「DNSプロキシ実装ガイドライン」）で説明されているように、IPv6 Transition CEルーターはDNSプロキシを実装する必要があります。
3.2. Transition Technologies Support for IPv4 Service Continuity (IPv4- as-a-Service)
3.2. 移行テクノロジによるIPv4サービス継続性のサポート（IPv4- as-a-Service）
The main target of this document is the support of IPv6-only WAN access. To enable legacy IPv4 functionality, this document also includes the support of IPv4-only devices and applications in the customer LANs, as well as IPv4-only services on the Internet. Thus, both IPv4-only and IPv6-only devices in the customer-side LANs of the IPv6 Transition CE Router are able to reach the IPv4-only services.
このドキュメントの主な対象は、IPv6のみのWANアクセスのサポートです。従来のIPv4機能を有効にするために、このドキュメントには、お客様のLANでのIPv4専用デバイスとアプリケーションのサポート、およびインターネット上のIPv4専用サービスも含まれています。したがって、IPv6 Transition CEルーターのカスタマー側LANのIPv4専用デバイスとIPv6専用デバイスの両方が、IPv4専用サービスに到達できます。
Note that this document only configures IPv4aaS in the IPv6 Transition CE Router itself; it does not forward such information to devices attached to the LANs. Thus, the WAN configuration and availability of native IPv4 or IPv4aaS are transparent for the devices attached to the LANs.
このドキュメントでは、IPv6 Transition CEルーター自体でのみIPv4aaSを構成することに注意してください。 LANに接続されているデバイスにそのような情報を転送することはありません。したがって、WAN構成とネイティブIPv4またはIPv4aaSの可用性は、LANに接続されたデバイスに対して透過的です。
This document takes no position on simultaneous operation of one or several transition mechanisms and/or native IPv4.
このドキュメントは、1つまたは複数の移行メカニズムおよび/またはネイティブIPv4の同時動作に関する立場を取りません。
In order to seamlessly provide IPv4 service continuity in the customer LANs and allow automated IPv6 transition mechanism provisioning, the following general transition requirements are defined.
お客様のLANでIPv4サービスの継続性をシームレスに提供し、自動化されたIPv6移行メカニズムのプロビジョニングを可能にするために、次の一般的な移行要件が定義されています。
General transition requirements:
一般的な移行要件：
TRANS-1: The IPv6 Transition CE Router MUST support the DHCPv6 S46 priority options described in [RFC8026] ("Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism").
TRANS-1：[RFC8026]（「Unified IPv4-in-IPv6 Softwire Customer Premises Equipment（CPE）：A DHCPv6-Based Prioritization Mechanism」）で説明されているDHCPv6 S46優先オプションをIPv6移行CEルーターはサポートする必要があります。
TRANS-2: The IPv6 Transition CE Router MUST have a GUI and either a CLI or API (or both) to manually enable/disable each of the supported transition mechanisms.
TRANS-2：IPv6トランジションCEルーターには、サポートされている各トランジションメカニズムを手動で有効/無効にするためのGUIとCLIまたはAPI（または両方）が必要です。
TRANS-3: If an IPv6 Transition CE Router supports more than one LAN subnet, the IPv6 Transition CE Router MUST allow appropriate subnetting and configuration of the address space among several interfaces. In some transition mechanisms, this may require differentiating mappings/ translations on a per-interface basis.
TRANS-3：IPv6トランジションCEルーターが複数のLANサブネットをサポートする場合、IPv6トランジションCEルーターは、複数のインターフェース間でのアドレス空間の適切なサブネット化と構成を許可する必要があります。一部の移行メカニズムでは、インターフェイスごとにマッピング/変換を区別する必要があります。
In order to allow the service provider to disable all the transition mechanisms and/or choose the most convenient one, the IPv6 Transition CE Router MUST follow the following configuration steps:
サービスプロバイダーがすべての移行メカニズムを無効にしたり、最も便利なメカニズムを選択したりできるようにするには、IPv6移行CEルーターは次の構成手順に従う必要があります。
CONFIG-1: Request the relevant configuration options for each supported transition mechanisms, which MUST remain disabled at this step.
CONFIG-1：サポートされている各移行メカニズムに関連する構成オプションを要求します。このオプションは、このステップでは無効のままにしておく必要があります。
CONFIG-2: Following the steps in Section 1.4 of [RFC8026], MUST check for a valid match in OPTION_S46_PRIORITY, which allows enabling/disabling a transition mechanism.
CONFIG-2：[RFC8026]のセクション1.4の手順に従って、OPTION_S46_PRIORITYで有効な一致を確認する必要があります。これにより、移行メカニズムを有効/無効にできます。
CONFIG-3: Keep disabled all the transition mechanisms if no match is found between the priority list and the candidate list, unless a NAT64 [RFC6146] prefix has been configured, in which case, 464XLAT [RFC6877] MUST be enabled.
CONFIG-3：NAT64 [RFC6146]プレフィックスが構成されていない限り、優先リストと候補リストの間に一致が見つからない場合は、すべての移行メカニズムを無効のままにします。この場合、464XLAT [RFC6877]を有効にする必要があります。
Because 464XLAT has no DHCPv6 configuration options, it can't currently be included in the OPTION_S46_PRIORITY. In the future, an update of [RFC8026] or a NAT64 DHCPv6 configuration option may enable it. Meanwhile, if an operator provides 464XLAT, it needs to ensure that OPTION_S46_PRIORITY is not sent for any other transition mechanism to the relevant customers.
464XLATにはDHCPv6構成オプションがないため、現在OPTION_S46_PRIORITYに含めることはできません。将来的には、[RFC8026]の更新またはNAT64 DHCPv6構成オプションにより、それが有効になる可能性があります。一方、オペレーターが464XLATを提供する場合は、OPTION_S46_PRIORITYが他の移行メカニズムのために関連する顧客に送信されないようにする必要があります。
The following subsections describe the requirements for supporting each one of the transition mechanisms. An IPv6 Transition CE Router intended for the retail market MUST support all of them.
次のサブセクションでは、移行メカニズムのそれぞれをサポートするための要件について説明します。小売市場向けのIPv6 Transition CEルーターは、それらすべてをサポートする必要があります。
464XLAT [RFC6877] is a technique to provide IPv4 service over an IPv6-only access network without encapsulation. This architecture assumes a Stateful NAT64 [RFC6146] function deployed at the service provider or a third-party network.
464XLAT [RFC6877]は、カプセル化なしでIPv6のみのアクセスネットワーク上でIPv4サービスを提供する技術です。このアーキテクチャは、サービスプロバイダーまたはサードパーティのネットワークに展開されたステートフルNAT64 [RFC6146]機能を想定しています。
The IPv6 Transition CE Router MUST support customer-side translator (CLAT) functionality [RFC6877] if intended for the retail market. If 464XLAT is supported, it MUST be implemented according to [RFC6877]. The following IPv6 Transition CE Router requirements also apply.
IPv6トランジションCEルーターは、小売市場向けの場合、顧客側トランスレータ（CLAT）機能[RFC6877]をサポートする必要があります。 464XLATがサポートされている場合は、[RFC6877]に従って実装する必要があります。次のIPv6 Transition CEルーターの要件も適用されます。
464XLAT requirements:
464XLAT要件：
464XLAT-1: Unless a dedicated /64 prefix has been acquired, either by using DHCPv6-PD (Dynamic Host Configuration Protocol for IPv6 Prefix Delegation) or by alternative means, the IPv6 Transition CE Router MUST perform IPv4 Network Address Translation (NAT) on IPv4 traffic translated using the CLAT.
464XLAT-1：DHCPv6-PD（IPv6プレフィックス委任用の動的ホスト構成プロトコル）または代替手段のいずれかを使用して専用の/ 64プレフィックスが取得されていない限り、IPv6移行CEルーターはIPv4ネットワークアドレス変換（NAT）を実行する必要がありますCLATを使用して変換されたIPv4トラフィック。
464XLAT-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF [RFC6970] ("Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF)").
464XLAT-2：IPv6移行CEルーターはIGD-PCP IWF [RFC6970]（「ユニバーサルプラグアンドプレイ（UPnP）インターネットゲートウェイデバイス-ポート制御プロトコルインターワーキング機能（IGD-PCP IWF））」をサポートする必要があります（SHOULD）。
464XLAT-3: If the Port Control Protocol (PCP) [RFC6887] is implemented, the IPv6 Transition CE Router MUST also implement [RFC7291] ("DHCP Options for the Port Control Protocol (PCP)"). Following [RFC6887], if no PCP server is configured, the IPv6 Transition CE Router MAY verify if the default gateway or the NAT64 is the PCP server. The IPv6 Transition CE Router MUST use plain IPv6 mode (i.e., not IPv4-in-IPv6 encapsulation) to send PCP requests to the server.
464XLAT-3：ポート制御プロトコル（PCP）[RFC6887]が実装されている場合、IPv6移行CEルーターは[RFC7291]（「ポート制御プロトコル（PCP）のDHCPオプション」）も実装する必要があります。 [RFC6887]に続いて、PCPサーバーが構成されていない場合、IPv6 Transition CEルーターは、デフォルトゲートウェイまたはNAT64がPCPサーバーであるかどうかを確認できます（MAY）。 IPv6移行CEルーターは、サーバーにPCP要求を送信するために、プレーンIPv6モード（つまり、IPv4-in-IPv6カプセル化ではない）を使用する必要があります。
464XLAT-4: The IPv6 Transition CE Router MUST implement [RFC7050] ("Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis") in order to discover the provider-side translator (PLAT) translation IPv4 and IPv6 prefix(es)/suffix(es).
464XLAT-4：プロバイダー側トランスレーター（PLAT）変換IPv4およびIPv6プレフィックス（複数可）/サフィックスを検出するために、IPv6遷移CEルーターは[RFC7050]（「IPv6アドレス合成に使用されるIPv6プレフィックスの検出」）を実装する必要があります（es）。
464XLAT-5: If PCP is implemented, the IPv6 Transition CE Router MUST follow [RFC7225] ("Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)") in order to learn the PLAT-side translation IPv4 and IPv6 prefix(es)/suffix(es) used by an upstream PCP-controlled NAT64 device.
464XLAT-5：PCPが実装されている場合、IPv6移行CEルーターは、[RFC7225]（「ポート制御プロトコル（PCP）を使用したNAT64 IPv6プレフィックスの検出」）に従って、PLAT側の変換IPv4およびIPv6プレフィックスを学習する必要があります。 ）/上流のPCP制御のNAT64デバイスで使用される接尾辞。
464XLAT-6: If the network provides several choices for the discovery/learning of the NAT64 prefix, the priority to use one or the other MUST follow this order: 1) [RFC7225] and 2) [RFC7050].
464XLAT-6：ネットワークがNAT64プレフィックスの検出/学習にいくつかの選択肢を提供する場合、どちらか一方を使用する優先順位は次の順序に従う必要があります：1）[RFC7225]および2）[RFC7050]。
The NAT64 prefix could be discovered by means of the method defined in [RFC7050] only if the service provider uses DNS64 [RFC6147]. It may be the case that the service provider does not use or does not trust DNS64 [RFC6147] because the DNS configuration at the CE (or hosts behind the CE) can be modified by the customer. In that case, the service provider may opt to configure the NAT64 prefix by means of the option defined in [RFC7225]. This can also be used if the service provider uses DNS64 [RFC6147].
NAT64プレフィックスは、サービスプロバイダーがDNS64 [RFC6147]を使用している場合にのみ、[RFC7050]で定義されている方法で発見できます。 CE（またはCEの背後にあるホスト）のDNS構成はお客様が変更できるため、サービスプロバイダーがDNS64 [RFC6147]を使用または信頼していない可能性があります。その場合、サービスプロバイダーは、[RFC7225]で定義されているオプションを使用して、NAT64プレフィックスを設定することを選択できます。これは、サービスプロバイダーがDNS64 [RFC6147]を使用している場合にも使用できます。
DS-Lite [RFC6333] enables continued support for IPv4 services. DS-Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT). It is expected that DS-Lite traffic is forwarded over the IPv6 Transition CE Router's native IPv6 WAN interface and not encapsulated in another tunnel.
DS-Lite [RFC6333]は、IPv4サービスの継続的なサポートを可能にします。 DS-Liteを使用すると、ブロードバンドサービスプロバイダーは、IP in IP（IPv4-in-IPv6）とネットワークアドレス変換（NAT）の2つのよく知られたテクノロジーを組み合わせることにより、IPv4アドレスを顧客間で共有できます。 DS-Liteトラフィックは、IPv6 Transition CEルーターのネイティブIPv6 WANインターフェイスを介して転送され、別のトンネルでカプセル化されないことが期待されています。
The IPv6 Transition CE Router MUST implement DS-Lite B4 functionality [RFC6333] if intended for the retail market. If DS-Lite is supported, it MUST be implemented according to [RFC6333]. The following IPv6 Transition CE Router requirements also apply.
IPv6トランジションCEルーターは、小売市場向けの場合、DS-Lite B4機能[RFC6333]を実装する必要があります。 DS-Liteがサポートされている場合は、[RFC6333]に従って実装する必要があります。次のIPv6 Transition CEルーターの要件も適用されます。
DS-Lite requirements:
DS-Liteの要件：
DSLITE-1: The IPv6 Transition CE Router MUST support configuration of DS-Lite via the DS-Lite DHCPv6 option [RFC6334] ("Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite"). The IPv6 Transition CE Router MAY use other mechanisms to configure DS-Lite parameters. Such mechanisms are outside the scope of this document.
DSLITE-1：IPv6トランジションCEルーターは、DS-Lite DHCPv6オプション[RFC6334]（ "Dynamic Host Configuration Protocol for IPv6（DHCPv6）Option for Dual-Stack Lite"）によるDS-Liteの構成をサポートする必要があります。 IPv6トランジションCEルーターは、DS-Liteパラメータを設定するために他のメカニズムを使用する場合があります。このようなメカニズムは、このドキュメントの範囲外です。
DSLITE-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF [RFC6970].
DSLITE-2：IPv6移行CEルーターはIGD-PCP IWF [RFC6970]をサポートする必要があります（SHOULD）。
DSLITE-3: If PCP [RFC6887] is implemented, the IPv6 Transition CE Router SHOULD implement [RFC7291]. If PCP [RFC6887] is implemented and a PCP server is not configured, the IPv6 Transition CE Router MUST assume, by default, that the Address Family Transition Router (AFTR, commonly called "CGN" - Carrier-Grade NAT) is the PCP server. The IPv6
DSLITE-3：PCP [RFC6887]が実装されている場合、IPv6 Transition CEルーターは[RFC7291]を実装する必要があります（SHOULD）。 PCP [RFC6887]が実装されていて、PCPサーバーが構成されていない場合、IPv6移行CEルーターは、デフォルトで、アドレスファミリー移行ルーター（AFTR、一般に「CGN」と呼ばれる-キャリアグレードNAT）がPCPサーバーであると想定する必要があります。 。 IPv6
Transition CE Router MUST use plain IPv6 mode (i.e., not IPv4-in-IPv6 encapsulation) to send PCP requests to the server. The term "default" above is to be interpreted as pertaining to a configuration as applied by a vendor prior to the administrator changing it for its initial activation.
移行CEルーターは、PCP要求をサーバーに送信するために、プレーンIPv6モード（つまり、IPv4-in-IPv6カプセル化ではない）を使用する必要があります。上記の「デフォルト」という用語は、管理者が初期アクティベーションのために設定を変更する前に、ベンダーによって適用される構成に関連すると解釈されます。
DSLITE-4: The IPv6 Transition CE Router MUST NOT perform IPv4 Network Address Translation (NAT) on IPv4 traffic encapsulated using DS-Lite [RFC6333].
DSLITE-4：IPv6移行CEルーターは、DS-Lite [RFC6333]を使用してカプセル化されたIPv4トラフィックでIPv4ネットワークアドレス変換（NAT）を実行してはなりません（MUST NOT）。
lw4o6 [RFC7596] specifies an extension to DS-Lite that moves the NAPT function from the DS-Lite tunnel concentrator to the tunnel client located in the IPv6 Transition CE Router, removing the requirement for an AFTR (CGN) function in the tunnel concentrator and reducing the amount of centralized state.
lw4o6 [RFC7596]は、NA-PT機能をDS-LiteトンネルコンセントレータからIPv6トランジションCEルーターにあるトンネルクライアントに移動するDS-Liteへの拡張を指定し、トンネルコンセントレータでのAFTR（CGN）機能の要件を削除し、集中状態の量を減らします。
The IPv6 Transition CE Router MUST implement lwB4 functionality [RFC7596] if intended for the retail market. If DS-Lite is implemented, lw4o6 SHOULD be implemented as well. If lw4o6 is supported, it MUST be implemented according to [RFC7596]. The following IPv6 Transition CE Router requirements also apply.
IPv6トランジションCEルーターは、小売市場向けの場合、lwB4機能[RFC7596]を実装する必要があります。 DS-Liteが実装されている場合は、lw4o6も実装する必要があります（SHOULD）。 lw4o6がサポートされている場合、[RFC7596]に従って実装する必要があります。次のIPv6 Transition CEルーターの要件も適用されます。
lw4o6 requirements:
lw4o6の要件：
LW4O6-1: The IPv6 Transition CE Router MUST support configuration of lw4o6 via the lw4o6 DHCPv6 options [RFC7598] ("DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients"). The IPv6 Transition CE Router MAY use other mechanisms to configure lw4o6 parameters. Such mechanisms are outside the scope of this document.
LW4O6-1：IPv6移行CEルーターは、lw4o6 DHCPv6オプション[RFC7598]を介したlw4o6の構成をサポートする必要があります（「Softwireアドレスとポートマップクライアントの構成のためのDHCPv6オプション」）。 IPv6移行CEルーターは、他のメカニズムを使用してlw4o6パラメーターを構成できます（MAY）。このようなメカニズムは、このドキュメントの範囲外です。
LW4O6-2: The IPv6 Transition CE Router MUST support the DHCPv4-over-DHCPv6 (DHCP 4o6) transport described in [RFC7341] ("DHCPv4-over-DHCPv6 (DHCP 4o6) Transport").
LW4O6-2：[RFC7341]で説明されているDHCPv4-over-DHCPv6（DHCP 4o6）トランスポート（「DHCPv4-over-DHCPv6（DHCP 4o6）トランスポート」）をサポートする必要があります。
LW4O6-3: The IPv6 Transition CE Router MAY support Dynamic Allocation of Shared IPv4 Addresses as described in [RFC7618] ("Dynamic Allocation of Shared IPv4 Addresses").
LW4O6-3：[RFC7618]（「共有IPv4アドレスの動的割り当て」）で説明されているように、IPv6移行CEルーターは共有IPv4アドレスの動的割り当てをサポートしてもよい（MAY）。
Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597] is a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation. MAP-E includes an algorithmic mechanism for mapping between IPv6 and IPv4 addresses.
カプセル化によるアドレスとポートのマッピング（MAP-E）[RFC7597]は、IPカプセル化を使用してIPv6ネットワークを介してIPv4パケットを転送するためのメカニズムです。 MAP-Eには、IPv6アドレスとIPv4アドレスをマッピングするためのアルゴリズムメカニズムが含まれています。
The IPv6 Transition CE Router MUST support MAP-E CE functionality [RFC7597] if intended for the retail market. If MAP-E is supported, it MUST be implemented according to [RFC7597]. The following IPv6 Transition CE Router requirements also apply.
IPv6トランジションCEルーターは、小売市場向けの場合、MAP-E CE機能[RFC7597]をサポートする必要があります。 MAP-Eがサポートされている場合は、[RFC7597]に従って実装する必要があります。次のIPv6 Transition CEルーターの要件も適用されます。
MAP-E requirements:
MAP-Eの要件：
MAPE-1: The IPv6 Transition CE Router MUST support configuration of MAP-E via the MAP-E DHCPv6 options [RFC7598]. The IPv6 Transition CE Router MAY use other mechanisms to configure MAP-E parameters. Such mechanisms are outside the scope of this document.
MAPE-1：IPv6移行CEルーターは、MAP-E DHCPv6オプション[RFC7598]によるMAP-Eの構成をサポートする必要があります。 IPv6移行CEルーターは、他のメカニズムを使用してMAP-Eパラメーターを構成できます（MAY）。このようなメカニズムは、このドキュメントの範囲外です。
MAPE-2: The IPv6 Transition CE Router MAY support Dynamic Allocation of Shared IPv4 Addresses as described in [RFC7618].
MAPE-2：[RFC7618]で説明されているように、IPv6移行CEルーターは共有IPv4アドレスの動的割り当てをサポートしてもよい（MAY）。
MAP-T [RFC7599] is a mechanism similar to MAP-E, differing from it in that MAP-T uses IPv4-IPv6 translation, instead of encapsulation, as the form of IPv6 domain transport.
MAP-T [RFC7599]はMAP-Eと同様のメカニズムですが、MAP-TがIPv6ドメイントランスポートの形式としてカプセル化ではなくIPv4-IPv6変換を使用する点が異なります。
The IPv6 Transition CE Router MUST support MAP-T CE functionality [RFC7599] if intended for the retail market. If MAP-T is supported, it MUST be implemented according to [RFC7599]. The following IPv6 Transition CE Router requirements also apply.
IPv6トランジションCEルーターは、小売市場向けである場合、MAP-T CE機能[RFC7599]をサポートする必要があります。 MAP-Tがサポートされている場合は、[RFC7599]に従って実装する必要があります。次のIPv6 Transition CEルーターの要件も適用されます。
MAP-T requirements:
MAP-Tの要件：
MAPT-1: The IPv6 Transition CE Router MUST support configuration of MAP-T via the MAP-T DHCPv6 options [RFC7598]. The IPv6 Transition CE Router MAY use other mechanisms to configure MAP-T parameters. Such mechanisms are outside the scope of this document.
MAPT-1：IPv6移行CEルーターは、MAP-T DHCPv6オプション[RFC7598]によるMAP-Tの構成をサポートする必要があります。 IPv6トランジションCEルーターは、他のメカニズムを使用してMAP-Tパラメータを構成する場合があります。このようなメカニズムは、このドキュメントの範囲外です。
MAPT-2: The IPv6 Transition CE Router MAY support Dynamic Allocation of Shared IPv4 Addresses as described in [RFC7618].
MAPT-2：[RFC7618]で説明されているように、IPv6移行CEルーターは共有IPv4アドレスの動的割り当てをサポートしてもよい（MAY）。
Existing IPv4 deployments support IPv4 multicast for services such as IPTV. In the transition phase, it is expected that multicast services will still be provided using IPv4 to the customer LANs.
既存のIPv4展開は、IPTVなどのサービスのIPv4マルチキャストをサポートしています。移行フェーズでは、IPv4を使用して顧客のLANにマルチキャストサービスが引き続き提供されることが予想されます。
If the IPv6 Transition CE Router supports delivery of IPv4 multicast services, then it MUST support [RFC8114] ("Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network") and [RFC8115] ("DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes").
IPv6トランジションCEルーターがIPv4マルチキャストサービスの配信をサポートしている場合、[RFC8114]（ "IPv4マルチキャストサービスを介したIPv4クライアントへのIPv4マルチキャストサービスの配信"）および[RFC8115]（ "IPv4埋め込みマルチキャストのDHCPv6オプション"をサポートする必要があります。およびユニキャストIPv6プレフィックス」）。
If the UPnP WANIPConnection:2 service [UPnP-WANIPC][OCF-IGD] is enabled on a CE router, but cannot be associated with an IPv4 interface established by an IPv4aaS mechanism or cannot determine which ports are available, an AddPortMapping() or AddAnyPortMapping() action MUST be rejected with error code 729 ("ConflictWithOtherMechanisms"). Port availability could be determined through PCP or access to a configured port set (if the IPv4aaS mechanism limits the available ports).
UPnP WANIPConnection：2サービス[UPnP-WANIPC] [OCF-IGD]がCEルーターで有効になっているが、IPv4aaSメカニズムによって確立されたIPv4インターフェースに関連付けることができないか、使用可能なポートを判別できない場合、AddPortMapping()またはAddAnyPortMapping()アクションは、エラーコード729（ "ConflictWithOtherMechanisms"）で拒否される必要があります。ポートの可用性は、PCPまたは構成されたポートセットへのアクセスを介して決定できます（IPv4aaSメカニズムが使用可能なポートを制限している場合）。
An AddPortMapping() request for a port that is not available MUST result in "ConflictInMappingEntry".
利用できないポートに対するAddPortMapping()リクエストは、 "ConflictInMappingEntry"を引き起こさなければなりません（MUST）。
An AddAnyPortMapping() request for a port that is not available SHOULD result in a successful mapping with an alternative "NewReservedPort" value from within the configured port set range or as assigned by PCP as per Section 5.6.1 of [RFC6970].
利用できないポートに対するAddAnyPortMapping()リクエストは、構成されたポートセット範囲内から、または[RFC6970]のセクション5.6.1に従ってPCPによって割り当てられた代替の「NewReservedPort」値でマッピングを成功させる必要があります（SHOULD）。
Note that IGD:1 and its WANIPConnection:1 service have been deprecated by OCF (Open Connectivity Foundation) [OCF-IGD].
IGD：1とそのWANIPConnection：1サービスは、OCF（Open Connectivity Foundation）[OCF-IGD]によって非推奨になっていることに注意してください。
This document doesn't include support for 6rd [RFC5969] because it is an IPv6-in-IPv4 tunneling.
このドキュメントはIPv6-in-IPv4トンネリングであるため、6rd [RFC5969]のサポートは含まれていません。
Regarding DS-LITE [RFC6333], this document includes slightly different requirements related to the support of PCP [RFC6887], IGD-PCP IWF [RFC6970], and the prioritization of the transition mechanisms, including dual-stack.
DS-LITE [RFC6333]に関して、このドキュメントには、PCP [RFC6887]、IGD-PCP IWF [RFC6970]のサポート、およびデュアルスタックを含む移行メカニズムの優先順位付けに関連するわずかに異なる要件が含まれています。
At the time of this writing, one of the apparent main issues for vendors with regard to including new functionalities, such as support for new transition mechanisms, is the lack of space in the flash (or equivalent) memory. However, it has been confirmed from existing open-source implementations (e.g., OpenWRT/LEDE, Linux, and VPP) that adding the support for the new transition mechanisms requires around 10-12 KBs because most of the code base is shared among several transition mechanisms, which are already supported by [RFC7084]. A single data plane is common to all of them, which typically means, in popular CEs already in the market [OpenWRT], the new required code is only about 0.15% of the total existing code size.
この記事の執筆時点で、新しい遷移メカニズムのサポートなど、新しい機能を含めることに関するベンダーの主な主な問題の1つは、フラッシュ（または同等の）メモリ内のスペースの不足です。ただし、既存のオープンソース実装（OpenWRT / LEDE、Linux、VPPなど）から、新しい移行メカニズムのサポートを追加するには、コードベースのほとんどが複数の移行で共有されるため、約10〜12 KBが必要であることが確認されています[RFC7084]ですでにサポートされているメカニズム。単一のデータプレーンはそれらすべてに共通です。つまり、一般に、すでに市場に出回っている一般的なCE [OpenWRT]では、新しく必要なコードは既存の合計コードサイズの約0.15％にすぎません。
In general, the new requirements don't have extra cost in terms of RAM memory, nor other hardware requirements such as more powerful CPUs, if compared to the cost of NAT44 code. Thus, existing hardware should be able to support all of them with minimal impact.
一般に、NAT44コードのコストと比較した場合、新しい要件には、RAMメモリの観点からの追加コストや、より強力なCPUなどの他のハードウェア要件はありません。したがって、既存のハードウェアは、最小限の影響ですべてをサポートできる必要があります。
The other issue seems to be the cost of developing the code for those new functionalities. However, at the time of writing this document, it has been confirmed that there are several open-source versions of the required code for supporting all the new transition mechanisms, and several vendors already have implementations and provided them to ISPs. Therefore, the development cost is negligible, and only integration and testing cost may become an issue.
もう1つの問題は、これらの新しい機能のコードを開発するコストです。ただし、このドキュメントの執筆時点では、すべての新しい移行メカニズムをサポートするために必要なコードのオープンソースバージョンがいくつかあることが確認されており、いくつかのベンダーはすでに実装を行っており、ISPに提供しています。したがって、開発コストはごくわずかであり、統合とテストのコストのみが問題になる可能性があります。
Finally, in some cases, operators supporting several transition mechanisms may need to consider training costs for staff in all the techniques for the operation and management of these mechanisms, even if the costs are not directly caused by supporting this document but because of business decisions.
最後に、いくつかのケースでは、いくつかの移行メカニズムをサポートするオペレーターは、これらのメカニズムの運用と管理のすべての手法について、スタッフのトレーニングコストを考慮する必要がある場合があります。
The IPv6 Transition CE Router must comply with the Security Considerations in [RFC7084] as well as those for each transition mechanism implemented by the IPv6 Transition CE Router.
IPv6移行CEルーターは、[RFC7084]のセキュリティに関する考慮事項、およびIPv6移行CEルーターによって実装される各移行メカニズムのセキュリティに関する考慮事項に準拠する必要があります。
As described in the Security Considerations of [RFC8026] and [RFC8415], there are generic DHCP security issues, which, in the case of this document, mean that malicious nodes may alter the priority of the transition mechanisms.
[RFC8026]および[RFC8415]のセキュリティに関する考慮事項で説明されているように、一般的なDHCPセキュリティの問題があります。これは、このドキュメントの場合、悪意のあるノードが移行メカニズムの優先度を変更する可能性があることを意味します。
Access network architecture for securing DHCP within the access network is out of scope for this document. Securing DHCP in the LAN is also not in scope. DHCP packets MUST NOT be forwarded between LAN and WAN interfaces of an IPv6 Transition CE Router.
アクセスネットワーク内でDHCPを保護するためのアクセスネットワークアーキテクチャは、このドキュメントの範囲外です。 LANでのDHCPの保護も対象外です。 DHCPパケットは、IPv6 Transition CEルーターのLANインターフェースとWANインターフェース間で転送してはなりません（MUST NOT）。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, <https://www.rfc-editor.org/info/rfc5625>.
[RFC5625] Bellis、R。、「DNSプロキシ実装ガイドライン」、BCP 152、RFC 5625、DOI 10.17487 / RFC5625、2009年8月、<https://www.rfc-editor.org/info/rfc5625>。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, DOI 10.17487/RFC5969, August 2010, <https://www.rfc-editor.org/info/rfc5969>.
[RFC5969] Townsley、W。およびO. Troan、「IPv4 Infrastructures on IPv4 Infrastructures（6rd）-Protocol Specification」、RFC 5969、DOI 10.17487 / RFC5969、2010年8月、<https：//www.rfc-editor。 org / info / rfc5969>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「ステートフルNAT64：IPv6クライアントからIPv4サーバーへのネットワークアドレスおよびプロトコル変換」、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<https： //www.rfc-editor.org/info/rfc6146>。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, <https://www.rfc-editor.org/info/rfc6147>.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P。、およびI. van Beijnum、「DNS64：DNS拡張機能によるIPv6クライアントからIPv4サーバーへのネットワークアドレス変換」、RFC 6147、DOI 10.17487 / RFC6147、4月2011、<https://www.rfc-editor.org/info/rfc6147>。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, <https://www.rfc-editor.org/info/rfc6333>.
[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4の枯渇に続くデュアルスタックLiteブロードバンドの展開」、RFC 6333、DOI 10.17487 / RFC6333、2011年8月、<https：/ /www.rfc-editor.org/info/rfc6333>。
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, DOI 10.17487/RFC6334, August 2011, <https://www.rfc-editor.org/info/rfc6334>.
[RFC6334] Hankins、D.、T。Mrugalski、「Dynamic Host Configuration Protocol for IPv6（DHCPv6）Option for Dual-Stack Lite」、RFC 6334、DOI 10.17487 / RFC6334、2011年8月、<https：//www.rfc- editor.org/info/rfc6334>。
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <https://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月、<https：//www.rfc-editor .org / info / rfc6877>。
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <https://www.rfc-editor.org/info/rfc6887>.
[RFC6887] Wing、D.、Ed。、Cheshire、S.、Boucadair、M.、Penno、R.、and P. Selkirk、 "Port Control Protocol（PCP）"、RFC 6887、DOI 10.17487 / RFC6887、April 2013 、<https://www.rfc-editor.org/info/rfc6887>。
[RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, DOI 10.17487/RFC6970, July 2013, <https://www.rfc-editor.org/info/rfc6970>.
[RFC6970] Boucadair、M.、Penno、R。、およびD. Wing、「ユニバーサルプラグアンドプレイ（UPnP）インターネットゲートウェイデバイス-ポート制御プロトコルインターワーキング機能（IGD-PCP IWF）」、RFC 6970、DOI 10.17487 / RFC6970 、2013年7月、<https://www.rfc-editor.org/info/rfc6970>。
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, November 2013, <https://www.rfc-editor.org/info/rfc7050>.
[RFC7050] Savolainen、T.、Korhonen、J。、およびD. Wing、「IPv6アドレス合成に使用されるIPv6プレフィックスの発見」、RFC 7050、DOI 10.17487 / RFC7050、2013年11月、<https：//www.rfc -editor.org/info/rfc7050>。
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <https://www.rfc-editor.org/info/rfc7084>.
[RFC7084] Singh、H.、Beebee、W.、Donley、C。、およびB. Stark、「IPv6カスタマーエッジルーターの基本要件」、RFC 7084、DOI 10.17487 / RFC7084、2013年11月、<https：// www .rfc-editor.org / info / rfc7084>。
[RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)", RFC 7225, DOI 10.17487/RFC7225, May 2014, <https://www.rfc-editor.org/info/rfc7225>.
[RFC7225] Boucadair、M。、「Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol（PCP）」、RFC 7225、DOI 10.17487 / RFC7225、2014年5月、<https://www.rfc-editor.org/info/rfc7225 >。
[RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for the Port Control Protocol (PCP)", RFC 7291, DOI 10.17487/RFC7291, July 2014, <https://www.rfc-editor.org/info/rfc7291>.
[RFC7291] Boucadair、M.、Penno、R。、およびD. Wing、「ポート制御プロトコル（PCP）のDHCPオプション」、RFC 7291、DOI 10.17487 / RFC7291、2014年7月、<https：//www.rfc -editor.org/info/rfc7291>。
[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 7341, DOI 10.17487/RFC7341, August 2014, <https://www.rfc-editor.org/info/rfc7341>.
[RFC7341] Sun、Q.、Cui、Y.、Siodelski、M.、Krishnan、S.、I。Farrer、「DHCPv4-over-DHCPv6（DHCP 4o6）Transport」、RFC 7341、DOI 10.17487 / RFC7341、8月2014、<https://www.rfc-editor.org/info/rfc7341>。
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, <https://www.rfc-editor.org/info/rfc7596>.
[RFC7596] Cui、Y.、Sun、Q.、Boucadair、M.、Tsou、T.、Lee、Y.、I。Farrer、「Lightweight 4over6：An Extension to the Dual-Stack Lite Architecture」、RFC 7596 、DOI 10.17487 / RFC7596、2015年7月、<https://www.rfc-editor.org/info/rfc7596>。
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, <https://www.rfc-editor.org/info/rfc7597>.
[RFC7597] Troan、O.、Ed。、Dec、W.、Li、X.、Bao、C.、Matsushima、S.、Murakami、T.、and T. Taylor、Ed。、 "Mapping of Address and Portカプセル化あり（MAP-E）」、RFC 7597、DOI 10.17487 / RFC7597、2015年7月、<https://www.rfc-editor.org/info/rfc7597>。
[RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, <https://www.rfc-editor.org/info/rfc7598>.
[RFC7598] Mrugalski、T.、Troan、O.、Farrer、I.、Perreault、S.、Dec、W.、Bao、C.、Yeh、L。、およびX. Deng、「DHCPv6オプションfor Softwireの構成Address and Port-Mapped Clients」、RFC 7598、DOI 10.17487 / RFC7598、2015年7月、<https://www.rfc-editor.org/info/rfc7598>。
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015, <https://www.rfc-editor.org/info/rfc7599>.
[RFC7599] Li、X.、Bao、C.、Dec、W.、Ed。、Troan、O.、Matsushima S.、T。Murakami、「変換を使用したアドレスとポートのマッピング（MAP-T）」 、RFC 7599、DOI 10.17487 / RFC7599、2015年7月、<https://www.rfc-editor.org/info/rfc7599>。
[RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", RFC 7618, DOI 10.17487/RFC7618, August 2015, <https://www.rfc-editor.org/info/rfc7618>.
[RFC7618] Cui、Y.、Sun、Q.、Farrer、I.、Lee、Y.、Sun、Q。、およびM. Boucadair、「共有IPv4アドレスの動的割り当て」、RFC 7618、DOI 10.17487 / RFC7618、 2015年8月、<https://www.rfc-editor.org/info/rfc7618>。
[RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism", RFC 8026, DOI 10.17487/RFC8026, November 2016, <https://www.rfc-editor.org/info/rfc8026>.
[RFC8026] Boucadair、M。およびI. Farrer、「Unified IPv4-in-IPv6 Softwire Customer Premises Equipment（CPE）：A DHCPv6-Based Prioritization Mechanism」、RFC 8026、DOI 10.17487 / RFC8026、2016年11月、<https：/ /www.rfc-editor.org/info/rfc8026>。
[RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network", RFC 8114, DOI 10.17487/RFC8114, March 2017, <https://www.rfc-editor.org/info/rfc8114>.
[RFC8114] Boucadair、M.、Qin、C.、Jacquenet、C.、Lee、Y。、およびQ. Wang、「IPv6マルチキャストネットワークを介したIPv4クライアントへのIPv4マルチキャストサービスの配信」、RFC 8114、DOI 10.17487 / RFC8114、2017年3月、<https://www.rfc-editor.org/info/rfc8114>。
[RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017, <https://www.rfc-editor.org/info/rfc8115>.
[RFC8115] Boucadair、M.、Qin、J.、Tsou、T。、およびX. Deng、「DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes」、RFC 8115、DOI 10.17487 / RFC8115、2017年3月、<https ：//www.rfc-editor.org/info/rfc8115>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415] Mrugalski、T.、Siodelski、M.、Volz、B.、Yourtchenko、A.、Richardson、M.、Jiang、S.、Lemon、T。、およびT. Winters、「IPv6の動的ホスト構成プロトコル（DHCPv6）」、RFC 8415、DOI 10.17487 / RFC8415、2018年11月、<https://www.rfc-editor.org/info/rfc8415>。
[IPv6Survey] Palet Martinez, J., "Best Current Operational Practice for operators: IPv6 Prefix Assignment for end-customers -- persistent vs non-persistent and what size to choose", January 2018, <https://indico.uknof.org.uk/event/41/contribution/5/ material/slides/0.pdf>.
[IPv6Survey] Palet Martinez、J。、「オペレーター向けの現在のベストオペレーションプラクティス：エンドユーザー向けのIPv6プレフィックス割り当て-永続的vs非永続的、どのサイズを選択するか」、2018年1月、<https：//indico.uknof。 org.uk/event/41/contribution/5/ material / slides / 0.pdf>。
[OCF-IGD] Open Connectivity Foundation, "Internet Gateway Device (IGD) V 2.0", March 2015, <https://openconnectivity.org/developer/specifications/ upnp-resources/upnp/internet-gateway-device-igd-v-2-0>.
[OCF-IGD] Open Connectivity Foundation、「Internet Gateway Device（IGD）V 2.0」、2015年3月、<https://openconnectivity.org/developer/specifications/ upnp-resources / upnp / internet-gateway-device-igd- v-2-0>。
[OpenWRT] OpenWRT, "Packages", <https://openwrt.org/packages/start>.
[OpenWRT] OpenWRT、「パッケージ」、<https://openwrt.org/packages/start>。
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, <https://www.rfc-editor.org/info/rfc7788>.
[RFC7788] Stenberg、M.、Barth、S。、およびP. Pfister、「Home Networking Control Protocol」、RFC 7788、DOI 10.17487 / RFC7788、2016年4月、<https://www.rfc-editor.org/info / rfc7788>。
[UPnP-IGD] UPnP Forum, "InternetGatewayDevice:2 Device Template Version 1.01", December 2010, <http://upnp.org/specs/gw/ UPnP-gw-InternetGatewayDevice-v2-Device.pdf>.
[UPnP-IGD] UPnPフォーラム、「InternetGatewayDevice：2 Device Template Version 1.01」、2010年12月、<http://upnp.org/specs/gw/ UPnP-gw-InternetGatewayDevice-v2-Device.pdf>。
[UPnP-WANIPC] UPnP Forum, "WANIPConnection:2 Service", September 2010, <http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v2-Service.pdf>.
[UPnP-WANIPC] UPnPフォーラム、「WANIPConnection：2 Service」、2010年9月、<http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v2-Service.pdf>。
The situation of ongoing IPv6 deployment and a lack of IPv4 addresses is not happening at the same pace in every country and even within every country for every ISP. For different technical, financial, commercial/marketing, and socio-economic reasons, each network is transitioning at their own pace; the global transition timings cannot be reliably estimated.
進行中のIPv6の展開とIPv4アドレスの不足という状況は、すべての国で同じペースで起こっているわけではなく、すべての国ですべてのISPに起こっているわけではありません。さまざまな技術的、財務的、商業的/マーケティング的、および社会経済的理由により、各ネットワークは独自のペースで移行しています。グローバルな遷移タイミングを正確に推定することはできません。
Different studies (for example, [IPv6Survey]) also show that IPv6 deployment is a changing situation. In a single country, not all operators will necessarily provide IPv6 support. Consumers may also switch ISPs and use the same IPv6 Transition CE Router with either an ISP that provides IPv4-only or an ISP that provides IPv6 with IPv4aaS.
さまざまな調査（たとえば、[IPv6Survey]）も、IPv6の導入が変化する状況であることを示しています。単一の国では、必ずしもすべての事業者がIPv6サポートを提供するわけではありません。コンシューマは、ISPを切り替えて、IPv4のみを提供するISPまたはIPv6をIPv4aaSで提供するISPのいずれかと同じIPv6移行CEルーターを使用することもできます。
So, to cover all those evolving situations, an IPv6 Transition CE Router is required, at least from the perspective of transition support.
したがって、これらすべての進化する状況に対応するには、少なくとも移行サポートの観点から、IPv6移行CEルーターが必要です。
Moreover, because some services and service providers will remain IPv4-only for an undetermined period of time, IPv4 service continuity is required. Thus, there is a need for CEs to support IPv4aaS indefinitely.
さらに、一部のサービスとサービスプロバイダーは不確定な期間IPv4のみのままになるため、IPv4サービスの継続性が必要です。したがって、CEがIPv4aaSを無期限にサポートする必要があります。
Based on these premises, this document ensures that the IPv6 Transition CE Router allows the continued transition from networks that today may provide access with dual-stack or IPv6-in-IPv4 (as described in [RFC7084]) to networks that provide IPv6-only access with IPv4aaS.
これらの前提に基づいて、このドキュメントは、IPv6移行CEルーターが、デュアルスタックまたはIPv6-in-IPv4（[RFC7084]で説明されている）でアクセスを提供できるネットワークから、IPv6のみを提供するネットワークへの継続的な移行を可能にすることを保証しますIPv4aaSによるアクセス。
Considering that situation and different possible usage cases, the IPv6 Transition CE Router described in this document is expected to be used in residential/household; small office, home office (SOHO); and small/medium enterprise (SME). Common usage is any kind of Internet access (web, email, streaming, online gaming, etc.), and more advanced requirements include inbound connections (IP cameras, web, DNS, email, VPN, etc.).
この状況と考えられるさまざまな使用例を考慮して、このドキュメントで説明されているIPv6トランジションCEルーターは、住宅/家庭での使用が想定されています。小規模オフィス、ホームオフィス（SOHO）;中小企業（SME）。一般的な使用法は、あらゆる種類のインターネットアクセス（ウェブ、電子メール、ストリーミング、オンラインゲームなど）です。より高度な要件には、インバウンド接続（IPカメラ、ウェブ、DNS、電子メール、VPNなど）が含まれます。
The above is not intended to be a comprehensive list of all the possible usage cases, just an overview. In fact, combinations of the above usages are also possible, along with situations where the same CE is used at different times in different scenarios or even with different IPv4aaSes at different service providers.
上記は、考えられるすべての使用例の包括的なリストではなく、単なる概要です。実際、上記の使用法の組み合わせは、同じCEが異なるシナリオで異なる時間に使用される状況や、異なるサービスプロバイダーの異なるIPv4aaSでさえも可能です。
The mechanisms for allowing inbound connections are naturally available in any IPv6 router when using IPv6 Global Unicast Addresses (GUAs), unless they are blocked by firewall rules, which may require some manual configuration.
IPv6グローバルユニキャストアドレス（GUA）を使用する場合、インバウンド接続を許可するためのメカニズムは、ファイアウォールルールによってブロックされない限り、どのIPv6ルーターでも自然に利用できます。
However, in the case of IPv4aaS, because of the usage of private IPv4 addresses and NAT and depending on the specific transition mechanism, inbound connections typically require some degree of more complex manual configuration, such as setting up a DMZ, setting up virtual servers, or setting up port/protocol forwarding. In general, IPv4 CE Routers already provide a GUI, CLI, or API to manually configure them, or provide the possibility to set up the CE in bridge mode, so another Router behind the original CE, takes care of inbound connections. The requirements for that support are out of the scope of this document.
ただし、IPv4aaSの場合、プライベートIPv4アドレスとNATを使用しているため、特定の移行メカニズムによっては、インバウンド接続には通常、DMZの設定、仮想サーバーの設定など、ある程度複雑な手動設定が必要です。または、ポート/プロトコル転送を設定します。一般に、IPv4 CEルーターは、手動で構成するためのGUI、CLI、またはAPIをすでに提供しています。または、CEをブリッジモードで設定できるため、元のCEの背後にある別のルーターが受信接続を処理します。そのサポートの要件は、このドキュメントの範囲外です。
Who provides the IPv6 Transition CE Router is not relevant. In most cases, the service provider is responsible for provisioning/managing, at least on the WAN side. Commonly, the user has access to configure the LAN interfaces, firewall, DMZ, and many other features. However, in many cases, the user must supply or may replace the IPv6 Transition CE Router. This underscores the importance of the IPv6 Transition CE Routers fulfilling the requirements defined in this document.
誰がIPv6 Transition CEルーターを提供するかは関係ありません。ほとんどの場合、サービスプロバイダーは、少なくともWAN側でプロビジョニング/管理を担当します。通常、ユーザーはLANインターフェース、ファイアウォール、DMZ、およびその他の多くの機能を設定するためのアクセス権を持っています。ただし、多くの場合、ユーザーはIPv6 Transition CEルーターを提供するか、置き換える必要があります。これは、このドキュメントで定義されている要件を満たすIPv6トランジションCEルーターの重要性を強調しています。
The IPv6 Transition CE Router described in this document is not intended for usage in other scenarios, such as large enterprises, data centers, content providers, etc. Even if the documented requirements meet their needs, they may have additional requirements, which are out of the scope of this document.
このドキュメントで説明されているIPv6トランジションCEルーターは、大企業、データセンター、コンテンツプロバイダーなど、他のシナリオでの使用を目的としていません。このドキュメントの範囲。
An end-user network will likely support both IPv4 and IPv6 (see Section 1 and Appendix A). It is not expected that end users will change their existing network topology with the introduction of IPv6. There are some differences in how IPv6 works and is provisioned; these differences have implications for the network architecture.
エンドユーザーネットワークは、IPv4とIPv6の両方をサポートする可能性があります（セクション1と付録Aを参照）。 IPv6の導入により、エンドユーザーが既存のネットワークトポロジを変更することは想定されていません。 IPv6の動作とプロビジョニングにはいくつかの違いがあります。これらの違いは、ネットワークアーキテクチャに影響を与えます。
A typical IPv4 end-user network consists of a "plug and play" router with NAT functionality and a single link upstream, connected to the service provider network.
典型的なIPv4エンドユーザーネットワークは、NAT機能を備えた「プラグアンドプレイ」ルーターと、サービスプロバイダーネットワークに接続された単一のアップストリームで構成されます。
From the perspective of an IPv4 user behind an IPv6 Transition CE Router, this doesn't change.
IPv6移行CEルーターの背後にあるIPv4ユーザーの観点からは、これは変わりません。
However, while a typical IPv4 NAT deployment, by default, blocks all incoming connections and may allow opening of ports using a Universal Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD][OCF-IGD] or some other firewall control protocol, in the case of an IPv6-only access and IPv4aaS, that may not be feasible depending on specific transition mechanism details. PCP [RFC6887] may be an alternative solution.
ただし、通常のIPv4 NAT展開では、デフォルトですべての着信接続がブロックされ、ユニバーサルプラグアンドプレイインターネットゲートウェイデバイス（UPnP IGD）[UPnP-IGD] [OCF-IGD]またはその他のファイアウォールコントロールを使用してポートを開くことができる場合があります。 IPv6のみのアクセスとIPv4aaSの場合、プロトコルは特定の移行メカニズムの詳細によっては実行できない場合があります。 PCP [RFC6887]は代替ソリューションの可能性があります。
Another consequence of using IPv4 private address space in the end-user network is that it provides stable addressing; that is, it doesn't change, even when you change service providers, and the addresses are always usable even when the WAN interface is down or the customer edge router has not yet been provisioned. In the case of IPv6-only access, private IPv4 addresses are also available if the IPv4aaS transition mechanism keeps running the NAT interface towards the LAN side when the WAN interface is down.
エンドユーザーネットワークでIPv4プライベートアドレス空間を使用するもう1つの結果は、安定したアドレス指定を提供することです。つまり、サービスプロバイダーを変更してもアドレスは変更されず、WANインターフェイスがダウンしているか、カスタマーエッジルーターがまだプロビジョニングされていない場合でも、アドレスは常に使用可能です。 IPv6のみのアクセスの場合、WANインターフェースがダウンしているときにIPv4aaS移行メカニズムがNATインターフェースをLAN側に向けて実行し続けると、プライベートIPv4アドレスも利用できます。
More advanced routers support dynamic routing (which learns routes from other routers), and advanced end users can build arbitrary, complex networks using manual configuration of address prefixes combined with a dynamic routing protocol. Once again, this is true for both IPv4 and IPv6.
より高度なルーターは動的ルーティング（他のルーターからのルートを学習する）をサポートし、高度なエンドユーザーは動的ルーティングプロトコルと組み合わせたアドレスプレフィックスの手動構成を使用して任意の複雑なネットワークを構築できます。繰り返しますが、これはIPv4とIPv6の両方に当てはまります。
In general, the end-user network architecture for IPv6 should provide equivalent or better capabilities and functionality than the current IPv4 architecture.
一般に、IPv6のエンドユーザーネットワークアーキテクチャは、現在のIPv4アーキテクチャと同等以上の機能を提供する必要があります。
The end-user network is a stub network in the sense that is not providing transit to other external networks. However, HNCP [RFC7788] allows support for automatic provisioning of downstream routers. Figure 2 illustrates the model topology for the end-user network.
エンドユーザーネットワークは、他の外部ネットワークへのトランジットを提供しないという意味でスタブネットワークです。ただし、HNCP [RFC7788]では、ダウンストリームルーターの自動プロビジョニングをサポートできます。図2は、エンドユーザーネットワークのモデルトポロジを示しています。
+---------------+ \
| Service | \
| Provider | \
| Router | | Service
+-------+-------+ | Provider
| IPv6-only | Network
| Customer /
| Internet Connection /
| /
+------+--------+ \
| IPv6 | \
| Transition CE | \
| Router | |
+---+-------+---+ |
Network A | | Network B |
-+----------------+-+- -+---+-------------+- |
| | | | |
+---+------+ | +----+-----+ +-----+----+ |
| IPv6 | | | IPv4 | |IPv4/IPv6 | |
| Host | | | Host | | Host | |
+----------+ | +----------+ +----------+ | End-User
| | Network(s)
+------+--------+ |
| IPv6 | |
| Router | |
+------+--------+ |
Network C | |
-+-------------+--+- |
| | |
+---+------+ +----+-----+ |
| IPv6 | | IPv6 | /
| Host | | Host | /
+----------+ +----------+ /
Figure 2: Example of a Typical End-User Network
図2：一般的なエンドユーザーネットワークの例
This architecture describes the:
このアーキテクチャは以下を説明します：
o Basic capabilities of the IPv6 Transition CE Router
o IPv6トランジションCEルーターの基本機能
o Provisioning of the WAN interface connecting to the service provider
o サービスプロバイダーに接続するWANインターフェイスのプロビジョニング
o Provisioning of the LAN interfaces The IPv6 Transition CE Router may be manually configured in an arbitrary topology with a dynamic routing protocol or HNCP [RFC7788]. Automatic provisioning and configuration are described for a single IPv6 Transition CE Router only.
o LANインターフェースのプロビジョニングIPv6 Transition CEルーターは、動的ルーティングプロトコルまたはHNCP [RFC7788]を使用して、任意のトポロジで手動で構成できます。自動プロビジョニングと構成は、単一のIPv6トランジションCEルーターについてのみ説明されています。
Acknowledgements
謝辞
Thanks to Mikael Abrahamsson, Fred Baker, Mohamed Boucadair, Brian Carpenter, Lorenzo Colitti, Alejandro D'Egidio, Ian Farrer, Lee Howard, Richard Patterson, Barbara Stark, Ole Troan, and James Woodyatt for their review and comments in this and/or previous draft versions of this document. Thanks also for the Last Call reviews by Dan Romascanu (OPS-DIR); Christian Huitema (SEC-DIR); Daniele Ceccarelli (RTG-DIR); Martin Stiemerling (TSV-ART); Matthew Miller (Gen-ART); and Alissa Cooper, Benjamin Kaduk, Suresh Krishnan, Ben Campbell, Spencer Dawkins, Mirja Kuhlewind, and Adam Roach (all IESG).
this and / orのレビューとコメントについて、Mikael Abrahamsson、Fred Baker、Mohamed Boucadair、Brian Carpenter、Lorenzo Colitti、Alejandro D'Egidio、Ian Farrer、Lee Howard、Richard Patterson、Barbara Stark、Ole Troan、James Woodyattに感謝します。このドキュメントの以前のドラフトバージョン。 Dan Romascanu（OPS-DIR）によるLast Callのレビューもありがとうございます。クリスチャン・ウイテマ（SEC-DIR）;ダニエレ・セカレッリ（RTG-DIR）;マーティン・スティーマーリング（TSV-ART）;マシュー・ミラー（Gen-ART）;アリッサクーパー、ベンジャミンカドゥック、スレッシュクリシュナン、ベンキャンベル、スペンサードーキンス、ミルハクーレウィンド、アダムローチ（すべてIESG）。
Authors' Addresses
著者のアドレス
Jordi Palet Martinez The IPv6 Company Molino de la Navata, 75 La Navata - Galapagar, Madrid 28420 Spain
Jordi Palet Martinez The IPv6 Company Molino de la Navata、75 La Navata-Galapagar、Madrid 28420 Spain
Email: jordi.palet@theipv6company.com
URI: http://www.theipv6company.com/
Hans M.-H. Liu D-Link Systems, Inc. 17595 Mount Herrmann St. Fountain Valley, California 92708 United States of America
ハンスM.-H. Liu D-Link Systems、Inc. 17595 Mount Herrmann St. Fountain Valley、California 92708アメリカ合衆国
Email: hans.liu@dlinkcorp.com
URI: https://www.dlink.com/
Masanobu Kawashima NEC Platforms, Ltd. 2-3, Kanda-Tsukasamachi Chiyoda-ku, Tokyo 101-8532 Japan
まさのぶ かわしま ねＣ Ｐぁｔふぉｒｍｓ、 Ｌｔｄ。 ２ー３、 かんだーつかさまち ちよだーく、 ときょ １０１ー８５３２ じゃぱん
Email: kawashimam@vx.jp.nec.com
URI: https://www.necplatforms.co.jp/en/