Unified IPv6 Transition Framework With Flow-based Forwarding
draft-cui-softwire-unified-v6-framework-00

Versions: 00                                                            
Network Working Group                                             Y. Cui
Internet-Draft                                                   Y. Chen
Intended status: Standards Track                     Tsinghua University
Expires: December 31, 2014                                 June 29, 2014


      Unified IPv6 Transition Framework With Flow-based Forwarding
               draft-cui-softwire-unified-v6-framework-00

Abstract

   This document describes a software defined networking (SDN) based
   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 transition
   mechanisms, such as MAP-E, Lightweight 4over6, etc.

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 December 31, 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



Cui & Chen              Expires December 31, 2014               [Page 1]


Internet-Draft       Unified v6 Transition Framework           June 2014


   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
     5.1.  Controller-based NAT44  . . . . . . . . . . . . . . . . .   5
     5.2.  Port-Set Based Packet Matching  . . . . . . . . . . . . .   6
   6.  Example: 4over6 Mode  . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Forwarding Rules  . . . . . . . . . . . . . . . . . . . .   7
     6.2.  Mesh Mode . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  NAT Consideration . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     10.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Currently several IPv6 transition mechanisms have been proposed, such
   as DS-Lite [RFC6333], MAP-E [I-D.ietf-softwire-map], and Lightweight
   4over6 [I-D.ietf-softwire-lw4over6].  These mechanisms have been or
   being implemented by the industry.  However, each of these transition
   mechanisms have some unique features in control or data plane
   behavior such as IP provisioning, so the mechanisms require different
   dedicated implementations on both CPE and BR side and it's
   complicated and a big cost to upgrade existing devices to support new
   mechanisms.

   This document describes a SDN-based IPv6 transition framework.  This
   framework adopts flow-based packet forwarding technology on
   transition devices, which can simplify the implementation of both
   control plane and data plane operations of transition mechanisms.  A
   centralized Controller is added into the network to control the
   forwarding rules of both CPE and BR, leaving other devices in ISP
   network between CPE and BR as traditional devices.  The forwarding



Cui & Chen              Expires December 31, 2014               [Page 2]


Internet-Draft       Unified v6 Transition Framework           June 2014


   rules of transition devices can be changed easily by changing network
   applications on the Controller, thus this framework can implement
   transition scenarios easily, e.g.  IPv4 over IPv6 hub and spoke model
   that Lightweight 4over6 does.  Both CPE and BR can be implemented by
   standardized SDN switches thus no dedicated devices are needed, so it
   can reduce the cost of deploying new mechanisms for customer
   networks.

2.  Terminology

   This document uses the following terms:

   Customer Premises Equipment Switch (CPE Switch):  A dual-stack L3
                            switch that performs the flow-based packet
                            forwarding function.  It implements the
                            OpenFlow protocol [OpenFlow] It can be the
                            home gateway or BNG.

   Border Relay Switch (BR Switch):  A dual-stack L3 switch that
                            performs the flow-based packet forwarding
                            function.  It implements the OpenFlow
                            protocol [OpenFlow] It is on the boarder of
                            the ISP network and IPv4/ IPv6 Internet.

   Controller:              A centralized manager that controls both CPE
                            Switch and BR Switch.  The Controller is
                            treated as a logical device that can be a
                            single or multiple physical devices.

   Flow-based Packet Forwarding:  A function that forwards packets
                            according to the forwarding rules specified
                            by a flow table.  A typical forwarding rule
                            includes a match field and a action set.
                            The match field specifies a certain flow,
                            which is a set of packets that share some
                            common features (e.g. same source and
                            destination address).  The action set
                            specifies the actions that should act on the
                            certain flow (e.g. forward a packet,
                            encapsulate or decapsulate a packet).

3.  Framework Overview

   The architecture of the proposed unified IPv6 transition framework is
   illustrated in Figure 1.  The customer LAN connects the IPv6 ISP
   network through CPE Switch.  The ISP Network accesses the Internet
   through BR Switch.  Devices in the ISP Network are not required to be
   managed by the Controller, thus the operator only needs to upgrade



Cui & Chen              Expires December 31, 2014               [Page 3]


Internet-Draft       Unified v6 Transition Framework           June 2014


   the CPEs and BRs.

                            +---------------+
                      ______|  Controller   |______
                     |      |               |      |
                     |      +---------------+      |
                     |                             |
 ______________      v       _______________       v      ______________
|              | +--------+ |               | +--------+ |              |
| Customer LAN |_|  CPE   |_|    ISP IPv6   |_|   BR   |_|    IPv4      |
|              | | Switch | |    Network    | | Switch | |   Internet   |
|______________| +--------+ |_______________| +--------+ |______________|



                      Figure 1 Architecture Overview

   Both CPE Switch and BR Switch perform flow-based forwarding, and are
   managed by the Controller.  Since CPE Switch can work as the gateway
   of customer network, it also needs to support traditional CPE
   functions, such as be compatible with [RFC7084].

   Controller is responsible for controlling the forwarding behavior of
   both CPE Switch and BR Switch.  Controller can be an individual or a
   cluster of physical devices.  The Controller configures the
   forwarding rules in the flow tables maintained by the CPE Switch and
   BR Switch according to the packets passed from Switches.  There can
   also be separate physical controllers at CPE side and BR side, but
   both controllers needs to share their network state so they can work
   as a single logical controller.  The state sharing method is out of
   the scope of this document.

   Controller communicates with Switch using protocols that is able to
   carry flow information and flow table configuration.  Currently we
   suggest and choose Openflow [OpenFlow] as the best approach, however
   some changes are proposed to support IPv6 tunneling and port set
   based forwarding.

