IPv6 Working Group                                     Salman Asadullah
INTERNET DRAFT                                              Adeel Ahmed
February
April 2005                                            Ciprian Popoviciu
                                                          Cisco Systems
                                                            Jordi Palet
                                                            Consulintel

       ISP IPv6 Deployment Scenarios in Broadband Access Networks
         <draft-ietf-v6ops-bb-deployment-scenarios-00.txt>
           <draft-ietf-v6ops-bb-deployment-scenarios-01.txt>

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC3667. By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 27, 2005.

Abstract

   This document provides detailed description of IPv6 deployment and
   integration methods and scenarios in today's Service Provider (SP)
   Broadband (BB) networks in coexistence with deployed IPv4 services.

   Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies
   that are currently deployed, and discussed in this document. The
   emerging PLC/BPL access technology is also discussed for completion
   purposes. In this document we will discuss main components of IPv6
   BB networks and their differences from IPv4 BB networks and how IPv6
   is deployed and integrated in each of these BB technologies using
   tunneling mechanisms and native IPv6.

Table of Contents:
    1.  Introduction..................................................3
    2.  IPv6 Based BB Services........................................3 Services........................................4
    3.  Scope of the Document.........................................4 Document.........................................5
    4.  Core Backbone Network.........................................5
        4.1 Layer 2 Access Provider....................................5 Provider...................................6
        4.2 Layer3 Access Provider....................................6
    5.  Tunneling Options.............................................7
        5.1 Access over Tunnels-customers with public IPv4 address....7
        5.2 Access over Tunnels-customers with private IPv4 address...7 address...8
        5.3 Transition a portion of the IPv4 infrastructure...........8
    6.  Broadband Cable Networks .....................................9
        6.1 Broadband Cable Network Elements .........................9
        6.2 Deploying IPv6 in Cable Networks.........................10
            6.2.1  Bridged CMTS Network .............................11
            6.2.2  Routed CMTS Network ..............................13 ..............................14
        6.3 IPv6 Multicast ..........................................22
        6.4 IPv6 QoS ................................................22
        6.5 IPv6 Security Considerations.............................23
        6.6 IPv6 Network Management .................................23 .................................24
            6.6.1  Using IPv6 for Management in Cable Networks ......24
            6.6.2  Updates to MIBs/Standards to support IPv6 ........25
    7.  Broadband DSL Networks.......................................24 Networks.......................................25
        7.1 DSL Network Elements ....................................24 ....................................25
        7.2 Deploying IPv6 in IPv4 DSL Networks......................25 Networks......................26
            7.2.1  Point-to-Point Model..............................26 Model..............................27
            7.2.2  PPP Terminated Aggregation (PTA) Model............27 Model............29
            7.2.3  L2TP Access Aggregation (LAA) Model...............30 Model...............31
            7.2.4  Hybrid Model for IPv4 and IPv6 Service ...........33 ...........34
        7.3 IPv6 Multicast...........................................35 Multicast...........................................36
            7.3.1 ASM Based Deployments..............................35 Deployments..............................36
            7.3.1 SSM Based Deployments..............................36 Deployments..............................37
        7.4 IPv6 QoS.................................................37 QoS.................................................38
        7.5 IPv6 Security Considerations.............................37 Considerations.............................38
        7.6 IPv6 Network Management..................................38 Management..................................39
    8.  Broadband Ethernet Networks..................................38 Networks..................................39
        8.1  Ethernet Access Network Elements .......................38 .......................39
        8.2  Deploying IPv6 in IPv4 BB Ethernet Networks.............39 Networks.............40
             8.2.1  Point-to-Point Model.............................40 Model.............................41
             8.2.2  PPP Terminated Aggregation (PTA) Model...........41 Model...........43
             8.2.3  L2TP Access Aggregation (LAA) Model..............43 Model..............45
             8.2.4  Hybrid Model for IPv4 and IPv6 Service...........45 Service...........46
        8.3  IPv6 Multicast..........................................47
        8.4  IPv6 QoS................................................48 QoS................................................49
        8.5  IPv6 Security Considerations............................48 Considerations............................50
        8.6  IPv6 Network Management.................................49 Management.................................50
     9. Broadband Wireless LAN Networks..............................49 Networks..............................51
        9.1  WLAN Deployment Scenarios...............................49 Scenarios...............................51
             9.1.1  Layer 2 Switch Between AP and SP Edge Router......51 Router.....52
             9.1.2  Access Router Between AP and SP Edge Router......53 Router......54
             9.1.3  PPP Based Model..................................55 Model..................................56
        9.2  IPv6 Multicast..........................................57 Multicast..........................................58
        9.3  IPv6 QoS................................................58 QoS................................................60
        9.4  IPv6 Security Considerations............................59 Considerations............................60
        9.5  IPv6 Network Management.................................59
      10.Gap Analysis.................................................60
      11.Contributors.................................................62
      12.Acknowledgments..............................................62
      13.References...................................................62 Management.................................61
     10. Broadband Power Line Communications (PLC)...................61
        10.1 PLC/BPL Access Network Elements.........................62
        10.2 Deploying IPv6 in IPv4 PLC/BPL..........................63
             10.2.1 IPv6 Related Infrastructure Changes..............63
             10.2.2 Addressing.......................................63
             10.2.3 Routing..........................................64
        10.3 IPv6 Multicast..........................................65
        10.4 IPv6 QoS................................................65
        10.5 IPv6 Security Considerations............................65
        10.6 IPv6 Network Management.................................65
     11. Gap Analysis................................................65
     12. Contributors................................................67
     13. Acknowledgments.............................................67
     14. References..................................................67
     Authors Addresses...............................................64 Addresses...............................................70

1. Introduction

   With the exponential growth of the Internet and increasing number of
   end users, SPs are looking for new ways to evolve their current
   network architecture to meet the needs of Internet ready appliances,
   new applications and services. IPv6 is designed to enable SPs to
   meet these challenges and provide new services to their customers.

   As the number of devices per BB user increase exponentially
   worldwide, Cable, DSL, Ethernet to the Home, Wireless Wireless, PLC/BPL and
   other always-on access technologies can benefit from the huge
   address range [RFC3513] of IPv6. Other benefits of IPv6 include the
   capability to enhance end-to-end security, mobile communications,
   and ease system management burdens. Some examples include
   peer-to-peer communication without NAT traversal problems, being
   able to access securely devices at home from work, enhanced IP
   Mobility [RFC3775] and so on.

   Therefore SPs are aggressively evaluating the capabilities of IPv6
   to meet these needs. Some countries have taken a lead role in this
   race and moved from testing and evaluation to real deployments of
   IPv6 in the BB arena. Japan is a prime example along with other
   countries that are looking at moving towards large scale production
   deployments of IPv6.

   The SPs are deploying tunneling mechanisms to transport IPv6 over
   their existing IPv4 networks as a start as well as deploying native
   IPv6 where possible. Deployment of tunneling solutions is simpler,
   easier and more economical to start the IPv6 services, as they
   require minimal investments and network infrastructure changes in
   current SP model. Depending on customer needs and requirements a
   native IPv6 deployment option might be more scalable and provide
   required service performance.

2. IPv6 Based BB Services

   At this point IPv6 based services are seen as a differentiator that
   enables SPs to take advantage of the large IPv6 address space to
   the extent that subscribers get up to fixed /64 /48 prefixes versus the
   single, temporary IPv4 addresses. Such resources allow the SPs to
   better position themselves against the competition. The IPv6
   deployments can be seen as a driver for lower service support costs
   by eliminating NAT with its negative impact on applications and its
   complex behavior. Another reason of IPv6 being very popular in some
   countries is might be the government driven financial incentives and
   favorable legislation toward towards the ISPs IPs who are deploying IPv6.

   NTT East, Japan started a commercial dual-stack (devices capable of
   forwarding IPv4 and IPv6 packets) IPv6 unicast service option early
   this year for its ADSL and FTTH subscribers, under the name of
   FLETS.Net [Dual Stack Access].

   For these users the IPv6 addresses are dedicated (/64 per user) and
   are used when needed.  However, this IPv6 service is available only
   to the NTT-East ADSL and FTTH subscribers who are part of FLETS.NET
   network and at this point does not provide connectivity to the
   IPv6 Internet.

   The list of BB SPs that have deployed IPv6 services contains names
   such as: SpaceNet in Germany, Dolphin in Switzerland, Nerim in
   France and XS4ALL in The Netherlands.

   Some ISPs that are currently providing IPv4 based Multicast and
   VoIP services are evaluating IPv6 to take advantage of the huge
   address space and other useful features. The Multicast services
   consist of video and audio streaming of several programs (streams).
   The content provider will have certain content (which is of user
   interest) and they would send these multicast streams to BB
   subscribers. Today, when done through IPv4, there is generally a
   single device directly attached to the CPE that receives the
   Multicast stream. By moving to IPv6, ISP should be capable to
   provide multiple streams to multiple devices on the customer site.

   For instance in Japan, Cable TV and dish services are not very
   popular,  the users expect everything through the broadcasted, free
   programs (traditional TV). In case of BB users however, they can get
   some  extra content through the SP, which is very reasonably priced
   for 20 Mbps or 10/100 Mbps of bandwidth. Users sign up with a
   content provider that is multicasting several channels of video and
   audio. A subscriber would join the multicast group of interest
   (after authentication) and will start receiving the stream(s). An
   example of a video stream could be Disney movies and an example of
   an audio stream could be Karaoke (part of same *,G group). Similar
   to Cable TV, where customers sign up and pay for single programs or
   packages of programs.

   SPs are also offering IPv6 services over wireless links using 802.11
   compliant WiFi Hot Spots. This enables users to take notebook PCs and
   PDAs (Windows 2003 supports IPv6 capable Internet Explorer and Media
   Player 9) along with them and connect to the Internet from various
   locations without the restriction of staying indoors.

3. Scope of the Document

   The focus of this document is to present the options available in
   deploying IPv6 services in the access portion of a BB Service
   Provider network namely Cable/HFC, BB Ethernet, xDSL xDSL, WLAN and WLAN.
   PLC/BPL.

   This document briefly discusses the other elements of a provider
   network as well. It provides different viable IPv6 deployment and
   integration techniques and models for each of the above mentioned BB
   technologies separately. The example list is not exhaustive but it
   tries to be representative.

   This document analyzes, how all the important parts of current IPv4
   based Cable/HFC, BB Ethernet, xDSL and xDSL, WLAN and PLC/BPL networks will
   behave when IPv6 is integrated and deployed.

   The following important pieces are discussed:

   A. Available tunneling options
   B. Devices that would require to be upgraded to support IPv6
   C. Available IPv6 address assignment techniques and their use
   D. Possible IPv6 Routing options and their use
   E. IPv6 unicast and multicast packet transmission
   F. Required IPv6 QoS parameters
   G. Required IPv6 Security parameters
   H. Required IPv6 Network Management parameters

   It is important to note that the addressing rules provided
   throughout this document represent an example that follows the
   current assignment policies and recommendations of the registries.
   They can be however adapted to the network and business model needs
   of the ISPs.

   The scope of the document is to advise on the ways of upgrading
   an existing infrastructure to support IPv6 services. The
   recommendation to upgrade a device to dual-stack does not stop an
   SP from adding a new device to its network to perform the neccessary
   IPv6 functions discussed. The costs involved could be offset by
   lower impact on the existing IPv4 services.

4. Core/Backbone Network

   This section intends to briefly discuss the some important elements
   of a provider network tied to the deployment of IPv6. A more
   detailed description of the core network is provided in other
   documents [ISP Networks IPv6 Scenarios].

   There are two networks identified in the Broadband deployments:

   A. Access Provider Network: This network provides the broadband
   access and aggregates the subscribers. The subscriber traffic is
   handed over to the Service Provider at Layer 2 or 3.
   B. Service Provider Network: This network provides Intranet and
   Internet IP connectivity for the subscribers.

   The Service Provider network structure beyond the Edge routers that
   interface with the Access provider is beyond the scope of this
   document.

4.1 Layer 2 Access Provider Network

   The Access Provider can deploy a Layer 2 network and perform no
   routing of the subscriber traffic to the SP. The devices
   that support each specific access technology are aggregated into a
   highly redundant, resilient and scalable layer two core. The network
   core can involve various technologies such as Ethernet, ATM etc.
   The Service Provider Edge Router connects to the Access Provider
   core.

   In this type of a network the impact of deploying IPv6 is minimal.
   The network is transparent to the Layer 3 protocol. The only possible
   changes would come with the intent of filtering and monitoring IPv6
   traffic based on layer 2 information such as IPv6 Ether Type Protocol
   ID (0x86DD) or IPv6 multicast specific MAC addresses
   (3333.xxxx.xxxx).

4.2 Layer3 Access Provider Network

   The Access Provider can choose to terminate the Layer 2 domain and
   route the IP traffic to the Service Provider network. Access Routers
   are used to aggregate the subscriber traffic and route it over a
   Layer3 core to the SP Edge Routers. In this case the impact of the
   IPv6 deployment is significant.

   The case studies in this document only present the significant
   network elements of such a network: Customer Premises Equipment,
   Access Router and Edge Router. In real networks the link between the
   Access Router and the Edge Router involves other routers that are
   part of the aggregation and the core layer of the Access Provider
   network.

   The Access Provider can forward the IPv6 traffic through its layer3
   core in three possible ways:

   A. IPv6 Tunneling: As a temporary solution, the Access Providers can
   choose to use a tunneling mechanism to forward the subscriber IPv6
   traffic to the Service Provider Edge Router. This approach has the
   least impact on the Access Provider network however, as the number of
   users increase and the amount of IPv6 traffic grows, the ISP will
   have to evolve to one of the scenarios listed below.

   B. Native IPv6 Deployment: The Access Provider routers are upgraded
   to support IPv6 and can become dual-stack. In a dual-stack network
   an IPv6 IGP such as OSPFv3 or IS-IS is enabled, usually mapping enabled. RFC4029 discusses the
   IGP deployed for IPv4. The most important thing to remember in this
   case is that the device resources are now shared between IPv4 and
   IPv6 processes. This problem could be eliminated selection options with the use of
   ISIS-MT (multi-topology) where a single database and SPF is used for
   IPv4 their benefits and IPv6. drawbacks.

   C. MPLS 6PE Deployment [6PE]: If the Access Provider is running MPLS
   in its IPv4 core it could use 6PE to forward IPv6 traffic over its. it.
   In this case only a subset of routers close to the edge of the
   network need to be IPv6 aware. With this approach BGP becomes
   important in order to support 6PE.

   The 6PE approach has the advantage of having minimal impact on the
   Access Provider network. Fewer devices need to be upgraded and
   configured while the MPLS core continues to switch the traffic
   un-aware of the fact that it transports both IPv4 and IPv6 traffic.
   6PE should be leveraged only if MPLS is already deployed in the
   network. At the time of writing this document, a major disadvantage
   of the 6PE solution is the fact that it does not support multicast
   IPv6 traffic.

   The native approach has the advantage of supporting IPv6
   multicast traffic but it may imply a significant impact on the IPv4
   operational network from software, configuration and possibly
   hardware upgrade perspective.

   More detailed Core Network deployment recommendations are discussed
   in other documents [ISP Networks IPv6 Scenarios]. The handling of
   IPv6 traffic in the Core of the Access Provider Network will not be
   discussed for the remainder of this document.

5. Tunneling Overview

   Service Providers might not be able to deploy native IPv6 today due
   to the cost associated with HW and SW upgrades, the infrastructure
   changes needed to their current network and the current demand for
   the service. For these reasons, some SPs might choose tunneling
   based transition mechanisms to start an IPv6 service offering and
   move to native IPv6 deployment at a later time.

   Several tunneling mechanisms were developed specifically
   to transport IPv6 over existing IPv4 infrastructures. Several of
   them have been standardized and their use depends on the existing SP
   IPv4 network and the structure of the IPv6 service. The
   requirements for the most appropriate mechanisms are described in
   [Assisted Tunneling] and [ZeroConf] [v6tc] with more updates to follow.
   Deploying IPv6 using tunneling techniques can imply as little
   changes to the network as upgrading SW on tunnel end points. points (TEP).
   A Service Provider could use tunneling to deploy IPv6 in the
   following scenarios:

5.1 Access over Tunnels-customers with Public IPv4 Address

   If the customer is a residential user, it can initiate the tunnel
   directly from the IPv6 capable host to a tunnel termination router
   located in the NAP or ISP network. The tunnel type used should be
   decided by the SP but it should take into consideration its
   availability on commonly used software running on the host machine.
   Out of the many tunneling mechanisms developed [RFC3053, RFC3056,
   RFC2473, ISATAP, RFC2893, RFC2529] some are more popular than the
   others.

   If the end customer has a GWR installed, then it could be used to
   originate the tunnel and thus offer native IPv6 access to multiple
   hosts on the customer network. In this case the GWR would need to be
   upgraded to dual-stack in order to support IPv6. The GWR can be owned
   by the customer or by the SP.

5.2 Access over Tunnels-Customers with Private IPv4 Address

   If the end customer receives a private IPv4 address and its hosts
   need needs to go through
   initiate a tunnel through NAT, tunneling techniques like 6to4 will not work
   since they rely on Public IPv4 address. In this case the end user
   might have to use tunnels that can operate through NATs (such as
   Teredo tunnel [OPS]).

   The customer has the option to initiate the tunnel from the device
   (GWR) that performs the NAT functionality, similar to the GWR
   scenario discussed in section 5.1. This will imply HW replacement or
   SW upgrade and a native IPv6 environment behind the GWR.

   It is important to note that the customers of a Service Provider can
   choose to establish tunnels to publicly available and free tunnel
   services. Even though the quality of such services might not be high,
   they provide free IPv6 access. In designing their IPv6 services, the
   SPs should take into considerations such options available to their
   potential customers. The IPv6 deployment should support services
   (like multicast, VoIPv6 etc) and a level of quality that would make
   the access through the SP worthwhile to potential subscribers.

   It is also worth observing that initiating an IPv6 tunnel over IPv4
   through already established IPv4 IPsec sessions would provide a
   certain level of security to the IPv6 traffic [Tunnel through IPsec].

5.3 Transition a Portion of the IPv4 Infrastructure

   Tunnels can be used to transport the IPv6 traffic across a defined
   segment of the network. As an example, the customer might connect
   natively to the Network Access Provider and a tunnel is used to
   transit the traffic over IPv4 to the ISP. In this case the tunnel
   choice depends on its capabilities (for example, whether it supports
   multicast or not), routing protocols used (GRE is the only tunnel
   type which (there are several types
   that can transport layer 2 messages such as well), GRE, L2TPv3 or
   Pseudowire), manage-ability and scalability (dynamic versus static
   tunnels).

   This scenario implies that the access portion of the network has been
   upgraded to support dual stack so the savings provided by tunneling
   in this scenario are very small compared with the previous two.
   Depending on the number of sites requiring the service and
   considering the expenses required to manage the tunnels (some tunnels
   are static while others are dynamic [Dynamic Tunnel]) in this case,
   the SPs might find the native approach worth the additional
   investments.

   In all the scenarios listed above the tunnel selection process should
   consider the IPv6 multicast forwarding capabilities if such service
   is planned. As an example, 6to4 tunnels do not support IPv6
   multicast traffic.

   The operation, capabilities and deployment of various tunnel types
   has been discussed extensively in the documents referenced earlier as
   well as in [OPS, RFC3904]. Details of a tunnel based deployment are
   offered in the next section of this document (section 6). In the case
   of Cable Access where the current DOCSIS specifications do not
   provide support for native IPv6 access. Although sections 7, 8 and 8, 9
   and 10 focus on a native IPv6 deployments over DSL, FTTH and FTTH, Wireless
   and PLC/BPL because this approach is fully supported today, tunnel
   based solutions are also possible in these cases based on the
   guidelines of this section and some of the recommendations provided
   in section 6.

6. Broadband Cable Networks

   This section describes the infrastructure that exists today in
   cable networks providing BB services to the home. It also describes
   IPv6 deployment options in these cable networks.

   DOCSIS standardizes and documents the operation of data over Cable
   Networks. The current version of DOCSIS has limitations that do not
   allow for a smooth implementation of native IPv6 transport. Some of
   these limitations are discussed in this section. For this reason,
   the IPv6 deployment scenarios discussed in this section for the
   existent Cable Networks are tunnel based. The tunneling examples
   presented here could also be applied to the other BB technologies
   described in sections 7, 8 8, 9 and 9. 10.

6.1 Broadband Cable Network Elements

   Broadband cable networks are capable of transporting IP traffic to/
   from users to provide high speed Internet access and VOIP services.
   The mechanism of transporting IP traffic over cable networks is
   outlined in the DOCSIS specification [RF Interface].

   Here are some of the key elements of a Cable network:

   Cable (HFC) Plant: Hybrid Fiber Coaxial plant, used as the underlying
   transport

   CMTS: Cable Modem Termination System (can be a Layer 2 bridging or
   Layer 3 routing CMTS)

   GWR: Residential Gateway Router (provides Layer 3 services to hosts)
   Host: PC, notebook etc. which is connected to the CM or GWR

   CM: Cable Modem

   ER: Edge Router

   MSO: Multiple Service Operator

   Data Over Cable Service Interface Specification (DOCSIS): The
   standards defining how data should be carried over cable networks.

   Figure 9.1 6.1 illustrates the key elements of a Cable Network

<--- ACCESS  ---><------ HFC ------><----- Aggregation / Core ----->
+-----+  +------+
|Host |--| GWR  |
+-----+  +--+---+
            |        _ _ _ _ _ _
         +------+   |           |
         |  CM  |---|           |
         +------+   |           |
                    |    HFC    |   +------+   +--------+
                    |           |   |      |   | Edge   |
+-----+  +------+   |  Network  |---| CMTS |---|        |===> ISP
|Host |--|  CM  |---|           |   |      |   | Router |   Network
+-----+  +--+---+   |           |   +------+   +--------+
                    |_ _ _ _ _ _|
         +------+         |
+-----+  | GWR/ |         |
|Host |--| CM   |---------+
+-----+  |      |
         +------+      Figure 6.1

6.2 Deploying IPv6 in Cable Networks

   One of the motivators for an MSO to deploy IPv6 over their Cable
   Network is to ease management burdens. IPv6 can be enabled on the
   host,
   CM, CMTS and ER for management purposes. Currently portions of the
   cable infrastructure use RFC1918 IPv4 addresses; however, there are
   a finite number of those.  Thus, IPv6 could have utility in the
   cable space implemented on the control management plane initially and later
   on focused on the data plane for end user services. For more
   details on using IPv6 for management in Cable Networks please refer
   to section 6.6.1.

   There are two different deployment modes in current cable networks:
   a bridged CMTS environment and a routed CMTS environment. IPv6 can
   be deployed in both of these environments.

   1. Bridged CMTS Network

   In this scenario, both the CM and CMTS bridge all data traffic.

   Traffic to/from host devices is forwarded through the cable network
   to the ER. The ER then routes traffic through the ISP network to the
   Internet. The CM and CMTS support a certain degree of Layer 3
   functionality for management purposes.

   2. Routed CMTS Network

   In a routed network, the CMTS forwards IP traffic to/from hosts
   based on Layer 3 information using the IP source/destination address.
   The CM acts as a Layer-2 bridge for forwarding data traffic and
   supports some Layer 3 functionality for management purposes.

   Some of the factors that hinder deployment of native IPv6 in current
   cable networks include:

   A. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. These
   devices rely on IGMP join messages to track membership of hosts that
   are part of a particular IP Multicast group. In order to support ND
   the CM and CMTS will need to support IGMPv3/MLDv1 IGMPv3/MLDv2 or v2 v1 snooping.

   B. Classification of IPv6 traffic in the upstream and downstream
   direction. The CM and CMTS will need to support classification of
   IPv6 packets in order to give them the appropriate priority and
   QoS. Without proper classification all IPv6 traffic will need to be
   sent best effort (BE) which can cause problems when deploying
   services like VOIP and IP Multicast video.

   C. Changes need to be made to the DOCSIS specification to include
   support for IPv6 on the CM and CMTS. This is imperative for
   deploying native IPv6 over cable networks.

   Due to the above mentioned limitations in deployed cable networks,
   the only available option to cable operators is to use tunneling
   techniques in order to transport IPv6 traffic over their current
   IPv4 infrastructure. The following sections will cover these
   deployment scenarios in more detail.

6.2.1 Deploying IPv6 in a Bridged CMTS Network

   In IPv4 the CM and CMTS act as Layer 2 bridges and forward all data
   traffic to/from the hosts and the ER. The hosts use the ER as their
   Layer 3 next hop. If there is a GWR behind the CM it can act as a
   next hop for all hosts and forward data traffic to/from the ER.

   When deploying IPv6 in this environment, the CM and CMTS will
   continue to be bridging devices in order to keep the transition
   smooth and reduce operational complexity. The CM and CMTS will need
   to bridge IPv6 unicast and multicast packets to/from the ER and the
   hosts. If there is a GWR connected to the CM, it will need to forward
   IPv6 unicast and multicast traffic to/from the ER.

   Figure 6.2.1 illustrate the IPv6 deployment scenario

+-----+  +-----+
|Host |--| GWR |
+-----+  +--+--+
            |              _ _ _ _ _ _
            |  +------+   |           |
            +--|  CM  |---|           |
               +------+   |           |
                          |   HFC     |   +------+   +--------+
                          |           |   |      |   | Edge   |
      +-----+  +------+   |  Network  |---| CMTS |---|        |===> ISP
      |Host |--|  CM  |---|           |   |      |   | Router |  Network
      +-----+  +------+   |           |   +------+   +--------+
                          |_ _ _ _ _ _|

<-------------><---------------------------------><--------------->
    L3 Routed              L2 Bridged                 L3 Routed

                          Figure 6.2.1

6.2.1.1 IPv6 Related Infrastructure Changes

   In this scenario the CM and the CMTS bridge all data traffic so they
   will need to support bridging of native IPv6 unicast and multicast
   traffic. The following devices have to be upgraded to dual stack:
   Host, GWR and ER.

6.2.1.2 Addressing

   The proposed architecture for IPv6 deployment includes two components
   that must be provisioned: the CM and the host. Additionally if there
   is a GWR connected to the CM, it will also need to be provisioned.
   The host or the GWR use the ER as their Layer 3 next hop.

6.2.1.2.1 IP Addressing for CM

   The CM will be provisioned in the same way as in currently deployed
   cable networks, using an IPv4 address on the cable interface
   connected to the MSO network for management functions. During the
   initialization phase, it will obtain its IPv4 address using DHCPv4,
   and download a DOCSIS configuration file identified by the DHCPv4
   server.

