rfc4779
Network Working Group S. Asadullah
Request for Comments: 4779 A. Ahmed
Category: Informational C. Popoviciu
Cisco Systems
P. Savola
CSC/FUNET
J. Palet
Consulintel
January 2007
ISP IPv6 Deployment Scenarios in Broadband Access Networks
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document provides a detailed description of IPv6 deployment and
integration methods and scenarios in today's Service Provider (SP)
Broadband (BB) networks in coexistence with deployed IPv4 services.
Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies
that are currently deployed, and discussed in this document. The
emerging Broadband Power Line Communications (PLC/BPL) access
technology is also discussed for completeness. In this document we
will discuss main components of IPv6 BB networks, their differences
from IPv4 BB networks, and how IPv6 is deployed and integrated in
each of these networks using tunneling mechanisms and native IPv6.
Asadullah, et al. Informational [Page 1]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Common Terminology . . . . . . . . . . . . . . . . . . . . . . 5
3. Core/Backbone Network . . . . . . . . . . . . . . . . . . . . 5
3.1. Layer 2 Access Provider Network . . . . . . . . . . . . . 5
3.2. Layer 3 Access Provider Network . . . . . . . . . . . . . 6
4. Tunneling Overview . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Access over Tunnels - Customers with Public IPv4
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Access over Tunnels - Customers with Private IPv4
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Transition a Portion of the IPv4 Infrastructure . . . . . 8
5. Broadband Cable Networks . . . . . . . . . . . . . . . . . . . 9
5.1. Broadband Cable Network Elements . . . . . . . . . . . . . 9
5.2. Deploying IPv6 in Cable Networks . . . . . . . . . . . . . 10
5.2.1. Deploying IPv6 in a Bridged CMTS Network . . . . . . . 12
5.2.2. Deploying IPv6 in a Routed CMTS Network . . . . . . . 14
5.2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . 23
5.2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.5. IPv6 Security Considerations . . . . . . . . . . . . . 24
5.2.6. IPv6 Network Management . . . . . . . . . . . . . . . 25
6. Broadband DSL Networks . . . . . . . . . . . . . . . . . . . . 26
6.1. DSL Network Elements . . . . . . . . . . . . . . . . . . . 26
6.2. Deploying IPv6 in IPv4 DSL Networks . . . . . . . . . . . 28
6.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 29
6.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 30
6.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 33
6.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 36
6.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 38
6.3.1. ASM-Based Deployments . . . . . . . . . . . . . . . . 39
6.3.2. SSM-Based Deployments . . . . . . . . . . . . . . . . 39
6.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 41
6.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 42
7. Broadband Ethernet Networks . . . . . . . . . . . . . . . . . 42
7.1. Ethernet Access Network Elements . . . . . . . . . . . . . 42
7.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks . . . . 43
7.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 44
7.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 46
7.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 48
7.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 50
7.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 52
7.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 54
7.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 55
Asadullah, et al. Informational [Page 2]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
8. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.1. WLAN Deployment Scenarios . . . . . . . . . . . . . . . . 55
8.1.1. Layer 2 NAP with Layer 3 termination at NSP Edge
Router . . . . . . . . . . . . . . . . . . . . . . . . 56
8.1.2. Layer 3 Aware NAP with Layer 3 Termination at
Access Router . . . . . . . . . . . . . . . . . . . . 59
8.1.3. PPP-Based Model . . . . . . . . . . . . . . . . . . . 61
8.2. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 63
8.3. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.4. IPv6 Security Considerations . . . . . . . . . . . . . . . 65
8.5. IPv6 Network Management . . . . . . . . . . . . . . . . . 67
9. Broadband Power Line Communications (PLC) . . . . . . . . . . 67
9.1. PLC/BPL Access Network Elements . . . . . . . . . . . . . 68
9.2. Deploying IPv6 in IPv4 PLC/BPL . . . . . . . . . . . . . . 69
9.2.1. IPv6 Related Infrastructure Changes . . . . . . . . . 69
9.2.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 69
9.2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 70
9.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 71
9.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 71
9.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 71
10. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 71
11. Security Considerations . . . . . . . . . . . . . . . . . . . 74
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 74
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74
13.1. Normative References . . . . . . . . . . . . . . . . . . . 74
13.2. Informative References . . . . . . . . . . . . . . . . . . 76
Asadullah, et al. Informational [Page 3]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
1. Introduction
This document presents the options available in deploying IPv6
services in the access portion of a BB Service Provider (SP) network
- namely Cable/HFC, BB Ethernet, xDSL, WLAN, and PLC/BPL.
This document briefly discusses the other elements of a provider
network as well. It provides different viable IPv6 deployment and
integration techniques, and models for each of the above-mentioned BB
technologies individually. The example list is not exhaustive, but
it tries to be representative.
This document analyzes how all the important components of current
IPv4-based Cable/HFC, BB Ethernet, xDSL, WLAN, and PLC/BPL networks
will behave when IPv6 is integrated and deployed.
The following important pieces are discussed:
A. Available tunneling options
B. Devices that would have to be upgraded to support IPv6
C. Available IPv6 address assignment techniques and their use
D. Possible IPv6 Routing options and their use
E. IPv6 unicast and multicast packet transmission
F. Required IPv6 Quality of Service (QoS) parameters
G. Required IPv6 Security parameters
H. Required IPv6 Network Management parameters
It is important to note that the addressing rules provided throughout
this document represent an example that follows the current
assignment policies and recommendations of the registries. However,
they can be adapted to the network and business model needs of the
ISPs.
The scope of the document is to advise on the ways of upgrading an
existing infrastructure to support IPv6 services. The recommendation
to upgrade a device to dual stack does not stop an SP from adding a
new device to its network to perform the necessary IPv6 functions
discussed. The costs involved with such an approach could be offset
by lower impact on the existing IPv4 services.
Asadullah, et al. Informational [Page 4]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
2. Common Terminology
BB: Broadband
CPE: Customer Premise Equipment
GWR: Gateway Router
ISP: Internet Service Provider
NAP: Network Access Provider
NSP: Network Service Provider
QoS: Quality of Service
SP: Service Provider
3. Core/Backbone Network
This section intends to briefly discuss some important elements of a
provider network tied to the deployment of IPv6. A more detailed
description of the core network is provided in other documents
[RFC4029].
There are two types of networks identified in the Broadband
deployments:
A. Access Provider Network: This network provides the broadband
access and aggregates the subscribers. The subscriber traffic is
handed over to the Service Provider at Layer 2 or 3.
B. Service Provider Network: This network provides Intranet and
Internet IP connectivity for the subscribers.
The Service Provider network structure beyond the Edge Routers that
interface with the Access provider is beyond the scope of this
document.
3.1. Layer 2 Access Provider Network
The Access Provider can deploy a Layer 2 network and perform no
routing of the subscriber traffic to the SP. The devices that
support each specific access technology are aggregated into a highly
redundant, resilient, and scalable Layer 2 core. The network core
can involve various technologies such as Ethernet, Asynchronous
Transfer Mode (ATM), etc. The Service Provider Edge Router connects
to the Access Provider core.
Asadullah, et al. Informational [Page 5]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
This type of network may be transparent to the Layer 3 protocol.
Some possible changes may come with the intent of supporting IPv6
provisioning mechanisms, as well as filtering and monitoring IPv6
traffic based on Layer 2 information such as IPv6 Ether Type Protocol
ID (0x86DD) or IPv6 multicast specific Media Access Control (MAC)
addresses (33:33:xx:xx:xx:xx).
3.2. Layer 3 Access Provider Network
The Access Provider can choose to terminate the Layer 2 domain and
route the IP traffic to the Service Provider network. Access Routers
are used to aggregate the subscriber traffic and route it over a
Layer 3 core to the SP Edge Routers. In this case, the impact of the
IPv6 deployment is significant.
The case studies in this document discuss only the relevant network
elements of such a network: Customer Premise Equipment, Access
Router, and Edge Router. In real networks, the link between the
Access Router and the Edge Router involves other routers that are
part of the aggregation and the core layer of the Access Provider
network.
The Access Provider can forward the IPv6 traffic through its Layer 3
core in three possible ways:
A. IPv6 Tunneling: As a temporary solution, the Access Provider can
choose to use a tunneling mechanism to forward the subscriber
IPv6 traffic to the Service Provider Edge Router. This approach
has the least impact on the Access Provider network; however, as
the number of users increase and the amount of IPv6 traffic
grows, the ISP will have to evolve to one of the scenarios listed
below.
B. Native IPv6 Deployment: The Access Provider routers are upgraded
to support IPv6 and can become dual stack. In a dual-stack
network, an IPv6 Interior Gateway Protocol (IGP), such as OSPFv3
[RFC2740] or IS-IS [ISISv6], is enabled. RFC 4029 [RFC4029]
discusses the IGP selection options with their benefits and
drawbacks.
C. MPLS 6PE Deployment [6PE]: If the Access Provider is running MPLS
in its IPv4 core, it could use 6PE to forward IPv6 traffic over
it. In this case, only a subset of routers close to the edge of
the network need to be IPv6 aware. With this approach, BGP
becomes important in order to support 6PE.
The 6PE approach has the advantage of having minimal impact on the
Access Provider network. Fewer devices need to be upgraded and
Asadullah, et al. Informational [Page 6]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
configured while the MPLS core continues to switch the traffic,
unaware that it transports both IPv4 and IPv6. 6PE should be
leveraged only if MPLS is already deployed in the network. At the
time of writing this document, a major disadvantage of the 6PE
solution is that it does not support multicast IPv6 traffic.
The native approach has the advantage of supporting IPv6 multicast
traffic, but it may imply a significant impact on the IPv4
operational network in terms of software configuration and possibly
hardware upgrade.
More detailed Core Network deployment recommendations are discussed
in other documents [RFC4029]. The handling of IPv6 traffic in the
Core of the Access Provider Network will not be discussed for the
remainder of this document.
4. Tunneling Overview
If SPs are not able to deploy native IPv6, they might use tunneling-
based transition mechanisms to start an IPv6 service offering, and
move to native IPv6 deployment at a later time.
Several tunneling mechanisms were developed specifically to transport
IPv6 over existing IPv4 infrastructures. Several of them have been
standardized and their use depends on the existing SP IPv4 network
and the structure of the IPv6 service. The requirements for the most
appropriate mechanisms are described in [v6tc] with more updates to
follow. Deploying IPv6 using tunneling techniques can imply as
little changes to the network as upgrading software on tunnel end
points. A Service Provider could use tunneling to deploy IPv6 in the
following scenarios:
4.1. Access over Tunnels - Customers with Public IPv4 Addresses
If the customer is a residential user, it can initiate the tunnel
directly from the IPv6 capable host to a tunnel termination router
located in the NAP or ISP network. The tunnel type used should be
decided by the SP, but it should take into consideration its
availability on commonly used software running on the host machine.
Of the many tunneling mechanisms developed, such as IPv6 Tunnel
Broker [RFC3053], Connection of IPv6 Domains via IPv4 Clouds
[RFC3056], Generic Packet Tunneling in IPv6 [RFC2473], ISATAP
[RFC4214], Basic Transition Mechanisms for IPv6 Hosts and Routers
[RFC4213], and Transmission of IPv6 over IPv4 Domains without
Explicit Tunnels [RFC2529], some are more popular than the others.
At the time of writing this document, the IETF Softwire Working Group
was tasked with standardizing a single tunneling protocol [Softwire]
for this application.
Asadullah, et al. Informational [Page 7]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
If the end customer has a GWR installed, then it could be used to
originate the tunnel, thus offering native IPv6 access to multiple
hosts on the customer network. In this case, the GWR would need to
be upgraded to dual stack in order to support IPv6. The GWR can be
owned by the customer or by the SP.
4.2. Access over Tunnels - Customers with Private IPv4 Addresses
If the end customer receives a private IPv4 address and needs to
initiate a tunnel through Network Address Translation (NAT),
techniques like 6to4 may not work since they rely on public IPv4
address. In this case, unless the existing GWRs support protocol-41-
forwarding [Protocol41], the end user might have to use tunnels that
can operate through NATs (such as Teredo [RFC4380]). Most GWRs
support protocol-41-forwarding, which means that hosts can initiate
the tunnels - in which case the GWR is not affected by the IPv6
service.
The customer has the option to initiate the tunnel from the device
(GWR) that performs the NAT functionality, similar to the GWR
scenario discussed in Section 4.1. This will imply hardware
replacement or software upgrade and a native IPv6 environment behind
the GWR.
It is also worth observing that initiating an IPv6 tunnel over IPv4
through already established IPv4 IPsec sessions would provide a
certain level of security to the IPv6 traffic.
4.3. Transition a Portion of the IPv4 Infrastructure
Tunnels can be used to transport the IPv6 traffic across a defined
segment of the network. As an example, the customer might connect
natively to the Network Access Provider, where a tunnel is used to
transit the traffic over IPv4 to the ISP. In this case, the tunnel
choice depends on its capabilities (for example, whether or not it
supports multicast), routing protocols used (there are several types
that can transport Layer 2 messages, such as GRE [RFC2784], L2TPv3
[RFC3931], or pseudowire), manageability, and scalability (dynamic
versus static tunnels).
This scenario implies that the access portion of the network has been
upgraded to support dual stack, so the savings provided by tunneling
in this scenario are very small compared with the previous two
scenarios. Depending on the number of sites requiring the service,
and considering the expenses required to manage the tunnels (some
tunnels are static while others are dynamic [DynamicTunnel]) in this
case, the SPs might find the native approach worth the additional
investments.
Asadullah, et al. Informational [Page 8]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
In all the scenarios listed above, the tunnel selection process
should consider the IPv6 multicast forwarding capabilities if such
service is planned. As an example, 6to4 tunnels do not support IPv6
multicast traffic.
The operation, capabilities, and deployment of various tunnel types
have been discussed extensively in the documents referenced earlier
as well as in [RFC4213] and [RFC3904]. Details of a tunnel-based
deployment are offered in the next section of this document, which
discusses the case of Cable Access, where the current Data Over Cable
Service Interface Specification (DOCSIS 2.0) [RF-Interface] and prior
specifications do not provide support for native IPv6 access.
Although Sections 6, 7, 8, and 9 focus on a native IPv6 deployments
over DSL, Fiber to the Home (FTTH), wireless, and PLC/BPL and because
this approach is fully supported today, tunnel-based solutions are
also possible in these cases based on the guidelines of this section
and some of the recommendations provided in Section 5.
5. Broadband Cable Networks
This section describes the infrastructure that exists today in cable
networks providing BB services to the home. It also describes IPv6
deployment options in these cable networks.
DOCSIS standardizes and documents the operation of data over cable
networks. DOCSIS 2.0 and prior specifications have limitations that
do not allow for a smooth implementation of native IPv6 transport.
Some of these limitations are discussed in this section. For this
reason, the IPv6 deployment scenarios discussed in this section for
the existing cable networks are tunnel based. The tunneling examples
presented here could also be applied to the other BB technologies
described in Sections 6, 7, 8, and 9.
5.1. Broadband Cable Network Elements
Broadband cable networks are capable of transporting IP traffic to/
from users to provide high speed Internet access and Voice over IP
(VoIP) services. The mechanism for transporting IP traffic over
cable networks is outlined in the DOCSIS specification
[RF-Interface].
Here are some of the key elements of a cable network:
Cable (HFC) Plant: Hybrid Fiber Coaxial plant, used as the underlying
transport
CMTS: Cable Modem Termination System (can be a Layer 2 bridging or
Layer 3 routing CMTS)
Asadullah, et al. Informational [Page 9]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
GWR: Residential Gateway Router (provides Layer 3 services to hosts)
Host: PC, notebook, etc., which is connected to the CM or GWR
CM: Cable Modem
ER: Edge Router
MSO: Multiple Service Operator
Data Over Cable Service Interface Specification (DOCSIS): Standards
defining how data should be carried over cable networks
Figure 5.1 illustrates the key elements of a Cable Network.
|--- ACCESS ---||------ HFC ------||----- Aggregation / Core -----|
+-----+ +------+
|Host |--| GWR |
+-----+ +--+---+
| _ _ _ _ _ _
+------+ | |
| CM |---| |
+------+ | |
| HFC | +------+ +--------+
| | | | | Edge |
+-----+ +------+ | Network |---| CMTS |---| |=>ISP
|Host |--| CM |---| | | | | Router | Network
+-----+ +--+---+ | | +------+ +--------+
|_ _ _ _ _ _|
+------+ |
+-----+ | GWR/ | |
|Host |--| CM |---------+
+-----+ | |
+------+
Figure 5.1
5.2. Deploying IPv6 in Cable Networks
One of the motivators for an MSO to deploy IPv6 over its cable
network is to ease management burdens. IPv6 can be enabled on the
CM, CMTS, and ER for management purposes. Currently portions of the
cable infrastructure use IPv4 address space [RFC1918]; however, there
is a finite number of those. Thus, IPv6 could have utility in the
cable space implemented on the management plane initially and focused
Asadullah, et al. Informational [Page 10]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
on the data plane for end-user services later. For more details on
using IPv6 for management in cable networks, please refer to Section
5.6.1.
There are two different deployment modes in current cable networks: a
bridged CMTS environment and a routed CMTS environment. IPv6 can be
deployed in both of these environments.
1. Bridged CMTS Network
In this scenario, both the CM and CMTS bridge all data traffic.
Traffic to/from host devices is forwarded through the cable network
to the ER. The ER then routes traffic through the ISP network to the
Internet. The CM and CMTS support a certain degree of Layer 3
functionality for management purposes.
2. Routed CMTS Network
In a routed network, the CMTS forwards IP traffic to/from hosts based
on Layer 3 information using the IP source/destination address. The
CM acts as a Layer 2 bridge for forwarding data traffic and supports
some Layer 3 functionality for management purposes.
Some of the factors that hinder deployment of native IPv6 in current
routed and bridged cable networks include:
A. Changes need to be made to the DOCSIS specification
[RF-Interface] to include support for IPv6 on the CM and CMTS.
This is imperative for deploying native IPv6 over cable networks.
B. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. In
IPv4, these devices rely on Internet Group Multicast Protocol
(IGMP) join messages to track membership of hosts that are part
of a particular IP multicast group. In order to support ND, a
multicast-based process, the CM and CMTS will need to support
IGMPv3/Multicast Listener Discovery Version 2 (MLDv2) or v1
snooping.
C. Classification of IPv6 traffic in the upstream and downstream
direction. The CM and CMTS will need to support classification
of IPv6 packets in order to give them the appropriate priority
and QoS. Service providers that wish to deploy QoS mechanisms
also have to support classification of IPv6 traffic.
Due to the above mentioned limitations in deployed cable networks, at
the time of writing this document, the only option available for
cable operators is to use tunneling techniques in order to transport
IPv6 traffic over their current IPv4 infrastructure. The following
Asadullah, et al. Informational [Page 11]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
sections will cover tunneling and native IPv6 deployment scenarios in
more detail.
5.2.1. Deploying IPv6 in a Bridged CMTS Network
In IPv4, the CM and CMTS act as Layer 2 bridges and forward all data
traffic to/from the hosts and the ER. The hosts use the ER as their
Layer 3 next hop. If there is a GWR behind the CM it can act as a
next hop for all hosts and forward data traffic to/from the ER.
When deploying IPv6 in this environment, the CM and CMTS will
continue to act as bridging devices in order to keep the transition
smooth and reduce operational complexity. The CM and CMTS will need
to bridge IPv6 unicast and multicast packets to/from the ER and the
hosts. If there is a GWR connected to the CM, it will need to
forward IPv6 unicast and multicast traffic to/from the ER.
IPv6 can be deployed in a bridged CMTS network either natively or via
tunneling. This section discusses the native deployment model. The
tunneling model is similar to ones described in Sections 5.2.2.1 and
5.2.2.2.
Figure 5.2.1 illustrates the IPv6 deployment scenario.
+-----+ +-----+
|Host |--| GWR |
+-----+ +--+--+
| _ _ _ _ _ _
| +------+ | |
+--| CM |---| |
+------+ | |
| HFC | +------+ +--------+
| | | | | Edge |
+-----+ +------+ | Network |---| CMTS |--| |=>ISP
|Host |--| CM |---| | | | | Router |Network
+-----+ +------+ | | +------+ +--------+
|_ _ _ _ _ _|
|-------------||---------------------------------||---------------|
L3 Routed L2 Bridged L3 Routed
Figure 5.2.1
Asadullah, et al. Informational [Page 12]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
5.2.1.1. IPv6 Related Infrastructure Changes
In this scenario, the CM and the CMTS bridge all data traffic so they
will need to support bridging of native IPv6 unicast and multicast
traffic. The following devices have to be upgraded to dual stack:
Host, GWR, and ER.
5.2.1.2. Addressing
The proposed architecture for IPv6 deployment includes two components
that must be provisioned: the CM and the host. Additionally if there
is a GWR connected to the CM, it will also need to be provisioned.
The host or the GWR use the ER as their Layer 3 next hop.
5.2.1.2.1. IP Addressing for CM
The CM will be provisioned in the same way as in currently deployed
cable networks, using an IPv4 address on the cable interface
connected to the MSO network for management functions. During the
initialization phase, it will obtain its IPv4 address using Dynamic
Host Configuration Protocol (DHCPv4), and download a DOCSIS
configuration file identified by the DHCPv4 server.
5.2.1.2.2. IP Addressing for Hosts
If there is no GWR connected to the CM, the host behind the CM will
get a /64 prefix via stateless auto-configuration or DHCPv6.
If using stateless auto-configuration, the host listens for routing
advertisements (RAs) from the ER. The RAs contain the /64 prefix
assigned to the segment. Upon receipt of an RA, the host constructs
its IPv6 address by combining the prefix in the RA (/64) and a unique
identifier (e.g., its modified EUI-64 (64-bit Extended Unique
Identifier) format interface ID).
If DHCPv6 is used to obtain an IPv6 address, it will work in much the
same way as DHCPv4 works today. The DHCPv6 messages exchanged
between the host and the DHCPv6 server are bridged by the CM and the
CMTS.
5.2.1.2.3. IP Addressing for GWR
The GWR can use stateless auto-configuration (RA) to obtain an
address for its upstream interface, the link between itself and the
ER. This step is followed by a request via DHCP-PD (Prefix
Delegation) for a prefix shorter than /64, typically /48 [RFC3177],
which in turn is divided into /64s and assigned to its downstream
interfaces connecting to the hosts.
Asadullah, et al. Informational [Page 13]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
5.2.1.3. Data Forwarding
The CM and CMTS must be able to bridge native IPv6 unicast and
multicast traffic. The CMTS must provide IP connectivity between
hosts attached to CMs, and must do so in a way that meets the
expectation of Ethernet-attached customer equipment. In order to do
that, the CM and CMTS must forward Neighbor Discovery (ND) packets
between ER and the hosts attached to the CM.
Communication between hosts behind different CMs is always forwarded
through the CMTS. IPv6 communication between the different sites
relies on multicast IPv6 ND [RFC2461] frames being forwarded
correctly by the CM and the CMTS.
In order to support IPv6 multicast applications across DOCSIS cable
networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 or v1
snooping. MLD is almost identical to IGMP in IPv4, only the name and
numbers are changed. MLDv2 is identical to IGMPv3 and also supports
ASM (Any-Source Multicast) and SSM (Source-Specific Multicast)
service models. Implementation work on CM/CMTS should be minimal
because the only significant difference between IPv4 IGMPv3 and IPv6
MLDv2 is the longer addresses in the protocol.
5.2.1.4. Routing
The hosts install a default route that points to the ER or the GWR.
No routing protocols are needed on these devices, which generally
have limited resources. If there is a GWR present, it will also use
static default route to the ER.
The ER runs an IGP such as OSPFv3 or IS-IS. The connected prefixes
have to be redistributed. If DHCP-PD is used, with every delegated
prefix a static route is installed by the ER. For this reason, the
static routes must also be redistributed. Prefix summarization
should be done at the ER.
5.2.2. Deploying IPv6 in a Routed CMTS Network
In an IPv4/IPv6 routed CMTS network, the CM still acts as a Layer 2
device and bridges all data traffic between its Ethernet interface
and cable interface connected to the cable operator network. The
CMTS acts as a Layer 3 router and may also include the ER
functionality. The hosts and the GWR use the CMTS as their Layer 3
next hop.
When deploying IPv6, the CMTS/ER will need to either tunnel IPv6
traffic or natively support IPv6.
Asadullah, et al. Informational [Page 14]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
There are five possible deployment scenarios for IPv6 in a routed
CMTS network:
1. IPv4 Cable (HFC) Network
In this scenario, the cable network, including the CM and CMTS,
remain IPv4 devices. The host and ER are upgraded to dual stack.
This is the easiest way for a cable operator to provide IPv6 service,
as no changes are made to the cable network.
2. IPv4 Cable (HFC) Network, GWR at Customer Site
In this case, the cable network, including the CM and CMTS, remain
IPv4 devices. The host, GWR, and ER are upgraded to dual stack.
This scenario is also easy to deploy since the cable operator just
needs to add GWR at the customer site.
3. Dual-stacked Cable (HFC) Network, CM, and CMTS Support IPv6
In this scenario, the CMTS is upgraded to dual stack to support IPv4
and IPv6. Since the CMTS supports IPv6, it can act as an ER as well.
The CM will act as a Layer 2 bridge, but will need to bridge IPv6
unicast and multicast traffic. This scenario is not easy to deploy
since it requires changes to the DOCSIS specification. The CM and
CMTS may require hardware and software upgrades to support IPv6.
4. Dual-stacked Cable (HFC) Network, Standalone GWR, and CMTS
Support IPv6
In this scenario there is a stand-alone GWR connected to the CM.
Since the IPv6 functionality exists on the GWR, the CM does not need
to be dual stack. The CMTS is upgraded to dual stack and it can
incorporate the ER functionality. This scenario may also require
hardware and software changes on the GWR and CMTS.
5. Dual-stacked Cable (HFC) Network, Embedded GWR/CM, and CMTS
Support IPv6
In this scenario, the CM and GWR functionality exists on a single
device, which needs to be upgraded to dual stack. The CMTS will also
need to be upgraded to a dual-stack device. This scenario is also
difficult to deploy in existing cable network since it requires
changes on the Embedded GWR/CM and the CMTS.
The DOCSIS specification will also need to be modified to allow
native IPv6 support on the Embedded GWR/CM.
Asadullah, et al. Informational [Page 15]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
5.2.2.1. IPv4 Cable Network, Host, and ER Upgraded to Dual Stack
This is one of the most cost-effective ways for a cable operator to
offer IPv6 services to its customers. Since the cable network
remains IPv4, there is relatively minimal cost involved in turning up
IPv6 service. All IPv6 traffic is exchanged between the hosts and
the ER.
Figure 5.2.2.1 illustrates this deployment scenario.
+-----------+ +------+ +--------+
+-----+ +-------+ | Cable | | | | Edge |
|Host |--| CM |----| (HFC) |---| CMTS |---| |=>ISP
+-----+ +-------+ | Network | | | | Router |Network
+-----------+ +------+ +--------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel
|---------||---------------------------------------||------------|
IPv4/v6 IPv4 only IPv4/v6
Figure 5.2.2.1
5.2.2.1.1. IPv6 Related Infrastructure Changes
In this scenario, the CM and the CMTS will only need to support IPv4,
so no changes need to be made to them or the cable network. The
following devices have to be upgraded to dual stack: Host and ER.
5.2.2.1.2. Addressing
The only device that needs to be assigned an IPv6 address at the
customer site is the host. Host address assignment can be done in
multiple ways. Depending on the tunneling mechanism used, it could
be automatic or might require manual configuration.
The host still receives an IPv4 address using DHCPv4, which works the
same way in currently deployed cable networks. In order to get IPv6
connectivity, host devices will also need an IPv6 address and a means
to communicate with the ER.
Asadullah, et al. Informational [Page 16]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
5.2.2.1.3. Data Forwarding
All IPv6 traffic will be sent to/from the ER and the host device. In
order to transport IPv6 packets over the cable operator IPv4 network,
the host and the ER will need to use one of the available IPv6 in
IPv4 tunneling mechanisms.
The host will use its IPv4 address to source the tunnel to the ER.
All IPv6 traffic will be forwarded to the ER, encapsulated in IPv4
packets. The intermediate IPv4 nodes will forward this traffic as
regular IPv4 packets. The ER will need to terminate the tunnel
and/or provide other IPv6 services.
5.2.2.1.4. Routing
Routing configuration on the host will vary depending on the
tunneling technique used. In some cases, a default or static route
might be needed to forward traffic to the next hop.
The ER runs an IGP such as OSPFv3 or ISIS.
5.2.2.2. IPv4 Cable Network, Host, GWR and ER Upgraded to Dual Stack
The cable operator can provide IPv6 services to its customers, in
this scenario, by adding a GWR behind the CM. Since the GWR will
facilitate all IPv6 traffic between the host and the ER, the cable
network, including the CM and CMTS, does not need to support IPv6,
and can remain as IPv4 devices.
Figure 5.2.2.2 illustrates this deployment scenario.
+-----+
|Host |
+--+--+
| +-----------+ +------+ +--------+
+---+---+ +-------+ | Cable | | | | Edge |
| GWR |--| CM |----| (HFC) |---| CMTS |---| |=>ISP
+-------+ +-------+ | Network | | | | Router |Network
+-----------+ +------+ +--------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel
|---------||--------------------------------------||-------------|
IPv4/v6 IPv4 only IPv4/v6
Figure 5.2.2.2
Asadullah, et al. Informational [Page 17]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
5.2.2.2.1. IPv6 Related Infrastructure Changes
In this scenario, the CM and the CMTS will only need to support IPv4,
so no changes need to be made to them or the cable network. The
following devices have to be upgraded to dual stack: Host, GWR, and
ER.
5.2.2.2.2. Addressing
The only devices that need to be assigned an IPv6 address at customer
site are the host and GWR. IPv6 address assignment can be done
statically at the GWR downstream interface. The GWR will send out RA
messages on its downstream interface, which will be used by the hosts
to auto-configure themselves with an IPv6 address. The GWR can also
configure its upstream interface using RA messages from the ER and
use DHCP-PD for requesting a /48 [RFC3177] prefix from the ER. This
/48 prefix will be used to configure /64s on hosts connected to the
GWR downstream interfaces. The uplink to the ISP network is
configured with a /64 prefix as well.
The GWR still receives a global IPv4 address on its upstream
interface using DHCPv4, which works the same way in currently
deployed cable networks. In order to get IPv6 connectivity to the
Internet, the GWR will need to communicate with the ER.
5.2.2.2.3. Data Forwarding
All IPv6 traffic will be sent to/from the ER and the GWR, which will
forward IPv6 traffic to/from the host. In order to transport IPv6
packets over the cable operator IPv4 network, the GWR and the ER will
need to use one of the available IPv6 in IPv4 tunneling mechanisms.
All IPv6 traffic will need to go through the tunnel, once it comes
up.
The GWR will use its IPv4 address to source the tunnel to the ER.
The tunnel endpoint will be the IPv4 address of the ER. All IPv6
traffic will be forwarded to the ER, encapsulated in IPv4 packets.
The intermediate IPv4 nodes will forward this traffic as regular IPv4
packets. In case of 6to4 tunneling, the ER will need to support 6to4
relay functionality in order to provide IPv6 Internet connectivity to
the GWR, and hence, the hosts connected to the GWR.
5.2.2.2.4. Routing
Depending on the tunneling technique used, additional configuration
might be needed on the GWR and the ER. If the ER is also providing a
6to4 relay service then a default route will need to be added to the
GWR pointing to the ER, for all non-6to4 traffic.
Asadullah, et al. Informational [Page 18]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
If using manual tunneling, the GWR and ER can use static routing or
an IGP such as RIPng [RFC2080]. The RIPng updates can be transported
over a manual tunnel, which does not work when using 6to4 tunneling
since it does not support multicast.
Customer routes can be carried to the ER using RIPng updates. The ER
can advertise these routes in its IGP. Prefix summarization should
be done at the ER.
If DHCP-PD is used for address assignment, a static route is
automatically installed on the ER for each delegated /48 prefix. The
static routes need to be redistributed into the IGP at the ER, so
there is no need for a routing protocol between the ER and the GWR.
The ER runs an IGP such as OSPFv3 or ISIS.
5.2.2.3. Dual-Stacked Cable (HFC) Network, CM, and CMTS Support IPv6
In this scenario the cable operator can offer native IPv6 services to
its customers since the cable network, including the CMTS, supports
IPv6. The ER functionality can be included in the CMTS or it can
exist on a separate router connected to the CMTS upstream interface.
The CM will need to bridge IPv6 unicast and multicast traffic.
Figure 5.2.2.3 illustrates this deployment scenario.
+-----------+ +-------------+
+-----+ +-------+ | Cable | | CMTS / Edge |
|Host |--| CM |----| (HFC) |---| |=>ISP
+-----+ +-------+ | Network | | Router | Network
+-----------+ +-------------+
|-------||---------------------------||---------------|
IPv4/v6 IPv4/v6 IPv4/v6
Figure 5.2.2.3
5.2.2.3.1. IPv6 Related Infrastructure Changes
Since the CM still acts as a Layer 2 bridge, it does not need to be
dual stack. The CM will need to support bridging of IPv6 unicast and
multicast traffic and IGMPv3/MLDv2 or v1 snooping, which requires
changes in the DOCSIS specification. In this scenario, the following
devices have to be upgraded to dual stack: Host and CMTS/ER.
Asadullah, et al. Informational [Page 19]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
5.2.2.3.2. Addressing
In cable networks today, the CM receives a private IPv4 address using
DHCPv4 for management purposes. In an IPv6 environment, the CM will
continue to use an IPv4 address for management purposes. The cable
operator can also choose to assign an IPv6 address to the CM for
management, but the CM will have to be upgraded to support this
functionality.
IPv6 address assignment for the CM and host can be done via DHCP or
stateless auto-configuration. If the CM uses an IPv4 address for
management, it will use DHCPv4 for its address assignment and the
CMTS will need to act as a DHCPv4 relay agent. If the CM uses an
IPv6 address for management, it can use DHCPv6, with the CMTS acting
as a DHCPv6 relay agent, or the CMTS can be statically configured
with a /64 prefix and it can send out RA messages out the cable
interface. The CMs connected to the cable interface can use the RA
messages to auto-configure themselves with an IPv6 address. All CMs
connected to the cable interface will be in the same subnet.
The hosts can receive their IPv6 address via DHCPv6 or stateless
auto-configuration. With DHCPv6, the CMTS may need to act as a
DHCPv6 relay agent and forward DHCP messages between the hosts and
the DHCP server. With stateless auto-configuration, the CMTS will be
configured with multiple /64 prefixes and send out RA messages to the
hosts. If the CMTS is not also acting as an ER, the RA messages will
come from the ER connected to the CMTS upstream interface. The CMTS
will need to forward the RA messages downstream or act as an ND
proxy.
5.2.2.3.3. Data Forwarding
All IPv6 traffic will be sent to/from the CMTS and hosts. Data
forwarding will work the same way it works in currently deployed
cable networks. The CMTS will forward IPv6 traffic to/from hosts
based on the IP source/destination address.
5.2.2.3.4. Routing
No routing protocols are needed between the CMTS and the host since
the CM and host are directly connected to the CMTS cable interface.
Since the CMTS supports IPv6, hosts will use the CMTS as their Layer
3 next hop.
If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or
IS-IS.
Asadullah, et al. Informational [Page 20]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
5.2.2.4. Dual-Stacked Cable (HFC) Network, Stand-Alone GWR, and CMTS
Support IPv6
In this case, the cable operator can offer IPv6 services to its
customers by adding a GWR between the CM and the host. The GWR will
facilitate IPv6 communication between the host and the CMTS/ER. The
CMTS will be upgraded to dual stack to support IPv6 and can act as an
ER as well. The CM will act as a bridge for forwarding data traffic
and does not need to support IPv6.
This scenario is similar to the case described in Section 5.2.2.2.
The only difference in this case is that the ER functionality exists
on the CMTS instead of on a separate router in the cable operator
network.
Figure 5.2.2.4 illustrates this deployment scenario.
+-----------+ +-----------+
+------+ +-------+ +-------+ | Cable | |CMTS / Edge|
| Host |--| GWR |--| CM |---| (HFC) |---| |=>ISP
+------+ +-------+ +-------+ | Network | | Router |Network
+-----------+ +-----------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel
|-----------------||-----------------------------||--------------|
IPv4/v6 IPv4 IPv4/v6
Figure 5.2.2.4
5.2.2.4.1. IPv6 Related Infrastructure Changes
Since the CM still acts as a Layer 2 bridge, it does not need to be
dual stack, nor does it need to support IPv6. In this scenario, the
following devices have to be upgraded to dual stack: Host, GWR, and
CMTS/ER.
5.2.2.4.2. Addressing
The CM will still receive a private IPv4 address using DHCPv4, which
works the same way in existing cable networks. The CMTS will act as
a DHCPv4 relay agent.
The address assignment for the host and GWR happens in a similar
manner as described in Section 5.2.2.2.2.
Asadullah, et al. Informational [Page 21]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
5.2.2.4.3. Data Forwarding
Data forwarding between the host and CMTS/ER is facilitated by the
GWR and happens in a similar manner as described in Section
5.2.2.2.3.
5.2.2.4.4. Routing
In this case, routing is very similar to the case described in
Section 5.2.2.2.4. Since the CMTS now incorporates the ER
functionality, it will need to run an IGP such as OSPFv3 or IS-IS.
5.2.2.5. Dual-Stacked Cable (HFC) Network, Embedded GWR/CM, and CMTS
Support IPv6
In this scenario, the cable operator can offer native IPv6 services
to its customers since the cable network, including the CM/Embedded
GWR and CMTS, supports IPv6. The ER functionality can be included in
the CMTS or it can exist on a separate router connected to the CMTS
upstream interface. The CM/Embedded GWR acts as a Layer 3 device.
Figure 5.2.2.5 illustrates this deployment scenario.
+-----------+ +-------------+
+-----+ +-----------+ | Cable | | CMTS / Edge |
|Host |---| CM / GWR |---| (HFC) |---| |=>ISP
+-----+ +-----------+ | Network | | Router |Network
+-----------+ +-------------+
|---------------------------------------------------------|
IPv4/v6
Figure 5.2.2.5
5.2.2.5.1. IPv6 Related Infrastructure Changes
Since the CM/GWR acts as a Layer 3 device, IPv6 can be deployed end-
to-end. In this scenario, the following devices have to be upgraded
to dual stack: Host, CM/GWR, and CMTS/ER.
5.2.2.5.2. Addressing
Since the CM/GWR is dual stack, it can receive an IPv4 or IPv6
address using DHCP for management purposes. As the GWR functionality
is embedded in the CM, it will need an IPv6 address for forwarding
data traffic. IPv6 address assignment for the CM/GWR and host can be
done via DHCPv6 or DHCP-PD.
Asadullah, et al. Informational [Page 22]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
If using DHCPv6, the CMTS will need to act as a DHCPv6 relay agent.
The host and CM/GWR will receive IPv6 addresses from pools of /64
prefixes configured on the DHCPv6 server. The CMTS will need to
glean pertinent information from the DHCP Offer messages, sent from
the DHCP server to the DHCP clients (host and CM/GWR), much like it
does today in DHCPv4. All CM/GWR connected to the same cable
interface on the CMTS belong to the same management /64 prefix. The
hosts connected to the same cable interface on the CMTS may belong to
different /64 customer prefixes, as the CMTS may have multiple /64
prefixes configured under its cable interfaces.
It is also possible to use DHCP-PD for an IPv6 address assignment.
In this case, the CM/GWR will use stateless auto-configuration to
assign an IPv6 address to its upstream interface using the /64 prefix
sent by the CMTS/ER in an RA message. Once the CM/GWR assigns an
IPv6 address to its upstream interface, it will request a /48
[RFC3177] prefix from the CMTS/ER and chop this /48 prefix into /64s
for assigning IPv6 addresses to hosts. The uplink to the ISP network
is configured with a /64 prefix as well.
5.2.2.5.3. Data Forwarding
The host will use the CM/GWR as the Layer 3 next hop. The CM/GWR
will forward all IPv6 traffic to/from the CMTS/ER and hosts. The
CMTS/ER will forward IPv6 traffic to/from hosts based on the IP
source/destination address.
5.2.2.5.4. Routing
The CM/GWR can use a static default route pointing to the CMTS/ER or
it can run a routing protocol such as RIPng or OSPFv3 between itself
and the CMTS. Customer routes from behind the CM/GWR can be carried
to the CMTS using routing updates.
If DHCP-PD is used for address assignment, a static route is
automatically installed on the CMTS/ER for each delegated /48 prefix.
The static routes need to be redistributed into the IGP at the
CMTS/ER so there is no need for a routing protocol between the
CMTS/ER and the GWR.
If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or
IS-IS.
5.2.3. IPv6 Multicast
In order to support IPv6 multicast applications across DOCSIS cable
networks, the CM and bridging CMTS will need to support IGMPv3/MLDv2
or v1 snooping. MLD is almost identical to IGMP in IPv4, only the
Asadullah, et al. Informational [Page 23]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
name and numbers are changed. MLDv2 is almost identical to IGMPv3
and also supports ASM (Any-Source Multicast) and SSM (Source-Specific
Multicast) service models.
SSM is more suited for deployments where the SP intends to provide
paid content to the users (video or audio). These types of services
are expected to be of primary interest. Moreover, the simplicity of
the SSM model often overrides the scalability issues that would be
resolved in an ASM model. ASM is, however, an option that is
discussed in Section 6.3.1. The Layer 3 CM, GWR, and Layer 3 routed
CMTS/ER will need to be enabled with PIM-SSM, which requires the
definition and support for IGMPv3/MLDv1 or v2 snooping, in order to
track join/leave messages from the hosts. Another option would be
for the Layer 3 CM or GWR to support MLD proxy routing. The Layer 3
next hop for the hosts needs to support MLD.
Refer to Section 6.3 for more IPv6 multicast details.
5.2.4. IPv6 QoS
IPv6 will not change or add any queuing/scheduling functionality
already existing in DOCSIS specifications. But the QoS mechanisms on
the CMTS and CM would need to be IPv6 capable. This includes support
for IPv6 classifiers, so that data traffic to/from host devices can
be classified appropriately into different service flows and be
assigned appropriate priority. Appropriate classification criteria
would need to be implemented for unicast and multicast traffic.
Traffic classification and marking should be done at the CM for
upstream traffic and the CMTS/ER for downstream traffic, in order to
support the various types of services: data, voice, and video. The
same IPv4 QoS concepts and methodologies should be applied for IPv6
as well.
It is important to note that when traffic is encrypted end-to-end,
the traversed network devices will not have access to many of the
packet fields used for classification purposes. In these cases,
routers will most likely place the packets in the default classes.
The QoS design should take into consideration this scenario and try
to use mainly IP header fields for classification purposes.
5.2.5. IPv6 Security Considerations
Security in a DOCSIS cable network is provided using Baseline Privacy
Plus (BPI+). The only part that is dependent on IP addresses is
encrypted multicast. Semantically, multicast encryption would work
the same way in an IPv6 environment as in the IPv4 network. However,
Asadullah, et al. Informational [Page 24]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
appropriate enhancements will be needed in the DOCSIS specification
to support encrypted IPv6 multicast.
There are limited changes that have to be done for hosts in order to
enhance security. The privacy extensions [RFC3041] for auto-
configuration should be used by the hosts. IPv6 firewall functions
could be enabled, if available on the host or GWR.
The ISP provides security against attacks that come from its own
subscribers, but it could also implement security services that
protect its subscribers from attacks sourced from the outside of its
network. Such services do not apply at the access level of the
network discussed here.
The CMTS/ER should protect the ISP network and the other subscribers
against attacks by one of its own customers. For this reason Unicast
Reverse Path Forwarding (uRPF) [RFC3704] and Access Control Lists
(ACLs) should be used on all interfaces facing subscribers.
Filtering should be implemented with regard for the operational
requirements of IPv6 [IPv6-Security].
The CMTS/ER should protect its processing resources against floods of
valid customer control traffic such as: Router and Neighbor
Solicitations, and MLD Requests.
All other security features used with the IPv4 service should be
similarly applied to IPv6 as well.
5.2.6. IPv6 Network Management
IPv6 can have many applications in cable networks. MSOs can
initially implement IPv6 on the control plane and use it to manage
the thousands of devices connected to the CMTS. This would be a good
way to introduce IPv6 in a cable network. Later, the MSO can extend
IPv6 to the data plane and use it to carry customer traffic as well
as management traffic.
5.2.6.1. Using IPv6 for Management in Cable Networks
IPv6 can be enabled in a cable network for management of devices like
CM, CMTS, and ER. With the rollout of advanced services like VoIP
and Video-over-IP, MSOs are looking for ways to manage the large
number of devices connected to the CMTS. In IPv4, an RFC1918 address
is assigned to these devices for management purposes. Since there is
a finite number of RFC1918 addresses available, it is becoming
difficult for MSOs to manage these devices.
Asadullah, et al. Informational [Page 25]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
By using IPv6 for management purposes, MSOs can scale their network
management systems to meet their needs. The CMTS/ER can be
configured with a /64 management prefix that is shared among all CMs
connected to the CMTS cable interface. Addressing for the CMs can be
done via stateless auto-configuration or DHCPv6. Once the CMs
receive a /64 prefix, they can configure themselves with an IPv6
address.
If there are devices behind the CM that need to be managed by the
MSO, another /64 prefix can be defined on the CMTS/ER. These devices
can also use stateless auto-configuration to assign themselves an
IPv6 address.
Traffic sourced from or destined to the management prefix should not
cross the MSO's network boundaries.
In this scenario, IPv6 will only be used for managing devices on the
cable network. The CM will no longer require an IPv4 address for
management as described in DOCSIS 3.0 [DOCSIS3.0-Reqs].
5.2.6.2. Updates to MIB Modules/Standards to Support IPv6
The current DOCSIS, PacketCable, and CableHome MIB modules are
already designed to support IPv6 objects. In this case, IPv6 will
neither add nor change any of the functionality of these MIB modules.
The Textual Convention used to represent Structure of Management
Information Version 2 (SMIv2) objects representing IP addresses was
updated [RFC4001] and a new Textual Convention InetAddressType was
added to identify the type of the IP address used for IP address
objects in MIB modules.
There are some exceptions; the MIB modules that might need to add
IPv6 support are defined in the DOCSIS 3.0 OSSI specification
[DOCSIS3.0-OSSI].
6. Broadband DSL Networks
This section describes the IPv6 deployment options in today's high-
speed DSL networks.
6.1. DSL Network Elements
Digital Subscriber Line (DSL) broadband services provide users with
IP connectivity over the existing twisted-pair telephone lines called
the local-loop. A wide range of bandwidth offerings are available
depending on the quality of the line and the distance between the
Customer Premise Equipment and the DSL Access Multiplexer (DSLAM).
Asadullah, et al. Informational [Page 26]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
The following network elements are typical of a DSL network:
DSL Modem: It can be a stand-alone device, be incorporated in the
host, incorporate router functionalities, and also have the
capability to act as a CPE router.
Customer Premise Router (CPR): It is used to provide Layer 3 services
for customer premise networks. It is usually used to provide
firewalling functions and segment broadcast domains for a small
business.
DSL Access Multiplexer (DSLAM): It terminates multiple twisted-pair
telephone lines and provides aggregation to BRAS.
Broadband Remote Access Server (BRAS): It aggregates or terminates
multiple Permanent Virtual Circuits (PVCs) corresponding to the
subscriber DSL circuits.
Edge Router (ER): It provides the Layer 3 interface to the ISP
network.
Figure 6.1 depicts all the network elements mentioned.
Customer Premise | Network Access Provider | Network Service Provider
CP NAP NSP
+-----+ +------+ +------+ +--------+
|Hosts|--|Router| +--+ BRAS +---+ Edge | ISP
+-----+ +--+---+ | | | | Router +==> Network
| | +------+ +--------+
+--+---+ |
| DSL +-+ |
|Modem | | |
+------+ | +-----+ |
+--+ | |
+------+ |DSLAM+--+
+-----+ | DSL | +--+ |
|Hosts|--+Modem +-+ +-----+
+-----+ +--+---+
Figure 6.1
Asadullah, et al. Informational [Page 27]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
6.2. Deploying IPv6 in IPv4 DSL Networks
There are three main design approaches to providing IPv4 connectivity
over a DSL infrastructure:
1. Point-to-Point Model: Each subscriber connects to the DSLAM over
a twisted pair and is provided with a unique PVC that links it to
the service provider. The PVCs can be terminated at the BRAS or
at the Edge Router. This type of design is not very scalable if
the PVCs are not terminated as close as possible to the DSLAM (at
the BRAS). In this case, a large number of Layer 2 circuits has
to be maintained over a significant portion of the network. The
Layer 2 domains can be terminated at the ER in three ways:
A. In a common bridge group with a virtual interface that routes
traffic out.
B. By enabling a Routed Bridged Encapsulation feature, all users
could be part of the same subnet. This is the most common
deployment approach of IPv4 over DSL but it might not be the
best choice in IPv6 where address availability is not an
issue.
C. By terminating the PVC at Layer 3, each PVC has its own
prefix. This is the approach that seems more suitable for
IPv6 and is presented in Section 6.2.1.
None of these ways requires that the CPE (DSL modem) be
upgraded.
2. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened
between each subscriber and the BRAS. The BRAS terminates the
PPP sessions and provides Layer 3 connectivity between the
subscriber and the ISP. This model is presented in Section
6.2.2.
3. Layer 2 Tunneling Protocol (L2TP) Access Aggregation (LAA) Model:
PPP sessions are opened between each subscriber and the ISP Edge
Router. The BRAS tunnels the subscriber PPP sessions to the ISP
by encapsulating them into L2TPv2 [RFC2661] tunnels. This model
is presented in Section 6.2.3.
In aggregation models, the BRAS terminates the subscriber PVCs and
aggregates their connections before providing access to the ISP.
In order to maintain the deployment concepts and business models
proven and used with existing revenue generating IPv4 services, the
IPv6 deployment will match the IPv4 one. This approach is presented
Asadullah, et al. Informational [Page 28]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
in Sections 6.2.1 - 6.2.3 that describe current IPv4 over DSL
broadband access deployments. Under certain circumstances where new
service types or service needs justify it, IPv4 and IPv6 network
logical architectures could be different as described in Section
6.2.4.
6.2.1. Point-to-Point Model
In this scenario, the Ethernet frames from the Host or the Customer
Premise Router are bridged over the PVC assigned to the subscriber.
Figure 6.2.1 describes the protocol architecture of this model.
Customer Premise NAP NSP
|-------------------------| |---------------| |------------------|
+-----+ +-------+ +-----+ +--------+ +----------+
|Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP
+-----+ +-------+ |Modem| +--------+ | Router +=>Network
+-----+ +----------+
|----------------------------|
ATM
Figure 6.2.1
6.2.1.1. IPv6 Related Infrastructure Changes
In this scenario, the DSL modem and the entire NAP is Layer 3
unaware, so no changes are needed to support IPv6. The following
devices have to be upgraded to dual stack: Host, Customer Router (if
present), and Edge Router.
6.2.1.2. Addressing
The Hosts or the Customer Routers have the Edge Router as their Layer
3 next hop.
If there is no Customer Router, all the hosts on the subscriber site
belong to the same /64 subnet that is statically configured on the
Edge Router for that subscriber PVC. The hosts can use stateless
auto-configuration or stateful DHCPv6-based configuration to acquire
an address via the Edge Router.
However, as manual configuration for each customer is a provisioning
challenge, implementers are encouraged to develop mechanism(s) that
automatically map the PVC (or some other customer-specific
information) to an IPv6 subnet prefix, and advertise the customer-
specific prefix to all the customers with minimal configuration.
Asadullah, et al. Informational [Page 29]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
If a Customer Router is present:
A. It is statically configured with an address on the /64 subnet
between itself and the Edge Router, and with /64 prefixes on the
interfaces connecting the hosts on the customer site. This is
not a desired provisioning method being expensive and difficult
to manage.
B. It can use its link-local address to communicate with the ER. It
can also dynamically acquire, through stateless auto-
configuration, the prefix for the link between itself and the ER.
The later option allows it to contact a remote DHCPv6 server, if
needed. This step is followed by a request via DHCP-PD for a
prefix shorter than /64 that, in turn, is divided in /64s and
assigned to its downstream interfaces.
The Edge Router has a /64 prefix configured for each subscriber PVC.
Each PVC should be enabled to relay DHCPv6 requests from the
subscribers to DHCPv6 servers in the ISP network. The PVCs providing
access for subscribers that use DHCP-PD as well, have to be enabled
to support the feature. The uplink to the ISP network is configured
with a /64 prefix as well.
The prefixes used for subscriber links and the ones delegated via
DHCP-PD should be planned in a manner that allows as much
summarization as possible at the Edge Router.
Other information of interest to the host, such as DNS, is provided
through stateful DHCPv6 [RFC3315] and stateless DHCPv6 [RFC3736].
6.2.1.3. Routing
The CPE devices are configured with a default route that points to
the Edge Router. No routing protocols are needed on these devices,
which generally have limited resources.
The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS.
The connected prefixes have to be redistributed. If DHCP-PD is used,
with every delegated prefix a static route is installed by the Edge
Router. For this reason, the static routes must also be
redistributed. Prefix summarization should be done at the Edge
Router.
6.2.2. PPP Terminated Aggregation (PTA) Model
The PTA architecture relies on PPP-based protocols (PPPoA [RFC2364]
and PPPoE [RFC2516]). The PPP sessions are initiated by Customer
Premise Equipment and are terminated at the BRAS. The BRAS
Asadullah, et al. Informational [Page 30]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
authorizes the session, authenticates the subscriber, and provides an
IP address on behalf of the ISP. The BRAS then does Layer 3 routing
of the subscriber traffic to the NSP Edge Router.
When the NSP is also the NAP, the BRAS and NSP Edge Router could be
the same piece of equipment and provide the above mentioned
functionality.
There are two types of PPP encapsulations that can be leveraged with
this model:
A. Connection using PPPoA
Customer Premise NAP NSP
|--------------------| |----------------------| |----------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
+-----+ +-------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
|--------------------------| +-----------+
PPP
Figure 6.2.2.1
The PPP sessions are initiated by the Customer Premise Equipment.
The BRAS authenticates the subscriber against a local or a remote
database. Once the session is established, the BRAS provides an
address and maybe a DNS server to the user; this information is
acquired from the subscriber profile or from a DHCP server.
This solution scales better then the Point-to-Point, but since there
is only one PPP session per ATM PVC, the subscriber can choose a
single ISP service at a time.
Asadullah, et al. Informational [Page 31]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
B. Connection using PPPoE
Customer Premise NAP NSP
|--------------------------| |-------------------| |---------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
|
+-----+ +-------+ +--------+ +-----+----+ +-----------+
|Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +----------+ | Router +=>O
| | R
|--------------------------------| +-----------+ E
PPP
Figure 6.2.2.2
The operation of PPPoE is similar to PPPoA with the exception that
with PPPoE multiple sessions can be supported over the same PVC, thus
allowing the subscriber to connect to multiple services at the same
time. The hosts can initiate the PPPoE sessions as well. It is
important to remember that the PPPoE encapsulation reduces the IP MTU
available for the customer traffic due to additional headers.
The network design and operation of the PTA model is the same,
regardless of the PPP encapsulation type used.
6.2.2.1. IPv6 Related Infrastructure Changes
In this scenario the BRAS is Layer 3 aware and it has to be upgraded
to support IPv6. Since the BRAS terminates the PPP sessions it has
to support the implementation of these PPP protocols with IPv6. The
following devices have to be upgraded to dual stack: Host, Customer
Router (if present), BRAS, and Edge Router.
6.2.2.2. Addressing
The BRAS terminates the PPP sessions and provides the subscriber with
an IPv6 address from the defined pool for that profile. The
subscriber profile for authorization and authentication can be
located on the BRAS or on an Authentication, Authorization, and
Accounting (AAA) server. The Hosts or the Customer Routers have the
BRAS as their Layer 3 next hop.
Asadullah, et al. Informational [Page 32]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
The PPP session can be initiated by a host or by a Customer Router.
In the latter case, once the session is established with the BRAS and
an address is negotiated for the uplink to the BRAS, DHCP-PD can be
used to acquire prefixes for the Customer Router other interfaces.
The BRAS has to be enabled to support DHCP-PD and to relay the DHCPv6
requests of the hosts on the subscriber sites.
The BRAS has /64 prefixes configured on the link to the Edge router.
The Edge Router links are also configured with /64 prefixes to
provide connectivity to the rest of the ISP network.
The prefixes used for subscribers and the ones delegated via DHCP-PD
should be planned in a manner that allows maximum summarization at
the BRAS.
Other information of interest to the host, such as DNS, is provided
through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
6.2.2.3. Routing
The CPE devices are configured with a default route that points to
the BRAS router. No routing protocols are needed on these devices,
which generally have limited resources.
The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the
addresses assigned to the PPP sessions are represented as connected
host routes, connected prefixes have to be redistributed. If DHCP-PD
is used, with every delegated prefix a static route is installed by
the Edge Router. For this reason, the static routes must also be
redistributed. Prefix summarization should be done at the BRAS.
The Edge Router is running the IGP used in the ISP network: OSPFv3 or
IS-IS.
A separation between the routing domains of the ISP and the Access
Provider is recommended if they are managed independently.
Controlled redistribution will be needed between the Access Provider
IGP and the ISP IGP.
6.2.3. L2TPv2 Access Aggregation (LAA) Model
In the LAA model, the BRAS forwards the CPE initiated session to the
ISP over an L2TPv2 tunnel established between the BRAS and the Edge
Router. In this case, the authentication, authorization, and
subscriber configuration are performed by the ISP itself. There are
two types of PPP encapsulations that can be leveraged with this
model:
Asadullah, et al. Informational [Page 33]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
A. Connection via PPPoA
Customer Premise NAP NSP
|--------------------| |----------------------| |----------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
|----------------------------------------|
PPP
|------------|
L2TPv2
Figure 6.2.3.1
B. Connection via PPPoE
Customer Premise NAP NSP
|--------------------------| |--------------------| |---------------|
+-----------+
| AAA |
+------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +----+------+
|Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +----------+ | Router +=>O
| | R
+-----------+ E
|-----------------------------------------------|
PPP
|--------------|
L2TPv2
Figure 6.2.3.2
The network design and operation of the PTA model is the same,
regardless of the PPP encapsulation type used.
Asadullah, et al. Informational [Page 34]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
6.2.3.1. IPv6 Related Infrastructure Changes
In this scenario, the BRAS is forwarding the PPP sessions initiated
by the subscriber over the L2TPv2 tunnel established to the L2TP
Network Server (LNS), the aggregation point in the ISP network. The
L2TPv2 tunnel between the L2TP Access Concentrator (LAC) and LNS can
run over IPv6 or IPv4. These capabilities have to be supported on
the BRAS. The following devices have to be upgraded to dual stack:
Host, Customer Router, and Edge Router. If the tunnel is set up over
IPv6, then the BRAS must be upgraded to dual stack.
6.2.3.2. Addressing
The Edge Router terminates the PPP sessions and provides the
subscriber with an IPv6 address from the defined pool for that
profile. The subscriber profile for authorization and authentication
can be located on the Edge Router or on an AAA server. The Hosts or
the Customer Routers have the Edge Router as their Layer 3 next hop.
The PPP session can be initiated by a host or by a Customer Router.
In the latter case, once the session is established with the Edge
Router, DHCP-PD can be used to acquire prefixes for the Customer
Router interfaces. The Edge Router has to be enabled to support
DHCP-PD and to relay the DHCPv6 requests generated by the hosts on
the subscriber sites.
The BRAS has a /64 prefix configured on the link to the Edge Router.
The Edge Router links are also configured with /64 prefixes to
provide connectivity to the rest of the ISP network. Other
information of interest to the host, such as DNS, is provided through
stateful [RFC3315] and stateless [RFC3736] DHCPv6.
It is important to note here a significant difference between this
deployment for IPv6 versus IPv4. In the case of IPv4, the customer
router or CPE can end up on any Edge Router (acting as LNS), where
the assumption is that there are at least two of them for redundancy
purposes. Once authenticated, the customer will be given an address
from the IP pool of the ER (LNS) it connected to. This allows the
ERs (LNSs) to aggregate the addresses handed out to the customers.
In the case of IPv6, an important constraint that likely will be
enforced is that the customer should keep its own address, regardless
of the ER (LNS) it connects to. This could significantly reduce the
prefix aggregation capabilities of the ER (LNS). This is different
than the current IPv4 deployment where addressing is dynamic in
nature, and the same user can get different addresses depending on
the LNS it ends up connecting to.
Asadullah, et al. Informational [Page 35]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
One possible solution is to ensure that a given BRAS will always
connect to the same ER (LNS) unless that LNS is down. This means
that customers from a given prefix range will always be connected to
the same ER (primary, if up, or secondary, if not). Each ER (LNS)
can carry summary statements in their routing protocol configuration
for the prefixes for which they are the primary ER (LNS), as well as
for the ones for which they are the secondary. This way the prefixes
will be summarized any time they become "active" on the ER (LNS).
6.2.3.3. Routing
The CPE devices are configured with a default route that points to
the Edge Router that terminates the PPP sessions. No routing
protocols are needed on these devices, which generally have limited
resources.
The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS.
Different processes should be used if the NAP and the NSP are managed
by different organizations. In this case, controlled redistribution
should be enabled between the two domains.
The Edge Router is running the IPv6 IGP used in the ISP network:
OSPFv3 or IS-IS.
6.2.4. Hybrid Model for IPv4 and IPv6 Service
It was recommended throughout this section that the IPv6 service
implementation should map the existing IPv4 one. This approach
simplifies manageability and minimizes training needed for personnel
operating the network. In certain circumstances such mapping is not
feasible. This typically becomes the case when a Service Provider
plans to expand its service offering with the new IPv6 deployed
infrastructure. If this new service is not well supported in a
network design such as the one used for IPv4, then a different design
might be used for IPv6.
An example of such circumstances is that of a provider using an LAA
design for its IPv4 services. In this case all the PPP sessions are
bundled and tunneled across the entire NAP infrastructure which is
made of multiple BRAS routers, aggregation routers etc. The end
point of these tunnels is the ISP Edge Router. If the provider
decides to offer multicast services over such a design, it will face
the problem of NAP resources being over utilized. The multicast
traffic can be replicated only at the end of the tunnels by the Edge
Router and the copies for all the subscribers are carried over the
entire NAP.
Asadullah, et al. Informational [Page 36]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
A Modified Point-to-Point (as described in Section 6.2.4.2) or PTA
model is more suitable to support multicast services because the
packet replication can be done closer to the destination at the BRAS.
Such topology saves NAP resources.
In this sense, IPv6 deployment can be viewed as an opportunity to
build an infrastructure that might better support the expansion of
services. In this case, an SP using the LAA design for its IPv4
services might choose a modified Point-to-Point or PTA design for
IPv6.
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
relatively straightforward. The PPP sessions are terminated on
different network devices for the IPv4 and IPv6 services. The PPP
sessions for the existing IPv4 service deployed in an LAA model are
terminated on the Edge Router. The PPP sessions for the new IPv6
service deployed in a PTA model are terminated on the BRAS.
The logical design for IPv6 and IPv4 in this hybrid model is
presented in Figure 6.2.4.1.
IPv6 |--------------------------|
PPP +-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
Figure 6.2.4.1
6.2.4.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
IPv6 service is a modified version of the model described in section
6.2.1.
Asadullah, et al. Informational [Page 37]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
For the IPv4 service in the LAA model, the PVCs are terminated on the
BRAS and PPP sessions are terminated on the Edge Router (LNS). For
IPv6 service in the Point-to-Point model, the PVCs are terminated at
the Edge Router as described in Section 6.2.1. In this hybrid model,
the Point-to-Point link could be terminated on the BRAS, a NAP-owned
device. The IPv6 traffic is then routed through the NAP network to
the NSP. In order to have this hybrid model, the BRAS has to be
upgraded to a dual-stack router. The functionalities of the Edge
Router, as described in Section 6.2.1, are now implemented on the
BRAS.
The other aspect of this deployment model is the fact that the BRAS
has to be capable of distinguishing between the IPv4 PPP traffic that
has to be bridged across the L2TPv2 tunnel and the IPv6 packets that
have to be routed to the NSP. The IPv6 Routing and Bridging
Encapsulation (RBE) has to be enabled on all interfaces with PVCs
supporting both IPv4 and IPv6 services in this hybrid design.
The logical design for IPv6 and IPv4 in this hybrid model is
presented in Figure 6.2.4.2.
IPv6 |----------------|
ATM +-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
Figure 6.2.4.2
6.3. IPv6 Multicast
The deployment of IPv6 multicast services relies on MLD, identical to
IGMP in IPv4 and on PIM for routing. ASM (Any Source Multicast) and
SSM (Single Source Multicast) service models operate almost the same
as in IPv4. Both have the same benefits and disadvantages as in
IPv4. Nevertheless, the larger address space and the scoped address
architecture provide major benefits for multicast IPv6. Through RFC
3306, the large address space provides the means to assign global
Asadullah, et al. Informational [Page 38]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
multicast group addresses to organizations or users that were
assigned unicast prefixes. It is a significant improvement with
respect to the IPv4 GLOP mechanism [RFC3180].
This facilitates the deployment of multicast services. The
discussion of this section applies to all the multicast sections in
the document.
6.3.1. ASM-Based Deployments
Any Source Multicast (ASM) is useful for Service Providers that
intend to support the forwarding of multicast traffic of their
customers. It is based on the Protocol Independent Multicast -
Sparse Mode (PIM-SM) protocol and it is more complex to manage
because of the use of Rendezvous Points (RPs). With IPv6, static RP
and Bootstrap Router [BSR] can be used for RP-to-group mapping
similar to IPv4. Additionally, the larger IPv6 address space allows
for building up of group addresses that incorporate the address of
the RP. This RP-to-group mapping mechanism is called Embedded RP and
is specific to IPv6.
In inter-domain deployments, Multicast Source Discovery Protocol
(MSDP) [RFC3618] is an important element of IPv4 PIM-SM deployments.
MSDP is meant to be a solution for the exchange of source
registration information between RPs in different domains. This
solution was intended to be temporary. This is one of the reasons
why it was decided not to implement MSDP in IPv6 [IPv6-Multicast].
For multicast reachability across domains, Embedded RP can be used.
As Embedded RP provides roughly the same capabilities as MSDP, but in
a slightly different way, the best management practices for ASM
multicast with embedded RP still remain to be developed.
6.3.2. SSM-Based Deployments
Based on PIM-SSM, the Source-Specific Multicast deployments do not
need an RP or related protocols (such as BSR or MSDP), but rely on
the listeners to know the source of the multicast traffic they plan
to receive. The lack of RP makes SSM not only simpler to operate,
but also robust; it is not impacted by RP failures or inter-domain
constraints. It also has a higher level of security (no RP to be
targeted by attacks). For more discussions on the topic of IPv6
multicast, see [IPv6-Multicast].
The typical multicast service offered for residential and very small
businesses is video/audio streaming, where the subscriber joins a
multicast group and receives the content. This type of service model
is well supported through PIM-SSM which is very simple and easy to
Asadullah, et al. Informational [Page 39]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
manage. PIM-SSM has to be enabled throughout the SP network. MLDv2
is required for PIM-SSM support. Vendors can choose to implement
features that allow routers to map MLDv1 group joins to predefined
sources.
Subscribers might use a set-top box that is responsible for the
control piece of the multicast service (does group joins/leaves).
The subscriber hosts can also join desired multicast groups as long
as they are enabled to support MLDv1 or MLDv2. If a customer premise
router is used, then it has to be enabled to support MLDv1 and MLDv2
in order to process the requests of the hosts. It has to be enabled
to support PIM-SSM in order to send PIM joins/leaves up to its Layer
3 next hop whether it is the BRAS or the Edge Router. When enabling
this functionality on a CPR, its limited resources should be taken
into consideration. Another option would be for the CPR to support
MLD proxy routing.
The router that is the Layer 3 next hop for the subscriber (BRAS in
the PTA model or the Edge Router in the LAA and Point-to-Point model)
has to be enabled to support MLDv1 and MLDv2 in order to process the
requests coming from subscribers without CPRs. It has to be enabled
for PIM-SSM in order to receive joins/leaves from customer routers
and send joins/leaves to the next hop towards the multicast source
(Edge Router or the NSP core).
MLD authentication, authorization and accounting are usually
configured on the Edge Router in order to enable the ISP to control
the subscriber access of the service and do billing for the content
provided. Alternative mechanisms that would support these functions
should be investigated further.
6.4. IPv6 QoS
The QoS configuration is particularly relevant on the router that
represents the Layer 3 next hop for the subscriber (BRAS in the PTA
model or the Edge Router in the LAA and Point-to-Point model) in
order to manage resources shared amongst multiple subscribers,
possibly with various service level agreements.
In the DSL infrastructure, it is expected that there is already a
level of traffic policing and shaping implemented for IPv4
connectivity. This is implemented throughout the NAP and is beyond
the scope of this document.
On the BRAS or the Edge Router, the subscriber-facing interfaces have
to be configured to police the inbound customer traffic and shape the
traffic outbound to the customer based on the service level
agreements (SLAs). Traffic classification and marking should also be
Asadullah, et al. Informational [Page 40]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
done on the router closest (at Layer 3) to the subscriber in order to
support the various types of customer traffic (data, voice, and
video) and to optimally use the infrastructure resources. Each
provider (NAP, NSP) could implement their own QoS policies and
services so that reclassification and marking might be performed at
the boundary between the NAP and the NSP, in order to make sure the
traffic is properly handled by the ISP. The same IPv4 QoS concepts
and methodologies should be applied with IPv6 as well.
It is important to note that when traffic is encrypted end-to-end,
the traversed network devices will not have access to many of the
packet fields used for classification purposes. In these cases,
routers will most likely place the packets in the default classes.
The QoS design should take into consideration this scenario and try
to use mainly IP header fields for classification purposes.
6.5. IPv6 Security Considerations
There are limited changes that have to be done for CPEs in order to
enhance security. The privacy extensions for auto-configuration
[RFC3041] should be used by the hosts. ISPs can track the prefixes
it assigns to subscribers relatively easily. If, however, the ISPs
are required by regulations to track their users at a /128 address
level, the privacy extensions may be implemented in parallel with
network management tools that could provide traceability of the
hosts. IPv6 firewall functions should be enabled on the hosts or
CPR, if present.
The ISP provides security against attacks that come from its own
subscribers but it could also implement security services that
protect its subscribers from attacks sourced from the outside of its
network. Such services do not apply at the access level of the
network discussed here.
The device that is the Layer 3 next hop for the subscribers (BRAS or
Edge Router) should protect the network and the other subscribers
against attacks by one of the provider customers. For this reason,
uRPF and ACLs should be used on all interfaces facing subscribers.
Filtering should be implemented with regard for the operational
requirements of IPv6 [IPv6-Security].
The BRAS and the Edge Router should protect their processing
resources against floods of valid customer control traffic such as:
Router and Neighbor Solicitations, and MLD Requests. Rate limiting
should be implemented on all subscriber-facing interfaces. The
emphasis should be placed on multicast-type traffic, as it is most
often used by the IPv6 control plane.
Asadullah, et al. Informational [Page 41]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
All other security features used with the IPv4 service should be
similarly applied to IPv6 as well.
6.6. IPv6 Network Management
The necessary instrumentation (such as MIB modules, NetFlow Records,
etc.) should be available for IPv6.
Usually, NSPs manage the edge routers by SNMP. The SNMP transport
can be done over IPv4 if all managed devices have connectivity over
both IPv4 and IPv6. This would imply the smallest changes to the
existing network management practices and processes. Transport over
IPv6 could also be implemented, and it might become necessary if IPv6
only islands are present in the network. The management applications
may be running on hosts belonging to the NSP core network domain.
Network Management Applications should handle IPv6 in a similar
fashion to IPv4; however, they should also support features specific
to IPv6 (such as neighbor monitoring).
In some cases, service providers manage equipment located on
customers' LANs. The management of equipment at customers' LANs is
out of scope of this memo.
7. Broadband Ethernet Networks
This section describes the IPv6 deployment options in currently
deployed Broadband Ethernet Access Networks.
7.1. Ethernet Access Network Elements
In environments that support the infrastructure deploying RJ-45 or
fiber (Fiber to the Home (FTTH) service) to subscribers, 10/100 Mbps
Ethernet broadband services can be provided. Such services are
generally available in metropolitan areas in multi-tenant buildings
where an Ethernet infrastructure can be deployed in a cost-effective
manner. In such environments, Metro-Ethernet services can be used to
provide aggregation and uplink to a Service Provider.
The following network elements are typical of an Ethernet network:
Access Switch: It is used as a Layer 2 access device for subscribers.
Customer Premise Router: It is used to provide Layer 3 services for
customer premise networks.
Aggregation Ethernet Switches: Aggregates multiple subscribers.
Broadband Remote Access Server (BRAS)
Asadullah, et al. Informational [Page 42]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
Edge Router (ER)
Figure 7.1 depicts all the network elements mentioned.
Customer Premise | Network Access Provider | Network Service Provider
CP NAP NSP
+-----+ +------+ +------+ +--------+
|Hosts|--|Router| +-+ BRAS +--+ Edge | ISP
+-----+ +--+---+ | | | | Router +===> Network
| | +------+ +--------+
+--+----+ |
|Access +-+ |
|Switch | | |
+-------+ | +------+ |
+--+Agg E | |
+-------+ |Switch+-+
+-----+ |Access | +--+ |
|Hosts|--+Switch +-+ +------+
+-----+ +-------+
Figure 7.1
The logical topology and design of Broadband Ethernet Networks are
very similar to DSL Broadband Networks discussed in Section 6.
It is worth noting that the general operation, concepts and
recommendations described in this section apply similarly to a
HomePNA-based network environment. In such an environment, some of
the network elements might be differently named.
7.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks
There are three main design approaches to providing IPv4 connectivity
over an Ethernet infrastructure:
A. Point-to-Point Model: Each subscriber connects to the network
Access switch over RJ-45 or fiber links. Each subscriber is
assigned a unique VLAN on the access switch. The VLAN can be
terminated at the BRAS or at the Edge Router. The VLANs are
802.1Q trunked to the Layer 3 device (BRAS or Edge Router).
This model is presented in Section 7.2.1.
Asadullah, et al. Informational [Page 43]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
B. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened
between each subscriber and the BRAS. The BRAS terminates the
PPP sessions and provides Layer 3 connectivity between the
subscriber and the ISP.
This model is presented in Section 7.2.2.
C. L2TPv2 Access Aggregation (LAA) Model: PPP sessions are opened
between each subscriber and the ISP termination devices. The
BRAS tunnels the subscriber PPP sessions to the ISP by
encapsulating them into L2TPv2 tunnels.
This model is presented in Section 7.2.3.
In aggregation models the BRAS terminates the subscriber VLANs and
aggregates their connections before providing access to the ISP.
In order to maintain the deployment concepts and business models
proven and used with existing revenue generating IPv4 services, the
IPv6 deployment will match the IPv4 one. This approach is presented
in Sections 7.2.1 - 7.2.3 that describe currently deployed IPv4 over
Ethernet broadband access deployments. Under certain circumstances
where new service types or service needs justify it, IPv4 and IPv6
network architectures could be different as described in Section
7.2.4.
7.2.1. Point-to-Point Model
In this scenario, the Ethernet frames from the Host or the Customer
Premise Router are bridged over the VLAN assigned to the subscriber.
Figure 7.2.1 describes the protocol architecture of this model.
| Customer Premise | | NAP | NSP |
+-----+ +------+ +------+ +--------+ +----------+
|Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP
+-----+ +------+ |Switch| +--------+ 802.1Q | Router +=>Network
+------+ +----------+
|----------------------------|
Ethernet/VLANs
Figure 7.2.1
Asadullah, et al. Informational [Page 44]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
7.2.1.1. IPv6 Related Infrastructure Changes
In this scenario, the Access Switch is on the customer site and the
entire NAP is Layer 3 unaware, so no changes are needed to support
IPv6. The following devices have to be upgraded to dual stack: Host,
Customer Router, and Edge Router.
The Access switches might need upgrades to support certain IPv6-
related features such as MLD Snooping.
7.2.1.2. Addressing
The Hosts or the Customer Routers have the Edge Router as their Layer
3 next hop. If there is no Customer Router all the hosts on the
subscriber site belong to the same /64 subnet that is statically
configured on the Edge Router for that subscriber VLAN. The hosts
can use stateless auto-configuration or stateful DHCPv6-based
configuration to acquire an address via the Edge Router.
However, as manual configuration for each customer is a provisioning
challenge, implementations are encouraged to develop mechanism(s)
that automatically map the VLAN (or some other customer-specific
information) to an IPv6 subnet prefix, and advertise the customer-
specific prefix to all the customers with minimal configuration.
If a Customer Router is present:
A. It is statically configured with an address on the /64 subnet
between itself and the Edge Router, and with /64 prefixes on the
interfaces connecting the hosts on the customer site. This is
not a desired provisioning method, being expensive and difficult
to manage.
B. It can use its link-local address to communicate with the ER. It
can also dynamically acquire, through stateless auto-
configuration, the address for the link between itself and the
ER. This step is followed by a request via DHCP-PD for a prefix
shorter than /64 that in turn is divided in /64s and assigned to
its interfaces connecting the hosts on the customer site.
The Edge Router has a /64 prefix configured for each subscriber VLAN.
Each VLAN should be enabled to relay DHCPv6 requests from the
subscribers to DHCPv6 servers in the ISP network. The VLANs
providing access for subscribers that use DHCP-PD have to be enabled
to support the feature. The uplink to the ISP network is configured
with a /64 prefix as well.
Asadullah, et al. Informational [Page 45]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
The prefixes used for subscriber links and the ones delegated via
DHCP-PD should be planned in a manner that allows as much
summarization as possible at the Edge Router.
Other information of interest to the host, such as DNS, is provided
through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
7.2.1.3. Routing
The CPE devices are configured with a default route that points to
the Edge Router. No routing protocols are needed on these devices,
which generally have limited resources.
The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS.
The connected prefixes have to be redistributed. If DHCP-PD is used,
with every delegated prefix a static route is installed by the Edge
Router. For this reason, the static routes must also be
redistributed. Prefix summarization should be done at the Edge
Router.
7.2.2. PPP Terminated Aggregation (PTA) Model
The PTA architecture relies on PPP-based protocols (PPPoE). The PPP
sessions are initiated by Customer Premise Equipment and are
terminated at the BRAS. The BRAS authorizes the session,
authenticates the subscriber, and provides an IP address on behalf of
the ISP. The BRAS then does Layer 3 routing of the subscriber
traffic to the NSP Edge Router.
When the NSP is also the NAP, the BRAS and NSP Edge Router could be
the same piece of equipment and provide the above mentioned
functionality.
The PPPoE logical diagram in an Ethernet Broadband Network is shown
in Fig 7.2.2.1.
Asadullah, et al. Informational [Page 46]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
| Customer Premise | | NAP | | NSP |
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
+-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O
|---------------- PPP ----------------| | | R
+-----------+ E
Figure 7.2.2.1
The PPP sessions are initiated by the Customer Premise Equipment
(Host or Router). The BRAS authenticates the subscriber against a
local or remote database. Once the session is established, the BRAS
provides an address and maybe a DNS server to the user; this
information is acquired from the subscriber profile or a DHCP server.
This model allows for multiple PPPoE sessions to be supported over
the same VLAN, thus allowing the subscriber to connect to multiple
services at the same time. The hosts can initiate the PPPoE sessions
as well. It is important to remember that the PPPoE encapsulation
reduces the IP MTU available for the customer traffic.
7.2.2.1. IPv6 Related Infrastructure Changes
In this scenario, the BRAS is Layer 3 aware and has to be upgraded to
support IPv6. Since the BRAS terminates the PPP sessions, it has to
support PPPoE with IPv6. The following devices have to be upgraded
to dual stack: Host, Customer Router (if present), BRAS and Edge
Router.
7.2.2.2. Addressing
The BRAS terminates the PPP sessions and provides the subscriber with
an IPv6 address from the defined pool for that profile. The
subscriber profile for authorization and authentication can be
located on the BRAS, or on an AAA server. The Hosts or the Customer
Routers have the BRAS as their Layer 3 next hop.
The PPP session can be initiated by a host or by a Customer Router.
In the latter case, once the session is established with the BRAS,
DHCP-PD can be used to acquire prefixes for the Customer Router
interfaces. The BRAS has to be enabled to support DHCP-PD and to
relay the DHCPv6 requests of the hosts on the subscriber sites.
Asadullah, et al. Informational [Page 47]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
The BRAS has a /64 prefix configured on the link facing the Edge
router. The Edge Router links are also configured with /64 prefixes
to provide connectivity to the rest of the ISP network.
The prefixes used for subscribers and the ones delegated via DHCP-PD
should be planned in a manner that allows maximum summarization at
the BRAS.
Other information of interest to the host, such as DNS, is provided
through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
7.2.2.3. Routing
The CPE devices are configured with a default route that points to
the BRAS router. No routing protocols are needed on these devices,
which generally have limited resources.
The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the
addresses assigned to the PPP sessions are represented as connected
host routes, connected prefixes have to be redistributed. If DHCP-PD
is used, with every delegated prefix a static route is installed by
the BRAS. For this reason, the static routes must also be
redistributed. Prefix summarization should be done at the BRAS.
The Edge Router is running the IGP used in the ISP network: OSPFv3 or
IS-IS. A separation between the routing domains of the ISP and the
Access Provider is recommended if they are managed independently.
Controlled redistribution will be needed between the Access Provider
IGP and the ISP IGP.
7.2.3. L2TPv2 Access Aggregation (LAA) Model
In the LAA model, the BRAS forwards the CPE initiated session to the
ISP over an L2TPv2 tunnel established between the BRAS and the Edge
Router. In this case, the authentication, authorization, and
subscriber configuration are performed by the ISP itself.
Asadullah, et al. Informational [Page 48]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 2007
| Customer Premise | | NAP | | NSP |
+-----------+
| AAA |
+------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O
| | R
+-----------+ E
|-----------------------------------------------|
PPP
|--------------|
L2TPv2
Figure 7.2.3.1
7.2.3.1. IPv6 Related Infrastructure Changes
In this scenario, the BRAS is Layer 3 aware and has to be upgraded to
support IPv6. The PPP sessions initiated by the subscriber are
forwarded over the L2TPv2 tunnel to the aggregation point in the ISP
network. The BRAS (LAC) can aggregate IPv6 PPP sessions and tunnel
them to the LNS using L2TPv2. The L2TPv2 tunnel between the LAC and
LNS could run over IPv6 or IPv4. These capabilities have to be
supported on the BRAS. The following devices have to be upgraded to
dual stack: Host, Customer Router (if present), BRAS and Edge Router.
7.2.3.2. Addressing
The Edge Router terminates the PPP sessions and provides the
subscriber with an IPv6 address from the defined pool for that
profile. The subscriber profile for authorization and authentication
can be located on the Edge Router or on an AAA server. The Hosts or
the Customer Routers have the Edge Router as their Layer 3 next hop.
The PPP session can be initiated by a host or by a Customer Router.
In the latter case, once the session is established with the Edge
Router and an IPv6 address is assigned to the Customer Router by the
Edge Router, DHCP-PD can be used to acquire prefixes for the Customer
Router other interfaces. The Edge Router has to be enabled to
support DHCP-PD and to relay the DHCPv6 requests of the hosts on the
subscriber sites. The uplink to the ISP network is configured with a
/64 prefix as well.
Asadullah, et al. Informational [Page 49]
RFC 4779 ISP IPv6 Deployment Scenarios in BB January 200
