[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group                                             Q. Sun
Internet-Draft                                             China Telecom
Intended status: Informational                                    W. Liu
Expires: August 17, 2014                                         C. Zhou
                                                     Huawei Technologies
                                                            G. Leclanche
                                                                Viagenie
                                                       February 13, 2014


                  Problem Statement for Openv6 Scheme
                 draft-sun-openv6-problem-statement-01

Abstract

   This document assesses the variety and complexity of IPv6
   deployments, and proposes a new space of study to simplify the
   enablement of new IPv6 applications on an existing network.  The
   document evaluates the identified technical gaps as well.

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 August 17, 2014.

Copyright Notice

   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



Sun, et al.              Expires August 17, 2014                [Page 1]


Internet-Draft          Openv6 Problem Statement           February 2014


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Extent and Existing Work  . . . . . . . . . . . . . .   3
     3.1.  Variety of IPv6 deployment technologies . . . . . . . . .   3
     3.2.  Complexity of IPv6 operation  . . . . . . . . . . . . . .   5
       3.2.1.  End-to-End Network Management . . . . . . . . . . . .   5
       3.2.2.  Open Network Business Capabilities  . . . . . . . . .   6
     3.3.  Existing evaluations of the IPv6 Transition Landscape . .   7
   4.  Alternative Approach to IPv6 applications enablement  . . . .   8
   5.  Existing protocols and methods for the alternate approach . .   9
   6.  Missing protocols and methods for the alternate approach  . .   9
     6.1.  Dynamic devices forwarding table configuration  . . . . .   9
     6.2.  Address Management  . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     7.1.  Source Address Validation and Traceback with Openv6 . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   9.  Authors . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

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
   activation requires costly end-to-end network upgrades and different
   network scenarios will co-exist during IPv6 transition.  In addition,
   the technologies deployed for the transition are suppose to be
   obsoleted once the transition is completed.

   This document proposes a new approach to deploy and operate IPv6
   applications on a network, whether related to transition technologies
   or purely native ones.  Such a technology would allow to continue
   using the same equipments and operational practices for various
   deployment scenarios.







Sun, et al.              Expires August 17, 2014                [Page 2]


Internet-Draft          Openv6 Problem Statement           February 2014


2.  Terminology

3.  Problem Extent and Existing Work

3.1.  Variety of IPv6 deployment technologies

   The IPv6 transition period contains three stages for IP Networks:
   IPv4-only, dual-stack and IPv6-only.  The networks should support
   both IPv4 services and IPv6 services during each
   stage.[One-vision-for-IPv6]

   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 the IPv6 transition
   period, which means the devices implementing the IPv6 transition
   technology should support the array of technologies, or there has to
   be as many devices as technologies used in a given network.  The
   following scenarios below will happen during the IPv6 transition
   period :

      Scenario 1: An IPv6 host visits IPv6 servers via an IPv4 access
      network

      Scenario 2: An IPv4 host visits IPv4 servers via an IPv4 NAT Dual-
      stack network

      Scenario 3: An IPv6 host visits IPv6 servers via an IPv6 network

      Scenario 4: An IPv4 host visits IPv4 servers via an IPv6 access
      network

      Scenario 5: IPv4 host and IPv6 host interaction

   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 issue.  An operator having a diverse customer
   base might have to deploy different transition technologies for a
   given scenario depending on the required user experience.  This
   implies that it is useful to support multiple transition mechanisms
   in the same area, and preferably on the same transition devices.

   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.



Sun, et al.              Expires August 17, 2014                [Page 3]


Internet-Draft          Openv6 Problem Statement           February 2014


   The 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 that can be configured in one device, while some
   have restrictions regarding the resource occupation (e.g. one
   transition instance will use a static amount of memory).  The major
   challenges of IPv6 deployment mainly lie in two aspects:

      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.

   The issues are:

      1.  How to support multiple transition mechanisms in a cost-
      efficient and flexible way ?

      2.  How to easily identify the transition type of different
      subscribers ?

   A random operator will most likely not go through each scenario one
   by one.  For example, some operators may start from scenario 1, and
   some may start directly from scenario 2 or scenario 4.  However,
   since the target scenario is the IPv6-only access network, a single
   operator will be confronted to multiple scenarios on 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 difficult to guarantee that all the legacy
   devices can be upgraded at the same time.  This is costly and
   operationally complicated.

   We call Transition Data Plane (TDP) the data forwarding plane of the
   operator network during the whole transition period.  Issues that can
   be identified to improve the situation are:

      1.  How to manipulate Transition Data Plane with different modes?

      2.  How to identify the capabilities of different transition
      devices ?

      3.  How does the Transition Data Plane identify different modes in
      the unified platform ?




Sun, et al.              Expires August 17, 2014                [Page 4]


Internet-Draft          Openv6 Problem Statement           February 2014


3.2.  Complexity of IPv6 operation

3.2.1.  End-to-End Network Management

3.2.1.1.  Scattered Address Pool Management

   When operators are facing the IPv4 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, the occupation of
   the address pools may vary during different transition periods: when
   there is not many IPv6-enabled services and IPv6-enabled devices,
   IPv4 traffic will still represent a great portion of the total
   traffic, while in the later stage of IPv6 transition, IPv4 traffic
   will decrease and the amount of allocated IPv4 addresses may decrease
   as well, depending on customer requirements.

   A solution could be 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 any longer.  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.

   Fixing this problem implies solving those issues:

      1.  How to configure the address pools for different mechanisms ?

      2.  How to collect the current status of address pool usage ?

3.2.1.2.  Source Address Validation and Traceback with Openv6

   It has been long known the IPv4/IPv6 transition makes the tracking
   and validating of source IP address challenging.  Whenever an IPvX
   packet is translated into an IPvY packet, a major change happens to
   the IP packet, which brings new issues:

      1.  How to track the origin of the IPvY packet which is actually
      in the IPvX world?

      2.  How to validate the IPvX packet at the edge of the IPvY world
      to prevent possible spoofing?

      3.  How to protect the IPvY address from being spoofed in the IPvY
      world?



Sun, et al.              Expires August 17, 2014                [Page 5]


Internet-Draft          Openv6 Problem Statement           February 2014


   SAVI[RFC7039] defines the source address validation solutions for
   both IPv4 and IPv6, but doesn't cover the scenario where an IPv4/IPv6
   transition technology is used in the network.  Currently designing a
   solution for the transition scenario is not an easy task.  There are
   two main challenges:

   1. the diversity of IPv4/IPv6 transition mechanisms.  There have been
   a number of transition mechanism.  Moreover, new transition
   mechanisms may be standardized in the future.  It would be complex
   for a SAVI solution to understand each transition mechanism.  An
   unified abstraction of the transition mechanisms (for example, an
   abstract Openv6 Transition Data Plan (TDP)) and a set of unified open
   interfaces should be provided by Openv6 to the SAVI solution for the
   transition scenario.  Then the SAVI solution could know the
   correspondences between the two IP protocols without having to
   inspect each packet or keep heavy state locally.  The SAVI solution
   can then generate filtering rules and process tracking.

   2. the inflexibility of SAVI.  Currently SAVI solutions are tightly
   associated with address assignment mechanisms.  It should be noted
   that each IPv4/IPv6 transition mechanism actually introduce a new
   mechanism to assign valid IPv4/IPv6 addresses.  Based on the current
   model of SAVI, the SAVI solution for the transition scenario should
   be able to track the address translation in all the transition
   mechanism.  Such a SAVI solution is heavy and costly for switches.
   The SAVI solution should introduce flexibility in rule generation
   similarly as Openv6, which offloading the complexity from network
   devices to a controller.

3.2.2.  Open Network Business Capabilities

3.2.2.1.  Dynamic QoS guarantee in IPv6 transition period

   Traditionally, almost all bandwidth on the Internet is shared, or
   with a pre-configured QoS class.  However, since the QoS requirements
   by different applications are not always the same, the subscribers
   should either waste money by paying for a higher bandwidth service,
   or can not get qualified service when needed.  Therefore, currently,
   operators are tending to provide more dynamic QoS guarantee for
   subscribers so that they may apply for a higher bandwidth on-demand
   when they needed, or specific QoS guarantee can be applied for a
   certain amount of applications.  In this case, the QoS adjustment
   platform is needed to pass the QoS adjustment request from
   subscribers or application servers dynamically.

   In IPv6 transition period, the situation will become more
   complicated.  When CGNs are introduced in the network, ip address and
   port will change during the translation or tunnelling process.  For



Sun, et al.              Expires August 17, 2014                [Page 6]


Internet-Draft          Openv6 Problem Statement           February 2014


   some solutions, e.g. NAT444, DS-Lite, etc., the mappings might be
   different for different sessions.

   In this case, the QoS adjustment platform should have the ability to
   pass and acquire QoS requirements for certain mappings in the CGNs.
   Therefore, more flexibility should be introduced in the network to
   load the dynamic QoS requests to the forwarding devices, no matter
   whether it is a tunnelling or translating mapping.

3.2.2.2.  Coordinated NAT translation

   Traditionally, most peer-to-peer applications would deploy relays by
   their own to achieve NAT traversal.  They may use different kinds of
   ways e.g. TURN, STUN, or use some private protocols for their own
   purpose.  It would not only cost a lot for applications deploy
   multiple relays, but also introduces a lot of complexity for newly
   emerging applications.  In addition, in IPv6 transition period, there
   would be more CGNs than before which might make it more difficult for
   applications to achieve NAT traversal.

   However, when operators have deployed some kinds of CGNs in their
   network, it is reasonable for operators to provide NAT traversal
   service for third-party applications so that the applications do not
   need to deploy the relays by their own.  For example, the third-party
   application may require the CGN with the transport address, reflect
   address, etc., and then choose the one to use for the specific NAT
   situation.  It can also be applied when IPv6 client communicates with
   iPv4 client with similar procedure.  In this case, a centralized
   controller is needed to acquire the requests from third-party
   applications and form the specific mappings for them.

3.3.  Existing evaluations of the IPv6 Transition Landscape

   This paragraph references work done at the IETF or to describe the
   complex landscape of transition technologies.

   The different network environments (architecture, scale, services
   deployed, varying IP traffic) cause a variety of IPv6 transition
   technologies for different operators.  This section analyses the
   current and future coexistence of IPv6 transition technologies
   situation as well as the issues behind it.

   Since IPv6 was proposed, there have been a couple of RFCs and on-
   going documents in IETF, as listed in the table below.







Sun, et al.              Expires August 17, 2014                [Page 7]


Internet-Draft          Openv6 Problem Statement           February 2014


   +--------+---------+------------------------------------------------+
   | status |  number |                   documents                    |
   +--------+---------+------------------------------------------------+
   |  RFC   |   8 or  |  [RFC5571], [RFC6333], [RFC6674], [RFC5969],   |
   |        |   more  |  [RFC6219], [RFC6535], [RFC6654], [RFC6145],   |
   |        |         |                      ...                       |
   |   WG   |   6 or  |            [I-D.ietf-softwire-4rd],            |
   | draft  |   more  |            [I-D.ietf-softwire-map],            |
   |        |         |           [I-D.ietf-softwire-map-t],           |
   |        |         |       [I-D.ietf-softwire-public-4over6],       |
   |        |         |         [I-D.ietf-softwire-lw4over6],          |
   |        |         |         [I-D.ietf-v6ops-464xlat], ...          |
   | Active | several |                      ...                       |
   | draft  |         |                                                |
   +--------+---------+------------------------------------------------+

          Table 1: A Table of IPv6 Transition Technologies @ IETF

   The situation described above depicts the difficulty of selecting
   appropriate IPv6 transition technologies for the carriers.  Moreover,
   according to [SD-NAT], there are multiple stages during the whole
   IPv6 transition period, and a variety of technologies and equipments
   are used during different IPv6 transition stages.  To protect the
   user experience and the early investment, an operator will not
   upgrade its network directly to the final stage of IPv6 transition.
   During different IPv6 transition stages, an operator needs different
   technologies in different stages.  Thus, a method that is able to
   implement different IPv6 transition technologies in the same hardware
   is crucial, to avoid repeated investments.

4.  Alternative Approach to IPv6 applications enablement

   Finally an IP Network is simply an interconnection of various IPv4-
   and IPv6-aware devices over some transport.  From a payload point of
   view, there is no need to wonder how the packet got to the
   destination (security aspects are reserved).  Removing the complexity
   of the transport from the IP-aware devices, by simply considering it
   as a hop-by-hop "encapsulation" would simplify some situations and
   bring more flexibility for new applications.

   The alternative approach proposed here is to put the IPv6 forwarding
   rules into the devices by a dynamic configuration protocol like
   Netconf, depending on the application requirements.  Those forwarding
   rules could for example require a change of encapsulation (e.g. from
   IPv6oEthernet to IPv6oIPv4oEthernet), or an IP protocol change (e.g.
   apply a NAT64 translation).  A central management server would be
   able to coordinate this configuration and push it adequately on the
   forwarding devices.



Sun, et al.              Expires August 17, 2014                [Page 8]


Internet-Draft          Openv6 Problem Statement           February 2014


   Today, the configuration of these encapsulation or translations is
   done manually and is not controlled in a coordinated and standard
   way.  The goal of the application-based approach is to allow the
   operator to have both the flexibility and full control on what
   technologies have to be used and when to help with its IPv6
   transition process.

5.  Existing protocols and methods for the alternate approach

   The proposed approach would have impact on layer 3, and maybe 4.
   Hence there is no need to change anything to Layer 1-2 protocols and
   techniques.

   Higher layer applications are not impacted either as the network
   forwarding is transparent to them.

   The proposed approach requires a dynamic configuration protocol for
   network devices, to update the forwarding table accordingly.
   Protocols like Netconf (add ref) or Openflow (add ref) are already
   existing to achieve this goal.  Thanks to their openness, they can
   easily be extended to support it.

6.  Missing protocols and methods for the alternate approach

   The authors have identified some missing pieces to be able to use the
   technology in a fully standard way.

6.1.  Dynamic devices forwarding table configuration

   The IETF standard for devices configuration is [RFC6241], the NETCONF
   Protocol.  So it may be suitable for the forwarding table
   configuration of the openv6 devices and the address management in
   [section 6.2], with some modifications of the code.  However, Netconf
   is not able to support the packet report from the device to the
   controller/applications, which may need extensions of the protocol.

6.2.  Address Management

   Having a centralized way to manage addresses requires an efficient
   protocol to request and allocate them.  Among the possible solutions,
   Netconf or Radius could be extended.

7.  Security Considerations








Sun, et al.              Expires August 17, 2014                [Page 9]


Internet-Draft          Openv6 Problem Statement           February 2014


7.1.  Source Address Validation and Traceback with Openv6

   A easy-to-use solution for Source Address Validation would increase
   the safety of networks.  If operators have an efficient and low cost
   unified solution for this problem for both IPv4 and IPv6 and the
   transition itself, they would be more incline to implement it and
   therefore the security of networks as a whole would improve.

8.  IANA Considerations

   This document has no actions for IANA.

9.  Authors

   Credits and Thanks

10.  Acknowledgements

   Reference previous work.

11.  References

11.1.  Normative References

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

11.2.  Informative References

   [I-D.ietf-softwire-4rd]
              Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and
              M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless
              Solution (4rd)", draft-ietf-softwire-4rd-07 (work in
              progress), October 2013.

   [I-D.ietf-softwire-lw4over6]
              Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
              I. Farrer, "Lightweight 4over6: An Extension to the DS-
              Lite Architecture", draft-ietf-softwire-lw4over6-06 (work
              in progress), February 2014.

   [I-D.ietf-softwire-map-t]
              Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and
              T. Murakami, "Mapping of Address and Port using
              Translation (MAP-T)", draft-ietf-softwire-map-t-05 (work
              in progress), February 2014.





