Internet DRAFT - draft-cui-intarea-unified-v6-framework

draft-cui-intarea-unified-v6-framework







Network Working Group                                             Y. Cui
Internet-Draft                                                   Y. Chen
Intended status: Standards Track                     Tsinghua University
Expires: September 5, 2014                                 March 4, 2014


      Unified IPv6 Transition Framework With Flow-based Forwarding
               draft-cui-intarea-unified-v6-framework-01

Abstract

   This document describes a unified IPv6 transition framework.  This
   framework makes use of the flow-based packet forwarding technology,
   which can simplify the implementation of both control plane and data
   plane operations of transition mechanisms.  The purpose of this work
   is to provide an integrated and flexible framework to implement and
   deploy the most popular translation and tunneling mechanisms, such as
   NAT64, DS-Lite, Lightweight 4over6 and MAP-E. This framework can
   benefit the industry by reducing the cost of implementation,
   providing flexibility for deployment, and enabling transition
   mechanisms to coexist and cooperate in the common infrastructure.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

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 September 5, 2014.







Cui & Chen              Expires September 5, 2014               [Page 1]

Internet-Draft       Unified v6 Transition Framework          March 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
   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.  Framework Overview  . . . . . . . . . . . . . . . . . . . . .   3
   4.  Control Plane Behavior  . . . . . . . . . . . . . . . . . . .   4
   5.  Data Plane Behavior . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Currently several translation and tunneling mechanisms have been
   proposed, such as NAT64 [RFC6146], DS-Lite [RFC6333], Lightweight
   4over6 [I-D.ietf-softwire-lw4over6] and MAP-E
   [I-D.ietf-softwire-map].  These mechanisms have been or being
   implemented by the industry.  Nowadays Internet Service Providers
   (ISPs) usually should deploy multiple parallel mechanisms in order to
   fulfill transition requirements.  However, the concurrent deployment
   and management of several mechanisms are not cost-effective.  In
   addition, the suitable transition mechanisms may change along the
   ISP's transition period.  It's complicated to replace the previous
   implementations with the new devices.

   This document describes a unified IPv6 transition framework.  This
   framework adopts a kind of flow-based packet forwarding technology,
   which can simplify the implementation of both control plane and data
   plane operations of transition mechanisms.  The purpose of this work



Cui & Chen              Expires September 5, 2014               [Page 2]

Internet-Draft       Unified v6 Transition Framework          March 2014


   is to provide an integrated framework to implement the most popular
   transition mechanisms like NAT64, DS-Lite, Lightweight 4over6 and
   MAP-E. This framework can benefit the industry by reducing the cost
   of implementing and deploying transition mechanisms, and enable these
   mechanisms to coexist in the common infrastructure.

2.  Terminology

   This document uses the following terms:

   Customer Premises Equipment Switch (CPE Switch):  The dual-stack L3
                            swtich that performs the flow-based packet
                            forwarding function.  It is the local
                            gateway of the customer LAN, and connects to
                            the IPv6 ISP network.

   Border Relay Switch (BR Switch):  The dual-stack L3 switch that
                            performs the flow-based packet forwarding
                            function.  It is the entry of the IPv6 ISP
                            network to the IPv4/ IPv6 Internet.

   Controller:              The centrallized manager that controls both
                            CPE Switch and BR Switch.  Controller can be
                            a single device or a cluster of devices.  It
                            can connect to the CPE Switch and BR Switch
                            through specific links.

   Flow-based Packet Forwarding:  A function that forwards packets
                            according to the forwarding rules specified
                            by a flow table.  Each of these rules
                            includes a match field and a action set.
                            The match field specifies a certain flow.
                            This flow is a set of packets that share
                            some common features (e.g. same source and
                            destionation address).  The action set
                            specifies the actions that should act on the
                            certain flow.

3.  Framework Overview

   The architecture of the proposed unified IPv6 transition framework is
   illustrated in Figure 1.  The customer LAN is a dual-stack/ IPv6
   network, in which there could be arbitrary customer end devices.  A
   DHCP server could be deployed in this network, in order to provision
   private IPv4 addresses to the end devices.  The customer LAN connects
   the IPv6 ISP network through CPE Switch.  The IPv6 ISP Network is the
   access network, and it accesses the IPv4/IPv6 Internet through BR
   Switch.



