[要約] 要約： RFC 4852は、IPv6エンタープライズネットワークの分析に焦点を当てたIPレイヤー3の技術に関する情報を提供しています。目的： このRFCの目的は、IPv6ネットワークの設計、トラブルシューティング、パフォーマンスの最適化に役立つ情報を提供することです。
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
IPv6エンタープライズネットワーク分析 - IPレイヤー3フォーカス
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）The IETF Trust（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つ以上のプロバイダーへの1つ以上のルーター接続を持ち、ネットワーク運用エンティティによって管理されていると特徴付けられます。分析では、エンタープライズシナリオの以前のドキュメントから拡張されたトランジション表記ネットワークと要件のベースセットに焦点を当てています。エンタープライズ内のデュアル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.
このドキュメントは、IPレイヤー3に焦点を当てたエンタープライズネットワークのIPv6への移行を分析します。これらのネットワークは、複数の内部リンク、1つ以上のプロバイダーへの1つ以上のルーター接続があり、ネットワーク運用エンティティによって管理されていると特徴付けられます。分析では、エンタープライズシナリオの以前のドキュメントから拡張されたトランジション表記ネットワークと要件のベースセットに焦点を当てています。エンタープライズ内のデュアル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がエンタープライズネットワークの一部または内部で支配的であると判断された場合の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.
- Multihoming-アプリケーショントランジション/移植（[アプリ]を参照）。-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展開分析作業と同じ方法でIPレイヤー3展開に焦点を当てています[uman] [ISPA] [3GPA]。このドキュメントは、アドレス管理や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プロバイダーに）獲得している個々のユーザーのケースについては説明していません。分析の多くはワイヤレスネットワークに適用できますが、このドキュメントに含まれていないワイヤレスネットワークには追加の考慮事項があります。
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].
このドキュメントは、Crisis Management Enterprise Networkを描いた読者に付録Aを提供し、セクション3、4、5、6、および7で分析されたすべてのプロパティを必要とするエンタープライズネットワークの例を実証します。さらに、このドキュメントの読者はこのドキュメントの読者をお勧めします。また、別のユースケースドキュメントを読んで、キャンパスネットワーク[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つ以上のプロバイダーへの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 -Capable -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.
Dual -IP- IPv4とIPv6の両方をサポートするネットワークまたはノード。
IP-capability - The ability to support IPv6 only, IPv4 only, or Dual-IP Layer
IP-Capability-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 -Dominant -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つの異なるグローバル場所で、エンタープライズ所有のイントラネットに接続されたホストで構成されています。エンタープライズは、独自のイントラネットワークを所有、運営、維持していますが、インターネットサービスを提供する外部プロバイダー組織に依存しています。ローカルおよび宛先の両方のイントラネットワークは、同じ企業内の異なる組織によって運営されているため、移行期間の特定の時期に他のイントラネットワークとは異なる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のみのISPSまたは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つのシナリオのそれぞれで、パケットは少なくとも1つの互換性のないネットワークコンポーネントを通過する必要があります。たとえば、シナリオ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に移行したという異常な状況を表していますが、（シナリオ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.
シナリオE-Jは、企業がIPv4とIPv6ベースの両方のインスタンス化を、相互運用し続けなければならない同じアプリケーションのインスタンス化を備えている移行状況を表しています。さらに、これらのシナリオは、企業がすべてのオーガニックおよび/またはサービスプロバイダーネットワークで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]テキストから駆動されます。この分析はさらに、上記のセクション3のシナリオAに対応しています（ただし、シナリオAは、エンタープライズが1つのネットワークセグメントがまだデュアルIPへの移行に遅れていることを示しています）。
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）。また、地域のインターネットレジストリ（RIRS）によって割り当てられたアドレススペースからエンタープライズのアップストリームプロバイダーによって割り当てられた集約可能なグローバル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対応ルーティングインフラストラクチャの選択です。撮影されたパスは、Enterpriseが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ルーティングインフラストラクチャを展開するという2つの基本的な選択に直面しています。
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エッジルーターが存在する状況を考えてみましょうが、他の人、おそらくエンタープライズバックボーン自体はIPv6対応ではありません（表1のシナリオB）。[BCNF]に記載されているように、トンネルはエンタープライズ上のデュアルIP対応ルーター間に確立され、したがって、既存の非IPv6対応ルーターとプラットフォームを「バイパス」します。
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.
IPv6を既存のIPv4エンタープライズサブネットに配布するために、[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または両方の組み合わせのいずれかのIPv6サービスを展開したと仮定します（表1のシナリオB）。この場合、プロバイダーはまた、IPv6サブスクライバーをサポートするために1つ以上の遷移メカニズムを展開する可能性があります。明らかに、企業はプロバイダーから提供される移行サービスを利用することを決定することができました。ただし、これは通常、ネットワーク内の個々のノードが独自のIPv6-in-IPV4トンネルを必要とすることを意味します。すべてのIPv6トラフィックは、エンタープライズのIPv4インフラストラクチャによってプロバイダーが提供されるトンネルエンドポイントに転送する必要があるため、最終結果はやや非効率的なIPV6 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.
あるいは、企業は独自の遷移メカニズムノードを展開し、上流のプロバイダーに接続するBorder Routerに隣接する可能性のある遷移メカニズムノードを展開することを決定できます。この場合、このトンネルエンドポイントを使用した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対応である場合でも、エンタープライズネットワーク内のネットワークまたは特定のサイトがIPv6ルーティングのみを使用してIPv4パケットとIPv6パケットをネットワーク上に転送することです。IPv4ルーティングは、EDGE 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-CominantネットワークのIPv6対応ノードがIPv4ノードと通信する必要がある場合、IPv6ノードはデュアルIP実装を使用してIPv6 [V6TUN]のIPv4パケットをトンネルします。IPv6-dominantネットワーク内のエッジルーターは、IPv4パケットを脱カプセル化し、ネットワーク上のIPv4ノードのパスにルーティングします。これにより、デュアルIPレイヤーノードは、IPv6支配ネットワーク内のレガシーIPv4ノードと通信できます。
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.
表1のシナリオEとFは、IPv6を支配する展開戦略が導入される可能性のある追加のケースを示しています。シナリオ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エンドホストと相互操作するために）、ネットワーク上のトンネルエンドポイントを見つけなければなりません。宛先デュアル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プロバイダーになります。エンタープライズは、ネイティブIPv6の上流接続性を使用するか、その不在下で、上流プロバイダーに手動で構成されたトンネル[BCNF]を使用することが予想されます。
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]で説明されているように、企業はプロバイダーから少なくともA /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ノードのA /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を使用すると、リンクには実際に任意の数のノードがあり、関連する変更要件でプレフィックス割り当てを調整することなくリンクの成長を可能にします。初期サイトの割り当てのサイズ（現在A /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サイズのプレフィックスを割り当て、サイト内の成長の範囲を持つ方法でそれを行う必要があります。このサイトは、最初のIPv6プレフィックス割り当て（現在A /48に推奨されている）にはそのような成長の余地が含まれる可能性が高いため、サイトのトポロジー的成長のためのスペースを留保する計画を利用する必要があります。「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.
エンタープライズサイトは、AAAA形式[DNSV6R]を使用してIPv6 DNSレコードを提供し、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].
内部ルーティングの場合、適切なインテリアルーティングプロトコルが展開される場合があります。使用できるIPv6ルーティングプロトコルは次のとおりです。BGP4[BGP4]、IS-IS [ISIS]、OSPFV3 [OSPF]、およびRIPNG [RIPNG]。
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エンタープライズでは、Stateless Address Autoconfiguration [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.
セキュアなオートコンチュレーションのサポートが必要な場合は、送信[送信]を使用できます。読者は、送信ドキュメント内に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サーバーなど）を取得することを希望するステートレス構成ノードには、Stateful 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.
IPv6をデュアルIPネットワーク内に展開する場合、IPv4対応ノードの場合と同様に、IPv6対応ノードのサイトセキュリティポリシーを実装する必要があります。たとえば、Border Firewallは、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、Stateless Autoconfiguration（および送信）、IPv6プライバシー拡張、エンドツーエンドのIPSECECEなど、サイトに展開されるIPv6固有の機能に照らして、セキュリティポリシーを確認する必要があります。。さらに、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を使用したネットワークアーキテクチャ保護（NAP）の概要は、NATを必要とせずに同じまたはそれ以上の利点を[NAP]で見つけることができます。これは、IPv4 NATを使用した知覚されたセキュリティをIPv6で達成および超える方法、つまりIPv6テクノロジーを使用してIPv4 NATの市場認識利点を提供する方法を説明しています。
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.
IPv6トランスポートがすべてのアプリケーションで好まれていなくても、サイト内でのIPv6の使用をサポートしたいサイトによってデュアルIP展開が行われます。すべてのサイトインフラストラクチャ（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のシナリオの1つにマッピングすることは、互換性のないネットワークインターフェイスであるエンタープライズネットワーク内の重要なタッチポイントを認識するよりもはるかに重要ではありません。エンタープライズがサービスとしてエンタープライズによって提供されている場合を除き、メカニズムを考慮しなければならないのはこれらのタッチポイントにあります。
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.
2番目の共通テーマ（表1のシナリオB-Dに描かれている）では、エンタープライズは互換性のあるホストで構成され、その間に1つ以上の互換性のないネットワークタッチポイントがあります。セクション4.2.2.1で説明されているように、トンネリングを使用して、互換性のないネットワークセグメントを「バイパス」できます。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エンドサービスにトンネルするために、サイト内自動トンネルアドレス指定プロトコル（ISATAP）[ISTP]またはTeredo [TRDO]が含まれます。ISATAP [ISTP]を使用して、IPv4でのIPv6の自動トンネリングを使用して、分離されたIPv4ネットワーク上のノードからエンドノードIPv6接続を提供できます。Teredo [TRDO]は、エンタープライズネットワークがNATの背後にあるときに使用できます。
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ドミナントリンクまたはエンタープライズイントラネットを介してIPv6 [V6TUN]内のIPv4 [V6TUN]内の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.
互換性のないネットワークタッチポイントを認識しているため、アプリケーションの互換性を特定することもアーキテクトの義務です。特に大企業の移行期間中、ある場所でホストされているアプリケーションが他の場所でピア（またはサーバー）のIPv6互換性を導く（または遅延）する可能性があることが予想されます。
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.
これにより、3番目のテーマ（シナリオEおよびGで表される）につながります。これは、均質なネットワーク全体で通信する互換性のないアプリケーションです。翻訳は明らかなソリューションですが、ネットワークエッジにあるレガシーデバイスを除いて推奨されません。よりスケーラブルなソリューションは、互換性のないホスト間でアプリケーションレイヤーゲートウェイ（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の4番目の共通のテーマを表しています（特にシナリオF、H、I、Jで描かれています）。これらの状況でIPの相互運用性を維持するには、追加の計画が必要であり、多様な遷移メカニズムの複数またはネストされた使用を必要とする場合があります。たとえば、アプリケーションサーバーと協力したアルグは、互換性のないネットワークセグメントを介して同時にトンネル化される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展開のセキュリティ上の考慮事項は、上記のセクション7.4.5で説明されています。ここでは、概要ドキュメント[V6SEC] [NAP]への外部参照も含まれています。
[CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[Conf] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、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.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6（DHCPV6）の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[6TO4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[6to4] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[BSCN] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[BSCN] Bound、J.、ed。、「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：ネットワークアドレス翻訳（NAT）を介してUDPを介したIPv6のトンネル」、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] Templin、F.、Gleeson、T.、Talwar、M。、およびD. Thaler、「敷地内自動トンネルアドレス指定プロトコル（ISATAP）」、RFC 4214、2005年10月。
[V6TUN] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[V6Tun] Conta、A。およびS. Deering、「IPv6仕様の一般的なパケットトンネル」、RFC 2473、1998年12月。
[TBRK] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[TBRK] Durand、A.、Fasano、P.、Guardini、I。、およびD. Lento、「IPv6 Tunnel Broker」、RFC 3053、2001年1月。
[ALLOC] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[Alloc] IABおよびIESG、「IPv6に関する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、「ネットワークアドレス変換 - プロトコル翻訳（NAT -PT）」、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. van der Pol、「管理されていないネットワークの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.
[ISPA] Lind、M.、Ksinant、V.、Park、S.、Baudot、A。、およびP. Savola、「ISPネットワークにIPv6を導入するためのシナリオと分析」、RFC 4029、2005年3月。
[3GPA] Wiljakka, J., Ed., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005.
[3GPA] Wiljakka、J.、ed。、「第3世代パートナーシッププロジェクト（3GPP）ネットワークにおけるIPv6トランジションに関する分析」、RFC 4215、2005年10月。
[OSPF] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[OSPF] Coltun、R.、Ferguson、D。、およびJ. Moy、「OSPF for IPv6」、RFC 2740、1999年12月。
[BGP4] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[BGP4] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、2007年1月。
[ISIS] Oran, D., Ed., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142, February 1990.
[ISIS] Oran、D.、ed。、「OSI IS-IS-IS Domain Routing Protocol」、RFC 1142、1990年2月。
[RIPng] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RIPNG] Malkin、G。およびR. Minnear、「RIPNG for IPv6」、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] Shin、M-K。、Ed。、Hong、Y-G。、Hagino、J.、Savola、P。、およびE. Castro、「IPv6 Transitionのアプリケーションの側面」、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] Baker、F.、Lear、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. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[ULA] Hinden、R。およびB. Haberman、「ユニークなローカル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] Durand、A.、Ihren、J。、およびP. Savola、「IPv6 DNSに関する運用上の考慮事項と問題」、RFC 4472、2006年4月。
[DNSV6R] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[DNSV6R] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「DNS拡張機能IPバージョン6」、RFC 3596、2003年10月。
[NIS] Kalusivalingam, V., "Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.
[NIS] Kalusivalingam、V。、「IPv6（DHCPV6）の動的ホスト構成プロトコルのネットワーク情報サービス（NIS）構成オプション」、RFC 3898、2004年10月。
[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] EastLake 3rd、D。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件」、RFC 4305、2005年12月。
[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[送信] Arkko、J.、ed。、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（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のステートレスアドレスAutoconfigurationのプライバシー拡張」、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] Blanchet、M。、およびF. Parent、「Tunnel Setup Protocolを使用したIPv6トンネルブローカー」（TSP」、2005年8月、Work in Progress。
[V6SEC] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/Co-existence Security Considerations", Work in Progress, October 2006.
[V6Sec] Davies、E.、Krishnan、S。、およびP. Savola、「IPv6 Transition/Co-Existence Security Smissations」、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] van de Velde、G.、Hain、T.、Droms、R.、Carpenter、B。、およびE. Klein、「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] Van de Velde、G.、Popoviciu、C。、およびT. Chown、「IPv6 Unicastアドレスの割り当て」、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] Roy、S.、Durand、A。、およびJ. Paugh、「IPv6 Neighbor Discovery On-Link Assuptionが有害と見なされる」、2006年1月の作業。
[SOFTW] Dawkins, S., Ed., "Softwire Problem Statement", Work in Progress, March 2007.
[Softw] Dawkins、S.、ed。、「Softwire Problem Statement」、2007年3月の作業。
The authors would like to acknowledge contributions from the following: IETF v6ops Working Group members, Fred Baker, Pekka Savola, and Jordi Palet
著者は、以下からの貢献を認めたいと思います。IETFV6OPSワーキンググループメンバー、フレッドベイカー、ペッカサボラ、ジョルディパレット
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.
この付録では、最初にIPv6が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.
Crisis Management EnterpriseがIPv6を展開する場合、その目標は、IPV6接続を制度的な固定ネットワークと、危機エリアに展開されているモバイルワイヤレスサービスに提供することです。新しいIPv6サービスは、既存のIPv4サービスに追加する必要があります。IPv6の導入はこの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を追加するさまざまな方法を見つけます。このドキュメントでは、今後10年間に危機管理ネットワークで支配的であると予想される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の詳細な実装計画を説明するのは、このドキュメントの範囲外です。
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ネットワークを展開し、新たなIPv6ネットワーク中心の機能を利用し、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.
Enterpriseには、IPv6インフラストラクチャを介して通信する必要があるIPv4対応/唯一のノード/アプリケーションが限られています。Crisis Management Enterpriseは既存のネットワークを再構築し、ネットワーク中心のサービスのイネーブラーとして積極的な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トランジションを通じて、操作とメンテナンスの要件を削減し、ネット中心性を向上させます。Legacy IPv4ネットワークとアプリケーションとの相互操作と共存が必要です。LEGACY IPv4ノード/アプリケーション/ネットワークは、IPv6バックボーン全体で動作できる必要があり、IPv6を支配するネットワークのノード/アプリケーションと相互運用できる必要があります。
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またはパートナー組織が提供する外部有線およびワイヤレスネットワークを介して独自のモバイルワイヤレスネットワークを展開するか、接続することができなければなりません。このインフラストラクチャにより、IPv4/IPv6の相互運用性の基本領域を、顧客アプリケーション、ローカルネットワーク、ネットワークバックボーンの3つの主要な領域に分割できます。
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：危機管理ネットワークトポロジ。
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を顧客に提供するネットワークの機能を最大化するシナリオです。最初の3つの段階では、目標は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
o ステージ1リミテッドローンチoステージ2デュアルスタックドミナンスoステージ3 IPv6ドミナンスoステージ4 IPv6トランジション完了
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.
一般的に、Crisis Management Networkは、現在のIPv4ネットワークを完全にアップグレードして、ステージ2のデュアルスタックネットワークを介してIPv6サービスを提供し、図2に示すようにステージ3と4にゆっくりと進行することができます。IPv6は支配的であるため、ステージ3に移動し、IPv6でバックボーンネットワークを完全に実行し、V6トンネリングまたは翻訳メカニズムを介して既存の構成にV4を介してIPv4逆方向の互換性をステージ2に追加することにより、一部のネットワークで運用コストを削減できます。ステージ2から既存の構成新しいネットワークは、新しい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（例えば、アフリニック、apnic、arin、lacnic、熟した）からプレフィックス割り当て（通常はa /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.
また、Crisis Management Enterpriseは、ホームベースネットワークとバックボーン上のモバイルワイヤレスネットワーク間の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は、Enterpriseが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を介して提供できず、一部のレガシーネットワーク接続はまだアップグレードされていない可能性があるため、Legacy 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がレガシーである場合を除き、IPv4ではなくIPv6を使用します。
Authors' Addresses
著者のアドレス
Jim Bound HP 110 Spitbrook Road Nashua, NH 03062 USA Phone: 603.465.3130 EMail: jim.bound@hp.com
ジムバウンドHP 110 Spitbrook Road Nashua、NH 03062 USA電話：603.465.330メール：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ソフィアアンティポリスセデックスフランス電話：33492956285メール：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
サウサンプトンサウサンプトンのティムチャウンスクールサウサンプトンSO17 1BJイギリスの電子メール：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
David Green Command Information 13655 Dulles Technology Drive Drive Suite 500 Herndon、VA 20171 USA電話：703.561.5937メール：green@commandinformation.com
Steve Klynsma The MITRE Corporation 7515 Colshire Drive McLean, VA 22102-5708 USA Phone: 703-883-6469 EMail: sklynsma@mitre.org
Steve Klynsma The Miter Corporation 7515 Colshire Drive McLean、VA 22102-5708 USA電話：703-883-6469メール：sklynsma@mitre.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。