[要約] RFC 4029は、ISPネットワークへのIPv6導入のシナリオと分析に関するドキュメントです。その目的は、ISPがIPv6を効果的に導入するためのガイダンスを提供することです。
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
IPv6をISPネットワークに導入するためのシナリオと分析
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）The Internet Society（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
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の間または異なる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に沿ってISPに沿ってIPv6を顧客に提供するために必要な機能を実装するという点で、段階がどれだけ到達したかの尺度です。
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からの少なくともA /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
o ステージ1発売oステージ2aバックボーンoステージ2bカスタマー接続oステージ3完了
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は、現在のIPv4ネットワークをステージ2Bを介して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（例えば、アフリニック、apnic、arin、lacnic、熟した）からプレフィックス割り当て（通常はa /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から一時的な接続を取得することが可能かもしれません。ただし、長期的な目標は、IPv6接続の品質が低下する可能性が高いため、輸送ISPから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）で確立できます。ほとんどのIXSは、IPv6が使いやすい技術を使用しており、多くのIXSはすでに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 Customer Connection Networksを介して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バックボーンネットワークとIPv4とIPv6の両方をサポートする顧客接続ネットワークを備えたISPで構成されています。顧客へのサービスはネイティブ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によってNATTED）またはパブリック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がある段階から別の段階に移行できる必要があることは明らかです。このドキュメントの初期段階は、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.
- 顧客管理（半径など）のメカニズムを拡張して、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 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-over-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接続に使用されるIPv6 LSPのネイティブルーティングとセットアップをサポートする必要があります。
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-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）は、明らかに最良のターゲットアプローチです。ただし、アプローチ1）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が広く展開されている場合は、より大きなネットワークでスケーラビリティを欠く可能性があることを除いて、アプローチとほぼ同等です。
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は優れたIGPSであるため、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の選択を行う必要があります。OSPFV3またはIS-ISのいずれかのIPv6のいずれかです。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
- 個別のプロセスを使用：IPv4のOSOSPFV2、IPv6のIS-IS（IPv4のOSPFv2、IPv6のOSOSPFv3、またはIIS-IS IS IS IS IS IS IS IS IS IS IS IS IS
- 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-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およびCORE）に展開され、顧客のプレフィックスと外部ルートに関するルーティング情報を配布します。
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のいずれかに加えて、少なくとも限られた方法で、そしていくつかのメカニズムによって、ルーティングプロトコル間でルーティング情報を再配布する必要がある場合があります。
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.
マルチプロトコル拡張[RFC2858]を備えたBGPは、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.
単一の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 Transportおよび同様に、いくつかの理由で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接続が減少している場合（またはその逆）に機能する場合があります。
* 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の大規模なセットに接続された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.
IPv4ネットワークを介してIPv6の顧客をIPv6バックボーンに接続することは、IPv4サービスをIPv4顧客に提供するためにISPが取った最初の慎重なステップと見なすことができます。一部の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).
いずれにせよ、Tunneling技術を使用して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の割り当てられたプレフィックス（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つのトンネルエンドポイント間の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が転送プロトコル-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リレーとテレドサーバー（または同様）を展開して、顧客の接続性を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の割り当てられたプレフィックス（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 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セッションを開始する）を展開するか、トンネル構成サービスを展開することです。トンネル構成の主要な候補は、ステップ[ステップ]と小さじであり、どちらも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固有のユーザー認証が必ずしも必要ではありません。たとえば、IPv6サービスに自動的にアクセスできるIPv4サービスの顧客です。この場合、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)
- 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と一緒に利用可能である限り、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から複数の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に複数回接続することは簡単なプラクティスです。これは、たとえば、パブリックまたはプライベートの数字と顧客に割り当てられたプレフィックスを使用して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サーバー[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は、特定の環境で有用なメカニズムとして認められました。ただし、代替方法を使用して同じ目的を達成することは可能であるため、これを指定することは厳密には必要ありません。
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を実行しています。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機器は、レイヤー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.
Access 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および埋め込み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の変更を必要としません：IPv6接続は、PEルーターを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への接続とExchange Pointは、BGPを交換ルートに実行します。マルチキャストとQOは展開されません。
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.
Access 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 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-Tunnelingに加えて、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.
Transit Providerは、他のプロバイダーにIP接続を提供しますが、エンドユーザーや企業には接続しません。IS-ISおよびIBGPは内部で使用され、BGPは外部で使用されます。Connect 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トランジットを顧客に無料で提供します。また、最初のフェーズのみで、BGPが重要なサイトと顧客（AS番号がある人）がIPv6を提供していないときはいつでも顧客の顧客である顧客を覗き込む構成されたトンネルサービスを提供します。これは、それらを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認証キーイング）、およびStateless Address Autoconfigurationが使用されている場合の顧客トレーサビリティを管理する方法。
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.
ドキュメントを校正してくれたリチャードグレイグマンとマイケルランバートに感謝します。
[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. Haberman、「IPv6マルチキャストアドレスにRendezvous Point（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：Multi Topology（MT）ルーティングIS-IS」、進行中の作業。
[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。and 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] Eabley、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] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介した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] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（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雲をBGPでIPv6島を接続する」、進行中の作業。
[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.、Yamasaki、T.、Tauchouchi、A。、「IPv6/IPv4デュアルスタックインターネットアクセスサービスのモデル」、進行中の作業。
[STEP] Savola, P., "Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP)", Work in Progress.
[Step] Savola、P。、「Simple IPv6-in-IPV4トンネル設立手順（STEP）」、進行中の作業。
[TSP] Blanchet, M., "IPv6 Tunnel Broker with Tunnel Setup Protocol (TSP)", Work in Progress.
[TSP] Blanchet、M。、「Tunnel Setup Protocol（TSP）を備えたIPv6トンネルブローカー」、進行中の作業。
[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.、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.、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 Boxesの転送プロトコル41」、進行中の作業。
[V6SEC] Savola, P., "IPv6 Transition/Co-existence Security Considerations", Work in Progress.
[V6Sec] Savola、P。、「IPv6遷移/共存セキュリティに関する考慮事項」、進行中の作業。
[DNSGUIDE] Durand, A., Ihren, J., "DNS IPv6 transport operational guidelines", Work in Progress.
[Dnsguide] Durand、A.、Ihren、J。、「DNS IPv6輸送運用ガイドライン」、進行中の作業。
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", Work in Progress.
[Teredo] Huitema、C。、「Teredo：UDPを介してIPv6をトンネル化する」、進行中の作業。
Appendix A: Convexity Requirements in Single Topology IS-IS
付録A：単一トポロジの凸の要件はISです
The single-topology IS-IS convexity requirements could be summarized, from IPv4/6 perspective, as follows:
次のように、IPv4/6の観点から、単一トポロジーIS-IS凸性要件を要約することができます。
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はCLNに基づいているため、これらは簡単に達成されていません。シングルトポロジー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パケットはR3を通過しますが、これはIPv6をサポートせず、パケットは破棄されます。R1-R3、R3-R2、R1-R4、R4-R2間のコストを逆転させることにより、通常のケースでトラフィックが機能しますが、リンクが失敗し、ルーティングがR3を通過すると、パケットが再び破棄され始めます。
Authors' Addresses
著者のアドレス
Mikael Lind TeliaSonera Vitsandsgatan 9B SE-12386 Farsta, Sweden
Mikael Lind Teliasonera Vitsandsgatan 9b SE-12386 Farsta、Sweden
EMail: 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
Soohong Daniel Park Mobile Platform Laboratory, SAMSUNG Electronics. 416, Maetan-3dong, Paldal-Gu, Suwon, Gyeonggi-do, Korea
Soohong Daniel Park Mobile Platform Laboratory、Samsung Electronics。416、Maetan-3dong、Paldal-gu、Suwon、Gyeonggi-do、韓国
EMail: 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 Caen-フランス
EMail: alain.baudot@francetelecom.com
Pekka Savola CSC/FUNET Espoo, Finland
Pekka Savola CSC/Funet Espoo、フィンランド
EMail: psavola@funet.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。