IPv6 Working Group Salman Asadullah
INTERNET DRAFT Adeel Ahmed
October 2004 Ciprian Popoviciu
Cisco Systems
ISP IPv6 Deployment Scenarios in Broadband Access Networks
<draft-asadullah-v6ops-bb-deployment-scenarios-02.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 27, 2005.
Abstract
This document provides 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. In this
document we will discuss main components of IPv6 BB networks and
their differences from IPv4 BB networks and how IPv6 is deployed
and integrated in each of these BB technologies using tunneling
mechanisms and native IPv6.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 1]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
Table of Contents:
1. Introduction..................................................3
2. IPv6 Based BB Services........................................3
3. Scope of the Document.........................................4
4. Core Backbone Network.........................................5
4.1 Layer2 Access Provider....................................5
4.2 Layer3 Access Provider....................................6
5. Tunneling Options.............................................7
5.1 Access over Tunnels-customers with public IPv4 address....7
5.2 Access over Tunnels-customers with private IPv4 address...7
5.3 Transition a portion of the IPv4 infrastructure...........8
6. Broadband Cable Networks .....................................9
6.1 Broadband Cable Network Elements .........................9
6.2 Deploying IPv6 in Cable Networks.........................10
6.2.1 Bridged CMTS Network .............................11
6.2.2 Routed CMTS Network ..............................13
6.3 IPv6 Multicast ..........................................22
6.4 IPv6 QoS ................................................22
6.5 IPv6 Security Considerations.............................23
6.6 IPv6 Network Management .................................23
7. Broadband DSL Networks.......................................24
7.1 DSL Network Elements ....................................24
7.2 Deploying IPv6 in IPv4 DSL Networks......................25
7.2.1 Point-to-Point Model..............................26
7.2.2 PPP Terminated Aggregation (PTA) Model............27
7.2.3 L2TP Access Aggregation (LAA) Model...............30
7.2.4 Hybrid Model for IPv4 and IPv6 Service ...........33
7.3 IPv6 Multicast...........................................35
7.3.1 ASM Based Deployments..............................35
7.3.1 SSM Based Deployments..............................36
7.4 IPv6 QoS.................................................37
7.5 IPv6 Security Considerations.............................37
7.6 IPv6 Network Management..................................38
8. Broadband Ethernet Networks..................................38
8.1 Ethernet Access Network Elements .......................38
8.2 Deploying IPv6 in IPv4 BB Ethernet Networks.............39
8.2.1 Point-to-Point Model.............................40
8.2.2 PPP Terminated Aggregation (PTA) Model...........41
8.2.3 L2TP Access Aggregation (LAA) Model..............43
8.2.4 Hybrid Model for IPv4 and IPv6 Service...........45
8.3 IPv6 Multicast..........................................47
8.4 IPv6 QoS................................................48
8.5 IPv6 Security Considerations............................48
8.6 IPv6 Network Management.................................49
9. Broadband Wireless LAN Networks..............................49
9.1 WLAN Deployment Scenarios...............................49
9.1.1 Layer2 Switch Between AP and SP Edge Router......51
9.1.2 Access Router Between AP and SP Edge Router......53
9.1.3 PPP Based Model..................................55
9.2 IPv6 Multicast..........................................57
9.3 IPv6 QoS................................................58
9.4 IPv6 Security Considerations............................59
9.5 IPv6 Network Management.................................59
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 2]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
10.Gap Analysis.................................................60
11.Contributors.................................................62
12.Acknowledgments..............................................62
13.References...................................................62
Authors Addresses...............................................64
1. Introduction
With the exponential growth of the Internet and increasing number of
end users, SPs are looking for new ways to evolve their current
network architecture to meet the needs of Internet ready appliances,
new applications and services. IPv6 is designed to enable SPs to meet
these challenges and provide new services to their customers.
As the number of devices per BB users increase exponentially
worldwide, Cable, DSL, Ethernet to the Home, Wireless and other
always-on access technologies can benefit from the huge address
range [RFC 3513] of IPv6. Other benefits of IPV6 include the
capability to enhance end-to-end security, mobile communications,
and ease system management burdens. Some examples include
peer-to-peer communication without NAT traversal problems, being
able to access securely devices at home from work, enhanced IP
Mobility [RFC 3775] and so on.
Therefore SPs are aggressively evaluating the capabilities of IPv6
to meet these needs. Some countries have taken a lead role in this
race and moved from testing and evaluation to real deployments of
IPv6 in the BB arena. Japan is a prime example along with other
countries that are looking at moving towards large scale production
deployments of IPv6.
The SPs are deploying tunneling mechanisms to transport IPv6 over
their existing IPv4 networks as a start as well as deploying native
IPv6 where possible. Deployment of tunneling solutions are simpler,
easier and more economical to start the IPv6 services, as they
require minimal investments and network infrastructure changes in
current SP model. Depending on customer needs and requirements a
native IPv6 deployment option might be more scalable and provide
required service performance.
2. IPv6 Based BB Services
At this point IPv6 based services are seen as a differentiator that
enables SPs to take advantage of the large IPv6 address space to
the extent that subscribers get fixed /64 prefixes versus the single,
temporary IPv4 addresses. Such resources allow the SPs to better
position themselves against the competition. The IPv6 deployments
can be seen as a driver for lower service support costs by
eliminating NAT with its negative impact on applications and its
complex behavior. Another reason of IPv6 being very popular in some
countries is the government driven financial incentives and favorable
legislation toward the ISPs who are deploying IPv6.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 3]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
NTT East, Japan started a commercial dual-stack (devices capable of
forwarding IPv4 and IPv6 packets) IPv6 unicast service option early
this year for its ADSL and FTTH subscribers, under the name of
FLETS.Net [Dual Stack Access].
For these users the IPv6 addresses are dedicated (/64 per user) and
are used when needed. However, this IPv6 service is available only
to the NTT-East ADSL and FTTH subscribers who are part of FLETS.NET
network and at this point does not provide connectivity to the
IPv6 Internet.
The list of BB SPs that have deployed IPv6 services contains names
such as: SpaceNet in Germany, Dolphin in Switzerland, Nerim in
France and XS4ALL in The Netherlands.
Some ISPs that are currently providing IPv4 based Multicast and
VoIP services are evaluating IPv6 to take advantage of the huge
address space and other useful features. The Multicast services
consist of video and audio streaming of several programs (streams).
The content provider will have certain content (which is of user
interest) and they would send these multicast streams to BB
subscribers. Today, when done through IPv4, there is generally a
single device directly attached to the CPE that receives the
Multicast stream. By moving to IPv6, ISP should be capable to
provide multiple streams to multiple devices on the customer site.
For instance in Japan, Cable TV and dish services are not very
popular, the users expect everything through the broadcasted, free
programs (traditional TV). In case of BB users however, they can get
some extra content through the SP, which is very reasonably priced
for 20 Mbps or 10/100 Mbps of bandwidth. Users sign up with a content
provider that is multicasting several channels of video and audio. A
subscriber would join the multicast group of interest (after
authentication) and will start receiving the stream(s). An example of
a video stream could be Disney movies and an example of an audio
stream could be Karaoke (part of same *,G group). Similar to Cable
TV, where customers sign up and pay for single programs or packages
of programs.
SPs are also offering IPv6 services over wireless links using 802.11
compliant WiFi Hot Spots. This enables users to take notebook PCs and
PDAs (Windows 2003 supports IPv6 capable Internet Explorer and Media
Player 9) along with them and connect to the Internet from various
locations without the restriction of staying indoors.
3. Scope of the Document
The focus of this document is to present the options available in
deploying IPv6 services in the access portion of a BB Service
Provider network namely Cable/HFC, BB Ethernet, xDSL and WLAN.
This document briefly discusses the other elements of a provider
network as well. It provides different viable IPv6 deployment and
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 4]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
integration techniques and models for each of the above mentioned BB
technologies separately. The example list is not exhaustive but it
tries to be representative.
This document analyzes, how all the important parts of current IPv4
based Cable/HFC, BB Ethernet, xDSL and WLAN networks will behave
when IPv6 is integrated and deployed.
The following important pieces are discussed:
A. Available tunneling options
B. Devices that would require 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 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. They can
be however adapted to the network and business model needs of the
ISPs.
4. Core/Backbone Network
This section intends to briefly discuss the 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 [ISP
Networks IPv6 Scenarios].
There are two 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.
4.1 Layer2 Access Provider Network
The Access Provider can deploy a Layer2 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 two core. The network
core can involve various technologies such as Ethernet, ATM and etc.
The Service Provider Edge Router connects to the Access Provider
core.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 5]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
In this type of a network the impact of deploying IPv6 is minimal.
The network is transparent to the Layer 3 protocol. The only possible
changes would come with the intent of filtering and monitoring IPv6
traffic based on layer 2 information such as IPv6 Ether Type Protocol
ID (0x86DD) or IPv6 multicast specific MAC addresses
(3333.xxxx.xxxx).
4.2 Layer3 Access Provider Network
The Access Provider can choose to terminate the Layer2 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
Layer3 core to the SP Edge Routers. In this case the impact of the
IPv6 deployment is significant.
The case studies in this document only present the significant
network elements of such a network: Customer Premises 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 layer3
core in three possible ways:
A. IPv6 Tunneling: As a temporary solution, the Access Providers 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 IGP such as OSPFv3 or IS-IS is enabled, usually mapping the
IGP deployed for IPv4. The most important thing to remember in this
case is that the device resources are now shared between IPv4 and
IPv6 processes. This problem could be elimnated with the use of
ISIS-MT (multi-topology) where a single database and SPF is used for
IPv4 and IPv6.
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 its.
In this case only a subset of routers close to the edge of the
network needs to be IPv6 aware. With this approach BGP becomes
important in order to support 6PE. Its deployment will most likely
leverage the Route Reflector structure used with the IPv4 deployment.
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
un-aware of the fact that it transports both IPv4 and IPv6 traffic.
6PE should be leveraged only if MPLS is already deployed in the
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 6]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
network. At the time of writing this document, a major disadvantage
of the 6PE solution is the fact that it does not support multicast
IPv6 traffic.
The native approach has the advantage of supporting IPv6
multicast traffic but it implies a significant impact on the IPv4
operational network from software, configuration and possibly
hardware upgrade perspective.
More detailed Core Network deployment recommendations are discussed
in other documents [ISP Networks IPv6 Scenarios]. The handling of
IPv6 traffic in the Core of the Access Provider Network will not be
discussed for the remainder of this document.
5. Tunneling Overview
Service Providers might not be able to deploy native IPv6 today due
to the cost associated with HW and SW upgrades, the infrastructure
changes needed to their current network and the current demand for
the service. For these reasons, some SPs might choose 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
[Assisted Tunneling] and [ZeroConf] with more updates to follow.
Deploying IPv6 using tunneling techniques can imply as little
changes to the network as upgrading SW on tunnel end points.
A Service Provider could use tunneling to deploy IPv6 in the
following scenarios:
5.1 Access over Tunnels-customers with Public IPv4 Address
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.
Out of the many tunneling mechanisms developed [RFC3053, RFC3056,
RFC2473, ISATAP, RFC2893, RFC2529] some are more popular than the
others.
If the end customer has a GWR installed, then it could be used to
originate the tunnel and thus offer native IPv6 access to multiple
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.
5.2 Access over Tunnels-Customers with Private IPv4 Address
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 7]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
If the end customer receives a private IPv4 address and its hosts
need to go through a NAT, tunneling techniques like 6to4 will not
work since they rely on Public IPv4 address. In this case the end
user might have to use tunnels that can operate through NATs (such
as Teredo tunnel [OPS]).
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 5.1. This will imply HW replacement or
SW upgrade and a native IPv6 environment behind the GWR.
It is important to note that the customers of a Service Provider can
choose to establish tunnels to publicly available and free tunnel
services. Even though the quality of such services might not be high,
they provide free IPv6 access. In designing their IPv6 services, the
SPs should take into considerations such options available to their
potential customers. The IPv6 deployment should support services
(like multicast, VoIPv6 etc) and a level of quality that would make
the access through the SP worthwhile to potential subscribers.
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 [Tunnel through IPsec].
5.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 and 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 it supports
multicast or not), routing protocols used (GRE is the only tunnel
type which can transport layer 2 messages as well), manage-ability
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.
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 [Dynamic Tunnel]) in this case,
the SPs might find the native approach worth the additional
investments.
In all the scenarios listed above the tunnel selection process should
consider the IPv6 multicast forwarding capabilities if such service
is planed. As an example, 6to4 tunnels do not support IPv6 multicast
traffic.
The operation, capabilities and deployment of various tunnel types
has been discussed extensively in the documents referenced earlier as
well as in [OPS, RFC3904]. Details of a tunnel based deployment are
offered in the next section of this document (section 6). In the case
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 8]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
of Cable Access where the current DOCSIS specifications do not
provide support for native IPv6 access. Although sections 7, 8 and 9
focus on a native IPv6 deployments over DSL, FTTH and Wireless
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
6.
6. 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 Cable Networks.
The current version of DOCSIS has 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 existent Cable
Networks are tunnel based. The tunneling examples presented here
could also be applied to the other BB technologies described in
sections 7, 8 and 9.
6.1 Broadband Cable Network Elements
Broadband cable networks are capable of transporting IP traffic to/
from users to provide high speed Internet access and VOIP services.
The mechanism of 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)
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
Data Over Cable Service Interface Specification (DOCSIS): The
standards defining how data should be carried over cable networks.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 9]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
Figure 9.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 6.1
6.2 Deploying IPv6 in Cable Networks
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 some 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
cable networks include:
A. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. These
devices rely on IGMP join messages to track membership of hosts that
are part of a particular IP Multicast group. In order to support ND
the CM and CMTS will need to support IGMPv3/MLDv2 snooping.
B. Classification of IPv6 traffic in the upstream and downstream
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 10]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
direction. The CM and CMTS will need to support classification of
IPv6 packets in order to give them the appropriate priority and
QoS. Without proper classification all IPv6 traffic will need to be
sent best effort (BE) which can cause problems when deploying
services like VOIP and IP Multicast video.
C. Changes need to be made to the DOCSIS specification to include
support for IPv6 on the CM and CMTS. This is imperative for
deploying native IPv6 over cable networks.
Due to the above mentioned limitations in deployed cable networks,
the only available option to cable operators is to use tunneling
techniques in order to transport IPv6 traffic over their current
IPv4 infrastructure. The following sections will cover these
deployment scenarios in more detail.
6.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 acts 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 be 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.
Figure 6.2.1 illustrate the IPv6 deployment scenario
+-----+ +-----+
|Host |--| GWR |
+-----+ +--+--+
| _ _ _ _ _ _
| +------+ | |
+--| CM |---| |
+------+ | |
| HFC | +------+ +--------+
| | | | | Edge |
+-----+ +------+ | Network |---| CMTS |---| |===> ISP
|Host |--| CM |---| | | | | Router | Network
+-----+ +------+ | | +------+ +--------+
|_ _ _ _ _ _|
<-------------><---------------------------------><--------------->
L3 Routed L2 Bridged L3 Routed
Figure 6.2.1
6.2.1.1 IPv6 Related Infrastructure Changes
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 11]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
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.
6.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.
6.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 DHCPv4,
and download a DOCSIS configuration file identified by the DHCPv4
server.
6.2.1.2.2 IP Addressing for Hosts
If there is no GWR connected to the CM, all the hosts behind the CM
will belong to the same /64 subnet that is assigned using stateless
auto-configuration or DHCPv6.
If using stateless auto-configuration, the host listens for routing
advertisements (RA) 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 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.
6.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 for a prefix
shorter than /64, typically /48, which in turn is divided into /64s
and assigned to its downstream interfaces connecting to the hosts.
6.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 CMTS must either forward Neighbor Discovery (ND) packets
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 12]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
or provide a proxy ND service.
Communication between hosts behind different CMs is always forwarded
by the CMTS. IPv6 communication between the different sites relies
on multicast IPv6 ND [RFC2461] frames being forwarded correctly by
the CM and the CMTS. As with the CM, a bridged CMTS that selectively
forwards multicast datagrams on the basis of IGMPv2 will potentially
break IPv6 ND.
In order to support IPv6 multicast applications across DOCSIS cable
networks, the CM and bridging CMTS need to support IGMPv3/MLDv2
snooping. MLD is 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 (Single Source Multicast) service models.
Implementation work on CM/CMTS should be minimal because the only
significant difference between IPv4 IGMPv3 and IPv6 MLDv2 are the
longer addresses in the protocol.
6.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 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.
6.2.2 Deploying IPv6 in a Routed CMTS Network
In an IPv4 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 in a routed CMTS network, the CM still acts
as a Layer-2 device and will need to bridge IPv6 unicast as well as
multicast traffic. The CMTS/ER will need to either tunnel IPv6
traffic or natively support IPv6. The host and GWR will use the
CMTS/ER as their Layer-3 next hop.
There could be 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
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 13]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
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 acts 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 HW and SW upgrades to support IPv6.
4. Dual-stacked Cable (HFC) Network, Standalone GWR and CMTS Support
IPv6
In this scenario there is a standalone 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 HW
and SW 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 existent 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.
6.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.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 14]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
Figure 6.2.2.1 illustrates this deployment scenario
+-----------+ +------+ +--------+
+-----+ +-------+ | Cable | | | | Edge |
|Host |--| CM |----| (HFC) |----| CMTS |----| |=>ISP
+-----+ +-------+ | Network | | | | Router | Network
+-----------+ +------+ +--------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-over-IPv4 tunnel
<---------><----------------------------------------><------------>
IPv4/v6 IPv4 only IPv4/v6
Figure 6.2.2.1
6.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.
6.2.2.1.2 Addressing
The only device that needs to be assigned an IPv6 address at customer
site is the host. Host address assignment can be done statically as
there is no mechanism to transport ND messages or DHCPv6 messages
over the IPv4 cable network.
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.
6.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 over 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 [for example 6to4 relay, tunnel
broker etc.].
6.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
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 15]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
route might be needed to forward traffic to the next hop.
The ER runs an IGP such as OSPFv3 or ISIS.
6.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 to/from the host and the ER, the cable
network including the CM and CMTS do not need to support IPv6 and
can remain IPv4 devices.
Figure 6.2.2.2 illustrates this deployment scenario
+-----+
|Host |
+--+--+
| +-----------+ +------+ +--------+
+---+---+ +-------+ | Cable | | | | Edge |
| GWR |--| CM |----| (HFC) |----| CMTS |----| |=>ISP
+-------+ +-------+ | Network | | | | Router | Network
+-----------+ +------+ +--------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-over-IPv4 tunnel
<---------><---------------------------------------><------------->
IPv4/v6 IPv4 only IPv4/v6
Figure 6.2.2.2
6.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.
6.2.2.2.2 Addressing
The only devices that needs 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 prefix from the ER. This /48
prefix will be used to configure /64s on hosts connected to the GWR
downstream interfaces. Currently the DHCP-PD functionality cannot be
implemented if the DHCP-PD server is not the Edge Router. If the
DHCP-PD messages are relayed, the Edge Router does not have a
mechanism to learn the assigned prefixes and thus install the proper
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 16]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
routes to make that prefix reachable. Work is being done to address
this issue, one idea being to provide the Edge Router with a snooping
mechanism. 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.
6.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 over IPv4 tunneling
mechanisms. All IPv6 traffic will need to go through the tunnel, once
it comes up.
The GWR will use its global IPv4 address to source the tunnel to
the ER. The tunnel endpoint will be the IPv4 global 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.
6.2.2.2.4 Routing
Depending on the tunneling technique used there might some
configuration 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.
If using manual tunneling, the GWR and ER can use static routing or
they can also configure RIPng. The RIPng updates can be transported
over a manual tunnel, which does not work when using 6to4 tunneling.
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 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.
The ER runs an IGP such as OSPFv3 or ISIS.
6.2.2.3 Dual-stacked Cable (HFC) Network, CM and CMTS Support IPv6
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 17]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
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 6.2.2.3 illustrates this deployment scenario
+-----------+ +-------------+
+-----+ +-------+ | Cable | | CMTS / Edge |
|Host |--| CM |----| (HFC) |----| |=>ISP
+-----+ +-------+ | Network | | Router | Network
+-----------+ +-------------+
<-------><----------------------------><---------------->
IPv4/v6 IPv4/v6 IPv4/v6
Figure 6.2.2.3
6.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 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.
6.2.2.3.2 Addressing
In today cable networks 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 autoconfiguration. 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 with the CMTS
acting as a DHCPv6 relay agent. If address assignment on hosts is
done via stateless autoconfiguration, 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
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 18]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
need to forward the RA messages downstream or act as an ND proxy.
6.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.
6.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 ISIS.
6.2.2.4 Dual-Stacked Cable (HFC) Network, Standalone 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 acts 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 6.2.2.2.
The only difference in this case is the ER functionality exists on
the CMTS instead of a separate router in the cable operator network.
Figure 6.2.2.4 illustrates this deployment scenario
+-----------+ +------------+
+------+ +-------+ +-------+ | Cable | |CMTS / Edge |
| Host |---| GWR |--| CM |---| (HFC) |----| |=>ISP
+------+ +-------+ +-------+ | Network | | Router |Network
+-----------+ +------------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-over-IPv4 tunnel
<-----------------><--------------------------------><-------------->
IPv4/v6 IPv4 IPv4/v6
Figure 6.2.2.4
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 19]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
6.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.
6.2.2.4.2 Addressing
The CM will still receive a private IPv4 address using DHCPv4 which
works the same way in existent cable networks. The CMTS will act as
DHCPv4 relay agent.
The address assignment for the host and GWR happens in a similar
manner as described in section 6.2.2.2.2.
6.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
6.2.2.2.3.
6.2.2.4.4 Routing
In this case routing is very similar to the case described in
section 6.2.2.2.4. Since the CMTS now incorporates the ER
functionality, it will need to run an IGP such as OSPFv3 or ISIS.
6.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 support 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 6.2.2.5 illustrates this deployment scenario
+-----------+ +-------------+
+-----+ +-----------+ | Cable | | CMTS / Edge |
|Host |---| CM / GWR |----| (HFC) |----| |=> ISP
+-----+ +-----------+ | Network | | Router | Network
+-----------+ +-------------+
<---------------------------------------------------------->
IPv4/v6
Figure 6.2.2.5
6.2.2.5.1 IPv6 Related Infrastructure Changes
Since the CM/GWR acts as a Layer-3 device, IPv6 can be deployed
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 20]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
end-to-end. In this scenario the following devices have to be
upgraded to dual-stack: Host, CM/GWR and CMTS/ER.
6.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.
If using DHCPv6 the CMTS will need to act as 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 same /64 prefix. The hosts connected to the same
cable interface on the CMTS may belong to different /64 prefixes as
the CMTS will have multiple /64 prefixes configured under its cable
interfaces.
It is also possible to use DHCP-PD for 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 RA message. Once the CM/GWR assigns an IPv6
address to its upstream interface it will request a /48 prefix from
the CMTS/ER and chop this /48 prefix into /64s for assigning IPv6
addresses to hosts. Currently the DHCP-PD functionality cannot be
implemented if the DHCP-PD server is not the Edge Router. If the
DHCP-PD messages are relayed, the Edge Router does not have a
mechanism to learn the assigned prefixes and thus install the proper
routes to make that prefix reachable. Work is being done to address
this issue, one idea being to provide the Edge Router with a snooping
mechanism. The uplink to the ISP network is configured with a /64
prefix as well.
6.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.
6.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 RIP-ng 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.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 21]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
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 ISIS.
6.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
snooping. MLD is 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 (Single Source Multicast) service
models.
SSM is more suited for deployments where the SP intends to provide
paid content to the users (Video or Audio). This type of services
are expected to be of primary interest. Moreover, the simplicity of
the SSM model often times override the scalability issues that would
be resolved in an ASM model. ASM is however an option that is
discussed in section 7.3.1. The "SSM safe reporting" problem for IPv4
does not exist in IPv6 multicast because the use of SSM in IPv6 is
well defined and uses un-contentious address ranges. The CM, GWR and
CMTS/ER will need to be enabled with PIM-SSM, which requires the
definition and support for IGMPv3/MLDv2 snooping, in order to track
join/leave messages from the hosts. The Layer 3 next hop for the
hosts support MLD.
Please refer to section 7.3 for more IPv6 multicast details.
6.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.
In order to classify IPv6 traffic the following classifiers would
need to be modified in the DOCSIS specification to support the
128-bit IPv6 address:
A. IP source address
B. IP source mask
C. IP destination address
D. IP destination mask
E. IP traffic class (DSCP)
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 22]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
The following classifiers would be new for IPv6:
A. IP version
B. Flow label (optional)
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, video. The same
IPv4 QoS concepts and methodologies should be applied for IPv6 as
well.
6.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,
appropriate enhancements will be needed in the DOCSIS specification
to support encrypted IPv6 multicast. The other aspect of security
enhancement is mandated IPSec support in IPv6. The IPv6
specifications mandate implementation of IPSec, but they do not
mandate its use. The IPv4 specifications do not mandate IPSec. IPSec
is the same for both IPv4 and IPv6, but it still requires a key
distribution mechanism. Cable operators may consider deploying it
end-to-end on IPv6 as there is not an intermediate device(i.e. NAT).
There are limited changes that have to be done for hosts in order to
enhance security. The Privacy extensions [RFC3041] for
autoconfiguration 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 form 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 uRPF and
ACLs should be used on all interfaces facing subscribers. Filtering
should be implemented with regard for the operational requirements of
IPv6 (ICMPv6 types).
The CMTS/ER should protect its processing resources against floods of
valid customer control traffic such as: Router and Neighbor
Solicitations, MLD Requests.
All other security features used with the IPv4 service should be
similarly applied to IPv6 as well.
6.6 IPv6 Network Management
All current DOCSIS, PacketCable, and CableHome MIBs are already
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 23]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
designed to support IPv6 objects. In this case, IPv6 will neither
add, nor change any of the functionality of these MIBs. An object to
identify the IP version, InetAddressType has been added to all the
appropriate SNMP objects related to IP address.
7. Broadband DSL Networks
This section describes the IPv6 deployment options in today
High Speed DSL Networks.
7.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 Premises Equipment and the DSLAM.
The following network elements are typical of a DSL network [ISP
Transition Scenarios]:
DSL Modem: It can be a stand alone device, it can be incorporated
in the host, and it can incorporate router functionalities.
Customer Premises Router: It is used to provide layer 3 services
for customer premises networks. It is usually use 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 PVC corresponding to the subscriber DSL circuits.
Edge Router (ER): It provides the Layer 3 interface to the ISP
network.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 24]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
Figure 7.1 depicts all the network elements mentioned.
Customer Premises | Network Access Provider | Network Service Provider
CP NAP NSP
+-----+ +------+ +------+ +--------+
|Hosts|--|Router| +--+ BRAS +---+ Edge | ISP
+-----+ +--+---+ | | | | Router +===> Network
| | +------+ +--------+
+--+---+ |
| DSL +--+ |
|Modem | | |
+------+ | +-----+ |
+--+ | |
+------+ |DSLAM+--+
+-----+ | DSL | +--+ |
|Hosts|--+Modem +--+ +-----+
+-----+ +--+---+
Figure 7.1
7.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 two circuits has to be
maintained over a significant portion of the network. The layer two
domains can be terminated at the ER in three ways:
A. In a common bridge group with a virtual interface that routes it
out.
B. Enable a Routed Bridged Encapsulation feature, all users could be
part of the same subnet. This is the most common deployment type of
IPv4 over DSL but it might not be the best choice in IPv6 where
address availability is not an issue.
C. Terminate the PVC at layer 3, each PVC has its own prefix. This is
the approach that seems more suitable for IPv6 and presented in 7.2.1
In none of these cases the CPE (DSL Modem) has to 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 7.2.2.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 25]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
3. 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
tunnels. This model is presented in section 7.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 existent revenue generating IPv4 services, the
IPv6 deployment will match the IPv4 one. This approach is presented
in sections 7.2.1-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 7.2.4.
7.2.1 Point-to-Point Model
In this scenario the Ethernet frames from the Host or the Customer
Premises Router are bridged over the PVC assigned to the subscriber
[ISP Transition Scenarios].
Figure 7.2.1 describes the protocol architecture of this model.
Customer Premises NAP NSP
<-------------------------> <---------------> <-------------------->
+-----+ +-------+ +-----+ +--------+ +----------+
|Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP
+-----+ +-------+ |Modem| +--------+ | Router +==> Network
+-----+ +----------+
<---------------------------->
ATM
Figure 7.2.1
7.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.
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 PVC. The hosts can use stateless
autoconfiguration or statefull DHCPv6 based configuration to acquire
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 26]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
an address via the Edge Router.
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 dynamically acquires through stateless autoconfiguration the
address for the link between itself and the Edge Router. This step
is followed by a DHCP-PD [RFC 3633] request for a prefix shorter then
/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 as well, have to be enabled
to support the feature. Currently the DHCP-PD functionality cannot be
implemented if the DHCP-PD server is not the Edge Router. If the
DHCP-PD messages are relayed, the Edge Router does not have a
mechanism to learn the assigned prefixes and thus install the proper
routes to make that prefix reachable. Work is being done to address
this issue, one idea being to provide the Edge Router with a snooping
mechanism. 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 statefull DHCPv6 [RFC 3315] and stateless DHCPv6 [RFC 3736].
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 do 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 (PPPoA [RFC 2364]
and PPPoE [RFC 2516]). The PPP sessions are initiated by Customer
Premise Equipment and it is terminated at the BRAS. The BRAS
authorizes the session, authenticates the subscriber, and provides
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 27]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
an IP address on behalf of the ISP. The BRAS then does Layer-3
routing of the subscriber traffic to the NSP Edge Router. This model
is often used when the NSP is also the NAP
[ISP Transition Scenarios].
There are two types of PPP encapsulations that can be leveraged with
this model:
A. Connection using PPPoA
Customer Premises NAP NSP
<--------------------> <----------------------> <----------------->
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
|
+-----+ +-------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
<-------------------------->
PPP
Figure 7.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, information 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.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 28]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
B. Connection using PPPoE
Customer Premises NAP NSP
<----------------------------> <-------------------> <----------------->
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
|
+-----+ +-------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +------------+ DSLAM +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +----------+ | Router +=>O
| | R
+-----------+ E
<-------------------------------->
PPP
Figure 7.2.2.2
The operation of PPPoE is similar to PPPoA with the exception that
with PPPoE multiple session 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
[ISP Transition Scenarios].
The network design and operation of the PTA model is the same
regardless of the PPP encapsulation type used.
7.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.
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 a 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 later 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.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 29]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
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 a /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 subscriber 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 statefull [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 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.
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
[ISP Transitions Scenarios]. There are two types of PPP
encapsulations that can be leveraged with this model:
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 30]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
A. Connection via PPPoA
Customer Premises NAP NSP
<--------------------> <----------------------> <----------------->
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
<---------------------------------------->
PPP
<------------>
L2TPv2
Figure 7.2.3.1
B. Connection via PPPoE
Customer Premises NAP NSP
<---------------------------> <--------------------> <----------------->
+-----------+
| AAA |
+------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +----+------+
|Hosts|--+Router +------------+ DSLAM +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +----------+ | Router +=>O
| | R
+-----------+ E
<----------------------------------------------->
PPP
<-------------->
L2TPv2
Figure 7.2.3.2
The network design and operation of the PTA model is the same
regardless of the PPP encapsulation type used.
7.2.3.1 IPv6 Related Infrastructure Changes
In this scenario the BRAS is layer-3 aware and it 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
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 31]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
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, 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 a 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 later 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 statefull [RFC3315] and stateless [RFC3736] DHCPv6.
It is important to note here a signifcant 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).
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 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).
7.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 have limited
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 32]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
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.
7.2.4 Hybrid Model for IPv4 and IPv6 Service
It was recommended throughout this section that the IPv6 service
implementation should map the existent 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.
A Modified Point-to-Point (as described in 7.2.4.2) or PTA model are
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.
7.2.4.1 IPv4 in LAA Model and IPv6 in PTA Model
The coexistence of the two PPP based models, PTA and LAA, is
relatively straight forward. It is a straight forward overlap of the
two deployment models. The PPP sessions are terminated on
different network devices for the IPv4 and IPv6 services. The PPP
sessions for the existent 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.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 33]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
The logical design for IPv6 and IPv4 in this hybrid model is
presented in Figure 7.2.4.1.
IPv6 <-------------------------->
PPP +-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 <---------------------------------------->
PPP
<------------>
L2TPv2
Figure 7.2.4.1
7.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
7.2.1.
For the IPv4 service in LAA model, the VLANs are terminated on the
BRAS and PPP sessions are terminated on the Edge Router (LNS). For
IPv6 service in Point-to-Point model, the VLANs are terminated at
the Edge Router as described in section 7.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 7.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 VLANs
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 7.2.4.2.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 34]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
IPv6 <---------------->
ATM +-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 <---------------------------------------->
PPP
<------------>
L2TPv2
Figure 7.2.4.2
7.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
RFC3306 the large address space provides the means to assign global
multicast group addresses to organizations or users that were
assigned unicast prefixes. It is a significant improvement with
respect to the IPv4 GLOP mechanism [RFC2770].
This facilitates the deployment of multicast services. The
discussion of this section applies to all the multicast sections
in the document.
7.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 PIM-SM protocol and it is more complex
to manage because of the use of Rendevous Points (RPs). With IPv6,
static RP and BSR [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].
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 35]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
For multicast reachability across domains, Embedded RP could be
used. Despite its shortcomings, MSDP provides additional
flexibility in managing the domains that may not be matched with
the protocols available in IPv6 today. The value of such
flexibility is still under evaluation.
7.3.2 SSM Based Deployments
Based on PIM-SSM, the Source Specific Multicast deployments do not
need an RP and the related protocols (such as BSR or MSDP) but rely
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 is 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 services 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 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 customer premises router, its
limited resources should be taken into consideration.
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 customer
premises routers. 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 is usually
configured on the edge router in order to enable the ISP to do
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.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 36]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
7.4 IPv6 QoS
The QoS configuration is particularly relevant on the router that
represents the Layer-3 next hop for the subscriber (BRAS in the PTA
model or the Edge router in the LAA and Point-to-Point model) in
order to manage resources shared amongst multiple subscribers
possibly with various service level agreements.
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 it is
beyond the scope of this document.
On the BRAS or the Edge Router the subscriber facing interfaces have
to be configure to police the inbound customer traffic and shape the
traffic outbound to the customer based on the SLAs. Traffic
classification and marking should also be done on the router closest
(at layer 3) to the subscriber in order to support the various types
of customer traffic: data, voice, video and to optimally use the
infrastructure resources. Each provider (NAP, NSP) could implement
their own QoS policies and services so 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
the IPv6 as well.
7.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
[RFC 3041] 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 /128 address level,
the Privacy Extensions can be implemented only in parallel with
network management tools that could provide trace-ability of the
hosts. IPv6 firewall functions should be enabled on the hosts or
customer premises router if present.
The ISP provides security against attacks that come form 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 (ICMPv6 types). Authentication and authorization
should be used wherever possible.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 37]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
The BRAS and the Edge Router should protect their processing
resources against floods of valid customer control traffic such as:
Router and Neighbor Solicitations, 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.
All other security features used with the IPv4 service should be
similarly applied to IPv6 as well.
7.6 IPv6 Network management
The necessary instrumentation (such as MIBs, 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
existent 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 stations are
located on the core network. 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.
8. Broadband Ethernet Networks
This section describes the IPv6 deployment options in currently
deployed Broadband Ethernet Access Networks.
8.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
[ISP Transition Scenarios]:
Access Switch: It is used as a Layer 2 access device for subscribers.
Customer Premises Router: It is used to provide layer 3 services
for customer premises networks.
Aggregation Ethernet Switches: Aggregates multiple subscribers.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 38]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
Broadband Remote Access Server (BRAS)
Edge Router (ER)
Figure 8.1 depicts all the network elements mentioned.
Customer Premises | 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 8.1
The logical topology and design of Broadband Ethernet Networks is
very similar to DSL Broadband Networks discussed in section 6.
8.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 8.2.1.
B. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened
between each subscriber and the BRAS. The BRAS terminates the PPP
sessions and provides Layer 3 connectivity between the subscriber
and the ISP.
This model is presented in section 8.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
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 39]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
into L2TPv2 tunnels.
This model is presented in section 8.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 existent revenue generating IPv4 services, the
IPv6 deployment will match the IPv4 one. This approach is presented
in sections 8.2.1-3 that describes 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
8.2.4.
8.2.1 Point-to-Point Model
In this scenario the Ethernet frames from the Host or the Customer
Premises Router are bridged over the VLAN assigned to the subscriber.
Figure 8.2.1 describes the protocol architecture of this model.
Customer Premises NAP NSP
<-------------------------> <---------------> <-------------------->
+-----+ +------+ +------+ +--------+ +----------+
|Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP
+-----+ +------+ |Switch| +--------+ 802.1q | Router +==> Network
+------+ +----------+
<---------------------------->
Ethernet/VLANs
Figure 8.2.1
8.2.1.1 IPv6 Related Infrastructure Changes
In this scenario the Access Switch 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.
8.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
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 40]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
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 autoconfiguration or statefull DHCPv6
based configuration to acquire an address via the Edge Router.
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 dynamically acquires through stateless autoconfiguration the
address for the link between itself and the Edge Router. This step
is followed by a request via DHCP-PD for a prefix shorter then /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 as well, have to
be enabled to support the feature. Currently the DHCP-PD
functionality cannot be implemented if the DHCP-PD server is not the
Edge Router. If the DHCP-PD messages are relayed, the Edge Router
does not have a mechanism to learn the assigned prefixes and thus
install the proper routes to make that prefix reachable. Work is
being done to address this issue, one idea being to provide the Edge
Router with a snooping mechanism. The uplink to the ISP network is
configured with a /64 prefix as well.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 statefull [RFC3315] and stateless [RFC3736] DHCPv6.
8.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 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.
8.2.2 PPP Terminated Aggregation (PTA) Model
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 41]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
The PTA architecture relies on PPP-based protocols (PPPoE). The PPP
sessions are initiated by Customer Premise Equipment and it is
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. This model is often used when the
NSP is also the NAP.
The PPPoE logical diagram in an Ethernet Broadband Network is shown
in Fig 8.2.2.1.
Customer Premises NAP NSP
<---------------------------> <-----------------> <----------------->
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
+-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O
<---------------- PPP ----------------> | | R
+-----------+ E
Figure 8.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 a remote database. Once the session is established, the
BRAS provides an address and maybe a DNS server to the user,
information acquired from the subscriber profile or from a DHCP
server.
This model allows for multiple PPPoE session 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.
8.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 PPPoE with IPv6. The following devices have to be upgraded to
dual stack: Host, Customer Router (if present), BRAS and Edge Router.
8.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 a AAA server. The Hosts or the Customer
Routers have the BRAS as their Layer 3 next hop.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 42]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
The PPP session can be initiated by a host or by a Customer Router.
In the later 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.
Currently the DHCP-PD functionality cannot be implemented if the
DHCP-PD server is not the Edge Router. If the DHCP-PD messages are
relayed, the Edge Router does not have a mechanism to learn the
assigned prefixes and thus install the proper routes to make that
prefix reachable. Work is being done to address this issue, one idea
being to provide the Edge Router with a snooping mechanism. The
uplink to the ISP network is configured with a /64 prefix as well.
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 subscriber 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 statefull [RFC3315] and stateless [RFC3736] DHCPv6.
8.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 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.
8.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.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 43]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
Customer Premises NAP NSP
<--------------------> <----------------------> <----------------->
+-----------+
| AAA |
+------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O
| | R
+-----------+ E
<----------------------------------------------->
PPP
<-------------->
L2TPv2
Figure 8.2.3.1
8.2.3.1 IPv6 Related Infrastructure Changes
In this scenario the BRAS is layer-3 aware and it 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.
8.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 a 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 later 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. Currently the DHCP-PD functionality cannot be
implemented if the DHCP-PD server is not the Edge Router. If the
DHCP-PD messages are relayed, the Edge Router does not have a
mechanism to learn the assigned prefixes and thus install the proper
routes to make that prefix reachable. Work is being done to address
this issue, one idea being to provide the Edge Router with a snooping
mechanism. The uplink to the ISP network is configured with a /64
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 44]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
prefix as well.
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 statefull [RFC3315] and stateless [RFC3736] DHCPv6.
The address assignment and prefix summarization issues discussed in
section 7.2.3.2 are relevant in the same way for this media access
type as well.
8.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 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.
8.2.4 Hybrid Model for IPv4 and IPv6 Service
It was recommended throughout this section that the IPv6 service
implementation should map the existent 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 SP decides to offer
multicast services over such a design, it will face the problem of
NAP resources being over utilized. The multicast traffic can be
replicated only at the end of the tunnels by the Edge router and the
copies for all the subscribers are carried over the entire NAP.
A Modified Point-to-Point (see section 8.2.4.2) or a PTA model is
more suitable to support multicast services because the packet
replication can be done closer to the destination at the BRAS.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 45]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
Such topology saves NAP resources.
In this sense IPv6 deployments can be viewed as an opportunity to
build an infrastructure that can better support the expansion of
services. In this case, an SP using the LAA design for its IPv4
services might choose a modified Point-to-Point or PTA design for
IPv6.
8.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 straight forward. It is a straight forward overlap of the
two deployment models. The PPP sessions are terminated on
different network devices for the IPv4 and IPv6 services. The PPP
sessions for the existent 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 8.2.4.1.
IPv6 <-------------------------->
PPP +-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 <---------------------------------------->
PPP
<------------>
L2TPv2
Figure 8.2.4.1
8.2.4.2 IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model
The coexistence of the modified Point-to-Point and the LAA models
implies a few specific changes.
For the IPv4 service in LAA model, the VLANs are terminated on the
BRAS and PPP sessions are terminated on the Edge Router (LNS). For
IPv6 service in Point-to-Point model, the VLANs are terminated at
the Edge Router as described in section 7.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
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 46]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
Router as described in section 7.2.1 are now implemented on the BRAS.
The logical design for IPv6 and IPv4 in this hybrid model is
in Figure 8.2.4.2.
IPv6 <---------------->
Ethernet
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 <---------------------------------------->
PPP
<------------>
L2TPv2
Figure 8.2.4.2
8.3 IPv6 Multicast
The typical multicast services 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
manage. PIM-SSM has to be enabled throughout the ISP network. MLDv2
is required for PIM-SSM support. Vendors can choose to implement
features that allow routers to map MLDv1 group joins to predefined
sources.
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 customer premises router,
its limited resources should be taken into consideration.
MLD snooping or similar layer two multicast related protocols could
be enabled on the NAP switches.
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)
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 47]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
has to be enabled to support MLDv1 and MLDv2 in order to process the
requests coming from subscribers without customer premises routers.
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 is usually
configured on the edge router in order to enable the ISP to do
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.
Please refer to section 7.3 for more IPv6 multicast details.
8.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.
On the BRAS or the Edge Router the subscriber facing interfaces have
to be configure to police the inbound customer traffic and shape the
traffic outbound to the customer based on the SLAs. Traffic
classification and marking should also be done on the router closest
(at layer 3) to the subscriber in order to support the various types
of customer traffic: data, voice, video and to optimally use the
network resources. This infrastructure offers a very good opportunity
to leverage the QoS capabilities of Layer two devices. DiffServ based
QoS used for IPv4 should be expanded to IPv6.
Each provider (NAP, NSP) could implement their own QoS policies and
services so reclassification and marking might be performed at the
boundary between the NAP and the NSP in order to make sure the
traffic is properly handled by the ISP.
The same IPv4 QoS concepts and methodologies should be applied for
the IPv6 as well.
8.5 IPv6 Security Considerations
There are limited changes that have to be done for CPEs in order to
enhance security. The Privacy extensions [RFC3041] for
autoconfiguration should be used by the hosts with the same
considerations for host trace-ability as discussed in section 7.5.
IPv6 firewall functions should be enabled on the hosts or customer
premises router if present.
The ISP provides security against attacks that come form 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
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 48]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
network discussed here.
If any layer two filters for Ethertypes are in place, the NAP must
permit the IPv6 Ethertype (0X86DD).
The device that is the Layer-3 next hop for the subscribers (BRAS
Edge router) should protect the network and the other subscribers
against attacks by one of the provider customers. For this reason
uRPF and ACLs should be used on all interfaces facing subscribers.
Filtering should be implemented with regard for the operational
requirements of IPv6 (ICMPv6 types). Authentication and authorization
should be used wherever possible.
The BRAS and the Edge Router should protect their processing
resources against floods of valid customer control traffic such as:
Router and Neighbor Solicitations, 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.
All other security features used with the IPv4 service should be
similarly applied to IPv6 as well.
8.6 IPv6 Network Management
The necessary instrumentation (such as MIBs, 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 existent
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 stations are
located on the core network. 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.
9. Wireless LAN
This section provides detailed description of IPv6 deployment and
integration methods in currently deployed wireless LAN (WLAN)
infrastructure.
9.1 WLAN Deployment Scenarios
WLAN enables subscribers to connect to the Internet from various
locations without the restriction of staying indoors. WLAN is
standardized by IEEE 802.11x. Consideration should be also given to
IEEE 802.16 WiMAX for similar deployment approaches. IEEE 802.11
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 49]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
offers maximum transmission speed from 1 or 2 Mbps, IEEE 802.11b
offers 11 Mbps and IEEE 802.11a offers up to 54 Mbps.
Figure 9.1 describes the current WLAN architecture.
Customer Premises| Access Provider |Service Provider
| |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | |Access Router/| |Underlying| |Edge |
|Host/ |-(WLAN)-|AP|-|Layer2 Switch |-|Technology|-|Router|=>SP
|Router| ---- | | | | | | | | Network
+------+ +--+ +--------------+ +----------+ +------+
|
+------+
|AAA |
|Server|
Figure 9.1 +------+
The host should have a wireless network interface card (NIC) in order
to connect to a WLAN network. WLAN is a flat broadcast network and
works in a similar fashion as Ethernet. When hosts initiate a
connection, it is authenticated by the AAA server located at the
SP network. All the authentication parameters (username, password
and etc.) are forwarded by the Access Point (AP) to the AAA server.
The AAA server authenticates the host, once authenticated
successfully the host can send data packets. The AP is located near
the host and acts as a bridge. The AP forwards all the packets
coming to/from host to the Edge Router. The underlying connection
between the AP and Edge Router could be based on any access layer
technology such as HFC/Cable, FTTH, xDSL or etc.
WLANs are based in limited areas known as WiFi Hot Spots. While users
are present in the area covered by the WLAN range, they can be
connected to the Internet given they have a wireless NIC and required
configuration settings in their devices (notebook PCs, PDA or etc.).
Once the user initiates the connection the IP address is assigned by
the SP using DHCPv4. In most of the cases SP assigns limited
number of public IP addresses to the its customer. When the user
disconnects the connection and move to a new WiFi hot spot, the above
mentioned process of authentication, address assignment and accessing
the Internet is repeated.
There are IPv4 deployments where customers can use WLAN routers to
connect over wireless to their service provider. This deployment
types do not fit in the typical Hot Spot concept but they rather
address fixed customers. For this reason this section discusses the
WLAN router options as well. In this case, the ISP provides a public
IP address and the WLAN Router assigns private addresses [RFC 1918]
to all WLAN users. The WLAN Router provides NAT functionality while
WLAN users access the Internet.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 50]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
A detailed description of current WLAN infrastructure using IPv4 is
explained in [ISP Transition Scenarios].
While deploying IPv6 in the above mentioned WLAN architecture, there
are three possible scenarios as discussed below.
A. Layer2 Switch Between AP and Edge Router
B. Access Router Between AP and Edge Router
C. PPP Based Model
9.1.1 Layer2 Switch Between AP and Edge Router
When a Layer2 switch is present between AP and Edge Router, the AP
and Layer2 switch continues to work as a bridge, forwarding IPv4
and IPv6 packets from WLAN Host/Router to Edge Router and vice
versa.
When initiating the connection, the WLAN host is authenticated by the
AAA server located at the SP network. All the parameters related to
authentication (username, password and etc.) are forwarded by the AP
to the AAA server. The AAA server authenticates the WLAN Hosts and
once authenticated and associated successfully with WLAN AP, IPv6
address will be acquired by the WLAN Host. Note the initiation and
authentication process is same as used in IPv4.
Figure 9.1.1 describes the WLAN architecture when Layer2 Switch is
located between AP and Edge Router.
Customer Premises| Access Provider |Service Provider
| |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | |Underlying| |Edge |
|Host/ |-(WLAN)-|AP|-|Layer2 Switch |-|Technology|-|Router|=>SP
|Router| ---- | | | | | | | | Network
+------+ +--+ +--------------+ +----------+ +------+
|
+------+
|AAA |
|Server|
+------+
Figure 9.1.1
9.1.1.1 IPv6 Related Infrastructure Changes
IPv6 will be deployed in this scenario by upgrading the following
devices to dual-stack: WLAN Host, WLAN Router (if present) and Edge
Router.
9.1.1.2 Addressing
When customer WLAN Router is not present, the WLAN Host has two
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 51]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
possible options to get an IPv6 address via the Edge Router.
A. The WLAN host can get the IPv6 address from Edge router using
stateless auto-configuration [RFC 2462]. All the hosts on the WLAN
belong to the same /64 subnet that is statically configured on the
Edge Router. The IPv6 WLAN Host may use stateless DHCPv6 for
obtaining other information of interest such as DNS and etc.
B. IPv6 WLAN host can use DHCPv6 [RFC 3315] to get a IPv6 address
from the DHCPv6 server. In this case the DHCPv6 server would be
located in the SP core network and Edge Router would act simply as
a DHCP Relay Agent. This option is similar to what we do today in
case of DHCPv4. It is important to note that host implementation of
statefull auto-configuration is rather limited at this time and this
should be considered if choosing this address assignment option.
When a customer WLAN Router is present, the WLAN Host has two
possible options as well for acquiring IPv6 address.
A. The WLAN Router may be assigned a prefix between /48 and /64
depending on the SP policy and customer requirements. If the WLAN
Router has multiple networks connected to its interfaces, the network
administrator will have to configure the /64 prefixes to the WLAN
Router interfaces connecting the WLAN Hosts on the customer site.
The WLAN Hosts connected to these interfaces can automatically
configure themselves using stateless auto-configuration with /64
prefix.
B. The WLAN Router dynamically acquires an address through
stateless auto-configuration for the link between itself and the Edge
Router. This step is followed by a request using DHCP Prefix
Delegation (PD) [RFC 3633] for a prefix. In this option, the WLAN
Router would act as a requesting router and Edge Router would act
as delegating router. Once prefix is received by the WLAN Router,
it assigns /64 prefixes to each of its interfaces connecting the
WLAN Hosts on the customer site. The WLAN Hosts connected to these
interfaces can automatically configure themselves using stateless
auto-configuration with /64 prefix. Currently the DHCP-PD
functionality cannot be implemented if the DHCP-PD server is not the
Edge Router. If the DHCP-PD messages are relayed, the Edge Router
does not have a mechanism to learn the assigned prefixes and thus
install the proper routes to make that prefix reachable. Work is
being done to address this issue, one idea being to provide the Edge
Router with a snooping mechanism. The uplink to the ISP network is
configured with a /64 prefix as well.
Usually it is easier for the SPs to stay with the DHCP PD and
stateless auto-configuration model and point the clients to a
central server for DNS/domain information, proxy configurations and
etc. Using this model the SP could change prefixes on the fly
and the WLAN Router would simply pull the newest prefix based on the
valid/preferred lifetime.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 52]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
The prefixes used for subscriber links and the ones delegated via
DHCP-PD should be planned in a manner that allows maximum
summarization as possible at the Edge Router.
Other information of interest to the host, such as DNS, is provided
through statefull [RFC3315] and stateless [RFC3736] DHCPv6.
9.1.1.3 Routing
The WLAN Host/Router are configured with a default route that points
to the Edge router. No routing protocols are needed on these devices
which have limited resources.
The Edge Router runs the IGP used in the SP network such as OSPFv3
or IS-IS for IPv6. The connected prefixes have to be redistributed.
Prefix summarization should be done at the Edge Router. When DHCP-PD
is used, the IGP has to redistribute the static routes installed
during the process of prefix delegation.
9.1.2 Access Router Between AP and SP Edge Router
When a Access Router is present between AP and Edge Router, the AP
continues to work as a bridge, bridging IPv4 and IPv6 packets from
WLAN Host/Router to Access/Edge Router and vice versa. The Access
Router could be part of SP network or owned by a separate Access
Provider.
When WLAN Host initiates the connection, the AAA authentication and
association process with WLAN AP will be similar as explained in
section 9.1.1.
Figure 9.1.2 describes the WLAN architecture when Access Router is
located between AP and Edge Router.
Customer Premises| Access Provider |Service Provider
| |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | |Underlying| |Edge |
|Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP
|Router| ---- | | | | | | | | Network
+------+ +--+ +--------------+ +----------+ +------+
|
+------+
|AAA |
|Server|
+------+
Figure 9.1.2
9.1.2.1 IPv6 Related Infrastructure Changes
IPv6 is deployed in this scenario by upgrading the following devices
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 53]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
to dual-stack: WLAN Host, WLAN Router (if present), Access Router
and Edge Router.
9.1.2.2 Addressing
There are three possible options in this scenario for IPv6 address
assignment:
A. The Edge Router interface facing towards the Access Router is
statically configured with /64 prefix. The Access Router receives/
configures an /64 prefix on its interface facing towards Edge
Router through stateless auto-configuration. The network
administrator will have to configure the /64 prefixes to the Access
Router interface facing towards the customer premises. The WLAN
Host/Router connected to this interface can automatically configure
themselves using stateless auto-configuration with /64 prefix.
B. This option uses DHCPv6 [RFC3315] for IPv6 prefix assignments to
the WLAN Host/Router. There is no use of DHCP PD or stateless
auto-configuration in this option. The DHCPv6 server can be located
on the Access Router, on the Edge Router or somewhere in the SP
network. In this case depending on where the DHCPv6 server is
located, Access Router or the Edge Router would relay the DHCPv6
requests.
C. The Access Router dynamically acquires an address through
statelss auto-configuration for the link between itself and the
Edge Router. This step is followed by a request using DHCP Prefix
Delegation (PD) [RFC3633] for a prefix. In this option, the Access
Router would act as a requesting router and Edge Router would act
as delegating router. Once prefix is received by the Access Router,
it assigns /64 prefixes to each of its interfaces connecting the
WLAN Host/Router on customer site. The WLAN Host/Router connected
to these interfaces can automatically configure themselves using
stateless auto-configuration with /64 prefix. Currently the DHCP-PD
functionality cannot be implemented if the DHCP-PD server is not the
Edge Router. If the DHCP-PD messages are relayed, the Edge Router
does not have a mechanism to learn the assigned prefixes and thus
install the proper routes to make that prefix reachable. Work is
being done to address this issue, one idea being to provide the
Edge Router with a snooping mechanism. The uplink to the ISP
network is configured with a /64 prefix as well.
It is easier for the SPs to stay with the DHCP PD and stateless
auto-configuration model and point the clients to a central
server for DNS/domain information, proxy configurations and others.
Using this model the provider could change prefixes on the fly and
the Access Router would simply pull the newest prefix based on the
valid/preferred lifetime.
As mentioned before the prefixes used for subscriber links and the
ones delegated via DHCP-PD should be planned in a manner that
allows maximum summarization possible at the Edge Router.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 54]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
Other information of interest to the host, such as DNS, is provided
through statefull [RFC3315] and stateless [RFC3736] DHCPv6.
9.1.2.3 Routing
The WLAN Host/Router are configured with a default route that points
to the Access Router. No routing protocols are needed on these
devices which have limited resources.
If the Access Router is owned by an Access Provider, then the Access
Router can have a default route, pointing towards the SP Edge
Router. The Edge Router runs the IGP used in the SP network such as
OSPFv3 or IS-IS for IPv6. The connected prefixes have to be
redistributed. If DHCP-PD is used, with every delegated prefix a
static route is installed by the Edge Router. For this reason the
static routes must be redistributed. Prefix summarization should be
done at the Edge Router.
If the Access Router is owned by the SP, then Access Router will also
run IPv6 IGP and will be part of SP IPv6 routing domain (OSPFv3
or IS-IS). The connected prefixes have to be redistributed. If
DHCP-PD is used, with every delegated prefix a static route is
installed by the Access Router. For this reason the static routes
must be redistributed. Prefix summarization should be done at the
Access Router.
9.1.3 PPP Based Model
PPP TERMINATED AGGREGATION (PTA) and L2TPv2 ACCESS AGGREGATION (LAA)
models as discussed in sections 7.2.2 and 7.2.3 respectively can
also be deployed in IPv6 WLAN environment.
9.1.3.1 PTA Model in IPv6 WLAN Environment
While deploying the PTA model in IPv6 WLAN environment the Access
Router is Layer3 aware and it has to be upgraded to support IPv6.
Since the Access Router terminates the PPP sessions initiated by
WLAN Host/Router, it has to support PPPoE with IPv6.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 55]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
Figure 9.1.3.1 describes the PTA Model in IPv6 WLAN environment
Customer Premises| Access Provider |Service Provider
| |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | |Underlying| |Edge |
|Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP
|Router| ---- | | | | | | | | Network
+------+ +--+ +--------------+ +----------+ +------+
|
<---------------------------> +------+
PPP |AAA |
|Server|
+------+
Figure 9.1.3.1
9.1.3.1.1 IPv6 Related Infrastructure Changes
IPv6 is deployed in this scenario by upgrading the following
devices to dual-stack: WLAN Host, WLAN Router (if present),
Access Router and Edge Router.
9.1.3.1.2 Addressing
The addressing techniques described in section 7.2.2.2 applies to
IPv6 WLAN PTA scenario as well.
9.1.3.1.3 Routing
The routing techniques described in section 7.2.2.3 applies to
IPv6 WLAN PTA scenario as well.
9.1.3.2 LAA Model in IPv6 WLAN Environment
While deploying the LAA model in IPv6 WLAN environment the Access
Router is Layer3 aware and it has to be upgraded to support IPv6.
The PPP sessions initiated by WLAN Host/Router are forwarded over
the L2TPv2 tunnel to the aggregation point in the SP network. The
Access Router must have the capability to support L2TPv2 for IPv6.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 56]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
Figure 9.1.3.2 describes the LAA Model in IPv6 WLAN environment
Customer Premises| Access Provider |Service Provider
| |
+------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | |Underlying| |Edge |
|Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP
|Router| ---- | | | | | | | | Network
+------+ +--+ +--------------+ +----------+ +------+
|
<-------------------------------------------------->|
PPP |
<--------------------->|
L2TPv2 |
+------+
|AAA |
|Server|
+------+
Figure 9.1.3.2
9.1.3.2.1 IPv6 Related Infrastructure Changes
IPv6 is deployed in this scenario by upgrading the following
devices to dual-stack: WLAN Host, WLAN Router (if present),
Access Router and Edge Router.
9.1.3.2.2 Addressing
The addressing techniques described in section 7.2.3.2 applies to
IPv6 WLAN LAA scenario as well.
9.1.3.2.3 Routing
The routing techniques described in section 7.2.3.3 applies to
IPv6 WLAN LAA scenario as well.
9.2 IPv6 Multicast
The typical multicast services offered are video/audio streaming
where the IPv6 WLAN Host joins a multicast group and receives the
content. This type of service model is well supported through
PIM-SSM which is enabled throughout the SP network. MLDv2 is required
for PIM-SSM support. Vendors can choose to implement features that
allow routers to map MLDv1 group joins to predefined sources.
It is important to note that in the shared wireless environments
multicast can have a significant bandwidth impact. For this reason
the bandwidth allocated to multicast traffic should be limited and
fixed based on the overall capacity of the wireless specification
used 802.11a, 802.11b or 802.11g.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 57]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
The IPv6 WLAN Hosts can also join desired multicast groups as
long as they are enabled to support MLDv1 or MLDv2. If a
WLAN/Access Routers are used then they have to be enabled to
support MLDv1 and MLDv2 in order to process the requests of the
IPv6 WLAN Hosts. The WLAN/Access Router should also needs to be
enabled to support PIM-SSM in order to send PIM joins up to the
Edge Router. When enabling this functionality on a WLAN/Access
Router, its limited resources should be taken into consideration.
The Edge Router has to be enabled to support MLDv1 and MLDv2 in
order to process the requests coming from IPv6 WLAN Host or
WLAN/Access Router (if present). The Edge Router has also needs
to be enabled for PIM-SSM in order to receive joins from IPv6
WLAN Hosts or WLAN/Access Router (if present) and send joins
towards the SP core.
MLD authentication, authorization and accounting is usually
configured on the Edge Router in order to enable the SP to do
billing for the content services provided. Further investigation
should be made in investigating alternative mechanisms that would
support these functions.
The IETF draft [IPv6 over 802.11] mentions some of the concerns
related to running IPv6 multicast over WLAN links. Potentially
these are same kind of issues when running any Layer3 protocol
over a WLAN link that has a high loss-to-signal ratio, certain
frames that are multicast based are dropped when settings are not
adjusted properly. For instance this behavior is similar to IGMP host
membership report, when done on a WLAN link with high loss-to-signal
ratio and high interference. This problem is inherited to WLAN that
can impact both IPv4 and IPv6 multicast packets and not specific to
IPv6 multicast.
While deploying WLAN (IPv4 or IPv6), one should adjust their
broadcast/multicast settings if they are in danger of dropping
application dependent frames. These problems are usually caused when
AP are placed too far apart (not following the distance limitations),
high interference and etc. These issues may impact a real multicast
application such as streaming video or basic operation of IPv6 if
the frames were dropped. Basic IPv6 communications uses functions
such as Duplicate Address Detection (DAD), Router and Neighbor
Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA)
and etc. which could be impacted by the above mentioned issues as
these frames are Layer2 Ethernet multicast frames.
Please refer to section 7.3 for more IPv6 multicast details.
9.3 IPv6 QoS
Today, QoS is done outside of the WiFi domain but it is
nevertheless important to the overall deployment.
The QoS configuration is particularly relevant on the Edge Router in
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 58]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
order to manage resources shared amongst multiple subscribers
possibly with various service level agreements (SLA). Although, the
WLAN Host/Router and Access Router could also be configured for QoS.
This includes support for IPv6 classifiers, so that data traffic
to/from IPv6 WLAN Host/Router, Access Router and Edge Router can be
classified appropriately into different service flows (SF) and be
assigned appropriate priority. Appropriate classification criteria
would need to be implemented for IPv6 unicast and multicast traffic.
On the Edge Router the subscriber facing interfaces have to be
configure to police the inbound customer traffic and shape the
traffic outbound to the customer, based on the SLA. Traffic
classification and marking should also be done on the Edge router in
order to support the various types of customer traffic: data, voice,
video. The same IPv4 QoS concepts and methodologies should be applied
for the IPv6 as well.
9.4 IPv6 Security Considerations
There are limited changes that have to be done for WLAN Host/Router
in order to enhance security. The Privacy extensions [RFC3041] for
autoconfiguration should be used by the hosts with the same
consideration for host trace-ability as described in section 7.5.
IPv6 firewall functions should be enabled on the WLAN Host/Router if
present.
The ISP provides security against attacks that come form 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.
If any layer two filters for Ethertypes are in place, the NAP must
permit the IPv6 Ethertype (0X86DD).
The device that is the Layer3 next hop for the subscribers
(Access or Edge Router) should protect the network and the other
subscribers against attacks by one of the provider customers.
For this reason uRPF and ACLs should be used on all interfaces
facing subscribers. Filtering should be implemented with regard
for the operational requirements of IPv6 (ICMPv6 types).
Authentication and authorization should be used wherever possible.
The Access and the Edge Router should protect their processing
resources against floods of valid customer control traffic such as:
RS, NS, 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.
9.5 IPv6 Network Management
The necessary instrumentation (such as MIBs, NetFlow Records, etc)
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 59]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
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 existent
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 stations are
located on the core network. 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.
10. Gap Analysis
Several aspects of deploying IPv6 over SP Broadband networks were
highlighted in this document, aspects that require additional work
in order to facilitate native deployments as summarized below:
A. As mentioned in section 6, changes will need to be made to the
DOCSIS specification in order for SPs to deploy native IPv6 over
cable networks. The CM and CMTS will both need to support IPv6
natively in order to forward IPv6 unicast and multicast traffic.
This is required for IPv6 Neighbor Discovery to work over DOCSIS
cable networks. Additional classifiers need to be added to the
DOCSIS specification in order to classify IPv6 traffic at the CM
and CMTS in order to provide QoS.
B. Currently the DHCP-PD functionality cannot be implemented if the
DHCP-PD server is not the Edge Router. If the DHCP-PD messages are
relayed, the Edge Router does not have a mechanism to learn the
assigned prefixes and thus install the proper routes to make that
prefix reachable. Work needs to be done to address this issue, one
idea being to provide the Edge Router with a snooping mechanism. The
uplink to the ISP network is configured with a /64 prefix as well.
C. Section 7 stated that current RBE based IPv4 deployment might not
be the best approach for IPv6. The addressing space available gives
the SP the opportunity to separate the users on different subnets.
If however, support is found for a deployment similar to IPv4,
and if the SP chooses to let subscribers talk amongst themselves
directly, then special consideration should be give to the ND
operation at the Edge Router.
D. Section 7 discussed the constraints imposed on a LAA based IPv6
deployment by the fact that it is expected that the subscribers keep
their assigned prefix regardless of LNS. A deployment approach was
proposed that would maintain the addressing schemes contiguous and
offers prefix summarization opportunities. The topic could be
further investigated for other solutions or improvements.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 60]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
E. Sections 7 and 8 pointed out the limitations (previously
documented in [IPv6 Multicast]) in deploying inter-domain ASM
however, SSM based services seem more likely at this time. For such
SSM based services of content delivery (video or Audio), mechanisms
are needed to facilitate the billing and management of listeners.
The currently available feature of MLD AAA is suggested however,
other methods or mechanisms might be developed and proposed.
F. In relation to section 9, the IETF draft [IPv6 over 802.11]
mentions some of the concerns related to running IPv6 multicast
over WLAN links. Potentially these are same kind of issue when
running any Layer3 protocol over a WLAN link that has a high
loss-to-signal ratio, certain frames that are multicast based are
dropped when settings are not adjusted properly. For instance this
behavior is similar to IGMP host membership report, when done on
a WLAN link with high loss-to-signal ratio and high interference.
This problem is inherited to WLAN that can impact both IPv4 and
IPv6 multicast packets and not specific to IPv6 multicast.
The IETF draft [IPv6 over 802.11] raises some other concerns as
well related to IPv6 mechanisms and WLAN, which should be addressed
and resolved by the standard bodies.
G. The Privacy Extensions were mentioned as a popular means to
provide some form of host security. ISPs can track relatively
easily the prefixes assigned to subscribers. If however the ISPs
are required by regulations to track their users at host address
level, the Privacy Extensions [RFC3041] can be implemented only in
parallel with network management tools that could provide
trace-ability of the hosts. Mechanisms should be defined to
implement this aspect of user management.
H. Tunnels are an effective way to avoid deployment dependencies on
the IPv6 support on platforms that are out of the SP control (GWRs
or CPEs) or over technologies that did not standardize the IPv6
support yet (cable). They can be used in the following ways:
i. Tunnels directly to the CPE or GWR with public or private IPv4
addresses.
ii. Tunnels directly to hosts with public or private IPv4 addresses.
Recommendations on the exact tunneling mechanisms that can/should be
used for last mile access need to be investigated further and should
be covered in a future IETF draft.
I.Through its larger address space, IPv6 allows SPs to assign fixed,
globally routable prefixes to the link connecting each subscriber.
This approach changes the addressing methodologies that were used
for IPv4. Static configuration of the addresses on the Edge Routers
or Access Routers might not be a scalable option. Provisioning
mechanisms might need further investigation for deployments that
are not PPP based.
The outcome of solutions to some of these topics ranges from making
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 61]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
a media access capable of supporting native IPv6 (cable) to improving
operational aspects of native IPv6 deployments.
11. Contributors
We would like to thank Pekka Savola for his contribution, guidance
and feedback in order to improve this document.
12. Acknowledgements
We would like to thank Brian Carpenter, Patrick Grossetete, Toerless
Eckert, Madhu Sudan, Shannon McFarland and Benoit Lourdelet for their
valuable comments. The authors would like to acknowledge the
structure and information guidance provided to this work by
[ISP Transition Scenarios].
13. References
Normative References
[RFC3053]
Durand A., Fasano P., Guardini I., Lento D. "IPv6 Tunnel Broker",
RFC3053, January 2001.
[RFC3056]
Carpenter B., Moore K., "Connection of IPv6 Domains via IPv4 Clouds",
RFC3056, February 2001.
[RFC2473]
Conta A., Deering S., "Generic Packet tunneling in IPv6
Specification", December 1998.
[RFC2893]
Gilligan R., Nordmark E., "Transition Mechanisms for IPv6 Hosts
and Routers", August 2000.
[RFC2529]
Carpenter B., Jung C. "Transmission of IPv6 over IPv4 Domains
without Explicit Tunnels", March 1999
[RFC3904]
Huitema C., Austein R., Satapati S., van der Pol R., "Evaluation
of IPv6 Transition Mechanisms for Unmanaged Networks", September 2000
[RFC 3513]
R. Hinden and S. Deering, "IP Version 6 Addressing Architecture",
RFC 3513, April 2003.
[RFC3736]
Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
Service for IPv6", RFC 3736, April 2004.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 62]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
[RFC3315]
Droms, R., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003.
[RFC2462]
Thomson, S. and Narten, T., "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3633]
Troan, O. and Droms, R., "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC 3041]
T. Narten and R. Draves, "Privacy Extensions for Stateless Address
Autoconfiguration in IPv6," RFC 3041, April 2001.
[RFC2516]
Mamakos, L., "A Method for Transmitting PPP Over Ethernet (PPPoE)",
RFC 2516, February 1999.
[RFC2364]
Gross, G., "PPP Over AAL5 (PPPoA)", RFC 2516, July 1998.
[RFC2472]
Haskin, D. and Allen, E., "IP Version 6 over PPP", RFC 2472,
December 1998.
[RFC2461]
Narten, T., Nordmark, E. and Simpson, W., "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2770]
Meyer. D., "GLOP Addressing in 233/8", RFC 2770, February 2000
[RFC3646]
Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3618]
Fenner B., Meyer D., "Multicast Source Discovery Protocol (MSDP)",
Informative References
[Dual Stack Access]
Shirasaki, et al., "A Model of IPv6/IPv4 Dual Stack Internet Access
Service", draft-shirasaki-dualstack-service-04.txt (work in
progress) ,April 2004.
[6PE] De Clercq J., et al., "Connecting IPv6 Islands across IPv4
Clouds with BGP:, draft-ietf-ngtrans-bgp-tunnel-04.txt, July 2002
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 63]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
[ISP Networks IPv6 Scenarios]
Lind et, al., "Scenarios and Analysis for Introducing IPv6 into ISP
Networks", draft-ietf-v6ops-isp-scenarios-analysis-03.txt (work in
progress), June 2004.
[ISATAP]
Templin F., et al., "Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP)", draft-ietf-ngtrans-isatap-12.txt, January 2003.
[Dynamic Tunnel]
Palet J., et al., "Analysis of IPv6 Tunnel End-point Discovery
Mechanisms", draft-palet-v6ops-tun-auto-disc-01.txt, June 2004.
[OPS]
Nordmark E., Gilligan R. E., "Basic Transition Mechanisms for
IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06.txt,
September 2004.
[IPv6 over 802.11]
Park, S., "Transmission of IPv6 Packets over 802.11/WLAN Networks",
draft-daniel-ipv6-over-wifi-01.txt, (work in progress), July 2004
[ISP Transition Scenarios]
Mickels, C., "Transition Scenarios for ISP Networks",
draft-mickles-v6ops-isp-cases-05.txt, March 2003
[DOCSIS 2.1 Proposal]
Sudan, M., "DOCSIS 2.1 Proposal", May 2004.
[IPv6 Multicast]
Savola, P. "IPv6 Multicast Deployment Issues",
draft-savola-v6ops-multicast-issues-03.txt, February 2004
[RF Interface]
Cable Labs, "Radio Frequency Interface Specification
SP-RFIv2.0-I02-020617", Jun 2002.
[BSR]
Nidhi Bhaskar et all., "Bootstrap Router (BSR) Mechanism for PIM",
draft-ietf-pim-sm-bsr-04.txt, January 2005
[Assisted Tunneling]
A.Durand, F. Parent,"Requirements for assisted tunneling",
draft-ietf-v6ops-assisted-tunneling-requirements-00.txt, June 2004
[ZeroConf]
Suryanarayanan, et al., "Zero-Configuration Tunneling Requirements",
draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt, October, 2004
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 64]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
Authors Addresses
Salman Asadullah
Cisco Systems, Inc.
170 West Tasman Drive,
San Jose, CA 95134, USA
Phone: 408 526 8982
Email: sasad@cisco.com
Adeel Ahmed
Cisco Systems, Inc.
2200 East President George Bush Turnpike,
Richardson, TX 75082, USA
Phone: 469 255 4122
Email: adahmed@cisco.com
Ciprian Popoviciu
Cisco Systems, Inc.
7025-6 Kit Creek Road,
Research Triangle Park, NC 27709, USA
Phone: 919 392 3723
Email: cpopovic@cisco.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology describe
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
draft-asadullah-v6ops-bb-deployment-scenarios-02.txt [Page 65]
INTERNET-DRAFT ISP IPv6 Deployment Scenarios in BB Networks Oct 2004
Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.