draft-ietf-v6ops-bb-deployment-scenarios-05.txt   rfc4779.txt 
Network Working Group S. Asadullah Network Working Group S. Asadullah
Internet-Draft A. Ahmed Request for Comments: 4779 A. Ahmed
Expires: December 9, 2006 C. Popoviciu Category: Informational C. Popoviciu
Cisco Systems Cisco Systems
P. Savola P. Savola
CSC/FUNET CSC/FUNET
J. Palet J. Palet
Consulintel Consulintel
June 7, 2006 January 2007
ISP IPv6 Deployment Scenarios in Broadband Access Networks ISP IPv6 Deployment Scenarios in Broadband Access Networks
<draft-ietf-v6ops-bb-deployment-scenarios-05.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 9, 2006. 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 Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document provides detailed description of IPv6 deployment and This document provides a detailed description of IPv6 deployment and
integration methods and scenarios in today's Service Provider (SP) integration methods and scenarios in today's Service Provider (SP)
Broadband (BB) networks in coexistence with deployed IPv4 services. Broadband (BB) networks in coexistence with deployed IPv4 services.
Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies
that are currently deployed, and discussed in this document. The that are currently deployed, and discussed in this document. The
emerging Broadband Power Line Communications (PLC/BPL) access emerging Broadband Power Line Communications (PLC/BPL) access
technology is also discussed for completeness. In this document we technology is also discussed for completeness. In this document we
will discuss main components of IPv6 BB networks and their will discuss main components of IPv6 BB networks, their differences
differences from IPv4 BB networks and how IPv6 is deployed and from IPv4 BB networks, and how IPv6 is deployed and integrated in
integrated in each of these networks using tunneling mechanisms and each of these networks using tunneling mechanisms and native IPv6.
native IPv6.
Table of Contents Table of Contents
1. Scope of the Document . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Common Terminology . . . . . . . . . . . . . . . . . . . . . . 5 2. Common Terminology . . . . . . . . . . . . . . . . . . . . . . 5
3. Core/Backbone Network . . . . . . . . . . . . . . . . . . . . 5 3. Core/Backbone Network . . . . . . . . . . . . . . . . . . . . 5
3.1. Layer 2 Access Provider Network . . . . . . . . . . . . . 5 3.1. Layer 2 Access Provider Network . . . . . . . . . . . . . 5
3.2. Layer 3 Access Provider Network . . . . . . . . . . . . . 6 3.2. Layer 3 Access Provider Network . . . . . . . . . . . . . 6
4. Tunneling Overview . . . . . . . . . . . . . . . . . . . . . . 7 4. Tunneling Overview . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Access over Tunnels - Customers with Public IPv4 4.1. Access over Tunnels - Customers with Public IPv4
Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Access over Tunnels - Customers with Private IPv4 4.2. Access over Tunnels - Customers with Private IPv4
Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Transition a Portion of the IPv4 Infrastructure . . . . . 8 4.3. Transition a Portion of the IPv4 Infrastructure . . . . . 8
5. Broadband Cable Networks . . . . . . . . . . . . . . . . . . . 9 5. Broadband Cable Networks . . . . . . . . . . . . . . . . . . . 9
5.1. Broadband Cable Network Elements . . . . . . . . . . . . . 9 5.1. Broadband Cable Network Elements . . . . . . . . . . . . . 9
5.2. Deploying IPv6 in Cable Networks . . . . . . . . . . . . . 10 5.2. Deploying IPv6 in Cable Networks . . . . . . . . . . . . . 10
5.2.1. Deploying IPv6 in a Bridged CMTS Network . . . . . . . 11 5.2.1. Deploying IPv6 in a Bridged CMTS Network . . . . . . . 12
5.2.2. Deploying IPv6 in a Routed CMTS Network . . . . . . . 14 5.2.2. Deploying IPv6 in a Routed CMTS Network . . . . . . . 14
5.2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . 23 5.2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . 23
5.2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . 24 5.2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.5. IPv6 Security Considerations . . . . . . . . . . . . . 24 5.2.5. IPv6 Security Considerations . . . . . . . . . . . . . 24
5.2.6. IPv6 Network Management . . . . . . . . . . . . . . . 25 5.2.6. IPv6 Network Management . . . . . . . . . . . . . . . 25
6. Broadband DSL Networks . . . . . . . . . . . . . . . . . . . . 26 6. Broadband DSL Networks . . . . . . . . . . . . . . . . . . . . 26
6.1. DSL Network Elements . . . . . . . . . . . . . . . . . . . 26 6.1. DSL Network Elements . . . . . . . . . . . . . . . . . . . 26
6.2. Deploying IPv6 in IPv4 DSL Networks . . . . . . . . . . . 27 6.2. Deploying IPv6 in IPv4 DSL Networks . . . . . . . . . . . 28
6.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 28 6.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 29
6.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 30 6.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 30
6.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 32 6.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 33
6.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 35 6.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 36
6.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 37 6.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 38
6.3.1. ASM Based Deployments . . . . . . . . . . . . . . . . 38 6.3.1. ASM-Based Deployments . . . . . . . . . . . . . . . . 39
6.3.2. SSM Based Deployments . . . . . . . . . . . . . . . . 38 6.3.2. SSM-Based Deployments . . . . . . . . . . . . . . . . 39
6.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 40 6.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 41
6.6. IPv6 Network management . . . . . . . . . . . . . . . . . 40 6.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 42
7. Broadband Ethernet Networks . . . . . . . . . . . . . . . . . 41 7. Broadband Ethernet Networks . . . . . . . . . . . . . . . . . 42
7.1. Ethernet Access Network Elements . . . . . . . . . . . . . 41 7.1. Ethernet Access Network Elements . . . . . . . . . . . . . 42
7.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks . . . . 42 7.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks . . . . 43
7.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 43 7.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 44
7.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 45 7.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 46
7.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 47 7.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 48
7.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 48 7.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 50
7.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 51 7.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 52
7.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 52 7.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 52 7.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 54
7.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 53 7.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 55
8. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . 54 8. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.1. WLAN Deployment Scenarios . . . . . . . . . . . . . . . . 54 8.1. WLAN Deployment Scenarios . . . . . . . . . . . . . . . . 55
8.1.1. Layer 2 NAP with Layer 3 termination at NSP Edge 8.1.1. Layer 2 NAP with Layer 3 termination at NSP Edge
Router . . . . . . . . . . . . . . . . . . . . . . . . 55 Router . . . . . . . . . . . . . . . . . . . . . . . . 56
8.1.2. Layer 3 aware NAP with Layer 3 termination at 8.1.2. Layer 3 Aware NAP with Layer 3 Termination at
Access Router . . . . . . . . . . . . . . . . . . . . 57 Access Router . . . . . . . . . . . . . . . . . . . . 59
8.1.3. PPP Based Model . . . . . . . . . . . . . . . . . . . 60 8.1.3. PPP-Based Model . . . . . . . . . . . . . . . . . . . 61
8.2. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 62 8.2. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 63
8.3. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 63 8.3. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.4. IPv6 Security Considerations . . . . . . . . . . . . . . . 63 8.4. IPv6 Security Considerations . . . . . . . . . . . . . . . 65
8.5. IPv6 Network Management . . . . . . . . . . . . . . . . . 65 8.5. IPv6 Network Management . . . . . . . . . . . . . . . . . 67
9. Broadband Power Line Communications (PLC) . . . . . . . . . . 65 9. Broadband Power Line Communications (PLC) . . . . . . . . . . 67
9.1. PLC/BPL Access Network Elements . . . . . . . . . . . . . 66 9.1. PLC/BPL Access Network Elements . . . . . . . . . . . . . 68
9.2. Deploying IPv6 in IPv4 PLC/BPL . . . . . . . . . . . . . . 67 9.2. Deploying IPv6 in IPv4 PLC/BPL . . . . . . . . . . . . . . 69
9.2.1. IPv6 Related Infrastructure Changes . . . . . . . . . 67 9.2.1. IPv6 Related Infrastructure Changes . . . . . . . . . 69
9.2.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 67 9.2.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 69
9.2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 68 9.2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 70
9.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 69 9.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 71
9.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 69 9.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 69 9.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 71
9.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 69 9.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 71
10. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 69 10. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 71
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 11. Security Considerations . . . . . . . . . . . . . . . . . . . 74
12. Security Considerations . . . . . . . . . . . . . . . . . . . 72 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 74
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 72 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 13.1. Normative References . . . . . . . . . . . . . . . . . . . 74
14.1. Normative References . . . . . . . . . . . . . . . . . . . 72 13.2. Informative References . . . . . . . . . . . . . . . . . . 76
14.2. Informative References . . . . . . . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77
Intellectual Property and Copyright Statements . . . . . . . . . . 79
1. Scope of the Document 1. Introduction
This document presents the options available in deploying IPv6 This document presents the options available in deploying IPv6
services in the access portion of a BB Service Provider network services in the access portion of a BB Service Provider (SP) network
namely Cable/HFC, BB Ethernet, xDSL, WLAN and PLC/BPL. - namely Cable/HFC, BB Ethernet, xDSL, WLAN, and PLC/BPL.
This document briefly discusses the other elements of a provider This document briefly discusses the other elements of a provider
network as well. It provides different viable IPv6 deployment and network as well. It provides different viable IPv6 deployment and
integration techniques and models for each of the above mentioned BB integration techniques, and models for each of the above-mentioned BB
technologies individually. The example list is not exhaustive but it technologies individually. The example list is not exhaustive, but
tries to be representative. it tries to be representative.
This document analyzes, how all the important components of current This document analyzes how all the important components of current
IPv4 based Cable/HFC, BB Ethernet, xDSL, WLAN and PLC/BPL networks IPv4-based Cable/HFC, BB Ethernet, xDSL, WLAN, and PLC/BPL networks
will behave when IPv6 is integrated and deployed. will behave when IPv6 is integrated and deployed.
The following important pieces are discussed: The following important pieces are discussed:
A. Available tunneling options A. Available tunneling options
B. Devices that would require to be upgraded to support IPv6 B. Devices that would have to be upgraded to support IPv6
C. Available IPv6 address assignment techniques and their use C. Available IPv6 address assignment techniques and their use
D. Possible IPv6 Routing options and their use D. Possible IPv6 Routing options and their use
E. IPv6 unicast and multicast packet transmission E. IPv6 unicast and multicast packet transmission
F. Required IPv6 QoS parameters F. Required IPv6 Quality of Service (QoS) parameters
G. Required IPv6 Security parameters G. Required IPv6 Security parameters
H. Required IPv6 Network Management parameters H. Required IPv6 Network Management parameters
It is important to note that the addressing rules provided throughout It is important to note that the addressing rules provided throughout
this document represent an example that follows the current this document represent an example that follows the current
assignment policies and recommendations of the registries. They can assignment policies and recommendations of the registries. However,
be however adapted to the network and business model needs of the they can be adapted to the network and business model needs of the
ISPs. ISPs.
The scope of the document is to advise on the ways of upgrading an The scope of the document is to advise on the ways of upgrading an
existing infrastructure to support IPv6 services. The recommendation existing infrastructure to support IPv6 services. The recommendation
to upgrade a device to dual-stack does not stop an SP from adding a 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 new device to its network to perform the necessary IPv6 functions
discussed. The costs involved with such an approach could be offset discussed. The costs involved with such an approach could be offset
by lower impact on the existing IPv4 services. by lower impact on the existing IPv4 services.
2. Common Terminology 2. Common Terminology
BB: Broadband BB: Broadband
CPE: Customer Premise Equipment CPE: Customer Premise Equipment
skipping to change at page 5, line 40 skipping to change at page 5, line 40
There are two types of networks identified in the Broadband There are two types of networks identified in the Broadband
deployments: deployments:
A. Access Provider Network: This network provides the broadband A. Access Provider Network: This network provides the broadband
access and aggregates the subscribers. The subscriber traffic is access and aggregates the subscribers. The subscriber traffic is
handed over to the Service Provider at Layer 2 or 3. handed over to the Service Provider at Layer 2 or 3.
B. Service Provider Network: This network provides Intranet and B. Service Provider Network: This network provides Intranet and
Internet IP connectivity for the subscribers. Internet IP connectivity for the subscribers.
The Service Provider network structure beyond the Edge routers that The Service Provider network structure beyond the Edge Routers that
interface with the Access provider is beyond the scope of this interface with the Access provider is beyond the scope of this
document. document.
3.1. Layer 2 Access Provider Network 3.1. Layer 2 Access Provider Network
The Access Provider can deploy a Layer 2 network and perform no The Access Provider can deploy a Layer 2 network and perform no
routing of the subscriber traffic to the SP. The devices that routing of the subscriber traffic to the SP. The devices that
support each specific access technology are aggregated into a highly support each specific access technology are aggregated into a highly
redundant, resilient and scalable Layer 2 core. The network core can redundant, resilient, and scalable Layer 2 core. The network core
involve various technologies such as Ethernet, ATM etc. The Service can involve various technologies such as Ethernet, Asynchronous
Provider Edge Router connects to the Access Provider core. Transfer Mode (ATM), etc. The Service Provider Edge Router connects
to the Access Provider core.
This type of network may be transparent to the Layer 3 protocol. This type of network may be transparent to the Layer 3 protocol.
Some possible changes may come with the intent of supporting IPv6 Some possible changes may come with the intent of supporting IPv6
provisioning mechanisms as well as filtering and monitoring IPv6 provisioning mechanisms, as well as filtering and monitoring IPv6
traffic based on layer 2 information such as IPv6 Ether Type Protocol traffic based on Layer 2 information such as IPv6 Ether Type Protocol
ID (0x86DD) or IPv6 multicast specific MAC addresses ID (0x86DD) or IPv6 multicast specific Media Access Control (MAC)
(33:33:xx:xx:xx:xx). addresses (33:33:xx:xx:xx:xx).
3.2. Layer 3 Access Provider Network 3.2. Layer 3 Access Provider Network
The Access Provider can choose to terminate the Layer 2 domain and The Access Provider can choose to terminate the Layer 2 domain and
route the IP traffic to the Service Provider network. Access Routers route the IP traffic to the Service Provider network. Access Routers
are used to aggregate the subscriber traffic and route it over a 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 Layer 3 core to the SP Edge Routers. In this case, the impact of the
IPv6 deployment is significant. IPv6 deployment is significant.
The case studies in this document discuss only the relevant network The case studies in this document discuss only the relevant network
elements of such a network: Customer Premise Equipment, Access Router elements of such a network: Customer Premise Equipment, Access
and Edge Router. In real networks the link between the Access Router Router, and Edge Router. In real networks, the link between the
and the Edge Router involves other routers that are part of the Access Router and the Edge Router involves other routers that are
aggregation and the core layer of the Access Provider network. 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 The Access Provider can forward the IPv6 traffic through its Layer 3
core in three possible ways: core in three possible ways:
A. IPv6 Tunneling: As a temporary solution, the Access Provider can A. IPv6 Tunneling: As a temporary solution, the Access Provider can
choose to use a tunneling mechanism to forward the subscriber IPv6 choose to use a tunneling mechanism to forward the subscriber
traffic to the Service Provider Edge Router. This approach has the IPv6 traffic to the Service Provider Edge Router. This approach
least impact on the Access Provider network however, as the number of has the least impact on the Access Provider network; however, as
users increase and the amount of IPv6 traffic grows, the ISP will the number of users increase and the amount of IPv6 traffic
have to evolve to one of the scenarios listed below. grows, the ISP will have to evolve to one of the scenarios listed
below.
B. Native IPv6 Deployment: The Access Provider routers are upgraded B. Native IPv6 Deployment: The Access Provider routers are upgraded
to support IPv6 and can become dual-stack. In a dual-stack network to support IPv6 and can become dual stack. In a dual-stack
an IPv6 IGP such as OSPFv3 [RFC2740] or IS-IS [ISISv6] is enabled. network, an IPv6 Interior Gateway Protocol (IGP), such as OSPFv3
RFC4029 [RFC4029] discusses the IGP selection options with their [RFC2740] or IS-IS [ISISv6], is enabled. RFC 4029 [RFC4029]
benefits and drawbacks. discusses the IGP selection options with their benefits and
drawbacks.
C. MPLS 6PE Deployment [6PE]: If the Access Provider is running MPLS 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 its IPv4 core, it could use 6PE to forward IPv6 traffic over
In this case only a subset of routers close to the edge of the it. In this case, only a subset of routers close to the edge of
network need to be IPv6 aware. With this approach BGP becomes the network need to be IPv6 aware. With this approach, BGP
important in order to support 6PE. becomes important in order to support 6PE.
The 6PE approach has the advantage of having minimal impact on the The 6PE approach has the advantage of having minimal impact on the
Access Provider network. Fewer devices need to be upgraded and Access Provider network. Fewer devices need to be upgraded and
configured while the MPLS core continues to switch the traffic un- configured while the MPLS core continues to switch the traffic,
aware of the fact that it transports both IPv4 and IPv6. 6PE should unaware that it transports both IPv4 and IPv6. 6PE should be
be leveraged only if MPLS is already deployed in the network. At the leveraged only if MPLS is already deployed in the network. At the
time of writing this document, a major disadvantage of the 6PE time of writing this document, a major disadvantage of the 6PE
solution is the fact that it does not support multicast IPv6 traffic. solution is that it does not support multicast IPv6 traffic.
The native approach has the advantage of supporting IPv6 multicast The native approach has the advantage of supporting IPv6 multicast
traffic but it may imply a significant impact on the IPv4 operational traffic, but it may imply a significant impact on the IPv4
network from software, configuration and possibly hardware upgrade operational network in terms of software configuration and possibly
perspective. hardware upgrade.
More detailed Core Network deployment recommendations are discussed More detailed Core Network deployment recommendations are discussed
in other documents [RFC4029]. The handling of IPv6 traffic in the in other documents [RFC4029]. The handling of IPv6 traffic in the
Core of the Access Provider Network will not be discussed for the Core of the Access Provider Network will not be discussed for the
remainder of this document. remainder of this document.
4. Tunneling Overview 4. Tunneling Overview
If SPs are not able to deploy native IPv6, they might use tunneling If SPs are not able to deploy native IPv6, they might use tunneling-
based transition mechanisms to start an IPv6 service offering and based transition mechanisms to start an IPv6 service offering, and
move to native IPv6 deployment at a later time. move to native IPv6 deployment at a later time.
Several tunneling mechanisms were developed specifically to transport Several tunneling mechanisms were developed specifically to transport
IPv6 over existing IPv4 infrastructures. Several of them have been IPv6 over existing IPv4 infrastructures. Several of them have been
standardized and their use depends on the existing SP IPv4 network standardized and their use depends on the existing SP IPv4 network
and the structure of the IPv6 service. The requirements for the most and the structure of the IPv6 service. The requirements for the most
appropriate mechanisms are described in [v6tc] with more updates to appropriate mechanisms are described in [v6tc] with more updates to
follow. Deploying IPv6 using tunneling techniques can imply as follow. Deploying IPv6 using tunneling techniques can imply as
little changes to the network as upgrading software on tunnel end little changes to the network as upgrading software on tunnel end
points. A Service Provider could use tunneling to deploy IPv6 in the points. A Service Provider could use tunneling to deploy IPv6 in the
following scenarios: following scenarios:
4.1. Access over Tunnels - Customers with Public IPv4 Address 4.1. Access over Tunnels - Customers with Public IPv4 Addresses
If the customer is a residential user, it can initiate the tunnel If the customer is a residential user, it can initiate the tunnel
directly from the IPv6 capable host to a tunnel termination router directly from the IPv6 capable host to a tunnel termination router
located in the NAP or ISP network. The tunnel type used should be located in the NAP or ISP network. The tunnel type used should be
decided by the SP but it should take into consideration its decided by the SP, but it should take into consideration its
availability on commonly used software running on the host machine. availability on commonly used software running on the host machine.
Out of the many tunneling mechanisms developed such as IPv6 Tunnel Of the many tunneling mechanisms developed, such as IPv6 Tunnel
Broker [RFC3053], Connection of IPv6 Domains via IPv4 Clouds Broker [RFC3053], Connection of IPv6 Domains via IPv4 Clouds
[RFC3056], Generic Packet Tunneling in IPv6 [RFC2473], ISATAP [RFC3056], Generic Packet Tunneling in IPv6 [RFC2473], ISATAP
[RFC4214], Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4214], Basic Transition Mechanisms for IPv6 Hosts and Routers
[RFC4213] and Transmission of IPv6 over IPv4 Domains without Explicit [RFC4213], and Transmission of IPv6 over IPv4 Domains without
Tunnels [RFC2529] some are more popular than the others. At the time Explicit Tunnels [RFC2529], some are more popular than the others.
of writing this document, the IETF Softwire Working Group was tasked At the time of writing this document, the IETF Softwire Working Group
with standardizing a single tunneling protocol [Softwire] for this was tasked with standardizing a single tunneling protocol [Softwire]
application. for this application.
If the end customer has a GWR installed, then it could be used to If the end customer has a GWR installed, then it could be used to
originate the tunnel and thus offer native IPv6 access to multiple originate the tunnel, thus offering native IPv6 access to multiple
hosts on the customer network. In this case the GWR would need to be hosts on the customer network. In this case, the GWR would need to
upgraded to dual-stack in order to support IPv6. The GWR can be be upgraded to dual stack in order to support IPv6. The GWR can be
owned by the customer or by the SP. owned by the customer or by the SP.
4.2. Access over Tunnels - Customers with Private IPv4 Address 4.2. Access over Tunnels - Customers with Private IPv4 Addresses
If the end customer receives a private IPv4 address and needs to If the end customer receives a private IPv4 address and needs to
initiate a tunnel through NAT, techniques like 6to4 may not work initiate a tunnel through Network Address Translation (NAT),
since they rely on public IPv4 address. In this case, unless the techniques like 6to4 may not work since they rely on public IPv4
existing GWRs support protocol-41-forwarding [Protocol 41], the end address. In this case, unless the existing GWRs support protocol-41-
user might have to use tunnels that can operate through NATs (such as forwarding [Protocol41], the end user might have to use tunnels that
Teredo [RFC4380]). Most GWRs support protocol-41-forwarding which can operate through NATs (such as Teredo [RFC4380]). Most GWRs
means that hosts can initiate the tunnels in which case the GWR is support protocol-41-forwarding, which means that hosts can initiate
not affected by the IPv6 service. the tunnels - in which case the GWR is not affected by the IPv6
service.
The customer has the option to initiate the tunnel from the device The customer has the option to initiate the tunnel from the device
(GWR) that performs the NAT functionality, similar to the GWR (GWR) that performs the NAT functionality, similar to the GWR
scenario discussed in section 4.1. This will imply HW replacement or scenario discussed in Section 4.1. This will imply hardware
SW upgrade and a native IPv6 environment behind the GWR. replacement or software upgrade and a native IPv6 environment behind
the GWR.
It is also worth observing that initiating an IPv6 tunnel over IPv4 It is also worth observing that initiating an IPv6 tunnel over IPv4
through already established IPv4 IPsec sessions would provide a through already established IPv4 IPsec sessions would provide a
certain level of security to the IPv6 traffic. certain level of security to the IPv6 traffic.
4.3. Transition a Portion of the IPv4 Infrastructure 4.3. Transition a Portion of the IPv4 Infrastructure
Tunnels can be used to transport the IPv6 traffic across a defined Tunnels can be used to transport the IPv6 traffic across a defined
segment of the network. As an example, the customer might connect segment of the network. As an example, the customer might connect
natively to the Network Access Provider and a tunnel is used to 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 transit the traffic over IPv4 to the ISP. In this case, the tunnel
choice depends on its capabilities (for example, whether it supports choice depends on its capabilities (for example, whether or not it
multicast or not), routing protocols used (there are several types supports multicast), routing protocols used (there are several types
that can transport layer 2 messages such as GRE [RFC2784], L2TPv3 that can transport Layer 2 messages, such as GRE [RFC2784], L2TPv3
[RFC3931] or Pseudowire), manage-ability and scalability (dynamic [RFC3931], or pseudowire), manageability, and scalability (dynamic
versus static tunnels). versus static tunnels).
This scenario implies that the access portion of the network has been This scenario implies that the access portion of the network has been
upgraded to support dual stack so the savings provided by tunneling upgraded to support dual stack, so the savings provided by tunneling
in this scenario are very small compared with the previous two in this scenario are very small compared with the previous two
scenarios. Depending on the number of sites requiring the service scenarios. Depending on the number of sites requiring the service,
and considering the expenses required to manage the tunnels (some and considering the expenses required to manage the tunnels (some
tunnels are static while others are dynamic [Dynamic Tunnel]) in this tunnels are static while others are dynamic [Dynamic Tunnel]) in this
case, the SPs might find the native approach worth the additional case, the SPs might find the native approach worth the additional
investments. investments.
In all the scenarios listed above the tunnel selection process should In all the scenarios listed above, the tunnel selection process
consider the IPv6 multicast forwarding capabilities if such service should consider the IPv6 multicast forwarding capabilities if such
is planned. As an example, 6to4 tunnels do not support IPv6 service is planned. As an example, 6to4 tunnels do not support IPv6
multicast traffic. multicast traffic.
The operation, capabilities and deployment of various tunnel types The operation, capabilities, and deployment of various tunnel types
has been discussed extensively in the documents referenced earlier as have been discussed extensively in the documents referenced earlier
well as in [RFC4213], [RFC3904]. Details of a tunnel based as well as in [RFC4213] and [RFC3904]. Details of a tunnel-based
deployment are offered in the next section of this document which deployment are offered in the next section of this document, which
discusses the case of Cable Access where the current DOCSIS 2.0 [RF discusses the case of Cable Access, where the current Data Over Cable
Interface] and prior specifications do not provide support for native Service Interface Specification (DOCSIS 2.0) [RF-Interface] and prior
IPv6 access. Although sections 6, 7, 8 and 9 focus on a native IPv6 specifications do not provide support for native IPv6 access.
deployments over DSL, FTTH, Wireless and PLC/BPL because this Although Sections 6, 7, 8, and 9 focus on a native IPv6 deployments
approach is fully supported today, tunnel based solutions are also over DSL, Fiber to the Home (FTTH), wireless, and PLC/BPL and because
possible in these cases based on the guidelines of this section and this approach is fully supported today, tunnel-based solutions are
some of the recommendations provided in section 5. also possible in these cases based on the guidelines of this section
and some of the recommendations provided in Section 5.
5. Broadband Cable Networks 5. Broadband Cable Networks
This section describes the infrastructure that exists today in cable This section describes the infrastructure that exists today in cable
networks providing BB services to the home. It also describes IPv6 networks providing BB services to the home. It also describes IPv6
deployment options in these cable networks. deployment options in these cable networks.
DOCSIS standardizes and documents the operation of data over Cable DOCSIS standardizes and documents the operation of data over cable
Networks. DOCSIS 2.0 and prior specifications have limitations that networks. DOCSIS 2.0 and prior specifications have limitations that
do not allow for a smooth implementation of native IPv6 transport. do not allow for a smooth implementation of native IPv6 transport.
Some of these limitations are discussed in this section. For this Some of these limitations are discussed in this section. For this
reason, the IPv6 deployment scenarios discussed in this section for reason, the IPv6 deployment scenarios discussed in this section for
the existing Cable Networks are tunnel based. The tunneling examples the existing cable networks are tunnel based. The tunneling examples
presented here could also be applied to the other BB technologies presented here could also be applied to the other BB technologies
described in sections 6, 7, 8, and 9. described in Sections 6, 7, 8, and 9.
5.1. Broadband Cable Network Elements 5.1. Broadband Cable Network Elements
Broadband cable networks are capable of transporting IP traffic to/ Broadband cable networks are capable of transporting IP traffic to/
from users to provide high speed Internet access and VOIP services. from users to provide high speed Internet access and Voice over IP
The mechanism of transporting IP traffic over cable networks is (VoIP) services. The mechanism for transporting IP traffic over
outlined in the DOCSIS specification [RF Interface]. cable networks is outlined in the DOCSIS specification
[RF-Interface].
Here are some of the key elements of a Cable network: Here are some of the key elements of a cable network:
Cable (HFC) Plant: Hybrid Fiber Coaxial plant, used as the underlying Cable (HFC) Plant: Hybrid Fiber Coaxial plant, used as the underlying
transport transport
CMTS: Cable Modem Termination System (can be a Layer 2 bridging or CMTS: Cable Modem Termination System (can be a Layer 2 bridging or
Layer 3 routing CMTS) Layer 3 routing CMTS)
GWR: Residential Gateway Router (provides Layer 3 services to hosts) GWR: Residential Gateway Router (provides Layer 3 services to hosts)
Host: PC, notebook etc. which is connected to the CM or GWR
Host: PC, notebook, etc., which is connected to the CM or GWR
CM: Cable Modem CM: Cable Modem
ER: Edge Router ER: Edge Router
MSO: Multiple Service Operator MSO: Multiple Service Operator
Data Over Cable Service Interface Specification (DOCSIS): The Data Over Cable Service Interface Specification (DOCSIS): Standards
standards defining how data should be carried over cable networks. defining how data should be carried over cable networks
Figure 5.1 illustrates the key elements of a Cable Network Figure 5.1 illustrates the key elements of a Cable Network.
|--- ACCESS ---||------ HFC ------||----- Aggregation / Core -----| |--- ACCESS ---||------ HFC ------||----- Aggregation / Core -----|
+-----+ +------+ +-----+ +------+
|Host |--| GWR | |Host |--| GWR |
+-----+ +--+---+ +-----+ +--+---+
| _ _ _ _ _ _ | _ _ _ _ _ _
+------+ | | +------+ | |
| CM |---| | | CM |---| |
+------+ | | +------+ | |
| HFC | +------+ +--------+ | HFC | +------+ +--------+
| | | | | Edge | | | | | | Edge |
+-----+ +------+ | Network |---| CMTS |---| |=>ISP +-----+ +------+ | Network |---| CMTS |---| |=>ISP
|Host |--| CM |---| | | | | Router | Network |Host |--| CM |---| | | | | Router | Network
+-----+ +--+---+ | | +------+ +--------+ +-----+ +--+---+ | | +------+ +--------+
|_ _ _ _ _ _| |_ _ _ _ _ _|
+------+ | +------+ |
+-----+ | GWR/ | | +-----+ | GWR/ | |
|Host |--| CM |---------+ |Host |--| CM |---------+
+-----+ | | +-----+ | |
+------+ Figure 5.1 +------+
Figure 5.1
5.2. Deploying IPv6 in Cable Networks 5.2. Deploying IPv6 in Cable Networks
One of the motivators for an MSO to deploy IPv6 over its Cable 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 network is to ease management burdens. IPv6 can be enabled on the
CM, CMTS and ER for management purposes. Currently portions of the CM, CMTS, and ER for management purposes. Currently portions of the
cable infrastructure use IPv4 address space [RFC1918]; however, there cable infrastructure use IPv4 address space [RFC1918]; however, there
are a finite number of those. Thus, IPv6 could have utility in the is a finite number of those. Thus, IPv6 could have utility in the
cable space implemented on the management plane initially and later cable space implemented on the management plane initially and focused
on focused on the data plane for end user services. For more details on the data plane for end-user services later. For more details on
on using IPv6 for management in Cable Networks please refer to using IPv6 for management in cable networks, please refer to Section
section 5.6.1. 5.6.1.
There are two different deployment modes in current cable networks: a There are two different deployment modes in current cable networks: a
bridged CMTS environment and a routed CMTS environment. IPv6 can be bridged CMTS environment and a routed CMTS environment. IPv6 can be
deployed in both of these environments. deployed in both of these environments.
1. Bridged CMTS Network 1. Bridged CMTS Network
In this scenario, both the CM and CMTS bridge all data traffic. In this scenario, both the CM and CMTS bridge all data traffic.
Traffic to/from host devices is forwarded through the cable network 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 to the ER. The ER then routes traffic through the ISP network to the
skipping to change at page 11, line 27 skipping to change at page 11, line 30
2. Routed CMTS Network 2. Routed CMTS Network
In a routed network, the CMTS forwards IP traffic to/from hosts based In a routed network, the CMTS forwards IP traffic to/from hosts based
on Layer 3 information using the IP source/destination address. The on Layer 3 information using the IP source/destination address. The
CM acts as a Layer 2 bridge for forwarding data traffic and supports CM acts as a Layer 2 bridge for forwarding data traffic and supports
some Layer 3 functionality for management purposes. some Layer 3 functionality for management purposes.
Some of the factors that hinder deployment of native IPv6 in current Some of the factors that hinder deployment of native IPv6 in current
routed and bridged cable networks include: routed and bridged cable networks include:
A. Changes need to be made to the DOCSIS specification [RF Interface] A. Changes need to be made to the DOCSIS specification
to include support for IPv6 on the CM and CMTS. This is imperative [RF-Interface] to include support for IPv6 on the CM and CMTS.
for deploying native IPv6 over cable networks. This is imperative for deploying native IPv6 over cable networks.
B. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. In B. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. In
IPv4, these devices rely on IGMP join messages to track membership of IPv4, these devices rely on Internet Group Multicast Protocol
hosts that are part of a particular IP Multicast group. In order to (IGMP) join messages to track membership of hosts that are part
support ND, a multicast based process, the CM and CMTS will need to of a particular IP multicast group. In order to support ND, a
support IGMPv3/MLDv2 or v1 snooping. multicast-based process, the CM and CMTS will need to support
IGMPv3/Multicast Listener Discovery Version 2 (MLDv2) or v1
snooping.
C. Classification of IPv6 traffic in the upstream and downstream C. Classification of IPv6 traffic in the upstream and downstream
direction. The CM and CMTS will need to support classification of direction. The CM and CMTS will need to support classification
IPv6 packets in order to give them the appropriate priority and QoS. of IPv6 packets in order to give them the appropriate priority
Service providers that wish to deploy QoS mechanisms also have to and QoS. Service providers that wish to deploy QoS mechanisms
support classification of IPv6 traffic. also have to support classification of IPv6 traffic.
Due to the above mentioned limitations in deployed cable networks, at Due to the above mentioned limitations in deployed cable networks, at
the time of writing this document the only option available for cable the time of writing this document, the only option available for
operators is to use tunneling techniques in order to transport IPv6 cable operators is to use tunneling techniques in order to transport
traffic over their current IPv4 infrastructure. The following IPv6 traffic over their current IPv4 infrastructure. The following
sections will cover tunneling and native IPv6 deployment scenarios in sections will cover tunneling and native IPv6 deployment scenarios in
more detail. more detail.
5.2.1. Deploying IPv6 in a Bridged CMTS Network 5.2.1. Deploying IPv6 in a Bridged CMTS Network
In IPv4 the CM and CMTS act as Layer 2 bridges and forward all data 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 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 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. next hop for all hosts and forward data traffic to/from the ER.
When deploying IPv6 in this environment, the CM and CMTS will When deploying IPv6 in this environment, the CM and CMTS will
continue to act as bridging devices in order to keep the transition continue to act as bridging devices in order to keep the transition
smooth and reduce operational complexity. The CM and CMTS will need smooth and reduce operational complexity. The CM and CMTS will need
to bridge IPv6 unicast and multicast packets to/from the ER and the 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 hosts. If there is a GWR connected to the CM, it will need to
forward IPv6 unicast and multicast traffic to/from the ER. forward IPv6 unicast and multicast traffic to/from the ER.
IPv6 can be deployed in a bridged CMTS network either natively or via IPv6 can be deployed in a bridged CMTS network either natively or via
tunneling. This section discusses the native deployment model. The tunneling. This section discusses the native deployment model. The
tunneling model is similar to ones described in sections 5.2.2.1 and tunneling model is similar to ones described in Sections 5.2.2.1 and
5.2.2.2. 5.2.2.2.
Figure 5.2.1 illustrate the IPv6 deployment scenario Figure 5.2.1 illustrates the IPv6 deployment scenario.
+-----+ +-----+ +-----+ +-----+
|Host |--| GWR | |Host |--| GWR |
+-----+ +--+--+ +-----+ +--+--+
| _ _ _ _ _ _ | _ _ _ _ _ _
| +------+ | | | +------+ | |
+--| CM |---| | +--| CM |---| |
+------+ | | +------+ | |
| HFC | +------+ +--------+ | HFC | +------+ +--------+
| | | | | Edge | | | | | | Edge |
skipping to change at page 12, line 42 skipping to change at page 13, line 7
|Host |--| CM |---| | | | | Router |Network |Host |--| CM |---| | | | | Router |Network
+-----+ +------+ | | +------+ +--------+ +-----+ +------+ | | +------+ +--------+
|_ _ _ _ _ _| |_ _ _ _ _ _|
|-------------||---------------------------------||---------------| |-------------||---------------------------------||---------------|
L3 Routed L2 Bridged L3 Routed L3 Routed L2 Bridged L3 Routed
Figure 5.2.1 Figure 5.2.1
5.2.1.1. IPv6 Related Infrastructure Changes 5.2.1.1. IPv6 Related Infrastructure Changes
In this scenario the CM and the CMTS bridge all data traffic so they 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 will need to support bridging of native IPv6 unicast and multicast
traffic. The following devices have to be upgraded to dual stack: traffic. The following devices have to be upgraded to dual stack:
Host, GWR and ER. Host, GWR, and ER.
5.2.1.2. Addressing 5.2.1.2. Addressing
The proposed architecture for IPv6 deployment includes two components The proposed architecture for IPv6 deployment includes two components
that must be provisioned: the CM and the host. Additionally if there 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. is a GWR connected to the CM, it will also need to be provisioned.
The host or the GWR use the ER as their Layer 3 next hop. The host or the GWR use the ER as their Layer 3 next hop.
5.2.1.2.1. IP Addressing for CM 5.2.1.2.1. IP Addressing for CM
The CM will be provisioned in the same way as in currently deployed The CM will be provisioned in the same way as in currently deployed
cable networks, using an IPv4 address on the cable interface cable networks, using an IPv4 address on the cable interface
connected to the MSO network for management functions. During the connected to the MSO network for management functions. During the
initialization phase, it will obtain its IPv4 address using DHCPv4, initialization phase, it will obtain its IPv4 address using Dynamic
and download a DOCSIS configuration file identified by the DHCPv4 Host Configuration Protocol (DHCPv4), and download a DOCSIS
server. configuration file identified by the DHCPv4 server.
5.2.1.2.2. IP Addressing for Hosts 5.2.1.2.2. IP Addressing for Hosts
If there is no GWR connected to the CM, the host behind the CM will 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. get a /64 prefix via stateless auto-configuration or DHCPv6.
If using stateless auto-configuration, the host listens for routing If using stateless auto-configuration, the host listens for routing
advertisements (RA) from the ER. The RAs contain the /64 prefix advertisements (RAs) from the ER. The RAs contain the /64 prefix
assigned to the segment. Upon receipt of an RA, the host constructs 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 its IPv6 address by combining the prefix in the RA (/64) and a unique
identifier (e.g. its modified EUI-64 format interface ID). identifier (e.g., its modified EUI-64 (64-bit Extended Unique
Identifier) format interface ID).
If DHCPv6 is used to obtain an IPv6 address, it will work in much the 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 same way as DHCPv4 works today. The DHCPv6 messages exchanged
between the host and the DHCPv6 server are bridged by the CM and the between the host and the DHCPv6 server are bridged by the CM and the
CMTS. CMTS.
5.2.1.2.3. IP Addressing for GWR 5.2.1.2.3. IP Addressing for GWR
The GWR can use stateless auto-configuration (RA) to obtain an The GWR can use stateless auto-configuration (RA) to obtain an
address for its upstream interface, the link between itself and the address for its upstream interface, the link between itself and the
ER. This step is followed by a request via DHCP-PD (Prefix ER. This step is followed by a request via DHCP-PD (Prefix
Delegation) for a prefix shorter than /64, typically /48 [RFC3177], Delegation) for a prefix shorter than /64, typically /48 [RFC3177],
which in turn is divided into /64s and assigned to its downstream which in turn is divided into /64s and assigned to its downstream
interfaces connecting to the hosts. interfaces connecting to the hosts.
5.2.1.3. Data Forwarding 5.2.1.3. Data Forwarding
The CM and CMTS must be able to bridge native IPv6 unicast and The CM and CMTS must be able to bridge native IPv6 unicast and
multicast traffic. The CMTS must provide IP connectivity between multicast traffic. The CMTS must provide IP connectivity between
hosts attached to CMs and must do so in a way that meets the hosts attached to CMs, and must do so in a way that meets the
expectation of Ethernet attached customer equipment. In order to do expectation of Ethernet-attached customer equipment. In order to do
that, the CM and CMTS must forward Neighbor Discovery (ND) packets that, the CM and CMTS must forward Neighbor Discovery (ND) packets
between ER and the hosts attached to the CM. between ER and the hosts attached to the CM.
Communication between hosts behind different CMs is always forwarded Communication between hosts behind different CMs is always forwarded
through the CMTS. IPv6 communication between the different sites through the CMTS. IPv6 communication between the different sites
relies on multicast IPv6 ND [RFC2461] frames being forwarded relies on multicast IPv6 ND [RFC2461] frames being forwarded
correctly by the CM and the CMTS. correctly by the CM and the CMTS.
In order to support IPv6 multicast applications across DOCSIS cable In order to support IPv6 multicast applications across DOCSIS cable
networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 or v1 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 snooping. MLD is almost identical to IGMP in IPv4, only the name and
numbers are changed. MLDv2 is identical to IGMPv3 and also supports numbers are changed. MLDv2 is identical to IGMPv3 and also supports
ASM (Any Source Multicast) and SSM (Single Source Multicast) service ASM (Any-Source Multicast) and SSM (Source-Specific Multicast)
models. Implementation work on CM/CMTS should be minimal because the service models. Implementation work on CM/CMTS should be minimal
only significant difference between IPv4 IGMPv3 and IPv6 MLDv2 is the because the only significant difference between IPv4 IGMPv3 and IPv6
longer addresses in the protocol. MLDv2 is the longer addresses in the protocol.
5.2.1.4. Routing 5.2.1.4. Routing
The hosts install a default route that points to the ER or the GWR. 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 No routing protocols are needed on these devices, which generally
limited resources. If there is a GWR present it will also use static have limited resources. If there is a GWR present, it will also use
default route to the ER. static default route to the ER.
The ER runs an IGP such as OSPFv3 or IS-IS. The connected prefixes 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 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 prefix a static route is installed by the ER. For this reason, the
static routes must also be redistributed. Prefix summarization static routes must also be redistributed. Prefix summarization
should be done at the ER. should be done at the ER.
5.2.2. Deploying IPv6 in a Routed CMTS Network 5.2.2. Deploying IPv6 in a Routed CMTS Network
In an IPv4/IPv6 routed CMTS network the CM still acts as a Layer 2 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 device and bridges all data traffic between its Ethernet interface
and cable interface connected to the cable operator network. The and cable interface connected to the cable operator network. The
CMTS acts as a Layer 3 router and may also include the ER 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 functionality. The hosts and the GWR use the CMTS as their Layer 3
next hop. next hop.
When deploying IPv6, the CMTS/ER will need to either tunnel IPv6 When deploying IPv6, the CMTS/ER will need to either tunnel IPv6
traffic or natively support IPv6. traffic or natively support IPv6.
There are five possible deployment scenarios for IPv6 in a routed There are five possible deployment scenarios for IPv6 in a routed
CMTS network: CMTS network:
1. IPv4 Cable (HFC) Network 1. IPv4 Cable (HFC) Network
In this scenario the cable network, including the CM and CMTS remain In this scenario, the cable network, including the CM and CMTS,
IPv4 devices. The host and ER are upgraded to dual-stack. This is remain IPv4 devices. The host and ER are upgraded to dual stack.
the easiest way for a Cable Operator to provide IPv6 service as no This is the easiest way for a cable operator to provide IPv6 service,
changes are made to the cable network. as no changes are made to the cable network.
2. IPv4 Cable (HFC) Network, GWR at Customer Site 2. IPv4 Cable (HFC) Network, GWR at Customer Site
In this case the cable network, including the CM and CMTS remain IPv4 In this case, the cable network, including the CM and CMTS, remain
devices. The host, GWR and ER are upgraded to dual-stack. This IPv4 devices. The host, GWR, and ER are upgraded to dual stack.
scenario is also easy to deploy since the cable operator just needs This scenario is also easy to deploy since the cable operator just
to add GWR at the customer site. needs to add GWR at the customer site.
3. Dual-stacked Cable (HFC) Network, CM and CMTS Support IPv6 3. Dual-stacked Cable (HFC) Network, CM, and CMTS Support IPv6
In this scenario the CMTS is upgraded to dual-stack to support IPv4 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. 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 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 unicast and multicast traffic. This scenario is not easy to deploy
since it requires changes to the DOCSIS specification. The CM and since it requires changes to the DOCSIS specification. The CM and
CMTS may require HW and SW upgrades to support IPv6. CMTS may require hardware and software upgrades to support IPv6.
4. Dual-stacked Cable (HFC) Network, Standalone GWR and CMTS Support 4. Dual-stacked Cable (HFC) Network, Standalone GWR, and CMTS
IPv6 Support IPv6
In this scenario there is a standalone GWR connected to the CM. 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 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 to be dual stack. The CMTS is upgraded to dual stack and it can
incorporate the ER functionality. This scenario may also require HW incorporate the ER functionality. This scenario may also require
and SW changes on the GWR and CMTS. hardware and software changes on the GWR and CMTS.
5. Dual-stacked Cable (HFC) Network, Embedded GWR/CM and CMTS 5. Dual-stacked Cable (HFC) Network, Embedded GWR/CM, and CMTS
Support IPv6 Support IPv6
In this scenario the CM and GWR functionality exists on a single 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 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 need to be upgraded to a dual-stack device. This scenario is also
difficult to deploy in existing cable network since it requires difficult to deploy in existing cable network since it requires
changes on the Embedded GWR/CM and the CMTS. changes on the Embedded GWR/CM and the CMTS.
The DOCSIS specification will also need to be modified to allow The DOCSIS specification will also need to be modified to allow
native IPv6 support on the Embedded GWR/CM. native IPv6 support on the Embedded GWR/CM.
5.2.2.1. IPv4 Cable Network, Host and ER Upgraded to Dual-Stack 5.2.2.1. IPv4 Cable Network, Host, and ER Upgraded to Dual Stack
This is one of the most cost effective ways for a Cable Operator to This is one of the most cost-effective ways for a cable operator to
offer IPv6 services to its customers. Since the cable network offer IPv6 services to its customers. Since the cable network
remains IPv4 there is relatively minimal cost involved in turning up remains IPv4, there is relatively minimal cost involved in turning up
IPv6 service. All IPv6 traffic is exchanged between the hosts and IPv6 service. All IPv6 traffic is exchanged between the hosts and
the ER. the ER.
Figure 5.2.2.1 illustrates this deployment scenario Figure 5.2.2.1 illustrates this deployment scenario.
+-----------+ +------+ +--------+ +-----------+ +------+ +--------+
+-----+ +-------+ | Cable | | | | Edge | +-----+ +-------+ | Cable | | | | Edge |
|Host |--| CM |----| (HFC) |---| CMTS |---| |=>ISP |Host |--| CM |----| (HFC) |---| CMTS |---| |=>ISP
+-----+ +-------+ | Network | | | | Router |Network +-----+ +-------+ | Network | | | | Router |Network
+-----------+ +------+ +--------+ +-----------+ +------+ +--------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel IPv6-in-IPv4 tunnel
|---------||---------------------------------------||------------| |---------||---------------------------------------||------------|
IPv4/v6 IPv4 only IPv4/v6 IPv4/v6 IPv4 only IPv4/v6
Figure 5.2.2.1 Figure 5.2.2.1
5.2.2.1.1. IPv6 Related Infrastructure Changes 5.2.2.1.1. IPv6 Related Infrastructure Changes
In this scenario the CM and the CMTS will only need to support IPv4 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 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. following devices have to be upgraded to dual stack: Host and ER.
5.2.2.1.2. Addressing 5.2.2.1.2. Addressing
The only device that needs to be assigned an IPv6 address at customer The only device that needs to be assigned an IPv6 address at the
site is the host. Host address assignment can be done in multiple customer site is the host. Host address assignment can be done in
ways. Depending on the tunneling mechanism used it could be multiple ways. Depending on the tunneling mechanism used, it could
automatic or might require manual configuration. be automatic or might require manual configuration.
The host still receives an IPv4 address using DHCPv4, which works the The host still receives an IPv4 address using DHCPv4, which works the
same way in currently deployed cable networks. In order to get IPv6 same way in currently deployed cable networks. In order to get IPv6
connectivity, host devices will also need an IPv6 address and a means connectivity, host devices will also need an IPv6 address and a means
to communicate with the ER. to communicate with the ER.
5.2.2.1.3. Data Forwarding 5.2.2.1.3. Data Forwarding
All IPv6 traffic will be sent to/from the ER and the host device. In 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, order to transport IPv6 packets over the cable operator IPv4 network,
skipping to change at page 17, line 8 skipping to change at page 17, line 21
The host will use its IPv4 address to source the tunnel to the ER. 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 All IPv6 traffic will be forwarded to the ER, encapsulated in IPv4
packets. The intermediate IPv4 nodes will forward this traffic as packets. The intermediate IPv4 nodes will forward this traffic as
regular IPv4 packets. The ER will need to terminate the tunnel regular IPv4 packets. The ER will need to terminate the tunnel
and/or provide other IPv6 services. and/or provide other IPv6 services.
5.2.2.1.4. Routing 5.2.2.1.4. Routing
Routing configuration on the host will vary depending on the Routing configuration on the host will vary depending on the
tunneling technique used, in some cases a default or static route tunneling technique used. In some cases, a default or static route
might be needed to forward traffic to the next hop. might be needed to forward traffic to the next hop.
The ER runs an IGP such as OSPFv3 or ISIS. The ER runs an IGP such as OSPFv3 or ISIS.
5.2.2.2. IPv4 Cable Network, Host, GWR and ER Upgraded to Dual-Stack 5.2.2.2. IPv4 Cable Network, Host, GWR and ER Upgraded to Dual Stack
The cable operator can provide IPv6 services to its customers, in The cable operator can provide IPv6 services to its customers, in
this scenario, by adding a GWR behind the CM. Since the GWR will 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 facilitate all IPv6 traffic between the host and the ER, the cable
network including the CM and CMTS do not need to support IPv6 and can network, including the CM and CMTS, does not need to support IPv6,
remain as IPv4 devices. and can remain as IPv4 devices.
Figure 5.2.2.2 illustrates this deployment scenario Figure 5.2.2.2 illustrates this deployment scenario.
+-----+ +-----+
|Host | |Host |
+--+--+ +--+--+
| +-----------+ +------+ +--------+ | +-----------+ +------+ +--------+
+---+---+ +-------+ | Cable | | | | Edge | +---+---+ +-------+ | Cable | | | | Edge |
| GWR |--| CM |----| (HFC) |---| CMTS |---| |=>ISP | GWR |--| CM |----| (HFC) |---| CMTS |---| |=>ISP
+-------+ +-------+ | Network | | | | Router |Network +-------+ +-------+ | Network | | | | Router |Network
+-----------+ +------+ +--------+ +-----------+ +------+ +--------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel IPv6-in-IPv4 tunnel
|---------||--------------------------------------||-------------| |---------||--------------------------------------||-------------|
IPv4/v6 IPv4 only IPv4/v6 IPv4/v6 IPv4 only IPv4/v6
Figure 5.2.2.2 Figure 5.2.2.2
5.2.2.2.1. IPv6 Related Infrastructure Changes 5.2.2.2.1. IPv6 Related Infrastructure Changes
In this scenario the CM and the CMTS will only need to support IPv4 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 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 following devices have to be upgraded to dual stack: Host, GWR, and
ER. ER.
5.2.2.2.2. Addressing 5.2.2.2.2. Addressing
The only devices that need to be assigned an IPv6 address at customer 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 site are the host and GWR. IPv6 address assignment can be done
statically at the GWR downstream interface. The GWR will send out RA statically at the GWR downstream interface. The GWR will send out RA
messages on its downstream interface which will be used by the hosts messages on its downstream interface, which will be used by the hosts
to auto-configure themselves with an IPv6 address. The GWR can also to auto-configure themselves with an IPv6 address. The GWR can also
configure its upstream interface using RA messages from the ER and configure its upstream interface using RA messages from the ER and
use DHCP-PD for requesting a /48 [RFC3177] prefix from the ER. This 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 /48 prefix will be used to configure /64s on hosts connected to the
GWR downstream interfaces. The uplink to the ISP network is GWR downstream interfaces. The uplink to the ISP network is
configured with a /64 prefix as well. configured with a /64 prefix as well.
The GWR still receives a global IPv4 address on its upstream The GWR still receives a global IPv4 address on its upstream
interface using DHCPv4, which works the same way in currently interface using DHCPv4, which works the same way in currently
deployed cable networks. In order to get IPv6 connectivity to the deployed cable networks. In order to get IPv6 connectivity to the
Internet the GWR will need to communicate with the ER. Internet, the GWR will need to communicate with the ER.
5.2.2.2.3. Data Forwarding 5.2.2.2.3. Data Forwarding
All IPv6 traffic will be sent to/from the ER and the GWR, which will 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 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 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. 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 All IPv6 traffic will need to go through the tunnel, once it comes
up. up.
The GWR will use its IPv4 address to source the tunnel to the ER. 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 The tunnel endpoint will be the IPv4 address of the ER. All IPv6
traffic will be forwarded to the ER, encapsulated in IPv4 packets. traffic will be forwarded to the ER, encapsulated in IPv4 packets.
The intermediate IPv4 nodes will forward this traffic as regular IPv4 The intermediate IPv4 nodes will forward this traffic as regular IPv4
packets. In case of 6to4 tunneling, the ER will need to support 6to4 packets. In case of 6to4 tunneling, the ER will need to support 6to4
relay functionality in order to provide IPv6 Internet connectivity to relay functionality in order to provide IPv6 Internet connectivity to
the GWR and hence the hosts connected to the GWR. the GWR, and hence, the hosts connected to the GWR.
5.2.2.2.4. Routing 5.2.2.2.4. Routing
Depending on the tunneling technique used, additional configuration Depending on the tunneling technique used, additional configuration
might be needed on the GWR and the ER. If the ER is also providing a 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 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 pointing to the ER, for all non-6to4 traffic.
If using manual tunneling, the GWR and ER can use static routing or 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 an IGP such as RIPng [RFC2080]. The RIPng updates can be transported
over a manual tunnel, which does not work when using 6to4 tunneling over a manual tunnel, which does not work when using 6to4 tunneling
since it does not support multicast. since it does not support multicast.
Customer routes can be carried to the ER using RIPng updates. The ER Customer routes can be carried to the ER using RIPng updates. The ER
can advertise these routes in its IGP. Prefix summarization should can advertise these routes in its IGP. Prefix summarization should
be done at the ER. be done at the ER.
If DHCP-PD is used for address assignment a static route is If DHCP-PD is used for address assignment, a static route is
automatically installed on the ER for each delegated /48 prefix. The automatically installed on the ER for each delegated /48 prefix. The
static routes need to be redistributed into the IGP at the ER, so 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. there is no need for a routing protocol between the ER and the GWR.
The ER runs an IGP such as OSPFv3 or ISIS. The ER runs an IGP such as OSPFv3 or ISIS.
5.2.2.3. Dual-stacked Cable (HFC) Network, CM and CMTS Support IPv6 5.2.2.3. Dual-Stacked Cable (HFC) Network, CM, and CMTS Support IPv6
In this scenario the Cable Operator can offer native IPv6 services to In this scenario the cable operator can offer native IPv6 services to
its customers since the cable network including the CMTS supports its customers since the cable network, including the CMTS, supports
IPv6. The ER functionality can be included in the CMTS or it can IPv6. The ER functionality can be included in the CMTS or it can
exist on a separate router connected to the CMTS upstream interface. exist on a separate router connected to the CMTS upstream interface.
The CM will need to bridge IPv6 unicast and multicast traffic. The CM will need to bridge IPv6 unicast and multicast traffic.
Figure 5.2.2.3 illustrates this deployment scenario Figure 5.2.2.3 illustrates this deployment scenario.
+-----------+ +-------------+ +-----------+ +-------------+
+-----+ +-------+ | Cable | | CMTS / Edge | +-----+ +-------+ | Cable | | CMTS / Edge |
|Host |--| CM |----| (HFC) |---| |=>ISP |Host |--| CM |----| (HFC) |---| |=>ISP
+-----+ +-------+ | Network | | Router | Network +-----+ +-------+ | Network | | Router | Network
+-----------+ +-------------+ +-----------+ +-------------+
|-------||---------------------------||---------------| |-------||---------------------------||---------------|
IPv4/v6 IPv4/v6 IPv4/v6 IPv4/v6 IPv4/v6 IPv4/v6
Figure 5.2.2.3 Figure 5.2.2.3
5.2.2.3.1. IPv6 Related Infrastructure Changes 5.2.2.3.1. IPv6 Related Infrastructure Changes
Since the CM still acts as a Layer 2 bridge, it does not need to be 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 dual stack. The CM will need to support bridging of IPv6 unicast and
multicast traffic and IGMPv3/MLDv2 or v1 snooping which requires multicast traffic and IGMPv3/MLDv2 or v1 snooping, which requires
changes in the DOCSIS specification. In this scenario the following changes in the DOCSIS specification. In this scenario, the following
devices have to be upgraded to dual stack: Host and CMTS/ER. devices have to be upgraded to dual stack: Host and CMTS/ER.
5.2.2.3.2. Addressing 5.2.2.3.2. Addressing
In cable networks today the CM receives a private IPv4 address using In cable networks today, the CM receives a private IPv4 address using
DHCPv4 for management purposes. In an IPv6 environment, the CM will DHCPv4 for management purposes. In an IPv6 environment, the CM will
continue to use an IPv4 address for management purposes. The cable continue to use an IPv4 address for management purposes. The cable
operator can also choose to assign an IPv6 address to the CM for 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 management, but the CM will have to be upgraded to support this
functionality. functionality.
IPv6 address assignment for the CM and host can be done via DHCP or 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 stateless auto-configuration. If the CM uses an IPv4 address for
management, it will use DHCPv4 for its address assignment and the 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 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 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 as a DHCPv6 relay agent, or the CMTS can be statically configured
a /64 prefix and it can send out RA messages out the cable interface. with a /64 prefix and it can send out RA messages out the cable
The CMs connected to the cable interface can use the RA messages to interface. The CMs connected to the cable interface can use the RA
auto-configure themselves with an IPv6 address. All CMs connected to messages to auto-configure themselves with an IPv6 address. All CMs
the cable interface will be in the same subnet. connected to the cable interface will be in the same subnet.
The hosts can receive their IPv6 address via DHCPv6 or stateless The hosts can receive their IPv6 address via DHCPv6 or stateless
auto-configuration. With DHCPv6, the CMTS may need to act as a auto-configuration. With DHCPv6, the CMTS may need to act as a
DHCPv6 relay agent and forward DHCP messages between the hosts and DHCPv6 relay agent and forward DHCP messages between the hosts and
the DHCP server. With stateless auto-configuration, the CMTS will be the DHCP server. With stateless auto-configuration, the CMTS will be
configured with multiple /64 prefixes and send out RA messages to the 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 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 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 will need to forward the RA messages downstream or act as an ND
proxy. proxy.
skipping to change at page 20, line 36 skipping to change at page 20, line 50
based on the IP source/destination address. based on the IP source/destination address.
5.2.2.3.4. Routing 5.2.2.3.4. Routing
No routing protocols are needed between the CMTS and the host since No routing protocols are needed between the CMTS and the host since
the CM and host are directly connected to the CMTS cable interface. 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 Since the CMTS supports IPv6, hosts will use the CMTS as their Layer
3 next hop. 3 next hop.
If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or
ISIS. IS-IS.
5.2.2.4. Dual-Stacked Cable (HFC) Network, Standalone GWR and CMTS 5.2.2.4. Dual-Stacked Cable (HFC) Network, Stand-Alone GWR, and CMTS
Support IPv6 Support IPv6
In this case the cable operator can offer IPv6 services to its 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 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 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 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 ER as well. The CM will act as a bridge for forwarding data traffic
and does not need to support IPv6. and does not need to support IPv6.
This scenario is similar to the case described in section 5.2.2.2. This scenario is similar to the case described in Section 5.2.2.2.
The only difference in this case is the ER functionality exists on The only difference in this case is that the ER functionality exists
the CMTS instead of a separate router in the cable operator network. on the CMTS instead of on a separate router in the cable operator
network.
Figure 5.2.2.4 illustrates this deployment scenario Figure 5.2.2.4 illustrates this deployment scenario.
+-----------+ +-----------+ +-----------+ +-----------+
+------+ +-------+ +-------+ | Cable | |CMTS / Edge| +------+ +-------+ +-------+ | Cable | |CMTS / Edge|
| Host |--| GWR |--| CM |---| (HFC) |---| |=>ISP | Host |--| GWR |--| CM |---| (HFC) |---| |=>ISP
+------+ +-------+ +-------+ | Network | | Router |Network +------+ +-------+ +-------+ | Network | | Router |Network
+-----------+ +-----------+ +-----------+ +-----------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel IPv6-in-IPv4 tunnel
|-----------------||-----------------------------||--------------| |-----------------||-----------------------------||--------------|
IPv4/v6 IPv4 IPv4/v6 IPv4/v6 IPv4 IPv4/v6
Figure 5.2.2.4 Figure 5.2.2.4
5.2.2.4.1. IPv6 Related Infrastructure Changes 5.2.2.4.1. IPv6 Related Infrastructure Changes
Since the CM still acts as a Layer 2 bridge, it does not need to be 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 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 following devices have to be upgraded to dual stack: Host, GWR, and
CMTS/ER. CMTS/ER.
5.2.2.4.2. Addressing 5.2.2.4.2. Addressing
The CM will still receive a private IPv4 address using DHCPv4 which 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 works the same way in existing cable networks. The CMTS will act as
DHCPv4 relay agent. a DHCPv4 relay agent.
The address assignment for the host and GWR happens in a similar The address assignment for the host and GWR happens in a similar
manner as described in section 5.2.2.2.2. manner as described in Section 5.2.2.2.2.
5.2.2.4.3. Data Forwarding 5.2.2.4.3. Data Forwarding
Data forwarding between the host and CMTS/ER is facilitated by the Data forwarding between the host and CMTS/ER is facilitated by the
GWR and happens in a similar manner as described in section GWR and happens in a similar manner as described in Section
5.2.2.2.3. 5.2.2.2.3.
5.2.2.4.4. Routing 5.2.2.4.4. Routing
In this case routing is very similar to the case described in section In this case, routing is very similar to the case described in
5.2.2.2.4. Since the CMTS now incorporates the ER functionality, it Section 5.2.2.2.4. Since the CMTS now incorporates the ER
will need to run an IGP such as OSPFv3 or ISIS. functionality, it will need to run an IGP such as OSPFv3 or IS-IS.
5.2.2.5. Dual-Stacked Cable (HFC) Network, Embedded GWR/CM and CMTS 5.2.2.5. Dual-Stacked Cable (HFC) Network, Embedded GWR/CM, and CMTS
Support IPv6 Support IPv6
In this scenario the Cable Operator can offer native IPv6 services to In this scenario, the cable operator can offer native IPv6 services
its customers since the cable network including the CM/Embedded GWR to its customers since the cable network, including the CM/Embedded
and CMTS support IPv6. The ER functionality can be included in the GWR and CMTS, supports IPv6. The ER functionality can be included in
CMTS or it can exist on a separate router connected to the CMTS 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. upstream interface. The CM/Embedded GWR acts as a Layer 3 device.
Figure 5.2.2.5 illustrates this deployment scenario Figure 5.2.2.5 illustrates this deployment scenario.
+-----------+ +-------------+ +-----------+ +-------------+
+-----+ +-----------+ | Cable | | CMTS / Edge | +-----+ +-----------+ | Cable | | CMTS / Edge |
|Host |---| CM / GWR |---| (HFC) |---| |=>ISP |Host |---| CM / GWR |---| (HFC) |---| |=>ISP
+-----+ +-----------+ | Network | | Router |Network +-----+ +-----------+ | Network | | Router |Network
+-----------+ +-------------+ +-----------+ +-------------+
|---------------------------------------------------------| |---------------------------------------------------------|
IPv4/v6 IPv4/v6
Figure 5.2.2.5 Figure 5.2.2.5
5.2.2.5.1. IPv6 Related Infrastructure Changes 5.2.2.5.1. IPv6 Related Infrastructure Changes
Since the CM/GWR acts as a Layer 3 device, IPv6 can be deployed end- 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-end. In this scenario, the following devices have to be upgraded
to dual-stack: Host, CM/GWR and CMTS/ER. to dual stack: Host, CM/GWR, and CMTS/ER.
5.2.2.5.2. Addressing 5.2.2.5.2. Addressing
Since the CM/GWR is dual-stack, it can receive an IPv4 or IPv6 Since the CM/GWR is dual stack, it can receive an IPv4 or IPv6
address using DHCP for management purposes. As the GWR functionality address using DHCP for management purposes. As the GWR functionality
is Embedded in the CM, it will need an IPv6 address for forwarding 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 data traffic. IPv6 address assignment for the CM/GWR and host can be
done via DHCPv6 or DHCP-PD. done via DHCPv6 or DHCP-PD.
If using DHCPv6 the CMTS will need to act as DHCPv6 relay agent. The If using DHCPv6, the CMTS will need to act as a DHCPv6 relay agent.
host and CM/GWR will receive IPv6 addresses from pools of /64 The host and CM/GWR will receive IPv6 addresses from pools of /64
prefixes configured on the DHCPv6 server. The CMTS will need to prefixes configured on the DHCPv6 server. The CMTS will need to
glean pertinent information from the DHCP Offer messages, sent from glean pertinent information from the DHCP Offer messages, sent from
the DHCP server to the DHCP clients (host and CM/GWR), much like it 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 does today in DHCPv4. All CM/GWR connected to the same cable
interface on the CMTS belong to same management /64 prefix. The 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 hosts connected to the same cable interface on the CMTS may belong to
different /64 customer prefixes as the CMTS may have multiple /64 different /64 customer prefixes, as the CMTS may have multiple /64
prefixes configured under its cable interfaces. prefixes configured under its cable interfaces.
It is also possible to use DHCP-PD for IPv6 address assignment. In It is also possible to use DHCP-PD for an IPv6 address assignment.
this case the CM/GWR will use stateless auto-configuration to assign In this case, the CM/GWR will use stateless auto-configuration to
an IPv6 address to its upstream interface using the /64 prefix sent assign an IPv6 address to its upstream interface using the /64 prefix
by the CMTS/ER in RA message. Once the CM/GWR assigns an IPv6 sent by the CMTS/ER in an RA message. Once the CM/GWR assigns an
address to its upstream interface it will request a /48 [RFC3177] IPv6 address to its upstream interface, it will request a /48
prefix from the CMTS/ER and chop this /48 prefix into /64s for [RFC3177] prefix from the CMTS/ER and chop this /48 prefix into /64s
assigning IPv6 addresses to hosts. The uplink to the ISP network is for assigning IPv6 addresses to hosts. The uplink to the ISP network
configured with a /64 prefix as well. is configured with a /64 prefix as well.
5.2.2.5.3. Data Forwarding 5.2.2.5.3. Data Forwarding
The host will use the CM/GWR as the Layer 3 next hop. The CM/GWR 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 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 CMTS/ER will forward IPv6 traffic to/from hosts based on the IP
source/destination address. source/destination address.
5.2.2.5.4. Routing 5.2.2.5.4. Routing
The CM/GWR can use a static default route pointing to the CMTS/ER or 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 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 and the CMTS. Customer routes from behind the CM/GWR can be carried
to the CMTS using routing updates. to the CMTS using routing updates.
If DHCP-PD is used for address assignment a static route is If DHCP-PD is used for address assignment, a static route is
automatically installed on the CMTS/ER for each delegated /48 prefix. automatically installed on the CMTS/ER for each delegated /48 prefix.
The static routes need to be redistributed into the IGP at the 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 so there is no need for a routing protocol between the
CMTS/ER and the GWR. CMTS/ER and the GWR.
If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or
ISIS. IS-IS.
5.2.3. IPv6 Multicast 5.2.3. IPv6 Multicast
In order to support IPv6 multicast applications across DOCSIS cable In order to support IPv6 multicast applications across DOCSIS cable
networks, the CM and bridging CMTS will need to support IGMPv3/MLDv2 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 or v1 snooping. MLD is almost identical to IGMP in IPv4, only the
name and numbers are changed. MLDv2 is almost identical to IGMPv3 name and numbers are changed. MLDv2 is almost identical to IGMPv3
and also supports ASM (Any Source Multicast) and SSM (Single Source and also supports ASM (Any-Source Multicast) and SSM (Source-Specific
Multicast) service models. Multicast) service models.
SSM is more suited for deployments where the SP intends to provide SSM is more suited for deployments where the SP intends to provide
paid content to the users (Video or Audio). This type of services paid content to the users (video or audio). These types of services
are expected to be of primary interest. Moreover, the simplicity of are expected to be of primary interest. Moreover, the simplicity of
the SSM model often times override the scalability issues that would the SSM model often overrides the scalability issues that would be
be resolved in an ASM model. ASM is however an option that is 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 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 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 definition and support for IGMPv3/MLDv1 or v2 snooping, in order to
track join/leave messages from the hosts. Another option would be 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 for the Layer 3 CM or GWR to support MLD proxy routing. The Layer 3
next hop for the hosts needs to support MLD. next hop for the hosts needs to support MLD.
Refer to section 6.3 for more IPv6 multicast details. Refer to Section 6.3 for more IPv6 multicast details.
5.2.4. IPv6 QoS 5.2.4. IPv6 QoS
IPv6 will not change or add any queuing/scheduling functionality IPv6 will not change or add any queuing/scheduling functionality
already existing in DOCSIS specifications. But the QoS mechanisms on already existing in DOCSIS specifications. But the QoS mechanisms on
the CMTS and CM would need to be IPv6 capable. This includes support 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 for IPv6 classifiers, so that data traffic to/from host devices can
be classified appropriately into different service flows and be be classified appropriately into different service flows and be
assigned appropriate priority. Appropriate classification criteria assigned appropriate priority. Appropriate classification criteria
would need to be implemented for unicast and multicast traffic. would need to be implemented for unicast and multicast traffic.
Traffic classification and marking should be done at the CM for Traffic classification and marking should be done at the CM for
upstream traffic and the CMTS/ER for downstream traffic in order to upstream traffic and the CMTS/ER for downstream traffic, in order to
support the various types of services: data, voice and video. The support the various types of services: data, voice, and video. The
same IPv4 QoS concepts and methodologies should be applied for IPv6 same IPv4 QoS concepts and methodologies should be applied for IPv6
as well. as well.
It is important to note that when traffic is encrypted end-to-end, 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 the traversed network devices will not have access to many of the
packet fields used for classification purposes. In these cases packet fields used for classification purposes. In these cases,
routers will most likely place the packets in the default classes. routers will most likely place the packets in the default classes.
The QoS design should take into consideration this scenario and try The QoS design should take into consideration this scenario and try
to use mainly IP header fields for classification purposes. to use mainly IP header fields for classification purposes.
5.2.5. IPv6 Security Considerations 5.2.5. IPv6 Security Considerations
Security in a DOCSIS cable network is provided using Baseline Privacy Security in a DOCSIS cable network is provided using Baseline Privacy
Plus (BPI+). The only part that is dependent on IP addresses is Plus (BPI+). The only part that is dependent on IP addresses is
encrypted multicast. Semantically, multicast encryption would work encrypted multicast. Semantically, multicast encryption would work
the same way in an IPv6 environment as in the IPv4 network. However, the same way in an IPv6 environment as in the IPv4 network. However,
appropriate enhancements will be needed in the DOCSIS specification appropriate enhancements will be needed in the DOCSIS specification
to support encrypted IPv6 multicast. to support encrypted IPv6 multicast.
There are limited changes that have to be done for hosts in order to There are limited changes that have to be done for hosts in order to
enhance security. The Privacy extensions [RFC3041] for auto- enhance security. The privacy extensions [RFC3041] for auto-
configuration should be used by the hosts. IPv6 firewall functions configuration should be used by the hosts. IPv6 firewall functions
could be enabled, if available on the host or GWR. could be enabled, if available on the host or GWR.
The ISP provides security against attacks that come from its own The ISP provides security against attacks that come from its own
subscribers but it could also implement security services that subscribers, but it could also implement security services that
protect its subscribers from attacks sourced from the outside of its protect its subscribers from attacks sourced from the outside of its
network. Such services do not apply at the access level of the network. Such services do not apply at the access level of the
network discussed here. network discussed here.
The CMTS/ER should protect the ISP network and the other subscribers The CMTS/ER should protect the ISP network and the other subscribers
against attacks by one of its own customers. For this reason Unicast against attacks by one of its own customers. For this reason Unicast
Reverse Path Forwarding (uRPF) [RFC3704] and ACLs should be used on Reverse Path Forwarding (uRPF) [RFC3704] and Access Control Lists
all interfaces facing subscribers. Filtering should be implemented (ACLs) should be used on all interfaces facing subscribers.
with regard for the operational requirements of IPv6 [Security Filtering should be implemented with regard for the operational
considerations for IPv6]. requirements of IPv6 [IPv6-Security].
The CMTS/ER should protect its processing resources against floods of The CMTS/ER should protect its processing resources against floods of
valid customer control traffic such as: Router and Neighbor valid customer control traffic such as: Router and Neighbor
Solicitations, MLD Requests. Solicitations, and MLD Requests.
All other security features used with the IPv4 service should be All other security features used with the IPv4 service should be
similarly applied to IPv6 as well. similarly applied to IPv6 as well.
5.2.6. IPv6 Network Management 5.2.6. IPv6 Network Management
IPv6 can have many applications in Cable Networks. MSOs can IPv6 can have many applications in cable networks. MSOs can
initially implement IPv6 on the control plane and use it to manage 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 the thousands of devices connected to the CMTS. This would be a good
way to introduce IPv6 in a Cable Network. Later on the MSO can way to introduce IPv6 in a cable network. Later, the MSO can extend
extend IPv6 to the data plane and use it to carry customer as well as IPv6 to the data plane and use it to carry customer traffic as well
management traffic. as management traffic.
5.2.6.1. Using IPv6 for Management in Cable Networks 5.2.6.1. Using IPv6 for Management in Cable Networks
IPv6 can be enabled in a Cable Network for management of devices like IPv6 can be enabled in a cable network for management of devices like
CM, CMTS and ER. With the roll out of advanced services like VoIP 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 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 number of devices connected to the CMTS. In IPv4, an RFC1918 address
is assigned to these devices for management purposes. Since there is is assigned to these devices for management purposes. Since there is
a finite number of RFC1918 addresses available, it is becoming a finite number of RFC1918 addresses available, it is becoming
difficult for MSOs to manage these devices. difficult for MSOs to manage these devices.
By using IPv6 for management purposes, MSOs can scale their network By using IPv6 for management purposes, MSOs can scale their network
management systems to meet their needs. The CMTS/ER can be management systems to meet their needs. The CMTS/ER can be
configured with a /64 management prefix which is shared among all CMs configured with a /64 management prefix that is shared among all CMs
connected to the CMTS cable interface. Addressing for the CMs can be connected to the CMTS cable interface. Addressing for the CMs can be
done via stateless auto-configuration or DHCPv6. Once the CMs done via stateless auto-configuration or DHCPv6. Once the CMs
receive a /64 prefix they can configure themselves with an IPv6 receive a /64 prefix, they can configure themselves with an IPv6
address. address.
If there are devices behind the CM which need to be managed by the 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 MSO, another /64 prefix can be defined on the CMTS/ER. These devices
can also use stateless auto-configuration to assign themselves an can also use stateless auto-configuration to assign themselves an
IPv6 address. IPv6 address.
Traffic sourced from or destined to the management prefix should not Traffic sourced from or destined to the management prefix should not
cross the MSO's network boundaries. cross the MSO's network boundaries.
In this scenario IPv6 will only be used for managing devices on the 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 cable network. The CM will no longer require an IPv4 address for
management as described in DOCSIS 3.0 [DOCSIS 3.0 Requirements]. management as described in DOCSIS 3.0 [DOCSIS3.0-Reqs].
5.2.6.2. Updates to MIB modules/Standards to support IPv6 5.2.6.2. Updates to MIB Modules/Standards to Support IPv6
The current DOCSIS, PacketCable, and CableHome MIB modules are The current DOCSIS, PacketCable, and CableHome MIB modules are
already designed to support IPv6 objects. In this case, IPv6 will already designed to support IPv6 objects. In this case, IPv6 will
neither add, nor change any of the functionality of these MIB neither add nor change any of the functionality of these MIB modules.
modules. The Textual Convention used to represent SMIv2 objects The Textual Convention used to represent Structure of Management
representing IP addresses was updated [RFC4001] and a new Textual Information Version 2 (SMIv2) objects representing IP addresses was
Convention InetAddressType was added to identify the type of the IP updated [RFC4001] and a new Textual Convention InetAddressType was
address used for IP address objects in MIB modules. added to identify the type of the IP address used for IP address
objects in MIB modules.
There are some exceptions, the MIB modules that might need to add There are some exceptions; the MIB modules that might need to add
IPv6 support are defined in the DOCSIS 3.0 OSSI specification [DOCSIS IPv6 support are defined in the DOCSIS 3.0 OSSI specification
3.0 OSSI]. [DOCSIS3.0-OSSI].
6. Broadband DSL Networks 6. Broadband DSL Networks
This section describes the IPv6 deployment options in today's High This section describes the IPv6 deployment options in today's high-
Speed DSL Networks. speed DSL networks.
6.1. DSL Network Elements 6.1. DSL Network Elements
Digital Subscriber Line (DSL) broadband services provide users with Digital Subscriber Line (DSL) broadband services provide users with
IP connectivity over the existing twisted-pair telephone lines called IP connectivity over the existing twisted-pair telephone lines called
the local-loop. A wide range of bandwidth offerings are available the local-loop. A wide range of bandwidth offerings are available
depending on the quality of the line and the distance between the depending on the quality of the line and the distance between the
Customer Premise Equipment and the DSLAM. Customer Premise Equipment and the DSL Access Multiplexer (DSLAM).
The following network elements are typical of a DSL network: The following network elements are typical of a DSL network:
DSL Modem: It can be a stand alone device, it can be incorporated in DSL Modem: It can be a stand-alone device, be incorporated in the
the host, it can incorporate router functionalities and also have the host, incorporate router functionalities, and also have the
capability to act as a CPE router. capability to act as a CPE router.
Customer Premise Router: It is used to provide Layer 3 services for Customer Premise Router (CPR): It is used to provide Layer 3 services
customer premise networks. It is usually used to provide firewalling for customer premise networks. It is usually used to provide
functions and segment broadcast domains for a Small business. firewalling functions and segment broadcast domains for a small
business.
DSL Access Multiplexer (DSLAM): It terminates multiple twisted pair DSL Access Multiplexer (DSLAM): It terminates multiple twisted-pair
telephone lines and provides aggregation to BRAS. telephone lines and provides aggregation to BRAS.
Broadband Remote Access Server (BRAS): It aggregates or terminates Broadband Remote Access Server (BRAS): It aggregates or terminates
multiple PVC corresponding to the subscriber DSL circuits. multiple Permanent Virtual Circuits (PVCs) corresponding to the
subscriber DSL circuits.
Edge Router (ER): It provides the Layer 3 interface to the ISP Edge Router (ER): It provides the Layer 3 interface to the ISP
network. network.
Figure 6.1 depicts all the network elements mentioned Figure 6.1 depicts all the network elements mentioned.
Customer Premise | Network Access Provider | Network Service Provider Customer Premise | Network Access Provider | Network Service Provider
CP NAP NSP CP NAP NSP
+-----+ +------+ +------+ +--------+ +-----+ +------+ +------+ +--------+
|Hosts|--|Router| +--+ BRAS +---+ Edge | ISP |Hosts|--|Router| +--+ BRAS +---+ Edge | ISP
+-----+ +--+---+ | | | | Router +==> Network +-----+ +--+---+ | | | | Router +==> Network
| | +------+ +--------+ | | +------+ +--------+
+--+---+ | +--+---+ |
| DSL +-+ | | DSL +-+ |
|Modem | | | |Modem | | |
skipping to change at page 27, line 22 skipping to change at page 27, line 43
| | +------+ +--------+ | | +------+ +--------+
+--+---+ | +--+---+ |
| DSL +-+ | | DSL +-+ |
|Modem | | | |Modem | | |
+------+ | +-----+ | +------+ | +-----+ |
+--+ | | +--+ | |
+------+ |DSLAM+--+ +------+ |DSLAM+--+
+-----+ | DSL | +--+ | +-----+ | DSL | +--+ |
|Hosts|--+Modem +-+ +-----+ |Hosts|--+Modem +-+ +-----+
+-----+ +--+---+ +-----+ +--+---+
Figure 6.1 Figure 6.1
6.2. Deploying IPv6 in IPv4 DSL Networks 6.2. Deploying IPv6 in IPv4 DSL Networks
There are three main design approaches to providing IPv4 connectivity There are three main design approaches to providing IPv4 connectivity
over a DSL infrastructure: over a DSL infrastructure:
1. Point-to-Point Model: Each subscriber connects to the DSLAM over 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 a twisted pair and is provided with a unique PVC that links it to
service provider. The PVCs can be terminated at the BRAS or at the the service provider. The PVCs can be terminated at the BRAS or
Edge Router. This type of design is not very scalable if the PVCs at the Edge Router. This type of design is not very scalable if
are not terminated as close as possible to the DSLAM (at the BRAS). the PVCs are not terminated as close as possible to the DSLAM (at
In this case a large number of Layer 2 circuits has to be maintained the BRAS). In this case, a large number of Layer 2 circuits has
over a significant portion of the network. The Layer 2 domains can to be maintained over a significant portion of the network. The
be terminated at the ER in three ways: Layer 2 domains can be terminated at the ER in three ways:
A. In a common bridge group with a virtual interface that routes A. In a common bridge group with a virtual interface that routes
traffic out. traffic out.
B. Enable a Routed Bridged Encapsulation feature, all users could be B. By enabling a Routed Bridged Encapsulation feature, all users
part of the same subnet. This is the most common deployment approach could be part of the same subnet. This is the most common
of IPv4 over DSL but it might not be the best choice in IPv6 where deployment approach of IPv4 over DSL but it might not be the
address availability is not an issue. best choice in IPv6 where address availability is not an
issue.
C. Terminate the PVC at Layer 3, each PVC has its own prefix. This C. By terminating the PVC at Layer 3, each PVC has its own
is the approach that seems more suitable for IPv6 and is presented in prefix. This is the approach that seems more suitable for
6.2.1 In none of these cases the CPE (DSL Modem) has to be upgraded. IPv6 and is presented in Section 6.2.1.
None of these ways requires that the CPE (DSL modem) be
upgraded.
2. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened 2. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened
between each subscriber and the BRAS. The BRAS terminates the PPP between each subscriber and the BRAS. The BRAS terminates the
sessions and provides Layer 3 connectivity between the subscriber and PPP sessions and provides Layer 3 connectivity between the
the ISP. This model is presented in section 6.2.2. subscriber and the ISP. This model is presented in Section
6.2.2.
3. L2TP Access Aggregation (LAA) Model: PPP sessions are opened 3. Layer 2 Tunneling Protocol (L2TP) Access Aggregation (LAA) Model:
between each subscriber and the ISP Edge Router. The BRAS tunnels PPP sessions are opened between each subscriber and the ISP Edge
the subscriber PPP sessions to the ISP by encapsulating them into Router. The BRAS tunnels the subscriber PPP sessions to the ISP
L2TPv2 [RFC2661] tunnels. This model is presented in section 6.2.3. by encapsulating them into L2TPv2 [RFC2661] tunnels. This model
is presented in Section 6.2.3.
In aggregation models the BRAS terminates the subscriber PVCs and In aggregation models, the BRAS terminates the subscriber PVCs and
aggregates their connections before providing access to the ISP. aggregates their connections before providing access to the ISP.
In order to maintain the deployment concepts and business models In order to maintain the deployment concepts and business models
proven and used with existing revenue generating IPv4 services, the proven and used with existing revenue generating IPv4 services, the
IPv6 deployment will match the IPv4 one. This approach is presented IPv6 deployment will match the IPv4 one. This approach is presented
in sections 6.2.1-3 that describe current IPv4 over DSL broadband in Sections 6.2.1 - 6.2.3 that describe current IPv4 over DSL
access deployments. Under certain circumstances where new service broadband access deployments. Under certain circumstances where new
types or service needs justify it, IPv4 and IPv6 network logical service types or service needs justify it, IPv4 and IPv6 network
architectures could be different as described in section 6.2.4. logical architectures could be different as described in Section
6.2.4.
6.2.1. Point-to-Point Model 6.2.1. Point-to-Point Model
In this scenario the Ethernet frames from the Host or the Customer In this scenario, the Ethernet frames from the Host or the Customer
Premise Router are bridged over the PVC assigned to the subscriber. Premise Router are bridged over the PVC assigned to the subscriber.
Figure 6.2.1 describes the protocol architecture of this model Figure 6.2.1 describes the protocol architecture of this model.
Customer Premise NAP NSP Customer Premise NAP NSP
|-------------------------| |---------------| |------------------| |-------------------------| |---------------| |------------------|
+-----+ +-------+ +-----+ +--------+ +----------+ +-----+ +-------+ +-----+ +--------+ +----------+
|Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP |Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP
+-----+ +-------+ |Modem| +--------+ | Router +=>Network +-----+ +-------+ |Modem| +--------+ | Router +=>Network
+-----+ +----------+ +-----+ +----------+
|----------------------------| |----------------------------|
ATM ATM
Figure 6.2.1 Figure 6.2.1
6.2.1.1. IPv6 Related Infrastructure Changes 6.2.1.1. IPv6 Related Infrastructure Changes
In this scenario the DSL modem and the entire NAP is Layer 3 unaware, In this scenario, the DSL modem and the entire NAP is Layer 3
so no changes are needed to support IPv6. The following devices have unaware, so no changes are needed to support IPv6. The following
to be upgraded to dual stack: Host, Customer Router (if present) and devices have to be upgraded to dual stack: Host, Customer Router (if
Edge Router. present), and Edge Router.
6.2.1.2. Addressing 6.2.1.2. Addressing
The Hosts or the Customer Routers have the Edge Router as their Layer The Hosts or the Customer Routers have the Edge Router as their Layer
3 next hop. 3 next hop.
If there is no Customer Router all the hosts on the subscriber site 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 belong to the same /64 subnet that is statically configured on the
Edge Router for that subscriber PVC. The hosts can use stateless Edge Router for that subscriber PVC. The hosts can use stateless
auto-configuration or stateful DHCPv6 based configuration to acquire auto-configuration or stateful DHCPv6-based configuration to acquire
an address via the Edge Router. an address via the Edge Router.
However, as manual configuration for each customer is a provisioning However, as manual configuration for each customer is a provisioning
challenge, implementations are encouraged to develop mechanism(s) challenge, implementers are encouraged to develop mechanism(s) that
which automatically map the PVC (or some other customer-specific automatically map the PVC (or some other customer-specific
information) to an IPv6 subnet prefix, and advertise the customer- information) to an IPv6 subnet prefix, and advertise the customer-
specific prefix to all the customers with minimal configuration. specific prefix to all the customers with minimal configuration.
If a Customer Router is present: If a Customer Router is present:
A. It is statically configured with an address on the /64 subnet A. It is statically configured with an address on the /64 subnet
between itself and the Edge Router, and with /64 prefixes on the between itself and the Edge Router, and with /64 prefixes on the
interfaces connecting the hosts on the customer site. This is not a interfaces connecting the hosts on the customer site. This is
desired provisioning method being expensive and difficult to manage. not a desired provisioning method being expensive and difficult
to manage.
B. It can use its link-local address to communicate with the ER. It B. It can use its link-local address to communicate with the ER. It
can also dynamically acquire through stateless auto-configuration the can also dynamically acquire, through stateless auto-
prefix for the link between itself and the ER. The later option configuration, the prefix for the link between itself and the ER.
allows it to contact a remote DHCPv6 server if needed. This step is The later option allows it to contact a remote DHCPv6 server, if
followed by a request via DHCP-PD for a prefix shorter than /64 that needed. This step is followed by a request via DHCP-PD for a
in turn is divided in /64s and assigned to its downstream interfaces. prefix shorter than /64 that, in turn, is divided in /64s and
assigned to its downstream interfaces.
The Edge Router has a /64 prefix configured for each subscriber PVC. The Edge Router has a /64 prefix configured for each subscriber PVC.
Each PVC should be enabled to relay DHCPv6 requests from the Each PVC should be enabled to relay DHCPv6 requests from the
subscribers to DHCPv6 servers in the ISP network. The PVCs providing subscribers to DHCPv6 servers in the ISP network. The PVCs providing
access for subscribers that use DHCP-PD as well, have to be enabled 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 to support the feature. The uplink to the ISP network is configured
with a /64 prefix as well. with a /64 prefix as well.
The prefixes used for subscriber links and the ones delegated via The prefixes used for subscriber links and the ones delegated via
DHCP-PD should be planned in a manner that allows as much DHCP-PD should be planned in a manner that allows as much
summarization as possible at the Edge Router. summarization as possible at the Edge Router.
Other information of interest to the host, such as DNS, is provided Other information of interest to the host, such as DNS, is provided
through stateful DHCPv6 [RFC3315] and stateless DHCPv6 [RFC3736]. through stateful DHCPv6 [RFC3315] and stateless DHCPv6 [RFC3736].
6.2.1.3. Routing 6.2.1.3. Routing
The CPE devices are configured with a default route that points to The CPE devices are configured with a default route that points to
the Edge router. No routing protocols are needed on these devices the Edge Router. No routing protocols are needed on these devices,
which generally have limited resources. which generally have limited resources.
The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 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, The connected prefixes have to be redistributed. If DHCP-PD is used,
with every delegated prefix a static route is installed by the Edge with every delegated prefix a static route is installed by the Edge
Router. For this reason the static routes must also be Router. For this reason, the static routes must also be
redistributed. Prefix summarization should be done at the Edge redistributed. Prefix summarization should be done at the Edge
Router. Router.
6.2.2. PPP Terminated Aggregation (PTA) Model 6.2.2. PPP Terminated Aggregation (PTA) Model
The PTA architecture relies on PPP-based protocols (PPPoA [RFC2364] The PTA architecture relies on PPP-based protocols (PPPoA [RFC2364]
and PPPoE [RFC2516]). The PPP sessions are initiated by Customer and PPPoE [RFC2516]). The PPP sessions are initiated by Customer
Premise Equipment and are terminated at the BRAS. The BRAS Premise Equipment and are terminated at the BRAS. The BRAS
authorizes the session, authenticates the subscriber, and provides an authorizes the session, authenticates the subscriber, and provides an
IP address on behalf of the ISP. The BRAS then does Layer 3 routing IP address on behalf of the ISP. The BRAS then does Layer 3 routing
skipping to change at page 30, line 39 skipping to change at page 31, line 29
+-----------+ +-----------+
| AAA | | AAA |
+-------+ Radius | +-------+ Radius |
| | TACACS | | | TACACS |
| +-----------+ | +-----------+
+-----+ +-------+ +--------+ +----+-----+ +-----------+ +-----+ +-------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core +-----+ +-------+ +--------+ +----------+ | Router +=>Core
|--------------------------| +-----------+ |--------------------------| +-----------+
PPP PPP
Figure 6.2.2.1 Figure 6.2.2.1
The PPP sessions are initiated by the Customer Premise Equipment. The PPP sessions are initiated by the Customer Premise Equipment.
The BRAS authenticates the subscriber against a local or a remote The BRAS authenticates the subscriber against a local or a remote
database. Once the session is established, the BRAS provides an database. Once the session is established, the BRAS provides an
address and maybe a DNS server to the user, information acquired from address and maybe a DNS server to the user; this information is
the subscriber profile or from a DHCP server. acquired from the subscriber profile or from a DHCP server.
This solution scales better then the Point-to-Point but since there 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 is only one PPP session per ATM PVC, the subscriber can choose a
single ISP service at a time. single ISP service at a time.
B. Connection using PPPoE B. Connection using PPPoE
Customer Premise NAP NSP Customer Premise NAP NSP
|--------------------------| |-------------------| |---------------| |--------------------------| |-------------------| |---------------|
+-----------+ +-----------+
| AAA | | AAA |
+-------+ Radius | +-------+ Radius |
skipping to change at page 31, line 21 skipping to change at page 32, line 21
+-------+ Radius | +-------+ Radius |
| | TACACS | | | TACACS |
| +-----------+ | +-----------+
| |
+-----+ +-------+ +--------+ +-----+----+ +-----------+ +-----+ +-------+ +--------+ +-----+----+ +-----------+
|Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C |Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +----------+ | Router +=>O +-----+ +-------+ +--------+ +----------+ | Router +=>O
| | R | | R
|--------------------------------| +-----------+ E |--------------------------------| +-----------+ E
PPP PPP
Figure 6.2.2.2 Figure 6.2.2.2
The operation of PPPoE is similar to PPPoA with the exception that The operation of PPPoE is similar to PPPoA with the exception that
with PPPoE multiple sessions can be supported over the same PVC thus with PPPoE multiple sessions can be supported over the same PVC, thus
allowing the subscriber to connect to multiple services at the same allowing the subscriber to connect to multiple services at the same
time. The hosts can initiate the PPPoE sessions as well. It is time. The hosts can initiate the PPPoE sessions as well. It is
important to remember that the PPPoE encapsulation reduces the IP MTU important to remember that the PPPoE encapsulation reduces the IP MTU
available for the customer traffic due to additional headers. available for the customer traffic due to additional headers.
The network design and operation of the PTA model is the same The network design and operation of the PTA model is the same,
regardless of the PPP encapsulation type used. regardless of the PPP encapsulation type used.
6.2.2.1. IPv6 Related Infrastructure Changes 6.2.2.1. IPv6 Related Infrastructure Changes
In this scenario the BRAS is Layer 3 aware and it has to be upgraded 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 IPv6. Since the BRAS terminates the PPP sessions it has
to support the implementation of these PPP protocols with IPv6. The to support the implementation of these PPP protocols with IPv6. The
following devices have to be upgraded to dual stack: Host, Customer following devices have to be upgraded to dual stack: Host, Customer
Router (if present), BRAS and Edge Router. Router (if present), BRAS, and Edge Router.
6.2.2.2. Addressing 6.2.2.2. Addressing
The BRAS terminates the PPP sessions and provides the subscriber with The BRAS terminates the PPP sessions and provides the subscriber with
an IPv6 address from the defined pool for that profile. The an IPv6 address from the defined pool for that profile. The
subscriber profile for authorization and authentication can be subscriber profile for authorization and authentication can be
located on the BRAS or on a AAA server. The Hosts or the Customer located on the BRAS or on an Authentication, Authorization, and
Routers have the BRAS as their Layer 3 next hop. Accounting (AAA) server. The Hosts or the Customer Routers have the
BRAS as their Layer 3 next hop.
The PPP session can be initiated by a host or by a Customer Router. The PPP session can be initiated by a host or by a Customer Router.
In the latter case, once the session is established with the BRAS and 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 an address is negotiated for the uplink to the BRAS, DHCP-PD can be
used to acquire prefixes for the Customer Router other interfaces. used to acquire prefixes for the Customer Router other interfaces.
The BRAS has to be enabled to support DHCP-PD and to relay the DHCPv6 The BRAS has to be enabled to support DHCP-PD and to relay the DHCPv6
requests of the hosts on the subscriber sites. requests of the hosts on the subscriber sites.
The BRAS has a /64 prefixes configured on the link to the Edge The BRAS has /64 prefixes configured on the link to the Edge router.
router. The Edge router links are also configured with /64 prefixes The Edge Router links are also configured with /64 prefixes to
to provide connectivity to the rest of the ISP network. provide connectivity to the rest of the ISP network.
The prefixes used for subscriber and the ones delegated via DHCP-PD The prefixes used for subscribers and the ones delegated via DHCP-PD
should be planned in a manner that allows maximum summarization at should be planned in a manner that allows maximum summarization at
the BRAS. the BRAS.
Other information of interest to the host, such as DNS, is provided Other information of interest to the host, such as DNS, is provided
through stateful [RFC3315] and stateless [RFC3736] DHCPv6. through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
6.2.2.3. Routing 6.2.2.3. Routing
The CPE devices are configured with a default route that points to The CPE devices are configured with a default route that points to
the BRAS router. No routing protocols are needed on these devices the BRAS router. No routing protocols are needed on these devices,
which generally have limited resources. which generally have limited resources.
The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the 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 addresses assigned to the PPP sessions are represented as connected
host routes, connected prefixes have to be redistributed. If DHCP-PD host routes, connected prefixes have to be redistributed. If DHCP-PD
is used, with every delegated prefix a static route is installed by is used, with every delegated prefix a static route is installed by
the Edge Router. For this reason the static routes must also be the Edge Router. For this reason, the static routes must also be
redistributed. Prefix summarization should be done at the BRAS. redistributed. Prefix summarization should be done at the BRAS.
The Edge Router is running the IGP used in the ISP network: OSPFv3 or The Edge Router is running the IGP used in the ISP network: OSPFv3 or
IS-IS. IS-IS.
A separation between the routing domains of the ISP and the Access A separation between the routing domains of the ISP and the Access
Provider is recommended if they are managed independently. Provider is recommended if they are managed independently.
Controlled redistribution will be needed between the Access Provider Controlled redistribution will be needed between the Access Provider
IGP and the ISP IGP. IGP and the ISP IGP.
6.2.3. L2TPv2 Access Aggregation (LAA) Model 6.2.3. L2TPv2 Access Aggregation (LAA) Model
In the LAA model the BRAS forwards the CPE initiated session to the 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 ISP over an L2TPv2 tunnel established between the BRAS and the Edge
Router. In this case the authentication, authorization and Router. In this case, the authentication, authorization, and
subscriber configuration are performed by the ISP itself. There are subscriber configuration are performed by the ISP itself. There are
two types of PPP encapsulations that can be leveraged with this two types of PPP encapsulations that can be leveraged with this
model: model:
A. Connection via PPPoA A. Connection via PPPoA
Customer Premise NAP NSP Customer Premise NAP NSP
|--------------------| |----------------------| |----------------| |--------------------| |----------------------| |----------------|
+-----------+ +-----------+
| AAA | | AAA |
skipping to change at page 33, line 44 skipping to change at page 34, line 45
| | | |
+-----+ +-------+ +--------+ +----+-----+ +----+------+ +-----+ +-------+ +--------+ +----+-----+ +----+------+
|Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C |Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +----------+ | Router +=>O +-----+ +-------+ +--------+ +----------+ | Router +=>O
| | R | | R
+-----------+ E +-----------+ E
|-----------------------------------------------| |-----------------------------------------------|
PPP PPP
|--------------| |--------------|
L2TPv2 L2TPv2
Figure 6.2.3.2 Figure 6.2.3.2
The network design and operation of the PTA model is the same The network design and operation of the PTA model is the same,
regardless of the PPP encapsulation type used. regardless of the PPP encapsulation type used.
6.2.3.1. IPv6 Related Infrastructure Changes 6.2.3.1. IPv6 Related Infrastructure Changes
In this scenario the BRAS is forwarding the PPP sessions initiated by In this scenario, the BRAS is forwarding the PPP sessions initiated
the subscriber over the L2TPv2 tunnel established to the LNS, the by the subscriber over the L2TPv2 tunnel established to the L2TP
aggregation point in the ISP network. The L2TPv2 tunnel between the Network Server (LNS), the aggregation point in the ISP network. The
LAC and LNS can run over IPv6 or IPv4. These capabilities have to be L2TPv2 tunnel between the L2TP Access Concentrator (LAC) and LNS can
supported on the BRAS. The following devices have to be upgraded to run over IPv6 or IPv4. These capabilities have to be supported on
dual stack: Host, Customer Router and Edge Router. If the tunnel is the BRAS. The following devices have to be upgraded to dual stack:
set up over IPv6 then the BRAS must 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.
6.2.3.2. Addressing 6.2.3.2. Addressing
The Edge router terminates the PPP sessions and provides the The Edge Router terminates the PPP sessions and provides the
subscriber with an IPv6 address from the defined pool for that subscriber with an IPv6 address from the defined pool for that
profile. The subscriber profile for authorization and authentication profile. The subscriber profile for authorization and authentication
can be located on the Edge Router or on a AAA server. The Hosts or 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. the Customer Routers have the Edge Router as their Layer 3 next hop.
The PPP session can be initiated by a host or by a Customer Router. The PPP session can be initiated by a host or by a Customer Router.
In the latter case, once the session is established with the Edge 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, DHCP-PD can be used to acquire prefixes for the Customer
Router interfaces. The Edge Router has to be enabled to support Router interfaces. The Edge Router has to be enabled to support
DHCP-PD and to relay the DHCPv6 requests generated by the hosts on DHCP-PD and to relay the DHCPv6 requests generated by the hosts on
the subscriber sites. the subscriber sites.
The BRAS has a /64 prefix configured on the link to the Edge router. 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 The Edge Router links are also configured with /64 prefixes to
provide connectivity to the rest of the ISP network. Other provide connectivity to the rest of the ISP network. Other
information of interest to the host, such as DNS, is provided through information of interest to the host, such as DNS, is provided through
stateful [RFC3315] and stateless [RFC3736] DHCPv6. stateful [RFC3315] and stateless [RFC3736] DHCPv6.
It is important to note here a significant difference between this It is important to note here a significant difference between this
deployment for IPv6 versus IPv4. In the case of IPv4 the customer 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 router or CPE can end up on any Edge Router (acting as LNS), where
assumption is that there are at least two of them for redundancy the assumption is that there are at least two of them for redundancy
purposes. Once authenticated, the customer will be given an address purposes. Once authenticated, the customer will be given an address
from the IP pool of the ER (LNS) it connected to. This allows the 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. ERs (LNSs) to aggregate the addresses handed out to the customers.
In the case of IPv6, an important constraint that likely will be In the case of IPv6, an important constraint that likely will be
enforced is that the customer should keep its own address regardless enforced is that the customer should keep its own address, regardless
of the ER (LNS) it connects to. This could significantly reduce the of the ER (LNS) it connects to. This could significantly reduce the
prefix aggregation capabilities of the ER (LNS). This is different prefix aggregation capabilities of the ER (LNS). This is different
than the current IPv4 deployment where addressing is dynamic in than the current IPv4 deployment where addressing is dynamic in
nature and the same user can get different addresses depending on the nature, and the same user can get different addresses depending on
LNS it ends up connecting to. the LNS it ends up connecting to.
One possible solution is to ensure that a given BRAS will always 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 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 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 the same ER (primary, if up, or secondary, if not). Each ER (LNS)
carry summary statements in their routing protocol configuration for can carry summary statements in their routing protocol configuration
the prefixes they are the primary ER (LNS) as well as for the ones for the prefixes for which they are the primary ER (LNS), as well as
for which they are the secondary. This way the prefixes will be for the ones for which they are the secondary. This way the prefixes
summarized any time they become "active" on the ER (LNS). will be summarized any time they become "active" on the ER (LNS).
6.2.3.3. Routing 6.2.3.3. Routing
The CPE devices are configured with a default route that points to The CPE devices are configured with a default route that points to
the Edge router that terminates the PPP sessions. No routing the Edge Router that terminates the PPP sessions. No routing
protocols are needed on these devices which have generally limited protocols are needed on these devices, which generally have limited
resources. resources.
The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. 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 Different processes should be used if the NAP and the NSP are managed
by different organizations. In this case, controlled redistribution by different organizations. In this case, controlled redistribution
should be enabled between the two domains. should be enabled between the two domains.
The Edge Router is running the IPv6 IGP used in the ISP network: The Edge Router is running the IPv6 IGP used in the ISP network:
OSPFv3 or IS-IS. OSPFv3 or IS-IS.
6.2.4. Hybrid Model for IPv4 and IPv6 Service 6.2.4. Hybrid Model for IPv4 and IPv6 Service
It was recommended throughout this section that the IPv6 service It was recommended throughout this section that the IPv6 service
implementation should map the existing IPv4 one. This approach implementation should map the existing IPv4 one. This approach
simplifies manageability and minimizes training needed for personnel simplifies manageability and minimizes training needed for personnel
operating the network. In certain circumstances such mapping is not operating the network. In certain circumstances such mapping is not
feasible. This typically becomes the case when a Service Provider feasible. This typically becomes the case when a Service Provider
plans to expand its service offering with the new IPv6 deployed plans to expand its service offering with the new IPv6 deployed
infrastructure. If this new service is not well supported in a infrastructure. If this new service is not well supported in a
network design such as the one used for IPv4 then a different design network design such as the one used for IPv4, then a different design
might be used for IPv6. might be used for IPv6.
An example of such circumstances is that of a provider using an LAA 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 design for its IPv4 services. In this case all the PPP sessions are
bundled and tunneled across the entire NAP infrastructure which is bundled and tunneled across the entire NAP infrastructure which is
made of multiple BRAS routers, aggregation routers etc. The end made of multiple BRAS routers, aggregation routers etc. The end
point of these tunnels is the ISP Edge Router. If the provider point of these tunnels is the ISP Edge Router. If the provider
decides to offer multicast services over such a design, it will face decides to offer multicast services over such a design, it will face
the problem of NAP resources being over utilized. The multicast the problem of NAP resources being over utilized. The multicast
traffic can be replicated only at the end of the tunnels by the Edge 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 Router and the copies for all the subscribers are carried over the
entire NAP. entire NAP.
A Modified Point-to-Point (as described in 6.2.4.2) or PTA model are A Modified Point-to-Point (as described in Section 6.2.4.2) or PTA
more suitable to support multicast services because the packet model is more suitable to support multicast services because the
replication can be done closer to the destination at the BRAS. Such packet replication can be done closer to the destination at the BRAS.
topology saves NAP resources. Such topology saves NAP resources.
In this sense IPv6 deployment can be viewed as an opportunity to In this sense, IPv6 deployment can be viewed as an opportunity to
build an infrastructure that might better support the expansion of build an infrastructure that might better support the expansion of
services. In this case, an SP using the LAA design for its IPv4 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 services might choose a modified Point-to-Point or PTA design for
IPv6. IPv6.
6.2.4.1. IPv4 in LAA Model and IPv6 in PTA Model 6.2.4.1. IPv4 in LAA Model and IPv6 in PTA Model
The coexistence of the two PPP based models, PTA and LAA, is The coexistence of the two PPP-based models, PTA and LAA, is
relatively straight forward. The PPP sessions are terminated on relatively straight forward. The PPP sessions are terminated on
different network devices for the IPv4 and IPv6 services. The PPP different network devices for the IPv4 and IPv6 services. The PPP
sessions for the existing IPv4 service deployed in an LAA model are sessions for the existing IPv4 service deployed in an LAA model are
terminated on the Edge Router. The PPP sessions for the new IPv6 terminated on the Edge Router. The PPP sessions for the new IPv6
service deployed in a PTA model are terminated on the BRAS. service deployed in a PTA model are terminated on the BRAS.
The logical design for IPv6 and IPv4 in this hybrid model is The logical design for IPv6 and IPv4 in this hybrid model is
presented in Figure 6.2.4.1. presented in Figure 6.2.4.1.
IPv6 |--------------------------| IPv6 |--------------------------|
skipping to change at page 36, line 40 skipping to change at page 37, line 43
| +-----+-----+ | +-----+-----+
| | | |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+ +-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core +-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+ +-----------+
IPv4 |----------------------------------------| IPv4 |----------------------------------------|
PPP PPP
|------------| |------------|
L2TPv2 L2TPv2
Figure 6.2.4.1 Figure 6.2.4.1
6.2.4.2. IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model 6.2.4.2. IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model
In this particular scenario the Point-to-Point model used for the In this particular scenario the Point-to-Point model used for the
IPv6 service is a modified version of the model described in section IPv6 service is a modified version of the model described in section
6.2.1. 6.2.1.
For the IPv4 service in LAA model, the PVCs are terminated on the 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 BRAS and PPP sessions are terminated on the Edge Router (LNS). For
IPv6 service in Point-to-Point model, the PVCs are terminated at the IPv6 service in the Point-to-Point model, the PVCs are terminated at
Edge Router as described in section 6.2.1. In this hybrid model, the the Edge Router as described in Section 6.2.1. In this hybrid model,
Point-to-Point link could be terminated on the BRAS, a NAP owned 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 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 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 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. Router, as described in Section 6.2.1, are now implemented on the
BRAS.
The other aspect of this deployment model is the fact that the 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 capable of distinguishing between the IPv4 PPP traffic that
has to be bridged across the L2TPv2 tunnel and the IPv6 packets 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 have to be routed to the NSP. The IPv6 Routing and Bridging
Encapsulation (RBE) has to be enabled on all interfaces with PVCs Encapsulation (RBE) has to be enabled on all interfaces with PVCs
supporting both IPv4 and IPv6 services in this hybrid design. supporting both IPv4 and IPv6 services in this hybrid design.
The logical design for IPv6 and IPv4 in this hybrid model is The logical design for IPv6 and IPv4 in this hybrid model is
presented in Figure 6.2.4.2. presented in Figure 6.2.4.2.
skipping to change at page 37, line 35 skipping to change at page 38, line 41
| +-----+-----+ | +-----+-----+
| | | |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+ +-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core +-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+ +-----------+
IPv4 |----------------------------------------| IPv4 |----------------------------------------|
PPP PPP
|------------| |------------|
L2TPv2 L2TPv2
Figure 6.2.4.2 Figure 6.2.4.2
6.3. IPv6 Multicast 6.3. IPv6 Multicast
The deployment of IPv6 multicast services relies on MLD, identical to The deployment of IPv6 multicast services relies on MLD, identical to
IGMP in IPv4 and on PIM for routing. ASM (Any Source Multicast) and IGMP in IPv4 and on PIM for routing. ASM (Any Source Multicast) and
SSM (Single Source Multicast) service models operate almost the same SSM (Single Source Multicast) service models operate almost the same
as in IPv4. Both have the same benefits and disadvantages as in as in IPv4. Both have the same benefits and disadvantages as in
IPv4. Nevertheless, the larger address space and the scoped address IPv4. Nevertheless, the larger address space and the scoped address
architecture provide major benefits for multicast IPv6. Through architecture provide major benefits for multicast IPv6. Through RFC
RFC3306 the large address space provides the means to assign global 3306, the large address space provides the means to assign global
multicast group addresses to organizations or users that were multicast group addresses to organizations or users that were
assigned unicast prefixes. It is a significant improvement with assigned unicast prefixes. It is a significant improvement with
respect to the IPv4 GLOP mechanism [RFC2770]. respect to the IPv4 GLOP mechanism [RFC3180].
This facilitates the deployment of multicast services. The This facilitates the deployment of multicast services. The
discussion of this section applies to all the multicast sections in discussion of this section applies to all the multicast sections in
the document. the document.
6.3.1. ASM Based Deployments 6.3.1. ASM-Based Deployments
Any Source Multicast (ASM) is useful for Service Providers that Any Source Multicast (ASM) is useful for Service Providers that
intend to support the forwarding of multicast traffic of their intend to support the forwarding of multicast traffic of their
customers. It is based on the PIM-SM protocol and it is more complex customers. It is based on the Protocol Independent Multicast -
to manage because of the use of Rendezvous Points (RPs). With IPv6, Sparse Mode (PIM-SM) protocol and it is more complex to manage
static RP and BSR [BSR] can be used for RP-to-group mapping similar because of the use of Rendezvous Points (RPs). With IPv6, static RP
to IPv4. Additionally, the larger IPv6 address space allows for and Bootstrap Router [BSR] can be used for RP-to-group mapping
building up of group addresses that incorporate the address of the similar to IPv4. Additionally, the larger IPv6 address space allows
RP. This RP-to-group mapping mechanism is called Embedded RP and is for building up of group addresses that incorporate the address of
specific to IPv6. the RP. This RP-to-group mapping mechanism is called Embedded RP and
is specific to IPv6.
In inter-domain deployments, Multicast Source Discovery Protocol In inter-domain deployments, Multicast Source Discovery Protocol
(MSDP) [RFC3618] is an important element of IPv4 PIM-SM deployments. (MSDP) [RFC3618] is an important element of IPv4 PIM-SM deployments.
MSDP is meant to be a solution for the exchange of source MSDP is meant to be a solution for the exchange of source
registration information between RPs in different domains. This registration information between RPs in different domains. This
solution was intended to be temporary. This is one of the reasons solution was intended to be temporary. This is one of the reasons
why it was decided not to implement MSDP in IPv6 [IPv6 Multicast]. why it was decided not to implement MSDP in IPv6 [IPv6-Multicast].
For multicast reachability across domains, Embedded RP can be used. For multicast reachability across domains, Embedded RP can be used.
As Embedded RP provides roughly the same capabilities as MSDP, but in As Embedded RP provides roughly the same capabilities as MSDP, but in
a slightly different way, the best management practices for ASM a slightly different way, the best management practices for ASM
multicast with embedded RP still remain to be developed. multicast with embedded RP still remain to be developed.
6.3.2. SSM Based Deployments 6.3.2. SSM-Based Deployments
Based on PIM-SSM, the Source Specific Multicast deployments do not Based on PIM-SSM, the Source-Specific Multicast deployments do not
need an RP and the related protocols (such as BSR or MSDP) but rely need an RP or related protocols (such as BSR or MSDP), but rely on
on the listeners to know the source of the multicast traffic they the listeners to know the source of the multicast traffic they plan
plan to receive. The lack of RP makes SSM not only simpler to to receive. The lack of RP makes SSM not only simpler to operate,
operate but also robust, it is not impacted by RP failures or inter but also robust; it is not impacted by RP failures or inter-domain
domain constraints. It is also has a higher level of security (No RP constraints. It also has a higher level of security (no RP to be
to be targeted by attacks). For more discussions on the topic of targeted by attacks). For more discussions on the topic of IPv6
IPv6 multicast see [IPv6 Multicast]. multicast, see [IPv6-Multicast].
The typical multicast services offered for residential and very small The typical multicast service offered for residential and very small
businesses is video/audio streaming where the subscriber joins a businesses is video/audio streaming, where the subscriber joins a
multicast group and receives the content. This type of service model multicast group and receives the content. This type of service model
is well supported through PIM-SSM which is very simple and easy to is well supported through PIM-SSM which is very simple and easy to
manage. PIM-SSM has to be enabled throughout the SP network. MLDv2 manage. PIM-SSM has to be enabled throughout the SP network. MLDv2
is required for PIM-SSM support. Vendors can choose to implement is required for PIM-SSM support. Vendors can choose to implement
features that allow routers to map MLDv1 group joins to predefined features that allow routers to map MLDv1 group joins to predefined
sources. sources.
Subscribers might use a set-top box that is responsible for the Subscribers might use a set-top box that is responsible for the
control piece of the multicast service (does group joins/leaves). control piece of the multicast service (does group joins/leaves).
The subscriber hosts can also join desired multicast groups as long The subscriber hosts can also join desired multicast groups as long
as they are enabled to support MLDv1 or MLDv2. If a customer premise 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 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 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 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 3 next hop whether it is the BRAS or the Edge Router. When enabling
this functionality on a customer premise router, its limited this functionality on a CPR, its limited resources should be taken
resources should be taken into consideration. Another option would into consideration. Another option would be for the CPR to support
be for the customer premise router to support MLD proxy routing. MLD proxy routing.
The router that is the Layer 3 next hop for the subscriber (BRAS in 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) 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 has to be enabled to support MLDv1 and MLDv2 in order to process the
requests coming from subscribers without customer premise routers. requests coming from subscribers without CPRs. It has to be enabled
It has to be enabled for PIM-SSM in order to receive joins/leaves for PIM-SSM in order to receive joins/leaves from customer routers
from customer routers and send joins/leaves to the next hop towards and send joins/leaves to the next hop towards the multicast source
the multicast source (Edge router or the NSP core). (Edge Router or the NSP core).
MLD authentication, authorization and accounting is usually MLD authentication, authorization and accounting are usually
configured on the edge router in order to enable the ISP to control 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 the subscriber access of the service and do billing for the content
provided. Alternative mechanisms that would support these functions provided. Alternative mechanisms that would support these functions
should be investigated further. should be investigated further.
6.4. IPv6 QoS 6.4. IPv6 QoS
The QoS configuration is particularly relevant on the router that The QoS configuration is particularly relevant on the router that
represents the Layer 3 next hop for the subscriber (BRAS in the PTA 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 model or the Edge Router in the LAA and Point-to-Point model) in
order to manage resources shared amongst multiple subscribers order to manage resources shared amongst multiple subscribers,
possibly with various service level agreements. possibly with various service level agreements.
In the DSL infrastructure it is expected that there is already a In the DSL infrastructure, it is expected that there is already a
level of traffic policing and shaping implemented for IPv4 level of traffic policing and shaping implemented for IPv4
connectivity. This is implemented throughout the NAP and it is connectivity. This is implemented throughout the NAP and is beyond
beyond the scope of this document. the scope of this document.
On the BRAS or the Edge Router the subscriber facing interfaces have On the BRAS or the Edge Router, the subscriber-facing interfaces have
to be configure to police the inbound customer traffic and shape the to be configured to police the inbound customer traffic and shape the
traffic outbound to the customer based on the SLAs. Traffic traffic outbound to the customer based on the service level
classification and marking should also be done on the router closest agreements (SLAs). Traffic classification and marking should also be
(at Layer 3) to the subscriber in order to support the various types done on the router closest (at Layer 3) to the subscriber in order to
of customer traffic: data, voice, video and to optimally use the support the various types of customer traffic (data, voice, and
infrastructure resources. Each provider (NAP, NSP) could implement video) and to optimally use the infrastructure resources. Each
their own QoS policies and services so reclassification and marking provider (NAP, NSP) could implement their own QoS policies and
might be performed at the boundary between the NAP and the NSP in services so that reclassification and marking might be performed at
order to make sure the traffic is properly handled by the ISP. The the boundary between the NAP and the NSP, in order to make sure the
same IPv4 QoS concepts and methodologies should be applied with IPv6 traffic is properly handled by the ISP. The same IPv4 QoS concepts
as well. and methodologies should be applied with IPv6 as well.
It is important to note that when traffic is encrypted end-to-end, 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 the traversed network devices will not have access to many of the
packet fields used for classification purposes. In these cases packet fields used for classification purposes. In these cases,
routers will most likely place the packets in the default classes. routers will most likely place the packets in the default classes.
The QoS design should take into consideration this scenario and try The QoS design should take into consideration this scenario and try
to use mainly IP header fields for classification purposes. to use mainly IP header fields for classification purposes.
6.5. IPv6 Security Considerations 6.5. IPv6 Security Considerations
There are limited changes that have to be done for CPEs in order to There are limited changes that have to be done for CPEs in order to
enhance security. The Privacy extensions for auto-configuration enhance security. The privacy extensions for auto-configuration
[RFC3041] should be used by the hosts. ISPs can track the prefixes [RFC3041] should be used by the hosts. ISPs can track the prefixes
it assigns to subscribers relatively easily. If however the ISPs are it assigns to subscribers relatively easily. If, however, the ISPs
required by regulations to track their users at /128 address level, are required by regulations to track their users at a /128 address
the Privacy Extensions may be implemented in parallel with network level, the privacy extensions may be implemented in parallel with
management tools that could provide traceability of the hosts. IPv6 network management tools that could provide traceability of the
firewall functions should be enabled on the hosts or customer premise hosts. IPv6 firewall functions should be enabled on the hosts or
router if present. CPR, if present.
The ISP provides security against attacks that come from its own The ISP provides security against attacks that come from its own
subscribers but it could also implement security services that subscribers but it could also implement security services that
protect its subscribers from attacks sourced from the outside of its protect its subscribers from attacks sourced from the outside of its
network. Such services do not apply at the access level of the network. Such services do not apply at the access level of the
network discussed here. network discussed here.
The device that is the Layer 3 next hop for the subscribers (BRAS or The device that is the Layer 3 next hop for the subscribers (BRAS or
Edge router) should protect the network and the other subscribers Edge Router) should protect the network and the other subscribers
against attacks by one of the provider customers. For this reason against attacks by one of the provider customers. For this reason,
uRPF and ACLs should be used on all interfaces facing subscribers. uRPF and ACLs should be used on all interfaces facing subscribers.
Filtering should be implemented with regard for the operational Filtering should be implemented with regard for the operational
requirements of IPv6 [Security considerations for IPv6]. requirements of IPv6 [IPv6-Security].
Authentication and authorization should be used wherever possible.
The BRAS and the Edge Router should protect their processing The BRAS and the Edge Router should protect their processing
resources against floods of valid customer control traffic such as: resources against floods of valid customer control traffic such as:
Router and Neighbor Solicitations, MLD Requests. Rate limiting Router and Neighbor Solicitations, and MLD Requests. Rate limiting
should be implemented on all subscriber facing interfaces. The should be implemented on all subscriber-facing interfaces. The
emphasis should be placed on multicast type traffic as it is most emphasis should be placed on multicast-type traffic, as it is most
often used by the IPv6 control plane. often used by the IPv6 control plane.
All other security features used with the IPv4 service should be All other security features used with the IPv4 service should be
similarly applied to IPv6 as well. similarly applied to IPv6 as well.
6.6. IPv6 Network management 6.6. IPv6 Network Management
The necessary instrumentation (such as MIB modules, NetFlow Records The necessary instrumentation (such as MIB modules, NetFlow Records,
etc) should be available for IPv6. etc.) should be available for IPv6.
Usually, NSPs manage the edge routers by SNMP. The SNMP transport Usually, NSPs manage the edge routers by SNMP. The SNMP transport
can be done over IPv4 if all managed devices have connectivity over can be done over IPv4 if all managed devices have connectivity over
both IPv4 and IPv6. This would imply the smallest changes to the both IPv4 and IPv6. This would imply the smallest changes to the
existing network management practices and processes. Transport over existing network management practices and processes. Transport over
IPv6 could also be implemented and it might become necessary if IPv6 IPv6 could also be implemented, and it might become necessary if IPv6
only islands are present in the network. The management applications only islands are present in the network. The management applications
may be running on hosts belonging to the NSP core network domain. may be running on hosts belonging to the NSP core network domain.
Network Management Applications should handle IPv6 in a similar Network Management Applications should handle IPv6 in a similar
fashion to IPv4, however, they should also support features specific fashion to IPv4; however, they should also support features specific
to IPv6 (such as Neighbor monitoring). to IPv6 (such as neighbor monitoring).
In some cases service providers manage equipment located on customers In some cases, service providers manage equipment located on
LANs. The management of equipment at customers' LANs is out of scope customers' LANs. The management of equipment at customers' LANs is
of this memo. out of scope of this memo.
7. Broadband Ethernet Networks 7. Broadband Ethernet Networks
This section describes the IPv6 deployment options in currently This section describes the IPv6 deployment options in currently
deployed Broadband Ethernet Access Networks. deployed Broadband Ethernet Access Networks.
7.1. Ethernet Access Network Elements 7.1. Ethernet Access Network Elements
In environments that support the infrastructure deploying RJ-45 or In environments that support the infrastructure deploying RJ-45 or
fiber (Fiber to the Home (FTTH) service) to subscribers, 10/100 Mbps fiber (Fiber to the Home (FTTH) service) to subscribers, 10/100 Mbps
Ethernet broadband services can be provided. Such services are Ethernet broadband services can be provided. Such services are
generally available in metropolitan areas, in multi tenant buildings generally available in metropolitan areas in multi-tenant buildings
where an Ethernet infrastructure can be deployed in a cost effective where an Ethernet infrastructure can be deployed in a cost-effective
manner. In such environments Metro-Ethernet services can be used to manner. In such environments, Metro-Ethernet services can be used to
provide aggregation and uplink to a Service Provider. provide aggregation and uplink to a Service Provider.
The following network elements are typical of an Ethernet network: The following network elements are typical of an Ethernet network:
Access Switch: It is used as a Layer 2 access device for subscribers. 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 Router: It is used to provide Layer 3 services for
customer premise networks. customer premise networks.
Aggregation Ethernet Switches: Aggregates multiple subscribers. Aggregation Ethernet Switches: Aggregates multiple subscribers.
skipping to change at page 42, line 21 skipping to change at page 43, line 24
| | +------+ +--------+ | | +------+ +--------+
+--+----+ | +--+----+ |
|Access +-+ | |Access +-+ |
|Switch | | | |Switch | | |
+-------+ | +------+ | +-------+ | +------+ |
+--+Agg E | | +--+Agg E | |
+-------+ |Switch+-+ +-------+ |Switch+-+
+-----+ |Access | +--+ | +-----+ |Access | +--+ |
|Hosts|--+Switch +-+ +------+ |Hosts|--+Switch +-+ +------+
+-----+ +-------+ +-----+ +-------+
Figure 7.1 Figure 7.1
The logical topology and design of Broadband Ethernet Networks is The logical topology and design of Broadband Ethernet Networks are
very similar to DSL Broadband Networks discussed in section 6. very similar to DSL Broadband Networks discussed in Section 6.
It is worth noting that the general operation, concepts and It is worth noting that the general operation, concepts and
recommendations described in this section apply similarly to a recommendations described in this section apply similarly to a
HomePNA based network environment. In such an environment some of HomePNA-based network environment. In such an environment, some of
the network elements might be differently named. the network elements might be differently named.
7.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks 7.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks
There are three main design approaches to providing IPv4 connectivity There are three main design approaches to providing IPv4 connectivity
over an Ethernet infrastructure: over an Ethernet infrastructure:
A. Point-to-Point Model: Each subscriber connects to the network A. Point-to-Point Model: Each subscriber connects to the network
Access switch over RJ-45 or fiber links. Each subscriber is assigned Access switch over RJ-45 or fiber links. Each subscriber is
a unique VLAN on the access switch. The VLAN can be terminated at assigned a unique VLAN on the access switch. The VLAN can be
the BRAS or at the Edge Router. The VLANs are 802.1Q trunked to the terminated at the BRAS or at the Edge Router. The VLANs are
Layer 3 device (BRAS or Edge Router). 802.1Q trunked to the Layer 3 device (BRAS or Edge Router).
This model is presented in section 7.2.1. This model is presented in Section 7.2.1.
B. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened B. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened
between each subscriber and the BRAS. The BRAS terminates the PPP between each subscriber and the BRAS. The BRAS terminates the
sessions and provides Layer 3 connectivity between the subscriber and PPP sessions and provides Layer 3 connectivity between the
the ISP. subscriber and the ISP.
This model is presented in section 7.2.2. This model is presented in Section 7.2.2.
C. L2TPv2 Access Aggregation (LAA) Model: PPP sessions are opened C. L2TPv2 Access Aggregation (LAA) Model: PPP sessions are opened
between each subscriber and the ISP termination devices. The BRAS between each subscriber and the ISP termination devices. The
tunnels the subscriber PPP sessions to the ISP by encapsulating them BRAS tunnels the subscriber PPP sessions to the ISP by
into L2TPv2 tunnels. encapsulating them into L2TPv2 tunnels.
This model is presented in section 7.2.3. This model is presented in Section 7.2.3.
In aggregation models the BRAS terminates the subscriber VLANs and In aggregation models the BRAS terminates the subscriber VLANs and
aggregates their connections before providing access to the ISP. aggregates their connections before providing access to the ISP.
In order to maintain the deployment concepts and business models In order to maintain the deployment concepts and business models
proven and used with existing revenue generating IPv4 services, the proven and used with existing revenue generating IPv4 services, the
IPv6 deployment will match the IPv4 one. This approach is presented IPv6 deployment will match the IPv4 one. This approach is presented
in sections 7.2.1-3 that describe currently deployed IPv4 over in Sections 7.2.1 - 7.2.3 that describe currently deployed IPv4 over
Ethernet broadband access deployments. Under certain circumstances Ethernet broadband access deployments. Under certain circumstances
where new service types or service needs justify it, IPv4 and IPv6 where new service types or service needs justify it, IPv4 and IPv6
network architectures could be different as described in section network architectures could be different as described in Section
7.2.4. 7.2.4.
7.2.1. Point-to-Point Model 7.2.1. Point-to-Point Model
In this scenario the Ethernet frames from the Host or the Customer In this scenario, the Ethernet frames from the Host or the Customer
Premise Router are bridged over the VLAN assigned to the subscriber. Premise Router are bridged over the VLAN assigned to the subscriber.
Figure 7.2.1 describes the protocol architecture of this model. Figure 7.2.1 describes the protocol architecture of this model.
| Customer Premise | | NAP | NSP | | Customer Premise | | NAP | NSP |
+-----+ +------+ +------+ +--------+ +----------+ +-----+ +------+ +------+ +--------+ +----------+
|Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP |Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP
+-----+ +------+ |Switch| +--------+ 802.1Q | Router +=>Network +-----+ +------+ |Switch| +--------+ 802.1Q | Router +=>Network
+------+ +----------+ +------+ +----------+
|----------------------------| |----------------------------|
Ethernet/VLANs Ethernet/VLANs
Figure 7.2.1 Figure 7.2.1
7.2.1.1. IPv6 Related Infrastructure Changes 7.2.1.1. IPv6 Related Infrastructure Changes
In this scenario the Access Switch on the customer site and the 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 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, IPv6. The following devices have to be upgraded to dual stack: Host,
Customer Router and Edge Router. Customer Router, and Edge Router.
The Access switches might need upgrades to support certain IPv6 The Access switches might need upgrades to support certain IPv6-
related features such as MLD Snooping. related features such as MLD Snooping.
7.2.1.2. Addressing 7.2.1.2. Addressing
The Hosts or the Customer Routers have the Edge Router as their Layer 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 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 subscriber site belong to the same /64 subnet that is statically
configured on the Edge Router for that subscriber VLAN. The hosts configured on the Edge Router for that subscriber VLAN. The hosts
can use stateless auto-configuration or stateful DHCPv6 based can use stateless auto-configuration or stateful DHCPv6-based
configuration to acquire an address via the Edge Router. configuration to acquire an address via the Edge Router.
However, as manual configuration for each customer is a provisioning However, as manual configuration for each customer is a provisioning
challenge, implementations are encouraged to develop mechanism(s) challenge, implementations are encouraged to develop mechanism(s)
which automatically map the VLAN (or some other customer-specific that automatically map the VLAN (or some other customer-specific
information) to an IPv6 subnet prefix, and advertise the customer- information) to an IPv6 subnet prefix, and advertise the customer-
specific prefix to all the customers with minimal configuration. specific prefix to all the customers with minimal configuration.
If a Customer Router is present: If a Customer Router is present:
A. It is statically configured with an address on the /64 subnet A. It is statically configured with an address on the /64 subnet
between itself and the Edge Router, and with /64 prefixes on the between itself and the Edge Router, and with /64 prefixes on the
interfaces connecting the hosts on the customer site. This is not a interfaces connecting the hosts on the customer site. This is
desired provisioning method being expensive and difficult to manage. not a desired provisioning method, being expensive and difficult
to manage.
B. It can use its link-local address to communicate with the ER. It B. It can use its link-local address to communicate with the ER. It
can also dynamically acquire through stateless auto-configuration the can also dynamically acquire, through stateless auto-
address for the link between itself and the ER. This step is configuration, the address for the link between itself and the
followed by a request via DHCP-PD for a prefix shorter than /64 that ER. This step is followed by a request via DHCP-PD for a prefix
in turn is divided in /64s and assigned to its interfaces connecting shorter than /64 that in turn is divided in /64s and assigned to
the hosts on the customer site. its interfaces connecting the hosts on the customer site.
The Edge Router has a /64 prefix configured for each subscriber VLAN. The Edge Router has a /64 prefix configured for each subscriber VLAN.
Each VLAN should be enabled to relay DHCPv6 requests from the Each VLAN should be enabled to relay DHCPv6 requests from the
subscribers to DHCPv6 servers in the ISP network. The VLANs subscribers to DHCPv6 servers in the ISP network. The VLANs
providing access for subscribers that use DHCP-PD as well, have to be providing access for subscribers that use DHCP-PD have to be enabled
enabled to support the feature. The uplink to the ISP network is to support the feature. The uplink to the ISP network is configured
configured with a /64 prefix as well. with a /64 prefix as well.
The prefixes used for subscriber links and the ones delegated via The prefixes used for subscriber links and the ones delegated via
DHCP-PD should be planned in a manner that allows as much DHCP-PD should be planned in a manner that allows as much
summarization as possible at the Edge Router. summarization as possible at the Edge Router.
Other information of interest to the host, such as DNS, is provided Other information of interest to the host, such as DNS, is provided
through stateful [RFC3315] and stateless [RFC3736] DHCPv6. through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
7.2.1.3. Routing 7.2.1.3. Routing
The CPE devices are configured with a default route that points to The CPE devices are configured with a default route that points to
the Edge router. No routing protocols are needed on these devices the Edge Router. No routing protocols are needed on these devices,
which generally have limited resources. which generally have limited resources.
The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 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, The connected prefixes have to be redistributed. If DHCP-PD is used,
with every delegated prefix a static route is installed by the Edge with every delegated prefix a static route is installed by the Edge
Router. For this reason the static routes must also be Router. For this reason, the static routes must also be
redistributed. Prefix summarization should be done at the Edge redistributed. Prefix summarization should be done at the Edge
Router. Router.
7.2.2. PPP Terminated Aggregation (PTA) Model 7.2.2. PPP Terminated Aggregation (PTA) Model
The PTA architecture relies on PPP-based protocols (PPPoE). The PPP The PTA architecture relies on PPP-based protocols (PPPoE). The PPP
sessions are initiated by Customer Premise Equipment and it is sessions are initiated by Customer Premise Equipment and are
terminated at the BRAS. The BRAS authorizes the session, terminated at the BRAS. The BRAS authorizes the session,
authenticates the subscriber, and provides an IP address on behalf of authenticates the subscriber, and provides an IP address on behalf of
the ISP. The BRAS then does Layer 3 routing of the subscriber the ISP. The BRAS then does Layer 3 routing of the subscriber
traffic to the NSP Edge Router. traffic to the NSP Edge Router.
When the NSP is also the NAP, the BRAS and NSP Edge Router could be 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 the same piece of equipment and provide the above mentioned
functionality. functionality.
The PPPoE logical diagram in an Ethernet Broadband Network is shown The PPPoE logical diagram in an Ethernet Broadband Network is shown
skipping to change at page 45, line 40 skipping to change at page 47, line 17
+-----------+ +-----------+
| AAA | | AAA |
+-------+ Radius | +-------+ Radius |
| | TACACS | | | TACACS |
| +-----------+ | +-----------+
+-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C |Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O
|---------------- PPP ----------------| | | R |---------------- PPP ----------------| | | R
+-----------+ E +-----------+ E
Figure 7.2.2.1 Figure 7.2.2.1
The PPP sessions are initiated by the Customer Premise Equipment The PPP sessions are initiated by the Customer Premise Equipment
(Host or Router). The BRAS authenticates the subscriber against a (Host or Router). The BRAS authenticates the subscriber against a
local or a remote database. Once the session is established, the local or remote database. Once the session is established, the BRAS
BRAS provides an address and maybe a DNS server to the user, provides an address and maybe a DNS server to the user; this
information acquired from the subscriber profile or from a DHCP information is acquired from the subscriber profile or a DHCP server.
server.
This model allows for multiple PPPoE sessions to be supported over This model allows for multiple PPPoE sessions to be supported over
the same VLAN thus allowing the subscriber to connect to multiple the same VLAN, thus allowing the subscriber to connect to multiple
services at the same time. The hosts can initiate the PPPoE sessions services at the same time. The hosts can initiate the PPPoE sessions
as well. It is important to remember that the PPPoE encapsulation as well. It is important to remember that the PPPoE encapsulation
reduces the IP MTU available for the customer traffic. reduces the IP MTU available for the customer traffic.
7.2.2.1. IPv6 Related Infrastructure Changes 7.2.2.1. IPv6 Related Infrastructure Changes
In this scenario the BRAS is Layer 3 aware and it has to be upgraded In this scenario, the BRAS is Layer 3 aware and has to be upgraded to
to support IPv6. Since the BRAS terminates the PPP sessions it has support IPv6. Since the BRAS terminates the PPP sessions, it has to
to support PPPoE with IPv6. The following devices have to be support PPPoE with IPv6. The following devices have to be upgraded
upgraded to dual stack: Host, Customer Router (if present), BRAS and to dual stack: Host, Customer Router (if present), BRAS and Edge
Edge Router. Router.
7.2.2.2. Addressing 7.2.2.2. Addressing
The BRAS terminates the PPP sessions and provides the subscriber with The BRAS terminates the PPP sessions and provides the subscriber with
an IPv6 address from the defined pool for that profile. The an IPv6 address from the defined pool for that profile. The
subscriber profile for authorization and authentication can be subscriber profile for authorization and authentication can be
located on the BRAS or on a AAA server. The Hosts or the Customer located on the BRAS, or on an AAA server. The Hosts or the Customer
Routers have the BRAS as their Layer 3 next hop. Routers have the BRAS as their Layer 3 next hop.
The PPP session can be initiated by a host or by a Customer Router. The PPP session can be initiated by a host or by a Customer Router.
In the latter case, once the session is established with the BRAS, In the latter case, once the session is established with the BRAS,
DHCP-PD can be used to acquire prefixes for the Customer Router 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 interfaces. The BRAS has to be enabled to support DHCP-PD and to
relay the DHCPv6 requests of the hosts on the subscriber sites. relay the DHCPv6 requests of the hosts on the subscriber sites.
The BRAS has a /64 prefix configured on the link facing the Edge The BRAS has a /64 prefix configured on the link facing the Edge
router. The Edge router links are also configured with /64 prefixes router. The Edge Router links are also configured with /64 prefixes
to provide connectivity to the rest of the ISP network. to provide connectivity to the rest of the ISP network.
The prefixes used for subscriber and the ones delegated via DHCP-PD The prefixes used for subscribers and the ones delegated via DHCP-PD
should be planned in a manner that allows maximum summarization at should be planned in a manner that allows maximum summarization at
the BRAS. the BRAS.
Other information of interest to the host, such as DNS, is provided Other information of interest to the host, such as DNS, is provided
through stateful [RFC3315] and stateless [RFC3736] DHCPv6. through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
7.2.2.3. Routing 7.2.2.3. Routing
The CPE devices are configured with a default route that points to The CPE devices are configured with a default route that points to
the BRAS router. No routing protocols are needed on these devices the BRAS router. No routing protocols are needed on these devices,
which generally have limited resources. which generally have limited resources.
The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the 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 addresses assigned to the PPP sessions are represented as connected
host routes, connected prefixes have to be redistributed. If DHCP-PD host routes, connected prefixes have to be redistributed. If DHCP-PD
is used, with every delegated prefix a static route is installed by is used, with every delegated prefix a static route is installed by
the BRAS. For this reason the static routes must also be the BRAS. For this reason, the static routes must also be
redistributed. Prefix summarization should be done at the BRAS. redistributed. Prefix summarization should be done at the BRAS.
The Edge Router is running the IGP used in the ISP network: OSPFv3 or 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 IS-IS. A separation between the routing domains of the ISP and the
Access Provider is recommended if they are managed independently. Access Provider is recommended if they are managed independently.
Controlled redistribution will be needed between the Access Provider Controlled redistribution will be needed between the Access Provider
IGP and the ISP IGP. IGP and the ISP IGP.
7.2.3. L2TPv2 Access Aggregation (LAA) Model 7.2.3. L2TPv2 Access Aggregation (LAA) Model
In the LAA model the BRAS forwards the CPE initiated session to the 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 ISP over an L2TPv2 tunnel established between the BRAS and the Edge
Router. In this case the authentication, authorization and Router. In this case, the authentication, authorization, and
subscriber configuration are performed by the ISP itself. subscriber configuration are performed by the ISP itself.
| Customer Premise | | NAP | | NSP | | Customer Premise | | NAP | | NSP |
+-----------+ +-----------+
| AAA | | AAA |
+------+ Radius | +------+ Radius |
| | TACACS | | | TACACS |
| +-----+-----+ | +-----+-----+
| | | |
skipping to change at page 47, line 39 skipping to change at page 49, line 26
| | R | | R
+-----------+ E +-----------+ E
|-----------------------------------------------| |-----------------------------------------------|
PPP PPP
|--------------| |--------------|
L2TPv2 L2TPv2
Figure 7.2.3.1 Figure 7.2.3.1
7.2.3.1. IPv6 Related Infrastructure Changes 7.2.3.1. IPv6 Related Infrastructure Changes
In this scenario the BRAS is Layer 3 aware and it has to be upgraded In this scenario, the BRAS is Layer 3 aware and has to be upgraded to
to support IPv6. The PPP sessions initiated by the subscriber are support IPv6. The PPP sessions initiated by the subscriber are
forwarded over the L2TPv2 tunnel to the aggregation point in the ISP forwarded over the L2TPv2 tunnel to the aggregation point in the ISP
network. The BRAS (LAC) can aggregate IPv6 PPP sessions and tunnel network. The BRAS (LAC) can aggregate IPv6 PPP sessions and tunnel
them to the LNS using L2TPv2. The L2TPv2 tunnel between the LAC and 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 LNS could run over IPv6 or IPv4. These capabilities have to be
supported on the BRAS. The following devices have to be upgraded to supported on the BRAS. The following devices have to be upgraded to
dual stack: Host, Customer Router (if present), BRAS and Edge Router. dual stack: Host, Customer Router (if present), BRAS and Edge Router.
7.2.3.2. Addressing 7.2.3.2. Addressing
The Edge router terminates the PPP sessions and provides the The Edge Router terminates the PPP sessions and provides the
subscriber with an IPv6 address from the defined pool for that subscriber with an IPv6 address from the defined pool for that
profile. The subscriber profile for authorization and authentication profile. The subscriber profile for authorization and authentication
can be located on the Edge Router or on a AAA server. The Hosts or 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. the Customer Routers have the Edge Router as their Layer 3 next hop.
The PPP session can be initiated by a host or by a Customer Router. The PPP session can be initiated by a host or by a Customer Router.
In the latter case, once the session is established with the Edge 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 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 Edge Router, DHCP-PD can be used to acquire prefixes for the Customer
Router other interfaces. The Edge Router has to be enabled to 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 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 subscriber sites. The uplink to the ISP network is configured with a
/64 prefix as well. /64 prefix as well.
The BRAS has a /64 prefix configured on the link to the Edge router. 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 The Edge Router links are also configured with /64 prefixes to
provide connectivity to the rest of the ISP network. provide connectivity to the rest of the ISP network.
Other information of interest to the host, such as DNS, is provided Other information of interest to the host, such as DNS, is provided
through stateful [RFC3315] and stateless [RFC3736] DHCPv6. through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
The address assignment and prefix summarization issues discussed in The address assignment and prefix summarization issues discussed in
section 6.2.3.2 are relevant in the same way for this media access Section 6.2.3.2 are relevant in the same way for this media access
type as well. type as well.
7.2.3.3. Routing 7.2.3.3. Routing
The CPE devices are configured with a default route that points to The CPE devices are configured with a default route that points to
the Edge router that terminates the PPP sessions. No routing the Edge Router that terminates the PPP sessions. No routing
protocols are needed on these devices which have limited resources. protocols are needed on these devices, which have limited resources.
The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. 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 Different processes should be used if the NAP and the NSP are managed
by different organizations. In this case controlled redistribution by different organizations. In this case, controlled redistribution
should be enabled between the two domains. should be enabled between the two domains.
The Edge Router is running the IPv6 IGP used in the ISP network: The Edge Router is running the IPv6 IGP used in the ISP network:
OSPFv3 or IS-IS. OSPFv3 or IS-IS.
7.2.4. Hybrid Model for IPv4 and IPv6 Service 7.2.4. Hybrid Model for IPv4 and IPv6 Service
It was recommended throughout this section that the IPv6 service It was recommended throughout this section that the IPv6 service
implementation should map the existing IPv4 one. This approach implementation should map the existing IPv4 one. This approach
simplifies manageability and minimizes training needed for personnel simplifies manageability and minimizes training needed for personnel
operating the network. In certain circumstances such mapping is not operating the network. In certain circumstances, such mapping is not
feasible. This typically becomes the case when a Service Provider feasible. This typically becomes the case when a Service Provider
plans to expand its service offering with the new IPv6 deployed plans to expand its service offering with the new IPv6 deployed
infrastructure. If this new service is not well supported in a infrastructure. If this new service is not well supported in a
network design such as the one used for IPv4 then a different design network design such as the one used for IPv4, then a different design
might be used for IPv6. might be used for IPv6.
An example of such circumstances is that of a provider using an LAA 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 design for its IPv4 services. In this case, all the PPP sessions are
bundled and tunneled across the entire NAP infrastructure which is bundled and tunneled across the entire NAP infrastructure, which is
made of multiple BRAS routers, aggregation routers etc. The end made of multiple BRAS routers, aggregation routers, etc. The end
point of these tunnels is the ISP Edge Router. If the SP decides to 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 offer multicast services over such a design, it will face the problem
of NAP resources being over utilized. The multicast traffic can be 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 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. copies for all the subscribers are carried over the entire NAP.
A Modified Point-to-Point (see section 7.2.4.2) or a PTA model is 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 more suitable to support multicast services because the packet
replication can be done closer to the destination at the BRAS. Such replication can be done closer to the destination at the BRAS. Such
a topology saves NAP resources. a topology saves NAP resources.
In this sense IPv6 deployments can be viewed as an opportunity to In this sense, IPv6 deployments can be viewed as an opportunity to
build an infrastructure that can better support the expansion of build an infrastructure that can better support the expansion of
services. In this case, an SP using the LAA design for its IPv4 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 services might choose a modified Point-to-Point or PTA design for
IPv6. IPv6.
7.2.4.1. IPv4 in LAA Model and IPv6 in PTA Model 7.2.4.1. IPv4 in LAA Model and IPv6 in PTA Model
The coexistence of the two PPP based models, PTA and LAA, is The coexistence of the two PPP-based models, PTA and LAA, is
relatively straight forward. It is a straight forward overlap of the relatively straight forward. It is a straight forward overlap of the
two deployment models. The PPP sessions are terminated on different two deployment models. The PPP sessions are terminated on different
network devices for the IPv4 and IPv6 services. The PPP sessions for 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 existing IPv4 service deployed in an LAA model are terminated on
the Edge Router. The PPP sessions for the new IPv6 service deployed the Edge Router. The PPP sessions for the new IPv6 service deployed
in a PTA model are terminated on the BRAS. in a PTA model are terminated on the BRAS.
The logical design for IPv6 and IPv4 in this hybrid model is The logical design for IPv6 and IPv4 in this hybrid model is
presented in Figure 7.2.4.1. presented in Figure 7.2.4.1.
skipping to change at page 50, line 21 skipping to change at page 51, line 45
| | | |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+ +-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge | |Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core +-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+ +-----------+
IPv4 |----------------------------------------| IPv4 |----------------------------------------|
PPP PPP
|------------| |------------|
L2TPv2 L2TPv2
Figure 7.2.4.1 Figure 7.2.4.1
7.2.4.2. IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model 7.2.4.2. IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model
The coexistence of the modified Point-to-Point and the LAA models The coexistence of the modified Point-to-Point and the LAA models
implies a few specific changes. implies a few specific changes.
For the IPv4 service in LAA model, the VLANs are terminated on the 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 BRAS, and PPP sessions are terminated on the Edge Router (LNS). For
the IPv6 service in Point-to-Point model, the VLANs are terminated at the IPv6 service in the Point-to-Point model, the VLANs are
the Edge Router as described in section 6.2.1. In this hybrid model, terminated at the Edge Router as described in Section 6.2.1. In this
the Point-to-Point link could be terminated on the BRAS, a NAP owned hybrid model, the Point-to-Point link could be terminated on the
device. The IPv6 traffic is then routed through the NAP network to BRAS, a NAP-owned device. The IPv6 traffic is then routed through
the NSP. In order to have this hybrid model, the BRAS has to be the NAP network to the NSP. In order to have this hybrid model, the
upgraded to a dual-stack router. The functionalities of the Edge BRAS has to be upgraded to a dual-stack router. The functionalities
Router as described in section 6.2.1 are now implemented on the BRAS. of the Edge Router, as described in Section 6.2.1, are now
implemented on the BRAS.
The logical design for IPv6 and IPv4 in this hybrid model is in The logical design for IPv6 and IPv4 in this hybrid model is in
Figure 7.2.4.2. Figure 7.2.4.2.
IPv6 |----------------| IPv6 |----------------|
Ethernet Ethernet
+-----------+ +-----------+
| AAA | | AAA |
+-------+ Radius | +-------+ Radius |
| | TACACS | | | TACACS |
skipping to change at page 51, line 21 skipping to change at page 52, line 40
| +-----+-----+ | +-----+-----+
| | | |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+ +-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge | |Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core +-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+ +-----------+
IPv4 |----------------------------------------| IPv4 |----------------------------------------|
PPP PPP
|------------| |------------|
L2TPv2 L2TPv2
Figure 7.2.4.2 Figure 7.2.4.2
7.3. IPv6 Multicast 7.3. IPv6 Multicast
The typical multicast services offered for residential and very small The typical multicast services offered for residential and very small
businesses is video/audio streaming where the subscriber joins a businesses are video/audio streaming where the subscriber joins a
multicast group and receives the content. This type of service model multicast group and receives the content. This type of service model
is well supported through PIM-SSM which is very simple and easy to 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 manage. PIM-SSM has to be enabled throughout the ISP network. MLDv2
is required for PIM-SSM support. Vendors can choose to implement is required for PIM-SSM support. Vendors can choose to implement
features that allow routers to map MLDv1 group joins to predefined features that allow routers to map MLDv1 group joins to predefined
sources. sources.
Subscribers might use a set-top box that is responsible for the Subscribers might use a set-top box that is responsible for the
control piece of the multicast service (does group joins/leaves). control piece of the multicast service (does group joins/leaves).
The subscriber hosts can also join desired multicast groups as long The subscriber hosts can also join desired multicast groups as long
as they are enabled to support MLDv1 or MLDv2. If a customer premise as they are enabled to support MLDv1 or MLDv2. If a CPR is used,
router is used then it has to be enabled to support MLDv1 and MLDv2 then it has to be enabled to support MLDv1 and MLDv2 in order to
in order to process the requests of the hosts. It has to be enabled process the requests of the hosts. It has to be enabled to support
to support PIM-SSM in order to send PIM joins/leaves up to its Layer PIM-SSM in order to send PIM joins/leaves up to its Layer 3 next hop
3 next hop whether it is the BRAS or the Edge router. When enabling whether it is the BRAS or the Edge Router. When enabling this
this functionality on a customer premise router, its limited functionality on a CPR, its limited resources should be taken into
resources should be taken into consideration. Another option would consideration. Another option would be for the CPR to support MLD
be for the customer premise router to support MLD proxy routing. MLD proxy routing. MLD snooping or similar Layer 2 multicast-related
snooping or similar Layer 2 multicast related protocols could be protocols could be enabled on the NAP switches.
enabled on the NAP switches.
The router that is the Layer 3 next hop for the subscriber (BRAS in 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) 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 has to be enabled to support MLDv1 and MLDv2 in order to process the
requests coming from subscribers without customer premise routers. requests coming from subscribers without CPRs. It has to be enabled
It has to be enabled for PIM-SSM in order to receive joins/leaves for PIM-SSM in order to receive joins/leaves from customer routers
from customer routers and send joins/leaves to the next hop towards and send joins/leaves to the next hop towards the multicast source
the multicast source (Edge router or the NSP core). (Edge Router or the NSP core).
MLD authentication, authorization and accounting is usually MLD authentication, authorization, and accounting are usually
configured on the edge router in order to enable the ISP to do configured on the edge router in order to enable the ISP to control
control the subscriber access of the service and do billing for the the subscriber access of the service and do billing for the content
content provided. Alternative mechanisms that would support these provided. Alternative mechanisms that would support these functions
functions should be investigated further. should be investigated further.
Please refer to section 6.3 for more IPv6 multicast details. Please refer to section 6.3 for more IPv6 multicast details.
7.4. IPv6 QoS 7.4. IPv6 QoS
The QoS configuration is particularly relevant on the router that The QoS configuration is particularly relevant on the router that
represents the Layer 3 next hop for the subscriber (BRAS in the PTA 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 model or the Edge Router in the LAA and Point-to-Point model) in
order to manage resources shared amongst multiple subscribers order to manage resources shared amongst multiple subscribers,
possibly with various service level agreements. possibly with various service level agreements.
On the BRAS or the Edge Router the subscriber facing interfaces have On the BRAS or the Edge Router, the subscriber-facing interfaces have
to be configured to police the inbound customer traffic and shape the to be configured to police the inbound customer traffic and shape the
traffic outbound to the customer based on the SLAs. Traffic traffic outbound to the customer based on the SLAs. Traffic
classification and marking should also be done on the router closest classification and marking should also be done on the router closest
(at Layer 3) to the subscriber in order to support the various types (at Layer 3) to the subscriber in order to support the various types
of customer traffic: data, voice, video and to optimally use the of customer traffic: data, voice, video, and to optimally use the
network resources. This infrastructure offers a very good network resources. This infrastructure offers a very good
opportunity to leverage the QoS capabilities of Layer 2 devices. opportunity to leverage the QoS capabilities of Layer 2 devices.
DiffServ based QoS used for IPv4 should be expanded to IPv6. Diffserv-based QoS used for IPv4 should be expanded to IPv6.
Each provider (NAP, NSP) could implement their own QoS policies and Each provider (NAP, NSP) could implement their own QoS policies and
services so reclassification and marking might be performed at the services so that reclassification and marking might be performed at
boundary between the NAP and the NSP in order to make sure the 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 traffic is properly handled by the ISP. The same IPv4 QoS concepts
and methodologies should be applied for the IPv6 as well. and methodologies should be applied for the IPv6 as well.
It is important to note that when traffic is encrypted end-to-end, 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 the traversed network devices will not have access to many of the
packet fields used for classification purposes. In these cases packet fields used for classification purposes. In these cases,
routers will most likely place the packets in the default classes. routers will most likely place the packets in the default classes.
The QoS design should take into consideration this scenario and try The QoS design should take into consideration this scenario and try
to use mainly IP header fields for classification purposes. to use mainly IP header fields for classification purposes.
7.5. IPv6 Security Considerations 7.5. IPv6 Security Considerations
There are limited changes that have to be done for CPEs in order to There are limited changes that have to be done for CPEs in order to
enhance security. The Privacy extensions [RFC3041] for auto- enhance security. The privacy extensions [RFC3041] for auto-
configuration should be used by the hosts with the same configuration should be used by the hosts with the same
considerations for host traceability as discussed in section 6.5. considerations for host traceability as discussed in Section 6.5.
IPv6 firewall functions should be enabled on the hosts or Customer
IPv6 firewall functions should be enabled on the hosts or customer Premise Router, if present.
premise router if present.
The ISP provides security against attacks that come from its own The ISP provides security against attacks that come from its own
subscribers but it could also implement security services that subscribers, but it could also implement security services that
protect its subscribers from attacks sourced from the outside of its protect its subscribers from attacks sourced from outside its
network. Such services do not apply at the access level of the network. Such services do not apply at the access level of the
network discussed here. network discussed here.
If any Layer 2 filters for Ethertypes are in place, the NAP must If any Layer 2 filters for Ethertypes are in place, the NAP must
permit the IPv6 Ethertype (0X86DD). permit the IPv6 Ethertype (0X86DD).
The device that is the Layer 3 next hop for the subscribers (BRAS The device that is the Layer 3 next hop for the subscribers (BRAS
Edge router) should protect the network and the other subscribers Edge Router) should protect the network and the other subscribers
against attacks by one of the provider customers. For this reason against attacks by one of the provider customers. For this reason
uRPF and ACLs should be used on all interfaces facing subscribers. uRPF and ACLs should be used on all interfaces facing subscribers.
Filtering should be implemented with regard for the operational Filtering should be implemented with regard for the operational
requirements of IPv6 [Security considerations for IPv6]. requirements of IPv6 [IPv6-Security].
The BRAS and the Edge Router should protect their processing The BRAS and the Edge Router should protect their processing
resources against floods of valid customer control traffic such as: resources against floods of valid customer control traffic such as:
Router and Neighbor Solicitations, MLD Requests. Rate limiting Router and Neighbor Solicitations, and MLD Requests. Rate limiting
should be implemented on all subscriber facing interfaces. The should be implemented on all subscriber-facing interfaces. The
emphasis should be placed on multicast type traffic as it is most emphasis should be placed on multicast-type traffic, as it is most
often used by the IPv6 control plane. often used by the IPv6 control plane.
All other security features used with the IPv4 service should be All other security features used with the IPv4 service should be
similarly applied to IPv6 as well. similarly applied to IPv6 as well.
7.6. IPv6 Network Management 7.6. IPv6 Network Management
The necessary instrumentation (such as MIB modules, NetFlow Records The necessary instrumentation (such as MIB modules, NetFlow Records,
etc) should be available for IPv6. etc.) should be available for IPv6.
Usually, NSPs manage the edge routers by SNMP. The SNMP transport Usually, NSPs manage the edge routers by SNMP. The SNMP transport
can be done over IPv4 if all managed devices have connectivity over can be done over IPv4 if all managed devices have connectivity over
both IPv4 and IPv6. This would imply the smallest changes to the both IPv4 and IPv6. This would imply the smallest changes to the
existing network management practices and processes. Transport over existing network management practices and processes. Transport over
IPv6 could also be implemented and it might become necessary if IPv6 IPv6 could also be implemented and it might become necessary if IPv6
only islands are present in the network. The management applications only islands are present in the network. The management applications
may be running on hosts belonging to the NSP core network domain. may be running on hosts belonging to the NSP core network domain.
Network Management Applications should handle IPv6 in a similar Network Management Applications should handle IPv6 in a similar
fashion to IPv4 however they should also support features specific to fashion to IPv4; however, they should also support features specific
IPv6 such as Neighbor monitoring. to IPv6 such as neighbor monitoring.
In some cases service providers manage equipment located on customers In some cases, service providers manage equipment located on
LANs. customers' LANs.
8. Wireless LAN 8. Wireless LAN
This section provides a detailed description of IPv6 deployment and This section provides a detailed description of IPv6 deployment and
integration methods in currently deployed wireless LAN (WLAN) integration methods in currently deployed wireless LAN (WLAN)
infrastructure. infrastructure.
8.1. WLAN Deployment Scenarios 8.1. WLAN Deployment Scenarios
WLAN enables subscribers to connect to the Internet from various WLAN enables subscribers to connect to the Internet from various
skipping to change at page 54, line 32 skipping to change at page 55, line 51
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | |Access Router/| | Provider | |Edge | |WLAN | ---- | | |Access Router/| | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network |Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
| |
+------+ +------+
|AAA | |AAA |
|Server| |Server|
+------+ +------+
Figure 8.1
The host should have a wireless network interface card (NIC) in order Figure 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 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 works in a similar fashion as Ethernet. When a host initiates a
connection, it is authenticated by the AAA server located at the SP connection, it is authenticated by the AAA server located at the SP
network. All the authentication parameters (username, password and network. All the authentication parameters (username, password,
etc.) are forwarded by the Access Point (AP) to the AAA server. The etc.) are forwarded by the Access Point (AP) to the AAA server. The
AAA server authenticates the host, once successfully authenticated AAA server authenticates the host; once successfully authenticated,
the host can send data packets. The AP is located near the host and 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 acts as a bridge. The AP forwards all the packets coming to/from
host to the Edge Router. The underlying connection between the AP host to the Edge Router. The underlying connection between the AP
and Edge Router could be based on any access layer technology such as and Edge Router could be based on any access layer technology such as
HFC/Cable, FTTH, xDSL or etc. HFC/Cable, FTTH, xDSL, etc.
WLANs operate within limited areas known as WiFi Hot Spots. While 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 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 connected to the Internet given they have a wireless NIC and required
configuration settings in their devices (notebook PCs, PDA or etc.). configuration settings in their devices (notebook PCs, PDAs, etc.).
Once the user initiates the connection the IP address is assigned by Once the user initiates the connection, the IP address is assigned by
the SP using DHCPv4. In most of the cases SP assigns limited number the SP using DHCPv4. In most of the cases, SP assigns a limited
of public IP addresses to the its customer. When the user number of public IP addresses to its customers. When the user
disconnects the connection and moves to a new WiFi hot spot, the disconnects the connection and moves to a new WiFi hot spot, the
above mentioned process of authentication, address assignment and above-mentioned process of authentication, address assignment, and
accessing the Internet is repeated. accessing the Internet is repeated.
There are IPv4 deployments where customers can use WLAN routers to There are IPv4 deployments where customers can use WLAN routers to
connect over wireless to their service provider. These deployment connect over wireless to their service provider. These deployment
types do not fit in the typical Hot Spot concept but they rather types do not fit in the typical Hot Spot concept, but rather they
serve fixed customers. For this reason this section discusses the serve fixed customers. For this reason, this section discusses the
WLAN router options as well. In this case, the ISP provides a public WLAN router options as well. In this case, the ISP provides a public
IP address and the WLAN Router assigns private addresses [RFC1918] to IP address and the WLAN Router assigns private addresses [RFC1918] to
all WLAN users. The WLAN Router provides NAT functionality while all WLAN users. The WLAN Router provides NAT functionality while
WLAN users access the Internet. WLAN users access the Internet.
While deploying IPv6 in the above mentioned WLAN architecture, there While deploying IPv6 in the above-mentioned WLAN architecture, there
are three possible scenarios as discussed below. are three possible scenarios as discussed below.
A. Layer 2 NAP with Layer 3 termination at NSP Edge Router A. Layer 2 NAP with Layer 3 termination at NSP Edge Router
B. Layer 3 aware NAP with Layer 3 termination at Access Router B. Layer 3 aware NAP with Layer 3 termination at Access Router
C. PPP Based Model C. PPP-Based Model
8.1.1. Layer 2 NAP with Layer 3 termination at NSP Edge Router 8.1.1. Layer 2 NAP with Layer 3 termination at NSP Edge Router
When a Layer 2 switch is present between AP and Edge Router, the AP 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 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. IPv6 packets from WLAN Host/Router to Edge Router and vice versa.
When initiating the connection, the WLAN host is authenticated by the When initiating the connection, the WLAN Host is authenticated by the
AAA server located at the SP network. All the parameters related to AAA server located at the SP network. All the parameters related to
authentication (username, password and etc.) are forwarded by the AP authentication (username, password, etc.) are forwarded by the AP to
to the AAA server. The AAA server authenticates the WLAN Hosts and the AAA server. The AAA server authenticates the WLAN Hosts, and
once authenticated and associated successfully with WLAN AP, an IPv6 once the WLAN Host is authenticated and associated successfully with
address will be acquired by the WLAN Host. Note the initiation and the WLAN AP, it acquires an IPv6 address. Note that the initiation
authentication process is same as used in IPv4. and authentication process is the same as used in IPv4.
Figure 8.1.1 describes the WLAN architecture when a Layer 2 Switch is Figure 8.1.1 describes the WLAN architecture when a Layer 2 Switch is
located between AP and Edge Router. located between AP and Edge Router.
Customer | Access Provider | Service Provider Customer | Access Provider | Service Provider
Premise | | Premise | |
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge | |WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP
skipping to change at page 56, line 18 skipping to change at page 57, line 29
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge | |WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network |Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
| |
+------+ +------+
|AAA | |AAA |
|Server| |Server|
+------+ +------+
Figure 8.1.1 Figure 8.1.1
8.1.1.1. IPv6 Related Infrastructure Changes 8.1.1.1. IPv6 Related Infrastructure Changes
IPv6 will be deployed in this scenario by upgrading the following IPv6 will be deployed in this scenario by upgrading the following
devices to dual-stack: WLAN Host, WLAN Router (if present) and Edge devices to dual stack: WLAN Host, WLAN Router (if present), and Edge
Router. Router.
8.1.1.2. Addressing 8.1.1.2. Addressing
When customer WLAN Router is not present, the WLAN Host has two When a customer WLAN Router is not present, the WLAN Host has two
possible options to get an IPv6 address via the Edge Router. possible options to get an IPv6 address via the Edge Router.
A. The WLAN host can get the IPv6 address from Edge router using A. The WLAN Host can get the IPv6 address from an Edge Router using
stateless auto-configuration [RFC2462]. All hosts on the WLAN belong stateless auto-configuration [RFC2462]. All hosts on the WLAN
to the same /64 subnet that is statically configured on the Edge belong to the same /64 subnet that is statically configured on
Router. The IPv6 WLAN Host may use stateless DHCPv6 for obtaining the Edge Router. The IPv6 WLAN Host may use stateless DHCPv6 for
other information of interest such as DNS and etc. obtaining other information of interest such as DNS, etc.
B. IPv6 WLAN host can use DHCPv6 [RFC3315] to get a IPv6 address from B. The IPv6 WLAN Host can use DHCPv6 [RFC3315] to get an IPv6
the DHCPv6 server. In this case the DHCPv6 server would be located address from the DHCPv6 server. In this case, the DHCPv6 server
in the SP core network and Edge Router would simply act as a DHCP would be located in the SP core network, and the Edge Router
Relay Agent. This option is similar to what is done today in case of would simply act as a DHCP Relay Agent. This option is similar
DHCPv4. It is important to note that host implementation of stateful to what is done today in case of DHCPv4. It is important to note
auto-configuration is rather limited at this time and this should be that host implementation of stateful auto-configuration is rather
considered if choosing this address assignment option. limited at this time, and this should be considered if choosing
this address assignment option.
When a customer WLAN Router is present, the WLAN Host has two When a customer WLAN Router is present, the WLAN Host has two
possible options as well for acquiring IPv6 address. possible options as well for acquiring IPv6 address.
A. The WLAN Router may be assigned a prefix between /48 and /64 A. The WLAN Router may be assigned a prefix between /48 and /64
[RFC3177] depending on the SP policy and customer requirements. If [RFC3177] depending on the SP policy and customer requirements.
the WLAN Router has multiple networks connected to its interfaces, If the WLAN Router has multiple networks connected to its
the network administrator will have to configure the /64 prefixes to interfaces, the network administrator will have to configure the
the WLAN Router interfaces connecting the WLAN Hosts on the customer /64 prefixes to the WLAN Router interfaces connecting the WLAN
site. The WLAN Hosts connected to these interfaces can automatically Hosts on the customer site. The WLAN Hosts connected to these
configure themselves using stateless auto-configuration. interfaces can automatically configure themselves using stateless
auto-configuration.
B. The WLAN Router can use its link-local address to communicate with B. The WLAN Router can use its link-local address to communicate
the ER. It can also dynamically acquire through stateless auto- with the ER. It can also dynamically acquire through stateless
configuration the address for the link between itself and the ER. auto-configuration the address for the link between itself and
This step is followed by a request via DHCP-PD for a prefix shorter the ER. This step is followed by a request via DHCP-PD for a
than /64 that in turn is divided in /64s and assigned to its prefix shorter than /64 that, in turn, is divided in /64s and
interfaces connecting the hosts on the customer site. assigned to its interfaces connecting the hosts on the customer
site.
In this option, the WLAN Router would act as a requesting router and In this option, the WLAN Router would act as a requesting router and
Edge Router would act as delegating router. Once prefix is received the Edge Router would act as a delegating router. Once the prefix is
by the WLAN Router, it assigns /64 prefixes to each of its interfaces received by the WLAN Router, it assigns /64 prefixes to each of its
connecting the WLAN Hosts on the customer site. The WLAN Hosts interfaces connecting the WLAN Hosts on the customer site. The WLAN
connected to these interfaces can automatically configure themselves Hosts connected to these interfaces can automatically configure
using stateless auto-configuration. The uplink to the ISP network is themselves using stateless auto-configuration. The uplink to the ISP
configured with a /64 prefix as well. network is configured with a /64 prefix as well.
Usually it is easier for the SPs to stay with the DHCP-PD and 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 stateless auto-configuration model and point the clients to a central
server for DNS/domain information, proxy configurations and etc. server for DNS/domain information, proxy configurations, etc. Using
Using this model the SP could change prefixes on the fly and the WLAN this model, the SP could change prefixes on the fly, and the WLAN
Router would simply pull the newest prefix based on the valid/ Router would simply pull the newest prefix based on the valid/
preferred lifetime. preferred lifetime.
The prefixes used for subscriber links and the ones delegated via The prefixes used for subscriber links and the ones delegated via
DHCP-PD should be planned in a manner that allows maximum DHCP-PD should be planned in a manner that allows maximum
summarization as possible at the Edge Router. summarization at the Edge Router.
Other information of interest to the host, such as DNS, is provided Other information of interest to the host, such as DNS, is provided
through stateful [RFC3315] and stateless [RFC3736] DHCPv6. through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
8.1.1.3. Routing 8.1.1.3. Routing
The WLAN Host/Router are configured with a default route that points The WLAN Host/Router is configured with a default route that points
to the Edge router. No routing protocols are needed on these devices to the Edge Router. No routing protocols are needed on these
which generally have limited resources. devices, which generally have limited resources.
The Edge Router runs the IGP used in the SP network such as OSPFv3 or 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. IS-IS for IPv6. The connected prefixes have to be redistributed.
Prefix summarization should be done at the Edge Router. When DHCP-PD Prefix summarization should be done at the Edge Router. When DHCP-PD
is used, the IGP has to redistribute the static routes installed is used, the IGP has to redistribute the static routes installed
during the process of prefix delegation. during the process of prefix delegation.
8.1.2. Layer 3 aware NAP with Layer 3 termination at Access Router 8.1.2. Layer 3 Aware NAP with Layer 3 Termination at Access Router
When an Access Router is present between AP and Edge Router, the AP When an Access Router is present between the AP and Edge Router, the
continues to work as a bridge, bridging IPv4 and IPv6 packets from 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 WLAN Host/Router to Access Router and vice versa. The Access Router
could be part of SP network or owned by a separate Access Provider. could be part of the SP network or owned by a separate Access
Provider.
When WLAN Host initiates the connection, the AAA authentication and When the WLAN Host initiates the connection, the AAA authentication
association process with WLAN AP will be similar as explained in and association process with WLAN AP will be similar, as explained in
section 8.1.1. Section 8.1.1.
Figure 8.1.2 describes the WLAN architecture when Access Router is Figure 8.1.2 describes the WLAN architecture when the Access Router
located between AP and Edge Router. is located between the AP and Edge Router.
Customer | Access Provider | Service Provider Customer | Access Provider | Service Provider
Premise | | Premise | |
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge | |WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP |Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network |Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
| |
skipping to change at page 58, line 27 skipping to change at page 59, line 45
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge | |WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP |Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network |Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
| |
+------+ +------+
|AAA | |AAA |
|Server| |Server|
+------+ +------+
Figure 8.1.2 Figure 8.1.2
8.1.2.1. IPv6 Related Infrastructure Changes 8.1.2.1. IPv6 Related Infrastructure Changes
IPv6 is deployed in this scenario by upgrading the following devices IPv6 is deployed in this scenario by upgrading the following devices
to dual-stack: WLAN Host, WLAN Router (if present), Access Router and to dual stack: WLAN Host, WLAN Router (if present), Access Router,
Edge Router. and Edge Router.
8.1.2.2. Addressing 8.1.2.2. Addressing
There are three possible options in this scenario for IPv6 address There are three possible options in this scenario for IPv6 address
assignment: assignment:
A. The Edge Router interface facing towards the Access Router is A. The Edge Router interface facing towards the Access Router is
statically configured with /64 prefix. The Access Router receives/ statically configured with a /64 prefix. The Access Router
configures an /64 prefix on its interface facing towards Edge Router receives/ configures a /64 prefix on its interface facing towards
through stateless auto-configuration. The network administrator will the Edge Router through stateless auto-configuration. The
have to configure the /64 prefixes to the Access Router interface network administrator will have to configure the /64 prefixes to
facing towards the customer premise. The WLAN Host/Router connected the Access Router interface facing toward the customer premise.
to this interface can automatically configure themselves using The WLAN Host/Router connected to this interface can
stateless auto-configuration. automatically configure itself using stateless auto-
configuration.
B. This option uses DHCPv6 [RFC3315] for IPv6 prefix assignments to 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- the WLAN Host/Router. There is no use of DHCP PD or stateless
configuration in this option. The DHCPv6 server can be located on auto-configuration in this option. The DHCPv6 server can be
the Access Router, on the Edge Router or somewhere in the SP network. located on the Access Router, the Edge Router, or somewhere in
In this case depending on where the DHCPv6 server is located, Access the SP network. In this case, depending on where the DHCPv6
Router or the Edge Router would relay the DHCPv6 requests. server is located, the Access Router or the Edge Router would
relay the DHCPv6 requests.
C. It can use its link-local address to communicate with the ER. It C. It can use its link-local address to communicate with the ER. It
can also dynamically acquire through stateless auto-configuration the can also dynamically acquire through stateless auto-configuration
address for the link between itself and the ER. This step is 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 followed by a request via DHCP-PD for a prefix shorter than /64
in turn is divided in /64s and assigned to its interfaces connecting that, in turn, is divided in /64s and assigned to its interfaces
the hosts on the customer site. connecting the hosts on the customer site.
In this option, the Access Router would act as a requesting router In this option, the Access Router would act as a requesting
and Edge Router would act as delegating router. Once prefix is router, and the Edge Router would act as a delegating router.
received by the Access Router, it assigns /64 prefixes to each of its Once the prefix is received by the Access Router, it assigns /64
interfaces connecting the WLAN Host/Router on customer site. The prefixes to each of its interfaces connecting the WLAN Host/
WLAN Host/Router connected to these interfaces can automatically Router on the customer site. The WLAN Host/Router connected to
configure themselves using stateless auto-configuration. The uplink these interfaces can automatically configure itself using
to the ISP network is configured with a /64 prefix as well. stateless auto-configuration. The uplink to the ISP network is
configured with a /64 prefix as well.
It is easier for the SPs to stay with the DHCP PD and stateless auto- 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 configuration model and point the clients to a central server for
DNS/domain information, proxy configurations and others. Using this DNS/domain information, proxy configurations, and others. Using this
model the provider could change prefixes on the fly and the Access model, the provider could change prefixes on the fly, and the Access
Router would simply pull the newest prefix based on the valid/ Router would simply pull the newest prefix based on the valid/
preferred lifetime. preferred lifetime.
As mentioned before the prefixes used for subscriber links and the As mentioned before, the prefixes used for subscriber links and the
ones delegated via DHCP-PD should be planned in a manner that allows ones delegated via DHCP-PD should be planned in a manner that allows
maximum summarization possible at the Edge Router. Other information the maximum summarization possible at the Edge Router. Other
of interest to the host, such as DNS, is provided through stateful information of interest to the host, such as DNS, is provided through
[RFC3315] and stateless [RFC3736] DHCPv6. stateful [RFC3315] and stateless [RFC3736] DHCPv6.
8.1.2.3. Routing 8.1.2.3. Routing
The WLAN Host/Router are configured with a default route that points The WLAN Host/Router is configured with a default route that points
to the Access Router. No routing protocols are needed on these to the Access Router. No routing protocols are needed on these
devices which generally have limited resources. devices, which generally have limited resources.
If the Access Router is owned by an Access Provider, then the Access 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. 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 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 IS-IS for IPv6. The connected prefixes have to be redistributed. If
DHCP-PD is used, with every delegated prefix a static route is DHCP-PD is used, with every delegated prefix a static route is
installed by the Edge Router. For this reason the static routes must installed by the Edge Router. For this reason the static routes must
be redistributed. Prefix summarization should be done at the Edge be redistributed. Prefix summarization should be done at the Edge
Router. Router.
If the Access Router is owned by the SP, then Access Router will also If the Access Router is owned by the SP, then the Access Router will
run IPv6 IGP and will be part of SP IPv6 routing domain (OSPFv3 or also run IPv6 IGP, and will be part of the SP IPv6 routing domain
IS-IS). The connected prefixes have to be redistributed. If DHCP-PD (OSPFv3 or IS-IS). The connected prefixes have to be redistributed.
is used, with every delegated prefix a static route is installed by If DHCP-PD is used, with every delegated prefix a static route is
the Access Router. For this reason the static routes must be installed by the Access Router. For this reason, the static routes
redistributed. Prefix summarization should be done at the Access must be redistributed. Prefix summarization should be done at the
Router. Access Router.
8.1.3. PPP Based Model 8.1.3. PPP-Based Model
PPP Terminated Aggregation (PTA) and L2TPv2 Access Aggregation (LAA) PPP Terminated Aggregation (PTA) and L2TPv2 Access Aggregation (LAA)
models as discussed in sections 6.2.2 and 6.2.3 respectively can also models, as discussed in Sections 6.2.2 and 6.2.3, respectively, can
be deployed in IPv6 WLAN environment. also be deployed in IPv6 WLAN environment.
8.1.3.1. PTA Model in IPv6 WLAN Environment 8.1.3.1. PTA Model in IPv6 WLAN Environment
While deploying the PTA model in IPv6 WLAN environment the Access 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. Router is Layer 3 aware and it has to be upgraded to support IPv6.
Since the Access Router terminates the PPP sessions initiated by WLAN Since the Access Router terminates the PPP sessions initiated by the
Host/Router, it has to support PPPoE with IPv6. WLAN Host/Router, it has to support PPPoE with IPv6.
Figure 8.1.3.1 describes the PTA Model in IPv6 WLAN environment. Figure 8.1.3.1 describes the PTA Model in IPv6 WLAN environment.
Customer | Access Provider | Service Provider Customer | Access Provider | Service Provider
Premise | | Premise | |
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge | |WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP |Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network |Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
skipping to change at page 60, line 38 skipping to change at page 62, line 17
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge | |WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP |Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network |Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
| |
|---------------------------| +------+ |---------------------------| +------+
PPP |AAA | PPP |AAA |
|Server| |Server|
+------+ +------+
Figure 8.1.3.1 Figure 8.1.3.1
8.1.3.1.1. IPv6 Related Infrastructure Changes 8.1.3.1.1. IPv6 Related Infrastructure Changes
IPv6 is deployed in this scenario by upgrading the following devices IPv6 is deployed in this scenario by upgrading the following devices
to dual-stack: WLAN Host, WLAN Router (if present), Access Router and to dual stack: WLAN Host, WLAN Router (if present), Access Router,
Edge Router. and Edge Router.
8.1.3.1.2. Addressing 8.1.3.1.2. Addressing
The addressing techniques described in section 6.2.2.2 apply to the The addressing techniques described in Section 6.2.2.2 apply to the
IPv6 WLAN PTA scenario as well. IPv6 WLAN PTA scenario as well.
8.1.3.1.3. Routing 8.1.3.1.3. Routing
The routing techniques described in section 6.2.2.3 apply to the IPv6 The routing techniques described in Section 6.2.2.3 apply to the IPv6
WLAN PTA scenario as well. WLAN PTA scenario as well.
8.1.3.2. LAA Model in IPv6 WLAN Environment 8.1.3.2. LAA Model in IPv6 WLAN Environment
While deploying the LAA model in IPv6 WLAN environment the Access While deploying the LAA model in IPv6 WLAN environment, the Access
Router is Layer 3 aware and it has to be upgraded to support IPv6. Router is Layer 3 aware and has to be upgraded to support IPv6. The
The PPP sessions initiated by WLAN Host/Router are forwarded over 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 L2TPv2 tunnel to the aggregation point in the SP network. The Access
Router must have the capability to support L2TPv2 for IPv6. Router must have the capability to support L2TPv2 for IPv6.
Figure 8.1.3.2 describes the LAA Model in IPv6 WLAN environment Figure 8.1.3.2 describes the LAA Model in IPv6 WLAN environment.
Customer | Access Provider | Service Provider Customer | Access Provider | Service Provider
Premise | | Premise | |
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | | Provider | |Edge | |WLAN | ---- | | | | | Provider | |Edge |
|Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP |Host/ |-(WLAN)--|AP|-|Access Router |-| Network |-|Router|=>SP
|Router| ---- | | | | | | | |Network |Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
| |
skipping to change at page 61, line 37 skipping to change at page 63, line 22
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
| |
|-------------------------------------------------- | |-------------------------------------------------- |
PPP | PPP |
|--------------------- | |--------------------- |
L2TPv2 | L2TPv2 |
+------+ +------+
|AAA | |AAA |
|Server| |Server|
+------+ +------+
Figure 8.1.3.2 Figure 8.1.3.2
8.1.3.2.1. IPv6 Related Infrastructure Changes 8.1.3.2.1. IPv6 Related Infrastructure Changes
IPv6 is deployed in this scenario by upgrading the following devices IPv6 is deployed in this scenario by upgrading the following devices
to dual-stack: WLAN Host, WLAN Router (if present), Access Router and to dual stack: WLAN Host, WLAN Router (if present), Access Router,
Edge Router. and Edge Router.
8.1.3.2.2. Addressing 8.1.3.2.2. Addressing
The addressing techniques described in section 6.2.3.2 apply to the The addressing techniques described in Section 6.2.3.2 apply to the
IPv6 WLAN LAA scenario as well. IPv6 WLAN LAA scenario as well.
8.1.3.2.3. Routing 8.1.3.2.3. Routing
The routing techniques described in section 6.2.3.3 apply to the IPv6 The routing techniques described in Section 6.2.3.3 apply to the IPv6
WLAN LAA scenario as well. WLAN LAA scenario as well.
8.2. IPv6 Multicast 8.2. IPv6 Multicast
The typical multicast services offered are video/audio streaming The typical multicast services offered are video/audio streaming
where the IPv6 WLAN Host joins a multicast group and receives the where the IPv6 WLAN Host joins a multicast group and receives the
content. This type of service model is well supported through PIM- content. This type of service model is well supported through PIM-
SSM which is enabled throughout the SP network. MLDv2 is required SSM, which is enabled throughout the SP network. MLDv2 is required
for PIM-SSM support. Vendors can choose to implement features that for PIM-SSM support. Vendors can choose to implement features that
allow routers to map MLDv1 group joins to predefined sources. allow routers to map MLDv1 group joins to predefined sources.
It is important to note that in the shared wireless environments It is important to note that in the shared wireless environments,
multicast can have a significant bandwidth impact. For this reason multicast can have a significant bandwidth impact. For this reason,
the bandwidth allocated to multicast traffic should be limited and the bandwidth allocated to multicast traffic should be limited and
fixed based on the overall capacity of the wireless specification fixed, based on the overall capacity of the wireless specification
used 802.11a, 802.11b or 802.11g. used in 802.11a, 802.11b, or 802.11g.
The IPv6 WLAN Hosts can also join desired multicast groups as long as The IPv6 WLAN Hosts can also join desired multicast groups as long as
they are enabled to support MLDv1 or MLDv2. If a WLAN/Access Routers 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 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/ order to process the requests of the IPv6 WLAN Hosts. The WLAN/
Access Router should also needs to be enabled to support PIM-SSM in Access Router also needs to be enabled to support PIM-SSM in order to
order to send PIM joins up to the Edge Router. When enabling this send PIM joins up to the Edge Router. When enabling this
functionality on a WLAN/Access Router, its limited resources should functionality on a WLAN/Access Router, its limited resources should
be taken into consideration. Another option would be for the WLAN/ be taken into consideration. Another option would be for the WLAN/
Access Router to support MLD proxy routing. Access Router to support MLD proxy routing.
The Edge Router has to be enabled to support MLDv1 and MLDv2 in order The Edge Router has to be enabled to support MLDv1 and MLDv2 in order
to process the requests coming from IPv6 WLAN Host or WLAN/Access 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 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/ 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. Access Router (if present), and send joins towards the SP core.
MLD authentication, authorization and accounting is usually MLD authentication, authorization, and accounting are usually
configured on the Edge Router in order to enable the SP to do billing configured on the Edge Router in order to enable the SP to do billing
for the content services provided. Further investigation should be for the content services provided. Further investigation should be
made in finding alternative mechanisms that would support these made in finding alternative mechanisms that would support these
functions. functions.
Concerns have been raised in the past related to running IPv6 Concerns have been raised in the past related to running IPv6
multicast over WLAN links. Potentially these are same kind of issues multicast over WLAN links. Potentially these are the same kind of
when running any Layer 3 protocol over a WLAN link that has a high issues when running any Layer 3 protocol over a WLAN link that has a
loss-to-signal ratio, where certain frames that are multicast based high loss-to-signal ratio, where certain frames that are multicast
are dropped when settings are not adjusted properly. For instance based are dropped when settings are not adjusted properly. For
this behavior is similar to IGMP host membership report, when done on instance, this behavior is similar to an IGMP host membership report,
a WLAN link with high loss-to-signal ratio and high interference. when done on a WLAN link with a high loss-to-signal ratio and high
interference.
This problem is inherited to WLAN that can impact both IPv4 and IPv6 This problem is inherited by WLAN that can impact both IPv4 and IPv6
multicast packets and not specific to IPv6 multicast. multicast packets; it is not specific to IPv6 multicast.
While deploying WLAN (IPv4 or IPv6), one should adjust their While deploying WLAN (IPv4 or IPv6), one should adjust their
broadcast/multicast settings if they are in danger of dropping broadcast/multicast settings if they are in danger of dropping
application dependent frames. These problems are usually caused when application dependent frames. These problems are usually caused when
AP are placed too far apart (not following the distance limitations), the AP is placed too far (not following the distance limitations),
high interference and etc. These issues may impact a real multicast high interference, etc. These issues may impact a real multicast
application such as streaming video or basic operation of IPv6 if the application such as streaming video or basic operation of IPv6 if the
frames were dropped. Basic IPv6 communications uses functions such frames were dropped. Basic IPv6 communications uses functions such
as Duplicate Address Detection (DAD), Router and Neighbor as Duplicate Address Detection (DAD), Router and Neighbor
Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA) Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA),
and etc. which could be impacted by the above mentioned issues as etc., which could be impacted by the above mentioned issues as these
these frames are Layer 2 Ethernet multicast frames. frames are Layer 2 Ethernet multicast frames.
Please refer to section 6.3 for more IPv6 multicast details. Please refer to Section 6.3 for more IPv6 multicast details.
8.3. IPv6 QoS 8.3. IPv6 QoS
Today, QoS is done outside of the WiFi domain but it is nevertheless Today, QoS is done outside of the WiFi domain, but it is nevertheless
important to the overall deployment. important to the overall deployment.
The QoS configuration is particularly relevant on the Edge Router in The QoS configuration is particularly relevant on the Edge Router in
order to manage resources shared amongst multiple subscribers order to manage resources shared amongst multiple subscribers
possibly with various service level agreements (SLA). Although, the possibly with various service level agreements (SLAs). However, the
WLAN Host/Router and Access Router could also be configured for QoS. WLAN Host/Router and Access Router could also be configured for QoS.
This includes support for appropriate classification criteria which This includes support for appropriate classification criteria, which
would need to be implemented for IPv6 unicast and multicast traffic. would need to be implemented for IPv6 unicast and multicast traffic.
On the Edge Router the subscriber facing interfaces have to be On the Edge Router, the subscriber-facing interfaces have to be
configured to police the inbound customer traffic and shape the configured to police the inbound customer traffic and shape the
traffic outbound to the customer, based on the SLA. Traffic traffic outbound to the customer, based on the SLA. Traffic
classification and marking should also be done on the Edge router in classification and marking should also be done on the Edge Router in
order to support the various types of customer traffic: data, voice, order to support the various types of customer traffic: data, voice,
video. The same IPv4 QoS concepts and methodologies should be and video. The same IPv4 QoS concepts and methodologies should be
applied for the IPv6 as well. applied for the IPv6 as well.
It is important to note that when traffic is encrypted end-to-end, 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 the traversed network devices will not have access to many of the
packet fields used for classification purposes. In these cases packet fields used for classification purposes. In these cases,
routers will most likely place the packets in the default classes. routers will most likely place the packets in the default classes.
The QoS design should take into consideration this scenario and try The QoS design should take into consideration this scenario and try
to use mainly IP header fields for classification purposes. to use mainly IP header fields for classification purposes.
8.4. IPv6 Security Considerations 8.4. IPv6 Security Considerations
There are limited changes that have to be done for WLAN Host/Router There are limited changes that have to be done for WLAN the Host/
in order to enhance security. The Privacy extensions [RFC3041] for Router in order to enhance security. The privacy extensions
auto-configuration should be used by the hosts with the same [RFC3041] for auto-configuration should be used by the hosts with the
consideration for host traceability as described in section 6.5. same consideration for host traceability as described in Section 6.5.
IPv6 firewall functions should be enabled on the WLAN Host/Router if IPv6 firewall functions should be enabled on the WLAN Host/Router, if
present. present.
The ISP provides security against attacks that come from its own The ISP provides security against attacks that come from its own
subscribers but it could also implement security services that subscribers, but it could also implement security services that
protect its subscribers from attacks sourced from the outside of its protect its subscribers from attacks sourced from outside its
network. Such services do not apply at the access level of the network. Such services do not apply at the access level of the
network discussed here. network discussed here.
If the host authentication at hot spots is done using web based If the host authentication at hotspots is done using a web-based
authentication system then the level of security would depend on the authentication system, then the level of security would depend on the
particular implementation. User credential should never be sent as particular implementation. User credentials should never be sent as
clear text via HTTP. Secure HTTP (HTTPS) should be used between the clear text via HTTP. Secure HTTP (HTTPS) should be used between the
web browser and authentication server. The authentication server web browser and authentication server. The authentication server
could use RADIUS and LDAP services at the back end. could use RADIUS and LDAP services at the back end.
Authentication is an important aspect of securing WLAN networks prior Authentication is an important aspect of securing WLAN networks prior
to implementing Layer 3 security policies. This would help for to implementing Layer 3 security policies. For example, this would
example avoid threats to the ND or stateless auto-configuration help avoid threats to the ND or stateless auto-configuration
processes. 802.1x [IEEE8021X] provides the means to secure the processes. 802.1x [IEEE8021X] provides the means to secure the
network access however, the many types of EAP (PEAP, EAP-TLS, EAP- network access; however, the many types of EAP (PEAP, EAP-TLS, EAP-
TTLS, EAP-FAST, LEAP) and the capabilities of the hosts to support TTLS, EAP-FAST, and LEAP) and the capabilities of the hosts to
some of the features might make it difficult to implement a support some of the features might make it difficult to implement a
comprehensive and consistent policy. comprehensive and consistent policy.
The 802.11i [IEEE80211i] amendment has many components, the most The 802.11i [IEEE80211i] amendment has many components, the most
obvious of which are the two new data-confidentiality protocols, obvious of which are the two new data-confidentiality protocols,
Temporal Key Integrity Protocol (TKIP) and Counter-Mode/CBC-MAC Temporal Key Integrity Protocol (TKIP) and Counter-Mode/CBC-MAC
Protocol (CCMP). 802.11i also uses 802.1X's key-distribution system Protocol (CCMP). 802.11i also uses 802.1X's key-distribution system
to control access to the network. Because 802.11 handles unicast and to control access to the network. Because 802.11 handles unicast and
broadcast traffic differently, each traffic type has different broadcast traffic differently, each traffic type has different
security concerns. With several data-confidentiality protocols and security concerns. With several data-confidentiality protocols and
the key distribution, 802.11i includes a negotiation process for the key distribution, 802.11i includes a negotiation process for
skipping to change at page 65, line 7 skipping to change at page 66, line 46
secure. secure.
If any Layer 2 filters for Ethertypes are in place, the NAP must If any Layer 2 filters for Ethertypes are in place, the NAP must
permit the IPv6 Ethertype (0X86DD). permit the IPv6 Ethertype (0X86DD).
The device that is the Layer 3 next hop for the subscribers (Access The device that is the Layer 3 next hop for the subscribers (Access
or Edge Router) should protect the network and the other subscribers or Edge Router) should protect the network and the other subscribers
against attacks by one of the provider customers. For this reason against attacks by one of the provider customers. For this reason
uRPF and ACLs should be used on all interfaces facing subscribers. uRPF and ACLs should be used on all interfaces facing subscribers.
Filtering should be implemented with regard for the operational Filtering should be implemented with regard for the operational
requirements of IPv6 [Security considerations for IPv6]. requirements of IPv6 [IPv6-Security].
The Access and the Edge Router should protect their processing The Access and the Edge Router should protect their processing
resources against floods of valid customer control traffic such as: resources against floods of valid customer control traffic such as:
RS, NS, MLD Requests. Rate limiting should be implemented on all RS, NS, and MLD Requests. Rate limiting should be implemented on all
subscriber facing interfaces. The emphasis should be placed on subscriber-facing interfaces. The emphasis should be placed on
multicast type traffic as it is most often used by the IPv6 control multicast-type traffic, as it is most often used by the IPv6 control
plane. plane.
8.5. IPv6 Network Management 8.5. IPv6 Network Management
The necessary instrumentation (such as MIB modules, NetFlow Records, The necessary instrumentation (such as MIB modules, NetFlow Records,
etc) should be available for IPv6. etc) should be available for IPv6.
Usually, NSPs manage the edge routers by SNMP. The SNMP transport Usually, NSPs manage the edge routers by SNMP. The SNMP transport
can be done over IPv4 if all managed devices have connectivity over can be done over IPv4 if all managed devices have connectivity over
both IPv4 and IPv6. This would imply the smallest changes to the both IPv4 and IPv6. This would imply the smallest changes to the
existing network management practices and processes. Transport over existing network management practices and processes. Transport over
IPv6 could also be implemented and it might become necessary if IPv6 IPv6 could also be implemented and it might become necessary if IPv6
only islands are present in the network. The management applications only islands are present in the network. The management applications
may be running on hosts belonging to the NSP core network domain. may be running on hosts belonging to the NSP core network domain.
Network Management Applications should handle IPv6 in a similar Network Management Applications should handle IPv6 in a similar
fashion to IPv4 however they should also support features specific to fashion to IPv4; however, they should also support features specific
IPv6 (such as Neighbor monitoring). to IPv6 (such as neighbor monitoring).
In some cases service providers manage equipment located on customers In some cases, service providers manage equipment located on
LANs. customers' LANs.
9. Broadband Power Line Communications (PLC) 9. Broadband Power Line Communications (PLC)
This section describes the IPv6 deployment in Power Line This section describes the IPv6 deployment in Power Line
Communications (PLC) Access Networks. There may be other choices, Communications (PLC) Access Networks. There may be other choices,
but it seems that this is the best model to follow. Lessons learnt but it seems that this is the best model to follow. Lessons learnt
from Cable, Ethernet and even WLAN access networks may be applicable from cable, Ethernet, and even WLAN access networks may be applicable
also. also.
Power Line Communications are also often called Broadband Power Line Power Line Communications are also often called Broadband Power Line
(BPL) and some times even Power Line Telecommunications (PLT). (BPL) and some times even Power Line Telecommunications (PLT).
PLC/BPL can be used for providing, with today's technology, up to PLC/BPL can be used for providing, with today's technology, up to
200Mbps (total, upstream+downstream) by means of the power grid. The 200Mbps (total, upstream+downstream) by means of the power grid. The
coverage is often the last half mile (typical distance from the coverage is often the last half mile (typical distance from the
Medium-to-Low Voltage transformer to the customer premise meter), and 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 of course, as an in-home network (which is out of the scope of this
document). document).
The bandwidth in a given PLC/BPL segment is shared among all the The bandwidth in a given PLC/BPL segment is shared among all the
customers connected to that segment (often the customers connected to customers connected to that segment (often the customers connected to
the same medium-to-low voltage transformer). The number of customers the same medium-to-low voltage transformer). The number of customers
can vary depending on different factors, such as distances and even can vary depending on different factors, such as distances and even
countries (from a few customers, just 5-6, up to 100-150). countries (from a few customers, just 5-6, up to 100-150).
PLC/BPL could also be used in the Medium Voltage network (often PLC/BPL could also be used in the medium voltage network (often
configured as Metropolitan Area Networks), but this is also out of 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, the scope of this document, as it will be part of the core network,
not the access one. not the access one.
9.1. PLC/BPL Access Network Elements 9.1. PLC/BPL Access Network Elements
This section describes the different elements commonly used in PLC/ This section describes the different elements commonly used in PLC/
BPL access networks. BPL access networks.
Head End (HE): Router that connects the PLC/BPL access network (the Head End (HE): Router that connects the PLC/BPL access network (the
power grid), located at the medium-to-low voltage transformer, to 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 core network. The HE PLC/BPL interface appears to each customer as a
single virtual interface, all of them sharing the same physical single virtual interface, all of them sharing the same physical
media. media.
Repeater (RPT): A device which may be required in some circumstances 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 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 are many customers in the same segment or building. It is often a
bridge, but it could be also a router if for example there is a lot 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 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 nature of the PLC/BPL technology, is required to improve the
performance within that segment. For simplicity, in this document, performance within that segment. For simplicity within this
it will be considered that the RPT is always a transparent layer 2 document, the RPT will always be considered a transparent Layer 2
bridge, so it may be present or not (from the layer 3 point of view). bridge, so it may or may not be present (from the Layer 3 point of
view).
Customer Premise Equipment (CPE): Modem (internal to the host), Customer Premise Equipment (CPE): Modem (internal to the host),
modem/bridge (BCPE), router (RCPE) or any combination among those modem/bridge (BCPE), router (RCPE), or any combination among those
(i.e. modem+bridge/router), located at the customer premise. (i.e., modem+bridge/router), located at the customer premise.
Edge Router (ER) Edge Router (ER)
Figure 9.1 depicts all the network elements indicated above Figure 9.1 depicts all the network elements indicated above.
Customer Premise | Network Access Provider | Network Service Provider Customer Premise | Network Access Provider | Network Service Provider
+-----+ +------+ +-----+ +------+ +--------+ +-----+ +------+ +-----+ +------+ +--------+
|Hosts|--| RCPE |--| RPT |--------+ Head +---+ Edge | ISP |Hosts|--| RCPE |--| RPT |--------+ Head +---+ Edge | ISP
+-----+ +------+ +-----+ | End | | Router +=>Network +-----+ +------+ +-----+ | End | | Router +=>Network
+--+---+ +--------+ +--+---+ +--------+
+-----+ +------+ +-----+ | +-----+ +------+ +-----+ |
|Hosts|--| BCPE |--| RPT |-----------+ |Hosts|--| BCPE |--| RPT |-----------+
+-----+ +------+ +-----+ +-----+ +------+ +-----+
Figure 9.1
Figure 9.1
The logical topology and design of PLC/BPL is very similar to The logical topology and design of PLC/BPL is very similar to
Ethernet Broadband Networks as discussed in Section 7. IP Ethernet Broadband Networks as discussed in Section 7. IP
connectivity is typically provided in a Point-to-Point model as connectivity is typically provided in a Point-to-Point model, as
described in section 7.2.1 described in Section 7.2.1
9.2. Deploying IPv6 in IPv4 PLC/BPL 9.2. Deploying IPv6 in IPv4 PLC/BPL
The most simplistic and efficient model, considering the nature of 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 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 to each customer. Even if several customers share the same physical
media, the traffic is not visible among them because each one uses media, the traffic is not visible among them because each one uses
different channels, which are in addition encrypted by means of 3DES. different channels, which are, in addition, encrypted by means of
3DES.
In order to maintain the deployment concepts and business models In order to maintain the deployment concepts and business models
proven and used with existing revenue generating IPv4 services, the proven and used with existing revenue-generating IPv4 services, the
IPv6 deployment will match the IPv4 one. Under certain circumstances IPv6 deployment will match the IPv4 one. Under certain circumstances
where new service types or service needs justify it, IPv4 and IPv6 where new service types or service needs justify it, IPv4 and IPv6
network architectures could be different. Both approaches are very network architectures could be different. Both approaches are very
similar to those already described for the Ethernet case. similar to those already described for the Ethernet case.
9.2.1. IPv6 Related Infrastructure Changes 9.2.1. IPv6 Related Infrastructure Changes
In this scenario only the RPT is layer 3 unaware, but the other 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 devices have to be upgraded to dual stack Hosts, RCPE, Head End, and
Edge Router. Edge Router.
9.2.2. Addressing 9.2.2. Addressing
The Hosts or the RCPEs have the HE as their Layer 3 next hop. The Hosts or the RCPEs have the HE as their Layer 3 next hop.
If there is no RCPE, but instead a BCPE all the hosts on the 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 subscriber site belong to the same /64 subnet that is statically
configured on the HE. The hosts can use stateless auto-configuration configured on the HE. The hosts can use stateless auto-configuration
or stateful DHCPv6 based configuration to acquire an address via the or stateful DHCPv6-based configuration to acquire an address via the
HE. HE.
If a RCPE is present: If an RCPE is present:
A. It is statically configured with an address on the /64 subnet A. It is statically configured with an address on the /64 subnet
between itself and the HE, and with /64 prefixes on the interfaces between itself and the HE, and with /64 prefixes on the
connecting the hosts on the customer site. This is not a desired interfaces connecting the hosts on the customer site. This is
provisioning method being expensive and difficult to manage. not a desired provisioning method, being expensive and difficult
to manage.
B. It can use its link-local address to communicate with the HE. It B. It can use its link-local address to communicate with the HE. It
can also dynamically acquire through stateless auto-configuration the can also dynamically acquire through stateless auto-configuration
address for the link between itself and the HE. This step is the address for the link between itself and the HE. This step is
followed by a request via DHCP-PD for a prefix shorter than /64 followed by a request via DHCP-PD for a prefix shorter than /64
(typically /48 [RFC3177]) that in turn is divided in /64s and (typically /48 [RFC3177]) that, in turn, is divided in /64s and
assigned to its interfaces connecting the hosts on the customer site. assigned to its interfaces connecting the hosts on the customer
This should be the preferred provisioning method, being cheaper and site. This should be the preferred provisioning method, being
easier to manage. cheaper and easier to manage.
The Edge Router needs to have a prefix considering that each customer The Edge Router needs to have a prefix, considering that each
in general will receive a /48 prefix, and that each HE will customer in general will receive a /48 prefix, and that each HE will
accommodate customers. Consequently each HE will require n x /48 accommodate customers. Consequently, each HE will require n x /48
prefixes. prefixes.
It could be possible to use a kind of Hierarchical Prefix Delegation It could be possible to use a kind of Hierarchical Prefix Delegation
to automatically provision the required prefixes and fully auto- to automatically provision the required prefixes and fully auto-
configure the HEs, and consequently reduce the network setup, configure the HEs, and consequently reduce the network setup,
operation and maintenance cost. operation, and maintenance cost.
The prefixes used for subscriber links and the ones delegated via The prefixes used for subscriber links and the ones delegated via
DHCP-PD should be planned in a manner that allows as much DHCP-PD should be planned in a manner that allows as much
summarization as possible at the Edge Router. summarization as possible at the Edge Router.
Other information of interest to the host, such as DNS, is provided Other information of interest to the host, such as DNS, is provided
through stateful [RFC3315] and stateless [RFC3736] DHCPv6. through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
9.2.3. Routing 9.2.3. Routing
If no routers are used on the customer premise, the HE can simply be 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 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 router is used on the customer premise (RCPE), then the HE could also
run an IGP to the ER such as OSPFv3, IS-IS or even RIPng. The 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 connected prefixes should be redistributed. If DHCP-PD is used, with
every delegated prefix a static route is installed by the HE. For every delegated prefix a static route is installed by the HE. For
this reason the static routes must also be redistributed. Prefix this reason, the static routes must also be redistributed. Prefix
summarization should be done at the HE. summarization should be done at the HE.
The RCPE requires only a default route pointing to the HE. No The RCPE requires only a default route pointing to the HE. No
routing protocols are needed on these devices which generally have routing protocols are needed on these devices, which generally have
limited resources. limited resources.
The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. 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 RP The connected prefixes have to be redistributed, as well as any
other than the ones used on the ER that might be used between the HE routing protocols (other than the ones used on the ER) that might be
and the ER. used between the HE and the ER.
9.3. IPv6 Multicast 9.3. IPv6 Multicast
The considerations regarding IPv6 Multicast for Ethernet are also The considerations regarding IPv6 Multicast for Ethernet are also
applicable here, in general, but assuming the nature of PLC/BPL being applicable here, in general, assuming the nature of PLC/BPL is a
a shared media. If a lot of Multicast is expected, it may be worth 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 considering using RPT which are Layer 3 aware. In that case, one
extra layer of Hierarchical DHCP-PD could be considered, in order to extra layer of Hierarchical DHCP-PD could be considered, in order to
facilitate the deployment, operation and maintenance of the network. facilitate the deployment, operation, and maintenance of the network.
9.4. IPv6 QoS 9.4. IPv6 QoS
The considerations introduced for QoS in Ethernet are also applicable The considerations introduced for QoS in Ethernet are also applicable
here. PLC/BPL networks support QoS, which basically is the same here. PLC/BPL networks support QoS, which basically is the same
whether the transport is IPv4 or IPv6. It is necessary to understand whether the transport is IPv4 or IPv6. It is necessary to understand
that there are specific network characteristics, such as the that there are specific network characteristics, such as the
variability that may be introduced by electrical noise, towards which variability that may be introduced by electrical noise, towards which
the PLC/BPL network will automatically self-adapt. the PLC/BPL network will automatically self-adapt.
9.5. IPv6 Security Considerations 9.5. IPv6 Security Considerations
There are no differences in terms of security considerations if There are no differences in terms of security considerations if
compared with the Ethernet case. compared with the Ethernet case.
9.6. IPv6 Network Management 9.6. IPv6 Network Management
The issues related to IPv6 Network Management in PLC networks should The issues related to IPv6 Network Management in PLC networks should
be similar to those discussed for Broadband Ethernet Networks in 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 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 PLC networks and interfaces, but this is not necessarily related to
IPv6 management. IPv6 management.
10. Gap Analysis 10. Gap Analysis
Several aspects of deploying IPv6 over SP Broadband networks were Several aspects of deploying IPv6 over SP Broadband networks were
highlighted in this document, aspects that require additional work in highlighted in this document, aspects that require additional work in
order to facilitate native deployments as summarized below: order to facilitate native deployments, as summarized below:
A. As mentioned in section 5, changes will need to be made to the 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 DOCSIS specification in order for SPs to deploy native IPv6 over
cable networks. The CM and CMTS will both need to support IPv6 cable networks. The CM and CMTS will both need to support IPv6
natively in order to forward IPv6 unicast and multicast traffic. natively in order to forward IPv6 unicast and multicast traffic.
This is required for IPv6 Neighbor Discovery to work over DOCSIS This is required for IPv6 Neighbor Discovery to work over DOCSIS
cable networks. Additional classifiers need to be added to the cable networks. Additional classifiers need to be added to the
DOCSIS specification in order to classify IPv6 traffic at the CM and DOCSIS specification in order to classify IPv6 traffic at the CM
CMTS in order to provide QoS. These issues are addressed in a recent and CMTS in order to provide QoS. These issues are addressed in
proposal made to Cable Labs for DOCSIS 3.0 [DOCSIS 3.0 Requirements]. a recent proposal made to Cable Labs for DOCSIS 3.0
[DOCSIS3.0-Reqs].
B. Section 6 stated that current RBE based IPv4 deployment might not B. Section 6 stated that current RBE-based IPv4 deployment might not
be the best approach for IPv6 where the addressing space available be the best approach for IPv6, where the addressing space
gives the SP the opportunity to separate the users on different available gives the SP the opportunity to separate the users on
subnets. The differences between IPv4 RBE and IPv6 RBE were different subnets. The differences between IPv4 RBE and IPv6 RBE
highlighted in section 6. If however, support and reason is found were highlighted in Section 6. If, however, support and reason
for a deployment similar to IPv4 RBE, then the environment becomes are found for a deployment similar to IPv4 RBE, then the
NBMA and the new feature should observe RFC2491 recommendations. environment becomes NBMA and the new feature should observe
RFC2491 recommendations.
C. Section 6 discussed the constraints imposed on a LAA based IPv6 C. Section 6 discussed the constraints imposed on an LAA-based IPv6
deployment by the fact that it is expected that the subscribers keep deployment by the fact that it is expected that the subscribers
their assigned prefix regardless of LNS. A deployment approach was keep their assigned prefix, regardless of LNS. A deployment
proposed that would maintain the addressing schemes contiguous and approach was proposed that would maintain the addressing schemes
offers prefix summarization opportunities. The topic could be contiguous and offers prefix summarization opportunities. The
further investigated for other solutions or improvements. topic could be further investigated for other solutions or
improvements.
D. Sections 6 and 7 pointed out the limitations (previously D. Sections 6 and 7 pointed out the limitations (previously
documented in [IPv6 Multicast]) in deploying inter-domain ASM documented in [IPv6-Multicast]) in deploying inter-domain ASM;
however, SSM based services seem more likely at this time. For such however, SSM-based services seem more likely at this time. For
SSM based services of content delivery (video or Audio), mechanisms such SSM-based services of content delivery (video or audio),
are needed to facilitate the billing and management of listeners. mechanisms are needed to facilitate the billing and management of
The currently available feature of MLD AAA is suggested however, listeners. The currently available feature of MLD AAA is
other methods or mechanisms might be developed and proposed. suggested; however, other methods or mechanisms might be
developed and proposed.
E. In relation to section 8, concerns have been raised related to E. In relation to Section 8, concerns have been raised related to
running IPv6 multicast over WLAN links. Potentially these are same running IPv6 multicast over WLAN links. Potentially, these are
kind of issues when running any Layer 3 protocol over a WLAN link the same kind of issues when running any Layer 3 protocol over a
that has a high loss-to-signal ratio, certain frames that are WLAN link that has a high loss-to-signal ratio; certain frames
multicast based are dropped when settings are not adjusted properly. that are multicast based are dropped when settings are not
For instance this behavior is similar to IGMP host membership report, adjusted properly. For instance this behavior is similar to an
when done on a WLAN link with high loss-to-signal ratio and high IGMP host membership report, when done on a WLAN link with high
interference. This problem is inherited to WLAN that can impact both loss-to-signal ratio and high interference. This problem is
IPv4 and IPv6 multicast packets and not specific to IPv6 multicast. inherited by WLAN that can impact both IPv4 and IPv6 multicast
packets; it is not specific to IPv6 multicast.
F. The Privacy Extensions were mentioned as a popular means to F. The privacy extensions were mentioned as a popular means to
provide some form of host security. ISPs can track relatively easily provide some form of host security. ISPs can track relatively
the prefixes assigned to subscribers. If however the ISPs are easily the prefixes assigned to subscribers. If, however, the
required by regulations to track their users at host address level, ISPs are required by regulations to track their users at host
the Privacy Extensions [RFC3041] can be implemented only in parallel address level, the privacy extensions [RFC3041] can be
with network management tools that could provide traceability of the implemented only in parallel with network management tools that
hosts. Mechanisms should be defined to implement this aspect of user could provide traceability of the hosts. Mechanisms should be
management. defined to implement this aspect of user management.
G. Tunnels are an effective way to avoid deployment dependencies on 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 the IPv6 support on platforms that are out of the SP control
CPEs) or over technologies that did not standardize the IPv6 support (GWRs or CPEs) or over technologies that did not standardize the
yet (cable). They can be used in the following ways: IPv6 support yet (cable). They can be used in the following
ways:
i. Tunnels directly to the CPE or GWR with public or private IPv4 i. Tunnels directly to the CPE or GWR with public or private
addresses. IPv4 addresses.
ii. Tunnels directly to hosts with public or private IPv4 addresses. ii. Tunnels directly to hosts with public or private IPv4
Recommendations on the exact tunneling mechanisms that can/should be addresses. Recommendations on the exact tunneling
used for last mile access need to be investigated further and should mechanisms that can/should be used for last-mile access need
be addressed by the IETF Softwire Working Group. to be investigated further and should be addressed by the
IETF Softwire Working Group.
H. Through its larger address space, IPv6 allows SPs to assign fixed, H. Through its larger address space, IPv6 allows SPs to assign
globally routable prefixes to the links connecting each subscriber. fixed, globally routable prefixes to the links connecting each
subscriber.
This approach changes the provisioning methodologies that were used This approach changes the provisioning methodologies that were
for IPv4. Static configuration of the IPv6 addresses for all these used for IPv4. Static configuration of the IPv6 addresses for
links on the Edge Routers or Access Routers might not be a scalable all these links on the Edge Routers or Access Routers might not
option. New provisioning mechanisms or features might need to be be a scalable option. New provisioning mechanisms or features
developed in order to deal with this issue, such as automatic mapping might need to be developed in order to deal with this issue, such
of VLAN IDs/PVCs (or other customer-specific information) to IPv6 as automatic mapping of VLAN IDs/PVCs (or other customer-specific
prefixes. information) to IPv6 prefixes.
I. New deployment models are emerging for the Layer 2 portion of the I. New deployment models are emerging for the Layer 2 portion of the
NAP where individual VLANs are not dedicated to each subscriber. NAP where individual VLANs are not dedicated to each subscriber.
This approach allows Layer 2 switches to aggregate more then 4096 This approach allows Layer 2 switches to aggregate more then 4096
users. MAC Forced Forwarding [MFF] is an example of such an users. MAC Forced Forwarding [RFC4562] is an example of such an
implementation where a broadcast domain is turned into a NBMA like implementation, where a broadcast domain is turned into an NBMA-
environment by forwarding the frames based on both Source and like environment by forwarding the frames based on both Source
Destination MAC addresses. Since these models are being adopted by and Destination MAC addresses. Since these models are being
the field, the implications of deploying IPv6 in such environments adopted by the field, the implications of deploying IPv6 in such
need to be further investigated. environments need to be further investigated.
J. The deployment of IPv6 in continuously evolving access service J. The deployment of IPv6 in continuously evolving access service
models raises some issues that may need further investigation. models raises some issues that may need further investigation.
Examples of such topics are [v6 auto-config]: Examples of such topics are [AUTO-CONFIG]:
i. Network Service Selection & Authentication (NSSA) mechanisms i. Network Service Selection & Authentication (NSSA) mechanisms
working in association with stateless auto-configuration. As an working in association with stateless auto-configuration.
example, NSSA relevant information such as ISP preference, passwords As an example, NSSA relevant information, such as ISP
or profile ID can be sent by hosts with the RS [RFC4191]. preference, passwords, or profile ID, can be sent by hosts
with the RS [RFC4191].
ii. Providing additional information in Router Advertisements to ii. Providing additional information in Router Advertisements to
help access nodes with prefix selection in multi-ISP/multi-homed help access nodes with prefix selection in multi-ISP/
environment. multi-homed environments.
The outcome of solutions to some of these topics ranges from making a
media access capable of supporting native IPv6 (cable) to improving
operational aspects of native IPv6 deployments.
11. IANA Considerations
This document requests no action by IANA. 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.
12. Security Considerations 11. Security Considerations
Please refer to the individual "IPv6 Security Considerations" Please refer to the individual "IPv6 Security Considerations"
technology sections for details. technology sections for details.
13. Acknowledgements 12. Acknowledgements
We would like to thank Brian Carpenter, Patrick Grossetete, Toerless We would like to thank Brian Carpenter, Patrick Grossetete, Toerless
Eckert, Madhu Sudan, Shannon McFarland and Benoit Lourdelet, Fred Eckert, Madhu Sudan, Shannon McFarland, Benoit Lourdelet, and Fred
Baker for their valuable comments. The authors would like to Baker for their valuable comments. The authors would like to
acknowledge the structure and information guidance provided by the acknowledge the structure and information guidance provided by the
work of Mickels et al on Transition Scenarios for ISP Networks. work of Mickles, et al., on "Transition Scenarios for ISP Networks"
[ISP-CASES].
14. References 13. References
14.1. Normative References 13.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot,
E. Lear, "Address Allocation for Private Internets", G., and E. Lear, "Address Allocation for Private
BCP 5, RFC 1918, February 1996. Internets", BCP 5, RFC 1918, February 1996.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6",
January 1997. RFC 2080, January 1997.
[RFC2364] Gross, G., Kaycee, M., Lin, A., Malis, A., and J. [RFC2364] Gross, G., Kaycee, M., Lin, A., Malis, A., and J.
Stephens, "PPP Over AAL5", RFC 2364, July 1998. Stephens, "PPP Over AAL5", RFC 2364, July 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998. December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling
IPv6 Specification", RFC 2473, December 1998. in IPv6 Specification", RFC 2473, December 1998.
[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.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D.,
Domains without Explicit Tunnels", RFC 2529, March 1999. Simone, D., and R. Wheeler, "A Method for
Transmitting PPP Over Ethernet (PPPoE)", RFC 2516,
February 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", over IPv4 Domains without Explicit Tunnels",
RFC 2661, August 1999. RFC 2529, March 1999.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G.,
RFC 2740, December 1999. Zorn, G., and B. Palter, "Layer Two Tunneling
Protocol "L2TP"", RFC 2661, August 1999.
[RFC2770] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for
RFC 2770, February 2000. IPv6", RFC 2740, December 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)",
March 2000. RFC 2784, March 2000.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041, Stateless Address Autoconfiguration in IPv6",
January 2001. RFC 3041, January 2001.
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento,
Tunnel Broker", RFC 3053, January 2001. "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6
via IPv4 Clouds", RFC 3056, February 2001. Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6
Allocations to Sites", RFC 3177, September 2001. Address Allocations to Sites", RFC 3177,
September 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in
and M. Carney, "Dynamic Host Configuration Protocol for 233/8", BCP 53, RFC 3180, September 2001.
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
Protocol (MSDP)", RFC 3618, October 2003. C., and M. Carney, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3618] Fenner, B. and D. Meyer, "Multicast Source
Networks", BCP 84, RFC 3704, March 2004. Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
(DHCP) Service for IPv6", RFC 3736, April 2004. Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der [RFC3736] Droms, R., "Stateless Dynamic Host Configuration
Pol, "Evaluation of IPv6 Transition Mechanisms for Protocol (DHCP) Service for IPv6", RFC 3736,
Unmanaged Networks", RFC 3904, September 2004. April 2004.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling [RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. der Pol, "Evaluation of IPv6 Transition Mechanisms
for Unmanaged Networks", RFC 3904, September 2004.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two
Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
March 2005.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network Schoenwaelder, "Textual Conventions for Internet
Addresses", RFC 4001, February 2005. Network Addresses", RFC 4001, February 2005.
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
Savola, "Scenarios and Analysis for Introducing IPv6 into Savola, "Scenarios and Analysis for Introducing
ISP Networks", RFC 4029, March 2005. IPv6 into ISP Networks", RFC 4029, March 2005.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router
More-Specific Routes", RFC 4191, November 2005. Preferences and More-Specific Routes", RFC 4191,
November 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition
for IPv6 Hosts and Routers", RFC 4213, October 2005. Mechanisms for IPv6 Hosts and Routers", RFC 4213,
October 2005.
[RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D.
"Intra-Site Automatic Tunnel Addressing Protocol Thaler, "Intra-Site Automatic Tunnel Addressing
(ISATAP)", RFC 4214, October 2005. Protocol (ISATAP)", RFC 4214, October 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP
Network Address Translations (NATs)", RFC 4380, through Network Address Translations (NATs)",
February 2006. RFC 4380, February 2006.
14.2. Informative References 13.2. Informative References
[6PE] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, [6PE] De Clercq, J., Ooms, D., Prevost, S., and F. Le
"Connecting IPv6 Islands across IPv4 Clouds with Faucheur, "Connecting IPv6 Islands across IPv4
BGP(draft-ooms-v6ops-bgp-tunnel-04.txt)", October 2004. Clouds with BGP", Work in Progress, December 2006.
[BSR] Bhaskar, N., Gall, A., and S. Venaas, "Bootstrap Router [AUTO-CONFIG] Wen, H., Zhu, X., Jiang, Y., and R. Yan, "The
(BSR) Mechanism for PIM(draft-ietf-pim-sm-bsr-04.txt)", deployment of IPv6 stateless auto-configuration in
January 2005. access network", 8th International Conference on
Telecommunications, ConTEL 2005, June 2005.
[DOCSIS 3.0 OSSI] [BSR] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
CableLabs, CL., "DOCSIS 3.0 OSSI Specification(CM-SP- "Bootstrap Router (BSR) Mechanism for PIM", Work
OSSIv3.0-D02-060504)", May 2006. in Progress, June 2006.
[DOCSIS 3.0 Requirements] [DOCSIS3.0-OSSI] CableLabs, CL., "DOCSIS 3.0 OSSI Specification(CM-
Droms, R., Durand, A., Kharbanda, D., and J-F. Mule, SP-OSSIv3.0-D02-060504)", May 2006.
"DOCSIS 3.0 Requirements for IPv6
Support(draft-mule-cablelabs-docsis3-ipv6-00.txt)",
March 2006.
[Dynamic Tunnel] [DOCSIS3.0-Reqs] Droms, R., Durand, A., Kharbanda, D., and J-F.
Palet, J., Diaz, M., and P. Savola, "Analysis of IPv6 Mule, "DOCSIS 3.0 Requirements for IPv6 Support",
Tunnel End-point Discovery Work in Progress, March 2006.
Mechanisms(draft-palet-v6ops-tun-auto-disc-03.txt)",
January 2005.
[IEEE80211i] [DynamicTunnel] Palet, J., Diaz, M., and P. Savola, "Analysis of
IEEE, "IEEE Standards for Information Technology: Part 11: IPv6 Tunnel End-point Discovery Mechanisms", Work
Wireless LAN Medium Access Control (MAC) and Physical in Progress, January 2005.
Layer (PHY) specifications, Amendment 6: Medium Access
Control (MAC) Security Enhancements", July 2004.
[IEEE8021X] [IEEE80211i] IEEE, "IEEE Standards for Information Technology:
IEEE, "IEEE Standards for Local and Metropolitan Area Part 11: Wireless LAN Medium Access Control (MAC)
Networks: Port based Network Access Control, IEEE Std and Physical Layer (PHY) specifications, Amendment
802.1X-2001", June 2001. 6: Medium Access Control (MAC) Security
Enhancements", July 2004.
[IPv6 Multicast] [IEEE8021X] IEEE, "IEEE Standards for Local and Metropolitan
Savola, P., "IPv6 Multicast Deployment Area Networks: Port based Network Access Control,
Issues(draft-mboned-ipv6-multicast-issues.txt)", IEEE Std 802.1X-2001", June 2001.
April 2004.
[ISISv6] Hopps, C., "Routing IPv6 with [IPv6-Multicast] Savola, P., "IPv6 Multicast Deployment Issues",
IS-IS(draft-ietf-isis-ipv6-06.txt)", October 2005. Work in Progress, April 2004.
[MFF] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method [IPv6-Security] Convery, S. and D. Miller, "IPv6 and IPv4 Threat
for Traffic Separation on an Ethernet Access Comparison and Best-Practice Evaluation",
Network(draft-melsen-mac-forced-fwd-04.txt)", March 2004.
January 2006.
[Protocol 41] [ISISv6] Hopps, C., "Routing IPv6 with IS-IS", Work
Palet, J., Olvera, C., and D. Fernandez, "Forwarding in Progress, October 2005.
Protocol 41 in NAT
Boxes(draft-palet-v6ops-proto41-nat-03.txt)",
October 2003.
[RF Interface] [ISP-CASES] Mickles, C., "Transition Scenarios for ISP
CableLabs, CL., "DOCSIS 2.0(CM-SP-RFIv2.0-I10-051209)", Networks", Work in Progress, September 2002.
December 2005.
[Security considerations for IPv6] [Protocol41] Palet, J., Olvera, C., and D. Fernandez,
Convery, S. and D. Miller, "IPv6 and IPv4 Threat "Forwarding Protocol 41 in NAT Boxes", Work
Comparison and Best-Practice Evaluation", March 2004. in Progress, October 2003.
[Softwire] [RF-Interface] CableLabs, CL., "DOCSIS 2.0(CM-SP-RFIv2.0-I10-
Li, X., Durand, A., Ward, D., and S. Dawkins, Ed., 051209)", December 2005.
"Softwire Problem
Statement(draft-ietf-softwire-problem-statement-01.txt)",
February 2006.
[v6 auto-config] [RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A
Wen, H., Zhu, X., Jiang, Y., and R. Yan, "The deployment Method for Subscriber Separation on an Ethernet
of IPv6 stateless auto-configuration in access network", Access Network", RFC 4562, June 2006.
June 2005.
[Softwire] Dawkins, S., Ed., "Softwire Problem Statement",
Work in Progress, May 2006.
[v6tc] Palet, J., Nielsent, K., Parent, F., Durand, A., [v6tc] Palet, J., Nielsent, K., Parent, F., Durand, A.,
Suryanarayanan, R., and P. Savola, "Goals for Tunneling Suryanarayanan, R., and P. Savola, "Goals for
Configuration(draft-palet-v6tc-goals-tunneling-00.txt)", Tunneling Configuration", Work in Progress,
August 2005. August 2005.
Authors' Addresses Authors' Addresses
Salman Asadullah Salman Asadullah
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: 408 526 8982 Phone: 408 526 8982
Email: sasad@cisco.com EMail: sasad@cisco.com
Adeel Ahmed Adeel Ahmed
Cisco Systems Cisco Systems
2200 East President George Bush Turnpike 2200 East President George Bush Turnpike
Richardson, TX 75082 Richardson, TX 75082
USA USA
Phone: 469 255 4122 Phone: 469 255 4122
Email: adahmed@cisco.com EMail: adahmed@cisco.com
Ciprian Popoviciu Ciprian Popoviciu
Cisco Systems Cisco Systems
7025-6 Kit Creek Road 7025-6 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Phone: 919 392 3723 Phone: 919 392 3723
Email: cpopovic@cisco.com EMail: cpopovic@cisco.com
Pekka Savola Pekka Savola
CSC - Scientific Computing Ltd. CSC - Scientific Computing Ltd.
Espoo Espoo
Finland Finland
Email: psavola@funet.fi EMail: psavola@funet.fi
Jordi Palet Martinez Jordi Palet Martinez
Consulintel Consulintel
San Jose Artesano, 1 San Jose Artesano, 1
Alcobendas, Madrid E-28108 Alcobendas, Madrid E-28108
Spain Spain
Phone: +34 91 151 81 99 Phone: +34 91 151 81 99
Email: jordi.palet@consulintel.es EMail: jordi.palet@consulintel.es
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 79, line 29 skipping to change at page 81, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 502 change blocks. 
1147 lines changed or deleted 1178 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/