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]