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
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）IETFトラスト（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のネットワークから、その違いの主なコンポーネントについて説明し、どのようになるの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.
すなわち、ケーブル/ HFC、BBイーサネット、xDSLの、WLAN、および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.
この文書では、簡単にだけでなく、プロバイダのネットワークの他の要素について説明します。これは、個別に、上記のBBテクノロジーごとに異なる実行可能なIPv6の展開と統合技術、およびモデルを提供します。例えば、リストは網羅的なものではないが、それが代表になろうと。
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.
この文書は、IPv6を統合し、展開されたときに、現在のIPv4ベースのケーブル/ HFC、BBイーサネット、xDSLの、WLAN、およびPLC / BPLネットワークのすべての重要なコンポーネントがどのように動作するかを分析します。
The following important pieces are discussed:
以下の重要な部分を説明します。
A. Available tunneling options
A.利用可能なトンネリングオプション
B. Devices that would have to be upgraded to support IPv6
IPv6をサポートするようにアップグレードしなければならないであろうB.デバイス
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サービスをサポートするために、既存のインフラストラクチャをアップグレードする方法について助言することです。デュアルスタックにデバイスをアップグレードするための推奨事項が議論に必要なのIPv6機能を実行するためにそのネットワークに新しいデバイスを追加することから、SPを停止しません。このようなアプローチに関わる費用は、既存のIPv4サービスの低下の影響により相殺することができます。
BB: Broadband
B：ブロードバンド
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のイーサタイププロトコルID（0x86DD）またはIPv6マルチキャスト特定のメディアアクセス制御（MAC）アドレスなどのレイヤ2情報に基づいて、IPv6トラフィックをフィルタリングと同様に、メカニズムをプロビジョニングIPv6のサポート及び監視の目的で33来るかもしれません：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トラフィックを終了することを選択できます。アクセスルータは、SPエッジルータへのレイヤ3コア上で加入者トラフィックやルート、それを集約するために使用されています。この場合、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トラフィックを転送するトンネリングメカニズムを使用するように選択することができます。このアプローチは、アクセスプロバイダネットワーク上の少なくとも影響を与えています。ユーザー数が増加し、IPv6トラフィックの量が大きくなるにつれてしかし、ISPは、下記のシナリオのいずれかに進化する必要があります。
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をサポートするようにアップグレードされており、デュアルスタックになることができます。デュアルスタックネットワークでは、IPv6のインテリアゲートウェイようOSPFv3のようなプロトコル（IGP）、[RFC2740]、または、[ISISv6] IS-ISが有効になっています。 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を実行している場合、それはその上のIPv6トラフィックを転送するために6PEを使用することができます。この場合、ネットワークのエッジに近いルータのサブセットだけは、IPv6認識する必要があります。このアプローチでは、BGPは6PEをサポートするために重要になります。
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の両方を輸送することを気づいていない、トラフィックを切り替えるために続けている間にアップグレードして設定する必要があります。 MPLSは、すでにネットワークに配備されている場合は6PEにのみ活用されなければなりません。このドキュメントの執筆時点で、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]で議論されています。アクセスプロバイダーネットワークのコアにおける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.
SPはネイティブIPv6を導入することができない場合は、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.
顧客が住宅のユーザである場合、それはNAPまたはISPネットワーク内に位置するトンネル終端ルータへのIPv6できるホストから直接トンネルを開始することができます。使用されるトンネルタイプは、SPによって決定されるべきであるが、それを考慮にホストマシン上で実行されている一般的に使用されるソフトウェアにその可用性を取る必要があります。 IPv6ホストとルータの多くのトンネリングのようなIPv6のトンネルブローカーとして開発機構、[RFC3053]、IPv4の雲を介したIPv6ドメインの接続[RFC3056]、IPv6における汎用パケットトンネリング[RFC2473]、ISATAP [RFC4214]、基本的な移行メカニズムの[ RFC4213]、および明示的なトンネル[RFC2529]なしのIPv4ドメイン上のIPv6の送信、一部は他よりも人気があります。この文書を書いている時点で、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.
エンドユーザーは、GWRがインストールされている場合、このように、顧客のネットワーク上の複数のホストへのネイティブのIPv6アクセスを提供し、トンネルを発信するために使用することができます。この場合、GWRは、IPv6をサポートするために、デュアルスタックにアップグレードする必要があります。 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）を介してトンネルを開始する必要がある場合、彼らはパブリックIPv4アドレスに依存していることから、6to4のような技術が動作しない場合があります。この場合、既存のGWRs支持プロトコル41-フォワーディング[Protocol41]ない限り、エンドユーザは、（Teredoの[RFC4380]などの）NATを介して動作することができるトンネルを使用する必要があるかもしれません。 GWRは、IPv6サービスによって影響されない場合 - ホストがトンネルを開始することができることを意味最もGWRs支持プロトコル-41転送、。
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トラフィックを転送するために使用することができます。例として、顧客はトンネルがISPに遷移するのIPv4上のトラフィックを使用しているネットワークアクセスプロバイダにネイティブに接続する可能性があります。この場合、トンネルの選択は、（例えば、か否かがマルチキャストをサポートしている）、その能力に依存し、使用されるルーティングプロトコルは、（例えば、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]動的でありながら、いくつかのトンネルが静的で）、SPは追加投資価値がネイティブなアプローチを見つけるかもしれません。
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-インターフェース]で提供され、従来の仕様はサポートを提供しませんネイティブのIPv6アクセス用。セクション6、7、8、およびDSL上ネイティブIPv6展開に9つの焦点が、ホーム（FTTH）、無線、およびPLC / BPLに、今日、このアプローチが完全にサポートされているので、ファイバは、トンネルベースのソリューションも可能ですこれらの例は、このセクションのガイドラインに基づいており、第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.
このセクションでは、家にBBサービスを提供するケーブルネットワークで、今日存在するインフラストラクチャについて説明します。また、これらのケーブルネットワークでの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].
ブロードバンドケーブルネットワークは、IP（VoIP）のサービスを超える高速インターネットアクセス、音声を提供するために、ユーザーからの/へのIPトラフィックを輸送することができます。ケーブルネットワークを介してIPトラフィックを搬送するための機構は、DOCSIS仕様[RF-インタフェース]に概説されています。
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)
CMTS：ケーブルモデム終端システム（レイヤ2ブリッジングまたはレイヤ3ルーティングCMTSであることができます）
GWR: Residential Gateway Router (provides Layer 3 services to hosts)
GWR：レジデンシャルゲートウェイルータ（ホストにレイヤ3つのサービスを提供しています）
Host: PC, notebook, etc., which is connected to the CM or GWR
ホスト：PC、ノートPCなど、CMやGWRに接続されています
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を展開するための動機の一つは、管理負担を緩和することです。 IPv6は、管理目的のためにCM、CMTS、および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は、これらの環境の両方で展開することができます。
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へのケーブル・ネットワークを介して転送されます。インターネットへのISPのネットワークを介してERその後、ルーティングトラフィック。 CMとCMTSは、管理目的のためのレイヤ3機能をある程度サポートしています。
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.
ルーティングされたネットワークでは、IPトラフィックを転送CMTSはに/ホストからIPソース/宛先アドレスを使用して、レイヤ3情報に基づいて。 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-インターフェース]になされる必要があります。これは、ケーブルネットワーク上でネイティブ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.
CMとCMTS上のIPv6近隣探索（ND）とB.問題。 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.
上流及び下流方向のIPv6トラフィックのC.分類。 CMとCMTSは彼らに適切な優先順位とQoSを与えるために、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、レイヤ2つのブリッジとしてCMとCMTS行為でに/ホストとERからのすべてのデータトラフィックを転送します。ホストは、レイヤ3のネクストホップとしてERを使用します。 GWRは、CMの背後に存在する場合には、ERから/へのすべてのホストと順方向データ・トラフィックのネクストホップとして機能することができます。
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ユニキャストおよびマルチキャストパケットをブリッジする必要があります。 GWRはCMに接続がある場合、それは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.
CMとホスト：IPv6展開のための提案されたアーキテクチャは、プロビジョニングされなければならない2つの構成要素を含みます。 CMに接続GWRがある場合はさらに、それはまた、プロビジョニングする必要があります。ホストまたはGWRは自分のレイヤ3のネクストホップとしてERを使用します。
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.
何GWRがない場合にはCMに接続され、CMの背後にあるホストはステートレス自動設定またはDHCPv6の経由/ 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).
ステートレス自動構成を使用している場合、ホストは、ERからの広告（RAS）をルーティングするためにリッスン。 RAはセグメントに割り当てられた/ 64プレフィックスを含みます。 RAを受信すると、ホストは、RAにおけるプレフィックス（/ 64）及び固有の識別子（例えば、その変形EUI-64（64ビット拡張一意識別子）形式のインタフェースID）を組み合わせることにより、そのIPv6アドレスを構成します。
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のメッセージは、CMとCMTSによって架橋されたホストとDHCPv6サーバ間で交換しました。
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は、その上流インタフェース自体とERとの間のリンクのアドレスを取得するためにステートレス自動設定（RA）を使用することができます。この工程は、典型的には、接頭辞より短い/ 64のためのDHCP-PDを介して要求（プレフィックス委譲）が続く順番に64S /に分割され、ホストに接続し、その下流インターフェースに割り当て/ 48 [RFC3177]。
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.
異なるのCMの背後にあるホスト間の通信は、常にCMTSを介して転送されます。異なるサイト間の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やブリッジCMTSはIGMPv3の/ MLDv2のか、V1スヌーピングをサポートする必要があります。 MLDは、IPv4のIGMPとほぼ同じである、唯一の名前と番号が変更されます。 MLDv2のは、IGMPv3のと同じであり、また、ASM（どれ-ソースマルチキャスト）とSSM（ソース固有のマルチキャスト）サービスモデルをサポートしています。 IPv4のIGMPv3のとIPv6 MLDv2の間の唯一の大きな違いは、プロトコルで長いアドレスであるため、CMの/のCMTS上の実装作業は最小限でなければなりません。
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のようIGPを実行するか、IS-IS。接続されているプレフィックスは再配布する必要があります。 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は、そのレイヤ3のネクストホップとしてCMTSを使用しています。
When deploying IPv6, the CMTS/ER will need to either tunnel IPv6 traffic or natively support IPv6.
IPv6を展開する場合、CMTS / ERは、トンネルIPv6トラフィックのいずれかに必要か、ネイティブIPv6をサポートします。
There are five possible deployment scenarios for IPv6 in a routed CMTS network:
ルーティングされたCMTSネットワークにおけるIPv6のための5つの可能な展開シナリオがあります。
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サービスを提供するために、ケーブル事業者のための最も簡単な方法です。
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を追加する必要があるために展開することも容易です。
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.
このシナリオでは、スタンドアロンのGWRはCMに接続されているがあります。 IPv6機能は、GWRに存在するので、CMはデュアルスタックである必要はありません。 CMTSは、デュアルスタックにアップグレードされ、それがERの機能を組み込むことができます。このシナリオはまた、GWRおよびCMTS上のハードウェアとソフトウェアの変更が必要な場合があります。
5. Dual-stacked Cable (HFC) Network, Embedded GWR/CM, and CMTS Support IPv6
GWR / CM、及びCMTSサポートIPv6の組み込み5デュアル積層ケーブル（HFC）ネットワーク、
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機能は、デュアルスタックにアップグレードする必要があり、単一のデバイス、上に存在します。 CMTSはまた、デュアルスタックデバイスにアップグレードする必要があります。それは組み込み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サービスを提供するケーブル事業者のための最も費用対効果の高い方法の一つです。ケーブルネットワークは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は、利用可能なIPv6のIPv4のトンネリングメカニズムのいずれかを使用する必要があります。
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.
ホストは、ERへのトンネルを調達するために、そのIPv4アドレスを使用します。すべての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は、IPv6アドレスと自分自身を自動設定するためにホストによって使用されるその下流インタフェース、上のRAメッセージを送信します。 GWRはまた、ERからRAメッセージを用いて、その上流インタフェースを構成し、ERから/ 48 [RFC3177]プレフィックスを要求するDHCP-PDを使用することができます。この/ 48プレフィックスはGWR下流インターフェイスに接続されたホスト上の/ 64Sを構成するために使用されます。 ISPネットワークへのアップリンクは、同様に/ 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トラフィックがホストへ/からのIPv6トラフィックを転送しますERとGWR、へ/から送信されます。ケーブルオペレータのIPv4ネットワーク上でIPv6パケットを転送するために、GWRおよびERは、利用可能なIPv6のIPv4のトンネリングメカニズムのいずれかを使用する必要があります。それが起動したら、すべての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は、ERへのトンネルを調達するために、そのIPv4アドレスを使用します。トンネルエンドポイントは、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.
使用トンネリング技術によっては、追加の設定は、GWRおよびERに必要になることがあります。 ERはまた、6to4リレーサービスを提供している場合、デフォルトルートは、すべての非の6to4トラフィックのために、ERにGWRのポインティングに追加する必要があります。
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がアドレスの割り当てに使用されている場合、スタティックルートは自動的に各委任/ 48プレフィックスのための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は、DOCSIS仕様の変更を必要としたIPv6ユニキャストおよびマルチキャストトラフィックおよびIGMPv3 / MLDv2のか、V1スヌーピングのブリッジングをサポートする必要があります。ホストおよびCMTS / 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またはステートレス自動設定を介して行うことができます。 CMは、管理用のIPv4アドレスを使用している場合、それはそのアドレス割り当てのためのDHCPv4を使用すると、CMTSはDHCPv4のリレーエージェントとして機能する必要があります。 CMは、管理のためのIPv6アドレスを使用している場合、それはCMTSがのDHCPv6リレーエージェントとして動作し、DHCPv6のを使用することができ、またはCMTSは、静的/ 64プレフィックスで構成することができ、それはケーブルインターフェイスからRAメッセージを送信することができます。 CMはIPv6アドレスと自分自身を自動設定するには、RAメッセージを使用することができるケーブルインターフェイスに接続されています。ケーブルインターフェイスに接続されているすべてのCMは、同じサブネットになります。
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のか、ステートレス自動設定を経由して自分のIPv6アドレスを受け取ることができます。 DHCPv6のでは、CMTSがホストとDHCPサーバ間のDHCPv6リレーエージェントと前方DHCPメッセージとして機能する必要があるかもしれません。ステートレス自動設定を使用すると、CMTSは、複数の/ 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ケーブルインターフェイスに接続されているので、全くルーティングプロトコルは、CMTSとホストとの間で必要とされません。 CMTSはIPv6をサポートしているため、ホストは、レイヤ3のネクストホップとしてCMTSを使用します。
If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or IS-IS.
CMTSはまた、ERとして機能している場合は、そのようなOSPFv3のようIGPを実行するか、IS-IS。
5.2.2.4. Dual-Stacked Cable (HFC) Network, Stand-Alone GWR, and CMTS Support IPv6
5.2.2.4。デュアルスタックケーブル（HFC）ネットワーク、スタンドアロンGWR、CMTSおよびサポートのIPv6
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通信を容易にします。 CMTSは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.
セクション5.2.2.2.2に記載されているように、ホストとGWRのアドレス割当ても同様に起こります。
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のようIGPを実行する必要がありますまたはIS-IS。
5.2.2.5. Dual-Stacked Cable (HFC) Network, Embedded GWR/CM, and CMTS Support IPv6
5.2.2.5。デュアルスタックケーブル（HFC）ネットワーク、組み込みGWR / CM、およびCMTSのサポートIPv6の
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は、DHCPv4のに今日ないくらいのような、DHCPクライアント（ホストおよびCM / GWR）にDHCPサーバから送信されたDHCPオファーメッセージから適切な情報を収集する必要があります。 CMTS上の同じケーブルインターフェイスに接続されている全てのCM / GWRは、同じ管理/ 64プレフィックスに属します。 CMTSがケーブルインターフェイスの下に構成された複数の/ 64プレフィックスを有することができるようにCMTS上の同じケーブルインターフェイスに接続されたホストは、異なる/ 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プレフィックスを使用して、その上流のインタフェースにIPv6アドレスを割り当てるためにステートレス自動構成を使用します。 CM / GWRは、その上流のインタフェースにIPv6アドレスを割り当てたら、CMTS / ERから/ 48 [RFC3177]プレフィックスを要求およびIPv6ホストにアドレスを割り当てるための/ 64Sにプレフィックスこの/ 48をチョップします。 ISPネットワークへのアップリンクは、同様に/ 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.
ホストは、レイヤ3のネクストホップとしてCM / GWRを使用します。 CM / GWRはCMTS / ERおよびホストから/へのすべてのIPv6トラフィックを転送します。 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とGWR間ルーティングプロトコルの必要がないので、CMTS / ERでIGPに再配布する必要があります。
If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or IS-IS.
CMTSはまた、ERとして機能している場合は、そのようなOSPFv3のようIGPを実行するか、IS-IS。
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（どれ-ソースマルチキャスト）と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は、ホストからのメッセージを残す/参加を追跡するために、IGMPv3の/のMLDv1またはv2スヌーピングの定義とサポートを必要とPIM-SSM、で有効にする必要がありますルーティングされます。別のオプションは、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仕様で、既存の任意のキューイング/スケジューリング機能を変更したり、追加しません。しかし、CMTSと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.
データ、音声、およびビデオ：トラフィックの分類およびマーキングは、各種のサービスをサポートするために、アップストリームトラフィックとダウンストリームトラフィックのためのCMTS / ERのためのCMで行うべきです。同じ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環境で同じように動作します。しかし、適切な機能強化は、暗号化された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網や他の加入者を保護する必要があります。この理由のためにユニキャストRPF（uRPFの）[RFC3704]とアクセス制御リスト（ACL）は、加入者が直面しているすべてのインターフェイスで使用されるべきです。フィルタリングは、IPv6 [IPv6対応セキュリティ]の動作要件を考慮して実装する必要があります。
The CMTS/ER should protect its processing resources against floods of valid customer control traffic such as: Router and Neighbor Solicitations, and MLD Requests.
ルータと近隣要請、そしてMLD要求：CMTS / ERは、次のような有効な顧客制御トラフィックの洪水に対して、その処理リソースを保護する必要があります。
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を実装し、CMTSに接続されたデバイスの数千人を管理するためにそれを使用することができます。これは、ケーブルネットワークで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、CMTS、およびERなどのデバイスを管理するためのケーブルネットワークで有効にすることができます。 VoIPおよびビデオオーバーIPのような高度なサービスの展開では、MSOのは、CMTSに接続されている多数のデバイスを管理する方法を模索しています。 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のケーブルインターフェイスに接続された全てのCM間で共有される/ 64管理プレフィックスを使用して構成することができます。 CMのためにアドレス指定することはステートレス自動設定またはDHCPv6のを介して行うことができます。 CMは/ 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、別の/ 64のプレフィックスで管理する必要があるCMの背後にあるデバイスがある場合CMTS / ERに定義することができます。また、これらのデバイスは、自分自身に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は唯一のケーブルネットワーク上のデバイスを管理するために使用されます。 DOCSIS 3.0 [DOCSIS3.0-要求数]で説明されるようにCMはもはや管理のための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モジュールの機能のいずれかを追加することも、変更されます。 [RFC4001]を更新し、新しいテキストの表記法InetAddressTypeのはMIBモジュールにIPアドレスオブジェクトに使用されるIPアドレスのタイプを識別するために添加したテキストの表記法は、IPアドレスを表す経営情報バージョン2（SMIv2）オブジェクトの構造を表すために使用されます。
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 OSSI仕様で定義されている[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モデム：それは、スタンドアロンデバイスとすることができるホストに組み込まれても、ルータの機能を組み込み、また、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.
顧客宅内ルータ（CPR）：レイヤ顧客宅内ネットワークのための3つのサービスを提供するために使用されます。通常、小規模ビジネスのためのファイアウォール機能とセグメントブロードキャストドメインを提供するために使用されます。
DSL Access Multiplexer (DSLAM): It terminates multiple twisted-pair telephone lines and provides aggregation to BRAS.
DSLアクセスマルチプレクサ（DSLAM）：これは、複数のツイストペア電話回線を終端し、BRASへの集約を提供します。
Broadband Remote Access Server (BRAS): It aggregates or terminates multiple Permanent Virtual Circuits (PVCs) corresponding to the subscriber DSL circuits.
ブロードバンドリモートアクセスサーバ（BRAS）：これは、集約や加入者のDSL回線に対応した複数の相手先固定接続（PVC）を終了します。
Edge Router (ER): It provides the Layer 3 interface to the ISP network.
エッジルータ（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はBRASで、またはエッジルータで終端することができます。 PVCは（BRASで）DSLAMにできるだけ近くに終了されていない場合は、デザインのこのタイプは非常にスケーラブルではありません。この場合には、レイヤ2の回路の多数のネットワークのかなりの部分にわたって維持されなければなりません。レイヤ2つのドメインの3つの方法でERで終了することができます。
A. In a common bridge group with a virtual interface that routes
traffic out.
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.
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セッションは、各加入者とBRAS間で開かれます。 BRASは、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）モデル：PPPセッションが各加入者とISPエッジルータ間で開かれています。 BRASは、L2TPv2 [RFC2661]トンネルにそれらをカプセル化することによってISPの加入者PPPセッションをトンネリング。このモデルは、6.2.3項に示されています。
In aggregation models, the BRAS terminates the subscriber PVCs and aggregates their connections before providing access to the ISP.
集約モデルでは、BRASは、加入者の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.3 - このアプローチは、セクション6.2.1に示されています。 6.2.4項で説明したように、新たなサービスの種類やサービスのニーズはそれを正当化する特定の状況下では、IPv4とIPv6ネットワークの論理的なアーキテクチャは異なる可能性があります。
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サブネットに属しています。ホストは、エッジルータを介してアドレスを取得するためにステートレス自動設定またはステートフルDHCPv6のベースの構成を使用することができます。
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.
顧客ごとに手動設定がプロビジョニング挑戦であるしかし、実装者は、自動的にIPv6サブネットプレフィックスにPVC（またはいくつかの他の顧客固有の情報）をマッピングメカニズム（複数可）を開発し、に顧客固有のプレフィックスを通知することをお勧めします最小限の構成ですべての顧客。
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サーバに連絡することができます。この工程は、順番に、/ 64Sに分割され、その下流側のインターフェイスに割り当てられ、プレフィックスより短い/ 64のためのDHCP-PDを介して要求が続いています。
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用に構成/ 64プレフィックスを有しています。各PVCは、ISPのネットワーク内のDHCPv6サーバに、加入者からのDHCPv6要求を中継するために有効にする必要があります。同様DHCP-PDを使用して加入者のアクセスを提供するPVCは、機能をサポートするために有効にする必要があります。 ISPネットワークへのアップリンクは、同様に/ 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などのホストに関心のある他の情報は、ステートフルDHCPv6の[RFC3315]とステートレス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.
OSPFv3のか-IS IS：エッジルータは、NSPで使用される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セッションは、顧客宅内機器によって開始され、BRASで終端されています。 BRASは、セッションを許可加入者を認証し、ISPに代わってIPアドレスを提供します。 BRASは、NSPエッジルータへの加入者トラフィックの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
PPPoAのを使用してA.接続
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セッションは、顧客宅内機器によって開始されています。 BRASは、ローカルまたはリモートのデータベースに対してユーザを認証します。セッションが確立されると、BRASは、ユーザーへのアドレスと、おそらく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ごとに1つだけのPPPセッションがあるので、加入者は、一度に一つのISPサービスを選択することができます。
B. Connection using PPPoE
PPPoEを使って接続B.
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.
このシナリオではBRASはレイヤ3認識しており、それがIPv6をサポートするようにアップグレードする必要があります。 BRASは、PPPセッションを終了しているので、それはIPv6でこれらのPPPプロトコルの実装をサポートする必要があります。ホスト、お客様のルーター（もしあれば）、BRAS、およびエッジルータ：以下のデバイスは、デュアルスタックにアップグレードする必要があります。
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アドレスを加入者に提供します。許可および認証のための加入者プロファイルは、BRASまたは認証、許可、アカウンティング（AAA）サーバ上に配置することができます。ホストまたはお客様のルータは、そのレイヤ3ネクストホップとしてBRASを持っています。
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セッションは、ホストによってまたはお客様のルータによって開始することができます。セッションがBRASを用いて確立され、アドレスがBRAS、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.
BRASは、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のプレフィックスを持っています。エッジルータのリンクもISPネットワークの他の部分への接続を提供するために/ 64のプレフィックスを使用して構成されています。
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を介し委任ものに使用されるプレフィックスはBRAS最大集約を可能にするように計画されるべきです。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
DNSなどのホストに関心のある他の情報は、ステートフル[RFC3315]とステートレス[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.
BRASは、エッジルータにIGPを実行します：OSPFv3のか、IS-IS。 PPPセッションに割り当てられたアドレスが接続されたホストルートとして表現されているので、接続プレフィックスは再配布されなければなりません。 DHCP-PDを使用している場合、すべての委任プレフィックスでスタティックルートは、エッジルータによってインストールされます。このため、スタティックルートも再配布する必要があります。プレフィックス集約はBRASで行うべきです。
The Edge Router is running the IGP used in the ISP network: OSPFv3 or IS-IS.
エッジルータは、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:
LAAモデルでは、BRASはBRASとエッジルータとの間で確立されたL2TPv2トンネルを介してISPにセッションを開始したCPEを転送します。この場合には、認証、認可、及び加入者構成は、ISP自体によって実行されます。このモデルを活用することができるPPPカプセル化の2種類があります。
A. Connection via PPPoA
PPPoAの経由A.接続
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
PPPoEを経由して接続B.
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.
このシナリオでは、BRASは、L2TPネットワークサーバー（LNS）、ISPネットワーク内の集約ポイントに確立L2TPv2トンネルを介して加入者によって開始されたPPPセッションを転送しています。 L2TPアクセス・コンセントレータ（LAC）とLNS間のL2TPv2トンネルは、IPv6又はIPv4の上で実行することができます。これらの機能は、BRAS上でサポートする必要があります。ホスト、お客様のルータ、およびエッジルータ：次のデバイスは、デュアルスタックにアップグレードする必要があります。トンネルはIPv6の上に設定されている場合は、BRASは、デュアルスタックにアップグレードする必要があります。
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.
エッジルータは、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は、顧客ルータインターフェイスのプレフィックスを取得するために使用することができます。エッジルータは、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.
BRASは、エッジルータへのリンク上で設定/ 64プレフィックスを持っています。エッジルータのリンクもISPネットワークの他の部分への接続を提供するために/ 64のプレフィックスを使用して構成されています。 DNSなどのホストに関心のある他の情報は、ステートフル[RFC3315]とステートレス[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.
ここでのIPv4対IPv6のためのこの展開の間に有意差を注意することが重要です。 IPv4の場合には、顧客のルータまたはCPEは、仮定が、冗長性の目的で、それらの少なくとも2つが存在することで、任意のエッジルータ（LNSとして動作）に終わることができます。認証されると、顧客はそれが接続されているER（LNS）のIPプールからアドレスが与えられます。これは、排出権（のLNS）は、顧客に配布アドレスを集約することができます。 IPv6の場合には、可能性が施行され、重要な制約に関わらず、ER（LNS）のそれはに接続し、顧客は自身のアドレスを保持するべきであるということです。これは、大幅にER（LNS）のプレフィックス集約機能を低下させる可能性があります。これは、アドレッシングは本質的に動的である現在のIPv4の展開よりも異なり、同じユーザが、それが接続して終わるLNSに応じて異なるアドレスを取得することができます。
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).
一つの可能な解決策は、LNSがダウンしている場合を除き与えBRASは常に同じ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.
OSPFv3のか-IS IS：BRASは、エッジルータにIPv6のIGPを実行します。 NAPとNSPは、異なる組織によって管理されている場合は、別のプロセスが使用する必要があります。この場合、制御された再分配は、2つのドメイン間で有効にされるべきです。
The Edge Router is running the IPv6 IGP used in the ISP network: OSPFv3 or IS-IS.
OSPFv3のか、IS-IS：エッジルータは、IPv6 IGPは、ISPのネットワークで使用される実行されています。
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 1をマッピングする必要があり、このセクション全体で推奨されていました。このアプローチは、管理を簡素化し、ネットワークの運用担当者のために必要な訓練を最小限に抑えることができます。特定の状況では、このようなマッピングは実現不可能です。これは通常、サービスプロバイダは、インフラストラクチャを展開し、新たな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セッションがバンドルされ、複数のBRASルータで構成されている全体NAPインフラストラクチャでトンネリングなどこれらのトンネルの終点集約ルータは、ISPエッジルータです。プロバイダは、このような設計上のマルチキャストサービスを提供することを決定した場合、それが利用されて上NAP資源の問題に直面するだろう。マルチキャストトラフィックは全体のみ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.
パケット複製がBRASに宛先に近い行うことができるので、改変ポイントツーポイント（セクション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セッションがBRASで終端されています。
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は、BRASに終了し、PPPセッションは、エッジルータ（LNS）で終端されています。 6.2.1項で説明したように、ポイントツーポイントモデルでのIPv6サービスの場合、PVCはエッジルータで終端されています。このハイブリッドモデルでは、ポイントツーポイントリンクは、BRAS、NAP-所有のデバイス上で終了することができます。 IPv6トラフィックは、NSPにNAPネットワークを介してルーティングされます。このハイブリッドモデルを持っているために、BRASは、デュアルスタックルーターにアップグレードする必要があります。エッジルータの機能は、セクション6.2.1で説明したように、今BRASに実装されています。
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.
この展開モデルの他の態様は、BRASは、L2TPv2トンネル及びNSPにルーティングされなければならないIPv6パケット掛けなければならないのIPv4 PPPトラフィックとを区別することが可能でなければならないという事実です。 IPv6ルーティングブリッジングカプセル化（RBE）は、このハイブリッド設計では、IPv4とIPv6の両方のサービスをサポートするのPVCと、すべてのインターフェイス上でイネーブルされなければなりません。
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
IPv6マルチキャストサービスの展開は、IPv4のとルーティングのためのPIM上のIGMPと同じで、MLDに依存しています。 ASM（任意のソースマルチキャスト）とSSM（シングルソースマルチキャスト）サービスモデルは、ほとんどのIPv4と同様に動作します。どちらのは、IPv4の場合と同じ利点と欠点を持っています。それにもかかわらず、より大きなアドレス空間とスコープアドレスアーキテクチャは、マルチキャスト、IPv6の主な利点を提供します。 RFC 3306を介して、大きなアドレス空間は、グローバル割り当てるための手段を提供します
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].
マルチキャストグループは、ユニキャストプレフィックスが割り当てられた組織またはユーザーに対応します。それは、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）プロトコル、ためにランデブーポイント（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].
ドメイン間の展開では、は、Multicast Source Discovery Protocol（MSDP）[RFC3618]はIPv4のPIM-SMの展開の重要な要素です。 MSDPは、異なるドメインでのRPとの間のソース登録情報の交換のための溶液であることを意味します。このソリューションは一時的であることを意図していました。これは、IPv6の[IPv6対応マルチキャスト]でMSDPを実装しないことに決めた理由の一つです。
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に基づいて、ソース固有のマルチキャストの展開は、（BSRまたはMSDPのような）RPまたは関連するプロトコルを必要としませんが、彼らが受け取ることを計画マルチキャストトラフィックの送信元を知るために、リスナーに依存しています。 RPの欠如は、SSMだけではなく、単純に動作するだけでなく、堅牢になり、それはRPの障害やドメイン間の制約の影響を受けていません。また、より高いレベルのセキュリティ（攻撃の標的とすべきRP）があります。 IPv6のマルチキャストのトピックに関する詳細な議論については、[IPv6の-マルチキャスト]を参照してください。
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は/加入次のことがBRASまたはエッジルータであるかどうかホップのレイヤ3に任せて送信するために、PIM-SSMをサポートするために有効にする必要があります。 CPRにこの機能を有効にする場合は、その限られた資源を考慮する必要があります。別のオプションは、MLDプロキシルーティングをサポートするためのCPRのためになります。
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).
（PTAモデルまたはLAAとポイントツーポイントモデルのエッジルータでBRAS）レイヤ3次の加入者のためのホップであるルータがからの要求を処理するためにはMLDv1およびMLDv2のを支援するために有効にする必要がありますCPRSなしで加入。これは、顧客のルータから合流/葉を受け取り、マルチキャストソース（エッジルータまたは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を有効にするためにエッジルータ上に設定されています。これらの機能をサポートする代替メカニズムをさらに調査する必要があります。
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モデルにおけるBRASまたは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接続のために実装トラフィックポリシングとシェーピングのレベルがすでに存在することが期待されています。これは、NAP全体に実装し、この文書の範囲外です。
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.
BRASまたはエッジルータに、加入者側インターフェイスは、インバウンド顧客のトラフィックをポリシングし、サービスレベル契約（SLA）に基づいて、顧客へのトラフィック送信を成形するように構成されなければなりません。トラフィックの分類およびマーキングは、顧客のトラフィック（データ、音声、およびビデオ）の様々なタイプをサポートするための、最適インフラストラクチャリソースを使用するために、ルータの加入者に（レイヤ3で）最も近い上で実行する必要があります。再分類およびマーキングは、トラフィックが適切にISPによって処理されていることを確認するためには、NAPとNSPとの境界で実行されることがありますように、各プロバイダ（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]のプライバシー拡張は、ホストによって使用されるべきです。 ISPは、それが比較的容易に加入者に割り当てるプレフィックスを追跡することができます。しかし、ISPには/ 128アドレスレベルでそのユーザーを追跡するために、規制によって要求された場合は、プライバシーの拡張機能は、ホストのトレーサビリティを提供できるネットワーク管理ツールと並行して実施することができます。 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].
加入者（BRASまたはエッジルータ）用のレイヤ3次のホップであるデバイスは、プロバイダーのお客様のいずれかによって攻撃からネットワークや他の加入者を保護する必要があります。このため、uRPFのとACLは、加入者が直面しているすべてのインターフェイスで使用されるべきです。フィルタリングは、IPv6 [IPv6対応セキュリティ]の動作要件を考慮して実装する必要があります。
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要求：BRASとエッジルータは、次のような有効な顧客制御トラフィックの洪水に対して、その処理リソースを保護する必要があります。レート制限は、すべての加入者側インターフェイスに実装する必要があります。それは、ほとんどの場合、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.
（等MIBモジュール、NetFlowのレコードなど）が必要計装は、IPv6のために利用可能であるべきです。
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または光ファイバ（ホーム（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.
顧客宅内ルーター：これは、レイヤ顧客宅内ネットワークのための3つのサービスを提供するために使用されます。
Aggregation Ethernet Switches: Aggregates multiple subscribers.
集約イーサネットスイッチ：複数の加入者を集約します。
Broadband Remote Access Server (BRAS)
ブロードバンドリモートアクセスサーバ（BRAS）
Edge Router (ER)
エッジルータ（ER）
Figure 7.1 depicts all the network elements mentioned.
図7.1は、言及された全てのネットワーク要素を示しています。
Customer Premise | Network Access Provider | Network Service Provider CP NAP NSP
顧客宅内|ネットワークアクセスプロバイダ|ネットワーク・サービス・プロバイダ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.
これは、一般的な動作は、このセクションで説明する概念および推奨はのHomePNAベースのネットワーク環境にも同様に適用することは注目に値します。このような環境では、ネットワーク要素のいくつかは、異なる名前を付けることがあります。
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は、BRASで、またはエッジルータで終端することができます。 VLANは、レイヤ3デバイス（BRASまたはエッジルータ）に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）モデル末端：PPPセッションは、各加入者とBRAS間で開かれます。 BRASは、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終端装置との間で開かれます。 BRASは、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.
集約モデルでBRASは、加入者の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.3 - このアプローチは、セクション7.2.1に示されています。 7.2.4項で説明したように、新たなサービスの種類やサービスのニーズはそれを正当化する特定の状況下では、IPv4とIPv6のネットワーク・アーキテクチャは異なる可能性があります。
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 |
|顧客宅内| | 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サブネットに属しています。ホストは、エッジルータを介してアドレスを取得するためにステートレス自動設定またはステートフルDHCPv6のベースの構成を使用することができます。
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.
各顧客のために手動設定プロビジョニング課題であるようしかし、実装が自動的にIPv6サブネットプレフィックスにVLAN（またはいくつかの他の顧客固有情報）をマッピングし、及びに顧客固有のプレフィックスを通知機構（単数または複数）を開発することが奨励されます最小限の構成ですべての顧客。
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との間のリンクのアドレスを取得することができます。このステップは順番に/ 64Sに分割され、顧客サイトにホストを接続し、そのインタフェースに割り当てられたより短い/ 64ことプレフィックスのDHCP-PDを介して要求が続いています。
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用に構成/ 64プレフィックスを有しています。各VLANには、ISPのネットワーク内のDHCPv6サーバに、加入者からのDHCPv6要求を中継するために有効にする必要があります。 DHCP-PDを使用して加入者のアクセスを提供するVLANは、機能をサポートするために有効にする必要があります。 ISPネットワークへのアップリンクは、同様に/ 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などのホストに関心のある他の情報は、ステートフル[RFC3315]とステートレス[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.
OSPFv3のか-IS IS：エッジルータは、NSPで使用される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セッションは、顧客宅内機器によって開始され、BRASで終端されています。 BRASは、セッションを許可加入者を認証し、ISPに代わってIPアドレスを提供します。 BRASは、NSPエッジルータへの加入者トラフィックの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 |
|顧客宅内| | 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セッションは、顧客宅内機器（ホストまたはルータ）によって開始されています。 BRASは、ローカルまたはリモートのデータベースに対してユーザを認証します。セッションが確立されると、BRASは、ユーザーへのアドレスと、おそらく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.
このモデルは、このように、加入者が同時に複数のサービスに接続できるように、同じVLAN上でサポートされる複数のPPPoEセッションが可能になります。ホストは、同様の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.
このシナリオでは、BRASはレイヤ3認識しており、IPv6をサポートするようにアップグレードする必要があります。 BRASは、PPPセッションを終了しているので、それはIPv6でPPPoEをサポートする必要があります。ホスト、お客様のルーター（もしあれば）、BRASおよびエッジルータ：以下のデバイスは、デュアルスタックにアップグレードする必要があります。
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アドレスを加入者に提供します。認可と認証のための加入者プロファイルはBRAS上、またはAAAサーバ上に配置することができます。ホストまたはお客様のルータは、そのレイヤ3ネクストホップとしてBRASを持っています。
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セッションは、ホストによってまたはお客様のルータによって開始することができます。セッションがBRASを用いて確立されると、後者の場合には、DHCP-PDは、顧客ルータインターフェイスのプレフィックスを取得するために使用することができます。 BRASは、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.
BRASは、エッジルータが直面しているリンク上に構成/ 64プレフィックスを持っています。エッジルータのリンクもISPネットワークの他の部分への接続を提供するために/ 64のプレフィックスを使用して構成されています。
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を介し委任ものに使用されるプレフィックスはBRAS最大集約を可能にするように計画されるべきです。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
DNSなどのホストに関心のある他の情報は、ステートフル[RFC3315]とステートレス[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.
BRASは、エッジルータにIGPを実行します：OSPFv3のか、IS-IS。 PPPセッションに割り当てられたアドレスが接続されたホストルートとして表現されているので、接続プレフィックスは再配布されなければなりません。 DHCP-PDを使用している場合、すべての委任プレフィックスでスタティックルートは、BRASによってインストールされます。このため、スタティックルートも再配布する必要があります。プレフィックス集約はBRASで行うべきです。
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.
エッジルータは、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はBRASとエッジルータとの間で確立されたL2TPv2トンネルを介してISPにセッションを開始したCPEを転送します。この場合には、認証、認可、及び加入者構成は、ISP自体によって実行されます。
| Customer Premise | | NAP | | NSP |
|顧客宅内| | 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.
このシナリオでは、BRASはレイヤ3認識しており、IPv6をサポートするようにアップグレードする必要があります。加入者によって開始されたPPPセッションは、ISPネットワーク内の集約ポイントにL2TPv2トンネルを介して転送されます。 BRAS（LAC）は、IPv6のPPPセッションとL2TPv2を使用してLNSにトンネルそれらを集約することができます。 LACとLNS間のL2TPv2トンネルは、IPv6又はIPv4の上に実行することができます。これらの機能は、BRAS上でサポートする必要があります。ホスト、お客様のルーター（もしあれば）、BRASおよびエッジルータ：以下のデバイスは、デュアルスタックにアップグレードする必要があります。
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.
エッジルータは、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は、顧客ルータ他のインターフェイスのためのプレフィクスを取得するために使用することができます。エッジルータは、DHCP-PDをサポートし、加入者サイトのホストのDHCPv6の要求を中継するために有効にする必要があります。 ISPネットワークへのアップリンクは、同様に/ 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.
BRASは、エッジルータへのリンク上で設定/ 64プレフィックスを持っています。エッジルータのリンクもISPネットワークの他の部分への接続を提供するために/ 64のプレフィックスを使用して構成されています。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
DNSなどのホストに関心のある他の情報は、ステートフル[RFC3315]とステートレス[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.
OSPFv3のか-IS IS：BRASは、エッジルータにIPv6のIGPを実行します。 NAPとNSPは、異なる組織によって管理されている場合は、別のプロセスが使用する必要があります。この場合、制御された再分配は、2つのドメイン間で有効にされるべきです。
The Edge Router is running the IPv6 IGP used in the ISP network: OSPFv3 or IS-IS.
OSPFv3のか、IS-IS：エッジルータは、IPv6 IGPは、ISPのネットワークで使用される実行されています。
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 1をマッピングする必要があり、このセクション全体で推奨されていました。このアプローチは、管理を簡素化し、ネットワークの運用担当者のために必要な訓練を最小限に抑えることができます。特定の状況では、そのようなマッピングは実現不可能です。これは通常、サービスプロバイダは、インフラストラクチャを展開し、新たな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セッションがバンドルされており、ISPエッジルータである等、これらのトンネルの終点複数BRASルータ、アグリゲーションルータ、で構成されている全体NAPインフラストラクチャでトンネリング。 SPは、このような設計上のマルチキャストサービスを提供することを決定した場合、それが過剰に利用されてNAP資源の問題に直面するだろう。マルチキャストトラフィックは、エッジルータによってのみ、トンネルの終わりに複製することができ、すべての加入者のためのコピーが全体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.
パケット複製がBRASで目的地に近い行うことができますので、変更されたポイントツーポイント（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セッションがBRASで終端されています。
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はBRASに終了し、PPPセッションは、エッジルータ（LNS）で終端されています。 6.2.1項で説明したように、ポイントツーポイントモデルでのIPv6サービスの場合、VLANはエッジルータで終端されています。このハイブリッドモデルでは、ポイントツーポイントリンクは、BRAS、NAP-所有のデバイス上で終了することができます。 IPv6トラフィックは、NSPにNAPネットワークを介してルーティングされます。このハイブリッドモデルを持っているために、BRASは、デュアルスタックルーターにアップグレードする必要があります。エッジルータの機能は、セクション6.2.1で説明したように、今BRASに実装されています。
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は、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は/加入次のことがBRASまたはエッジルータであるかどうかホップのレイヤ3に任せて送信するために、PIM-SSMをサポートするために有効にする必要があります。 CPRにこの機能を有効にする場合は、その限られた資源を考慮する必要があります。別のオプションは、MLDプロキシルーティングをサポートするためのCPRのためになります。 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).
（PTAモデルまたはLAAとポイントツーポイントモデルのエッジルータでBRAS）レイヤ3次の加入者のためのホップであるルータがからの要求を処理するためにはMLDv1およびMLDv2のを支援するために有効にする必要がありますCPRSなしで加入。これは、顧客のルータから合流/葉を受け取り、マルチキャストソース（エッジルータまたは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を有効にするためにエッジルータに設定されています。これらの機能をサポートする代替メカニズムをさらに調査する必要があります。
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モデルにおけるBRASまたは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.
BRASまたはエッジルータでは、加入者側インターフェイスは、インバウンド顧客のトラフィックをポリシングと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.
再分類およびマーキングは、トラフィックが適切にISPによって処理されていることを確認するためには、NAPとNSPとの境界で実行されることがありますように、各プロバイダ（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).
イーサタイプのための任意のレイヤ2つのフィルタが所定の位置にある場合、NAPは、IPv6イーサタイプ（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エッジルータ）は、プロバイダの顧客のいずれかによって攻撃からネットワークや他の加入者を保護する必要があります。この理由のuRPFとACLは、加入者が直面しているすべてのインターフェイスで使用されるべきです。フィルタリングは、IPv6 [IPv6対応セキュリティ]の動作要件を考慮して実装する必要があります。
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要求：BRASとエッジルータは、次のような有効な顧客制御トラフィックの洪水に対して、その処理リソースを保護する必要があります。レート制限は、すべての加入者側インターフェイスに実装する必要があります。それは、ほとんどの場合、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.
（等MIBモジュール、NetFlowのレコードなど）が必要計装は、IPv6のために利用可能であるべきです。
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サーバによって認証されています。すべての認証パラメータ（ユーザ名、パスワードなど）がAAAサーバへのアクセスポイント（AP）によって転送されます。 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アドレスの数に制限を割り当てます。ユーザーが接続を切断し、新しい無線LANホットスポット、認証の上記プロセスは、アドレスの割り当てに移動し、インターネットが繰り返されるアクセスするとき。
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.
顧客がサービスプロバイダに無線経由で接続する無線LANルーターを使用することができますIPv4の展開があります。これらの展開のタイプは、一般的なホットスポットの概念に適合しないが、むしろ彼らは、固定された顧客にサービスを提供します。このため、このセクションは、同様に無線LANルータのオプションについて説明します。この場合、ISPは、パブリックIPアドレスを提供し、WLANルータは、すべてのWLANのユーザーにプライベートアドレス[RFC1918]を割り当てます。 WLANユーザーがインターネットにアクセスしながら、WLANルータはNAT機能を提供します。
While deploying IPv6 in the above-mentioned WLAN architecture, there are three possible scenarios as discussed below.
上記WLANアーキテクチャでIPv6を導入しながら以下に説明するように、三つの可能なシナリオがあります。
A. Layer 2 NAP with Layer 3 termination at NSP Edge Router
NSPエッジルータのレイヤ3の終端とA.レイヤ2 NAP
B. Layer 3 aware NAP with Layer 3 termination at Access Router
B.レイヤ3アクセスルータでのレイヤ3の終端と認識してNAP
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.
レイヤ2スイッチは、APとエッジルータとの間に存在する場合、APとのレイヤ2スイッチは、ルータ及びその逆をEdgeに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サーバによって認証されます。認証（ユーザ名、パスワードなど）に関連するすべてのパラメータは、AAAサーバにAPによって転送されます。 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.
WLANホスト、WLANルータ（存在する場合）、およびエッジルータを：IPv6のデュアルスタックに次のデバイスをアップグレードすることによって、このシナリオで展開されます。
When a customer WLAN Router is not present, the WLAN Host has two possible options to get an IPv6 address via the Edge Router.
顧客の無線LANルータが存在しない場合には、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ホストは、[RFC2462]ステートレス自動設定を使用してエッジルータからIPv6アドレスを取得することができます。 WLAN上のすべてのホストは、静的エッジルータ上で設定されているのと同じ/ 64サブネットに属しています。 IPv6のWLANホスト等、DNSなどの関心のある他の情報を取得するためにステートレス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サーバからIPv6アドレスを取得するためのDHCPv6 [RFC3315]を使用することができます。この場合、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のホストを接続する無線LANルータのインターフェイスに/ 64のプレフィックスを設定する必要があります。これらのインタフェースに接続されたWLANホストは自動的にステートレス自動構成を使用して自分自身を設定することができます。
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との間のリンクのアドレスを取得することができます。この工程は、順番に、/ 64Sに分割され、顧客サイトにホストを接続し、そのインタフェースに割り当てられ、プレフィックスより短い/ 64のためのDHCP-PDを介して要求が続いています。
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ホストは自動的にステートレス自動構成を使用して自分自身を設定することができます。 ISPネットワークへのアップリンクは、同様に/ 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.
SPはDHCP-PDおよびステートレス自動設定モデルで滞在し、このモデルを使用して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を介し委任ものに使用されるプレフィックスは、エッジルータで最大集約を可能にするように計画されるべきです。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
DNSなどのホストに関心のある他の情報は、ステートフル[RFC3315]とステートレス[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.
エッジルータは、OSPFv3のようなSPのネットワークで使用されるIGPを実行するか、IPv6のIS-IS。接続されているプレフィックスは再配布する必要があります。プレフィックス要約は、エッジルータで実行する必要があります。 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で説明したように、WLAN APとAAA認証およびアソシエーション処理は、同様です。
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アドレスの割り当てについては、このシナリオでは三つの可能なオプションがあります。
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.ザエッジルータインターフェイスは、静的/ 64プレフィックスで構成されています。アクセスルータは、受信/ステートレス自動設定を通じてエッジルータに面したそのインターフェイス上の/ 64プレフィックスを設定します。ネットワーク管理者は、顧客宅内に向いたアクセスルータインターフェイスに/ 64のプレフィックスを設定する必要があります。このインターフェイスに接続されたWLANホスト/ルータは自動的にステートレス自動構成を使用してそれ自体を構成することができます。
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またはステートレス自動設定の使用はありません。 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との間のリンクのアドレスを取得することができます。この工程は、順番に、/ 64Sに分割され、顧客サイトにホストを接続し、そのインタフェースに割り当てられ、プレフィックスより短い/ 64のためのDHCP-PDを介して要求が続いています。
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.
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.
SPはDHCP PDとステートレス自動設定モデルで滞在し、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を介し委任ものに使用されるプレフィックスは、エッジルータで可能な最大の集約を可能にするように計画されるべきです。 DNSなどのホストに関心のある他の情報は、ステートフル[RFC3315]とステートレス[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エッジルータの方を向いて、デフォルトルートを持つことができます。エッジルータは、OSPFv3のようなSPのネットワークで使用されるIGPを実行するか、IPv6のIS-IS。接続されているプレフィックスは再配布する必要があります。 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を実行し、（OSPFv3のまたはIS-IS）SP IPv6ルーティングドメインの一部となります。接続されているプレフィックスは再配布する必要があります。 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終端集約（PTA）およびL2TPv2アクセス集約（LAA）モデル、セクション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をサポートするようにアップグレードする必要があります。アクセスルータは、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セッションは、SPネットワーク内の集約点にL2TPv2トンネルを介して転送されます。アクセスルータは、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 /アクセスルータもPIMエッジルータまでの加入を送信するために、PIM-SSMをサポートするために有効にする必要があります。 WLAN /アクセスルータにこの機能を有効にする場合は、その限られた資源を考慮する必要があります。 WLAN /アクセスルータが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.
エッジルータは、IPv6ホストWLANまたはWLAN /アクセスルータ（存在する場合）からの要求を処理するためにのMLDv1およびMLDv2のをサポートすることが可能でなければなりません。エッジルータはまた、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を有効にするためにエッジルータ上に設定されています。詳しい調査の結果、これらの機能をサポートする代替メカニズムを見つけることでなされるべきです。
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プロトコルを実行する際に、潜在的にこれらの問題の同じ種類です。例えば、この現象は、高損失対信号比および高い干渉を有する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
WLAN（IPv4またはIPv6）を展開しながら、彼らはアプリケーションに依存コマ落ちの危険にさらされている場合、一つは自分のブロードキャスト/マルチキャストの設定を調整する必要があります。 APは、（距離制限に従っていない）あまりにも遠くに配置される場合、これらの問題は、通常、フレームがドロップされた場合、これらの問題は、ストリーミングビデオやIPv6の基本的な動作として、実際のマルチキャストアプリケーションに影響を与えることができるなど、高い干渉、引き起こされます。基本的なIPv6通信は、重複検出（DAD）をアドレス、ルータと隣接などの機能を使用し
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.
要請（RS、NS）は、これらのフレームとして、上述した問題により影響を受ける可能性等ルータと近隣広告（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）で場合によっては複数の加入者間で共有リソースを管理するためにエッジルータに特に関連があります。しかし、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.
エッジルータでは、加入者側インターフェイスは、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セキュリティを強化するために、ホスト/ルータのために行われなければなら限られた変更があります。自動設定のためのプライバシーの拡張[RFC3041]は、セクション6.5で説明したように、ホストトレーサビリティのために同じ考慮してホストによって使用されるべきです。存在する場合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.
ホットスポットでのホスト認証はウェブベースの認証システムを使用して行われている場合、セキュリティのレベルは、特定の実装に依存するであろう。ユーザーの資格情報は、HTTP経由でクリアテキストとして送信されるべきではありません。セキュア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（Temporal Key Integrity Protocol）がおよびカウンターモード/ 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).
イーサタイプのための任意のレイヤ2つのフィルタが所定の位置にある場合、NAPは、IPv6イーサタイプ（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].
加入者（Accessまたはエッジルータ）用のレイヤ3次のホップであるデバイスは、プロバイダーのお客様のいずれかによって攻撃からネットワークや他の加入者を保護する必要があります。この理由のuRPFとACLは、加入者が直面しているすべてのインターフェイスで使用されるべきです。フィルタリングは、IPv6 [IPv6対応セキュリティ]の動作要件を考慮して実装する必要があります。
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.
（例えば等MIBモジュール、NetFlowのレコードなど）が必要計装は、IPv6のために利用可能であるべきです。
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セグメントにおける帯域幅は、そのセグメント（同じ培地 - 低電圧の変圧器に接続され、多くの場合、顧客）に接続されたすべての顧客間で共有されています。顧客の数は、このような（100-150までの少数の顧客から、ちょうど5-6、）の距離、さらには国など、さまざまな要因に応じて変化させることができます。
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
セクション7.2.1で説明したように、典型的には、ポイントツーポイントモデルで提供される第7のIP接続で説明したようにPLC / BPLの論理トポロジと設計は、イーサネットブロードバンドネットワークと非常に類似しています
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ネットワークの性質を考慮して、ポイント・ツー・ポイント、各顧客への1つとして、ネットワークを確認することです。複数の顧客が同じ物理メディアを共有する場合であっても、それぞれが3DESによって暗号化され、加えて、ある異なるチャネルを、使用しているため、トラフィックは、その中で表示されません。
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.
ホストまたはRCPEsは自分のレイヤ3ネクストホップとしてHEを持っています。
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サブネットに属しています。ホストは、HEを介してアドレスを取得するためにステートレス自動設定またはステートフルDHCPv6のベースの構成を使用することができます。
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を介して要求が続いて、順番に、/ 64Sに分割され、顧客サイトにホストを接続し、そのインタフェースに割り当てられました。これは、安価で管理が容易であること、好ましくプロビジョニング方法でなければなりません。
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.
エッジルータは、一般的には、各顧客が接頭辞/ 48を受信し、各HEは、顧客に対応することになることを考慮すると、接頭辞を持っている必要があります。したがって、各HEは、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.
自動的にプロビジョニングに必要なプレフィックスを下位階層プレフィックス委任の種類を使用することも可能で、完全にHEはを自動設定し、その結果、ネットワークの設定、操作、およびメンテナンスコストを削減することができます。
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などのホストに関心のある他の情報は、ステートフル[RFC3315]とステートレス[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.
何のルータが顧客宅内で使用されていない場合は、HEは、単純にエッジルータを指すデフォルトルートを設定することができます。ルータが顧客宅内（RCPE）で使用されている場合は、彼はまた、ERに（IS-ISまたはさえたRIPng、OSPFv3は、このようななど）IGPを実行することができます。接続されているプレフィックスは再配布されなければなりません。 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.
OSPFv3のか-IS IS：エッジルータは、NSPで使用される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ネットワークは基本的に輸送はIPv4またはIPv6であるか否か同じであるQoSをサポートします。 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をサポートする必要があります。これは、DOCSISケーブルネットワーク上で動作するようにIPv6の近隣探索のために必要とされます。追加の分類は、QoSを提供するために、CMとCMTSでのIPv6トラフィックを分類するために、DOCSIS仕様に追加する必要があります。これらの問題は、DOCSIS 3.0のケーブルLabsの[DOCSIS3.0-要求数]に行われた最近の提案で対処されています。
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展開が可能なアドレス空間がSPに異なるサブネット上のユーザーを分離する機会を与えてくれたIPv6のための最善のアプローチではないかもしれないと述べました。しかし、サポート、理由はIPv4のRBEに似た展開に発見された場合はIPv4とIPv6のRBE RBEとの違いは、第6節で強調表示された後、環境が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にマルチキャスト]に記載）の限界を指摘しました。しかし、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.
第8項に関連してE.は、懸念が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.トンネルは（GWRsかのCPE）のSP制御不能か、まだ（ケーブル）IPv6サポートを標準化していなかった技術を超えているプラットフォームでのIPv6サポートの展開依存関係を回避するための効果的な方法です。彼らは、次のように使用することができます。
i. Tunnels directly to the CPE or GWR with public or private
IPv4 addresses.
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は、SPは、各加入者を接続するリンクに固定され、グローバルにルーティング可能なプレフィックスを割り当てることができます。
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.
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の部分のために浮上しています。このアプローチは、もっとして4096人のユーザーを集約する2スイッチ、レイヤことができます。 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導入は、さらなる調査を必要とするかもしれないいくつかの問題を提起します。そのようなトピックの例は、[AUTO-CONFIG]：
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].
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].
私たちは、彼らの貴重なコメントのためにブライアン・カーペンター、パトリックGrossetete、Toerlessエッカート、マドゥスーダン、シャノン・マクファーランド、ブノワLourdelet、およびフレッドベイカーに感謝したいと思います。著者は、「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.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC2080]マルキン、G.およびR. Minnear、 "IPv6のためのRIPng"、RFC 2080、1997年1月。
[RFC2364] Gross, G., Kaycee, M., Lin, A., Malis, A., and J. Stephens, "PPP Over AAL5", RFC 2364, July 1998.
[RFC2364]グロス、G.、Kaycee、M.、リン、A.、Malis、A.、およびJ.スティーブンス、 "PPPオーバー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.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]コンタ、A.、およびS.デアリング、 "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.、カレル、D.、シモン、D.、およびR.ウィーラー、 "PPPオーバーイーサネット（PPPoEを）送信するための方法"、RFC 2516年2月1999。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2529]カーペンター、B.及びC.チョン、 "明示的なトンネルなしでの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.、バレンシア、A.、ルーベンス、A.、ポール、G.、ツォルン、G.、およびB. Palter、 "レイヤ2トンネリングプロトコル "L2TP""、RFC 2661、1999年8月。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[RFC2740] Coltun、R.、ファーガソン、D.、およびJ.モイ、 "IPv6のためのOSPF"、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]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（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におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053]デュラン、A.、ファザーノ、P.、Guardini、I.、およびD.レント、 "IPv6のトンネルブローカー"、RFC 3053、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[RFC3177] IABとIESG、RFC 3177、2001年9月 "サイトへのIPv6アドレスの割り当てにIAB / IESG勧告"。
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001.
[RFC3180]マイヤー、D.およびP. Lothberg、 "8分の233にアドレッシング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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]フェナー、B.とD.マイヤー、 "は、Multicast Source Discovery Protocol（MSDP）"、RFC 3618、2003年10月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、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.のファンデルポール、 "非管理ネットワークの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]ラウ、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]ダニエル、M.、ハーバーマン、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]リンド、M.、Ksinant、V.、公園、S.、ボドー、A.、およびP. Savola、 "ISPネットワークにIPv6を導入するためのシナリオと分析"、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.ターラー、 "デフォルトルータの設定と、より詳細なルート"、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.ギリガン、 "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]テンプリン、F.、グリーソン、T.、Talwar、M.、およびD.ターラーは、 "イントラサイト自動トンネルプロトコル（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：ネットワークアドレス変換を通じてUDP経由トンネリングのIPv6器（NAT）"、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]デClercq、J.、Ooms、D.、プレボ、S.、およびF.ルFaucheur、 "BGPでIPv4の雲の間でIPv6の島を接続する"、進歩、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]温家宝、H.、朱、X.、江、Y.、およびR.ヤン、 "アクセスネットワークにおけるIPv6ステートレス自動設定の展開"、電気通信第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.、ガル、A.、リンガード、J.、およびS. Venaas、 "PIMブートストラップルータ（BSR）メカニズム"、進歩、2006年6月に働いています。
[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-要求数] Droms、R.、デュラン、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.、ディアス、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 802.1X STD-2001"、2001年6月。
[IPv6-Multicast] Savola, P., "IPv6 Multicast Deployment Issues", Work in Progress, April 2004.
[IPv6の-マルチキャスト] Savola、P.、 "IPv6マルチキャストデプロイの問題"、進歩、2004年4月に作業。
[IPv6-Security] Convery, S. and D. Miller, "IPv6 and IPv4 Threat Comparison and Best-Practice Evaluation", March 2004.
[IPv6の-セキュリティ] Convery、S.および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-CASES] 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.、オルベラ、C.、およびD.フェルナンデス、 "NATボックスでプロトコル41の転送"、進歩、2003年10月に作業。
[RF-Interface] CableLabs, CL., "DOCSIS 2.0(CM-SP-RFIv2.0-I10- 051209)", December 2005.
[RF-インタフェース] 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.ブレイク、 "MAC-強制フォワーディング：イーサネット・アクセス・ネットワーク上の加入者を分離する方法"、RFC 4562、2006年6月。
[Softwire] Dawkins, S., Ed., "Softwire Problem Statement", Work in Progress, May 2006.
[Softwire]ドーキンス、S.、エド。、 "Softwire問題文"、進歩、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.、親、F.、デュラン、A.、Suryanarayanan、R.、およびP. Savola、 "トンネリング設定の目標"、進歩、2005年8月ワーク。
Authors' Addresses
著者のアドレス
Salman Asadullah Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
サルマンAsadullahシスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134 USA
Phone: 408 526 8982 EMail: sasad@cisco.com
電話：408 526 8982 Eメール：sasad@cisco.com
Adeel Ahmed Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA
アディール・アーメドシスコシステムズ2200東ブッシュ大統領ターンパイクリチャードソン、TX 75082 USA
Phone: 469 255 4122 EMail: adahmed@cisco.com
電話：469 255 4122 Eメール：adahmed@cisco.com
Ciprian Popoviciu Cisco Systems 7025-6 Kit Creek Road Research Triangle Park, NC 27709 USA
シプリアンPopoviciu 7025から6シスコシステムズキットクリーク道路リサーチトライアングルパーク、NC 27709 USA
Phone: 919 392 3723 EMail: cpopovic@cisco.com
電話：919 392 3723 Eメール：cpopovic@cisco.com
Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland
ペッカSavola CSC - 科学計算株式会社エスポー、フィンランド
EMail: psavola@funet.fi
メールアドレス：psavola@funet.fi
Jordi Palet Martinez Consulintel San Jose Artesano, 1 Alcobendas, Madrid E-28108 Spain
ジョルディPaletマルティネスConsulintelサンノゼArtesano 1つのアルコベンダス、マドリッドE-28108スペイン
Phone: +34 91 151 81 99 EMail: jordi.palet@consulintel.es
電話：+34 91 151 81 99 Eメール：jordi.palet@consulintel.es
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。