[要約] RFC 4779は、ブロードバンドアクセスネットワークでのISP IPv6展開シナリオに関するガイドラインです。このRFCの目的は、ISPがIPv6を効果的に展開するための異なるシナリオとその利点を提供することです。
Network Working Group S. Asadullah
Request for Comments: 4779 A. Ahmed
Category: Informational C. Popoviciu
Cisco Systems
P. Savola
CSC/FUNET
J. Palet
Consulintel
January 2007
ISP IPv6 Deployment Scenarios in Broadband Access Networks
ブロードバンドアクセスネットワークのISP IPv6展開シナリオ
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document provides a detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP) Broadband (BB) networks in coexistence with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies that are currently deployed, and discussed in this document. The emerging Broadband Power Line Communications (PLC/BPL) access technology is also discussed for completeness. In this document we will discuss main components of IPv6 BB networks, their differences from IPv4 BB networks, and how IPv6 is deployed and integrated in each of these networks using tunneling mechanisms and native IPv6.
このドキュメントは、展開されたIPv4サービスと共存して、今日のサービスプロバイダー（SP）ブロードバンド（BB）ネットワークにおけるIPv6の展開および統合方法とシナリオの詳細な説明を提供します。ケーブル/HFC、BBイーサネット、XDSL、およびWLANは、現在展開されており、このドキュメントで説明されている主要なBBテクノロジーです。新しいブロードバンド電力線通信（PLC/BPL）アクセステクノロジーについても、完全性について説明します。このドキュメントでは、IPv6 BBネットワークの主要コンポーネント、IPv4 BBネットワークとの違い、およびTunnelingメカニズムとネイティブIPv6を使用してこれらの各ネットワークにIPv6が展開および統合される方法について説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Common Terminology . . . . . . . . . . . . . . . . . . . . . . 5
3. Core/Backbone Network . . . . . . . . . . . . . . . . . . . . 5
3.1. Layer 2 Access Provider Network . . . . . . . . . . . . . 5
3.2. Layer 3 Access Provider Network . . . . . . . . . . . . . 6
4. Tunneling Overview . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Access over Tunnels - Customers with Public IPv4
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Access over Tunnels - Customers with Private IPv4
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Transition a Portion of the IPv4 Infrastructure . . . . . 8
5. Broadband Cable Networks . . . . . . . . . . . . . . . . . . . 9
5.1. Broadband Cable Network Elements . . . . . . . . . . . . . 9
5.2. Deploying IPv6 in Cable Networks . . . . . . . . . . . . . 10
5.2.1. Deploying IPv6 in a Bridged CMTS Network . . . . . . . 12
5.2.2. Deploying IPv6 in a Routed CMTS Network . . . . . . . 14
5.2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . 23
5.2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.5. IPv6 Security Considerations . . . . . . . . . . . . . 24
5.2.6. IPv6 Network Management . . . . . . . . . . . . . . . 25
6. Broadband DSL Networks . . . . . . . . . . . . . . . . . . . . 26
6.1. DSL Network Elements . . . . . . . . . . . . . . . . . . . 26
6.2. Deploying IPv6 in IPv4 DSL Networks . . . . . . . . . . . 28
6.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 29
6.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 30
6.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 33
6.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 36
6.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 38
6.3.1. ASM-Based Deployments . . . . . . . . . . . . . . . . 39
6.3.2. SSM-Based Deployments . . . . . . . . . . . . . . . . 39
6.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 41
6.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 42
7. Broadband Ethernet Networks . . . . . . . . . . . . . . . . . 42
7.1. Ethernet Access Network Elements . . . . . . . . . . . . . 42
7.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks . . . . 43
7.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 44
7.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 46
7.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 48
7.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 50
7.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 52
7.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 54
7.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 55
8. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.1. WLAN Deployment Scenarios . . . . . . . . . . . . . . . . 55
8.1.1. Layer 2 NAP with Layer 3 termination at NSP Edge
Router . . . . . . . . . . . . . . . . . . . . . . . . 56
8.1.2. Layer 3 Aware NAP with Layer 3 Termination at
Access Router . . . . . . . . . . . . . . . . . . . . 59
8.1.3. PPP-Based Model . . . . . . . . . . . . . . . . . . . 61
8.2. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 63
8.3. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.4. IPv6 Security Considerations . . . . . . . . . . . . . . . 65
8.5. IPv6 Network Management . . . . . . . . . . . . . . . . . 67
9. Broadband Power Line Communications (PLC) . . . . . . . . . . 67
9.1. PLC/BPL Access Network Elements . . . . . . . . . . . . . 68
9.2. Deploying IPv6 in IPv4 PLC/BPL . . . . . . . . . . . . . . 69
9.2.1. IPv6 Related Infrastructure Changes . . . . . . . . . 69
9.2.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 69
9.2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 70
9.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 71
9.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 71
9.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 71
10. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 71
11. Security Considerations . . . . . . . . . . . . . . . . . . . 74
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 74
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74
13.1. Normative References . . . . . . . . . . . . . . . . . . . 74
13.2. Informative References . . . . . . . . . . . . . . . . . . 76
This document presents the options available in deploying IPv6 services in the access portion of a BB Service Provider (SP) network - namely Cable/HFC, BB Ethernet, xDSL, WLAN, and PLC/BPL.
このドキュメントでは、BBサービスプロバイダー（SP）ネットワークのアクセス部分にIPv6サービスを展開する際に利用可能なオプションを提示します。
This document briefly discusses the other elements of a provider network as well. It provides different viable IPv6 deployment and integration techniques, and models for each of the above-mentioned BB technologies individually. The example list is not exhaustive, but it tries to be representative.
このドキュメントでは、プロバイダーネットワークの他の要素についても簡単に説明します。異なる実行可能なIPv6の展開と統合技術、および上記の各BBテクノロジーのモデルを個別に提供します。サンプルリストは網羅的ではありませんが、代表者になろうとします。
This document analyzes how all the important components of current IPv4-based Cable/HFC, BB Ethernet, xDSL, WLAN, and PLC/BPL networks will behave when IPv6 is integrated and deployed.
このドキュメントでは、IPv4ベースの現在のIPv4ベースのケーブル/HFC、XDSL、WLAN、およびPLC/BPLネットワークのすべての重要なコンポーネントが、IPv6が統合および展開されたときにどのように動作するかを分析します。
The following important pieces are discussed:
次の重要な作品について説明します。
A. Available tunneling options
A.利用可能なトンネルオプション
B. Devices that would have to be upgraded to support IPv6
B. IPv6をサポートするためにアップグレードする必要があるデバイス
C. Available IPv6 address assignment techniques and their use
C.利用可能なIPv6アドレス割り当て手法とその使用
D. Possible IPv6 Routing options and their use
D.可能なIPv6ルーティングオプションとその使用
E. IPv6 unicast and multicast packet transmission
E. IPv6ユニキャストおよびマルチキャストパケット送信
F. Required IPv6 Quality of Service (QoS) parameters
F.必要なIPv6サービス品質（QOS）パラメーター
G. Required IPv6 Security parameters
G.必要なIPv6セキュリティパラメーター
H. Required IPv6 Network Management parameters
H.必要なIPv6ネットワーク管理パラメーター
It is important to note that the addressing rules provided throughout this document represent an example that follows the current assignment policies and recommendations of the registries. However, they can be adapted to the network and business model needs of the ISPs.
このドキュメント全体で提供されるアドレス指定規則は、現在の課題ポリシーとレジストリの推奨事項に従う例を表していることに注意することが重要です。ただし、ISPのネットワークおよびビジネスモデルのニーズに適合させることができます。
The scope of the document is to advise on the ways of upgrading an existing infrastructure to support IPv6 services. The recommendation to upgrade a device to dual stack does not stop an SP from adding a new device to its network to perform the necessary IPv6 functions discussed. The costs involved with such an approach could be offset by lower impact on the existing IPv4 services.
ドキュメントの範囲は、IPv6サービスをサポートするために既存のインフラストラクチャをアップグレードする方法についてアドバイスすることです。デバイスをデュアルスタックにアップグレードするという推奨事項は、SPがネットワークに新しいデバイスを追加して、議論されている必要なIPv6関数を実行するのを止めません。このようなアプローチに伴うコストは、既存のIPv4サービスへの影響の低下により相殺される可能性があります。
BB: Broadband
BB：ブロードバンド
CPE: Customer Premise Equipment
CPE：顧客の前提装備
GWR: Gateway Router
GWR：ゲートウェイルーター
ISP: Internet Service Provider
ISP：インターネットサービスプロバイダー
NAP: Network Access Provider
NAP：ネットワークアクセスプロバイダー
NSP: Network Service Provider
NSP：ネットワークサービスプロバイダー
QoS: Quality of Service
QOS：サービス品質
SP: Service Provider
SP：サービスプロバイダー
This section intends to briefly discuss some important elements of a provider network tied to the deployment of IPv6. A more detailed description of the core network is provided in other documents [RFC4029].
このセクションでは、IPv6の展開に関連するプロバイダーネットワークのいくつかの重要な要素について簡単に説明する予定です。コアネットワークのより詳細な説明は、他のドキュメント[RFC4029]に記載されています。
There are two types of networks identified in the Broadband deployments:
ブロードバンドの展開には、ネットワークには2つのタイプがあります。
A. Access Provider Network: This network provides the broadband access and aggregates the subscribers. The subscriber traffic is handed over to the Service Provider at Layer 2 or 3.
A.アクセスプロバイダーネットワーク：このネットワークは、ブロードバンドアクセスを提供し、サブスクライバーを集約します。加入者トラフィックは、レイヤー2または3のサービスプロバイダーに引き渡されます。
B. Service Provider Network: This network provides Intranet and Internet IP connectivity for the subscribers.
B.サービスプロバイダーネットワーク：このネットワークは、サブスクライバーにイントラネットおよびインターネットIP接続を提供します。
The Service Provider network structure beyond the Edge Routers that interface with the Access provider is beyond the scope of this document.
アクセスプロバイダーとインターフェイスするエッジルーターを超えたサービスプロバイダーネットワーク構造は、このドキュメントの範囲を超えています。
The Access Provider can deploy a Layer 2 network and perform no routing of the subscriber traffic to the SP. The devices that support each specific access technology are aggregated into a highly redundant, resilient, and scalable Layer 2 core. The network core can involve various technologies such as Ethernet, Asynchronous Transfer Mode (ATM), etc. The Service Provider Edge Router connects to the Access Provider core.
アクセスプロバイダーは、レイヤー2ネットワークを展開し、サブスクライバートラフィックのルーティングをSPに実行できません。各特定のアクセステクノロジーをサポートするデバイスは、非常に冗長で回復力があり、スケーラブルなレイヤー2コアに集約されます。ネットワークコアには、イーサネット、非同期転送モード（ATM）などのさまざまなテクノロジーが含まれます。サービスプロバイダーのエッジルーターは、アクセスプロバイダーコアに接続します。
This type of network may be transparent to the Layer 3 protocol. Some possible changes may come with the intent of supporting IPv6 provisioning mechanisms, as well as filtering and monitoring IPv6 traffic based on Layer 2 information such as IPv6 Ether Type Protocol ID (0x86DD) or IPv6 multicast specific Media Access Control (MAC) addresses (33:33:xx:xx:xx:xx).
このタイプのネットワークは、レイヤー3プロトコルに対して透過的である可能性があります。IPv6プロビジョニングメカニズムをサポートする意図、およびIPv6エーテル型プロトコルID（0x86DD）またはIPv6マルチキャスト固有のメディアアクセスコントロール（MAC）アドレス（33などのレイヤー2情報に基づいてIPv6トラフィックをフィルタリングおよび監視する意図がある場合、いくつかの可能性のある変更が伴う場合があります。：33：xx：xx：xx：xx）。
The Access Provider can choose to terminate the Layer 2 domain and route the IP traffic to the Service Provider network. Access Routers are used to aggregate the subscriber traffic and route it over a Layer 3 core to the SP Edge Routers. In this case, the impact of the IPv6 deployment is significant.
アクセスプロバイダーは、レイヤー2ドメインを終了し、IPトラフィックをサービスプロバイダーネットワークにルーティングすることを選択できます。アクセスルーターは、サブスクライバートラフィックを集約し、レイヤー3コアにSPエッジルーターにルーティングするために使用されます。この場合、IPv6展開の影響は重要です。
The case studies in this document discuss only the relevant network elements of such a network: Customer Premise Equipment, Access Router, and Edge Router. In real networks, the link between the Access Router and the Edge Router involves other routers that are part of the aggregation and the core layer of the Access Provider network.
このドキュメントのケーススタディでは、このようなネットワークの関連するネットワーク要素のみについて説明します：顧客前提装備、アクセスルーター、およびエッジルーター。実際のネットワークでは、アクセスルーターとエッジルーターの間のリンクには、集約の一部である他のルーターとアクセスプロバイダーネットワークのコア層が含まれます。
The Access Provider can forward the IPv6 traffic through its Layer 3 core in three possible ways:
アクセスプロバイダーは、3つの可能な方法でレイヤー3コアを介してIPv6トラフィックを転送できます。
A. IPv6 Tunneling: As a temporary solution, the Access Provider can choose to use a tunneling mechanism to forward the subscriber IPv6 traffic to the Service Provider Edge Router. This approach has the least impact on the Access Provider network; however, as the number of users increase and the amount of IPv6 traffic grows, the ISP will have to evolve to one of the scenarios listed below.
A. IPv6トンネル：一時的なソリューションとして、アクセスプロバイダーはトンネリングメカニズムを使用して、サブスクライバーIPv6トラフィックをサービスプロバイダーEdgeルーターに転送することを選択できます。このアプローチは、アクセスプロバイダーネットワークに最も影響を与えません。ただし、ユーザーの数が増加し、IPv6トラフィックの量が増加するにつれて、ISPは以下にリストされているシナリオの1つに進化する必要があります。
B. Native IPv6 Deployment: The Access Provider routers are upgraded to support IPv6 and can become dual stack. In a dual-stack network, an IPv6 Interior Gateway Protocol (IGP), such as OSPFv3 [RFC2740] or IS-IS [ISISv6], is enabled. RFC 4029 [RFC4029] discusses the IGP selection options with their benefits and drawbacks.
B.ネイティブIPv6の展開：アクセスプロバイダールーターはアップグレードされてIPv6をサポートし、デュアルスタックになる可能性があります。デュアルスタックネットワークでは、OSPFV3 [RFC2740]やIS-IS [ISISV6]などのIPv6インテリアゲートウェイプロトコル（IGP）が有効になります。RFC 4029 [RFC4029]は、IGPの選択オプションについて、利点と欠点について説明します。
C. MPLS 6PE Deployment [6PE]: If the Access Provider is running MPLS in its IPv4 core, it could use 6PE to forward IPv6 traffic over it. In this case, only a subset of routers close to the edge of the network need to be IPv6 aware. With this approach, BGP becomes important in order to support 6PE.
C. MPLS 6PE展開[6PE]：アクセスプロバイダーがIPv4コアでMPLSを実行している場合、6PEを使用してIPv6トラフィックを転送できます。この場合、ネットワークの端に近いルーターのサブセットのみがIPv6を認識する必要があります。このアプローチにより、6PEをサポートするためにBGPが重要になります。
The 6PE approach has the advantage of having minimal impact on the Access Provider network. Fewer devices need to be upgraded and configured while the MPLS core continues to switch the traffic, unaware that it transports both IPv4 and IPv6. 6PE should be leveraged only if MPLS is already deployed in the network. At the time of writing this document, a major disadvantage of the 6PE solution is that it does not support multicast IPv6 traffic.
6PEアプローチには、アクセスプロバイダーネットワークに最小限の影響を与えるという利点があります。MPLSコアがトラフィックの切り替えを続けている間に、アップグレードおよび構成する必要があるデバイスは少なくなり、IPv4とIPv6の両方を輸送することに気付いていません。6PEは、MPLSがネットワークに既に展開されている場合にのみレバレッジする必要があります。このドキュメントを書いている時点で、6PEソリューションの大きな欠点は、マルチキャストIPv6トラフィックをサポートしていないことです。
The native approach has the advantage of supporting IPv6 multicast traffic, but it may imply a significant impact on the IPv4 operational network in terms of software configuration and possibly hardware upgrade.
ネイティブアプローチには、IPv6マルチキャストトラフィックをサポートするという利点がありますが、ソフトウェアの構成とハードウェアのアップグレードの観点から、IPv4の運用ネットワークに大きな影響を与える可能性があります。
More detailed Core Network deployment recommendations are discussed in other documents [RFC4029]. The handling of IPv6 traffic in the Core of the Access Provider Network will not be discussed for the remainder of this document.
より詳細なコアネットワーク展開の推奨事項は、他のドキュメント[RFC4029]で説明されています。Access ProviderネットワークのコアでのIPv6トラフィックの取り扱いは、このドキュメントの残りの部分については議論されません。
If SPs are not able to deploy native IPv6, they might use tunneling-based transition mechanisms to start an IPv6 service offering, and move to native IPv6 deployment at a later time.
SPSがネイティブIPv6を展開できない場合、Tunnelingベースの遷移メカニズムを使用してIPv6サービスの提供を開始し、後でネイティブIPv6展開に移動する可能性があります。
Several tunneling mechanisms were developed specifically to transport IPv6 over existing IPv4 infrastructures. Several of them have been standardized and their use depends on the existing SP IPv4 network and the structure of the IPv6 service. The requirements for the most appropriate mechanisms are described in [v6tc] with more updates to follow. Deploying IPv6 using tunneling techniques can imply as little changes to the network as upgrading software on tunnel end points. A Service Provider could use tunneling to deploy IPv6 in the following scenarios:
いくつかのトンネルメカニズムが、既存のIPv4インフラストラクチャを介してIPv6を輸送するために特別に開発されました。それらのいくつかは標準化されており、それらの使用は既存のSP IPv4ネットワークとIPv6サービスの構造に依存しています。最も適切なメカニズムの要件は[V6TC]で説明されており、より多くの更新が続きます。トンネリング技術を使用してIPv6を展開すると、トンネルエンドポイントのアップグレードソフトウェアがネットワークの変更がほとんどないことを意味します。サービスプロバイダーは、トンネリングを使用して、次のシナリオにIPv6を展開できます。
If the customer is a residential user, it can initiate the tunnel directly from the IPv6 capable host to a tunnel termination router located in the NAP or ISP network. The tunnel type used should be decided by the SP, but it should take into consideration its availability on commonly used software running on the host machine. Of the many tunneling mechanisms developed, such as IPv6 Tunnel Broker [RFC3053], Connection of IPv6 Domains via IPv4 Clouds [RFC3056], Generic Packet Tunneling in IPv6 [RFC2473], ISATAP [RFC4214], Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213], and Transmission of IPv6 over IPv4 Domains without Explicit Tunnels [RFC2529], some are more popular than the others. At the time of writing this document, the IETF Softwire Working Group was tasked with standardizing a single tunneling protocol [Softwire] for this application.
顧客が住宅ユーザーである場合、IPv6対応ホストからNAPまたはISPネットワークにあるトンネル終端ルーターに直接トンネルを開始できます。使用するトンネルタイプはSPによって決定される必要がありますが、ホストマシンで実行されている一般的に使用されるソフトウェアでの可用性を考慮する必要があります。IPv6トンネルブローカー[RFC3053]、IPv4クラウド[RFC3056]を介したIPv6ドメインの接続、IPv6 [RFC2473]、ISATAP [RFC4214]、IPV6宿主およびRuterの基本的な移行メカニズムなど、開発された多くのトンネルメカニズムのうち、開発された多くのトンネルメカニズムのうち、[RFC4213]、および明示的なトンネルのないIPv4ドメインを介したIPv6の伝達[RFC2529]は、他のものよりも人気があります。このドキュメントの作成時点で、IETF Softwireワーキンググループは、このアプリケーションの単一のトンネルプロトコル[SoftWire]を標準化する任務を負っていました。
If the end customer has a GWR installed, then it could be used to originate the tunnel, thus offering native IPv6 access to multiple hosts on the customer network. In this case, the GWR would need to be upgraded to dual stack in order to support IPv6. The GWR can be owned by the customer or by the SP.
End CustomerにGWRがインストールされている場合、トンネルを発信するために使用できるため、顧客ネットワーク上の複数のホストにネイティブのIPv6アクセスを提供します。この場合、IPv6をサポートするためにGWRをデュアルスタックにアップグレードする必要があります。GWRは、顧客またはSPが所有できます。
If the end customer receives a private IPv4 address and needs to initiate a tunnel through Network Address Translation (NAT), techniques like 6to4 may not work since they rely on public IPv4 address. In this case, unless the existing GWRs support protocol-41- forwarding [Protocol41], the end user might have to use tunnels that can operate through NATs (such as Teredo [RFC4380]). Most GWRs support protocol-41-forwarding, which means that hosts can initiate the tunnels - in which case the GWR is not affected by the IPv6 service.
エンド顧客がプライベートIPv4アドレスを受け取り、ネットワークアドレス変換（NAT）を介してトンネルを開始する必要がある場合、6to4などの手法はパブリックIPv4アドレスに依存しているため機能しない場合があります。この場合、既存のGWRSがプロトコル-41-転送[Protocol41]をサポートしない限り、エンドユーザーはNAT（Teredo [RFC4380]など）を介して動作できるトンネルを使用する必要があります。ほとんどのGWRSはプロトコル-41-Forwardingをサポートしています。これは、ホストがトンネルを開始できることを意味します。その場合、GWRはIPv6サービスの影響を受けません。
The customer has the option to initiate the tunnel from the device (GWR) that performs the NAT functionality, similar to the GWR scenario discussed in Section 4.1. This will imply hardware replacement or software upgrade and a native IPv6 environment behind the GWR.
顧客には、セクション4.1で説明したGWRシナリオと同様に、NAT機能を実行するデバイス（GWR）からトンネルを開始するオプションがあります。これは、ハードウェアの交換またはソフトウェアのアップグレードと、GWRの背後にあるネイティブIPv6環境を意味します。
It is also worth observing that initiating an IPv6 tunnel over IPv4 through already established IPv4 IPsec sessions would provide a certain level of security to the IPv6 traffic.
また、すでに確立されているIPv4 IPSECセッションを介してIPv4を介してIPv6トンネルを開始すると、IPv6トラフィックに一定レベルのセキュリティが提供されることを観察する価値があります。
Tunnels can be used to transport the IPv6 traffic across a defined segment of the network. As an example, the customer might connect natively to the Network Access Provider, where a tunnel is used to transit the traffic over IPv4 to the ISP. In this case, the tunnel choice depends on its capabilities (for example, whether or not it supports multicast), routing protocols used (there are several types that can transport Layer 2 messages, such as GRE [RFC2784], L2TPv3 [RFC3931], or pseudowire), manageability, and scalability (dynamic versus static tunnels).
トンネルを使用して、ネットワークの定義されたセグメント全体でIPv6トラフィックを輸送できます。例として、顧客はネットワークアクセスプロバイダーにネイティブに接続する場合があります。ネットワークアクセスプロバイダーでは、トンネルを使用してIPv4を介してトラフィックをISPに通過させます。この場合、トンネルの選択は、その機能（たとえば、マルチキャストをサポートするかどうかにかかわらず）、使用されたルーティングプロトコル（GRE [RFC2784]、L2TPV3 [RFC3931]などのレイヤー2メッセージを輸送できるいくつかのタイプがあります。または擬似ワイヤ）、管理可能性、およびスケーラビリティ（動的トンネルと静的トンネル）。
This scenario implies that the access portion of the network has been upgraded to support dual stack, so the savings provided by tunneling in this scenario are very small compared with the previous two scenarios. Depending on the number of sites requiring the service, and considering the expenses required to manage the tunnels (some tunnels are static while others are dynamic [DynamicTunnel]) in this case, the SPs might find the native approach worth the additional investments.
このシナリオは、ネットワークのアクセス部分がデュアルスタックをサポートするようにアップグレードされていることを意味します。そのため、このシナリオでトンネリングが提供する節約は、以前の2つのシナリオと比較して非常に少ないことを意味します。サービスを必要とするサイトの数に応じて、トンネルの管理に必要な費用（一部のトンネルは静的であり、他のトンネルは動的である[dynamictunnel]）を考慮して、SPSは追加の投資に値するネイティブアプローチを見つける可能性があります。
In all the scenarios listed above, the tunnel selection process should consider the IPv6 multicast forwarding capabilities if such service is planned. As an example, 6to4 tunnels do not support IPv6 multicast traffic.
上記のすべてのシナリオで、トンネル選択プロセスでは、そのようなサービスが計画されている場合は、IPv6マルチキャスト転送機能を考慮する必要があります。例として、6to4トンネルはIPv6マルチキャストトラフィックをサポートしていません。
The operation, capabilities, and deployment of various tunnel types have been discussed extensively in the documents referenced earlier as well as in [RFC4213] and [RFC3904]. Details of a tunnel-based deployment are offered in the next section of this document, which discusses the case of Cable Access, where the current Data Over Cable Service Interface Specification (DOCSIS 2.0) [RF-Interface] and prior specifications do not provide support for native IPv6 access. Although Sections 6, 7, 8, and 9 focus on a native IPv6 deployments over DSL, Fiber to the Home (FTTH), wireless, and PLC/BPL and because this approach is fully supported today, tunnel-based solutions are also possible in these cases based on the guidelines of this section and some of the recommendations provided in Section 5.
さまざまなトンネルタイプの操作、能力、および展開については、[RFC4213]および[RFC3904]と同様に、前述の文書で広く議論されています。トンネルベースの展開の詳細は、このドキュメントの次のセクションで提供されています。このドキュメントでは、ケーブルアクセスのケースについて説明します。ケーブルサービスインターフェイス仕様（DOCSIS 2.0）[RF-Interface]および以前の仕様はサポートを提供していません。ネイティブIPv6アクセス用。セクション6、7、8、および9は、DSL、家庭用ファイバー（FTTH）、ワイヤレス、PLC/BPLを介したネイティブIPv6の展開に焦点を当てていますが、このアプローチは今日完全にサポートされているため、トンネルベースのソリューションも可能です。これらのケースは、このセクションのガイドラインとセクション5で提供されている推奨事項の一部に基づいています。
This section describes the infrastructure that exists today in cable networks providing BB services to the home. It also describes IPv6 deployment options in these cable networks.
このセクションでは、ケーブルネットワークに現在存在するインフラストラクチャについて説明します。また、これらのケーブルネットワークのIPv6展開オプションについても説明しています。
DOCSIS standardizes and documents the operation of data over cable networks. DOCSIS 2.0 and prior specifications have limitations that do not allow for a smooth implementation of native IPv6 transport. Some of these limitations are discussed in this section. For this reason, the IPv6 deployment scenarios discussed in this section for the existing cable networks are tunnel based. The tunneling examples presented here could also be applied to the other BB technologies described in Sections 6, 7, 8, and 9.
DOCSISは、ケーブルネットワークを介したデータの操作を標準化および文書化します。DOCSIS 2.0および以前の仕様には、ネイティブIPv6輸送のスムーズな実装を許可しない制限があります。これらの制限のいくつかについては、このセクションで説明します。このため、既存のケーブルネットワークについてこのセクションで説明したIPv6展開シナリオはトンネルベースです。ここに示されているトンネルの例は、セクション6、7、8、および9で説明されている他のBBテクノロジーにも適用できます。
Broadband cable networks are capable of transporting IP traffic to/ from users to provide high speed Internet access and Voice over IP (VoIP) services. The mechanism for transporting IP traffic over cable networks is outlined in the DOCSIS specification [RF-Interface].
ブロードバンドケーブルネットワークは、高速インターネットアクセスとVoice over IP（VOIP）サービスを提供するために、ユーザーとの間でIPトラフィックを輸送することができます。ケーブルネットワーク上でIPトラフィックを輸送するメカニズムは、DOCSIS仕様[RF-Interface]で概説されています。
Here are some of the key elements of a cable network:
ケーブルネットワークの重要な要素の一部は次のとおりです。
Cable (HFC) Plant: Hybrid Fiber Coaxial plant, used as the underlying transport
ケーブル（HFC）プラント：基礎となる輸送として使用されるハイブリッド繊維同軸プラント
CMTS: Cable Modem Termination System (can be a Layer 2 bridging or Layer 3 routing CMTS) GWR: Residential Gateway Router (provides Layer 3 services to hosts)
CMTS：ケーブルモデム終了システム（レイヤー2ブリッジングまたはレイヤー3ルーティングCMTSにすることができます）GWR：住宅ゲートウェイルーター（ホストにレイヤー3サービスを提供）
Host: PC, notebook, etc., which is connected to the CM or GWR
ホスト：CMまたはGWRに接続されているPC、ノートブックなど
CM: Cable Modem
CM：ケーブルモデム
ER: Edge Router
ER：エッジルーター
MSO: Multiple Service Operator
MSO：複数のサービスオペレーター
Data Over Cable Service Interface Specification (DOCSIS): Standards defining how data should be carried over cable networks
ケーブルサービスインターフェイス仕様（DOCSIS）を介したデータ：データをどのように運ぶかを定義する標準ケーブルネットワーク
Figure 5.1 illustrates the key elements of a Cable Network.
図5.1は、ケーブルネットワークの重要な要素を示しています。
|--- ACCESS ---||------ HFC ------||----- Aggregation / Core -----|
+-----+ +------+
|Host |--| GWR |
+-----+ +--+---+
| _ _ _ _ _ _
+------+ | |
| CM |---| |
+------+ | |
| HFC | +------+ +--------+
| | | | | Edge |
+-----+ +------+ | Network |---| CMTS |---| |=>ISP
|Host |--| CM |---| | | | | Router | Network
+-----+ +--+---+ | | +------+ +--------+
|_ _ _ _ _ _|
+------+ |
+-----+ | GWR/ | |
|Host |--| CM |---------+
+-----+ | |
+------+
Figure 5.1
図5.1
One of the motivators for an MSO to deploy IPv6 over its cable network is to ease management burdens. IPv6 can be enabled on the CM, CMTS, and ER for management purposes. Currently portions of the cable infrastructure use IPv4 address space [RFC1918]; however, there is a finite number of those. Thus, IPv6 could have utility in the cable space implemented on the management plane initially and focused on the data plane for end-user services later. For more details on using IPv6 for management in cable networks, please refer to Section 5.6.1.
MSOがケーブルネットワークにIPv6を展開する動機の1つは、管理の負担を軽減することです。IPv6は、管理目的でCM、CMT、およびERで有効にすることができます。現在、ケーブルインフラストラクチャの一部を使用していますIPv4アドレススペース[RFC1918];ただし、それらには有限数があります。したがって、IPv6は、最初に管理プレーンに実装されたケーブルスペースにユーティリティを持ち、後でエンドユーザーサービスのデータプレーンに焦点を合わせました。ケーブルネットワークの管理にIPv6を使用する詳細については、セクション5.6.1を参照してください。
There are two different deployment modes in current cable networks: a bridged CMTS environment and a routed CMTS environment. IPv6 can be deployed in both of these environments.
現在のケーブルネットワークには、ブリッジ付きCMTS環境とルーティングされたCMTS環境の2つの異なる展開モードがあります。IPv6は、これらの両方の環境で展開できます。
1. Bridged CMTS Network
1. Bridged CMTSネットワーク
In this scenario, both the CM and CMTS bridge all data traffic. Traffic to/from host devices is forwarded through the cable network to the ER. The ER then routes traffic through the ISP network to the Internet. The CM and CMTS support a certain degree of Layer 3 functionality for management purposes.
このシナリオでは、CMとCMTSの両方がすべてのデータトラフィックをブリッジします。ホストデバイスとの間のトラフィックは、ケーブルネットワークを介してERに転送されます。その後、ERはISPネットワークを介してトラフィックをインターネットにルーティングします。CMおよびCMTSは、管理目的である程度のレイヤー3機能をサポートしています。
2. Routed CMTS Network
2. ルーティングされたCMTSネットワーク
In a routed network, the CMTS forwards IP traffic to/from hosts based on Layer 3 information using the IP source/destination address. The CM acts as a Layer 2 bridge for forwarding data traffic and supports some Layer 3 functionality for management purposes.
ルーティングされたネットワークでは、CMTはIPソース/宛先アドレスを使用してレイヤー3情報に基づいて、ホストにIPトラフィックをフォワードします。CMは、データトラフィックを転送するためのレイヤー2ブリッジとして機能し、管理目的でレイヤー3機能をサポートします。
Some of the factors that hinder deployment of native IPv6 in current routed and bridged cable networks include:
現在のルーティングおよびブリッジされたケーブルネットワークでネイティブIPv6の展開を妨げる要因のいくつかは次のとおりです。
A. Changes need to be made to the DOCSIS specification [RF-Interface] to include support for IPv6 on the CM and CMTS. This is imperative for deploying native IPv6 over cable networks.
A. CMおよびCMTSでのIPv6のサポートを含めるには、DOCSIS仕様[RF-Interface]に変更を加える必要があります。これは、ケーブルネットワーク上にネイティブIPv6を展開するために不可欠です。
B. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. In IPv4, these devices rely on Internet Group Multicast Protocol (IGMP) join messages to track membership of hosts that are part of a particular IP multicast group. In order to support ND, a multicast-based process, the CM and CMTS will need to support IGMPv3/Multicast Listener Discovery Version 2 (MLDv2) or v1 snooping.
B. CMおよびCMTSのIPv6 Neighbor Discovery（ND）の問題。IPv4では、これらのデバイスはインターネットグループマルチキャストプロトコル（IGMP）に依存してメッセージを結合して、特定のIPマルチキャストグループの一部であるホストのメンバーシップを追跡します。マルチキャストベースのプロセスであるNDをサポートするには、CMとCMTSはIGMPV3/マルチキャストリスナーディスカバリーバージョン2（MLDV2）またはV1スヌーピングをサポートする必要があります。
C. Classification of IPv6 traffic in the upstream and downstream direction. The CM and CMTS will need to support classification of IPv6 packets in order to give them the appropriate priority and QoS. Service providers that wish to deploy QoS mechanisms also have to support classification of IPv6 traffic.
C.上流および下流の方向におけるIPv6トラフィックの分類。CMおよびCMTSは、適切な優先度とQOを提供するために、IPv6パケットの分類をサポートする必要があります。QoSメカニズムを展開したいサービスプロバイダーは、IPv6トラフィックの分類もサポートする必要があります。
Due to the above mentioned limitations in deployed cable networks, at the time of writing this document, the only option available for cable operators is to use tunneling techniques in order to transport IPv6 traffic over their current IPv4 infrastructure. The following sections will cover tunneling and native IPv6 deployment scenarios in more detail.
展開されたケーブルネットワークの上記の制限により、このドキュメントの作成時点では、ケーブルオペレーターが利用できる唯一のオプションは、現在のIPv4インフラストラクチャにIPv6トラフィックを輸送するためにトンネリングテクニックを使用することです。次のセクションでは、トンネルとネイティブのIPv6展開シナリオを詳細に説明します。
In IPv4, the CM and CMTS act as Layer 2 bridges and forward all data traffic to/from the hosts and the ER. The hosts use the ER as their Layer 3 next hop. If there is a GWR behind the CM it can act as a next hop for all hosts and forward data traffic to/from the ER.
IPv4では、CMおよびCMTSはレイヤー2ブリッジとして機能し、すべてのデータトラフィックをホストおよびERに賛成します。ホストは、次のホップ3レイヤーとしてERを使用します。CMの背後にGWRがある場合、すべてのホストとフォワードデータトラフィックの次のホップとして機能します。
When deploying IPv6 in this environment, the CM and CMTS will continue to act as bridging devices in order to keep the transition smooth and reduce operational complexity. The CM and CMTS will need to bridge IPv6 unicast and multicast packets to/from the ER and the hosts. If there is a GWR connected to the CM, it will need to forward IPv6 unicast and multicast traffic to/from the ER.
この環境にIPv6を展開する場合、CMおよびCMTSは、移行をスムーズに保ち、運用上の複雑さを減らすために、ブリッジングデバイスとして引き続き機能します。CMおよびCMTSは、ERおよびホストに出入りするIPv6ユニキャストとマルチキャストパケットを橋渡しする必要があります。CMに接続されているGWRがある場合、ERに出入りするIPv6ユニキャストとマルチキャストトラフィックを転送する必要があります。
IPv6 can be deployed in a bridged CMTS network either natively or via tunneling. This section discusses the native deployment model. The tunneling model is similar to ones described in Sections 5.2.2.1 and 5.2.2.2.
IPv6は、ネイティブまたはトンネリングを介して、ブリッジ付きCMTSネットワークに展開できます。このセクションでは、ネイティブ展開モデルについて説明します。トンネリングモデルは、セクション5.2.2.1および5.2.2.2で説明されているモデルに似ています。
Figure 5.2.1 illustrates the IPv6 deployment scenario.
図5.2.1は、IPv6の展開シナリオを示しています。
+-----+ +-----+
|Host |--| GWR |
+-----+ +--+--+
| _ _ _ _ _ _
| +------+ | |
+--| CM |---| |
+------+ | |
| HFC | +------+ +--------+
| | | | | Edge |
+-----+ +------+ | Network |---| CMTS |--| |=>ISP
|Host |--| CM |---| | | | | Router |Network
+-----+ +------+ | | +------+ +--------+
|_ _ _ _ _ _|
|-------------||---------------------------------||---------------|
L3 Routed L2 Bridged L3 Routed
Figure 5.2.1
図5.2.1
In this scenario, the CM and the CMTS bridge all data traffic so they will need to support bridging of native IPv6 unicast and multicast traffic. The following devices have to be upgraded to dual stack: Host, GWR, and ER.
このシナリオでは、CMとCMTSはすべてのデータトラフィックをブリッジするため、ネイティブIPv6ユニキャストとマルチキャストトラフィックの架橋をサポートする必要があります。次のデバイスは、ホスト、GWR、およびERのデュアルスタックにアップグレードする必要があります。
The proposed architecture for IPv6 deployment includes two components that must be provisioned: the CM and the host. Additionally if there is a GWR connected to the CM, it will also need to be provisioned. The host or the GWR use the ER as their Layer 3 next hop.
IPv6展開用の提案されたアーキテクチャには、プロビジョニングする必要がある2つのコンポーネントが含まれています。CMとホストです。さらに、CMに接続されたGWRがある場合は、プロビジョニングする必要もあります。ホストまたはGWRは、ERを次のレイヤー3として使用します。
The CM will be provisioned in the same way as in currently deployed cable networks, using an IPv4 address on the cable interface connected to the MSO network for management functions. During the initialization phase, it will obtain its IPv4 address using Dynamic Host Configuration Protocol (DHCPv4), and download a DOCSIS configuration file identified by the DHCPv4 server.
CMは、管理機能のためにMSOネットワークに接続されたケーブルインターフェイスのIPv4アドレスを使用して、現在展開されているケーブルネットワークと同じ方法でプロビジョニングされます。初期化フェーズでは、動的ホスト構成プロトコル（DHCPV4）を使用してIPv4アドレスを取得し、DHCPV4サーバーによって識別されたDOCSIS構成ファイルをダウンロードします。
If there is no GWR connected to the CM, the host behind the CM will get a /64 prefix via stateless auto-configuration or DHCPv6.
CMに接続されているGWRがない場合、CMの背後にあるホストは、Stateless Auto ConfigurationまたはDHCPV6を介してA /64プレフィックスを取得します。
If using stateless auto-configuration, the host listens for routing advertisements (RAs) from the ER. The RAs contain the /64 prefix assigned to the segment. Upon receipt of an RA, the host constructs its IPv6 address by combining the prefix in the RA (/64) and a unique identifier (e.g., its modified EUI-64 (64-bit Extended Unique Identifier) format interface ID).
Stateless Auto Configurationを使用している場合、ホストはERからのルーティング広告（RA）に耳を傾けます。RASには、セグメントに割り当てられた /64プレフィックスが含まれています。RAを受け取ると、ホストはRA（/64）のプレフィックスを組み合わせてIPv6アドレスを構築し、一意の識別子（たとえば、変更されたEUI-64（64ビット拡張ユニークな識別子）形式インターフェイスID）を組み合わせます。
If DHCPv6 is used to obtain an IPv6 address, it will work in much the same way as DHCPv4 works today. The DHCPv6 messages exchanged between the host and the DHCPv6 server are bridged by the CM and the CMTS.
DHCPV6がIPv6アドレスを取得するために使用される場合、DHCPV4が現在機能するのとほぼ同じ方法で機能します。ホストとDHCPV6サーバーの間で交換されるDHCPV6メッセージは、CMとCMTSによって架橋されます。
The GWR can use stateless auto-configuration (RA) to obtain an address for its upstream interface, the link between itself and the ER. This step is followed by a request via DHCP-PD (Prefix Delegation) for a prefix shorter than /64, typically /48 [RFC3177], which in turn is divided into /64s and assigned to its downstream interfaces connecting to the hosts.
GWRは、Stateless Auto Configuration（RA）を使用して、アップストリームインターフェイス、それ自体とERのリンクのアドレスを取得できます。このステップの後に、 /64より短いプレフィックス、通常 /48 [RFC3177]のDHCP-PD（プレフィックス委任）を介したリクエストが続きます。
The CM and CMTS must be able to bridge native IPv6 unicast and multicast traffic. The CMTS must provide IP connectivity between hosts attached to CMs, and must do so in a way that meets the expectation of Ethernet-attached customer equipment. In order to do that, the CM and CMTS must forward Neighbor Discovery (ND) packets between ER and the hosts attached to the CM.
CMおよびCMTSは、ネイティブIPv6ユニキャストとマルチキャストトラフィックを橋渡しできる必要があります。CMTSは、CMSに接続されたホスト間でIP接続を提供する必要があり、イーサネットに適合した顧客機器の期待を満たす方法でそれを行う必要があります。そのためには、CMとCMTSは、ERとCMに接続されたホストの間に近隣発見（ND）パケットを転送する必要があります。
Communication between hosts behind different CMs is always forwarded through the CMTS. IPv6 communication between the different sites relies on multicast IPv6 ND [RFC2461] frames being forwarded correctly by the CM and the CMTS.
異なるCMSの背後にあるホスト間の通信は、常にCMTを介して転送されます。さまざまなサイト間のIPv6通信は、CMとCMTSによって正しく転送されるマルチキャストIPv6 ND [RFC2461]フレームに依存しています。
In order to support IPv6 multicast applications across DOCSIS cable networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 or v1 snooping. MLD is almost identical to IGMP in IPv4, only the name and numbers are changed. MLDv2 is identical to IGMPv3 and also supports ASM (Any-Source Multicast) and SSM (Source-Specific Multicast) service models. Implementation work on CM/CMTS should be minimal because the only significant difference between IPv4 IGMPv3 and IPv6 MLDv2 is the longer addresses in the protocol.
DOCSISケーブルネットワーク全体でIPv6マルチキャストアプリケーションをサポートするために、CMとブリッジングCMTはIGMPV3/MLDV2またはV1スヌーピングをサポートする必要があります。MLDはIPv4のIGMPとほぼ同じであり、名前と数字のみが変更されます。MLDV2はIGMPV3と同一であり、ASM（Any-Source Multicast）およびSSM（ソース固有のマルチキャスト）サービスモデルもサポートしています。CM/CMTでの実装作業は、IPv4 IgMPv3とIPv6 MLDV2の唯一の有意差がプロトコルのより長いアドレスであるため、最小限である必要があります。
The hosts install a default route that points to the ER or the GWR. No routing protocols are needed on these devices, which generally have limited resources. If there is a GWR present, it will also use static default route to the ER.
ホストは、ERまたはGWRを指すデフォルトルートをインストールします。これらのデバイスでは、通常はリソースが限られているルーティングプロトコルは必要ありません。GWRが存在する場合、ERへの静的デフォルトルートも使用します。
The ER runs an IGP such as OSPFv3 or IS-IS. The connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the ER. For this reason, the static routes must also be redistributed. Prefix summarization should be done at the ER.
ERは、OSPFV3またはIS-ISなどのIGPを実行します。接続されたプレフィックスを再配布する必要があります。DHCP-PDを使用する場合、委任されたすべてのプレフィックスで、静的ルートがERによってインストールされます。このため、静的ルートも再配布する必要があります。プレフィックスの要約はERで行う必要があります。
In an IPv4/IPv6 routed CMTS network, the CM still acts as a Layer 2 device and bridges all data traffic between its Ethernet interface and cable interface connected to the cable operator network. The CMTS acts as a Layer 3 router and may also include the ER functionality. The hosts and the GWR use the CMTS as their Layer 3 next hop.
IPv4/IPv6ルーティングされたCMTSネットワークでは、CMはレイヤー2デバイスとして機能し、ケーブルオペレーターネットワークに接続されたイーサネットインターフェイスとケーブルインターフェイスの間のすべてのデータトラフィックをブリッジします。CMTSはレイヤー3ルーターとして機能し、ER機能も含まれる場合があります。ホストとGWRは、CMTをレイヤー3次のホップとして使用します。
When deploying IPv6, the CMTS/ER will need to either tunnel IPv6 traffic or natively support IPv6.
IPv6を展開する場合、CMTS/ERはTunnel IPv6トラフィックのいずれかをサポートするか、IPv6をネイティブにサポートする必要があります。
There are five possible deployment scenarios for IPv6 in a routed CMTS network:
ルーティングされたCMTSネットワークには、IPv6の5つの展開シナリオが5つあります。
1. IPv4 Cable (HFC) Network
1. IPv4ケーブル（HFC）ネットワーク
In this scenario, the cable network, including the CM and CMTS, remain IPv4 devices. The host and ER are upgraded to dual stack. This is the easiest way for a cable operator to provide IPv6 service, as no changes are made to the cable network.
このシナリオでは、CMおよびCMTSを含むケーブルネットワークはIPv4デバイスのままです。ホストとERはデュアルスタックにアップグレードされます。これは、ケーブルネットワークに変更が加えられないため、ケーブルオペレーターがIPv6サービスを提供する最も簡単な方法です。
2. IPv4 Cable (HFC) Network, GWR at Customer Site
2. IPv4ケーブル（HFC）ネットワーク、顧客サイトのGWR
In this case, the cable network, including the CM and CMTS, remain IPv4 devices. The host, GWR, and ER are upgraded to dual stack. This scenario is also easy to deploy since the cable operator just needs to add GWR at the customer site.
この場合、CMおよびCMTSを含むケーブルネットワークは、IPv4デバイスのままです。ホスト、GWR、およびERはデュアルスタックにアップグレードされます。ケーブルオペレーターは顧客サイトにGWRを追加する必要があるため、このシナリオも簡単に展開できます。
3. Dual-stacked Cable (HFC) Network, CM, and CMTS Support IPv6
3. デュアルスタックケーブル（HFC）ネットワーク、CM、およびCMTSはIPv6をサポートしています
In this scenario, the CMTS is upgraded to dual stack to support IPv4 and IPv6. Since the CMTS supports IPv6, it can act as an ER as well. The CM will act as a Layer 2 bridge, but will need to bridge IPv6 unicast and multicast traffic. This scenario is not easy to deploy since it requires changes to the DOCSIS specification. The CM and CMTS may require hardware and software upgrades to support IPv6.
このシナリオでは、CMTSはデュアルスタックにアップグレードされ、IPv4とIPv6をサポートします。CMTSはIPv6をサポートしているため、ERとしても機能します。CMはレイヤー2ブリッジとして機能しますが、IPv6ユニキャストとマルチキャストトラフィックをブリッジする必要があります。このシナリオは、DOCSIS仕様の変更が必要なため、展開するのは簡単ではありません。CMおよびCMTSは、IPv6をサポートするためにハードウェアとソフトウェアのアップグレードが必要になる場合があります。
4. Dual-stacked Cable (HFC) Network, Standalone GWR, and CMTS Support IPv6
4. デュアルスタックケーブル（HFC）ネットワーク、スタンドアロンGWR、およびCMTSはIPv6をサポートしています
In this scenario there is a stand-alone GWR connected to the CM. Since the IPv6 functionality exists on the GWR, the CM does not need to be dual stack. The CMTS is upgraded to dual stack and it can incorporate the ER functionality. This scenario may also require hardware and software changes on the GWR and CMTS.
このシナリオでは、CMに接続されたスタンドアロンGWRがあります。IPv6の機能はGWRに存在するため、CMはデュアルスタックである必要はありません。CMTSはデュアルスタックにアップグレードされ、ER機能を組み込むことができます。このシナリオには、GWRおよびCMTのハードウェアとソフトウェアの変更も必要になる場合があります。
5. Dual-stacked Cable (HFC) Network, Embedded GWR/CM, and CMTS Support IPv6
5. デュアルスタックケーブル（HFC）ネットワーク、埋め込みGWR/CM、およびCMTSはIPv6をサポートします
In this scenario, the CM and GWR functionality exists on a single device, which needs to be upgraded to dual stack. The CMTS will also need to be upgraded to a dual-stack device. This scenario is also difficult to deploy in existing cable network since it requires changes on the Embedded GWR/CM and the CMTS.
このシナリオでは、CMとGWRの機能は単一のデバイスに存在し、デュアルスタックにアップグレードする必要があります。また、CMTはデュアルスタックデバイスにアップグレードする必要があります。このシナリオは、埋め込まれたGWR/CMとCMTSの変更が必要なため、既存のケーブルネットワークに展開することも困難です。
The DOCSIS specification will also need to be modified to allow native IPv6 support on the Embedded GWR/CM.
また、DOCSIS仕様を変更して、埋め込みGWR/CMでネイティブIPv6サポートを許可する必要があります。
This is one of the most cost-effective ways for a cable operator to offer IPv6 services to its customers. Since the cable network remains IPv4, there is relatively minimal cost involved in turning up IPv6 service. All IPv6 traffic is exchanged between the hosts and the ER.
これは、ケーブルオペレーターがIPv6サービスを顧客に提供する最も費用対効果の高い方法の1つです。ケーブルネットワークはIPv4のままであるため、IPv6サービスの上昇には比較的最小限のコストがかかります。すべてのIPv6トラフィックは、ホストとERの間で交換されます。
Figure 5.2.2.1 illustrates this deployment scenario.
図5.2.2.1は、この展開シナリオを示しています。
+-----------+ +------+ +--------+
+-----+ +-------+ | Cable | | | | Edge |
|Host |--| CM |----| (HFC) |---| CMTS |---| |=>ISP
+-----+ +-------+ | Network | | | | Router |Network
+-----------+ +------+ +--------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel
|---------||---------------------------------------||------------|
IPv4/v6 IPv4 only IPv4/v6
Figure 5.2.2.1
図5.2.2.1
In this scenario, the CM and the CMTS will only need to support IPv4, so no changes need to be made to them or the cable network. The following devices have to be upgraded to dual stack: Host and ER.
このシナリオでは、CMとCMTSはIPv4をサポートするだけである必要があるため、それらまたはケーブルネットワークに変更を加える必要はありません。次のデバイスは、ホストとERのデュアルスタックにアップグレードする必要があります。
The only device that needs to be assigned an IPv6 address at the customer site is the host. Host address assignment can be done in multiple ways. Depending on the tunneling mechanism used, it could be automatic or might require manual configuration.
顧客サイトでIPv6アドレスを割り当てる必要がある唯一のデバイスはホストです。ホストアドレスの割り当ては、複数の方法で実行できます。使用されるトンネルメカニズムに応じて、自動になるか、手動構成が必要になる場合があります。
The host still receives an IPv4 address using DHCPv4, which works the same way in currently deployed cable networks. In order to get IPv6 connectivity, host devices will also need an IPv6 address and a means to communicate with the ER.
ホストは引き続きDHCPV4を使用してIPv4アドレスを受け取ります。これは、現在展開されているケーブルネットワークでも同じように機能します。IPv6接続を取得するには、ホストデバイスにはIPv6アドレスとERと通信する手段も必要です。
All IPv6 traffic will be sent to/from the ER and the host device. In order to transport IPv6 packets over the cable operator IPv4 network, the host and the ER will need to use one of the available IPv6 in IPv4 tunneling mechanisms.
すべてのIPv6トラフィックは、ERおよびホストデバイスに送信されます。ケーブルオペレーターIPv4ネットワーク上でIPv6パケットを輸送するには、ホストとERがIPv4トンネリングメカニズムで利用可能なIPv6のいずれかを使用する必要があります。
The host will use its IPv4 address to source the tunnel to the ER. All IPv6 traffic will be forwarded to the ER, encapsulated in IPv4 packets. The intermediate IPv4 nodes will forward this traffic as regular IPv4 packets. The ER will need to terminate the tunnel and/or provide other IPv6 services.
ホストはIPv4アドレスを使用して、トンネルをERに調達します。すべてのIPv6トラフィックは、IPv4パケットにカプセル化されたERに転送されます。中間IPv4ノードは、このトラフィックを通常のIPv4パケットとして転送します。ERは、トンネルを終了したり、他のIPv6サービスを提供したりする必要があります。
Routing configuration on the host will vary depending on the tunneling technique used. In some cases, a default or static route might be needed to forward traffic to the next hop.
ホストのルーティング構成は、使用されるトンネル技術によって異なります。場合によっては、トラフィックを次のホップに転送するには、デフォルトまたは静的ルートが必要になる場合があります。
The ER runs an IGP such as OSPFv3 or ISIS.
ERは、OSPFV3やISISなどのIGPを実行します。
The cable operator can provide IPv6 services to its customers, in this scenario, by adding a GWR behind the CM. Since the GWR will facilitate all IPv6 traffic between the host and the ER, the cable network, including the CM and CMTS, does not need to support IPv6, and can remain as IPv4 devices.
ケーブルオペレーターは、CMの背後にGWRを追加することにより、このシナリオでIPv6サービスを顧客に提供できます。GWRはホストとERの間のすべてのIPv6トラフィックを促進するため、CMおよびCMTSを含むケーブルネットワークはIPv6をサポートする必要はなく、IPv4デバイスとして留まることができます。
Figure 5.2.2.2 illustrates this deployment scenario.
図5.2.2.2は、この展開シナリオを示しています。
+-----+
|Host |
+--+--+
| +-----------+ +------+ +--------+
+---+---+ +-------+ | Cable | | | | Edge |
| GWR |--| CM |----| (HFC) |---| CMTS |---| |=>ISP
+-------+ +-------+ | Network | | | | Router |Network
+-----------+ +------+ +--------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel
|---------||--------------------------------------||-------------|
IPv4/v6 IPv4 only IPv4/v6
Figure 5.2.2.2
図5.2.2.2
In this scenario, the CM and the CMTS will only need to support IPv4, so no changes need to be made to them or the cable network. The following devices have to be upgraded to dual stack: Host, GWR, and ER.
このシナリオでは、CMとCMTSはIPv4をサポートするだけである必要があるため、それらまたはケーブルネットワークに変更を加える必要はありません。次のデバイスは、ホスト、GWR、およびERのデュアルスタックにアップグレードする必要があります。
The only devices that need to be assigned an IPv6 address at customer site are the host and GWR. IPv6 address assignment can be done statically at the GWR downstream interface. The GWR will send out RA messages on its downstream interface, which will be used by the hosts to auto-configure themselves with an IPv6 address. The GWR can also configure its upstream interface using RA messages from the ER and use DHCP-PD for requesting a /48 [RFC3177] prefix from the ER. This /48 prefix will be used to configure /64s on hosts connected to the GWR downstream interfaces. The uplink to the ISP network is configured with a /64 prefix as well.
顧客サイトでIPv6アドレスを割り当てる必要がある唯一のデバイスは、ホストとGWRです。IPv6アドレスの割り当ては、GWRダウンストリームインターフェイスで静的に実行できます。GWRは、下流インターフェイスにRAメッセージを送信します。これは、ホストがIPv6アドレスで自動構成するために使用します。GWRは、ERからのRAメッセージを使用して上流インターフェイスを構成し、DHCP-PDを使用してERからA /48 [RFC3177]プレフィックスを要求することもできます。この /48プレフィックスは、GWRダウンストリームインターフェイスに接続されたホストで /64Sを構成するために使用されます。ISPネットワークへのアップリンクは、A /64プレフィックスでも構成されています。
The GWR still receives a global IPv4 address on its upstream interface using DHCPv4, which works the same way in currently deployed cable networks. In order to get IPv6 connectivity to the Internet, the GWR will need to communicate with the ER.
GWRは、DHCPV4を使用して上流インターフェイスでグローバルIPv4アドレスを受信します。これは、現在展開されているケーブルネットワークでも同じように機能します。IPv6接続をインターネットに導入するには、GWRはERと通信する必要があります。
All IPv6 traffic will be sent to/from the ER and the GWR, which will forward IPv6 traffic to/from the host. In order to transport IPv6 packets over the cable operator IPv4 network, the GWR and the ER will need to use one of the available IPv6 in IPv4 tunneling mechanisms. All IPv6 traffic will need to go through the tunnel, once it comes up.
すべてのIPv6トラフィックは、ERおよびGWRに出入りするもので、IPv6トラフィックをホストに送信します。ケーブルオペレーターIPv4ネットワーク上でIPv6パケットを輸送するには、GWRとERは、IPv4トンネリングメカニズムで利用可能なIPv6のいずれかを使用する必要があります。すべてのIPv6トラフィックがトンネルを通過する必要があります。
The GWR will use its IPv4 address to source the tunnel to the ER. The tunnel endpoint will be the IPv4 address of the ER. All IPv6 traffic will be forwarded to the ER, encapsulated in IPv4 packets. The intermediate IPv4 nodes will forward this traffic as regular IPv4 packets. In case of 6to4 tunneling, the ER will need to support 6to4 relay functionality in order to provide IPv6 Internet connectivity to the GWR, and hence, the hosts connected to the GWR.
GWRはIPv4アドレスを使用して、トンネルをERに調達します。トンネルのエンドポイントは、ERのIPv4アドレスになります。すべてのIPv6トラフィックは、IPv4パケットにカプセル化されたERに転送されます。中間IPv4ノードは、このトラフィックを通常のIPv4パケットとして転送します。6to4トンネルの場合、ERはGWRにIPv6インターネット接続を提供するために6to4リレー機能をサポートする必要があります。したがって、ホストはGWRに接続されています。
Depending on the tunneling technique used, additional configuration might be needed on the GWR and the ER. If the ER is also providing a 6to4 relay service then a default route will need to be added to the GWR pointing to the ER, for all non-6to4 traffic.
If using manual tunneling, the GWR and ER can use static routing or an IGP such as RIPng [RFC2080]. The RIPng updates can be transported over a manual tunnel, which does not work when using 6to4 tunneling since it does not support multicast.
手動トンネリングを使用する場合、GWRとERは静的ルーティングまたはRIPNG [RFC2080]などのIGPを使用できます。RIPNGの更新は、マルチキャストをサポートしていないため、6to4トンネルを使用する場合は機能しない手動トンネル上で輸送できます。
Customer routes can be carried to the ER using RIPng updates. The ER can advertise these routes in its IGP. Prefix summarization should be done at the ER.
顧客ルートは、RIPNGアップデートを使用してERに持ち込むことができます。ERは、IGPでこれらのルートを宣伝できます。プレフィックスの要約はERで行う必要があります。
If DHCP-PD is used for address assignment, a static route is automatically installed on the ER for each delegated /48 prefix. The static routes need to be redistributed into the IGP at the ER, so there is no need for a routing protocol between the ER and the GWR.
DHCP-PDがアドレス割り当てに使用される場合、委任された各プレフィックスのERに静的ルートが自動的にインストールされます。静的ルートは、ERのIGPに再配布する必要があるため、ERとGWRの間のルーティングプロトコルは必要ありません。
The ER runs an IGP such as OSPFv3 or ISIS.
ERは、OSPFV3やISISなどのIGPを実行します。
In this scenario the cable operator can offer native IPv6 services to its customers since the cable network, including the CMTS, supports IPv6. The ER functionality can be included in the CMTS or it can exist on a separate router connected to the CMTS upstream interface. The CM will need to bridge IPv6 unicast and multicast traffic.
このシナリオでは、CMTSを含むケーブルネットワークがIPv6をサポートするため、ケーブルオペレーターはネイティブIPv6サービスを顧客に提供できます。ER機能はCMTSに含めることができます。または、CMTSアップストリームインターフェイスに接続された個別のルーターに存在できます。CMは、IPv6ユニキャストとマルチキャストトラフィックを橋渡しする必要があります。
Figure 5.2.2.3 illustrates this deployment scenario.
図5.2.2.3は、この展開シナリオを示しています。
+-----------+ +-------------+
+-----+ +-------+ | Cable | | CMTS / Edge |
|Host |--| CM |----| (HFC) |---| |=>ISP
+-----+ +-------+ | Network | | Router | Network
+-----------+ +-------------+
|-------||---------------------------||---------------|
IPv4/v6 IPv4/v6 IPv4/v6
Figure 5.2.2.3
図5.2.2.3
Since the CM still acts as a Layer 2 bridge, it does not need to be dual stack. The CM will need to support bridging of IPv6 unicast and multicast traffic and IGMPv3/MLDv2 or v1 snooping, which requires changes in the DOCSIS specification. In this scenario, the following devices have to be upgraded to dual stack: Host and CMTS/ER.
CMは依然としてレイヤー2ブリッジとして機能するため、デュアルスタックである必要はありません。CMは、IPv6ユニキャストおよびマルチキャストトラフィックの橋渡しとIgmpv3/MLDV2またはV1スヌーピングをサポートする必要があります。これには、DOCSIS仕様の変更が必要です。このシナリオでは、次のデバイスをデュアルスタック（ホストとCMT/ER）にアップグレードする必要があります。
In cable networks today, the CM receives a private IPv4 address using DHCPv4 for management purposes. In an IPv6 environment, the CM will continue to use an IPv4 address for management purposes. The cable operator can also choose to assign an IPv6 address to the CM for management, but the CM will have to be upgraded to support this functionality.
今日のケーブルネットワークでは、CMは管理目的でDHCPV4を使用してプライベートIPv4アドレスを受け取ります。IPv6環境では、CMは管理目的でIPv4アドレスを引き続き使用します。ケーブルオペレーターは、管理のためにCMにIPv6アドレスを割り当てることもできますが、この機能をサポートするにはCMをアップグレードする必要があります。
IPv6 address assignment for the CM and host can be done via DHCP or stateless auto-configuration. If the CM uses an IPv4 address for management, it will use DHCPv4 for its address assignment and the CMTS will need to act as a DHCPv4 relay agent. If the CM uses an IPv6 address for management, it can use DHCPv6, with the CMTS acting as a DHCPv6 relay agent, or the CMTS can be statically configured with a /64 prefix and it can send out RA messages out the cable interface. The CMs connected to the cable interface can use the RA messages to auto-configure themselves with an IPv6 address. All CMs connected to the cable interface will be in the same subnet.
CMおよびホストのIPv6アドレスの割り当ては、DHCPまたはStateless Auto Configurationを介して実行できます。CMが管理にIPv4アドレスを使用している場合、アドレス割り当てにDHCPV4を使用し、CMTSはDHCPV4リレーエージェントとして機能する必要があります。CMが管理にIPv6アドレスを使用する場合、DHCPV6を使用してCMTSをDHCPV6リレーエージェントとして機能させるか、CMTをA /64プレフィックスで静的に構成し、RAメッセージをケーブルインターフェイスから送信できます。ケーブルインターフェイスに接続されたCMSは、RAメッセージを使用して、IPv6アドレスで自動構成することができます。ケーブルインターフェイスに接続されているすべてのCMSは、同じサブネットになります。
The hosts can receive their IPv6 address via DHCPv6 or stateless auto-configuration. With DHCPv6, the CMTS may need to act as a DHCPv6 relay agent and forward DHCP messages between the hosts and the DHCP server. With stateless auto-configuration, the CMTS will be configured with multiple /64 prefixes and send out RA messages to the hosts. If the CMTS is not also acting as an ER, the RA messages will come from the ER connected to the CMTS upstream interface. The CMTS will need to forward the RA messages downstream or act as an ND proxy.
ホストは、DHCPV6またはStateless Auto Configurationを介してIPv6アドレスを受け取ることができます。DHCPV6を使用すると、CMTSはDHCPV6リレーエージェントとして機能し、ホストとDHCPサーバーの間でDHCPメッセージを転送する必要がある場合があります。Stateless Auto Configurationを使用すると、CMTは複数 /64プレフィックスで構成され、RAメッセージをホストに送信します。CMTSがERとしても作用していない場合、RAメッセージはCMTSアップストリームインターフェイスに接続されたERから届きます。CMTSは、下流のRAメッセージを転送するか、NDプロキシとして機能する必要があります。
All IPv6 traffic will be sent to/from the CMTS and hosts. Data forwarding will work the same way it works in currently deployed cable networks. The CMTS will forward IPv6 traffic to/from hosts based on the IP source/destination address.
すべてのIPv6トラフィックは、CMTSおよびホストに送信されます。データ転送は、現在展開されているケーブルネットワークで機能するのと同じように機能します。CMTSは、IPソース/宛先アドレスに基づいて、ホストに出入りするIPv6トラフィックを転送します。
No routing protocols are needed between the CMTS and the host since the CM and host are directly connected to the CMTS cable interface. Since the CMTS supports IPv6, hosts will use the CMTS as their Layer 3 next hop.
CMとホストはCMTSケーブルインターフェイスに直接接続されているため、CMTとホストの間にはルーティングプロトコルは必要ありません。CMTSはIPv6をサポートしているため、ホストはCMTをレイヤー3の次のホップとして使用します。
If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or IS-IS.
CMTがERとしても機能している場合、OSPFV3やIS-ISなどのIGPを実行します。
In this case, the cable operator can offer IPv6 services to its customers by adding a GWR between the CM and the host. The GWR will facilitate IPv6 communication between the host and the CMTS/ER. The CMTS will be upgraded to dual stack to support IPv6 and can act as an ER as well. The CM will act as a bridge for forwarding data traffic and does not need to support IPv6.
この場合、ケーブルオペレーターは、CMとホストの間にGWRを追加することにより、顧客にIPv6サービスを提供できます。GWRは、ホストとCMTS/ER間のIPv6通信を促進します。CMTは、IPv6をサポートするためにデュアルスタックにアップグレードされ、ERとしても機能します。CMは、データトラフィックを転送するためのブリッジとして機能し、IPv6をサポートする必要はありません。
This scenario is similar to the case described in Section 5.2.2.2. The only difference in this case is that the ER functionality exists on the CMTS instead of on a separate router in the cable operator network.
このシナリオは、セクション5.2.2.2で説明されているケースに似ています。この場合の唯一の違いは、ER機能がケーブルオペレーターネットワークの別のルーターではなく、CMTSに存在することです。
Figure 5.2.2.4 illustrates this deployment scenario.
図5.2.2.4は、この展開シナリオを示しています。
+-----------+ +-----------+
+------+ +-------+ +-------+ | Cable | |CMTS / Edge|
| Host |--| GWR |--| CM |---| (HFC) |---| |=>ISP
+------+ +-------+ +-------+ | Network | | Router |Network
+-----------+ +-----------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel
|-----------------||-----------------------------||--------------|
IPv4/v6 IPv4 IPv4/v6
Figure 5.2.2.4
図5.2.2.4
Since the CM still acts as a Layer 2 bridge, it does not need to be dual stack, nor does it need to support IPv6. In this scenario, the following devices have to be upgraded to dual stack: Host, GWR, and CMTS/ER.
CMはまだレイヤー2ブリッジとして機能するため、デュアルスタックである必要はなく、IPv6をサポートする必要もありません。このシナリオでは、次のデバイスをデュアルスタック、ホスト、GWR、およびCMTS/ERにアップグレードする必要があります。
The CM will still receive a private IPv4 address using DHCPv4, which works the same way in existing cable networks. The CMTS will act as a DHCPv4 relay agent.
CMは、既存のケーブルネットワークでも同じように機能するDHCPV4を使用して、プライベートIPv4アドレスを受け取ります。CMTSはDHCPV4リレーエージェントとして機能します。
The address assignment for the host and GWR happens in a similar manner as described in Section 5.2.2.2.2.
ホストとGWRのアドレス割り当ては、セクション5.2.2.2.2で説明されているように同様の方法で発生します。
Data forwarding between the host and CMTS/ER is facilitated by the GWR and happens in a similar manner as described in Section 5.2.2.2.3.
ホストとCMTS/ER間のデータ転送はGWRによって促進され、セクション5.2.2.2.3で説明されているように同様の方法で発生します。
In this case, routing is very similar to the case described in Section 5.2.2.2.4. Since the CMTS now incorporates the ER functionality, it will need to run an IGP such as OSPFv3 or IS-IS.
この場合、ルーティングはセクション5.2.2.2.4で説明されているケースと非常に似ています。CMTSにはER機能が組み込まれているため、OSPFV3やIS-ISなどのIGPを実行する必要があります。
In this scenario, the cable operator can offer native IPv6 services to its customers since the cable network, including the CM/Embedded GWR and CMTS, supports IPv6. The ER functionality can be included in the CMTS or it can exist on a separate router connected to the CMTS upstream interface. The CM/Embedded GWR acts as a Layer 3 device.
このシナリオでは、ケーブルオペレーターは、CM/埋め込みGWRやCMTSを含むケーブルネットワークがIPv6をサポートするため、ネイティブIPv6サービスを顧客に提供できます。ER機能はCMTSに含めることができます。または、CMTSアップストリームインターフェイスに接続された個別のルーターに存在できます。CM/埋め込みGWRは、レイヤー3デバイスとして機能します。
Figure 5.2.2.5 illustrates this deployment scenario.
図5.2.2.5は、この展開シナリオを示しています。
+-----------+ +-------------+
+-----+ +-----------+ | Cable | | CMTS / Edge |
|Host |---| CM / GWR |---| (HFC) |---| |=>ISP
+-----+ +-----------+ | Network | | Router |Network
+-----------+ +-------------+
|---------------------------------------------------------|
IPv4/v6
Figure 5.2.2.5
図5.2.2.5
Since the CM/GWR acts as a Layer 3 device, IPv6 can be deployed end-to-end. In this scenario, the following devices have to be upgraded to dual stack: Host, CM/GWR, and CMTS/ER.
CM/GWRはレイヤー3デバイスとして機能するため、IPv6はエンドツーエンドを展開できます。このシナリオでは、次のデバイスをデュアルスタック、ホスト、CM/GWR、およびCMTS/ERにアップグレードする必要があります。
Since the CM/GWR is dual stack, it can receive an IPv4 or IPv6 address using DHCP for management purposes. As the GWR functionality is embedded in the CM, it will need an IPv6 address for forwarding data traffic. IPv6 address assignment for the CM/GWR and host can be done via DHCPv6 or DHCP-PD.
CM/GWRはデュアルスタックであるため、管理目的でDHCPを使用してIPv4またはIPv6アドレスを受信できます。GWR機能はCMに埋め込まれているため、データトラフィックを転送するためにIPv6アドレスが必要になります。CM/GWRおよびホストのIPv6アドレス割り当ては、DHCPV6またはDHCP-PDを介して実行できます。
If using DHCPv6, the CMTS will need to act as a DHCPv6 relay agent. The host and CM/GWR will receive IPv6 addresses from pools of /64 prefixes configured on the DHCPv6 server. The CMTS will need to glean pertinent information from the DHCP Offer messages, sent from the DHCP server to the DHCP clients (host and CM/GWR), much like it does today in DHCPv4. All CM/GWR connected to the same cable interface on the CMTS belong to the same management /64 prefix. The hosts connected to the same cable interface on the CMTS may belong to different /64 customer prefixes, as the CMTS may have multiple /64 prefixes configured under its cable interfaces.
DHCPV6を使用する場合、CMTSはDHCPV6リレーエージェントとして機能する必要があります。ホストとCM /GWRは、DHCPV6サーバーで構成された /64プレフィックスのプールからIPv6アドレスを受け取ります。CMTSは、DHCPサーバーからDHCPクライアント（ホストおよびCM/GWR）に送信されるDHCP提供メッセージから関連情報を収集する必要があります。CMTS上の同じケーブルインターフェイスに接続されたすべてのCM /GWRは、同じ管理 /64プレフィックスに属します。CMTSの同じケーブルインターフェイスに接続されたホストは、CMTSにはケーブルインターフェイスの下で構成された複数の /64のプレフィックスがあるため、異なる /64の顧客プレフィックスに属する場合があります。
It is also possible to use DHCP-PD for an IPv6 address assignment. In this case, the CM/GWR will use stateless auto-configuration to assign an IPv6 address to its upstream interface using the /64 prefix sent by the CMTS/ER in an RA message. Once the CM/GWR assigns an IPv6 address to its upstream interface, it will request a /48 [RFC3177] prefix from the CMTS/ER and chop this /48 prefix into /64s for assigning IPv6 addresses to hosts. The uplink to the ISP network is configured with a /64 prefix as well.
IPv6アドレスの割り当てにDHCP-PDを使用することもできます。この場合、CM/GWRは、RAメッセージでCMTS/ERによって送信された/64プレフィックスを使用して、Stateless Auto Configurationを使用してIPv6アドレスをアップストリームインターフェイスに割り当てます。CM /GWRがIPv6アドレスをアップストリームインターフェイスに割り当てると、CMTS /ERからA /48 [RFC3177]プレフィックスを要求し、IPv6アドレスをホストに割り当てるためにこの /48プレフィックスを /64Sにチョップします。ISPネットワークへのアップリンクは、A /64プレフィックスでも構成されています。
The host will use the CM/GWR as the Layer 3 next hop. The CM/GWR will forward all IPv6 traffic to/from the CMTS/ER and hosts. The CMTS/ER will forward IPv6 traffic to/from hosts based on the IP source/destination address.
ホストは、CM/GWRをレイヤー3の次のホップとして使用します。CM/GWRは、すべてのIPv6トラフィックをCMTS/ERおよびホストに出入りさせます。CMTS/ERは、IPソース/宛先アドレスに基づいて、ホストに出入りするIPv6トラフィックを転送します。
The CM/GWR can use a static default route pointing to the CMTS/ER or it can run a routing protocol such as RIPng or OSPFv3 between itself and the CMTS. Customer routes from behind the CM/GWR can be carried to the CMTS using routing updates.
CM/GWRは、CMTS/ERを指す静的なデフォルトルートを使用したり、それ自体とCMTSの間でRIPNGやOSPFV3などのルーティングプロトコルを実行できます。CM/GWRの後ろからの顧客ルートは、ルーティングアップデートを使用してCMTSに運ぶことができます。
If DHCP-PD is used for address assignment, a static route is automatically installed on the CMTS/ER for each delegated /48 prefix. The static routes need to be redistributed into the IGP at the CMTS/ER so there is no need for a routing protocol between the CMTS/ER and the GWR.
DHCP-PDがアドレス割り当てに使用される場合、各委任 /48プレフィックスのCMTS /ERに静的ルートが自動的にインストールされます。静的ルートは、CMTS/ERでIGPに再配布する必要があるため、CMTS/ERとGWRの間にルーティングプロトコルは必要ありません。
If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or IS-IS.
CMTがERとしても機能している場合、OSPFV3やIS-ISなどのIGPを実行します。
In order to support IPv6 multicast applications across DOCSIS cable networks, the CM and bridging CMTS will need to support IGMPv3/MLDv2 or v1 snooping. MLD is almost identical to IGMP in IPv4, only the name and numbers are changed. MLDv2 is almost identical to IGMPv3 and also supports ASM (Any-Source Multicast) and SSM (Source-Specific Multicast) service models.
DOCSISケーブルネットワーク全体でIPv6マルチキャストアプリケーションをサポートするには、CMとブリッジングCMTSはIGMPV3/MLDV2またはV1スヌーピングをサポートする必要があります。MLDはIPv4のIGMPとほぼ同じであり、名前と数字のみが変更されます。MLDV2はIGMPV3とほぼ同一であり、ASM（Any-Source Multicast）およびSSM（ソース固有のマルチキャスト）サービスモデルもサポートしています。
SSM is more suited for deployments where the SP intends to provide paid content to the users (video or audio). These types of services are expected to be of primary interest. Moreover, the simplicity of the SSM model often overrides the scalability issues that would be resolved in an ASM model. ASM is, however, an option that is discussed in Section 6.3.1. The Layer 3 CM, GWR, and Layer 3 routed CMTS/ER will need to be enabled with PIM-SSM, which requires the definition and support for IGMPv3/MLDv1 or v2 snooping, in order to track join/leave messages from the hosts. Another option would be for the Layer 3 CM or GWR to support MLD proxy routing. The Layer 3 next hop for the hosts needs to support MLD.
SSMは、SPがユーザーに有料コンテンツを提供するつもりである展開により適しています（ビデオまたはオーディオ）。これらのタイプのサービスは、主要な関心があると予想されています。さらに、SSMモデルの単純さは、ASMモデルで解決されるスケーラビリティの問題をオーバーライドすることがよくあります。ただし、ASMはセクション6.3.1で説明されているオプションです。層3 cm、GWR、およびレイヤー3ルーティングCMTS/ERは、PIM-SSMで有効にする必要があります。これには、ホストからの結合メッセージを追跡するために、IGMPV3/MLDV1またはV2スヌーピングの定義とサポートが必要です。別のオプションは、MLDプロキシルーティングをサポートするためのレイヤー3 cmまたはGWRの場合です。レイヤー3次は、ホストのためのホップMLDをサポートする必要があります。
Refer to Section 6.3 for more IPv6 multicast details.
その他のIPv6マルチキャストの詳細については、セクション6.3を参照してください。
IPv6 will not change or add any queuing/scheduling functionality already existing in DOCSIS specifications. But the QoS mechanisms on the CMTS and CM would need to be IPv6 capable. This includes support for IPv6 classifiers, so that data traffic to/from host devices can be classified appropriately into different service flows and be assigned appropriate priority. Appropriate classification criteria would need to be implemented for unicast and multicast traffic.
IPv6は、DOCSIS仕様に既に存在するキューイング/スケジューリング機能を変更または追加しません。しかし、CMTとCMのQoSメカニズムはIPv6対応である必要があります。これには、IPv6分類器のサポートが含まれます。これにより、ホストデバイスへの出来事とのデータトラフィックは、異なるサービスフローに適切に分類し、適切な優先度を割り当てることができます。ユニキャストおよびマルチキャストトラフィックには、適切な分類基準を実装する必要があります。
Traffic classification and marking should be done at the CM for upstream traffic and the CMTS/ER for downstream traffic, in order to support the various types of services: data, voice, and video. The same IPv4 QoS concepts and methodologies should be applied for IPv6 as well.
さまざまな種類のサービスをサポートするために、上流トラフィックの場合はCMおよび下流トラフィックのCMTS/ERのトラフィック分類とマーキングを行う必要があります。データ、音声、ビデオをサポートする必要があります。同じIPv4 QoSの概念と方法論もIPv6に適用する必要があります。
It is important to note that when traffic is encrypted end-to-end, the traversed network devices will not have access to many of the packet fields used for classification purposes. In these cases, routers will most likely place the packets in the default classes. The QoS design should take into consideration this scenario and try to use mainly IP header fields for classification purposes.
トラフィックがエンドツーエンドで暗号化されている場合、トラバースされたネットワークデバイスは分類に使用されるパケットフィールドの多くにアクセスできないことに注意することが重要です。これらの場合、ルーターはおそらくパケットをデフォルトのクラスに配置します。QoS設計では、このシナリオを考慮し、分類目的で主にIPヘッダーフィールドを使用しようとする必要があります。
Security in a DOCSIS cable network is provided using Baseline Privacy Plus (BPI+). The only part that is dependent on IP addresses is encrypted multicast. Semantically, multicast encryption would work the same way in an IPv6 environment as in the IPv4 network. However, appropriate enhancements will be needed in the DOCSIS specification to support encrypted IPv6 multicast.
DOCSISケーブルネットワークのセキュリティは、ベースラインプライバシープラス（BPI）を使用して提供されます。IPアドレスに依存する唯一の部分は、暗号化されたマルチキャストです。意味的には、マルチキャスト暗号化はIPv4ネットワークと同じように同じように機能します。ただし、暗号化されたIPv6マルチキャストをサポートするために、DOCSIS仕様で適切な拡張機能が必要になります。
There are limited changes that have to be done for hosts in order to enhance security. The privacy extensions [RFC3041] for auto-configuration should be used by the hosts. IPv6 firewall functions could be enabled, if available on the host or GWR.
セキュリティを強化するためには、ホストに対して行う必要がある限られた変更があります。自動構成のためのプライバシー拡張[RFC3041]は、ホストが使用する必要があります。IPv6ファイアウォール機能は、ホストまたはGWRで利用可能な場合、有効にすることができます。
The ISP provides security against attacks that come from its own subscribers, but it could also implement security services that protect its subscribers from attacks sourced from the outside of its network. Such services do not apply at the access level of the network discussed here.
ISPは、独自の加入者から生じる攻撃に対するセキュリティを提供しますが、ネットワークの外側から供給された攻撃から加入者を保護するセキュリティサービスを実装することもできます。このようなサービスは、ここで説明するネットワークのアクセスレベルでは適用されません。
The CMTS/ER should protect the ISP network and the other subscribers against attacks by one of its own customers. For this reason Unicast Reverse Path Forwarding (uRPF) [RFC3704] and Access Control Lists (ACLs) should be used on all interfaces facing subscribers. Filtering should be implemented with regard for the operational requirements of IPv6 [IPv6-Security].
CMTS/ERは、ISPネットワークと他のサブスクライバーが、それ自体の顧客の1人による攻撃から保護する必要があります。このため、ユニキャストリバースパス転送（URPF）[RFC3704]およびアクセス制御リスト（ACL）は、サブスクライバーに直面しているすべてのインターフェイスで使用する必要があります。IPv6 [IPv6-Security]の運用要件に関して、フィルタリングを実装する必要があります。
The CMTS/ER should protect its processing resources against floods of valid customer control traffic such as: Router and Neighbor Solicitations, and MLD Requests.
CMTS/ERは、ルーターや近隣の勧誘、MLDリクエストなど、有効な顧客制御トラフィックの洪水から処理リソースを保護する必要があります。
All other security features used with the IPv4 service should be similarly applied to IPv6 as well.
IPv4サービスで使用される他のすべてのセキュリティ機能も同様にIPv6に適用する必要があります。
IPv6 can have many applications in cable networks. MSOs can initially implement IPv6 on the control plane and use it to manage the thousands of devices connected to the CMTS. This would be a good way to introduce IPv6 in a cable network. Later, the MSO can extend IPv6 to the data plane and use it to carry customer traffic as well as management traffic.
IPv6は、ケーブルネットワークに多くのアプリケーションを持つことができます。MSOは最初にコントロールプレーンにIPv6を実装し、それを使用してCMTに接続された数千のデバイスを管理できます。これは、ケーブルネットワークにIPv6を導入する良い方法です。その後、MSOはIPv6をデータプレーンに拡張し、それを使用して顧客のトラフィックと管理トラフィックを運ぶことができます。
IPv6 can be enabled in a cable network for management of devices like CM, CMTS, and ER. With the rollout of advanced services like VoIP and Video-over-IP, MSOs are looking for ways to manage the large number of devices connected to the CMTS. In IPv4, an RFC1918 address is assigned to these devices for management purposes. Since there is a finite number of RFC1918 addresses available, it is becoming difficult for MSOs to manage these devices.
IPv6は、CM、CMT、ERなどのデバイスの管理のためにケーブルネットワークで有効にすることができます。VoIPやVideo-Over-IPなどの高度なサービスの展開により、MSOはCMTに接続された多数のデバイスを管理する方法を探しています。IPv4では、管理目的でRFC1918アドレスがこれらのデバイスに割り当てられています。有限数のRFC1918アドレスが利用可能であるため、MSOがこれらのデバイスを管理することは困難になっています。
By using IPv6 for management purposes, MSOs can scale their network management systems to meet their needs. The CMTS/ER can be configured with a /64 management prefix that is shared among all CMs connected to the CMTS cable interface. Addressing for the CMs can be done via stateless auto-configuration or DHCPv6. Once the CMs receive a /64 prefix, they can configure themselves with an IPv6 address.
管理目的でIPv6を使用することにより、MSOはネットワーク管理システムをスケーリングしてニーズを満たすことができます。CMTS /ERは、CMTSケーブルインターフェイスに接続されたすべてのCMS間で共有されるA /64管理プレフィックスで構成できます。CMSのアドレス指定は、Stateless Auto ConfigurationまたはDHCPV6を介して実行できます。CMSがA /64プレフィックスを受信すると、IPv6アドレスで自分自身を構成できます。
If there are devices behind the CM that need to be managed by the MSO, another /64 prefix can be defined on the CMTS/ER. These devices can also use stateless auto-configuration to assign themselves an IPv6 address.
MSOが管理する必要があるCMの背後にデバイスがある場合、別の /64プレフィックスをCMTS /ERで定義できます。これらのデバイスは、Stateless Auto Configurationを使用してIPv6アドレスを割り当てることもできます。
Traffic sourced from or destined to the management prefix should not cross the MSO's network boundaries.
管理プレフィックスからまたは運命づけられたトラフィックは、MSOのネットワーク境界を越えてはなりません。
In this scenario, IPv6 will only be used for managing devices on the cable network. The CM will no longer require an IPv4 address for management as described in DOCSIS 3.0 [DOCSIS3.0-Reqs].
このシナリオでは、IPv6はケーブルネットワーク上のデバイスの管理にのみ使用されます。CMは、DOCSIS 3.0 [DOCSIS3.0-REQS]で説明されているように、管理にIPv4アドレスを必要としなくなります。
The current DOCSIS, PacketCable, and CableHome MIB modules are already designed to support IPv6 objects. In this case, IPv6 will neither add nor change any of the functionality of these MIB modules. The Textual Convention used to represent Structure of Management Information Version 2 (SMIv2) objects representing IP addresses was updated [RFC4001] and a new Textual Convention InetAddressType was added to identify the type of the IP address used for IP address objects in MIB modules.
現在のDOCSIS、PacketCable、およびCablehome MIBモジュールは、IPv6オブジェクトをサポートするように既に設計されています。この場合、IPv6はこれらのMIBモジュールの機能を追加も変更も変更しません。IPアドレスを表す管理情報バージョン2（SMIV2）オブジェクトの構造を表すために使用されるテキスト条約は、MIBモジュールのIPアドレスオブジェクトに使用されるIPアドレスのタイプを識別するために、新しいテキスト条約InetAddressTypeを追加しました。
There are some exceptions; the MIB modules that might need to add IPv6 support are defined in the DOCSIS 3.0 OSSI specification [DOCSIS3.0-OSSI].
いくつかの例外があります。IPv6サポートを追加する必要があるMIBモジュールは、DOCSIS 3.0 OOSSI仕様[DOCSIS3.0-OSSI]で定義されています。
This section describes the IPv6 deployment options in today's high-speed DSL networks.
このセクションでは、今日の高速DSLネットワークのIPv6展開オプションについて説明します。
Digital Subscriber Line (DSL) broadband services provide users with IP connectivity over the existing twisted-pair telephone lines called the local-loop. A wide range of bandwidth offerings are available depending on the quality of the line and the distance between the Customer Premise Equipment and the DSL Access Multiplexer (DSLAM).
デジタルサブスクライバーライン（DSL）ブロードバンドサービスは、ローカルループと呼ばれる既存のツイストペア電話回線上のIP接続をユーザーに提供します。幅広い帯域幅の提供物は、ラインの品質と顧客の前提装備とDSLアクセスマルチプレクサ（DSLAM）の間の距離に応じて利用できます。
The following network elements are typical of a DSL network:
次のネットワーク要素は、DSLネットワークの典型です。
DSL Modem: It can be a stand-alone device, be incorporated in the host, incorporate router functionalities, and also have the capability to act as a CPE router.
DSL Modem：スタンドアロンデバイスであり、ホストに組み込まれ、ルーター機能を組み込んでおり、CPEルーターとして機能する機能を備えています。
Customer Premise Router (CPR): It is used to provide Layer 3 services for customer premise networks. It is usually used to provide firewalling functions and segment broadcast domains for a small business.
Customer Premise Router（CPR）：顧客の前提ネットワークにレイヤー3サービスを提供するために使用されます。通常、中小企業向けにファイアウォール機能とセグメントブロードキャストドメインを提供するために使用されます。
DSL Access Multiplexer (DSLAM): It terminates multiple twisted-pair telephone lines and provides aggregation to BRAS.
DSL Access Multiplexer（DSLAM）：複数のツイストペア電話回線を終了し、BRAに集約を提供します。
Broadband Remote Access Server (BRAS): It aggregates or terminates multiple Permanent Virtual Circuits (PVCs) corresponding to the subscriber DSL circuits.
ブロードバンドリモートアクセスサーバー（BRA）：サブスクライバーDSLサーキットに対応する複数の永続的な仮想回路（PVC）を集約または終了します。
Edge Router (ER): It provides the Layer 3 interface to the ISP network.
Edge Router（ER）：ISPネットワークへのレイヤー3インターフェイスを提供します。
Figure 6.1 depicts all the network elements mentioned.
図6.1は、言及されたすべてのネットワーク要素を示しています。
Customer Premise | Network Access Provider | Network Service Provider
CP NAP NSP
+-----+ +------+ +------+ +--------+
|Hosts|--|Router| +--+ BRAS +---+ Edge | ISP
+-----+ +--+---+ | | | | Router +==> Network
| | +------+ +--------+
+--+---+ |
| DSL +-+ |
|Modem | | |
+------+ | +-----+ |
+--+ | |
+------+ |DSLAM+--+
+-----+ | DSL | +--+ |
|Hosts|--+Modem +-+ +-----+
+-----+ +--+---+
Figure 6.1
図6.1
There are three main design approaches to providing IPv4 connectivity over a DSL infrastructure:
DSLインフラストラクチャを介してIPv4接続を提供するための3つの主要な設計アプローチがあります。
1. Point-to-Point Model: Each subscriber connects to the DSLAM over a twisted pair and is provided with a unique PVC that links it to the service provider. The PVCs can be terminated at the BRAS or at the Edge Router. This type of design is not very scalable if the PVCs are not terminated as close as possible to the DSLAM (at the BRAS). In this case, a large number of Layer 2 circuits has to be maintained over a significant portion of the network. The Layer 2 domains can be terminated at the ER in three ways:
1. ポイントツーポイントモデル：各サブスクライバーは、ねじれたペアを介してDSLAMに接続し、それをサービスプロバイダーにリンクする一意のPVCが提供されます。PVCは、ブラジャーまたはエッジルーターで終了できます。このタイプの設計は、PVCがDSLAM（BRAで）に可能な限り近づいていない場合、あまりスケーラブルではありません。この場合、ネットワークのかなりの部分で多数のレイヤー2回路を維持する必要があります。レイヤー2ドメインは、3つの方法でERで終了できます。
A. In a common bridge group with a virtual interface that routes traffic out.
A.トラフィックをルーティングする仮想インターフェイスを備えた一般的なブリッジグループで。
B. By enabling a Routed Bridged Encapsulation feature, all users could be part of the same subnet. This is the most common deployment approach of IPv4 over DSL but it might not be the best choice in IPv6 where address availability is not an issue.
B.ルーティングされたブリッジ付きカプセル化機能を有効にすることにより、すべてのユーザーが同じサブネットの一部になる可能性があります。これは、DSLを介したIPv4の最も一般的な展開アプローチですが、アドレスの可用性が問題ではないIPv6で最良の選択ではないかもしれません。
C. By terminating the PVC at Layer 3, each PVC has its own prefix. This is the approach that seems more suitable for IPv6 and is presented in Section 6.2.1.
C.レイヤー3でPVCを終了することにより、各PVCには独自のプレフィックスがあります。これは、IPv6により適していると思われるアプローチであり、セクション6.2.1に示されています。
None of these ways requires that the CPE (DSL modem) be upgraded.
これらの方法では、CPE（DSLモデム）をアップグレードする必要はありません。
2. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened between each subscriber and the BRAS. The BRAS terminates the PPP sessions and provides Layer 3 connectivity between the subscriber and the ISP. This model is presented in Section 6.2.2.
2. PPP終端集約（PTA）モデル：PPPセッションは、各サブスクライバーとBRAの間で開かれます。ブラジャーはPPPセッションを終了し、サブスクライバーとISPの間のレイヤー3接続を提供します。このモデルは、セクション6.2.2に示されています。
3. Layer 2 Tunneling Protocol (L2TP) Access Aggregation (LAA) Model: PPP sessions are opened between each subscriber and the ISP Edge Router. The BRAS tunnels the subscriber PPP sessions to the ISP by encapsulating them into L2TPv2 [RFC2661] tunnels. This model is presented in Section 6.2.3.
3. レイヤー2トンネルプロトコル（L2TP）アクセス集約（LAA）モデル：各サブスクライバーとISPエッジルーターの間にPPPセッションが開かれます。ブラジャーは、それらをL2TPV2 [RFC2661]トンネルにカプセル化することにより、サブスクライバーPPPセッションをISPにトンネルします。このモデルは、セクション6.2.3に示されています。
In aggregation models, the BRAS terminates the subscriber PVCs and aggregates their connections before providing access to the ISP.
集約モデルでは、ブラジャーはサブスクライバーPVCを終了し、ISPへのアクセスを提供する前に接続を集約します。
In order to maintain the deployment concepts and business models proven and used with existing revenue generating IPv4 services, the IPv6 deployment will match the IPv4 one. This approach is presented in Sections 6.2.1 - 6.2.3 that describe current IPv4 over DSL broadband access deployments. Under certain circumstances where new service types or service needs justify it, IPv4 and IPv6 network logical architectures could be different as described in Section 6.2.4.
展開の概念とビジネスモデルを維持するために、既存の収益を生成するIPv4サービスで使用され、IPv6の展開がIPv4の展開と一致します。このアプローチは、DSLブロードバンドアクセスの展開を介した現在のIPv4を説明するセクション6.2.1-6.2.3に示されています。新しいサービスタイプまたはサービスが必要な特定の状況では、IPv4およびIPv6ネットワークの論理アーキテクチャは、セクション6.2.4で説明されているように異なる可能性があります。
In this scenario, the Ethernet frames from the Host or the Customer Premise Router are bridged over the PVC assigned to the subscriber.
このシナリオでは、ホストまたは顧客の前提ルーターからのイーサネットフレームが、サブスクライバーに割り当てられたPVCに架橋されています。
Figure 6.2.1 describes the protocol architecture of this model.
図6.2.1は、このモデルのプロトコルアーキテクチャを説明しています。
Customer Premise NAP NSP
|-------------------------| |---------------| |------------------|
+-----+ +-------+ +-----+ +--------+ +----------+
|Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP
+-----+ +-------+ |Modem| +--------+ | Router +=>Network
+-----+ +----------+
|----------------------------|
ATM
Figure 6.2.1
図6.2.1
In this scenario, the DSL modem and the entire NAP is Layer 3 unaware, so no changes are needed to support IPv6. The following devices have to be upgraded to dual stack: Host, Customer Router (if present), and Edge Router.
このシナリオでは、DSLモデムとNAP全体がレイヤー3を認識していないため、IPv6をサポートするために変更は必要ありません。次のデバイスは、ホスト、顧客ルーター（存在する場合）、およびエッジルーターのデュアルスタックにアップグレードする必要があります。
The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop.
ホストまたは顧客ルーターは、次のホップ3としてエッジルーターを持っています。
If there is no Customer Router, all the hosts on the subscriber site belong to the same /64 subnet that is statically configured on the Edge Router for that subscriber PVC. The hosts can use stateless auto-configuration or stateful DHCPv6-based configuration to acquire an address via the Edge Router.
顧客ルーターがない場合、サブスクライバーサイトのすべてのホストは、そのサブスクライバーPVCのエッジルーターで静的に構成された同じ /64サブネットに属します。ホストは、Stateless Auto ConfigurationまたはStateful DHCPV6ベースの構成を使用して、Edgeルーターを介してアドレスを取得できます。
However, as manual configuration for each customer is a provisioning challenge, implementers are encouraged to develop mechanism(s) that automatically map the PVC (or some other customer-specific information) to an IPv6 subnet prefix, and advertise the customer-specific prefix to all the customers with minimal configuration.
ただし、各顧客の手動構成はプロビジョニングチャレンジであるため、実装者は、PVC（または他の顧客固有の情報）をIPv6サブネットプレフィックスに自動的にマッピングするメカニズムを開発することをお勧めし、顧客固有のプレフィックスを宣伝します。最小限の構成ですべての顧客。
If a Customer Router is present:
顧客ルーターが存在する場合：
A. It is statically configured with an address on the /64 subnet between itself and the Edge Router, and with /64 prefixes on the interfaces connecting the hosts on the customer site. This is not a desired provisioning method being expensive and difficult to manage.
A.それは、それ自体とエッジルーターの間の /64サブネットのアドレスと、顧客サイトのホストを接続するインターフェイス上の /64プレフィックスで静的に構成されています。これは、高価で管理が困難な望ましいプロビジョニング方法ではありません。
B. It can use its link-local address to communicate with the ER. It can also dynamically acquire, through stateless auto-configuration, the prefix for the link between itself and the ER. The later option allows it to contact a remote DHCPv6 server, if needed. This step is followed by a request via DHCP-PD for a prefix shorter than /64 that, in turn, is divided in /64s and assigned to its downstream interfaces.
B.リンクローカルアドレスを使用してERと通信できます。また、ステートレスの自動構成を通じて、それ自体とERの間のリンクのプレフィックスを動的に取得することができます。後のオプションを使用すると、必要に応じてリモートDHCPV6サーバーに連絡できます。このステップの後に、 /64より短い接頭辞のDHCP-PDを介したリクエストが続き、次に /64Sに分割され、その下流のインターフェイスに割り当てられます。
The Edge Router has a /64 prefix configured for each subscriber PVC. Each PVC should be enabled to relay DHCPv6 requests from the subscribers to DHCPv6 servers in the ISP network. The PVCs providing access for subscribers that use DHCP-PD as well, have to be enabled to support the feature. The uplink to the ISP network is configured with a /64 prefix as well.
エッジルーターには、各サブスクライバーPVCに対して構成されたA /64プレフィックスがあります。各PVCは、サブスクライバーからISPネットワークのDHCPV6サーバーにDHCPV6要求を中継することを有効にする必要があります。DHCP-PDを使用する加入者にアクセスを提供するPVCは、機能をサポートするために有効にする必要があります。ISPネットワークへのアップリンクは、A /64プレフィックスでも構成されています。
The prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows as much summarization as possible at the Edge Router.
サブスクライバーリンクに使用されるプレフィックスとDHCP-PDを介して委任されたプレフィックスは、エッジルーターでできるだけ多くの要約を許可する方法で計画する必要があります。
Other information of interest to the host, such as DNS, is provided through stateful DHCPv6 [RFC3315] and stateless DHCPv6 [RFC3736].
DNSなどのホストにとって関心のある他の情報は、Stateful DHCPV6 [RFC3315]およびStateless DHCPV6 [RFC3736]を介して提供されます。
The CPE devices are configured with a default route that points to the Edge Router. No routing protocols are needed on these devices, which generally have limited resources.
CPEデバイスは、エッジルーターを指すデフォルトルートで構成されています。これらのデバイスでは、通常はリソースが限られているルーティングプロトコルは必要ありません。
The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. The connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the Edge Router. For this reason, the static routes must also be redistributed. Prefix summarization should be done at the Edge Router.
エッジルーターは、NSP：OSPFV3またはIS-ISで使用されるIPv6 IGPを実行します。接続されたプレフィックスを再配布する必要があります。DHCP-PDを使用する場合、委任されたすべてのプレフィックスを使用して、静的ルートがエッジルーターによってインストールされます。このため、静的ルートも再配布する必要があります。プレフィックスの要約は、エッジルーターで行う必要があります。
The PTA architecture relies on PPP-based protocols (PPPoA [RFC2364] and PPPoE [RFC2516]). The PPP sessions are initiated by Customer Premise Equipment and are terminated at the BRAS. The BRAS authorizes the session, authenticates the subscriber, and provides an IP address on behalf of the ISP. The BRAS then does Layer 3 routing of the subscriber traffic to the NSP Edge Router.
PTAアーキテクチャは、PPPベースのプロトコル（PPPOA [RFC2364]およびPPPOE [RFC2516]）に依存しています。PPPセッションは顧客の前提装備によって開始され、ブラジャーで終了します。ブラジャーはセッションを承認し、サブスクライバーを認証し、ISPに代わってIPアドレスを提供します。BRAは、NSPエッジルーターへのサブスクライバートラフィックの3ルーティングをレイヤー3ルーティングします。
When the NSP is also the NAP, the BRAS and NSP Edge Router could be the same piece of equipment and provide the above mentioned functionality.
NSPもNAPである場合、BRASおよびNSPエッジルーターは同じ機器であり、上記の機能を提供する可能性があります。
There are two types of PPP encapsulations that can be leveraged with this model:
このモデルで活用できるPPPカプセルには2つのタイプがあります。
A. Connection using PPPoA
A. PPPOAを使用した接続
Customer Premise NAP NSP
|--------------------| |----------------------| |----------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
+-----+ +-------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
|--------------------------| +-----------+
PPP
Figure 6.2.2.1
図6.2.2.1
The PPP sessions are initiated by the Customer Premise Equipment. The BRAS authenticates the subscriber against a local or a remote database. Once the session is established, the BRAS provides an address and maybe a DNS server to the user; this information is acquired from the subscriber profile or from a DHCP server.
PPPセッションは、顧客の前提装備によって開始されます。BRAは、ローカルまたはリモートデータベースに対してサブスクライバーを認証します。セッションが確立されると、BRAはユーザーにアドレスとDNSサーバーを提供します。この情報は、サブスクライバープロファイルまたはDHCPサーバーから取得されます。
This solution scales better then the Point-to-Point, but since there is only one PPP session per ATM PVC, the subscriber can choose a single ISP service at a time.
このソリューションはポイントツーポイントよりも優れていますが、ATM PVCごとにPPPセッションが1つしかないため、サブスクライバーは一度に単一のISPサービスを選択できます。
B. Connection using PPPoE
B. pppoeを使用した接続
Customer Premise NAP NSP
|--------------------------| |-------------------| |---------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
|
+-----+ +-------+ +--------+ +-----+----+ +-----------+
|Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +----------+ | Router +=>O
| | R
|--------------------------------| +-----------+ E
PPP
Figure 6.2.2.2
図6.2.2.2
The operation of PPPoE is similar to PPPoA with the exception that with PPPoE multiple sessions can be supported over the same PVC, thus allowing the subscriber to connect to multiple services at the same time. The hosts can initiate the PPPoE sessions as well. It is important to remember that the PPPoE encapsulation reduces the IP MTU available for the customer traffic due to additional headers.
PPPOEの動作は、PPPOEで複数のセッションを同じPVCでサポートできるため、サブスクライバーが複数のサービスに同時に接続できることを除いて、PPPOAに似ています。ホストはPPPOEセッションも開始できます。PPPOEカプセル化により、追加のヘッダーが原因で顧客トラフィックが利用可能なIP MTUが減少することを覚えておくことが重要です。
The network design and operation of the PTA model is the same, regardless of the PPP encapsulation type used.
PTAモデルのネットワーク設計と動作は、使用されるPPPカプセル化タイプに関係なく同じです。
In this scenario the BRAS is Layer 3 aware and it has to be upgraded to support IPv6. Since the BRAS terminates the PPP sessions it has to support the implementation of these PPP protocols with IPv6. The following devices have to be upgraded to dual stack: Host, Customer Router (if present), BRAS, and Edge Router.
このシナリオでは、ブラジャーはレイヤー3を認識しており、IPv6をサポートするためにアップグレードする必要があります。ブラジャーはPPPセッションを終了するため、これらのPPPプロトコルのIPv6を使用した実装をサポートする必要があります。次のデバイスは、ホスト、カスタマールーター（存在する場合）、ブラジャー、およびエッジルーターのデュアルスタックにアップグレードする必要があります。
The BRAS terminates the PPP sessions and provides the subscriber with an IPv6 address from the defined pool for that profile. The subscriber profile for authorization and authentication can be located on the BRAS or on an Authentication, Authorization, and Accounting (AAA) server. The Hosts or the Customer Routers have the BRAS as their Layer 3 next hop.
BRASは、PPPセッションを終了し、そのプロファイルの定義されたプールのIPv6アドレスをサブスクライバーに提供します。承認と認証のためのサブスクライバープロファイルは、ブラジャーまたは認証、承認、および会計（AAA）サーバーに配置できます。ホストまたは顧客ルーターは、次のホップ3としてブラジャーを持っています。
The PPP session can be initiated by a host or by a Customer Router. In the latter case, once the session is established with the BRAS and an address is negotiated for the uplink to the BRAS, DHCP-PD can be used to acquire prefixes for the Customer Router other interfaces.
PPPセッションは、ホストまたは顧客ルーターによって開始できます。後者の場合、セッションがブラジャーで確立され、ブラジャーのアップリンクのために住所がネゴシエートされると、DHCP-PDを使用して、顧客ルーターの他のインターフェイスのプレフィックスを取得できます。
The BRAS has to be enabled to support DHCP-PD and to relay the DHCPv6 requests of the hosts on the subscriber sites.
BRAは、DHCP-PDをサポートし、サブスクライバーサイトのホストのDHCPV6要求を中継するために有効にする必要があります。
The BRAS has /64 prefixes configured on the link to the Edge router. The Edge Router links are also configured with /64 prefixes to provide connectivity to the rest of the ISP network.
BRASには、エッジルーターへのリンクで構成された /64のプレフィックスがあります。Edgeルーターリンクは、 /64プレフィックスで構成されており、ISPネットワークの残りの部分への接続を提供します。
The prefixes used for subscribers and the ones delegated via DHCP-PD should be planned in a manner that allows maximum summarization at the BRAS.
サブスクライバーに使用されるプレフィックスとDHCP-PDを介して委任されたプレフィックスは、BRAでの最大の要約を可能にする方法で計画する必要があります。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
DNSなどのホストにとって関心のある他の情報は、Stateful [RFC3315]およびStateless [RFC3736] DHCPV6を通じて提供されます。
The CPE devices are configured with a default route that points to the BRAS router. No routing protocols are needed on these devices, which generally have limited resources.
CPEデバイスは、BRASルーターを指すデフォルトルートで構成されています。これらのデバイスでは、通常はリソースが限られているルーティングプロトコルは必要ありません。
The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the addresses assigned to the PPP sessions are represented as connected host routes, connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the Edge Router. For this reason, the static routes must also be redistributed. Prefix summarization should be done at the BRAS.
ブラジャーは、EdgeルーターのIGPを実行します：OSPFV3またはIS-IS。PPPセッションに割り当てられたアドレスは、接続されたホストルートとして表されるため、接続されたプレフィックスを再配布する必要があります。DHCP-PDを使用する場合、委任されたすべてのプレフィックスを使用して、静的ルートがエッジルーターによってインストールされます。このため、静的ルートも再配布する必要があります。接頭辞の要約はブラジャーで行う必要があります。
The Edge Router is running the IGP used in the ISP network: OSPFv3 or IS-IS.
Edgeルーターは、ISPネットワークで使用されているIGPを実行しています：OSPFV3またはIS-IS。
A separation between the routing domains of the ISP and the Access Provider is recommended if they are managed independently. Controlled redistribution will be needed between the Access Provider IGP and the ISP IGP.
ISPのルーティングドメインとアクセスプロバイダーが独立して管理されている場合は、アクセスプロバイダーの間の分離をお勧めします。アクセスプロバイダーIGPとISP IGPの間で、制御された再分配が必要になります。
In the LAA model, the BRAS forwards the CPE initiated session to the ISP over an L2TPv2 tunnel established between the BRAS and the Edge Router. In this case, the authentication, authorization, and subscriber configuration are performed by the ISP itself. There are two types of PPP encapsulations that can be leveraged with this model: A. Connection via PPPoA
LAAモデルでは、BRASは、BRAとエッジルーターの間に確立されたL2TPV2トンネルを介して、CPE開始セッションをISPに転送します。この場合、認証、承認、およびサブスクライバー構成は、ISP自体によって実行されます。このモデルで活用できるPPPカプセルには2つのタイプがあります。A。PPPOA経由の接続
Customer Premise NAP NSP
|--------------------| |----------------------| |----------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
|----------------------------------------|
PPP
|------------|
L2TPv2
Figure 6.2.3.1
図6.2.3.1
B. Connection via PPPoE
B. pppoe経由の接続
Customer Premise NAP NSP
|--------------------------| |--------------------| |---------------|
+-----------+
| AAA |
+------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +----+------+
|Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +----------+ | Router +=>O
| | R
+-----------+ E
|-----------------------------------------------|
PPP
|--------------|
L2TPv2
Figure 6.2.3.2
図6.2.3.2
The network design and operation of the PTA model is the same, regardless of the PPP encapsulation type used.
PTAモデルのネットワーク設計と動作は、使用されるPPPカプセル化タイプに関係なく同じです。
In this scenario, the BRAS is forwarding the PPP sessions initiated by the subscriber over the L2TPv2 tunnel established to the L2TP Network Server (LNS), the aggregation point in the ISP network. The L2TPv2 tunnel between the L2TP Access Concentrator (LAC) and LNS can run over IPv6 or IPv4. These capabilities have to be supported on the BRAS. The following devices have to be upgraded to dual stack: Host, Customer Router, and Edge Router. If the tunnel is set up over IPv6, then the BRAS must be upgraded to dual stack.
このシナリオでは、ブラジャーは、ISPネットワークの集約点であるL2TPネットワークサーバー（LNS）に確立されたL2TPV2トンネルを介してサブスクライバーによって開始されたPPPセッションを転送しています。L2TPアクセス濃縮器（LAC）とLNSの間のL2TPV2トンネルは、IPv6またはIPv4を介して実行できます。これらの機能はブラジャーでサポートする必要があります。次のデバイスは、ホスト、顧客ルーター、およびエッジルーターのデュアルスタックにアップグレードする必要があります。トンネルがIPv6を介してセットアップされている場合、ブラジャーをデュアルスタックにアップグレードする必要があります。
The Edge Router terminates the PPP sessions and provides the subscriber with an IPv6 address from the defined pool for that profile. The subscriber profile for authorization and authentication can be located on the Edge Router or on an AAA server. The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop.
EdgeルーターはPPPセッションを終了し、そのプロファイルの定義されたプールのIPv6アドレスをサブスクライバーに提供します。承認と認証のためのサブスクライバープロファイルは、エッジルーターまたはAAAサーバーに配置できます。ホストまたは顧客ルーターは、次のホップ3としてエッジルーターを持っています。
The PPP session can be initiated by a host or by a Customer Router. In the latter case, once the session is established with the Edge Router, DHCP-PD can be used to acquire prefixes for the Customer Router interfaces. The Edge Router has to be enabled to support DHCP-PD and to relay the DHCPv6 requests generated by the hosts on the subscriber sites.
PPPセッションは、ホストまたは顧客ルーターによって開始できます。後者の場合、エッジルーターでセッションが確立されると、DHCP-PDを使用して、顧客ルーターインターフェイスのプレフィックスを取得できます。Edgeルーターは、DHCP-PDをサポートし、サブスクライバーサイトのホストが生成したDHCPV6リクエストを中継するために有効にする必要があります。
The BRAS has a /64 prefix configured on the link to the Edge Router. The Edge Router links are also configured with /64 prefixes to provide connectivity to the rest of the ISP network. Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
ブラジャーには、エッジルーターへのリンクで構成された /64プレフィックスがあります。Edgeルーターリンクは、 /64プレフィックスで構成されており、ISPネットワークの残りの部分への接続を提供します。DNSなどのホストにとって関心のある他の情報は、Stateful [RFC3315]およびStateless [RFC3736] DHCPV6を通じて提供されます。
It is important to note here a significant difference between this deployment for IPv6 versus IPv4. In the case of IPv4, the customer router or CPE can end up on any Edge Router (acting as LNS), where the assumption is that there are at least two of them for redundancy purposes. Once authenticated, the customer will be given an address from the IP pool of the ER (LNS) it connected to. This allows the ERs (LNSs) to aggregate the addresses handed out to the customers. In the case of IPv6, an important constraint that likely will be enforced is that the customer should keep its own address, regardless of the ER (LNS) it connects to. This could significantly reduce the prefix aggregation capabilities of the ER (LNS). This is different than the current IPv4 deployment where addressing is dynamic in nature, and the same user can get different addresses depending on the LNS it ends up connecting to.
ここでは、IPv6とIPv4のこの展開の間に大きな違いに注意することが重要です。IPv4の場合、顧客ルーターまたはCPEは任意のエッジルーター（LNSとして機能する）で終わる可能性があります。ここでは、冗長性のために少なくとも2つあるという仮定があります。認証されると、顧客に接続されたER（LNS）のIPプールからアドレスが与えられます。これにより、ERS（LNSS）が顧客に配られたアドレスを集約することができます。IPv6の場合、施行される可能性が高い重要な制約は、顧客が接続するER（LNS）に関係なく、独自の住所を保持する必要があることです。これにより、ER（LNS）のプレフィックス集約機能が大幅に削減される可能性があります。これは、アドレス指定が本質的に動的であり、同じユーザーが接続するLNSに応じて異なるアドレスを取得できる現在のIPv4展開とは異なります。
One possible solution is to ensure that a given BRAS will always connect to the same ER (LNS) unless that LNS is down. This means that customers from a given prefix range will always be connected to the same ER (primary, if up, or secondary, if not). Each ER (LNS) can carry summary statements in their routing protocol configuration for the prefixes for which they are the primary ER (LNS), as well as for the ones for which they are the secondary. This way the prefixes will be summarized any time they become "active" on the ER (LNS).
考えられる解決策の1つは、特定のブラジャーが常に同じER（LNS）に接続されていることを確認することです。つまり、特定のプレフィックス範囲の顧客は、常に同じER（プライマリ、アップ、またはセカンダリ、そうでない場合）に接続されることを意味します。各ER（LNS）は、プライマリER（LNS）であるプレフィックスとセカンダリであるプレフィックスのルーティングプロトコル構成に概要ステートメントを掲載できます。このようにして、プレフィックスは、ER（LNS）で「アクティブ」になるたびに要約されます。
The CPE devices are configured with a default route that points to the Edge Router that terminates the PPP sessions. No routing protocols are needed on these devices, which generally have limited resources.
CPEデバイスは、PPPセッションを終了するエッジルーターを指すデフォルトルートで構成されています。これらのデバイスでは、通常はリソースが限られているルーティングプロトコルは必要ありません。
The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. Different processes should be used if the NAP and the NSP are managed by different organizations. In this case, controlled redistribution should be enabled between the two domains.
BRASは、IPv6 IGPをエッジルーターに実行します：OSPFV3またはIS-IS。NAPとNSPがさまざまな組織によって管理されている場合は、さまざまなプロセスを使用する必要があります。この場合、2つのドメイン間で制御された再分配を有効にする必要があります。
The Edge Router is running the IPv6 IGP used in the ISP network: OSPFv3 or IS-IS.
エッジルーターは、ISPネットワークで使用されるIPv6 IGPを実行しています：OSPFV3またはIS-IS。
It was recommended throughout this section that the IPv6 service implementation should map the existing IPv4 one. This approach simplifies manageability and minimizes training needed for personnel operating the network. In certain circumstances such mapping is not feasible. This typically becomes the case when a Service Provider plans to expand its service offering with the new IPv6 deployed infrastructure. If this new service is not well supported in a network design such as the one used for IPv4, then a different design might be used for IPv6.
このセクション全体で、IPv6サービスの実装が既存のIPv4 Oneをマッピングすることをお勧めします。このアプローチは、管理性を簡素化し、ネットワークを操作する担当者に必要なトレーニングを最小限に抑えます。特定の状況では、そのようなマッピングは実行不可能です。これは通常、サービスプロバイダーが新しいIPv6デプロイインフラストラクチャでサービス提供を拡大することを計画している場合に当てはまります。この新しいサービスがIPv4に使用されるものなどのネットワーク設計で十分にサポートされていない場合、IPv6には別の設計が使用される場合があります。
An example of such circumstances is that of a provider using an LAA design for its IPv4 services. In this case all the PPP sessions are bundled and tunneled across the entire NAP infrastructure which is made of multiple BRAS routers, aggregation routers etc. The end point of these tunnels is the ISP Edge Router. If the provider decides to offer multicast services over such a design, it will face the problem of NAP resources being over utilized. The multicast traffic can be replicated only at the end of the tunnels by the Edge Router and the copies for all the subscribers are carried over the entire NAP.
このような状況の例は、IPv4サービスにLAA設計を使用するプロバイダーの例です。この場合、すべてのPPPセッションは、複数のブラスルーター、集約ルーターなどで作られたNAPインフラストラクチャ全体にバンドルされ、トンネル化されます。これらのトンネルのエンドポイントはISPエッジルーターです。プロバイダーがこのようなデザインでマルチキャストサービスを提供することを決定した場合、NAPリソースが過剰に利用されるという問題に直面します。マルチキャストトラフィックは、エッジルーターによってトンネルの端でのみ複製でき、すべてのサブスクライバーのコピーは昼寝全体に運ばれます。
A Modified Point-to-Point (as described in Section 6.2.4.2) or PTA model is more suitable to support multicast services because the packet replication can be done closer to the destination at the BRAS. Such topology saves NAP resources.
パケットレプリケーションはブラスの宛先に近づくことができるため、修正されたポイントツーポイント（セクション6.2.4.2で説明）またはPTAモデルは、マルチキャストサービスをサポートするのに適しています。このようなトポロジは、NAPリソースを節約します。
In this sense, IPv6 deployment can be viewed as an opportunity to build an infrastructure that might better support the expansion of services. In this case, an SP using the LAA design for its IPv4 services might choose a modified Point-to-Point or PTA design for IPv6.
この意味で、IPv6の展開は、サービスの拡大をよりよくサポートする可能性のあるインフラストラクチャを構築する機会と見なすことができます。この場合、IPv4サービスにLAA設計を使用するSPは、IPv6の変更されたポイントツーポイントまたはPTA設計を選択する場合があります。
The coexistence of the two PPP-based models, PTA and LAA, is relatively straightforward. The PPP sessions are terminated on different network devices for the IPv4 and IPv6 services. The PPP sessions for the existing IPv4 service deployed in an LAA model are terminated on the Edge Router. The PPP sessions for the new IPv6 service deployed in a PTA model are terminated on the BRAS.
2つのPPPベースのモデルであるPTAとLAAの共存は、比較的簡単です。PPPセッションは、IPv4およびIPv6サービスのさまざまなネットワークデバイスで終了します。LAAモデルに展開されている既存のIPv4サービスのPPPセッションは、エッジルーターで終了します。PTAモデルに展開されている新しいIPv6サービスのPPPセッションは、BRAで終了します。
The logical design for IPv6 and IPv4 in this hybrid model is presented in Figure 6.2.4.1.
このハイブリッドモデルのIPv6とIPv4の論理設計を図6.2.4.1に示します。
IPv6 |--------------------------|
PPP +-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
Figure 6.2.4.1
図6.2.4.1
In this particular scenario the Point-to-Point model used for the IPv6 service is a modified version of the model described in section 6.2.1.
この特定のシナリオでは、IPv6サービスに使用されるポイントツーポイントモデルは、セクション6.2.1で説明されているモデルの修正バージョンです。
For the IPv4 service in the LAA model, the PVCs are terminated on the BRAS and PPP sessions are terminated on the Edge Router (LNS). For IPv6 service in the Point-to-Point model, the PVCs are terminated at the Edge Router as described in Section 6.2.1. In this hybrid model, the Point-to-Point link could be terminated on the BRAS, a NAP-owned device. The IPv6 traffic is then routed through the NAP network to the NSP. In order to have this hybrid model, the BRAS has to be upgraded to a dual-stack router. The functionalities of the Edge Router, as described in Section 6.2.1, are now implemented on the BRAS.
LAAモデルのIPv4サービスの場合、PVCはBRAで終了し、PPPセッションはEdgeルーター（LNS）で終了します。ポイントツーポイントモデルのIPv6サービスの場合、セクション6.2.1で説明されているように、PVCはエッジルーターで終了します。このハイブリッドモデルでは、ポイントツーポイントリンクは、昼寝型デバイスであるBRAで終了できます。IPv6トラフィックは、NAPネットワークを介してNSPにルーティングされます。このハイブリッドモデルを使用するには、ブラジャーをデュアルスタックルーターにアップグレードする必要があります。セクション6.2.1で説明されているように、エッジルーターの機能は現在ブラジャーに実装されています。
The other aspect of this deployment model is the fact that the BRAS has to be capable of distinguishing between the IPv4 PPP traffic that has to be bridged across the L2TPv2 tunnel and the IPv6 packets that have to be routed to the NSP. The IPv6 Routing and Bridging Encapsulation (RBE) has to be enabled on all interfaces with PVCs supporting both IPv4 and IPv6 services in this hybrid design.
この展開モデルのもう1つの側面は、BRASがL2TPV2トンネルを介して橋渡しする必要があるIPv4 PPPトラフィックと、NSPにルーティングする必要があるIPv6パケットを区別できる必要があるという事実です。このハイブリッド設計では、IPv4サービスとIPv6サービスの両方をサポートするPVCを使用して、すべてのインターフェイスでIPv6ルーティングとブリッジングカプセル化（RBE）を有効にする必要があります。
The logical design for IPv6 and IPv4 in this hybrid model is presented in Figure 6.2.4.2.
このハイブリッドモデルのIPv6とIPv4の論理設計を図6.2.4.2に示します。
IPv6 |----------------|
ATM +-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
Figure 6.2.4.2
図6.2.4.2
The deployment of IPv6 multicast services relies on MLD, identical to IGMP in IPv4 and on PIM for routing. ASM (Any Source Multicast) and SSM (Single Source Multicast) service models operate almost the same as in IPv4. Both have the same benefits and disadvantages as in IPv4. Nevertheless, the larger address space and the scoped address architecture provide major benefits for multicast IPv6. Through RFC 3306, the large address space provides the means to assign global multicast group addresses to organizations or users that were assigned unicast prefixes. It is a significant improvement with respect to the IPv4 GLOP mechanism [RFC3180].
IPv6マルチキャストサービスの展開は、MLDに依存しており、IPv4のIGMPとルーティングのPIMに依存しています。ASM（任意のソースマルチキャスト）およびSSM（シングルソースマルチキャスト）サービスモデルは、IPv4とほぼ同じ動作します。どちらもIPv4と同じ利点と短所を持っています。それにもかかわらず、より大きなアドレス空間とスコープされたアドレスアーキテクチャは、マルチキャストIPv6に大きな利点を提供します。RFC 3306を通じて、大規模なアドレススペースは、ユニキャストプレフィックスが割り当てられた組織またはユーザーにグローバルマルチキャストグループアドレスを割り当てる手段を提供します。これは、IPv4 GLOPメカニズム[RFC3180]に関して大幅に改善されています。
This facilitates the deployment of multicast services. The discussion of this section applies to all the multicast sections in the document.
これにより、マルチキャストサービスの展開が容易になります。このセクションの説明は、ドキュメント内のすべてのマルチキャストセクションに適用されます。
Any Source Multicast (ASM) is useful for Service Providers that intend to support the forwarding of multicast traffic of their customers. It is based on the Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol and it is more complex to manage because of the use of Rendezvous Points (RPs). With IPv6, static RP and Bootstrap Router [BSR] can be used for RP-to-group mapping similar to IPv4. Additionally, the larger IPv6 address space allows for building up of group addresses that incorporate the address of the RP. This RP-to-group mapping mechanism is called Embedded RP and is specific to IPv6.
ソースマルチキャスト（ASM）は、顧客のマルチキャストトラフィックの転送をサポートする予定のサービスプロバイダーに役立ちます。これは、プロトコル独立したマルチキャスト - スパースモード（PIM -SM）プロトコルに基づいており、Rendezvousポイント（RPS）の使用により管理する方が複雑です。IPv6を使用すると、静的RPおよびブートストラップルーター[BSR]を使用して、IPv4と同様のRPからグループへのマッピングに使用できます。さらに、より大きなIPv6アドレス空間を使用すると、RPのアドレスを組み込んだグループアドレスを構築できます。このRPからグループ間マッピングメカニズムは、埋め込みRPと呼ばれ、IPv6に固有です。
In inter-domain deployments, Multicast Source Discovery Protocol (MSDP) [RFC3618] is an important element of IPv4 PIM-SM deployments. MSDP is meant to be a solution for the exchange of source registration information between RPs in different domains. This solution was intended to be temporary. This is one of the reasons why it was decided not to implement MSDP in IPv6 [IPv6-Multicast].
ドメイン間展開では、マルチキャストソースディスカバリープロトコル（MSDP）[RFC3618]は、IPv4 PIM-SM展開の重要な要素です。MSDPは、異なるドメインのRP間のソース登録情報を交換するためのソリューションとなることを目的としています。このソリューションは一時的なものになることを目的としていました。これが、IPv6 [IPv6-Multicast]にMSDPを実装しないことが決定された理由の1つです。
For multicast reachability across domains, Embedded RP can be used. As Embedded RP provides roughly the same capabilities as MSDP, but in a slightly different way, the best management practices for ASM multicast with embedded RP still remain to be developed.
ドメイン全体でマルチキャストの到達可能性には、埋め込まれたRPを使用できます。埋め込まれたRPはMSDPとほぼ同じ機能を提供しますが、わずかに異なる方法で、埋め込まれたRPを備えたASMマルチキャストの最良の管理慣行はまだ開発されていません。
Based on PIM-SSM, the Source-Specific Multicast deployments do not need an RP or related protocols (such as BSR or MSDP), but rely on the listeners to know the source of the multicast traffic they plan to receive. The lack of RP makes SSM not only simpler to operate, but also robust; it is not impacted by RP failures or inter-domain constraints. It also has a higher level of security (no RP to be targeted by attacks). For more discussions on the topic of IPv6 multicast, see [IPv6-Multicast].
PIM-SSMに基づいて、ソース固有のマルチキャスト展開には、RPまたは関連するプロトコル（BSRやMSDPなど）は必要ありませんが、リスナーに依存して、受け取る予定のマルチキャストトラフィックのソースを知ることができます。RPがないため、SSMは操作がより簡単になるだけでなく、堅牢性をもたらします。RP障害やドメイン間の制約の影響はありません。また、より高いレベルのセキュリティを持っています（攻撃によってターゲットにされるRPはありません）。IPv6マルチキャストのトピックに関する詳細については、[IPv6-Multicast]を参照してください。
The typical multicast service offered for residential and very small businesses is video/audio streaming, where the subscriber joins a multicast group and receives the content. This type of service model is well supported through PIM-SSM which is very simple and easy to manage. PIM-SSM has to be enabled throughout the SP network. MLDv2 is required for PIM-SSM support. Vendors can choose to implement features that allow routers to map MLDv1 group joins to predefined sources.
住宅および非常に中小企業向けに提供される典型的なマルチキャストサービスは、ビデオ/オーディオストリーミングであり、サブスクライバーがマルチキャストグループに参加してコンテンツを受け取ります。このタイプのサービスモデルは、非常にシンプルで管理しやすいPIM-SSMを通じてよくサポートされています。PIM-SSMは、SPネットワーク全体で有効にする必要があります。MLDV2は、PIM-SSMサポートに必要です。ベンダーは、ルーターが事前定義されたソースに結合するMLDV1グループをマッピングできるようにする機能を実装することを選択できます。
Subscribers might use a set-top box that is responsible for the control piece of the multicast service (does group joins/leaves). The subscriber hosts can also join desired multicast groups as long as they are enabled to support MLDv1 or MLDv2. If a customer premise router is used, then it has to be enabled to support MLDv1 and MLDv2 in order to process the requests of the hosts. It has to be enabled to support PIM-SSM in order to send PIM joins/leaves up to its Layer 3 next hop whether it is the BRAS or the Edge Router. When enabling this functionality on a CPR, its limited resources should be taken into consideration. Another option would be for the CPR to support MLD proxy routing.
加入者は、マルチキャストサービスのコントロールピースを担当するセットトップボックスを使用する場合があります（グループが結合/葉をつけます）。サブスクライバーホストは、MLDV1またはMLDV2をサポートできる限り、希望のマルチキャストグループに参加することもできます。顧客の前提ルーターを使用する場合、ホストのリクエストを処理するためにMLDV1とMLDV2をサポートするために有効にする必要があります。PIM-SSMをサポートして、ブラジャーであろうとエッジルーターであろうと、次のホップに層3に去る/去るために有効にする必要があります。CPRでこの機能を有効にする場合、限られたリソースを考慮する必要があります。別のオプションは、CPRがMLDプロキシルーティングをサポートすることです。
The router that is the Layer 3 next hop for the subscriber (BRAS in the PTA model or the Edge Router in the LAA and Point-to-Point model) has to be enabled to support MLDv1 and MLDv2 in order to process the requests coming from subscribers without CPRs. It has to be enabled for PIM-SSM in order to receive joins/leaves from customer routers and send joins/leaves to the next hop towards the multicast source (Edge Router or the NSP core).
レイヤー3である次のサブスクライバー（PTAモデルのBRAまたはLAAおよびポイントツーポイントモデルのエッジルーター）の次は、MLDV1とMLDV2をサポートするために有効にする必要があります。CPRSのない購読者。顧客ルーターから結合/葉を受け取り、マルチキャストソース（EdgeルーターまたはNSPコア）に向かって次のホップに結合/葉を送信するために、PIM-SSMを有効にする必要があります。
MLD authentication, authorization and accounting are usually configured on the Edge Router in order to enable the ISP to control the subscriber access of the service and do billing for the content provided. Alternative mechanisms that would support these functions should be investigated further.
MLD認証、承認、および会計は、通常、ISPがサービスのサブスクライバーアクセスを制御し、提供されたコンテンツの請求を行うことを可能にするために、Edgeルーターで構成されます。これらの機能をサポートする代替メカニズムをさらに調査する必要があります。
The QoS configuration is particularly relevant on the router that represents the Layer 3 next hop for the subscriber (BRAS in the PTA model or the Edge Router in the LAA and Point-to-Point model) in order to manage resources shared amongst multiple subscribers, possibly with various service level agreements.
QoS構成は、複数のサブスクライバーの間で共有されているリソースを管理するために、サブスクライバー（PTAモデルのBRAまたはLAAおよびポイントツーポイントモデル）のレイヤー3次のホップを表すルーターに特に関連しています。おそらくさまざまなサービスレベルの契約があります。
In the DSL infrastructure, it is expected that there is already a level of traffic policing and shaping implemented for IPv4 connectivity. This is implemented throughout the NAP and is beyond the scope of this document.
DSLインフラストラクチャでは、IPv4接続のために実装されているトラフィックポリシングと形成のレベルがすでにあることが予想されます。これは昼寝全体で実装され、このドキュメントの範囲を超えています。
On the BRAS or the Edge Router, the subscriber-facing interfaces have to be configured to police the inbound customer traffic and shape the traffic outbound to the customer based on the service level agreements (SLAs). Traffic classification and marking should also be done on the router closest (at Layer 3) to the subscriber in order to support the various types of customer traffic (data, voice, and video) and to optimally use the infrastructure resources. Each provider (NAP, NSP) could implement their own QoS policies and services so that reclassification and marking might be performed at the boundary between the NAP and the NSP, in order to make sure the traffic is properly handled by the ISP. The same IPv4 QoS concepts and methodologies should be applied with IPv6 as well.
ブラジャーまたはエッジルーターでは、サブスクライバー向けインターフェイスを設定する必要があります。インバウンド顧客のトラフィックを締結し、サービスレベル契約（SLA）に基づいて顧客にトラフィックを形作る必要があります。さまざまなタイプの顧客トラフィック（データ、音声、ビデオ）をサポートし、インフラストラクチャリソースを最適に使用するために、サブスクライバーに最も近いルーター（レイヤー3）でトラフィックの分類とマーキングを行う必要があります。各プロバイダー（NAP、NSP）は、ISPによってトラフィックが適切に処理されることを確認するために、NAPとNSPの境界で再分類とマーキングを実行できるように、独自のQOSポリシーとサービスを実装できます。同じIPv4 QoSの概念と方法論もIPv6に適用する必要があります。
It is important to note that when traffic is encrypted end-to-end, the traversed network devices will not have access to many of the packet fields used for classification purposes. In these cases, routers will most likely place the packets in the default classes. The QoS design should take into consideration this scenario and try to use mainly IP header fields for classification purposes.
トラフィックがエンドツーエンドで暗号化されている場合、トラバースされたネットワークデバイスは分類に使用されるパケットフィールドの多くにアクセスできないことに注意することが重要です。これらの場合、ルーターはおそらくパケットをデフォルトのクラスに配置します。QoS設計では、このシナリオを考慮し、分類目的で主にIPヘッダーフィールドを使用しようとする必要があります。
There are limited changes that have to be done for CPEs in order to enhance security. The privacy extensions for auto-configuration [RFC3041] should be used by the hosts. ISPs can track the prefixes it assigns to subscribers relatively easily. If, however, the ISPs are required by regulations to track their users at a /128 address level, the privacy extensions may be implemented in parallel with network management tools that could provide traceability of the hosts. IPv6 firewall functions should be enabled on the hosts or CPR, if present.
セキュリティを強化するためには、CPEに対して行う必要がある限られた変更があります。自動構成のためのプライバシー拡張[RFC3041]は、ホストが使用する必要があります。ISPSは、サブスクライバーに割り当てる接頭辞を比較的簡単に追跡できます。ただし、A /128アドレスレベルでユーザーを追跡するためにISPが規制で必要な場合、プライバシー拡張機能は、ホストのトレーサビリティを提供できるネットワーク管理ツールと並行して実装できます。IPv6ファイアウォール機能は、存在する場合はホストまたはCPRで有効にする必要があります。
The ISP provides security against attacks that come from its own subscribers but it could also implement security services that protect its subscribers from attacks sourced from the outside of its network. Such services do not apply at the access level of the network discussed here.
ISPは、独自の加入者から生じる攻撃に対するセキュリティを提供しますが、ネットワークの外側から供給された攻撃から加入者を保護するセキュリティサービスを実装することもできます。このようなサービスは、ここで説明するネットワークのアクセスレベルでは適用されません。
The device that is the Layer 3 next hop for the subscribers (BRAS or Edge Router) should protect the network and the other subscribers against attacks by one of the provider customers. For this reason, uRPF and ACLs should be used on all interfaces facing subscribers. Filtering should be implemented with regard for the operational requirements of IPv6 [IPv6-Security].
レイヤー3次のデバイスは、サブスクライバー（ブラジャーまたはエッジルーター）のためのホップに、プロバイダーの顧客のいずれかによる攻撃からネットワークと他のサブスクライバーを保護する必要があります。このため、URPFとACLは、サブスクライバーに直面しているすべてのインターフェイスで使用する必要があります。IPv6 [IPv6-Security]の運用要件に関して、フィルタリングを実装する必要があります。
The BRAS and the Edge Router should protect their processing resources against floods of valid customer control traffic such as: Router and Neighbor Solicitations, and MLD Requests. Rate limiting should be implemented on all subscriber-facing interfaces. The emphasis should be placed on multicast-type traffic, as it is most often used by the IPv6 control plane.
ブラジャーとエッジルーターは、ルーターや近隣の勧誘、MLDリクエストなど、有効な顧客制御トラフィックの洪水から処理リソースを保護する必要があります。レート制限は、すべての加入者向けインターフェイスに実装する必要があります。IPv6コントロールプレーンで最もよく使用されるため、マルチキャストタイプのトラフィックに重点を置く必要があります。
All other security features used with the IPv4 service should be similarly applied to IPv6 as well.
IPv4サービスで使用される他のすべてのセキュリティ機能も同様にIPv6に適用する必要があります。
The necessary instrumentation (such as MIB modules, NetFlow Records, etc.) should be available for IPv6.
IPv6では、必要な計装（MIBモジュール、Netflow Recordsなど）を利用できる必要があります。
Usually, NSPs manage the edge routers by SNMP. The SNMP transport can be done over IPv4 if all managed devices have connectivity over both IPv4 and IPv6. This would imply the smallest changes to the existing network management practices and processes. Transport over IPv6 could also be implemented, and it might become necessary if IPv6 only islands are present in the network. The management applications may be running on hosts belonging to the NSP core network domain. Network Management Applications should handle IPv6 in a similar fashion to IPv4; however, they should also support features specific to IPv6 (such as neighbor monitoring).
通常、NSPはSNMPでエッジルーターを管理します。すべてのマネージドデバイスがIPv4とIPv6の両方に接続されている場合、SNMPトランスポートはIPv4で実行できます。これは、既存のネットワーク管理のプラクティスとプロセスに対する最小の変更を意味します。IPv6を介した輸送も実装でき、IPv6のみがネットワークに存在する場合が必要になる場合があります。管理アプリケーションは、NSPコアネットワークドメインに属するホストで実行されている場合があります。ネットワーク管理アプリケーションは、IPv4と同様の方法でIPv6を処理する必要があります。ただし、IPv6に固有の機能（近隣監視など）もサポートする必要があります。
In some cases, service providers manage equipment located on customers' LANs. The management of equipment at customers' LANs is out of scope of this memo.
場合によっては、サービスプロバイダーは顧客のLANにある機器を管理します。顧客のLANでの機器の管理は、このメモの範囲外です。
This section describes the IPv6 deployment options in currently deployed Broadband Ethernet Access Networks.
このセクションでは、現在展開されているブロードバンドイーサネットアクセスネットワークのIPv6展開オプションについて説明します。
In environments that support the infrastructure deploying RJ-45 or fiber (Fiber to the Home (FTTH) service) to subscribers, 10/100 Mbps Ethernet broadband services can be provided. Such services are generally available in metropolitan areas in multi-tenant buildings where an Ethernet infrastructure can be deployed in a cost-effective manner. In such environments, Metro-Ethernet services can be used to provide aggregation and uplink to a Service Provider.
RJ-45またはファイバー（Fiber to the Home（FTTH）サービス）をサブスクライバーに展開するインフラストラクチャをサポートする環境では、10/100 Mbpsイーサネットブロードバンドサービスを提供できます。このようなサービスは、一般に、イーサネットインフラストラクチャを費用対効果の高い方法で展開できるマルチテナントの建物の大都市圏で利用できます。このような環境では、メトロエテルネットサービスを使用して、サービスプロバイダーに集約とアップリンクを提供できます。
The following network elements are typical of an Ethernet network:
次のネットワーク要素は、イーサネットネットワークの典型です。
Access Switch: It is used as a Layer 2 access device for subscribers.
アクセススイッチ：サブスクライバー向けのレイヤー2アクセスデバイスとして使用されます。
Customer Premise Router: It is used to provide Layer 3 services for customer premise networks.
Customer Premise Router：Customer Premise Networksにレイヤー3サービスを提供するために使用されます。
Aggregation Ethernet Switches: Aggregates multiple subscribers.
集約イーサネットスイッチ：複数のサブスクライバーを集約します。
Broadband Remote Access Server (BRAS) Edge Router (ER)
ブロードバンドリモートアクセスサーバー（BRAS）エッジルーター（ER）
Figure 7.1 depicts all the network elements mentioned.
図7.1は、言及されたすべてのネットワーク要素を示しています。
Customer Premise | Network Access Provider | Network Service Provider
CP NAP NSP
+-----+ +------+ +------+ +--------+
|Hosts|--|Router| +-+ BRAS +--+ Edge | ISP
+-----+ +--+---+ | | | | Router +===> Network
| | +------+ +--------+
+--+----+ |
|Access +-+ |
|Switch | | |
+-------+ | +------+ |
+--+Agg E | |
+-------+ |Switch+-+
+-----+ |Access | +--+ |
|Hosts|--+Switch +-+ +------+
+-----+ +-------+
Figure 7.1
図7.1
The logical topology and design of Broadband Ethernet Networks are very similar to DSL Broadband Networks discussed in Section 6.
ブロードバンドイーサネットネットワークの論理トポロジと設計は、セクション6で説明したDSLブロードバンドネットワークに非常に似ています。
It is worth noting that the general operation, concepts and recommendations described in this section apply similarly to a HomePNA-based network environment. In such an environment, some of the network elements might be differently named.
このセクションで説明した一般的な操作、概念、および推奨事項が、ホームプナベースのネットワーク環境に同様に適用されることは注目に値します。このような環境では、ネットワーク要素の一部は異なる名前が付いている可能性があります。
There are three main design approaches to providing IPv4 connectivity over an Ethernet infrastructure:
イーサネットインフラストラクチャを介してIPv4接続を提供するための3つの主要な設計アプローチがあります。
A. Point-to-Point Model: Each subscriber connects to the network Access switch over RJ-45 or fiber links. Each subscriber is assigned a unique VLAN on the access switch. The VLAN can be terminated at the BRAS or at the Edge Router. The VLANs are 802.1Q trunked to the Layer 3 device (BRAS or Edge Router).
A.ポイントツーポイントモデル：各サブスクライバーは、RJ-45またはファイバーリンクを介してネットワークアクセススイッチに接続します。各サブスクライバーには、アクセススイッチに一意のVLANが割り当てられます。VLANは、ブラジャーまたはエッジルーターで終了できます。VLANは、レイヤー3デバイス（ブラジャーまたはエッジルーター）にトランクされた802.1Qです。
This model is presented in Section 7.2.1.
このモデルは、セクション7.2.1に示されています。
B. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened between each subscriber and the BRAS. The BRAS terminates the PPP sessions and provides Layer 3 connectivity between the subscriber and the ISP.
B. PPP終端凝集（PTA）モデル：各サブスクライバーとBRAの間でPPPセッションが開かれます。ブラジャーはPPPセッションを終了し、サブスクライバーとISPの間のレイヤー3接続を提供します。
This model is presented in Section 7.2.2.
このモデルは、セクション7.2.2に示されています。
C. L2TPv2 Access Aggregation (LAA) Model: PPP sessions are opened between each subscriber and the ISP termination devices. The BRAS tunnels the subscriber PPP sessions to the ISP by encapsulating them into L2TPv2 tunnels.
C. L2TPV2アクセス集約（LAA）モデル：PPPセッションは、各サブスクライバーとISP終了デバイスの間で開かれます。ブラジャーは、それらをL2TPV2トンネルにカプセル化することにより、ISPへの加入者PPPセッションをトンネルします。
This model is presented in Section 7.2.3.
このモデルは、セクション7.2.3に示されています。
In aggregation models the BRAS terminates the subscriber VLANs and aggregates their connections before providing access to the ISP.
集約モデルでは、ブラジャーはサブスクライバーVLANを終了し、ISPへのアクセスを提供する前に接続を集約します。
In order to maintain the deployment concepts and business models proven and used with existing revenue generating IPv4 services, the IPv6 deployment will match the IPv4 one. This approach is presented in Sections 7.2.1 - 7.2.3 that describe currently deployed IPv4 over Ethernet broadband access deployments. Under certain circumstances where new service types or service needs justify it, IPv4 and IPv6 network architectures could be different as described in Section 7.2.4.
展開の概念とビジネスモデルを維持するために、既存の収益を生成するIPv4サービスで使用され、IPv6の展開がIPv4の展開と一致します。このアプローチは、イーサネットブロードバンドアクセスの展開を介して現在展開されているIPv4を説明するセクション7.2.1-7.2.3に示されています。新しいサービスタイプまたはサービスが必要な特定の状況では、IPv4およびIPv6ネットワークアーキテクチャはセクション7.2.4で説明されているように異なる可能性があります。
In this scenario, the Ethernet frames from the Host or the Customer Premise Router are bridged over the VLAN assigned to the subscriber.
このシナリオでは、ホストまたは顧客の前提ルーターからのイーサネットフレームが、サブスクライバーに割り当てられたVLAN上に架橋されています。
Figure 7.2.1 describes the protocol architecture of this model.
図7.2.1は、このモデルのプロトコルアーキテクチャを説明しています。
| Customer Premise | | NAP | NSP |
+-----+ +------+ +------+ +--------+ +----------+
|Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP
+-----+ +------+ |Switch| +--------+ 802.1Q | Router +=>Network
+------+ +----------+
|----------------------------|
Ethernet/VLANs
Figure 7.2.1
図7.2.1
In this scenario, the Access Switch is on the customer site and the entire NAP is Layer 3 unaware, so no changes are needed to support IPv6. The following devices have to be upgraded to dual stack: Host, Customer Router, and Edge Router.
このシナリオでは、アクセススイッチは顧客サイトにあり、NAP全体がレイヤー3を認識していないため、IPv6をサポートするために変更は必要ありません。次のデバイスは、ホスト、顧客ルーター、およびエッジルーターのデュアルスタックにアップグレードする必要があります。
The Access switches might need upgrades to support certain IPv6- related features such as MLD Snooping.
アクセススイッチには、MLDスヌーピングなどの特定のIPv6関連機能をサポートするためのアップグレードが必要になる場合があります。
The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop. If there is no Customer Router all the hosts on the subscriber site belong to the same /64 subnet that is statically configured on the Edge Router for that subscriber VLAN. The hosts can use stateless auto-configuration or stateful DHCPv6-based configuration to acquire an address via the Edge Router.
ホストまたは顧客ルーターは、次のホップ3としてエッジルーターを持っています。顧客ルーターがない場合、サブスクライバーサイトのすべてのホストは、そのサブスクライバーVLANのエッジルーターで静的に構成されている同じ /64サブネットに属します。ホストは、Stateless Auto ConfigurationまたはStateful DHCPV6ベースの構成を使用して、Edgeルーターを介してアドレスを取得できます。
However, as manual configuration for each customer is a provisioning challenge, implementations are encouraged to develop mechanism(s) that automatically map the VLAN (or some other customer-specific information) to an IPv6 subnet prefix, and advertise the customer-specific prefix to all the customers with minimal configuration.
ただし、各顧客の手動構成はプロビジョニングの課題であるため、VLAN（または他の顧客固有の情報）を自動的にIPv6サブネットプレフィックスに自動的にマッピングするメカニズムを開発し、顧客固有のプレフィックスを宣伝する実装が奨励されています。最小限の構成ですべての顧客。
If a Customer Router is present:
顧客ルーターが存在する場合：
A. It is statically configured with an address on the /64 subnet between itself and the Edge Router, and with /64 prefixes on the interfaces connecting the hosts on the customer site. This is not a desired provisioning method, being expensive and difficult to manage.
A.それは、それ自体とエッジルーターの間の /64サブネットのアドレスと、顧客サイトのホストを接続するインターフェイス上の /64プレフィックスで静的に構成されています。これは望ましいプロビジョニング方法ではなく、高価で管理が困難です。
B. It can use its link-local address to communicate with the ER. It can also dynamically acquire, through stateless auto-configuration, the address for the link between itself and the ER. This step is followed by a request via DHCP-PD for a prefix shorter than /64 that in turn is divided in /64s and assigned to its interfaces connecting the hosts on the customer site.
B.リンクローカルアドレスを使用してERと通信できます。また、ステートレスの自動構成を通じて、それ自体とERの間のリンクのアドレスを動的に取得することもできます。このステップの後に、 /64より短い接頭辞のDHCP-PDを介したリクエストが続き、順番に /64Sで分割され、顧客サイトのホストを接続するインターフェイスに割り当てられます。
The Edge Router has a /64 prefix configured for each subscriber VLAN. Each VLAN should be enabled to relay DHCPv6 requests from the subscribers to DHCPv6 servers in the ISP network. The VLANs providing access for subscribers that use DHCP-PD have to be enabled to support the feature. The uplink to the ISP network is configured with a /64 prefix as well.
エッジルーターには、各サブスクライバーVLANに対して構成されたA /64プレフィックスがあります。各VLANは、サブスクライバーからISPネットワークのDHCPV6サーバーにDHCPV6要求を中継することを有効にする必要があります。DHCP-PDを使用する加入者にアクセスを提供するVLANは、機能をサポートするために有効にする必要があります。ISPネットワークへのアップリンクは、A /64プレフィックスでも構成されています。
The prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows as much summarization as possible at the Edge Router.
サブスクライバーリンクに使用されるプレフィックスとDHCP-PDを介して委任されたプレフィックスは、エッジルーターでできるだけ多くの要約を許可する方法で計画する必要があります。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
DNSなどのホストにとって関心のある他の情報は、Stateful [RFC3315]およびStateless [RFC3736] DHCPV6を通じて提供されます。
The CPE devices are configured with a default route that points to the Edge Router. No routing protocols are needed on these devices, which generally have limited resources.
CPEデバイスは、エッジルーターを指すデフォルトルートで構成されています。これらのデバイスでは、通常はリソースが限られているルーティングプロトコルは必要ありません。
The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. The connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the Edge Router. For this reason, the static routes must also be redistributed. Prefix summarization should be done at the Edge Router.
エッジルーターは、NSP：OSPFV3またはIS-ISで使用されるIPv6 IGPを実行します。接続されたプレフィックスを再配布する必要があります。DHCP-PDを使用する場合、委任されたすべてのプレフィックスを使用して、静的ルートがエッジルーターによってインストールされます。このため、静的ルートも再配布する必要があります。プレフィックスの要約は、エッジルーターで行う必要があります。
The PTA architecture relies on PPP-based protocols (PPPoE). The PPP sessions are initiated by Customer Premise Equipment and are terminated at the BRAS. The BRAS authorizes the session, authenticates the subscriber, and provides an IP address on behalf of the ISP. The BRAS then does Layer 3 routing of the subscriber traffic to the NSP Edge Router.
PTAアーキテクチャは、PPPベースのプロトコル（PPPOE）に依存しています。PPPセッションは顧客の前提装備によって開始され、ブラジャーで終了します。ブラジャーはセッションを承認し、サブスクライバーを認証し、ISPに代わってIPアドレスを提供します。BRAは、NSPエッジルーターへのサブスクライバートラフィックの3ルーティングをレイヤー3ルーティングします。
When the NSP is also the NAP, the BRAS and NSP Edge Router could be the same piece of equipment and provide the above mentioned functionality.
NSPもNAPである場合、BRASおよびNSPエッジルーターは同じ機器であり、上記の機能を提供する可能性があります。
The PPPoE logical diagram in an Ethernet Broadband Network is shown in Fig 7.2.2.1.
イーサネットブロードバンドネットワークのPPPOE論理図を図7.2.2.1に示します。
| Customer Premise | | NAP | | NSP |
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
+-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O
|---------------- PPP ----------------| | | R
+-----------+ E
Figure 7.2.2.1
図7.2.2.1
The PPP sessions are initiated by the Customer Premise Equipment (Host or Router). The BRAS authenticates the subscriber against a local or remote database. Once the session is established, the BRAS provides an address and maybe a DNS server to the user; this information is acquired from the subscriber profile or a DHCP server.
PPPセッションは、顧客の前提装備（ホストまたはルーター）によって開始されます。BRAは、ローカルまたはリモートのデータベースに対してサブスクライバーを認証します。セッションが確立されると、BRAはユーザーにアドレスとDNSサーバーを提供します。この情報は、サブスクライバープロファイルまたはDHCPサーバーから取得されます。
This model allows for multiple PPPoE sessions to be supported over the same VLAN, thus allowing the subscriber to connect to multiple services at the same time. The hosts can initiate the PPPoE sessions as well. It is important to remember that the PPPoE encapsulation reduces the IP MTU available for the customer traffic.
このモデルにより、複数のPPPOEセッションを同じVLANでサポートできるため、サブスクライバーが複数のサービスに同時に接続できるようになります。ホストはPPPOEセッションも開始できます。PPPOEカプセル化により、顧客トラフィックが利用可能なIP MTUが減少することを覚えておくことが重要です。
In this scenario, the BRAS is Layer 3 aware and has to be upgraded to support IPv6. Since the BRAS terminates the PPP sessions, it has to support PPPoE with IPv6. The following devices have to be upgraded to dual stack: Host, Customer Router (if present), BRAS and Edge Router.
このシナリオでは、ブラジャーはレイヤー3を認識しており、IPv6をサポートするためにアップグレードする必要があります。ブラジャーはPPPセッションを終了するため、IPv6でPPPOEをサポートする必要があります。次のデバイスは、ホスト、カスタマールーター（存在する場合）、ブラジャー、エッジルーターのデュアルスタックにアップグレードする必要があります。
The BRAS terminates the PPP sessions and provides the subscriber with an IPv6 address from the defined pool for that profile. The subscriber profile for authorization and authentication can be located on the BRAS, or on an AAA server. The Hosts or the Customer Routers have the BRAS as their Layer 3 next hop.
BRASは、PPPセッションを終了し、そのプロファイルの定義されたプールのIPv6アドレスをサブスクライバーに提供します。許可と認証のためのサブスクライバープロファイルは、BRA、またはAAAサーバーに配置できます。ホストまたは顧客ルーターは、次のホップ3としてブラジャーを持っています。
The PPP session can be initiated by a host or by a Customer Router. In the latter case, once the session is established with the BRAS, DHCP-PD can be used to acquire prefixes for the Customer Router interfaces. The BRAS has to be enabled to support DHCP-PD and to relay the DHCPv6 requests of the hosts on the subscriber sites.
PPPセッションは、ホストまたは顧客ルーターによって開始できます。後者の場合、BRAでセッションが確立されると、DHCP-PDを使用して、顧客ルーターインターフェイスのプレフィックスを取得できます。BRAは、DHCP-PDをサポートし、サブスクライバーサイトのホストのDHCPV6要求を中継するために有効にする必要があります。
The BRAS has a /64 prefix configured on the link facing the Edge router. The Edge Router links are also configured with /64 prefixes to provide connectivity to the rest of the ISP network.
ブラジャーには、エッジルーターを向いてリンクに構成された /64プレフィックスがあります。Edgeルーターリンクは、 /64プレフィックスで構成されており、ISPネットワークの残りの部分への接続を提供します。
The prefixes used for subscribers and the ones delegated via DHCP-PD should be planned in a manner that allows maximum summarization at the BRAS.
サブスクライバーに使用されるプレフィックスとDHCP-PDを介して委任されたプレフィックスは、BRAでの最大の要約を可能にする方法で計画する必要があります。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
DNSなどのホストにとって関心のある他の情報は、Stateful [RFC3315]およびStateless [RFC3736] DHCPV6を通じて提供されます。
The CPE devices are configured with a default route that points to the BRAS router. No routing protocols are needed on these devices, which generally have limited resources.
CPEデバイスは、BRASルーターを指すデフォルトルートで構成されています。これらのデバイスでは、通常はリソースが限られているルーティングプロトコルは必要ありません。
The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the addresses assigned to the PPP sessions are represented as connected host routes, connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the BRAS. For this reason, the static routes must also be redistributed. Prefix summarization should be done at the BRAS.
ブラジャーは、EdgeルーターのIGPを実行します：OSPFV3またはIS-IS。PPPセッションに割り当てられたアドレスは、接続されたホストルートとして表されるため、接続されたプレフィックスを再配布する必要があります。DHCP-PDを使用すると、委任されたすべてのプレフィックスが使用されている場合、静的ルートはBRAによってインストールされます。このため、静的ルートも再配布する必要があります。接頭辞の要約はブラジャーで行う必要があります。
The Edge Router is running the IGP used in the ISP network: OSPFv3 or IS-IS. A separation between the routing domains of the ISP and the Access Provider is recommended if they are managed independently. Controlled redistribution will be needed between the Access Provider IGP and the ISP IGP.
Edgeルーターは、ISPネットワークで使用されているIGPを実行しています：OSPFV3またはIS-IS。ISPのルーティングドメインとアクセスプロバイダーが独立して管理されている場合は、アクセスプロバイダーの間の分離をお勧めします。アクセスプロバイダーIGPとISP IGPの間で、制御された再分配が必要になります。
In the LAA model, the BRAS forwards the CPE initiated session to the ISP over an L2TPv2 tunnel established between the BRAS and the Edge Router. In this case, the authentication, authorization, and subscriber configuration are performed by the ISP itself.
LAAモデルでは、BRASは、BRAとエッジルーターの間に確立されたL2TPV2トンネルを介して、CPE開始セッションをISPに転送します。この場合、認証、承認、およびサブスクライバー構成は、ISP自体によって実行されます。
| Customer Premise | | NAP | | NSP |
+-----------+
| AAA |
+------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O
| | R
+-----------+ E
|-----------------------------------------------|
PPP
|--------------|
L2TPv2
Figure 7.2.3.1
In this scenario, the BRAS is Layer 3 aware and has to be upgraded to support IPv6. The PPP sessions initiated by the subscriber are forwarded over the L2TPv2 tunnel to the aggregation point in the ISP network. The BRAS (LAC) can aggregate IPv6 PPP sessions and tunnel them to the LNS using L2TPv2. The L2TPv2 tunnel between the LAC and LNS could run over IPv6 or IPv4. These capabilities have to be supported on the BRAS. The following devices have to be upgraded to dual stack: Host, Customer Router (if present), BRAS and Edge Router.
このシナリオでは、ブラジャーはレイヤー3を認識しており、IPv6をサポートするためにアップグレードする必要があります。サブスクライバーによって開始されたPPPセッションは、L2TPV2トンネルを介してISPネットワークの集約点に転送されます。BRAS（LAC）は、IPv6 PPPセッションを集約し、L2TPV2を使用してLNSにトンネルできます。LACとLNSの間のL2TPV2トンネルは、IPv6またはIPv4を介して実行できます。これらの機能はブラジャーでサポートする必要があります。次のデバイスは、ホスト、カスタマールーター（存在する場合）、ブラジャー、エッジルーターのデュアルスタックにアップグレードする必要があります。
The Edge Router terminates the PPP sessions and provides the subscriber with an IPv6 address from the defined pool for that profile. The subscriber profile for authorization and authentication can be located on the Edge Router or on an AAA server. The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop.
EdgeルーターはPPPセッションを終了し、そのプロファイルの定義されたプールのIPv6アドレスをサブスクライバーに提供します。承認と認証のためのサブスクライバープロファイルは、エッジルーターまたはAAAサーバーに配置できます。ホストまたは顧客ルーターは、次のホップ3としてエッジルーターを持っています。
The PPP session can be initiated by a host or by a Customer Router. In the latter case, once the session is established with the Edge Router and an IPv6 address is assigned to the Customer Router by the Edge Router, DHCP-PD can be used to acquire prefixes for the Customer Router other interfaces. The Edge Router has to be enabled to support DHCP-PD and to relay the DHCPv6 requests of the hosts on the subscriber sites. The uplink to the ISP network is configured with a /64 prefix as well.
PPPセッションは、ホストまたは顧客ルーターによって開始できます。後者の場合、セッションがエッジルーターで確立され、IPv6アドレスがエッジルーターによって顧客ルーターに割り当てられたら、DHCP-PDを使用して、顧客ルーターの他のインターフェイスのプレフィックスを取得できます。Edgeルーターは、DHCP-PDをサポートし、サブスクライバーサイトのホストのDHCPV6要求を中継するために有効にする必要があります。ISPネットワークへのアップリンクは、A /64プレフィックスでも構成されています。
The BRAS has a /64 prefix configured on the link to the Edge Router. The Edge Router links are also configured with /64 prefixes to provide connectivity to the rest of the ISP network.
ブラジャーには、エッジルーターへのリンクで構成された /64プレフィックスがあります。Edgeルーターリンクは、 /64プレフィックスで構成されており、ISPネットワークの残りの部分への接続を提供します。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
DNSなどのホストにとって関心のある他の情報は、Stateful [RFC3315]およびStateless [RFC3736] DHCPV6を通じて提供されます。
The address assignment and prefix summarization issues discussed in Section 6.2.3.2 are relevant in the same way for this media access type as well.
セクション6.2.3.2で説明されているアドレスの割り当てとプレフィックスの要約の問題は、このメディアアクセスタイプと同じように関連しています。
The CPE devices are configured with a default route that points to the Edge Router that terminates the PPP sessions. No routing protocols are needed on these devices, which have limited resources.
CPEデバイスは、PPPセッションを終了するエッジルーターを指すデフォルトルートで構成されています。これらのデバイスでは、リソースが限られているデバイスにはルーティングプロトコルは必要ありません。
The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. Different processes should be used if the NAP and the NSP are managed by different organizations. In this case, controlled redistribution should be enabled between the two domains.
The Edge Router is running the IPv6 IGP used in the ISP network: OSPFv3 or IS-IS.
エッジルーターは、ISPネットワークで使用されるIPv6 IGPを実行しています：OSPFV3またはIS-IS。
It was recommended throughout this section that the IPv6 service implementation should map the existing IPv4 one. This approach simplifies manageability and minimizes training needed for personnel operating the network. In certain circumstances, such mapping is not feasible. This typically becomes the case when a Service Provider plans to expand its service offering with the new IPv6 deployed infrastructure. If this new service is not well supported in a network design such as the one used for IPv4, then a different design might be used for IPv6.
このセクション全体で、IPv6サービスの実装が既存のIPv4 Oneをマッピングすることをお勧めします。このアプローチは、管理性を簡素化し、ネットワークを操作する担当者に必要なトレーニングを最小限に抑えます。特定の状況では、そのようなマッピングは実行不可能です。これは通常、サービスプロバイダーが新しいIPv6デプロイインフラストラクチャでサービス提供を拡大することを計画している場合に当てはまります。この新しいサービスがIPv4に使用されるものなどのネットワーク設計で十分にサポートされていない場合、IPv6には別の設計が使用される場合があります。
An example of such circumstances is that of a provider using an LAA design for its IPv4 services. In this case, all the PPP sessions are bundled and tunneled across the entire NAP infrastructure, which is made of multiple BRAS routers, aggregation routers, etc. The end point of these tunnels is the ISP Edge Router. If the SP decides to offer multicast services over such a design, it will face the problem of NAP resources being over-utilized. The multicast traffic can be replicated only at the end of the tunnels by the Edge Router, and the copies for all the subscribers are carried over the entire NAP.
このような状況の例は、IPv4サービスにLAA設計を使用するプロバイダーの例です。この場合、すべてのPPPセッションは、複数のBRAルーター、集約ルーターなどで作られたNAPインフラストラクチャ全体にバンドルされ、トンネル化されています。これらのトンネルのエンドポイントはISPエッジルーターです。SPがこのようなデザインでマルチキャストサービスを提供することを決定した場合、NAPリソースが過剰に利用されるという問題に直面します。マルチキャストトラフィックは、エッジルーターによってトンネルの端でのみ複製でき、すべてのサブスクライバーのコピーは昼寝全体に運ばれます。
A Modified Point-to-Point (see Section 7.2.4.2) or a PTA model is more suitable to support multicast services because the packet replication can be done closer to the destination at the BRAS. Such a topology saves NAP resources.
パケットレプリケーションをブラジャーの宛先に近づけることができるため、修正されたポイントツーポイント（セクション7.2.4.2を参照）またはPTAモデルは、マルチキャストサービスをサポートするためにより適しています。このようなトポロジは、NAPリソースを節約します。
In this sense, IPv6 deployments can be viewed as an opportunity to build an infrastructure that can better support the expansion of services. In this case, an SP using the LAA design for its IPv4 services might choose a modified Point-to-Point or PTA design for IPv6.
この意味で、IPv6の展開は、サービスの拡大をよりよくサポートできるインフラストラクチャを構築する機会と見なすことができます。この場合、IPv4サービスにLAA設計を使用するSPは、IPv6の変更されたポイントツーポイントまたはPTA設計を選択する場合があります。
The coexistence of the two PPP-based models, PTA and LAA, is relatively straightforward. It is a straightforward overlap of the two deployment models. The PPP sessions are terminated on different network devices for the IPv4 and IPv6 services. The PPP sessions for the existing IPv4 service deployed in an LAA model are terminated on the Edge Router. The PPP sessions for the new IPv6 service deployed in a PTA model are terminated on the BRAS.
2つのPPPベースのモデルであるPTAとLAAの共存は、比較的簡単です。これは、2つの展開モデルの簡単なオーバーラップです。PPPセッションは、IPv4およびIPv6サービスのさまざまなネットワークデバイスで終了します。LAAモデルに展開されている既存のIPv4サービスのPPPセッションは、エッジルーターで終了します。PTAモデルに展開されている新しいIPv6サービスのPPPセッションは、BRAで終了します。
The logical design for IPv6 and IPv4 in this hybrid model is presented in Figure 7.2.4.1.
このハイブリッドモデルのIPv6とIPv4の論理設計を図7.2.4.1に示します。
IPv6 |--------------------------|
PPP +-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
Figure 7.2.4.1
図7.2.4.1
The coexistence of the modified Point-to-Point and the LAA models implies a few specific changes.
修正されたポイントツーポイントとLAAモデルの共存は、いくつかの特定の変化を意味します。
For the IPv4 service in LAA model, the VLANs are terminated on the BRAS, and PPP sessions are terminated on the Edge Router (LNS). For the IPv6 service in the Point-to-Point model, the VLANs are terminated at the Edge Router as described in Section 6.2.1. In this hybrid model, the Point-to-Point link could be terminated on the BRAS, a NAP-owned device. The IPv6 traffic is then routed through the NAP network to the NSP. In order to have this hybrid model, the BRAS has to be upgraded to a dual-stack router. The functionalities of the Edge Router, as described in Section 6.2.1, are now implemented on the BRAS.
LAAモデルのIPv4サービスの場合、VLANはBRAで終了し、PPPセッションはエッジルーター（LNS）で終了します。ポイントツーポイントモデルのIPv6サービスの場合、セクション6.2.1で説明されているように、VLANはエッジルーターで終了します。このハイブリッドモデルでは、ポイントツーポイントリンクは、昼寝型デバイスであるBRAで終了できます。IPv6トラフィックは、NAPネットワークを介してNSPにルーティングされます。このハイブリッドモデルを使用するには、ブラジャーをデュアルスタックルーターにアップグレードする必要があります。セクション6.2.1で説明されているように、エッジルーターの機能は現在ブラジャーに実装されています。
The logical design for IPv6 and IPv4 in this hybrid model is in Figure 7.2.4.2.
このハイブリッドモデルのIPv6とIPv4の論理設計は、図7.2.4.2にあります。
IPv6 |----------------|
Ethernet
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
Figure 7.2.4.2
図7.2.4.2
The typical multicast services offered for residential and very small businesses are video/audio streaming where the subscriber joins a multicast group and receives the content. This type of service model is well supported through PIM-SSM, which is very simple and easy to manage. PIM-SSM has to be enabled throughout the ISP network. MLDv2 is required for PIM-SSM support. Vendors can choose to implement features that allow routers to map MLDv1 group joins to predefined sources.
住宅および非常に中小企業向けに提供される典型的なマルチキャストサービスは、サブスクライバーがマルチキャストグループに参加してコンテンツを受け取るビデオ/オーディオストリーミングです。このタイプのサービスモデルは、PIM-SSMを通じてよくサポートされています。PIM-SSMは非常にシンプルで管理しやすいです。PIM-SSMは、ISPネットワーク全体で有効にする必要があります。MLDV2は、PIM-SSMサポートに必要です。ベンダーは、ルーターが事前定義されたソースに結合するMLDV1グループをマッピングできるようにする機能を実装することを選択できます。
Subscribers might use a set-top box that is responsible for the control piece of the multicast service (does group joins/leaves). The subscriber hosts can also join desired multicast groups as long as they are enabled to support MLDv1 or MLDv2. If a CPR is used, then it has to be enabled to support MLDv1 and MLDv2 in order to process the requests of the hosts. It has to be enabled to support PIM-SSM in order to send PIM joins/leaves up to its Layer 3 next hop whether it is the BRAS or the Edge Router. When enabling this functionality on a CPR, its limited resources should be taken into consideration. Another option would be for the CPR to support MLD proxy routing. MLD snooping or similar Layer 2 multicast-related protocols could be enabled on the NAP switches.
加入者は、マルチキャストサービスのコントロールピースを担当するセットトップボックスを使用する場合があります（グループが結合/葉をつけます）。サブスクライバーホストは、MLDV1またはMLDV2をサポートできる限り、希望のマルチキャストグループに参加することもできます。CPRを使用する場合は、ホストのリクエストを処理するためにMLDV1とMLDV2をサポートするために有効にする必要があります。PIM-SSMをサポートして、ブラジャーであろうとエッジルーターであろうと、次のホップに層3に去る/去るために有効にする必要があります。CPRでこの機能を有効にする場合、限られたリソースを考慮する必要があります。別のオプションは、CPRがMLDプロキシルーティングをサポートすることです。MLDスヌーピングまたは同様のレイヤー2マルチキャスト関連プロトコルをNAPスイッチで有効にすることができます。
The router that is the Layer 3 next hop for the subscriber (BRAS in the PTA model or the Edge Router in the LAA and Point-to-Point model) has to be enabled to support MLDv1 and MLDv2 in order to process the requests coming from subscribers without CPRs. It has to be enabled for PIM-SSM in order to receive joins/leaves from customer routers and send joins/leaves to the next hop towards the multicast source (Edge Router or the NSP core).
レイヤー3である次のサブスクライバー（PTAモデルのBRAまたはLAAおよびポイントツーポイントモデルのエッジルーター）の次は、MLDV1とMLDV2をサポートするために有効にする必要があります。CPRSのない購読者。顧客ルーターから結合/葉を受け取り、マルチキャストソース（EdgeルーターまたはNSPコア）に向かって次のホップに結合/葉を送信するために、PIM-SSMを有効にする必要があります。
MLD authentication, authorization, and accounting are usually configured on the edge router in order to enable the ISP to control the subscriber access of the service and do billing for the content provided. Alternative mechanisms that would support these functions should be investigated further.
MLD認証、承認、および会計は、通常、ISPがサービスのサブスクライバーアクセスを制御し、提供されたコンテンツの請求を行うことができるように、Edgeルーターで構成されます。これらの機能をサポートする代替メカニズムをさらに調査する必要があります。
Please refer to section 6.3 for more IPv6 multicast details.
IPv6マルチキャストの詳細については、セクション6.3を参照してください。
The QoS configuration is particularly relevant on the router that represents the Layer 3 next hop for the subscriber (BRAS in the PTA model or the Edge Router in the LAA and Point-to-Point model) in order to manage resources shared amongst multiple subscribers, possibly with various service level agreements.
QoS構成は、複数のサブスクライバーの間で共有されているリソースを管理するために、サブスクライバー（PTAモデルのBRAまたはLAAおよびポイントツーポイントモデル）のレイヤー3次のホップを表すルーターに特に関連しています。おそらくさまざまなサービスレベルの契約があります。
On the BRAS or the Edge Router, the subscriber-facing interfaces have to be configured to police the inbound customer traffic and shape the traffic outbound to the customer based on the SLAs. Traffic classification and marking should also be done on the router closest (at Layer 3) to the subscriber in order to support the various types of customer traffic: data, voice, video, and to optimally use the network resources. This infrastructure offers a very good opportunity to leverage the QoS capabilities of Layer 2 devices. Diffserv-based QoS used for IPv4 should be expanded to IPv6.
ブラジャーまたはエッジルーターでは、サブスクライバー向けインターフェイスを設定する必要があります。インバウンド顧客のトラフィックを締結し、SLAに基づいて顧客にトラフィックを形作る必要があります。トラフィックの分類とマーキングは、データ、音声、ビデオ、およびネットワークリソースを最適に使用するために、さまざまなタイプの顧客トラフィックをサポートするために、サブスクライバーに最も近いルーター（レイヤー3）で行う必要があります。このインフラストラクチャは、レイヤー2デバイスのQoS機能を活用する非常に良い機会を提供します。IPv4に使用されるDIFFSERVベースのQOSは、IPv6に拡張する必要があります。
Each provider (NAP, NSP) could implement their own QoS policies and services so that reclassification and marking might be performed at the boundary between the NAP and the NSP, in order to make sure the traffic is properly handled by the ISP. The same IPv4 QoS concepts and methodologies should be applied for the IPv6 as well.
各プロバイダー（NAP、NSP）は、ISPによってトラフィックが適切に処理されることを確認するために、NAPとNSPの境界で再分類とマーキングを実行できるように、独自のQOSポリシーとサービスを実装できます。同じIPv4 QoSの概念と方法論もIPv6にも適用する必要があります。
It is important to note that when traffic is encrypted end-to-end, the traversed network devices will not have access to many of the packet fields used for classification purposes. In these cases, routers will most likely place the packets in the default classes. The QoS design should take into consideration this scenario and try to use mainly IP header fields for classification purposes.
トラフィックがエンドツーエンドで暗号化されている場合、トラバースされたネットワークデバイスは分類に使用されるパケットフィールドの多くにアクセスできないことに注意することが重要です。これらの場合、ルーターはおそらくパケットをデフォルトのクラスに配置します。QoS設計では、このシナリオを考慮し、分類目的で主にIPヘッダーフィールドを使用しようとする必要があります。
There are limited changes that have to be done for CPEs in order to enhance security. The privacy extensions [RFC3041] for auto-configuration should be used by the hosts with the same considerations for host traceability as discussed in Section 6.5. IPv6 firewall functions should be enabled on the hosts or Customer Premise Router, if present.
セキュリティを強化するためには、CPEに対して行う必要がある限られた変更があります。セクション6.5で説明したように、ホストのトレーサビリティについて同じ考慮事項で、自動構成のプライバシー拡張[RFC3041]は、ホストが使用する必要があります。IPv6ファイアウォール機能は、存在する場合はホストまたは顧客の前提ルーターで有効にする必要があります。
The ISP provides security against attacks that come from its own subscribers, but it could also implement security services that protect its subscribers from attacks sourced from outside its network. Such services do not apply at the access level of the network discussed here.
ISPは、独自の加入者から生じる攻撃に対するセキュリティを提供しますが、ネットワークの外部から供給された攻撃から加入者を保護するセキュリティサービスを実装することもできます。このようなサービスは、ここで説明するネットワークのアクセスレベルでは適用されません。
If any Layer 2 filters for Ethertypes are in place, the NAP must permit the IPv6 Ethertype (0X86DD).
The device that is the Layer 3 next hop for the subscribers (BRAS Edge Router) should protect the network and the other subscribers against attacks by one of the provider customers. For this reason uRPF and ACLs should be used on all interfaces facing subscribers. Filtering should be implemented with regard for the operational requirements of IPv6 [IPv6-Security].
レイヤー3次のデバイスは、サブスクライバー（BRASエッジルーター）のためのホップをホップする必要があります。これは、プロバイダーの顧客の1人による攻撃からネットワークと他のサブスクライバーを保護する必要があります。このため、URPFとACLは、サブスクライバーに直面しているすべてのインターフェイスで使用する必要があります。IPv6 [IPv6-Security]の運用要件に関して、フィルタリングを実装する必要があります。
The BRAS and the Edge Router should protect their processing resources against floods of valid customer control traffic such as: Router and Neighbor Solicitations, and MLD Requests. Rate limiting should be implemented on all subscriber-facing interfaces. The emphasis should be placed on multicast-type traffic, as it is most often used by the IPv6 control plane.
All other security features used with the IPv4 service should be similarly applied to IPv6 as well.
IPv4サービスで使用される他のすべてのセキュリティ機能も同様にIPv6に適用する必要があります。
The necessary instrumentation (such as MIB modules, NetFlow Records, etc.) should be available for IPv6.
IPv6では、必要な計装（MIBモジュール、Netflow Recordsなど）を利用できる必要があります。
Usually, NSPs manage the edge routers by SNMP. The SNMP transport can be done over IPv4 if all managed devices have connectivity over both IPv4 and IPv6. This would imply the smallest changes to the existing network management practices and processes. Transport over IPv6 could also be implemented and it might become necessary if IPv6 only islands are present in the network. The management applications may be running on hosts belonging to the NSP core network domain. Network Management Applications should handle IPv6 in a similar fashion to IPv4; however, they should also support features specific to IPv6 such as neighbor monitoring.
通常、NSPはSNMPでエッジルーターを管理します。すべてのマネージドデバイスがIPv4とIPv6の両方に接続されている場合、SNMPトランスポートはIPv4で実行できます。これは、既存のネットワーク管理のプラクティスとプロセスに対する最小の変更を意味します。IPv6を介した輸送も実装でき、IPv6のみの島がネットワークに存在する場合が必要になる場合があります。管理アプリケーションは、NSPコアネットワークドメインに属するホストで実行されている場合があります。ネットワーク管理アプリケーションは、IPv4と同様の方法でIPv6を処理する必要があります。ただし、近隣監視などのIPv6に固有の機能もサポートする必要があります。
In some cases, service providers manage equipment located on customers' LANs.
場合によっては、サービスプロバイダーは顧客のLANにある機器を管理します。
This section provides a detailed description of IPv6 deployment and integration methods in currently deployed wireless LAN (WLAN) infrastructure.
このセクションでは、現在展開されているワイヤレスLAN（WLAN）インフラストラクチャにおけるIPv6の展開および統合方法の詳細な説明を提供します。
WLAN enables subscribers to connect to the Internet from various locations without the restriction of staying indoors. WLAN is standardized by IEEE 802.11a/b/g.
WLANにより、加入者は、屋内にとどまることを制限することなく、さまざまな場所からインターネットに接続できます。WLANはIEEE 802.11a/b/gによって標準化されています。
Figure 8.1 describes the current WLAN architecture.
図8.1は、現在のWLANアーキテクチャを説明しています。
Customer | Access Provider | Service Provider
Premise | |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | |Access Router/| | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
+------+
|AAA |
|Server|
+------+
Figure 8.1
図8.1
The host should have a wireless Network Interface Card (NIC) in order to connect to a WLAN network. WLAN is a flat broadcast network and works in a similar fashion as Ethernet. When a host initiates a connection, it is authenticated by the AAA server located at the SP network. All the authentication parameters (username, password, etc.) are forwarded by the Access Point (AP) to the AAA server. The AAA server authenticates the host; once successfully authenticated, the host can send data packets. The AP is located near the host and acts as a bridge. The AP forwards all the packets coming to/from host to the Edge Router. The underlying connection between the AP and Edge Router could be based on any access layer technology such as HFC/Cable, FTTH, xDSL, etc.
ホストには、WLANネットワークに接続するために、ワイヤレスネットワークインターフェイスカード（NIC）が必要です。WLANはフラットブロードキャストネットワークであり、イーサネットと同様の方法で動作します。ホストが接続を開始すると、SPネットワークにあるAAAサーバーによって認証されます。すべての認証パラメーター（ユーザー名、パスワードなど）は、アクセスポイント（AP）によってAAAサーバーに転送されます。AAAサーバーはホストを認証します。正常に認証されると、ホストはデータパケットを送信できます。APはホストの近くにあり、橋として機能します。APは、ホストからエッジルーターに出入りするすべてのパケットを転送します。APルーターとエッジルーターの根本的な接続は、HFC/ケーブル、FTTH、XDSLなどのアクセスレイヤーテクノロジーに基づいています。
WLANs operate within limited areas known as WiFi Hot Spots. While users are present in the area covered by the WLAN range, they can be connected to the Internet given they have a wireless NIC and required configuration settings in their devices (notebook PCs, PDAs, etc.). Once the user initiates the connection, the IP address is assigned by the SP using DHCPv4. In most of the cases, SP assigns a limited number of public IP addresses to its customers. When the user disconnects the connection and moves to a new WiFi hot spot, the above-mentioned process of authentication, address assignment, and accessing the Internet is repeated.
WLANは、WiFiホットスポットとして知られる限られたエリア内で動作します。ユーザーはWLANの範囲でカバーされているエリアに存在しますが、ワイヤレスNICがあり、デバイス（ノートブックPC、PDAなど）に必要な構成設定があることを考えると、インターネットに接続できます。ユーザーが接続を開始すると、IPアドレスはDHCPV4を使用してSPによって割り当てられます。ほとんどの場合、SPは限られた数のパブリックIPアドレスを顧客に割り当てます。ユーザーが接続を切断して新しいWiFiホットスポットに移動すると、上記の認証、アドレスの割り当て、およびインターネットへのアクセスのプロセスが繰り返されます。
There are IPv4 deployments where customers can use WLAN routers to connect over wireless to their service provider. These deployment types do not fit in the typical Hot Spot concept, but rather they serve fixed customers. For this reason, this section discusses the WLAN router options as well. In this case, the ISP provides a public IP address and the WLAN Router assigns private addresses [RFC1918] to all WLAN users. The WLAN Router provides NAT functionality while WLAN users access the Internet.
顧客がWLANルーターを使用してワイヤレスをサービスプロバイダーに接続できるIPv4展開があります。これらの展開タイプは、典型的なホットスポットのコンセプトに適合しませんが、むしろ固定顧客にサービスを提供しています。このため、このセクションでは、WLANルーターのオプションについても説明します。この場合、ISPはパブリックIPアドレスを提供し、WLANルーターはすべてのWLANユーザーにプライベートアドレス[RFC1918]を割り当てます。WLANルーターはNAT機能を提供し、WLANユーザーはインターネットにアクセスします。
While deploying IPv6 in the above-mentioned WLAN architecture, there are three possible scenarios as discussed below.
上記のWLANアーキテクチャにIPv6を展開している間、以下で説明するように3つのシナリオがあります。
A. Layer 2 NAP with Layer 3 termination at NSP Edge Router
A. NSPエッジルーターでのレイヤー3終端を備えたレイヤー2昼寝
B. Layer 3 aware NAP with Layer 3 termination at Access Router
B.レイヤー3アクセスルーターでのレイヤー3終端を備えた昼寝を認識します
C. PPP-Based Model
C. PPPベースのモデル
When a Layer 2 switch is present between AP and Edge Router, the AP and Layer 2 switch continues to work as a bridge, forwarding IPv4 and IPv6 packets from WLAN Host/Router to Edge Router and vice versa.
APルーターとエッジルーターの間にレイヤー2スイッチが存在する場合、APとレイヤー2スイッチはブリッジとして機能し続け、WLANホスト/ルーターからIPv4およびIPv6パケットをエッジルーターに転送し、その逆になります。
When initiating the connection, the WLAN Host is authenticated by the AAA server located at the SP network. All the parameters related to authentication (username, password, etc.) are forwarded by the AP to the AAA server. The AAA server authenticates the WLAN Hosts, and once the WLAN Host is authenticated and associated successfully with the WLAN AP, it acquires an IPv6 address. Note that the initiation and authentication process is the same as used in IPv4.
接続を開始すると、WLANホストはSPネットワークにあるAAAサーバーによって認証されます。認証に関連するすべてのパラメーター（ユーザー名、パスワードなど）は、APによってAAAサーバーに転送されます。AAAサーバーはWLANホストを認証し、WLANホストが認証され、WLAN APに正常に関連すると、IPv6アドレスを取得します。開始と認証プロセスは、IPv4で使用されるものと同じであることに注意してください。
Figure 8.1.1 describes the WLAN architecture when a Layer 2 Switch is located between AP and Edge Router.
図8.1.1は、レイヤー2スイッチがAPとエッジルーターの間にある場合のWLANアーキテクチャを説明しています。
Customer | Access Provider | Service Provider
Premise | |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
+------+
|AAA |
|Server|
+------+
Figure 8.1.1
図8.1.1
IPv6 will be deployed in this scenario by upgrading the following devices to dual stack: WLAN Host, WLAN Router (if present), and Edge Router.
IPv6は、次のデバイスをデュアルスタックにアップグレードすることにより、このシナリオに展開されます：WLANホスト、WLANルーター（存在する場合）、およびエッジルーター。
When a customer WLAN Router is not present, the WLAN Host has two possible options to get an IPv6 address via the Edge Router.
顧客WLANルーターが存在しない場合、WLANホストには、エッジルーターを介してIPv6アドレスを取得する2つの可能なオプションがあります。
A. The WLAN Host can get the IPv6 address from an Edge Router using stateless auto-configuration [RFC2462]. All hosts on the WLAN belong to the same /64 subnet that is statically configured on the Edge Router. The IPv6 WLAN Host may use stateless DHCPv6 for obtaining other information of interest such as DNS, etc.
A. WLANホストは、Stateless Auto Configuration [RFC2462]を使用して、EdgeルーターからIPv6アドレスを取得できます。WLANのすべてのホストは、エッジルーターで静的に構成されている同じ /64サブネットに属します。IPv6 WLANホストは、DNSなどの関心のある他の情報を取得するために、Stateless DHCPV6を使用する場合があります。
B. The IPv6 WLAN Host can use DHCPv6 [RFC3315] to get an IPv6 address from the DHCPv6 server. In this case, the DHCPv6 server would be located in the SP core network, and the Edge Router would simply act as a DHCP Relay Agent. This option is similar to what is done today in case of DHCPv4. It is important to note that host implementation of stateful auto-configuration is rather limited at this time, and this should be considered if choosing this address assignment option.
B. IPv6 WLANホストは、DHCPV6 [RFC3315]を使用して、DHCPV6サーバーからIPv6アドレスを取得できます。この場合、DHCPV6サーバーはSPコアネットワークに配置され、エッジルーターは単にDHCPリレーエージェントとして機能します。このオプションは、DHCPV4の場合に今日行われていることに似ています。現時点では、ステートフルな自動構成のホスト実装はかなり制限されていることに注意することが重要です。これは、このアドレス割り当てオプションを選択する場合は考慮する必要があります。
When a customer WLAN Router is present, the WLAN Host has two possible options as well for acquiring IPv6 address.
顧客WLANルーターが存在する場合、WLANホストにはIPv6アドレスを取得するための2つの可能なオプションがあります。
A. The WLAN Router may be assigned a prefix between /48 and /64 [RFC3177] depending on the SP policy and customer requirements. If the WLAN Router has multiple networks connected to its interfaces, the network administrator will have to configure the /64 prefixes to the WLAN Router interfaces connecting the WLAN Hosts on the customer site. The WLAN Hosts connected to these interfaces can automatically configure themselves using stateless auto-configuration.
A. WLANルーターには、SPポリシーと顧客の要件に応じて、 /48と /64 [RFC3177]の間のプレフィックスを割り当てることができます。WLANルーターにインターフェイスに接続された複数のネットワークがある場合、ネットワーク管理者は、顧客サイトのWLANホストを接続するWLANルーターインターフェイスに /64プレフィックスを構成する必要があります。これらのインターフェイスに接続されているWLANホストは、Stateless Auto Configurationを使用して自動的に自動的に構成できます。
B. The WLAN Router can use its link-local address to communicate with the ER. It can also dynamically acquire through stateless auto-configuration the address for the link between itself and the ER. This step is followed by a request via DHCP-PD for a prefix shorter than /64 that, in turn, is divided in /64s and assigned to its interfaces connecting the hosts on the customer site.
B. WLANルーターは、リンクローカルアドレスを使用してERと通信できます。また、ステートレスの自動構成を通じて、それ自体とERの間のリンクのアドレスを動的に取得することもできます。このステップの後に、 /64より短い接頭辞のDHCP-PDを介したリクエストが続きます。これは、 /64Sに分割され、顧客サイトのホストを接続するインターフェイスに割り当てられます。
In this option, the WLAN Router would act as a requesting router and the Edge Router would act as a delegating router. Once the prefix is received by the WLAN Router, it assigns /64 prefixes to each of its interfaces connecting the WLAN Hosts on the customer site. The WLAN Hosts connected to these interfaces can automatically configure themselves using stateless auto-configuration. The uplink to the ISP network is configured with a /64 prefix as well.
このオプションでは、WLANルーターはリクエストルーターとして機能し、エッジルーターは委任ルーターとして機能します。接頭辞がWLANルーターによって受信されると、顧客サイトのWLANホストを接続する各インターフェイスに /64のプレフィックスを割り当てます。これらのインターフェイスに接続されているWLANホストは、Stateless Auto Configurationを使用して自動的に自動的に構成できます。ISPネットワークへのアップリンクは、A /64プレフィックスでも構成されています。
Usually it is easier for the SPs to stay with the DHCP-PD and stateless auto-configuration model and point the clients to a central server for DNS/domain information, proxy configurations, etc. Using this model, the SP could change prefixes on the fly, and the WLAN Router would simply pull the newest prefix based on the valid/ preferred lifetime.
通常、SPSはDHCP-PDおよびStateless Auto Configurationモデルにとどまり、クライアントをDNS/ドメイン情報、プロキシ構成などの中央サーバーに向けます。このモデルを使用すると、SPはフライ、そしてWLANルーターは、有効な/優先寿命に基づいて最新のプレフィックスを単純に引っ張ります。
The prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows maximum summarization at the Edge Router.
サブスクライバーリンクに使用されるプレフィックスとDHCP-PDを介して委任されたプレフィックスは、Edgeルーターでの最大の要約を許可する方法で計画する必要があります。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
DNSなどのホストにとって関心のある他の情報は、Stateful [RFC3315]およびStateless [RFC3736] DHCPV6を通じて提供されます。
The WLAN Host/Router is configured with a default route that points to the Edge Router. No routing protocols are needed on these devices, which generally have limited resources.
WLANホスト/ルーターは、エッジルーターを指すデフォルトルートで構成されています。これらのデバイスでは、通常はリソースが限られているルーティングプロトコルは必要ありません。
The Edge Router runs the IGP used in the SP network such as OSPFv3 or IS-IS for IPv6. The connected prefixes have to be redistributed. Prefix summarization should be done at the Edge Router. When DHCP-PD is used, the IGP has to redistribute the static routes installed during the process of prefix delegation.
エッジルーターは、IPV6のOSPFV3やIS-ISなどのSPネットワークで使用されるIGPを実行します。接続されたプレフィックスを再配布する必要があります。プレフィックスの要約は、エッジルーターで行う必要があります。DHCP-PDを使用する場合、IGPはプレフィックス委任のプロセス中に設置された静的ルートを再配布する必要があります。
When an Access Router is present between the AP and Edge Router, the AP continues to work as a bridge, bridging IPv4 and IPv6 packets from WLAN Host/Router to Access Router and vice versa. The Access Router could be part of the SP network or owned by a separate Access Provider.
APルーターとエッジルーターの間にアクセスルーターが存在する場合、APはブリッジとして機能し続け、WLANホスト/ルーターからIPv4とIPv6パケットをブリッジしてルーターにアクセスし、その逆も同様です。アクセスルーターは、SPネットワークの一部であるか、別のアクセスプロバイダーが所有する場合があります。
When the WLAN Host initiates the connection, the AAA authentication and association process with WLAN AP will be similar, as explained in Section 8.1.1.
WLANホストが接続を開始すると、セクション8.1.1で説明されているように、AAA認証とWLAN APとの関連プロセスが類似しています。
Figure 8.1.2 describes the WLAN architecture when the Access Router is located between the AP and Edge Router.
図8.1.2は、アクセスルーターがAPルーターとエッジルーターの間にある場合のWLANアーキテクチャを示しています。
Customer | Access Provider | Service Provider
Premise | |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
+------+
|AAA |
|Server|
+------+
Figure 8.1.2
図8.1.2
IPv6 is deployed in this scenario by upgrading the following devices to dual stack: WLAN Host, WLAN Router (if present), Access Router, and Edge Router.
IPv6は、次のデバイスをデュアルスタックにアップグレードすることにより、このシナリオに展開されます：WLANホスト、WLANルーター（存在する場合）、アクセスルーター、およびエッジルーター。
There are three possible options in this scenario for IPv6 address assignment:
このシナリオには、IPv6アドレスの割り当てには3つのオプションがあります。
A. The Edge Router interface facing towards the Access Router is statically configured with a /64 prefix. The Access Router receives/ configures a /64 prefix on its interface facing towards the Edge Router through stateless auto-configuration. The network administrator will have to configure the /64 prefixes to the Access Router interface facing toward the customer premise. The WLAN Host/Router connected to this interface can automatically configure itself using stateless auto-configuration.
A.アクセスルーターに向かって面を表すエッジルーターインターフェイスは、A /64プレフィックスで静的に構成されています。アクセスルーターは、ステートレスオートコンフィグレーザーを介してエッジルーターに向かって面を表すインターフェイスでA / 64プレフィックスを受信 /構成します。ネットワーク管理者は、顧客の前提に向けて面に向けてアクセスルーターインターフェイスに /64のプレフィックスを構成する必要があります。このインターフェイスに接続されたWLANホスト/ルーターは、Stateless Auto Configurationを使用して自動的に自動的に構成できます。
B. This option uses DHCPv6 [RFC3315] for IPv6 prefix assignments to the WLAN Host/Router. There is no use of DHCP PD or stateless auto-configuration in this option. The DHCPv6 server can be located on the Access Router, the Edge Router, or somewhere in the SP network. In this case, depending on where the DHCPv6 server is located, the Access Router or the Edge Router would relay the DHCPv6 requests.
B.このオプションは、WLANホスト/ルーターへのIPv6プレフィックス割り当てにDHCPV6 [RFC3315]を使用します。このオプションでは、DHCP PDまたはStateless Auto-Configurationの使用はありません。DHCPV6サーバーは、アクセスルーター、エッジルーター、またはSPネットワークのどこかに配置できます。この場合、DHCPV6サーバーがどこにあるかに応じて、アクセスルーターまたはエッジルーターがDHCPV6要求を中継します。
C. It can use its link-local address to communicate with the ER. It can also dynamically acquire through stateless auto-configuration the address for the link between itself and the ER. This step is followed by a request via DHCP-PD for a prefix shorter than /64 that, in turn, is divided in /64s and assigned to its interfaces connecting the hosts on the customer site.
C.リンクローカルアドレスを使用してERと通信できます。また、ステートレスの自動構成を通じて、それ自体とERの間のリンクのアドレスを動的に取得することもできます。このステップの後に、 /64より短い接頭辞のDHCP-PDを介したリクエストが続きます。これは、 /64Sに分割され、顧客サイトのホストを接続するインターフェイスに割り当てられます。
In this option, the Access Router would act as a requesting router, and the Edge Router would act as a delegating router. Once the prefix is received by the Access Router, it assigns /64 prefixes to each of its interfaces connecting the WLAN Host/ Router on the customer site. The WLAN Host/Router connected to these interfaces can automatically configure itself using stateless auto-configuration. The uplink to the ISP network is configured with a /64 prefix as well.
このオプションでは、アクセスルーターはリクエストルーターとして機能し、エッジルーターは委任ルーターとして機能します。接頭辞がアクセスルーターによって受信されると、顧客サイトのWLANホスト /ルーターを接続する各インターフェイスに / 64のプレフィックスを割り当てます。これらのインターフェイスに接続されたWLANホスト/ルーターは、Stateless Auto Configurationを使用して自動的に自動的に構成できます。ISPネットワークへのアップリンクは、A /64プレフィックスでも構成されています。
It is easier for the SPs to stay with the DHCP PD and stateless auto-configuration model and point the clients to a central server for DNS/domain information, proxy configurations, and others. Using this model, the provider could change prefixes on the fly, and the Access Router would simply pull the newest prefix based on the valid/ preferred lifetime.
SPSがDHCP PDおよびStateless Auto Configurationモデルにとどまり、DNS/ドメイン情報、プロキシ構成などの中央サーバーにクライアントを指すのは簡単です。このモデルを使用して、プロバイダーはその場でプレフィックスを変更することができ、アクセスルーターは、有効な/優先寿命に基づいて最新のプレフィックスを単純に引くだけです。
As mentioned before, the prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows the maximum summarization possible at the Edge Router. Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
前述のように、サブスクライバーリンクに使用されるプレフィックスとDHCP-PDを介して委任されたプレフィックスは、Edgeルーターで可能な最大の要約を可能にする方法で計画する必要があります。DNSなどのホストにとって関心のある他の情報は、Stateful [RFC3315]およびStateless [RFC3736] DHCPV6を通じて提供されます。
The WLAN Host/Router is configured with a default route that points to the Access Router. No routing protocols are needed on these devices, which generally have limited resources.
WLANホスト/ルーターは、アクセスルーターを指すデフォルトルートで構成されています。これらのデバイスでは、通常はリソースが限られているルーティングプロトコルは必要ありません。
If the Access Router is owned by an Access Provider, then the Access Router can have a default route, pointing towards the SP Edge Router. The Edge Router runs the IGP used in the SP network such as OSPFv3 or IS-IS for IPv6. The connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the Edge Router. For this reason the static routes must be redistributed. Prefix summarization should be done at the Edge Router.
アクセスルーターがアクセスプロバイダーが所有している場合、アクセスルーターには、SPエッジルーターに向かって指すデフォルトルートを持つことができます。エッジルーターは、IPV6のOSPFV3やIS-ISなどのSPネットワークで使用されるIGPを実行します。接続されたプレフィックスを再配布する必要があります。DHCP-PDを使用する場合、委任されたすべてのプレフィックスを使用して、静的ルートがエッジルーターによってインストールされます。このため、静的ルートを再配布する必要があります。プレフィックスの要約は、エッジルーターで行う必要があります。
If the Access Router is owned by the SP, then the Access Router will also run IPv6 IGP, and will be part of the SP IPv6 routing domain (OSPFv3 or IS-IS). The connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the Access Router. For this reason, the static routes must be redistributed. Prefix summarization should be done at the Access Router.
アクセスルーターがSPが所有している場合、アクセスルーターもIPv6 IGPを実行し、SP IPv6ルーティングドメイン（OSPFV3またはIS-IS）の一部になります。接続されたプレフィックスを再配布する必要があります。DHCP-PDを使用する場合、委任されたすべてのプレフィックスを使用すると、アクセスルーターによって静的ルートがインストールされます。このため、静的ルートを再配布する必要があります。接頭辞の要約は、アクセスルーターで行う必要があります。
PPP Terminated Aggregation (PTA) and L2TPv2 Access Aggregation (LAA) models, as discussed in Sections 6.2.2 and 6.2.3, respectively, can also be deployed in IPv6 WLAN environment.
PPPは、セクション6.2.2および6.2.3で説明したように、それぞれIPv6 WLAN環境に展開することができます。
While deploying the PTA model in IPv6 WLAN environment, the Access Router is Layer 3 aware and it has to be upgraded to support IPv6. Since the Access Router terminates the PPP sessions initiated by the WLAN Host/Router, it has to support PPPoE with IPv6.
IPv6 WLAN環境でPTAモデルを展開する際、アクセスルーターはレイヤー3を認識しており、IPv6をサポートするためにアップグレードする必要があります。Accessルーターは、WLANホスト/ルーターによって開始されたPPPセッションを終了するため、IPv6でPPPOEをサポートする必要があります。
Figure 8.1.3.1 describes the PTA Model in IPv6 WLAN environment.
図8.1.3.1は、IPv6 WLAN環境のPTAモデルを説明しています。
Customer | Access Provider | Service Provider
Premise | |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
|---------------------------| +------+
PPP |AAA |
|Server|
+------+
Figure 8.1.3.1
図8.1.3.1
IPv6 is deployed in this scenario by upgrading the following devices to dual stack: WLAN Host, WLAN Router (if present), Access Router, and Edge Router.
IPv6は、次のデバイスをデュアルスタックにアップグレードすることにより、このシナリオに展開されます：WLANホスト、WLANルーター（存在する場合）、アクセスルーター、およびエッジルーター。
The addressing techniques described in Section 6.2.2.2 apply to the IPv6 WLAN PTA scenario as well.
セクション6.2.2.2で説明されているアドレス指定手法は、IPv6 WLAN PTAシナリオにも適用されます。
The routing techniques described in Section 6.2.2.3 apply to the IPv6 WLAN PTA scenario as well.
セクション6.2.2.3で説明されているルーティング手法は、IPv6 WLAN PTAシナリオにも適用されます。
While deploying the LAA model in IPv6 WLAN environment, the Access Router is Layer 3 aware and has to be upgraded to support IPv6. The PPP sessions initiated by the WLAN Host/Router are forwarded over the L2TPv2 tunnel to the aggregation point in the SP network. The Access Router must have the capability to support L2TPv2 for IPv6.
IPv6 WLAN環境でLAAモデルを展開する際、アクセスルーターはレイヤー3を認識しており、IPv6をサポートするためにアップグレードする必要があります。WLANホスト/ルーターによって開始されたPPPセッションは、L2TPV2トンネルを介してSPネットワークの集約点に転送されます。アクセスルーターには、IPv6のL2TPV2をサポートする機能が必要です。
Figure 8.1.3.2 describes the LAA Model in IPv6 WLAN environment.
図8.1.3.2は、IPv6 WLAN環境のLAAモデルを説明しています。
Customer | Access Provider | Service Provider
Premise | |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
|-------------------------------------------------- |
PPP |
|--------------------- |
L2TPv2 |
+------+
|AAA |
|Server|
+------+
Figure 8.1.3.2
図8.1.3.2
IPv6 is deployed in this scenario by upgrading the following devices to dual stack: WLAN Host, WLAN Router (if present), Access Router, and Edge Router.
IPv6は、次のデバイスをデュアルスタックにアップグレードすることにより、このシナリオに展開されます：WLANホスト、WLANルーター（存在する場合）、アクセスルーター、およびエッジルーター。
The addressing techniques described in Section 6.2.3.2 apply to the IPv6 WLAN LAA scenario as well.
セクション6.2.3.2で説明されているアドレス指定手法は、IPv6 WLAN LAAシナリオにも適用されます。
The routing techniques described in Section 6.2.3.3 apply to the IPv6 WLAN LAA scenario as well.
セクション6.2.3.3で説明されているルーティング手法は、IPv6 WLAN LAAシナリオにも適用されます。
The typical multicast services offered are video/audio streaming where the IPv6 WLAN Host joins a multicast group and receives the content. This type of service model is well supported through PIM-SSM, which is enabled throughout the SP network. MLDv2 is required for PIM-SSM support. Vendors can choose to implement features that allow routers to map MLDv1 group joins to predefined sources.
提供される典型的なマルチキャストサービスは、IPv6 WLANホストがマルチキャストグループに参加してコンテンツを受信するビデオ/オーディオストリーミングです。このタイプのサービスモデルは、SPネットワーク全体で有効になっているPIM-SSMを通じてよくサポートされています。MLDV2は、PIM-SSMサポートに必要です。ベンダーは、ルーターが事前定義されたソースに結合するMLDV1グループをマッピングできるようにする機能を実装することを選択できます。
It is important to note that in the shared wireless environments, multicast can have a significant bandwidth impact. For this reason, the bandwidth allocated to multicast traffic should be limited and fixed, based on the overall capacity of the wireless specification used in 802.11a, 802.11b, or 802.11g.
共有されたワイヤレス環境では、マルチキャストが帯域幅に大きな影響を与える可能性があることに注意することが重要です。このため、マルチキャストトラフィックに割り当てられた帯域幅は、802.11a、802.11b、または802.11gで使用されるワイヤレス仕様の全体的な容量に基づいて、制限および固定する必要があります。
The IPv6 WLAN Hosts can also join desired multicast groups as long as they are enabled to support MLDv1 or MLDv2. If WLAN/Access Routers are used, then they have to be enabled to support MLDv1 and MLDv2 in order to process the requests of the IPv6 WLAN Hosts. The WLAN/ Access Router also needs to be enabled to support PIM-SSM in order to send PIM joins up to the Edge Router. When enabling this functionality on a WLAN/Access Router, its limited resources should be taken into consideration. Another option would be for the WLAN/ Access Router to support MLD proxy routing.
IPv6 WLANホストは、MLDV1またはMLDV2をサポートできる限り、希望のマルチキャストグループに参加することもできます。WLAN/アクセスルーターを使用する場合、IPv6 WLANホストの要求を処理するためにMLDV1とMLDV2をサポートするために有効にする必要があります。WLAN/ Accessルーターは、PIM-SSMをサポートして、PIM結合をエッジルーターに送信するために有効にする必要があります。WLAN/Accessルーターでこの機能を有効にする場合、その限られたリソースを考慮する必要があります。別のオプションは、WLAN/ AccessルーターがMLDプロキシルーティングをサポートすることです。
The Edge Router has to be enabled to support MLDv1 and MLDv2 in order to process the requests coming from the IPv6 WLAN Host or WLAN/Access Router (if present). The Edge Router has also needs to be enabled for PIM-SSM in order to receive joins from IPv6 WLAN Hosts or WLAN/ Access Router (if present), and send joins towards the SP core.
Edgeルーターは、IPv6 WLANホストまたはWLAN/アクセスルーター（存在する場合）から来るリクエストを処理するために、MLDV1とMLDV2をサポートするために有効にする必要があります。Edgeルーターは、IPv6 WLANホストまたはWLAN/アクセスルーター（存在する場合）から結合を受信し、SPコアに合わせて結合を送信するために、PIM-SSMの有効化する必要があります。
MLD authentication, authorization, and accounting are usually configured on the Edge Router in order to enable the SP to do billing for the content services provided. Further investigation should be made in finding alternative mechanisms that would support these functions.
MLD認証、承認、および会計は、通常、SPが提供されるコンテンツサービスの請求を行うことができるように、Edgeルーターで構成されます。これらの機能をサポートする代替メカニズムを見つける際に、さらなる調査を行う必要があります。
Concerns have been raised in the past related to running IPv6 multicast over WLAN links. Potentially these are the same kind of issues when running any Layer 3 protocol over a WLAN link that has a high loss-to-signal ratio, where certain frames that are multicast based are dropped when settings are not adjusted properly. For instance, this behavior is similar to an IGMP host membership report, when done on a WLAN link with a high loss-to-signal ratio and high interference.
WLANリンクを介したIPv6マルチキャストの実行に関連する過去に懸念が提起されました。潜在的に、これらは、ゼロとシグナルの比率が高いWLANリンク上でレイヤー3プロトコルを実行する場合と同じ種類の問題であり、マルチキャストベースの特定のフレームが設定が適切に調整されていないときに削除されます。たとえば、この動作は、LOSとシグナルの比率が高い干渉と高い干渉を伴うWLANリンクで行われた場合、IGMPホストメンバーシップレポートに似ています。
This problem is inherited by WLAN that can impact both IPv4 and IPv6 multicast packets; it is not specific to IPv6 multicast.
この問題は、IPv4とIPv6マルチキャストパケットの両方に影響を与える可能性のあるWLANによって継承されています。IPv6マルチキャストに固有のものではありません。
While deploying WLAN (IPv4 or IPv6), one should adjust their broadcast/multicast settings if they are in danger of dropping application dependent frames. These problems are usually caused when the AP is placed too far (not following the distance limitations), high interference, etc. These issues may impact a real multicast application such as streaming video or basic operation of IPv6 if the frames were dropped. Basic IPv6 communications uses functions such as Duplicate Address Detection (DAD), Router and Neighbor Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA), etc., which could be impacted by the above mentioned issues as these frames are Layer 2 Ethernet multicast frames.
WLAN（IPv4またはIPv6）の展開中に、アプリケーションに依存するフレームを削除する危険がある場合は、ブロードキャスト/マルチキャスト設定を調整する必要があります。これらの問題は通常、APがあまりにも遠くに配置されている場合（距離制限に従わない）、高い干渉などを引き起こします。これらの問題は、フレームがドロップされた場合、ストリーミングビデオやIPv6の基本操作などの実際のマルチキャストアプリケーションに影響を与える可能性があります。基本的なIPv6通信は、Duplicate Address Detection（DAD）、RouterおよびNeighbor Solications（RS、NS）、RouterおよびNeighbor Advertisement（RA、NA）などの関数を使用します。レイヤー2イーサネットマルチキャストフレーム。
Please refer to Section 6.3 for more IPv6 multicast details.
IPv6マルチキャストの詳細については、セクション6.3を参照してください。
Today, QoS is done outside of the WiFi domain, but it is nevertheless important to the overall deployment.
今日、QosはWiFiドメインの外で行われていますが、それでも全体的な展開にとって重要です。
The QoS configuration is particularly relevant on the Edge Router in order to manage resources shared amongst multiple subscribers possibly with various service level agreements (SLAs). However, the WLAN Host/Router and Access Router could also be configured for QoS. This includes support for appropriate classification criteria, which would need to be implemented for IPv6 unicast and multicast traffic.
QoS構成は、おそらくさまざまなサービスレベル契約（SLA）で複数のサブスクライバー間で共有されるリソースを管理するために、特にEdgeルーターに関連しています。ただし、WLANホスト/ルーターとアクセスルーターもQoS用に構成できます。これには、IPv6ユニキャストおよびマルチキャストトラフィックに実装する必要がある適切な分類基準のサポートが含まれます。
On the Edge Router, the subscriber-facing interfaces have to be configured to police the inbound customer traffic and shape the traffic outbound to the customer, based on the SLA. Traffic classification and marking should also be done on the Edge Router in order to support the various types of customer traffic: data, voice, and video. The same IPv4 QoS concepts and methodologies should be applied for the IPv6 as well.
Edgeルーターでは、サブスクライバー向けインターフェイスを設定する必要があります。インバウンド顧客のトラフィックを締結し、SLAに基づいて顧客にトラフィックを形作る必要があります。さまざまな種類の顧客トラフィック（データ、音声、ビデオ）をサポートするために、トラフィックの分類とマーキングもエッジルーターで行う必要があります。同じIPv4 QoSの概念と方法論もIPv6にも適用する必要があります。
It is important to note that when traffic is encrypted end-to-end, the traversed network devices will not have access to many of the packet fields used for classification purposes. In these cases, routers will most likely place the packets in the default classes. The QoS design should take into consideration this scenario and try to use mainly IP header fields for classification purposes.
トラフィックがエンドツーエンドで暗号化されている場合、トラバースされたネットワークデバイスは分類に使用されるパケットフィールドの多くにアクセスできないことに注意することが重要です。これらの場合、ルーターはおそらくパケットをデフォルトのクラスに配置します。QoS設計では、このシナリオを考慮し、分類目的で主にIPヘッダーフィールドを使用しようとする必要があります。
There are limited changes that have to be done for WLAN the Host/ Router in order to enhance security. The privacy extensions [RFC3041] for auto-configuration should be used by the hosts with the same consideration for host traceability as described in Section 6.5. IPv6 firewall functions should be enabled on the WLAN Host/Router, if present.
セキュリティを強化するために、ホスト/ルーターをWLANに行う必要がある限られた変更があります。セクション6.5で説明されているように、ホストのトレーサビリティについて同じ考慮事項で、自動構成のプライバシー拡張[RFC3041]は、ホストが使用する必要があります。IPv6ファイアウォール機能は、存在する場合はWLANホスト/ルーターで有効にする必要があります。
The ISP provides security against attacks that come from its own subscribers, but it could also implement security services that protect its subscribers from attacks sourced from outside its network. Such services do not apply at the access level of the network discussed here.
ISPは、独自の加入者から生じる攻撃に対するセキュリティを提供しますが、ネットワークの外部から供給された攻撃から加入者を保護するセキュリティサービスを実装することもできます。このようなサービスは、ここで説明するネットワークのアクセスレベルでは適用されません。
If the host authentication at hotspots is done using a web-based authentication system, then the level of security would depend on the particular implementation. User credentials should never be sent as clear text via HTTP. Secure HTTP (HTTPS) should be used between the web browser and authentication server. The authentication server could use RADIUS and LDAP services at the back end.
ホットスポットでのホスト認証がWebベースの認証システムを使用して行われた場合、セキュリティのレベルは特定の実装に依存します。ユーザー資格情報は、HTTPを介して明確なテキストとして送信されないでください。Secure HTTP（HTTPS）は、Webブラウザーと認証サーバーの間で使用する必要があります。認証サーバーは、バックエンドでRADIUSおよびLDAPサービスを使用できます。
Authentication is an important aspect of securing WLAN networks prior to implementing Layer 3 security policies. For example, this would help avoid threats to the ND or stateless auto-configuration processes. 802.1x [IEEE8021X] provides the means to secure the network access; however, the many types of EAP (PEAP, EAP-TLS, EAP-TTLS, EAP-FAST, and LEAP) and the capabilities of the hosts to support some of the features might make it difficult to implement a comprehensive and consistent policy.
認証は、レイヤー3セキュリティポリシーを実装する前に、WLANネットワークを保護する重要な側面です。たとえば、これは、NDまたはステートレスの自動構成プロセスに対する脅威を回避するのに役立ちます。802.1x [IEEE8021X]は、ネットワークアクセスを保護する手段を提供します。ただし、多くのタイプのEAP（PEAP、EAP-TLS、EAP-TTLS、EAP-FAST、LEAP）とホストの機能の一部をサポートする機能により、包括的で一貫したポリシーを実装することが難しくなる可能性があります。
The 802.11i [IEEE80211i] amendment has many components, the most obvious of which are the two new data-confidentiality protocols, Temporal Key Integrity Protocol (TKIP) and Counter-Mode/CBC-MAC Protocol (CCMP). 802.11i also uses 802.1X's key-distribution system to control access to the network. Because 802.11 handles unicast and broadcast traffic differently, each traffic type has different security concerns. With several data-confidentiality protocols and the key distribution, 802.11i includes a negotiation process for selecting the correct confidentiality protocol and key system for each traffic type. Other features introduced include key caching and pre-authentication.
802.11i [IEEE80211i]修正には多くのコンポーネントがあり、その中で最も明白なのは、2つの新しいデータ自信プロトコル、時間的キーインテグリティプロトコル（TKIP）、およびカウンターモード/CBC-MACプロトコル（CCMP）です。802.11iは、802.1xのキーディストリビューションシステムも使用して、ネットワークへのアクセスを制御します。802.11はユニキャストと放送トラフィックを異なる方法で処理し、各トラフィックタイプには異なるセキュリティの懸念があります。いくつかのデータ自信プロトコルと主要な分布により、802.11iには、各トラフィックタイプの正しい機密性プロトコルとキーシステムを選択するためのネゴシエーションプロセスが含まれています。導入されたその他の機能には、重要なキャッシュと事前認証が含まれます。
The 802.11i amendment is a step forward in wireless security. The amendment adds stronger encryption, authentication, and key management strategies that could make wireless data and systems more secure.
802.11iの修正は、ワイヤレスセキュリティの一歩前進です。この修正は、ワイヤレスデータとシステムをより安全にする可能性のあるより強力な暗号化、認証、および主要な管理戦略を追加します。
If any Layer 2 filters for Ethertypes are in place, the NAP must permit the IPv6 Ethertype (0X86DD).
Ethertypesのレイヤー2フィルターが整っている場合、NAPはIPv6 EtherType（0x86DD）を許可する必要があります。
The device that is the Layer 3 next hop for the subscribers (Access or Edge Router) should protect the network and the other subscribers against attacks by one of the provider customers. For this reason uRPF and ACLs should be used on all interfaces facing subscribers. Filtering should be implemented with regard for the operational requirements of IPv6 [IPv6-Security].
次にレイヤー3であるデバイスは、サブスクライバー（アクセスまたはエッジルーター）のためのホップに、プロバイダーの顧客のいずれかによる攻撃からネットワークと他のサブスクライバーを保護する必要があります。このため、URPFとACLは、サブスクライバーに直面しているすべてのインターフェイスで使用する必要があります。IPv6 [IPv6-Security]の運用要件に関して、フィルタリングを実装する必要があります。
The Access and the Edge Router should protect their processing resources against floods of valid customer control traffic such as: RS, NS, and MLD Requests. Rate limiting should be implemented on all subscriber-facing interfaces. The emphasis should be placed on multicast-type traffic, as it is most often used by the IPv6 control plane.
アクセスとエッジルーターは、RS、NS、MLDリクエストなどの有効な顧客制御トラフィックの洪水から処理リソースを保護する必要があります。レート制限は、すべての加入者向けインターフェイスに実装する必要があります。IPv6コントロールプレーンで最もよく使用されるため、マルチキャストタイプのトラフィックに重点を置く必要があります。
The necessary instrumentation (such as MIB modules, NetFlow Records, etc) should be available for IPv6.
IPv6では、必要な計装（MIBモジュール、Netflow Recordsなど）を利用できる必要があります。
Usually, NSPs manage the edge routers by SNMP. The SNMP transport can be done over IPv4 if all managed devices have connectivity over both IPv4 and IPv6. This would imply the smallest changes to the existing network management practices and processes. Transport over IPv6 could also be implemented and it might become necessary if IPv6 only islands are present in the network. The management applications may be running on hosts belonging to the NSP core network domain. Network Management Applications should handle IPv6 in a similar fashion to IPv4; however, they should also support features specific to IPv6 (such as neighbor monitoring).
通常、NSPはSNMPでエッジルーターを管理します。すべてのマネージドデバイスがIPv4とIPv6の両方に接続されている場合、SNMPトランスポートはIPv4で実行できます。これは、既存のネットワーク管理のプラクティスとプロセスに対する最小の変更を意味します。IPv6を介した輸送も実装でき、IPv6のみの島がネットワークに存在する場合が必要になる場合があります。管理アプリケーションは、NSPコアネットワークドメインに属するホストで実行されている場合があります。ネットワーク管理アプリケーションは、IPv4と同様の方法でIPv6を処理する必要があります。ただし、IPv6に固有の機能（近隣監視など）もサポートする必要があります。
In some cases, service providers manage equipment located on customers' LANs.
場合によっては、サービスプロバイダーは顧客のLANにある機器を管理します。
This section describes the IPv6 deployment in Power Line Communications (PLC) Access Networks. There may be other choices, but it seems that this is the best model to follow. Lessons learnt from cable, Ethernet, and even WLAN access networks may be applicable also.
このセクションでは、電力線通信（PLC）アクセスネットワークにおけるIPv6展開について説明します。他の選択肢があるかもしれませんが、これは従うのに最適なモデルのようです。ケーブル、イーサネット、さらにはWLANアクセスネットワークから学んだ教訓も適用できます。
Power Line Communications are also often called Broadband Power Line (BPL) and sometimes even Power Line Telecommunications (PLT).
電力線通信は、しばしばブロードバンド電力線（BPL）と呼ばれ、時には電力線通信（PLT）さえ呼ばれます。
PLC/BPL can be used for providing, with today's technology, up to 200Mbps (total, upstream+downstream) by means of the power grid. The coverage is often the last half mile (typical distance from the medium-to-low voltage transformer to the customer premise meter) and, of course, as an in-home network (which is out of the scope of this document).
PLC/BPLは、今日のテクノロジーを使用して、電力網を使用して最大200mbps（合計、上流の下流）を提供するために使用できます。カバレッジは、多くの場合、最後の半マイル（中程度から低い電圧変圧器から顧客の前提メーターまでの一般的な距離）であり、もちろん、在宅ネットワーク（このドキュメントの範囲外）としてです。
The bandwidth in a given PLC/BPL segment is shared among all the customers connected to that segment (often the customers connected to the same medium-to-low voltage transformer). The number of customers can vary depending on different factors, such as distances and even countries (from a few customers, just 5-6, up to 100-150).
特定のPLC/BPLセグメントの帯域幅は、そのセグメントに接続されているすべての顧客の間で共有されます（多くの場合、顧客は同じ中程度の電圧変圧器に接続されています）。顧客の数は、距離や国などの要因によって異なる場合があります（少数の顧客から、わずか5〜6、最大100〜150まで）。
PLC/BPL could also be used in the medium voltage network (often configured as Metropolitan Area Networks), but this is also out of the scope of this document, as it will be part of the core network, not the access one.
PLC/BPLは、中電圧ネットワーク（多くの場合、メトロポリタンエリアネットワークとして構成されている）で使用できますが、これはアクセスネットワークではなくコアネットワークの一部になるため、このドキュメントの範囲外でもあります。
This section describes the different elements commonly used in PLC/ BPL access networks.
このセクションでは、PLC/ BPLアクセスネットワークで一般的に使用されるさまざまな要素について説明します。
Head End (HE): Router that connects the PLC/BPL access network (the power grid), located at the medium-to-low voltage transformer, to the core network. The HE PLC/BPL interface appears to each customer as a single virtual interface, all of them sharing the same physical media.
ヘッドエンド（HE）：中程度から低い電圧変圧器にあるPLC/BPLアクセスネットワーク（電源グリッド）をコアネットワークに接続するルーター。He PLC/BPLインターフェイスは、各顧客に単一の仮想インターフェイスとして表示され、すべてが同じ物理メディアを共有しています。
Repeater (RPT): A device that may be required in some circumstances to improve the signal on the PLC/BPL. This may be the case if there are many customers in the same segment or building. It is often a bridge, but it could also be a router if, for example, there is a lot of peer-to-peer traffic in a building and due to the master-slave nature of the PLC/BPL technology, is required to improve the performance within that segment. For simplicity within this document, the RPT will always be considered a transparent Layer 2 bridge, so it may or may not be present (from the Layer 3 point of view).
リピーター（RPT）：PLC/BPLの信号を改善するために状況によって必要なデバイス。これは、同じセグメントまたは建物に多くの顧客がいる場合に当てはまります。多くの場合、それは橋ですが、たとえば、建物にピアツーピアのトラフィックがたくさんあり、PLC/BPLテクノロジーのマスタースレーブの性質のために、ピアツーピアからピアへのトラフィックがたくさんある場合、ルーターになる可能性もあります。そのセグメント内のパフォーマンスを改善します。このドキュメント内の簡単にするために、RPTは常に透明レイヤー2ブリッジと見なされるため、存在する場合と存在しない場合があります（レイヤー3の観点から）。
Customer Premise Equipment (CPE): Modem (internal to the host), modem/bridge (BCPE), router (RCPE), or any combination among those (i.e., modem+bridge/router), located at the customer premise.
顧客前提機器（CPE）：モデム（ホストの内部）、モデム/ブリッジ（BCPE）、ルーター（RCPE）、またはそれらの任意の組み合わせ（つまり、モデムブリッジ/ルーター）、顧客の施設にあります。
Edge Router (ER)
エッジルーター（ER）
Figure 9.1 depicts all the network elements indicated above.
図9.1は、上記のすべてのネットワーク要素を示しています。
Customer Premise | Network Access Provider | Network Service Provider
顧客の前提|ネットワークアクセスプロバイダー|ネットワークサービスプロバイダー
+-----+ +------+ +-----+ +------+ +--------+
|Hosts|--| RCPE |--| RPT |--------+ Head +---+ Edge | ISP
+-----+ +------+ +-----+ | End | | Router +=>Network
+--+---+ +--------+
+-----+ +------+ +-----+ |
|Hosts|--| BCPE |--| RPT |-----------+
+-----+ +------+ +-----+
Figure 9.1
図9.1
The logical topology and design of PLC/BPL is very similar to Ethernet Broadband Networks as discussed in Section 7. IP connectivity is typically provided in a Point-to-Point model, as described in Section 7.2.1
PLC/BPLの論理トポロジと設計は、セクション7で説明したように、イーサネットブロードバンドネットワークと非常に似ています。IP接続性は、セクション7.2.1で説明されているように、ポイントツーポイントモデルで提供されます。
The most simplistic and efficient model, considering the nature of the PLC/BPL networks, is to see the network as a point-to-point, one to each customer. Even if several customers share the same physical media, the traffic is not visible among them because each one uses different channels, which are, in addition, encrypted by means of 3DES.
PLC/BPLネットワークの性質を考慮して、最も単純で効率的なモデルは、ネットワークを各顧客にとってポイントツーポイントと見なすことです。いくつかの顧客が同じ物理メディアを共有していても、それぞれが3DEによって暗号化される異なるチャネルを使用するため、トラフィックはそれらの間で表示されません。
In order to maintain the deployment concepts and business models proven and used with existing revenue-generating IPv4 services, the IPv6 deployment will match the IPv4 one. Under certain circumstances where new service types or service needs justify it, IPv4 and IPv6 network architectures could be different. Both approaches are very similar to those already described for the Ethernet case.
展開の概念とビジネスモデルを維持するために、既存の収益を生み出すIPv4サービスで実証および使用されるため、IPv6の展開はIPv4の展開と一致します。新しいサービスタイプまたはサービスが必要な特定の状況では、IPv4とIPv6ネットワークアーキテクチャが異なる可能性があります。どちらのアプローチも、イーサネットの場合にすでに説明されているアプローチと非常に似ています。
In this scenario, only the RPT is Layer 3 unaware, but the other devices have to be upgraded to dual stack Hosts, RCPE, Head End, and Edge Router.
このシナリオでは、RPTのみがレイヤー3を認識していませんが、他のデバイスはデュアルスタックホスト、RCPE、ヘッドエンド、およびエッジルーターにアップグレードする必要があります。
The Hosts or the RCPEs have the HE as their Layer 3 next hop.
ホストまたはRCPEは、HEをレイヤー3次のホップとして持っています。
If there is no RCPE, but instead a BCPE, all the hosts on the subscriber site belong to the same /64 subnet that is statically configured on the HE. The hosts can use stateless auto-configuration or stateful DHCPv6-based configuration to acquire an address via the HE.
RCPEがないが、代わりにBCPEである場合、サブスクライバーサイトのすべてのホストは、HEで静的に構成されている同じ /64サブネットに属します。ホストは、Stateless Auto ConfigurationまたはStateful DHCPV6ベースの構成を使用して、HEを介して住所を取得できます。
If an RCPE is present:
RCPEが存在する場合：
A. It is statically configured with an address on the /64 subnet between itself and the HE, and with /64 prefixes on the interfaces connecting the hosts on the customer site. This is not a desired provisioning method, being expensive and difficult to manage.
A.それは、それ自体とHeの間の /64サブネットのアドレスと、顧客サイトのホストを接続するインターフェイス上の /64プレフィックスで静的に構成されています。これは望ましいプロビジョニング方法ではなく、高価で管理が困難です。
B. It can use its link-local address to communicate with the HE. It can also dynamically acquire through stateless auto-configuration the address for the link between itself and the HE. This step is followed by a request via DHCP-PD for a prefix shorter than /64 (typically /48 [RFC3177]) that, in turn, is divided in /64s and assigned to its interfaces connecting the hosts on the customer site. This should be the preferred provisioning method, being cheaper and easier to manage.
B.リンクローカルアドレスを使用して、HEと通信できます。また、ステートレスの自動構成を通じて、それ自体と彼との間のリンクのアドレスを動的に取得することができます。このステップの後に、 /64より短い接頭辞（通常 /48 [RFC3177]）のDHCP-PDを介したリクエストが続き、顧客サイトのホストを接続するインターフェイスに割り当てられ、その後、顧客サイトのホストを接続するインターフェイスに割り当てられます。これは、より安価で管理が容易である優先プロビジョニング方法である必要があります。
The Edge Router needs to have a prefix, considering that each customer in general will receive a /48 prefix, and that each HE will accommodate customers. Consequently, each HE will require n x /48 prefixes.
Edgeルーターには、各顧客が一般的にA /48プレフィックスを受け取ること、そしてそれぞれが顧客に対応することを考慮して、プレフィックスが必要です。その結果、それぞれがn x /48プレフィックスが必要になります。
It could be possible to use a kind of Hierarchical Prefix Delegation to automatically provision the required prefixes and fully auto-configure the HEs, and consequently reduce the network setup, operation, and maintenance cost.
一種の階層的プレフィックス委任を使用して、必要なプレフィックスを自動的にプロビジョニングし、HESを完全に自動構成し、その結果、ネットワークのセットアップ、操作、およびメンテナンスコストを削減することができます。
The prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows as much summarization as possible at the Edge Router.
サブスクライバーリンクに使用されるプレフィックスとDHCP-PDを介して委任されたプレフィックスは、エッジルーターでできるだけ多くの要約を許可する方法で計画する必要があります。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
DNSなどのホストにとって関心のある他の情報は、Stateful [RFC3315]およびStateless [RFC3736] DHCPV6を通じて提供されます。
If no routers are used on the customer premise, the HE can simply be configured with a default route that points to the Edge Router. If a router is used on the customer premise (RCPE), then the HE could also run an IGP (such as OSPFv3, IS-IS or even RIPng) to the ER. The connected prefixes should be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the HE. For this reason, the static routes must also be redistributed. Prefix summarization should be done at the HE.
顧客の前提でルーターが使用されていない場合、Edgeルーターを指すデフォルトルートで彼は単純に構成できます。ルーターが顧客の前提（RCPE）で使用されている場合、彼はERにIGP（OSPFV3、IS-IS、さらにはRIPNGなど）を実行することもできます。接続されたプレフィックスを再配布する必要があります。DHCP-PDが使用されている場合、すべての委任された接頭辞を使用して、HEによって静的ルートがインストールされます。このため、静的ルートも再配布する必要があります。プレフィックスの要約は、HEで行う必要があります。
The RCPE requires only a default route pointing to the HE. No routing protocols are needed on these devices, which generally have limited resources.
RCPEには、HEを指すデフォルトルートのみが必要です。これらのデバイスでは、通常はリソースが限られているルーティングプロトコルは必要ありません。
The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. The connected prefixes have to be redistributed, as well as any routing protocols (other than the ones used on the ER) that might be used between the HE and the ER.
エッジルーターは、NSP：OSPFV3またはIS-ISで使用されるIPv6 IGPを実行します。接続されたプレフィックスは、HEとERの間で使用される可能性のあるルーティングプロトコル（ERで使用されているもの以外）を再配布する必要があります。
The considerations regarding IPv6 Multicast for Ethernet are also applicable here, in general, assuming the nature of PLC/BPL is a shared media. If a lot of Multicast is expected, it may be worth considering using RPT which are Layer 3 aware. In that case, one extra layer of Hierarchical DHCP-PD could be considered, in order to facilitate the deployment, operation, and maintenance of the network.
イーサネット用のIPv6マルチキャストに関する考慮事項も、PLC/BPLの性質が共有メディアであると仮定して、ここでも適用されます。多くのマルチキャストが予想される場合、レイヤー3を認識しているRPTを使用することを検討する価値があります。その場合、ネットワークの展開、操作、およびメンテナンスを容易にするために、階層的なDHCP-PDの1つの余分な層を考慮することができます。
The considerations introduced for QoS in Ethernet are also applicable here. PLC/BPL networks support QoS, which basically is the same whether the transport is IPv4 or IPv6. It is necessary to understand that there are specific network characteristics, such as the variability that may be introduced by electrical noise, towards which the PLC/BPL network will automatically self-adapt.
イーサネットでQoSに導入された考慮事項もここに適用されます。PLC/BPLネットワークはQOSをサポートします。これは、輸送がIPv4であるかIPv6であろうと同じです。PLC/BPLネットワークが自動的に自己適応する電気ノイズによって導入される可能性のある変動など、特定のネットワーク特性があることを理解する必要があります。
There are no differences in terms of security considerations if compared with the Ethernet case.
イーサネットの場合と比較した場合、セキュリティ上の考慮事項に関して違いはありません。
The issues related to IPv6 Network Management in PLC networks should be similar to those discussed for Broadband Ethernet Networks in Section 7.6. Note that there may be a need to define MIB modules for PLC networks and interfaces, but this is not necessarily related to IPv6 management.
PLCネットワークのIPv6ネットワーク管理に関連する問題は、セクション7.6のブロードバンドイーサネットネットワークについて説明した問題と類似する必要があります。PLCネットワークとインターフェイスのMIBモジュールを定義する必要があるかもしれませんが、これは必ずしもIPv6管理に関連しているわけではありません。
Several aspects of deploying IPv6 over SP Broadband networks were highlighted in this document, aspects that require additional work in order to facilitate native deployments, as summarized below:
このドキュメントでは、SPブロードバンドネットワークを介してIPv6を展開するいくつかの側面が強調表示されました。これは、以下に要約されるように、ネイティブの展開を容易にするために追加の作業を必要とする側面です。
A. As mentioned in section 5, changes will need to be made to the DOCSIS specification in order for SPs to deploy native IPv6 over cable networks. The CM and CMTS will both need to support IPv6 natively in order to forward IPv6 unicast and multicast traffic. This is required for IPv6 Neighbor Discovery to work over DOCSIS cable networks. Additional classifiers need to be added to the DOCSIS specification in order to classify IPv6 traffic at the CM and CMTS in order to provide QoS. These issues are addressed in a recent proposal made to Cable Labs for DOCSIS 3.0 [DOCSIS3.0-Reqs].
A.セクション5で述べたように、SPSがケーブルネットワーク上にネイティブIPv6を展開するためには、DOCSIS仕様に変更を加える必要があります。CMとCMTSは、IPv6ユニキャストとマルチキャストトラフィックを転送するために、IPv6をネイティブにサポートする必要があります。これは、IPv6 Neighbor DiscoveryがDocSISケーブルネットワークを介して動作するために必要です。QoSを提供するために、CMおよびCMTSでIPv6トラフィックを分類するために、追加の分類器をDOCSIS仕様に追加する必要があります。これらの問題は、DOCSIS 3.0 [DocSIS3.0-Reqs]のケーブルラボに対する最近の提案で対処されています。
B. Section 6 stated that current RBE-based IPv4 deployment might not be the best approach for IPv6, where the addressing space available gives the SP the opportunity to separate the users on different subnets. The differences between IPv4 RBE and IPv6 RBE were highlighted in Section 6. If, however, support and reason are found for a deployment similar to IPv4 RBE, then the environment becomes NBMA and the new feature should observe RFC2491 recommendations.
B.セクション6は、現在のRBEベースのIPv4展開はIPv6にとって最良のアプローチではない可能性があると述べました。ここでは、利用可能なアドレス指定スペースにより、SPがユーザーを異なるサブネットで分離する機会が与えられます。IPv4 RBEとIPv6 RBEの違いは、セクション6で強調表示されました。ただし、IPv4 RBEと同様の展開のサポートと理由が見つかった場合、環境はNBMAになり、新機能はRFC2491の推奨事項を観察する必要があります。
C. Section 6 discussed the constraints imposed on an LAA-based IPv6 deployment by the fact that it is expected that the subscribers keep their assigned prefix, regardless of LNS. A deployment approach was proposed that would maintain the addressing schemes contiguous and offers prefix summarization opportunities. The topic could be further investigated for other solutions or improvements.
C.セクション6では、LNSに関係なく、加入者が割り当てられたプレフィックスを維持することが予想されるという事実により、LAAベースのIPv6展開に課される制約について説明しました。アドレス指定スキームを連続して維持し、プレフィックスの要約の機会を提供する展開アプローチが提案されました。このトピックは、他のソリューションや改善についてさらに調査できます。
D. Sections 6 and 7 pointed out the limitations (previously documented in [IPv6-Multicast]) in deploying inter-domain ASM; however, SSM-based services seem more likely at this time. For such SSM-based services of content delivery (video or audio), mechanisms are needed to facilitate the billing and management of listeners. The currently available feature of MLD AAA is suggested; however, other methods or mechanisms might be developed and proposed.
D.セクション6および7では、ドメイン間ASMの展開における制限（以前は[IPv6-Multicast]で文書化された）を指摘しました。ただし、現時点ではSSMベースのサービスが可能性が高いようです。このようなSSMベースのコンテンツ配信サービス（ビデオまたはオーディオ）の場合、リスナーの請求と管理を促進するためにメカニズムが必要です。MLD AAAの現在利用可能な機能を提案します。ただし、他の方法またはメカニズムが開発および提案される場合があります。
E. In relation to Section 8, concerns have been raised related to running IPv6 multicast over WLAN links. Potentially, these are the same kind of issues when running any Layer 3 protocol over a WLAN link that has a high loss-to-signal ratio; certain frames that are multicast based are dropped when settings are not adjusted properly. For instance this behavior is similar to an IGMP host membership report, when done on a WLAN link with high loss-to-signal ratio and high interference. This problem is inherited by WLAN that can impact both IPv4 and IPv6 multicast packets; it is not specific to IPv6 multicast.
E.セクション8に関連して、WLANリンクを介したIPv6マルチキャストの実行に関連する懸念が提起されています。潜在的に、これらは、副号とシグナルの比率が高いWLANリンクを介してレイヤー3プロトコルを実行する場合と同じ種類の問題です。マルチキャストベースの特定のフレームは、設定が適切に調整されていない場合に削除されます。たとえば、この動作は、高い損失とシグナルの比率と高い干渉を伴うWLANリンクで行われた場合、IGMPホストメンバーシップレポートに似ています。この問題は、IPv4とIPv6マルチキャストパケットの両方に影響を与える可能性のあるWLANによって継承されています。IPv6マルチキャストに固有のものではありません。
F. The privacy extensions were mentioned as a popular means to provide some form of host security. ISPs can track relatively easily the prefixes assigned to subscribers. If, however, the ISPs are required by regulations to track their users at host address level, the privacy extensions [RFC3041] can be implemented only in parallel with network management tools that could provide traceability of the hosts. Mechanisms should be defined to implement this aspect of user management.
F.プライバシー拡張は、何らかの形のホストセキュリティを提供するための一般的な手段として言及されました。ISPは、加入者に割り当てられたプレフィックスを比較的簡単に追跡できます。ただし、ISPがホストアドレスレベルでユーザーを追跡するために規制で必要な場合、プライバシー拡張[RFC3041]は、ホストのトレーサビリティを提供できるネットワーク管理ツールと並行してのみ実装できます。メカニズムは、ユーザー管理のこの側面を実装するために定義する必要があります。
G. Tunnels are an effective way to avoid deployment dependencies on the IPv6 support on platforms that are out of the SP control (GWRs or CPEs) or over technologies that did not standardize the IPv6 support yet (cable). They can be used in the following ways:
G.トンネルは、SPコントロール（GWRまたはCPES）またはまだIPv6サポートを標準化していないテクノロジー（ケーブル）のテクノロジーを超えるプラットフォーム上のIPv6サポートの展開依存関係を回避する効果的な方法です。次の方法で使用できます。
i. Tunnels directly to the CPE or GWR with public or private IPv4 addresses.
i. パブリックまたはプライベートIPv4アドレスを使用して、CPEまたはGWRに直接トンネル。
ii. Tunnels directly to hosts with public or private IPv4 addresses. Recommendations on the exact tunneling mechanisms that can/should be used for last-mile access need to be investigated further and should be addressed by the IETF Softwire Working Group.
ii。パブリックまたはプライベートIPv4アドレスを持つホストに直接トンネル。ラストマイルアクセスに使用できる/使用する必要がある正確なトンネルメカニズムに関する推奨事項は、さらに調査する必要があり、IETF Softwireワーキンググループで対処する必要があります。
H. Through its larger address space, IPv6 allows SPs to assign fixed, globally routable prefixes to the links connecting each subscriber.
H.より大きなアドレススペースを通じて、IPv6を使用すると、SPSは、各サブスクライバーを接続するリンクに固定されたグローバルなルーティング可能なプレフィックスを割り当てることができます。
This approach changes the provisioning methodologies that were used for IPv4. Static configuration of the IPv6 addresses for all these links on the Edge Routers or Access Routers might not be a scalable option. New provisioning mechanisms or features might need to be developed in order to deal with this issue, such as automatic mapping of VLAN IDs/PVCs (or other customer-specific information) to IPv6 prefixes.
このアプローチは、IPv4に使用されたプロビジョニング方法を変更します。エッジルーターまたはアクセスルーターのこれらすべてのリンクのIPv6アドレスの静的構成は、スケーラブルなオプションではない場合があります。VLAN ID/PVC（またはその他の顧客固有の情報）のIPv6プレフィックスへの自動マッピングなど、この問題に対処するために、新しいプロビジョニングメカニズムまたは機能を開発する必要がある場合があります。
I. New deployment models are emerging for the Layer 2 portion of the NAP where individual VLANs are not dedicated to each subscriber. This approach allows Layer 2 switches to aggregate more then 4096 users. MAC Forced Forwarding [RFC4562] is an example of such an implementation, where a broadcast domain is turned into an NBMA-like environment by forwarding the frames based on both Source and Destination MAC addresses. Since these models are being adopted by the field, the implications of deploying IPv6 in such environments need to be further investigated.
I.個々のVLANが各サブスクライバー専用のNAPのレイヤー2部分には、新しい展開モデルが出現しています。このアプローチにより、レイヤー2スイッチは4096人以上のユーザーを集計します。MAC強制転送[RFC4562]は、ソースと宛先MACアドレスの両方に基づいてフレームを転送することにより、ブロードキャストドメインがNBMAのような環境に変換されるこのような実装の例です。これらのモデルはこの分野で採用されているため、このような環境でIPv6を展開することの意味をさらに調査する必要があります。
J. The deployment of IPv6 in continuously evolving access service models raises some issues that may need further investigation. Examples of such topics are [AUTO-CONFIG]:
J.継続的に進化するアクセスサービスモデルにおけるIPv6の展開は、さらなる調査が必要ないくつかの問題を提起します。このようなトピックの例は[autoconfig]です。
i. Network Service Selection & Authentication (NSSA) mechanisms working in association with stateless auto-configuration. As an example, NSSA relevant information, such as ISP preference, passwords, or profile ID, can be sent by hosts with the RS [RFC4191].
i. ネットワークサービスの選択と認証（NSSA）ステートレスの自動構成に関連して機能するメカニズム。例として、ISPの嗜好、パスワード、プロファイルIDなどのNSSA関連情報は、RS [RFC4191]でホストによって送信できます。
ii. Providing additional information in Router Advertisements to help access nodes with prefix selection in multi-ISP/ multi-homed environments.
ii。ルーター広告で追加情報を提供して、マルチISP/マルチホーム環境でのプレフィックス選択を備えたノードにアクセスするのに役立ちます。
Solutions to some of these topics range from making a media access capable of supporting native IPv6 (cable) to improving operational aspects of native IPv6 deployments.
これらのトピックのいくつかのソリューションは、ネイティブIPv6（ケーブル）をサポートできるメディアアクセスの作成から、ネイティブIPv6の展開の運用的側面の改善にまで及びます。
Please refer to the individual "IPv6 Security Considerations" technology sections for details.
詳細については、個々の「IPv6セキュリティに関する考慮事項」テクノロジーセクションを参照してください。
We would like to thank Brian Carpenter, Patrick Grossetete, Toerless Eckert, Madhu Sudan, Shannon McFarland, Benoit Lourdelet, and Fred Baker for their valuable comments. The authors would like to acknowledge the structure and information guidance provided by the work of Mickles, et al., on "Transition Scenarios for ISP Networks" [ISP-CASES].
ブライアン・カーペンター、パトリック・グロッセット、トアーレス・エッカート、マドゥ・スーダン、シャノン・マクファーランド、ブノワ・ルルデレット、フレッド・ベイカーの貴重なコメントに感謝します。著者は、「ISPネットワークの遷移シナリオ」[ISP-Cases]に関するMicklesなどの作業によって提供された構造と情報ガイダンスを認めたいと考えています。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC2080] Malkin、G。およびR. Minnear、「RIPNG for IPv6」、RFC 2080、1997年1月。
[RFC2364] Gross, G., Kaycee, M., Lin, A., Malis, A., and J. Stephens, "PPP Over AAL5", RFC 2364, July 1998.
[RFC2364] Gross、G.、Kaycee、M.、Lin、A.、Malis、A。、およびJ. Stephens、「PPP Over AAL5」、RFC 2364、1998年7月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473] Conta、A。およびS. Deering、「IPv6仕様の一般的なパケットトンネル」、RFC 2473、1998年12月。
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2516] Mamakos、L.、Lidl、K.、Evarts、J.、Carrel、D.、Simone、D.、およびR. Wheeler、「PPPをイーサネット上に送信する方法」、RFC 2516、2月1999年。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2529] Carpenter、B。およびC. Jung、「明示的なトンネルなしのIPv4ドメイン上のIPv6の伝送」、RFC 2529、1999年3月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661] Townsley、W.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。、およびB. Palter、 "Layer Two Tunneling Protocol" L2TP ""、RFC 2661、1999年8月。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[RFC2740] Coltun、R.、Ferguson、D。、およびJ. Moy、「OSPF for IPv6」、RFC 2740、1999年12月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Cancapstulation（GRE）」、RFC 2784、2000年3月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten、T。およびR. Draves、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 3041、2001年1月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053] Durand、A.、Fasano、P.、Guardini、I。、およびD. Lento、「IPv6 Tunnel Broker」、RFC 3053、2001年1月。
[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月。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[RFC3177] IABおよびIESG、「IPv6に関するIAB/IESGの推奨事項は、サイトへの割り当てアドレス」、RFC 3177、2001年9月。
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001.
[RFC3180] Meyer、D。およびP. Lothberg、「233/8でのGLOPアドレス指定」、BCP 53、RFC 3180、2001年9月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618] Fenner、B。およびD. Meyer、「マルチキャストソースディスカバリープロトコル（MSDP）」、RFC 3618、2003年10月。
[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月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] DROMS、R。、「IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス」、RFC 3736、2004年4月。
[RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks", RFC 3904, September 2004.
[RFC3904] Huitema、C.、Austein、R.、Satapati、S。、およびR. van der Pol、「管理されていないネットワークのIPv6遷移メカニズムの評価」、RFC 3904、2004年9月。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931] Lau、J.、Townsley、M。、およびI. Goyret、「レイヤー2つのトンネルプロトコル - バージョン3（L2TPV3）」、RFC 3931、2005年3月。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
[RFC4001] Daniele、M.、Haberman、B.、Routhier、S。、およびJ. Schoenwaelder、「インターネットネットワークアドレスのテキストコンベンション」、RFC 4001、2005年2月。
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[RFC4029] Lind、M.、Ksinant、V.、Park、S.、Baudot、A。、およびP. Savola、「IPv6をISPネットワークに導入するためのシナリオと分析」、RFC 4029、2005年3月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191] Draves、R。およびD. Thaler、「デフォルトのルーターの設定とより固有のルート」、RFC 4191、2005年11月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, October 2005.
[RFC4214] Templin、F.、Gleeson、T.、Talwar、M。、およびD. Thaler、「敷地内自動トンネルアドレス指定プロトコル（ISATAP）」、RFC 4214、2005年10月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380] Huitema、C。、「Teredo：ネットワークアドレス翻訳（NAT）を介してUDPを介してIPv6をトンネル化する」、RFC 4380、2006年2月。
[6PE] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands across IPv4 Clouds with BGP", Work in Progress, December 2006.
[6pe] de Clercq、J.、Ooms、D.、Prevost、S。、およびF. Le Faucheur、「IPv6雲をBGPに接続する」、2006年12月の進行中の作業。
[AUTO-CONFIG] Wen, H., Zhu, X., Jiang, Y., and R. Yan, "The deployment of IPv6 stateless auto-configuration in access network", 8th International Conference on Telecommunications, ConTEL 2005, June 2005.
[Auto-Config] Wen、H.、Zhu、X.、Jiang、Y.、およびR. Yan、「アクセスネットワークにおけるIPv6 Stateless Auto Configurationの展開」、第8回電気通信に関する国際会議、Contel 2005、2005年6月。
[BSR] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for PIM", Work in Progress, June 2006.
[BSR] Bhaskar、N.、Gall、A.、Lingard、J。、およびS. Venaas、「Bootstrap Router（BSR）メカニズムのメカニズム」、2006年6月、Work in Progress。
[DOCSIS3.0-OSSI] CableLabs, CL., "DOCSIS 3.0 OSSI Specification(CM-SP-OSSIv3.0-D02-060504)", May 2006.
[docsis3.0-ossi] cablelabs、cl。、 "docsis 3.0 ossi仕様（cm-sp-ossiv3.0-d02-060504）、2006年5月。
[DOCSIS3.0-Reqs] Droms, R., Durand, A., Kharbanda, D., and J-F. Mule, "DOCSIS 3.0 Requirements for IPv6 Support", Work in Progress, March 2006.
[docsis3.0-reqs] Droms、R.、Durand、A.、Kharbanda、D。、およびJ-F。ラバ、「IPv6サポートのDocsis 3.0要件」、2006年3月、進行中の作業。
[DynamicTunnel] Palet, J., Diaz, M., and P. Savola, "Analysis of IPv6 Tunnel End-point Discovery Mechanisms", Work in Progress, January 2005.
[Dynamictunnel] Palet、J.、Diaz、M。、およびP. Savola、「IPv6トンネルエンドポイント発見メカニズムの分析」、2005年1月、進行中の作業。
[IEEE80211i] IEEE, "IEEE Standards for Information Technology: Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications, Amendment 6: Medium Access Control (MAC) Security Enhancements", July 2004.
[IEEE80211I] IEEE、「情報技術のIEEE標準：パート11：ワイヤレスLANメディアアクセス制御（MAC）および物理層（PHY）仕様、修正6：中アクセス制御（MAC）セキュリティ強化」、2004年7月。
[IEEE8021X] IEEE, "IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001", June 2001.
[IEEE8021X] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：ポートベースのネットワークアクセス制御、IEEE STD 802.1x-2001」、2001年6月。
[IPv6-Multicast] Savola, P., "IPv6 Multicast Deployment Issues", Work in Progress, April 2004.
[IPv6-Multicast] Savola、P。、「IPv6マルチキャスト展開の問題」、2004年4月、進行中の作業。
[IPv6-Security] Convery, S. and D. Miller, "IPv6 and IPv4 Threat Comparison and Best-Practice Evaluation", March 2004.
[IPv6-Security] Convery、S。and D. Miller、「IPv6およびIPv4の脅威の比較とベストプラクティス評価」、2004年3月。
[ISISv6] Hopps, C., "Routing IPv6 with IS-IS", Work in Progress, October 2005.
[ISISV6] HOPPS、C。、「IS-ISを使用したIPv6をルーティング」、2005年10月、作業中。
[ISP-CASES] Mickles, C., "Transition Scenarios for ISP Networks", Work in Progress, September 2002.
[ISPケース] Mickles、C。、「ISPネットワークの移行シナリオ」、2002年9月、進行中の作業。
[Protocol41] Palet, J., Olvera, C., and D. Fernandez, "Forwarding Protocol 41 in NAT Boxes", Work in Progress, October 2003.
[Protocol41] Palet、J.、Olvera、C。、およびD. Fernandez、「NAT Boxesの転送プロトコル41」、2003年10月の作業。
[RF-Interface] CableLabs, CL., "DOCSIS 2.0(CM-SP-RFIv2.0-I10- 051209)", December 2005.
[rf-interface] cablelabs、cl。、 "docsis 2.0（cm-sp-rfiv2.0-i10- 051209）、2005年12月。
[RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network", RFC 4562, June 2006.
[RFC4562] Melsen、T。およびS. Blake、「MAC強制転送：イーサネットアクセスネットワークでのサブスクライバー分離の方法」、RFC 4562、2006年6月。
[Softwire] Dawkins, S., Ed., "Softwire Problem Statement", Work in Progress, May 2006.
[Softwire] Dawkins、S.、ed。、「Softwire Problem Statement」、2006年5月の作業。
[v6tc] Palet, J., Nielsent, K., Parent, F., Durand, A., Suryanarayanan, R., and P. Savola, "Goals for Tunneling Configuration", Work in Progress, August 2005.
[V6TC] Palet、J.、Nielsent、K.、Parent、F.、Durand、A.、Suryanarayanan、R。、およびP. Savola、「トンネル構成の目標」、2005年8月の作業。
Authors' Addresses
著者のアドレス
Salman Asadullah Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
Salman Asadullah Cisco Systems 170 West Tasman Drive San Jose、CA 95134 USA
Phone: 408 526 8982 EMail: sasad@cisco.com
電話：408 526 8982メール：sasad@cisco.com
Adeel Ahmed Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA
Adeel Ahmed Cisco Systems 2200 East President George Bush Turnpike Richardson、TX 75082 USA
Phone: 469 255 4122 EMail: adahmed@cisco.com
電話：469 255 4122メール：adahmed@cisco.com
Ciprian Popoviciu Cisco Systems 7025-6 Kit Creek Road Research Triangle Park, NC 27709 USA
Ciprian Popoviciu Cisco Systems 7025-6 Kit Creek Road Research Triangle Park、NC 27709 USA
Phone: 919 392 3723 EMail: cpopovic@cisco.com
電話：919 392 3723メール：cpopovic@cisco.com
Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland
Pekka Savola CSC -Scientific Computing Ltd. Espoo Finland
EMail: psavola@funet.fi
Jordi Palet Martinez
Consulintel
San Jose Artesano, 1
Alcobendas, Madrid E-28108
Spain
Phone: +34 91 151 81 99
EMail: jordi.palet@consulintel.es
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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エディター機能の資金は現在、インターネット協会によって提供されています。