[要約] RFC 7050は、IPv6アドレス合成に使用されるIPv6プレフィックスの発見に関する標準です。その目的は、IPv6アドレスの合成に使用されるプレフィックスを効率的に特定することです。
Internet Engineering Task Force (IETF) T. Savolainen
Request for Comments: 7050 Nokia
Category: Standards Track J. Korhonen
ISSN: 2070-1721 Broadcom
D. Wing
Cisco Systems
November 2013
Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
IPv6アドレス合成に使用されるIPv6プレフィックスの検出
Abstract
概要
This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments.
このドキュメントでは、DNS64の存在を検出し、アクセスネットワークでプロトコル変換に使用されるIPv6プレフィックスを学習する方法について説明します。この方法は、よく知られているIPv4のみの完全修飾ドメイン名「ipv4only.arpa。」の存在に依存します。学習した情報により、ノードはローカルIPv6アドレス合成を実行し、デュアルスタックおよびマルチインターフェイスの展開でNAT64を潜在的に回避できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7050.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7050で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements Notation and Terminology ...........................4
2.1. Requirements Notation ......................................4
2.2. Terminology ................................................4
3. Node Behavior ...................................................4
3.1. Validation of Discovered Pref64::/n ........................6
3.1.1. DNSSEC Requirements for the Network .................7
3.1.2. DNSSEC Requirements for the Node ....................7
3.2. Connectivity Check .........................................8
3.2.1. No Connectivity Checks against "ipv4only.arpa." .....9
3.3. Alternative Fully Qualified Domain Names ..................10
3.4. Message Flow Illustration .................................10
4. Operational Considerations for Hosting the IPv4-Only
Well-Known Name ................................................12
5. Operational Considerations for DNS64 Operator ..................12
5.1. Mapping of IPv4 Address Ranges to IPv6 Prefixes ...........13
6. Exit Strategy ..................................................14
7. Security Considerations ........................................14
8. IANA Considerations ............................................15
8.1. Domain Name Reservation Considerations ....................15
8.2. IPv4 Address Allocation Considerations ....................16
8.3. IAB Statement Regarding This .arpa Request ................17
9. Acknowledgements ...............................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
Appendix A. Example of DNS Record Configuration ..................20
Appendix B. About the IPv4 Address for the Well-Known Name .......21
As part of the transition to IPv6, NAT64 [RFC6146] and DNS64 [RFC6147] technologies will be utilized by some access networks to provide IPv4 connectivity for IPv6-only nodes [RFC6144]. DNS64 utilizes IPv6 address synthesis to create local IPv6 addresses for peers having only IPv4 addresses, hence allowing DNS-using IPv6-only nodes to communicate with IPv4-only peers.
IPv6への移行の一部として、NAT64 [RFC6146]およびDNS64 [RFC6147]テクノロジは、一部のアクセスネットワークでIPv6のみのノード[RFC6144]にIPv4接続を提供するために利用されます。 DNS64はIPv6アドレス合成を利用して、IPv4アドレスのみを持つピアのローカルIPv6アドレスを作成します。これにより、DNSを使用するIPv6のみのノードがIPv4のみのピアと通信できるようになります。
However, DNS64 cannot serve applications not using DNS, such as those receiving IPv4 address literals as referrals. Such applications could nevertheless be able to work through NAT64, provided they are able to create locally valid IPv6 addresses that would be translated to the peers' IPv4 addresses.
ただし、DNS64は、参照としてIPv4アドレスリテラルを受信するアプリケーションなど、DNSを使用しないアプリケーションには対応できません。それでも、このようなアプリケーションは、ピアのIPv4アドレスに変換されるローカルで有効なIPv6アドレスを作成できれば、NAT64を介して機能する可能性があります。
Additionally, DNS64 is not able to do IPv6 address synthesis for nodes running validating DNS resolvers enabled by DNS Security (DNSSEC), but instead, the synthesis must be done by the nodes themselves. In order to perform IPv6 synthesis, nodes have to learn the IPv6 prefix(es) used on the access network for protocol translation. A prefix, which may be a Network-Specific Prefix (NSP) or a Well-Known Prefix (WKP) [RFC6052], is referred to in this document as Pref64::/n [RFC6146].
さらに、DNS64は、DNSセキュリティ（DNSSEC）によって有効にされた検証DNSリゾルバーを実行しているノードのIPv6アドレス合成を実行できませんが、代わりにノード自体が合成を行う必要があります。 IPv6合成を実行するには、ノードは、プロトコル変換のためにアクセスネットワークで使用されるIPv6プレフィックスを学習する必要があります。プレフィックスは、ネットワーク固有のプレフィックス（NSP）または既知のプレフィックス（WKP）[RFC6052]の場合があり、このドキュメントではPref64 :: / n [RFC6146]と呼ばれます。
This document describes a best-effort method for applications and nodes to learn the information required to perform local IPv6 address synthesis. The IPv6 address synthesis procedure itself is out of the scope of this document. An example application is a browser encountering IPv4 address literals in an IPv6-only access network. Another example is a node running a validating security-aware DNS resolver in an IPv6-only access network.
このドキュメントでは、アプリケーションとノードがローカルIPv6アドレス合成を実行するために必要な情報を学習するためのベストエフォート方式について説明します。 IPv6アドレス合成手順自体は、このドキュメントの範囲外です。アプリケーションの例は、IPv6のみのアクセスネットワークでIPv4アドレスリテラルに遭遇するブラウザです。別の例は、IPv6のみのアクセスネットワークで検証するセキュリティ対応DNSリゾルバーを実行しているノードです。
The knowledge of IPv6 address synthesis taking place may also be useful if DNS64 and NAT64 are used in dual-stack-enabled access networks or if a node is multi-interfaced [RFC6418]. In such cases, nodes may choose to prefer IPv4 or an alternative network interface in order to avoid traversal through protocol translators.
行われているIPv6アドレス合成の知識は、DNS64とNAT64がデュアルスタック対応のアクセスネットワークで使用されている場合、またはノードがマルチインターフェースになっている場合にも役立ちます[RFC6418]。このような場合、ノードは、プロトコルトランスレータを介したトラバースを回避するために、IPv4または代替のネットワークインターフェイスを優先することを選択できます。
It is important to note that use of this approach will not result in a system that is as robust, secure, and well-behaved as an all-IPv6 system would be. Hence, it is highly recommended to upgrade nodes' destinations to IPv6 and utilize the described method only as a transition solution.
このアプローチを使用しても、全IPv6システムのように堅牢で、安全で、適切に動作するシステムにはならないことに注意することが重要です。したがって、ノードの宛先をIPv6にアップグレードし、上記の方法を移行ソリューションとしてのみ使用することを強くお勧めします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
NAT64 FQDN: a fully qualified domain name (FQDN) for a NAT64 protocol translator.
NAT64 FQDN：NAT64プロトコルトランスレータの完全修飾ドメイン名（FQDN）。
Pref64::/n: an IPv6 prefix used for IPv6 address synthesis [RFC6146].
Pref64 :: / n：IPv6アドレス合成に使用されるIPv6プレフィックス[RFC6146]。
Pref64::WKA: an IPv6 address consisting of Pref64::/n and WKA at any of the locations allowed by RFC 6052 [RFC6052].
Pref64 :: WKA：RFC 6052 [RFC6052]で許可されている任意の場所にあるPref64 :: / nおよびWKAで構成されるIPv6アドレス。
Secure Channel: a communication channel a node has between itself and a DNS64 server protecting DNS protocol-related messages from interception and tampering. The channel can be, for example, an IPsec-based virtual private network (VPN) tunnel or a link layer utilizing data encryption technologies.
セキュアチャネル：ノードが自身とDNS64サーバーとの間に持つ通信チャネルで、DNSプロトコル関連のメッセージを傍受や改ざんから保護します。チャネルは、たとえば、IPsecベースの仮想プライベートネットワーク（VPN）トンネルまたはデータ暗号化技術を利用するリンクレイヤーにすることができます。
Well-Known IPv4-only Name (WKN): the fully qualified domain name, "ipv4only.arpa.", well-known to have only A record(s).
既知のIPv4のみの名前（WKN）：完全修飾ドメイン名、 "ipv4only.arpa。"、Aレコードのみを持つことが知られています。
Well-Known IPv4 Address (WKA): an IPv4 address that is well-known and present in an A record for the well-known name. Two well-known IPv4 addresses are defined for Pref64::/n discovery purposes: 192.0.0.170 and 192.0.0.171.
既知のIPv4アドレス（WKA）：既知であり、既知の名前のAレコードに存在するIPv4アドレス。 Pref64 :: / n検出目的で2つの既知のIPv4アドレスが定義されています：192.0.0.170および192.0.0.171。
A node requiring information about the presence (or absence) of NAT64, and one or more Pref64::/n used for protocol translation SHALL send a DNS query for AAAA resource records of the Well-Known IPv4-only Name (WKN) "ipv4only.arpa.". The node MAY perform the DNS query in both IPv6-only and dual-stack access networks.
NAT64の存在（または不在）に関する情報を必要とするノード、およびプロトコル変換に使用される1つ以上のPref64 :: / nは、既知のIPv4専用名（WKN） "ipv4onlyのAAAAリソースレコードのDNSクエリを送信する必要があります。 .arpa。」ノードは、IPv6のみのネットワークとデュアルスタックアクセスネットワークの両方でDNSクエリを実行できます。
When sending a DNS AAAA resource record query for the WKN, a node MUST set the "Checking Disabled (CD)" bit to zero [RFC4035], as otherwise the DNS64 server will not perform IPv6 address synthesis (Section 3 of [RFC6147]) and hence would not reveal the Pref64::/n used for protocol translation.
WKNのDNS AAAAリソースレコードクエリを送信する場合、ノードは「Checking Disabled（CD）」ビットをゼロに設定する必要があります[RFC4035]。それ以外の場合、DNS64サーバーはIPv6アドレス合成を実行しません（[RFC6147]のセクション3）。したがって、プロトコル変換に使用されるPref64 :: / nは明らかになりません。
A DNS reply with one or more AAAA resource records indicates that the access network is utilizing IPv6 address synthesis. In some scenarios, captive portals, or NXDOMAIN and NODATA hijacking, performed by the access network may result in a false positive. One method to detect such hijacking is to query a fully qualified domain name that is known to be invalid (and normally returns an empty response or an error response) and see if it returns a valid resource record. However, as long as the hijacked domain does not result in AAAA resource record responses that contain a well-known IPv4 address in any location defined by [RFC6052], the response will not disturb the Pref64::/n learning procedure.
1つ以上のAAAAリソースレコードを含むDNS応答は、アクセスネットワークがIPv6アドレス合成を利用していることを示しています。一部のシナリオでは、アクセスネットワークによってキャプティブポータル、またはNXDOMAINおよびNODATAハイジャックが実行されると、誤検知が発生する可能性があります。このような乗っ取りを検出する方法の1つは、無効であることがわかっている（通常は空の応答またはエラー応答を返す）完全修飾ドメイン名を照会し、有効なリソースレコードを返すかどうかを確認することです。ただし、ハイジャックされたドメインが、[RFC6052]で定義された任意の場所に既知のIPv4アドレスを含むAAAAリソースレコード応答にならない限り、応答はPref64 :: / n学習手順を妨害しません。
A node MUST look through all of the received AAAA resource records to collect one or more Pref64::/n. The Pref64::/n list might include the Well-Known Prefix 64:ff9b::/96 [RFC6052] or one or more Network-Specific Prefixes. In the case of NSPs, the node SHALL determine the used address format by searching the received IPv6 addresses for the WKN's well-known IPv4 addresses. The node SHALL assume the well-known IPv4 addresses might be found at the locations specified by [RFC6052], Section 2.2. The node MUST check on octet boundaries to ensure a 32-bit well-known IPv4 address value is present only once in an IPv6 address. In case another instance of the value is found inside the IPv6 address, the node SHALL repeat the search with the other well-known IPv4 address.
ノードは、受信したすべてのAAAAリソースレコードを調べて、1つ以上のPref64 :: / nを収集する必要があります。 Pref64 :: / nリストには、既知のプレフィックス64：ff9b :: / 96 [RFC6052]または1つ以上のネットワーク固有のプレフィックスが含まれる場合があります。 NSPの場合、ノードは、受信したIPv6アドレスでWKNの既知のIPv4アドレスを検索して、使用するアドレス形式を決定する必要があります（SHALL）。ノードは、既知のIPv4アドレスが[RFC6052]、セクション2.2で指定された場所にある可能性があることを前提としています。ノードはオクテット境界をチェックして、32ビットの既知のIPv4アドレス値がIPv6アドレスに1回だけ存在することを確認する必要があります。値の別のインスタンスがIPv6アドレス内で見つかった場合、ノードは他の既知のIPv4アドレスで検索を繰り返す必要があります（SHALL）。
If only one Pref64::/n was present in the DNS response, a node SHALL use that Pref64::/n for both local synthesis and for detecting synthesis done by the DNS64 server on the network.
DNS応答にPref64 :: / nが1つだけ存在する場合、ノードはそのPref64 :: / nをローカル合成とネットワーク上のDNS64サーバーによって行われる合成の検出の両方に使用する必要があります（SHALL）。
If more than one Pref64::/n was present in the DNS response, a node SHOULD use all of them when determining whether other received IPv6 addresses are synthetic. The node MUST use all learned Pref64::/n when performing local IPv6 address synthesis and use the prefixes in the order received from the DNS64 server. That is, when the node is providing a list of locally synthesized IPv6 addresses to upper layers, IPv6 addresses MUST be synthesized by using all discovered Pref64::/n prefixes in the received order.
DNS応答に複数のPref64 :: / nが存在する場合、ノードは他の受信したIPv6アドレスが合成であるかどうかを判断するときに、それらすべてを使用する必要があります（SHOULD）。ノードは、ローカルIPv6アドレス合成を実行するときに学習したすべてのPref64 :: / nを使用し、DNS64サーバーから受信した順序でプレフィックスを使用する必要があります。つまり、ノードがローカルに合成されたIPv6アドレスのリストを上位層に提供している場合、IPv6アドレスは、検出されたすべてのPref64 :: / nプレフィックスを受信順に使用して合成する必要があります。
If the well-known IPv4 addresses are not found within the standard locations, the DNS response indicates that the network is not using a standard address format or unexpected IPv4 addresses were used in the AAAA resource record synthesis. In either case, the Pref64::/n cannot be determined and the heuristic procedure has failed. Developers can, over time, learn of IPv6-translated address formats that are extensions or alternatives to the standard formats. At that point, developers MAY add additional steps to the described discovery procedure. The additional steps are outside the scope of the present document.
既知のIPv4アドレスが標準の場所で見つからない場合、DNS応答は、ネットワークが標準のアドレス形式を使用していないか、AAAAリソースレコードの合成で予期しないIPv4アドレスが使用されたことを示します。どちらの場合も、Pref64 :: / nを判別できず、ヒューリスティックな手順が失敗しました。開発者は、時間の経過とともに、標準形式の拡張または代替であるIPv6変換アドレス形式を知ることができます。その時点で、開発者は記述されたディスカバリー手順に追加のステップを追加できます（MAY）。追加の手順は、このドキュメントの範囲外です。
In case a node does not receive a positive DNS reply to the AAAA resource record query, the node MAY perform a DNS A resource record query for the well-known name. Receiving a positive reply to the DNS A resource record query indicates that the recursive DNS server that is used is not a DNS64 server.
ノードがAAAAリソースレコードクエリに対する肯定的なDNS応答を受信しない場合、ノードは、既知の名前に対してDNS Aリソースレコードクエリを実行できます（MAY）。 DNS Aリソースレコードクエリへの肯定応答を受信すると、使用されている再帰DNSサーバーがDNS64サーバーではないことを示しています。
In the case of a negative response (NXDOMAIN, NODATA) or a DNS query timeout, a DNS64 server is not available on the access network, the access network filtered out the well-known query, or something went wrong in the DNS resolution. All unsuccessful cases result in a node being unable to perform local IPv6 address synthesis. In the case of timeout, the node SHOULD retransmit the DNS query like any other DNS query the node makes [RFC1035]. In the case of a negative response (NXDOMAIN, NODATA), the node MUST obey the Time to Live (TTL) [RFC1035] of the response before resending the AAAA resource record query. The node MAY monitor for DNS replies with IPv6 addresses constructed from the WKP, in which case if any are observed, the node SHOULD use the WKP as if it were learned during the query for the well-known name.
否定応答（NXDOMAIN、NODATA）またはDNSクエリのタイムアウトの場合、DNS64サーバーがアクセスネットワークで利用できないか、アクセスネットワークが既知のクエリを除外したか、DNS解決で問題が発生しました。すべての失敗したケースでは、ノードがローカルIPv6アドレス合成を実行できなくなります。タイムアウトの場合、ノードは、ノードが行う他のDNSクエリと同様にDNSクエリを再送信する必要があります[RFC1035]。否定応答（NXDOMAIN、NODATA）の場合、ノードは、AAAAリソースレコードクエリを再送信する前に、応答の存続時間（TTL）[RFC1035]に従う必要があります。ノードは、WKPから構築されたIPv6アドレスでDNS応答を監視する可能性があります。
To save Internet resources if possible, a node should perform Pref64::/n discovery only when needed (e.g., when local synthesis is required, when a new network interface is connected to a new network, and so forth). The node SHALL cache the replies it receives during the Pref64::/n discovery procedure, and it SHOULD repeat the discovery process ten seconds before the TTL of the Well-Known Name's synthetic AAAA resource record expires.
可能であればインターネットリソースを節約するために、ノードは必要な場合のみ（たとえば、ローカル合成が必要な場合、新しいネットワークインターフェイスが新しいネットワークに接続されている場合など）にPref64 :: / n検出を実行する必要があります。ノードは、Pref64 :: / nディスカバリ手順中に受信した応答をキャッシュする必要があり（SHALL）、既知の名前の合成AAAAリソースレコードのTTLが期限切れになる10秒前にディスカバリプロセスを繰り返す必要があります。
If a node is using an insecure channel between itself and a DNS64 server or the DNS64 server is untrusted, it is possible for an attacker to influence the node's Pref64::/n discovery procedures. This may result in denial-of-service, redirection, man-in-the-middle, or other attacks.
ノードが自身とDNS64サーバー間で安全でないチャネルを使用している場合、またはDNS64サーバーが信頼されていない場合、攻撃者がノードのPref64 :: / n検出手順に影響を与える可能性があります。これにより、サービス拒否、リダイレクト、中間者攻撃、またはその他の攻撃が発生する可能性があります。
To mitigate against attacks, the node SHOULD communicate with a trusted DNS64 server over a secure channel or use DNSSEC. NAT64 operators SHOULD provide facilities for validating discovery of Pref64::/n via a secure channel and/or DNSSEC protection.
攻撃を緩和するために、ノードは安全なチャネルを介して信頼されたDNS64サーバーと通信するか、DNSSECを使用する必要があります。 NAT64オペレーターは、安全なチャネルやDNSSEC保護を介してPref64 :: / nの検出を検証する機能を提供する必要があります（SHOULD）。
It is important to understand that DNSSEC only validates that the discovered Pref64::/n is the one that belongs to a domain used by NAT64 FQDN. Importantly, the DNSSEC validation does not tell if the node is at the network where the Pref64::/n is intended to be used. Furthermore, DNSSEC validation cannot be utilized in the case of a WKP.
DNSSECは、検出されたPref64 :: / nがNAT64 FQDNで使用されるドメインに属しているものであることのみを検証することを理解することが重要です。重要なのは、DNSSEC検証では、ノードがPref64 :: / nの使用が意図されているネットワークにあるかどうかが示されないことです。さらに、DNSSEC検証は、WKPの場合には利用できません。
If the operator has chosen to support nodes performing validation of discovered Pref64::/n with DNSSEC, the operator of the NAT64 device MUST perform the following configurations.
オペレーターがDNSSECで発見されたPref64 :: / nの検証を実行するノードをサポートすることを選択した場合、NAT64デバイスのオペレーターは次の構成を実行する必要があります。
1. Have one or more fully qualified domain names for the NAT64 translator entities (later referred to as NAT64 FQDN). In the case of more than one Pref64::/n being used in a network, e.g., for load-balancing purposes, it is for network administrators to decide whether a single NAT64's fully qualified domain name maps to more than one Pref64::/n, or whether there will be a dedicated NAT64 FQDN per Pref64::/n.
1. NAT64トランスレータエンティティ（後でNAT64 FQDNと呼ばれる）の1つ以上の完全修飾ドメイン名を持っている。ネットワークで複数のPref64 :: / nが使用されている場合、たとえば、負荷分散の目的で、ネットワーク管理者は、単一のNAT64の完全修飾ドメイン名が複数のPref64 :: /にマップするかどうかを決定する必要があります。 n、またはPref64 :: / nごとに専用のNAT64 FQDNがあるかどうか。
2. Each NAT64 FQDN MUST have one or more DNS AAAA resource records containing Pref64::WKA (Pref64::/n combined with WKA).
2. 各NAT64 FQDNには、Pref64 :: WKA（Pref64 :: / nとWKAの組み合わせ）を含む1つ以上のDNS AAAAリソースレコードが必要です。
3. Each Pref64::WKA MUST have a PTR resource record that points to the corresponding NAT64 FQDN.
3. 各Pref64 :: WKAには、対応するNAT64 FQDNを指すPTRリソースレコードが必要です。
4. Sign the NAT64 FQDNs' AAAA and A resource records with DNSSEC.
4. NAT64 FQDNのAAAAおよびAリソースレコードにDNSSECで署名します。
A node SHOULD prefer a secure channel to talk to a DNS64 server whenever possible. In addition, a node that implements a DNSSEC validating resolver MAY use the following procedure to validate discovery of the Pref64::/n.
ノードは、可能な場合は常に、DNS64サーバーと通信するために安全なチャネルを優先する必要があります（SHOULD）。さらに、DNSSEC検証リゾルバーを実装するノードは、次の手順を使用してPref64 :: / nの検出を検証できます（MAY）。
1. Heuristically find Pref64::/n candidates by making a AAAA resource record query for "ipv4only.arpa." by following the procedure in Section 3. This will result in IPv6 addresses consisting of Pref64::/n combined with WKA, i.e., Pref64::WKA. For each Pref64::/n that the node wishes to validate, the node performs the following steps.
1. "ipv4only.arpa"のAAAAリソースレコードクエリを実行して、Pref64 :: / n候補を発見的に見つけます。セクション3の手順に従ってください。これにより、Pref64 :: / nとWKAを組み合わせたIPv6アドレス、つまりPref64 :: WKAが生成されます。ノードが検証するPref64 :: / nごとに、ノードは次の手順を実行します。
2. Send a DNS PTR resource record query for the IPv6 address of the translator (for ".ip6.arpa." tree), using the Pref64::WKA learned in step 1. CNAME and DNAME results should be followed according to the rules in RFC 1034 [RFC1034], RFC 1035 [RFC1035], and RFC 6672 [RFC6672]. The ultimate response will include one or more NAT64 FQDNs.
2. 手順1で学習したPref64 :: WKAを使用して、トランスレータのIPv6アドレス（ ".ip6.arpa。"ツリー用）のDNS PTRリソースレコードクエリを送信します。CNAMEおよびDNAMEの結果は、RFCのルールに従っている必要があります1034 [RFC1034]、RFC 1035 [RFC1035]、およびRFC 6672 [RFC6672]。最終的な応答には、1つ以上のNAT64 FQDNが含まれます。
3. The node SHOULD compare the domains of learned NAT64 FQDNs to a list of the node's trusted domains and choose a NAT64 FQDN that matches. The means for a node to learn the trusted domains is implementation specific. If the node has no trust for the domain, the discovery procedure is not secure, and the remaining steps described below MUST NOT be performed.
3.ノードは、学習したNAT64 FQDNのドメインをノードの信頼されたドメインのリストと比較して、一致するNAT64 FQDNを選択する必要があります（SHOULD）。ノードが信頼されたドメインを学習するための手段は、実装固有です。ノードがドメインを信頼していない場合、検出手順は安全ではないため、以下で説明する残りの手順を実行してはなりません（MUST NOT）。
4. Send a DNS AAAA resource record query for the NAT64 FQDN.
4. NAT64 FQDNのDNS AAAAリソースレコードクエリを送信します。
5. Verify the DNS AAAA resource record contains Pref64::WKA addresses received at step 1. It is possible that the NAT64 FQDN has multiple AAAA records, in which case the node MUST check if any of the addresses match the ones obtained in step 1. The node MUST ignore other responses and not use them for local IPv6 address synthesis.
5. DNS AAAAリソースレコードに、手順1で受信したPref64 :: WKAアドレスが含まれていることを確認します。NAT64FQDNに複数のAAAAレコードがある可能性があります。その場合、ノードは、手順1で取得したアドレスと一致するアドレスがあるかどうかを確認する必要があります。ノードは他の応答を無視し、ローカルIPv6アドレス合成にそれらを使用してはなりません（MUST）。
6. Perform DNSSEC validation of the DNS AAAA response.
6. DNS AAAA応答のDNSSEC検証を実行します。
After the node has successfully performed the above five steps, the node can consider Pref64::/n validated.
ノードが上記の5つのステップを正常に実行した後、ノードはPref64 :: / nが検証されたと見なすことができます。
After learning a Pref64::/n, the node SHOULD perform a connectivity check to ensure the learned Pref64::/n is functional. It could be non-functional for a variety of reasons -- the discovery failed to work as expected, the IPv6 path to the NAT64 is down, the NAT64 is down, or the IPv4 path beyond the NAT64 is down.
Pref64 :: / nを学習した後、ノードは、接続チェックを実行して、学習したPref64 :: / nが機能していることを確認する必要があります。さまざまな理由で機能しない可能性があります-検出が期待どおりに機能しなかった、NAT64へのIPv6パスがダウンしている、NAT64がダウンしている、またはNAT64を超えるIPv4パスがダウンしています。
There are two main approaches to determine if the learned Pref64::/n is functional. The first approach is to perform a dedicated connectivity check. The second approach is to simply attempt to use the learned Pref64::/n. Each approach has some trade-offs (e.g., additional network traffic or possible user-noticeable delay), and implementations should carefully weigh which approach is appropriate for their application and the network.
学習したPref64 :: / nが機能しているかどうかを判断するには、主に2つの方法があります。最初のアプローチは、専用の接続チェックを実行することです。 2番目の方法は、学習したPref64 :: / nを使用することです。各アプローチにはいくつかのトレードオフ（たとえば、追加のネットワークトラフィックやユーザーが気付く可能性のある遅延）があり、実装では、アプリケーションとネットワークに適したアプローチを慎重に検討する必要があります。
The node SHOULD use an implementation-specific connectivity check server and a protocol of the implementation's choice, but if that is not possible, a node MAY do a PTR resource record query of the Pref64::WKA to get a NAT64 FQDN. The node then does an A resource query of the NAT64 FQDN, which will return zero or more A resource records pointing to connectivity check servers used by the network operator. A negative response to the PTR or A resource query means there are no connectivity check servers available. A network operator that provides NAT64 services for a mix of nodes with and without implementation-specific connectivity check servers SHOULD assist nodes in their connectivity checks by mapping each NAT64 FQDN to one or more DNS A resource records with IPv4 address(es) pointing to connectivity check server(s). The connectivity check approach based on Pref64::/n works only with NSPs, as it is not possible to register A records for each different domain using a WKP. The network operator MUST disable ICMPv6 rate limiting for connectivity check messages.
ノードは実装固有の接続チェックサーバーと実装で選択されたプロトコルを使用する必要があります（SHOULD）が、それが不可能な場合、ノードはPref64 :: WKAのPTRリソースレコードクエリを実行してNAT64 FQDNを取得できます（MAY）。次に、ノードはNAT64 FQDNのAリソースクエリを実行します。これは、ネットワークオペレーターが使用する接続チェックサーバーを指す0個以上のAリソースレコードを返します。 PTRまたはAリソースクエリに対する否定的な応答は、使用可能な接続チェックサーバーがないことを意味します。実装固有の接続チェックサーバーの有無にかかわらず、ノードの混合にNAT64サービスを提供するネットワークオペレーターは、各NAT64 FQDNを、接続を指すIPv4アドレスを持つ1つ以上のDNS Aリソースレコードにマッピングすることにより、ノードの接続チェックを支援する必要があります（SHOULD）サーバーをチェックしてください。 Pref64 :: / nに基づく接続チェックアプローチは、WKPを使用して異なるドメインごとにAレコードを登録することができないため、NSPでのみ機能します。ネットワークオペレーターは、接続性チェックメッセージのICMPv6レート制限を無効にする必要があります。
If multiple connectivity check servers are available for use, the node chooses the first one, preferring implementation-specific servers.
複数の接続チェックサーバーを使用できる場合、ノードは最初のサーバーを選択し、実装固有のサーバーを優先します。
The connectivity check protocol used with implementation-specific connectivity check servers is implementation specific.
実装固有の接続チェックサーバーで使用される接続チェックプロトコルは、実装固有です。
The connectivity check protocol used with connectivity check servers pointed to by the NAT64 FQDN's A resource records is ICMPv6 [RFC4443]. The node performing a connectivity check against these servers SHALL send an ICMPv6 Echo Request to an IPv6 address synthesized by combining discovered Pref64::/n with an IPv4 address of the server as specified in [RFC6052]. This will test the IPv6 path to the NAT64, the NAT64's operation, and the IPv4 path all the way to the connectivity check server. If no response is received for the ICMPv6 Echo Request, the node SHALL send another ICMPv6 Echo Request a second later. If still no response is received, the node SHALL send a third ICMPv6 Echo Request two seconds later. If an ICMPv6 Echo Response is received, the node knows the IPv6 path to the connectivity check server is functioning normally. If no response is received after three transmissions and after three seconds have elapsed since the last ICMPv6 Echo Request, the node learns this Pref64::/n might not be functioning, and the node MAY choose a different Pref64::/n (if available), choose to alert the user, or proceed anyway assuming the failure is temporary or is caused by the connectivity check itself. After all, ICMPv6 is unreliable by design, and failure to receive ICMPv6 responses may not indicate anything other than network failure to transport ICMPv6 messages.
NAT64 FQDNのAリソースレコードが指す接続確認サーバーで使用される接続確認プロトコルはICMPv6 [RFC4443]です。これらのサーバーに対して接続チェックを実行するノードは、[RFC6052]で指定されているように、発見されたPref64 :: / nとサーバーのIPv4アドレスを組み合わせて合成されたIPv6アドレスにICMPv6エコー要求を送信する必要があります（SHALL）。これにより、NAT64へのIPv6パス、NAT64の操作、および接続性チェックサーバーへのIPv4パスがテストされます。 ICMPv6エコー要求に対する応答が受信されない場合、ノードは1秒後に別のICMPv6エコー要求を送信する必要があります（SHALL）。それでも応答が受信されない場合、ノードは2秒後に3番目のICMPv6エコー要求を送信する必要があります（SHALL）。 ICMPv6エコー応答を受信した場合、ノードは、接続性チェックサーバーへのIPv6パスが正常に機能していることを認識しています。 3回の送信後、最後のICMPv6エコー要求から3秒が経過しても応答が受信されない場合、ノードはこのPref64 :: / nが機能していない可能性があることを学習し、ノードは別のPref64 :: / nを選択できます（利用可能な場合） ）、ユーザーに警告することを選択するか、障害が一時的なものであるか、接続チェック自体が原因であると想定して続行します。結局のところ、ICMPv6は設計上信頼性が低く、ICMPv6応答の受信の失敗は、ICMPv6メッセージのトランスポートのネットワーク障害以外の何も示していない場合があります。
If no separate connectivity check is performed before local IPv6 address synthesis, a node MAY monitor success of connection attempts performed with locally synthesized IPv6 addresses. Based on success of these connections, and based on possible ICMPv6 error messages received (such as Destination Unreachable messages), the node MAY cease to perform local address synthesis and MAY restart the Pref64::/n discovery procedures.
ローカルIPv6アドレス合成の前に個別の接続チェックが実行されない場合、ノードはローカルに合成されたIPv6アドレスで実行された接続試行の成功を監視できます（MAY）。これらの接続の成功と、受信した可能性のあるICMPv6エラーメッセージ（Destination Unreachableメッセージなど）に基づいて、ノードはローカルアドレス合成の実行を中止し、Pref64 :: / n検出手順を再開できます（MAY）。
Clients MUST NOT send a connectivity check to an address returned by the "ipv4only.arpa." query. This is because, by design, no server will be operated on the Internet at that address as such. Similarly, network operators MUST NOT operate a server on that address. The reason this address isn't used for connectivity checks is that operators who neglect to operate a connectivity check server will allow that traffic towards the Internet where it will be dropped and cause a false negative connectivity check with the client (that is, the NAT64 is working fine, but the connectivity check fails because a server is not operating at "ipv4only.arpa." on the Internet and a server is not operated by the NAT64 operator). Instead, for the connectivity check, an additional DNS resource record is looked up and used for the connectivity check. This ensures that packets don't unnecessarily leak to the Internet and reduces the chance of a false negative connectivity check.
クライアントは、「ipv4only.arpa」によって返されたアドレスに接続チェックを送信してはなりません（MUST NOT）。クエリ。これは、設計上、そのアドレスではインターネット上でサーバーが動作しないためです。同様に、ネットワークオペレーターはそのアドレスでサーバーを操作してはなりません。このアドレスが接続性チェックに使用されない理由は、接続性チェックサーバーの操作を怠ったオペレーターが、トラフィックがドロップされるインターネットへのトラフィックを許可し、クライアント（つまり、NAT64は正常に機能していますが、サーバーがインターネット上の「ipv4only.arpa。」で動作しておらず、サーバーがNAT64オペレーターによって操作されていないため、接続チェックは失敗します。代わりに、接続性チェックでは、追加のDNSリソースレコードが検索され、接続性チェックに使用されます。これにより、パケットがインターネットに不必要に漏洩しないようになり、誤った否定的な接続チェックの可能性が減少します。
Some applications, operating systems, devices, or networks may find it advantageous to operate their own DNS infrastructure to perform a function similar to "ipv4only.arpa." but use a different resource record. The primary advantage is to ensure availability of the DNS infrastructure and ensure the proper configuration of the DNS record itself. For example, a company named Example might have their application query "ipv4only.example.com". Other than the different DNS resource record being queried, the rest of the operations are anticipated to be identical to the steps described in this document.
一部のアプリケーション、オペレーティングシステム、デバイス、またはネットワークでは、独自のDNSインフラストラクチャを操作して「ipv4only.arpa」と同様の機能を実行することが有利である場合があります。ただし、別のリソースレコードを使用します。主な利点は、DNSインフラストラクチャの可用性を確保し、DNSレコード自体を適切に構成することです。たとえば、Exampleという名前の会社のアプリケーションクエリは「ipv4only.example.com」のようになります。クエリされる別のDNSリソースレコードを除いて、残りの操作は、このドキュメントで説明されている手順と同じであると予想されます。
The figure below gives an example illustration of a message flow in the case of prefix discovery utilizing Pref64::/n validation. The figure also shows a step where the procedure ends if no Pref64::/n validation is performed.
次の図は、Pref64 :: / n検証を利用したプレフィックス検出の場合のメッセージフローの例を示しています。この図は、Pref64 :: / n検証が実行されない場合に手順が終了するステップも示しています。
In this example, three Pref64::/n prefixes are provided by the DNS64 server. The first Pref64::/n is using an NSP, in this example, "2001:db8:42::/96". The second Pref64::/n is using an NSP, in this example, "2001:db8:43::/96". The third Pref64::/n is using the WKP. Hence, when the Pref64::/n prefixes are combined with the WKA to form Pref64::WKA, the synthetic IPv6 addresses returned by the DNS64 server are "2001:db8:42::192.0.0.170", "2001:db8:43::192.0.0.170", and "64:ff9b::192.0.0.170". The DNS64 server could also return synthetic addresses containing the IPv4 address 192.0.0.171.
この例では、3つのPref64 :: / nプレフィックスがDNS64サーバーによって提供されています。最初のPref64 :: / nはNSPを使用しています。この例では、「2001：db8：42 :: / 96」です。 2番目のPref64 :: / nはNSPを使用しています。この例では、「2001：db8：43 :: / 96」です。 3番目のPref64 :: / nはWKPを使用しています。したがって、Pref64 :: / nプレフィックスがWKAと組み合わされてPref64 :: WKAを形成する場合、DNS64サーバーから返される合成IPv6アドレスは「2001：db8：42 :: 192.0.0.170」、「2001：db8： 43 :: 192.0.0.170 "、および" 64：ff9b :: 192.0.0.170 "。 DNS64サーバーは、IPv4アドレス192.0.0.171を含む合成アドレスを返すこともできます。
The validation is not done for the WKP; see Section 3.1.
WKPの検証は行われません。セクション3.1を参照してください。
Node DNS64 server
| |
| "AAAA" query for "ipv4only.arpa." |
|----------------------------------------------->|"A" query for
| |"ipv4only.arpa."
| |--------------->
| |
| | "A" response:
| | "192.0.0.170"
| | "192.0.0.171"
| |<---------------
| +----------------------------+
| | "AAAA" synthesis using |
| | three Pref64::/n. |
| +----------------------------+
| "AAAA" response with: |
| "2001:db8:42::192.0.0.170" |
| "2001:db8:43::192.0.0.170" |
| "64:ff9b::192.0.0.170" |
|<-----------------------------------------------|
| |
+----------------------------------------------+ |
| If Pref64::/n validation is not performed, a | |
| node can fetch prefixes from AAAA responses | |
| at this point and skip the steps below. | |
+----------------------------------------------+ |
| |
| "PTR" query #1 for "2001:db8:42::192.0.0.170 |
|----------------------------------------------->|
| "PTR" query #2 for "2001:db8:43::192.0.0.170 |
|----------------------------------------------->|
| |
| "PTR" response #1 "nat64_1.example.com" |
|<-----------------------------------------------|
| "PTR" response #2 "nat64_2.example.com" |
|<-----------------------------------------------|
| |
+----------------------------------------------+ |
| Compare received domains to a trusted domain | |
| list and if matches are found, continue. | |
+----------------------------------------------+ |
| |
| "AAAA" query #1 for "nat64_1.example.com" |
|----------------------------------------------->|
| "AAAA" query #2 for "nat64_2.example.com" |
|----------------------------------------------->|
| |
| "AAAA" resp. #1 with "2001:db8:42::192.0.0.170 |
|<-----------------------------------------------|
| "AAAA" resp. #2 with "2001:db8:43::192.0.0.170 |
|<-----------------------------------------------|
| |
+----------------------------------------------+ |
| Validate AAAA responses and compare the IPv6 | |
| addresses to those previously learned. | |
+----------------------------------------------+ |
| |
+----------------------------------------------+ |
| Fetch the Pref64::/n from the validated | |
| responses and take into use. | |
+----------------------------------------------+ |
| |
Figure 1: Pref64::/n Discovery Procedure
The authoritative name server for the well-known name SHALL have DNS record TTL set to at least 60 minutes in order to improve effectiveness of DNS caching. The exact TTL value will be determined and tuned based on operational experiences.
既知の名前の権威ネームサーバーは、DNSキャッシュの効率を向上させるために、DNSレコードのTTLを少なくとも60分に設定する必要があります（SHALL）。正確なTTL値は、運用経験に基づいて決定および調整されます。
The domain serving the well-known name MUST be signed with DNSSEC. See also Section 7.
既知の名前を提供するドメインは、DNSSECで署名されている必要があります。セクション7も参照してください。
A network operator of a DNS64 server can guide nodes utilizing heuristic discovery procedures by managing the responses a DNS64 server provides.
DNS64サーバーのネットワークオペレーターは、DNS64サーバーが提供する応答を管理することにより、発見的発見手順を利用してノードをガイドできます。
If the network operator would like nodes to utilize multiple Pref64::/n prefixes, the operator needs to configure DNS64 servers to respond with multiple synthetic AAAA records. As per Section 3, the nodes can then use them all.
ネットワークオペレーターがノードで複数のPref64 :: / nプレフィックスを使用する場合、オペレーターは複数の合成AAAAレコードで応答するようにDNS64サーバーを構成する必要があります。セクション3に従って、ノードはそれらすべてを使用できます。
There are no guarantees on which of the Pref64::/n prefixes nodes will end up using. If the operator wants nodes to specifically use a certain Pref64::/n or periodically change the Pref64::/n they use, for example, for load balancing reasons, the only guaranteed method is to make DNS64 servers return only a single synthetic AAAA resource record and have the TTL of that synthetic record such that the node repeats the Pref64::/n discovery when required.
どのPref64 :: / nプレフィックスノードが最終的に使用されるかについての保証はありません。オペレーターがノードに特定のPref64 :: / nを具体的に使用することを希望する場合、または、たとえば負荷分散の理由で、使用するPref64 :: / nを定期的に変更する場合、保証される唯一の方法は、DNS64サーバーが単一の合成AAAAのみを返すようにすることリソースレコード。ノードが必要に応じてPref64 :: / nディスカバリを繰り返すように、その合成レコードのTTLを持っています。
Besides choosing how many Pref64::/n prefixes to respond and what TTL to use, DNS64 servers MUST NOT interfere with or perform other special procedures for the queries related to the well-known name.
応答するPref64 :: / nプレフィックスの数と使用するTTLを選択する以外に、DNS64サーバーは、既知の名前に関連するクエリに対して他の特別な手順を妨害または実行してはなりません。
RFC 6147 [RFC6147] allows DNS64 implementations to be able to map specific IPv4 address ranges to separate Pref64::/n prefixes. That allows handling of special use IPv4 addresses [RFC6890]. The example setup where this might be used is illustrated in Figure 2. The NAT64 "A" is used when accessing IPv4-only servers in the data center, and the NAT64 "B" is used for Internet access.
RFC 6147 [RFC6147]を使用すると、DNS64実装で特定のIPv4アドレス範囲をマップして、Pref64 :: / nプレフィックスを分離できます。これにより、特別な用途のIPv4アドレスを処理できます[RFC6890]。これが使用される可能性のある設定例を図2に示します。NAT64 "A"はデータセンターのIPv4専用サーバーにアクセスするときに使用され、NAT64 "B"はインターネットアクセスに使用されます。
NAT64 "A" ----- IPv4-only servers in a data center
/
IPv6-only node---<
\
NAT64 "B" ----- IPv4 Internet
Figure 2: NAT64s with IPv4 Address Ranges
図2：IPv4アドレス範囲を持つNAT64
The heuristic discovery method described herein does not support learning of the possible rules used by a DNS64 server for mapping specific IPv4 address ranges to separate Pref64::/n prefixes. Therefore, nodes will use the same discovered Pref64::/n to synthesize IPv6 addresses from any IPv4 address. This can cause issues for routing and connectivity establishment procedures. The operator of the NAT64 and the DNS64 ought to take this into account in the network design.
ここで説明する発見的発見方法は、特定のIPv4アドレス範囲をPref64 :: / nプレフィックスを分離するためにマッピングするためにDNS64サーバーが使用する可能なルールの学習をサポートしていません。したがって、ノードは同じ検出されたPref64 :: / nを使用して、任意のIPv4アドレスからIPv6アドレスを合成します。これにより、ルーティングと接続の確立手順に問題が発生する可能性があります。 NAT64とDNS64のオペレーターは、ネットワーク設計でこれを考慮に入れるべきです。
The network operators can help IPv6-only nodes by ensuring the nodes do not have to work with IPv4 address literals for which special mapping rules are used. That is, the IPv4-only servers addressed from the special IPv4 address ranges ought to have signed AAAA records, which allows IPv6-only nodes to avoid local address synthesis. If the IPv6-only nodes are not using DNSSEC, then it is enough if the network's DNS64 server returns synthetic AAAA resource records pointing to IPv4-only servers. Avoiding the need for IPv6-only nodes to perform address synthesis for IPv4 addresses belonging to special ranges is the best approach to assist nodes.
ネットワークオペレーターは、ノードが特別なマッピングルールが使用されるIPv4アドレスリテラルを処理する必要がないようにすることで、IPv6のみのノードを支援できます。つまり、特別なIPv4アドレス範囲からアドレス指定されたIPv4専用サーバーは、AAAAレコードに署名する必要があります。これにより、IPv6専用ノードがローカルアドレスの合成を回避できるようになります。 IPv6のみのノードがDNSSECを使用していない場合、ネットワークのDNS64サーバーがIPv4のみのサーバーを指す合成AAAAリソースレコードを返すだけで十分です。 IPv6のみのノードが特別な範囲に属するIPv4アドレスのアドレス合成を実行する必要性を回避することは、ノードを支援するための最良のアプローチです。
If the IPv6-only nodes have no choice other than using IPv4-address literals belonging to special IPv4 address ranges and the IPv6-only node will perform local synthesis by using the discovered Pref64::/n, then the network ought to ensure with routing that the packets are delivered to the correct NAT64. For example, a router in the path from an IPv6-only host to NAT64s can forward the IPv6 packets to the correct NAT64 as illustrated in Figure 3. The routing could be based on the last 32 bits of the IPv6 address, but the network operator can also use some other IPv6 address format allowed by RFC 6052 [RFC6052] if it simplifies routing setup. This setup requires additional logic on the NAT64 providing connectivity to special IPv4 address ranges: it needs to be able to translate packets it receives that are using the Pref64::/n used with Internet connections.
IPv6-onlyノードが特別なIPv4アドレス範囲に属するIPv4-addressリテラルを使用する以外に選択肢がなく、IPv6-onlyノードが発見されたPref64 :: / nを使用してローカル合成を実行する場合、ネットワークはルーティングで確実にする必要がありますパケットが正しいNAT64に配信されること。たとえば、IPv6のみのホストからNAT64へのパスにあるルーターは、図3に示すように、IPv6パケットを正しいNAT64に転送できます。ルーティングは、IPv6アドレスの最後の32ビットに基づくことができますが、ネットワークオペレータールーティングのセットアップを簡略化する場合は、RFC 6052 [RFC6052]で許可されている他のIPv6アドレス形式も使用できます。このセットアップでは、特別なIPv4アドレス範囲への接続を提供するNAT64で追加のロジックが必要です。インターネット接続で使用されるPref64 :: / nを使用する受信パケットを変換できる必要があります。
NAT64 "A" ----- IPv4-only servers in a data center
/
IPv6-only host---router
\
NAT64 "B" ----- IPv4 Internet
Figure 3: NAT64s with Assisting Router
図3：補助ルーターを使用したNAT64
A day will come when this tool is no longer needed. A node SHOULD implement a configuration knob for disabling the Pref64::/n discovery feature.
このツールが不要になる日がやってきます。ノードは、Pref64 :: / n検出機能を無効にするための設定ノブを実装する必要があります（SHOULD）。
The security considerations follow closely those of RFC 6147 [RFC6147]. The possible attacks are very similar in the case where an attacker controls a DNS64 server and returns tampered IPv6 addresses to a node and in the case where an attacker causes the node to use tampered Pref64::/n for local address synthesis. DNSSEC cannot be used to validate responses created by a DNS64 server with which the node has no trust relationship. Hence, this document does not change the big picture for untrusted network scenarios. If an attacker alters the Pref64::/n used by a DNS64 server or a node, the traffic generated by the node will be delivered to an altered destination. This can result in either a denial-of-service (DoS) attack (if the resulting IPv6 addresses are not assigned to any device), a flooding attack (if the resulting IPv6 addresses are assigned to devices that do not wish to receive the traffic), or an eavesdropping attack (in case the altered NSP is routed through the attacker).
セキュリティに関する考慮事項は、RFC 6147 [RFC6147]のそれに厳密に従っています。可能性のある攻撃は、攻撃者がDNS64サーバーを制御して改ざんされたIPv6アドレスをノードに返す場合と、攻撃者がノードに改ざんされたPref64 :: / nをローカルアドレス合成に使用させる場合と非常に似ています。 DNSSECを使用して、ノードに信頼関係がないDNS64サーバーによって作成された応答を検証することはできません。したがって、このドキュメントは、信頼できないネットワークシナリオの全体像を変えるものではありません。攻撃者がDNS64サーバーまたはノードで使用されているPref64 :: / nを変更すると、ノードによって生成されたトラフィックは変更された宛先に配信されます。これにより、サービス拒否（DoS）攻撃（結果のIPv6アドレスがどのデバイスにも割り当てられていない場合）、フラッディング攻撃（結果のIPv6アドレスがトラフィックの受信を望まないデバイスに割り当てられている場合）が発生する可能性があります）、または盗聴攻撃（変更されたNSPが攻撃者を介してルーティングされる場合）。
Even though a well-known name's DNS A resource record would not necessarily need to be protected with DNSSEC as both the name and IPv4 addresses well-known, DNSSEC protection is required for DNS AAAA resource record queries. Without DNSSEC, fake positive AAAA responses could cause hosts to erroneously detect Pref64::/n, thus allowing an attacker to inject malicious Pref64::/n for hosts' synthesis procedures. A signed "ipv4only.arpa." allows validating DNS64 servers (see [RFC6147] Section 3, Case 5, for example) to detect malicious AAAA resource records. Therefore, the zone serving the well-known name has to be protected with DNSSEC.
既知の名前のDNS Aリソースレコードは、名前とIPv4アドレスの両方が既知であるため、必ずしもDNSSECで保護する必要はありませんが、DNS AAAAリソースレコードクエリにはDNSSEC保護が必要です。 DNSSECがないと、偽の肯定的なAAAA応答により、ホストがPref64 :: / nを誤って検出し、攻撃者が悪意のあるPref64 :: / nをホストの合成手順に挿入する可能性があります。署名された「ipv4only.arpa」。 DNS64サーバー（[RFC6147]セクション3、ケース5などを参照）を検証して、悪意のあるAAAAリソースレコードを検出できるようにします。したがって、既知の名前を提供するゾーンはDNSSECで保護する必要があります。
For Pref64::/n discovery validation, the access network SHOULD sign the NAT64 translator's fully qualified domain name. A node SHOULD use the algorithm described in Section 3.1 to validate each discovered Pref64::/n.
Pref64 :: / nディスカバリ検証の場合、アクセスネットワークはNAT64トランスレータの完全修飾ドメイン名に署名する必要があります（SHOULD）。ノードは、セクション3.1で説明されているアルゴリズムを使用して、検出された各Pref64 :: / nを検証する必要があります（SHOULD）。
The procedure described in Section 3.1.2 requires a node using DNSSEC to validate discovery of Pref64::/n to have a list of trusted domains. If a matching domain is not found at Step 3 in Section 3.1.2, an implementation might be tempted to ask a user to temporarily or permanently add a received domain as trusted. History has shown that average users are unable to properly handle such queries and tend to answer positively without thinking in an attempt to move forward quickly. Therefore, unless the DNSSEC-using implementation has a way to dynamically and reliably add trusted domains, it is better to fail the Pref64::/n discovery procedure.
セクション3.1.2で説明されている手順では、DNSSECを使用するノードがPref64 :: / nの検出を検証して、信頼されたドメインのリストを取得する必要があります。セクション3.1.2のステップ3で一致するドメインが見つからない場合、受信したドメインを信頼できるものとして一時的または永続的に追加するようにユーザーに要求する実装が考えられます。歴史は、平均的なユーザーがそのようなクエリを適切に処理することができず、迅速に前進しようとすることを考えずに肯定的に回答する傾向があることを示しています。したがって、DNSSECを使用する実装に信頼できるドメインを動的かつ確実に追加する方法がない限り、Pref64 :: / n検出手順を失敗させることをお勧めします。
Lastly, the best mitigation action against Pref64::/n discovery attacks is to add IPv6 support for nodes' destinations and hence reduce the need to perform local IPv6 address synthesis.
最後に、Pref64 :: / n検出攻撃に対する最善の軽減アクションは、ノードの宛先にIPv6サポートを追加することです。これにより、ローカルIPv6アドレス合成を実行する必要性を減らします。
According to procedures described in [RFC3172] and [RFC6761], IANA has delegated a new second-level domain in the .ARPA zone for the well-known domain name "ipv4only.arpa.". The intention is that there will not be any further delegation of names below the "ipv4only.arpa." domain. The administrative and operational management of this zone is performed by IANA. The answers to the seven questions listed in [RFC6761] are as follows:
[RFC3172]と[RFC6761]で説明されている手順に従って、IANAは.ARPAゾーンの既知のドメイン名「ipv4only.arpa。」の新しい第2レベルドメインを委任しました。 「ipv4only.arpa」の下に名前の委任がなくなることを意図しています。ドメイン。このゾーンの管理および運用管理は、IANAによって実行されます。 [RFC6761]に記載されている7つの質問に対する回答は次のとおりです。
1. Are human users expected to recognize these names as special and use them differently? In what way?
1. 人間のユーザーは、これらの名前を特別なものとして認識し、別の方法で使用することを期待されていますか？どのように？
No, although this is a domain delegated under the .arpa infrastructural identifier top level domain.
いいえ。ただし、これは.arpaインフラストラクチャ識別子のトップレベルドメインの下で委任されたドメインです。
2. Are writers of application software expected to make their software recognize these names as special and treat them differently? In what way?
2. アプリケーションソフトウェアの作成者は、ソフトウェアにこれらの名前を特別なものとして認識させ、別の扱いをするように期待されていますか？どのように？
Yes. Any application attempting to perform NAT64 discovery will query the name.
はい。 NAT64ディスカバリーを実行しようとするアプリケーションはすべて、名前を照会します。
3. Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently? If so, how?
3. 名前解決APIおよびライブラリの作成者は、ソフトウェアにこれらの名前を特別なものとして認識させ、別の方法で処理することを期待されていますか？もしそうなら、どうですか？
Yes, to the extent the API or library is affected by NAT64.
はい、APIまたはライブラリがNAT64の影響を受ける範囲で。
4. Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?
4. キャッシングドメインネームサーバーの開発者は、実装にこれらの名前を特別なものとして認識させ、別の扱いをさせることを期待されていますか？もしそうなら、どうですか？
No.
の。
5. Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?
5. 権威あるドメインネームサーバーの開発者は、実装にこれらの名前を特別なものとして認識させ、別の方法で処理することを期待されていますか？もしそうなら、どうですか？
No.
の。
6. Does this reserved Special-Use Domain Name have any potential impact on DNS server operators? If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid? Do DNS server operators need to know about that and understand why? Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware?
6. この予約された特殊用途ドメイン名は、DNSサーバーオペレーターに影響を与える可能性がありますか？権限のあるDNSサーバーをこの予約名に対して権限のあるものとして構成しようとすると、準拠ネームサーバーソフトウェアはそれを無効として拒否しますか？ DNSサーバーオペレーターはそのことを知り、その理由を理解する必要がありますか？ネームサーバーソフトウェアがこの予約された名前の使用を妨げない場合でも、DNSサーバーオペレーターが知っておくべき他の方法で期待どおりに機能しない可能性がありますか？
This name has effects for operators of NAT64/DNS64, but otherwise is just another delegated .arpa domain.
この名前はNAT64 / DNS64のオペレーターに影響を与えますが、それ以外は委任された.arpaドメインにすぎません。
7. How should DNS Registries/Registrars treat requests to register this reserved domain name? Should such requests be denied? Should such requests be allowed, but only to a specially-designated entity?
7. DNSレジストリ/レジストラは、この予約済みドメイン名を登録する要求をどのように処理する必要がありますか？そのような要求は拒否されるべきですか？そのようなリクエストは許可されるべきですか、特別に指定されたエンティティのみに許可されますか？
The registry for .arpa is held at IANA, and only IANA needs to take action here.
.arpaのレジストリはIANAで保持され、IANAのみがここでアクションを実行する必要があります。
The well-known name needs to map to two different global IPv4 addresses, which have been allocated as described in [RFC6890]. The addresses have been taken from the IANA IPv4 Special Purpose Address Registry [RFC6890], and 192.0.0.170 and 192.0.0.171 have been assigned to this document with the parameters shown below:
既知の名前は、[RFC6890]で説明されているように割り当てられた2つの異なるグローバルIPv4アドレスにマップする必要があります。アドレスは、IANA IPv4特別目的アドレスレジストリ[RFC6890]から取得され、192.0.0.170および192.0.0.171は、以下に示すパラメーターでこのドキュメントに割り当てられています。
+----------------------+-------------------------------+
| Attribute | Value |
+----------------------+-------------------------------+
| Address Block | 192.0.0.170/32 |
| | 192.0.0.171/32 |
| Name | NAT64/DNS64 Discovery |
| RFC | RFC 7050, Section 2.2 |
| Allocation Date | February 2013 |
| Termination Date | N/A |
| Source | False |
| Destination | False |
| Forwardable | False |
| Global | False |
| Reserved-by-protocol | True |
+----------------------+-------------------------------+
The Record for IPv4 Address Allocation for IPv4 Special Purpose Address Registry
IPv4特別目的アドレスレジストリのIPv4アドレス割り当ての記録
The zone "ipv4only.arpa." is delegated from the ARPA zone to appropriate name servers chosen by the IANA. An apex A RRSet has been inserted in the "ipv4only.arpa." zone as follows:
ゾーン「ipv4only.arpa」。 ARPAゾーンから、IANAによって選択された適切なネームサーバーに委任されます。頂点A RRSetが「ipv4only.arpa」に挿入されました。次のゾーン：
IPV4ONLY.ARPA. IN A 192.0.0.170
IPV4ONLY.ARPA。 IN 192.0.0.170
IPV4ONLY.ARPA. IN A 192.0.0.171
IPV4ONLY.ARPA。 IN 192.0.0.171
With the publication of this document, the IAB approves of the delegation of "ipv4only" in the .arpa domain. Under [RFC3172], the IAB has requested that IANA delegate and provision "ipv4only.arpa." as written in this specification. However, the IAB does not take any architectural or technical position about this specification.
このドキュメントの公開に伴い、IABは.arpaドメインでの「ipv4only」の委任を承認します。 [RFC3172]の下で、IABはIANAに「ipv4only.arpa」を委任してプロビジョニングすることを要求しています。この仕様に記載されているとおり。ただし、IABはこの仕様に関してアーキテクチャ上または技術上の立場をとりません。
The authors would like to thank Dmitry Anipko, Cameron Byrne, Aaron Yi Ding, Christian Huitema, Washam Fan, Peter Koch, Stephan Lagerholm, Zhenqiang Li, Simon Perreault, Marc Petit-Huguenin, Andrew Sullivan, and Dave Thaler for significant improvement ideas and comments.
著者は、重要な改善のアイデアを提供してくれたDmitry Anipko、Cameron Byrne、Aaron Yi Ding、Christian Huitema、Washam Fan、Peter Koch、Stephan Lagerholm、Zhenqiang Li、Simon Perreault、Marc Petit-Huguenin、Andrew Sullivan、Dave Thalerに感謝します。コメント。
Jouni Korhonen would like to acknowledge his previous employer, Nokia Siemens Networks, where the majority of his work on this document was carried out.
Jouni Korhonenは、このドキュメントに関する彼の仕事の大部分が実行された、彼の以前の雇用主であるNokia Siemens Networksを認めたいと思います。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのプロトコル変更」、RFC 4035、2005年3月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]コンタ、A。、ディアリング、S。、およびM.グプタ、「インターネットプロトコルバージョン6（IPv6）仕様のインターネットコントロールメッセージプロトコル（ICMPv6）」、RFC 4443、2006年3月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M。、およびX. Li、「IPv4 / IPv6トランスレータのIPv6アドレッシング」、RFC 6052、2010年10月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「Stateful NAT64：Network Address and Protocol Translation to IPv6 Clients to IPv4 Servers」、RFC 6146、2011年4月。
[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, April 2011.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P.、I。van Beijnum、「DNS64：DNS Extensions for Network Address Translation to IPv4 Servers to IPv4 Servers」、RFC 6147、2011年4月。
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, June 2012.
[RFC6672] Rose、S。およびW. Wijngaards、「DNSでのDNAMEリダイレクション」、RFC 6672、2012年6月。
[RFC3172] Huston, G., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, September 2001.
[RFC3172] Huston、G.、「アドレスとルーティングパラメータエリアドメイン（ "arpa"）の管理ガイドラインと運用要件」、BCP 52、RFC 3172、2001年9月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", RFC 5735, January 2010.
[RFC5735]綿、M。およびL.ベゴダ、「特別な用途のIPv4アドレス」、RFC 5735、2010年1月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144] Baker、F.、Li、X.、Bao、C。、およびK. Yin、「Framework for IPv4 / IPv6 Translation」、RFC 6144、2011年4月。
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011.
[RFC6418] Blanchet、M。およびP. Seite、「Multiple Interfaces and Provisioning Domains Problem Statement」、RFC 6418、2011年11月。
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, February 2013.
[RFC6761] Cheshire、S。およびM. Krochmal、「特別用途ドメイン名」、RFC 6761、2013年2月。
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, April 2013.
[RFC6890]綿、M。、ベゴダ、L。、ボニカ、R。、およびB.ハーバーマン、「特別な目的のIPアドレスレジストリ」、BCP 153、RFC 6890、2013年4月。
The following BIND-style examples illustrate how A and AAAA records could be configured by a NAT64 operator.
次のBINDスタイルの例は、AおよびAAAAレコードがNAT64オペレーターによってどのように構成されるかを示しています。
The examples use Pref64::/n of 2001:db8::/96, both WKAs, and the example.com domain.
この例では、2001：db8 :: / 96のPref64 :: / n、両方のWKA、およびexample.comドメインを使用しています。
The PTR record for reverse queries (Section 3.1.1, Bullet 3):
逆クエリのPTRレコード（セクション3.1.1、箇条書き3）：
$ORIGIN A.A.0.0.0.0.0.C\ .0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA. @ IN SOA ns1.example.com. hostmaster.example.com. ( 2003080800 12h 15m 3w 2h) IN NS ns.example.com.
$ ORIGIN A.A.0.0.0.0.0.C \ .0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA。 @ IN SOA ns1.example.com。 hostmaster.example.com。 （2003080800 12h 15m 3w 2h）IN NS ns.example.com。
IN PTR nat64.example.com.
IN PTR nat64.example.com。
$ORIGIN B.A.0.0.0.0.0.C\ .0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA. @ IN SOA ns1.example.com. hostmaster.example.com. ( 2003080800 12h 15m 3w 2h) IN NS ns.example.com.
$ ORIGIN B.A.0.0.0.0.0.C \ .0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA。 @ IN SOA ns1.example.com。 hostmaster.example.com。 （2003080800 12h 15m 3w 2h）IN NS ns.example.com。
IN PTR nat64.example.com.
IN PTR nat64.example.com。
If example.com does not use DNSSEC, the following configuration file could be used. Please note that nat64.example.com has both a AAAA record with the Pref64::/n and an A record for the connectivity check (Section 3.1.1, Bullet 2).
example.comがDNSSECを使用しない場合、次の構成ファイルを使用できます。 nat64.example.comには、Pref64 :: / nのAAAAレコードと、接続チェック用のAレコードの両方があることに注意してください（セクション3.1.1、箇条書き2）。
example.com. IN SOA ns.example.com. hostmaster.example.com. ( 2002050501 ; serial 100 ; refresh (1 minute 40 seconds) 200 ; retry (3 minutes 20 seconds) 604800 ; expire (1 week) 100 ; minimum (1 minute 40 seconds) )
example.com。 IN SOA ns.example.com。 hostmaster.example.com。 （2002050501;シリアル100;更新（1分40秒）200;再試行（3分20秒）604800;有効期限（1週間）100;最小（1分40秒））
example.com. IN NS ns.example.com.
example.com。 IN NS ns.example.com。
nat64.example.com.
IN AAAA 2001:db8:0:0:0:0:C000:00AA
IN AAAA 2001:db8:0:0:0:0:C000:00AB
IN A 192.0.2.1
For DNSSEC to sign the records, the owner of the example.com zone would have RRSIG records for both the AAAA and A records for nat64.example.com. As a normal DNSSEC requirement, the zone and its parent also need to be signed.
DNSSECがレコードに署名する場合、example.comゾーンの所有者は、nat64.example.comのAAAAおよびAレコードの両方のRRSIGレコードを持っています。通常のDNSSEC要件として、ゾーンとその親も署名する必要があります。
The IPv4 addresses for the well-known name cannot be non-global IPv4 addresses as listed in the Section 3 of [RFC5735]. Otherwise, DNS64 servers might not perform AAAA record synthesis when the well-known prefix is used, as stated in Section 3.1 of [RFC6052]. However, the addresses do not have to be routable or allocated to any real node as no communications will be initiated to these IPv4 address.
[RFC5735]のセクション3に記載されているように、既知の名前のIPv4アドレスを非グローバルIPv4アドレスにすることはできません。そうしないと、[RFC6052]のセクション3.1で説明されているように、既知のプレフィックスが使用されている場合、DNS64サーバーがAAAAレコード合成を実行しない可能性があります。ただし、これらのIPv4アドレスへの通信は開始されないため、アドレスはルーティング可能である必要はなく、実際のノードに割り当てられている必要もありません。
Allocation of at least two IPv4 addresses improves the heuristics in cases where the bit pattern of the primary IPv4 address appears more than once in the synthetic IPv6 address (i.e., the NSP prefix contains the same bit pattern as the IPv4 address).
少なくとも2つのIPv4アドレスを割り当てると、プライマリIPv4アドレスのビットパターンが合成IPv6アドレスで複数回出現する場合（つまり、NSPプレフィックスにIPv4アドレスと同じビットパターンが含まれる場合）のヒューリスティックが向上します。
If no well-known IPv4 addresses would be statically allocated for this method, the heuristic would require sending of an additional A query to learn the IPv4 addresses that would be then searched from inside of the received IPv6 address.
このメソッドに既知のIPv4アドレスが静的に割り当てられない場合、ヒューリスティックは追加のAクエリを送信して、受信したIPv6アドレスの内部から検索されるIPv4アドレスを学習する必要があります。
Authors' Addresses
著者のアドレス
Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 Tampere Finland
Teemu Savolainen Nokia Hermiankatu 12 D FI-33720タンペレフィンランド
EMail: teemu.savolainen@nokia.com
Jouni Korhonen Broadcom Linnoitustie 6 FI-02600 Espoo Finland
Jouni Korhonen Broadcom Linnoitustie 6 FI-02600 Espooフィンランド
EMail: jouni.nospam@gmail.com
Dan Wing Cisco Systems 170 West Tasman Drive San Jose, California 95134 USA
Dan Wing Cisco Systems 170 West Tasman Drive San Jose、California 95134 USA
EMail: dwing@cisco.com