[要約] このRFCは、NAT64の展開オプションと経験に関する情報を提供することを目的としています。要約すると、NAT64の展開に関する実際の選択肢と経験についてのガイドラインを提供しています。
Internet Engineering Task Force (IETF) G. Chen
Request for Comments: 7269 Z. Cao
Category: Informational China Mobile
ISSN: 2070-1721 C. Xie
China Telecom
D. Binet
France Telecom-Orange
June 2014
NAT64 Deployment Options and Experience
NAT64の展開オプションとエクスペリエンス
Abstract
概要
This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier-Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document.
このドキュメントでは、NAT64関数の展開シナリオと運用経験をまとめています。このドキュメントでは、NAT64キャリアグレードNAT（NAT64-CGN）とNAT64サーバーフロントエンド（NAT64-FE）の両方が考慮されます。
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/rfc7269.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7269で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. NAT64 Networking Experience . . . . . . . . . . . . . . . . . 4
3.1. NAT64-CGN Consideration . . . . . . . . . . . . . . . . . 4
3.1.1. NAT64-CGN Usages . . . . . . . . . . . . . . . . . . 4
3.1.2. DNS64 Deployment . . . . . . . . . . . . . . . . . . 4
3.1.3. NAT64 Placement . . . . . . . . . . . . . . . . . . . 5
3.1.4. Coexistence of NAT64 and NAT44 . . . . . . . . . . . 5
3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 6
4. High Availability . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7
4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9
5. Source-Address Transparency . . . . . . . . . . . . . . . . . 9
5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Geolocation . . . . . . . . . . . . . . . . . . . . . . . 10
6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11
6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11
6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 13
7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Test Results for Application Behavior . . . . . . . 21
IPv6 is the only sustainable solution for numbering nodes on the Internet due to the IPv4 depletion. Network operators have to deploy IPv6-only networks in order to meet the needs of the expanding Internet without available IPv4 addresses.
IPv4の枯渇により、IPv6はインターネット上のノードに番号を付けるための唯一の持続可能なソリューションです。ネットワーク事業者は、利用可能なIPv4アドレスなしで拡大するインターネットのニーズを満たすために、IPv6のみのネットワークを展開する必要があります。
Single-stack IPv6 network deployment can simplify network provisioning; some justification was provided in 464XLAT [RFC6877]. IPv6-only connectivity confers some benefits to mobile operators as an example. In the mobile context, IPv6-only usage enables the use of a single IPv6 Packet Data Protocol (PDP) context or Evolved Packet System (EPS) bearer on Long Term Evolution (LTE) networks. This eliminates significant network costs (caused by employing two PDP contexts in some cases) and the need for IPv4 addresses to be assigned to customers. In broadband networks overall, it can allow for the scaling of edge-network growth to be decoupled from IPv4 numbering limitations.
シングルスタックIPv6ネットワーク配備は、ネットワークのプロビジョニングを簡素化できます。一部の正当化は464XLAT [RFC6877]で提供されました。 IPv6のみの接続は、例としてモバイルオペレーターにいくつかの利点をもたらします。モバイルコンテキストでは、IPv6のみの使用により、単一のIPv6パケットデータプロトコル（PDP）コンテキストまたはLong Term Evolution（LTE）ネットワークでのEvolved Packet System（EPS）ベアラーの使用が可能になります。これにより、重要なネットワークコスト（場合によっては2つのPDPコンテキストを使用することにより発生）およびIPv4アドレスを顧客に割り当てる必要がなくなります。ブロードバンドネットワーク全体では、エッジネットワークの成長のスケーリングをIPv4番号の制限から切り離すことができます。
In transition scenarios, some existing networks are likely to be IPv4 only for quite a long time. IPv6 networks and IPv6-only hosts will need to coexist with IPv4 numbered resources. Widespread dual-stack deployments have not materialized at the anticipated rate over the last 10 years, one possible conclusion being that legacy networks will not make the jump quickly. The Internet will include nodes that are dual stack, nodes that remain IPv4 only, and nodes that can be deployed as IPv6-only nodes. A translation mechanism based on a NAT64 function [RFC6145] [RFC6146] is likely to be a key element of Internet connectivity for IPv6-IPv4 interoperability.
移行シナリオでは、一部の既存のネットワークはかなり長い間IPv4でしかありません。 IPv6ネットワークとIPv6のみのホストは、IPv4番号付きリソースと共存する必要があります。過去10年間、広範囲のデュアルスタック展開が予想される速度で実現していないため、レガシーネットワークではすぐに効果が出ないという結論が出ました。インターネットには、デュアルスタックのノード、IPv4のみを維持するノード、およびIPv6のみのノードとして展開できるノードが含まれます。 NAT64関数[RFC6145] [RFC6146]に基づく変換メカニズムは、IPv6-IPv4相互運用性のためのインターネット接続の重要な要素である可能性があります。
[RFC6036] reports at least 30% of operators plan to run some kind of translator (presumably NAT64/DNS64). Advice on NAT64 deployment and operations are therefore of some importance. [RFC6586] documents the implications for IPv6-only networks. This document intends to be specific to NAT64 network planning.
[RFC6036]は、オペレーターの少なくとも30％が何らかのトランスレータ（おそらくNAT64 / DNS64）の実行を計画していると報告しています。したがって、NAT64の展開と運用に関するアドバイスは重要です。 [RFC6586]は、IPv6のみのネットワークへの影響を文書化しています。このドキュメントは、NAT64ネットワーク計画に特化したものです。
Regarding IPv4/IPv6 translation, [RFC6144] has described a framework for enabling networks to make interworking possible between IPv4 and IPv6 networks. Two operation modes (i.e., stateful translation and stateless translation) have been described in Section 3.2 of [RFC6144]. This document describes the usage of those two operation modes and has further categorized different NAT64 functions, locations, and use cases. The principal distinction of location is whether the NAT64 is located in a Carrier-Grade NAT or server Front End. The terms "NAT-CGN" and "NAT-FE" are understood to be a topological distinction indicating different features employed in a NAT64 deployment.
IPv4 / IPv6変換に関して、[RFC6144]はネットワークがIPv4とIPv6ネットワーク間の相互作用を可能にするためのフレームワークを説明しました。 [RFC6144]のセクション3.2には、2つの動作モード（つまり、ステートフル変換とステートレス変換）が記載されています。このドキュメントでは、これら2つの動作モードの使用法について説明し、さまざまなNAT64機能、場所、および使用例をさらに分類しています。場所の主な違いは、NAT64がキャリアグレードのNATにあるか、サーバーのフロントエンドにあるかです。 「NAT-CGN」および「NAT-FE」という用語は、NAT64展開で使用されるさまざまな機能を示すトポロジの違いであると理解されています。
NAT64 Carrier Grade NAT (NAT64-CGN): A NAT64-CGN is placed in an ISP network. IPv6-enabled subscribers leverage the NAT64-CGN to access existing IPv4 Internet services. The ISP as an administrative entity takes full control of the IPv6 side, but it has limited or no control on the IPv4 Internet side. NAT64-CGN deployments may have to consider the IPv4 Internet environment and services, and make appropriate configuration choices accordingly.
NAT64キャリアグレードNAT（NAT64-CGN）：NAT64-CGNはISPネットワークに配置されます。 IPv6対応の加入者は、NAT64-CGNを利用して既存のIPv4インターネットサービスにアクセスします。管理エンティティとしてのISPはIPv6側を完全に制御しますが、IPv4インターネット側では制御が制限されるか、まったく制御されません。 NAT64-CGNの展開では、IPv4インターネット環境とサービスを考慮し、それに応じて適切な構成を選択する必要がある場合があります。
NAT64 server Front End (NAT64-FE): A NAT64-FE is generally a device with NAT64 functionality in a content provider or data center network. It could be, for example, a traffic load balancer or a firewall. The operator of the NAT64-FE has full control over the IPv4 network within the data center but only limited influence or control over the external Internet IPv6 network.
NAT64サーバーフロントエンド（NAT64-FE）：NAT64-FEは通常、コンテンツプロバイダーまたはデータセンターネットワークにNAT64機能を備えたデバイスです。たとえば、トラフィックロードバランサーやファイアウォールなどです。 NAT64-FEのオペレーターは、データセンター内のIPv4ネットワークを完全に制御できますが、外部インターネットIPv6ネットワークの影響または制御は限定的です。
Fixed network operators and mobile operators may locate NAT64 translators in access networks or in mobile core networks. NAT64 can be built into various devices, including routers, gateways, or firewalls, in order to connect IPv6 users to the IPv4 Internet. With regard to the numbers of users and the shortage of public IPv4 addresses, stateful NAT64 [RFC6146] is more suited to maximize sharing of public IPv4 addresses. The usage of stateless NAT64 can provide better transparency features [MOTIVATION], but it has to be coordinated with Address plus Port (A+P) processes [RFC6346] as specified in [MAP-T] in order to deal with an IPv4 address shortage.
固定ネットワークオペレーターおよびモバイルオペレーターは、アクセスネットワークまたはモバイルコアネットワークにNAT64トランスレーターを配置できます。 NAT64は、IPv6ユーザーをIPv4インターネットに接続するために、ルーター、ゲートウェイ、ファイアウォールなどのさまざまなデバイスに組み込むことができます。ユーザーの数とパブリックIPv4アドレスの不足に関して、ステートフルNAT64 [RFC6146]はパブリックIPv4アドレスの共有を最大化するのにより適しています。ステートレスNAT64を使用すると、透過性機能が向上しますが[MOTIVATION]、IPv4アドレスの不足に対処するには、[MAP-T]で指定されているアドレスプラスポート（A + P）プロセス[RFC6346]と調整する必要があります。
DNS64 [RFC6147] is recommended for use in combination with stateful NAT64, and it will likely be an essential part of an IPv6 single-stack network that couples to the IPv4 Internet. 464XLAT [RFC6877] can enable access of IPv4-only applications or applications that call IPv4 literal addresses. Using DNS64 will help 464XLAT to automatically discover NAT64 prefixes through [RFC7050]. Berkeley Internet Name Daemon (BIND) software supports that function. It's important to note that DNS64 generates the synthetic AAAA reply when services only provide A records. Operators should not expect to access IPv4 parts of a dual-stack server using NAT64/DNS64. The traffic is forwarded on IPv6 paths if dual-stack servers are targeted. IPv6 traffic may be routed around rather than going through NAT64. Only the traffic going to IPv4-only services would traverse the NAT64 translator. In some sense, it encourages IPv6 usage and limits NAT translation compared to employing NAT44, where all traffic flows have to be translated. In some cases, NAT64-CGNs may serve double roles, i.e., as a translator and IPv6 forwarder. In mobile networks, NAT64 may be deployed as the default gateway serving all the IPv6 traffic. The traffic heading to a dual-stack server is only forwarded on the NAT64. Therefore, both IPv6 and IPv4 are suggested to be configured on the Internet-facing interfaces of NAT64. We tested on the top 100 websites (referring to [Alexa] statistics). 43% of websites are connected and forwarded on NAT64 since those websites have both AAAA and A records. With expansion of IPv6 support, the translation process on NAT64 will likely become less important over time. It should be noted that the DNS64-DNSSEC interaction [RFC6147] may impact validation of Resource Records retrieved from the DNS64 process. In particular, DNSSEC validation will fail when DNS64 synthesizes AAAA records where there is a DNS query received with the "DNSSEC OK" (DO) bit set and the "Checking Disabled" (CD) bit set.
DNS64 [RFC6147]は、ステートフルNAT64と組み合わせて使用することをお勧めします。これは、IPv4インターネットに結合するIPv6シングルスタックネットワークの重要な部分になる可能性があります。 464XLAT [RFC6877]は、IPv4のみのアプリケーションまたはIPv4リテラルアドレスを呼び出すアプリケーションへのアクセスを有効にすることができます。 DNS64を使用すると、464XLATが[RFC7050]を介してNAT64プレフィックスを自動的に検出できるようになります。 Berkeley Internet Name Daemon（BIND）ソフトウェアはその機能をサポートしています。サービスがAレコードのみを提供する場合、DNS64が合成AAAA応答を生成することに注意することが重要です。オペレーターは、NAT64 / DNS64を使用してデュアルスタックサーバーのIPv4部分にアクセスすることを期待すべきではありません。デュアルスタックサーバーがターゲットの場合、トラフィックはIPv6パスで転送されます。 IPv6トラフィックは、NAT64を経由するのではなく、ルーティングされます。 IPv4のみのサービスに向かうトラフィックのみがNAT64トランスレータを通過します。ある意味では、すべてのトラフィックフローを変換する必要があるNAT44を使用する場合と比較して、IPv6の使用を促進し、NAT変換を制限します。場合によっては、NAT64-CGNは、トランスレータとIPv6フォワーダの2つの役割を果たします。モバイルネットワークでは、すべてのIPv6トラフィックを処理するデフォルトゲートウェイとしてNAT64を展開できます。デュアルスタックサーバーに向かうトラフィックは、NAT64でのみ転送されます。したがって、IPv6とIPv4の両方をNAT64のインターネットに面するインターフェイスで構成することをお勧めします。上位100のWebサイトでテストしました（[Alexa]統計を参照）。 43％のWebサイトは、AAAAとAの両方のレコードを持っているため、NAT64で接続および転送されます。 IPv6サポートの拡大に伴い、NAT64での変換プロセスは時間の経過とともに重要性が低くなる可能性があります。 DNS64とDNSSECの相互作用[RFC6147]は、DNS64プロセスから取得したリソースレコードの検証に影響を与える可能性があることに注意してください。特に、DNS64が「DNSSEC OK」（DO）ビットセットと「Checking Disabled」（CD）ビットセットで受信されたDNSクエリがあるAAAAレコードを合成する場合、DNSSEC検証は失敗します。
All connections to IPv4 services from IPv6-only clients must traverse the NAT64-CGN. It can be advantageous from the viewpoint of troubleshooting and traffic engineering to carry the IPv6 traffic natively for as long as possible within an access network and translate packets only at or near the network egress. NAT64 may be a feature of the Autonomous System (AS) border in fixed networks. It may be deployed in an IP node beyond the Gateway GPRS Support Node (GGSN) or Packet Data Network Gateway (PDN-GW) in mobile networks or directly as part of the gateway itself in some situations. This allows consistent attribution and traceability within the service provider network. It has been observed that the process of correlating log information is problematic from multiple vendors' equipment due to inconsistent formats of log records. Placing NAT64 in a centralized location may reduce diversity of log format and simplify the network provisioning. Moreover, since NAT64 is only targeted at serving traffic flows from IPv6 to IPv4-only services, the user traffic volume should not be as high as in a NAT44 scenario, and therefore, the gateway's capacity in such a location may be less of a concern or a hurdle to deployment. On the other hand, placement in a centralized fashion would require more strict high-availability (HA) design. It would also make geolocation based on IPv4 addresses rather inaccurate as is currently the case for NAT44 CGNs already deployed in ISP networks. More considerations or workarounds on HA and traceability can be found in Sections 4 and 5.
IPv6のみのクライアントからIPv4サービスへのすべての接続は、NAT64-CGNを通過する必要があります。トラブルシューティングとトラフィックエンジニアリングの観点から見ると、IPv6トラフィックをネイティブでアクセスネットワーク内で可能な限り長く伝送し、ネットワーク出口またはその近くでのみパケットを変換することが有利です。 NAT64は、固定ネットワークの自律システム（AS）ボーダーの機能である可能性があります。モバイルネットワークのゲートウェイGPRSサポートノード（GGSN）またはパケットデータネットワークゲートウェイ（PDN-GW）の先のIPノードに、または状況によってはゲートウェイ自体の一部として直接展開できます。これにより、サービスプロバイダーネットワーク内で一貫した帰属と追跡が可能になります。ログ情報の相関プロセスは、ログレコードのフォーマットに一貫性がないため、複数のベンダーの機器から問題があることが確認されています。 NAT64を一元化された場所に配置すると、ログ形式の多様性が減り、ネットワークプロビジョニングが簡略化される場合があります。さらに、NAT64はIPv6からIPv4のみのサービスへのトラフィックフローを提供することのみを目的としているため、ユーザートラフィック量はNAT44シナリオほど高くないはずです。そのため、このような場所でのゲートウェイの容量はそれほど問題になりません。または展開のハードル。一方、集中的に配置するには、より厳密な高可用性（HA）設計が必要になります。また、ISPネットワークにすでに展開されているNAT44 CGNの現在のケースのように、IPv4アドレスに基づく地理位置情報も不正確になります。 HAとトレーサビリティに関するその他の考慮事項または回避策については、セクション4および5を参照してください。
NAT64 will likely coexist with NAT44 in a dual-stack network where IPv4 private addresses are allocated to customers. The coexistence has already been observed in mobile networks, in which dual-stack mobile phones normally initiate some dual-stack PDN/PDP Type [RFC6459] to query both IPv4/IPv6 addresses and IPv4-allocated addresses (which are very often private ones). [RFC6724] always prioritizes IPv6 connections regardless of whether the end-to-end path is native IPv6 or IPv6 translated to IPv4 via NAT64/DNS64. Conversely, a "Happy Eyeballs" [RFC6555] algorithm will direct some IP flows across IPv4 paths. The selection of IPv4/IPv6 paths may depend on particular implementation choices or settings on a host-by-host basis, and it may differ from an operator's deterministic scheme. Our tests verified that hosts may find themselves switching between IPv4 and IPv6 paths as they access identical services, but at different times [COEXIST]. Since the topology on each path is
NAT64は、IPv4プライベートアドレスが顧客に割り当てられるデュアルスタックネットワークでNAT44と共存する可能性があります。モバイルネットワークではすでに共存が確認されており、デュアルスタック携帯電話は通常、デュアルスタックPDN / PDPタイプ[RFC6459]を開始して、IPv4 / IPv6アドレスとIPv4割り当てアドレス（非常に多くの場合プライベートアドレス）の両方をクエリします。 。 [RFC6724]は、エンドツーエンドパスがネイティブIPv6であるか、NAT64 / DNS64を介してIPv4に変換されたIPv6であるかに関係なく、常にIPv6接続を優先します。逆に、「Happy Eyeballs」[RFC6555]アルゴリズムは、一部のIPフローをIPv4パスに転送します。 IPv4 / IPv6パスの選択は、特定の実装の選択またはホストごとの設定に依存する場合があり、オペレーターの決定論的スキームとは異なる場合があります。私たちのテストでは、ホストが同一のサービスにアクセスするときに、IPv4パスとIPv6パスを切り替える場合があることを確認しましたが、[COEXIST]は異なります。各パスのトポロジーは
potentially different, it may cause unstable user experience and some degradation of Quality of Experience (QoE) when falling back to the other protocol. It's also difficult for operators to find a solution to make a stable network with optimal resource utilization. In general, it's desirable to figure out the solution that will introduce IPv6/IPv4 translation service to IPv6-only hosts connecting to IPv4 servers, while making sure dual-stack hosts have at least one address family accessible via native service if possible. With the end-to-end native IPv6 environment available, hosts should be upgraded aggressively to migrate in favor of IPv6 only. There are ongoing efforts to detect host connectivity and propose a new DHCPv6 option [CONN-STATUS] to convey appropriate configuration information to the hosts.
異なる可能性があるため、他のプロトコルにフォールバックすると、ユーザーエクスペリエンスが不安定になり、Quality of Experience（QoE）が低下する可能性があります。また、オペレーターが最適なリソース使用率で安定したネットワークを構築するためのソリューションを見つけることも困難です。一般に、デュアルスタックホストにネイティブサービス経由でアクセス可能なアドレスファミリが少なくとも1つあることを確認しながら、IPv4サーバーに接続するIPv6のみのホストにIPv6 / IPv4変換サービスを導入するソリューションを理解することが望ましいです。エンドツーエンドのネイティブIPv6環境が利用可能な場合、IPv6のみを優先して移行するには、ホストを積極的にアップグレードする必要があります。ホスト接続を検出し、適切な構成情報をホストに伝えるための新しいDHCPv6オプション[CONN-STATUS]を提案するための継続的な取り組みがあります。
Some Internet Content Providers (ICPs) may locate NAT64 in front of an Internet Data Center (IDC), for example, co-located with a load-balancing function. Load balancers are employed to connect different IP family domains and distribute workloads across multiple domains or internal servers. In some cases, IPv4 address exhaustion may not be a problem in an IDC's internal network. IPv6 support for some applications may require increased investment and workload, so IPv6 support may not be a priority. NAT64 can be used to support widespread IPv6 adoption on the Internet while maintaining access to IPv4-only applications.
一部のインターネットコンテンツプロバイダー（ICP）は、インターネットデータセンター（IDC）の前にNAT64を配置する場合があります。たとえば、負荷分散機能と同じ場所に配置されます。ロードバランサは、異なるIPファミリドメインを接続し、複数のドメインまたは内部サーバーにワークロードを分散するために使用されます。場合によっては、IPv4アドレスの枯渇はIDCの内部ネットワークでは問題にならないことがあります。一部のアプリケーションのIPv6サポートは、投資とワークロードの増加を必要とする場合があるため、IPv6サポートは優先事項ではない場合があります。 NAT64を使用すると、IPv4のみのアプリケーションへのアクセスを維持しながら、インターネットでの広範なIPv6の採用をサポートできます。
Different strategies have been described in [RFC6883]; they are referred to as "inside out" and "outside in". An IDC operator may implement the following practices in the NAT64-FE networking scenario.
[RFC6883]にはさまざまな戦略が記述されています。それらは「裏返し」および「裏返し」と呼ばれます。 IDCオペレーターは、NAT64-FEネットワークシナリオで次のプラクティスを実装できます。
o Some ICPs who already have satisfactory operational experience might adopt single-stack IPv6 operation in building data center networks, servers, and applications, as it allows new services to be delivered without having to consider IPv4 NAT or the address limitations of IPv4 networks. Stateless NAT64 [RFC6145] can used to provide services for IPv4-only customers. [SIIT] has provided further descriptions and guidelines.
o すでに十分な運用経験を持っている一部のICPは、IPv4 NATまたはIPv4ネットワークのアドレス制限を考慮せずに新しいサービスを提供できるため、データセンターネットワーク、サーバー、およびアプリケーションの構築にシングルスタックIPv6運用を採用する可能性があります。ステートレスNAT64 [RFC6145]は、IPv4のみの顧客にサービスを提供するために使用できます。 [SIIT]は、詳細な説明とガイドラインを提供しています。
o ICPs who attempt to offer customers IPv6 support in their application farms at an early stage will likely run proxies, load balancers, or translators that are configured to handle incoming IPv6 flows and proxy them to IPv4 back-end systems. Many load balancers integrate proxy functionality. IPv4 addresses configured in the proxy may be multiplexed like a stateful NAT64 translator. A similar challenge exists as more users with IPv6 connectivity access IPv4 networks. High loads on load balancers may be apt to cause additional latency, IPv4 pool exhaustion, etc. Therefore, this approach is only reasonable at an early stage. ICPs may employ dual stack or IPv6 single stack in a further stage, since native IPv6 is frequently more desirable than any of the transition solutions.
oアプリケーションファームで早い段階でIPv6サポートを顧客に提供しようとするICPは、着信IPv6フローを処理してIPv4バックエンドシステムにプロキシするように構成されたプロキシ、ロードバランサー、またはトランスレーターを実行する可能性があります。多くのロードバランサーはプロキシ機能を統合しています。プロキシで構成されたIPv4アドレスは、ステートフルNAT64トランスレータのように多重化できます。 IPv6接続を使用するユーザーがIPv4ネットワークにアクセスするにつれて、同様の課題が存在します。ロードバランサーの負荷が高いと、追加のレイテンシ、IPv4プールの枯渇などが発生する可能性があります。したがって、このアプローチは初期段階でのみ妥当です。多くの場合、ネイティブIPv6がどの移行ソリューションよりも望ましいため、ICPは、デュアルスタックまたはIPv6シングルスタックをさらに段階的に採用する可能性があります。
[RFC6144] recommends that AAAA records of load balancers or application servers can be directly registered in the authoritative DNS servers. In this case, there is no need to deploy DNS64 name servers. Those AAAA records can point to natively assigned IPv6 addresses or IPv4-converted IPv6 addresses [RFC6052]. Hosts are not aware of the NAT64 translator on the communication path. For testing purposes, operators could employ an independent subdomain, e.g., ipv6exp.example.com, to identify experimental IPv6 services to users. How to design the Fully Qualified Domain Name (FQDN) for the IPv6 service is outside the scope of this document.
[RFC6144]は、ロードバランサーまたはアプリケーションサーバーのAAAAレコードを信頼できるDNSサーバーに直接登録できることを推奨しています。この場合、DNS64ネームサーバーを展開する必要はありません。これらのAAAAレコードは、ネイティブに割り当てられたIPv6アドレスまたはIPv4変換IPv6アドレス[RFC6052]をポイントできます。ホストは、通信パス上のNAT64トランスレータを認識していません。テストの目的で、オペレーターは、独立したサブドメイン（ipv6exp.example.comなど）を使用して、ユーザーに対する実験的なIPv6サービスを識別できます。 IPv6サービスの完全修飾ドメイン名（FQDN）を設計する方法は、このドキュメントの範囲外です。
High Availability (HA) is a major requirement for every service and network service. Deploying redundancy mechanisms is essential to avoiding failure and significantly increasing the network reliability. It's useful not only to stateful NAT64 cases but also to stateless NAT64 gateways.
高可用性（HA）は、すべてのサービスおよびネットワークサービスの主要な要件です。障害を回避し、ネットワークの信頼性を大幅に向上させるには、冗長メカニズムの導入が不可欠です。ステートフルNAT64ケースだけでなく、ステートレスNAT64ゲートウェイにも役立ちます。
Three redundancy modes are mainly used: Cold Standby, Warm Standby, and Hot Standby.
コールドスタンバイ、ウォームスタンバイ、ホットスタンバイの3つの冗長モードが主に使用されます。
o Cold Standby HA devices do not replicate the NAT64 states from the primary equipment to the backup. Administrators switch on the backup NAT64 only if the primary NAT64 fails. As a result, all existing established sessions through a failed translator will be disconnected. The translated flows will need to be recreated by end systems. Since the backup NAT64 is manually configured to switch over to active NAT64, it may have unpredictable impacts to the ongoing services.
o コールドスタンバイHAデバイスは、NAT64状態をプライマリ機器からバックアップに複製しません。管理者は、プライマリNAT64に障害が発生した場合にのみ、バックアップNAT64をオンにします。その結果、失敗したトランスレータを介して確立された既存のセッションはすべて切断されます。変換されたフローは、エンドシステムで再作成する必要があります。バックアップNAT64はアクティブなNAT64に切り替えるように手動で構成されているため、進行中のサービスに予期しない影響を与える可能性があります。
o Warm Standby is a flavor of the Cold Standby mode. Backup NAT64 would keep running once the primary NAT64 is working. This makes Warm Standby less time-consuming during the traffic failover. The Virtual Router Redundancy Protocol (VRRP)[RFC5798] can be a solution to enable automatic handover during Warm Standby. During testing, the handover took a maximum of 1 minute if the backup NAT64 had to take over routing and reconstruct the Binding Information Bases (BIBs) for 30 million sessions. In the deployment phase, operators could balance loads on distinct NAT64 devices. Those NAT64 devices make a warm backup of each other.
oウォームスタンバイは、コールドスタンバイモードの一種です。プライマリNAT64が動作すると、バックアップNAT64は引き続き実行されます。これにより、トラフィックのフェイルオーバー中にウォームスタンバイの時間が短縮されます。仮想ルーター冗長プロトコル（VRRP）[RFC5798]は、ウォームスタンバイ時の自動ハンドオーバーを可能にするソリューションになります。テスト中、バックアップNAT64がルーティングを引き継ぎ、3,000万セッションのバインディング情報ベース（BIB）を再構築する必要がある場合、ハンドオーバーは最大1分かかりました。展開フェーズでは、オペレーターは個別のNAT64デバイスの負荷を分散できます。これらのNAT64デバイスは、互いにウォームバックアップを作成します。
o Hot Standby must synchronize the BIBs between the primary NAT64 and backup. When the primary NAT64 fails, the backup NAT64 takes over and maintains the state of all existing sessions. The internal hosts don't have to reconnect the external hosts. The handover time is extremely reduced. During testing that employed Bidirectional Forwarding Detection (BFD) [RFC5880] combined with VRRP, a handover time of only 35 ms for 30 million sessions was observed. Under ideal conditions, Hot Standby deployments could guarantee the session continuity for every service. In order to transmit session states in a timely manner, operators may have to deploy extra transport links between the primary NAT64 and the distant backup. The scale of synchronization of the data instance depends on the particular deployment. For example, if a NAT64-CGN serves 200,000 users, an average amount of 800,000 sessions per second is a rough estimate of the newly created and expired sessions. A physical 10 Gbit/s transport link may have to be deployed for the sync data transmission considering the amount of sync sessions at the peak and the capacity redundancy.
o ホットスタンバイは、プライマリNAT64とバックアップの間でBIBを同期する必要があります。プライマリNAT64に障害が発生すると、バックアップNAT64が引き継ぎ、既存のすべてのセッションの状態を維持します。内部ホストは外部ホストを再接続する必要はありません。ハンドオーバー時間が大幅に短縮されます。双方向転送検出（BFD）[RFC5880]をVRRPと組み合わせて使用したテスト中に、3,000万セッションで35ミリ秒のハンドオーバー時間が観察されました。理想的な条件下では、ホットスタンバイの展開により、すべてのサービスのセッションの継続性が保証されます。セッション状態をタイムリーに送信するために、オペレーターはプライマリNAT64と遠隔バックアップの間に追加のトランスポートリンクを展開する必要がある場合があります。データインスタンスの同期のスケールは、特定のデプロイメントによって異なります。たとえば、NAT64-CGNが200,000人のユーザーにサービスを提供している場合、1秒あたりの平均セッション数は800,000セッションであり、新しく作成されて期限切れになったセッションの概算です。ピーク時の同期セッションの量と容量の冗長性を考慮して、同期データ送信のために物理10 Gbit / sトランスポートリンクを展開する必要がある場合があります。
In general, Cold Standby and Warm Standby are simpler and less resource intensive, but they require clients to re-establish sessions when a failover occurs. Hot Standby increases resource consumption in order to synchronize state, but it potentially achieves seamless handover. For stateless NAT64, considerations are simple because state synchronization is unnecessary. Regarding stateful NAT64, it may be useful to investigate the performance tolerance of applications and the traffic characteristics in a particular network. Some test results are shown in the Appendix A.
一般に、コールドスタンバイとウォームスタンバイはシンプルでリソースをあまり消費しませんが、フェイルオーバーが発生したときにクライアントがセッションを再確立する必要があります。ホットスタンバイは、状態を同期するためにリソース消費を増やしますが、シームレスなハンドオーバーを実現する可能性があります。ステートレスNAT64の場合、状態の同期が不要であるため、考慮事項は単純です。ステートフルNAT64に関しては、アプリケーションのパフォーマンス許容度と特定のネットワークのトラフィック特性を調査することが役立つ場合があります。付録Aにいくつかのテスト結果を示します。
Our statistics in a mobile network shown that almost 91.21% of traffic is accounted by HTTP/HTTPS services. These services generally don't require session continuity. Hot Standby does not offer much benefit for those sessions on this point. In fixed networks, HTTP streaming, P2P, and online games would be the major traffic beneficiaries of Hot Standby replication [Cisco-VNI]. Consideration should be given to the importance of maintaining bindings for those sessions across failover. Operators may also consider the Average Revenue Per User (ARPU) when deploying a suitable redundancy mode. Warm Standby may still be adopted to cover most services, while Hot Standby could be used to upgrade the Quality of Experience (QoE) and using DNS64 to generate different synthetic responses for limited traffic or destinations. Further considerations are discussed at Section 6.
モバイルネットワークの統計によると、トラフィックのほぼ91.21％がHTTP / HTTPSサービスによるものです。これらのサービスは通常、セッションの継続性を必要としません。ホットスタンバイは、この点でこれらのセッションにあまりメリットをもたらしません。固定ネットワークでは、HTTPストリーミング、P2P、およびオンラインゲームが、ホットスタンバイレプリケーションの主要なトラフィック受益者になります[Cisco-VNI]。フェイルオーバー全体でこれらのセッションのバインディングを維持することの重要性を考慮する必要があります。オペレーターは、適切な冗長モードを展開する際に、ユーザーあたりの平均収益（ARPU）も考慮します。ウォームスタンバイは、ほとんどのサービスをカバーするために引き続き採用できますが、ホットスタンバイは、Quality of Experience（QoE）をアップグレードし、DNS64を使用して、限られたトラフィックまたは宛先に対して異なる合成応答を生成できます。さらなる考慮事項については、セクション6で説明します。
Load balancing is used to accompany redundancy design so that better scalability and resiliency can be achieved. Stateless NAT64s allow asymmetric routing, while anycast-based solutions are recommended in [MAP-DEPLOY]. The deployment of load balancing may make more sense to stateful NAT64s for the sake of avoiding single-point failures. Since the NAT64-CGN and NAT64-FE have distinct facilities, the following lists the considerations for each case.
ロードバランシングは、より優れたスケーラビリティと復元力を実現できるように、冗長設計に伴うものです。ステートレスNAT64では非対称ルーティングが可能ですが、[MAP-DEPLOY]ではエニーキャストベースのソリューションが推奨されます。負荷分散の導入は、シングルポイント障害を回避するために、ステートフルNAT64にとってより意味のあるものになる場合があります。 NAT64-CGNとNAT64-FEには異なる機能があるため、以下に各ケースの考慮事項を示します。
o NAT64-CGN normally doesn't implement load-balancing functions; they may be implemented in other dedicated equipment. Therefore, the gateways have to resort to DNS64 or an internal host's behavior. Once DNS64 is deployed, the load balancing can be performed by synthesizing the AAAA response with different IPv6 prefixes. For the applications not requiring a DNS resolver, internal hosts could learn multiple IPv6 prefixes through the approaches defined in [RFC7050] and then select one based on a given prefix selection policy.
o NAT64-CGNは通常、負荷分散機能を実装していません。それらは他の専用機器に実装される場合があります。したがって、ゲートウェイはDNS64または内部ホストの動作に頼る必要があります。 DNS64が展開されると、さまざまなIPv6プレフィックスを使用してAAAA応答を合成することにより、負荷分散を実行できます。 DNSリゾルバを必要としないアプリケーションの場合、内部ホストは[RFC7050]で定義されたアプローチを通じて複数のIPv6プレフィックスを学習し、所定のプレフィックス選択ポリシーに基づいて選択することができます。
o A dedicated load balancer could be deployed at the front of a NAT64-FE farm. The load balancer could use proxy mode to redirect the flows to the appropriate NAT64 instance. Stateful NAT64s require a deterministic pattern to arrange the traffic in order to ensure outbound/inbound flows traverse the identical NAT64. Therefore, static scheduling algorithms, for example, a source-address-based policy, is preferred. A dynamic algorithm, for example, Round-Robin, may have impacts on applications seeking session continuity, which are described in Table 1.
o 専用のロードバランサーをNAT64-FEファームの前面に配置できます。ロードバランサーは、プロキシモードを使用してフローを適切なNAT64インスタンスにリダイレクトできます。ステートフルNAT64は、アウトバウンド/インバウンドフローが同一のNAT64を確実に通過するように、トラフィックを調整する確定的パターンを必要とします。したがって、ソースアドレスベースのポリシーなどの静的スケジューリングアルゴリズムが推奨されます。ラウンドロビンなどの動的アルゴリズムは、セッションの継続性を求めるアプリケーションに影響を与える可能性があります（表1を参照）。
Traceability is required in many cases, such as meeting accounting requirements and identifying the sources of malicious attacks. Operators are asked to record the NAT64 log information for specific periods of time. In our lab testing, the log information from 200,000 subscribers was collected from a stateful NAT64 gateway for 60 days. Syslog [RFC5424] has been adopted to transmit log messages from NAT64 to a log station. Each log message contains the transport protocol, source IPv6 address:port, translated IPv4 address:port, and timestamp. It takes almost 125 bytes in ASCII format. It has been verified that the rate of traffic flow is around 72,000 flows per second, and the volume of recorded information reaches up to 42.5 terabytes in the raw format. The volume is 29.07 terabytes in a compact format. At scale, operators have to build up dedicated transport links, storage systems, and servers for the purpose of managing such logging.
会計要件を満たす、悪意のある攻撃のソースを特定するなど、多くの場合、トレーサビリティが必要です。オペレーターは、特定の期間のNAT64ログ情報を記録するように求められます。ラボテストでは、200,000人のサブスクライバーからのログ情報が、ステートフルNAT64ゲートウェイから60日間収集されました。 Syslog [RFC5424]は、NAT64からログステーションにログメッセージを送信するために採用されました。各ログメッセージには、トランスポートプロトコル、送信元IPv6アドレス：ポート、変換されたIPv4アドレス：ポート、およびタイムスタンプが含まれます。 ASCII形式で約125バイトかかります。トラフィックフローの速度は毎秒約72,000フローであり、記録された情報の量は未加工形式で最大42.5テラバイトに達することが確認されています。ボリュームはコンパクトな形式で29.07テラバイトです。大規模な場合、事業者はこのようなロギングを管理するために、専用のトランスポートリンク、ストレージシステム、およびサーバーを構築する必要があります。
There are also several improvements that can be made to mitigate the issue. For example, stateful NAT64 could be configured with the bulk port allocation method. Once a subscriber creates the first session, a number of ports are pre-allocated. A bulk allocation message is logged indicating this allocation. Subsequent session creations will use one of the pre-allocated ports and hence do not require logging. The log volume in this case may be only one thousandth of that of dynamic port allocation. Some implementations may adopt static port-range allocations [DET-CGN] that eliminate the need for per-subscriber logging. As a side effect of those methods, the IPv4 multiplexing efficiency is decreased. For example, the utilization ratio of public IPv4 addresses drops to approximately 75% when the NAT64 gateway is configured with bulk port allocation. (The lab testing allocates each subscriber with 400 ports.) In addition, port-range-based allocation should consider port randomization as described in [RFC6056]. The trade-off among address multiplexing efficiency, logging storage compression, and port allocation complexity should be considered. More discussions can be found in [PORT-ALLOC]. The decision can balance usable IPv4 resources against investments in log systems.
この問題を軽減するために行うことができるいくつかの改善点もあります。たとえば、ステートフルNAT64は、バルクポート割り当て方法で構成できます。サブスクライバーが最初のセッションを作成すると、いくつかのポートが事前に割り当てられます。この割り当てを示す一括割り当てメッセージがログに記録されます。後続のセッションの作成では、事前に割り当てられたポートの1つを使用するため、ロギングは必要ありません。この場合のログボリュームは、動的ポート割り当ての1000分の1になる可能性があります。一部の実装では、サブスクライバーごとのログ記録の必要性を排除する静的ポート範囲割り当て[DET-CGN]を採用する場合があります。これらの方法の副作用として、IPv4多重化効率が低下します。たとえば、NAT64ゲートウェイが一括ポート割り当てで構成されている場合、パブリックIPv4アドレスの使用率は約75％に低下します。 （ラボテストでは、各サブスクライバーに400ポートを割り当てます。）さらに、[RFC6056]で説明されているように、ポート範囲ベースの割り当てでは、ポートのランダム化を考慮する必要があります。アドレスの多重化効率、ロギングストレージの圧縮、ポート割り当ての複雑さの間のトレードオフを考慮する必要があります。 [PORT-ALLOC]でより多くの議論を見つけることができます。この決定により、ログシステムへの投資と使用可能なIPv4リソースのバランスをとることができます。
IP addresses are usually used as inputs to geolocation services. The use of address sharing prevents these systems from resolving the location of a host based on IP address alone. Applications that assume such geographic information may not work as intended. The possible solutions listed in [RFC6967] are intended to bridge the gap. However, those solutions can only provide a suboptimal substitution to solve the problem of host identification; in particular, it may not solve today's problems with source identification through translation. The following lists current practices to mitigate the issue.
IPアドレスは通常、地理位置情報サービスへの入力として使用されます。アドレス共有を使用すると、これらのシステムがIPアドレスのみに基づいてホストの場所を解決できなくなります。このような地理情報を想定したアプリケーションは、意図したとおりに機能しない可能性があります。 [RFC6967]にリストされている可能な解決策は、ギャップを埋めることを目的としています。ただし、これらのソリューションは、ホストの識別の問題を解決するための次善の代替手段しか提供できません。特に、翻訳によるソースの識別に関する今日の問題を解決できない可能性があります。以下は、問題を軽減するための現在の慣行の一覧です。
o Operators who adopt NAT64-FE may leverage the application-layer proxies, e.g., X-Forwarded-For (XFF) [RFC7239], to convey the IPv6 source address in HTTP headers. Those messages would be passed on to web servers. The log parsing tools are required to be able to support IPv6 and may lookup RADIUS servers for the target subscribers based on IPv6 addresses included in XFF HTTP headers. XFF is the de facto standard that has been integrated in most load balancers. Therefore, it may be superior to use in a NAT-FE environment. On the downside, XFF is specific to HTTP. It restricts usage so that the solution can't be applied to requests made over HTTPS. This makes geolocation problematic for HTTPS-based services.
o NAT64-FEを採用する事業者は、アプリケーション層プロキシ（X-Forwarded-For（XFF）[RFC7239]など）を利用して、HTTPヘッダーでIPv6送信元アドレスを伝達できます。これらのメッセージはWebサーバーに渡されます。ログ解析ツールは、IPv6をサポートできる必要があり、XFF HTTPヘッダーに含まれているIPv6アドレスに基づいてターゲットサブスクライバーのRADIUSサーバーを検索する場合があります。 XFFは、ほとんどのロードバランサーに統合されている事実上の標準です。したがって、NAT-FE環境での使用よりも優れている場合があります。欠点として、XFFはHTTPに固有です。 HTTPSを介して行われたリクエストにソリューションを適用できないように、使用を制限します。これにより、HTTPSベースのサービスで地理位置情報が問題になります。
o The NAT64-CGN equipment may not implement XFF. Geolocation based on shared IPv4 addresses is rather inaccurate in that case. Operators could subdivide the outside IPv4 address pool so an IPv6 address can be translated depending on the IPv6 subscriber's geographical locations. As a consequence, location information can be identified from a certain IPv4 address range. [RFC6967] also enumerates several options to reveal the host identifier. Each solution likely has its own specific usage. For the geolocation systems relying on a RADIUS database [RFC5580], we have investigated delivering NAT64 BIBs and Session Table Entries (STEs) to a RADIUS server [NAT64-RADIUS]. This method could provide a geolocation system with an internal IPv6 address to identify each user. It can be paired with [RFC5580] to convey the original source address through the same message bus.
o NAT64-CGN機器はXFFを実装しない場合があります。その場合、共有IPv4アドレスに基づく位置情報はかなり不正確です。オペレーターは外部のIPv4アドレスプールを細分化して、IPv6サブスクライバーの地理的な場所に応じてIPv6アドレスを変換できるようにします。その結果、特定のIPv4アドレス範囲から位置情報を識別できます。 [RFC6967]は、ホスト識別子を明らかにするためのいくつかのオプションも列挙しています。各ソリューションには、固有の使用法がある可能性があります。 RADIUSデータベースに依存する地理位置情報システム[RFC5580]の場合、NAT64 BIBおよびセッションテーブルエントリ（STE）をRADIUSサーバー[NAT64-RADIUS]に配信することを調査しました。この方法により、地理位置情報システムに各ユーザーを識別する内部IPv6アドレスを提供できます。 [RFC5580]と組み合わせて、同じメッセージバスを介して元の送信元アドレスを伝達できます。
NAT64 is providing a translation capability between IPv6 and IPv4 end nodes. In order to provide reachability between two IP address families, NAT64-CGN has to implement appropriate application-aware functions, i.e., Application Layer Gateways (ALGs), where address translation is not sufficient and security mechanisms do not render the functions infeasible. Most NAT64-CGNs mainly provide FTP-ALG [RFC6384]. NAT64-FEs may have functional richness on the load balancer; for example, HTTP-ALG, HTTPS-ALG, RTSP-ALG, and SMTP-ALG have been supported. Those application protocols exchange IP address and port parameters within a control session, for example, using the "Via" field in a HTTP header, "Transport" field in an RTSP SETUP message, or "Received:" header in a SMTP message. ALG functions will detect those fields and make IP address translations. It should be noted that ALGs may impact the performance on a NAT64 box to some extent. ISPs as well as content providers might choose to avoid situations where the imposition of an ALG might be required. At the same time, it is also important to remind customers and application developers that IPv6 end-to-end usage does not require ALG imposition and therefore results in a better overall user experience.
NAT64は、IPv6とIPv4のエンドノード間の変換機能を提供します。 2つのIPアドレスファミリ間の到達可能性を提供するために、NAT64-CGNは適切なアプリケーション対応機能、つまりアプリケーションレイヤーゲートウェイ（ALG）を実装する必要があります。この場合、アドレス変換では不十分であり、セキュリティメカニズムでは機能を実行できません。ほとんどのNAT64-CGNは主にFTP-ALG [RFC6384]を提供します。 NAT64-FEは、ロードバランサーの機能が豊富な場合があります。たとえば、HTTP-ALG、HTTPS-ALG、RTSP-ALG、SMTP-ALGがサポートされています。これらのアプリケーションプロトコルは、制御セッション内でIPアドレスとポートパラメータを交換します。たとえば、HTTPヘッダーの「Via」フィールド、RTSP SETUPメッセージの「Transport」フィールド、またはSMTPメッセージの「Received：」ヘッダーを使用します。 ALG関数はこれらのフィールドを検出し、IPアドレス変換を行います。 ALGはNAT64ボックスのパフォーマンスにある程度影響を与える可能性があることに注意してください。 ISPとコンテンツプロバイダーは、ALGの強制が必要になる状況を回避することを選択する場合があります。同時に、IPv6のエンドツーエンドの使用にはALGインポジションが必要ないため、全体的なユーザーエクスペリエンスが向上することを顧客とアプリケーション開発者に思い出させることも重要です。
The service reachability is also subject to the IPv6 support in the client side. We tested several kinds of applications as shown in the below table to verify the IPv6 support. The experiences of some applications are still aligned with [RFC6586]. For example, we tested P2P file sharing and streaming applications including eMule v0.50a, Thunder v7.9, and PPS TV v3.2.0. It has been found there are some software issues with the support of IPv6 at this time. The application software would benefit from 464XLAT [RFC6877] until the software adds IPv6 support. A SIP-based voice call has been tested in the LTE mobile environment as specified in [IR.92]. The voice call failed due to the lack of NAT64 traversal when an IPv6 SIP user agent communicates with an IPv4 SIP user agent. In order to address the failure, Interactive Connectivity Establishment (ICE) as described in [RFC5245] is recommended to be supported for the SIP IPv6 transition. [RFC6157] describes both signaling and the media-layer process, which should be followed. In addition, it is worth noting that ICE is not only useful for NAT traversal, but also for firewall [RFC6092] traversal in a native IPv6 deployment.
サービスの到達可能性は、クライアント側でのIPv6サポートの影響も受けます。次の表に示すように、数種類のアプリケーションをテストして、IPv6のサポートを確認しました。一部のアプリケーションのエクスペリエンスは、まだ[RFC6586]と整合しています。たとえば、eMule v0.50a、Thunder v7.9、PPS TV v3.2.0などのP2Pファイル共有およびストリーミングアプリケーションをテストしました。現時点では、IPv6のサポートに伴うソフトウェアの問題がいくつかあることが判明しています。アプリケーションソフトウェアは、ソフトウェアがIPv6サポートを追加するまで、464XLAT [RFC6877]の恩恵を受けます。 SIPベースの音声通話は、[IR.92]で指定されているLTEモバイル環境でテストされています。 IPv6 SIPユーザーエージェントがIPv4 SIPユーザーエージェントと通信するときにNAT64トラバーサルがないため、音声通話が失敗しました。障害に対処するために、[RFC5245]で説明されているInteractive Connectivity Establishment（ICE）をSIP IPv6移行でサポートすることをお勧めします。 [RFC6157]は、シグナリングとメディア層プロセスの両方について説明しており、従う必要があります。さらに、ICEはNATトラバーサルだけでなく、ネイティブIPv6展開でのファイアウォール[RFC6092]トラバーサルにも役立ちます。
Different IPsec modes for VPN services have been tested, including IPsec Authentication Header (AH) and IPsec Encapsulating Security Payload (ESP). It has been shown that IPsec AH fails because the destination host detects the IP header changes and invalidates the packets. IPsec ESP failed in our testing because the NAT64 does not translate IPsec ESP (i.e., protocol 50) packets. It has been suggested that IPsec ESP would succeed if the IPsec client supports NAT traversal in the Internet Key Exchange Protocol (IKE) [RFC3947] and uses IPsec ESP over UDP [RFC3948].
IPsec認証ヘッダー（AH）やIPsecカプセル化セキュリティペイロード（ESP）など、VPNサービスのさまざまなIPsecモードがテストされています。宛先ホストがIPヘッダーの変更を検出し、パケットを無効にするため、IPsec AHが失敗することが示されています。 NAT64がIPsec ESP（つまり、プロトコル50）パケットを変換しないため、IPsec ESPはテストで失敗しました。 IPsecクライアントがインターネットキー交換プロトコル（IKE）[RFC3947]でNATトラバーサルをサポートし、IPsec ESP over UDP [RFC3948]を使用する場合、IPsec ESPは成功することが示唆されています。
Table 1: The Tested Applications
表1：テスト済みアプリケーション
+----------------+----------------------------------------------------+
| Application | Results and Issues Found |
+----------------+----------------------------------------------------+
| Web service | Mostly pass; some failures due to IPv4 literals |
+----------------+----------------------------------------------------+
|Instant Message | Mostly fail; software can't support IPv6 |
+----------------+----------------------------------------------------+
| Games | Mostly pass for web-based games; mostly fail for |
| | standalone games due to the lack of IPv6 support |
| | in software |
+----------------+----------------------------------------------------+
| SIP VoIP | Fail, due to the lack of NAT64 traversal |
+----------------+----------------------------------------------------+
| IPsec VPN | Fail; the translated IPsec packets are invalidated |
+----------------+----------------------------------------------------+
|P2P file sharing| Mostly fail; software can't support IPv6, |
|and streaming | e.g., eMule, Thunder, and PPS TV |
+----------------+----------------------------------------------------+
| FTP | Pass |
+----------------+----------------------------------------------------+
| Email | Pass |
+----------------+----------------------------------------------------+
Session status normally is managed by a static timer. For example, the value of the "established connection idle-timeout" must not be less than 2 hours 4 minutes [RFC5382] for TCP sessions and 5 minutes for UDP sessions [RFC4787]. In some cases, NAT resources may be significantly consumed by largely inactive users. The NAT and other customers would suffer from service degradation due to port consumption by other subscribers using the same NAT64 device. A flexible NAT session control is desirable to resolve these issues. The Port Control Protocol (PCP) [RFC6887] could be a candidate to provide such capability. A NAT64-CGN should integrate with a PCP server to allocate available IPv4 address/port resources. Resources could be assigned to PCP clients through PCP MAP/PEER mode. Doing so might improve user experiences, for example, by assigning different sizes of port ranges for different subscribers. Those mechanisms are also helpful to minimize terminal battery consumption and reduce the number of keep-alive messages sent by mobile terminal devices.
セッションステータスは通常、静的タイマーによって管理されます。たとえば、「確立された接続のアイドルタイムアウト」の値は、TCPセッションの場合は2時間4分[RFC5382]、UDPセッションの場合は5分[RFC4787]以上でなければなりません。場合によっては、NATリソースがほとんどアクティブでないユーザーによって大幅に消費されることがあります。同じNAT64デバイスを使用している他のサブスクライバーによるポートの消費により、NATおよび他の顧客はサービスの低下に悩まされるでしょう。これらの問題を解決するには、柔軟なNATセッション制御が望ましいです。 Port Control Protocol（PCP）[RFC6887]は、そのような機能を提供する候補になる可能性があります。 NAT64-CGNはPCPサーバーと統合して、使用可能なIPv4アドレス/ポートリソースを割り当てる必要があります。 PCP MAP / PEERモードを介してリソースをPCPクライアントに割り当てることができます。これにより、たとえば、異なるサブスクライバーに異なるサイズのポート範囲を割り当てることにより、ユーザーエクスペリエンスが向上する可能性があります。これらのメカニズムは、端末のバッテリー消費を最小限に抑え、モバイル端末デバイスが送信するキープアライブメッセージの数を減らすのにも役立ちます。
Subscribers can also benefit from network reliability. It has been discussed that Hot Standby offers a satisfactory experience after outage of the primary NAT64 has occurred. Operators may rightly be concerned about the considerable investment required for NAT64 equipment relative to low ARPU. For example, transport links may be expensive, because the primary NAT64 and the backup are normally located at different locations, separated by a relatively large distance. Additional cost would be incurred to ensure the connectivity quality. However, that may be necessary to applications that are delay-sensitive and seek session continuity, for example, online games and live streaming. Operators may be able to get added value from those services by offering first-class services. The service sessions can be pre-configured on the gateway to Hot Standby mode depending on the subscriber's profile. The rest of the sessions can be covered by Cold or Warm Standby.
加入者は、ネットワークの信頼性のメリットも享受できます。プライマリNAT64の停止が発生した後、ホットスタンバイが満足のいくエクスペリエンスを提供することが議論されています。事業者は、低ARPUに比べてNAT64機器に必要なかなりの投資を懸念している可能性があります。たとえば、プライマリNAT64とバックアップは通常、比較的大きな距離で離れた別の場所にあるため、トランスポートリンクは高価になる可能性があります。接続品質を保証するために追加費用が発生します。ただし、オンラインゲームやライブストリーミングなど、遅延の影響を受けやすく、セッションの継続性を求めるアプリケーションでは、これが必要になる場合があります。オペレーターは、ファーストクラスのサービスを提供することにより、これらのサービスから付加価値を得ることができる場合があります。サービスセッションは、加入者のプロファイルに応じて、ゲートウェイ上でホットスタンバイモードに事前設定できます。残りのセッションは、コールドまたはウォームスタンバイでカバーできます。
IPv6 requires that every link in the Internet have a Maximum Transmission Unit (MTU) of 1280 octets or greater [RFC2460]. However, if NAT64 translation is deployed, some IPv4 MTU constrained link will be used in a communication path and the originating IPv6 nodes may therefore receive an ICMP Packet Too Big (PTB) message, reporting a Next-Hop MTU less than 1280 bytes. The result would be that IPv6 allows packets to contain a fragmentation header, without the packet being fragmented into multiple pieces. A NAT64 would receive IPv6 packets with a fragmentation header in which the "M" flag is set to 0 and the "Fragment Offset" is set to 0. Those packets likely impact other fragments already queued with the same set of {IPv6 Source Address, IPv6 Destination Address, Fragment Identification}. If the NAT64 box is compliant with [RFC5722], there is a risk that all the fragments will have to be dropped.
IPv6では、インターネットのすべてのリンクの最大伝送ユニット（MTU）が1280オクテット以上である必要があります[RFC2460]。ただし、NAT64変換が展開されている場合、一部のIPv4 MTU制約リンクが通信パスで使用されるため、発信IPv6ノードがICMPパケットが大きすぎる（PTB）メッセージを受信し、1280バイト未満のネクストホップMTUを報告する場合があります。その結果、IPv6では、パケットが複数の断片に断片化されることなく、パケットに断片化ヘッダーを含めることができます。 NAT64は、「M」フラグが0に設定され、「フラグメントオフセット」が0に設定されているフラグメンテーションヘッダーを持つIPv6パケットを受信します。これらのパケットは、同じ{IPv6送信元アドレス、 IPv6宛先アドレス、フラグメント識別}。 NAT64ボックスが[RFC5722]に準拠している場合、すべてのフラグメントをドロップする必要があるリスクがあります。
[RFC6946] discusses how this situation could be exploited by an attacker to perform fragmentation-based attacks and also proposes improved handling of such packets. It requires enhancements on NAT64 gateway implementations to isolate the processing of packets. NAT64 devices should follow the recommendations and take steps to prevent the risks of fragmentation.
[RFC6946]は、攻撃者がこの状況を悪用して断片化ベースの攻撃を実行する方法を説明し、そのようなパケットの処理を改善することも提案しています。パケットの処理を分離するには、NAT64ゲートウェイ実装の拡張が必要です。 NAT64デバイスは推奨事項に従い、断片化のリスクを防ぐための措置を講じる必要があります。
Another approach that potentially avoids this issue is to configure the IPv4 MTU to more than 1260 bytes. This would prevent getting a PTB message for an MTU smaller than 1280 bytes. Such an operational consideration is hard to universally apply to the legacy "IPv4 Internet" that is bridged by NAT64-CGNs. However, it's a feasible approach in NAT64-FE cases, since an IPv4 network NAT64-FE is rather well-organized and operated by an IDC operator or content provider. Therefore, the MTU of an IPv4 network in NAT64-FE case is strongly recommended to be set to more than 1260 bytes.
この問題を潜在的に回避する別のアプローチは、IPv4 MTUを1260バイト以上に構成することです。これにより、1280バイト未満のMTUのPTBメッセージを取得できなくなります。このような運用上の考慮事項は、NAT64-CGNによってブリッジされるレガシー「IPv4インターネット」に普遍的に適用することは困難です。ただし、IPv4ネットワークNAT64-FEはIDCオペレーターまたはコンテンツプロバイダーによってかなり組織化され、運用されているため、これはNAT64-FEのケースでは実行可能なアプローチです。したがって、NAT64-FEの場合のIPv4ネットワークのMTUは、1260バイトを超える値に設定することを強くお勧めします。
Unique Local Addresses (ULAs) are defined in [RFC4193] to be renumbered within a network site for local communications. Operators may use ULAs as NAT64 prefixes to provide site-local IPv6 connectivity. Those ULA prefixes are stripped when the packets go to the IPv4 Internet; therefore, ULAs are only valid in the IPv6 site. The use of ULAs could help in identifying the translation traffic. [ULA-USAGE] provides further guidance on using ULAs.
一意のローカルアドレス（ULA）は、[RFC4193]で定義されており、ローカル通信用にネットワークサイト内で番号が付け直されます。オペレーターは、サイトローカルIPv6接続を提供するためにULAをNAT64プレフィックスとして使用できます。これらのULAプレフィックスは、パケットがIPv4インターネットに送信されるときに削除されます。したがって、ULAはIPv6サイトでのみ有効です。 ULAの使用は、変換トラフィックの識別に役立ちます。 [ULA-USAGE]は、ULAの使用に関する詳細なガイダンスを提供します。
We configure ULAs as NAT64 prefixes on a NAT64-CGN. If a host is assigned with only an IPv6 address and connected to a NAT64-CGN, when it connects to an IPv4 service, it would receive a AAAA record generated by the DNS64 with the ULA prefix. A Global Unicast Address (GUA) will be selected as the source address to the ULA destination address. When the host has both IPv4 and IPv6 addresses, it would initiate both A and AAAA record lookup, then both the original A record and DNS64-generated AAAA record would be received. A host that is compliant with [RFC6724] will never prefer a ULA over an IPv4 address. An IPv4 path will always be selected. It may be undesirable because the NAT64-CGN will never be used. Operators may consider adding additional site-specific rows into the default policy table for host address selection in order to steer traffic flows through the NAT64-CGN. However, it involves significant costs to change a terminal's behavior. Therefore, it is not suggested that operators configure ULAs on a NAT64-CGN.
NAT64-CGN上のNAT64プレフィックスとしてULAを構成します。ホストにIPv6アドレスのみが割り当てられ、NAT64-CGNに接続されている場合、ホストがIPv4サービスに接続すると、DNS64によって生成されたULAプレフィックス付きのAAAAレコードを受け取ります。グローバルユニキャストアドレス（GUA）が、ULA宛先アドレスへのソースアドレスとして選択されます。ホストにIPv4とIPv6の両方のアドレスがある場合、ホストはAとAAAAの両方のレコード検索を開始し、元のAレコードとDNS64で生成されたAAAAレコードの両方が受信されます。 [RFC6724]に準拠するホストは、IPv4アドレスよりもULAを優先することはありません。 IPv4パスが常に選択されます。 NAT64-CGNは決して使用されないため、これは望ましくない場合があります。オペレーターは、NAT64-CGNを通過するトラフィックフローを誘導するために、ホストアドレス選択用のデフォルトのポリシーテーブルにサイト固有の行を追加することを検討する場合があります。ただし、端末の動作を変更するにはかなりのコストがかかります。したがって、オペレーターがNAT64-CGNでULAを構成することはお勧めしません。
ULAs can't work when hosts transit the Internet to connect with NAT64. Therefore, ULAs are not applicable to the case of NAT64-FE.
ホストがNAT64に接続するためにインターネットを通過する場合、ULAは機能しません。したがって、ULAはNAT64-FEの場合には適用されません。
This document presents the deployment experiences of NAT64 in CGN and FE scenarios. In general, RFC 6146 [RFC6146] provides TCP-tracking, address-dependent filtering mechanisms to protect NAT64 from Distributed Denial of Service (DDoS). In NAT64-CGN cases, operators could also adopt unicast Reverse Path Forwarding (uRPF) [RFC3704] and blacklisting and whitelisting to enhance security by specifying access policies. For example, NAT64-CGN should forbid establishing NAT64 BIB for incoming IPv6 packets if they do not pass the uRPF check in Strict or Loose mode or if their source IPv6 address is blacklisted.
このドキュメントでは、CGNおよびFEシナリオでのNAT64の展開エクスペリエンスについて説明します。一般的に、RFC 6146 [RFC6146]は、分散型サービス拒否（DDoS）からNAT64を保護するために、TCP追跡、アドレス依存のフィルタリングメカニズムを提供します。 NAT64-CGNの場合、事業者はユニキャストリバースパスフォワーディング（uRPF）[RFC3704]とブラックリストおよびホワイトリストを採用して、アクセスポリシーを指定することでセキュリティを強化することもできます。たとえば、NAT64-CGNは、ストリクトモードまたはルーズモードでuRPFチェックに合格しない場合、または送信元IPv6アドレスがブラックリストに登録されている場合、着信IPv6パケットのNAT64 BIBの確立を禁止する必要があります。
Stateful NAT64-FE creates state and maps that connection to an internally facing IPv4 address and port. An attacker can consume the resources of the NAT64-FE device by sending an excessive number of connection attempts. Without a DDoS limitation mechanism, the NAT64-FE is exposed to attacks. The load balancer is recommended to enable the capabilities for line-rate DDOS defense, such as the employment of SYN proxy/cookie. In this case, division of the security domain is necessary as well. Therefore, load balancers could not only optimize the traffic distribution but also prevent service from quality deterioration due to security attacks.
ステートフルNAT64-FEは状態を作成し、その接続を内部に面したIPv4アドレスとポートにマップします。攻撃者は、過剰な数の接続試行を送信することにより、NAT64-FEデバイスのリソースを消費する可能性があります。 DDoS制限メカニズムがなければ、NAT64-FEは攻撃にさらされます。 SYNプロキシ/ Cookieの使用など、ラインレートのDDOS防御機能を有効にするには、ロードバランサーをお勧めします。この場合、セキュリティドメインの分割も必要です。したがって、ロードバランサーはトラフィックの分散を最適化するだけでなく、セキュリティ攻撃によるサービスの品質低下を防ぐことができます。
The DNS64 process will potentially interfere with the DNSSEC functions [RFC4035], since the DNS response is modified and DNSSEC intends to prevent such changes. More detailed discussions can be found in [RFC6147].
DNS64プロセスはDNSSEC機能[RFC4035]に干渉する可能性があります。これは、DNS応答が変更され、DNSSECがそのような変更を防止しようとするためです。より詳細な議論は[RFC6147]で見つけることができます。
The authors would like to thank Jari Arkko, Dan Wing, Remi Despres, Fred Baker, Hui Deng, Iljitsch van Beijnum, Philip Matthews, Randy Bush, Mikael Abrahamsson, Lorenzo Colitti, Sheng Jiang, Nick Heatley, Tim Chown, Gert Doering, and Simon Perreault for their helpful comments.
著者は、Jari Arkko、Dan Wing、Remi Despres、Fred Baker、Hui Deng、Iljitsch van Beijnum、Philip Matthews、Randy Bush、Mikael Abrahamsson、Lorenzo Colitti、Sheng Jiang、Nick Heatley、Tim Chown、Gert Doering、およびSimon Perreaultの役立つコメント。
Many thanks to Wesley George, Lee Howard, and Satoru Matsushima for their detailed reviews.
Wesley George、Lee Howard、松島悟の詳細なレビューに感謝します。
The authors especially thank Joel Jaeggli and Ray Hunter for their efforts and contributions on editing, which substantially improved the readability of the document.
執筆者は、特に、Joel Jaeggli氏とRay Hunter氏の編集への取り組みと貢献に感謝します。これにより、ドキュメントの可読性が大幅に向上しました。
Thanks to Cameron Byrne who was an active coauthor of some earlier draft versions of this document.
このドキュメントの以前のドラフトバージョンのいくつかの積極的な共著者であったCameron Byrneに感謝します。
The following individuals contributed extensively to the effort:
以下の個人は、努力に広範囲に貢献しました：
Qiong Sun China Telecom Room 708, No. 118, Xizhimennei Street Beijing 100035 P.R. China Phone: +86-10-58552936 EMail: sunqiong@ctbri.com.cn
Qiong Sun China Telecom Room 708、No. 118、Xizhimennei Street Beijing 100035 P.R. China電話：+ 86-10-58552936メール：sunqiong@ctbri.com.cn
QiBo Niu ZTE 50 RuanJian Road YuHua District, Nan Jing 210012 P.R. China EMail: niu.qibo@zte.com.cn
IUのQ IB ZT E 50 RuプレスJ Ian道路Yuh UA地区、南京210012 P.R.中国メール：牛.pacing @中特.com。Talent
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F。、およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、2004年3月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947] Kivinen、T.、Swander、B.、Huttunen、A。、およびV. Volpe、「IKEにおけるNATトラバーサルの交渉」、RFC 3947、2005年1月。
[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月。
[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月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、2005年10月。
[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月。
[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月。
[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月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards、R。、「Syslogプロトコル」、RFC 5424、2009年3月。
[RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, August 2009.
[RFC5580] Tschofenig、H.、Adrangi、F.、Jones、M.、Lior、A。、およびB. Aboba、「RADIUSおよびDiameterでのロケーションオブジェクトの持ち運び」、RFC 5580、2009年8月。
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009.
[RFC5722] Krishnan、S。、「Handling of Overlapping IPv6 Fragments」、RFC 5722、2009年12月。
[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
[RFC5798] Nadas、S。、「Virtual Router Redundancy Protocol（VRRP）Version 3 for IPv4 and IPv6」、RFC 5798、2010年3月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、2010年6月。
[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月。
[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 IPv4 Servers」、RFC 6147、2011年4月。
[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月。
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6555] Wing、D。およびA. Yourtchenko、「Happy Eyeballs：Success with Dual-Stack Hosts」、RFC 6555、2012年4月。
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724] Thaler、D.、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、2012年9月。
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[RFC6887] Wing、D.、Cheshire、S.、Boucadair、M.、Penno、R。、およびP. Selkirk、「Port Control Protocol（PCP）」、RFC 6887、2013年4月。
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 6946, May 2013.
[RFC6946] Gont、F。、「Processing of IPv6 "Atomic" Fragments」、RFC 6946、2013年5月。
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, November 2013.
[RFC7050] Savolainen、T.、Korhonen、J。、およびD. Wing、「IPv6アドレス合成に使用されるIPv6プレフィックスの発見」、RFC 7050、2013年11月。
[RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", RFC 7239, June 2014.
[RFC7239] Petersson、A。およびM. Nilsson、「Forwarded HTTP Extension」、RFC 7239、2014年6月。
[Alexa] Alexa, "Top 500 Global Sites", April 2013, <http://www.alexa.com/topsites>.
[Alexa] Alexa、「Top 500 Global Sites」、2013年4月、<http://www.alexa.com/topsites>。
[COEXIST] Kaliwoda, A. and D. Binet, "Co-existence of both dual-stack and IPv6-only hosts", Work in Progress, October 2012.
[共存] Kaliwoda、A。およびD. Binet、「デュアルスタックホストとIPv6のみのホストの共存」、Work in Progress、2012年10月。
[CONN-STATUS] Patil, P., Boucadair, M., Wing, D., and T. Reddy, "IP Connectivity Status Notifications for DHCPv6", Work in Progress, February 2014.
[CONN-STATUS] Patil、P.、Boucadair、M.、Wing、D。、およびT. Reddy、「DHCPv6のIP接続ステータス通知」、作業中、2014年2月。
[Cisco-VNI] Cisco, "Cisco VNI Global Mobile Data Traffic Forecast, 2012-2018", February 2014, <http://ciscovni.com/forecast-widget/index.html>.
[Cisco-VNI] Cisco、「Cisco VNI Global Mobile Data Traffic Forecast、2012-2018」、2014年2月、<http://ciscovni.com/forecast-widget/index.html>。
[DET-CGN] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., and O. Vautrin, "Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments", Work in Progress, January 2014.
[DET-CGN] Donley、C.、Grundemann、C.、Sarawat、V.、Sundaresan、K。、およびO. Vautrin、「決定的なアドレスマッピングによるキャリアグレードのNAT展開でのロギングの削減」、作業中、2014年1月。
[IR.92] Global System for Mobile Communications Association (GSMA), "IMS Profile for Voice and SMS Version 7.0", March 2013.
[IR.92] Global Systems for Mobile Communications Association（GSMA）、「IMS Profile for Voice and SMS Version 7.0」、2013年3月。
[MAP-DEPLOY] Qiong, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault, "Mapping of Address and Port (MAP) - Deployment Considerations", Work in Progress, April 2014.
[MAP-DEPLOY] Qiong、Q.、Chen、M.、Chen、G.、Tsou、T。、およびS. Perreault、「アドレスとポート（MAP）のマッピング-展開に関する考慮事項」、進行中の作業、2014年4月。
[MAP-T] Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", Work in Progress, February 2014.
[MAP-T] Li、X.、Bao、C.、Dec、W.、Troan、O.、Matsushima、S.、and T. Murakami、 "アドレスのマッピングとポートを使用した変換（MAP-T）"、進行中の作業、2014年2月。
[MOTIVATION] Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., Borges, I., and G. Chen, "Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions", Work in Progress, November 2012.
[MOTIVATION] Boucadair、M.、Matsushima、S.、Lee、Y.、Bonness、O.、Borges、I。、およびG. Chen、「Motorations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions」、Work in Progress 、2012年11月。
[NAT64-RADIUS] Chen, G. and D. Binet, "Radius Attributes for Stateful NAT64", Work in Progress, July 2013.
[NAT64-RADIUS]チェン、G、D。ビネット、「ステートフルNAT64の半径属性」、作業中、2013年7月。
[PORT-ALLOC] Chen, G., Tsou, T., Donley, C., and T. Taylor, "Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses", Work in Progress, April 2014.
[PORT-ALLOC] Chen、G.、Tsou、T.、Donley、C。、およびT. Taylor、「Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses」、Work in Progress、2014年4月。
[RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider Scenarios for IPv6 Deployment", RFC 6036, October 2010.
[RFC6036] Carpenter、B。およびS. Jiang、「IPv6展開のための新興サービスプロバイダーシナリオ」、RFC 6036、2010年10月。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.
[RFC6056] Larsen、M。およびF. Gont、「Recommendations for Transport-Protocol Port Randomization」、BCP 156、RFC 6056、2011年1月。
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011.
[RFC6092] Woodyatt、J。、「住宅用IPv6インターネットサービスを提供するための顧客宅内機器（CPE）における推奨される単純なセキュリティ機能」、RFC 6092、2011年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月。
[RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, August 2011.
[RFC6346]ブッシュR。、「IPv4アドレス不足に対するアドレスとポート（A + P）のアプローチ」、RFC 6346、2011年8月。
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012.
[RFC6459] Korhonen、J.、Soininen、J.、Patil、B.、Savolainen、T.、Bajko、G。、およびK. Iisakkila、「IPv6 in the 3rd Generation Partnership Project（3GPP）Evolved Packet System（EPS）」 、RFC 6459、2012年1月。
[RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", RFC 6586, April 2012.
[RFC6586] Arkko、J。およびA. Keranen、「Experiences from an IPv6-Only Network」、RFC 6586、2012年4月。
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013.
[RFC6877] Mawatari、M.、Kawashima、M.、and C. Byrne、 "464XLAT：Combination of Stateful and Stateless Translation"、RFC 6877、April 2013。
[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet Content Providers and Application Service Providers", RFC 6883, March 2013.
[RFC6883] Carpenter、B。およびS. Jiang、「インターネットコンテンツプロバイダーおよびアプリケーションサービスプロバイダーのためのIPv6ガイダンス」、RFC 6883、2013年3月。
[RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments", RFC 6967, June 2013.
[RFC6967] Boucadair、M.、Touch、J.、Levis、P。、およびR. Penno、「Analysis of Potential Solutions for Reving a Host Identifier（HOST_ID）in Shared Address Deployments」、RFC 6967、2013年6月。
[SIIT] Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data Centre Environments", Work in Progress, November 2012.
[SIIT]アンダーソン、T。、「IPv6データセンター環境におけるステートレスIP / ICMP変換」、進行中の作業、2012年11月。
[ULA-USAGE] Liu, B. and S. Jiang, "Recommendations of Using Unique Local Addresses", Work in Progress, February 2014.
[ULA-USAGE] Liu、B。、およびS. Jiang、「一意のローカルアドレスの使用に関する推奨事項」、進行中の作業、2014年2月。
We tested several application behaviors in a lab environment to evaluate the impact when a primary NAT64 is out of service. In this testing, participants were asked to connect an IPv6-only WiFi network using laptops, tablets, or mobile phones. NAT64 was deployed as the gateway to provide Internet service. The tested applications are shown in the table below. Cold Standby, Warm Standby, and Hot Standby were each tested. The participants may have experienced service interruption due to the NAT64 handover. Different interruption intervals were tested to gauge application behaviors. The results are shown below.
ラボ環境でいくつかのアプリケーションの動作をテストして、プライマリNAT64が停止したときの影響を評価しました。このテストでは、参加者はラップトップ、タブレット、または携帯電話を使用してIPv6のみのWiFiネットワークに接続するように求められました。 NAT64は、インターネットサービスを提供するゲートウェイとして導入されました。テストしたアプリケーションを下の表に示します。コールドスタンバイ、ウォームスタンバイ、ホットスタンバイがそれぞれテストされました。参加者は、NAT64ハンドオーバーのためにサービスが中断した可能性があります。アプリケーションの動作を測定するために、さまざまな中断間隔がテストされました。結果を以下に示します。
Table 2: The Acceptable Delay of Applications
表2：アプリケーションの許容遅延
+----------------+------------------------+-------------------------+
| Application | Acceptable Interrupt | Session Continuity |
| | Recovery | |
+----------------+------------------------+-------------------------+
| Web browsing | Maximum of 6 s | No |
+----------------+------------------------+-------------------------+
| HTTP streaming | Maximum of 10 s (cache)| Yes |
+----------------+------------------------+-------------------------+
| Games | 200-400 ms | Yes |
+----------------+------------------------+-------------------------+
|P2P file sharing| 10-16 s | Yes |
|and streaming | | |
+----------------+------------------------+-------------------------+
| Instant Message| 1 minute | Yes |
+----------------+------------------------+-------------------------+
| Email | 30 s | No |
+----------------+------------------------+-------------------------+
| Downloading | 1 minute | No |
+----------------+------------------------+-------------------------+
Authors' Addresses
著者のアドレス
Gang Chen China Mobile Xuanwumenxi Ave. No. 32 Xuanwu District Beijing 100053 P.R. China
ギャングチェンチャイナモバイルX uプレス5ドアave。no。32 X UA N地区なし北京100053 P.R.中国
EMail: chengang@chinamobile.com, phdgang@gmail.com
Zhen Cao China Mobile Xuanwumenxi Ave. No. 32 Xuanwu District Beijing 100053 P.R. China
ZおよびNC AOチャイナモバイルX uは5ドアave。no。32 X UA N no地区を押します北京100053 P.R.中国
EMail: caozhen@chinamobile.com, zehn.cao@gmail.com
Chongfeng Xie China Telecom Room 708, No. 118, Xizhimennei Street Beijing 100035 P.R. China
C Red Maple X IE China Telecom Room 708、no。118、inside street Beijing 100035 P.R. China
EMail: xiechf@ctbri.com.cn
David Binet France Telecom-Orange Rennes 35000 France
David Binet France Telecom-Orange Rennes 35000 France
EMail: david.binet@orange.com