Internet Engineering Task Force (IETF) N. Buraglio
Request for Comments: 9872 Energy Sciences Network
Category: Informational T. Jensen
ISSN: 2070-1721
J. Linkova
Google
September 2025
On networks providing IPv4-IPv6 translation (RFC 7915), hosts and other endpoints need to know the IPv6 prefix(es) used for translation (the NAT64 prefix (RFC 6052)). This document provides guidelines for NAT64 prefix discovery, specifically recommending obtaining the NAT64 prefix from the Router Advertisement option (RFC 8781) when available.
IPv4-IPV6翻訳（RFC 7915）を提供するネットワークでは、ホストおよびその他のエンドポイントが翻訳に使用されるIPv6プレフィックス（ES）を知る必要があります（NAT64プレフィックス（RFC 6052））。このドキュメントは、NAT64プレフィックスディスカバリーのガイドラインを提供します。これは、利用可能な場合は、ルーター広告オプション（RFC 8781）からNAT64プレフィックスを取得することをお勧めします。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9872.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9872で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
3. Recommendations for PREF64 Discovery
3.1. Deployment Recommendations for Endpoints
3.2. Deployment Recommendations for Operators
3.2.1. Mobile Network Considerations
3.2.2. Migration Considerations
4. Existing Issues with RFC 7050
4.1. Dependency on Network-Provided Recursive Resolvers
4.2. Network Stack Initialization Delay
4.3. Latency in Updates Propagation
4.4. Multihoming Implications
4.5. Security Implications
4.5.1. Definition of Secure Channel
4.5.2. Secure Channel Example of IPsec
4.5.3. Secure Channel Example of Link Layer Encryption
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Authors' Addresses
Devices translating between IPv4 and IPv6 packet headers [RFC7915] use a NAT64 prefix to map IPv4 addresses into the IPv6 address space, and vice versa. When a network provides NAT64, it is advantageous for endpoints to acquire the network's NAT64 prefixes (PREF64). Discovering the PREF64 enables endpoints to:
IPv4とIPv6パケットヘッダー[RFC7915]間で翻訳するデバイスNAT64プレフィックスを使用して、IPv4アドレスをIPv6アドレススペースにマッピングします。ネットワークがNAT64を提供する場合、エンドポイントがネットワークのNAT64プレフィックスを取得することが有利です（Pref64）。fref64を発見すると、エンドポイントが次のことを可能にします。
* Implement the customer-side translator (CLAT) function of the 464XLAT architecture [RFC6877].
* 464xlatアーキテクチャ[RFC6877]の顧客側翻訳者（CLAT）関数を実装します。
* Translate IPv4 literals to IPv6 literals (Section 7.1 of [RFC8305]).
* IPv4リテラルをIPv6リテラルに変換します（[RFC8305]のセクション7.1）。
* Perform local DNS64 [RFC6147] functions.
* ローカルDNS64 [RFC6147]関数を実行します。
* Support applications relying on IPv4 address referral (Section 3.2.2 of [RFC7225]).
* IPv4アドレス紹介に依存するサポートアプリケーション（[RFC7225]のセクション3.2.2）。
Dynamic PREF64 discovery is useful to keep the NAT64 prefix configuration up-to-date, particularly for unmanaged endpoints or endpoints that move between networks. [RFC7050] introduces the first DNS64-based mechanism for PREF64 discovery per the analysis described in [RFC7051]. However, subsequent methods have been developed to address the limitations of the mechanism described in [RFC7050].
Dynamic Pref64 Discoveryは、特にネットワーク間を移動する管理されていないエンドポイントまたはエンドポイントの場合、NAT64プレフィックス構成を最新の状態に保つのに役立ちます。[RFC7050]は、[RFC7051]に記載されている分析ごとに、FREF64発見の最初のDNS64ベースのメカニズムを導入します。ただし、[RFC7050]で説明されているメカニズムの制限に対処するために、その後の方法が開発されています。
For instance, [RFC8781] defines a Neighbor Discovery [RFC4861] option for Router Advertisements (RAs) to convey PREF64 information to hosts. This approach offers several advantages (Section 3 of [RFC8781]), including fate sharing with other host network configuration parameters.
たとえば、[RFC8781]は、Router Advertisements（RAS）の近隣発見[RFC4861]オプションを定義して、FREG64情報をホストに伝えます。このアプローチは、他のホストネットワーク構成パラメーターとの運命を共有する運命を含む、いくつかの利点（[RFC8781]のセクション3）を提供します。
Due to fundamental shortcomings of the mechanism defined in [RFC7050] (see Section 4 for more details), [RFC8781] describes the preferred solution for new deployments. Implementations should strive for consistent PREF64 acquisition methods. The DNS64-based mechanism of [RFC7050] should be employed only when RA-based PREF64 delivery is unavailable or as a fallback for legacy systems incapable of processing the PREF64 RA Option.
[RFC7050]で定義されているメカニズムの基本的な欠点により（詳細についてはセクション4を参照）、[RFC8781]は、新しい展開に適したソリューションについて説明します。実装は、一貫したPref64取得方法を目指して努力する必要があります。[RFC7050]のDNS64ベースのメカニズムは、RAベースのPref64配信が利用できない場合、またはPref64 RAオプションを処理できないレガシーシステムのフォールバックとしてのみ使用する必要があります。
DNS64:
DNS64：
A mechanism for synthesizing AAAA records from A records, defined in [RFC6147].
[RFC6147]で定義されているレコードからAAAAレコードを合成するためのメカニズム。
NAT64:
NAT64：
A mechanism for translating IPv6 packets to IPv4 packets, and vice versa. The translation is done by translating the packet headers according to the IP/ICMP Translation Algorithm defined in [RFC7915]. NAT64 translators can operate in stateful mode [RFC6144] or stateless mode [RFC6877] (e.g., customer-side translator (CLAT)). This document uses "NAT64" as a generalized term for a translator, which uses the stateless IP/ICMP Translation Algorithm defined in [RFC7915] and operates within a framework for IPv4/IPv6 translation described in [RFC6144].
IPv6パケットをIPv4パケットに変換するメカニズム、およびその逆。翻訳は、[RFC7915]で定義されているIP/ICMP翻訳アルゴリズムに従ってパケットヘッダーを翻訳することによって行われます。NAT64翻訳者は、ステートフルモード[RFC6144]またはステートレスモード[RFC6877]（例えば、顧客側の翻訳者（CLAT））で動作できます。このドキュメントは、[RFC7915]で定義されたステートレスIP/ICMP翻訳アルゴリズムを使用し、[RFC6144]で説明されているIPv4/IPv6翻訳のフレームワーク内で動作する翻訳者の一般化用語として「NAT64」を使用します。
PREF64:
PREF64：
Pref64::/n or NAT64 prefix. An IPv6 prefix used for IPv6 address synthesis [RFC6146].
pref64 ::/nまたはnat64プレフィックス。IPv6アドレス合成[RFC6146]に使用されるIPv6プレフィックス。
RA:
RA:
Router Advertisement. A packet used by Neighbor Discovery [RFC4861] and SLAAC to advertise the presence of the routers, together with other IPv6 configuration information.
ルーター広告。Neighbor Discovery [RFC4861]とSLAACが使用するパケットは、他のIPv6構成情報とともにルーターの存在を宣伝します。
SLAAC:
Slaac：
Stateless Address Autoconfiguration [RFC4862].
ステートレスアドレスAutoconfiguration [RFC4862]。
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] で説明されているように解釈されます。
Endpoints SHOULD attempt to obtain PREF64 information from RAs per [RFC8781], instead of using the method described in [RFC7050]. In the absence of the PREF64 information in RAs, an endpoint MAY choose to fall back to the mechanism defined in [RFC7050]. This recommendation to prefer the mechanism defined in [RFC8781] over the one defined in [RFC7050] is consistent with Section 5.1 of [RFC8781].
エンドポイントは、[RFC7050]で説明されている方法を使用する代わりに、[RFC8781]ごとにRASからPref64情報を取得しようとする必要があります。RASにfref64情報がない場合、エンドポイントは[RFC7050]で定義されているメカニズムに戻ることを選択する場合があります。[rfc8781]で[RFC7050]で定義されているメカニズムよりも[RFC8781]よりも[RFC8781]を好むこの推奨事項は、[RFC8781]のセクション5.1と一致しています。
Network operators deploying NAT64 SHOULD provide PREF64 information in Router Advertisements per [RFC8781].
NAT64を展開するネットワークオペレーターは、[RFC8781]ごとにルーター広告にPref64情報を提供する必要があります。
While support for the option specified in [RFC8781] is widely integrated into modern operating systems on mobile endpoints, equipment deployed in mobile network environments often lacks abilities to include the PREF64 Option into RAs. Therefore, the immediate deployment and enablement of PREF64 by mobile operators may not currently be feasible and the recommendations outlined in this document are not presently applicable to mobile network operators. These environments are encouraged to incorporate the option specified in [RFC8781] when made practical by infrastructure upgrades or software stack feature additions.
[RFC8781]で指定されているオプションのサポートは、モバイルエンドポイントの最新のオペレーティングシステムに広く統合されていますが、モバイルネットワーク環境に展開されている機器には、RASにPref64オプションを含める能力がしばしば欠けています。したがって、モバイルオペレーターによるfref64の即時展開と有効化は現在実行不可能である可能性があり、このドキュメントで概説されている推奨事項は現在、モバイルネットワークオペレーターには適用できません。これらの環境は、インフラストラクチャのアップグレードまたはソフトウェアスタック機能の追加により実用的になった場合、[RFC8781]で指定されたオプションを組み込むことが推奨されます。
Transitioning from the heuristic procedure in [RFC7050] to using the approach in [RFC8781] might require a period of time where both mechanisms coexist. How long this may take depends on the endpoint footprint, particularly the presence and number of endpoints running outdated operating systems that do not support the option in [RFC8781]. Operators are advised to take those factors into account prior to removing support for the heuristic procedure in [RFC7050], noting that it is still safe to add support for the approach in [RFC8781] since endpoints that support it will always prefer it over [RFC7050] if they follow RFC requirements.
[RFC7050]のヒューリスティック手順から[RFC8781]のアプローチを使用することに移行するには、両方のメカニズムが共存する期間が必要になる場合があります。これがどれだけ時間がかかるかは、エンドポイントのフットプリント、特に[RFC8781]のオプションをサポートしていない時代遅れのオペレーティングシステムを実行するエンドポイントの存在と数に依存します。オペレーターは、[RFC7050]のヒューリスティック手順のサポートを削除する前に、これらの要因を考慮に入れることをお勧めします。これは、RFC要件に従う場合は常に[RFC7050]よりも[RFC8781]よりも[RFC8781]のアプローチのサポートを追加することは安全であることに注意してください。
Migrating away from DNS64-based discovery also reduces dependency on DNS64 in general, thereby eliminating DNSSEC and DNS64 incompatibility concerns (Section 6.2 of [RFC6147]).
DNS64ベースの発見から離れて移動すると、一般にDNS64への依存性が低下し、DNSSECおよびDNS64の非互換性の懸念が排除されます（[RFC6147]のセクション6.2）。
DNS-based discovery of the NAT64 prefix introduces some challenges, which make this approach less preferable than the latest developed alternatives (such as the PREF64 RA Option [RFC8781]). This section outlines the key issues associated with [RFC7050] with a focus on those not discussed in [RFC7050] or in the analysis of solutions for hosts to discover the NAT64 prefix [RFC7051].
NAT64プレフィックスのDNSベースの発見は、いくつかの課題を導入します。これにより、このアプローチは、最新の開発された代替案よりも好ましくなくなります（FREF64 RAオプション[RFC8781]など）。このセクションでは、[RFC7050]に関連する[RFC7050]に関連する重要な問題の概要を説明します。[RFC7050]で説明されていないもの、または宿主のソリューションの分析でNAT64プレフィックス[RFC7051]を発見します。
Signalling PREF64 in the RA Option addresses all issues outlined in this section (see Section 3 of [RFC8781] for details).
RAオプションのSignaling Pref64は、このセクションで概説されているすべての問題に対処します（詳細については、[RFC8781]のセクション3を参照）。
The presence or absence of NAT64 functionality, as well as its associated prefix (if present), are network-dependent attributes. Therefore, [RFC7050] requires the endpoint discovering the prefix to use the DNS64 resolvers provided by the network. If the device or an application is configured to use other recursive resolvers or runs a local recursive resolver, the corresponding name resolution APIs and libraries are required to recognize 'ipv4only.arpa.' as a special name and give it special treatment. This issue and remediation approach are discussed in [RFC8880]. However, it has been observed that very few implementations of the method described in [RFC7050] support the requirements specified in [RFC8880] for special treatment of 'ipv4only.arpa.'. As a result, configuring such systems and applications to use resolvers other than the one provided by the network breaks the PREF64 discovery, leading to degraded user experience.
NAT64機能の有無、および関連するプレフィックス（存在する場合）は、ネットワーク依存属性です。したがって、[RFC7050]では、ネットワークが提供するDNS64リゾルバーを使用するプレフィックスを発見するエンドポイントが必要です。デバイスまたはアプリケーションが他の再帰リゾルバーを使用するように構成されている場合、またはローカル再帰リゾルバーを実行する場合、対応する名前解像度APIとライブラリは「IPv4only.arpa」を認識するために必要です。特別な名前として、特別な治療を行います。この問題と修復アプローチについては、[RFC8880]で説明します。ただし、[RFC7050]に記載されているメソッドの実装は、[RFC8880]で指定された要件をサポートして、「IPv4only.Arpa。」の特別な治療のためにサポートすることがわずかであることが観察されています。その結果、ネットワークが提供するもの以外のリゾルバーを使用するようにこのようなシステムとアプリケーションを構成すると、Pref64ディスカバリーが破損し、ユーザーエクスペリエンスが低下します。
VPN applications may override the endpoint's DNS configuration, for example, by configuring enterprise DNS servers as the node's recursive resolvers and forcing all name resolution through the VPN. These enterprise DNS servers typically lack DNS64 functionality and therefore cannot provide information about the PREF64 used within the local network. If the VPN is configured in so-called "split tunneling" mode (when only a subset of network traffic is routed into the VPN tunnel), endpoints may not discover the necessary PREF64, which negatively impacts their connectivity on IPv6-only networks.
VPNアプリケーションは、エンドポイントのDNS構成をオーバーライドする場合があります。たとえば、エンタープライズDNSサーバーをノードの再帰リゾルバーとして構成し、VPNを介してすべての名前解像度を強制することができます。これらのエンタープライズDNSサーバーは通常、DNS64機能がないため、ローカルネットワーク内で使用されるfref64に関する情報を提供できません。VPNがいわゆる「スプリットトンネル」モードで構成されている場合（ネットワークトラフィックのサブセットのみがVPNトンネルにルーティングされる場合）、エンドポイントは必要なPREF64を発見しない場合があります。
If both the network-provided DNS64 and the endpoint's resolver happen to utilize the Well-Known Prefix (64:ff9b::/96) [RFC6052], the endpoint would end up using a PREF64 that's valid for the current network. However, if the endpoint changes its network attachment, it can't detect if the new network lacks NAT64 entirely or uses a network-specific prefix (NSP) [RFC6144] for NAT64.
ネットワークが提供するDNS64とエンドポイントのリゾルバーの両方が、よく知られているプレフィックス（64：FF9B ::/96）[RFC6052]を使用している場合、エンドポイントは現在のネットワークに有効なFREF64を使用します。ただし、エンドポイントがネットワークの添付ファイルを変更した場合、新しいネットワークにNAT64が完全に欠けているか、NAT64にネットワーク固有のプレフィックス（NSP）[RFC6144]を使用しているかどうかは検出できません。
Signalling PREF64 in an RA Option decouples the PREF64 discovery from the host's DNS resolver configuration.
RAオプションのシグナリングPREF64は、ホストのDNSリゾルバー構成からのPref64発見を切り離します。
When using SLAAC, an IPv6 host typically requires a single RA to acquire its network configuration. For IPv6-only endpoints, timely PREF64 discovery is critical, particularly for those performing local DNS64 or NAT64 functions, such as CLAT [RFC6877]. Until a PREF64 is obtained, the endpoint's IPv4-only applications and communication to IPv4-only destinations are impaired. The mechanism defined in [RFC7050] does not bundle PREF64 information with other network configuration parameters and requires at least one round-trip time (to send a DNS request and receive a response) after the network stack configuration is completed.
SLAACを使用する場合、IPv6ホストは通常、ネットワーク構成を取得するために単一のRAを必要とします。IPv6のみのエンドポイントの場合、特にCLAT [RFC6877]などのローカルDNS64またはNAT64関数を実行している人にとっては、タイムリーなPref64発見が重要です。Pref64が取得されるまで、EndpointのIPv4のみのアプリケーションとIPv4のみの宛先への通信が損なわれます。[RFC7050]で定義されているメカニズムは、他のネットワーク構成パラメーターにプレフ64情報をバンドルせず、ネットワークスタック構成が完了した後、少なくとも1回の往復時間（DNS要求を送信して応答を受信するため）が必要です。
On the other hand, advertising PREF64 in an RA eliminates the period when the host obtains IPv6 addresses and default routers but no PREF64.
一方、RAのfref64は、ホストがIPv6アドレスとデフォルトのルーターを取得しますが、pref64は取得しない期間を排除します。
Section 3 of [RFC7050] states:
[RFC7050]のセクション3は次のとおりです。
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発見手順中に受信した応答をキャッシュするものとし、有名な名前の合成AAAAリソースレコードのTTLの10秒前に発見プロセスを繰り返す必要があります。
As a result, once a PREF64 is discovered, it will be used until the TTL expires or until the node disconnects from the network. There is no mechanism for an operator to force the PREF64 rediscovery on the node without disconnecting the node from the network. If the operator needs to change the PREF64 value used in the network, they need to proactively reduce the TTL value returned by the DNS64 server. This method has two significant drawbacks:
その結果、Pref64が発見されると、TTLの有効期限が切れるまで、またはノードがネットワークから切断されるまで使用されます。ネットワークからノードを切断することなく、ノードにfref64再発見を強制するオペレーターが強制するメカニズムはありません。オペレーターがネットワークで使用されるfref64値を変更する必要がある場合、DNS64サーバーによって返されるTTL値を積極的に削減する必要があります。この方法には2つの重要な欠点があります。
* Many networks utilize external DNS64 servers and therefore have no control over the TTL value if the PREF64 needs to be changed or withdrawn.
* 多くのネットワークは、外部DNS64サーバーを利用しているため、PREF64を変更または撤回する必要がある場合、TTL値を制御できません。
* The PREF64 changes need to be planned and executed at least TTL seconds in advance. If the operator needs to notify nodes that a particular prefix must not be used (e.g., during a network outage or if the nodes learned a rogue PREF64 as a result of an attack), it might not be possible without interrupting the network connectivity for the affected nodes.
* Pref64の変更は、少なくとも事前にTTL秒を計画および実行する必要があります。オペレーターが特定のプレフィックスを使用してはならないことをノードに通知する必要がある場合（たとえば、ネットワークの停止中、またはノードが攻撃の結果としてRogue Pref64を学習した場合）、影響を受けるノードのネットワーク接続を中断することなく不可能かもしれません。
The mechanism defined in [RFC8781] allows notifying hosts about PREF64 changes immediately by sending an RA with updated information.
[RFC8781]で定義されているメカニズムにより、更新された情報を使用してRAを送信することにより、Fref64の変更に関するホストにすぐに通知できます。
Section 3 of [RFC7050] requires a node to examine all received AAAA resource records to discover one or more PREF64s and to utilize all learned prefixes. However, this approach presents challenges in some multihomed topologies where different DNS64 servers belonging to different ISPs might return different PREF64s. In such cases, it is crucial that traffic destined for synthesized addresses is sent to the correct NAT64 and the source address selected for those flows belongs to the prefix from that ISP's address space. In other words, the node needs to associate each discovered PREF64 with upstream information, including the IPv6 prefix and default gateway. Currently, there is no reliable way for a node to map a DNS64 response (and the prefix learned from it) to a specific upstream in a multihoming scenario. Consequently, the node might inadvertently select an incorrect source address for a given PREF64 and/or send traffic to the incorrect uplink.
[RFC7050]のセクション3では、1つまたは複数のPref64sを発見し、学習したすべてのプレフィックスを利用するために、受信したすべてのAAAAリソースレコードを調べるノードが必要です。ただし、このアプローチは、異なるISPに属する異なるDNS64サーバーが異なるfref64を返す可能性があるいくつかのマルチホームのトポロジに課題を提示します。そのような場合、合成アドレスに運命づけられているトラフィックが正しいNAT64に送信され、それらのフローに選択されたソースアドレスは、ISPのアドレス空間からプレフィックスに属します。言い換えれば、ノードは、IPv6プレフィックスやデフォルトゲートウェイなど、発見された各fref64を上流の情報に関連付ける必要があります。現在、ノードがDNS64応答（およびそれから学習したプレフィックス）をマルチホームシナリオで特定のアップストリームにマッピングする信頼できる方法はありません。その結果、ノードは、特定のfref64の誤ったソースアドレスを誤って選択したり、トラフィックを間違ったアップリンクに送信したりする場合があります。
Advertising PREF64 in RAs allows hosts to track which PREF64 was advertised by which router and use that information to select the correct next hop. Section 8 of [CLAT] discusses this scenario in more details.
RASの広告Pref64を使用すると、ホストはどのrouterによって広告されたかを追跡し、その情報を使用して正しい次のホップを選択します。[CLAT]のセクション8では、このシナリオについて詳しく説明します。
As discussed in Section 7 of [RFC7050], the DNS-based PREF64 discovery is prone to DNS spoofing attacks. In addition to creating a wider attack surface for IPv6 deployments, [RFC7050] has other security challenges, which are discussed below.
[RFC7050]のセクション7で説明したように、DNSベースのPref64ディスカバリーは、DNSスプーフィング攻撃を起こしやすいです。IPv6展開用のより広い攻撃面を作成することに加えて、[RFC7050]には、以下で説明する他のセキュリティの課題があります。
[RFC7050] requires a node's communication channel with a DNS64 server to be a "secure channel", which it defines to mean "a communication channel a node has between itself and a DNS64 server protecting DNS protocol-related messages from interception and tampering". This need is redundant when another communication mechanism of IPv6-related configuration, specifically RAs, can already be defended against tampering, for example, by enabling RA-Guard [RFC6105]. When the mechanism defined in [RFC8781] is used in place of the one defined in [RFC7050], nodes only need to implement one defense mechanism; requiring nodes to implement two defense mechanisms creates an unnecessary risk.
[RFC7050]は、DNS64サーバーを使用したノードの通信チャネルを「セキュアチャネル」とする必要があります。これは、「インターセプトと改ざんからのDNSプロトコル関連のメッセージを保護するDNS64サーバーの間にノードが持つ通信チャネル」を意味すると定義しています。このニーズは、IPv6関連構成の別の通信メカニズム、特にRASが、たとえばRa-Guard [RFC6105]を有効にすることにより、改ざんから既に防御できる場合に冗長です。[RFC8781]で定義されているメカニズムが[RFC7050]で定義されているメカニズムの代わりに使用される場合、ノードは1つの防御メカニズムを実装する必要があります。2つの防御メカニズムを実装するためにノードを要求すると、不必要なリスクが生じます。
One of the two examples that [RFC7050] defines to qualify a communication channel with a DNS64 server is the use of an "IPsec-based virtual private network (VPN) tunnel". As of the time of this writing, this is not supported as a practice by any common operating system DNS client. While they could, there have also since been multiple mechanisms defined for performing DNS-specific encryption, such as those defined in [RFC9499], that would be more appropriately scoped to the applicable DNS traffic. These are also compatible with encrypted DNS advertisement by the network using Discovery of Network-designated Resolvers [RFC9463], which would ensure the clients know in advance that the DNS64 server supported the encryption mechanism.
[RFC7050]がDNS64サーバーを使用して通信チャネルを修飾するために定義する2つの例の1つは、「IPSECベースの仮想プライベートネットワーク（VPN）トンネル」の使用です。この執筆時点では、これは一般的なオペレーティングシステムDNSクライアントによって実践としてサポートされていません。彼らはそうすることができましたが、それ以来、[RFC9499]で定義されているものなど、DNS固有の暗号化を実行するために定義された複数のメカニズムがありましたが、これは該当するDNSトラフィックにより適切にスコープされます。これらは、ネットワーク指定リゾルバー[RFC9463]の発見を使用して、ネットワークによる暗号化されたDNS広告とも互換性があり、DNS64サーバーが暗号化メカニズムをサポートしていることをクライアントが事前に知ることができます。
The other example given by [RFC7050] that would allow a communication channel with a DNS64 server to qualify as a "secure channel" is the use of a "link layer utilizing data encryption technologies". As of the time of this writing, most common link layer implementations use data encryption already with no extra effort needed on the part of network nodes. While this appears to be a trivial way to satisfy this requirement, it also renders the requirement meaningless since any node along the path can still read the higher-layer DNS traffic containing the translation prefix. This seems to be at odds with the definition of "secure channel", as explained in Section 2.2 of [RFC7050].
[RFC7050]で与えられたもう1つの例は、DNS64サーバーを使用した通信チャネルが「セキュアチャネル」として適格になることを可能にします。この執筆時点では、最も一般的なリンクレイヤーの実装は、ネットワークノードの部分に余分な労力を必要としないデータ暗号化を既に使用しています。これはこの要件を満たすための些細な方法であるように見えますが、パスに沿ったノードは、翻訳プレフィックスを含む高層DNSトラフィックを読み取ることができるため、要件を無意味にします。これは、[RFC7050]のセクション2.2で説明されているように、「安全なチャネル」の定義と対立しているようです。
Obtaining PREF64 information using RAs improves the overall security of an IPv6-only endpoint as it mitigates all attack vectors related to a spoofed or rogue DNS response, as discussed in Section 7 of [RFC7050]. Security considerations related to obtaining PREF64 information from RAs are discussed in Section 7 of [RFC8781].
RASを使用してPref64情報を取得すると、[RFC7050]のセクション7で説明したように、スプーフィングまたは不正なDNS応答に関連するすべての攻撃ベクトルを軽減するため、IPv6のみのエンドポイントの全体的なセキュリティが向上します。RASからPREF64情報の取得に関連するセキュリティ上の考慮事項については、[RFC8781]のセクション7で説明します。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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>.
[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>.
[RFC8781] Colitti, L. and J. Linkova, "Discovering PREF64 in Router
Advertisements", RFC 8781, DOI 10.17487/RFC8781, April
2020, <https://www.rfc-editor.org/info/rfc8781>.
[CLAT] Colitti, L., Linkova, J., and T. Jensen, "464XLAT
Customer-side Translator (CLAT): Node Recommendations",
Work in Progress, Internet-Draft, draft-ietf-v6ops-claton-
08, 17 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
claton-08>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[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>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC6105, February 2011,
<https://www.rfc-editor.org/info/rfc6105>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC8880] Cheshire, S. and D. Schinazi, "Special Use Domain Name
'ipv4only.arpa'", RFC 8880, DOI 10.17487/RFC8880, August
2020, <https://www.rfc-editor.org/info/rfc8880>.
[RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
and T. Jensen, "DHCP and Router Advertisement Options for
the Discovery of Network-designated Resolvers (DNR)",
RFC 9463, DOI 10.17487/RFC9463, November 2023,
<https://www.rfc-editor.org/info/rfc9463>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
The authors would like to thank the following people for their valuable contributions: Mike Bishop, Mohamed Boucadair, Lorenzo Colitti, Tom Costello, Charles Eckel, Susan Hares, Nick Heatley, Ted Lemon, Gábor Lencse, David Lou, Peter Schmitt, Éric Vyncke, and Chongfeng Xie.
著者は、マイク・ビショップ、モハメド・ブーカデア、ロレンツォ・コリッティ、トム・コステロ、チャールズ・エッケル、スーザン・ハレス、ニック・ヒートリー、テッド・レモン、ガーバー・レンセ、デビッド・ルー、ピーター・シュミット、エリック・ヴィンケ、チョンフェンXie。
Nick Buraglio
Energy Sciences Network
Email: buraglio@forwardingplane.net
Tommy Jensen
Email: tojens.ietf@gmail.com
Jen Linkova
Google
Email: furry13@gmail.com