Internet DRAFT - draft-sun-supa-openv6-use-cases

draft-sun-supa-openv6-use-cases






Network Working Group                                             C. Xie
Internet-Draft                                                    Q. Sun
Intended status: Informational                             China Telecom
Expires: March 29, 2015                                     JF. Tremblay
                                                                Viagenie
                                                      September 25, 2014


                  Use case of IPv6 transition in SUPA
                   draft-sun-supa-openv6-use-cases-00

Abstract

   The IPv6 transition has been an ongoing process throughout the world
   due to the exhaustion of the IPv4 address space.  However, this
   transition leads to costly end-to-end network upgrades and poses new
   challenges of managing a large number of devices with a variety of
   transitioning protocols.  While IPv6 transition tools exist, there
   are still new issues exist.  Operators may need various types of IPv6
   transition technologies depending on performance requirements,
   deployment scenarios, etc.

   To address these difficulties, a software defined unifying approach
   would provide a unified way to deploy IPv6 in a cost-effective,
   flexible manner.

   This document describes use cases of IPv6 transition (Openv6) and
   also requirements in SUPA architecture.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on March 29, 2015.

Copyright Notice




Xie, et al.              Expires March 29, 2015                 [Page 1]

Internet-Draft     Use case of IPv6 transition in supa    September 2014


   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  IPv6 transition Use case  . . . . . . . . . . . . . . . . . . . 3
     3.1.  Evolve from one Scenario to Another . . . . . . . . . . . . 3
     3.2.  Multiple Transition Mechanisms Co-Exist . . . . . . . . . . 4
     3.3.  Scattered Address Pool Management . . . . . . . . . . . . . 5
     3.4.  Virtualized Computing Resource Management . . . . . . . . . 5
     3.5.  Transition Function Openness to Third-party
           Applications  . . . . . . . . . . . . . . . . . . . . . . . 6
     3.6.  ISP Customers Opt-out for Transition Mechanisms . . . . . . 6
       3.6.1.  Failure Modes for Transition Mechanisms . . . . . . . . 6
       3.6.2.  Failure Modes for Native Deployments  . . . . . . . . . 7
       3.6.3.  Application-driven Opt-out Mechanism for ISPs . . . . . 7
   4.  SUPA Application in Openv6  . . . . . . . . . . . . . . . . . . 8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9















Xie, et al.              Expires March 29, 2015                 [Page 2]

Internet-Draft     Use case of IPv6 transition in supa    September 2014


1.  Introduction

   The exhaustion of the IPv4 address space has been a practical problem
   that providers are facing today.  Network address migration to IPv6
   is ongoing or upcoming throughout the world.  However, IPv6 requires
   costly end-to-end network upgrades and different network scenarios
   will co-exist during IPv6 transition.  Therefore, operators have to
   upgrade network devices to support different transition tools, or buy
   new devices for different scenarios.

   This document describes use cases of IPv6 transition (Openv6) and
   also requirements in SUPA architecture.


2.  Terminology


3.  IPv6 transition Use case

3.1.   Evolve from one Scenario to Another

   During the IPv6 transition period, the network needs three stages of
   IPv4-only, dual-stack and IPv6-only.  The networks should support
   both IPv4 services and IPv6 services at each stage.[Reference-Mark]

   There are multiple IPv6 transition technologies for different network
   scenarios (e.g.  IPv4 network for IPv4/IPv6 user access, IPv6 network
   for IPv4/IPv6 user access, IPv4 servers for IPv6 visitors, etc.).
   Different network scenarios will co-exist during IPv6 transition
   which means the IPv6 transition device should support multiple IPv6
   transition technologies.  The following are possible scenarios in the
   whole IPv6 transition period.

      1)Scenario 1: IPv6 host visit IPv6 servers via IPv4 access network

      2)Scenario 2: IPv4 host visit IPv4 servers via IPv4 NAT Dual-stack
      network

      3)Scenario 3: IPv6 host visit IPv6 servers via IPv6 network

      4)Scenario 4: IPv4 host visit IPv4 servers via IPv6 access network

      5)Scenario 5: IPv6 host visit IPv6 servers via IPv4 access network

      6)Scenario 6: IPv4 host and IPv6 host interaction

   It is not necessary that every operator will go through each scenario
   one by one.  For example, some operators may start from scenario 1,



