[要約] RFC 6180は、IPv6展開中にIPv6移行メカニズムを使用するためのガイドラインです。その目的は、IPv6の展開を支援し、移行メカニズムの適切な使用を促進することです。
Internet Engineering Task Force (IETF) J. Arkko
Request for Comments: 6180 Ericsson
Category: Informational F. Baker
ISSN: 2070-1721 Cisco Systems
May 2011
Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment
IPv6展開中にIPv6遷移メカニズムを使用するためのガイドライン
Abstract
概要
The Internet continues to grow beyond the capabilities of IPv4. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table. Yet, IPv6 deployment requires some effort, resources, and expertise. The availability of many different deployment models is one reason why expertise is required. This document discusses the IPv6 deployment models and migration tools, and it recommends ones that have been found to work well in operational networks in many common situations.
インターネットは、IPv4の機能を超えて成長し続けています。アドレス空間の拡張が明らかに必要です。サブネットで利用可能なプレフィックスとアドレスの数が増加し、アドレス管理の改善があるため、IPv6はテーブル上の唯一の実際のオプションです。しかし、IPv6の展開には、ある程度の努力、リソース、専門知識が必要です。多くの異なる展開モデルの可用性は、専門知識が必要な理由の1つです。このドキュメントでは、IPv6の展開モデルと移行ツールについて説明し、多くの一般的な状況で運用ネットワークでうまく機能することがわかったものを推奨しています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6180.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6180で取得できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Choosing a Deployment Model . . . . . . . . . . . . . . . 6
4. Guidelines for IPv6 Deployment . . . . . . . . . . . . . . . . 7
4.1. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 8
4.2. Crossing IPv4 Islands . . . . . . . . . . . . . . . . . . 10
4.3. IPv6-Only Core Network . . . . . . . . . . . . . . . . . . 11
4.4. IPv6-Only Deployment . . . . . . . . . . . . . . . . . . . 11
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20
The Internet continues to grow beyond the capabilities of IPv4. The tremendous success of the Internet has strained the IPv4 address space, which is no longer sufficient to fuel future growth. At the time of this writing, August 2010, the IANA "free pool" contains only 14 unallocated unicast IPv4 /8 prefixes. Credible estimates based on past behavior suggest that the Regional Internet Registries (RIRs) will exhaust their remaining address space by early 2012, apart from the development of a market in IPv4 address space. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table.
インターネットは、IPv4の機能を超えて成長し続けています。インターネットの途方もない成功により、IPv4アドレス空間に緊張していますが、これはもはや将来の成長を促進するのに十分ではありません。2010年8月のこの執筆時点で、IANAの「フリープール」には、14の未割り当てUnicast IPv4 /8プレフィックスのみが含まれています。過去の行動に基づいた信頼できる推定では、IPv4アドレススペースの市場の開発とは別に、地域のインターネットレジストリ（RIRS）が残りの住所スペースを排出することを示唆しています。アドレス空間の拡張が明らかに必要です。サブネットで利用可能なプレフィックスとアドレスの数が増加し、アドレス管理の改善があるため、IPv6はテーブル上の唯一の実際のオプションです。
John Curran, in "An Internet Transition Plan" [RFC5211], gives estimated dates for significant points in the transition; while the tail of the process will likely be long, it is clear that deployment is a present reality and requirement.
ジョン・カランは、「インターネット移行計画」[RFC5211]で、移行の重要なポイントの推定日を与えます。プロセスの尾はおそらく長くなるでしょうが、展開が現在の現実と要件であることは明らかです。
Accordingly, many organizations have employed or are planning to employ IPv6 in their networks. Yet, IPv6 deployment requires some effort, resources, and expertise. This is largely a natural part of maintaining and evolving a network: changing requirements are taken into account in normal planning, procurement, and update cycles. Very large networks have successfully adopted IPv6 alongside IPv4, with surprisingly little effort.
したがって、多くの組織がネットワークでIPv6を採用または採用しているか、または計画しています。しかし、IPv6の展開には、ある程度の努力、リソース、専門知識が必要です。これは主にネットワークを維持および進化させることの自然な部分です。要件の変更は、通常の計画、調達、および更新サイクルで考慮されます。非常に大きなネットワークは、IPv4と一緒にIPv6を採用していることに成功しており、驚くほど努力がほとんどありません。
However, in order to successfully make this transition, some amount of new expertise is required. Different types of experience will be required: basic understanding of IPv6 mechanisms, debugging tools, product capabilities and caveats when used with IPv6, and so on. The availability of many different IPv6 deployment models and tools is an additional reason why expertise is required. These models and tools have been developed over the years at the IETF, some for specific circumstances and others for more general use. They differ greatly in their principles of operation. Over time, views about the best ways to employ the tools have evolved. Given the number of options, network managers are understandably confused. They need guidance on recommended approaches to IPv6 deployment.
ただし、この移行を正常に行うには、ある程度の新しい専門知識が必要です。さまざまな種類のエクスペリエンスが必要です。IPv6メカニズムの基本的な理解、デバッグツール、製品機能、IPv6で使用する場合の警告など。多くの異なるIPv6展開モデルとツールの可用性は、専門知識が必要な追加の理由です。これらのモデルとツールは、IETFで長年にわたって開発されており、特定の状況に向けて、より一般的な使用のために開発されています。それらは、運用の原則が大きく異なります。時間が経つにつれて、ツールを採用する最良の方法についての見解が進化しました。オプションの数を考えると、ネットワークマネージャーは当然のことながら混乱しています。IPv6展開への推奨アプローチに関するガイダンスが必要です。
The rest of this document is organized as follows. Section 2 introduces some terminology, Section 3 discusses some of the general principles behind choosing particular deployment models and tools, Section 4 goes through the recommended deployment models for common situations, and Section 5 provides some concluding remarks about the choice between these models.
このドキュメントの残りの部分は、次のように整理されています。セクション2では、いくつかの用語を紹介します。セクション3では、特定の展開モデルとツールの選択の背後にある一般原則のいくつかについて説明し、セクション4は一般的な状況で推奨される展開モデルを通過し、セクション5では、これらのモデル間の選択に関するいくつかの結論を説明します。
Many networks can follow one of the four scenarios described in this document. However, variations will certainly occur in the details, and there will be questions, such as the particular choice of tunneling solution, for which there is no "one size fits all" answer. Network managers must each take the responsibility of choosing the best solution for their own case. This document does not attempt to provide guidance for all possible networking situations. Also, a systematic operational plan for the transition is required, but the details depend entirely on the individual network.
多くのネットワークは、このドキュメントで説明されている4つのシナリオのいずれかに従うことができます。ただし、詳細にバリエーションが確実に発生し、トンネリングソリューションの特定の選択など、「すべてのサイズに適合する」回答はありません。ネットワークマネージャーはそれぞれ、自分のケースに最適なソリューションを選択する責任を負う必要があります。このドキュメントは、可能なすべてのネットワーキング状況へのガイダンスを提供しようとはしていません。また、移行のための体系的な運用計画が必要ですが、詳細は個々のネットワークに完全に依存します。
In this document, the following terms are used.
このドキュメントでは、次の用語が使用されています。
IPv4/IPv4 NAT: refers to any IPv4-to-IPv4 network address translation algorithm, both "Basic NAT" and "Network Address/Port Translator (NAPT)", as defined by [RFC2663].
IPv4/IPv4 NAT：[RFC2663]で定義されているように、「基本NAT」と「ネットワークアドレス/ポート翻訳者（NAPT）」の両方のIPv4-to-IPV4ネットワークアドレス変換アルゴリズムを指します。
Dual Stack: refers to a technique for providing complete support for both Internet protocols -- IPv4 and IPv6 -- in hosts and routers [RFC4213].
デュアルスタック：ホストとルーター[RFC4213]で、インターネットプロトコル（IPv4とIPv6）の両方の完全なサポートを提供するための手法を指します。
Dual Stack Lite: also called "DS-Lite", refers to a technique that employs tunneling and IPv4/IPv4 NAT to provide IPv4 connectivity over IPv6 networks [DS-lite].
デュアルスタックライト：「DS-Lite」とも呼ばれ、TunnelingとIPv4/IPv4 NATを使用してIPv6ネットワークを介してIPv4接続を提供する手法を指します[DS-Lite]。
IPv4-only domain: as defined in [RFC6144], a routing domain in which applications can only use IPv4 to communicate, whether due to host limitations, application limitations, or network limitations.
IPv4のみのドメイン：[RFC6144]で定義されているように、ホストの制限、アプリケーションの制限、またはネットワークの制限によるものであっても、アプリケーションがIPv4のみを使用して通信できるルーティングドメイン。
IPv6-only domain: as defined in [RFC6144], a routing domain in which applications can only use IPv6 to communicate, whether due to host limitations, application limitations, or network limitations.
IPv6のみのドメイン：[RFC6144]で定義されているように、ホストの制限、アプリケーションの制限、またはネットワークの制限によるものであろうと、アプリケーションがIPv6のみを使用して通信できるルーティングドメイン。
NAT-PT: refers to a specific, old design of a Network Address Translator - Protocol Translator defined in [RFC2766] and deprecated due to the reasons stated in [RFC4966].
NAT -PT：[RFC2766]で定義され、[RFC4966]に記載されている理由により非推奨されているネットワークアドレス翻訳者 - プロトコル翻訳者の特定の古い設計を指します。
The primary goal is to facilitate the continued growth of the networking industry and deployment of Internet technology at relatively low capital and operational expense without destabilizing deployed services or degrading customer experience. This is at risk with IPv4 due to the address runout; economics teaches us that a finite resource, when stressed, becomes expensive, either in the actual cost of the resource or in the complexity of the technology and processes required to manage it. It is also at risk while both IPv4 and IPv6 are deployed in parallel, as it costs more to run two technologies than one. To this end, since IPv4 clearly will not scale to meet our insatiable requirements, the primary technical goals are the global deployment of IPv6 both in the network, in its service infrastructure, and by applications, resulting in the end of the requirement to deploy two IP versions and the obsolescence of transitional mechanisms. Temporary goals in support of this focus on enabling parts of the Internet to employ IPv6 and disable IPv4 before the entire Internet has done so.
主な目標は、展開されたサービスや顧客体験を低下させることなく、比較的低い資本および運用費用でネットワーキング業界の継続的な成長とインターネットテクノロジーの展開を促進することです。これは、アドレスのランアウトにより、IPv4で危険にさらされています。Economicsは、有限のリソースが、ストレスを受けたときに、リソースの実際のコストまたはそれを管理するために必要な技術とプロセスの複雑さのいずれかで高価になることを教えています。また、IPv4とIPv6の両方が並行して展開されますが、1つより2つのテクノロジーを実行するにはより多くの費用がかかるため、危険にさらされています。この目的のために、IPv4は飽くことのない要件を満たすために明らかに拡大しないため、主要な技術的目標は、ネットワーク、そのサービスインフラストラクチャ、およびアプリケーションの両方でのIPv6のグローバルな展開であり、2つの展開の要件が終了することになります。IPバージョンと移行メカニズムの陳腐化。インターネット全体がそうする前に、インターネットの一部がIPv6を使用し、IPv4を無効にすることを可能にすることに焦点を当てることをサポートする一時的な目標。
The end goal is network-wide native IPv6 deployment, resulting in the obsolescence of transitional mechanisms based on encapsulation, tunnels, or translation, and also resulting in the obsolescence of IPv4. Transition mechanisms, taken as a class, are a means to an end, to simplify the process for the network administration.
最終目標は、ネットワーク全体のネイティブIPv6の展開であり、カプセル化、トンネル、または翻訳に基づいた移行メカニズムの陳腐化をもたらし、IPv4の陳腐化をもたらします。クラスとして取られた遷移メカニズムは、ネットワーク管理のプロセスを簡素化するための目的の手段です。
However, the goals, constraints, and opportunities for IPv6 deployment differ from one case to another. There is no single right model for IPv6 deployment, just like there is no one and only model for IPv4 network design. Some guidelines can be given, however. Common deployment models that have been found to work well are discussed in Section 4, and the small set of standardized IETF migration tools support these models. But first it may be useful to discuss some general principles that guide our thinking about what is a good deployment model.
ただし、IPv6の展開の目標、制約、および機会は、ケースによって異なります。IPv4ネットワーク設計の唯一のモデルがないように、IPv6展開には単一の正しいモデルはありません。ただし、いくつかのガイドラインに示すことができます。うまく機能することがわかった一般的な展開モデルについては、セクション4で説明し、標準化されたIETF移行ツールの小さなセットがこれらのモデルをサポートしています。しかし、最初に、優れた展開モデルであるものについて私たちの考えを導くいくつかの一般原則を議論することは有用かもしれません。
It is important to start the deployment process in a timely manner. Most of the effort is practical -- network audit, network component choices, network management, planning, implementation -- and at the time of this writing, reasonably easily achievable. There is no particular advantage to avoiding dealing with IPv6 as part of the normal network planning cycle. The migration tools already exist, and while additional features continue to be developed, it is not expected that they radically change what networks have to do. In other words, there is no point in waiting for an improved design.
展開プロセスをタイムリーに開始することが重要です。ネットワーク監査、ネットワークコンポーネントの選択、ネットワーク管理、計画、実装など、ほとんどの努力は実用的です。この執筆時点では、合理的に簡単に達成できます。通常のネットワーク計画サイクルの一部としてIPv6への取引を避けることに特に利点はありません。移行ツールはすでに存在しており、追加機能は引き続き開発されていますが、ネットワークがしなければならないことを根本的に変えることは予想されません。言い換えれば、改善されたデザインを待つ意味はありません。
There are only a few exceptional networks where coexistence with IPv4 is not a consideration at all. These networks are typically new deployments, strictly controlled by a central authority, and have no need to deal with legacy devices. For example, specialized machine-to-machine networks that communicate only to designated servers, such as Smart Grids, can easily be deployed as IPv6-only networks. Mobile telephone network operators, especially those using 3GPP (Third Generation Partnership Project), have seriously considered IPv6-only operation, and some have deployed it. Research networks that can be separated from the IPv4 Internet to find out what happens are also a candidate. In most other networks, IPv4 has to be considered. A typical requirement is that older, IPv4-only applications, systems, or services must be accommodated. Most networks that cross administrative boundaries or allow end-user equipment have such requirements. Even in situations where the network consists of only new, IPv6-capable devices, it is typically required that the devices be able to communicate with the IPv4 Internet.
IPv4と共存することはまったく考慮されない例外的なネットワークはわずかです。これらのネットワークは通常、中央当局によって厳密に制御される新しい展開であり、レガシーデバイスに対処する必要はありません。たとえば、スマートグリッドなどの指定されたサーバーとのみ通信する専門のマシンからマシンへのネットワークは、IPv6のみのネットワークとして簡単に展開できます。携帯電話ネットワークオペレーター、特に3GPP（第3世代パートナーシッププロジェクト）を使用しているオペレーターは、IPv6のみの運用を真剣に検討しており、一部はそれを展開しています。IPv4インターネットから分離できる研究ネットワークは、何が起こるかを知ることも候補者です。他のほとんどのネットワークでは、IPv4を考慮する必要があります。典型的な要件は、古いIPv4のみのアプリケーション、システム、またはサービスに対応する必要があることです。管理境界を越えたり、エンドユーザー機器を許可したりするほとんどのネットワークには、そのような要件があります。ネットワークが新しいIPv6対応デバイスのみで構成されている状況でさえ、通常、デバイスがIPv4インターネットと通信できることが必要です。
It is expected that after a period of supporting both IPv4 and IPv6, IPv4 can eventually be turned off. This should happen gradually. For instance, a service provider network might stop providing IPv4 service within its own network, while still allowing its IPv6 customers to access the rest of the IPv4 Internet through overlay, proxy, or translation services. Regardless of progress in supporting IPv6, it is widely expected that some legacy applications and some networks will continue to run only over IPv4 for many years. All deployment scenarios need to deal with this situation.
IPv4とIPv6の両方をサポートする期間の後、IPv4は最終的にオフになる可能性があります。これは徐々に起こるはずです。たとえば、サービスプロバイダーネットワークは、独自のネットワーク内でIPv4サービスの提供を停止する可能性がありますが、IPv6のお客様はオーバーレイ、プロキシ、または翻訳サービスを介してIPv4インターネットの残りの部分にアクセスできるようになります。IPv6のサポートの進捗に関係なく、一部のレガシーアプリケーションと一部のネットワークは、長年にわたってIPv4を超えてのみ実行され続けることが広く期待されています。すべての展開シナリオは、この状況に対処する必要があります。
The first requirement is that the model or tool actually allow communications to flow and services to appropriately be delivered to customers without perceived degradation. While this sounds too obvious to even state, it is sometimes not easy to ensure that a proposed model does not have failure modes related to supporting older devices, for instance. A network that is not serving all of its users is not fulfilling its task.
最初の要件は、モデルまたはツールが実際に通信が流れ、サービスを適切に劣化せずに顧客に提供できるようにすることです。これは明白すぎると思われますが、提案されたモデルに古いデバイスのサポートに関連する障害モードがないことを保証することは容易ではない場合があります。すべてのユーザーにサービスを提供していないネットワークは、そのタスクを満たしていません。
The ability to communicate is far more important than fine-grained performance differences. In general, it is not productive to focus on the optimization of a design that is intended to be temporary, such as a migration solution necessarily is. Consequently, existing tools are often preferred over new ones, even if for some specific circumstance it would be possible to construct a slightly more efficient design.
コミュニケーションの能力は、きめ細かいパフォーマンスの違いよりもはるかに重要です。一般に、移行ソリューションなど、一時的であることを目的とした設計の最適化に焦点を当てることは生産的ではありません。したがって、特定の状況では、より効率的な設計を構築することが可能であっても、既存のツールは新しいツールよりも好まれます。
Similarly, migration tools that can be disposed after a period of co-existence are preferred over tools that require more permanent changes. Such permanent changes may incur costs even after the transition to IPv6 has been completed.
同様に、より恒久的な変更を必要とするツールよりも、共存期間後に処分できる移行ツールが好まれます。このような永続的な変更は、IPv6への移行が完了した後でもコストが発生する可能性があります。
Looking back on the deployment of Internet technology, some of the factors, as described in [RFC5218] and [Baker.Shanghai], that have been important for success include:
インターネットテクノロジーの展開を振り返ると、[RFC5218]と[Baker.Shanghai]に記載されている要因のいくつかは、成功のために重要でした。
o The ability to offer a valuable service. In the case of the Internet, connectivity has been this service.
o 貴重なサービスを提供する能力。インターネットの場合、接続性はこのサービスでした。
o The ability to deploy the solution in an incremental fashion.
o ソリューションを漸進的に展開する機能。
o Simplicity. This has been a key factor in making it possible for all types of devices to support the Internet protocols.
o シンプルさ。これは、あらゆるタイプのデバイスがインターネットプロトコルをサポートできるようにするための重要な要素です。
o Openly available implementations. These make it easier for researchers, start-ups, and others to build on or improve existing components.
o 公然と利用可能な実装。これらにより、研究者、新興企業、その他が既存のコンポーネントの上に構築または改善しやすくなります。
o The ability to scale. The IPv4 Internet grew far larger than its original designers had anticipated, and scaling limits only became apparent 20-30 years later.
o スケーリングする能力。IPv4インターネットは、元の設計者が予想していたよりもはるかに大きくなり、スケーリング制限は20〜30年後にしか明らかになりました。
o The design supports robust interoperability rather than mere correctness. This is important in order to ensure that the solution works in different circumstances and in an imperfectly controlled world.
o 設計は、単なる正確性ではなく、堅牢な相互運用性をサポートします。これは、ソリューションが異なる状況および不完全に制御された世界で機能することを保証するために重要です。
Similar factors are also important when choosing IPv6 migration tools. Success factors should be evaluated in the context of a migration solution. For instance, incremental deployability and lack of dependencies to components that are under someone else's control are key factors.
IPv6移行ツールを選択する際には、同様の要因も重要です。成功要因は、移行ソリューションのコンテキストで評価する必要があります。たとえば、他の誰かの制御下にあるコンポーネントへの増分の展開性と依存関係の欠如が重要な要素です。
It is also essential that any chosen designs allow the network to be maintained, serviced, diagnosed, and measured. The ability of the network to operate under many different circumstances and surprising conditions is a key. Any large network that employs brittle components will incur significant support costs.
また、選択された設計では、ネットワークを維持、サービス、診断、測定することを可能にすることも不可欠です。多くの異なる状況や驚くべき条件の下で動作するネットワークの能力が重要です。脆性コンポーネントを使用する大規模なネットワークは、大幅なサポートコストが発生します。
Properly executed IPv6 deployment normally involves a step-wise approach where individual functions or parts of the network are updated at different times. For instance, IPv6 connectivity has to be established and tested before DNS entries with IPv6 addresses can be provisioned. Or, specific services can be moved to support IPv6 earlier than others. In general, most deployment models employ a very similar network architecture for both IPv4 and IPv6. The principle of changing only the minimum amount necessary is applied here. As a result, some features of IPv6, such as the ability to have an effectively unlimited number of hosts on a subnet, may not be available in the short term.
適切に実行されたIPv6展開には、通常、ネットワークの個々の機能または部分が異なる時間に更新される段階的なアプローチが含まれます。たとえば、IPv6の接続性は、IPv6アドレスを使用したDNSエントリをプロビジョニングする前に確立およびテストする必要があります。または、特定のサービスを他のサービスよりも早くIPv6をサポートするために移動することができます。一般に、ほとんどの展開モデルは、IPv4とIPv6の両方で非常によく似たネットワークアーキテクチャを採用しています。必要な最小額のみを変更するという原則は、ここで適用されます。その結果、サブネットで効果的に無制限の数のホストを持つ機能など、IPv6のいくつかの機能は、短期的には利用できない場合があります。
This section presents a number of common scenarios along with recommended deployment tools for them. We start from the most obvious deployment situation where native connectivity is available and both IP versions are used. Since native IPv6 connectivity is not available in all networks, our second scenario looks at ways of arranging such connectivity over the IPv4 Internet. The third scenario is more advanced and looks at a service provider network that runs only on IPv6 but that is still capable of providing both IPv6 and IPv4 services. The fourth and most advanced scenario focuses on translation, at the application or the network layer.
このセクションでは、多くの一般的なシナリオと、推奨される展開ツールを提示します。ネイティブ接続が利用可能で、両方のIPバージョンが使用される最も明白な展開状況から始めます。ネイティブIPv6接続はすべてのネットワークで利用できないため、2番目のシナリオは、IPv4インターネット上のこのような接続を配置する方法を検討します。3番目のシナリオはより高度であり、IPv6でのみ実行されるサービスプロバイダーネットワークを調べますが、それでもIPv6サービスとIPv4サービスの両方を提供できます。4番目と最も高度なシナリオは、アプリケーションまたはネットワークレイヤーでの翻訳に焦点を当てています。
Note that there are many other possible deployment models and existing specifications to support such models. These other models are not necessarily frowned upon. However, they are not expected to be the mainstream deployment models, and consequently, the associated specifications are typically not IETF Standards Track RFCs. Network managers should not adopt these non-mainstream models lightly, however, as there is little guarantee that they work well. There are also models that are believed to be problematic. An older model of IPv6-IPv4 translation (NAT-PT) [RFC2766] suffers from a number of drawbacks arising from, for example, its attempt to capture DNS queries on path [RFC4966]. Another example regarding the preference to employ tunneling instead of double translation will be discussed later in this document.
そのようなモデルをサポートするために、他にも多くの可能な展開モデルと既存の仕様があることに注意してください。これらの他のモデルは必ずしも眉をひそめているわけではありません。ただし、それらは主流の展開モデルであるとは期待されておらず、その結果、関連する仕様は通常、IETF標準を追跡するRFCではありません。ただし、ネットワークマネージャーは、これらの非メインストリームモデルを軽視してはなりません。問題があると考えられているモデルもあります。IPv6-IPV4翻訳（NAT-PT）[RFC2766]の古いモデルは、たとえばパスでDNSクエリをキャプチャしようとする試み[RFC4966]から生じる多くの欠点に苦しんでいます。二重翻訳の代わりにトンネリングを使用する好みに関する別の例については、このドキュメントの後半で説明します。
The simplest deployment model is dual stack: one turns on IPv6 throughout one's existing IPv4 network and allows applications using the two protocols to operate as ships in the night. This model is applicable to most networks -- home, enterprise, service provider, or content provider network.
最もシンプルな展開モデルはデュアルスタックです。1つは既存のIPv4ネットワーク全体でIPv6をオンにし、2つのプロトコルを使用したアプリケーションが夜間に船舶として動作できるようにします。このモデルは、ホーム、エンタープライズ、サービスプロバイダー、またはコンテンツプロバイダーネットワークなどのほとんどのネットワークに適用できます。
The purpose of this model is to support any type of device and communication, and to make it an end-to-end choice which IP version is used between the peers. There are minimal assumptions about the capabilities and configuration of hosts in these networks. Native connectivity avoids problems associated with the configuration of tunnels and Maximum Transmission Unit (MTU) settings. As a result, these networks are robust and reliable. Accordingly, this is the recommended deployment model for most networks and is supported by IETF standards such as dual stack [RFC4213] and address selection [RFC3484]. Similarly, while there are some remaining challenges, this model is also preferred by many service providers and network managers [RFC6036] [IPv6-only-experience].
このモデルの目的は、あらゆるタイプのデバイスと通信をサポートし、ピア間でどのIPバージョンを使用するかをエンドツーエンドの選択にすることです。これらのネットワーク内のホストの機能と構成については、最小限の仮定があります。ネイティブ接続は、トンネルの構成と最大透過ユニット（MTU）設定に関連する問題を回避します。その結果、これらのネットワークは堅牢で信頼性が高くなります。したがって、これはほとんどのネットワークに推奨される展開モデルであり、デュアルスタック[RFC4213]やアドレス選択[RFC3484]などのIETF標準によってサポートされています。同様に、残りの課題はいくつかありますが、このモデルは多くのサービスプロバイダーやネットワークマネージャー[RFC6036] [IPv6のみの経験]よりも好まれています。
The challenges associated with this model are twofold. First, while dual stack allows each individual network to deploy IPv6 on their own, actual use still requires participation from all parties between the peers. For instance, the peer must be reachable over IPv6, have an IPv6 address to itself, and advertise such an address in the relevant naming service (such as the DNS). This can create a situation where IPv6 has been turned on in a network, but there is little actual traffic. One direct way to affect this situation is to ensure that major destinations of traffic are prepared to receive IPv6 traffic. Current Internet traffic is highly concentrated on selected content provider networks, and making a change in even a small number of these networks can have significant effects. This was recently observed when YouTube started supporting IPv6 [networkworld.youtube]. There are scenarios where these means are insufficient. The following sections discuss deployment models that enable parts of the network to deploy IPv6 faster than other parts.
このモデルに関連する課題は2つあります。まず、デュアルスタックでは、個々のネットワークがIPv6を独自に展開できるようにしますが、実際の使用には、ピア間のすべての関係者からの参加が必要です。たとえば、ピアはIPv6を介して到達可能であり、IPv6アドレスを自体に持っている必要があり、関連するネーミングサービス（DNSなど）でそのようなアドレスを宣伝する必要があります。これにより、IPv6がネットワークでオンになっている状況を作成できますが、実際のトラフィックはほとんどありません。この状況に影響を与える直接的な方法の1つは、トラフィックの主要な目的地がIPv6トラフィックを受け取る準備ができていることを保証することです。現在のインターネットトラフィックは、選択されたコンテンツプロバイダーネットワークに非常に集中しており、これらのネットワークの少数でも変更することで大きな効果があります。これは、YouTubeがIPv6 [NetworkWorld.Youtube]のサポートを開始したときに最近観察されました。これらの手段が不十分なシナリオがあります。次のセクションでは、ネットワークの部分が他の部品よりも速くIPv6を展開できるようにする展開モデルについて説明します。
The second challenge is that not all applications deal gracefully with situations where one of the alternative destination addresses works unreliably. For instance, if IPv6 connectivity is unreliable, it may take a long time for some applications to switch over to IPv4. As a result, many content providers are shying away from advertising IPv6 addresses in DNS. This in turn exacerbates the first challenge. Long term, the use of modern application toolkits and APIs solves this problem. In the short term, some content providers and user network managers have made a mutual agreement to resolve names to IPv6 addresses. Such agreements are similar to peering agreements and have been seen as necessary by many content providers. These "whitelisting" practices have some downsides as well, however. In particular, they create a dependency on an external party for moving traffic to IPv6. Nevertheless, there are many types of traffic in the Internet, and only some of it requires such careful coordination. Popular peer-to-peer systems can automatically and reliably employ IPv6 connectivity where it is available, for instance.
2番目の課題は、すべてのアプリケーションが代替の宛先アドレスの1つが信頼できない状況に優雅に対処するわけではないということです。たとえば、IPv6接続が信頼できない場合、一部のアプリケーションがIPv4に切り替えるには長い時間がかかる場合があります。その結果、多くのコンテンツプロバイダーは、DNSのIPv6アドレスの広告から遠ざかっています。これは、最初の課題を悪化させます。長期的には、最新のアプリケーションツールキットとAPIの使用がこの問題を解決します。短期的には、一部のコンテンツプロバイダーとユーザーネットワークマネージャーは、IPv6アドレスに名前を解決するために相互契約を結びました。このような契約は、ピアリング契約に似ており、多くのコンテンツプロバイダーに必要であると見なされています。ただし、これらの「ホワイトリスト」プラクティスには、いくつかの欠点もあります。特に、トラフィックをIPv6に移動するための外部パーティへの依存性を生み出します。それにもかかわらず、インターネットにはトラフィックには多くの種類があり、そのような慎重な調整が必要なものの一部だけがあります。人気のあるピアツーピアシステムは、たとえば利用可能な場合、IPv6接続を自動的かつ確実に使用できます。
Despite these challenges, the native dual-stack connectivity model remains the recommended approach. It is responsible for a large part of the progress on worldwide IPv6 deployment to date. The largest IPv6 networks -- notably, national research and education networks, Internet II, RENATER, and others -- employ this approach.
これらの課題にもかかわらず、ネイティブのデュアルスタック接続モデルは引き続き推奨されるアプローチです。これは、これまでに世界的なIPv6展開の進捗の大部分を担当しています。最大のIPv6ネットワーク（特に、国家研究および教育ネットワーク、インターネットII、Renaterなど）がこのアプローチを採用しています。
The original intent of dual stack was to deploy both IP versions alongside each other before IPv4 addresses were to run out. As we know, this never happened and deployment now has to take place with limited IPv4 addresses. Employing dual stack together with a traditional IPv4 address translator (IPv4/IPv4 NAT) is a very common configuration. If the address translator is acceptable for the network from a pure IPv4 perspective, this model can be recommended from a dual-stack perspective as well. The advantage of IPv6 in this model is that it allows direct addressing of specific nodes in the network, creating a contrast to the translated IPv4 service, as noted in [RFC2993] and [shared-addressing-issues]. As a result, it allows the construction of IPv6-based applications that offer more functionality.
デュアルスタックの当初の意図は、IPv4アドレスが使い果たす前に、両方のIPバージョンを互いに展開することでした。私たちが知っているように、これは決して起こりませんでしたし、限られたIPv4アドレスで展開が行われるようになりました。従来のIPv4アドレス翻訳者（IPv4/IPv4 NAT）と一緒にデュアルスタックを使用することは、非常に一般的な構成です。アドレス翻訳者が純粋なIPv4の観点からネットワークに受け入れられる場合、このモデルはデュアルスタックの観点からも推奨できます。このモデルでのIPv6の利点は、[RFC2993]および[共有アドレスリッジ]に記載されているように、ネットワーク内の特定のノードの直接アドレス指定を可能にし、翻訳されたIPv4サービスとのコントラストを作成することです。その結果、より多くの機能を提供するIPv6ベースのアプリケーションの構築が可能になります。
There may also be situations where a traditional IPv4 address translator is no longer sufficient. For instance, in typical residential networks, each subscriber is given one global IPv4 address, and the subscriber's IPv4/IPv4 NAT device may use this address with as many devices as it 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. The dual-stack model is still applicable even in these networks, but the IPv4/IPv4 Network Address Transition (NAT) functionality may need to be relocated and enhanced. On some networks it is possible to employ overlapping private address space [L2-NAT] [DS-extra-lite]. Other networks may require a combination of IPv4/IPv4 NAT enhancements and tunneling. These scenarios are discussed further in Section 4.3.
また、従来のIPv4アドレス翻訳者で十分でない状況もあります。たとえば、典型的な住宅ネットワークでは、各サブスクライバーに1つのグローバルIPv4アドレスが与えられ、サブスクライバーのIPv4/IPv4 NATデバイスは、処理できる数のデバイスでこのアドレスを使用できます。IPv4アドレススペースがより制約され、IPv6への実質的な移動がなければ、サービスプロバイダーが複数のサブスクライバーに単一のグローバルIPv4アドレスを割り当てるよう圧力をかけることが期待されます。実際、いくつかの展開では、これはすでに当てはまります。デュアルスタックモデルは、これらのネットワークでも適用可能ですが、IPv4/IPv4ネットワークアドレストランジション（NAT）機能を再配置して強化する必要がある場合があります。一部のネットワークでは、重複するプライベートアドレススペース[L2-NAT] [DS-EXTRA-LITE]を使用することができます。他のネットワークでは、IPv4/IPv4 NATの機能強化とトンネリングの組み合わせが必要になる場合があります。これらのシナリオについては、セクション4.3でさらに説明します。
Native IPv6 connectivity is not always available, but fortunately it can be established using tunnels. Tunneling introduces some additional complexity. It also increases the probability that the Path MTU algorithm will be used, as many implementations derive their default MTU from the Ethernet frame size; ICMP filtering interacts poorly with the Path MTU algorithm in [RFC1981]. However, its benefit is that it decouples addressing inside and outside the tunnel, making it easy to deploy IPv6 without having to modify routers along the path. Tunneling should be used when native connectivity cannot be established, such as when crossing another administrative domain or a router that cannot be easily reconfigured.
ネイティブのIPv6接続は常に利用可能ではありませんが、幸いなことに、トンネルを使用して確立できます。トンネリングは、いくつかの追加の複雑さを導入します。また、多くの実装がデフォルトのMTUをイーサネットフレームサイズから導き出すため、パスMTUアルゴリズムが使用される確率も向上します。ICMPフィルタリングは、[RFC1981]のパスMTUアルゴリズムとの相互作用が不十分です。ただし、その利点は、トンネルの内側と外側にアドレス指定することを切り離し、パスに沿ってルーターを変更することなくIPv6を簡単に展開できることです。別の管理ドメインや簡単に再構成できないルーターを横切る場合など、ネイティブ接続を確立できない場合は、トンネルを使用する必要があります。
There are several types of tunneling mechanisms, including manually configured IPv6-over-IPv4 tunnels [RFC4213], 6to4 [RFC3056], automatic host-based tunnels [RFC4380], tunnel brokers [RFC3053], running IPv6 over MPLS with IPv6 Provider Edge Routers (6PE) [RFC4798], the use of Virtual Private Networks (VPNs) or mobility tunnels to carry both IPv4 and IPv6 [RFC4301] [RFC5454] [RFC5555] [RFC5844], and many others. More advanced solutions provide a mesh-based framework of tunnels [RFC5565].
手動で構成されたIPv6-over-IPV4トンネル[RFC4213]、6to4 [RFC3056]、自動ホストベースのトンネル[RFC4380]、トンネルブローカー[RFC3053]、IPV6プロビデイダーエッジリュールのランニングIPv6のIPv6を実行するなど、トンネルメカニズムにはいくつかのタイプがあります。（6PE）[RFC4798]、仮想プライベートネットワーク（VPNS）またはモビリティトンネルの使用により、IPv4とIPv6とIPv6 [RFC4301] [RFC5454] [RFC5555] [RFC5844]など。より高度なソリューションは、トンネルのメッシュベースのフレームワークを提供します[RFC5565]。
On a managed network, there are no major challenges with tunneling beyond the possible configuration and MTU problems. Tunneling is very widely deployed both for IPv6 connectivity and other reasons, and is well understood. In general, the IETF recommends that tunneling be used if it is necessary to cross a segment of IP version X when communicating from IP version Y to Y. An alternative design would be to employ protocol translation twice. However, this design involves problems similar to those created by IPv4 address translation and is largely untried technology in any larger scale.
管理されたネットワークでは、可能な構成やMTUの問題を超えてトンネルに大きな課題はありません。トンネリングは、IPv6接続とその他の理由の両方で非常に広く展開されており、よく理解されています。一般に、IETFは、IPバージョンYからYに通信するときにIPバージョンXのセグメントを越える必要がある場合、トンネリングを使用することを推奨します。代替設計は、プロトコル翻訳を2回使用することです。ただし、この設計には、IPv4アドレスの翻訳によって作成されたものと同様の問題が含まれ、大規模なテクノロジーがほとんどありません。
On an unmanaged network, however, there have been a number of problems. In general, solutions aimed at early adopters (such as 6to4) have at times caused IPv6 connectivity to appear to be available on a network when in fact there is no connectivity. In turn, this has lead to the content providers needing to serve IPv6 results for DNS queries only for trusted peers with known high-quality connectivity.
ただし、管理されていないネットワークでは、多くの問題があります。一般に、早期採用者（6to4など）を対象としたソリューションは、実際に接続性がない場合に、IPv6接続がネットワークで利用可能に見えることがあります。次に、これにより、既知の高品質の接続性を持つ信頼できるピアに対してのみDNSクエリのIPv6結果を提供する必要があるコンテンツプロバイダーが必要です。
The IPv6 Rapid Deployment (6RD) [RFC5969] approach is a newer version of the 6to4 tunneling solution without the above drawbacks. It offers systematic IPv6 tunneling over IPv4 across an ISP, correspondence between IPv4 and IPv6 routing, and can be deployed within an ISP without the need to rely on other parties.
IPv6 Rapid Deployment（6RD）[RFC5969]アプローチは、上記の欠点がない6TO4トンネルソリューションの新しいバージョンです。ISP全体でIPv4を介した体系的なIPv6トンネル、IPv4とIPv6ルーティングの間の対応を提供し、他の関係者に頼る必要なくISP内に展開できます。
An emerging deployment model uses IPv6 as the dominant protocol at a service provider network, and tunnels IPv4 through this network in a manner converse to the one described in the previous section. There are several motivations for choosing this deployment model:
新たな展開モデルは、IPv6をサービスプロバイダーネットワークで支配的なプロトコルとして使用し、このネットワークを介してTunnels IPv4を前のセクションで説明したものと通信します。この展開モデルを選択するには、いくつかの動機があります。
o There may not be enough public or private IPv4 addresses to support network management functions in an end-to-end fashion, without segmenting the network into small parts with overlapping address space.
o エンドツーエンドの方法でネットワーク管理機能をサポートするのに十分なパブリックまたはプライベートIPv4アドレスがありません。
o IPv4 address sharing among subscribers may involve new address translation nodes within the service provider's network. IPv6 can be used to reach these nodes. Normal IPv4 routing is insufficient for this purpose, as the same addresses would be used in several parts of the network.
o サブスクライバー間のIPv4アドレス共有には、サービスプロバイダーのネットワーク内の新しいアドレス変換ノードが含まれる場合があります。IPv6を使用してこれらのノードに到達できます。ネットワークのいくつかの部分で同じアドレスが使用されるため、通常のIPv4ルーティングはこの目的では不十分です。
o It may be simpler for the service provider to employ a single-version network.
o サービスプロバイダーが単一バージョンネットワークを使用する方が簡単かもしれません。
The recommended tool for this model is Dual Stack Lite [DS-lite]. Dual Stack Lite both provides relief for IPv4 address shortage and makes forward progress on IPv6 deployment, by moving service provider networks and IPv4 traffic over IPv6. Given the IPv6 connectivity that Dual Stack Lite runs over, it becomes easy to provide IPv6 connectivity all the way to the end users as well.
このモデルに推奨されるツールは、デュアルスタックライト[DS-Lite]です。デュアルスタックライトはどちらも、IPv4アドレスの不足を緩和し、IPv6を介したサービスプロバイダーネットワークとIPv4トラフィックを移動することにより、IPv6の展開で前進します。デュアルスタックライトが実行されるIPv6接続を考えると、IPv6接続をエンドユーザーにも簡単に提供できるようになります。
Our final deployment model breaks the requirement that all parties must upgrade to IPv6 before any end-to-end communications use IPv6. This model makes sense when the following conditions are met: o There is a fact or requirement that there be an IPv4-only domain and an IPv6-only domain.
最終的な展開モデルは、エンドツーエンドの通信がIPv6を使用する前に、すべての関係者がIPv6にアップグレードする必要があるという要件を破ります。このモデルは、次の条件が満たされたときに理にかなっています。oIPv4のみのドメインとIPv6のみのドメインがあるという事実または要件があります。
o There is a requirement that hosts in the IPv4-only domain access servers or peers in the IPv6-only domain and vice versa.
o IPv4のみのドメインアクセスサーバーまたはIPv6のみのドメインのピアにホストが、その逆の要件があります。
This deployment model would fit well, for instance, a corporate or mobile network that offers IPv6-only networking but where users still wish to access content from the IPv4 Internet.
この展開モデルは、たとえば、IPv6のみのネットワーキングを提供するが、ユーザーがIPv4インターネットからコンテンツにアクセスすることを希望する企業またはモバイルネットワークに適しています。
When we say "IPv4-only" or "IPv6-only", we mean that the applications can communicate only using IPv4 or IPv6; this might be due to lack of capabilities in the applications, host stacks, or the network; the effect is the same. The reason to switch to an IPv6-only network may be a desire to test such a configuration or to simplify the network. It is expected that as IPv6 deployment progresses, the second reason will become more prevalent. One particular reason for considering an IPv6-only domain is the effect of overlapping private address space to applications. This is important in networks that have exhausted both public and private IPv4 address space and where arranging an IPv6-only network is easier than dealing with the overlapping address space in applications.
「IPv4のみ」または「IPv6のみ」と言うと、アプリケーションはIPv4またはIPv6のみを使用して通信できることを意味します。これは、アプリケーション、ホストスタック、またはネットワークに機能が不足していることが原因である可能性があります。効果は同じです。IPv6のみのネットワークに切り替える理由は、このような構成をテストしたり、ネットワークを簡素化したい場合もあります。IPv6の展開が進むにつれて、2番目の理由がより一般的になると予想されます。IPv6のみのドメインを考慮する特定の理由の1つは、アプリケーションにプライベートアドレススペースが重複する効果です。これは、パブリックとプライベートの両方のIPv4アドレススペースを使い果たしたネットワークで重要です。また、アプリケーションのオーバーラップアドレススペースを扱うよりもIPv6のみのネットワークを配置する方が簡単です。
Note that the existence of an IPv6-only domain requires that all devices are indeed IPv6 capable. In today's mixed networking environments with legacy devices, this cannot always be guaranteed. But, it can be arranged in networks where all devices are controlled by a central authority. For instance, newly built corporate networks can ensure that the latest device versions are in use. Some networks can also be engineered to support different services over an underlying network and, as such, can support IPv6-only networking more easily. For instance, a cellular network may support IPv4-only connectivity for the installed base of existing devices and IPv6-only connectivity for incremental growth with newer IPv6-capable handsets. Similarly, a broadband ISP may support dual-stack connectivity for customers that require both IPv4 and IPv6, and offer IPv6-only and NAT64 service for others. In the case of 3GPP and DOCSIS 3.0 access networks, the underlying access network architecture allows the flexibility to run different services in parallel to suit the various needs of the customer and the network operator.
IPv6のみのドメインの存在には、すべてのデバイスが実際にIPv6対応であることが必要であることに注意してください。レガシーデバイスを備えた今日の混合ネットワーキング環境では、これを常に保証することはできません。ただし、すべてのデバイスが中央当局によって制御されているネットワークに配置できます。たとえば、新しく構築された企業ネットワークは、最新のデバイスバージョンが使用されていることを確認できます。一部のネットワークは、基礎となるネットワークを介してさまざまなサービスをサポートするように設計することもでき、IPv6のみのネットワークをより簡単にサポートできます。たとえば、セルラーネットワークは、既存のデバイスのインストールされているベースのIPv4のみの接続と、新しいIPv6対応ハンドセットによる増分成長のためのIPv6のみの接続性をサポートする場合があります。同様に、ブロードバンドISPは、IPv4とIPv6の両方を必要とする顧客のデュアルスタック接続をサポートし、他の人にIPv6のみおよびNAT64サービスを提供する場合があります。3GPPおよびDOCSIS 3.0アクセスネットワークの場合、基礎となるアクセスネットワークアーキテクチャにより、顧客とネットワークオペレーターのさまざまなニーズに合わせてさまざまなサービスを並行して実行できます。
It is also necessary for the network operator to have some level of understanding of what applications are used in the network, enabling him to ensure that any communication exchange is in fact predictable, capable of using IPv6, and translatable. In such a case, full interoperability can be expected. This has been demonstrated with some mobile devices, for instance. Note that the requirements on applications are similar to those in networks employing IPv4 NAT technology.
また、ネットワークオペレーターは、ネットワークで使用されているアプリケーションをある程度理解しているため、コミュニケーション交換が実際に予測可能で、IPv6を使用できることを保証できるようにする必要があります。そのような場合、完全な相互運用性が予想されます。これは、たとえばいくつかのモバイルデバイスで実証されています。アプリケーションの要件は、IPv4 NATテクノロジーを採用しているネットワークの要件に似ていることに注意してください。
One obvious IPv6-only deployment approach applies to applications that include proxies or relays. One might position a web proxy, a mail server, or a SIP (Session Initiation Protocol) and media stream back-to-back user agent across the boundary between IPv4 and IPv6 domains, so that the application terminates IPv4 sessions on one side and IPv6 sessions on the other. Doing this preserves the end-to-end nature of communications from the gateway to the communicating peer. For obvious reasons, this solution is preferable to the implementation of Application Layer Gateways in network-layer translators.
1つの明らかなIPv6のみの展開アプローチは、プロキシまたはリレーを含むアプリケーションに適用されます。Webプロキシ、メールサーバー、またはSIP（セッション開始プロトコル）を配置し、IPv4ドメインとIPv6ドメイン間の境界を越えてメディアストリーミングの連続したユーザーエージェントを配置する場合があります。他のセッション。これを行うと、ゲートウェイから通信ピアまでの通信のエンドツーエンドの性質が維持されます。明らかな理由で、このソリューションは、ネットワーク層翻訳者のアプリケーションレイヤーゲートウェイの実装よりも好ましいです。
The other approach is network-layer IPv4/IPv6 translation as described in "IPv4/IPv6 Translation" [RFC6144] [RFC6145] [RFC6146] [RFC6052] [RFC6147] [FTP64]. IPv4/IPv6 translation at the network layer is similar to IPv4/IPv4 translation in its advantages and disadvantages. It allows a network to provide two types of services to IPv6-only hosts:
もう1つのアプローチは、「IPv4/IPv6翻訳」[RFC6144] [RFC6145] [RFC6146] [RFC6052] [RFC6147] [FTP64]で説明されているように、ネットワーク層IPv4/IPv6翻訳です。ネットワークレイヤーでのIPv4/IPv6翻訳は、その利点と短所でIPv4/IPv4の翻訳に似ています。ネットワークは、IPv6のみのホストに2種類のサービスを提供できます。
o a relatively small set of systems may be configured with IPv4- mapped addresses, enabling stateless interoperation between IPv4- only and IPv6-only domains, each of which can use the other as peers or servers, and
o 比較的小さなシステムセットは、IPv4マッピングされたアドレスで構成され、IPv4-のみとIPv6のみのドメインとの間のステートレスの相互操作を可能にします。
o a larger set of systems with global IPv6 addresses, which can access IPv4 servers using stateful translation but which are inaccessible as peers or servers from the IPv4-only domain.
o グローバルIPv6アドレスを備えたシステムセットは、Stateful翻訳を使用してIPv4サーバーにアクセスできますが、IPv4のみのドメインからのピアまたはサーバーとしてアクセスできません。
The former service is used today in some university networks, and the latter in some corporate and mobile networks. The stateless service is naturally better suited for servers, and the stateful service for large numbers of client devices. The latter case occurs typically in a public network access setting. The two services can of course also be used together. In this scenario, network-layer translation provides for straightforward services for most applications crossing the IPv4-only/IPv6-only boundary.
以前のサービスは現在、一部の大学ネットワークで使用されており、後者は一部の企業およびモバイルネットワークで使用されています。ステートレスサービスは、当然サーバーと、多数のクライアントデバイス用のステートフルサービスに適しています。後者の場合は、通常、パブリックネットワークアクセス設定で発生します。もちろん、2つのサービスも一緒に使用できます。このシナリオでは、ネットワーク層翻訳は、IPv4のみ/IPv6のみの境界を通過するほとんどのアプリケーションに簡単なサービスを提供します。
One challenge in this model is that as long as IPv4 addresses are still shared, issues similar to those caused by IPv4 NATs will still appear [shared-addressing-issues]. Another challenge relates to communications involving IPv4 referrals. IPv4-literals within certain protocols and formats, such as HTML, will fail when passed to IPv6-only hosts since the host does not have an IPv4 address to source the IPv4 communications or an IPv4 route. Measurements on the public Internet show that literals appear in a tiny but measurable part of web pages [IPv6-only-experience], though whether this poses a practical problem is debatable. If this poses a particular problem for the types of applications in use, proxy configurations could be modified to use a proxy for the traffic in question, hosts could be modified to understand how they can map IPv4-literals to IPv6 addresses, or native dual stack could be employed instead.
このモデルの課題の1つは、IPv4アドレスがまだ共有されている限り、IPv4 NATによって引き起こされた問題と同様の問題がまだ表示されることです[共有アドレス発行]。別の課題は、IPv4紹介を含む通信に関するものです。HTMLなどの特定のプロトコルおよびフォーマット内のIPv4リテラルは、IPv4通信またはIPv4ルートを調達するIPv4アドレスを持っていないため、IPv6のみのホストに渡されたときに失敗します。パブリックインターネット上の測定は、リテラルがWebページ[IPv6のみの経験]の小さなが測定可能な部分に表示されることを示していますが、これが実際的な問題をもたらすかどうかは議論の余地があります。これが使用中のアプリケーションの種類に特定の問題をもたらす場合、プロキシ構成を変更して問題のトラフィックにプロキシを使用することができます。ホストは、IPv4リテラルをIPv6アドレスにマッピングする方法、またはネイティブデュアルスタックにどのようにマッピングできるかを理解することができます。代わりに採用することができます。
The fundamental recommendation is to turn on IPv6. Section 4 described four deployment models to do that, presented in rough order of occurrence in the world at the time of this writing. The first two models are the most widely deployed today. All four models are recommended by the IETF, though, again, the first two models should take priority where they are applicable.
基本的な推奨事項は、IPv6をオンにすることです。セクション4では、この執筆時点で世界で大まかな発生順に提示された4つの展開モデルについて説明しました。最初の2つのモデルは、今日最も広く展開されています。4つのモデルはすべてIETFによって推奨されていますが、繰り返しますが、最初の2つのモデルが適用可能な場合に優先されるはずです。
As noted in Section 1, variations occur in details, and network managers are ultimately in charge of choosing the best solution for their own case. Benefits and challenges discussed in the previous sections should be considered when weighing deployment alternatives. The transition mechanisms that operators have deployed have been a mixed blessing; native dual-stack deployments are not used to their full extent if peers have not upgraded, tunnel mechanisms that don't follow the routing of the underlying network have been problematic, and translation has its faults as well. Nevertheless, operators have successfully deployed very large networks with these models.
セクション1で述べたように、バリエーションは詳細に発生し、ネットワークマネージャーは最終的に自分のケースに最適なソリューションを選択することを担当します。前のセクションで説明した利点と課題は、展開の代替品を比較検討する際に考慮する必要があります。オペレーターが展開した遷移メカニズムは、祝福されています。ネイティブのデュアルスタックの展開は、ピアがアップグレードされていない場合、完全に使用されません。基礎となるネットワークのルーティングに従わないトンネルメカニズムには問題があり、翻訳にも障害があります。それにもかかわらず、オペレーターはこれらのモデルを使用して非常に大きなネットワークを正常に展開しています。
Some additional considerations are discussed below.
いくつかの追加の考慮事項については、以下で説明します。
o There is a tradeoff between ability to connect as many different types of devices as possible and the ability to move forward with deployment as independently as possible. As an example, native dual stack ensures the best connectivity but requires updates in peer systems before actual traffic flows over IPv6. Conversely, IPv6-only networks are very sensitive to what kind of devices they can support, but can be deployed without any expectation of updates on peer systems.
o できるだけ多くの異なるタイプのデバイスを接続する能力と、できるだけ独立して展開を進める能力との間にはトレードオフがあります。例として、ネイティブのデュアルスタックは最適な接続を保証しますが、IPv6を介して実際のトラフィックが流れる前にピアシステムの更新が必要です。逆に、IPv6のみのネットワークは、サポートできるデバイスの種類に非常に敏感ですが、ピアシステムの更新を期待することなく展開できます。
o "Greenfield" networks and networks with existing IPv4 devices and users need to be treated differently. In the latter case, turning on IPv6 in addition to IPv4 seems the rational choice. In the former case, an IPv6-only model may make sense.
o 既存のIPv4デバイスとユーザーを備えた「Greenfield」ネットワークとネットワークは、異なる方法で扱われる必要があります。後者の場合、IPv4に加えてIPv6をオンにすることは合理的な選択のようです。前者の場合、IPv6のみのモデルが理にかなっているかもしれません。
o The right deployment model choices also vary as time goes by. For instance, a tunneling solution that makes sense today may become a native dual-stack solution as the network and devices in the network evolve. Or, an IPv6-only network becomes feasible when a sufficient fraction of client devices become IPv6-enabled.
o 適切な展開モデルの選択は、時間が経つにつれて異なります。たとえば、今日の意味のあるトンネリングソリューションは、ネットワークのネットワークとデバイスが進化するにつれて、ネイティブのデュアルスタックソリューションになる可能性があります。または、クライアントデバイスの十分な割合がIPv6対応になると、IPv6のみのネットワークが実行可能になります。
No matter which deployment model is chosen, many of the important implications of IPv6 deployment are elsewhere within the network: IPv6 needs to be taken into account in network management systems and operations, address assignments, service agreements, firewalls, intrusion detection systems, and so on.
どの展開モデルが選択されていても、IPv6展開の重要な意味の多くはネットワーク内の他の場所にあります。IPv6は、ネットワーク管理システムと運用、アドレスの割り当て、サービス契約、ファイアウォール、侵入検知システムなどで考慮する必要があります。の上。
Various aspects of IPv6 deployment have been covered in several documents. Of particular interest may be the basic dual-stack definition [RFC4213], application aspects [RFC4038], deployment in Internet service provider networks [RFC4029] [RFC6036], deployment in enterprise networks [RFC4057] [RFC4852], IPv6-only deployment [IPv6-only-experience], and considerations in specific access networks such as cellular networks [RFC3314] [RFC3574] [RFC4215] [v6-in-mobile] or 802.16 networks [RFC5181].
IPv6の展開のさまざまな側面は、いくつかのドキュメントで説明されています。特に興味深いのは、基本的なデュアルスタック定義[RFC4213]、アプリケーションの側面[RFC4038]、インターネットサービスプロバイダーネットワーク[RFC4029] [RFC6036]、エンタープライズネットワークの展開[RFC4057] [RFC4852]、IPV6-only Doiling [RFC4852]である可能性があります。IPv6のみの経験]、およびセルラーネットワーク[RFC3314] [RFC3574] [RFC4215] [V6-in-Mobile]または802.16ネットワーク[RFC5181]などの特定のアクセスネットワークの考慮事項。
This document provides general guidance on IPv6 deployment models that have been found suitable for most organizations. The purpose of this document is not to enumerate all special circumstances that may warrant other types of deployment models or the details of the necessary transition tools. Many of the special cases and details have been discussed in the above documents.
このドキュメントは、ほとんどの組織に適したIPv6展開モデルに関する一般的なガイダンスを提供します。このドキュメントの目的は、他の種類の展開モデルや必要な遷移ツールの詳細を保証する可能性のあるすべての特別な状況を列挙することではありません。特別なケースと詳細の多くは、上記の文書で説明されています。
While there are detailed differences between the security properties and vulnerabilities between IPv4 and IPv6, in general they provide a very similar level of security and are subject to the same threats. With both protocols, specific security issues are more likely to be found at the practical level than in the specifications. The practical issues include, for instance, bugs or available security mechanisms on a given product. When deploying IPv6, it is important to ensure that the necessary security capabilities exist on the network components even when dealing with IPv6 traffic. For instance, firewall capabilities have often been a challenge in IPv6 deployments.
セキュリティプロパティとIPv4とIPv6の脆弱性には詳細な違いがありますが、一般に、非常に類似したレベルのセキュリティを提供し、同じ脅威の対象となります。両方のプロトコルでは、特定のセキュリティの問題が、仕様よりも実際のレベルで見つかる可能性が高くなります。実際の問題には、たとえば、特定の製品のバグや利用可能なセキュリティメカニズムが含まれます。IPv6を展開する場合、IPv6トラフィックを扱う場合でも、ネットワークコンポーネントに必要なセキュリティ機能が存在することを確認することが重要です。たとえば、ファイアウォール機能は、IPv6の展開において課題となっていることがよくあります。
This document has no impact on the security properties of specific IPv6 transition tools. The security considerations relating to the transition tools are described in the relevant documents, for instance, [RFC4213], [RFC6147], [DS-lite], and [RFC6169].
このドキュメントは、特定のIPv6遷移ツールのセキュリティプロパティに影響を与えません。遷移ツールに関連するセキュリティ上の考慮事項は、たとえば[RFC4213]、[RFC6147]、[DS-Lite]、および[RFC6169]など、関連するドキュメントで説明されています。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[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月。
[RFC5454] Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile IPv4", RFC 5454, March 2009.
[RFC5454] Tsirtsis、G.、Park、V。、およびH. Soliman、「デュアルスタックモバイルIPv4」、RFC 5454、2009年3月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555] Soliman、H。、「デュアルスタックホストとルーターのモバイルIPv6サポート」、RFC 5555、2009年6月。
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009.
[RFC5565] Wu、J.、Cui、Y.、Metz、C。、およびE. Rosen、「Softwire Mesh Framework」、RFC 5565、2009年6月。
[Baker.Shanghai] Baker, F., "The view from IPv6 Operations WG (and we'll talk about translation)", Presentation in the China Mobile Workshop on IPv6 Deployment in Cellular Networks, Shanghai, China, November 2009, <http://ipv6ws.arkko.com/ presentations/3GPP-IETF-V6OPS-Discussion.pdf>.
[Baker.Shanghai] Baker、F。、「IPv6 Operations WG（そして翻訳について話します）からの見解」、2009年11月、中国、上海、Cellular NetworksのIPv6展開に関する中国モバイルワークショップでのプレゼンテーション、<http：//ipv6ws.arkko.com/ Presentations/3gpp-itf-v6ops-discussion.pdf>。
[DS-extra-lite] Arkko, J., Eggert, L., and M. Townsley, "Scalable Operation of Address Translators with Per-Interface Bindings", Work in Progress, February 2011.
[DS-Extra-Lite] Arkko、J.、Eggert、L。、およびM. Townsley、「インターフェイスごとのバインディングを備えたアドレス翻訳者のスケーラブルな操作」、2011年2月の作業。
[DS-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", Work in Progress, August 2010.
[DS-Lite] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4 Exhotion後のデュアルスタックLiteブロードバンド展開」、2010年8月の作業。
[FTP64] Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation", Work in Progress, March 2011.
[FTP64] Beijnum、I。、「IPv6-to-IPV4翻訳用のFTPアルグ」、2011年3月の作業。
[IPv6-only-experience] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", Work in Progress, April 2011.
[IPv6のみの経験] Arkko、J。およびA. Keranen、「IPv6のみのネットワークからの経験」、2011年4月、進行中の作業。
[L2-NAT] Miles, D. and M. Townsley, "Layer2-Aware NAT", Work in Progress, March 2009.
[L2-Nat] Miles、D。およびM. Townsley、「layer2-aware nat」、2009年3月、進行中の作業。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[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月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993] Hain、T。、「Natの建築的意味」、RFC 2993、2000年11月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053] Durand、A.、Fasano、P.、Guardini、I。、およびD. Lento、「IPv6 Tunnel Broker」、RFC 3053、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[RFC3314] Wasserman、M。、「第3世代パートナーシッププロジェクト（3GPP）標準におけるIPv6の推奨」、RFC 3314、2002年9月。
[RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC 3574, August 2003.
[RFC3574] Soininen、J。、「3GPPネットワークの遷移シナリオ」、RFC 3574、2003年8月。
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[RFC4029] Lind、M.、Ksinant、V.、Park、S.、Baudot、A。、およびP. Savola、「IPv6をISPネットワークに導入するためのシナリオと分析」、RFC 4029、2005年3月。
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[RFC4038] Shin、M-K。、Hong、Y-G。、Hagino、J.、Savola、P。、およびE. Castro、「IPv6遷移のアプリケーションの側面」、RFC 4038、2005年3月。
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[RFC4057] Bound、J。、「IPv6エンタープライズネットワークシナリオ」、RFC 4057、2005年6月。
[RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005.
[RFC4215] Wiljakka、J。、「第3世代パートナーシッププロジェクト（3GPP）ネットワークにおけるIPv6遷移に関する分析」、RFC 4215、2005年10月。
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
[RFC4798] de Clercq、J.、Ooms、D.、Prevost、S。、およびF. Le Faucheur、「IPv6プロバイダーエッジルーター（6PE）を使用してIPv4 MPLSを介してIPv6島を接続する」、RFC 4798、2007年2月。
[RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. Green, "IPv6 Enterprise Network Analysis - IP Layer 3 Focus", RFC 4852, April 2007.
[RFC4852] Bound、J.、Pouffary、Y.、Klynsma、S.、Chown、T。、およびD. Green、「IPv6エンタープライズネットワーク分析-IPレイヤー3フォーカス」、RFC 4852、2007年4月。
[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月。
[RFC5181] Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, "IPv6 Deployment Scenarios in 802.16 Networks", RFC 5181, May 2008.
[RFC5181] Shin、M-K。、Han、Y-H。、Kim、S-E。、およびD. Premec、「802.16ネットワークのIPv6展開シナリオ」、RFC 5181、2008年5月。
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July 2008.
[RFC5211] Curran、J。、「インターネット移行計画」、RFC 5211、2008年7月。
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful Protocol?", RFC 5218, July 2008.
[RFC5218] Thaler、D。およびB. Aboba、「プロトコルを成功させるものは何ですか？」、RFC 5218、2008年7月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844] Wakikawa、R。およびS. Gundavelli、「Proxy Mobile IPv6のIPv4サポート」、RFC 5844、2010年5月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969] Townsley、W.およびO. Troan、「IPv6インフラストラクチャのIPv6迅速な展開（6rd） - プロトコル仕様」、RFC 5969、2010年8月。
[RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider Scenarios for IPv6 Deployment", RFC 6036, October 2010.
[RFC6036] Carpenter、B。およびS. Jiang、「IPv6展開のための新しいサービスプロバイダーシナリオ」、RFC 6036、2010年10月。
[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月。
[RFC6127] Arkko, J. and M. Townsley, "IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios", RFC 6127, May 2011.
[RFC6127] Arkko、J。およびM. Townsley、「IPv4ランアウトおよびIPv4-IPV6共存在シナリオ」、RFC 6127、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. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. Beijnum、「Stateful Nat64：IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳」、RFC 6146、2011年4月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. 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. Beijnum、 "DNS64：DNS拡張IPv6クライアントからIPv4サーバーへのネットワークアドレス変換の拡張"、RFC 6147、2011年4月。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6169] Krishnan、S.、Thaler、D。、およびJ. Hoagland、「IPトンネリングに関するセキュリティ上の懸念」、RFC 6169、2011年4月。
[networkworld.youtube] Marsan, C., "YouTube support of IPv6 seen in dramatic traffic spike", Network World article, February 2010, <http://www.networkworld.com/news/2010/ 020110-youtube-ipv6.html>.
[NetworkWorld.Youtube] Marsan、C。、「ドラマチックトラフィックスパイクで見られるIPv6のYouTubeサポート」、Network World Article、<http://www.networld.com/news/2010/020110-youtube-ipv6。html>。
[shared-addressing-issues] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", Work in Progress, March 2011.
[Shared-Addressing-Issues] Ford、M.、Boucadair、M.、Durand、A.、Levis、P。、およびP. Roberts、「IPアドレス共有の問題」、2011年3月の進行中。
[v6-in-mobile] Koodli, R., "Mobile Networks Considerations for IPv6 Deployment", Work in Progress, May 2011.
[V6-in-Mobile] Koodli、R。、「IPv6展開のためのモバイルネットワークの考慮事項」、2011年5月の進行中。
The authors would like to thank the many people who have engaged in discussions around this topic over the years. Some of the material in this document comes originally from Fred Baker's presentation in a workshop in Shanghai [Baker.Shanghai]. In addition, the authors would like to thank Mark Townsley with whom Jari Arkko wrote an earlier document [RFC6127]. Brian Carpenter submitted an in-depth review and provided significant new text. Cameron Byrne provided significant feedback on the key recommendations in this memo. The authors would also like thank Dave Thaler, Alain Durand, Randy Bush, and Dan Wing, who have always provided valuable guidance in this field. Finally, the authors would like to thank Suresh Krishnan, Fredrik Garneij, Mohamed Boucadair, Remi Despres, Kurtis Lindqvist, Shawn Emery, Dan Romascanu, Tim Polk, Ralph Droms, Sean Turner, Tina Tsou, Nevil Brownlee, and Joel Jaeggli, who have commented on early versions of this memo.
著者は、長年にわたってこのトピックについて議論してきた多くの人々に感謝したいと思います。この文書の資料のいくつかは、もともと上海[Baker.Shanghai]のワークショップでのフレッド・ベイカーのプレゼンテーションから来ています。さらに、著者は、Jari Arkkoが以前の文書[RFC6127]を書いたMark Townsleyに感謝したいと思います。ブライアンカーペンターは詳細なレビューを提出し、重要な新しいテキストを提供しました。Cameron Byrneは、このメモの主要な推奨事項について重要なフィードバックを提供しました。著者はまた、この分野で常に貴重なガイダンスを提供してきたDave Thaler、Alain Durand、Randy Bush、およびDan Wingに感謝します。最後に、著者は、Suresh Krishnan、Fredrik Garneij、Mohamed Boucadair、Remi Despres、Kurtis Lindqvist、Shawn Emery、Dan Romascanu、Tim Polk、Ralph Droms、Sean Turner、Tina Tsou、Nevil Brownlee、Joel Jaggli、このメモの初期バージョンにコメントしました。
Authors' Addresses
著者のアドレス
Jari Arkko Ericsson Jorvas 02420 Finland
Jari Arkko Ericsson Jorvas 02420フィンランド
EMail: jari.arkko@piuha.net
Fred Baker Cisco Systems Santa Barbara, California 93117 USA
フレッドベイカーシスコシステムサンタバーバラ、カリフォルニア93117 USA
EMail: fred@cisco.com