6.2.1.2.2 IP Addressing for Hosts

   If there is no GWR connected to the CM, the host behind the CM will
   get a /64 prefix assigned to it via stateless autoconfiguration or
   DHCPv6.

   If using stateless auto-configuration, the host listens for routing
   advertisements (RA) from the ER. The RAs contain the /64 prefix
   assigned to the segment. Upon receipt of an RA, the host constructs
   its IPv6 address by combining the prefix in the RA (/64) and a unique
   identifier (e.g., its modified EUI-64 format interface ID).

   If DHCPv6 is used to obtain an IPv6 address, it will work in much
   the same way as DHCPv4 works today. The DHCPv6 messages exchanged
   between the host and the DHCPv6 server are bridged by the CM and
   the CMTS.

6.2.1.2.3 IP Addressing for GWR

   The GWR can use stateless auto-configuration (RA) to obtain an
   address for its upstream interface, the link between itself and
   the ER. This step is followed by a request via DHCP-PD (Prefix
   Delegation) for a prefix shorter than /64, typically /48, which
   in turn is divided into /64s and assigned to its downstream
   interfaces connecting to the hosts.

6.2.1.3 Data Forwarding

   The CM and CMTS must be able to bridge native IPv6 unicast and
   multicast traffic. The CMTS must provide IP connectivity between
   hosts attached to CMs and must do so in a way that meets the
   expectation of Ethernet attached customer equipment. In order to do
   that, the CM and CMTS must either forward Neighbor Discovery (ND) packets
   or provide a proxy ND service.
   between ER and the hosts attached to the CM.

   Communication between hosts behind different CMs is always forwarded
   through the CMTS.  IPv6 communication between the different sites
   relies on multicast IPv6 ND [RFC2461] frames being forwarded
   correctly by the CM and the CMTS. As with the CM, a bridged CMTS that
   selectively forwards multicast datagrams on the basis of IGMPv2 will
   potentially break IPv6 ND.

   In order to support IPv6 multicast applications across DOCSIS cable
   networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 or v1
   snooping. MLD is almost identical to IGMP in IPv4, only the name and
   numbers are changed. MLDv2 is identical to IGMPv3 and also supports
   ASM (Any Source Multicast) and SSM (Single Source Multicast)
   service models. Implementation work on CM/CMTS should be minimal
   because the only significant difference between IPv4 IGMPv3 and IPv6
   MLDv2 is the longer addresses in the protocol.

6.2.1.4 Routing

   The hosts install a default route that points to the ER or the GWR.
   No routing protocols are needed on these devices which generally
   have limited resources. If there is a GWR present it will also use
   static default route to the ER.

   The ER runs an IGP such as OSPFv3 or IS-IS. The connected prefixes
   have to be redistributed. If DHCP-PD is used, with every delegated
   prefix a static route is installed by the ER. For this reason the
   static routes must also be redistributed. Prefix summarization
   should be done at the ER.

   its IPv6 address by combining the prefix in the RA (/64) and a unique
   identifier (e.g., its modified EUI-64 format interface ID).

   If DHCPv6 is used to obtain an IPv6 address, it will work in much
6.2.2  Deploying IPv6 in a Routed CMTS Network

   In an IPv4 routed CMTS network the CM still acts as a Layer-2
   device and bridges all data traffic between its Ethernet interface
   and cable interface connected to the cable operator network. The CMTS
   acts as a Layer 3 router and may also include the ER functionality.
   The hosts and the GWR use the CMTS as their Layer 3 next hop.

   When deploying IPv6 in a routed CMTS network, the CM still acts
   as a Layer-2 device and will need to bridge IPv6 unicast as well as
   multicast traffic. The CMTS/ER will need to either tunnel IPv6
   traffic or natively support IPv6. The host and GWR will use the
   CMTS/ER as their Layer 3 next hop.

   There could be five possible deployment scenarios for IPv6 in a
   routed CMTS network:

   1. IPv4 Cable (HFC) Network

   In this scenario the cable network, including the CM and CMTS remain
   IPv4 devices. The host and ER are upgraded to dual-stack. This is the
   easiest way for a Cable Operator to provide IPv6 service as no
   changes are made to the cable network.

   2. IPv4 Cable (HFC) Network, GWR at Customer Site

   In this case the cable network, including the CM and CMTS remain
   IPv4 devices. The host, GWR and ER are upgraded to dual-stack. This
   scenario is also easy to deploy since the cable operator just needs
   to add GWR at the customer site.

   3. Dual-stacked Cable (HFC) Network, CM and CMTS Support IPv6

   In this scenario the CMTS is upgraded to dual-stack to support IPv4
   and IPv6. Since the CMTS supports IPv6 it can acts as an ER as well.
   The CM will act as a Layer-2 bridge but will need to bridge IPv6
   unicast and multicast traffic. This scenario is not easy to deploy
   since it requires changes to the DOCSIS specification. The CM and
   CMTS may require HW and SW upgrades to support IPv6.

   4. Dual-stacked Cable (HFC) Network, Standalone GWR and CMTS Support
      IPv6

   In this scenario there is a standalone GWR connected to the CM.
   Since the IPv6 functionality exists on the GWR the CM does not need
   to be dual-stack. The  CMTS is upgraded to dual-stack and it can
   incorporate the ER functionality. This scenario may also require HW
   and SW changes on the GWR and CMTS.

   5. Dual-stacked Cable (HFC) Network, Embedded GWR/CM and CMTS Support
      IPv6

   In this scenario the CM and GWR functionality exists on a single
   device which needs to be upgraded to dual-stack. The CMTS will also
   need to be upgraded to a dual-stack device. This scenario is also
   difficult to deploy in existent cable network since it requires
   changes on the Embedded GWR/CM and the CMTS.

   The DOCSIS specification will also need to be modified to allow
   native IPv6 support on the Embedded GWR/CM.

6.2.2.1 IPv4 Cable Network, Host and ER Upgraded to Dual-Stack

   This is one of the most cost effective ways for a Cable Operator to
   offer IPv6 services to its customers. Since the cable network remains
   IPv4 there is relatively minimal cost involved in turning up IPv6
   service. All IPv6 traffic is exchanged between the hosts and the ER.

   Figure 6.2.2.1 illustrates this deployment scenario

                        +-----------+    +------+    +--------+
  +-----+  +-------+    |   Cable   |    |      |    |  Edge  |
  |Host |--|  CM   |----|  (HFC)    |----| CMTS |----|        |=>ISP
  +-----+  +-------+    |  Network  |    |      |    | Router | Network
                        +-----------+    +------+    +--------+
          _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
        ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
                     IPv6-over-IPv4
                       IPv6-in-IPv4 tunnel

<---------><----------------------------------------><------------>
  IPv4/v6                 IPv4 only                    IPv4/v6

                           Figure 6.2.2.1

6.2.2.1.1 IPv6 Related Infrastructure Changes

   In this scenario the CM and the CMTS will only need to support IPv4
   so no changes need to be made to them or the cable network. The
   following devices have to be upgraded to dual stack: Host and ER.

6.2.2.1.2 Addressing

   The only device that needs to be assigned an IPv6 address at customer
   site is the host. Host address assignment can be done in multiple
   ways. Depending on the tunneling mechanism used it could be
   automatic or might require manual configuration.. configuration.

   The host still receives an IPv4 address using DHCPv4, which works
   the same way in currently deployed cable networks. In order to get
   IPv6 connectivity, host devices will also need an IPv6 address and
   a means to communicate with the ER.

6.2.2.1.3 Data Forwarding

   All IPv6 traffic will be sent to/from the ER and the host device. In
   order to transport IPv6 packets over the cable operator IPv4
   network, the host and the ER will need to use one of the available
   IPv6 over in IPv4 tunneling mechanisms.

   The host will use its IPv4 address to source the tunnel to the
   ER. All IPv6 traffic will be forwarded to the ER, encapsulated in
   IPv4 packets. The intermediate IPv4 nodes will forward this traffic
   as regular IPv4 packets. The ER will need to terminate the tunnel
   and/or provide other IPv6 services.

6.2.2.1.4 Routing

   Routing configuration on the host will vary depending on
   the tunneling technique used, in some cases a default or static
   route might be needed to forward traffic to the next hop.

   The ER runs an IGP such as OSPFv3 or ISIS.

6.2.2.2 IPv4 Cable Network, Host, GWR and ER Upgraded to Dual-Stack

   The cable operator can provide IPv6 services to its customers, in
   this scenario, by adding a GWR behind the CM. Since the GWR will
   facilitate all IPv6 traffic to/from the host and the ER, the cable
   network including the CM and CMTS do not need to support IPv6 and
   can remain IPv4 devices.

   Figure 6.2.2.2 illustrates this deployment scenario

 +-----+
 |Host |
 +--+--+
    |                   +-----------+    +------+    +--------+
+---+---+  +-------+    |   Cable   |    |      |    |  Edge  |
|  GWR  |--|  CM   |----|  (HFC)    |----| CMTS |----|        |=>ISP
+-------+  +-------+    |  Network  |    |      |    | Router |  Network
                        +-----------+    +------+    +--------+
          _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
        ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
                      IPv6-over-IPv4
                       IPv6-in-IPv4 tunnel

<---------><---------------------------------------><------------->
  IPv4/v6                 IPv4 only                    IPv4/v6

                           Figure 6.2.2.2

6.2.2.2.1 IPv6 Related Infrastructure Changes

   In this scenario the CM and the CMTS will only need to support IPv4
   so no changes need to be made to them or the cable network. The
   following devices have to be upgraded to dual stack: Host, GWR and
   ER.

6.2.2.2.2 Addressing

   The only devices that needs to be assigned an IPv6 address at
   customer site are the host and GWR. IPv6 address assignment can be
   done statically at the GWR downstream interface. The GWR will send
   out RA messages on its downstream interface which will be used by the
   hosts to auto-configure themselves with an IPv6 address. The GWR can
   also configure its upstream interface using RA messages from the ER
   and use DHCP-PD for requesting a /48 prefix from the ER. This /48
   prefix will be used to configure /64s on hosts connected to the GWR
   downstream interfaces. Currently the DHCP-PD functionality cannot be
   implemented if the DHCP-PD server is not the Edge Router. If the
   DHCP-PD messages are relayed, the Edge Router does not have a
   mechanism to learn the assigned prefixes and thus install the proper
   routes to make that prefix reachable. Work is being done to address
   this issue, one idea being to provide the Edge Router with a snooping
   mechanism. The uplink to the ISP network is configured with a /64
   prefix as well.

   The GWR still receives a global IPv4 address on its upstream
   interface using DHCPv4, which works the same way in currently
   deployed cable networks. In order to get IPv6 connectivity to the
   Internet the GWR will need to communicate with the ER.

6.2.2.2.3 Data Forwarding

   All IPv6 traffic will be sent to/from the ER and the GWR, which will
   forward IPv6 traffic to/from the host. In order to transport IPv6
   packets over the cable operator IPv4 network, the GWR and the ER
   will need to use one of the available IPv6 over in IPv4 tunneling
   mechanisms. All IPv6 traffic will need to go through the tunnel, once
   it comes up.

   The GWR will use its IPv4 address to source the tunnel to the ER.
   The tunnel endpoint will be the IPv4 address of the ER. All IPv6
   traffic will be forwarded to the ER, encapsulated in IPv4 packets.
   The intermediate IPv4 nodes will forward this traffic as regular
   IPv4 packets. In case of 6to4 tunneling, the ER will need to support
   6to4 relay functionality in order to provide IPv6 Internet
   connectivity to the GWR and hence the hosts connected to the GWR.

6.2.2.2.4 Routing

   Depending on the tunneling technique used there might some
   configuration needed on the GWR and the ER. If the ER is also
   providing a 6to4 relay service then a default route will need to be
   added to the GWR pointing to the ER, for all non-6to4 traffic.

   If using manual tunneling, the GWR and ER can use static routing or
   they can also configure RIPng. The RIPng updates can be transported
   over a manual tunnel, which does not work when using 6to4 tunneling.

   Customer routes can be carried to the ER using RIPng updates. The ER
   can advertise these routes in its IGP. Prefix summarization should be
   done at the ER.

   If DHCP-PD is used for address assignment a static route is
   automatically installed on the CMTS/ER for each delegated /48 prefix.
   The static routes need to be redistributed into the IGP at the
   CMTS/ER, so there is no need for a routing protocol between the
   CMTS/ER and the GWR.

   The ER runs an IGP such as OSPFv3 or ISIS.

6.2.2.3 Dual-stacked Cable (HFC) Network, CM and CMTS Support IPv6

   In this scenario the Cable Operator can offer native IPv6 services
   to its customers since the cable network including the CMTS supports
   IPv6. The ER functionality can be included in the CMTS or it can
   exist on a separate router connected to the CMTS upstream interface.
   The CM will need to bridge IPv6 unicast and multicast traffic.

   Figure 6.2.2.3 illustrates this deployment scenario

                        +-----------+    +-------------+
  +-----+  +-------+    |   Cable   |    | CMTS / Edge |
  |Host |--|  CM   |----|  (HFC)    |----|             |=>ISP
  +-----+  +-------+    |  Network  |    |   Router    |  Network
                        +-----------+    +-------------+

  <-------><----------------------------><---------------->
   IPv4/v6              IPv4/v6              IPv4/v6

                          Figure 6.2.2.3

6.2.2.3.1 IPv6 Related Infrastructure Changes

   Since the CM still acts as a Layer-2 bridge, it does not need to
   be dual-stack. The CM will need to support bridging of IPv6 unicast
   and multicast traffic and IGMPv3/MLDv1 IGMPv3/MLDv2 or v2 v1 snooping which requires
   changes in the DOCSIS specification. In this scenario the following
   devices have to be upgraded to dual stack: Host and CMTS/ER.

6.2.2.3.2 Addressing

   In today's cable networks the CM receives a private IPv4 address
   using DHCPv4 for management purposes. In an IPv6 environment, the
   CM will continue to use an IPv4 address for management purposes.
   The cable operator can also choose to assign an IPv6 address to the
   CM for management, but the CM will have to be upgraded to support
   this functionality.

   IPv6 address assignment for the CM and host can be done via DHCP or
   stateless autoconfiguration. If the CM uses an IPv4 address for
   management, it will use DHCPv4 for its address assignment and the
   CMTS will need to act as a DHCPv4 relay agent. If the CM uses an IPv6
   address for management, it can use DHCPv6 with the CMTS acting as a
   DHCPv6 relay agent or the CMTS can be statically configured with a
   /64 prefix and it can send out RA messages out the cable interface.
   The CMs connected to the cable interface can use the RA messages to
   auto-configure themselves with an IPv6 address. All CMs connected to
   the cable interface will be in the same subnet.

   The hosts can receive their IPv6 address via DHCPv6 or stateless
   autoconfiguration. With DHCPv6, the CMTS may need to act as a DHCPv6
   relay agent and forward DHCP messages between the hosts and the DHCP
   server. With stateless autoconfiguration, the CMTS will be configured
   with multiple /64 prefixes and send out RA messages to the hosts.
   If the CMTS is not also acting as an ER, the RA messages will come
   from the ER connected to the CMTS upstream interface. The CMTS will
   need to forward the RA messages downstream or act as an ND proxy.

6.2.2.3.3 Data Forwarding

   All IPv6 traffic will be sent to/from the CMTS and hosts. Data
   forwarding will work the same way it works in currently deployed
   cable networks. The CMTS will forward IPv6 traffic to/from hosts
   based on the IP source/destination address.

6.2.2.3.4 Routing

   No routing protocols are needed between the CMTS and the host
   since the CM and host are directly connected to the CMTS cable
   interface. Since the CMTS supports IPv6, hosts will use the CMTS
   as their Layer 3 next hop.

   If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3
   or ISIS.

6.2.2.4 Dual-Stacked Cable (HFC) Network, Standalone GWR and CMTS
        Support IPv6

   In this case the cable operator can offer IPv6 services to its
   customers by adding a GWR between the CM and the host. The GWR will
   facilitate IPv6 communication between the host and the CMTS/ER. The
   CMTS will be upgraded to dual-stack to support IPv6 and can acts as
   an ER as well. The CM will act as a bridge for forwarding data
   traffic and does not need to support IPv6.

   This scenario is similar to the case described in section 6.2.2.2.
   The only difference in this case is the ER functionality exists on
   the CMTS instead of a separate router in the cable operator network.

   Figure 6.2.2.4 illustrates this deployment scenario
                                  +-----------+    +------------+
+------+   +-------+  +-------+   |   Cable   |    |CMTS / Edge |
| Host |---| GWR   |--|  CM   |---|  (HFC)    |----|            |=>ISP
+------+   +-------+  +-------+   |  Network  |    |   Router   |Network
                                  +-----------+    +------------+

                   _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
                  ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
                        IPv6-over-IPv4
                          IPv6-in-IPv4 tunnel
<-----------------><--------------------------------><-------------->
      IPv4/v6                      IPv4                  IPv4/v6

                            Figure 6.2.2.4

6.2.2.4.1 IPv6 Related Infrastructure Changes

   Since the CM still acts as a Layer-2 bridge, it does not need to
   be dual-stack nor does it need to support IPv6. In this scenario
   the following devices have to be upgraded to dual stack: Host, GWR
   and CMTS/ER.

6.2.2.4.2 Addressing

   The CM will still receive a private IPv4 address using DHCPv4 which
   works the same way in existent cable networks. The CMTS will act as
   DHCPv4 relay agent.

   The address assignment for the host and GWR happens in a similar
   manner as described in section 6.2.2.2.2.

6.2.2.4.3 Data Forwarding

   Data forwarding between the host and CMTS/ER is facilitated by the
   GWR and happens in a similar manner as described in section
   6.2.2.2.3.

6.2.2.4.4 Routing

   In this case routing is very similar to the case described in
   section 6.2.2.2.4. Since the CMTS now incorporates the ER
   functionality, it will need to run an IGP such as OSPFv3 or ISIS.

6.2.2.5 Dual-Stacked Cable (HFC) Network, Embedded GWR/CM and CMTS
        Support IPv6

   In this scenario the Cable Operator can offer native IPv6 services
   to its customers since the cable network including the CM/Embedded
   GWR and CMTS support IPv6. The ER functionality can be included in
   the CMTS or it can exist on a separate router connected to the CMTS
   upstream interface. The CM/Embedded GWR acts as a Layer 3 device.

   Figure 6.2.2.5 illustrates this deployment scenario

                            +-----------+    +-------------+
 +-----+   +-----------+    |   Cable   |    | CMTS / Edge |
 |Host |---| CM / GWR  |----|  (HFC)    |----|             |=> ISP
 +-----+   +-----------+    |  Network  |    |   Router    |   Network
                            +-----------+    +-------------+

 <---------------------------------------------------------->
                           IPv4/v6

                          Figure 6.2.2.5

6.2.2.5.1 IPv6 Related Infrastructure Changes

   Since the CM/GWR acts as a Layer 3 device, IPv6 can be deployed
   end-to-end. In this scenario the following devices have to be
   upgraded to dual-stack: Host, CM/GWR and CMTS/ER.

6.2.2.5.2 Addressing

   Since the CM/GWR is dual-stack, it can receive an IPv4 or IPv6
   address using DHCP for management purposes. As the GWR functionality
   is Embedded in the CM, it will need an IPv6 address for forwarding
   data traffic. IPv6 address assignment for the CM/GWR and host can be
   done via DHCPv6 or DHCP-PD.

   If using DHCPv6 the CMTS will need to act as DHCPv6 relay agent. The
   host and CM/GWR will receive IPv6 addresses from pools of /64
   prefixes configured on the DHCPv6 server. The CMTS will need to glean
   pertinent information from the DHCP Offer messages, sent from the
   DHCP server to the DHCP clients (host and CM/GWR), much like it does
   today in DHCPv4. All CM/GWR connected to the same cable interface on
   the CMTS belong to same management /64 prefix. The hosts connected
   to the same cable interface on the CMTS may belong to different /64
   customer prefixes as the CMTS will may have multiple /64 prefixes
   configured under its cable interfaces.

   It is also possible to use DHCP-PD for IPv6 address assignment. In
   this case the CM/GWR will use stateless auto-configuration to assign
   an IPv6 address to its upstream interface using the /64 prefix
   sent by the CMTS/ER in RA message. Once the CM/GWR assigns an IPv6
   address to its upstream interface it will request a /48 prefix from
   the CMTS/ER and chop this /48 prefix into /64s for assigning IPv6
   addresses to hosts. Currently the DHCP-PD functionality cannot be
   implemented if the DHCP-PD server is not the Edge Router. If the
   DHCP-PD messages are relayed, the Edge Router does not have a
   mechanism to learn the assigned prefixes and thus install the proper
   routes to make that prefix reachable. Work is being done to address
   this issue, one idea being to provide the Edge Router with a snooping
   mechanism. The uplink to the ISP network is configured with a /64
   prefix as well.

6.2.2.5.3 Data Forwarding

   The host will use the CM/GWR as the Layer 3 next hop. The CM/GWR
   will forward all IPv6 traffic to/from the CMTS/ER and hosts. The
   CMTS/ER will forward IPv6 traffic to/from hosts based on the IP
   source/destination address.

6.2.2.5.4 Routing

   The CM/GWR can use a static default route pointing to the CMTS/ER or
   it can run a routing protocol such as RIP-ng or OSPFv3 between itself
   and the CMTS. Customer routes from behind the CM/GWR can be carried
   to the CMTS using routing updates.

   If DHCP-PD is used for address assignment a static route is
   automatically installed on the CMTS/ER for each delegated /48 prefix.
   The static routes need to be redistributed into the IGP at the
   CMTS/ER so there is no need for a routing protocol between the
   CMTS/ER and the GWR.

   If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3
   or ISIS.

6.3 IPv6 Multicast

   In order to support IPv6 multicast applications across DOCSIS cable
   networks, the CM and bridging CMTS will need to support IGMPv3/MLDv1 IGMPv3/MLDv2
   or v2 v1 snooping. MLD is almost identical to IGMP in IPv4, only the
   name and numbers are changed. MLDv2 is almost identical to IGMPv3
   and also supports ASM (Any Source Multicast) and SSM (Single Source
   Multicast) service models.

   SSM is more suited for deployments where the SP intends to provide
   paid content to the users (Video or Audio). This type of services
   are expected to be of primary interest. Moreover, the simplicity of
   the SSM model often times override the scalability issues that would
   be resolved in an ASM model. ASM is however an option that is
   discussed in section 7.3.1. The "SSM safe reporting" problem for IPv4
   where contention can be generated when a snooping switch sees a (S,G)
   INCLUDE and a (*,G) EXCLUDE does not exist in IPv6 multicast because
   the SSM address range in IPv6 is well defined. The Layer 3 CM, GWR and
   Layer 3 routed CMTS/ER will need to be enabled with PIM-SSM, which
   requires the definition and support for IGMPv3/MLDv1 or v2 snooping,
   in order to track join/leave messages from the hosts. Another option
   would be for the Layer 3 CM or GWR to support MLD proxy routing. The
   Layer 3 next hop for the hosts needs to support MLD.

   Please refer to section 7.3 for more IPv6 multicast details.

6.4 IPv6 QoS

   IPv6 will not change or add any queuing/scheduling functionality
   already existing in DOCSIS specifications. But the QoS mechanisms on
   the CMTS and CM would need to be IPv6 capable. This includes support
   for IPv6 classifiers, so that data traffic to/from host devices can
   be classified appropriately into different service flows and be
   assigned appropriate priority. Appropriate classification criteria
   would need to be implemented for unicast and multicast traffic.

   In order to classify IPv6 traffic the following classifiers would
   need to be modified in the DOCSIS specification to support the
   128-bit IPv6 address:

   A. IP source address
   B. IP source mask
   C. IP destination address
   D. IP destination mask
   E. IP traffic class (DSCP)

   The following classifiers would be new for IPv6:

   A. IP version
   B. Flow label (optional)

   Traffic classification and marking should be done at the CM for
   upstream traffic and the CMTS/ER for downstream traffic in order to
   support the various types of services: data, voice, video. The same
   IPv4 QoS concepts and methodologies should be applied for IPv6 as
   well.

   It is important to note that when traffic is encrypted end-to-end,
   the traversed network devices will not have access to many of the
   packet fields used for classification purposes. In these cases
   routers will most likely place the packets in the default classes.
   The QoS design should take into consideration this scenario and try
   to use mainly IP header fields for classification purposes.

6.5 IPv6 Security Considerations

   Security in a DOCSIS cable network is provided using Baseline Privacy
   Plus (BPI+). The only part that is dependent on IP addresses is
   encrypted multicast. Semantically, multicast encryption would work
   the same way in an IPv6 environment as in the IPv4 network. However,
   appropriate enhancements will be needed in the DOCSIS specification
   to support encrypted IPv6 multicast.

   The other aspect of security enhancement is mandated IPSec support
   in IPv6. The IPv6 specifications mandate implementation of IPSec,
   but they do not mandate its use. The IPv4 specifications do not
   mandate IPSec. IPSec is the same for both IPv4 and IPv6, but it
   still requires a key distribution mechanism. Cable operators may
   consider deploying it end-to-end on IPv6 as there is not an
   intermediate device(i.e. NAT).

   There are limited changes that have to be done for hosts in order to
   enhance security. The Privacy extensions [RFC3041] for
   autoconfiguration should be used by the hosts. IPv6 firewall
   functions could be enabled, if available on the host or GWR.

   The ISP provides security against attacks that come form its own
   subscribers but it could also implement security services that
   protect its subscribers from attacks sourced from the outside of its
   network. Such services do not apply at the access level of the
   network discussed here.

   The CMTS/ER should protect the ISP network and the other subscribers
   against attacks by one of its own customers. For this reason Unicast
   Reverse Path Forwarding (uRPF) [RFC3704] and ACLs should be used on
   all interfaces facing subscribers. Filtering should be implemented
   with regard for the operational requirements of IPv6 (ICMPv6 types).
   For instance, ND messages should not be filtered. [Security
   considerations for IPv6].

   The CMTS/ER should protect its processing resources against floods of
   valid customer control traffic such as: Router and Neighbor
   Solicitations, MLD Requests.

   All other security features used with the IPv4 service should be
   similarly applied to IPv6 as well.

