    Network Working Group                                       S. Asadullah
    Request for Comments: 4779                                      A. Ahmed
    Category: Informational                                     C. Popoviciu
                                                               Cisco Systems
                                                                   P. Savola
                                                                   CSC/FUNET
                                                                    J. Palet
                                                                 Consulintel
                                                                January 2007

           ISP IPv6 Deployment Scenarios in Broadband Access Networks

    Status of This Memo

       This memo provides information for the Internet community.  It does
       not specify an Internet standard of any kind.  Distribution of this
       memo is unlimited.

    Copyright Notice

       Copyright (C) The IETF Trust (2007).

    Abstract

       This document provides a detailed description of IPv6 deployment and
       integration methods and scenarios in today's Service Provider (SP)
       Broadband (BB) networks in coexistence with deployed IPv4 services.
       Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies
       that are currently deployed, and discussed in this document.  The
       emerging Broadband Power Line Communications (PLC/BPL) access
       technology is also discussed for completeness.  In this document we
       will discuss main components of IPv6 BB networks, their differences
       from IPv4 BB networks, and how IPv6 is deployed and integrated in
       each of these networks using tunneling mechanisms and native IPv6.

    Asadullah, et al.            Informational                      [Page 1]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    Table of Contents

       1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
       2.  Common Terminology . . . . . . . . . . . . . . . . . . . . . .  5
       3.  Core/Backbone Network  . . . . . . . . . . . . . . . . . . . .  5
         3.1.  Layer 2 Access Provider Network  . . . . . . . . . . . . .  5
         3.2.  Layer 3 Access Provider Network  . . . . . . . . . . . . .  6
       4.  Tunneling Overview . . . . . . . . . . . . . . . . . . . . . .  7
         4.1.  Access over Tunnels - Customers with Public IPv4
               Addresses  . . . . . . . . . . . . . . . . . . . . . . . .  7
         4.2.  Access over Tunnels - Customers with Private IPv4
               Addresses  . . . . . . . . . . . . . . . . . . . . . . . .  8
         4.3.  Transition a Portion of the IPv4 Infrastructure  . . . . .  8
       5.  Broadband Cable Networks . . . . . . . . . . . . . . . . . . .  9
         5.1.  Broadband Cable Network Elements . . . . . . . . . . . . .  9
         5.2.  Deploying IPv6 in Cable Networks . . . . . . . . . . . . . 10
           5.2.1.  Deploying IPv6 in a Bridged CMTS Network . . . . . . . 12
           5.2.2.  Deploying IPv6 in a Routed CMTS Network  . . . . . . . 14
           5.2.3.  IPv6 Multicast . . . . . . . . . . . . . . . . . . . . 23
           5.2.4.  IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . 24
           5.2.5.  IPv6 Security Considerations . . . . . . . . . . . . . 24
           5.2.6.  IPv6 Network Management  . . . . . . . . . . . . . . . 25
       6.  Broadband DSL Networks . . . . . . . . . . . . . . . . . . . . 26
         6.1.  DSL Network Elements . . . . . . . . . . . . . . . . . . . 26
         6.2.  Deploying IPv6 in IPv4 DSL Networks  . . . . . . . . . . . 28
           6.2.1.  Point-to-Point Model . . . . . . . . . . . . . . . . . 29
           6.2.2.  PPP Terminated Aggregation (PTA) Model . . . . . . . . 30
           6.2.3.  L2TPv2 Access Aggregation (LAA) Model  . . . . . . . . 33
           6.2.4.  Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 36
         6.3.  IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 38
           6.3.1.  ASM-Based Deployments  . . . . . . . . . . . . . . . . 39
           6.3.2.  SSM-Based Deployments  . . . . . . . . . . . . . . . . 39
         6.4.  IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 40
         6.5.  IPv6 Security Considerations . . . . . . . . . . . . . . . 41
         6.6.  IPv6 Network Management  . . . . . . . . . . . . . . . . . 42
       7.  Broadband Ethernet Networks  . . . . . . . . . . . . . . . . . 42
         7.1.  Ethernet Access Network Elements . . . . . . . . . . . . . 42
         7.2.  Deploying IPv6 in IPv4 Broadband Ethernet Networks . . . . 43
           7.2.1.  Point-to-Point Model . . . . . . . . . . . . . . . . . 44
           7.2.2.  PPP Terminated Aggregation (PTA) Model . . . . . . . . 46
           7.2.3.  L2TPv2 Access Aggregation (LAA) Model  . . . . . . . . 48
           7.2.4.  Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 50
         7.3.  IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 52
         7.4.  IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 53
         7.5.  IPv6 Security Considerations . . . . . . . . . . . . . . . 54
         7.6.  IPv6 Network Management  . . . . . . . . . . . . . . . . . 55

    Asadullah, et al.            Informational                      [Page 2]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       8.  Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . 55
         8.1.  WLAN Deployment Scenarios  . . . . . . . . . . . . . . . . 55
           8.1.1.  Layer 2 NAP with Layer 3 termination at NSP Edge
                   Router . . . . . . . . . . . . . . . . . . . . . . . . 56
           8.1.2.  Layer 3 Aware NAP with Layer 3 Termination at
                   Access Router  . . . . . . . . . . . . . . . . . . . . 59
           8.1.3.  PPP-Based Model  . . . . . . . . . . . . . . . . . . . 61
         8.2.  IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 63
         8.3.  IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 65
         8.4.  IPv6 Security Considerations . . . . . . . . . . . . . . . 65
         8.5.  IPv6 Network Management  . . . . . . . . . . . . . . . . . 67
       9.  Broadband Power Line Communications (PLC)  . . . . . . . . . . 67
         9.1.  PLC/BPL Access Network Elements  . . . . . . . . . . . . . 68
         9.2.  Deploying IPv6 in IPv4 PLC/BPL . . . . . . . . . . . . . . 69
           9.2.1.  IPv6 Related Infrastructure Changes  . . . . . . . . . 69
           9.2.2.  Addressing . . . . . . . . . . . . . . . . . . . . . . 69
           9.2.3.  Routing  . . . . . . . . . . . . . . . . . . . . . . . 70
         9.3.  IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 71
         9.4.  IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 71
         9.5.  IPv6 Security Considerations . . . . . . . . . . . . . . . 71
         9.6.  IPv6 Network Management  . . . . . . . . . . . . . . . . . 71
       10. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 71
       11. Security Considerations  . . . . . . . . . . . . . . . . . . . 74
       12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 74
       13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74
         13.1. Normative References . . . . . . . . . . . . . . . . . . . 74
         13.2. Informative References . . . . . . . . . . . . . . . . . . 76

    Asadullah, et al.            Informational                      [Page 3]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    1.  Introduction

       This document presents the options available in deploying IPv6
       services in the access portion of a BB Service Provider (SP) network
       - namely Cable/HFC, BB Ethernet, xDSL, WLAN, and PLC/BPL.

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

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

       The following important pieces are discussed:

       A. Available tunneling options

       B. Devices that would have to be upgraded to support IPv6

       C. Available IPv6 address assignment techniques and their use

       D. Possible IPv6 Routing options and their use

       E. IPv6 unicast and multicast packet transmission

       F. Required IPv6 Quality of Service (QoS) parameters

       G. Required IPv6 Security parameters

       H. Required IPv6 Network Management parameters

       It is important to note that the addressing rules provided throughout
       this document represent an example that follows the current
       assignment policies and recommendations of the registries.  However,
       they can be adapted to the network and business model needs of the
       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 necessary IPv6 functions
       discussed.  The costs involved with such an approach could be offset
       by lower impact on the existing IPv4 services.

    Asadullah, et al.            Informational                      [Page 4]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    2.  Common Terminology

       BB: Broadband

       CPE: Customer Premise Equipment

       GWR: Gateway Router

       ISP: Internet Service Provider

       NAP: Network Access Provider

       NSP: Network Service Provider

       QoS: Quality of Service

       SP: Service Provider

    3.  Core/Backbone Network

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

       There are two types of 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.

    3.1.  Layer 2 Access Provider Network

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

    Asadullah, et al.            Informational                      [Page 5]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       This type of network may be transparent to the Layer 3 protocol.
       Some possible changes may come with the intent of supporting IPv6
       provisioning mechanisms, as well as filtering and monitoring IPv6
       traffic based on Layer 2 information such as IPv6 Ether Type Protocol
       ID (0x86DD) or IPv6 multicast specific Media Access Control (MAC)
       addresses (33:33:xx:xx:xx:xx).

    3.2.  Layer 3 Access Provider Network

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

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

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

       A.  IPv6 Tunneling: As a temporary solution, the Access Provider can
           choose to use a tunneling mechanism to forward the subscriber
           IPv6 traffic to the Service Provider Edge Router.  This approach
           has the least impact on the Access Provider network; however, as
           the number of users increase and the amount of IPv6 traffic
           grows, the ISP will have to evolve to one of the scenarios listed
           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 Interior Gateway Protocol (IGP), such as OSPFv3
           [RFC2740] or IS-IS [ISISv6], is enabled.  RFC 4029 [RFC4029]
           discusses the IGP selection options with their benefits and
           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
           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

    Asadullah, et al.            Informational                      [Page 6]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       configured while the MPLS core continues to switch the traffic,
       unaware that it transports both IPv4 and IPv6. 6PE should be
       leveraged only if MPLS is already deployed in the network.  At the
       time of writing this document, a major disadvantage of the 6PE
       solution is that it does not support multicast IPv6 traffic.

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

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

    4.  Tunneling Overview

       If SPs are not able to deploy native IPv6, they might use tunneling-
       based transition mechanisms to start an IPv6 service offering, and
       move to native IPv6 deployment at a later time.

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

    4.1.  Access over Tunnels - Customers with Public IPv4 Addresses

       If the customer is a residential user, it can initiate the tunnel
       directly from the IPv6 capable host to a tunnel termination router
       located in the NAP or ISP network.  The tunnel type used should be
       decided by the SP, but it should take into consideration its
       availability on commonly used software running on the host machine.
       Of the many tunneling mechanisms developed, such as IPv6 Tunnel
       Broker [RFC3053], Connection of IPv6 Domains via IPv4 Clouds
       [RFC3056], Generic Packet Tunneling in IPv6 [RFC2473], ISATAP
       [RFC4214], Basic Transition Mechanisms for IPv6 Hosts and Routers
       [RFC4213], and Transmission of IPv6 over IPv4 Domains without
       Explicit Tunnels [RFC2529], some are more popular than the others.
       At the time of writing this document, the IETF Softwire Working Group
       was tasked with standardizing a single tunneling protocol [Softwire]
       for this application.

    Asadullah, et al.            Informational                      [Page 7]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

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

    4.2.  Access over Tunnels - Customers with Private IPv4 Addresses

       If the end customer receives a private IPv4 address and needs to
       initiate a tunnel through Network Address Translation (NAT),
       techniques like 6to4 may not work since they rely on public IPv4
       address.  In this case, unless the existing GWRs support protocol-41-
       forwarding [Protocol41], the end user might have to use tunnels that
       can operate through NATs (such as Teredo [RFC4380]).  Most GWRs
       support protocol-41-forwarding, which means that hosts can initiate
       the tunnels - in which case the GWR is not affected by the IPv6
       service.

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

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

    4.3.  Transition a Portion of the IPv4 Infrastructure

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

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

    Asadullah, et al.            Informational                      [Page 8]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       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
       have been discussed extensively in the documents referenced earlier
       as well as in [RFC4213] and [RFC3904].  Details of a tunnel-based
       deployment are offered in the next section of this document, which
       discusses the case of Cable Access, where the current Data Over Cable
       Service Interface Specification (DOCSIS 2.0) [RF-Interface] and prior
       specifications do not provide support for native IPv6 access.
       Although Sections 6, 7, 8, and 9 focus on a native IPv6 deployments
       over DSL, Fiber to the Home (FTTH), wireless, and PLC/BPL and because
       this approach is fully supported today, tunnel-based solutions are
       also possible in these cases based on the guidelines of this section
       and some of the recommendations provided in Section 5.

    5.  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.  DOCSIS 2.0 and prior specifications have 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 existing cable networks are tunnel based.  The tunneling examples
       presented here could also be applied to the other BB technologies
       described in Sections 6, 7, 8, and 9.

    5.1.  Broadband Cable Network Elements

       Broadband cable networks are capable of transporting IP traffic to/
       from users to provide high speed Internet access and Voice over IP
       (VoIP) services.  The mechanism for 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)

    Asadullah, et al.            Informational                      [Page 9]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       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): Standards
       defining how data should be carried over cable networks

       Figure 5.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 5.1

    5.2.  Deploying IPv6 in Cable Networks

       One of the motivators for an MSO to deploy IPv6 over its cable
       network is to ease management burdens.  IPv6 can be enabled on the
       CM, CMTS, and ER for management purposes.  Currently portions of the
       cable infrastructure use IPv4 address space [RFC1918]; however, there
       is a finite number of those.  Thus, IPv6 could have utility in the
       cable space implemented on the management plane initially and focused

    Asadullah, et al.            Informational                     [Page 10]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       on the data plane for end-user services later.  For more details on
       using IPv6 for management in cable networks, please refer to Section
       5.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
       routed and bridged cable networks include:

       A.  Changes need to be made to the DOCSIS specification
           [RF-Interface] to include support for IPv6 on the CM and CMTS.
           This is imperative for deploying native IPv6 over cable networks.

       B.  Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS.  In
           IPv4, these devices rely on Internet Group Multicast Protocol
           (IGMP) join messages to track membership of hosts that are part
           of a particular IP multicast group.  In order to support ND, a
           multicast-based process, the CM and CMTS will need to support
           IGMPv3/Multicast Listener Discovery Version 2 (MLDv2) or v1
           snooping.

       C.  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.  Service providers that wish to deploy QoS mechanisms
           also have to support classification of IPv6 traffic.

       Due to the above mentioned limitations in deployed cable networks, at
       the time of writing this document, the only option available for
       cable operators is to use tunneling techniques in order to transport
       IPv6 traffic over their current IPv4 infrastructure.  The following

    Asadullah, et al.            Informational                     [Page 11]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       sections will cover tunneling and native IPv6 deployment scenarios in
       more detail.

    5.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 act as 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.

       IPv6 can be deployed in a bridged CMTS network either natively or via
       tunneling.  This section discusses the native deployment model.  The
       tunneling model is similar to ones described in Sections 5.2.2.1 and
       5.2.2.2.

       Figure 5.2.1 illustrates the IPv6 deployment scenario.

       +-----+  +-----+
       |Host |--| GWR |
       +-----+  +--+--+
                   |              _ _ _ _ _ _
                   |  +------+   |           |
                   +--|  CM  |---|           |
                      +------+   |           |
                                 |   HFC     |   +------+  +--------+
                                 |           |   |      |  | Edge   |
             +-----+  +------+   |  Network  |---| CMTS |--|        |=>ISP
             |Host |--|  CM  |---|           |   |      |  | Router |Network
             +-----+  +------+   |           |   +------+  +--------+
                                 |_ _ _ _ _ _|
       |-------------||---------------------------------||---------------|
           L3 Routed              L2 Bridged                 L3 Routed

                                 Figure 5.2.1

    Asadullah, et al.            Informational                     [Page 12]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    5.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.

    5.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.

    5.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 Dynamic
       Host Configuration Protocol (DHCPv4), and download a DOCSIS
       configuration file identified by the DHCPv4 server.

    5.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 via stateless auto-configuration or DHCPv6.

       If using stateless auto-configuration, the host listens for routing
       advertisements (RAs) 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 (64-bit Extended Unique
       Identifier) 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.

    5.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 [RFC3177],
       which in turn is divided into /64s and assigned to its downstream
       interfaces connecting to the hosts.

    Asadullah, et al.            Informational                     [Page 13]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    5.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 forward Neighbor Discovery (ND) packets
       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.

       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 (Source-Specific 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.

    5.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.

    5.2.2.  Deploying IPv6 in a Routed CMTS Network

       In an IPv4/IPv6 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, the CMTS/ER will need to either tunnel IPv6
       traffic or natively support IPv6.

    Asadullah, et al.            Informational                     [Page 14]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       There are 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 act 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 hardware and software upgrades to support IPv6.

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

       In this scenario there is a stand-alone 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
       hardware and software 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 existing 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.

    Asadullah, et al.            Informational                     [Page 15]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    5.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 5.2.2.1 illustrates this deployment scenario.

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

         |---------||---------------------------------------||------------|
         IPv4/v6                 IPv4 only                    IPv4/v6

                                  Figure 5.2.2.1

    5.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.

    5.2.2.1.2.  Addressing

       The only device that needs to be assigned an IPv6 address at the
       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.

       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.

    Asadullah, et al.            Informational                     [Page 16]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    5.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 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.

    5.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.

    5.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 between the host and the ER, the cable
       network, including the CM and CMTS, does not need to support IPv6,
       and can remain as IPv4 devices.

       Figure 5.2.2.2 illustrates this deployment scenario.

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

       |---------||--------------------------------------||-------------|
         IPv4/v6                 IPv4 only                    IPv4/v6

                                  Figure 5.2.2.2

    Asadullah, et al.            Informational                     [Page 17]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    5.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.

    5.2.2.2.2.  Addressing

       The only devices that need 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 [RFC3177] prefix from the ER.  This
       /48 prefix will be used to configure /64s on hosts connected to the
       GWR downstream interfaces.  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.

    5.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 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.

    5.2.2.2.4.  Routing

       Depending on the tunneling technique used, additional configuration
       might be 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.

    Asadullah, et al.            Informational                     [Page 18]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       If using manual tunneling, the GWR and ER can use static routing or
       an IGP such as RIPng [RFC2080].  The RIPng updates can be transported
       over a manual tunnel, which does not work when using 6to4 tunneling
       since it does not support multicast.

       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 ER for each delegated /48 prefix.  The
       static routes need to be redistributed into the IGP at the ER, so
       there is no need for a routing protocol between the ER and the GWR.

       The ER runs an IGP such as OSPFv3 or ISIS.

    5.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 5.2.2.3 illustrates this deployment scenario.

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

         |-------||---------------------------||---------------|
          IPv4/v6              IPv4/v6              IPv4/v6

                                 Figure 5.2.2.3

    5.2.2.3.1.  IPv6 Related Infrastructure Changes

       Since the CM still acts as a Layer 2 bridge, it does not need to be
       dual stack.  The CM will need to support bridging of IPv6 unicast and
       multicast traffic and IGMPv3/MLDv2 or 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.

    Asadullah, et al.            Informational                     [Page 19]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    5.2.2.3.2.  Addressing

       In cable networks today, 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 auto-configuration.  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
       auto-configuration.  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 auto-configuration, 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.

    5.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.

    5.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
       IS-IS.

    Asadullah, et al.            Informational                     [Page 20]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    5.2.2.4.  Dual-Stacked Cable (HFC) Network, Stand-Alone 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 act 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 5.2.2.2.
       The only difference in this case is that the ER functionality exists
       on the CMTS instead of on a separate router in the cable operator
       network.

       Figure 5.2.2.4 illustrates this deployment scenario.

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

                                   Figure 5.2.2.4

    5.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.

    5.2.2.4.2.  Addressing

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

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

    Asadullah, et al.            Informational                     [Page 21]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    5.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
       5.2.2.2.3.

    5.2.2.4.4.  Routing

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

    5.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, 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/Embedded GWR acts as a Layer 3 device.

       Figure 5.2.2.5 illustrates this deployment scenario.

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

        |---------------------------------------------------------|
                                  IPv4/v6

                              Figure 5.2.2.5

    5.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.

    5.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.

    Asadullah, et al.            Informational                     [Page 22]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       If using DHCPv6, the CMTS will need to act as a 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 the 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 may have multiple /64
       prefixes configured under its cable interfaces.

       It is also possible to use DHCP-PD for an 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 an RA message.  Once the CM/GWR assigns an
       IPv6 address to its upstream interface, it will request a /48
       [RFC3177] prefix from the CMTS/ER and chop this /48 prefix into /64s
       for assigning IPv6 addresses to hosts.  The uplink to the ISP network
       is configured with a /64 prefix as well.

    5.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.

    5.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 RIPng 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
       IS-IS.

    5.2.3.  IPv6 Multicast

       In order to support IPv6 multicast applications across DOCSIS cable
       networks, the CM and bridging CMTS will need to support IGMPv3/MLDv2
       or v1 snooping.  MLD is almost identical to IGMP in IPv4, only the

    Asadullah, et al.            Informational                     [Page 23]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       name and numbers are changed.  MLDv2 is almost identical to IGMPv3
       and also supports ASM (Any-Source Multicast) and SSM (Source-Specific
       Multicast) service models.

       SSM is more suited for deployments where the SP intends to provide
       paid content to the users (video or audio).  These types of services
       are expected to be of primary interest.  Moreover, the simplicity of
       the SSM model often overrides the scalability issues that would be
       resolved in an ASM model.  ASM is, however, an option that is
       discussed in Section 6.3.1.  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.

       Refer to Section 6.3 for more IPv6 multicast details.

    5.2.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.

       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, and 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.

    5.2.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,

    Asadullah, et al.            Informational                     [Page 24]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       appropriate enhancements will be needed in the DOCSIS specification
       to support encrypted IPv6 multicast.

       There are limited changes that have to be done for hosts in order to
       enhance security.  The privacy extensions [RFC3041] for auto-
       configuration 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 from 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 Access Control Lists
       (ACLs) should be used on all interfaces facing subscribers.
       Filtering should be implemented with regard for the operational
       requirements of IPv6 [IPv6-Security].

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

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

    5.2.6.  IPv6 Network Management

       IPv6 can have many applications in cable networks.  MSOs can
       initially implement IPv6 on the control plane and use it to manage
       the thousands of devices connected to the CMTS.  This would be a good
       way to introduce IPv6 in a cable network.  Later, the MSO can extend
       IPv6 to the data plane and use it to carry customer traffic as well
       as management traffic.

    5.2.6.1.  Using IPv6 for Management in Cable Networks

       IPv6 can be enabled in a cable network for management of devices like
       CM, CMTS, and ER.  With the rollout of advanced services like VoIP
       and Video-over-IP, MSOs are looking for ways to manage the large
       number of devices connected to the CMTS.  In IPv4, an RFC1918 address
       is assigned to these devices for management purposes.  Since there is
       a finite number of RFC1918 addresses available, it is becoming
       difficult for MSOs to manage these devices.

    Asadullah, et al.            Informational                     [Page 25]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       By using IPv6 for management purposes, MSOs can scale their network
       management systems to meet their needs.  The CMTS/ER can be
       configured with a /64 management prefix that is shared among all CMs
       connected to the CMTS cable interface.  Addressing for the CMs can be
       done via stateless auto-configuration or DHCPv6.  Once the CMs
       receive a /64 prefix, they can configure themselves with an IPv6
       address.

       If there are devices behind the CM that need to be managed by the
       MSO, another /64 prefix can be defined on the CMTS/ER.  These devices
       can also use stateless auto-configuration 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 devices on the
       cable network.  The CM will no longer require an IPv4 address for
       management as described in DOCSIS 3.0 [DOCSIS3.0-Reqs].

    5.2.6.2.  Updates to MIB Modules/Standards to Support IPv6

       The current DOCSIS, PacketCable, and CableHome MIB modules are
       already designed to support IPv6 objects.  In this case, IPv6 will
       neither add nor change any of the functionality of these MIB modules.
       The Textual Convention used to represent Structure of Management
       Information Version 2 (SMIv2) objects representing IP addresses was
       updated [RFC4001] and a new Textual Convention InetAddressType was
       added to identify the type of the IP address used for IP address
       objects in MIB modules.

       There are some exceptions; the MIB modules that might need to add
       IPv6 support are defined in the DOCSIS 3.0 OSSI specification
       [DOCSIS3.0-OSSI].

    6.  Broadband DSL Networks

       This section describes the IPv6 deployment options in today's high-
       speed DSL networks.

    6.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 Premise Equipment and the DSL Access Multiplexer (DSLAM).

    Asadullah, et al.            Informational                     [Page 26]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       The following network elements are typical of a DSL network:

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

       Customer Premise Router (CPR): It is used to provide Layer 3 services
       for customer premise 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 Permanent Virtual Circuits (PVCs) corresponding to the
       subscriber DSL circuits.

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

       Figure 6.1 depicts all the network elements mentioned.

       Customer Premise | Network Access Provider | Network Service Provider
              CP                     NAP                        NSP
       +-----+  +------+                +------+   +--------+
       |Hosts|--|Router|             +--+ BRAS +---+ Edge   |      ISP
       +-----+  +--+---+             |  |      |   | Router +==> Network
                   |                 |  +------+   +--------+
                +--+---+             |
                | DSL  +-+           |
                |Modem | |           |
                +------+ |  +-----+  |
                         +--+     |  |
                +------+    |DSLAM+--+
       +-----+  | DSL  | +--+     |
       |Hosts|--+Modem +-+  +-----+
       +-----+  +--+---+

                                       Figure 6.1

    Asadullah, et al.            Informational                     [Page 27]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    6.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 2 circuits has
           to be maintained over a significant portion of the network.  The
           Layer 2 domains can be terminated at the ER in three ways:

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

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

           C.  By terminating the PVC at Layer 3, each PVC has its own
               prefix.  This is the approach that seems more suitable for
               IPv6 and is presented in Section 6.2.1.

               None of these ways requires that the CPE (DSL modem) 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
           6.2.2.

       3.  Layer 2 Tunneling Protocol (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 [RFC2661] tunnels.  This model
           is presented in Section 6.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 existing revenue generating IPv4 services, the
       IPv6 deployment will match the IPv4 one.  This approach is presented

    Asadullah, et al.            Informational                     [Page 28]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       in Sections 6.2.1 - 6.2.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
       6.2.4.

    6.2.1.  Point-to-Point Model

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

       Figure 6.2.1 describes the protocol architecture of this model.

            Customer Premise               NAP                 NSP
       |-------------------------|  |---------------| |------------------|
       +-----+  +-------+  +-----+  +--------+        +----------+
       |Hosts|--+Router +--+ DSL +--+ DSLAM  +--------+   Edge   |     ISP
       +-----+  +-------+  |Modem|  +--------+        |  Router  +=>Network
                           +-----+                    +----------+
                               |----------------------------|
                                          ATM

                                      Figure 6.2.1

    6.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.

    6.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
       auto-configuration or stateful DHCPv6-based configuration to acquire
       an address via the Edge Router.

       However, as manual configuration for each customer is a provisioning
       challenge, implementers are encouraged to develop mechanism(s) that
       automatically map the PVC (or some other customer-specific
       information) to an IPv6 subnet prefix, and advertise the customer-
       specific prefix to all the customers with minimal configuration.

    Asadullah, et al.            Informational                     [Page 29]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       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 auto-
           configuration, 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 PVC.
       Each PVC should be enabled to relay DHCPv6 requests from the
       subscribers to DHCPv6 servers in the ISP network.  The PVCs providing
       access for subscribers that use DHCP-PD as well, have to be enabled
       to support the feature.  The uplink to the ISP network is configured
       with a /64 prefix as well.

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

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

    6.2.1.3.  Routing

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

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

    6.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

    Asadullah, et al.            Informational                     [Page 30]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       authorizes the session, authenticates the subscriber, and provides an
       IP address on behalf of the ISP.  The BRAS then does Layer 3 routing
       of the subscriber traffic to the NSP Edge Router.

       When the NSP is also the NAP, the BRAS and NSP Edge Router could be
       the same piece of equipment and provide the above mentioned
       functionality.

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

       A. Connection using PPPoA

         Customer Premise               NAP                   NSP
       |--------------------| |----------------------| |----------------|
                                                       +-----------+
                                                       |    AAA    |
                                               +-------+   Radius  |
                                               |       |   TACACS  |
                                               |       +-----------+
       +-----+  +-------+      +--------+ +----+-----+ +-----------+
       |Hosts|--+Router +------+ DSLAM  +-+   BRAS   +-+    Edge   |
       +-----+  +-------+      +--------+ +----------+ |   Router  +=>Core
                    |--------------------------|       +-----------+
                                 PPP

                                  Figure 6.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; this information is
       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.

    Asadullah, et al.            Informational                     [Page 31]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       B. Connection using PPPoE

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

                                    Figure 6.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.

    6.2.2.1.  IPv6 Related Infrastructure Changes

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

    6.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 an Authentication, Authorization, and
       Accounting (AAA) server.  The Hosts or the Customer Routers have the
       BRAS as their Layer 3 next hop.

    Asadullah, et al.            Informational                     [Page 32]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       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 /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 subscribers and the ones delegated via DHCP-PD
       should be planned in a manner that allows maximum summarization at
       the BRAS.

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

    6.2.2.3.  Routing

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

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

       The Edge Router is running the IGP used in the ISP network: OSPFv3 or
       IS-IS.

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

    6.2.3.  L2TPv2 Access Aggregation (LAA) Model

       In the LAA model, the BRAS forwards the CPE initiated session to the
       ISP over an L2TPv2 tunnel established between the BRAS and the Edge
       Router.  In this case, the authentication, authorization, and
       subscriber configuration are performed by the ISP itself.  There are
       two types of PPP encapsulations that can be leveraged with this
       model:

    Asadullah, et al.            Informational                     [Page 33]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       A. Connection via PPPoA

         Customer Premise              NAP                    NSP
       |--------------------| |----------------------| |----------------|
                                                       +-----------+
                                                       |    AAA    |
                                               +-------+   Radius  |
                                               |       |   TACACS  |
                                               |       +-----+-----+
                                               |             |
       +-----+  +-------+      +--------+ +----+-----+ +-----+-----+
       |Hosts|--+Router +------+ DSLAM  +-+  BRAS    +-+   Edge    |
       +-----+  +-------+      +--------+ +----------+ |  Router   +=>Core
                                                       +-----------+
                    |----------------------------------------|
                                       PPP
                                                |------------|
                                                     L2TPv2

                               Figure 6.2.3.1

       B. Connection via PPPoE

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

                                 Figure 6.2.3.2

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

    Asadullah, et al.            Informational                     [Page 34]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    6.2.3.1.  IPv6 Related Infrastructure Changes

       In this scenario, the BRAS is forwarding the PPP sessions initiated
       by the subscriber over the L2TPv2 tunnel established to the L2TP
       Network Server (LNS), the aggregation point in the ISP network.  The
       L2TPv2 tunnel between the L2TP Access Concentrator (LAC) and LNS can
       run over IPv6 or IPv4.  These capabilities have to be supported on
       the BRAS.  The following devices have to be upgraded to dual stack:
       Host, Customer Router, and Edge Router.  If the tunnel is set up over
       IPv6, then the BRAS must be upgraded to dual stack.

    6.2.3.2.  Addressing

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

       The PPP session can be initiated by a host or by a Customer Router.
       In the latter case, once the session is established with the Edge
       Router, DHCP-PD can be used to acquire prefixes for the Customer
       Router interfaces.  The Edge Router has to be enabled to support
       DHCP-PD and to relay the DHCPv6 requests generated by the hosts on
       the subscriber sites.

       The BRAS has a /64 prefix configured on the link to the Edge Router.
       The Edge Router links are also configured with /64 prefixes to
       provide connectivity to the rest of the ISP network.  Other
       information of interest to the host, such as DNS, is provided through
       stateful [RFC3315] and stateless [RFC3736] DHCPv6.

       It is important to note here a significant difference between this
       deployment for IPv6 versus IPv4.  In the case of IPv4, the customer
       router or CPE can end up on any Edge Router (acting as LNS), where
       the assumption is that there are at least two of them for redundancy
       purposes.  Once authenticated, the customer will be given an address
       from the IP pool of the ER (LNS) it connected to.  This allows the
       ERs (LNSs) to aggregate the addresses handed out to the customers.
       In the case of IPv6, an important constraint that likely will be
       enforced is that the customer should keep its own address, regardless
       of the ER (LNS) it connects to.  This could significantly reduce the
       prefix aggregation capabilities of the ER (LNS).  This is different
       than the current IPv4 deployment where addressing is dynamic in
       nature, and the same user can get different addresses depending on
       the LNS it ends up connecting to.

    Asadullah, et al.            Informational                     [Page 35]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       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 for which they are the primary ER (LNS), as well as
       for the ones for which they are the secondary.  This way the prefixes
       will be summarized any time they become "active" on the ER (LNS).

    6.2.3.3.  Routing

       The CPE devices are configured with a default route that points to
       the Edge Router that terminates the PPP sessions.  No routing
       protocols are needed on these devices, which generally have limited
       resources.

       The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS.
       Different processes should be used if the NAP and the NSP are managed
       by different organizations.  In this case, controlled redistribution
       should be enabled between the two domains.

       The Edge Router is running the IPv6 IGP used in the ISP network:
       OSPFv3 or IS-IS.

    6.2.4.  Hybrid Model for IPv4 and IPv6 Service

       It was recommended throughout this section that the IPv6 service
       implementation should map the existing IPv4 one.  This approach
       simplifies manageability and minimizes training needed for personnel
       operating the network.  In certain circumstances such mapping is not
       feasible.  This typically becomes the case when a Service Provider
       plans to expand its service offering with the new IPv6 deployed
       infrastructure.  If this new service is not well supported in a
       network design such as the one used for IPv4, then a different design
       might be used for IPv6.

       An example of such circumstances is that of a provider using an LAA
       design for its IPv4 services.  In this case all the PPP sessions are
       bundled and tunneled across the entire NAP infrastructure which is
       made of multiple BRAS routers, aggregation routers etc.  The end
       point of these tunnels is the ISP Edge Router.  If the provider
       decides to offer multicast services over such a design, it will face
       the problem of NAP resources being over utilized.  The multicast
       traffic can be replicated only at the end of the tunnels by the Edge
       Router and the copies for all the subscribers are carried over the
       entire NAP.

    Asadullah, et al.            Informational                     [Page 36]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       A Modified Point-to-Point (as described in Section 6.2.4.2) or PTA
       model is more suitable to support multicast services because the
       packet replication can be done closer to the destination at the BRAS.
       Such topology saves NAP resources.

       In this sense, IPv6 deployment can be viewed as an opportunity to
       build an infrastructure that might better support the expansion of
       services.  In this case, an SP using the LAA design for its IPv4
       services might choose a modified Point-to-Point or PTA design for
       IPv6.

    6.2.4.1.  IPv4 in LAA Model and IPv6 in PTA Model

       The coexistence of the two PPP-based models, PTA and LAA, is
       relatively straightforward.  The PPP sessions are terminated on
       different network devices for the IPv4 and IPv6 services.  The PPP
       sessions for the existing IPv4 service deployed in an LAA model are
       terminated on the Edge Router.  The PPP sessions for the new IPv6
       service deployed in a PTA model are terminated on the BRAS.

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

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

                                 Figure 6.2.4.1

    6.2.4.2.  IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model

       In this particular scenario the Point-to-Point model used for the
       IPv6 service is a modified version of the model described in section
       6.2.1.

    Asadullah, et al.            Informational                     [Page 37]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       For the IPv4 service in the LAA model, the PVCs are terminated on the
       BRAS and PPP sessions are terminated on the Edge Router (LNS).  For
       IPv6 service in the Point-to-Point model, the PVCs are terminated at
       the Edge Router as described in Section 6.2.1.  In this hybrid model,
       the Point-to-Point link could be terminated on the BRAS, a NAP-owned
       device.  The IPv6 traffic is then routed through the NAP network to
       the NSP.  In order to have this hybrid model, the BRAS has to be
       upgraded to a dual-stack router.  The functionalities of the Edge
       Router, as described in Section 6.2.1, are now implemented on the
       BRAS.

       The other aspect of this deployment model is the fact that the BRAS
       has to be capable of distinguishing between the IPv4 PPP traffic that
       has to be bridged across the L2TPv2 tunnel and the IPv6 packets that
       have to be routed to the NSP.  The IPv6 Routing and Bridging
       Encapsulation (RBE) has to be enabled on all interfaces with PVCs
       supporting both IPv4 and IPv6 services in this hybrid design.

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

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

                                 Figure 6.2.4.2

    6.3.  IPv6 Multicast

       The deployment of IPv6 multicast services relies on MLD, identical to
       IGMP in IPv4 and on PIM for routing.  ASM (Any Source Multicast) and
       SSM (Single Source Multicast) service models operate almost the same
       as in IPv4.  Both have the same benefits and disadvantages as in
       IPv4.  Nevertheless, the larger address space and the scoped address
       architecture provide major benefits for multicast IPv6.  Through RFC
       3306, the large address space provides the means to assign global

    Asadullah, et al.            Informational                     [Page 38]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       multicast group addresses to organizations or users that were
       assigned unicast prefixes.  It is a significant improvement with
       respect to the IPv4 GLOP mechanism [RFC3180].

       This facilitates the deployment of multicast services.  The
       discussion of this section applies to all the multicast sections in
       the document.

    6.3.1.  ASM-Based Deployments

       Any Source Multicast (ASM) is useful for Service Providers that
       intend to support the forwarding of multicast traffic of their
       customers.  It is based on the Protocol Independent Multicast -
       Sparse Mode (PIM-SM) protocol and it is more complex to manage
       because of the use of Rendezvous Points (RPs).  With IPv6, static RP
       and Bootstrap Router [BSR] can be used for RP-to-group mapping
       similar to IPv4.  Additionally, the larger IPv6 address space allows
       for building up of group addresses that incorporate the address of
       the RP.  This RP-to-group mapping mechanism is called Embedded RP and
       is specific to IPv6.

       In inter-domain deployments, Multicast Source Discovery Protocol
       (MSDP) [RFC3618] is an important element of IPv4 PIM-SM deployments.
       MSDP is meant to be a solution for the exchange of source
       registration information between RPs in different domains.  This
       solution was intended to be temporary.  This is one of the reasons
       why it was decided not to implement MSDP in IPv6 [IPv6-Multicast].

       For multicast reachability across domains, Embedded RP can be used.
       As Embedded RP provides roughly the same capabilities as MSDP, but in
       a slightly different way, the best management practices for ASM
       multicast with embedded RP still remain to be developed.

    6.3.2.  SSM-Based Deployments

       Based on PIM-SSM, the Source-Specific Multicast deployments do not
       need an RP or related protocols (such as BSR or MSDP), but rely on
       the listeners to know the source of the multicast traffic they plan
       to receive.  The lack of RP makes SSM not only simpler to operate,
       but also robust; it is not impacted by RP failures or inter-domain
       constraints.  It also has a higher level of security (no RP to be
       targeted by attacks).  For more discussions on the topic of IPv6
       multicast, see [IPv6-Multicast].

       The typical multicast service offered for residential and very small
       businesses is video/audio streaming, where the subscriber joins a
       multicast group and receives the content.  This type of service model
       is well supported through PIM-SSM which is very simple and easy to

    Asadullah, et al.            Informational                     [Page 39]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       manage.  PIM-SSM has to be enabled throughout the SP network.  MLDv2
       is required for PIM-SSM support.  Vendors can choose to implement
       features that allow routers to map MLDv1 group joins to predefined
       sources.

       Subscribers might use a set-top box that is responsible for the
       control piece of the multicast service (does group joins/leaves).
       The subscriber hosts can also join desired multicast groups as long
       as they are enabled to support MLDv1 or MLDv2.  If a customer premise
       router is used, then it has to be enabled to support MLDv1 and MLDv2
       in order to process the requests of the hosts.  It has to be enabled
       to support PIM-SSM in order to send PIM joins/leaves up to its Layer
       3 next hop whether it is the BRAS or the Edge Router.  When enabling
       this functionality on a CPR, its limited resources should be taken
       into consideration.  Another option would be for the CPR to support
       MLD proxy routing.

       The router that is the Layer 3 next hop for the subscriber (BRAS in
       the PTA model or the Edge Router in the LAA and Point-to-Point model)
       has to be enabled to support MLDv1 and MLDv2 in order to process the
       requests coming from subscribers without CPRs.  It has to be enabled
       for PIM-SSM in order to receive joins/leaves from customer routers
       and send joins/leaves to the next hop towards the multicast source
       (Edge Router or the NSP core).

       MLD authentication, authorization and accounting are usually
       configured on the Edge Router in order to enable the ISP to 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.

    6.4.  IPv6 QoS

       The QoS configuration is particularly relevant on the router that
       represents the Layer 3 next hop for the subscriber (BRAS in the PTA
       model or the Edge Router in the LAA and Point-to-Point model) in
       order to manage resources shared amongst multiple subscribers,
       possibly with various service level agreements.

       In the DSL infrastructure, it is expected that there is already a
       level of traffic policing and shaping implemented for IPv4
       connectivity.  This is implemented throughout the NAP and is beyond
       the scope of this document.

       On the BRAS or the Edge Router, the subscriber-facing interfaces have
       to be configured to police the inbound customer traffic and shape the
       traffic outbound to the customer based on the service level
       agreements (SLAs).  Traffic classification and marking should also be

    Asadullah, et al.            Informational                     [Page 40]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       done on the router closest (at Layer 3) to the subscriber in order to
       support the various types of customer traffic (data, voice, and
       video) and to optimally use the infrastructure resources.  Each
       provider (NAP, NSP) could implement their own QoS policies and
       services so that reclassification and marking might be performed at
       the boundary between the NAP and the NSP, in order to make sure the
       traffic is properly handled by the ISP.  The same IPv4 QoS concepts
       and methodologies should be applied with 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

       There are limited changes that have to be done for CPEs in order to
       enhance security.  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 to track their users at a /128 address
       level, the privacy extensions may be implemented in parallel with
       network management tools that could provide traceability of the
       hosts.  IPv6 firewall functions should be enabled on the hosts or
       CPR, if present.

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

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

       The BRAS and the Edge Router should protect their processing
       resources against floods of valid customer control traffic such as:
       Router and Neighbor Solicitations, and MLD Requests.  Rate limiting
       should be implemented on all subscriber-facing interfaces.  The
       emphasis should be placed on multicast-type traffic, as it is most
       often used by the IPv6 control plane.

    Asadullah, et al.            Informational                     [Page 41]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

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

    6.6.  IPv6 Network Management

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

       Usually, NSPs manage the edge routers by SNMP.  The SNMP transport
       can be done over IPv4 if all managed devices have connectivity over
       both IPv4 and IPv6.  This would imply the smallest changes to the
       existing network management practices and processes.  Transport over
       IPv6 could also be implemented, and it might become necessary if IPv6
       only islands are present in the network.  The management applications
       may be running on hosts belonging to the NSP core network domain.
       Network Management Applications should handle IPv6 in a similar
       fashion to IPv4; however, they should also support features specific
       to IPv6 (such as neighbor monitoring).

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

    7.  Broadband Ethernet Networks

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

    7.1.  Ethernet Access Network Elements

       In environments that support the infrastructure deploying RJ-45 or
       fiber (Fiber to the Home (FTTH) service) to subscribers, 10/100 Mbps
       Ethernet broadband services can be provided.  Such services are
       generally available in metropolitan areas in multi-tenant buildings
       where an Ethernet infrastructure can be deployed in a cost-effective
       manner.  In such environments, Metro-Ethernet services can be used to
       provide aggregation and uplink to a Service Provider.

       The following network elements are typical of an Ethernet network:

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

       Customer Premise Router: It is used to provide Layer 3 services for
       customer premise networks.

       Aggregation Ethernet Switches: Aggregates multiple subscribers.

       Broadband Remote Access Server (BRAS)

    Asadullah, et al.            Informational                     [Page 42]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       Edge Router (ER)

       Figure 7.1 depicts all the network elements mentioned.

       Customer Premise | 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 7.1

       The logical topology and design of Broadband Ethernet Networks are
       very similar to DSL Broadband Networks discussed in Section 6.

       It is worth noting that the general operation, concepts and
       recommendations described in this section apply similarly to a
       HomePNA-based network environment.  In such an environment, some of
       the network elements might be differently named.

    7.2.  Deploying IPv6 in IPv4 Broadband Ethernet Networks

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

       A.  Point-to-Point Model: Each subscriber connects to the network
           Access switch over RJ-45 or fiber links.  Each subscriber is
           assigned a unique VLAN on the access switch.  The VLAN can be
           terminated at the BRAS or at the Edge Router.  The VLANs are
           802.1Q trunked to the Layer 3 device (BRAS or Edge Router).

           This model is presented in Section 7.2.1.

    Asadullah, et al.            Informational                     [Page 43]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       B.  PPP Terminated Aggregation (PTA) Model: PPP sessions are opened
           between each subscriber and the BRAS.  The BRAS terminates the
           PPP sessions and provides Layer 3 connectivity between the
           subscriber and the ISP.

           This model is presented in Section 7.2.2.

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

           This model is presented in Section 7.2.3.

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

       In order to maintain the deployment concepts and business models
       proven and used with existing revenue generating IPv4 services, the
       IPv6 deployment will match the IPv4 one.  This approach is presented
       in Sections 7.2.1 - 7.2.3 that describe currently deployed IPv4 over
       Ethernet broadband access deployments.  Under certain circumstances
       where new service types or service needs justify it, IPv4 and IPv6
       network architectures could be different as described in Section
       7.2.4.

    7.2.1.  Point-to-Point Model

       In this scenario, the Ethernet frames from the Host or the Customer
       Premise Router are bridged over the VLAN assigned to the subscriber.

       Figure 7.2.1 describes the protocol architecture of this model.

       |   Customer Premise     |  |       NAP       |        NSP         |

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

                              |----------------------------|
                                      Ethernet/VLANs

                                     Figure 7.2.1

    Asadullah, et al.            Informational                     [Page 44]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    7.2.1.1.  IPv6 Related Infrastructure Changes

       In this scenario, the Access Switch is on the customer site and the
       entire NAP is Layer 3 unaware, so no changes are needed to support
       IPv6.  The following devices have to be upgraded to dual stack: Host,
       Customer Router, and Edge Router.

       The Access switches might need upgrades to support certain IPv6-
       related features such as MLD Snooping.

    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 VLAN.  The hosts
       can use stateless auto-configuration or stateful DHCPv6-based
       configuration to acquire an address via the Edge Router.

       However, as manual configuration for each customer is a provisioning
       challenge, implementations are encouraged to develop mechanism(s)
       that automatically map the VLAN (or some other customer-specific
       information) to an IPv6 subnet prefix, and advertise the customer-
       specific prefix to all the customers with minimal configuration.

       If a Customer Router is present:

       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 auto-
           configuration, the address for the link between itself and the
           ER.  This step is followed by a request via DHCP-PD for a prefix
           shorter 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 to relay DHCPv6 requests from the
       subscribers to DHCPv6 servers in the ISP network.  The VLANs
       providing access for subscribers that use DHCP-PD have to be enabled
       to support the feature.  The uplink to the ISP network is configured
       with a /64 prefix as well.

    Asadullah, et al.            Informational                     [Page 45]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

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

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

    7.2.1.3.  Routing

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

       The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS.
       The connected prefixes have to be redistributed.  If DHCP-PD is used,
       with every delegated prefix a static route is installed by the 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 (PPPoE).  The PPP
       sessions are initiated by Customer Premise Equipment and are
       terminated at the BRAS.  The BRAS authorizes the session,
       authenticates the subscriber, and provides an IP address on behalf of
       the ISP.  The BRAS then does Layer 3 routing of the subscriber
       traffic to the NSP Edge Router.

       When the NSP is also the NAP, the BRAS and NSP Edge Router could be
       the same piece of equipment and provide the above mentioned
       functionality.

       The PPPoE logical diagram in an Ethernet Broadband Network is shown
       in Fig 7.2.2.1.

    Asadullah, et al.            Informational                     [Page 46]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       |     Customer Premise      | |       NAP       | |      NSP       |

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

                                   Figure 7.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 remote database.  Once the session is established, the BRAS
       provides an address and maybe a DNS server to the user; this
       information is acquired from the subscriber profile or a DHCP server.

       This model allows for multiple PPPoE sessions 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.

    7.2.2.1.  IPv6 Related Infrastructure Changes

       In this scenario, the BRAS is Layer 3 aware and 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.

    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 an 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,
       DHCP-PD can be used to acquire prefixes for the Customer Router
       interfaces.  The BRAS has to be enabled to support DHCP-PD and to
       relay the DHCPv6 requests of the hosts on the subscriber sites.

    Asadullah, et al.            Informational                     [Page 47]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

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

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

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

    7.2.2.3.  Routing

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

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

       The Edge Router is running the IGP used in the ISP network: OSPFv3 or
       IS-IS.  A separation between the routing domains of the ISP and the
       Access Provider is recommended if they are managed independently.
       Controlled redistribution will be needed between the Access Provider
       IGP and the ISP IGP.

    7.2.3.  L2TPv2 Access Aggregation (LAA) Model

       In the LAA model, the BRAS forwards the CPE initiated session to the
       ISP over an L2TPv2 tunnel established between the BRAS and the Edge
       Router.  In this case, the authentication, authorization, and
       subscriber configuration are performed by the ISP itself.

    Asadullah, et al.            Informational                     [Page 48]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       | Customer Premise   | |         NAP          | |       NSP       |

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

    7.2.3.1.  IPv6 Related Infrastructure Changes

       In this scenario, the BRAS is Layer 3 aware and has to be upgraded to
       support IPv6.  The PPP sessions initiated by the subscriber are
       forwarded over the L2TPv2 tunnel to the aggregation point in the ISP
       network.  The BRAS (LAC) can aggregate IPv6 PPP sessions and tunnel
       them to the LNS using L2TPv2.  The L2TPv2 tunnel between the LAC and
       LNS could run over IPv6 or IPv4.  These capabilities have to be
       supported on the BRAS.  The following devices have to be upgraded to
       dual stack: Host, Customer Router (if present), BRAS and Edge Router.

    7.2.3.2.  Addressing

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

       The PPP session can be initiated by a host or by a Customer Router.
       In the latter case, once the session is established with the Edge
       Router and an IPv6 address is assigned to the Customer Router by the
       Edge Router, DHCP-PD can be used to acquire prefixes for the Customer
       Router other interfaces.  The Edge Router has to be enabled to
       support DHCP-PD and to relay the DHCPv6 requests of the hosts on the
       subscriber sites.  The uplink to the ISP network is configured with a
       /64 prefix as well.

    Asadullah, et al.            Informational                     [Page 49]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

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

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

       The address assignment and prefix summarization issues discussed in
       Section 6.2.3.2 are relevant in the same way for this media access
       type as well.

    7.2.3.3.  Routing

       The CPE devices are configured with a default route that points to
       the Edge Router that terminates the PPP sessions.  No routing
       protocols are needed on these devices, which have limited resources.

       The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS.
       Different processes should be used if the NAP and the NSP are managed
       by different organizations.  In this case, controlled redistribution
       should be enabled between the two domains.

       The Edge Router is running the IPv6 IGP used in the ISP network:
       OSPFv3 or IS-IS.

    7.2.4.  Hybrid Model for IPv4 and IPv6 Service

       It was recommended throughout this section that the IPv6 service
       implementation should map the existing IPv4 one.  This approach
       simplifies manageability and minimizes training needed for personnel
       operating the network.  In certain circumstances, such mapping is not
       feasible.  This typically becomes the case when a Service Provider
       plans to expand its service offering with the new IPv6 deployed
       infrastructure.  If this new service is not well supported in a
       network design such as the one used for IPv4, then a different design
       might be used for IPv6.

       An example of such circumstances is that of a provider using an LAA
       design for its IPv4 services.  In this case, all the PPP sessions are
       bundled and tunneled across the entire NAP infrastructure, which is
       made of multiple BRAS routers, aggregation routers, etc.  The end
       point of these tunnels is the ISP Edge Router.  If the SP decides to
       offer multicast services over such a design, it will face the problem
       of NAP resources being over-utilized.  The multicast traffic can be
       replicated only at the end of the tunnels by the Edge Router, and the
       copies for all the subscribers are carried over the entire NAP.

    Asadullah, et al.            Informational                     [Page 50]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

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

       In this sense, IPv6 deployments can be viewed as an opportunity to
       build an infrastructure that can better support the expansion of
       services.  In this case, an SP using the LAA design for its IPv4
       services might choose a modified Point-to-Point or PTA design for
       IPv6.

    7.2.4.1.  IPv4 in LAA Model and IPv6 in PTA Model

       The coexistence of the two PPP-based models, PTA and LAA, is
       relatively straightforward.  It is a straightforward overlap of the
       two deployment models.  The PPP sessions are terminated on different
       network devices for the IPv4 and IPv6 services.  The PPP sessions for
       the existing IPv4 service deployed in an LAA model are terminated on
       the Edge Router.  The PPP sessions for the new IPv6 service deployed
       in a PTA model are terminated on the BRAS.

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

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

       IPv4          |----------------------------------------|
                                       PPP
                                                |------------|
                                                    L2TPv2

                                Figure 7.2.4.1

    Asadullah, et al.            Informational                     [Page 51]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

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

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

       For the IPv4 service in LAA model, the VLANs are terminated on the
       BRAS, and PPP sessions are terminated on the Edge Router (LNS).  For
       the IPv6 service in the Point-to-Point model, the VLANs are
       terminated at the Edge Router as described in Section 6.2.1.  In this
       hybrid model, the Point-to-Point link could be terminated on the
       BRAS, a NAP-owned device.  The IPv6 traffic is then routed through
       the NAP network to the NSP.  In order to have this hybrid model, the
       BRAS has to be upgraded to a dual-stack router.  The functionalities
       of the Edge Router, as described in Section 6.2.1, are now
       implemented on the BRAS.

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

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

                                     Figure 7.2.4.2

    7.3.  IPv6 Multicast

       The typical multicast services offered for residential and very small
       businesses are video/audio streaming where the subscriber joins a
       multicast group and receives the content.  This type of service model
       is well supported through PIM-SSM, which is very simple and easy to
       manage.  PIM-SSM has to be enabled throughout the ISP network.  MLDv2
       is required for PIM-SSM support.  Vendors can choose to implement
       features that allow routers to map MLDv1 group joins to predefined
       sources.

    Asadullah, et al.            Informational                     [Page 52]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       Subscribers might use a set-top box that is responsible for the
       control piece of the multicast service (does group joins/leaves).
       The subscriber hosts can also join desired multicast groups as long
       as they are enabled to support MLDv1 or MLDv2.  If a CPR is used,
       then it has to be enabled to support MLDv1 and MLDv2 in order to
       process the requests of the hosts.  It has to be enabled to support
       PIM-SSM in order to send PIM joins/leaves up to its Layer 3 next hop
       whether it is the BRAS or the Edge Router.  When enabling this
       functionality on a CPR, its limited resources should be taken into
       consideration.  Another option would be for the CPR to support MLD
       proxy routing.  MLD snooping or similar Layer 2 multicast-related
       protocols could be enabled on the NAP switches.

       The router that is the Layer 3 next hop for the subscriber (BRAS in
       the PTA model or the Edge Router in the LAA and Point-to-Point model)
       has to be enabled to support MLDv1 and MLDv2 in order to process the
       requests coming from subscribers without CPRs.  It has to be enabled
       for PIM-SSM in order to receive joins/leaves from customer routers
       and send joins/leaves to the next hop towards the multicast source
       (Edge Router or the NSP core).

       MLD authentication, authorization, and accounting are usually
       configured on the edge router in order to enable the ISP to control
       the subscriber access of the service and do billing for the content
       provided.  Alternative mechanisms that would support these functions
       should be investigated further.

       Please refer to section 6.3 for more IPv6 multicast details.

    7.4.  IPv6 QoS

       The QoS configuration is particularly relevant on the router that
       represents the Layer 3 next hop for the subscriber (BRAS in the PTA
       model or the Edge Router in the LAA and Point-to-Point model) in
       order to manage resources shared amongst multiple subscribers,
       possibly with various service level agreements.

       On the BRAS or the Edge Router, the subscriber-facing interfaces have
       to be configured to police the inbound customer traffic and shape the
       traffic outbound to the customer based on the SLAs.  Traffic
       classification and marking should also be done on the router closest
       (at Layer 3) to the subscriber in order to support the various types
       of customer traffic: data, voice, video, and to optimally use the
       network resources.  This infrastructure offers a very good
       opportunity to leverage the QoS capabilities of Layer 2 devices.
       Diffserv-based QoS used for IPv4 should be expanded to IPv6.

    Asadullah, et al.            Informational                     [Page 53]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       Each provider (NAP, NSP) could implement their own QoS policies and
       services so that reclassification and marking might be performed at
       the boundary between the NAP and the NSP, in order to make sure the
       traffic is properly handled by the ISP.  The same IPv4 QoS concepts
       and methodologies should be applied for the IPv6 as well.

       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.

    7.5.  IPv6 Security Considerations

       There are limited changes that have to be done for CPEs in order to
       enhance security.  The privacy extensions [RFC3041] for auto-
       configuration should be used by the hosts with the same
       considerations for host traceability as discussed in Section 6.5.
       IPv6 firewall functions should be enabled on the hosts or Customer
       Premise Router, if present.

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

       If any Layer 2 filters for Ethertypes are in place, the NAP must
       permit the IPv6 Ethertype (0X86DD).

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

       The BRAS and the Edge Router should protect their processing
       resources against floods of valid customer control traffic such as:
       Router and Neighbor Solicitations, and MLD Requests.  Rate limiting
       should be implemented on all subscriber-facing interfaces.  The
       emphasis should be placed on multicast-type traffic, as it is most
       often used by the IPv6 control plane.

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

    Asadullah, et al.            Informational                     [Page 54]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    7.6.  IPv6 Network Management

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

       Usually, NSPs manage the edge routers by SNMP.  The SNMP transport
       can be done over IPv4 if all managed devices have connectivity over
       both IPv4 and IPv6.  This would imply the smallest changes to the
       existing network management practices and processes.  Transport over
       IPv6 could also be implemented and it might become necessary if IPv6
       only islands are present in the network.  The management applications
       may be running on hosts belonging to the NSP core network domain.
       Network Management Applications should handle IPv6 in a similar
       fashion to IPv4; however, they should also support features specific
       to IPv6 such as neighbor monitoring.

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

    8.  Wireless LAN

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

    8.1.  WLAN Deployment Scenarios

       WLAN enables subscribers to connect to the Internet from various
       locations without the restriction of staying indoors.  WLAN is
       standardized by IEEE 802.11a/b/g.

       Figure 8.1 describes the current WLAN architecture.

           Customer |             Access Provider        | Service Provider
           Premise  |                                    |

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

                                     Figure 8.1

    Asadullah, et al.            Informational                     [Page 55]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       The host should have a wireless Network Interface Card (NIC) in order
       to connect to a WLAN network.  WLAN is a flat broadcast network and
       works in a similar fashion as Ethernet.  When a host initiates a
       connection, it is authenticated by the AAA server located at the SP
       network.  All the authentication parameters (username, password,
       etc.) are forwarded by the Access Point (AP) to the AAA server.  The
       AAA server authenticates the host; once successfully authenticated,
       the host can send data packets.  The AP is located near the host and
       acts as a bridge.  The AP forwards all the packets coming to/from
       host to the Edge Router.  The underlying connection between the AP
       and Edge Router could be based on any access layer technology such as
       HFC/Cable, FTTH, xDSL, etc.

       WLANs operate within limited areas known as WiFi Hot Spots.  While
       users are present in the area covered by the WLAN range, they can be
       connected to the Internet given they have a wireless NIC and required
       configuration settings in their devices (notebook PCs, PDAs, etc.).
       Once the user initiates the connection, the IP address is assigned by
       the SP using DHCPv4.  In most of the cases, SP assigns a limited
       number of public IP addresses to its customers.  When the user
       disconnects the connection and moves to a new WiFi hot spot, the
       above-mentioned process of authentication, address assignment, and
       accessing the Internet is repeated.

       There are IPv4 deployments where customers can use WLAN routers to
       connect over wireless to their service provider.  These deployment
       types do not fit in the typical Hot Spot concept, but rather they
       serve fixed customers.  For this reason, this section discusses the
       WLAN router options as well.  In this case, the ISP provides a public
       IP address and the WLAN Router assigns private addresses [RFC1918] to
       all WLAN users.  The WLAN Router provides NAT functionality while
       WLAN users access the Internet.

       While deploying IPv6 in the above-mentioned WLAN architecture, there
       are three possible scenarios as discussed below.

       A. Layer 2 NAP with Layer 3 termination at NSP Edge Router

       B. Layer 3 aware NAP with Layer 3 termination at Access Router

       C. PPP-Based Model

    8.1.1.  Layer 2 NAP with Layer 3 termination at NSP Edge Router

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

    Asadullah, et al.            Informational                     [Page 56]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       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, etc.) are forwarded by the AP to
       the AAA server.  The AAA server authenticates the WLAN Hosts, and
       once the WLAN Host is authenticated and associated successfully with
       the WLAN AP, it acquires an IPv6 address.  Note that the initiation
       and authentication process is the same as used in IPv4.

       Figure 8.1.1 describes the WLAN architecture when a Layer 2 Switch is
       located between AP and Edge Router.

           Customer |             Access Provider        | Service Provider
           Premise  |                                    |

         +------+         +--+ +--------------+ +----------+ +------+
         |WLAN  |  ----   |  | |              | | Provider | |Edge  |
         |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network  |-|Router|=>SP
         |Router|  ----   |  | |              | |          | |      |Network
         +------+         +--+ +--------------+ +----------+ +------+
                                                               |
                                                            +------+
                                                            |AAA   |
                                                            |Server|
                                                            +------+

                                     Figure 8.1.1

    8.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.

    8.1.1.2.  Addressing

       When a 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 an Edge Router using
           stateless auto-configuration [RFC2462].  All 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, etc.

       B.  The IPv6 WLAN Host can use DHCPv6 [RFC3315] to get an IPv6
           address from the DHCPv6 server.  In this case, the DHCPv6 server
           would be located in the SP core network, and the Edge Router
           would simply act as a DHCP Relay Agent.  This option is similar

    Asadullah, et al.            Informational                     [Page 57]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

           to what is done 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 Router is present, the WLAN Host has two
       possible options as well for acquiring IPv6 address.

       A.  The WLAN Router may be assigned a prefix between /48 and /64
           [RFC3177] depending on the SP policy and customer requirements.
           If the WLAN Router has multiple networks connected to its
           interfaces, the network administrator will have to configure the
           /64 prefixes to the WLAN Router interfaces connecting the WLAN
           Hosts on the customer site.  The WLAN Hosts connected to these
           interfaces can automatically configure themselves using stateless
           auto-configuration.

       B.  The WLAN Router can use its link-local address to communicate
           with the ER.  It can also dynamically acquire through stateless
           auto-configuration the address for the link between itself and
           the ER.  This step is followed by a request via DHCP-PD for a
           prefix shorter 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 Router would act as a requesting router and
       the Edge Router would act as a delegating router.  Once the prefix is
       received by the WLAN Router, it assigns /64 prefixes to each of its
       interfaces connecting the WLAN Hosts on the customer site.  The WLAN
       Hosts connected to these interfaces can automatically configure
       themselves using stateless auto-configuration.  The uplink to the ISP
       network is configured with a /64 prefix as well.

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

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

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

    Asadullah, et al.            Informational                     [Page 58]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    8.1.1.3.  Routing

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

       The Edge Router runs the IGP used in the SP network such as OSPFv3 or
       IS-IS for IPv6.  The connected prefixes have to be redistributed.
       Prefix summarization should be done at the Edge Router.  When DHCP-PD
       is used, the IGP has to redistribute the static routes installed
       during the process of prefix delegation.

    8.1.2.  Layer 3 Aware NAP with Layer 3 Termination at Access Router

       When an Access Router is present between the AP and Edge Router, the
       AP continues to work as a bridge, bridging IPv4 and IPv6 packets from
       WLAN Host/Router to Access Router and vice versa.  The Access Router
       could be part of the SP network or owned by a separate Access
       Provider.

       When the WLAN Host initiates the connection, the AAA authentication
       and association process with WLAN AP will be similar, as explained in
       Section 8.1.1.

       Figure 8.1.2 describes the WLAN architecture when the Access Router
       is located between the AP and Edge Router.

           Customer |             Access Provider        | Service Provider
           Premise  |                                    |

         +------+         +--+ +--------------+ +----------+ +------+
         |WLAN  |  ----   |  | |              | | Provider | |Edge  |
         |Host/ |-(WLAN)--|AP|-|Access Router |-| Network  |-|Router|=>SP
         |Router|  ----   |  | |              | |          | |      |Network
         +------+         +--+ +--------------+ +----------+ +------+
                                                               |
                                                            +------+
                                                            |AAA   |
                                                            |Server|
                                                            +------+

                                      Figure 8.1.2

    8.1.2.1.  IPv6 Related Infrastructure Changes

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

    Asadullah, et al.            Informational                     [Page 59]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    8.1.2.2.  Addressing

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

       A.  The Edge Router interface facing towards the Access Router is
           statically configured with a /64 prefix.  The Access Router
           receives/ configures a /64 prefix on its interface facing towards
           the Edge Router through stateless auto-configuration.  The
           network administrator will have to configure the /64 prefixes to
           the Access Router interface facing toward the customer premise.
           The WLAN Host/Router connected to this interface can
           automatically configure itself using stateless auto-
           configuration.

       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, the Edge Router, or somewhere in
           the SP network.  In this case, depending on where the DHCPv6
           server is located, the 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 auto-configuration
           the address for the link between itself and the ER.  This step is
           followed by a request via DHCP-PD for a prefix shorter 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 Access Router would act as a requesting
           router, and the Edge Router would act as a delegating router.
           Once the prefix is received by the Access Router, it assigns /64
           prefixes to each of its interfaces connecting the WLAN Host/
           Router on the customer site.  The WLAN Host/Router connected to
           these interfaces can automatically configure itself using
           stateless auto-configuration.  The uplink to the ISP network is
           configured with a /64 prefix as well.

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

    Asadullah, et al.            Informational                     [Page 60]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       As mentioned before, the prefixes used for subscriber links and the
       ones delegated via DHCP-PD should be planned in a manner that allows
       the maximum summarization possible at the Edge Router.  Other
       information of interest to the host, such as DNS, is provided through
       stateful [RFC3315] and stateless [RFC3736] DHCPv6.

    8.1.2.3.  Routing

       The WLAN Host/Router is configured with a default route that points
       to the 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.

       If the Access Router is owned by the SP, then the Access Router will
       also run IPv6 IGP, and will be part of the SP IPv6 routing domain
       (OSPFv3 or IS-IS).  The connected prefixes have to be redistributed.
       If DHCP-PD is used, with every delegated prefix a static route is
       installed by the Access Router.  For this reason, the static routes
       must be redistributed.  Prefix summarization should be done at the
       Access Router.

    8.1.3.  PPP-Based Model

       PPP Terminated Aggregation (PTA) and L2TPv2 Access Aggregation (LAA)
       models, as discussed in Sections 6.2.2 and 6.2.3, respectively, can
       also be deployed in IPv6 WLAN environment.

    8.1.3.1.  PTA Model in IPv6 WLAN Environment

       While deploying the PTA model in IPv6 WLAN environment, the Access
       Router is Layer 3 aware and it has to be upgraded to support IPv6.
       Since the Access Router terminates the PPP sessions initiated by the
       WLAN Host/Router, it has to support PPPoE with IPv6.

       Figure 8.1.3.1 describes the PTA Model in IPv6 WLAN environment.

    Asadullah, et al.            Informational                     [Page 61]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

           Customer |             Access Provider        | Service Provider
           Premise  |                                    |
         +------+         +--+ +--------------+ +----------+ +------+
         |WLAN  |  ----   |  | |              | | Provider | |Edge  |
         |Host/ |-(WLAN)--|AP|-|Access Router |-| Network  |-|Router|=>SP
         |Router|  ----   |  | |              | |          | |      |Network
         +------+         +--+ +--------------+ +----------+ +------+
                                                               |
           |---------------------------|                    +------+
                       PPP                                  |AAA   |
                                                            |Server|
                                                            +------+

                                    Figure 8.1.3.1

    8.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.

    8.1.3.1.2.  Addressing

       The addressing techniques described in Section 6.2.2.2 apply to the
       IPv6 WLAN PTA scenario as well.

    8.1.3.1.3.  Routing

       The routing techniques described in Section 6.2.2.3 apply to the IPv6
       WLAN PTA scenario as well.

    8.1.3.2.  LAA Model in IPv6 WLAN Environment

       While deploying the LAA model in IPv6 WLAN environment, the Access
       Router is Layer 3 aware and has to be upgraded to support IPv6.  The
       PPP sessions initiated by the WLAN Host/Router are forwarded over the
       L2TPv2 tunnel to the aggregation point in the SP network.  The Access
       Router must have the capability to support L2TPv2 for IPv6.

       Figure 8.1.3.2 describes the LAA Model in IPv6 WLAN environment.

    Asadullah, et al.            Informational                     [Page 62]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

           Customer |             Access Provider        | Service Provider
           Premise  |                                    |

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

                                    Figure 8.1.3.2

    8.1.3.2.1.  IPv6 Related Infrastructure Changes

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

    8.1.3.2.2.  Addressing

       The addressing techniques described in Section 6.2.3.2 apply to the
       IPv6 WLAN LAA scenario as well.

    8.1.3.2.3.  Routing

       The routing techniques described in Section 6.2.3.3 apply to the IPv6
       WLAN LAA scenario as well.

    8.2.  IPv6 Multicast

       The typical multicast services offered are video/audio streaming
       where the IPv6 WLAN Host joins a multicast group and receives the
       content.  This type of service model is well supported through PIM-
       SSM, which is enabled throughout the SP network.  MLDv2 is required
       for PIM-SSM support.  Vendors can choose to implement features that
       allow routers to map MLDv1 group joins to predefined sources.

    Asadullah, et al.            Informational                     [Page 63]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       It is important to note that in the shared wireless environments,
       multicast can have a significant bandwidth impact.  For this reason,
       the bandwidth allocated to multicast traffic should be limited and
       fixed, based on the overall capacity of the wireless specification
       used in 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 WLAN/Access Routers
       are used, then they have to be enabled to support MLDv1 and MLDv2 in
       order to process the requests of the IPv6 WLAN Hosts.  The WLAN/
       Access Router also needs to be enabled to support PIM-SSM in order to
       send PIM joins up to the Edge Router.  When enabling this
       functionality on a WLAN/Access Router, its limited resources should
       be taken into consideration.  Another option would be for the WLAN/
       Access Router to support MLD proxy routing.

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

       MLD authentication, authorization, and accounting are usually
       configured on the Edge Router in order to enable the SP to do billing
       for the content services provided.  Further investigation should be
       made in finding alternative mechanisms that would support these
       functions.

       Concerns have been raised in the past related to running IPv6
       multicast over WLAN links.  Potentially these are the same kind of
       issues when running any Layer 3 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 behavior is similar to an IGMP host membership report,
       when done on a WLAN link with a high loss-to-signal ratio and high
       interference.

       This problem is inherited by WLAN that can impact both IPv4 and IPv6
       multicast packets; it is not specific to IPv6 multicast.

       While deploying WLAN (IPv4 or IPv6), one should adjust their
       broadcast/multicast settings if they are in danger of dropping
       application dependent frames.  These problems are usually caused when
       the AP is placed too far (not following the distance limitations),
       high interference, etc.  These issues may impact a real multicast
       application such as streaming video or basic operation of IPv6 if the
       frames were dropped.  Basic IPv6 communications uses functions such
       as Duplicate Address Detection (DAD), Router and Neighbor

    Asadullah, et al.            Informational                     [Page 64]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA),
       etc., which could be impacted by the above mentioned issues as these
       frames are Layer 2 Ethernet multicast frames.

       Please refer to Section 6.3 for more IPv6 multicast details.

    8.3.  IPv6 QoS

       Today, QoS is done outside of the WiFi domain, but it is nevertheless
       important to the overall deployment.

       The QoS configuration is particularly relevant on the Edge Router in
       order to manage resources shared amongst multiple subscribers
       possibly with various service level agreements (SLAs).  However, the
       WLAN Host/Router and Access Router could also be configured for QoS.
       This includes support for appropriate classification criteria, which
       would need to be implemented for IPv6 unicast and multicast traffic.

       On the Edge Router, the subscriber-facing interfaces have to be
       configured to police the inbound customer traffic and shape the
       traffic outbound to the customer, based on the SLA.  Traffic
       classification and marking should also be done on the Edge Router in
       order to support the various types of customer traffic: data, voice,
       and video.  The same IPv4 QoS concepts and methodologies should be
       applied for the IPv6 as well.

       It is important to note that when traffic is encrypted end-to-end,
       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.

    8.4.  IPv6 Security Considerations

       There are limited changes that have to be done for WLAN the Host/
       Router in order to enhance security.  The privacy extensions
       [RFC3041] for auto-configuration should be used by the hosts with the
       same consideration for host traceability as described in Section 6.5.
       IPv6 firewall functions should be enabled on the WLAN Host/Router, if
       present.

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

    Asadullah, et al.            Informational                     [Page 65]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       If the host authentication at hotspots is done using a web-based
       authentication system, then the level of security would depend on the
       particular implementation.  User credentials 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 an important aspect of securing WLAN networks prior
       to implementing Layer 3 security policies.  For example, this would
       help avoid threats to the ND or stateless auto-configuration
       processes. 802.1x [IEEE8021X] provides the means to secure the
       network access; however, the many types of EAP (PEAP, EAP-TLS, EAP-
       TTLS, EAP-FAST, and LEAP) and the capabilities of the hosts to
       support some of the features might make it difficult to implement a
       comprehensive and consistent policy.

       The 802.11i [IEEE80211i] amendment has many components, the most
       obvious of which are the two new data-confidentiality protocols,
       Temporal Key Integrity Protocol (TKIP) and Counter-Mode/CBC-MAC
       Protocol (CCMP). 802.11i also uses 802.1X's key-distribution system
       to control access to the network.  Because 802.11 handles unicast and
       broadcast traffic differently, each traffic type has different
       security concerns.  With several data-confidentiality protocols and
       the key distribution, 802.11i includes a negotiation process for
       selecting the correct confidentiality protocol and key system for
       each traffic type.  Other features introduced include key caching and
       pre-authentication.

       The 802.11i amendment is a step forward in wireless security.  The
       amendment adds stronger encryption, authentication, and key
       management strategies that could make wireless data and systems more
       secure.

       If any Layer 2 filters for Ethertypes are in place, the NAP must
       permit the IPv6 Ethertype (0X86DD).

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

       The Access and the Edge Router should protect their processing
       resources against floods of valid customer control traffic such as:
       RS, NS, and MLD Requests.  Rate limiting should be implemented on all

    Asadullah, et al.            Informational                     [Page 66]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       subscriber-facing interfaces.  The emphasis should be placed on
       multicast-type traffic, as it is most often used by the IPv6 control
       plane.

    8.5.  IPv6 Network Management

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

       Usually, NSPs manage the edge routers by SNMP.  The SNMP transport
       can be done over IPv4 if all managed devices have connectivity over
       both IPv4 and IPv6.  This would imply the smallest changes to the
       existing network management practices and processes.  Transport over
       IPv6 could also be implemented and it might become necessary if IPv6
       only islands are present in the network.  The management applications
       may be running on hosts belonging to the NSP core network domain.
       Network Management Applications should handle IPv6 in a similar
       fashion to IPv4; however, they should also support features specific
       to IPv6 (such as neighbor monitoring).

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

    9.  Broadband Power Line Communications (PLC)

       This section describes the IPv6 deployment in Power Line
       Communications (PLC) Access Networks.  There may be other choices,
       but it seems that this is the best model to follow.  Lessons learnt
       from cable, Ethernet, and even WLAN access networks may be applicable
       also.

       Power Line Communications are also often called Broadband Power Line
       (BPL) and sometimes even Power Line Telecommunications (PLT).

       PLC/BPL can be used for providing, with today's technology, up to
       200Mbps (total, upstream+downstream) by means of the power grid.  The
       coverage is often the last half mile (typical distance from the
       medium-to-low voltage transformer to the customer premise meter) and,
       of course, as an in-home network (which is out of the scope of this
       document).

       The bandwidth in a given PLC/BPL segment is shared among all the
       customers connected to that segment (often the customers connected to
       the same medium-to-low voltage transformer).  The number of customers
       can vary depending on different factors, such as distances and even
       countries (from a few customers, just 5-6, up to 100-150).

    Asadullah, et al.            Informational                     [Page 67]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       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.

    9.1.  PLC/BPL Access Network Elements

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

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

       Repeater (RPT): A device that may be required in some circumstances
       to improve the signal on the PLC/BPL.  This may be the case if there
       are many customers in the same segment or building.  It is often a
       bridge, but it could also be a router if, for example, there is a lot
       of peer-to-peer traffic in a building and due to the master-slave
       nature of the PLC/BPL technology, is required to improve the
       performance within that segment.  For simplicity within this
       document, the RPT will always be considered a transparent Layer 2
       bridge, so it may or may not be present (from the Layer 3 point of
       view).

       Customer Premise Equipment (CPE): 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 9.1 depicts all the network elements indicated above.

       Customer Premise | Network Access Provider | Network Service Provider

        +-----+  +------+  +-----+        +------+   +--------+
        |Hosts|--| RCPE |--| RPT |--------+ Head +---+ Edge   |    ISP
        +-----+  +------+  +-----+        | End  |   | Router +=>Network
                                          +--+---+   +--------+
        +-----+  +------+  +-----+           |
        |Hosts|--| BCPE |--| RPT |-----------+
        +-----+  +------+  +-----+

                                        Figure 9.1

    Asadullah, et al.            Informational                     [Page 68]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       The logical topology and design of PLC/BPL is very similar to
       Ethernet Broadband Networks as discussed in Section 7.  IP
       connectivity is typically provided in a Point-to-Point model, as
       described in Section 7.2.1

    9.2.  Deploying IPv6 in IPv4 PLC/BPL

       The most simplistic and efficient model, considering the nature of
       the PLC/BPL networks, is to see the network as a point-to-point, one
       to each customer.  Even if several customers share the same physical
       media, the traffic is not visible among them because each one uses
       different channels, which are, in addition, encrypted by means of
       3DES.

       In order to maintain the deployment concepts and business models
       proven and used with existing revenue-generating IPv4 services, the
       IPv6 deployment will match the IPv4 one.  Under certain circumstances
       where new service types or service needs justify it, IPv4 and IPv6
       network architectures could be different.  Both approaches are very
       similar to those already described for the Ethernet case.

    9.2.1.  IPv6 Related Infrastructure Changes

       In this scenario, only the RPT is Layer 3 unaware, but the other
       devices have to be upgraded to dual stack Hosts, RCPE, Head End, and
       Edge Router.

    9.2.2.  Addressing

       The Hosts or the RCPEs have the HE as their Layer 3 next hop.

       If there is no RCPE, but instead a BCPE, all the hosts on the
       subscriber site belong to the same /64 subnet that is statically
       configured on the HE.  The hosts can use stateless auto-configuration
       or stateful DHCPv6-based configuration to acquire an address via the
       HE.

       If an RCPE is present:

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

       B.  It can use its link-local address to communicate with the HE.  It
           can also dynamically acquire through stateless auto-configuration
           the address for the link between itself and the HE.  This step is

    Asadullah, et al.            Informational                     [Page 69]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

           followed by a request via DHCP-PD for a prefix shorter than /64
           (typically /48 [RFC3177]) that, in turn, is divided in /64s and
           assigned to its interfaces connecting the hosts on the customer
           site.  This should be the preferred provisioning method, being
           cheaper and easier to manage.

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

       It could be possible to use a kind of Hierarchical Prefix Delegation
       to automatically provision the required prefixes and fully auto-
       configure the HEs, and consequently reduce the network setup,
       operation, and maintenance cost.

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

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

    9.2.3.  Routing

       If no routers are used on the customer premise, the HE can simply be
       configured with a default route that points to the Edge Router.  If a
       router is used on the customer premise (RCPE), then the HE could also
       run an IGP (such as OSPFv3, IS-IS or even RIPng) to the ER.  The
       connected prefixes should be redistributed.  If DHCP-PD is used, with
       every delegated prefix a static route is installed by the HE.  For
       this reason, the static routes must also be redistributed.  Prefix
       summarization should be done at the HE.

       The RCPE requires only a default route pointing to the HE.  No
       routing protocols are needed on these devices, which generally have
       limited resources.

       The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS.
       The connected prefixes have to be redistributed, as well as any
       routing protocols (other than the ones used on the ER) that might be
       used between the HE and the ER.

    Asadullah, et al.            Informational                     [Page 70]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    9.3.  IPv6 Multicast

       The considerations regarding IPv6 Multicast for Ethernet are also
       applicable here, in general, assuming the nature of PLC/BPL is a
       shared media.  If a lot of Multicast is expected, it may be worth
       considering using RPT which are Layer 3 aware.  In that case, one
       extra layer of Hierarchical DHCP-PD could be considered, in order to
       facilitate the deployment, operation, and maintenance of the network.

    9.4.  IPv6 QoS

       The considerations introduced for QoS in Ethernet are also applicable
       here.  PLC/BPL networks support QoS, which basically is the same
       whether the transport is IPv4 or IPv6.  It is necessary to understand
       that there are specific network characteristics, such as the
       variability that may be introduced by electrical noise, towards which
       the PLC/BPL network will automatically self-adapt.

    9.5.  IPv6 Security Considerations

       There are no differences in terms of security considerations if
       compared with the Ethernet case.

    9.6.  IPv6 Network Management

       The issues related to IPv6 Network Management in PLC networks should
       be similar to those discussed for Broadband Ethernet Networks in
       Section 7.6.  Note that there may be a need to define MIB modules for
       PLC networks and interfaces, but this is not necessarily related to
       IPv6 management.

    10.  Gap Analysis

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

       A.  As mentioned in section 5, 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.  These issues are addressed in
           a recent proposal made to Cable Labs for DOCSIS 3.0
           [DOCSIS3.0-Reqs].

    Asadullah, et al.            Informational                     [Page 71]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       B.  Section 6 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 6.  If, however, support and reason
           are found for a deployment similar to IPv4 RBE, then the
           environment becomes NBMA and the new feature should observe
           RFC2491 recommendations.

       C.  Section 6 discussed the constraints imposed on an 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.

       D.  Sections 6 and 7 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.

       E.  In relation to Section 8, concerns have been raised related to
           running IPv6 multicast over WLAN links.  Potentially, these are
           the same kind of issues when running any Layer 3 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 an
           IGMP host membership report, when done on a WLAN link with high
           loss-to-signal ratio and high interference.  This problem is
           inherited by WLAN that can impact both IPv4 and IPv6 multicast
           packets; it is not specific to IPv6 multicast.

       F.  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.

    Asadullah, et al.            Informational                     [Page 72]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       G.  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 addressed by the
                IETF Softwire Working Group.

       H.  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, such
           as automatic mapping of VLAN IDs/PVCs (or other customer-specific
           information) to IPv6 prefixes.

       I.  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 [RFC4562] is an example of such an
           implementation, where a broadcast domain is turned into an 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.

       J.  The deployment of IPv6 in continuously evolving access service
           models raises some issues that may need further investigation.
           Examples of such topics are [AUTO-CONFIG]:

            i.  Network Service Selection & Authentication (NSSA) mechanisms
                working in association with stateless auto-configuration.
                As an example, NSSA relevant information, such as ISP
                preference, passwords, or profile ID, can be sent by hosts
                with the RS [RFC4191].

    Asadullah, et al.            Informational                     [Page 73]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

            ii. Providing additional information in Router Advertisements to
                help access nodes with prefix selection in multi-ISP/
                multi-homed environments.

       Solutions to some of these topics range from making a media access
       capable of supporting native IPv6 (cable) to improving operational
       aspects of native IPv6 deployments.

    11.  Security Considerations

       Please refer to the individual "IPv6 Security Considerations"
       technology sections for details.

    12.  Acknowledgements

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

    13.  References

    13.1.  Normative References

       [RFC1918]         Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot,
                         G., and E. Lear, "Address Allocation for Private
                         Internets", BCP 5, RFC 1918, February 1996.

       [RFC2080]         Malkin, G. and R. Minnear, "RIPng for IPv6",
                         RFC 2080, January 1997.

       [RFC2364]         Gross, G., Kaycee, M., Lin, A., Malis, A., and J.
                         Stephens, "PPP Over AAL5", RFC 2364, July 1998.

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

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

       [RFC2473]         Conta, A. and S. Deering, "Generic Packet Tunneling
                         in IPv6 Specification", RFC 2473, December 1998.

    Asadullah, et al.            Informational                     [Page 74]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       [RFC2516]         Mamakos, L., Lidl, K., Evarts, J., Carrel, D.,
                         Simone, D., and R. Wheeler, "A Method for
                         Transmitting PPP Over Ethernet (PPPoE)", RFC 2516,
                         February 1999.

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

       [RFC2661]         Townsley, W., Valencia, A., Rubens, A., Pall, G.,
                         Zorn, G., and B. Palter, "Layer Two Tunneling
                         Protocol "L2TP"", RFC 2661, August 1999.

       [RFC2740]         Coltun, R., Ferguson, D., and J. Moy, "OSPF for
                         IPv6", RFC 2740, December 1999.

       [RFC2784]         Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
                         Traina, "Generic Routing Encapsulation (GRE)",
                         RFC 2784, March 2000.

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

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

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

       [RFC3177]         IAB and IESG, "IAB/IESG Recommendations on IPv6
                         Address Allocations to Sites", RFC 3177,
                         September 2001.

       [RFC3180]         Meyer, D. and P. Lothberg, "GLOP Addressing in
                         233/8", BCP 53, RFC 3180, September 2001.

       [RFC3315]         Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
                         C., and M. Carney, "Dynamic Host Configuration
                         Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

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

       [RFC3704]         Baker, F. and P. Savola, "Ingress Filtering for
                         Multihomed Networks", BCP 84, RFC 3704, March 2004.

    Asadullah, et al.            Informational                     [Page 75]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

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

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

       [RFC3931]         Lau, J., Townsley, M., and I. Goyret, "Layer Two
                         Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
                         March 2005.

       [RFC4001]         Daniele, M., Haberman, B., Routhier, S., and J.
                         Schoenwaelder, "Textual Conventions for Internet
                         Network Addresses", RFC 4001, February 2005.

       [RFC4029]         Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
                         Savola, "Scenarios and Analysis for Introducing
                         IPv6 into ISP Networks", RFC 4029, March 2005.

       [RFC4191]         Draves, R. and D. Thaler, "Default Router
                         Preferences and More-Specific Routes", RFC 4191,
                         November 2005.

       [RFC4213]         Nordmark, E. and R. Gilligan, "Basic Transition
                         Mechanisms for IPv6 Hosts and Routers", RFC 4213,
                         October 2005.

       [RFC4214]         Templin, F., Gleeson, T., Talwar, M., and D.
                         Thaler, "Intra-Site Automatic Tunnel Addressing
                         Protocol (ISATAP)", RFC 4214, October 2005.

       [RFC4380]         Huitema, C., "Teredo: Tunneling IPv6 over UDP
                         through Network Address Translations (NATs)",
                         RFC 4380, February 2006.

    13.2.  Informative References

       [6PE]             De Clercq, J., Ooms, D., Prevost, S., and F. Le
                         Faucheur, "Connecting IPv6 Islands across IPv4
                         Clouds with BGP", Work in Progress, December 2006.

       [AUTO-CONFIG]     Wen, H., Zhu, X., Jiang, Y., and R. Yan, "The
                         deployment of IPv6 stateless auto-configuration in
                         access network", 8th International Conference on
                         Telecommunications, ConTEL 2005, June 2005.

    Asadullah, et al.            Informational                     [Page 76]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       [BSR]             Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
                         "Bootstrap Router (BSR) Mechanism for PIM", Work
                         in Progress, June 2006.

       [DOCSIS3.0-OSSI]  CableLabs, CL., "DOCSIS 3.0 OSSI Specification(CM-
                         SP-OSSIv3.0-D02-060504)", May 2006.

       [DOCSIS3.0-Reqs]  Droms, R., Durand, A., Kharbanda, D., and J-F.
                         Mule, "DOCSIS 3.0 Requirements for IPv6 Support",
                         Work in Progress, March 2006.

       [DynamicTunnel]   Palet, J., Diaz, M., and P. Savola, "Analysis of
                         IPv6 Tunnel End-point Discovery Mechanisms", Work
                         in Progress, January 2005.

       [IEEE80211i]      IEEE, "IEEE Standards for Information Technology:
                         Part 11: Wireless LAN Medium Access Control (MAC)
                         and Physical Layer (PHY) specifications, Amendment
                         6: Medium Access Control (MAC) Security
                         Enhancements", July 2004.

       [IEEE8021X]       IEEE, "IEEE Standards for Local and Metropolitan
                         Area Networks: Port based Network Access Control,
                         IEEE Std 802.1X-2001", June 2001.

       [IPv6-Multicast]  Savola, P., "IPv6 Multicast Deployment Issues",
                         Work in Progress, April 2004.

       [IPv6-Security]   Convery, S. and D. Miller, "IPv6 and IPv4 Threat
                         Comparison and Best-Practice Evaluation",
                         March 2004.

       [ISISv6]          Hopps, C., "Routing IPv6 with IS-IS", Work
                         in Progress, October 2005.

       [ISP-CASES]       Mickles, C., "Transition Scenarios for ISP
                         Networks", Work in Progress, September 2002.

       [Protocol41]      Palet, J., Olvera, C., and D. Fernandez,
                         "Forwarding Protocol 41 in NAT Boxes", Work
                         in Progress, October 2003.

       [RF-Interface]    CableLabs, CL., "DOCSIS 2.0(CM-SP-RFIv2.0-I10-
                         051209)", December 2005.

       [RFC4562]         Melsen, T. and S. Blake, "MAC-Forced Forwarding: A
                         Method for Subscriber Separation on an Ethernet
                         Access Network", RFC 4562, June 2006.

    Asadullah, et al.            Informational                     [Page 77]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

       [Softwire]        Dawkins, S., Ed., "Softwire Problem Statement",
                         Work in Progress, May 2006.

       [v6tc]            Palet, J., Nielsent, K., Parent, F., Durand, A.,
                         Suryanarayanan, R., and P. Savola, "Goals for
                         Tunneling Configuration", Work in Progress,
                         August 2005.

    Asadullah, et al.            Informational                     [Page 78]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    Authors' Addresses

       Salman Asadullah
       Cisco Systems
       170 West Tasman Drive
       San Jose, CA  95134
       USA

       Phone: 408 526 8982
       EMail: sasad@cisco.com

       Adeel Ahmed
       Cisco Systems
       2200 East President George Bush Turnpike
       Richardson, TX  75082
       USA

       Phone: 469 255 4122
       EMail: adahmed@cisco.com

       Ciprian Popoviciu
       Cisco Systems
       7025-6 Kit Creek Road
       Research Triangle Park, NC  27709
       USA

       Phone: 919 392 3723
       EMail: cpopovic@cisco.com

       Pekka Savola
       CSC - Scientific Computing Ltd.
       Espoo
       Finland

       EMail: psavola@funet.fi

    Asadullah, et al.            Informational                     [Page 79]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

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

       Phone: +34 91 151 81 99
       EMail: jordi.palet@consulintel.es

    Asadullah, et al.            Informational                     [Page 80]

    RFC 4779          ISP IPv6 Deployment Scenarios in BB       January 2007

    Full Copyright Statement

       Copyright (C) The IETF Trust (2007).

       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.

       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, THE IETF TRUST 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.

    Intellectual Property

       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 described 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.

    Acknowledgement

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

    Asadullah, et al.            Informational                     [Page 81]