[要約] RFC 6889は、Stateful 64 Translationの分析に関するものであり、IPv6とIPv4の相互運用性を向上させるための新しいトランスレーション技術を評価しています。目的は、IPv6ネットワークでIPv4トラフィックを処理するための効果的な手法を提供することです。
Internet Engineering Task Force (IETF) R. Penno
Request for Comments: 6889 Cisco Systems, Inc.
Category: Informational T. Saxena
ISSN: 2070-1721 Cisco Systems
M. Boucadair
France Telecom
S. Sivakumar
Cisco Systems
April 2013
Analysis of Stateful 64 Translation
ステートフル64変換の分析
Abstract
概要
Due to specific problems, Network Address Translation - Protocol Translation (NAT-PT) was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT.
特定の問題により、ネットワークアドレス変換-プロトコル変換（NAT-PT）は、IPv6-IPv4変換を実行するメカニズムとしてIETFによって廃止されました。それ以来、IETF内でIPv6-IPv4変換を実行する代替メカニズムを標準化するための新しい取り組みが行われています。このドキュメントでは、新しいステートフル変換メカニズムによって、IETFがNAT-PTを廃止する原因となった問題をどの程度回避できるかを分析します。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc6889.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6889で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Context . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Analysis of 64 Translation against Concerns of RFC 4966 . . . 4
2.1. Problems Impossible to Solve . . . . . . . . . . . . . . . 4
2.2. Problems That Can Be Solved . . . . . . . . . . . . . . . 5
2.3. Problems Solved . . . . . . . . . . . . . . . . . . . . . 7
3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 13
This document uses stateful 64 (or 64 for short) to refer to the mechanisms defined in the following documents:
このドキュメントでは、ステートフル64（または略して64）を使用して、次のドキュメントで定義されているメカニズムを参照しています。
o IP/ICMP Translation Algorithm [RFC6145]
o IP / ICMP変換アルゴリズム[RFC6145]
o Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [RFC6146]
o ステートフルNAT64：IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル変換[RFC6146]
o DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [RFC6147]
o DNS64：IPv6クライアントからIPv4サーバーへのネットワークアドレス変換のためのDNS拡張[RFC6147]
o IPv6 Addressing of IPv4/IPv6 Translators [RFC6052]
o IPv4 / IPv6トランスレータのIPv6アドレッシング[RFC6052]
o Framework for IPv4/IPv6 Translation [RFC6144]
o IPv4 / IPv6変換のフレームワーク[RFC6144]
Stateful 64 is widely seen as a major interconnection technique designed to enable communications between IPv6-only and IPv4-only networks. One of the building blocks of the stateful 64 is decoupling the DNS functionality from the protocol translation itself.
ステートフル64は、IPv6のみのネットワークとIPv4のみのネットワーク間の通信を可能にするように設計された主要な相互接続技術として広く見られています。ステートフル64のビルディングブロックの1つは、DNS機能をプロトコル変換自体から分離することです。
This approach is pragmatic in the sense that there is no dependency on DNS implementation for the successful NAT handling. As long as there is a function (e.g., DNS64 [RFC6147] or other means) that can construct an IPv6-embedded IPv4 address with a pre-configured IPv6 prefix, an IPv4 address and a suffix (refer to [RFC6052]), NAT64 will work just fine.
このアプローチは、NAT処理を成功させるためにDNS実装に依存しないという意味で実用的です。事前構成されたIPv6プレフィックス、IPv4アドレスおよびサフィックス（[RFC6052]を参照）を使用してIPv6埋め込みIPv4アドレスを構築できる機能（DNS64 [RFC6147]またはその他の手段）がある限り、NAT64うまくいきます。
The focus of the stateful 64 is on the deployment and not the implementation details. As long as a NAT64 implementation conforms to the expected behavior, as desired in the deployment scenario, the details are not very important as mentioned in this excerpt from [RFC6146]:
ステートフル64の焦点はデプロイメントであり、実装の詳細ではありません。 [RFC6146]からのこの抜粋で言及されているように、NAT64の実装が期待される動作に準拠している限り、展開シナリオで必要とされている限り、詳細はそれほど重要ではありません。
A NAT64 MAY perform the steps in a different order, or MAY perform different steps, but the externally visible outcome MUST be the same as the one described in this document.
NAT64は異なる順序でステップを実行してもよい（MAY）、または異なるステップを実行してもよい（MAY）が、外部から見える結果は、このドキュメントで説明されているものと同じである必要があります。
This document provides an analysis of how the proposed set of documents that specify stateful IPv6-only to IPv4-only translation and replace Network Address Translation - Protocol Translation (NAT-PT) [RFC2766] address the issues raised in [RFC4966].
このドキュメントは、ステートフルIPv6-onlyからIPv4-onlyへの変換を指定し、ネットワークアドレス変換-プロトコル変換（NAT-PT）[RFC2766]を置き換える提案された一連のドキュメントが[RFC4966]で提起された問題にどのように対処するかを分析します。
As a reminder, it is worth mentioning the analysis is limited in the sense that hosts from IPv6 networks can initiate a communication to IPv4 network/Internet, but not vice versa. This corresponds to Scenarios 1 and 5 described in [RFC6144]. Hence, the scenario of servers moving to IPv6 while clients remaining IPv4 remains unaddressed. Of course, IPv6-to-IPv4 communications can also be supported if static or explicit bindings (e.g., [RFC6887]) are configured on the stateful NAT64.
注意として、IPv6ネットワークのホストがIPv4ネットワーク/インターネットへの通信を開始できるが、その逆はできないという意味で、分析が制限されていることに言及する価値があります。これは、[RFC6144]で説明されているシナリオ1および5に対応します。したがって、クライアントがIPv4のままでサーバーがIPv6に移行するシナリオは、アドレス指定されないままです。もちろん、静的または明示的なバインディング（[RFC6887]など）がステートフルNAT64で構成されている場合は、IPv6-to-IPv4通信もサポートできます。
Stateful 64, just like any other technique under development, has some positives and some drawbacks. The ups and downs of the proposal must be clearly understood while going forward with its future development.
ステートフル64は、開発中の他のテクニックと同様に、いくつかの利点と欠点があります。提案の浮き沈みは、その将来の発展を進める間、明確に理解されなければなりません。
The scope of this document does not include stateless translation.
このドキュメントの範囲には、ステートレス翻訳は含まれていません。
Of the set of problems pointed out in [RFC4966], the stateful 64 addresses some of them, whereas it leaves others unaddressed.
[RFC4966]で指摘された一連の問題のうち、ステートフル64はそれらのいくつかに対処しますが、他の問題には対処しません。
Some issues mentioned in [RFC4966] were solved by [RFC4787], [RFC5382], and [RFC5508]. At the time when NAT-PT was published, these recommendations were not in place but they are orthogonal to the translation algorithm per se; therefore, they could be implemented with NAT-PT. On the other hand, NAT64 [RFC6146] explicitly mentions that these recommendations need to be followed and thus should be seen as a complete specification.
[RFC4966]で言及されているいくつかの問題は、[RFC4787]、[RFC5382]、および[RFC5508]によって解決されました。 NAT-PTが公開された時点では、これらの推奨事項は実施されていませんでしたが、変換アルゴリズム自体に直交しています。したがって、NAT-PTで実装できます。一方、NAT64 [RFC6146]は、これらの推奨事項に従う必要があるため、完全な仕様と見なす必要があることを明示的に述べています。
It is also worth pointing out that the scope of the stateful 64 is reduced when compared to NAT-PT. Following is a point-by-point analysis of the problems. This document classifies the issues listed in [RFC4966] into three categories:
NAT-PTと比較すると、ステートフル64のスコープが減少していることも指摘する価値があります。以下は、問題のポイントごとの分析です。このドキュメントでは、[RFC4966]に記載されている問題を3つのカテゴリに分類しています。
1. Problems impossible to solve.
1. 解決できない問題。
2. Problems that can be solved.
2. 解決できる問題。
3. Problems solved.
3. 問題は解決しました。
Problems discussed in [RFC4966] that are impossible to solve:
[RFC4966]で説明されている解決できない問題：
1. Inability to redirect traffic for protocols that lack de-multiplexing capabilities or are not built on top of specific transport-layer protocols for transport address translations (Section 2.2 of [RFC4966]).
1. 逆多重化機能がないか、トランスポートアドレス変換用の特定のトランスポート層プロトコルの上に構築されていないプロトコルのトラフィックをリダイレクトできない（[RFC4966]のセクション2.2）。
Analysis: This issue is not specific to 64 but to all NAT-based solutions.
分析：この問題は64に固有ではなく、すべてのNATベースのソリューションに固有です。
2. Loss of information due to incompatible semantics between IPv4 and IPv6 versions of headers and protocols (Section 2.4 of [RFC4966]).
2. ヘッダーとプロトコルのIPv4バージョンとIPv6バージョンの間の互換性のないセマンティクスによる情報の損失（[RFC4966]のセクション2.4）。
Analysis: This issue is not specific to 64 but is due to the design of IPv4 and IPv6.
分析：この問題は64に固有のものではなく、IPv4とIPv6の設計によるものです。
3. Need for the NAT64-capable device to act as proxy for correspondent node when IPv6 node is mobile, with consequent restrictions on mobility (Section 2.7 of [RFC4966]).
3. IPv6ノードがモバイルの場合、NAT64対応デバイスがコレスポンデントノードのプロキシとして機能する必要があり、その結果、モビリティが制限されます（[RFC4966]のセクション2.7）。
Analysis: This is not specific to NAT64 but to all NAT flavors. Refer to [NAT64-HARMFUL] for an early analysis on mobility complications encountered when NAT64 is involved.
分析：これはNAT64に固有ではなく、すべてのNATフレーバーに固有です。 NAT64が関与しているときに遭遇する可動性合併症の早期分析については、[NAT64-HARMFUL]を参照してください。
Problems discussed in [RFC4966] that can be solved:
[RFC4966]で説明されている解決可能な問題：
1. Disruption of all protocols that embed IP addresses (and/or ports) in packet payloads or apply integrity mechanisms using IP addresses (and ports) (Section 2.1 of [RFC4966]).
1. パケットペイロードにIPアドレス（またはポート）を埋め込む、またはIPアドレス（およびポート）を使用して整合性メカニズムを適用するすべてのプロトコルの中断（[RFC4966]のセクション2.1）。
Analysis: In the case of FTP [RFC0959], this problem can be mitigated in several ways (e.g., use a FTP64 Application Layer Gateway (ALG) [RFC6384] or in the FTP client (e.g., [FTP64])).
分析：FTP [RFC0959]の場合、この問題はいくつかの方法で軽減できます（たとえば、FTP64アプリケーションレイヤーゲートウェイ（ALG）[RFC6384]を使用するか、FTPクライアント（[FTP64]など）で）。
In the case of SIP [RFC3261], no specific issue is induced by 64; the same techniques for NAT traversal can be used when a NAT64 is involved in the path (e.g., Interactive Connectivity Establishment (ICE) [RFC5245], maintain SIP-related NAT bindings as per Section 3.4 of [RFC5853], media latching [MIDDLEBOXES], embedded SIP ALGs, etc.). [RFC6157] provides more discussion on how to establish SIP sessions between IPv4 and IPv6 SIP user agents.
SIP [RFC3261]の場合、64によって特定の問題が発生することはありません。 NAT64がパスに含まれている場合、NATトラバーサルと同じ手法を使用できます（たとえば、Interactive Connectivity Establishment（ICE）[RFC5245]、[RFC5853]のセクション3.4に従ってSIP関連のNATバインディングを維持し、メディアラッチ[MIDDLEBOXES] 、組み込みSIP ALGなど）。 [RFC6157]では、IPv4とIPv6のSIPユーザーエージェント間でSIPセッションを確立する方法について詳しく説明しています。
The functioning of other protocols is left for future study. Note that the traversal of NAT64 by application embedding IP address literal is not specific to NAT64 but generic to all NAT-based solutions.
他のプロトコルの機能は将来の研究に残されています。アプリケーション埋め込みIPアドレスリテラルによるNAT64のトラバーサルは、NAT64に固有のものではなく、すべてのNATベースのソリューションに一般的であることに注意してください。
2. Interaction with Stream Control Transmission Protocol (SCTP) [RFC4960] and multihoming (Section 2.6 of [RFC4966]).
2. Stream Control Transmission Protocol（SCTP）との相互作用[RFC4960]およびマルチホーミング（[RFC4966]のセクション2.6）。
Analysis: Only TCP and UDP transport protocols are within the scope of NAT64 [RFC6146]. SCTP is out of scope of this document.
分析：TCPおよびUDPトランスポートプロトコルのみがNAT64 [RFC6146]のスコープ内にあります。 SCTPはこのドキュメントの範囲外です。
3. Inability to handle multicast traffic (Section 2.8 of [RFC4966]).
3. マルチキャストトラフィックを処理できない（[RFC4966]のセクション2.8）。
Analysis: This problem is not addressed by the current 64 specifications.
分析：この問題は、現在の64仕様では対処されていません。
4. Scalability concerns together with introduction of a single point of failure and a security attack nexus (Section 3.2 of [RFC4966]).
4. スケーラビリティの懸念、および単一障害点の導入とセキュリティ攻撃のネクサス（[RFC4966]のセクション3.2）。
Analysis: This is not specific to NAT64 but to all stateful NAT flavors. The presence of a single point of failure is deployment-specific; some service providers may deploy state synchronization means while others may only rely on a distributed NAT64 model.
分析：これはNAT64に固有ではなく、すべてのステートフルNATフレーバーに固有です。単一障害点の存在はデプロイメント固有です。一部のサービスプロバイダーは、状態同期手段を展開する場合がありますが、他のサービスプロバイダーは、分散NAT64モデルのみに依存する場合があります。
5. Restricted validity of translated DNS records: a translated record may be forwarded to an application that cannot use it (Section 4.2 of [RFC4966]).
5. 変換されたDNSレコードの有効性の制限：変換されたレコードは、それを使用できないアプリケーションに転送される場合があります（[RFC4966]のセクション4.2）。
Analysis: If a node on the IPv4 side forwards the address of the other endpoint to a node that cannot reach the NAT box or is not covered under the endpoint-independent constraint of NAT, then the new node will not be able to initiate a successful session.
分析：IPv4側のノードが、他のエンドポイントのアドレスを、NATボックスに到達できないノードに転送するか、NATのエンドポイントに依存しない制約でカバーされていない場合、新しいノードは正常に開始できませんセッション。
Actually, this is not a limitation of 64 (or even NAT-PT) but a deployment context where IPv4 addresses managed by the NAT64 are not globally reachable. The same limitation can be encountered when referrals (even without any NAT in the path) include reachability information with limited reachability scope (see [REFERRAL] for more discussion about issues related to reachability scope).
実際、これは64（またはNAT-PT）の制限ではなく、NAT64によって管理されるIPv4アドレスにグローバルに到達できない展開コンテキストです。参照に（パスにNATがなくても）到達可能性の範囲が制限された到達可能性情報が含まれている場合にも、同じ制限が発生する可能性があります（到達可能性の範囲に関連する問題の詳細については、[参照]を参照）。
6. IPsec traffic using AH (Authentication Header) [RFC4302] in both transport and tunnel modes cannot be carried through NAT-PT without terminating the security associations on the NAT-PT, due to the inclusion of IP header fields in the scope of AH's cryptographic integrity protection [RFC3715] (Section 2.1 of [RFC4966]). In addition, IPsec traffic using ESP (Encapsulating Security Payload) [RFC4303] in transport mode generally uses UDP encapsulation [RFC3948] for NAT traversal (including NAT-PT traversal) in order to avoid the problems described in [RFC3715] (Section 2.1 of [RFC4966]).
6. トランスポートモードとトンネルモードの両方でAH（認証ヘッダー）[RFC4302]を使用するIPsecトラフィックは、AHの暗号整合性のスコープにIPヘッダーフィールドが含まれているため、NAT-PTのセキュリティアソシエーションを終了しないと、NAT-PTを介して伝送できません。保護[RFC3715]（[RFC4966]のセクション2.1）。さらに、トランスポートモードでESP（Encapsulating Security Payload）[RFC4303]を使用するIPsecトラフィックは、[RFC3715]で説明されている問題（セクション2.1 [RFC4966]）。
Analysis: This is not specific to NAT64 but to all NAT flavors.
分析：これはNAT64に固有ではなく、すべてのNATフレーバーに固有です。
7. Address selection issues when either the internal or external hosts implement both IPv4 and IPv6 (Section 4.1 of [RFC4966]).
7. 内部ホストまたは外部ホストのいずれかがIPv4とIPv6の両方を実装する場合の選択の問題に対処します（[RFC4966]のセクション4.1）。
Analysis: This is out of scope of 64 since Scenarios 1 and 5 of [RFC6144] assume IPv6-only hosts.
分析：[RFC6144]のシナリオ1と5はIPv6のみのホストを想定しているため、これは64の範囲外です。
Therefore, this issue is not resolved and mitigation techniques outside the 64 need to be used (e.g., [ADDR-SELECT]). These techniques may allow one to offload NAT64 resources and prefer native communications that do not involve address family translation. Avoiding NAT devices in the path is encouraged for mobile nodes in order to save power consumption due to keepalive messages that are required to maintain NAT states ("always-on" services). An in-depth discussion can be found in [DNS64].
したがって、この問題は解決されず、64以外の軽減技術を使用する必要があります（[ADDR-SELECT]など）。これらの手法により、NAT64リソースをオフロードし、アドレスファミリ変換を含まないネイティブ通信を優先できます。 NAT状態を維持するために必要なキープアライブメッセージ（「常時オン」サービス）による電力消費を節約するために、モバイルノードではパス内のNATデバイスを回避することをお勧めします。詳細については、[DNS64]をご覧ください。
Problems identified in [RFC4966] that have been solved:
[RFC4966]で特定された解決済みの問題：
1. Constraints on network topology (as it relates to DNS-ALG; see Section 3.1 of [RFC4966]).
1. ネットワークトポロジの制約（DNS-ALGに関連するもの。[RFC4966]のセクション3.1を参照）。
Analysis: The severity of this issue has been mitigated by the separation of the DNS from the NAT functionality. Nevertheless, a minimal coordination may be required to ensure that the NAT64 to be crossed (the one to which the IPv4- Converted IPv6 address returned to a requesting host) must be in the path and has also sufficient resources to handle received traffic.
分析：この問題の深刻度は、NAT機能からDNSを分離することで緩和されました。それにもかかわらず、最小限の調整は、通過するNAT64（IPv4に変換されたIPv6アドレスが要求ホストに返されるアドレス）がパス内にあり、受信したトラフィックを処理するのに十分なリソースを持っていることを確認するために必要な場合があります。
2. Need for additional state and/or packet reconstruction in dealing with packet fragmentation. Otherwise, implement no support for fragments (Section 2.5 of [RFC4966]).
2. パケットの断片化に対処するには、追加の状態やパケットの再構成が必要です。それ以外の場合は、フラグメントのサポートを実装しません（[RFC4966]のセクション2.5）。
Analysis: This issue is not specific to 64 but to all NAT-based solutions. [RFC6146] specifies how to handle fragmentation; appropriate recommendations to avoid fragmentation-related DoS (Denial-of-Service) attacks are proposed (e.g., limit resources to be dedicated to out-of-order fragments).
分析：この問題は64に固有ではなく、すべてのNATベースのソリューションに固有です。 [RFC6146]は断片化を処理する方法を指定します。断片化関連のDoS（サービス拒否）攻撃を回避するための適切な推奨事項が提案されます（たとえば、リソースを順序が乱れたフラグメント専用にするように制限します）。
3. Inappropriate translation of responses to A queries from IPv6 nodes (Section 4.3 of [RFC4966]).
3. IPv6ノードからのAクエリに対する応答の不適切な変換（[RFC4966]のセクション4.3）。
Analysis: DNS64 [RFC6147] does not alter A queries.
分析：DNS64 [RFC6147]はAクエリを変更しません。
4. Address selection issues and resource consumption in a DNS-ALG with multi-addressed nodes (Section 4.4 of [RFC4966]).
4. 複数アドレスのノードを持つDNS-ALGでの選択の問題とリソース消費に対処します（[RFC4966]のセクション4.4）。
Analysis: Since no DNS-ALG is required to be co-located with NAT64, there is no need to maintain temporary states in anticipation of connections. Note that explicit bindings (see Section 3 of [RFC6887]) are required to allow for communications initiated from an IPv4-only client to an IPv6- only server.
分析：DNS-ALGをNAT64と同じ場所に配置する必要がないため、接続を見越して一時的な状態を維持する必要はありません。 IPv4のみのクライアントからIPv6のみのサーバーへの通信を可能にするには、明示的なバインディング（[RFC6887]のセクション3を参照）が必要であることに注意してください。
5. Limitations on DNS security capabilities when using a DNS-ALG (Section 2.5 of [RFC4966]).
5. DNS-ALGを使用する場合のDNSセキュリティ機能の制限（[RFC4966]のセクション2.5）。
Analysis: A DNSSEC validating stub resolver behind a DNS64 in server mode is not supported. Therefore, if a host wants to do its own DNSSEC validation, and it wants to use a NAT64, the host has to also perform its own DNS64 synthesis. Refer to Section 3 of [RFC6147] for more details.
分析：サーバーモードのDNS64の背後にあるDNSSEC検証スタブリゾルバーはサポートされていません。したがって、ホストが独自のDNSSEC検証を行い、NAT64を使用する場合、ホストは独自のDNS64合成も実行する必要があります。詳細については、[RFC6147]のセクション3を参照してください。
6. Creation of a DoS threat relating to exhaustion of memory and address/port pool resources on the translator (Section 3.4 of [RFC4966]).
6. トランスレータのメモリおよびアドレス/ポートプールリソースの枯渇に関連するDoS脅威の作成（[RFC4966]のセクション3.4）。
Analysis: This specific DoS concern on Page 6 of [RFC4966] is under a DNS-ALG heading in that document, and refers to NAT-PT's creation of NAT mapping state when a DNS query occurred. With the new IPv6-IPv4 translation mechanisms, DNS queries do not create any mapping state in the NAT64.
分析：[RFC4966]の6ページのこの特定のDoSの懸念は、そのドキュメントのDNS-ALG見出しの下にあり、DNSクエリが発生したときのNAT-PTによるNATマッピング状態の作成を指します。新しいIPv6-IPv4変換メカニズムでは、DNSクエリはNAT64でマッピング状態を作成しません。
To mitigate the exhaustion of port pool issue (Section 3.4 of [RFC4966]), 64 must enforce a port limit similar to the one defined in [RFC6888].
ポートプールの問題の枯渇を緩和するには（[RFC4966]のセクション3.4）、64は[RFC6888]で定義されているものと同様のポート制限を適用する必要があります。
Thus, this concern can be fully eliminated in 64.
したがって、この問題は64で完全に排除できます。
7. Requirement for applications to use keepalive mechanisms to work around connectivity issues caused by premature timeout for session table and Binding Information Base entries (Section 2.3 of [RFC4966]).
7. アプリケーションがキープアライブメカニズムを使用して、セッションテーブルとバインディング情報ベースエントリの早期タイムアウトによって引き起こされる接続の問題を回避するための要件（[RFC4966]のセクション2.3）。
Analysis: Since NAT64 follows some of the [RFC4787], [RFC5382], and [RFC5508] requirements, there is a high lower bound for the lifetime of sessions. In NAT-PT, this was unknown and applications needed to assume the worst case. For instance, in NAT64, the lifetime for a TCP session is approximately two hours, so not much keepalive signaling overhead is needed.
分析：NAT64は[RFC4787]、[RFC5382]、および[RFC5508]の要件の一部に準拠しているため、セッションのライフタイムには高い下限があります。 NAT-PTでは、これは不明であり、アプリケーションは最悪のケースを想定する必要がありました。たとえば、NAT64では、TCPセッションのライフタイムは約2時間なので、キープアライブシグナリングのオーバーヘッドはそれほど必要ありません。
Application clients (e.g., VPN clients) are not aware of the timer configured in the NAT device. For unmanaged services, a conservative approach would be adopted by applications that issue frequent keepalive messages to be sure that an active mapping is still maintained by any involved NAT64 device even if the NAT64 complies with [RFC4787], [RFC5382], and [RFC5508].
アプリケーションクライアント（VPNクライアントなど）は、NATデバイスで構成されたタイマーを認識しません。アンマネージドサービスの場合、頻繁にキープアライブメッセージを発行するアプリケーションでは、NAT64が[RFC4787]、[RFC5382]、および[RFC5508]に準拠している場合でも、関連するNAT64デバイスによってアクティブマッピングが維持されるように、保守的なアプローチが採用されます。 。
Note that keepalive messages may be issued by applications to ensure that an active entry is maintained by a firewall, with or without a NAT in the path, which is located in the boundaries of a local domain.
アプリケーションがキープアライブメッセージを発行して、ローカルドメインの境界にあるパスにNATの有無にかかわらず、ファイアウォールによってアクティブエントリが維持されるようにすることができます。
8. Lack of address mapping persistence: Some applications require address retention between sessions. The user traffic will be disrupted if a different mapping is used. The use of the DNS-ALG to create address mappings with limited lifetimes means that applications must start using the address shortly after the mapping is created, as well as keep it alive once they start using it (Section 3.3 of [RFC4966]).
8. アドレスマッピングの永続性の欠如：一部のアプリケーションでは、セッション間でアドレスを保持する必要があります。別のマッピングを使用すると、ユーザートラフィックが中断されます。 DNS-ALGを使用して、有効期間が限定されたアドレスマッピングを作成するということは、アプリケーションは、マッピングの作成後すぐにアドレスの使用を開始し、使用を開始したらそのまま維持する必要があることを意味します（[RFC4966]のセクション3.3）。
Analysis: In the following, address persistence is used to refer to the support of "IP address pooling" behavior of "Paired" [RFC4787].
分析：以下では、アドレスの永続性は、「ペア」の[IPアドレスプーリング]動作のサポートを参照するために使用されます[RFC4787]。
In the context of 64, the external IPv4 address (representing the IPv6 host in the IPv4 network) is assigned by the NAT64 machinery and not the DNS64 function. Therefore, address persistence can be easily ensured by the NAT64 function (which complies with NAT recommendations [RFC4787] and [RFC5382]). Address persistence should be guaranteed for both dynamic and static bindings.
64のコンテキストでは、外部IPv4アドレス（IPv4ネットワークのIPv6ホストを表す）は、DNS64機能ではなくNAT64機構によって割り当てられます。したがって、NAT64機能（NAT勧告[RFC4787]および[RFC5382]に準拠）によって、アドレスの永続性を簡単に確保できます。アドレスの永続性は、動的バインディングと静的バインディングの両方で保証される必要があります。
In the IPv6 side of the NAT64, the same IPv6 address is used to represent an IPv4 host; no issue about address persistence is raised in an IPv6 network.
NAT64のIPv6側では、同じIPv6アドレスがIPv4ホストを表すために使用されます。 IPv6ネットワークでは、アドレスの永続性に関する問題は発生しません。
The above analysis of the solutions provided by the stateful 64 shows that the majority of the problems that are not directly related to the decoupling of NAT and DNS remain unaddressed. Some of these problems are not specific to 64 but are generic to all NAT-based solutions.
ステートフル64によって提供されるソリューションの上記の分析は、NATとDNSの分離に直接関連しない問題の大部分が対処されていないことを示しています。これらの問題の一部は64に固有のものではありませんが、すべてのNATベースのソリューションに共通しています。
This points to several shortcomings of stateful 64 that must be addressed if the future network deployments have to move reliably towards 64 as a solution to IPv6-IPv4 interconnection.
これは、将来のネットワーク展開がIPv6-IPv4相互接続のソリューションとして64に確実に移行する必要がある場合に対処する必要があるステートフル64のいくつかの欠点を示しています。
Some of the issues, as pointed out in [RFC4966], have possible solutions. However these solutions will require significant updates to the stateful 64, increasing its complexity.
[RFC4966]で指摘されているように、いくつかの問題には可能な解決策があります。ただし、これらのソリューションでは、ステートフル64を大幅に更新する必要があり、その複雑さが増します。
The following table summarizes the conclusions based on the analysis of stateful 64.
次の表は、ステートフル64の分析に基づく結論をまとめたものです。
+---------------+----------+---------+----------+---------+---------+
| Issue | NAT-PT | Exists | DNS ALG | Generic | Can be |
| | Specific | in | Specific | NAT | solved? |
| | | NAT64 | | | |
+---------------+----------+---------+----------+---------+---------+
| Protocols | No | Yes | No | Yes | Yes |
| embedding | | | | | |
| addresses | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Protocols | No | Yes | No | Yes | No |
| without demux | | | | | |
| capability | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Binding state | No | Yes | No | Yes | Yes |
| decay | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Loss of | No | Yes | No | No | No |
| information | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Fragmentation | No | No | No | Yes | Yes |
+---------------+----------+---------+----------+---------+---------+
| SCTP and | No | Yes | No | Yes | Yes |
| Multihoming | | | | | |
| interaction | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Proxy | No | Yes | No | No | No |
| correspondent | | | | | |
| node for | | | | | |
| MIPv6 | | | | | |
| Multicast | No | Yes | No | Yes | Yes |
+---------------+----------+---------+----------+---------+---------+
| IPsec tunnel | No | Yes | No | Yes | Yes |
| mode | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Topology | Yes | No | Yes | No | Yes |
| constraints | | | | | |
| with DNS-ALG | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Scale and | No | Yes | No | Yes | Yes |
| Single point | | | | | |
| of failure | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Lack of | No | Yes | No | Yes | Yes |
| address | | | | | |
| persistence | | | | | |
+---------------+----------+---------+----------+---------+---------+
| DoS attacks | No | Yes | No | Yes | Yes |
+---------------+----------+---------+----------+---------+---------+
| Address | Yes | No | Yes | No | Yes |
| selection | | | | | |
| issues with | | | | | |
| Dual stack | | | | | |
| hosts | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Non-global | Yes | No | Yes | No | Yes |
| validity of | | | | | |
| Translated RR | | | | | |
| records | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Incorrect | Yes | No | Yes | No | Yes |
| translation | | | | | |
| of A | | | | | |
| responses | | | | | |
+---------------+----------+---------+----------+---------+---------+
| DNS-ALG and | No | Yes | No | Yes | Yes |
| Multi- | | | | | |
| addressed | | | | | |
| nodes | | | | | |
+---------------+----------+---------+----------+---------+---------+
| DNSSEC | No | Yes | No | Yes | Yes |
| limitations | | | | | |
+---------------+----------+---------+----------+---------+---------+
Table 1: Summary of NAT64 analysis
表1：NAT64分析の概要
This document does not specify any new protocol or architecture. It only analyzes how BEHAVE WG 64 documents mitigate concerns raised in [RFC4966] and which ones are still unaddressed.
このドキュメントでは、新しいプロトコルやアーキテクチャを指定していません。 BEHAVE WG 64の文書が[RFC4966]で提起された懸念を軽減する方法と、まだ対処されていない問題を分析するだけです。
Many thanks to M. Bagnulo, D. Wing, X. Li, D. Anipko, and S. Moonesamy for their review and comments.
M. Bagnulo、D。Wing、X。Li、D。Anipko、およびS. Moonesamyのレビューとコメントに感謝します。
D. Black provided the IPsec text.
D.黒はIPsecテキストを提供しました。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、Volpe、V.、DiBurro、L。、およびM. Stenberg、「IPsec ESPパケットのUDPカプセル化」、RFC 3948、2005年1月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]オーデットF.およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、2007年1月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.
[RFC4966] Aoun、C。およびE. Davies、「ネットワークアドレストランスレータ-プロトコルトランスレータ（NAT-PT）を歴史的なステータスに移行する理由」、RFC 4966、2007年7月。
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382] Guha、S.、Biswas、K.、Ford、B.、Sivakumar、S。、およびP. Srisuresh、「NAT Behavioral Requirements for TCP」、BCP 142、RFC 5382、2008年10月。
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.
[RFC5508] Srisuresh、P.、Ford、B.、Sivakumar、S。、およびS. Guha、「NAT Behavioral Requirements for ICMP」、BCP 148、RFC 5508、2009年4月。
[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月。
[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月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145] Li、X.、Bao、C。、およびF. Baker、「IP / ICMP変換アルゴリズム」、RFC 6145、2011年4月。
[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」、RFC 6147、2011年4月。
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[RFC6887] Wing、D.、Ed。、Cheshire、S.、Boucadair、M.、Penno、R.、and P. Selkirk、 "Port Control Protocol（PCP）"、RFC 6887、April 2013。
[ADDR-SELECT] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing Address Selection Policy using DHCPv6", Work in Progress, April 2013.
[ADDR-SELECT]マツモトA.、藤崎T.、およびT. Chown、「DHCPv6を使用したアドレス選択ポリシーの配布」、作業中、2013年4月。
[DNS64] Wing, D., "IPv6-only and Dual Stack Hosts on the Same Network with DNS64", Work in Progress, February 2011.
[DNS64] Wing、D。、「DNS64を使用した同じネットワーク上のIPv6のみのホストとデュアルスタックホスト」、作業中、2011年2月。
[FTP64] Liu, D., Beijnum, I., and Z. Cao, "FTP consideration for IPv4/IPv6 transition", Work in Progress, January 2012.
[FTP64] Liu、D.、Beijnum、I。、およびZ. Cao、「IPv4 / IPv6移行のためのFTPの考慮事項」、作業中、2012年1月。
[MIDDLEBOXES] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Work in Progress, January 2013.
[MIDDLEBOXES] Stucker、B.、Tschofenig、H。、およびG. Salgueiro、「Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path」、作業中、2013年1月。
[NAT64-HARMFUL] Haddad, W. and C. Perkins, "A Note on NAT64 Interaction with Mobile IPv6", Work in Progress, March 2011.
[NAT64-HARMFUL] Haddad、W。およびC. Perkins、「NAT64とモバイルIPv6との相互作用に関するノート」、進行中の作業、2011年3月。
[REFERRAL] Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and K. Moore, "A Generic Referral Object for Internet Entities", Work in Progress, October 2009.
[参照] Carpenter、B.、Boucadair、M.、Halpern、J.、Jiang、S。、およびK. Moore、「インターネットエンティティの一般的な参照オブジェクト」、作業中、2009年10月。
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2766] Tsirtsis、G。およびP. Srisuresh、「ネットワークアドレス変換-プロトコル変換（NAT-PT）」、RFC 2766、2000年2月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] Aboba、B。およびW. Dixon、「IPsecネットワークアドレス変換（NAT）互換性要件」、RFC 3715、2004年3月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、2010年4月。
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
[RFC5853] Hautakorpi、J.、Camarillo、G.、Penfield、R.、Hawrylyshen、A。、およびM. Bhatia、「Session Initiation Protocol（SIP）Session Border Control（SBC）Deployments from Requirements」、RFC 5853、4月2010。
[RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", RFC 6157, April 2011.
[RFC6157] Camarillo、G.、El Malki、K。、およびV. Gurbani、「IPv6 Transition in the Session Initiation Protocol（SIP）」、RFC 6157、2011年4月。
[RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation", RFC 6384, October 2011.
[RFC6384] van Beijnum、I。、「IPv6-to-IPv4変換用のFTPアプリケーション層ゲートウェイ（ALG）」、RFC 6384、2011年10月。
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013.
[RFC6888] Perreault、S.、Ed。、Yamagata、I.、Miyakawa、S.、Nakagawa、A.、and H. Ashida、 "Common Requirements for Carrier-Grade NATs（CGNs）"、BCP 127、RFC 6888、 2013年4月。
Authors' Addresses
著者のアドレス
Reinaldo Penno Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134 USA
Reinaldo Penno Cisco Systems、Inc. 170 West Tasman Drive San Jose、California 95134 USA
EMail: repenno@cisco.com
Tarun Saxena Cisco Systems Cessna Business Park Bangalore 560103 India
Tarun Saxena Cisco Systems Cessna Business Parkバンガロール560103インド
EMail: tasaxena@cisco.com
Mohamed Boucadair France Telecom Rennes 35000 France
Mohamed Boucadair France Telecom Rennes 35000 France
EMail: mohamed.boucadair@orange.com
Senthil Sivakumar Cisco Systems 7100-8 Kit Creek Road Research Triangle Park, North Carolina 27709 USA
Senthil Sivakumar Cisco Systems 7100-8 Kit Creek Road Research Triangle Park、North Carolina 27709 USA
EMail: ssenthil@cisco.com