6.6 IPv6 Network Management

   The current DOCSIS, PacketCable, and CableHome MIBs are already

   designed to support

   IPv6 objects. In this case, can have many applications in Cable Networks. MSOs can initially
   implement IPv6 will neither
   add, nor change any of on the functionality control plane and use it to manage the
   thousands of these MIBs. An object devices connected to
   identify the IP version, InetAddressType has been added CMTS. This would be a good way
   to all introduce IPv6 in a Cable Network. Later on the
   appropriate SNMP objects related MSO can extend
   IPv6 to IP address.

   There are some exceptions, the following MIBs might need data plane and use it to add carry customer as well as
   management traffic.

6.6.1 Using IPv6
   support:

   On the CMTS

   A. DOCS-QOS-MIB
   B. DOCS-SUBMGT-MIB (Subscriber for Management Interface Specification
      ANNEX B)

   On the CM

   A. DOCS-QOS-MIB
   B. DOCS-CABLE-DEVICE-MIB (or RFC2669)

7. Broadband DSL in Cable Networks

   This section describes the

   IPv6 deployment options can be enabled in today's
   High Speed DSL Networks.

7.1 DSL a Cable Network Elements

   Digital Subscriber Line (DSL) broadband services provide users
   with IP connectivity over the existing twisted-pair telephone lines
   called the local-loop. A wide range of bandwidth offerings are
   available depending on the quality for management of the line devices like
   CM, CMTS and ER. With the distance
   between the Customer Premises Equipment roll out of advanced services like VoIP and the DSLAM.

   The following network elements
   Video-over-IP, MSOs are typical looking for ways to manage the large number
   of devices connected to the CMTS. In IPv4, an RFC1918 address is
   assigned to these devices like CM for management purposes. Since
   there is a DSL finite number of RFC1918 addresses available, it is
   becoming difficult for MSOs to manage these devices.

   By using IPv6 for management purposes, MSOs can scale their network [ISP
   Transition Scenarios]:

    DSL Modem: It
   management systems to meet their needs. The CMTS/ER can be
   configured with a stand alone device, it /64 management prefix which is shared among all
   CMs connected to the CMTS cable interface. Addressing for the CMs
   can be incorporated
    in done via stateless autoconfiguration. Once the host, it CMs receive
   the /64 prefix from the CMTS/ER via RA they can incorporate router functionalities and also
    have configure themselves
   with an IPv6 address.

   If there are devices behind the capabilities to act as a CPE router.

    Customer Premises Router: It is used CM which need to provide Layer 3 services
    for customer premises networks. It be managed by the
   MSO, another /64 prefix can be defined on the CMTS/ER. These devices
   can also use stateless autoconfiguration to assign themselves an IPv6
   address.

   Traffic sourced from or destined to the management prefix should not
   cross the MSO's network boundaries.

   In this scenario IPv6 will only be used for managing these devices
   on the Cable Network, all data traffic will still be forwarded by
   the CM and CMTS/ER using IPv4.

6.6.2 Updates to MIBs/Standards to support IPv6

   The current DOCSIS, PacketCable, and CableHome MIBs are already
   designed to support IPv6 objects. In this case, IPv6 will neither
   add, nor change any of the functionality of these MIBs. An object to
   identify the IP version, InetAddressType has been added to all the
   appropriate SNMP objects related to IP address.

   There are some exceptions, the following MIBs might need to add IPv6
   support:

   On the CMTS

   A. DOCS-QOS-MIB
   B. DOCS-SUBMGT-MIB (Subscriber Management Interface Specification
      ANNEX B)

   On the CM

   A. DOCS-QOS-MIB
   B. DOCS-CABLE-DEVICE-MIB (or RFC2669)

7. Broadband DSL Networks

   This section describes the IPv6 deployment options in today's
   High Speed DSL Networks.

7.1 DSL Network Elements

   Digital Subscriber Line (DSL) broadband services provide users
   with IP connectivity over the existing twisted-pair telephone lines
   called the local-loop. A wide range of bandwidth offerings are
   available depending on the quality of the line and the distance
   between the Customer Premises Equipment and the DSLAM.

   The following network elements are typical of a DSL network [ISP
   Transition Scenarios]:

    DSL Modem: It can be a stand alone device, it can be incorporated
    in the host, it can incorporate router functionalities and also
    have the capabilities to act as a CPE router.

    Customer Premises Router: It is used to provide Layer 3 services
    for customer premises networks. It is usually used to provide
    firewalling functions and segment broadcast domains for a Small
    business.

    DSL Access Multiplexer (DSLAM): It terminates multiple twisted
    pair telephone lines and provides aggregation to BRAS.

    Broadband Remote Access Server (BRAS): It aggregates or terminates
    multiple PVC corresponding to the subscriber DSL circuits.

    Edge Router (ER): It provides the Layer 3 interface to the ISP
    network.

   Figure 7.1 depicts all the network elements mentioned.

Customer Premises | Network Access Provider | Network Service Provider
       CP                     NAP                        NSP

+-----+  +------+                 +------+   +--------+
|Hosts|--|Router|              +--+ BRAS +---+ Edge   |       ISP
+-----+  +--+---+              |  |      |   | Router +===> Network
            |                  |  +------+   +--------+
         +--+---+              |
         | DSL  +--+           |
         |Modem |  |           |
         +------+  |  +-----+  |
                   +--+     |  |
         +------+     |DSLAM+--+
+-----+  | DSL  |  +--+     |
|Hosts|--+Modem +--+  +-----+
+-----+  +--+---+

                                Figure 7.1

7.2 Deploying IPv6 in IPv4 DSL Networks

   There are three main design approaches to providing IPv4 connectivity
   over a DSL infrastructure:

   1. Point-to-Point Model: Each subscriber connects to the DSLAM
   over a twisted pair and is provided with a unique PVC that links it
   to the service provider. The PVCs can be terminated at the BRAS or
   at the Edge Router.  This type of design is not very scalable if the
   PVCs are not terminated as close as possible to the DSLAM (at the
   BRAS). In this case a large number of layer two circuits has to be
   maintained over a significant portion of the network. The layer two
   domains can be terminated at the ER in three ways:

   A. In a common bridge group with a virtual interface that routes it
   out.

   B. Enable a Routed Bridged Encapsulation feature, all users could be
   part of the same subnet. This is the most common deployment type of
   IPv4 over DSL but it might not be the best choice in IPv6 where
   address availability is not an issue.

   C. Terminate the PVC at Layer 3, each PVC has its own prefix. This is
   the approach that seems more suitable for IPv6 and presented in 7.2.1
   In none of these cases the CPE (DSL Modem) has to be upgraded.

   2. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened
   between each subscriber and the BRAS. The BRAS terminates the PPP
   sessions and provides Layer 3 connectivity between the subscriber
   and the ISP. This model is presented in section 7.2.2.

   3. L2TP Access Aggregation (LAA) Model: PPP sessions are opened
   between each subscriber and the ISP Edge Router. The BRAS tunnels the
   subscriber PPP sessions to the ISP by encapsulating them into L2TPv2
   tunnels. This model is presented in section 7.2.3.

   In aggregation models the BRAS terminates the subscriber PVCs and
   aggregates their connections before providing access to the ISP.

   In order to maintain the deployment concepts and business models
   proven and used with existent revenue generating IPv4 services, the
   IPv6 deployment will match the IPv4 one. This approach is presented
   in sections 7.2.1-3 that describe current IPv4 over DSL broadband
   access deployments. Under certain circumstances where new service
   types or service needs justify it, IPv4 and IPv6 network logical
   architectures could be different as described in section 7.2.4.

7.2.1 Point-to-Point Model

   In this scenario the Ethernet frames from the Host or the Customer
   Premises Router are bridged over the PVC assigned to the subscriber.

   Figure 7.2.1 describes the protocol architecture of this model.

     Customer Premises              NAP                 NSP
<------------------------->  <---------------> <-------------------->

+-----+  +-------+  +-----+  +--------+        +----------+
|Hosts|--+Router +--+ DSL +--+ DSLAM  +--------+   Edge   |      ISP
+-----+  +-------+  |Modem|  +--------+        |  Router  +==> Network
                    +-----+                    +----------+
                        <---------------------------->
                                    ATM
                                Figure 7.2.1

7.2.1.1 IPv6 Related Infrastructure Changes

   In this scenario the DSL modem and the entire NAP is Layer 3 unaware,
   so no changes are needed to support IPv6. The following devices have
   to be upgraded to dual stack: Host, Customer Router (if present) and
   Edge Router.

7.2.1.2 Addressing

   The Hosts or the Customer Routers have the Edge Router as their Layer
   3 next hop.

   If there is no Customer Router all the hosts on the subscriber site
   belong to the same /64 subnet that is statically configured on the
   Edge Router for that subscriber PVC. The hosts can use stateless
   autoconfiguration or stateful DHCPv6 based configuration to acquire
   an address via the Edge Router.

   If a Customer Router is present:

   A. It is statically configured with an address on the /64 subnet
   between itself and the Edge Router, and with /64 prefixes on the
   interfaces connecting the hosts on the customer site. This is not a
   desired provisioning method being expensive and difficult to manage.

   B. It can use its link-local address to communicate with the ER.
   It can also dynamically acquire through stateless autoconfiguration
   the prefix for the link between itself and the ER. The later option
   allows it to contact a remote DHCPv6 server if needed. This step is
   followed by a request via DHCP-PD for a prefix shorter than /64
   that in turn is divided in /64s and assigned to its downstream
   interfaces.

   The Edge Router has a /64 prefix configured for each subscriber VLAN.
   Each VLAN should be enabled to relay DHCPv6 requests from the
   subscribers to DHCPv6 servers in the ISP network. The VLANs providing
   access for subscribers that use DHCP-PD as well, have to be enabled
   to support the feature. Currently the DHCP-PD functionality cannot be
   implemented if the DHCP-PD server is usually use to provide
    firewalling functions and segment broadcast domains for not the Edge Router. If the
   DHCP-PD messages are relayed, the Edge Router does not have a Small
    business.

    DSL Access Multiplexer (DSLAM): It terminates multiple twisted
    pair telephone lines
   mechanism to learn the assigned prefixes and provides aggregation thus install the proper
   routes to BRAS.

    Broadband Remote Access Server (BRAS): It aggregates or terminates
    multiple PVC corresponding make that prefix reachable. Work is being done to address
   this issue, one idea being to provide the subscriber DSL circuits. Edge Router (ER): It provides the Layer 3 interface with a snooping
   mechanism. The uplink to the ISP
    network.
   Figure 7.1 depicts all the network elements mentioned.

Customer Premises | Network Access Provider | Network Service Provider
       CP                     NAP                        NSP

+-----+  +------+                 +------+   +--------+
|Hosts|--|Router|              +--+ BRAS +---+ Edge   |       ISP
+-----+  +--+---+              |  |      |   | Router +===> Network
            |                  |  +------+   +--------+
         +--+---+              |
         | DSL  +--+           |
         |Modem |  |           |
         +------+  |  +-----+  |
                   +--+     |  |
         +------+     |DSLAM+--+
+-----+  | DSL  |  +--+     |
|Hosts|--+Modem +--+  +-----+
+-----+  +--+---+

                                Figure 7.1

7.2 Deploying IPv6 in IPv4 DSL Networks

   There are three main design approaches to providing IPv4 connectivity
   over is configured with a DSL infrastructure:

   1. Point-to-Point Model: Each /64
   prefix as well.

   The prefixes used for subscriber connects to links and the DSLAM
   over ones delegated via
   DHCP-PD should be planned in a twisted pair and manner that allows as much
   summarization as possible at the Edge Router.

   Other information of interest to the host, such as DNS, is provided
   through stateful DHCPv6 [RFC3315] and stateless DHCPv6 [RFC3736].

7.2.1.3 Routing

   The CPE devices are configured with a unique PVC default route that links it points to
   the service provider. The PVCs can be terminated at the BRAS or
   at the Edge Router.  This type of design is not very scalable if the
   PVCs router. No routing protocols are not terminated as close as possible to needed on these devices
   which generally have limited resources.

   The Edge Router runs the DSLAM (at IPv6 IGP used in the
   BRAS). In this case a large number of layer two circuits has NSP: OSPFv3 or IS-IS.
   The connected prefixes have to be
   maintained over redistributed. If DHCP-PD is used,
   with every delegated prefix a significant portion of static route is installed by the network. The layer two
   domains can be terminated at Edge
   Router. For this reason the ER in three ways:

   A. In a common bridge group with a virtual interface that static routes it
   out.

   B. Enable a Routed Bridged Encapsulation feature, all users could must also be
   part of the same subnet. This is the most common deployment type of
   IPv4 over DSL but it might not redistributed.
   Prefix summarization should be the best choice in IPv6 where
   address availability is not an issue.

   C. Terminate the PVC done at Layer 3, each PVC has its own prefix. This is
   the approach that seems more suitable for IPv6 and presented in 7.2.1
   In none of these cases the CPE (DSL Modem) has to be upgraded.

   2. Edge Router.

7.2.2 PPP Terminated Aggregation (PTA) Model: Model

   The PTA architecture relies on PPP-based protocols (PPPoA [RFC2364]
   and PPPoE [RFC2516]). The PPP sessions are opened
   between each subscriber initiated by Customer
   Premise Equipment and are terminated at the BRAS. The BRAS terminates
   authorizes the PPP
   sessions session, authenticates the subscriber, and provides
   an IP address on behalf of the ISP. The BRAS then does Layer 3 connectivity between
   routing of the subscriber
   and traffic to the ISP. NSP Edge Router. This model
   is presented in section 7.2.2.

   3. L2TP Access Aggregation (LAA) Model: PPP sessions are opened
   between each subscriber and often used when the ISP NSP is also the NAP.

   There are two types of PPP encapsulations that can be leveraged with
   this model:

   A. Connection using PPPoA

  Customer Premises              NAP                   NSP
<--------------------> <----------------------> <----------------->

                                                +-----------+
                                                |    AAA    |
                                        +-------+   Radius  |
                                        |       |   TACACS  |
                                        |       +-----------+
                                        |
+-----+  +-------+      +--------+ +----+-----+ +-----------+
|Hosts|--+Router +------+ DSLAM  +-+   BRAS   +-+    Edge Router.   |
+-----+  +-------+      +--------+ +----------+ |   Router  +=>Core
                                                +-----------+
             <-------------------------->
                         PPP

                            Figure 7.2.2.1

   The BRAS tunnels the
   subscriber PPP sessions to the ISP are initiated by encapsulating them into L2TPv2
   tunnels. This model is presented in section 7.2.3.

   In aggregation models the Customer Premise Equipment. The
   BRAS terminates authenticates the subscriber PVCs and
   aggregates their connections before providing access to the ISP.

   In order to maintain the deployment concepts and business models
   proven and used with existent revenue generating IPv4 services, the
   IPv6 deployment will match the IPv4 one. This approach is presented
   in sections 7.2.1-3 that describe current IPv4 over DSL broadband
   access deployments. Under certain circumstances where new service
   types against a local or service needs justify it, IPv4 and IPv6 network logical
   architectures could be different as described in section 7.2.4.

7.2.1 Point-to-Point Model

   In this scenario a remote
   database. Once the Ethernet frames session is established, the BRAS provides an
   address and maybe a DNS server to the user, information acquired from
   the Host subscriber profile or from a DHCP server.

   This solution scales better then the Customer
   Premises Router are bridged over the Point-to-Point but since there
   is only one PPP session per ATM PVC assigned to the subscriber
   [ISP Transition Scenarios].

   Figure 7.2.1 describes the protocol architecture of this model. can choose a
   single ISP service at a time.

   B. Connection using PPPoE

       Customer Premises                NAP                 NSP
<------------------------->  <---------------> <-------------------->

+-----+
<----------------------------> <-------------------> <----------------->

                                                      +-----------+
                                                      |    AAA    |
                                              +-------+   Radius  |
                                              |       |   TACACS  |
                                              |       +-----------+
                                              |
+-----+  +-------+            +--------+        +----------+ +----+-----+ +-----------+
|Hosts|--+Router +--+ DSL +--+ +------------+ DSLAM  +--------+  +-+   BRAS   +-+    Edge   |      ISP  C
+-----+  +-------+  |Modem|            +--------+ +----------+ |   Router  +==> Network
                    +-----+                    +----------+
                        <---------------------------->
                                    ATM  +=>O
                                                      |           |  R
                                                      +-----------+  E
            <-------------------------------->
                         PPP

                               Figure 7.2.1

7.2.1.1 7.2.2.2

   The operation of PPPoE is similar to PPPoA with the exception that
   with PPPoE multiple sessions can be supported over the same PVC thus
   allowing the subscriber to connect to multiple services at the same
   time. The hosts can initiate the PPPoE sessions as well. It is
   important to remember that the PPPoE encapsulation reduces the IP
   MTU available for the customer traffic due to additional headers.

   The network design and operation of the PTA model is the same
   regardless of the PPP encapsulation type used.

7.2.2.1 IPv6 Related Infrastructure Changes

   In this scenario the DSL modem and the entire NAP BRAS is Layer 3 unaware,
   so no changes are needed aware and it has to be upgraded
   to support IPv6. Since the BRAS terminates the PPP sessions it has to
   support the implementation of these PPP protocols with IPv6. The
   following devices have to be upgraded to dual stack: Host, Customer
   Router (if present) present), BRAS and Edge Router.

7.2.1.2

7.2.2.2 Addressing

   The BRAS terminates the PPP sessions and provides the subscriber with
   an IPv6 address from the defined pool for that profile. The
   subscriber profile for authorization and authentication can be
   located on the BRAS or on a AAA server. The Hosts or the Customer
   Routers have the Edge Router BRAS as their Layer 3 next hop.

   If there is no Customer Router all the hosts on the subscriber site
   belong to the same /64 subnet that is statically configured on the
   Edge Router for that subscriber PVC.

   The hosts PPP session can use stateless
   autoconfiguration be initiated by a host or stateful DHCPv6 based configuration to acquire
   an address via the Edge Router.

   If by a Customer Router is present:

   A. It is statically configured with an address on the /64 subnet
   between itself and the Edge Router, and with /64 prefixes on the
   interfaces connecting Router.
   In the hosts on latter case, once the customer site. This session is not a
   desired provisioning method being expensive and difficult to manage.

   B. It can use its link-local address to communicate established with the ER.
   It can also dynamically acquire through stateless autoconfiguration
   the address for the link between itself BRAS and the ER.  This step
   an address is
   followed by a request via DHCP-PD negotiated for a prefix shorter than /64 that
   in turn is divided in /64s and assigned to its interfaces connecting
   the hosts on the customer site.

   The Edge Router has a /64 prefix configured for each subscriber VLAN.
   Each VLAN should be enabled uplink to relay DHCPv6 requests from the
   subscribers BRAS, DHCP-PD can be
   used to DHCPv6 servers in acquire prefixes for the ISP network. Customer Router other interfaces.

   The VLANs providing
   access for subscribers that use DHCP-PD as well, have BRAS has to be enabled to support the feature. Currently the DHCP-PD functionality cannot be
   implemented if the DHCP-PD server is not and to relay the Edge Router. If
   DHCPv6 requests of the
   DHCP-PD messages are relayed, hosts on the Edge Router does not have subscriber sites.

   The BRAS has a
   mechanism to learn the assigned /64 prefixes and thus install configured on the proper
   routes to make that prefix reachable. Work is being done to address
   this issue, one idea being link to provide the Edge Router with a snooping
   mechanism.
   router. The uplink to the ISP
   network is Edge router links are also configured with a /64 prefix as well. prefixes
   to provide connectivity to the rest of the ISP network.

   The prefixes used for subscriber links and the ones delegated via DHCP-PD
   should be planned in a manner that allows as much maximum summarization as possible at
   the Edge Router. BRAS.

   Other information of interest to the host, such as DNS, is provided
   through stateful DHCPv6 [RFC3315] and stateless DHCPv6 [RFC3736].

7.2.1.3 [RFC3736] DHCPv6.

7.2.2.3 Routing

   The CPE devices are configured with a default route that points to
   the Edge BRAS router. No routing protocols are needed on these devices
   which do generally have limited resources.

   The Edge Router BRAS runs the IPv6 an IGP used in to the NSP: Edge Router: OSPFv3 or IS-IS.
   The Since the
   addresses assigned to the PPP sessions are represented as connected

   host routes, connected prefixes have to be redistributed. If DHCP-PD
   is used, with every delegated prefix a static route is installed by
   the Edge Router. For this reason the static routes must also be
   redistributed. Prefix summarization should be done at the Edge Router.

7.2.2 PPP Terminated Aggregation (PTA) Model

   The PTA architecture relies on PPP-based protocols (PPPoA [RFC2364]
   and PPPoE [RFC2516]). The PPP sessions are initiated by Customer
   Premise Equipment and are terminated at the BRAS.

   The BRAS
   authorizes Edge Router is running the session, authenticates IGP used in the subscriber, and provides

   an IP address on behalf ISP network: OSPFv3
   or IS-IS.

   A separation between the routing domains of the ISP. The ISP and the Access
   Provider is recommended if they are managed independently. Controlled
   redistribution will be needed between the Access Provider IGP and the
   ISP IGP.

7.2.3 L2TPv2 Access Aggregation (LAA) Model

   In the LAA model the BRAS then does Layer 3
   routing of forwards the subscriber traffic CPE initiated session to
   the NSP ISP over an L2TPv2 tunnel established between the BRAS and the
   Edge Router. This model
   is often used when In this case the NSP is also authentication, authorization and
   subscriber configuration are performed by the NAP
   [ISP Transition Scenarios]. ISP itself. There
   are two types of PPP encapsulations that can be leveraged with
   this model:

   A. Connection using via PPPoA

  Customer Premises              NAP                   NSP
<--------------------> <----------------------> <----------------->

                                                +-----------+
                                                |    AAA    |
                                        +-------+   Radius  |
                                        |       |   TACACS  |
                                        |       +-----------+       +-----+-----+
                                        |             |
+-----+  +-------+      +--------+ +----+-----+ +-----------+ +-----+-----+
|Hosts|--+Router +------+ DSLAM  +-+  BRAS    +-+   Edge    |
+-----+  +-------+      +--------+ +----------+ |  Router   +=>Core
                                                +-----------+
             <-------------------------->
             <---------------------------------------->
                                PPP
                                         <------------>
                                              L2TPv2
                        Figure 7.2.2.1

   The PPP sessions are initiated by the Customer Premise Equipment. The
   BRAS authenticates the subscriber against a local or a remote
   database. Once the session is established, the BRAS provides an
   address and maybe a DNS server to the user, information acquired from
   the subscriber profile or from a DHCP server.

   This solution scales better then the Point-to-Point but since there
   is only one PPP session per ATM PVC the subscriber can choose a
   single ISP service at a time. 7.2.3.1

   B. Connection using via PPPoE

      Customer Premises                NAP                   NSP
<----------------------------> <------------------->
<---------------------------> <--------------------> <----------------->
                                                     +-----------+
                                                     |    AAA    |
                                              +-------+
                                              +------+   Radius  |
                                              |      |   TACACS  |
                                              |       +-----------+      +-----+-----+
                                              |            |
+-----+  +-------+            +--------+ +----+-----+ +-----------+ +----+------+
|Hosts|--+Router +------------+ DSLAM  +-+   BRAS   +-+    Edge   |  C
+-----+  +-------+            +--------+ +----------+ |   Router  +=>O
                                                      |           |  R
                                                      +-----------+  E
            <-------------------------------->
                         PPP

                               Figure 7.2.2.2

   The operation of PPPoE is similar to PPPoA with the exception that
   with PPPoE multiple sessions can be supported over the same PVC thus
   allowing the subscriber to connect to multiple services at the same
   time. The hosts can initiate the PPPoE sessions as well. It is
   important to remember that the PPPoE encapsulation reduces the IP
   MTU available for the customer traffic due to additional headers
   [ISP Transition Scenarios].  +-+  BRAS    +-+    Edge   |  C
+-----+  +-------+            +--------+ +----------+ |   Router  +=>O
                                                      |           |  R
                                                      +-----------+  E
            <----------------------------------------------->
                                    PPP
                                             <-------------->
                                                   L2TPv2

                          Figure 7.2.3.2

   The network design and operation of the PTA model is the same
   regardless of the PPP encapsulation type used.

7.2.2.1

7.2.3.1 IPv6 Related Infrastructure Changes

   In this scenario the BRAS is Layer 3 aware and it has to be upgraded
   to support IPv6. Since the BRAS terminates the PPP sessions it has to
   support the implementation of these PPP protocols with IPv6. The
   following devices have to be upgraded to dual stack: Host, Customer
   Router (if present), BRAS and Edge Router.

7.2.2.2 Addressing

   The BRAS terminates forwarding the PPP sessions and provides the subscriber with
   an IPv6 address from the defined pool for that profile. The
   subscriber profile for authorization and authentication can be
   located on the BRAS or on a AAA server. The Hosts or the Customer
   Routers have the BRAS as their Layer 3 next hop.

   The PPP session can be initiated
   by a host or by a Customer Router.
   In the latter case, once the session is established with the BRAS and
   an address is negotiated for the uplink to the BRAS, DHCP-PD can be
   used to acquire prefixes for the Customer Router other interfaces.

   The BRAS has to be enabled to support DHCP-PD and to relay the
   DHCPv6 requests of the hosts on the subscriber sites.

   The BRAS has a /64 prefixes configured on the link to the Edge
   router. The Edge router links are also configured with /64 prefixes
   to provide connectivity to the rest of the ISP network.

   The prefixes used for subscriber and the ones delegated via DHCP-PD
   should be planned in a manner that allows maximum summarization at the BRAS.

   Other information of interest to subscriber over the host, such as DNS, is provided
   through stateful [RFC3315] and stateless [RFC3736] DHCPv6.

7.2.2.3 Routing

   The CPE devices are configured with a default route that points L2TPv2 tunnel established to the BRAS router. No routing protocols are needed on these devices
   which have limited resources. LNS, the
   aggregation point in the ISP network. The BRAS runs an IGP to L2TPv2 tunnel between the Edge Router: OSPFv3
   LAC and LNS could run over IPv6 or IS-IS. Since the
   addresses assigned IPv4. These capabilities
   have to be supported on the PPP sessions are represented as connected

   host routes, connected prefixes BRAS. The following devices have to be redistributed. If DHCP-PD
   is used, with every delegated prefix a static route is installed by
   the
   upgraded to dual stack: Host, Customer Router and Edge Router. For this reason If
   the static routes tunnel is set up over IPv6 then the BRAS must also be
   redistributed. Prefix summarization should be done at the BRAS. upgraded to
   dual stack.

