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
Network Working Group S. Asadullah
Request for Comments: 4779 A. Ahmed
Category: Informational C. Popoviciu
Cisco Systems
P. Savola
CSC/FUNET
J. Palet
Consulintel
January 2007
ISP IPv6 Deployment Scenarios in Broadband Access Networks
宽带接入网中的ISP-IPv6部署方案
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document provides a detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP) Broadband (BB) networks in coexistence with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies that are currently deployed, and discussed in this document. The emerging Broadband Power Line Communications (PLC/BPL) access technology is also discussed for completeness. In this document we will discuss main components of IPv6 BB networks, their differences from IPv4 BB networks, and how IPv6 is deployed and integrated in each of these networks using tunneling mechanisms and native IPv6.
本文档详细描述了当前服务提供商（SP）宽带（BB）网络中与已部署IPv4服务共存的IPv6部署和集成方法及场景。Cable/HFC、BB以太网、xDSL和WLAN是当前部署的主要BB技术，本文档对此进行了讨论。为了完整性，还讨论了新兴的宽带电力线通信（PLC/BPL）接入技术。在本文档中，我们将讨论IPv6 BB网络的主要组件，它们与IPv4 BB网络的区别，以及如何使用隧道机制和本机IPv6在这些网络中部署和集成IPv6。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Common Terminology . . . . . . . . . . . . . . . . . . . . . . 5
3. Core/Backbone Network . . . . . . . . . . . . . . . . . . . . 5
3.1. Layer 2 Access Provider Network . . . . . . . . . . . . . 5
3.2. Layer 3 Access Provider Network . . . . . . . . . . . . . 6
4. Tunneling Overview . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Access over Tunnels - Customers with Public IPv4
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Access over Tunnels - Customers with Private IPv4
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Transition a Portion of the IPv4 Infrastructure . . . . . 8
5. Broadband Cable Networks . . . . . . . . . . . . . . . . . . . 9
5.1. Broadband Cable Network Elements . . . . . . . . . . . . . 9
5.2. Deploying IPv6 in Cable Networks . . . . . . . . . . . . . 10
5.2.1. Deploying IPv6 in a Bridged CMTS Network . . . . . . . 12
5.2.2. Deploying IPv6 in a Routed CMTS Network . . . . . . . 14
5.2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . 23
5.2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.5. IPv6 Security Considerations . . . . . . . . . . . . . 24
5.2.6. IPv6 Network Management . . . . . . . . . . . . . . . 25
6. Broadband DSL Networks . . . . . . . . . . . . . . . . . . . . 26
6.1. DSL Network Elements . . . . . . . . . . . . . . . . . . . 26
6.2. Deploying IPv6 in IPv4 DSL Networks . . . . . . . . . . . 28
6.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 29
6.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 30
6.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 33
6.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 36
6.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 38
6.3.1. ASM-Based Deployments . . . . . . . . . . . . . . . . 39
6.3.2. SSM-Based Deployments . . . . . . . . . . . . . . . . 39
6.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 41
6.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 42
7. Broadband Ethernet Networks . . . . . . . . . . . . . . . . . 42
7.1. Ethernet Access Network Elements . . . . . . . . . . . . . 42
7.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks . . . . 43
7.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 44
7.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 46
7.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 48
7.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 50
7.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 52
7.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 54
7.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 55
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Common Terminology . . . . . . . . . . . . . . . . . . . . . . 5
3. Core/Backbone Network . . . . . . . . . . . . . . . . . . . . 5
3.1. Layer 2 Access Provider Network . . . . . . . . . . . . . 5
3.2. Layer 3 Access Provider Network . . . . . . . . . . . . . 6
4. Tunneling Overview . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Access over Tunnels - Customers with Public IPv4
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Access over Tunnels - Customers with Private IPv4
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Transition a Portion of the IPv4 Infrastructure . . . . . 8
5. Broadband Cable Networks . . . . . . . . . . . . . . . . . . . 9
5.1. Broadband Cable Network Elements . . . . . . . . . . . . . 9
5.2. Deploying IPv6 in Cable Networks . . . . . . . . . . . . . 10
5.2.1. Deploying IPv6 in a Bridged CMTS Network . . . . . . . 12
5.2.2. Deploying IPv6 in a Routed CMTS Network . . . . . . . 14
5.2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . 23
5.2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.5. IPv6 Security Considerations . . . . . . . . . . . . . 24
5.2.6. IPv6 Network Management . . . . . . . . . . . . . . . 25
6. Broadband DSL Networks . . . . . . . . . . . . . . . . . . . . 26
6.1. DSL Network Elements . . . . . . . . . . . . . . . . . . . 26
6.2. Deploying IPv6 in IPv4 DSL Networks . . . . . . . . . . . 28
6.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 29
6.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 30
6.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 33
6.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 36
6.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 38
6.3.1. ASM-Based Deployments . . . . . . . . . . . . . . . . 39
6.3.2. SSM-Based Deployments . . . . . . . . . . . . . . . . 39
6.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 41
6.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 42
7. Broadband Ethernet Networks . . . . . . . . . . . . . . . . . 42
7.1. Ethernet Access Network Elements . . . . . . . . . . . . . 42
7.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks . . . . 43
7.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 44
7.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 46
7.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 48
7.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 50
7.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 52
7.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 54
7.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 55
8. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.1. WLAN Deployment Scenarios . . . . . . . . . . . . . . . . 55
8.1.1. Layer 2 NAP with Layer 3 termination at NSP Edge
Router . . . . . . . . . . . . . . . . . . . . . . . . 56
8.1.2. Layer 3 Aware NAP with Layer 3 Termination at
Access Router . . . . . . . . . . . . . . . . . . . . 59
8.1.3. PPP-Based Model . . . . . . . . . . . . . . . . . . . 61
8.2. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 63
8.3. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.4. IPv6 Security Considerations . . . . . . . . . . . . . . . 65
8.5. IPv6 Network Management . . . . . . . . . . . . . . . . . 67
9. Broadband Power Line Communications (PLC) . . . . . . . . . . 67
9.1. PLC/BPL Access Network Elements . . . . . . . . . . . . . 68
9.2. Deploying IPv6 in IPv4 PLC/BPL . . . . . . . . . . . . . . 69
9.2.1. IPv6 Related Infrastructure Changes . . . . . . . . . 69
9.2.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 69
9.2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 70
9.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 71
9.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 71
9.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 71
10. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 71
11. Security Considerations . . . . . . . . . . . . . . . . . . . 74
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 74
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74
13.1. Normative References . . . . . . . . . . . . . . . . . . . 74
13.2. Informative References . . . . . . . . . . . . . . . . . . 76
8. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.1. WLAN Deployment Scenarios . . . . . . . . . . . . . . . . 55
8.1.1. Layer 2 NAP with Layer 3 termination at NSP Edge
Router . . . . . . . . . . . . . . . . . . . . . . . . 56
8.1.2. Layer 3 Aware NAP with Layer 3 Termination at
Access Router . . . . . . . . . . . . . . . . . . . . 59
8.1.3. PPP-Based Model . . . . . . . . . . . . . . . . . . . 61
8.2. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 63
8.3. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.4. IPv6 Security Considerations . . . . . . . . . . . . . . . 65
8.5. IPv6 Network Management . . . . . . . . . . . . . . . . . 67
9. Broadband Power Line Communications (PLC) . . . . . . . . . . 67
9.1. PLC/BPL Access Network Elements . . . . . . . . . . . . . 68
9.2. Deploying IPv6 in IPv4 PLC/BPL . . . . . . . . . . . . . . 69
9.2.1. IPv6 Related Infrastructure Changes . . . . . . . . . 69
9.2.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 69
9.2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 70
9.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 71
9.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 71
9.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 71
10. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 71
11. Security Considerations . . . . . . . . . . . . . . . . . . . 74
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 74
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74
13.1. Normative References . . . . . . . . . . . . . . . . . . . 74
13.2. Informative References . . . . . . . . . . . . . . . . . . 76
This document presents the options available in deploying IPv6 services in the access portion of a BB Service Provider (SP) network - namely Cable/HFC, BB Ethernet, xDSL, WLAN, and PLC/BPL.
本文档介绍了在BB服务提供商（SP）网络的接入部分部署IPv6服务的可用选项，即电缆/HFC、BB以太网、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.
本文档还简要讨论了提供商网络的其他元素。它分别为上述每种BB技术提供了不同的可行IPv6部署和集成技术以及模型。示例列表并非详尽无遗，但它试图具有代表性。
This document analyzes how all the important components of current IPv4-based Cable/HFC, BB Ethernet, xDSL, WLAN, and PLC/BPL networks will behave when IPv6 is integrated and deployed.
本文档分析了当前基于IPv4的电缆/HFC、BB以太网、xDSL、WLAN和PLC/BPL网络的所有重要组件在集成和部署IPv6时的行为。
The following important pieces are discussed:
讨论了以下重要内容：
A. Available tunneling options
A.可用的隧道方案
B. Devices that would have to be upgraded to support IPv6
B.必须升级以支持IPv6的设备
C. Available IPv6 address assignment techniques and their use
C.可用的IPv6地址分配技术及其使用
D. Possible IPv6 Routing options and their use
D.可能的IPv6路由选择及其使用
E. IPv6 unicast and multicast packet transmission
E.IPv6单播和多播数据包传输
F. Required IPv6 Quality of Service (QoS) parameters
F.所需的IPv6服务质量（QoS）参数
G. Required IPv6 Security parameters
G.所需的IPv6安全参数
H. Required IPv6 Network Management parameters
H.所需的IPv6网络管理参数
It is important to note that the addressing rules provided throughout this document represent an example that follows the current assignment policies and recommendations of the registries. However, they can be adapted to the network and business model needs of the ISPs.
需要注意的是，本文件中提供的寻址规则是遵循登记处现行转让政策和建议的一个例子。但是，它们可以适应ISP的网络和业务模式需求。
The scope of the document is to advise on the ways of upgrading an existing infrastructure to support IPv6 services. The recommendation to upgrade a device to dual stack does not stop an SP from adding a new device to its network to perform the necessary IPv6 functions discussed. The costs involved with such an approach could be offset by lower impact on the existing IPv4 services.
该文件的范围是就如何升级现有基础设施以支持IPv6服务提供建议。将设备升级到双堆栈的建议不会阻止SP向其网络添加新设备以执行所讨论的必要IPv6功能。这种方法所涉及的成本可以通过降低对现有IPv4服务的影响来抵消。
BB: Broadband
宽带
CPE: Customer Premise Equipment
CPE：客户现场设备
GWR: Gateway Router
网关路由器
ISP: Internet Service Provider
互联网服务提供商
NAP: Network Access Provider
网络访问提供商
NSP: Network Service Provider
网络服务提供商
QoS: Quality of Service
QoS：服务质量
SP: Service Provider
SP：服务提供商
This section intends to briefly discuss some important elements of a provider network tied to the deployment of IPv6. A more detailed description of the core network is provided in other documents [RFC4029].
本节旨在简要讨论与IPv6部署相关的提供商网络的一些重要元素。其他文件[RFC4029]中提供了对核心网络的更详细描述。
There are two types of networks identified in the Broadband deployments:
宽带部署中确定了两种类型的网络：
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.
接入提供商网络：该网络提供宽带接入并聚合用户。用户流量在第2层或第3层移交给服务提供商。
B. Service Provider Network: This network provides Intranet and Internet IP connectivity for the subscribers.
B.服务提供商网络：该网络为用户提供内部网和互联网IP连接。
The Service Provider network structure beyond the Edge Routers that interface with the Access provider is beyond the scope of this document.
与接入提供商接口的边缘路由器之外的服务提供商网络结构超出了本文档的范围。
The Access Provider can deploy a Layer 2 network and perform no routing of the subscriber traffic to the SP. The devices that support each specific access technology are aggregated into a highly redundant, resilient, and scalable Layer 2 core. The network core can involve various technologies such as Ethernet, Asynchronous Transfer Mode (ATM), etc. The Service Provider Edge Router connects to the Access Provider core.
接入提供商可以部署第2层网络，并且不执行到SP的订户流量路由。支持每种特定接入技术的设备聚合到一个高度冗余、弹性和可扩展的第2层核心中。网络核心可以涉及各种技术，如以太网、异步传输模式（ATM）等。服务提供商边缘路由器连接到接入提供商核心。
This type of network may be transparent to the Layer 3 protocol. Some possible changes may come with the intent of supporting IPv6 provisioning mechanisms, as well as filtering and monitoring IPv6 traffic based on Layer 2 information such as IPv6 Ether Type Protocol ID (0x86DD) or IPv6 multicast specific Media Access Control (MAC) addresses (33:33:xx:xx:xx:xx).
这种类型的网络可能对第3层协议是透明的。一些可能的更改可能是为了支持IPv6配置机制，以及基于第2层信息（如IPv6以太类型协议ID（0x86DD）或IPv6多播特定媒体访问控制（MAC）地址（33:33:xx:xx:xx:xx））过滤和监视IPv6流量。
The Access Provider can choose to terminate the Layer 2 domain and route the IP traffic to the Service Provider network. Access Routers are used to aggregate the subscriber traffic and route it over a Layer 3 core to the SP Edge Routers. In this case, the impact of the IPv6 deployment is significant.
接入提供商可以选择终止第2层域，并将IP流量路由到服务提供商网络。访问路由器用于聚合订户流量，并通过第3层核心将其路由到SP边缘路由器。在这种情况下，IPv6部署的影响是巨大的。
The case studies in this document discuss only the relevant network elements of such a network: Customer Premise Equipment, Access Router, and Edge Router. In real networks, the link between the Access Router and the Edge Router involves other routers that are part of the aggregation and the core layer of the Access Provider network.
本文档中的案例研究仅讨论此类网络的相关网络元素：客户场所设备、接入路由器和边缘路由器。在实际网络中，接入路由器和边缘路由器之间的链路涉及作为接入提供商网络聚合和核心层一部分的其他路由器。
The Access Provider can forward the IPv6 traffic through its Layer 3 core in three possible ways:
接入提供商可以通过三种可能的方式通过其第3层核心转发IPv6流量：
A. IPv6 Tunneling: As a temporary solution, the Access Provider can choose to use a tunneling mechanism to forward the subscriber IPv6 traffic to the Service Provider Edge Router. This approach has the least impact on the Access Provider network; however, as the number of users increase and the amount of IPv6 traffic grows, the ISP will have to evolve to one of the scenarios listed below.
A.IPv6隧道：作为临时解决方案，接入提供商可以选择使用隧道机制将订户IPv6流量转发到服务提供商边缘路由器。这种方法对接入提供商网络的影响最小；然而，随着用户数量的增加和IPv6通信量的增加，ISP将不得不发展到下面列出的场景之一。
B. Native IPv6 Deployment: The Access Provider routers are upgraded to support IPv6 and can become dual stack. In a dual-stack network, an IPv6 Interior Gateway Protocol (IGP), such as OSPFv3 [RFC2740] or IS-IS [ISISv6], is enabled. RFC 4029 [RFC4029] discusses the IGP selection options with their benefits and drawbacks.
B.本机IPv6部署：接入提供商路由器升级为支持IPv6，可以成为双栈。在双栈网络中，启用IPv6内部网关协议（IGP），如OSPFv3[RFC2740]或IS-IS[ISISv6]。RFC 4029[RFC4029]讨论了IGP选择选项及其优缺点。
C. MPLS 6PE Deployment [6PE]: If the Access Provider is running MPLS in its IPv4 core, it could use 6PE to forward IPv6 traffic over it. In this case, only a subset of routers close to the edge of the network need to be IPv6 aware. With this approach, BGP becomes important in order to support 6PE.
C.MPLS 6PE部署[6PE]：如果访问提供商在其IPv4核心中运行MPLS，则可以使用6PE转发其上的IPv6流量。在这种情况下，只有靠近网络边缘的路由器子集需要知道IPv6。通过这种方法，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方法的优点是对接入提供商网络的影响最小。需要升级和升级的设备更少
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]中讨论了更详细的核心网络部署建议。本文档的其余部分将不讨论接入提供商网络核心中IPv6流量的处理。
If SPs are not able to deploy native IPv6, they might use tunneling-based transition mechanisms to start an IPv6 service offering, and move to native IPv6 deployment at a later time.
如果SP无法部署本机IPv6，他们可能会使用基于隧道的转换机制启动IPv6服务，并在稍后转移到本机IPv6部署。
Several tunneling mechanisms were developed specifically to transport IPv6 over existing IPv4 infrastructures. Several of them have been standardized and their use depends on the existing SP IPv4 network and the structure of the IPv6 service. The requirements for the most appropriate mechanisms are described in [v6tc] with more updates to follow. Deploying IPv6 using tunneling techniques can imply as little changes to the network as upgrading software on tunnel end points. A Service Provider could use tunneling to deploy IPv6 in the following scenarios:
有几种隧道机制专门用于在现有IPv4基础设施上传输IPv6。其中一些已经标准化，它们的使用取决于现有的SP IPv4网络和IPv6服务的结构。[v6tc]中描述了对最合适机制的要求，并提供了更多更新。使用隧道技术部署IPv6对网络的影响与在隧道端点升级软件一样小。在以下情况下，服务提供商可以使用隧道来部署IPv6：
If the customer is a residential user, it can initiate the tunnel
directly from the IPv6 capable host to a tunnel termination router
located in the NAP or ISP network. The tunnel type used should be
decided by the SP, but it should take into consideration its
availability on commonly used software running on the host machine.
Of the many tunneling mechanisms developed, such as IPv6 Tunnel
Broker [RFC3053], Connection of IPv6 Domains via IPv4 Clouds
[RFC3056], Generic Packet Tunneling in IPv6 [RFC2473], ISATAP
[RFC4214], Basic Transition Mechanisms for IPv6 Hosts and Routers
[RFC4213], and Transmission of IPv6 over IPv4 Domains without
Explicit Tunnels [RFC2529], some are more popular than the others.
At the time of writing this document, the IETF Softwire Working Group
was tasked with standardizing a single tunneling protocol [Softwire]
for this application.
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.
If the end customer has a GWR installed, then it could be used to originate the tunnel, thus offering native IPv6 access to multiple hosts on the customer network. In this case, the GWR would need to be upgraded to dual stack in order to support IPv6. The GWR can be owned by the customer or by the SP.
如果最终客户安装了GWR，那么它可以用来发起隧道，从而提供对客户网络上多个主机的本机IPv6访问。在这种情况下，GWR需要升级到双栈以支持IPv6。GWR可归客户或SP所有。
If the end customer receives a private IPv4 address and needs to initiate a tunnel through Network Address Translation (NAT), techniques like 6to4 may not work since they rely on public IPv4 address. In this case, unless the existing GWRs support protocol-41- forwarding [Protocol41], the end user might have to use tunnels that can operate through NATs (such as Teredo [RFC4380]). Most GWRs support protocol-41-forwarding, which means that hosts can initiate the tunnels - in which case the GWR is not affected by the IPv6 service.
如果终端客户收到一个专用IPv4地址，并且需要通过网络地址转换（NAT）启动隧道，那么像6to4这样的技术可能无法工作，因为它们依赖于公共IPv4地址。在这种情况下，除非现有GWRs支持协议-41-转发[Protocol41]，否则最终用户可能必须使用可通过NAT运行的隧道（例如Teredo[RFC4380]）。大多数GWR支持协议-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 IPsec会话在IPv4上启动IPv6隧道将为IPv6流量提供一定级别的安全性。
Tunnels can be used to transport the IPv6 traffic across a defined segment of the network. As an example, the customer might connect natively to the Network Access Provider, where a tunnel is used to transit the traffic over IPv4 to the ISP. In this case, the tunnel choice depends on its capabilities (for example, whether or not it supports multicast), routing protocols used (there are several types that can transport Layer 2 messages, such as GRE [RFC2784], L2TPv3 [RFC3931], or pseudowire), manageability, and scalability (dynamic versus static tunnels).
隧道可用于跨定义的网络段传输IPv6流量。例如，客户可能以本机方式连接到网络访问提供商，其中使用隧道将IPv4上的流量传输到ISP。在这种情况下，隧道的选择取决于其功能（例如，它是否支持多播）、使用的路由协议（有几种类型可以传输第2层消息，如GRE[RFC2784]、L2TPv3[RFC3931]或伪线）、可管理性和可伸缩性（动态隧道与静态隧道）。
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.
此场景意味着网络的接入部分已升级以支持双堆栈，因此与前两种场景相比，此场景中通过隧道提供的节省非常小。根据需要服务的站点数量，并考虑到管理隧道所需的费用（在这种情况下，一些隧道是静态的，而另一些是动态的[DynamicTunnel]），SPs可能会发现本地方法值得额外投资。
In all the scenarios listed above, the tunnel selection process should consider the IPv6 multicast forwarding capabilities if such service is planned. As an example, 6to4 tunnels do not support IPv6 multicast traffic.
在上面列出的所有场景中，如果选择这样的服务，隧道选择过程应该考虑IPv6组播转发能力。例如，6to4隧道不支持IPv6多播通信。
The operation, capabilities, and deployment of various tunnel types have been discussed extensively in the documents referenced earlier as well as in [RFC4213] and [RFC3904]. Details of a tunnel-based deployment are offered in the next section of this document, which discusses the case of Cable Access, where the current Data Over Cable Service Interface Specification (DOCSIS 2.0) [RF-Interface] and prior specifications do not provide support for native IPv6 access. Although Sections 6, 7, 8, and 9 focus on a native IPv6 deployments over DSL, Fiber to the Home (FTTH), wireless, and PLC/BPL and because this approach is fully supported today, tunnel-based solutions are also possible in these cases based on the guidelines of this section and some of the recommendations provided in Section 5.
先前参考的文件以及[RFC4213]和[RFC3904]对各种隧道类型的操作、能力和部署进行了广泛讨论。本文档下一节提供了基于隧道的部署的详细信息，其中讨论了电缆访问的情况，当前的电缆数据服务接口规范（DOCSIS 2.0）[RF接口]和以前的规范不支持本机IPv6访问。尽管第6、7、8和9节重点介绍了通过DSL、光纤到户（FTTH）、无线和PLC/BPL的本机IPv6部署，并且由于目前完全支持这种方法，根据本节的指导原则和第5节中提供的一些建议，在这些情况下也可以使用基于隧道的解决方案。
This section describes the infrastructure that exists today in cable networks providing BB services to the home. It also describes IPv6 deployment options in these cable networks.
本节介绍目前为家庭提供BB服务的有线网络中存在的基础设施。它还描述了这些有线网络中的IPv6部署选项。
DOCSIS standardizes and documents the operation of data over cable networks. DOCSIS 2.0 and prior specifications have limitations that do not allow for a smooth implementation of native IPv6 transport. Some of these limitations are discussed in this section. For this reason, the IPv6 deployment scenarios discussed in this section for the existing cable networks are tunnel based. The tunneling examples presented here could also be applied to the other BB technologies described in Sections 6, 7, 8, and 9.
DOCSIS标准化并记录有线网络上的数据操作。DOCSIS 2.0和以前的规范有一些限制，不允许顺利实现本机IPv6传输。本节将讨论其中一些限制。因此，本节讨论的现有有线网络的IPv6部署场景是基于隧道的。此处给出的隧道示例也可应用于第6、7、8和9节中描述的其他BB技术。
Broadband cable networks are capable of transporting IP traffic to/ from users to provide high speed Internet access and Voice over IP (VoIP) services. The mechanism for transporting IP traffic over cable networks is outlined in the DOCSIS specification [RF-Interface].
宽带电缆网络能够向/从用户传输IP流量，以提供高速互联网接入和IP语音（VoIP）服务。DOCSIS规范[射频接口]概述了通过电缆网络传输IP流量的机制。
Here are some of the key elements of a cable network:
以下是有线网络的一些关键要素：
Cable (HFC) Plant: Hybrid Fiber Coaxial plant, used as the underlying transport
电缆（HFC）设备：混合光纤同轴设备，用作底层传输
CMTS: Cable Modem Termination System (can be a Layer 2 bridging or Layer 3 routing CMTS)
CMTS：电缆调制解调器终端系统（可以是第2层桥接或第3层路由CMTS）
GWR: Residential Gateway Router (provides Layer 3 services to hosts)
GWR：住宅网关路由器（向主机提供第3层服务）
Host: PC, notebook, etc., which is connected to the CM or GWR
主机：连接到CM或GWR的PC、笔记本等
CM: Cable Modem
电缆调制解调器
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 -----|
|--- ACCESS ---||------ HFC ------||----- Aggregation / Core -----|
+-----+ +------+
|Host |--| GWR |
+-----+ +--+---+
| _ _ _ _ _ _
+------+ | |
| CM |---| |
+------+ | |
| HFC | +------+ +--------+
| | | | | Edge |
+-----+ +------+ | Network |---| CMTS |---| |=>ISP
|Host |--| CM |---| | | | | Router | Network
+-----+ +--+---+ | | +------+ +--------+
|_ _ _ _ _ _|
+------+ |
+-----+ | GWR/ | |
|Host |--| CM |---------+
+-----+ | |
+------+
+-----+ +------+
|Host |--| GWR |
+-----+ +--+---+
| _ _ _ _ _ _
+------+ | |
| CM |---| |
+------+ | |
| HFC | +------+ +--------+
| | | | | Edge |
+-----+ +------+ | Network |---| CMTS |---| |=>ISP
|Host |--| CM |---| | | | | Router | Network
+-----+ +--+---+ | | +------+ +--------+
|_ _ _ _ _ _|
+------+ |
+-----+ | GWR/ | |
|Host |--| CM |---------+
+-----+ | |
+------+
Figure 5.1
图5.1
One of the motivators for an MSO to deploy IPv6 over its cable network is to ease management burdens. IPv6 can be enabled on the CM, CMTS, and ER for management purposes. Currently portions of the cable infrastructure use IPv4 address space [RFC1918]; however, there is a finite number of those. Thus, IPv6 could have utility in the cable space implemented on the management plane initially and focused
MSO通过有线网络部署IPv6的动机之一是减轻管理负担。出于管理目的，可以在CM、CMT和ER上启用IPv6。目前部分电缆基础设施使用IPv4地址空间[RFC1918]；然而，其中的数量是有限的。因此，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.
当前有线网络中有两种不同的部署模式：桥接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和CMT都桥接了所有数据通信。进出主机设备的流量通过电缆网络转发到ER。ER然后通过ISP网络将流量路由到Internet。出于管理目的，CM和CMT支持一定程度的第3层功能。
2. Routed CMTS Network
2. 路由CMTS网络
In a routed network, the CMTS forwards IP traffic to/from hosts based on Layer 3 information using the IP source/destination address. The CM acts as a Layer 2 bridge for forwarding data traffic and supports some Layer 3 functionality for management purposes.
在路由网络中，CMTS使用IP源/目标地址，基于第3层信息将IP流量转发到主机或从主机转发IP流量。CM充当用于转发数据流量的第2层网桥，并支持用于管理目的的某些第3层功能。
Some of the factors that hinder deployment of native IPv6 in current routed and bridged cable networks include:
阻碍在当前路由和桥接电缆网络中部署本机IPv6的一些因素包括：
A. Changes need to be made to the DOCSIS specification [RF-Interface] to include support for IPv6 on the CM and CMTS. This is imperative for deploying native IPv6 over cable networks.
A.需要对DOCSIS规范[RF接口]进行更改，以包括对CM和CMT上IPv6的支持。这对于通过有线网络部署本机IPv6是必不可少的。
B. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. In IPv4, these devices rely on Internet Group Multicast Protocol (IGMP) join messages to track membership of hosts that are part of a particular IP multicast group. In order to support ND, a multicast-based process, the CM and CMTS will need to support IGMPv3/Multicast Listener Discovery Version 2 (MLDv2) or v1 snooping.
B.CM和CMT上的IPv6邻居发现（ND）问题。在IPv4中，这些设备依赖于Internet组多播协议（IGMP）加入消息来跟踪属于特定IP多播组的主机的成员身份。为了支持基于多播的进程ND，CM和CMT需要支持IGMPv3/多播侦听器发现版本2（MLDv2）或v1监听。
C. Classification of IPv6 traffic in the upstream and downstream direction. The CM and CMTS will need to support classification of IPv6 packets in order to give them the appropriate priority and QoS. Service providers that wish to deploy QoS mechanisms also have to support classification of IPv6 traffic.
C.上游和下游方向的IPv6流量分类。CM和CMT将需要支持IPv6数据包的分类，以便为它们提供适当的优先级和QoS。希望部署QoS机制的服务提供商还必须支持IPv6流量的分类。
Due to the above mentioned limitations in deployed cable networks, at the time of writing this document, the only option available for cable operators is to use tunneling techniques in order to transport IPv6 traffic over their current IPv4 infrastructure. The following
由于上述已部署电缆网络的限制，在编写本文档时，电缆运营商唯一可用的选择是使用隧道技术，以便在其当前IPv4基础设施上传输IPv6流量。以下
sections will cover tunneling and native IPv6 deployment scenarios in more detail.
本节将更详细地介绍隧道和本机IPv6部署场景。
In IPv4, the CM and CMTS act as Layer 2 bridges and forward all data traffic to/from the hosts and the ER. The hosts use the ER as their Layer 3 next hop. If there is a GWR behind the CM it can act as a next hop for all hosts and forward data traffic to/from the ER.
在IPv4中，CM和CMT充当第2层网桥，并将所有数据流量转发到主机和ER或从主机和ER转发。主机使用ER作为第3层下一跳。如果CM后面有一个GWR，它可以充当所有主机的下一个跃点，并将数据流量转发到ER或从ER转发数据流量。
When deploying IPv6 in this environment, the CM and CMTS will continue to act as bridging devices in order to keep the transition smooth and reduce operational complexity. The CM and CMTS will need to bridge IPv6 unicast and multicast packets to/from the ER and the hosts. If there is a GWR connected to the CM, it will need to forward IPv6 unicast and multicast traffic to/from the ER.
在此环境中部署IPv6时，CM和CMT将继续充当桥接设备，以保持平稳过渡并降低操作复杂性。CM和CMT将需要桥接与ER和主机之间的IPv6单播和多播数据包。如果有一个GWR连接到CM，则需要将IPv6单播和多播流量转发到ER或从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可以以本机方式或通过隧道方式部署在桥接CMTS网络中。本节讨论本机部署模型。隧道模型类似于第5.2.2.1节和第5.2.2.2节中所述的模型。
Figure 5.2.1 illustrates the IPv6 deployment scenario.
图5.2.1说明了IPv6部署场景。
+-----+ +-----+
|Host |--| GWR |
+-----+ +--+--+
| _ _ _ _ _ _
| +------+ | |
+--| CM |---| |
+------+ | |
| HFC | +------+ +--------+
| | | | | Edge |
+-----+ +------+ | Network |---| CMTS |--| |=>ISP
|Host |--| CM |---| | | | | Router |Network
+-----+ +------+ | | +------+ +--------+
|_ _ _ _ _ _|
|-------------||---------------------------------||---------------|
L3 Routed L2 Bridged L3 Routed
+-----+ +-----+
|Host |--| GWR |
+-----+ +--+--+
| _ _ _ _ _ _
| +------+ | |
+--| CM |---| |
+------+ | |
| HFC | +------+ +--------+
| | | | | Edge |
+-----+ +------+ | Network |---| CMTS |--| |=>ISP
|Host |--| CM |---| | | | | Router |Network
+-----+ +------+ | | +------+ +--------+
|_ _ _ _ _ _|
|-------------||---------------------------------||---------------|
L3 Routed L2 Bridged L3 Routed
Figure 5.2.1
图5.2.1
In this scenario, the CM and the CMTS bridge all data traffic so they will need to support bridging of native IPv6 unicast and multicast traffic. The following devices have to be upgraded to dual stack: Host, GWR, and ER.
在此场景中，CM和CMT桥接所有数据流量，因此它们需要支持本机IPv6单播和多播流量的桥接。必须将以下设备升级到双堆栈：主机、GWR和ER。
The proposed architecture for IPv6 deployment includes two components that must be provisioned: the CM and the host. Additionally if there is a GWR connected to the CM, it will also need to be provisioned. The host or the GWR use the ER as their Layer 3 next hop.
建议的IPv6部署体系结构包括两个必须配置的组件：CM和主机。此外，如果有一个GWR连接到CM，则还需要对其进行配置。主机或GWR将ER用作其第3层下一跳。
The CM will be provisioned in the same way as in currently deployed cable networks, using an IPv4 address on the cable interface connected to the MSO network for management functions. During the initialization phase, it will obtain its IPv4 address using Dynamic Host Configuration Protocol (DHCPv4), and download a DOCSIS configuration file identified by the DHCPv4 server.
配置CM的方式与当前部署的有线网络相同，使用连接到MSO网络的电缆接口上的IPv4地址进行管理。在初始化阶段，它将使用动态主机配置协议（DHCPv4）获取其IPv4地址，并下载由DHCPv4服务器标识的DOCSIS配置文件。
If there is no GWR connected to the CM, the host behind the CM will get a /64 prefix via stateless auto-configuration or DHCPv6.
如果没有GWR连接到CM，CM后面的主机将通过无状态自动配置或DHCPv6获得/64前缀。
If using stateless auto-configuration, the host listens for routing advertisements (RAs) from the ER. The RAs contain the /64 prefix assigned to the segment. Upon receipt of an RA, the host constructs its IPv6 address by combining the prefix in the RA (/64) and a unique identifier (e.g., its modified EUI-64 (64-bit Extended Unique Identifier) format interface ID).
如果使用无状态自动配置，主机将侦听来自ER的路由播发（RAs）。RAs包含分配给该段的/64前缀。在收到RA后，主机通过将RA中的前缀（/64）和唯一标识符（例如，其修改的EUI-64（64位扩展唯一标识符）格式接口ID）组合来构造其IPv6地址。
If DHCPv6 is used to obtain an IPv6 address, it will work in much the same way as DHCPv4 works today. The DHCPv6 messages exchanged between the host and the DHCPv6 server are bridged by the CM and the CMTS.
如果使用DHCPv6获取IPv6地址，它的工作方式将与DHCPv4目前的工作方式大致相同。主机和DHCPv6服务器之间交换的DHCPv6消息由CM和CMT桥接。
The GWR can use stateless auto-configuration (RA) to obtain an address for its upstream interface, the link between itself and the ER. This step is followed by a request via DHCP-PD (Prefix Delegation) for a prefix shorter than /64, typically /48 [RFC3177], which in turn is divided into /64s and assigned to its downstream interfaces connecting to the hosts.
GWR可以使用无状态自动配置（RA）来获取其上游接口的地址，即GWR自身与ER之间的链接。此步骤之后，通过DHCP-PD（前缀委派）请求短于/64的前缀，通常为/48[RFC3177]，该前缀又被划分为/64，并分配给连接到主机的下游接口。
The CM and CMTS must be able to bridge native IPv6 unicast and multicast traffic. The CMTS must provide IP connectivity between hosts attached to CMs, and must do so in a way that meets the expectation of Ethernet-attached customer equipment. In order to do that, the CM and CMTS must forward Neighbor Discovery (ND) packets between ER and the hosts attached to the CM.
CM和CMT必须能够桥接本机IPv6单播和多播流量。CMT必须在连接到CMs的主机之间提供IP连接，并且必须以满足连接到以太网的客户设备的期望的方式进行。为了做到这一点，CM和CMT必须在ER和连接到CM的主机之间转发邻居发现（ND）数据包。
Communication between hosts behind different CMs is always forwarded through the CMTS. IPv6 communication between the different sites relies on multicast IPv6 ND [RFC2461] frames being forwarded correctly by the CM and the CMTS.
不同CMs后面的主机之间的通信始终通过CMT转发。不同站点之间的IPv6通信依赖于CM和CMT正确转发的多播IPv6 ND[RFC2461]帧。
In order to support IPv6 multicast applications across DOCSIS cable networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 or v1 snooping. MLD is almost identical to IGMP in IPv4, only the name and numbers are changed. MLDv2 is identical to IGMPv3 and also supports ASM (Any-Source Multicast) and SSM (Source-Specific Multicast) service models. Implementation work on CM/CMTS should be minimal because the only significant difference between IPv4 IGMPv3 and IPv6 MLDv2 is the longer addresses in the protocol.
为了支持跨DOCSIS有线网络的IPv6多播应用，CM和桥接CMT需要支持IGMPv3/MLDv2或v1监听。MLD与IPv4中的IGMP几乎相同，只更改了名称和编号。MLDv2与IGMPv3相同，还支持ASM（任何源多播）和SSM（源特定多播）服务模型。在CM/CMT上的实现工作应该是最小的，因为IPv4 IGMPv3和IPv6 MLDv2之间唯一的显著区别是协议中的地址更长。
The hosts install a default route that points to the ER or the GWR. No routing protocols are needed on these devices, which generally have limited resources. If there is a GWR present, it will also use static default route to the ER.
主机安装指向ER或GWR的默认路由。这些设备通常资源有限，不需要路由协议。如果存在GWR，它还将使用到ER的静态默认路由。
The ER runs an IGP such as OSPFv3 or IS-IS. The connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the ER. For this reason, the static routes must also be redistributed. Prefix summarization should be done at the ER.
ER运行IGP，如OSPFv3或IS-IS。连接的前缀必须重新分配。如果使用DHCP-PD，ER将通过每个委派前缀安装静态路由。因此，静态路由也必须重新分配。前缀摘要应在ER处完成。
In an IPv4/IPv6 routed CMTS network, the CM still acts as a Layer 2 device and bridges all data traffic between its Ethernet interface and cable interface connected to the cable operator network. The CMTS acts as a Layer 3 router and may also include the ER functionality. The hosts and the GWR use the CMTS as their Layer 3 next hop.
在IPv4/IPv6路由CMTS网络中，CM仍然充当第2层设备，并在其以太网接口和连接到有线运营商网络的有线接口之间桥接所有数据通信。CMT充当第3层路由器，并且还可以包括ER功能。主机和GWR使用CMT作为第3层下一跳。
When deploying IPv6, the CMTS/ER will need to either tunnel IPv6 traffic or natively support IPv6.
部署IPv6时，CMTS/ER将需要通过隧道传输IPv6流量或本机支持IPv6。
There are five possible deployment scenarios for IPv6 in a routed CMTS network:
在路由CMTS网络中，IPv6有五种可能的部署方案：
1. IPv4 Cable (HFC) Network
1. IPv4电缆（HFC）网络
In this scenario, the cable network, including the CM and CMTS, remain IPv4 devices. The host and ER are upgraded to dual stack. This is the easiest way for a cable operator to provide IPv6 service, as no changes are made to the cable network.
在这种情况下，有线网络（包括CM和CMT）仍然是IPv4设备。主机和ER升级为双堆栈。这是有线电视运营商提供IPv6服务的最简单方式，因为有线电视网络没有任何变化。
2. IPv4 Cable (HFC) Network, GWR at Customer Site
2. IPv4电缆（HFC）网络，客户现场的GWR
In this case, the cable network, including the CM and CMTS, remain IPv4 devices. The host, GWR, and ER are upgraded to dual stack. This scenario is also easy to deploy since the cable operator just needs to add GWR at the customer site.
在这种情况下，电缆网络（包括CM和CMT）仍然是IPv4设备。主机、GWR和ER升级为双堆栈。由于有线电视运营商只需在客户站点添加GWR，因此该场景也很容易部署。
3. Dual-stacked Cable (HFC) Network, CM, and CMTS Support IPv6
3. 双堆叠电缆（HFC）网络、CM和CMT支持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.
在此场景中，CMT升级为双栈以支持IPv4和IPv6。由于CMTS支持IPv6，因此它也可以充当ER。CM将充当第2层网桥，但需要桥接IPv6单播和多播流量。此场景不容易部署，因为它需要更改DOCSIS规范。CM和CMT可能需要硬件和软件升级以支持IPv6。
4. Dual-stacked Cable (HFC) Network, Standalone GWR, and CMTS Support IPv6
4. 双堆叠电缆（HFC）网络、独立GWR和CMT支持IPv6
In this scenario there is a stand-alone GWR connected to the CM. Since the IPv6 functionality exists on the GWR, the CM does not need to be dual stack. The CMTS is upgraded to dual stack and it can incorporate the ER functionality. This scenario may also require hardware and software changes on the GWR and CMTS.
在这种情况下，有一个独立的GWR连接到CM。由于GWR上存在IPv6功能，因此CM不需要是双堆栈。CMT升级为双堆栈，并可结合ER功能。该场景还可能需要对GWR和CMT进行硬件和软件更改。
5. Dual-stacked Cable (HFC) Network, Embedded GWR/CM, and CMTS Support IPv6
5. 双堆叠电缆（HFC）网络、嵌入式GWR/CM和CMT支持IPv6
In this scenario, the CM and GWR functionality exists on a single device, which needs to be upgraded to dual stack. The CMTS will also need to be upgraded to a dual-stack device. This scenario is also difficult to deploy in existing cable network since it requires changes on the Embedded GWR/CM and the CMTS.
在此场景中，CM和GWR功能存在于单个设备上，需要升级到双堆栈。CMT还需要升级为双堆栈设备。这种情况也很难在现有有线网络中部署，因为它需要对嵌入式GWR/CM和CMT进行更改。
The DOCSIS specification will also need to be modified to allow native IPv6 support on the Embedded GWR/CM.
DOCSIS规范也需要修改，以允许在嵌入式GWR/CM上支持本机IPv6。
This is one of the most cost-effective ways for a cable operator to offer IPv6 services to its customers. Since the cable network remains IPv4, there is relatively minimal cost involved in turning up IPv6 service. All IPv6 traffic is exchanged between the hosts and the ER.
这是有线电视运营商向其客户提供IPv6服务的最具成本效益的方式之一。由于有线网络仍然是IPv4，因此开通IPv6服务的成本相对较低。所有IPv6流量在主机和ER之间交换。
Figure 5.2.2.1 illustrates this deployment scenario.
图5.2.2.1说明了此部署场景。
+-----------+ +------+ +--------+
+-----+ +-------+ | Cable | | | | Edge |
|Host |--| CM |----| (HFC) |---| CMTS |---| |=>ISP
+-----+ +-------+ | Network | | | | Router |Network
+-----------+ +------+ +--------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel
+-----------+ +------+ +--------+
+-----+ +-------+ | 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
图5.2.2.1
In this scenario, the CM and the CMTS will only need to support IPv4, so no changes need to be made to them or the cable network. The following devices have to be upgraded to dual stack: Host and ER.
在这种情况下，CM和CMT只需要支持IPv4，因此无需对其或有线网络进行更改。以下设备必须升级到双堆栈：主机和ER。
The only device that needs to be assigned an IPv6 address at the customer site is the host. Host address assignment can be done in multiple ways. Depending on the tunneling mechanism used, it could be automatic or might require manual configuration.
唯一需要在客户站点分配IPv6地址的设备是主机。主机地址分配可以通过多种方式完成。根据使用的隧道机制，它可能是自动的，也可能需要手动配置。
The host still receives an IPv4 address using DHCPv4, which works the same way in currently deployed cable networks. In order to get IPv6 connectivity, host devices will also need an IPv6 address and a means to communicate with the ER.
主机仍然使用DHCPv4接收IPv4地址，这与当前部署的有线网络的工作方式相同。为了获得IPv6连接，主机设备还需要IPv6地址和与ER通信的方式。
All IPv6 traffic will be sent to/from the ER and the host device. In order to transport IPv6 packets over the cable operator IPv4 network, the host and the ER will need to use one of the available IPv6 in IPv4 tunneling mechanisms.
所有IPv6流量都将发送到ER和主机设备，或从ER和主机设备发送。为了通过有线电视运营商IPv4网络传输IPv6数据包，主机和ER需要使用IPv4隧道机制中的一种可用IPv6。
The host will use its IPv4 address to source the tunnel to the ER. All IPv6 traffic will be forwarded to the ER, encapsulated in IPv4 packets. The intermediate IPv4 nodes will forward this traffic as regular IPv4 packets. The ER will need to terminate the tunnel and/or provide other IPv6 services.
主机将使用其IPv4地址将隧道源发送到ER。所有IPv6流量都将转发到ER，并封装在IPv4数据包中。中间IPv4节点将此流量作为常规IPv4数据包转发。ER将需要终止隧道和/或提供其他IPv6服务。
Routing configuration on the host will vary depending on the tunneling technique used. In some cases, a default or static route might be needed to forward traffic to the next hop.
主机上的路由配置将因使用的隧道技术而异。在某些情况下，可能需要使用默认或静态路由将流量转发到下一跳。
The ER runs an IGP such as OSPFv3 or ISIS.
ER运行一个IGP，如OSPFv3或ISIS。
The cable operator can provide IPv6 services to its customers, in this scenario, by adding a GWR behind the CM. Since the GWR will facilitate all IPv6 traffic between the host and the ER, the cable network, including the CM and CMTS, does not need to support IPv6, and can remain as IPv4 devices.
在这种情况下，有线电视运营商可以通过在CM后面添加GWR向其客户提供IPv6服务。由于GWR将促进主机和ER之间的所有IPv6通信，因此有线网络（包括CM和CMT）不需要支持IPv6，可以保留为IPv4设备。
Figure 5.2.2.2 illustrates this deployment scenario.
图5.2.2.2说明了此部署场景。
+-----+
|Host |
+--+--+
| +-----------+ +------+ +--------+
+---+---+ +-------+ | Cable | | | | Edge |
| GWR |--| CM |----| (HFC) |---| CMTS |---| |=>ISP
+-------+ +-------+ | Network | | | | Router |Network
+-----------+ +------+ +--------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel
+-----+
|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
图5.2.2.2
In this scenario, the CM and the CMTS will only need to support IPv4, so no changes need to be made to them or the cable network. The following devices have to be upgraded to dual stack: Host, GWR, and ER.
在这种情况下，CM和CMT只需要支持IPv4，因此无需对其或有线网络进行更改。必须将以下设备升级到双堆栈：主机、GWR和ER。
The only devices that need to be assigned an IPv6 address at customer site are the host and GWR. IPv6 address assignment can be done statically at the GWR downstream interface. The GWR will send out RA messages on its downstream interface, which will be used by the hosts to auto-configure themselves with an IPv6 address. The GWR can also configure its upstream interface using RA messages from the ER and use DHCP-PD for requesting a /48 [RFC3177] prefix from the ER. This /48 prefix will be used to configure /64s on hosts connected to the GWR downstream interfaces. The uplink to the ISP network is configured with a /64 prefix as well.
唯一需要在客户站点分配IPv6地址的设备是主机和GWR。IPv6地址分配可以在GWR下游接口静态完成。GWR将在其下游接口上发送RA消息，主机将使用该消息自动配置自己的IPv6地址。GWR还可以使用来自ER的RA消息配置其上游接口，并使用DHCP-PD从ER请求a/48[RFC3177]前缀。此/48前缀将用于在连接到GWR下游接口的主机上配置/64s。ISP网络的上行链路也配置了/64前缀。
The GWR still receives a global IPv4 address on its upstream interface using DHCPv4, which works the same way in currently deployed cable networks. In order to get IPv6 connectivity to the Internet, the GWR will need to communicate with the ER.
GWR仍然使用DHCPv4在其上游接口上接收全局IPv4地址，这与当前部署的有线网络中的工作方式相同。为了实现到Internet的IPv6连接，GWR需要与ER通信。
All IPv6 traffic will be sent to/from the ER and the GWR, which will forward IPv6 traffic to/from the host. In order to transport IPv6 packets over the cable operator IPv4 network, the GWR and the ER will need to use one of the available IPv6 in IPv4 tunneling mechanisms. All IPv6 traffic will need to go through the tunnel, once it comes up.
所有IPv6流量都将发送到/从ER和GWR发送，后者将向/从主机转发IPv6流量。为了通过有线电视运营商IPv4网络传输IPv6数据包，GWR和ER需要使用IPv4隧道机制中的一种可用IPv6。一旦出现，所有IPv6流量都需要通过隧道。
The GWR will use its IPv4 address to source the tunnel to the ER. The tunnel endpoint will be the IPv4 address of the ER. All IPv6 traffic will be forwarded to the ER, encapsulated in IPv4 packets. The intermediate IPv4 nodes will forward this traffic as regular IPv4 packets. In case of 6to4 tunneling, the ER will need to support 6to4 relay functionality in order to provide IPv6 Internet connectivity to the GWR, and hence, the hosts connected to the GWR.
GWR将使用其IPv4地址将隧道源发送到ER。隧道端点将是ER的IPv4地址。所有IPv6流量都将转发到ER，并封装在IPv4数据包中。中间IPv4节点将此流量作为常规IPv4数据包转发。在6to4隧道的情况下，ER将需要支持6to4中继功能，以便提供到GWR的IPv6 Internet连接，从而提供连接到GWR的主机。
Depending on the tunneling technique used, additional configuration might be needed on the GWR and the ER. If the ER is also providing a 6to4 relay service then a default route will need to be added to the GWR pointing to the ER, for all non-6to4 traffic.
根据使用的隧道技术，GWR和ER可能需要额外的配置。如果ER还提供6to4中继服务，则需要为所有非6to4通信量向指向ER的GWR添加默认路由。
If using manual tunneling, the GWR and ER can use static routing or an IGP such as RIPng [RFC2080]. The RIPng updates can be transported over a manual tunnel, which does not work when using 6to4 tunneling since it does not support multicast.
如果使用手动隧道，GWR和ER可以使用静态路由或IGP，如RIPng[RFC2080]。RIPng更新可以通过手动隧道传输，使用6to4隧道时，手动隧道不起作用，因为它不支持多播。
Customer routes can be carried to the ER using RIPng updates. The ER can advertise these routes in its IGP. Prefix summarization should be done at the ER.
可以使用RIPng更新将客户路线传送到ER。ER可以在其IGP中公布这些路线。前缀摘要应在ER处完成。
If DHCP-PD is used for address assignment, a static route is automatically installed on the ER for each delegated /48 prefix. The static routes need to be redistributed into the IGP at the ER, so there is no need for a routing protocol between the ER and the GWR.
如果DHCP-PD用于地址分配，则会在ER上为每个委派/48前缀自动安装静态路由。静态路由需要在ER处重新分配到IGP中，因此ER和GWR之间不需要路由协议。
The ER runs an IGP such as OSPFv3 or ISIS.
ER运行一个IGP，如OSPFv3或ISIS。
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.
在这种情况下，有线电视运营商可以向其客户提供本机IPv6服务，因为有线电视网络（包括CMT）支持IPv6。ER功能可以包含在CMTS中，也可以存在于连接到CMTS上游接口的单独路由器上。CM将需要桥接IPv6单播和多播流量。
Figure 5.2.2.3 illustrates this deployment scenario.
图5.2.2.3说明了此部署场景。
+-----------+ +-------------+
+-----+ +-------+ | Cable | | CMTS / Edge |
|Host |--| CM |----| (HFC) |---| |=>ISP
+-----+ +-------+ | Network | | Router | Network
+-----------+ +-------------+
+-----------+ +-------------+
+-----+ +-------+ | 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
图5.2.2.3
Since the CM still acts as a Layer 2 bridge, it does not need to be dual stack. The CM will need to support bridging of IPv6 unicast and multicast traffic and IGMPv3/MLDv2 or v1 snooping, which requires changes in the DOCSIS specification. In this scenario, the following devices have to be upgraded to dual stack: Host and CMTS/ER.
由于CM仍然充当第2层桥接器，因此它不需要是双堆栈。CM需要支持IPv6单播和多播流量的桥接以及IGMPv3/MLDv2或v1监听，这需要修改DOCSIS规范。在这种情况下，必须将以下设备升级到双堆栈：主机和CMT/ER。
In cable networks today, the CM receives a private IPv4 address using DHCPv4 for management purposes. In an IPv6 environment, the CM will continue to use an IPv4 address for management purposes. The cable operator can also choose to assign an IPv6 address to the CM for management, but the CM will have to be upgraded to support this functionality.
在今天的有线网络中，CM使用DHCPv4接收专用IPv4地址以进行管理。在IPv6环境中，CM将继续使用IPv4地址进行管理。有线电视运营商也可以选择将IPv6地址分配给CM进行管理，但CM必须升级以支持此功能。
IPv6 address assignment for the CM and host can be done via DHCP or stateless auto-configuration. If the CM uses an IPv4 address for management, it will use DHCPv4 for its address assignment and the CMTS will need to act as a DHCPv4 relay agent. If the CM uses an IPv6 address for management, it can use DHCPv6, with the CMTS acting as a DHCPv6 relay agent, or the CMTS can be statically configured with a /64 prefix and it can send out RA messages out the cable interface. The CMs connected to the cable interface can use the RA messages to auto-configure themselves with an IPv6 address. All CMs connected to the cable interface will be in the same subnet.
CM和主机的IPv6地址分配可以通过DHCP或无状态自动配置完成。如果CM使用IPv4地址进行管理，它将使用DHCPv4进行地址分配，CMT将需要充当DHCPv4中继代理。如果CM使用IPv6地址进行管理，它可以使用DHCPv6，CMT充当DHCPv6中继代理，或者CMT可以静态配置为/64前缀，并可以通过电缆接口发送RA消息。连接到电缆接口的CMs可以使用RA消息自动配置自己的IPv6地址。连接到电缆接口的所有CMs将位于同一子网中。
The hosts can receive their IPv6 address via DHCPv6 or stateless auto-configuration. With DHCPv6, the CMTS may need to act as a DHCPv6 relay agent and forward DHCP messages between the hosts and the DHCP server. With stateless auto-configuration, the CMTS will be configured with multiple /64 prefixes and send out RA messages to the hosts. If the CMTS is not also acting as an ER, the RA messages will come from the ER connected to the CMTS upstream interface. The CMTS will need to forward the RA messages downstream or act as an ND proxy.
主机可以通过DHCPv6或无状态自动配置接收其IPv6地址。对于DHCPv6，CMT可能需要充当DHCPv6中继代理，并在主机和DHCP服务器之间转发DHCP消息。通过无状态自动配置，CMT将配置多个/64前缀，并向主机发送RA消息。如果CMTS不同时充当ER，RA消息将来自连接到CMTS上游接口的ER。CMT需要将RA消息转发到下游或充当ND代理。
All IPv6 traffic will be sent to/from the CMTS and hosts. Data forwarding will work the same way it works in currently deployed cable networks. The CMTS will forward IPv6 traffic to/from hosts based on the IP source/destination address.
所有IPv6流量都将发送到CMT和主机，或从CMT和主机发送。数据转发的工作方式与当前部署的有线网络相同。CMTS将根据IP源/目标地址向主机转发IPv6通信量。
No routing protocols are needed between the CMTS and the host since the CM and host are directly connected to the CMTS cable interface. Since the CMTS supports IPv6, hosts will use the CMTS as their Layer 3 next hop.
CMTS和主机之间不需要路由协议，因为CM和主机直接连接到CMTS电缆接口。由于CMT支持IPv6，主机将使用CMT作为其第3层下一跳。
If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or IS-IS.
如果CMT还充当ER，则它运行一个IGP，如OSPFv3或is-is。
5.2.2.4. Dual-Stacked Cable (HFC) Network, Stand-Alone GWR, and CMTS Support IPv6
5.2.2.4. 双堆叠电缆（HFC）网络、独立GWR和CMT支持IPv6
In this case, the cable operator can offer IPv6 services to its customers by adding a GWR between the CM and the host. The GWR will facilitate IPv6 communication between the host and the CMTS/ER. The CMTS will be upgraded to dual stack to support IPv6 and can act as an ER as well. The CM will act as a bridge for forwarding data traffic and does not need to support IPv6.
在这种情况下，有线电视运营商可以通过在CM和主机之间添加GWR向其客户提供IPv6服务。GWR将促进主机和CMTS/ER之间的IPv6通信。CMT将升级为双栈以支持IPv6，并可以充当ER。CM将充当转发数据流量的桥梁，不需要支持IPv6。
This scenario is similar to the case described in Section 5.2.2.2. The only difference in this case is that the ER functionality exists on the CMTS instead of on a separate router in the cable operator network.
这种情况类似于第5.2.2.2节中描述的情况。这种情况下唯一的区别是，ER功能存在于CMT上，而不是有线运营商网络中的单独路由器上。
Figure 5.2.2.4 illustrates this deployment scenario.
图5.2.2.4说明了此部署场景。
+-----------+ +-----------+
+------+ +-------+ +-------+ | Cable | |CMTS / Edge|
| Host |--| GWR |--| CM |---| (HFC) |---| |=>ISP
+------+ +-------+ +-------+ | Network | | Router |Network
+-----------+ +-----------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel
|-----------------||-----------------------------||--------------|
IPv4/v6 IPv4 IPv4/v6
+-----------+ +-----------+
+------+ +-------+ +-------+ | Cable | |CMTS / Edge|
| Host |--| GWR |--| CM |---| (HFC) |---| |=>ISP
+------+ +-------+ +-------+ | Network | | Router |Network
+-----------+ +-----------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel
|-----------------||-----------------------------||--------------|
IPv4/v6 IPv4 IPv4/v6
Figure 5.2.2.4
图5.2.2.4
Since the CM still acts as a Layer 2 bridge, it does not need to be dual stack, nor does it need to support IPv6. In this scenario, the following devices have to be upgraded to dual stack: Host, GWR, and CMTS/ER.
由于CM仍然充当第2层网桥，因此它不需要是双栈，也不需要支持IPv6。在此场景中，必须将以下设备升级到双堆栈：主机、GWR和CMT/ER。
The CM will still receive a private IPv4 address using DHCPv4, which works the same way in existing cable networks. The CMTS will act as a DHCPv4 relay agent.
CM仍将使用DHCPv4接收专用IPv4地址，这与现有有线网络中的工作方式相同。CMTS将充当DHCPv4中继代理。
The address assignment for the host and GWR happens in a similar manner as described in Section 5.2.2.2.2.
主机和GWR的地址分配方式与第5.2.2.2.2节所述类似。
Data forwarding between the host and CMTS/ER is facilitated by the GWR and happens in a similar manner as described in Section 5.2.2.2.3.
GWR促进主机和CMTS/ER之间的数据转发，并以第5.2.2.2.3节所述的类似方式进行。
In this case, routing is very similar to the case described in Section 5.2.2.2.4. Since the CMTS now incorporates the ER functionality, it will need to run an IGP such as OSPFv3 or IS-IS.
在这种情况下，布线与第5.2.2.2.4节中描述的情况非常相似。由于CMTS现在包含ER功能，因此需要运行IGP，如OSPFv3或IS-IS。
5.2.2.5. Dual-Stacked Cable (HFC) Network, Embedded GWR/CM, and CMTS Support IPv6
5.2.2.5. 双堆叠电缆（HFC）网络、嵌入式GWR/CM和CMT支持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.
在这种情况下，有线电视运营商可以向其客户提供本机IPv6服务，因为有线电视网络（包括CM/Embedded GWR和CMT）支持IPv6。ER功能可以包含在CMTS中，也可以存在于连接到CMTS上游接口的单独路由器上。CM/嵌入式GWR充当第3层设备。
Figure 5.2.2.5 illustrates this deployment scenario.
图5.2.2.5说明了此部署场景。
+-----------+ +-------------+
+-----+ +-----------+ | Cable | | CMTS / Edge |
|Host |---| CM / GWR |---| (HFC) |---| |=>ISP
+-----+ +-----------+ | Network | | Router |Network
+-----------+ +-------------+
+-----------+ +-------------+
+-----+ +-----------+ | Cable | | CMTS / Edge |
|Host |---| CM / GWR |---| (HFC) |---| |=>ISP
+-----+ +-----------+ | Network | | Router |Network
+-----------+ +-------------+
|---------------------------------------------------------|
IPv4/v6
|---------------------------------------------------------|
IPv4/v6
Figure 5.2.2.5
图5.2.2.5
Since the CM/GWR acts as a Layer 3 device, IPv6 can be deployed end-to-end. In this scenario, the following devices have to be upgraded to dual stack: Host, CM/GWR, and CMTS/ER.
由于CM/GWR充当第3层设备，因此可以端到端部署IPv6。在此场景中，必须将以下设备升级到双堆栈：主机、CM/GWR和CMTS/ER。
Since the CM/GWR is dual stack, it can receive an IPv4 or IPv6 address using DHCP for management purposes. As the GWR functionality is embedded in the CM, it will need an IPv6 address for forwarding data traffic. IPv6 address assignment for the CM/GWR and host can be done via DHCPv6 or DHCP-PD.
由于CM/GWR是双栈，因此出于管理目的，它可以使用DHCP接收IPv4或IPv6地址。由于GWR功能嵌入到CM中，因此需要一个IPv6地址来转发数据流量。CM/GWR和主机的IPv6地址分配可以通过DHCPv6或DHCP-PD完成。
If using DHCPv6, the CMTS will need to act as a DHCPv6 relay agent. The host and CM/GWR will receive IPv6 addresses from pools of /64 prefixes configured on the DHCPv6 server. The CMTS will need to glean pertinent information from the DHCP Offer messages, sent from the DHCP server to the DHCP clients (host and CM/GWR), much like it does today in DHCPv4. All CM/GWR connected to the same cable interface on the CMTS belong to the same management /64 prefix. The hosts connected to the same cable interface on the CMTS may belong to different /64 customer prefixes, as the CMTS may have multiple /64 prefixes configured under its cable interfaces.
如果使用DHCPv6，CMT将需要充当DHCPv6中继代理。主机和CM/GWR将从DHCPv6服务器上配置的/64前缀池接收IPv6地址。CMT需要从DHCP提供消息中收集相关信息，这些消息从DHCP服务器发送到DHCP客户端（主机和CM/GWR），就像今天在DHCPv4中一样。连接到CMT上同一电缆接口的所有CM/GWR都属于同一管理/64前缀。连接到CMT上相同电缆接口的主机可能属于不同的/64客户前缀，因为CMT可能在其电缆接口下配置了多个/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.
也可以将DHCP-PD用于IPv6地址分配。在这种情况下，CM/GWR将使用无状态自动配置，使用CMTS/ER在RA消息中发送的/64前缀将IPv6地址分配给其上游接口。一旦CM/GWR将IPv6地址分配给其上游接口，它将从CMTS/ER请求/48[RFC3177]前缀，并将该/48前缀切碎为/64s，以便将IPv6地址分配给主机。ISP网络的上行链路也配置了/64前缀。
The host will use the CM/GWR as the Layer 3 next hop. The CM/GWR will forward all IPv6 traffic to/from the CMTS/ER and hosts. The CMTS/ER will forward IPv6 traffic to/from hosts based on the IP source/destination address.
主机将使用CM/GWR作为第3层下一跳。CM/GWR将向CMT/ER和主机转发所有IPv6流量。CMTS/ER将根据IP源/目标地址向主机转发IPv6通信量。
The CM/GWR can use a static default route pointing to the CMTS/ER or it can run a routing protocol such as RIPng or OSPFv3 between itself and the CMTS. Customer routes from behind the CM/GWR can be carried to the CMTS using routing updates.
CM/GWR可以使用指向CMT/ER的静态默认路由，也可以在自身和CMT之间运行路由协议，如RIPng或OSPFv3。可以使用路由更新将CM/GWR后面的客户路由传送到CMT。
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用于地址分配，则会在CMTS/ER上为每个委派/48前缀自动安装静态路由。静态路由需要在CMTS/ER处重新分配到IGP中，因此CMTS/ER和GWR之间不需要路由协议。
If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or IS-IS.
如果CMT还充当ER，则它运行一个IGP，如OSPFv3或is-is。
In order to support IPv6 multicast applications across DOCSIS cable networks, the CM and bridging CMTS will need to support IGMPv3/MLDv2 or v1 snooping. MLD is almost identical to IGMP in IPv4, only the
为了支持跨DOCSIS有线网络的IPv6多播应用，CM和桥接CMT将需要支持IGMPv3/MLDv2或v1监听。MLD与IPv4中的IGMP几乎相同，只有
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（任何源多播）和SSM（源特定多播）服务模型。
SSM is more suited for deployments where the SP intends to provide paid content to the users (video or audio). These types of services are expected to be of primary interest. Moreover, the simplicity of the SSM model often overrides the scalability issues that would be resolved in an ASM model. ASM is, however, an option that is discussed in Section 6.3.1. The Layer 3 CM, GWR, and Layer 3 routed CMTS/ER will need to be enabled with PIM-SSM, which requires the definition and support for IGMPv3/MLDv1 or v2 snooping, in order to track join/leave messages from the hosts. Another option would be for the Layer 3 CM or GWR to support MLD proxy routing. The Layer 3 next hop for the hosts needs to support MLD.
SSM更适合SP打算向用户提供付费内容（视频或音频）的部署。预计这些类型的服务将是最重要的。此外，SSM模型的简单性通常会覆盖ASM模型中要解决的可伸缩性问题。但是，ASM是第6.3.1节中讨论的一个选项。需要使用PIM-SSM启用第3层CM、GWR和第3层路由CMT/ER，这需要定义和支持IGMPv3/MLDv1或v2侦听，以便跟踪来自主机的加入/离开消息。另一种选择是第3层CM或GWR支持MLD代理路由。主机的第3层下一跳需要支持MLD。
Refer to Section 6.3 for more IPv6 multicast details.
有关IPv6多播的更多详细信息，请参阅第6.3节。
IPv6 will not change or add any queuing/scheduling functionality already existing in DOCSIS specifications. But the QoS mechanisms on the CMTS and CM would need to be IPv6 capable. This includes support for IPv6 classifiers, so that data traffic to/from host devices can be classified appropriately into different service flows and be assigned appropriate priority. Appropriate classification criteria would need to be implemented for unicast and multicast traffic.
IPv6不会更改或添加DOCSIS规范中已有的任何排队/调度功能。但是CMT和CM上的QoS机制需要支持IPv6。这包括对IPv6分类器的支持，以便可以将进出主机设备的数据流量适当地分类到不同的服务流中，并分配适当的优先级。需要为单播和多播通信量实施适当的分类标准。
Traffic classification and marking should be done at the CM for upstream traffic and the CMTS/ER for downstream traffic, in order to support the various types of services: data, voice, and video. The same IPv4 QoS concepts and methodologies should be applied for IPv6 as well.
流量分类和标记应在上游流量的CM和下游流量的CMT/ER处进行，以支持各种类型的服务：数据、语音和视频。同样的IPv4 QoS概念和方法也应适用于IPv6。
It is important to note that when traffic is encrypted end-to-end, the traversed network devices will not have access to many of the packet fields used for classification purposes. In these cases, routers will most likely place the packets in the default classes. The QoS design should take into consideration this scenario and try to use mainly IP header fields for classification purposes.
重要的是要注意，当对通信量进行端到端加密时，经过的网络设备将无法访问用于分类目的的许多数据包字段。在这些情况下，路由器最有可能将数据包放在默认类中。QoS设计应考虑到这种情况，并尝试主要使用IP头字段进行分类。
Security in a DOCSIS cable network is provided using Baseline Privacy Plus (BPI+). The only part that is dependent on IP addresses is encrypted multicast. Semantically, multicast encryption would work the same way in an IPv6 environment as in the IPv4 network. However,
DOCSIS有线网络中的安全性是使用基线隐私增强（BPI+）提供的。唯一依赖于IP地址的部分是加密多播。从语义上讲，多播加密在IPv6环境中的工作方式与在IPv4网络中的工作方式相同。然而
appropriate enhancements will be needed in the DOCSIS specification to support encrypted IPv6 multicast.
DOCSIS规范中需要适当的增强以支持加密的IPv6多播。
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]。如果在主机或GWR上可用，可以启用IPv6防火墙功能。
The ISP provides security against attacks that come from its own subscribers, but it could also implement security services that protect its subscribers from attacks sourced from 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网络和其他订户免受其客户的攻击。因此，应在面向订户的所有接口上使用单播反向路径转发（uRPF）[RFC3704]和访问控制列表（ACL）。应根据IPv6[IPv6安全]的操作要求实施过滤。
The CMTS/ER should protect its processing resources against floods of valid customer control traffic such as: Router and Neighbor Solicitations, and MLD Requests.
CMTS/ER应保护其处理资源免受有效客户控制流量的泛滥，如：路由器和邻居请求，以及MLD请求。
All other security features used with the IPv4 service should be similarly applied to IPv6 as well.
与IPv4服务一起使用的所有其他安全功能也应类似地应用于IPv6。
IPv6 can have many applications in cable networks. MSOs can initially implement IPv6 on the control plane and use it to manage the thousands of devices connected to the CMTS. This would be a good way to introduce IPv6 in a cable network. Later, the MSO can extend IPv6 to the data plane and use it to carry customer traffic as well as management traffic.
IPv6在有线网络中有许多应用。MSO最初可以在控制平面上实现IPv6，并使用它来管理连接到CMT的数千个设备。这将是在有线网络中引入IPv6的一个好方法。之后，MSO可以将IPv6扩展到数据平面，并使用它承载客户流量和管理流量。
IPv6 can be enabled in a cable network for management of devices like CM, CMTS, and ER. With the rollout of advanced services like VoIP and Video-over-IP, MSOs are looking for ways to manage the large number of devices connected to the CMTS. In IPv4, an RFC1918 address is assigned to these devices for management purposes. Since there is a finite number of RFC1918 addresses available, it is becoming difficult for MSOs to manage these devices.
IPv6可以在有线网络中启用，用于管理CM、CMT和ER等设备。随着VoIP和IP视频等高级服务的推出，MSO正在寻找管理大量连接到CMT的设备的方法。在IPv4中，为这些设备分配RFC1918地址以进行管理。由于可用的RFC1918地址数量有限，MSO管理这些设备变得越来越困难。
By using IPv6 for management purposes, MSOs can scale their network management systems to meet their needs. The CMTS/ER can be configured with a /64 management prefix that is shared among all CMs connected to the CMTS cable interface. Addressing for the CMs can be done via stateless auto-configuration or DHCPv6. Once the CMs receive a /64 prefix, they can configure themselves with an IPv6 address.
通过使用IPv6进行管理，MSO可以扩展其网络管理系统以满足其需求。CMTS/ER可以配置一个/64管理前缀，该前缀在连接到CMTS电缆接口的所有CMs之间共享。CMs的寻址可以通过无状态自动配置或DHCPv6完成。一旦CMs接收到/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管理的设备，则可以在CMT/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不再需要DOCSIS 3.0[DOCSIS 3.0-Reqs]中所述的IPv4地址进行管理。
The current DOCSIS, PacketCable, and CableHome MIB modules are already designed to support IPv6 objects. In this case, IPv6 will neither add nor change any of the functionality of these MIB modules. The Textual Convention used to represent Structure of Management Information Version 2 (SMIv2) objects representing IP addresses was updated [RFC4001] and a new Textual Convention InetAddressType was added to identify the type of the IP address used for IP address objects in MIB modules.
当前的DOCSIS、PacketCable和CableHome MIB模块已经设计为支持IPv6对象。在这种情况下，IPv6既不会添加也不会更改这些MIB模块的任何功能。更新了用于表示IP地址的管理信息版本2（SMIv2）对象结构的文本约定[RFC4001]，并添加了新的文本约定InetAddressType，以标识MIB模块中IP地址对象使用的IP地址类型。
There are some exceptions; the MIB modules that might need to add IPv6 support are defined in the DOCSIS 3.0 OSSI specification [DOCSIS3.0-OSSI].
有一些例外；可能需要添加IPv6支持的MIB模块在DOCSIS 3.0 OSI规范[DOCSIS 3.0-OSI]中定义。
This section describes the IPv6 deployment options in today's high-speed DSL networks.
本节介绍当今高速DSL网络中的IPv6部署选项。
Digital Subscriber Line (DSL) broadband services provide users with IP connectivity over the existing twisted-pair telephone lines called the local-loop. A wide range of bandwidth offerings are available depending on the quality of the line and the distance between the Customer Premise Equipment and the DSL Access Multiplexer (DSLAM).
数字用户线（DSL）宽带服务通过称为本地环路的现有双绞线电话线为用户提供IP连接。根据线路的质量以及用户端设备与DSL接入多路复用器（DSLAM）之间的距离，可以提供多种带宽。
The following network elements are typical of a DSL network:
以下网络元件是DSL网络的典型特征：
DSL Modem: It can be a stand-alone device, be incorporated in the host, incorporate router functionalities, and also have the capability to act as a CPE router.
DSL调制解调器：它可以是一个独立的设备，可以整合到主机中，整合路由器功能，还可以充当CPE路由器。
Customer Premise Router (CPR): It is used to provide Layer 3 services for customer premise networks. It is usually used to provide firewalling functions and segment broadcast domains for a small business.
客户端路由器（CPR）：用于为客户端网络提供第3层服务。它通常用于为小型企业提供防火墙功能和分段广播域。
DSL Access Multiplexer (DSLAM): It terminates multiple twisted-pair telephone lines and provides aggregation to BRAS.
DSL接入多路复用器（DSLAM）：它终止多条双绞线电话线，并向BRA提供聚合。
Broadband Remote Access Server (BRAS): It aggregates or terminates multiple Permanent Virtual Circuits (PVCs) corresponding to the subscriber DSL circuits.
宽带远程访问服务器（BRAS）：它聚合或终止与用户DSL电路对应的多个永久虚拟电路（PVC）。
Edge Router (ER): It provides the Layer 3 interface to the ISP network.
边缘路由器（ER）：它为ISP网络提供第3层接口。
Figure 6.1 depicts all the network elements mentioned.
图6.1描述了提到的所有网络元素。
Customer Premise | Network Access Provider | Network Service Provider
CP NAP NSP
+-----+ +------+ +------+ +--------+
|Hosts|--|Router| +--+ BRAS +---+ Edge | ISP
+-----+ +--+---+ | | | | Router +==> Network
| | +------+ +--------+
+--+---+ |
| DSL +-+ |
|Modem | | |
+------+ | +-----+ |
+--+ | |
+------+ |DSLAM+--+
+-----+ | DSL | +--+ |
|Hosts|--+Modem +-+ +-----+
+-----+ +--+---+
Customer Premise | Network Access Provider | Network Service Provider
CP NAP NSP
+-----+ +------+ +------+ +--------+
|Hosts|--|Router| +--+ BRAS +---+ Edge | ISP
+-----+ +--+---+ | | | | Router +==> Network
| | +------+ +--------+
+--+---+ |
| DSL +-+ |
|Modem | | |
+------+ | +-----+ |
+--+ | |
+------+ |DSLAM+--+
+-----+ | DSL | +--+ |
|Hosts|--+Modem +-+ +-----+
+-----+ +--+---+
Figure 6.1
图6.1
There are three main design approaches to providing IPv4 connectivity over a DSL infrastructure:
通过DSL基础设施提供IPv4连接有三种主要设计方法：
1. Point-to-Point Model: Each subscriber connects to the DSLAM over a twisted pair and is provided with a unique PVC that links it to the service provider. The PVCs can be terminated at the BRAS or at the Edge Router. This type of design is not very scalable if the PVCs are not terminated as close as possible to the DSLAM (at the BRAS). In this case, a large number of Layer 2 circuits has to be maintained over a significant portion of the network. The Layer 2 domains can be terminated at the ER in three ways:
1. 点对点模式：每个用户通过双绞线连接到DSLAM，并提供一个独特的PVC连接到服务提供商。PVC可以在BRA或边缘路由器处终止。如果PVC没有尽可能靠近DSLAM（在BRA处）终止，则这种类型的设计的可扩展性不是很强。在这种情况下，必须在网络的很大一部分上维持大量的第2层电路。层2域可通过三种方式在ER处终止：
A. In a common bridge group with a virtual interface that routes traffic out.
A.在具有虚拟接口的公共网桥组中，该虚拟接口将流量路由出去。
B. By enabling a Routed Bridged Encapsulation feature, all users could be part of the same subnet. This is the most common deployment approach of IPv4 over DSL but it might not be the best choice in IPv6 where address availability is not an issue.
B.通过启用路由桥接封装功能，所有用户都可以是同一子网的一部分。这是IPv4 over DSL最常见的部署方法，但在地址可用性不是问题的IPv6中，这可能不是最佳选择。
C. By terminating the PVC at Layer 3, each PVC has its own prefix. This is the approach that seems more suitable for IPv6 and is presented in Section 6.2.1.
C.通过在第3层终止PVC，每个PVC都有自己的前缀。这是一种似乎更适合IPv6的方法，在第6.2.1节中介绍。
None of these ways requires that the CPE (DSL modem) be upgraded.
所有这些方法都不需要升级CPE（DSL调制解调器）。
2. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened between each subscriber and the BRAS. The BRAS terminates the PPP sessions and provides Layer 3 connectivity between the subscriber and the ISP. This model is presented in Section 6.2.2.
2. PPP终止聚合（PTA）模型：在每个订户和BRA之间打开PPP会话。BRA终止PPP会话，并在用户和ISP之间提供第3层连接。第6.2.2节介绍了该模型。
3. Layer 2 Tunneling Protocol (L2TP) Access Aggregation (LAA) Model: PPP sessions are opened between each subscriber and the ISP Edge Router. The BRAS tunnels the subscriber PPP sessions to the ISP by encapsulating them into L2TPv2 [RFC2661] tunnels. This model is presented in Section 6.2.3.
3. 第二层隧道协议（L2TP）访问聚合（LAA）模型：在每个订户和ISP边缘路由器之间打开PPP会话。BRA通过将用户PPP会话封装到L2TPv2[RFC2661]隧道中，将其隧道传输到ISP。该模型见第6.2.3节。
In aggregation models, the BRAS terminates the subscriber PVCs and aggregates their connections before providing access to the ISP.
在聚合模型中，BRA在提供对ISP的访问之前终止订户PVC并聚合其连接。
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部署相匹配。本文介绍了这种方法
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.3节介绍了当前IPv4 over DSL宽带接入部署。在某些新的服务类型或服务需要证明其合理性的情况下，IPv4和IPv6网络逻辑架构可能会有所不同，如第6.2.4节所述。
In this scenario, the Ethernet frames from the Host or the Customer Premise Router are bridged over the PVC assigned to the subscriber.
在这种情况下，来自主机或客户端路由器的以太网帧通过分配给订户的PVC桥接。
Figure 6.2.1 describes the protocol architecture of this model.
图6.2.1描述了该模型的协议架构。
Customer Premise NAP NSP
|-------------------------| |---------------| |------------------|
+-----+ +-------+ +-----+ +--------+ +----------+
|Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP
+-----+ +-------+ |Modem| +--------+ | Router +=>Network
+-----+ +----------+
|----------------------------|
ATM
Customer Premise NAP NSP
|-------------------------| |---------------| |------------------|
+-----+ +-------+ +-----+ +--------+ +----------+
|Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP
+-----+ +-------+ |Modem| +--------+ | Router +=>Network
+-----+ +----------+
|----------------------------|
ATM
Figure 6.2.1
图6.2.1
In this scenario, the DSL modem and the entire NAP is Layer 3 unaware, so no changes are needed to support IPv6. The following devices have to be upgraded to dual stack: Host, Customer Router (if present), and Edge Router.
在这种情况下，DSL调制解调器和整个NAP是第3层不知道的，因此不需要更改以支持IPv6。必须将以下设备升级到双堆栈：主机、客户路由器（如果存在）和边缘路由器。
The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop.
主机或客户路由器将边缘路由器作为其第3层下一跳。
If there is no Customer Router, all the hosts on the subscriber site belong to the same /64 subnet that is statically configured on the Edge Router for that subscriber PVC. The hosts can use stateless auto-configuration or stateful DHCPv6-based configuration to acquire an address via the Edge Router.
如果没有客户路由器，则订阅服务器站点上的所有主机都属于在该订阅服务器的边缘路由器上静态配置的同一/64子网。主机可以使用无状态自动配置或基于状态DHCPv6的配置通过边缘路由器获取地址。
However, as manual configuration for each customer is a provisioning challenge, implementers are encouraged to develop mechanism(s) that automatically map the PVC (or some other customer-specific information) to an IPv6 subnet prefix, and advertise the customer-specific prefix to all the customers with minimal configuration.
但是，由于每个客户的手动配置都是一项资源调配挑战，因此鼓励实施者开发自动将PVC（或某些其他特定于客户的信息）映射到IPv6子网前缀的机制，并以最少的配置向所有客户公布特定于客户的前缀。
If a Customer Router is present:
如果存在客户路由器：
A. It is statically configured with an address on the /64 subnet between itself and the Edge Router, and with /64 prefixes on the interfaces connecting the hosts on the customer site. This is not a desired provisioning method being expensive and difficult to manage.
A.它在自身和边缘路由器之间的/64子网上静态配置一个地址，在连接客户站点上主机的接口上使用/64前缀。这不是一种理想的资源调配方法，因为其成本高昂且难以管理。
B. It can use its link-local address to communicate with the ER. It can also dynamically acquire, through stateless auto-configuration, the prefix for the link between itself and the ER. The later option allows it to contact a remote DHCPv6 server, if needed. This step is followed by a request via DHCP-PD for a prefix shorter than /64 that, in turn, is divided in /64s and assigned to its downstream interfaces.
B.它可以使用其链路本地地址与ER通信。它还可以通过无状态自动配置动态获取自身与ER之间链接的前缀。如果需要，后面的选项允许它联系远程DHCPv6服务器。此步骤之后，通过DHCP-PD请求短于/64的前缀，然后将其划分为/64并分配给其下游接口。
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.
边缘路由器为每个用户配置了/64前缀。每个PVC应能够将订户的DHCPv6请求中继到ISP网络中的DHCPv6服务器。为使用DHCP-PD的订户提供访问权限的PVC必须启用才能支持该功能。ISP网络的上行链路也配置了/64前缀。
The prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows as much summarization as possible at the Edge Router.
用于订户链路的前缀和通过DHCP-PD委托的前缀应以允许在边缘路由器上尽可能多地汇总的方式进行规划。
Other information of interest to the host, such as DNS, is provided through stateful DHCPv6 [RFC3315] and stateless DHCPv6 [RFC3736].
主机感兴趣的其他信息，如DNS，通过有状态DHCPv6[RFC3315]和无状态DHCPv6[RFC3736]提供。
The CPE devices are configured with a default route that points to the Edge Router. No routing protocols are needed on these devices, which generally have limited resources.
CPE设备配置有指向边缘路由器的默认路由。这些设备通常资源有限，不需要路由协议。
The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. The connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the Edge Router. For this reason, the static routes must also be redistributed. Prefix summarization should be done at the Edge Router.
边缘路由器运行NSP中使用的IPv6 IGP:OSPFv3或IS-IS。连接的前缀必须重新分配。如果使用DHCP-PD，则边缘路由器将通过每个委派前缀安装静态路由。因此，静态路由也必须重新分配。前缀摘要应该在边缘路由器上完成。
The PTA architecture relies on PPP-based protocols (PPPoA [RFC2364] and PPPoE [RFC2516]). The PPP sessions are initiated by Customer Premise Equipment and are terminated at the BRAS. The BRAS
PTA体系结构依赖于基于PPP的协议（PPPoA[RFC2364]和PPPoE[RFC2516]）。PPP会话由客户现场设备发起，并在BRA处终止。胸罩
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将用户通信量第3层路由到NSP边缘路由器。
When the NSP is also the NAP, the BRAS and NSP Edge Router could be the same piece of equipment and provide the above mentioned functionality.
当NSP也是NAP时，BRAS和NSP边缘路由器可以是同一设备，并提供上述功能。
There are two types of PPP encapsulations that can be leveraged with this model:
此模型可以利用两种类型的PPP封装：
A. Connection using PPPoA
A.使用PPPoA的连接
Customer Premise NAP NSP
|--------------------| |----------------------| |----------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
+-----+ +-------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
|--------------------------| +-----------+
PPP
Customer Premise NAP NSP
|--------------------| |----------------------| |----------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
+-----+ +-------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
|--------------------------| +-----------+
PPP
Figure 6.2.2.1
图6.2.2.1
The PPP sessions are initiated by the Customer Premise Equipment. The BRAS authenticates the subscriber against a local or a remote database. Once the session is established, the BRAS provides an address and maybe a DNS server to the user; this information is acquired from the subscriber profile or from a DHCP server.
PPP会话由客户场所设备发起。BRAS根据本地或远程数据库对订户进行身份验证。一旦会话建立，BRAS向用户提供一个地址，可能还有一个DNS服务器；此信息从订户配置文件或DHCP服务器获取。
This solution scales better then the Point-to-Point, but since there is only one PPP session per ATM PVC, the subscriber can choose a single ISP service at a time.
此解决方案比点对点扩展更好，但由于每个ATM PVC只有一个PPP会话，用户一次可以选择一个ISP服务。
B. Connection using PPPoE
B.使用PPPoE连接
Customer Premise NAP NSP
|--------------------------| |-------------------| |---------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
|
+-----+ +-------+ +--------+ +-----+----+ +-----------+
|Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +----------+ | Router +=>O
| | R
|--------------------------------| +-----------+ E
PPP
Customer Premise NAP NSP
|--------------------------| |-------------------| |---------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
|
+-----+ +-------+ +--------+ +-----+----+ +-----------+
|Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +----------+ | Router +=>O
| | R
|--------------------------------| +-----------+ E
PPP
Figure 6.2.2.2
图6.2.2.2
The operation of PPPoE is similar to PPPoA with the exception that with PPPoE multiple sessions can be supported over the same PVC, thus allowing the subscriber to connect to multiple services at the same time. The hosts can initiate the PPPoE sessions as well. It is important to remember that the PPPoE encapsulation reduces the IP MTU available for the customer traffic due to additional headers.
PPPoE的操作与PPPoA类似，但PPPoE可以在同一PVC上支持多个会话，从而允许用户同时连接到多个服务。主机也可以启动PPPoE会话。重要的是要记住，PPPoE封装由于额外的报头而减少了可用于客户流量的IP MTU。
The network design and operation of the PTA model is the same, regardless of the PPP encapsulation type used.
无论使用何种PPP封装类型，PTA模型的网络设计和操作都是相同的。
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.
在这种情况下，BRA支持第3层，必须升级以支持IPv6。由于BRA终止PPP会话，它必须支持使用IPv6实现这些PPP协议。以下设备必须升级到双堆栈：主机、客户路由器（如果存在）、BRAS和边缘路由器。
The BRAS terminates the PPP sessions and provides the subscriber with an IPv6 address from the defined pool for that profile. The subscriber profile for authorization and authentication can be located on the BRAS or on an Authentication, Authorization, and Accounting (AAA) server. The Hosts or the Customer Routers have the BRAS as their Layer 3 next hop.
BRAS终止PPP会话，并从为该配置文件定义的池中向订阅者提供IPv6地址。用于授权和身份验证的订户配置文件可以位于BRAS或身份验证、授权和记帐（AAA）服务器上。主机或客户路由器将BRA作为其第3层下一跳。
The PPP session can be initiated by a host or by a Customer Router. In the latter case, once the session is established with the BRAS and an address is negotiated for the uplink to the BRAS, DHCP-PD can be used to acquire prefixes for the Customer Router other interfaces.
PPP会话可以由主机或客户路由器发起。在后一种情况下，一旦建立了与BRA的会话并协商了用于到BRA的上行链路的地址，就可以使用DHCP-PD为客户路由器和其他接口获取前缀。
The BRAS has to be enabled to support DHCP-PD and to relay the DHCPv6 requests of the hosts on the subscriber sites.
必须启用BRA以支持DHCP-PD，并在订户站点上中继主机的DHCPv6请求。
The BRAS has /64 prefixes configured on the link to the Edge router. The Edge Router links are also configured with /64 prefixes to provide connectivity to the rest of the ISP network.
BRAS在到边缘路由器的链路上配置了/64前缀。边缘路由器链路还配置了/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.
主机感兴趣的其他信息，如DNS，通过有状态[RFC3315]和无状态[RFC3736]DHCPv6提供。
The CPE devices are configured with a default route that points to the BRAS router. No routing protocols are needed on these devices, which generally have limited resources.
CPE设备配置有指向BRAS路由器的默认路由。这些设备通常资源有限，不需要路由协议。
The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the addresses assigned to the PPP sessions are represented as connected host routes, connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the Edge Router. For this reason, the static routes must also be redistributed. Prefix summarization should be done at the BRAS.
BRAS向边缘路由器运行IGP：OSPFv3或IS-IS。由于分配给PPP会话的地址表示为连接的主机路由，因此必须重新分配连接的前缀。如果使用DHCP-PD，则边缘路由器将通过每个委派前缀安装静态路由。因此，静态路由也必须重新分配。前缀摘要应该在BRAS中完成。
The Edge Router is running the IGP used in the ISP network: OSPFv3 or IS-IS.
边缘路由器正在运行ISP网络中使用的IGP：OSPFv3或is-is。
A separation between the routing domains of the ISP and the Access Provider is recommended if they are managed independently. Controlled redistribution will be needed between the Access Provider IGP and the ISP IGP.
如果ISP和访问提供商的路由域是独立管理的，建议将它们分开。接入提供商IGP和ISP IGP之间需要有控制的重新分配。
In the LAA model, the BRAS forwards the CPE initiated session to the ISP over an L2TPv2 tunnel established between the BRAS and the Edge Router. In this case, the authentication, authorization, and subscriber configuration are performed by the ISP itself. There are two types of PPP encapsulations that can be leveraged with this model:
在LAA模型中，BRA通过在BRA和边缘路由器之间建立的L2TPv2隧道将CPE发起的会话转发给ISP。在这种情况下，身份验证、授权和订户配置由ISP自己执行。此模型可以利用两种类型的PPP封装：
A. Connection via PPPoA
A.通过PPPoA连接
Customer Premise NAP NSP
|--------------------| |----------------------| |----------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
|----------------------------------------|
PPP
|------------|
L2TPv2
Customer Premise NAP NSP
|--------------------| |----------------------| |----------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
|----------------------------------------|
PPP
|------------|
L2TPv2
Figure 6.2.3.1
图6.2.3.1
B. Connection via PPPoE
B.通过PPPoE连接
Customer Premise NAP NSP
|--------------------------| |--------------------| |---------------|
+-----------+
| AAA |
+------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +----+------+
|Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +----------+ | Router +=>O
| | R
+-----------+ E
|-----------------------------------------------|
PPP
|--------------|
L2TPv2
Customer Premise NAP NSP
|--------------------------| |--------------------| |---------------|
+-----------+
| AAA |
+------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +----+------+
|Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +----------+ | Router +=>O
| | R
+-----------+ E
|-----------------------------------------------|
PPP
|--------------|
L2TPv2
Figure 6.2.3.2
图6.2.3.2
The network design and operation of the PTA model is the same, regardless of the PPP encapsulation type used.
无论使用何种PPP封装类型，PTA模型的网络设计和操作都是相同的。
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.
在此场景中，BRA通过建立的L2TPv2隧道将订户发起的PPP会话转发到L2TP网络服务器（LNS），即ISP网络中的聚合点。L2TP访问集中器（LAC）和LNS之间的L2TPv2隧道可以通过IPv6或IPv4运行。这些功能必须在BRAS上得到支持。以下设备必须升级到双堆栈：主机、客户路由器和边缘路由器。如果隧道是通过IPv6设置的，则必须将BRA升级到双堆栈。
The Edge Router terminates the PPP sessions and provides the subscriber with an IPv6 address from the defined pool for that profile. The subscriber profile for authorization and authentication can be located on the Edge Router or on an AAA server. The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop.
边缘路由器终止PPP会话，并从为该配置文件定义的池向订户提供IPv6地址。用于授权和身份验证的订户配置文件可以位于边缘路由器或AAA服务器上。主机或客户路由器将边缘路由器作为其第3层下一跳。
The PPP session can be initiated by a host or by a Customer Router. In the latter case, once the session is established with the Edge Router, DHCP-PD can be used to acquire prefixes for the Customer Router interfaces. The Edge Router has to be enabled to support DHCP-PD and to relay the DHCPv6 requests generated by the hosts on the subscriber sites.
PPP会话可以由主机或客户路由器发起。在后一种情况下，一旦与边缘路由器建立会话，DHCP-PD可用于获取客户路由器接口的前缀。必须启用边缘路由器以支持DHCP-PD，并中继订户站点上主机生成的DHCPv6请求。
The BRAS has a /64 prefix configured on the link to the Edge Router. The Edge Router links are also configured with /64 prefixes to provide connectivity to the rest of the ISP network. Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
BRAS在到边缘路由器的链路上配置了/64前缀。边缘路由器链路还配置了/64前缀，以提供与ISP网络其余部分的连接。主机感兴趣的其他信息，如DNS，通过有状态[RFC3315]和无状态[RFC3736]DHCPv6提供。
It is important to note here a significant difference between this deployment for IPv6 versus IPv4. In the case of IPv4, the customer router or CPE can end up on any Edge Router (acting as LNS), where the assumption is that there are at least two of them for redundancy purposes. Once authenticated, the customer will be given an address from the IP pool of the ER (LNS) it connected to. This allows the ERs (LNSs) to aggregate the addresses handed out to the customers. In the case of IPv6, an important constraint that likely will be enforced is that the customer should keep its own address, regardless of the ER (LNS) it connects to. This could significantly reduce the prefix aggregation capabilities of the ER (LNS). This is different than the current IPv4 deployment where addressing is dynamic in nature, and the same user can get different addresses depending on the LNS it ends up connecting to.
这里需要注意的是，IPv6与IPv4的部署之间存在显著差异。在IPv4的情况下，客户路由器或CPE可以在任何边缘路由器（充当LN）上结束，其中假设至少有两个用于冗余目的。一旦通过身份验证，客户将从其连接的ER（LNS）的IP池中获得一个地址。这允许ERs（LNS）汇总分发给客户的地址。在IPv6的情况下，可能会实施的一个重要约束是，客户应该保留自己的地址，而不管它连接到哪个ER（LN）。这可能会显著降低ER（LNS）的前缀聚合能力。这与当前IPv4部署不同，当前IPv4部署的寻址本质上是动态的，同一用户可以根据其最终连接到的LN获得不同的地址。
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).
一种可能的解决方案是确保给定的BRA始终连接到相同的ER（LNS），除非LNS关闭。这意味着来自给定前缀范围的客户将始终连接到同一ER（主，如果是向上的，或辅助，如果不是）。每个ER（LNS）都可以在其路由协议配置中为其作为主要ER（LNS）的前缀以及作为次要ER（LNS）的前缀携带摘要语句。这样一来，只要前缀在ER（LNS）上变为“活动”，就会对其进行汇总。
The CPE devices are configured with a default route that points to the Edge Router that terminates the PPP sessions. No routing protocols are needed on these devices, which generally have limited resources.
CPE设备配置有指向终止PPP会话的边缘路由器的默认路由。这些设备通常资源有限，不需要路由协议。
The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. Different processes should be used if the NAP and the NSP are managed by different organizations. In this case, controlled redistribution should be enabled between the two domains.
BRAS运行到边缘路由器的IPv6 IGP:OSPFv3或IS-IS。如果NAP和NSP由不同的组织管理，则应使用不同的流程。在这种情况下，应在两个域之间启用受控的重新分发。
The Edge Router is running the IPv6 IGP used in the ISP network: OSPFv3 or IS-IS.
边缘路由器正在运行ISP网络中使用的IPv6 IGP:OSPFv3或is-is。
It was recommended throughout this section that the IPv6 service implementation should map the existing IPv4 one. This approach simplifies manageability and minimizes training needed for personnel operating the network. In certain circumstances such mapping is not feasible. This typically becomes the case when a Service Provider plans to expand its service offering with the new IPv6 deployed infrastructure. If this new service is not well supported in a network design such as the one used for IPv4, then a different design might be used for IPv6.
本节建议IPv6服务实现应映射现有的IPv4服务。这种方法简化了可管理性，最大限度地减少了网络操作人员所需的培训。在某些情况下，这种映射是不可行的。当服务提供商计划使用新的IPv6部署基础设施扩展其服务产品时，通常会出现这种情况。如果此新服务在网络设计（如用于IPv4的网络设计）中没有得到很好的支持，那么IPv6可能会使用不同的设计。
An example of such circumstances is that of a provider using an LAA design for its IPv4 services. In this case all the PPP sessions are bundled and tunneled across the entire NAP infrastructure which is made of multiple BRAS routers, aggregation routers etc. The end point of these tunnels is the ISP Edge Router. If the provider decides to offer multicast services over such a design, it will face the problem of NAP resources being over utilized. The multicast traffic can be replicated only at the end of the tunnels by the Edge Router and the copies for all the subscribers are carried over the entire NAP.
这种情况的一个例子是提供商对其IPv4服务使用LAA设计。在这种情况下，所有PPP会话都捆绑在整个NAP基础设施（由多个BRAS路由器、聚合路由器等组成）上并通过隧道传输。这些隧道的终点是ISP边缘路由器。如果提供商决定通过这种设计提供多播服务，它将面临NAP资源被过度利用的问题。多播流量只能由边缘路由器在隧道末端复制，所有订阅者的副本都会在整个NAP中传输。
A Modified Point-to-Point (as described in Section 6.2.4.2) or PTA model is more suitable to support multicast services because the packet replication can be done closer to the destination at the BRAS. Such topology saves NAP resources.
修改后的点对点（如第6.2.4.2节所述）或PTA模型更适合支持多播服务，因为包复制可以在BRA的目的地附近完成。这样的拓扑可以节省NAP资源。
In this sense, IPv6 deployment can be viewed as an opportunity to build an infrastructure that might better support the expansion of services. In this case, an SP using the LAA design for its IPv4 services might choose a modified Point-to-Point or PTA design for IPv6.
从这个意义上讲，IPv6部署可以被视为构建基础设施的机会，该基础设施可能更好地支持服务的扩展。在这种情况下，为其IPv4服务使用LAA设计的SP可能会为IPv6选择修改的点对点或PTA设计。
The coexistence of the two PPP-based models, PTA and LAA, is relatively straightforward. The PPP sessions are terminated on different network devices for the IPv4 and IPv6 services. The PPP sessions for the existing IPv4 service deployed in an LAA model are terminated on the Edge Router. The PPP sessions for the new IPv6 service deployed in a PTA model are terminated on the BRAS.
PTA和LAA这两种基于PPP的模式共存相对简单。PPP会话在IPv4和IPv6服务的不同网络设备上终止。LAA模型中部署的现有IPv4服务的PPP会话在边缘路由器上终止。在PTA模型中部署的新IPv6服务的PPP会话在BRA上终止。
The logical design for IPv6 and IPv4 in this hybrid model is presented in Figure 6.2.4.1.
图6.2.4.1给出了该混合模型中IPv6和IPv4的逻辑设计。
IPv6 |--------------------------|
PPP +-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
IPv6 |--------------------------|
PPP +-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
Figure 6.2.4.1
图6.2.4.1
In this particular scenario the Point-to-Point model used for the IPv6 service is a modified version of the model described in section 6.2.1.
在此特定场景中，用于IPv6服务的点对点模型是第6.2.1节中描述的模型的修改版本。
For the IPv4 service in the LAA model, the PVCs are terminated on the BRAS and PPP sessions are terminated on the Edge Router (LNS). For IPv6 service in the Point-to-Point model, the PVCs are terminated at the Edge Router as described in Section 6.2.1. In this hybrid model, the Point-to-Point link could be terminated on the BRAS, a NAP-owned device. The IPv6 traffic is then routed through the NAP network to the NSP. In order to have this hybrid model, the BRAS has to be upgraded to a dual-stack router. The functionalities of the Edge Router, as described in Section 6.2.1, are now implemented on the BRAS.
对于LAA模型中的IPv4服务，PVC在BRA上终止，PPP会话在边缘路由器（LNS）上终止。对于点到点模型中的IPv6服务，PVC在边缘路由器处终止，如第6.2.1节所述。在这种混合模式中，点对点链路可以在BRAS（NAP拥有的设备）上终止。IPv6流量随后通过NAP网络路由到NSP。为了拥有这种混合模式，BRAS必须升级为双栈路由器。如第6.2.1节所述，边缘路由器的功能现已在BRAS上实现。
The other aspect of this deployment model is the fact that the BRAS has to be capable of distinguishing between the IPv4 PPP traffic that has to be bridged across the L2TPv2 tunnel and the IPv6 packets that have to be routed to the NSP. The IPv6 Routing and Bridging Encapsulation (RBE) has to be enabled on all interfaces with PVCs supporting both IPv4 and IPv6 services in this hybrid design.
此部署模型的另一个方面是，BRA必须能够区分必须跨L2TPv2隧道桥接的IPv4 PPP流量和必须路由到NSP的IPv6数据包。在这种混合设计中，必须在具有支持IPv4和IPv6服务的PVC的所有接口上启用IPv6路由和桥接封装（RBE）。
The logical design for IPv6 and IPv4 in this hybrid model is presented in Figure 6.2.4.2.
此混合模型中IPv6和IPv4的逻辑设计如图6.2.4.2所示。
IPv6 |----------------|
ATM +-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
IPv6 |----------------|
ATM +-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
Figure 6.2.4.2
图6.2.4.2
The deployment of IPv6 multicast services relies on MLD, identical to IGMP in IPv4 and on PIM for routing. ASM (Any Source Multicast) and SSM (Single Source Multicast) service models operate almost the same as in IPv4. Both have the same benefits and disadvantages as in IPv4. Nevertheless, the larger address space and the scoped address architecture provide major benefits for multicast IPv6. Through RFC 3306, the large address space provides the means to assign global
IPv6多播服务的部署依赖于MLD，与IPv4中的IGMP相同，并依赖PIM进行路由。ASM（任意源多播）和SSM（单源多播）服务模型的运行方式与IPv4中几乎相同。两者都有与IPv4相同的优点和缺点。然而，更大的地址空间和作用域地址体系结构为多播IPv6提供了主要优势。通过RFC3306，大地址空间提供了分配全局地址的方法
multicast group addresses to organizations or users that were assigned unicast prefixes. It is a significant improvement with respect to the IPv4 GLOP mechanism [RFC3180].
分配了单播前缀的组织或用户的多播组地址。这是对IPv4 GLOP机制的重大改进[RFC3180]。
This facilitates the deployment of multicast services. The discussion of this section applies to all the multicast sections in the document.
这有助于多播服务的部署。本节的讨论适用于文档中的所有多播部分。
Any Source Multicast (ASM) is useful for Service Providers that intend to support the forwarding of multicast traffic of their customers. It is based on the Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol and it is more complex to manage because of the use of Rendezvous Points (RPs). With IPv6, static RP and Bootstrap Router [BSR] can be used for RP-to-group mapping similar to IPv4. Additionally, the larger IPv6 address space allows for building up of group addresses that incorporate the address of the RP. This RP-to-group mapping mechanism is called Embedded RP and is specific to IPv6.
任何源多播（ASM）对于打算支持其客户的多播流量转发的服务提供商都很有用。它基于协议无关的多播稀疏模式（PIM-SM）协议，由于使用了集合点（RPs），因此管理起来更加复杂。使用IPv6，静态RP和引导路由器[BSR]可用于RP到组的映射，类似于IPv4。此外，更大的IPv6地址空间允许建立包含RP地址的组地址。此RP到组映射机制称为嵌入式RP，特定于IPv6。
In inter-domain deployments, Multicast Source Discovery Protocol (MSDP) [RFC3618] is an important element of IPv4 PIM-SM deployments. MSDP is meant to be a solution for the exchange of source registration information between RPs in different domains. This solution was intended to be temporary. This is one of the reasons why it was decided not to implement MSDP in IPv6 [IPv6-Multicast].
在域间部署中，多播源发现协议（MSDP）[RFC3618]是IPv4 PIM-SM部署的一个重要元素。MSDP是用于在不同域中的RPs之间交换源注册信息的解决方案。该解决方案是临时性的。这是决定不在IPv6[IPv6多播]中实现MSDP的原因之一。
For multicast reachability across domains, Embedded RP can be used. As Embedded RP provides roughly the same capabilities as MSDP, but in a slightly different way, the best management practices for ASM multicast with embedded RP still remain to be developed.
对于跨域的多播可达性，可以使用嵌入式RP。由于嵌入式RP提供的功能与MSDP大致相同，但方式略有不同，因此使用嵌入式RP的ASM多播的最佳管理实践仍有待开发。
Based on PIM-SSM, the Source-Specific Multicast deployments do not need an RP or related protocols (such as BSR or MSDP), but rely on the listeners to know the source of the multicast traffic they plan to receive. The lack of RP makes SSM not only simpler to operate, but also robust; it is not impacted by RP failures or inter-domain constraints. It also has a higher level of security (no RP to be targeted by attacks). For more discussions on the topic of IPv6 multicast, see [IPv6-Multicast].
基于PIM-SSM，源特定的多播部署不需要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得到了很好的支持，PIM-SSM非常简单且易于实现
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.
管理必须在整个SP网络中启用PIM-SSM。PIM-SSM支持需要MLDv2。供应商可以选择实现允许路由器将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加入/离开发送到其第3层下一跳，无论是BRAS还是边缘路由器。在CPR上启用此功能时，应考虑其有限的资源。另一个选择是CPR支持MLD代理路由。
The router that is the Layer 3 next hop for the subscriber (BRAS in the PTA model or the Edge Router in the LAA and Point-to-Point model) has to be enabled to support MLDv1 and MLDv2 in order to process the requests coming from subscribers without CPRs. It has to be enabled for PIM-SSM in order to receive joins/leaves from customer routers and send joins/leaves to the next hop towards the multicast source (Edge Router or the NSP core).
作为订户的第3层下一跳的路由器（PTA模型中的BRA或LAA和点对点模型中的边缘路由器）必须启用以支持MLDv1和MLDv2，以便处理来自没有CPR的订户的请求。必须为PIM-SSM启用该功能，以便从客户路由器接收加入/离开，并向多播源（边缘路由器或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能够控制用户对服务的访问，并对提供的内容进行计费。应进一步研究支持这些职能的替代机制。
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层下一跳的路由器（PTA模型中的BRA或LAA和点对点模型中的边缘路由器）上特别相关，以便管理多个用户之间共享的资源，可能使用各种服务级别协议。
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或边缘路由器上，必须配置面向用户的接口，以监控入站客户流量，并根据服务水平协议（SLA）调整出站客户流量。交通分类和标记也应
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.
在离用户最近的路由器（第3层）上完成，以支持各种类型的客户流量（数据、语音和视频），并优化使用基础设施资源。每个提供商（NAP、NSP）都可以实施自己的QoS策略和服务，以便在NAP和NSP之间的边界处执行重新分类和标记，以确保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头字段进行分类。
There are limited changes that have to be done for CPEs in order to enhance security. The privacy extensions for auto-configuration [RFC3041] should be used by the hosts. ISPs can track the prefixes it assigns to subscribers relatively easily. If, however, the ISPs are required by regulations to track their users at a /128 address level, the privacy extensions may be implemented in parallel with network management tools that could provide traceability of the hosts. IPv6 firewall functions should be enabled on the hosts or CPR, if present.
为了增强安全性，必须对CPE进行有限的更改。主机应使用自动配置的隐私扩展[RFC3041]。ISP可以相对容易地跟踪分配给订阅者的前缀。但是，如果法规要求ISP在a/128地址级别跟踪其用户，则隐私扩展可与网络管理工具并行实施，以提供主机的可跟踪性。应在主机或CPR（如果存在）上启用IPv6防火墙功能。
The ISP provides security against attacks that come from its own subscribers but it could also implement security services that protect its subscribers from attacks sourced from 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].
作为用户（BRA或边缘路由器）的第3层下一跳的设备应保护网络和其他用户免受提供商客户之一的攻击。因此，uRPF和ACL应该在面向订阅者的所有接口上使用。应根据IPv6[IPv6安全]的操作要求实施过滤。
The BRAS and the Edge Router should protect their processing resources against floods of valid customer control traffic such as: Router and Neighbor Solicitations, and MLD Requests. Rate limiting should be implemented on all subscriber-facing interfaces. The emphasis should be placed on multicast-type traffic, as it is most often used by the IPv6 control plane.
BRA和边缘路由器应保护其处理资源不受有效客户控制流量的影响，例如：路由器和邻居请求，以及MLD请求。应在所有面向订户的接口上实施速率限制。重点应放在多播类型的流量上，因为IPv6控制平面最常用多播类型的流量。
All other security features used with the IPv4 service should be similarly applied to IPv6 as well.
与IPv4服务一起使用的所有其他安全功能也应类似地应用于IPv6。
The necessary instrumentation (such as MIB modules, NetFlow Records, etc.) should be available for IPv6.
IPv6应提供必要的工具（如MIB模块、NetFlow记录等）。
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进行连接，则可以通过IPv4进行SNMP传输。这意味着对现有网络管理实践和流程的改动最小。还可以通过IPv6实现传输，如果网络中只存在IPv6孤岛，则可能有必要这样做。管理应用程序可能正在属于NSP核心网络域的主机上运行。网络管理应用程序应以类似于IPv4的方式处理IPv6；但是，它们还应该支持IPv6特有的功能（例如邻居监视）。
In some cases, service providers manage equipment located on customers' LANs. The management of equipment at customers' LANs is out of scope of this memo.
在某些情况下，服务提供商管理位于客户局域网上的设备。客户局域网上的设备管理不在本备忘录的范围内。
This section describes the IPv6 deployment options in currently deployed Broadband Ethernet Access Networks.
本节介绍当前部署的宽带以太网接入网络中的IPv6部署选项。
In environments that support the infrastructure deploying RJ-45 or fiber (Fiber to the Home (FTTH) service) to subscribers, 10/100 Mbps Ethernet broadband services can be provided. Such services are generally available in metropolitan areas in multi-tenant buildings where an Ethernet infrastructure can be deployed in a cost-effective manner. In such environments, Metro-Ethernet services can be used to provide aggregation and uplink to a Service Provider.
在支持向用户部署RJ-45或光纤（光纤到户（FTTH）服务）的基础设施的环境中，可以提供10/100 Mbps以太网宽带服务。这种服务通常在多租户建筑的大都市地区提供，在那里可以以经济高效的方式部署以太网基础设施。在这种环境中，城域以太网服务可用于向服务提供商提供聚合和上行链路。
The following network elements are typical of an Ethernet network:
以下网元是以太网的典型网络：
Access Switch: It is used as a Layer 2 access device for subscribers.
接入交换机：用作用户的第二层接入设备。
Customer Premise Router: It is used to provide Layer 3 services for customer premise networks.
用户端路由器：用于为用户端网络提供第三层服务。
Aggregation Ethernet Switches: Aggregates multiple subscribers.
聚合以太网交换机：聚合多个订户。
Broadband Remote Access Server (BRAS)
宽带远程访问服务器（BRAS）
Edge Router (ER)
边缘路由器（ER）
Figure 7.1 depicts all the network elements mentioned.
图7.1描述了提及的所有网络元素。
Customer Premise | Network Access Provider | Network Service Provider CP NAP NSP
客户场所|网络接入提供商|网络服务提供商CP NAP NSP
+-----+ +------+ +------+ +--------+
|Hosts|--|Router| +-+ BRAS +--+ Edge | ISP
+-----+ +--+---+ | | | | Router +===> Network
| | +------+ +--------+
+--+----+ |
|Access +-+ |
|Switch | | |
+-------+ | +------+ |
+--+Agg E | |
+-------+ |Switch+-+
+-----+ |Access | +--+ |
|Hosts|--+Switch +-+ +------+
+-----+ +-------+
+-----+ +------+ +------+ +--------+
|Hosts|--|Router| +-+ BRAS +--+ Edge | ISP
+-----+ +--+---+ | | | | Router +===> Network
| | +------+ +--------+
+--+----+ |
|Access +-+ |
|Switch | | |
+-------+ | +------+ |
+--+Agg E | |
+-------+ |Switch+-+
+-----+ |Access | +--+ |
|Hosts|--+Switch +-+ +------+
+-----+ +-------+
Figure 7.1
图7.1
The logical topology and design of Broadband Ethernet Networks are very similar to DSL Broadband Networks discussed in Section 6.
宽带以太网的逻辑拓扑和设计与第6节中讨论的DSL宽带网络非常相似。
It is worth noting that the general operation, concepts and recommendations described in this section apply similarly to a HomePNA-based network environment. In such an environment, some of the network elements might be differently named.
值得注意的是，本节介绍的一般操作、概念和建议同样适用于基于HomePNA的网络环境。在这种环境中，某些网络元素的名称可能不同。
There are three main design approaches to providing IPv4 connectivity over an Ethernet infrastructure:
通过以太网基础设施提供IPv4连接有三种主要设计方法：
A. Point-to-Point Model: Each subscriber connects to the network Access switch over RJ-45 or fiber links. Each subscriber is assigned a unique VLAN on the access switch. The VLAN can be terminated at the BRAS or at the Edge Router. The VLANs are 802.1Q trunked to the Layer 3 device (BRAS or Edge Router).
A.点对点模式：每个用户通过RJ-45或光纤链路连接到网络接入交换机。在接入交换机上为每个订户分配一个唯一的VLAN。VLAN可以在BRA或边缘路由器处终止。VLAN是802.1Q中继到第3层设备（BRAS或边缘路由器）。
This model is presented in Section 7.2.1.
该模型见第7.2.1节。
B. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened between each subscriber and the BRAS. The BRAS terminates the PPP sessions and provides Layer 3 connectivity between the subscriber and the ISP.
B.PPP终止聚合（PTA）模型：在每个订户和BRA之间打开PPP会话。BRA终止PPP会话，并在用户和ISP之间提供第3层连接。
This model is presented in Section 7.2.2.
第7.2.2节介绍了该模型。
C. L2TPv2 Access Aggregation (LAA) Model: PPP sessions are opened between each subscriber and the ISP termination devices. The BRAS tunnels the subscriber PPP sessions to the ISP by encapsulating them into L2TPv2 tunnels.
C.L2TPv2访问聚合（LAA）模型：在每个订户和ISP终端设备之间打开PPP会话。BRA通过将用户PPP会话封装到L2TPv2隧道中，将其隧道传输到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.
在聚合模型中，BRA在提供对ISP的访问之前终止订户VLAN并聚合其连接。
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部署相匹配。第7.2.1-7.2.3节介绍了这种方法，其中描述了当前部署的IPv4 over Ethernet宽带接入部署。在某些情况下，新的服务类型或服务需求证明了这一点，IPv4和IPv6网络架构可能会有所不同，如第7.2.4节所述。
In this scenario, the Ethernet frames from the Host or the Customer Premise Router are bridged over the VLAN assigned to the subscriber.
在这种情况下，来自主机或客户端路由器的以太网帧通过分配给订户的VLAN桥接。
Figure 7.2.1 describes the protocol architecture of this model.
图7.2.1描述了该模型的协议架构。
| Customer Premise | | NAP | NSP |
| Customer Premise | | NAP | NSP |
+-----+ +------+ +------+ +--------+ +----------+
|Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP
+-----+ +------+ |Switch| +--------+ 802.1Q | Router +=>Network
+------+ +----------+
+-----+ +------+ +------+ +--------+ +----------+
|Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP
+-----+ +------+ |Switch| +--------+ 802.1Q | Router +=>Network
+------+ +----------+
|----------------------------|
Ethernet/VLANs
|----------------------------|
Ethernet/VLANs
Figure 7.2.1
图7.2.1
In this scenario, the Access Switch is on the customer site and the entire NAP is Layer 3 unaware, so no changes are needed to support IPv6. The following devices have to be upgraded to dual stack: Host, Customer Router, and Edge Router.
在这种情况下，访问交换机位于客户站点上，而整个NAP是第3层不知道的，因此不需要更改以支持IPv6。以下设备必须升级到双堆栈：主机、客户路由器和边缘路由器。
The Access switches might need upgrades to support certain IPv6- related features such as MLD Snooping.
接入交换机可能需要升级以支持某些与IPv6相关的功能，如MLD窥探。
The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop. If there is no Customer Router all the hosts on the subscriber site belong to the same /64 subnet that is statically configured on the Edge Router for that subscriber VLAN. The hosts can use stateless auto-configuration or stateful DHCPv6-based configuration to acquire an address via the Edge Router.
主机或客户路由器将边缘路由器作为其第3层下一跳。如果没有客户路由器，则订阅服务器站点上的所有主机都属于在该订阅服务器VLAN的边缘路由器上静态配置的同一/64子网。主机可以使用无状态自动配置或基于状态DHCPv6的配置通过边缘路由器获取地址。
However, as manual configuration for each customer is a provisioning challenge, implementations are encouraged to develop mechanism(s) that automatically map the VLAN (or some other customer-specific information) to an IPv6 subnet prefix, and advertise the customer-specific prefix to all the customers with minimal configuration.
但是，由于每个客户的手动配置都是一项资源调配挑战，因此鼓励实施开发自动将VLAN（或某些其他特定于客户的信息）映射到IPv6子网前缀的机制，并以最少的配置向所有客户公布特定于客户的前缀。
If a Customer Router is present:
如果存在客户路由器：
A. It is statically configured with an address on the /64 subnet between itself and the Edge Router, and with /64 prefixes on the interfaces connecting the hosts on the customer site. This is not a desired provisioning method, being expensive and difficult to manage.
A.它在自身和边缘路由器之间的/64子网上静态配置一个地址，在连接客户站点上主机的接口上使用/64前缀。这不是一种理想的资源调配方法，成本高昂且难以管理。
B. It can use its link-local address to communicate with the ER. It can also dynamically acquire, through stateless auto-configuration, the address for the link between itself and the ER. This step is followed by a request via DHCP-PD for a prefix shorter than /64 that in turn is divided in /64s and assigned to its interfaces connecting the hosts on the customer site.
B.它可以使用其链路本地地址与ER通信。它还可以通过无状态自动配置动态获取自身与ER之间的链接地址。此步骤之后，通过DHCP-PD请求短于/64的前缀，该前缀被划分为/64，并分配给连接客户站点上主机的接口。
The Edge Router has a /64 prefix configured for each subscriber VLAN. Each VLAN should be enabled to relay DHCPv6 requests from the subscribers to DHCPv6 servers in the ISP network. The VLANs providing access for subscribers that use DHCP-PD have to be enabled to support the feature. The uplink to the ISP network is configured with a /64 prefix as well.
边缘路由器为每个订户VLAN配置了/64前缀。应启用每个VLAN，以将订户的DHCPv6请求中继到ISP网络中的DHCPv6服务器。必须启用为使用DHCP-PD的订阅者提供访问权限的VLAN以支持该功能。ISP网络的上行链路也配置了/64前缀。
The prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows as much summarization as possible at the Edge Router.
用于订户链路的前缀和通过DHCP-PD委托的前缀应以允许在边缘路由器上尽可能多地汇总的方式进行规划。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
主机感兴趣的其他信息，如DNS，通过有状态[RFC3315]和无状态[RFC3736]DHCPv6提供。
The CPE devices are configured with a default route that points to the Edge Router. No routing protocols are needed on these devices, which generally have limited resources.
CPE设备配置有指向边缘路由器的默认路由。这些设备通常资源有限，不需要路由协议。
The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. The connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the Edge Router. For this reason, the static routes must also be redistributed. Prefix summarization should be done at the Edge Router.
边缘路由器运行NSP中使用的IPv6 IGP:OSPFv3或IS-IS。连接的前缀必须重新分配。如果使用DHCP-PD，则边缘路由器将通过每个委派前缀安装静态路由。因此，静态路由也必须重新分配。前缀摘要应该在边缘路由器上完成。
The PTA architecture relies on PPP-based protocols (PPPoE). The PPP sessions are initiated by Customer Premise Equipment and are terminated at the BRAS. The BRAS authorizes the session, authenticates the subscriber, and provides an IP address on behalf of the ISP. The BRAS then does Layer 3 routing of the subscriber traffic to the NSP Edge Router.
PTA体系结构依赖于基于PPP的协议（PPPoE）。PPP会话由客户现场设备发起，并在BRA处终止。BRAS授权会话，认证用户，并代表ISP提供IP地址。然后，BRAS将用户通信量第3层路由到NSP边缘路由器。
When the NSP is also the NAP, the BRAS and NSP Edge Router could be the same piece of equipment and provide the above mentioned functionality.
当NSP也是NAP时，BRAS和NSP边缘路由器可以是同一设备，并提供上述功能。
The PPPoE logical diagram in an Ethernet Broadband Network is shown in Fig 7.2.2.1.
以太网宽带网络中的PPPoE逻辑图如图7.2.2.1所示。
| Customer Premise | | NAP | | NSP |
| Customer Premise | | NAP | | NSP |
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
+-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O
|---------------- PPP ----------------| | | R
+-----------+ E
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
+-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O
|---------------- PPP ----------------| | | R
+-----------+ E
Figure 7.2.2.1
图7.2.2.1
The PPP sessions are initiated by the Customer Premise Equipment (Host or Router). The BRAS authenticates the subscriber against a local or remote database. Once the session is established, the BRAS provides an address and maybe a DNS server to the user; this information is acquired from the subscriber profile or a DHCP server.
PPP会话由客户场所设备（主机或路由器）发起。BRAS根据本地或远程数据库对订户进行身份验证。一旦会话建立，BRAS向用户提供一个地址，可能还有一个DNS服务器；此信息从订户配置文件或DHCP服务器获取。
This model allows for multiple PPPoE sessions to be supported over the same VLAN, thus allowing the subscriber to connect to multiple services at the same time. The hosts can initiate the PPPoE sessions as well. It is important to remember that the PPPoE encapsulation reduces the IP MTU available for the customer traffic.
该模型允许在同一VLAN上支持多个PPPoE会话，从而允许订户同时连接到多个服务。主机也可以启动PPPoE会话。重要的是要记住，PPPoE封装减少了可用于客户流量的IP MTU。
In this scenario, the BRAS is Layer 3 aware and has to be upgraded to support IPv6. Since the BRAS terminates the PPP sessions, it has to support PPPoE with IPv6. The following devices have to be upgraded to dual stack: Host, Customer Router (if present), BRAS and Edge Router.
在这种情况下，BRA支持第3层，必须升级以支持IPv6。由于BRA终止PPP会话，因此它必须支持带有IPv6的PPPoE。以下设备必须升级到双堆栈：主机、客户路由器（如果存在）、BRAS和边缘路由器。
The BRAS terminates the PPP sessions and provides the subscriber with an IPv6 address from the defined pool for that profile. The subscriber profile for authorization and authentication can be located on the BRAS, or on an AAA server. The Hosts or the Customer Routers have the BRAS as their Layer 3 next hop.
BRAS终止PPP会话，并从为该配置文件定义的池中向订阅者提供IPv6地址。用于授权和身份验证的订户配置文件可以位于BRA或AAA服务器上。主机或客户路由器将BRA作为其第3层下一跳。
The PPP session can be initiated by a host or by a Customer Router. In the latter case, once the session is established with the BRAS, DHCP-PD can be used to acquire prefixes for the Customer Router interfaces. The BRAS has to be enabled to support DHCP-PD and to relay the DHCPv6 requests of the hosts on the subscriber sites.
PPP会话可以由主机或客户路由器发起。在后一种情况下，一旦与BRA建立会话，DHCP-PD可用于获取客户路由器接口的前缀。必须启用BRA以支持DHCP-PD，并在订户站点上中继主机的DHCPv6请求。
The BRAS has a /64 prefix configured on the link facing the Edge router. The Edge Router links are also configured with /64 prefixes to provide connectivity to the rest of the ISP network.
BRAS在面向边缘路由器的链路上配置了/64前缀。边缘路由器链路还配置了/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.
主机感兴趣的其他信息，如DNS，通过有状态[RFC3315]和无状态[RFC3736]DHCPv6提供。
The CPE devices are configured with a default route that points to the BRAS router. No routing protocols are needed on these devices, which generally have limited resources.
CPE设备配置有指向BRAS路由器的默认路由。这些设备通常资源有限，不需要路由协议。
The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the addresses assigned to the PPP sessions are represented as connected host routes, connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the BRAS. For this reason, the static routes must also be redistributed. Prefix summarization should be done at the BRAS.
BRAS向边缘路由器运行IGP：OSPFv3或IS-IS。由于分配给PPP会话的地址表示为连接的主机路由，因此必须重新分配连接的前缀。如果使用DHCP-PD，则BRA将通过每个委派前缀安装静态路由。因此，静态路由也必须重新分配。前缀摘要应该在BRAS中完成。
The Edge Router is running the IGP used in the ISP network: OSPFv3 or IS-IS. A separation between the routing domains of the ISP and the Access Provider is recommended if they are managed independently. Controlled redistribution will be needed between the Access Provider IGP and the ISP IGP.
边缘路由器正在运行ISP网络中使用的IGP：OSPFv3或is-is。如果ISP和访问提供商的路由域是独立管理的，建议将它们分开。接入提供商IGP和ISP IGP之间需要有控制的重新分配。
In the LAA model, the BRAS forwards the CPE initiated session to the ISP over an L2TPv2 tunnel established between the BRAS and the Edge Router. In this case, the authentication, authorization, and subscriber configuration are performed by the ISP itself.
在LAA模型中，BRA通过在BRA和边缘路由器之间建立的L2TPv2隧道将CPE发起的会话转发给ISP。在这种情况下，身份验证、授权和订户配置由ISP自己执行。
| Customer Premise | | NAP | | NSP |
| Customer Premise | | NAP | | NSP |
+-----------+
| AAA |
+------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O
| | R
+-----------+ E
|-----------------------------------------------|
PPP
|--------------|
L2TPv2
Figure 7.2.3.1
+-----------+
| AAA |
+------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O
| | R
+-----------+ E
|-----------------------------------------------|
PPP
|--------------|
L2TPv2
Figure 7.2.3.1
In this scenario, the BRAS is Layer 3 aware and has to be upgraded to support IPv6. The PPP sessions initiated by the subscriber are forwarded over the L2TPv2 tunnel to the aggregation point in the ISP network. The BRAS (LAC) can aggregate IPv6 PPP sessions and tunnel them to the LNS using L2TPv2. The L2TPv2 tunnel between the LAC and LNS could run over IPv6 or IPv4. These capabilities have to be supported on the BRAS. The following devices have to be upgraded to dual stack: Host, Customer Router (if present), BRAS and Edge Router.
在这种情况下，BRA支持第3层，必须升级以支持IPv6。用户发起的PPP会话通过L2TPv2隧道转发到ISP网络中的聚合点。BRA（LAC）可以聚合IPv6 PPP会话，并使用L2TPv2将它们隧道到LN。LAC和LNS之间的L2TPv2隧道可以通过IPv6或IPv4运行。这些功能必须在BRAS上得到支持。以下设备必须升级到双堆栈：主机、客户路由器（如果存在）、BRAS和边缘路由器。
The Edge Router terminates the PPP sessions and provides the subscriber with an IPv6 address from the defined pool for that profile. The subscriber profile for authorization and authentication can be located on the Edge Router or on an AAA server. The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop.
边缘路由器终止PPP会话，并从为该配置文件定义的池向订户提供IPv6地址。用于授权和身份验证的订户配置文件可以位于边缘路由器或AAA服务器上。主机或客户路由器将边缘路由器作为其第3层下一跳。
The PPP session can be initiated by a host or by a Customer Router. In the latter case, once the session is established with the Edge Router and an IPv6 address is assigned to the Customer Router by the Edge Router, DHCP-PD can be used to acquire prefixes for the Customer Router other interfaces. The Edge Router has to be enabled to support DHCP-PD and to relay the DHCPv6 requests of the hosts on the subscriber sites. The uplink to the ISP network is configured with a /64 prefix as well.
PPP会话可以由主机或客户路由器发起。在后一种情况下，一旦与边缘路由器建立会话并且边缘路由器将IPv6地址分配给客户路由器，DHCP-PD可用于为客户路由器和其他接口获取前缀。必须启用边缘路由器以支持DHCP-PD，并中继订户站点上主机的DHCPv6请求。ISP网络的上行链路也配置了/64前缀。
The BRAS has a /64 prefix configured on the link to the Edge Router. The Edge Router links are also configured with /64 prefixes to provide connectivity to the rest of the ISP network.
BRAS在到边缘路由器的链路上配置了/64前缀。边缘路由器链路还配置了/64前缀，以提供与ISP网络其余部分的连接。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
主机感兴趣的其他信息，如DNS，通过有状态[RFC3315]和无状态[RFC3736]DHCPv6提供。
The address assignment and prefix summarization issues discussed in Section 6.2.3.2 are relevant in the same way for this media access type as well.
第6.2.3.2节中讨论的地址分配和前缀摘要问题与此媒体访问类型同样相关。
The CPE devices are configured with a default route that points to the Edge Router that terminates the PPP sessions. No routing protocols are needed on these devices, which have limited resources.
CPE设备配置有指向终止PPP会话的边缘路由器的默认路由。这些设备资源有限，不需要路由协议。
The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. Different processes should be used if the NAP and the NSP are managed by different organizations. In this case, controlled redistribution should be enabled between the two domains.
BRAS运行到边缘路由器的IPv6 IGP:OSPFv3或IS-IS。如果NAP和NSP由不同的组织管理，则应使用不同的流程。在这种情况下，应在两个域之间启用受控的重新分发。
The Edge Router is running the IPv6 IGP used in the ISP network: OSPFv3 or IS-IS.
边缘路由器正在运行ISP网络中使用的IPv6 IGP:OSPFv3或is-is。
It was recommended throughout this section that the IPv6 service implementation should map the existing IPv4 one. This approach simplifies manageability and minimizes training needed for personnel operating the network. In certain circumstances, such mapping is not feasible. This typically becomes the case when a Service Provider plans to expand its service offering with the new IPv6 deployed infrastructure. If this new service is not well supported in a network design such as the one used for IPv4, then a different design might be used for IPv6.
本节建议IPv6服务实现应映射现有的IPv4服务。这种方法简化了可管理性，最大限度地减少了网络操作人员所需的培训。在某些情况下，这种映射是不可行的。当服务提供商计划使用新的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边缘路由器。如果SP决定通过这种设计提供多播服务，它将面临NAP资源被过度利用的问题。边缘路由器只能在隧道末端复制多播流量，所有订阅者的副本都会在整个NAP中进行。
A Modified Point-to-Point (see Section 7.2.4.2) or a PTA model is more suitable to support multicast services because the packet replication can be done closer to the destination at the BRAS. Such a topology saves NAP resources.
修改后的点对点（见第7.2.4.2节）或PTA模型更适合支持多播服务，因为包复制可以在BRA的目的地附近完成。这样的拓扑可以节省NAP资源。
In this sense, IPv6 deployments can be viewed as an opportunity to build an infrastructure that can better support the expansion of services. In this case, an SP using the LAA design for its IPv4 services might choose a modified Point-to-Point or PTA design for IPv6.
从这个意义上讲，IPv6部署可以被视为构建能够更好地支持服务扩展的基础设施的机会。在这种情况下，为其IPv4服务使用LAA设计的SP可能会为IPv6选择修改的点对点或PTA设计。
The coexistence of the two PPP-based models, PTA and LAA, is relatively straightforward. It is a straightforward overlap of the two deployment models. The PPP sessions are terminated on different network devices for the IPv4 and IPv6 services. The PPP sessions for the existing IPv4 service deployed in an LAA model are terminated on the Edge Router. The PPP sessions for the new IPv6 service deployed in a PTA model are terminated on the BRAS.
PTA和LAA这两种基于PPP的模式共存相对简单。这是两种部署模型的直接重叠。PPP会话在IPv4和IPv6服务的不同网络设备上终止。LAA模型中部署的现有IPv4服务的PPP会话在边缘路由器上终止。在PTA模型中部署的新IPv6服务的PPP会话在BRA上终止。
The logical design for IPv6 and IPv4 in this hybrid model is presented in Figure 7.2.4.1.
图7.2.4.1给出了该混合模型中IPv6和IPv4的逻辑设计。
IPv6 |--------------------------|
PPP +-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv6 |--------------------------|
PPP +-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
Figure 7.2.4.1
图7.2.4.1
The coexistence of the modified Point-to-Point and the LAA models implies a few specific changes.
修改后的点对点模型和LAA模型的共存意味着一些具体的变化。
For the IPv4 service in LAA model, the VLANs are terminated on the BRAS, and PPP sessions are terminated on the Edge Router (LNS). For the IPv6 service in the Point-to-Point model, the VLANs are terminated at the Edge Router as described in Section 6.2.1. In this hybrid model, the Point-to-Point link could be terminated on the BRAS, a NAP-owned device. The IPv6 traffic is then routed through the NAP network to the NSP. In order to have this hybrid model, the BRAS has to be upgraded to a dual-stack router. The functionalities of the Edge Router, as described in Section 6.2.1, are now implemented on the BRAS.
对于LAA模型中的IPv4服务，VLAN在BRA上终止，PPP会话在边缘路由器（LNS）上终止。对于点到点模型中的IPv6服务，VLAN在边缘路由器处终止，如第6.2.1节所述。在这种混合模式中，点对点链路可以在BRAS（NAP拥有的设备）上终止。IPv6流量随后通过NAP网络路由到NSP。为了拥有这种混合模式，BRAS必须升级为双栈路由器。如第6.2.1节所述，边缘路由器的功能现已在BRAS上实现。
The logical design for IPv6 and IPv4 in this hybrid model is in Figure 7.2.4.2.
此混合模型中IPv6和IPv4的逻辑设计如图7.2.4.2所示。
IPv6 |----------------|
Ethernet
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
IPv6 |----------------|
Ethernet
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
Figure 7.2.4.2
图7.2.4.2
The typical multicast services offered for residential and very small businesses are video/audio streaming where the subscriber joins a multicast group and receives the content. This type of service model is well supported through PIM-SSM, which is very simple and easy to manage. PIM-SSM has to be enabled throughout the ISP network. MLDv2 is required for PIM-SSM support. Vendors can choose to implement features that allow routers to map MLDv1 group joins to predefined sources.
为住宅和小型企业提供的典型多播服务是视频/音频流，其中订户加入多播组并接收内容。这种类型的服务模型通过PIM-SSM得到了很好的支持，PIM-SSM非常简单且易于管理。必须在整个ISP网络中启用PIM-SSM。PIM-SSM支持需要MLDv2。供应商可以选择实现允许路由器将MLDv1组连接映射到预定义源的功能。
Subscribers might use a set-top box that is responsible for the control piece of the multicast service (does group joins/leaves). The subscriber hosts can also join desired multicast groups as long as they are enabled to support MLDv1 or MLDv2. If a CPR is used, then it has to be enabled to support MLDv1 and MLDv2 in order to process the requests of the hosts. It has to be enabled to support PIM-SSM in order to send PIM joins/leaves up to its Layer 3 next hop whether it is the BRAS or the Edge Router. When enabling this functionality on a CPR, its limited resources should be taken into consideration. Another option would be for the CPR to support MLD proxy routing. MLD snooping or similar Layer 2 multicast-related protocols could be enabled on the NAP switches.
订阅者可以使用一个机顶盒，负责多播服务的控制部分（组加入/离开）。订户主机还可以加入所需的多播组，只要它们能够支持MLDv1或MLDv2。如果使用CPR，则必须启用它以支持MLDv1和MLDv2，以便处理主机的请求。必须启用它以支持PIM-SSM，以便将PIM加入/离开发送到其第3层下一跳，无论是BRAS还是边缘路由器。在CPR上启用此功能时，应考虑其有限的资源。另一个选择是CPR支持MLD代理路由。可以在NAP交换机上启用MLD侦听或类似的第2层多播相关协议。
The router that is the Layer 3 next hop for the subscriber (BRAS in the PTA model or the Edge Router in the LAA and Point-to-Point model) has to be enabled to support MLDv1 and MLDv2 in order to process the requests coming from subscribers without CPRs. It has to be enabled for PIM-SSM in order to receive joins/leaves from customer routers and send joins/leaves to the next hop towards the multicast source (Edge Router or the NSP core).
作为订户的第3层下一跳的路由器（PTA模型中的BRA或LAA和点对点模型中的边缘路由器）必须启用以支持MLDv1和MLDv2，以便处理来自没有CPR的订户的请求。必须为PIM-SSM启用该功能，以便从客户路由器接收加入/离开，并向多播源（边缘路由器或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节。
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层下一跳的路由器（PTA模型中的BRA或LAA和点对点模型中的边缘路由器）上特别相关，以便管理多个用户之间共享的资源，可能使用各种服务级别协议。
On the BRAS or the Edge Router, the subscriber-facing interfaces have to be configured to police the inbound customer traffic and shape the traffic outbound to the customer based on the SLAs. Traffic classification and marking should also be done on the router closest (at Layer 3) to the subscriber in order to support the various types of customer traffic: data, voice, video, and to optimally use the network resources. This infrastructure offers a very good opportunity to leverage the QoS capabilities of Layer 2 devices. Diffserv-based QoS used for IPv4 should be expanded to IPv6.
在BRAS或边缘路由器上，面向订户的接口必须配置为监控入站客户流量，并根据SLA调整出站客户流量。流量分类和标记也应在离用户最近的路由器（第3层）上进行，以支持各种类型的客户流量：数据、语音、视频，并优化使用网络资源。该基础架构提供了一个很好的机会来利用第2层设备的QoS功能。用于IPv4的基于区分服务的QoS应扩展到IPv6。
Each provider (NAP, NSP) could implement their own QoS policies and services so that reclassification and marking might be performed at the boundary between the NAP and the NSP, in order to make sure the traffic is properly handled by the ISP. The same IPv4 QoS concepts and methodologies should be applied for the IPv6 as well.
每个提供商（NAP、NSP）都可以实施自己的QoS策略和服务，以便在NAP和NSP之间的边界处执行重新分类和标记，以确保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头字段进行分类。
There are limited changes that have to be done for CPEs in order to enhance security. The privacy extensions [RFC3041] for auto-configuration should be used by the hosts with the same considerations for host traceability as discussed in Section 6.5. IPv6 firewall functions should be enabled on the hosts or Customer Premise Router, if present.
为了增强安全性，必须对CPE进行有限的更改。主机使用自动配置的隐私扩展[RFC3041]时，应考虑与第6.5节中讨论的主机可追溯性相同的因素。应在主机或客户端路由器（如果存在）上启用IPv6防火墙功能。
The ISP provides security against attacks that come from its own subscribers, but it could also implement security services that protect its subscribers from attacks sourced from outside its network. Such services do not apply at the access level of the network discussed here.
ISP针对来自其自身用户的攻击提供安全保护，但它也可以实施安全服务，保护其用户免受来自其网络外部的攻击。此类服务不适用于此处讨论的网络访问级别。
If any Layer 2 filters for Ethertypes are in place, the NAP must permit the IPv6 Ethertype (0X86DD).
如果有任何以太网类型的第2层过滤器，NAP必须允许IPv6以太网类型（0X86DD）。
The device that is the Layer 3 next hop for the subscribers (BRAS Edge Router) should protect the network and the other subscribers against attacks by one of the provider customers. For this reason uRPF and ACLs should be used on all interfaces facing subscribers. Filtering should be implemented with regard for the operational requirements of IPv6 [IPv6-Security].
作为用户的第3层下一跳的设备（BRAS边缘路由器）应保护网络和其他用户免受提供商客户之一的攻击。因此，面向订阅者的所有接口上都应使用uRPF和ACL。应根据IPv6[IPv6安全]的操作要求实施过滤。
The BRAS and the Edge Router should protect their processing resources against floods of valid customer control traffic such as: Router and Neighbor Solicitations, and MLD Requests. Rate limiting should be implemented on all subscriber-facing interfaces. The emphasis should be placed on multicast-type traffic, as it is most often used by the IPv6 control plane.
BRA和边缘路由器应保护其处理资源不受有效客户控制流量的影响，例如：路由器和邻居请求，以及MLD请求。应在所有面向订户的接口上实施速率限制。重点应放在多播类型的流量上，因为IPv6控制平面最常用多播类型的流量。
All other security features used with the IPv4 service should be similarly applied to IPv6 as well.
与IPv4服务一起使用的所有其他安全功能也应类似地应用于IPv6。
The necessary instrumentation (such as MIB modules, NetFlow Records, etc.) should be available for IPv6.
IPv6应提供必要的工具（如MIB模块、NetFlow记录等）。
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进行连接，则可以通过IPv4进行SNMP传输。这意味着对现有网络管理实践和流程的改动最小。还可以通过IPv6实现传输，如果网络中只存在IPv6孤岛，则可能有必要这样做。管理应用程序可能正在属于NSP核心网络域的主机上运行。网络管理应用程序应以类似于IPv4的方式处理IPv6；但是，它们还应该支持IPv6特有的功能，如邻居监视。
In some cases, service providers manage equipment located on customers' LANs.
在某些情况下，服务提供商管理位于客户局域网上的设备。
This section provides a detailed description of IPv6 deployment and integration methods in currently deployed wireless LAN (WLAN) infrastructure.
本节详细介绍当前部署的无线局域网（WLAN）基础设施中的IPv6部署和集成方法。
WLAN enables subscribers to connect to the Internet from various locations without the restriction of staying indoors. WLAN is standardized by IEEE 802.11a/b/g.
无线局域网使用户能够从不同的位置连接到互联网，而不受呆在室内的限制。WLAN由IEEE 802.11a/b/g标准化。
Figure 8.1 describes the current WLAN architecture.
图8.1描述了当前的WLAN架构。
Customer | Access Provider | Service Provider
Premise | |
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 | ---- | | |Access Router/| | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
+------+
|AAA |
|Server|
+------+
Figure 8.1
图8.1
The host should have a wireless Network Interface Card (NIC) in order to connect to a WLAN network. WLAN is a flat broadcast network and works in a similar fashion as Ethernet. When a host initiates a connection, it is authenticated by the AAA server located at the SP network. All the authentication parameters (username, password, etc.) are forwarded by the Access Point (AP) to the AAA server. The AAA server authenticates the host; once successfully authenticated, the host can send data packets. The AP is located near the host and acts as a bridge. The AP forwards all the packets coming to/from host to the Edge Router. The underlying connection between the AP and Edge Router could be based on any access layer technology such as HFC/Cable, FTTH, xDSL, etc.
主机应具有无线网络接口卡（NIC），以便连接到WLAN网络。WLAN是一种平面广播网络，其工作方式与以太网类似。当主机启动连接时，它将由位于SP网络的AAA服务器进行身份验证。所有身份验证参数（用户名、密码等）都由接入点（AP）转发到AAA服务器。AAA服务器对主机进行认证；一旦成功验证，主机就可以发送数据包。AP位于主机附近，充当桥接器。AP将所有进出主机的数据包转发到边缘路由器。AP和边缘路由器之间的底层连接可以基于任何接入层技术，如HFC/电缆、FTTH、xDSL等。
WLANs operate within limited areas known as WiFi Hot Spots. While users are present in the area covered by the WLAN range, they can be connected to the Internet given they have a wireless NIC and required configuration settings in their devices (notebook PCs, PDAs, etc.). Once the user initiates the connection, the IP address is assigned by the SP using DHCPv4. In most of the cases, SP assigns a limited number of public IP addresses to its customers. When the user disconnects the connection and moves to a new WiFi hot spot, the above-mentioned process of authentication, address assignment, and accessing the Internet is repeated.
无线局域网在称为WiFi热点的有限区域内运行。当用户位于WLAN覆盖范围内时，只要他们的设备（笔记本电脑、PDA等）中有无线NIC和所需的配置设置，他们就可以连接到Internet。一旦用户启动连接，SP将使用DHCPv4分配IP地址。在大多数情况下，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路由器通过无线连接到其服务提供商。这些部署类型不适合典型的热点概念，而是为固定客户服务。因此，本节还将讨论WLAN路由器选项。在这种情况下，[RF918]为WLAN用户分配一个专用IP地址。WLAN路由器在WLAN用户访问Internet时提供NAT功能。
While deploying IPv6 in the above-mentioned WLAN architecture, there are three possible scenarios as discussed below.
在上述WLAN体系结构中部署IPv6时，有三种可能的情况，如下所述。
A. Layer 2 NAP with Layer 3 termination at NSP Edge Router
A.在NSP边缘路由器处具有第3层终端的第2层NAP
B. Layer 3 aware NAP with Layer 3 termination at Access Router
B.在接入路由器处具有第3层终端的第3层感知NAP
C. PPP-Based Model
C.基于PPP的模式
When a Layer 2 switch is present between AP and Edge Router, the AP and Layer 2 switch continues to work as a bridge, forwarding IPv4 and IPv6 packets from WLAN Host/Router to Edge Router and vice versa.
当AP和边缘路由器之间存在第2层交换机时，AP和第2层交换机继续充当网桥，将IPv4和IPv6数据包从WLAN主机/路由器转发到边缘路由器，反之亦然。
When initiating the connection, the WLAN Host is authenticated by the AAA server located at the SP network. All the parameters related to authentication (username, password, etc.) are forwarded by the AP to the AAA server. The AAA server authenticates the WLAN Hosts, and once the WLAN Host is authenticated and associated successfully with the WLAN AP, it acquires an IPv6 address. Note that the initiation and authentication process is the same as used in IPv4.
启动连接时，WLAN主机由位于SP网络的AAA服务器进行身份验证。所有与身份验证相关的参数（用户名、密码等）都由AP转发到AAA服务器。AAA服务器对WLAN主机进行身份验证，一旦WLAN主机通过身份验证并与WLAN AP成功关联，它将获取IPv6地址。请注意，启动和身份验证过程与IPv4中使用的过程相同。
Figure 8.1.1 describes the WLAN architecture when a Layer 2 Switch is located between AP and Edge Router.
图8.1.1描述了当第2层交换机位于AP和边缘路由器之间时的WLAN架构。
Customer | Access Provider | Service Provider
Premise | |
Customer | Access Provider | Service Provider
Premise | |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
+------+
|AAA |
|Server|
+------+
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
+------+
|AAA |
|Server|
+------+
Figure 8.1.1
图8.1.1
IPv6 will be deployed in this scenario by upgrading the following devices to dual stack: WLAN Host, WLAN Router (if present), and Edge Router.
在这种情况下，将通过将以下设备升级到双堆栈来部署IPv6：WLAN主机、WLAN路由器（如果存在）和边缘路由器。
When a customer WLAN Router is not present, the WLAN Host has two possible options to get an IPv6 address via the Edge Router.
当客户WLAN路由器不存在时，WLAN主机有两个可能的选项通过边缘路由器获取IPv6地址。
A. The WLAN Host can get the IPv6 address from an Edge Router using stateless auto-configuration [RFC2462]. All hosts on the WLAN belong to the same /64 subnet that is statically configured on the Edge Router. The IPv6 WLAN Host may use stateless DHCPv6 for obtaining other information of interest such as DNS, etc.
A.WLAN主机可以使用无状态自动配置[RFC2462]从边缘路由器获取IPv6地址。WLAN上的所有主机都属于边缘路由器上静态配置的同一/64子网。IPv6 WLAN主机可以使用无状态DHCPv6来获取其他感兴趣的信息，例如DNS等。
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
B.IPv6 WLAN主机可以使用DHCPv6[RFC3315]从DHCPv6服务器获取IPv6地址。在这种情况下，DHCPv6服务器将位于SP核心网络中，边缘路由器将仅充当DHCP中继代理。这个选项是类似的
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，今天所做的工作。需要注意的是，此时有状态自动配置的主机实现相当有限，如果选择此地址分配选项，则应考虑这一点。
When a customer WLAN Router is present, the WLAN Host has two possible options as well for acquiring IPv6 address.
当存在客户WLAN路由器时，WLAN主机还有两个可能的选项用于获取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策略和客户要求，可以为WLAN路由器分配介于/48和/64[RFC3177]之间的前缀。如果WLAN路由器有多个网络连接到其接口，则网络管理员必须为连接客户站点上WLAN主机的WLAN路由器接口配置/64前缀。连接到这些接口的WLAN主机可以使用无状态自动配置自动配置自己。
B. The WLAN Router can use its link-local address to communicate with the ER. It can also dynamically acquire through stateless auto-configuration the address for the link between itself and the ER. This step is followed by a request via DHCP-PD for a prefix shorter than /64 that, in turn, is divided in /64s and assigned to its interfaces connecting the hosts on the customer site.
B.WLAN路由器可以使用其链路本地地址与ER通信。它还可以通过无状态自动配置动态获取自身与ER之间链接的地址。此步骤之后，通过DHCP-PD请求短于/64的前缀，然后将其划分为/64，并分配给连接客户站点上主机的接口。
In this option, the WLAN Router would act as a requesting router and the Edge Router would act as a delegating router. Once the prefix is received by the WLAN Router, it assigns /64 prefixes to each of its interfaces connecting the WLAN Hosts on the customer site. The WLAN Hosts connected to these interfaces can automatically configure themselves using stateless auto-configuration. The uplink to the ISP network is configured with a /64 prefix as well.
在此选项中，WLAN路由器将充当请求路由器，边缘路由器将充当委托路由器。一旦WLAN路由器接收到前缀，它会将/64前缀分配给连接客户站点上WLAN主机的每个接口。连接到这些接口的WLAN主机可以使用无状态自动配置自动配置自己。ISP网络的上行链路也配置了/64前缀。
Usually it is easier for the SPs to stay with the DHCP-PD and stateless auto-configuration model and point the clients to a central server for DNS/domain information, proxy configurations, etc. Using this model, the SP could change prefixes on the fly, and the WLAN Router would simply pull the newest prefix based on the valid/ preferred lifetime.
通常，SP更容易使用DHCP-PD和无状态自动配置模型，并将客户端指向中央服务器以获取DNS/域信息、代理配置等。使用此模型，SP可以动态更改前缀，WLAN路由器只需根据有效/首选生存期提取最新前缀。
The prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows maximum summarization at the Edge Router.
用于订户链路的前缀和通过DHCP-PD委托的前缀应以允许在边缘路由器进行最大汇总的方式进行规划。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
主机感兴趣的其他信息，如DNS，通过有状态[RFC3315]和无状态[RFC3736]DHCPv6提供。
The WLAN Host/Router is configured with a default route that points to the Edge Router. No routing protocols are needed on these devices, which generally have limited resources.
WLAN主机/路由器配置有指向边缘路由器的默认路由。这些设备通常资源有限，不需要路由协议。
The Edge Router runs the IGP used in the SP network such as OSPFv3 or IS-IS for IPv6. The connected prefixes have to be redistributed. Prefix summarization should be done at the Edge Router. When DHCP-PD is used, the IGP has to redistribute the static routes installed during the process of prefix delegation.
边缘路由器运行SP网络中使用的IGP，如用于IPv6的OSPFv3或IS-IS。连接的前缀必须重新分配。前缀摘要应该在边缘路由器上完成。当使用DHCP-PD时，IGP必须重新分配前缀委派过程中安装的静态路由。
When an Access Router is present between the AP and Edge Router, the AP continues to work as a bridge, bridging IPv4 and IPv6 packets from WLAN Host/Router to Access Router and vice versa. The Access Router could be part of the SP network or owned by a separate Access Provider.
当AP和边缘路由器之间存在接入路由器时，AP继续充当桥接器，将IPv4和IPv6数据包从WLAN主机/路由器桥接到接入路由器，反之亦然。接入路由器可以是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主机启动连接时，AAA认证和与WLAN AP的关联过程将类似，如第8.1.1节所述。
Figure 8.1.2 describes the WLAN architecture when the Access Router is located between the AP and Edge Router.
图8.1.2描述了接入路由器位于AP和边缘路由器之间时的WLAN架构。
Customer | Access Provider | Service Provider
Premise | |
Customer | Access Provider | Service Provider
Premise | |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
+------+
|AAA |
|Server|
+------+
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
+------+
|AAA |
|Server|
+------+
Figure 8.1.2
图8.1.2
IPv6 is deployed in this scenario by upgrading the following devices to dual stack: WLAN Host, WLAN Router (if present), Access Router, and Edge Router.
在这种情况下，通过将以下设备升级到双堆栈来部署IPv6：WLAN主机、WLAN路由器（如果存在）、访问路由器和边缘路由器。
There are three possible options in this scenario for IPv6 address assignment:
此方案中有三种可能的IPv6地址分配选项：
A. The Edge Router interface facing towards the Access Router is statically configured with a /64 prefix. The Access Router receives/ configures a /64 prefix on its interface facing towards the Edge Router through stateless auto-configuration. The network administrator will have to configure the /64 prefixes to the Access Router interface facing toward the customer premise. The WLAN Host/Router connected to this interface can automatically configure itself using stateless auto-configuration.
A.面向接入路由器的边缘路由器接口静态配置有/64前缀。接入路由器通过无状态自动配置在其面向边缘路由器的接口上接收/配置/64前缀。网络管理员必须为面向客户的接入路由器接口配置/64前缀。连接到此接口的WLAN主机/路由器可以使用无状态自动配置自动配置自身。
B. This option uses DHCPv6 [RFC3315] for IPv6 prefix assignments to the WLAN Host/Router. There is no use of DHCP PD or stateless auto-configuration in this option. The DHCPv6 server can be located on the Access Router, the Edge Router, or somewhere in the SP network. In this case, depending on where the DHCPv6 server is located, the Access Router or the Edge Router would relay the DHCPv6 requests.
B.此选项使用DHCPv6[RFC3315]将IPv6前缀分配给WLAN主机/路由器。此选项中不使用DHCP PD或无状态自动配置。DHCPv6服务器可以位于接入路由器、边缘路由器或SP网络中的某个位置。在这种情况下，根据DHCPv6服务器所在的位置，访问路由器或边缘路由器将中继DHCPv6请求。
C. It can use its link-local address to communicate with the ER. It can also dynamically acquire through stateless auto-configuration the address for the link between itself and the ER. This step is followed by a request via DHCP-PD for a prefix shorter than /64 that, in turn, is divided in /64s and assigned to its interfaces connecting the hosts on the customer site.
C.它可以使用其链路本地地址与ER通信。它还可以通过无状态自动配置动态获取自身与ER之间链接的地址。此步骤之后，通过DHCP-PD请求短于/64的前缀，然后将其划分为/64，并分配给连接客户站点上主机的接口。
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.
在该选项中，访问路由器将充当请求路由器，边缘路由器将充当委托路由器。一旦接入路由器接收到前缀，它会将/64前缀分配给连接客户站点上WLAN主机/路由器的每个接口。连接到这些接口的WLAN主机/路由器可以使用无状态自动配置自动配置自身。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/域信息、代理配置和其他信息。使用此模型，提供者可以动态更改前缀，访问路由器只需根据有效/首选生存期提取最新前缀。
As mentioned before, the prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows the maximum summarization possible at the Edge Router. Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
如前所述，用于订户链路的前缀和通过DHCP-PD委托的前缀应以允许在边缘路由器上进行最大程度汇总的方式进行规划。主机感兴趣的其他信息，如DNS，通过有状态[RFC3315]和无状态[RFC3736]DHCPv6提供。
The WLAN Host/Router is configured with a default route that points to the Access Router. No routing protocols are needed on these devices, which generally have limited resources.
WLAN主机/路由器配置有指向接入路由器的默认路由。这些设备通常资源有限，不需要路由协议。
If the Access Router is owned by an Access Provider, then the Access Router can have a default route, pointing towards the SP Edge Router. The Edge Router runs the IGP used in the SP network such as OSPFv3 or IS-IS for IPv6. The connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the Edge Router. For this reason the static routes must be redistributed. Prefix summarization should be done at the Edge Router.
如果访问路由器归访问提供商所有，则访问路由器可以具有指向SP边缘路由器的默认路由。边缘路由器运行SP网络中使用的IGP，如用于IPv6的OSPFv3或IS-IS。连接的前缀必须重新分配。如果使用DHCP-PD，则边缘路由器将通过每个委派前缀安装静态路由。因此，必须重新分配静态路由。前缀摘要应该在边缘路由器上完成。
If the Access Router is owned by the SP, then the Access Router will also run IPv6 IGP, and will be part of the SP IPv6 routing domain (OSPFv3 or IS-IS). The connected prefixes have to be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the Access Router. For this reason, the static routes must be redistributed. Prefix summarization should be done at the Access Router.
如果接入路由器归SP所有，则接入路由器也将运行IPv6 IGP，并且将是SP IPv6路由域（OSPFv3或is-is）的一部分。连接的前缀必须重新分配。如果使用DHCP-PD，则访问路由器将通过每个委派前缀安装静态路由。因此，必须重新分配静态路由。前缀摘要应该在访问路由器上完成。
PPP Terminated Aggregation (PTA) and L2TPv2 Access Aggregation (LAA) models, as discussed in Sections 6.2.2 and 6.2.3, respectively, can also be deployed in IPv6 WLAN environment.
第6.2.2节和第6.2.3节分别讨论的PPP终止聚合（PTA）和L2TPv2访问聚合（LAA）模型也可以部署在IPv6 WLAN环境中。
While deploying the PTA model in IPv6 WLAN environment, the Access Router is Layer 3 aware and it has to be upgraded to support IPv6. Since the Access Router terminates the PPP sessions initiated by the WLAN Host/Router, it has to support PPPoE with IPv6.
在IPv6 WLAN环境中部署PTA模型时，接入路由器支持第3层，必须升级以支持IPv6。由于接入路由器终止由WLAN主机/路由器发起的PPP会话，因此它必须支持带有IPv6的PPPoE。
Figure 8.1.3.1 describes the PTA Model in IPv6 WLAN environment.
图8.1.3.1描述了IPv6 WLAN环境中的PTA模型。
Customer | Access Provider | Service Provider
Premise | |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
|---------------------------| +------+
PPP |AAA |
|Server|
+------+
Customer | Access Provider | Service Provider
Premise | |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
|---------------------------| +------+
PPP |AAA |
|Server|
+------+
Figure 8.1.3.1
图8.1.3.1
IPv6 is deployed in this scenario by upgrading the following devices to dual stack: WLAN Host, WLAN Router (if present), Access Router, and Edge Router.
在这种情况下，通过将以下设备升级到双堆栈来部署IPv6：WLAN主机、WLAN路由器（如果存在）、访问路由器和边缘路由器。
The addressing techniques described in Section 6.2.2.2 apply to the IPv6 WLAN PTA scenario as well.
第6.2.2.2节中描述的寻址技术也适用于IPv6 WLAN PTA场景。
The routing techniques described in Section 6.2.2.3 apply to the IPv6 WLAN PTA scenario as well.
第6.2.2.3节中描述的路由技术也适用于IPv6 WLAN PTA场景。
While deploying the LAA model in IPv6 WLAN environment, the Access Router is Layer 3 aware and has to be upgraded to support IPv6. The PPP sessions initiated by the WLAN Host/Router are forwarded over the L2TPv2 tunnel to the aggregation point in the SP network. The Access Router must have the capability to support L2TPv2 for IPv6.
在IPv6 WLAN环境中部署LAA模型时，接入路由器支持第3层，必须升级以支持IPv6。WLAN主机/路由器发起的PPP会话通过L2TPv2隧道转发到SP网络中的聚合点。接入路由器必须能够支持IPv6的L2TPv2。
Figure 8.1.3.2 describes the LAA Model in IPv6 WLAN environment.
图8.1.3.2描述了IPv6 WLAN环境中的LAA模型。
Customer | Access Provider | Service Provider
Premise | |
Customer | Access Provider | Service Provider
Premise | |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
|-------------------------------------------------- |
PPP |
|--------------------- |
L2TPv2 |
+------+
|AAA |
|Server|
+------+
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+
|
|-------------------------------------------------- |
PPP |
|--------------------- |
L2TPv2 |
+------+
|AAA |
|Server|
+------+
Figure 8.1.3.2
图8.1.3.2
IPv6 is deployed in this scenario by upgrading the following devices to dual stack: WLAN Host, WLAN Router (if present), Access Router, and Edge Router.
在这种情况下，通过将以下设备升级到双堆栈来部署IPv6：WLAN主机、WLAN路由器（如果存在）、访问路由器和边缘路由器。
The addressing techniques described in Section 6.2.3.2 apply to the IPv6 WLAN LAA scenario as well.
第6.2.3.2节中描述的寻址技术也适用于IPv6 WLAN LAA场景。
The routing techniques described in Section 6.2.3.3 apply to the IPv6 WLAN LAA scenario as well.
第6.2.3.3节中描述的路由技术也适用于IPv6 WLAN LAA场景。
The typical multicast services offered are video/audio streaming where the IPv6 WLAN Host joins a multicast group and receives the content. This type of service model is well supported through PIM-SSM, which is enabled throughout the SP network. MLDv2 is required for PIM-SSM support. Vendors can choose to implement features that allow routers to map MLDv1 group joins to predefined sources.
提供的典型多播服务是视频/音频流，其中IPv6 WLAN主机加入多播组并接收内容。这种类型的服务模型通过PIM-SSM得到很好的支持，PIM-SSM在整个SP网络中启用。PIM-SSM支持需要MLDv2。供应商可以选择实现允许路由器将MLDv1组连接映射到预定义源的功能。
It is important to note that in the shared wireless environments, multicast can have a significant bandwidth impact. For this reason, the bandwidth allocated to multicast traffic should be limited and fixed, based on the overall capacity of the wireless specification used in 802.11a, 802.11b, or 802.11g.
需要注意的是，在共享无线环境中，多播可能会对带宽产生重大影响。因此，根据802.11a、802.11b或802.11g中使用的无线规范的总体容量，分配给多播业务的带宽应该是有限的和固定的。
The IPv6 WLAN Hosts can also join desired multicast groups as long as they are enabled to support MLDv1 or MLDv2. If WLAN/Access Routers are used, then they have to be enabled to support MLDv1 and MLDv2 in order to process the requests of the IPv6 WLAN Hosts. The WLAN/ Access Router also needs to be enabled to support PIM-SSM in order to send PIM joins up to the Edge Router. When enabling this functionality on a WLAN/Access Router, its limited resources should be taken into consideration. Another option would be for the WLAN/ Access Router to support MLD proxy routing.
IPv6 WLAN主机还可以加入所需的多播组，只要它们能够支持MLDv1或MLDv2。如果使用WLAN/接入路由器，则必须启用它们以支持MLDv1和MLDv2，以便处理IPv6 WLAN主机的请求。为了向边缘路由器发送PIM连接，还需要启用WLAN/接入路由器以支持PIM-SSM。在WLAN/接入路由器上启用此功能时，应考虑其有限的资源。另一个选项是WLAN/接入路由器支持MLD代理路由。
The Edge Router has to be enabled to support MLDv1 and MLDv2 in order to process the requests coming from the IPv6 WLAN Host or WLAN/Access Router (if present). The Edge Router has also needs to be enabled for PIM-SSM in order to receive joins from IPv6 WLAN Hosts or WLAN/ Access Router (if present), and send joins towards the SP core.
必须启用边缘路由器以支持MLDv1和MLDv2，以便处理来自IPv6 WLAN主机或WLAN/接入路由器（如果存在）的请求。还需要为PIM-SSM启用边缘路由器，以便从IPv6 WLAN主机或WLAN/接入路由器（如果存在）接收连接，并向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能够为提供的内容服务进行计费。应进行进一步调查，以找到支持这些职能的替代机制。
Concerns have been raised in the past related to running IPv6 multicast over WLAN links. Potentially these are the same kind of issues when running any Layer 3 protocol over a WLAN link that has a high loss-to-signal ratio, where certain frames that are multicast based are dropped when settings are not adjusted properly. For instance, this behavior is similar to an IGMP host membership report, when done on a WLAN link with a high loss-to-signal ratio and high interference.
过去，人们对通过WLAN链路运行IPv6多播提出了担忧。当在具有高信号丢失率的WLAN链路上运行任何第3层协议时，这些问题可能是相同的，其中某些基于多播的帧在未正确调整设置时被丢弃。例如，当在具有高损耗信号比和高干扰的WLAN链路上执行时，此行为类似于IGMP主机成员资格报告。
This problem is inherited by WLAN that can impact both IPv4 and IPv6 multicast packets; it is not specific to IPv6 multicast.
此问题由WLAN继承，可能会影响IPv4和IPv6多播数据包；它不是特定于IPv6多播的。
While deploying WLAN (IPv4 or IPv6), one should adjust their broadcast/multicast settings if they are in danger of dropping application dependent frames. These problems are usually caused when the AP is placed too far (not following the distance limitations), high interference, etc. These issues may impact a real multicast application such as streaming video or basic operation of IPv6 if the frames were dropped. Basic IPv6 communications uses functions such as Duplicate Address Detection (DAD), Router and Neighbor
在部署WLAN（IPv4或IPv6）时，如果存在丢弃依赖于应用程序的帧的危险，则应调整其广播/多播设置。这些问题通常是由于AP放置得太远（不遵循距离限制）、高干扰等造成的。如果帧被丢弃，这些问题可能会影响真实的多播应用程序，如流视频或IPv6的基本操作。基本IPv6通信使用重复地址检测（DAD）、路由器和邻居等功能
Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA), etc., which could be impacted by the above mentioned issues as these frames are Layer 2 Ethernet multicast frames.
请求（RS、NS）、路由器和邻居广告（RA、NA）等，由于这些帧是第2层以太网多播帧，因此可能会受到上述问题的影响。
Please refer to Section 6.3 for more IPv6 multicast details.
有关IPv6多播的更多详细信息，请参阅第6.3节。
Today, QoS is done outside of the WiFi domain, but it is nevertheless important to the overall deployment.
如今，QoS是在WiFi域之外完成的，但它对整体部署仍然很重要。
The QoS configuration is particularly relevant on the Edge Router in order to manage resources shared amongst multiple subscribers possibly with various service level agreements (SLAs). However, the WLAN Host/Router and Access Router could also be configured for QoS. This includes support for appropriate classification criteria, which would need to be implemented for IPv6 unicast and multicast traffic.
QoS配置在边缘路由器上特别相关，以便管理多个订阅者之间共享的资源，这些订阅者可能具有各种服务级别协议（SLA）。然而，WLAN主机/路由器和接入路由器也可以配置为QoS。这包括对适当分类标准的支持，这需要为IPv6单播和多播流量实现。
On the Edge Router, the subscriber-facing interfaces have to be configured to police the inbound customer traffic and shape the traffic outbound to the customer, based on the SLA. Traffic classification and marking should also be done on the Edge Router in order to support the various types of customer traffic: data, voice, and video. The same IPv4 QoS concepts and methodologies should be applied for the IPv6 as well.
在边缘路由器上，必须根据SLA配置面向订户的接口，以监控入站客户流量，并塑造出站客户流量。还应在边缘路由器上进行流量分类和标记，以支持各种类型的客户流量：数据、语音和视频。同样的IPv4 QoS概念和方法也应适用于IPv6。
It is important to note that when traffic is encrypted end-to-end, the traversed network devices will not have access to many of the packet fields used for classification purposes. In these cases, routers will most likely place the packets in the default classes. The QoS design should take into consideration this scenario and try to use mainly IP header fields for classification purposes.
重要的是要注意，当对通信量进行端到端加密时，经过的网络设备将无法访问用于分类目的的许多数据包字段。在这些情况下，路由器最有可能将数据包放在默认类中。QoS设计应考虑到这种情况，并尝试主要使用IP头字段进行分类。
There are limited changes that have to be done for WLAN the Host/ Router in order to enhance security. The privacy extensions [RFC3041] for auto-configuration should be used by the hosts with the same consideration for host traceability as described in Section 6.5. IPv6 firewall functions should be enabled on the WLAN Host/Router, if present.
为了增强安全性，必须对WLAN主机/路由器进行有限的更改。主机使用自动配置的隐私扩展[RFC3041]时，应考虑第6.5节所述的主机可追溯性。应在WLAN主机/路由器上启用IPv6防火墙功能（如果存在）。
The ISP provides security against attacks that come from its own subscribers, but it could also implement security services that protect its subscribers from attacks sourced from outside its network. Such services do not apply at the access level of the network discussed here.
ISP针对来自其自身用户的攻击提供安全保护，但它也可以实施安全服务，保护其用户免受来自其网络外部的攻击。此类服务不适用于此处讨论的网络访问级别。
If the host authentication at hotspots is done using a web-based authentication system, then the level of security would depend on the particular implementation. User credentials should never be sent as clear text via HTTP. Secure HTTP (HTTPS) should be used between the web browser and authentication server. The authentication server could use RADIUS and LDAP services at the back end.
如果热点的主机身份验证是使用基于web的身份验证系统完成的，那么安全级别将取决于特定的实现。绝不应通过HTTP以明文形式发送用户凭据。web浏览器和身份验证服务器之间应使用安全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.
在实施第3层安全策略之前，身份验证是确保WLAN网络安全的一个重要方面。例如，这将有助于避免对ND或无状态自动配置进程的威胁。802.1x[IEEE8021X]提供了确保网络访问安全的方法；但是，多种类型的EAP（PEAP、EAP-TLS、EAP-TTLS、EAP-FAST和LEAP）以及主机支持某些功能的能力可能使实施全面一致的策略变得困难。
The 802.11i [IEEE80211i] amendment has many components, the most obvious of which are the two new data-confidentiality protocols, Temporal Key Integrity Protocol (TKIP) and Counter-Mode/CBC-MAC Protocol (CCMP). 802.11i also uses 802.1X's key-distribution system to control access to the network. Because 802.11 handles unicast and broadcast traffic differently, each traffic type has different security concerns. With several data-confidentiality protocols and the key distribution, 802.11i includes a negotiation process for selecting the correct confidentiality protocol and key system for each traffic type. Other features introduced include key caching and pre-authentication.
802.11i[IEEE801I]修正案有许多组成部分，其中最明显的是两个新的数据保密协议，即临时密钥完整性协议（TKIP）和计数器模式/CBC-MAC协议（CCMP）。802.11i还使用802.1X的密钥分发系统来控制对网络的访问。由于802.11处理单播和广播流量的方式不同，因此每种流量类型都有不同的安全问题。802.11i具有多种数据保密协议和密钥分发，它包括一个协商过程，用于为每种通信量类型选择正确的保密协议和密钥系统。引入的其他功能包括密钥缓存和预认证。
The 802.11i amendment is a step forward in wireless security. The amendment adds stronger encryption, authentication, and key management strategies that could make wireless data and systems more secure.
802.11i修正案是无线安全的一个进步。修正案增加了更强大的加密、认证和密钥管理策略，使无线数据和系统更加安全。
If any Layer 2 filters for Ethertypes are in place, the NAP must permit the IPv6 Ethertype (0X86DD).
如果有任何以太网类型的第2层过滤器，NAP必须允许IPv6以太网类型（0X86DD）。
The device that is the Layer 3 next hop for the subscribers (Access or Edge Router) should protect the network and the other subscribers against attacks by one of the provider customers. For this reason uRPF and ACLs should be used on all interfaces facing subscribers. Filtering should be implemented with regard for the operational requirements of IPv6 [IPv6-Security].
作为用户（访问或边缘路由器）的第3层下一跳的设备应保护网络和其他用户免受提供商客户之一的攻击。因此，面向订阅者的所有接口上都应使用uRPF和ACL。应根据IPv6[IPv6安全]的操作要求实施过滤。
The Access and the Edge Router should protect their processing resources against floods of valid customer control traffic such as: RS, NS, and MLD Requests. Rate limiting should be implemented on all
访问和边缘路由器应保护其处理资源免受有效客户控制流量（如：RS、NS和MLD请求）的冲击。应在所有车辆上实施限速
subscriber-facing interfaces. The emphasis should be placed on multicast-type traffic, as it is most often used by the IPv6 control plane.
面向订户的接口。重点应放在多播类型的流量上，因为IPv6控制平面最常用多播类型的流量。
The necessary instrumentation (such as MIB modules, NetFlow Records, etc) should be available for IPv6.
IPv6应提供必要的工具（如MIB模块、NetFlow记录等）。
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进行连接，则可以通过IPv4进行SNMP传输。这意味着对现有网络管理实践和流程的改动最小。还可以通过IPv6实现传输，如果网络中只存在IPv6孤岛，则可能有必要这样做。管理应用程序可能正在属于NSP核心网络域的主机上运行。网络管理应用程序应以类似于IPv4的方式处理IPv6；但是，它们还应该支持IPv6特有的功能（例如邻居监视）。
In some cases, service providers manage equipment located on customers' LANs.
在某些情况下，服务提供商管理位于客户局域网上的设备。
This section describes the IPv6 deployment in Power Line Communications (PLC) Access Networks. There may be other choices, but it seems that this is the best model to follow. Lessons learnt from cable, Ethernet, and even WLAN access networks may be applicable also.
本节介绍电力线通信（PLC）接入网络中的IPv6部署。也许还有其他选择，但这似乎是最好的模式。从电缆、以太网甚至WLAN接入网络中吸取的经验教训也可能适用。
Power Line Communications are also often called Broadband Power Line (BPL) and sometimes even Power Line Telecommunications (PLT).
电力线通信通常也称为宽带电力线（BPL），有时甚至称为电力线通信（PLT）。
PLC/BPL can be used for providing, with today's technology, up to 200Mbps (total, upstream+downstream) by means of the power grid. The coverage is often the last half mile (typical distance from the medium-to-low voltage transformer to the customer premise meter) and, of course, as an in-home network (which is out of the scope of this document).
利用当今的技术，PLC/BPL可通过电网提供高达200Mbps（总速度、上游+下游）的电力。覆盖范围通常是最后半英里（从中低压变压器到客户场所仪表的典型距离），当然，作为家庭网络（不在本文件范围内）。
The bandwidth in a given PLC/BPL segment is shared among all the customers connected to that segment (often the customers connected to the same medium-to-low voltage transformer). The number of customers can vary depending on different factors, such as distances and even countries (from a few customers, just 5-6, up to 100-150).
给定PLC/BPL段中的带宽由连接到该段的所有客户共享（通常是连接到同一中低压变压器的客户）。客户数量可能因不同因素而有所不同，例如距离甚至国家（从少数客户，仅5-6家，到100-150家）。
PLC/BPL could also be used in the medium voltage network (often configured as Metropolitan Area Networks), but this is also out of the scope of this document, as it will be part of the core network, not the access one.
PLC/BPL也可用于中压网络（通常配置为城域网），但这也超出了本文件的范围，因为它将是核心网络的一部分，而不是接入网络的一部分。
This section describes the different elements commonly used in PLC/ BPL access networks.
本节介绍PLC/BPL接入网络中常用的不同元件。
Head End (HE): Router that connects the PLC/BPL access network (the power grid), located at the medium-to-low voltage transformer, to the core network. The HE PLC/BPL interface appears to each customer as a single virtual interface, all of them sharing the same physical media.
前端（HE）：将位于中低压变压器处的PLC/BPL接入网络（电网）连接至核心网络的路由器。PLC/BPL接口在每个客户看来都是一个单独的虚拟接口，所有客户共享相同的物理介质。
Repeater (RPT): A device that may be required in some circumstances to improve the signal on the PLC/BPL. This may be the case if there are many customers in the same segment or building. It is often a bridge, but it could also be a router if, for example, there is a lot of peer-to-peer traffic in a building and due to the master-slave nature of the PLC/BPL technology, is required to improve the performance within that segment. For simplicity within this document, the RPT will always be considered a transparent Layer 2 bridge, so it may or may not be present (from the Layer 3 point of view).
中继器（RPT）：在某些情况下可能需要的设备，用于改善PLC/BPL上的信号。如果同一细分市场或建筑中有许多客户，则可能会出现这种情况。它通常是一个网桥，但也可以是一个路由器，例如，如果建筑物中存在大量对等通信，并且由于PLC/BPL技术的主从性质，需要改进该段内的性能。为了在本文档中简单起见，RPT将始终被视为透明的第2层桥接，因此它可能存在，也可能不存在（从第3层的角度来看）。
Customer Premise Equipment (CPE): Modem (internal to the host), modem/bridge (BCPE), router (RCPE), or any combination among those (i.e., modem+bridge/router), located at the customer premise.
客户场所设备（CPE）：位于客户场所的调制解调器（主机内部）、调制解调器/网桥（BCPE）、路由器（RCPE）或它们之间的任何组合（即调制解调器+网桥/路由器）。
Edge Router (ER)
边缘路由器（ER）
Figure 9.1 depicts all the network elements indicated above.
图9.1描述了上述所有网络元件。
Customer Premise | Network Access Provider | Network Service Provider
客户场所|网络接入提供商|网络服务提供商
+-----+ +------+ +-----+ +------+ +--------+
|Hosts|--| RCPE |--| RPT |--------+ Head +---+ Edge | ISP
+-----+ +------+ +-----+ | End | | Router +=>Network
+--+---+ +--------+
+-----+ +------+ +-----+ |
|Hosts|--| BCPE |--| RPT |-----------+
+-----+ +------+ +-----+
+-----+ +------+ +-----+ +------+ +--------+
|Hosts|--| RCPE |--| RPT |--------+ Head +---+ Edge | ISP
+-----+ +------+ +-----+ | End | | Router +=>Network
+--+---+ +--------+
+-----+ +------+ +-----+ |
|Hosts|--| BCPE |--| RPT |-----------+
+-----+ +------+ +-----+
Figure 9.1
图9.1
The logical topology and design of PLC/BPL is very similar to Ethernet Broadband Networks as discussed in Section 7. IP connectivity is typically provided in a Point-to-Point model, as described in Section 7.2.1
PLC/BPL的逻辑拓扑和设计与第7节中讨论的以太网宽带网络非常相似。IP连接通常以点对点模式提供，如第7.2.1节所述
The most simplistic and efficient model, considering the nature of the PLC/BPL networks, is to see the network as a point-to-point, one to each customer. Even if several customers share the same physical media, the traffic is not visible among them because each one uses different channels, which are, in addition, encrypted by means of 3DES.
考虑到PLC/BPL网络的性质，最简单有效的模型是将网络视为点对点，每个客户一对一。即使多个客户共享相同的物理介质，他们之间的流量也不可见，因为每个客户使用不同的通道，这些通道还通过3DES加密。
In order to maintain the deployment concepts and business models proven and used with existing revenue-generating IPv4 services, the IPv6 deployment will match the IPv4 one. Under certain circumstances where new service types or service needs justify it, IPv4 and IPv6 network architectures could be different. Both approaches are very similar to those already described for the Ethernet case.
为了维护经验证并用于现有创收IPv4服务的部署概念和业务模型，IPv6部署将与IPv4部署相匹配。在某些情况下，新的服务类型或服务需求证明了这一点，IPv4和IPv6网络架构可能会有所不同。这两种方法与以太网案例中已经描述的方法非常相似。
In this scenario, only the RPT is Layer 3 unaware, but the other devices have to be upgraded to dual stack Hosts, RCPE, Head End, and Edge Router.
在这种情况下，只有RPT是第3层不知道的，但其他设备必须升级到双栈主机、RCPE、前端和边缘路由器。
The Hosts or the RCPEs have the HE as their Layer 3 next hop.
主机或RCPE将HE作为其第3层下一跳。
If there is no RCPE, but instead a BCPE, all the hosts on the subscriber site belong to the same /64 subnet that is statically configured on the HE. The hosts can use stateless auto-configuration or stateful DHCPv6-based configuration to acquire an address via the HE.
如果没有RCPE，而是BCPE，则订阅服务器站点上的所有主机都属于在HE上静态配置的同一/64子网。主机可以使用无状态自动配置或基于状态DHCPv6的配置通过HE获取地址。
If an RCPE is present:
如果存在RCPE：
A. It is statically configured with an address on the /64 subnet between itself and the HE, and with /64 prefixes on the interfaces connecting the hosts on the customer site. This is not a desired provisioning method, being expensive and difficult to manage.
A.静态配置为在其自身和HE之间的/64子网上有一个地址，在连接客户站点上主机的接口上有/64前缀。这不是一种理想的资源调配方法，成本高昂且难以管理。
B. It can use its link-local address to communicate with the HE. It can also dynamically acquire through stateless auto-configuration the address for the link between itself and the HE. This step is
B.可使用其链接本地地址与HE通信。它还可以通过无状态自动配置动态获取自身与HE之间链接的地址。这一步很简单
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.
然后通过DHCP-PD请求短于/64（通常为/48[RFC3177]）的前缀，该前缀被划分为/64，并分配给连接客户站点上主机的接口。这应该是首选的资源调配方法，更便宜，更易于管理。
The Edge Router needs to have a prefix, considering that each customer in general will receive a /48 prefix, and that each HE will accommodate customers. Consequently, each HE will require n x /48 prefixes.
边缘路由器需要有一个前缀，考虑到每个客户通常都会收到一个/48前缀，并且每个HE都会容纳客户。因此，每个HE都需要n x/48个前缀。
It could be possible to use a kind of Hierarchical Prefix Delegation to automatically provision the required prefixes and fully auto-configure the HEs, and consequently reduce the network setup, operation, and maintenance cost.
可以使用一种分级前缀委托来自动提供所需的前缀并完全自动配置HEs，从而降低网络设置、操作和维护成本。
The prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned in a manner that allows as much summarization as possible at the Edge Router.
用于订户链路的前缀和通过DHCP-PD委托的前缀应以允许在边缘路由器上尽可能多地汇总的方式进行规划。
Other information of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
主机感兴趣的其他信息，如DNS，通过有状态[RFC3315]和无状态[RFC3736]DHCPv6提供。
If no routers are used on the customer premise, the HE can simply be configured with a default route that points to the Edge Router. If a router is used on the customer premise (RCPE), then the HE could also run an IGP (such as OSPFv3, IS-IS or even RIPng) to the ER. The connected prefixes should be redistributed. If DHCP-PD is used, with every delegated prefix a static route is installed by the HE. For this reason, the static routes must also be redistributed. Prefix summarization should be done at the HE.
如果在客户场所未使用路由器，则可以简单地为HE配置指向边缘路由器的默认路由。如果在客户场所（RCPE）使用路由器，则HE还可以向ER运行IGP（如OSPFv3、is-is甚至RIPng）。应重新分配连接的前缀。如果使用DHCP-PD，则HE将通过每个委派前缀安装静态路由。因此，静态路由也必须重新分配。前缀摘要应在HE处完成。
The RCPE requires only a default route pointing to the HE. No routing protocols are needed on these devices, which generally have limited resources.
RCPE只需要指向HE的默认路由。这些设备通常资源有限，不需要路由协议。
The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. The connected prefixes have to be redistributed, as well as any routing protocols (other than the ones used on the ER) that might be used between the HE and the ER.
边缘路由器运行NSP中使用的IPv6 IGP:OSPFv3或IS-IS。必须重新分配连接的前缀，以及可能在HE和ER之间使用的任何路由协议（ER上使用的路由协议除外）。
The considerations regarding IPv6 Multicast for Ethernet are also applicable here, in general, assuming the nature of PLC/BPL is a shared media. If a lot of Multicast is expected, it may be worth considering using RPT which are Layer 3 aware. In that case, one extra layer of Hierarchical DHCP-PD could be considered, in order to facilitate the deployment, operation, and maintenance of the network.
一般来说，假设PLC/BPL的本质是一种共享介质，关于以太网IPv6多播的考虑也适用于此。如果需要大量的多播，那么可以考虑使用支持第3层的RPT。在这种情况下，可以考虑一个额外的分层DHCP-PD层，以便于网络的部署、操作和维护。
The considerations introduced for QoS in Ethernet are also applicable here. PLC/BPL networks support QoS, which basically is the same whether the transport is IPv4 or IPv6. It is necessary to understand that there are specific network characteristics, such as the variability that may be introduced by electrical noise, towards which the PLC/BPL network will automatically self-adapt.
以太网中引入的QoS注意事项也适用于此处。PLC/BPL网络支持QoS，无论传输是IPv4还是IPv6，QoS基本相同。有必要了解特定的网络特性，例如电气噪声可能引入的可变性，PLC/BPL网络将自动适应这些特性。
There are no differences in terms of security considerations if compared with the Ethernet case.
如果与以太网案例相比，在安全考虑方面没有差异。
The issues related to IPv6 Network Management in PLC networks should be similar to those discussed for Broadband Ethernet Networks in Section 7.6. Note that there may be a need to define MIB modules for PLC networks and interfaces, but this is not necessarily related to IPv6 management.
PLC网络中与IPv6网络管理相关的问题应类似于第7.6节中针对宽带以太网所讨论的问题。请注意，可能需要为PLC网络和接口定义MIB模块，但这不一定与IPv6管理相关。
Several aspects of deploying IPv6 over SP Broadband networks were highlighted in this document, aspects that require additional work in order to facilitate native deployments, as summarized below:
本文档重点介绍了在SP宽带网络上部署IPv6的几个方面，这些方面需要进行额外的工作以促进本机部署，总结如下：
A. As mentioned in section 5, changes will need to be made to the DOCSIS specification in order for SPs to deploy native IPv6 over cable networks. The CM and CMTS will both need to support IPv6 natively in order to forward IPv6 unicast and multicast traffic. This is required for IPv6 Neighbor Discovery to work over DOCSIS cable networks. Additional classifiers need to be added to the DOCSIS specification in order to classify IPv6 traffic at the CM and CMTS in order to provide QoS. These issues are addressed in a recent proposal made to Cable Labs for DOCSIS 3.0 [DOCSIS3.0-Reqs].
A.如第5节所述，需要对DOCSIS规范进行更改，以便SP通过有线网络部署本机IPv6。CM和CMT都需要本机支持IPv6，以便转发IPv6单播和多播流量。这是IPv6邻居发现在DOCSIS有线网络上工作所必需的。需要在DOCSIS规范中添加额外的分类器，以便在CM和CMT上对IPv6流量进行分类，以便提供QoS。这些问题在最近向电缆实验室提出的DOCSIS 3.0[DOCSIS 3.0-Reqs]提案中得到了解决。
B. Section 6 stated that current RBE-based IPv4 deployment might not be the best approach for IPv6, where the addressing space available gives the SP the opportunity to separate the users on different subnets. The differences between IPv4 RBE and IPv6 RBE were highlighted in Section 6. If, however, support and reason are found for a deployment similar to IPv4 RBE, then the environment becomes NBMA and the new feature should observe RFC2491 recommendations.
B.第6节指出，当前基于RBE的IPv4部署可能不是IPv6的最佳方法，因为可用的寻址空间使SP有机会将不同子网上的用户分开。IPv4 RBE和IPv6 RBE之间的差异在第6节中突出显示。但是，如果找到类似于IPv4 RBE的部署的支持和理由，则环境将变为NBMA，新功能应遵守RFC2491建议。
C. Section 6 discussed the constraints imposed on an LAA-based IPv6 deployment by the fact that it is expected that the subscribers keep their assigned prefix, regardless of LNS. A deployment approach was proposed that would maintain the addressing schemes contiguous and offers prefix summarization opportunities. The topic could be further investigated for other solutions or improvements.
C.第6节讨论了基于LAA的IPv6部署所受到的限制，因为无论LN如何，用户都应保留其分配的前缀。提出了一种部署方法，该方法将保持寻址方案的连续性，并提供前缀摘要机会。可以进一步研究该主题，以寻求其他解决方案或改进。
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链路上运行任何第3层协议时，这些问题可能是相同的；设置未正确调整时，某些基于多播的帧将被丢弃。例如，当在具有高损耗信号比和高干扰的WLAN链路上执行时，此行为类似于IGMP主机成员资格报告。此问题由WLAN继承，可能会影响IPv4和IPv6多播数据包；它不是特定于IPv6多播的。
F. The privacy extensions were mentioned as a popular means to provide some form of host security. ISPs can track relatively easily the prefixes assigned to subscribers. If, however, the ISPs are required by regulations to track their users at host address level, the privacy extensions [RFC3041] can be implemented only in parallel with network management tools that could provide traceability of the hosts. Mechanisms should be defined to implement this aspect of user management.
F.隐私扩展被认为是提供某种形式主机安全的一种流行手段。ISP可以相对容易地跟踪分配给订户的前缀。但是，如果法规要求ISP在主机地址级别跟踪其用户，则隐私扩展[RFC3041]只能与能够提供主机跟踪的网络管理工具并行实施。应该定义机制来实现用户管理的这一方面。
G. Tunnels are an effective way to avoid deployment dependencies on the IPv6 support on platforms that are out of the SP control (GWRs or CPEs) or over technologies that did not standardize the IPv6 support yet (cable). They can be used in the following ways:
G.隧道是一种有效的方法，可以避免在SP无法控制的平台（GWR或CPE）上部署对IPv6支持的依赖，或者避免部署对尚未标准化IPv6支持的技术（电缆）的依赖。它们可通过以下方式使用：
i. Tunnels directly to the CPE or GWR with public or private IPv4 addresses.
i. 使用公共或专用IPv4地址直接到CPE或GWR的隧道。
ii. Tunnels directly to hosts with public or private IPv4 addresses. Recommendations on the exact tunneling mechanisms that can/should be used for last-mile access need to be investigated further and should be addressed by the IETF Softwire Working Group.
二、通过隧道直接连接到具有公共或专用IPv4地址的主机。关于最后一英里通道可以/应该使用的确切隧道机制的建议需要进一步调查，并应由IETF软线工作组解决。
H. Through its larger address space, IPv6 allows SPs to assign fixed, globally routable prefixes to the links connecting each subscriber.
H.通过更大的地址空间，IPv6允许SP向连接每个订户的链路分配固定的、全局可路由的前缀。
This approach changes the provisioning methodologies that were used for IPv4. Static configuration of the IPv6 addresses for all these links on the Edge Routers or Access Routers might not be a scalable option. New provisioning mechanisms or features might need to be developed in order to deal with this issue, such as automatic mapping of VLAN IDs/PVCs (or other customer-specific information) to IPv6 prefixes.
此方法更改了IPv4使用的配置方法。边缘路由器或访问路由器上所有这些链路的IPv6地址的静态配置可能不是一个可扩展选项。为了解决这个问题，可能需要开发新的资源调配机制或功能，例如将VLAN ID/PVC（或其他特定于客户的信息）自动映射到IPv6前缀。
I. New deployment models are emerging for the Layer 2 portion of the NAP where individual VLANs are not dedicated to each subscriber. This approach allows Layer 2 switches to aggregate more then 4096 users. MAC Forced Forwarding [RFC4562] is an example of such an implementation, where a broadcast domain is turned into an NBMA-like environment by forwarding the frames based on both Source and Destination MAC addresses. Since these models are being adopted by the field, the implications of deploying IPv6 in such environments need to be further investigated.
I.NAP的第2层部分出现了新的部署模型，其中单个VLAN不专用于每个订户。这种方法允许第2层交换机聚合超过4096个用户。MAC强制转发[RFC4562]是这种实现的示例，其中通过基于源和目的MAC地址转发帧，将广播域转变为类似于NBMA的环境。由于这些模型正在被现场采用，因此需要进一步研究在此类环境中部署IPv6的影响。
J. The deployment of IPv6 in continuously evolving access service models raises some issues that may need further investigation. Examples of such topics are [AUTO-CONFIG]:
J.在不断发展的接入服务模型中部署IPv6提出了一些需要进一步研究的问题。此类主题的示例包括[自动配置]：
i. Network Service Selection & Authentication (NSSA) mechanisms working in association with stateless auto-configuration. As an example, NSSA relevant information, such as ISP preference, passwords, or profile ID, can be sent by hosts with the RS [RFC4191].
i. 与无状态自动配置相关联的网络服务选择和认证（NSSA）机制。例如，NSSA相关信息，如ISP首选项、密码或配置文件ID，可以由主机通过RS[RFC4191]发送。
ii. Providing additional information in Router Advertisements to help access nodes with prefix selection in multi-ISP/ multi-homed environments.
二、在路由器广告中提供附加信息，以帮助在多ISP/多宿环境中通过前缀选择访问节点。
Solutions to some of these topics range from making a media access capable of supporting native IPv6 (cable) to improving operational aspects of native IPv6 deployments.
其中一些主题的解决方案包括使媒体访问能够支持本机IPv6（电缆）到改进本机IPv6部署的操作方面。
Please refer to the individual "IPv6 Security Considerations" technology sections for details.
有关详细信息，请参阅各个“IPv6安全注意事项”技术部分。
We would like to thank Brian Carpenter, Patrick Grossetete, Toerless Eckert, Madhu Sudan, Shannon McFarland, Benoit Lourdelet, and Fred Baker for their valuable comments. The authors would like to acknowledge the structure and information guidance provided by the work of Mickles, et al., on "Transition Scenarios for ISP Networks" [ISP-CASES].
我们要感谢Brian Carpenter、Patrick Grossette、Toerless Eckert、Madhu Sudan、Shannon McFarland、Benoit Lourdelet和Fred Baker的宝贵意见。作者希望感谢Mickles等人关于“ISP网络的过渡场景”[ISP-CASES]的工作提供的结构和信息指导。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC2080]Malkin，G.和R.Minnear，“IPv6的RIPng”，RFC20801997年1月。
[RFC2364] Gross, G., Kaycee, M., Lin, A., Malis, A., and J. Stephens, "PPP Over AAL5", RFC 2364, July 1998.
[RFC2364]Gross，G.，Kaycee，M.，Lin，A.，Malis，A.，和J.Stephens，“AAL5上的购买力平价”，RFC 2364，1998年7月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC2462，1998年12月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2516]Mamakos，L.，Lidl，K.，Evarts，J.，Carrel，D.，Simone，D.，和R.Wheeler，“通过以太网传输PPP（PPPoE）的方法”，RFC 2516，1999年2月。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2529]Carpenter，B.和C.Jung，“在没有明确隧道的IPv4域上传输IPv6”，RFC 2529，1999年3月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[RFC2740]Coltun，R.，Ferguson，D.，和J.Moy，“IPv6的OSPF”，RFC 27401999年12月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041]Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC 3041，2001年1月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053]Durand，A.，Fasano，P.，Guardini，I.，和D.Lento，“IPv6隧道代理”，RFC 3053，2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[RFC3177]IAB和IESG，“IAB/IESG对站点IPv6地址分配的建议”，RFC3177，2001年9月。
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001.
[RFC3180]Meyer，D.和P.Lothberg，“233/8中的GLOP寻址”，BCP 53，RFC 31802001年9月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]Fenner，B.和D.Meyer，“多播源发现协议（MSDP）”，RFC3618，2003年10月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736]Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，2004年4月。
[RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks", RFC 3904, September 2004.
[RFC3904]Huitema，C.，Austein，R.，Satapati，S.，和R.van der Pol，“非托管网络IPv6过渡机制的评估”，RFC 3904，2004年9月。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]Lau，J.，Townsley，M.，和I.Goyret，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
[RFC4001]Daniele，M.，Haberman，B.，Routhier，S.，和J.Schoenwaeld，“互联网网络地址的文本约定”，RFC 4001，2005年2月。
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[RFC4029]Lind，M.，Ksinant，V.，Park，S.，Baudot，A.，和P.Savola，“将IPv6引入ISP网络的场景和分析”，RFC 40292005年3月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191]Draves，R.和D.Thaler，“默认路由器首选项和更具体的路由”，RFC 41912005年11月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, October 2005.
[RFC4214]Templin，F.，Gleeson，T.，Talwar，M.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 4214，2005年10月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[6PE] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands across IPv4 Clouds with BGP", Work in Progress, December 2006.
[6PE]De Clercq，J.，Ooms，D.，Prevost，S.，和F.Le Faucheur，“通过BGP跨IPv4云连接IPv6岛”，正在进行的工作，2006年12月。
[AUTO-CONFIG] Wen, H., Zhu, X., Jiang, Y., and R. Yan, "The deployment of IPv6 stateless auto-configuration in access network", 8th International Conference on Telecommunications, ConTEL 2005, June 2005.
[AUTO-CONFIG]温，H.，朱，X.，蒋，Y.，和R.Yan，“IPv6无状态自动配置在接入网中的部署”，第八届国际电信大会，ConTEL 2005，2005年6月。
[BSR] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for PIM", Work in Progress, June 2006.
[BSR]Bhaskar，N.，Gall，A.，Lingard，J.，和S.Venaas，“PIM引导路由器（BSR）机制”，正在进行的工作，2006年6月。
[DOCSIS3.0-OSSI] CableLabs, CL., "DOCSIS 3.0 OSSI Specification(CM-SP-OSSIv3.0-D02-060504)", May 2006.
[DOCSIS 3.0-OSSI]CableLabs，CL.，“DOCSIS 3.0 OSSI规范（CM-SP-OSSIv3.0-D02-060504）”，2006年5月。
[DOCSIS3.0-Reqs] Droms, R., Durand, A., Kharbanda, D., and J-F. Mule, "DOCSIS 3.0 Requirements for IPv6 Support", Work in Progress, March 2006.
[DOCSIS 3.0-Reqs]Droms，R.，Durand，A.，Kharbanda，D.，和J-F.Mule，“IPv6支持的DOCSIS 3.0要求”，正在进行的工作，2006年3月。
[DynamicTunnel] Palet, J., Diaz, M., and P. Savola, "Analysis of IPv6 Tunnel End-point Discovery Mechanisms", Work in Progress, January 2005.
[DynamicTunnel]Palet，J.，Diaz，M.，和P.Savola，“IPv6隧道端点发现机制的分析”，正在进行的工作，2005年1月。
[IEEE80211i] IEEE, "IEEE Standards for Information Technology: Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications, Amendment 6: Medium Access Control (MAC) Security Enhancements", July 2004.
[IEEE801I]IEEE，“IEEE信息技术标准：第11部分：无线局域网介质访问控制（MAC）和物理层（PHY）规范，修改件6：介质访问控制（MAC）安全增强”，2004年7月。
[IEEE8021X] IEEE, "IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001", June 2001.
[IEEE8021X]IEEE，“局域网和城域网的IEEE标准：基于端口的网络访问控制，IEEE标准802.1X-2001”，2001年6月。
[IPv6-Multicast] Savola, P., "IPv6 Multicast Deployment Issues", Work in Progress, April 2004.
[IPv6多播]Savola，P.，“IPv6多播部署问题”，正在进行的工作，2004年4月。
[IPv6-Security] Convery, S. and D. Miller, "IPv6 and IPv4 Threat Comparison and Best-Practice Evaluation", March 2004.
[IPv6安全]Convery，S.和D.Miller，“IPv6和IPv4威胁比较和最佳实践评估”，2004年3月。
[ISISv6] Hopps, C., "Routing IPv6 with IS-IS", Work in Progress, October 2005.
[ISISv6]Hopps，C.，“使用IS-IS路由IPv6”，正在进行的工作，2005年10月。
[ISP-CASES] Mickles, C., "Transition Scenarios for ISP Networks", Work in Progress, September 2002.
[ISP案例]Mickles，C.，“ISP网络的过渡场景”，正在进行的工作，2002年9月。
[Protocol41] Palet, J., Olvera, C., and D. Fernandez, "Forwarding Protocol 41 in NAT Boxes", Work in Progress, October 2003.
[Protocol41]Palet，J.，Olvera，C.，和D.Fernandez，“NAT盒中的转发协议41”，正在进行的工作，2003年10月。
[RF-Interface] CableLabs, CL., "DOCSIS 2.0(CM-SP-RFIv2.0-I10- 051209)", December 2005.
[射频接口]CableLabs，CL.，“DOCSIS 2.0（CM-SP-RFIv2.0-I10-051209）”，2005年12月。
[RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network", RFC 4562, June 2006.
[RFC4562]Melsen，T.和S.Blake，“MAC强制转发：以太网接入网络上用户分离的方法”，RFC 45622，2006年6月。
[Softwire] Dawkins, S., Ed., "Softwire Problem Statement", Work in Progress, May 2006.
[Softwire]Dawkins，S.，Ed.，“Softwire问题陈述”，正在进行的工作，2006年5月。
[v6tc] Palet, J., Nielsent, K., Parent, F., Durand, A., Suryanarayanan, R., and P. Savola, "Goals for Tunneling Configuration", Work in Progress, August 2005.
[v6tc]Palet，J.，Nielsent，K.，Parent，F.，Durand，A.，Suryanarayanan，R.，和P.Savola，“隧道结构的目标”，正在进行的工作，2005年8月。
Authors' Addresses
作者地址
Salman Asadullah Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
Phone: 408 526 8982 EMail: sasad@cisco.com
电话：408 526 8982电子邮件：sasad@cisco.com
Adeel Ahmed Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA
阿德尔·艾哈迈德·思科系统2200美国德克萨斯州东总统乔治·布什收费公路理查森75082
Phone: 469 255 4122 EMail: adahmed@cisco.com
电话：469 255 4122电子邮件：adahmed@cisco.com
Ciprian Popoviciu Cisco Systems 7025-6 Kit Creek Road Research Triangle Park, NC 27709 USA
Ciprian Popoviciu Cisco Systems 7025-6 Kit Creek Road Research Triangle Park，美国北卡罗来纳州27709
Phone: 919 392 3723 EMail: cpopovic@cisco.com
电话：9193923723电子邮件：cpopovic@cisco.com
Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland
Pekka Savola CSC-科学计算有限公司，芬兰埃斯波
EMail: psavola@funet.fi
EMail: psavola@funet.fi
Jordi Palet Martinez Consulintel San Jose Artesano, 1 Alcobendas, Madrid E-28108 Spain
Jordi Palet Martinez圣何塞Artesano领事馆，地址：西班牙马德里阿尔科本达斯1号E-28108
Phone: +34 91 151 81 99
EMail: jordi.palet@consulintel.es
Phone: +34 91 151 81 99
EMail: jordi.palet@consulintel.es
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。