Internet DRAFT - draft-liu-openv6-architecture

draft-liu-openv6-architecture







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


                Openv6 Architecture for IPv6 Deployment
                    draft-liu-openv6-architecture-01

Abstract

   IPv6 transition leads to costly end-to-end network upgrades and poses
   new challenges in terms of device management with a variety of
   transitional protocols.

   This document provides a cost-effective and flexible unified IPv6
   deployment by describing an architecture of a standard and
   programmatic manner for IPv6 deployment.

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 18, 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



Liu, et al.              Expires August 18, 2014                [Page 1]

Internet-Draft   Openv6 Architecture for IPv6 Deployment   February 2014


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation for OpenV6 Architecture  . . . . . . . . . . . . .   3
   4.  Overview of the OpenV6 Architecture . . . . . . . . . . . . .   4
   5.  OpenV6 Considerations . . . . . . . . . . . . . . . . . . . .   5
   6.  Manageability Considerations  . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     10.2.  Informative References . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The exhaustion of the IPv4 address space has been a practical problem
   that network carriers are facing today.  Existing solutions such as
   IPv4 re-addressing and address reusing fail to fundamentally solve
   this problem.  Instead, IPv6 is regarded as a complete and thorough
   solution to this problem.

   To date, the adoption of IPv6 is progressing slowly.
   [Google-IPv6-Statistics] shows the statistics of IPv6 adoption.  On
   one hand, IPv6 lacks support from applications.  As a result, end
   users are reluctant to transition to IPv6 due to lack of attractive
   applications and competitive prices on IPv6.  On the other hand, a
   large-scale IPv6 network as well as a stable and large IPv6 user
   group are the fundamental driving forces for evolving to IPv6.

   The key to the above deadlock is that network carriers should take
   the initiative in constructing and developing an IPv6-friendly
   infrastructure, thus providing IPv6-based service access capabilities
   and actively nurturing the IPv6 adoption.  The Openv6 and this
   document are focused on flexibly unifying the IPv6 transition
   mechanisms.  The Openv6 provides an IPv6-friendly infrastructure to
   let the users decide for themselves when and how to start the IPv6
   transition.




Liu, et al.              Expires August 18, 2014                [Page 2]

Internet-Draft   Openv6 Architecture for IPv6 Deployment   February 2014


2.  Terminology

3.  Motivation for OpenV6 Architecture

   Several motivations for the Openv6 are listed below.  This list is
   not meant to be exhaustive and is provided for the sake of
   illustration.

   It should be highlighted that the aim of this section is to provide
   some application examples for which the OpenV6 may be suitable: this
   also clearly states that such a model does not aim to replace
   existing IPv6 transition mechanisms but would apply to specific
   existing or future situations.

   The Openv6 does not replace the existing IPv6 transition mechanisms
   in the network.  Instead, it is compatible (or accommodate) existing
   and future IPv6 transition mechanisms.

   Not all networks, servers and users will upgrade to IPv6 at the same
   pace along IPv6 transition.  There will be many different scenarios,
   among which we can highlight the following ones:

      Some regions will stay as IPv4-only networks (whenever transition
      is too costly or there are compelling technical reasons for not
      upgrading), and some regions will start as IPv6-only networks.

      IPv6 end users accessing the IPv6 Internet via a service
      provider's IPv4 network infrastructure.

      IPv4 end users accessing the IPv4 Internet via a service
      provider's IPv6 network infrastructure.

      IPv6 end users accessing the IPv4 Internet.

   According to these (and many others) different scenarios, and to the
   current status of network infrastructure, a number of different IPv6
   transition technologies have been defined.  For any device it becomes
   extremely hard to support them all at the same time, so addressing
   all the potential situations can become extremely costly, both in
   terms of CAPEX and OPEX.

   The Openv6 provides an opportunity to build a unified approach to the
   different IPv6 transition technologies.  With unified devices on the
   forwarding plane, packets are processed according to flow tables, in
   a way completely oblivious to the transition technology particular
   aspects.





Liu, et al.              Expires August 18, 2014                [Page 3]

Internet-Draft   Openv6 Architecture for IPv6 Deployment   February 2014