4.  Control Plane Behavior

   The Controller configures both CPE Switch and BR Switch through flow
   configuration.  The switches are configured or pre-installed with
   default forwarding policy that forwards all unknown flows to the
   controller.  The controller then installs forwarding rules for the
   specific flow into the switch.  All remaining packets of the same
   flow are processed based on this rule and will not be forwarded to
   the Controller.  The definition of a flow depends on the forwarding
   policy.  For example, in MAP-E or Lightweight 4over6 scenario, the BR



Cui & Chen              Expires December 31, 2014               [Page 4]


Internet-Draft       Unified v6 Transition Framework           June 2014


   Switch treats all traffic from the same CPE as a single flow.

   Some transition mechanisms require provisioning parameters to CPE.
   For example, DS-Lite, MAP-E and Lightweight 4over6 use DHCPv6 to
   provision IPv6 address of AFTR/BR to CPE.  Lightweight 4over6 and
   MAP-E provision IPv4 address and port set to CPE.  Since these
   parameters can be represented by flow forwarding rules, in this
   framework such DHCPv6 based softwire provisioning is not required.
   Instead these softwire configuration are embedded into forwarding
   rules and provisioned to CPE Switch through flow configuration, e.g.
   the IPv4 address of the CPE can be represented as the value of set-
   field actions.

   The connection between the switches and the controller SHOULD be
   through IPv6.  In order to build the IPv6 based connection, the
   switches MUST be configured with an IPv6 address and the IPv6 address
   of the Controller.  Since the CPE side requires automatic
   configuration, DHCPv6 is RECOMMENDED for the CPE Switch to get its
   IPv6 address or prefix, and the controller address.

5.  Data Plane Behavior

   When received an incoming packet which is the initial packet of an
   unknown flow, CPE Switch and BR Switch MUST pass the packet to
   Controller to ask for the forwarding rule.  Controller determines how
   to proceed the flow, and interpret the process into a set of
   forwarding rule configurations.  Controller then installs these
   configurations to CPE Switch and/or BR Switch.  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.

   Both CPE Switch and BR Switch MUST support the IPv6 tunneling
   encapsulation/decapuslation function required in [RFC6333],
   [I-D.ietf-softwire-lw4over6] and [I-D.ietf-softwire-map] as actions
   to the incoming IPv4 packets.  IPv4-in-IPv6 tunneling SHOULD be
   implemented by Switches.  When it is not supported, other tunneling
   format such as GRE tunnel can be used.  The encapsulation action is
   specified with two parameters: source and destination IPv6 address.

5.1.  Controller-based NAT44

   In MAP-E/Lightweight 4over6 CPE, NAT44 is required.  In this
   framework, NAT44 can be simply supported by flow-based forwarding
   rules.  Since protocol header modification is supported by Switches
   (i.e. set-field action in OpenFlow), NAT44 can be implemented as
   modification of source/destination IPv4 addresses and port fields.
   As an example, for the upstreaming traffic on CPE Switch, the Switch



Cui & Chen              Expires December 31, 2014               [Page 5]


Internet-Draft       Unified v6 Transition Framework           June 2014


   asks for the forwarding rule of each flow identified by (source IPv4
   address, source port), and the Controller allocates an address and a
   port for each flow and orders the Switch to rewrite the source IPv4
   address and port of the upstreaming flow, and the destination IPv4
   address and port of the corresponding downstreaming flow.  The NAT44
   state is maintained by the Controller.

5.2.  Port-Set Based Packet Matching

   Since MAP-E/Lightweight 4over6 requires port-based IPv4 address
   sharing, there may be thousands of ports of the same IPv4 address
   allocated to the same CPE.  To reduce the amount of forwarding rules
   in BR Switch, when BR Switch matching an incoming packet, it SHOULD
   support the port-set based matching as defined in in Section 5.1 of
   [I-D.ietf-softwire-map].  The BR Switch SHOULD support and accept
   match field masking for ports (see section 7.2.2.5 of [OpenFlow]).
   For the PSID usage, the PSID bits (k bits) in the port mask are
   filled with "1"s, and the remaining bits (a+m bits) are filled with
   "0"s.

