Network Working Group J. Bound
Request for Comments: 4852 Y. Pouffary
Category: Informational Hewlett-Packard
S. Klynsma
MITRE
T. Chown
University of Southampton
D. Green
Command Information
April 2007
IPv6 Enterprise Network Analysis - IP Layer 3 Focus
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3. These networks are characterized as having multiple internal links and one or more router connections to one or more Providers, and as being managed by a network operations entity. The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise. Then, a set of transition mechanisms are recommended for each notational network.
この文書では、IP層3上に焦点企業ネットワークにおけるIPv6への移行を解析し、複数の内部リンクと、1つまたは2つ以上のプロバイダへ、及びネットワーク運用エンティティによって管理されているような複数のルータの接続を有することを特徴とするこれらのネットワーク。分析は、遷移表記ネットワーク及びエンタープライズ・シナリオの以前の文書から展開要件の基本セットに焦点を当てます。議論は、企業内のデュアルIPレイヤ（IPv4およびIPv6）ネットワークとノード環境を想定し、IPv6への移行する企業のために必要な遷移解析の集束セット上に設けられています。次に、移行メカニズムのセットがそれぞれ表記ネットワークに推奨されています。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Enterprise Matrix Analysis for Transition .......................5
4. Wide-Scale Dual-Stack Deployment Analysis ......................10
4.1. Staged Dual-Stack Deployment ..............................10
4.2. Routing Capability Analysis for Dual-IP Deployment ........11
4.2.1. IPv6 Routing Capability ............................11
4.2.2. IPv6 Routing Non-Capability ........................11
4.2.2.1. Tunnel IPv6 over the IPv4 infrastructure ..12
4.2.2.2. Deploy a Parallel IPv6 Infrastructure .....12
4.3. Remote IPv6 Access to the Enterprise ......................12
4.4. Other Considerations ......................................13
5. Sparse Dual-Stack Deployment Analysis ..........................13
5.1. Internal versus External Tunnel Endpoint ..................13
5.2. Manual versus Autoconfigured ..............................14
6. IPv6-Dominant Network Deployment Analysis ......................14
7. General Issues from Analysis ...................................15
7.1. Staged Plan for IPv6 Deployment ...........................15
7.2. Network Infrastructure Requirements .......................15
7.3. Stage 1: Initial Connectivity Steps .......................15
7.3.1. Obtaining External Connectivity ....................16
7.3.2. Obtaining Global IPv6 Address Space ................16
7.4. Stage 2: Deploying Generic Basic Service Components .......16
7.4.1. Developing an IPv6 Addressing Plan .................16
7.4.2. IPv6 DNS ...........................................17
7.4.3. IPv6 Routing .......................................17
7.4.4. Configuration of Hosts .............................18
7.4.5. Security ...........................................18
7.5. Stage 3: Widespread Dual-Stack Deployment On-Site .........19
8. Applicable Transition Mechanisms ...............................20
8.1. Recognizing Incompatible Network Touchpoints ..............20
8.2. Recognizing Application Incompatibilities .................21
8.3. Using Multiple Mechanisms to Support IPv6 Transition ......22
9. Security Considerations ........................................22
10. References ....................................................22
10.1. Normative References .....................................22
10.2. Informative References ...................................24
11. Acknowledgments ...............................................25
Appendix A. Crisis Management Network Scenarios ...................26
A.1. Introduction ..............................................26
A.2. Scenarios for IPv6 Deployment in Crisis Management
Networks ..................................................26
A.3. Description of a Generic Crisis Management Network ........28
A.4. Stages of IPv6 Deployment .................................29
This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3. These networks are characterized as having multiple internal links, and one or more router connections to one or more Providers, and as being managed by a network operations entity. The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise. Then, a set of transition mechanisms are recommended for each notational network.
この文書は、複数の内部リンクを有し、および1つまたは複数のプロバイダへの1つ以上のルーター接続、およびネットワーク運用エンティティによって管理されているとしてとして特徴付けられるIP層3これらのネットワークに焦点を当てた企業ネットワークにおけるIPv6への移行を分析します。分析は、遷移表記ネットワーク及びエンタープライズ・シナリオの以前の文書から展開要件の基本セットに焦点を当てます。議論は、企業内のデュアルIPレイヤ（IPv4およびIPv6）ネットワークとノード環境を想定し、IPv6への移行する企業のために必要な遷移解析の集束セット上に設けられています。次に、移行メカニズムのセットがそれぞれ表記ネットワークに推奨されています。
The audience for this document is the enterprise network team considering deployment of IPv6. The document will be useful for enterprise teams that have to determine the IPv6 transition strategy for their enterprise. It is expected that those teams include members from management, network operations, and engineering. The analysis and notational networks presented provide an example set of cases the enterprise can use to build an IPv6 transition strategy.
このドキュメントの対象読者は、IPv6の展開を考えると、企業のネットワークチームです。文書は、企業のためのIPv6移行戦略を決定する必要があり、企業チームのために有用であろう。これらのチームは、経営陣からのメンバー、ネットワークオペレーション、エンジニアリングを含むことが予想されます。提示分析と表記ネットワークは、企業がIPv6移行戦略を構築するために使用することができる場合の設定例を提供します。
The enterprise analysis begins by describing a matrix as a tool to be used to portray the different IPv4 and IPv6 possibilities for deployment. The document will then provide analysis to support enterprise-wide Dual-IP layer deployment strategy, to provide the reader with a view of how that can be planned and what options are available. The document then discusses the deployment of sparse IPv6 nodes within the enterprise and the requirements that need to be considered and implemented when the enterprise remains with an IPv4- only routing infrastructure for some time. The next discussion focuses on the use of IPv6 when it is determined to be dominant across or within parts of the enterprise network.
企業分析は、展開のために異なるIPv4とIPv6の可能性を表現するために使用されるツールとして行列を記述することによって開始します。文書は、その計画は、どのようなオプションが用意されてできるかのビューを読者に提供するために、企業全体のデュアルIPレイヤの展開戦略をサポートするための分析を提供します。文書は、その後、疎のIPv6企業内のノードと企業がしばらくIPv4-のみルーティングインフラストラクチャに残っている場合と考えられ、実施される必要がある要件の展開を論じています。次の議論は、全体または企業ネットワークの一部内で支配的であると判断されたIPv6の使用に焦点を当てています。
The document then discusses the general issues and applicability from the previous analysis. The document concludes by providing a set of current transition mechanism recommendations for the notational network scenarios to support an enterprise that is planning to deploy IPv6.
文書は、以前の分析から、一般的な問題と適用性を説明します。文書は、IPv6を展開することを計画している企業をサポートするために、表記のネットワークシナリオの現在の遷移機構の推奨のセットを提供することによって終了します。
As stated, this document focuses only on the deployment cases where a Dual-IP Layer 3 is supported across the network and on the nodes in the enterprise. Additional deployment transition analysis will be required from the effects of an IPv6-only node or Provider deployments, and is beyond the scope of this document. In addition, this document does not attempt to define or discuss any use with network address translation [NATPT] or Provider Independent address space.
述べたように、このドキュメントでは、デュアルIPレイヤ3は、ネットワークを介して、エンタープライズ内のノード上でサポートされての展開例に焦点を当てています。追加の展開遷移解析は、IPv6のみのノードまたはプロバイダの展開の影響から要求され、このドキュメントの範囲を超えてされます。また、この文書は、ネットワークアドレス変換[NATPT]またはプロバイダ独立したアドレス空間を持つ任意の使用を定義するかについて議論しようとしません。
The following specific topics are currently out of scope for this document:
次の特定のトピックは、このドキュメントの範囲外現在、次のとおりです。
- Multihoming - Application transition/porting (see [APPS]). - IPv6 VPN, firewall, or intrusion detection deployment. - IPv6 network management and QoS deployment. - Detailed IT Department requirements. - Deployment of novel IPv6 services, e.g., Mobile IPv6. - Requirements or Transition at the Providers' network. - Transport protocol selection for applications with IPv6. - Application layer and configuration issues. - IPv6 only future deployment scenarios.
- マルチホーミング - アプリケーション移行/移植（参照[APPS]）。 - IPv6のVPN、ファイアウォール、侵入検知の展開。 - IPv6ネットワーク管理およびQoSの展開。 - 詳細なIT部門の要件。 - 新規のIPv6サービスの展開、例えば、モバイルIPv6。 - プロバイダのネットワークでの要件やトランジション。 - IPv6でのアプリケーションのためのトランスポートプロトコルの選択。 - アプリケーション層と構成の問題。 - IPv6の唯一の将来の展開シナリオ。
This document focuses on IP Layer 3 deployment in the same way as the other IPv6 deployment analysis works have done [UMAN] [ISPA] [3GPA]. This document covers deployment of IPv6 "on the wire", including address management and DNS services.
他のIPv6展開分析作品は[UMAN] [ISPA] [3GPA]行ったように、この文書では、同じようにIPレイヤ3の展開に焦点を当てています。この文書では、アドレス管理およびDNSサービスなど、「ワイヤ上の」IPv6の展開をカバーしています。
We are also assuming that the enterprise deployment is being undertaken by the network administration team, i.e., this document does not discuss the case of an individual user gaining IPv6 connectivity (to some external IPv6 provider) from within an enterprise network. Much of the analysis is applicable to wireless networks, but there are additional considerations for wireless networks not contained within this document.
また、この文書は、企業ネットワーク内から（一部の外部のIPv6プロバイダーに）IPv6接続を獲得し、個々のユーザーの場合を議論していない、つまり、エンタープライズ展開は、ネットワーク管理チームによって行われていると仮定されています。分析の多くは、ワイヤレスネットワークに適用されますが、この文書内に含まれていないワイヤレスネットワークのための追加の考慮事項があります。
In Section 2, we introduce the terminology used in this document. In Section 3, we introduce and define a tools matrix and define the IP Layer 3 connectivity requirements. In Section 4, we discuss wide scale Dual-IP layer use within an enterprise. In Section 5, we discuss sparse Dual-IP layer deployment within an enterprise. In Section 6, we discuss IPv6-dominant network deployment within the enterprise. In Section 7, we discuss general issues and applicability. In Section 8, a set of transition mechanisms that can support the deployment of IPv6 with an enterprise are recommended.
第2節では、このドキュメントで使用される用語を紹介します。第3節では、紹介やツールの行列を定義し、IPレイヤ3接続の要件を定義します。第4節では、企業内の広いスケールのデュアルIPレイヤの使用を議論します。第5節では、企業内のまばらなデュアルIPレイヤの展開を議論します。第6節では、企業内のIPv6-支配的なネットワーク展開を議論します。 7章では、我々は一般的な問題と適用性を議論します。セクション8において、企業とIPv6の導入をサポートすることができる遷移メカニズムのセットが推奨されます。
This document then provides Appendix A for readers depicting a Crisis Management enterprise network to demonstrate an enterprise network example that requires all the properties as analyzed in Sections 3, 4, 5, 6, and 7. In addition, we recommend that readers of this document also read another use-case document to support an IPv6 Transition for a Campus Network [CAMP].
この文書は、その後、セクション3、4、5、6で分析し、7さらにとしてすべてのプロパティを必要とする企業ネットワークの一例を示すために、危機管理、エンタープライズネットワークを描いた読者のために、付録Aを提供し、ことをお勧めし、この文書の読者また、キャンパスネットワーク[CAMP]のIPv6移行をサポートするために、別のユースケース文書を読み取ります。
Readers should also be aware that a parallel effort for an enterprise to transition to IPv6 is training, but out of scope for this document.
読者はまた、IPv6へ移行する企業のための並列努力がなく、この文書の範囲の外に、訓練であることを認識する必要があります。
Enterprise Network - A network that has multiple internal links, and one or more router connections to one or more Providers, and is actively managed by a network operations entity.
エンタープライズネットワーク - 複数の内部リンク、および1つまたは複数のプロバイダへの一の以上のルータの接続があり、積極的にネットワーク運用エンティティによって管理されたネットワーク。
Provider - An entity that provides services and connectivity to the Internet or other private external networks for the enterprise network.
プロバイダ - エンタープライズネットワークのためのインターネットや他のプライベート外部ネットワークへのサービスとの接続性を提供するエンティティ。
IPv6-capable - A node or network capable of supporting both IPv6 and IPv4.
IPv6対応 - IPv6とIPv4の両方をサポートすることができるノードまたはネットワーク。
IPv4-only - A node or network capable of supporting only IPv4.
IPv4のみ - IPv4のみをサポートすることができるノードまたはネットワーク。
IPv6-only - A node or network capable of supporting only IPv6. This does not imply an IPv6 only stack in this document.
IPv6のみ - IPv6のみをサポートすることができるノードまたはネットワーク。これは、このドキュメントでのIPv6スタックのみを意味するものではありません。
Dual-IP - A network or node that supports both IPv4 and IPv6.
デュアルIP - IPv4とIPv6の両方をサポートするネットワークまたはノード。
IP-capability - The ability to support IPv6 only, IPv4 only, or Dual-IP Layer
IP-機能 - IPv6のみをサポートする機能、IPv4のみ、またはデュアルIPレイヤ
IPv6-dominant - A network running IPv6 routing and control plane services that provides transport for both IPv4 and IPv6 protocol services
IPv6のドミナント - IPv4とIPv6の両方のプロトコル・サービスのための輸送を提供するIPv6ルーティングおよび制御プレーンサービスを実行しているネットワーク
Transition - The network strategy the enterprise uses to Implementation transition to IPv6.
遷移 - IPv6への実装への移行企業が使用するネットワーク戦略。
In order to identify the best-suited transition mechanisms for an enterprise, it is recommended that the enterprise have an in-depth up-to-date understanding of its current IT environment. This understanding will help choose the best-suited transition mechanisms. It is important to note that one size does not fit all. Selection of mechanisms that reduce the impact on the existing environment is suggested. When selecting a transition mechanism, one must consider the functionality required, its scalability characteristic, and the security implications of each mechanism.
企業のための最も適し移行メカニズムを識別するためには、企業が現在のIT環境の詳細な最新の理解を持っていることをお勧めします。この理解は最も適し移行メカニズムを選択するのに役立ちます。 1つのサイズはすべてに適合しないことに注意することが重要です。既存の環境への影響を減らすメカニズムの選択が示唆されました。移行メカニズムを選択するとき、人は必要な機能、スケーラビリティの特性、および各機構のセキュリティへの影響を考慮する必要があります。
To provide context for an analysis of the transitioning enterprise at Layer 3, we have provided a matrix that describes various scenarios which might be encountered during an IPv6 transition. The notional enterprise network is comprised of hosts attached to an enterprise-owned intranet(s) at two different global locations separated by the Internet. The enterprise owns, operates, and maintains its own intranetworks, but relies on an external provider organization that offers Internet Service. Both local and destination intranetworks are operated by different organizations within the same enterprise and consequently could have different IP-capability than other intranetworks at certain times in the transition period.
レイヤ3での移行の企業を分析するためのコンテキストを提供するために、我々は、IPv6への移行の際に遭遇する様々なシナリオを記述する行列を提供してきました。概念的な企業ネットワークは、インターネットによって分離された2つの異なるグローバル位置における企業所有のイントラネット（複数可）に接続されたホストから構成されています。企業は、所有して動作し、独自のintranetworksを維持するが、インターネットサービスを提供しています外部プロバイダ組織に依存しています。ローカルおよび宛先intranetworksは、同一企業内の異なる組織によって運営され、その結果、移行期間中の特定の時間に他のintranetworks異なるIP-能力を有することができます。
Addressing every possible combination of network IP-capability in this notional enterprise network is impractical; therefore, trivial notional networks (i.e., pure IPv4, pure IPv6, and ubiquitous Dual-IP) are not considered. In addition, the authors could not conceive of any scenarios involving IPv6-only ISPs or IPv6-only nodes in the near term and consequently have not addressed scenarios with IPv6- only ISPs or IPv6-only nodes. We assume all nodes that host IPv6 applications are Dual-IP. The matrix does not assume or suggest that network address translation is used. The authors recommend that network address translation not be used in these notional cases.
この名目企業ネットワーク内のネットワークIP-機能のすべての組み合わせに対処することは非現実的です。したがって、些細な概念上のネットワーク（すなわち、純粋のIPv4、IPv6の純粋な、及びユビキタスデュアルIP）が考慮されません。また、著者は、短期的にIPv6のみのISPまたはIPv6専用ノードを含むいずれかのシナリオを考えることができませんでしたし、その結果IPv6-のみのISPまたはIPv6専用ノードとのシナリオに対処していません。私たちは、ホストのIPv6アプリケーションは、デュアルIPであるすべてのノードを想定しています。マトリックスは、仮定やネットワークアドレス変換が使用されていることを示唆していません。著者は、ネットワークアドレス変換は、これらの想定元本の場合に使用されていないことをお勧めします。
Future enterprise transitions that support IPv6-only nodes and IPv6- only ISPs will require separate analysis, which is beyond the scope of this document.
IPv6専用ノードとIPv6-のみのISPをサポートし、将来の企業の遷移は、このドキュメントの範囲を超えて別の分析を、必要になります。
Table 1 below is a matrix of ten possible Transition Implementations that, being encountered in an enterprise, may require analysis and the selection of an IPv6 transition mechanism for that notional network. Each possible implementation is represented by the rows of the matrix. The matrix describes a set of notional networks as follows:
1以下の表は、企業内で遭遇され、10個の可能な遷移の実装の行列で分析し、その概念上のネットワークのIPv6移行メカニズムの選択を必要とし得ます。各可能な実装は、行列の行で表されます。次のように行列は、概念的ネットワークのセットを記述する。
- The first column represents the protocol used by the application and, below, the IP-capability of the node originating the IP packets. (Application/Host 1 OS)
- 最初の列は、以下、IPパケットを発信するノードのIP-能力をアプリケーションによって使用されるプロトコルを表し、。 （アプリケーション/ホスト1つのOS）
- The second column represents the IP-capability of the host network wherein the node originated the packet. (Host 1 Network)
- 第2列は、ノードがパケットを発信し、前記ホストネットワークのIP-能力を表します。 （ホスト1ネットワーク）
- The third column represents the IP-capability of the service provider network. (Service Provider)
- 第3の列は、サービス・プロバイダ・ネットワークのIP-能力を表します。 （サービスプロバイダ）
- The fourth column represents the IP-capability of the destination network wherein the originating IP packets are received. (Host 2 Network)
- 第4列は、発信IPパケットが受信される宛先ネットワークのIP-能力を表します。 （ホスト2ネットワーク）
- The fifth column represents the protocol used by the application and, below, the IP-capability of the destination node receiving the originating IP packets. (Application/Host 2 OS)
- 第5列は、アプリケーションと、以下、発信IPパケットを受信した宛先ノードのIP-機能によって使用されるプロトコルを表します。 （アプリケーション/ホスト2 OS）
As an example, notional network 1 is an IPv6 application residing on a Dual-IP layer host trying to establish a communications exchange with a destination IPv6 application. To complete the information exchange, the packets must first traverse the host's originating IPv4 network (intranet), then the service provider's and destination host's Dual-IP network.
一例として、概念的ネットワーク1は、宛先のIPv6アプリケーションとの通信交換を確立しようとデュアルIPレイヤのホスト上に存在するIPv6のアプリケーションです。情報交換を完了するために、パケットは、最初にホストの発信元IPv4ネットワーク（イントラネット）、サービスプロバイダのと宛先ホストのデュアルIPネットワークを横断しなければなりません。
Obviously, Table 1 does not describe every possible scenario. Trivial notional networks (such as pure IPv4, pure IPv6, and ubiquitous Dual-IP) are not addressed. However, the authors feel these ten scenarios represent the vast majority of transitional situations likely to be encountered in today's enterprise. Therefore, we will use these ten to address the analysis for enterprise deployment.
明らかに、表1は、すべての可能なシナリオを説明していません。 （そのような純粋のIPv4、IPv6の純粋な、及びユビキタスデュアルIPなど）些細な概念的なネットワークが対処されていません。しかし、著者らは、これら10本のシナリオは、今日の企業で遭遇する可能性が高い過渡的な状況の大半を表している感じ。したがって、我々は、エンタープライズ展開のための分析に対処するためにこれらの10を使用します。
Table 1 - Enterprise Scenario Deployment Matrix
表1 - エンタープライズシナリオの展開マトリックス
======================================================
|Application |Host 1 |Service |Host 2 |Application |
|----------- |Network|Provider|Network|---------- |
| Host 1 OS | | | | Host 2 OS |
=====================================+================
| IPv6 | |Dual IP | | IPv6 |
A | ---- | IPv4 | or |Dual IP| ---- |
| Dual IP | | IPv4 | | Dual IP |
======================================================
| IPv6 | | | | IPv6 |
B | ---- | IPv6 | IPv4 | IPv4 | ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv4 | | | | IPv4 |
C | ---- | IPv4 |Dual IP | IPv6 | ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv4 |Dual IP| | | IPv4 |
D | ---- | or | IPv4 | IPv6 | ---- |
| Dual IP | IPv6 | | | Dual IP |
======================================================
| IPv6 |Dual IP| |Dual IP| IPv4 |
E | ---- | or |Dual IP | or | ---- |
| Dual IP | IPv6 | | IPv6 | Dual IP |
======================================================
| IPv6 | | | | IPv4 |
F | ---- | IPv6 | IPv4 | IPv4 | ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv4 | | | | IPv6 |
G | ---- | IPv6 | Dual IP| IPv6 | ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv4 | | | | IPv6 |
H | ---- | IPv6 |Dual IP | IPv4 | ---- |
| IPv4 | | | | Dual IP |
======================================================
| IPv4 | | | | IPv6 |
I | ---- | IPv6 | IPv4 | IPv6 | ---- |
| IPv4 | | | | Dual IP |
======================================================
| IPv6 | | | | IPv4 |
J | ---- | IPv4 | IPv4 | IPv6 | ---- |
| Dual IP | | | | Dual IP |
======================================================
The reader should note that Scenarios A-C in Table 1 are variations of compatible hosts communicating across largely (but not entirely) homogenous networks. In each of the first three scenarios, the packet must traverse at least one incompatible network component. For example, Scenario B represents an enterprise that wishes to use IPv6 applications, but has yet to transition its internal networks; its Service Provider also lags, offering only a v4 IP-service. Conversely, Scenario C represents an enterprise that has completed transition to IPv6 in its core networks (as has its Service Provider), but continues to require a legacy IPv4-based application.
読者は、表1のシナリオA-Cは、主に（しかし完全に）均一なネットワークを介して通信互換性のあるホストのバリエーションがあることに注意すべきです。最初の3つのシナリオのそれぞれにおいて、パケットは、少なくとも一つの互換性のないネットワークコンポーネントを横断しなければなりません。例えば、シナリオBは、IPv6アプリケーションを使用したいが、その内部ネットワークを移行するためにまだ持っている企業を表します。そのサービスプロバイダはまた、唯一のV4 IPサービスを提供し、遅れています。逆に、シナリオCは、そのコアネットワークにおけるIPv6への移行を完了した企業を表す（そのサービスプロバイダを有するもの）が、レガシーIPv4ベースのアプリケーションを必要とし続けます。
Scenario D represents the unusual situation where the enterprise has transitioned its core intranetworks to IPv6, but (like Scenario B) it's ISP provider has yet to transition. In addition, this enterprise continues to retain critical legacy IPv4-based applications that must communicate over this heterogeneous network environment.
シナリオDは、企業がIPv6に中核intranetworksに遷移した異常事態を表すが、（シナリオBのような）はISPプロバイダが移行するまだです。また、この企業は、この異種ネットワーク環境を介して通信しなければならない重要なレガシーIPv4ベースのアプリケーションを保持し続けます。
Scenarios E-J represent transitional situations wherein the enterprise has both IPv4 and IPv6 based instantiations of the same application that must continue to interoperate. In addition, these scenarios show that the enterprise has not completed transition to IPv6 in all its organic and/or Service Provider networks. Instead, it maintains a variety of heterogeneous network segments between the communicating applications. Scenarios E and J represent distinctly different extremes on either end of the spectrum. In Scenario E, the enterprise has largely transitioned to IPv6 in both its applications and networks. However, Scenario E shows that a few legacy IPv4-based applications may still be found in the enterprise. On the other hand, Scenario J shows an enterprise that has begun its transition in a very disjointed manner and, in which IPv6-based applications and network segments are relatively rare.
企業が相互運用し続ける必要があり、同じアプリケーションのIPv4とIPv6の両方ベースのインスタンスを有するシナリオE-Jは、過渡的な状況を表しています。また、これらのシナリオは、企業がそのすべての有機および/またはサービスプロバイダーのネットワークでIPv6への移行を完了していないことを示しています。代わりに、通信アプリケーション間の異種ネットワークセグメントの多様を維持します。シナリオE及びJは、スペクトルの両端に明確に異なる極値を表します。シナリオEにおいて、企業は、主にそのアプリケーションとネットワークの両方にIPv6へ移行しました。しかし、シナリオEは、いくつかの従来のIPv4ベースのアプリケーションは、まだ企業に見出すことができることを示しています。一方、シナリオJは、IPv6ベースのアプリケーションとネットワークセグメントは比較的まれである、その非常にバラバラな方法で遷移とを、開始した企業を示します。
In this section, we address Scenario 1 as described in Section 3.1 of [BSCN]. The scenario, assumptions, and requirements are driven from the [BSCN] text. This analysis further corresponds to Scenario A in Section 3 above (although Scenario A shows a transitional situation wherein the enterprise has one network segment still lagging on transition to Dual-IP).
【BSCN]のセクション3.1に記載したように、このセクションでは、シナリオ1に対処します。シナリオ、仮定、および要件は、[BSCN]テキストから駆動されます。 （シナリオAは、企業がまだデュアルIPへの移行に遅れつのネットワークセグメントを有する過渡的な状況を示しているが）この分析は、さらに、上記のセクション3にシナリオAに相当します。
Within these IPv6 deployment scenarios the enterprise network administrator would introduce IPv6 by enabling IPv6 on the wire (i.e., within the network infrastructure) in a structured fashion with the existing IPv4 infrastructure. In such scenarios, a number of the existing IPv4 routers (and thus subnets) will be made Dual-IP, such that communications can run over either protocol.
これらのIPv6展開シナリオ内の企業ネットワーク管理者は、既存のIPv4インフラストラクチャと構造化様式で（すなわち、ネットワークインフラストラクチャ内の）ワイヤーでIPv6を有効にすることにより、IPv6を導入します。そのようなシナリオでは、既存のIPv4ルータ（したがってサブネット）の数は、通信プロトコルのいずれかの上で実行することができるようにデュアルIP、説明します。
Nodes on the Dual-IP links may themselves be IPv4-only or IPv6- capable. The driver for deploying IPv6 on the wire may not be for immediate wide-scale usage of IPv6, but rather to prepare an existing IPv4 infrastructure to support IPv6-capable nodes. Thus, while IPv6 is not used, Dual-IP nodes exist, and the enterprise can be transitioned to IPv6 on demand.
デュアルIPリンク上のノード自体はIPv4のみまたはIPv6-ことが可能であってもよいです。ワイヤ上でIPv6を展開するためのドライバは、IPv6の即時の大規模な使用のためではないかもしれない、むしろIPv6対応のノードをサポートするために既存のIPv4インフラストラクチャを準備します。 IPv6が使用されていないつつ、デュアルIPノードが存在し、企業は、オンデマンドでのIPv6に移行させることができます。
Analyzing this scenario against existing transition mechanisms for their applicability suggests a staged approach for IPv6 deployment in the enterprise.
その適用のための既存の移行メカニズムに対して、このシナリオを分析して、企業内のIPv6展開のための段階的アプローチを示唆しています。
Under these scenarios (as well as most others), the site administrator should formulate a staged plan for the introduction of a Dual-IP IPv6 network. We suggest that Section 7 of this document provides a good basis for such a plan.
これらのシナリオ（だけでなく、他のほとんど）の下では、サイト管理者は、デュアルIP IPv6ネットワークの導入のための段階的な計画を策定すべきです。私たちは、このドキュメントのセクション7は、そのような計画のための良好な基礎を提供することを示唆しています。
In an enterprise network, the administrator will generally seek to deploy IPv6 in a structured, controlled manner, such that IPv6 can be enabled on specific links at various stages of deployment. There may be a requirement that some links remain IPv4 only, or some that specifically should not have IPv6 connectivity (e.g., Scenario A of Table 1). There may also be a requirement that aggregatable global IPv6 addresses, assigned by the enterprise's upstream provider from the address space allocated to them by the Regional Internet Registries (RIRs), be assigned.
企業ネットワークでは、管理者は、一般のIPv6展開の様々な段階で特定のリンク上で有効にすることができるように、構造化され、制御された方法でIPv6を展開しよう。いくつかのリンクは、IPv4のみのまま要求、または具体的にIPv6接続を持っていなければならないこといくつか（例えば、表1のシナリオA）が存在してもよいです。また割り当てることが、地域インターネットレジストリ（RIRが）によってそれらに割り当てられたアドレス空間から、企業の上流プロバイダから割り当てられたグローバルIPv6アドレスを集約要件があるかもしれません。
In this document, we do not discuss the deployment of Unique Local IPv6 Unicast Addresses [ULA] because the address type and scope selected is orthogonal to the Layer 3 analysis of this document.
この文書では、我々は選択したアドレスの種類と範囲は、このドキュメントのレイヤ3分析に直交しているので、ユニークローカルIPv6ユニキャストは、[ULA]アドレスの展開については説明しません。
A typical deployment would initially involve the establishment of a single "testbed" Dual-IP subnet at the enterprise site prior to wider deployment. Such a testbed not only allows the IPv6 capability of specific platforms and applications to be evaluated and verified, but also permits the steps in Sections 7.3 and 7.4 of this document to be undertaken without (potential) adverse impact on the production elements of the enterprise.
典型的な展開は、最初は前より広く展開に、企業サイトでのシングル「たたき台」デュアルIPサブネットの確立を伴うだろう。そのようなテストベッドは、特定のプラットフォームおよびアプリケーションのIPv6の能力が評価され、検証されることを可能にするだけでなく、企業の生産要素に（潜在的な）悪影響なしに行われるため、セクション7.3およびこの文書の7.4の手順を可能にするだけでなく。
Section 7.5 describes the stages for the widespread deployment in the enterprise, which could be undertaken after the basic building blocks for IPv6 deployment are in place.
7.5節では、IPv6の展開のための基本的なビルディング・ブロックが整備されている後に着手することができ、企業内の広範囲に展開するための段階を説明しています。
A critical part of Dual-IP deployment is the selection of the IPv6- capable routing infrastructure to be implemented. The path taken will depend on whether the enterprise has existing Layer 2/3 switch/router equipment that has an IPv6 (routing) capability, or that can be upgraded to have such capability.
デュアルIP展開の重要な部分は、IPv6-可能なルーティングインフラストラクチャの選択が実施されるべきです。たどる経路は、企業がIPv6（ルーティング）機能を有するレイヤ2/3スイッチ/ルータ機器を既存している、またはそのような能力を有するようにアップグレードできるかどうかに依存するであろう。
In Section 4, we are not considering sparse IPv6 deployment; the goal of Dual-IP deployment is widespread use in the enterprise.
第4節では、スパースのIPv6導入を検討されていません。デュアルIPの展開の目標は、企業内で広く普及しています。
Where IPv6 routing capability exists within the infrastructure, the network administrator can enable IPv6 on the same physical hardware as the existing IPv4 service. Enabling both is the end-goal of any enterprise to support Dual-IP deployment, when the capability, performance, and robustness of the Dual-IP operational deployment has been verified.
IPv6ルーティング能力がインフラ内に存在する場合、ネットワーク管理者は、既存のIPv4サービスと同じ物理ハードウェア上でIPv6を有効にすることができます。両方とも有効にすると、デュアルIP業務展開の機能、性能、堅牢性が検証されたデュアルIPの展開をサポートするために、あらゆる企業のエンド目標です。
Ideally, the IPv6 capability will span the entire enterprise, allowing deployment on any link or subnet. If not, techniques from Section 4.4 may be required.
理想的には、IPv6の機能は、任意のリンクまたはサブネット上の展開を可能にし、企業全体に及ぶだろう。ない場合は、4.4節からの技術が必要になることがあります。
If the enterprise cannot provide IPv6 routing initially, there are alternative methods for transition. In this case, the enterprise administrator faces two basic choices, either to tunnel IPv6 over some or all of the existing IPv4 infrastructure, or to deploy a parallel IPv6 routing infrastructure providing IPv6 connectivity into existing IPv4 subnets.
企業は、最初のIPv6ルーティングを提供することができない場合は、遷移のための代替方法があります。この場合には、エンタープライズ管理者は、既存のIPv4インフラストラクチャの一部又は全ての上のいずれかのトンネルIPv6へ、二つの基本的な選択肢に直面している、または既存のIPv4サブネットにIPv6接続を提供平行IPv6ルーティングインフラストラクチャを展開します。
It may thus be the case that a node's IPv4 and IPv6 default routes to reach other links (subnets) are through different routing platforms.
したがって、ノードのIPv4およびIPv6デフォルトルートが、異なるルーティング・プラットフォームを介して他のリンク（サブネット）であるに到達する場合であってもよいです。
Consider the situation where there exists IPv6 edge routers that are IPv6-capable, while others, and perhaps the enterprise backbone itself, are not IPv6-capable (Scenario B of Table 1). Tunneling, as described in [BCNF], would be established between the Dual-IP capable routers on the enterprise, thus "bypassing" existing non IPv6-capable routers and platforms.
IPv6対応されたIPv6エッジルータ、他の一方で、おそらく企業バックボーン自体が存在する状況を考慮して、（表1のシナリオB）は、IPv6に対応していません。トンネリングは、[BCNF]に記載されているように、既存の非IPv6対応ルータおよびプラットフォームを「迂回」こうして、企業にデュアルIP可能ルータとの間で確立されるであろう。
In the widespread Dual-IP scenario, a more structured, manageable method is required, where the administrator has control of the deployment per-link and (ideally) long-term, aggregatable global IPv6 addressing is obtained, planned, and used from the outset.
広範囲のデュアルIPのシナリオでは、より構造化され、管理しやすい方法は、管理者は、展開の制御を有する場合、必要とされるごとのリンクと（理想的には）長期的、計画的取得、および当初から使用されているアドレス指定を集約可能グローバルIPv6 。
Alternatively, the administrator may deploy a new, separate IPv6- capable router (or set of routers). It is quite possible that such a parallel infrastructure would be IPv6-dominant.
あるいは、管理者が新しい、別個IPv6-対応ルータ（またはルータのセット）を配備することができます。このような並列インフラがIPv6-支配的になることは非常に可能です。
Such an approach would likely require additional hardware, but it has the advantage that the existing IPv4 routing platforms are not disturbed by the introduction of IPv6.
このようなアプローチは、おそらく追加のハードウェアを必要とするが、それは、既存のIPv4ルーティング・プラットフォームは、IPv6の導入によって妨害されていないという利点があります。
To distribute IPv6 to existing IPv4 enterprise subnets, either dedicated physical infrastructure can be employed or, if available, IEEE 802.1q VLANs could be used, as described in [VLAN]. The latter has the significant advantage of not requiring any additional physical cabling/wiring and also offers all the advantages of VLANs for the new Dual-IP environment. Many router platforms can tag multiple VLAN IDs on a single physical interface based on the subnet/link the packet is destined for; thus, multiple IPv6 links can be collapsed for delivery on a single (or small number of) physical IPv6 router interface(s) in the early stages of deployment.
既存のIPv4企業サブネットにIPv6を配布し、いずれかの専用物理インフラストラクチャに[VLAN]で説明したように、IEEE 802.1Q VLANは、使用することができる利用可能な場合、使用またはすることができます。後者は、追加の物理的なケーブル接続/配線を必要としないという大きな利点を持っており、また新しいデュアルIP環境用のVLANのすべての利点を提供しています。多くのルータプラットフォームは、サブネットに基づいて、単一の物理インターフェイス上に複数のVLAN IDをタグ付けすることができます/パケットを宛てているリンク。従って、複数のIPv6リンクは、展開の初期段階における物理IPv6ルータインターフェイス（複数可）は、単一の（または少数）に送達するために折り畳むことができます。
The parallel infrastructure should only be seen as an interim step towards full Dual-IP deployment on a unified infrastructure. The parallel infrastructure however allows all other aspects of the IPv6 enterprise services to be deployed, including IPv6 addressing, thus making the enterprise ready for that unifying step at a later date.
並列インフラストラクチャは、統一されたインフラストラクチャの完全なデュアルIP展開に向けて中間ステップとして理解されるべきです。平行インフラしかしIPv6のエンタープライズサービスの全ての他の態様は、このように、IPv6アドレスを含む後日その統合のステップのための企業の準備ができて製造、配備されることを可能にします。
When the enterprise's users are off-site, and using an ISP that does not support any native IPv6 service or IPv6 transition aids, the enterprise may consider deploying it's own remote IPv6 access support. Such remote support might for example be offered by deployment of an IPv6 Tunnel Broker [TBRK].
企業のユーザーがオフサイトであり、任意のネイティブIPv6サービスやIPv6移行補助をサポートしていないISPを使用している場合、企業は、それ自身のリモートのIPv6アクセスサポートの展開を検討します。例えば、このようなリモートサポートかもしれないは、IPv6トンネルブローカ[TBRK]の展開によって提供されます。
There are some issues associated with turning IPv6 on by default, including application connection delays, poor connectivity, and network insecurity, as discussed in [V6DEF]. The issues can be worked around or mitigated by following the advice in [V6DEF].
[V6DEF]で説明したように、アプリケーション接続の遅延、貧弱な接続、およびネットワークの不安を含め、デフォルトで上のIPv6をオンに関連付けられているいくつかの問題があります。問題は、[V6DEF]でアドバイスに従うことによって回避または軽減することができます。
This section covers Scenario 2 as described in Section 3.1 of [BSCN]. This scenario assumes the requirements defined within the [BSCN] text.
【BSCN]のセクション3.1に記載されているように、このセクションでは、シナリオ2を覆っています。このシナリオでは、[BSCN]テキスト内で定義された要件を前提としています。
IPv6 deployment within the enterprise network, with an existing IPv4 infrastructure, could be motivated by mission-critical or business applications or services that require IPv6. In this case, the prerequisite is that only the nodes using those IPv6 applications need to be upgraded to be IPv6-capable. The routing infrastructure will not be upgraded to support IPv6, nor does the enterprise wish to deploy a parallel IPv6 routing infrastructure at this point, since this is an option in Section 4.
既存のIPv4インフラストラクチャと企業ネットワーク内でのIPv6の展開は、ミッションクリティカルまたはビジネスアプリケーションまたはIPv6を必要とするサービスによって動機づけすることができます。この場合、前提条件は、これらのIPv6アプリケーションを使用してのみノードがIPv6-できるようにアップグレードする必要があることです。ルーティングインフラストラクチャは、IPv6をサポートするようにアップグレードされることはありません、また、これは、セクション4でオプションであるため、企業は、この時点で平行IPv6ルーティングインフラストラクチャを展開したいん。
There is a need for end-to-end communication with IPv6, but the infrastructure only supports IPv4 routing. Thus, the only viable method for end-to-end communication with IPv6 is to tunnel the traffic over the existing IPv4 infrastructure as defined in this analysis document.
そこIPv6でのエンドツーエンド通信の必要性があるが、インフラストラクチャは、IPv4のみのルーティングをサポートしています。このように、IPv6でのエンドツーエンド通信のための唯一の実行可能な方法は、この分析の文書で定義されている既存のIPv4インフラストラクチャ上のトラフィックは、トンネルです。
The network team needs to decide which of the available transition tunneling mechanisms are the most efficient to deploy, so they can be used without disrupting the existing IPv4 infrastructure. Several conditions require analysis, as introduced in the following sub-sections.
ネットワークチームが展開するのが最も効率的である可能な遷移トンネリングメカニズムのかを決定する必要があるので、彼らは既存のIPv4インフラストラクチャを中断することなく使用することができます。以下のサブセクションで導入され、いくつかの条件は、分析を必要とします。
Let's assume the upstream provider has deployed some IPv6 services, either native IPv6 in its backbone or in the access network, or some combination of both (Scenario B of Table 1). In this case, the provider will likely also deploy one or more transition mechanisms to support their IPv6 subscribers. Obviously, the enterprise could decide to take advantage of those transition services offered from the Provider. However, this will usually mean that individual nodes in the network require their own IPv6-in-IPv4 tunnel. The end result is somewhat inefficient IPv6 intranetworks communication, because all IPv6 traffic must be forwarded by the enterprise's IPv4 infrastructure to the Tunnel Endpoint offered by the Provider. Nevertheless, this may be acceptable, particularly if the IPv6 applications do not require intranetworks communication at all -- for example, when an application's server is located outside of the enterprise network, or on other intranetworks of the same enterprise.
ネイティブその骨格内のIPv6またはアクセスネットワークに、またはその両方の組み合わせ（表1のシナリオB）のいずれか、上流プロバイダは、いくつかのIPv6サービスを展開していると仮定しましょう。この場合、プロバイダは、おそらくまた、彼らのIPv6の加入者をサポートするために、1つのまたは複数の移行メカニズムを展開します。明らかに、企業はプロバイダーから提供されるもの移行サービスを利用するために決めることができました。しかし、これは通常、ネットワーク内の各ノードが自分のIPv6型のIPv4トンネルを必要とすることを意味します。すべてのIPv6トラフィックはプロバイダによって提供されるトンネルエンドポイントへの企業のIPv4インフラによって転送されなければならないので、最終的な結果は、IPv6のintranetworks通信やや非効率的です。例えば、アプリケーションのサーバは、企業ネットワークの外部、または同じ企業の他のintranetworksに配置されている場合 - それにもかかわらず、これは、IPv6アプリケーションが全くintranetworks通信を必要としない場合は特に、許容可能であり得ます。
Alternatively, the enterprise could decide to deploy its own transition mechanism node, possibly collocating it adjacent to the border router that connects to the upstream Provider. In this case, intranetnetworks communication using this tunnel endpoint is also possible.
代替的に、企業は、おそらく上流プロバイダに接続する境界ルータにそれが隣接共存さ、独自の遷移機構のノードを展開することを決定する可能性があります。この場合には、このトンネルのエンドポイントを使用intranetnetworks通信も可能です。
If the number of nodes to be using IPv6 is low, the first option is to use statically configured tunnels. However, automatically configured tunnels may be preferable, especially if the number is higher.
IPv6を使用するノードの数が少ない場合、最初のオプションは、静的に構成されたトンネルを使用することです。しかし、自動的に設定されたトンネルは、数が高い場合は特に、好ましいかもしれません。
In this section we are covering Scenario 3 as described in Section 3.1 of [BSCN]. The scenario, assumptions, and requirements are driven from the [BSCN] text. Within this document, this situation is captured in Scenario C of Table 1.
【BSCN]のセクション3.1に記載したようにこのセクションでは、シナリオ3をカバーしています。シナリオ、仮定、および要件は、[BSCN]テキストから駆動されます。この文書内で、このような状況は、表1のシナリオCで捕捉されます。
Some enterprise networks may wish to employ an IPv6-dominant network deployment strategy. What this means essentially is that the network or specific sites within the enterprise network will transition to IPv6 using only IPv6 routing to transfer both IPv4 and IPv6 packets over the network, even though the network may be Dual-IP capable. IPv4 routing would not be turned on within an IPv6-dominant network, except if required to support edge IPv4 networks.
いくつかの企業ネットワークは、IPv6-支配的なネットワーク展開方策を採用することができます。これは本質的に意味することは、企業ネットワーク内のネットワークまたは特定のサイトは、ネットワークが可能なデュアルIPであっても、ネットワーク上でIPv4とIPv6の両方のパケットを転送するだけのIPv6ルーティングを使用して、IPv6への移行ということです。 IPv4ルーティングは、エッジIPv4ネットワークをサポートするために必要な場合を除いて、IPv6がドミナントネットワーク内でオンされないであろう。
Under this scenario, communications between IPv6 nodes will use IPv6. When IPv6-capable nodes in the IPv6-dominant network need to communicate with IPv4 nodes, the IPv6 nodes will use their Dual-IP implementation to tunnel IPv4 packets in IPv6 [V6TUN]. An edge router within the IPv6-dominant network will decapsulate the IPv4 packet and route to the path of the IPv4 node on the network. This permits Dual-IP layer nodes to communicate with legacy IPv4 nodes within an IPv6-dominant network.
このシナリオでは、IPv6ノード間の通信は、IPv6を使用します。 IPv6の優性ネットワークにおけるIPv6対応のノードがIPv4ノードと通信する必要がある場合、IPv6ノードは、IPv6 [V6TUN】トンネルIPv4パケットへのデュアルIP実装を使用します。 IPv6の優位ネットワーク内のエッジルータは、ネットワーク上のIPv4ノードの経路にIPv4パケット及びルートをデカプセル化します。これは、IPv6-ドミナントネットワーク内のレガシーIPv4ノードと通信するためにデュアルIPレイヤノードを可能にします。
Scenarios E and F from Table 1 depict additional cases where an IPv6-dominant deployment strategy could be in place. In Scenario E, the entire network could be IPv6-dominant, but the Host OS 2 system is running an IPv4 application. In Scenario F, the Host OS 1 system network could be IPv6-dominant, but the rest of the networks are all IPv4.
IPv6のドミナント展開戦略が所定の位置にあることができ、表1を描い追加の例からシナリオEとF。シナリオEにおいては、全体のネットワークは、IPv6-優勢であり得るが、ホストOS 2システムは、IPv4アプリケーションを実行しています。シナリオFでは、ホストOS 1システムネットワークがIPv6-支配的かもしれないが、ネットワークの残りの部分は、すべてのIPv4です。
In each case, communicating with an IPv4 end host or over an IPv4 network requires that a transition point exist within the network to support that operation. Furthermore, the node in the IPv6-dominant network must acquire an IPv4 address (to interoperate with the IPv4 end host), and locate a tunnel endpoint on their network which permits the IPv4 packet to be tunneled to the next-hop IPv6 router and eventually to a destination Dual-IP router.
各場合において、IPv4のエンドホストまたはIPv4ネットワークを介して通信する遷移点は、その動作をサポートするネットワーク内に存在することを必要とします。また、IPv6の優性ネットワーク内のノードは、IPv4アドレス（IPv4エンドホストと相互運用する）を取得し、最終的に次のホップIPv6ルータとにトンネルされるIPv4パケットを許可し、ネットワーク上のトンネルエンドポイントを見つけなければなりません先デュアルIPルータへ。
While retaining interoperability with IPv4 is a noble goal for enterprise architects, it is an unfortunate fact that maintaining IPv4 services in an IPv6-dominant network slows and may even impede your ability to reap the maximum benefits of IPv6.
IPv4の相互運用性を維持することは、エンタープライズ・アーキテクトのための崇高な目標ですが、IPv6-支配的ネットワークでのIPv4サービスを維持することが遅くなり、さらにはIPv6の最大のメリットを享受するためにあなたの能力を妨げることがあります。という不幸な事実であります
The decision whether or not to use an IPv6-dominant network deployment strategy is completely driven by the enterprise's business and operational objectives and guided by the enterprise's transition plan.
IPv6の優位ネットワーク展開戦略を使用するかどうかの決定は完全に企業のビジネスおよび運用目標によって駆動され、企業の移行計画によって導かれます。
In this section, we describe generic enterprise IPv6 deployment issues, applicable to the analysis in Sections 4-6 of this document.
このセクションでは、このドキュメントのセクション4-6の分析に適用される一般的な企業のIPv6展開の問題を、説明します。
The enterprise network administrator will need to follow a staged plan for IPv6 deployment. What this means is that a strategic identification of the enterprise network must be performed for all points and components of the transition.
企業のネットワーク管理者は、IPv6の展開のための段階的な計画を実行する必要があります。これが意味することは、企業ネットワークの戦略的な識別は、遷移のすべてのポイントとコンポーネントのために実行しなければならないことです。
The considerations for the enterprise components are detailed in Section 3.2 of [BSCN]. We do not go into detail on all aspects of such components in this document. In this document, we focus on Layer 3 issues.
エンタープライズコンポーネントの考慮事項は、[BSCN]のセクション3.2に詳述されています。私たちは、この文書に記載されているこのような構成要素のすべての側面について、詳細には触れません。この文書では、我々は、レイヤ3つの問題に焦点を当てます。
The first steps for IPv6 deployment do not involve technical aspects per se; the enterprise needs to select an external IPv6 provider and obtain globally routable IPv6 address space from that provider.
IPv6の展開のための最初のステップは、それ自体の技術的な側面を含みません。企業は、外部のIPv6プロバイダを選択し、そのプロバイダからグローバルにルーティング可能なIPv6のアドレス空間を取得する必要があります。
The enterprise service provider would typically be a topographically close IPv6 provider that is able to provide an IPv6 upstream link. It would be expected that the enterprise would use either native IPv6 upstream connectivity or, in its absence, a manually configured tunnel [BCNF] to the upstream provider.
エンタープライズ・サービス・プロバイダは、典型的には、IPv6の上流のリンクを提供することができる地形的に近接したIPv6プロバイダであろう。企業が上流プロバイダに[BCNF】ネイティブIPv6上流接続や、その非存在下で、手動で設定されたトンネルのいずれかを使用することが期待されるであろう。
The enterprise will obtain global IPv6 address space from its selected upstream provider, as provider-assigned (PA) address space.
企業は、プロバイダが割り当て（PA）アドレス空間として、その選択された上流プロバイダからグローバルIPv6アドレス空間を取得します。
The enterprise should receive at least a /48 allocation from its provider, as described in [ALLOC].
[ALLOC]で説明したように、企業は、そのプロバイダから少なくとも/ 48割当を受けるべきです。
Should an enterprise change their provider, a procedure for enterprise renumbering between providers is described in [RENUM].
企業がそのプロバイダを変更する必要があり、プロバイダ間エンタープライズ・リナンバリングのための手順は、[RENUM]に記載されています。
Most of these are discussed in Section 4 of [BSCN]. Here we comment on those aspects that we believe are in scope for this analysis document. Thus, we have not included network management, multihoming, multicast, or application transition analysis here; however, these aspects should be addressed in Stage 2.
これらのほとんどは、[BSCN]のセクション4で議論されています。ここでは、我々はこの分析文書の範囲内にあると考えているこれらの側面にコメント。したがって、ここでは、ネットワーク管理、マルチホーミング、マルチキャスト、またはアプリケーションの移行解析を含めていません。しかし、これらの側面は、第2段階で対処しなければなりません。
A site will need to formulate an IPv6 addressing plan, utilizing the globally aggregatable public IPv6 prefix allocated to it by its upstream connectivity provider.
サイトでは、その上流接続プロバイダーによってそれに割り当てられたグローバル集約公共IPv6プレフィックスを利用し、IPv6のアドレス指定の計画を策定する必要があります。
In a Dual-IP deployment, the site will need to decide whether it wishes to deploy IPv6 links to be congruent with existing IPv4 subnets. In this case, nodes will fall into the same links or subnets for both protocols. Such a scheme could be followed, with IPv6 prefix allocations being made such that room for topological growth is provisioned (reducing the potential requirement for future renumbering due to restructuring).
デュアルIPの展開では、サイトには、それが既存のIPv4サブネットと一致するIPv6のリンクを展開することを希望するかどうかを決定する必要があります。この場合、ノードは、両方のプロトコルに対して同じリンクまたはサブネットに落ちます。 IPv6プレフィックスの割り当てが（によるリストラに将来リナンバリングのための潜在的な必要性を減少させる）トポロジー成長のためのように部屋がプロビジョニングされて作られてこのような方式は、続くことができます。
A beneficial property of IPv6 is that an administrator will not need to invest as much effort in address conservation. With IPv4, a site will likely allocate IPv4 subnets to be as small as possible for the number of hosts currently in the subnet (e.g., a /26 for 50 nodes) because IPv4 address conservation is required. This creates problems when the number of nodes on a subnet grows, larger IPv4 prefixes are then required, and potentially time-consuming and disruptive renumbering events will follow.
IPv6のの有益な特性は、管理者がアドレス保全にできるだけ多くの労力を投資する必要がないということです。 IPv4アドレスの節約が要求されるためのIPv4と、サイトは、おそらく（50個のノードに対して、例えば、/ 26）現在のサブネット内のホストの数をできる限り小さくするのIPv4サブネットを割り当てます。サブネット上のノードの数が多いのIPv4プレフィックスは、その後、必要とされる、成長し、潜在的に時間がかかり、破壊的なリナンバリングイベントが続くときに問題を作成します。
With IPv6, a link can in effect have any number of nodes, allowing link growth without the need to adjust prefix allocations with the associated renumbering requirement. The size of the initial site allocation (currently recommended to be a /48) also is likely to allow room for site growth without a need to return to the connectivity provider to obtain more, potentially non-sequential, address space (as is the case for IPv4 today, with the associated paperwork and probable delays).
IPv6では、リンクが有効に関連したリナンバリング要件とプレフィックスの割り当てを調整することなく、リンクの成長を可能にし、任意の数のノードを持つことができます。最初のサイトの割り当てのサイズは、（現在であることをお勧めします/ 48）もそうであるように（より多くを取得するために接続プロバイダー、潜在的に非シーケンシャル、アドレス空間に戻る必要なしに、サイトの成長のための部屋を許可する可能性がありますIPv4の今日、関連する事務処理と予想遅延）で。
At the time of writing, best practice in IPv6 site address planning is restricted due to limited wide-scale deployments. Administrators should allocate /64 size prefixes for subnets, and do so in a way that has scope for growth within a site. The site should utilize a plan that reserves space for topological growth in the site, given that its initial IPv6 prefix allocation (currently recommended to be a /48) is likely to include such room for growth. Also see "IPv6 Unicast Address Assignment" [UNAD].
執筆時点では、IPv6のサイトのアドレス計画におけるベストプラクティスを伴う限ら大規模な展開に制限されています。管理者は、サブネットの/ 64サイズ接頭辞を割り当て、サイト内の成長のためのスコープを持っているように、そうする必要があります。このサイトは（現在は/ 48であることをお勧めします）、その最初のIPv6プレフィックスの割り当ては、成長のために、このような部屋を含まれている可能性が高いことを考えると、サイト内のトポロジカルな成長のためのスペースを確保し計画を活用すべきです。また、「IPv6ユニキャストアドレスの割り当て」[UNAD]を参照してください。
The enterprise site should deploy a DNS service that is capable of both serving IPv6 DNS records using the AAAA format [DNSV6R] and communicating over IPv6 transport.
企業サイトは、サービスのIPv6 DNSレコード[DNSV6R] AAAAフォーマットを使用し、IPv6トランスポートを介して通信の両方が可能なDNSサービスを配備すべきです。
Specific IPv6 DNS issues are reported in [DNSOP6].
特定のIPv6 DNSの問題は、[DNSOP6]で報告されています。
The enterprise network will need to support methods for internal and external routing.
企業ネットワークは、内部と外部のルーティングのための方法をサポートする必要があります。
For a single-homed single-site network, a static route to a single upstream provider may be sufficient, although the site may choose to use an exterior routing protocol, especially where it has multiple upstream providers.
サイトは、複数の上流プロバイダを有し、特にここで、外部ルーティングプロトコルを使用することを選択するかもしれないが、単一のホームシングルサイトネットワークのために、単一の上流プロバイダへの静的ルートは、十分であり得ます。
For internal routing, an appropriate interior routing protocol may be deployed. IPv6 routing protocols that can be used are as follows: BGP4+ [BGP4], IS-IS [ISIS], OSPFv3 [OSPF], and RIPng [RIPng].
内部ルーティングのために、適切な内部ルーティングプロトコルが配備されてもよいです。 RIPngの[たRIPng] BGP4 + [BGP4]、ISIS [ISIS]、OSPFv3の[OSPF]、そして以下のように使用することができるIPv6ルーティングプロトコルがあります。
An enterprise network will have a number of tools available for the delegation and management of IPv4 addresses and other configuration information. These include manual configuration, NIS [NIS], and DHCP [DHCPv4].
企業ネットワークはIPv4アドレスおよびその他の構成情報の委任と管理のために利用可能なツールの数を持っています。これらは、手動設定、NIS [NIS]、およびDHCP [DHCPv4の]を含んでいます。
In an IPv6 enterprise, Stateless Address Autoconfiguration [CONF] may be used to configure a host with a global IPv6 address, a default router, and on-link prefix information.
IPv6の企業では、ステートレスアドレス自動設定[CONF]はグローバルIPv6アドレスを持つホスト、デフォルトルータ、およびオンリンクプレフィックス情報を設定するために使用することができます。
Where support for secure autoconfiguration is required, SEND [SEND] can be used. Readers should see the applicability statements to IPsec [IPSEC] within the SEND document.
安全な自動設定のためのサポートが必要な場合は、使用することができます[SEND]を送信します。読者はSEND文書内のIPsec [IPSEC]に適用文が表示されるはずです。
A stateless configured node wishing to gain other configuration information (e.g., DNS, NTP servers) will likely need a Stateful DHCPv6 [DHCPv6] service available.
その他の構成情報（例えば、DNS、NTPサーバ）を獲得することを望むステートレス構成されたノードは、おそらく利用可能なステートフルDHCPv6の【のDHCPv6]サービスを必要とします。
For nodes configuring using DHCPv6, where DHCPv6 servers are offlink, a DHCPv6 Relay Agent function will be required. Where DHCPv4 and DHCPv6 service are deployed together, dual-stack considerations need to be made, as discussed within current work on DHCP dual-stack issues [DHDS].
DHCPv6サーバがオフリンクされたDHCPv6を使用して構成するノードについては、DHCPv6のリレーエージェント機能が必要となります。 DHCPv4とDHCPv6サービスが一緒に配備されている場合は、デュアルスタックの考慮事項は、DHCPデュアルスタックの問題[DHDS]に、現在の仕事の中に説明したように、なされる必要があります。
Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6]; there is support for DHCPv6 to assign privacy addresses to nodes in managed environments.
ホストはまた、生成することができるまたは要求のIPv6プライバシー[PRIVv6]アドレス。管理環境内のノードにプライバシーアドレスを割り当てるにはDHCPv6のサポートがあります。
When deploying IPv6 within a Dual-IP network, a site will need to implement its site security policy for IPv6-capable nodes as it does for IPv4-capable nodes. For example, a border firewall should be capable of filtering and controlling IPv6 traffic by enforcing the same policy as it already does for IPv4.
デュアルIPネットワーク内でIPv6を展開する場合、サイトは、IPv4対応ノードの場合と同様にIPv6対応ノードのために、そのサイトのセキュリティポリシーを実装する必要があります。例えば、境界ファイアウォールは、それが既にIPv4の場合と同じポリシーを適用することによりフィルタリング及び制御IPv6トラフィックことができなければなりません。
However, a site will also need to review its security policy in light of IPv6-specific functionality that will be deployed in the site, e.g., Mobile IPv6, stateless autoconfiguration (and SEND), IPv6 Privacy Extensions, and end-to-end IPsec. In addition, a site will need to review the use of globally aggregatable public address space where, for IPv4, private addressing and NAT may have been used.
しかし、サイトでは、IPv6固有のサイト内に展開される機能は、例えば、モバイルIPv6、ステートレス自動設定（およびSEND）、IPv6のプライバシーの拡張機能、およびエンドツーエンドのIPsecの光にそのセキュリティポリシーを確認する必要があります。また、サイトでは、IPv4のために、民間のアドレッシングおよびNATが使用されている可能性があり、世界的に集約パブリックアドレス空間の使用を検討する必要があります。
An overview of how Network Architecture Protection (NAP) using IPv6 can provide the same or more benefits without the need for NAT can be found in [NAP]. This describes how the perceived security with IPv4 NAT can be achieved and surpassed with IPv6, i.e., how IPv6 technology can be used to provide the market-perceived benefits of IPv4 NAT.
IPv6はNATを必要とせずに、同じまたはより多くの利益を提供することができます使用してどのようにネットワークアーキテクチャ保護（NAP）の概要は、[NAP]で見つけることができます。これは、IPv4のNATと認識されるセキュリティは、IPv6技術は、IPv4 NATの市場認知の利点を提供するために使用することができ、すなわち、どのように、IPv6で実現して突破する方法について説明します。
Where deployed, intrusion detection systems will need to be enhanced to check IPv6 transport both for known application layer attack patterns and for new potential IPv6 threats, e.g., excessive hop-by-hop headers or errant IPv6 header options.
展開ここで、侵入検知システムは、既知のアプリケーション層の攻撃パターンおよび新しい可能性IPv6の脅威、例えば、過剰なホップバイホップヘッダーや誤ったIPv6ヘッダオプションの両方IPv6トランスポートをチェックするように拡張される必要があります。
The deployment of specific transition mechanisms may also introduce threats, e.g., carrying IPv6 data tunneled in IPv4. The site security policy should embrace the transition mechanisms that are deployed.
特定の遷移メカニズムの展開はまた、IPv4のトンネリングIPv6のデータを搬送する、例えば、脅威を導入することができます。サイトのセキュリティポリシーが展開されている移行メカニズムを採用すべきです。
An overview of IPv6 security issues can be found in [V6SEC]. This includes discussion of issues specific to the IPv6 protocol, to transition mechanisms, and to IPv6 deployment itself.
IPv6のセキュリティ問題の概要は、[V6SEC]で見つけることができます。これは、IPv6プロトコルに、移行メカニズム、およびIPv6展開自体に固有の問題の議論を含みます。
In addition, an enterprise should review all current host-based security requirements for their networks and verify support for IPv6.
加えて、企業は自社のネットワークのためのすべての現在のホスト・ベースのセキュリティ要件を見直し、IPv6のサポートを確認する必要があります。
With the basic building blocks of external connectivity, interior IPv6 routing, an IPv6 DNS service, and address allocation management in place, the IPv6 capability can be rolled out to the wider enterprise. This involves putting IPv6 on the wire in the desired links, and enabling applications and other services to begin using an IPv6 transport.
外部接続、内部IPv6ルーティング、IPv6のDNSサービス、および場所のアドレス割り当て管理の基本的なビルディング・ブロックでは、IPv6の機能は、より広い企業にロールアウトすることができます。これは、所望のリンクにワイヤーでIPv6を入れて、IPv6トランスポートの使用を開始するアプリケーションやその他のサービスを可能にすることを伴います。
In the Dual-IP deployment case, this means enabling IPv6 on existing IPv4 subnets. As described in Section 7.4.4, above, it is likely that IPv6 links will be congruent with IPv4 subnets because IPv4 subnets tend to be created for geographic, policy, or administrative reasons that would be IP version-independent.
デュアルIP展開場合、これは、既存のIPv4サブネット上のIPv6を有効にすることを意味します。上記7.4.4項で説明したように、IPv4サブネットはIPのバージョンに依存しないだろう、地理的なポリシー、または管理上の理由のために作成される傾向があるため、IPv6のリンクはIPv4のサブネットと合同になる可能性が高いです。
While the use of IPv6 by some applications can be administratively controlled (e.g., in the case of open source software by compiling the application without IPv6 support enabled), the use of IPv6 transport, and preference over IPv4 transport, will vary per application based on the developer/author's implementation.
一部のアプリケーションでのIPv6の使用が管理（例えば、有効IPv6サポートなしでアプリケーションをコンパイルすることにより、オープンソースソフトウェアの場合）IPv6トランスポートの使用を制御し、IPv4トランスポートよりも優先することができるが、アプリケーションごとに変化するであろう基づい開発者/著者の実装。
A Dual-IP deployment will often be made by sites wishing to support use of IPv6 within a site, even if IPv6 transport is not preferred by all applications. Putting support for IPv6 in all site infrastructure (DNS, email transport, etc.) allows IPv6 usage to be phased in over time. As nodes become IPv6 capable, and applications and services IPv6 enabled, the IPv6 capable infrastructure can be leveraged. For most networks, Dual-IP will be at the very least a medium-term transition towards an IPv6-dominant future. However, the introduction of IPv6 support, with the potential benefits of globally aggregatable public address usage (with [NAP]) and other new IPv6 capabilities, can bring more immediate benefits for the site.
デュアルIPの展開は、多くの場合、IPv6トランスポートは、すべてのアプリケーションで好まれていない場合でも、サイト内でのIPv6の使用をサポートしたいサイトによって行われます。すべてのサイトのインフラストラクチャ（DNS、メール転送、など）でのIPv6のサポートを置くとIPv6の使用量が時間をかけて段階的することができます。ノードがIPv6対応になり、アプリケーションやサービスのIPv6が有効になっているように、IPv6のできるインフラを活用することができます。ほとんどのネットワークでは、デュアルIPは、IPv6-支配的な未来に向けた非常に少なくとも中期的な推移となります。しかし、世界的に集約パブリックアドレスの使用状況（と[NAP]）および他の新しいIPv6機能の潜在的な利点を持つIPv6サポートの導入は、サイトのより直接的な利益をもたらすことができます。
This section will provide general guidance for the use of specific transition mechanisms which in turn can be used by the enterprise to support the enterprise matrix notional networks (rows) in Section 3, and within the context of the analysis discussed in Sections 4, 5, and 6.
このセクションでは、順番に第3の企業マトリックス概念的ネットワーク（行）をサポートするために企業によって使用され得る特定の遷移メカニズムの使用のための一般的なガイダンスを提供し、セクション4、5で説明した分析の文脈の中であろうそして6。
Table 1 provides a number of common scenarios that an enterprise architect might encounter as they consider how and where they should consider deploying transition mechanisms to support the network transition to IPv6. Selecting the most appropriate mechanism for each scenario is more of an art than a science and consequently making recommendations against each of the ten scenarios would be simply fodder for sharpshooters touting their favored product. However we can provide some high-level guidance that should benefit the architect's decision-making process.
表1は、それらがどのように、彼らは、IPv6へのネットワークの移行をサポートするために展開移行メカニズムを検討すべきである場合考慮するとして、エンタープライズ・アーキテクトが発生する可能性のある一般的なシナリオの数を提供します。各シナリオのための最も適切なメカニズムを選択することは、科学よりも芸術のより多く、その結果、10本の各シナリオに対して勧告を行うことは自分の好む製品を売り込んで狙撃兵のために簡単に餌食になります。しかし私たちは、建築家の意思決定プロセスに利益をもたらす必要があり、いくつかの高レベルのガイダンスを提供することができます。
Mapping your specific situation into one of the ten scenarios of Table 1 is far less important than recognizing the critical touchpoints within the enterprise networks where incompatible networks interface. Unless a transition mechanism is being offered by the enterprise as a service, it is at these touchpoints that a mechanism must be considered.
表1の10本のシナリオのいずれかに特定の状況をマッピングするとはるかに重要な互換性のないネットワークインターフェイス企業ネットワーク内の重要なタッチポイントを認識することよりもです。移行メカニズムをサービスとして、企業によって提供されていない限り、それはメカニズムが考慮されなければならないこれらのタッチポイントです。
A quick review of Table 1 reveals that the ten scenarios can be boiled down to variations of four major themes. The simplest, but also most favored (due to its flexibility), is widespread Dual-IP with compatible hosts at either end. This situation is illustrated in Scenario A, and transition mechanism considerations have already been described in some detail in Section 4.
表1のクイックレビューは10本のシナリオは、4つの主要なテーマのバリエーションに煮詰めことができることが明らかになりました。 （これはその柔軟性に）最も簡単なだけでなく、最も好まれ、両端に互換性のあるホストとのデュアルIP普及しています。この状況は、シナリオAに示され、遷移機構の考察は、既に第4章である程度詳細に記載されています。
In the second common theme (depicted in Scenarios B-D of Table 1), the enterprise is comprised of compatible hosts, with one or more incompatible network touchpoints in between. As described in Section 4.2.2.1, tunneling can be used to "bypass" the incompatible network segments. One tunneling option, manually configured tunnels [BCNF] could be used by the enterprise, but as the name implies, this mechanism provides no automated tunnel configuration.
（表1のシナリオB-Dに示されている）は、第2の共通のテーマでは、企業は、間の内の1つまたは複数の互換性のないネットワークのタッチポイントで、互換性のあるホストで構成されています。セクション4.2.2.1に記載されているように、トンネリングは「バイパス」互換性のないネットワークセグメントに使用することができます。一のトンネリングオプションは、手動で設定されたトンネルは、[BCNF】企業によって使用することができるが、名前が示すように、この機構には自動化されたトンネルの設定を提供しません。
"Connection of IPv6 Domains via IPv4 Clouds" [6TO4] can be used to support enterprises that do not have an assigned IPv6 prefix address.
「IPv4の雲を介したIPv6のドメインの接続」[6TO4]は割り当てられたIPv6プレフィックスアドレスを持っていない企業をサポートするために使用することができます。
Identifying the responsible device to perform the tunneling is driven by the position of the incompatible touchpoint. If a local network is incompatible, then host tunneling is appropriate. If the backbone (provider) network is incompatible, then gateway-to-gateway tunneling might be a better choice. By working to ensure tunnel endpoints are always configured at Dual-IP devices, end-to-end communication or services (IPv4 or IPv6) can be preserved.
トンネリングを実行する責任がデバイスを識別することは、互換性のないタッチポイントの位置によって駆動されます。ローカルネットワークに互換性がない場合、ホストトンネリングは適切です。バックボーン（プロバイダ）のネットワークに互換性がない場合は、ゲートウェイ間のトンネルは、より良い選択かもしれません。トンネルエンドポイントは、常にデュアルIPデバイスで構成されていることを確認するために働くことによって、エンドツーエンドの通信又はサービス（IPv4またはIPv6）を保存することができます。
Readers should review the current work regarding tunnels within the IETF Softwire working group and problem statement [SOFTW].
読者はIETF Softwireワーキンググループ内のトンネルや問題文[SOFTW]について、現在の作業を確認する必要があります。
Having IPv6 applications on a Dual-IP host on a v4-only network requires some form of tunneling. Where configured tunnels are not sufficient, a more automatic solution may be appropriate. Available solutions include the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [ISTP] or Teredo [TRDO] to tunnel to a v6 end service. ISATAP [ISTP] can be used to provide end-node IPv6 connectivity from nodes on an isolated IPv4 network, through the use of automatic tunneling of IPv6 in IPv4. Teredo [TRDO] can be used when the enterprise network is behind a NAT.
v4の専用ネットワーク上のデュアルIPホスト上のIPv6アプリケーションを持つことは、トンネルのいくつかのフォームが必要です。構成されたトンネルが十分でない場合、より自動ソリューションが適切であり得ます。利用可能なソリューションは、V6エンドサービスへのトンネルに[ISTP]またはTeredoの[TRDO]プロトコル（ISATAP）をアドレス指定イントラサイト自動トンネルを含みます。 ISATAPは[ISTP] IPv4のIPv6の自動トンネリングを使用することにより、単離されたIPv4ネットワーク上のノードからエンドノードのIPv6接続性を提供するために使用することができます。企業ネットワークは、NATの背後にある場合Teredoは[TRDO】使用することができます。
Enterprise architects should consider providing a Tunnel Broker [TBRK] [TSPB] as a cost-effective service to local users or applications. Tunnel Brokers can be used to provide tunnel setup for an enterprise using manually configured tunnels and 6TO4 [6TO4]. Tunnel Brokers can automate the use of tunnels across an enterprise deploying IPv6.
エンタープライズ・アーキテクトは、ローカルユーザーやアプリケーションへの費用対効果の高いサービスとして[TBRK] [TSPB]トンネルブローカーを提供することを検討すべきです。トンネルブローカーは、手動設定トンネルと6to4 [6TO4]を使用して、企業のためのトンネル設定を提供するために使用することができます。トンネルブローカーは、IPv6を導入する企業全体のトンネルの使用を自動化することができます。
Later in the transition process, after the enterprise has transitioned to a predominately IPv6 infrastructure, the architect will need to determine a network transition strategy to tunnel IPv4 within IPv6 [V6TUN] across IPv6-dominant links, or the enterprise Intranet. Or in the case of early deployment of IPv6-dominant networks, the architect will need to address this from the beginning of the required transition planning.
企業は、主にIPv6のインフラストラクチャに移行した後の後の遷移過程において、建築家は、IPv6-ドミナントリンク、または企業のイントラネットを横切っ[V6TUN] IPv6の内のIPv4トンネルにネットワーク移行戦略を決定する必要があります。またはIPv6-支配的なネットワークの早期導入の場合には、建築家は、必要な移行計画の最初からこの問題に対処する必要があります。
Having recognized incompatible network touchpoints, it is also incumbent on the architect to identify application incompatibilities. During the transition period, particularly for large enterprises, it is to be expected that an application hosted at one location may lead (or lag) the IPv6-compatibility of its peer (or server) at some other location.
互換性のないネットワークのタッチポイントを認識した、それはアプリケーションの非互換性を識別するために、建築家でも現職です。移行期間中、特に大企業のために、これは、1つの場所でホストされているアプリケーションは、いくつかの他の場所でそのピア（またはサーバ）のIPv6の互換性を導く（またはLAG）ことが予想されます。
This leads us to the third theme (represented by Scenarios E and G): incompatible applications communicating across a homogenous network. Translation is an obvious solution, but not recommended except for legacy devices that are at the network edge and cannot or never will be upgraded to IPv6. A more scalable solution would be to use an Application Layer Gateway (ALG) between the incompatible hosts.
均質なネットワークを介して通信互換性のないアプリケーション：これは（シナリオEおよびGによって表される）第三のテーマに私たちをリード。翻訳は明白な解決策ですが、ネットワークのエッジであるとIPv6にアップグレードされますないか、決してできレガシーデバイス以外はお勧めしません。よりスケーラブルなソリューションは、互換性のないホスト間のアプリケーション層ゲートウェイ（ALG）を使用することであろう。
Inevitably, during the course of transitioning a large enterprise to IPv6, the architect will be faced with both incompatible hosts and simultaneously (at different parts of the enterprise) incompatible networks. These highly complex situations represent the fourth common theme in Table 1 (specifically depicted by Scenarios F, H, I, and J). Maintaining IP interoperability in these situations requires additional planning and may require multiple or even nested use of diverse transition mechanisms. For example, an ALG collocated with the application server may be required to service both IPv4 and IPv6 data streams that are simultaneously tunneled through incompatible network segment(s).
必然的に、IPv6への大企業の移行の過程で、建築家は、互換性のないネットワーク（企業の異なる部分で）同時に互換性のないホストとの両方に直面します。これらの非常に複雑な状況は、表1の第四の共通のテーマ（具体的シナリオF、H、I、及びJで示す）を表します。このような状況でIPの相互運用性を維持するには、追加の計画が必要と多様な移行メカニズムの倍数、あるいはネストされた使用が必要な場合があります。例えば、アプリケーションサーバと並置ALGは同時に互換性のないネットワークセグメント（複数可）を介してトンネリングされ、IPv4とIPv6の両方のデータストリームをサービスするために必要とされ得ます。
Security considerations for IPv6 deployment in a Dual-IP environment are discussed above in Section 7.4.5, where external references to overview documents [V6SEC] [NAP] are also included.
デュアルIP環境でのIPv6の展開のためのセキュリティに関する考慮事項も含まれている外部参照概要文書に[V6SEC] [NAP]セクション7.4.5、して上述されています。
[CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[CONF]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[DHCPv6] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
【のDHCPv6] Droms、R.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315 、2003年7月。
[6TO4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
"IPv4の雲を介したIPv6ドメインの接続" [6TO4]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月。
[BSCN] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[BSCN] J.、エド。、 "IPv6のエンタープライズネットワークシナリオ"、RFC 4057、2005年6月には、バウンド。
[TRDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[TRDO]のHuitema、C.、 "Teredoの：UDP上でトンネリングIPv6ネットワーク経由アドレス変換器（NAT）"、RFC 4380、2006年2月。
[ISTP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, October 2005.
【ISTP]テンプリン、F.、グリーソン、T.、Talwar、M.、およびD.ターレル、 "イントラサイト自動トンネルプロトコル（ISATAP）をアドレス指定"、RFC 4214、2005年10月。
[V6TUN] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
【V6TUN]コンタ、A.、およびS.デアリング、 "IPv6の仕様の汎用パケットトンネリング"、RFC 2473、1998年12月。
[TBRK] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[TBRK]デュラン、A.、ファザーノ、P.、Guardini、I.、およびD.レント、 "IPv6のトンネルブローカー"、RFC 3053、2001年1月。
[ALLOC] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
"サイトへのIPv6アドレスの割り当てにIAB / IESG勧告" [ALLOC] IABとIESG、RFC 3177、2001年9月。
[NATPT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[NATPT] Tsirtsis、G.とP. Srisuresh、 "ネットワークアドレス変換 - プロトコル変換（NATPT）"、RFC 2766、2000年2月。
[UMAN] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks", RFC 3904, September 2004.
[UMAN]のHuitema、C.、Austeinと、R.、Satapati、S.、およびR.ファンデルポール、 "非管理ネットワークのIPv6移行メカニズムの評価"、RFC 3904、2004年9月。
[ISPA] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
、RFC 4029、2005年3月[ISPA]リンド、M.、Ksinant、V.、公園、S.、ボドー、A.、およびP. Savola、 "ISPネットワークにIPv6を導入するためのシナリオと分析"。
[3GPA] Wiljakka, J., Ed., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005.
[3GPA] Wiljakka、J.、エド。、RFC 4215 "第三世代パートナーシッププロジェクト（3GPP）ネットワークにおけるIPv6移行に関する分析"、2005年10月。
[OSPF] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[OSPF] Coltun、R.、ファーガソン、D.、およびJ.モイ、 "IPv6のためのOSPF"、RFC 2740、1999年12月。
[BGP4] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[BGP4]ベイツ、T.、チャンドラ、R.、カッツ、D.、およびY. Rekhter、 "BGP4のためのマルチプロトコル拡張機能"、RFC 4760、2007年1月。
[ISIS] Oran, D., Ed., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142, February 1990.
[ISIS]オラン、D.編、 "OSI ISISイントラドメインルーティングプロトコル"、RFC 1142、1990年2月。
[RIPng] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RIPngの]マルキン、G.およびR. Minnear、 "IPv6のためのRIPng"、RFC 2080、1997年1月。
[APPS] Shin, M-K., Ed., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[APPS]シン、M-K。、編、香港、Y-G。、萩野、J.、Savola、P.、およびE.カストロ、 "IPv6移行のアプリケーション側面"、RFC 4038、2005年3月。
[RENUM] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RENUM]ベイカー、F.、リア、E.、およびR. Droms、 "国旗の日なしでIPv6ネットワークを再番号付けのための手順"、RFC 4192、2005年9月。
[BCNF] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[BCNF] Nordmarkと、E.とR.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。
[ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[ULA] HindenとR.とB.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、2005年10月。
[DNSOP6] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, April 2006.
[DNSOP6]デュラン、A.、Ihren、J.、およびP. Savola、RFC 4472 "IPv6のDNSで運用考慮事項と課題"、2006年4月。
[DNSV6R] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[DNSV6R]トムソン、S.、のHuitema、C.、Ksinant、V.、およびM. Souissi、RFC 3596、2003年10月 "DNSの拡張機能は、IPバージョン6をサポートします"。
[NIS] Kalusivalingam, V., "Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.
、RFC 3898、2004年10月[NIS] Kalusivalingam、V.、 "IPv6の動的ホスト構成プロトコル（DHCPv6）のためのネットワーク情報サービス（NIS）の設定オプション"。
[DHCPv4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[DHCPv4の] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[IPSEC] Eastlake 3rd, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[IPSEC]イーストレイク3日、D.、RFC 4305、2005年12月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）のための暗号アルゴリズム実装要件"。
[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[SEND] Arkko、J.、編、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[PRIVv6] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[PRIVv6] Narten氏、T.およびR. Draves、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[TSPB] Blanchet, M., and F. Parent, "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP", Work in Progress, August 2005.
[TSPB]ブランシェ、M.、およびF.親、 "トンネルセットアッププロトコルとIPv6のトンネルブローカー（TSP"、進歩、2005年8月の作業。
[V6SEC] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/Co-existence Security Considerations", Work in Progress, October 2006.
[V6SEC]デイヴィス、E.、クリシュナン、S.、およびP. Savola、 "IPv6移行/共存のセキュリティの考慮事項"、進歩、2006年10月に作業。
[NAP] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", Work in Progress, January 2007.
[NAP]ヴァン・デ・ヴェルデ、G.、ハイン、T.、Droms、R.、大工、B.、およびE.クライン、 "IPv6のローカルネットワークの保護"、進歩、2007年1月の作業。
[CAMP] Chown, T., "IPv6 Campus Transition Scenario Description and Analysis", Work in Progress, March 2007.
[CAMP]のchown、T.、 "IPv6のキャンパスの変遷シナリオの説明と分析"、進歩、2007年3月に作業。
[DHDS] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues", RFC 4477, May 2006.
[DHDS]のchown、T.、Venaas、S.、およびC. Strauf、 "動的ホスト構成プロトコル（DHCP）：IPv4とIPv6のデュアルスタックの問題"、RFC 4477、2006年5月。
[UNAD] Van de Velde, G., Popoviciu, C., and T. Chown, "IPv6 Unicast Address Assignment", Work in Progress, March 2007.
[UNAD]ヴァン・デ・ヴェルデ、G.、Popoviciu、C.、およびT. chownコマンドは、 "IPv6ユニキャストアドレスの割り当て"、進歩、2007年3月に作業します。
[VLAN] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks", RFC 4554, June 2006.
[VLAN]のchown、T.、 "企業ネットワーク内のIPv4-IPv6の共存のためのVLANの使用"、RFC 4554、2006年6月。
[V6DEF] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", Work in Progress, January 2006.
[V6DEF]ロイ、S.、デュラン、A.、およびJ. Paughは、 "IPv6の近隣探索は、リンク上の仮定は、有害と考えられ、" 進歩、2006年1月の作業。
[SOFTW] Dawkins, S., Ed., "Softwire Problem Statement", Work in Progress, March 2007.
[SOFTWARE]ドーキンス、VS.、エド。、 "ソフトウェアの問題に関する声明"、進歩、2007年3月に作業。
The authors would like to acknowledge contributions from the following: IETF v6ops Working Group members, Fred Baker, Pekka Savola, and Jordi Palet
IETF v6opsワーキンググループのメンバー、フレッド・ベイカー、ペッカSavola、およびジョルディPalet：著者は、次からの貢献に感謝します
Appendix A. Crisis Management Network Scenarios
付録A.危機管理ネットワークシナリオ
A.1. Introduction
A.1。前書き
This appendix first describes different scenarios for the introduction of IPv6 into a crisis management network for emergency services, defense, or security forces that are currently running IPv4 service. Then, the scenarios for introducing IPv6 are analyzed, and the relevance of already defined transition mechanisms are evaluated. Known challenges are also identified.
この付録では、まず、現在のIPv4サービスを実行している緊急サービス、防衛、または治安部隊のための危機管理ネットワークへのIPv6の導入のためのさまざまなシナリオについて説明します。次に、IPv6を導入するためのシナリオを解析し、既に定義された移行メカニズムの関連性が評価されます。既知の課題も同定されています。
When a crisis management enterprise deploys IPv6, its goal is to provide IPv6 connectivity on its institutional fixed networks and on the mobile wireless services that are deployed to a crisis area. The new IPv6 service must be added to an already existing IPv4 service, the introduction of IPv6 must not interrupt this IPv4 service, and the IPv6 services must be interoperable with existing IPv4 services.
危機管理企業がIPv6を展開すると、その目標は、その制度の固定ネットワーク上の危機エリアに展開されているモバイル無線サービスにIPv6接続を提供することです。新しいIPv6サービスは、IPv6の導入は、このIPv4サービスを中断してはならない、既存のIPv4サービスに追加する必要があり、およびIPv6サービスは、既存のIPv4サービスと相互運用可能でなければなりません。
Crisis management enterprises accessing IPv4 service across mobile ground networks, airborne networks, and satellites will find different ways to add IPv6 to this service based on their network architecture, funding, and institutional goals. This document discusses a small set of scenarios representing the architectures for IPv6 expected to be dominant in crisis management networks during the next decade. This document evaluates the relevance of the existing transition mechanisms in the context of these deployment scenarios, and points out the lack of essential functionality within these methods for a provider to support IPv6 services for these scenarios.
危機管理企業は、モバイル地上ネットワークを介して空気中のネットワークをIPv4サービスへのアクセス、衛星は彼らのネットワークアーキテクチャ、資金調達、および制度的目標に基づいて、このサービスにIPv6を追加するさまざまな方法を見つけるでしょう。このドキュメントでは、次の十年の間に危機管理ネットワークで支配的であることが予想IPv6のアーキテクチャを表すシナリオの小さなセットを説明します。この文書では、これらの展開シナリオのコンテキストで既存の移行メカニズムの妥当性を評価し、これらのシナリオのためのIPv6サービスをサポートするために、プロバイダのため、これらのメソッド内で必要不可欠な機能の欠如を指摘しています。
The document focuses on services that include both IPv6 and IPv4 and does cover issues surrounding accessing IPv4 services across IPv6- only networks. It is outside the scope of this document to describe detailed implementation plans for IPv6 in defense networks.
文書は、IPv6とIPv4の両方が含まれており、ネットワークだけIPv6-間でのIPv4サービスにアクセス取り巻くカバーの問題を行い、サービスに焦点を当てています。それは防衛ネットワークにおけるIPv6の詳細な実施計画を記述するために、このドキュメントの範囲外です。
A.2. Scenarios for IPv6 Deployment in Crisis Management Networks
A.2。危機管理ネットワークにおけるIPv6の展開のシナリオ
Scenario 1: Limited IPv6 Deployment Network
シナリオ1：リミテッドIPv6の展開のネットワーク
Sparse IPv6 dual-stack deployment in an existing IPv4 network infrastructure. Enterprise with an existing IPv4 network wants to deploy a set of particular IPv6 "applications" and have some ability to interoperate with other institutions that are using IPv6 services. The IPv6 deployment is limited to the minimum required to operate this set of applications.
既存のIPv4ネットワークインフラストラクチャにおけるスパースIPv6のデュアルスタック展開。既存のIPv4ネットワークを持つ企業は、特定のIPv6「アプリケーション」のセットを展開し、IPv6サービスを使用している他の機関と相互運用するためにいくつかの能力を持って望んでいます。 IPv6の展開は、アプリケーションのこのセットを動作させるために必要な最小限に制限されています。
Assumptions: IPv6 software/hardware components for the application are available, and platforms for the application are IPv6 capable.
仮定：アプリケーションのIPv6ソフトウェア/ハードウェア・コンポーネントが利用可能であり、アプリケーションのためのプラットフォームはIPv6対応です。
Requirements: Do not disrupt IPv4 infrastructure.
要件：IPv4インフラストラクチャを妨害しないでください。
Scenario 2: Dual-Stack Network
シナリオ2：デュアルスタックネットワーク
Wide-scale/total dual-stack deployment of IPv4 and IPv6 capable hosts and network infrastructure. Enterprise with an existing IPv4 network wants to deploy IPv6 in conjunction with their IPv4 network in order to take advantage of emerging IPv6 network-centric capabilities and to be interoperable with other agencies, international partners, and commercial enterprises that are deploying an IPv6 architecture.
大規模/ IPv4とIPv6対応ホストとネットワークインフラストラクチャの総デュアルスタック展開。既存のIPv4ネットワークを持つ企業は、新興のIPv6ネットワーク中心の機能を活用して、他の機関、国際的なパートナー、およびIPv6のアーキテクチャを展開している民間企業と相互運用可能にするために彼らのIPv4ネットワークと連携してIPv6を展開したいと考えています。
Assumptions: The IPv4 network infrastructure used has an equivalent capability in IPv6.
仮定：使用のIPv4ネットワークインフラストラクチャは、IPv6で同等の機能を備えています。
Requirements: Do not disrupt existing IPv4 network infrastructure with IPv6. IPv6 should be equivalent or "better" than the network infrastructure in IPv4. It may not be feasible to deploy IPv6 on all parts of the network immediately. Dual-stacked defense enterprise network must be interoperable with both IPv4 and IPv6 networks and applications.
要件：IPv6で既存のIPv4ネットワークインフラストラクチャを中断しないでください。 IPv6は、IPv4のネットワークインフラストラクチャよりも同等か、「より良い」でなければなりません。すぐにネットワークのすべての部分でIPv6を導入することは実現可能ではないかもしれません。デュアル積層防御企業ネットワークは、IPv4とIPv6の両方のネットワークとアプリケーションとの相互運用が可能でなければなりません。
Scenario 3: IPv6-Dominant Network
シナリオ3：IPv6のドミナントネットワーク
Enterprise has some limited IPv4-capable/only nodes/applications needing to communicate over the IPv6 infrastructure. Crisis management enterprise re-structuring an existing network, decides to pursue aggressive IPv6 transition as an enabler for network-centric services and wants to run some native IPv6-only networks to eliminate cost/complexity of supporting a dual stack. Some legacy IPv4 capable nodes/applications within the enterprise will have slow technical refresh/replacement paths and will need to communicate over the IPv6 dominant infrastructure for years until they are replaced. The IPv6-dominant enterprise network will need to be interoperable with its own legacy networks, commercial networks, and the legacy networks of similar organizations that will remain IPv4-dominant during a long transition period. Reserve units, contractors, other agencies, and international partners may need IPv4 service across this enterprise's IPv6-dominant backbone.
企業は、IPv6インフラストラクチャを介して通信する必要がいくつかの限定されたIPv4対応/専用ノード/アプリケーションを有しています。既存のネットワークを再構築する危機管理企業は、ネットワーク中心のサービスのためのイネーブラーとしての積極的なIPv6への移行を追求することを決定し、デュアルスタックをサポートするコスト/複雑さを排除するために、いくつかのネイティブIPv6のみのネットワークを実行したいと考えています。企業内の一部のレガシーのIPv4対応ノード/アプリケーションが遅く、技術リフレッシュ/代替パスを持つことになり、それらが交換されるまで年間、IPv6の支配的なインフラ上で通信する必要があります。 IPv6の優位企業ネットワークは、独自のレガシーネットワーク、商用ネットワーク、および長い移行期間中のIPv4-支配的なままになります同様の組織のレガシーネットワークと相互運用可能にする必要があります。予約ユニット、請負業者、他の機関、および国際的なパートナーは、この企業のIPv6-支配的なバックボーン間でIPv4サービスが必要な場合があります。
Assumptions: Required IPv6 network infrastructure is available, or available over some defined timeline, supporting the aggressive transition plan.
仮定：必要なIPv6ネットワークインフラストラクチャは、いくつかの定義されたタイムライン上で利用可能な、または利用可能である積極的な移行計画を支援します。
Requirements: Reduce operation and maintenance requirements and increase net-centricity through aggressive IPv6 transition. Interoperation and coexistence with legacy IPv4 networks and applications is required. Legacy IPv4 nodes/applications/networks will need to be able to operate across the IPv6 backbone and need to be able to interoperate with the IPv6-dominant network's nodes/applications.
要件：運転・保守要件を削減し、積極的なIPv6への移行を通じてネット中心主義を高めます。従来のIPv4ネットワークとアプリケーションとの相互運用および共存が必要です。レガシーIPv4ノード/アプリケーション/ネットワークは、IPv6バックボーンにわたって動作できるようにする必要がありますし、IPv6のドミナントネットワークのノード/アプリケーションと相互運用できるようにする必要があります。
A.3. Description of a Generic Crisis Management Network
A.3。一般的な危機管理ネットワークの説明
A generic network topology for crisis management reflects the various ways a crisis management network can connect customers through their network infrastructure. Because the institution's existing wired and fixed-site wireless infrastructure can be destroyed or unavailable in a crisis, the crisis management network must be able to deploy its own mobile wireless network or connect through external wired and wireless networks provided by ISPs or partner organizations. This infrastructure lets us divide the basic areas for IPv4/IPv6 interoperability into three main areas: the customer applications, the local network, and the network backbone.
危機管理のための一般的なネットワークトポロジは、危機管理ネットワークは、ネットワークインフラストラクチャを通じて顧客を接続することができますさまざまな方法を反映しています。機関の既存の有線および固定サイト無線インフラが破壊されたり、危機にはないことができるため、危機管理ネットワークは、独自のモバイル無線ネットワークを展開するか、外部の有線およびISPやパートナー組織が提供する無線ネットワークを介して接続することができなければなりません。顧客のアプリケーション、ローカルネットワーク、およびネットワーク・バックボーン：このインフラストラクチャは、私たちは3つの主要分野へのIPv4 / IPv6の相互運用性のための基本的な領域を分割することができます。
The basic components in a crisis management network are depicted in Figure 1.
危機管理ネットワーク内の基本的な構成要素は、図1に示されています。
------------ ---------- ---- Wired Connection
| Network and| | | .... Wireless Connection
| Service |--| Backbone |
| Operation | | |
------------ ----------
/ | ---------------------
/ : _|Connection to |
/ : |Commercial Internet |
/ : ---------------------
Network Backbone
-------------- /------|-------------|--------------------
---------- / ---------- ----------
| Home |/ | Wireless | |External |.............
| Base | | Mobile | |Untrusted |+--------- :
| Network | | Network | |Network | | :
---------- ---------- ---------- | :
| : : | :
Local Network
-----:------------:-----------------------------------
Customer Applications
| : : | :
+--------+ +--------+ +--------+ | :
| | | | | | | :
|Customer| |Customer| |Customer|+----------- :
| | | | | |..............
+--------+ +--------+ +--------+
Figure 1: Crisis Management Network Topology.
図1：危機管理ネットワークトポロジ。
A.4. Stages of IPv6 Deployment
A.4。 IPv6の展開のステージ
The stages are derived from the generic description of scenarios for crisis management networks in Section 2. Combinations of different building blocks that constitute a crisis network environment lead to a number of scenarios from which the network engineers can choose. The scenarios most relevant to this document are those that maximize the network's ability to offer IPv6 to its customers in the most efficient and feasible way. In the first three stages, the goal is to offer both IPv4 and IPv6 to the customer, and it is assumed that in the distant future, all IPv4 services will be eventually switched to IPv6. This document will cover engineering the first four stages.
ステージは、セクションネットワークエンジニアが選択できるシナリオの数に危機ネットワーク環境のリードを構成するさまざまなビルディング・ブロックの2の組み合わせにおける危機管理ネットワークのためのシナリオの一般的な記述に由来しています。この文書に最も関連性の高いシナリオは、最も効率的かつ実行可能な方法で顧客にIPv6を提供するネットワークの能力を最大化するものです。最初の三つの段階では、目標は、顧客にIPv4とIPv6の両方を提供することであり、遠い将来では、すべてのIPv4サービスは、最終的にIPv6への切り替えすることを想定しています。この文書では、最初の4つの段階をエンジニアリングカバーします。
The four most probable stages are:
4つの最も可能性の高いステージは、次のとおりです。
o Stage 1 Limited Launch
o Stage 2 Dual-Stack Dominance
o Stage 3 IPv6 Dominance
o Stage 4 IPv6 Transition Complete
Generally, a crisis management network is able to entirely upgrade a current IPv4 network to provide IPv6 services via a dual-stack network in Stage 2 and then slowly progress to Stages 3 and 4 as indicated in Figure 2. During Stage 2, when most applications are IPv6 dominant, operational and maintenance costs can be reduced on some networks by moving to Stage 3 and running backbone networks entirely on IPv6, while adding IPv4 backwards compatibility via v4 in v6 tunneling or translation mechanisms to the existing configuration from Stage 2. When designing a new network, if a new IPv6-only service is required, it can be implemented at a lower cost by jumping directly to Stage 3/4 if there are only limited or no legacy concerns.
一般的に、危機管理ネットワークは完全にステージ2でデュアルスタックネットワークを介してIPv6サービスを提供するために、現在のIPv4ネットワークをアップグレードすることができ、ステージ2、ほとんどのアプリケーションの間に、図2に示すように、ゆっくりとステージ3と4に進みます設計するときはステージ2からの既存の構成に後方V6トンネリングや変換メカニズムでV4を経由して互換性をIPv4のを追加しながらIPv6の、支配的な運用および保守コストは、ステージ3に移動するとIPv6に完全にバックボーンネットワークを実行して、いくつかのネットワークに低減することができます新しいIPv6のみのサービスが必要な場合にのみ限定された、あるいは全くレガシーの懸念がある場合は、新しいネットワークは、それがステージ3/4に直接ジャンプすることにより低コストで実現することができます。
Stage 1: Limited Launch
ステージ1：リミテッド起動
The first stage begins with an IPv4-only network and IPv4 customers. This is the most common case today and the natural starting point for the introduction of IPv6. During this stage, the enterprise begins to connect individual IPv6 applications run on dual-stacked hosts through host-based tunneling using Tunnel Broker, ISATAP, or Teredo. Some early adopter networks are created for pilot studies and networked together through configured tunnels and 6to4.
第一段階は、IPv4のみのネットワークとIPv4の顧客から始まります。これは、最も一般的なケース今日とIPv6の導入のための自然な出発点です。この段階では、企業は、トンネルブローカー、ISATAP、またはのTeredoを使用して、ホストベースのトンネリングによるデュアルスタックホスト上で実行する個々のIPv6アプリケーションを接続するために開始します。いくつかの早期導入ネットワークは、パイロット研究のために作成され、設定トンネルと6to4を介して一緒にネットワーク化されています。
The immediate first step consists of obtaining a prefix allocation (typically a /32) from the appropriate RIR (e.g., AfriNIC, APNIC, ARIN, LACNIC, RIPE) according to allocation procedures.
即時の最初のステップは、割り当て手順に従って、適切なRIR（例えば、AfriNIC、APNIC、ARIN、LACNIC、RIPE）からプレフィックス割当（通常/ 32）を得ることから成ります。
The crisis management enterprise will also need to establish IPv6 connectivity between its home base networks and mobile wireless networks over its backbone. It will need to negotiate IPv6 service with its service providers and with peer organizations; it is of utmost importance to require IPv6 capability or an upgrade plan when negotiating purchases of network applications and infrastructure. In the short term, network connections, especially legacy wireless networks that cannot provide IPv6 services, can provide IPv6 services through the use of tunnels. However, the longer-term goal must be requiring and obtaining IPv6 native connectivity from the transit networks. Otherwise, the quality of IPv6 connectivity will likely be poor and the transition to Stage 2 will be delayed.
危機管理企業も、そのホームベースのネットワークとそのバックボーン上でモバイルワイヤレスネットワーク間のIPv6接続を確立する必要があります。それは、そのサービスプロバイダとし、ピア組織とIPv6サービスを交渉する必要があります。それは、ネットワークアプリケーションとインフラストラクチャの購入を交渉する際のIPv6機能やアップグレード計画を必要とすることが最も重要です。短期的には、ネットワーク接続は、特にレガシーIPv6サービスを提供できないワイヤレスネットワークは、トンネルを使用してIPv6サービスを提供することができます。しかし、長期的な目標は、必要とトランジットネットワークからのIPv6ネイティブ接続を取得する必要があります。それ以外の場合は、IPv6接続の品質はそう悪くなるとステージ2への移行が延期されます。
Stage 2: Dual-Stack Dominance
ステージ2：デュアルスタック支配
Stage 2 occurs when most applications, local networks, and network backbones become dual-stacked so that native IPv6 connections are enabled. At this point there is a mix of IPv4 and IPv6 applications and services in use across the enterprise. The enterprise may be made IPv6-capable through either software upgrades, hardware upgrades, or a combination of both. Generally IPv6 is added during normal technical refresh as the enterprise buys new equipment that is IPv6 ready.
ステージ2は、ネイティブIPv6接続が有効になっているように、ほとんどのアプリケーションで、ローカルネットワーク、およびネットワーク・バックボーンは、デュアルスタックになったときに発生します。この時点で、企業全体の使用でIPv4とIPv6のアプリケーションとサービスのミックスがあります。企業は、ソフトウェアのアップグレード、ハードウェアのアップグレード、または両方の組み合わせのいずれかを介してIPv6対応してもよいです。企業がIPv6の準備ができている新しい機器を購入すると一般的にIPv6は、通常の技術的なリフレッシュ中に追加されます。
Specialty legacy applications and wireless/satellite networks may be especially slow to transition to IPv6 capability due to upgrade costs, so plans must be made for backwards compatibility for these systems. Since some new IPv6 services cannot be provided through IPv4, and some legacy network connections may not yet be upgraded, tunneling mechanisms have to be provided on the backbone to provide IPv6 connectivity through to customer IPv6 applications still relying on legacy IPv4-only networks. The tunnels may provide host-based tunneling for individual customers or site-to-site tunnels to connect small IPv6 domains through IPv4-only networks. If any new applications are IPv6-only rather than dual-stacked, and need to interact with IPv4-only legacy applications, translators will be used as a transition mechanism of last resort during this stage.
計画は、これらのシステムのための後方互換性のために作られなければならないので、専門のレガシーアプリケーションおよび無線/衛星ネットワークは、コストをアップグレードするため、IPv6の機能に移行するのが特に遅くなることがあります。いくつかの新しいIPv6のサービスはIPv4のを介して提供することができず、一部のレガシーネットワーク接続がまだアップグレードされない場合がありますので、トンネリングメカニズムは、まだ従来のIPv4のみのネットワークに依存する顧客のIPv6アプリケーションに至るまでのIPv6接続を提供するために、バックボーンに提供されなければなりません。トンネルは、IPv4のみのネットワークを通じて、小さなIPv6のドメインを接続するには、個々の顧客またはサイトツーサイトトンネルのホストベースのトンネリングを提供することができます。いずれかの新しいアプリケーションがIPv6のみではなく、デュアルスタックである、とIPv4のみのレガシーアプリケーションとやり取りする必要がある場合、翻訳者はこの段階で最後の遷移メカニズムとして使用されます。
Stage 3: IPv6 Dominance
ステージ3：IPv6の支配
Applications are deployed specifically to use IPv6 as benefit; thus, network backbone and nodes use IPv6 and not IPv4, except where IPv4 is legacy.
アプリケーションは、特典としてIPv6を使用するために特別に配備されています。このように、ネットワークバックボーンノードは、IPv4の遺産である場合を除いて、IPv6とIPv4のないを使用しています。
Authors' Addresses
著者のアドレス
Jim Bound HP 110 Spitbrook Road Nashua, NH 03062 USA Phone: 603.465.3130 EMail: jim.bound@hp.com
ジムはHPをバウンド110 Spitbrook道路ナシュア、ニューハンプシャー03062 USA電話：603.465.3130 Eメール：jim.bound@hp.com
Yanick Pouffary HP Competency Center 950, Route des Colles, BP027, 06901 Sophia Antipolis CEDEX FRANCE Phone: + 33492956285 EMail: Yanick.pouffary@hp.com
Yanick Pouffary HPコンピテンシー・センター950、ルート・デ・コーレス、BP027、06901ソフィアアンティポリスセデックスFRANCE電話：+ 33492956285 Eメール：Yanick.pouffary@hp.com
Tim Chown School of Electronics and Computer Science University of Southampton Southampton SO17 1BJ United Kingdom EMail: tjc@ecs.soton.ac.uk
電子のティムのchown学校とサウサンプトンサウサンプトンSO17 1BJイギリスのコンピュータサイエンス大学Eメール：tjc@ecs.soton.ac.uk
David Green Command Information 13655 Dulles Technology Drive Suite 500 Herndon, VA 20171 USA Phone: 703.561.5937 EMail: green@commandinformation.com
デビッド・グリーン・コマンド情報13655ダレステクノロジードライブスイート500ハーンドン、VA 20171 USA電話：703.561.5937 Eメール：green@commandinformation.com
Steve Klynsma The MITRE Corporation 7515 Colshire Drive McLean, VA 22102-5708 USA Phone: 703-883-6469 EMail: sklynsma@mitre.org
スティーブKlynsmaザ・MITRE社7515 Colshireドライブマクリーン、バージニア州22102から5708 USA電話：703-883-6469 Eメール：sklynsma@mitre.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。