Internet Engineering Task Force (IETF) J. Arkko
Request for Comments: 6127 Ericsson
Category: Informational M. Townsley
ISSN: 2070-1721 Cisco
May 2011
IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios
Abstract
抽象
When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition.
IPv6が設計された場合には、IPv4からIPv6への移行がより円滑かつ迅速に経験が明らかになったよりも起こることが予想されました。予見可能な地平線上のIPv4インターネットの成長とIPv4アドレスブロックの空きプールの予測枯渇は、IPv6の展開モデルを再検討する緊急の必要性を強調しました。この文書では、産業界は、IPv4とIPv6の共存と移行を支援する必要がある追加ツールの種類を理解するために助けを目標に展開シナリオの概要を説明します。
This document was originally created as input to the Montreal co-existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 co-existence work. This document is published as a historical record of the thinking at the time, but hopefully will also help readers understand the rationale behind current IETF tools for co-existence and transition.
この文書は、もともと新しいIPv4とIPv6の共存の仕事を取るために動作し、Softwireワーキンググループのrecharteringにつながった、2008年10月にモントリオール共存中間会合への入力として作成されました。この文書では、一度に思考の歴史的な記録として公開されていますが、うまくいけば、また読者は共存と移行のための現在のIETFのツールの背後にある理論的根拠を理解するのに役立ちます。
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/rfc6127.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6127で取得することができます。
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. Scenarios .......................................................4
2.1. Reaching the IPv4 Internet .................................4
2.1.1. NAT444 ..............................................5
2.1.2. Distributed NAT .....................................6
2.1.3. Recommendation ......................................8
2.2. Running Out of IPv4 Private Address Space ..................9
2.3. Enterprise IPv6-Only Networks .............................11
2.4. Reaching Private IPv4-Only Servers ........................13
2.5. Reaching IPv6-Only Servers ................................14
3. Security Considerations ........................................16
4. Conclusions ....................................................16
5. References .....................................................17
5.1. Normative References ......................................17
5.2. Informative References ....................................17
Appendix A. Acknowledgments .......................................20
This document was originally created as input to the Montreal co-existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 co-existence work. This document is published as a historical record of the thinking at the time, but hopefully will also help readers understand the rationale behind current IETF tools for co-existence and transition.
この文書は、もともと新しいIPv4とIPv6の共存の仕事を取るために動作し、Softwireワーキンググループのrecharteringにつながった、2008年10月にモントリオール共存中間会合への入力として作成されました。この文書では、一度に思考の歴史的な記録として公開されていますが、うまくいけば、また読者は共存と移行のための現在のIETFのツールの背後にある理論的根拠を理解するのに役立ちます。
When IPv6 was designed, it was expected that IPv6 would be enabled, in part or in whole, while continuing to run IPv4 side-by-side on the same network nodes and hosts. This method of transition is referred to as "dual-stack" [RFC4213] and has been the prevailing method driving the specifications and available tools for IPv6 to date.
IPv6が設計された場合には、同一のネットワーク・ノードとホストにIPv4のサイドバイサイドを実行し続けながらIPv6は、部分的に又は全体的に、有効にすることが期待されました。遷移のこの方法は、「デュアルスタック」[RFC4213]と呼ばれ、今日までIPv6の仕様と利用可能なツールを駆動優勢方法でした。
Experience has shown that large-scale deployment of IPv6 takes time, effort, and significant investment. With IPv4 address pool depletion on the foreseeable horizon [HUSTON-IPv4], network operators and Internet Service Providers are being forced to consider network designs that no longer assume the same level of access to unique global IPv4 addresses. IPv6 alone does not alleviate this concern given the basic assumption that all hosts and nodes will be dual-stack until the eventual sunsetting of IPv4-only equipment. In short, the time-frames for the growth of the IPv4 Internet, the universal deployment of dual-stack IPv4 and IPv6, and the final transition to an IPv6-dominant Internet are not in alignment with what was originally expected.
経験は、IPv6の大規模な展開は、時間、労力、多額の投資を要することが示されています。予見可能な地平線上のIPv4アドレスプールの枯渇と[HUSTON-のIPv4]、ネットワーク事業者やインターネットサービスプロバイダは、もはや独自のグローバルIPv4アドレスへのアクセスの同じレベルを負いませんネットワーク設計を検討することを余儀なくされています。 IPv6は一人ですべてのホストおよびノードがIPv4のみの機器の最終的sunsettingまで、デュアルスタックとなることを基本的な前提を与えられたこの懸念を軽減しません。要するに、IPv4インターネットの成長、デュアルスタックIPv4とIPv6の普遍的展開、およびIPv6-支配的なインターネットへの最終的な移行のための時間枠は、当初の予想されたものと整合していません。
While dual-stack remains the most well-understood approach to deploying IPv6 today, current realities dictate a re-assessment of the tools available for other deployment models that are likely to emerge. In particular, the implications of deploying multiple layers of IPv4 address translation need to be considered, as well as those associated with translation between IPv4 and IPv6, which led to the deprecation of [RFC2766] as detailed in [RFC4966]. This document outlines some of the scenarios where these address and protocol translation mechanisms could be useful, in addition to methods where carrying IPv4 over IPv6 may be used to assist in transition to IPv6 and co-existence with IPv4. We purposefully avoid a description of classic dual-stack methods, as well as IPv6-over-IPv4 tunneling. Instead, this document focuses on scenarios that are driving tools we have historically not been developing standard solutions around.
デュアルスタックは、今日のIPv6の展開に最もよく理解されたアプローチのまま、現在の現実が出現する可能性がある他の展開モデルのために利用可能なツールの再評価を指示します。具体的には、IPv4アドレス変換の複数の層を展開する影響を考慮する必要があり、同様に[RFC4966]に詳述されるように[RFC2766]の廃止につながったIPv4とIPv6との間の変換、に関連するもの。この文書は、IPv4とIPv6への移行と共存するのを補助するために使用することができるこれらのアドレスおよびプロトコル変換メカニズムは、IPv6上のIPv4を運ぶ方法に加えて、有用であり得るシナリオのいくつかを概説します。我々は、古典的なデュアルスタック方式の説明と同様に、IPv6のオーバーIPv4トンネリングを意図的に避けてください。代わりに、この文書では、我々は歴史的に周りの標準ソリューションを開発していないツールを運転しているシナリオに焦点を当てています。
It should be understood that the scenarios in this document represent new deployment models and are intended to complement, and not replace, existing ones. For instance, dual-stack continues to be the most recommended deployment model. Note that dual-stack is not limited to situations where all hosts can acquire public IPv4 addresses. A common deployment scenario is running dual-stack on the IPv6 side with public addresses, and on the IPv4 side with just one public address and a traditional IPv4 NAT. Generally speaking, offering native connectivity with both IP versions is preferred over the use of translation or tunneling mechanisms when sufficient address space is available.
この文書のシナリオは、既存のものを新しい展開モデルを表現し、補完することを意図している、と交換しないでいることを理解すべきです。例えば、デュアルスタックは、最も推奨される展開モデルであり続けています。デュアルスタックは、すべてのホストがパブリックIPv4アドレスを取得できる状況に限定されるものではないことに注意してください。一般的な展開シナリオは、ちょうど1パブリックアドレスと従来のIPv4 NATとパブリックアドレスを持つ、とIPv4側でのIPv6側にデュアルスタックを実行しています。一般的には十分なアドレス空間が利用可能であるとき、翻訳やトンネリング機構の使用よりも好ましい両方のIPバージョンでネイティブ接続を提供し、話します。
This section identifies five deployment scenarios that we believe have a significant level of near-to-medium-term demand somewhere on the globe. We will discuss these in the following sections, while walking through a bit of the design space to get an understanding of the types of tools that could be developed to solve each. In particular, we want the reader to consider for each scenario what type of new equipment must be introduced in the network, and where; which nodes must be changed in some way; and which nodes must work together in an interoperable manner via a new or existing protocol.
このセクションでは、私たちがどこかに地球上の近くツー中期需要の大幅なレベルを持っていると信じて5つの展開シナリオを特定します。それぞれを解決するために開発できるツールの種類の理解を得るために設計空間のビットを歩いている間私たちは、次のセクションでは、これらについて説明します。特に、我々は読者がそれぞれのネットワークに導入されなければならない新しい機器のどのような種類のシナリオ、そしてどこのために考慮したいです。どのノードが何らかの方法で変更する必要があります。ノードは、新規または既存のプロトコルを介して相互運用可能な方法で一緒に動作しなければなりません。
The five scenarios are:
5つのシナリオは以下のとおりです。
o Reaching the IPv4 Internet with less than one global IPv4 address per subscriber or subscriber household available (Section 2.1).
利用できる加入者または加入者世帯当たり未満のグローバルIPv4アドレス（2.1節）でIPv4インターネットに達するO。
o Running a large network needing more addresses than those available in private RFC 1918 address space (Section 2.2).
OプライベートRFC 1918アドレス空間（2.2節）で利用可能なものよりも多くのアドレスを必要とする大規模なネットワークを実行しています。
o Running an IPv6-only network for operational simplicity as compared to dual-stack, while still needing access to the global IPv4 Internet for some, but not all, connectivity (Section 2.3).
デュアルスタックに比べて、まだいくつかのグローバルIPv4インターネットへのアクセスを必要としたまま、o、運用の簡素化のためのIPv6のみのネットワークを実行して、すべてではなく、接続（2.3節）。
o Reaching one or more privately addressed IPv4-only servers via IPv6 (Section 2.4).
一つ以上に達するoを個人のIPv6（2.4節）を経由して、IPv4専用のサーバーを取り上げました。
o Accessing IPv6-only servers from IPv4-only clients (Section 2.5).
IPv4専用のクライアント（2.5節）からOへのアクセスIPv6専用サーバ。
+----+ +---------------+
IPv4 host(s)-----+ GW +------IPv4-------------| IPv4 Internet |
+----+ +---------------+
<---private v4--->NAT<--------------public v4----------------->
Figure 1: Accessing the IPv4 Internet Today
図1：今日のIPv4インターネットへのアクセス
Figure 1 shows a typical model for accessing the IPv4 Internet today, with the gateway device implementing a Network Address and Port Translation (NAPT, or more simply referred to in this document as NAT). The NAT function serves a number of purposes, one of which is to allow more hosts behind the gateway (GW) than there are IPv4 addresses presented to the Internet. This multiplexing of IP addresses comes at great cost to the original end-to-end model of the Internet, but nonetheless is the dominant method of access today, particularly to residential subscribers.
図1は、ネットワークアドレス及びポート変換（NAPT、以上単にNATとして本文書で言及）を実現するゲートウェイ装置と、今日のIPv4インターネットにアクセスするための代表的なモデルを示しています。 NAT機能は、インターネットに提示のIPv4アドレスがあるよりも、ゲートウェイ（GW）の背後にある複数のホストを可能にすることでその一つの目的の数を、提供しています。 IPアドレスのこの多重化は、インターネットの本来のエンド・ツー・エンドモデルに大きなコストがかかりますが、それにもかかわらず、特に住宅の加入者に、今日のアクセスの支配的な方法です。
Taking the typical residential subscriber as an example, each subscriber line is allocated one global IPv4 address for it to use with as many devices as the NAT GW and local network can handle. As IPv4 address space becomes more constrained and without substantial movement to IPv6, it is expected that service providers will be pressured to assign a single global IPv4 address to multiple subscribers. Indeed, in some deployments this is already the case.
それは扱うことができNAT GWとローカルネットワークなどのような多くのデバイスで使用するための一例として、典型的な住宅の加入者を取って、各加入者線は、一つのグローバルIPv4アドレスを割り当てられています。 IPv4アドレス空間は、より制約およびIPv6へのかなりの移動なしになると、サービスプロバイダーは、複数の加入者に対して単一のグローバルIPv4アドレスを割り当てるために圧力をかけされることが期待されます。確かに、いくつかの展開で、これはすでにケースです。
When there is less than one address per subscriber at a given time, address multiplexing must be performed at a location where visibility to more than one subscriber can be realized. The most obvious place for this is within the service provider network itself, requiring the service provider to acquire and operate NAT equipment to allow sharing of addresses across multiple subscribers. For deployments where the GW is owned and operated by the customer, however, this becomes operational overhead for the Internet Service Provider (ISP), for which the ISP will no longer be able to rely on the customer and the seller of the GW device.
加入者当たり未満1つのアドレスが所与の時間に存在する場合、アドレス多重化は、複数の加入者への視認性を実現することができる場所で実行されなければなりません。このための最も明白な場所が取得し、複数の加入者間のアドレスの共有を許可するようにNAT機器を操作するサービスプロバイダを必要とする、サービスプロバイダーのネットワーク自体の中にあります。 GWは、顧客が所有、運営している展開では、しかし、これは、ISPは、もはや顧客とGW装置の販売業者に頼ることはできませんそのため、インターネットサービスプロバイダ（ISP）、運用のためのオーバーヘッドになります。
This new address translation node has been termed a "Carrier Grade NAT", or CGN [NISHITANI-CGN]. The CGN's insertion into the ISP network is shown in Figure 2.
この新しいアドレス変換ノードは、「キャリアグレードNAT」と呼ばれる、またはCGN [西谷-CGN]されています。 ISPネットワークへCGNの挿入は、図2に示されています。
+----+ +---+ +-------------+
IPv4 host(s)-----+ GW +------IPv4---------+CGN+--+IPv4 Internet|
+----+ +---+ +-------------+
<---private v4--->NAT<----private v4------>NAT<----public v4--->
Figure 2: Employing Two NAT Devices: NAT444
図2：2つのNATデバイスを採用：NAT444
This approach is known as "NAT444" or "Double-NAT" and is discussed further in [NAT-PT].
このアプローチは、「NAT444」または「ダブルNAT」として知られており、[NAT-PT]で詳しく説明されています。
It is important to note that while multiplexing of IPv4 addresses is occurring here at multiple levels, there is no aggregation of NAT state between the GW and the CGN. Every flow that is originated in the subscriber home is represented as duplicate state in the GW and the CGN. For example, if there are 4 PCs in a subscriber home, each with 25 open TCP sessions, both the GW and the CGN must track 100 sessions each for that subscriber line.
IPv4アドレスの多重化は、複数のレベルで、ここで行われている間、GWとCGN間のNAT状態のない集合体が存在しないことに注意することが重要です。加入者宅に発信され、すべてのフローは、GWとCGN内の重複状態として表現されます。加入者宅に4本、25回のオープンTCPセッションとのそれぞれが存在する場合、例えば、GWとCGNの両方は、加入者線100回のセッション毎に追跡しなければなりません。
NAT444 has the enticing property that it seems, at first glance, that the CGN can be deployed without any change to the GW device or other node in the network. While it is true that a GW that can accept a lease for a global IPv4 address would very likely accept a translated
NAT444はCGNは、ネットワーク内のGW装置、または他のノードに変更することなく展開することができることは、一見、それはそう魅力的な性質を有しています。グローバルIPv4アドレスのリースを受け入れることができGWは非常に可能性の高い翻訳を受け入れるということは事実ですが
IPv4 address as well, the CGN is neither transparent to the GW nor to the subscriber. In short, it is a very different service model to offer a translated IPv4 address versus a global IPv4 address to a customer. While many things may continue to work in both environments, some end-host applications may break, and GW port-mapping functionality will likely cease to work reliably. Further, if addresses between the subscriber network and service provider network overlap [ISP-SHARED-ADDR], ambiguous routes in the GW could lead to misdirected or black-holed traffic. Resolving this overlap through allocation of new private address space is difficult, as many existing devices rely on knowing what address ranges represent private addresses [IPv4-SPACE-ISSUES].
IPv4アドレスは、同様に、CGNはGWにも加入者に対して透過的でもありません。要するに、顧客にグローバルIPv4アドレス対翻訳IPv4アドレスを提供するために非常に異なるサービスモデルです。多くの物事は両方の環境で作業を続けるかもしれないが、いくつかのエンドホストアプリケーションが破損すること、およびGWポートマッピング機能は、おそらく確実に動作しなくなります。さらに、加入者ネットワークとサービスプロバイダネットワークのオーバーラップ[ISP-共有ADDR]との間のアドレスは、GWにおける曖昧ルートが誤っまたはブラックホールトラフィックを導くことができれば。多くの既存のデバイスがどのようなアドレス範囲を知ることに依存しているように、新しいプライベートアドレス空間の割り当てを通じて、この重複を解決することは、困難であるプライベートアドレス[IPv4の-SPACE-問題]を表します。
Network operations that had previously been tied to a single IPv4 address for a subscriber would need to be considered when deploying NAT444 as well. These may include troubleshooting, operations, accounting, logging and legal intercept, Quality of Service (QoS) functions, anti-spoofing and security, backoffice systems, etc. Ironically, some of these considerations overlap with the kinds of considerations one needs to perform when deploying IPv6.
同様NAT444を展開する際に、以前に加入者のための単一のIPv4アドレスに縛られていたネットワーク運用を検討する必要があろう。これらは、トラブルシューティング、運用、経理、ロギングと法的切片を含むことができ、サービスの品質（QoS）機能、皮肉なことに、これらの考慮事項の一部が1の時に実行する必要がある考慮事項の種類と重複するなど、スプーフィング防止やセキュリティ、バックオフィスシステム、 IPv6を配備します。
Consequences aside, NAT444 service is already being deployed in some networks for residential broadband service. It is safe to assume that this trend will likely continue in the face of tightening IPv4 address availability. The operational considerations of NAT444 need to be well-documented.
結果はさておき、NAT444サービスは、すでに家庭用ブロードバンドサービスのためのいくつかのネットワークで展開されています。この傾向はおそらく、IPv4アドレスの可用性を締めるの顔に継続すると仮定しても安全です。 NAT444の運用の考慮事項が十分に文書化する必要があります。
NAT444 assumes that the global IPv4 address offered to a residential subscriber today will simply be replaced with a single translated address. In order to try and circumvent performing NAT twice, and since the address being offered is no longer a global address, a service provider could begin offering a subnet of translated IPv4 addresses in hopes that the subscriber would route IPv4 in the GW rather than NAT. The same would be true if the GW was known to be an IP-unaware bridge. This makes assumptions on whether the ISP can enforce policies, or even identify specific capabilities, of the GW. Once we start opening the door to making changes at the GW, we have increased the potential design space considerably. The next section covers the same problem scenario of reaching the IPv4 Internet in the face of IPv4 address depletion, but with the added wrinkle that the GW can be updated or replaced along with the deployment of a CGN (or CGN-like) node.
NAT444は、今日の住宅加入者に提供するグローバルIPv4アドレスは、単に一つの変換されたアドレスに置き換えられますことを前提としています。てみないと二度NATを実行回避、および提供されているアドレスは、もはやグローバルアドレスであることからするためには、サービスプロバイダは、その加入者がルートのIPv4がGWではなくNATの場合と期待して翻訳されたIPv4アドレスのサブネットを提供し始めることができます。 GWは、IP非対応ブリッジであることが知られた場合も同様になります。これは、ISPがポリシーを実施、あるいはGWの特定の機能を、特定することができるかどうかの仮定を行います。私たちはGWの変更を行うにドアを開ける開始すると、私たちはかなり潜在的な設計空間を増加しています。次のセクションでは、IPv4アドレスの枯渇に直面してIPv4インターネットに到達するのと同じ問題シナリオをカバーするが、GWは、CGN（又はCGN状）ノードの展開に伴って更新または置換することができる添加しわを有します。
Increasingly, service providers offering "triple-play" services own and manage a highly functional GW in the subscriber home. These managed GWs generally have rather tight integration with the service provider network and applications. In these types of deployments, we can begin to consider what other possibilities exist besides NAT444 by assuming cooperative functionality between the CGN and the GW.
ますます、サービスプロバイダは、独自の「トリプルプレイ」サービスを提供し、加入者宅に高機能なGWを管理します。これらの管理対象のGWは、一般的に、サービスプロバイダーのネットワークとアプリケーションとかなり緊密な統合を持っています。このようなタイプの配置では、我々はCGNとGW間の協調的な機能を想定してNAT444以外に存在する他のどのような可能性を検討し始めることができます。
If the connection between the GW and the CGN is a point-to-point link (a common configuration between the GW and the "IP edge" in a number of access architectures), NAT-like functionality may be "split" between the GW and the CGN rather than performing NAT444 as described in the previous section.
GWとCGN間の接続がポイントツーポイントリンク（アクセスアーキテクチャの数のGWと「IPエッジ」との間の一般的な構成）の場合、NATのような機能は、GW間の「スプリット」であってもよいです前のセクションで説明したようにCGNはなくNAT444を行います。
one frac addr one public addr
+----+ +---+ +-------------+
IPv4 host(s)-----+ GW +-----p2p link------+CGN+--+IPv4 Internet|
+----+ +---+ +-------------+
<---private v4---> NAT <----public v4--->
(distributed,
over a p2p link)
Figure 3: Distributed-NAT Service
図3：分散-NATサービス
In this approach, multiple GWs share a common public IPv4 address, but with separate, non-overlapping port ranges. Each such address/ port range pair is defined as a "fractional address". Each home gateway can use the address as if it were its own public address, except that only a limited port range is available to the gateway. The CGN is aware of the port ranges, which may be assigned in different ways, for instance during DHCP lease acquisition or dynamically when ports are needed [v6OPS-APBP]. The CGN directs traffic to the fractional address towards that subscriber's GW device. This method has the advantage that the more complicated aspects of the NAT function (Application Level Gateways (ALGs), port mapping, etc.) remain in the GW, augmented only by the restricted port range allocated to the fractional address for that GW. The CGN is then free to operate in a fairly stateless manner, forwarding traffic based on IP address and port ranges and not tracking any individual flows from within the subscriber network. There are obvious scaling benefits to this approach within the CGN node, with the tradeoff of complexity in terms of the number of nodes and protocols that must work together in an interoperable manner. Further, the GW is still receiving a global IPv4 address, albeit only a "portion" of one in terms of available port usage. There are still outstanding questions in terms of how to handle protocols that run directly over IP and cannot use the divided port number ranges, and how to handle fragmented packets, but the benefit is that we are no longer burdened by two layers of NAT as in NAT444.
このアプローチでは、複数のGWは、共通のパブリックIPv4アドレスを共有するが、別個の非重複ポート範囲を有します。このような各アドレス/ポート範囲ペアは「分数アドレス」として定義されます。それは限られたポート範囲がゲートウェイに利用可能であることを除いて、独自のパブリックアドレスであるかのように、各ホームゲートウェイは、アドレスを使用することができます。 CGNは、DHCPリース取得または動的にポートが必要とされている[v6OPS-APBP]中に、例えば、様々な方法で割り当てることができるポート範囲の認識しています。 CGNは、その加入者のGW装置に向けた小数アドレスにトラフィックを誘導します。この方法は、GW用フラクショナルアドレスに割り当てられた制限されたポートの範囲によってのみ拡張NAT機能（アプリケーションレベルゲートウェイ（のALG）、ポートマッピング、等）のより複雑な態様はGWに留まるという利点を有します。 CGNは、IPアドレスとポート範囲と加入者ネットワーク内からの任意の個々のフローを追跡しないに基づいてトラフィックを転送し、その後、かなりステートレスな方法で動作するように自由です。相互運用可能な方法で協力しなければならないノードとプロトコルの数の面での複雑さのトレードオフとCGNノード内のこのアプローチには明らかなスケーリング利点があります。さらに、GWは、まだ使用可能なポートの使用の点で一方の唯一の「部分」とはいえ、グローバルIPv4アドレスを受信しています。そこIP上で直接実行して、断片化されたパケットを処理する方法を分割番号範囲ポート、およびを使用することはできませんプロトコルを処理する方法の面で優れた質問はまだですが、利点は、我々はもはやのようにNATの二つの層によって負担されているということではありませんNAT444。
Not all access architectures provide a natural point-to-point link between the GW and the CGN to tie into. Further, the CGN may not be incorporated into the IP edge device in networks that do have point-to-point links. For these cases, we can build our own point-to-point link using a tunnel. A tunnel is essentially a point-to-point link that we create when needed [INTAREA-TUNNELS]. This is illustrated in Figure 4.
いないすべてのアクセス・アーキテクチャはに結びつけるためにGWとCGNの間に自然なポイントツーポイントリンクを提供しています。さらに、CGNは、ポイントツーポイントリンクを持っているネットワークにおけるIPエッジデバイスに組み込まれなくてもよいです。このような場合のために、我々はトンネルを使用して、当社の独自のポイントツーポイントリンクを構築することができます。トンネルは、本質的に[INTAREA-トンネル]必要なときに我々が作成したポイントツーポイントリンクです。これは、図4に示されています。
one frac addr one public addr
+----+ +---+ +-------------+
IPv4 host(s)-----+ GW +======tunnel=======+CGN+--+IPv4 Internet|
+----+ +---+ +-------------+
<---private v4---> NAT <----public v4--->
(distributed,
over a tunnel)
Figure 4: Point-to-Point Link Created through a Tunnel
図4：トンネル経由で作成ポイントツーポイントリンク
Figure 4 is essentially the same as Figure 3, except the data link is created with a tunnel. The tunnel could be created in any number of ways, depending on the underlying network.
図4は、データリンクがトンネルを使用して作成されている以外は、基本的に図3と同じです。トンネルは、基礎となるネットワークに応じて、任意の数の方法で作成することができます。
At this point, we have used a tunnel or point-to-point link with coordinated operation between the GW and the CGN in order to keep most of the NAT functionality in the GW.
この時点で、我々はGW中にNAT機能のほとんどを維持するために、トンネルやGWとCGN間の協調動作とポイントツーポイントリンクを使用していました。
Given the assumption of a point-to-point link between the GW and the CGN, the CGN could perform the NAT function, allowing private, overlapping space to all subscribers. For example, each subscriber GW may be assigned the same 10.0.0.0/8 address space (or all RFC 1918 [RFC1918] space for that matter). The GW then becomes a simple "tunneling router", and the CGN takes on the full NAT role. One can think of this design as effectively a layer-3 VPN, but with Virtual-NAT tables rather than Virtual-Routing tables.
GWとCGN間のポイントツーポイントリンクの仮定を考えると、CGNは、すべての加入者にプライベート、重複スペースを許可する、NAT機能を実行することができます。例えば、各加入者GWは同じ10.0.0.0/8アドレス空間（またはそのことについては、すべてのRFC 1918 [RFC1918]のスペース）を割り当てることができます。 GWは、単純な「トンネリングルータ」になり、CGNはフルNAT役割を引き受けます。一つは、として効果的にこの設計のレイヤ3 VPNと思いますが、仮想NATテーブルではなく、仮想ルーティングテーブルを持つことができます。
This section deals strictly with the problem of reaching the IPv4 Internet with limited public address space for each device in a network. We explored combining NAT functions and tunnels between the GW and the CGN to obtain similar results with different design tradeoffs. The methods presented can be summarized as:
厳密ネットワーク内の各デバイスのための公共のアドレス空間を持つIPv4インターネットに到達する問題このセクションで扱っています。我々は、さまざまな設計上のトレードオフと同様の結果を得るためにGWとCGN間NAT機能とトンネルを組み合わせる探求しました。提示方法は、以下のように要約することができます。
a. Double-NAT (NAT444)
A。ダブルNAT（NAT444）
b. Single-NAT at CGN with a subnet and routing at the GW c. Tunnel/link + fractional IP (NAT at GW, port-routing at CGN)
B。 GW cのサブネットとルーティングとCGNのシングルNAT。トンネル/リンク+分数IP（GWでNAT、ポートルーティングCGNにおいて）
d. Tunnel/link + Single-NAT with overlapping RFC 1918 ("Virtual NAT" tables and routing at the GW)
D。 （GWで「仮想NAT」テーブルとルーティング）RFC 1918が重複するトンネル/リンク+シングルNAT
In all of the methods above, the GW could be logically moved into a single host, potentially eliminating one level of NAT by that action alone. As long as the hosts themselves need only a single IPv4 address, methods b and d obviously are of little interest. This leaves methods a and c as the more interesting methods in cases where there is no analogous GW device (such as a campus network).
上記方法の全てにおいて、GWは、論理的に、潜在的に、単独でその作用によりNATの1つのレベルをなくし、単一のホストに移動することができます。限り、ホスト自体は、単一のIPv4アドレス、方法Bを必要とし、明らかに少し関心があるdは。これは、（例えば、キャンパスネットワークのような）は、類似のGW装置が存在しない場合には、より興味深い方法として、方法AおよびCを残します。
This document recommends the development of new guidelines and specifications to address the above methods. Cases where the home gateway both can and cannot be modified should be addressed.
この文書では、上記の方法に対処するための新しいガイドラインと仕様の開発を推奨しています。対処すべきケースホームゲートウェイの両方が、変更することはできませんすることができます。
In addition to public address space depletion, very large privately addressed networks are reaching exhaustion of RFC 1918 space on local networks as well. Very large service provider networks are prime candidates for this. Private address space is used locally in ISPs for a variety of things, including:
パブリックアドレス空間の枯渇に加えて、非常に大規模な私的に取り組むネットワークは、同様にローカルネットワーク上のRFC 1918のスペースの枯渇に達しています。非常に大規模なサービスプロバイダーのネットワークは、このための主要な候補です。プライベートアドレス空間を含め、様々なもののためのISPでローカルに使用されます。
o Control and management of service provider devices in subscriber premises (cable modems, set-top boxes, and so on).
Oコントロールと加入者宅におけるサービス提供装置の管理（ケーブルモデム、セットトップボックスなど）。
o Addressing the subscriber's NAT devices in a Double-NAT arrangement.
ダブルNAT構成では、加入者のNATデバイスへの対応、O。
o "Walled garden" data, voice, or video services.
「城壁の庭」データ、音声、またはビデオサービスO。
Some providers deal with this problem by dividing their network into parts, each on its own copy of the private space. However, this limits the way services can be deployed and what management systems can reach what devices. It is also operationally complicated in the sense that the network operators have to understand which private scope they are in.
一部のプロバイダは、プライベートな空間の独自のコピーに、部分にそれぞれが自分のネットワークを分割することにより、この問題に対処します。しかし、これはサービスが展開できる方法制限し、どのような管理システムは、どのようなデバイスに到達することができます。これは、ネットワーク事業者は、彼らがしている民間のどの範囲を理解しなければならないという意味でも、操作上煩雑です。
Tunnels were used in the previous section to facilitate distribution of a single global IPv4 address across multiple endpoints without using NAT, or to allow overlapping address space to GWs or hosts connected to a CGN. The kind of tunnel or link was not specified. If the tunnel used carries IPv4 over IPv6, the portion of the IPv6 network traversed naturally need not be IPv4-capable, and need not utilize IPv4 addresses, private or public, for the tunnel traffic to traverse the network. This is shown in Figure 5.
トンネルは、NATを使用することなく、複数のエンドポイントを横切る単一のグローバルIPv4アドレスの分布を容易にするために、又はCGNに接続されているのGWまたはホストに重複アドレス空間を可能にするために、前のセクションで使用しました。トンネルやリンクの種類が指定されていません。使用されるトンネルは、IPv6上のIPv4を搬送する場合、IPv6ネットワークの部分は、IPv4対応である必要はなく、自然に横断し、トンネルトラフィックがネットワークを横断するため、プライベートまたはパブリックIPv4アドレスを利用する必要はありません。これは図5に示されています。
IPv6-only network
+----+ +---+ +-------------+
IPv4 host--------+ GW +=======tunnel========+CGN+--+IPv4 Internet|
+----+ +---+ +-------------+
<---private v4----> <----- v4 over v6 -----> <---public v4---->
Figure 5: Running IPv4 over an IPv6-Only Network
図5：IPv6のみのネットワーク上でのIPv4を実行します
Each of the four approaches (a, b, c, and d) from the Section 2.1 scenario could be applied here, and for brevity each iteration is not specified in full here. The models are essentially the same, just that the tunnel is over an IPv6 network and carries IPv4 traffic. Note that while there are numerous solutions for carrying IPv6 over IPv4, this reverse mode is somewhat of an exception (one notable exception being the Softwire working group, as seen in [RFC4925]).
セクション2.1シナリオからの4つのアプローチ（A、B、C、およびD）のそれぞれは、ここで適用することができ、簡潔にするために各繰り返しは、ここで完全に指定されていません。モデルは、トンネルがIPv6ネットワーク上にあり、IPv4トラフィックを運ぶちょうどこと、本質的に同じです。 IPv4の上にIPv6を運ぶための多数の解決策があるが、この逆方向モードはやや例外であることに注意してください（[RFC4925]に見られるように、1つの注目すべき例外は、Softwireワーキンググループです）。
Once we have IPv6 to the GW (or host, if we consider the GW embedded in the host), enabling IPv6 and IPv4 over the IPv6 tunnel allows for dual-stack operation at the host or network behind the GW device. This is depicted in Figure 6:
我々はGWへのIPv6たら（またはホストを、我々はホストに埋め込まれたGWを考慮した場合）、IPv6トンネル上のIPv6とIPv4を有効にするGW装置の背後のホストまたはネットワークでデュアルスタック操作を可能にします。これは、図6に示されています。
+----+ +-------------+
IPv6 host-----+ | +------------------+IPv6 Internet|
| +---IPv6-----+ +-------------+
dual-stack host-+ GW |
| | +---+ +-------------+
IPv4 host-----+ +===v4-over-v6 tunnel====+CGN+--+IPv4 Internet|
+----+ +---+ +-------------+
<-----------private v4 (partially in tunnel)-->NAT<---public v4---->
<-----------------------------public v6---------------------------->
Figure 6: "Dual-Stack Lite" Operation over an IPv6-Only Network
図6：IPv6のみのネットワークを介した「デュアルスタックライト」操作
In [DUAL-STACK-LITE], this is referred to as "dual-stack lite", bowing to the fact that it is dual-stack at the gateway, but not at the network. As introduced in Section 2.1, if the CGN here is a full functioning NAT, hosts behind a dual-stack lite gateway can support IPv4-only and IPv6-enabled applications across an IPv6-only network without provisioning a unique IPv4 address to each gateway. In fact, every gateway may have the same address.
[デュアルスタック-LITE]、これは、それがゲートウェイではなく、ネットワークでデュアルスタックであるという事実にお辞儀、「デュアルスタックライト」と呼ばれます。 CGNは、ここにフル機能NATであれば、2.1節で紹介したように、ゲートウェイliteのデュアルスタックの背後にあるホストが各ゲートウェイにユニークなIPv4アドレスをプロビジョニングすることなく、IPv6のみのネットワークを介してIPv4のみとIPv6対応のアプリケーションをサポートすることができます。実際には、すべてのゲートウェイが同じアドレスを持つことができます。
While the high-level problem space in this scenario is how to alleviate local usage of IPv4 addresses within a service provider network, the solution direction identified with IPv6 has interesting operational properties that should be pointed out. By tunneling IPv4 over IPv6 across the service provider network, the separate problems of transitioning the service provider network to IPv6, deploying IPv6 to subscribers, and continuing to provide IPv4 service can all be decoupled. The service provider could deploy IPv6 internally, turn off IPv4 internally, and still carry IPv4 traffic across the IPv6 core for end users. In the extreme case, all of that IPv4 traffic need not be provisioned with different IPv4 addresses for each endpoint, as there is not IPv4 routing or forwarding within the network. Thus, there are no issues with IPv4 renumbering, address space allocation, etc. within the network itself.
このシナリオでは、高レベルの問題空間は、サービスプロバイダーネットワーク内のIPv4アドレスのローカルな利用を軽減する方法ですが、IPv6で識別される解決策の方向が指摘されるべき興味深い運用特性を有しています。サービスプロバイダーのネットワークを介したIPv6上でのIPv4をトンネリングすることにより、IPv6へのサービスプロバイダのネットワークを移行加入者にIPv6を導入し、IPv4サービスを提供し続けることの別の問題は、すべて切り離すことができます。サービスプロバイダは、内部的にIPv6を展開し、内部でのIPv4をオフにして、まだエンドユーザーのためのIPv6コア間でIPv4トラフィックを運ぶことができます。ネットワーク内のIPv4ルーティングまたは転送がないように、極端な場合には、そのIPv4トラフィックの全ては、各エンドポイントの異なるIPv4アドレスをプロビジョニングする必要はありません。したがって、ネットワーク自体の中などのIPv4番号を付け替える、アドレス空間の割り当て、とは問題がありません。
It is recommended that the IETF develop tools to address this scenario for both a host and the GW. It is assumed that both endpoints of the tunnel can be modified to support these new tools.
IETFは、ホストとGWの両方のために、このシナリオに対処するためのツールを開発することをお勧めします。トンネルの両方のエンドポイントがこれらの新しいツールをサポートするように変更することができるものとします。
This scenario is about allowing an IPv6-only host or a host that has no interfaces connected to an IPv4 network to reach servers on the IPv4 Internet. This is an important scenario for what we sometimes call "greenfield" deployments. One example is an enterprise network that wishes to operate only IPv6 for operational simplicity, but still wishes to reach the content in the IPv4 Internet. For instance, a new office building may be provisioned with IPv6 only. This is shown in Figure 7.
このシナリオは、IPv6のみのホストまたはIPv4インターネット上のサーバーに到達するためにIPv4ネットワークに接続されていないインタフェースを持っていないホストを許可についてです。これは、我々は時々「グリーンフィールド」の展開と呼んでいるもののための重要なシナリオです。一例としては、運用の簡素化のためにIPv6のみを操作することを希望する企業ネットワークであるが、それでもIPv4インターネットでのコンテンツに到達したいです。たとえば、新しいオフィスビルは、IPv6のみをプロビジョニングすることができます。これは、図7に示されています。
+----+ +-------------+
| +------------------+IPv6 Internet+
| | +-------------+
IPv6 host-----------------+ GW |
| | +-------------+
| +------------------+IPv4 Internet+
+----+ +-------------+
<-------------------------public v6----------------------------->
<-------public v6--------->NAT<----------public v4-------------->
Figure 7: Enterprise IPv6-Only Network
図7：エンタープライズのIPv6オンリーネットワーク
Other cases that have been mentioned include "greenfield" wireless service provider networks and sensor networks. This enterprise IPv6- only scenario bears a striking resemblance to the Section 2.2 scenario as well, if one considers a particularly large enterprise network that begins to resemble a service provider network.
言及されている他の例では、「グリーンフィールド」無線サービスプロバイダのネットワークやセンサネットワークが含まれます。一つは、サービス・プロバイダ・ネットワークに類似するように開始し、特に大規模な企業ネットワークを考える場合、この企業IPv6-唯一のシナリオは、同様に、セクション2.2シナリオに顕著似ています。
In the Section 2.2 scenario, we dipped into design space enough to illustrate that the service provider was able to implement an IPv6- only network to ease their addressing problems via tunneling. This came at the cost of touching two devices on the edges of this network; both the GW and the CGN have to support IPv6 and the tunneling mechanism over IPv6. The greenfield enterprise scenario is different from that one in the sense that there is only one place that the enterprise can easily modify: the border between its network and the IPv4 Internet. Obviously, the IPv4 Internet operates the way it already does. But in addition, the hosts in the enterprise network are commercially available devices, personal computers with existing operating systems. While we consider in this scenario that all of the devices on the network are "modern" dual-stack-capable devices, we do not want to have to rely upon kernel-level modifications to these operating systems. This restriction drives us to a "one box" type of solution, where IPv6 can be translated into IPv4 to reach the public Internet. This is one situation where new or improved IETF specifications could have an effect on the user experience in these networks. In fairness, it should be noted that even a network-based solution will take time and effort to deploy. This is essentially, again, a tradeoff between one new piece of equipment in the network, or a cooperation between two.
2.2シナリオでは、サービスプロバイダが、トンネルを経由して自分のアドレッシングの問題を緩和するためにIPv6-だけネットワークを実装することができたことを示すために十分な設計空間の中に浸漬しました。これは、このネットワークのエッジにある2つのデバイスに触れるの費用で来ました。 GWとCGNの両方は、IPv6およびIPv6経由トンネリングメカニズムをサポートしなければなりません。そのネットワークとIPv4インターネットとの間の境界：グリーンフィールドエンタープライズシナリオでは、企業が簡単に変更することができる唯一の場所があるという意味で、その1つの異なっています。明らかに、IPv4インターネットがまだない方法を運営しています。それに加えて、企業ネットワーク内のホストは、市販の装置、既存のオペレーティングシステムとのパーソナルコンピュータで。私たちは、ネットワーク上のすべてのデバイスは、「現代の」デュアルスタック対応のデバイスであり、このシナリオで検討している間、私たちは、これらのオペレーティングシステムにカーネルレベルの変更に依拠する必要がありますする必要はありません。この制限は、IPv6は公共のインターネットに到達するためにはIPv4に変換することができるソリューションの「ワンボックス」タイプ、に私たちを駆動します。これは、新規または改善されたIETF仕様は、これらのネットワークにおけるユーザーエクスペリエンスに影響を与える可能性がある状況です。公平に、それも、ネットワークベースのソリューションを展開するために時間と労力がかかりますことに留意すべきです。これは、再び、本質的に1つの新しいネットワークにおける機器の一部、または2間の協力の間のトレードオフです。
One approach to deal with this environment is to provide an application-level proxy at the edge of the network (GW). For instance, if the only application that needs to reach the IPv4 Internet is the web, then an HTTP/HTTPS proxy can easily convert traffic from IPv6 into IPv4 on the outside.
この環境に対処する一つのアプローチは、ネットワーク（GW）のエッジでアプリケーションレベルのプロキシを提供することです。 IPv4インターネットに到達するために必要がある唯一のアプリケーションがウェブである場合たとえば、その後、HTTP / HTTPSプロキシを簡単に外でIPv4へのIPv6のトラフィックを変換することができます。
Another more generic approach is to employ an IPv6-to-IPv4 translator device. Different types of translation schemes are discussed in [NAT-PT], [RFC6144], [RFC6145], and [RFC6052]. NAT64 is one example of a translation scheme falling under this category [RFC6147] [RFC6146].
別のより一般的なアプローチは、IPv6からIPv4トランスレーターデバイスを使用することです。変換方式の異なるタイプの[NAT-PT]、[RFC6144]、[RFC6145]、および[RFC6052]で議論されています。 NAT64はこのカテゴリ[RFC6147] [RFC6146]に該当する変換方式の一例です。
Translation will in most cases have some negative consequences for the end-to-end operation of Internet protocols. For instance, the issues with Network Address Translation - Protocol Translation (NAT-PT) [RFC2766] have been described in [RFC4966]. It is important to note that the choice of translation solution, and the assumptions about the network in which it is used, impact the consequences. A translator for the general case has a number of issues that a translator for a more specific situation may not have at all.
翻訳はほとんどの場合、インターネット・プロトコルのエンド・ツー・エンドの操作のためのいくつかの負の影響を持つことになります。例えば、ネットワークアドレス変換の問題 - プロトコル変換（NAT-PT）[RFC2766]は、[RFC4966]に記載されています。翻訳ソリューションの選択、およびそれが使用されるネットワークに関する仮定は、結果に影響を与えることに注意することが重要です。一般的なケースのための翻訳者は、より具体的な状況のためのトランスレータは全く持っていないかもしれない多くの問題があります。
It is recommended that the IETF develop tools to address this scenario. These tools need to allow existing IPv6 hosts to operate unchanged.
IETFは、このシナリオに対処するためのツールを開発することをお勧めします。これらのツールは、IPv6ホストを既存の変わらず動作することができるようにする必要があります。
This section discusses the specific problem of IPv4-only-capable server farms that no longer can be allocated a sufficient number of public addresses. It is expected that for individual servers, addresses are going to be available for a long time in a reasonably easy manner. However, a large server farm may require a large enough block of addresses that it is either not feasible to allocate one or it becomes economically desirable to use the addresses for other purposes.
このセクションでは、もはやパブリックアドレスの十分な数を割り当てることのできるIPv4のみ対応のサーバファームの特定の問題を論じています。個々のサーバのために、アドレスが合理的に簡単な方法で、長い時間のために利用可能であることを行っていることが期待されます。しかし、大規模なサーバファームは、どちらかではないものを割り当てることが可能か、他の目的のためにアドレスを使用することが経済的に望ましいとなるアドレスの十分に大きなブロックを必要とするかもしれません。
Another use case for this scenario involves a service provider that is capable of acquiring a sufficient number of IPv4 addresses, and has already done so. However, the service provider also simply wishes to start to offer an IPv6 service but without yet touching the server farm (that is, without upgrading the server farm to IPv6).
このシナリオの別のユースケースは、IPv4アドレスの十分な数を取得することができるサービスプロバイダを含み、そしてまだ行きました。しかし、サービスプロバイダは、単にIPv6サービスを提供するために開始したいが、まだ（それがIPv6にサーバーファームをアップグレードせず、である）サーバファームに触れることなく。
One option available in such a situation is to move those servers and their clients to IPv6. However, moving to IPv6 involves not just the cost of the IPv6 connectivity, but the cost of moving the application itself from IPv4 to IPv6. So, in this case, the server farm is IPv4- only, there is an increasing cost for IPv4 connectivity, and there is an expensive bill for moving server infrastructure to IPv6. What can be done?
このような状況で使用できる1つのオプションは、IPv6へのそれらのサーバーとそのクライアントを移動することです。しかし、IPv6への移動はないだけでIPv6接続のコストが、IPv4からIPv6へのアプリケーション自体を移動するコストを伴います。サーバーファームが唯一のIPv4-あるので、この場合には、IPv4接続のためのコストの増加があり、IPv6へのサーバーインフラストラクチャを移動するための高価な法案があります。何を行うことができますか？
If the clients are IPv4-only as well, the problem is a hard one. This issue is dealt with in more depth in Section 2.5. However, there are important cases where large sets of clients are IPv6- capable. In these cases, it is possible to place the server farm in private IPv4 space and arrange some of the gateway service from IPv6 to IPv4 to reach the servers. This is shown in Figure 8.
クライアントはIPv4のみにもある場合は、問題は難しいものです。この問題は、2.5節で詳しく扱われます。しかし、クライアントの大規模なセットがIPv6-ことができる重要な場合があります。これらのケースでは、プライベートIPv4空間のサーバーファームを配置し、サーバに到達するためのIPv6からIPv4のへのゲートウェイサービスの一部を配置することが可能です。これは図8に示されています。
+----+
IPv6 host(s)-------(Internet)-----+ GW +------Private IPv4 servers
+----+
<---------public v6--------------->NAT<------private v4---------->
Figure 8: Reaching Servers in Private IPv4 Space
図8：プライベートIPv4のスペースで到達サーバー
One approach to implement this is to use NAT64 to translate IPv6 into private IPv4 addresses. The private IPv4 addresses are mapped into IPv6 addresses within one or more known prefixes. The GW at the edge of the server farm is aware of the mapping, as is the Domain Name
これを実現するための一つのアプローチは、プライベートIPv4アドレスにIPv6を変換するためにNAT64を使用することです。プライベートIPv4アドレスは、一の以上の既知のプレフィクス内のIPv6アドレスにマッピングされています。ドメイン名は、サーバファームのエッジにおけるGWは、マッピングを認識しています
System (DNS). AAAA records for each server name are given an IPv6 address that corresponds to the mapped private IPv4 address. Thus, each privately addressed IPv4 server is given a public IPv6 presentation. No Application Level Gateway for DNS (DNS-ALG) is needed in this case, contrary to what NAT-PT would require, for instance.
システム（DNS）。各サーバー名のAAAAレコードがマッピングされたプライベートIPv4アドレスに対応するIPv6アドレスを与えられています。このように、各個人対処のIPv4サーバは、パブリックIPv6のプレゼンテーションを与えています。 DNSにはアプリケーションレベルゲートウェイ（DNS-ALG）は、NAT-PTは、例えば、必要となるものに反して、この場合に必要ありません。
This is very similar to the Section 2.3 scenario where we typically think of a small site with IPv6 needing to reach the public IPv4 Internet. The difference here is that we assume not a small IPv6 site, but the whole of the IPv6 Internet needing to reach a small IPv4 site. This example was driven by the enterprise network with IPv4 servers, but could be scaled down to the individual subscriber home level as well. Here, the same technique could be used to, say, access an IPv4 webcam in the home from the IPv6 Internet. All that is needed is the ability to update AAAA records appropriately, an IPv6 client (which could use Teredo [RFC4380] or some other method to obtain IPv6 reachability), and the NAT64 mechanism. In this sense, this method looks much like a "NAT/firewall bypass" function.
これは、我々は通常、IPv6は公共のIPv4インターネットに到達するために必要と小さなサイトの考える、2.3節のシナリオと非常によく似ています。ここでの違いは、私たちは小さなIPv6サイトがないと仮定しますが、IPv6インターネット全体が小さなIPv4のサイトに到達するために必要ということです。この例では、IPv4サーバと企業ネットワークによるものであったが、同様に、個々の加入者宅レベルまで縮小することができます。ここでは、同じ技術は、たとえば、IPv6インターネットから自宅でのIPv4ウェブカメラにアクセスするために使用することができます。必要とされる全ては、とNAT64機構（Teredoの[RFC4380]またはIPv6到達可能性を得るためにいくつかの他の方法を使用することができる）適切にAAAAレコードを更新する機能、IPv6クライアントです。この意味で、この方法は多くの「NAT /ファイアウォールのバイパス」機能のように見えます。
An argument could be made that since the host is likely dual-stack, existing port-mapping services or NAT traversal techniques could be used to reach the private space instead of IPv6. This would have to be done anyway if the hosts are not all IPv6-capable or connected. However, in cases where the hosts are all IPv6-capable, the alternative techniques force additional limitations on the use of port numbers. In the case of IPv6-to-IPv4 translation, the full port space would be available for each server, even in the private space.
引数には、ホストはデュアルスタック可能性があるため、既存のポートマッピングサービスやNATトラバーサル技術が代わりのIPv6のプライベート空間に到達するために使用することができることを作ることができます。ホストは、すべてのIPv6対応または接続されていない場合、これはとにかく行わなければなりません。しかし、ホストがすべてのIPv6対応している場合には、代替技術は、ポート番号の使用に関する追加の制限を強制します。 IPv6のツーIPv4の翻訳の場合、フルポート空間でもプライベート空間に、各サーバーで使用可能になります。
It is recommended that the IETF develop tools to address this scenario. These tools need to allow existing IPv4 servers to operate unchanged.
IETFは、このシナリオに対処するためのツールを開発することをお勧めします。これらのツールは、既存のIPv4サーバがそのまま動作することができるようにする必要があります。
This scenario is predicted to become increasingly important as IPv4 global connectivity sufficient for supporting server-oriented content becomes significantly more difficult to obtain than global IPv6 connectivity. Historically, the expectation has been that for connectivity to IPv6-only devices, devices would either need to be IPv6-connected, or dual-stack with the ability to set up an IPv6- over-IPv4 tunnel in order to access the IPv6 Internet. Many "modern" device stacks have this capability, and for them this scenario does not present a problem as long as a suitable gateway to terminate the tunnel and route the IPv6 packets is available. But, for the server operator, it may be a difficult proposition to leave all IPv4-only devices without reachability. Thus, if a solution for IPv4-only devices to reach IPv6-only servers were realizable, the benefits would be clear. Not only could servers move directly to IPv6 without trudging through a difficult dual-stack period, but they could do so without risk of losing connectivity with the IPv4-only Internet.
このシナリオは、サーバー指向のコンテンツをサポートするための十分なIPv4グローバルな接続は、グローバルIPv6接続よりも得ることが著しく困難になるにつれて、ますます重要になると予測されています。歴史的に、期待がIPv6のみのデバイスへの接続のために、機器がIPv6に接続する必要があるだろうか、IPv6インターネットにアクセスするためにIPv6-オーバーのIPv4トンネルを設定する能力を持つデュアルスタックということでした。多くの「現代」デバイススタックは、この機能を持っており、彼らのために、このシナリオであればトンネルとルートIPv6パケットを終了するための適切なゲートウェイが利用可能であるなどの問題を提示しません。しかし、サーバオペレータのために、到達せずに、すべてのIPv4専用デバイスを残す難しい命題かもしれません。 IPv4のみのソリューションは、IPv6のみのサーバーに到達するためのデバイスが実現可能であればこのように、メリットは明らかです。サーバーは、困難なデュアルスタック期間を経て重そうに歩くことなく、IPv6へ直接移動することもできますが、彼らは、IPv4のみのインターネットとの接続を失うリスクなしにそれを行うことができないだけで。
Unfortunately, realizing this goal is complicated by the fact that IPv4 to IPv6 is considered "hard" since of course IPv6 has a much larger address space than IPv4. Thus, representing 128 bits in 32 bits is not possible, barring the use of techniques similar to NAT64, which uses IPv6 addresses to represent IPv4 addresses as well.
残念ながら、この目標を実現することはもちろんのIPv6は、IPv4よりもはるかに大きなアドレス空間を持っているので、IPv6へのIPv4が「ハード」と見なされているという事実によって複雑になります。したがって、32ビットで128ビットを表すことIPv6は同様にIPv4アドレスを表すためにアドレスを使用NAT64に同様の技術を使用することを除けば、不可能です。
The main questions regarding this scenario are about timing and priority. While the expectation that this scenario may be of importance one day is readily acceptable, at the time of this writing, there are few or no IPv6-only servers of importance (beyond some contrived cases) that the authors are aware of. The difficulty of making a decision about this case is that, quite possibly, when there is sufficient pressure on IPv4 such that we see IPv6-only servers, the vast majority of hosts will either have IPv6 connectivity or the ability to tunnel IPv6 over IPv4 in one way or another.
このシナリオに関する主な質問は、タイミングと優先順位についてです。このシナリオでは重要では1日であってもよいこと期待が容易に許容されますが、この記事の執筆時点では、筆者が知っていること（いくつかの不自然な例を超えた）重要性のいくつかまたは全くIPv6のみのサーバーがあります。この場合についての決定を行うことの難しさは、我々はIPv6のみのサーバーを参照するようなIPv4のに十分な圧力がある場合に、ホストの大半はIPv6接続または中over IPv4トンネリングIPv6への能力を持ってするか、恐らく、ということですあれやこれやで。
This discussion makes assumptions about what a "server" is as well. For the majority of applications seen on the IPv4 Internet to date, this distinction has been more or less clear. This clarity is perhaps in no small part due to the overhead today in creating a truly end-to-end application in the face of the fragmented addressing and reachability brought on by the various NATs and firewalls employed today. However, current notions of a "server" are beginning to shift, as we see more and more pressure to connect people to one another in an end-to-end fashion -- with peer-to-peer techniques, for instance -- rather than simply content server to client. Thus, if we consider an "IPv6-only server" as what we classically consider an "IPv4 server" today, there may not be a lot of demand for this in the near future. However, with a more distributed model of the Internet in mind, there may be more opportunities to employ IPv6-only "servers" that we would normally extrapolate from based on past experience with applications.
この議論は、「サーバー」は、同様であるかについての仮定を行います。これまでのIPv4インターネット上で見られる大多数のアプリケーションでは、この区別は、多かれ少なかれ明らかにされています。この透明度は、今日使用される種々のNATやファイアウォールによってもたらさアドレッシング断片化および到達可能性の面で真のエンド・ツー・エンドのアプリケーションを作成する際に伴うオーバーヘッドに少なからずにおそらく今日。例えば、ピア・ツー・ピア技術を - - しかし、「サーバー」の現在の概念は、我々は、エンドツーエンドの形でお互いに人々を接続するために、より多くの圧力を見るように、シフトし始めているといいますクライアントに単にコンテンツサーバーより。我々は古典的に「IPv4のサーバー」今日考えるものとして、「IPv6専用サーバー」を考慮すれば、このように、近い将来、この需要の多くがない可能性があります。しかし、心の中で、インターネットのより多くの分散モデルで、我々は通常のアプリケーションとの過去の経験に基づいてから外挿しますIPv6のみの「サーバ」を採用するより多くの機会があるかもしれません。
It is recommended that the IETF address this scenario, though perhaps with a slightly lower priority than the others. In any case, when new tools are developed to support this, it should be obvious that we cannot assume any support for updating legacy IPv4 hosts in order to reach the IPv6-only servers.
おそらく他の人よりも少し低い優先順位を持つもののIETFは、このシナリオに対処することをお勧めします。新しいツールは、これをサポートするために開発されたときにどのような場合には、我々がIPv6のみのサーバーに到達するために、従来のIPv4ホストを更新するためのあらゆるサポートを負いかねますことは言うまでもないです。
Security aspects of the individual solutions are discussed in more depth elsewhere, for instance in [DUAL-STACK-LITE], [RFC6144], [RFC6147], [RFC6145], [RFC6146], [NAT-PT], and [RFC4966]. This document highlights just three issues:
個々のソリューションのセキュリティ態様は[デュアルスタック-LITE]、[RFC6144]、[RFC6147]、[RFC6145]、[RFC6146]、[NAT-PT]、および[RFC4966]に、例えば、他の箇所でより詳しく説明されています。この文書では、ちょうど3つの問題に焦点を当てています。
o Any type of translation may have an impact on how certain protocols can pass through. For example, IPsec needs support for NAT traversal, and the proliferation of NATs implies an even higher reliance on these mechanisms. It may also require additional support for new types of translation.
O翻訳の任意のタイプは、特定のプロトコルが通過することができる方法に影響を与えることができます。例えば、IPsecはNATトラバーサルのサポートを必要とし、NATのの増殖は、これらのメカニズムのより高い信頼を意味します。また、翻訳の新しいタイプの追加サポートが必要な場合があります。
o Some solutions have a need to modify results obtained from DNS. This may have an impact on DNS security, as discussed in [RFC4966]. Minimization or even elimination of such problems is essential, as discussed in [RFC6147].
Oいくつかのソリューションは、DNSから得られた結果を変更する必要があります。これは[RFC4966]で議論するように、DNSのセキュリティに影響を与えることができます。 [RFC6147]で議論するように最小化、またはこのような問題も解消は、必須です。
o Tunneling solutions have their own security issues, for instance the need to secure tunnel endpoint discovery or to avoid opening up denial-of-service or reflection vulnerabilities [RFC6169].
Oトンネリングソリューションは、独自のセキュリティ問題、トンネルエンドポイントの検出を確保するか、開くサービス拒否の脆弱性や反射[RFC6169]を回避するには、インスタンスを必要としています。
The authors believe that the scenarios outlined in this document are among the top of the list of those that should be addressed by the IETF community in short order. For each scenario, there are clearly different solution approaches with implementation, operations, and deployment tradeoffs. Further, some approaches rely on existing or well-understood technology, while some require new protocols and changes to established network architecture. It is essential that these tradeoffs be considered, understood by the community at large, and in the end well-documented as part of the solution design.
著者は、この文書で概説したシナリオが短いために、IETFコミュニティによって対処すべきもののリストのトップの一つであると考えています。各シナリオのために、別の解決策は、実装、運用、および展開のトレードオフと明らかに近づくあります。いくつかの新しいプロトコルおよび確立されたネットワークアーキテクチャへの変更を必要としながら、さらに、いくつかのアプローチは、既存またはよく理解技術に依存しています。これらのトレードオフが広く社会に理解さ、と考えられ、そして最終的にソリューション設計の一部として十分に文書化することが不可欠です。
After writing the initial version of this document, the Softwire working group was rechartered to address the Section 2.2 scenario with a combination of existing tools (tunneling, IPv4 NATs) and some minor new ones (DHCP options) [DUAL-STACK-LITE]. Similarly, the Behave working group was rechartered to address scenarios from Sections 2.3, 2.4, and 2.5. At the time this document is being published, proposals to address scenarios from Section 2.1 are still under consideration for new IETF work items.
このドキュメントの最初のバージョンを書いた後、Softwireワーキンググループは、既存のツール（トンネリング、IPv4のNATの）といくつかのマイナーな新しいもの（DHCPオプション）[DUAL-STACK-LITE]の組み合わせで2.2シナリオに対処するためにrecharteredました。同様に、振るまいワーキンググループは、セクション2.3、2.4、および2.5からシナリオに対処するためにrecharteredました。この文書が公開されている時には、セクション2.1からのシナリオに対処するための提案は新しいIETF作業項目について検討中でまだです。
This document set out to list scenarios that are important for the Internet community. While it introduces some design elements in order to understand and discuss tradeoffs, it does not list detailed requirements. In large part, the authors believe that exhaustive and detailed requirements would not be helpful at the expense of embarking on solutions, given our current state of affairs. We do not expect any of the solutions to be perfect when measured from all vantage points. When looking for opportunities to deploy IPv6, reaching too far for perfection could result in losing these opportunities if we are not attentive. Our goal with this document is to support the development of tools to help minimize the tangible problems that we are experiencing now, as well as those problems that we can best anticipate down the road, in hopes of steering the Internet on its best course from here.
この文書は、インターネットコミュニティのための重要なシナリオを一覧表示するために着手しました。それは理解し、トレードオフを議論するために、いくつかの設計要素を紹介するが、それは詳細な要件をリストしていません。大部分では、著者が徹底的かつ詳細な要件は、事務の私たちの現在の状態を考えると、解決策に着手するの犠牲に役立つことはないだろうと信じています。我々は、すべての見晴らしの良い地点から測定した場合の解決策のいずれかが完璧であることを期待しないでください。 IPv6を展開する機会を探したとき、完璧をすぎて到達することは、我々が行き届いていない場合は、これらの機会を失うことにつながる可能性があります。このドキュメントでの私たちの目標は、ここからその最高のコースでインターネットを操縦することを期待して、私たちが今経験している有形の問題だけでなく、私たちは最高の道を予想することができ、それらの問題を最小限に抑えるためのツールの開発をサポートすることです。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リアデ、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[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月。
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2766] Tsirtsis、G.とP. Srisuresh、 "ネットワークアドレス変換 - プロトコル変換（NAT-PT）"、RFC 2766、2000年2月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]のHuitema、C.、 "のTeredo：ネットワークアドレス変換を通じてUDP経由トンネリングのIPv6器（NAT）"、RFC 4380、2006年2月。
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007.
[RFC4925]のLi、X.、ドーキンス、S.、ウォード、D.、およびA.デュラン、 "Softwire問題文"、RFC 4925、2007年7月。
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.
[RFC4966]アウン、C.およびE.デイヴィス、 "ネットワークアドレス変換に移動する理由 - 歴史的な状態にプロトコル変換（NAT-PT）" を、RFC 4966、2007年7月。
[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の翻訳者のアドレス指定"。
[NAT-PT] Wing, D., Ward, D., and A. Durand, "A Comparison of Proposals to Replace NAT-PT", Work in Progress, September 2008.
[NAT-PT]ウイング、D.、ウォード、D.、およびA.デュラン、進歩、2008年9月の作品 "NAT-PTを交換する提案の比較"。
[DUAL-STACK-LITE] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", Work in Progress, May 2011.
[DUAL-STACK-LITE]デュラン、A.、Droms、R.、Woodyatt、J.、およびY.リー、 "IPv4の枯渇に続いてデュアルスタックLiteのブロードバンドの展開"、進歩、2011年5月に作業。
[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月。
[INTAREA-TUNNELS] Touch, J. and M. Townsley, "Tunnels in the Internet Architecture", Work in Progress, March 2010.
[INTAREA-TUNNELS]タッチ、J.とM. Townsley、 "インターネットアーキテクチャにおけるトンネル"、進歩、2010年3月での作業。
[v6OPS-APBP] Despres, R., "A Scalable IPv4-IPv6 Transition Architecture Need for an Address-Port-Borrowing-Protocol (APBP)", Work in Progress, July 2008.
[v6OPS-APBP]デプレ、R.、進歩、2008年7月に仕事を "スケーラブルたIPv4-IPv6移行のアーキテクチャは、アドレス・ポート・借入・プロトコル（APBP）の必要性"。
[HUSTON-IPv4] Huston, G., "IPv4 Address Report", available at http://www.potaroo.net, December 2010.
[HUSTON-のIPv4]ヒューストン、G.、http://www.potaroo.netで入手可能な "IPv4アドレス報告書"、2010年12月。
[NISHITANI-CGN] 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]ペロー、S.、エド。、山形、I.、宮川、S.、中川、A.、およびH.芦田、 "IPアドレス共有スキームのための共通要件"、進歩、2011年3月に作業。
[ISP-SHARED-ADDR] Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, "ISP Shared Address", Work in Progress, September 2010.
[ISP-共有ADDR]進歩、2010年9月山形、I.、宮川、S.、中川、A.、山口、J.、およびH.芦田、 "ISP共有アドレス"、ワーク。
[IPv4-SPACE-ISSUES] Azinger, M. and L. Vegoda, "Issues Associated with Designating Additional Private IPv4 Address Space", Work in Progress, January 2011.
[IPv4の-SPACE-ISSUES] Azinger、M.およびL. Vegoda、 "追加のプライベートIPv4アドレス空間の指定に関する問題関連"、進歩、2011年1月での作業。
[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月。
Appendix A. Acknowledgments
付録A.謝辞
Discussions with a number of people including Dave Thaler, Thomas Narten, Marcelo Bagnulo, Fred Baker, Remi Despres, Lorenzo Colitti, Dan Wing, and Brian Carpenter, and feedback during the Internet Area open meeting at IETF 72, were essential to the creation of the content in this document.
IETF 72でのインターネットエリアオープン会議中デーブターラー、トーマスNarten氏、マルセロBagnulo、フレッド・ベイカー、レミ・デプレ、ロレンツォColitti、ダン・ウィング、そしてブライアン・カーペンターを含む人々の数、およびフィードバックとの議論は、の作成に不可欠でしたこの文書の内容。
Authors' Addresses
著者のアドレス
Jari Arkko Ericsson Jorvas 02420 Finland
ヤリArkkoエリクソン02420 Jorvasフィンランド
EMail: jari.arkko@piuha.net
メールアドレス：jari.arkko@piuha.net
Mark Townsley Cisco Paris 75006 France
マークTownsleyシスコパリ75006フランス
EMail: townsley@cisco.com
メールアドレス：townsley@cisco.com