Cui & Chen              Expires September 5, 2014               [Page 3]

Internet-Draft       Unified v6 Transition Framework          March 2014


                            +---------------+
                      ______|  Controller   |______
                     |      |               |      |
                     |      +---------------+      |
                     |                             |
 ______________      v       _______________       v      ______________
|              | +--------+ |               | +--------+ |              |
| Customer LAN |_|  CPE   |_|    IPv6 ISP   |_|   BR   |_|  IPv4/ IPv6  |
|(dual-stack/  | | Switch | |    Network    | | Switch | |   Internet   |
| IPv6 network)| +--------+ |               | +--------+ |______________|
|______________|            |_______________|


   Figure 1 Architecture Overview

   CPE Switch performs the flow-based packet forwarding function.  It
   MUST support the softwire encapsulation/ decapuslation function
   specified in [RFC6333], [I-D.ietf-softwire-lw4over6] and
   [I-D.ietf-softwire-map].  It MUST also support traditional NAPT44 and
   NAT64 translator ([RFC6146]) function.

   BR Switch also performs the flow-based packet forwarding function.
   It MUST support the softwire encapsulation/ decapuslation function
   specified in [RFC6333], [I-D.ietf-softwire-lw4over6] and
   [I-D.ietf-softwire-map].  Particularly, it MUST support the port-set
   matching for incoming IPv4 packets, which is defined in section 6.2
   of [I-D.ietf-softwire-lw4over6].

   Controller is responsible for controlling the performance of both CPE
   Switch and BR Switch.  Controller can be an individual device or a
   cluster of devices.  In case of being a cluster, Controller can be
   implemented by mulitiple physic or virtual machines, and each machine
   connects to a Switch.  It must configure the forwarding rules in the
   flow tables maintained by the CPE Switch and BR Switch.  It maintains
   the NAPT44 state and NAT64 state that is associated with the CPE
   Switch.  It also maintains the NAPT44 state, MAP mapping rules, and
   Lightweight 4over6 binding table state that are associated with the
   BR Switch.

   Controller communicates with Switch using protocols that is able to
   carry flow information and flow table configuration, such as NETCONF
   [RFC6241], Openflow, etc.

4.  Control Plane Behavior

   At least one softwire mechanism (e.g. DS-Lite , Lightweight 4over6 or
   MAP-E) should be deployed in the system.  Multiple softwire
   mechanisms can be deployed at the same time.  This situation includes



Cui & Chen              Expires September 5, 2014               [Page 4]

Internet-Draft       Unified v6 Transition Framework          March 2014


   two cases: (1) mechanisms are implemented in different devices (e.g.
   DS-Lite B4 and Lightweight 4over6 LwB4 are implemented in different
   CPE Switches); (2) mechanisms are activated in the same devices (e.g.
   both DS-Lite B4 and LwB4 are activated in the same CPE Switch).  In
   the first case, Controller can distinguish the CPE Switches or BR
   Switches by their addresses; in the second case, CPE Switch and BR
   Switch can apply actions of different mechanisms to different flows
   according to the flow table.

   The end devices in the customer LAN can be provisioned with private
   IPv4 addresses by a local DHCP server.  They can also be provisioned
   with at least one global IPv6 address.

   CPE Switch and BR Switch MUST be provisioned with at least one IPv6
   address in the IPv6 ISP network.  They MUST be configured with
   default forwarding rules by Controller.  These default rules should
   cover actions such as forward-to-controller action and default
   encapsulation/ decapsulation action.  Note that configuring default
   encapsulation/ decapsulation rules can be regarded as establishing a
   tunnel between CPE Switch and BR Switch if Lightweight 4over6 or
   MAP-E is deployed in the network.

5.  Data Plane Behavior

   When receiving an incoming packet that doesn't have a match in the
   flow table (usually the intial packet of a new flow), CPE Switch and
   BR Switch MUST forward the packet to Controller.  Controller MUST
   determine how to proceed the flow (e.g. whether to apply NAT/ NAT64
   translation and/ or softwire encapsluaton/ decapuslutaion), and
   interpret the process into a set of forwarding rule configurations.
   Controller then passes these configurations to CPE Swtich and BR
   Switch.  CPE Switch and BR Switch then configure their flow table
   according to these configurations, continue to apply the
   corresponding actions to the packet, and forward it to the next step.
   When receiving the subsequent packets of the flow, CPE Switch and BR
   Switch will apply the same actions to them, according to the
   forwarding rules in the flow table.

