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の展開にはいくつかの努力、リソース、および専門知識を必要とします。多くの異なった展開モデルの可用性は、専門知識が必要とされる理由の一つです。この文書は、IPv6導入モデルと移行ツールについて説明し、それが発見されているものは、多くの一般的な状況で運用ネットワークでうまく動作するように推奨しています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6180.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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未割り当てのユニキャストのIPv4 / 8プレフィックスが含まれています。過去の行動に基づいた信頼性の推定値は地域インターネットレジストリ（RIRが）が離れてIPv4アドレス空間における市場の発展から、初期の2012年までに彼らの残りのアドレス空間を使い果たすだろうことを示唆しています。アドレス空間の拡張は明らかに必要とされます。利用可能プレフィックスとサブネット内のアドレス、およびアドレス管理の改善の数でその増加に伴い、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]で定義されるように、任意のIPv4のツーのIPv4ネットワークアドレス変換アルゴリズムを指し、両方の「基本的なNAT」と「ネットワークアドレス/ポートトランスレータ（NAPT）」。
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-ライト" と呼ばれるが、IPv6ネットワーク[DS-LITE]上のIPv4接続性を提供するために、トンネリングとIPv4 / IPv4のNATを使用する技術を指します。
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と危険があります。経済学は、有限のリソースは、ストレスを受けたときに、リソースの実際のコストや、それを管理するために必要な技術やプロセスの複雑さのいずれかで、高価になることを私たちに教えています。双方の間、それは危険でもあります
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.
1よりも二つの技術を実行するために、より多くの費用がかかるとして、IPv4とIPv6は、並列に配置されています。このため、IPv4のため、はっきりと2を展開するための要件の最後で、その結果、主要な技術的な目標は、そのサービスインフラストラクチャで、ネットワーク上のIPv6の両方のグローバル展開しており、アプリケーションによって、私たちの飽くなき要求を満たすために拡張しません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の展開のための機会を別のケースとは異なります。 IPv6の展開のための単一の右のモデルは、IPv4ネットワーク設計のための唯一のモデルが存在しないと同じように、ありません。いくつかのガイドラインは、しかし、与えられたことができます。うまく動作するように発見されている一般的な展開モデルは、第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のは最終的にオフにすることができることが期待されます。これは、徐々に起こるはず。例えば、サービスプロバイダのネットワークはまだIPv6の顧客は、オーバーレイ、プロキシ、または翻訳サービスを通じてIPv4インターネットの残りの部分にアクセスすることを可能にしながら、独自のネットワーク内の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インターネット上で、このような接続を配置する方法を見てみましょう。第三のシナリオは、より高度であり、唯一のIPv6の上で動作するサービスプロバイダのネットワークに見えますが、それはまだIPv6とIPv4の両方のサービスを提供することが可能です。第四と最も先進的なシナリオは、アプリケーションやネットワーク層で、翻訳に焦点を当てています。
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]の古いモデルは、例えば、その試みがパス[RFC4966]にDNSクエリをキャプチャするために、起因するいくつかの欠点に苦しんでいます。代わりに、二重翻訳のトンネリングを採用するの好みについてのもう一つの例は、このドキュメントで後述します。
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は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ネットワークでオンになっている状況を作成することができますが、少し実際のトラフィックがあります。このような状況に影響を与える一つの直接的な方法は、トラフィックの主要な目的地は、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.
第二の課題は、必ずしもすべてのアプリケーションが代替の宛先アドレスのいずれかが不確かに働く状況に対応するということです。 IPv6接続の信頼性が低い場合にはいくつかのアプリケーションがIPv4に切り替えるために例えば、それは長い時間がかかることがあります。その結果、多くのコンテンツプロバイダがDNSに離れて広告IPv6アドレスからshyingされています。これは、順番に初挑戦を悪化させます。長期では、近代的なアプリケーションツールキットと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展開の進捗状況の大部分を担当しています。特に、国の研究と教育ネットワーク、インターネットII、RENATER、およびその他 - - 最大のIPv6ネットワークこのアプローチを採用しています。
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アドレス変換は、もはや十分であるような状況があるかもしれません。例えば、典型的な住宅のネットワークでは、各加入者は一つのグローバルIPv4アドレスを付与され、それが扱うことができるよう、加入者のIPv4 / IPv4のNATデバイスは、多くのデバイスでこのアドレスを使用することができます。 IPv4アドレス空間は、より制約およびIPv6へのかなりの移動なしになると、サービスプロバイダーは、複数の加入者に対して単一のグローバルIPv4アドレスを割り当てるために圧力をかけされることが期待されます。確かに、いくつかの展開で、これはすでにケースです。デュアルスタックモデルであっても、これらのネットワークではまだ適用されますが、IPv4の/ IPv4のネットワークアドレス遷移（NAT）機能が移転して強化する必要があるかもしれません。一部のネットワーク上では、重複プライベートアドレス空間[L2-NAT] [DS-余分-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のプロバイダーエッジルータとMPLSの上のIPv6を実行して手動で設定したIPv6オーバーIPv4トンネル[RFC4213]の6to4 [RFC3056]を含むトンネリングメカニズムのいくつかのタイプ、自動ホストベースのトンネル[RFC4380]、トンネルブローカー[RFC3053]は、あります（6PE）[RFC4798]は、仮想プライベートネットワーク（VPN）またはモビリティトンネルの使用は、IPv4と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は、二回プロトコル変換を使用することであろう代替設計をYにIPバージョンYから通信するとき、IPバージョンXのセグメントを横断する必要がある場合、トンネリングを使用することをお勧めします。しかし、この設計は、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の迅速な展開（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:
新興の展開モデルは、支配的なサービス・プロバイダ・ネットワークにおけるプロトコルと、前のセクションで説明したものと逆の方法でこのネットワークを介してトンネルIPv4とIPv6を使用します。この展開モデルを選択するためのいくつかの動機があります。
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の]です。デュアルスタックLiteは、両方のは、IPv4アドレスの不足のために救済を提供し、IPv6の上で、サービスプロバイダーのネットワークとIPv4トラフィックを移動することで、IPv6の展開に前進しています。デュアルスタックLiteは上で動作する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にアップグレードする必要があります要件を破ります。次の条件が満たされたときに、このモデルは、理にかなって：IPv4のみのドメインとIPv6専用ドメインがあるという事実や要件がありますoを。
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 IPv6のみのドメインおよびその逆に、IPv4専用ドメインアクセスサーバーまたはピアのホスト要件があります。
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の導入が進むにつれて、第二の理由は、より普及することが予想されます。 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のみより簡単にネットワークをサポートすることができ、基盤となるネットワーク上のさまざまなサービスをサポートするように設計することが可能。例えば、セルラーネットワークは、既存のデバイスのインストールベースと新しいIPv6対応の携帯電話とのインクリメンタル成長のためのIPv6のみの接続のためのIPv4のみの接続をサポートすることができます。同様に、ブロードバンド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のみの展開アプローチは、プロキシまたはリレーを含むアプリケーションに適用されます。アプリケーションは片側およびIPv6上でIPv4のセッションを終了するように一つは、IPv4とIPv6のドメイン間の境界を越えてWebプロキシ、メールサーバー、またはSIP（セッション開始プロトコル）とメディアストリームバックツーバックユーザエージェントを配置するかもしれません他のセッション。これを行うと、通信ピアへのゲートウェイからの通信のエンドツーエンドの性質を保持します。明白な理由のために、このソリューションは、ネットワーク層トランスレータにおけるアプリケーション層ゲートウェイの実装に好適です。
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:
"はIPv4 / IPv6変換" に記載されているように、他のアプローチは、ネットワーク層のIPv4 / IPv6変換である[RFC6144]、[RFC6145]、[RFC6146]、[RFC6052]、[RFC6147] [FTP64]。ネットワーク層での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
IPv4-ピアまたはサーバのような他を使用することができるそれぞれがIPv4-のみとIPv6専用ドメイン間のステートレスな相互運用を可能にする、アドレスがマッピングされているシステムの比較的小さなセットが構成されていてもよい、O、及び
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.
ステートフル翻訳を使用したIPv4サーバーにアクセスすることができますが、IPv4のみのドメインからのピアまたはサーバアクセス不能であるグローバルIPv6アドレスを持つシステムの大きなセット、O。
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の紹介を含む通信に関する。 IPv6のみのホストに渡されたときに、ホストがIPv4通信またはIPv4ルートを供給するためのIPv4アドレスを持っていないので、HTMLなどの特定のプロトコルやフォーマット内のIPv4-リテラルは、失敗します。これは実用的な問題を提起するかどうかは議論の余地があるもののリテラルは、[IPv6のみの体験] Webページの小さなが測定部分に表示されていることを公共のインターネット番組で測定。これは、使用中のアプリケーションの種類のための特定の問題を提起する場合、プロキシの設定が問題のトラフィックのためにプロキシを使用するように変更することができ、ホストは、IPv6アドレス、またはネイティブデュアルスタックにはIPv4-リテラルをマッピングすることができる方法を理解するように変更することができ代わりに使用することができます。
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.
既存のIPv4デバイスとユーザとO「グリーンフィールド」ネットワークとネットワークが異なる扱いをする必要があります。後者の場合、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のみの展開[かもしれIPv6のみの体験]、及びそのようなセルラネットワーク[RFC3314]、[RFC3574]、[RFC4215] [V6インモバイル]または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.ホールドレッジ、 "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.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmarkと、E.とR.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、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：ネットワークアドレス変換を通じてUDP経由トンネリングのIPv6器（NAT）"、RFC 4380、2006年2月。
[RFC5454] Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile IPv4", RFC 5454, March 2009.
[RFC5454] Tsirtsis、G.、公園、V.、およびH.ソリマン、 "デュアルスタックモバイルIPv4"、RFC 5454、2009年3月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555]ソリマン、H.、RFC 5555 "デュアルスタックホストとルータのためのモバイルIPv6のサポート"、2009年6月。
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009.
[RFC5565]呉、J.、キュイ、Y.、メス、C.、およびE.ローゼン、 "Softwireメッシュフレームワーク"、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]ベイカー、F.、IPv6のセルラーネットワークにおける展開、上海、中国、2009年11月に、中国移動通信ワークショップでのプレゼンテーション「IPv6の運用WG（と私たちは翻訳について話しましょう）からの眺め」、<HTTP ：//ipv6ws.arkko.com/プレゼンテーション/ 3GPP-IETF-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-余分-LITE] Arkko、J.、エッゲルト、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の]デュラン、A.、Droms、R.、Woodyatt、J.、およびY.リー、 "IPv4の枯渇後デュアルスタックLiteのブロードバンドの展開"、進歩、2010年8月での作業。
[FTP64] Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation", Work in Progress, March 2011.
[FTP64] Beijnum、I.、進歩、2011年3月に仕事の "IPv6からIPv4翻訳のためのFTP ALG"。
[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]マイル、D.とM. Townsley、 "レイヤ2-AwareのNAT"、進歩、2009年3月に作業。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981、1996年8月 "IPバージョン6のパスMTUディスカバリー"。
[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]ハイン、T.、 "NATの建築的意味"、RFC 2993、2000年11月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053]デュラン、A.、ファザーノ、P.、Guardini、I.、およびD.レント、 "IPv6のトンネルブローカー"、RFC 3053、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[RFC3314]ワッサーマン、M.、RFC 3314、2002年9月、 "第三世代パートナーシッププロジェクト（3GPP）規格におけるIPv6のための提言"。
[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]リンド、M.、Ksinant、V.、公園、S.、ボドー、A.、およびP. Savola、 "ISPネットワークにIPv6を導入するためのシナリオと分析"、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]シン、M-K。、香港、Y-G。、萩野、J.、Savola、P.、およびE.カストロ、 "IPv6移行のアプリケーション側面"、RFC 4038、2005年3月。
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[RFC4057]バウンド、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.、RFC 4215、2005年10月、 "第三世代パートナーシッププロジェクト（3GPP）ネットワークにおけるIPv6移行に関する分析"。
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
[RFC4798]デClercq、J.、Ooms、D.、プレボ、S.、およびF.ルFaucheur、 "IPv6のプロバイダエッジルータを使用したIPv4 MPLS上のIPv6諸島接続（6PE）"、RFC 4798、2007年2月。
[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]バウンド、J.、Pouffary、Y.、Klynsma、S.、chownコマンド、T.、およびD.グリーン、 "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]アウン、C.およびE.デイヴィス、 "ネットワークアドレス変換に移動する理由 - 歴史的な状態にプロトコル変換（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]新、M-K。、ハン、Y-H。、キム、S-E。、およびD. Premec、 "802.16ネットワークにおけるIPv6の展開シナリオ"、RFC 5181、2008年5月。
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July 2008.
[RFC5211]カラン、J.、 "アンインターネット移行計画"、RFC 5211、2008年7月。
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful Protocol?", RFC 5218, July 2008.
[RFC5218]ターラー、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、 "プロキシモバイル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、 "IPv4の基盤のIPv6のRapid Deployment（6rd） - プロトコル仕様"、RFC 5969、2010年8月。
[RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider Scenarios for IPv6 Deployment", RFC 6036, October 2010.
[RFC6036]大工、B.とS.江、 "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]バオ、C.、のHuitema、C.、Bagnulo、M.、Boucadair、M.、およびX.李、RFC 6052、2010年10月の "IPv6は、IPv4 / IPv6の翻訳者のアドレス指定"。
[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]ベーカー、F.はLi、X.、バオ、C.、およびK.陰陽 "のIPv4 / IPv6変換のためのフレームワーク"、RFC 6144、2011年4月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]のLi、X.、バオ、C.、およびF.ベイカー、 "IP / ICMP翻訳アルゴリズム"、RFC 6145、2011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、マシューズ、P.、およびI. Beijnum、 "ステートフルNAT64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレスとプロトコル変換"、RFC 6146、2011年4月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147] Bagnulo、M.、サリバン、A.、マシューズ、P.、およびI. Beijnum、 "DNS64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレス変換のためのDNSの拡張"、RFC 6147、2011年4月。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6169]クリシュナン、S.、ターラー、D.、およびJ.ホーグランド、 "IPトンネリングとセキュリティの懸念"、RFC 6169、2011年4月。
[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]マルサン、C.、 "劇的なトラフィックスパイクで見られたIPv6のYouTubeのサポート"、ネットワークの世界の記事、2010年2月、<http://www.networkworld.com/news/2010/ 020110-動画 - 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.
[共有アドレッシングの問題]、進歩、2011年3月に仕事フォード、M.、Boucadair、M.、デュラン、A.、リーバイス、P.、およびP.ロバーツ、 "IPアドレスの共有に関する問題が"。
[v6-in-mobile] Koodli, R., "Mobile Networks Considerations for IPv6 Deployment", Work in Progress, May 2011.
[V6・イン・モバイル] Koodli、R.、「IPv6の展開のためのモバイルネットワークの考慮事項」、進歩、2011年5月での作業。
Appendix A. Acknowledgments
付録A.謝辞
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]上海でのワークショップでフレッド・ベイカーのプレゼンテーションから元々来ています。また、著者はヤリArkko、以前の文書[RFC6127]を書いた人とマークTownsleyに感謝したいと思います。ブライアン・カーペンターは、詳細なレビューを提出し、重要な新しいテキストを提供します。キャメロン・バーンは、このメモの重要勧告に重要なフィードバックを提供します。著者らはまた、常にこの分野での貴重なガイダンスを提供してきたデーブターラー、アラン・デュラン、ランディブッシュ、そしてダンウィングを、感謝したいと思います。最後に、著者は持っているのSureshクリシュナン、フレドリックGarneij、モハメドBoucadair、レミ・デプレ、カーティスLindqvist、ショーン・エメリー、ダンRomascanu、ティムポーク、ラルフDroms、ショーン・ターナー、ティナツオウ、Nevilブラウンリー、とジョエルJaeggliを、感謝したいと思いますこのメモの初期のバージョンでコメントしました。
Authors' Addresses
著者のアドレス
Jari Arkko Ericsson Jorvas 02420 Finland
ヤリArkkoエリクソン02420 Jorvasフィンランド
EMail: jari.arkko@piuha.net
メールアドレス：jari.arkko@piuha.net
Fred Baker Cisco Systems Santa Barbara, California 93117 USA
フレッドベイカーシスコシステムズサンタバーバラ、カリフォルニア93117 USA
EMail: fred@cisco.com
メールアドレス：fred@cisco.com