RFC4779 日本語訳
4779 ISP IPv6 Deployment Scenarios in Broadband Access Networks. S.Asadullah, A. Ahmed, C. Popoviciu, P. Savola, J. Palet. January 2007. (Format: TXT=188511 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Asadullahがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4779年のA.アフマドカテゴリ: 情報のC.のP.Savola CSC/FUNET J.殻Consulintel Popoviciuシスコシステムズ2007年1月
ISP IPv6 Deployment Scenarios in Broadband Access Networks
広帯域アクセスネットワークにおけるISP IPv6展開シナリオ
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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サービスとの共存で今日のService Provider(SP)ブロードバンド(掲示板)ネットワークにIPv6展開、統合メソッド、およびシナリオの詳述を提供します。 ケーブル/HFC、掲示板イーサネット、xDSL、およびWLANは現在配布されて、本書では議論する主な掲示板技術です。 また、完全性のために現れているBroadband Power線Communications(PLC/BPL)アクセス技術について議論します。 本書では私たちは、トンネリングメカニズムとネイティブのIPv6を使用することでIPv6がどうそれぞれのこれらのネットワークにIPv6掲示板ネットワークの主な成分と、IPv4掲示板ネットワークからのそれらの違いと、配布されて、統合されるかについて議論するつもりです。
Asadullah, et al. Informational [Page 1] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[1ページ]のRFC4779ISP 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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 4 2。 一般的な用語. . . . . . . . . . . . . . . . . . . . . . 5 3。 コア/バックボーンネットワーク. . . . . . . . . . . . . . . . . . . . 5 3.1。 2アクセスプロバイダネットワーク. . . . . . . . . . . . . 5 3.2を層にしてください。 3アクセスプロバイダネットワーク. . . . . . . . . . . . . 6 4を層にしてください。 概要. . . . . . . . . . . . . . . . . . . . . . 7 4.1にトンネルを堀ります。 Tunnelsの上のアクセス--公共のIPv4アドレス. . . . . . . . . . . . . . . . . . . . . . . . 7 4.2をもっている顧客。 Tunnelsの上のアクセス--個人的なIPv4アドレス. . . . . . . . . . . . . . . . . . . . . . . . 8 4.3をもっている顧客。 変遷はIPv4インフラストラクチャ. . . . . 8 5の部分です。 広帯域のケーブルネットワーク. . . . . . . . . . . . . . . . . . . 9 5.1。 広帯域のケーブルネットワーク要素. . . . . . . . . . . . . 9 5.2。 ケーブルネットワーク. . . . . . . . . . . . . 10 5.2.1でIPv6を配布します。 ブリッジしているCMTSのIPv6にネットワーク. . . . . . . 12 5.2.2を配布します。 発送されたCMTSのIPv6にネットワーク. . . . . . . 14 5.2.3を配布します。 IPv6マルチキャスト. . . . . . . . . . . . . . . . . . . . 23 5.2.4。 IPv6 QoS. . . . . . . . . . . . . . . . . . . . . . . 24 5.2.5。 IPv6セキュリティ問題. . . . . . . . . . . . . 24 5.2.6。 IPv6ネットワークマネージメント. . . . . . . . . . . . . . . 25 6。 ブロードバンドDSLは.266.1をネットワークでつなぎます。 DSLは要素. . . . . . . . . . . . . . . . . . . 26 6.2をネットワークでつなぎます。 IPv4 DSLネットワーク. . . . . . . . . . . 28 6.2で.1にIPv6を配布します。 二地点間モデル. . . . . . . . . . . . . . . . . 29 6.2.2。 pppは集合(PTA)モデル. . . . . . . . 30 6.2.3を終えました。 L2TPv2は集合(LAA)モデル. . . . . . . . 33 6.2.4にアクセスします。 IPv4のハイブリッド・モデルとIPv6は.366.3を修理します。 IPv6マルチキャスト. . . . . . . . . . . . . . . . . . . . . . 38 6.3.1。 ASMベースの展開. . . . . . . . . . . . . . . . 39 6.3.2。 SSMベースの展開. . . . . . . . . . . . . . . . 39 6.4。 IPv6 QoS. . . . . . . . . . . . . . . . . . . . . . . . . 40 6.5。 IPv6セキュリティ問題. . . . . . . . . . . . . . . 41 6.6。 IPv6ネットワークマネージメント. . . . . . . . . . . . . . . . . 42 7。 広帯域のイーサネットは.427.1をネットワークでつなぎます。 イーサネットはネットワーク要素. . . . . . . . . . . . . 42 7.2にアクセスします。 IPv4の広帯域のイーサネットネットワーク. . . . 43 7.2で.1にIPv6を配布します。 二地点間モデル. . . . . . . . . . . . . . . . . 44 7.2.2。 pppは集合(PTA)モデル. . . . . . . . 46 7.2.3を終えました。 L2TPv2は集合(LAA)モデル. . . . . . . . 48 7.2.4にアクセスします。 IPv4のハイブリッド・モデルとIPv6は.507.3を修理します。 IPv6マルチキャスト. . . . . . . . . . . . . . . . . . . . . . 52 7.4。 IPv6 QoS. . . . . . . . . . . . . . . . . . . . . . . . . 53 7.5。 IPv6セキュリティ問題. . . . . . . . . . . . . . . 54 7.6。 IPv6ネットワークマネージメント. . . . . . . . . . . . . . . . . 55
Asadullah, et al. Informational [Page 2] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[2ページ]のRFC4779ISP IPv6展開シナリオ
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
8. ワイヤレスのLAN. . . . . . . . . . . . . . . . . . . . . . . . . 55 8.1。 WLAN展開シナリオ. . . . . . . . . . . . . . . . 55 8.1.1。 Layer3終了でNSP Edge Router. . . . . . . . . . . . . . . . . . . . . . . . 56 8.1.2で2NAPを層にしてください。 アクセスルータ. . . . . . . . . . . . . . . . . . . . 59 8.1.3で層3の終了との3の意識している仮眠を層にしてください。 pppベースのモデル. . . . . . . . . . . . . . . . . . . 61 8.2。 IPv6マルチキャスト. . . . . . . . . . . . . . . . . . . . . . 63 8.3。 IPv6 QoS. . . . . . . . . . . . . . . . . . . . . . . . . 65 8.4。 IPv6セキュリティ問題. . . . . . . . . . . . . . . 65 8.5。 IPv6ネットワークマネージメント. . . . . . . . . . . . . . . . . 67 9。 広帯域の電力線通信(PLC).679.1。 PLC/BPLはネットワーク要素. . . . . . . . . . . . . 68 9.2にアクセスします。 IPv4 PLC/BPL. . . . . . . . . . . . . . 69 9.2.1でIPv6を配布します。 IPv6は.2にインフラストラクチャ変化. . . . . . . . . 69 9.2を関係づけました。 アドレシング. . . . . . . . . . . . . . . . . . . . . . 69 9.2.3。 ルート設定. . . . . . . . . . . . . . . . . . . . . . . 70 9.3。 IPv6マルチキャスト. . . . . . . . . . . . . . . . . . . . . . 71 9.4。 IPv6 QoS. . . . . . . . . . . . . . . . . . . . . . . . . 71 9.5。 IPv6セキュリティ問題. . . . . . . . . . . . . . . 71 9.6。 IPv6ネットワークマネージメント. . . . . . . . . . . . . . . . . 71 10。 ギャップ分析. . . . . . . . . . . . . . . . . . . . . . . . . 71 11。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 74 12。 承認. . . . . . . . . . . . . . . . . . . . . . . 74 13。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 74 13.1。 引用規格. . . . . . . . . . . . . . . . . . . 74 13.2。 有益な参照. . . . . . . . . . . . . . . . . . 76
Asadullah, et al. Informational [Page 3] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[3ページ]のRFC4779ISP IPv6展開シナリオ
1. Introduction
1. 序論
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.
このドキュメントは掲示板Service Provider(SP)ネットワークのアクセス一部でIPv6にサービスを配布するのにおいて利用可能なオプションを提示します--すなわち、Cable/HFC、掲示板イーサネット、xDSL、WLAN、およびPLC/BPL。
This document briefly discusses the other elements of a provider network as well. It provides different viable IPv6 deployment and integration techniques, and models for each of the above-mentioned BB technologies individually. The example list is not exhaustive, but it tries to be representative.
このドキュメントは簡潔にまた、プロバイダーネットワークの他の原理について議論します。 それは個別に異なった実行可能なIPv6展開、統合のテクニック、およびモデルをそれぞれの上記の掲示板技術に提供します。 例のリストは徹底的ではありませんが、それは代表するようになろうとします。
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ベースのCable/HFC、掲示板イーサネット、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
Service(QoS)パラメタのF.の必要なIPv6 Quality
G. Required IPv6 Security parameters
G.の必要なIPv6 Securityパラメタ
H. Required IPv6 Network Management parameters
H.の必要なIPv6 Network Managementパラメタ
It is important to note that the addressing rules provided throughout this document represent an example that follows the current assignment policies and recommendations of the registries. However, they can be adapted to the network and business model needs of the ISPs.
このドキュメント中で提供されたアドレシング規則が登録の現在の課題方針と推薦に従う例を表すことに注意するのは重要です。 しかしながら、ISPのネットワークとビジネスモデルの必要性にそれらを適合させることができます。
The scope of the document is to advise on the ways of upgrading an existing infrastructure to support IPv6 services. The recommendation to upgrade a device to dual stack does not stop an SP from adding a new device to its network to perform the necessary IPv6 functions discussed. The costs involved with such an approach could be offset by lower impact on the existing IPv4 services.
ドキュメントの範囲はIPv6にサービスをサポートする既存のインフラストラクチャをアップグレードさせる方法の助言を与えることになっています。 デバイスをデュアルスタックにアップグレードさせるという推薦は、SPが議論した必要なIPv6機能を実行するために新しいデバイスをネットワークに追加するのを止めません。 下側の影響は既存のIPv4サービスのときにそのようなアプローチに伴われるコストを相殺できました。
Asadullah, et al. Informational [Page 4] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[4ページ]のRFC4779ISP IPv6展開シナリオ
2. Common Terminology
2. 一般的な用語
BB: Broadband
掲示板: ブロードバンド
CPE: Customer Premise Equipment
CPE: 顧客前提設備
GWR: Gateway Router
GWR: ゲートウェイルータ
ISP: Internet Service Provider
ISP: インターネットサービスプロバイダ
NAP: Network Access Provider
以下を毛羽立ててください。 ネットワークアクセスプロバイダ
NSP: Network Service Provider
NSP: ネットワーク・サービスプロバイダー
QoS: Quality of Service
QoS: サービスの質
SP: Service Provider
SP: サービスプロバイダー
3. Core/Backbone Network
3. コア/バックボーンネットワーク
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:
Broadband展開で特定された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.アクセスプロバイダネットワーク: このネットワークは、広帯域アクセスを提供して、加入者に集められます。 加入者トラフィックはLayer2か3でService Providerに引き渡されます。
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.
Accessプロバイダーに連結するEdge Routersを超えたService Providerネットワーク構造はこのドキュメントの範囲を超えています。
3.1. Layer 2 Access Provider Network
3.1. 層2のアクセスプロバイダネットワーク
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.
Access ProviderはLayer2ネットワークを配布して、加入者トラフィックを掘ることをSPに実行できません。 それぞれの特定のアクセスが技術であるとサポートするデバイスは非常に余分で、弾力があって、スケーラブルなLayer2コアに集められます。 ネットワークコアはイーサネットなどの様々な技術、Asynchronous Transfer Mode(ATM)などにかかわることができます。 Service Provider Edge RouterはAccess Providerコアに接続します。
Asadullah, et al. Informational [Page 5] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[5ページ]のRFC4779ISP IPv6展開シナリオ
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).
このタイプのネットワークはLayer3プロトコルに見え透いているかもしれません。 IPv6をサポートする意図がメカニズムに食糧を供給して、フィルターにかけて、IPv6トラフィックをモニターするのがIPv6 Ether Type Protocol IDなどのLayer2情報(0x86DD)かIPv6マルチキャスト特定のメディアAccess Control(MAC)アドレス(33:33:xx:xx:xx:xx)に基づいていて、いくつかの可能な変化が来るかもしれません。
3.2. Layer 3 Access Provider Network
3.2. 層3のアクセスプロバイダネットワーク
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.
Access ProviderはLayer2ドメインを終えて、IPトラフィックをService Providerネットワークに発送するのを選ぶことができます。 アクセスRoutersは、SP Edge RoutersへのLayer3コアの上に加入者トラフィックに集めて、それを発送するのに使用されます。 この場合、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.
ケーススタディは本書ではそのようなネットワークの関連ネットワーク原理だけについて議論します: 顧客前提設備、アクセスルータ、および縁のルータ。 本当のネットワークに、Access RouterとEdge Routerとのリンクは集合の一部とAccess Providerネットワークのコア層である他のルータにかかわります。
The Access Provider can forward the IPv6 traffic through its Layer 3 core in three possible ways:
Access Providerは3つの可能な方法でLayer3コアを通して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トンネリング: 一時的な解決として、Access Providerは、加入者IPv6トラフィックをService Provider Edge Routerに送るのにトンネリングメカニズムを使用するのを選ぶことができます。 このアプローチはAccess Providerネットワークに最少の影響力を持っています。 しかしながら、ユーザの数が増加して、IPv6トラフィックの量が成長するのに従って、ISPは以下に記載されたシナリオの1つに発展しなければならないでしょう。
B. Native IPv6 Deployment: The Access Provider routers are upgraded
to support IPv6 and can become dual stack. In a dual-stack
network, an IPv6 Interior Gateway Protocol (IGP), such as OSPFv3
[RFC2740] or IS-IS [ISISv6], is enabled. RFC 4029 [RFC4029]
discusses the IGP selection options with their benefits and
drawbacks.
B.のネイティブのIPv6展開: Access Providerルータは、IPv6をサポートするためにアップグレードして、デュアルスタックになることができます。 または、デュアルスタックネットワーク、OSPFv3などのIPv6 Interiorゲートウェイプロトコル(IGP)[RFC2740]、-、[ISISv6]、可能にされます。 RFC4029[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]: Access Providerが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
6PEアプローチには、Access Providerネットワークに最小量の影響力を持つ利点があります。 そしてより少ないデバイスが、アップグレードする必要がある。
Asadullah, et al. Informational [Page 6] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[6ページ]のRFC4779ISP IPv6展開シナリオ
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.
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]で、より詳細なCore Network展開推薦について議論します。 このドキュメントの残りのためにAccess Provider NetworkのCoreのIPv6トラフィックの取り扱いについて議論しないでしょう。
4. Tunneling Overview
4. トンネリング概要
If SPs are not able to deploy native IPv6, they might use tunneling- based transition mechanisms to start an IPv6 service offering, and move to native IPv6 deployment at a later time.
SPsがネイティブのIPv6を配布することができないなら、彼らは、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を輸送するために開発されました。 それらの数個が標準化されました、そして、彼らの使用はIPv6サービスの既存のSP IPv4ネットワークと構造に依存します。 最も適切なメカニズムのための要件は[v6tc]で、より多くのアップデートで説明されて、続きます。 トンネリングのテクニックを使用することでIPv6を配布すると、トンネルエンドポイントでソフトウェアをアップグレードさせるほど少ししかネットワークへの変化を含意できません。 Service Providerは以下のシナリオでIPv6を配布するのにトンネリングを使用できました:
4.1. Access over Tunnels - Customers with Public IPv4 Addresses
4.1. Tunnelsの上のアクセス--公共のIPv4アドレスをもっている顧客
If the customer is a residential user, it can initiate the tunnel directly from the IPv6 capable host to a tunnel termination router located in the NAP or ISP network. The tunnel type used should be decided by the SP, but it should take into consideration its availability on commonly used software running on the host machine. Of the many tunneling mechanisms developed, such as IPv6 Tunnel Broker [RFC3053], Connection of IPv6 Domains via IPv4 Clouds [RFC3056], Generic Packet Tunneling in IPv6 [RFC2473], ISATAP [RFC4214], Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213], and Transmission of IPv6 over IPv4 Domains without Explicit Tunnels [RFC2529], some are more popular than the others. At the time of writing this document, the IETF Softwire Working Group was tasked with standardizing a single tunneling protocol [Softwire] for this application.
顧客が住宅のユーザであるなら、それは直接IPv6の有能なホストからNAPかISPネットワークで位置するトンネル終了ルータまでトンネルを開始できます。 タイプが使用したトンネルはSPによって決められるはずですが、それは、ホスト・マシンで動きながら、一般的に使用されたソフトウェアの上で有用性を考慮に入れるべきです。 トンネリングメカニズムがIPv6 Tunnel Broker[RFC3053]や、IPv4 Cloudsを通したIPv6 DomainsのConnection[RFC3056]や、IPv6のGeneric Packet Tunneling[RFC2473]や、ISATAP[RFC4214]や、IPv6 HostsのためのBasic Transition MechanismsとRouters[RFC4213]や、IPv6のTransmissionなどのようにIPv4 Domainsの上でExplicit Tunnels[RFC2529]なしで開発した多くでは、或るものは他のものよりポピュラーです。 これを書いている時点でこのドキュメント、IETF Softwire作業部会はこのアプリケーションのために、ただ一つのトンネリングプロトコル[Softwire]を標準化するのに仕事を課されました。
Asadullah, et al. Informational [Page 7] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[7ページ]のRFC4779ISP IPv6展開シナリオ
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をサポートするためにデュアルスタックにアップグレードする必要があるでしょう。 顧客かSPがGWRを所有できます。
4.2. Access over Tunnels - Customers with Private IPv4 Addresses
4.2. Tunnelsの上のアクセス--個人的なIPv4アドレスをもっている顧客
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アドレスを受け取って、Network Address Translation(NAT)を通してトンネルを開始する必要があるなら、彼らが公共のIPv4アドレスを当てにするので、6to4のようなテクニックは利かないかもしれません。 この場合、既存のGWRsが、プロトコル-41推進が[Protocol41]であるとサポートしないなら、エンドユーザはNATs(Teredo[RFC4380]などの)を通して作動できるトンネルを使用しなければならないかもしれません。 ほとんどのGWRsがホストがトンネルを開始できることを意味するプロトコル41推進をサポートします--その場合、GWRはIPv6サービスで影響を受けません。
The customer has the option to initiate the tunnel from the device (GWR) that performs the NAT functionality, similar to the GWR scenario discussed in Section 4.1. This will imply hardware replacement or software upgrade and a native IPv6 environment behind the GWR.
顧客には、NATの機能性を実行するデバイス(GWR)からトンネルを開始するオプションがあります、セクション4.1で議論した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の上で既に確立したIPv4 IPsecセッションでIPv6トンネルを開始するとあるレベルのセキュリティがIPv6トラフィックに提供されるのを観測する価値があります。
4.3. Transition a Portion of the IPv4 Infrastructure
4.3. 変遷はIPv4インフラストラクチャの部分です。
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トラフィックを輸送するのにTunnelsを使用できます。 例として、顧客はネイティブにNetwork Access Providerに接続するかもしれません。そこでは、トンネルが、ISPへのIPv4の上にトラフィックを通過するのに使用されます。 この場合、このトンネル選択は能力次第です。(それはマルチキャスト) 使用される(Layer2メッセージを輸送できるいくつかのタイプがあります、GRE[RFC2784]、L2TPv3[RFC3931]、またはpseudowireなどのように)プロトコルを発送することでの管理可能性をサポートするかどうか、そして、例えば、スケーラビリティ(静的なトンネルに対してダイナミックな)。
This scenario implies that the access portion of the network has been upgraded to support dual stack, so the savings provided by tunneling in this scenario are very small compared with the previous two scenarios. Depending on the number of sites requiring the service, and considering the expenses required to manage the tunnels (some tunnels are static while others are dynamic [DynamicTunnel]) in this case, the SPs might find the native approach worth the additional investments.
このシナリオが、ネットワークのアクセス一部がデュアルスタックをサポートするためにアップグレードしたのを含意するので、このシナリオでトンネルを堀ることによって提供された貯蓄は前の2つのシナリオと比べて非常にわずかです。 サービスを必要として、費用がこの場合トンネル(他のものはダイナミックですが[DynamicTunnel]、いくつかのトンネルが静的である)を管理するのが必要であると考える場合サイトの数によって、SPsは、ネイティブのアプローチは追加出資の価値があるのがわかるかもしれません。
Asadullah, et al. Informational [Page 8] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[8ページ]のRFC4779ISP IPv6展開シナリオ
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]で手広く様々なトンネルタイプの操作、能力、および展開について議論しました。 このドキュメントの次のセクションでトンネルベースの展開の詳細を提供します。(それは、Cable Accessに関するケースについて論じます)。(そこでは、現在のData Over Cable Service Interface Specification(DOCSIS2.0)[RF-インタフェース]と先の仕様がネイティブのIPv6アクセサリーのサポートを提供しません)。 ネイティブのIPv6の上のセクション6、7、8、および9焦点ですが、DSL、ファイバー・トゥ・ザ・ホーム(FTTH)、ワイヤレス、およびPLC/BPLの上の展開であり、また、このアプローチが今日完全にサポートされるので、トンネルベースのソリューションもこのセクションのガイドラインとセクション5に提供された推薦のいくつかに基づくこれらの場合で可能です。
5. Broadband Cable Networks
5. 広帯域のケーブルネットワーク
This section describes the infrastructure that exists today in cable networks providing BB services to the home. It also describes IPv6 deployment options in these cable networks.
このセクションは今日ホームに対する掲示板サービスを提供するケーブルネットワークで存在するインフラストラクチャについて説明します。 また、それはこれらのケーブルネットワークでIPv6展開オプションについて説明します。
DOCSIS standardizes and documents the operation of data over cable networks. DOCSIS 2.0 and prior specifications have limitations that do not allow for a smooth implementation of native IPv6 transport. Some of these limitations are discussed in this section. For this reason, the IPv6 deployment scenarios discussed in this section for the existing cable networks are tunnel based. The tunneling examples presented here could also be applied to the other BB technologies described in Sections 6, 7, 8, and 9.
DOCSISはケーブルネットワークの上にデータの操作を標準化して、記録します。 DOCSIS2.0と先の仕様には、ネイティブのIPv6輸送の滑らかな実装を考慮しない制限があります。 このセクションでこれらの制限のいくつかについて議論します。 この理由で、既存のケーブルネットワークのためにこのセクションで議論したIPv6展開シナリオは基づくトンネルです。 また、セクション6、7、8、および9で説明された他の掲示板技術にここに提示されたトンネリングの例は適用できました。
5.1. Broadband Cable Network Elements
5.1. 広帯域のケーブルネットワークElements
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)は以下を植えます。 基本的な輸送として使用されるハイブリッドFiber Coaxialプラント
CMTS: Cable Modem Termination System (can be a Layer 2 bridging or Layer 3 routing CMTS)
CMTS: ケーブルモデム終了システム(Layer2のブリッジするかLayer3ルーティングCMTSであることができます)
Asadullah, et al. Informational [Page 9] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[9ページ]のRFC4779ISP IPv6展開シナリオ
GWR: Residential Gateway Router (provides Layer 3 services to hosts)
GWR: 住宅のゲートウェイルータ(ホストに対するサービスをLayer3に供給します)
Host: PC, notebook, etc., which is connected to the CM or GWR
以下を接待してください。 PC、ノート、など、どれがCMに関連づけられるか、そして、またはGWR
CM: Cable Modem
CM: ケーブルモデム
ER: Edge Router
えー: 縁のルータ
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 -----|
|--- アクセス---||------ HFC------||----- 集合/コア-----|
+-----+ +------+
|Host |--| GWR |
+-----+ +--+---+
| _ _ _ _ _ _
+------+ | |
| CM |---| |
+------+ | |
| HFC | +------+ +--------+
| | | | | Edge |
+-----+ +------+ | Network |---| CMTS |---| |=>ISP
|Host |--| CM |---| | | | | Router | Network
+-----+ +--+---+ | | +------+ +--------+
|_ _ _ _ _ _|
+------+ |
+-----+ | GWR/ | |
|Host |--| CM |---------+
+-----+ | |
+------+
+-----+ +------+ |ホスト|--| GWR| +-----+ +--+---+ | _ _ _ _ _ _ +------+ | | | CM|---| | +------+ | | | HFC| +------+ +--------+ | | | | | 縁| +-----+ +------+ | ネットワーク|---| CMTS|---| |=>ISP|ホスト|--| CM|---| | | | | ルータ| ネットワーク+-----+ +--+---+ | | +------+ +--------+ |_ _ _ _ _ _| +------+ | +-----+ | GWR/| | |ホスト|--| CM|---------+ +-----+ | | +------+
Figure 5.1
図5.1
5.2. Deploying IPv6 in Cable Networks
5.2. ケーブルネットワークでIPv6を配布します。
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
MSOがケーブルネットワークの上でIPv6を配布する動機付け要因のひとりは管理負担をゆるめることになっています。 管理目的のためにCM、CMTS、およびERでIPv6を有効にすることができます。 現在の、ケーブルインフラストラクチャの部分はIPv4アドレス空間[RFC1918]を使用します。 しかしながら、有限数のものがあります。 したがって、IPv6はケーブルスペースのユーティリティが初めは、管理飛行機の上で実装されて、焦点を合わせられるのをさせることができました。
Asadullah, et al. Informational [Page 10] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[10ページ]のRFC4779ISP IPv6展開シナリオ
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.
後でのエンドユーザサービスのためのデータ飛行機に関して。 管理にケーブルネットワークに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.
現在のケーブルネットワークには2つの異なった展開モードがあります: ブリッジしているCMTS環境と発送されたCMTS環境。 これらの環境の両方でIPv6を配布することができます。
1. Bridged CMTS Network
1. CMTSネットワークであるとブリッジされます。
In this scenario, both the CM and CMTS bridge all data traffic. Traffic to/from host devices is forwarded through the cable network to the ER. The ER then routes traffic through the ISP network to the Internet. The CM and CMTS support a certain degree of Layer 3 functionality for management purposes.
このシナリオでは、CMとCMTSの両方が、すべてのデータがトラフィックであるとブリッジします。 ケーブルネットワークを通してホストデバイスからの/へのトラフィックをERに送ります。 そして、ERはISPネットワークを通してトラフィックをインターネットに発送します。 CMとCMTSは管理目的のためのある度合いのLayer3の機能性をサポートします。
2. Routed CMTS Network
2. 発送されたCMTSネットワーク
In a routed network, the CMTS forwards IP traffic to/from hosts based on Layer 3 information using the IP source/destination address. The CM acts as a Layer 2 bridge for forwarding data traffic and supports some Layer 3 functionality for management purposes.
発送されたネットワークでは、CMTSはIPソース/送付先アドレスを使用することでLayer3情報に基づくホストからの/にIPトラフィックを送ります。 CMは、Layer2が、推進のためにデータがトラフィックであるとブリッジするとき行動して、いくらかのLayerが管理目的のための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.
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.
C. Classification of IPv6 traffic in the upstream and downstream
direction. The CM and CMTS will need to support classification
of IPv6 packets in order to give them the appropriate priority
and QoS. Service providers that wish to deploy QoS mechanisms
also have to support classification of IPv6 traffic.
C. 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.
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
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
Asadullah, et al. Informational [Page 11] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah, et al. Informational [Page 11] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
sections will cover tunneling and native IPv6 deployment scenarios in more detail.
sections will cover tunneling and native IPv6 deployment scenarios in more detail.
5.2.1. Deploying IPv6 in a Bridged CMTS Network
5.2.1. Deploying IPv6 in a Bridged CMTS Network
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.
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.
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.
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 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 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.
Figure 5.2.1 illustrates the IPv6 deployment scenario.
Figure 5.2.1 illustrates the IPv6 deployment scenario.
+-----+ +-----+
|Host |--| GWR |
+-----+ +--+--+
| _ _ _ _ _ _
| +------+ | |
+--| CM |---| |
+------+ | |
| HFC | +------+ +--------+
| | | | | Edge |
+-----+ +------+ | Network |---| CMTS |--| |=>ISP
|Host |--| CM |---| | | | | Router |Network
+-----+ +------+ | | +------+ +--------+
|_ _ _ _ _ _|
|-------------||---------------------------------||---------------|
L3 Routed L2 Bridged L3 Routed
+-----+ +-----+ |Host |--| GWR | +-----+ +--+--+ | _ _ _ _ _ _ | +------+ | | +--| CM |---| | +------+ | | | HFC | +------+ +--------+ | | | | | Edge | +-----+ +------+ | Network |---| CMTS |--| |=>ISP |Host |--| CM |---| | | | | Router |Network +-----+ +------+ | | +------+ +--------+ |_ _ _ _ _ _| |-------------||---------------------------------||---------------| L3 Routed L2 Bridged L3 Routed
Figure 5.2.1
Figure 5.2.1
Asadullah, et al. Informational [Page 12] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah, et al. Informational [Page 12] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
5.2.1.1. IPv6 Related Infrastructure Changes
5.2.1.1. IPv6 Related Infrastructure Changes
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.
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.
5.2.1.2. Addressing
5.2.1.2. Addressing
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.
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.
5.2.1.2.1. IP Addressing for CM
5.2.1.2.1. IP Addressing for CM
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.
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.
5.2.1.2.2. IP Addressing for Hosts
5.2.1.2.2. IP Addressing for Hosts
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.
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.
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).
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).
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.
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.
5.2.1.2.3. IP Addressing for GWR
5.2.1.2.3. IP Addressing for GWR
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.
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.
Asadullah, et al. Informational [Page 13] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah, et al. Informational [Page 13] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
5.2.1.3. Data Forwarding
5.2.1.3. Data Forwarding
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.
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.
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.
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.
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.
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.
5.2.1.4. Routing
5.2.1.4. Routing
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.
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.
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.
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.
5.2.2. Deploying IPv6 in a Routed CMTS Network
5.2.2. Deploying IPv6 in a Routed CMTS Network
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.
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.
When deploying IPv6, the CMTS/ER will need to either tunnel IPv6 traffic or natively support IPv6.
When deploying IPv6, the CMTS/ER will need to either tunnel IPv6 traffic or natively support IPv6.
Asadullah, et al. Informational [Page 14] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah, et al. Informational [Page 14] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
There are five possible deployment scenarios for IPv6 in a routed CMTS network:
There are five possible deployment scenarios for IPv6 in a routed CMTS network:
1. IPv4 Cable (HFC) Network
1. IPv4 Cable (HFC) Network
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.
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.
2. IPv4 Cable (HFC) Network, GWR at Customer Site
2. IPv4 Cable (HFC) Network, GWR at Customer Site
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.
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.
3. Dual-stacked Cable (HFC) Network, CM, and CMTS Support IPv6
3. Dual-stacked Cable (HFC) Network, CM, and CMTS Support IPv6
In this scenario, the CMTS is upgraded to dual stack to support IPv4 and IPv6. Since the CMTS supports IPv6, it can act as an ER as well. The CM will act as a Layer 2 bridge, but will need to bridge IPv6 unicast and multicast traffic. This scenario is not easy to deploy since it requires changes to the DOCSIS specification. The CM and CMTS may require hardware and software upgrades to support IPv6.
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.
4. Dual-stacked Cable (HFC) Network, Standalone GWR, and CMTS Support IPv6
4. Dual-stacked Cable (HFC) Network, Standalone GWR, and CMTS Support 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.
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.
5. Dual-stacked Cable (HFC) Network, Embedded GWR/CM, and CMTS Support IPv6
5. Dual-stacked Cable (HFC) Network, Embedded GWR/CM, and CMTS Support IPv6
In this scenario, the CM and GWR functionality exists on a single device, which needs to be upgraded to dual stack. The CMTS will also need to be upgraded to a dual-stack device. This scenario is also difficult to deploy in existing cable network since it requires changes on the Embedded GWR/CM and the CMTS.
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.
The DOCSIS specification will also need to be modified to allow native IPv6 support on the Embedded GWR/CM.
The DOCSIS specification will also need to be modified to allow native IPv6 support on the Embedded GWR/CM.
Asadullah, et al. Informational [Page 15] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah, et al. Informational [Page 15] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
5.2.2.1. IPv4 Cable Network, Host, and ER Upgraded to Dual Stack
5.2.2.1. IPv4 Cable Network, Host, and ER Upgraded to Dual Stack
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.
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.
Figure 5.2.2.1 illustrates this deployment scenario.
Figure 5.2.2.1 illustrates this deployment scenario.
+-----------+ +------+ +--------+
+-----+ +-------+ | Cable | | | | Edge |
|Host |--| CM |----| (HFC) |---| CMTS |---| |=>ISP
+-----+ +-------+ | Network | | | | Router |Network
+-----------+ +------+ +--------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel
+-----------+ +------+ +--------+ +-----+ +-------+ | Cable | | | | Edge | |Host |--| CM |----| (HFC) |---| CMTS |---| |=>ISP +-----+ +-------+ | Network | | | | Router |Network +-----------+ +------+ +--------+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() IPv6-in-IPv4 tunnel
|---------||---------------------------------------||------------|
IPv4/v6 IPv4 only IPv4/v6
|---------||---------------------------------------||------------| IPv4/v6 IPv4 only IPv4/v6
Figure 5.2.2.1
Figure 5.2.2.1
5.2.2.1.1. IPv6 Related Infrastructure Changes
5.2.2.1.1. IPv6 Related Infrastructure Changes
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.
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.
5.2.2.1.2. Addressing
5.2.2.1.2. Addressing
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.
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.
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.
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.
Asadullah, et al. Informational [Page 16] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah, et al. Informational [Page 16] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
5.2.2.1.3. Data Forwarding
5.2.2.1.3. Data Forwarding
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.
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.
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.
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.
5.2.2.1.4. Routing
5.2.2.1.4. Routing
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.
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.
The ER runs an IGP such as OSPFv3 or ISIS.
5.2.2.2. IPv4 Cable Network, Host, GWR and ER Upgraded to Dual Stack
5.2.2.2. IPv4 Cable Network, Host, GWR and ER Upgraded to Dual Stack
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.
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.
Figure 5.2.2.2 illustrates this deployment scenario.
Figure 5.2.2.2 illustrates this deployment scenario.
+-----+
|Host |
+--+--+
| +-----------+ +------+ +--------+
+---+---+ +-------+ | Cable | | | | Edge |
| GWR |--| CM |----| (HFC) |---| CMTS |---| |=>ISP
+-------+ +-------+ | Network | | | | Router |Network
+-----------+ +------+ +--------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel
+-----+ |Host | +--+--+ | +-----------+ +------+ +--------+ +---+---+ +-------+ | Cable | | | | Edge | | GWR |--| CM |----| (HFC) |---| CMTS |---| |=>ISP +-------+ +-------+ | Network | | | | Router |Network +-----------+ +------+ +--------+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() IPv6-in-IPv4 tunnel
|---------||--------------------------------------||-------------|
IPv4/v6 IPv4 only IPv4/v6
|---------||--------------------------------------||-------------| IPv4/v6 IPv4 only IPv4/v6
Figure 5.2.2.2
Figure 5.2.2.2
Asadullah, et al. Informational [Page 17] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah, et al. Informational [Page 17] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
5.2.2.2.1. IPv6 Related Infrastructure Changes
5.2.2.2.1. IPv6 Related Infrastructure Changes
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.
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.
5.2.2.2.2. Addressing
5.2.2.2.2. Addressing
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.
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.
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.
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.
5.2.2.2.3. Data Forwarding
5.2.2.2.3. Data Forwarding
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.
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.
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.
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.
5.2.2.2.4. Routing
5.2.2.2.4. Routing
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.
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.
Asadullah, et al. Informational [Page 18] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah, et al. Informational [Page 18] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
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.
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.
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.
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.
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.
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.
The ER runs an IGP such as OSPFv3 or ISIS.
The ER runs an IGP such as OSPFv3 or ISIS.
5.2.2.3. Dual-Stacked Cable (HFC) Network, CM, and CMTS Support IPv6
5.2.2.3. Dual-Stacked Cable (HFC) Network, CM, and CMTS Support IPv6
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.
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.
Figure 5.2.2.3 illustrates this deployment scenario.
Figure 5.2.2.3 illustrates this deployment scenario.
+-----------+ +-------------+
+-----+ +-------+ | Cable | | CMTS / Edge |
|Host |--| CM |----| (HFC) |---| |=>ISP
+-----+ +-------+ | Network | | Router | Network
+-----------+ +-------------+
+-----------+ +-------------+ +-----+ +-------+ | Cable | | CMTS / Edge | |Host |--| CM |----| (HFC) |---| |=>ISP +-----+ +-------+ | Network | | Router | Network +-----------+ +-------------+
|-------||---------------------------||---------------|
IPv4/v6 IPv4/v6 IPv4/v6
|-------||---------------------------||---------------| IPv4/v6 IPv4/v6 IPv4/v6
Figure 5.2.2.3
Figure 5.2.2.3
5.2.2.3.1. IPv6 Related Infrastructure Changes
5.2.2.3.1. IPv6 Related Infrastructure Changes
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.
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.
Asadullah, et al. Informational [Page 19] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah, et al. Informational [Page 19] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
5.2.2.3.2. Addressing
5.2.2.3.2. Addressing
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.
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.
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.
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.
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.
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.
5.2.2.3.3. Data Forwarding
5.2.2.3.3. Data Forwarding
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.
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.
5.2.2.3.4. Routing
5.2.2.3.4. Routing
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.
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.
If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or IS-IS.
If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or IS-IS.
Asadullah, et al. Informational [Page 20] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah, et al. Informational [Page 20] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
5.2.2.4. Dual-Stacked Cable (HFC) Network, Stand-Alone GWR, and CMTS
Support IPv6
5.2.2.4. Dual-Stacked Cable (HFC) Network, Stand-Alone GWR, and CMTS Support 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.
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.
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.
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.
Figure 5.2.2.4 illustrates this deployment scenario.
Figure 5.2.2.4 illustrates this deployment scenario.
+-----------+ +-----------+
+------+ +-------+ +-------+ | Cable | |CMTS / Edge|
| Host |--| GWR |--| CM |---| (HFC) |---| |=>ISP
+------+ +-------+ +-------+ | Network | | Router |Network
+-----------+ +-----------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel
|-----------------||-----------------------------||--------------|
IPv4/v6 IPv4 IPv4/v6
+-----------+ +-----------+ +------+ +-------+ +-------+ | 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
Figure 5.2.2.4
5.2.2.4.1. IPv6 Related Infrastructure Changes
5.2.2.4.1. IPv6 Related Infrastructure Changes
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.
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.
5.2.2.4.2. Addressing
5.2.2.4.2. Addressing
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.
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.
The address assignment for the host and GWR happens in a similar manner as described in Section 5.2.2.2.2.
The address assignment for the host and GWR happens in a similar manner as described in Section 5.2.2.2.2.
Asadullah, et al. Informational [Page 21] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah, et al. Informational [Page 21] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
5.2.2.4.3. Data Forwarding
5.2.2.4.3. Data Forwarding
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.
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.
5.2.2.4.4. Routing
5.2.2.4.4. Routing
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.
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.5. Dual-Stacked Cable (HFC) Network, Embedded GWR/CM, and CMTS
Support IPv6
5.2.2.5. Dual-Stacked Cable (HFC) Network, Embedded GWR/CM, and CMTS Support 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.
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.
Figure 5.2.2.5 illustrates this deployment scenario.
Figure 5.2.2.5 illustrates this deployment scenario.
+-----------+ +-------------+
+-----+ +-----------+ | Cable | | CMTS / Edge |
|Host |---| CM / GWR |---| (HFC) |---| |=>ISP
+-----+ +-----------+ | Network | | Router |Network
+-----------+ +-------------+
+-----------+ +-------------+ +-----+ +-----------+ | ケーブル| | CMTS/縁| |ホスト|---| CM/GWR|---| (HFC) |---| |=>ISP+-----+ +-----------+ | ネットワーク| | ルータ|ネットワーク+-----------+ +-------------+
|---------------------------------------------------------|
IPv4/v6
|---------------------------------------------------------| IPv4/v6
Figure 5.2.2.5
図5.2 .2 .5
5.2.2.5.1. IPv6 Related Infrastructure Changes
5.2.2.5.1. IPv6はインフラストラクチャ変化を関係づけました。
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.
Layer3デバイスとしてのCM/GWR条例以来、終わりから終わりをIPv6に配布することができます。 このシナリオでは、以下のデバイスはデュアルスタックにアップグレードしなければなりません: ホスト、CM/GWR、およびCMTS/、えー。
5.2.2.5.2. Addressing
5.2.2.5.2. アドレシング
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アドレスを必要とするでしょう。 DHCPv6かDHCP-PDを通してCM/GWRとホストのためのIPv6アドレス課題ができます。
Asadullah, et al. Informational [Page 22] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[22ページ]のRFC4779ISP IPv6展開シナリオ
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は64の接頭語がDHCPv6サーバで構成した/のプールからIPv6アドレスを受け取るでしょう。CMTSは、今日DHCPv4でするようにDHCPサーバからDHCPクライアント(ホストとCM/GWR)に送られたDHCP Offerメッセージからの適切な情報を収集する必要があるでしょう。 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は、64接頭語がRAメッセージでCMTS/ERで送った/を使用することでIPv6アドレスを上流のインタフェースに割り当てるのに状態がない自動構成を使用するでしょう。 CM/GWRがいったんIPv6アドレスを上流のインタフェースに割り当てると、それは、/48[RFC3177]がCMTS/ERとチョップからホストへのアドレスをIPv6に割り当てるための/64年代へこの/48接頭語を前に置くよう要求するでしょう。 ISPネットワークへのアップリンクはまた、/64接頭語によって構成されます。
5.2.2.5.3. Data Forwarding
5.2.2.5.3. データ推進
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.
ホストは次のLayer3としてのGWRが飛び越すCM/を使用するでしょう。 CM/GWRはすべてのIPv6トラフィックをCMTS/ERとホストからの/に送るでしょう。 CMTS/ERはIPソース/送付先アドレスに基づくホストからの/へのトラフィックをIPv6に送るでしょう。
5.2.2.5.4. Routing
5.2.2.5.4. ルート設定
The CM/GWR can use a static default route pointing to the CMTS/ER or it can run a routing protocol such as RIPng or OSPFv3 between itself and the CMTS. Customer routes from behind the CM/GWR can be carried to the CMTS using routing updates.
CM/GWRがCMTS/ERを示しながら、静的なデフォルトルートを使用できますか、またはそれはそれ自体とCMTSの間でRIPngかOSPFv3などのルーティング・プロトコルを実行できます。 ルーティングアップデートを使用することでCM/GWRの後ろからの顧客ルートをCMTSまで運ぶことができます。
If DHCP-PD is used for address assignment, a static route is automatically installed on the CMTS/ER for each delegated /48 prefix. The static routes need to be redistributed into the IGP at the CMTS/ER so there is no need for a routing protocol between the CMTS/ER and the GWR.
DHCP-PDがアドレス課題に使用されるなら、スタティックルートはそれぞれの代表として派遣された/48接頭語のために自動的にCMTS/ERの上にインストールされます。 スタティックルートが、CMTS/ERのIGPに再配付される必要があるので、CMTS/ERとGWRの間には、ルーティング・プロトコルの必要は全くありません。
If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or IS-IS.
または、また、CMTSがERとして機能しているなら、OSPFv3などのIGPを実行する、-
5.2.3. IPv6 Multicast
5.2.3. IPv6マルチキャスト
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
DOCSISケーブルネットワークの向こう側にマルチキャストアプリケーションをIPv6にサポートするために、CMとCMTSをブリッジするのは、IGMPv3/MLDv2かv1詮索をサポートする必要があるでしょう。 MLDがIPv4でIGMPとほとんど同じである、唯一
Asadullah, et al. Informational [Page 23] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[23ページ]のRFC4779ISP IPv6展開シナリオ
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.
名前と数を変えます。 MLDv2がIGMPv3とほとんど同じであり、また、ASMをサポートする、(いくらか、-、ソース、Multicast) そして、SSM(ソース特有のMulticast)サービスモデル。
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で議論するオプションです。 3CM、GWR、およびLayer3の発送されたCMTS/ERがIGMPv3/MLDv1の定義とサポートを必要とするPIM-SSMか追跡するために詮索されるv2で可能にされる必要があるLayerはホストからメッセージを接合するか、または外します。 別のオプションはLayer3CMかMLDがプロキシルーティングであるとサポートするGWRのためのものでしょう。 ホストのための次のホップがMLDをサポートする必要があるLayer3。
Refer to Section 6.3 for more IPv6 multicast details.
よりその他のIPv6マルチキャストの詳細についてセクション6.3を参照してください。
5.2.4. IPv6 QoS
5.2.4. IPv6 QoS
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.
トラフィック分類と上流のトラフィックのためのCMと川下のトラフィックのためのCMTS/ERにマークするべきです、様々なタイプのサービスをサポートするために: データ、声、およびビデオ。 同じIPv4 QoS概念と方法論はまた、IPv6のために適用されるべきです。
It is important to note that when traffic is encrypted end-to-end, the traversed network devices will not have access to many of the packet fields used for classification purposes. In these cases, routers will most likely place the packets in the default classes. The QoS design should take into consideration this scenario and try to use mainly IP header fields for classification purposes.
トラフィックが暗号化された終わりから終わりであるとき、横断されたネットワークデバイスが分類目的に使用されるパケット分野の多くに近づく手段を持たないことに注意するのは重要です。 これらの場合では、ルータはたぶんデフォルトのクラスにパケットを置くでしょう。 QoSデザインは、このシナリオを考慮に入れて、分類目的にIPヘッダーフィールドを主に使用しようとするべきです。
5.2.5. IPv6 Security Considerations
5.2.5. IPv6セキュリティ問題
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,
Baseline Privacy Plus(BPI+)を使用することでDOCSISケーブルネットワークにおけるセキュリティを提供します。 IPアドレスに依存する唯一の部分が暗号化されたマルチキャストです。 意味的に、マルチキャスト暗号化はIPv4ネットワークのようにIPv6環境で同じように働いているでしょう。 しかしながら
Asadullah, et al. Informational [Page 24] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[24ページ]のRFC4779ISP IPv6展開シナリオ
appropriate enhancements will be needed in the DOCSIS specification to support encrypted IPv6 multicast.
適切な増進が、暗号化された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ネットワークと他の加入者を保護するはずです。 この理由のために、Unicast Reverse Path Forwarding(uRPF)[RFC3704]とAccess Control Lists(ACLs)は加入者に面しているすべてのインタフェースで使用されるべきです。 フィルタリングは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.
CMTS/ERは以下などの有効な顧客コントロールトラフィックの洪水に対して処理リソースを保護するはずです。 ルータ、隣人懇願、およびMLD要求。
All other security features used with the IPv4 service should be similarly applied to IPv6 as well.
IPv4サービスと共に使用される他のすべてのセキュリティ機能が同様にまた、IPv6に適用されるべきです。
5.2.6. IPv6 Network Management
5.2.6. 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はケーブルネットワークで多くのアプリケーションを持つことができます。 MSOsは、初めは、制御飛行機の上のIPv6を実装して、CMTSに接続された何千台ものデバイスを管理するのにそれを使用できます。 これはケーブルネットワークでIPv6を導入する早道でしょう。 その後、MSOは、データ飛行機にIPv6を広げていて、管理トラフィックと同様に顧客トラフィックを運ぶのにそれを使用できます。
5.2.6.1. Using IPv6 for Management in Cable Networks
5.2.6.1. 管理にケーブルネットワークに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.
CM、CMTS、およびERのようなデバイスの管理のためにケーブルネットワークでIPv6を有効にすることができます。 高度にVoIPとVideo過剰IPのようなサービスの初公開で、MSOsはCMTSに接続された多くのデバイスを管理する方法を探しています。 IPv4では、RFC1918アドレスは管理目的のためにこれらのデバイスに割り当てられます。 有限数の利用可能なRFC1918アドレスがあるので、MSOsがこれらのデバイスを管理するのは難しくなっています。
Asadullah, et al. Informational [Page 25] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[25ページ]のRFC4779ISP IPv6展開シナリオ
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を使用することによって、MSOsは彼らの需要を満たすために彼らのネットワーク管理システムをスケーリングできます。 CMTSケーブルインタフェースに接続されたすべてのCMの中で共有される/64管理接頭語はCMTS/ERを構成できます。 状態がない自動構成かDHCPv6を通してCMのためのアドレシングができます。 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.
CMの後ろのMSOによって管理される必要があるデバイスがあれば、CMTS/ERで別の/64接頭語を定義できます。 また、これらのデバイスは、IPv6アドレスを自分たちに割り当てるのに状態がない自動構成を使用できます。
Traffic sourced from or destined to the management prefix should not cross the MSO's network boundaries.
接頭語が出典を明示されるか、または管理に運命づけられたトラフィックはMSOのネットワーク限界に交差するべきではありません。
In this scenario, IPv6 will only be used for managing devices on the cable network. The CM will no longer require an IPv4 address for management as described in DOCSIS 3.0 [DOCSIS3.0-Reqs].
このシナリオでは、IPv6は、ケーブルネットワークでデバイスを管理するのに使用されるだけでしょう。 CMはもうDOCSIS3.0[DOCSIS3.0-Reqs]で説明されるように管理のためのIPv4アドレスを必要としないでしょう。
5.2.6.2. Updates to MIB Modules/Standards to Support IPv6
5.2.6.2. IPv6をサポートするためにモジュール/規格をMIBにアップデートします。
The current DOCSIS, PacketCable, and CableHome MIB modules are already designed to support IPv6 objects. In this case, IPv6 will neither add nor change any of the functionality of these MIB modules. The Textual Convention used to represent Structure of Management Information Version 2 (SMIv2) objects representing IP addresses was updated [RFC4001] and a new Textual Convention InetAddressType was added to identify the type of the IP address used for IP address objects in MIB modules.
現在のDOCSIS、PacketCable、およびCableHome MIBモジュールは、IPv6にオブジェクトを支えるように既に設計されています。 この場合、IPv6はこれらのMIBモジュールの機能性のいずれも付加でない、また変えないでしょう。 IPアドレスを表すManagement情報バージョン2(SMIv2)オブジェクトのStructureを表すのにおいて中古のTextual Conventionをアップデートしました、そして、[RFC4001]MIBモジュールでIPアドレスオブジェクトに使用されるIPアドレスのタイプを特定するために新しいTextual Convention InetAddressTypeを加えました。
There are some exceptions; the MIB modules that might need to add IPv6 support are defined in the DOCSIS 3.0 OSSI specification [DOCSIS3.0-OSSI].
いくつかの例外があります。 IPv6サポートを加える必要があるかもしれないMIBモジュールはDOCSIS3.0オッシ仕様[DOCSIS3.0-オッシ]に基づき定義されます。
6. Broadband DSL Networks
6. 広帯域のDSLネットワーク
This section describes the IPv6 deployment options in today's high- speed DSL networks.
このセクションは今日高値の速度DSLネットワークでIPv6展開オプションについて説明します。
6.1. DSL Network Elements
6.1. DSLネットワークElements
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).
デジタルSubscriber線(DSL)広帯域サービスは存在の上のIPの接続性をもっているユーザに回線折返しと呼ばれるツイストペア電話回線を提供します。 系列の品質とCustomer Premise EquipmentとDSL Access Multiplexerの間の距離(DSLAM)によって、さまざまな帯域幅提供が利用可能です。
Asadullah, et al. Informational [Page 26] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[26ページ]のRFC4779ISP IPv6展開シナリオ
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): それは、顧客前提ネットワークのためにLayer3にサービスを供給するのに使用されます。 通常、それは、提供するのに中小企業のために機能とセグメント放送ドメインをfirewallingしながら、使用されます。
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.
広帯域のリモートアクセス・サーバー(ブラ): それは、加入者DSL回路に対応する複数のPermanent Virtual Circuits(PVCs)を集めるか、または終えます。
Edge Router (ER): It provides the Layer 3 interface to the ISP network.
ルータ(えー)を斜めに進ませてください: それはLayer3インタフェースをISPネットワークに提供します。
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 +-+ +-----+
+-----+ +--+---+
顧客前提| ネットワークアクセスプロバイダ| ネットワーク・サービスプロバイダーCP仮眠NSP+-----+ +------+ +------+ +--------+ |ホスト|--|ルータ| +--+ ブラ+---+ 縁| ISP+-----+ +--+---+ | | | | ルータ+=>ネットワーク| | +------+ +--------+ +--+---+ | | DSL++| |モデム| | | +------+ | +-----+ | +--+ | | +------+ |DSLAM+--+ +-----+ | DSL| +--+ | |ホスト|--+ モデム+++-----+ +-----+ +--+---+
Figure 6.1
図6.1
Asadullah, et al. Informational [Page 27] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[27ページ]のRFC4779ISP IPv6展開シナリオ
6.2. Deploying IPv6 in IPv4 DSL Networks
6.2. IPv4 DSLネットワークでIPv6を配布します。
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. 二地点間モデル: 各加入者は、1ツイストペアの上でDSLAMに接続して、それをリンクするユニークなPVCをサービスプロバイダーに提供します。 BRASにおいて、または、Edge RouterでPVCsを終えることができます。 PVCsができるだけDSLAM(BRASの)の近くで終えられないなら、このタイプのデザインはそれほどスケーラブルではありません。 この場合、多くのLayer2回路がネットワークの重要な部分に関して維持されなければなりません。 ERで3つの方法でLayer2ドメインを終えることができます:
A. In a common bridge group with a virtual interface that routes
traffic out.
A. 一般的なブリッジでは、外の仮想インターフェースがトラフィックを発送していて、分類してください。
B. By enabling a Routed Bridged Encapsulation feature, all users
could be part of the same subnet. This is the most common
deployment approach of IPv4 over DSL but it might not be the
best choice in IPv6 where address availability is not an
issue.
B. Routed Bridged Encapsulationの特徴を可能にすることによって、すべてのユーザが同じサブネットの一部であるかもしれません。 これは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. Layer3でPVCを終えることによって、各PVCには、それ自身の接頭語があります。 これはIPv6により適当に思えて、セクション6.2.1で提示されるアプローチです。
None of these ways requires that the CPE (DSL modem) be
upgraded.
これらの方法のいずれも、CPE(DSLモデム)がアップグレードするのを必要としません。
2. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened
between each subscriber and the BRAS. The BRAS terminates the
PPP sessions and provides Layer 3 connectivity between the
subscriber and the ISP. This model is presented in Section
6.2.2.
2. pppは集合(PTA)モデルを終えました: PPPセッションは各加入者とBRASの間で開かれます。 BRASは加入者とISPの間にPPPセッションを終えて、Layer3の接続性を提供します。 このモデルはセクション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 Edge Routerの間で開かれます。 L2TPv2[RFC2661]トンネルにそれらをカプセル化することによって、BRASは加入者PPPセッションにISPにトンネルを堀ります。 このモデルはセクション6.2.3で提示されます。
In aggregation models, the BRAS terminates the subscriber PVCs and aggregates their connections before providing access to the ISP.
集合モデルでは、ISPへのアクセスを提供する前に、BRASは加入者PVCsを終えて、彼らの接続に集めます。
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
IPv4にサービスを生成する既存の収入と共に証明されて、使用される展開概念とビジネスモデルを維持するために、IPv6展開はIPv4 1に合うでしょう。 このアプローチは提示されます。
Asadullah, et al. Informational [Page 28] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[28ページ]のRFC4779ISP IPv6展開シナリオ
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.
セクション6.2.1--6.2では、DSLブロードバンドの上で現在のIPv4について説明する.3が展開にアクセスします。 ある状況で、下、新しいサービスタイプかサービスの必要性がそれ、IPv4、およびIPv6ネットワークを正当化する論理的なアーキテクチャはセクション6.2.4で説明されるように異なっているかもしれません。
6.2.1. Point-to-Point Model
6.2.1. 二地点間モデル
In this scenario, the Ethernet frames from the Host or the Customer Premise Router are bridged over the PVC assigned to the subscriber.
このシナリオでは、HostかCustomer Premise Routerからのイーサネットフレームは加入者に割り当てられた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
顧客前提仮眠NSP|-------------------------| |---------------| |------------------| +-----+ +-------+ +-----+ +--------+ +----------+ |ホスト|--+--+ DSL+--+ + ルータDSLAM+--------+ 縁| ISP+-----+ +-------+ |モデム| +--------+ | ルータ+=>ネットワーク+-----+ +----------+ |----------------------------| 気圧
Figure 6.2.1
図6.2 .1
6.2.1.1. IPv6 Related Infrastructure Changes
6.2.1.1. IPv6はインフラストラクチャ変化を関係づけました。
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がLayer3気づかないので、IPv6は変化が全くサポートされる必要はありません。 以下のデバイスはデュアルスタックにアップグレードしなければなりません: ホスト、Customer Router(存在しているなら)、およびEdge Router。
6.2.1.2. Addressing
6.2.1.2. アドレシング
The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop.
彼らの次のLayer3が跳ぶとき、HostsかCustomer Routersには、Edge Routerがあります。
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.
Customer Routerが全くなければ、加入者サイトのすべてのホストがその加入者PVCのためにEdge Routerで静的に構成される同じ/64サブネットに属します。 ホストは、Edge Routerを通してアドレスを習得するのに状態がない自動構成かstateful 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.
しかしながら、各顧客のための手動の構成が食糧を供給する挑戦であるので、implementersは自動的に、PVC(または、ある他の顧客特定情報)を写像するメカニズムをIPv6サブネット接頭語に開発して、最小量の構成で顧客の特定の接頭語のすべての顧客に広告を出すよう奨励されます。
Asadullah, et al. Informational [Page 29] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[29ページ]のRFC4779ISP IPv6展開シナリオ
If a Customer Router is present:
Customer Routerが存在しているなら:
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. それはそれ自体とEdge Routerの間の/64サブネットに関するアドレス、およびインタフェースの顧客サイトにホストを接続する/64接頭語によって静的に構成されます。 これは管理する高価で難しい必要な食糧を供給するメソッドではありません。
B. It can use its link-local address to communicate with the ER. It
can also dynamically acquire, through stateless auto-
configuration, the prefix for the link between itself and the ER.
The later option allows it to contact a remote DHCPv6 server, if
needed. This step is followed by a request via DHCP-PD for a
prefix shorter than /64 that, in turn, is divided in /64s and
assigned to its downstream interfaces.
B. それは、ERとコミュニケートするのにリンクローカルアドレスを使用できます。 また、それは状態がない自動構成を通してダイナミックにそれ自体とERとのリンクに接頭語を習得できます。 後のオプションで、必要であるなら、それはリモートDHCPv6サーバに連絡できます。 要求は順番に/64年代で分割されて、川下のインタフェースに割り当てられる/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.
Edge Routerはそれぞれの加入者PVCのために/64接頭語を構成させます。 各PVCがISPネットワークで加入者からDHCPv6サーバまでのDHCPv6要求をリレーするのが有効にされるべきです。 PVCsはまた、DHCP-PDを使用する加入者にアクセスを前提として、特徴をサポートするのが有効にされなければなりません。 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を通して代表として派遣されたEdge Routerで同じくらい可能な同じくらい多くの総括を許す方法で計画されるべきです。
Other information of interest to the host, such as DNS, is provided through stateful DHCPv6 [RFC3315] and stateless DHCPv6 [RFC3736].
stateful DHCPv6[RFC3315]と状態がないDHCPv6[RFC3736]を通してDNSなどのホストにとって、興味深い他の情報を提供します。
6.2.1.3. Routing
6.2.1.3. ルート設定
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デバイスはEdge Routerを示すデフォルトルートによって構成されます。 ルーティング・プロトコルは全くこれらのデバイスで必要ではありません。(一般に、デバイスはリソースを制限しました)。
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.
Edge RouterはNSPで使用されるIPv6 IGPを実行します: または、OSPFv3、- 接続接頭語を再配付しなければなりません。 DHCP-PDが使用されているなら、あらゆる代表として派遣された接頭語で、スタティックルートはEdge Routerによってインストールされます。 この理由で、また、スタティックルートを再配付しなければなりません。 接頭語総括をEdge Routerにするべきです。
6.2.2. PPP Terminated Aggregation (PTA) Model
6.2.2. pppの終えられた集合(PTA)モデル
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
PTAアーキテクチャはPPPベースのプロトコル(PPPoA[RFC2364]とPPPoE[RFC2516])を当てにします。 PPPセッションは、Customer Premise Equipmentによって開始されて、BRASで終えられます。 ブラ
Asadullah, et al. Informational [Page 30] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[30ページ]のRFC4779ISP IPv6展開シナリオ
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.
ISPを代表してセッションを認可して、加入者を認証して、IPアドレスを提供します。 そして、BRASは加入者トラフィックのLayer3ルーティングをNSP Edge Routerにします。
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 Edge Routerは同じ設備であり、上記の機能性を提供できました。
There are two types of PPP encapsulations that can be leveraged with this model:
このモデルと共に利用することができる2つのタイプのPPPカプセル化があります:
A. Connection using PPPoA
PPPoAを使用しているA.接続
Customer Premise NAP NSP
|--------------------| |----------------------| |----------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
+-----+ +-------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
|--------------------------| +-----------+
PPP
顧客前提仮眠NSP|--------------------| |----------------------| |----------------| +-----------+ | AAA| +-------+ 半径| | | TACACS| | +-----------+ +-----+ +-------+ +--------+ +----+-----+ +-----------+ |ホスト|--+ ルータ+------+ DSLAM++ブラ++縁| +-----+ +-------+ +--------+ +----------+ | ルータ+=>コア|--------------------------| +-----------+ 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セッションはCustomer Premise Equipmentによって開始されます。 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.
このソリューションは、よりよく比例します、そして、Pointからポイントであり1ATM PVCあたり1つのPPPセッションしかないので、次に、加入者は一度に、ただ一つのISPサービスを選ぶことができます。
Asadullah, et al. Informational [Page 31] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[31ページ]のRFC4779ISP IPv6展開シナリオ
B. Connection using PPPoE
PPPoEを使用しているB.接続
Customer Premise NAP NSP
|--------------------------| |-------------------| |---------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
|
+-----+ +-------+ +--------+ +-----+----+ +-----------+
|Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +----------+ | Router +=>O
| | R
|--------------------------------| +-----------+ E
PPP
顧客前提仮眠NSP|--------------------------| |-------------------| |---------------| +-----------+ | AAA| +-------+ 半径| | | TACACS| | +-----------+ | +-----+ +-------+ +--------+ +-----+----+ +-----------+ |ホスト|--+ ルータ+-----------+ DSLAM++ブラ++縁| C+-----+ +-------+ +--------+ +----------+ | ルータ+=>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カプセル化にかかわらず同じです。
6.2.2.1. IPv6 Related Infrastructure Changes
6.2.2.1. IPv6はインフラストラクチャ変化を関係づけました。
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はLayer3意識しています、そして、それは、IPv6をサポートするためにアップグレードしなければなりません。 BRASがPPPセッションを終えるので、それはIPv6と共にこれらのPPPプロトコルの実装をサポートしなければなりません。 以下のデバイスはデュアルスタックにアップグレードしなければなりません: ホスト、Customer Router(存在しているなら)、BRAS、およびEdge Router。
6.2.2.2. Addressing
6.2.2.2. アドレシング
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の上、または、Authentication、Authorization、およびAccounting(AAA)サーバの上に位置できます。彼らの次のLayer3が跳ぶとき、HostsかCustomer Routersには、BRASがあります。
Asadullah, et al. Informational [Page 32] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[32ページ]のRFC4779ISP IPv6展開シナリオ
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.
ホストかCustomer RouterがPPPセッションを開始できます。 後者の場合では、いったんセッションがBRASと共に確立されて、アドレスがアップリンクのためにBRASと交渉されると、Customer Router他のインタフェースに接頭語を習得するのに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.
DHCP-PDをサポートして、BRASが加入者サイトにおけるホストの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はEdgeルータへのリンクの上に/64接頭語を構成させます。 また、Edge Routerリンクは/64接頭語によって構成されて、ISPネットワークの残りに接続性を提供します。
The prefixes used for subscribers and the ones delegated via DHCP-PD should be planned in a manner that allows maximum summarization at the BRAS.
加入者に使用される接頭語とDHCP-PDを通して代表として派遣されたBRASで最大の総括を許す方法で計画されるべきです。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
stateful[RFC3315]と状態がない[RFC3736]DHCPv6を通してDNSなどのホストにとって、興味深い他の情報を提供します。
6.2.2.3. Routing
6.2.2.3. ルート設定
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をEdge Routerに実行します: または、OSPFv3、- PPPセッションまで割り当てられたアドレスが接続ホストルートとして表されるので、接続接頭語を再配付しなければなりません。 DHCP-PDが使用されているなら、あらゆる代表として派遣された接頭語で、スタティックルートはEdge Routerによってインストールされます。 この理由で、また、スタティックルートを再配付しなければなりません。 接頭語総括をBRASにするべきです。
The Edge Router is running the IGP used in the ISP network: OSPFv3 or IS-IS.
Edge RouterはISPネットワークに使用されるIGPを実行しています: または、OSPFv3、-
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とAccess Providerの経路ドメインの間の分離はお勧めです。 制御再分配がAccess Provider IGPとISP IGPの間で必要でしょう。
6.2.3. L2TPv2 Access Aggregation (LAA) Model
6.2.3. L2TPv2アクセス集合(LAA)モデル
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はL2TPv2トンネルの上のISPへの開始しているセッションがBRASとEdge Routerの間に設立したCPEを進めます。 この場合、認証、承認、および加入者構成はISP自体によって実行されます。 このモデルと共に利用することができる2つのタイプのPPPカプセル化があります:
Asadullah, et al. Informational [Page 33] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[33ページ]のRFC4779ISP IPv6展開シナリオ
A. Connection via PPPoA
PPPoAを通したA.接続
Customer Premise NAP NSP
|--------------------| |----------------------| |----------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
|----------------------------------------|
PPP
|------------|
L2TPv2
顧客前提仮眠NSP|--------------------| |----------------------| |----------------| +-----------+ | AAA| +-------+ 半径| | | TACACS| | +-----+-----+ | | +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ |ホスト|--+ ルータ+------+ DSLAM++ブラ++縁| +-----+ +-------+ +--------+ +----------+ | ルータ+=>コア+-----------+ |----------------------------------------| 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
顧客前提仮眠NSP|--------------------------| |--------------------| |---------------| +-----------+ | AAA| +------+ 半径| | | TACACS| | +-----+-----+ | | +-----+ +-------+ +--------+ +----+-----+ +----+------+ |ホスト|--+ ルータ+-----------+ DSLAM++ブラ++縁| C+-----+ +-------+ +--------+ +----------+ | ルータ+=>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カプセル化にかかわらず同じです。
Asadullah, et al. Informational [Page 34] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[34ページ]のRFC4779ISP IPv6展開シナリオ
6.2.3.1. IPv6 Related Infrastructure Changes
6.2.3.1. IPv6はインフラストラクチャ変化を関係づけました。
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 Network Server(LNS)(ISPネットワークにおける集合ポイント)に確立されたL2TPv2トンネルの上で加入者によって開始されたPPPセッションを進めています。 L2TP Access Concentrator(LAC)とLNSの間のL2TPv2トンネルはIPv6かIPv4をひくことができます。 これらの能力はBRASでサポートされなければなりません。 以下のデバイスはデュアルスタックにアップグレードしなければなりません: ホスト、顧客ルータ、および縁のルータ。 トンネルがIPv6の上に設立されるなら、BRASはデュアルスタックにアップグレードしなければなりません。
6.2.3.2. Addressing
6.2.3.2. アドレシング
The Edge Router terminates the PPP sessions and provides the subscriber with an IPv6 address from the defined pool for that profile. The subscriber profile for authorization and authentication can be located on the Edge Router or on an AAA server. The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop.
Edge Routerはそのプロフィールのために定義されたプールからPPPセッションを終えて、IPv6アドレスを加入者に提供します。 承認と認証のための加入者プロフィールはEdge Routerの上、または、AAAサーバの上に位置できます。彼らの次のLayer3が跳ぶとき、HostsかCustomer Routersには、Edge Routerがあります。
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.
ホストかCustomer RouterがPPPセッションを開始できます。 後者の場合では、セッションがEdge Routerと共にいったん確立されるとCustomer Routerインタフェースに接頭語を習得するのにDHCP-PDを使用できます。 DHCP-PDをサポートして、Edge Routerが加入者サイトのホストによって生成された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はEdge Routerへのリンクの上に/64接頭語を構成させます。 また、Edge Routerリンクは/64接頭語によって構成されて、ISPネットワークの残りに接続性を提供します。 stateful[RFC3315]と状態がない[RFC3736]DHCPv6を通してDNSなどのホストにとって、興味深い他の情報を提供します。
It is important to note here a significant difference between this deployment for IPv6 versus IPv4. In the case of IPv4, the customer router or CPE can end up on any Edge Router (acting as LNS), where the assumption is that there are at least two of them for redundancy purposes. Once authenticated, the customer will be given an address from the IP pool of the ER (LNS) it connected to. This allows the ERs (LNSs) to aggregate the addresses handed out to the customers. In the case of IPv6, an important constraint that likely will be enforced is that the customer should keep its own address, regardless of the ER (LNS) it connects to. This could significantly reduce the prefix aggregation capabilities of the ER (LNS). This is different than the current IPv4 deployment where addressing is dynamic in nature, and the same user can get different addresses depending on the LNS it ends up connecting to.
IPv6対IPv4によってここでこの展開の著しい違いに注意するのは重要です。 IPv4の場合では、顧客のルータかCPEがどんなEdge Router(LNSとして、機能する)の上でも終わることができます。そこでは、仮定は少なくとも彼らの2人が冗長目的を支持しているということです。 いったん認証すると、アドレスをそれが接続したER(LNS)のIPプールから顧客に与えるでしょう。 これで、ERs(LNSs)は顧客に与えられたアドレスに集めることができます。 IPv6の場合では、おそらく励行される重要な規制は顧客がそれ自身のアドレスを保管するべきであるということです、それが接続するER(LNS)にかかわらず。 これはER(LNS)の接頭語集合能力をかなり減少させるかもしれません。 これはアドレシングが現実にダイナミックであり、同じユーザが異なったアドレスをそれが終わらせるLNSに接続に依存させることができるところで現在のIPv4展開と異なっています。
Asadullah, et al. Informational [Page 35] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[35ページ]のRFC4779ISP IPv6展開シナリオ
One possible solution is to ensure that a given BRAS will always connect to the same ER (LNS) unless that LNS is down. This means that customers from a given prefix range will always be connected to the same ER (primary, if up, or secondary, if not). Each ER (LNS) can carry summary statements in their routing protocol configuration for the prefixes for which they are the primary ER (LNS), as well as for the ones for which they are the secondary. This way the prefixes will be summarized any time they become "active" on the ER (LNS).
1つの可能なソリューションはそのLNSが下がっていない場合与えられたBRASがいつも同じER(LNS)に接続するのを保証することです。 これは、与えられた接頭語範囲からの顧客がいつも同じER(そうでなければ、プライマリの、または、上がっているか、セカンダリの)に接続されることを意味します。 各ER(LNS)はそれらがプライマリER(LNS)である接頭語のためにそれらのルーティング・プロトコル構成で要約報告を運ぶことができます、よくそれらがセカンダリであるもののように。 接頭語がいつでもまとめられるこのように、それらはER(LNS)で「アクティブに」なります。
6.2.3.3. Routing
6.2.3.3. ルート設定
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セッションを終えるEdge Routerを示すデフォルトルートによって構成されます。 ルーティング・プロトコルは全くこれらのデバイスで必要ではありません。(一般に、デバイスはリソースを制限しました)。
The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. Different processes should be used if the NAP and the NSP are managed by different organizations. In this case, controlled redistribution should be enabled between the two domains.
BRASはIPv6 IGPをEdge Routerに実行します: または、OSPFv3、- NAPとNSPが異なった組織によって管理されるなら、異なったプロセスは使用されるべきです。 この場合、制御再分配は2つのドメインの間で可能にされるべきです。
The Edge Router is running the IPv6 IGP used in the ISP network: OSPFv3 or IS-IS.
Edge RouterはISPネットワークに使用されるIPv6 IGPを実行しています: または、OSPFv3、-
6.2.4. Hybrid Model for IPv4 and IPv6 Service
6.2.4. IPv4のハイブリッド・モデルとIPv6サービス
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を写像するべきであることが勧められました。 このアプローチは、管理可能性を簡素化して、ネットワークを経営している人員に必要であるトレーニングを最小にします。 ある特定の状況ではそのようなマッピングは可能ではありません。 Service Providerが、新しい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 Edge Routerです。 プロバイダーが、そのようなデザインの上にマルチキャストサービスを提供すると決めると、それは終わっているのが利用したNAPリソースの問題に直面するでしょう。 Edge Routerはトンネルの端だけにマルチキャストトラフィックを模写できます、そして、すべての加入者のためのコピーは全体のNAPの上まで運ばれます。
Asadullah, et al. Informational [Page 36] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[36ページ]のRFC4779ISP IPv6展開シナリオ
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にできるのでマルチキャストサービスをサポートすることではModified Pointからポイント(セクション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のための変更されたPointからポイントかPTAデザインを選ぶかもしれません。
6.2.4.1. IPv4 in LAA Model and IPv6 in PTA Model
6.2.4.1. LAAのIPv4はモデル化します、そして、PTAにおけるIPv6はモデル化します。
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サービスのための異なったネットワークデバイスで終えられます。 IPv4サービスがLAAモデルで配布した存在のためのPPPセッションはEdge Routerで終えられます。 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
IPv6|--------------------------| ppp+-----------+ | AAA| +-------+ 半径| | | TACACS| | +-----+-----+ | | +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ |ホスト|--+ ルータ+------+ DSLAM++ブラ++縁| +-----+ +-------+ +--------+ +----------+ | ルータ+=>コア+-----------+ IPv4|----------------------------------------| ppp|------------| L2TPv2
Figure 6.2.4.1
図6.2 .4 .1
6.2.4.2. IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model
6.2.4.2. LAAのIPv4はモデル化します、そして、変更されたポイントツーポイントにおけるIPv6はモデル化します。
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.
この特定のシナリオでは、PointからポイントへのIPv6サービスに使用されるモデルはセクション6.2.1で説明されたモデルの変更されたバージョンです。
Asadullah, et al. Informational [Page 37] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[37ページ]のRFC4779ISP IPv6展開シナリオ
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サービスにおいて、PVCsはBRASで終えられます、そして、PPPセッションはEdge Router(LNS)で終えられます。 PointからポイントへのモデルにおけるIPv6サービスにおいて、PVCsはセクション6.2.1で説明されるようにEdge Routerで終えられます。 このハイブリッド・モデルでは、BRAS、NAPによって所有されているデバイスでPointからポイントへのリンクを終えることができました。 そして、IPv6トラフィックはNAPネットワークを通してNSPに発送されます。 このハイブリッド・モデルがいるように、BRASはデュアルスタックルータにアップグレードしなければなりません。 セクション6.2.1で説明されるEdge Routerの機能性は現在、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トンネルの向こう側にブリッジされなければならないIPv4 PPPトラフィックとNSPに発送されなければならないIPv6パケットを見分けることができなければならないという事実です。 IPv6ルート設定とBridging Encapsulation(RBE)はこのハイブリッドデザインにおけるサービスをIPv4とIPv6の両方にサポートするPVCsとのすべてのインタフェースで有効にされなければなりません。
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
IPv6|----------------| 気圧+-----------+ | AAA| +-------+ 半径| | | TACACS| | +-----+-----+ | | +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ |ホスト|--+ ルータ+------+ DSLAM++ブラ++縁| +-----+ +-------+ +--------+ +----------+ | ルータ+=>コア+-----------+ IPv4|----------------------------------------| ppp|------------| L2TPv2
Figure 6.2.4.2
図6.2 .4 .2
6.3. IPv6 Multicast
6.3. IPv6マルチキャスト
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(どんなSource Multicastも)とSSM(独身のSource Multicast)サービスモデルはIPv4のようにほぼ同じように働いています。 両方には、同じ利益と損失がIPv4のようにあります。 それにもかかわらず、より大きいアドレス空間と見られたアドレス体系は主要な利益をマルチキャストIPv6に供給します。 RFC3306を通して、大きいアドレス空間は案配にグローバルな手段を提供します。
Asadullah, et al. Informational [Page 38] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[38ページ]のRFC4779ISP IPv6展開シナリオ
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.
これはマルチキャストサービスの展開を容易にします。 このセクションの議論はドキュメントのすべてのマルチキャスト部に適用されます。
6.3.1. ASM-Based Deployments
6.3.1. ASMベースの展開
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.
どんなSource Multicast(ASM)も彼らの顧客のマルチキャストトラフィックの推進をサポートするつもりであるService Providersの役に立ちます。 それはプロトコル無党派Multicastに基づいています--まばらなMode(PIM-SM)は議定書を作ります、そして、Rendezvous Points(RPs)の使用のために管理するのは、より複雑です。 IPv6と共に、RPからグループへのIPv4と同様のマッピングに、静的なRPとBootstrap Router[BSR]を使用できます。 さらに、より大きいIPv6アドレス空間は、RPのアドレスを取り入れるグループアドレスを確立すると考慮します。 RPからグループへのマッピングこのメカニズムは、Embedded 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ディスカバリープロトコル(MSDP)[RFC3618]はIPv4 PIM-SM展開の重要な要素です。 MSDPは異なったドメインのRPsの間のソースレジスト情報の交換のためのソリューションであることが意味されます。 このソリューションが一時的であることを意図しました。 これはそれがIPv6[IPv6-マルチキャスト]でMSDPを実装しないように決められた理由の1つです。
For multicast reachability across domains, Embedded RP can be used. As Embedded RP provides roughly the same capabilities as MSDP, but in a slightly different way, the best management practices for ASM multicast with embedded RP still remain to be developed.
ドメイン中のマルチキャストの可到達性のために、Embedded RPを使用できます。 Embedded RPがおよそMSDPと同じ能力を提供する、しかし、わずかに異なった方法で、埋め込まれたRPがあるASMマルチキャストのための最も良い管理練習は、開発されるためにまだ残っています。
6.3.2. SSM-Based Deployments
6.3.2. SSMベースの展開
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に基づいて、Source特有のMulticast展開は、彼らが受けるのを計画しているマルチキャストトラフィックについてソースを知るためにRPを必要ともしませんし、プロトコル(BSRかMSDPなどの)を関係づけますが、リスナーに頼りもしません。 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
住宅の、そして、非常に小さいビジネスのために提供された典型的なマルチキャストサービスはビデオ/オーディオストリーミングです、加入者がマルチキャストグループに加わって、内容を受け取るところで。 このタイプのサービスモデルにおいて、非常に簡単なPIM-SSMを通してよくサポートされて、簡単です。
Asadullah, et al. Informational [Page 39] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[39ページ]のRFC4779ISP IPv6展開シナリオ
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はSPネットワーク中で有効にされなければなりません。 MLDv2がPIM-SSMサポートに必要です。 ベンダーは、地図への事前に定義されて、MLDv1グループが接合するルータを許容する特徴にソースを実装するのを選ぶことができます。
Subscribers might use a set-top box that is responsible for the control piece of the multicast service (does group joins/leaves). The subscriber hosts can also join desired multicast groups as long as they are enabled to support MLDv1 or MLDv2. If a customer premise router is used, then it has to be enabled to support MLDv1 and MLDv2 in order to process the requests of the hosts. It has to be enabled to support PIM-SSM in order to send PIM joins/leaves up to its Layer 3 next hop whether it is the BRAS or the Edge Router. When enabling this functionality on a CPR, its limited resources should be taken into consideration. Another option would be for the CPR to support MLD proxy routing.
加入者がマルチキャストサービスのコントロール断片に原因となるセットトップボックスを使用するかもしれない、(グループが合流するか、または残す、) また、MLDv1かMLDv2をサポートするのが可能にされる限り、加入者ホストは必要なマルチキャストグループに加わることができます。 顧客前提ルータが使用されているなら、ホストの要求を処理するためにMLDv1とMLDv2をサポートするのが可能にされなければなりません。 発信するためにPIM-SSMをサポートするのが可能にされて、PIMがそれがBRASであるか、そして、Edge Routerに次のホップをLayer3に合流するか、または任せるということでなければなりません。 CPRでこの機能性を可能にするとき、限りある資源は考慮に入れられるべきです。 別のオプションはCPRが、MLDがプロキシルーティングであるとサポートするだろうことです。
The router that is the Layer 3 next hop for the subscriber (BRAS in the PTA model or the Edge Router in the LAA and Point-to-Point model) has to be enabled to support MLDv1 and MLDv2 in order to process the requests coming from subscribers without CPRs. It has to be enabled for PIM-SSM in order to receive joins/leaves from customer routers and send joins/leaves to the next hop towards the multicast source (Edge Router or the NSP core).
加入者からCPRsなしで来る要求を処理するためにMLDv1とMLDv2をサポートするのが可能にされるために加入者(LAAとPointからポイントへのモデルのPTAモデルかEdge RouterのBRAS)のための次のホップにはあるLayer3であるルータ。 受信して、PIM-SSMのために可能にされるのは顧客ルータから/葉を接合します、そして、発信してください。持っている、マルチキャストソース(縁のRouterかNSPコア)に向かった次のホップに/葉を接合します。
MLD authentication, authorization and accounting are usually configured on the Edge Router in order to enable the ISP to control the subscriber access of the service and do billing for the content provided. Alternative mechanisms that would support these functions should be investigated further.
通常、MLD認証、承認、および会計は、ISPがサービスの加入者アクセスを制御して、提供された内容のために支払いをするのを可能にするためにEdge Routerで構成されます。 これらの機能をサポートする代替のメカニズムはさらに調査されるべきです。
6.4. IPv6 QoS
6.4. IPv6 QoS
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構成は複数の加入者の中で共有されたリソースを管理して、次の3が加入者(LAAとPointからポイントへのモデルのPTAモデルかEdge RouterのBRAS)のために飛び越すLayerを表すルータで特に関連しています、ことによると様々なサービスレベル協定で。
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
BRASかEdge Routerでは、加入者に面するインタフェースは、顧客にとっての、外国行きのトラフィックがサービスレベル協定(SLA)に基礎づけた本国行きの顧客トラフィックと形を取り締まるために構成されなければなりません。 また、トラフィック分類とマークがあるべきです。
Asadullah, et al. Informational [Page 40] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[40ページ]のRFC4779ISP IPv6展開シナリオ
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.
様々なタイプの顧客トラフィック(データ、声、およびビデオ)をサポートして、インフラストラクチャリソースを最適に使用するために加入者の最も近く(Layer3で)でルータをします。 各プロバイダー(NAP、NSP)は、NAPとNSPの間の境界で再分類とマークを実行できるようにそれら自身のQoSが方針とサービスであると実装するかもしれません、トラフィックがISPによって適切に扱われるのを確実にするために。 同じ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ヘッダーフィールドを主に使用しようとするべきです。
6.5. IPv6 Security Considerations
6.5. IPv6セキュリティ問題
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.
セキュリティを高めて、CPEsのためにしなければならない限られた変化があります。 自動構成[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].
次の3が加入者(BRASかEdge Router)のために飛び越すLayerであるデバイスはプロバイダー顧客のひとりによる攻撃に対してネットワークと他の加入者を保護するはずです。 この理由のために、uRPFとACLsは加入者に面しているすべてのインタフェースで使用されるべきです。 フィルタリングは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.
BRASとEdge Routerは以下などの有効な顧客コントロールトラフィックの洪水に対して彼らの処理リソースを保護するはずです。 ルータ、隣人懇願、およびMLD要求。 レート制限はすべての加入者に面するインタフェースで実装されるべきです。 それがIPv6制御飛行機によってたいてい使用されるとき、強調はマルチキャストタイプトラフィックに置かれるべきです。
Asadullah, et al. Informational [Page 41] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[41ページ]のRFC4779ISP IPv6展開シナリオ
All other security features used with the IPv4 service should be similarly applied to IPv6 as well.
IPv4サービスと共に使用される他のすべてのセキュリティ機能が同様にまた、IPv6に適用されるべきです。
6.6. IPv6 Network Management
6.6. IPv6ネットワークマネージメント
The necessary instrumentation (such as MIB modules, NetFlow Records, etc.) should be available for IPv6.
必要な計装(MIBモジュール、NetFlow Recordsなどの)は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).
通常、NSPsはSNMPで縁のルータを管理します。 すべての管理されたデバイスがIPv4とIPv6の両方の上に接続性を持っているなら、SNMP輸送がIPv4の上にできます。 これは既存のネットワークマネージメント練習とプロセスへの最も小さい変化を含意するでしょう。 また、IPv6の上の輸送を実装することができました、そして、それはネットワークで島だけがIPv6であるなら存在しているのが必要になるかもしれません。 管理アプリケーションはNSPコアネットワークドメインに属すホストで動いているかもしれません。 ネットワークManagement Applicationsは同様に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における設備の管理があります。
7. Broadband Ethernet Networks
7. 広帯域のイーサネットネットワーク
This section describes the IPv6 deployment options in currently deployed Broadband Ethernet Access Networks.
このセクションは現在配布しているBroadbandイーサネットAccess NetworksのIPv6展開オプションについて説明します。
7.1. Ethernet Access Network Elements
7.1. イーサネットアクセスネットワーク要素
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イーサネット広帯域サービスを提供できます。 一般に、そのようなサービスは費用対効果に優れた方法でイーサネットインフラストラクチャを配布することができる雑居ビルの都市エリアで利用可能です。 そのような環境で、集合とアップリンクをService Providerに供給するのにMetro-イーサネットサービスを利用できます。
The following network elements are typical of an Ethernet network:
以下のネットワーク要素はイーサネットネットワークの典型です:
Access Switch: It is used as a Layer 2 access device for subscribers.
スイッチにアクセスしてください: それは加入者にLayer2アクセスデバイスとして使用されます。
Customer Premise Router: It is used to provide Layer 3 services for customer premise networks.
顧客前提ルータ: それは、顧客前提ネットワークのためにLayer3にサービスを供給するのに使用されます。
Aggregation Ethernet Switches: Aggregates multiple subscribers.
集合イーサネットは切り替わります: 複数の加入者に集めます。
Broadband Remote Access Server (BRAS)
広帯域のリモートアクセス・サーバー(ブラ)
Asadullah, et al. Informational [Page 42] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[42ページ]のRFC4779ISP IPv6展開シナリオ
Edge Router (ER)
縁のルータ(えー)
Figure 7.1 depicts all the network elements mentioned.
図7.1は要素が言及したすべてのネットワークについて表現します。
Customer Premise | Network Access Provider | Network Service Provider
CP NAP NSP
顧客前提| ネットワークアクセスプロバイダ| ネットワーク・サービスプロバイダーCP仮眠NSP
+-----+ +------+ +------+ +--------+
|Hosts|--|Router| +-+ BRAS +--+ Edge | ISP
+-----+ +--+---+ | | | | Router +===> Network
| | +------+ +--------+
+--+----+ |
|Access +-+ |
|Switch | | |
+-------+ | +------+ |
+--+Agg E | |
+-------+ |Switch+-+
+-----+ |Access | +--+ |
|Hosts|--+Switch +-+ +------+
+-----+ +-------+
+-----+ +------+ +------+ +--------+ |ホスト|--|ルータ| ++ブラ+--+ 縁| ISP+-----+ +--+---+ | | | | ルータ+===>ネットワーク| | +------+ +--------+ +--+----+ | |アクセス++| |スイッチ| | | +-------+ | +------+ | +--+ Agg E| | +-------+ |スイッチ+++-----+ |アクセス| +--+ | |ホスト|--+ スイッチ+++------+ +-----+ +-------+
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.
BroadbandイーサネットNetworksの論理的トポロジーとデザインはセクション6で議論したDSL Broadband Networksと非常に同様です。
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ベースのネットワーク環境に適用されることに注意する価値があります。 そのような環境で、いくつかのネットワーク要素が異なって命名されるかもしれません。
7.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks
7.2. IPv4の広帯域のイーサネットネットワークでIPv6を配布します。
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かファイバーリンクの上のネットワークAccessスイッチに接続します。 各加入者はユニークなVLANをアクセススイッチに割り当てられます。 BRASにおいて、または、Edge RouterでVLANを終えることができます。 VLANsはLayer3デバイス(BRASかEdge Router)への802.1Q trunkedです。
This model is presented in Section 7.2.1.
このモデルはセクション7.2.1で提示されます。
Asadullah, et al. Informational [Page 43] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[43ページ]のRFC4779ISP IPv6展開シナリオ
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は加入者とISPの間にPPPセッションを終えて、Layer3の接続性を提供します。
This model is presented in Section 7.2.2.
このモデルはセクション7.2.2で提示されます。
C. L2TPv2 Access Aggregation (LAA) Model: PPP sessions are opened
between each subscriber and the ISP termination devices. The
BRAS tunnels the subscriber PPP sessions to the ISP by
encapsulating them into L2TPv2 tunnels.
C.L2TPv2アクセス集合(LAA)はモデル化します: PPPセッションは各加入者とISP終了デバイスの間で開かれます。 L2TPv2トンネルにそれらをカプセル化することによって、BRASは加入者PPPセッションにISPにトンネルを堀ります。
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.
集合モデルでは、ISPへのアクセスを提供する前に、BRASは加入者VLANsを終えて、彼らの接続に集めます。
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 1に合うでしょう。 このアプローチはセクション7.2.1--7.2で提示されて、イーサネットブロードバンドの上で現在配布しているIPv4について説明する.3が展開にアクセスします。 ある状況で、下、新しいサービスタイプかサービスの必要性がそれを正当化するIPv4とIPv6ネットワークアーキテクチャはセクション7.2.4で説明されるように異なっているかもしれません。
7.2.1. Point-to-Point Model
7.2.1. 二地点間モデル
In this scenario, the Ethernet frames from the Host or the Customer Premise Router are bridged over the VLAN assigned to the subscriber.
このシナリオでは、HostかCustomer Premise Routerからのイーサネットフレームは加入者に割り当てられたVLANの上でブリッジされます。
Figure 7.2.1 describes the protocol architecture of this model.
図7.2 .1 このモデルのプロトコルアーキテクチャについて説明します。
| Customer Premise | | NAP | NSP |
| 顧客前提| | 仮眠| NSP|
+-----+ +------+ +------+ +--------+ +----------+
|Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP
+-----+ +------+ |Switch| +--------+ 802.1Q | Router +=>Network
+------+ +----------+
+-----+ +------+ +------+ +--------+ +----------+ |ホスト|--+ ルータ+--+ アクセス+--+ スイッチ+--------+ 縁| ISP+-----+ +------+ |スイッチ| +--------+ 802.1Q| ルータ+=>ネットワーク+------+ +----------+
|----------------------------|
Ethernet/VLANs
|----------------------------| イーサネット/VLANs
Figure 7.2.1
図7.2 .1
Asadullah, et al. Informational [Page 44] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[44ページ]のRFC4779ISP IPv6展開シナリオ
7.2.1.1. IPv6 Related Infrastructure Changes
7.2.1.1. IPv6はインフラストラクチャ変化を関係づけました。
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.
このシナリオには、Access Switchが顧客サイトにあって、全体のNAPがLayer3気づかないので、IPv6は変化が全くサポートされる必要はありません。 以下のデバイスはデュアルスタックにアップグレードしなければなりません: ホスト、顧客ルータ、および縁のルータ。
The Access switches might need upgrades to support certain IPv6- related features such as MLD Snooping.
Accessスイッチは、MLD SnoopingなどのあるIPv6関連する特徴をサポートするためにアップグレードを必要とするかもしれません。
7.2.1.2. Addressing
7.2.1.2. アドレシング
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.
彼らの次のLayer3が跳ぶとき、HostsかCustomer Routersには、Edge Routerがあります。 Customer Routerが全くなければ、加入者サイトのすべてのホストがその加入者VLANのためにEdge Routerで静的に構成される同じ/64サブネットに属します。 ホストは、Edge Routerを通してアドレスを習得するのに状態がない自動構成かstateful 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.
しかしながら、各顧客のための手動の構成が食糧を供給する挑戦であるので、実装は、自動的に、VLAN(または、ある他の顧客特定情報)を写像するメカニズムをIPv6サブネット接頭語に開発して、最小量の構成で顧客の特定の接頭語のすべての顧客に広告を出すよう奨励されます。
If a Customer Router is present:
Customer Routerが存在しているなら:
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. それはそれ自体とEdge Routerの間の/64サブネットに関するアドレス、およびインタフェースの顧客サイトにホストを接続する/64接頭語によって静的に構成されます。 高価であって、管理するのが難しくて、これは必要な食糧を供給するメソッドではありません。
B. It can use its link-local address to communicate with the ER. It
can also dynamically acquire, through stateless auto-
configuration, the address for the link between itself and the
ER. This step is followed by a request via DHCP-PD for a prefix
shorter than /64 that in turn is divided in /64s and assigned to
its interfaces connecting the hosts on the customer site.
B. それは、ERとコミュニケートするのにリンクローカルアドレスを使用できます。 また、それは状態がない自動構成を通してダイナミックにそれ自体とERとのリンクへのアドレスを習得できます。 要求は顧客サイトにホストを接続しながら順番に/64年代で分割されて、インタフェースに割り当てられる/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.
Edge Routerはそれぞれの加入者VLANのために/64接頭語を構成させます。 各VLANがISPネットワークで加入者からDHCPv6サーバまでのDHCPv6要求をリレーするのが有効にされるべきです。 DHCP-PDを使用する加入者にアクセスを提供するVLANsが特徴をサポートするのが有効にされなければなりません。 ISPネットワークへのアップリンクはまた、/64接頭語によって構成されます。
Asadullah, et al. Informational [Page 45] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[45ページ]のRFC4779ISP IPv6展開シナリオ
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を通して代表として派遣されたEdge Routerで同じくらい可能な同じくらい多くの総括を許す方法で計画されるべきです。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
stateful[RFC3315]と状態がない[RFC3736]DHCPv6を通してDNSなどのホストにとって、興味深い他の情報を提供します。
7.2.1.3. Routing
7.2.1.3. ルート設定
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デバイスはEdge Routerを示すデフォルトルートによって構成されます。 ルーティング・プロトコルは全くこれらのデバイスで必要ではありません。(一般に、デバイスはリソースを制限しました)。
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.
Edge RouterはNSPで使用されるIPv6 IGPを実行します: または、OSPFv3、- 接続接頭語を再配付しなければなりません。 DHCP-PDが使用されているなら、あらゆる代表として派遣された接頭語で、スタティックルートはEdge Routerによってインストールされます。 この理由で、また、スタティックルートを再配付しなければなりません。 接頭語総括をEdge Routerにするべきです。
7.2.2. PPP Terminated Aggregation (PTA) Model
7.2.2. pppの終えられた集合(PTA)モデル
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セッションは、Customer Premise Equipmentによって開始されて、BRASで終えられます。 BRASはISPを代表してセッションを認可して、加入者を認証して、IPアドレスを提供します。 そして、BRASは加入者トラフィックのLayer3ルーティングをNSP Edge Routerにします。
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 Edge Routerは同じ設備であり、上記の機能性を提供できました。
The PPPoE logical diagram in an Ethernet Broadband Network is shown in Fig 7.2.2.1.
イーサネットBroadband NetworkのPPPoEの論理的なダイヤグラムは図7.2.2で.1に見せられます。
Asadullah, et al. Informational [Page 46] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[46ページ]のRFC4779ISP IPv6展開シナリオ
| Customer Premise | | NAP | | NSP |
| 顧客前提| | 仮眠| | NSP|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
+-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O
|---------------- PPP ----------------| | | R
+-----------+ E
+-----------+ | AAA| +-------+ 半径| | | TACACS| | +-----------+ +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ |ホスト|-+ ルータスイッチ++が切り換える++A++ブラ++縁| C+-----+ +-------+ +--------+ +--------+ +----------+ | ルータ+=>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セッションはCustomer Premise Equipment(ホストかRouter)によって開始されます。 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.
このモデルは、複数のPPPoEセッションが同じVLANの上でサポートされるのを許容します、その結果、加入者が同時に複数のサービスに接続するのを許容します。 ホストはまた、PPPoEセッションを開始できます。 PPPoEカプセル化が顧客トラフィックに利用可能なIP MTUを減少させるのを覚えているのは重要です。
7.2.2.1. IPv6 Related Infrastructure Changes
7.2.2.1. IPv6はインフラストラクチャ変化を関係づけました。
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は、Layer3意識していて、IPv6をサポートするためにアップグレードしなければなりません。 BRASがPPPセッションを終えるので、それはIPv6と共にPPPoEをサポートしなければなりません。 以下のデバイスはデュアルスタックにアップグレードしなければなりません: ホスト、Customer Router(存在しているなら)、BRAS、およびEdge Router。
7.2.2.2. Addressing
7.2.2.2. アドレシング
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サーバの上に位置できます。彼らの次のLayer3が跳ぶとき、HostsかCustomer Routersには、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.
ホストかCustomer RouterがPPPセッションを開始できます。 後者の場合では、セッションがBRASと共にいったん確立されるとCustomer Routerインタフェースに接頭語を習得するのにDHCP-PDを使用できます。 DHCP-PDをサポートして、BRASが加入者サイトにおけるホストのDHCPv6要求をリレーするのが有効にされなければなりません。
Asadullah, et al. Informational [Page 47] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[47ページ]のRFC4779ISP IPv6展開シナリオ
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は、Edgeルータに直面しながら、リンクの上に/64接頭語を構成させます。 また、Edge Routerリンクは/64接頭語によって構成されて、ISPネットワークの残りに接続性を提供します。
The prefixes used for subscribers and the ones delegated via DHCP-PD should be planned in a manner that allows maximum summarization at the BRAS.
加入者に使用される接頭語とDHCP-PDを通して代表として派遣されたBRASで最大の総括を許す方法で計画されるべきです。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
stateful[RFC3315]と状態がない[RFC3736]DHCPv6を通してDNSなどのホストにとって、興味深い他の情報を提供します。
7.2.2.3. Routing
7.2.2.3. ルート設定
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をEdge Routerに実行します: または、OSPFv3、- 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.
Edge RouterはISPネットワークに使用されるIGPを実行しています: または、OSPFv3、- それらが独自に管理されるなら、ISPとAccess Providerの経路ドメインの間の分離はお勧めです。 制御再分配がAccess Provider IGPとISP IGPの間で必要でしょう。
7.2.3. L2TPv2 Access Aggregation (LAA) Model
7.2.3. L2TPv2アクセス集合(LAA)モデル
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はL2TPv2トンネルの上のISPへの開始しているセッションがBRASとEdge Routerの間に設立したCPEを進めます。 この場合、認証、承認、および加入者構成はISP自体によって実行されます。
Asadullah, et al. Informational [Page 48] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[48ページ]のRFC4779ISP IPv6展開シナリオ
| Customer Premise | | NAP | | NSP |
| 顧客前提| | 仮眠| | NSP|
+-----------+
| AAA |
+------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O
| | R
+-----------+ E
|-----------------------------------------------|
PPP
|--------------|
L2TPv2
Figure 7.2.3.1
+-----------+ | AAA| +------+ 半径| | | TACACS| | +-----+-----+ | | +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ |ホスト|-+ ルータスイッチ++が切り換える++A++ブラ++縁| C+-----+ +-------+ +--------+ +--------+ +----------+ | ルータ+=>O| | R+-----------+ E|-----------------------------------------------| ppp|--------------| L2TPv2図7.2.3.1
7.2.3.1. IPv6 Related Infrastructure Changes
7.2.3.1. IPv6はインフラストラクチャ変化を関係づけました。
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は、Layer3意識していて、IPv6をサポートするためにアップグレードしなければなりません。 ISPネットワークで集合ポイントへのL2TPv2トンネルの上に加入者によって開始されたPPPセッションを送ります。 L2TPv2を使用することで、BRAS(LAC)はIPv6 PPPセッションを集めて、LNSにそれらにトンネルを堀ることができます。 LACとLNSの間のL2TPv2トンネルはIPv6かIPv4をひくかもしれません。 これらの能力はBRASでサポートされなければなりません。 以下のデバイスはデュアルスタックにアップグレードしなければなりません: ホスト、Customer Router(存在しているなら)、BRAS、およびEdge Router。
7.2.3.2. Addressing
7.2.3.2. アドレシング
The Edge Router terminates the PPP sessions and provides the subscriber with an IPv6 address from the defined pool for that profile. The subscriber profile for authorization and authentication can be located on the Edge Router or on an AAA server. The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop.
Edge Routerはそのプロフィールのために定義されたプールからPPPセッションを終えて、IPv6アドレスを加入者に提供します。 承認と認証のための加入者プロフィールはEdge Routerの上、または、AAAサーバの上に位置できます。彼らの次のLayer3が跳ぶとき、HostsかCustomer Routersには、Edge Routerがあります。
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.
ホストかCustomer RouterがPPPセッションを開始できます。 後者の場合では、いったんセッションがEdge Routerと共に確立されて、IPv6アドレスがEdge RouterによってCustomer Routerに割り当てられると、Customer Router他のインタフェースに接頭語を習得するのにDHCP-PDを使用できます。 DHCP-PDをサポートして、Edge Routerが加入者サイトにおけるホストのDHCPv6要求をリレーするのが有効にされなければなりません。 ISPネットワークへのアップリンクはまた、/64接頭語によって構成されます。
Asadullah, et al. Informational [Page 49] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[49ページ]のRFC4779ISP IPv6展開シナリオ
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はEdge Routerへのリンクの上に/64接頭語を構成させます。 また、Edge Routerリンクは/64接頭語によって構成されて、ISPネットワークの残りに接続性を提供します。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
stateful[RFC3315]と状態がない[RFC3736]DHCPv6を通してDNSなどのホストにとって、興味深い他の情報を提供します。
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.
ずっとまた、このメディアアクセス型のために.2が関連しているセクション6.2.3で同じように議論したアドレス課題と接頭語総括問題。
7.2.3.3. Routing
7.2.3.3. ルート設定
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セッションを終えるEdge Routerを示すデフォルトルートによって構成されます。 ルーティング・プロトコルは全くこれらのデバイスで必要ではありません。(デバイスはリソースを制限しました)。
The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. Different processes should be used if the NAP and the NSP are managed by different organizations. In this case, controlled redistribution should be enabled between the two domains.
BRASはIPv6 IGPをEdge Routerに実行します: または、OSPFv3、- NAPとNSPが異なった組織によって管理されるなら、異なったプロセスは使用されるべきです。 この場合、制御再分配は2つのドメインの間で可能にされるべきです。
The Edge Router is running the IPv6 IGP used in the ISP network: OSPFv3 or IS-IS.
Edge RouterはISPネットワークに使用されるIPv6 IGPを実行しています: または、OSPFv3、-
7.2.4. Hybrid Model for IPv4 and IPv6 Service
7.2.4. IPv4のハイブリッド・モデルとIPv6サービス
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を写像するべきであることが勧められました。 このアプローチは、管理可能性を簡素化して、ネットワークを経営している人員に必要であるトレーニングを最小にします。 ある特定の状況では、そのようなマッピングは可能ではありません。 Service Providerが、新しい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セッションが、全体のNAPインフラストラクチャの向こう側に添付されて、トンネルを堀られます。インフラストラクチャは複数のBRASルータ、集合ルータなどで作られています。 これらのトンネルのエンドポイントはISP Edge Routerです。 SPが、そのようなデザインの上にマルチキャストサービスを提供すると決めると、利用され過ぎていて、それはNAPリソースの問題に直面するでしょう。 Edge Routerはトンネルの端だけにマルチキャストトラフィックを模写できます、そして、すべての加入者のためのコピーは全体のNAPの上まで運ばれます。
Asadullah, et al. Informational [Page 50] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[50ページ]のRFC4779ISP IPv6展開シナリオ
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.
Modified Pointからポイント、(目的地の、より近くでパケット模写がBRASにできるのでマルチキャストサービスをサポートするのにおいて.2か)PTAがモデル化するセクション7.2.4が、より適当であることを確実にしてください。 そのようなトポロジーは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のための変更されたPointからポイントかPTAデザインを選ぶかもしれません。
7.2.4.1. IPv4 in LAA Model and IPv6 in PTA Model
7.2.4.1. LAAのIPv4はモデル化します、そして、PTAにおけるIPv6はモデル化します。
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サービスのための異なったネットワークデバイスで終えられます。 IPv4サービスがLAAモデルで配布した存在のためのPPPセッションはEdge Routerで終えられます。 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
+-----------+
IPv6|--------------------------| ppp+-----------+ | AAA| +-------+ 半径| | | TACACS| | +-----+-----+ | | +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ |ホスト|--+ ルータ+------+ スイッチ++ブラ++縁| +-----+ +-------+ +--------+ +----------+ | ルータ+=>コア+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
IPv4|----------------------------------------| ppp|------------| L2TPv2
Figure 7.2.4.1
図7.2 .4 .1
Asadullah, et al. Informational [Page 51] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[51ページ]のRFC4779ISP IPv6展開シナリオ
7.2.4.2. IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model
7.2.4.2. LAAのIPv4はモデル化します、そして、変更されたポイントツーポイントにおけるIPv6はモデル化します。
The coexistence of the modified Point-to-Point and the LAA models implies a few specific changes.
変更されたPointからポイントと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サービスにおいて、VLANsはBRASで終えられます、そして、PPPセッションはEdge Router(LNS)で終えられます。 PointからポイントへのモデルにおけるIPv6サービスにおいて、VLANsはセクション6.2.1で説明されるようにEdge Routerで終えられます。 このハイブリッド・モデルでは、BRAS、NAPによって所有されているデバイスでPointからポイントへのリンクを終えることができました。 そして、IPv6トラフィックはNAPネットワークを通してNSPに発送されます。 このハイブリッド・モデルがいるように、BRASはデュアルスタックルータにアップグレードしなければなりません。 セクション6.2.1で説明されるEdge Routerの機能性は現在、BRASで実装されます。
The logical design for IPv6 and IPv4 in this hybrid model is in Figure 7.2.4.2.
図7.2.4にはこのハイブリッド・モデルのIPv6とIPv4のための論理的なデザインが.2にあります。
IPv6 |----------------|
Ethernet
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
IPv6|----------------| イーサネット+-----------+ | AAA| +-------+ 半径| | | TACACS| | +-----+-----+ | | +-----+ +-------+ +--------+ +----+-----+ +-----+-----+ |ホスト|--+ ルータ+------+ スイッチ++ブラ++縁| +-----+ +-------+ +--------+ +----------+ | ルータ+=>コア+-----------+ IPv4|----------------------------------------| ppp|------------| L2TPv2
Figure 7.2.4.2
図7.2 .4 .2
7.3. IPv6 Multicast
7.3. IPv6マルチキャスト
The typical multicast services offered for residential and very small businesses are video/audio streaming where the subscriber joins a multicast group and receives the content. This type of service model is well supported through PIM-SSM, which is very simple and easy to manage. PIM-SSM has to be enabled throughout the ISP network. MLDv2 is required for PIM-SSM support. Vendors can choose to implement features that allow routers to map MLDv1 group joins to predefined sources.
住宅の、そして、非常に小さいビジネスのために提供された典型的なマルチキャストサービスは加入者がマルチキャストグループに加わって、内容を受け取るところのビデオ/オーディオストリーミングです。 このタイプのサービスモデルはPIM-SSMを通してよくサポートされます。PIM-SSMは非常に簡単であって、管理しやすいです。 PIM-SSMはISPネットワーク中で有効にされなければなりません。 MLDv2がPIM-SSMサポートに必要です。 ベンダーは、地図への事前に定義されて、MLDv1グループが接合するルータを許容する特徴にソースを実装するのを選ぶことができます。
Asadullah, et al. Informational [Page 52] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[52ページ]のRFC4779ISP IPv6展開シナリオ
Subscribers might use a set-top box that is responsible for the control piece of the multicast service (does group joins/leaves). The subscriber hosts can also join desired multicast groups as long as they are enabled to support MLDv1 or MLDv2. If a CPR is used, then it has to be enabled to support MLDv1 and MLDv2 in order to process the requests of the hosts. It has to be enabled to support PIM-SSM in order to send PIM joins/leaves up to its Layer 3 next hop whether it is the BRAS or the Edge Router. When enabling this functionality on a CPR, its limited resources should be taken into consideration. Another option would be for the CPR to support MLD proxy routing. MLD snooping or similar Layer 2 multicast-related protocols could be enabled on the NAP switches.
加入者がマルチキャストサービスのコントロール断片に原因となるセットトップボックスを使用するかもしれない、(グループが合流するか、または残す、) また、MLDv1かMLDv2をサポートするのが可能にされる限り、加入者ホストは必要なマルチキャストグループに加わることができます。 CPRが使用されているなら、ホストの要求を処理するためにMLDv1とMLDv2をサポートするのが可能にされなければなりません。 発信するためにPIM-SSMをサポートするのが可能にされて、PIMがそれがBRASであるか、そして、Edge Routerに次のホップをLayer3に合流するか、または任せるということでなければなりません。 CPRでこの機能性を可能にするとき、限りある資源は考慮に入れられるべきです。 別のオプションはCPRが、MLDがプロキシルーティングであるとサポートするだろうことです。 NAPスイッチでMLD詮索か同様のLayer2のマルチキャスト関連のプロトコルを可能にすることができました。
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).
加入者からCPRsなしで来る要求を処理するためにMLDv1とMLDv2をサポートするのが可能にされるために加入者(LAAとPointからポイントへのモデルのPTAモデルかEdge RouterのBRAS)のための次のホップにはあるLayer3であるルータ。 受信して、PIM-SSMのために可能にされるのは顧客ルータから/葉を接合します、そして、発信してください。持っている、マルチキャストソース(縁のRouterかNSPコア)に向かった次のホップに/葉を接合します。
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を参照してください。
7.4. IPv6 QoS
7.4. IPv6 QoS
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構成は複数の加入者の中で共有されたリソースを管理して、次の3が加入者(LAAとPointからポイントへのモデルのPTAモデルかEdge RouterのBRAS)のために飛び越すLayerを表すルータで特に関連しています、ことによると様々なサービスレベル協定で。
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かEdge Routerでは、加入者に面するインタフェースは、顧客にとっての、外国行きのトラフィックがSLAに基礎づけた本国行きの顧客トラフィックと形を取り締まるために構成されなければなりません。 また、トラフィック分類とマークのときに、顧客トラフィックの様々なタイプをサポートするために加入者の最も近く(Layer3で)でルータをするべきです: データ、声、ビデオ、ネットワーク資源を最適に使用します。 このインフラストラクチャはQoSがLayer2デバイスの能力であると利用する非常に良い機会を提供します。 IPv4に使用されるDiffservベースのQoSはIPv6に広げられるべきです。
Asadullah, et al. Informational [Page 53] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[53ページ]のRFC4779ISP IPv6展開シナリオ
Each provider (NAP, NSP) could implement their own QoS policies and services so that reclassification and marking might be performed at the boundary between the NAP and the NSP, in order to make sure the traffic is properly handled by the ISP. The same IPv4 QoS concepts and methodologies should be applied for the IPv6 as well.
各プロバイダー(NAP、NSP)は、NAPとNSPの間の境界で再分類とマークを実行できるようにそれら自身のQoSが方針とサービスであると実装するかもしれません、トラフィックがISPによって適切に扱われるのを確実にするために。 同じ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ヘッダーフィールドを主に使用しようとするべきです。
7.5. IPv6 Security Considerations
7.5. IPv6セキュリティ問題
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.
セキュリティを高めて、CPEsのためにしなければならない限られた変化があります。 自動構成のためのプライバシー拡張子[RFC3041]はホストの追随性にセクション6.5で議論するように同じ問題でホストによって使用されるべきです。 IPv6ファイアウォール機能は、ホストかCustomer Premise Routerで可能にされて、存在しているべきです。
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).
何かEthertypesのためのLayer2フィルタが適所にあるなら、NAPはIPv6 Ethertype(0X86DD)を可能にしなければなりません。
The device that is the Layer 3 next hop for the subscribers (BRAS Edge Router) should protect the network and the other subscribers against attacks by one of the provider customers. For this reason uRPF and ACLs should be used on all interfaces facing subscribers. Filtering should be implemented with regard for the operational requirements of IPv6 [IPv6-Security].
次の3が加入者(BRAS Edge Router)のために飛び越すLayerであるデバイスはプロバイダー顧客のひとりによる攻撃に対してネットワークと他の加入者を保護するはずです。 この理由のために、uRPFとACLsは加入者に面しているすべてのインタフェースで使用されるべきです。 フィルタリングは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.
BRASとEdge Routerは以下などの有効な顧客コントロールトラフィックの洪水に対して彼らの処理リソースを保護するはずです。 ルータ、隣人懇願、およびMLD要求。 レート制限はすべての加入者に面するインタフェースで実装されるべきです。 それがIPv6制御飛行機によってたいてい使用されるとき、強調はマルチキャストタイプトラフィックに置かれるべきです。
All other security features used with the IPv4 service should be similarly applied to IPv6 as well.
IPv4サービスと共に使用される他のすべてのセキュリティ機能が同様にまた、IPv6に適用されるべきです。
Asadullah, et al. Informational [Page 54] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[54ページ]のRFC4779ISP IPv6展開シナリオ
7.6. IPv6 Network Management
7.6. IPv6ネットワークマネージメント
The necessary instrumentation (such as MIB modules, NetFlow Records, etc.) should be available for IPv6.
必要な計装(MIBモジュール、NetFlow Recordsなどの)は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.
通常、NSPsはSNMPで縁のルータを管理します。 すべての管理されたデバイスがIPv4とIPv6の両方の上に接続性を持っているなら、SNMP輸送がIPv4の上にできます。 これは既存のネットワークマネージメント練習とプロセスへの最も小さい変化を含意するでしょう。 また、IPv6の上の輸送を実装することができました、そして、それはネットワークで島だけがIPv6であるなら存在しているのが必要になるかもしれません。 管理アプリケーションはNSPコアネットワークドメインに属すホストで動いているかもしれません。 ネットワークManagement Applicationsは同様にIPv4にIPv6を扱うはずです。 しかしながら、また、彼らは隣人モニターなどのIPv6に特定の特徴をサポートするべきです。
In some cases, service providers manage equipment located on customers' LANs.
いくつかの場合、サービスプロバイダーは顧客のLANに位置する設備を管理します。
8. Wireless LAN
8. ワイヤレスのLAN
This section provides a detailed description of IPv6 deployment and integration methods in currently deployed wireless LAN (WLAN) infrastructure.
このセクションは無線LAN(WLAN)インフラストラクチャであると配布された現在のIPv6展開と統合メソッドの詳述を提供します。
8.1. WLAN Deployment Scenarios
8.1. WLAN展開シナリオ
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.
エイト環.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|
+------+
+------+ +--+ +--------------+ +----------+ +------+ |WLAN| ---- | | |アクセスルータ/| | プロバイダー| |縁| |ホスト/|-(WLAN)--|AP|-|層2のスイッチ|-| ネットワーク|-|ルータ|=>SP|ルータ| ---- | | | | | | | |ネットワーク+------+ +--+ +--------------+ +----------+ +------+ | +------+ |AAA| |サーバ| +------+
Figure 8.1
エイト環.1
Asadullah, et al. Informational [Page 55] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[55ページ]のRFC4779ISP IPv6展開シナリオ
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ネットワークに接続するために、ワイヤレスのNetwork Interface Card(NIC)を持つべきです。 WLANは平坦な放送網であり、同様にイーサネットとして働いています。 ホストが接続を開始するとき、それはSPネットワークに位置するAAAサーバによって認証されます。 すべての認証パラメタ(ユーザ名、パスワードなど)がAccess Point(AP)によってAAAサーバに転送されます。AAAサーバはホストを認証します。 いったん首尾よく認証されると、ホストはデータ・パケットを送ることができます。 APはホストの近くに位置していて、ブリッジとして機能します。 APはホストからEdge Routerまでの/に来るすべてのパケットを進めます。 APとEdge Routerとの基本的な接続は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.
WLANsはWiFi Hot Spotsとして知られている限られた領域の中で作動します。 ユーザがWLAN範囲でカバーされた領域に出席している間、彼らは与えられたインターネットに関連づけられて、自分達のデバイスにワイヤレスのNICと必要な構成設定を持っているということであるかもしれません(ノートPC、PDAなど)。 ユーザがいったん接続を開始すると、IPアドレスは、DHCPv4を使用することでSPによって割り当てられます。 場合の大部分では、SPは限られた数の公共のIPアドレスを顧客に割り当てます。 ユーザが接続から切断して、新しいWiFiホットスポットに移行するとき、認証と、アドレス課題と、インターネットにアクセスする上記のプロセスは繰り返されます。
There are IPv4 deployments where customers can use WLAN routers to connect over wireless to their service provider. These deployment types do not fit in the typical Hot Spot concept, but rather they serve fixed customers. For this reason, this section discusses the WLAN router options as well. In this case, the ISP provides a public IP address and the WLAN Router assigns private addresses [RFC1918] to all WLAN users. The WLAN Router provides NAT functionality while WLAN users access the Internet.
IPv4展開が顧客がワイヤレスの上でそれらのサービスプロバイダーに接続するのにWLANルータを使用できるところにあります。 これらの展開タイプは典型的なHot Spot概念をうまくはめ込みませんが、むしろ彼らは固定顧客に役立ちます。 この理由で、このセクションはまた、WLANルータオプションについて論じます。 この場合、ISPは公共のIPアドレスを提供します、そして、WLAN Routerはプライベート・アドレス[RFC1918]をすべてのWLANユーザに割り当てます。 WLANユーザはインターネットにアクセスしますが、WLAN RouterはNATの機能性を提供します。
While deploying IPv6 in the above-mentioned WLAN architecture, there are three possible scenarios as discussed below.
上記のWLANアーキテクチャでIPv6を配布している間、3つの可能なシナリオが以下で議論するようにあります。
A. Layer 2 NAP with Layer 3 termination at NSP Edge Router
Layer3終了がNSP Edge RouterにあるA.層2のNAP
B. Layer 3 aware NAP with Layer 3 termination at Access Router
Layer3終了がAccess RouterにあるB.層3の意識しているNAP
C. PPP-Based Model
C.のpppベースのモデル
8.1.1. Layer 2 NAP with Layer 3 termination at NSP Edge Router
8.1.1. Layer3終了がNSP Edge Routerにある層2のNAP
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.
Layer2スイッチがAPとEdge Routerの間に存在しているとき、APとLayer2スイッチは、架け橋として尽力し続けています、WLAN Host/ルータからEdge Routerまで逆もまた同様にIPv4とIPv6にパケットを送って。
Asadullah, et al. Informational [Page 56] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[56ページ]のRFC4779ISP 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 HostはSPネットワークに位置するAAAサーバによって認証されます。 認証(ユーザ名、パスワードなど)に関連するすべてのパラメタがAPによってAAAサーバに転送されます。AAAサーバはWLAN Hostsを認証して、WLAN Hostがいったん首尾よくWLAN APに認証されて、関連づけられると、それはIPv6アドレスを習得します。 開始と認証が処理されるというメモはIPv4で使用されるのと同じです。
Figure 8.1.1 describes the WLAN architecture when a Layer 2 Switch is located between AP and Edge Router.
Layer2SwitchがAPとEdge Routerの間に位置しているとき、エイト環.1.1はWLANアーキテクチャについて説明します。
Customer | Access Provider | Service Provider
Premise | |
顧客| アクセスプロバイダ| サービスプロバイダー前提| |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
+------+
|AAA |
|Server|
+------+
+------+ +--+ +--------------+ +----------+ +------+ |WLAN| ---- | | | | | プロバイダー| |縁| |ホスト/|-(WLAN)--|AP|-|層2のスイッチ|-| ネットワーク|-|ルータ|=>SP|ルータ| ---- | | | | | | | |ネットワーク+------+ +--+ +--------------+ +----------+ +------+ | +------+ |AAA| |サーバ| +------+
Figure 8.1.1
エイト環.1.1
8.1.1.1. IPv6 Related Infrastructure Changes
8.1.1.1. IPv6はインフラストラクチャ変化を関係づけました。
IPv6 will be deployed in this scenario by upgrading the following devices to dual stack: WLAN Host, WLAN Router (if present), and Edge Router.
IPv6はこのシナリオで以下のデバイスをデュアルスタックにアップグレードさせることによって、配布されるでしょう: WLAN Host、WLAN Router(存在しているなら)、およびEdge Router。
8.1.1.2. Addressing
8.1.1.2. アドレシング
When a customer WLAN Router is not present, the WLAN Host has two possible options to get an IPv6 address via the Edge Router.
顧客WLAN Routerが存在していないとき、WLAN Hostには、Edge Routerを通して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 Hostは、Edge Routerから状態がない自動構成[RFC2462]を使用することでIPv6アドレスを得ることができます。 WLANの上のすべてのホストがEdge Routerで静的に構成される同じ/64サブネットに属します。 IPv6 WLAN Hostは、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
IPv6 WLAN Hostは、DHCPv6サーバからIPv6アドレスを得るのに、DHCPv6[RFC3315]を使用できます。B. この場合、DHCPv6サーバはSPコアネットワークで位置していて、Edge RouterはDHCP Relayエージェントとして単に務めるでしょう。 このオプションは同様です。
Asadullah, et al. Informational [Page 57] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[57ページ]のRFC4779ISP IPv6展開シナリオ
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.
今日DHCPv4の場合に行われることに。 stateful自動構成のホスト導入がこのときかなり限られることに注意するのが重要であり、このアドレス課題オプションを選ぶなら、これは考えられるべきです。
When a customer WLAN Router is present, the WLAN Host has two possible options as well for acquiring IPv6 address.
顧客WLAN Routerが存在しているとき、WLAN Hostには、また、2つの可能なオプションが、IPv6アドレスを習得するためにあります。
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. SP方針と顧客の要求によって、/48と/64[RFC3177]の間の接頭語はWLAN Routerに割り当てられるかもしれません。 WLAN Routerが複数のネットワークをインタフェースに接続させると、ネットワーク管理者は/64接頭語を顧客サイトのWLAN Hostsを接続するWLAN Routerインタフェースまで構成しなければならないでしょう。 これらのインタフェースに接続されたWLAN Hostsは、状態がない自動構成を使用することで自動的に自分たちを構成できます。
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 Routerは、ERとコミュニケートするのにリンクローカルアドレスを使用できます。 また、それは状態がない自動構成を通してダイナミックにそれ自体とERとのリンクへのアドレスを習得できます。 要求は顧客サイトにホストを接続しながら順番に/64年代で分割されて、インタフェースに割り当てられる/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.
このオプションでは、要求ルータとEdge Routerが代表として派遣するルータとして機能するようにWLAN Routerは行動するでしょう。 かつて、接頭語はWLAN Routerによって受け取られて、それは顧客サイトのWLAN Hostsを接続するそれぞれのインタフェースへの案配/64接頭語です。 これらのインタフェースに接続されたWLAN Hostsは、状態がない自動構成を使用することで自動的に自分たちを構成できます。 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.
通常、SPsがDNS/ドメイン情報、プロキシ構成などのためにDHCP-PDと状態がない自動構成モデルと共に滞在して、クライアントをセントラルサーバーに向けるのは、より簡単です。 このモデルを使用して、SPは急いで接頭語を変えることができました、そして、WLAN Routerは単に有効であるか都合のよい生涯に基づく中で最も新しい接頭語を引くでしょう。
The prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows maximum summarization at the Edge Router.
加入者リンクに使用される接頭語とDHCP-PDを通して代表として派遣されたEdge Routerで最大の総括を許す方法で計画されるべきです。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
stateful[RFC3315]と状態がない[RFC3736]DHCPv6を通してDNSなどのホストにとって、興味深い他の情報を提供します。
Asadullah, et al. Informational [Page 58] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[58ページ]のRFC4779ISP IPv6展開シナリオ
8.1.1.3. Routing
8.1.1.3. ルート設定
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 Host/ルータは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. 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.
または、Edge RouterがOSPFv3などのSPネットワークに使用されるIGPを実行する、-、IPv6のために。 接続接頭語を再配付しなければなりません。 接頭語総括をEdge Routerにするべきです。 DHCP-PDが使用されているとき、IGPは接頭語委譲のプロセスの間にインストールされたスタティックルートを再配付しなければなりません。
8.1.2. Layer 3 Aware NAP with Layer 3 Termination at Access Router
8.1.2. アクセスルータにおける層3の終了との3の意識している仮眠を層にしてください。
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.
Access RouterがAPとEdge Routerの間に存在しているとき、APは、架け橋として尽力し続けています、IPv4とIPv6がパケットであるとWLAN Host/ルータからAccess Routerまで逆もまた同様にブリッジして。 Access Routerは別々のAccess Providerによる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 Hostが接続を開始するとき、WLAN APがあるAAA認証と協会プロセスは同様になるでしょう、セクション8.1.1で説明されるように。
Figure 8.1.2 describes the WLAN architecture when the Access Router is located between the AP and Edge Router.
Access RouterがAPとEdge Routerの間に位置しているとき、エイト環.1.2はWLANアーキテクチャについて説明します。
Customer | Access Provider | Service Provider
Premise | |
顧客| アクセスプロバイダ| サービスプロバイダー前提| |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
+------+
|AAA |
|Server|
+------+
+------+ +--+ +--------------+ +----------+ +------+ |WLAN| ---- | | | | | プロバイダー| |縁| |ホスト/|-(WLAN)--|AP|-|アクセスルータ|-| ネットワーク|-|ルータ|=>SP|ルータ| ---- | | | | | | | |ネットワーク+------+ +--+ +--------------+ +----------+ +------+ | +------+ |AAA| |サーバ| +------+
Figure 8.1.2
エイト環.1.2
8.1.2.1. IPv6 Related Infrastructure Changes
8.1.2.1. IPv6はインフラストラクチャ変化を関係づけました。
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 Host、WLAN Router(存在しているなら)、Access Router、およびEdge Router。
Asadullah, et al. Informational [Page 59] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[59ページ]のRFC4779ISP IPv6展開シナリオ
8.1.2.2. Addressing
8.1.2.2. アドレシング
There are three possible options in this scenario for IPv6 address assignment:
IPv6アドレス課題のためのこのシナリオには3つの可能なオプションがあります:
A. The Edge Router interface facing towards the Access Router is
statically configured with a /64 prefix. The Access Router
receives/ configures a /64 prefix on its interface facing towards
the Edge Router through stateless auto-configuration. The
network administrator will have to configure the /64 prefixes to
the Access Router interface facing toward the customer premise.
The WLAN Host/Router connected to this interface can
automatically configure itself using stateless auto-
configuration.
A. Access Routerに向くEdge Routerインタフェースは/64接頭語によって静的に構成されます。 Access Routerは、状態がない自動構成を通してEdge Routerに向きながら、インタフェースで/64接頭語を受け取るか、または構成します。 ネットワーク管理者は/64接頭語を顧客前提に向くAccess Routerインタフェースまで構成しなければならないでしょう。 このインタフェースに接続されたWLAN Host/ルータは、状態がない自動構成を使用することで自動的にそれ自体を構成できます。
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. このオプションはIPv6接頭語課題に、DHCPv6[RFC3315]をWLAN Host/ルータに使用します。 このオプションにはDHCP PDの無駄か状態がない自動構成があります。 DHCPv6サーバはAccess Router、Edge Routerの上かSPネットワークにおけるどこかに位置できます。 この場合、DHCPv6サーバが位置しているところによるか、Access RouterまたはEdge RouterがDHCPv6要求をリレーするでしょう。
C. It can use its link-local address to communicate with the ER. It
can also dynamically acquire through stateless auto-configuration
the address for the link between itself and the ER. This step is
followed by a request via DHCP-PD for a prefix shorter than /64
that, in turn, is divided in /64s and assigned to its interfaces
connecting the hosts on the customer site.
C. それは、ERとコミュニケートするのにリンクローカルアドレスを使用できます。 また、それは状態がない自動構成を通してダイナミックにそれ自体とERとのリンクへのアドレスを習得できます。 要求は顧客サイトにホストを接続しながら順番に/64年代で分割されて、インタフェースに割り当てられる/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.
このオプションでは、Access Routerは要求ルータとして機能するでしょう、そして、Edge Routerは代表として派遣するルータとして機能するでしょう。 かつて、接頭語はAccess Routerによって受け取られて、それはWLAN Host/ルータを顧客サイトに関連づけるそれぞれのインタフェースへの案配/64接頭語です。 これらのインタフェースに接続されたWLAN Host/ルータは、状態がない自動構成を使用することで自動的にそれ自体を構成できます。 ISPネットワークへのアップリンクはまた、/64接頭語によって構成されます。
It is easier for the SPs to stay with the DHCP PD and stateless auto- configuration model and point the clients to a central server for DNS/domain information, proxy configurations, and others. Using this model, the provider could change prefixes on the fly, and the Access Router would simply pull the newest prefix based on the valid/ preferred lifetime.
SPsがDHCP PDと状態がない自動構成モデルと共に滞在して、DNS/ドメイン情報、プロキシ構成、および他のもののためにクライアントをセントラルサーバーに向けるのは、より簡単です。 このモデルを使用して、プロバイダーは急いで接頭語を変えるかもしれません、そして、Access Routerは単に有効であるか都合のよい生涯に基づく中で最も新しい接頭語を引くでしょう。
Asadullah, et al. Informational [Page 60] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[60ページ]のRFC4779ISP IPv6展開シナリオ
As mentioned before, the prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows the maximum summarization possible at the Edge Router. Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
以前言及されるように、加入者リンクに使用される接頭語とDHCP-PDを通して代表として派遣されたEdge Routerで可能な最大の総括を許す方法で計画されるべきです。 stateful[RFC3315]と状態がない[RFC3736]DHCPv6を通してDNSなどのホストにとって、興味深い他の情報を提供します。
8.1.2.3. Routing
8.1.2.3. ルート設定
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 Host/ルータはAccess Routerを示すデフォルトルートによって構成されます。 ルーティング・プロトコルは全くこれらのデバイスで必要ではありません。(一般に、デバイスはリソースを制限しました)。
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.
Access RouterがAccess Providerによって所有されているなら、Access Routerはデフォルトルートを持つことができます、SP Edge Routerを示して。 または、Edge RouterがOSPFv3などのSPネットワークに使用されるIGPを実行する、-、IPv6のために。 接続接頭語を再配付しなければなりません。 DHCP-PDが使用されているなら、あらゆる代表として派遣された接頭語で、スタティックルートはEdge Routerによってインストールされます。 この理由で、スタティックルートを再配付しなければなりません。 接頭語総括をEdge Routerにするべきです。
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.
または、Access RouterがSPによって所有されているなら、Access Routerがまた、IPv6 IGPを実行して、SP IPv6経路ドメインの一部になる、(OSPFv3、-、) 接続接頭語を再配付しなければなりません。 DHCP-PDが使用されているなら、あらゆる代表として派遣された接頭語で、スタティックルートはAccess Routerによってインストールされます。 この理由で、スタティックルートを再配付しなければなりません。 接頭語総括をAccess Routerにするべきです。
8.1.3. PPP-Based Model
8.1.3. pppベースのモデル
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.
また、IPv6 WLAN環境でPPP Terminated Aggregation(PTA)とセクション6.2.2と6.2で.3について議論するとき(LAA)がそれぞれモデル化するL2TPv2 Access Aggregationを配布することができます。
8.1.3.1. PTA Model in IPv6 WLAN Environment
8.1.3.1. IPv6 WLAN環境におけるPTAモデル
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モデルを配布している間、Access RouterはLayer3意識しています、そして、それは、IPv6をサポートするためにアップグレードしなければなりません。 Access RouterがWLAN Host/ルータによって開始されたPPPセッションを終えるので、それはIPv6と共にPPPoEをサポートしなければなりません。
Figure 8.1.3.1 describes the PTA Model in IPv6 WLAN environment.
エイト環、.1 .3 .1 IPv6 WLAN環境でPTA Modelについて説明します。
Asadullah, et al. Informational [Page 61] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[61ページ]のRFC4779ISP IPv6展開シナリオ
Customer | Access Provider | Service Provider
Premise | |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
|---------------------------| +------+
PPP |AAA |
|Server|
+------+
顧客| アクセスプロバイダ| サービスプロバイダー前提| | +------+ +--+ +--------------+ +----------+ +------+ |WLAN| ---- | | | | | プロバイダー| |縁| |ホスト/|-(WLAN)--|AP|-|アクセスルータ|-| ネットワーク|-|ルータ|=>SP|ルータ| ---- | | | | | | | |ネットワーク+------+ +--+ +--------------+ +----------+ +------+ | |---------------------------| +------+ ppp|AAA| |サーバ| +------+
Figure 8.1.3.1
エイト環.1.3、.1
8.1.3.1.1. IPv6 Related Infrastructure Changes
8.1.3.1.1. IPv6はインフラストラクチャ変化を関係づけました。
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 Host、WLAN Router(存在しているなら)、Access Router、およびEdge Router。
8.1.3.1.2. Addressing
8.1.3.1.2. アドレシング
The addressing techniques described in Section 6.2.2.2 apply to the IPv6 WLAN PTA scenario as well.
.2がまた、IPv6 WLAN PTAシナリオに適用するセクション6.2.2で説明されたアドレシングのテクニック。
8.1.3.1.3. Routing
8.1.3.1.3. ルート設定
The routing techniques described in Section 6.2.2.3 apply to the IPv6 WLAN PTA scenario as well.
.3がまた、IPv6 WLAN PTAシナリオに適用するセクション6.2.2で説明されたルーティングのテクニック。
8.1.3.2. LAA Model in IPv6 WLAN Environment
8.1.3.2. LAAはIPv6 WLAN環境でモデル化します。
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モデルを配布している間、Access Routerは、Layer3意識していて、IPv6をサポートするためにアップグレードしなければなりません。 SPネットワークでWLAN Host/ルータによって開始されたPPPセッションを集合ポイントへのL2TPv2トンネルの上に送ります。 Access Routerには、IPv6のためにL2TPv2をサポートする能力がなければなりません。
Figure 8.1.3.2 describes the LAA Model in IPv6 WLAN environment.
エイト環、.1 .3 .2 IPv6 WLAN環境でLAA Modelについて説明します。
Asadullah, et al. Informational [Page 62] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[62ページ]のRFC4779ISP IPv6展開シナリオ
Customer | Access Provider | Service Provider
Premise | |
顧客| アクセスプロバイダ| サービスプロバイダー前提| |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
|-------------------------------------------------- |
PPP |
|--------------------- |
L2TPv2 |
+------+
|AAA |
|Server|
+------+
+------+ +--+ +--------------+ +----------+ +------+ |WLAN| ---- | | | | | プロバイダー| |縁| |ホスト/|-(WLAN)--|AP|-|アクセスルータ|-| ネットワーク|-|ルータ|=>SP|ルータ| ---- | | | | | | | |ネットワーク+------+ +--+ +--------------+ +----------+ +------+ | |-------------------------------------------------- | ppp| |--------------------- | L2TPv2| +------+ |AAA| |サーバ| +------+
Figure 8.1.3.2
エイト環.1.3、.2
8.1.3.2.1. IPv6 Related Infrastructure Changes
8.1.3.2.1. IPv6はインフラストラクチャ変化を関係づけました。
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 Host、WLAN Router(存在しているなら)、Access Router、およびEdge Router。
8.1.3.2.2. Addressing
8.1.3.2.2. アドレシング
The addressing techniques described in Section 6.2.3.2 apply to the IPv6 WLAN LAA scenario as well.
.2がまた、IPv6 WLAN LAAシナリオに適用するセクション6.2.3で説明されたアドレシングのテクニック。
8.1.3.2.3. Routing
8.1.3.2.3. ルート設定
The routing techniques described in Section 6.2.3.3 apply to the IPv6 WLAN LAA scenario as well.
.3がまた、IPv6 WLAN LAAシナリオに適用するセクション6.2.3で説明されたルーティングのテクニック。
8.2. IPv6 Multicast
8.2. IPv6マルチキャスト
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 Hostがマルチキャストグループに加わって、内容を受け取るところのビデオ/オーディオストリーミングです。 このタイプのサービスモデルはPIM- SSMを通してよくサポートされます。PIM- SSMはSPネットワーク中で有効にされます。 MLDv2がPIM-SSMサポートに必要です。 ベンダーは、地図への事前に定義されて、MLDv1グループが接合するルータを許容する特徴にソースを実装するのを選ぶことができます。
Asadullah, et al. Informational [Page 63] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[63ページ]のRFC4779ISP IPv6展開シナリオ
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.
また、MLDv1かMLDv2をサポートするのが可能にされる限り、IPv6 WLAN Hostsは必要なマルチキャストグループに加わることができます。 WLAN/アクセスRoutersが使用されているなら、彼らがIPv6 WLAN Hostsの要求を処理するためにMLDv1とMLDv2をサポートするのが可能にされなければなりません。 またRouterがPIMを送るためにPIM-SSMをサポートするのが可能にされる必要があるWLAN/アクセスはEdge Routerまで接合します。 WLAN/アクセスRouterでこの機能性を可能にするとき、限りある資源は考慮に入れられるべきです。 別のオプションはWLAN/アクセスRouterが、MLDがプロキシルーティングであるとサポートするだろうことです。
The Edge Router has to be enabled to support MLDv1 and MLDv2 in order to process the requests coming from the IPv6 WLAN Host or WLAN/Access Router (if present). The Edge Router has also needs to be enabled for PIM-SSM in order to receive joins from IPv6 WLAN Hosts or WLAN/ Access Router (if present), and send joins towards the SP core.
Edge RouterがIPv6 WLAN HostかWLAN/アクセスRouterから来る要求を処理する(存在しているなら)ためにMLDv1とMLDv2をサポートするのが有効にされなければなりません。 Edge Routerはそうしました、また、受信して、PIM-SSMのために可能にされるべき必要性がIPv6 WLAN HostsかWLAN/アクセスRouterから接合します(存在しているなら)、そして、発信してください。SPコアに向かって接合します。
MLD authentication, authorization, and accounting are usually configured on the Edge Router in order to enable the SP to do billing for the content services provided. Further investigation should be made in finding alternative mechanisms that would support these functions.
通常、MLD認証、承認、および会計は、SPが提供されたコンテンツサービスのために支払いをするのを可能にするためにEdge Routerで構成されます。 これらの機能をサポートする代替のメカニズムを見つける際にさらなる調査をするべきです。
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リンクの上のどんなLayer3プロトコル((設定が適切に調整されないとき、下げられます)基づくマルチキャストである、あるフレーム)も実行するとき、潜在的にこれらは同じ種類の問題です。 例えば、この振舞いはIGMPホスト会員資格レポートと同様です、高い合図する損失比と高い干渉とのWLANリンクですると。
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コミュニケーション用途のDuplicate Address Detectionなどの機能(DAD)、Router、およびNeighbor
Asadullah, et al. Informational [Page 64] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[64ページ]のRFC4779ISP IPv6展開シナリオ
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)とRouterとNeighbor Advertisement(RA、NA)(上記の問題はこれらのフレームとして影響を与えることができた)などはLayer2イーサネットマルチキャストフレームです。
Please refer to Section 6.3 for more IPv6 multicast details.
よりその他のIPv6マルチキャストの詳細についてセクション6.3を参照してください。
8.3. IPv6 QoS
8.3. IPv6 QoS
Today, QoS is done outside of the WiFi domain, but it is nevertheless important to the overall deployment.
今日、WiFiドメインの外でQoSをしますが、それにもかかわらず、それは総合的な展開に重要です。
The QoS configuration is particularly relevant on the Edge Router in order to manage resources shared amongst multiple subscribers possibly with various service level agreements (SLAs). However, the WLAN Host/Router and Access Router could also be configured for QoS. This includes support for appropriate classification criteria, which would need to be implemented for IPv6 unicast and multicast traffic.
QoS構成は、複数の加入者の中でことによると様々なサービスレベル協定(SLA)と共有されたリソースを管理するためにEdge Routerで特に関連しています。 しかしながら、また、QoSのためにWLAN Host/ルータとAccess Routerを構成できました。 これは適切な分類評価基準のサポートを含んでいます。(評価基準はIPv6ユニキャストとマルチキャストトラフィックのために実装される必要があるでしょう)。
On the Edge Router, the subscriber-facing interfaces have to be configured to police the inbound customer traffic and shape the traffic outbound to the customer, based on the SLA. Traffic classification and marking should also be done on the Edge Router in order to support the various types of customer traffic: data, voice, and video. The same IPv4 QoS concepts and methodologies should be applied for the IPv6 as well.
Edge Routerでは、加入者に面するインタフェースは本国行きの顧客トラフィックを取り締まって、顧客にとっての、外国行きのトラフィックを形成するために構成されなければなりません、SLAに基づいて。 トラフィック分類とまた、顧客トラフィックの様々なタイプをサポートするためにEdge Routerでマークするべきです: データ、声、およびビデオ。 同じ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ヘッダーフィールドを主に使用しようとするべきです。
8.4. IPv6 Security Considerations
8.4. IPv6セキュリティ問題
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 Host/ルータのためにしなければならない限られた変化があります。 自動構成のためのプライバシー拡張子[RFC3041]はホストの追随性にセクション6.5で説明されるように同じ考慮でホストによって使用されるべきです。 IPv6ファイアウォール機能は、WLAN Host/ルータで可能にされて、存在しているべきです。
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はそれ自身の加入者から起こる攻撃に対してセキュリティを提供しますが、また、それは、セキュリティがネットワークの外から出典を明示された攻撃から加入者を保護するサービスであると実装するかもしれません。 そのようなサービスはここで議論したネットワークのアクセスレベルで申請されません。
Asadullah, et al. Informational [Page 65] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[65ページ]のRFC4779ISP IPv6展開シナリオ
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)はウェブブラウザと認証サーバの間で使用されるべきです。認証サーバはバックエンドで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.
認証はLayer3に安全保障政策を実装する前にWLANにネットワークを保証する重要な一面です。 例えば、これは、ノースダコタか状態がない自動構成プロセスへの脅威を避けるのを助けるでしょう。 802.1 x[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つの新しいデータの機密性プロトコルと、Temporal Key Integrityプロトコル(TKIP)とCounter-モードであるか/CBC-MACプロトコル(CCMP))があります。 802.11 また、私は、ネットワークへのアクセスを制御するのに802.1Xの主要な流通制度を使用します。 802.11がユニキャストと放送トラフィックを異なって扱うので、それぞれのトラフィックタイプには、異なった安全上の配慮があります。 いくつかのデータの機密性プロトコルと主要な分配で、802.11iはそれぞれのトラフィックタイプの正しい秘密性プロトコルと主要なシステムを選択するための交渉プロセスを含んでいます。 導入された他の特徴は主要なキャッシュとプレ認証を含んでいます。
The 802.11i amendment is a step forward in wireless security. The amendment adds stronger encryption, authentication, and key management strategies that could make wireless data and systems more secure.
802.11i修正はワイヤレスのセキュリティで先取りです。 修正は、より強い暗号化、認証、およびワイヤレスのデータとシステムをより安全にすることができたかぎ管理戦略を加えます。
If any Layer 2 filters for Ethertypes are in place, the NAP must permit the IPv6 Ethertype (0X86DD).
何かEthertypesのためのLayer2フィルタが適所にあるなら、NAPはIPv6 Ethertype(0X86DD)を可能にしなければなりません。
The device that is the Layer 3 next hop for the subscribers (Access or Edge Router) should protect the network and the other subscribers against attacks by one of the provider customers. For this reason uRPF and ACLs should be used on all interfaces facing subscribers. Filtering should be implemented with regard for the operational requirements of IPv6 [IPv6-Security].
次の3が加入者(アクセスかEdge Router)のために飛び越すLayerであるデバイスはプロバイダー顧客のひとりによる攻撃に対してネットワークと他の加入者を保護するはずです。 この理由のために、uRPFとACLsは加入者に面しているすべてのインタフェースで使用されるべきです。 フィルタリングは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
AccessとEdge Routerは以下などの有効な顧客コントロールトラフィックの洪水に対して彼らの処理リソースを保護するはずです。 RS、ナノ秒、およびMLD要求。 レート制限はすべてで実装されるべきです。
Asadullah, et al. Informational [Page 66] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[66ページ]のRFC4779ISP IPv6展開シナリオ
subscriber-facing interfaces. The emphasis should be placed on multicast-type traffic, as it is most often used by the IPv6 control plane.
加入者面は連結します。 それがIPv6制御飛行機によってたいてい使用されるとき、強調はマルチキャストタイプトラフィックに置かれるべきです。
8.5. IPv6 Network Management
8.5. IPv6ネットワークマネージメント
The necessary instrumentation (such as MIB modules, NetFlow Records, etc) should be available for IPv6.
必要な計装(MIBモジュール、NetFlow Recordsなどの)は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).
通常、NSPsはSNMPで縁のルータを管理します。 すべての管理されたデバイスがIPv4とIPv6の両方の上に接続性を持っているなら、SNMP輸送がIPv4の上にできます。 これは既存のネットワークマネージメント練習とプロセスへの最も小さい変化を含意するでしょう。 また、IPv6の上の輸送を実装することができました、そして、それはネットワークで島だけがIPv6であるなら存在しているのが必要になるかもしれません。 管理アプリケーションはNSPコアネットワークドメインに属すホストで動いているかもしれません。 ネットワークManagement Applicationsは同様にIPv4にIPv6を扱うはずです。 しかしながら、また、彼らはIPv6(隣人モニターなどの)に特定の特徴をサポートするべきです。
In some cases, service providers manage equipment located on customers' LANs.
いくつかの場合、サービスプロバイダーは顧客のLANに位置する設備を管理します。
9. Broadband Power Line Communications (PLC)
9. 広帯域の電力線通信(PLC)
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.
このセクションはPower線Communications(PLC)アクセスNetworksでIPv6展開について説明します。 他の選択があるかもしれませんが、続くようにこれが最高のモデルであるように思えます。 また、ケーブルから学習されたレッスン、イーサネット、およびWLANアクセスネットワークもさえ適切であるかもしれません。
Power Line Communications are also often called Broadband Power Line (BPL) and sometimes even Power Line Telecommunications (PLT).
また、パワー線CommunicationsはしばしばBroadband Power線(BPL)と時々Power線さえTelecommunications(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).
今日の技術に送電網による(総で、上流か川下)の200Mbpsまで提供するのにPLC/BPLを使用できます。 そして、しばしば適用範囲が最後の半マイル(典型的な媒体から低電圧への変圧器から顧客前提メーターまでの距離)である、もちろん、ホームネットワーク、(このドキュメントの範囲の外にあります。)
The bandwidth in a given PLC/BPL segment is shared among all the customers connected to that segment (often the customers connected to the same medium-to-low voltage transformer). The number of customers can vary depending on different factors, such as distances and even countries (from a few customers, just 5-6, up to 100-150).
与えられたPLC/BPLセグメントにおける帯域幅はそのセグメント(しばしば媒体から低電圧への同じ変圧器に接続された顧客)に接続されたすべての顧客の中で共有されます。 異なった要素によって、顧客の数は異なることができます、距離や国(数人の顧客からのちょうど5-6、100-150)のようにさえ。
Asadullah, et al. Informational [Page 67] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[67ページ]のRFC4779ISP IPv6展開シナリオ
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.
また、中型の電圧ネットワーク(Metropolitan Area Networksとしてしばしば構成される)にPLC/BPLを使用できましたが、このドキュメントの範囲のも外にこれはあります、アクセス1ではなく、コアネットワークの一部になるので。
9.1. PLC/BPL Access Network Elements
9.1. PLC/BPLアクセスネットワークElements
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.
ギヤエンド(彼): 媒体から低電圧への変圧器に位置する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が透明なLayer2ブリッジであるといつも考えられるので、それは存在しているかもしれません(Layer3観点からの)。
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)
縁のルータ(えー)
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 |-----------+
+-----+ +------+ +-----+
+-----+ +------+ +-----+ +------+ +--------+ |ホスト|--| RCPE|--| RPT|--------+ ヘッド+---+ 縁| ISP+-----+ +------+ +-----+ | 終わり| | ルータ+=>ネットワーク+--+---+ +--------+ +-----+ +------+ +-----+ | |ホスト|--| BCPE|--| RPT|-----------+ +-----+ +------+ +-----+
Figure 9.1
図9.1
Asadullah, et al. Informational [Page 68] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[68ページ]のRFC4779ISP IPv6展開シナリオ
The logical topology and design of PLC/BPL is very similar to Ethernet Broadband Networks as discussed in Section 7. IP connectivity is typically provided in a Point-to-Point model, as described in Section 7.2.1
PLC/BPLの論理的トポロジーとデザインはセクション7で議論するようにイーサネットBroadband Networksと非常に同様です。 セクション7.2.1で説明されるようにPointからポイントへのモデルにIPの接続性を通常提供します。
9.2. Deploying IPv6 in IPv4 PLC/BPL
9.2. IPv4 PLC/BPLでIPv6を配布します。
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 1に合うでしょう。 ある状況で、下、新しいサービスタイプかサービスの必要性がそれを正当化するIPv4とIPv6ネットワークアーキテクチャは異なっているかもしれません。 両方のアプローチはイーサネットケースのために既に説明されたものと非常に同様です。
9.2.1. IPv6 Related Infrastructure Changes
9.2.1. 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だけでは、Layer3は気づかないのですが、対向機器はデュアルスタックHosts、RCPE、Head End、およびEdge Routerにアップグレードしなければなりません。
9.2.2. Addressing
9.2.2. アドレシング
The Hosts or the RCPEs have the HE as their Layer 3 next hop.
彼らの次のLayer3が跳ぶとき、HostsかRCPEsには、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を通してアドレスを習得するのに状態がない自動構成かstateful 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
B. それは、HEとコミュニケートするのにリンクローカルアドレスを使用できます。 また、それは状態がない自動構成を通してダイナミックにそれ自体とHEとのリンクへのアドレスを習得できます。 このステップはそうです。
Asadullah, et al. Informational [Page 69] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[69ページ]のRFC4779ISP IPv6展開シナリオ
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.
要求は顧客サイトにホストを接続しながら順番に/64年代で分割されて、インタフェースに割り当てられる/64(通常/48[RFC3177])より短い接頭語のためのDHCP-PDを通してあとに続いています。 より安くて、管理するのが、より簡単であることで、これは都合のよい食糧を供給するメソッドであるべきです。
The Edge Router needs to have a prefix, considering that each customer in general will receive a /48 prefix, and that each HE will accommodate customers. Consequently, each HE will require n x /48 prefixes.
Edge Routerは接頭語を必要とします、一般に、各顧客が/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.
自動的に支給へのHierarchical Prefix Delegationの種類で必要な接頭語を完全に使用するのが可能であるかもしれない、自動、構成、HEs、その結果、ネットワークセットアップ、操作、および維持費を抑えてください。
The prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows as much summarization as possible at the Edge Router.
加入者リンクに使用される接頭語とDHCP-PDを通して代表として派遣されたEdge Routerで同じくらい可能な同じくらい多くの総括を許す方法で計画されるべきです。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
stateful[RFC3315]と状態がない[RFC3736]DHCPv6を通してDNSなどのホストにとって、興味深い他の情報を提供します。
9.2.3. Routing
9.2.3. ルート設定
If no routers are used on the customer premise, the HE can simply be configured with a default route that points to the Edge Router. If a router is used on the customer premise (RCPE), then the HE could also run an IGP (such as OSPFv3, IS-IS or even RIPng) to the ER. The connected prefixes should be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the HE. For this reason, the static routes must also be redistributed. Prefix summarization should be done at the HE.
ルータが全く顧客前提で使用されないなら、Edge Routerを示すデフォルトルートは単にHEを構成できます。 または、また、ルータが顧客前提(RCPE)で使用されるならHEがIGPを実行するかもしれない、(OSPFv3などのように-、RIPngさえ) ERに。 接続接頭語を再配付するべきです。 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.
Edge RouterはNSPで使用されるIPv6 IGPを実行します: または、OSPFv3、- 接続接頭語を再配付しなければなりません、HEとERの間で使用されるどんなルーティング・プロトコル(ERで使用されるものを除いた)と同様に。
Asadullah, et al. Informational [Page 70] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[70ページ]のRFC4779ISP IPv6展開シナリオ
9.3. IPv6 Multicast
9.3. IPv6マルチキャスト
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.
一般に、また、PLC/BPLの自然が共有されたメディアであると仮定するのにおいてイーサネットのためのIPv6 Multicastに関する問題もここで適切です。 多くのMulticastが予想されるなら、Layer3意識しているRPTを使用すると考える価値があるかもしれません。 その場合、Hierarchical DHCP-PDの1つの付加的な層を考えることができました、ネットワークの展開、操作、およびメインテナンスを容易にするために。
9.4. IPv6 QoS
9.4. IPv6 QoS
The considerations introduced for QoS in Ethernet are also applicable here. PLC/BPL networks support QoS, which basically is the same whether the transport is IPv4 or IPv6. It is necessary to understand that there are specific network characteristics, such as the variability that may be introduced by electrical noise, towards which the PLC/BPL network will automatically self-adapt.
また、イーサネットにおけるQoSのために紹介された問題もここで適切です。 PLC/BPLネットワークはQoSをサポートします。(QoSは輸送がIPv4かIPv6であることにかかわらず基本的に同じです)。 特定のネットワークの特性があるのを理解するのが必要です、PLC/BPLネットワークが自動的に自己に適合する電気雑音によって導入されるかもしれない可変性などのように。
9.5. IPv6 Security Considerations
9.5. IPv6セキュリティ問題
There are no differences in terms of security considerations if compared with the Ethernet case.
イーサネットケースと比べるなら、セキュリティ問題に関して違いが全くありません。
9.6. IPv6 Network Management
9.6. IPv6ネットワークマネージメント
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 Network Managementに関連する問題はセクション7.6でBroadbandイーサネットNetworksのために議論したものと同様であるべきです。 PLCネットワークとインタフェースとMIBモジュールを定義する必要があるかもしれませんが、これが必ずIPv6管理に関連するというわけではないことに注意してください。
10. Gap Analysis
10. ギャップ分析
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 Broadbandネットワークの上で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で言及されるように、変化は、ネイティブのIPv6がケーブルネットワークの上でSPsにおいて、整然としているDOCSIS仕様に配布させられる必要があるでしょう。 CMとCMTSは、ともにユニキャストとマルチキャストトラフィックをIPv6に送るためにIPv6 nativelyをサポートする必要があるでしょう。 これが、IPv6 NeighborディスカバリーがDOCSISケーブルネットワークの上で働くのに必要です。 追加クラシファイアは、QoSを提供するためにCMとCMTSでIPv6トラフィックを分類するためにDOCSIS仕様に追加される必要があります。 これらの問題はDOCSIS3.0[DOCSIS3.0-Reqs]のためにケーブルラボにされた最近の提案で扱われます。
Asadullah, et al. Informational [Page 71] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[71ページ]のRFC4779ISP IPv6展開シナリオ
B. Section 6 stated that current RBE-based IPv4 deployment might not
be the best approach for IPv6, where the addressing space
available gives the SP the opportunity to separate the users on
different subnets. The differences between IPv4 RBE and IPv6 RBE
were highlighted in Section 6. If, however, support and reason
are found for a deployment similar to IPv4 RBE, then the
environment becomes NBMA and the new feature should observe
RFC2491 recommendations.
B.セクション6は、現在のRBEベースのIPv4展開がIPv6に、最も良いアプローチでないかもしれないと述べました。そこでは、利用可能なアドレシングスペースが異なったサブネットでユーザを切り離す機会をSPに与えます。 IPv4 RBEとIPv6 RBEの違いはセクション6で目立ちました。 しかしながら、サポートと理由がIPv4 RBEと同様の展開に関して見つけられるなら、環境はNBMAになります、そして、新機能はRFC2491推薦を観測するべきです。
C. Section 6 discussed the constraints imposed on an LAA-based IPv6
deployment by the fact that it is expected that the subscribers
keep their assigned prefix, regardless of LNS. A deployment
approach was proposed that would maintain the addressing schemes
contiguous and offers prefix summarization opportunities. The
topic could be further investigated for other solutions or
improvements.
C.セクション6は加入者が彼らの割り当てられた接頭語を保つと予想されるという事実によってLAAベースのIPv6展開に課された規制について論じました、LNSにかかわらず。 アドレシング体系を隣接に維持して、接頭語総括の機会を提供する展開アプローチは、提案されました。 他のソリューションか改良のためにさらに話題を調査できました。
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.
E. セクション8と関連して、関心はWLANリンクの上にIPv6マルチキャストを実行するのに関連していた状態で高められました。 高い合図する損失比を持っているWLANリンクの上にどんなLayer3プロトコルも実行するとき、潜在的に、これらは同じ種類の問題です。 設定が適切に調整されないとき、基づくマルチキャストである、あるフレームは下げられます。 例えば、この振舞いはIGMPホスト会員資格レポートと同様です、高い合図する損失比と高い干渉とのWLANリンクですると。 この問題は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]を実装することができます。 メカニズムは、ユーザー管理のこの局面を実装するために定義されるべきです。
Asadullah, et al. Informational [Page 72] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[72ページ]のRFC4779ISP IPv6展開シナリオ
G. Tunnels are an effective way to avoid deployment dependencies on
the IPv6 support on platforms that are out of the SP control
(GWRs or CPEs) or over technologies that did not standardize the
IPv6 support yet (cable). They can be used in the following
ways:
G.トンネルはSPコントロール(GWRsかCPEs)から脱しているプラットホームの上、または、IPv6サポートにもかかわらず、(ケーブル)を標準化しなかった技術の上のIPv6サポートのときに展開の依存を避ける効果的な方法です。 以下の方法でそれらを使用できます:
i. Tunnels directly to the CPE or GWR with public or private
IPv4 addresses.
i。 直接公共の、または、個人的なIPv4アドレスがあるCPEかGWRへのTunnels。
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アドレスをもっているホストへのTunnels。 正確なそうすることができるトンネリングメカニズムの上では、/が最後のマイルアクセスに使用されるべきであるという推薦は、さらに調査されるのが必要であり、IETF Softwire作業部会によって記述されるべきです。
H. Through its larger address space, IPv6 allows SPs to assign
fixed, globally routable prefixes to the links connecting each
subscriber.
H. より大きいアドレス空間を通して、IPv6はSPsに修理されて、グローバルに発送可能な接頭語を各加入者に接するリンクに割り当てさせます。
This approach changes the provisioning methodologies that were
used for IPv4. Static configuration of the IPv6 addresses for
all these links on the Edge Routers or Access Routers might not
be a scalable option. New provisioning mechanisms or features
might need to be developed in order to deal with this issue, such
as automatic mapping of VLAN IDs/PVCs (or other customer-specific
information) to IPv6 prefixes.
このアプローチはIPv4に使用された食糧を供給する方法論を変えます。 Edge RoutersかAccess Routersの上のこれらのすべてのリンクへのIPv6アドレスの静的な構成はスケーラブルなオプションでないかもしれません。 新しい食糧を供給するメカニズムか特徴が、この問題に対処するために開発される必要があるかもしれません、IPv6接頭語へのVLAN ID/PVCs(または、他の顧客特定情報)の自動マッピングなどのように。
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.の新しい展開モデルは個々のVLANsが各加入者に捧げられないNAPのLayer2部分に現れています。 このアプローチで、Layer2スイッチはさらに次に、4096人のユーザに集められます。 MAC Forced Forwarding[RFC4562]はそのような実現に関する例です。(そこでは、フレームを進めるのによる環境がアドレスをSourceとDestination 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].
i。 国がない自動構成と関連して動作するService Selection&Authentication(NSSA)メカニズムをネットワークでつないでください。 例として、RS[RFC4191]のホストはISP好みなどのNSSAの関連情報(パスワード、またはプロフィールID)を送ることができます。
Asadullah, et al. Informational [Page 73] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[73ページ]のRFC4779ISP IPv6展開シナリオ
ii. Providing additional information in Router Advertisements to
help access nodes with prefix selection in multi-ISP/
multi-homed environments.
ii。 接頭語選択がマルチISP/にある状態でアクセスノードを助けるためにRouter Advertisementsの追加情報を提供する、マルチ、家へ帰り、環境。
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展開の操作上の局面を改良するまで及びます。
11. Security Considerations
11. セキュリティ問題
Please refer to the individual "IPv6 Security Considerations" technology sections for details.
詳細について個々の「IPv6セキュリティ問題」技術部を参照してください。
12. Acknowledgements
12. 承認
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].
彼らの貴重なコメントについてブライアンCarpenter、パトリックGrossetete、Toerlessエッケルト、Madhu Sudan、シャノン・マクファーランド、ブノワLourdelet、およびフレッド・ベイカーに感謝申し上げます。 作者はMicklesの仕事で提供された構造と情報指導を承諾したがっています、他、「ISPネットワークのための変遷シナリオ」[ISP-CASES]で。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[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.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6",
RFC 2080, January 1997.
[RFC2080] マルキンとG.とR.Minnear、「IPv6"、RFC2080、1997年1月のためのRIPng。」
[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.スティーブンズ、「AAL5"、RFC2364、1998年7月の間のppp。」
[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)のための隣人発見」、RFC2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2462] トムソンとS.とT.Narten、「IPv6の国がないアドレス自動構成」、RFC2462、1998年12月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling
in IPv6 Specification", RFC 2473, December 1998.
[RFC2473] コンタとA.とS.デアリング、「IPv6仕様による一般的なパケットトンネリング」、RFC2473、1998年12月。
Asadullah, et al. Informational [Page 74] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[74ページ]のRFC4779ISP IPv6展開シナリオ
[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.、エバーツ、J.、個人閲覧室、D.、シモン、D.、およびR.ウィーラー、「イーサネットの上にpppを伝えるための方法(PPPoE)」、RFC2516(1999年2月)。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6
over IPv4 Domains without Explicit Tunnels",
RFC 2529, March 1999.
[RFC2529] 大工とB.とC.ユング、「明白なTunnelsのいないIPv4ドメインの上のIPv6のトランスミッション」、RFC2529、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.はあしらいます、「層Twoはプロトコル"L2TP"にトンネルを堀っ」て、RFC2661、1999年8月。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for
IPv6", RFC 2740, December 1999.
[RFC2740] ColtunとR.とファーガソン、D.とJ.Moy、「IPv6"、RFC2740、1999年12月のためのOSPF。」
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)",
RFC 2784, March 2000.
2000年3月の[RFC2784]ファリナッチとD.と李とT.とハンクスとS.とマイヤー、D.とP.Traina、「一般ルーティングのカプセル化(GRE)」RFC2784。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6",
RFC 3041, January 2001.
[RFC3041] NartenとT.とR.Draves、「IPv6"での国がないアドレス自動構成のためのプライバシー拡大、RFC3041、2001年1月。」
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento,
"IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053] ジュランドとA.とファザーノとP.とグァルディーニ、I.とレントのD.「IPv6トンネルのブローカー」、RFC3053、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6
Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] 大工とB.とK.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、RFC3056、2001年2月。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6
Address Allocations to Sites", RFC 3177,
September 2001.
[RFC3177] IABとIESG、「サイトへのIPv6アドレス配分のIAB/IESG推薦」、RFC3177、2001年9月。
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in
233/8", BCP 53, RFC 3180, September 2001.
[RFC3180] マイヤーとD.とP.Lothberg、「233/8インチ、BCP53、RFCに3180、2001年9月を記述するGLOP。」
[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.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source
Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]フェナーとB.とD.マイヤー、「マルチキャストソース発見プロトコル(MSDP)」、RFC3618 2003年10月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.とP.Savola、「Multihomedのためにネットワークをフィルターにかけるイングレス」BCP84、2004年3月のRFC3704。
Asadullah, et al. Informational [Page 75] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[75ページ]のRFC4779ISP IPv6展開シナリオ
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration
Protocol (DHCP) Service for IPv6", RFC 3736,
April 2004.
[RFC3736] Droms、R.「(DHCP)がIPv6"、RFC3736年のために修理する国がないダイナミックなホスト構成プロトコル、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] der Pol、「UnmanagedネットワークのためのIPv6変遷メカニズムの評価」をHuitema、C.、Austein、R.、Satapati、S.、およびR.はバンに積みます、RFC3904、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)」、RFC3931、3月2005日
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet
Network Addresses", RFC 4001, February 2005.
2005年2月の[RFC4001]ダニエルとM.とハーバーマンとB.とRouthier、S.とJ.Schoenwaelder、「インターネットネットワーク・アドレスのための原文のコンベンション」RFC4001。
[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.、Baudot、A.、およびP.Savola、「ISPネットワークにIPv6を取り入れるためのシナリオと分析」(RFC4029)は2005を行進させます。
[RFC4191] Draves, R. and D. Thaler, "Default Router
Preferences and More-Specific Routes", RFC 4191,
November 2005.
[RFC4191]Draves、研究開発ターレル、「デフォルトルータ好みの、そして、より特定のルート」、RFC4191、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ホストとルータのための基本的な変遷メカニズム」、RFC4213、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)」、RFC4214、2005年10月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP
through Network Address Translations (NATs)",
RFC 4380, February 2006.
[RFC4380]Huitema、C.、「船食虫:」 「ネットワークアドレス変換(NATs)でUDPの上でIPv6にトンネルを堀る」RFC4380、2006年2月。
13.2. Informative References
13.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] 「IPv4雲の向こう側にIPv6諸島をBGPにつなげ」て、De Clercq、J.、オームス、D.、プレヴォー、S.、およびF.Le Faucheurは進行中(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の国がない自動構成の展開」、Telecommunications、ConTEL2005(2005年6月)の上の第8国際コンファレンス。
Asadullah, et al. Informational [Page 76] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[76ページ]のRFC4779ISP IPv6展開シナリオ
[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-オッシ]CableLabs、Cl、「DOCSIS3.0オッシSpecification(CM SP-OSSIv3.0-D02-060504)」、5月2006日
[DOCSIS3.0-Reqs] Droms, R., Durand, A., Kharbanda, D., and J-F.
Mule, "DOCSIS 3.0 Requirements for IPv6 Support",
Work in Progress, March 2006.
[DOCSIS3.0-Reqs。]Droms、R.、ジュランド、A.、Kharbanda、D.、およびJ-F ラバ、「IPv6のための要件が支持するDOCSIS3.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] 殻、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 Medium Access Control(MAC)とPhysical Layer(PHY)仕様、Amendment6: 2004年7月の「媒体アクセス制御(MAC)セキュリティ増進。」
[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規格:」 2001年6月に「ポートはNetwork Access Control、IEEE Std 802.1X-2001を基礎づけました」。
[IPv6-Multicast] Savola, P., "IPv6 Multicast Deployment Issues",
Work in Progress, April 2004.
P.、「IPv6マルチキャスト展開問題」という[IPv6-マルチキャスト]Savolaは進歩、2004年4月に働いています。
[IPv6-Security] Convery, S. and D. Miller, "IPv6 and IPv4 Threat
Comparison and Best-Practice Evaluation",
March 2004.
[IPv6-セキュリティ]ConveryとS.とD.ミラー、「IPv6、IPv4脅威比較、および最も良い習慣評価」、2004年3月。
[ISISv6] Hopps, C., "Routing IPv6 with IS-IS", Work
in Progress, October 2005.
[ISISv6]ホップス、C.、「IPv6を発送する、-、」、10月2005、進行中で、働いてください。
[ISP-CASES] Mickles, C., "Transition Scenarios for ISP
Networks", Work in Progress, September 2002.
「ISPネットワークのための変遷シナリオ」という[ISPケース]Mickles、C.は進歩、2002年9月に働いています。
[Protocol41] Palet, J., Olvera, C., and D. Fernandez,
"Forwarding Protocol 41 in NAT Boxes", Work
in Progress, October 2003.
[Protocol41] 殻とJ.とオルベラ、C.と「NAT箱の中にプロトコル41を進め」て、仕事進行中のD.フェルナンデス、2003年10月。
[RF-Interface] CableLabs, CL., "DOCSIS 2.0(CM-SP-RFIv2.0-I10-
051209)", December 2005.
[rfインタフェース] CableLabs、Cl、「DOCSIS2.0(CM SP-RFIv2.0-I10-051209)」、12月2005日
[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強制しました」。 「イーサネットアクセスネットワークにおける加入者分離のための方法」、RFC4562、2006年6月。
Asadullah, et al. Informational [Page 77] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[77ページ]のRFC4779ISP IPv6展開シナリオ
[Softwire] Dawkins, S., Ed., "Softwire Problem Statement",
Work in Progress, May 2006.
[Softwire] ダウキンズ、S.、エド、「Softwire問題声明」(処理中の作業)は2006にそうするかもしれません。
[v6tc] Palet, J., Nielsent, K., Parent, F., Durand, A.,
Suryanarayanan, R., and P. Savola, "Goals for
Tunneling Configuration", Work in Progress,
August 2005.
[v6tc]殻、J.、Nielsent、K.、親、F.、ジュランド、A.、Suryanarayanan、R.、およびP.Savola、「トンネリング構成の目標」が進行中(2005年8月)で働いています。
Asadullah, et al. Informational [Page 78] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[78ページ]のRFC4779ISP IPv6展開シナリオ
Authors' Addresses
作者のアドレス
Salman Asadullah Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
西タスマン・DriveサルマンAsadullahシスコシステムズ170カリフォルニア95134サンノゼ(米国)
Phone: 408 526 8982 EMail: sasad@cisco.com
以下に電話をしてください。 8982年の408 526メール: sasad@cisco.com
Adeel Ahmed Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA
Adeelアフマドシスコシステムズ2200の東社長のジョージ・ブッシュ・Turnpikeテキサス75082リチャードソン(米国)
Phone: 469 255 4122 EMail: adahmed@cisco.com
以下に電話をしてください。 4122年の469 255メール: adahmed@cisco.com
Ciprian Popoviciu Cisco Systems 7025-6 Kit Creek Road Research Triangle Park, NC 27709 USA
Ciprian Popoviciuシスコシステムズ7025-6キットクリーク道路リサーチトライアングル公園、NC27709米国
Phone: 919 392 3723 EMail: cpopovic@cisco.com
以下に電話をしてください。 3723年の919 392メール: cpopovic@cisco.com
Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland
ペッカSavola CSC--科学計算株式会社エスポーフィンランド
EMail: psavola@funet.fi
メール: psavola@funet.fi
Asadullah, et al. Informational [Page 79] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[79ページ]のRFC4779ISP IPv6展開シナリオ
Jordi Palet Martinez Consulintel San Jose Artesano, 1 Alcobendas, Madrid E-28108 Spain
ジョルディ・殻マルチネス・ConsulintelサンノゼArtesano、1アルコベンダス、マドリードE-28108スペイン
Phone: +34 91 151 81 99 EMail: jordi.palet@consulintel.es
以下に電話をしてください。 +34 91 151 81 99はメールされます: jordi.palet@consulintel.es
Asadullah, et al. Informational [Page 80] RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Asadullah、他 掲示板2007年1月の情報[80ページ]のRFC4779ISP IPv6展開シナリオ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Asadullah, et al. Informational [Page 81]
Asadullah、他 情報[81ページ]
一覧
スポンサーリンク