6.  Example: 4over6 Mode

   This section describes an example of running IPv4 over IPv6 tunneling
   mode in this framework.  The network behavior is similar to
   Lightweight 4over6, however the DHCPv6-based IPv4 address and PSID
   provisioning for lwB4 is not needed.  In this mode, The Customer LAN
   is an IPv4 or dual-stack network, and the ISP Network is an IPv6
   network.  Initially the CPE Switch is configured with IPv6 prefix
   through DHCPv6 Prefix Delegation and connects to the Controller
   through OpenFLow.  Then the CPE Switch is ordered to pass all unknown
   packets to the Controller.

   The Controller manages the binding between IPv4 addresses and IPv6
   addresses.  When a new CPE Switch connects to the Controller, the
   Controller allocates an IPv4 address and a port set for the CPE
   Switch, and installs per-subscriber scale forwarding rule(s) in BR
   Switch.  To work as MAP-E mode, the IPv4 address and port set are
   calculated from the CPE's IPv6 prefix.  To work as Lightweight 4over6
   mode, the IPv4 address and port set are allocated dynamically.

   In case that CPE's NAT44 state is maintained in Controller, when
   received an unknown packet from CPE Switch, the Controller picks one
   port from the port set of the CPE Switch and installs the forwarding
   rule in the CPE Switch, to rewrite the source IPv4 address and port
   into public ones on the flow.  Both forwarding rules in CPE Switch
   and BR Switch include IPv4-in-IPv6 tunnel encapsulation/decapuslation
   action, taking the IPv6 address of the opposite as an parameter.




Cui & Chen              Expires December 31, 2014               [Page 6]


Internet-Draft       Unified v6 Transition Framework           June 2014


6.1.  Forwarding Rules

   A CPE Switch is configured with following rules:

      Decapsulation rule: For all IPv6 traffic from ISP network with the
      protocol type 4, pop the IPv6 tunnel header.

      NAT rule: For each flow received from LAN network and identified
      by (source IPv4 address, source port): rewrite source IPv4 address
      and source port to public values specified by Controller; also
      rewrite destination IPv4 address and port of the corresponding
      opposite flow.

      Encapsulation rule: For all IPv4 traffic from LAN network: push a
      IPv6 tunnel header (protocol type 4), of which the source and
      destination address are specified by the Controller.  The tunnel
      source address is one of the CPE Switch's addresses chosen by the
      Controller.  The tunnel destination address is the BR Switch's
      address.

   A BR Switch is configured with following rules:

      Decapsulation rule: For all IPv6 traffic from ISP network with the
      protocol type 4, pop the IPv6 tunnel header and forward to
      Internet.

      Encapsulation rule: For each flow received from Internet side and
      identified by (destination IPv4 address, destination port set):
      push a IPv6 tunnel header (protocol type 4), of which the source
      and destination address are specified by the Controller.  The
      tunnel source address is the BR Switch's address.  The tunnel
      destination address is one of the CPE Switch's address, which MUST
      be the same address used in CPE Switch's forwarding rule.  By
      masking a port set mask when doing port matching, one matching
      rule can match a set of ports.

6.2.  Mesh Mode

   This framework can support mesh mode for Lightweight 4over6.  In mesh
   mode, if the (destination IPv4 address, destination port) of a LAN
   side incoming flow on a CPE Switch (CPE1) belongs to another CPE
   Switch (CPE2), the tunnel destination address of the encapsulation
   action for this flow is set to CPE2's IPv6 address directly.  The
   priority of mesh mode encapsulation rule is higher than default
   encapsulation rule.






Cui & Chen              Expires December 31, 2014               [Page 7]


Internet-Draft       Unified v6 Transition Framework           June 2014


7.  NAT Consideration

   Section 5.1 describes how Controller-based NAT44 works.  In some
   cases that only NAT44 but no other applications are performed for
   TCP/UDP flows, passing the initial packet of each flow to Controller
   may be inefficient.  In this case, the framework proposed in this
   document allows the switches to have a dedicated NAT module that
   handles NAT44 states and rewrites packets.  The NAT module works as a
   virtual interface to the switch, and the switch perform NAT44 action
   to packets by forwarding packets to the NAT interface.  The NAT44
   module needs to be configured with the public IPv4 address and/or
   port set.  In case a switch has a dedicated NAT44 module, the
   Controller may still want to handle the forwarding rules of part of
   the flows, to provide better quality for some services.

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

   Further security consideration is TBD.

9.  IANA Considerations

   This document does not include an IANA request.

10.  References

10.1.  Normative 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-10 (work
              in progress), June 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.




Cui & Chen              Expires December 31, 2014               [Page 8]


Internet-Draft       Unified v6 Transition Framework           June 2014


   [OpenFlow]
              Open Networking Foundation, "OpenFlow Switch Specification
              1.4.0",
              <https://www.opennetworking.org/images/stories/downloads/
              sdn-resources/onf-specifications/openflow/openflow-spec-
              v1.4.0.pdf>.

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

10.2.  Informative References

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

   [RFC7084]  Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
              Requirements for IPv6 Customer Edge Routers", RFC 7084,
              November 2013.

Authors' Addresses

   Yong Cui
   Tsinghua University
   Beijing  100084
   P.R.China

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


   Yuchi Chen
   Tsinghua University
   Beijing  100084
   P.R.China

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













Cui & Chen              Expires December 31, 2014               [Page 9]