Xie, et al.              Expires March 29, 2015                 [Page 3]

Internet-Draft     Use case of IPv6 transition in supa    September 2014


   and some may start directly from scenario 2 or scenario 4.  However,
   since the final stage (target) is the IPv6-only access network, one
   still need to undergo multiple scenarios from the long term.

   In such a case, the operator should either upgrade existing devices
   to support new features, or replace them with new ones.  In
   particular, when the operator's network consists of devices from
   different vendors, it is hard to guarantee that all the legacy
   devices can be upgraded at the same time.  This is costly and
   complicated.

   The requirements are:

      1.  The Transition Data Plane should be flexible to deal with
      different scenarios and different mechanisms.

      2.  The Transition Control Plane should be able to notify the
      Transition Data Plane with its desired scenario.  It is also have
      the ability to collect the current status from the running
      Transition Devices.

3.2.  Multiple Transition Mechanisms Co-Exist

   In transition from one scenario to another, different transition
   mechanisms may have different impacts on user experience.  For
   example, DS-Lite would have some impact due to address sharing
   compared to 6rd mechanisms, and NAT64 would have extra impact due to
   ALG issues.  Operators will need to offer a fallback mechanism to
   guarantee the same level of user experience when there are complaints
   from subscribers.  Therefore, it is required to support multiple
   transition mechanisms in the same area (even in the same device).

   Another use case is that multiple scenarios may exist in the same
   stage.  For example, if there are both IPv6-only devices and IPv4-
   only host in the same area with limited public IPv4 address, both
   NAT64 and NAT44 (or DS-Lite) are required to achieve IPv4 service
   connectivity.

   Current implementations normally use a separate instance for each
   mechanism,, and additional policies need to be applied when running
   multiple mechanisms in one device.  Some have a limitation on the
   number of policies which can be configured in one device, while some
   have restrictions regarding the resource occupation (e.g. one
   transition instance will occupy a static amount of memory).

   The major requirements in multiple transition co-existence mainly lie
   in two aspects:




Xie, et al.              Expires March 29, 2015                 [Page 4]

Internet-Draft     Use case of IPv6 transition in supa    September 2014


      The need to implement different IPv6 transition technologies in
      the same hardware and the need to support this by upgrading
      network devices as little as possible.

      The need to hop over legacy infrastructures which are not IPv6
      enabled, costly or impossible to upgrade.