4.  Overview of the OpenV6 Architecture

   This section gives an overview of the architecture of the Openv6.

   The figure in Figure 1 shows the basic architecture of Openv6.

                                  +------------------------+
                                  |       Applications     |
                                  |     (OSS,3rd-APPs,     |
                                  |     security service,  |
                                  |  v6 trans service,etc.)|
                                  |    +----------------+  |
                                  |    |  Openv6 Agent  |  |
                                  |    +----------------+  |
                                  +----------- ^ ----------+
                                               |
                                               |
                                               |
                                  +----------- v ----------+
                                  |   +---------------+    |
                                  |   |               |    |
                                  | +-----+       +-----+  |
                                  | |Agent|  ...  |Agent|  |
                       +-------+  | +-----+       +-----+  |
                       |       |  |   |               |    |
+----+  +-----------+  |       |  |   +---------------+    |
|Host|--|Unified    |--|       |  |            ^           |
+----+  |v6Trans CPE|  |       |  |            |           |  +--------+
        +-----------+  |       |  |            v           |  |        |
                       |IPv4/  |  |     +--------------+   |  |IPv4/   |
                       |IPv6   |--|     |              |   |--|IPv6    |
                       |Network|  |     |  Unified     |   |  |Internet|
+----+  +-----------+  |       |  |     |  Flow Table  |   |  |        |
|Host|--|Unified    |--|       |  |     |              |   |  +--------+
+----+  |v6Trans CPE|  |       |  |     +--------------+   |
        +-----------+  |       |  |                        |
                       |       |  |Unified Forwarding Node |
                       +-------+  +------------------------+

                     Figure 1: Architecture of OpenV6

   Unified Forwarding Node: A forwarding node that handles incoming
   packets basing on the flow table.  Examples of Forwarding Nodes can
   include:

   A router that has an extended function module.  The extended module
   handles incoming packets basing on the flow table of the module.




Liu, et al.              Expires August 18, 2014                [Page 4]

Internet-Draft   Openv6 Architecture for IPv6 Deployment   February 2014


   A server that runs vRouter or vSwitch.

   A CGN that runs NAT, Tunnel En/De-capsulation functions.

   A Forwarding Node may be locally managed, whether via CLI, SNMP, or
   NETCONF.

   Unified Flow Table: The flow table is used for handling incoming
   packets of the forwarding node.  The flow table can be updated by the
   application.  If an incoming packet does not match any entry of the
   flow table, the packet will be delivered to the agent for generating
   new entries.

   OpenV6 Agent: The OpenV6 agent interacts with the forwarding node to
   provide specified behavior for incoming packets via the flow table.

   Applications: A network application that needs to manipulate the
   network to achieve its service requirements.  Various IPv6 related
   services can be enabled by corresponding Applications such as:

      OSS: can be considered as an application;

      3rd-party APPs: IPv6 based 3rd-party applications;

      Network security service: security related services such as savi

      IPv6 transition service: transition mechanisms are are considered
      to be a variety of applications in OpenV6.  The application can
      communicate with multiple forwarding node.

   Agent: The agent interacts with the applications and the forwarding
   nodes.  It can be implemented in the forwarding node for policies
   driven provisioning.  There may be multiple agents in an forwarding
   node.  Each agent executes a specific policy(for example, one agent
   for App-Lw4over6, one agent for NAT64, etc.)

5.  OpenV6 Considerations

6.  Manageability Considerations

7.  Security Considerations

8.  IANA Considerations








Liu, et al.              Expires August 18, 2014                [Page 5]

Internet-Draft   Openv6 Architecture for IPv6 Deployment   February 2014


9.  Acknowledgements

   N/A.

10.  References

10.1.  Normative References

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

10.2.  Informative References

   [Google-IPv6-Statistics]
              Google, "Google IPv6 Statistics", <http://www.google.com/
              ipv6/statistics.html#tab=ipv6-adoption>.

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

   [RFC6888]  Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
              and H. Ashida, "Common Requirements for Carrier-Grade NATs
              (CGNs)", BCP 127, RFC 6888, April 2013.

Authors' Addresses

   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








Liu, et al.              Expires August 18, 2014                [Page 6]

Internet-Draft   Openv6 Architecture for IPv6 Deployment   February 2014


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

   Email: sunqiong@ctbri.com.cn


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

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


































Liu, et al.              Expires August 18, 2014                [Page 7]