[要約] 要約：RFC 8683は、オペレーターおよびエンタープライズネットワークでのNAT64/464XLATの追加展開ガイドラインを提供しています。 目的：このRFCの目的は、NAT64/464XLATの展開に関するベストプラクティスとガイドラインを提供し、ネットワークオペレーターやエンタープライズが効果的かつ効率的に展開できるようにすることです。
Internet Engineering Task Force (IETF) J. Palet Martinez
Request for Comments: 8683 The IPv6 Company
Category: Informational November 2019
ISSN: 2070-1721
Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks
オペレーターおよびエンタープライズネットワークにおけるNAT64 / 464XLATの追加の展開ガイドライン
Abstract
概要
This document describes how Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) (including 464XLAT) can be deployed in an IPv6 network -- whether it's cellular ISP, broadband ISP, or enterprise -- and the possible optimizations. This document also discusses issues to be considered when having IPv6-only connectivity, such as: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6-compliant APIs, and c) IPv4-only hosts or applications.
このドキュメントでは、IPv6クライアントからIPv4サーバー（NAT64）（464XLATを含む）へのネットワークアドレスとプロトコル変換をIPv6ネットワーク（セルラーISP、ブロードバンドISP、またはエンタープライズ）に展開する方法と、可能な最適化について説明します。このドキュメントでは、IPv6のみの接続の場合に考慮すべき問題についても説明します。たとえば、a）DNS64、b）リテラルIPv4アドレスまたは非IPv6準拠のAPIを使用するアプリケーションまたはデバイス、c）IPv4のみのホストまたはアプリケーションなどです。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8683.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8683で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Requirements Language
3. NAT64 Deployment Scenarios
3.1. Known to Work
3.1.1. Service Provider NAT64 with DNS64
3.1.2. Service Provider Offering 464XLAT Using DNS64
3.1.3. Service Provider Offering 464XLAT, without Using DNS64
3.2. Known to Work under Special Conditions
3.2.1. Service Provider NAT64 without DNS64
3.2.2. Service-Provider NAT64; DNS64 in IPv6 Hosts
3.2.3. Service-Provider NAT64; DNS64 in the IPv4-Only Remote
Network
3.3. Comparing the Scenarios
4. Issues to be Considered
4.1. DNSSEC Considerations and Possible Approaches
4.1.1. Not Using DNS64
4.1.2. DNSSEC Validator Aware of DNS64
4.1.3. Stub Validator
4.1.4. CLAT with DNS Proxy and Validator
4.1.5. ACL of Clients
4.1.6. Mapping Out IPv4 Addresses
4.2. DNS64 and Reverse Mapping
4.3. Using 464XLAT with/without DNS64
4.4. Foreign DNS
4.4.1. Manual Configuration of DNS
4.4.2. DNS Privacy/Encryption Mechanisms
4.4.3. Split DNS and VPNs
4.5. Well-Known Prefix (WKP) vs. Network-Specific Prefix (NSP)
4.6. IPv4 Literals and Non-IPv6-Compliant APIs
4.7. IPv4-Only Hosts or Applications
4.8. CLAT Translation Considerations
4.9. EAM Considerations
4.10. Incoming Connections
5. Summary of Deployment Recommendations for NAT64/464XLAT
6. Deployment of 464XLAT/NAT64 in Enterprise Networks
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Example of Broadband Deployment with 464XLAT
Appendix B. CLAT Implementation
Appendix C. Benchmarking
Acknowledgements
Author's Address
Stateful NAT64 [RFC6146] describes a stateful IPv6-to-IPv4 translation mechanism that allows IPv6-only hosts to communicate with IPv4-only servers using unicast UDP, TCP, or ICMP by means of IPv4 public address sharing among multiple IPv6-only hosts. Unless otherwise stated, references to NAT64 (function) in this document should be interpreted as Stateful NAT64.
ステートフルNAT64 [RFC6146]は、IPv6のみのホストが複数のIPv6のみのホスト間でIPv4パブリックアドレスを共有することにより、ユニキャストUDP、TCP、またはICMPを使用してIPv4のみのサーバーと通信できるようにする、ステートフルIPv6-to-IPv4変換メカニズムについて説明しています。特に明記されていない限り、このドキュメントでのNAT64（関数）への参照は、ステートフルNAT64として解釈されます。
The translation of the packet headers is done using the IP/ICMP translation algorithm defined in [RFC7915]; algorithmically translating the IPv4 addresses to IPv6 addresses, and vice versa, is done following [RFC6052].
パケットヘッダーの変換は、[RFC7915]で定義されているIP / ICMP変換アルゴリズムを使用して行われます。 IPv4アドレスをIPv6アドレスに、またはその逆にアルゴリズム的に変換することは、[RFC6052]に従って行われます。
DNS64 [RFC6147] is in charge of the synthesis of AAAA records from the A records, so it only works for applications making use of DNS. It was designed to avoid changes in both the IPv6-only hosts and the IPv4-only server, so they can use a NAT64 function. As discussed in Section 5.5 of [RFC6147], a security-aware and validating host has to perform the DNS64 function locally.
DNS64 [RFC6147]は、AレコードからのAAAAレコードの合成を担当するため、DNSを使用するアプリケーションでのみ機能します。これは、IPv6のみのホストとIPv4のみのサーバーの両方での変更を回避して、NAT64機能を使用できるように設計されています。 [RFC6147]のセクション5.5で説明されているように、セキュリティ対応および検証ホストはDNS64機能をローカルで実行する必要があります。
However, the use of NAT64 and/or DNS64 presents three drawbacks:
ただし、NAT64やDNS64を使用すると、3つの欠点が生じます。
1. Because DNS64 [RFC6147] modifies DNS answers, and DNSSEC is designed to detect such modifications, DNS64 [RFC6147] may potentially break DNSSEC, depending on a number of factors such as the location of the DNS64 function (at a DNS server or validator, at the end host, ...), how it has been configured, if the end hosts are validating, etc.
1. DNS64 [RFC6147]はDNSの回答を変更し、DNSSECはそのような変更を検出するように設計されているため、DNS64 [RFC6147]は、DNS64関数の場所（DNSサーバーまたは検証サーバーでエンドホスト、...）、それがどのように構成されているか、エンドホストが検証している場合など。
2. Because of the need to use DNS64 [RFC6147] or an alternative "host/application built-in" mechanism for address synthesis, there may be an issue for NAT64 [RFC6146] because it doesn't work when IPv4 literal addresses or non-IPv6-compliant APIs are being used.
2. アドレス合成にDNS64 [RFC6147]または代替の「ホスト/アプリケーション組み込み」メカニズムを使用する必要があるため、IPv4リテラルアドレスまたは非IPv6の場合は機能しないため、NAT64 [RFC6146]に問題がある可能性があります。準拠のAPIが使用されています。
3. NAT64 alone was not designed to provide a solution for IPv4-only hosts or applications that are located within a network and connected to a service provider IPv6-only access link, as it was designed for a very specific scenario (see Section 2.1 of [RFC6144]).
3. NAT64のみは、非常に特定のシナリオ用に設計されたため、ネットワーク内にあり、サービスプロバイダーのIPv6のみのアクセスリンクに接続されているIPv4のみのホストまたはアプリケーションのソリューションを提供するようには設計されていません（[RFC6144のセクション2.1を参照]。 ]）。
The drawbacks discussed above may come into play if part of an enterprise network is connected to other parts of the same network or to third-party networks by means of IPv6-only connectivity. This is just an example that may apply to many other similar cases. All of them are deployment specific.
エンタープライズネットワークの一部が同じネットワークの他の部分に接続されている場合、またはIPv6のみの接続によってサードパーティのネットワークに接続されている場合、上記の欠点が発生する可能性があります。これは、他の多くの同様のケースに当てはまる例にすぎません。それらはすべてデプロイメント固有です。
Accordingly, the use of "operator", "operator network", "service provider", and similar terms in this document are interchangeable with equivalent cases of enterprise networks; other cases may be similar as well. This may be also the case for "managed end-user networks".
したがって、このドキュメントでの「オペレーター」、「オペレーターネットワーク」、「サービスプロバイダー」、および同様の用語の使用は、エンタープライズネットワークの同等のケースと交換可能です。他の場合も同様です。これは、「管理されたエンドユーザーネットワーク」の場合も同様です。
Note that if all the hosts in a network were performing address synthesis, as described in Section 7.2 of [RFC6147], some of the drawbacks may not apply. However, it is unrealistic to expect that in today's world, considering the high number of devices and applications that aren't yet IPv6 enabled. In this document, the case in which all hosts provide synthesis will be considered only for specific scenarios that can guarantee it.
[RFC6147]のセクション7.2で説明されているように、ネットワーク内のすべてのホストがアドレス合成を実行している場合、いくつかの欠点が適用されない場合があることに注意してください。ただし、今日の世界では、まだIPv6に対応していない多数のデバイスとアプリケーションを考慮すると、現実的ではありません。このドキュメントでは、すべてのホストが合成を提供するケースは、それを保証できる特定のシナリオでのみ考慮されます。
An analysis of stateful IPv4/IPv6 mechanisms is provided in [RFC6889].
ステートフルIPv4 / IPv6メカニズムの分析は[RFC6889]で提供されています。
This document looks into different possible NAT64 [RFC6146] deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) and similar ones that were not documented in [RFC6144], such as 464XLAT [RFC6877] in operator (broadband and cellular) and enterprise networks; it provides guidelines to avoid operational issues.
このドキュメントでは、IPv4-IPv6-IPv4（略して464）や、[RFC6144]で文書化されていなかった、オペレーター（ブロードバンドおよびセルラー）の464XLAT [RFC6877]などの類似のシナリオを含む、さまざまなNAT64 [RFC6146]展開シナリオを検討します。エンタープライズネットワーク;運用上の問題を回避するためのガイドラインを提供します。
This document also explores the possible NAT64 deployment scenarios (split in "known to work" and "known to work under special conditions"), providing a quick and generic comparison table among them. Then, the document describes the issues that an operator needs to understand, which will allow the best approach/scenario to be defined for each specific network case. A summary provides some recommendations and decision points. A section with clarifications on the usage of this document for enterprise networks is also provided. Finally, Appendix A provides an example of a broadband deployment using 464XLAT and hints for a customer-side translator (CLAT) implementation.
このドキュメントでは、可能なNAT64展開シナリオ（「既知の動作」と「特別な条件下で動作することがわかっている」に分割）についても説明し、それらの間の簡単で一般的な比較表を示します。次に、ドキュメントは、オペレーターが理解する必要がある問題について説明します。これにより、特定のネットワークケースごとに最適なアプローチ/シナリオを定義できます。概要には、いくつかの推奨事項と決定ポイントが記載されています。このドキュメントのエンタープライズネットワークでの使用方法を明確にしたセクションも提供されます。最後に、付録Aは、464XLATを使用したブロードバンド展開の例と、顧客側トランスレータ（CLAT）実装のヒントを示しています。
[RFC7269] already provides information about NAT64 deployment options and experiences. This document and [RFC7269] are complementary; they both look into different deployment considerations. Furthermore, this document considers the updated deployment experience and newer standards.
[RFC7269]は、NAT64展開オプションとエクスペリエンスに関する情報をすでに提供しています。このドキュメントと[RFC7269]は補足的です。どちらも、導入に関するさまざまな考慮事項を検討しています。さらに、このドキュメントでは、更新された展開エクスペリエンスと新しい標準について検討します。
The target deployment scenarios in this document may also be covered by other IPv4-as-a-Service (IPv4aaS) transition mechanisms. Note that this is true only for broadband networks; in the case of cellular networks, the only supported solution is the use of NAT64/464XLAT. So, it is out of scope of this document to provide a comparison among the different IPv4aaS transition mechanisms, which are analyzed in [IPv6-TRANSITION].
このドキュメントの対象となる展開シナリオは、他のIPv4-as-a-Service（IPv4aaS）移行メカニズムによってカバーされる場合もあります。これはブロードバンドネットワークにのみ当てはまることに注意してください。携帯電話ネットワークの場合、サポートされる唯一のソリューションはNAT64 / 464XLATの使用です。したがって、[IPv6-TRANSITION]で分析されているさまざまなIPv4aaS移行メカニズムを比較することは、このドキュメントの範囲外です。
Consequently, this document should not be used as a guide for an operator or enterprise to decide which IPv4aaS is the best one for its own network. Instead, it should be used as a tool for understanding all the implications, including relevant documents (or even specific parts of them) for the deployment of NAT64/464XLAT and for facilitating the decision process regarding specific deployment details.
したがって、このドキュメントは、オペレーターまたは企業が自社のネットワークに最適なIPv4aaSを決定するためのガイドとして使用しないでください。代わりに、NAT64 / 464XLATの展開に関する関連ドキュメント（またはドキュメントの特定の部分）を含むすべての影響を理解し、特定の展開の詳細に関する決定プロセスを容易にするためのツールとして使用する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
DNS64 (see Section 7 of [RFC6147]) provides three deployment scenarios, depending on the location of the DNS64 function. However, since the publication of that document, other deployment scenarios and NAT64 use cases need to be considered in actual networks, despite the fact that some of them were specifically ruled out by the original NAT64/DNS64 work.
DNS64（[RFC6147]のセクション7を参照）は、DNS64関数の場所に応じて、3つの展開シナリオを提供します。ただし、そのドキュメントの公開以降、元のNAT64 / DNS64の作業によって明確に除外されていたにもかかわらず、実際のネットワークでは他の展開シナリオとNAT64の使用例を考慮する必要があります。
Consequently, the perspective in this document is to broaden those scenarios and include a few new ones. However, in order to reduce the number of possible cases, we work under the assumption that the service provider wants to make sure that all the customers have a service without failures. This means considering the following assumptions for the worst possible case:
したがって、このドキュメントの視点は、これらのシナリオを広げ、いくつかの新しいシナリオを含めることです。ただし、発生する可能性のあるケースの数を減らすために、サービスプロバイダーはすべての顧客にサービスを確実に提供し、障害のないサービスを提供することを前提としています。これは、考えられる最悪のケースに対して以下の仮定を考慮することを意味します。
a. There are hosts that will be validating DNSSEC.
a. DNSSECを検証するホストがあります。
b. IPv4 literal addresses and non-IPv6-compliant APIs are being used.
b. IPv4リテラルアドレスと非IPv6準拠のAPIが使用されています。
c. There are IPv4-only hosts or applications beyond the IPv6-only link (e.g., tethering in cellular networks).
c. IPv6のみのリンクを超えたIPv4のみのホストまたはアプリケーション（たとえば、セルラーネットワークでのテザリング）があります。
This document uses a common set of possible "participant entities":
このドキュメントでは、可能な「参加者エンティティ」の共通セットを使用しています。
1. An IPv6-only access network (IPv6).
1. IPv6のみのアクセスネットワーク（IPv6）。
2. An IPv4-only remote network/server/service (IPv4).
2. IPv4のみのリモートネットワーク/サーバー/サービス（IPv4）。
3. A NAT64 function (NAT64) in the service provider.
3. サービスプロバイダーのNAT64関数（NAT64）。
4. A DNS64 function (DNS64) in the service provider.
4. サービスプロバイダーのDNS64関数（DNS64）。
5. An external service provider offering the NAT64 function and/or the DNS64 function (extNAT64/extDNS64).
5. NAT64機能またはDNS64機能（extNAT64 / extDNS64）を提供する外部サービスプロバイダー。
6. A 464XLAT customer-side translator (CLAT).
6. 464XLAT顧客側トランスレータ（CLAT）。
Note that the nomenclature used in parentheses is the one that, for short, will be used in the figures. Note: for simplicity, the boxes in the figures don't mean they are actually a single device; they represent one or more functions as located in that part of the network (i.e., a single box with NAT64 and DNS64 functions can actually be several devices, not just one).
括弧内で使用されている用語は、略して、図で使用されるものであることに注意してください。注：簡単にするために、図中のボックスは、それらが実際に単一のデバイスであることを意味するものではありません。それらは、ネットワークのその部分にある1つ以上の機能を表します（つまり、NAT64およびDNS64機能を備えた単一のボックスは、実際には1つだけではなく複数のデバイスになる場合があります）。
The possible scenarios are split in two general categories:
考えられるシナリオは、2つの一般的なカテゴリに分けられます。
1. Known to work.
1. 動作することが知られています。
2. Known to work under special conditions.
2. 特別な条件下で動作することが知られています。
The scenarios in this category are known to work, as there are well-known existing deployments from different operators using them. Each one may have different pros and cons, and in some cases, the trade-offs may be acceptable for some operators.
このカテゴリーのシナリオは、それらを使用するさまざまなオペレーターからの既知の既存のデプロイメントがあるため、機能することがわかっています。それぞれに長所と短所があり、場合によっては、一部のオペレーターにとってはトレードオフが許容されることがあります。
In this scenario (Figure 1), the service provider offers both the NAT64 and DNS64 functions.
このシナリオ（図1）では、サービスプロバイダーがNAT64機能とDNS64機能の両方を提供しています。
This is the most common scenario as originally considered by the designers of NAT64 [RFC6146] and DNS64 [RFC6147]; however, it may also have the implications related to the DNSSEC.
これは、NAT64 [RFC6146]およびDNS64 [RFC6147]の設計者によって最初に検討された最も一般的なシナリオです。ただし、DNSSECに関連する可能性もあります。
This scenario may also fail to solve the issues of IPv4 literal addresses, non-IPv6-compliant APIs, or IPv4-only hosts or applications behind the IPv6-only access network.
このシナリオでは、IPv4リテラルアドレス、非IPv6準拠のAPI、またはIPv6のみのアクセスネットワークの背後にあるIPv4のみのホストまたはアプリケーションの問題も解決できない場合があります。
+----------+ +----------+ +----------+
| | | NAT64 | | |
| IPv6 +--------+ + +--------+ IPv4 |
| | | DNS64 | | |
+----------+ +----------+ +----------+
Figure 1: NAT64 with DNS64
図1：DNS64を使用したNAT64
A similar scenario (Figure 2) exists if the service provider offers only the DNS64 function; the NAT64 function is provided by an outsourcing agreement with an external provider. All the considerations in the previous paragraphs of this section are the same for this sub-case.
サービスプロバイダーがDNS64機能のみを提供する場合も、同様のシナリオ（図2）が存在します。 NAT64機能は、外部プロバイダーとのアウトソーシング契約によって提供されます。このセクションの前の段落のすべての考慮事項は、このサブケースでも同じです。
+----------+ +----------+
| | | |
| extNAT64 +--------+ IPv4 |
| | | |
+----+-----+ +----------+
|
|
+----------+ +----+-----+
| | | |
| IPv6 +--------+ DNS64 +
| | | |
+----------+ +----------+
Figure 2: NAT64 in an External Service Provider
図2：外部サービスプロバイダーのNAT64
This is equivalent to the scenario (Figure 3) where the outsourcing agreement with the external provider is to provide both the NAT64 and DNS64 functions. Once more, all the considerations in the previous paragraphs of this section are the same for this sub-case.
これは、外部プロバイダーとのアウトソーシング契約がNAT64機能とDNS64機能の両方を提供することであるシナリオ（図3）と同等です。ここでも、このセクションの前の段落のすべての考慮事項は、このサブケースについて同じです。
+----------+ +----------+
| extNAT64 | | |
| + +-------+ IPv4 |
| extDNS64 | | |
+----+-----+ +----------+
|
+----------+ |
| | |
| IPv6 +-------------+
| |
+----------+
Figure 3: NAT64 and DNS64 in an External Provider
図3：外部プロバイダーのNAT64およびDNS64
One additional equivalent scenario (Figure 4) exists if the service provider only offers the NAT64 function; the DNS64 function is from an external provider with or without a specific agreement among them. This is a common scenario today, as several "global" service providers provide free DNS/DNS64 services, and users often configure their DNS manually. This will only work if both the NAT64 and DNS64 functions are using the Well-Known Prefix (WKP) or the same Network-Specific Prefix (NSP). All the considerations in the previous paragraphs of this section are the same for this sub-case.
サービスプロバイダーがNAT64機能のみを提供している場合、同等のシナリオが1つ追加されます（図4）。 DNS64関数は、外部プロバイダーからのものであり、それらの間で特定の合意がある場合とない場合があります。これは今日の一般的なシナリオです。いくつかの「グローバル」サービスプロバイダーが無料のDNS / DNS64サービスを提供しており、ユーザーはDNSを手動で構成することがよくあります。これは、NAT64機能とDNS64機能の両方が既知のプレフィックス（WKP）または同じネットワーク固有のプレフィックス（NSP）を使用している場合にのみ機能します。このセクションの前の段落のすべての考慮事項は、このサブケースでも同じです。
Of course, if the external DNS64 function is agreed with the service provider, then this case is similar to the ones already depicted in this scenario.
もちろん、外部DNS64機能がサービスプロバイダーと合意している場合、このケースはこのシナリオですでに示したケースと似ています。
+----------+
| |
| extDNS64 |
| |
+----+-----+
|
|
+----------+ +----+-----+ +----------+
| | | | | |
| IPv6 +--------+ NAT64 +--------+ IPv4 |
| | | | | |
+----------+ +----------+ +----------+
Figure 4: NAT64; DNS64 by an External Provider
図4：NAT64;外部プロバイダーによるDNS64
464XLAT [RFC6877] describes an architecture that provides IPv4 connectivity across a network, or part of it, when it is only natively transporting IPv6. The need to support the CLAT function in order to ensure the IPv4 service continuity in IPv6-only cellular deployments has been suggested in [RFC7849].
464XLAT [RFC6877]は、IPv6をネイティブにのみ転送する場合に、ネットワーク全体またはその一部にIPv4接続を提供するアーキテクチャについて説明しています。 [RFC7849]では、IPv6のみのセルラー展開でIPv4サービスの継続性を確保するためにCLAT機能をサポートする必要性が示唆されています。
In order to do that, 464XLAT [RFC6877] relies on the combination of existing protocols:
そのために、464XLAT [RFC6877]は既存のプロトコルの組み合わせに依存しています。
1. The CLAT is a stateless IPv4-to-IPv6 translator (NAT46) [RFC7915] implemented in the end-user device or Customer Edge Router (CE), located at the "customer edge" of the network.
1. CLATは、ネットワークの「カスタマーエッジ」にあるエンドユーザーデバイスまたはカスタマーエッジルーター（CE）に実装されているステートレスIPv4-to-IPv6トランスレーター（NAT46）[RFC7915]です。
2. The provider-side translator (PLAT) is a stateful NAT64 [RFC6146], implemented typically in the operator network.
2. プロバイダー側トランスレーター（PLAT）は、通常はオペレーターネットワークで実装されるステートフルNAT64 [RFC6146]です。
3. Optionally, DNS64 [RFC6147] may allow an optimization: a single translation at the NAT64, instead of two translations (NAT46+NAT64), when the application at the end-user device supports IPv6 DNS (uses AAAA Resource Records).
3. オプションで、DNS64 [RFC6147]は最適化を許可する場合があります。エンドユーザーデバイスのアプリケーションがIPv6 DNSをサポートする場合（AAAAリソースレコードを使用）、2つの変換（NAT46 + NAT64）ではなく、NAT64での単一の変換です。
Note that even if the provider-side translator is referred to as PLAT in the 464XLAT terminology [RFC6877], for simplicity and uniformity across this document, it is always referred to as NAT64 (function).
プロバイダー側のトランスレータが464XLAT用語[RFC6877]でPLATと呼ばれている場合でも、このドキュメント全体での単純さと統一性のために、常にNAT64（関数）と呼ばれていることに注意してください。
In this scenario (Figure 5), the service provider deploys 464XLAT with a DNS64 function.
このシナリオ（図5）では、サービスプロバイダーはDNS64関数を使用して464XLATを展開します。
As a consequence, the DNSSEC issues remain, unless the host is doing the address synthesis.
結果として、ホストがアドレス合成を行わない限り、DNSSECの問題は残ります。
464XLAT [RFC6877] is a very simple approach to cope with the major NAT64+DNS64 drawback: not working with applications or devices that use literal IPv4 addresses or non-IPv6-compliant APIs.
464XLAT [RFC6877]は、NAT64 + DNS64の主な欠点に対処するための非常に単純なアプローチです。リテラルIPv4アドレスまたは非IPv6準拠のAPIを使用するアプリケーションまたはデバイスでは機能しません。
464XLAT [RFC6877] has been used mainly in IPv6-only cellular networks. By supporting a CLAT function, end-user device applications can access IPv4-only end networks / applications, despite the fact that those applications or devices use literal IPv4 addresses or non-IPv6-compliant APIs.
464XLAT [RFC6877]は、主にIPv6のみのセルラーネットワークで使用されています。 CLAT機能をサポートすることにより、エンドユーザーデバイスアプリケーションは、IPv4のみのエンドネットワーク/アプリケーションにアクセスできます。これらのアプリケーションまたはデバイスは、リテラルIPv4アドレスまたは非IPv6準拠のAPIを使用しています。
In addition, in the cellular network example above, if the User Equipment (UE) provides tethering, other devices behind it will be presented with a traditional Network Address Translation from IPv4 to IPv4 (NAT44), in addition to the native IPv6 support, so clearly it allows IPv4-only hosts behind the IPv6-only access network.
さらに、上記のセルラーネットワークの例では、ユーザー機器（UE）がテザリングを提供している場合、その背後にある他のデバイスに、ネイティブIPv6サポートに加えて、IPv4からIPv4（NAT44）への従来のネットワークアドレス変換が提示されます。明らかに、IPv6のみのアクセスネットワークの背後にあるIPv4のみのホストを許可します。
Furthermore, as discussed in [RFC6877], 464XLAT can be used in broadband IPv6 network architectures, by implementing the CLAT function at the CE.
さらに、[RFC6877]で説明されているように、464XLATは、CEにCLAT機能を実装することにより、ブロードバンドIPv6ネットワークアーキテクチャで使用できます。
The support of this scenario in a network offers two additional advantages:
ネットワークでのこのシナリオのサポートには、さらに2つの利点があります。
* DNS load optimization: A CLAT should implement a DNS proxy (per [RFC5625]) so that only IPv6-native queries and AAAA records are sent to the DNS64 server. Otherwise, doubling the number of queries may impact the DNS infrastructure.
* DNS負荷の最適化：IPv6ネイティブクエリとAAAAレコードのみがDNS64サーバーに送信されるように、CLATは（[RFC5625]に従って）DNSプロキシを実装する必要があります。それ以外の場合、クエリの数を2倍にすると、DNSインフラストラクチャに影響を与える可能性があります。
* Connection establishment delay optimization: If the UE/CE implementation is detecting the presence of a DNS64 function, it may issue only the AAAA query, instead of both the AAAA and A queries.
* 接続確立遅延の最適化：UE / CE実装がDNS64関数の存在を検出している場合、AAAAクエリとAクエリの両方ではなく、AAAAクエリのみを発行する場合があります。
In order to understand all the communication possibilities, let's assume the following representation of two dual-stack (DS) peers:
すべての通信の可能性を理解するために、2つのデュアルスタック（DS）ピアの次の表現を想定します。
+-------+ .-----. .-----.
| | / \ / \
.-----. | Res./ | / IPv6- \ .-----. / IPv4- \
/ Local \ | SOHO +--( only )---( NAT64 )---( only )
/ \ | | \ flow /\ `-----' \ flow /
( Dual- )--+ IPv6 | \ / \ / \ /
\ Stack / | CE | `--+--' \ .-----. / `--+--'
\ Peer / | with | | \ / Remote\/ |
`-----' | CLAT | +---+----+ / \ +---+----+
| | |DNS/IPv6| ( Dual- ) |DNS/IPv4|
+-------+ | with | \ Stack / +--------+
| DNS64 | \ Peer /
+--------+ `-----'
Figure A: Representation of 464XLAT among Two Peers with DNS64
図A：DNS64を使用する2つのピア間の464XLATの表現
In this case, the possible communication paths, among the IPv4/IPv6 stacks of both peers, are as follows:
この場合、両方のピアのIPv4 / IPv6スタック間で可能な通信パスは次のとおりです。
a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among peers.
a. ローカルIPv6からリモートIPv6：ピア間の通常のDNSおよびネイティブIPv6。
b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation.
b. ローカルIPv6からリモートIPv4へ：DNS64およびNAT64変換。
c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT implements Explicit Address Mappings (EAMs) as indicated by Section 4.9. In principle, it is not expected that services are deployed in the Internet when using IPv6 only, unless there is certainty that peers will also be IPv6 capable.
c. ローカルIPv4からリモートIPv6へ：CLATがセクション4.9で示すように明示的アドレスマッピング（EAM）を実装しない限り、不可能です。原則として、ピアもIPv6対応であることが確実でない限り、IPv6のみを使用する場合にインターネットでサービスが展開されることは想定されていません。
d. Local-IPv4 to Remote-IPv4: DNS64, CLAT, and NAT64 translations.
d. ローカルIPv4からリモートIPv4へ：DNS64、CLAT、およびNAT64変換。
e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the CLAT implements EAM as indicated by Section 4.9, instead of using the path d. above, NAT64 translation is avoided, and the flow will use IPv6 from the CLAT to the destination.
e. EAM最適化を使用したローカルIPv4からリモートデュアルスタックへ：CLATがセクション4.9で示すようにEAMを実装する場合、パスdを使用する代わりに。上記では、NAT64変換は回避され、フローはCLATから宛先へのIPv6を使用します。
The rest of the figures in this section show different choices for placing the different elements.
このセクションの残りの図は、さまざまな要素を配置するためのさまざまな選択肢を示しています。
+----------+ +----------+ +----------+
| IPv6 | | NAT64 | | |
| + +--------+ + +--------+ IPv4 |
| CLAT | | DNS64 | | |
+----------+ +----------+ +----------+
Figure 5: 464XLAT with DNS64
図5：DNS64を使用した464XLAT
A similar scenario (Figure 6) exists if the service provider only offers the DNS64 function; the NAT64 function is provided by an outsourcing agreement with an external provider. All the considerations in the previous paragraphs of this section are the same for this sub-case.
サービスプロバイダーがDNS64機能のみを提供している場合も、同様のシナリオ（図6）が存在します。 NAT64機能は、外部プロバイダーとのアウトソーシング契約によって提供されます。このセクションの前の段落のすべての考慮事項は、このサブケースでも同じです。
+----------+ +----------+
| | | |
| extNAT64 +--------+ IPv4 |
| | | |
+----+-----+ +----------+
|
|
+----------+ +----+-----+
| IPv6 | | |
| + +--------+ DNS64 +
| CLAT | | |
+----------+ +----------+
Figure 6: 464XLAT with DNS64; NAT64 in an External Provider
図6：DNS64を使用した464XLAT;外部プロバイダーのNAT64
In addition, it is equivalent to the scenario (Figure 7) where the outsourcing agreement with the external provider is to provide both the NAT64 and DNS64 functions. Once more, all the considerations in the previous paragraphs of this section are the same for this sub-case.
さらに、外部プロバイダーとのアウトソーシング契約がNAT64機能とDNS64機能の両方を提供することであるシナリオ（図7）と同等です。ここでも、このセクションの前の段落のすべての考慮事項は、このサブケースについて同じです。
+----------+ +----------+
| extNAT64 | | |
| + +--------+ IPv4 |
| extDNS64 | | |
+----+-----+ +----------+
|
+----------+ |
| IPv6 | |
| + +-------------+
| CLAT |
+----------+
Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in an External Provider
図7：DNS64を使用した464XLAT;外部プロバイダーのNAT64およびDNS64
The major advantage of this scenario (Figure 8), using 464XLAT without DNS64, is that the service provider ensures that DNSSEC is never broken, even if the user modifies the DNS configuration. Nevertheless, some CLAT implementations or applications may impose an extra delay, which is induced by the dual A/AAAA queries (and the wait for both responses), unless Happy Eyeballs v2 [RFC8305] is also present.
DNS64を使用せずに464XLATを使用するこのシナリオ（図8）の主な利点は、ユーザーがDNS構成を変更した場合でも、サービスプロバイダーがDNSSECが破損しないことを保証することです。それでも、Happy Eyeballs v2 [RFC8305]が存在しない場合を除き、一部のCLAT実装またはアプリケーションは、デュアルA / AAAAクエリ（および両方の応答の待機）によって引き起こされる追加の遅延を課す場合があります。
A possible variation of this scenario is when DNS64 is used only for the discovery of the NAT64 prefix. In the rest of the document, it is not considered a different scenario because once the prefix has been discovered, the DNS64 function is not used, so it behaves as if the DNS64 synthesis function is not present.
このシナリオの可能なバリエーションは、DNS64がNAT64プレフィックスの検出にのみ使用される場合です。ドキュメントの残りの部分では、プレフィックスが検出されるとDNS64関数が使用されないため、DNS64合成関数が存在しないかのように動作するため、別のシナリオとは見なされません。
In this scenario, as in the previous one, there are no issues related to IPv4-only hosts (or IPv4-only applications) behind the IPv6-only access network, as neither are related to the usage of IPv4 literals or non-IPv6-compliant APIs.
このシナリオでは、前のシナリオと同様に、IPv4リテラルまたは非IPv6-準拠API。
The support of this scenario in a network offers one advantage:
ネットワークでのこのシナリオのサポートには、1つの利点があります。
* DNS load optimization: A CLAT should implement a DNS proxy (per [RFC5625]) so that only IPv6 native queries are sent to the DNS64 server. Otherwise, doubling the number of queries may impact the DNS infrastructure.
* DNS負荷の最適化：IPv6ネイティブクエリのみがDNS64サーバーに送信されるように、CLATは（[RFC5625]に従って）DNSプロキシを実装する必要があります。それ以外の場合、クエリの数を2倍にすると、DNSインフラストラクチャに影響を与える可能性があります。
As indicated earlier, the connection establishment delay optimization is achieved only in the case of devices, Operating Systems, or applications that use Happy Eyeballs v2 [RFC8305], which is very common.
前述のように、接続確立遅延の最適化は、Happy Eyeballs v2 [RFC8305]を使用するデバイス、オペレーティングシステム、またはアプリケーションの場合にのみ達成されます。これは非常に一般的です。
As in the previous case, let's assume the representation of two dual-stack peers:
前のケースと同様に、2つのデュアルスタックピアの表現を想定します。
+-------+ .-----. .-----.
| | / \ / \
.-----. | Res./ | / IPv6- \ .-----. / IPv4- \
/ Local \ | SOHO +--( only )---( NAT64 )---( only )
/ \ | | \ flow /\ `-----' \ flow /
( Dual- )--+ IPv6 | \ / \ / \ /
\ Stack / | CE | `--+--' \ .-----. / `--+--'
\ Peer / | with | | \ / Remote\/ |
`-----' | CLAT | +---+----+ / \ +---+----+
| | |DNS/IPv6| ( Dual- ) |DNS/IPv4|
+-------+ +--------+ \ Stack / +--------+
\ Peer /
`-----'
Figure B: Representation of 464XLAT among Two Peers without DNS64
図B：DNS64のない2つのピア間の464XLATの表現
In this case, the possible communication paths, among the IPv4/IPv6 stacks of both peers, are as follows:
この場合、両方のピアのIPv4 / IPv6スタック間で可能な通信パスは次のとおりです。
a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among peers.
a. ローカルIPv6からリモートIPv6：ピア間の通常のDNSおよびネイティブIPv6。
b. Local-IPv6 to Remote-IPv4: Regular DNS, CLAT, and NAT64 translations.
b. ローカルIPv6からリモートIPv4へ：通常のDNS、CLAT、およびNAT64変換。
c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT implements EAM as indicated by Section 4.9. In principle, it is not expected that services are deployed in the Internet using IPv6 only, unless there is certainty that peers will also be IPv6-capable.
c. ローカルIPv4からリモートIPv6へ：CLATがセクション4.9で示すようにEAMを実装しない限り、不可能です。原則として、ピアもIPv6対応であることが確実でない限り、サービスがIPv6のみを使用してインターネットに展開されることは想定されていません。
d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT, and NAT64 translations.
d. ローカルIPv4からリモートIPv4へ：通常のDNS、CLAT、およびNAT64変換。
e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the CLAT implements EAM as indicated by Section 4.9, instead of using the path d. above, NAT64 translation is avoided, and the flow will use IPv6 from the CLAT to the destination.
e. EAM最適化を使用したローカルIPv4からリモートデュアルスタックへ：CLATがセクション4.9で示すようにEAMを実装する場合、パスdを使用する代わりに。上記では、NAT64変換は回避され、フローはCLATから宛先へのIPv6を使用します。
Notice that this scenario works while the local hosts/applications are dual stack (which is the current situation) because the connectivity from a local IPv6 to a remote IPv4 is not possible without a AAAA synthesis. This aspect is important only when there are IPv6-only hosts in the LANs behind the CLAT and they need to communicate with remote IPv4-only hosts. However, it is not a sensible approach from an Operating System or application vendor perspective to provide IPv6-only support unless, similar to case c above, there is certainty of peers supporting IPv6 as well. An approach to a solution for this is also presented in [OPT-464XLAT].
AAAA合成がないとローカルIPv6からリモートIPv4への接続ができないため、このシナリオはローカルホスト/アプリケーションがデュアルスタック（現在の状況）であるときに機能します。この側面は、CLATの背後にあるLANにIPv6のみのホストがあり、リモートのIPv4のみのホストと通信する必要がある場合にのみ重要です。ただし、上記のケースcと同様に、ピアがIPv6もサポートする確実性がない限り、IPv6のみのサポートを提供することは、オペレーティングシステムまたはアプリケーションベンダーの観点からの賢明なアプローチではありません。この解決策へのアプローチは、[OPT-464XLAT]にも示されています。
The following figures show different choices for placing the different elements.
次の図は、さまざまな要素を配置するためのさまざまな選択肢を示しています。
+----------+ +----------+ +----------+
| IPv6 | | | | |
| + +--------+ NAT64 +--------+ IPv4 |
| CLAT | | | | |
+----------+ +----------+ +----------+
Figure 8: 464XLAT without DNS64
図8：DNS64なしの464XLAT
This is equivalent to the scenario (Figure 9) where there is an outsourcing agreement with an external provider for the NAT64 function. All the considerations in the previous paragraphs of this section are the same for this sub-case.
これは、NAT64機能の外部プロバイダーとの外部委託契約があるシナリオ（図9）と同等です。このセクションの前の段落のすべての考慮事項は、このサブケースでも同じです。
+----------+ +----------+
| | | |
| extNAT64 +--------+ IPv4 |
| | | |
+----+-----+ +----------+
|
+----------+ |
| IPv6 | |
| + +-------------+
| CLAT |
+----------+
Figure 9: 464XLAT without DNS64; NAT64 in an External Provider
図9：DNS64なしの464XLAT;外部プロバイダーのNAT64
The scenarios in this category are known not to work unless significant effort is devoted to solving the issues or they are intended to solve problems across "closed" networks instead of as a general Internet access usage. Even though some of the different pros, cons, and trade-offs may be acceptable, operators have implementation difficulties, as their expectations of NAT64/DNS64 are beyond the original intent.
このカテゴリのシナリオは、問題の解決に多大な労力が費やされない限り、または一般的なインターネットアクセスの使用ではなく、「閉じた」ネットワーク全体の問題を解決することを目的としない限り、機能しないことがわかっています。さまざまな長所、短所、およびトレードオフの一部は許容できるかもしれませんが、NAT64 / DNS64に対する期待が当初の意図を超えているため、オペレーターは実装に困難を抱えています。
In this scenario (Figure 10), the service provider offers a NAT64 function; however, there is no DNS64 function support at all.
このシナリオ（図10）では、サービスプロバイダーがNAT64機能を提供しています。ただし、DNS64関数のサポートはまったくありません。
As a consequence, an IPv6 host in the IPv6-only access network will not be able to detect the presence of DNS64 by means of [RFC7050] or learn the IPv6 prefix to be used for the NAT64 function.
結果として、IPv6のみのアクセスネットワークのIPv6ホストは、[RFC7050]を使用してDNS64の存在を検出したり、NAT64機能に使用されるIPv6プレフィックスを学習したりできません。
This can be sorted out as indicated in Section 4.1.1.
これは、セクション4.1.1に示すようにソートできます。
Regardless, because of the lack of the DNS64 function, the IPv6 host will not be able to obtain AAAA synthesized records, so the NAT64 function becomes useless.
とにかく、DNS64機能がないため、IPv6ホストはAAAA合成レコードを取得できず、NAT64機能は役に立たなくなります。
An exception to this "useless" scenario is to manually configure mappings between the A records of each of the IPv4-only remote hosts and the corresponding AAAA records with the WKP or NSP used by the service-provider NAT64 function, as if they were synthesized by a DNS64 function.
この「役に立たない」シナリオの例外は、IPv4のみの各リモートホストのAレコードと、サービスプロバイダーのNAT64関数で使用されるWKPまたはNSPを使用して対応するAAAAレコード間のマッピングを手動で構成することです。 DNS64関数による。
This mapping could be done by several means, typically at the authoritative DNS server or at the service-provider resolvers by means of DNS Response Policy Zones (RPZs) [DNS-RPZ] or equivalent functionality. DNS RPZ may have implications in DNSSEC if the zone is signed. Also, if the service provider is using an NSP, having the mapping at the authoritative server may create troubles for other parties trying to use a different NSP or WKP, unless multiple DNS "views" (split-DNS) are also being used at the authoritative servers.
このマッピングは、いくつかの方法で行うことができます。通常は、権威DNSサーバーまたはサービスプロバイダーリゾルバーで、DNS応答ポリシーゾーン（RPZ）[DNS-RPZ]または同等の機能を使用します。ゾーンが署名されている場合、DNS RPZはDNSSECに影響を与える可能性があります。また、サービスプロバイダーがNSPを使用している場合、権限のあるサーバーでマッピングを行うと、複数のDNS "ビュー"（スプリットDNS）も使用されていない限り、他の当事者が別のNSPまたはWKPを使用しようとすると問題が発生する可能性があります。権限のあるサーバー。
Generally, the mappings alternative will only make sense if a few sets of IPv4-only remote hosts need to be accessed by a single network (or a small number of them), which supports IPv6 only in the access. This will require some kind of mutual agreement for using this procedure; this should not be a problem because it won't interfere with Internet use (which is a "closed service").
一般に、マッピングの代替は、IPv6のみをアクセスでサポートする単一のネットワーク（または少数）からIPv4のみのリモートホストのいくつかのセットにアクセスする必要がある場合にのみ意味があります。これには、この手順を使用するための何らかの相互合意が必要です。これはインターネットの使用（「クローズドサービス」）を妨害しないため、問題にはなりません。
In any case, this scenario doesn't solve the issue of IPv4 literal addresses, non-IPv6-compliant APIs, or IPv4-only hosts within that IPv6-only access network.
いずれにしても、このシナリオでは、IPv4リテラルアドレス、非IPv6準拠のAPI、またはそのIPv6のみのアクセスネットワーク内のIPv4のみのホストの問題は解決されません。
+----------+ +----------+ +----------+
| | | | | |
| IPv6 +--------+ NAT64 +--------+ IPv4 |
| | | | | |
+----------+ +----------+ +----------+
Figure 10: NAT64 without DNS64
図10：DNS64を使用しないNAT64
In this scenario (Figure 11), the service provider offers the NAT64 function but not the DNS64 function. However, the IPv6 hosts have a built-in DNS64 function.
このシナリオ（図11）では、サービスプロバイダーはNAT64機能を提供しますが、DNS64機能は提供しません。ただし、IPv6ホストにはDNS64機能が組み込まれています。
This may become common if the DNS64 function is implemented in all the IPv6 hosts/stacks. This is not common at the time of writing but may become more common in the near future. This way, the DNSSEC validation is performed on the A record, and then the host can use the DNS64 function in order to use the NAT64 function without any DNSSEC issues.
これは、DNS64機能がすべてのIPv6ホスト/スタックに実装されている場合に一般的になる可能性があります。これは、執筆時点では一般的ではありませんが、近い将来、より一般的になる可能性があります。このように、AレコードでDNSSEC検証が実行され、ホストはDNS64関数を使用して、DNSSEC問題なしでNAT64関数を使用できます。
This scenario fails to solve the issue of IPv4 literal addresses or non-IPv6-compliant APIs, unless the IPv6 hosts also support Happy Eyeballs v2 (Section 7.1 of [RFC8305]).
このシナリオでは、IPv6ホストがHappy Eyeballs v2（[RFC8305]のセクション7.1）もサポートしていない限り、IPv4リテラルアドレスまたは非IPv6準拠のAPIの問題を解決できません。
Moreover, this scenario also fails to solve the problem of IPv4-only hosts or applications behind the IPv6-only access network.
さらに、このシナリオでは、IPv6のみのアクセスネットワークの背後にあるIPv4のみのホストまたはアプリケーションの問題も解決できません。
+----------+ +----------+ +----------+
| IPv6 | | | | |
| + +--------+ NAT64 +--------+ IPv4 |
| DNS64 | | | | |
+----------+ +----------+ +----------+
Figure 11: NAT64; DNS64 in IPv6 Hosts
図11：NAT64; IPv6ホストのDNS64
In this scenario (Figure 12), the service provider offers the NAT64 function only. The IPv4-only remote network offers the DNS64 function.
このシナリオ（図12）では、サービスプロバイダーはNAT64機能のみを提供します。 IPv4のみのリモートネットワークはDNS64機能を提供します。
This is not common, and it doesn't make sense that a remote network, not deploying IPv6, is providing a DNS64 function. Like the scenario depicted in Section 3.2.1, it will only work if both sides are using the WKP or the same NSP, so the same considerations apply. It can also be tuned to behave as in Section 3.1.1.
これは一般的ではなく、IPv6を展開していないリモートネットワークがDNS64機能を提供していることは意味がありません。セクション3.2.1に示したシナリオと同様に、両方がWKPまたは同じNSPを使用している場合にのみ機能するため、同じ考慮事項が適用されます。セクション3.1.1のように動作するように調整することもできます。
This scenario fails to solve the issue of IPv4 literal addresses or non-IPv6-compliant APIs.
このシナリオでは、IPv4リテラルアドレスまたは非IPv6準拠のAPIの問題を解決できません。
Moreover, this scenario also fails to solve the problem of IPv4-only hosts or applications behind the IPv6-only access network.
さらに、このシナリオでは、IPv6のみのアクセスネットワークの背後にあるIPv4のみのホストまたはアプリケーションの問題も解決できません。
+----------+ +----------+ +----------+
| | | | | IPv4 |
| IPv6 +--------+ NAT64 +--------+ + |
| | | | | DNS64 |
+----------+ +----------+ +----------+
Figure 12: NAT64; DNS64 in IPv4-Only Hosts
図12：NAT64; IPv4専用ホストのDNS64
This section compares the different scenarios, including possible variations (each one represented in the previous sections by a different figure), while considering the following criteria:
このセクションでは、次の基準を考慮しながら、考えられるバリエーション（前のセクションでは別の図で示したもの）を含むさまざまなシナリオを比較します。
a. DNSSEC: Are there hosts validating DNSSEC?
a. DNSSEC：DNSSECを検証するホストはありますか？
b. Literal/APIs: Are there applications using IPv4 literals or non-IPv6-compliant APIs?
b. リテラル/ API：IPv4リテラルまたは非IPv6準拠のAPIを使用するアプリケーションはありますか？
c. IPv4 only: Are there hosts or applications using IPv4 only?
c. IPv4のみ：IPv4のみを使用するホストまたはアプリケーションはありますか？
d. Foreign DNS: Does the scenario survive if the user, Operating System, applications, or devices change the DNS?
d. 外部DNS：ユーザー、オペレーティングシステム、アプリケーション、またはデバイスがDNSを変更しても、シナリオは存続しますか？
e. DNS load opt. (DNS load optimization): Are there extra queries that may impact the DNS infrastructure?
e. DNSロードオプション（DNS負荷の最適化）：DNSインフラストラクチャに影響を与える可能性のある追加のクエリはありますか？
f. Connect. opt. (connection establishment delay optimization): Is the UE/CE only issuing the AAAA query or also the A query and waiting for both responses?
f. 接続します。選ぶ。 （接続確立遅延の最適化）：UE / CEはAAAAクエリのみを発行しますか、それともAクエリも発行し、両方の応答を待機していますか？
In the table below, the columns represent each of the scenarios from the previous sections by the figure number. The possible values are as follows:
次の表の列は、前のセクションの各シナリオを図番号で表しています。可能な値は次のとおりです。
"-" means the scenario is "bad" for that criterion.
「-」は、シナリオがその基準に対して「悪い」ことを意味します。
"+" means the scenario is "good" for that criterion.
「+」は、シナリオがその基準に対して「良好」であることを意味します。
"*" means the scenario is "bad" for that criterion; however, it is typically resolved with the support of Happy Eyeballs v2 [RFC8305].
「*」は、シナリオがその基準に対して「悪い」ことを意味します。ただし、通常はHappy Eyeballs v2 [RFC8305]のサポートにより解決されます。
In some cases, "countermeasures", alternative or special configurations, may be available for the criterion designated as "bad". So, this comparison is considering a generic case as a quick comparison guide. In some cases, a "bad" criterion is not necessarily a negative aspect; it all depends on the specific needs/ characteristics of the network where the deployment will take place. For instance, in a network that only has IPv6-only hosts and apps using DNS and IPv6-compliant APIs, there is no impact using only NAT64 and DNS64, but if the hosts validate DNSSEC, that criterion is still relevant.
場合によっては、「悪い」と指定された基準に対して、「対策」、代替構成または特別な構成が利用できる場合があります。したがって、この比較では、一般的なケースを簡単な比較ガイドとして検討しています。場合によっては、「悪い」基準は必ずしも否定的な側面ではありません。それはすべて、展開が行われるネットワークの特定のニーズ/特性に依存します。たとえば、DNSとIPv6に準拠したAPIを使用するIPv6のみのホストとアプリのみがあるネットワークでは、NAT64とDNS64のみを使用しても影響はありませんが、ホストがDNSSECを検証する場合、その基準は依然として関連しています。
+---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
+===============+===+===+===+===+===+===+===+===+===+====+====+====+
| DNSSEC | - | - | - | - | - | - | - | + | + | + | + | + |
+---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Literal/APIs | - | - | - | - | + | + | + | + | + | - | - | - |
+---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| IPv4-only | - | - | - | - | + | + | + | + | + | - | - | - |
+---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Foreign DNS | - | - | - | - | + | + | + | + | + | - | + | - |
+---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| DNS load opt. | + | + | + | + | + | + | + | + | + | + | + | + |
+---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Connect. opt. | + | + | + | + | + | + | + | * | * | + | + | + |
+---------------+---+---+---+---+---+---+---+---+---+----+----+----+
Table 1: Scenario Comparison
表1：シナリオの比較
As a general conclusion, we should note if the network must support applications using any of the following:
一般的な結論として、ネットワークが次のいずれかを使用するアプリケーションをサポートする必要があるかどうかに注意する必要があります。
* IPv4 literals
* IPv4リテラル
* non-IPv6-compliant APIs
* 非IPv6準拠API
* IPv4-only hosts or applications
* IPv4のみのホストまたはアプリケーション
Then, only the scenarios with 464XLAT, a CLAT function, or equivalent built-in local address synthesis features will provide a valid solution. Furthermore, those scenarios will also keep working if the DNS configuration is modified. Clearly, depending on if DNS64 is used or not, DNSSEC may be broken for those hosts doing DNSSEC validation.
次に、464XLAT、CLAT関数、または同等の組み込みローカルアドレス合成機能を備えたシナリオのみが有効なソリューションを提供します。さらに、DNS構成が変更されても、これらのシナリオは機能し続けます。明らかに、DNS64が使用されているかどうかに応じて、DNSSEC検証を実行しているホストでDNSSECが壊れる可能性があります。
All the scenarios are good in terms of DNS load optimization, and in the case of 464XLAT, it may provide an extra degree of optimization. Finally, all of the scenarios are also good in terms of connection establishment delay optimization. However, in the case of 464XLAT without DNS64, the usage of Happy Eyeballs v2 is required. This is not an issue as it is commonly available in actual Operating Systems.
すべてのシナリオはDNS負荷の最適化の点で優れており、464XLATの場合は、追加の最適化が提供される可能性があります。最後に、すべてのシナリオは、接続確立遅延の最適化の点でも優れています。ただし、DNS64を使用しない464XLATの場合、Happy Eyeballs v2の使用が必要です。これは実際のオペレーティングシステムで一般的に利用できるため、問題ではありません。
This section reviews the different issues that an operator needs to consider for a NAT64/464XLAT deployment, as they may develop specific decision points about how to approach that deployment.
このセクションでは、NAT64 / 464XLATの展開についてオペレーターが検討する必要のあるさまざまな問題について説明します。これらの問題は、展開へのアプローチ方法に関する特定の決定ポイントを開発する可能性があるためです。
As indicated in the security considerations for DNS64 (see Section 8 of [RFC6147]) because DNS64 modifies DNS answers and DNSSEC is designed to detect such modifications, DNS64 may break DNSSEC.
DNS64はDNSの回答を変更し、DNSSECはそのような変更を検出するように設計されているため、DNS64のセキュリティに関する考慮事項（[RFC6147]のセクション8を参照）に示されているように、DNSSECが機能しなくなる可能性があります。
When a device connected to an IPv6-only access network queries for a domain name in a signed zone, by means of a recursive name server that supports DNS64, the result may be a synthesized AAAA record. In that case, if the recursive name server is configured to perform DNSSEC validation and has a valid chain of trust to the zone in question, it will cryptographically validate the negative response from the authoritative name server. This is the expected DNS64 behavior: the recursive name server actually "lies" to the client device. However, in most of the cases, the client will not notice it, because generally, they don't perform validation themselves; instead, they rely on the recursive name servers.
IPv6のみのアクセスネットワークに接続されたデバイスが、DNS64をサポートする再帰的なネームサーバーを使用して、署名済みゾーンのドメイン名をクエリすると、合成されたAAAAレコードが生成される場合があります。その場合、再帰的ネームサーバーがDNSSEC検証を実行するように構成されていて、問題のゾーンへの有効な信頼チェーンがある場合、信頼できるネームサーバーからの否定応答を暗号で検証します。これは、予想されるDNS64の動作です。再帰的なネームサーバーは、実際にはクライアントデバイスに「嘘をついています」。ただし、ほとんどの場合、クライアントはそれを認識しません。これは、通常、自分で検証を実行しないためです。代わりに、それらは再帰的なネームサーバーに依存しています。
In fact, a validating DNS64 resolver increases the confidence on the synthetic AAAA, as it has validated that a non-synthetic AAAA doesn't exist. However, if the client device is oblivious to NAT64 (the most common case) and performs DNSSEC validation on the AAAA record, it will fail as it is a synthesized record.
実際、DNS64リゾルバーを検証すると、非合成AAAAが存在しないことが検証されたため、合成AAAAの信頼性が向上します。ただし、クライアントデバイスがNAT64（最も一般的なケース）に気付かず、AAAAレコードでDNSSEC検証を実行する場合、合成されたレコードであるため失敗します。
The best possible scenario from a DNSSEC point of view is when the client requests that the DNS64 server perform the DNSSEC validation (by setting the DNSSEC OK (DO) bit to 1 and the CD bit to 0). In this case, the DNS64 server validates the data; thus, tampering may only happen inside the DNS64 server (which is considered as a trusted part, thus, its likelihood is low) or between the DNS64 server and the client. All other parts of the system (including transmission and caching) are protected by DNSSEC [Threat-DNS64].
DNSSECの観点から考えられる最良のシナリオは、クライアントがDNS64サーバーにDNSSEC検証を実行するように要求する場合です（DNSSEC OK（DO）ビットを1に、CDビットを0に設定することによって）。この場合、DNS64サーバーはデータを検証します。したがって、改ざんはDNS64サーバー内（信頼された部分と見なされるため、その可能性は低い）またはDNS64サーバーとクライアントの間でのみ発生する可能性があります。システムの他のすべての部分（送信とキャッシングを含む）は、DNSSEC [Threat-DNS64]によって保護されています。
Similarly, if the client querying the recursive name server is another name server configured to use it as a forwarder, and it is performing DNSSEC validation, it will also fail on any synthesized AAAA record.
同様に、再帰的なネームサーバーをクエリするクライアントが、フォワーダーとして使用するように構成された別のネームサーバーであり、DNSSEC検証を実行している場合、合成されたAAAAレコードでも失敗します。
All those considerations are extensively covered in Sections 3, 5.5, and 6.2 of [RFC6147].
これらの考慮事項はすべて、[RFC6147]のセクション3、5.5、および6.2で広範囲にカバーされています。
DNSSEC issues could be avoided if all the signed zones provide IPv6 connectivity together with the corresponding AAAA records. However, this is out of the control of the operator needing to deploy a NAT64 function. This has been proposed already in [DNS-DNSSEC].
すべての署名済みゾーンが対応するAAAAレコードと一緒にIPv6接続を提供する場合、DNSSECの問題を回避できます。ただし、これは、NAT64関数を展開する必要があるオペレーターの制御の範囲外です。これはすでに[DNS-DNSSEC]で提案されています。
An alternative solution, which was considered while developing [RFC6147], is that the validators will be DNS64 aware. Then, they can perform the necessary discovery and do their own synthesis. Since that was standardized sufficiently early in the validator deployment curve, the expectation was that it would be okay to break certain DNSSEC assumptions for networks that were stuck and really needing NAT64/DNS64.
[RFC6147]の開発中に検討された代替ソリューションは、バリデーターがDNS64を認識することです。その後、必要な発見を実行し、独自の合成を行うことができます。これはバリデーターの展開曲線の早い段階で十分に標準化されていたため、スタックしていてNAT64 / DNS64を実際に必要とするネットワークについて、特定のDNSSECの仮定を破っても大丈夫であると予想されていました。
As already indicated, the scenarios in the previous section are simplified to look at the worst possible case and for the most perfect approach. A DNSSEC breach will not happen if the end host is not doing validation.
すでに示したように、前のセクションのシナリオは、最悪のケースと最も完全なアプローチを見るために簡略化されています。エンドホストが検証を行わない場合、DNSSEC違反は発生しません。
The figures in previous studies indicate that DNSSEC broken by using DNS64 makes up about 1.7% [About-DNS64] of the cases. However, we can't negate that this may increase as DNSSEC deployment grows. Consequently, a decision point for the operator must depend on the following question: Do I really care about that percentage of cases and the impact on my help desk, or can I provide alternative solutions for them? Some possible solutions may be exist, as depicted in the next sections.
以前の調査の数値は、DNSSECがDNS64を使用して破損した場合、ケースの約1.7％[About-DNS64]を占めることを示しています。ただし、DNSSECの展開が増えるにつれて、これが増える可能性があることを否定することはできません。したがって、オペレーターの決定ポイントは、次の質問に依存する必要があります。そのケースのパーセンテージとヘルプデスクへの影響を本当に気にかけますか、それとも代替ソリューションを提供できますか？次のセクションで示すように、いくつかの可能な解決策が存在する可能性があります。
One solution is to avoid using DNS64, but as already indicated, this is not possible in all the scenarios.
1つの解決策はDNS64の使用を避けることですが、すでに示したように、これはすべてのシナリオで可能ではありません。
The use of DNS64 is a key component for some networks, in order to comply with traffic performance metrics, monitored by some governmental bodies and other institutions [FCC] [ARCEP].
DNS64の使用は、一部の政府機関や他の機関[FCC] [ARCEP]によって監視されるトラフィックパフォーマンスメトリックに準拠するために、一部のネットワークにとって重要なコンポーネントです。
One drawback of not having a DNS64 on the network side is that it's not possible to heuristically discover NAT64 [RFC7050]. Consequently, an IPv6 host behind the IPv6-only access network will not be able to detect the presence of the NAT64 function, nor learn the IPv6 prefix to be used for it, unless it is configured by alternative means.
ネットワーク側にDNS64がないことの1つの欠点は、NAT64 [RFC7050]を発見的に発見できないことです。その結果、IPv6のみのアクセスネットワークの背後にあるIPv6ホストは、NAT64機能の存在を検出できず、代替手段で構成されていない限り、IPv6プレフィックスを使用することを学習できません。
The discovery of the IPv6 prefix could be solved, as described in [RFC7050], by means of adding the relevant AAAA records to the ipv4only.arpa. zone of the service-provider recursive servers, i.e., if using the WKP (64:ff9b::/96):
[RFC7050]で説明されているように、関連するAAAAレコードをipv4only.arpaに追加することにより、IPv6プレフィックスの発見を解決できます。サービスプロバイダーの再帰サーバーのゾーン、つまりWKP（64：ff9b :: / 96）を使用している場合：
ipv4only.arpa. SOA . . 0 0 0 0 0 ipv4only.arpa. NS . ipv4only.arpa. AAAA 64:ff9b::192.0.0.170 ipv4only.arpa. AAAA 64:ff9b::192.0.0.171 ipv4only.arpa. A 192.0.0.170 ipv4only.arpa. A 192.0.0.171
ipv4only.arpa。 SOA。 。 0 0 0 0 0 ipv4only.arpa。 NS。 ipv4only.arpa。 AAAA 64：ff9b :: 192.0.0.170 ipv4only.arpa。 AAAA 64：ff9b :: 192.0.0.171 ipv4only.arpa。 192.0.0.170 ipv4only.arpa。 192.0.0.171
An alternative option is the use of DNS RPZ [DNS-RPZ] or equivalent functionalities. Note that this may impact DNSSEC if the zone is signed.
代替オプションは、DNS RPZ [DNS-RPZ]または同等の機能の使用です。ゾーンが署名されている場合、これはDNSSECに影響を与える可能性があることに注意してください。
Another alternative, only valid in environments with support from the Port Control Protocol (PCP) (for both the hosts or CEs and for the service-provider network), is to follow "Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)" [RFC7225].
（ホストまたはCEとサービスプロバイダーネットワークの両方に対して）ポート制御プロトコル（PCP）からのサポートがある環境でのみ有効な別の代替方法は、「ポート制御プロトコル（PCP）を使用したNAT64 IPv6プレフィックスの検出」に従うことです。 [RFC7225]。
Other alternatives may be available in the future. All them are extensively discussed in [RFC7051]; however, due to the deployment evolution, many considerations from that document have changed. New options are being documented, such as using Router Advertising [PREF64] or DHCPv6 options [DHCPv6-OPTIONS].
将来的には他の代替手段が利用可能になるかもしれません。それらはすべて[RFC7051]で広く議論されています。ただし、展開の進化により、そのドキュメントの多くの考慮事項が変更されました。ルーターアドバタイズ[PREF64]またはDHCPv6オプション[DHCPv6-OPTIONS]の使用など、新しいオプションが文書化されています。
Simultaneous support of several of the possible approaches is convenient and will ensure that clients with different ways to configure the NAT64 prefix successfully obtain it. This is also convenient even if DNS64 is being used.
いくつかの可能なアプローチの同時サポートは便利であり、NAT64プレフィックスを構成するさまざまな方法を持つクライアントがそれを正常に取得することを保証します。これは、DNS64を使用している場合にも便利です。
Also of special relevance to this section is [IPV4ONLY-ARPA].
このセクションに特に関連するのは、[IPV4ONLY-ARPA]です。
In general, by default, DNS servers with DNS64 function will not synthesize AAAA responses if the DO flag was set in the query.
一般に、デフォルトでは、DNS機能を備えたDNSサーバーは、クエリでDOフラグが設定されている場合、AAAA応答を合成しません。
In this case, since only an A record is available, if a CLAT function is present, the CLAT will, as in the case of literal IPv4 addresses, keep that traffic flow end to end as IPv4 so DNSSEC is not broken.
この場合、Aレコードしか使用できないため、CLAT関数が存在する場合、CLATはリテラルIPv4アドレスの場合と同様に、そのトラフィックフローをIPv4としてエンドツーエンドで維持するため、DNSSECが破損しません。
However, this will not work if a CLAT function is not present because the hosts will not be able to use IPv4 (which is the case for all the scenarios without 464XLAT).
ただし、ホストはIPv4を使用できないため、CLAT機能が存在しない場合、これは機能しません（464XLATがないすべてのシナリオに当てはまります）。
If the DO flag is set and the client device performs DNSSEC validation, and the Checking Disabled (CD) flag is set for a query, the DNS64 recursive server will not synthesize AAAA responses. In this case, the client could perform the DNSSEC validation with the A record and then synthesize the AAAA responses [RFC6052]. For that to be possible, the client must have learned the NAT64 prefix beforehand using any of the available methods (see [RFC7050], [RFC7225], [PREF64], and [DHCPv6-OPTIONS]). This allows the client device to avoid using the DNS64 function and still use NAT64 even with DNSSEC.
DOフラグが設定されていて、クライアントデバイスがDNSSEC検証を実行し、クエリにチェック無効（CD）フラグが設定されている場合、DNS64再帰サーバーはAAAA応答を合成しません。この場合、クライアントはAレコードを使用してDNSSEC検証を実行し、次にAAAA応答を合成できます[RFC6052]。それを可能にするには、クライアントは利用可能な方法のいずれかを使用して、NAT64プレフィックスを事前に学習している必要があります（[RFC7050]、[RFC7225]、[PREF64]、および[DHCPv6-OPTIONS]を参照）。これにより、クライアントデバイスはDNS64機能の使用を回避し、DNSSECを使用してもNAT64を使用できます。
If the end host is IPv4 only, this will not work if a CLAT function is not present (which is the case for all scenarios without 464XLAT).
エンドホストがIPv4のみの場合、CLAT機能が存在しないとこれは機能しません（464XLATがないすべてのシナリオに当てはまります）。
Instead of a CLAT, some devices or Operating Systems may implement an equivalent function by using Bump-in-the-Host [RFC6535] as part of Happy Eyeballs v2 (see Section 7.1 of [RFC8305]). In this case, the considerations in the above paragraphs are also applicable.
CLATの代わりに、一部のデバイスまたはオペレーティングシステムは、Happy Eyeballs v2の一部としてBump-in-the-Host [RFC6535]を使用して同等の機能を実装する場合があります（[RFC8305]のセクション7.1を参照）。この場合、上記の段落の考慮事項も適用されます。
If a CE includes CLAT support and also a DNS proxy, as indicated in Section 6.4 of [RFC6877], the CE could behave as a stub validator on behalf of the client devices. Then, following the same approach described in Section 4.1.3, the DNS proxy will actually "lie" to the client devices, which, in most cases, will not be noticed unless they perform validation by themselves. Again, this allows the client devices to avoid the use of the DNS64 function but to still use NAT64 with DNSSEC.
[RFC6877]のセクション6.4に示されているように、CEにCLATサポートとDNSプロキシが含まれている場合、CEはクライアントデバイスに代わってスタブバリデーターとして動作する可能性があります。次に、4.1.3項で説明したのと同じアプローチに従って、DNSプロキシは実際にはクライアントデバイスに「うそ」をつきます。ほとんどの場合、DNSプロキシは自分で検証を実行しない限り気づかれません。この場合も、クライアントデバイスはDNS64機能の使用を回避しながら、NAT64をDNSSECで使用できます。
Once more, this will not work without a CLAT function (which is the case for all scenarios without 464XLAT).
もう一度、これはCLAT関数なしでは機能しません（464XLATなしのすべてのシナリオに当てはまります）。
In cases of dual-stack clients, AAAA queries typically take preference over A queries. If DNS64 is enabled for those clients, it will never get A records, even for IPv4-only servers.
デュアルスタッククライアントの場合、AAAAクエリは通常、Aクエリよりも優先されます。これらのクライアントでDNS64が有効になっている場合、IPv4のみのサーバーであっても、Aレコードは取得されません。
As a consequence, in cases where there are IPv4-only servers, and those are located in the path before the NAT64 function, the clients will not be able to reach them. If DNSSEC is being used for all those flows, specific addresses or prefixes can be left out of the DNS64 synthesis by means of Access Control Lists (ACLs).
その結果、IPv4専用サーバーがあり、それらがNAT64機能の前のパスにある場合、クライアントはそれらに到達できません。これらすべてのフローにDNSSECが使用されている場合、アクセス制御リスト（ACL）を使用して、特定のアドレスまたはプレフィックスをDNS64合成から除外できます。
Once more, this will not work without a CLAT function (which is the case for all scenarios without 464XLAT).
もう一度、これはCLAT関数なしでは機能しません（464XLATなしのすべてのシナリオに当てはまります）。
If there are well-known specific IPv4 addresses or prefixes using DNSSEC, they can be mapped out of the DNS64 synthesis.
DNSSECを使用する既知の特定のIPv4アドレスまたはプレフィックスがある場合、それらはDNS64合成からマッピングできます。
Even if this is not related to DNSSEC, this "mapping-out" feature is quite commonly used to ensure that addresses [RFC1918] (for example, used by LAN servers) are not synthesized to AAAA.
これがDNSSECに関係しない場合でも、この「マッピングアウト」機能は、アドレス[RFC1918]（たとえば、LANサーバーで使用される）がAAAAに合成されないようにするためによく使用されます。
Once more, this will not work without a CLAT function (which is the case for all scenarios without 464XLAT).
もう一度、これはCLAT関数なしでは機能しません（464XLATなしのすべてのシナリオに当てはまります）。
When a client device using DNS64 tries to reverse-map a synthesized IPv6 address, the name server responds with a CNAME record that points the domain name used to reverse-map the synthesized IPv6 address (the one under ip6.arpa) to the domain name corresponding to the embedded IPv4 address (under in-addr.arpa).
DNS64を使用するクライアントデバイスが合成されたIPv6アドレスを逆マッピングしようとすると、ネームサーバーは、合成されたIPv6アドレス（ip6.arpaの下にあるもの）をドメイン名に逆マッピングするために使用されるドメイン名をポイントするCNAMEレコードで応答します。埋め込みIPv4アドレスに対応します（in-addr.arpaの下）。
This is the expected behavior, so no issues need to be considered regarding DNS reverse mapping.
これは予想される動作であるため、DNSリバースマッピングに関して問題を考慮する必要はありません。
In case the client device is IPv6 only (either because the stack or application is IPv6 only or because it is connected via an IPv6-only LAN) and the remote server is IPv4 only (either because the stack is IPv4 only or because it is connected via an IPv4-only LAN), only NAT64 combined with DNS64 will be able to provide access between both. Because DNS64 is then required, DNSSEC validation will only be possible if the recursive name server is validating the negative response from the authoritative name server, and the client is not performing validation.
クライアントデバイスがIPv6のみ（スタックまたはアプリケーションがIPv6のみ、またはIPv6のみのLAN経由で接続されているため）であり、リモートサーバーがIPv4のみ（スタックがIPv4のみまたは接続されているため）の場合IPv4のみのLANを介して）、NAT64とDNS64を組み合わせたものだけが両方のアクセスを提供できます。次にDNS64が必要になるため、DNSSEC検証は、再帰的なネームサーバーが権限のあるネームサーバーからの否定応答を検証していて、クライアントが検証を実行していない場合にのみ可能です。
Note that at this stage of the transition, it is not expected that applications, devices, or Operating Systems are IPv6 only. It will not be a sensible decision for a developer to work on that direction, unless it is clear that the deployment scenario fully supports it.
移行のこの段階では、アプリケーション、デバイス、またはオペレーティングシステムがIPv6のみであることは想定されていないことに注意してください。展開シナリオがそれを完全にサポートしていることが明らかでない限り、開発者がその方向に取り組むことは賢明な決定ではありません。
On the other hand, an end user or enterprise network may decide to run IPv6 only in the LANs. In case there is any chance for applications to be IPv6 only, the Operating System may be responsible for either doing a local address synthesis or setting up some kind of on-demand VPN (IPv4-in-IPv6), which needs to be supported by that network. This may become very common in enterprise networks, where "Unique IPv6 Prefix per Host" [RFC8273] is supported.
一方、エンドユーザーまたはエンタープライズネットワークは、LANでのみIPv6を実行することを決定する場合があります。アプリケーションがIPv6のみになる可能性がある場合、オペレーティングシステムは、ローカルアドレス合成を実行するか、ある種のオンデマンドVPN（IPv4-in-IPv6）を設定する必要があります。そのネットワーク。これは、「ホストごとの一意のIPv6プレフィックス」[RFC8273]がサポートされているエンタープライズネットワークでは非常に一般的になる可能性があります。
However, when the client device is dual stack and/or connected in a dual-stack LAN by means of a CLAT function (or has a built-in CLAT function), DNS64 is an option.
ただし、クライアントデバイスがデュアルスタックであるか、CLAT機能を使用してデュアルスタックLANに接続されている場合（またはCLAT機能が組み込まれている場合）、DNS64はオプションです。
1. With DNS64: If DNS64 is used, most of the IPv4 traffic (except if using literal IPv4 addresses or non-IPv6-compliant APIs) will not use the CLAT and will instead use the IPv6 path, so only one translation will be done at the NAT64. This may break DNSSEC, unless measures as described in the previous sections are taken.
1. DNS64を使用する場合：DNS64を使用する場合、ほとんどのIPv4トラフィック（リテラルIPv4アドレスまたは非IPv6準拠のAPIを使用する場合を除く）はCLATを使用せず、代わりにIPv6パスを使用するため、 NAT64。これは、前のセクションで説明したような対策を講じない限り、DNSSECを破壊する可能性があります。
2. Without DNS64: If DNS64 is not used, all the IPv4 traffic will make use of the CLAT, so two translations are required (NAT46 at the CLAT and NAT64 at the PLAT), which adds some overhead in terms of the extra NAT46 translation. However, this avoids the AAAA synthesis and consequently will never break DNSSEC.
2. DNS64がない場合：DNS64が使用されない場合、すべてのIPv4トラフィックがCLATを使用するため、2つの変換が必要です（CLATでのNAT46とPLATでのNAT64）。これにより、NAT46変換の追加という点でいくつかのオーバーヘッドが追加されます。ただし、これによりAAAA合成が回避されるため、DNSSECが壊れることはありません。
Note that the extra translation, when DNS64 is not used, takes place at the CLAT, which means no extra overhead for the operator. However, it adds potential extra delays to establish the connections and has no perceptible impact for a CE in a broadband network, but it may have some impact on a battery-powered device. The cost for a battery-powered device is possibly comparable to the cost when the device is doing a local address synthesis (see Section 7.1 of [RFC8305]).
DNS64が使用されていない場合、追加の変換はCLATで行われることに注意してください。これは、オペレーターに余分なオーバーヘッドがないことを意味します。ただし、接続を確立するために潜在的な余分な遅延が追加され、ブロードバンドネットワークのCEに知覚できる影響はありませんが、バッテリ駆動のデバイスに影響を与える可能性があります。バッテリ駆動のデバイスのコストは、デバイスがローカルアドレス合成を実行しているときのコストに匹敵する可能性があります（[RFC8305]のセクション7.1を参照）。
Clients, devices, or applications in a service-provider network may use DNS servers from other networks. This may be the case if individual applications use their own DNS server, the Operating System itself or even the CE, or combinations of the above.
サービスプロバイダーネットワークのクライアント、デバイス、またはアプリケーションは、他のネットワークのDNSサーバーを使用できます。これは、個々のアプリケーションが独自のDNSサーバー、オペレーティングシステム自体、さらにはCE、または上記の組み合わせを使用する場合に当てはまることがあります。
Those "foreign" DNS servers may not support DNS64; as a consequence, those scenarios that require a DNS64 may not work. However, if a CLAT function is available, the considerations in Section 4.3 will apply.
これらの「外部」DNSサーバーはDNS64をサポートしない場合があります。結果として、DNS64を必要とするシナリオは機能しない可能性があります。ただし、CLAT関数が使用可能な場合は、セクション4.3の考慮事項が適用されます。
If the foreign DNS supports the DNS64 function, incorrect configuration parameters may be provided that, for example, cause WKP or NSP to become unmatched or result in a case such as the one described in Section 3.2.3.
外部DNSがDNS64機能をサポートしている場合、たとえば、WKPまたはNSPが不一致になったり、セクション3.2.3で説明されているようなケースが発生したりする、不適切な構成パラメーターが提供される可能性があります。
Having a CLAT function, even if using foreign DNS without a DNS64 function, ensures that everything will work, so the CLAT must be considered to be an advantage despite user configuration errors. As a result, all the traffic will use a double translation (NAT46 at the CLAT and NAT64 at the operator network), unless there is support for EAM (Section 4.9).
DNS64関数を使用せずに外部DNSを使用する場合でも、CLAT関数を使用すると、すべてが機能することが保証されます。そのため、ユーザー構成エラーがあってもCLATは有利であると考える必要があります。その結果、EAM（セクション4.9）のサポートがない限り、すべてのトラフィックは二重変換（CLATではNAT46、オペレーターネットワークではNAT64）を使用します。
An exception is the case where there is a CLAT function at the CE that is not able to obtain the correct configuration parameters (again, causing WKP or NSP to become unmatched).
例外は、正しい構成パラメーターを取得できないCEにCLAT機能がある場合です（ここでも、WKPまたはNSPが不一致になります）。
However, it needs to be emphasized that if there is no CLAT function (which is the case for all scenarios without 464XLAT), an external DNS without DNS64 support will disallow any access to IPv4-only destination networks and will not guarantee the correct DNSSEC validation, so it will behave as in Section 3.2.1.
ただし、CLAT機能がない場合（464XLATがないすべてのシナリオに当てはまります）、DNS64をサポートしない外部DNSはIPv4のみの宛先ネットワークへのアクセスを許可せず、正しいDNSSEC検証を保証しないことを強調する必要がありますなので、セクション3.2.1のように動作します。
In summary, the consequences of using foreign DNS depends on each specific case. However, in general, if a CLAT function is present, most of the time there will not be any issues. In the other cases, the access to IPv6-enabled services is still guaranteed for IPv6-enabled hosts, but it is not guaranteed for IPv4-only hosts nor is the access to IPv4-only services for any hosts in the network.
要約すると、外部DNSを使用した場合の結果は、特定のケースごとに異なります。ただし、一般に、CLAT関数が存在する場合、ほとんどの場合、問題は発生しません。その他の場合、IPv6対応サービスへのアクセスはIPv6対応ホストで保証されますが、IPv4専用ホストでは保証されず、ネットワーク内のホストのIPv4専用サービスへのアクセスも保証されません。
The causes of "foreign DNS" could be classified in three main categories, as depicted in the following subsections.
「外部DNS」の原因は、次のサブセクションに示すように、3つの主なカテゴリに分類できます。
It is becoming increasingly common that end users, or even devices or applications, configure alternative DNS in their Operating Systems and sometimes in CEs.
エンドユーザー、さらにはデバイスやアプリケーションでさえ、オペレーティングシステムおよび場合によってはCEで代替DNSを構成することがますます一般的になっています。
Clients or applications may use mechanisms for DNS privacy/ encryption, such as DNS over TLS (DoT) [RFC7858], DNS over DTLS [RFC8094], DNS queries over HTTPS (DoH) [RFC8484], or DNS over QUIC (DoQ) [QUIC-CONNECTIONS].
クライアントまたはアプリケーションは、DNSプライバシー/暗号化のメカニズムを使用できます。たとえば、DNS over TLS（DoT）[RFC7858]、DNS over DTLS [RFC8094]、DNS over HTTPS（DoH）[RFC8484]、DNS over QUIC（DoQ）[ QUIC-CONNECTIONS]。
Currently, those DNS privacy/encryption options are typically provided by the applications, not the Operating System vendors. At the time this document was written, the DoT and DoH standards have declared DNS64 (and consequently NAT64) out of their scope, so an application using them may break NAT64, unless a correctly configured CLAT function is used.
現在、これらのDNSプライバシー/暗号化オプションは通常、オペレーティングシステムベンダーではなく、アプリケーションによって提供されています。このドキュメントが作成された時点で、DoTおよびDoH標準はDNS64（およびその結果としてNAT64）を範囲外として宣言しているため、それらを使用するアプリケーションは、正しく構成されたCLAT関数が使用されない限り、NAT64を壊す可能性があります。
When networks or hosts use "split-DNS" (also called Split Horizon, DNS views, or private DNS), the successful use of DNS64 is not guaranteed. This case is analyzed in Section 4 of [RFC6950].
ネットワークまたはホストが「スプリットDNS」（スプリットホライズン、DNSビュー、またはプライベートDNSとも呼ばれる）を使用する場合、DNS64の正常な使用は保証されません。このケースは、[RFC6950]のセクション4で分析されています。
A similar situation may happen with VPNs that force all the DNS queries through the VPN and ignore the operator DNS64 function.
同様の状況は、VPNを介してすべてのDNSクエリを強制し、オペレーターのDNS64機能を無視するVPNでも発生する可能性があります。
Section 3 of "IPv6 Addressing of IPv4/IPv6 Translator" [RFC6052] discusses some considerations that are useful to an operator when deciding if a WKP or an NSP should be used.
「IPv4 / IPv6トランスレーターのIPv6アドレッシング」[RFC6052]のセクション3では、WKPとNSPのどちらを使用するかを決定するときにオペレーターに役立ついくつかの考慮事項について説明します。
Considering that discussion and other issues, we can summarize the possible decision points to as follows:
その議論およびその他の問題を考慮して、考えられる決定ポイントを次のように要約できます。
a. The WKP MUST NOT be used to represent non-global IPv4 addresses. If this is required because the network to be translated uses non-global addresses, then an NSP is required.
a. WKPは、非グローバルIPv4アドレスを表すために使用してはなりません（MUST NOT）。変換されるネットワークが非グローバルアドレスを使用するためにこれが必要な場合は、NSPが必要です。
b. The WKP MAY appear in interdomain routing tables, if the operator provides a NAT64 function to peers. However, in this case, special considerations related to BGP filtering are required, and IPv4-embedded IPv6 prefixes longer than the WKP MUST NOT be advertised (or accepted) in BGP. An NSP may be a more appropriate option in those cases.
b. オペレーターがピアにNAT64機能を提供する場合、WKPはドメイン間ルーティングテーブルに表示される場合があります。ただし、この場合、BGPフィルタリングに関連する特別な考慮事項が必要であり、WKPより長いIPv4埋め込みIPv6プレフィックスは、BGPでアドバタイズ（または受け入れ）してはなりません（MUST NOT）。そのような場合は、NSPがより適切なオプションになる場合があります。
c. If several NAT64s use the same prefix, packets from the same flow may be routed to a different NAT64 in case of routing changes. This can be avoided by either using different prefixes for each NAT64 function or ensuring that all the NAT64s coordinate their state. Using an NSP could simplify that.
c. 複数のNAT64が同じプレフィックスを使用する場合、ルーティングが変更された場合、同じフローからのパケットが別のNAT64にルーティングされる可能性があります。これは、NAT64関数ごとに異なるプレフィックスを使用するか、すべてのNAT64がその状態を調整するようにすることで回避できます。 NSPを使用すると、それを簡素化できます。
d. If DNS64 is required and users, devices, Operating Systems, or applications may change their DNS configuration and deliberately choose an alternative DNS64 function, the alternative DNS64 will most likely use the WKP by default. In that case, if an NSP is used by the NAT64 function, clients will not be able to use the operator NAT64 function, which will break connectivity to IPv4-only destinations.
d. DNS64が必要で、ユーザー、デバイス、オペレーティングシステム、またはアプリケーションがDNS構成を変更し、故意に代替DNS64関数を選択する場合、代替DNS64はデフォルトでWKPを使用する可能性が最も高くなります。その場合、NSPがNAT64機能で使用されると、クライアントはオペレーターのNAT64機能を使用できなくなり、IPv4のみの宛先への接続が切断されます。
A host or application using literal IPv4 addresses or older APIs, which aren't IPv6 compliant, behind a network with IPv6-only access will not work unless any of the following alternatives are provided:
IPv6のみのアクセスを持つネットワークの背後にある、リテラルIPv4アドレスまたはIPv6に準拠していない古いAPIを使用するホストまたはアプリケーションは、次の代替手段が提供されない限り機能しません。
* CLAT (or an equivalent function).
* CLAT（または同等の関数）。
* Happy Eyeballs v2 (Section 7.1 of [RFC8305]).
* Happy Eyeballs v2（[RFC8305]のセクション7.1）。
* Bump-in-the-Host [RFC6535] with a DNS64 function.
* DNS64機能を備えたBump-in-the-Host [RFC6535]。
Those alternatives will solve the problem for an end host. However, if the end host is providing "tethering" or an equivalent service to other hosts, that needs to be considered as well. In other words, in a cellular network, these alternatives resolve the issue for the UE itself, but this may not be the case for hosts connected via the tethering.
これらの選択肢は、エンドホストの問題を解決します。ただし、エンドホストが「テザリング」または同等のサービスを他のホストに提供している場合は、それも考慮する必要があります。言い換えると、セルラーネットワークでは、これらの代替手段によってUE自体の問題が解決されますが、テザリングを介して接続されたホストの場合はそうではない可能性があります。
Otherwise, the support of 464XLAT is the only valid and complete approach to resolve this issue.
それ以外の場合は、464XLATのサポートが、この問題を解決するための唯一の有効で完全なアプローチです。
IPv4-only hosts or an application behind a network with IPv6-only access will not work unless a CLAT function is present.
IPv4のみのホストまたはIPv6のみのアクセスを持つネットワークの背後にあるアプリケーションは、CLAT機能が存在しない限り機能しません。
464XLAT is the only valid approach to resolve this issue.
この問題を解決するには、464XLATが唯一の有効なアプローチです。
As described in "IPv6 Prefix Handling" (see Section 6.3 of [RFC6877]), if the CLAT function can be configured with a dedicated /64 prefix for the NAT46 translation, then it will be possible to do a more efficient stateless translation.
「IPv6プレフィックスの処理」（[RFC6877]のセクション6.3を参照）で説明されているように、NAT46変換に専用の/ 64プレフィックスを使用してCLAT機能を構成できる場合は、より効率的なステートレス変換を実行できます。
Otherwise, if this dedicated prefix is not available, the CLAT function will need to do a stateful translation, for example, perform stateful NAT44 for all the IPv4 LAN packets so they appear as coming from a single IPv4 address; in turn, the CLAT function will perform a stateless translation to a single IPv6 address.
それ以外の場合、この専用プレフィックスが使用できない場合、CLAT関数はステートフル変換を行う必要があります。たとえば、すべてのIPv4 LANパケットに対してステートフルNAT44を実行して、単一のIPv4アドレスから送信されたように見せます。次に、CLAT関数は、単一のIPv6アドレスへのステートレス変換を実行します。
A possible setup, in order to maximize the CLAT performance, is to configure the dedicated translation prefix. This can be easily achieved automatically, if the broadband CE or end-user device is able to obtain a shorter prefix by means of DHCPv6-PD [RFC8415] or other alternatives. The CE can then use a specific /64 for the translation. This is also possible when broadband is provided by a cellular access.
CLATのパフォーマンスを最大化するために可能な設定は、専用の変換プレフィックスを構成することです。これは、ブロードバンドCEまたはエンドユーザーデバイスがDHCPv6-PD [RFC8415]または他の代替手段によって短いプレフィックスを取得できる場合、自動的に簡単に実現できます。その後、CEは特定の/ 64を変換に使用できます。これは、セルラーアクセスによってブロードバンドが提供される場合にも可能です。
The above recommendation is often not possible for cellular networks, when connecting smartphones (as UEs): generally they don't use DHCPv6-PD [RFC8415]. Instead, a single /64 is provided for each Packet Data Protocol (PDP) context, and prefix sharing [RFC6877] is used. In this case, the UEs typically have a build-in CLAT function that is performing a stateful NAT44 translation before the stateless NAT46.
上記の推奨事項は、スマートフォンを（UEとして）接続する場合、セルラーネットワークでは多くの場合不可能です。通常、それらはDHCPv6-PD [RFC8415]を使用しません。代わりに、単一の/ 64が各パケットデータプロトコル（PDP）コンテキストに提供され、プレフィックス共有[RFC6877]が使用されます。この場合、UEには通常、ステートレスNAT46の前にステートフルNAT44変換を実行するビルトインCLAT機能があります。
"Explicit Address Mappings for Stateless IP/ICMP Translation" [RFC7757] provides a way to configure explicit mappings between IPv4 and IPv6 prefixes of any length. When this is used, for example, in a CLAT function, it may provide a simple mechanism in order to avoid traffic flows between IPv4-only nodes or applications and dual-stack destinations to be translated twice (NAT46 and NAT64), by creating mapping entries with the Global Unicast Address (GUA) of the IPv6-reachable destination. This optimization of NAT64 usage is very useful in many scenarios, including Content Delivery Networks (CDNs) and caches, as described in [OPT-464XLAT].
「ステートレスIP / ICMP変換の明示的なアドレスマッピング」[RFC7757]は、任意の長さのIPv4とIPv6プレフィックス間の明示的なマッピングを構成する方法を提供します。これをたとえばCLAT関数で使用すると、マッピングを作成することにより、IPv4のみのノードまたはアプリケーションとデュアルスタック宛先の間のトラフィックフローが2回変換されるのを防ぐために、シンプルなメカニズムを提供できます（NAT46とNAT64）。 IPv6到達可能宛先のグローバルユニキャストアドレス（GUA）を持つエントリ。このNAT64の使用の最適化は、[OPT-464XLAT]で説明されているように、コンテンツ配信ネットワーク（CDN）やキャッシュなど、多くのシナリオで非常に役立ちます。
In addition, it may also provide a way for IPv4-only nodes or applications to communicate with IPv6-only destinations.
さらに、IPv4のみのノードまたはアプリケーションがIPv6のみの宛先と通信する方法も提供します。
The use of NAT64, in principle, disallows IPv4 incoming connections, which may still be needed for IPv4-only peer-to-peer applications. However, there are several alternatives that resolve this issue:
原則として、NAT64を使用すると、IPv4着信接続が許可されなくなります。これは、IPv4のみのピアツーピアアプリケーションで必要になる場合があります。ただし、この問題を解決するいくつかの代替策があります。
a. Session Traversal Utilities for NAT (STUN) [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and Interactive Connectivity Establishment (ICE) [RFC8445] are commonly used by peer-to-peer applications in order to allow incoming connections with IPv4 NAT. In the case of NAT64, they work as well.
a. NATのセッショントラバーサルユーティリティ（STUN）[RFC5389]、NAT周辺のリレーを使用したトラバーサル（TURN）[RFC5766]、およびインタラクティブ接続確立（ICE）[RFC8445]は、着信接続を許可するためにピアツーピアアプリケーションで一般的に使用されますIPv4 NAT。 NAT64の場合も機能します。
b. The Port Control Protocol (PCP) [RFC6887] allows a host to control how incoming IPv4 and IPv6 packets are translated and forwarded. A NAT64 may implement PCP to allow this service.
b. ポート制御プロトコル（PCP）[RFC6887]を使用すると、ホストは着信IPv4およびIPv6パケットの変換および転送方法を制御できます。 NAT64はPCPを実装してこのサービスを許可する場合があります。
c. EAM [RFC7757] may also be used in order to configure explicit mappings for customers that require them. This is used, for example, by Stateless IP/ICMP Translation for IPv6 Data Center Environments (SIIT-DC) [RFC7755] and SIIT-DC Dual Translation Mode (SIIT-DC-DTM) [RFC7756].
c. EAM [RFC7757]は、それらを必要とする顧客の明示的なマッピングを構成するために使用することもできます。これは、たとえば、IPv6データセンター環境用のステートレスIP / ICMP変換（SIIT-DC）[RFC7755]およびSIIT-DCデュアル変換モード（SIIT-DC-DTM）[RFC7756]によって使用されます。
It has been demonstrated that NAT64/464XLAT is a valid choice in several scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), being the predominant mechanism in the majority of the cellular networks, which account for hundreds of millions of users [ISOC]. NAT64/464XLAT offer different choices of deployment, depending on each network case, needs, and requirements. Despite that, this document is not an explicit recommendation for using this choice versus other IPv4aaS transition mechanisms. Instead, this document is a guide that facilitates evaluating a possible implementation of NAT64/464XLAT and key decision points about specific design considerations for its deployment.
NAT64 / 464XLATはいくつかのシナリオ（IPv6-IPv4およびIPv4-IPv6-IPv4）で有効な選択肢であり、数億人のユーザーを占める大多数のセルラーネットワークの主要なメカニズムであることが示されています[ISOC] 。 NAT64 / 464XLATは、ネットワークの各ケース、ニーズ、および要件に応じて、さまざまな展開の選択肢を提供します。それにもかかわらず、このドキュメントは、この選択を他のIPv4aaS移行メカニズムと比較して使用するための明示的な推奨事項ではありません。代わりに、このドキュメントは、NAT64 / 464XLATの可能な実装と、その展開に関する特定の設計上の考慮事項に関する重要な決定ポイントの評価を容易にするガイドです。
Depending on the specific requirements of each deployment case, DNS64 may be a required function, while in other cases, the adverse effects may be counterproductive. Similarly, in some cases, a NAT64 function, together with a DNS64 function, may be a valid solution when there is a certainty that IPv4-only hosts or applications do not need to be supported (see Sections 4.6 and 4.7). However, in other cases (i.e., IPv4-only devices or applications that need to be supported), the limitations of NAT64/DNS64 may indicate that the operator needs to look into 464XLAT as a more complete solution.
各展開ケースの特定の要件に応じて、DNS64が必要な機能になる場合がありますが、他の場合では、悪影響が逆効果になる場合があります。同様に、場合によっては、IPv4のみのホストまたはアプリケーションをサポートする必要がないことが確実である場合に、DNS64関数と一緒にNAT64関数が有効なソリューションになることがあります（セクション4.6および4.7を参照）。ただし、他の場合（つまり、サポートする必要があるIPv4専用のデバイスまたはアプリケーション）では、NAT64 / DNS64の制限により、オペレーターがより完全なソリューションとして464XLATを調査する必要があることが示される場合があります。
For broadband-managed networks (where the CE is provided or suggested/supported by the operator), in order to fully support the actual user's needs (i.e., IPv4-only devices and applications and the usage of IPv4 literals and non-IPv6-compliant APIs), the 464XLAT scenario should be considered. In that case, it must support a CLAT function.
ブロードバンド管理ネットワーク（CEが提供されるか、オペレーターによって提案/サポートされる）の場合、実際のユーザーのニーズ（つまり、IPv4のみのデバイスとアプリケーション、およびIPv4リテラルと非IPv6準拠の使用を完全にサポートするため） API）、464XLATシナリオを検討する必要があります。その場合、CLAT関数をサポートする必要があります。
If the operator provides DNS services, they may support a DNS64 function to avoid, as much as possible, breaking DNSSEC. This will also increase performance, by reducing the double translation for all the IPv4 traffic. In this case, if the DNS service is offering DNSSEC validation, then it must be in such a way that it is aware of the DNS64. This is considered the simpler and safer approach, and it may be combined with other recommendations described in this document:
オペレーターがDNSサービスを提供している場合、DNSSEC機能の破壊を可能な限り回避するために、DNS64機能をサポートしている場合があります。これにより、すべてのIPv4トラフィックの二重変換が減少するため、パフォーマンスも向上します。この場合、DNSサービスがDNSSEC検証を提供している場合は、DNS64を認識できるようにする必要があります。これはより簡単で安全なアプローチと考えられており、このドキュメントで説明されている他の推奨事項と組み合わせることができます。
* DNS infrastructure MUST be aware of DNS64 (Section 4.1.2).
* DNSインフラストラクチャはDNS64を認識している必要があります（セクション4.1.2）。
* Devices running CLAT SHOULD follow the indications in "Stub Validator" (see Section 4.1.3). However, this may be out of the control of the operator.
* CLATを実行するデバイスは、「スタブバリデーター」の指示に従う必要があります（セクション4.1.3を参照）。ただし、これはオペレータの制御の範囲外である可能性があります。
* CEs SHOULD include a DNS proxy and validator (Section 4.1.4).
* CEには、DNSプロキシとバリデーターを含める必要があります（セクション4.1.4）。
* "ACL of Clients" (see Section 4.1.5) and "Mapping Out IPv4 Addresses" (see Section 4.1.6) MAY be considered by operators, depending on their own infrastructure.
* 「クライアントのACL」（セクション4.1.5を参照）および「IPv4アドレスのマッピング」（セクション4.1.6を参照）は、独自のインフラストラクチャに応じて、オペレータによって検討される場合があります。
This "increased performance" approach has the disadvantage of potentially breaking DNSSEC for a small percentage of validating end hosts versus the small impact of a double translation taking place in the CE. If CE performance is not an issue, which is the most frequent case, then a much safer approach is to not use DNS64 at all, and consequently, ensure that all the IPv4 traffic is translated at the CLAT (Section 4.3).
この「パフォーマンスの向上」アプローチには、CEで行われる二重変換のわずかな影響に対して、検証ホストホストの割合が小さいためにDNSSECが壊れる可能性があるという欠点があります。最も頻繁なケースであるCEパフォーマンスが問題ではない場合、より安全なアプローチは、DNS64をまったく使用せず、その結果、すべてのIPv4トラフィックがCLATで変換されることを確認することです（セクション4.3）。
If DNS64 is not used, at least one of the alternatives described in Section 4.1.1 must be followed in order to learn the NAT64 prefix.
DNS64を使用しない場合は、NAT64プレフィックスを学習するために、セクション4.1.1で説明されている代替策の少なくとも1つに従う必要があります。
The operator needs to consider that if the DNS configuration is modified (see Sections 4.4, 4.4.2, and 4.4.3), which most likely cannot be avoided, a foreign non-DNS64 could be used instead of configuring a DNS64. In a scenario with only a NAT64 function, an IPv4-only remote host will no longer be accessible. Instead, it will continue to work in the case of 464XLAT.
オペレーターは、回避できない可能性が最も高いDNS構成が変更された場合（セクション4.4、4.4.2、および4.4.3を参照）、DNS64を構成する代わりに外部の非DNS64を使用できることを考慮する必要があります。 NAT64機能のみのシナリオでは、IPv4のみのリモートホストにアクセスできなくなります。代わりに、464XLATの場合は引き続き機能します。
Similar considerations need to be made regarding the usage of a NAT64 WKP vs. NSP (Section 4.5), as they must match the configuration of DNS64. When using foreign DNS, they may not match. If there is a CLAT and the configured foreign DNS is not a DNS64, the network will keep working only if other means of learning the NAT64 prefix are available.
NAT64 WKPとNSP（セクション4.5）の使用については、DNS64の構成と一致する必要があるため、同様の考慮事項を行う必要があります。外部DNSを使用する場合、それらは一致しない場合があります。 CLATがあり、構成された外部DNSがDNS64でない場合、ネットワークは、NAT64プレフィックスを学習する他の手段が利用可能な場合にのみ機能し続けます。
For broadband networks, as described in Section 4.8, the CEs supporting a CLAT function SHOULD support DHCPv6-PD [RFC8415] or alternative means for configuring a shorter prefix. The CE SHOULD internally reserve one /64 for the stateless NAT46 translation. The operator must ensure that the customers are allocated prefixes shorter than /64 in order to support this optimization. One way or another, this is not impacting the performance of the operator network.
ブロードバンドネットワークの場合、セクション4.8で説明されているように、CLAT機能をサポートするCEは、DHCPv6-PD [RFC8415]または短いプレフィックスを構成するための代替手段をサポートする必要があります（SHOULD）。 CEは内部でステートレスNAT46変換用に1/64を予約する必要があります（SHOULD）。オペレーターは、この最適化をサポートするために、顧客に/ 64より短いプレフィックスが割り当てられていることを確認する必要があります。いずれにせよ、これは事業者ネットワークのパフォーマンスに影響を与えていません。
Operators may follow "Deployment Considerations" (Section 7 of [RFC6877]) for suggestions on how to take advantage of traffic-engineering requirements.
通信事業者は、トラフィックエンジニアリングの要件を活用する方法についての提案について、「導入に関する考慮事項」（[RFC6877]のセクション7）に従うことができます。
For cellular networks, the considerations regarding DNSSEC may appear to be out of scope because UEs' Operating Systems commonly don't support DNSSEC. However, applications running on them may, or it may be an Operating System "built-in" support in the future. Moreover, if those devices offer tethering, other client devices behind the UE may be doing the validation; hence, proper DNSSEC support by the operator network is relevant.
セルラーネットワークの場合、UEのオペレーティングシステムは一般にDNSSECをサポートしていないため、DNSSECに関する考慮事項は範囲外となる場合があります。ただし、それらで実行されているアプリケーションは、将来的にはオペレーティングシステムの「組み込み」サポートになる可能性があります。さらに、これらのデバイスがテザリングを提供している場合、UEの背後にある他のクライアントデバイスが検証を行っている可能性があります。したがって、事業者ネットワークによる適切なDNSSECサポートが重要です。
Furthermore, cellular networks supporting 464XLAT [RFC6877] and "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" [RFC7050] allow a progressive IPv6 deployment, with a single Access Point Name (APN) supporting all types of PDP context (IPv4, IPv6, and IPv4v6). This approach allows the network to automatically serve every possible combination of UEs.
さらに、464XLAT [RFC6877]および「IPv6アドレス合成に使用されるIPv6プレフィックスの検出」[RFC7050]をサポートするセルラーネットワークでは、すべてのタイプのPDPコンテキスト（IPv4、IPv6 、およびIPv4v6）。このアプローチにより、ネットワークはUEのあらゆる可能な組み合わせに自動的に対応できます。
If the operator chooses to provide validation for the DNS64 prefix discovery, it must follow the advice from "Validation of Discovered Pref64::/n" (see Section 3.1 of [RFC7050]).
オペレーターがDNS64プレフィックス検出の検証を提供することを選択した場合、「検出されたPref64 :: / nの検証」からのアドバイスに従う必要があります（[RFC7050]のセクション3.1を参照）。
One last consideration is that many networks may have a mix of different complex scenarios at the same time; for example, customers that require 464XLAT and those that don't, customers that require DNS64 and those that don't, etc. In general, the different issues and the approaches described in this document can be implemented at the same time for different customers or parts of the network. That mix of approaches doesn't present any problem or incompatibility; they work well together as a matter of appropriate and differentiated provisioning. In fact, the NAT64/464XLAT approach facilitates an operator offering both cellular and broadband services to have a single IPv4aaS for both networks while differentiating the deployment key decisions to optimize each case. It's even possible to use hybrid CEs that have a main broadband access link and a backup via the cellular network.
最後に考慮しなければならないのは、多くのネットワークで同時に異なる複雑なシナリオが混在する可能性があることです。たとえば、464XLATを必要とするお客様と必要としないお客様、DNS64を必要とするお客様と必要としないお客様など。一般に、このドキュメントで説明されているさまざまな問題とアプローチは、さまざまなお客様に同時に実装できますまたはネットワークの一部。このようなアプローチを組み合わせても、問題や非互換性はありません。これらは、適切で差別化されたプロビジョニングの問題として、連携して機能します。実際、NAT64 / 464XLATアプローチは、セルラーサービスとブロードバンドサービスの両方を提供するオペレーターが、両方のネットワークに単一のIPv4aaSを提供すると同時に、それぞれのケースを最適化するための展開の重要な決定を差別化します。メインブロードバンドアクセスリンクとセルラーネットワーク経由のバックアップを備えたハイブリッドCEを使用することも可能です。
In an ideal world, we could safely use DNS64 if the approach proposed in [DNS-DNSSEC] were followed, avoiding the cases where DNSSEC may be broken. However, this will not solve the issues related to DNS privacy and split DNS.
理想的な世界では、[DNS-DNSSEC]で提案されたアプローチに従えばDNS64を安全に使用でき、DNSSECが破られる可能性があるケースを回避できます。ただし、これはDNSプライバシーとスプリットDNSに関連する問題を解決しません。
The only 100% safe solution that also resolves all the issues is, in addition to having a CLAT function, not using a DNS64 but instead making sure that the hosts have a built-in address synthesis feature. Operators could manage to provide CEs with the CLAT function; however, the built-in address synthesis feature is out of their control. If the synthesis is provided by either the Operating System (via its DNS resolver API) or the application (via its own DNS resolver) in such way that the prefix used for the NAT64 function is reachable for the host, the problem goes away.
すべての問題を解決する唯一の100％安全なソリューションは、CLAT機能に加えて、DNS64を使用せず、代わりにホストに組み込みのアドレス合成機能があることを確認することです。オペレーターは、CEにCLAT機能を提供することができます。ただし、組み込みのアドレス合成機能は制御できません。オペレーティングシステム（DNSリゾルバーAPIを介して）またはアプリケーション（独自のDNSリゾルバーを介して）のいずれかによって、NAT64関数に使用されるプレフィックスがホストに到達できるように合成が提供されている場合、問題は解消されます。
Whenever feasible, using EAM [RFC7757] as indicated in Section 4.9 provides a very relevant optimization, avoiding double translations.
可能な場合はいつでも、セクション4.9で示されているようにEAM [RFC7757]を使用することで、非常に適切な最適化が提供され、二重変換が回避されます。
Applications that require incoming connections typically provide a means for that already. However, PCP and EAM, as indicated in Section 4.10, are valid alternatives, even for creating explicit mappings for customers that require them.
着信接続を必要とするアプリケーションは、通常、すでにそのための手段を提供しています。ただし、セクション4.10に示すように、PCPとEAMは、それらを必要とする顧客の明示的なマッピングを作成する場合でも、有効な代替手段です。
The recommendations in this document can also be used in enterprise networks, campuses, and other similar scenarios (including managed end-user networks).
このドキュメントの推奨事項は、エンタープライズネットワーク、キャンパス、およびその他の同様のシナリオ（管理されたエンドユーザーネットワークを含む）でも使用できます。
This includes scenarios where the NAT64 function (and DNS64 function, if available) are under the control of that network (or can be configured manually according to that network's specific requirements), and there is a need to provide IPv6-only access to any part of that network, or it is IPv6 only connected to third-party networks.
これには、NAT64機能（および使用可能な場合はDNS64機能）がそのネットワークの制御下にある（またはそのネットワークの特定の要件に従って手動で構成できる）シナリオが含まれ、任意の部分にIPv6のみのアクセスを提供する必要がありますそのネットワークの、またはそれはサードパーティのネットワークにのみ接続されたIPv6です。
An example is the IETF meeting network itself, where both NAT64 and DNS64 functions are provided, presenting in this case the same issues as per Section 3.1.1. If there is a CLAT function in the IETF network, then there is no need to use DNS64, and it falls under the considerations of Section 3.1.3. Both scenarios have been tested and verified already in the IETF network.
例として、IETFミーティングネットワーク自体があり、NAT64とDNS64の両方の機能が提供されています。この場合、セクション3.1.1と同じ問題が発生します。 IETFネットワークにCLAT機能がある場合、DNS64を使用する必要はなく、セクション3.1.3の考慮事項に該当します。どちらのシナリオもIETFネットワークでテストおよび検証されています。
The following figures represent a few of the possible scenarios.
次の図は、考えられるシナリオのいくつかを表しています。
Figure 13 provides an example of an IPv6-only enterprise network connected with a dual stack to the Internet using local NAT64 and DNS64 functions.
図13は、ローカルNAT64およびDNS64機能を使用して、デュアルスタックでインターネットに接続されたIPv6のみのエンタープライズネットワークの例を示しています。
+----------------------------------+
| Enterprise Network |
| +----------+ +----------+ | +----------+
| | IPv6- | | NAT64 | | | IPv4 |
| | only +--------+ + | +-------+ + |
| | LANs | | DNS64 | | | IPv6 |
| +----------+ +----------+ | +----------+
+----------------------------------+
Figure 13: IPv6-Only Enterprise with NAT64 and DNS64
図13：NAT64およびDNS64を使用するIPv6のみのエンタープライズ
Figure 14 provides an example of a DS enterprise network connected with DS to the Internet using a CLAT function, without a DNS64 function.
図14は、DNS機能なしでCLAT機能を使用してDSとインターネットに接続されたDSエンタープライズネットワークの例を示しています。
+----------------------------------+
| Enterprise Network |
| +----------+ +----------+ | +----------+
| | IPv6 | | | | | IPv4 |
| | + +--------+ NAT64 | +-------+ + |
| | CLAT | | | | | IPv6 |
| +----------+ +----------+ | +----------+
+----------------------------------+
Figure 14: DS Enterprise with CLAT, DS Internet, without DNS64
図14：DNS64を使用しない、CLATを使用したDSエンタープライズ、DSインターネット
Finally, Figure 15 provides an example of an IPv6-only provider with a NAT64 function, and a DS enterprise network by means of their own CLAT function, without a DNS64 function.
最後に、図15は、NAT64機能を備えたIPv6のみのプロバイダーの例と、DNS64機能なしの独自のCLAT機能を使用したDSエンタープライズネットワークの例を示しています。
+----------------------------------+
| Enterprise Network |
| +----------+ +----------+ | +----------+
| | IPv6 | | | | IPv6 | |
| | + +--------+ CLAT | +--------+ NAT64 |
| | IPv4 | | | | only | |
| +----------+ +----------+ | +----------+
+----------------------------------+
Figure 15: DS Enterprise with CLAT and IPv6-Only Access, without DNS64
図15：DNS64を使用しない、CLATおよびIPv6のみのアクセスを備えたDSエンタープライズ
This document does not have new specific security considerations beyond those already reported by each of the documents cited. For example, DNS64 [RFC6147] already describes the DNSSEC issues.
このドキュメントには、引用された各ドキュメントによってすでに報告されているものを超える、特定のセキュリティに関する新しい考慮事項はありません。たとえば、DNS64 [RFC6147]はすでにDNSSECの問題について説明しています。
As already described in Section 4.4, note that there may be undesirable interactions, especially if using VPNs or DNS privacy, which may impact the correct performance of DNS64/NAT64.
セクション4.4で既に説明したように、特にVPNまたはDNSプライバシーを使用している場合、望ましくない相互作用があり、DNS64 / NAT64の正しいパフォーマンスに影響を与える可能性があることに注意してください。
Note that the use of a DNS64 function has privacy considerations that are equivalent to regular DNS, and they are located in either the service provider or an external service provider.
DNS64関数の使用には、通常のDNSと同等のプライバシーに関する考慮事項があり、サービスプロバイダーまたは外部サービスプロバイダーのいずれかにあることに注意してください。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、GJ、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、 <https://www.rfc-editor.org/info/rfc1918>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-editor.org/info/rfc5389>.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<https：// www.rfc-editor.org/info/rfc5389>。
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, <https://www.rfc-editor.org/info/rfc5625>.
[RFC5625] Bellis、R。、「DNSプロキシ実装ガイドライン」、BCP 152、RFC 5625、DOI 10.17487 / RFC5625、2009年8月、<https://www.rfc-editor.org/info/rfc5625>。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <https://www.rfc-editor.org/info/rfc5766>.
[RFC5766] Mahy、R.、Matthews、P。、およびJ. Rosenberg、「NATのリレーを使用したトラバーサル（TURN）：NATのセッショントラバーサルユーティリティへのリレー拡張（STUN）」、RFC 5766、DOI 10.17487 / RFC5766、4月2010、<https://www.rfc-editor.org/info/rfc5766>。
[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。、およびX. Li、「IPv4 / IPv6トランスレータのIPv6アドレッシング」、RFC 6052、DOI 10.17487 / RFC6052、2010年10月、< https://www.rfc-editor.org/info/rfc6052>。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, April 2011, <https://www.rfc-editor.org/info/rfc6144>.
[RFC6144] Baker、F.、Li、X.、Bao、C。、およびK. Yin、「IPv4 / IPv6変換のフレームワーク」、RFC 6144、DOI 10.17487 / RFC6144、2011年4月、<https：// www。 rfc-editor.org/info/rfc6144>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「ステートフルNAT64：IPv6クライアントからIPv4サーバーへのネットワークアドレスおよびプロトコル変換」、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<https： //www.rfc-editor.org/info/rfc6146>。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, <https://www.rfc-editor.org/info/rfc6147>.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P.、I。van Beijnum、「DNS64：DNS Extensions for Network Address Translation to IPv4 Servers to RFC」、RFC 6147、DOI 10.17487 / RFC6147、4月2011、<https://www.rfc-editor.org/info/rfc6147>。
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", RFC 6535, DOI 10.17487/RFC6535, February 2012, <https://www.rfc-editor.org/info/rfc6535>.
[RFC6535] Huang、B.、Deng、H。、およびT. Savolainen、「Bump-in-the-Host（BIH）を使用したデュアルスタックホスト」、RFC 6535、DOI 10.17487 / RFC6535、2012年2月、< https://www.rfc-editor.org/info/rfc6535>。
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <https://www.rfc-editor.org/info/rfc6877>.
[RFC6877] Mawatari、M.、Kawashima、M。、およびC. Byrne、「464XLAT：Combination of Stateful and Stateless Translation」、RFC 6877、DOI 10.17487 / RFC6877、2013年4月、<https：//www.rfc-editor .org / info / rfc6877>。
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <https://www.rfc-editor.org/info/rfc6887>.
[RFC6887] Wing、D.、Ed。、Cheshire、S.、Boucadair、M.、Penno、R。、およびP. Selkirk、「Port Control Protocol（PCP）」、RFC 6887、DOI 10.17487 / RFC6887、2013年4月、<https://www.rfc-editor.org/info/rfc6887>。
[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>。
[RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)", RFC 7225, DOI 10.17487/RFC7225, May 2014, <https://www.rfc-editor.org/info/rfc7225>.
[RFC7225] Boucadair、M。、「Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol（PCP）」、RFC 7225、DOI 10.17487 / RFC7225、2014年5月、<https://www.rfc-editor.org/info/rfc7225 >。
[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]アンダーソン、T。、およびA.リーバポッパー、「ステートレス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>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, <https://www.rfc-editor.org/info/rfc8273>.
[RFC8273] Brzozowski、J。およびG. Van de Velde、「Unique IPv6 Prefix per Host」、RFC 8273、DOI 10.17487 / RFC8273、2017年12月、<https://www.rfc-editor.org/info/rfc8273> 。
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, <https://www.rfc-editor.org/info/rfc8305>.
[RFC8305] Schinazi、D。およびT. Pauly、「Happy Eyeballs Version 2：Better Connectivity Using Concurrency」、RFC 8305、DOI 10.17487 / RFC8305、2017年12月、<https://www.rfc-editor.org/info/ rfc8305>。
[RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, <https://www.rfc-editor.org/info/rfc8375>.
[RFC8375] Pfister、P。およびT. Lemon、「Special-Use Domain 'home.arpa。'」、RFC 8375、DOI 10.17487 / RFC8375、2018年5月、<https://www.rfc-editor.org/info / rfc8375>。
[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>。
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.
[RFC8445] Keranen、A.、Holmberg、C。、およびJ. Rosenberg、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal」、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、< https://www.rfc-editor.org/info/rfc8445>。
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.
[RFC8484] Hoffman、P。およびP. McManus、「HTTPS（DoH）を介したDNSクエリ」、RFC 8484、DOI 10.17487 / RFC8484、2018年10月、<https://www.rfc-editor.org/info/rfc8484> 。
[About-DNS64] Linkova, J., "Let's talk about IPv6 DNS64 & DNSSEC", June 2016, <https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/>.
[About-DNS64] Linkova、J。、「Let's talk about IPv6 DNS64＆DNSSEC」、2016年6月、<https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/ >。
[ARCEP] ARCEP, "Service client des operateurs : les mesures de qualite de service", April 2018, <https://www.arcep.fr/ cartes-et-donnees/nos-publications-chiffrees/service-client-des-operateurs-mesures-de-la-qualite-de-service/ service-client-des-operateurs-les-mesures-de-qualite-de-service.html>.
[ARCEP] ARCEP、「オペレーターカスタマーサービス：サービス品質の測定」、2018年4月、<https://www.arcep.fr/ cartes-et-dates / nos-publications-figures / service-client-des -operators-measures-of-the-quality-of-service / customer-service-of-operators-measures-of-quality-of-service.html>。
[DHCPv6-OPTIONS] Li, L., Cui, Y., Liu, C., Wu, J., Baker, F., and J. Palet, "DHCPv6 Options for Discovery NAT64 Prefixes", Work in Progress, Internet-Draft, draft-li-intarea-nat64-prefix-dhcp-option-02, 20 April 2019, <https://tools.ietf.org/html/draft-li-intarea-nat64- prefix-dhcp-option-02>.
[DHCPv6-OPTIONS] Li、L.、Cui、Y.、Liu、C.、Wu、J.、Baker、F.、J。Palet、「ディスカバリNAT64プレフィックスのDHCPv6オプション」、作業中、インターネット- Draft、draft-li-intarea-nat64-prefix-dhcp-option-02、2019年4月20日、<https://tools.ietf.org/html/draft-li-intarea-nat64- prefix-dhcp-option-02 >。
[DNS-DNSSEC] Byrne, C. and J. Palet, "IPv6-Ready DNS/DNSSSEC Infrastructure", Work in Progress, Internet-Draft, draft-bp-v6ops-ipv6-ready-dns-dnssec-00, 10 October 2018, <https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-dns-dnssec-00>.
[DNS-DNSSEC] Byrne、C。およびJ. Palet、「IPv6-Ready DNS / DNSSSEC Infrastructure」、Work in Progress、Internet-Draft、draft-bp-v6ops-ipv6-ready-dns-dnssec-00、10月10日2018、<https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-dns-dnssec-00>。
[DNS-RPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones (RPZ)", Work in Progress, Internet-Draft, draft-vixie-dnsop-dns-rpz-00, 23 June 2018, <https://tools.ietf.org/html/draft-vixie-dnsop-dns-rpz-00>.
[DNS-RPZ] Vixie、P。およびV. Schryver、「DNS Response Policy Zones（RPZ）」、Work in Progress、Internet-Draft、draft-vixie-dnsop-dns-rpz-00、2018年6月23日、<https ：//tools.ietf.org/html/draft-vixie-dnsop-dns-rpz-00>。
[DNS64-Benchm] Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", pp. 61-74, no. 1, vol. 127, Computer Communications, DOI 10.1016/j.comcom.2018.05.005, September 2018, <https://www.sciencedirect.com/science/article/pii/ S0140366418302184?via%3Dihub>.
[DNS64-Benchm] Lencse、G。およびY. Kadobayashi、「DNS64実装のベンチマーク：理論と実践」、61〜74ページ、no。 1、vol。 127、Computer Communications、DOI 10.1016 / j.comcom.2018.05.005、2018年9月、<https://www.sciencedirect.com/science/article/pii/ S0140366418302184？via％3Dihub>。
[DNS64-BM-Meth] Lencse, G., Georgescu, M., and Y. Kadobayashi, "Benchmarking Methodology for DNS64 Servers", pp. 162-175, no. 1, vol. 109, Computer Communications, DOI 10.1016/j.comcom.2017.06.004, September 2017, <https://www.sciencedirect.com/science/article/pii/ S0140366416305904?via%3Dihub>.
[DNS64-BM-Meth] Lencse、G.、Georgescu、M。、およびY. Kadobayashi、「DNS64サーバーのベンチマーク手法」、pp。162-175、no。 1、vol。 109、Computer Communications、DOI 10.1016 / j.comcom.2017.06.004、2017年9月、<https://www.sciencedirect.com/science/article/pii/ S0140366416305904？via％3Dihub>。
[FCC] FCC, "Measuring Broadband America Mobile 2013-2018 Coarsened Data", December 2018, <https://www.fcc.gov/ reports-research/reports/measuring-broadband-america/ measuring-broadband-america-mobile-2013-2018>.
[FCC] FCC、「Measuring Broadband America Mobile 2013-2018 Coarsened Data」、2018年12月、<https://www.fcc.gov/ reports-research / reports / measuring-broadband-america / Measurement-broadband-america-mobile -2013-2018>。
[IPV4ONLY-ARPA] Cheshire, S. and D. Schinazi, "Special Use Domain Name 'ipv4only.arpa'", Work in Progress, Internet-Draft, draft-cheshire-sudn-ipv4only-dot-arpa-14, 3 November 2018, <https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa-14>.
[IPV4ONLY-ARPA] Cheshire、S。およびD. Schinazi、「特別用途ドメイン名「ipv4only.arpa」」、進行中の作業、インターネットドラフト、draft-cheshire-sudn-ipv4only-dot-arpa-14、11月3日2018年、<https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa-14>。
[IPv6-TRANSITION] Lencse, G., Palet, J., Howard, L., Patterson, R., and I. Farrer, "Pros and Cons of IPv6 Transition Technologies for IPv4aaS", Work in Progress, Internet-Draft, draft-lmhp-v6ops-transition-comparison-03, 6 July 2019, <https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-03>.
[IPv6-TRANSITION] Lencse、G.、Palet、J.、Howard、L.、Patterson、R.、I。Farrer、「IPv4aaSのためのIPv6移行テクノロジの長所と短所」、進行中の作業、インターネットドラフト、 draft-lmhp-v6ops-transition-comparison-03、2019年7月6日、<https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-03>。
[ISOC] ISOC, "State of IPv6 Deployment 2018", June 2018, <https://www.internetsociety.org/resources/2018/state-of-ipv6-deployment-2018/>.
[ISOC] ISOC、「State of IPv6 Deployment 2018」、2018年6月、<https://www.internetsociety.org/resources/2018/state-of-ipv6-deployment-2018/>。
[OPT-464XLAT] Palet, J. and A. D'Egidio, "464XLAT Optimization", Work in Progress, Internet-Draft, draft-palet-v6ops-464xlat-opt-cdn-caches-03, 8 July 2019, <https://tools.ietf.org/html/ draft-palet-v6ops-464xlat-opt-cdn-caches-03>.
[OPT-464XLAT] Palet、J。およびA. D'Egidio、「464XLAT最適化」、Work in Progress、Internet-Draft、draft-palet-v6ops-464xlat-opt-cdn-caches-03、2019年7月8日、< https://tools.ietf.org/html/ draft-palet-v6ops-464xlat-opt-cdn-caches-03>。
[PREF64] Colitti, L. and J. Linkova, "Discovering PREF64 in Router Advertisements", Work in Progress, Internet-Draft, draft-ietf-6man-ra-pref64-06, 3 October 2019, <https://tools.ietf.org/html/draft-ietf-6man-ra-pref64-06>.
[PREF64] Colitti、L。およびJ. Linkova、「ルーターアドバタイズメントでのPREF64の発見」、Work in Progress、Internet-Draft、draft-ietf-6man-ra-pref64-06、2019年10月3日、<https：// tools .ietf.org / html / draft-ietf-6man-ra-pref64-06>。
[QUIC-CONNECTIONS] Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. Iyengar, "Specification of DNS over Dedicated QUIC Connections", Work in Progress, Internet-Draft, draft-huitema-quic-dnsoquic-07, 7 September 2019, <https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-07>.
[QUIC-CONNECTIONS] Huitema、C.、Shore、M.、Mankin、A.、Dickinson、S。、およびJ. Iyengar、「専用QUIC接続を介したDNSの仕様」、作業中、インターネットドラフト、ドラフト- huitema-quic-dnsoquic-07、2019年9月7日、<https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-07>。
[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、「Analysis of Stateful 64 Translation」、RFC 6889、DOI 10.17487 / RFC6889、2013年4月、<https：//www.rfc -editor.org/info/rfc6889>。
[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, "Architectural Considerations on Application Features in the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, <https://www.rfc-editor.org/info/rfc6950>.
[RFC6950] Peterson、J.、Kolkman、O.、Tschofenig、H。、およびB. Aboba、「DNSのアプリケーション機能に関するアーキテクチャ上の考慮事項」、RFC 6950、DOI 10.17487 / RFC6950、2013年10月、<https：// www.rfc-editor.org/info/rfc6950>。
[RFC7051] Korhonen, J., Ed. and T. Savolainen, Ed., "Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix", RFC 7051, DOI 10.17487/RFC7051, November 2013, <https://www.rfc-editor.org/info/rfc7051>.
[RFC7051]コルホネン、J。、エド。 T. Savolainen、編、「Analysis of Solution Proposals to Learn NAT64 Prefix」、RFC 7051、DOI 10.17487 / RFC7051、2013年11月、<https://www.rfc-editor.org/info/rfc7051>。
[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 Deployment Options and Experience」、RFC 7269、DOI 10.17487 / RFC7269、2014年6月、<https：//www.rfc -editor.org/info/rfc7269>。
[RFC7755] Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments", RFC 7755, DOI 10.17487/RFC7755, February 2016, <https://www.rfc-editor.org/info/rfc7755>.
[RFC7755]アンダーソン、T。、「SIIT-DC：IPv6データセンター環境向けのステートレスIP / ICMP変換」、RFC 7755、DOI 10.17487 / RFC7755、2016年2月、<https://www.rfc-editor.org/info / rfc7755>。
[RFC7756] Anderson, T. and S. Steffann, "Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode", RFC 7756, DOI 10.17487/RFC7756, February 2016, <https://www.rfc-editor.org/info/rfc7756>.
[RFC7756]アンダーソン、T。、およびS.ステファン、「IPv6インターネットデータセンター環境用のステートレスIP / ICMP変換（SIIT-DC）：デュアル変換モード」、RFC 7756、DOI 10.17487 / RFC7756、2016年2月、<https：/ /www.rfc-editor.org/info/rfc7756>。
[RFC7849] Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley, N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner, "An IPv6 Profile for 3GPP Mobile Devices", RFC 7849, DOI 10.17487/RFC7849, May 2016, <https://www.rfc-editor.org/info/rfc7849>.
[RFC7849] Binet、D.、Boucadair、M.、Vizdal、A.、Chen、G.、Heatley、N.、Chandler、R.、Michaud、D.、Lopez、D。、およびW. Haeffner、「An 3GPPモバイルデバイスのIPv6プロファイル」、RFC 7849、DOI 10.17487 / RFC7849、2016年5月、<https://www.rfc-editor.org/info/rfc7849>。
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7858] Hu、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D。、およびP. Hoffman、「DNS over Transport Layer Security（TLS）の仕様」、RFC 7858、DOI 10.17487 / RFC7858、2016年5月、<https://www.rfc-editor.org/info/rfc7858>。
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-editor.org/info/rfc8094>.
[RFC8094] Reddy、T.、Wing、D。、およびP. Patil、「DNS over Datagram Transport Layer Security（DTLS）」、RFC 8094、DOI 10.17487 / RFC8094、2017年2月、<https：//www.rfc- editor.org/info/rfc8094>。
[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 Transition Technologiesのベンチマーク手法」、RFC 8219、DOI 10.17487 / RFC8219、2017年8月、<https://www.rfc-editor.org / info / rfc8219>。
[RFC8585] Palet Martinez, J., Liu, H. M.-H., and M. Kawashima, "Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May 2019, <https://www.rfc-editor.org/info/rfc8585>.
[RFC8585] Palet Martinez、J.、Liu、HM-H。、M。Kawashima、「IPv6カスタマーエッジルーターがIPv4-as-a-Serviceをサポートするための要件」、RFC 8585、DOI 10.17487 / RFC8585、2019年5月、 <https://www.rfc-editor.org/info/rfc8585>。
[RIPE-690] RIPE, "Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose", October 2017, <https://www.ripe.net/publications/docs/ripe-690>.
[RIPE-690] RIPE、「オペレーター向けの現在のベストオペレーションプラクティス：エンドユーザーへのIPv6プレフィックス割り当て-永続的か非永続的か、どのサイズを選択するか」、2017年10月、<https://www.ripe.net/ Publications / docs / ripe-690>。
[Threat-DNS64] 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", pp. 397-411, no. 1, vol. 77, Computers & Security, DOI 10.1016/j.cose.2018.04.012, August 2018, <https://www.sciencedirect.com/science/article/pii/ S0167404818303663?via%3Dihub>.
[Threat-DNS64] Lencse、G.およびY. Kadobayashi、「さまざまなIPv6移行テクノロジーの潜在的なセキュリティ問題を特定するための方法論：DNS64およびステートフルNAT64の脅威分析」、pp。397-411、no。 1、vol。 77、Computers＆Security、DOI 10.1016 / j.cose.2018.04.012、August 2018、<https://www.sciencedirect.com/science/article/pii/ S0167404818303663？via％3Dihub>。
This section summarizes how an operator may deploy an IPv6-only network for residential/SOHO customers, supporting IPv6 inbound connections, and IPv4-as-a-Service (IPv4aaS) by using 464XLAT.
このセクションでは、464XLATを使用してIPv6インバウンド接続とIPv4-as-a-Service（IPv4aaS）をサポートし、オペレーターが住宅/ SOHOの顧客にIPv6のみのネットワークを展開する方法を要約します。
Note that an equivalent setup could also be provided for enterprise customers. If they need to support IPv4 inbound connections, several mechanisms, depending on specific customer needs, allow it; see [RFC7757].
同等の設定を企業のお客様にも提供できることに注意してください。 IPv4インバウンド接続をサポートする必要がある場合は、特定の顧客のニーズに応じて、いくつかのメカニズムで許可します。 [RFC7757]を参照してください。
Conceptually, most of the operator network could be IPv6 only (represented in the next figures as "IPv6-only flow"), or even if part of the network is actually dual stack, only IPv6 access is available for some customers (i.e., residential customers). This part of the network connects the IPv6-only subscribers (by means of IPv6-only access links) to the IPv6 upstream providers and to the IPv4-Internet by means of NAT64 (PLAT in the 464XLAT terminology).
概念的には、ほとんどのオペレーターネットワークはIPv6のみであるか（次の図では「IPv6のみのフロー」として表されます）、またはネットワークの一部が実際にデュアルスタックである場合でも、一部の顧客（つまり、住宅顧客）。ネットワークのこの部分は、IPv6のみのサブスクライバーを（IPv6のみのアクセスリンクによって）IPv6アップストリームプロバイダーに接続し、NAT64（464XLAT用語ではPLAT）を使用してIPv4-Internetに接続します。
The traffic flow from and back to the CE to services available in the IPv6 Internet (or even dual-stack remote services, when IPv6 is being used) is purely native IPv6 traffic, so there are no special considerations about it.
IPv6インターネットで利用可能なサービス（またはIPv6が使用されている場合はデュアルスタックリモートサービス）へのCEとの間のトラフィックフローは、純粋にネイティブIPv6トラフィックであるため、特別な考慮事項はありません。
From the DNS perspective, there are remote networks with IPv4 only that will typically have only IPv4 DNS (DNS/IPv4) or will at least be seen as IPv4 DNS from the CE perspective. On the operator side, the DNS, as seen from the CE, is only IPv6 (DNS/IPv6), and it also has a DNS64 function.
DNSの観点から見ると、IPv4のみのリモートネットワークがあり、通常はIPv4 DNS（DNS / IPv4）のみを備えているか、少なくともCEの観点からはIPv4 DNSと見なされます。オペレーター側では、CEから見たDNSはIPv6のみ（DNS / IPv6）であり、DNS64機能も備えています。
On the customer LANs side, there is actually one network, which of course could be split into different segments. The most common setup will be dual-stack segments, using global IPv6 addresses and [RFC1918] for IPv4, in any regular residential / Small Office, Home Office (SOHO) IPv4 network. In the figure below, it is represented as tree segments to show that the three possible setups are valid (IPv6 only, IPv4 only, and dual stack).
お客様のLAN側には、実際には1つのネットワークがありますが、当然、これは異なるセグメントに分割できます。最も一般的な設定は、通常の住宅/小規模オフィス、ホームオフィス（SOHO）IPv4ネットワークで、グローバルIPv6アドレスとIPv4の[RFC1918]を使用するデュアルスタックセグメントです。以下の図では、3つの可能なセットアップが有効であることを示すために、ツリーセグメントとして表されています（IPv6のみ、IPv4のみ、およびデュアルスタック）。
.-----. +-------+ .-----. .-----.
/ IPv6- \ | | / \ / \
( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \
\ LANs / | SOHO +--( only )--( NAT64 )--( only )
`-----' | | \ flow / `-----' \ flow /
.-----. | IPv6 | \ / \ /
/ IPv4- \ | CE | `--+--' `--+--'
( only )--+ with | | |
\ LANs / | CLAT | +---+----+ +---+----+
`-----' | | |DNS/IPv6| |DNS/IPv4|
.-----. +---+---+ | with | +--------+
/ Dual- \ | | DNS64 |
( Stack )------| +--------+
\ LANs /
`-----'
Figure 16: CE Setup with Built-In CLAT, with DNS64
図16：DNS64を使用した組み込みCLATを使用したCEセットアップ
In addition to the regular CE setup, which typically will be access-technology dependent, the steps for the CLAT function configuration can be summarized as follows:
通常はアクセス技術に依存する通常のCEセットアップに加えて、CLAT機能の構成手順は次のように要約できます。
1. Discovery of the PLAT (NAT64) prefix: It may be done using [RFC7050], [RFC7225] in those networks where PCP is supported, or other alternatives that may be available in the future, such as Router Advertising [PREF64] or DHCPv6 options [DHCPv6-OPTIONS].
1. PLAT（NAT64）プレフィックスの検出：PCPがサポートされているネットワークでは、[RFC7050]、[RFC7225]、またはルーターアドバタイズ[PREF64]やDHCPv6オプションなど、将来利用できる可能性のある他の代替手段を使用して行うことができます。 [DHCPv6-OPTIONS]。
2. If the CLAT function allows stateless NAT46 translation, a /64 from the pool typically provided to the CE by means of DHCPv6-PD [RFC8415] needs to be set aside for that translation. Otherwise, the CLAT is forced to perform an intermediate stateful NAT44 before the stateless NAT46, as described in Section 4.8.
2. CLAT機能がステートレスNAT46変換を許可する場合、通常、DHCPv6-PD [RFC8415]によってCEに提供されるプールからの/ 64は、その変換のために取っておかれる必要があります。それ以外の場合、セクション4.8で説明されているように、CLATはステートレスNAT46の前に中間のステートフルNAT44を実行する必要があります。
A more detailed configuration approach is described in [RFC8585].
より詳細な構成アプローチは[RFC8585]で説明されています。
The operator network needs to ensure that the correct responses are provided for the discovery of the PLAT prefix. It is highly recommended that [RIPE-690] be followed in order to ensure that multiple /64s are available, including the one needed for the NAT46 stateless translation.
事業者ネットワークは、PLATプレフィックスのディスカバリーに対して正しい応答が提供されるようにする必要があります。 NAT46ステートレス変換に必要な/ 64を含め、複数の/ 64を確実に使用できるようにするために、[RIPE-690]に従うことを強くお勧めします。
The operator needs to understand other issues, as described throughout this document, in order to make relevant decisions. For example, if several NAT64 functions are needed in the context of scalability / high availability, an NSP should be considered (see Section 4.5).
オペレーターは、関連する決定を行うために、このドキュメント全体で説明されているように、他の問題を理解する必要があります。たとえば、スケーラビリティ/高可用性のコンテキストで複数のNAT64関数が必要な場合は、NSPを検討する必要があります（セクション4.5を参照）。
More complex scenarios are possible, for example, if a network offers multiple NAT64 prefixes, destination-based NAT64 prefixes, etc.
たとえば、ネットワークが複数のNAT64プレフィックス、宛先ベースのNAT64プレフィックスなどを提供している場合、より複雑なシナリオが考えられます。
If the operator decides not to provide a DNS64 function, then this setup will be the same as the following figure. This will also be the setup that will be seen from the perspective of the CE, if a foreign DNS is used and consequently is not the operator-provided DNS64 function.
オペレーターがDNS64機能を提供しないことを決定した場合、このセットアップは次の図と同じになります。これは、外部DNSが使用され、その結果、オペレーターが提供するDNS64機能ではない場合に、CEの観点から見たセットアップにもなります。
.-----. +-------+ .-----. .-----.
/ IPv6- \ | | / \ / \
( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \
\ LANs / | SOHO +--( only )--( NAT64 )--( only )
`-----' | | \ flow / `-----' \ flow /
.-----. | IPv6 | \ / \ /
/ IPv4- \ | CE | `--+--' `--+--'
( only )--+ with | | |
\ LANs / | CLAT | +---+----+ +---+----+
`-----' | | |DNS/IPv6| |DNS/IPv4|
.-----. +---+---+ +--------+ +--------+
/ Dual- \ |
( Stack )------|
\ LANs /
`-----'
Figure 17: CE Setup with Built-In CLAT, without DNS64
図17：DNS64なしの組み込みCLATを使用したCEセットアップ
In this case, the discovery of the PLAT prefix needs to be arranged as indicated in Section 4.1.1.
この場合、PLATプレフィックスの検出は、セクション4.1.1に示すように調整する必要があります。
In addition, if the CE doesn't have a built-in CLAT function, the customer can choose to set up the IPv6 operator-managed CE in bridge mode (and optionally use an external router). Or, for example, if there is an access technology that requires some kind of media converter (Optical Network Termination (ONT) for fiber to the home (FTTH), Cable Modem for Data-Over-Cable Service Interface Specification (DOCSIS), etc.), the complete setup will look like Figure 18. Obviously, there will be some intermediate configuration steps for the bridge, depending on the specific access technology/ protocols, which should not modify the steps already described in the previous cases for the CLAT function configuration.
さらに、CEにCLAT機能が組み込まれていない場合、顧客はIPv6オペレーター管理CEをブリッジモードでセットアップすることを選択できます（オプションで外部ルーターを使用します）。または、たとえば、ある種のメディアコンバーターを必要とするアクセステクノロジーがある場合（Fiber to the Home（FTTH）の光ネットワーク終端（ONT）、Data-Over-Cable Service Interface Specification（DOCSIS）のケーブルモデムなど） 。）、完全なセットアップは図18のようになります。明らかに、特定のアクセステクノロジー/プロトコルによっては、ブリッジの中間構成手順がいくつかあります。CLAT機能の前のケースですでに説明されている手順を変更しないでください。構成。
+-------+ .-----. .-----.
| | / \ / \
| Res./ | / IPv6- \ .-----. / IPv4- \
| SOHO +--( only )--( NAT64 )--( only )
| | \ flow / `-----' \ flow /
| IPv6 | \ / \ /
| CE | `--+--' `--+--'
| Bridge| | |
| | +---+----+ +---+----+
| | |DNS/IPv6| |DNS/IPv4|
+---+---+ +--------+ +--------+
|
.-----. +---+---+
/ IPv6- \ | |
( only )--+ IPv6 |
\ LANs / | Router|
`-----' | |
.-----. | with |
/ IPv4- \ | CLAT |
( only )--+ |
\ LANs / | |
`-----' | |
.-----. +---+---+
/ Dual- \ |
( Stack )------|
\ LANs /
`-----'
Figure 18: CE Setup with Bridged CLAT, without DNS64
図18：DNS64を使用しない、ブリッジドCLATを使用したCEセットアップ
Several routers (i.e., the operator-provided CE and the downstream user-provided router) that enable simultaneous routing and/or CLAT should be avoided to ensure that multiple NAT44 and NAT46 levels are not used and that the operation of multiple IPv6 subnets is correct. In those cases, the use of the Home Networking Control Protocol (HNCP) [RFC8375] is suggested.
複数のNAT44およびNAT46レベルが使用されていないこと、および複数のIPv6サブネットの動作が正しいことを確認するために、同時ルーティングおよび/またはCLATを有効にするいくつかのルーター（つまり、オペレーター提供のCEおよびダウンストリームユーザー提供のルーター）は避けてください。そのような場合、ホームネットワーキングコントロールプロトコル（HNCP）[RFC8375]の使用が推奨されます。
Note that the procedure described here for the CE setup can be simplified if the CE follows [RFC8585].
CEが[RFC8585]に準拠している場合、ここで説明するCEセットアップの手順は簡略化できることに注意してください。
In addition to the regular set of features for a CE, a CLAT CE implementation requires support for:
CEの通常の機能セットに加えて、CLAT CEの実装には次のサポートが必要です。
* [RFC7915] for the NAT46 function.
* [RFC7915] NAT46機能用。
* [RFC7050] for the PLAT prefix discovery.
* [RFC7050] PLATプレフィックスの検出。
* [RFC7225] for the PLAT prefix discovery if PCP is supported.
* [RFC7225] PCPがサポートされている場合のPLATプレフィックス検出。
* [PREF64] for the PLAT prefix discovery by means of Router Advertising.
* [PREF64]ルーターアドバタイズによるPLATプレフィックスの検出。
* [DHCPv6-OPTIONS] for the PLAT prefix discovery by means of DHCP.
* [DHCPv6-OPTIONS] DHCPを使用したPLATプレフィックス検出。
* If stateless NAT46 is supported, a mechanism to ensure that multiple /64 are available, such as DHCPv6-PD [RFC8415], must be used.
* ステートレスNAT46がサポートされている場合、DHCPv6-PD [RFC8415]など、複数の/ 64が使用可能であることを確認するメカニズムを使用する必要があります。
There are several Open Source implementations of CLAT, such as:
CLATには、次のようないくつかのオープンソース実装があります。
* Android: https://github.com/ddrown/android_external_android-clat
* Android：https://github.com/ddrown/android_external_android-clat
* Jool: https://www.jool.mx
* ラグ：https://www.jool.mx
* Linux: https://github.com/toreanderson/clatd
* Linux：https://github.com/toreanderson/clatd
* OpenWRT: https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search &h=refs%2Ftags%2Fv19.07.0-rc1&st=commit&s=464xlat
* OpenWRT：https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search＆h = refs％2Ftags％2Fv19.07.0-rc1＆st = commit＆s = 464xlat
* VPP: https://git.fd.io/vpp/tree/src/plugins/nat
* VPP：https://git.fd.io/vpp/tree/src/plugins/nat
A benchmarking methodology for IPv6 transition technologies has been defined in [RFC8219]. NAT64 and 464XLAT are addressed among the single- and double-translation technologies, respectively. DNS64 is addressed in Section 9, and the methodology is elaborated in [DNS64-BM-Meth] of that document.
IPv6移行テクノロジーのベンチマーク手法は[RFC8219]で定義されています。 NAT64と464XLATは、それぞれ単一および二重変換テクノロジで処理されます。 DNS64はセクション9で扱われ、その方法論はそのドキュメントの[DNS64-BM-Meth]で詳しく説明されています。
Several documents provide references to benchmarking results, for example, for DNS64 [DNS64-Benchm].
たとえば、DNS64 [DNS64-Benchm]のベンチマーク結果への参照を提供するドキュメントがいくつかあります。
Acknowledgements
謝辞
The author would like to acknowledge the inputs of Gabor Lencse, Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker, Mohamed Boucadair, Alejandro D'Egidio, Dan Wing, Mikael Abrahamsson, and Eric Vyncke.
著者は、Gabor Lencse、Andrew Sullivan、Lee Howard、Barbara Stark、Fred Baker、Mohamed Boucadair、Alejandro D'Egidio、Dan Wing、Mikael Abrahamsson、およびEric Vynckeの入力を認めたいと思います。
Conversations with Marcelo Bagnulo, one of the coauthors of NAT64 and DNS64, and email correspondence via the IETF mailing lists with Mark Andrews have been very useful for this work.
NAT64とDNS64の共著者の1人であるMarcelo Bagnuloとの会話、およびMark AndrewsとのIETFメーリングリストを介した電子メール通信は、この作業に非常に役立ちました。
Work on this document was inspired by Christian Huitema, who suggested that DNS64 should never be used when deploying CLAT in the IETF network.
このドキュメントでの作業は、IETFネットワークにCLATを展開するときにDNS64を使用しないことを提案したChristian Huitemaに触発されました。
Author's Address
著者のアドレス
Jordi Palet Martinez The IPv6 Company Molino de la Navata, 75 28420 La Navata - Galapagar Madrid Spain
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/