[要約] RFC 9313は、IPv6トランジション技術を利用してIPv4-as-a-Service（IPv4aaS）を提供するための利点と欠点を検討し、ネットワークオペレーターが最適な技術を選択する際の参考情報を提供することを目的としています。
Internet Engineering Task Force (IETF) G. Lencse
Request for Comments: 9313 BUTE
Category: Informational J. Palet Martinez
ISSN: 2070-1721 The IPv6 Company
L. Howard
Retevia
R. Patterson
Sky UK
I. Farrer
Deutsche Telekom AG
October 2022
Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS)
IPv4-as-a-service（IPv4aas）のIPv6遷移技術の長所と短所
Abstract
概要
Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. These technologies have their advantages and disadvantages. Depending on existing topology, skills, strategy, and other preferences, one of these technologies may be the most appropriate solution for a network operator.
IPv6のみのアクセスおよび/またはコアネットワークを備えたISPSのIPv4-As-a-Service（IPv4AAS）を顧客に提供するために、いくつかのIPv6トランジションテクノロジーが開発されています。これらのテクノロジーには、利点と短所があります。既存のトポロジ、スキル、戦略、その他の好みに応じて、これらのテクノロジーの1つがネットワークオペレーターにとって最も適切なソリューションである可能性があります。
This document examines the five most prominent IPv4aaS technologies and considers a number of different aspects to provide network operators with an easy-to-use reference to assist in selecting the technology that best suits their needs.
このドキュメントでは、5つの最も顕著なIPV4AASテクノロジーを検証し、ネットワークオペレーターに、ニーズに最適なテクノロジーの選択を支援するための使いやすいリファレンスを提供するさまざまな側面を検討します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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）の製品です。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/rfc9313.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9313で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Overview of the Technologies
2.1. 464XLAT
2.2. Dual-Stack Lite
2.3. Lightweight 4over6
2.4. MAP-E
2.5. MAP-T
3. High-Level Architectures and Their Consequences
3.1. Service Provider Network Traversal
3.2. Network Address Translation among the Different IPv4aaS
Technologies
3.3. IPv4 Address Sharing
3.4. IPv4 Pool Size Considerations
3.5. CE Provisioning Considerations
3.6. Support for Multicast
4. Detailed Analysis
4.1. Architectural Differences
4.1.1. Basic Comparison
4.2. Trade-Off between Port Number Efficiency and Stateless
Operation
4.3. Support for Public Server Operation
4.4. Support and Implementations
4.4.1. Vendor Support
4.4.2. Support in Cellular and Broadband Networks
4.4.3. Implementation Code Sizes
4.5. Typical Deployment and Traffic Volume Considerations
4.5.1. Deployment Possibilities
4.5.2. Cellular Networks with 464XLAT
4.5.3. Wireline Networks with 464XLAT
4.6. Load Sharing
4.7. Logging
4.8. Optimization for IPv4-Only Devices and Applications
5. Performance Comparison
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
As the deployment of IPv6 continues to be prevalent, it becomes clearer that network operators will move to building single-stack IPv6 core and access networks to simplify network planning and operations. However, providing customers with IPv4 services continues to be a requirement for the foreseeable future. To meet this need, the IETF has standardized a number of different IPv4aaS technologies for this (see [LEN2019]) based on differing requirements and deployment scenarios.
IPv6の展開が引き続き普及しているため、ネットワークオペレーターがシングルスタックIPv6コアの構築に移行し、ネットワークの計画と運用を簡素化するためにネットワークにアクセスすることが明らかになります。ただし、IPV4サービスを顧客に提供することは、予見可能な将来の要件であり続けます。このニーズを満たすために、IETFは、さまざまな要件と展開シナリオに基づいて、このためのさまざまなIPv4AASテクノロジー（[LEN2019]を参照）を標準化しました。
The number of technologies that have been developed makes it time-consuming for a network operator to identify the most appropriate mechanism for their specific deployment. This document provides a comparative analysis of the most commonly used mechanisms to assist operators with this problem.
開発された技術の数は、ネットワークオペレーターが特定の展開に最も適切なメカニズムを特定するのに時間がかかります。このドキュメントは、この問題でオペレーターを支援するために最も一般的に使用されるメカニズムの比較分析を提供します。
Five different IPv4aaS solutions are considered:
5つの異なるIPv4AASソリューションが考慮されます。
1. 464XLAT [RFC6877]
1. 464xlat [rfc6877]
2. Dual-Stack Lite [RFC6333]
2. デュアルスタックライト[RFC6333]
3. Lightweight 4over6 (lw4o6) [RFC7596]
3. 軽量4Over6（LW4O6）[RFC7596]
4. Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597]
4. カプセル化による住所とポートのマッピング（MAP-E）[RFC7597]
5. Mapping of Address and Port using Translation (MAP-T) [RFC7599]
5. 翻訳を使用したアドレスとポートのマッピング（MAP-T）[RFC7599]
We note that [RFC6180] gives guidelines for using IPv6 transition mechanisms during IPv6 deployment; that document addresses a much broader topic, whereas this document focuses on a small part of it.
[RFC6180]は、IPv6の展開中にIPv6遷移メカニズムを使用するためのガイドラインを提供していることに注意してください。このドキュメントは、はるかに広いトピックに対応していますが、このドキュメントはそのほんの一部に焦点を当てています。
The following sections introduce the different technologies analyzed in this document and describe some of their most important characteristics.
次のセクションでは、このドキュメントで分析されたさまざまなテクノロジーを紹介し、最も重要な特性のいくつかについて説明します。
464XLAT may use double translation (stateless NAT46 + stateful NAT64) or single translation (stateful NAT64) depending on different factors, such as the use of DNS by the applications and the availability of a DNS64 function (in the host or service provider network).
464XLATは、アプリケーションによるDNSの使用やDNS64関数の可用性（ホストまたはサービスプロバイダーネットワーク）などのさまざまな要因に応じて、二重翻訳（Stateless Nat46 Stateful Nat64）または単一翻訳（Stateful Nat64）を使用できます。
The customer-side translator (CLAT) is located in the customer's device, and it performs stateless NAT46 translation [RFC7915] (more precisely, a stateless IP/ICMP translation from IPv4 to IPv6). IPv4-embedded IPv6 addresses [RFC6052] are used for both source and destination addresses. Commonly, a /96 prefix (either the 64:ff9b::/96 Well-Known Prefix (WKP) or a Network-Specific Prefix) is used as the IPv6 destination for the IPv4-embedded client traffic.
顧客側の翻訳者（CLAT）は顧客のデバイスにあり、Stateless Nat46翻訳[RFC7915]を実行します（より正確には、IPv4からIPv6へのステートレスIP/ICMP翻訳）。IPv4-Bedded IPv6アドレス[RFC6052]は、ソースアドレスと宛先アドレスの両方に使用されます。一般的に、A /96プレフィックス（64：FF9B :: /96有名なプレフィックス（WKP）またはネットワーク固有のプレフィックス）は、IPv4が埋め込まれたクライアントトラフィックのIPv6宛先として使用されます。
In deployments where NAT64 load balancing (see Section 4.2 of [RFC7269]) is enabled, multiple WKPs [RFC8215] may be used.
NAT64ロードバランシング（[RFC7269]のセクション4.2を参照）を有効にする展開では、複数のWKPS [RFC8215]を使用できます。
In the operator's network, the provider-side translator (PLAT) performs stateful NAT64 [RFC6146] to translate the traffic. The destination IPv4 address is extracted from the IPv4-embedded IPv6 packet destination address, and the source address is from a pool of public IPv4 addresses.
オペレーターのネットワークでは、プロバイダー側の翻訳者（PLAT）がステートフルNAT64 [RFC6146]を実行してトラフィックを翻訳します。宛先IPv4アドレスは、IPv4-埋め込まれたIPv6パケット宛先アドレスから抽出され、ソースアドレスはパブリックIPv4アドレスのプールからです。
Alternatively, when a dedicated /64 is not available for translation, the CLAT device uses a stateful NAT44 translation before the stateless NAT46 translation.
あるいは、専用 /64が翻訳に利用できない場合、CLATデバイスは、ステートレスNAT46翻訳の前にステートフルなNAT44翻訳を使用します。
In general, keeping state in devices close to the end-user network (i.e., at the CE (Customer Edge) router) is not perceived to be as problematic as keeping state in the operator's network.
一般に、エンドユーザーネットワーク（つまり、CE（カスタマーエッジ）ルーター）に近いデバイスの状態を維持することは、オペレーターのネットワークで状態を維持するほど問題があると認識されていません。
In typical deployments, 464XLAT is used together with DNS64 [RFC6147]; see Section 3.1.2 of [RFC8683]. When an IPv6-only client or application communicates with an IPv4-only server, the DNS64 server returns the IPv4-embedded IPv6 address of the IPv4-only server. In this case, the IPv6-only client sends out IPv6 packets, the CLAT functions as an IPv6 router, and the PLAT performs a stateful NAT64 for these packets. There is a single translation.
典型的な展開では、464xlatがDNS64 [RFC6147]と一緒に使用されます。[RFC8683]のセクション3.1.2を参照してください。IPv6のみのクライアントまたはアプリケーションがIPv4のみのサーバーと通信すると、DNS64サーバーはIPv4のみのサーバーのIPv4-埋め込みIPv6アドレスを返します。この場合、IPv6のみのクライアントはIPv6パケットを送信し、CLATはIPv6ルーターとして機能し、PLATはこれらのパケットに対してステートフルNAT64を実行します。単一の翻訳があります。
Similarly, when an IPv4-only client or application communicates with an IPv4-only server, the CLAT will statelessly translate to IPv6 so it can traverse the ISP network up to the PLAT (NAT64), which in turn will translate to IPv4.
同様に、IPv4のみのクライアントまたはアプリケーションがIPv4のみのサーバーと通信すると、CLATはIPv6にステクトレスに変換されるため、ISPネットワークをPLAT（NAT64）まで通過し、IPv4に翻訳します。
Alternatively, one can say that DNS64 + stateful NAT64 is used to carry the traffic of the IPv6-only client and the IPv4-only server, and the CLAT is used only for the IPv4 traffic from applications or devices that use literal IPv4 addresses or non-IPv6-compliant APIs.
あるいは、DNS64 Stateful Nat64は、IPv6のみのクライアントとIPv4のみのサーバーのトラフィックを運ぶために使用され、CLATは、文字通りのIPv4アドレスまたは以外のアプリケーションまたはデバイスからのIPv4トラフィックにのみ使用されると言えます。IPv6準拠のAPI。
Private +----------+ Translated +----------+ _______
+------+ IPv4 | CLAT | 4-6-4 | PLAT | ( IPv4 )
| IPv4 |------->| Stateless|------------>| Stateful +--( Internet )
|Device|<-------| NAT46 |<------------| NAT64 | (________)
+------+ +----------+ ^ +----------+
|
Operator IPv6
Network
Figure 1: Overview of the 464XLAT Architecture
図1：464xlatアーキテクチャの概要
Note: In mobile networks, the CLAT is commonly implemented in the user equipment (UE) or smartphone; please refer to Figure 2 in [RFC6877].
注：モバイルネットワークでは、CLATは一般にユーザー機器（UE）またはスマートフォンに実装されています。[RFC6877]の図2を参照してください。
Some NAT64 vendors support direct communication (that is, without translation) between two CLATs by means of hairpinning through the NAT64.
一部のNAT64ベンダーは、NAT64を介してヘアピニングを使用して、2つのクラット間の直接通信（つまり、翻訳なし）をサポートしています。
Dual-Stack Lite (DS-Lite) [RFC6333] was the first of the considered transition mechanisms to be developed. DS-Lite uses a Basic Bridging BroadBand (B4) function in the customer's CE router that encapsulates IPv4 in IPv6 traffic and sends it over the IPv6 native service provider network to an Address Family Transition Router (AFTR). The AFTR performs encapsulation/decapsulation of the 4in6 [RFC2473] traffic and translates the IPv4 source address in the inner IPv4 packet to a public IPv4 source address using a stateful NAPT44 [RFC2663] function.
デュアルスタックライト（DS-Lite）[RFC6333]は、開発される考慮された遷移メカニズムの最初のものでした。DS-Liteは、IPv6トラフィックのIPv4をカプセル化し、IPv6ネイティブサービスプロバイダーネットワークを介して住所ファミリートランジションルーター（AFTR）に送信する顧客のCEルーターで基本的なブリッジングブロードバンド（B4）機能を使用します。AFTRは、4IN6 [RFC2473]トラフィックのカプセル化/脱カプセル化を実行し、Stateful NAPT44 [RFC2663]関数を使用して、内部IPv4パケットのIPv4ソースアドレスをパブリックIPv4ソースアドレスに変換します。
+-------------+
Private +----------+ IPv4-in-IPv6|Stateful AFTR|
+------+ IPv4 | B4 | Tunnel |------+------+ _______
| IPv4 |------->| Encap./ |------------>|Encap.| | ( IPv4 )
|Device|<-------| Decap. |<------------| / | NAPT +--( Internet )
+------+ +----------+ ^ |Decap.| 44 | (________)
| +------+------+
Operator IPv6
Network
Figure 2: Overview of the DS-Lite Architecture
図2：DS-Liteアーキテクチャの概要
Some AFTR vendors support direct communication between two B4s by means of hairpinning through the AFTR.
一部のAFTRベンダーは、AFTRを介してヘアピニングを使用して、2つのB4間の直接通信をサポートしています。
Lightweight 4over6 (lw4o6) is a variant of DS-Lite. The main difference is that the stateful NAPT44 function is relocated from the centralized AFTR to the customer's B4 element (called an "lwB4"). The AFTR (called an "lwAFTR") function therefore only performs A+P (Address plus Port) routing [RFC6346] and 4in6 encapsulation/ decapsulation.
Lightweight 4Over6（LW4O6）は、DS-Liteのバリアントです。主な違いは、Stateful NAPT44関数が集中AFTRから顧客のB4要素（「LWB4」と呼ばれる）に移動されることです。したがって、AFTR（「LWAFTR」と呼ばれる）関数は、P（アドレスプラスポート）ルーティング[RFC6346]および4IN6カプセル化/脱カプセル化のみを実行します。
Routing to the correct client and IPv4 address sharing are achieved using the A+P model [RFC6346] of provisioning each lwB4 with a unique tuple of IPv4 address and a unique range of transport-layer ports. The client uses these for NAPT44.
正しいクライアントとIPv4アドレスの共有へのルーティングは、各LWB4のプロビジョニングのA Pモデル[RFC6346]を使用して、IPv4アドレスのユニークなタプルとユニークな輸送層ポートを提供します。クライアントはこれらをNAPT44に使用します。
The lwAFTR implements a binding table, which has a per-client entry linking the customer's source IPv4 address and an allocated range of transport-layer ports to their IPv6 tunnel endpoint address. The binding table allows egress traffic from customers to be validated (to prevent spoofing) and ingress traffic to be correctly encapsulated and forwarded. As there needs to be a per-client entry, an lwAFTR implementation needs to be optimized for performing a per-packet lookup on the binding table.
LWAFTRは、顧客のソースIPv4アドレスをリンクし、輸送層ポートの割り当て範囲をIPv6トンネルエンドポイントアドレスにリンクするクライアントごとのエントリを備えたバインディングテーブルを実装しています。バインディングテーブルにより、顧客からの出力トラフィックを検証し（スプーフィングを防ぐため）、トラフィックを正しくカプセル化および転送することができます。クライアントごとのエントリが必要であるため、LWAFTR実装は、バインディングテーブルでパケットごとの検索を実行するために最適化する必要があります。
Direct communication (that is, without translation) between two lwB4s is performed by hairpinning traffic through the lwAFTR.
2つのLWB4間の直接通信（つまり、翻訳なし）は、LWAFTRを介してトラフィックをヘアピニングすることにより実行されます。
+-------------+ +----------+
Private | lwB4 | IPv4-in-IPv6| Stateless|
+------+ IPv4 |------+------| Tunnel | lwAFTR | _______
| IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 )
|Device|<-------| NAPT | / |<------------|bind. tab +--( Internet )
+------+ | 44 |Decap.| ^ | routing) | (________)
+------+------+ | +----------+
Operator IPv6
Network
Figure 3: Overview of the lw4o6 Architecture
図3：LW4O6アーキテクチャの概要
Like 464XLAT (Section 2.1), MAP-E and MAP-T use IPv4-embedded IPv6 addresses [RFC6052] to represent IPv4 hosts outside the MAP domain.
464xlat（セクション2.1）と同様に、MAP-EおよびMAP-TはIPv4-埋め込みIPv6アドレス[RFC6052]を使用して、MAPドメインの外側のIPv4ホストを表します。
MAP-E and MAP-T use a stateless algorithm to embed portions of the customer's allocated IPv4 address (or part of an address with A+P routing) into the IPv6 prefix delegated to the client. This allows for large numbers of clients to be provisioned using a single MAP rule (called a "MAP domain"). The algorithm also allows direct IPv4 peer-to-peer communication between hosts provisioned with common MAP rules.
MAP-EとMAP-Tは、ステートレスアルゴリズムを使用して、顧客の割り当てられたIPv4アドレス（またはPルーティングのあるアドレスの一部）の一部をクライアントに委任されたIPv6プレフィックスに埋め込みます。これにより、単一のマップルール（「マップドメイン」と呼ばれる）を使用して、多数のクライアントをプロビジョニングできます。このアルゴリズムは、一般的なマップルールをプロビジョニングしたホスト間の直接的なIPv4ピアツーピア通信も可能にします。
The CE router typically performs stateful NAPT44 [RFC2663] to translate the private IPv4 source addresses and source ports into an address and port range defined by applying the MAP rule to the delegated IPv6 prefix. The client address/port allocation size is a configuration parameter. The CE router then encapsulates the IPv4 packet in an IPv6 packet [RFC2473] and sends it directly to another host in the MAP domain (for peer-to-peer) or to a Border Router (BR) if the IPv4 destination is not covered in one of the CE's MAP rules.
CEルーターは通常、Stateful NAPT44 [RFC2663]を実行して、マップルールを委任されたIPv6プレフィックスに適用して定義されたプライベートIPv4ソースアドレスとソースポートをアドレスとポート範囲に変換します。クライアントアドレス/ポート割り当てサイズは、構成パラメーターです。次に、CEルーターはIPv6パケット[RFC2473]のIPv4パケットをカプセル化し、IPv4宛先がカバーされていない場合、MAPドメインの別のホスト（ピアツーピア用）またはBorder Router（BR）に直接送信します。CEのマップルールの1つ。
The MAP BR is provisioned with the set of MAP rules for the MAP domains it serves. These rules determine how the MAP BR is to decapsulate traffic that it receives from the client, validate the source IPv4 address and transport-layer ports assigned, and calculate the destination IPv6 address for ingress IPv4 traffic.
マップBRは、提供するマップドメインのマップルールのセットでプロビジョニングされます。これらのルールは、マップBRがクライアントから受信するトラフィックを脱カプセル化する方法を決定し、割り当てられたソースIPv4アドレスと輸送層ポートを検証し、Ingress IPv4トラフィックの宛先IPv6アドレスを計算します。
+-------------+ +----------+
Private | MAP CE | IPv4-in-IPv6| Stateless|
+------+ IPv4 |------+------| tunnel | MAP BR | _______
| IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 )
|Device|<-------| NAPT | / |<------------|algorithm +--( Internet )
+------+ | 44 |Decap.| ^ | routing) | (________)
+------+------+ | +----------+
Operator IPv6
Network
Figure 4: Overview of the MAP-E Architecture
図4：MAP-Eアーキテクチャの概要
Some BR vendors support direct communication between two MAP CEs by means of hairpinning through the BR.
一部のBRベンダーは、BRを介してヘアピニングを使用して、2つのマップCE間の直接通信をサポートしています。
MAP-T uses the same mapping algorithm as MAP-E. The major difference is that double stateless translation (NAT46 in the CE and NAT64 in the BR) is used to traverse the ISP's IPv6 single-stack network. MAP-T can also be compared to 464XLAT when there is a double translation.
MAP-Tは、MAP-Eと同じマッピングアルゴリズムを使用します。主な違いは、ISPのIPv6シングルスタックネットワークを横断するために、二重のステートレス翻訳（CEのNAT46およびBRのNAT64）を使用していることです。MAP-Tは、二重変換がある場合は464xLatとも比較できます。
A MAP CE router typically performs stateful NAPT44 to translate traffic to a public IPv4 address and port range calculated by applying the provisioned Basic MAP Rule (BMR), which is a set of inputs to the algorithm, to the delegated IPv6 prefix. The CE then performs stateless translation from IPv4 to IPv6 [RFC7915]. The MAP BR is provisioned with the same BMR as the client, enabling the received IPv6 traffic to be translated (using stateless NAT64) back to the public IPv4 source address used by the client.
マップCEルーターは通常、Stateful NAPT44を実行して、プロビジョニングされた基本マップルール（BMR）を適用して計算されたパブリックIPv4アドレスとポート範囲にトラフィックを変換します。CEは、IPv4からIPv6 [RFC7915]へのステートレス翻訳を実行します。マップBRはクライアントと同じBMRでプロビジョニングされ、受信したIPv6トラフィックを（Stateless NAT64を使用して）翻訳して、クライアントが使用するパブリックIPv4ソースアドレスに戻すことができます。
Using translation instead of encapsulation also allows IPv4-only nodes to correspond directly with IPv6 nodes in the MAP-T domain that have IPv4-embedded IPv6 addresses.
カプセル化の代わりに翻訳を使用すると、IPv4のみのノードがIPv4-TドメインのIPv6ノードに直接対応することができます。
+-------------+ +----------+
Private | MAP CE | Translated | Stateless|
+------+ IPv4 |------+------| 4-6-4 | MAP BR | _______
| IPv4 |------->| |State-|------------>|(NAT64/A+P| ( IPv4 )
|Device|<-------| NAPT | less |<------------|algorithm +--( Internet )
+------+ | 44 |NAT46 | ^ | routing) | (________)
+------+------+ | +----------+
Operator IPv6
Network
Figure 5: Overview of the MAP-T Architecture
図5：MAP-Tアーキテクチャの概要
Some BR vendors support direct communication between two MAP CEs by means of hairpinning through the BR.
一部のBRベンダーは、BRを介してヘアピニングを使用して、2つのマップCE間の直接通信をサポートしています。
For the data plane, there are two approaches for traversing the IPv6 provider network:
データプレーンの場合、IPv6プロバイダーネットワークを通過するための2つのアプローチがあります。
* 4-6-4 translation
* 4-6-4翻訳
* 4in6 encapsulation
* 4IN6カプセル化
+====================+=========+=========+=======+=======+=======+
| | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T |
+====================+=========+=========+=======+=======+=======+
| 4-6-4 translation | X | | | | X |
+--------------------+---------+---------+-------+-------+-------+
| 4in6 encapsulation | | X | X | X | |
+--------------------+---------+---------+-------+-------+-------+
Table 1: Available Traversal Mechanisms
表1：利用可能なトラバーサルメカニズム
In the scope of this document, all of the encapsulation-based mechanisms use IP-in-IP tunneling [RFC2473]. This is a stateless tunneling mechanism that does not require any additional overhead.
このドキュメントの範囲では、すべてのカプセル化ベースのメカニズムがIP-in-IPトンネル[RFC2473]を使用しています。これは、追加のオーバーヘッドを必要としないステートレストンネルメカニズムです。
It should be noted that both of these approaches result in an increase in the size of the packet that needs to be transported across the operator's network when compared to native IPv4. 4-6-4 translation adds a 20-byte overhead (the 20-byte IPv4 header is replaced with a 40-byte IPv6 header). Encapsulation has a 40-byte overhead (an IPv6 header is prepended to the IPv4 header).
これらのアプローチの両方が、ネイティブIPv4と比較した場合、オペレーターのネットワーク全体で輸送する必要があるパケットのサイズが増加することに注意する必要があります。4-6-4翻訳は20バイトの概要を追加します（20バイトのIPv4ヘッダーは40バイトのIPv6ヘッダーに置き換えられます）。カプセル化には40バイトの概要があります（IPv6ヘッダーはIPv4ヘッダーに加えられます）。
The increase in packet size can become a significant problem if there is a link with a smaller MTU in the traffic path. This may result in the need for traffic to be fragmented at the ingress point to the IPv6 only domain (i.e., the NAT46 or 4in6 encapsulation endpoint). It may also result in the need to implement buffering and fragment reassembly in the PLAT/AFTR/lwAFTR/BR node.
トラフィックパスに小さなMTUとのリンクがある場合、パケットサイズの増加は重大な問題になる可能性があります。これにより、IPv6のみのドメイン（つまり、NAT46または4IN6カプセル化エンドポイント）のイングレスポイントでトラフィックを断片化する必要がある場合があります。また、PLAT/AFTR/LWAFTR/BRノードにバッファリングとフラグメントの再組み立てを実装する必要がある場合もあります。
The advice given in Section 8.3.1 of [RFC7597] is applicable to all of these mechanisms: It is strongly recommended that the MTU in the IPv6-only domain be well managed (it should have sufficiently large MTU to support tunneling and/or translation) and that the IPv6 MTU on the CE WAN-side interface be set so that no fragmentation occurs within the boundary of the IPv6-only domain.
[RFC7597]のセクション8.3.1に記載されているアドバイスは、これらすべてのメカニズムに適用できます。IPv6のみのドメインのMTUを適切に管理することを強くお勧めします（トンネルや翻訳をサポートするのに十分な大きさのMTUが必要です）およびCE WAN側インターフェイスのIPv6 MTUが設定されているため、IPv6のみのドメインの境界内でフラグメンテーションが発生しないように設定されています。
For the high-level solution of IPv6 service provider network traversal, MAP-T uses double stateless translation. The first translation is from IPv4 to IPv6 (NAT46) at the CE, and the second translation is from IPv6 to IPv4 (NAT64) at the service provider network.
IPv6サービスプロバイダーネットワークトラバーサルの高レベルソリューションの場合、MAP-Tは二重のステートレス翻訳を使用します。最初の翻訳は、CEのIPv4からIPv6（NAT46）へのもので、2番目の翻訳はサービスプロバイダーネットワークのIPv6からIPv4（NAT64）までです。
464XLAT may use double translation (stateless NAT46 + stateful NAT64) or single translation (stateful NAT64) depending on different factors, such as the use of DNS by the applications and the availability of a DNS64 function (in the host or in the service provider network). For deployment guidelines, please refer to [RFC8683].
464XLATは、アプリケーションによるDNSの使用やDNS64関数の利用可能性など、異なる要因（ホストまたはサービスプロバイダーネットワーク）に応じて、二重翻訳（Stateless NAT46 Stateful Nat64）または単一翻訳（Stateful Nat64）を使用する場合があります。。展開ガイドラインについては、[RFC8683]を参照してください。
The first step for the double translation mechanisms is a stateless NAT from IPv4 to IPv6 implemented as SIIT (Stateless IP/ICMP Translation Algorithm) [RFC7915], which does not translate IPv4 header options and/or multicast IP/ICMP packets. With encapsulation-based technologies, the header is transported intact, and multicast can also be carried.
二重変換メカニズムの最初のステップは、IPv4からSIIT（Stateless IP/ICMP翻訳アルゴリズム）[RFC7915]として実装されたIPv4からIPv6へのステートレスNATです。カプセル化ベースのテクノロジーを使用すると、ヘッダーはそのまま輸送され、マルチキャストも輸送できます。
Single and double translation results in native IPv6 traffic with a transport-layer next header. The fields in these headers can be used for functions such as hashing across equal-cost multipaths or Access Control List (ACL) filtering. Encapsulation technologies, in contrast, may hinder hashing algorithms or other functions relying on header inspection.
単一および二重変換により、輸送層の次のヘッダーを備えたネイティブIPv6トラフィックが発生します。これらのヘッダーのフィールドは、等しいコストマルチパスやアクセス制御リスト（ACL）フィルタリングをハッシュするなどの機能に使用できます。対照的に、カプセル化テクノロジーは、ヘッダー検査に依存しているハッシュアルゴリズムまたはその他の機能を妨げる可能性があります。
Solutions using double translation can only carry port-aware IP protocols (e.g., TCP and UDP) and ICMP when they are used with IPv4 address sharing (please refer to Section 4.3 for more details). Encapsulation-based solutions can also carry any other protocols over IP.
ダブル翻訳を使用したソリューションは、IPv4アドレス共有で使用される場合、ポートアウェアIPプロトコル（TCPやUDPなど）とICMPのみを搭載できます（詳細については、セクション4.3を参照してください）。カプセル化ベースのソリューションは、IPよりも他のプロトコルを運ぶこともできます。
An in-depth analysis of stateful NAT64 can be found in [RFC6889].
ステートフルNAT64の詳細な分析は、[RFC6889]に記載されています。
As stateful NAT interferes with the port numbers, [NAT-SUPP] explains how NATs can handle SCTP (Stream Control Transmission Protocol).
ステートフルNATがポート番号を妨げるように、[Nat-Supp]は、NATがSCTP（ストリーム制御伝送プロトコル）をどのように処理できるかを説明します。
As public IPv4 address exhaustion is a common motivation for deploying IPv6, transition technologies need to provide a solution that allows public IPv4 address sharing.
パブリックIPv4アドレスの疲労はIPv6を展開するための一般的な動機であるため、遷移テクノロジーはパブリックIPv4アドレス共有を可能にするソリューションを提供する必要があります。
In order to fulfill this requirement, a stateful NAPT function is a necessary function in all of the mechanisms. The major differentiator is where in the architecture this function is located.
この要件を満たすために、ステートフルなNAPT機能は、すべてのメカニズムに必要な機能です。主要な差別化要因は、アーキテクチャのこの機能の位置です。
The solutions compared by this document fall into two categories:
このドキュメントで比較されたソリューションは、2つのカテゴリに分類されます。
* Approaches based on Carrier-Grade NAT (CGN) (DS-Lite, 464XLAT)
* キャリアグレードNAT（CGN）（DS-Lite、464XLAT）に基づくアプローチ
* Approaches based on A+P (lw4o6, MAP-E, MAP-T)
* P（LW4O6、MAP-E、MAP-T）に基づくアプローチ
In the CGN-based model, a device such as a CGN/AFTR or NAT64 performs the NAPT44 function and maintains per-session state for all of the active client's traffic. The customer's device does not require per-session state for NAPT.
CGNベースのモデルでは、CGN/AFTRやNAT64などのデバイスがNAPT44関数を実行し、アクティブなクライアントのすべてのトラフィックに対してセッションごとの状態を維持します。顧客のデバイスは、NAPTにセッションごとの状態を必要としません。
In the A+P-based model, a device (usually a CE) performs stateful NAPT44 and maintains per-session state only for co-located devices, e.g., in the customer's home network. Here, the centralized network function (lwAFTR or BR) only needs to perform stateless encapsulation/decapsulation or NAT64.
A Pベースのモデルでは、デバイス（通常はCE）がStateful NAPT44を実行し、顧客のホームネットワークで、共同配置されたデバイスに対してのみセッションごとの状態を維持します。ここでは、集中ネットワーク関数（LWAFTRまたはBR）は、ステートレスカプセル化/脱カプセル化またはNAT64を実行するだけで済みます。
Issues related to IPv4 address-sharing mechanisms are described in [RFC6269] and should also be considered.
IPv4アドレス共有メカニズムに関連する問題は[RFC6269]で説明されており、考慮する必要があります。
The address-sharing efficiency of the five technologies is significantly different and is discussed in Section 4.2.
5つのテクノロジーのアドレス共有効率は大きく異なり、セクション4.2で説明しています。
Lw4o6, MAP-E, and MAP-T can also be configured without IPv4 address sharing; see the details in Section 4.3. However, in that case, there is no advantage in terms of public IPv4 address saving. In the case of 464XLAT, one-to-one mapping can also be achieved through EAMT (Explicit Address Mapping Table) [RFC7757].
LW4O6、MAP-E、およびMAP-Tは、IPv4アドレス共有なしで構成することもできます。セクション4.3の詳細を参照してください。ただし、その場合、パブリックIPv4アドレスの保存に関しては利点はありません。464xLatの場合、EAMT（明示的なアドレスマッピングテーブル）[RFC7757]を介して1対1のマッピングを実現できます。
Conversely, both MAP-E and MAP-T may be configured to provide more than one public IPv4 address (i.e., an address with an IPv4 prefix shorter than a /32) to customers.
逆に、MAP-EとMAP-Tの両方が、顧客に複数のパブリックIPv4アドレス（つまり、A /32よりも短いIPv4プレフィックスを持つアドレス）を提供するように構成できます。
Dynamic DNS issues in address-sharing contexts and their possible solutions using PCP (Port Control Protocol) are discussed in detail in [RFC7393].
アドレス共有コンテキストでの動的DNSの問題とPCP（ポート制御プロトコル）を使用した可能なソリューションについては、[RFC7393]で詳しく説明します。
In this section, we do some simple calculations regarding port numbers. However, technical limitations are not the only point to consider for port sharing; there are also local regulations and best current practices.
このセクションでは、ポート番号に関する簡単な計算を行います。ただし、ポート共有では技術的な制限が考慮すべきポイントではありません。また、現地の規制と最良の現在の慣行もあります。
Note: By "port numbers", we mean TCP/UDP port numbers or ICMP identifiers.
注：「ポート番号」とは、TCP/UDPポート番号またはICMP識別子を意味します。
In most networks, it is possible to use existing data about flows to Content Delivery Networks (CDNs), caches, or other well-known IPv6-enabled destinations to calculate the percentage of traffic that would turn into IPv6 if IPv6 is enabled on that network or on part of it.
ほとんどのネットワークでは、フローに関する既存のデータをコンテンツ配信ネットワーク（CDN）、キャッシュ、またはその他の有名なIPv6対応の宛先に使用して、IPv6がそのネットワークで有効になっている場合にIPv6に変わるトラフィックの割合を計算することができます。またはその一部。
Knowing that, it is possible to calculate the IPv4 pool size required for a given number of subscribers, depending on the IPv4aaS technology being used.
それを知って、使用されているIPv4AASテクノロジーに応じて、特定の数のサブスクライバーに必要なIPv4プールサイズを計算することができます。
According to [MIY2010], each user device (computer, tablet, smartphone) behind a NAT could simultaneously use up to 300 ports. (Table 1 of [MIY2010] lists the port number usage of various applications. According to [REP2014], the downloading of some web pages may consume up to 200 port numbers.) If the extended NAPT algorithm is used, which includes the full 5-tuple into the connection tracking table, then the port numbers are reused when the destinations are different. Therefore, we need to consider the number of "port-hungry" applications that are accessing the same destination simultaneously. We estimate that in the case of a residential subscriber, there will be typically no more than four port-hungry applications communicating with the same destination simultaneously, which is a total of 1,200 ports.
[MIY2010]によると、NATの背後にある各ユーザーデバイス（コンピューター、タブレット、スマートフォン）は、最大300ポートを同時に使用できます。（[MIY2010]の表1には、さまざまなアプリケーションのポート番号の使用法がリストされています。[Rep2014]によると、一部のWebページのダウンロードは最大200ポート番号を消費する場合があります。） - 接続トラッキングテーブルに押し込むと、宛先が異なるとポート番号が再利用されます。したがって、同じ宛先に同時にアクセスしている「ポートハングリー」アプリケーションの数を同時に考慮する必要があります。住宅サブスクライバーの場合、通常、同じ宛先と同時に通信する4つのポートに飢えたアプリケーションがあり、合計1,200ポートであると推定されます。
For example, if 80% of the traffic is expected towards IPv6 destinations, only 20% will actually be using IPv4 ports. Thus, in our example, 240 ports are required for each subscriber.
たとえば、トラフィックの80％がIPv6の宛先に向けて予想される場合、実際にIPv4ポートを使用するのは20％だけです。したがって、この例では、各サブスクライバーに240ポートが必要です。
From the 65,535 ports available per IPv4 address, we could even consider reserving 1,024 ports for customers that need EAMT entries for incoming connections to System ports (0-1023, also called "well-known ports") [RFC7605]. This means that 64,511 ports are actually available for each IPv4 address.
IPv4アドレスごとに利用可能な65,535ポートから、システムポートへの接続を着信するためにEAMTエントリ（「有名なポート」とも呼ばれる0-1023）[RFC7605] [RFC7605]を必要とする顧客向けに1,024ポートを予約することを検討することもできます。これは、64,511ポートが実際にIPv4アドレスごとに使用できることを意味します。
According to this, a /22 (1.024 public IPv4 addresses) will be sufficient for over 275,000 subscribers (1,024x64,511/240=275,246.93).
これによれば、A /22（1.024パブリックIPv4アドレス）は、275,000人以上の加入者（1,024x64,511 /240 = 275,246.93）に十分です。
Similarly, a /18 (16,384 public IPv4 addresses) will be sufficient for over 4,403,940 subscribers, and so on.
同様に、A /18（16,384のパブリックIPv4アドレス）は、4,403,940人以上の加入者などに十分です。
This is a conservative approach, which is valid in the case of 464XLAT because ports are assigned dynamically by the NAT64. Therefore, it is not necessary to consider if one user is actually using more or fewer ports; average values work well.
これは保守的なアプローチであり、ポートはNAT64によって動的に割り当てられているため、464XLATの場合に有効です。したがって、1人のユーザーが実際にポートを実際に使用しているかどうかを考慮する必要はありません。平均値はうまく機能します。
As the deployment of IPv6 progresses, the use of NAT64, and therefore of public IPv4 addresses, decreases (more IPv6 ports, fewer IPv4 ports). Thus, either more subscribers can be accommodated with the same number of IPv4 addresses or some of those addressed can be retired from the NAT64.
IPv6の展開が進むにつれて、Nat64の使用、したがってパブリックIPv4アドレスの使用が減少します（IPv6ポートの多く、IPv4ポートの数が少なくなります）。したがって、より多くのサブスクライバーを同じ数のIPv4アドレスで収容できるか、アドレス指定されたアドレスの一部をNAT64から廃止することができます。
For comparison, if dual-stack is being used, any given number of users will require the same number of public IPv4 addresses. For instance, a /14 will provide 262,144 IPv4 public addresses for 262,144 subscribers, versus 275,000 subscribers being served with only a /22.
比較のために、デュアルスタックが使用されている場合、任意の数のユーザーには同じ数のパブリックIPv4アドレスが必要になります。たとえば、A /14は、262,144の加入者に対して262,144のIPv4パブリックアドレスを提供します。これに対しては、A /22のみで275,000人の加入者が提供されます。
In the other IPv4aaS technologies, this calculation will only match if the assignment of ports per subscriber can be done dynamically, which is not always the case (depending on the vendor implementation).
他のIPV4AASテクノロジーでは、この計算は、サブスクライバーあたりのポートの割り当てを動的に実行できる場合にのみ一致します。これは常にそうではありません（ベンダーの実装に応じて）。
When dynamic assignment of addresses is not possible, an alternative approximation for the other IPv4aaS technologies must ensure a sufficient number of ports per subscriber. That means 1,200 ports, and typically, it comes to 2,000 ports in many deployments. In that case, assuming 80% is IPv6 traffic (as above), only 30 subscribers will be allowed per each IPv4 address; thus, the closer approximation to 275,000 subscribers per our example with 464XLAT (with a /22) will be using a /19, which serves 245,760 subscribers (a /19 has 8,192 addresses and 30 subscribers with 2,000 ports each per address).
アドレスの動的割り当てが不可能な場合、他のIPv4AASテクノロジーの代替近似は、サブスクライバーごとに十分な数のポートを確保する必要があります。つまり、1,200ポートを意味し、通常、多くの展開で2,000ポートになります。その場合、80％がIPv6トラフィック（上記のように）であると仮定すると、各IPv4アドレスごとに30人のサブスクライバーのみが許可されます。したがって、464XLAT（A /22）を使用した例に従って275,000人のサブスクライバーに近い275,000人のサブスクライバーがA /19を使用します。これは245,760人の加入者にサービスを提供します（A /19には8,192人のアドレスと30人のサブスクライバーがあり、各アドレスあたり2,000ポートがあります）。
If the CGN (in case of DS-Lite) or the CE (in case of lw4o6, MAP-E, and MAP-T) make use of a 5-tuple for tracking the NAT connections, the number of ports required per subscriber can be limited as low as four ports per subscriber. However, the practical limit depends on the desired limit for parallel connections that any single host behind the NAT can have to the same address and port in Internet. Note that it is becoming more common that applications use AJAX (Asynchronous JavaScript and XML) and similar mechanisms, so taking that extreme limit is probably not a safe choice.
CGN（DS-LITEの場合）またはCE（LW4O6、MAP-E、およびMAP-Tの場合）がNAT接続を追跡するために5タプルを使用している場合、サブスクライバーごとのポートの数は缶を使用できます。サブスクライバーあたり4ポートの低いポートに制限されます。ただし、実際の制限は、NATの背後にある単一のホストがインターネット内の同じアドレスとポートに対して持つことができる並列接続の目的の制限に依存します。アプリケーションがAjax（非同期JavaScriptとXML）および同様のメカニズムを使用することがより一般的になっているため、その極端な限界をとることはおそらく安全な選択ではないことに注意してください。
This feature of extremely reduced number of ports could also be used in case the CLAT-enabled CE with 464XLAT makes use of tracking the 5-tuple NAT connections and could also be further extended if the NAT64 also uses the 5-tuple.
464XLATを備えたCLAT対応CEが5タプルNAT接続の追跡を利用し、NAT64が5タプルも使用する場合、さらに拡張できる場合に、非常に減少したポート数のこの機能を使用できます。
Please also refer to [RFC6888] for in-depth information about the requirements for sizing CGN gateways.
また、CGNゲートウェイのサイジングの要件に関する詳細な情報については、[RFC6888]を参照してください。
All of the technologies require some provisioning of customer devices. The table below shows which methods currently have extensions for provisioning the different mechanisms.
すべてのテクノロジーには、顧客デバイスのいくつかのプロビジョニングが必要です。以下の表は、現在、さまざまなメカニズムをプロビジョニングするための拡張機能がある方法を示しています。
+==============+=========+=========+=========+==========+===========+
|Provisioning | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T |
|Method | | | | | |
+==============+=========+=========+=========+==========+===========+
|DHCPv6 | | X | X | X | X |
|[RFC8415] | | | | | |
+--------------+---------+---------+---------+----------+-----------+
|RADIUS | |[RFC6519]| X | X | X |
|[RFC8658] | | | | | |
+--------------+---------+---------+---------+----------+-----------+
|TR-069 | * | X | * | X | X |
|[TR-069] | | | | | |
+--------------+---------+---------+---------+----------+-----------+
|DNS64 | X | | | | |
|[RFC7050] | | | | | |
+--------------+---------+---------+---------+----------+-----------+
|YANG [RFC7950]|[RFC8512]|[RFC8513]|[RFC8676]|[RFC8676] | [RFC8676] |
+--------------+---------+---------+---------+----------+-----------+
|DHCP 4o6 | | | X | X | |
|[RFC7341] | | | | | |
+--------------+---------+---------+---------+----------+-----------+
Table 2: Available Provisioning Mechanisms
表2：利用可能なプロビジョニングメカニズム
*: Work started at Broadband Forum (2021)
*：ブロードバンドフォーラム（2021）で始まった作業
X: Supported by the provisioning method
X：プロビジョニング方法でサポートされています
The solutions covered in this document are all intended for unicast traffic. [RFC8114] describes a method for carrying encapsulated IPv4 multicast traffic over an IPv6 multicast network. This could be deployed in parallel to any of the operator's chosen IPv4aaS mechanism.
このドキュメントで説明されているソリューションはすべて、ユニキャストトラフィックを対象としています。[RFC8114]は、IPv6マルチキャストネットワーク上でカプセル化されたIPv4マルチキャストトラフィックを運ぶ方法を説明しています。これは、オペレーターが選択したIPv4AASメカニズムのいずれかと並行して展開できます。
The five IPv4aaS technologies can be classified based on two aspects:
5つのIPV4AASテクノロジーは、2つの側面に基づいて分類できます。
* Technology used for service provider network traversal. It can be single/double translation or encapsulation.
* サービスプロバイダーネットワークトラバーサルに使用される技術。単一/二重翻訳またはカプセル化にすることができます。
* Presence or absence of per-flow state in the operator network.
* オペレーターネットワークにおける流量あたりの状態の有無。
+====================+=========+=========+=======+=======+=======+
| | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T |
+====================+=========+=========+=======+=======+=======+
| Translation (T) or | T | E | E | E | T |
| Encapsulation (E) | | | | | |
+--------------------+---------+---------+-------+-------+-------+
| Presence (+) of | + | + | | | |
| Per-Flow State in | | | | | |
| Operator Network | | | | | |
+--------------------+---------+---------+-------+-------+-------+
Table 3: Basic Comparison among the Analyzed Technologies
表3：分析されたテクノロジー間の基本的な比較
464XLAT and DS-Lite use stateful NAPT at the PLAT and AFTR devices, respectively. This may cause scalability issues for the number of clients or volume of traffic, but it does not impose a limitation on the number of ports per user, as they can be allocated dynamically on-demand and the allocation policy can be centrally managed and adjusted.
464XLATとDS-LITEは、それぞれPlatおよびAFTRデバイスでステートフルなNAPTを使用しています。これにより、クライアント数やトラフィックの量のスケーラビリティの問題が発生する可能性がありますが、ユーザーあたりのポート数に制限を課すことはありません。これは、需要があり、割り当てポリシーを中央に管理および調整できるため、ユーザーあたりのポート数を割り当てることができます。
A+P-based mechanisms (lw4o6, MAP-E, and MAP-T) avoid using NAPT in the service provider network. However, this means that the number of ports provided to each user (and hence the effective IPv4 address-sharing ratio) must be pre-provisioned to the client.
Pベースのメカニズム（LW4O6、MAP-E、およびMAP-T）は、サービスプロバイダーネットワークでNAPTの使用を避けています。ただし、これは、各ユーザーに提供されるポートの数（したがって、有効なIPv4アドレス共有比率）をクライアントに事前に導入する必要があることを意味します。
Changing the allocated port ranges with A+P-based technologies requires more planning and is likely to involve reprovisioning both hosts and operator-side equipment. It should be noted that due to the per-customer binding table entry used by lw4o6, a single customer can be reprovisioned (e.g., if they request a full IPv4 address) without needing to change parameters for a number of customers as in a MAP domain.
Pベースのテクノロジーで割り当てられたポート範囲を変更するには、より多くの計画が必要であり、ホストとオペレーター側の両方の機器の両方を再確認する必要があります。LW4O6が使用する顧客ごとのバインディングテーブルエントリにより、単一の顧客を、MAPドメインのように多くの顧客のパラメーターを変更する必要なく、単一の顧客を非難することができることに注意してください。。
It is also worth noting that there is a direct relationship between the efficiency of public port allocations for customers and the corresponding logging overhead that may be necessary to meet data-retention requirements. This is considered in Section 4.7.
また、顧客のパブリックポート配分の効率と、データ - 保持要件を満たすために必要な対応する伐採オーバーヘッドとの間に直接的な関係があることも注目に値します。これはセクション4.7で考慮されます。
Determining the optimal number of ports for a fixed port set is not an easy task and may also be impacted by local regulatory law (and in the Belgian case, it is not a law but more a memorandum of understanding or best current practice), which may define a maximum number of users per IP address and consequently a minimum number of ports per user.
固定されたポートセットの最適なポート数を決定することは簡単な作業ではなく、地元の規制法（そしてベルギーの場合、それは法律ではなく、より多くの理解または最良の現在の慣行）の影響を受ける可能性があります。IPアドレスごとに最大数のユーザーを定義し、その結果、ユーザーごとに最低数のポートを定義できます。
On the one hand, the "lack of ports" situation may cause serious problems in the operation of certain applications. For example, Miyakawa has demonstrated the consequences of the session number limitation due to port number shortage in the example of Google Maps [MIY2010]. When the limit was 15, several blocks of the map were missing, and the map was unusable. This study also provided several examples for the session numbers of different applications (the highest one was Apple's iTunes at 230-270 ports).
一方では、「ポートの不足」状況は、特定のアプリケーションの運用に深刻な問題を引き起こす可能性があります。たとえば、宮川は、Googleマップ[MIY2010]の例でのポート番号不足によるセッション番号制限の結果を実証しています。制限が15の場合、マップの数ブロックが欠落しており、マップは使用できませんでした。この調査では、さまざまなアプリケーションのセッション番号についてもいくつかの例を提供しました（最高のアプリケーションは230-270ポートのAppleのiTunesでした）。
The port number consumption of different applications is highly varying. In the case of web browsing, it depends on several factors, including the choice of the web page, the web browser, and sometimes the operating system [REP2014]. For example, under certain conditions, 120-160 ports were used (URL: sohu.com, browser: Firefox under Ubuntu Linux), and in some other cases, only 3-12 ports were used (URL: twitter.com, browser: Iceweasel under Debian Linux).
さまざまなアプリケーションのポート番号の消費は非常にさまざまです。Webブラウジングの場合、Webページ、Webブラウザー、時にはオペレーティングシステム[Rep2014]の選択など、いくつかの要因に依存します。たとえば、特定の条件下では、120〜160ポートが使用され（url：sohu.com、ブラウザー：ubuntu linux下のFirefox）、他の場合は3〜12ポートのみが使用されました（url：twitter.com、ブラウザー：Debian Linuxの下のIceweasel）。
There may be several users behind a CE router, especially in the broadband case (e.g., Internet is used by different members of a family simultaneously), so sufficient ports must be allocated to avoid impacting user experience.
CEルーターの背後には、特にブロードバンドのケースでは複数のユーザーがいる可能性があります（たとえば、インターネットは同時に家族のさまざまなメンバーが使用しているため、ユーザーエクスペリエンスに影響を与えないように十分なポートを割り当てる必要があります。
In general, assigning too few source port numbers to an end user may result in unexpected and hard-to-debug consequences; therefore, if the number of ports per end user is fixed, then we recommend assigning a conservatively large number of ports. For example, the developers of Jool used 2048 ports per user in their example for MAP-T [JOOL-MAPT].
一般に、エンドユーザーにソースポート番号を割り当てるのが少なすぎると、予期せぬ困難な結果が生じる可能性があります。したがって、エンドユーザーあたりのポート数が修正されている場合は、控えめに多数のポートを割り当てることをお勧めします。たとえば、Joolの開発者は、Map-T [Jool-Mapt]の例でユーザーごとに2048ポートを使用しました。
However, assigning too many ports per CE router will result in waste of public IPv4 addresses, which are scarce and expensive resources. Clearly, this is a big advantage in the case of 464XLAT where they are dynamically managed so that the number of IPv4 addresses for the sharing pool is smaller while the availability of ports per user doesn't need to be pre-defined and is not a limitation.
ただし、CEルーターごとにポートが多すぎると、パブリックIPv4アドレスが無駄になります。これは、希少で高価なリソースです。明らかに、これは464XLATの場合には大きな利点です。これらの場合、それらは動的に管理されているため、共有プールのIPv4アドレスの数が小さくなりますが、ユーザーあたりのポートの可用性は事前に定義する必要はなく、制限。
There is a direct trade-off between the optimization of client port allocations and the associated logging overhead. Section 4.7 discusses this in more depth.
クライアントポート割り当ての最適化と関連するロギングオーバーヘッドとの間には、直接的なトレードオフがあります。セクション4.7では、これをより深く説明します。
We note that common NAT44 implementations utilizing Netfilter at the CE router multiplex active sessions using a 3-tuple (source address, destination address, and destination port). This means that external source ports can be reused for unique internal source and destination addresses and port sessions. It is also noted that Netfilter cannot currently make use of multiple source port ranges (i.e., several blocks of ports distributed across the total port space as is common in MAP deployments). This may influence the design when using stateless technologies.
3タプル（ソースアドレス、宛先アドレス、および宛先ポート）を使用して、CEルーターマルチプレックスアクティブセッションでNetFilterを使用する一般的なNAT44実装があることに注意してください。これは、外部のソースポートを、一意の内部ソースおよび宛先アドレスとポートセッションのために再利用できることを意味します。また、NetFilterは現在、複数のソースポート範囲を使用できないことにも注意してください（つまり、マップの展開で一般的であるように、総ポートスペースに分布するポートの数ブロック）。これは、ステートレステクノロジーを使用するときに設計に影響を与える可能性があります。
Stateful technologies, 464XLAT, DS-Lite, and NAT444 can therefore be much more efficient in terms of port allocation and thus public IP address saving. The price is the stateful operation in the service provider network, which allegedly does not scale up well. It should be noted that, in many cases, all those factors may depend on how it is actually implemented.
したがって、ステートフルテクノロジー、464XLAT、DS-LITE、およびNAT444は、ポート割り当て、したがってパブリックIPアドレスの節約に関してはるかに効率的です。価格は、サービスプロバイダーネットワークでのステートフル運用であり、言われていると言われています。多くの場合、これらすべての要因が実際にどのように実装されるかに依存する可能性があることに注意する必要があります。
Measurements have been started to examine the scalability of a few stateful solutions in two areas:
2つの領域でのいくつかのステートフルソリューションのスケーラビリティを調べるために測定が開始されました。
* How their performance scales up with the number of CPU cores
* CPUコアの数でパフォーマンスがどのように拡大するか
* To what extent their performance degrades with the number of concurrent connections
* 同時接続の数で彼らのパフォーマンスがどの程度低下するか
The details of the measurements and their results are available from [IPv4aaS-SCALE-TECH].
測定とその結果の詳細は、[IPv4aas-Scale-Tech]から入手できます。
We note that some CGN-type solutions can allocate ports dynamically "on the fly". Depending on configuration, this can result in the same customer being allocated ports from different source addresses. This can cause operational issues for protocols and applications that expect multiple flows to be sourced from the same address (e.g., ECMP hashing, STUN, gaming, and content delivery networks). However, it should be noted that this is the same problem when a network has a NAT44 with multiple public IPv4 addresses, or even when applications in a dual-stack case, behave wrongly if Happy Eyeballs is flapping the flow address between IPv4 and IPv6.
一部のCGNタイプのソリューションでは、ポートを「その場で」動的に割り当てることができることに注意してください。構成によっては、同じ顧客が異なるソースアドレスからポートを割り当てられる可能性があります。これにより、同じアドレス（ECMPハッシュ、スタン、ゲーム、コンテンツ配信ネットワークなど）から複数のフローが供給されると予想されるプロトコルとアプリケーションの運用上の問題を引き起こす可能性があります。ただし、これは、ネットワークに複数のパブリックIPv4アドレスを備えたNAT44を搭載している場合、またはデュアルスタックの場合のアプリケーションがHappy EyeballsがIPv4とIPv6の間のフローアドレスを羽ばたく場合でも誤って動作する場合でも、同じ問題であることに注意してください。
The consequences of IPv4 address sharing [RFC6269] may impact all five technologies. However, when ports are allocated statically, more customers may get ports from the same public IPv4 address, which may result in negative consequences with higher probability. For example, many applications and service providers (Sony PlayStation Network, OpenDNS, etc.) can permanently block IPv4 ranges if they detect that they are used for address sharing.
IPv4アドレス共有[RFC6269]の結果は、5つのテクノロジーすべてに影響を与える可能性があります。ただし、ポートが静的に割り当てられている場合、より多くの顧客が同じパブリックIPv4アドレスからポートを取得する可能性があり、より高い確率でマイナスの結果をもたらす可能性があります。たとえば、多くのアプリケーションとサービスプロバイダー（Sony PlayStation Network、OpenDnsなど）は、アドレス共有に使用されていることを検出すると、IPv4範囲を永続的にブロックできます。
Both cases are, again, implementation-dependent.
どちらの場合も、実装に依存します。
We note that although it is not of typical use, one can do deterministic, stateful NAT and reserve a fixed set of ports for each customer as well.
典型的な使用ではありませんが、決定論的でステートフルなNATを行い、各顧客に固定されたポートセットを予約できることに注意してください。
Mechanisms that rely on operator-side per-flow state do not, by themselves, offer a way for customers to present services on publicly accessible transport-layer ports.
オペレーターサイドあたりの状態に依存するメカニズムは、それ自体では、顧客が公開されている輸送層ポートでサービスを提示する方法を提供しません。
The Port Control Protocol (PCP) [RFC6887] provides a mechanism for a client to request an external public port from a CGN device. For server operation, it is required with 464XLAT/NAT64, and it is supported in some DS-Lite AFTR implementations.
ポート制御プロトコル（PCP）[RFC6887]は、クライアントがCGNデバイスから外部パブリックポートを要求するメカニズムを提供します。サーバーの操作には、464XLAT/NAT64で必要であり、一部のDS-Lite AFTR実装でサポートされています。
A+P-based mechanisms distribute a public IPv4 address and restricted range of transport-layer ports to the client. In this case, it is possible for the user to configure their device to offer a publicly accessible server on one of their allocated ports. It should be noted that operators commonly do not assign the well-known ports to users (unless they are allocating a full IPv4 address), so the user will need to run the service on an allocated port or configure port translation.
Pベースのメカニズムは、パブリックIPv4アドレスと制限された輸送層ポートをクライアントに配布します。この場合、ユーザーがデバイスを構成して、割り当てられたポートのいずれかで公開されているサーバーを提供することができます。オペレーターは一般に、よく知られているポートをユーザーに割り当てないことに注意する必要があります（完全なIPv4アドレスを割り当てている場合を除く）。そのため、ユーザーは割り当てられたポートでサービスを実行するか、ポート翻訳を構成する必要があります。
Lw4o6, MAP-E, and MAP-T may be configured to allocated clients with a full IPv4 address, allowing exclusive use of all ports and non-port-based transport-layer protocols. Thus, they may also be used to support server/services operation on their default ports. However, when public IPv4 addresses are assigned to the CE router without address sharing, there is obviously no advantage in terms of IPv4 public addresses saving.
LW4O6、MAP-E、およびMAP-Tは、完全なIPv4アドレスを持つクライアントに割り当てられたクライアントに構成され、すべてのポートと非ポートベースの輸送レイヤープロトコルを排他的に使用できるようにすることができます。したがって、デフォルトのポートでサーバー/サービス操作をサポートするためにも使用できます。ただし、アドレス共有なしでパブリックIPv4アドレスがCEルーターに割り当てられている場合、IPv4パブリックアドレスの保存に関しては明らかに利点はありません。
It is also possible to configure specific ports mapping in 464XLAT/ NAT64 using EAMT [RFC7757], which means that only those ports are "lost" from the pool of addresses, so there is a higher maximization of the total usage of IPv4 port resources.
また、EAMT [RFC7757]を使用して464XLAT/ NAT64で特定のポートマッピングを構成することも可能です。つまり、これらのポートのみが住所のプールから「失われ」られているため、IPv4ポートリソースの合計使用量の最大化が高くなります。
In general, router vendors support AFTR, MAP-E BR, MAP-T BR, and NAT64. Vendors of load balancers and firewalls usually support NAT64 as well while not all of them have support for the other protocols.
一般に、ルーターベンダーはAFTR、MAP-E BR、MAP-T BR、およびNAT64をサポートしています。ロードバランサーとファイアウォールのベンダーは通常、NAT64もサポートしますが、それらのすべてが他のプロトコルをサポートしているわけではありません。
A 464XLAT client (CLAT) is implemented in Windows 10, Linux (including Android), Windows Mobile, Chrome OS, and iOS, but it is not available in macOS 12.3.1.
464XLATクライアント（CLAT）は、Windows 10、Linux（Androidを含む）、Windows Mobile、Chrome OS、およびiOSに実装されていますが、MacOS 12.3.1では使用できません。
The remaining four solutions are commonly deployed as functions in the CE device only; however, the vendors' support is poor in general (except for DS-Lite).
残りの4つのソリューションは、一般にCEデバイスの関数としてのみ展開されます。ただし、ベンダーのサポートは一般的に貧弱です（DS-Liteを除く）。
OpenWRT is a Linux-based open-source OS designed for CE devices. It offers a number of different 'opkg' packages as part of the distribution:
OpenWRTは、CEデバイス向けに設計されたLinuxベースのオープンソースOSです。配布の一部として、さまざまな「OPKG」パッケージを提供します。
* '464xlat' enables support for 464XLAT CLAT functionality.
* 「464xlat」は、464xlat CLAT機能のサポートを可能にします。
* 'ds-lite' enables support for DSLite B4 functionality.
* 「DS-Lite」は、DSLITE B4機能のサポートを可能にします。
* 'map' enables support for MAP-E and lw4o6 CE functionality.
* 「MAP」により、MAP-EおよびLW4O6 CE機能のサポートが可能になります。
* 'map-t' enables support for MAP-T CE functionality.
* 「MAP-T」は、MAP-T CE機能のサポートを可能にします。
At the time of publication, some free open-source implementations exist for the operator-side functionality:
出版時には、オペレーター側の機能には無料のオープンソース実装が存在します。
* Jool [JOOL] (CLAT, NAT64, EAMT, MAP-T CE, MAP-T BR)
* Jool [Jool]（Clat、Nat64、Eamt、Map-T CE、Map-T BR）
* VPP/fd.io [VPP] (MAP-BR, lwAFTR, CGN, CLAT, NAT64)
* vpp/fd.io [vpp]（map-br、lwaftr、cgn、clat、nat64）
* Snabb [SNABB] (lwAFTR)
* snabb [snabb]（lwaftr）
* AFTR [AFTR] (DSLite AFTR)
* 後[後]（ds lite aftr）
Several cellular networks use 464XLAT, whereas there are no deployments of the four other technologies in cellular networks, as they are neither standardized nor implemented in UE devices.
いくつかのセルラーネットワークは464XLATを使用していますが、Cellularネットワーク内の4つの他のテクノロジーの展開はありません。これは、UEデバイスで標準化されていないか実装されていないためです。
In broadband networks, there are some deployments of 464XLAT, MAP-E, and MAP-T. Lw4o6 and DS-Lite have more deployments, with DS-Lite being the most common, but deployments of lw4o6 have been rapidly increasing in the last few years.
ブロードバンドネットワークでは、464xlat、Map-E、およびMap-Tのいくつかの展開があります。LW4O6とDS-Liteにはより多くの展開があり、DS-Liteが最も一般的ですが、LW4O6の展開はここ数年で急速に増加しています。
Please refer to Tables 2 and 3 of [LEN2019] for a limited set of deployment information.
限られた展開情報については、[LEN2019]の表2および3を参照してください。
As a hint to the relative complexity of the mechanisms, the code sizes reported from the OpenWRT implementations of each technology are 17 kB, 35 kB, 15 kB, 35 kB, and 48 kB for 464XLAT, lw4o6, DS-Lite, MAP-E, and MAP-T, respectively (see <https://openwrt.org/packages/start>).
メカニズムの相対的な複雑さのヒントとして、各テクノロジーのOpenWRT実装から報告されたコードサイズは、464XLAT、LW4O6、DS-Lite、MAP-Eの場合、17 KB、35 KB、15 KB、35 KB、および48 KBです。、およびMap-t（それぞれ<https://openwrt.org/packages/start>を参照）。
We note that the support for all five technologies requires a much smaller code size than the total sum of the above quantities, because they contain a lot of common functions (e.g., data plane is shared among several of them).
5つのテクノロジーすべてのサポートには、多くの一般的な関数が含まれているため、上記の量の合計よりもはるかに小さなコードサイズが必要であることに注意してください（たとえば、データプレーンはそれらのいくつかで共有されています）。
Theoretically, all five IPv4aaS technologies could be used together with DNS64 + stateful NAT64, as is done in 464XLAT. In this case, the CE router would treat the traffic between an IPv6-only client and IPv4-only server as normal IPv6 traffic, and the stateful NAT64 gateway would do a single translation, thus offloading this kind of traffic from the IPv4aaS technology. The cost of this solution would be the need to also deploy DNS64 + stateful NAT64.
理論的には、5つのIPV4AASテクノロジーはすべて、464XLATで行われるように、DNS64ステートフルNAT64と一緒に使用できます。この場合、CEルーターはIPv6のみのクライアントとIPv4のみのサーバー間のトラフィックを通常のIPv6トラフィックとして処理し、Stateful Nat64 Gatewayは単一の翻訳を行い、IPv4AASテクノロジーからこの種のトラフィックをオフロードします。このソリューションのコストは、DNS64 Stateful Nat64を展開する必要があります。
However, this has not been implemented in clients or actual deployments, so only 464XLAT always uses this optimization, and the other four solutions do not use it at all.
ただし、これはクライアントや実際の展開に実装されていないため、常にこの最適化を使用しているのは464xLatのみであり、他の4つのソリューションはまったく使用していません。
Figures from existing deployments (through the end of 2018) show the typical traffic volumes in an IPv6-only cellular network when 464XLAT technology is used together with DNS64:
既存の展開の数値（2018年末まで）は、464XLATテクノロジーがDNS64と一緒に使用される場合、IPv6のみのセルラーネットワークの典型的なトラフィック量を示しています。
* 75% of traffic is IPv6 end-to-end (no translation).
* トラフィックの75％はIPv6エンドツーエンドです（翻訳なし）。
* 24% of traffic uses DNS64 + NAT64 (one translation).
* トラフィックの24％はDNS64 NAT64を使用しています（1つの翻訳）。
* Less than 1% of traffic uses the CLAT in addition to NAT64 (two translations), due to an IPv4 socket and/or IPv4 literal.
* IPv4ソケットおよび/またはIPv4リテラルにより、NAT64（2つの翻訳）に加えて、トラフィックの1％未満がCLATを使用しています。
Without using DNS64, 25% of the traffic would undergo double translation.
DNS64を使用せずに、トラフィックの25％が二重の翻訳を受けます。
Figures from several existing deployments (through the end of 2020), mainly with residential customers, show the ranges of typical traffic volumes in an IPv6-only network, when 464XLAT is used with DNS64:
主に住宅の顧客を抱えるいくつかの既存の展開の数値（2020年の終わりまで）は、464XLATがDNS64で使用される場合、IPv6のみのネットワークの典型的なトラフィック量の範囲を示しています。
* 65%-85% of traffic is IPv6 end-to-end (no translation).
* トラフィックの65％-85％はIPv6エンドツーエンドです（翻訳なし）。
* 14%-34% of traffic uses DNS64 + NAT64 (one translation).
* トラフィックの14％-34％はDNS64 NAT64を使用しています（1つの翻訳）。
* Less than 1-2% of traffic uses the CLAT in addition to NAT64 (two translations), due to an IPv4 socket and/or IPv4 literal.
* IPv4ソケットおよび/またはIPv4リテラルのため、トラフィックの1〜2％未満がNAT64（2つの翻訳）に加えてCLATを使用しています。
Without using DNS64, 16%-35% of the traffic would undergo double translation.
DNS64を使用せずに、トラフィックの16％〜35％が二重の翻訳を受けます。
This data is consistent with non-public information of actual deployments, which can be easily explained. When a wireline ISP has mainly residential customers, content providers and CDNs that are already IPv6 enabled (Google/YouTube, Netflix, Facebook, Akamai, etc.) typically account for 65-85% of the traffic in the network. Thus, when the subscribers are IPv6 enabled, about the same percentage of traffic will become IPv6.
このデータは、実際の展開の非公開情報と一致しており、簡単に説明できます。Wireline ISPには、主に住宅の顧客、コンテンツプロバイダー、およびすでにIPv6が有効になっているCDN（Google/YouTube、Netflix、Facebook、Akamaiなど）がある場合、通常、ネットワーク内のトラフィックの65〜85％を占めています。したがって、サブスクライバーがIPv6を有効にすると、ほぼ同じ割合のトラフィックがIPv6になります。
If multiple network-side devices are needed as PLAT/AFTR/BR for capacity, then there is a need for a load-sharing mechanism. ECMP (Equal-Cost Multipath) load sharing can be used for all technologies; however, stateful technologies will be impacted by changes in network topology or device failure.
複数のネットワーク側のデバイスが容量のためにPLAT/AFTR/BRとして必要な場合、負荷シェアリングメカニズムが必要です。ECMP（等しいマルチパス）負荷共有は、すべてのテクノロジーに使用できます。ただし、ステートフルなテクノロジーは、ネットワークトポロジまたはデバイスの障害の変更によって影響を受けます。
Technologies utilizing DNS64 can also distribute load across PLAT/ AFTR devices, evenly or unevenly, by using different prefixes. Different network-specific prefixes can be distributed for subscribers in appropriately sized segments (like split-horizon DNS, also called "DNS views").
DNS64を使用するテクノロジーは、異なるプレフィックスを使用して、Plat/ AFTRデバイスに均等または不均一に負荷を分配することもできます。適切なサイズのセグメント（「DNSビュー」とも呼ばれるスプリットホリゾンDNSなど）のサブスクライバーには、さまざまなネットワーク固有のプレフィックスを配布できます。
Stateless technologies, due to the lack of per-flow state, can make use of anycast routing for load sharing and resiliency across network devices, both ingress and egress; flows can take asymmetric paths through the network, i.e., in through one lwAFTR/BR and out via another.
フローごとの状態が不足しているため、ステートレステクノロジーは、イングレスと出口の両方で、ネットワークデバイス全体のロード共有と回復力のための任意のキャストルーティングを利用できます。フローは、ネットワークを介して非対称パス、つまり1つのLWAFTR/BRを介して別のLWAFTR/BRを介して取ることができます。
Mechanisms with centralized NAPT44 state have a number of challenges specifically related to scaling and resilience. As the total amount of client traffic exceeds the capacity of a single CGN instance, additional nodes are required to handle the load. Each CGN maintains a stateful table of active client sessions, and this table may need to be synchronized between CGN instances. This is necessary for two reasons:
集中化されたNAPT44状態を持つメカニズムには、スケーリングと回復力に特に関連する多くの課題があります。クライアントトラフィックの合計量が単一のCGNインスタンスの容量を超えるため、負荷を処理するには追加のノードが必要です。各CGNは、アクティブなクライアントセッションのステートフルテーブルを維持しており、このテーブルはCGNインスタンス間で同期する必要がある場合があります。これは、2つの理由で必要です。
* To prevent all active customer sessions from being dropped in the event of a CGN node failure.
* すべてのアクティブな顧客セッションがCGNノード障害の場合に削除されないようにするため。
* To ensure a matching state table entry for an active session in the event of asymmetric routing through different egress and ingress CGN nodes.
* さまざまな出力および侵入CGNノードを介して非対称ルーティングが発生した場合に、アクティブセッションの一致する状態テーブルエントリを確保します。
In the case of 464XLAT and DS-Lite, the user of any given public IPv4 address and port combination will vary over time; therefore, logging is necessary to meet data-retention laws. Each entry in the PLAT/ AFTR generates a logging entry. As discussed in Section 4.2, a client may open hundreds of sessions during common tasks such as web browsing, each of which needs to be logged so the overall logging burden on the network operator is significant. In some countries, this level of logging is required to comply with data-retention legislation.
464XLATおよびDS-LITEの場合、特定のパブリックIPv4アドレスとポートの組み合わせのユーザーは時間とともに異なります。したがって、データ - 保持法を満たすためにロギングが必要です。Plat/ AFTRの各エントリは、ロギングエントリを生成します。セクション4.2で説明したように、クライアントは、Webブラウジングなどの一般的なタスク中に数百のセッションを開くことができます。それぞれを記録する必要があるため、ネットワーク演算子の全体的なログの負担が大きくなります。一部の国では、このレベルの伐採は、データ保持法に準拠するために必要です。
One common optimization available to reduce the logging overhead is the allocation of a block of ports to a client for the duration of their session. This means that a logging entry only needs to be made when the client's port block is released, which dramatically reduces the logging overhead. This comes as the cost of less efficient public address sharing as clients need to be allocated a port block of a fixed size regardless of the actual number of ports that they are using.
ロギングオーバーヘッドを削減するために利用できる一般的な最適化の1つは、セッション中にクライアントにポートブロックを割り当てることです。これは、クライアントのポートブロックがリリースされたときにのみロギングエントリを作成する必要があることを意味します。これにより、ロギングのオーバーヘッドが劇的に減少します。これは、クライアントに使用しているポートの実際の数に関係なく、クライアントに固定サイズのポートブロックを割り当てる必要があるため、より効率の低いパブリックアドレス共有のコストとして発生します。
Stateless technologies that pre-allocate the IPv4 addresses and ports only require that copies of the active MAP rules (for MAP-E and MAP-T) or binding table (for lw4o6) are retained along with timestamp information of when they have been active. Support tools (e.g., those used to serve data-retention requests) may need to be updated to be aware of the mechanism in use (e.g., implementing the MAP algorithm so that IPv4 information can be linked to the IPv6 prefix delegated to a client). Stateless technologies do not have a centralized stateful element that customer traffic needs to pass through, so if data-retention laws mandate per-session logging, there is no simple way of meeting this requirement with a stateless technology alone. Thus, a centralized NAPT44 model may be the only way to meet this requirement.
IPv4アドレスとポートを事前に割り当てるステートレステクノロジーでは、アクティブなMAPルール（MAP-EおよびMAP-Tの場合）またはバインディングテーブル（LW4O6用）のコピーのみが、アクティブのタイムスタンプ情報とともに保持されます。サポートツール（データ保持要求を提供するために使用されるものなど）を更新する必要がある場合があります（例えば、IPv4情報がクライアントに委任されたIPv6プレフィックスにリンクできるようにマップアルゴリズムを実装する）。ステートレステクノロジーには、顧客のトラフィックが通過する必要がある集中的なステートフルな要素はありません。したがって、データ - 保持法がセッションごとのロギングを義務付けている場合、この要件をステートレステクノロジーだけで満たす簡単な方法はありません。したがって、集中化されたNAPT44モデルが、この要件を満たす唯一の方法かもしれません。
Deterministic CGN [RFC7422] was proposed as a solution to reduce the resource consumption of logging.
決定論的CGN [RFC7422]は、ロギングのリソース消費を減らすためのソリューションとして提案されました。
Please also refer to Section 4 of [RFC6888] for more information about requirements for logging CGN gateways.
CGNゲートウェイのロギングの要件の詳細については、[RFC6888]のセクション4を参照してください。
When IPv4-only devices or applications are behind a CE connected with IPv6-only and IPv4aaS, the IPv4-only traffic flows will necessarily be encapsulated/decapsulated (in the case of DS-Lite, lw4o6, and MAP-E) and will reach the IPv4 address of the destination, even if that service supports dual-stack. This means that the traffic flow will cross through the AFTR, lwAFTR, or BR, depending on the specific transition mechanism being used.
IPv4のみのデバイスまたはアプリケーションがIPv6のみおよびIPv4AASに接続されたCEの背後にある場合、IPv4のみのトラフィックフローは必然的にカプセル化/分裂されます（DS-Lite、LW4O6、およびMAP-Eの場合）そのサービスがデュアルスタックをサポートしていても、宛先のIPv4アドレスは宛先です。これは、使用されている特定の遷移メカニズムに応じて、トラフィックフローがAFTR、LWAFTR、またはBRを通過することを意味します。
Even if those services are directly connected to the operator network (e.g., CDNs and caches) or located internally (such as VoIP, etc.), it is not possible to avoid that overhead.
これらのサービスがオペレータネットワーク（CDNやキャッシュなど）に直接接続されている場合、または内部に配置されている場合（VoIPなど）、そのオーバーヘッドを回避することはできません。
However, in the case of those mechanisms that use a NAT46 function, in the CE (464XLAT and MAP-T), it is possible to take advantage of optimization functionalities, such as the ones described in [OP-464XLAT/MAP-T].
ただし、CE（464XLATおよびMAP-T）でNAT46関数を使用するメカニズムの場合、[OP-464XLAT/MAP-T]で説明されている機能などの最適化機能を活用することができます。。
Because the NAT46 has already translated the IPv4-only flow to IPv6 and the services are dual-stack, using these optimizations allows the services to be reached without the need to translate the flow back to IPv4.
NAT46はすでにIPv4のみのフローをIPv6に翻訳しており、サービスはデュアルスタックであるため、これらの最適化を使用すると、フローをIPv4に戻す必要なくサービスにアクセスできます。
We plan to compare the performances of the most prominent free software implementations of the five IPv6 transition technologies using the methodology described in "Benchmarking Methodology for IPv6 Transition Technologies" [RFC8219].
「IPv6遷移技術のベンチマーク方法論」[RFC8219]で説明されている方法論を使用して、5つのIPv6遷移テクノロジーの最も顕著なフリーソフトウェア実装のパフォーマンスを比較する予定です。
The dual Device Under Test (DUT) setup of [RFC8219] makes it possible to use the existing measurement devices compliant with "Benchmarking Methodology for Network Interconnect Devices" [RFC2544]; however, this solution has two kinds of limitations:
[RFC8219]のテスト中のデバイス（DUT）セットアップにより、「ネットワーク相互接続デバイスのベンチマーク方法論」[RFC2544]に準拠した既存の測定デバイスを使用することができます。ただし、このソリューションには2種類の制限があります。
* Dual DUT setup has the drawback that the performances of the CE and the ISP-side device (e.g., the CLAT and PLAT of 464XLAT) are measured together. In order to measure the performance of only one of them, we need to ensure that the desired one is the bottleneck.
* デュアルDUTセットアップには、CEとISP側のデバイスのパフォーマンス（たとえば、464XLATのCLATとPLAT）が一緒に測定されるという欠点があります。そのうちの1つだけのパフォーマンスを測定するには、目的のパフォーマンスがボトルネックであることを確認する必要があります。
* Measurement procedures for Packet Delay Variation (PDV) and Inter-Packet Delay Variation (IPDV) measurements are missing from the legacy devices, and the old measurement procedure for latency has been redefined in [RFC8219].
* パケット遅延変動（PDV）およびパケット間遅延変動（IPDV）測定の測定手順は、レガシーデバイスから欠落しており、遅延の古い測定手順は[RFC8219]で再定義されています。
The single DUT setup of [RFC8219] makes it possible to benchmark the selected device separately, but either special Tester is required or some trick is needed if we want to use legacy Testers. An example for the latter is our stateless NAT64 measurements testing Throughput and Frame Loss Rate using a legacy commercial Tester [LEN2020a] that is compliant with [RFC5180].
[RFC8219]の単一のDUTセットアップにより、選択したデバイスを個別にベンチマークすることができますが、レガシーテスターを使用する場合は、特別なテスターが必要です。後者の例は、[RFC5180]に準拠したレガシー商業テスター[LEN2020A]を使用したスループットとフレームの損失率をテストするステートレスNAT64測定のテストです。
Siitperf, a DPDK-based software Tester that is compliant with [RFC8219] and used for benchmarking stateless NAT64 gateways, has been developed recently. Siitperf is available from GitHub [SIITPERF] as free software and is documented in [LEN2021]. Originally, it literally followed the test frame format of [RFC2544], including "hard-wired" source and destination port numbers, and then it was complemented with the pseudorandom port feature required by [RFC4814]. The new version is documented in [LEN2020b].
[RFC8219]に準拠し、Stateless Nat64ゲートウェイのベンチマークに使用されるDPDKベースのソフトウェアテスターであるSiitperfが最近開発されました。siitperfは、Github [siitperf]からフリーソフトウェアとして入手でき、[len2021]で文書化されています。もともとは、「ハードワイヤード」ソースおよび宛先ポート番号を含む[RFC2544]のテストフレーム形式に文字通り従いましたが、[RFC4814]が必要とする擬似ランダムポート機能で補完されました。新しいバージョンは[len2020b]に文書化されています。
Further DPDK-based software Testers that are compliant with [RFC8219] are being developed at the Budapest University of Technology and Economics as student projects. They are planned to be released as free software, too.
[RFC8219]に準拠しているさらなるDPDKベースのソフトウェアテスターは、学生プロジェクトとしてブダペスト工科大学と経済学大学で開発されています。それらもフリーソフトウェアとしてリリースされる予定です。
Information about the benchmarking tools, measurements, and results will be made available in [IPv4aaS-BENCHMARK-TECH].
ベンチマークツール、測定、および結果に関する情報は、[IPv4aas-Benchmark-Tech]で利用可能になります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
As discussed in Section 4.7, the different technologies have varying logging capabilities and limitations. Care should be taken when storing, transmitting, and providing access to log entries that may be considered personally identifiable information. However, it should be noted that those issues are not specific to the IPv4aaS IPv6 transition technologies but apply to logging functionalities in general.
セクション4.7で説明したように、さまざまなテクノロジーにはさまざまなロギング機能と制限があります。個人識別可能な情報と見なされる可能性のあるログエントリへのアクセスを保存、送信、および提供する際には注意が必要です。ただし、これらの問題はIPv4AAS IPv6トランジションテクノロジーに固有ではなく、一般的なロギング機能に適用されることに注意する必要があります。
For all five technologies, the CE device typically contains a DNS proxy. However, the user may change DNS settings. If this happens and lw4o6, MAP-E, and MAP-T are used with a significantly restricted port set (which is required for efficient public IPv4 address sharing), the entropy of the source ports is significantly lowered (e.g., from 16 bits to 10 bits when 1024 port numbers are assigned to each subscriber), and these technologies are thus theoretically less resilient against cache poisoning (see [RFC5452]). However, an efficient cache poisoning attack requires that the subscriber operates its own caching DNS server and the attack is performed in the service provider network. Thus, we consider the chance of the successful exploitation of this vulnerability to be low.
5つのテクノロジーすべてについて、CEデバイスには通常、DNSプロキシが含まれています。ただし、ユーザーはDNS設定を変更する場合があります。これが発生し、LW4O6、MAP-E、およびMAP-Tが大幅に制限されたポートセット（効率的なパブリックIPv4アドレス共有に必要な）で使用された場合、ソースポートのエントロピーは大幅に低下します（たとえば、16ビットから16ビットまで10ビット1024ポート番号が各サブスクライバーに割り当てられている場合）。したがって、これらの技術は、キャッシュ中毒に対する理論的には回復力が低い（[RFC5452]を参照）。ただし、効率的なキャッシュ中毒攻撃では、サブスクライバーが独自のキャッシュDNSサーバーを操作し、攻撃がサービスプロバイダーネットワークで実行される必要があります。したがって、この脆弱性の搾取が成功する可能性が低いと考えています。
IPv4aaS technologies based on encapsulation have no DNSSEC implications. However, those based on translation may have implications as discussed in Section 4.1 of [RFC8683].
カプセル化に基づくIPv4AASテクノロジーには、DNSSECの意味はありません。ただし、翻訳に基づくものは、[RFC8683]のセクション4.1で説明したように影響を及ぼします。
An in-depth security analysis of all five IPv6 transition technologies and their most prominent free software implementations according to the methodology defined in [LEN2018] is planned.
[LEN2018]で定義されている方法論に従って、5つのIPv6遷移技術とその最も顕著なフリーソフトウェア実装の詳細なセキュリティ分析が計画されています。
As the first step, an initial security analysis of 464XLAT was done in [AZZ2021].
最初のステップとして、[AZZ2021]で464xLatの初期セキュリティ分析が行われました。
The implementers of any of the five IPv4aaS solutions should consult the Security Considerations of the respective RFCs documenting them.
5つのIPV4AASソリューションのいずれかの実装者は、それらを文書化するそれぞれのRFCのセキュリティに関する考慮事項を参照する必要があります。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC2473] Conta、A。およびS. Deering、「IPv6仕様の一般的なパケットトンネル」、RFC 2473、DOI 10.17487/RFC2473、1998年12月、<https://www.rfc-editor.org/info/rfc2473>
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, <https://www.rfc-editor.org/info/rfc2544>.
[RFC2544] Bradner、S。およびJ. McQuaid、「ネットワーク相互接続デバイスのベンチマーク方法論」、RFC 2544、DOI 10.17487/RFC2544、1999年3月、<https://www.rfc-editor.org/info/RFC2544>
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <https://www.rfc-editor.org/info/rfc2663>.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、DOI 10.17487/RFC2663、1999年8月、<https://www.rfc-editor.org/info/RFC2663>。
[RFC4814] Newman, D. and T. Player, "Hash and Stuffing: Overlooked Factors in Network Device Benchmarking", RFC 4814, DOI 10.17487/RFC4814, March 2007, <https://www.rfc-editor.org/info/rfc4814>.
[RFC4814] Newman、D。and T. Player、「Hash and Stiffing：Network Device Benchmarkingの見落とされた要因」、RFC 4814、DOI 10.17487/RFC4814、2007年3月、<https://www.rfc-editor.org/info/rfc4814>。
[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin, "IPv6 Benchmarking Methodology for Network Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May 2008, <https://www.rfc-editor.org/info/rfc5180>.
[RFC5180] Popoviciu、C.、Hamza、A.、Van de Velde、G。、およびD. Dugatkin、「ネットワーク相互接続デバイスのIPv6ベンチマーク方法」、RFC 5180、DOI 10.17487/RFC5180、2008年5月、<https：/<https：//www.rfc-editor.org/info/rfc5180>。
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, DOI 10.17487/RFC5452, January 2009, <https://www.rfc-editor.org/info/rfc5452>.
[RFC5452] Hubert、A。およびR. Van Mook、「Forged Answersに対してDNSをより回復力を高めるための対策」、RFC 5452、DOI 10.17487/RFC5452、2009年1月、<https://www.rfc-editor.org/info/RFC5452>。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <https://www.rfc-editor.org/info/rfc6052>.
[RFC6052] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M.、and X. Li、「IPv4/IPv6翻訳者のアドレス指定」、RFC 6052、DOI 10.17487/RFC6052、2010年10月、<<<<https://www.rfc-editor.org/info/rfc6052>。
[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、「Stateful 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 Extensions IPv6クライアントからIPv4サーバーへのネットワークアドレス変換の拡張、RFC 6147、DOI 10.17487/RFC6147、4月2011、<https://www.rfc-editor.org/info/rfc6147>。
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", RFC 6180, DOI 10.17487/RFC6180, May 2011, <https://www.rfc-editor.org/info/rfc6180>.
[RFC6180] Arkko、J。およびF. Baker、「IPv6展開中にIPv6遷移メカニズムを使用するためのガイドライン」、RFC 6180、DOI 10.17487/RFC6180、<https：//www.rfc-editor.org/info/RFC6180>。
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <https://www.rfc-editor.org/info/rfc6269>.
[RFC6269] Ford、M.、Ed。、Boucadair、M.、Durand、A.、Levis、P.、およびP. Roberts、「IPアドレス共有の問題」、RFC 6269、DOI 10.17487/RFC6269、2011年6月、2011年6月、<https://www.rfc-editor.org/info/rfc6269>。
[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疲労後のデュアルスタックライトブロードバンド展開」、RFC 6333、DOI 10.17487/RFC6333、2011年8月、<https：/<https：//www.rfc-editor.org/info/rfc6333>。
[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/RFC6346, August 2011, <https://www.rfc-editor.org/info/rfc6346>.
[RFC6346] Bush、R.、ed。、「IPv4アドレス不足に対するアドレスプラスポート（A P）アプローチ」、RFC 6346、DOI 10.17487/RFC6346、2011年8月、<https://www.rfc-editor.org/info/rfc6346>。
[RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual-Stack Lite", RFC 6519, DOI 10.17487/RFC6519, February 2012, <https://www.rfc-editor.org/info/rfc6519>.
[RFC6519] Maglione、R。およびA. Durand、「デュアルスタックライトの半径拡張」、RFC 6519、DOI 10.17487/RFC6519、2012年2月、<https://www.rfc-editor.org/info/rfc6519>。
[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：ステートフルとステートレス翻訳の組み合わせ」、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。、Ed。、Cheshire、S.、Boucadair、M.、Penno、R.、およびP. Selkirk、「ポートコントロールプロトコル（PCP）」、RFC 6887、DOI 10.17487/RFC6887、2013年4月、<https://www.rfc-editor.org/info/rfc6887>。
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, <https://www.rfc-editor.org/info/rfc6888>.
[RFC6888] Perreault、S.、Ed。、Yamagata、I.、Miyakawa、S.、Nakagawa、A。、およびH. Ashida、「キャリアグレードNAT（CGN）の共通要件」、BCP 127、RFC 6888、doi 10.17487/rfc6888、2013年4月、<https://www.rfc-editor.org/info/rfc6888>。
[RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, "Analysis of Stateful 64 Translation", RFC 6889, DOI 10.17487/RFC6889, April 2013, <https://www.rfc-editor.org/info/rfc6889>.
[RFC6889] Penno、R.、Saxena、T.、Boucadair、M.、およびS. Sivakumar、「Stateful 64翻訳の分析」、RFC 6889、DOI 10.17487/RFC6889、2013年4月、<https：//ww.rfc6889-editor.org/info/rfc6889>。
[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>。
[RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 Deployment Options and Experience", RFC 7269, DOI 10.17487/RFC7269, June 2014, <https://www.rfc-editor.org/info/rfc7269>.
[RFC7269] Chen、G.、Cao、Z.、Xie、C。、およびD. Binet、「Nat64展開オプションと経験」、RFC 7269、DOI 10.17487/RFC7269、2014年6月、<https：//www.rfc-editor.org/info/rfc7269>。
[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）輸送"、RFC 7341、doi 10.17487/rfc7341、August2014、<https://www.rfc-editor.org/info/rfc7341>。
[RFC7393] Deng, X., Boucadair, M., Zhao, Q., Huang, J., and C. Zhou, "Using the Port Control Protocol (PCP) to Update Dynamic DNS", RFC 7393, DOI 10.17487/RFC7393, November 2014, <https://www.rfc-editor.org/info/rfc7393>.
[RFC7393] Deng、X.、Boucadair、M.、Zhao、Q.、Huang、J。、およびC. Zhou、「ポートコントロールプロトコル（PCP）を使用して動的DNSを更新する」、RFC 7393、DOI 10.17487/RFC739333333、2014年11月、<https://www.rfc-editor.org/info/rfc7393>。
[RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., and O. Vautrin, "Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments", RFC 7422, DOI 10.17487/RFC7422, December 2014, <https://www.rfc-editor.org/info/rfc7422>.
、2014年12月、<https://www.rfc-editor.org/info/rfc7422>。
[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：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。、およびT. Taylor、ed。、「住所とポートのマッピングカプセル化（MAP-E） "、RFC 7597、doi 10.17487/rfc7597、2015年7月、<https://www.rfc-editor.org/info/rfc7597>。
[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>。
[RFC7605] Touch, J., "Recommendations on Using Assigned Transport Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, August 2015, <https://www.rfc-editor.org/info/rfc7605>.
[RFC7605] Touch、J。、「割り当てられた輸送ポート番号の使用に関する推奨事項」、BCP 165、RFC 7605、DOI 10.17487/RFC7605、2015年8月、<https://www.rfc-editor.org/info/rfc7605>
[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI 10.17487/RFC7757, February 2016, <https://www.rfc-editor.org/info/rfc7757>.
[RFC7757] Anderson、T。およびA. Leiva Popper、「ステートレスIP/ICMP翻訳の明示的なアドレスマッピング」、RFC 7757、DOI 10.17487/RFC7757、2016年2月、<https：//www.rfc-editor.org/info/RFC7757>。
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016, <https://www.rfc-editor.org/info/rfc7915>.
[RFC7915] Bao、C.、Li、X.、Baker、F.、Anderson、T.、およびF. Gont、「IP/ICMP翻訳アルゴリズム」、RFC 7915、DOI 10.17487/RFC7915、2016年6月、<https：//www.rfc-editor.org/info/rfc7915>。
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950] Bjorklund、M.、ed。、「Yang 1.1 Data Modeling Language」、RFC 7950、DOI 10.17487/RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[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、「IPv4マルチキャストネットワークを介したIPv4マルチキャストサービスのIPv4クライアントへの配信」、RFC 8114、DOI 10.17487/RFC8114、2017年3月、<https://www.rfc-editor.org/info/rfc8114>。
[RFC8215] Anderson, T., "Local-Use IPv4/IPv6 Translation Prefix", RFC 8215, DOI 10.17487/RFC8215, August 2017, <https://www.rfc-editor.org/info/rfc8215>.
[RFC8215] Anderson、T。、「ローカル使用IPv4/IPv6翻訳プレフィックス」、RFC 8215、DOI 10.17487/RFC8215、2017年8月、<https://www.rfc-editor.org/info/rfc8215>
[RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking Methodology for IPv6 Transition Technologies", RFC 8219, DOI 10.17487/RFC8219, August 2017, <https://www.rfc-editor.org/info/rfc8219>.
[RFC8219] Georgescu、M.、Pislaru、L.、およびG. Lencse、「IPv6遷移技術のベンチマーク方法論」、RFC 8219、DOI 10.17487/RFC8219、2017年8月、<https://ww.rfc-editor.org/info/rfc8219>。
[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>。
[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., Vinapamula, S., and Q. Wu, "A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, <https://www.rfc-editor.org/info/rfc8512>.
[RFC8512] Boucadair、M.、Ed。、Sivakumar、S.、Jacquenet、C.、Vinapamula、S.、＆Q。Wu、「ネットワークアドレス変換（NAT）およびネットワークプレフィックス翻訳（NPT）のヤンモジュール」、RFC 8512、DOI 10.17487/RFC8512、2019年1月、<https://www.rfc-editor.org/info/rfc8512>。
[RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, DOI 10.17487/RFC8513, January 2019, <https://www.rfc-editor.org/info/rfc8513>.
[RFC8513] Boucadair、M.、Jacquenet、C。、およびS. Sivakumar、「デュアルスタックLite（DS-Lite）のYangデータモデル」、RFC 8513、DOI 10.17487/RFC8513、2019年1月、<HTTPS：//www.rfc-editor.org/info/rfc8513>。
[RFC8658] Jiang, S., Ed., Fu, Y., Ed., Xie, C., Li, T., and M. Boucadair, Ed., "RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P)", RFC 8658, DOI 10.17487/RFC8658, November 2019, <https://www.rfc-editor.org/info/rfc8658>.
[RFC8658] Jiang、S.、Ed。、Fu、Y.、Ed。、Xie、C.、Li、T。、およびM. Boucadair、ed。、「アドレスプラスポートに基づくソフトワイヤーメカニズムのRadius属性（A P））」、RFC 8658、DOI 10.17487/RFC8658、2019年11月、<https://www.rfc-editor.org/info/rfc8658>。
[RFC8676] Farrer, I., Ed. and M. Boucadair, Ed., "YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires", RFC 8676, DOI 10.17487/RFC8676, November 2019, <https://www.rfc-editor.org/info/rfc8676>.
[RFC8676] Farrer、I.、ed。and M. Boucadair、ed。、「IPv4-in-IPV6アドレスプラスポート（A P）ソフトウェアのYangモジュール」、RFC 8676、DOI 10.17487/RFC8676、2019年11月、<https://www.rfc-editor.org/情報/RFC8676>。
[RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks", RFC 8683, DOI 10.17487/RFC8683, November 2019, <https://www.rfc-editor.org/info/rfc8683>.
[RFC8683] Palet Martinez、J。、「オペレーターおよびエンタープライズネットワークにおけるNAT64/464XLATの追加展開ガイドライン」、RFC 8683、DOI 10.17487/RFC8683、2019年11月、<https://www.rfc-editor.org/info//RFC8683>。
[AFTR] ISC, "ISC Implementation of AFTR", <https://downloads.isc.org/isc/aftr/>.
[AFTR] ISC、「AFTRのISC実装」、<https://downloads.isc.org/isc/aftr/>。
[AZZ2021] Al-Azzawi, A. and G. Lencse, "Identification of the Possible Security Issues of the 464XLAT IPv6 Transition Technology", Infocommunications Journal, Vol. 13, No. 4, pp. 10-18, DOI 10.36244/ICJ.2021.4.2, December 2021, <https://www.infocommunications.hu/2021_4_2>.
[Azz2021] Al-Azzawi、A。およびG. Lencse、「464XLAT IPv6 Transition Technologyの可能なセキュリティ問題の特定」、Infocommunications Journal、Vol。13、No。4、pp。10-18、DOI 10.36244/ICJ.2021.4.2、2021年12月、<https://www.infocommunications.hu/2021_4_2>。
[IPv4aaS-BENCHMARK-TECH] Lencse, G., "Performance Analysis of IPv6 Transition Technologies for IPv4aaS", Work in Progress, Internet-Draft, draft-lencse-v6ops-transition-benchmarking-01, 2 May 2022, <https://datatracker.ietf.org/doc/html/draft-lencse-v6ops-transition-benchmarking-01>.
[IPv4aas-Benchmark-Tech] Lencse、G。、「IPv4aasのIPv6遷移技術のパフォーマンス分析」、進行中の作業、インターネットドラフト、ドラフトLencse-V6OPS-Transition-Benchmarking-01、2022年5月2日、<HTTPS：//datatracker.ietf.org/doc/html/draft-lencse-v6ops-transition-benchmarkink-01>。
[IPv4aaS-SCALE-TECH] Lencse, G., "Scalability of IPv6 Transition Technologies for IPv4aaS", Work in Progress, Internet-Draft, draft-lencse-v6ops-transition-scalability-03, 30 June 2022, <https://datatracker.ietf.org/doc/html/draft-lencse-v6ops-transition-scalability-03>.
[IPv4aas-scale-tech] Lencse、G。、「IPv4aasのIPv6遷移技術のスケーラビリティ」、進行中の作業、インターネットドラフト、ドラフトLencse-v6ops-transition-scalability-03、30 6月30日、<https：//datatracker.ietf.org/doc/html/draft-lencse-v6ops-transition-scalability-03>。
[JOOL] "Jool: SIIT & NAT64", <http://www.jool.mx>.
[Jool] "Jool：Siit＆Nat64"、<http://www.jool.mx>。
[JOOL-MAPT] "MAP-T Run", <https://www.jool.mx/en/run-mapt.html>.
[Jool-Mapt] "Map-t run"、<https://www.jool.mx/en/run-mapt.html>。
[LEN2018] Lencse, G. and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers & Security, Vol. 77, No. 1, pp. 397-411, DOI 10.1016/j.cose.2018.04.012, August 2018, <http://www.hit.bme.hu/~lencse/publications/ECS-2018- Methodology-revised.pdf>.
[LEN2018] Lencse、G。およびY. Kadobayashi、「異なるIPv6遷移技術の潜在的なセキュリティ問題の識別の方法論：DNS64およびStateful Nat64の脅威分析」、Computers＆Security、vol。77、No。1、pp。397-411、doi 10.1016/j.cose.2018.04.012、2018年8月、<http://www.hit.bme.hu/~lencse/publications/ecs-2018-方法論Revised.pdf>。
[LEN2019] Lencse, G. and Y. Kadobayashi, "Comprehensive Survey of IPv6 Transition Technologies: A Subjective Classification for Security Analysis", IEICE Transactions on Communications, Vol. E102-B, No. 10, pp. 2021-2035, DOI 10.1587/transcom.2018EBR0002, October 2019, <http://www.hit.bme.hu/~lencse/publications/ e102-b_10_2021.pdf>.
[Len2019] Lencse、G。およびY. Kadobayashi、「IPv6遷移技術の包括的な調査：セキュリティ分析のための主観的分類」、IEICE Transactions on Communications、Vol。E102-B、No。10、pp。2021-2035、doi 10.1587/transcom.2018ebr0002、2019年10月、<http://www.hit.bme.hu/~lencse/publications/ e102-b_10_2021.pdf>。
[LEN2020a] Lencse, G., "Benchmarking stateless NAT64 implementations with a standard tester", Telecommunication Systems, Vol. 75, pp. 245-257, DOI 10.1007/s11235-020-00681-x, June 2020, <https://link.springer.com/article/10.1007/ s11235-020-00681-x>.
[LEN2020A] Lencse、G。、「標準テスターを使用したステートレスNAT64実装のベンチマーク」、Telecommunication Systems、Vol。75、pp。245-257、doi 10.1007/s11235-020-00681-x、2020年6月、<https://link.springer.com/article/10.1007/ s11235-020-00681-x>。
[LEN2020b] Lencse, G., "Adding RFC 4814 Random Port Feature to Siitperf: Design, Implementation and Performance Estimation", International Journal of Advances in Telecommunications, Electrotechnics, Signals and Systems, Vol. 9, No. 3, pp. 18-26, DOI 10.11601/ijates.v9i3.291, 2020, <https://ijates.org/index.php/ijates/article/view/291>.
[LEN2020B] Lencse、G。、「RFC 4814ランダムポート機能をSIITPERFに追加：設計、実装、パフォーマンスの推定」、国際的なJournal of Advances in Electrotechnics、Signals and Systems、Vol。9、No。3、pp。18-26、doi 10.11601/ijates.v9i3.291、2020、<https://ijates.org/index.php/ijates/article/view/291>。
[LEN2021] Lencse, G., "Design and Implementation of a Software Tester for Benchmarking Stateless NAT64 Gateways", IEICE Transactions on Communications, Vol. E104.B, Issue 2, pp. 128-140, DOI 10.1587/transcom.2019EBN0010, 2021, <https://doi.org/10.1587/transcom.2019EBN0010>.
[LEN2021] Lencse、G。、「Stateless Nat64ゲートウェイのベンチマークのためのソフトウェアテスターの設計と実装」、IEICE Transactions on Communications、Vol。E104.B、Issue 2、pp。128-140、DOI 10.1587/transcom.2019EBN0010、2021、<https://doi.org/10.1587/transcom.2019ebn0010>。
[MIY2010] Miyakawa, S., "IPv4 to IPv6 Transformation Schemes", IEICE Transactions on Communications, Vol. E93-B, Issue 5, pp. 1078-1084, DOI 10.1587/transcom.E93.B.1078, 2010, <https://www.jstage.jst.go.jp/article/transcom/E93.B/5/ E93.B_5_1078/_article>.
[MIY2010] Miyakawa、S。、「IPv4からIPv6変換スキーム」、IEICE Transactions on Communications、Vol。E93-B、Issue 5、pp。1078-1084、doi 10.1587/transcom.e93.b.1078、2010、<https://www.jstage.jst.go.jp/transcom/e93.b/5/ e93.b_5_1078/ _article>。
[NAT-SUPP] Stewart, R. R., Tüxen, M., and I. Ruengeler, "Stream Control Transmission Protocol (SCTP) Network Address Translation Support", Work in Progress, Internet-Draft, draft-ietf-tsvwg-natsupp-23, 25 October 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-natsupp-23>.
[Nat-Supp] Stewart、R。R.、Tüxen、M。、およびI. Ruengeler、「ストリーム制御伝送プロトコル（SCTP）ネットワークアドレス翻訳サポート」、Work in Progress、Internet-Draft、Draft-IITF-TSVWG-Natsupp-23、2021年10月25日、<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-natsupp-23>。
[OP-464XLAT/MAP-T] Palet Martinez, J. and A. D'Egidio, "464XLAT/MAT-T Optimization", Work in Progress, Internet-Draft, draft-ietf-v6ops-464xlat-optimization-03, 28 July 2020, <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization-03>.
[OP-464XLAT/MAP-T] Palet Martinez、J。およびA. D'Egidio、「464XLAT/MAT-T Optimization」、Work in Progress、ITERTF-V6OPS-464XLAT-OPTIMIZATION-03、2020年7月28日、<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization-03>。
[REP2014] Répás, S., Hajas, T., and G. Lencse, "Port Number Consumption of the NAT64 IPv6 Transition Technology", 37th International Conference on Telecommunications and Signal Processing, DOI 10.1109/TSP.2015.7296411, 2014, <http://www.hit.bme.hu/~lencse/publications/TSP-2014-PC.pdf>.
[Rep2014]Répás、S.、Hajas、T.、およびG. Lencse、「Nat64 IPv6遷移技術のポート番号消費」、第37回電気通信および信号処理に関する国際会議、DOI 10.1109/TSP.2015.7296411、2014、<HTTPPP.：//www.hit.bme.hu/~lencse/publications/tsp-2014-pc.pdf>。
[SIITPERF] "Siitperf: an RFC 8219 compliant SIIT (stateless NAT64) tester", commit bdce0f, February 2021, <https://github.com/lencsegabor/siitperf>.
[siitperf] "siitperf：an rfc 8219準拠のsiit（stateless nat64）テスター"、commit bdce0f、2021年2月、<https://github.com/lencsegabor/siitperf>。
[SNABB] "Snabb implementation of lwAFTR", commit 1ef72ce, January 2022, <https://github.com/Igalia/snabb>.
[SNABB]「LWAFTRのSNABB実装」、2022年1月、<https://github.com/galia/snabb>をコミットします。
[TR-069] Broadband Forum, "CPE WAN Management Protocol", Technical Report TR-069, June 2020, <https://www.broadband-forum.org/technical/download/TR-069.pdf>.
[TR-069]ブロードバンドフォーラム、「CPE WAN管理プロトコル」、テクニカルレポートTR-069、2020年6月、<https://www.broadband-forum.org/technical/download/tr-069.pdf>。
[VPP] "VPP", July 2022, <https://wiki.fd.io/index.php?title=VPP&oldid=11809>.
[vpp] "vpp"、2022年7月、<https://wiki.fd.io/index.php?title=vpp＆old = 11809>。
Acknowledgements
謝辞
The authors would like to thank Ole Troan, Warren Kumari, Dan Romascanu, Brian Trammell, Joseph Salowey, Roman Danyliw, Erik Kline, Lars Eggert, Zaheduzzaman Sarker, Robert Wilton, Éric Vyncke and Martin Duke for their review of this document and acknowledge the inputs of Mark Andrews, Edwin Cordeiro, Fred Baker, Alexandre Petrescu, Cameron Byrne, Tore Anderson, Mikael Abrahamsson, Gert Doering, Satoru Matsushima, Yutianpeng (Tim), Mohamed Boucadair, Nick Hilliard, Joel Jaeggli, Kristian McColm, Tom Petch, Yannis Nikolopoulos, Havard Eidnes, Yann-Ju Chu, Barbara Stark, Vasilenko Eduard, Chongfeng Xie, Henri Alves de Godoy, Magnus Westerlund, Michael Tüxen, Philipp S. Tiesel, Brian E. Carpenter, and Joe Touch.
著者は、Ole Troan、Warren Kumari、Dan Romascanu、Brian Trammell、Joseph Salowey、Roman Danyliw、Erik Kline、Lars Eggert、Zaheduzzaman Sarker、Robert Wilton、Eric Vyncke、Martin Dukeに感謝し、この文書をレビューしてくれたことに感謝します。マーク・アンドリュース、エドウィン・コルデイロ、フレッド・ベイカー、アレクサンドル・ペトレシュ、キャメロン・バーン、トーレ・アンダーソン、ミカエル・アブラハムソン、ゲルト・ドーリング、ユティアンペン（ティム）、モハメド・ブーカデア、ニック・ヒリヤード、ジョエル・ジェグリ、ヤエル・ジェグリ、ヤエル・ジェグリニコロプロス、ハバード・アイドネス、ヤンジュ・チュー、バーバラ・スターク、ヴァシレンコ・エドゥアルド、チョンフェンXie、アンリ・アルベス・デ・ゴドイ、マグナス・ウェスターランド、マイケル・チューセン、フィリップ・S・タイーセル、ブライアン・E・カーペンター、ジョー・タッチ。
Authors' Addresses
著者のアドレス
Gábor Lencse Budapest University of Technology and Economics Budapest Magyar tudósok körútja 2 H-1117 Hungary Email: lencse@hit.bme.hu URI: http://www.hit.bme.hu/~lencse/index_en.htm
GáborLencseBudapest Technology and Economics大学
Jordi Palet Martinez The IPv6 Company Molino de la Navata, 75 28420 La Navata - Galapagar Madrid Spain Email: jordi.palet@theipv6company.com URI: http://www.theipv6company.com/
Jordi Palet Martinez The IPv6 Company Molino de La Navata、75 28420 La Navata -Galapagar Madridスペインメール：jordi.palet@theipv6company.com URI：http：//www.theipv6company.com/
Lee Howard Retevia 9940 Main St., Suite 200 Fairfax, Virginia 22031 United States of America Email: lee@asgard.org
Lee Howard Retevia 9940 Main St.、Suite 200 Fairfax、Virginia 22031アメリカ合衆国電子メール：lee@asgard.org
Richard Patterson Sky UK 1 Brick Lane London EQ 6PU United Kingdom Email: richard.patterson@sky.uk
リチャードパターソンスカイUK 1ブリックレーンロンドンEQ 6puイギリスの電子メール：richard.patterson@sky.uk
Ian Farrer Deutsche Telekom AG Landgrabenweg 151 53227 Bonn Germany Email: ian.farrer@telekom.de
Ian Farrer Deutsche Telekom AG Landgrabenweg 151 53227 Bonn Germanyメール：ian.farrer@telekom.de