tech-invite   World Map     

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

RFC 4779

 Errata 
Informational
Pages: 81
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: V6OPS

ISP IPv6 Deployment Scenarios in Broadband Access Networks

Part 1 of 4, p. 1 to 9
None       Next RFC Part

 


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


       ISP IPv6 Deployment Scenarios in Broadband Access Networks

Status of This Memo

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

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

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

Top       Page 2 
Table of Contents

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

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

Top      ToC       Page 4 
1.  Introduction

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

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

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

   The following important pieces are discussed:

   A. Available tunneling options

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

   C. Available IPv6 address assignment techniques and their use

   D. Possible IPv6 Routing options and their use

   E. IPv6 unicast and multicast packet transmission

   F. Required IPv6 Quality of Service (QoS) parameters

   G. Required IPv6 Security parameters

   H. Required IPv6 Network Management parameters

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

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

Top      ToC       Page 5 
2.  Common Terminology

   BB: Broadband

   CPE: Customer Premise Equipment

   GWR: Gateway Router

   ISP: Internet Service Provider

   NAP: Network Access Provider

   NSP: Network Service Provider

   QoS: Quality of Service

   SP: Service Provider

3.  Core/Backbone Network

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

   There are two types of networks identified in the Broadband
   deployments:

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

   B.  Service Provider Network: This network provides Intranet and
       Internet IP connectivity for the subscribers.

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

3.1.  Layer 2 Access Provider Network

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

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

3.2.  Layer 3 Access Provider Network

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

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

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

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

   B.  Native IPv6 Deployment: The Access Provider routers are upgraded
       to support IPv6 and can become dual stack.  In a dual-stack
       network, an IPv6 Interior Gateway Protocol (IGP), such as OSPFv3
       [RFC2740] or IS-IS [ISISv6], is enabled.  RFC 4029 [RFC4029]
       discusses the IGP selection options with their benefits and
       drawbacks.

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

   The 6PE approach has the advantage of having minimal impact on the
   Access Provider network.  Fewer devices need to be upgraded and

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

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

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

4.  Tunneling Overview

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

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

4.1.  Access over Tunnels - Customers with Public IPv4 Addresses

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

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

4.2.  Access over Tunnels - Customers with Private IPv4 Addresses

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

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

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

4.3.  Transition a Portion of the IPv4 Infrastructure

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

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

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

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



(page 9 continued on part 2)

Next RFC Part