RFC4852 日本語訳
4852 IPv6 Enterprise Network Analysis - IP Layer 3 Focus. J. Bound, Y.Pouffary, S. Klynsma, T. Chown, D. Green. April 2007. (Format: TXT=76199 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
ネットワークワーキンググループJ.はコメントを求める要求を縛りました: 4852年のY.Pouffaryカテゴリ: 情報のサウサンプトンD.大学緑色のヒューレット・パッカードのT.Chownコマンド情報S.Klynsma斜め継ぎ2007年4月
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).
IETFが信じる著作権(C)(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 Layer3に焦点を合わせる企業網でIPv6への変遷を分析します。 複数の内部のリンクと1つ以上のルータ接続が1Providersまであることとしてネットワーク操作実体によって管理されることとしてこれらのネットワークは特徴付けられます。 分析は企業シナリオで1人の基底集合の変遷の記号法のネットワークと前のドキュメントから広げられた要件に焦点を合わせます。 企業にIPv6への変遷に必要である集中している変遷分析のときに議論を提供します、企業の中でDual-IP層(IPv4とIPv6)のネットワークとノードが環境であると仮定して。 そして、1セットの変遷メカニズムはそれぞれの記号法のネットワークのために推薦されます。
Bound, et al. Informational [Page 1] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [1ページ]情報のRFC4852IPv6企業網分析2007年4月
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
1. 序論…3 2. 用語…5 3. 変遷のためのエンタープライズマトリクス解析…5 4. 広いスケールデュアルスタック展開分析…10 4.1. デュアルスタック展開を上演します…10 4.2. 二元的なIP展開のためのルート設定能力分析…11 4.2.1. IPv6ルート設定能力…11 4.2.2. IPv6ルート設定非能力…11 4.2.2.1. IPv4インフラストラクチャの上でIPv6にトンネルを堀ってください。12 4.2.2.2. 平行なIPv6インフラストラクチャを配布してください…12 4.3. エンタープライズへのリモートIPv6アクセス…12 4.4. 他の問題…13 5. まばらなデュアルスタック展開分析…13 5.1. 外部のトンネル終点に対する内部…13 5.2. マニュアル対自動構成される…14 6. IPv6優位なネットワーク展開分析…14 7. 一般は分析から外へ出ます…15 7.1. IPv6展開のためのプランを上演します…15 7.2. インフラストラクチャ要件をネットワークでつないでください…15 7.3. ステージ1: 接続性ステップに頭文字をつけてください…15 7.3.1. 外部の接続性を得ます…16 7.3.2. グローバルなIPv6アドレス空間を得ます…16 7.4. ステージ2: ジェネリック基本サービスがコンポーネントであると配布します…16 7.4.1. IPv6アドレシングを開発して、計画してください…16 7.4.2. IPv6 DNS…17 7.4.3. IPv6ルート設定…17 7.4.4. ホストの構成…18 7.4.5. セキュリティ…18 7.5. ステージ3: 広範囲のデュアルスタック展開現場…19 8. 適切な変遷メカニズム…20 8.1. 非互換なネットワークTouchpointsを認識します…20 8.2. アプリケーション非互換性を認識します…21 8.3. IPv6が変遷であるとサポートするのに複数のメカニズムを使用します…22 9. セキュリティ問題…22 10. 参照…22 10.1. 標準の参照…22 10.2. 有益な参照…24 11. 承認…25 付録A.危機経営者側はシナリオをネットワークでつなぎます…26 A.1。 序論…26 A.2。 危機マネジメント・ネットワークにおけるIPv6展開のためのシナリオ…26 A.3。 ジェネリック危機マネジメント・ネットワークの記述…28 A.4。 IPv6展開のステージ…29
Bound, et al. Informational [Page 2] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [2ページ]情報のRFC4852IPv6企業網分析2007年4月
1. Introduction
1. 序論
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 Layer3に焦点を合わせる企業網でIPv6への変遷を分析します。 複数の内部のリンク、および1つ以上のルータ接続が1Providersまであることとしてネットワーク操作実体によって管理されることとしてこれらのネットワークは特徴付けられます。 分析は企業シナリオで1人の基底集合の変遷の記号法のネットワークと前のドキュメントから広げられた要件に焦点を合わせます。 企業にIPv6への変遷に必要である集中している変遷分析のときに議論を提供します、企業の中でDual-IP層(IPv4とIPv6)のネットワークとノードが環境であると仮定して。 そして、1セットの変遷メカニズムはそれぞれの記号法のネットワークのために推薦されます。
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の可能性を描くのにツールとしてマトリクスを記述することによって、企業分析は使用され始めます。 そして、ドキュメントは、企業全体のDual-IP層の展開が戦略であるとサポートして、どうしたらそれを計画できるか、そして、どんなオプションが利用可能であるかに関する意見を読者に提供するために分析を提供するでしょう。 そして、ドキュメントは企業がしばらく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.
そして、ドキュメントは前の分析から一般答弁と適用性について議論します。 ドキュメントは、記号法のネットワークシナリオが企業がそれであるとサポートするという1セットの現在の変遷メカニズム推薦が、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.
述べられているように、このドキュメントはDual-IP Layer3がネットワークの向こう側にサポートされるところとノードで企業で展開ケースだけに焦点を合わせます。 追加展開変遷分析は、IPv6だけノードかProvider展開の効果から必要であり、このドキュメントの範囲を超えています。 さらに、このドキュメントは、ネットワークアドレス変換[NATPT]かProvider無党派アドレス空間とどんな使用についても定義するか、または議論するのを試みません。
Bound, et al. Informational [Page 3] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [3ページ]情報のRFC4852IPv6企業網分析2007年4月
The following specific topics are currently out of scope for this document:
現在、このドキュメントのための範囲の外に以下の特定の話題があります:
- Multihoming
- Application transition/porting (see [APPS]).
- IPv6 VPN, firewall, or intrusion detection deployment.
- IPv6 network management and QoS deployment.
- Detailed IT Department requirements.
- Deployment of novel IPv6 services, e.g., Mobile IPv6.
- Requirements or Transition at the Providers' network.
- Transport protocol selection for applications with IPv6.
- Application layer and configuration issues.
- IPv6 only future deployment scenarios.
- マルチホーミング--アプリケーション変遷/ポーティング([APPS]を見ます)。 - IPv6 VPN、ファイアウォール、または侵入検出展開。 - IPv6ネットワークマネージメントとQoS展開。 - 詳細なIT部の要件。 - 目新しいIPv6サービス、例えば、モバイルIPv6の展開。 - Providersのネットワークの要件かTransition。 - 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が[ウマン][ISPA][3GPA]をしたとき、同様に、このドキュメントはIP Layer3展開に焦点を合わせます。 このドキュメントは「ワイヤ」でのアドレス管理とDNSサービスを含むIPv6の展開をカバーしています。
We are also assuming that the enterprise deployment is being undertaken by the network administration team, i.e., this document does not discuss the case of an individual user gaining IPv6 connectivity (to some external IPv6 provider) from within an enterprise network. Much of the analysis is applicable to wireless networks, but there are additional considerations for wireless networks not contained within this document.
また、私たちは、企業展開がネットワーク管理チームによって引き受けられていると思っています、すなわち、このドキュメントは中からIPv6の接続性(何らかの外部のIPv6プロバイダーへの)に企業網を獲得する個々のユーザのケースについて議論しません。 分析の多くがワイヤレス・ネットワークに適切ですが、このドキュメントの中に含まれなかったワイヤレス・ネットワークのための追加問題があります。
In Section 2, we introduce the terminology used in this document. In Section 3, we introduce and define a tools matrix and define the IP Layer 3 connectivity requirements. In Section 4, we discuss wide scale Dual-IP layer use within an enterprise. In Section 5, we discuss sparse Dual-IP layer deployment within an enterprise. In Section 6, we discuss IPv6-dominant network deployment within the enterprise. In Section 7, we discuss general issues and applicability. In Section 8, a set of transition mechanisms that can support the deployment of IPv6 with an enterprise are recommended.
セクション2では、私たちは本書では使用される用語を紹介します。 セクション3では、私たちは、ツールマトリクスを導入して、定義して、IP Layer3接続性要件を定義します。 セクション4では、私たちは企業の中で広いスケールDual-IP層の使用について議論します。 セクション5では、私たちは企業の中でまばらなDual-IP層の展開について議論します。 セクション6では、私たちは企業の中でIPv6優位なネットワーク展開について議論します。 セクション7では、私たちは一般答弁と適用性について議論します。 セクション8では、企業とのIPv6の展開をサポートすることができる1セットの変遷メカニズムはお勧めです。
This document then provides Appendix A for readers depicting a Crisis Management enterprise network to demonstrate an enterprise network example that requires all the properties as analyzed in Sections 3, 4, 5, 6, and 7. In addition, we recommend that readers of this document also read another use-case document to support an IPv6 Transition for a Campus Network [CAMP].
そして、このドキュメントはセクション3、4、5、6、および7で分析されるように企業網の例を示すためにCrisis Management企業網について表現する読者のためのすべてを必要とするAppendix Aに資産を供給します。 さらに、私たちは、また、このドキュメントの読者がCampus Network[CAMP]のためにIPv6 Transitionをサポートするために別のケースを使用しているドキュメントを読むことを勧めます。
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に訓練していますが、このドキュメントのための範囲から訓練しているのを意識しているべきです。
Bound, et al. Informational [Page 4] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [4ページ]情報のRFC4852IPv6企業網分析2007年4月
2. Terminology
2. 用語
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.
エンタープライズNetwork--複数の内部のリンク、および1つ以上のルータ接続が1Providersまであって、ネットワーク操作実体によって活発に経営されるネットワーク。
Provider - An entity that provides services and
connectivity to the Internet or other private
external networks for the enterprise network.
プロバイダー--企業網のためにインターネットか他の私設の外部のネットワークにサービスと接続性を提供する実体。
IPv6-capable - A node or network capable of supporting both
IPv6 and IPv4.
IPv6できる、--IPv6とIPv4の両方をサポートすることができるノードかネットワーク。
IPv4-only - A node or network capable of supporting only
IPv4.
IPv4専用--IPv4しかサポートすることができないノードかネットワーク。
IPv6-only - A node or network capable of supporting only
IPv6. This does not imply an IPv6 only stack in
this document.
IPv6専用--IPv6しかサポートすることができないノードかネットワーク。 これは、IPv6が本書では積み重ねるだけであるのを含意しません。
Dual-IP - A network or node that supports both IPv4 and
IPv6.
二元的なIP--IPv4とIPv6の両方を支えるネットワークかノード。
IP-capability - The ability to support IPv6 only, IPv4 only, or
Dual-IP Layer
IP-能力--IPv6だけ、IPv4だけ、またはDual-IP Layerをサポートする能力
IPv6-dominant - A network running IPv6 routing and control plane
services that provides transport for both IPv4
and IPv6 protocol services
IPv6-優性--それがIPv4とIPv6プロトコルサービスの両方のための輸送を提供するネットワーク実行IPv6ルーティングとコントロール飛行機サービス
Transition - The network strategy the enterprise uses to Implementation transition to IPv6.
変遷--企業がIPv6へのImplementation変遷に使用するネットワーク戦略。
3. Enterprise Matrix Analysis for Transition
3. 変遷のためのエンタープライズマトリクス解析
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
Layer3で移行企業の分析に文脈を提供するために、私たちは様々なシナリオについて説明するマトリクスを供給しました。
Bound, et al. Informational [Page 5] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [5ページ]情報のRFC4852IPv6企業網分析2007年4月
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.
IPv6変遷の間、遭遇するかもしれません。 概念的な企業網はインターネットによって切り離された2つの異なったグローバルな位置の企業の所有されているイントラネットに付けられたホストから成ります。 企業は、それ自身のintranetworksを所有して、操作して、維持しますが、インターネットのサービスを提供する外部のプロバイダー組織に依存します。 ともに地方と目的地intranetworksには、過渡期における、ある時の他のintranetworksより同じ企業の中で異なった組織によって運用されて、その結果、異なるIP-機能があるかもしれません。
Addressing every possible combination of network IP-capability in this notional enterprise network is impractical; therefore, trivial notional networks (i.e., pure IPv4, pure IPv6, and ubiquitous Dual- IP) are not considered. In addition, the authors could not conceive of any scenarios involving IPv6-only ISPs or IPv6-only nodes in the near term and consequently have not addressed scenarios with IPv6- only ISPs or IPv6-only nodes. We assume all nodes that host IPv6 applications are Dual-IP. The matrix does not assume or suggest that network address translation is used. The authors recommend that network address translation not be used in these notional cases.
この概念的な企業網における、ネットワークIP-能力のあらゆる可能な組み合わせを扱うのは非実用的です。 したがって、些細な概念的なネットワーク(すなわち、純粋なIPv4、純粋なIPv6、および遍在しているDual IP)は考えられません。 さらに、作者は、近いうちにIPv6だけISPかIPv6だけノードにかかわるどんなシナリオも想像できないで、その結果、ISPかIPv6だけノードだけをIPv6があるシナリオに扱っていません。 私たちは、IPv6アプリケーションを主催するすべてのノードがDual-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可能なTransition Implementationsのマトリクスとその概念的なネットワークのためのIPv6変遷メカニズムの選択があります。 それぞれの可能な実装はマトリクスの行によって表されます。 マトリクスは以下の1セットの概念的なネットワークについて説明します:
- 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-能力によって使用されるプロトコルを表します。 (アプリケーション/ホスト1OS)
- 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-能力を表します。 (サービスプロバイダー)
Bound, et al. Informational [Page 6] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [6ページ]情報のRFC4852IPv6企業網分析2007年4月
- 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)
- 反逆者は起因しているIPパケットを受けるアプリケーションで使用されるプロトコルと以下の目的地ノードのIP-能力を表します。 (アプリケーション/ホスト2OS)
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はコミュニケーション交換を確立しようとするDual-IP層のホストの上に目的地IPv6アプリケーションであるIPv6アプリケーションです。 情報交換を終了するために、パケットは最初に、ホストの起因するIPv4ネットワーク(イントラネット)(次に、サービスプロバイダーとあて先ホストのDual-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.
明らかに、Table1はあらゆる可能なシナリオについて説明するというわけではありません。 些細な概念的なネットワーク(純粋なIPv4や、純粋なIPv6や、遍在しているDual-IPなどの)は演説されません。 しかしながら、作者は、これらの10のシナリオが今日の企業で遭遇しそうな過渡的な状況のかなりの大部分の代理をすると感じます。 したがって、私たちは、企業展開のための分析を扱うのにこれらの10を使用するつもりです。
Bound, et al. Informational [Page 7] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [7ページ]情報のRFC4852IPv6企業網分析2007年4月
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 |
======================================================
====================================================== |アプリケーション|ホスト1|サービス|ホスト2|アプリケーション| |----------- |ネットワーク|プロバイダー|ネットワーク|---------- | | ホスト1OS| | | | ホスト2OS| =====================================+================ | IPv6| |二元的なIP| | IPv6| A| ---- | IPv4| または|二元的なIP| ---- | | 二元的なIP| | IPv4| | 二元的なIP| ====================================================== | IPv6| | | | IPv6| B| ---- | IPv6| IPv4| IPv4| ---- | | 二元的なIP| | | | 二元的なIP| ====================================================== | IPv4| | | | IPv4| C| ---- | IPv4|二元的なIP| IPv6| ---- | | 二元的なIP| | | | 二元的なIP| ====================================================== | IPv4|二元的なIP| | | IPv4| D| ---- | または| IPv4| IPv6| ---- | | 二元的なIP| IPv6| | | 二元的なIP| ====================================================== | IPv6|二元的なIP| |二元的なIP| IPv4| E| ---- | または|二元的なIP| または| ---- | | 二元的なIP| IPv6| | IPv6| 二元的なIP| ====================================================== | IPv6| | | | IPv4| F| ---- | IPv6| IPv4| IPv4| ---- | | 二元的なIP| | | | 二元的なIP| ====================================================== | IPv4| | | | IPv6| G| ---- | IPv6| 二元的なIP| IPv6| ---- | | 二元的なIP| | | | 二元的なIP| ====================================================== | IPv4| | | | IPv6| H| ---- | IPv6|二元的なIP| IPv4| ---- | | IPv4| | | | 二元的なIP| ====================================================== | IPv4| | | | IPv6| I| ---- | IPv6| IPv4| IPv6| ---- | | IPv4| | | | 二元的なIP| ====================================================== | IPv6| | | | IPv4| J| ---- | IPv4| IPv4| IPv6| ---- | | 二元的なIP| | | | 二元的なIP| ======================================================
Bound, et al. Informational [Page 8] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [8ページ]情報のRFC4852IPv6企業網分析2007年4月
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.
読者は、Table1のScenarios A-Cがコンパチブルホストが主に(完全でない)均質のネットワークの向こう側に交信する変化であることに注意するべきです。 それぞれの最初の3つのシナリオでは、パケットは少なくとも1個の両立しないネットワーク要素を横断しなければなりません。 例えば、Scenario BはIPv6アプリケーションを使用したがっている企業を代表しますが、まだ内部のネットワークを変遷に持っています。 また、v4IP-サービスだけを提供して、Service Providerは遅れます。 逆に、Scenario Cはコアネットワーク(Service Providerのような)で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はコアintranetworksをIPv6に移行させましたが、企業がプロバイダーが持っている(Scenario 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のベースの具体化の両方を持っている過渡的な状況を表します。 さらに、これらのシナリオは、企業がすべての有機肥料、そして/または、Service ProviderネットワークでIPv6への変遷を終了していないのを示します。 代わりに、それは交信アプリケーションの間のさまざまな異機種ネットワークセグメントを維持します。 シナリオEとJはスペクトルのどちらの終わりにも明瞭に異なった極端を表します。 Scenario Eでは、企業はアプリケーションとネットワークの両方でIPv6に主に移行しました。 しかしながら、Scenario Eは、いくつかのレガシーのIPv4ベースの法則が企業でまだ見つけられているかもしれないのを示します。 他方では、Scenario Jはそれが非常にばらばらの方法で変遷を始めて、どのIPv6ベースのアプリケーションとネットワークでは、セグメントが比較的まれであるかを企業に示します。
Bound, et al. Informational [Page 9] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [9ページ]情報のRFC4852IPv6企業網分析2007年4月
4. Wide-Scale Dual-Stack Deployment Analysis
4. 広いスケールデュアルスタック展開分析
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で説明されるようにScenario1を扱います。 シナリオ、仮定、および要件は[BSCN]テキストから追い立てられます。 この分析は上のセクション3でさらにScenario Aに対応しています(Scenario Aは、企業がまだ1つのネットワークセグメントを持っている過渡的な状況がDual-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ルータ(そして、その結果、サブネット)が人工のDual-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.
Dual-IPリンクの上のノードがそうするかもしれない、自分たち、IPv4だけかできるIPv6になってください。 ワイヤの上のIPv6を配布するためのドライバーは、IPv6が即座の広いスケール用法のためのものであるのではなくむしろIPv6できるノードをサポートするために既存のIPv4インフラストラクチャを準備するためにはものであるかもしれません。 その結果、IPv6が使用されていない間、Dual-IPノードは存在します、そして、企業は存在できます。オンデマンドのIPv6に移行しました。
Analyzing this scenario against existing transition mechanisms for their applicability suggests a staged approach for IPv6 deployment in the enterprise.
彼らの適用性のために既存の変遷メカニズムに対してこのシナリオを分析すると、IPv6展開のための上演されたアプローチは企業で示されます。
4.1. Staged Dual-Stack Deployment
4.1. 上演されたデュアルスタック展開
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.
これらのシナリオ(ほとんどの他のものと同様に)の下では、サイトの管理者はDual-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の接続性を持つべきでない何か(例えば、Table1のScenario A)があるかもしれません。 また、企業の上流のプロバイダーによってRegionalインターネットRegistries(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.
本書では、タイプと範囲が選択したアドレスがこのドキュメントのLayer3分析と直交しているので、私たちはUnique Local IPv6 Unicast Addresses[ULA]の展開について議論しません。
Bound, et al. Informational [Page 10] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [10ページ]情報のRFC4852IPv6企業網分析2007年4月
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.
典型的な展開は、より広い展開の前に初めは、企業サイトでただ一つの「テストベッド」Dual-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展開のための基本的なブロックが適所にあった後にそれを引き受けることができました)。
4.2. Routing Capability Analysis for Dual-IP Deployment
4.2. 二元的なIP展開のためのルート設定能力分析
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.
Dual-IP展開の重要な部分は実装されるIPv6のできるルーティングインフラストラクチャの選択です。 取られた経路は企業にはIPv6(ルーティング)能力を持っているか、またはそのような能力を持つためにアップグレードできる既存のLayer2/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が展開であると考えていません。 Dual-IP展開の目標は企業で普及使用です。
4.2.1. IPv6 Routing Capability
4.2.1. IPv6ルート設定能力
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を有効にすることができます。 両方を可能にするのは、Dual-IP展開をサポートするどんな企業の最終目標です、Dual-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からのテクニックが必要であるかもしれません。
4.2.2. IPv6 Routing Non-Capability
4.2.2. IPv6ルート設定非能力
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に供給できないなら、変遷のための別法があります。 この場合、企業の管理者は2つの基本的な選択、既存のIPv4インフラストラクチャのいくつかかすべて上でIPv6にトンネルを堀るか、または既存のIPv4サブネットにIPv6の接続性を提供する平行なIPv6ルーティングインフラストラクチャを配布するどちらかに面しています。
It may thus be the case that a node's IPv4 and IPv6 default routes to reach other links (subnets) are through different routing platforms.
その結果、異なったルーティングプラットホームを通ってデフォルトが他のリンク(サブネット)に達するように発送するノードのIPv4とIPv6があるのは、事実であるかもしれません。
Bound, et al. Informational [Page 11] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [11ページ]情報のRFC4852IPv6企業網分析2007年4月
4.2.2.1. Tunnel IPv6 over the IPv4 infrastructure
4.2.2.1. 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できませんが(Table1のシナリオB)。 [BCNF]で説明されるようにトンネルを堀るのは企業にDual-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.
広範囲のDual-IPシナリオでは、さらに構造化されて、処理しやすいメソッド(管理者は展開リンクを管理する)が必要であり、(理想的に)長期的で、「集合-可能」なグローバルなIPv6アドレシングは、着手から得られて、計画されて、使用されます。
4.2.2.2. Deploy a Parallel IPv6 Infrastructure
4.2.2.2. 平行なIPv6インフラストラクチャを配布してください。
Alternatively, the administrator may deploy a new, separate IPv6- capable router (or set of routers). It is quite possible that such a parallel infrastructure would be IPv6-dominant.
あるいはまた、管理者は新しくて、別々のIPv6できるルータ(または、ルータのセット)を配布するかもしれません。 そのような平行なインフラストラクチャがIPv6優位であることは、かなり可能です。
Such an approach would likely require additional hardware, but it has the advantage that the existing IPv4 routing platforms are not disturbed by the introduction of IPv6.
そのようなアプローチはおそらく追加ハードウェアを必要とするでしょうが、それには、既存のIPv4がプラットホームを発送して、IPv6の導入で擾乱されない利点があります。
To distribute IPv6 to existing IPv4 enterprise subnets, either dedicated physical infrastructure can be employed or, if available, IEEE 802.1q VLANs could be used, as described in [VLAN]. The latter has the significant advantage of not requiring any additional physical cabling/wiring and also offers all the advantages of VLANs for the new Dual-IP environment. Many router platforms can tag multiple VLAN IDs on a single physical interface based on the subnet/link the packet is destined for; thus, multiple IPv6 links can be collapsed for delivery on a single (or small number of) physical IPv6 router interface(s) in the early stages of deployment.
捧げられた既存のIPv4企業サブネットにIPv6を分配するのに、物的なインフラを使うことができますか、または利用可能であるなら、IEEE 802.1q VLANsは使用されるかもしれません、[VLAN]で説明されるように。 後者は、少しの追加物理的なケーブリング/配線も必要としない重要な利点を持って、また、新しいDual-IP環境のためにVLANsのすべての利点を示します。 多くのルータプラットホームがパケットが運命づけられているサブネット/リンクに基づく単一の物理インターフェースで複数の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.
平行なインフラストラクチャは統一されたインフラストラクチャで完全なDual-IP展開に向かって中間の段階と考えられるだけであるべきです。 しかしながら、平行なインフラストラクチャで、IPv6エンタープライズサービスの他のすべての局面が配布します、IPv6アドレシングを含んでいて、その結果、それのために、より後日ステップを統一しながら、企業を用意します。
4.3. Remote IPv6 Access to the Enterprise
4.3. エンタープライズへのリモート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 Tunnel Broker[TBRK]の展開でそのような遠隔サポートを提供するかもしれません。
Bound, et al. Informational [Page 12] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [12ページ]情報のRFC4852IPv6企業網分析2007年4月
4.4. Other Considerations
4.4. 他の問題
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].
デフォルトでIPv6をつけると関連しているいくつかの問題があります、アプリケーション接続遅れ、不十分な接続性、およびネットワークの不安定を含んでいて、[V6DEF]で議論するように。 問題は、[V6DEF]でのアドバイスに従うことで扱うか緩和できます。
5. Sparse Dual-Stack Deployment Analysis
5. まばらなデュアルスタック展開分析
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で説明されるようにScenario2をカバーします。 このシナリオは[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インフラストラクチャを混乱させないで、それらを使用できます。 いくつかの状態が以下のサブセクションで導入するように分析を必要とします。
5.1. Internal versus External Tunnel Endpoint
5.1. 外部のトンネル終点に対して内部です。
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
上流のプロバイダーがいくつかのIPv6サービス(バックボーンかアクセスネットワークにおけるネイティブのIPv6か両方(Table1のシナリオB)の何らかの組み合わせのどちらか)を配布したと仮定しましょう。 また、この場合、プロバイダーは、彼らのIPv6加入者をサポートするためにおそらく1つ以上の変遷メカニズムを配布するでしょう。 明らかに、企業は、Providerから提供されたそれらの変遷サービスを利用すると決めることができました。 しかしながら、通常、これは、ネットワークにおける個々のノードがそれら自身のIPv4のIPv6トンネルを必要とすることを意味するでしょう。 結末はいくらか効率の悪いIPv6 intranetworksコミュニケーションです、企業のIPv4インフラストラクチャですべてのIPv6トラフィックをProviderによって提供されたTunnel Endpointに送らなければならないので。 それにもかかわらず、これは特にIPv6であるなら許容できるかもしれません。
Bound, et al. Informational [Page 13] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [13ページ]情報のRFC4852IPv6企業網分析2007年4月
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.
アプリケーションは全く、例えばintranetworksコミュニケーションを必要としません、アプリケーションのサーバが企業網の外に位置しているか、または同じ企業の他の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.
あるいはまた、企業は上流のProviderに接続する境界ルータに隣接してそれ自身の変遷メカニズムノードを配布して、ことによると並べるのにそれについて決めることができました。 また、この場合、このトンネル終点を使用するintranetnetworksコミュニケーションも可能です。
5.2. Manual versus Autoconfigured
5.2. マニュアル対自動構成にされる
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を使用しているノードの数が下位であるなら、第1の選択は静的に構成されたトンネルを使用することです。 しかしながら、特に数が、より大きいなら、自動的に構成されたトンネルは望ましいかもしれません。
6. IPv6-Dominant Network Deployment Analysis
6. 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で説明されるようにScenario3をカバーしています。 シナリオ、仮定、および要件は[BSCN]テキストから追い立てられます。 このドキュメントの中では、Table1のScenario 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優位なネットワーク展開戦略を使いたがっているかもしれない企業網もあります。 これが本質的には意味することは企業網の中のネットワークか特定のサイトはネットワークができるDual-IPであるかもしれませんが、IPv4とIPv6パケットの両方をネットワークの上に移すのにIPv6ルーティングだけを使用するIPv6への変遷がそうするということです。 必要なら、縁のIPv4ネットワークをサポートする以外に、IPv4ルーティングはIPv6優位なネットワークの中でつけられないでしょう。
Under this scenario, communications between IPv6 nodes will use IPv6. When IPv6-capable nodes in the IPv6-dominant network need to communicate with IPv4 nodes, the IPv6 nodes will use their Dual-IP implementation to tunnel IPv4 packets in IPv6 [V6TUN]. An edge router within the IPv6-dominant network will decapsulate the IPv4 packet and route to the path of the IPv4 node on the network. This permits Dual-IP layer nodes to communicate with legacy IPv4 nodes within an IPv6-dominant network.
このような筋書で、IPv6ノードのコミュニケーションはIPv6を使用するでしょう。 IPv6優位なネットワークにおけるIPv6できるノードが、IPv4ノードとコミュニケートする必要があると、IPv6ノードはIPv6[V6TUN]でそれらのDual-IP実装をトンネルIPv4パケットに使用するでしょう。 IPv6優位なネットワークの中の縁のルータはネットワークのIPv4ノードの経路にIPv4パケットとルートをdecapsulateするでしょう。 これは、Dual-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.
Table1からのシナリオEとFはIPv6優位な展開戦略が適所にあるかもしれない追加ケースについて表現します。 Scenario Eでは、全体のネットワークはIPv6優位であるかもしれませんが、Host OS2システムはIPv4アプリケーションを実行しています。 Scenario Fでは、HostのOSの1台のシステムのネットワークはIPv6優位であるかもしれませんが、ネットワークの残りはすべてIPv4です。
Bound, et al. Informational [Page 14] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [14ページ]情報のRFC4852IPv6企業網分析2007年4月
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終わりのホストと共に共同利用する)を習得して、IPv4パケットが次のホップIPv6ルータにトンネルを堀られることを許可するそれらのネットワークと結局、目的地Dual-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優位なネットワーク展開戦略を使用するかどうかという決定は、企業のビジネスと作戦目的による完全に駆動であり、企業の変遷プランによって誘導されます。
7. General Issues from Analysis
7. 分析からの一般答弁
In this section, we describe generic enterprise IPv6 deployment issues, applicable to the analysis in Sections 4-6 of this document.
このセクションで、私たちはこのドキュメントのセクション4-6での分析に適切なジェネリック企業IPv6展開問題について説明します。
7.1. Staged Plan for IPv6 Deployment
7.1. 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展開のための上演されたプランに従う必要があるでしょう。 これが意味することは変遷のすべてのポイントとコンポーネントのために企業網の戦略の識別を実行しなければならないということです。
7.2. Network Infrastructure Requirements
7.2. ネットワークインフラ要件
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で詳細です。 私たちはそのようなコンポーネントの全面で本書では詳細に立ち入りません。 本書では、私たちはLayer3問題に焦点を合わせます。
7.3. Stage 1: Initial Connectivity Steps
7.3. ステージ1: 初期の接続性ステップ
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プロバイダーを選択して、そのプロバイダーからroutable IPv6アドレス空間をグローバルに得る必要があります。
Bound, et al. Informational [Page 15] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [15ページ]情報のRFC4852IPv6企業網分析2007年4月
7.3.1. Obtaining External Connectivity
7.3.1. 外部の接続性を得ます。
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.
エンタープライズサービスプロバイダーは通常、aがIPv6の上流のリンクを提供できるIPv6プロバイダーを地誌的に閉じるということでしょう。 企業が固有のIPv6上流の接続性か不在における手動で構成されたトンネル[BCNF]のどちらかを上流のプロバイダーに使用すると予想されるでしょう。
7.3.2. Obtaining Global IPv6 Address Space
7.3.2. グローバルなIPv6アドレス空間を得ます。
The enterprise will obtain global IPv6 address space from its selected upstream provider, as provider-assigned (PA) address space.
企業はプロバイダーで割り当てられた(PA)アドレス空間として選択された上流のプロバイダーからグローバルなIPv6アドレス空間を得るでしょう。
The enterprise should receive at least a /48 allocation from its provider, as described in [ALLOC].
企業は[ALLOC]で説明されるようにプロバイダーから少なくとも/48配分を受けるべきです。
Should an enterprise change their provider, a procedure for enterprise renumbering between providers is described in [RENUM].
企業がそれらのプロバイダーを変えるなら、プロバイダーの間の企業の番号を付け替える手順は[RENUM]で説明されます。
7.4. Stage 2: Deploying Generic Basic Service Components
7.4. ステージ2: ジェネリック基本サービスがコンポーネントであると配布します。
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でこれらの大部分について議論します。 ここで、私たちはこの解析書のために範囲にあると信じているそれらの局面を批評します。 したがって、私たちはここでネットワークマネージメント、マルチホーミング、マルチキャスト、またはアプリケーション変遷分析を入れていません。 しかしながら、これらの局面はStage2で扱われるべきです。
7.4.1. Developing an IPv6 Addressing Plan
7.4.1. IPv6アドレシングプランを開発します。
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).
Dual-IP展開では、サイトは、それが、IPv6リンクが既存のIPv4サブネットについて一致していると配布したがっているかどうか決める必要があるでしょう。 この場合、ノードは両方のプロトコルのための同じリンクかサブネットになるでしょう。 そのような体系に続くことができました、位相的な成長の余地が食糧を供給される(企業再構築のため将来の番号を付け替える潜在的要件を減らす)ように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
IPv6の有利な特性は管理者がアドレス保護に同じくらい多くの取り組みを注ぎ込む必要はないということです。 IPv4と共に、サイトは、IPv4アドレス保護が必要であるのでできるだけ現在サブネット(例えば、50のノードのための/26)における、ホストの数には小さくなるようにサブネットをIPv4におそらく割り当てるでしょう。 これは問題を生じさせます。
Bound, et al. Informational [Page 16] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [16ページ]情報のRFC4852IPv6企業網分析2007年4月
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.
サブネットのノードの数が成長すると、より大きいIPv4接頭語が必要です、そして、潜在的に手間がかかって破壊的な番号を付け替えるイベントは続くでしょう。
With IPv6, a link can in effect have any number of nodes, allowing link growth without the need to adjust prefix allocations with the associated renumbering requirement. The size of the initial site allocation (currently recommended to be a /48) also is likely to allow room for site growth without a need to return to the connectivity provider to obtain more, potentially non-sequential, address space (as is the case for IPv4 today, with the associated paperwork and probable delays).
IPv6があるので、事実上、リンクはいろいろなノードを持つことができます、関連番号を付け替える要件で接頭語配分を調整する必要性なしでリンクの成長を許容して。 初期のサイト配分(現在、/48であることが推薦される)のサイズも接続性プロバイダーに戻って、より多くて、潜在的に非連続したアドレス空間を得る必要性なしでサイトの成長の余地を許容しそうです(今日関連文書業務とありえそうな遅れに関してIPv4のためにそうであるように)。
At the time of writing, best practice in IPv6 site address planning is restricted due to limited wide-scale deployments. Administrators should allocate /64 size prefixes for subnets, and do so in a way that has scope for growth within a site. The site should utilize a plan that reserves space for topological growth in the site, given that its initial IPv6 prefix allocation (currently recommended to be a /48) is likely to include such room for growth. Also see "IPv6 Unicast Address Assignment" [UNAD].
これを書いている時点で、IPv6サイトアドレス計画で最も良い習慣は限られた広いスケール展開のため制限されます。 管理者は、サブネットのために64のサイズ接頭語を/に割り当てて、そうサイトの中に成長のための範囲を持っている方法でするべきです。 サイトはサイトでの位相的な成長のためにスペースを予約するプランを利用するべきです、初期のIPv6接頭語配分(現在、/48であることが推薦される)が成長のそのような部屋を含んでいそうであるなら。 また、「IPv6ユニキャストアドレス課題」[UNAD]を見てください。
7.4.2. IPv6 DNS
7.4.2. IPv6 DNS
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]で報告されます。
7.4.3. IPv6 Routing
7.4.3. IPv6ルート設定
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.
aはシングル家へ帰りました。ただ一つのサイトネットワーク、ただ一つの上流プロバイダーへのスタティックルートは十分であるかもしれません、サイトが、外のルーティング・プロトコルを使用するのを選ぶかもしれませんが、特にそれには複数の上流のプロバイダーがあるところで。
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[イシス]、OSPFv3[OSPF]、およびRIPng[RIPng]。
Bound, et al. Informational [Page 17] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [17ページ]情報のRFC4852IPv6企業網分析2007年4月
7.4.4. Configuration of Hosts
7.4.4. ホストの構成
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.
安全な自動構成のサポートが必要であるところでは、SEND[SEND]を使用できます。 読者はSENDドキュメントの中にIPsec[IPSEC]への適用性証明を見るべきです。
A stateless configured node wishing to gain other configuration information (e.g., DNS, NTP servers) will likely need a Stateful DHCPv6 [DHCPv6] service available.
他の設定情報(例えば、DNS、NTPサーバ)を獲得したがっている状態がない構成されたノードはおそらく利用可能な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 Relayエージェント機能が必要でしょう。そこでは、DHCPv6サーバがofflinkです。 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 Privacy Addresses[PRIVv6]を生成するか、または要求するかもしれません。 DHCPv6が管理された環境でプライバシーアドレスをノードに割り当てるように、サポートがあります。
7.4.5. Security
7.4.5. セキュリティ
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.
Dual-IPネットワークの中でIPv6を配布するとき、サイトは、IPv6できるノードのためにIPv4できるノードのためにするようにサイト安全保障政策を実装する必要があるでしょう。 例えば、既にそれと同じ方針を実施するのによるトラフィックがIPv4のためにするIPv6をフィルターにかけて、境界ファイアウォールは制御できるべきです。
However, a site will also need to review its security policy in light of IPv6-specific functionality that will be deployed in the site, e.g., Mobile IPv6, stateless autoconfiguration (and SEND), IPv6 Privacy Extensions, and end-to-end IPsec. In addition, a site will need to review the use of globally aggregatable public address space where, for IPv4, private addressing and NAT may have been used.
しかしながら、また、サイトは、サイトで配布されるIPv6特有の機能性、例えば、モバイルIPv6(状態がない自動構成(そして、SEND)、IPv6 Privacy Extensions、および終わりから終わりへのIPsec)の観点から安全保障政策を見直す必要があるでしょう。 さらに、サイトは、IPv4に、個人的なアドレシングとNATが使用されたかもしれないグローバルに「集合-可能」な場内放送スペースの使用を見直す必要があるでしょう。
An overview of how Network Architecture Protection (NAP) using IPv6 can provide the same or more benefits without the need for NAT can be found in [NAP]. This describes how the perceived security with IPv4 NAT can be achieved and surpassed with IPv6, i.e., how IPv6
[NAP]でIPv6を使用するNetwork Architecture Protection(NAP)がNATの必要性なしで同じくらいか、より多くの利益をどう提供できるかに関する概要を見つけることができます。 これはすなわち、IPv6、どのようにIPv6と共にIPv4NATがある知覚されたセキュリティをどう達成して、凌ぐことができるかを説明します。
Bound, et al. Informational [Page 18] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [18ページ]情報のRFC4852IPv6企業網分析2007年4月
technology can be used to provide the market-perceived benefits of IPv4 NAT.
IPv4NATの市場によって知覚された利益を提供するのに技術を使用できます。
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.
また、特定の変遷メカニズムの展開は脅威を導入するかもしれません、例えば、IPv6データを運ぶのがIPv4でトンネルを堀りました。 サイト安全保障政策は配布される変遷メカニズムを受け入れるべきです。
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.
[V6SEC]でIPv6安全保障問題の概要を見つけることができます。 これはIPv6展開自体にIPv6プロトコルと、そして、変遷メカニズムと、そして、特定の問題の議論を含んでいます。
In addition, an enterprise should review all current host-based security requirements for their networks and verify support for IPv6.
さらに、企業は、それらのネットワークのためのすべての現在のホストベースのセキュリティ要件を再検討して、IPv6のサポートについて確かめるべきです。
7.5. Stage 3: Widespread Dual-Stack Deployment On-Site
7.5. ステージ3: 広範囲のデュアルスタック展開現場です。
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.
Dual-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
しばしばサイトの中でIPv6の使用をサポートしたがっているサイトでDual-IP展開をするでしょう、IPv6輸送がすべてのアプリケーションで好まれないでも。 すべてのサイトインフラストラクチャ(DNS、メール輸送など)にIPv6のサポートを入れるのは、IPv6用法が時間がたつにつれて段階的に導入されるのを許容します。 ノードがIPv6が有効にしたできるIPv6、アプリケーション、およびサービスになるとき、IPv6のできるインフラストラクチャを利用することができます。 Dual-IPは少なくともほとんどのネットワークにおける、aになるでしょう。
Bound, et al. Informational [Page 19] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [19ページ]情報のRFC4852IPv6企業網分析2007年4月
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優位な未来に向かった中期変遷。 しかしながら、グローバルに「集合-可能」な場内放送用法([NAP]がある)と他の新しいIPv6能力の潜在的利益で、IPv6サポートの導入は、より即座の利益をサイトにもたらすことができます。
8. Applicable Transition Mechanisms
8. 適切な変遷メカニズム
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.
IPv6へのネットワーク変遷をサポートするためにどのように、どこで変遷がメカニズムであると配布すると考えるべきであるかを考えるとき、テーブル1は企業の建築家が遭遇するかもしれない多くの共通したシナリオを提供します。 各シナリオのために最も適切なメカニズムを選択するのは、科学より芸術です、そして、その結果それぞれの10のシナリオに対して推薦状をするのは、単に彼らの好評な製品を売り込む射撃の名手のためのまぐさでしょう。 しかしながら、私たちは建築家の意志決定のプロセスのためになるべきである何らかのハイレベルの指導を提供できます。
8.1. Recognizing Incompatible Network Touchpoints
8.1. 非互換なネットワークTouchpointsを認識します。
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.
Table1の10のシナリオの1つにあなたの特定の状況を写像するのは両立しないネットワークが連結する企業網の中で重要なtouchpointsを認識するよりはるかに重要ではありません。 変遷メカニズムがサービスとして企業によって提供されていない場合、これらのtouchpointsでは、メカニズムを考えなければなりません。
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.
Table1の迅速なレビューは、4つの主要なテーマの変化を10のシナリオに煮詰めることができるのを明らかにします。 最も簡単ですが、また、最も好評であるのは(柔軟性による)、どちらかの終わりのコンパチブルホストがいる広範囲のDual-IPです。 この状況はScenario 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番目の一般的なテーマ(Table1のScenarios B-Dでは、表現される)では、企業は中間で1非互換なネットワークtouchpointsでコンパチブルホストから成ります。 セクション4.2.2で説明されるように、両立しないネットワークセグメントを「迂回させること」に.1、トンネリングを使用できます。 1つのトンネリングオプション、企業は手動で構成されたトンネル[BCNF]を使用できましたが、名前が含意するように、このメカニズムはどんな自動化されたトンネル構成も提供しません。
Bound, et al. Informational [Page 20] RFC 4852 IPv6 Enterprise Network Analysis April 2007
バウンド、他 [20ページ]情報のRFC4852IPv6企業網分析2007年4月
"Connection of IPv6 Domains via IPv4 Clouds" [6TO4] can be used to support enterprises that do not have an assigned IPv6 prefix address.
割り当てられたIPv6接頭語アドレスを持っていない企業をサポートするのに、「IPv4 Cloudsを通したIPv6 Domainsの接続」[6TO4]を使用できます。
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.
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.
Readers should review the current work regarding tunnels within the IETF Softwire working group and problem statement [SOFTW].
Readers should review the current work regarding tunnels within the IETF Softwire working group and problem statement [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.
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.
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.
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.
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.
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.
8.2. Recognizing Application Incompatibilities
8.2. Recognizing Application Incompatibilities
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.
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.
Bound, et al. Informational [Page 21] RFC 4852 IPv6 Enterprise Network Analysis April 2007
Bound, et al. Informational [Page 21] RFC 4852 IPv6 Enterprise Network Analysis April 2007
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.
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.
8.3. Using Multiple Mechanisms to Support IPv6 Transition
8.3. Using Multiple Mechanisms to Support IPv6 Transition
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).
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).
9. Security Considerations
9. Security Considerations
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.
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.
10. References
10. References
10.1. Normative References
10.1. Normative References
[CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[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., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[6TO4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001.
[6TO4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[BSCN] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", RFC
4057, June 2005.
[BSCN] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[TRDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, February
2006.
[TRDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
Bound, et al. Informational [Page 22] RFC 4852 IPv6 Enterprise Network Analysis April 2007
Bound, et al. Informational [Page 22] RFC 4852 IPv6 Enterprise Network Analysis April 2007
[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., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, October 2005.
[V6TUN] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998.
[V6TUN] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[TBRK] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001.
[TBRK] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[ALLOC] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", RFC 3177, September 2001.
[ALLOC] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[NATPT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation
- Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[NATPT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[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., and R. van der Pol, "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks", RFC 3904, September 2004.
[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., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[3GPA] Wiljakka, J., Ed., "Analysis on IPv6 Transition in Third
Generation Partnership Project (3GPP) Networks", RFC 4215,
October 2005.
[3GPA] Wiljakka, J., Ed., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005.
[OSPF] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC
2740, December 1999.
[OSPF] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[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., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[ISIS] Oran, D., Ed., "OSI IS-IS Intra-domain Routing Protocol",
RFC 1142, February 1990.
[ISIS] Oran, D., Ed., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142, February 1990.
[RIPng] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RIPng] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[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., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[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., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
Bound, et al. Informational [Page 23] RFC 4852 IPv6 Enterprise Network Analysis April 2007
Bound, et al. Informational [Page 23] RFC 4852 IPv6 Enterprise Network Analysis April 2007
[BCNF] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[BCNF] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[DNSOP6] Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", RFC 4472, April
2006.
[DNSOP6] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, April 2006.
[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., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[NIS] Kalusivalingam, V., "Network Information Service (NIS)
Configuration Options for Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.
[NIS] Kalusivalingam, V., "Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.
[DHCPv4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[DHCPv4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[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., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[PRIVv6] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[PRIVv6] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
10.2. Informative References
10.2. Informative References
[TSPB] Blanchet, M., and F. Parent, "IPv6 Tunnel Broker with the
Tunnel Setup Protocol (TSP", Work in Progress, August 2005.
[TSPB] Blanchet, M., and F. Parent, "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP", Work in Progress, August 2005.
[V6SEC] Davies, E., Krishnan, S., and P. Savola, "IPv6
Transition/Co-existence Security Considerations", Work in
Progress, October 2006.
[V6SEC] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/Co-existence Security Considerations", Work in Progress, October 2006.
[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., and E. Klein, "Local Network Protection for IPv6", Work in Progress, January 2007.
[CAMP] Chown, T., "IPv6 Campus Transition Scenario Description and
Analysis", Work in Progress, March 2007.
[CAMP] Chown, T., "IPv6 Campus Transition Scenario Description and Analysis", Work in Progress, March 2007.
Bound, et al. Informational [Page 24] RFC 4852 IPv6 Enterprise Network Analysis April 2007
Bound, et al. Informational [Page 24] RFC 4852 IPv6 Enterprise Network Analysis April 2007
[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., and C. Strauf, "Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues", RFC 4477, May 2006.
[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., and T. Chown, "IPv6 Unicast Address Assignment", Work in Progress, March 2007.
[VLAN] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in
Enterprise Networks", RFC 4554, June 2006.
[VLAN] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks", RFC 4554, June 2006.
[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., and J. Paugh, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", Work in Progress, January 2006.
[SOFTW] Dawkins, S., Ed., "Softwire Problem Statement", Work in
Progress, March 2007.
[SOFTW] Dawkins, S., Ed., "Softwire Problem Statement", Work in Progress, March 2007.
11. Acknowledgments
11. Acknowledgments
The authors would like to acknowledge contributions from the following: IETF v6ops Working Group members, Fred Baker, Pekka Savola, and Jordi Palet
The authors would like to acknowledge contributions from the following: IETF v6ops Working Group members, Fred Baker, Pekka Savola, and Jordi Palet
Bound, et al. Informational [Page 25] RFC 4852 IPv6 Enterprise Network Analysis April 2007
Bound, et al. Informational [Page 25] RFC 4852 IPv6 Enterprise Network Analysis April 2007
Appendix A. Crisis Management Network Scenarios
Appendix A. Crisis Management Network Scenarios
A.1. Introduction
A.1. Introduction
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.
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.
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.
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 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.
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.
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.
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.
A.2. Scenarios for IPv6 Deployment in Crisis Management Networks
A.2. Scenarios for IPv6 Deployment in Crisis Management Networks
Scenario 1: Limited IPv6 Deployment Network
Scenario 1: Limited IPv6 Deployment Network
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.
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.
Assumptions: IPv6 software/hardware components for the application are available, and platforms for the application are IPv6 capable.
Assumptions: IPv6 software/hardware components for the application are available, and platforms for the application are IPv6 capable.
Bound, et al. Informational [Page 26] RFC 4852 IPv6 Enterprise Network Analysis April 2007
Bound, et al. Informational [Page 26] RFC 4852 IPv6 Enterprise Network Analysis April 2007
Requirements: Do not disrupt IPv4 infrastructure.
Requirements: Do not disrupt IPv4 infrastructure.
Scenario 2: Dual-Stack Network
Scenario 2: Dual-Stack Network
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.
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.
Assumptions: The IPv4 network infrastructure used has an equivalent capability in IPv6.
Assumptions: The IPv4 network infrastructure used has an equivalent capability in 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.
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.
Scenario 3: IPv6-Dominant Network
Scenario 3: IPv6-Dominant Network
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 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.
Assumptions: Required IPv6 network infrastructure is available, or available over some defined timeline, supporting the aggressive transition plan.
Assumptions: Required IPv6 network infrastructure is available, or available over some defined timeline, supporting the aggressive transition plan.
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
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
Bound, et al. Informational [Page 27] RFC 4852 IPv6 Enterprise Network Analysis April 2007
Bound, et al. Informational [Page 27] RFC 4852 IPv6 Enterprise Network Analysis April 2007
be able to interoperate with the IPv6-dominant network's nodes/applications.
be able to interoperate with the IPv6-dominant network's nodes/applications.
A.3. Description of a Generic Crisis Management Network
A.3. Description of a Generic Crisis Management Network
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.
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.
The basic components in a crisis management network are depicted in Figure 1.
The basic components in a crisis management network are depicted in Figure 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|+----------- :
| | | | | |..............
+--------+ +--------+ +--------+
------------ ---------- ---- 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.
Figure 1: Crisis Management Network Topology.
Bound, et al. Informational [Page 28] RFC 4852 IPv6 Enterprise Network Analysis April 2007
Bound, et al. Informational [Page 28] RFC 4852 IPv6 Enterprise Network Analysis April 2007
A.4. Stages of IPv6 Deployment
A.4. Stages of IPv6 Deployment
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.
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.
The four most probable stages are:
The four most probable stages are:
o Stage 1 Limited Launch
o Stage 2 Dual-Stack Dominance
o Stage 3 IPv6 Dominance
o Stage 4 IPv6 Transition Complete
o Stage 1 Limited Launch o Stage 2 Dual-Stack Dominance o Stage 3 IPv6 Dominance o Stage 4 IPv6 Transition Complete
Generally, a crisis management network is able to entirely upgrade a current IPv4 network to provide IPv6 services via a dual-stack network in Stage 2 and then slowly progress to Stages 3 and 4 as indicated in Figure 2. During Stage 2, when most applications are IPv6 dominant, operational and maintenance costs can be reduced on some networks by moving to Stage 3 and running backbone networks entirely on IPv6, while adding IPv4 backwards compatibility via v4 in v6 tunneling or translation mechanisms to the existing configuration from Stage 2. When designing a new network, if a new IPv6-only service is required, it can be implemented at a lower cost by jumping directly to Stage 3/4 if there are only limited or no legacy concerns.
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.
Stage 1: Limited Launch
Stage 1: Limited Launch
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.
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.
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.
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.
Bound, et al. Informational [Page 29] RFC 4852 IPv6 Enterprise Network Analysis April 2007
Bound, et al. Informational [Page 29] RFC 4852 IPv6 Enterprise Network Analysis April 2007
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.
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.
Stage 2: Dual-Stack Dominance
Stage 2: Dual-Stack Dominance
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.
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.
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.
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.
Stage 3: IPv6 Dominance
Stage 3: IPv6 Dominance
Applications are deployed specifically to use IPv6 as benefit; thus, network backbone and nodes use IPv6 and not IPv4, except where IPv4 is legacy.
Applications are deployed specifically to use IPv6 as benefit; thus, network backbone and nodes use IPv6 and not IPv4, except where IPv4 is legacy.
Bound, et al. Informational [Page 30] RFC 4852 IPv6 Enterprise Network Analysis April 2007
Bound, et al. Informational [Page 30] RFC 4852 IPv6 Enterprise Network Analysis April 2007
Authors' Addresses
Authors' Addresses
Jim Bound HP 110 Spitbrook Road Nashua, NH 03062 USA Phone: 603.465.3130 EMail: jim.bound@hp.com
Jim Bound HP 110 Spitbrook Road Nashua, NH 03062 USA Phone: 603.465.3130 EMail: 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 Competency Center 950, Route des Colles, BP027, 06901 Sophia Antipolis CEDEX FRANCE Phone: + 33492956285 EMail: 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
Tim Chown School of Electronics and Computer Science University of Southampton Southampton SO17 1BJ United Kingdom EMail: 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 Suite 500 Herndon, VA 20171 USA Phone: 703.561.5937 EMail: 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 MITRE Corporation 7515 Colshire Drive McLean, VA 22102-5708 USA Phone: 703-883-6469 EMail: sklynsma@mitre.org
Bound, et al. Informational [Page 31] RFC 4852 IPv6 Enterprise Network Analysis April 2007
Bound, et al. Informational [Page 31] RFC 4852 IPv6 Enterprise Network Analysis April 2007
Full Copyright Statement
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
Copyright (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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Bound, et al. Informational [Page 32]
バウンド、他 情報[32ページ]
一覧
スポンサーリンク
