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
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アドレスの枯渇が近づくにつれ、IPv6への移行の問題へのIPv4がより重要と少なく扱いやすいなります。デュアルスタック環境で使用されるホストベースの移行メカニズムは、すべての移行の要件を満たすことができません。ほとんどのエンドユーザーは、設定またはホストベースの移行メカニズムを維持するのに十分な専門家ではありません。キャリアグレード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移行へのIPv4の初期の段階でそのままレガシーISPネットワークの多くを残しながら、IPv4ホストのためのIPv6ホストとIPv4アクセスサービスのIPv6アクセスサービスを提供することができます。一人でCGNとは異なり、増分CGNもサポートしており、デュアルスタックまたはIPv6のみのISPのネットワークへのスムーズな移行を奨励しています。統合構成CGN装置および適応ホームゲートウェイ（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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
10年前に予測されたようにグローバルIPv6の展開は起こりませんでした。ネットワークプロバイダは、IPv4があった最初の移動をすることを躊躇しており、まだうまく機能しています。しかし、IPv4アドレスの枯渇が目前に迫っています。動的に更新されたIPv4アドレスは、レポート[IPUSAGE]この問題を解析しました。 IANAは、未割り当てアドレスプールの枯渇は、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).
また、NAT444 CGNや大規模NATと呼ばれるキャリアグレードNAT（CGN）[CGN-REQS]は、単独で使用する場合のIPv4操作上の問題を化合物が、IPv6への移行にはIPv4を奨励するために何もしません。 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と呼ばれるデュアルスタックライト[DS-LITE]は、移行をサポートしていCGNベースのソリューションですが、それはすぐにIPv6へのネットワークをアップグレードするISPが必要です。多くのISPは、最初のステップとして、これを行うことを躊躇します。理論的には、DS-Liteは、二重カプセル化（IPv4のインのIPv6インの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はなく、周りの他の方法に似ています。これは主にV6オーバーv4のトンネリング機能をV4-V4のNATを兼ね備えています。そのままレガシーのIPv4 ISPネットワークのほとんどを残しながら、IPv6対応のホストとIPv4ホストのIPv4アクセスサービスのIPv6アクセスサービスを提供することができます。グローバルIPv4のは全く対処して、この技術の導入は、従来のIPv4ホストには影響を与えません。これは、IPv6への移行はIPv4の初期段階に適しています。また、デュアルスタックまたは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アクセスサービスを提供し始めています。 IPv6移行へのIPv4の初期段階では、IPv4接続とトラフィックは、ほとんどのISPのネットワークのトラフィックの大半を表現していきます。 ISPは彼らのIPv4ネットワークへの変更を最小限にしたいと思います。 IPv6のみに全ISPのネットワークを切り替えは過激な戦略と考えられます。デュアルスタックに全ISPのネットワークを切り替えると、以下の基であるが、運用コストと複雑さを紹介しています。いくつかのISPが正常にデュアルスタックネットワークを展開しているものの、他の人は、IPv6での最初のステップとしてこれを行うことを好みません。しかし、彼らは現在、2つの緊急の圧力に直面している - アドレス共有のいくつかの方法を展開することで、IPv4アドレスの即時不足を補うためにとIPv6のアドレス空間とサービスの展開の使用を積極的に準備します。 2のうちの一つだけの圧力に直面してISPは（IPv6接続サービスを提供するために）CGN（IPv4アドレスの不足のため）、または6rdのいずれかを採用することができます。この文書に記載されたアプローチは、V6-V4オーバートンネリング技術とV4-V4 CGNを組み合わせることにより、同時にこれらの圧力の両方に対処することを意図しています。
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の相互通信に関する詳細については、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.
6rd [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に適しているであろう。議論を簡単にするために、我々は、6rdの使用を前提としています。
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が存在しない場合には、スタックは、単に通常のIPv4デフォルトルータになりますCGN、にパケットを転送します。 V4-V4のNATが有効になっている場合は、HGがCGN-スコープのIPv4アドレスにHG-スコーププライベート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は、6rdを使用して、例えば、CGNに向けて、新たなIPv4パケットを送信します。
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とCGNからカプセル化されたIPv6パケットからIPv4パケットは、翻訳又はデカプセル化格納されたマッピング情報に従ってと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は、パブリックIPv4アドレスにCGN-範囲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のデバイスが使用中のまま。それは今であるようにグローバルIPv4アドレスのいずれかを有するか、V4-V4 NATの背後に、図1の右下のボックスとして示される既存のIPv4ホストは、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は時々NAT64と呼ばれる、推奨のIPv4 / IPv6変換アルゴリズムを標準化することが期待されます。これは、以下に指定されています。
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]
O [RFC6052]の "IPv6は、IPv4 / IPv6の翻訳者のアドレス指定" 〇〇 "のIPv4 / IPv6変換のための枠組み" [RFC6144] "DNS64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレス変換のためのDNS拡張機能" [RFC6147]「IP / ICMP O翻訳アルゴリズム」[RFC6145] O "ステートフルNAT64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレスとプロトコル変換のIPv6からIPv4変換のためのFTP ALGの" o [RFC6146] "" [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からのアクセスを提供します。これは、任意の-to-anyの翻訳を提供していません。一つの結果は、ステートフルな翻訳を通してのIPv4サービスへのIPv6ドメイン利得のクライアントホストだけがアクセスという点です。別の結果は、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アドレスを持つシステムは、IPv4、任意の仮定とは違って、NAT、全体で到達可能であるという事実から、ローカルアドレスは、リモートピアとアプリケーションペイロード内のリテラル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を、と紹介してDNS名ではなくIPアドレスリテラルを使用して、一般的には依存しないネットワーク層でなければなりません。
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-の問題（例えば、スケーリング及びインバウンドトラフィックのための周知のポートをサポートすることの困難）のすべての問題を継承します。二重の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
インクリメンタルCGNのアプローチに純粋NAT444 CGNまたは6rdからの移行は簡単です。 HGとCGNデバイスとその場所を変更する必要はありません。唯一のソフトウェアアップグレードが必要な場合があります。理想的なモデルでもソフトウェアのアップグレードが必要ではないが、以下に説明します。デバイスの再構成は十分にあります。 NAT444 CGNは、現在のIPv4インフラストラクチャにおけるパブリックアドレス不足の問題を解決します。しかし、それは全くのIPv6の展開に向けて貢献していません。オーバーレイのIPv6サービスを提供しながら、増分CGNのアプローチは、NAT444 CGN機能を継承することができます。 6rdメカニズムも、この増分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は、デュアルスタックルーティングに移動することを好む場合は、デュアルながら直接前方次いでIPv6とIPv4の両方のトラフィックをネイティブIPv6ルータ広告（RA）またはDHCPv6のトラフィックを観察したとき、HGは、単にその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.
しかし、我々は、彼らがデュアルスタックルーティングを回避し、IPv4のみIPv6専用ルーティングへのルーティングから漸増的に移動しようとするので、ISPがここに増分CGNとして説明した手法を選択することが予想されます。この場合、増分CGNのアプローチのための理想的なモデルは、統合された構成CGN装置および適応HG装置のことです。統合されたCGN装置はNAT444 CGN、6rdルータ（または代替トンネリング機構）、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をポーリングします。 6rdが利用可能になったとき、例えば、純粋なIPv4のみのシナリオ（HGがIPv4のみのデフォルトルータとしてCGNを治療する）から出発して、HGは（稀ポーリングによって）発見であろう。ホームユーザーは、IPv6プレフィックスを取得します。後の段階で、HGは、DS-Liteのを含むIPv6サービスの利用可能性を発見するためにネイティブのIPv6ルートの通知メッセージやDHCPv6のメッセージの外観を観察します。したがって、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への新機能自体、ひいてはなし新しいセキュリティの考慮事項を導入しません。 6rdのためのセキュリティ問題は[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.
有益なコメントはフレッド・ベイカー、ダン・ウィング、フレッド・テンプリン、誠一川村、レミ・デプレ、ヤーノシュMohacsi、モハメドBoucadair、宮川晋、ジョエルJaeggli、ヤリArkko、ティムポーク、ショーン・ターナー、およびIETF V6OPSワーキンググループの他のメンバーによって作られました。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2529]カーペンター、B.及びC.チョン、 "明示的なトンネルなしでの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]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5569]デプレ、R.、 "IPv4の基盤のIPv6のRapid Deployment（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、 "IPv4の基盤のIPv6のRapid Deployment（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.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]ハイン、T.、 "NATの建築的意味"、RFC 2993、2000年11月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053]デュラン、A.、ファザーノ、P.、Guardini、I.、およびD.レント、 "IPv6のトンネルブローカー"、RFC 3053、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmarkと、E.とR.ギリガン、 "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]デClercq、J.、Ooms、D.、プレボ、S.、およびF.ルFaucheur、 "IPv6のプロバイダエッジルータを使用したIPv4 MPLS上のIPv6諸島接続（6PE）"、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]ヴァン・デ・ヴェルデ、G.、ハイン、T.、Droms、R.、大工、B.、およびE.クライン、 "IPv6のローカルネットワークの保護"、RFC 4864、2007年5月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890]デイヴィス、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.、パルタサラティ、M.、Savola、P.、およびH. Tschofenig、RFC 4891、2007年5月の "IPv6インIPv4トンネルを保護するためにIPsecを使用します"。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]テンプリン、F.、グリーソン、T.、およびD.ターラーは、 "イントラサイト自動トンネルは、プロトコル（ISATAP）をアドレス指定"、RFC 5214、2008年3月。
[RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", RFC 5558, February 2010.
[RFC5558]テンプリン、F.、エド。、 "仮想エンタープライズトラバーサル（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]バオ、C.、のHuitema、C.、Bagnulo、M.、Boucadair、M.、およびX.李、RFC 6052、2010年10月の "IPv6は、IPv4 / IPv6の翻訳者のアドレス指定"。
[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、RFC 6092、2011年1月J.、エド。、 "住宅IPv6インターネットサービスを提供するための顧客宅内機器（CPE）で推奨シンプルなセキュリティ機能"。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144]ベーカー、F.はLi、X.、バオ、C.、およびK.陰陽 "の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.、バオ、C.、およびF.ベイカー、 "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.、マシューズ、P.、およびI.バンBeijnum、 "ステートフルNAT64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレスとプロトコル変換"、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.、サリバン、A.、マシューズ、P.、およびI.バンBeijnum、 "DNS64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレス変換のためのDNS拡張機能"、RFC 6147、2011年4月。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6169]クリシュナン、S.、ターラー、D.、およびJ.ホーグランド、 "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.ベーカー、 "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]シン、H.、Beebee、W.、Donley、C.、スターク、B.、およびO. Troan、エド。、 "IPv6のカスタマーエッジルータのための基本要件"、RFC 6204、2011年4月。
[IPUSAGE] G. Huston, IPv4 Address Report, June 2011, http://www.potaroo.net/tools/ipv4/index.html.
[IPUSAGE] G.ヒューストン、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]デュラン、A.、Droms、R.、Woodyatt、J.、およびY.リー、 "デュアルスタックLiteのブロードバンドの展開に続いてIPv4の枯渇"、進歩、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]フォード、M.、Boucadair、M.、デュラン、A.、リーバイス、P.、およびP.ロバーツ、進歩、2011年3月に、作業 "IPアドレス共有の問題"。
[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]ペロー、S.、エド。、山形、I.、宮川、S.、中川、A.、およびH.芦田、 "IPアドレス共有スキームのための一般的な要件"、進歩、2011年3月に作業。
[FTP-ALG] van Beijnum, I., "An FTP ALG for IPv6-to-IPv4 Translation", Work in Progress, May 2011.
[FTP-ALG]バンBeijnum、I.、進歩、2011年5月における作業の "IPv6からIPv4変換のためのFTP ALG"。
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
シェン・ジャン華為技術有限会社Huawei社ビル、第3号Xinxi Rdを、シャンジ情報産業基地、HAI-ディアン地区北京100085中華人民共和国メール:. 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郭華為技術有限会社Huawei社ビル、第3号Xinxi Rdを、シャンジ情報産業基地、HAI-ディアン地区北京100085中華人民共和国メール:. 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ニュージーランドEメール：brian.e.carpenter@gmail.com