Internet DRAFT - draft-cui-softwire-unified-v6-framework
draft-cui-softwire-unified-v6-framework
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]