7.2.3.2 Addressing

   The Edge Router is running router terminates the IGP used in PPP sessions and provides the ISP network: OSPFv3
   subscriber with an IPv6 address from the defined pool for that
   profile. The subscriber profile for authorization and authentication
   can be located on the Edge Router or on a AAA server. The Hosts or IS-IS.

   A separation between
   the routing domains of Customer Routers have the ISP and Edge Router as their Layer 3 next hop.

   The PPP session can be initiated by a host or by a Customer Router.
   In the Access
   Provider is recommended if they are managed independently. Controlled
   redistribution will latter case, once the session is established with the Edge
   Router, DHCP-PD can be needed between used to acquire prefixes for the Access Provider IGP Customer
   Router interfaces. The Edge Router has to be enabled to support
   DHCP-PD and to relay the
   ISP IGP.

7.2.3 L2TPv2 Access Aggregation (LAA) Model

   In DHCPv6 requests generated by the LAA model hosts on
   the subscriber sites.

   The BRAS forwards has a /64 prefix configured on the CPE initiated session link to the ISP over an L2TPv2 tunnel established between Edge router.
   The Edge router links are also configured with /64 prefixes to
   provide connectivity to the BRAS and rest of the
   Edge Router. In this case ISP network. Other
   information of interest to the authentication, authorization host, such as DNS, is provided
   through stateful [RFC3315] and
   subscriber configuration are performed by stateless [RFC3736] DHCPv6.

   It is important to note here a significant difference between this
   deployment for IPv6 versus IPv4. In the ISP itself
   [ISP Transitions Scenarios]. There are two types case of PPP
   encapsulations that IPv4 the customer
   router or CPE can be leveraged with this model:

   A. Connection via PPPoA

  Customer Premises              NAP                   NSP
<--------------------> <----------------------> <----------------->

                                                +-----------+
                                                |    AAA    |
                                        +-------+   Radius  |
                                        |       |   TACACS  |
                                        |       +-----+-----+
                                        |             |
+-----+  +-------+      +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM  +-+  BRAS    +-+   Edge    |
+-----+  +-------+      +--------+ +----------+ |  Router   +=>Core
                                                +-----------+
             <---------------------------------------->
                                PPP
                                         <------------>
                                              L2TPv2
                        Figure 7.2.3.1

   B. Connection via PPPoE

      Customer Premises                NAP                   NSP
<---------------------------> <--------------------> <----------------->
                                                     +-----------+
                                                     |    AAA    |
                                              +------+   Radius  |
                                              |      |   TACACS  |
                                              |      +-----+-----+
                                              |            |
+-----+  +-------+            +--------+ +----+-----+ +----+------+
|Hosts|--+Router +------------+ DSLAM  +-+  BRAS    +-+ end up on any Edge   |  C
+-----+  +-------+            +--------+ +----------+ | Router  +=>O
                                                      |           |  R
                                                      +-----------+  E
            <----------------------------------------------->
                                    PPP
                                             <-------------->
                                                   L2TPv2

                          Figure 7.2.3.2

   The network design and operation of (acting as LNS) where the PTA model
   assumption is that there are at least two of them for redundancy
   purposes. Once authenticated, the same
   regardless customer will be given an address
   from the IP pool of the PPP encapsulation type used.

7.2.3.1 IPv6 Related Infrastructure Changes ER (LNS) it connected to. This allows the ERs
   (LNSs) to aggregate the addresses handed out to the customers. In this scenario the BRAS
   case of IPv6, an important constraint that likely will be enforced is forwarding
   that the PPP sessions initiated
   by customer should keep its own address regardless of the subscriber over ER
   (LNS) it connects to. This could significantly reduce the L2TPv2 tunnel established to prefix
   aggregation capabilities of the LNS, ER (LNS). This is different than the
   aggregation point
   current IPv4 deployment where addressing is dynamic in nature and the ISP network. The L2TPv2 tunnel between
   same user can get different addresses depending on the
   LAC and LNS could run over IPv6 or IPv4. These capabilities
   have it ends up
   connecting to.

   One possible solution is to ensure that a given BRAS will always
   connect to the same ER (LNS) unless that LNS is down. This means that
   customers from a given prefix range will always be connected to the
   same ER (primary if up or secondary if not). Each ER (LNS) can carry
   summary statements in their routing protocol configuration for the
   prefixes they are the primary ER (LNS) as well as for the ones for
   which they are the secondary. This way the prefixes will be supported
   summarized any time they become "active" on the BRAS. ER (LNS).

7.2.3.3 Routing

   The following CPE devices have to be
   upgraded are configured with a default route that points to dual stack: Host, Customer Router and Edge Router. If
   the tunnel is set up over IPv6 then
   the BRAS must be upgraded to
   dual stack.

7.2.3.2 Addressing

   The Edge router that terminates the PPP sessions and provides the
   subscriber with sessions. No routing
   protocols are needed on these devices which have generally limited
   resources.

   The BRAS runs an IPv6 address from IGP to the defined pool for that
   profile. The subscriber profile for authorization Edge Router: OSPFv3 or IS-IS.
   Different processes should be used if the NAP and authentication
   can the NSP are
   managed by different organizations. In this case, controlled
   redistribution should be located on enabled between the two domains.

   The Edge Router is running the IPv6 IGP used in the ISP network:
   OSPFv3 or on a AAA server. The Hosts or IS-IS.

7.2.4 Hybrid Model for IPv4 and IPv6 Service

   It was recommended throughout this section that the Customer Routers have IPv6 service
   implementation should map the Edge Router existent IPv4 one. This approach
   simplifies manageability and minimizes training needed for personnel
   operating the network. In certain circumstances such mapping is not
   feasible. This typically becomes the case when a Service Provider
   plans to expand its service offering with the new IPv6 deployed
   infrastructure. If this new service is not well supported in a
   network design such as their Layer 3 next hop.

   The PPP session can be initiated by the one used for IPv4 then a host or by different design
   might be used for IPv6.

   An example of such circumstances is that of a Customer Router. provider using an LAA
   design for its IPv4 services. In this case all the latter case, once PPP sessions are
   bundled and tunneled across the session entire NAP infrastructure which is
   made of multiple BRAS routers, aggregation routers etc. The end point
   of these tunnels is established with the ISP Edge
   Router, DHCP-PD can be used Router. If the provider decides to acquire prefixes for
   offer multicast services over such a design, it will face the Customer
   Router interfaces. problem
   of NAP resources being over utilized. The Edge Router has to multicast traffic can be enabled to support
   DHCP-PD and to relay
   replicated only at the DHCPv6 requests generated end of the tunnels by the hosts on Edge router and the subscriber sites.

   The BRAS has a /64 prefix configured on
   copies for all the link to subscribers are carried over the Edge router.
   The Edge router links entire NAP.

   A Modified Point-to-Point (as described in 7.2.4.2) or PTA model are also configured with /64 prefixes to
   provide connectivity
   more suitable to support multicast services because the rest of the ISP network.

   Other information of interest packet
   replication can be done closer to the host, such destination at the BRAS. Such
   topology saves NAP resources.

   In this sense IPv6 deployment can be viewed as DNS, is provided
   through stateful [RFC3315] and stateless [RFC3736] DHCPv6.

   It is important an opportunity to note here a significant difference between
   build an infrastructure that might better support the expansion of
   services. In this
   deployment case, an SP using the LAA design for its IPv4
   services might choose a modified Point-to-Point or PTA design for
   IPv6.

7.2.4.1 IPv4 in LAA Model and IPv6 versus IPv4. In the case in PTA Model

   The coexistence of IPv4 the customer
   router or CPE can end up on any Edge Router (acting as LNS) where the
   assumption two PPP based models, PTA and LAA, is that there
   relatively straight forward. The PPP sessions are at least two of them terminated on
   different network devices for redundancy
   purposes. Once authenticated, the customer will be given an address
   from the IP pool of the ER (LNS) it connected to. This allows IPv4 and IPv6 services. The PPP
   sessions for the ERs
   (LNSs) to aggregate existent IPv4 service deployed in an LAA model are
   terminated on the addresses handed out to Edge Router. The PPP sessions for the customers. In new IPv6
   service deployed in a PTA model are terminated on the
   case of IPv6, an important constraint that likely will be enforced BRAS.

   The logical design for IPv6 and IPv4 in this hybrid model is
   that the customer should keep its own address regardless of
   presented in Figure 7.2.4.1.

IPv6          <-------------------------->
                         PPP                    +-----------+
                                                |    AAA    |
                                        +-------+   Radius  |
                                        |       |   TACACS  |
                                        |       +-----+-----+
                                        |             |
+-----+  +-------+      +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM  +-+  BRAS    +-+   Edge    |
+-----+  +-------+      +--------+ +----------+ |  Router   +=>Core
                                                +-----------+
IPv4          <---------------------------------------->
                                PPP
                                         <------------>
                                              L2TPv2
                              Figure 7.2.4.1

7.2.4.2 IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model

   In this particular scenario the ER
   (LNS) it connects to. This could significantly reduce Point-to-Point model used for the prefix
   aggregation capabilities
   IPv6 service is a modified version of the ER (LNS). This is different than model described in section
   7.2.1.

   For the
   current IPv4 deployment where addressing is dynamic service in nature and LAA model, the
   same user can get different addresses depending VLANs are terminated on the LNS it ends up
   connecting to.

   One possible solution is to ensure that a given
   BRAS will always
   connect to the same ER (LNS) unless that LNS is down. This means that
   customers from a given prefix range will always be connected to and PPP sessions are terminated on the
   same ER (primary if up or secondary if not). Each ER (LNS) can carry
   summary statements Edge Router (LNS). For
   IPv6 service in their routing protocol configuration for Point-to-Point model, the
   prefixes they VLANs are terminated at
   the primary ER (LNS) as well Edge Router as for the ones for
   which they are the secondary. This way described in section 7.2.1.  In this hybrid model,
   the prefixes will Point-to-Point link could be
   summarized any time they become "active" terminated on the ER (LNS).

7.2.3.3 Routing

   The CPE devices are configured with BRAS, a default route that points NAP owned
   device. The IPv6 traffic is then routed through the NAP network to
   the Edge router that terminates NSP. In order to have this hybrid model, the PPP sessions. No routing
   protocols BRAS has to be
   upgraded to a dual-stack router. The functionalities of the Edge
   Router as described in section 7.2.1 are needed now implemented on these devices which have limited resources. the BRAS.

   The other aspect of this deployment model is the fact that the BRAS runs an IPv6 IGP
   has to be capable of distinguishing between the IPv4 PPP traffic that
   has to the Edge Router: OSPFv3 or IS-IS.
   Different processes should be used if bridged across the NAP L2TPv2 tunnel and the NSP are managed
   by different organizations. In this case, controlled redistribution
   should IPv6 packets that
   have to be enabled between routed to the two domains. NSP. The Edge Router is running the IPv6 IGP used in the ISP network:
   OSPFv3 or IS-IS.

7.2.4 Hybrid Model for Routing and Bridging
   Encapsulation (RBE) has to be enabled on all interfaces with VLANs
   supporting both IPv4 and IPv6 Service

   It was recommended throughout services in this section that the hybrid design.

   The logical design for IPv6 service
   implementation should map the existent IPv4 one. This approach
   simplifies manageability and minimizes training needed for personnel
   operating the network. In certain circumstances such mapping IPv4 in this hybrid model is not
   feasible. This typically becomes the case when a Service Provider
   plans
   presented in Figure 7.2.4.2.

IPv6              <---------------->
                         ATM                    +-----------+
                                                |    AAA    |
                                        +-------+   Radius  |
                                        |       |   TACACS  |
                                        |       +-----+-----+
                                        |             |
+-----+  +-------+      +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM  +-+  BRAS    +-+   Edge    |
+-----+  +-------+      +--------+ +----------+ |  Router   +=>Core
                                                +-----------+
IPv4          <---------------------------------------->
                                PPP
                                         <------------>
                                              L2TPv2
                              Figure 7.2.4.2

7.3 IPv6 Multicast

   The deployment of IPv6 multicast services relies on MLD, identical to expand its
   IGMP in IPv4 and on PIM for routing. ASM (Any Source Multicast) and
   SSM (Single Source Multicast) service offering with models operate almost the new IPv6 deployed
   infrastructure. If this new service is not well supported same
   as in a
   network design such IPv4. Both have the same benefits and disadvantages as in IPv4.
   Nevertheless, the larger address space and the one used for IPv4 then a different design
   might be used scoped address
   architecture provide major benefits for multicast IPv6.

   An example of such circumstances is Through
   RFC3306 the large address space provides the means to assign global
   multicast group addresses to organizations or users that of were
   assigned unicast prefixes. It is a provider using an LAA
   design for its IPv4 services. In this case all significant improvement with
   respect to the PPP sessions are
   bundled and tunneled across IPv4 GLOP mechanism [RFC2770].

   This facilitates the entire NAP infrastructure which is
   made deployment of multiple BRAS routers, aggregation routers etc. multicast services. The end point
   discussion of these tunnels is this section applies to all the ISP Edge Router. If multicast sections
   in the provider decides document.

7.3.1 ASM Based Deployments

   Any Source Multicast (ASM) is useful for Service Providers that
   intend to
   offer multicast services over such a design, it will face support the problem forwarding of NAP resources being over utilized. The multicast traffic can be
   replicated only at the end of their
   customers. It is based on the tunnels by the Edge router PIM-SM protocol and the
   copies for all the subscribers are carried over the entire NAP.

   A Modified Point-to-Point (as described in 7.2.4.2) or PTA model are it is more suitable complex
   to support multicast services manage because of the packet
   replication use of Rendezvous Points (RPs). With IPv6,
   static RP and BSR [BSR] can be done closer used for RP-to-group mapping similar
   to IPv4. Additionally, the destination at the BRAS. Such
   topology saves NAP resources.

   In this sense larger IPv6 deployment can be viewed as an opportunity to
   build an infrastructure address space allows for
   building up of group addresses that might better support incorporate the expansion address of
   services. the
   RP. This RP-to-group mapping mechanism is called Embedded RP and is
   specific to IPv6.

   In this case, inter-domain deployments, Multicast Source Discovery Protocol
   (MSDP) [RFC3618] is an SP using the LAA design for its important element of IPv4
   services might choose PIM-SM deployments.
   MSDP is meant to be a modified Point-to-Point or PTA design solution for
   IPv6.

7.2.4.1 IPv4 the exchange of source
   registration information between RPs in different domains. This
   solution was intended to be temporary. This is one of the reasons
   why it was decided not to implement MSDP in LAA Model and IPv6 [IPv6 Multicast].

   For multicast reachability across domains, Embedded RP could be
   used. Despite its shortcomings, MSDP provides additional
   flexibility in PTA Model managing the domains that may not be matched with
   the protocols available in IPv6 today. The coexistence value of the two PPP based models, PTA and LAA, such
   flexibility is
   relatively straight forward. The PPP sessions are terminated still under evaluation.

7.3.2 SSM Based Deployments

   Based on
   different network devices for PIM-SSM, the IPv4 Source Specific Multicast deployments do not
   need an RP and IPv6 services. The PPP
   sessions for the existent IPv4 service deployed in an LAA model are
   terminated related protocols (such as BSR or MSDP) but rely
   on the Edge Router. The PPP sessions for listeners to know the new IPv6
   service deployed in source of the multicast traffic
   they plan to receive. The lack of RP makes SSM not only simpler to
   operate but also robust, it is not impacted by RP failures or inter
   domain constraints. It is also has a PTA model are terminated higher level of security (No RP
   to be targeted by attacks). For more discussions on the BRAS. topic of
   IPv6 multicast see [IPv6 Multicast].

   The logical design typical multicast services offered for IPv6 residential and IPv4 in this hybrid model very
   small businesses is
   presented in Figure 7.2.4.1.

IPv6          <-------------------------->
                         PPP                    +-----------+
                                                |    AAA    |
                                        +-------+   Radius  |
                                        |       |   TACACS  |
                                        |       +-----+-----+
                                        |             |
+-----+  +-------+      +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM  +-+  BRAS    +-+   Edge    |
+-----+  +-------+      +--------+ +----------+ |  Router   +=>Core
                                                +-----------+
IPv4          <---------------------------------------->
                                PPP
                                         <------------>
                                              L2TPv2
                              Figure 7.2.4.1

7.2.4.2 IPv4 in LAA Model video/audio streaming where the subscriber joins
   a multicast group and IPv6 in Modified Point-to-Point Model

   In this particular scenario receives the Point-to-Point content. This type of service
   model used for is well supported through PIM-SSM which is very simple and
   easy to manage. PIM-SSM has to be enabled throughout the
   IPv6 service SP network.
   MLDv2 is required for PIM-SSM support. Vendors can choose to
   implement features that allow routers to map MLDv1 group joins to
   predefined sources.

   Subscribers might use a modified version of the model described in section
   7.2.1.

   For the IPv4 service in LAA model, the VLANs are terminated on set-top box that is responsible for the
   BRAS and PPP sessions are terminated on
   control piece of the Edge Router (LNS). For
   IPv6 multicast service in Point-to-Point model, the VLANs are terminated at
   the Edge Router as described in section 7.2.1.  In this hybrid model,
   the Point-to-Point link could be terminated on the BRAS, (does group joins/leaves).
   The subscriber hosts can also join desired multicast groups as long
   as they are enabled to support MLDv1 or MLDv2. If a NAP owned
   device. The IPv6 traffic customer premise
   router is used then routed through the NAP network it has to
   the NSP. In be enabled to support MLDv1 and MLDv2
   in order to have this hybrid model, process the BRAS requests of the hosts. It has to be
   upgraded enabled
   to a dual-stack router. The functionalities of 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 as described in section 7.2.1 are now implemented router. When
   enabling this functionality on a customer premises router, its
   limited resources should be taken into consideration. Another option
   would be for the BRAS. customer premises router to support MLD proxy
   routing.

   The other aspect of this deployment model router that is the fact that Layer 3 next hop for the BRAS subscriber (BRAS in
   the PTA model or the Edge router in the LAA and Point-to-Point
   model) has to be capable of distinguishing between enabled to support MLDv1 and MLDv2 in order to
   process the IPv4 PPP traffic that requests coming from subscribers without customer
   premises routers. It has to be bridged across enabled for PIM-SSM in order to
   receive joins/leaves from customer routers and send joins/leaves
   to the L2TPv2 tunnel next hop towards the multicast source (Edge router or the
   NSP core).

   MLD authentication, authorization and accounting is usually
   configured on the IPv6 packets that
   have to be routed edge router in order to enable the NSP. The IPv6 Routing and Bridging
   Encapsulation (RBE) has ISP to be enabled on all interfaces with VLANs
   supporting both IPv4 do
   control the subscriber access of the service and do billing for the
   content provided. Alternative mechanisms that would support these
   functions should be investigated further.

7.4 IPv6 services in this hybrid design. QoS

   The logical design QoS configuration is particularly relevant on the router that
   represents the Layer 3 next hop for IPv6 and IPv4 the subscriber (BRAS in this hybrid the PTA
   model is
   presented in Figure 7.2.4.2.

IPv6              <---------------->
                         ATM                    +-----------+
                                                |    AAA    |
                                        +-------+   Radius  |
                                        |       |   TACACS  |
                                        |       +-----+-----+
                                        |             |
+-----+  +-------+      +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM  +-+  BRAS    +-+ or the Edge    |
+-----+  +-------+      +--------+ +----------+ |  Router   +=>Core
                                                +-----------+
IPv4          <---------------------------------------->
                                PPP
                                         <------------>
                                              L2TPv2
                              Figure 7.2.4.2

7.3 IPv6 Multicast

   The deployment of IPv6 multicast services relies on MLD, identical to
   IGMP router in IPv4 and on PIM for routing. ASM (Any Source Multicast) and
   SSM (Single Source Multicast) service models operate almost the same
   as LAA and Point-to-Point model) in IPv4. Both have
   order to manage resources shared amongst multiple subscribers
   possibly with various service level agreements.

   In the same benefits DSL infrastructure it is expected that there is already a
   level of traffic policing and disadvantages as in IPv4.
   Nevertheless, shaping implemented for IPv4
   connectivity. This is implemented throughout the larger address space NAP and it is
   beyond the scoped address
   architecture provide major benefits for multicast IPv6. Through
   RFC3306 scope of this document.

   On the large address space provides BRAS or the means Edge Router the subscriber facing interfaces have
   to assign global
   multicast group addresses be configure to organizations or users that were
   assigned unicast prefixes. It is a significant improvement with
   respect police the inbound customer traffic and shape the
   traffic outbound to the IPv4 GLOP mechanism [RFC2770].

   This facilitates customer based on the deployment of multicast services. The
   discussion of this section applies SLAs. Traffic
   classification and marking should also be done on the router closest
   (at Layer 3) to all the multicast sections subscriber in the document.

7.3.1 ASM Based Deployments

   Any Source Multicast (ASM) is useful for Service Providers that
   intend order to support the forwarding of multicast traffic various types
   of their
   customers. It is based on the PIM-SM protocol customer traffic: data, voice, video and it is more complex to manage because of the optimally use of Rendezvous Points (RPs). With IPv6,
   static RP the
   infrastructure resources. Each provider (NAP, NSP) could implement
   their own QoS policies and BSR [BSR] can services so reclassification and marking
   might be used for RP-to-group mapping similar
   to IPv4. Additionally, performed at the larger IPv6 address space allows for
   building up of group addresses that incorporate boundary between the address of NAP and the
   RP. This RP-to-group mapping mechanism NSP in
   order to make sure the traffic is called Embedded RP properly handled by the ISP. The
   same IPv4 QoS concepts and methodologies should be applied with IPv6
   as well.

   It is
   specific important to IPv6.

   In inter-domain deployments, Multicast Source Discovery Protocol
   (MSDP) [RFC3618] note that when traffic is an important element encrypted end-to-end,
   the traversed network devices will not have access to many of IPv4 PIM-SM deployments.
   MSDP is meant the
   packet fields used for classification purposes. In these cases
   routers will most likely place the packets in the default classes.
   The QoS design should take into consideration this scenario and try
   to use mainly IP header fields for classification purposes.

7.5 IPv6 Security Considerations

   There are limited changes that have to be a solution done for the exchange of source
   registration information between RPs CPEs in different domains. This
   solution was intended order to
   enhance security. The Privacy extensions for auto-configuration
   [RFC3041] should be temporary. This is one of used by the reasons
   why hosts. ISPs can track the prefixes
   it was decided not assigns to implement MSDP in IPv6 [IPv6 Multicast].

   For multicast reachability across domains, Embedded RP could be
   used. Despite its shortcomings, MSDP provides additional
   flexibility in managing subscribers relatively easily. If however the domains that may not ISPs are
   required by regulations to track their users at /128 address level,
   the Privacy Extensions can be matched implemented only in parallel with
   network management tools that could provide traceability of the protocols available in
   hosts. IPv6 today. The value of such
   flexibility is still under evaluation.

7.3.2 SSM Based Deployments

   Based firewall functions should be enabled on PIM-SSM, the Source Specific Multicast deployments do not
   need an RP and the related protocols (such as BSR hosts or MSDP) but rely
   on the listeners to know the source of the multicast traffic
   they plan to receive.
   customer premises router if present.

   The lack of RP makes SSM not only simpler to
   operate ISP provides security against attacks that come form its own
   subscribers but also robust, it is not impacted by RP failures or inter
   domain constraints. It is could also has a higher implement security services that
   protect its subscribers from attacks sourced from the outside of its
   network. Such services do not apply at the access level of security (No RP
   to be targeted the
   network discussed here.

   The device that is the Layer 3 next hop for the subscribers (BRAS or
   Edge router) should protect the network and the other subscribers
   against attacks by attacks). one of the provider customers. For more discussions this reason
   uRPF and ACLs should be used on all interfaces facing subscribers.
   Filtering should be implemented with regard for the topic operational
   requirements of IPv6 multicast see [IPv6 Multicast].

   The typical multicast services offered [Security considerations for residential IPv6].
   Authentication and very
   small businesses is video/audio streaming where the subscriber joins
   a multicast group authorization should be used wherever possible.

   The BRAS and receives the content. This type Edge Router should protect their processing
   resources against floods of service
   model is well supported through PIM-SSM which is very simple valid customer control traffic such as:
   Router and
   easy to manage. PIM-SSM has to Neighbor Solicitations, MLD Requests. Rate limiting
   should be enabled throughout the SP network.
   MLDv2 implemented on all subscriber facing interfaces. The
   emphasis should be placed on multicast type traffic as it is required for PIM-SSM support. Vendors can choose to
   implement most
   often used by the IPv6 control plane.

   All other security features that allow routers to map MLDv1 group joins used with the IPv4 service should be
   similarly applied to
   predefined sources.

   Subscribers might use a set-top box that is responsible IPv6 as well.

7.6 IPv6 Network management

   The necessary instrumentation (such as MIBs, NetFlow Records etc)
   should be available for IPv6.

   Usually, NSPs manage the edge routers by SNMP. The SNMP transport
   can be done over IPv4 if all managed devices have connectivity over
   both IPv4 and IPv6. This would imply the
   control piece of smallest changes to the multicast service (does group joins/leaves).
   The subscriber hosts can
   existent network management practices and processes. Transport over
   IPv6 could also join desired multicast groups as long
   as they are enabled to support MLDv1 or MLDv2. If a customer premise
   router is used then it has to be enabled to support MLDv1 implemented and MLDv2 it might become necessary if IPv6
   only islands are present in order to process the requests of network. The management stations are
   located on the hosts. It has to be enabled
   to support PIM-SSM core network. Network Management Applications should
   handle IPv6 in order a similar fashion to send PIM joins/leaves up IPv4, however, they should also
   support features specific to its
   Layer 3 next hop whether it is the BRAS or the Edge router. When
   enabling this functionality IPv6 (such as Neighbor monitoring).

   In some cases service providers manage equipment located on a customer premises router, its
   limited resources should be taken into consideration.
   customers LANs. The router that management of equipment at customers' LANs is
   out of scope of this memo.

