[要約] 要約：RFC 6127は、IPv4アドレスの枯渇とIPv4とIPv6の共存シナリオに関する情報を提供するものです。 目的：このRFCの目的は、IPv4アドレスの枯渇に対処するためのIPv4とIPv6の共存戦略を提案し、インターネットの持続的な成長を支援することです。
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
IPv4ランアウトおよびIPv4-IPV6共存シナリオ
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.
このドキュメントは、2008年10月にモントリオールの共存暫定会議への入力として作成されたもので、新しいIPv4とIPv6の共存作業を引き受けるために、行動とソフトワイヤのワーキンググループが充電されました。このドキュメントは、当時の思考の歴史的記録として公開されていますが、読者が共存と移行のための現在の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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. 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.
このドキュメントは、2008年10月にモントリオールの共存暫定会議への入力として作成されたもので、新しいIPv4とIPv6の共存作業を引き受けるために、行動とソフトワイヤのワーキンググループが充電されました。このドキュメントは、当時の思考の歴史的記録として公開されていますが、読者が共存と移行のための現在の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が設計されたとき、IPv6が部分的または全体的に有効になることが予想され、同じネットワークノードとホストでIPv4を並べて実行し続けました。この遷移方法は、「デュアルスタック」[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の大規模な展開には時間、労力、多額の投資が必要であることが示されています。近予測可能な地平線[Huston-IPV4]のIPv4アドレスプールの枯渇により、ネットワークオペレーターとインターネットサービスプロバイダーは、一意のグローバルIPv4アドレスへの同じレベルのアクセスを想定しなくなったネットワーク設計を検討せざるを得ません。IPv6のみが、すべてのホストとノードがIPv4のみの機器の最終的な日没までデュアルスタックになるという基本的な仮定を考えると、この懸念を軽減しません。要するに、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を介してIPv4を運ぶことを使用してIPv6への移行とIPv4との共存を支援する方法に加えて、これらのアドレスとプロトコルの翻訳メカニズムが役立つ可能性があるシナリオのいくつかを概説しています。IPv6-over-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アドレスを取得できる状況に限定されないことに注意してください。一般的な展開シナリオは、パブリックアドレスを備えたIPv6側と、1つのパブリックアドレスと従来のIPv4 NATのみを備えたIPv4側でデュアルスタックを実行しています。一般的に言えば、両方の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).
o サブスクライバーまたはサブスクライバーの世帯ごとに1つ未満のグローバルIPv4アドレスでIPv4インターネットに到達します（セクション2.1）。
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).
o デュアルスタックと比較して、運用上のシンプルさのためにIPv6のみのネットワークを実行しますが、すべてではありませんが、接続性（セクション2.3）のためにグローバルIPv4インターネットへのアクセスが必要です。
o Reaching one or more privately addressed IPv4-only servers via IPv6 (Section 2.4).
o IPv6を介して1つ以上のプライベートアドレスIPv4のみのサーバーに到達します（セクション2.4）。
o Accessing IPv6-only servers from IPv4-only clients (Section 2.5).
o IPv4のみのクライアントからのIPv6のみのサーバーにアクセスします（セクション2.5）。
+----+ +---------------+
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は、今日のIPv4インターネットにアクセスするための典型的なモデルを示しています。ゲートウェイデバイスはネットワークアドレスとポート翻訳を実装しています（NAPT、またはより簡単にこのドキュメントでNATと呼ばれます）。NAT機能は多くの目的を果たします。その1つは、インターネットに提示された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とローカルネットワークと同じくらい多くのデバイスで使用するために、1つのグローバル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 [Nishitani-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」または「double-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個のPCがあり、それぞれが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 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].
NAT444には、一見、ネットワーク内のGWデバイスや他のノードを変更せずにCGNを展開できると思われる魅力的なプロパティがあります。グローバルIPv4アドレスのリースを受け入れることができるGWは、翻訳されたIPv4アドレスも同様に受け入れる可能性が非常に高いことは事実ですが、CGNはGWでもサブスクライバーに対しても透過的ではありません。要するに、翻訳されたIPv4アドレスと顧客にグローバルなIPv4アドレスを提供するのは、非常に異なるサービスモデルです。両方の環境で多くのことが機能し続ける可能性がありますが、一部のエンドホストアプリケーションは破損する可能性があり、GWポートマッピング機能は確実に機能しなくなる可能性があります。さらに、サブスクライバーネットワークとサービスプロバイダーネットワーク間のアドレスが[ISP-Shared-ADDR]オーバーラップを行うと、GWのあいまいなルートが誤った方向または黒穴のトラフィックにつながる可能性があります。多くの既存のデバイスは、どのアドレス範囲がプライベートアドレス[IPv4-Space-Issues]を表すかを知ることに依存しているため、新しいプライベートアドレススペースの割り当てを通じてこの重複を解決することは困難です。
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.
以前にサブスクライバーの単一のIPv4アドレスに関連付けられていたネットワーク操作も、NAT444を展開するときにも考慮する必要があります。これらには、トラブルシューティング、操作、会計、ロギングと法的傍受、サービス品質（QOS）機能、スプーフィングとセキュリティ、バックオフィスシステムなどが含まれます。皮肉なことに、これらの考慮事項のいくつかは、実行する必要がある種類の考慮事項と重複しています。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を2回実行しようとするために、および提供されているアドレスがグローバルアドレスではなくなったため、サービスプロバイダーは、サブスクライバーがNATではなくGWでIPv4をルーティングすることを期待して、翻訳されたIPv4アドレスのサブネットの提供を開始できます。GWがIPユナウェアブリッジであることが知られている場合、同じことが当てはまります。これにより、ISPがGWのポリシーを実施できるか、特定の機能を特定できるかどうかについて仮定します。GWで変更を行うための扉を開き始めると、潜在的な設計スペースを大幅に増やしました。次のセクションでは、IPv4アドレスの枯渇に直面してIPv4インターネットに到達するという同じ問題シナリオをカバーしますが、CGN（またはCGNのような）ノードの展開とともにGWを更新または置き換えることができるというしわが追加されました。
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を所有および管理しています。これらの管理されたGWSは、一般に、サービスプロバイダーネットワークおよびアプリケーションとかなり緊密な統合を持っています。これらのタイプの展開では、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間で「分割」される場合があります前のセクションで説明されているように、NAT444を実行するのではなく、CGN。
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：分散型ナットサービス
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.
このアプローチでは、複数のGWSが共通のパブリックIPv4アドレスを共有していますが、個別の非重複ポート範囲があります。そのような各アドレス/ポート範囲ペアは、「分数アドレス」として定義されます。各ホームゲートウェイは、ゲートウェイでは限られたポート範囲のみが利用可能であることを除いて、それが独自の公開アドレスであるかのように住所を使用できます。CGNは、ポート範囲を認識しています。ポート範囲は、たとえばDHCPリースの取得中やポートが必要な場合に動的に割り当てられる可能性があります[V6OPS-APBP]。CGNは、そのサブスクライバーのGWデバイスに向けて分数アドレスにトラフィックを向けます。この方法には、NAT関数のより複雑な側面（アプリケーションレベルゲートウェイ（ALG）、ポートマッピングなど）がGWに残るという利点があり、そのGWの分数アドレスに割り当てられた制限されたポート範囲によってのみ増強されます。CGNは、IPアドレスとポート範囲に基づいてトラフィックを転送し、サブスクライバーネットワーク内から個々のフローを追跡しないか、かなりステートレスの方法で自由に動作できます。CGNノード内のこのアプローチには明らかなスケーリングの利点があり、相互運用可能な方法で連携する必要があるノードとプロトコルの数の観点から複雑さのトレードオフがあります。さらに、GWは、利用可能なポート使用量の観点からは「部分」のみであるにもかかわらず、グローバルIPv4アドレスを受け取っています。IPで直接実行され、分割されたポート数の範囲を使用できないプロトコルを処理する方法と、断片化されたパケットを処理する方法に関しては、まだ未解決の質問がありますが、利点は、2層の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-Tunnels]。これを図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と考えることができますが、仮想ルーティングテーブルではなく仮想ナットテーブルを使用することができます。
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. double-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. サブネットを備えたCGNのシングルナットとGWでのルーティングc。トンネル/リンク分数IP（GWのNAT、CGNでのポートルーティング）
d. Tunnel/link + Single-NAT with overlapping RFC 1918 ("Virtual NAT" tables and routing at the GW)
d. Tunnel/Link single-natオーバーラップRFC 1918（ "Virtual Nat"テーブルとGWでのルーティング）
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は論理的に単一のホストに移動し、そのアクションだけで1つのレベルのNATを排除する可能性があります。ホスト自体が単一のIPv4アドレスのみを必要とする限り、方法BとDは明らかにほとんど関心がありません。これにより、メソッドAとCは、類似のGWデバイス（キャンパスネットワークなど）がない場合のより興味深い方法として残されます。
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.
o ダブルナットの配置でサブスクライバーのNATデバイスに対処します。
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に接続されたGWSまたはホストにアドレススペースを重複させるために、トンネルを使用しました。トンネルまたはリンクの種類は指定されていません。使用されているトンネルがIPv4を介してIPv4を運ぶ場合、IPv6ネットワークの部分は自然に移動する必要はありません。Tunnelトラフィックがネットワークを横断するために、プライベートまたはパブリックの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つの注目すべき例外はソフトワイヤワーキンググループです）。
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（またはホスト、ホストにGWが埋め込まれていると考える場合）にIPv6を持っていると、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.
[デュアルスタックライト]では、これは「デュアルスタックライト」と呼ばれ、ネットワークではないゲートウェイではデュアルスタックであるという事実に屈しています。セクション2.1で導入されているように、ここのCGNが完全に機能するNATである場合、デュアルスタックLite Gatewayの背後にあるホストは、各ゲートウェイに一意の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で識別されるソリューションの方向には、指摘されるべき興味深い動作特性があります。サービスプロバイダーネットワーク全体でIPv4を介して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インターネット上のサーバーに到達することに関するものです。これは、「グリーンフィールド」展開と呼ばれることの重要なシナリオです。1つの例は、運用上のシンプルさのために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よりもトンネルメカニズムをサポートする必要があります。Greenfieldエンタープライズシナリオは、エンタープライズが簡単に変更できる場所が1つしかないという意味で、ネットワークとIPv4インターネットの境界線が1つしかないという意味とは異なります。明らかに、IPv4インターネットは既にそのように動作します。さらに、エンタープライズネットワークのホストは、既存のオペレーティングシステムを備えた市販のデバイス、パーソナルコンピューターです。このシナリオでは、ネットワーク上のすべてのデバイスが「最新の」デュアルスタック対応デバイスであると考えていますが、これらのオペレーティングシステムにカーネルレベルの変更に依存する必要はありません。この制限により、「1つのボックス」タイプのソリューションに駆り立てられ、IPv6をIPv4に翻訳してパブリックインターネットに到達できます。これは、新しいまたは改善されたIETF仕様がこれらのネットワークでのユーザーエクスペリエンスに影響を与える可能性がある1つの状況です。公平に言えば、ネットワークベースのソリューションでさえ、展開するのに時間と労力がかかることに注意する必要があります。これは本質的に、ネットワーク内の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.
この環境に対処するための1つのアプローチは、ネットワークの端（GW）でアプリケーションレベルのプロキシを提供することです。たとえば、IPv4インターネットに到達する必要がある唯一のアプリケーションがWebである場合、HTTP/HTTPSプロキシは、IPv6から外側のIPv4にトラフィックを簡単に変換できます。
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].
もう1つのより一般的なアプローチは、IPv6-to-IPV4 Translatorデバイスを使用することです。さまざまなタイプの翻訳スキームが[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 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.
これを実装する1つのアプローチは、NAT64を使用してIPv6をプライベートIPv4アドレスに変換することです。プライベートIPv4アドレスは、1つ以上の既知のプレフィックス内のIPv6アドレスにマッピングされます。サーバーファームの端にあるGWは、ドメイン名システム（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 Webカメラにアクセスできます。必要なのは、AAAAレコードを適切に更新する機能、IPv6クライアント（Teredo [RFC4380]を使用することができるIPv6の到達可能性を取得する他の方法）、およびNAT64メカニズムです。この意味で、この方法は「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- Over-IPV4トンネルをセットアップする機能を備えたデバイスがIPv6接続されるか、デュアルスタックのいずれかが必要であることが期待されていました。多くの「最新の」デバイススタックにはこの機能があり、トンネルを終了してルーティングする適切なゲートウェイが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.
残念ながら、IPv4から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.
このシナリオに関する主な質問は、タイミングと優先事項に関するものです。このシナリオがいつか重要になる可能性があるという期待は、この執筆時点では容易に受け入れられる可能性がありますが、著者が知っているIPv6のみの重要なサーバー（いくつかの考慮されたケースを超えて）はほとんどまたはまったくありません。このケースについて決定することの難しさは、おそらくIPv6のみのサーバーが表示されるようにIPv4に十分な圧力がある場合、ホストの大部分がIPv6接続またはIPv6を介してIPv6を介して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インターネットで見られるアプリケーションの大部分では、この区別は多かれ少なかれ明確でした。この明確さは、今日の断片化されたアドレス指定と到達可能性に直面して真にエンドツーエンドのアプリケーションを作成することで、今日のオーバーヘッドのために、おそらくほんの少しの部分ではありません。ただし、「サーバー」の現在の概念は変化し始めています。たとえば、ピアツーピアテクニックで、エンドツーエンドの方法で人々を互いに結びつけるというプレッシャーがますます多くを見ているので、単にコンテンツサーバーからクライアントよりも。したがって、「IPv6のみのサーバー」を今日古典的に「IPv4サーバー」と見なしていると考えると、近い将来、これに対する需要はあまりないかもしれません。ただし、インターネットのより分散したモデルを念頭に置いていると、アプリケーションの過去の経験に基づいて通常外挿する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のみのサーバーに到達するために、Legacy 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:
個々のソリューションのセキュリティの側面は、たとえば[デュアルスタックライト]、[RFC6144]、[RFC6147]、[RFC6145]、[RFC6146]、[NAT-PT]、および[RFC49666]で、他の場所でより深く説明しています。。このドキュメントは、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.
このドキュメントの初期バージョンを書いた後、ソフトワイヤーワーキンググループは、既存のツール（トンネリング、IPv4 NAT）といくつかのマイナーな新しいもの（DHCPオプション）[デュアルスタックライト]の組み合わせでセクション2.2シナリオに対処するために充電されました。同様に、行動ワーキンググループは、セクション2.3、2.4、および2.5のシナリオに対処するために充電されました。このドキュメントが公開されている時点で、セクション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.、Moskowitz、R.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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. Gilligan、「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：ネットワークアドレス翻訳（NAT）を介してUDPを介したIPv6のトンネル」、RFC 4380、2006年2月。
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007.
[RFC4925] Li、X.、Dawkins、S.、Ward、D。、およびA. Durand、「Softwire Problem Statement」、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] AOUN、C。およびE. Davies、「ネットワークアドレス翻訳者を移動する理由 - プロトコル翻訳者（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] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M.、およびX. Li、「IPv4/IPv6翻訳者のアドレス指定」、RFC 6052、2010年10月。
[NAT-PT] Wing, D., Ward, D., and A. Durand, "A Comparison of Proposals to Replace NAT-PT", Work in Progress, September 2008.
[Nat-Pt] Wing、D.、Ward、D。、およびA. Durand、「Nat-PTを置き換える提案の比較」、2008年9月、進行中の作業。
[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.
[デュアルスタックライト] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4排出後のデュアルスタックライトブロードバンド展開」、2011年5月の進行中。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144] Baker、F.、Li、X.、Bao、C。、およびK. Yin、「IPv4/IPv6翻訳のフレームワーク」、RFC 6144、2011年4月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145] Li、X.、Bao、C。、およびF. Baker、「IP/ICMP翻訳アルゴリズム」、RFC 6145、2011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. Van Beijnum、「Stateful Nat64：IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳」、RFC 6146、2011年4月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P。、およびI. Van Beijnum、 "DNS64：IPv6クライアントからIPv4サーバーへのネットワークアドレス変換のDNS拡張"、RFC 6147、2011年4月。
[INTAREA-TUNNELS] Touch, J. and M. Townsley, "Tunnels in the Internet Architecture", Work in Progress, March 2010.
[Intarea-Tunnels] Touch、J。and 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] Despres、R。、「スケーラブルなIPv4-IPV6遷移アーキテクチャの必要性アドレスポート販売プロトコル（APBP）」、2008年7月の進行中の作業。
[HUSTON-IPv4] Huston, G., "IPv4 Address Report", available at http://www.potaroo.net, December 2010.
[Huston-IPV4] Huston、G。、「IPv4アドレスレポート」、http：//www.potaroo.net、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.
[Nishitani-CGN] Perreault、S.、Ed。、Yamagata、I.、Miyakawa、S.、Nakagawa、A。、およびH. Ashida、「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-Shared-Addr] Yamagata、I.、Miyakawa、S.、Nakagawa、A.、Yamaguchi、J。、およびH. Ashida、「ISP共有住所」、2010年9月の作業。
[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] Krishnan、S.、Thaler、D。、およびJ. Hoagland、「IPトンネリングに関するセキュリティ上の懸念」、RFC 6169、2011年4月。
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.
Dave Thaler、Thomas Narten、Marcelo Bagnulo、Fred Baker、Remi Despres、Lorenzo Colitti、Dan Wing、Brian Carpenter、IETF 72でのインターネットエリアオープンミーティング中のフィードバックなど、多くの人々との議論は、IETF 72でのオープンミーティングでのフィードバックが、作成に不可欠でした。このドキュメントのコンテンツ。
Authors' Addresses
著者のアドレス
Jari Arkko Ericsson Jorvas 02420 Finland
Jari Arkko Ericsson Jorvas 02420フィンランド
EMail: jari.arkko@piuha.net
Mark Townsley Cisco Paris 75006 France
マークタウンズリーシスコパリ75006フランス
EMail: townsley@cisco.com