RFC4029 日本語訳
4029 Scenarios and Analysis for Introducing IPv6 into ISP Networks. M.Lind, V. Ksinant, S. Park, A. Baudot, P. Savola. March 2005. (Format: TXT=64388 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Lind
Request for Comments: 4029 TeliaSonera
Category: Informational V. Ksinant
Thales Communications
S. Park
SAMSUNG Electronics
A. Baudot
France Telecom
P. Savola
CSC/Funet
March 2005
コメントを求めるワーキンググループM.リンド要求をネットワークでつないでください: 4029年のTeliaSoneraカテゴリ: 2005年の情報のV.のA.BaudotフランステレコムのP.Savola CSC/Funet Ksinant ThalesコミュニケーションS.公園三星のエレクトロニクス行進
Scenarios and Analysis for Introducing IPv6 into ISP Networks
ISPネットワークに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 different scenarios for the introduction of IPv6 into an ISP's existing IPv4 network without disrupting the IPv4 service. The scenarios for introducing IPv6 are analyzed, and the relevance of already defined transition mechanisms are evaluated. Known challenges are also identified.
IPv4サービスを中断しないで、このドキュメントはIPv6の導入のためにISPの既存のIPv4ネットワークに異なったシナリオについて説明します。 IPv6を導入するためのシナリオは分析されます、そして、既に定義された変遷メカニズムの関連性は評価されます。 また、知られている挑戦は特定されます。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Goal and Scope of the Document. . . . . . . . . . . . . 2
2. Brief Description of a Generic ISP Network. . . . . . . . . . 3
3. Transition Scenarios. . . . . . . . . . . . . . . . . . . . . 4
3.1. Identification of Stages and Scenarios. . . . . . . . . 4
3.2. Stages. . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Stage 1 Scenarios: Launch . . . . . . . . . . . 5
3.2.2. Stage 2a Scenarios: Backbone. . . . . . . . . . 6
3.2.3. Stage 2b Scenarios: Customer Connection . . . . 6
3.2.4. Stage 3 Scenarios: Complete . . . . . . . . . . 7
3.2.5. Stages 2a and 3: Combination Scenarios. . . . . 7
3.3. Transition Scenarios. . . . . . . . . . . . . . . . . . 7
3.4. Actions Needed When Deploying IPv6 in an ISP's Network. 8
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. ドキュメントの目標と範囲。 . . . . . . . . . . . . 2 2. ジェネリックISPネットワークの記述に事情を知らせてください。 . . . . . . . . . 3 3. 変遷シナリオ。 . . . . . . . . . . . . . . . . . . . . 4 3.1. ステージとシナリオの識別。 . . . . . . . . 4 3.2. ステージ。 . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. ステージ1シナリオ: 着手. . . . . . . . . . . 5 3.2.2。 2aシナリオを上演してください: バックボーン。 . . . . . . . . . 6 3.2.3. 2bシナリオを上演してください: 顧客接続. . . . 6 3.2.4。 3つのシナリオを上演してください: .5に.73.2を完成してください。 ステージ2aと3: 組み合わせシナリオ。 . . . . 7 3.3. 変遷シナリオ。 . . . . . . . . . . . . . . . . . 7 3.4. 動作は、ISPのネットワークでIPv6を配布する必要がありました。 8
Lind, et al. Informational [Page 1] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[1ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
4. Backbone Transition Actions . . . . . . . . . . . . . . . . . 9
4.1. Steps in the Transition of Backbone Networks. . . . . . 9
4.1.1. MPLS Backbone . . . . . . . . . . . . . . . . . 9
4.2. Configuration of Backbone Equipment . . . . . . . . . . 10
4.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. IGP . . . . . . . . . . . . . . . . . . . . . . 11
4.3.2. EGP . . . . . . . . . . . . . . . . . . . . . . 12
4.3.3. Transport of Routing Protocols. . . . . . . . . 12
4.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . 13
5. Customer Connection Transition Actions. . . . . . . . . . . . 13
5.1. Steps in the Transition of Customer Connection Networks 13
5.1.1. Small End Sites . . . . . . . . . . . . . . . . 14
5.1.2. Large End Sites . . . . . . . . . . . . . . . . 15
5.2. User Authentication/Access Control Requirements . . . . 15
5.3. Configuration of Customer Equipment . . . . . . . . . . 16
5.4. Requirements for Traceability . . . . . . . . . . . . . 16
5.5. Ingress Filtering in the Customer Connection Network. . 17
5.6. Multihoming . . . . . . . . . . . . . . . . . . . . . . 17
5.7. Quality of Service. . . . . . . . . . . . . . . . . . . 17
6. Network and Service Operation Actions . . . . . . . . . . . . 18
7. Future Stages . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Requirements for Follow-On Work . . . . . . . . . . . . . . . 19
9. Example Networks. . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . 22
9.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
12. Informative References. . . . . . . . . . . . . . . . . . . . 24
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 27
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 28
4. バックボーン変遷動作. . . . . . . . . . . . . . . . . 9 4.1。 バックボーンネットワークの変遷におけるステップ。 . . . . . 9 4.1.1. MPLSバックボーン. . . . . . . . . . . . . . . . . 9 4.2。 バックボーン設備. . . . . . . . . . 10 4.3の構成。 ルート設定. . . . . . . . . . . . . . . . . . . . . . . . 10 4.3.1。 IGP. . . . . . . . . . . . . . . . . . . . . . 11 4.3.2。 EGP. . . . . . . . . . . . . . . . . . . . . . 12 4.3.3。 ルーティング・プロトコルの輸送。 . . . . . . . . 12 4.4. マルチキャスト. . . . . . . . . . . . . . . . . . . . . . . 13 5。 顧客接続変遷動作。 . . . . . . . . . . . 13 5.1. 顧客接続ネットワーク13 5.1.1の変遷におけるステップ。 小さい端のサイト. . . . . . . . . . . . . . . . 14 5.1.2。 大きい端のサイト. . . . . . . . . . . . . . . . 15 5.2。 ユーザー認証/アクセス制御要件. . . . 15 5.3。 顧客設備. . . . . . . . . . 16 5.4の構成。 追随性. . . . . . . . . . . . . 16 5.5のための要件。 顧客で接続ネットワークをフィルターにかけるイングレス。 . 17 5.6. マルチホーミング. . . . . . . . . . . . . . . . . . . . . . 17 5.7。 サービスの質。 . . . . . . . . . . . . . . . . . . 17 6. 操作動作. . . . . . . . . . . . 18 7をネットワークでつないで、修理してください。 未来は.188を上演します。 フォローオンのための要件は.199を扱います。 例のネットワーク。 . . . . . . . . . . . . . . . . . . . . . . 19 9.1. 例1の.219.2。 例2の.229.3。 例3の.23 10。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 23 11。 承認. . . . . . . . . . . . . . . . . . . . . . . 24 12。 有益な参照。 . . . . . . . . . . . . . . . . . . . 24 付録A.. . . . . . . . . . . . . . . . . . . . . . . . . 26作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . 27 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 28
1. Introduction
1. 序論
1.1. Goal and Scope of the Document
1.1. ドキュメントの目標と範囲
When an ISP deploys IPv6, its goal is to provide IPv6 connectivity and global address space to its customers. The new IPv6 service must be added to an existing IPv4 service, and the introduction of IPv6 must not interrupt this IPv4 service.
ISPがIPv6を配布すると、目標はIPv6の接続性とグローバルアドレスに顧客へのスペースを提供することです。 既存のIPv4サービスに新しいIPv6サービスを加えなければなりません、そして、IPv6の導入はこのIPv4サービスを中断してはいけません。
An ISP offering IPv4 service will find different ways to add IPv6 to this service. This document discusses a small set of scenarios for the introduction of IPv6 into an ISP's IPv4 network. It evaluates the relevance of the existing transition mechanisms in the context of these deployment scenarios and points out the lack of essential functionality in these methods.
サービスをIPv4に提供するISPはこのサービスにIPv6を加える異なった方法を見つけるでしょう。 このドキュメントはIPv6の導入のためにISPのIPv4ネットワークと小さいセットのシナリオについて議論します。 それは、これらの展開シナリオの文脈における、既存の変遷メカニズムの関連性を評価して、これらのメソッドにおける、不可欠の機能性の不足を指摘します。
Lind, et al. Informational [Page 2] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[2ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
The document is focused on services that include both IPv6 and IPv4 and does not cover issues surrounding IPv6-only service. It is also outside the scope of this document to describe different types of access or network technologies.
ドキュメントは、IPv6とIPv4の両方を含んでいるサービスに焦点を合わせられて、IPv6だけサービスを囲む問題をカバーしていません。 異なったタイプのアクセスかネットワーク技術を説明するために、このドキュメントの範囲の外にもそれはあります。
2. Brief Description of a Generic ISP Network
2. ジェネリックISPネットワークの簡単な説明
A generic network topology for an ISP can be divided into two main parts: the backbone network and customer connection networks. In addition, it includes building blocks such as network and service operations. The additional building blocks used in this document are defined as follows:
ISPのためのジェネリックネットワーク形態を2つの主部に分割できます: バックボーンネットワークと顧客接続ネットワーク。 さらに、それはネットワークや戦務活動などのブロックを含んでいます。 本書では使用される追加ブロックは以下の通り定義されます:
"CPE" : Customer Premises Equipment
"CPE": 顧客端末
"PE" : Provider Edge Equipment
"PE": プロバイダー縁の設備
"Network and service operation"
: This is the part of the ISP's network that hosts the
services required for the correct operation of the
ISP's network. These services usually include
management, supervision, accounting, billing, and
customer management applications.
「ネットワークとサービス操作」: これはISPのネットワークの正しい操作に必要であるサービスを主催するISPのネットワークの部分です。 通常、これらのサービスは管理、指揮、会計、支払い、および顧客管理アプリケーションを含んでいます。
"Customer connection"
: This is the part of the network used by a customer
when connecting to an ISP's network. It includes the
CPE, the last hop link, and the parts of the PE
interfacing to the last hop link.
「顧客接続」: これはISPのネットワークに接続するとき顧客によって使用されたネットワークの部分です。 それはCPE、最後のホップリンク、およびPEが連結する部品を最後のホップリンクに含めます。
"Backbone" : This is the rest of the ISP's network infrastructure.
It includes the parts of the PE interfacing to the
core, the core routers of the ISP, and the border
routers used to exchange routing information with
other ISPs (or other administrative entities).
「バックボーン」: これはISPのネットワークインフラの残りです。 それはPEがコアに連結する部品、ISPのコアルータ、および他のISPとルーティング情報を交換するのに使用される境界ルータ(または、他の管理実体)を含んでいます。
"Dual-stack network"
: A network that natively supports both IPv4 and IPv6.
「デュアルスタックネットワーク」: そんなにネイティブのネットワークはIPv4とIPv6の両方をサポートします。
In some cases (e.g., incumbent national or regional operators), a given customer connection network may have to be shared between or among different ISPs. According to the type of customer connection network used (e.g., one involving only layer 2 devices or one involving non-IP technology), this constraint may result in architectural considerations relevant to this document.
いくつかの場合、与えられた顧客接続ネットワークの(例えば、現職の国家の、または、地方のオペレータ)はISPの間、または、異なったISPの中で共有されなければならないかもしれません。 接続ネットワークが使用した顧客(例えば、非IP技術にかかわる層2台のデバイスか1だけにかかわる1つ)のタイプによると、この規制はこのドキュメントに関連している建築問題をもたらすかもしれません。
The basic components in the ISP's network are depicted in Figure 1.
ISPのネットワークにおける基本的なコンポーネントは図1に表現されます。
Lind, et al. Informational [Page 3] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[3ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
------------ ----------
| Network and| | |
| Service |--| Backbone |
| Operation | | |\
------------ ---------- \
/ | \ \
/ | \ \_Peering (Direct and
/ | \ exchange points)
/ | \
/ | \
---------- / ---------- \ ----------
| Customer | / | Customer | \ | Customer |
|Connection|--/ |Connection| \--|Connection|
| 1 | | 2 | | 3 |
---------- ---------- ----------
| | | ISP's Network
-------------------------------------------------------
| | | Customers' Networks
+--------+ +--------+ +--------+
| | | | | |
|Customer| |Customer| |Customer|
| | | | | |
+--------+ +--------+ +--------+
------------ ---------- | そしてネットワーク。| | | | サービス|--| バックボーン| | 操作| | |\ ------------ ---------- \ / | \ \ / | \ \_Peering (Direct and / | \ exchange points) / | \ / | \ ---------- / ---------- \ ---------- | 顧客| / | 顧客| \ | 顧客| |接続|--/ |接続| \--|接続| | 1 | | 2 | | 3 | ---------- ---------- ---------- | | | ISPのネットワーク------------------------------------------------------- | | | 顧客のネットワーク+--------+ +--------+ +--------+ | | | | | | |顧客| |顧客| |顧客| | | | | | | +--------+ +--------+ +--------+
Figure 1: ISP Network Topology
図1: ISPネットワーク形態
3. Transition Scenarios
3. 変遷シナリオ
3.1. Identification of Stages and Scenarios
3.1. ステージとシナリオの識別
This section describes different stages an ISP might consider when introducing IPv6 connectivity into its existing IPv4 network and the different scenarios of what might occur in the respective stages.
このセクションは既存のIPv4ネットワークにIPv6の接続性を取り入れるときISPが考えるかもしれない異なったステージと何がそれぞれの段階に起こるかもしれないかに関する異なったシナリオについて説明します。
The stages here are snapshots of the ISP's network with respect to IPv6 maturity. Because the ISP's network is continually evolving, a stage is a measure of how far along the ISP has come in terms of implementing the functionality necessary to offer IPv6 to its customers.
ここのステージはIPv6円熟に関するISPのネットワークのスナップです。 ISPのネットワークが絶えず発展しているので、顧客にとってステージはIPv6がISPに沿って遠くに提供するのに必要な機能性を実装することに関してどう来たかに関する測定です。
It is possible for a transition to occur freely between different stages. Although a network segment can only be in one stage at a time, the ISP's network as a whole can be in different stages. Different transition paths can be followed from the first to the final stage. The transition between two stages does not have to be instantaneous; it can occur gradually.
変遷が異なったステージの間に自由に起こるのは、可能です。 ネットワークセグメントが全体があることができるように一度にISPのものがネットワークでつなぐ1つの段階にあることができるだけですが、異なった段階にあってください。 1日から最終段階まで異なった変遷経路に続くことができます。 2つのステージの間の変遷は瞬時に起こっている必要はありません。 それは徐々に起こることができます。
Lind, et al. Informational [Page 4] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[4ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
Each stage has different IPv6 properties. Therefore, based on its requirements, an ISP can decide which set of stages it will follow and in what order to transform its network.
各ステージには、異なったIPv6の特性があります。 したがって、要件に基づいて、ISPはそれがネットワークを変えるよう続いて、こと命令するステージのどのセットについて決めることができるか。
This document is not aimed at covering small ISPs, hosting providers, or data centers; only the scenarios applicable to ISPs eligible for at least a /32 IPv6 prefix allocation from an RIR are covered.
このドキュメントはプロバイダー、またはデータセンターをホスティングして、小さいISPをカバーするのを目的とされません。 RIRからの少なくとも/32IPv6接頭語配分に、適任のISPに適切なシナリオだけがカバーされています。
3.2. Stages
3.2. ステージ
The stages are derived from the generic description of an ISP's network in Section 2. Combinations of different building blocks that constitute an ISP's environment lead to a number of scenarios from which the ISP can choose. The scenarios most relevant to this document are those that maximize an ISP's ability to offer IPv6 to its customers in the most efficient and feasible way. The assumption in all stages is that the ISP's goal is to offer both IPv4 and IPv6 to the customer.
セクション2における、ISPのネットワークのジェネリック記述からステージを得ます。 ISPの環境を構成する異なったブロックの組み合わせはISPが選ばれることができる多くのシナリオにつながります。 このドキュメントに最も関連しているシナリオは最も効率的で可能な方法でIPv6を顧客に提供するISPの能力を最大にするものです。 すべての段階の仮定はISPの目標がIPv4とIPv6の両方を顧客に提供することであるということです。
The four most probable stages are as follows:
4つの最もありえそうなステージは以下の通りです:
o Stage 1 Launch
o Stage 2a Backbone
o Stage 2b Customer connection
o Stage 3 Complete
o ステージの1Launch oのStage 2a Backbone o Stage 2b Customer接続o Stage3Complete
Generally, an ISP is able to upgrade a current IPv4 network to an IPv4/IPv6 dual-stack network via Stage 2b, but the IPv6 service can also be implemented at a small cost by adding simple tunnel mechanisms to the existing configuration. When a new network is designed, Stage 3 might be the first or last step because there are no legacy concerns. Nevertheless, the absence of IPv6 capability in the network equipment can still be a limiting factor.
一般に、ISPはStage 2bを通して現在のIPv4ネットワークをIPv4/IPv6デュアルスタックネットワークにアップグレードさせることができますが、また、わずかな費用で簡単なトンネルメカニズムを既存の構成に加えることによって、IPv6サービスを実装することができます。 新しいネットワークが設計されているとき、レガシー関心が全くないので、Stage3は1番目か最後のステップであるかもしれません。 それにもかかわらず、ネットワーク装置における、IPv6能力の欠如はまだ限定因子であるかもしれません。
Note that in every stage except Stage 1, the ISP can offer both IPv4 and IPv6 services to its customers.
Stage1以外のあらゆる段階では、ISPがIPv4とIPv6の両方に顧客に対するサービスを提供できることに注意してください。
3.2.1. Stage 1 Scenarios: Launch
3.2.1. ステージ1シナリオ: 着手
The first stage is an IPv4-only ISP with an IPv4 customer. This is the most common case today and is the natural starting point for the introduction of IPv6. From this stage, the ISP can move (undergo a transition) from Stage 1 to any other stage with the goal of offering IPv6 to its customer.
第一段階はIPv4顧客がいるIPv4だけISPです。 これは、今日最も一般的なケースであり、IPv6の導入のための本来の出発点です。 このステージから、ISPはIPv6を顧客に提供するという目標のためにStage1からいかなる他のステージまでも移行できます(推移します)。
The immediate first step consists of obtaining a prefix allocation (typically a /32) from the appropriate RIR (e.g., AfriNIC, APNIC, ARIN, LACNIC, RIPE) according to allocation procedures.
即座の第一歩は配分手順に応じて適切なRIR(例えば、AfriNIC、APNIC、ARIN、LACNIC、RIPE)から接頭語配分(通常/32)を得るのから成ります。
Lind, et al. Informational [Page 5] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[5ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
The ISP will also need to establish IPv6 connectivity to its upstream providers and peers; it is of utmost importance to require IPv6 transit when negotiating IP transit deals with the upstream ISPs. If the upstream is not providing IPv6 connectivity at the moment, it may be possible to obtain temporary connectivity from a nearby ISP, possibly using a short configured tunnel. However, the longer-term goal must be to require and to obtain IPv6 connectivity from the transit ISPs, because otherwise the quality of IPv6 connectivity will likely be poor.
また、ISPは、その上流のプロバイダーと同輩にIPv6の接続性を確立する必要があるでしょう。 それは、上流のISPとのIPトランジット取引を交渉するとき、IPv6トランジットを必要とするためには最重要性のものです。 上流が現在IPv6の接続性を提供していないなら、近いISPから一時的な接続性を得るのは可能であるかもしれません、ことによると短い構成されたトンネルを使用して。 しかしながら、トランジットISPからの目標が必要であり、得ることになっていなければならないより長い期間のIPv6の接続性、そうでないので、IPv6の接続性の品質はおそらく劣るでしょう。
Connectivity to peers can typically be established either directly or at Internet Exchange Points (IX). Most IXs use techniques where IPv6 is easy to use, and many IXs already provide infrastructure for IPv6 peerings. Such peerings can be done natively by using IPv6. Peerings over IPv6-in-IPv4 tunnels is also possible but not recommended, at least in the long term. Direct connectivity to peers may be feasible when there is direct connectivity to the peer for IPv4.
直接かインターネットExchange Points(IX)で同輩への接続性を通常確立できます。 ほとんどのIXsがIPv6が使用しやすいテクニックを使用します、そして、多くのIXsが既にインフラストラクチャをIPv6 peeringsに供給します。 IPv6を使用することによって、ネイティブにそのようなpeeringsができます。 IPv4のIPv6トンネルの上のPeeringsは少なくとも長期にまた、可能ですが、お勧めではありません。 IPv4のための同輩への接続性がダイレクトにあるとき、同輩へのダイレクト接続性は可能であるかもしれません。
3.2.2. Stage 2a Scenarios: Backbone
3.2.2. 2aシナリオを上演してください: バックボーン
Stage 2a deals with an ISP with IPv4-only customer connection networks and a backbone that supports both IPv4 and IPv6. In particular, the ISP has the possibility of making the backbone IPv6- capable through software upgrades, hardware upgrades, or a combination of both.
ステージ2aはIPv4だけ顧客接続ネットワークがあるISPとIPv4とIPv6の両方をサポートするバックボーンに対処します。 ISPには、特に、バックボーンをソフトウェアの更新でできるIPv6にする可能性、ハードウェアアップグレード、または両方の組み合わせがあります。
Since the customer connections have not yet been upgraded, a tunneling mechanism has to be used to provide IPv6 connectivity through the IPv4 customer connection networks. The customer can terminate the tunnel at the CPE (if it has IPv6 support) or at some set of devices internal to its network. That is, either the CPE or a device inside the network could provide global IPv6 connectivity to the rest of the devices in the customer's network.
顧客接続がまだアップグレードしていないので、トンネリングメカニズムはIPv4顧客接続ネットワークを通してIPv6の接続性を提供するのに使用されなければなりません。 顧客はCPE(それにIPv6サポートがあるなら)において、または、ネットワークへの内部のデバイスの何らかのセットでトンネルを終えることができます。 すなわち、ネットワークにおけるCPEかデバイスのどちらかが顧客のネットワークにおける、デバイスの残りにグローバルなIPv6の接続性を提供するかもしれません。
3.2.3. Stage 2b Scenarios: Customer Connection
3.2.3. 2bシナリオを上演してください: 顧客接続
Stage 2b consists of an ISP with an IPv4 backbone network and a customer connection network that supports both IPv4 and IPv6. Because the service to the customer is native IPv6, the customer is not required to support both IPv4 and IPv6. This is the biggest difference from the previous stage. The need to exchange IPv6 traffic still exists but might be more complicated than in the previous case because the backbone is not IPv6-enabled. After completing Stage 2b, the original IPv4 backbone is unchanged. This means that the IPv6 traffic is transported either by tunneling over the existing IPv4 backbone, or in an IPv6 overlay network more or less separated from the IPv4 backbone.
ステージ2bはIPv4とIPv6の両方をサポートするIPv4バックボーンネットワークと顧客接続ネットワークと共にISPから成ります。 顧客に対するサービスがネイティブのIPv6であるので、顧客はIPv4とIPv6の両方をサポートする必要はありません。 これは前のステージからの最大の違いです。 IPv6トラフィックを交換する必要性は、まだ存在していますが、バックボーンがIPv6によって可能にされないので、先の事件より複雑であるかもしれません。 Stage 2bを完成した後に、オリジナルのIPv4バックボーンは変わりがありません。 これは、IPv6トラフィックが既存のIPv4バックボーンの上のトンネリング、またはIPv4バックボーンと多少切り離されたIPv6オーバレイネットワークで輸送されることを意味します。
Lind, et al. Informational [Page 6] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[6ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
Normally, the ISP will continue to provide IPv4 connectivity by using private (NATted by the ISP) or public IPv4 address. In many cases, the customer also has a NAT of his/her own; if so, this likely continues to be used for IPv4 connectivity.
ISPは、通常、個人的(ISPによるNATted)か公共のIPv4アドレスを使用することによってIPv4の接続性を提供し続けるでしょう。 また、多くの場合、顧客には、自分のNATがあります。 そうだとすれば、これは、IPv4の接続性におそらく使用され続けています。
3.2.4. Stage 3 Scenarios: Complete
3.2.4. 3つのシナリオを上演してください: 完全
Stage 3 could be considered the final step in introducing IPv6, at least within the scope of this document. This stage consists of ubiquitous IPv6 service with native support for IPv6 and IPv4 in both backbone and customer connection networks. From the customer's perspective, it is identical to the previous stage because the customer connection network has not changed. The requirement for exchanging IPv6 traffic is identical to that of Stage 2.
少なくともこのドキュメントの範囲の中でIPv6を導入することにおける最終的なステップであるとステージ3を考えることができました。 このステージはバックボーンと顧客接続ネットワークの両方でIPv6とIPv4のネイティブのサポートで遍在しているIPv6サービスから成ります。 顧客の見解から、顧客接続ネットワークが変化していないので、それは前のステージと同じです。 IPv6トラフィックを交換するための要件はStage2のものと同じです。
3.2.5. Stages 2a and 3: Combination Scenarios
3.2.5. ステージ2aと3: 組み合わせシナリオ
Some ISPs may use different access technologies of varying IPv6 maturity. This may result in a combination of the Stages 2a and 3: some customer connections do not support IPv6, but others do; in both cases the backbone is dual-stack.
いくつかのISPが異なったIPv6円熟の異なったアクセス技術を使用するかもしれません。 これはStages 2aと3つのものの組み合わせをもたらすかもしれません: 何人かの顧客接続はIPv6をサポートしませんが、他のものはサポートします。 どちらの場合も、バックボーンはデュアルスタックです。
This scenario is equivalent to Stage 2a, but it requires support for native IPv6 customer connections on some access technologies.
このシナリオはStage 2aに同等ですが、それはネイティブのIPv6顧客接続にいくつかのアクセス技術で支持を要します。
3.3. Transition Scenarios
3.3. 変遷シナリオ
Given the different stages, it is clear that an ISP has to be able to make a transition from one stage to another. The initial stage in this document is an IPv4-only service and network. The end stage is a dual IPv4/IPv6 service and network.
異なったステージを考えて、ISPが1つのステージから別のステージまでの変遷をすることができなければならないのは、明確です。 初期は、本書ではIPv4だけサービスとネットワークです。 末期は、二元的なIPv4/IPv6サービスとネットワークです。
The transition starts with an IPv4 ISP and then moves in one of three directions. This choice corresponds to the different transition scenarios. Stage 2a consists of upgrading the backbone first. Stage 2b consists of upgrading the customer connection network. Finally, Stage 3 consists of introducing IPv6 in both the backbone and customer connections as needed.
変遷は、IPv4ISPから始まって、次に、3つの方向の1つに入って来ます。 この選択は異なった変遷シナリオに対応しています。 ステージ2aは最初にバックボーンをアップグレードさせるのから成ります。 ステージ2bは顧客接続ネットワークをアップグレードさせるのから成ります。 最終的に、Stage3は必要に応じてバックボーンと顧客接続の両方でIPv6を導入するのから成ります。
Because most ISP backbone IPv4 networks continually evolve (firmware replacements in routers, new routers, etc.), they can be made ready for IPv6 without additional investment (except staff training). This transition path may be slower but still useful, as it allows for the introduction of IPv6 without any actual customer demand. This approach may be superior to doing everything at the last minute, which may entail a higher investment. However, it is important to consider (and to request from vendors) IPv6 features in all new equipment from the outset. Otherwise, the time and effort required
ほとんどのISPバックボーンIPv4ネットワークが絶えず(ルータにおけるファームウェア交換、新しいルータなど)を発展するので、IPv6のために追加出資(職員研修を除いた)なしでそれらを用意できます。 この変遷経路は、より遅いのですが、まだ役に立っているかもしれません、少しも実際の顧客要求なしでIPv6の導入を考慮するとき。 このアプローチは土壇場ですべてをするより優れているかもしれません(さらに高い投資を伴うかもしれません)。 しかしながら、着手からすべての新しい設備におけるIPv6の特徴を考えるのは(ベンダーから要求するために)重要です。 さもなければ、時間と取り組みが必要です。
Lind, et al. Informational [Page 7] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[7ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
to remove non-IPv6-capable hardware from the network may be significant.
ネットワークからできる非IPv6ハードウェアを取り外すのは重要であるかもしれません。
3.4. Actions Needed When Deploying IPv6 in an ISP's Network
3.4. 動作は、ISPのネットワークでIPv6を配布する必要がありました。
Examination of the transitions described above reveals that it is possible to split the work required for each transition into a small set of actions. Each action is largely independent of the others, and some actions may be common to multiple transitions.
上で説明された変遷の試験は、各変遷に必要である仕事を小さいセットの機能に分けるのが可能であることを明らかにします。 それぞれの動きは他のものから主に独立しています、そして、いくつかの動作が複数の変遷に共通であるかもしれません。
Analysis of the possible transitions leads to a small list of actions:
可能な変遷の分析は動作の小さいリストにつながります:
* Actions required for backbone transition:
* 動作がバックボーン変遷に必要です:
- Connect dual-stack customer connection networks to other
IPv6 networks through an IPv4 backbone.
- IPv4バックボーンを通してデュアルスタック顧客接続ネットワークを他のIPv6ネットワークに接続してください。
- Transform an IPv4 backbone into a dual-stack one. This
action can be performed directly or through intermediate
steps.
- IPv4バックボーンをデュアルスタック1に変えてください。 直接か途中経過を通ってこの動作を実行できます。
* Actions required for customer connection transition:
* 動作が顧客接続変遷に必要です:
- Connect IPv6 customers to an IPv6 backbone through an IPv4
network.
- IPv4ネットワークを通してIPv6顧客をIPv6バックボーンに接続してください。
- Transform an IPv4 customer connection network into a dual-
stack one.
- IPv4顧客接続ネットワークを二元的なスタック1に変えてください。
* Actions required for network and service operation transition:
* 動作がネットワークとサービス操作変遷に必要です:
- Set up IPv6 connectivity to upstream providers and peers.
- 上流のプロバイダーと同輩にIPv6の接続性をセットアップしてください。
- Configure IPv6 functions into network components.
- IPv6機能をネットワーク要素に構成してください。
- Upgrade regular network management and monitoring
applications to take IPv6 into account.
- レギュラー・ネットワーク管理と監視用途をアップグレードさせて、IPv6を考慮に入れてください。
- Extend customer management (e.g., RADIUS) mechanisms to be
able to supply IPv6 prefixes and other information to
customers.
- 顧客管理(例えば、RADIUS)メカニズムを広げて、IPv6接頭語と他の情報を顧客に供給できてください。
- Enhance accounting, billing, and so on to work with IPv6 as
needed. (Note: If dual-stack service is offered, this may
not be necessary.)
- 必要に応じてIPv6と共に働くために会計、支払いなどを機能アップしてください。 (注意: デュアルスタックサービスを提供するなら、これは必要でないかもしれません。)
- Implement security for network and service operation.
- ネットワークとサービス操作のためにセキュリティを実装してください。
Lind, et al. Informational [Page 8] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[8ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
Sections 4, 5, and 6 contain detailed descriptions of each action.
セクション4、5、および6 それぞれの動作の詳述を含んでください。
4. Backbone Transition Actions
4. バックボーン変遷動作
4.1. Steps in the Transition of Backbone Networks
4.1. バックボーンネットワークの変遷におけるステップ
In terms of physical equipment, backbone networks mainly consist of high-speed core and edge routers. Border routers provide peering with other providers. Filtering, routing policy, and policing functions are generally managed on border routers.
物理的機器に関して、バックボーンネットワークは主に高速コアと縁のルータから成ります。 境界ルータは、他のプロバイダーでじっと見ながら、提供されます。 一般に、フィルタリングと、ルーティング方針と、機能を取り締まるのは境界ルータで管理されます。
In the beginning, an ISP has an IPv4-only backbone. In the end, the backbone is completely dual-stack. In between, intermediate steps may be identified:
初めに、ISPには、IPv4だけバックボーンがあります。 結局、バックボーンは完全にデュアルスタックです。 中間で、途中経過は特定されるかもしれません:
Tunnels Tunnels Dual Full
IPv4-only ----> or ---> or + Stack --> Dual Stack
dedicated IPv6 dedicated IPv6 routers
links links
Tunnelsは二元的な完全なIPv4だけにトンネルを堀ります。----または>。--->か+スタック-->の専用IPv6専用IPv6ルータDual Stackリンクはリンクされます。
Figure 2: Transition Path
図2: 変遷経路
The first step involves tunnels or dedicated links but leaves existing routers unchanged. Only a small set of routers then have IPv6 capabilities. The use of configured tunnels is adequate during this step.
第一歩は、トンネルにかかわるか、リンクを捧げますが、または既存のルータを変わりがないままにします。 そして、小さいセットのルータだけには、IPv6能力があります。 構成されたトンネルの使用はこのステップの間、適切です。
In the second step, some dual-stack routers are added, progressively, to this network.
第2ステップでは、いくつかのデュアルスタックルータが次第にこのネットワークに追加されます。
The final step is reached when all or almost all routers are dual-stack.
すべてかほとんどすべてのルータがデュアルスタックであるときに、最終的なステップに達しています。
For many reasons (technical, financial, etc.), the ISP may progress step by step or jump directly to the final one. One important criterion in planning this evolution is the number of IPv6 customers the ISP expects during its initial deployments. If few customers connect to the original IPv6 infrastructure, then the ISP is likely to remain in the initial steps for a long time.
種々の理由で(技術的で、財政的ななど)、ISPは、直接最終的なものまで一歩一歩進歩をするか、またはジャンプするかもしれません。 この発展を計画することにおける1つの重要な評価基準がISPが初期の展開の間に予想するIPv6顧客の数です。 わずかな顧客しかオリジナルのIPv6インフラストラクチャに接続しないなら、ISPは長い間、初期段階に残っていそうです。
In short, each intermediate step is possible, but none is mandatory.
要するに、それぞれの途中経過は可能ですが、なにも義務的ではありません。
4.1.1. MPLS Backbone
4.1.1. MPLSバックボーン
If MPLS is already deployed in the backbone, it may be desirable to provide IPv6-over-MPLS connectivity. However, setting up an IPv6 Label Switched Path (LSP) requires signaling through the MPLS
MPLSがバックボーンで既に配布されるなら、IPv6過剰MPLSの接続性を提供するのは望ましいかもしれません。 しかしながら、IPv6 Label Switched Path(LSP)をセットアップするのは、MPLSを通して合図するのを必要とします。
Lind, et al. Informational [Page 9] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[9ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
network; both LDP and RSVP-TE can set up IPv6 LSPs, but this might require upgrade/change in the MPLS core network.
ネットワーク。 自由民主党とRSVP-TEの両方がIPv6 LSPsをセットアップできますが、これはMPLSコアネットワークにおけるアップグレード/変化を必要とするかもしれません。
An alternative approach is to use BGP for signaling or to perform; for example, IPv6-over-IPv4/MPLS, as described in [BGPTUNNEL]. Some possibilities are preferable to others, depending on the specific environment under consideration. The approaches seem to be as follows:
代替的アプローチは、シグナリングにBGPを使用するか、または働くことです。 例えば、[BGPTUNNEL]で説明されるようなIPv6過剰IPv4/MPLS。 特定の環境に考慮でよって、いくつかの可能性が他のものより望ましいです。 アプローチは以下の通りであるように思えます:
1) Require that MPLS networks deploy native IPv6 routing and
forwarding support.
1) MPLSネットワークが、固有のIPv6ルーティングと推進がサポートであると配布するのを必要であってください。
2) Require that MPLS networks support native routing and
setting up of IPv6 LSPs, used for IPv6 connectivity.
2) MPLSネットワークが上がっていてIPv6 LSPsを、IPv6の接続性に、中古の固有のルーティングと設定をサポートするのを必要であってください。
3) Use only configured tunneling over IPv4 LSPs.
3) 使用はIPv4 LSPsの上でトンネリングを構成しただけです。
4) Use [BGPTUNNEL] to perform IPv6-over-IPv4/MPLS encapsulation
for IPv6 connectivity.
4) [BGPTUNNEL]を使用して、IPv6の接続性のためにIPv6過剰IPv4/MPLSカプセル化を実行してください。
Approaches 1) and 2) are clearly the best target approaches. However, approach 1) may not be possible if the ISP is not willing to add IPv6 support in the network, or if the installed equipment is not capable of high performance native IPv6 forwarding. Approach 2) may not be possible if the ISP is unwilling or unable to add IPv6 LSP set-up support in the MPLS control plane.
アプローチ1と)2)は明確に最も良い目標アプローチです。 しかしながら、ISPがネットワークでIPv6サポートを加えることを望んでいないか、または固定的設備は高性能のネイティブのIPv6推進ができないなら、アプローチ1)は可能でないかもしれません。 ISPが不本意であるか、またはMPLS制御飛行機でIPv6 LSPセットアップサポートを加えることができないなら、アプローチ2)は可能でないかもしれません。
Approach 4) can be used as an interim mechanism when other options are unfeasible or undesirable for the reasons discussed above.
別の選択肢が上で議論した理由で実行不可能であるか、または望ましくないときに、当座のメカニズムとしてアプローチ4)を使用できます。
Approach 3) is roughly equivalent to approach 4) except that it does not require additional mechanisms but may lack scalability in the larger networks, especially if IPv6 is widely deployed.
アプローチ3)は、追加メカニズムを必要としないのを除いて、4に)アプローチするためにおよそ同等ですが、より大きいネットワークにスケーラビリティを欠くかもしれません、特にIPv6が広く配布されるなら。
4.2. Configuration of Backbone Equipment
4.2. バックボーン設備の構成
In the backbone, the number of devices is small, and IPv6 configuration mainly deals with routing protocol parameters, interface addresses, loop-back addresses, access control lists, and so on.
バックボーンでは、デバイスの数は少ないです、そして、IPv6構成はルーティング・プロトコルパラメタ、インターフェース・アドレス、ループバックアドレス、アクセスコントロールリストなどに主に対処します。
These IPv6 parameters need to be configured manually.
これらのIPv6パラメタは、手動で構成される必要があります。
4.3. Routing
4.3. ルート設定
ISPs need routing protocols to advertise reachability and to find the shortest working paths, both internally and externally.
ISPは、可到達性の広告を出して、内部的に外部的に最も短い働く経路を見つけるためにルーティング・プロトコルを必要とします。
Lind, et al. Informational [Page 10] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[10ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
Either OSPFv2 or IS-IS is typically used as the IPv4 IGP. RIPv2 is not usually used in service provider networks, as OSPF and IS-IS are superior IGPs. BGP is the only IPv4 EGP. Static routes also are used in both cases.
または、OSPFv2、-、IPv4 IGPとして通常使用されます。 そして、通常、RIPv2がOSPFとしてサービスプロバイダーネットワークに使用されない、-、優れたIGPsはそうです。 BGPは唯一のIPv4 EGPです。 スタティックルートもどちらの場合も、使用されます。
Note that it is possible to configure a given network so that it has an IPv6 topology different from its IPv4 topology. For example, some links or interfaces may be dedicated to IPv4-only or IPv6-only traffic, or some routers may be dual-stack whereas others may be IPv4- or IPv6-only. In this case, routing protocols must be able to understand and cope with multiple topologies.
それにはIPv4トポロジーと異なったIPv6トポロジーがあるように、与えられたネットワークを構成するのが可能であることに注意してください。 例えば、いくつかのリンクかインタフェースがIPv4だけかIPv6だけトラフィックに捧げられるかもしれませんか、いくつかのルータがデュアルスタックであるかもしれませんが、IPv4か他のものはIPv6専用であるかもしれません。 この場合、ルーティング・プロトコルは、複数のtopologiesを理解して、対処できなければなりません。
4.3.1. IGP
4.3.1. IGP
Once the IPv6 topology has been determined, the choice of IPv6 IGP must be made: either OSPFv3 or IS-IS for IPv6. RIPng is not appropriate in most contexts, due to RIPv2 not being appropriate for IPv4 either, and is therefore not discussed here. The IGP typically includes the routers' point-to-point and loop-back addresses.
IPv6トポロジーがいったん断固とするようになると、IPv6 IGPの選択をしなければなりません: または、OSPFv3、-、IPv6のために。 RIPngについてIPv4には、適切でないRIPv2のためにほとんどの文脈で適切でなく、またしたがって、ここで議論しません。 IGPはルータのポイントツーポイントとループバックアドレスを通常含んでいます。
The most important decision is whether one wishes to have separate routing protocol processes for IPv4 and IPv6. Separating them requires more memory and CPU for route calculations, e.g., when the links flap. But separation provides a measure of assurance that should problems arise with IPv6 routing, they will not affect the IPv4 routing protocol. In the initial phases, if it is uncertain whether joint IPv4-IPv6 networking is working as intended, running separate processes may be desirable and easier to manage.
最も重要な決定は人がIPv4とIPv6のための別々のルーティング・プロトコルプロセスを持ちたがっているかどうかということです。 例えば、リンクがばたつくと、それらを切り離すのはルート計算のために、より多くのメモリとCPUを必要とします。 しかし、分離は問題がIPv6ルーティングで起こると、IPv4ルーティング・プロトコルに影響しないという保証の手段を提供します。 初期位相では、共同IPv4-IPv6ネットワークが意図されるとして働いているかどうかが、不確実であるなら、実行している別々のプロセスは、望ましくて、管理するのは、より簡単であるかもしれません。
The possible combinations are as follows:
可能な組み合わせは以下の通りです:
- With separate processes:
o OSPFv2 for IPv4, IS-IS for IPv6 (only)
o OSPFv2 for IPv4, OSPFv3 for IPv6, or
o IS-IS for IPv4, OSPFv3 for IPv6
- 別々のプロセスで: o IPv4のためのOSPFv2、-、IPv4のためのIPv6(単に)o OSPFv2、IPv6のためのOSPFv3、またはo、-、IPv4、IPv6のためのOSPFv3
- With the same process:
o IS-IS for both IPv4 and IPv6
- 同じくらいで、以下を処理してください。 o -、IPv4とIPv6の両方
Note that if IS-IS is used for both IPv4 and IPv6, the IPv4/IPv6 topologies must be "convex", unless the multiple-topology IS-IS extensions [MTISIS] have been implemented (using IS-IS for only IPv4 or only IPv6 requires no convexity). In simpler networks or with careful planning of IS-IS link costs, it is possible to keep even incongruent IPv4/IPv6 topologies "convex". The convexity problem is explained in more detail with an example in Appendix A.
それに注意してください、-、IPv4とIPv6の両方において使用されていて、IPv4/IPv6 topologiesが「凸状でなければならない」、複数のトポロジー、-、拡大[MTISIS]が実装された、(使用、-、IPv4だけかIPv6だけが凸状を全く必要としない、) より簡単なネットワークか綿密な計画、-、リンクコスト、「凸状に」合同でないIPv4/IPv6 topologiesさえ保つのは可能です。 さらに詳細に例がAppendix Aにある状態で、凸状問題は説明されます。
Lind, et al. Informational [Page 11] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[11ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
When deploying full dual-stack in the short-term, using single- topology IS-IS is recommended. This may be particularly applicable for some larger ISPs. In other scenarios, choosing between one or two separate processes often depends on the perceived risk to the IPv4 routing infrastructure, i.e., whether one wishes to keep them separate for the time being. If this is not a factor, using a single process is usually preferable for operational reasons: not having to manage two protocols and topologies.
単一のトポロジーを使用して、短期的で完全なデュアルスタックを配布する、-、推薦されます。 いくつかの、より大きいISPには、これは特に適切であるかもしれません。 他のシナリオでは、1か2つの別々のプロセスを選ぶのをしばしばIPv4ルーティングインフラストラクチャへの知覚リスクに依存します、すなわち、人が当分の間それらを別々に保ちたがっているか否かに関係なく。 これが要素でないなら、通常、単一のプロセスを使用するのは操作上の理由で望ましいです: 2プロトコルとtopologiesを管理する必要はないこと。
The IGP is typically only used to carry loopback and point-to-point addresses and doesn't include customer prefixes or external routes. Internal BGP (iBGP), as described in the next section, is most often deployed in all routers (PE and core) to distribute routing information about customer prefixes and external routes.
IGPはループバックと二地点間アドレスを運ぶのに通常使用されるだけであり、顧客接頭語か外部経路を含んでいません。 次のセクションで説明される内部のBGP(iBGP)は、顧客接頭語と外部経路のルーティング情報を分配するためにすべてのルータ(PEとコア)でたいてい配布されます。
Some of the simplest devices (e.g., CPE routers) may not implement routing protocols other than RIPng. In some cases, therefore, it may be necessary to run RIPng in addition to one of the above IGPs, at least in a limited fashion, and then, by some mechanism, to redistribute routing information between the routing protocols.
いくつかの最も簡単なデバイス(例えば、CPEルータ)は、ルーティングがRIPng以外のプロトコルであると実装しないかもしれません。 いくつかの場合、したがって、少なくとも限られたファッション、および次に、上のIGPsの1つに加えた何らかのメカニズムでRIPngを実行するのが、ルーティング情報をルーティング・プロトコルの間に再配付するのに必要であるかもしれません。
4.3.2. EGP
4.3.2. EGP
BGP is used for both internal and external BGP sessions.
BGPは内部の、そして、外部の両方のBGPセッションに使用されます。
BGP with multiprotocol extensions [RFC2858] can be used for IPv6 [RFC2545]. These extensions enable the exchange of IPv6 routing information and the establishment of BGP sessions using TCP over IPv6.
IPv6[RFC2545]に「マルチ-プロトコル」拡張子[RFC2858]があるBGPを使用できます。 これらの拡大は、IPv6の上でTCPを使用することでIPv6ルーティング情報の交換とBGPセッションの設立を可能にします。
It is possible to use a single BGP session to advertise both IPv4 and IPv6 prefixes between two peers. However, the most common practice today is to use separate BGP sessions.
2人の同輩の間のIPv4とIPv6接頭語の両方の広告を出すのにただ一つのBGPセッションを使用するのは可能です。 しかしながら、今日の最も一般的な習慣は別々のBGPセッションを使用することになっています。
4.3.3. Transport of Routing Protocols
4.3.3. ルーティング・プロトコルの輸送
IPv4 routing information should be carried by IPv4 transport and, similarly, IPv6 routing information by IPv6 for several reasons:
IPv4ルーティング情報はいくつかの理由でIPv4輸送と同様にIPv6ルーティング情報によってIPv6によって運ばれるはずです:
* IPv6 connectivity may work when IPv4 connectivity is down (or
vice-versa).
* The best route for IPv4 is not always the best one for IPv6.
* IPv4の接続性が下がっているとき(逆もまた同様に)、IPv6の接続性は働くかもしれません。 * IPv4に、最も良いルートはいつもIPv6のための最も良い方であるというわけではありません。
* The IPv4 and IPv6 logical topologies may be different because
the administrator may want to assign different metrics to a
physical link for load balancing or because tunnels may be in
use.
* 管理者がロードバランシングのために異なった測定基準を物理的なリンクに割り当てたがっているかもしれないか、またはトンネルが使用中であるかもしれないので、IPv4とIPv6の論理的なtopologiesは異なっているかもしれません。
Lind, et al. Informational [Page 12] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[12ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
4.4. Multicast
4.4. マルチキャスト
Currently, IPv6 multicast is not a major concern for most ISPs. However, some of them are considering deploying it. Multicast is achieved by using the PIM-SM and PIM-SSM protocols. These also work with IPv6.
現在、IPv6マルチキャストはほとんどのISPに関する主要な関心事ではありません。 しかしながら、彼らの何人かが、それを配布すると考えています。 マルチキャストは、PIM-SMとPIM-SSMプロトコルを使用することによって、達成されます。 また、これらはIPv6と共に働いています。
Information about multicast sources is exchanged by using MSDP in IPv4, but MSDP is intentionally not defined for IPv6. Instead, one should use only PIM-SSM or an alternative mechanism for conveying the information [EMBEDRP].
IPv4でMSDPを使用することによって、マルチキャストソースに関する情報を交換しますが、IPv6のために故意にMSDPを定義しません。 代わりに、情報[EMBEDRP]を伝えるのにPIM-SSMか代替のメカニズムだけを使用するべきです。
5. Customer Connection Transition Actions
5. 顧客接続変遷動作
5.1. Steps in the Transition of Customer Connection Networks
5.1. 顧客接続ネットワークの変遷におけるステップ
Customer connection networks are generally composed of a small set of PEs connected to a large set of CPEs and may be based on different technologies depending on the customer type or size, as well as the required bandwidth or even quality of service. Small unmanaged connection networks used for public customers usually rely on different technologies (e.g., dial-up or DSL) than the ones used for large customers, which typically run managed networks. Transitioning these infrastructures to IPv6 can be accomplished in several steps, but some ISPs, depending on their perception of the risks, may avoid some of the steps.
顧客接続ネットワークは、一般に、CPEsの大きいセットに接続されたPEsの小さいセットで構成されて、必要な帯域幅と同様に顧客タイプかサイズに頼る異なった技術かサービスの質にさえ基づくかもしれません。 公共の顧客が通常、通常走る大口顧客に使用されるものと異なった技術(例えば、ダイヤルアップかDSL)を当てにするので、ネットワークが使用した小さい非管理された接続はネットワークを経営しました。 移行して、数ステップでIPv6へのこれらのインフラストラクチャを達成できますが、彼らのリスクの認知によって、いくつかのISPがステップのいくつかを避けるかもしれません。
Connecting IPv6 customers to an IPv6 backbone through an IPv4 network can be considered a first careful step taken by an ISP to provide IPv6 services to its IPv4 customers. Some ISPs may also choose to provide IPv6 service independently from the regular IPv4 service.
ISPによって取られた、IPv4顧客に対するサービスをIPv6に供給した最初の慎重な方法であるとIPv4ネットワークを通してIPv6顧客をIPv6バックボーンに接続するのを考えることができます。 また、いくつかのISPが、サービスを定期的なIPv4サービスからIPv6に独自に供給するのを選ぶかもしれません。
In any case, IPv6 service can be provided by using tunneling techniques. The tunnel may terminate at the CPE corresponding to the IPv4 service or in some other part of the customer's infrastructure (for instance, on IPv6-specific CPE or even on a host).
どのような場合でも、トンネリングのテクニックを使用することによって、IPv6サービスを提供できます。 トンネルはIPv4サービスか顧客のインフラストラクチャのある他の部分(例えばIPv6特有のCPEの上、または、ホストの上でさえ)で対応するCPEで終わるかもしれません。
Several tunneling techniques have already been defined: configured tunnels with tunnel broker, 6to4 [RFC3056], Teredo [TEREDO], and so on. Some of these are based on a specific addressing plan independent of the ISP's allocated prefix(es), while others use a part of the ISP's prefix. In most cases, using the ISP's address space is preferable.
いくつかのトンネリングのテクニックが既に定義されました: トンネルのブローカー(6to4[RFC3056])Teredo[TEREDO]などがある構成されたトンネル。 これらの或るものはISPの割り当てられた接頭語(es)の如何にかかわらず特定のアドレシングプランに基づいています、他のものがISPの接頭語の一部を使用しますが。 多くの場合、ISPのアドレス空間を使用するのは望ましいです。
A key factor is the presence or absence of NATs between the two tunnel end-points. In most cases, 6to4 and ISATAP are incompatible with NATs, and UDP encapsulation for configured tunnels has not been specified.
主要因は、2つのトンネルエンドポイントの間のNATsの存在か不在です。 多くの場合、6to4とISATAPはNATsと非互換です、そして、構成されたトンネルへのUDPカプセル化は指定されていません。
Lind, et al. Informational [Page 13] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[13ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
Dynamic and non-permanent IPv4 address allocation is another factor a tunneling technique may have to deal with. In this case, the tunneling techniques may be more difficult to deploy at the ISP's end, especially if a protocol including authentication (like PPP for IPv6) is not used. This may need to be considered in more detail.
ダイナミックで非永久的なIPv4アドレス配分はトンネリングのテクニックが対処しなければならないかもしれない別の要素です。 この場合、トンネリングのテクニックはISPの終わりに配布するのが、より難しいかもしれません、特に認証(IPv6のためのPPPのような)を含むプロトコルが使用されていないなら。 これは、さらに詳細に考えられる必要があるかもしれません。
However, NAT traversal can be avoided if the NAT supports forwarding protocol-41 [PROTO41] and is configured to do so.
しかしながら、NATが推進がプロトコル-41[PROTO41]であるとサポートして、そうするために構成されるなら、NAT縦断を避けることができます。
Firewalls in the path can also break tunnels of these types. The administrator of the firewall needs to create a hole for the tunnel. This is usually manageable, as long as the firewall is controlled by either the customer or the ISP, which is almost always the case.
また、経路のファイアウォールはこれらのタイプのトンネルを壊すことができます。 ファイアウォールの管理者は、穴をトンネルに作成する必要があります。 通常、これは処理しやすいです、ファイアウォールがほとんどいつもケースである顧客かISPのどちらかによって制御される限り。
When the CPE is performing NAT or firewall functions, terminating the tunnels directly at the CPE typically simplifies the scenario considerably, avoiding the NAT and firewall traversal. If such an approach is adopted, the CPE has to support the tunneling mechanism used, or be upgraded to do so.
CPEがNATかファイアウォール機能を実行しているとき、直接CPEでトンネルを終えると、通常、シナリオはかなり簡略化します、NATとファイアウォール縦断を避けて。 そのようなアプローチが取られるなら、CPEは、使用されるトンネリングメカニズムをサポートしなければならないか、またはそうするためにアップグレードしなければなりません。
5.1.1. Small End Sites
5.1.1. 小さい端のサイト
Tunneling considerations for small end sites are discussed in [UNMANEVA]. These identify solutions relevant to the first category of unmanaged networks. The tunneling requirements applicable in these scenarios are described in [TUNREQS].
[UNMANEVA]で小さい端のサイトへのトンネリング問題について議論します。 これらは非管理されたネットワークの最初のカテゴリに関連しているソリューションを特定します。 これらのシナリオで適切なトンネリング要件は[TUNREQS]で説明されます。
The connectivity mechanisms can be categorized as "managed" or "opportunistic". The former consist of native service or a configured tunnel (with or without a tunnel broker); the latter include 6to4 and, e.g., Teredo -- they provide "short-cuts" between nodes using the same mechanisms and are available without contracts with the ISP.
「管理される」か「便宜主義的である」として接続性メカニズムを分類できます。 前者はネイティブのサービスか構成されたトンネル(トンネルのブローカーのあるなしにかかわらず)から成ります。 そして、後者が6to4を含んでいる、例えば、Teredo--それらは、同じメカニズムを使用することでノードの間の「ショートカット」を提供して、ISPで契約法なしで利用可能です。
The ISP may offer opportunistic services, mainly a 6to4 relay, especially as a test when no actual service is offered yet. At the later phases, ISPs might also deploy 6to4 relays and Teredo servers (or similar) to optimize their customers' connectivity to 6to4 and Teredo nodes.
ISPは便宜主義的なサービス、主に6to4リレーを提供するかもしれません、特にまだ就航を全く提供していないときのテストとして。 また、後期では、ISPは、6to4リレー、彼らの顧客の接続性を6to4に最適化するためにはサーバの、そして、(同様)のTeredo、およびTeredoがノードであると配布するかもしれません。
Opportunistic services are typically based on techniques that don't use IPv6 addresses from the ISP's allocated prefix(es), and the services have very limited functions to control the origin and the number of customers connected to a given relay.
便宜主義的なサービスはISPの割り当てられた接頭語(es)からのIPv6アドレスを使用しないテクニックに通常基づいています、そして、サービスで、発生源を制御する非常に限られた機能と顧客の数を与えられたリレーに関連づけます。
Most interesting are the managed services. When dual-stack is not an option, a form of tunneling must be used. When configured tunneling is not an option (e.g., due to dynamic IPv4 addressing), some form of
最もおもしろいのは、管理されたサービスです。 デュアルスタックがオプションでないときに、トンネリングのフォームを使用しなければなりません。 いつでは、構成されたトンネリングはオプション(例えば、ダイナミックなIPv4アドレシングによる)、何らかのフォームではありませんか。
Lind, et al. Informational [Page 14] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[14ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
automation has to be used. Basically, the options are either to deploy an L2TP architecture (whereby the customers would run L2TP clients and PPP over it to initiate IPv6 sessions) or to deploy a tunnel configuration service. The prime candidates for tunnel configuration are STEP [STEP] and TSP [TSP], which both also work in the presence of NATs. Neither is analyzed further in this document.
オートメーションは使用されなければなりません。 基本的に、オプションはL2TPがアーキテクチャ(顧客がIPv6セッションを開始するためにL2TPクライアントとPPPをそれの上に車で送るだろう)であると配布するか、またはトンネル構成サービスを配布するどちらかです。 トンネル構成の主要な候補は、STEP[STEP]とTSP[TSP]です。(そのTSPはまた、NATsの面前でともに働いています)。 どちらもさらに本書では分析されません。
5.1.2. Large End Sites
5.1.2. 大きい端のサイト
Large end sites usually have a managed network.
大きい端のサイトには、通常、管理されたネットワークがあります。
Dual-stack access service is often a possibility, as the customer network is managed (although CPE upgrades may be necessary).
顧客ネットワークが経営されるとき(CPEアップグレードが必要であるかもしれませんが)、しばしばデュアルスタックアクセス・サービスは可能性です。
Configured tunnels, as-is, are a good solution when a NAT is not in the way and the IPv4 end-point addresses are static. In this scenario, NAT traversal is not typically required. If fine-grained access control is needed, an authentication protocol needs to be implemented.
NATが邪魔をしていないとき、構成されたそのままなトンネルは良いソリューションです、そして、IPv4エンドポイントアドレスは静的です。 このシナリオでは、NAT縦断は通常必要ではありません。 きめ細かに粒状のアクセスコントロールが必要であるなら、認証プロトコルは、実装される必要があります。
Tunnel brokering solutions have been proposed to help facilitate the set-up of a bi-directional tunnel. Such mechanisms are typically unnecessary for large end-sites, as simple configured tunneling or native access can be used instead. However, if such mechanisms would already be deployed, large sites starting to deploy IPv6 might benefit from them in any case.
トンネル仲介ソリューションは、双方向のトンネルのセットアップを容易にするのを助けるために提案されました。 大きい端サイトに、そのようなメカニズムは、代わりに簡単な構成されたトンネリングかネイティブのアクセスを使用できるので、通常不要です。 しかしながら、そのようなメカニズムが既に配布されるなら、どのような場合でも、IPv6を配布し始める大きいサイトはそれらの利益を得るかもしれません。
Teredo is not applicable in this scenario, as it can only provide IPv6 connectivity to a single host, not the whole site. 6to4 is not recommended due to its reliance on the relays and provider- independent address space, which makes it impossible to guarantee the required service quality and manageability large sites typically want.
船食虫はこのシナリオで適切ではありません、全体のサイトではなく、独身のホストにIPv6の接続性を提供できるだけであるとき。 6to4はリレーとプロバイダーの独立しているアドレス空間への信用のため推薦されません。信用は大きいサイトが通常必要とする必要なサービス品質と管理可能性を保証するのを不可能にします。
5.2. User Authentication/Access Control Requirements
5.2. ユーザー認証/アクセス制御要件
User authentication can be used to control who can use the IPv6 connectivity service in the first place or who can access specific IPv6 services (e.g., NNTP servers meant for customers only). The former is described at more length below. The latter can be achieved by ensuring that for all the service-specific IPv4 access lists, there are also equivalent IPv6 access lists.
だれが第一に、IPv6接続性サービスを利用できるか、そして、またはだれが特定のIPv6サービス(例えば顧客だけのために意味されたNNTPサーバ)にアクセスできるかを制御するのにユーザー認証を使用できます。 前者は以下の、より多くの長さで説明されます。 また、すべてのサービス特有のIPv4アクセスリストのために、同等なIPv6アクセスリストがあるのを確実にすることによって、後者を達成できます。
IPv6-specific user authentication is not always required. An example would be a customer of the IPv4 service automatically having access to the IPv6 service. In this case, the IPv4 access control also provides access to the IPv6 services.
IPv6特有のユーザー認証がいつも必要であるというわけではありません。 例は自動的にIPv6サービスに近づく手段を持っているIPv4サービスの顧客でしょう。 また、この場合、IPv4アクセス制御はIPv6サービスへのアクセスを提供します。
Lind, et al. Informational [Page 15] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[15ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
When a provider does not wish to give its IPv4 customers automatic access to IPv6 services, specific IPv6 access control must be performed parallel with the IPv4 access control. This does not imply that different user authentication must be performed for IPv6, but merely that the authentication process may lead to different results for IPv4 and IPv6 access.
プロバイダーがIPv6サービスへの自動アクセスをIPv4顧客に与えたがっていないとき、IPv4アクセス制御に平行に特定のIPv6アクセスコントロールを実行しなければなりません。 これは、IPv6のために異なったユーザー認証を実行しなければなりませんが、単に、認証過程がIPv4とIPv6アクセサリーのための異なった結果につながるかもしれないのを含意しません。
Access control traffic may use IPv4 or IPv6 transport. For instance, RADIUS [RFC2865] traffic related to IPv6 service can be transported over IPv4.
アクセス制御トラフィックはIPv4かIPv6輸送を使用するかもしれません。 例えば、IPv4の上でIPv6サービスに関連するRADIUS[RFC2865]トラフィックは輸送できます。
5.3. Configuration of Customer Equipment
5.3. 顧客設備の構成
The customer connection networks are composed of PE and CPE(s). Usually, each PE connects multiple CPE components to the backbone network infrastructure. This number may reach tens of thousands of customers, or more. The configuration of CPE is difficult for the ISP, and it is even more difficult when it must be done remotely. In this context, the use of auto-configuration mechanisms is beneficial, even if manual configuration is still an option.
顧客接続ネットワークはPEとCPE(s)で構成されます。 通常、各PEは複数のCPEの部品をバックボーンネットワークインフラに接続します。 この数は何万もの顧客、または以上に届くかもしれません。 ISPに、CPEの構成は難しいです、そして、離れて完了していなければならないとき、それはさらに難しいです。 このような関係においては、自動構成メカニズムの使用は手動の構成がオプションであっても有益です。
The parameters that usually need to be provided to customers automatically are as follows:
通常、自動的に顧客に提供される必要があるパラメタは以下の通りです:
- The network prefix delegated by the ISP
- The address of the Domain Name System server (DNS)
- Possibly other parameters (e.g., the address of an NTP
server)
- ISPによって代表として派遣されたネットワーク接頭語--ドメインネームシステムサーバ(DNS)のアドレス--ことによると他のパラメタ(例えば、NTPサーバのアドレス)
When user identification is required on the ISP's network, DHCPv6 may be used to provide configurations; otherwise, either DHCPv6 or a stateless mechanism may be used. This is discussed in more detail in [DUAL-ACCESS].
ユーザ登録名がISPのネットワークで必要であるときに、DHCPv6は構成を提供するのに使用されるかもしれません。 さもなければ、DHCPv6か状態がないメカニズムのどちらかが使用されるかもしれません。 さらに詳細に[DUAL-ACCESS]でこれについて議論します。
Note that when the customer connection network is shared between the users or the ISPs and is not just a point-to-point link, authenticating the configuration of the parameters (especially prefix delegation) requires further study.
顧客接続ネットワークがユーザかISPの間で共有されて、単なるポイントツーポイント接続でないときに、パラメタ(特に接頭語委譲)の構成を認証するのがさらなる研究を必要とすることに注意してください。
As long as IPv4 service is available alongside IPv6, it is not required to auto configure IPv6 parameters in the CPE, except the prefix, because the IPv4 settings may be used.
IPv4サービスがIPv6と並んで利用可能である、それは自動車に必要でない限り、CPEのIPv6パラメタを構成してください、接頭語を除いて、IPv4設定が使用されるかもしれないので。
5.4. Requirements for Traceability
5.4. 追随性のための要件
Most ISPs have some kind of mechanism to trace the origin of traffic in their networks. This also has to be available for IPv6 traffic, meaning that a specific IPv6 address or prefix has to be tied to a
ほとんどのISPには、それらのネットワークでトラフィックの発生源をたどるある種のメカニズムがあります。 また、これもIPv6トラフィックに利用可能でなければなりません、aに結ばれるために特定のIPv6アドレスか接頭語にはある意味
Lind, et al. Informational [Page 16] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[16ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
certain customer, or that records must be maintained of which customer had which address or prefix. This also applies to the customers with tunneled connectivity.
顧客がどのアドレスか接頭語を持っていた確信している顧客、またはその記録を保守しなければなりません。 また、これはトンネルを堀られた接続性で顧客に適用されます。
This can be done, for example, by mapping a DHCP response to a physical connection and storing the result in a database. It can also be done by assigning a static address or prefix to the customer. A tunnel server could also provide this mapping.
例えば、物理接続へのDHCP応答を写像して、データベースの結果を保存することによって、これができます。 また、静的なアドレスか接頭語を顧客に割り当てることによって、それができます。 また、トンネルサーバはこのマッピングを提供するかもしれません。
5.5. Ingress Filtering in the Customer Connection Network
5.5. 顧客で接続ネットワークをフィルターにかけるイングレス
Ingress filtering must be deployed toward the customers, everywhere, to ensure traceability, to prevent DoS attacks using spoofed addresses, to prevent illegitimate access to the management infrastructure, and so on.
追随性を確実にして、偽造しているアドレスを使用することでDoS攻撃を防いで、管理インフラストラクチャなどへの違法なアクセスを防ぐためにいたる所で顧客に向かってイングレスフィルタリングを配布しなければなりません。
Ingress filtering can be done, for example, by using access lists or Unicast Reverse Path Forwarding (uRPF). Mechanisms for these are described in [RFC3704].
例えば、アクセスリストかUnicast Reverse Path Forwarding(uRPF)を使用することによって、イングレスフィルタリングができます。 これらのためのメカニズムは[RFC3704]で説明されます。
5.6. Multihoming
5.6. マルチホーミング
Customers may desire multihoming or multi-connecting for a number of reasons [RFC3582].
顧客は様々な意味で[RFC3582]マルチホーミングかマルチ接続を望むかもしれません。
Mechanisms for multihoming to more than one ISP are still under discussion. One working model would deploy at least one prefix per ISP and choose the prefix from the ISP to which traffic is sent. In addition, tunnels may be used for robustness [RFC3178]. Currently, there are no provider-independent addresses for end-sites. Such addresses would enable IPv4-style multihoming, with associated disadvantages.
1つ以上のISPへのマルチホーミングのためのメカニズムがまだ議論であります。 1人のワーキングモデルが、1ISPあたり少なくとも1つの接頭語を配布して、トラフィックが送られるISPから接頭語を選ぶでしょう。 さらに、トンネルは丈夫さ[RFC3178]に使用されるかもしれません。 現在、端サイトへのどんなプロバイダーから独立しているアドレスもありません。 そのようなアドレスは関連損失に伴うIPv4-スタイルマルチホーミングを可能にするでしょう。
Multi-connecting more than once to one ISP is a simple practice, and this can be done, for example, by using BGP with public or private AS numbers and a prefix assigned to the customer.
1つのISPへの一度より多くのマルチ接続は簡単な習慣です、そして、例えば、顧客に割り当てられる公共の、または、個人的なAS番号と接頭語と共にBGPを使用することによって、これができます。
5.7. Quality of Service
5.7. サービスの質
In most networks, quality of service in one form or another is important.
ほとんどのネットワークでは、サービスの質はあれやこれやの重要です。
Naturally, the introduction of IPv6 should not impair existing Service Level Agreements (SLAs) or similar quality assurances.
当然、IPv6の導入は既存のサービス・レベル・アグリーメント(SLA)か同様の品質保証を損ないません。
During the deployment of the IPv6 service, the service could be best effort or similar, even if the IPv4 service has an SLA. In the end, both IP versions should be treated equally.
IPv6サービスの展開の間、サービスは、ベストエフォート型である、または同様であるかもしれません、IPv4サービスにSLAがあっても。 結局、両方のIPバージョンは等しく扱われるべきです。
Lind, et al. Informational [Page 17] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[17ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
IntServ and DiffServ are equally applicable to IPv6 and IPv4 and work similarly regardless of IP version. Of the two, typically only DiffServ has been implemented.
IntServとDiffServはIPバージョンにかかわらず同様に等しくIPv6とIPv4に適切であり、働いています。 2では、通常唯一のDiffServが実装されました。
Many bandwidth provisioning systems operate with IPv4 assumptions, e.g., taking an IPv4 address or (set of) prefixes for which traffic is reserved or preferred. These systems require special attention when introducing IPv6 support in the networks.
多くの帯域幅食糧を供給するシステムがIPv4仮定で作動して、例えば、IPv4アドレスか(セットされます)接頭語をどのトラフィックに取るかは、予約されるか、または好まれます。 ネットワークでIPv6サポートを導入するとき、これらのシステムは特別な注意を必要とします。
6. Network and Service Operation Actions
6. 操作動作をネットワークでつないで、修理してください。
The network and service operation actions fall into different categories as listed below:
ネットワークとサービス操作動作は以下に記載されているように異なったカテゴリになります:
- Set up IPv6 connectivity to upstream providers and peers
- IPv6 network device configuration: for initial configuration
and updates
- IPv6 network management
- IPv6 monitoring
- IPv6 customer management
- IPv6 network and service operation security
- 上流のプロバイダーと同輩にIPv6の接続性をセットアップしてください--IPv6はデバイス構成をネットワークでつなぎます: 初期の構成とアップデート--IPv6ネットワークマネージメント--IPv6がネットワークでつなぐIPv6モニター(IPv6顧客管理)とサービス操作セキュリティのために
Some of these items will require an available IPv6 native transport layer and others will not.
これらの数個の項目が利用可能なIPv6自然なトランスポート層を必要とするでしょう、そして、他のものは必要にならないでしょう。
As a first step, network device configuration and regular network management operations can be performed over an IPv4 transport, because IPv6 MIBs are also available. Nevertheless, some monitoring functions require the availability of IPv6 transport. This is the case, for instance, when ICMPv6 messages are used by the monitoring applications.
第一歩として、IPv4輸送の上でネットワークデバイス構成とレギュラー・ネットワーク管理操作を実行できます、また、IPv6 MIBsも利用可能であるので。 それにもかかわらず、いくつかの監視機能がIPv6輸送の有用性を必要とします。 例えば、ICMPv6メッセージが監視用途で使用されるとき、これはそうです。
On many platforms, the current inability to retrieve separate IPv4 and IPv6 traffic statistics from dual-stack interfaces for management purposes by using SNMP is an issue.
多くのプラットホームでは、管理目的のためにデュアルスタックインタフェースからSNMPを使用することによって別々のIPv4とIPv6トラフィック統計を検索できない現在のことが問題です。
As a second step, IPv6 transport can be provided for any of these network and service operation facilities.
第2のステップとして、これらのネットワークとサービス操作施設のいずれにもIPv6輸送を提供できます。
7. Future Stages
7. 将来のステージ
At some point, an ISP may want to change to a service that is IPv6 only, at least in certain parts of its network. This transition creates many new cases into which continued maintenance of the IPv4 service must be factored. Providing an IPv6-only service is not much different from the dual IPv4/IPv6 service described in stage 3 except for the need to phase out the IPv4 service. The delivery of IPv4 services over an IPv6 network and the phaseout of IPv4 are issues
何らかのポイントでは、ISPはIPv6専用であるサービスに変化したがっているかもしれません、少なくともネットワークのある部分で。 この変遷は継続的なIPv4サービスのメインテナンスを因数分解しなければならない多くの新しいケースを引き起こします。 サービスをIPv6だけに供給するのはIPv4サービスを段階的に廃止する必要性以外の段階3で説明された二元的なIPv4/IPv6サービスとあまり異なっていません。 IPv6ネットワークの上のIPv4サービスの配送とIPv4の段階的撤去は問題です。
Lind, et al. Informational [Page 18] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[18ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
left for a subsequent document. Note that there are some services which will need to maintain IPv4 connectivity (e.g., authorative and some recursive DNS servers [DNSGUIDE]).
その後のドキュメントのための左。 IPv4の接続性が(例えば、authorativeといくつかの再帰的なDNSサーバ[DNSGUIDE])であると主張する必要があるいくつかのサービスがあることに注意してください。
8. Requirements for Follow-On Work
8. フォローオン仕事のための要件
This section tries to summarize the potential items requiring specification in the IETF.
このセクションはIETFの仕様を必要とする潜在的項目をまとめようとします。
Work items for which an approach was not yet apparent as of this writing are as follows:
アプローチがこの書くことの時点でまだ明らかでなかった仕事項目は以下の通りです:
- A tunnel server/broker mechanism, for the cases where the customer
connection networks cannot be upgraded, needs to be specified
[TUNREQS].
- An IPv6 site multihoming mechanism (or multiple ones) needs to be
developed.
- トンネルのサーバ/ブローカーメカニズムは、顧客接続ネットワークがアップグレードできないケースに指定される[TUNREQS]必要があります。 - IPv6サイトマルチホーミングメカニズム(または、複数のもの)は、開発される必要があります。
Work items which were already fast in progress, as of this writing, are as follows:
この書くこと付けで進行中が既に速かった仕事項目は以下の通りです:
- 6PE for MPLS was identified as a required mechanism, and this is
already in progress [BGPTUNNEL].
- IS-IS for Multiple Topologies was noted as a helpful mechanism in
certain environments; however, it is possible to use alternative
methods to achieve the same end, so specifying this is not
strictly required.
- MPLSのための6PEは必要なメカニズムとして特定されました、そして、これは既に進行しています[BGPTUNNEL]。 - -、役立っているメカニズムとしてある環境でMultiple Topologiesに注意したので。 しかしながら、これを指定するのは厳密に必要でないことで、同じ終わりを達成する別法を使用するのが可能です。
9. Example Networks
9. 例のネットワーク
This section presents a number of different example networks. These will not necessarily match any existing networks but are intended to be useful even when they do not correspond to specific target networks. The purpose is to exemplify the applicability of the transition mechanisms described in this document to a number of different situations with different prerequisites.
このセクションは多くの異なった例のネットワークを提示します。 これらは、必ずどんな既存のネットワークも合わせるというわけではありませんが、特定の目標ネットワークに対応さえしないとき、役に立つことを意図します。 目的は異なった前提条件で本書では多くの異なった状況に説明された変遷メカニズムの適用性を例示することです。
The sample network layout will be the same in each network example. This should be viewed as a specific representation of a generic network with a limited number of network devices. A small number of routers have been used in the examples. However, because the network examples follow the implementation strategies recommended for the generic network scenario, it should be possible to scale the examples to fit a network with an arbitrary number, e.g., several hundreds or thousands of routers.
サンプルネットワークレイアウトはそれぞれのネットワークの例で同じになるでしょう。 これは限られた数のネットワークデバイスによるジェネリックネットワークの特定の代理として見なされるべきです。 少ない数のルータが例で使用されました。 しかしながら、ネットワークの例がジェネリックネットワークシナリオのために推薦された実装戦略に従うので、特殊活字の数字、例えば、数個の数百があるネットワークに合う例か何千ものルータをスケーリングするのは可能であるべきです。
Lind, et al. Informational [Page 19] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[19ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
The routers in the sample network layout are interconnected with each other and with another ISP. The connection to another ISP can be either direct or through an exchange point. A number of customer connection networks are also connected to the routers. Customer connection networks can be, for example, xDSL or cable network equipment.
サンプルネットワークレイアウトにおけるルータは互いと別のISPでインタコネクトされます。 ダイレクトにか交換ポイントを通して別のISPとの接続があることができます。 また、多くの顧客接続ネットワークがルータに接続されます。 例えば、顧客接続ネットワークは、xDSLかケーブルネットワーク設備であるかもしれません。
ISP1 | ISP2
+------+ | +------+
| | | | |
|Router|--|--|Router|
| | | | |
+------+ | +------+
/ \ +-----------------------
/ \
/ \
+------+ +------+
| | | |
|Router|----|Router|
| | | |
+------+ +------+\
| | \ | Exchange point
+------+ +------+ \ +------+ | +------+
| | | | \_| | | | |--
|Router|----|Router|----\|Router|--|--|Switch|--
| | | | | | | | |--
+------+ /+------+ +------+ | +------+
| / | |
+-------+/ +-------+ |
| | | |
|Access1| |Access2|
| | | |
+-------+ +-------+
||||| ||||| ISP Network
----|-----------|----------------------
| | Customer Networks
+--------+ +--------+
| | | |
|Customer| |Customer|
| | | |
+--------+ +--------+
ISP1| ISP2+------+ | +------+ | | | | | |ルータ|--|--|ルータ| | | | | | +------+ | +------+ / \ +----------------------- / \ / \ +------+ +------+ | | | | |ルータ|----|ルータ| | | | | +------+ +------+\ | | \ | 交換ポイント+------+ +------+ \ +------+ | +------+ | | | | \_| | | | |-- |ルータ|----|ルータ|----\|ルータ|--|--|スイッチ|-- | | | | | | | | |-- +------+ /+------+ +------+ | +------+ | / | | +-------+/ +-------+ | | | | | |Access1| |Access2| | | | | +-------+ +-------+ ||||| ||||| ISPネットワーク----|-----------|---------------------- | | 顧客は+をネットワークでつなぎます。--------+ +--------+ | | | | |顧客| |顧客| | | | | +--------+ +--------+
Figure 3: ISP Sample Network Layout
図3: ISPサンプルネットワークレイアウト
Lind, et al. Informational [Page 20] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[20ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
9.1. Example 1
9.1. 例1
Example 1 presents a network built according to the sample network layout with a native IPv4 backbone. The backbone is running IS-IS and IBGP as routing protocols for internal and external routes, respectively. Multiprotocol BGP is used to exchange routes over the connections to ISP2 and the exchange point. Multicast using PIM-SM routing is present. QoS using DiffServ is deployed.
例1はサンプルネットワークレイアウトに従ってネイティブのIPv4バックボーンで造られたネットワークを提示します。 バックボーンが稼働している、-、そして、それぞれ内部の、そして、外部のルートにプロトコルを発送するとしてのIBGP。 Multiprotocol BGPは、ISP2との接続と交換ポイントの上とルートを交換するのに使用されます。 PIM-SMルーティングを使用するマルチキャストは存在しています。 DiffServを使用するQoSが配布されます。
Access 1 is xDSL connected to the backbone through an access router. The xDSL equipment, except for the access router, is considered to be layer 2 only, e.g., Ethernet or ATM. IPv4 addresses are dynamically assigned to the customer with DHCP. No routing information is exchanged with the customer. Access control and traceability are performed in the access router. Customers are separated into VLANs or separate ATM PVCs up to the access router.
アクセス1はアクセスルータを通してバックボーンに接続されたxDSLです。 アクセスルータを除いて、xDSL設備は例えば層2専用であると考えられます。イーサネットかATM。 IPv4アドレスはDHCPと共に顧客にダイナミックに割り当てられます。 顧客と共にルーティング情報を全く交換しません。 アクセスコントロールと追随性はアクセスルータで実行されます。 顧客はVLANsか別々のATM PVCsにアクセスルータまで切り離されます。
Access 2 is "fiber to the building or home" (FTTB/H) connected directly to the backbone router. This connection is considered layer-3-aware, because it uses layer 3 switches and performs access control and traceability through its layer 3 awareness by using DHCP snooping. IPv4 addresses are dynamically assigned to the customers with DHCP. No routing information is exchanged with the customer.
アクセス2は直接バックボーンルータに関連づけられた「ビルかホームへのファイバー」(FTTB/H)です。 この接続は意識していた状態で3を層にすると考えられます、レイヤ3スイッチを使用して、層を通してアクセスコントロールと追随性を実行するので。DHCP詮索を使用するのによる3認識。 IPv4アドレスはDHCPと共に顧客にダイナミックに割り当てられます。 顧客と共にルーティング情報を全く交換しません。
The actual IPv6 deployment might start by enabling IPv6 on a couple of backbone routers, configuring tunnels between them (if not adjacent) and connecting to a few peers or upstream providers (either through tunnels or at an internet exchange).
実際のIPv6展開は2、3のバックボーンルータでIPv6を有効にすることによって、始まるかもしれません、それら(隣接していないなら)の間のトンネルを構成して、数人の同輩か上流のプロバイダー(トンネルを通る、または、インターネット交換における)に接して。
After a trial period, the rest of the backbone is upgraded to dual- stack, and IS-IS, without multi-topology extensions (the upgrade order is considered with care), is used as an IPv6 and IPv4 IGP. During an upgrade until IPv6 customers are connected behind a backbone router, the convexity requirement is not critical: The routers will just not be reachable with IPv6. Software supporting IPv6 could be installed even though the routers would not be used for (customer) IPv6 traffic yet. That way, IPv6 could be enabled in the backbone as needed.
そして、トライアルの期間の後にバックボーンの残りが二元的なスタックにアップグレードする、-、IPv6とIPv4 IGPとしてマルチトポロジー拡大(アップグレード命令は慎重に考えられる)なしで使用されます。 IPv6顧客がバックボーンルータの後ろで接されるまでのアップグレードの間、凸状要件は重要ではありません: ルータはIPv6と共にただ届かないでしょう。 ルータは(顧客)IPv6トラフィックにまだ使用されていなかったでしょうが、IPv6をサポートするソフトウェアはインストールできました。 そのように、必要に応じてバックボーンでIPv6を有効にすることができました。
Separate IPv6 BGP sessions are built similarly to IPv4. Multicast (through SSM and Embedded-RP) and DiffServ are offered at a later phase of the network, e.g., after a year of stable IPv6 unicast operations.
別々のIPv6 BGPセッションは同様にIPv4に組み込まれます。 ネットワークの後期でマルチキャスト(SSMとEmbedded-RPを通した)とDiffServを提供します、例えば、1年間の安定したIPv6ユニキャスト操作の後に。
Offering native service as quickly as possible is important. In the meantime, however, a 6to4 relay may be provided in the meantime for optimized 6to4 connectivity and may also be combined with a tunnel broker for extended functionality. Operating as bridges at Layer 2
できるだけはやくネイティブのサービスを提供するのは重要です。 差し当たり、しかしながら、6to4リレーは、差し当たり最適化された6to4の接続性に提供されて、また、拡張機能性のためにトンネルのブローカーに結合されるかもしれません。 ブリッジとして、Layer2では、作動します。
Lind, et al. Informational [Page 21] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[21ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
only, xDSL equipment does not require changes in CPE: IPv6 connectivity can be offered to the customers by upgrading the PE router to IPv6. In the initial phase, only Router Advertisements are used; DHCPv6 Prefix Delegation can be added as the next step if no other mechanisms are available.
xDSL設備はCPEにおける変化を必要とするだけではありません: PEルータをIPv6にアップグレードさせることによって、IPv6の接続性を顧客に提供できます。 初期位相Router Advertisementsだけは使用されています。 他のどんなメカニズムも利用可能でないなら、次のステップとしてDHCPv6 Prefix Delegationを加えることができます。
The FTTB/H access has to be upgraded to support access control and traceability in the switches, probably by using DHCP snooping or a similar IPv6 capability, but it also has to be compatible with prefix delegation, not just address assignment. This could, however, lead to the necessity to use DHCPv6 for address assignment.
FTTB/Hアクセスはスイッチでアクセスがコントロールと追随性であるとサポートするためにアップグレードしなければなりません、たぶんDHCP詮索か同様のIPv6能力を使用することによって、しかし、また、それもアドレス課題だけではなく、接頭語委譲と互換性がなければなりません。 しかしながら、これはアドレス課題にDHCPv6を使用する必要性に通じるかもしれません。
9.2. Example 2
9.2. 例2
In example 2, the backbone is running IPv4 with MPLS and is using OSPF and IBGP for internal and external routes, respectively. The connections to ISP2 and the exchange point run BGP to exchange routes. Multicast and QoS are not deployed.
例2では、バックボーンは、それぞれMPLSとIPv4を実行して、内部の、そして、外部のルートにOSPFとIBGPを使用していることです。 ISP2との接続と交換ポイントは、ルートを交換するためにBGPを実行します。 マルチキャストとQoSは配布されません。
Access 1 is a fixed line, e.g., fiber, connected directly to the backbone. Routing information is in some cases exchanged with CPE at the customer's site; otherwise static routing is used. Access 1 can also be connected to a BGP/MPLS-VPN running in the backbone.
アクセス1は固定系列、例えば直接バックボーンに接続されたファイバーです。 いくつかの場合、顧客のサイトのCPEと共にルート設定情報を交換します。 さもなければ、スタティックルーティングは使用されています。 また、バックボーンへ駆け込むBGP/MPLS-VPNにアクセス1を接続できます。
Access 2 is xDSL connected directly to the backbone router. The xDSL is layer 2 only, and access control and traceability are achieved through PPPoE/PPPoA. PPP also provides address assignment. No routing information is exchanged with the customer.
アクセス2は直接バックボーンルータに接続されたxDSLです。 xDSLは層2専用です、そして、アクセスコントロールと追随性はPPPoE/PPPoAを通して達成されます。 また、PPPはアドレス課題を提供します。 顧客と共にルーティング情報を全く交換しません。
IPv6 deployment might start with an upgrade of a couple of PE routers to support [BGPTUNNEL], as this will allow large-scale IPv6 support without hardware or software upgrades in the core. In a later phase, native IPv6 traffic or IPv6 LSPs would be used in the whole network. In this case, IS-IS or OSPF could be used for the internal routing, and a separate IPv6 BGP session would be run.
IPv6展開は、2、3のPEルータのアップグレードから[BGPTUNNEL]をサポートし始めるかもしれません、これがコアでハードウェアもソフトウェアの更新なしで大規模なIPv6サポートを許すとき。 後期では、ネイティブのIPv6トラフィックかIPv6 LSPsが全体のネットワークに使用されるでしょう。 または、この場合、-、内部のルーティングにOSPFを使用できて、別々のIPv6 BGPセッションは実行されるでしょう。
For the fixed-line customers, the CPE has to be upgraded, and prefix delegation using DHCPv6 or static assignment would be used. An IPv6 MBGP session would be used when routing information has to be exchanged. In the xDSL case, the same conditions for IP-tunneling apply as in Example 1. In addition to IP-tunneling, a PPP session can be used to offer IPv6 access to a limited number of customers. Later, when clients and servers have been updated, the IPv6 PPP session can be replaced with a combined PPP session for both IPv4 and IPv6. PPP has to be used for address and prefix assignment.
固定系列顧客に関しては、CPEはアップグレードしなければなりません、そして、DHCPv6を使用する接頭語委譲か静的な課題が使用されるでしょう。 ルーティング情報を交換しなければならないとき、IPv6 MBGPセッションを使用するでしょう。 xDSL場合では、IP-トンネリングのための同じ状態はExample1のように適用されます。 IP-トンネリングに加えて、限られた数の顧客へのアクセスをIPv6に提供するのにPPPセッションを使用できます。 その後クライアントとサーバをアップデートしたとき、IPv6 PPPセッションをIPv4とIPv6の両方のための結合したPPPセッションに取り替えることができます。 PPPはアドレスと接頭語課題に使用されなければなりません。
Lind, et al. Informational [Page 22] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[22ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
9.3. Example 3
9.3. 例3
A transit provider offers IP connectivity to other providers, but not to end users or enterprises. IS-IS and IBGP are used internally, and BGP is used externally. Its accesses connect Tier-2 provider cores. No multicast or QoS is used.
トランジットプロバイダーは、IPの接続性を他のプロバイダーに提供しますが、エンドユーザか企業に提供するというわけではありません。 そして、-、IBGPは内部的に使用されて、BGPは外部的に使用されます。 アクセスはTier-2プロバイダーコアを接続します。 マルチキャストかどんなQoSも使用されていません。
As this type of transit provider has a number of customers, who have a large number of customers in turn, it obtains an address allocation from an RIR. The whole backbone can be upgraded to dual-stack in a reasonably short time after a trial with a couple of routers. IPv6 routing is performed by using the same IS-IS process and separate IPv6 BGP sessions.
このタイプのトランジットプロバイダーに多くの顧客(多くの顧客が順番にいます)がいるとき、それはRIRからアドレス配分を得ます。 全体のバックボーンはトライアルの後に適度に短い間に2、3のルータでデュアルスタックにアップグレードできます。 IPv6ルーティングが同じくらい使用することによって実行される、-、IPv6 BGPセッションを処理して、切り離してください。
The ISP provides IPv6 transit to its customers for free, as a competitive advantage. It also provides, at the first phase only, a configured tunnel service with BGP peering to the significant sites and customers (those with an AS number) who are the customers of its customers whenever its own customer networks are not offering IPv6. This is done both to introduce them to IPv6 and to create a beneficial side effect: A bit of extra revenue is generated from its direct customers as the total amount of transited traffic grows.
ISPは競争力において有利な立場としての無料の顧客へのトランジットをIPv6に供給します。 また、それは提供されます、第1段階だけで、BGPがそれ自身の顧客ネットワークがIPv6を提供していないときはいつも、顧客の顧客である重要なサイトと顧客(AS番号があるそれら)としてじっと見ている構成されたトンネルサービス。 ともにIPv6にそれらを紹介して、有益な副作用を引き起こすためにこれをします: 通過しているトラフィックの総量が成長するとき、少しの付加的な収入が直接の顧客から生成されます。
10. Security Considerations
10. セキュリティ問題
This document analyzes scenarios and identifies transition mechanisms that could be used for the scenarios. It does not introduce any new security issues. Security considerations of each mechanism are described in the respective documents.
このドキュメントは、シナリオを分析して、シナリオに使用できた変遷メカニズムを特定します。 それは少しの新しい安全保障問題も紹介しません。 それぞれのメカニズムのセキュリティ問題はそれぞれのドキュメントで説明されます。
However, a few generic observations are in order.
しかしながら、いくつかのジェネリック観測が整然としています。
o Introducing IPv6 adds new classes of security threats or
requires adopting new protocols or operational models than
those for IPv4; typically these are generic issues, to be
discussed further in other documents, for example, [V6SEC].
o IPv6を導入するのは、IPv4のためのそれらより新しいクラスの軍事的脅威を言い足すか、または新しいプロトコルかオペレーショナル・モデルを採用するのを必要とします。 通常これらは、例えば、他のドキュメントで、より詳しく議論する[V6SEC]ためにはジェネリック問題です。
o The more complex the transition mechanisms employed become, the
more difficult it will be to manage or analyze their impact on
security. Consequently, simple mechanisms are preferable.
o 使われた変遷メカニズムが複雑であれば複雑であるほど、セキュリティでそれらの影響を管理するか、または分析するのがそれが、より難しくなるでしょう。 その結果、簡単なメカニズムは望ましいです。
o This document has identified a number of requirements for
analysis or further work that should be explicitly considered
when adopting IPv6: how to perform access control over shared
media or shared ISP customer connection media, how to manage
the configuration management security on such environments
o このドキュメントはIPv6を採用するとき明らかに考えられるべきである分析かさらなる仕事のための多くの要件を特定しました: 共有されたメディアか共有されたISP顧客接続メディア、そのような環境でどう構成管理セキュリティを管理するかのアクセスコントロールを実行する方法
Lind, et al. Informational [Page 23] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[23ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
(e.g., DHCPv6 authentication keying), and how to manage
customer traceability if stateless address autoconfiguration is
used.
(例えば、DHCPv6認証の合わせること)で、管理するのに、顧客の追随性は、状態がないアドレス自動構成であるならどう使用されているか。
11. Acknowledgments
11. 承認
This document has greatly benefited from input by Marc Blanchet, Jordi Palet, Francois Le Faucheur, Ronald van der Pol, and Cleve Mickles.
このドキュメントは大いにマークBlanchet、ジョルディPalet、フランソアLe Faucheur、ロナルドバンder Pol、およびクリーブMicklesで入力の利益を得ました。
Special thanks to Richard Graveman and Michael Lambert for proofreading the document.
リチャードGravemanとマイケル・ランバートのおかげで、ドキュメントを校正するのにおいて、特別です。
12. Informative References
12. 有益な参照
[EMBEDRP] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", RFC
3956, November 2004.
[EMBEDRP] Savola、P.、およびB.ハーバーマン、「ランデブーポイント(RP)を埋め込んで、IPv6でマルチキャストアドレスを扱ってください」、RFC3956、2004年11月。
[MTISIS] Przygienda, T., Naiming Shen, Nischal Sheth, "M-ISIS:
Multi Topology (MT) Routing in IS-IS", Work in
Progress.
[MTISIS]Przygienda、T.、Naimingシン、Nischal Sheth、「Mイシス:」 「中のマルチトポロジー(MT)ルート設定、-、」 仕事進行中です。
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June
2000.
[RFC2858] ベイツ、T.、Rekhter、Y.、チャンドラ、R.、およびD.キャッツ、「BGP-4インチのためのMultiprotocol拡張子、RFC2858、2000年6月。」
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545,
March 1999.
[RFC2545]マルケスとP.とF.デュポン、「BGP-4 Multiprotocol拡張子のIPv6相互ドメインルート設定の使用」、RFC2545、1999年3月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.とP.Savola、「Multihomedのためにネットワークをフィルターにかけるイングレス」BCP84、2004年3月のRFC3704。
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6
Site-Multihoming Architectures", RFC 3582, August
2003.
[RFC3582] Abley、J.、黒、B.、およびV.エラ、「IPv6サイトマルチホーミングアーキテクチャの目標」、RFC3582、2003年8月。
[RFC3178] Hagino, J. and H. Snyder, "IPv6 Multihoming Support at
Site Exit Routers", RFC 3178, October 2001.
[RFC3178] HaginoとJ.とH.スナイダー、「サイト出口ルータにおけるIPv6マルチホーミングサポート」、RFC3178、2001年10月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6
Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] 大工とB.とK.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、RFC3056、2001年2月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
Lind, et al. Informational [Page 24] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[24ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
[BGPTUNNEL] De Clercq, J., Gastaud, G., Ooms, D., Prevost, S., Le
Faucheur, F., "Connecting IPv6 Islands across IPv4
Clouds with BGP", Work in Progress.
[BGPTUNNEL]De Clercq、J.、Gastaud、G.、オームス、D.、プレヴォー、S.、Le Faucheur、F.、「IPv4の向こう側にIPv6諸島をつなげるのはBGPと共に曇ります」、処理中の作業。
[DUAL-ACCESS] Shirasaki, Y., Miyakawa, S., Yamasaki, T., Takenouchi,
A., "A Model of IPv6/IPv4 Dual Stack Internet Access
Service", Work in Progress.
[二元的なアクセス]Shirasaki、Y.、Miyakawa、S.、山崎、T.、A.、「IPv6/IPv4デュアルスタックインターネットアクセス・サービスのモデル」というTakenouchiは進行中で働いています。
[STEP] Savola, P., "Simple IPv6-in-IPv4 Tunnel Establishment
Procedure (STEP)", Work in Progress.
P.、「簡単なIPv4のIPv6トンネル設立手順(ステップ)」という[ステップ]Savolaは進行中で働いています。
[TSP] Blanchet, M., "IPv6 Tunnel Broker with Tunnel Setup
Protocol (TSP)", Work in Progress.
M.、「トンネルセットアッププロトコル(ティースプーンフル)をもっているIPv6トンネルのブローカー」という[ティースプーンフル]Blanchetは進行中で働いています。
[TUNREQS] Palet, J., Nielsen, K., Parent, F., Durand, A.,
Suryanarayanan, R., and P. Savola, "Goals for
Tunneling Configuration", Work in Progress, February
2005.
[TUNREQS]殻、J.、ニールセン、K.、親、F.、ジュランド、A.、Suryanarayanan、R.、およびP.Savola、「トンネリング構成の目標」が進行中(2005年2月)で働いています。
[UNMANEVA] Huitema, C., Austein, R., Satapati, S., van der Pol,
R., "Evaluation of Transition Mechanisms for Unmanaged
Networks", Work in Progress.
[UNMANEVA]Huitema、C.、Austein、R.、der Pol、R.、「Unmanagedネットワークのための変遷メカニズムの評価」(ProgressのWork)をSatapati(S.)はバンに積みます。
[PROTO41] Palet, J., Olvera, C., Fernandez, D., "Forwarding
Protocol 41 in NAT Boxes", Work in Progress.
[PROTO41] 「NAT箱の中にプロトコル41を進め」て、殻、J.、オルベラ、C.、フェルナンデス、D.は進行中で働いています。
[V6SEC] Savola, P., "IPv6 Transition/Co-existence Security
Considerations", Work in Progress.
P.、「IPv6変遷/共存セキュリティ問題」という[V6SEC]Savolaは進行中で働いています。
[DNSGUIDE] Durand, A., Ihren, J., "DNS IPv6 transport operational
guidelines", Work in Progress.
[DNSGUIDE] ジュランド、A.、Ihren、J.、「DNS IPv6は運用指針を輸送する」ProgressのWork。
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs", Work in Progress.
[船食虫]Huitema、C.、「船食虫:」 「NATsを通してUDPの上でIPv6にトンネルを堀っ」て、進行中で働いてください。
Lind, et al. Informational [Page 25] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[25ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
Appendix A: Convexity Requirements in Single Topology IS-IS
付録A: 単一のトポロジーの凸状要件、-
The single-topology IS-IS convexity requirements could be summarized, from IPv4/6 perspective, as follows:
単一のトポロジー、-、凸状要件、以下の通りIPv4/6見解からまとめることができました:
1) "any IP-independent path from an IPv4 router to any other IPv4
router must only go through routers which are IPv4-capable", and
1) そして「どんなIPv4ルータからいかなる他のIPv4ルータまでのIP-独自路線もIPv4できるルータに直面するだけでよい」。
2) "any IP-independent path from an IPv6 router to any other IPv6
router must only go through routers which are IPv6-capable".
2) 「どんなIPv6ルータからいかなる他のIPv6ルータまでのIP-独自路線もIPv6できるルータに直面するだけでよいです。」
As IS-IS is based upon CLNS, these are not trivially accomplished. The single-topology IS-IS builds paths which are agnostic of IP versions.
-、CLNSに基づいて、これらは些細なことに達成されません。 単一のトポロジー、-、IPバージョンの不可知論者であることの経路を造ります。
Consider an example scenario of three IPv4/IPv6-capable routers and an IPv4-only router:
3の例のシナリオがIPv4/IPv6できるルータとIPv4だけルータであると考えてください:
cost 5 R4 cost 5
,------- [v4/v6] -----.
/ \
[v4/v6] ------ [ v4 ] -----[v4/v6]
R1 cost 3 R3 cost 3 R2
5R4に費用5かかってください。------- [v4/v6]-----. /\[v4/v6]------ [v4]-----[v4/v6]R1費用3R3は3R2かかります。
Here the second requirement would not hold. IPv6 packets from R1 to R2 (or vice versa) would go through R3, which does not support IPv6, and the packets would get discarded. By reversing the costs between R1-R3, R3-R2 and R1-R4,R4-R2 the traffic would work in the normal case, but if a link fails and the routing changes to go through R3, the packets would start being discarded again.
ここで、2番目の要件は成立しないでしょう。 R1からR2(逆もまた同様である)までのIPv6パケットはR3を通るでしょう、そして、パケットは捨てられるでしょう。(R3はIPv6をサポートしません)。 R1-R3とR3-R2とR1-R4、R4-R2の間のコストを逆にすることによって、トラフィックは正常な場合で働いているでしょうが、リンクが失敗して、ルーティングがR3を通るために変化するなら、パケットは、再び捨てられ始めるでしょう。
Lind, et al. Informational [Page 26] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[26ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
Authors' Addresses
作者のアドレス
Mikael Lind TeliaSonera Vitsandsgatan 9B SE-12386 Farsta, Sweden
マイケルリンドTeliaSonera Vitsandsgatan 9B SE-12386 Farsta、スウェーデン
EMail: mikael.lind@teliasonera.com
メール: mikael.lind@teliasonera.com
Vladimir Ksinant Thales Communications 160, boulevard de Valmy 92704 Colombes, France
ウラジミールKsinant Thales Communications160、de Valmy92704コロンブ、並木街フランス
EMail: vladimir.ksinant@fr.thalesgroup.com
メール: vladimir.ksinant@fr.thalesgroup.com
Soohong Daniel Park Mobile Platform Laboratory, SAMSUNG Electronics. 416, Maetan-3dong, Paldal-Gu, Suwon, Gyeonggi-do, Korea
Soohongダニエルはモバイルプラットホーム研究所、三星エレクトロニクスを駐車します。 416 Maetan-3dong、Paldal-Gu、水原の、そして、Gyeonggiしている韓国
EMail: soohong.park@samsung.com
メール: soohong.park@samsung.com
Alain Baudot France Telecom R&D Division 42, rue des coutures 14066 Caen - FRANCE
アランBaudotフランステレコム研究開発事業部42、悔悟des洋裁14066カーン--フランス
EMail: alain.baudot@francetelecom.com
メール: alain.baudot@francetelecom.com
Pekka Savola CSC/FUNET Espoo, Finland
ペッカ・Savola CSC/FUNETエスポー(フィンランド)
EMail: psavola@funet.fi
メール: psavola@funet.fi
Lind, et al. Informational [Page 27] RFC 4029 ISP Networks IPv6 Scenarios March 2005
リンド、他 情報[27ページ]のRFC4029ISPは2005年のシナリオ行進のときにIPv6をネットワークでつなぎます。
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機能のための基金は現在、インターネット協会によって提供されます。
Lind, et al. Informational [Page 28]
リンド、他 情報[28ページ]
一覧
スポンサーリンク
