[要約] RFC 6264は、IPv6移行のための段階的なキャリアグレードNAT（CGN）に関する規格です。その目的は、IPv4アドレスの枯渇を解決し、IPv6への移行を支援することです。
Internet Engineering Task Force (IETF) S. Jiang
Request for Comments: 6264 D. Guo
Category: Informational Huawei
ISSN: 2070-1721 B. Carpenter
University of Auckland
June 2011
An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition
IPv6遷移のための増分キャリアグレードNAT（CGN）
Abstract
概要
Global IPv6 deployment was slower than originally expected. As IPv4 address exhaustion approaches, IPv4 to IPv6 transition issues become more critical and less tractable. Host-based transition mechanisms used in dual-stack environments cannot meet all transition requirements. Most end users are not sufficiently expert to configure or maintain host-based transition mechanisms. Carrier-Grade NAT (CGN) devices with integrated transition mechanisms can reduce the operational changes required during the IPv4 to IPv6 migration or coexistence period.
グローバルIPv6の展開は、当初予想されるよりも遅くなりました。IPv4が消耗に近づくと、IPv4からIPv6への移行の問題がより重要になり、扱いやすくなります。デュアルスタック環境で使用されるホストベースの遷移メカニズムは、すべての遷移要件を満たすことができません。ほとんどのエンドユーザーは、ホストベースのトランジションメカニズムを構成または維持するのに十分な専門家ではありません。統合された遷移メカニズムを備えたキャリアグレードNAT（CGN）デバイスは、IPv4からIPv6への移行または共存期間中に必要な運用変更を減らすことができます。
This document proposes an incremental CGN approach for IPv6 transition. It can provide IPv6 access services for IPv6 hosts and IPv4 access services for IPv4 hosts while leaving much of a legacy ISP network unchanged during the initial stage of IPv4 to IPv6 migration. Unlike CGN alone, incremental CGN also supports and encourages smooth transition towards dual-stack or IPv6-only ISP networks. An integrated configurable CGN device and an adaptive home gateway (HG) device are described. Both are reusable during different transition phases, avoiding multiple upgrades. This enables IPv6 migration to be incrementally achieved according to real user requirements.
このドキュメントは、IPv6遷移の増分CGNアプローチを提案しています。IPv6ホストのIPv6アクセスサービスとIPv4ホスト用のIPv4アクセスサービスを提供することができ、IPv4からIPv6移行の初期段階では、レガシーISPネットワークの多くを変更しません。CGNのみとは異なり、増分CGNはデュアルスタックまたはIPv6のみのISPネットワークへのスムーズな移行もサポートおよび促進します。統合された構成可能なCGNデバイスとAdaptive Home Gateway（HG）デバイスについて説明します。どちらも異なる移行フェーズで再利用可能であり、複数のアップグレードを回避します。これにより、IPv6の移行は、実際のユーザー要件に応じて徐々に達成できます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。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/rfc6264.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6264で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. An Incremental CGN Approach .....................................4
2.1. Incremental CGN Approach Overview ..........................4
2.2. Choice of Tunneling Technology .............................5
2.3. Behavior of Dual-Stack Home Gateway ........................6
2.4. Behavior of Dual-Stack CGN .................................6
2.5. Impact for Existing Hosts and Unchanged Networks ...........7
2.6. IPv4/IPv6 Intercommunication ...............................7
2.7. Discussion .................................................8
3. Smooth Transition towards IPv6 Infrastructure ...................8
4. Security Considerations ........................................10
5. Acknowledgements ...............................................10
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................11
Global IPv6 deployment did not happen as was forecast 10 years ago. Network providers were hesitant to make the first move while IPv4 was and is still working well. However, IPv4 address exhaustion is imminent. The dynamically updated IPv4 Address Report [IPUSAGE] has analyzed this issue. IANA unallocated address pool exhaustion occurred in February 2011, and at the time of publication, the site predicts imminent exhaustion for Regional Internet Registry (RIR) unallocated address pools. Based on this fact, the Internet industry appears to have reached consensus that global IPv6 deployment is inevitable and has to be done expeditiously.
グローバルIPv6の展開は、10年前に予測されていたようには発生しませんでした。ネットワークプロバイダーは、IPv4がそうであり、まだうまく機能している間に最初の動きをすることをためらっていました。ただし、IPv4アドレスの疲労は差し迫っています。動的に更新されたIPv4アドレスレポート[IPUSAGE]がこの問題を分析しました。IANA Unallocatedアドレスプールの疲労は2011年2月に発生し、出版時には、このサイトは地域のインターネットレジストリ（RIR）の未成年者の住所プールの差し迫った消耗を予測しています。この事実に基づいて、インターネット業界は、グローバルなIPv6の展開は避けられず、迅速に行う必要があるというコンセンサスに達したようです。
IPv4 to IPv6 transition issues therefore become more critical and complicated for the approaching global IPv6 deployment. Host-based transition mechanisms alone are not able to meet the requirements in all cases. Therefore, network-based supporting functions and/or new transition mechanisms with simple user-side operation are needed.
したがって、IPv4からIPv6への移行の問題は、グローバルIPv6の展開に近づくと、より重要で複雑になります。ホストベースの遷移メカニズムだけでは、すべての場合に要件を満たすことができません。したがって、ネットワークベースのサポート機能および/または単純なユーザー側の操作を備えた新しい遷移メカニズムが必要です。
Carrier-Grade NAT (CGN) [CGN-REQS], also called NAT444 CGN or Large Scale NAT, compounds IPv4 operational problems when used alone but does nothing to encourage IPv4 to IPv6 transition. Deployment of NAT444 CGN allows ISPs to delay the transition and therefore causes double transition costs (once to add CGN and again to support IPv6).
キャリアグレードNAT（CGN）[CGN-REQS]、NAT444 CGNまたは大規模NATとも呼ばれますが、単独で使用するとIPv4の動作上の問題を化合しますが、IPv4からIPv6への移行を促進するために何もしません。NAT444 CGNの展開により、ISPは遷移を遅らせることができ、したがって二重の遷移コストを引き起こします（CGNを追加し、再びIPv6をサポートするために再び追加します）。
CGN deployments that integrate multiple transition mechanisms can simplify the operation of end-user services during the IPv4 to IPv6 migration and coexistence periods. CGNs are deployed on the network side and managed/maintained by professionals. On the user side, new home gateway (HG) devices may be needed too. They may be provided by network providers, depending on the specific business model. Dual-stack lite [DS-LITE], also called DS-Lite, is a CGN-based solution that supports transition, but it requires the ISP to upgrade its network to IPv6 immediately. Many ISPs hesitate to do this as the first step. Theoretically, DS-Lite can be used with double encapsulation (IPv4-in-IPv6-in-IPv4), but this seems even less likely to be accepted by an ISP and is not discussed in this document.
複数の遷移メカニズムを統合するCGN展開は、IPv4からIPv6への移行および共存期間中のエンドユーザーサービスの動作を簡素化できます。CGNはネットワーク側に展開され、専門家によって管理/維持されます。ユーザー側では、新しいホームゲートウェイ（HG）デバイスも必要になる場合があります。特定のビジネスモデルに応じて、ネットワークプロバイダーによって提供される場合があります。DS-Liteとも呼ばれるデュアルスタックLite [DS-Lite]は、遷移をサポートするCGNベースのソリューションですが、ISPはネットワークをすぐにIPv6にアップグレードする必要があります。多くのISPは、これを最初のステップとして行うことをためらいます。理論的には、DS-LITEは二重カプセル化（IPv4-in-IPV6-in-IPV4）で使用できますが、これはISPによって受け入れられる可能性がさらに低く、このドキュメントでは説明されていません。
This document proposes an incremental CGN approach for IPv6 transition. It does not define any new protocols or mechanisms but describes how to combine existing proposals in an incremental deployment. The approach is similar to DS-Lite but the other way around. It mainly combines v4-v4 NAT with v6-over-v4 tunneling functions. It can provide IPv6 access services for IPv6-enabled hosts and IPv4 access services for IPv4 hosts while leaving most of legacy IPv4 ISP networks unchanged. The deployment of this technology does not affect legacy IPv4 hosts with global IPv4 addresses at all. It is suitable for the initial stage of IPv4 to IPv6 migration. It also supports transition towards dual-stack or IPv6-only ISP networks.
このドキュメントは、IPv6遷移の増分CGNアプローチを提案しています。新しいプロトコルやメカニズムを定義するものではなく、既存の提案を増分展開で組み合わせる方法について説明します。このアプローチはDS-Liteに似ていますが、逆です。主にV4-V4 NATとV6-Over-V4トンネル機能を組み合わせています。Legacy IPv4 ISPネットワークのほとんどを変更せずに、IPv6対応のホストにIPv6対応ホストとIPv4ホスト向けのIPv4アクセスサービスのIPv6アクセスサービスを提供できます。このテクノロジーの展開は、グローバルIPv4アドレスを持つLegacy IPv4ホストにはまったく影響しません。IPv4からIPv6への移行の初期段階に適しています。また、デュアルスタックまたはIPv6のみのISPネットワークへの移行もサポートしています。
A smooth transition mechanism is also described in this document. It introduces an integrated configurable CGN device and an adaptive HG device. Both CGN and HG are reusable devices during different transition periods, so they do not need to be replaced as the transition proceeds. This enables IPv6 migration to be incrementally achieved according to the real user requirements.
このドキュメントでは、スムーズな遷移メカニズムも説明されています。統合された構成可能なCGNデバイスと適応型HGデバイスを導入します。CGNとHGの両方は、さまざまな移行期間中に再利用可能なデバイスであるため、遷移が進行するにつれて交換する必要はありません。これにより、IPv6の移行は、実際のユーザー要件に応じて徐々に達成できます。
Today, most consumers primarily use IPv4. Network providers are starting to provide IPv6 access services for end users. At the initial stage of IPv4 to IPv6 migration, IPv4 connectivity and traffic would continue to represent the majority of traffic for most ISP networks. ISPs would like to minimize the changes to their IPv4 networks. Switching the whole ISP network into IPv6-only would be considered a radical strategy. Switching the whole ISP network to dual-stack is less radical but introduces operational costs and complications. Although some ISPs have successfully deployed dual-stack networks, others prefer not to do this as their first step in IPv6. However, they currently face two urgent pressures -- to compensate for an immediate shortage of IPv4 addresses by deploying some method of address sharing and to prepare actively for the use of deployment of IPv6 address space and services. ISPs facing only one pressure out of two could adopt either CGN (for shortage of IPv4 addresses) or 6rd (to provide IPv6 connectivity services). The approach described in this document is intended to address both of these pressures at the same time by combining v4-v4 CGN with v6-over-v4 tunneling technologies.
今日、ほとんどの消費者は主にIPv4を使用しています。ネットワークプロバイダーは、エンドユーザーにIPv6アクセスサービスを提供し始めています。IPv4からIPv6への移行の初期段階では、IPv4の接続とトラフィックは、ほとんどのISPネットワークのトラフィックの大部分を引き続き表し続けます。ISPは、IPv4ネットワークの変更を最小限に抑えたいと考えています。ISPネットワーク全体をIPv6のみに切り替えることは、急進的な戦略と見なされます。ISPネットワーク全体をデュアルスタックに切り替えることは根本的ではありませんが、運用コストと合併症を導入します。一部のISPはデュアルスタックネットワークの展開に正常に展開していますが、IPv6での最初のステップとしてこれを行わないことを好む人もいます。ただし、現在、彼らは2つの緊急の圧力に直面しています - アドレス共有の方法を展開することによりIPv4アドレスの即時不足を補償し、IPv6アドレススペースとサービスの展開の使用に積極的に準備します。2つのうち1つの圧力に直面しているISPは、CGN（IPv4アドレスの不足の場合）または6番目（IPv6接続サービスを提供するため）のいずれかを採用できます。このドキュメントで説明されているアプローチは、V4-V4 CGNとV6オーバー-V4トンネリング技術を組み合わせることにより、これらの両方の圧力に同時に対処することを目的としています。
The incremental CGN approach we propose is illustrated in the following figure.
提案する増分CGNアプローチは、次の図に示されています。
+-------------+
|IPv6 Internet|
+-------------+
|
+---------------+----------+
+-----+ +--+ | IPv4 ISP +--+--+ | +--------+
|v4/v6|---|DS|=======+============| CGN |-------+---| IPv4 |
|Host | |HG| | Network +-----+ | | |Internet|
+-----+ +--+ +----------------------+---+ +--------+
_ _ _ _ _ _ _ _ _ _ _ |
()_6_over_4_ _t_u_n_n_e_l_() +---------------------+
| Existing IPv4 hosts |
+---------------------+
Figure 1: Incremental CGN Approach with IPv4 ISP Network
図1：IPv4 ISPネットワークを使用した増分CGNアプローチ
DS HG = Dual-Stack Home Gateway (CPE - Customer Premises Equipment).
DS HG =デュアルスタックホームゲートウェイ（CPE-顧客施設機器）。
As shown in the figure above, the ISP has not significantly changed its IPv4 network. This approach enables IPv4 hosts to access the IPv4 Internet and IPv6 hosts to access the IPv6 Internet. A dual- stack host is treated as an IPv4 host when it uses IPv4 access service and as an IPv6 host when it uses an IPv6 access service. In order to enable IPv4 hosts to access the IPv6 Internet and IPv6 hosts to access IPv4 Internet, NAT64 can be integrated with the CGN; see Section 2.6 for details regarding IPv4/IPv6 intercommunication. The integration of such mechanisms is out of scope for this document.
上の図に示すように、ISPはIPv4ネットワークを大幅に変更していません。このアプローチにより、IPv4ホストはIPv4インターネットとIPv6ホストにアクセスしてIPv6インターネットにアクセスできます。デュアルスタックホストは、IPv4アクセスサービスを使用する場合はIPv4ホストとして、IPv6アクセスサービスを使用する場合はIPv6ホストとして扱われます。IPv4ホストがIPv6インターネットとIPv6ホストにアクセスできるようにIPv4インターネットにアクセスできるようにするために、NAT64はCGNと統合できます。IPv4/IPv6 Intercommunicationに関する詳細については、セクション2.6を参照してください。このようなメカニズムの統合は、このドキュメントの範囲外です。
Two types of devices need to be deployed in this approach: a dual-stack home gateway (HG) and a dual-stack CGN. The dual-stack home gateway integrates both IPv6 and IPv4 forwarding and v6-over-v4 tunneling functions. It should follow the requirements of [RFC6204], including IPv6 prefix delegation. It may also integrate v4-v4 NAT functionality. The dual-stack CGN integrates v6-over-v4 tunneling and v4-v4 CGN functions as well as standard IPv6 and IPv4 routing.
このアプローチでは、2種類のデバイスを展開する必要があります：デュアルスタックホームゲートウェイ（HG）とデュアルスタックCGN。デュアルスタックホームゲートウェイは、IPv6とIPv4の転送とV6オーバー-V4トンネル機能の両方を統合します。IPv6プレフィックス委任を含む[RFC6204]の要件に従う必要があります。また、V4-V4 NAT機能を統合することもできます。デュアルスタックCGNは、V6オーバー-V4トンネリングとV4-V4 CGN関数、および標準のIPv6およびIPv4ルーティングを統合します。
The approach does not require any new mechanisms for IP packet forwarding or encapsulation or decapsulation at tunnel endpoints. The following sections describe how the HG and the incremental CGN interact.
このアプローチでは、トンネルエンドポイントでのIPパケット転送またはカプセル化または脱カプセル化のための新しいメカニズムは必要ありません。次のセクションでは、HGと増分CGNがどのように相互作用するかについて説明します。
In principle, this model will work with any form of tunnel between the dual-stack HG and the dual-stack CGN. However, tunnels that require individual configuration are clearly undesirable because of their operational cost. Configured tunnels based directly on [RFC4213] are therefore not suitable. A tunnel broker according to [RFC3053] would also have high operational costs and be unsuitable for home users.
原則として、このモデルは、デュアルスタックHGとデュアルスタックCGNの間のあらゆる形態のトンネルで動作します。ただし、個々の構成を必要とするトンネルは、運用コストのために明らかに望ましくありません。したがって、[RFC4213]に直接基づいた構成トンネルは適していません。[RFC3053]によるトンネルブローカーも、運用コストが高く、ホームユーザーには適していません。
6rd [RFC5569, RFC5969] technology appears suitable to support v6-over-v4 tunneling with low operational cost. Generic Routing Encapsulation (GRE) [RFC2784] with an additional auto-configuration mechanism is also able to support v6-over-v4 tunneling. Other tunneling mechanisms such as 6over4 [RFC2529], 6to4 [RFC3056], the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214], or Virtual Enterprise Traversal (VET) [RFC5558] could be considered. If the ISP has an entirely MPLS infrastructure between the HG and the dual-stack CGN, it would also be possible to use a IPv6 Provider Edge (6PE) [RFC4798] tunnel directly over MPLS. This would, however, only be suitable for an advanced HG that is unlikely to be found as a consumer device and is not further discussed here. To simplify the discussion, we assume the use of 6rd.
第6 [RFC5569、RFC5969]テクノロジーは、低い運用コストでV6オーバー-V4トンネルをサポートするのに適していると思われます。追加の自動構成メカニズムを備えたジェネリックルーティングカプセル化（GRE）[RFC2784]は、V6オーバーV4トンネリングをサポートすることもできます。6OVER4 [RFC2529]、6TO4 [RFC3056]、敷地内自動トンネルアドレス指定プロトコル（ISATAP）[RFC5214]、または仮想エンタープライズトラバーサル（VET）[RFC5558]などのその他のトンネルメカニズムを考慮することができます。ISPがHGとデュアルスタックCGNの間に完全にMPLSインフラストラクチャを持っている場合、MPLSの上に直接IPv6プロバイダーエッジ（6PE）[RFC4798]トンネルを使用することも可能です。ただし、これは、消費者デバイスとして見られる可能性が低く、ここではこれ以上議論されていない高度なHGにのみ適しています。議論を簡素化するために、6番目の使用を想定しています。
When a dual-stack home gateway receives a data packet from a host, it will determine whether the packet is an IPv4 or IPv6 packet. The packet will be handled by an IPv4 or IPv6 stack as appropriate. For IPv4, and in the absence of v4-v4 NAT on the HG, the stack will simply forward the packet to the CGN, which will normally be the IPv4 default router. If v4-v4 NAT is enabled, the HG translates the packet source address from an HG-scope private IPv4 address into a CGN-scope IPv4 address, performs port mapping if needed, and then forwards the packet towards the CGN. The HG records the v4-v4 address and port mapping information for inbound packets, like any other NAT.
デュアルスタックホームゲートウェイがホストからデータパケットを受信すると、パケットがIPv4パケットかIPv6パケットかどうかが判断されます。パケットは、必要に応じてIPv4またはIPv6スタックによって処理されます。IPv4の場合、およびHGにV4-V4 NATがない場合、スタックはパケットをCGNに転送するだけで、通常はIPv4デフォルトルーターになります。V4-V4 NATが有効になっている場合、HGはHG-SCOPEプライベートIPv4アドレスからパケットソースアドレスをCGN-SCOPE IPv4アドレスに変換し、必要に応じてポートマッピングを実行し、パケットをCGNに転送します。HGは、他のNATと同様に、インバウンドパケットのV4-V4アドレスとポートマッピング情報を記録します。
For IPv6, the HG needs to encapsulate the data into an IPv4 tunnel packet, which has the dual-stack CGN as the IPv4 destination. The HG sends the new IPv4 packet towards the CGN, for example, using 6rd.
IPv6の場合、HGはデータをIPv4宛先としてデュアルスタックCGNを持つIPv4トンネルパケットにカプセル化する必要があります。HGは、たとえば6番目を使用して、新しいIPv4パケットをCGNに向けて送信します。
If the HG is linked to more than one CGN, it will record the mapping information between the tunnel and the source IPv6 address for inbound packets. Detailed considerations for the use of multiple CGNs by one HG are for further study.
HGが複数のCGNにリンクされている場合、インバウンドパケットのトンネルとソースIPv6アドレスの間のマッピング情報を記録します。1つのHGによる複数のCGNを使用するための詳細な考慮事項は、さらなる研究のためです。
IPv4 packets from the CGN and encapsulated IPv6 packets from the CGN will be translated or decapsulated according to the stored mapping information and forwarded to the customer side of the HG.
CGNからのIPv4パケットとCGNからのカプセル化されたIPv6パケットは、保存されたマッピング情報に従って翻訳または脱カプセル化され、HGの顧客側に転送されます。
When a dual-stack CGN receives an IPv4 data packet from a dual-stack home gateway, it will determine whether the packet is a normal IPv4 packet, which is non-encapsulated, or a v6-over-v4 tunnel packet addressed to a tunnel endpoint within the CGN. For a normal IPv4 packet, the CGN translates the packet source address from a CGN-scope IPv4 address into a public IPv4 address, performs port mapping if necessary, and then forwards it normally to the IPv4 Internet. The CGN records the v4-v4 address and port mapping information for inbound packets, just like a normal NAT does. For a v6-over-v4 tunnel packet, the tunnel endpoint within the CGN will decapsulate it into the original IPv6 packet and then forward it to the IPv6 Internet. The CGN records the mapping information between the tunnel and the source IPv6 address for inbound packets.
デュアルスタックCGNがデュアルスタックホームゲートウェイからIPv4データパケットを受信すると、パケットが非カプセル化されていない通常のIPv4パケットか、トンネルにアドレス指定されたV6オーバー-V4トンネルパケットであるかどうかが判断されます。CGN内のエンドポイント。通常のIPv4パケットの場合、CGNはパケットソースアドレスをCGN-SCOPE IPv4アドレスからパブリックIPv4アドレスに変換し、必要に応じてポートマッピングを実行し、通常はIPv4インターネットに転送します。CGNは、通常のNATのように、インバウンドパケットのV4-V4アドレスとポートマッピング情報を記録します。V6オーバー-V4トンネルパケットの場合、CGN内のトンネルエンドポイントは、それを元のIPv6パケットに脱カプセル化し、IPv6インターネットに転送します。CGNは、インバウンドパケットのトンネルとソースIPv6アドレスの間のマッピング情報を記録します。
Depending on the deployed location of the CGN, it may use a further v6-over-v4 tunnel to connect to the IPv6 Internet.
CGNの展開された場所によっては、IPv6インターネットに接続するためにさらにV6オーバー-V4トンネルを使用する場合があります。
Packets from the IPv4 Internet will be appropriately translated by the CGN and forwarded to the HG, and packets from the IPv6 Internet will be tunneled to the appropriate HG, using the stored mapping information as necessary.
IPv4インターネットのパケットはCGNによって適切に翻訳され、HGに転送され、IPv6インターネットのパケットは、必要に応じて保存されたマッピング情報を使用して適切なHGにトンネル化されます。
This approach does not affect the unchanged parts of ISP networks at all. Legacy IPv4 ISP networks and their IPv4 devices remain in use. The existing IPv4 hosts, shown as the lower right box in Figure 1, having either global IPv4 addresses or behind v4-v4 NAT, can connect to the IPv4 Internet as it is now. These hosts, if they are upgraded to become dual-stack hosts, can access the IPv6 Internet through the IPv4 ISP network by using IPv6-over-IPv4 tunnel technologies. (See Section 2.7 for a comment on MTU size.)
このアプローチは、ISPネットワークの変更されていない部分にまったく影響しません。レガシーIPv4 ISPネットワークとそのIPv4デバイスは引き続き使用されています。図1の右下のボックスとして表示される既存のIPv4ホストは、グローバルIPv4アドレスまたはV4-V4 NATの背後にあるもので、現在のようにIPv4インターネットに接続できます。これらのホストは、デュアルスタックホストにアップグレードされた場合、IPv6-over-IPv4トンネルテクノロジーを使用してIPv4 ISPネットワークを介してIPv6インターネットにアクセスできます。（MTUサイズに関するコメントについては、セクション2.7を参照してください。）
For obvious commercial reasons, IPv6-only public services are not expected as long as there is a significant IPv4-only customer base in the world. However, IPv4/IPv6 intercommunication may become an issue in many scenarios.
明らかな商業上の理由により、IPv6のみの公共サービスは、世界に重要なIPv4のみの顧客ベースがある限り、予想されません。ただし、IPv4/IPv6相互コミュニケーションは、多くのシナリオで問題になる可能性があります。
The IETF is expected to standardize a recommended IPv4/IPv6 translation algorithm, sometimes referred to as NAT64. It is specified in the following:
IETFは、推奨されるIPv4/IPv6翻訳アルゴリズムを標準化することが期待されています。これは、NAT64と呼ばれることもあります。以下で指定されています。
o "Framework for IPv4/IPv6 Translation" [RFC6144]
o "IPv6 Addressing of IPv4/IPv6 Translators" [RFC6052]
o "DNS64: DNS Extensions for Network Address Translation from IPv6
Clients to IPv4 Servers" [RFC6147]
o "IP/ICMP Translation Algorithm" [RFC6145]
o "Stateful NAT64: Network Address and Protocol Translation from
IPv6 Clients to IPv4 Servers" [RFC6146]
o "An FTP ALG for IPv6-to-IPv4 Translation" [FTP-ALG]
The service, as described in the IETF's "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment" [RFC6180], provides for stateless translation between hosts in an IPv4-only domain or hosts that offer an IPv4-only service and hosts with an IPv4-embedded IPv6 address in an IPv6-only domain. It additionally provides access from IPv6 hosts with general format addresses to hosts in an IPv4-only domain or hosts that offer an IPv4-only service. It does not provide any-to-any translation. One result is that client-only hosts in the IPv6 domain gain access to IPv4 services through stateful translation. Another result is that the IPv6 network operator has the option of moving servers into the IPv6-only domain while retaining accessibility for IPv4-only clients through stateless translation of an IPv4-embedded IPv6 address.
IETFの「IPv6展開中にIPv6遷移メカニズムを使用するためのガイドライン」[RFC6180]で説明されているように、このサービスは、IPv4のみのドメインのホストまたはIPv4のみのサービスを提供し、IPv4-でホストを提供するホストのホスト間のステートレス翻訳を提供します。IPv6のみのドメインに埋め込まれたIPv6アドレス。さらに、IPv4のみのドメインまたはIPv4のみのサービスを提供するホストのホストに一般的な形式アドレスを持つIPv6ホストからのアクセスを提供します。それは何の翻訳からではありません。結果の1つは、IPv6ドメインのクライアントのみのホストが、ステートフルな翻訳を通じてIPv4サービスにアクセスできることです。別の結果は、IPv6ネットワークオペレーターには、IPv4のみのIPv6アドレスのステートレス翻訳を通じてIPv4のみのクライアントのアクセシビリティを保持しながら、サーバーをIPv6のみのドメインに移動するオプションがあることです。
Also, "Architectural Implications of NAT" [RFC2993] applies across the service just as in IPv4/IPv4 translation: apart from the fact that a system with an IPv4-embedded IPv6 address is reachable across the NAT, which is unlike IPv4, any assumption on the application's part that a local address is meaningful to a remote peer and any use of an IP address literal in the application payload is a source of service issues. In general, the recommended mitigation for this is as follows:
また、「NATのアーキテクチャの意味」[RFC2993]は、IPv4/IPv4翻訳と同様にサービス全体に適用されます。IPv4-埋め込まれたIPv6アドレスを持つシステムがNAT全体で到達可能であるという事実とは別に、IPv4とは異なります。アプリケーションの部分では、ローカルアドレスはリモートピアにとって意味があり、アプリケーションのペイロードで文字通りのIPアドレスの使用はサービスの問題の源です。一般に、これについて推奨される緩和は次のとおりです。
o Ideally, applications should use DNS names rather than IP address literals in URLs, URIs, and referrals, and in general be network layer agnostic.
o 理想的には、アプリケーションは、URL、URI、紹介のIPアドレスリテラルではなく、DNS名を使用し、一般にネットワークレイヤーに不可知論される必要があります。
o If they do not, the network may provide a relay or proxy that straddles the domains. For example, an SMTP Mail Transfer Agent (MTA) with both IPv4 and IPv6 connectivity handles IPv4/IPv6 translation cleanly at the application layer.
o そうでない場合、ネットワークはドメインにまたがるリレーまたはプロキシを提供する場合があります。たとえば、IPv4とIPv6接続の両方を備えたSMTPメール転送エージェント（MTA）は、アプリケーションレイヤーでIPv4/IPv6翻訳をきれいに処理します。
For IPv4 traffic, the incremental CGN approach inherits all the problems of CGN address-sharing techniques [ADDR-ISSUES] (e.g., scaling and the difficulty of supporting well-known ports for inbound traffic). Application-layer problems created by double NAT are beyond the scope of this document.
IPv4トラフィックの場合、増分CGNアプローチは、CGNアドレス共有技術のすべての問題を継承します[Addr-Issues]（たとえば、スケーリングとインバウンドトラフィックの有名なポートをサポートすることの難しさ）。Double NATによって作成されたアプリケーション層の問題は、このドキュメントの範囲を超えています。
For IPv6 traffic, a user behind the DS HG will see normal IPv6 service. We observe that an IPv6 tunnel MTU of at least 1500 bytes would ensure that the mechanism does not cause excessive fragmentation of IPv6 traffic or excessive IPv6 path MTU discovery interactions. This, and the absence of NAT problems for IPv6, will create an incentive for users and application service providers to prefer IPv6.
IPv6トラフィックの場合、DS HGの背後にあるユーザーには通常のIPv6サービスが表示されます。少なくとも1500バイトのIPv6トンネルMTUは、メカニズムがIPv6トラフィックの過度の断片化や過度のIPv6パスMTU発見相互作用を引き起こさないことを保証することがわかります。これ、およびIPv6にNATの問題がないため、ユーザーとアプリケーションサービスプロバイダーがIPv6を好むインセンティブが作成されます。
ICMP filtering [RFC4890] may be included as part of CGN functions.
ICMPフィルタリング[RFC4890]は、CGN関数の一部として含まれる場合があります。
Transition from pure NAT444 CGN or 6rd to the incremental CGN approach is straightforward. The HG and CGN devices and their locations do not have to be changed; only software upgrading may be needed. In the ideal model, described below, even software upgrading is not necessary; reconfiguration of the devices is enough. NAT444 CGN solves the public address shortage issues in the current IPv4 infrastructure. However, it does not contribute towards IPv6 deployment at all. The incremental CGN approach can inherit NAT444 CGN functions while providing overlay IPv6 services. 6rd mechanisms can also transform smoothly into this incremental CGN model. However, the home gateways need to be upgraded correspondingly to perform the steps described below
純粋なNAT444 CGNまたは6RDから増分CGNアプローチへの移行は簡単です。HGおよびCGNデバイスとその場所を変更する必要はありません。ソフトウェアアップグレードのみが必要になる場合があります。以下で説明する理想的なモデルでは、ソフトウェアのアップグレードさえも必要ありません。デバイスの再構成で十分です。NAT444 CGNは、現在のIPv4インフラストラクチャのパブリックアドレス不足の問題を解決します。ただし、IPv6の展開にはまったく貢献していません。増分CGNアプローチは、オーバーレイIPv6サービスを提供しながら、NAT444 CGN関数を継承できます。6番目のメカニズムは、この増分CGNモデルにスムーズに変換することもできます。ただし、以下に説明する手順を実行するには、ホームゲートウェイをアップグレードする必要があります
The incremental CGN can also easily be transitioned to an IPv6- enabled infrastructure, in which the ISP network is either dual-stack or IPv6-only.
増分CGNは、ISPネットワークがデュアルスタックまたはIPv6のみのいずれかであるIPv6-有効なインフラストラクチャに簡単に移行できます。
If the ISP prefers to move to dual-stack routing, the HG should simply switch off its v6-over-v4 function when it observes native IPv6 Router Advertisement (RA) or DHCPv6 traffic and then forward both IPv6 and IPv4 traffic directly while the dual-stack CGN keeps only its v4-v4 NAT function.
ISPがデュアルスタックルーティングに移動することを好む場合、HGはネイティブIPv6ルーター広告（RA）またはDHCPV6トラフィックを観察し、次にIPv6とIPv4トラフィックの両方を直接転送し、デュアルを直接転送するときに、V6オーバー-V4関数を単純に切り替える必要があります-Stack CGNは、V4-V4 NAT機能のみを保持します。
However, we expect ISPs to choose the approach described as incremental CGN here because they intend to avoid dual-stack routing and to move incrementally from IPv4-only routing to IPv6-only routing. In this case, the ideal model for the incremental CGN approach is that of an integrated configurable CGN device and an adaptive HG device. The integrated CGN device will be able to support multiple functions, including NAT444 CGN, 6rd router (or an alternative tunneling mechanism), DS-Lite, and dual-stack forwarding.
ただし、Dual Stackルーティングを回避し、IPv4のみのルーティングからIPv6のみのルーティングに漸進的に移動する予定であるため、ISPはここではインクリメンタルCGNとして説明されているアプローチを選択すると予想されます。この場合、インクリメンタルCGNアプローチの理想的なモデルは、統合された構成可能なCGNデバイスと適応型HGデバイスのモデルです。統合されたCGNデバイスは、NAT444 CGN、第6ルーター（または代替トンネルメカニズム）、DS-LITE、およびデュアルスタック転送など、複数の機能をサポートできます。
The HG has to integrate the corresponding functions and be able to detect relevant incremental changes on the CGN side. Typically, the HG will occasionally poll the CGN to discover which features are operational. For example, starting from a pure IPv4-only scenario (in which the HG treats the CGN only as an IPv4 default router), the HG would discover (by infrequent polling) when 6rd became available. The home user would then acquire an IPv6 prefix. At a later stage, the HG would observe the appearance of native IPv6 Route Advertisement messages or DHCPv6 messages to discover the availability of an IPv6 service including DS-Lite. Thus, when an ISP decides to switch from incremental CGN to DS-Lite CGN, only a configuration change or a minor software update is needed on the CGNs. The home gateway would detect this change and switch automatically to DS-Lite mode. The only impact on the home user will be to receive a different IPv6 prefix.
HGは、対応する関数を統合し、CGN側の関連する増分変化を検出できる必要があります。通常、HGはCGNを時々投票して、どの機能が動作しているかを発見します。たとえば、純粋なIPv4のみのシナリオ（HGがCGNをIPv4デフォルトルーターとしてのみ扱う）から始めて、HGは6RDが利用可能になったときに（まれなポーリングにより）発見されます。ホームユーザーはIPv6プレフィックスを取得します。後の段階では、HGはネイティブIPv6ルート広告メッセージまたはDHCPV6メッセージの外観を観察して、DS-Liteを含むIPv6サービスの可用性を発見します。したがって、ISPが増分CGNからDS-LITE CGNに切り替えることを決定した場合、CGNでは構成変更またはマイナーなソフトウェアアップデートのみが必要です。ホームゲートウェイはこの変更を検出し、DS-Liteモードに自動的に切り替えます。ホームユーザーへの唯一の影響は、別のIPv6プレフィックスを受信することです。
In the smooth transition model, both CGN and HG are reusable devices during different transition periods. This avoids potential multiple upgrades. Different regions of the same ISP network may be at different stages of the incremental process, using identical equipment but with different configurations of the incremental CGN devices in each region. Thus, IPv6 migration may be incrementally achieved according to the real ISP and customer requirements.
スムーズな遷移モデルでは、CGNとHGの両方が異なる遷移期間中に再利用可能なデバイスです。これにより、潜在的な複数のアップグレードが回避されます。同じISPネットワークの異なる領域は、同一の機器を使用して、各領域の増分CGNデバイスの異なる構成を使用して、増分プロセスの異なる段階にある場合があります。したがって、IPv6の移行は、実際のISPおよび顧客の要件に従って徐々に達成される場合があります。
Security issues associated with NAT have been documented in [RFC2663] and [RFC2993]. Security issues for large-scale address sharing, including CGN, are discussed in [ADDR-ISSUES]. The present specification does not introduce any new features to CGN itself and hence no new security considerations. Security issues for 6rd are documented in [RFC5569] and [RFC5969], and those for DS-Lite are discussed in [DS-LITE].
NATに関連するセキュリティの問題は、[RFC2663]および[RFC2993]で文書化されています。CGNを含む大規模な住所共有のセキュリティ問題については、[addr-issues]で議論されています。現在の仕様では、CGN自体に新しい機能を導入していないため、新しいセキュリティ上の考慮事項はありません。6番目のセキュリティ問題は[RFC5569]および[RFC5969]で文書化されており、DS-Liteの問題は[DS-Lite]で説明されています。
Since the tunnels proposed here exist entirely within a single ISP network between the HG/CPE and the CGN, the threat model is relatively simple. [RFC4891] describes how to protect tunnels using IPsec, but an ISP could reasonably deem its infrastructure to provide adequate security without the additional protection and overhead of IPsec. The intrinsic risks of tunnels are described in [RFC6169], which recommends that tunneled traffic should not cross border routers. The incremental CGN approach respects this recommendation. To avoid other risks caused by tunnels, it is important that any security mechanisms based on packet inspection and any implementation of ingress filtering are applied to IPv6 packets after they have been decapsulated by the CGN. The dual-stack home gateway will need to provide basic security functionality for IPv6 [RFC6092]. Other aspects are described in [RFC4864].
ここで提案されているトンネルは、HG/CPEとCGNの間の単一のISPネットワーク内に完全に存在するため、脅威モデルは比較的単純です。[RFC4891]は、IPSECを使用してトンネルを保護する方法を説明していますが、ISPはIPSECの追加保護とオーバーヘッドなしで適切なセキュリティを提供するためにインフラストラクチャを合理的に考えることができます。トンネルの固有のリスクは[RFC6169]に記載されており、トンネルトラフィックは境界線ルーターを渡るべきではないことを推奨しています。増分CGNアプローチは、この推奨事項を尊重します。トンネルによって引き起こされる他のリスクを回避するために、パケット検査とイングレスフィルタリングの実装に基づくセキュリティメカニズムが、CGNによって脱カプセル化された後にIPv6パケットに適用されることが重要です。デュアルスタックホームゲートウェイは、IPv6 [RFC6092]に基本的なセキュリティ機能を提供する必要があります。他の側面は[RFC4864]で説明されています。
Useful comments were made by Fred Baker, Dan Wing, Fred Templin, Seiichi Kawamura, Remi Despres, Janos Mohacsi, Mohamed Boucadair, Shin Miyakawa, Joel Jaeggli, Jari Arkko, Tim Polk, Sean Turner, and other members of the IETF V6OPS working group.
有用なコメントは、フレッド・ベイカー、ダン・ウィング、フレッド・テンプリン、川村側、レミ・デスプレス、ヤノス・モハクシ、モハメド・ブーカデア、シン・ミヤカワ、ジョエル・ジェグリ、ジャリ・アークコ、ティム・ポーク、ショーン・ターナー、その他のIETF V6OPSワーキンググループのメンバー。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2529] Carpenter、B。およびC. Jung、「明示的なトンネルなしのIPv4ドメイン上のIPv6の伝達」、RFC 2529、1999年3月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「一般的なルーティングカプセル化（GRE）」、RFC 2784、2000年3月。
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5569] DESPRES、R。、「IPv4インフラストラクチャのIPv6迅速な展開（6rd）」、RFC 5569、2010年1月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969] Townsley、W.およびO. Troan、「IPv6インフラストラクチャのIPv6迅速な展開（6rd） - プロトコル仕様」、RFC 5969、2010年8月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993] Hain、T。、「Natの建築的意味」、RFC 2993、2000年11月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053] Durand、A.、Fasano、P.、Guardini、I。、およびD. Lento、「IPv6 Tunnel Broker」、RFC 3053、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
[RFC4798] de Clercq、J.、Ooms、D.、Prevost、S。、およびF. Le Faucheur、「IPv6プロバイダーエッジルーター（6PE）を使用してIPv4 MPLSを介してIPv6島を接続する」、RFC 4798、2007年2月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864] van de Velde、G.、Hain、T.、Droms、R.、Carpenter、B。、およびE. Klein、「IPv6のローカルネットワーク保護」、RFC 4864、2007年5月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890] Davies、E。およびJ. Mohacsi、「ファイアウォールでICMPV6メッセージをフィルタリングするための推奨」、RFC 4890、2007年5月。
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", RFC 4891, May 2007.
[RFC4891] Graveman、R.、Parthasarathy、M.、Savola、P。、およびH. Tschofenig、「IPSECを使用してIPv6-in-IPV4トンネルを保護する」、RFC 4891、2007年5月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214] Templin、F.、Gleeson、T。、およびD. Thaler、「敷地内自動トンネルアドレス指定プロトコル（ISATAP）」、RFC 5214、2008年3月。
[RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", RFC 5558, February 2010.
[RFC5558] Templin、F.、ed。、「Virtual Enterprise Traversal（VET）」、RFC 5558、2010年2月。
[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翻訳者のアドレス指定」、RFC 6052、2010年10月。
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011.
[RFC6092] Woodyatt、J.、ed。、「住宅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、「IPv4/IPv6翻訳のフレームワーク」、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：IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳」、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：IPv6クライアントからIPv4サーバーへのネットワークアドレス変換のDNS拡張"、RFC 6147、2011年4月。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6169] Krishnan、S.、Thaler、D。、およびJ. Hoagland、「IPトンネリングに関するセキュリティ上の懸念」、RFC 6169、2011年4月。
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", RFC 6180, May 2011.
[RFC6180] Arkko、J。およびF. Baker、「IPv6展開中にIPv6遷移メカニズムを使用するためのガイドライン」、RFC 6180、2011年5月。
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, Ed., "Basic Requirements for IPv6 Customer Edge Routers", RFC 6204, April 2011.
[RFC6204] Singh、H.、Beebee、W.、Donley、C.、Stark、B。、およびO. Troan、ed。、「IPv6 Customer Edge Routersの基本要件」、RFC 6204、2011年4月。
[IPUSAGE] G. Huston, IPv4 Address Report, June 2011, http://www.potaroo.net/tools/ipv4/index.html.
[IPUSAGE] G. Huston、IPv4アドレスレポート、2011年6月、http：//www.potaroo.net/tools/ipv4/index.html。
[DS-LITE] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", Work in Progress, May 2011.
[DS-Lite] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4疲労後のデュアルスタックLiteブロードバンド展開」、2011年5月の進行中。
[ADDR-ISSUES] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", Work in Progress, March 2011.
[Addr-Issues] Ford、M.、Boucadair、M.、Durand、A.、Levis、P。、およびP. Roberts、「IPアドレス共有の問題」、2011年3月、進行中。
[CGN-REQS] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for IP address sharing schemes", Work in Progress, March 2011.
[CGN-Reqs] Perreault、S.、ed。、Yamagata、I.、Miyakawa、S.、Nakagawa、A。、およびH. Ashida、「IPアドレス共有スキームの共通要件」、2011年3月進行中。
[FTP-ALG] van Beijnum, I., "An FTP ALG for IPv6-to-IPv4 Translation", Work in Progress, May 2011.
[FTP-Alg] Van Beijnum、I。、「IPv6-to-IPV4翻訳のFTPアルグ」、2011年5月の作業。
Authors' Addresses
著者のアドレス
Sheng Jiang Huawei Technologies Co., Ltd Huawei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District Beijing 100085 P.R. China EMail: jiangsheng@huawei.com
Sheng Jiang Huawei Technologies Co.、Ltd Huawei Building、No.3 Xinxi Rd。、Shang-Di Information Industry Base、Hai-Dian District Beijing 100085 P.R. China Email：jiangsheng@huawei.com
Dayong Guo Huawei Technologies Co., Ltd Huawei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District Beijing 100085 P.R. China EMail: guoseu@huawei.com
Dayong Guo Huawei Technologies Co.、Ltd Huawei Building、No.3 Xinxi Rd。、Shang-Di Information Industry Base、Hai-Dian District Beijing 100085 P.R. China Email：Guoseu@huawei.com
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand EMail: brian.e.carpenter@gmail.com
ブライアンカーペンターコンピュータサイエンス大学オークランドPB 92019オークランド、1142ニュージーランドメール：brian.e.carpenter@gmail.com