RFC4057 日本語訳
4057 IPv6 Enterprise Network Scenarios. J. Bound, Ed.. June 2005. (Format: TXT=33454 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Bound, Ed. Request for Comments: 4057 Hewlett Packard Category: Informational June 2005
エド、ネットワークワーキンググループJ.を縛りました。コメントのために以下を要求してください。 4057年のヒューレットパッカードカテゴリ: 情報の2005年6月
IPv6 Enterprise Network Scenarios
IPv6企業網シナリオ
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 Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios. Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment. The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document.
このドキュメントはIPv6展開のために企業網の中でシナリオについて説明します。 それは、小さいセットの基本的な企業シナリオを定義して、企業の管理者がさらに彼らの展開シナリオを洗練するのを許容するために適切な質問を含んでいます。 IPv4ノードと、ネットワークとアプリケーション、およびIPv6展開のための基本のネットワークインフラ要件に関して共存でエンタープライズ展開要件について議論します。 さらなる分析が、どんな共存のテクニックとメカニズムが企業IPv6展開に必要であるかを決定するために本書では説明されたシナリオと要件は基礎になるでしょう。 その分析の結果は別々のドキュメントで発表されるでしょう。
Table of Contents
目次
1. Introduction................................................... 2 2. Terminology.................................................... 3 3. Base Scenarios................................................. 4 3.1. Base Scenarios Defined................................... 4 3.2. Scenarios Network Infrastructure Components.............. 5 3.3. Specific Scenario Examples............................... 8 3.4. Applicability Statement..................................10 4. Network Infrastructure Component Requirements..................10 4.1. DNS......................................................11 4.2. Routing..................................................11 4.3. Configuration of Hosts...................................11 4.4. Security.................................................11 4.5. Applications.............................................12 4.6. Network Management.......................................12 4.7. Address Planning.........................................12
1. 序論… 2 2. 用語… 3 3. シナリオを基礎づけてください… 4 3.1. 定義されたシナリオを基礎づけてください… 4 3.2. シナリオはインフラストラクチャコンポーネントをネットワークでつなぎます… 5 3.3. 特定のシナリオの例… 8 3.4. 適用性声明…10 4. インフラストラクチャコンポーネント要件をネットワークでつないでください…10 4.1. DNS…11 4.2. ルート設定…11 4.3. ホストの構成…11 4.4. セキュリティ…11 4.5. アプリケーション…12 4.6. ネットワークマネージメント…12 4.7. 計画を扱ってください…12
Bound Informational [Page 1] RFC 4057 IPv6 Enterprise Network Scenarios June 2005
[1ページ]制限された情報のRFC4057IPv6企業網シナリオ2005年6月
4.8. Multicast................................................12 4.9. Multihoming..............................................12 5. Security Considerations........................................12 6. Normative References...........................................13 Acknowledgements...................................................13
4.8. マルチキャスト…12 4.9. マルチホーミング…12 5. セキュリティ問題…12 6. 標準の参照…13の承認…13
1. Introduction
1. 序論
This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios. Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment. The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document.
このドキュメントはIPv6展開のために企業網の中でシナリオについて説明します。 それは、小さいセットの基本的な企業シナリオを定義して、企業の管理者がさらに彼らの展開シナリオを洗練するのを許容するために適切な質問を含んでいます。 IPv4ノードと、ネットワークとアプリケーション、およびIPv6展開のための基本のネットワークインフラ要件に関して共存でエンタープライズ展開要件について議論します。 さらなる分析が、どんな共存のテクニックとメカニズムが企業IPv6展開に必要であるかを決定するために本書では説明されたシナリオと要件は基礎になるでしょう。 その分析の結果は別々のドキュメントで発表されるでしょう。
The audience for this document is the enterprise network team considering deployment of IPv6. The document will be useful for enterprise teams that will have to determine the IPv6 transition strategy for their enterprise. It is expected those teams include members from management, network operations, and engineering. The scenarios presented provide an example set of cases the enterprise can use to build an IPv6 network scenario.
このドキュメントのための聴衆はIPv6の展開を考える企業網チームです。 ドキュメントはそれらの企業のためにIPv6変遷戦略を決定しなければならない企業チームの役に立ちます。 それらのチームが管理、ネットワーク操作、および工学からのメンバーを含めると予想されます。 提示されたシナリオは企業がIPv6ネットワークシナリオを造るのに使用できるケースの例のセットを提供します。
To frame the discussion, this document will describe a set of scenarios each with a network infrastructure. It is impossible to define every possible enterprise scenario that will apply to IPv6 adoption and transition.
議論を縁どるために、このドキュメントはネットワークインフラでそれぞれ1セットのシナリオについて説明するでしょう。 IPv6採用と変遷に適用されるあらゆる可能な企業シナリオを定義するのは不可能です。
Each enterprise will select the transition that best supports their business requirements. Any attempt to define a default or one-size- fits-all transition scenario, simply will not work. This document does not try to depict the drivers for adoption of IPv6 by an enterprise.
各企業はそれらのビジネスが要件であると最もよくサポートする変遷を選択するでしょう。 いずれも、デフォルトかすべてが1サイズぴったりの変遷シナリオを定義するのを試みて、絶対に働かないでしょう。 このドキュメントは企業によるIPv6の採用のためにドライバーについて表現しようとしません。
While it is difficult to quantify all the scenarios for an enterprise network team to plan for IPv6, it is possible to depict a set of abstract scenarios that will assist with planning. This document presents three base scenarios to be used as models by enterprises defining specific scenarios.
企業網チームがIPv6の計画を立てるようにすべてのシナリオを定量化するのが難しいのですが、計画を助ける1セットの抽象的なシナリオについて表現するのは可能です。 モデルとして特定のシナリオを定義する企業によって使用されるように、このドキュメントは3つのベースシナリオを提示します。
The first scenario assumes the enterprise decides to deploy IPv6 in conjunction with IPv4. The second scenario assumes the enterprise decides to deploy IPv6 because of a specific set of applications that
最初のシナリオは、企業が、IPv4に関連してIPv6を配布すると決めると仮定します。 2番目のシナリオは、企業が、特定のアプリケーションによるIPv6がそれであると配布すると決めると仮定します。
Bound Informational [Page 2] RFC 4057 IPv6 Enterprise Network Scenarios June 2005
[2ページ]制限された情報のRFC4057IPv6企業網シナリオ2005年6月
it wants to use over an IPv6 network. The third scenario assumes an enterprise is building a new network or restructuring an existing network and decides to deploy IPv6 as the predominant protocol within the enterprise coexisting with IPv4. This document then briefly reviews a set of network infrastructure components that must be analyzed, which are common to most enterprises.
それはIPv6の上でネットワークを使用したがっています。 3番目のシナリオは、企業が新しいネットワークを造るか、または既存のネットワークを再構築していると仮定して、IPv4と共存しながら支配的なプロトコルとして企業の中でIPv6を配布すると決めます。 そして、このドキュメントは簡潔に1セットの分析しなければならない、ほとんどの企業に共通のネットワークインフラの部品を見直します。
This document then provides three specific scenario examples using the network infrastructure components to depict the requirements. These are common enterprise deployment cases to depict the challenges for the enterprise to transition a network to IPv6.
そして、このドキュメントは、要件について表現するのにネットワークインフラコンポーネントを使用することで3つの特定のシナリオの例を提供します。 これらはIPv6への展開が企業のために変遷aネットワークに挑戦を説明するためにケースに入れる共同事業です。
Next, supporting legacy functions on the network (while the transition is in process), and the network infrastructure components requiring analysis by the enterprise are discussed. The interoperation with legacy functions within the enterprise will be required for all transition except possibly by a new network that will be IPv6 from inception. The network infrastructure components will depict functions in their networks that require consideration for IPv6 deployment and transition.
次に、レガシーをサポートするのはネットワークで機能します、そして、(変遷がプロセスにありますが)企業による分析を必要とするネットワークインフラコンポーネントについて議論します。 企業の中にレガシー機能があるinteroperationがことによるとIPv6になる新しいネットワーク以外のすべての変遷に始まりから必要でしょう。 ネットワークインフラコンポーネントはIPv6展開と変遷のための考慮を必要とするそれらのネットワークで機能について表現するでしょう。
Using the scenarios, network infrastructure components, and examples in this document, an enterprise can define its specific scenario requirements. Understanding the legacy functions and network infrastructure components required, the enterprise can determine the network operations required to deploy IPv6. The tools and mechanisms to support IPv6 deployment operations will require enterprise analysis. The analysis to determine the tools and mechanisms to support the scenarios will be presented in subsequent document(s).
本書ではシナリオ、ネットワークインフラコンポーネント、および例を使用して、企業は特定のシナリオ要件を定義できます。 レガシー機能とネットワークインフラコンポーネントが必要であることを理解していて、企業は、ネットワーク操作がIPv6を配布するのが必要であることを決定できます。 IPv6展開が操作であるとサポートする道具とメカニズムは企業分析を必要とするでしょう。 道具とメカニズムがシナリオをサポートすることを決定する分析はその後のドキュメントに提示されるでしょう。
2. Terminology
2. 用語
Enterprise Network - A network that has multiple internal links, one or more router connections to one or more Providers, and is actively managed by a network operations entity.
エンタープライズNetwork--1Providersには複数の内部のリンク、1つ以上のルータ接続があって、ネットワーク操作実体によって活発に経営されるネットワーク。
Provider - An entity that provides services and connectivity to the Internet or other private external networks for the enterprise network.
プロバイダー--企業網のためにインターネットか他の私設の外部のネットワークにサービスと接続性を提供する実体。
IPv6 Capable - A node or network capable of supporting both IPv6 and IPv4.
IPv6 Capable--IPv6とIPv4の両方をサポートすることができるノードかネットワーク。
IPv4 only - A node or network capable of supporting only IPv4.
IPv4専用--IPv4しかサポートすることができないノードかネットワーク。
Bound Informational [Page 3] RFC 4057 IPv6 Enterprise Network Scenarios June 2005
[3ページ]制限された情報のRFC4057IPv6企業網シナリオ2005年6月
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が本書では積み重ねるだけであるのを含意しません。
3. Base Scenarios
3. 基地のシナリオ
Three base scenarios are defined to capture the essential abstraction set for the enterprise. Each scenario has assumptions and requirements. This is not an exhaustive set of scenarios, but a base set of general cases.
3つのベースシナリオが、企業のために不可欠の抽象化セットを得るために定義されます。 各シナリオには、仮定と要件があります。 これは徹底的なセットのシナリオではなく、1人の基底集合の一般的なそうです。
Below we use the term network infrastructure to mean the software, network operations and configuration, and methods used to operate a network in an enterprise.
以下では、私たちが、ソフトウェア、ネットワーク操作、構成、およびメソッドが企業でネットワークを経営したことを意味するのにネットワークインフラという用語を使用します。
For the base scenarios it is assumed that any IPv6 node is IPv6 capable.
ベースシナリオにおいて、どんなIPv6ノードもできるIPv6であると思われます。
3.1. Base Scenarios Defined
3.1. シナリオが定義した基地
Scenario 1: 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.
シナリオ1: IPv4、IPv6の有能なホスト、およびネットワークインフラの広いスケール/総デュアルスタック展開。 既存のIPv4ネットワークがあるエンタープライズはそれらのIPv4ネットワークに関連してIPv6を配布したがっています。
Assumptions: The IPv4 network infrastructure used has an equivalent capability in IPv6.
仮定: ネットワークインフラが使用したIPv4には、同等機能がIPv6にあります。
Requirements: Do not disrupt existing IPv4 network infrastructure assumptions with IPv6. IPv6 should be equivalent or "better" than the network infrastructure in IPv4. However, it is understood that IPv6 is not required to solve current network infrastructure problems, not solved by IPv4. It may also not be feasible to deploy IPv6 on all parts of the network immediately.
要件: IPv6との既存のIPv4ネットワークインフラ仮定を中断しないでください。 IPv6は同等であるか「IPv4のネットワークインフラより良くあるべきです」。 しかしながら、IPv4によって解決されているのではなく、IPv6が現在のネットワークインフラ問題を解決する必要はないのが理解されています。 また、すぐにネットワークのすべての部分の上のIPv6を配布するのも可能でないかもしれません。
Scenario 2: Sparse IPv6 dual-stack deployment in IPv4 network infrastructure. Enterprise with an existing IPv4 network wants to deploy a set of particular IPv6 "applications" (application is voluntarily loosely defined here, e.g., peer to peer). The IPv6 deployment is limited to the minimum required to operate this set of applications.
シナリオ2: IPv4ネットワークインフラにおけるまばらなIPv6デュアルスタック展開。 既存のIPv4ネットワークがあるエンタープライズは1セットの特定のIPv6「アプリケーション」を配布したがっています(アプリケーションはここで自発的に緩く定義されます、例えば、ピアツーピア)。 IPv6展開はこのセットのアプリケーションを操作するのに必要である最小限に制限されます。
Assumptions: IPv6 software/hardware components for the application are available, and platforms for the application are IPv6 capable.
仮定: アプリケーションのためのIPv6ソフトウェア/ハードウェアの部品は利用可能です、そして、アプリケーションのためのプラットホームはできるIPv6です。
Bound Informational [Page 4] RFC 4057 IPv6 Enterprise Network Scenarios June 2005
[4ページ]制限された情報のRFC4057IPv6企業網シナリオ2005年6月
Requirements: Do not disrupt IPv4 infrastructure.
要件: IPv4インフラストラクチャを混乱させないでください。
Scenario 3: IPv6-only network infrastructure with some IPv4-capable nodes/applications needing to communicate over the IPv6 infrastructure. Enterprise deploying a new network or restructuring an existing network, decides IPv6 is the basis for most network communication. Some IPv4 capable nodes/applications will need to communicate over that infrastructure.
シナリオ3: IPv6だけがいくつかのIPv4できるノード/アプリケーションが、IPv6インフラストラクチャの上で交信する必要があるインフラストラクチャをネットワークでつなぎます。 企業、新しいネットワークか企業再構築が既存のネットワークであると配布して、IPv6がほとんどのネットワークコミュニケーションの基礎であると決めます。 いくつかのIPv4のできるノード/アプリケーションが、そのインフラストラクチャの上で交信する必要があるでしょう。
Assumptions: Required IPv6 network infrastructure is available, or available over some defined timeline, supporting the enterprise plan.
仮定: 企業プランをサポートして、必要なIPv6ネットワークインフラは、利用可能であるか、または何らかの定義されたスケジュールの上で利用可能です。
Requirements: Interoperation and Coexistence with IPv4 network infrastructure and applications are required for communications.
要件: IPv4ネットワークインフラとアプリケーションがあるInteroperationとCoexistenceがコミュニケーションに必要です。
3.2. Scenarios Network Infrastructure Components
3.2. シナリオネットワークインフラコンポーネント
This section defines the network infrastructure that exists for the above enterprise scenarios. This is not an exhaustive list, but a base list that can be expanded by the enterprise for specific deployment scenarios. The network infrastructure components are presented as functions that the enterprise must analyze as part of defining their specific scenario. The analysis of these functions will identify actions that are required to deploy IPv6.
このセクションは上の企業シナリオのために存在するネットワークインフラを定義します。 これは完全なりストではなく、企業が特定の展開シナリオのために広げることができるベースリストです。 ネットワークインフラコンポーネントは企業がそれらの特定のシナリオを定義する一部として分析しなければならない機能として提示されます。 これらの機能の分析はIPv6を配布するのに必要である動作を特定するでしょう。
Network Infrastructure Component 1 Enterprise Provider Requirements - Is external connectivity required? - One site vs. multiple sites and are they within different geographies? - Leased lines or VPNs? - If multiple sites, how is the traffic exchanged securely? - How many global IPv4 addresses are available to the enterprise? - What is the IPv6 address assignment plan available from the provider? - What prefix delegation is required by the Enterprise? - Will the enterprise be multihomed? - What multihoming techniques are available from the provider? - Will clients within the enterprise be multihomed? - Does the provider offer any IPv6 services? - Which site-external IPv6 routing protocols are required? - Is there an external data center to the enterprise, such as servers located at the Provider? - Is IPv6 available using the same access links as IPv4, or different ones?
ネットワークInfrastructure Component1エンタープライズProvider Requirements--外部の接続性が必要ですか? - 1つは、倍数に対してサイトを位置させて、異なった地形の中の彼らですか? - 専用線ですかそれともVPNsですか? - 複数のサイトであるなら、どのようにしっかりとトラフィックを交換しますか? - いくつのグローバルなIPv4アドレスが企業に利用可能ですか? - プロバイダーから利用可能なIPv6アドレス課題プランは何ですか? - どんな接頭語委譲がエンタープライズによって必要とされますか? - 企業は「マルチ-家へ帰」るでしょうか? - どんなマルチホーミングのテクニックがプロバイダーから利用可能ですか? - 企業の中のクライアントは「マルチ-家へ帰」るでしょうか? - プロバイダーは何かIPv6サービスを提供しますか? - どのサイト外部のIPv6ルーティング・プロトコルが必要ですか? - Providerでの企業であって、サーバなどのような位置への外部のデータセンターがありますか? - IPv6は、IPv4と同じアクセスリンク、または異なったものを使用することで利用可能ですか?
Bound Informational [Page 5] RFC 4057 IPv6 Enterprise Network Scenarios June 2005
[5ページ]制限された情報のRFC4057IPv6企業網シナリオ2005年6月
Network Infrastructure Component 2 Enterprise Application Requirements - List of applications in use? - Which applications must be moved to support IPv6 first? - Can the application be upgraded to IPv6? - Will the application have to support both IPv4 and IPv6? - Do the enterprise platforms support both IPv4 and IPv6? - Do the applications have issues with NAT v4-v4 and NAT v4-v6? - Do the applications need globally routable IP addresses? - Do the applications care about dependency between IPv4 and IPv6 addresses? - Are applications run only on the internal enterprise network?
ネットワークInfrastructure Component2エンタープライズApplication Requirements--使用中のアプリケーションのリスト? - 最初にIPv6をサポートするので、どのアプリケーションを動かさなければなりませんか? - アプリケーションはIPv6にアップグレードできますか? - アプリケーションはIPv4とIPv6の両方をサポートしなければならないでしょうか? - 企業プラットホームはIPv4とIPv6の両方をサポートしますか? - アプリケーションには、NAT v4-v4とNAT v4-v6の問題がありますか? - アプリケーションは発送可能IPアドレスをグローバルに必要としますか? - アプリケーションはIPv4とIPv6アドレスの間の依存を心配しますか? - アプリケーションは内部の企業網だけで実行されますか?
Network Infrastructure Component 3 Enterprise IT Department Requirements - Who "owns"/"operates" the network: in house or outsourced? - Is working remotely (i.e., through VPNs) supported? - Are inter-site communications required? - Is network mobility used or required for IPv6? - What are the requirements of the IPv6 address plan? - Is there a detailed asset management database, including hosts, IP/MAC addresses, etc.? - What is the enterprise's approach to numbering geographically separate sites that have their own Service Providers? - What will be the internal IPv6 address assignment procedure? - What site internal IPv6 routing protocols are required? - What will be the IPv6 Network Management policy/procedure? - What will be the IPv6 QOS policy/procedure? - What will be the IPv6 Security policy/procedure? - What is the IPv6 training plan to educate the enterprise? - What network operations software will be impacted by IPv6? - DNS - Management (SNMP & ad-hoc tools) - Enterprise Network Servers Applications - Mail Servers - High Availability Software for Nodes - Directory Services - Are all these software functions upgradeable to IPv6? - If not upgradeable, then what are the workarounds? - Do any of the software functions store, display, or allow input of IP addresses? - Other services (e.g., NTP, etc.)
ネットワークInfrastructure Component3エンタープライズIT部のRequirementsネットワークを「所有している」か、または(「操作します」): 社内かそれとも社外調達されていますか? - 離れて(すなわち、VPNsを通して)働いているのはサポートされますか? - 相互サイトコミュニケーションが必要ですか? - ネットワークの移動性が、IPv6に使用されますか、必要ですか? - IPv6アドレスプランの要件は何ですか? - ホスト、IP/MACアドレスなどを含む詳細な資産管理データベースがありますか?(それら自身のService Providersを持っている地理的に別々のサイトに付番することへの企業のアプローチは何です) - 内部のIPv6アドレス課題手順は何になるでしょうか? - どんなサイトの内部のIPv6ルーティング・プロトコルが必要ですか? - IPv6 Network Management方針/手順は何になるでしょうか? - IPv6 QOS方針/手順は何になるでしょうか? - IPv6 Security方針/手順は何になるでしょうか? - 企業を教育するIPv6トレーニング計画は何ですか? - どんなネットワーク操作ソフトウェアがIPv6によって影響を与えられるでしょうか? - DNS--経営者側(SNMPと臨時の道具)(エンタープライズNetwork Servers Applications)はServers(Nodesのための高いAvailability Software)にディレクトリサービスを郵送します--これらのすべてのソフトウェア機能がIPv6にアップグレード可能ですか? - アップグレード可能でないなら、回避策は何ですか? - ソフトウェア機能のどれかは、IPアドレスの入力を保存しますか、表示しますか、または許しますか? - 他のサービス(例えば、NTPなど)
Bound Informational [Page 6] RFC 4057 IPv6 Enterprise Network Scenarios June 2005
[6ページ]制限された情報のRFC4057IPv6企業網シナリオ2005年6月
- What network hardware will be impacted by IPv6? - Routers/switches - Printers/Faxes - Firewalls - Intrusion Detection - Load balancers - VPN Points of Entry/Exit - Security Servers and Services - Network Interconnect for Platforms - Intelligent Network Interface Cards - Network Storage Devices - Are all these hardware functions upgradeable to IPv6? - If not, what are the workarounds? - Do any of the hardware functions store, display, or allow input of IP addresses? - Are the nodes moving within the enterprise network? - Are the nodes moving outside and inside the enterprise network?
- どんなネットワークハードウェアがIPv6によって影響を与えられるでしょうか? - ルータ/スイッチ--プリンタ/ファックス--ファイアウォール負荷分散装置--Entry/出口のVPN Points--セキュリティServersとServices--PlatformsのためのネットワークInterconnect--知的なNetwork Interface Cards(侵入Detection)--ネットワークStorage Devices--これらのすべてのハード性能がIPv6にアップグレード可能ですか? - まして、回避策は何ですか? - ハード性能のどれかは、IPアドレスの入力を保存しますか、表示しますか、または許しますか? - ノードは企業網の中で移行していますか? - ノードは企業網の外と、そして、企業網の中で移行していますか?
Network Infrastructure Component 4 Enterprise Network Management System - Performance Management required? - Network Management applications required? - Configuration Management required? - Policy Management and Enforcement required? - Security Management required? - Management of Transition Tools and Mechanisms? - What new considerations does IPv6 create for Network Management?
ネットワークInfrastructure Component4エンタープライズNetwork Management System--Managementが必要としたパフォーマンス? - Managementアプリケーションが必要としたネットワーク? - Managementが必要とした構成? - ManagementとEnforcementが必要とした方針? - Managementが必要としたセキュリティ? - 変遷ツールとメカニズムの管理? - IPv6はNetwork Managementのためにどんな新しい問題を作成しますか?
Network Infrastructure Component 5 Enterprise Network Interoperation and Coexistence - What platforms are required to be IPv6 capable? - What network ingress and egress points to the site are required to be IPv6 capable? - What transition mechanisms are needed to support IPv6 network operations? - What policy/procedures are required to support the transition to IPv6? - What policy/procedures are required to support interoperation with legacy nodes and applications?
ネットワークInfrastructure Component5エンタープライズのNetwork InteroperationとCoexistence--どんなプラットホームが、できるIPv6になるのに必要ですか? - サイトへのどんなネットワークイングレスと出口ポイントができるIPv6であることが必要ですか? - どんな変遷メカニズムがネットワーク操作をIPv6にサポートするのが必要ですか? - どんな方針/手順が、IPv6への変遷をサポートするのに必要ですか? - どんな方針/手順が、レガシーノードとアプリケーションでinteroperationをサポートするのに必要ですか?
Bound Informational [Page 7] RFC 4057 IPv6 Enterprise Network Scenarios June 2005
[7ページ]制限された情報のRFC4057IPv6企業網シナリオ2005年6月
3.3. Specific Scenario Examples
3.3. 特定のシナリオの例
This section presents a set of base scenario examples and is not an exhaustive list of examples. These examples were selected to provide further clarity for base scenarios within an enterprise of a less abstract nature. The example networks may use the scenarios depicted in 3.1 and the infrastructure components in 3.2, but there are no direct implications specifically within these example networks. Section 3.1, 3.2, and 3.3 should be used in unison for enterprise IPv6 deployment planning and analysis.
このセクションは、1セットのベースシナリオの例を提示して、例に関する完全なりストではありません。 これらの例がそれほど抽象的でない自然の企業の中でさらなる明快をベースシナリオに提供するのが選択されました。 例のネットワークは3.2に3.1で表現されたシナリオとインフラストラクチャコンポーネントを使用するかもしれませんが、特にこれらの例のネットワークの中にどんなダイレクト含意もありません。 セクション3.1、3.2、および3.3は企業IPv6展開計画と分析に一斉に使用されるべきです。
Example Network A:
例のネットワークA:
A distributed network across a number of geographically separated campuses.
多くの地理的に切り離されたキャンパスの向こう側の分配されたネットワーク。
- External network operation. - External connectivity required. - Multiple sites connected by leased lines. - Provider independent IPv4 addresses. - ISP does not offer IPv6 service. - Private Leased Lines no Service Provider used.
- 外部のネットワーク操作。 - 外部の接続性が必要です。 - 複数のサイトが専用線で接続しました。 - プロバイダーの独立しているIPv4アドレス。 - ISPはサービスをIPv6に提供しません。 - どんなService Providerも使用しなかった個人的なLeased線。
Applications run by the enterprise:
アプリケーションは企業で稼働します:
- Internal Web/Mail. - File servers. - Java applications. - Collaborative development tools. - Enterprise Resource applications. - Multimedia applications. - Financial Enterprise applications. - Data Warehousing applications.
- 内部のウェブ/メール。 - ファイルサーバー。 - Javaアプリケーション。 - 協力的な開発ツール。 - エンタープライズResourceアプリケーション。 - マルチメディア応用。 - 財政的なエンタープライズアプリケーション。 - データWarehousingアプリケーション。
Internal network operation:
内部のネットワーク操作:
- In house operation of the network. - DHCP (v4) is used for all desktops; servers use static address configuration. - The DHCP server that updates naming records for dynamic desktops uses dynamic DNS. - A web based tool is used to enter name to address mappings for statically addressed servers. - Network management is done using SNMP. - All routers and switches are upgradeable to IPv6. - Existing firewalls can be upgraded to support IPv6 rules.
- ネットワークの家の操作で。 - DHCP(v4)はすべてのデスクトップに使用されます。 サーバは静的なアドレス構成を使用します。 - ダイナミックなデスクトップのための命名記録をアップデートするDHCPサーバはダイナミックなDNSを使用します。 - ウェブに基づいているツールは、静的に扱われたサーバのためのマッピングを扱うために名前を入れるのに使用されます。 - ネットワークマネージメントはSNMPを使用し終わっています。 - すべてのルータとスイッチはIPv6にアップグレード可能です。 - 既存のファイアウォールは、IPv6に規則をサポートするためにアップグレードできます。
Bound Informational [Page 8] RFC 4057 IPv6 Enterprise Network Scenarios June 2005
[8ページ]制限された情報のRFC4057IPv6企業網シナリオ2005年6月
- Load balancers do not support IPv6, upgrade path unclear. - Peer-2-Peer Application and Security supported. - IPv4 Private address space is used within the enterprise.
- 負荷分散装置は不明瞭な状態でIPv6、アップグレード経路をサポートしません。 - ApplicationとSecurityがサポートした同輩2同輩。 - IPv4兵士のアドレス空間は企業の中で使用されます。
Example Network B:
例のネットワークB:
A bank running a large network supporting online transaction processing (OLTP) across a distributed multi-sited network, with access to a central database on a remote network from the OLTP network.
主要なデータベースへのアクセスでOLTPネットワークからリモートネットワークに分配されたマルチ位置しているネットワークの向こう側にオンライン・トランザクションが処理(OLTP)であるとサポートする大きいネットワークを経営している銀行。
- External connectivity not required. - Multiple sites connected by VPN. - Multiple sites connected by Native IP protocol. - Private address space used with NAT. - Connections to private exchanges.
- 外部の接続性は必要ではありません。 - 複数のサイトがVPNで接続しました。 - ネイティブのIPによってつなげられた複数のサイトが議定書を作ります。 - NATと共に使用されるプライベート・アドレススペース。 - 私設交換機へのコネクションズ。
Applications in the enterprise:
企業におけるアプリケーション:
- ATM transaction application. - ATM management application. - Financial Software and Database. - Part of the workforce is mobile and requires access to the enterprise from outside networks.
- ATMトランザクションアプリケーション。 - ATM管理アプリケーション。 - 財政的なソフトウェアとデータベース。 - 従業員の一部が、モバイルであり、ネットワークの外から企業へのアクセスを必要とします。
Internal Network Operation:
内部のネットワーク操作:
- Existing firewalls can be upgraded to support IPv6 rules. - Load balancers do not support IPv6, upgrade path unclear. - Identifying and managing each node's IP address.
- 既存のファイアウォールは、IPv6に規則をサポートするためにアップグレードできます。 - 負荷分散装置は不明瞭な状態でIPv6、アップグレード経路をサポートしません。 - 各ノードのIPアドレスを特定して、管理します。
Example Network C:
例のネットワークC:
A Security Defense, Emergency, or other Mission Critical network operation:
Security Defense、Emergency、または他のMission Criticalが操作をネットワークでつなぎます:
- External network required at secure specific points. - Network is its own Internet. - Network must be able to absorb ad-hoc creation of sub-networks. - Entire parts of the network are completely mobile. - All nodes on the network can be mobile (including routers). - Network high-availability is mandatory. - Network must be able to be managed from ad-hoc location. - All nodes must be able to be configured from stateless mode.
- 外部のネットワークが安全な特定のポイントで必要です。 - ネットワークはそれ自身のインターネットです。 - ネットワークはサブネットワークの臨時の作成を吸収できなければなりません。 - ネットワークの全体の部分は完全にモバイルです。 - ネットワークのすべてのノードモバイルである場合があります(ルータを含んでいて)。 - ネットワーク高可用性は義務的です。 - ネットワークは臨時の位置から対処できなければなりません。 - すべてのノードが状態がないモードから構成できなければなりません。
Bound Informational [Page 9] RFC 4057 IPv6 Enterprise Network Scenarios June 2005
[9ページ]制限された情報のRFC4057IPv6企業網シナリオ2005年6月
Applications run by the Enterprise:
アプリケーションはエンタープライズで稼働します:
- Multimedia streaming of audio, video, and data for all nodes. - Data computation and analysis on stored and created data. - Transfer of data coordinate points to sensor devices. - Data and Intelligence gathering applications from all nodes.
- すべてのノードのためのオーディオ、ビデオ、およびデータのマルチメディアストリーミング。 - 保存されて作成されたデータのデータ計算と分析。 - データ転送座標はセンサー・デバイスを示します。 - すべてのノードからのデータとIntelligence集会アプリケーション。
Internal Network Operations:
内部のネットワークオペレーション:
- All packets must be secured end-2-end with encryption. - Intrusion Detection exists on all network entry points. - Network must be able to bolt on to the Internet to share bandwidth as required from Providers. - VPNs can be used, but NAT can never be used. - Nodes must be able to access IPv4 legacy applications over IPv6 network.
- 終わり2が暗号化で終わった状態で、すべてのパケットを機密保護しなければなりません。 - 侵入Detectionはすべてのネットワークエントリー・ポイントの上に存在しています。 - ネットワークは、必要に応じてProvidersから帯域幅を共有するためにインターネットに飛び出すことができなければなりません。 - VPNsを使用できますが、NATは決して使用できません。 - ノードはIPv6の上のIPv4レガシーアプリケーションがネットワークでつなぐアクセスにできるに違いありません。
3.4. Applicability Statement
3.4. 適用性証明
The specific network scenarios selected are chosen to depict a base set of examples, and to support further analysis of enterprise networks. This is not a complete set of network scenarios. Though Example Network C is a verifiable use case, currently the scenario defines an early adopter of enterprise networks transitioning to IPv6 as a predominant protocol strategy (i.e., IPv6 Routing, Applications, Security, and Operations), viewing IPv4 as legacy operations immediately in the transition strategy, and at this time may not be representative of many initial enterprise IPv6 deployments. Each enterprise planning team will need to make that determination as IPv6 deployment evolves.
選択された特定のネットワークシナリオは、基底集合について表現するために例について選ばれていて、企業網の分析をサポートに促進します。 これは完全なセットのネットワークシナリオではありません。 Example Network Cですが、レガシー操作が変遷戦略と、このときすぐに多くの初期の企業IPv6展開を代表しないかもしれないので、現在、証明可能な使用はケース、支配的なプロトコル戦略(すなわち、IPv6ルート設定、Applications、Security、およびOperations)としてIPv6に移行する企業網の初期採用者を定義して、IPv4を見るシナリオですか? それぞれの企業計画チームは、IPv6展開が発展するときそれを決断にする必要があるでしょう。
4. Network Infrastructure Component Requirements
4. ネットワークインフラコンポーネント要件
The enterprise will need to determine which network infrastructure components require enhancements or need to be added for deployment of IPv6. This infrastructure will need to be analyzed and understood as a critical resource to manage. The list in this section is not exhaustive, but contains the essential network infrastructure components for the enterprise to consider before beginning to define more fine-tuned requirements such as QOS, PKI, or Bandwidth requirements for IPv6. The components are only identified here and their details will be discussed in the analysis document for enterprise scenarios. References currently available for components are provided.
企業は、どのネットワークインフラコンポーネントが増進を必要とするかを決定するか、またはIPv6の展開のために加えられるのが必要である必要があるでしょう。 このインフラストラクチャは、分析されるのが必要であり、重要な資源として管理するのを分かりました。 このセクションのリストは、徹底的ではありませんが、IPv6のためのQOS、PKI、またはBandwidth要件などの、より微調整された要件を定義し始める前に企業が考える不可欠のネットワークインフラコンポーネントを含んでいます。 コンポーネントはここで特定されるだけです、そして、企業シナリオのための解析書でそれらの詳細について議論するでしょう。 現在コンポーネントに利用可能な参照を提供します。
Bound Informational [Page 10] RFC 4057 IPv6 Enterprise Network Scenarios June 2005
[10ページ]制限された情報のRFC4057IPv6企業網シナリオ2005年6月
4.1. DNS
4.1. DNS
DNS will now have to support both IPv4 and IPv6 DNS records and the enterprise will need to determine how the DNS is to be managed and accessed, and secured. The range of DNS operational issues is beyond the scope of this document. However, DNS resolution and transport solutions for both IP protocols are influenced by the chosen IPv6 deployment scenario. Users need to consider all current DNS IPv4 operations and determine if those operations are supported for IPv6 [DNSV6].
DNSは現在、IPv4とIPv6 DNSの両方に記録をサポートしなければならなくて、企業は、DNSがどのように管理されて、アクセスされて、固定されることになっているかを決定する必要があるでしょう。 DNSの操作上の問題の範囲はこのドキュメントの範囲を超えています。 しかしながら、両方のIPプロトコルのためのDNS解決と輸送対策は選ばれたIPv6展開シナリオによって影響を及ぼされます。 ユーザは、すべての現在のDNS IPv4操作を考えて、それらの操作がIPv6[DNSV6]のためにサポートされるかどうか決定する必要があります。
4.2. Routing
4.2. ルート設定
Interior and Exterior routing will be required to support both IPv4 and IPv6 routing protocols, and the coexistence of IPv4 and IPv6 over the enterprise network. The enterprise will need to define the IPv6 routing topology, any ingress and egress points to provider networks, and transition mechanisms that they wish to use for IPv6 adoption. The enterprise will also need to determine what IPv6 transition mechanisms are supported by their upstream providers.
内部とExteriorルーティングが、企業網の上でIPv4とIPv6の両方がルーティング・プロトコルと、IPv4とIPv6の共存であるとサポートするのに必要でしょう。 企業は、それらがIPv6採用に使用したがっているプロバイダーネットワーク、および変遷メカニズムと任意なIPv6ルーティングトポロジー、イングレス、および出口点を定義する必要があるでしょう。 また、企業は、どんなIPv6変遷メカニズムがそれらの上流のプロバイダーによってサポートされるかを決定する必要があるでしょう。
4.3. Configuration of Hosts
4.3. ホストの構成
IPv6 introduces the concept of stateless autoconfiguration in addition to stateful autoconfiguration, for the configuration of hosts within the enterprise. The enterprise will have to determine the best method of host configuration for its network, if it will use stateless or stateful autoconfiguration, and how autoconfiguration will operate for DNS updates. It will also need to determine how prefix delegation will be done from their upstream provider and how those prefixes will be cascaded down to the enterprise IPv6 network. The policy for DNS or choice of autoconfiguration is out of scope for this document [CONF, DHCPF, DHCPL].
IPv6はホストの構成のために企業の中でstateful自動構成に加えた状態がない自動構成の概念を紹介します。 企業はネットワークのためにホスト構成の最も良いメソッドを決定しなければならないでしょう、状態がないかstatefulな自動構成と、自動構成がDNSアップデートのためにどう作動するかを使用するなら。 また、それは、どのように接頭語委譲をそれらの上流のプロバイダーとそれらの接頭語がどうどっと落すだろうか、そして、企業IPv6ネットワークまでするかを決定する必要があるでしょう。 このドキュメント[CONF、DHCPF、DHCPL]のための範囲の外にDNSのための方針か自動構成の選択があります。
4.4. Security
4.4. セキュリティ
Current existing mechanisms used for IPv4 to provide security need to be supported for IPv6 within the enterprise. IPv6 should create no new security concerns for IPv4. The entire security infrastructure currently used in the enterprise needs to be analyzed against IPv6 deployment effect to determine what is supported in IPv6. Users should review other current security IPv6 network infrastructure work in the IETF and within the industry. Users will have to work with their platform and software providers to determine which IPv6 security network infrastructure components are supported. The security filters and firewall requirements for IPv6 need to be determined by the enterprise. The policy choice of users for security is beyond the scope of this document.
IPv4がセキュリティを提供するのに使用される現在の既存のメカニズムは、IPv6のために企業の中でサポートされる必要があります。 IPv6はIPv4のためにどんな新しい安全上の配慮も作成するはずがありません。 現在企業に使用されている全体のセキュリティインフラストラクチャは、何がIPv6でサポートされるかを決定するためにIPv6展開効果に対して分析される必要があります。 ユーザはIETFと産業の中で他の現在のセキュリティIPv6ネットワークインフラ仕事を見直すべきです。 ユーザは、どのIPv6セキュリティネットワークインフラの部品が支えられるかを決定するために彼らのプラットホームとソフトの提供者で働かなければならないでしょう。 IPv6のためのセキュリティフィルタとファイアウォール要件は、企業によって決定される必要があります。 セキュリティのためのユーザの政治的選択はこのドキュメントの範囲を超えています。
Bound Informational [Page 11] RFC 4057 IPv6 Enterprise Network Scenarios June 2005
[11ページ]制限された情報のRFC4057IPv6企業網シナリオ2005年6月
4.5. Applications
4.5. アプリケーション
Existing applications will need to be ported or provide proxies to support both IPv4 and IPv6 [APPS].
既存のアプリケーションは、IPv4とIPv6の両方[APPS]をサポートするために移植するか、またはプロキシを提供する必要があるでしょう。
4.6. Network Management
4.6. ネットワークマネージメント
The addition of IPv6 network infrastructure components will need to be managed by the enterprise network operations center. Users will need to work with their network management platform providers to determine what is supported for IPv6 while planning IPv6 adoption, and which tools are available to monitor the network. Network management will not need to support both IPv4 and IPv6 and view nodes as dual stacks.
IPv6ネットワークインフラの部品の追加は、企業網操作センターによって管理される必要があるでしょう。 ユーザは、何がIPv6のためにIPv6採用を計画している間、サポートされるか、そして、どのツールがネットワークをモニターするために利用可能であるかを決定するために彼らのネットワークマネージメントプラットホームプロバイダーで働く必要があるでしょう。 ネットワークマネージメントは、IPv4とIPv6の両方をサポートして、ノードをデュアルスタックであるとみなす必要はないでしょう。
4.7. Address Planning
4.7. アドレス計画
The address space within the enterprise will need to be defined and coordinated with the routing topology of the enterprise network. It is also important to identify the pool of IPv4 address space available to the enterprise to assist with IPv6 transition methods.
企業の中のアドレス空間は、企業網のルーティングトポロジーで定義されて、調整される必要があるでしょう。 また、IPv6変遷メソッドを助けるために企業に利用可能なIPv4アドレス空間のプールを特定するのも重要です。
4.8. Multicast
4.8. マルチキャスト
Enterprises utilizing IPv4 Multicast services will need to consider how these services may be implemented operationally in an IPv6- enabled environment.
IPv4 Multicastサービスを利用するエンタープライズは、これらのサービスがIPv6の可能にされた環境で操作上どのように実装されるかもしれないかを考える必要があるでしょう。
4.9. Multihoming
4.9. マルチホーミング
At this time, current IPv6 allocation policies are mandating the allocation of IPv6 address space from the upstream provider. If an enterprise is multihomed, the enterprise will have to determine how it wishes to support multihoming. This also is an area of study within the IETF and work in progress.
このとき、現在のIPv6配分方針は上流のプロバイダーからIPv6アドレス空間の配分を強制することです。 企業が「マルチ-家へ帰」ると、企業は、それがどのようにマルチホーミングをサポートしたがっているかを決定しなければならないでしょう。 また、これは進行中のIETFと仕事の中の研究領域です。
5. Security Considerations
5. セキュリティ問題
This document lists scenarios for the deployment of IPv6 in enterprise networks, and there are no security considerations associated with making such a list.
このドキュメントは企業網における、IPv6の展開のためにシナリオを記載します、そして、そのようなリストを作ると関連しているどんなセキュリティ問題もありません。
There will be security considerations for the deployment of IPv6 in each of these scenarios, but they will be addressed in the document that includes the analysis of each scenario.
それぞれのこれらのシナリオにおける、IPv6の展開のためのセキュリティ問題があるでしょうが、それらはそれぞれのシナリオの分析を含んでいるドキュメントで扱われるでしょう。
Bound Informational [Page 12] RFC 4057 IPv6 Enterprise Network Scenarios June 2005
[12ページ]制限された情報のRFC4057IPv6企業網シナリオ2005年6月
6. Normative References
6. 引用規格
[DNSV6] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", Work in Progress.
[DNSV6] ジュランド、A.、Ihren、J.、およびSavolaと、「IPv6 DNSの操作上の問題と問題」が進行中で扱うP.。
[CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[CONF] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
[DHCPF] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003
[DHCPF]Droms(R.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月
[DHCPL] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[DHCPL] Nikander、P.、ケンフ、J.、およびE.Nordmark、「IPv6隣人発見(ノースダコタ)信頼モデルと脅威」(RFC3756)は2004がそうするかもしれません。
[APPS] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[アプリケーション]はよじ登られます、M K.、商館、Y-G.、Hagino、J.、Savola、P.とE.カストロ、「IPv6変遷のアプリケーション局面」RFC4038、2005年3月。
Acknowledgements
承認
The Authors would like to acknowledge contributions from the following: IETF v6ops Working Group, Alan Beard, Brian Carpenter, Alain Durand, Bob Hinden, and Pekka Savola.
Authorsは以下から貢献を承諾したがっています: IETF v6ops作業部会、アランBeard、ブライアンCarpenter、アラン・ジュランド、ボブHinden、およびペッカSavola。
Bound Informational [Page 13] RFC 4057 IPv6 Enterprise Network Scenarios June 2005
[13ページ]制限された情報のRFC4057IPv6企業網シナリオ2005年6月
Authors' Addresses
作者のアドレス
Yanick Pouffary (Chair of Design Team) HP Competency Center 950, Route des Colles, BP027, 06901 Sophia Antipolis CEDEX FRANCE
Yanick Pouffary(Design Teamの議長)HP Competencyセンター950、Route desコリース、BP027、06901ソフィア・Antipolis CEDEXフランス
Phone: + 33492956285 EMail: Yanick.pouffary@hp.com
以下に電話をしてください。 + 33492956285メール: Yanick.pouffary@hp.com
Jim Bound (Editor) Hewlett Packard 110 Spitbrook Road Nashua, NH 03062 USA
ジムRoadナッシュア、(エディタ)制限されたヒューレットパッカード110Spitbrookニューハンプシャー03062米国
Phone: (603) 884-0062 EMail: jim.bound@hp.com
以下に電話をしてください。 (603) 884-0062 メールしてください: jim.bound@hp.com
Marc Blanchet Viagenie inc. 2875 boul. Laurier, bur. 300 Ste-Foy, Quebec, G1V 2M2 Canada
マークBlanchet Viagenie inc。 2875boul。 ローリエ、いが。 300 Ste-フォイ、ケベック、G1V 2M2カナダ
EMail: Marc.Blanchet@viagenie.qc.ca
メール: Marc.Blanchet@viagenie.qc.ca
Tony Hain Cisco Systems 500 108th Ave. N.E. Suite 400 Bellevue, WA 98004 USA
トニーハインシスコシステムズ500第108Ave。 東北Suite400ワシントン98004ベルビュー(米国)
EMail: alh-ietf@tndh.net
メール: alh-ietf@tndh.net
Paul Gilbert Cisco Systems 1 Penn Plaza, 5th floor, NY, NY 10119 USA
ポール・ギルバートシスコシステムズ1ペンPlaza、5階、ニューヨーク、ニューヨーク10119米国
Phone: (212) 714-4334 EMail: pgilbert@cisco.com
以下に電話をしてください。 (212) 714-4334 メールしてください: pgilbert@cisco.com
Bound Informational [Page 14] RFC 4057 IPv6 Enterprise Network Scenarios June 2005
[14ページ]制限された情報のRFC4057IPv6企業網シナリオ2005年6月
Margaret Wasserman ThingMagic One Broadway Cambridge, MA 02142 USA
マーガレットワッサーマンThingMagic1ブロードウェイMA02142ケンブリッジ(米国)
Phone: (617) 758-4177 EMail: margaret@thingmagic.com
以下に電話をしてください。 (617) 758-4177 メールしてください: margaret@thingmagic.com
Jason Goldschmidt Sun Microsystems M/S UMPK17-103 17 Network Circle Menlo Park, CA 94025 USA
ジェイソンゴールドシュミットサン・マイクロシステムズM/S UMPK17-103 17ネットワーク円のカリフォルニア94025メンローパーク(米国)
Phone: (650) 786-3502 Fax: (650) 786-8250 EMail: jason.goldschmidt@sun.com
以下に電話をしてください。 (650) 786-3502 Fax: (650) 786-8250 メールしてください: jason.goldschmidt@sun.com
Aldrin Isaac Bloomberg L.P. 499 Park Avenue New York, NY 10022 USA
アルドリンイサクブルームバーグL.P.499パーク・アベニューニューヨーク10022ニューヨーク(米国)
Phone: (212) 940-1812 EMail: aisaac@bloomberg.com
以下に電話をしてください。 (212) 940-1812 メールしてください: aisaac@bloomberg.com
Tim Chown School of Electronics and Computer Science University of Southampton Southampton SO17 1BJ United Kingdom
エレクトロニクスのティムChown学校とサウサンプトンサウサンプトンSO17 1BJイギリスのコンピュータサイエンス大学
EMail: tjc@ecs.soton.ac.uk
メール: tjc@ecs.soton.ac.uk
Bound Informational [Page 15] RFC 4057 IPv6 Enterprise Network Scenarios June 2005
[15ページ]制限された情報のRFC4057IPv6企業網シナリオ2005年6月
Jordi Palet Martinez Consulintel San Jose Artesano, 1 Madrid, SPAIN
ジョルディ・殻マルチネス・ConsulintelサンノゼArtesano、1マドリード(スペイン)
Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 EMail: jordi.palet@consulintel.es
以下に電話をしてください。 +34 91 151、81 99、Fax: +34 91 151 81 98はメールされます: jordi.palet@consulintel.es
Fred Templin Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
フレッドテンプリンノキア313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: (650) 625-2331 EMail: ftemplin@iprg.nokia.com
以下に電話をしてください。 (650) 625-2331 メールしてください: ftemplin@iprg.nokia.com
Roy Brabson IBM PO BOX 12195 3039 Cornwallis Road Research Triangle Park, NC 27709 USA
ロイBrabson IBM PO BOX12195 3039コーンウォリス道路リサーチトライアングル公園、NC27709米国
Phone: (919) 254-7332 EMail: rbrabson@us.ibm.com
以下に電話をしてください。 (919) 254-7332 メールしてください: rbrabson@us.ibm.com
Bound Informational [Page 16] RFC 4057 IPv6 Enterprise Network Scenarios June 2005
[16ページ]制限された情報のRFC4057IPv6企業網シナリオ2005年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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 Informational [Page 17]
バウンド情報です。[17ページ]
一覧
スポンサーリンク