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 2 of 4, p. 9 to 26
Prev RFC Part       Next RFC Part

 


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



(page 26 continued on part 3)

Next RFC Part