3.3.  Scattered Address Pool Management

   When operators are facing with address shortage problem, the
   remaining IPv4 address pools are usually quite scattered.  It is
   quite complicated for an operator to manage scattered address pools
   in many transition devices.  The situation will become even worse
   when multiple transition mechanisms in the same device need to be
   configured with different address pools.  Besides, since the
   occupation of the address pools may vary during different transition
   periods, (e.g. when there is not many IPv6-enabled services and IPv6-
   enabled devices, IPv4 traffic will still occupy a great portion of
   the total traffic, while in the later stage of IPv6 transition, IPv4
   traffic will decrease and the amount of IPv4 address pools will
   decrease accordingly.

   The ideal way is to manage the address pools centrally.  Different
   transition mechanisms can require the address pools on-demand.  For
   example, when one transition mechanism is running out of the current
   address pools,it may request a additional address pool.  It can also
   release the address pools that it is not using anymore.  In this way,
   operators do not need to configure the address pools one by one
   manually and it also helps using the address pools more efficiently.

   The major requirements are:

      The management plane should have the ability to configure the
      address pools for different mechanisms centralized.

      The management plane should be able to send the address pool
      information to the transition devices.

3.4.  Virtualized Computing Resource Management

   Many IPv6 transition mechanisms (e.g.  DS-Lite, CGN, etc.) would need
   to consume a lot of computing resources to maintain a large number of
   session tables.  However, since the number of concurrent subscribers
   may vary during different periods of time, it will be more flexible
   to manage the computing resouces centrally.  For example, we may add
   more computing resources when current resouces are not enough and
   release back to the resource pool if not necessary.




Xie, et al.              Expires March 29, 2015                 [Page 5]

Internet-Draft     Use case of IPv6 transition in supa    September 2014


   The major reuiqrements are :

      The management plane is able to allocate and withdrawn the
      computing resource for certain v6transition traffic.

      The management plane is able to request more resources for certain
      v6transition traffic.

3.5.  Transition Function Openness to Third-party Applications

   In migration from IPv4 to IPv6, some transition functionalities may
   be opened to Third-party ICPs.  For example, the NAT traversal
   functionality may be opened to Content Providers as a value-added
   service.  IPv4/IPv6 translation functionality can also be opened to
   Content Providers in order to support IPv6 client communicating with
   IPv4 peer.  It is also possible that one day, OTT providers may rent
   CGN functionality from operators to provide IPv6 access for end-host
   subscribers.

   Therefore, transition functions are required to have an interface for
   third-party applications.

3.6.  ISP Customers Opt-out for Transition Mechanisms

   While deploying transition scenarios detailed in section 3.1, such as
   6RD, DS-Lite, NAT444 or NAT64, ISPs may not be able to reach 100%
   end-user coverage for a specific mechanism.  Some failure modes exist
   for diverse end-user equipment, mechanisms and applications,
   depending if the deployment is done over a very homogenous or diverse
   user base and device population.  Failure modes may also exist for
   dual - stack deployments or native IPv6 without transition
   mechanisms.

3.6.1.  Failure Modes for Transition Mechanisms

   Device-based failure may be caused by inexistent or partial
   implementations in user CPE devices (aka home routers).  For example,
   some off-the-shelf home routers implement 6RD partially, sometimes
   with or without DHCPv4 option 212 support.  In the former case, 6RD
   failure may result from wrong 6RD parameters entered manually by a
   user.  In the latter case, failure may happen from partial
   implementations of the 6RD specifications [RFC5969] for example those
   without support for values of IPv4MaskLen larger than zero or when
   the IPv6 MTU is not reduced in IPv6 Router Advertisements (RA).

   For DS-Lite and NAT444, failure modes are usually application-related
   and are introduced through the presence of the additional IPv4
   Network Address Translation (NAT) function in the provider network.



Xie, et al.              Expires March 29, 2015                 [Page 6]

Internet-Draft     Use case of IPv6 transition in supa    September 2014


   These application may not support the interaction of with the ISP NAT
   device such as Port Control Protocol [RFC6887].

   For NAT64 deployments, failure modes are also often application-based
   or destination-specific and therefore can't be detected at the time
   of provisioning.  Such cases includes the presence of IPv4-only
   applications on the end-host (a mobile UE for example) without the
   presence of of a local CLAT/646XLAT implementation [RFC6877].  Other
   failure modes may be present if the DNS64 function shows difficulties
   for the synthesis of an IPv4-only server entry.

3.6.2.  Failure Modes for Native Deployments

   Failure modes for native deployments include those for IPv6-only
   deployments and dual-stack deployments.  Reasons for failures are
   various and include improper implementations of DHCPv6 and DHCPv6-PD
   in customer-grade home routers, improper or absent handling of IPv6
   DNS in Router Advertisement or local DHCPv6, absent or defective
   DHCPv6 server implementation on the LAN side, etc.  For example,
   early DHCPv6-PD implementations did not support delegated prefixes
   shorter than a /64 and would show erratic behaviour (such as RAs with
   prefixes advertisements longer than /64 on the LAN) or failure to
   operate in IPv6.

   Such defective implementations exist now in customer-grade equipment
   that may not be updated by newer software versions during their
   lifetime, if a newer non-defective firmware exists at all.  These
   defective implementation may lead to invalid IPv6 configurations on
   hosts, causing delays or application breakage, especially if Happy
   Eyeballs [RFC6555] type fallback is not implemented.

3.6.3.  Application-driven Opt-out Mechanism for ISPs

   In the cases mentioned above, it may be optimal for the ISP to allow
   the user or the application to opt-out dynamically from the
   transition mechanism or request access to the original native version
   of the access provisioning (such as standard NAT44, native IPv6 or
   through dual-stack IPv6).  Whether the access to such a feature is
   linked to the ISP billing scheme, such as a specific tier or paid
   add-on service, is out-of scope for the present document but could be
   considered by the ISP.

   For example, customers who host PC or console-based gaming servers
   and are affected by the deployment of mechanisms such as NAT444 or
   DS-Lite could choose to get a public address for their server based
   on a specific time-frame and other application-based requirements
   such as required latency, QoS and bandwidth.  Other examples include
   real-time chat or video-conferencing applications that could signal



Xie, et al.              Expires March 29, 2015                 [Page 7]

Internet-Draft     Use case of IPv6 transition in supa    September 2014


   their requirements to the network, which would then select an optimal
   transition mechanism based on them.


4.  SUPA Application in Openv6

   SUPA will define network management application-based policy
   protocol(s), mechanisms and models required to map application's
   demands to network management policies en procedures (e.g. traffic
   redirection based on customer's grade and link status), which can be
   directly enforced by a network management system on network devices,
   to meet the operator's demands.

   The network application in openv6 case needs to manipulate the
   network to achieve its service requirements.  Various IPv6 transition
   mechanisms (e.g.,Lw4o6, MAP, and etc.) are considered to be a variety
   of applications in Openv6.  SUPA configures the openv6 policy
   information (i.e., flow table)in the network management application
   in the form of network configuration models.  The flow table is used
   for handling incoming packets of the forwarding node.  The flow table
   can be updated by the application based on the user requirements.  If
   an incoming packet does not match any entry of the flow table, the
   packet will be delivered to the ABPD for generating new entries.


5.  Security Considerations


6.  Acknowledgements

   N/A.


7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2.  Informative References

   [RFC5571]  Storer, B., Pignataro, C., Dos Santos, M., Stevant, B.,
              Toutain, L., and J. Tremblay, "Softwire Hub and Spoke
              Deployment Framework with Layer Two Tunneling Protocol
              Version 2 (L2TPv2)", RFC 5571, June 2009.

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4



Xie, et al.              Expires March 29, 2015                 [Page 8]

Internet-Draft     Use case of IPv6 transition in supa    September 2014


              Infrastructures (6rd) -- Protocol Specification",
              RFC 5969, August 2010.

   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", RFC 6145, April 2011.

   [RFC6219]  Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
              China Education and Research Network (CERNET) IVI
              Translation Design and Deployment for the IPv4/IPv6
              Coexistence and Transition", RFC 6219, May 2011.

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, August 2011.

   [RFC6535]  Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
              Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012.

   [RFC6654]  Tsou, T., Zhou, C., Taylor, T., and Q. Chen, "Gateway-
              Initiated IPv6 Rapid Deployment on IPv4 Infrastructures
              (GI 6rd)", RFC 6654, July 2012.

   [RFC6674]  Brockners, F., Gundavelli, S., Speicher, S., and D. Ward,
              "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674,
              July 2012.


Authors' Addresses

   Chongfeng Xie
   China Telecom
   No.118 Xizhimennei street, Xicheng District
   Beijing  100035
   P.R. China

   Email: xiechf@ctbri.com.cn


   Qiong Sun
   China Telecom
   No.118 Xizhimennei street, Xicheng District
   Beijing  100035
   P.R. China

   Email: sunqiong@ctbri.com.cn






Xie, et al.              Expires March 29, 2015                 [Page 9]

Internet-Draft     Use case of IPv6 transition in supa    September 2014


   JF Tremblay
   Viagenie


   Email: jean-francois.tremblay@viagenie.ca














































Xie, et al.              Expires March 29, 2015                [Page 10]