draft-ietf-v6ops-bb-deployment-scenarios-00.txt   draft-ietf-v6ops-bb-deployment-scenarios-01.txt 
IPv6 Working Group Salman Asadullah IPv6 Working Group Salman Asadullah
INTERNET DRAFT Adeel Ahmed INTERNET DRAFT Adeel Ahmed
February 2005 Ciprian Popoviciu April 2005 Ciprian Popoviciu
Cisco Systems Cisco Systems
Jordi Palet
Consulintel
ISP IPv6 Deployment Scenarios in Broadband Access Networks ISP IPv6 Deployment Scenarios in Broadband Access Networks
<draft-ietf-v6ops-bb-deployment-scenarios-00.txt> <draft-ietf-v6ops-bb-deployment-scenarios-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC3667. By submitting this Internet-Draft, each of section 3 of RFC3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC3668. RFC3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 27, 2005.
Abstract Abstract
This document provides detailed description of IPv6 deployment and This document provides detailed description of IPv6 deployment and
integration methods and scenarios in today's Service Provider (SP) integration methods and scenarios in today's Service Provider (SP)
Broadband (BB) networks in coexistence with deployed IPv4 services. Broadband (BB) networks in coexistence with deployed IPv4 services.
Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies
that are currently deployed, and discussed in this document. In this that are currently deployed, and discussed in this document. The
document we will discuss main components of IPv6 BB networks and emerging PLC/BPL access technology is also discussed for completion
their differences from IPv4 BB networks and how IPv6 is deployed purposes. In this document we will discuss main components of IPv6
and integrated in each of these BB technologies using tunneling BB networks and their differences from IPv4 BB networks and how IPv6
mechanisms and native IPv6. is deployed and integrated in each of these BB technologies using
tunneling mechanisms and native IPv6.
Table of Contents: Table of Contents:
1. Introduction..................................................3 1. Introduction..................................................3
2. IPv6 Based BB Services........................................3 2. IPv6 Based BB Services........................................4
3. Scope of the Document.........................................4 3. Scope of the Document.........................................5
4. Core Backbone Network.........................................5 4. Core Backbone Network.........................................5
4.1 Layer 2 Access Provider....................................5 4.1 Layer 2 Access Provider...................................6
4.2 Layer3 Access Provider....................................6 4.2 Layer3 Access Provider....................................6
5. Tunneling Options.............................................7 5. Tunneling Options.............................................7
5.1 Access over Tunnels-customers with public IPv4 address....7 5.1 Access over Tunnels-customers with public IPv4 address....7
5.2 Access over Tunnels-customers with private IPv4 address...7 5.2 Access over Tunnels-customers with private IPv4 address...8
5.3 Transition a portion of the IPv4 infrastructure...........8 5.3 Transition a portion of the IPv4 infrastructure...........8
6. Broadband Cable Networks .....................................9 6. Broadband Cable Networks .....................................9
6.1 Broadband Cable Network Elements .........................9 6.1 Broadband Cable Network Elements .........................9
6.2 Deploying IPv6 in Cable Networks.........................10 6.2 Deploying IPv6 in Cable Networks.........................10
6.2.1 Bridged CMTS Network .............................11 6.2.1 Bridged CMTS Network .............................11
6.2.2 Routed CMTS Network ..............................13 6.2.2 Routed CMTS Network ..............................14
6.3 IPv6 Multicast ..........................................22 6.3 IPv6 Multicast ..........................................22
6.4 IPv6 QoS ................................................22 6.4 IPv6 QoS ................................................22
6.5 IPv6 Security Considerations.............................23 6.5 IPv6 Security Considerations.............................23
6.6 IPv6 Network Management .................................23 6.6 IPv6 Network Management .................................24
7. Broadband DSL Networks.......................................24 6.6.1 Using IPv6 for Management in Cable Networks ......24
7.1 DSL Network Elements ....................................24 6.6.2 Updates to MIBs/Standards to support IPv6 ........25
7.2 Deploying IPv6 in IPv4 DSL Networks......................25 7. Broadband DSL Networks.......................................25
7.2.1 Point-to-Point Model..............................26 7.1 DSL Network Elements ....................................25
7.2.2 PPP Terminated Aggregation (PTA) Model............27 7.2 Deploying IPv6 in IPv4 DSL Networks......................26
7.2.3 L2TP Access Aggregation (LAA) Model...............30 7.2.1 Point-to-Point Model..............................27
7.2.4 Hybrid Model for IPv4 and IPv6 Service ...........33 7.2.2 PPP Terminated Aggregation (PTA) Model............29
7.3 IPv6 Multicast...........................................35 7.2.3 L2TP Access Aggregation (LAA) Model...............31
7.3.1 ASM Based Deployments..............................35 7.2.4 Hybrid Model for IPv4 and IPv6 Service ...........34
7.3.1 SSM Based Deployments..............................36 7.3 IPv6 Multicast...........................................36
7.4 IPv6 QoS.................................................37 7.3.1 ASM Based Deployments..............................36
7.5 IPv6 Security Considerations.............................37 7.3.1 SSM Based Deployments..............................37
7.6 IPv6 Network Management..................................38 7.4 IPv6 QoS.................................................38
8. Broadband Ethernet Networks..................................38 7.5 IPv6 Security Considerations.............................38
8.1 Ethernet Access Network Elements .......................38 7.6 IPv6 Network Management..................................39
8.2 Deploying IPv6 in IPv4 BB Ethernet Networks.............39 8. Broadband Ethernet Networks..................................39
8.2.1 Point-to-Point Model.............................40 8.1 Ethernet Access Network Elements .......................39
8.2.2 PPP Terminated Aggregation (PTA) Model...........41 8.2 Deploying IPv6 in IPv4 BB Ethernet Networks.............40
8.2.3 L2TP Access Aggregation (LAA) Model..............43 8.2.1 Point-to-Point Model.............................41
8.2.4 Hybrid Model for IPv4 and IPv6 Service...........45 8.2.2 PPP Terminated Aggregation (PTA) Model...........43
8.2.3 L2TP Access Aggregation (LAA) Model..............45
8.2.4 Hybrid Model for IPv4 and IPv6 Service...........46
8.3 IPv6 Multicast..........................................47 8.3 IPv6 Multicast..........................................47
8.4 IPv6 QoS................................................48 8.4 IPv6 QoS................................................49
8.5 IPv6 Security Considerations............................48 8.5 IPv6 Security Considerations............................50
8.6 IPv6 Network Management.................................49 8.6 IPv6 Network Management.................................50
9. Broadband Wireless LAN Networks..............................49 9. Broadband Wireless LAN Networks..............................51
9.1 WLAN Deployment Scenarios...............................49 9.1 WLAN Deployment Scenarios...............................51
9.1.1 Layer 2 Switch Between AP and SP Edge Router......51 9.1.1 Layer 2 Switch Between AP and SP Edge Router.....52
9.1.2 Access Router Between AP and SP Edge Router......53 9.1.2 Access Router Between AP and SP Edge Router......54
9.1.3 PPP Based Model..................................55 9.1.3 PPP Based Model..................................56
9.2 IPv6 Multicast..........................................57 9.2 IPv6 Multicast..........................................58
9.3 IPv6 QoS................................................58 9.3 IPv6 QoS................................................60
9.4 IPv6 Security Considerations............................59 9.4 IPv6 Security Considerations............................60
9.5 IPv6 Network Management.................................59 9.5 IPv6 Network Management.................................61
10.Gap Analysis.................................................60 10. Broadband Power Line Communications (PLC)...................61
11.Contributors.................................................62 10.1 PLC/BPL Access Network Elements.........................62
12.Acknowledgments..............................................62 10.2 Deploying IPv6 in IPv4 PLC/BPL..........................63
13.References...................................................62 10.2.1 IPv6 Related Infrastructure Changes..............63
Authors Addresses...............................................64 10.2.2 Addressing.......................................63
10.2.3 Routing..........................................64
10.3 IPv6 Multicast..........................................65
10.4 IPv6 QoS................................................65
10.5 IPv6 Security Considerations............................65
10.6 IPv6 Network Management.................................65
11. Gap Analysis................................................65
12. Contributors................................................67
13. Acknowledgments.............................................67
14. References..................................................67
Authors Addresses...............................................70
1. Introduction 1. Introduction
With the exponential growth of the Internet and increasing number of With the exponential growth of the Internet and increasing number of
end users, SPs are looking for new ways to evolve their current end users, SPs are looking for new ways to evolve their current
network architecture to meet the needs of Internet ready appliances, network architecture to meet the needs of Internet ready appliances,
new applications and services. IPv6 is designed to enable SPs to meet new applications and services. IPv6 is designed to enable SPs to
these challenges and provide new services to their customers. meet these challenges and provide new services to their customers.
As the number of devices per BB user increase exponentially As the number of devices per BB user increase exponentially
worldwide, Cable, DSL, Ethernet to the Home, Wireless and other worldwide, Cable, DSL, Ethernet to the Home, Wireless, PLC/BPL and
always-on access technologies can benefit from the huge address other always-on access technologies can benefit from the huge
range [RFC3513] of IPv6. Other benefits of IPv6 include the address range [RFC3513] of IPv6. Other benefits of IPv6 include the
capability to enhance end-to-end security, mobile communications, capability to enhance end-to-end security, mobile communications,
and ease system management burdens. Some examples include and ease system management burdens. Some examples include
peer-to-peer communication without NAT traversal problems, being peer-to-peer communication without NAT traversal problems, being
able to access securely devices at home from work, enhanced IP able to access securely devices at home from work, enhanced IP
Mobility [RFC3775] and so on. Mobility [RFC3775] and so on.
Therefore SPs are aggressively evaluating the capabilities of IPv6 Therefore SPs are aggressively evaluating the capabilities of IPv6
to meet these needs. Some countries have taken a lead role in this to meet these needs. Some countries have taken a lead role in this
race and moved from testing and evaluation to real deployments of race and moved from testing and evaluation to real deployments of
IPv6 in the BB arena. Japan is a prime example along with other IPv6 in the BB arena. Japan is a prime example along with other
skipping to change at page 3, line 48 skipping to change at page 4, line 9
easier and more economical to start the IPv6 services, as they easier and more economical to start the IPv6 services, as they
require minimal investments and network infrastructure changes in require minimal investments and network infrastructure changes in
current SP model. Depending on customer needs and requirements a current SP model. Depending on customer needs and requirements a
native IPv6 deployment option might be more scalable and provide native IPv6 deployment option might be more scalable and provide
required service performance. required service performance.
2. IPv6 Based BB Services 2. IPv6 Based BB Services
At this point IPv6 based services are seen as a differentiator that At this point IPv6 based services are seen as a differentiator that
enables SPs to take advantage of the large IPv6 address space to enables SPs to take advantage of the large IPv6 address space to
the extent that subscribers get fixed /64 prefixes versus the single, the extent that subscribers get up to fixed /48 prefixes versus the
temporary IPv4 addresses. Such resources allow the SPs to better single, temporary IPv4 addresses. Such resources allow the SPs to
position themselves against the competition. The IPv6 deployments better position themselves against the competition. The IPv6
can be seen as a driver for lower service support costs by deployments can be seen as a driver for lower service support costs
eliminating NAT with its negative impact on applications and its by eliminating NAT with its negative impact on applications and its
complex behavior. Another reason of IPv6 being very popular in some complex behavior. Another reason of IPv6 being popular in some
countries is the government driven financial incentives and favorable countries might be the government driven financial incentives and
legislation toward the ISPs who are deploying IPv6. favorable legislation towards the IPs who are deploying IPv6.
NTT East, Japan started a commercial dual-stack (devices capable of NTT East, Japan started a commercial dual-stack (devices capable of
forwarding IPv4 and IPv6 packets) IPv6 unicast service option early forwarding IPv4 and IPv6 packets) IPv6 unicast service option early
this year for its ADSL and FTTH subscribers, under the name of this year for its ADSL and FTTH subscribers, under the name of
FLETS.Net [Dual Stack Access]. FLETS.Net [Dual Stack Access].
For these users the IPv6 addresses are dedicated (/64 per user) and For these users the IPv6 addresses are dedicated (/64 per user) and
are used when needed. However, this IPv6 service is available only 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 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 network and at this point does not provide connectivity to the
IPv6 Internet. 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 Some ISPs that are currently providing IPv4 based Multicast and
VoIP services are evaluating IPv6 to take advantage of the huge VoIP services are evaluating IPv6 to take advantage of the huge
address space and other useful features. The Multicast services address space and other useful features. The Multicast services
consist of video and audio streaming of several programs (streams). consist of video and audio streaming of several programs (streams).
The content provider will have certain content (which is of user The content provider will have certain content (which is of user
interest) and they would send these multicast streams to BB interest) and they would send these multicast streams to BB
subscribers. Today, when done through IPv4, there is generally a subscribers. Today, when done through IPv4, there is generally a
single device directly attached to the CPE that receives the single device directly attached to the CPE that receives the
Multicast stream. By moving to IPv6, ISP should be capable to Multicast stream. By moving to IPv6, ISP should be capable to
provide multiple streams to multiple devices on the customer site. provide multiple streams to multiple devices on the customer site.
For instance in Japan, Cable TV and dish services are not very For instance in Japan, Cable TV and dish services are not very
popular, the users expect everything through the broadcasted, free popular, the users expect everything through the broadcasted, free
programs (traditional TV). In case of BB users however, they can get programs (traditional TV). In case of BB users however, they can get
some extra content through the SP, which is very reasonably priced 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 for 20 Mbps or 10/100 Mbps of bandwidth. Users sign up with a
provider that is multicasting several channels of video and audio. A content provider that is multicasting several channels of video and
subscriber would join the multicast group of interest (after audio. A subscriber would join the multicast group of interest
authentication) and will start receiving the stream(s). An example of (after authentication) and will start receiving the stream(s). An
a video stream could be Disney movies and an example of an audio example of a video stream could be Disney movies and an example of
stream could be Karaoke (part of same *,G group). Similar to Cable an audio stream could be Karaoke (part of same *,G group). Similar
TV, where customers sign up and pay for single programs or packages to Cable TV, where customers sign up and pay for single programs or
of programs. packages of programs.
SPs are also offering IPv6 services over wireless links using 802.11 SPs are also offering IPv6 services over wireless links using 802.11
compliant WiFi Hot Spots. This enables users to take notebook PCs and compliant WiFi Hot Spots. This enables users to take notebook PCs and
PDAs (Windows 2003 supports IPv6 capable Internet Explorer and Media PDAs (Windows 2003 supports IPv6 capable Internet Explorer and Media
Player 9) along with them and connect to the Internet from various Player 9) along with them and connect to the Internet from various
locations without the restriction of staying indoors. locations without the restriction of staying indoors.
3. Scope of the Document 3. Scope of the Document
The focus of this document is to present the options available in The focus of this document is to present the options available in
deploying IPv6 services in the access portion of a BB Service deploying IPv6 services in the access portion of a BB Service
Provider network namely Cable/HFC, BB Ethernet, xDSL and WLAN. Provider network namely Cable/HFC, BB Ethernet, xDSL, WLAN and
PLC/BPL.
This document briefly discusses the other elements of a provider This document briefly discusses the other elements of a provider
network as well. It provides different viable IPv6 deployment and network as well. It provides different viable IPv6 deployment and
integration techniques and models for each of the above mentioned BB integration techniques and models for each of the above mentioned BB
technologies separately. The example list is not exhaustive but it technologies separately. The example list is not exhaustive but it
tries to be representative. tries to be representative.
This document analyzes, how all the important parts of current IPv4 This document analyzes, how all the important parts of current IPv4
based Cable/HFC, BB Ethernet, xDSL and WLAN networks will behave based Cable/HFC, BB Ethernet, xDSL, WLAN and PLC/BPL networks will
when IPv6 is integrated and deployed. behave when IPv6 is integrated and deployed.
The following important pieces are discussed: The following important pieces are discussed:
A. Available tunneling options A. Available tunneling options
B. Devices that would require to be upgraded to support IPv6 B. Devices that would require to be upgraded to support IPv6
C. Available IPv6 address assignment techniques and their use C. Available IPv6 address assignment techniques and their use
D. Possible IPv6 Routing options and their use D. Possible IPv6 Routing options and their use
E. IPv6 unicast and multicast packet transmission E. IPv6 unicast and multicast packet transmission
F. Required IPv6 QoS parameters F. Required IPv6 QoS parameters
G. Required IPv6 Security parameters G. Required IPv6 Security parameters
H. Required IPv6 Network Management parameters H. Required IPv6 Network Management parameters
It is important to note that the addressing rules provided throughout It is important to note that the addressing rules provided
this document represent an example that follows the current throughout this document represent an example that follows the
assignment policies and recommendations of the registries. They can current assignment policies and recommendations of the registries.
be however adapted to the network and business model needs of the They can be however adapted to the network and business model needs
ISPs. of the ISPs.
The scope of the document is to advise on the ways of upgrading
an existing infrastructure to support IPv6 services. The
recommendation to upgrade a device to dual-stack does not stop an
SP from adding a new device to its network to perform the neccessary
IPv6 functions discussed. The costs involved could be offset by
lower impact on the existing IPv4 services.
4. Core/Backbone Network 4. Core/Backbone Network
This section intends to briefly discuss the some important elements This section intends to briefly discuss the some important elements
of a provider network tied to the deployment of IPv6. A more detailed of a provider network tied to the deployment of IPv6. A more
description of the core network is provided in other documents [ISP detailed description of the core network is provided in other
Networks IPv6 Scenarios]. documents [ISP Networks IPv6 Scenarios].
There are two networks identified in the Broadband deployments: There are two networks identified in the Broadband deployments:
A. Access Provider Network: This network provides the broadband A. Access Provider Network: This network provides the broadband
access and aggregates the subscribers. The subscriber traffic is access and aggregates the subscribers. The subscriber traffic is
handed over to the Service Provider at Layer 2 or 3. handed over to the Service Provider at Layer 2 or 3.
B. Service Provider Network: This network provides Intranet and B. Service Provider Network: This network provides Intranet and
Internet IP connectivity for the subscribers. Internet IP connectivity for the subscribers.
The Service Provider network structure beyond the Edge routers that The Service Provider network structure beyond the Edge routers that
skipping to change at page 6, line 39 skipping to change at page 6, line 56
A. IPv6 Tunneling: As a temporary solution, the Access Providers can A. IPv6 Tunneling: As a temporary solution, the Access Providers can
choose to use a tunneling mechanism to forward the subscriber IPv6 choose to use a tunneling mechanism to forward the subscriber IPv6
traffic to the Service Provider Edge Router. This approach has the traffic to the Service Provider Edge Router. This approach has the
least impact on the Access Provider network however, as the number of least impact on the Access Provider network however, as the number of
users increase and the amount of IPv6 traffic grows, the ISP will users increase and the amount of IPv6 traffic grows, the ISP will
have to evolve to one of the scenarios listed below. have to evolve to one of the scenarios listed below.
B. Native IPv6 Deployment: The Access Provider routers are upgraded B. Native IPv6 Deployment: The Access Provider routers are upgraded
to support IPv6 and can become dual-stack. In a dual-stack network to support IPv6 and can become dual-stack. In a dual-stack network
an IPv6 IGP such as OSPFv3 or IS-IS is enabled, usually mapping the an IPv6 IGP such as OSPFv3 or IS-IS is enabled. RFC4029 discusses the
IGP deployed for IPv4. The most important thing to remember in this IGP selection options with their benefits and drawbacks.
case is that the device resources are now shared between IPv4 and
IPv6 processes. This problem could be eliminated 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 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 its IPv4 core it could use 6PE to forward IPv6 traffic over it.
In this case only a subset of routers close to the edge of the In this case only a subset of routers close to the edge of the
network need to be IPv6 aware. With this approach BGP becomes network need to be IPv6 aware. With this approach BGP becomes
important in order to support 6PE. important in order to support 6PE.
The 6PE approach has the advantage of having minimal impact on the The 6PE approach has the advantage of having minimal impact on the
Access Provider network. Fewer devices need to be upgraded and Access Provider network. Fewer devices need to be upgraded and
configured while the MPLS core continues to switch the traffic configured while the MPLS core continues to switch the traffic
un-aware of the fact that it transports both IPv4 and IPv6 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 6PE should be leveraged only if MPLS is already deployed in the
network. At the time of writing this document, a major disadvantage network. At the time of writing this document, a major disadvantage
skipping to change at page 7, line 32 skipping to change at page 7, line 45
changes needed to their current network and the current demand for changes needed to their current network and the current demand for
the service. For these reasons, some SPs might choose tunneling the service. For these reasons, some SPs might choose tunneling
based transition mechanisms to start an IPv6 service offering and based transition mechanisms to start an IPv6 service offering and
move to native IPv6 deployment at a later time. move to native IPv6 deployment at a later time.
Several tunneling mechanisms were developed specifically Several tunneling mechanisms were developed specifically
to transport IPv6 over existing IPv4 infrastructures. Several of to transport IPv6 over existing IPv4 infrastructures. Several of
them have been standardized and their use depends on the existing SP them have been standardized and their use depends on the existing SP
IPv4 network and the structure of the IPv6 service. The IPv4 network and the structure of the IPv6 service. The
requirements for the most appropriate mechanisms are described in requirements for the most appropriate mechanisms are described in
[Assisted Tunneling] and [ZeroConf] with more updates to follow. [Assisted Tunneling] and [v6tc] with more updates to follow.
Deploying IPv6 using tunneling techniques can imply as little Deploying IPv6 using tunneling techniques can imply as little
changes to the network as upgrading SW on tunnel end points. changes to the network as upgrading SW on tunnel end points (TEP).
A Service Provider could use tunneling to deploy IPv6 in the A Service Provider could use tunneling to deploy IPv6 in the
following scenarios: following scenarios:
5.1 Access over Tunnels-customers with Public IPv4 Address 5.1 Access over Tunnels-customers with Public IPv4 Address
If the customer is a residential user, it can initiate the tunnel If the customer is a residential user, it can initiate the tunnel
directly from the IPv6 capable host to a tunnel termination router directly from the IPv6 capable host to a tunnel termination router
located in the NAP or ISP network. The tunnel type used should be located in the NAP or ISP network. The tunnel type used should be
decided by the SP but it should take into consideration its decided by the SP but it should take into consideration its
availability on commonly used software running on the host machine. availability on commonly used software running on the host machine.
skipping to change at page 8, line 7 skipping to change at page 8, line 17
others. others.
If the end customer has a GWR installed, then it could be used to If the end customer has a GWR installed, then it could be used to
originate the tunnel and thus offer native IPv6 access to multiple originate the tunnel and thus offer native IPv6 access to multiple
hosts on the customer network. In this case the GWR would need to be hosts on the customer network. In this case the GWR would need to be
upgraded to dual-stack in order to support IPv6. The GWR can be owned upgraded to dual-stack in order to support IPv6. The GWR can be owned
by the customer or by the SP. by the customer or by the SP.
5.2 Access over Tunnels-Customers with Private IPv4 Address 5.2 Access over Tunnels-Customers with Private IPv4 Address
If the end customer receives a private IPv4 address and its hosts If the end customer receives a private IPv4 address and needs to
need to go through a NAT, tunneling techniques like 6to4 will not initiate a tunnel through NAT, techniques like 6to4 will not work
work since they rely on Public IPv4 address. In this case the end since they rely on Public IPv4 address. In this case the end user
user might have to use tunnels that can operate through NATs (such might have to use tunnels that can operate through NATs (such as
as Teredo tunnel [OPS]). Teredo tunnel [OPS]).
The customer has the option to initiate the tunnel from the device The customer has the option to initiate the tunnel from the device
(GWR) that performs the NAT functionality, similar to the GWR (GWR) that performs the NAT functionality, similar to the GWR
scenario discussed in section 5.1. This will imply HW replacement or scenario discussed in section 5.1. This will imply HW replacement or
SW upgrade and a native IPv6 environment behind the GWR. SW upgrade and a native IPv6 environment behind the GWR.
It is important to note that the customers of a Service Provider can It is important to note that the customers of a Service Provider can
choose to establish tunnels to publicly available and free tunnel choose to establish tunnels to publicly available and free tunnel
services. Even though the quality of such services might not be high, services. Even though the quality of such services might not be high,
they provide free IPv6 access. In designing their IPv6 services, the they provide free IPv6 access. In designing their IPv6 services, the
skipping to change at page 8, line 38 skipping to change at page 8, line 48
through already established IPv4 IPsec sessions would provide a through already established IPv4 IPsec sessions would provide a
certain level of security to the IPv6 traffic [Tunnel through IPsec]. certain level of security to the IPv6 traffic [Tunnel through IPsec].
5.3 Transition a Portion of the IPv4 Infrastructure 5.3 Transition a Portion of the IPv4 Infrastructure
Tunnels can be used to transport the IPv6 traffic across a defined Tunnels can be used to transport the IPv6 traffic across a defined
segment of the network. As an example, the customer might connect segment of the network. As an example, the customer might connect
natively to the Network Access Provider and a tunnel is used to natively to the Network Access Provider and a tunnel is used to
transit the traffic over IPv4 to the ISP. In this case the tunnel transit the traffic over IPv4 to the ISP. In this case the tunnel
choice depends on its capabilities (for example, whether it supports choice depends on its capabilities (for example, whether it supports
multicast or not), routing protocols used (GRE is the only tunnel multicast or not), routing protocols used (there are several types
type which can transport layer 2 messages as well), manage-ability that can transport layer 2 messages such as GRE, L2TPv3 or
and scalability (dynamic versus static tunnels). Pseudowire), manage-ability and scalability (dynamic versus static
tunnels).
This scenario implies that the access portion of the network has been This scenario implies that the access portion of the network has been
upgraded to support dual stack so the savings provided by tunneling upgraded to support dual stack so the savings provided by tunneling
in this scenario are very small compared with the previous two. in this scenario are very small compared with the previous two.
Depending on the number of sites requiring the service and Depending on the number of sites requiring the service and
considering the expenses required to manage the tunnels (some tunnels considering the expenses required to manage the tunnels (some tunnels
are static while others are dynamic [Dynamic Tunnel]) in this case, are static while others are dynamic [Dynamic Tunnel]) in this case,
the SPs might find the native approach worth the additional the SPs might find the native approach worth the additional
investments. investments.
In all the scenarios listed above the tunnel selection process should In all the scenarios listed above the tunnel selection process should
consider the IPv6 multicast forwarding capabilities if such service consider the IPv6 multicast forwarding capabilities if such service
is planned. As an example, 6to4 tunnels do not support IPv6 multicast is planned. As an example, 6to4 tunnels do not support IPv6
traffic. multicast traffic.
The operation, capabilities and deployment of various tunnel types The operation, capabilities and deployment of various tunnel types
has been discussed extensively in the documents referenced earlier as has been discussed extensively in the documents referenced earlier as
well as in [OPS, RFC3904]. Details of a tunnel based deployment are 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 offered in the next section of this document (section 6). In the case
of Cable Access where the current DOCSIS specifications do not of Cable Access where the current DOCSIS specifications do not
provide support for native IPv6 access. Although sections 7, 8 and 9 provide support for native IPv6 access. Although sections 7, 8, 9
focus on a native IPv6 deployments over DSL, FTTH and Wireless and 10 focus on a native IPv6 deployments over DSL, FTTH, Wireless
because this approach is fully supported today, tunnel based and PLC/BPL because this approach is fully supported today, tunnel
solutions are also possible in these cases based on the guidelines based solutions are also possible in these cases based on the
of this section and some of the recommendations provided in section guidelines of this section and some of the recommendations provided
6. in section 6.
6. Broadband Cable Networks 6. Broadband Cable Networks
This section describes the infrastructure that exists today in This section describes the infrastructure that exists today in
cable networks providing BB services to the home. It also describes cable networks providing BB services to the home. It also describes
IPv6 deployment options in these cable networks. IPv6 deployment options in these cable networks.
DOCSIS standardizes and documents the operation of data over Cable DOCSIS standardizes and documents the operation of data over Cable
Networks. The current version of DOCSIS has limitations that do not Networks. The current version of DOCSIS has limitations that do not
allow for a smooth implementation of native IPv6 transport. Some of allow for a smooth implementation of native IPv6 transport. Some of
these limitations are discussed in this section. For this reason, these limitations are discussed in this section. For this reason,
the IPv6 deployment scenarios discussed in this section for the the IPv6 deployment scenarios discussed in this section for the
existent Cable Networks are tunnel based. The tunneling examples existent Cable Networks are tunnel based. The tunneling examples
presented here could also be applied to the other BB technologies presented here could also be applied to the other BB technologies
described in sections 7, 8 and 9. described in sections 7, 8, 9 and 10.
6.1 Broadband Cable Network Elements 6.1 Broadband Cable Network Elements
Broadband cable networks are capable of transporting IP traffic to/ Broadband cable networks are capable of transporting IP traffic to/
from users to provide high speed Internet access and VOIP services. from users to provide high speed Internet access and VOIP services.
The mechanism of transporting IP traffic over cable networks is The mechanism of transporting IP traffic over cable networks is
outlined in the DOCSIS specification [RF Interface]. outlined in the DOCSIS specification [RF Interface].
Here are some of the key elements of a Cable network: Here are some of the key elements of a Cable network:
skipping to change at page 10, line 5 skipping to change at page 10, line 15
CM: Cable Modem CM: Cable Modem
ER: Edge Router ER: Edge Router
MSO: Multiple Service Operator MSO: Multiple Service Operator
Data Over Cable Service Interface Specification (DOCSIS): The Data Over Cable Service Interface Specification (DOCSIS): The
standards defining how data should be carried over cable networks. standards defining how data should be carried over cable networks.
Figure 9.1 illustrates the key elements of a Cable Network Figure 6.1 illustrates the key elements of a Cable Network
<--- ACCESS ---><------ HFC ------><----- Aggregation / Core -----> <--- ACCESS ---><------ HFC ------><----- Aggregation / Core ----->
+-----+ +------+ +-----+ +------+
|Host |--| GWR | |Host |--| GWR |
+-----+ +--+---+ +-----+ +--+---+
| _ _ _ _ _ _ | _ _ _ _ _ _
+------+ | | +------+ | |
| CM |---| | | CM |---| |
+------+ | | +------+ | |
| HFC | +------+ +--------+ | HFC | +------+ +--------+
skipping to change at page 10, line 31 skipping to change at page 10, line 41
+------+ | +------+ |
+-----+ | GWR/ | | +-----+ | GWR/ | |
|Host |--| CM |---------+ |Host |--| CM |---------+
+-----+ | | +-----+ | |
+------+ Figure 6.1 +------+ Figure 6.1
6.2 Deploying IPv6 in Cable Networks 6.2 Deploying IPv6 in Cable Networks
One of the motivators for an MSO to deploy IPv6 over their Cable One of the motivators for an MSO to deploy IPv6 over their Cable
Network is to ease management burdens. IPv6 can be enabled on the Network is to ease management burdens. IPv6 can be enabled on the
host, CM, CMTS and ER for management purposes. Currently portions of CM, CMTS and ER for management purposes. Currently portions of the
the cable infrastructure use RFC1918 IPv4 addresses; however, there cable infrastructure use RFC1918 IPv4 addresses; however, there are
are a finite number of those. Thus, IPv6 could have utility in the a finite number of those. Thus, IPv6 could have utility in the
cable space implemented on the control plane initially and later on cable space implemented on the management plane initially and later
focused on the data plane for end user services. on focused on the data plane for end user services. For more
details on using IPv6 for management in Cable Networks please refer
to section 6.6.1.
There are two different deployment modes in current cable networks: There are two different deployment modes in current cable networks:
a bridged CMTS environment and a routed CMTS environment. IPv6 can a bridged CMTS environment and a routed CMTS environment. IPv6 can
be deployed in both of these environments. be deployed in both of these environments.
1. Bridged CMTS Network 1. Bridged CMTS Network
In this scenario, both the CM and CMTS bridge all data traffic. In this scenario, both the CM and CMTS bridge all data traffic.
Traffic to/from host devices is forwarded through the cable network Traffic to/from host devices is forwarded through the cable network
to the ER. The ER then routes traffic through the ISP network to the to the ER. The ER then routes traffic through the ISP network to the
Internet. The CM and CMTS support a certain degree of Layer 3 Internet. The CM and CMTS support a certain degree of Layer 3
functionality for management purposes. functionality for management purposes.
2. Routed CMTS Network 2. Routed CMTS Network
In a routed network, the CMTS forwards IP traffic to/from hosts In a routed network, the CMTS forwards IP traffic to/from hosts
based on Layer 3 information using the IP source/destination address. based on Layer 3 information using the IP source/destination address.
The CM acts as a Layer-2 bridge for forwarding data traffic and The CM acts as a Layer-2 bridge for forwarding data traffic and
skipping to change at page 11, line 8 skipping to change at page 11, line 23
based on Layer 3 information using the IP source/destination address. based on Layer 3 information using the IP source/destination address.
The CM acts as a Layer-2 bridge for forwarding data traffic and The CM acts as a Layer-2 bridge for forwarding data traffic and
supports some Layer 3 functionality for management purposes. supports some Layer 3 functionality for management purposes.
Some of the factors that hinder deployment of native IPv6 in current Some of the factors that hinder deployment of native IPv6 in current
cable networks include: cable networks include:
A. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. These A. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. These
devices rely on IGMP join messages to track membership of hosts that 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 are part of a particular IP Multicast group. In order to support ND
the CM and CMTS will need to support IGMPv3/MLDv1 or v2 snooping. the CM and CMTS will need to support IGMPv3/MLDv2 or v1 snooping.
B. Classification of IPv6 traffic in the upstream and downstream B. Classification of IPv6 traffic in the upstream and downstream
direction. The CM and CMTS will need to support classification of direction. The CM and CMTS will need to support classification of
IPv6 packets in order to give them the appropriate priority and IPv6 packets in order to give them the appropriate priority and
QoS. Without proper classification all IPv6 traffic will need to be QoS. Without proper classification all IPv6 traffic will need to be
sent best effort (BE) which can cause problems when deploying sent best effort (BE) which can cause problems when deploying
services like VOIP and IP Multicast video. services like VOIP and IP Multicast video.
C. Changes need to be made to the DOCSIS specification to include C. Changes need to be made to the DOCSIS specification to include
support for IPv6 on the CM and CMTS. This is imperative for support for IPv6 on the CM and CMTS. This is imperative for
skipping to change at page 12, line 37 skipping to change at page 13, line 4
6.2.1.2.2 IP Addressing for Hosts 6.2.1.2.2 IP Addressing for Hosts
If there is no GWR connected to the CM, the host behind the CM will If there is no GWR connected to the CM, the host behind the CM will
get a /64 prefix assigned to it via stateless autoconfiguration or get a /64 prefix assigned to it via stateless autoconfiguration or
DHCPv6. DHCPv6.
If using stateless auto-configuration, the host listens for routing If using stateless auto-configuration, the host listens for routing
advertisements (RA) from the ER. The RAs contain the /64 prefix advertisements (RA) from the ER. The RAs contain the /64 prefix
assigned to the segment. Upon receipt of an RA, the host constructs assigned to the segment. Upon receipt of an RA, the host constructs
its IPv6 address by combining the prefix in the RA (/64) and a unique
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 the same way as DHCPv4 works today. The DHCPv6 messages exchanged
between the host and the DHCPv6 server are bridged by the CM and between the host and the DHCPv6 server are bridged by the CM and
the CMTS. the CMTS.
6.2.1.2.3 IP Addressing for GWR 6.2.1.2.3 IP Addressing for GWR
The GWR can use stateless auto-configuration (RA) to obtain an The GWR can use stateless auto-configuration (RA) to obtain an
address for its upstream interface, the link between itself and 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 the ER. This step is followed by a request via DHCP-PD (Prefix
shorter than /64, typically /48, which in turn is divided into /64s Delegation) for a prefix shorter than /64, typically /48, which
and assigned to its downstream interfaces connecting to the hosts. in turn is divided into /64s and assigned to its downstream
interfaces connecting to the hosts.
6.2.1.3 Data Forwarding 6.2.1.3 Data Forwarding
The CM and CMTS must be able to bridge native IPv6 unicast and The CM and CMTS must be able to bridge native IPv6 unicast and
multicast traffic. The CMTS must provide IP connectivity between multicast traffic. The CMTS must provide IP connectivity between
hosts attached to CMs and must do so in a way that meets the hosts attached to CMs and must do so in a way that meets the
expectation of Ethernet attached customer equipment. In order to do expectation of Ethernet attached customer equipment. In order to do
that, the CMTS must either forward Neighbor Discovery (ND) packets that, the CM and CMTS must forward Neighbor Discovery (ND) packets
or provide a proxy ND service. between ER and the hosts attached to the CM.
Communication between hosts behind different CMs is always forwarded Communication between hosts behind different CMs is always forwarded
through the CMTS. IPv6 communication between the different sites through the CMTS. IPv6 communication between the different sites
relies on multicast IPv6 ND [RFC2461] frames being forwarded correctly relies on multicast IPv6 ND [RFC2461] frames being forwarded
by the CM and the CMTS. As with the CM, a bridged CMTS that selectively correctly by the CM and the CMTS. As with the CM, a bridged CMTS that
forwards multicast datagrams on the basis of IGMPv2 will potentially selectively forwards multicast datagrams on the basis of IGMPv2 will
break IPv6 ND. potentially break IPv6 ND.
In order to support IPv6 multicast applications across DOCSIS cable In order to support IPv6 multicast applications across DOCSIS cable
networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 or v1
snooping. MLD is almost identical to IGMP in IPv4, only the name and snooping. MLD is almost identical to IGMP in IPv4, only the name and
numbers are changed. MLDv2 is identical to IGMPv3 and also supports numbers are changed. MLDv2 is identical to IGMPv3 and also supports
ASM (Any Source Multicast) and SSM (Single Source Multicast) service ASM (Any Source Multicast) and SSM (Single Source Multicast)
models. Implementation work on CM/CMTS should be minimal because the service models. Implementation work on CM/CMTS should be minimal
only significant difference between IPv4 IGMPv3 and IPv6 MLDv2 is the because the only significant difference between IPv4 IGMPv3 and IPv6
longer addresses in the protocol. MLDv2 is the longer addresses in the protocol.
6.2.1.4 Routing 6.2.1.4 Routing
The hosts install a default route that points to the ER or the GWR. The hosts install a default route that points to the ER or the GWR.
No routing protocols are needed on these devices which generally have No routing protocols are needed on these devices which generally
limited resources. If there is a GWR present it will also use static have limited resources. If there is a GWR present it will also use
default route to the ER. static default route to the ER.
The ER runs an IGP such as OSPFv3 or IS-IS. The connected prefixes The ER runs an IGP such as OSPFv3 or IS-IS. The connected prefixes
have to be redistributed. If DHCP-PD is used, with every delegated have to be redistributed. If DHCP-PD is used, with every delegated
prefix a static route is installed by the ER. For this reason the prefix a static route is installed by the ER. For this reason the
static routes must also be redistributed. Prefix summarization static routes must also be redistributed. Prefix summarization
should be done at the ER. should be done at the ER.
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
6.2.2 Deploying IPv6 in a Routed CMTS Network 6.2.2 Deploying IPv6 in a Routed CMTS Network
In an IPv4 routed CMTS network the CM still acts as a Layer-2 In an IPv4 routed CMTS network the CM still acts as a Layer-2
device and bridges all data traffic between its Ethernet interface device and bridges all data traffic between its Ethernet interface
and cable interface connected to the cable operator network. The CMTS and cable interface connected to the cable operator network. The CMTS
acts as a Layer 3 router and may also include the ER functionality. 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. 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 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 as a Layer-2 device and will need to bridge IPv6 unicast as well as
skipping to change at page 15, line 14 skipping to change at page 15, line 33
Figure 6.2.2.1 illustrates this deployment scenario Figure 6.2.2.1 illustrates this deployment scenario
+-----------+ +------+ +--------+ +-----------+ +------+ +--------+
+-----+ +-------+ | Cable | | | | Edge | +-----+ +-------+ | Cable | | | | Edge |
|Host |--| CM |----| (HFC) |----| CMTS |----| |=>ISP |Host |--| CM |----| (HFC) |----| CMTS |----| |=>ISP
+-----+ +-------+ | Network | | | | Router | Network +-----+ +-------+ | Network | | | | Router | Network
+-----------+ +------+ +--------+ +-----------+ +------+ +--------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-over-IPv4 tunnel IPv6-in-IPv4 tunnel
<---------><----------------------------------------><------------> <---------><----------------------------------------><------------>
IPv4/v6 IPv4 only IPv4/v6 IPv4/v6 IPv4 only IPv4/v6
Figure 6.2.2.1 Figure 6.2.2.1
6.2.2.1.1 IPv6 Related Infrastructure Changes 6.2.2.1.1 IPv6 Related Infrastructure Changes
In this scenario the CM and the CMTS will only need to support IPv4 In this scenario the CM and the CMTS will only need to support IPv4
so no changes need to be made to them or the cable network. The so no changes need to be made to them or the cable network. The
following devices have to be upgraded to dual stack: Host and ER. following devices have to be upgraded to dual stack: Host and ER.
6.2.2.1.2 Addressing 6.2.2.1.2 Addressing
The only device that needs to be assigned an IPv6 address at customer The only device that needs to be assigned an IPv6 address at customer
site is the host. Host address assignment can be done in multiple site is the host. Host address assignment can be done in multiple
ways. Depending on the tunneling mechanism used it be automatic or ways. Depending on the tunneling mechanism used it could be
might require manual configuration.. automatic or might require manual configuration.
The host still receives an IPv4 address using DHCPv4, which works The host still receives an IPv4 address using DHCPv4, which works
the same way in currently deployed cable networks. In order to get the same way in currently deployed cable networks. In order to get
IPv6 connectivity, host devices will also need an IPv6 address and IPv6 connectivity, host devices will also need an IPv6 address and
a means to communicate with the ER. a means to communicate with the ER.
6.2.2.1.3 Data Forwarding 6.2.2.1.3 Data Forwarding
All IPv6 traffic will be sent to/from the ER and the host device. In All IPv6 traffic will be sent to/from the ER and the host device. In
order to transport IPv6 packets over the cable operator IPv4 order to transport IPv6 packets over the cable operator IPv4
network, the host and the ER will need to use one of the available network, the host and the ER will need to use one of the available
IPv6 over IPv4 tunneling mechanisms. IPv6 in IPv4 tunneling mechanisms.
The host will use its IPv4 address to source the tunnel to the 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 ER. All IPv6 traffic will be forwarded to the ER, encapsulated in
IPv4 packets. The intermediate IPv4 nodes will forward this traffic IPv4 packets. The intermediate IPv4 nodes will forward this traffic
as regular IPv4 packets. The ER will need to terminate the tunnel as regular IPv4 packets. The ER will need to terminate the tunnel
and/or provide other IPv6 services. and/or provide other IPv6 services.
6.2.2.1.4 Routing 6.2.2.1.4 Routing
Routing configuration on the host will vary depending on Routing configuration on the host will vary depending on
skipping to change at page 16, line 28 skipping to change at page 16, line 46
+-----+ +-----+
|Host | |Host |
+--+--+ +--+--+
| +-----------+ +------+ +--------+ | +-----------+ +------+ +--------+
+---+---+ +-------+ | Cable | | | | Edge | +---+---+ +-------+ | Cable | | | | Edge |
| GWR |--| CM |----| (HFC) |----| CMTS |----| |=>ISP | GWR |--| CM |----| (HFC) |----| CMTS |----| |=>ISP
+-------+ +-------+ | Network | | | | Router | Network +-------+ +-------+ | Network | | | | Router | Network
+-----------+ +------+ +--------+ +-----------+ +------+ +--------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-over-IPv4 tunnel IPv6-in-IPv4 tunnel
<---------><---------------------------------------><-------------> <---------><---------------------------------------><------------->
IPv4/v6 IPv4 only IPv4/v6 IPv4/v6 IPv4 only IPv4/v6
Figure 6.2.2.2 Figure 6.2.2.2
6.2.2.2.1 IPv6 Related Infrastructure Changes 6.2.2.2.1 IPv6 Related Infrastructure Changes
In this scenario the CM and the CMTS will only need to support IPv4 In this scenario the CM and the CMTS will only need to support IPv4
so no changes need to be made to them or the cable network. The so no changes need to be made to them or the cable network. The
skipping to change at page 17, line 19 skipping to change at page 17, line 36
The GWR still receives a global IPv4 address on its upstream The GWR still receives a global IPv4 address on its upstream
interface using DHCPv4, which works the same way in currently interface using DHCPv4, which works the same way in currently
deployed cable networks. In order to get IPv6 connectivity to the deployed cable networks. In order to get IPv6 connectivity to the
Internet the GWR will need to communicate with the ER. Internet the GWR will need to communicate with the ER.
6.2.2.2.3 Data Forwarding 6.2.2.2.3 Data Forwarding
All IPv6 traffic will be sent to/from the ER and the GWR, which will All IPv6 traffic will be sent to/from the ER and the GWR, which will
forward IPv6 traffic to/from the host. In order to transport IPv6 forward IPv6 traffic to/from the host. In order to transport IPv6
packets over the cable operator IPv4 network, the GWR and the ER packets over the cable operator IPv4 network, the GWR and the ER
will need to use one of the available IPv6 over IPv4 tunneling will need to use one of the available IPv6 in IPv4 tunneling
mechanisms. All IPv6 traffic will need to go through the tunnel, once mechanisms. All IPv6 traffic will need to go through the tunnel, once
it comes up. it comes up.
The GWR will use its IPv4 address to source the tunnel to the ER. The GWR will use its IPv4 address to source the tunnel to the ER.
The tunnel endpoint will be the IPv4 address of the ER. All IPv6 The tunnel endpoint will be the IPv4 address of the ER. All IPv6
traffic will be forwarded to the ER, encapsulated in IPv4 packets. traffic will be forwarded to the ER, encapsulated in IPv4 packets.
The intermediate IPv4 nodes will forward this traffic as regular IPv4 The intermediate IPv4 nodes will forward this traffic as regular
packets. In case of 6to4 tunneling, the ER will need to support IPv4 packets. In case of 6to4 tunneling, the ER will need to support
6to4 relay functionality in order to provide IPv6 Internet 6to4 relay functionality in order to provide IPv6 Internet
connectivity to the GWR and hence the hosts connected to the GWR. connectivity to the GWR and hence the hosts connected to the GWR.
6.2.2.2.4 Routing 6.2.2.2.4 Routing
Depending on the tunneling technique used there might some Depending on the tunneling technique used there might some
configuration needed on the GWR and the ER. If the ER is also 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 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. added to the GWR pointing to the ER, for all non-6to4 traffic.
skipping to change at page 18, line 27 skipping to change at page 18, line 43
<-------><----------------------------><----------------> <-------><----------------------------><---------------->
IPv4/v6 IPv4/v6 IPv4/v6 IPv4/v6 IPv4/v6 IPv4/v6
Figure 6.2.2.3 Figure 6.2.2.3
6.2.2.3.1 IPv6 Related Infrastructure Changes 6.2.2.3.1 IPv6 Related Infrastructure Changes
Since the CM still acts as a Layer-2 bridge, it does not need to 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 be dual-stack. The CM will need to support bridging of IPv6 unicast
and multicast traffic and IGMPv3/MLDv1 or v2 snooping which requires and multicast traffic and IGMPv3/MLDv2 or v1 snooping which requires
changes in the DOCSIS specification. In this scenario the following changes in the DOCSIS specification. In this scenario the following
devices have to be upgraded to dual stack: Host and CMTS/ER. devices have to be upgraded to dual stack: Host and CMTS/ER.
6.2.2.3.2 Addressing 6.2.2.3.2 Addressing
In today's cable networks the CM receives a private IPv4 address In today's cable networks the CM receives a private IPv4 address
using DHCPv4 for management purposes. In an IPv6 environment, the using DHCPv4 for management purposes. In an IPv6 environment, the
CM will continue to use an IPv4 address for management purposes. CM will continue to use an IPv4 address for management purposes.
The cable operator can also choose to assign an IPv6 address to the 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 CM for management, but the CM will have to be upgraded to support
skipping to change at page 19, line 38 skipping to change at page 20, line 6
facilitate IPv6 communication between the host and the CMTS/ER. The facilitate IPv6 communication between the host and the CMTS/ER. The
CMTS will be upgraded to dual-stack to support IPv6 and can acts as 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 an ER as well. The CM will act as a bridge for forwarding data
traffic and does not need to support IPv6. traffic and does not need to support IPv6.
This scenario is similar to the case described in section 6.2.2.2. 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 only difference in this case is the ER functionality exists on
the CMTS instead of a separate router in the cable operator network. the CMTS instead of a separate router in the cable operator network.
Figure 6.2.2.4 illustrates this deployment scenario Figure 6.2.2.4 illustrates this deployment scenario
+-----------+ +------------+ +-----------+ +------------+
+------+ +-------+ +-------+ | Cable | |CMTS / Edge | +------+ +-------+ +-------+ | Cable | |CMTS / Edge |
| Host |---| GWR |--| CM |---| (HFC) |----| |=>ISP | Host |---| GWR |--| CM |---| (HFC) |----| |=>ISP
+------+ +-------+ +-------+ | Network | | Router |Network +------+ +-------+ +-------+ | Network | | Router |Network
+-----------+ +------------+ +-----------+ +------------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-over-IPv4 tunnel IPv6-in-IPv4 tunnel
<-----------------><--------------------------------><--------------> <-----------------><--------------------------------><-------------->
IPv4/v6 IPv4 IPv4/v6 IPv4/v6 IPv4 IPv4/v6
Figure 6.2.2.4 Figure 6.2.2.4
6.2.2.4.1 IPv6 Related Infrastructure Changes 6.2.2.4.1 IPv6 Related Infrastructure Changes
Since the CM still acts as a Layer-2 bridge, it does not need to 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 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 the following devices have to be upgraded to dual stack: Host, GWR
skipping to change at page 21, line 10 skipping to change at page 21, line 28
6.2.2.5.1 IPv6 Related Infrastructure Changes 6.2.2.5.1 IPv6 Related Infrastructure Changes
Since the CM/GWR acts as a Layer 3 device, IPv6 can be deployed Since the CM/GWR acts as a Layer 3 device, IPv6 can be deployed
end-to-end. In this scenario the following devices have to be end-to-end. In this scenario the following devices have to be
upgraded to dual-stack: Host, CM/GWR and CMTS/ER. upgraded to dual-stack: Host, CM/GWR and CMTS/ER.
6.2.2.5.2 Addressing 6.2.2.5.2 Addressing
Since the CM/GWR is dual-stack, it can receive an IPv4 or IPv6 Since the CM/GWR is dual-stack, it can receive an IPv4 or IPv6
address using DHCP for management purposes. As the GWR address using DHCP for management purposes. As the GWR functionality
functionality is Embedded in the CM, it will need an IPv6 address for is Embedded in the CM, it will need an IPv6 address for forwarding
forwarding data traffic. IPv6 address assignment for the CM/GWR and data traffic. IPv6 address assignment for the CM/GWR and host can be
host can be done via DHCPv6 or DHCP-PD. done via DHCPv6 or DHCP-PD.
If using DHCPv6 the CMTS will need to act as DHCPv6 relay agent. The If using DHCPv6 the CMTS will need to act as DHCPv6 relay agent. The
host and CM/GWR will receive IPv6 addresses from pools of /64 host and CM/GWR will receive IPv6 addresses from pools of /64
prefixes configured on the DHCPv6 server. The CMTS will need to glean prefixes configured on the DHCPv6 server. The CMTS will need to glean
pertinent information from the DHCP Offer messages, sent from the pertinent information from the DHCP Offer messages, sent from the
DHCP server to the DHCP clients (host and CM/GWR), much like it does 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 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 the CMTS belong to same management /64 prefix. The hosts connected
cable interface on the CMTS may belong to different /64 prefixes as to the same cable interface on the CMTS may belong to different /64
the CMTS will have multiple /64 prefixes configured under its cable customer prefixes as the CMTS may have multiple /64 prefixes
interfaces. configured under its cable interfaces.
It is also possible to use DHCP-PD for IPv6 address assignment. In It is also possible to use DHCP-PD for IPv6 address assignment. In
this case the CM/GWR will use stateless auto-configuration to assign this case the CM/GWR will use stateless auto-configuration to assign
an IPv6 address to its upstream interface using the /64 prefix 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 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 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 the CMTS/ER and chop this /48 prefix into /64s for assigning IPv6
addresses to hosts. Currently the DHCP-PD functionality cannot be addresses to hosts. Currently the DHCP-PD functionality cannot be
implemented if the DHCP-PD server is not the Edge Router. If the 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 DHCP-PD messages are relayed, the Edge Router does not have a
skipping to change at page 22, line 15 skipping to change at page 22, line 32
The static routes need to be redistributed into the IGP at the The static routes need to be redistributed into the IGP at the
CMTS/ER so there is no need for a routing protocol between the CMTS/ER so there is no need for a routing protocol between the
CMTS/ER and the GWR. CMTS/ER and the GWR.
If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3
or ISIS. or ISIS.
6.3 IPv6 Multicast 6.3 IPv6 Multicast
In order to support IPv6 multicast applications across DOCSIS cable In order to support IPv6 multicast applications across DOCSIS cable
networks, the CM and bridging CMTS will need to support IGMPv3/MLDv1 networks, the CM and bridging CMTS will need to support IGMPv3/MLDv2
or v2 snooping. MLD is almost identical to IGMP in IPv4, only the or v1 snooping. MLD is almost identical to IGMP in IPv4, only the
name and numbers are changed. MLDv2 is almost identical to IGMPv3 and name and numbers are changed. MLDv2 is almost identical to IGMPv3
also supports ASM (Any Source Multicast) and SSM (Single Source and also supports ASM (Any Source Multicast) and SSM (Single Source
Multicast) service models. Multicast) service models.
SSM is more suited for deployments where the SP intends to provide SSM is more suited for deployments where the SP intends to provide
paid content to the users (Video or Audio). This type of services paid content to the users (Video or Audio). This type of services
are expected to be of primary interest. Moreover, the simplicity of are expected to be of primary interest. Moreover, the simplicity of
the SSM model often times override the scalability issues that would the SSM model often times override the scalability issues that would
be resolved in an ASM model. ASM is however an option that is 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 discussed in section 7.3.1. The Layer 3 CM, GWR and
where contention can be generated when a snooping switch sees a (S,G)
INCLUDE and a (*,G) EXCLUDE does not exist in IPv6 multicast because
the SSM address range in IPv6 is well defined. The CM, GWR and
Layer 3 routed CMTS/ER will need to be enabled with PIM-SSM, which Layer 3 routed CMTS/ER will need to be enabled with PIM-SSM, which
requires the definition and support for IGMPv3/MLDv1 or v2 snooping, requires the definition and support for IGMPv3/MLDv1 or v2 snooping,
in order to track join/leave messages from the hosts. The Layer 3 in order to track join/leave messages from the hosts. Another option
next hop for the hosts support MLD. would be for the Layer 3 CM or GWR to support MLD proxy routing. The
Layer 3 next hop for the hosts needs to support MLD.
Please refer to section 7.3 for more IPv6 multicast details. Please refer to section 7.3 for more IPv6 multicast details.
6.4 IPv6 QoS 6.4 IPv6 QoS
IPv6 will not change or add any queuing/scheduling functionality IPv6 will not change or add any queuing/scheduling functionality
already existing in DOCSIS specifications. But the QoS mechanisms on already existing in DOCSIS specifications. But the QoS mechanisms on
the CMTS and CM would need to be IPv6 capable. This includes support the CMTS and CM would need to be IPv6 capable. This includes support
for IPv6 classifiers, so that data traffic to/from host devices can for IPv6 classifiers, so that data traffic to/from host devices can
be classified appropriately into different service flows and be be classified appropriately into different service flows and be
skipping to change at page 23, line 54 skipping to change at page 24, line 16
The ISP provides security against attacks that come form its own The ISP provides security against attacks that come form its own
subscribers but it could also implement security services that subscribers but it could also implement security services that
protect its subscribers from attacks sourced from the outside of its protect its subscribers from attacks sourced from the outside of its
network. Such services do not apply at the access level of the network. Such services do not apply at the access level of the
network discussed here. network discussed here.
The CMTS/ER should protect the ISP network and the other subscribers The CMTS/ER should protect the ISP network and the other subscribers
against attacks by one of its own customers. For this reason Unicast against attacks by one of its own customers. For this reason Unicast
Reverse Path Forwarding (uRPF) [RFC3704] and ACLs should be used on Reverse Path Forwarding (uRPF) [RFC3704] and ACLs should be used on
all interfaces facing subscribers. Filtering should be implemented all interfaces facing subscribers. Filtering should be implemented
with regard for the operational requirements of IPv6 (ICMPv6 types). with regard for the operational requirements of IPv6 [Security
For instance, ND messages should not be filtered. considerations for IPv6].
The CMTS/ER should protect its processing resources against floods of The CMTS/ER should protect its processing resources against floods of
valid customer control traffic such as: Router and Neighbor valid customer control traffic such as: Router and Neighbor
Solicitations, MLD Requests. Solicitations, MLD Requests.
All other security features used with the IPv4 service should be All other security features used with the IPv4 service should be
similarly applied to IPv6 as well. similarly applied to IPv6 as well.
6.6 IPv6 Network Management 6.6 IPv6 Network Management
The current DOCSIS, PacketCable, and CableHome MIBs are already IPv6 can have many applications in Cable Networks. MSOs can initially
implement IPv6 on the control plane and use it to manage the
thousands of devices connected to the CMTS. This would be a good way
to introduce IPv6 in a Cable Network. Later on the MSO can extend
IPv6 to the data plane and use it to carry customer as well as
management traffic.
6.6.1 Using IPv6 for Management in Cable Networks
IPv6 can be enabled in a Cable Network for management of devices like
CM, CMTS and ER. With the roll out of advanced services like VoIP and
Video-over-IP, MSOs are looking for ways to manage the large number
of devices connected to the CMTS. In IPv4, an RFC1918 address is
assigned to these devices like CM for management purposes. Since
there is a finite number of RFC1918 addresses available, it is
becoming difficult for MSOs to manage these devices.
By using IPv6 for management purposes, MSOs can scale their network
management systems to meet their needs. The CMTS/ER can be
configured with a /64 management prefix which is shared among all
CMs connected to the CMTS cable interface. Addressing for the CMs
can be done via stateless autoconfiguration. Once the CMs receive
the /64 prefix from the CMTS/ER via RA they can configure themselves
with an IPv6 address.
If there are devices behind the CM which need to be managed by the
MSO, another /64 prefix can be defined on the CMTS/ER. These devices
can also use stateless autoconfiguration to assign themselves an IPv6
address.
Traffic sourced from or destined to the management prefix should not
cross the MSO's network boundaries.
In this scenario IPv6 will only be used for managing these devices
on the Cable Network, all data traffic will still be forwarded by
the CM and CMTS/ER using IPv4.
6.6.2 Updates to MIBs/Standards to support IPv6
The current DOCSIS, PacketCable, and CableHome MIBs are already
designed to support IPv6 objects. In this case, IPv6 will neither designed to support IPv6 objects. In this case, IPv6 will neither
add, nor change any of the functionality of these MIBs. An object to add, nor change any of the functionality of these MIBs. An object to
identify the IP version, InetAddressType has been added to all the identify the IP version, InetAddressType has been added to all the
appropriate SNMP objects related to IP address. appropriate SNMP objects related to IP address.
There are some exceptions, the following MIBs might need to add IPv6 There are some exceptions, the following MIBs might need to add IPv6
support: support:
On the CMTS On the CMTS
skipping to change at page 24, line 56 skipping to change at page 25, line 55
between the Customer Premises Equipment and the DSLAM. between the Customer Premises Equipment and the DSLAM.
The following network elements are typical of a DSL network [ISP The following network elements are typical of a DSL network [ISP
Transition Scenarios]: Transition Scenarios]:
DSL Modem: It can be a stand alone device, it can be incorporated DSL Modem: It can be a stand alone device, it can be incorporated
in the host, it can incorporate router functionalities and also in the host, it can incorporate router functionalities and also
have the capabilities to act as a CPE router. have the capabilities to act as a CPE router.
Customer Premises Router: It is used to provide Layer 3 services Customer Premises Router: It is used to provide Layer 3 services
for customer premises networks. It is usually use to provide for customer premises networks. It is usually used to provide
firewalling functions and segment broadcast domains for a Small firewalling functions and segment broadcast domains for a Small
business. business.
DSL Access Multiplexer (DSLAM): It terminates multiple twisted DSL Access Multiplexer (DSLAM): It terminates multiple twisted
pair telephone lines and provides aggregation to BRAS. pair telephone lines and provides aggregation to BRAS.
Broadband Remote Access Server (BRAS): It aggregates or terminates Broadband Remote Access Server (BRAS): It aggregates or terminates
multiple PVC corresponding to the subscriber DSL circuits. multiple PVC corresponding to the subscriber DSL circuits.
Edge Router (ER): It provides the Layer 3 interface to the ISP Edge Router (ER): It provides the Layer 3 interface to the ISP
skipping to change at page 26, line 35 skipping to change at page 27, line 35
proven and used with existent revenue generating IPv4 services, the proven and used with existent revenue generating IPv4 services, the
IPv6 deployment will match the IPv4 one. This approach is presented IPv6 deployment will match the IPv4 one. This approach is presented
in sections 7.2.1-3 that describe current IPv4 over DSL broadband in sections 7.2.1-3 that describe current IPv4 over DSL broadband
access deployments. Under certain circumstances where new service access deployments. Under certain circumstances where new service
types or service needs justify it, IPv4 and IPv6 network logical types or service needs justify it, IPv4 and IPv6 network logical
architectures could be different as described in section 7.2.4. architectures could be different as described in section 7.2.4.
7.2.1 Point-to-Point Model 7.2.1 Point-to-Point Model
In this scenario the Ethernet frames from the Host or the Customer In this scenario the Ethernet frames from the Host or the Customer
Premises Router are bridged over the PVC assigned to the subscriber 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. Figure 7.2.1 describes the protocol architecture of this model.
Customer Premises NAP NSP Customer Premises NAP NSP
<-------------------------> <---------------> <--------------------> <-------------------------> <---------------> <-------------------->
+-----+ +-------+ +-----+ +--------+ +----------+ +-----+ +-------+ +-----+ +--------+ +----------+
|Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP |Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP
+-----+ +-------+ |Modem| +--------+ | Router +==> Network +-----+ +-------+ |Modem| +--------+ | Router +==> Network
+-----+ +----------+ +-----+ +----------+
skipping to change at page 27, line 25 skipping to change at page 28, line 26
If a Customer Router is present: If a Customer Router is present:
A. It is statically configured with an address on the /64 subnet A. It is statically configured with an address on the /64 subnet
between itself and the Edge Router, and with /64 prefixes on the between itself and the Edge Router, and with /64 prefixes on the
interfaces connecting the hosts on the customer site. This is not a interfaces connecting the hosts on the customer site. This is not a
desired provisioning method being expensive and difficult to manage. desired provisioning method being expensive and difficult to manage.
B. It can use its link-local address to communicate with the ER. B. It can use its link-local address to communicate with the ER.
It can also dynamically acquire through stateless autoconfiguration It can also dynamically acquire through stateless autoconfiguration
the address for the link between itself and the ER. This step is the prefix for the link between itself and the ER. The later option
followed by a request via DHCP-PD for a prefix shorter than /64 that allows it to contact a remote DHCPv6 server if needed. This step is
in turn is divided in /64s and assigned to its interfaces connecting followed by a request via DHCP-PD for a prefix shorter than /64
the hosts on the customer site. that in turn is divided in /64s and assigned to its downstream
interfaces.
The Edge Router has a /64 prefix configured for each subscriber VLAN. The Edge Router has a /64 prefix configured for each subscriber VLAN.
Each VLAN should be enabled to relay DHCPv6 requests from the Each VLAN should be enabled to relay DHCPv6 requests from the
subscribers to DHCPv6 servers in the ISP network. The VLANs providing subscribers to DHCPv6 servers in the ISP network. The VLANs providing
access for subscribers that use DHCP-PD as well, have to be enabled access for subscribers that use DHCP-PD as well, have to be enabled
to support the feature. Currently the DHCP-PD functionality cannot be to support the feature. Currently the DHCP-PD functionality cannot be
implemented if the DHCP-PD server is not the Edge Router. If the 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 DHCP-PD messages are relayed, the Edge Router does not have a
mechanism to learn the assigned prefixes and thus install the proper mechanism to learn the assigned prefixes and thus install the proper
routes to make that prefix reachable. Work is being done to address 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 this issue, one idea being to provide the Edge Router with a snooping
mechanism. The uplink to the ISP mechanism. The uplink to the ISP network is configured with a /64
network is configured with a /64 prefix as well. prefix as well.
The prefixes used for subscriber links and the ones delegated via The prefixes used for subscriber links and the ones delegated via
DHCP-PD should be planned in a manner that allows as much DHCP-PD should be planned in a manner that allows as much
summarization as possible at the Edge Router. summarization as possible at the Edge Router.
Other information of interest to the host, such as DNS, is provided Other information of interest to the host, such as DNS, is provided
through stateful DHCPv6 [RFC3315] and stateless DHCPv6 [RFC3736]. through stateful DHCPv6 [RFC3315] and stateless DHCPv6 [RFC3736].
7.2.1.3 Routing 7.2.1.3 Routing
The CPE devices are configured with a default route that points to The CPE devices are configured with a default route that points to
the Edge router. No routing protocols are needed on these devices the Edge router. No routing protocols are needed on these devices
which do have limited resources. which generally have limited resources.
The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS.
The connected prefixes have to be redistributed. If DHCP-PD is used, The connected prefixes have to be redistributed. If DHCP-PD is used,
with every delegated prefix a static route is installed by the Edge with every delegated prefix a static route is installed by the Edge
Router. For this reason the static routes must also be redistributed. Router. For this reason the static routes must also be redistributed.
Prefix summarization should be done at the Edge Router. Prefix summarization should be done at the Edge Router.
7.2.2 PPP Terminated Aggregation (PTA) Model 7.2.2 PPP Terminated Aggregation (PTA) Model
The PTA architecture relies on PPP-based protocols (PPPoA [RFC2364] The PTA architecture relies on PPP-based protocols (PPPoA [RFC2364]
skipping to change at page 28, line 14 skipping to change at page 29, line 17
with every delegated prefix a static route is installed by the Edge with every delegated prefix a static route is installed by the Edge
Router. For this reason the static routes must also be redistributed. Router. For this reason the static routes must also be redistributed.
Prefix summarization should be done at the Edge Router. Prefix summarization should be done at the Edge Router.
7.2.2 PPP Terminated Aggregation (PTA) Model 7.2.2 PPP Terminated Aggregation (PTA) Model
The PTA architecture relies on PPP-based protocols (PPPoA [RFC2364] The PTA architecture relies on PPP-based protocols (PPPoA [RFC2364]
and PPPoE [RFC2516]). The PPP sessions are initiated by Customer and PPPoE [RFC2516]). The PPP sessions are initiated by Customer
Premise Equipment and are terminated at the BRAS. The BRAS Premise Equipment and are terminated at the BRAS. The BRAS
authorizes the session, authenticates the subscriber, and provides authorizes the session, authenticates the subscriber, and provides
an IP address on behalf of the ISP. The BRAS then does Layer 3 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 routing of the subscriber traffic to the NSP Edge Router. This model
is often used when the NSP is also the NAP 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 There are two types of PPP encapsulations that can be leveraged with
this model: this model:
A. Connection using PPPoA A. Connection using PPPoA
Customer Premises NAP NSP Customer Premises NAP NSP
<--------------------> <----------------------> <-----------------> <--------------------> <----------------------> <----------------->
+-----------+ +-----------+
skipping to change at page 29, line 31 skipping to change at page 30, line 31
<--------------------------------> <-------------------------------->
PPP PPP
Figure 7.2.2.2 Figure 7.2.2.2
The operation of PPPoE is similar to PPPoA with the exception that The operation of PPPoE is similar to PPPoA with the exception that
with PPPoE multiple sessions can be supported over the same PVC thus with PPPoE multiple sessions can be supported over the same PVC thus
allowing the subscriber to connect to multiple services at the same allowing the subscriber to connect to multiple services at the same
time. The hosts can initiate the PPPoE sessions as well. It is time. The hosts can initiate the PPPoE sessions as well. It is
important to remember that the PPPoE encapsulation reduces the IP important to remember that the PPPoE encapsulation reduces the IP
MTU available for the customer traffic due to additional headers 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 The network design and operation of the PTA model is the same
regardless of the PPP encapsulation type used. regardless of the PPP encapsulation type used.
7.2.2.1 IPv6 Related Infrastructure Changes 7.2.2.1 IPv6 Related Infrastructure Changes
In this scenario the BRAS is Layer 3 aware and it has to be upgraded In this scenario the BRAS is Layer 3 aware and it has to be upgraded
to support IPv6. Since the BRAS terminates the PPP sessions it has to to support IPv6. Since the BRAS terminates the PPP sessions it has to
support the implementation of these PPP protocols with IPv6. The support the implementation of these PPP protocols with IPv6. The
following devices have to be upgraded to dual stack: Host, Customer following devices have to be upgraded to dual stack: Host, Customer
skipping to change at page 30, line 23 skipping to change at page 31, line 23
should be planned in a manner that allows maximum summarization at should be planned in a manner that allows maximum summarization at
the BRAS. the BRAS.
Other information of interest to the host, such as DNS, is provided Other information of interest to the host, such as DNS, is provided
through stateful [RFC3315] and stateless [RFC3736] DHCPv6. through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
7.2.2.3 Routing 7.2.2.3 Routing
The CPE devices are configured with a default route that points to The CPE devices are configured with a default route that points to
the BRAS router. No routing protocols are needed on these devices the BRAS router. No routing protocols are needed on these devices
which have limited resources. which generally have limited resources.
The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the
addresses assigned to the PPP sessions are represented as connected addresses assigned to the PPP sessions are represented as connected
host routes, connected prefixes have to be redistributed. If DHCP-PD host routes, connected prefixes have to be redistributed. If DHCP-PD
is used, with every delegated prefix a static route is installed by is used, with every delegated prefix a static route is installed by
the Edge Router. For this reason the static routes must also be the Edge Router. For this reason the static routes must also be
redistributed. Prefix summarization should be done at the BRAS. redistributed. Prefix summarization should be done at the BRAS.
The Edge Router is running the IGP used in the ISP network: OSPFv3 The Edge Router is running the IGP used in the ISP network: OSPFv3
skipping to change at page 30, line 46 skipping to change at page 31, line 46
A separation between the routing domains of the ISP and the Access A separation between the routing domains of the ISP and the Access
Provider is recommended if they are managed independently. Controlled Provider is recommended if they are managed independently. Controlled
redistribution will be needed between the Access Provider IGP and the redistribution will be needed between the Access Provider IGP and the
ISP IGP. ISP IGP.
7.2.3 L2TPv2 Access Aggregation (LAA) Model 7.2.3 L2TPv2 Access Aggregation (LAA) Model
In the LAA model the BRAS forwards the CPE initiated session to In the LAA model the BRAS forwards the CPE initiated session to
the ISP over an L2TPv2 tunnel established between the BRAS and the the ISP over an L2TPv2 tunnel established between the BRAS and the
Edge Router. In this case the authentication, authorization and Edge Router. In this case the authentication, authorization and
subscriber configuration are performed by the ISP itself subscriber configuration are performed by the ISP itself. There
[ISP Transitions Scenarios]. There are two types of PPP are two types of PPP encapsulations that can be leveraged with
encapsulations that can be leveraged with this model: this model:
A. Connection via PPPoA A. Connection via PPPoA
Customer Premises NAP NSP Customer Premises NAP NSP
<--------------------> <----------------------> <-----------------> <--------------------> <----------------------> <----------------->
+-----------+ +-----------+
| AAA | | AAA |
+-------+ Radius | +-------+ Radius |
| | TACACS | | | TACACS |
skipping to change at page 32, line 26 skipping to change at page 33, line 26
The PPP session can be initiated by a host or by a Customer Router. The PPP session can be initiated by a host or by a Customer Router.
In the latter case, once the session is established with the Edge In the latter case, once the session is established with the Edge
Router, DHCP-PD can be used to acquire prefixes for the Customer Router, DHCP-PD can be used to acquire prefixes for the Customer
Router interfaces. The Edge Router has to be enabled to support Router interfaces. The Edge Router has to be enabled to support
DHCP-PD and to relay the DHCPv6 requests generated by the hosts on DHCP-PD and to relay the DHCPv6 requests generated by the hosts on
the subscriber sites. the subscriber sites.
The BRAS has a /64 prefix configured on the link to the Edge router. The BRAS has a /64 prefix configured on the link to the Edge router.
The Edge router links are also configured with /64 prefixes to The Edge router links are also configured with /64 prefixes to
provide connectivity to the rest of the ISP network. provide connectivity to the rest of the ISP network. Other
information of interest to the host, such as DNS, is provided
Other information of interest to the host, such as DNS, is provided
through stateful [RFC3315] and stateless [RFC3736] DHCPv6. through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
It is important to note here a significant difference between this It is important to note here a significant difference between this
deployment for IPv6 versus IPv4. In the case of IPv4 the customer deployment for IPv6 versus IPv4. In the case of IPv4 the customer
router or CPE can end up on any Edge Router (acting as LNS) where the router or CPE can end up on any Edge Router (acting as LNS) where the
assumption is that there are at least two of them for redundancy assumption is that there are at least two of them for redundancy
purposes. Once authenticated, the customer will be given an address purposes. Once authenticated, the customer will be given an address
from the IP pool of the ER (LNS) it connected to. This allows the ERs 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 (LNSs) to aggregate the addresses handed out to the customers. In the
case of IPv6, an important constraint that likely will be enforced is case of IPv6, an important constraint that likely will be enforced is
skipping to change at page 33, line 5 skipping to change at page 34, line 5
same ER (primary if up or secondary if not). Each ER (LNS) can carry same ER (primary if up or secondary if not). Each ER (LNS) can carry
summary statements in their routing protocol configuration for the summary statements in their routing protocol configuration for the
prefixes they are the primary ER (LNS) as well as for the ones for 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 which they are the secondary. This way the prefixes will be
summarized any time they become "active" on the ER (LNS). summarized any time they become "active" on the ER (LNS).
7.2.3.3 Routing 7.2.3.3 Routing
The CPE devices are configured with a default route that points to The CPE devices are configured with a default route that points to
the Edge router that terminates the PPP sessions. No routing the Edge router that terminates the PPP sessions. No routing
protocols are needed on these devices which have limited resources. protocols are needed on these devices which have generally limited
resources.
The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS.
Different processes should be used if the NAP and the NSP are managed Different processes should be used if the NAP and the NSP are
by different organizations. In this case, controlled redistribution managed by different organizations. In this case, controlled
should be enabled between the two domains. redistribution should be enabled between the two domains.
The Edge Router is running the IPv6 IGP used in the ISP network: The Edge Router is running the IPv6 IGP used in the ISP network:
OSPFv3 or IS-IS. OSPFv3 or IS-IS.
7.2.4 Hybrid Model for IPv4 and IPv6 Service 7.2.4 Hybrid Model for IPv4 and IPv6 Service
It was recommended throughout this section that the IPv6 service It was recommended throughout this section that the IPv6 service
implementation should map the existent IPv4 one. This approach implementation should map the existent IPv4 one. This approach
simplifies manageability and minimizes training needed for personnel simplifies manageability and minimizes training needed for personnel
operating the network. In certain circumstances such mapping is not operating the network. In certain circumstances such mapping is not
skipping to change at page 36, line 36 skipping to change at page 37, line 36
easy to manage. PIM-SSM has to be enabled throughout the SP network. easy to manage. PIM-SSM has to be enabled throughout the SP network.
MLDv2 is required for PIM-SSM support. Vendors can choose to MLDv2 is required for PIM-SSM support. Vendors can choose to
implement features that allow routers to map MLDv1 group joins to implement features that allow routers to map MLDv1 group joins to
predefined sources. predefined sources.
Subscribers might use a set-top box that is responsible for the Subscribers might use a set-top box that is responsible for the
control piece of the multicast service (does group joins/leaves). control piece of the multicast service (does group joins/leaves).
The subscriber hosts can also join desired multicast groups as long The subscriber hosts can also join desired multicast groups as long
as they are enabled to support MLDv1 or MLDv2. If a customer premise as they are enabled to support MLDv1 or MLDv2. If a customer premise
router is used then it has to be enabled to support MLDv1 and MLDv2 router is used then it has to be enabled to support MLDv1 and MLDv2
in order to process the requests of the hosts. It has to be enabled in order to process the requests of the hosts. It has to be enabled
to support PIM-SSM in order to send PIM joins/leaves up to its 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 Layer 3 next hop whether it is the BRAS or the Edge router. When
enabling this functionality on a customer premises router, its enabling this functionality on a customer premises router, its
limited resources should be taken into consideration. limited resources should be taken into consideration. Another option
would be for the customer premises router to support MLD proxy
routing.
The router that is the Layer 3 next hop for the subscriber (BRAS in The router that is the Layer 3 next hop for the subscriber (BRAS in
the PTA model or the Edge router in the LAA and Point-to-Point 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 model) has to be enabled to support MLDv1 and MLDv2 in order to
process the requests coming from subscribers without customer process the requests coming from subscribers without customer
premises routers. It has to be enabled for PIM-SSM in order to premises routers. It has to be enabled for PIM-SSM in order to
receive joins/leaves from customer routers and send joins/leaves receive joins/leaves from customer routers and send joins/leaves
to the next hop towards the multicast source (Edge router or the to the next hop towards the multicast source (Edge router or the
NSP core). NSP core).
skipping to change at page 37, line 27 skipping to change at page 38, line 27
On the BRAS or the Edge Router the subscriber facing interfaces have On the BRAS or the Edge Router the subscriber facing interfaces have
to be configure to police the inbound customer traffic and shape the to be configure to police the inbound customer traffic and shape the
traffic outbound to the customer based on the SLAs. Traffic traffic outbound to the customer based on the SLAs. Traffic
classification and marking should also be done on the router closest classification and marking should also be done on the router closest
(at Layer 3) to the subscriber in order to support the various types (at Layer 3) to the subscriber in order to support the various types
of customer traffic: data, voice, video and to optimally use the of customer traffic: data, voice, video and to optimally use the
infrastructure resources. Each provider (NAP, NSP) could implement infrastructure resources. Each provider (NAP, NSP) could implement
their own QoS policies and services so reclassification and marking their own QoS policies and services so reclassification and marking
might be performed at the boundary between the NAP and the NSP in 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. order to make sure the traffic is properly handled by the ISP. The
same IPv4 QoS concepts and methodologies should be applied with IPv6
The same IPv4 QoS concepts and methodologies should be applied with as well.
the IPv6 as well.
It is important to note that when traffic is encrypted end-to-end, It is important to note that when traffic is encrypted end-to-end,
the traversed network devices will not have access to many of the the traversed network devices will not have access to many of the
packet fields used for classification purposes. In these cases routers packet fields used for classification purposes. In these cases
will most likely place the packets in the default classes. The QoS routers will most likely place the packets in the default classes.
design should take into consideration this scenario and try to use mainly The QoS design should take into consideration this scenario and try
IP header fields for classification purposes. to use mainly IP header fields for classification purposes.
7.5 IPv6 Security Considerations 7.5 IPv6 Security Considerations
There are limited changes that have to be done for CPEs in order to There are limited changes that have to be done for CPEs in order to
enhance security. The Privacy extensions for auto-configuration enhance security. The Privacy extensions for auto-configuration
[RFC3041] should be used by the hosts. ISPs can track the prefixes [RFC3041] should be used by the hosts. ISPs can track the prefixes
it assigns to subscribers relatively easily. If however the ISPs are it assigns to subscribers relatively easily. If however the ISPs are
required by regulations to track their users at /128 address level, required by regulations to track their users at /128 address level,
the Privacy Extensions can be implemented only in parallel with the Privacy Extensions can be implemented only in parallel with
network management tools that could provide traceability of the network management tools that could provide traceability of the
skipping to change at page 38, line 7 skipping to change at page 39, line 7
subscribers but it could also implement security services that subscribers but it could also implement security services that
protect its subscribers from attacks sourced from the outside of its protect its subscribers from attacks sourced from the outside of its
network. Such services do not apply at the access level of the network. Such services do not apply at the access level of the
network discussed here. network discussed here.
The device that is the Layer 3 next hop for the subscribers (BRAS or The device that is the Layer 3 next hop for the subscribers (BRAS or
Edge router) should protect the network and the other subscribers Edge router) should protect the network and the other subscribers
against attacks by one of the provider customers. For this reason against attacks by one of the provider customers. For this reason
uRPF and ACLs should be used on all interfaces facing subscribers. uRPF and ACLs should be used on all interfaces facing subscribers.
Filtering should be implemented with regard for the operational Filtering should be implemented with regard for the operational
requirements of IPv6 (ICMPv6 types). Authentication and authorization requirements of IPv6 [Security considerations for IPv6].
should be used wherever possible. Authentication and authorization should be used wherever possible.
The BRAS and the Edge Router should protect their processing The BRAS and the Edge Router should protect their processing
resources against floods of valid customer control traffic such as: resources against floods of valid customer control traffic such as:
Router and Neighbor Solicitations, MLD Requests. Rate limiting Router and Neighbor Solicitations, MLD Requests. Rate limiting
should be implemented on all subscriber facing interfaces. The should be implemented on all subscriber facing interfaces. The
emphasis should be placed on multicast type traffic as it is most emphasis should be placed on multicast type traffic as it is most
often used by the IPv6 control plane. often used by the IPv6 control plane.
All other security features used with the IPv4 service should be All other security features used with the IPv4 service should be
similarly applied to IPv6 as well. similarly applied to IPv6 as well.
skipping to change at page 38, line 54 skipping to change at page 39, line 54
8.1 Ethernet Access Network Elements 8.1 Ethernet Access Network Elements
In environments that support the infrastructure deploying RJ-45 or In environments that support the infrastructure deploying RJ-45 or
fiber (Fiber to the Home (FTTH) service) to subscribers, 10/100 fiber (Fiber to the Home (FTTH) service) to subscribers, 10/100
Mbps Ethernet broadband services can be provided. Such services are Mbps Ethernet broadband services can be provided. Such services are
generally available in metropolitan areas, in multi tenant buildings generally available in metropolitan areas, in multi tenant buildings
where an Ethernet infrastructure can be deployed in a cost effective where an Ethernet infrastructure can be deployed in a cost effective
manner. In such environments Metro-Ethernet services can be used to manner. In such environments Metro-Ethernet services can be used to
provide aggregation and uplink to a Service Provider. provide aggregation and uplink to a Service Provider.
The following network elements are typical of an Ethernet network The following network elements are typical of an Ethernet network:
[ISP Transition Scenarios]:
Access Switch: It is used as a Layer 2 access device for subscribers. Access Switch: It is used as a Layer 2 access device for subscribers.
Customer Premises Router: It is used to provide Layer 3 services Customer Premises Router: It is used to provide Layer 3 services
for customer premises networks. for customer premises networks.
Aggregation Ethernet Switches: Aggregates multiple subscribers. Aggregation Ethernet Switches: Aggregates multiple subscribers.
Broadband Remote Access Server (BRAS) Broadband Remote Access Server (BRAS)
skipping to change at page 39, line 35 skipping to change at page 40, line 35
|Switch | | | |Switch | | |
+--------+ | +------+ | +--------+ | +------+ |
+--+Agg E | | +--+Agg E | |
+--------+ |Switch+-+ +--------+ |Switch+-+
+-----+ |Access | +--+ | +-----+ |Access | +--+ |
|Hosts|--+Switch +-+ +------+ |Hosts|--+Switch +-+ +------+
+-----+ +--------+ +-----+ +--------+
Figure 8.1 Figure 8.1
The logical topology and design of Broadband Ethernet Networks is The logical topology and design of Broadband Ethernet Networks is
very similar to DSL Broadband Networks discussed in section 6. very similar to DSL Broadband Networks discussed in section 7.
It is worth noting that the general operation, concepts and It is worth noting that the general operation, concepts and
recommendations described in this section apply similarly to a recommendations described in this section apply similarly to a
HomePNA based network environment. Some of the network elements HomePNA based network environment. In such an environment some
might be differently named. of the network elements might be differently named.
8.2 Deploying IPv6 in IPv4 Broadband Ethernet Networks 8.2 Deploying IPv6 in IPv4 Broadband Ethernet Networks
There are three main design approaches to providing IPv4 There are three main design approaches to providing IPv4
connectivity over an Ethernet infrastructure: connectivity over an Ethernet infrastructure:
A. Point-to-Point Model: Each subscriber connects to the network A. Point-to-Point Model: Each subscriber connects to the network
Access switch over RJ-45 or fiber links. Each subscriber is assigned Access switch over RJ-45 or fiber links. Each subscriber is assigned
a unique VLAN on the access switch. The VLAN can be terminated at 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 the BRAS or at the Edge Router. The VLANs are 802.1q trunked to the
skipping to change at page 41, line 58 skipping to change at page 43, line 4
DHCP-PD should be planned in a manner that allows as much DHCP-PD should be planned in a manner that allows as much
summarization as possible at the Edge Router. summarization as possible at the Edge Router.
Other information of interest to the host, such as DNS, is provided Other information of interest to the host, such as DNS, is provided
through stateful [RFC3315] and stateless [RFC3736] DHCPv6. through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
8.2.1.3 Routing 8.2.1.3 Routing
The CPE devices are configured with a default route that points to The CPE devices are configured with a default route that points to
the Edge router. No routing protocols are needed on these devices the Edge router. No routing protocols are needed on these devices
which have limited resources. which generally have limited resources.
The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS.
The connected prefixes have to be redistributed. If DHCP-PD is used, The connected prefixes have to be redistributed. If DHCP-PD is used,
with every delegated prefix a static route is installed by the Edge with every delegated prefix a static route is installed by the Edge
Router. For this reason the static routes must also be redistributed. Router. For this reason the static routes must also be redistributed.
Prefix summarization should be done at the Edge Router. Prefix summarization should be done at the Edge Router.
8.2.2 PPP Terminated Aggregation (PTA) Model 8.2.2 PPP Terminated Aggregation (PTA) Model
The PTA architecture relies on PPP-based protocols (PPPoE). The PPP The PTA architecture relies on PPP-based protocols (PPPoE). The PPP
sessions are initiated by Customer Premise Equipment and it is sessions are initiated by Customer Premise Equipment and it is
terminated at the BRAS. The BRAS authorizes the session, terminated at the BRAS. The BRAS authorizes the session,
authenticates the subscriber, and provides an IP address on behalf authenticates the subscriber, and provides an IP address on behalf
of the ISP. The BRAS then does Layer 3 routing of the subscriber 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 traffic to the NSP Edge Router. This model is often used when the
NSP is also the NAP. NSP is also the NAP. The PPPoE logical diagram in an Ethernet
Broadband Network is shown in Fig 8.2.2.1.
The PPPoE logical diagram in an Ethernet Broadband Network is shown
in Fig 8.2.2.1.
Customer Premises NAP NSP Customer Premises NAP NSP
<---------------------------> <-----------------> <-----------------> <---------------------------> <-----------------> <----------------->
+-----------+ +-----------+
| AAA | | AAA |
+-------+ Radius | +-------+ Radius |
| | TACACS | | | TACACS |
| +-----------+ | +-----------+
+-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+ +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C |Hosts|--+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
skipping to change at page 43, line 41 skipping to change at page 44, line 41
should be planned in a manner that allows maximum summarization at should be planned in a manner that allows maximum summarization at
the BRAS. the BRAS.
Other information of interest to the host, such as DNS, is provided Other information of interest to the host, such as DNS, is provided
through stateful [RFC3315] and stateless [RFC3736] DHCPv6. through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
8.2.2.3 Routing 8.2.2.3 Routing
The CPE devices are configured with a default route that points to The CPE devices are configured with a default route that points to
the BRAS router. No routing protocols are needed on these devices the BRAS router. No routing protocols are needed on these devices
which have limited resources. which generally have limited resources.
The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the
addresses assigned to the PPP sessions are represented as connected addresses assigned to the PPP sessions are represented as connected
host routes, connected prefixes have to be redistributed. If DHCP-PD host routes, connected prefixes have to be redistributed. If DHCP-PD
is used, with every delegated prefix a static route is installed by is used, with every delegated prefix a static route is installed by
the BRAS. For this reason the static routes must also be the BRAS. For this reason the static routes must also be
redistributed. Prefix summarization should be done at the BRAS. redistributed. Prefix summarization should be done at the BRAS.
The Edge Router is running the IGP used in the ISP network: OSPFv3 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 or IS-IS. A separation between the routing domains of the ISP and
the Access Provider is recommended if they are managed independently. the Access Provider is recommended if they are managed independently.
Controlled redistribution will be needed between the Access Provider Controlled redistribution will be needed between the Access Provider
IGP and the ISP IGP. IGP and the ISP IGP.
8.2.3 L2TPv2 Access Aggregation (LAA) Model 8.2.3 L2TPv2 Access Aggregation (LAA) Model
In the LAA model the BRAS forwards the CPE initiated session to In the LAA model the BRAS forwards the CPE initiated session to the
the ISP over an L2TPv2 tunnel established between the BRAS and the ISP over an L2TPv2 tunnel established between the BRAS and the Edge
Edge Router. In this case the authentication, authorization and Router. In this case the authentication, authorization and subscriber
subscriber configuration are performed by the ISP itself. configuration are performed by the ISP itself.
Customer Premises NAP NSP Customer Premises NAP NSP
<--------------------> <----------------------> <-----------------> <--------------------> <----------------------> <----------------->
+-----------+ +-----------+
| AAA | | AAA |
+------+ Radius | +------+ Radius |
| | TACACS | | | TACACS |
| +-----+-----+ | +-----+-----+
| | | |
skipping to change at page 47, line 51 skipping to change at page 49, line ?
Subscribers might use a set-top box that is responsible for the Subscribers might use a set-top box that is responsible for the
control piece of the multicast service (does group joins/leaves). control piece of the multicast service (does group joins/leaves).
The subscriber hosts can also join desired multicast groups as The subscriber hosts can also join desired multicast groups as
long as they are enabled to support MLDv1 or MLDv2. If a customer 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 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 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 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. to its Layer 3 next hop whether it is the BRAS or the Edge router.
When enabling this functionality on a customer premises router, When enabling this functionality on a customer premises router,
its limited resources should be taken into consideration. its limited resources should be taken into consideration. Another
option would be for the customer premises router to support MLD
MLD snooping or similar layer two multicast related protocols could proxy routing. MLD snooping or similar layer two multicast related
be enabled on the NAP switches. protocols could be enabled on the NAP switches.
The router that is the Layer 3 next hop for the subscriber (BRAS in The router that is the Layer 3 next hop for the subscriber (BRAS in
the PTA model or the Edge router in the LAA and Point-to-Point model) the PTA model or the Edge router in the LAA and Point-to-Point model)
has to be enabled to support MLDv1 and MLDv2 in order to process the has to be enabled to support MLDv1 and MLDv2 in order to process the
requests coming from subscribers without customer premises routers. requests coming from subscribers without customer premises routers.
It has to be enabled for PIM-SSM in order to receive joins/leaves 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 from customer routers and send joins/leaves to the next hop towards
the multicast source (Edge router or the NSP core). the multicast source (Edge router or the NSP core).
MLD authentication, authorization and accounting is usually MLD authentication, authorization and accounting is usually
configured on the edge router in order to enable the ISP to do configured on the edge router in order to enable the ISP to do
control the subscriber access of the service and do billing for the control the subscriber access of the service and do billing for the
content provided. Alternative mechanisms that would support these content provided. Alternative mechanisms that would support these
skipping to change at page 48, line 43 skipping to change at page 49, line ?
classification and marking should also be done on the router closest classification and marking should also be done on the router closest
(at Layer 3) to the subscriber in order to support the various types (at Layer 3) to the subscriber in order to support the various types
of customer traffic: data, voice, video and to optimally use the of customer traffic: data, voice, video and to optimally use the
network resources. This infrastructure offers a very good opportunity network resources. This infrastructure offers a very good opportunity
to leverage the QoS capabilities of Layer two devices. DiffServ based to leverage the QoS capabilities of Layer two devices. DiffServ based
QoS used for IPv4 should be expanded to IPv6. QoS used for IPv4 should be expanded to IPv6.
Each provider (NAP, NSP) could implement their own QoS policies and Each provider (NAP, NSP) could implement their own QoS policies and
services so reclassification and marking might be performed at the services so reclassification and marking might be performed at the
boundary between the NAP and the NSP in order to make sure the boundary between the NAP and the NSP in order to make sure the
traffic is properly handled by the ISP. traffic is properly handled by the ISP. The same IPv4 QoS concepts
and methodologies should be applied for the IPv6 as well.
The same IPv4 QoS concepts and methodologies should be applied for
the IPv6 as well.
It is important to note that when traffic is encrypted end-to-end, It is important to note that when traffic is encrypted end-to-end,
the traversed network devices will not have access to many of the the traversed network devices will not have access to many of the
packet fields used for classification purposes. In these cases packet fields used for classification purposes. In these cases
routers will most likely place the packets in the default classes. routers will most likely place the packets in the default classes.
The QoS design should take into consideration this scenario and try The QoS design should take into consideration this scenario and try
to use mainly IP header fields for classification purposes. to use mainly IP header fields for classification purposes.
8.5 IPv6 Security Considerations 8.5 IPv6 Security Considerations
skipping to change at page 49, line 24 skipping to change at page 50, line 29
network discussed here. network discussed here.
If any layer two filters for Ethertypes are in place, the NAP must If any layer two filters for Ethertypes are in place, the NAP must
permit the IPv6 Ethertype (0X86DD). permit the IPv6 Ethertype (0X86DD).
The device that is the Layer 3 next hop for the subscribers (BRAS The device that is the Layer 3 next hop for the subscribers (BRAS
Edge router) should protect the network and the other subscribers Edge router) should protect the network and the other subscribers
against attacks by one of the provider customers. For this reason against attacks by one of the provider customers. For this reason
uRPF and ACLs should be used on all interfaces facing subscribers. uRPF and ACLs should be used on all interfaces facing subscribers.
Filtering should be implemented with regard for the operational Filtering should be implemented with regard for the operational
requirements of IPv6 (ICMPv6 types). Authentication and authorization requirements of IPv6 [Security considerations for IPv6].
should be used wherever possible. Authentication and authorization should be used wherever possible.
The BRAS and the Edge Router should protect their processing The BRAS and the Edge Router should protect their processing
resources against floods of valid customer control traffic such as: resources against floods of valid customer control traffic such as:
Router and Neighbor Solicitations, MLD Requests. Rate limiting Router and Neighbor Solicitations, MLD Requests. Rate limiting
should be implemented on all subscriber facing interfaces. The should be implemented on all subscriber facing interfaces. The
emphasis should be placed on multicast type traffic as it is most emphasis should be placed on multicast type traffic as it is most
often used by the IPv6 control plane. often used by the IPv6 control plane.
All other security features used with the IPv4 service should be All other security features used with the IPv4 service should be
similarly applied to IPv6 as well. similarly applied to IPv6 as well.
skipping to change at page 51, line 12 skipping to change at page 52, line 18
There are IPv4 deployments where customers can use WLAN routers to There are IPv4 deployments where customers can use WLAN routers to
connect over wireless to their service provider. These deployment connect over wireless to their service provider. These deployment
types do not fit in the typical Hot Spot concept but they rather types do not fit in the typical Hot Spot concept but they rather
serve fixed customers. For this reason this section discusses the serve fixed customers. For this reason this section discusses the
WLAN router options as well. In this case, the ISP provides a public WLAN router options as well. In this case, the ISP provides a public
IP address and the WLAN Router assigns private addresses [RFC1918] IP address and the WLAN Router assigns private addresses [RFC1918]
to all WLAN users. The WLAN Router provides NAT functionality while to all WLAN users. The WLAN Router provides NAT functionality while
WLAN users access the Internet. WLAN users access the Internet.
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 While deploying IPv6 in the above mentioned WLAN architecture, there
are three possible scenarios as discussed below. are three possible scenarios as discussed below.
A. Layer 2 Switch Between AP and Edge Router A. Layer 2 Switch Between AP and Edge Router
B. Access Router Between AP and Edge Router B. Access Router Between AP and Edge Router
C. PPP Based Model C. PPP Based Model
9.1.1 Layer 2 Switch Between AP and Edge Router 9.1.1 Layer 2 Switch Between AP and Edge Router
When a Layer 2 switch is present between AP and Edge Router, the AP When a Layer 2 switch is present between AP and Edge Router, the AP
skipping to change at page 52, line 51 skipping to change at page 53, line 51
B. The WLAN Router can use its link-local address to communicate with B. The WLAN Router can use its link-local address to communicate with
the ER. It can also dynamically acquire through stateless the ER. It can also dynamically acquire through stateless
autoconfiguration the address for the link between itself and the ER. autoconfiguration the address for the link between itself and the ER.
This step is followed by a request via DHCP-PD for a prefix shorter This step is followed by a request via DHCP-PD for a prefix shorter
than /64 that in turn is divided in /64s and assigned to its than /64 that in turn is divided in /64s and assigned to its
interfaces connecting the hosts on the customer site. interfaces connecting the hosts on the customer site.
In this option, the WLAN Router would act as a requesting router and In this option, the WLAN Router would act as a requesting router and
Edge Router would act as delegating router. Once prefix is received Edge Router would act as delegating router. Once prefix is received
by the WLAN Router, it assigns /64 prefixes to each of its interfaces by the WLAN Router, it assigns /64 prefixes to each of its
connecting the WLAN Hosts on the customer site. The WLAN Hosts interfaces connecting the WLAN Hosts on the customer site. The WLAN
connected to these interfaces can automatically configure themselves Hosts connected to these interfaces can automatically configure
using stateless auto-configuration with /64 prefix. Currently the themselves using stateless auto-configuration with /64 prefix.
DHCP-PD functionality cannot be implemented if the DHCP-PD server is Currently the DHCP-PD functionality cannot be implemented if the
not the ER. If the DHCP-PD messages are relayed, the Edge Router DHCP-PD server is not the ER. If the DHCP-PD messages are relayed,
does not have a mechanism to learn the assigned prefixes and thus the Edge Router does not have a mechanism to learn the assigned
install the proper routes to make that prefix reachable. Work is prefixes and thus install the proper routes to make that prefix
being done to address this issue, one idea being to provide the Edge reachable. Work is being done to address this issue, one idea being
Router with a snooping mechanism. The uplink to the ISP network is
configured with a /64 prefix as well. 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 Usually it is easier for the SPs to stay with the DHCP PD and
stateless auto-configuration model and point the clients to a stateless auto-configuration model and point the clients to a
central server for DNS/domain information, proxy configurations and central server for DNS/domain information, proxy configurations and
etc. Using this model the SP could change prefixes on the fly 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 and the WLAN Router would simply pull the newest prefix based on the
valid/preferred lifetime. valid/preferred lifetime.
The prefixes used for subscriber links and the ones delegated via The prefixes used for subscriber links and the ones delegated via
DHCP-PD should be planned in a manner that allows maximum DHCP-PD should be planned in a manner that allows maximum
summarization as possible at the Edge Router. summarization as possible at the Edge Router.
Other information of interest to the host, such as DNS, is provided Other information of interest to the host, such as DNS, is provided
through stateful [RFC3315] and stateless [RFC3736] DHCPv6. through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
9.1.1.3 Routing 9.1.1.3 Routing
The WLAN Host/Router are configured with a default route that points The WLAN Host/Router are configured with a default route that points
to the Edge router. No routing protocols are needed on these devices to the Edge router. No routing protocols are needed on these devices
which have limited resources. which generally have limited resources.
The Edge Router runs the IGP used in the SP network such as OSPFv3 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. or IS-IS for IPv6. The connected prefixes have to be redistributed.
Prefix summarization should be done at the Edge Router. When DHCP-PD Prefix summarization should be done at the Edge Router. When DHCP-PD
is used, the IGP has to redistribute the static routes installed is used, the IGP has to redistribute the static routes installed
during the process of prefix delegation. during the process of prefix delegation.
9.1.2 Access Router Between AP and SP Edge Router 9.1.2 Access Router Between AP and SP Edge Router
When a Access Router is present between AP and Edge Router, the AP When a Access Router is present between AP and Edge Router, the AP
skipping to change at page 54, line 57 skipping to change at page 55, line 57
C. It can use its link-local address to communicate with the ER. C. It can use its link-local address to communicate with the ER.
It can also dynamically acquire through stateless autoconfiguration It can also dynamically acquire through stateless autoconfiguration
the address for the link between itself and the ER. This step is the address for the link between itself and the ER. This step is
followed by a request via DHCP-PD for a prefix shorter than /64 that followed by a request via DHCP-PD for a prefix shorter than /64 that
in turn is divided in /64s and assigned to its interfaces connecting in turn is divided in /64s and assigned to its interfaces connecting
the hosts on the customer site. the hosts on the customer site.
In this option, the Access Router would act as a requesting router In this option, the Access Router would act as a requesting router
and Edge Router would act as delegating router. Once prefix is and Edge Router would act as delegating router. Once prefix is
received by the Access Router, it assigns /64 prefixes to each of its received by the Access Router, it assigns /64 prefixes to each of
interfaces connecting the WLAN Host/Router on customer site. The WLAN its interfaces connecting the WLAN Host/Router on customer site. The
Host/Router connected to these interfaces can automatically configure WLAN Host/Router connected to these interfaces can automatically
themselves using stateless auto-configuration with /64 prefix. configure themselves using stateless auto-configuration with /64
Currently the DHCP-PD functionality cannot be implemented if the prefix. Currently the DHCP-PD functionality cannot be implemented if
DHCP-PD server is not the Edge Router. If the DHCP-PD messages are the DHCP-PD server is not the Edge Router. If the DHCP-PD messages
relayed, the Edge Router does not have a mechanism to learn the are relayed, the Edge Router does not have a mechanism to learn the
assigned prefixes and thus install the proper routes to make that assigned prefixes and thus install the proper routes to make that
prefix reachable. Work is being done to address this issue, one idea prefix reachable. Work is being done to address this issue, one idea
being to provide the Edge Router with a snooping mechanism. The being to provide the Edge Router with a snooping mechanism. The
uplink to the ISP network is configured with a /64 prefix as well. 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 It is easier for the SPs to stay with the DHCP PD and stateless
auto-configuration model and point the clients to a central auto-configuration model and point the clients to a central
server for DNS/domain information, proxy configurations and others. server for DNS/domain information, proxy configurations and others.
Using this model the provider could change prefixes on the fly and Using this model the provider could change prefixes on the fly and
the Access Router would simply pull the newest prefix based on the the Access Router would simply pull the newest prefix based on the
skipping to change at page 55, line 32 skipping to change at page 56, line 32
As mentioned before the prefixes used for subscriber links and the As mentioned before the prefixes used for subscriber links and the
ones delegated via DHCP-PD should be planned in a manner that ones delegated via DHCP-PD should be planned in a manner that
allows maximum summarization possible at the Edge Router. Other allows maximum summarization possible at the Edge Router. Other
information of interest to the host, such as DNS, is provided information of interest to the host, such as DNS, is provided
through stateful [RFC3315] and stateless [RFC3736] DHCPv6. through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
9.1.2.3 Routing 9.1.2.3 Routing
The WLAN Host/Router are configured with a default route that points The WLAN Host/Router are configured with a default route that points
to the Access Router. No routing protocols are needed on these to the Access Router. No routing protocols are needed on these
devices which have limited resources. devices which generally have limited resources.
If the Access Router is owned by an Access Provider, then the Access If the Access Router is owned by an Access Provider, then the Access
Router can have a default route, pointing towards the SP Edge Router can have a default route, pointing towards the SP Edge
Router. The Edge Router runs the IGP used in the SP network such as 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 OSPFv3 or IS-IS for IPv6. The connected prefixes have to be
redistributed. If DHCP-PD is used, with every delegated prefix a redistributed. If DHCP-PD is used, with every delegated prefix a
static route is installed by the Edge Router. For this reason the static route is installed by the Edge Router. For this reason the
static routes must be redistributed. Prefix summarization should be static routes must be redistributed. Prefix summarization should be
done at the Edge Router. done at the Edge Router.
skipping to change at page 58, line 13 skipping to change at page 59, line 13
used 802.11a, 802.11b or 802.11g. used 802.11a, 802.11b or 802.11g.
The IPv6 WLAN Hosts can also join desired multicast groups as The IPv6 WLAN Hosts can also join desired multicast groups as
long as they are enabled to support MLDv1 or MLDv2. If a long as they are enabled to support MLDv1 or MLDv2. If a
WLAN/Access Routers are used then they have to be enabled to WLAN/Access Routers are used then they have to be enabled to
support MLDv1 and MLDv2 in order to process the requests of the support MLDv1 and MLDv2 in order to process the requests of the
IPv6 WLAN Hosts. The WLAN/Access Router should also needs to be 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 enabled to support PIM-SSM in order to send PIM joins up to the
Edge Router. When enabling this functionality on a WLAN/Access Edge Router. When enabling this functionality on a WLAN/Access
Router, its limited resources should be taken into consideration. Router, its limited resources should be taken into consideration.
Another option would be for the WLAN/Access Router to support
MLD proxy routing.
The Edge Router has to be enabled to support MLDv1 and MLDv2 in The Edge Router has to be enabled to support MLDv1 and MLDv2 in
order to process the requests coming from IPv6 WLAN Host or order to process the requests coming from IPv6 WLAN Host or
WLAN/Access Router (if present). The Edge Router has also needs WLAN/Access Router (if present). The Edge Router has also needs
to be enabled for PIM-SSM in order to receive joins from IPv6 to be enabled for PIM-SSM in order to receive joins from IPv6
WLAN Hosts or WLAN/Access Router (if present) and send joins WLAN Hosts or WLAN/Access Router (if present) and send joins
towards the SP core. towards the SP core.
MLD authentication, authorization and accounting is usually MLD authentication, authorization and accounting is usually
configured on the Edge Router in order to enable the SP to do configured on the Edge Router in order to enable the SP to do
billing for the content services provided. Further investigation billing for the content services provided. Further investigation
should be made in investigating alternative mechanisms that would should be made in investigating alternative mechanisms that would
support these functions. support these functions.
The IETF draft [IPv6 over 802.11] mentions some of the concerns Concerns have been raised in the past related to running IPv6
related to running IPv6 multicast over WLAN links. Potentially multicast over WLAN links. Potentially these are same kind of
these are same kind of issues when running any Layer3 protocol issues when running any Layer3 protocol over a WLAN link that has a
over a WLAN link that has a high loss-to-signal ratio, where certain high loss-to-signal ratio, where certain frames that are multicast
frames that are multicast based are dropped when settings are not based are dropped when settings are not adjusted properly. For
adjusted properly. For instance this behavior is similar to IGMP host instance this behavior is similar to IGMP host membership report,
membership report, when done on a WLAN link with high loss-to-signal when done on a WLAN link with high loss-to-signal ratio and high
ratio and high interference. This problem is inherited to WLAN that interference.
can impact both IPv4 and IPv6 multicast packets and not specific to
IPv6 multicast. 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 While deploying WLAN (IPv4 or IPv6), one should adjust their
broadcast/multicast settings if they are in danger of dropping broadcast/multicast settings if they are in danger of dropping
application dependent frames. These problems are usually caused when application dependent frames. These problems are usually caused when
AP are placed too far apart (not following the distance limitations), AP are placed too far apart (not following the distance limitations),
high interference and etc. These issues may impact a real multicast high interference and etc. These issues may impact a real multicast
application such as streaming video or basic operation of IPv6 if application such as streaming video or basic operation of IPv6 if
the frames were dropped. Basic IPv6 communications uses functions the frames were dropped. Basic IPv6 communications uses functions
such as Duplicate Address Detection (DAD), Router and Neighbor such as Duplicate Address Detection (DAD), Router and Neighbor
Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA) Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA)
skipping to change at page 59, line 47 skipping to change at page 60, line 54
The ISP provides security against attacks that come form its own The ISP provides security against attacks that come form its own
subscribers but it could also implement security services that subscribers but it could also implement security services that
protect its subscribers from attacks sourced from the outside of protect its subscribers from attacks sourced from the outside of
its network. Such services do not apply at the access level of the its network. Such services do not apply at the access level of the
network discussed here. network discussed here.
If the host authentication at hot spots is done using web based If the host authentication at hot spots is done using web based
authentication system then the level of security would depend on authentication system then the level of security would depend on
the particular implementation. User credential should never be sent the particular implementation. User credential should never be sent
as clear text via HTTP. Secure HTTP (HTTPS) should be used between as clear text via HTTP. Secure HTTP (HTTPS) should be used between
the web browser and authentication server. The authentication server the web browser and authentication server. The authentication
could use RADIUS and LDAP services at the back end. server could use RADIUS and LDAP services at the back end.
Authentication is an important aspect of securing WLAN networks
prior to implementing Layer 3 security policies. This would help
for example avoid threats to the ND or stateless autoconfiguration
processes. 802.1x provides the means to secure the network access
however, the many types of EAP (PEAP, EAP-TLS, EAP-TTLS, EAP-FAST,
LEAP) and the capabilities of the hosts to support some of the
features might make it difficult to implement a comprehensive and
consistent policy.
If any layer two filters for Ethertypes are in place, the NAP must If any layer two filters for Ethertypes are in place, the NAP must
permit the IPv6 Ethertype (0X86DD). permit the IPv6 Ethertype (0X86DD).
The device that is the Layer3 next hop for the subscribers The device that is the Layer3 next hop for the subscribers
(Access or Edge Router) should protect the network and the other (Access or Edge Router) should protect the network and the other
subscribers against attacks by one of the provider customers. subscribers against attacks by one of the provider customers.
For this reason uRPF and ACLs should be used on all interfaces For this reason uRPF and ACLs should be used on all interfaces
facing subscribers. Filtering should be implemented with regard facing subscribers. Filtering should be implemented with regard for
for the operational requirements of IPv6 (ICMPv6 types). the operational requirements of IPv6 [Security considerations for
Authentication and authorization should be used wherever possible. IPv6]. Authentication and authorization should be used wherever
possible.
The Access and the Edge Router should protect their processing The Access and the Edge Router should protect their processing
resources against floods of valid customer control traffic such as: resources against floods of valid customer control traffic such as:
RS, NS, MLD Requests. Rate limiting should be implemented on all RS, NS, MLD Requests. Rate limiting should be implemented on all
subscriber facing interfaces. The emphasis should be placed on subscriber facing interfaces. The emphasis should be placed on
multicast type traffic as it is most often used by the IPv6 control multicast type traffic as it is most often used by the IPv6 control
plane. plane.
9.5 IPv6 Network Management 9.5 IPv6 Network Management
skipping to change at page 60, line 33 skipping to change at page 61, line 51
network management practices and processes. Transport over IPv6 could network management practices and processes. Transport over IPv6 could
also be implemented and it might become necessary if IPv6 only also be implemented and it might become necessary if IPv6 only
islands are present in the network. The management stations are islands are present in the network. The management stations are
located on the core network. Network Management Applications should located on the core network. Network Management Applications should
handle IPv6 in a similar fashion to IPv4 however they should also handle IPv6 in a similar fashion to IPv4 however they should also
support features specific to IPv6 (such as Neighbor monitoring). support features specific to IPv6 (such as Neighbor monitoring).
In some cases service providers manage equipment located on customers In some cases service providers manage equipment located on customers
LANs. LANs.
10. Gap Analysis 10. Broadband Power Line Communications (PLC)
This section describes the IPv6 deployment in Power Line
Communications (PLC) Access Networks. There may be other choices,
but it seems that this is the best model to follow. Lessons learnt
from Cable, Ethernet and even WLAN access networks may be applicable
also.
Power Line Communications are also often called Broadband Power Line
(BPL) and some times even Power Line Telecommunications (PLT).
PLC/BPL can be used for providing, with todays technology, up to
200Mbps (total, upstream+downstream) by means of the power grid. The
coverage is often the last half mile (typical distance from the
Medium-to-Low Voltage transformer to the customer premise meter),
and of course, as an in-home network (which is out of the scope of
this document).
The bandwidth in a given PLC/BPL segment is shared among all the
customers connected to that segment (often the customers connected
to the same medium-to-low voltage transformer). The number of
customers can vary depending on different factors, such as distances
and even countries (from a few customers, just 5-6, up to 100-150).
PLC/BPL could also be used in the Medium Voltage network (often
configured as Metropolitan Area Networks), but this is also out
of the scope of this document, as it will be part of the core
network, not the access one.
Just for information/clarification, often the PLC/BPL access
networks use hybrid layer 2 combinations either with PLC/BPL in the
medium voltage, point to point links, wireless links, satellite,
etc., but once more, this seems to be out of the scope of this
document, as those means are transparent, for the purpose of this
document, to the last half mile access network deployed with PLC/BPL.
10.1 PLC/BPL Access Network Elements
This section describes the different elements commonly used in
PLC/BPL access networks.
Head End (HE): It is the router that connects the PLC/BPL access
network (the power grid), located at the medium-to-low voltage
transformer, to the core network. The HE PLC/BPL interface appears
to each customer as a single virtual interface, all of them sharing
the same physical media.
Repeater (RPT): It is the device which may be required in some
circumstances to improve the signal on the PLC/BPL. This may be the
case if there are many customers in the same segment or building.
Often is a bridge, but it could be also a router if for example
there is a lot of peer-to-peer traffic in a building and due to the
master-slave nature of the PLC/BPL technology, is required to improve
the performance within that segment. For simplicity, in this
document, it will be considered that the RPT is always a transparent
layer 2 bridge, so it may be present or not (from the layer 3 point
of view).
Customer Premise Equipment (CPE): It is the modem (internal to the
host), modem/bridge (BCPE), router (RCPE) or any combination among
those (i.e. modem+bridge/router), located at the customer premise.
Edge Router (ER)
Figure 10.1 depicts all the network elements indicated above
Customer Premises | Network Access Provider | Network Service Provider
CP NAP NSP
+-----+ +------+ +-----+ +------+ +--------+
|Hosts|--| RCPE |--| RPT |--------+ HE +---+ Edge | ISP
+-----+ +------+ +-----+ | | | Router +===> Network
+--+---+ +--------+
+-----+ +------+ +-----+ |
|Hosts|--| BCPE |--| RPT |-----------+
+-----+ +------+ +-----+
Figure 10.1
The logical topology and design of PLC/BPL is very similar to
Ethernet Broadband Networks as discussed in section 8.
10.2 Deploying IPv6 in IPv4 PLC/BPL
The most simplistic and efficient model, considering the nature of
the PLC/BPL networks, is to see the network as a point-to-point one
to each customer. Even if several customers share the same physical
media, the traffic is not visible among them because each one uses
different channels, which are in addition encrypted by means of 3DES.
Furthermore, if required, VLANs could also be used, as already
described for the Ethernet case.
In order to maintain the deployment concepts and business models
proven and used with existing revenue generating IPv4 services,
the IPv6 deployment will match the IPv4 one. Under certain
circumstances where new service types or service needs justify it,
IPv4 and IPv6 network architectures could be different. Both
approaches are very similar to those already described for the
Ethernet case.
10.2.1 IPv6 Related Infrastructure Changes
In this scenario the RPT is layer 3 unaware, but not the Head End,
which should be upgraded to support IPv6. Similarly other devices
which have to be upgraded to dual stack: Hosts, RCPE and Edge Router.
10.2.2 Addressing
The Hosts or the RCPEs have the HE as their Layer 3 next hop.
If there is no RCPE, but instead a BCPE all the hosts on the
subscriber site belong to the same /64 subnet that is statically
configured on the HE. The hosts can use stateless
autoconfiguration or stateful DHCPv6 based configuration to
acquire an address via the HE.
If a RCPE is present:
A. It is statically configured with an address on the /64 subnet
between itself and the HE, and with /64 prefixes on the
interfaces connecting the hosts on the customer site. This is not
a desired provisioning method being expensive and difficult to
manage.
B. It can use its link-local address to communicate with the HE.
It can also dynamically acquire through stateless
autoconfiguration the address for the link between itself and
the HE. This step is followed by a request via DHCP-PD for a
prefix shorter than /64 (typically /48) that in turn is divided
in /64s and assigned to its interfaces connecting the hosts on
the customer site. This should be the preferred provisioning
method, being cheaper and easier to manage.
The Edge Router needs to have a prefix considering that each
customer in general will receive a /48 prefix, and that each HE
will accommodate customers. Consequently each HE will require
n x /48 prefixes.
It could be possible to use a kind of Hierarchical Prefix
Delegation to automatically provision the required prefixes and
fully auto-configure the HEs, and consequently reduce the network
setup, operation and maintenance cost.
The prefixes used for subscriber links and the ones delegated via
DHCP-PD should be planned in a manner that allows as much
summarization as possible at the Edge Router.
Other information of interest to the host, such as DNS, is provided
through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
10.2.3 Routing
The HE are configured with a default route that points to
the Edge Router. No routing protocols are needed on these devices
which generally have limited resources.
The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS.
The connected prefixes have to be redistributed. If DHCP-PD is used,
with every delegated prefix a static route is installed by the HE
For this reason the static routes must also be redistributed.
Prefix summarization should be done at the HE.
10.3 IPv6 Multicast
The considerations regarding IPv6 Multicast for Ethernet are also
applicable here, in general, but assuming the nature of PLC/BPL
being a shared media. If a lot of Multicast is expected, it may be
worth considering using RPT which are layer 3 aware. In that case,
one extra layer of Hierarchical DHCP-PD could be considered, in
order to facilitate the deployment, operation and maintenance of
the network.
10.4 IPv6 QoS
The considerations introduced for QoS in Ethernet are also
applicable here. PLC/BPL networks support QoS, which basically are
no different whether the transport is IPv4 or IPv6. It is necessary
to understand that the specific network characteristics, such as the
variability that may be introduced by electrical noise, towards which
the PLC/BPL network will automatically self-adapt.
10.5 IPv6 Security Considerations
There are no differences in terms of security considerations if
compared with the Ethernet case.
10.6 IPv6 Network Management
There are no differences in terms of network management if compared
with the already described Ethernet case.
11. Gap Analysis
Several aspects of deploying IPv6 over SP Broadband networks were Several aspects of deploying IPv6 over SP Broadband networks were
highlighted in this document, aspects that require additional work highlighted in this document, aspects that require additional work
in order to facilitate native deployments as summarized below: in order to facilitate native deployments as summarized below:
A. As mentioned in section 6, changes will need to be made to the 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 DOCSIS specification in order for SPs to deploy native IPv6 over
cable networks. The CM and CMTS will both need to support IPv6 cable networks. The CM and CMTS will both need to support IPv6
natively in order to forward IPv6 unicast and multicast traffic. natively in order to forward IPv6 unicast and multicast traffic.
This is required for IPv6 Neighbor Discovery to work over DOCSIS This is required for IPv6 Neighbor Discovery to work over DOCSIS
skipping to change at page 61, line 4 skipping to change at page 66, line 7
B. Currently the DHCP-PD functionality cannot be implemented if the 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 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 relayed, the Edge Router does not have a mechanism to learn the
assigned prefixes and thus install the proper routes to make that assigned prefixes and thus install the proper routes to make that
prefix reachable. Work needs to be done to address this issue, one prefix reachable. Work needs to be done to address this issue, one
idea being to provide the Edge Router with a snooping mechanism. The 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. 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 C. Section 7 stated that current RBE based IPv4 deployment might not
be the best approach for IPv6 where the addressing space available be the best approach for IPv6 where the addressing space available
gives the SP the opportunity to separate the users on different subnets. gives the SP the opportunity to separate the users on different
The differences between IPv4 RBE and IPv6 RBE were highlighted in subnets. The differences between IPv4 RBE and IPv6 RBE were
section 7. If however, support and reason is found for a deployment highlighted in section 7. If however, support and reason is found
similar to IPv4 RBE, then the environment becomes NBMA and the new for a deployment similar to IPv4 RBE, then the environment becomes
feature should observe RFC2491 recommendations. NBMA and the new feature should observe RFC2491 recommendations.
D. Section 7 discussed the constraints imposed on a LAA based IPv6 D. Section 7 discussed the constraints imposed on a LAA based IPv6
deployment by the fact that it is expected that the subscribers keep deployment by the fact that it is expected that the subscribers keep
their assigned prefix regardless of LNS. A deployment approach was their assigned prefix regardless of LNS. A deployment approach was
proposed that would maintain the addressing schemes contiguous and proposed that would maintain the addressing schemes contiguous and
offers prefix summarization opportunities. The topic could be offers prefix summarization opportunities. The topic could be
further investigated for other solutions or improvements. further investigated for other solutions or improvements.
E. Sections 7 and 8 pointed out the limitations (previously E. Sections 7 and 8 pointed out the limitations (previously
documented in [IPv6 Multicast]) in deploying inter-domain ASM documented in [IPv6 Multicast]) in deploying inter-domain ASM
however, SSM based services seem more likely at this time. For such however, SSM based services seem more likely at this time. For such
SSM based services of content delivery (video or Audio), mechanisms SSM based services of content delivery (video or Audio), mechanisms
are needed to facilitate the billing and management of listeners. are needed to facilitate the billing and management of listeners.
The currently available feature of MLD AAA is suggested however, The currently available feature of MLD AAA is suggested however,
other methods or mechanisms might be developed and proposed. other methods or mechanisms might be developed and proposed.
F. In relation to section 9, the IETF draft [IPv6 over 802.11] F. In relation to section 9, concerns have been raised related to
mentions some of the concerns related to running IPv6 multicast running IPv6 multicast over WLAN links. Potentially these are same
over WLAN links. Potentially these are same kind of issue when kind of issue when running any Layer3 protocol over a WLAN link
running any Layer3 protocol over a WLAN link that has a high that has a high loss-to-signal ratio, certain frames that are
loss-to-signal ratio, certain frames that are multicast based are multicast based are dropped when settings are not adjusted
dropped when settings are not adjusted properly. For instance this properly. For instance this behavior is similar to IGMP host
behavior is similar to IGMP host membership report, when done on membership report, when done on a WLAN link with high
a WLAN link with high loss-to-signal ratio and high interference. loss-to-signal ratio and high interference. This problem is
This problem is inherited to WLAN that can impact both IPv4 and inherited to WLAN that can impact both IPv4 and IPv6 multicast
IPv6 multicast packets and not specific to 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 G. The Privacy Extensions were mentioned as a popular means to
provide some form of host security. ISPs can track relatively provide some form of host security. ISPs can track relatively
easily the prefixes assigned to subscribers. If however the ISPs easily the prefixes assigned to subscribers. If however the ISPs
are required by regulations to track their users at host address are required by regulations to track their users at host address
level, the Privacy Extensions [RFC3041] can be implemented only in level, the Privacy Extensions [RFC3041] can be implemented only in
parallel with network management tools that could provide parallel with network management tools that could provide
traceability of the hosts. Mechanisms should be defined to traceability of the hosts. Mechanisms should be defined to
implement this aspect of user management. implement this aspect of user management.
skipping to change at page 62, line 9 skipping to change at page 67, line 9
support yet (cable). They can be used in the following ways: support yet (cable). They can be used in the following ways:
i. Tunnels directly to the CPE or GWR with public or private IPv4 i. Tunnels directly to the CPE or GWR with public or private IPv4
addresses. addresses.
ii. Tunnels directly to hosts 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 Recommendations on the exact tunneling mechanisms that can/should be
used for last mile access need to be investigated further and should used for last mile access need to be investigated further and should
be covered in a future IETF draft. be covered in a future IETF draft.
I. Through its larger address space, IPv6 allows SPs to assign fixed, I. Through its larger address space, IPv6 allows SPs to assign
globally routable prefixes to the links connecting each subscriber. fixed, globally routable prefixes to the links connecting each
subscriber.
This approach changes the provisioning methodologies that were used This approach changes the provisioning methodologies that were used
for IPv4. Static configuration of the IPv6 addresses for all these for IPv4. Static configuration of the IPv6 addresses for all these
links on the Edge Routers or Access Routers might not be a scalable links on the Edge Routers or Access Routers might not be a scalable
option. New provisioning mechanisms or features might need to be option. New provisioning mechanisms or features might need to be
developed in order to deal with this issue. developed in order to deal with this issue.
J. New deployment models are emerging for the Layer 2 portion of the
NAP where individual VLANs are not dedicated to each subscriber. This
approach allows Layer 2 switches to aggregate more then 4096 users.
MAC Forced Forwarding [MFF] is an example of such an implementation
where a broadcast domain is turned into a NBMA like environment by
forwarding the frames based on both Source and Destination MAC
addresses. Since these models are being adopted by the field, the
implications of deploying IPv6 in such environments need to be
further investigated.
The outcome of solutions to some of these topics ranges from making The outcome of solutions to some of these topics ranges from making
a media access capable of supporting native IPv6 (cable) to improving a media access capable of supporting native IPv6 (cable) to
operational aspects of native IPv6 deployments. improving operational aspects of native IPv6 deployments.
11. Contributors 12. Contributors
We would like to thank Pekka Savola for his contribution, guidance We would like to thank Pekka Savola for his contribution, guidance
and feedback in order to improve this document. and feedback in order to improve this document.
12. Acknowledgements 13. Acknowledgements
We would like to thank Brian Carpenter, Patrick Grossetete, Toerless We would like to thank Brian Carpenter, Patrick Grossetete, Toerless
Eckert, Madhu Sudan, Shannon McFarland and Benoit Lourdelet for their Eckert, Madhu Sudan, Shannon McFarland and Benoit Lourdelet for their
valuable comments. The authors would like to acknowledge the valuable comments. The authors would like to acknowledge the
structure and information guidance provided to this work by structure and information guidance provided by the work of Mickels et
[ISP Transition Scenarios]. al on Transition Scenarios for ISP Networks.
13. References 14. References
Normative References Normative References
[RFC3053] [RFC3053]
Durand A., Fasano P., Guardini I., Lento D. "IPv6 Tunnel Broker", Durand A., Fasano P., Guardini I., Lento D. "IPv6 Tunnel Broker",
RFC3053, January 2001. RFC3053, January 2001.
[RFC3056] [RFC3056]
Carpenter B., Moore K., "Connection of IPv6 Domains via IPv4 Clouds", Carpenter B., Moore K., "Connection of IPv6 Domains via IPv4 Clouds",
RFC3056, February 2001. RFC3056, Aprilruary 2001.
[RFC2473] [RFC2473]
Conta A., Deering S., "Generic Packet tunneling in IPv6 Conta A., Deering S., "Generic Packet tunneling in IPv6
Specification", December 1998. Specification", December 1998.
[RFC2893] [RFC2893]
Gilligan R., Nordmark E., "Transition Mechanisms for IPv6 Hosts Gilligan R., Nordmark E., "Transition Mechanisms for IPv6 Hosts
and Routers", August 2000. and Routers", August 2000.
[RFC2529] [RFC2529]
skipping to change at page 63, line 35 skipping to change at page 68, line 47
[RFC3633] [RFC3633]
Troan, O. and Droms, R., "IPv6 Prefix Options for Dynamic Host Troan, O. and Droms, R., "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC3633, December 2003. Configuration Protocol (DHCP) version 6", RFC3633, December 2003.
[RFC3041] [RFC3041]
T. Narten and R. Draves, "Privacy Extensions for Stateless Address T. Narten and R. Draves, "Privacy Extensions for Stateless Address
Autoconfiguration in IPv6," RFC3041, April 2001. Autoconfiguration in IPv6," RFC3041, April 2001.
[RFC2516] [RFC2516]
Mamakos, L., "A Method for Transmitting PPP Over Ethernet (PPPoE)", Mamakos, L., "A Method for Transmitting PPP Over Ethernet (PPPoE)",
RFC2516, February 1999. RFC2516, Aprilruary 1999.
[RFC2364] [RFC2364]
Gross, G., "PPP Over AAL5 (PPPoA)", RFC2516, July 1998. Gross, G., "PPP Over AAL5 (PPPoA)", RFC2516, July 1998.
[RFC2472] [RFC2472]
Haskin, D. and Allen, E., "IP Version 6 over PPP", RFC2472, Haskin, D. and Allen, E., "IP Version 6 over PPP", RFC2472,
December 1998. December 1998.
[RFC2461] [RFC2461]
Narten, T., Nordmark, E. and Simpson, W., "Neighbor Discovery for Narten, T., Nordmark, E. and Simpson, W., "Neighbor Discovery for
IP Version 6 (IPv6)", RFC2461, December 1998. IP Version 6 (IPv6)", RFC2461, December 1998.
[RFC2770] [RFC2770]
Meyer. D., "GLOP Addressing in 233/8", RFC2770, February 2000 Meyer. D., "GLOP Addressing in 233/8", RFC2770, April 2000
[RFC3646] [RFC3646]
Droms, R., "DNS Configuration options for Dynamic Host Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC3646, December 2003. Configuration Protocol for IPv6 (DHCPv6)", RFC3646, December 2003.
[RFC3618] [RFC3618]
Fenner B., Meyer D., "Multicast Source Discovery Protocol (MSDP)", Fenner B., Meyer D., "Multicast Source Discovery Protocol (MSDP)",
RFC3618, October 2003
Informative References Informative References
[Dual Stack Access] [Dual Stack Access]
Shirasaki, et al., "A Model of IPv6/IPv4 Dual Stack Internet Access Shirasaki, et al., "A Model of IPv6/IPv4 Dual Stack Internet Access
Service", draft-shirasaki-dualstack-service-04.txt (work in Service", draft-shirasaki-dualstack-service-04.txt (work in
progress) ,April 2004. progress) ,April 2004.
[6PE] De Clercq J., et al., "Connecting IPv6 Islands across IPv4 [6PE] De Clercq J., et al., "Connecting IPv6 Islands across IPv4
Clouds with BGP:, draft-ooms-v6ops-bgp-tunnel-04.txt, October 2004 Clouds with BGP:, draft-ooms-v6ops-bgp-tunnel-04.txt, October 2004
[ISP Networks IPv6 Scenarios] [ISP Networks IPv6 Scenarios]
Lind et, al., "Scenarios and Analysis for Introducing IPv6 into ISP Lind et, al., "Scenarios and Analysis for Introducing IPv6 into ISP
Networks", draft-ietf-v6ops-isp-scenarios-analysis-03.txt (work in Networks", RFC 4029, March 2005.
progress), June 2004.
[ISATAP] [ISATAP]
Templin F., et al., "Intra-Site Automatic Tunnel Addressing Protocol Templin F., et al., "Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP)", draft-ietf-ngtrans-isatap-12.txt, January 2003. (ISATAP)", draft-ietf-ngtrans-isatap-12.txt, January 2003.
[Dynamic Tunnel] [Dynamic Tunnel]
Palet J., et al., "Analysis of IPv6 Tunnel End-point Discovery Palet J., et al., "Analysis of IPv6 Tunnel End-point Discovery
Mechanisms", draft-palet-v6ops-tun-auto-disc-01.txt, June 2004. Mechanisms", draft-palet-v6ops-tun-auto-disc-01.txt, June 2004.
[OPS] [OPS]
Nordmark E., Gilligan R. E., "Basic Transition Mechanisms for Nordmark E., Gilligan R. E., "Basic Transition Mechanisms for
IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06.txt, IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06.txt,
September 2004. September 2004.
[IPv6 over 802.11] [DOCSIS 3.0 Proposal]
Park, S., "Transmission of IPv6 Packets over 802.11/WLAN Networks", Cisco Systems, "DOCSIS 3.0 Proposal", April 2005.
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] [IPv6 Multicast]
Savola, P. "IPv6 Multicast Deployment Issues", Savola, P. "IPv6 Multicast Deployment Issues",
draft-mboned-ipv6-multicast-issues, February 2004 draft-mboned-ipv6-multicast-issues, April 2004
[RF Interface] [RF Interface]
Cable Labs, "Radio Frequency Interface Specification Cable Labs, "Radio Frequency Interface Specification
SP-RFIv2.0-I02-020617", Jun 2002. SP-RFIv2.0-I02-020617", Jun 2002.
[BSR] [BSR]
Nidhi Bhaskar et all., "Bootstrap Router (BSR) Mechanism for PIM", Nidhi Bhaskar et all., "Bootstrap Router (BSR) Mechanism for PIM",
draft-ietf-pim-sm-bsr-04.txt, January 2005 draft-ietf-pim-sm-bsr-04.txt, January 2005
[Assisted Tunneling] [Assisted Tunneling]
A.Durand, F. Parent,"Requirements for assisted tunneling", A.Durand, F. Parent,"Requirements for assisted tunneling",
draft-ietf-v6ops-assisted-tunneling-requirements-00.txt, June 2004 draft-ietf-v6ops-assisted-tunneling-requirements-00.txt, June 2004
[ZeroConf] [v6tc]
Suryanarayanan, et al., "Zero-Configuration Tunneling Requirements", J. Pallet, et al., "Goals for Tunneling Configuration",
draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt, October, 2004 draft-palet-v6tc-goals-tunneling-00.txt, August, 2005
[Security considerations for IPv6]
Sean Convery, Darrin Miller, "IPv6 and IPv4 Threat Comparison
and Best-Practice Evaluation"
Authors Addresses Authors Addresses
Salman Asadullah Salman Asadullah
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive, 170 West Tasman Drive,
San Jose, CA 95134, USA San Jose, CA 95134, USA
Phone: 408 526 8982 Phone: 408 526 8982
Email: sasad@cisco.com Email: sasad@cisco.com
skipping to change at page 65, line 31 skipping to change at page 70, line 43
Richardson, TX 75082, USA Richardson, TX 75082, USA
Phone: 469 255 4122 Phone: 469 255 4122
Email: adahmed@cisco.com Email: adahmed@cisco.com
Ciprian Popoviciu Ciprian Popoviciu
Cisco Systems, Inc. Cisco Systems, Inc.
7025-6 Kit Creek Road, 7025-6 Kit Creek Road,
Research Triangle Park, NC 27709, USA Research Triangle Park, NC 27709, USA
Phone: 919 392 3723 Phone: 919 392 3723
Email: cpopovic@cisco.com Email: cpopovic@cisco.com
Jordi Palet Martinez
Consulintel
San Jose Artesano, 1
Alcobendas - Madrid
E-28108 - Spain
Phone: +34 91 151 81 99
Fax: +34 91 151 81 98
Email: jordi.palet@consulintel.es
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology describe to pertain to the implementation or use of the technology describe
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/