draft-ietf-v6ops-bb-deployment-scenarios-02.txt   draft-ietf-v6ops-bb-deployment-scenarios-03.txt 
Network Working Group S. Asadullah Network Working Group S. Asadullah
Internet-Draft A. Ahmed Internet-Draft A. Ahmed
Expires: November 20, 2005 C. Popoviciu Expires: December 3, 2005 C. Popoviciu
Cisco Systems Cisco Systems
P. Savola
CSC/FUNET
J. Palet J. Palet
Consulintel Consulintel
May 19, 2005 June 2005
ISP IPv6 Deployment Scenarios in Broadband Access Networks ISP IPv6 Deployment Scenarios in Broadband Access Networks
<draft-ietf-v6ops-bb-deployment-scenarios-02.txt> <draft-ietf-v6ops-bb-deployment-scenarios-03.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 37 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference 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 November 20, 2005. This Internet-Draft will expire on December 3, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (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. The that are currently deployed, and discussed in this document. The
emerging PLC/BPL access technology is also discussed for completion emerging Broadband Power Line Communications (PLC/BPL) access
purposes. In this document we will discuss main components of IPv6 technology is also discussed for completeness. In this document we
BB networks and their differences from IPv4 BB networks and how IPv6 will discuss main components of IPv6 BB networks and their
is deployed and integrated in each of these BB technologies using differences from IPv4 BB networks and how IPv6 is deployed and
tunneling mechanisms and native IPv6. integrated in each of these BB technologies using tunneling
mechanisms and native IPv6.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. IPv6 Based BB Services . . . . . . . . . . . . . . . . . . . 4 1.1 Common Terminology . . . . . . . . . . . . . . . . . . . . 4
3. Scope of the Document . . . . . . . . . . . . . . . . . . . 5 2. IPv6 Based BB Services . . . . . . . . . . . . . . . . . . . 5
4. Core/Backbone Network . . . . . . . . . . . . . . . . . . . 6 3. Scope of the Document . . . . . . . . . . . . . . . . . . . 6
4. Core/Backbone Network . . . . . . . . . . . . . . . . . . . 7
4.1 Layer 2 Access Provider Network . . . . . . . . . . . . . 7 4.1 Layer 2 Access Provider Network . . . . . . . . . . . . . 7
4.2 Layer3 Access Provider Network . . . . . . . . . . . . . . 7 4.2 Layer 3 Access Provider Network . . . . . . . . . . . . . 7
5. Tunneling Overview . . . . . . . . . . . . . . . . . . . . . 8 5. Tunneling Overview . . . . . . . . . . . . . . . . . . . . . 8
5.1 Access over Tunnels-Customers with Public IPv4 Address . . 9 5.1 Access over Tunnels - Customers with Public IPv4 Address . 9
5.2 Access over Tunnels-Customers with Private IPv4 Address . 9 5.2 Access over Tunnels - Customers with Private IPv4
Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3 Transition a Portion of the IPv4 Infrastructure . . . . . 10 5.3 Transition a Portion of the IPv4 Infrastructure . . . . . 10
6. Broadband Cable Networks . . . . . . . . . . . . . . . . . . 10 6. Broadband Cable Networks . . . . . . . . . . . . . . . . . . 11
6.1 Broadband Cable Network Elements . . . . . . . . . . . . . 11 6.1 Broadband Cable Network Elements . . . . . . . . . . . . . 11
6.2 Deploying IPv6 in Cable Networks . . . . . . . . . . . . . 12 6.2 Deploying IPv6 in Cable Networks . . . . . . . . . . . . . 12
6.2.1 Deploying IPv6 in a Bridged CMTS Network . . . . . . . 13 6.2.1 Deploying IPv6 in a Bridged CMTS Network . . . . . . . 13
6.2.2 Deploying IPv6 in a Routed CMTS Network . . . . . . . 16 6.2.2 Deploying IPv6 in a Routed CMTS Network . . . . . . . 16
6.2.3 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . 25 6.2.3 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . 25
6.2.4 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . 26 6.2.4 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . 26
6.2.5 IPv6 Security Considerations . . . . . . . . . . . . . 27 6.2.5 IPv6 Security Considerations . . . . . . . . . . . . . 27
6.2.6 IPv6 Network Management . . . . . . . . . . . . . . . 28 6.2.6 IPv6 Network Management . . . . . . . . . . . . . . . 28
7. Broadband DSL Networks . . . . . . . . . . . . . . . . . . . 29 7. Broadband DSL Networks . . . . . . . . . . . . . . . . . . . 29
7.1 DSL Network Elements . . . . . . . . . . . . . . . . . . . 29 7.1 DSL Network Elements . . . . . . . . . . . . . . . . . . . 29
7.2 Deploying IPv6 in IPv4 DSL Networks . . . . . . . . . . . 30 7.2 Deploying IPv6 in IPv4 DSL Networks . . . . . . . . . . . 30
7.2.1 Point-to-Point Model . . . . . . . . . . . . . . . . . 31 7.2.1 Point-to-Point Model . . . . . . . . . . . . . . . . . 31
7.2.2 PPP Terminated Aggregation (PTA) Model . . . . . . . . 33 7.2.2 PPP Terminated Aggregation (PTA) Model . . . . . . . . 33
7.2.3 L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 36 7.2.3 L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 36
7.2.4 Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 38 7.2.4 Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 39
7.3 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 41 7.3 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 41
7.3.1 ASM Based Deployments . . . . . . . . . . . . . . . . 41 7.3.1 ASM Based Deployments . . . . . . . . . . . . . . . . 41
7.3.2 SSM Based Deployments . . . . . . . . . . . . . . . . 42 7.3.2 SSM Based Deployments . . . . . . . . . . . . . . . . 42
7.4 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.4 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.5 IPv6 Security Considerations . . . . . . . . . . . . . . . 43 7.5 IPv6 Security Considerations . . . . . . . . . . . . . . . 43
7.6 IPv6 Network management . . . . . . . . . . . . . . . . . 44 7.6 IPv6 Network management . . . . . . . . . . . . . . . . . 44
8. Broadband Ethernet Networks . . . . . . . . . . . . . . . . 45 8. Broadband Ethernet Networks . . . . . . . . . . . . . . . . 45
8.1 Ethernet Access Network Elements . . . . . . . . . . . . . 45 8.1 Ethernet Access Network Elements . . . . . . . . . . . . . 45
8.2 Deploying IPv6 in IPv4 Broadband Ethernet Networks . . . . 46 8.2 Deploying IPv6 in IPv4 Broadband Ethernet Networks . . . . 46
8.2.1 Point-to-Point Model . . . . . . . . . . . . . . . . . 47 8.2.1 Point-to-Point Model . . . . . . . . . . . . . . . . . 47
8.2.2 PPP Terminated Aggregation (PTA) Model . . . . . . . . 49 8.2.2 PPP Terminated Aggregation (PTA) Model . . . . . . . . 48
8.2.3 L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 51 8.2.3 L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 51
8.2.4 Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 53 8.2.4 Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 52
8.3 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 55 8.3 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 55
8.4 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 56 8.4 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 56
8.5 IPv6 Security Considerations . . . . . . . . . . . . . . . 56 8.5 IPv6 Security Considerations . . . . . . . . . . . . . . . 56
8.6 IPv6 Network Management . . . . . . . . . . . . . . . . . 57 8.6 IPv6 Network Management . . . . . . . . . . . . . . . . . 57
9. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . 58 9. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . 58
9.1 WLAN Deployment Scenarios . . . . . . . . . . . . . . . . 58 9.1 WLAN Deployment Scenarios . . . . . . . . . . . . . . . . 58
9.1.1 Layer 2 Switch Between AP and Edge Router . . . . . . 59 9.1.1 Layer 2 NAP with Layer 3 termination at NSP Edge
9.1.2 Access Router Between AP and SP Edge Router . . . . . 62 Router . . . . . . . . . . . . . . . . . . . . . . . . 59
9.1.2 Layer 3 aware NAP with Layer 3 termination at
Access Router . . . . . . . . . . . . . . . . . . . . 62
9.1.3 PPP Based Model . . . . . . . . . . . . . . . . . . . 64 9.1.3 PPP Based Model . . . . . . . . . . . . . . . . . . . 64
9.2 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 66 9.2 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 66
9.3 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 68 9.3 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 68
9.4 IPv6 Security Considerations . . . . . . . . . . . . . . . 68 9.4 IPv6 Security Considerations . . . . . . . . . . . . . . . 68
9.5 IPv6 Network Management . . . . . . . . . . . . . . . . . 69 9.5 IPv6 Network Management . . . . . . . . . . . . . . . . . 69
10. Broadband Power Line Communications (PLC) . . . . . . . . . 70 10. Broadband Power Line Communications (PLC) . . . . . . . . . 70
10.1 PLC/BPL Access Network Elements . . . . . . . . . . . . 70 10.1 PLC/BPL Access Network Elements . . . . . . . . . . . . 70
10.2 Deploying IPv6 in IPv4 PLC/BPL . . . . . . . . . . . . . 71 10.2 Deploying IPv6 in IPv4 PLC/BPL . . . . . . . . . . . . . 71
10.2.1 IPv6 Related Infrastructure Changes . . . . . . . . 72 10.2.1 IPv6 Related Infrastructure Changes . . . . . . . . 71
10.2.2 Addressing . . . . . . . . . . . . . . . . . . . . . 72 10.2.2 Addressing . . . . . . . . . . . . . . . . . . . . . 72
10.2.3 Routing . . . . . . . . . . . . . . . . . . . . . . 73 10.2.3 Routing . . . . . . . . . . . . . . . . . . . . . . 72
10.3 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . 73 10.3 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . 73
10.4 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . 73 10.4 IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . 73
10.5 IPv6 Security Considerations . . . . . . . . . . . . . . 73 10.5 IPv6 Security Considerations . . . . . . . . . . . . . . 73
10.6 IPv6 Network Management . . . . . . . . . . . . . . . . 74 10.6 IPv6 Network Management . . . . . . . . . . . . . . . . 73
11. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 74 11. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 74
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 76 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 76
13. Security Considerations . . . . . . . . . . . . . . . . . . 76 13. Security Considerations . . . . . . . . . . . . . . . . . . 76
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 76 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 76
14.1 Normative References . . . . . . . . . . . . . . . . . . 76 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 76
14.2 Informative References . . . . . . . . . . . . . . . . . 78 15.1 Normative References . . . . . . . . . . . . . . . . . . 76
15.2 Informative References . . . . . . . . . . . . . . . . . 78
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 79
Intellectual Property and Copyright Statements . . . . . . . 80 Intellectual Property and Copyright Statements . . . . . . . 81
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 new applications and services. IPv6 is designed to enable SPs to
meet 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, PLC/BPL and worldwide, Cable, DSL, Ethernet to the Home, Wireless, PLC/BPL and
other always-on access technologies can benefit from the huge address other always-on access technologies can benefit from the huge address
range [9] of IPv6. Other benefits of IPv6 include the capability to range [8] of IPv6. Other benefits of IPv6 include the capability to
enhance end-to-end security, mobile communications, and ease system enhance end-to-end security, mobile communications, and ease system
management burdens. Some examples include peer-to-peer communication management burdens. Some examples include peer-to-peer communication
without NAT traversal problems, being able to access securely devices without NAT traversal problems, being able to access securely devices
at home from work, enhanced IP Mobility [24] and so on. at home from work, enhanced IP Mobility [23] and so on.
Therefore SPs are aggressively evaluating the capabilities of IPv6 to Therefore SPs are aggressively evaluating the capabilities of IPv6 to
meet these needs. Some countries have taken a lead role in this race meet these needs. Some countries have taken a lead role in this race
and moved from testing and evaluation to real deployments of IPv6 in and moved from testing and evaluation to real deployments of IPv6 in
the BB arena. Japan is a prime example along with other countries the BB arena. Japan is a prime example along with other countries
that are looking at moving towards large scale production deployments that are looking at moving towards large scale production deployments
of IPv6. of IPv6.
The SPs are deploying tunneling mechanisms to transport IPv6 over The SPs are deploying tunneling mechanisms to transport IPv6 over
their existing IPv4 networks as a start as well as deploying native their existing IPv4 networks as a start as well as deploying native
IPv6 where possible. Deployment of tunneling solutions is simpler, IPv6 where possible. Deployment of tunneling solutions is simpler,
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.
1.1 Common Terminology
CPE: Customer Premise Equipment
GWR: Gateway Router
ISP: Internet Service Provider
NAP: Network Access Provider
NSP: Network Service Provider
SP: Service Provider
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 the enables SPs to take advantage of the large IPv6 address space to the
extent that subscribers get up to fixed /48 prefixes versus the extent that subscribers get up to fixed /48 prefixes versus the
single, temporary IPv4 addresses. Such resources allow the SPs to single, temporary IPv4 addresses. Such resources allow the SPs to
better position themselves against the competition. The IPv6 better position themselves against the competition. The IPv6
deployments can be seen as a driver for lower service support costs deployments can be seen as a driver for lower service support costs
by 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 popular in some complex behavior. Another reason of IPv6 being popular in some
countries might be the government driven financial incentives and countries might be the government driven financial incentives and
favorable legislation towards the IPs who are deploying IPv6. favorable legislation towards the ISPs 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 [26]. For these users the IPv6 addresses are dedicated FLETS.Net [25]. For these users the IPv6 addresses are dedicated
(/64 per user) and are used when needed. However, this IPv6 service (/64 per user) and are used when needed. However, this IPv6 service
is available only to the NTT-East ADSL and FTTH subscribers who are is available only to the NTT-East ADSL and FTTH subscribers who are
part of FLETS.NET network and at this point does not provide part of FLETS.NET network and at this point does not provide
connectivity to the IPv6 Internet. connectivity to the IPv6 Internet.
Some ISPs that are currently providing IPv4 based Multicast and VoIP Some ISPs that are currently providing IPv4 based Multicast and VoIP
services are evaluating IPv6 to improve and expand their service. services are evaluating IPv6 to improve and expand their service.
The Multicast services consist of video and audio streaming of The Multicast services consist of video and audio streaming of
several programs (streams). The content provider delivers these several programs (streams). The content provider delivers these
streams to BB subscribers. One of today's challenges is the fact streams to BB subscribers. One of today's challenges is the fact
skipping to change at page 6, line 36 skipping to change at page 6, line 50
It is important to note that the addressing rules provided throughout It is important to note that the addressing rules provided throughout
this document represent an example that follows the current this document represent an example that follows the current
assignment policies and recommendations of the registries. They can assignment policies and recommendations of the registries. They can
be however adapted to the network and business model needs of the be however adapted to the network and business model needs of the
ISPs. ISPs.
The scope of the document is to advise on the ways of upgrading an The scope of the document is to advise on the ways of upgrading an
existing infrastructure to support IPv6 services. The recommendation existing infrastructure to support IPv6 services. The recommendation
to upgrade a device to dual-stack does not stop an SP from adding a to upgrade a device to dual-stack does not stop an SP from adding a
new device to its network to perform the neccessary IPv6 functions new device to its network to perform the necessary IPv6 functions
discussed. The costs involved could be offset by lower impact on the discussed. The costs involved could be offset by lower impact on the
existing IPv4 services. existing IPv4 services.
4. Core/Backbone Network 4. Core/Backbone Network
This section intends to briefly discuss some important elements of a This section intends to briefly discuss some important elements of a
provider network tied to the deployment of IPv6. A more detailed provider network tied to the deployment of IPv6. A more detailed
description of the core network is provided in other documents [25]. description of the core network is provided in other documents [24].
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.
skipping to change at page 7, line 35 skipping to change at page 7, line 50
4.2 Layer3 Access Provider Network 4.2 Layer3 Access Provider Network
The Access Provider can choose to terminate the Layer 2 domain and The Access Provider can choose to terminate the Layer 2 domain and
route the IP traffic to the Service Provider network. Access Routers route the IP traffic to the Service Provider network. Access Routers
are used to aggregate the subscriber traffic and route it over a are used to aggregate the subscriber traffic and route it over a
Layer3 core to the SP Edge Routers. In this case the impact of the Layer3 core to the SP Edge Routers. In this case the impact of the
IPv6 deployment is significant. IPv6 deployment is significant.
The case studies in this document only present the significant The case studies in this document only present the significant
network elements of such a network: Customer Premises Equipment, network elements of such a network: Customer Premise Equipment,
Access Router and Edge Router. In real networks the link between the Access Router and Edge Router. In real networks the link between the
Access Router and the Edge Router involves other routers that are Access Router and the Edge Router involves other routers that are
part of the aggregation and the core layer of the Access Provider part of the aggregation and the core layer of the Access Provider
network. network.
The Access Provider can forward the IPv6 traffic through its layer3 The Access Provider can forward the IPv6 traffic through its layer3
core in three possible ways: core in three possible ways:
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. RFC4029 discusses an IPv6 IGP such as OSPFv3 or IS-IS is enabled. [24] discusses the
the IGP selection options with their benefits and drawbacks. IGP selection options with their benefits and drawbacks.
C. MPLS 6PE Deployment [27]: If the Access Provider is running MPLS C. MPLS 6PE Deployment [26]: If the Access Provider is running MPLS
in its IPv4 core it could use 6PE to forward IPv6 traffic over it. in its IPv4 core it could use 6PE to forward IPv6 traffic over 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 un- configured while the MPLS core continues to switch the traffic un-
aware of the fact that it transports both IPv4 and IPv6 traffic. 6PE aware of the fact that it transports both IPv4 and IPv6 traffic. 6PE
should be leveraged only if MPLS is already deployed in the network. should be leveraged only if MPLS is already deployed in the network.
At the time of writing this document, a major disadvantage of the 6PE At the time of writing this document, a major disadvantage of the 6PE
solution is the fact that it does not support multicast IPv6 traffic. solution is the fact that it does not support multicast IPv6 traffic.
The native approach has the advantage of supporting IPv6 multicast The native approach has the advantage of supporting IPv6 multicast
traffic but it may imply a significant impact on the IPv4 operational traffic but it may imply a significant impact on the IPv4 operational
network from software, configuration and possibly hardware upgrade network from software, configuration and possibly hardware upgrade
perspective. perspective.
More detailed Core Network deployment recommendations are discussed More detailed Core Network deployment recommendations are discussed
in other documents RFC4029. The handling of IPv6 traffic in the Core in other documents [24]. The handling of IPv6 traffic in the Core of
of the Access Provider Network will not be discussed for the the Access Provider Network will not be discussed for the remainder
remainder of this document. of this document.
5. Tunneling Overview 5. Tunneling Overview
Service Providers might not be able to deploy native IPv6 today due Service Providers might not be able to deploy native IPv6 today due
to the cost associated with HW and SW upgrades, the infrastructure to the cost associated with HW and SW upgrades, the infrastructure
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.
skipping to change at page 9, line 12 skipping to change at page 9, line 25
(TEP). A Service Provider could use tunneling to deploy IPv6 in the (TEP). 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.
Out of the many tunneling mechanisms developed [[2], [3], [4], [28], Out of the many tunneling mechanisms developed [2], [3], [4], [27],
[5], [6]] some are more popular than the others. [30], [5] some are more popular than the 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 upgraded to dual-stack in order to support IPv6. The GWR can be
owned by the customer or by the SP owned by the customer or by the SP
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 needs to If the end customer receives a private IPv4 address and needs to
initiate a tunnel through NAT, techniques like 6to4 may not work initiate a tunnel through NAT, techniques like 6to4 may not work
since they rely on Public IPv4 address. In this case, unless the since they rely on public IPv4 address. In this case, unless the
existing CPE supports protocol-41-forwarding, the end user might have existing GWRs support protocol-41-forwarding [29], the end user might
to use tunnels that can operate through NATs (such as Teredo tunnel have to use tunnels that can operate through NATs (such as Teredo
[30]). tunnel [30]). Most GWRs support protocol-41-forwarding which means
that hosts can initiate the tunnels in which case the GWR is not
affected by the IPv6 service.
The customer has the option to initiate the tunnel from the device 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. Most GWRs SW upgrade and a native IPv6 environment behind the GWR.
support protocol-41-forwarding which means that hosts can initiate
the tunnels in which case the GWR is not affected by the IPv6
service.
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 services. Even though the quality of such services might not be
high, they provide free IPv6 access. In designing their IPv6 high, they provide free IPv6 access. In designing their IPv6
services, the SPs should take into considerations such options services, the SPs should take into considerations such options
available to their potential customers. The IPv6 deployment should available to their potential customers. The IPv6 deployment should
support services (like multicast, VoIPv6 etc) and a level of quality support services (like multicast, VoIPv6 etc) and a level of quality
that would make the access through the SP worthwhile to potential that would make the access through the SP worthwhile to potential
subscribers. subscribers.
It is also worth observing that initiating an IPv6 tunnel over IPv4 It is also worth observing that initiating an IPv6 tunnel over IPv4
through already established IPv4 IPsec sessions would provide a through already established IPv4 IPSec sessions would provide a
certain level of security to the IPv6 traffic [Tunnel through IPsec]. certain level of security to the IPv6 traffic.
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 (there are several types multicast or not), routing protocols used (there are several types
that can transport layer 2 messages such as GRE, L2TPv3 or that can transport layer 2 messages such as GRE, L2TPv3 or
Pseudowire), manage-ability and scalability (dynamic versus static Pseudowire), manage-ability and scalability (dynamic versus static
tunnels). tunnels).
This scenario implies that the access portion of the network has been This scenario implies that the access portion of the network has been
upgraded to support dual stack so the savings provided by tunneling upgraded to support dual stack so the savings provided by tunneling
in this scenario are very small compared with the previous two in this scenario are very small compared with the previous two
scenarios. Depending on the number of sites requiring the service scenarios. Depending on the number of sites requiring the service
and considering the expenses required to manage the tunnels (some and considering the expenses required to manage the tunnels (some
tunnels are static while others are dynamic [29]) in this case, the tunnels are static while others are dynamic [28]) in this case, the
SPs might find the native approach worth the additional investments. SPs might find the native approach worth the additional 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 is planned. As an example, 6to4 tunnels do not support IPv6
multicast traffic. multicast traffic.
The operation, capabilities and deployment of various tunnel types The operation, capabilities and deployment of various tunnel types
has been discussed extensively in the documents referenced earlier as has been discussed extensively in the documents referenced earlier as
well as in [[30], [7]]. Details of a tunnel based deployment are well as in [30], [6]. Details of a tunnel based deployment are
offered in the next section of this document (section 6). In the offered in the next section of this document (section 6). In the
case of Cable Access where the current DOCSIS specifications do not case of Cable Access where the current DOCSIS specifications do not
provide support for native IPv6 access. Although sections 7, 8, 9 provide support for native IPv6 access. Although sections 7, 8, 9
and 10 focus on a native IPv6 deployments over DSL, FTTH, Wireless and 10 focus on a native IPv6 deployments over DSL, FTTH, Wireless
and PLC/BPL because this approach is fully supported today, tunnel and PLC/BPL because this approach is fully supported today, tunnel
based solutions are also possible in these cases based on the based solutions are also possible in these cases based on the
guidelines of this section and some of the recommendations provided guidelines of this section and some of the recommendations provided
in section 6. in section 6.
6. Broadband Cable Networks 6. Broadband Cable Networks
skipping to change at page 12, line 18 skipping to change at page 12, line 18
+-----+ +------+ +-----+ +------+
|Host |--| GWR | |Host |--| GWR |
+-----+ +--+---+ +-----+ +--+---+
| _ _ _ _ _ _ | _ _ _ _ _ _
+------+ | | +------+ | |
| CM |---| | | CM |---| |
+------+ | | +------+ | |
| HFC | +------+ +--------+ | HFC | +------+ +--------+
| | | | | Edge | | | | | | Edge |
+-----+ +------+ | Network |---| CMTS |---| |===> ISP +-----+ +------+ | Network |---| CMTS |---| |=>ISP
|Host |--| CM |---| | | | | Router | Network |Host |--| CM |---| | | | | Router | Network
+-----+ +--+---+ | | +------+ +--------+ +-----+ +--+---+ | | +------+ +--------+
|_ _ _ _ _ _| |_ _ _ _ _ _|
+------+ | +------+ |
+-----+ | GWR/ | | +-----+ | GWR/ | |
|Host |--| CM |---------+ |Host |--| CM |---------+
+-----+ | | +-----+ | |
+------+ Figure 6.1 +------+ Figure 6.1
6.2 Deploying IPv6 in Cable Networks 6.2 Deploying IPv6 in Cable Networks
skipping to change at page 14, line 21 skipping to change at page 14, line 21
+-----+ +-----+ +-----+ +-----+
|Host |--| GWR | |Host |--| GWR |
+-----+ +--+--+ +-----+ +--+--+
| _ _ _ _ _ _ | _ _ _ _ _ _
| +------+ | | | +------+ | |
+--| CM |---| | +--| CM |---| |
+------+ | | +------+ | |
| HFC | +------+ +--------+ | HFC | +------+ +--------+
| | | | | Edge | | | | | | Edge |
+-----+ +------+ | Network |--| CMTS |--| |===> ISP +-----+ +------+ | Network |---| CMTS |--| |=>ISP
|Host |--| CM |---| | | | | Router | Network |Host |--| CM |---| | | | | Router | Network
+-----+ +------+ | | +------+ +--------+ +-----+ +------+ | | +------+ +--------+
|_ _ _ _ _ _| |_ _ _ _ _ _|
|-------------||---------------------------------||---------------| |-------------||---------------------------------||---------------|
L3 Routed L2 Bridged L3 Routed L3 Routed L2 Bridged L3 Routed
Figure 6.2.1 Figure 6.2.1
6.2.1.1 IPv6 Related Infrastructure Changes 6.2.1.1 IPv6 Related Infrastructure Changes
skipping to change at page 15, line 9 skipping to change at page 15, line 9
The CM will be provisioned in the same way as in currently deployed The CM will be provisioned in the same way as in currently deployed
cable networks, using an IPv4 address on the cable interface cable networks, using an IPv4 address on the cable interface
connected to the MSO network for management functions. During the connected to the MSO network for management functions. During the
initialization phase, it will obtain its IPv4 address using DHCPv4, initialization phase, it will obtain its IPv4 address using DHCPv4,
and download a DOCSIS configuration file identified by the DHCPv4 and download a DOCSIS configuration file identified by the DHCPv4
server. server.
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 auto-configuration 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 its IPv6 address by combining the prefix in the RA (/64) and a unique
identifier (e.g., its modified EUI-64 format interface ID). identifier (e.g., its modified EUI-64 format interface ID).
If DHCPv6 is used to obtain an IPv6 address, it will work in much the If DHCPv6 is used to obtain an IPv6 address, it will work in much the
same way as DHCPv4 works today. The DHCPv6 messages exchanged same way as DHCPv4 works today. The DHCPv6 messages exchanged
between the host and the DHCPv6 server are bridged by the CM and the between the host and the DHCPv6 server are bridged by the CM and the
CMTS. CMTS.
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 the address for its upstream interface, the link between itself and the
ER. This step is followed by a request via DHCP-PD (Prefix ER. This step is followed by a request via DHCP-PD (Prefix
Delegation) for a prefix shorter than /64, typically /48 [8], which Delegation) for a prefix shorter than /64, typically /48 [7], which
in turn is divided into /64s and assigned to its downstream in turn is divided into /64s and assigned to its downstream
interfaces connecting to the hosts. 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 CM and CMTS must forward Neighbor Discovery (ND) packets that, the CM and CMTS must forward Neighbor Discovery (ND) packets
between ER and the hosts attached to the CM. between ER and the hosts attached to the CM.
Communication between hosts behind different CMs is always forwarded Communication between hosts behind different CMs is always forwarded
through the CMTS. IPv6 communication between the different sites through the CMTS. IPv6 communication between the different sites
relies on multicast IPv6 ND [18] frames being forwarded correctly by relies on multicast IPv6 ND [17] frames being forwarded correctly by
the CM and the CMTS. As with the CM, a bridged CMTS that selectively the CM and the CMTS. As with the CM, a bridged CMTS that selectively
forwards multicast datagrams on the basis of MLD will potentially forwards multicast datagrams on the basis of MLD will potentially
break IPv6 ND. 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 or v1 networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 or v1
snooping. MLD is almost identical to IGMP in IPv4, only the name and snooping. MLD is almost identical to IGMP in IPv4, only the name and
numbers are changed. MLDv2 is identical to IGMPv3 and also supports numbers are changed. MLDv2 is identical to IGMPv3 and also supports
ASM (Any Source Multicast) and SSM (Single Source Multicast) service ASM (Any Source Multicast) and SSM (Single Source Multicast) service
models. Implementation work on CM/CMTS should be minimal because the models. Implementation work on CM/CMTS should be minimal because the
skipping to change at page 18, line 12 skipping to change at page 18, line 12
IPv6 service. All IPv6 traffic is exchanged between the hosts and IPv6 service. All IPv6 traffic is exchanged between the hosts and
the ER. the ER.
Figure 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-in-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.
skipping to change at page 19, line 31 skipping to change at page 19, line 31
Figure 6.2.2.2 illustrates this deployment scenario Figure 6.2.2.2 illustrates this deployment scenario
+-----+ +-----+
|Host | |Host |
+--+--+ +--+--+
| +-----------+ +------+ +--------+ | +-----------+ +------+ +--------+
+---+---+ +-------+ | Cable | | | | Edge | +---+---+ +-------+ | Cable | | | | Edge |
| GWR |--| CM |----| (HFC) |---| CMTS |---| |=>ISP | GWR |--| CM |----| (HFC) |---| CMTS |---| |=>ISP
+-------+ +-------+ | Network | | | | Router | Network +-------+ +-------+ | Network | | | | Router | Network
+-----------+ +------+ +--------+ +-----------+ +------+ +--------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel IPv6-in-IPv4 tunnel
|---------||---------------------------------------||-------------| |---------||--------------------------------------||-------------|
IPv4/v6 IPv4 only IPv4/v6 IPv4/v6 IPv4 only IPv4/v6
Figure 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
following devices have to be upgraded to dual stack: Host, GWR and following devices have to be upgraded to dual stack: Host, GWR and
ER. ER.
6.2.2.2.2 Addressing 6.2.2.2.2 Addressing
The only devices that needs to be assigned an IPv6 address at The only devices that needs to be assigned an IPv6 address at
customer site are the host and GWR. IPv6 address assignment can be customer site are the host and GWR. IPv6 address assignment can be
done statically at the GWR downstream interface. The GWR will send done statically at the GWR downstream interface. The GWR will send
out RA messages on its downstream interface which will be used by the out RA messages on its downstream interface which will be used by the
hosts to auto-configure themselves with an IPv6 address. The GWR can hosts to auto-configure themselves with an IPv6 address. The GWR can
also configure its upstream interface using RA messages from the ER also configure its upstream interface using RA messages from the ER
and use DHCP-PD for requesting a /48 [8] prefix from the ER. This and use DHCP-PD for requesting a /48 [7] prefix from the ER. This
/48 prefix will be used to configure /64s on hosts connected to the /48 prefix will be used to configure /64s on hosts connected to the
GWR downstream interfaces. Currently the DHCP-PD functionality GWR downstream interfaces. Currently the DHCP-PD functionality
cannot be implemented if the DHCP-PD server is not the Edge Router. cannot be implemented if the DHCP-PD server is not the Edge Router.
If the DHCP-PD messages are relayed, the Edge Router does not have a If the DHCP-PD messages are relayed, the Edge Router does not have a
mechanism to learn the assigned prefixes and thus install the proper 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 network is configured with a /64 mechanism. The uplink to the ISP network is configured with a /64
prefix as well. prefix as well.
skipping to change at page 21, line 29 skipping to change at page 21, line 29
In this scenario the Cable Operator can offer native IPv6 services to In this scenario the Cable Operator can offer native IPv6 services to
its customers since the cable network including the CMTS supports its customers since the cable network including the CMTS supports
IPv6. The ER functionality can be included in the CMTS or it can IPv6. The ER functionality can be included in the CMTS or it can
exist on a separate router connected to the CMTS upstream interface. exist on a separate router connected to the CMTS upstream interface.
The CM will need to bridge IPv6 unicast and multicast traffic. The CM will need to bridge IPv6 unicast and multicast traffic.
Figure 6.2.2.3 illustrates this deployment scenario Figure 6.2.2.3 illustrates this deployment scenario
+-----------+ +-------------+ +-----------+ +-------------+
+-----+ +-------+ | Cable | | CMTS / Edge | +-----+ +-------+ | Cable | | CMTS / Edge |
|Host |--| CM |----| (HFC) |----| |=>ISP |Host |--| CM |----| (HFC) |---| |=>ISP
+-----+ +-------+ | Network | | Router | Network +-----+ +-------+ | Network | | Router | Network
+-----------+ +-------------+ +-----------+ +-------------+
|-------||----------------------------||----------------| |-------||---------------------------||---------------|
IPv4/v6 IPv4/v6 IPv4/v6 IPv4/v6 IPv4/v6 IPv4/v6
Figure 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 be Since the CM still acts as a Layer-2 bridge, it does not need to be
dual-stack. The CM will need to support bridging of IPv6 unicast and dual-stack. The CM will need to support bridging of IPv6 unicast and
multicast traffic and IGMPv3/MLDv2 or v1 snooping which requires multicast traffic and IGMPv3/MLDv2 or v1 snooping which requires
changes in the DOCSIS specification. In this scenario the following changes in the DOCSIS specification. In this scenario the following
skipping to change at page 22, line 9 skipping to change at page 22, line 9
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 CM using DHCPv4 for management purposes. In an IPv6 environment, the CM
will continue to use an IPv4 address for management purposes. The will continue to use an IPv4 address for management purposes. The
cable operator can also choose to assign an IPv6 address to the CM cable operator can also choose to assign an IPv6 address to the CM
for management, but the CM will have to be upgraded to support this for management, but the CM will have to be upgraded to support this
functionality. functionality.
IPv6 address assignment for the CM and host can be done via DHCP or IPv6 address assignment for the CM and host can be done via DHCP or
stateless autoconfiguration. If the CM uses an IPv4 address for stateless auto-configuration. If the CM uses an IPv4 address for
management, it will use DHCPv4 for its address assignment and the management, it will use DHCPv4 for its address assignment and the
CMTS will need to act as a DHCPv4 relay agent. If the CM uses an CMTS will need to act as a DHCPv4 relay agent. If the CM uses an
IPv6 address for management, it can use DHCPv6 with the CMTS acting IPv6 address for management, it can use DHCPv6 with the CMTS acting
as a DHCPv6 relay agent or the CMTS can be statically configured with as a DHCPv6 relay agent or the CMTS can be statically configured with
a /64 prefix and it can send out RA messages out the cable interface. a /64 prefix and it can send out RA messages out the cable interface.
The CMs connected to the cable interface can use the RA messages to The CMs connected to the cable interface can use the RA messages to
auto-configure themselves with an IPv6 address. All CMs connected to auto-configure themselves with an IPv6 address. All CMs connected to
the cable interface will be in the same subnet. the cable interface will be in the same subnet.
The hosts can receive their IPv6 address via DHCPv6 or stateless The hosts can receive their IPv6 address via DHCPv6 or stateless
autoconfiguration. With DHCPv6, the CMTS may need to act as a DHCPv6 auto-configuration. With DHCPv6, the CMTS may need to act as a
relay agent and forward DHCP messages between the hosts and the DHCP DHCPv6 relay agent and forward DHCP messages between the hosts and
server. With stateless autoconfiguration, the CMTS will be the DHCP server. With stateless auto-configuration, the CMTS will be
configured with multiple /64 prefixes and send out RA messages to the configured with multiple /64 prefixes and send out RA messages to the
hosts. If the CMTS is not also acting as an ER, the RA messages will hosts. If the CMTS is not also acting as an ER, the RA messages will
come from the ER connected to the CMTS upstream interface. The CMTS come from the ER connected to the CMTS upstream interface. The CMTS
will need to forward the RA messages downstream or act as an ND will need to forward the RA messages downstream or act as an ND
proxy. proxy.
6.2.2.3.3 Data Forwarding 6.2.2.3.3 Data Forwarding
All IPv6 traffic will be sent to/from the CMTS and hosts. Data All IPv6 traffic will be sent to/from the CMTS and hosts. Data
forwarding will work the same way it works in currently deployed forwarding will work the same way it works in currently deployed
skipping to change at page 23, line 14 skipping to change at page 23, line 14
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-in-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 be Since the CM still acts as a Layer-2 bridge, it does not need to be
dual-stack nor does it need to support IPv6. In this scenario the dual-stack nor does it need to support IPv6. In this scenario the
following devices have to be upgraded to dual stack: Host, GWR and following devices have to be upgraded to dual stack: Host, GWR and
CMTS/ER. CMTS/ER.
skipping to change at page 24, line 24 skipping to change at page 24, line 24
In this scenario the Cable Operator can offer native IPv6 services to In this scenario the Cable Operator can offer native IPv6 services to
its customers since the cable network including the CM/Embedded GWR its customers since the cable network including the CM/Embedded GWR
and CMTS support IPv6. The ER functionality can be included in the and CMTS support IPv6. The ER functionality can be included in the
CMTS or it can exist on a separate router connected to the CMTS CMTS or it can exist on a separate router connected to the CMTS
upstream interface. The CM/Embedded GWR acts as a Layer 3 device. upstream interface. The CM/Embedded GWR acts as a Layer 3 device.
Figure 6.2.2.5 illustrates this deployment scenario Figure 6.2.2.5 illustrates this deployment scenario
+-----------+ +-------------+ +-----------+ +-------------+
+-----+ +-----------+ | Cable | | CMTS / Edge | +-----+ +-----------+ | Cable | | CMTS / Edge |
|Host |---| CM / GWR |----| (HFC) |----| |=> ISP |Host |---| CM / GWR |---| (HFC) |---| |=>ISP
+-----+ +-----------+ | Network | | Router | Network +-----+ +-----------+ | Network | | Router | Network
+-----------+ +-------------+ +-----------+ +-------------+
|----------------------------------------------------------| |---------------------------------------------------------|
IPv4/v6 IPv4/v6
Figure 6.2.2.5 Figure 6.2.2.5
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 end- Since the CM/GWR acts as a Layer 3 device, IPv6 can be deployed end-
to-end. In this scenario the following devices have to be upgraded to-end. In this scenario the following devices have to be upgraded
to dual-stack: Host, CM/GWR and CMTS/ER. to dual-stack: Host, CM/GWR and CMTS/ER.
skipping to change at page 25, line 15 skipping to change at page 25, line 15
does today in DHCPv4. All CM/GWR connected to the same cable does today in DHCPv4. All CM/GWR connected to the same cable
interface on the CMTS belong to same management /64 prefix. The interface on the CMTS belong to same management /64 prefix. The
hosts connected to the same cable interface on the CMTS may belong to hosts connected to the same cable interface on the CMTS may belong to
different /64 customer prefixes as the CMTS may have multiple /64 different /64 customer prefixes as the CMTS may have multiple /64
prefixes configured under its cable interfaces. prefixes configured under its cable interfaces.
It is also possible to use DHCP-PD for IPv6 address assignment. In It is also possible to use DHCP-PD for 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 sent 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 by the CMTS/ER in RA message. Once the CM/GWR assigns an IPv6
address to its upstream interface it will request a /48 [8] prefix address to its upstream interface it will request a /48 [7] prefix
from the CMTS/ER and chop this /48 prefix into /64s for assigning from the CMTS/ER and chop this /48 prefix into /64s for assigning
IPv6 addresses to hosts. Currently the DHCP-PD functionality cannot IPv6 addresses to hosts. Currently the DHCP-PD functionality cannot
be implemented if the DHCP-PD server is not the Edge Router. If the be implemented if the DHCP-PD server is not the Edge Router. If the
DHCP-PD messages are relayed, the Edge Router does not have a 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 network is configured with a /64 mechanism. The uplink to the ISP network is configured with a /64
prefix as well. prefix as well.
6.2.2.5.3 Data Forwarding 6.2.2.5.3 Data Forwarding
The host will use the CM/GWR as the Layer 3 next hop. The CM/GWR The host will use the CM/GWR as the Layer 3 next hop. The CM/GWR
will forward all IPv6 traffic to/from the CMTS/ER and hosts. The will forward all IPv6 traffic to/from the CMTS/ER and hosts. The
CMTS/ER will forward IPv6 traffic to/from hosts based on the IP CMTS/ER will forward IPv6 traffic to/from hosts based on the IP
source/destination address. source/destination address.
6.2.2.5.4 Routing 6.2.2.5.4 Routing
The CM/GWR can use a static default route pointing to the CMTS/ER or The CM/GWR can use a static default route pointing to the CMTS/ER or
it can run a routing protocol such as RIP-ng or OSPFv3 between itself it can run a routing protocol such as RIPng or OSPFv3 between itself
and the CMTS. Customer routes from behind the CM/GWR can be carried and the CMTS. Customer routes from behind the CM/GWR can be carried
to the CMTS using routing updates. to the CMTS using routing updates.
If DHCP-PD is used for address assignment a static route is If DHCP-PD is used for address assignment a static route is
automatically installed on the CMTS/ER for each delegated /48 prefix. automatically installed on the CMTS/ER for each delegated /48 prefix.
The static routes need to be redistributed into the IGP at the The static routes need to be redistributed into the IGP at the
CMTS/ER so there is no need for a routing protocol between the CMTS/ER so there is no need for a routing protocol between the
CMTS/ER and the GWR. CMTS/ER and the GWR.
If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or
skipping to change at page 27, line 37 skipping to change at page 27, line 37
The other aspect of security enhancement is mandated IPSec support in The other aspect of security enhancement is mandated IPSec support in
IPv6. The IPv6 specifications mandate implementation of IPSec, but IPv6. The IPv6 specifications mandate implementation of IPSec, but
they do not mandate its use. The IPv4 specifications do not mandate they do not mandate its use. The IPv4 specifications do not mandate
IPSec. IPSec is the same for both IPv4 and IPv6, but it still IPSec. IPSec is the same for both IPv4 and IPv6, but it still
requires a key distribution mechanism. Cable operators may consider requires a key distribution mechanism. Cable operators may consider
deploying it end-to-end on IPv6 as there is not an intermediate deploying it end-to-end on IPv6 as there is not an intermediate
device(i.e. NAT). device(i.e. NAT).
There are limited changes that have to be done for hosts in order to There are limited changes that have to be done for hosts in order to
enhance security. The Privacy extensions [14] for autoconfiguration enhance security. The Privacy extensions [13] for auto-configuration
should be used by the hosts. IPv6 firewall functions could be should be used by the hosts. IPv6 firewall functions could be
enabled, if available on the host or GWR. enabled, if available on the host or GWR.
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) [23] and ACLs should be used on all Reverse Path Forwarding (uRPF) [22] and ACLs should be used on all
interfaces facing subscribers. Filtering should be implemented with interfaces facing subscribers. Filtering should be implemented with
regard for the operational requirements of IPv6 [Security regard for the operational requirements of IPv6 [Security
considerations for IPv6]. 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.
skipping to change at page 28, line 36 skipping to change at page 28, line 36
and Video-over-IP, MSOs are looking for ways to manage the large and Video-over-IP, MSOs are looking for ways to manage the large
number of devices connected to the CMTS. In IPv4, an RFC1918 address number of devices connected to the CMTS. In IPv4, an RFC1918 address
is assigned to these devices like CM for management purposes. Since is assigned to these devices like CM for management purposes. Since
there is a finite number of RFC1918 addresses available, it is there is a finite number of RFC1918 addresses available, it is
becoming difficult for MSOs to manage these devices. becoming difficult for MSOs to manage these devices.
By using IPv6 for management purposes, MSOs can scale their network By using IPv6 for management purposes, MSOs can scale their network
management systems to meet their needs. The CMTS/ER can be management systems to meet their needs. The CMTS/ER can be
configured with a /64 management prefix which is shared among all CMs configured with a /64 management prefix which is shared among all CMs
connected to the CMTS cable interface. Addressing for the CMs can be connected to the CMTS cable interface. Addressing for the CMs can be
done via stateless autoconfiguration. Once the CMs receive the /64 done via stateless auto-configuration. Once the CMs receive the /64
prefix from the CMTS/ER via RA they can configure themselves with an prefix from the CMTS/ER via RA they can configure themselves with an
IPv6 address. IPv6 address.
If there are devices behind the CM which need to be managed by the 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 MSO, another /64 prefix can be defined on the CMTS/ER. These devices
can also use stateless autoconfiguration to assign themselves an IPv6 can also use stateless auto-configuration to assign themselves an
address. IPv6 address.
Traffic sourced from or destined to the management prefix should not Traffic sourced from or destined to the management prefix should not
cross the MSO's network boundaries. cross the MSO's network boundaries.
In this scenario IPv6 will only be used for managing these devices on 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 the Cable Network, all data traffic will still be forwarded by the CM
and CMTS/ER using IPv4. and CMTS/ER using IPv4.
6.2.6.2 Updates to MIBs/Standards to support IPv6 6.2.6.2 Updates to MIBs/Standards to support IPv6
skipping to change at page 29, line 27 skipping to change at page 29, line 27
A. DOCS-QOS-MIB A. DOCS-QOS-MIB
B. DOCS-SUBMGT-MIB (Subscriber Management Interface Specification B. DOCS-SUBMGT-MIB (Subscriber Management Interface Specification
ANNEX B) ANNEX B)
On the CM On the CM
A. DOCS-QOS-MIB A. DOCS-QOS-MIB
B. DOCS-CABLE-DEVICE-MIB (or [20]) B. DOCS-CABLE-DEVICE-MIB (or [19])
7. Broadband DSL Networks 7. Broadband DSL Networks
This section describes the IPv6 deployment options in today's High This section describes the IPv6 deployment options in today's High
Speed DSL Networks. Speed DSL Networks.
7.1 DSL Network Elements 7.1 DSL Network Elements
Digital Subscriber Line (DSL) broadband services provide users with Digital Subscriber Line (DSL) broadband services provide users with
IP connectivity over the existing twisted-pair telephone lines called IP connectivity over the existing twisted-pair telephone lines called
the local-loop. A wide range of bandwidth offerings are available the local-loop. A wide range of bandwidth offerings are available
depending on the quality of the line and the distance between the depending on the quality of the line and the distance between the
Customer Premises Equipment and the DSLAM. Customer Premise 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 in DSL Modem: It can be a stand alone device, it can be incorporated in
the host, it can incorporate router functionalities and also have the the host, it can incorporate router functionalities and also have the
capabilities to act as a CPE router. capabilities to act as a CPE router.
Customer Premises Router: It is used to provide Layer 3 services for Customer Premise Router: It is used to provide Layer 3 services for
customer premises networks. It is usually used to provide customer premise networks. It is usually used to provide firewalling
firewalling functions and segment broadcast domains for a Small functions and segment broadcast domains for a Small business.
business.
DSL Access Multiplexer (DSLAM): It terminates multiple twisted pair DSL Access Multiplexer (DSLAM): It terminates multiple twisted pair
telephone lines and provides aggregation to BRAS. telephone lines and provides aggregation to BRAS.
Broadband Remote Access Server (BRAS): It aggregates or terminates Broadband Remote Access Server (BRAS): It aggregates or terminates
multiple PVC corresponding to the subscriber DSL circuits. multiple 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
network. network.
Figure 7.1 depicts all the network elements mentioned Figure 7.1 depicts all the network elements mentioned
Customer Premises | Network Access Provider |Network Service Provider Customer Premise | Network Access Provider | Network Service Provider
CP NAP NSP CP NAP NSP
+-----+ +------+ +------+ +--------+ +-----+ +------+ +------+ +--------+
|Hosts|--|Router| +--+ BRAS +---+ Edge | ISP |Hosts|--|Router| +--+ BRAS +---+ Edge | ISP
+-----+ +--+---+ | | | | Router +===> Network +-----+ +--+---+ | | | | Router +==> Network
| | +------+ +--------+ | | +------+ +--------+
+--+---+ | +--+---+ |
| DSL +--+ | | DSL +-+ |
|Modem | | | |Modem | | |
+------+ | +-----+ | +------+ | +-----+ |
+--+ | | +--+ | |
+------+ |DSLAM+--+ +------+ |DSLAM+--+
+-----+ | DSL | +--+ | +-----+ | DSL | +--+ |
|Hosts|--+Modem +--+ +-----+ |Hosts|--+Modem +-+ +-----+
+-----+ +--+---+ +-----+ +--+---+
Figure 7.1 Figure 7.1
7.2 Deploying IPv6 in IPv4 DSL Networks 7.2 Deploying IPv6 in IPv4 DSL Networks
There are three main design approaches to providing IPv4 connectivity There are three main design approaches to providing IPv4 connectivity
over a DSL infrastructure: over a DSL infrastructure:
1. Point-to-Point Model: Each subscriber connects to the DSLAM over 1. Point-to-Point Model: Each subscriber connects to the DSLAM over
a twisted pair and is provided with a unique PVC that links it to the a twisted pair and is provided with a unique PVC that links it to the
skipping to change at page 31, line 38 skipping to change at page 31, line 38
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. Premise Router are bridged over the PVC assigned to the subscriber.
Figure 7.2.1 describes the protocol architecture of this model Figure 7.2.1 describes the protocol architecture of this model
Customer Premises NAP NSP Customer Premise NAP NSP
|-------------------------| |---------------| |--------------------| |-------------------------| |---------------| |------------------|
+-----+ +-------+ +-----+ +--------+ +----------+ +-----+ +-------+ +-----+ +--------+ +----------+
|Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP |Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP
+-----+ +-------+ |Modem| +--------+ | Router +==>Network +-----+ +-------+ |Modem| +--------+ | Router +=>Network
+-----+ +----------+ +-----+ +----------+
|----------------------------| |----------------------------|
ATM ATM
Figure 7.2.1 Figure 7.2.1
7.2.1.1 IPv6 Related Infrastructure Changes 7.2.1.1 IPv6 Related Infrastructure Changes
In this scenario the DSL modem and the entire NAP is Layer 3 unaware, In this scenario the DSL modem and the entire NAP is Layer 3 unaware,
so no changes are needed to support IPv6. The following devices have so no changes are needed to support IPv6. The following devices have
to be upgraded to dual stack: Host, Customer Router (if present) and to be upgraded to dual stack: Host, Customer Router (if present) and
Edge Router. Edge Router.
7.2.1.2 Addressing 7.2.1.2 Addressing
The Hosts or the Customer Routers have the Edge Router as their Layer The Hosts or the Customer Routers have the Edge Router as their Layer
3 next hop. 3 next hop.
If there is no Customer Router all the hosts on the subscriber site If there is no Customer Router all the hosts on the subscriber site
belong to the same /64 subnet that is statically configured on the belong to the same /64 subnet that is statically configured on the
Edge Router for that subscriber PVC. The hosts can use stateless Edge Router for that subscriber PVC. The hosts can use stateless
autoconfiguration or stateful DHCPv6 based configuration to acquire auto-configuration or stateful DHCPv6 based configuration to acquire
an address via the Edge Router. an address via the Edge Router.
However, as manual configuration for each customer is a provisioning
challenge, implementations are encouraged to develop mechanism(s)
which automatically map the PVC (or some other customer-specific
information) to an IPv6 subnet prefix, and advertise the customer-
specific prefix to all the customers with minimal configuration.
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. It B. It can use its link-local address to communicate with the ER. It
can also dynamically acquire through stateless autoconfiguration the can also dynamically acquire through stateless auto-configuration the
prefix for the link between itself and the ER. The later option prefix for the link between itself and the ER. The later option
allows it to contact a remote DHCPv6 server if needed. This step is allows it to contact a remote DHCPv6 server if needed. This step is
followed by a request via DHCP-PD for a prefix shorter than /64 that followed by a request via DHCP-PD for a prefix shorter than /64 that
in turn is divided in /64s and assigned to its downstream interfaces. 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 subscribers to DHCPv6 servers in the ISP network. The VLANs
providing access for subscribers that use DHCP-PD as well, have to be providing access for subscribers that use DHCP-PD as well, have to be
enabled to support the feature. Currently the DHCP-PD functionality enabled to support the feature. Currently the DHCP-PD functionality
skipping to change at page 33, line 6 skipping to change at page 33, line 12
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 network is configured with a /64 mechanism. The uplink to the ISP 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 [11] and stateless DHCPv6 [10]. through stateful DHCPv6 [10] and stateless DHCPv6 [9].
7.2.1.3 Routing 7.2.1.3 Routing
The CPE devices are configured with a default route that points to The CPE devices are configured with a default route that points to
the Edge router. No routing protocols are needed on these devices the Edge router. No routing protocols are needed on these devices
which generally have limited resources. which generally have limited resources.
The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS.
The connected prefixes have to be redistributed. If DHCP-PD is used, The connected prefixes have to be redistributed. If DHCP-PD is used,
with every delegated prefix a static route is installed by the Edge with every delegated prefix a static route is installed by the Edge
Router. For this reason the static routes must also be Router. For this reason the static routes must also be
redistributed. Prefix summarization should be done at the Edge redistributed. Prefix summarization should be done at the Edge
Router. Router.
7.2.2 PPP Terminated Aggregation (PTA) Model 7.2.2 PPP Terminated Aggregation (PTA) Model
The PTA architecture relies on PPP-based protocols (PPPoA [16] and The PTA architecture relies on PPP-based protocols (PPPoA [15] and
PPPoE [15]). The PPP sessions are initiated by Customer Premise PPPoE [14]). The PPP sessions are initiated by Customer Premise
Equipment and are terminated at the BRAS. The BRAS authorizes the Equipment and are terminated at the BRAS. The BRAS authorizes the
session, authenticates the subscriber, and provides an IP address on session, authenticates the subscriber, and provides an IP address on
behalf of the ISP. The BRAS then does Layer 3 routing of the behalf of the ISP. The BRAS then does Layer 3 routing of the
subscriber traffic to the NSP Edge Router. This model is often used subscriber traffic to the NSP Edge Router. This model is often used
when the NSP is also the NAP. when the NSP is also the NAP.
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 Premise NAP NSP
|--------------------| |----------------------| |-----------------| |--------------------| |----------------------| |----------------|
+-----------+ +-----------+
| AAA | | AAA |
+-------+ Radius | +-------+ Radius |
| | TACACS | | | TACACS |
| +-----------+ | +-----------+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----------+ +-----+ +-------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core +-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+ +-----------+
skipping to change at page 34, line 16 skipping to change at page 34, line 35
database. Once the session is established, the BRAS provides an database. Once the session is established, the BRAS provides an
address and maybe a DNS server to the user, information acquired from address and maybe a DNS server to the user, information acquired from
the subscriber profile or from a DHCP server. the subscriber profile or from a DHCP server.
This solution scales better then the Point-to-Point but since there This solution scales better then the Point-to-Point but since there
is only one PPP session per ATM PVC the subscriber can choose a is only one PPP session per ATM PVC the subscriber can choose a
single ISP service at a time. single ISP service at a time.
B. Connection using PPPoE B. Connection using PPPoE
Customer Premises NAP NSP Customer Premise NAP NSP
|--------------------------| |-------------------| |--------------| |--------------------------| |-------------------| |---------------|
+-----------+ +-----------+
| AAA | | AAA |
+-------+ Radius | +-------+ Radius |
| | TACACS | | | TACACS |
| +-----------+ | +-----------+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----------+ +-----+ +-------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +----------+ DSLAM +-+ BRAS +-+ Edge | C |Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +----------+ | Router +=>O +-----+ +-------+ +--------+ +----------+ | Router +=>O
| | R | | R
+-----------+ E +-----------+ E
|-------------------------------| |--------------------------------|
PPP PPP
Figure 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 MTU important to remember that the PPPoE encapsulation reduces the IP MTU
available for the customer traffic due to additional headers. available for the customer traffic due to additional headers.
The network design and operation of the PTA model is the same The network design and operation of the PTA model is the same
regardless of the PPP encapsulation type used. regardless of the PPP encapsulation type used.
skipping to change at page 35, line 30 skipping to change at page 35, line 47
The BRAS has a /64 prefixes configured on the link to the Edge The BRAS has a /64 prefixes configured on the link to the Edge
router. The Edge router links are also configured with /64 prefixes router. The Edge router links are also configured with /64 prefixes
to provide connectivity to the rest of the ISP network. to provide connectivity to the rest of the ISP network.
The prefixes used for subscriber and the ones delegated via DHCP-PD The prefixes used for subscriber and the ones delegated via DHCP-PD
should be planned in a manner that allows maximum summarization at should be planned in a manner that allows maximum summarization at
the BRAS. the BRAS.
Other information of interest to the host, such as DNS, is provided Other information of interest to the host, such as DNS, is provided
through stateful [11] and stateless [10] DHCPv6. through stateful [10] and stateless [9] DHCPv6.
7.2.2.3 Routing 7.2.2.3 Routing
The CPE devices are configured with a default route that points to The CPE devices are configured with a default route that points to
the BRAS router. No routing protocols are needed on these devices the BRAS router. No routing protocols are needed on these devices
which generally have limited resources. which generally have limited resources.
The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the
addresses assigned to the PPP sessions are represented as connected addresses assigned to the PPP sessions are represented as connected
host routes, connected prefixes have to be redistributed. If DHCP-PD host routes, connected prefixes have to be redistributed. If DHCP-PD
skipping to change at page 36, line 16 skipping to change at page 36, line 33
In the LAA model the BRAS forwards the CPE initiated session to the In the LAA model the BRAS forwards the CPE initiated session to the
ISP over an L2TPv2 tunnel established between the BRAS and the Edge ISP over an L2TPv2 tunnel established between the BRAS and the Edge
Router. In this case the authentication, authorization and Router. In this case the authentication, authorization and
subscriber configuration are performed by the ISP itself. There are subscriber configuration are performed by the ISP itself. There are
two types of PPP encapsulations that can be leveraged with this two types of PPP encapsulations that can be leveraged with this
model: model:
A. Connection via PPPoA A. Connection via PPPoA
Customer Premises NAP NSP Customer Premise NAP NSP
|--------------------| |----------------------| |-----------------| |--------------------| |----------------------| |----------------|
+-----------+ +-----------+
| AAA | | AAA |
+-------+ Radius | +-------+ Radius |
| | TACACS | | | TACACS |
| +-----+-----+ | +-----+-----+
| | | |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+ +-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge | |Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core +-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+ +-----------+
|----------------------------------------| |----------------------------------------|
PPP PPP
|------------| |------------|
L2TPv2 L2TPv2
Figure 7.2.3.1 Figure 7.2.3.1
B. Connection via PPPoE B. Connection via PPPoE
Customer Premises NAP NSP Customer Premise NAP NSP
|-------------------------| |--------------------| |--------------| |--------------------------| |--------------------| |---------------|
+-----------+ +-----------+
| AAA | | AAA |
+------+ Radius | +------+ Radius |
| | TACACS | | | TACACS |
| +-----+-----+ | +-----+-----+
| | | |
+-----+ +-------+ +--------+ +----+-----+ +----+------+ +-----+ +-------+ +--------+ +----+-----+ +----+------+
|Hosts|--+Router +----------+ DSLAM +-+ BRAS +-+ Edge | C |Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +----------+ | Router +=>O +-----+ +-------+ +--------+ +----------+ | Router +=>O
| | R | | R
+-----------+ E +-----------+ E
|---------------------------------------------| |-----------------------------------------------|
PPP PPP
|------------| |--------------|
L2TPv2 L2TPv2
Figure 7.2.3.2 Figure 7.2.3.2
The network design and operation of the PTA model is the same The network design and operation of the PTA model is the same
regardless of the PPP encapsulation type used. regardless of the PPP encapsulation type used.
7.2.3.1 IPv6 Related Infrastructure Changes 7.2.3.1 IPv6 Related Infrastructure Changes
In this scenario the BRAS is forwarding the PPP sessions initiated by In this scenario the BRAS is forwarding the PPP sessions initiated by
the subscriber over the L2TPv2 tunnel established to the LNS, the the subscriber over the L2TPv2 tunnel established to the LNS, the
skipping to change at page 38, line 9 skipping to change at page 38, line 9
In the latter case, once the session is established with the Edge In the latter case, once the session is established with the Edge
Router, DHCP-PD can be used to acquire prefixes for the Customer Router, DHCP-PD can be used to acquire prefixes for the Customer
Router interfaces. The Edge Router has to be enabled to support Router interfaces. The Edge Router has to be enabled to support
DHCP-PD and to relay the DHCPv6 requests generated by the hosts on DHCP-PD and to relay the DHCPv6 requests generated by the hosts on
the subscriber sites. the subscriber sites.
The BRAS has a /64 prefix configured on the link to the Edge router. The BRAS has a /64 prefix configured on the link to the Edge router.
The Edge router links are also configured with /64 prefixes to The Edge router links are also configured with /64 prefixes to
provide connectivity to the rest of the ISP network. Other provide connectivity to the rest of the ISP network. Other
information of interest to the host, such as DNS, is provided through information of interest to the host, such as DNS, is provided through
stateful [11] and stateless [10] DHCPv6. stateful [10] and stateless [9] 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 from the IP pool of the ER (LNS) it connected to. This allows the
ERs (LNSs) to aggregate the addresses handed out to the customers. ERs (LNSs) to aggregate the addresses handed out to the customers.
In the case of IPv6, an important constraint that likely will be In the case of IPv6, an important constraint that likely will be
enforced is that the customer should keep its own address regardless enforced is that the customer should keep its own address regardless
skipping to change at page 41, line 33 skipping to change at page 41, line 33
The deployment of IPv6 multicast services relies on MLD, identical to The deployment of IPv6 multicast services relies on MLD, identical to
IGMP in IPv4 and on PIM for routing. ASM (Any Source Multicast) and IGMP in IPv4 and on PIM for routing. ASM (Any Source Multicast) and
SSM (Single Source Multicast) service models operate almost the same SSM (Single Source Multicast) service models operate almost the same
as in IPv4. Both have the same benefits and disadvantages as in as in IPv4. Both have the same benefits and disadvantages as in
IPv4. Nevertheless, the larger address space and the scoped address IPv4. Nevertheless, the larger address space and the scoped address
architecture provide major benefits for multicast IPv6. Through architecture provide major benefits for multicast IPv6. Through
RFC3306 the large address space provides the means to assign global RFC3306 the large address space provides the means to assign global
multicast group addresses to organizations or users that were multicast group addresses to organizations or users that were
assigned unicast prefixes. It is a significant improvement with assigned unicast prefixes. It is a significant improvement with
respect to the IPv4 GLOP mechanism [19]. respect to the IPv4 GLOP mechanism [18].
This facilitates the deployment of multicast services. The This facilitates the deployment of multicast services. The
discussion of this section applies to all the multicast sections in discussion of this section applies to all the multicast sections in
the document. the document.
7.3.1 ASM Based Deployments 7.3.1 ASM Based Deployments
Any Source Multicast (ASM) is useful for Service Providers that Any Source Multicast (ASM) is useful for Service Providers that
intend to support the forwarding of multicast traffic of their intend to support the forwarding of multicast traffic of their
customers. It is based on the PIM-SM protocol and it is more complex customers. It is based on the PIM-SM protocol and it is more complex
to manage because of the use of Rendezvous Points (RPs). With IPv6, to manage because of the use of Rendezvous Points (RPs). With IPv6,
static RP and BSR [34] can be used for RP-to-group mapping similar to static RP and BSR [34] can be used for RP-to-group mapping similar to
IPv4. Additionally, the larger IPv6 address space allows for IPv4. Additionally, the larger IPv6 address space allows for
building up of group addresses that incorporate the address of the building up of group addresses that incorporate the address of the
RP. This RP-to-group mapping mechanism is called Embedded RP and is RP. This RP-to-group mapping mechanism is called Embedded RP and is
specific to IPv6. specific to IPv6.
In inter-domain deployments, Multicast Source Discovery Protocol In inter-domain deployments, Multicast Source Discovery Protocol
(MSDP) [22] is an important element of IPv4 PIM-SM deployments. MSDP (MSDP) [21] is an important element of IPv4 PIM-SM deployments. MSDP
is meant to be a solution for the exchange of source registration is meant to be a solution for the exchange of source registration
information between RPs in different domains. This solution was information between RPs in different domains. This solution was
intended to be temporary. This is one of the reasons why it was intended to be temporary. This is one of the reasons why it was
decided not to implement MSDP in IPv6 [32]. decided not to implement MSDP in IPv6 [32].
For multicast reachability across domains, Embedded RP could be used. For multicast reachability across domains, Embedded RP can be used.
Despite its shortcomings, MSDP provides additional flexibility in As Embedded RP provides roughly the same capabilities as MSDP, but in
managing the domains that may not be matched with the protocols a slightly different way, the best management practices for ASM
available in IPv6 today. The value of such flexibility is still multicast with embedded RP still remain to be developed.
under evaluation.
7.3.2 SSM Based Deployments 7.3.2 SSM Based Deployments
Based on PIM-SSM, the Source Specific Multicast deployments do not Based on PIM-SSM, the Source Specific Multicast deployments do not
need an RP and the related protocols (such as BSR or MSDP) but rely need an RP and the related protocols (such as BSR or MSDP) but rely
on the listeners to know the source of the multicast traffic they on the listeners to know the source of the multicast traffic they
plan to receive. The lack of RP makes SSM not only simpler to plan to receive. The lack of RP makes SSM not only simpler to
operate but also robust, it is not impacted by RP failures or inter operate but also robust, it is not impacted by RP failures or inter
domain constraints. It is also has a higher level of security (No RP domain constraints. It is also has a higher level of security (No RP
to be targeted by attacks). For more discussions on the topic of to be targeted by attacks). For more discussions on the topic of
skipping to change at page 42, line 44 skipping to change at page 42, line 43
sources. sources.
Subscribers might use a set-top box that is responsible for the Subscribers might use a set-top box that is responsible for the
control piece of the multicast service (does group joins/leaves). control piece of the multicast service (does group joins/leaves).
The subscriber hosts can also join desired multicast groups as long The subscriber hosts can also join desired multicast groups as long
as they are enabled to support MLDv1 or MLDv2. If a customer premise as they are enabled to support MLDv1 or MLDv2. If a customer premise
router is used then it has to be enabled to support MLDv1 and MLDv2 router is used then it has to be enabled to support MLDv1 and MLDv2
in order to process the requests of the hosts. It has to be enabled in order to process the requests of the hosts. It has to be enabled
to support PIM-SSM in order to send PIM joins/leaves up to its Layer to support PIM-SSM in order to send PIM joins/leaves up to its Layer
3 next hop whether it is the BRAS or the Edge router. When enabling 3 next hop whether it is the BRAS or the Edge router. When enabling
this functionality on a customer premises router, its limited this functionality on a customer premise router, its limited
resources should be taken into consideration. Another option would resources should be taken into consideration. Another option would
be for the customer premises router to support MLD proxy routing. be for the customer premise 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 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 premise 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
functions should be investigated further. functions should be investigated further.
skipping to change at page 43, line 51 skipping to change at page 43, line 49
It is important to note that when traffic is encrypted end-to-end, It is important to note that when traffic is encrypted end-to-end,
the traversed network devices will not have access to many of the the traversed network devices will not have access to many of the
packet fields used for classification purposes. In these cases packet fields used for classification purposes. In these cases
routers will most likely place the packets in the default classes. routers will most likely place the packets in the default classes.
The QoS design should take into consideration this scenario and try The QoS design should take into consideration this scenario and try
to use mainly IP header fields for classification purposes. to use mainly IP header fields for classification purposes.
7.5 IPv6 Security Considerations 7.5 IPv6 Security Considerations
There are limited changes that have to be done for CPEs in order to There are limited changes that have to be done for CPEs in order to
enhance security. The Privacy extensions for auto-configuration [14] enhance security. The Privacy extensions for auto-configuration [13]
should be used by the hosts. ISPs can track the prefixes it assigns should be used by the hosts. ISPs can track the prefixes it assigns
to subscribers relatively easily. If however the ISPs are required to subscribers relatively easily. If however the ISPs are required
by regulations to track their users at /128 address level, the by regulations to track their users at /128 address level, the
Privacy Extensions can be implemented only in parallel with network Privacy Extensions can be implemented only in parallel with network
management tools that could provide traceability of the hosts. IPv6 management tools that could provide traceability of the hosts. IPv6
firewall functions should be enabled on the hosts or customer firewall functions should be enabled on the hosts or customer premise
premises router if present. router if present.
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 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
skipping to change at page 45, line 25 skipping to change at page 45, line 24
Ethernet broadband services can be provided. Such services are Ethernet broadband services can be provided. Such services are
generally available in metropolitan areas, in multi tenant buildings generally available in metropolitan areas, in multi tenant buildings
where an Ethernet infrastructure can be deployed in a cost effective where an Ethernet infrastructure can be deployed in a cost effective
manner. In such environments Metro-Ethernet services can be used to manner. In such environments Metro-Ethernet services can be used to
provide aggregation and uplink to a Service Provider. provide aggregation and uplink to a Service Provider.
The following network elements are typical of an Ethernet network: The following network elements are typical of an Ethernet network:
Access Switch: It is used as a Layer 2 access device for subscribers. Access Switch: It is used as a Layer 2 access device for subscribers.
Customer Premises Router: It is used to provide Layer 3 services for Customer Premise Router: It is used to provide Layer 3 services for
customer premises networks. customer premise networks.
Aggregation Ethernet Switches: Aggregates multiple subscribers. Aggregation Ethernet Switches: Aggregates multiple subscribers.
Broadband Remote Access Server (BRAS) Broadband Remote Access Server (BRAS)
Edge Router (ER) Edge Router (ER)
Figure 8.1 depicts all the network elements mentioned. Figure 8.1 depicts all the network elements mentioned.
Customer Premises | Network Access Provider |Network Service Provider Customer Premise | Network Access Provider | Network Service Provider
CP NAP NSP CP NAP NSP
+-----+ +------+ +------+ +--------+ +-----+ +------+ +------+ +--------+
|Hosts|--|Router| +-+ BRAS +---+ Edge | ISP |Hosts|--|Router| +-+ BRAS +--+ Edge | ISP
+-----+ +--+---+ | | | | Router +===> Network +-----+ +--+---+ | | | | Router +===> Network
| | +------+ +--------+ | | +------+ +--------+
+--+-----+ | +--+----+ |
|Access +-+ | |Access +-+ |
|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 7. 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. In such an environment some of HomePNA based network environment. In such an environment some of
the network elements might be differently named. the network elements might be differently named.
8.2 Deploying IPv6 in IPv4 Broadband Ethernet Networks 8.2 Deploying IPv6 in IPv4 Broadband Ethernet Networks
skipping to change at page 47, line 25 skipping to change at page 47, line 8
IPv6 deployment will match the IPv4 one. This approach is presented IPv6 deployment will match the IPv4 one. This approach is presented
in sections 8.2.1-3 that describe currently deployed IPv4 over in sections 8.2.1-3 that describe currently deployed IPv4 over
Ethernet broadband access deployments. Under certain circumstances Ethernet broadband access deployments. Under certain circumstances
where new service types or service needs justify it, IPv4 and IPv6 where new service types or service needs justify it, IPv4 and IPv6
network architectures could be different as described in section network architectures could be different as described in section
8.2.4. 8.2.4.
8.2.1 Point-to-Point Model 8.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 VLAN assigned to the subscriber. Premise Router are bridged over the VLAN assigned to the subscriber.
Figure 8.2.1 describes the protocol architecture of this model. Figure 8.2.1 describes the protocol architecture of this model.
| Customer Premises | | NAP | NSP | | Customer Premise | | NAP | NSP |
+-----+ +------+ +------+ +--------+ +----------+ +-----+ +------+ +------+ +--------+ +----------+
|Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP |Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP
+-----+ +------+ |Switch| +--------+ 802.1q | Router +==>Network +-----+ +------+ |Switch| +--------+ 802.1q | Router +=>Network
+------+ +----------+ +------+ +----------+
|----------------------------| |----------------------------|
Ethernet/VLANs Ethernet/VLANs
Figure 8.2.1 Figure 8.2.1
8.2.1.1 IPv6 Related Infrastructure Changes 8.2.1.1 IPv6 Related Infrastructure Changes
In this scenario the Access Switch on the customer site and the In this scenario the Access Switch on the customer site and the
skipping to change at page 48, line 11 skipping to change at page 47, line 40
The Access switches might need upgrades to support certain IPv6 The Access switches might need upgrades to support certain IPv6
related features such as MLD Snooping. related features such as MLD Snooping.
8.2.1.2 Addressing 8.2.1.2 Addressing
The Hosts or the Customer Routers have the Edge Router as their Layer The Hosts or the Customer Routers have the Edge Router as their Layer
3 next hop. If there is no Customer Router all the hosts on the 3 next hop. If there is no Customer Router all the hosts on the
subscriber site belong to the same /64 subnet that is statically subscriber site belong to the same /64 subnet that is statically
configured on the Edge Router for that subscriber VLAN. The hosts configured on the Edge Router for that subscriber VLAN. The hosts
can use stateless autoconfiguration or stateful DHCPv6 based can use stateless auto-configuration or stateful DHCPv6 based
configuration to acquire an address via the Edge Router. configuration to acquire an address via the Edge Router.
However, as manual configuration for each customer is a provisioning
challenge, implementations are encouraged to develop mechanism(s)
which automatically map the VLAN (or some other customer-specific
information) to an IPv6 subnet prefix, and advertise the customer-
specific prefix to all the customers with minimal configuration.
If a Customer Router is present: 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. It B. It can use its link-local address to communicate with the ER. It
can also dynamically acquire through stateless autoconfiguration the can also dynamically acquire through stateless auto-configuration the
address for the link between itself and the ER. This step is 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.
The Edge Router has a /64 prefix configured for each subscriber VLAN. The Edge Router has a /64 prefix configured for each subscriber VLAN.
Each VLAN should be enabled to relay DHCPv6 requests from the Each VLAN should be enabled to relay DHCPv6 requests from the
subscribers to DHCPv6 servers in the ISP network. The VLANs subscribers to DHCPv6 servers in the ISP network. The VLANs
providing access for subscribers that use DHCP-PD as well, have to be providing access for subscribers that use DHCP-PD as well, have to be
enabled to support the feature. Currently the DHCP-PD functionality enabled to support the feature. Currently the DHCP-PD functionality
skipping to change at page 48, line 47 skipping to change at page 48, line 34
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 network is configured with a /64 mechanism. The uplink to the ISP network is configured with a /64
prefix as well. The uplink to the ISP network is configured with a prefix as well. The uplink to the ISP network is configured with a
/64 prefix as well. /64 prefix as well.
The prefixes used for subscriber links and the ones delegated via The prefixes used for subscriber links and the ones delegated via
DHCP-PD should be planned in a manner that allows as much DHCP-PD should be planned in a manner that allows as much
summarization as possible at the Edge Router. summarization as possible at the Edge Router.
Other information of interest to the host, such as DNS, is provided Other information of interest to the host, such as DNS, is provided
through stateful [11] and stateless [10] DHCPv6. through stateful [10] and stateless [9] 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 generally have limited resources. which generally have limited resources.
The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS.
The connected prefixes have to be redistributed. If DHCP-PD is used, The connected prefixes have to be redistributed. If DHCP-PD is used,
with every delegated prefix a static route is installed by the Edge with every delegated prefix a static route is installed by the Edge
skipping to change at page 49, line 24 skipping to change at page 49, line 12
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 of authenticates the subscriber, and provides an IP address on behalf of
the ISP. The BRAS then does Layer 3 routing of the subscriber the ISP. The BRAS then does Layer 3 routing of the subscriber
traffic to the NSP Edge Router. 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. The PPPoE logical diagram in an Ethernet NSP is also the NAP. The PPPoE logical diagram in an Ethernet
Broadband Network is shown in Fig 8.2.2.1. Broadband Network is shown in Fig 8.2.2.1.
| Customer Premises | | NAP | | NSP | | Customer Premise | | NAP | | NSP |
+-----------+ +-----------+
| AAA | | AAA |
+-----+ Radius | +-------+ Radius |
| | TACACS | | | TACACS |
| +-----------+ | +-----------+
+-----+ +-------+ +--------+ +--------+ +----+---+ +-----------+ +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C |Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +--------+ +--------+ | Router +=>O +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O
|---------------- PPP ----------------| | | R |---------------- PPP ----------------| | | R
+-----------+ E +-----------+ E
Figure 8.2.2.1 Figure 8.2.2.1
The PPP sessions are initiated by the Customer Premise Equipment The PPP sessions are initiated by the Customer Premise Equipment
(Host or Router). The BRAS authenticates the subscriber against a (Host or Router). The BRAS authenticates the subscriber against a
local or a remote database. Once the session is established, the local or a remote database. Once the session is established, the
BRAS provides an address and maybe a DNS server to the user, BRAS provides an address and maybe a DNS server to the user,
information acquired from the subscriber profile or from a DHCP information acquired from the subscriber profile or from a DHCP
server. server.
skipping to change at page 50, line 43 skipping to change at page 50, line 29
The BRAS has a /64 prefix configured on the link facing the Edge The BRAS has a /64 prefix configured on the link facing the Edge
router. The Edge router links are also configured with /64 prefixes router. The Edge router links are also configured with /64 prefixes
to provide connectivity to the rest of the ISP network. to provide connectivity to the rest of the ISP network.
The prefixes used for subscriber and the ones delegated via DHCP-PD The prefixes used for subscriber and the ones delegated via DHCP-PD
should be planned in a manner that allows maximum summarization at should be planned in a manner that allows maximum summarization at
the BRAS. the BRAS.
Other information of interest to the host, such as DNS, is provided Other information of interest to the host, such as DNS, is provided
through stateful [11] and stateless [10] DHCPv6. through stateful [10] and stateless [9] 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 generally have limited resources. which generally have limited resources.
The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the
addresses assigned to the PPP sessions are represented as connected addresses assigned to the PPP sessions are represented as connected
host routes, connected prefixes have to be redistributed. If DHCP-PD host routes, connected prefixes have to be redistributed. If DHCP-PD
skipping to change at page 51, line 22 skipping to change at page 51, line 12
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 the In the LAA model the BRAS forwards the CPE initiated session to the
ISP over an L2TPv2 tunnel established between the BRAS and the Edge ISP over an L2TPv2 tunnel established between the BRAS and the Edge
Router. In this case the authentication, authorization and Router. In this case the authentication, authorization and
subscriber configuration are performed by the ISP itself. subscriber configuration are performed by the ISP itself.
| Customer Premises | | NAP | | NSP | | Customer Premise | | NAP | | NSP |
+----------+ +-----------+
| AAA | | AAA |
+-----+ Radius | +------+ Radius |
| | TACACS | | | TACACS |
| +----+-----+ | +-----+-----+
| | | |
+-----+ +-------+ +--------+ +--------+ +----+----+ +----------+ +-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C |Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +--------+ +---------+ | Router +=>O +-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O
| | R | | R
+----------+ E +-----------+ E
|---------------------------------------------| |-----------------------------------------------|
PPP PPP
|------------| |--------------|
L2TPv2 L2TPv2
Figure 8.2.3.1 Figure 8.2.3.1
8.2.3.1 IPv6 Related Infrastructure Changes 8.2.3.1 IPv6 Related Infrastructure Changes
In this scenario the BRAS is Layer 3 aware and it has to be upgraded In this scenario the BRAS is Layer 3 aware and it has to be upgraded
to support IPv6. The PPP sessions initiated by the subscriber are to support IPv6. The PPP sessions initiated by the subscriber are
forwarded over the L2TPv2 tunnel to the aggregation point in the ISP forwarded over the L2TPv2 tunnel to the aggregation point in the ISP
network. The BRAS (LAC) can aggregate IPv6 PPP sessions and tunnel network. The BRAS (LAC) can aggregate IPv6 PPP sessions and tunnel
them to the LNS using L2TPv2. The L2TPv2 tunnel between the LAC and them to the LNS using L2TPv2. The L2TPv2 tunnel between the LAC and
skipping to change at page 52, line 33 skipping to change at page 52, line 22
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 network is configured with a /64 mechanism. The uplink to the ISP network is configured with a /64
prefix as well. prefix as well.
The BRAS has a /64 prefix configured on the link to the Edge router. The BRAS has a /64 prefix configured on the link to the Edge router.
The Edge router links are also configured with /64 prefixes to The Edge router links are also configured with /64 prefixes to
provide connectivity to the rest of the ISP network. provide connectivity to the rest of the ISP network.
Other information of interest to the host, such as DNS, is provided Other information of interest to the host, such as DNS, is provided
through stateful [11] and stateless [10] DHCPv6. through stateful [10] and stateless [9] DHCPv6.
The address assignment and prefix summarization issues discussed in The address assignment and prefix summarization issues discussed in
section 7.2.3.2 are relevant in the same way for this media access section 7.2.3.2 are relevant in the same way for this media access
type as well. type as well.
8.2.3.3 Routing 8.2.3.3 Routing
The CPE devices are configured with a default route that points to The CPE devices are configured with a default route that points to
the Edge router that terminates the PPP sessions. No routing the Edge router that terminates the PPP sessions. No routing
protocols are needed on these devices which have limited resources. protocols are needed on these devices which have limited resources.
skipping to change at page 55, line 42 skipping to change at page 55, line 42
sources. sources.
Subscribers might use a set-top box that is responsible for the Subscribers might use a set-top box that is responsible for the
control piece of the multicast service (does group joins/leaves). control piece of the multicast service (does group joins/leaves).
The subscriber hosts can also join desired multicast groups as long The subscriber hosts can also join desired multicast groups as long
as they are enabled to support MLDv1 or MLDv2. If a customer premise as they are enabled to support MLDv1 or MLDv2. If a customer premise
router is used then it has to be enabled to support MLDv1 and MLDv2 router is used then it has to be enabled to support MLDv1 and MLDv2
in order to process the requests of the hosts. It has to be enabled in order to process the requests of the hosts. It has to be enabled
to support PIM-SSM in order to send PIM joins/leaves up to its Layer to support PIM-SSM in order to send PIM joins/leaves up to its Layer
3 next hop whether it is the BRAS or the Edge router. When enabling 3 next hop whether it is the BRAS or the Edge router. When enabling
this functionality on a customer premises router, its limited this functionality on a customer premise router, its limited
resources should be taken into consideration. Another option would resources should be taken into consideration. Another option would
be for the customer premises router to support MLD proxy routing. be for the customer premise router to support MLD proxy routing. MLD
MLD snooping or similar layer two multicast related protocols could snooping or similar layer two multicast related protocols could be
be enabled on the NAP switches. enabled on the NAP switches.
The router that is the Layer 3 next hop for the subscriber (BRAS in The router that is the Layer 3 next hop for the subscriber (BRAS in
the PTA model or the Edge router in the LAA and Point-to-Point model) the PTA model or the Edge router in the LAA and Point-to-Point model)
has to be enabled to support MLDv1 and MLDv2 in order to process the has to be enabled to support MLDv1 and MLDv2 in order to process the
requests coming from subscribers without customer premises routers. requests coming from subscribers without customer premise 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
functions should be investigated further. functions should be investigated further.
skipping to change at page 56, line 51 skipping to change at page 56, line 51
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
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 [14] for autoconfiguration enhance security. The Privacy extensions [13] for auto-configuration
should be used by the hosts with the same considerations for host should be used by the hosts with the same considerations for host
traceability as discussed in section 7.5. IPv6 firewall functions traceability as discussed in section 7.5. IPv6 firewall functions
should be enabled on the hosts or customer premises router if should be enabled on the hosts or customer premise router if present.
present.
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.
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).
skipping to change at page 58, line 19 skipping to change at page 58, line 18
integration methods in currently deployed wireless LAN (WLAN) integration methods in currently deployed wireless LAN (WLAN)
infrastructure. infrastructure.
9.1 WLAN Deployment Scenarios 9.1 WLAN Deployment Scenarios
WLAN enables subscribers to connect to the Internet from various WLAN enables subscribers to connect to the Internet from various
locations without the restriction of staying indoors. WLAN is locations without the restriction of staying indoors. WLAN is
standardized by IEEE 802.11a/b/g. Consideration should be also given standardized by IEEE 802.11a/b/g. Consideration should be also given
to IEEE 802.16 WiMAX for similar deployment approaches. IEEE 802.11 to IEEE 802.16 WiMAX for similar deployment approaches. IEEE 802.11
offers maximum transmission speed from 1 or 2 Mbps, IEEE 802.11b offers maximum transmission speed from 1 or 2 Mbps, IEEE 802.11b
offers 11 Mbps and IEEE 802.11a offers up to 54 Mbps. offers 11 Mbps and IEEE 802.11a/g offer up to 54 Mbps.
Figure 9.1 describes the current WLAN architecture. Figure 9.1 describes the current WLAN architecture.
Customer | Access Provider | Service Provider Customer | Access Provider | Service Provider
Premise | | Premise | |
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | |Access Router/| |Underlying| |Edge | |WLAN | ---- | | |Access Router/| |Underlying| |Edge |
|Host/ |-(WLAN)-|AP|-|Layer 2 Switch|-|Technology|-|Router|=>SP |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-|Technology|-|Router|=>SP
|Router| ---- | | | | | | | |Network |Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
| |
+------+ +------+
|AAA | |AAA |
|Server| |Server|
+------+ +------+
Figure 9.1 Figure 9.1
The host should have a wireless network interface card (NIC) in order The host should have a wireless network interface card (NIC) in order
skipping to change at page 59, line 26 skipping to change at page 59, line 24
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 [1] to all IP address and the WLAN Router assigns private addresses [1] to all
WLAN users. The WLAN Router provides NAT functionality while WLAN WLAN users. The WLAN Router provides NAT functionality while WLAN
users access the Internet. users access the Internet.
While deploying IPv6 in the above mentioned WLAN architecture, there While deploying IPv6 in the above mentioned WLAN architecture, there
are three possible scenarios as discussed below. are three possible scenarios as discussed below.
A. Layer 2 Switch Between AP and Edge Router A. Layer 2 NAP with Layer 3 termination at NSP Edge Router
B. Access Router Between AP and Edge Router B. Layer 3 aware NAP with Layer 3 termination at Access 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 NAP with Layer 3 termination at NSP Edge Router
When a Layer 2 switch is present between AP and Edge Router, the AP When a Layer 2 switch is present between AP and Edge Router, the AP
and Layer 2 switch continues to work as a bridge, forwarding IPv4 and and Layer 2 switch continues to work as a bridge, forwarding IPv4 and
IPv6 packets from WLAN Host/Router to Edge Router and vice versa. IPv6 packets from WLAN Host/Router to Edge Router and vice versa.
When initiating the connection, the WLAN host is authenticated by the When initiating the connection, the WLAN host is authenticated by the
AAA server located at the SP network. All the parameters related to AAA server located at the SP network. All the parameters related to
authentication (username, password and etc.) are forwarded by the AP authentication (username, password and etc.) are forwarded by the AP
to the AAA server. The AAA server authenticates the WLAN Hosts and to the AAA server. The AAA server authenticates the WLAN Hosts and
once authenticated and associated successfully with WLAN AP, IPv6 once authenticated and associated successfully with WLAN AP, IPv6
skipping to change at page 60, line 10 skipping to change at page 60, line 10
authentication process is same as used in IPv4. authentication process is same as used in IPv4.
Figure 9.1.1 describes the WLAN architecture when Layer 2 Switch is Figure 9.1.1 describes the WLAN architecture when Layer 2 Switch is
located between AP and Edge Router. located between AP and Edge Router.
Customer | Access Provider | Service Provider Customer | Access Provider | Service Provider
Premise | | Premise | |
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | |Underlying| |Edge | |WLAN | ---- | | | | |Underlying| |Edge |
|Host/ |-(WLAN)-|AP|-|Layer 2 Switch|-|Technology|-|Router|=>SP |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-|Technology|-|Router|=>SP
|Router| ---- | | | | | | | |Network |Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
| |
+------+ +------+
|AAA | |AAA |
|Server| |Server|
+------+ +------+
Figure 9.1.1 Figure 9.1.1
9.1.1.1 IPv6 Related Infrastructure Changes 9.1.1.1 IPv6 Related Infrastructure Changes
skipping to change at page 60, line 32 skipping to change at page 60, line 32
IPv6 will be deployed in this scenario by upgrading the following IPv6 will be deployed in this scenario by upgrading the following
devices to dual-stack: WLAN Host, WLAN Router (if present) and Edge devices to dual-stack: WLAN Host, WLAN Router (if present) and Edge
Router. Router.
9.1.1.2 Addressing 9.1.1.2 Addressing
When customer WLAN Router is not present, the WLAN Host has two When customer WLAN Router is not present, the WLAN Host has two
possible options to get an IPv6 address via the Edge Router. possible options to get an IPv6 address via the Edge Router.
A. The WLAN host can get the IPv6 address from Edge router using A. The WLAN host can get the IPv6 address from Edge router using
stateless auto-configuration [12]. All hosts on the WLAN belong to stateless auto-configuration [11]. All hosts on the WLAN belong to
the same /64 subnet that is statically configured on the Edge Router. the same /64 subnet that is statically configured on the Edge Router.
The IPv6 WLAN Host may use stateless DHCPv6 for obtaining other The IPv6 WLAN Host may use stateless DHCPv6 for obtaining other
information of interest such as DNS and etc. information of interest such as DNS and etc.
B. IPv6 WLAN host can use DHCPv6 [11] to get a IPv6 address from the B. IPv6 WLAN host can use DHCPv6 [10] to get a IPv6 address from the
DHCPv6 server. In this case the DHCPv6 server would be located in DHCPv6 server. In this case the DHCPv6 server would be located in
the SP core network and Edge Router would simply act as a DHCP Relay the SP core network and Edge Router would simply act as a DHCP Relay
Agent. This option is similar to what we do today in case of DHCPv4. Agent. This option is similar to what we do today in case of DHCPv4.
It is important to note that host implementation of stateful auto- It is important to note that host implementation of stateful auto-
configuration is rather limited at this time and this should be configuration is rather limited at this time and this should be
considered if choosing this address assignment option. considered if choosing this address assignment option.
When a customer WLAN Router is present, the WLAN Host has two When a customer WLAN Router is present, the WLAN Host has two
possible options as well for acquiring IPv6 address. possible options as well for acquiring IPv6 address.
A. The WLAN Router may be assigned a prefix between /48 and /64 [8] A. The WLAN Router may be assigned a prefix between /48 and /64 [7]
depending on the SP policy and customer requirements. If the WLAN depending on the SP policy and customer requirements. If the WLAN
Router has multiple networks connected to its interfaces, the network Router has multiple networks connected to its interfaces, the network
administrator will have to configure the /64 prefixes to the WLAN administrator will have to configure the /64 prefixes to the WLAN
Router interfaces connecting the WLAN Hosts on the customer site. Router interfaces connecting the WLAN Hosts on the customer site.
The WLAN Hosts connected to these interfaces can automatically The WLAN Hosts connected to these interfaces can automatically
configure themselves using stateless auto-configuration with /64 configure themselves using stateless auto-configuration with /64
prefix. prefix.
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 auto-
autoconfiguration the address for the link between itself and the ER. configuration the address for the link between itself and the ER.
This step is followed by a request via DHCP-PD for a prefix shorter 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 interfaces
connecting the WLAN Hosts on the customer site. The WLAN Hosts connecting the WLAN Hosts on the customer site. The WLAN Hosts
connected to these interfaces can automatically configure themselves connected to these interfaces can automatically configure themselves
using stateless auto-configuration with /64 prefix. Currently the using stateless auto-configuration with /64 prefix. Currently the
skipping to change at page 61, line 42 skipping to change at page 61, line 42
server for DNS/domain information, proxy configurations and etc. server for DNS/domain information, proxy configurations and etc.
Using this model the SP could change prefixes on the fly and the WLAN Using this model the SP could change prefixes on the fly and the WLAN
Router would simply pull the newest prefix based on the valid/ Router would simply pull the newest prefix based on the valid/
preferred lifetime. preferred lifetime.
The prefixes used for subscriber links and the ones delegated via The prefixes used for subscriber links and the ones delegated via
DHCP-PD should be planned in a manner that allows maximum DHCP-PD should be planned in a manner that allows maximum
summarization as possible at the Edge Router. summarization 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 [11] and stateless [10] DHCPv6. through stateful [10] and stateless [9] 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 generally have limited resources. which generally have limited resources.
The Edge Router runs the IGP used in the SP network such as OSPFv3 or The Edge Router runs the IGP used in the SP network such as OSPFv3 or
IS-IS for IPv6. The connected prefixes have to be redistributed. IS-IS for IPv6. The connected prefixes have to be redistributed.
Prefix summarization should be done at the Edge Router. When DHCP-PD Prefix summarization should be done at the Edge Router. When DHCP-PD
is used, the IGP has to redistribute the static routes installed is used, the IGP has to redistribute the static routes installed
during the process of prefix delegation. during the process of prefix delegation.
9.1.2 Access Router Between AP and SP Edge Router 9.1.2 Layer 3 aware NAP with Layer 3 termination at Access Router
When a Access Router is present between AP and Edge Router, the AP When an Access Router is present between AP and Edge Router, the AP
continues to work as a bridge, bridging IPv4 and IPv6 packets from continues to work as a bridge, bridging IPv4 and IPv6 packets from
WLAN Host/Router to Access/Edge Router and vice versa. The Access WLAN Host/Router to Access Router and vice versa. The Access Router
Router could be part of SP network or owned by a separate Access could be part of SP network or owned by a separate Access Provider.
Provider.
When WLAN Host initiates the connection, the AAA authentication and When WLAN Host initiates the connection, the AAA authentication and
association process with WLAN AP will be similar as explained in association process with WLAN AP will be similar as explained in
section 9.1.1. section 9.1.1.
Figure 9.1.2 describes the WLAN architecture when Access Router is Figure 9.1.2 describes the WLAN architecture when Access Router is
located between AP and Edge Router. located between AP and Edge Router.
Customer | Access Provider | Service Provider Customer | Access Provider | Service Provider
Premise | | Premise | |
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | |Underlying| |Edge | |WLAN | ---- | | | | |Underlying| |Edge |
|Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP |Host/ |-(WLAN)--|AP|-|Access Router |-|Technology|-|Router|=>SP
|Router| ---- | | | | | | | |Network |Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
| |
+------+ +------+
|AAA | |AAA |
|Server| |Server|
+------+ +------+
Figure 9.1.2 Figure 9.1.2
9.1.2.1 IPv6 Related Infrastructure Changes 9.1.2.1 IPv6 Related Infrastructure Changes
skipping to change at page 63, line 7 skipping to change at page 63, line 6
9.1.2.2 Addressing 9.1.2.2 Addressing
There are three possible options in this scenario for IPv6 address There are three possible options in this scenario for IPv6 address
assignment: assignment:
A. The Edge Router interface facing towards the Access Router is A. The Edge Router interface facing towards the Access Router is
statically configured with /64 prefix. The Access Router receives/ statically configured with /64 prefix. The Access Router receives/
configures an /64 prefix on its interface facing towards Edge Router configures an /64 prefix on its interface facing towards Edge Router
through stateless auto-configuration. The network administrator will through stateless auto-configuration. The network administrator will
have to configure the /64 prefixes to the Access Router interface have to configure the /64 prefixes to the Access Router interface
facing towards the customer premises. The WLAN Host/Router connected facing towards the customer premise. The WLAN Host/Router connected
to this interface can automatically configure themselves using to this interface can automatically configure themselves using
stateless auto-configuration with /64 prefix. stateless auto-configuration with /64 prefix.
B. This option uses DHCPv6 [11] for IPv6 prefix assignments to the B. This option uses DHCPv6 [10] for IPv6 prefix assignments to the
WLAN Host/Router. There is no use of DHCP PD or stateless auto- WLAN Host/Router. There is no use of DHCP PD or stateless auto-
configuration in this option. The DHCPv6 server can be located on configuration in this option. The DHCPv6 server can be located on
the Access Router, on the Edge Router or somewhere in the SP network. the Access Router, on the Edge Router or somewhere in the SP network.
In this case depending on where the DHCPv6 server is located, Access In this case depending on where the DHCPv6 server is located, Access
Router or the Edge Router would relay the DHCPv6 requests. Router or the Edge Router would relay the DHCPv6 requests.
C. It can use its link-local address to communicate with the ER. It C. It can use its link-local address to communicate with the ER. It
can also dynamically acquire through stateless autoconfiguration the can also dynamically acquire through stateless auto-configuration the
address for the link between itself and the ER. This step is 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 its
interfaces connecting the WLAN Host/Router on customer site. The interfaces connecting the WLAN Host/Router on customer site. The
WLAN Host/Router connected to these interfaces can automatically WLAN Host/Router connected to these interfaces can automatically
skipping to change at page 63, line 50 skipping to change at page 63, line 49
configuration model and point the clients to a central server for configuration model and point the clients to a central server for
DNS/domain information, proxy configurations and others. Using this DNS/domain information, proxy configurations and others. Using this
model the provider could change prefixes on the fly and the Access model the provider could change prefixes on the fly and the Access
Router would simply pull the newest prefix based on the valid/ Router would simply pull the newest prefix based on the valid/
preferred lifetime. preferred lifetime.
As mentioned before the prefixes used for subscriber links and the As mentioned before the prefixes used for subscriber links and the
ones delegated via DHCP-PD should be planned in a manner that allows ones delegated via DHCP-PD should be planned in a manner that allows
maximum summarization possible at the Edge Router. Other information maximum summarization possible at the Edge Router. Other information
of interest to the host, such as DNS, is provided through stateful of interest to the host, such as DNS, is provided through stateful
[11] and stateless [10] DHCPv6. [10] and stateless [9] 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 generally have limited resources. devices which generally have limited resources.
If the Access Router is owned by an Access Provider, then the Access If the Access Router is owned by an Access Provider, then the Access
Router can have a default route, pointing towards the SP Edge Router. Router can have a default route, pointing towards the SP Edge Router.
The Edge Router runs the IGP used in the SP network such as OSPFv3 or The Edge Router runs the IGP used in the SP network such as OSPFv3 or
skipping to change at page 65, line 10 skipping to change at page 65, line 10
Since the Access Router terminates the PPP sessions initiated by WLAN Since the Access Router terminates the PPP sessions initiated by WLAN
Host/Router, it has to support PPPoE with IPv6. Host/Router, it has to support PPPoE with IPv6.
Figure 9.1.3.1 describes the PTA Model in IPv6 WLAN environment. Figure 9.1.3.1 describes the PTA Model in IPv6 WLAN environment.
Customer | Access Provider | Service Provider Customer | Access Provider | Service Provider
Premise | | Premise | |
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | |Underlying| |Edge | |WLAN | ---- | | | | |Underlying| |Edge |
|Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP |Host/ |-(WLAN)--|AP|-|Access Router |-|Technology|-|Router|=>SP
|Router| ---- | | | | | | | |Network |Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
| |
|---------------------------| +------+ |---------------------------| +------+
PPP |AAA | PPP |AAA |
|Server| |Server|
+------+ +------+
Figure 9.1.3.1 Figure 9.1.3.1
9.1.3.1.1 IPv6 Related Infrastructure Changes 9.1.3.1.1 IPv6 Related Infrastructure Changes
skipping to change at page 66, line 9 skipping to change at page 66, line 9
The PPP sessions initiated by WLAN Host/Router are forwarded over the The PPP sessions initiated by WLAN Host/Router are forwarded over the
L2TPv2 tunnel to the aggregation point in the SP network. The Access L2TPv2 tunnel to the aggregation point in the SP network. The Access
Router must have the capability to support L2TPv2 for IPv6. Router must have the capability to support L2TPv2 for IPv6.
Figure 9.1.3.2 describes the LAA Model in IPv6 WLAN environment Figure 9.1.3.2 describes the LAA Model in IPv6 WLAN environment
Customer | Access Provider | Service Provider Customer | Access Provider | Service Provider
Premise | | Premise | |
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
|WLAN | ---- | | | | |Underlying| |Edge | |WLAN | ---- | | | | |Underlying| |Edge |
|Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP |Host/ |-(WLAN)--|AP|-|Access Router |-|Technology|-|Router|=>SP
|Router| ---- | | | | | | | |Network |Router| ---- | | | | | | | |Network
+------+ +--+ +--------------+ +----------+ +------+ +------+ +--+ +--------------+ +----------+ +------+
| |
|-------------------------------------------------- | |-------------------------------------------------- |
PPP | PPP |
|--------------------- | |--------------------- |
L2TPv2 | L2TPv2 |
+------+ +------+
|AAA | |AAA |
|Server| |Server|
skipping to change at page 68, line 37 skipping to change at page 68, line 37
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.
9.4 IPv6 Security Considerations 9.4 IPv6 Security Considerations
There are limited changes that have to be done for WLAN Host/Router There are limited changes that have to be done for WLAN Host/Router
in order to enhance security. The Privacy extensions [14] for in order to enhance security. The Privacy extensions [13] for auto-
autoconfiguration should be used by the hosts with the same configuration should be used by the hosts with the same consideration
consideration for host traceability as described in section 7.5. for host traceability as described in section 7.5. IPv6 firewall
IPv6 firewall functions should be enabled on the WLAN Host/Router if functions should be enabled on the WLAN Host/Router if present.
present.
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.
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 the authentication system then the level of security would depend on the
particular implementation. User credential should never be sent as particular implementation. User credential should never be sent as
clear text via HTTP. Secure HTTP (HTTPS) should be used between the clear text via HTTP. Secure HTTP (HTTPS) should be used between the
web browser and authentication server. The authentication server web browser and authentication server. The authentication server
could use RADIUS and LDAP services at the back end. could use RADIUS and LDAP services at the back end.
Authentication is an important aspect of securing WLAN networks prior Authentication is an important aspect of securing WLAN networks prior
to implementing Layer 3 security policies. This would help for to implementing Layer 3 security policies. This would help for
example avoid threats to the ND or stateless autoconfiguration example avoid threats to the ND or stateless auto-configuration
processes. 802.1x provides the means to secure the network access processes. 802.1x provides the means to secure the network access
however, the many types of EAP (PEAP, EAP-TLS, EAP-TTLS, EAP-FAST, 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 LEAP) and the capabilities of the hosts to support some of the
features might make it difficult to implement a comprehensive and features might make it difficult to implement a comprehensive and
consistent policy. 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 (Access or The device that is the Layer 3 next hop for the subscribers (Access
Edge Router) should protect the network and the other subscribers or Edge Router) should protect the network and the other subscribers
against attacks by one of the provider customers. For this reason against attacks by one of the provider customers. For this reason
uRPF and ACLs should be used on all interfaces facing subscribers. uRPF and ACLs should be used on all interfaces facing subscribers.
Filtering should be implemented with regard for the operational Filtering should be implemented with regard for the operational
requirements of IPv6 [Security considerations for IPv6]. requirements of IPv6 [Security considerations for IPv6].
Authentication and authorization should be used wherever possible. 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
skipping to change at page 70, line 16 skipping to change at page 70, line 16
This section describes the IPv6 deployment in Power Line This section describes the IPv6 deployment in Power Line
Communications (PLC) Access Networks. There may be other choices, Communications (PLC) Access Networks. There may be other choices,
but it seems that this is the best model to follow. Lessons learnt but it seems that this is the best model to follow. Lessons learnt
from Cable, Ethernet and even WLAN access networks may be applicable from Cable, Ethernet and even WLAN access networks may be applicable
also. also.
Power Line Communications are also often called Broadband Power Line Power Line Communications are also often called Broadband Power Line
(BPL) and some times even Power Line Telecommunications (PLT). (BPL) and some times even Power Line Telecommunications (PLT).
PLC/BPL can be used for providing, with todays technology, up to PLC/BPL can be used for providing, with today's technology, up to
200Mbps (total, upstream+downstream) by means of the power grid. The 200Mbps (total, upstream+downstream) by means of the power grid. The
coverage is often the last half mile (typical distance from the coverage is often the last half mile (typical distance from the
Medium-to-Low Voltage transformer to the customer premise meter), and Medium-to-Low Voltage transformer to the customer premise meter), and
of course, as an in-home network (which is out of the scope of this of course, as an in-home network (which is out of the scope of this
document). document).
The bandwidth in a given PLC/BPL segment is shared among all the The bandwidth in a given PLC/BPL segment is shared among all the
customers connected to that segment (often the customers connected to customers connected to that segment (often the customers connected to
the same medium-to-low voltage transformer). The number of customers the same medium-to-low voltage transformer). The number of customers
can vary depending on different factors, such as distances and even can vary depending on different factors, such as distances and even
countries (from a few customers, just 5-6, up to 100-150). countries (from a few customers, just 5-6, up to 100-150).
PLC/BPL could also be used in the Medium Voltage network (often PLC/BPL could also be used in the Medium Voltage network (often
configured as Metropolitan Area Networks), but this is also out of configured as Metropolitan Area Networks), but this is also out of
the scope of this document, as it will be part of the core network, the scope of this document, as it will be part of the core network,
not the access one. not the access one.
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 10.1 PLC/BPL Access Network Elements
This section describes the different elements commonly used in PLC/ This section describes the different elements commonly used in PLC/
BPL access networks. BPL access networks.
Head End (HE): It is the router that connects the PLC/BPL access Head End (HE): Router that connects the PLC/BPL access network (the
network (the power grid), located at the medium-to-low voltage power grid), located at the medium-to-low voltage transformer, to the
transformer, to the core network. The HE PLC/BPL interface appears core network. The HE PLC/BPL interface appears to each customer as a
to each customer as a single virtual interface, all of them sharing single virtual interface, all of them sharing the same physical
the same physical media. media.
Repeater (RPT): It is the device which may be required in some Repeater (RPT): A device which may be required in some circumstances
circumstances to improve the signal on the PLC/BPL. This may be the to improve the signal on the PLC/BPL. This may be the case if there
case if there are many customers in the same segment or building. are many customers in the same segment or building. It is often a
Often is a bridge, but it could be also a router if for example there bridge, but it could be also a router if for example there is a lot
is a lot of peer-to-peer traffic in a building and due to the master- of peer-to-peer traffic in a building and due to the master-slave
slave nature of the PLC/BPL technology, is required to improve the nature of the PLC/BPL technology, is required to improve the
performance within that segment. For simplicity, in this document, performance within that segment. For simplicity, in this document,
it will be considered that the RPT is always a transparent layer 2 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). 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 Customer Premise Equipment (CPE): Modem (internal to the host),
host), modem/bridge (BCPE), router (RCPE) or any combination among modem/bridge (BCPE), router (RCPE) or any combination among those
those (i.e. modem+bridge/router), located at the customer premise. (i.e. modem+bridge/router), located at the customer premise.
Edge Router (ER) Edge Router (ER)
Figure 10.1 depicts all the network elements indicated above Figure 10.1 depicts all the network elements indicated above
Customer Premises|Network Access Provider|Network Service Provider Customer Premise | Network Access Provider | Network Service Provider
CP NAP NSP CP NAP NSP
+-----+ +------+ +-----+ +------+ +--------+ +-----+ +------+ +-----+ +------+ +--------+
|Hosts|--| RCPE |--| RPT |--------+ HE +---+ Edge | ISP |Hosts|--| RCPE |--| RPT |--------+ Head +---+ Edge | ISP
+-----+ +------+ +-----+ | | | Router +===>Network +-----+ +------+ +-----+ | End | | Router +=>Network
+--+---+ +--------+ +--+---+ +--------+
+-----+ +------+ +-----+ | +-----+ +------+ +-----+ |
|Hosts|--| BCPE |--| RPT |-----------+ |Hosts|--| BCPE |--| RPT |-----------+
+-----+ +------+ +-----+ +-----+ +------+ +-----+
Figure 10.1 Figure 10.1
The logical topology and design of PLC/BPL is very similar to The logical topology and design of PLC/BPL is very similar to
Ethernet Broadband Networks as discussed in Section 8. Ethernet Broadband Networks as discussed in Section 8. IP
connectivity is typically provided in a Point-to-Point model as
described in section 8.2.1
10.2 Deploying IPv6 in IPv4 PLC/BPL 10.2 Deploying IPv6 in IPv4 PLC/BPL
The most simplistic and efficient model, considering the nature of The most simplistic and efficient model, considering the nature of
the PLC/BPL networks, is to see the network as a point-to-point one the PLC/BPL networks, is to see the network as a point-to-point one
to each customer. Even if several customers share the same physical to each customer. Even if several customers share the same physical
media, the traffic is not visible among them because each one uses media, the traffic is not visible among them because each one uses
different channels, which are in addition encrypted by means of 3DES. different channels, which are in addition encrypted by means of 3DES.
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 In order to maintain the deployment concepts and business models
proven and used with existing revenue generating IPv4 services, the proven and used with existing revenue generating IPv4 services, the
IPv6 deployment will match the IPv4 one. Under certain circumstances IPv6 deployment will match the IPv4 one. Under certain circumstances
where new service types or service needs justify it, IPv4 and IPv6 where new service types or service needs justify it, IPv4 and IPv6
network architectures could be different. Both approaches are very network architectures could be different. Both approaches are very
similar to those already described for the Ethernet case. similar to those already described for the Ethernet case.
10.2.1 IPv6 Related Infrastructure Changes 10.2.1 IPv6 Related Infrastructure Changes
In this scenario the RPT is layer 3 unaware, but not the Head End, In this scenario only the RPT is layer 3 unaware, but the other
which should be upgraded to support IPv6. Similarly other devices devices have to be upgraded to dual stack Hosts, RCPE, Head End, and
which have to be upgraded to dual stack: Hosts, RCPE and Edge Router. Edge Router.
10.2.2 Addressing 10.2.2 Addressing
The Hosts or the RCPEs have the HE as their Layer 3 next hop. The Hosts or the RCPEs have the HE as their Layer 3 next hop.
If there is no RCPE, but instead a BCPE all the hosts on the If there is no RCPE, but instead a BCPE all the hosts on the
subscriber site belong to the same /64 subnet that is statically subscriber site belong to the same /64 subnet that is statically
configured on the HE. The hosts can use stateless autoconfiguration configured on the HE. The hosts can use stateless auto-configuration
or stateful DHCPv6 based configuration to acquire an address via the or stateful DHCPv6 based configuration to acquire an address via the
HE. HE.
If a RCPE is present: If a RCPE is present:
A. It is statically configured with an address on the /64 subnet A. It is statically configured with an address on the /64 subnet
between itself and the HE, and with /64 prefixes on the interfaces between itself and the HE, and with /64 prefixes on the interfaces
connecting the hosts on the customer site. This is not a desired connecting the hosts on the customer site. This is not a desired
provisioning method being expensive and difficult to manage. provisioning method being expensive and difficult to manage.
B. It can use its link-local address to communicate with the HE. It B. It can use its link-local address to communicate with the HE. It
can also dynamically acquire through stateless autoconfiguration the can also dynamically acquire through stateless auto-configuration the
address for the link between itself and the HE. This step is address for the link between itself and the HE. This step is
followed by a request via DHCP-PD for a prefix shorter than /64 followed by a request via DHCP-PD for a prefix shorter than /64
(typically /48 [8]) that in turn is divided in /64s and assigned to (typically /48 [7]) that in turn is divided in /64s and assigned to
its interfaces connecting the hosts on the customer site. This its interfaces connecting the hosts on the customer site. This
should be the preferred provisioning method, being cheaper and easier should be the preferred provisioning method, being cheaper and easier
to manage. to manage.
The Edge Router needs to have a prefix considering that each customer The Edge Router needs to have a prefix considering that each customer
in general will receive a /48 prefix, and that each HE will in general will receive a /48 prefix, and that each HE will
accommodate customers. Consequently each HE will require n x /48 accommodate customers. Consequently each HE will require n x /48
prefixes. prefixes.
It could be possible to use a kind of Hierarchical Prefix Delegation It could be possible to use a kind of Hierarchical Prefix Delegation
to automatically provision the required prefixes and fully auto- to automatically provision the required prefixes and fully auto-
configure the HEs, and consequently reduce the network setup, configure the HEs, and consequently reduce the network setup,
operation and maintenance cost. operation and maintenance cost.
The prefixes used for subscriber links and the ones delegated via The prefixes used for subscriber links and the ones delegated via
DHCP-PD should be planned in a manner that allows as much DHCP-PD should be planned in a manner that allows as much
summarization as possible at the Edge Router. summarization as possible at the Edge Router.
Other information of interest to the host, such as DNS, is provided Other information of interest to the host, such as DNS, is provided
through stateful [11] and stateless [10] DHCPv6. through stateful [10] and stateless [9] DHCPv6.
10.2.3 Routing 10.2.3 Routing
If no routers are used on the custmer premises, the HE can simply be If no routers are used on the customer premise, the HE can simply be
configured with a default route that points to the Edge Router. If a configured with a default route that points to the Edge Router. If a
router is used on the customer premises (RCPE) then the HE will run router is used on the customer premise (RCPE) then the HE could also
an IGP to the ER such as OSPFv3, IS-IS or even RIPng. The connected run an IGP to the ER such as OSPFv3, IS-IS or even RIPng. The
prefixes should be redistributed. If DHCP-PD is used, with every connected prefixes should be redistributed. If DHCP-PD is used, with
delegated prefix a static route is installed by the HE. For this every delegated prefix a static route is installed by the HE. For
reason the static routes must also be redistributed. Prefix this reason the static routes must also be redistributed. Prefix
summarization should be done at the HE. summarization should be done at the HE.
The RCPE requires only a default route pointing to the HE. No The RCPE requires only a default route pointing to the HE. No
routing protocols are needed on these devices which generally have routing protocols are needed on these devices which generally have
limited resources. limited resources.
The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS. The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS.
The connected prefixes have to be redistributed as well as any RP The connected prefixes have to be redistributed as well as any RP
other than the ones used on the ER that might be used between the HE other than the ones used on the ER that might be used between the HE
and the ER. and the ER.
skipping to change at page 74, line 7 skipping to change at page 73, line 44
that may be introduced by electrical noise, towards which the PLC/BPL that may be introduced by electrical noise, towards which the PLC/BPL
network will automatically self-adapt. network will automatically self-adapt.
10.5 IPv6 Security Considerations 10.5 IPv6 Security Considerations
There are no differences in terms of security considerations if There are no differences in terms of security considerations if
compared with the Ethernet case. compared with the Ethernet case.
10.6 IPv6 Network Management 10.6 IPv6 Network Management
There are no differences in terms of network management if compared Conceptually network management in PLC Networks should be similar to
with the already described Ethernet case. Broadband Ethernet Networks as described in section 8.6. Although
there could be a need to develop some PLC specific MIBs.
11. Gap Analysis 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 in highlighted in this document, aspects that require additional work in
order to facilitate native deployments as summarized below: order to facilitate native deployments as summarized below:
A. As mentioned in section 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
cable networks. Additional classifiers need to be added to the cable networks. Additional classifiers need to be added to the
DOCSIS specification in order to classify IPv6 traffic at the CM and DOCSIS specification in order to classify IPv6 traffic at the CM and
CMTS in order to provide QoS. These issues are addressed in a recent CMTS in order to provide QoS. These issues are addressed in a recent
proposal made to Cable Labs for DOCSIS 3.0 [31] proposal made to Cable Labs for DOCSIS 3.0 [31].
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 (CPE's layer 3 next hop). If
relayed, the Edge Router does not have a mechanism to learn the the DHCP-PD messages are relayed, the Edge Router does not have a
assigned prefixes and thus install the proper routes to make that mechanism to learn the assigned prefixes and thus install the proper
prefix reachable. Work needs to be done to address this issue, one routes to make that prefix reachable. Work needs to be done to
idea being to provide the Edge Router with a snooping mechanism. The address this issue, one idea being to provide the Edge Router with a
uplink to the ISP network is configured with a /64 prefix as well. snooping mechanism. The uplink to the ISP network is configured with
a /64 prefix as well.
C. Section 7 stated that current RBE based IPv4 deployment might not 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 gives the SP the opportunity to separate the users on different
subnets. The differences between IPv4 RBE and IPv6 RBE were subnets. The differences between IPv4 RBE and IPv6 RBE were
highlighted in section 7. If however, support and reason is found highlighted in section 7. If however, support and reason is found
for a deployment similar to IPv4 RBE, then the environment becomes for a deployment similar to IPv4 RBE, then the environment becomes
NBMA and the new 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
skipping to change at page 75, line 10 skipping to change at page 75, line 7
E. Sections 7 and 8 pointed out the limitations (previously E. Sections 7 and 8 pointed out the limitations (previously
documented in [32]) in deploying inter-domain ASM however, SSM based documented in [32]) in deploying inter-domain ASM however, SSM based
services seem more likely at this time. For such SSM based services services seem more likely at this time. For such SSM based services
of content delivery (video or Audio), mechanisms are needed to of content delivery (video or Audio), mechanisms are needed to
facilitate the billing and management of listeners. The currently facilitate the billing and management of listeners. The currently
available feature of MLD AAA is suggested however, other methods or available feature of MLD AAA is suggested however, other methods or
mechanisms might be developed and proposed. mechanisms might be developed and proposed.
F. In relation to section 9, concerns have been raised related to F. In relation to section 9, concerns have been raised related to
running IPv6 multicast over WLAN links. Potentially these are same running IPv6 multicast over WLAN links. Potentially these are same
kind of issues when running any Layer3 protocol over a WLAN link that kind of issues when running any Layer 3 protocol over a WLAN link
has a high loss-to-signal ratio, certain frames that are multicast that has a high loss-to-signal ratio, certain frames that are
based are dropped when settings are not adjusted properly. For multicast based are dropped when settings are not adjusted properly.
instance this behavior is similar to IGMP host membership report, For instance this behavior is similar to IGMP host membership report,
when done on a WLAN link with high loss-to-signal ratio and high when done on a WLAN link with high loss-to-signal ratio and high
interference. This problem is inherited to WLAN that can impact both interference. This problem is inherited to WLAN that can impact both
IPv4 and IPv6 multicast packets and not specific to IPv6 multicast. IPv4 and IPv6 multicast packets and not specific to IPv6 multicast.
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 easily provide some form of host security. ISPs can track relatively easily
the prefixes assigned to subscribers. If however the ISPs are the prefixes assigned to subscribers. If however the ISPs are
required by regulations to track their users at host address level, required by regulations to track their users at host address level,
the Privacy Extensions [14] can be implemented only in parallel with the Privacy Extensions [13] 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
hosts. Mechanisms should be defined to implement this aspect of user hosts. Mechanisms should be defined to implement this aspect of user
management. management.
H. Tunnels are an effective way to avoid deployment dependencies on H. Tunnels are an effective way to avoid deployment dependencies on
the IPv6 support on platforms that are out of the SP control (GWRs or the IPv6 support on platforms that are out of the SP control (GWRs or
CPEs) or over technologies that did not standardize the IPv6 support CPEs) or over technologies that did not standardize the IPv6 support
yet (cable). They can be used in the following ways: 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
skipping to change at page 75, line 47 skipping to change at page 75, line 44
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 fixed,
globally routable prefixes to the links connecting each subscriber. 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, such as automatic mapping
of VLAN IDs/PVCs (or other customer-specific information) to IPv6
prefixes.
J. New deployment models are emerging for the Layer 2 portion of the J. New deployment models are emerging for the Layer 2 portion of the
NAP where individual VLANs are not dedicated to each subscriber. NAP where individual VLANs are not dedicated to each subscriber.
This approach allows Layer 2 switches to aggregate more then 4096 This approach allows Layer 2 switches to aggregate more then 4096
users. MAC Forced Forwarding [MFF] is an example of such an users. MAC Forced Forwarding [MFF] is an example of such an
implementation where a broadcast domain is turned into a NBMA like implementation where a broadcast domain is turned into a NBMA like
environment by forwarding the frames based on both Source and environment by forwarding the frames based on both Source and
Destination MAC addresses. Since these models are being adopted by Destination MAC addresses. Since these models are being adopted by
the field, the implications of deploying IPv6 in such environments the field, the implications of deploying IPv6 in such environments
need to be further investigated. need to be further investigated.
K. The deployment of IPv6 in continuously evolving access service
models raises some issues that may need further investigation.
Examples of such topics are [37]:
i. Network Service Selection & Authentication(NSSA) mechanisms
working in association with stateless auto-configuration. As an
example, NSSA relevant information such as ISP preference, passwords
or profile ID can be sent by hosts with the RS.
ii. Adding additional information in Router Advertisements to help
access nodes with prefix selection in multi-ISP/multi-homed
environment.
The outcome of solutions to some of these topics ranges from making a The outcome of solutions to some of these topics ranges from making a
media access capable of supporting native IPv6 (cable) to improving media access capable of supporting native IPv6 (cable) to improving
operational aspects of native IPv6 deployments. operational aspects of native IPv6 deployments.
12. IANA Considerations 12. IANA Considerations
This document requests no action by IANA. This document requests no action by IANA.
13. Security Considerations 13. Security Considerations
Please refer to the individual "IPv6 Security Considerations" Please refer to the individual "IPv6 Security Considerations"
technology sections for details. technology sections for details.
14. References 14. Acknowledgements
14.1 Normative References We would like to thank Brian Carpenter, Patrick Grossetete, Toerless
Eckert, Madhu Sudan, Shannon McFarland and Benoit Lourdelet, Fred
Baker for their valuable comments. The authors would like to
acknowledge the structure and information guidance provided by the
work of Mickels et al on Transition Scenarios for ISP Networks.
15. References
15.1 Normative References
[1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
Lear, "Address Allocation for Private Internets", BCP 5, Lear, "Address Allocation for Private Internets", BCP 5,
RFC 1918, February 1996. RFC 1918, February 1996.
[2] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 [2] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001. Tunnel Broker", RFC 3053, January 2001.
[3] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via [3] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001. IPv4 Clouds", RFC 3056, February 2001.
[4] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 [4] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998. Specification", RFC 2473, December 1998.
[5] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 [5] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Hosts and Routers", RFC 2893, August 2000.
[6] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999. Domains without Explicit Tunnels", RFC 2529, March 1999.
[7] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, [6] Huitema, C., Austein, R., Satapati, S., and R. van der Pol,
"Evaluation of IPv6 Transition Mechanisms for Unmanaged "Evaluation of IPv6 Transition Mechanisms for Unmanaged
Networks", RFC 3904, September 2004. Networks", RFC 3904, September 2004.
[8] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address [7] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", RFC 3177, September 2001. Allocations to Sites", RFC 3177, September 2001.
[9] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) [8] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003. Addressing Architecture", RFC 3513, April 2003.
[10] Droms, R., "Stateless Dynamic Host Configuration Protocol [9] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
[11] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[12] Thomson, S. and T. Narten, "IPv6 Stateless Address [11] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[13] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host [12] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633, Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[14] Narten, T. and R. Draves, "Privacy Extensions for Stateless [13] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001. Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[15] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and [14] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and
R. Wheeler, "A Method for Transmitting PPP Over Ethernet R. Wheeler, "A Method for Transmitting PPP Over Ethernet
(PPPoE)", RFC 2516, February 1999. (PPPoE)", RFC 2516, February 1999.
[16] Gross, G., Kaycee, M., Lin, A., Malis, A., and J. Stephens, [15] Gross, G., Kaycee, M., Lin, A., Malis, A., and J. Stephens,
"PPP Over AAL5", RFC 2364, July 1998. "PPP Over AAL5", RFC 2364, July 1998.
[17] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, [16] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998. December 1998.
[18] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [17] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[19] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", [18] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8",
RFC 2770, February 2000. RFC 2770, February 2000.
[20] St. Johns, M., "DOCSIS Cable Device MIB Cable Device Management [19] St. Johns, M., "DOCSIS Cable Device MIB Cable Device Management
Information Base for DOCSIS compliant Cable Modems and Cable Information Base for DOCSIS compliant Cable Modems and Cable
Modem Termination Systems", RFC 2669, August 1999. Modem Termination Systems", RFC 2669, August 1999.
[21] Droms, R., "DNS Configuration options for Dynamic Host [20] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003. December 2003.
[22] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol [21] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol
(MSDP)", RFC 3618, October 2003. (MSDP)", RFC 3618, October 2003.
[23] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [22] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[24] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [23] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[25] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, [24] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola,
"Scenarios and Analysis for Introducing IPv6 into ISP "Scenarios and Analysis for Introducing IPv6 into ISP
Networks", RFC 4029, March 2005. Networks", RFC 4029, March 2005.
14.2 Informative References 15.2 Informative References
[26] Shirasaki, Y., Miyakawa, S., and A. Takenouchi, "A Model of [25] Shirasaki, Y., Miyakawa, S., and A. Takenouchi, "A Model of
IPv6/IPv4 Dual Stack Internet Access IPv6/IPv4 Dual Stack Internet Access
Service(draft-shirasaki-dualstack-service-04.txt)", April 2004. Service(draft-shirasaki-dualstack-service-04.txt)", April 2004.
[27] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, [26] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
"Connecting IPv6 Islands across IPv4 Clouds with "Connecting IPv6 Islands across IPv4 Clouds with
BGP(draft-ooms-v6ops-bgp-tunnel-04.txt)", October 2004. BGP(draft-ooms-v6ops-bgp-tunnel-04.txt)", October 2004.
[28] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- [27] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-
Site Automatic Tunnel Addressing Protocol Site Automatic Tunnel Addressing Protocol
(ISATAP)(draft-ietf-ngtrans-isatap-12.txt)", January 2003. (ISATAP)(draft-ietf-ngtrans-isatap-12.txt)", January 2003.
[29] Palet, J., Diaz, M., and P. Savola, "Analysis of IPv6 Tunnel [28] Palet, J., Diaz, M., and P. Savola, "Analysis of IPv6 Tunnel
End-point Discovery End-point Discovery
Mechanisms(draft-palet-v6ops-tun-auto-disc-01.txt)", June 2004. Mechanisms(draft-palet-v6ops-tun-auto-disc-03.txt)",
January 2005.
[29] Palet, J., Olvera, C., and D. Fernandez, "Forwarding Protocol
41 in NAT Boxes(draft-palet-v6ops-proto41-nat-03.txt)",
October 2003.
[30] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for [30] Nordmark, E. and R. Gilligan, "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.
[31] Cisco, Systems., "DOCSIS 3.0 Proposal", April 2005. [31] Cisco, Systems., "DOCSIS 3.0 Proposal", April 2005.
[32] Savola, P., "IPv6 Multicast Deployment [32] Savola, P., "IPv6 Multicast Deployment
Issues(draft-mboned-ipv6-multicast-issues.txt)", April 2004. Issues(draft-mboned-ipv6-multicast-issues.txt)", April 2004.
skipping to change at page 79, line 8 skipping to change at page 79, line 29
Mechanism for PIM(draft-ietf-pim-sm-bsr-04.txt)", January 2005. Mechanism for PIM(draft-ietf-pim-sm-bsr-04.txt)", January 2005.
[35] Palet, J., Nielsent, K., Parent, F., Durand, A., [35] Palet, J., Nielsent, K., Parent, F., Durand, A.,
Suryanarayanan, R., and P. Savola, "Goals for Tunneling Suryanarayanan, R., and P. Savola, "Goals for Tunneling
Configuration(draft-palet-v6tc-goals-tunneling-00.txt)", Configuration(draft-palet-v6tc-goals-tunneling-00.txt)",
August 2005. August 2005.
[36] Convery, S. and D. Miller, "IPv6 and IPv4 Threat Comparison and [36] Convery, S. and D. Miller, "IPv6 and IPv4 Threat Comparison and
Best-Practice Evaluation", March 2004. Best-Practice Evaluation", March 2004.
[37] Wen, H., Zhu, X., Jiang, Y., and R. Yan, "The deployment of
IPv6 stateless auto-configuration in access network",
June 2005.
Authors' Addresses Authors' Addresses
Salman Asadullah Salman Asadullah
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: 408 526 8982 Phone: 408 526 8982
Email: sasad@cisco.com Email: sasad@cisco.com
skipping to change at page 79, line 37 skipping to change at page 80, line 22
Ciprian Popoviciu Ciprian Popoviciu
Cisco Systems Cisco Systems
7025-6 Kit Creek Road 7025-6 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Phone: 919 392 3723 Phone: 919 392 3723
Email: cpopovic@cisco.com Email: cpopovic@cisco.com
Pekka Savola
CSC - Scientific Computing Ltd.
Espoo
Finland
Email: psavola@funet.fi
Jordi Palet Martinez Jordi Palet Martinez
Consulintel Consulintel
San Jose Artesano, 1 San Jose Artesano, 1
Alcobendas, Madrid E-28108 Alcobendas, Madrid E-28108
Spain Spain
Phone: +34 91 151 81 99 Phone: +34 91 151 81 99
Email: jordi.palet@consulintel.es Email: jordi.palet@consulintel.es
Intellectual Property Statement Intellectual Property Statement
 End of changes. 

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