tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4779

 
 
 

ISP IPv6 Deployment Scenarios in Broadband Access Networks

Part 3 of 4, p. 26 to 55
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 26 
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).

Top      Up      ToC       Page 27 
   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

Top      Up      ToC       Page 28 
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

Top      Up      ToC       Page 29 
   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.

Top      Up      ToC       Page 30 
   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

Top      Up      ToC       Page 31 
   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.

Top      Up      ToC       Page 32 
   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.

Top      Up      ToC       Page 33 
   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:

Top      Up      ToC       Page 34 
   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.

Top      Up      ToC       Page 35 
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.

Top      Up      ToC       Page 36 
   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.

Top      Up      ToC       Page 37 
   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.

Top      Up      ToC       Page 38 
   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

Top      Up      ToC       Page 39 
   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

Top      Up      ToC       Page 40 
   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

Top      Up      ToC       Page 41 
   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.

Top      Up      ToC       Page 42 
   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)

Top      Up      ToC       Page 43 
   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.

Top      Up      ToC       Page 44 
   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

Top      Up      ToC       Page 45 
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.

Top      Up      ToC       Page 46 
   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.

Top      Up      ToC       Page 47 
   |     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.

Top      Up      ToC       Page 48 
   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.

Top      Up      ToC       Page 49 
   | 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.

Top      Up      ToC       Page 50 
   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.

Top      Up      ToC       Page 51 
   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

Top      Up      ToC       Page 52 
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.

Top      Up      ToC       Page 53 
   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.

Top      Up      ToC       Page 54 
   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.

Top      Up      ToC       Page 55 
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.



(page 55 continued on part 4)

Next RFC Part