8. Broadband Ethernet Networks

   This section describes the Layer 3 next hop for the subscriber (BRAS IPv6 deployment options in currently
   deployed Broadband Ethernet Access Networks.

8.1 Ethernet Access Network Elements

   In environments that support the PTA model infrastructure deploying RJ-45 or
   fiber (Fiber to the Edge router in the LAA and Point-to-Point
   model) has Home (FTTH) service) to subscribers, 10/100
   Mbps Ethernet broadband services can be enabled to support MLDv1 and MLDv2 provided. Such services are
   generally available in metropolitan areas, in order to
   process the requests coming from subscribers without customer
   premises routers. It has to multi tenant buildings
   where an Ethernet infrastructure can be enabled for PIM-SSM deployed in order a cost effective
   manner. In such environments Metro-Ethernet services can be used to
   receive joins/leaves from customer routers
   provide aggregation and send joins/leaves uplink to the next hop towards the multicast source (Edge router or the
   NSP core).

   MLD authentication, authorization and accounting a Service Provider.

   The following network elements are typical of an Ethernet network:

   Access Switch: It is usually
   configured on the edge router in order to enable the ISP to do
   control the subscriber used as a Layer 2 access of the service and do billing device for the
   content provided. Alternative mechanisms that would support these
   functions should be investigated further.

7.4 IPv6 QoS

   The QoS configuration subscribers.

   Customer Premises Router: It is particularly relevant on the router that
   represents the used to provide Layer 3 next hop services
   for the subscriber (BRAS in the PTA
   model or the customer premises networks.

   Aggregation Ethernet Switches: Aggregates multiple subscribers.

   Broadband Remote Access Server (BRAS)

   Edge router in Router (ER)

   Figure 8.1 depicts all the LAA network elements mentioned.

Customer Premises | Network Access Provider | Network Service Provider
       CP                     NAP                        NSP

+-----+  +------+                 +------+   +--------+
|Hosts|--|Router|               +-+ BRAS +---+ Edge   |       ISP
+-----+  +--+---+               | |      |   | Router +===> Network
            |                   | +------+   +--------+
         +--+-----+             |
         |Access  +-+           |
         |Switch  | |           |
         +--------+ |  +------+ |
                    +--+Agg E | |
         +--------+    |Switch+-+
+-----+  |Access  | +--+      |
|Hosts|--+Switch  +-+  +------+
+-----+  +--------+
                                 Figure 8.1

   The logical topology and Point-to-Point model) in
   order design of Broadband Ethernet Networks is
   very similar to manage resources shared amongst multiple subscribers
   possibly with various service level agreements.

   In the DSL infrastructure it Broadband Networks discussed in section 7.

   It is expected worth noting that there is already a
   level of traffic policing and shaping implemented for IPv4
   connectivity. This is implemented throughout the NAP general operation, concepts and it is
   beyond the scope of
   recommendations described in this document.

   On the BRAS or the Edge Router the subscriber facing interfaces have section apply similarly to a
   HomePNA based network environment. In such an environment some
   of the network elements might be configure differently named.

8.2 Deploying IPv6 in IPv4 Broadband Ethernet Networks

   There are three main design approaches to police the inbound customer traffic and shape the
   traffic outbound providing IPv4
   connectivity over an Ethernet infrastructure:

   A. Point-to-Point Model: Each subscriber connects to the customer based network
   Access switch over RJ-45 or fiber links. Each subscriber is assigned
   a unique VLAN on the SLAs. Traffic
   classification and marking should also access switch. The VLAN can be done on the router closest
   (at Layer 3) to terminated at
   the subscriber in order to support BRAS or at the various types
   of customer traffic: data, voice, video and Edge Router. The VLANs are 802.1q trunked to optimally use the
   infrastructure resources. Each provider (NAP, NSP) could implement
   their own QoS policies and services so reclassification
   Layer 3 device (BRAS or Edge Router).

   This model is presented in section 8.2.1.

   B. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened
   between each subscriber and marking
   might be performed at the boundary BRAS. The BRAS terminates the PPP
   sessions and provides Layer 3 connectivity between the NAP subscriber
   and the NSP ISP.

   This model is presented in
   order section 8.2.2.

   C. L2TPv2 Access Aggregation (LAA) Model: PPP sessions are opened
   between each subscriber and the ISP termination devices. The BRAS
   tunnels the subscriber PPP sessions to make sure the traffic is properly handled ISP by encapsulating them
   into L2TPv2 tunnels.

   This model is presented in section 8.2.3.

   In aggregation models the BRAS terminates the subscriber VLANs and
   aggregates their connections before providing access to the ISP.

   The same IPv4 QoS

   In order to maintain the deployment concepts and methodologies should be applied business models
   proven and used with existent revenue generating IPv4 services, the
   IPv6 as well.

   It deployment will match the IPv4 one. This approach is important to note presented
   in sections 8.2.1-3 that when traffic is encrypted end-to-end,
   the traversed network devices will not have describes currently deployed IPv4 over
   Ethernet broadband access to many of the
   packet fields used for classification purposes. deployments. Under certain circumstances
   where new service types or service needs justify it, IPv4 and IPv6
   network architectures could be different as described in section
   8.2.4.

8.2.1 Point-to-Point Model

   In these cases routers
   will most likely place this scenario the packets in Ethernet frames from the default classes. The QoS
   design should take into consideration Host or the Customer
   Premises Router are bridged over the VLAN assigned to the subscriber.

Figure 8.2.1 describes the protocol architecture of this model.

     Customer Premises              NAP                 NSP
<------------------------->  <---------------> <-------------------->

+-----+  +------+  +------+  +--------+        +----------+
|Hosts|--+Router+--+Access+--+ Switch +--------+   Edge   |      ISP
+-----+  +------+  |Switch|  +--------+ 802.1q |  Router  +==> Network
                   +------+                    +----------+

                       <---------------------------->
                               Ethernet/VLANs

                                Figure 8.2.1

8.2.1.1 IPv6 Related Infrastructure Changes

   In this scenario the Access Switch on the customer site and try to use mainly
   IP header fields for classification purposes.

7.5 IPv6 Security Considerations

   There are limited the
   entire NAP is Layer 3 unaware so no changes that are needed to support
   IPv6. The following devices have to be done for CPEs in order upgraded to
   enhance security. dual stack: Host,
   Customer Router and Edge Router.

   The Privacy extensions for auto-configuration
   [RFC3041] should be used by the hosts. ISPs can track the prefixes
   it assigns to subscribers relatively easily. If however the ISPs are
   required by regulations Access switches might need upgrades to track their users at /128 address level, support certain IPv6
   related features such as MLD Snooping.

8.2.1.2 Addressing

   The Hosts or the Privacy Extensions can be implemented only in parallel with
   network management tools that could provide traceability of Customer Routers have the
   hosts. IPv6 firewall functions should be enabled on Edge Router as their
   Layer 3 next hop. If there is no Customer Router all the hosts or
   customer premises router if present.

   The ISP provides security against attacks that come form its own
   subscribers but it could also implement security services that
   protect its subscribers from attacks sourced from the outside of its
   network. Such services do not apply at on

   the access level of subscriber site belong to the
   network discussed here.

   The device same /64 subnet that is
   statically configured on the Layer 3 next hop Edge Router for that subscriber VLAN.
   The hosts can use stateless autoconfiguration or stateful DHCPv6
   based configuration to acquire an address via the subscribers (BRAS or Edge router) should protect Router.

   If a Customer Router is present:

   A. It is statically configured with an address on the network /64 subnet
   between itself and the other subscribers
   against attacks by one of the provider customers. For this reason
   uRPF Edge Router, and ACLs should be used with /64 prefixes on all the
   interfaces facing subscribers.
   Filtering should be implemented connecting the hosts on the customer site. This is not
   a desired provisioning method being expensive and difficult to
   manage.

   B. It can use its link-local address to communicate with regard the ER.
   It can also dynamically acquire through stateless autoconfiguration
   the address for the operational
   requirements of IPv6 (ICMPv6 types). Authentication and authorization
   should be used wherever possible.

   The BRAS link between itself and the Edge Router should protect their processing
   resources against floods of valid customer control traffic such as:
   Router and Neighbor Solicitations, MLD Requests. Rate limiting
   should be implemented on all subscriber facing interfaces. The
   emphasis should be placed on multicast type traffic as it ER.  This step is most
   often used
   followed by a request via DHCP-PD for a prefix shorter than /64 that
   in turn is divided in /64s and assigned to its interfaces connecting
   the IPv6 control plane.

   All other security features used with hosts on the IPv4 service should be
   similarly applied to IPv6 as well.

7.6 IPv6 Network management customer site.

   The necessary instrumentation (such as MIBs, NetFlow Records etc) Edge Router has a /64 prefix configured for each subscriber VLAN.
   Each VLAN should be available for IPv6.

   Usually, NSPs manage enabled to relay DHCPv6 requests from the
   subscribers to DHCPv6 servers in the edge routers by SNMP. ISP network. The SNMP transport
   can be done over IPv4 if all managed devices VLANs
   providing access for subscribers that use DHCP-PD as well, have connectivity over
   both IPv4 and IPv6. This would imply the smallest changes to
   be enabled to support the
   existent network management practices and processes. Transport over
   IPv6 could also feature. Currently the DHCP-PD
   functionality cannot be implemented and it might become necessary if IPv6
   only islands are present in the network. The management stations DHCP-PD server is not the
   Edge Router. If the DHCP-PD messages are
   located on relayed, the core network. Network Management Applications should
   handle IPv6 in Edge Router
   does not have a similar fashion to IPv4, however, they should also
   support features specific mechanism to IPv6 (such as Neighbor monitoring).

   In some cases service providers manage equipment located on
   customers LANs. The management of equipment at customers' LANs is
   out of scope of this memo.

8. Broadband Ethernet Networks

   This section describes learn the IPv6 deployment options in currently
   deployed Broadband Ethernet Access Networks.

8.1 Ethernet Access Network Elements

   In environments that support assigned prefixes and thus
   install the infrastructure deploying RJ-45 or
   fiber (Fiber proper routes to the Home (FTTH) service) make that prefix reachable. Work is
   being done to subscribers, 10/100
   Mbps Ethernet broadband services can be provided. Such services are
   generally available in metropolitan areas, in multi tenant buildings
   where an Ethernet infrastructure can be deployed in a cost effective
   manner. In such environments Metro-Ethernet services can be used address this issue, one idea being to provide aggregation and the Edge
   Router with a snooping mechanism. The uplink to the ISP network is
   configured with a Service Provider. /64 prefix as well. The following network elements are typical of an Ethernet uplink to the ISP network
   [ISP Transition Scenarios]:

   Access Switch: It
   is used as configured with a Layer 2 access device for subscribers.

   Customer Premises Router: It is /64 prefix as well.

   The prefixes used to provide Layer 3 services for customer premises networks.

   Aggregation Ethernet Switches: Aggregates multiple subscribers.

   Broadband Remote Access Server (BRAS)

   Edge Router (ER)

   Figure 8.1 depicts all subscriber links and the ones delegated via
   DHCP-PD should be planned in a manner that allows as much
   summarization as possible at the network elements mentioned.

Customer Premises | Network Access Provider | Network Service Provider
       CP                     NAP                        NSP

+-----+  +------+                 +------+   +--------+
|Hosts|--|Router|               +-+ BRAS +---+ Edge   |       ISP
+-----+  +--+---+               | |      |   | Router +===> Network
            |                   | +------+   +--------+
         +--+-----+             |
         |Access  +-+           |
         |Switch  | |           |
         +--------+ |  +------+ |
                    +--+Agg E | |
         +--------+    |Switch+-+
+-----+  |Access  | +--+      |
|Hosts|--+Switch  +-+  +------+
+-----+  +--------+
                                 Figure 8.1

   The logical topology and design Router.

   Other information of Broadband Ethernet Networks is
   very similar interest to DSL Broadband Networks discussed in section 6.

   It is worth noting that the general operation, concepts host, such as DNS, is provided
   through stateful [RFC3315] and
   recommendations described in this section apply similarly to stateless [RFC3736] DHCPv6.

8.2.1.3 Routing

   The CPE devices are configured with a
   HomePNA based network environment. Some of default route that points to
   the Edge router. No routing protocols are needed on these devices
   which generally have limited resources.

   The Edge Router runs the network elements
   might be differently named.

8.2 Deploying IPv6 IGP used in IPv4 Broadband Ethernet Networks

   There are three main design approaches to providing IPv4
   connectivity over an Ethernet infrastructure:

   A. Point-to-Point Model: Each subscriber connects to the network
   Access switch over RJ-45 NSP: OSPFv3 or fiber links. Each subscriber IS-IS.
   The connected prefixes have to be redistributed. If DHCP-PD is assigned used,
   with every delegated prefix a unique VLAN on static route is installed by the access switch. The VLAN can be terminated at Edge
   Router. For this reason the BRAS or static routes must also be redistributed.
   Prefix summarization should be done at the Edge Router. The VLANs are 802.1q trunked to the
   Layer 3 device (BRAS or Edge Router).

   This model is presented in section 8.2.1.

   B.

8.2.2 PPP Terminated Aggregation (PTA) Model: Model

   The PTA architecture relies on PPP-based protocols (PPPoE). The PPP
   sessions are opened
   between each subscriber initiated by Customer Premise Equipment and it is
   terminated at the BRAS. The BRAS terminates authorizes the PPP
   sessions session,
   authenticates the subscriber, and provides an IP address on behalf
   of the ISP. The BRAS then does Layer 3 connectivity between routing of the subscriber
   and
   traffic to the ISP. NSP Edge Router. This model is presented often used when the
   NSP is also the NAP. The PPPoE logical diagram in section 8.2.2.

   C. L2TPv2 Access Aggregation (LAA) Model: an Ethernet
   Broadband Network is shown in Fig 8.2.2.1.

  Customer Premises                   NAP                   NSP
<---------------------------> <-----------------> <----------------->
                                                      +-----------+
                                                      |    AAA    |
                                              +-------+   Radius  |
                                              |       |   TACACS  |
                                              |       +-----------+
+-----+  +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +-+A Switch+-+ Switch +-+   BRAS   +-+    Edge   |  C
+-----+  +-------+ +--------+ +--------+ +----------+ |   Router  +=>O
     <----------------  PPP ---------------->         |           |  R
                                                      +-----------+  E
                            Figure 8.2.2.1

   The PPP sessions are opened
   between each subscriber and initiated by the ISP termination devices. Customer Premise Equipment
   (Host or Router). The BRAS
   tunnels authenticates the subscriber PPP sessions to against a
   local or a remote database. Once the ISP by encapsulating them
   into L2TPv2 tunnels.

   This model session is presented in section 8.2.3.

   In aggregation models established, the
   BRAS terminates the subscriber VLANs provides an address and
   aggregates their connections before providing access to the ISP.

   In order maybe a DNS server to maintain the deployment concepts and business models
   proven and used with existent revenue generating IPv4 services, the
   IPv6 deployment will match user,
   information acquired from the IPv4 one. This approach is presented
   in sections 8.2.1-3 that describes currently deployed IPv4 over
   Ethernet broadband access deployments. Under certain circumstances
   where new service types subscriber profile or service needs justify it, IPv4 and IPv6
   network architectures could from a DHCP
   server.

   This model allows for multiple PPPoE session to be different as described in section
   8.2.4.

8.2.1 Point-to-Point Model

   In this scenario supported over
   the Ethernet frames from same VLAN thus allowing the Host or subscriber to connect to multiple
   services at the Customer
   Premises Router are bridged over same time. The hosts can initiate the VLAN assigned PPPoE sessions
   as well. It is important to remember that the subscriber.

Figure 8.2.1 describes PPPoE encapsulation
   reduces the protocol architecture of this model.

     Customer Premises              NAP                 NSP
<------------------------->  <---------------> <-------------------->

+-----+  +------+  +------+  +--------+        +----------+
|Hosts|--+Router+--+Access+--+ Switch +--------+   Edge   |      ISP
+-----+  +------+  |Switch|  +--------+ 802.1q |  Router  +==> Network
                   +------+                    +----------+

                       <---------------------------->
                               Ethernet/VLANs

                                Figure 8.2.1

8.2.1.1 IP MTU available for the customer traffic.

8.2.2.1 IPv6 Related Infrastructure Changes

   In this scenario the Access Switch on the customer site and the
   entire NAP BRAS is Layer 3 unaware so no changes are needed aware and it has to be upgraded
   to support IPv6. Since the BRAS terminates the PPP sessions it has to
   support PPPoE with IPv6. The following devices have to be upgraded to
   dual stack: Host, Customer Router (if present), BRAS and Edge Router.

8.2.2.2 Addressing

   The Access switches might need upgrades to support certain BRAS terminates the PPP sessions and provides the subscriber with
   an IPv6
   related features such as MLD Snooping.

8.2.1.2 Addressing address from the defined pool for that profile. The
   subscriber profile for authorization and authentication can be
   located on the BRAS or on a AAA server. The Hosts or the Customer
   Routers have the Edge Router BRAS as their Layer 3 next hop. If there is no Customer Router all the hosts on

   the subscriber site belong to the same /64 subnet that is
   statically configured on the Edge Router for that subscriber VLAN.

   The hosts PPP session can use stateless autoconfiguration be initiated by a host or stateful DHCPv6
   based configuration to acquire an address via the Edge Router.

   If by a Customer Router is present:

   A. It is statically configured with an address on the /64 subnet
   between itself and the Edge Router, and with /64 prefixes on the
   interfaces connecting the hosts on the customer site. This is not
   a desired provisioning method being expensive and difficult to
   manage.

   B. It can use its link-local address to communicate with the ER.
   It can also dynamically acquire through stateless autoconfiguration
   the address for the link between itself and Router.
   In the ER.  This step is
   followed by a request via DHCP-PD for a prefix shorter than /64 that
   in turn latter case, once the session is divided in /64s and assigned to its interfaces connecting established with the hosts on BRAS,
   DHCP-PD can be used to acquire prefixes for the customer site.

   The Edge Customer Router
   interfaces. The BRAS has a /64 prefix configured for each subscriber VLAN.
   Each VLAN should to be enabled to support DHCP-PD and to
   relay DHCPv6 requests from the
   subscribers to DHCPv6 servers in requests of the ISP network. The VLANs
   providing access for subscribers that use DHCP-PD as well, have to
   be enabled to support hosts on the feature. subscriber sites.
   Currently the DHCP-PD functionality cannot be implemented if the
   DHCP-PD server is not the Edge Router. If the DHCP-PD messages are
   relayed, the Edge Router does not have a mechanism to learn the
   assigned prefixes and thus install the proper routes to make that
   prefix reachable. Work is being done to address this issue, one idea
   being to provide the Edge Router with a snooping mechanism. The
   uplink to the ISP network is configured with a /64 prefix as well.

   The uplink to BRAS has a /64 prefix configured on the ISP network
   is link facing the Edge
   router. The Edge router links are also configured with a /64 prefix as well. prefixes
   to provide connectivity to the rest of the ISP network.

   The prefixes used for subscriber links and the ones delegated via DHCP-PD
   should be planned in a manner that allows as much maximum summarization as possible at
   the Edge Router. BRAS.

   Other information of interest to the host, such as DNS, is provided
   through stateful [RFC3315] and stateless [RFC3736] DHCPv6.

8.2.1.3

8.2.2.3 Routing

   The CPE devices are configured with a default route that points to
   the Edge BRAS router. No routing protocols are needed on these devices
   which generally have limited resources.

   The Edge Router BRAS runs the IPv6 an IGP used in to the NSP: Edge Router: OSPFv3 or IS-IS.
   The Since the
   addresses assigned to the PPP sessions are represented as connected
   host routes, connected prefixes have to be redistributed. If DHCP-PD
   is used, with every delegated prefix a static route is installed by
   the Edge
   Router. BRAS. For this reason the static routes must also be
   redistributed. Prefix summarization should be done at the Edge Router.

8.2.2 PPP Terminated Aggregation (PTA) Model

   The PTA architecture relies on PPP-based protocols (PPPoE). BRAS.

   The PPP
   sessions are initiated by Customer Premise Equipment and it Edge Router is
   terminated at running the BRAS. The BRAS authorizes IGP used in the session,
   authenticates ISP network: OSPFv3
   or IS-IS. A separation between the subscriber, and provides an IP address on behalf routing domains of the ISP. The ISP and
   the Access Provider is recommended if they are managed independently.
   Controlled redistribution will be needed between the Access Provider
   IGP and the ISP IGP.

8.2.3 L2TPv2 Access Aggregation (LAA) Model

   In the LAA model the BRAS then does Layer 3 routing of forwards the subscriber
   traffic CPE initiated session to the NSP
   ISP over an L2TPv2 tunnel established between the BRAS and the Edge
   Router. This model is often used when In this case the
   NSP is also authentication, authorization and subscriber
   configuration are performed by the NAP.

   The PPPoE logical diagram in an Ethernet Broadband Network is shown
   in Fig 8.2.2.1. ISP itself.

  Customer Premises              NAP                   NSP
<---------------------------> <----------------->
<--------------------> <----------------------> <----------------->

                                                     +-----------+
                                                     |    AAA    |
                                              +-------+
                                              +------+   Radius  |
                                              |      |   TACACS  |
                                              |       +-----------+      +-----+-----+
                                              |            |
+-----+  +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +-+A Switch+-+ Switch +-+   BRAS   +-+    Edge   |  C
+-----+  +-------+ +--------+ +--------+ +----------+ |   Router  +=>O
     <----------------  PPP ---------------->
                                                      |           |  R
                                                      +-----------+  E
                            Figure 8.2.2.1

   The PPP sessions are initiated by the Customer Premise Equipment
   (Host or Router). The BRAS authenticates the subscriber against a
   local or a remote database. Once the session is established, the
   BRAS provides an address and maybe a DNS server to the user,
   information acquired from the subscriber profile or from a DHCP
   server.

   This model allows for multiple PPPoE session to be supported over
   the same VLAN thus allowing the subscriber to connect to multiple
   services at the same time. The hosts can initiate the PPPoE sessions
   as well. It is important to remember that the PPPoE encapsulation
   reduces the IP MTU available for the customer traffic.

8.2.2.1 IPv6 Related Infrastructure Changes

   In this scenario the BRAS is Layer 3 aware and it has to be upgraded
   to support IPv6. Since the BRAS terminates the PPP sessions it has to
   support PPPoE with IPv6. The following devices have to be upgraded to
   dual stack: Host, Customer Router (if present), BRAS and Edge Router.

8.2.2.2 Addressing

   The BRAS terminates the           |  R
                                                      +-----------+  E
            <----------------------------------------------->
                                    PPP sessions and provides the subscriber with
   an
                                             <-------------->
                                                   L2TPv2

                                Figure 8.2.3.1

8.2.3.1 IPv6 address from the defined pool for that profile. The
   subscriber profile for authorization and authentication can be
   located on the BRAS or on a AAA server. The Hosts or the Customer
   Routers have Related Infrastructure Changes

   In this scenario the BRAS as their is Layer 3 next hop. aware and it has to be upgraded
   to support IPv6. The PPP session can be sessions initiated by a host or by a Customer Router.
   In the latter case, once the session is established with subscriber are
   forwarded over the BRAS,
   DHCP-PD can be used L2TPv2 tunnel to acquire prefixes for the Customer Router
   interfaces. aggregation point in the ISP
   network. The BRAS has to be enabled to support DHCP-PD (LAC) can aggregate IPv6 PPP sessions and tunnel
   them to
   relay the DHCPv6 requests of the hosts on the subscriber sites.
   Currently the DHCP-PD functionality cannot be implemented if the
   DHCP-PD server is not the Edge Router. If the DHCP-PD messages are
   relayed, LNS using L2TPv2. The L2TPv2 tunnel between the Edge Router does not LAC and
   LNS could run over IPv6 or IPv4. These capabilities have a mechanism to learn the
   assigned prefixes and thus install be
   supported on the proper routes to make that
   prefix reachable. Work is being done BRAS. The following devices have to address this issue, one idea
   being be upgraded to provide the Edge
   dual stack: Host, Customer Router with a snooping mechanism. The
   uplink to the ISP network is configured with a /64 prefix as well.

   The BRAS has a /64 prefix configured on the link facing the (if present), BRAS and Edge
   router. Router.

8.2.3.2 Addressing

   The Edge router links are also configured with /64 prefixes
   to provide connectivity to terminates the rest of PPP sessions and provides the ISP network.

   The prefixes used for
   subscriber and with an IPv6 address from the ones delegated via DHCP-PD
   should be planned in a manner defined pool for that allows maximum summarization at
   the BRAS.

   Other information of interest to the host, such as DNS, is provided
   through stateful [RFC3315] and stateless [RFC3736] DHCPv6.

8.2.2.3 Routing
   profile. The CPE devices are configured with a default route that points to
   the BRAS router. No routing protocols are needed subscriber profile for authorization and authentication
   can be located on these devices
   which have limited resources.

   The BRAS runs an IGP to the Edge Router: OSPFv3 Router or on a AAA server. The Hosts or IS-IS. Since
   the
   addresses assigned to  Customer Routers have the PPP sessions are represented Edge Router as connected
   host routes, connected prefixes have to their Layer 3 next hop.

   The PPP session can be redistributed. If DHCP-PD
   is used, with every delegated prefix initiated by a static route is installed host or by a Customer Router.
   In the BRAS. For this reason latter case, once the static routes must also be
   redistributed. Prefix summarization should be done at session is established with the BRAS.

   The Edge
   Router and an IPv6 address is running the IGP used in the ISP network: OSPFv3
   or IS-IS. A separation between the routing domains of assigned to the ISP and Customer Router by the Access Provider is recommended if they are managed independently.
   Controlled redistribution will
   Edge router, DHCP-PD can be needed between used to acquire prefixes for the Access Provider
   IGP Customer
   Router other interfaces. The Edge Router has to be enabled to support
   DHCP-PD and to relay the ISP IGP.

8.2.3 L2TPv2 Access Aggregation (LAA) Model

   In the LAA model DHCPv6 requests of the BRAS forwards hosts on the CPE initiated session to
   subscriber sites. Currently the ISP over an L2TPv2 tunnel established between DHCP-PD functionality cannot be
   implemented if the BRAS and DHCP-PD server is not the Edge Router. In this case If the authentication, authorization and
   subscriber configuration
   DHCP-PD messages are performed by relayed, the ISP itself.

  Customer Premises              NAP                   NSP
<--------------------> <----------------------> <----------------->

                                                     +-----------+
                                                     |    AAA    |
                                              +------+   Radius  |
                                              |      |   TACACS  |
                                              |      +-----+-----+
                                              |            |
+-----+  +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +-+A Switch+-+ Switch +-+   BRAS   +-+ Edge   |  C
+-----+  +-------+ +--------+ +--------+ +----------+ | Router  +=>O
                                                      |           |  R
                                                      +-----------+  E
            <----------------------------------------------->
                                    PPP
                                             <-------------->
                                                   L2TPv2

                                Figure 8.2.3.1

