| Network Working Group | Y. Cui |
| Internet-Draft | Y. Chen |
| Intended status: Standards Track | Tsinghua University |
| Expires: September 05, 2014 | March 04, 2014 |
Unified IPv6 Transition Framework With Flow-based Forwarding
draft-cui-intarea-unified-v6-framework-01
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.
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].
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 05, 2014.
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.
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 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.
This document uses the following terms:
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.
+---------------+
______| 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.
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 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.
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.
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.
This document does not include an IANA request.
| [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. |
| [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", Internet-Draft draft-ietf-softwire-lw4over6-07, 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)", Internet-Draft draft-ietf-softwire-map-10, January 2014. |
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.
+--------+---------------+-----------------------+------------------+
| 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