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", . [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]