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
Scenarios and Analysis for Introducing IPv6 into ISP Networks
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).
著作権（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サービスを中断することなく、ISPの既存のIPv4ネットワークにIPv6を導入するためのさまざまなシナリオについて説明します。 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
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
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接続とグローバルアドレス空間を顧客に提供することです。 新しいIPv6サービスを既存のIPv4サービスに追加する必要があり、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を追加するさまざまな方法を見つけます。 このドキュメントでは、ISPのIPv4ネットワークに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のみのサービスを取り巻く問題をカバーしていません。 また、さまざまな種類のアクセスまたはネットワークテクノロジーについて説明することも、このドキュメントの範囲外です。
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間で共有する必要があります。 使用される顧客接続ネットワークのタイプ（たとえば、レイヤー2デバイスのみが関係するネットワークまたは非IPテクノロジーが関係するネットワーク）に応じて、この制約により、このドキュメントに関連するアーキテクチャ上の考慮事項が生じる場合があります。
The basic components in the ISP's network are depicted in Figure 1.
ISPのネットワークの基本的なコンポーネントを図1に示します。
------------ ----------
| 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|
| | | | | |
+--------+ +--------+ +--------+
Figure 1: ISP Network Topology
図1：ISPネットワークトポロジ
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のネットワークは絶えず進化しているため、段階は、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.
異なるステージ間で自由に移行することが可能です。 ネットワークセグメントは一度に1つのステージにしか存在できませんが、ISPのネットワーク全体は異なるステージに存在できます。 最初の段階から最終段階まで、さまざまな移行パスをたどることができます。 2つのステージ間の遷移は、瞬時である必要はありません。 徐々に発生する可能性があります。
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から少なくとも/ 32 IPv6プレフィックスの割り当てに適格なISPに適用されるシナリオのみが対象です。
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
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はステージ2bを介して現在のIPv4ネットワークをIPv4 / IPv6デュアルスタックネットワークにアップグレードできますが、既存の構成に単純なトンネルメカニズムを追加することにより、IPv6サービスをわずかなコストで実装することもできます。 新しいネットワークを設計する場合、レガシーの懸念がないため、ステージ3が最初または最後のステップになる場合があります。 それでも、ネットワーク機器にIPv6機能がないことは、依然として制限要因になる可能性があります。
Note that in every stage except Stage 1, the ISP can offer both IPv4 and IPv6 services to its customers.
ステージ1を除くすべてのステージで、ISPはIPv4サービスとIPv6サービスの両方を顧客に提供できることに注意してください。
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を提供することを目標に、段階1から他の段階に移行（移行）できます。
The immediate first step consists of obtaining a prefix allocation (typically a /32) from the appropriate RIR (e.g., AfriNIC, APNIC, ARIN, LACNIC, RIPE) according to allocation procedures.
即時の最初のステップは、割り当て手順に従って適切なRIR（AfriNIC、APNIC、ARIN、LACNIC、RIPEなど）からプレフィックス割り当て（通常/ 32）を取得することです。
The 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.
通常、ピアへの接続は、直接またはインターネット交換ポイント（IX）で確立できます。 ほとんどのIXは、IPv6が使いやすい技術を使用しており、多くのIXはすでにIPv6ピアリングのインフラストラクチャを提供しています。 このようなピアリングは、IPv6を使用してネイティブに実行できます。 IPv6-in-IPv4トンネルを介したピアリングも可能ですが、少なくとも長期的には推奨されません。 ピアへの直接接続は、IPv4のピアへの直接接続がある場合に実行可能です。
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のみの顧客接続ネットワークと、IPv4とIPv6の両方をサポートするバックボーンを持つISPを扱います。 特に、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接続を提供できます。
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バックボーンネットワークを備えたISPと、IPv4とIPv6の両方をサポートする顧客接続ネットワークで構成されます。 顧客へのサービスはネイティブIPv6であるため、顧客はIPv4とIPv6の両方をサポートする必要はありません。 これは前の段階との最大の違いです。 IPv6トラフィックを交換する必要性は依然として存在しますが、バックボーンがIPv6対応ではないため、前のケースよりも複雑になる可能性があります。 ステージ2bの完了後、元のIPv4バックボーンは変更されていません。 つまり、IPv6トラフィックは、既存のIPv4バックボーン上をトンネリングするか、IPv4バックボーンから多少分離された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によってNATされた）またはパブリックIPv4アドレスを使用してIPv4接続を提供し続けます。 多くの場合、顧客は自分のNATも持っています。 その場合、これはおそらくIPv4接続に引き続き使用されます。
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.
ステージ3は、少なくともこのドキュメントの範囲内で、IPv6を導入する最終ステップと見なすことができます。 この段階は、バックボーンネットワークと顧客接続ネットワークの両方でIPv6とIPv4をネイティブにサポートするユビキタスIPv6サービスで構成されています。 顧客の観点から見ると、顧客接続ネットワークは変更されていないため、前の段階と同じです。 IPv6トラフィックを交換するための要件は、ステージ2の要件と同じです。
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成熟度の異なるアクセステクノロジーを使用する場合があります。 これにより、ステージ2aと3の組み合わせが発生する場合があります。一部のカスタマー接続はIPv6をサポートしませんが、他のカスタマー接続はサポートします。 どちらの場合も、バックボーンはデュアルスタックです。
This scenario is equivalent to Stage 2a, but it requires support for native IPv6 customer connections on some access technologies.
このシナリオはステージ2aと同等ですが、一部のアクセステクノロジーでネイティブIPv6カスタマー接続をサポートする必要があります。
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.
移行はIPv4 ISPで始まり、3つの方向のいずれかに進みます。 この選択は、さまざまな移行シナリオに対応しています。 ステージ2aでは、最初にバックボーンをアップグレードします。 ステージ2bは、顧客接続ネットワークのアップグレードで構成されます。 最後に、ステージ3では、必要に応じてバックボーン接続と顧客接続の両方に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 to remove non-IPv6-capable hardware from the network may be significant.
ほとんどのISPバックボーンIPv4ネットワークは絶えず進化しているため（ルーターのファームウェアの交換、新しいルーターなど）、追加の投資なしでIPv6に対応できます（スタッフトレーニングを除く）。 この移行パスは、実際の顧客の要求なしにIPv6の導入を可能にするため、より遅いかもしれませんが、それでも有用です。 このアプローチは、土壇場ですべてを行うよりも優れている場合があり、より高い投資が必要になる場合があります。 ただし、最初からすべての新しい機器のIPv6機能を検討する（およびベンダーに要求する）ことが重要です。 そうしないと、ネットワークから非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バックボーンをデュアルスタックバックボーンに変換します。 このアクションは、直接または中間ステップを介して実行できます。
* 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カスタマー接続ネットワークをデュアルスタックネットワークに変換します。
* 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.
-ネットワークおよびサービス操作のセキュリティを実装します。
Sections 4, 5, and 6 contain detailed descriptions of each action.
セクション4、5、および6には、各アクションの詳細な説明が含まれています。
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
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.
要するに、各中間ステップは可能ですが、必須ではありません。
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 network; both LDP and RSVP-TE can set up IPv6 LSPs, but this might require upgrade/change in the MPLS core network.
MPLSがバックボーンに既に展開されている場合、IPv6-over-MPLS接続を提供することが望ましい場合があります。 ただし、IPv6ラベルスイッチドパス（LSP）をセットアップするには、MPLSネットワークを介したシグナリングが必要です。 LDPとRSVP-TEの両方でIPv6 LSPをセットアップできますが、これには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-over-IPv4 / MPLS。 検討中の特定の環境に応じて、いくつかの可能性が他よりも望ましい場合があります。 アプローチは次のように思われます：
1) Require that MPLS networks deploy native IPv6 routing and
forwarding support.
2) Require that MPLS networks support native routing and setting up of IPv6 LSPs, used for IPv6 connectivity.
2）MPLSネットワークがIPv6接続に使用されるIPv6 LSPのネイティブルーティングとセットアップをサポートすることを要求します。
3) Use only configured tunneling over IPv4 LSPs.
3）IPv4 LSPで設定されたトンネリングのみを使用します。
4) Use [BGPTUNNEL] to perform IPv6-over-IPv4/MPLS encapsulation for IPv6 connectivity.
4）[BGPTUNNEL]を使用して、IPv6接続のIPv6-over-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）は不可能な場合があります。 アプローチ2）ISPがMPLSコントロールプレーンでIPv6 LSPセットアップサポートを追加することを望まない、または追加できない場合、不可能な場合があります。
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）は、追加のメカニズムを必要としないが、特にIPv6が広く展開されている場合、大規模なネットワークでスケーラビリティが不足する可能性があることを除いて、アプローチ4）とほぼ同等です。
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パラメーターは手動で構成する必要があります。
ISPs need routing protocols to advertise reachability and to find the shortest working paths, both internally and externally.
ISPは、内部および外部の両方で到達可能性をアドバタイズし、最短作業パスを見つけるためにルーティングプロトコルを必要とします。
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またはIS-ISがIPv4 IGPとして使用されます。 OSPFおよびIS-ISは優れたIGPであるため、RIPv2は通常、サービスプロバイダーネットワークでは使用されません。 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専用である場合があります。 この場合、ルーティングプロトコルは複数のトポロジを理解して対処できる必要があります。
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を選択する必要があります。IPv6のOSPFv3またはIS-ISのいずれかです。 RIPngは、RIPv2がIPv4にも適切でないため、ほとんどのコンテキストでは適切ではないため、ここでは説明しません。 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、IPv6のIS-IS（のみ）o IPv4のOSPFv2、IPv6のOSPFv3、またはo IPv4のIS-IS、IPv6のOSPFv3
- With the same process: o IS-IS for both IPv4 and IPv6
-同じプロセスで：o IPv4とIPv6の両方のIS-IS
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.
IS-ISがIPv4とIPv6の両方に使用される場合、マルチトポロジIS-IS拡張[MTISIS]が実装されていない限り、IPv4 / IPv6トポロジは「凸」でなければなりません（IPv4のみまたはIS-IS IPv6には凸性は必要ありません）。 より単純なネットワークで、またはIS-ISリンクコストを慎重に計画すると、不適合なIPv4 / IPv6トポロジでさえ「凸」を保つことができます。 凸性の問題については、付録Aの例を使用して詳細に説明します。
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.
短期的にフルデュアルスタックを展開する場合は、シングルトポロジIS-ISを使用することをお勧めします。 これは、一部の大規模なISPに特に適用可能です。 他のシナリオでは、1つまたは2つの別々のプロセスを選択することは、多くの場合、IPv4ルーティングインフラストラクチャに対する認識されているリスク、つまり、当面の間それらを別々に保ちたいかどうかに依存します。 これが要因ではない場合、通常、2つのプロトコルとトポロジを管理する必要がないという運用上の理由から、単一のプロセスを使用することをお勧めします。
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以外のルーティングプロトコルを実装しない場合があります。 したがって、場合によっては、上記のIGPの1つに加えて、少なくとも限られた方法でRIPngを実行し、その後、何らかのメカニズムによってルーティングプロトコル間でルーティング情報を再配布する必要があります。
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.
マルチプロトコル拡張機能を備えたBGP [RFC2858]は、IPv6 [RFC2545]に使用できます。 これらの拡張により、IPv6ルーティング情報の交換と、IPv6を介したTCPを使用した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.
1つのBGPセッションを使用して、2つのピア間でIPv4とIPv6の両方のプレフィックスをアドバタイズすることができます。 ただし、現在最も一般的な方法は、個別のBGPセッションを使用することです。
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の論理トポロジは異なる場合があります。
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を使用して交換されますが、MSDPはIPv6用に意図的に定義されていません。 代わりに、PIM-SSMまたは情報を伝達するための代替メカニズム[EMBEDRP]のみを使用する必要があります。
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.
顧客接続ネットワークは通常、多数のCPEに接続された少数のPEで構成され、顧客のタイプやサイズ、必要な帯域幅、さらにはサービスの品質に応じて異なるテクノロジーに基づいている場合があります。 公共の顧客に使用される小さな管理されていない接続ネットワークは、通常、管理されたネットワークを通常実行する大規模な顧客に使用されるものとは異なる技術（ダイヤルアップや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.
IPv4ネットワークを介してIPv6顧客をIPv6バックボーンに接続することは、ISPがIPv4顧客に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サービスに対応するCPE、または顧客のインフラストラクチャの他の部分（たとえば、IPv6固有の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の割り当てられたプレフィックスとは独立した特定のアドレス指定計画に基づいていますが、その他は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つのトンネルエンドポイント間のNATの有無です。 ほとんどの場合、6to4およびISATAPはNATと互換性がなく、構成されたトンネルのUDPカプセル化は指定されていません。
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アドレスの割り当ては、トンネリング技術が対処しなければならない別の要因です。 この場合、特に認証を含むプロトコル（IPv6のPPPなど）が使用されていない場合、ISPの端にトンネリング技術を展開するのがより困難になる可能性があります。 これをより詳細に検討する必要がある場合があります。
However, NAT traversal can be avoided if the NAT supports forwarding protocol-41 [PROTO41] and is configured to do so.
ただし、NATがprotocol-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は使用されるトンネリングメカニズムをサポートするか、そうするためにアップグレードする必要があります。
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リレーとTeredoサーバー（または同様のもの）を展開して、6to4および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に割り当てられたプレフィックスからの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 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.
最も興味深いのはマネージドサービスです。 デュアルスタックがオプションではない場合、トンネリングの形式を使用する必要があります。 構成されたトンネリングがオプションではない場合（動的IPv4アドレス指定など）、何らかの形式の自動化を使用する必要があります。 基本的に、オプションは、L2TPアーキテクチャを展開する（これにより、顧客はL2TPクライアントとPPPを実行してIPv6セッションを開始する）か、トンネル構成サービスを展開します。 トンネル構成の主要な候補はSTEP [STEP]とTSP [TSP]であり、どちらもNATが存在する場合でも機能します。 このドキュメントでは、どちらも詳しく分析しません。
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.
Teredoは、サイト全体ではなく単一のホストにのみIPv6接続を提供できるため、このシナリオには適用できません。 6to4は、リレーやプロバイダーに依存しないアドレススペースに依存しているため、大規模なサイトが通常必要とする必要なサービス品質と管理性を保証できないため、推奨されません。
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固有のユーザー認証は必ずしも必要ではありません。 たとえば、IPv4サービスの顧客がIPv6サービスに自動的にアクセスできます。 この場合、IPv4アクセス制御は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.
プロバイダーがIPv4顧客にIPv6サービスへの自動アクセスを許可したくない場合、特定のIPv6アクセス制御をIPv4アクセス制御と並行して実行する必要があります。 これは、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トランスポートを使用できます。 たとえば、IPv6サービスに関連するRADIUS [RFC2865]トラフィックは、IPv4で転送できます。
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で構成されています。 通常、各PEは複数のCPEコンポーネントをバックボーンネットワークインフラストラクチャに接続します。 この数は、数万人以上の顧客に届く場合があります。 CPEの構成はISPにとって困難であり、リモートで行う必要がある場合はさらに困難です。 このコンテキストでは、手動構成が依然としてオプションである場合でも、自動構成メカニズムの使用は有益です。
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)
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のネットワークでユーザーIDが必要な場合、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とともに使用できる限り、IPv4設定が使用される可能性があるため、プレフィックスを除き、CPEでIPv6パラメーターを自動構成する必要はありません。
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 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.
ほとんどのISPには、ネットワーク内のトラフィックの発信元を追跡する何らかのメカニズムがあります。 これはIPv6トラフィックでも利用可能でなければなりません。つまり、特定のIPv6アドレスまたはプレフィックスを特定の顧客に結び付けるか、どの顧客がどのアドレスまたはプレフィックスを持っているかを記録する必要があります。 これは、トンネル接続の顧客にも適用されます。
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応答を物理接続にマッピングし、結果をデータベースに保存することで実行できます。 また、静的アドレスまたはプレフィックスを顧客に割り当てることでも実行できます。 トンネルサーバーもこのマッピングを提供できます。
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].
イングレスフィルタリングは、たとえば、アクセスリストまたはユニキャストリバースパス転送（uRPF）を使用して実行できます。 これらのメカニズムは[RFC3704]で説明されています。
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.
複数のISPへのマルチホーミングのメカニズムについてはまだ議論中です。 1つの動作モデルは、ISPごとに少なくとも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を使用することで実行できます。
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バージョンを同等に扱う必要があります。
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はIPv6とIPv4に等しく適用可能であり、IPバージョンに関係なく同様に機能します。 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サポートを導入するときに特別な注意が必要です。
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.
最初のステップとして、IPv6 MIBも利用できるため、ネットワークデバイスの構成と通常のネットワーク管理操作をIPv4トランスポートを介して実行できます。 それでも、一部の監視機能では、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トランスポートを提供できます。
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 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]).
ある時点で、ISPは少なくともそのネットワークの特定の部分でIPv6のみのサービスに変更したい場合があります。 この移行により、IPv4サービスの継続的なメンテナンスを考慮する必要がある多くの新しいケースが作成されます。 IPv6のみのサービスを提供することは、IPv4サービスを段階的に廃止する必要があることを除いて、ステージ3で説明したデュアルIPv4 / IPv6サービスとそれほど変わりません。 IPv6ネットワークを介したIPv4サービスの配信とIPv4の段階的廃止は、後続のドキュメントに残された問題です。 IPv4接続を維持する必要があるサービスがいくつかあることに注意してください（たとえば、権限のあるDNSサーバーといくつかの再帰DNSサーバー[DNSGUIDE]）。
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]。 -複数のトポロジのIS-ISは、特定の環境で役立つメカニズムとして注目されました。 ただし、同じ目的を達成するために別の方法を使用することもできます。そのため、これを厳密に指定する必要はありません。
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.
サンプルのネットワークレイアウトは、各ネットワークの例で同じです。 これは、限られた数のネットワークデバイスを持つ一般的なネットワークの特定の表現と見なされる必要があります。 この例では、少数のルーターが使用されています。 ただし、ネットワークの例は一般的なネットワークシナリオで推奨される実装戦略に従うため、ネットワークを任意の数、たとえば数百または数千のルーターに適合するように例を拡大することが可能です。
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|
| | | |
+--------+ +--------+
Figure 3: ISP Sample Network Layout
図3：ISPのサンプルネットワークレイアウト
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バックボーンを持つサンプルネットワークレイアウトに従って構築されたネットワークを示しています。 バックボーンは、内部ルートと外部ルートのルーティングプロトコルとしてそれぞれIS-ISとIBGPを実行しています。 マルチプロトコル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を使用して顧客に動的に割り当てられます。 ルーティング情報は顧客と交換されません。 アクセス制御とトレーサビリティは、アクセスルータで実行されます。 お客様は、アクセスルータまでVLANまたは個別のATM PVCに分割されます。
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スイッチを使用し、DHCPスヌーピングを使用してレイヤー3認識を通じてアクセス制御とトレーサビリティを実行するため、レイヤー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展開は、いくつかのバックボーンルーターで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.
試用期間の後、バックボーンの残りの部分はデュアルスタックにアップグレードされ、IS-ISはマルチトポロジ拡張なしで（アップグレードの順序は慎重に考慮されます）、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 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.
できるだけ早くネイティブサービスを提供することが重要です。 ただし、その間に、最適化された6to4接続のために6to4リレーが提供される可能性があります。また、拡張機能のためにトンネルブローカーと組み合わせることができます。 レイヤー2のみでブリッジとして動作するxDSL機器は、CPEの変更を必要としません。PEルーターをIPv6にアップグレードすることにより、IPv6接続を顧客に提供できます。 初期フェーズでは、ルーターアドバタイズのみが使用されます。 DHCPv6プレフィックス委任は、他のメカニズムが利用できない場合、次の手順として追加できます。
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を使用する必要が生じる可能性があります。
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と交換されます。 それ以外の場合は、静的ルーティングが使用されます。 アクセス1は、バックボーンで実行されているBGP / MPLS-VPNに接続することもできます。
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の展開は、[BGPTUNNEL]をサポートするためにいくつかのPEルーターのアップグレードから開始される可能性があります。これにより、コアでハードウェアまたはソフトウェアをアップグレードせずに大規模なIPv6サポートが可能になります。 後のフェーズでは、ネイティブIPv6トラフィックまたはIPv6 LSPがネットワーク全体で使用されます。 この場合、内部ルーティングにIS-ISまたは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の場合、例1と同じIPトンネリングの条件が適用されます。IPトンネリングに加えて、PPPセッションを使用して、限られた数の顧客にIPv6アクセスを提供できます。 後で、クライアントとサーバーが更新されたら、IPv6 PPPセッションをIPv4とIPv6の両方の結合PPPセッションに置き換えることができます。 アドレスとプレフィックスの割り当てにはPPPを使用する必要があります。
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接続を提供しますが、エンドユーザーまたは企業には提供しません。 IS-ISと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からアドレス割り当てを取得します。 いくつかのルーターで試用した後、バックボーン全体をかなり短い時間でデュアルスタックにアップグレードできます。 IPv6ルーティングは、同じIS-ISプロセスと個別の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トランジットを顧客に提供します。 また、最初のフェーズでのみ、独自の顧客ネットワークがIPv6を提供していない場合は常に、顧客の顧客である重要なサイトおよび顧客（AS番号を持つもの）へのBGPピアリングを使用した構成済みトンネルサービスを提供します。 これは、それらをIPv6に導入し、有益な副作用を生み出すために行われます。通過トラフィックの総量が増加するにつれて、直接の顧客から少しの余分な収益が発生します。
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 (e.g., DHCPv6 authentication keying), and how to manage customer traceability if stateless address autoconfiguration is used.
oこの文書は、IPv6を採用する際に明示的に考慮すべき分析またはさらなる作業のための多くの要件を特定しています：共有メディアまたは共有ISP顧客接続メディアのアクセス制御の実行方法、そのような環境での構成管理セキュリティの管理方法（例： 、DHCPv6認証キーイング）、およびステートレスアドレス自動設定が使用される場合の顧客のトレーサビリティの管理方法。
This document has greatly benefited from input by Marc Blanchet, Jordi Palet, Francois Le Faucheur, Ronald van der Pol, and Cleve Mickles.
この文書は、Marc Blanchet、Jordi Palet、Francois Le Faucheur、Ronald van der Pol、およびCleve Micklesの意見から大きな恩恵を受けています。
Special thanks to Richard Graveman and Michael Lambert for proofreading the document.
ドキュメントの校正をしてくれたRichard GravemanとMichael Lambertに感謝します。
[EMBEDRP] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[EMBEDRP]サヴォラ、P。、およびB.ハーバーマン、「IPv6マルチキャストアドレスへのランデブーポイント（RP）アドレスの埋め込み」、RFC 3956、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 Shen、Nischal Sheth、「M-ISIS：IS-ISのマルチトポロジ（MT）ルーティング」、Work in Progress。
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC2858] Bates、T.、Rekhter、Y.、Chandra、R。、およびD. Katz、「BGP-4のマルチプロトコル拡張」、RFC 2858、2000年6月。
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
[RFC2545] Marques、P。およびF. Dupont、「IPv6ドメイン間ルーティングのためのBGP-4マルチプロトコル拡張の使用」、RFC 2545、1999年3月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704] Baker、F。およびP. Savola、「マルチホームネットワークのイングレスフィルタリング」、BCP 84、RFC 3704、2004年3月。
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003.
[RFC3582] Abley、J.、Black、B。、およびV. Gill、「IPv6サイトマルチホーミングアーキテクチャの目標」、RFC 3582、2003年8月。
[RFC3178] Hagino, J. and H. Snyder, "IPv6 Multihoming Support at Site Exit Routers", RFC 3178, October 2001.
[RFC3178] Hagino、J。、およびH. Snyder、「サイト出口ルーターでのIPv6マルチホーミングサポート」、RFC 3178、2001年10月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.、K。ムーア、「IPv4クラウドを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]リグニー、C。、ウィレンス、S。、ルーベンス、A。、およびW.シンプソン、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[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.、Ooms、D.、Prevost、S.、Le Faucheur、F。、「IPv4クラウド間でIPv6アイランドをBGPで接続する」、Work in Progress。
[DUAL-ACCESS] Shirasaki, Y., Miyakawa, S., Yamasaki, T., Takenouchi, A., "A Model of IPv6/IPv4 Dual Stack Internet Access Service", Work in Progress.
[DUAL-ACCESS]白崎Y、宮川kawa、山崎saki、竹ノ内、「IPv6 / IPv4デュアルスタックインターネットアクセスサービスのモデル」、進行中。
[STEP] Savola, P., "Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP)", Work in Progress.
[ステップ] Savola、P。、「単純なIPv6-in-IPv4トンネル確立手順（STEP）」、進行中の作業。
[TSP] Blanchet, M., "IPv6 Tunnel Broker with Tunnel Setup Protocol (TSP)", Work in Progress.
[TSP] Blanchet、M.、「トンネルセットアッププロトコル（TSP）を備えたIPv6トンネルブローカー」、Work in Progress。
[TUNREQS] Palet, J., Nielsen, K., Parent, F., Durand, A., Suryanarayanan, R., and P. Savola, "Goals for Tunneling Configuration", Work in Progress, February 2005.
[TUNREQS] Palet、J.、Nielsen、K.、Parent、F.、Durand、A.、Suryanaranyanan、R。、およびP. Savola、「トンネル構成の目標」、Work in Progress、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.、Satapati、S.、van der Pol、R。、「管理されていないネットワークの移行メカニズムの評価」、進行中の作業。
[PROTO41] Palet, J., Olvera, C., Fernandez, D., "Forwarding Protocol 41 in NAT Boxes", Work in Progress.
[PROTO41] Palet、J.、Olvera、C.、Fernandez、D。、「NATボックスでのプロトコル41の転送」、Work in Progress。
[V6SEC] Savola, P., "IPv6 Transition/Co-existence Security Considerations", Work in Progress.
[V6SEC] Savola、P。、「IPv6移行/共存セキュリティの考慮事項」、Work in Progress。
[DNSGUIDE] Durand, A., Ihren, J., "DNS IPv6 transport operational guidelines", Work in Progress.
[DNSGUIDE] Durand、A.、Ihren、J。、「DNS IPv6トランスポート運用ガイドライン」、Work in Progress。
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", Work in Progress.
[TEREDO] Huitema、C。、「Teredo：NATを介したUDPを介したIPv6のトンネリング」、Work in Progress。
Appendix A: Convexity Requirements in Single Topology IS-IS
付録A：単一トポロジIS-ISの凸面要件
The single-topology IS-IS convexity requirements could be summarized, from IPv4/6 perspective, as follows:
単一トポロジのIS-ISコンベクシティ要件は、次のように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.
IS-ISはCLNSに基づいているため、これらは些細なことではありません。 単一トポロジのIS-ISは、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
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パケットは、IPv6をサポートしないR3を通過し、パケットは破棄されます。 R1-R3、R3-R2とR1-R4、R4-R2の間のコストを逆にすることにより、トラフィックは通常の場合に機能しますが、リンクが失敗し、ルーティングがR3を通過するように変更されると、パケットは再び破棄され始めます 。
Authors' Addresses
著者のアドレス
Mikael Lind TeliaSonera Vitsandsgatan 9B SE-12386 Farsta, Sweden
ミカエル・リンド・テリアソネラ・ヴィタンサンドガタン9B SE-12386ファルスタ、スウェーデン
EMail: mikael.lind@teliasonera.com
メール：mikael.lind@teliasonera.com
Vladimir Ksinant Thales Communications 160, boulevard de Valmy 92704 Colombes, France
Vladimir Ksinant Thales Communications 160、boulevard de Valmy 92704 Colombes、France
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 Daniel Parkモバイルプラットフォーム研究所、SAMSUNG Electronics。 京畿道水原市八達区前丹3洞416
EMail: soohong.park@samsung.com
メール：soohong.park@samsung.com
Alain Baudot France Telecom R&D Division 42, rue des coutures 14066 Caen - FRANCE
Alain Baudot France Telecom R＆D Division 42、rue des coutures 14066カーン-フランス
EMail: alain.baudot@francetelecom.com
メール：alain.baudot@francetelecom.com
Pekka Savola CSC/FUNET Espoo, Finland
Pekka Savola CSC / FUNET Espoo、フィンランド
EMail: psavola@funet.fi
メール：psavola@funet.fi
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（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.
この文書は、BCP 78に含まれる権利、ライセンス、制限の対象となります。また、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
本書および本書に含まれる情報は「現状のまま」提供され、寄稿者、代表者または代表者（もしあれば）、インターネット協会、インターネットエンジニアリングタスクフォースはすべての保証を放棄します 黙示的であるが、ここに記載されている情報の使用が商品性または特定の目的への適合性の黙示的保証を侵害しないという保証に限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書に記載されている技術の実装または使用に関連すると主張される可能性のある知的財産権またはその他の権利の有効性または範囲、またはそのような権利の下でのライセンスの有無に関して、立場をとりません。 利用可能 また、そのような権利を特定するための独立した努力を行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（http://www.ietf.org/ipr）から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この標準を実装するために必要な技術を対象とする著作権、特許、特許出願、またはその他の所有権に関心を寄せるよう、あらゆる利害関係者を招待します。 IETFのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。