8.2.3.1 IPv6 Related Infrastructure Changes

   In this scenario does not have a
   mechanism to learn the BRAS is Layer 3 aware assigned prefixes and it has thus install the proper
   routes to be upgraded make that prefix reachable. Work is being done to support IPv6. address
   this issue, one idea being to provide the Edge Router with a snooping
   mechanism. The PPP sessions initiated by uplink to the subscriber are
   forwarded over ISP network is configured with a /64
   prefix as well.

   The BRAS has a /64 prefix configured on the L2TPv2 tunnel link to the aggregation point in Edge router.
   The Edge router links are also configured with /64 prefixes to
   provide connectivity to the rest of the ISP network. The BRAS (LAC) can aggregate IPv6 PPP sessions and tunnel
   them

   Other information of interest to the LNS using L2TPv2. host, such as DNS, is provided
   through stateful [RFC3315] and stateless [RFC3736] DHCPv6.

   The L2TPv2 tunnel between the LAC address assignment and
   LNS could run over IPv6 or IPv4. These capabilities have to be
   supported on prefix summarization issues discussed in
   section 7.2.3.2 are relevant in the BRAS. same way for this media access
   type as well.

8.2.3.3 Routing

   The following CPE devices have to be upgraded are configured with a default route that points to
   dual stack: Host, Customer Router (if present), BRAS and Edge Router.

8.2.3.2 Addressing

   The
   the Edge router that terminates the PPP sessions and provides the
   subscriber with sessions. No routing
   protocols are needed on these devices which have limited
   resources.

   The BRAS runs an IPv6 address from IGP to the defined pool for that
   profile. The subscriber profile for authorization Edge Router: OSPFv3 or IS-IS.
   Different processes should be used if the NAP and authentication
   can the NSP are
   managed by different organizations. In this case controlled
   redistribution should be located on enabled between the two domains.

   The Edge Router or on a AAA server. The Hosts or is running the  Customer Routers have IPv6 IGP used in the Edge Router as their Layer 3 next hop.

   The PPP session can be initiated by a host ISP network:
   OSPFv3 or by a Customer Router.
   In IS-IS.

8.2.4 Hybrid Model for IPv4 and IPv6 Service

   It was recommended throughout this section that the latter case, once IPv6 service
   implementation should map the existent IPv4 one. This approach
   simplifies manageability and minimizes training needed for personnel
   operating the network. In certain circumstances such mapping is not
   feasible. This typically becomes the session is established case when a Service Provider
   plans to expand its service offering with the Edge
   Router and an new IPv6 address deployed
   infrastructure. If this new service is assigned to the Customer Router by not well supported in a
   network design such as the
   Edge router, DHCP-PD can one used for IPv4 then a different design
   might be used to acquire prefixes for IPv6.

   An example of such circumstances is that of a provider using an LAA
   design for its IPv4 services. In this case all the Customer
   Router other interfaces. The Edge Router has to be enabled to support
   DHCP-PD PPP sessions are
   bundled and to relay tunneled across the DHCPv6 requests entire NAP infrastructure which is
   made of multiple BRAS routers, aggregation routers etc. The end point
   of these tunnels is the hosts on ISP Edge Router. If the
   subscriber sites. Currently SP decides to offer
   multicast services over such a design, it will face the DHCP-PD functionality cannot problem of
   NAP resources being over utilized. The multicast traffic can be
   implemented if
   replicated only at the DHCP-PD server is not end of the tunnels by the Edge Router. If router and the
   DHCP-PD messages
   copies for all the subscribers are relayed, carried over the Edge Router does not have entire NAP.

   A Modified Point-to-Point (see section 8.2.4.2) or a
   mechanism PTA model is
   more suitable to learn the assigned prefixes and thus install support multicast services because the proper
   routes to make that prefix reachable. Work is being packet
   replication can be done closer to address the destination at the BRAS.
   Such topology saves NAP resources.

   In this issue, one idea being sense IPv6 deployments can be viewed as an opportunity to provide
   build an infrastructure that can better support the Edge Router with expansion of
   services. In this case, an SP using the LAA design for its IPv4
   services might choose a snooping
   mechanism. modified Point-to-Point or PTA design for
   IPv6.

8.2.4.1 IPv4 in LAA Model and IPv6 in PTA Model

   The uplink to coexistence of the ISP network two PPP based models, PTA and LAA, is
   relatively straight forward. It is configured with a /64
   prefix as well.

   The BRAS has a /64 prefix configured on the link to straight forward overlap of the Edge router.
   two deployment models. The Edge router links PPP sessions are also configured with /64 prefixes to
   provide connectivity to the rest of the ISP network.

   Other information of interest to terminated on
   different network devices for the host, such as DNS, is provided
   through stateful [RFC3315] IPv4 and stateless [RFC3736] DHCPv6. IPv6  services. The address assignment and prefix summarization issues discussed PPP
   sessions for the existent IPv4 service deployed in
   section 7.2.3.2 an LAA model are relevant
   terminated on the Edge Router. The PPP sessions for the new IPv6
   service deployed in a PTA model are terminated on the same way BRAS.

   The logical design for IPv6 and IPv4 in this media access
   type as well.

8.2.3.3 Routing hybrid model is
   presented in Figure 8.2.4.1.

IPv6          <-------------------------->
                         PPP                    +-----------+
                                                |    AAA    |
                                        +-------+   Radius  |
                                        |       |   TACACS  |
                                        |       +-----+-----+
                                        |             |
+-----+  +-------+      +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ Switch +-+  BRAS    +-+   Edge    |
+-----+  +-------+      +--------+ +----------+ |  Router   +=>Core
                                                +-----------+

IPv4          <---------------------------------------->
                                PPP
                                         <------------>
                                              L2TPv2
                          Figure 8.2.4.1

8.2.4.2 IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model

   The CPE devices are configured with coexistence of the modified Point-to-Point and the LAA models
   implies a default route that points to few specific changes.

   For the Edge router that terminates IPv4 service in LAA model, the PPP sessions. No routing
   protocols VLANs are needed terminated on these devices which have limited
   resources.

   The the
   BRAS runs an and PPP sessions are terminated on the Edge Router (LNS). For
   IPv6 IGP to service in Point-to-Point model, the VLANs are terminated at
   the Edge Router: OSPFv3 or IS-IS.
   Different processes should Router as described in section 7.2.1. In this hybrid model,
   the Point-to-Point link could be used if terminated on the BRAS, a NAP and owned
   device. The IPv6 traffic is then routed through the NSP are
   managed by different organizations. NAP network to
   the NSP. In order to have this case controlled
   redistribution should be enabled between hybrid model, the two domains. BRAS has to be
   upgraded to a dual-stack router. The functionalities of the Edge
   Router is running the IPv6 IGP used as described in section 7.2.1 are now implemented on the ISP network:
   OSPFv3 or IS-IS.

8.2.4 Hybrid Model BRAS.

   The logical design for IPv4 and IPv6 Service

   It was recommended throughout and IPv4 in this section that the hybrid model is
   in Figure 8.2.4.2.

IPv6 service
   implementation should map the existent              <---------------->
                        Ethernet
                                                +-----------+
                                                |    AAA    |
                                        +-------+   Radius  |
                                        |       |   TACACS  |
                                        |       +-----+-----+
                                        |             |
+-----+  +-------+      +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ Switch +-+  BRAS    +-+   Edge    |
+-----+  +-------+      +--------+ +----------+ |  Router   +=>Core
                                                +-----------+
IPv4 one. This approach
   simplifies manageability and minimizes training needed          <---------------------------------------->
                                PPP
                                          <------------>
                                              L2TPv2

                              Figure 8.2.4.2

8.3 IPv6 Multicast

   The typical multicast services offered for personnel
   operating the network. In certain circumstances such mapping residential and very small
   businesses is not
   feasible. This typically becomes video/audio streaming where the case when subscriber joins a Service Provider
   plans to expand its service offering with
   multicast group and receives the new IPv6 deployed
   infrastructure. If this new content. This type of service model
   is not well supported in a
   network design such as the one used for IPv4 then a different design
   might through PIM-SSM which is very simple and easy to
   manage. PIM-SSM has to be used for IPv6.

   An example of such circumstances enabled throughout the ISP network. MLDv2
   is required for PIM-SSM support.  Vendors can choose to implement
   features that of allow routers to map MLDv1 group joins to predefined
   sources.

   Subscribers might use a provider using an LAA
   design set-top box that is responsible for its IPv4 services. In this case all the PPP sessions
   control piece of the multicast service (does group joins/leaves).
   The subscriber hosts can also join desired multicast groups as
   long as they are
   bundled enabled to support MLDv1 or MLDv2. If a customer
   premise router is used then it has to be enabled to support MLDv1
   and tunneled across MLDv2 in order to process the entire NAP infrastructure which is
   made of multiple BRAS routers, aggregation routers etc. The end point requests of these tunnels the hosts. It has to
   be enabled to support PIM-SSM in order to send PIM joins/leaves up
   to its Layer 3 next hop whether it is the ISP BRAS or the Edge Router. If router.
   When enabling this functionality on a customer premises router,
   its limited resources should be taken into consideration. Another
   option would be for the SP decides customer premises router to offer support MLD
   proxy routing. MLD snooping or similar layer two multicast services over such a design, it will face related
   protocols could be enabled on the problem of NAP resources being over utilized. switches.

   The multicast traffic can be
   replicated only at the end of the tunnels by the Edge router and that is the
   copies Layer 3 next hop for all the subscribers are carried over subscriber (BRAS in
   the entire NAP.

   A Modified Point-to-Point (see section 8.2.4.2) or a PTA model is
   more suitable to support multicast services because the packet
   replication can be done closer to or the destination at Edge router in the BRAS.
   Such topology saves NAP resources.

   In this sense IPv6 deployments can LAA and Point-to-Point model)
   has to be viewed as an opportunity enabled to
   build an infrastructure that can better support MLDv1 and MLDv2 in order to process the expansion of
   services. In this case, an SP using the LAA design for its IPv4
   services might choose a modified Point-to-Point or PTA design
   requests coming from subscribers without customer premises routers.
   It has to be enabled for
   IPv6.

8.2.4.1 IPv4 PIM-SSM in LAA Model order to receive joins/leaves
   from customer routers and IPv6 in PTA Model

   The coexistence of send joins/leaves to the two PPP based models, PTA next hop towards
   the multicast source (Edge router or the NSP core).

   MLD authentication, authorization and LAA, is
   relatively straight forward. It accounting is a straight forward overlap usually
   configured on the edge router in order to enable the ISP to do
   control the subscriber access of the
   two deployment models. The PPP sessions are terminated on
   different network devices service and do billing for the IPv4 and
   content provided. Alternative mechanisms that would support these
   functions should be investigated further.

   Please refer to section 7.3 for more IPv6  services. multicast details.

8.4 IPv6 QoS

   The PPP
   sessions for the existent IPv4 service deployed in an LAA model are
   terminated QoS configuration is particularly relevant on the Edge Router. The PPP sessions router that
   represents the Layer 3 next hop for the new IPv6
   service deployed subscriber (BRAS in a the PTA
   model are terminated on or the BRAS.

   The logical design for IPv6 and IPv4 in this hybrid model is
   presented in Figure 8.2.4.1.

IPv6          <-------------------------->
                         PPP                    +-----------+
                                                |    AAA    |
                                        +-------+   Radius  |
                                        |       |   TACACS  |
                                        |       +-----+-----+
                                        |             |
+-----+  +-------+      +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ Switch +-+  BRAS    +-+ Edge    |
+-----+  +-------+      +--------+ +----------+ |  Router   +=>Core
                                                +-----------+

IPv4          <---------------------------------------->
                                PPP
                                         <------------>
                                              L2TPv2
                          Figure 8.2.4.1

8.2.4.2 IPv4 router in the LAA Model and IPv6 in Modified Point-to-Point Model

   The coexistence of the modified Point-to-Point and the LAA models
   implies a few specific changes.

   For the IPv4 service model) in LAA model, the VLANs are terminated on
   order to manage resources shared amongst multiple subscribers
   possibly with various service level agreements.

   On the BRAS and PPP sessions are terminated on or the Edge Router (LNS). For
   IPv6 service in Point-to-Point model, the VLANs are terminated at subscriber facing interfaces have
   to be configured to police the Edge Router as described in section 7.2.1. In this hybrid model, inbound customer traffic and shape the
   traffic outbound to the customer based on the Point-to-Point link could SLAs. Traffic
   classification and marking should also be terminated done on the BRAS, a NAP owned
   device. The IPv6 traffic is then routed through the NAP network router closest
   (at Layer 3) to the NSP. In subscriber in order to have this hybrid model, support the BRAS has to be
   upgraded to a dual-stack router. The functionalities various types
   of customer traffic: data, voice, video and to optimally use the Edge
   Router as described in section 7.2.1 are now implemented on
   network resources. This infrastructure offers a very good opportunity
   to leverage the BRAS.

   The logical design QoS capabilities of Layer two devices. DiffServ based
   QoS used for IPv6 and IPv4 in this hybrid model is
   in Figure 8.2.4.2.

IPv6              <---------------->
                        Ethernet
                                                +-----------+
                                                |    AAA    |
                                        +-------+   Radius  |
                                        |       |   TACACS  |
                                        |       +-----+-----+
                                        |             |
+-----+  +-------+      +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ Switch +-+  BRAS    +-+   Edge    |
+-----+  +-------+      +--------+ +----------+ |  Router   +=>Core
                                                +-----------+ IPv4          <---------------------------------------->
                                PPP
                                          <------------>
                                              L2TPv2

                              Figure 8.2.4.2

8.3 IPv6 Multicast

   The typical multicast should be expanded to IPv6.

   Each provider (NAP, NSP) could implement their own QoS policies and
   services offered for residential so reclassification and very small
   businesses is video/audio streaming where marking might be performed at the subscriber joins a
   multicast group
   boundary between the NAP and receives the content. This type of service model
   is well supported through PIM-SSM which NSP in order to make sure the
   traffic is very simple properly handled by the ISP. The same IPv4 QoS concepts
   and easy to
   manage. PIM-SSM has to methodologies should be enabled throughout applied for the ISP network. MLDv2 IPv6 as well.

   It is required for PIM-SSM support.  Vendors can choose to implement
   features that allow routers to map MLDv1 group joins important to predefined
   sources.

   Subscribers might use a set-top box note that when traffic is responsible for encrypted end-to-end,
   the
   control piece traversed network devices will not have access to many of the multicast service (does group joins/leaves).
   packet fields used for classification purposes. In these cases
   routers will most likely place the packets in the default classes.
   The subscriber hosts can also join desired multicast groups as
   long as they are enabled QoS design should take into consideration this scenario and try
   to support MLDv1 or MLDv2. If a customer
   premise router is used then it has use mainly IP header fields for classification purposes.

8.5 IPv6 Security Considerations

   There are limited changes that have to be enabled to support MLDv1
   and MLDv2 done for CPEs in order to process
   enhance security. The Privacy extensions [RFC3041] for
   autoconfiguration should be used by the requests of hosts with the hosts. It has to same
   considerations for host traceability as discussed in section 7.5.
   IPv6 firewall functions should be enabled to support PIM-SSM in order to send PIM joins/leaves up
   to its Layer 3 next hop whether it is on the BRAS hosts or the Edge router.
   When enabling this functionality on a customer
   premises router, router if present.

   The ISP provides security against attacks that come form its limited resources should be taken into consideration.

   MLD snooping or similar own
   subscribers but it could also implement security services that
   protect its subscribers from attacks sourced from the outside of its
   network. Such services do not apply at the access level of the

   network discussed here.

   If any layer two multicast related protocols could
   be enabled on filters for Ethertypes are in place, the NAP switches. must
   permit the IPv6 Ethertype (0X86DD).

   The router device that is the Layer 3 next hop for the subscriber subscribers (BRAS in
   the PTA model or the
   Edge router in router) should protect the LAA and Point-to-Point model)

   has to be enabled to support MLDv1 network and MLDv2 in order to process the
   requests coming from other subscribers without customer premises routers.
   It has to
   against attacks by one of the provider customers. For this reason
   uRPF and ACLs should be enabled used on all interfaces facing subscribers.
   Filtering should be implemented with regard for PIM-SSM in order to receive joins/leaves
   from customer routers and send joins/leaves to the next hop towards
   the multicast source (Edge router or the NSP core).

   MLD authentication, operational
   requirements of IPv6 [Security considerations for IPv6].
   Authentication and authorization should be used wherever possible.

   The BRAS and accounting is usually
   configured on the edge router in order to enable the ISP to do
   control the subscriber access Edge Router should protect their processing
   resources against floods of the service valid customer control traffic such as:
   Router and do billing for the
   content provided. Alternative mechanisms that would support these
   functions Neighbor Solicitations, MLD Requests. Rate limiting
   should be investigated further.

   Please refer to section 7.3 for more IPv6 multicast details.

8.4 IPv6 QoS

   The QoS configuration is particularly relevant implemented on the router that
   represents the Layer 3 next hop for the all subscriber (BRAS in the PTA
   model or the Edge router in facing interfaces. The
   emphasis should be placed on multicast type traffic as it is most
   often used by the LAA and Point-to-Point model) in
   order to manage resources shared amongst multiple subscribers
   possibly IPv6 control plane.

   All other security features used with various service level agreements.

   On the BRAS or the Edge Router the subscriber facing interfaces have
   to IPv4 service should be configured
   similarly applied to police IPv6 as well.

8.6 IPv6 Network Management

   The necessary instrumentation (such as MIBs, NetFlow Records etc)
   should be available for IPv6.

   Usually, NSPs manage the inbound customer traffic edge routers by SNMP. The SNMP transport can
   be done over IPv4 if all managed devices have connectivity over both
   IPv4 and shape IPv6. This would imply the
   traffic outbound smallest changes to the customer based on the SLAs. Traffic
   classification existent
   network management practices and marking should processes. Transport over IPv6 could
   also be done on the router closest
   (at Layer 3) to the subscriber implemented and it might become necessary if IPv6 only
   islands are present in order to support the various types
   of customer traffic: data, voice, video and to optimally use network. The management stations are
   located on the
   network resources. This infrastructure offers core network. Network Management Applications should
   handle IPv6 in a very good opportunity similar fashion to leverage the QoS capabilities of Layer two devices. DiffServ based
   QoS used for IPv4 however they should be expanded also
   support features specific to IPv6.

   Each provider (NAP, NSP) could implement their own QoS policies and
   services so reclassification and marking might be performed at the
   boundary between the NAP IPv6 such as Neighbor monitoring.

   In some cases service providers manage equipment located on customers
   LANs.

9. Wireless LAN

   This section provides detailed description of IPv6 deployment and the NSP
   integration methods in order currently deployed wireless LAN (WLAN)
   infrastructure.

9.1 WLAN Deployment Scenarios

   WLAN enables subscribers to connect to make sure the
   traffic Internet from various
   locations without the restriction of staying indoors.  WLAN is properly handled
   standardized by the ISP.

   The same IPv4 QoS concepts and methodologies IEEE 802.11a/b/g. Consideration should be applied also given
   to IEEE 802.16 WiMAX for
   the IPv6 as well.

   It is important similar deployment approaches. IEEE 802.11
   offers maximum transmission speed from 1 or 2 Mbps, IEEE 802.11b
   offers 11 Mbps and IEEE 802.11a offers up to note that when traffic is encrypted end-to-end, 54 Mbps.

   Figure 9.1 describes the traversed network devices will not current WLAN architecture.

    Customer Premises|        Access Provider       |Service Provider
                     |                              |

  +------+        +--+ +--------------+ +----------+ +------+
  |WLAN  |  ----  |  | |Access Router/| |Underlying| |Edge  |
  |Host/ |-(WLAN)-|AP|-|Layer 2 Switch|-|Technology|-|Router|=>SP
  |Router|  ----  |  | |              | |          | |      |  Network
  +------+        +--+ +--------------+ +----------+ +------+
                                                        |
                                                     +------+
                                                     |AAA   |
                                                     |Server|
                             Figure 9.1              +------+

   The host should have access a wireless network interface card (NIC) in order
   to many of the
   packet fields used for classification purposes. In these cases
   routers will most likely place the packets connect to a WLAN network.  WLAN is a flat broadcast network and
   works in a similar fashion as Ethernet. When hosts initiate a
   connection, it is authenticated by the default classes.
   The QoS design should take into consideration this scenario and try
   to use mainly IP header fields for classification purposes.

8.5 IPv6 Security Considerations

   There AAA server located at the
   SP network. All the authentication parameters (username, password
   and etc.) are limited changes that have to be done for CPEs in order forwarded by the Access Point (AP) to
   enhance security. the AAA server.
   The Privacy extensions [RFC3041] for
   autoconfiguration should be used by AAA server authenticates the hosts with host, once authenticated
   successfully the same
   considerations for host traceability as discussed in section 7.5.
   IPv6 firewall functions should be enabled on can send data packets. The AP is located near
   the hosts or customer
   premises router if present. host and acts as a bridge. The ISP provides security against attacks that come form its own
   subscribers but it could also implement security services that
   protect its subscribers from attacks sourced from AP forwards all the outside of its
   network. Such services do not apply at packets
   coming to/from host to the access level of Edge Router. The underlying connection
   between the

   network discussed here.

   If AP and Edge Router could be based on any access layer two filters for Ethertypes
   technology such as HFC/Cable, FTTH, xDSL or etc.

   WLANs are based in limited areas known as WiFi Hot Spots. While users
   are present in place, the NAP must
   permit area covered by the IPv6 Ethertype (0X86DD).

   The device that WLAN range, they can be
   connected to the Internet given they have a wireless NIC and required
   configuration settings in their devices (notebook PCs, PDA or etc.).
   Once the user initiates the connection the IP address is assigned by
   the Layer 3 next hop for SP using DHCPv4. In most of the subscribers (BRAS
   Edge router) should protect cases SP assigns limited
   number of public IP addresses to the its customer. When the network user
   disconnects the connection and move to a new WiFi hot spot, the other subscribers
   against attacks by one above
   mentioned process of authentication, address assignment and accessing
   the provider Internet is repeated.

   There are IPv4 deployments where customers can use WLAN routers to
   connect over wireless to their service provider. These deployment
   types do not fit in the typical Hot Spot concept but they rather
   serve fixed customers. For this reason
   uRPF and ACLs should be used on all interfaces facing subscribers.
   Filtering should be implemented with regard for this section discusses the operational
   requirements of IPv6 (ICMPv6 types). Authentication and authorization
   should be used wherever possible.

   The BRAS
   WLAN router options as well. In this case, the ISP provides a public
   IP address and the Edge Router should protect their processing
   resources against floods of valid customer control traffic such as: WLAN Router and Neighbor Solicitations, MLD Requests. Rate limiting
   should be implemented on assigns private addresses [RFC1918]
   to all subscriber facing interfaces. WLAN users. The
   emphasis should be placed on multicast type traffic as it is most
   often used by WLAN Router provides NAT functionality while
   WLAN users access the Internet.

   While deploying IPv6 control plane.

   All other security features used with in the IPv4 service should be
   similarly applied to IPv6 as well.

8.6 IPv6 Network Management

   The necessary instrumentation (such above mentioned WLAN architecture, there
   are three possible scenarios as MIBs, NetFlow Records etc)
   should be available for IPv6.

   Usually, NSPs manage the edge routers by SNMP. The SNMP transport can
   be done over IPv4 if all managed devices have connectivity over both
   IPv4 discussed below.

   A. Layer 2 Switch Between AP and IPv6. This would imply Edge Router
   B. Access Router Between AP and Edge Router
   C. PPP Based Model

9.1.1 Layer 2 Switch Between AP and Edge Router

   When a Layer 2 switch is present between AP and Edge Router, the smallest changes AP
   and Layer 2 switch continues to the existent
   network management practices work as a bridge, forwarding IPv4
   and processes. Transport over IPv6 could
   also be implemented packets from WLAN Host/Router to Edge Router and it might become necessary if IPv6 only
   islands are present in vice
   versa.

   When initiating the network. The management stations are connection, the WLAN host is authenticated by the
   AAA server located on at the core SP network. Network Management Applications should
   handle IPv6 in a similar fashion to IPv4 however they should also
   support features specific  All the parameters related to IPv6 such as Neighbor monitoring.

   In some cases service providers manage equipment located on customers
   LANs.

9. Wireless LAN

   This section provides detailed description of IPv6 deployment
   authentication (username, password and
   integration methods in currently deployed wireless LAN (WLAN)
   infrastructure.

9.1 WLAN Deployment Scenarios

   WLAN enables subscribers to connect etc.) are forwarded by the AP
   to the Internet from various
   locations without AAA server.  The AAA server authenticates the restriction of staying indoors. WLAN is
   standardized by IEEE 802.11a/b/g. Consideration should Hosts and
   once authenticated and associated successfully with WLAN AP, IPv6
   address will be also given
   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 11 Mbps acquired by the WLAN Host.  Note the initiation and IEEE 802.11a offers up to 54 Mbps.
   authentication process is same as used in IPv4.

   Figure 9.1 9.1.1 describes the current WLAN architecture. architecture when Layer 2 Switch is
   located between AP and Edge Router.

    Customer Premises|        Access Provider       |Service Provider
                     |                              |

  +------+        +--+ +--------------+ +----------+ +------+
  |WLAN  |  ----  |  | |Access Router/| |              | |Underlying| |Edge  |
  |Host/ |-(WLAN)-|AP|-|Layer 2 Switch |-|Technology|-|Router|=>SP Switch|-|Technology|-|Router|=>SP
  |Router|  ----  |  | |              | |          | |      |  Network
  +------+        +--+ +--------------+ +----------+ +------+
                                                        |
                                                     +------+
                                                     |AAA   |
                                                     |Server|
                             Figure 9.1
                                                     +------+
                              Figure 9.1.1

9.1.1.1 IPv6 Related Infrastructure Changes

   IPv6 will be deployed in this scenario by upgrading the following
   devices to dual-stack: WLAN Host, WLAN Router (if present) and Edge
   Router.

