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]