Sun, et al.              Expires August 17, 2014               [Page 10]


Internet-Draft          Openv6 Problem Statement           February 2014


   [I-D.ietf-softwire-map]
              Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
              Murakami, T., and T. Taylor, "Mapping of Address and Port
              with Encapsulation (MAP)", draft-ietf-softwire-map-10
              (work in progress), January 2014.

   [I-D.ietf-softwire-public-4over6]
              Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public
              IPv4 over IPv6 Access Network", draft-ietf-softwire-
              public-4over6-10 (work in progress), July 2013.

   [I-D.ietf-v6ops-464xlat]
              Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation", draft-
              ietf-v6ops-464xlat-10 (work in progress), February 2013.

   [One-vision-for-IPv6]
              Mark Townsley, "One vision for IPv6", .

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





Sun, et al.              Expires August 17, 2014               [Page 11]


Internet-Draft          Openv6 Problem Statement           February 2014


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

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

   [RFC7039]  Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,
              "Source Address Validation Improvement (SAVI) Framework",
              RFC 7039, October 2013.

   [SD-NAT]   Alain Durand, "SD-NAT",
              <http://www.ietf.org/proceedings/82/slides/behave-10.pdf>.

Authors' Addresses

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

   Email: sunqiong@ctbri.com.cn


   Will(Shucheng) Liu
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: liushucheng@huawei.com


   Cathy Zhou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: cathy.zhou@huawei.com









Sun, et al.              Expires August 17, 2014               [Page 12]


Internet-Draft          Openv6 Problem Statement           February 2014


   Guillaume Leclanche
   Viagenie
   246 Aberdeen
   Quebec, QC  G1R 2E1
   Canada

   Phone: +1 418 656 9254
   Email: guillaume.leclanche@viagenie.ca











































Sun, et al.              Expires August 17, 2014               [Page 13]