9.1.1.2 Addressing

   When customer WLAN Router is not present, the WLAN Host has two
   possible options to get an IPv6 address via the Edge Router.

   A. The WLAN host should have can get the IPv6 address from Edge router using
   stateless auto-configuration [RFC2462].  All the hosts on the WLAN
   belong to the same /64 subnet that is statically configured on the
   Edge Router.  The IPv6 WLAN Host may use stateless DHCPv6 for
   obtaining other information of interest such as DNS and etc.

   B. IPv6 WLAN host can use DHCPv6 [RFC3315] to get a wireless network interface card (NIC) IPv6 address
   from the DHCPv6 server.  In this case the DHCPv6 server would be
   located in order the SP core network and Edge Router would act simply as
   a DHCP Relay Agent.  This option is similar to connect what we do today in
   case of DHCPv4. It is important to note that host implementation of
   stateful auto-configuration is rather limited at this time and this
   should be considered if choosing this address assignment option.

   When a customer WLAN network. Router is present, the WLAN Host has two
   possible options as well for acquiring IPv6 address.

   A. The WLAN is Router may be assigned a flat broadcast network prefix between /48 and
   works in a similar fashion as Ethernet. When hosts initiate a
   connection, it is authenticated by the AAA server located at /64
   depending on the SP network. All the authentication parameters (username, password policy and etc.) are forwarded by customer requirements. If the Access Point (AP) WLAN
   Router has multiple networks connected to its interfaces, the AAA server.
   The AAA server authenticates network
   administrator will have to configure the host, once authenticated
   successfully /64 prefixes to the host WLAN
   Router interfaces connecting the WLAN Hosts on the customer site.
   The WLAN Hosts connected to these interfaces can send data packets. automatically
   configure themselves using stateless auto-configuration with /64
   prefix.

   B. The AP is located near WLAN Router can use its link-local address to communicate with
   the host ER. It can also dynamically acquire through stateless
   autoconfiguration the address for the link between itself and acts as a bridge. The AP forwards all the packets
   coming to/from host ER.
   This step is followed by a request via DHCP-PD for a prefix shorter
   than /64 that in turn is divided in /64s and assigned to its
   interfaces connecting the Edge Router. The underlying connection
   between hosts on the AP customer site.

   In this option, the WLAN Router would act as a requesting router and
   Edge Router could be based on any access layer
   technology such as HFC/Cable, FTTH, xDSL or etc.

   WLANs are based in limited areas known would act as WiFi Hot Spots. While users
   are present in delegating router. Once prefix is received
   by the WLAN Router, it assigns /64 prefixes to each of its
   interfaces connecting the area covered by WLAN Hosts on the customer site. The WLAN range, they can be
   Hosts connected to these interfaces can automatically configure
   themselves using stateless auto-configuration with /64 prefix.
   Currently the Internet given they have a wireless NIC and required
   configuration settings in their devices (notebook PCs, PDA or etc.).
   Once DHCP-PD functionality cannot be implemented if the user initiates
   DHCP-PD server is not the connection ER. If the DHCP-PD messages are relayed,
   the Edge Router does not have a mechanism to learn the IP address is assigned by
   prefixes and thus install the SP using DHCPv4. In most of proper routes to make that prefix
   reachable. Work is being done to address this issue, one idea being

   to provide the cases SP assigns limited
   number of public IP addresses Edge Router with a snooping mechanism. The uplink to
   the its customer. When ISP network is configured with a /64 prefix as well.

   Usually it is easier for the user
   disconnects SPs to stay with the connection DHCP PD and move
   stateless auto-configuration model and point the clients to a new WiFi hot spot,
   central server for DNS/domain information, proxy configurations and
   etc. Using this model the above
   mentioned process of authentication, address assignment SP could change prefixes on the fly
   and accessing the Internet is repeated.

   There are IPv4 deployments where customers can use WLAN routers to
   connect over wireless to their service provider. These deployment
   types do not fit in Router would simply pull the typical Hot Spot concept but they rather
   serve fixed customers. For this reason this section discusses newest prefix based on the
   valid/preferred lifetime.

   The prefixes used for subscriber links and the
   WLAN router options ones delegated via
   DHCP-PD should be planned in a manner that allows maximum
   summarization as well. In this case, possible at the ISP provides a public
   IP address and Edge Router.

   Other information of interest to the host, such as DNS, is provided
   through stateful [RFC3315] and stateless [RFC3736] DHCPv6.

9.1.1.3 Routing

   The WLAN Router assigns private addresses [RFC1918] Host/Router are configured with a default route that points
   to all WLAN users. the Edge router. No routing protocols are needed on these devices
   which generally have limited resources.

   The WLAN Edge Router provides NAT functionality while
   WLAN users access runs the Internet.

   A detailed description of current WLAN infrastructure using IPv4 is
   explained in [ISP Transition Scenarios].

   While deploying IPv6 IGP used in the above mentioned WLAN architecture, there
   are three possible scenarios SP network such as discussed below.

   A. Layer 2 Switch Between AP and OSPFv3
   or IS-IS for IPv6. The connected prefixes have to be redistributed.
   Prefix summarization should be done at the Edge Router
   B. Router. When DHCP-PD
   is used, the IGP has to redistribute the static routes installed
   during the process of prefix delegation.

9.1.2 Access Router Between AP and Edge Router
   C. PPP Based Model

9.1.1 Layer 2 Switch Between AP and SP Edge Router

   When a Layer 2 switch Access Router is present between AP and Edge Router, the AP
   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.

   When initiating the connection, the WLAN host is authenticated by the
   AAA server located at the SP network.  All the parameters related to
   authentication (username, password and etc.) are forwarded by Edge Router, the AP
   continues to the AAA server.  The AAA server authenticates the WLAN Hosts and
   once authenticated work as a bridge, bridging IPv4 and associated successfully with WLAN AP, IPv6
   address will packets from
   WLAN Host/Router to Access/Edge Router and vice versa. The Access
   Router could be acquired part of SP network or owned by the a separate Access
   Provider.

   When WLAN Host.  Note Host initiates the initiation and connection, the AAA authentication and
   association process is same with WLAN AP will be similar as used explained in IPv4.
   section 9.1.1.

   Figure 9.1.1 9.1.2 describes the WLAN architecture when Layer 2 Switch Access Router is
   located between AP and Edge Router.

    Customer Premises|        Access Provider       |Service Provider
                     |                              |

  +------+        +--+ +--------------+ +----------+ +------+
  |WLAN  |  ----  |  | |              | |Underlying| |Edge  |
  |Host/ |-(WLAN)-|AP|-|Layer 2 Switch |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP
  |Router|  ----  |  | |              | |          | |      |  Network
  +------+        +--+ +--------------+ +----------+ +------+
                                                        |
                                                     +------+
                                                     |AAA   |
                                                     |Server|
                                                     +------+
                              Figure 9.1.1

9.1.1.1 IPv6 Related Infrastructure Changes

   IPv6 will be deployed in this scenario by upgrading the following
   devices to dual-stack: WLAN Host, WLAN Router (if present) and Edge
   Router.

9.1.1.2 Addressing

   When customer WLAN Router is not present, the WLAN Host has two
   possible options to get an IPv6 address via the Edge Router.

   A. The WLAN host can get the IPv6 address from Edge router using
   stateless auto-configuration [RFC2462].  All the hosts on the WLAN
   belong to the same /64 subnet that is statically configured on the
   Edge Router.  The IPv6 WLAN Host may use stateless DHCPv6 for
   obtaining other information of interest such as DNS and etc.

   B. IPv6 WLAN host can use DHCPv6 [RFC3315] to get a IPv6 address
   from the DHCPv6 server.  In this case the DHCPv6 server would be
   located in the SP core network and Edge Router would act simply as
   a DHCP Relay Agent.  This option
                                                        |
                                                     +------+
                                                     |AAA   |
                                                     |Server|
                                                     +------+
                               Figure 9.1.2

9.1.2.1 IPv6 Related Infrastructure Changes

   IPv6 is similar to what we do today deployed in
   case of DHCPv4. It is important to note that host implementation of
   stateful auto-configuration is rather limited at this time and this
   should be considered if choosing this address assignment option.

   When a customer WLAN Router is present, scenario by upgrading the following devices
   to dual-stack: WLAN Host has two Host, WLAN Router (if present), Access Router
   and Edge Router.

9.1.2.2 Addressing

   There are three possible options as well in this scenario for acquiring IPv6 address. address
   assignment:

   A. The WLAN Edge Router may be assigned a prefix between /48 and /64
   depending on the SP policy and customer requirements. If interface facing towards the WLAN Access Router has multiple networks connected to is
   statically configured with /64 prefix. The Access Router receives/
   configures an /64 prefix on its interfaces, the interface facing towards Edge
   Router through stateless auto-configuration. The network
   administrator will have to configure the /64 prefixes to the WLAN Access
   Router interfaces connecting the WLAN Hosts on interface facing towards the customer site. premises. The WLAN Hosts
   Host/Router connected to these interfaces this interface can automatically configure
   themselves using stateless auto-configuration with /64 prefix.

   B. The This option uses DHCPv6 [RFC3315] for IPv6 prefix assignments to
   the WLAN Host/Router. There is no use of DHCP PD or stateless
   auto-configuration in this option. The DHCPv6 server can be located
   on the Access Router, on the Edge Router or somewhere in the SP
   network. In this case depending on where the DHCPv6 server is
   located, Access Router or the Edge Router would relay the DHCPv6
   requests.

   C. It can use its link-local address to communicate with the ER.
   It can also dynamically acquire through stateless autoconfiguration
   the address for the link between itself and the ER.  This step is
   followed by a request via DHCP-PD for a prefix shorter than /64 that
   in turn is divided in /64s and assigned to its interfaces connecting
   the hosts on the customer site.

   In this option, the WLAN Access Router would act as a requesting router
   and Edge Router would act as delegating router. Once prefix is
   received by the WLAN Access Router, it assigns /64 prefixes to each of
   its interfaces connecting the WLAN Hosts Host/Router on the customer site. The
   WLAN Hosts Host/Router connected to these interfaces can automatically
   configure themselves using stateless auto-configuration with /64
   prefix. Currently the DHCP-PD functionality cannot be implemented if
   the DHCP-PD server is not the ER. Edge Router. If the DHCP-PD messages
   are relayed, the Edge Router does not have a mechanism to learn the
   assigned prefixes and thus install the proper routes to make that
   prefix reachable. Work is being done to address this issue, one idea
   being to provide the Edge Router with a snooping mechanism. The
   uplink to the ISP network is configured with a /64 prefix as well.

   Usually it

   It is easier for the SPs to stay with the DHCP PD and stateless
   auto-configuration model and point the clients to a central
   server for DNS/domain information, proxy configurations and
   etc. others.
   Using this model the SP provider could change prefixes on the fly and
   the WLAN Access Router would simply pull the newest prefix based on the
   valid/preferred lifetime.

   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 maximum summarization as possible at the Edge Router. Other
   information of interest to the host, such as DNS, is provided
   through stateful [RFC3315] and stateless [RFC3736] DHCPv6.

9.1.1.3

9.1.2.3 Routing

   The WLAN Host/Router are configured with a default route that points
   to the Edge router. Access Router. No routing protocols are needed on these
   devices which generally have limited resources.

   If the Access Router is owned by an Access Provider, then the Access
   Router can have a default route, pointing towards the SP Edge
   Router. The Edge Router runs the IGP used in the SP network such as
   OSPFv3 or IS-IS for IPv6. The connected prefixes have to be
   redistributed. If DHCP-PD is used, with every delegated prefix a
   static route is installed by the Edge Router. For this reason the
   static routes must be redistributed. Prefix summarization should be
   done at the Edge Router. When DHCP-PD

   If the Access Router is used, owned by the SP, then Access Router will also
   run IPv6 IGP has and will be part of SP IPv6 routing domain (OSPFv3
   or IS-IS). The connected prefixes have to redistribute the be redistributed. If
   DHCP-PD is used, with every delegated prefix a static routes route is
   installed
   during by the process of prefix delegation.

9.1.2 Access Router Between AP and SP Edge Router

   When a Router. For this reason the static routes
   must be redistributed. Prefix summarization should be done at the
   Access Router is present between AP Router.

9.1.3 PPP Based Model

   PPP TERMINATED AGGREGATION (PTA) and Edge Router, the AP
   continues to work L2TPv2 ACCESS AGGREGATION (LAA)
   models as a bridge, bridging IPv4 discussed in sections 7.2.2 and 7.2.3 respectively can
   also be deployed in IPv6 packets from WLAN Host/Router to Access/Edge Router and vice versa. The environment.

9.1.3.1  PTA Model in IPv6 WLAN Environment

   While deploying the PTA model in IPv6 WLAN environment the Access
   Router could is Layer3 aware and it has to be part of SP network or owned by a separate Access
   Provider.

   When WLAN Host initiates upgraded to support IPv6.
   Since the connection, Access Router terminates the AAA authentication and
   association process with PPP sessions initiated by
   WLAN AP will be similar as explained in
   section 9.1.1. Host/Router, it has to support PPPoE with IPv6.

   Figure 9.1.2 9.1.3.1 describes the PTA Model in IPv6 WLAN architecture when Access Router is
   located between AP and Edge Router. environment

    Customer Premises|        Access Provider       |Service Provider
                     |                              |

  +------+        +--+ +--------------+ +----------+ +------+
  |WLAN  |  ----  |  | |              | |Underlying| |Edge  |
  |Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP
  |Router|  ----  |  | |              | |          | |      |  Network
  +------+        +--+ +--------------+ +----------+ +------+
                                                        |
    <--------------------------->                    +------+

                PPP                                  |AAA   |
                                                     |Server|
                                                     +------+

                             Figure 9.1.2

9.1.2.1 9.1.3.1

9.1.3.1.1  IPv6 Related Infrastructure Changes

   IPv6 is deployed in this scenario by upgrading the following
   devices to dual-stack: WLAN Host, WLAN Router (if present),
   Access Router and Edge Router.

9.1.2.2

9.1.3.1.2 Addressing

   There are three possible options in this scenario for IPv6 address
   assignment:

   A. The Edge Router interface facing towards the Access Router is
   statically configured with /64 prefix. The Access Router receives/
   configures an /64 prefix on its interface facing towards Edge
   Router through stateless auto-configuration. The network
   administrator will have to configure the /64 prefixes to the Access
   Router interface facing towards the customer premises.

   The WLAN
   Host/Router connected addressing techniques described in section 7.2.2.2 applies to this interface can automatically configure
   themselves using stateless auto-configuration with /64 prefix.

   B. This option uses DHCPv6 [RFC3315] for
   IPv6 prefix assignments to
   the WLAN Host/Router. There is no use of DHCP PD or stateless
   auto-configuration in this option. The DHCPv6 server can be located
   on the Access Router, on the Edge Router or somewhere in the SP
   network. In this case depending on where the DHCPv6 server is
   located, Access Router or the Edge Router would relay the DHCPv6
   requests.

   C. It can use its link-local address to communicate with the ER.
   It can also dynamically acquire through stateless autoconfiguration
   the address for the link between itself and the ER.  This step is
   followed by a request via DHCP-PD for a prefix shorter than /64 that
   in turn is divided PTA scenario as well.

9.1.3.1.3 Routing

   The routing techniques described in /64s and assigned section 7.2.2.3 applies to its interfaces connecting
   the hosts on
   IPv6 WLAN PTA scenario as well.

9.1.3.2  LAA Model in IPv6 WLAN Environment

   While deploying the customer site.

   In this option, LAA model in IPv6 WLAN environment the Access
   Router would act as a requesting router
   and Edge Router would act as delegating router. Once prefix is
   received by the Access Router, Layer3 aware and it assigns /64 prefixes has to each of its
   interfaces connecting the WLAN Host/Router on customer site. be upgraded to support IPv6.
   The PPP sessions initiated by WLAN Host/Router connected are forwarded over
   the L2TPv2 tunnel to these interfaces can automatically configure
   themselves using stateless auto-configuration with /64 prefix.
   Currently the DHCP-PD functionality cannot be implemented if aggregation point in the
   DHCP-PD server SP network. The
   Access Router must have the capability to support L2TPv2 for IPv6.

    Figure 9.1.3.2 describes the LAA Model in IPv6 WLAN environment

    Customer Premises|        Access Provider       |Service Provider
                     |                              |

  +------+        +--+ +--------------+ +----------+ +------+
  |WLAN  |  ----  |  | |              | |Underlying| |Edge  |
  |Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP
  |Router|  ----  |  | |              | |          | |      |  Network
  +------+        +--+ +--------------+ +----------+ +------+
                                                        |
    <-------------------------------------------------->|
                            PPP                         |
                                 <--------------------->|
                                            L2TPv2      |
                                                     +------+
                                                     |AAA   |
                                                     |Server|
                                                     +------+

                             Figure 9.1.3.2

9.1.3.2.1  IPv6 Related Infrastructure Changes

   IPv6 is not deployed in this scenario by upgrading the following
   devices to dual-stack: WLAN Host, WLAN Router (if present),
   Access Router and Edge Router. If the DHCP-PD messages

9.1.3.2.2 Addressing

   The addressing techniques described in section 7.2.3.2 applies to
   IPv6 WLAN LAA scenario as well.

9.1.3.2.3 Routing

   The routing techniques described in section 7.2.3.3 applies to
   IPv6 WLAN LAA scenario as well.

9.2 IPv6 Multicast

   The typical multicast services offered are
   relayed, video/audio streaming
   where the Edge Router does not have IPv6 WLAN Host joins a mechanism to learn the
   assigned prefixes multicast group and thus install receives the proper routes to make that
   prefix reachable. Work
   content. This type of service model is being done well supported through
   PIM-SSM which is enabled throughout the SP network. MLDv2 is required
   for PIM-SSM support.  Vendors can choose to address this issue, one idea
   being implement features that
   allow routers to provide the Edge Router with a snooping mechanism. The
   uplink map MLDv1 group joins to the ISP network is configured with a /64 prefix as well. predefined sources.

   It is easier for the SPs important to stay with the DHCP PD and stateless
   auto-configuration model and point note that in the clients to shared wireless environments
   multicast can have a central
   server for DNS/domain information, proxy configurations and others.
   Using significant bandwidth impact. For this model the provider could change prefixes on reason
   the fly bandwidth allocated to multicast traffic should be limited and
   the Access Router would simply pull the newest prefix
   fixed based on the
   valid/preferred lifetime.

   As mentioned before overall capacity of the prefixes wireless specification
   used for subscriber links and the
   ones delegated via DHCP-PD should 802.11a, 802.11b or 802.11g.

   The IPv6 WLAN Hosts can also join desired multicast groups as
   long as they are enabled to support MLDv1 or MLDv2. If a
   WLAN/Access Routers are used then they have to be planned enabled to
   support MLDv1 and MLDv2 in a manner that
   allows maximum summarization possible at order to process the Edge Router. Other
   information requests of interest to the host, such as DNS, is provided
   through stateful [RFC3315] and stateless [RFC3736] DHCPv6.

9.1.2.3 Routing

   The
   IPv6 WLAN Host/Router are configured with a default route that points Hosts. The WLAN/Access Router should also needs to be
   enabled to support PIM-SSM in order to send PIM joins up to the Access
   Edge Router. No routing protocols are needed When enabling this functionality on these
   devices which have a WLAN/Access
   Router, its limited resources.

   If resources should be taken into consideration.
   Another option would be for the Access WLAN/Access Router is owned by an Access Provider, then to support
   MLD proxy routing.

   The Edge Router has to be enabled to support MLDv1 and MLDv2 in
   order to process the Access requests coming from IPv6 WLAN Host or
   WLAN/Access Router can have a default route, pointing (if present). The Edge Router has also needs
   to be enabled for PIM-SSM in order to receive joins from IPv6
   WLAN Hosts or WLAN/Access Router (if present) and send joins
   towards the SP Edge
   Router. The core.

   MLD authentication, authorization and accounting is usually
   configured on the Edge Router runs the IGP used in order to enable the SP network such as
   OSPFv3 or IS-IS for IPv6. The connected prefixes have to do
   billing for the content services provided. Further investigation
   should be
   redistributed. If DHCP-PD is used, with every delegated prefix a
   static route is installed by made in investigating alternative mechanisms that would
   support these functions.

   Concerns have been raised in the Edge Router. past related to running IPv6
   multicast over WLAN links.  Potentially these are same kind of
   issues when running any Layer3 protocol over a WLAN link that has a
   high loss-to-signal ratio, where certain frames that are multicast
   based are dropped when settings are not adjusted properly. For
   instance this reason the
   static routes must be redistributed. Prefix summarization should be behavior is similar to IGMP host membership report,
   when done at the Edge Router.

   If the Access Router on a WLAN link with high loss-to-signal ratio and high
   interference.

   This problem is owned by the SP, then Access Router will also
   run inherited to WLAN that can impact both IPv4 and IPv6 IGP
   multicast packets and will be part of SP not specific to IPv6 routing domain (OSPFv3 multicast.

   While deploying WLAN (IPv4 or IS-IS). The connected prefixes have to be redistributed. If
   DHCP-PD is used, with every delegated prefix a static route is
   installed by the Access Router. For this reason the static routes
   must be redistributed. Prefix summarization IPv6), one should be done at adjust their
   broadcast/multicast settings if they are in danger of dropping
   application dependent frames. These problems are usually caused when
   AP are placed too far apart (not following the
   Access Router.

9.1.3 PPP Based Model

   PPP TERMINATED AGGREGATION (PTA) distance limitations),
   high interference and L2TPv2 ACCESS AGGREGATION (LAA)
   models etc. These issues may impact a real multicast
   application such as discussed in sections 7.2.2 and 7.2.3 respectively can
   also be deployed in streaming video or basic operation of IPv6 WLAN environment.

9.1.3.1  PTA Model in if
   the frames were dropped. Basic IPv6 WLAN Environment

   While deploying communications uses functions
   such as Duplicate Address Detection (DAD), Router and Neighbor
   Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA)
   and etc. which could be impacted by the PTA model in above mentioned issues as
   these frames are Layer 2 Ethernet multicast frames.

   Please refer to section 7.3 for more IPv6 WLAN environment the Access
   Router multicast details.

9.3 IPv6 QoS

   Today, QoS is Layer3 aware and done outside of the WiFi domain but it has to be upgraded is
   nevertheless important to support IPv6.
   Since the Access Router terminates overall deployment.

   The QoS configuration is particularly relevant on the PPP sessions initiated by
   WLAN Host/Router, it has Edge Router in
   order to support PPPoE manage resources shared amongst multiple subscribers
   possibly with IPv6.

   Figure 9.1.3.1 describes various service level agreements (SLA). Although, the PTA Model in IPv6
   WLAN environment

    Customer Premises| Host/Router and Access Provider       |Service Provider
                     |                              |

  +------+        +--+ +--------------+ +----------+ +------+
  |WLAN  |  ----  |  | |              | |Underlying| |Edge  |
  |Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP
  |Router|  ----  |  | |              | |          | |      |  Network
  +------+        +--+ +--------------+ +----------+ +------+
                                                        |
    <--------------------------->                    +------+
                PPP                                  |AAA   |
                                                     |Server|
                                                     +------+

                             Figure 9.1.3.1

9.1.3.1.1 could also be configured for QoS.
   This includes support for IPv6 Related Infrastructure Changes classifiers, so that data traffic
   to/from IPv6 is deployed in this scenario by upgrading the following
   devices to dual-stack: WLAN Host, WLAN Router (if present), Host/Router, Access Router and Edge Router.

9.1.3.1.2 Addressing

   The addressing techniques described in section 7.2.2.2 applies to
   IPv6 WLAN PTA scenario as well.

9.1.3.1.3 Routing

   The routing techniques described in section 7.2.2.3 applies to
   IPv6 WLAN PTA scenario as well.

9.1.3.2  LAA Model in IPv6 WLAN Environment

   While deploying the LAA model in Router can be
   classified appropriately into different service flows (SF) and be
   assigned appropriate priority. Appropriate classification criteria
   would need to be implemented for IPv6 WLAN environment unicast and multicast traffic.

   On the Access Edge Router is Layer3 aware and it has the subscriber facing interfaces have to be upgraded
   configure to support IPv6.
   The PPP sessions initiated by WLAN Host/Router are forwarded over police the L2TPv2 tunnel inbound customer traffic and shape the
   traffic outbound to the aggregation point in customer, based on the SP network. The
   Access Router must have SLA. Traffic
   classification and marking should also be done on the capability Edge router in
   order to support L2TPv2 the various types of customer traffic: data, voice,
   video. The same IPv4 QoS concepts and methodologies should be applied
   for IPv6.

   Figure 9.1.3.2 describes the LAA Model in IPv6 WLAN environment

    Customer Premises|        Access Provider       |Service Provider
                     |                              |

  +------+        +--+ +--------------+ +----------+ +------+
  |WLAN  |  ----  |  | |              | |Underlying| |Edge  |
  |Host/ |-(WLAN)-|AP|-|Access Router |-|Technology|-|Router|=>SP
  |Router|  ----  |  | |              | |          | |      |  Network
  +------+        +--+ +--------------+ +----------+ +------+
                                                        |
    <-------------------------------------------------->|
                            PPP                         |
                                 <--------------------->|
                                            L2TPv2      |
                                                     +------+
                                                     |AAA   |
                                                     |Server|
                                                     +------+

                             Figure 9.1.3.2

9.1.3.2.1  IPv6 Related Infrastructure Changes IPv6 as well.

   It is deployed important to note that when traffic is encrypted end-to-end,
   the traversed network devices will not have access to many of the
   packet fields used for classification purposes. In these cases
   routers will most likely place the packets in the default classes.
   The QoS design should take into consideration this scenario by upgrading the following
   devices and try
   to use mainly IP header fields for classification purposes.

9.4 IPv6 Security Considerations

   There are limited changes that have to dual-stack: WLAN Host, be done for WLAN Router (if present),
   Access Router and Edge Router.

9.1.3.2.2 Addressing

   The addressing techniques described Host/Router
   in section 7.2.3.2 applies order to
   IPv6 WLAN LAA scenario as well.

9.1.3.2.3 Routing enhance security. The routing techniques Privacy extensions [RFC3041] for
   autoconfiguration should be used by the hosts with the same
   consideration for host traceability as described in section 7.2.3.3 applies to 7.5.
   IPv6 firewall functions should be enabled on the WLAN LAA scenario as well.

