Network Working Group S. Asadullah
Request for Comments: 4779 A. Ahmed
Category: Informational C. Popoviciu
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 (C) The IETF Trust (2007).
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.
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
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.
2. Common Terminology
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
There are two types of networks identified in the Broadband
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
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.
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)
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
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
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
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
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
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
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.
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
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
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
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
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.