6.  Security Considerations

   As Switch should always send unknown flows to Controller, the link
   between Switch and Controller might be vulnerable to a typical DoS
   attack, which is done by flooding new sessions and can exhaust all
   available resources of Switch and/or Controller.  Some monitoring or
   filtering approaches should be used to prevent against such an
   attack.  In addition, Controller can implement a policy that
   restricts the resource allocated to a Switch, or restricts the
   resource of Switch allocated to a flow.



Cui & Chen              Expires September 5, 2014               [Page 5]

Internet-Draft       Unified v6 Transition Framework          March 2014


   Further security consideration is TBD.

7.  IANA Considerations

   This document does not include an IANA request.

8.  References

8.1.  Normative References

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

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011.

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

8.2.  Informative References

   [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-07 (work
              in progress), 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.

Appendix A.  Examples

   Both CPE Switch and BR Switch can perform mulitiple mechanism
   functions at the same time.  When receving a flow that has a match in
   the flow table, they should determine how to proceed this packet
   according to the corresponding matched actions in the flow table.
   Table 1 shows an example about how can CPE Switch or BR Switch choose
   the right action automatically.




Cui & Chen              Expires September 5, 2014               [Page 6]

Internet-Draft       Unified v6 Transition Framework          March 2014


   +--------+---------------+-----------------------+------------------+
   | Switch |   Flow type   |    Matched actions    |    Processing    |
   +--------+---------------+-----------------------+------------------+
   |        |               |     Encapsulation     |  encapsulate v6  |
   |        |               |                       |      header      |
   |        | Outbound IPv4 | --------------------- | ---------------- |
   |        |               |                       |     NAT44 ->     |
   |        |               | NAT44 + Encapsulation |  encapsulate v6  |
   |        |               |                       |      header      |
   |        | ------------- | --------------------- | ---------------- |
   |        | Outbound IPv6 |                       |     NAT64 ->     |
   |        |               | NAT64 + Encapsulation |  encapsulate v6  |
   |        |               |                       |      header      |
   |  CPE   | ------------- | --------------------- | ---------------- |
   |        |               |     Decapsulation     |  decapsulate v6  |
   |        |               |                       |      header      |
   |        |               | --------------------- | ---------------- |
   |        |  Inbound IPv6 | NAT44 + Decapsulation |  decapsulate v6  |
   |        |               |                       | header -> NAT44  |
   |        |               | --------------------- | ---------------- |
   |        |               | NAT64 + Decapsulation |  decapsulate v6  |
   |        |               |                       | header -> NAT64  |
   | ------ | ------------- | --------------------- | ---------------- |
   |        |               | NAT44 + Decapsulation |  decapsulate v6  |
   |        |               |                       | header -> NAT44  |
   |        | Outbound IPv6 | --------------------- | ---------------- |
   |        |               |     Decapsulation     |  decapsulate v6  |
   |        |               |                       |      header      |
   |   BR   | ------------- | --------------------- | ---------------- |
   |        |               |                       |     NAT44 ->     |
   |        |               | NAT44 + Encapsulation |  encapsulate v6  |
   |        |               |                       |      header      |
   |        |  Inbound IPv4 | --------------------- | ---------------- |
   |        |               |     Encapsulation     |  encapsulate v6  |
   |        |               |                       |      header      |
   +--------+---------------+-----------------------+------------------+

                     Table 1 Auto Processing of Flows

Authors' Addresses

   Yong Cui
   Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6260-3059
   Email: yong@csnet1.cs.tsinghua.edu.cn



Cui & Chen              Expires September 5, 2014               [Page 7]

Internet-Draft       Unified v6 Transition Framework          March 2014


   Yuchi Chen
   Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6278-5822
   Email: chenycmx@gmail.com












































Cui & Chen              Expires September 5, 2014               [Page 8]