9.2 IPv6 Multicast Host/Router if
   present.

   The typical multicast ISP provides security against attacks that come form its own
   subscribers but it could also implement security services offered are video/audio streaming
   where that
   protect its subscribers from attacks sourced from the IPv6 WLAN Host joins a multicast group and receives outside of
   its network. Such services do not apply at the
   content. This type access level of service model is well supported through
   PIM-SSM which the
   network discussed here.

   If the host authentication at hot spots is enabled throughout done using web based
   authentication system then the SP network. MLDv2 level of security would depend on
   the particular implementation. User credential should never be sent
   as clear text via HTTP. Secure HTTP (HTTPS) should be used between
   the web browser and authentication server.  The authentication
   server could use RADIUS and LDAP services at the back end.

   Authentication is required an important aspect of securing WLAN networks
   prior to implementing Layer 3 security policies. This would help
   for PIM-SSM support.  Vendors can choose example avoid threats to the ND or stateless autoconfiguration
   processes. 802.1x provides the means to secure the network access
   however, the many types of EAP (PEAP, EAP-TLS, EAP-TTLS, EAP-FAST,
   LEAP) and the capabilities of the hosts to implement support some of the
   features that
   allow routers to map MLDv1 group joins to predefined sources.

   It is important might make it difficult to note that implement a comprehensive and
   consistent policy.

   If any layer two filters for Ethertypes are in place, the shared wireless environments
   multicast can have a significant bandwidth impact. NAP must
   permit the IPv6 Ethertype (0X86DD).

   The device that is the Layer3 next hop for the subscribers
   (Access or Edge Router) should protect the network and the other
   subscribers against attacks by one of the provider customers.
   For this reason
   the bandwidth allocated to multicast traffic uRPF and ACLs should be limited and
   fixed based used on all interfaces
   facing subscribers. Filtering should be implemented with regard for
   the overall capacity operational requirements of the wireless specification
   used 802.11a, 802.11b or 802.11g.

   The IPv6 WLAN Hosts can also join desired multicast groups as
   long as they are enabled to support MLDv1 or MLDv2. If a
   WLAN/Access Routers are used then they have to [Security considerations for
   IPv6]. Authentication and authorization should be enabled to
   support MLDv1 used wherever
   possible.

   The Access and MLDv2 in order to process the requests Edge Router should protect their processing
   resources against floods of the
   IPv6 WLAN Hosts. valid customer control traffic such as:
   RS, NS, MLD Requests. Rate limiting should be implemented on all
   subscriber facing interfaces. The WLAN/Access Router emphasis should also needs to be
   enabled to support PIM-SSM in order to send PIM joins up to the
   Edge Router. When enabling this functionality placed on a WLAN/Access
   Router, its limited resources
   multicast type traffic as it is most often used by the IPv6 control
   plane.

9.5 IPv6 Network Management

   The necessary instrumentation (such as MIBs, NetFlow Records, etc)
   should be taken into consideration. available for IPv6.

   Usually, NSPs manage the edge routers by SNMP. The Edge Router has to SNMP transport can
   be enabled to support MLDv1 done over IPv4 if all managed devices have connectivity over both
   IPv4 and MLDv2 in
   order IPv6. This would imply the smallest changes to process the requests coming from existent
   network management practices and processes. Transport over IPv6 WLAN Host or
   WLAN/Access Router (if present). The Edge Router has could
   also needs
   to be enabled for PIM-SSM in order to receive joins from IPv6
   WLAN Hosts or WLAN/Access Router (if present) implemented and send joins
   towards it might become necessary if IPv6 only
   islands are present in the SP core.

   MLD authentication, authorization and accounting is usually
   configured network. The management stations are
   located on the Edge Router core network. Network Management Applications should
   handle IPv6 in order to enable the SP a similar fashion to do
   billing for the content services provided. Further investigation IPv4 however they should be made in investigating alternative mechanisms that would also
   support these functions.

   The IETF draft [IPv6 over 802.11] mentions features specific to IPv6 (such as Neighbor monitoring).

   In some of cases service providers manage equipment located on customers
   LANs.

10. Broadband Power Line Communications (PLC)

   This section describes the concerns
   related to running IPv6 multicast over WLAN links.  Potentially
   these are same kind of issues when running any Layer3 protocol
   over a WLAN link that has a high loss-to-signal ratio, where certain
   frames that are multicast based are dropped when settings are not
   adjusted properly. For instance deployment in Power Line
   Communications (PLC) Access Networks. There may be other choices,
   but it seems that this behavior is similar the best model to IGMP host
   membership report, when done on a WLAN link with high loss-to-signal
   ratio follow. Lessons learnt
   from Cable, Ethernet and high interference. This problem is inherited to even WLAN that
   can impact both IPv4 and IPv6 multicast packets access networks may be applicable
   also.

   Power Line Communications are also often called Broadband Power Line
   (BPL) and not specific some times even Power Line Telecommunications (PLT).

   PLC/BPL can be used for providing, with todays technology, up to
   IPv6 multicast.

   While deploying WLAN (IPv4 or IPv6), one should adjust their
   broadcast/multicast settings if they are in danger
   200Mbps (total, upstream+downstream) by means of dropping
   application dependent frames. These problems are usually caused when
   AP are placed too far apart (not following the power grid. The
   coverage is often the last half mile (typical distance limitations),
   high interference from the
   Medium-to-Low Voltage transformer to the customer premise meter),
   and etc. These issues may impact a real multicast
   application such of course, as streaming video or basic operation an in-home network (which is out of IPv6 if the frames were dropped. Basic IPv6 communications uses functions scope of
   this document).

   The bandwidth in a given PLC/BPL segment is shared among all the
   customers connected to that segment (often the customers connected
   to the same medium-to-low voltage transformer). The number of
   customers can vary depending on different factors, such as Duplicate Address Detection (DAD), Router and Neighbor
   Solicitations (RS, NS), Router distances
   and Neighbor Advertisement (RA, NA)
   and etc. which even countries (from a few customers, just 5-6, up to 100-150).

   PLC/BPL could also be used in the Medium Voltage network (often
   configured as Metropolitan Area Networks), but this is also out
   of the scope of this document, as it will be part of the core
   network, not the access one.

   Just for information/clarification, often the PLC/BPL access
   networks use hybrid layer 2 combinations either with PLC/BPL in the
   medium voltage, point to point links, wireless links, satellite,
   etc., but once more, this seems to be impacted by out of the above mentioned issues scope of this
   document, as
   these frames those means are Layer 2 Ethernet multicast frames.

   Please refer to section 7.3 transparent, for more IPv6 multicast details.

9.3 IPv6 QoS

   Today, QoS is done outside the purpose of this
   document, to the WiFi domain but it last half mile access network deployed with PLC/BPL.

10.1 PLC/BPL Access Network Elements

   This section describes the different elements commonly used in
   PLC/BPL access networks.

   Head End (HE): It is
   nevertheless important the router that connects the PLC/BPL access
   network (the power grid), located at the medium-to-low voltage
   transformer, to the overall deployment. core network. The QoS configuration HE PLC/BPL interface appears
   to each customer as a single virtual interface, all of them sharing
   the same physical media.

   Repeater (RPT): It is particularly relevant on the Edge Router device which may be required in
   order some
   circumstances to manage resources shared amongst multiple subscribers
   possibly with various service level agreements (SLA). Although, improve the
   WLAN Host/Router and Access Router signal on the PLC/BPL. This may be the
   case if there are many customers in the same segment or building.
   Often is a bridge, but it could also be configured for QoS.
   This includes support also a router if for IPv6 classifiers, so that data example
   there is a lot of peer-to-peer traffic
   to/from IPv6 WLAN Host/Router, in a building and due to the
   master-slave nature of the PLC/BPL technology, is required to improve
   the performance within that segment. For simplicity, in this
   document, it will be considered that the RPT is always a transparent
   layer 2 bridge, so it may be present or not (from the layer 3 point
   of view).

   Customer Premise Equipment (CPE): It is the modem (internal to the
   host), modem/bridge (BCPE), router (RCPE) or any combination among
   those (i.e. modem+bridge/router), located at the customer premise.

   Edge Router (ER)

   Figure 10.1 depicts all the network elements indicated above

  Customer Premises | Network Access Router and Provider | Network Service Provider
         CP                     NAP                        NSP

  +-----+  +------+  +-----+        +------+   +--------+
  |Hosts|--| RCPE |--| RPT |--------+  HE  +---+ Edge   |       ISP
  +-----+  +------+  +-----+        |      |   | Router can be
   classified appropriately into different service flows (SF) +===> Network
                                    +--+---+   +--------+
  +-----+  +------+  +-----+           |
  |Hosts|--| BCPE |--| RPT |-----------+
  +-----+  +------+  +-----+

                                 Figure 10.1

   The logical topology and be
   assigned appropriate priority. Appropriate classification criteria
   would need design of PLC/BPL is very similar to be implemented for
   Ethernet Broadband Networks as discussed in section 8.

10.2 Deploying IPv6 unicast in IPv4 PLC/BPL

   The most simplistic and multicast traffic.

   On efficient model, considering the Edge Router nature of
   the subscriber facing interfaces have to be
   configure PLC/BPL networks, is to police the inbound customer traffic and shape see the
   traffic outbound network as a point-to-point one
   to each customer. Even if several customers share the customer, based on same physical
   media, the SLA. Traffic
   classification and marking should traffic is not visible among them because each one uses
   different channels, which are in addition encrypted by means of 3DES.

   Furthermore, if required, VLANs could also be done on used, as already
   described for the Edge router in Ethernet case.

   In order to support maintain the various types of customer traffic: data, voice,
   video. The same IPv4 QoS deployment concepts and methodologies should be applied
   for business models
   proven and used with existing revenue generating IPv4 services,
   the IPv6 as well.

   It is important to note that when traffic is encrypted end-to-end,
   the traversed network devices deployment will not have access to many of match the
   packet fields used IPv4 one. Under certain
   circumstances where new service types or service needs justify it,
   IPv4 and IPv6 network architectures could be different. Both
   approaches are very similar to those already described for classification purposes. the
   Ethernet case.

10.2.1 IPv6 Related Infrastructure Changes

   In these cases
   routers will most likely place this scenario the packets in RPT is layer 3 unaware, but not the default classes.
   The QoS design Head End,
   which should take into consideration this scenario and try be upgraded to use mainly IP header fields for classification purposes.

9.4 IPv6 Security Considerations

   There are limited changes that support IPv6. Similarly other devices
   which have to be done for WLAN Host/Router
   in order upgraded to enhance security. dual stack: Hosts, RCPE and Edge Router.

10.2.2 Addressing

   The Privacy extensions [RFC3041] for
   autoconfiguration should be used by 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 with on the
   subscriber site belong to the same
   consideration for host traceability as described in section 7.5.
   IPv6 firewall functions should be enabled /64 subnet that is statically
   configured on the WLAN Host/Router if
   present. HE. The ISP provides security against attacks that come form its own
   subscribers but it could also implement security services that
   protect its subscribers from attacks sourced from hosts can use stateless
   autoconfiguration or stateful DHCPv6 based configuration to
   acquire an address via the outside of
   its network. Such services do HE.

   If a RCPE is present:

   A. It is statically configured with an address on the /64 subnet
      between itself and the HE, and with /64 prefixes on the
      interfaces connecting the hosts on the customer site. This is not apply at
      a desired provisioning method being expensive and difficult to
      manage.

   B. It can use its link-local address to communicate with the access level of HE.
      It can also dynamically acquire through stateless
      autoconfiguration the
   network discussed here.

   If address for the host authentication at hot spots link between itself and
      the HE. This step is done using web based
   authentication system then followed by a request via DHCP-PD for a
      prefix shorter than /64 (typically /48) that in turn is divided
      in /64s and assigned to its interfaces connecting the level of security would depend hosts on
      the particular implementation. User credential should never be sent
   as clear text via HTTP. Secure HTTP (HTTPS) customer site. This should be used between the web browser preferred provisioning
      method, being cheaper and authentication server. easier to manage.

   The authentication server Edge Router needs to have a prefix considering that each
   customer in general will receive a /48 prefix, and that each HE
   will accommodate customers. Consequently each HE will require
   n x /48 prefixes.

   It could be possible to use RADIUS a kind of Hierarchical Prefix
   Delegation to automatically provision the required prefixes and LDAP services at
   fully auto-configure the back end.

   If any layer two filters HEs, and consequently reduce the network
   setup, operation and maintenance cost.

   The prefixes used for Ethertypes are subscriber links and the ones delegated via
   DHCP-PD should be planned in place, a manner that allows as much
   summarization as possible at the NAP must
   permit Edge Router.

   Other information of interest to the IPv6 Ethertype (0X86DD). host, such as DNS, is provided
   through stateful [RFC3315] and stateless [RFC3736] DHCPv6.

10.2.3 Routing

   The device HE are configured with a default route that is the Layer3 next hop for points to
   the subscribers
   (Access or Edge Router) should protect Router. No routing protocols are needed on these devices
   which generally have limited resources.

   The Edge Router runs the network and IPv6 IGP used in the other
   subscribers against attacks NSP: OSPFv3 or IS-IS.
   The connected prefixes have to be redistributed. If DHCP-PD is used,
   with every delegated prefix a static route is installed by one of the provider customers. HE
   For this reason uRPF and ACLs should the static routes must also be used on all interfaces
   facing subscribers. Filtering redistributed.
   Prefix summarization should be implemented with regard
   for done at the operational requirements of HE.

10.3 IPv6 (ICMPv6 types).
   Authentication and authorization should be used wherever possible. Multicast

   The Access and considerations regarding IPv6 Multicast for Ethernet are also
   applicable here, in general, but assuming the Edge Router should protect their processing
   resources against floods nature of valid customer control traffic such as:
   RS, NS, MLD Requests. Rate limiting should PLC/BPL
   being a shared media. If a lot of Multicast is expected, it may be implemented on all
   subscriber facing interfaces. The emphasis should
   worth considering using RPT which are layer 3 aware. In that case,
   one extra layer of Hierarchical DHCP-PD could be placed on
   multicast type traffic as it is most often used by considered, in
   order to facilitate the deployment, operation and maintenance of
   the network.

10.4 IPv6 control
   plane.

9.5 IPv6 Network Management QoS

   The necessary instrumentation (such as MIBs, NetFlow Records, etc)
   should be available considerations introduced for IPv6.

   Usually, NSPs manage QoS in Ethernet are also
   applicable here. PLC/BPL networks support QoS, which basically are
   no different whether the edge routers by SNMP. The SNMP transport can
   be done over IPv4 if all managed devices have connectivity over both is IPv4 and or IPv6. This would imply the smallest changes It is necessary
   to understand that the existent specific network management practices and processes. Transport over IPv6 could
   also characteristics, such as the
   variability that may be implemented and it might become necessary if introduced by electrical noise, towards which
   the PLC/BPL network will automatically self-adapt.

10.5 IPv6 only
   islands Security Considerations

   There are present no differences in terms of security considerations if
   compared with the network. The management stations are
   located on the core network. Ethernet case.

10.6 IPv6 Network Management Applications should
   handle IPv6

   There are no differences in a similar fashion to IPv4 however they should also
   support features specific to IPv6 (such as Neighbor monitoring).

   In some cases service providers manage equipment located on customers
   LANs.

10. terms of network management if compared
   with the already described Ethernet case.

11. Gap Analysis

   Several aspects of deploying IPv6 over SP Broadband networks were
   highlighted in this document, aspects that require additional work
   in order to facilitate native deployments as summarized below:

   A. As mentioned in section 6, changes will need to be made to the
   DOCSIS specification in order for SPs to deploy native IPv6 over
   cable networks. The CM and CMTS will both need to support IPv6
   natively in order to forward IPv6 unicast and multicast traffic.
   This is required for IPv6 Neighbor Discovery to work over DOCSIS
   cable networks. Additional classifiers need to be added to the
   DOCSIS specification in order to classify IPv6 traffic at the CM
   and CMTS in order to provide QoS.

   B. Currently the DHCP-PD functionality cannot be implemented if the
   DHCP-PD server is not the Edge Router. If the DHCP-PD messages are
   relayed, the Edge Router does not have a mechanism to learn the
   assigned prefixes and thus install the proper routes to make that
   prefix reachable. Work needs to be done to address this issue, one
   idea being to provide the Edge Router with a snooping mechanism. The
   uplink to the ISP network is configured with a /64 prefix as well.

   C. Section 7 stated that current RBE based IPv4 deployment might not
   be the best approach for IPv6 where the addressing space available
   gives the SP the opportunity to separate the users on different
   subnets. The differences between IPv4 RBE and IPv6 RBE were
   highlighted in section 7. If however, support and reason is found
   for a deployment similar to IPv4 RBE, then the environment becomes
   NBMA and the new feature should observe RFC2491 recommendations.

   D. Section 7 discussed the constraints imposed on a LAA based IPv6
   deployment by the fact that it is expected that the subscribers keep
   their assigned prefix regardless of LNS. A deployment approach was
   proposed that would maintain the addressing schemes contiguous and
   offers prefix summarization opportunities. The topic could be
   further investigated for other solutions or improvements.

   E. Sections 7 and 8 pointed out the limitations (previously
   documented in [IPv6 Multicast]) in deploying inter-domain ASM
   however, SSM based services seem more likely at this time. For such
   SSM based services of content delivery (video or Audio), mechanisms
   are needed to facilitate the billing and management of listeners.
   The currently available feature of MLD AAA is suggested however,
   other methods or mechanisms might be developed and proposed.

   F. In relation to section 9, the IETF draft [IPv6 over 802.11]
    mentions some of the concerns have been raised related to
   running IPv6 multicast over WLAN links. Potentially these are same
   kind of issue when running any Layer3 protocol over a WLAN link
   that has a high loss-to-signal ratio, certain frames that are
   multicast based are dropped when settings are not adjusted
   properly. For instance this behavior is similar to IGMP host
   membership report, when done on a WLAN link with high
   loss-to-signal ratio and high interference. This problem is
   inherited to WLAN that can impact both IPv4 and IPv6 multicast
   packets and not specific to IPv6 multicast.
    The IETF draft [IPv6 over 802.11] raises some other concerns as
    well related to IPv6 mechanisms and WLAN, which should be addressed
    and resolved by the standard bodies.

   G. The Privacy Extensions were mentioned as a popular means to
   provide some form of host security. ISPs can track relatively
   easily the prefixes assigned to subscribers. If however the ISPs
   are required by regulations to track their users at host address
   level, the Privacy Extensions [RFC3041] can be implemented only in
   parallel with network management tools that could provide
   traceability of the hosts. Mechanisms should be defined to
   implement this aspect of user management.

   H. Tunnels are an effective way to avoid deployment dependencies on
   the IPv6 support on platforms that are out of the SP control (GWRs
   or CPEs) or over technologies that did not standardize the IPv6
   support yet (cable). They can be used in the following ways:

   i. Tunnels directly to the CPE or GWR with public or private IPv4
   addresses.
   ii. Tunnels directly to hosts with public or private IPv4 addresses.

   Recommendations on the exact tunneling mechanisms that can/should be
   used for last mile access need to be investigated further and should
   be covered in a future IETF draft.

   I. Through its larger address space, IPv6 allows SPs to assign
   fixed, globally routable prefixes to the links connecting each
   subscriber.

   This approach changes the provisioning methodologies that were used
   for IPv4. Static configuration of the IPv6 addresses for all these
   links on the Edge Routers or Access Routers might not be a scalable
   option. New provisioning mechanisms or features might need to be
   developed in order to deal with this issue.

   J. New deployment models are emerging for the Layer 2 portion of the
   NAP where individual VLANs are not dedicated to each subscriber. This
   approach allows Layer 2 switches to aggregate more then 4096 users.
   MAC Forced Forwarding [MFF] is an example of such an implementation
   where a broadcast domain is turned into a NBMA like environment by
   forwarding the frames based on both Source and Destination MAC
   addresses. Since these models are being adopted by the field, the
   implications of deploying IPv6 in such environments need to be
   further investigated.

   The outcome of solutions to some of these topics ranges from making
   a media access capable of supporting native IPv6 (cable) to
   improving operational aspects of native IPv6 deployments.

11.

12. Contributors

   We would like to thank Pekka Savola for his contribution, guidance
   and feedback in order to improve this document.

12.

13. Acknowledgements

   We would like to thank Brian Carpenter, Patrick Grossetete, Toerless
   Eckert, Madhu Sudan, Shannon McFarland and Benoit Lourdelet for their
   valuable comments. The authors would like to acknowledge the
   structure and information guidance provided to this work by
   [ISP the work of Mickels et
   al on Transition Scenarios].

13. Scenarios for ISP Networks.

14. References

Normative References

[RFC3053]
   Durand A., Fasano P., Guardini I., Lento D. "IPv6 Tunnel Broker",
   RFC3053, January 2001.

[RFC3056]
   Carpenter B., Moore K., "Connection of IPv6 Domains via IPv4 Clouds",
   RFC3056, February Aprilruary 2001.

[RFC2473]
   Conta A., Deering S., "Generic Packet tunneling in IPv6
   Specification", December 1998.

[RFC2893]
   Gilligan R., Nordmark E., "Transition Mechanisms for IPv6 Hosts
   and Routers", August 2000.

[RFC2529]
   Carpenter B., Jung C. "Transmission of IPv6 over IPv4 Domains
   without Explicit Tunnels", March 1999

[RFC3904]
   Huitema C., Austein R., Satapati S., van der Pol R., "Evaluation
   of IPv6 Transition Mechanisms for Unmanaged Networks", September 2000

[RFC3513]
   R. Hinden and S. Deering, "IP Version 6 Addressing Architecture",
   RFC3513, April 2003.

[RFC3736]
   Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
   Service for IPv6", RFC3736, April 2004.

[RFC3315]
   Droms, R., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
   RFC3315, July 2003.

[RFC2462]
   Thomson, S. and Narten, T.,  "IPv6 Stateless Address
   Autoconfiguration", RFC2462, December 1998.

[RFC3633]
   Troan, O. and Droms, R., "IPv6 Prefix Options for Dynamic Host
   Configuration Protocol (DHCP) version 6", RFC3633, December 2003.

[RFC3041]
   T. Narten and R. Draves, "Privacy Extensions for Stateless Address
   Autoconfiguration in IPv6," RFC3041, April 2001.

[RFC2516]
   Mamakos, L., "A Method for Transmitting PPP Over Ethernet (PPPoE)",
   RFC2516, February Aprilruary 1999.

[RFC2364]
   Gross, G., "PPP Over AAL5 (PPPoA)", RFC2516, July 1998.

[RFC2472]
   Haskin, D. and Allen, E., "IP Version 6 over PPP", RFC2472,
   December 1998.

[RFC2461]
   Narten, T., Nordmark, E. and Simpson, W., "Neighbor Discovery for
   IP Version 6 (IPv6)", RFC2461, December 1998.

[RFC2770]
   Meyer. D., "GLOP Addressing in 233/8", RFC2770, February April 2000

[RFC3646]
   Droms, R., "DNS Configuration options for Dynamic Host
   Configuration Protocol for IPv6 (DHCPv6)", RFC3646, December 2003.

[RFC3618]
   Fenner B., Meyer D., "Multicast Source Discovery Protocol (MSDP)",
   RFC3618, October 2003

Informative References

[Dual Stack Access]
   Shirasaki, et al., "A Model of IPv6/IPv4 Dual Stack Internet Access
   Service", draft-shirasaki-dualstack-service-04.txt (work in
   progress) ,April 2004.

[6PE] De Clercq J., et al., "Connecting IPv6 Islands across IPv4
   Clouds with BGP:, draft-ooms-v6ops-bgp-tunnel-04.txt, October 2004

[ISP Networks IPv6 Scenarios]
   Lind et, al., "Scenarios and Analysis for Introducing IPv6 into ISP
   Networks", draft-ietf-v6ops-isp-scenarios-analysis-03.txt (work in
   progress), June 2004. RFC 4029, March 2005.

[ISATAP]
   Templin F., et al., "Intra-Site Automatic Tunnel Addressing Protocol
   (ISATAP)", draft-ietf-ngtrans-isatap-12.txt, January 2003.

[Dynamic Tunnel]
   Palet J., et al., "Analysis of IPv6 Tunnel End-point Discovery
   Mechanisms", draft-palet-v6ops-tun-auto-disc-01.txt, June 2004.

[OPS]
   Nordmark E., Gilligan R. E., "Basic Transition Mechanisms for
   IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06.txt,
   September 2004.

[IPv6 over 802.11]
   Park, S., "Transmission of IPv6 Packets over 802.11/WLAN Networks",
   draft-daniel-ipv6-over-wifi-01.txt, (work in progress), July 2004

[ISP Transition Scenarios]
   Mickels, C., "Transition Scenarios for ISP Networks",
   draft-mickles-v6ops-isp-cases-05.txt,  March 2003

[DOCSIS 2.1 3.0 Proposal]
   Sudan, M.,
   Cisco Systems, "DOCSIS 2.1 3.0 Proposal", May 2004. April 2005.

[IPv6 Multicast]
   Savola, P. "IPv6 Multicast Deployment Issues",
   draft-mboned-ipv6-multicast-issues, February April 2004

[RF Interface]
   Cable Labs, "Radio Frequency Interface Specification
   SP-RFIv2.0-I02-020617", Jun 2002.

[BSR]
   Nidhi Bhaskar et all., "Bootstrap Router (BSR) Mechanism for PIM",
   draft-ietf-pim-sm-bsr-04.txt, January 2005

[Assisted Tunneling]
   A.Durand, F. Parent,"Requirements for assisted tunneling",
   draft-ietf-v6ops-assisted-tunneling-requirements-00.txt, June 2004

[ZeroConf]
   Suryanarayanan,

[v6tc]
   J. Pallet, et al., "Zero-Configuration "Goals for Tunneling Requirements",
   draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt, October, 2004 Configuration",
   draft-palet-v6tc-goals-tunneling-00.txt, August, 2005

[Security considerations for IPv6]
    Sean Convery, Darrin Miller, "IPv6 and IPv4 Threat Comparison
    and Best-Practice Evaluation"

Authors Addresses

   Salman Asadullah
   Cisco Systems, Inc.
   170 West Tasman Drive,
   San Jose, CA 95134, USA
   Phone: 408 526 8982
   Email: sasad@cisco.com

   Adeel Ahmed
   Cisco Systems, Inc.
   2200 East President George Bush Turnpike,
   Richardson, TX 75082, USA
   Phone: 469 255 4122
   Email: adahmed@cisco.com

   Ciprian Popoviciu
   Cisco Systems, Inc.
   7025-6 Kit Creek Road,
   Research Triangle Park, NC 27709, USA
   Phone: 919 392 3723
   Email: cpopovic@cisco.com

   Jordi Palet Martinez
   Consulintel
   San Jose Artesano, 1
   Alcobendas - Madrid
   E-28108 - Spain

   Phone: +34 91 151 81 99
   Fax:   +34 91 151 81 98
   Email: jordi.palet@consulintel.es

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology describe
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
   ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is
   subject to the rights, licenses and restrictions contained in BCP
   78, and except as set forth therein, the authors retain all their
   rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.