One document matched: draft-cui-intarea-unified-v6-framework-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited by Yuchi Chen, Tsinghua University -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc autobreaks="no"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-cui-intarea-unified-v6-framework-01" ipr="trust200902">
<front>
<title abbrev="Unified v6 Transition Framework">Unified IPv6 Transition Framework With Flow-based Forwarding</title>
<!-- Author List -->
<author fullname="Yong Cui" initials="Y." surname="Cui">
<organization>Tsinghua University</organization>
<address>
<postal>
<street/>
<city>Beijing</city>
<code>100084</code>
<country>P.R.China</country>
</postal>
<phone>+86-10-6260-3059</phone>
<email>yong@csnet1.cs.tsinghua.edu.cn</email>
</address>
</author>
<author fullname="Yuchi Chen" initials="Y." surname="Chen">
<organization>Tsinghua University</organization>
<address>
<postal>
<street/>
<city>Beijing</city>
<region></region>
<code>100084</code>
<country>P.R.China</country>
</postal>
<phone>+86-10-6278-5822</phone>
<email>chenycmx@gmail.com</email>
</address>
</author>
<date year="2014"/>
<abstract>
<t>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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119"></xref>.</t>
</note>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>Currently several translation and tunneling mechanisms have been proposed, such as NAT64 <xref target="RFC6146"></xref>, DS-Lite <xref target="RFC6333"></xref>, Lightweight 4over6 <xref target="I-D.ietf-softwire-lw4over6"></xref> and MAP-E <xref target="I-D.ietf-softwire-map"></xref>. 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.</t>
<t>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.</t>
</section>
<section anchor="Terminology" title="Terminology">
<t>This document uses the following terms:</t>
<t><list style="hanging" hangIndent="25">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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. </t>
<t hangText="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.</t>
</list></t>
</section>
<section anchor="Overview" title="Framework Overview">
<t>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.</t>
<figure>
<artwork><![CDATA[
+---------------+
______| Controller |______
| | | |
| +---------------+ |
| |
______________ v _______________ v ______________
| | +--------+ | | +--------+ | |
| Customer LAN |_| CPE |_| IPv6 ISP |_| BR |_| IPv4/ IPv6 |
|(dual-stack/ | | Switch | | Network | | Switch | | Internet |
| IPv6 network)| +--------+ | | +--------+ |______________|
|______________| |_______________|
]]></artwork>
<postamble> Figure 1 Architecture Overview </postamble>
</figure>
<t>CPE Switch performs the flow-based packet forwarding function. It MUST support the softwire encapsulation/ decapuslation function specified in <xref target="RFC6333"></xref>, <xref target="I-D.ietf-softwire-lw4over6"></xref> and <xref target="I-D.ietf-softwire-map"></xref>. It MUST also support traditional NAPT44 and NAT64 translator (<xref target="RFC6146"></xref>) function. </t>
<t>BR Switch also performs the flow-based packet forwarding function. It MUST support the softwire encapsulation/ decapuslation function specified in <xref target="RFC6333"></xref>, <xref target="I-D.ietf-softwire-lw4over6"></xref> and <xref target="I-D.ietf-softwire-map"></xref>. Particularly, it MUST support the port-set matching for incoming IPv4 packets, which is defined in section 6.2 of <xref target="I-D.ietf-softwire-lw4over6"></xref>. </t>
<t>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. </t>
<t>Controller communicates with Switch using protocols that is able to carry flow information and flow table configuration, such as NETCONF <xref target="RFC6241"></xref>, Openflow, etc.</t>
</section>
<section anchor="Control" title="Control Plane Behavior">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="Data" title="Data Plane Behavior">
<t>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.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
<t>Further security consideration is TBD.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document does not include an IANA request.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.6146" ?>
<?rfc include="reference.RFC.6241" ?>
<?rfc include="reference.RFC.6333" ?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-softwire-lw4over6" ?>
<?rfc include="reference.I-D.ietf-softwire-map" ?>
</references>
<section anchor="appendix" title="Examples">
<t>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.</t>
<figure title="Table 1 Auto Processing of Flows">
<artwork align="center"><![CDATA[
+--------+---------------+-----------------------+------------------+
| 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 |
+--------+---------------+-----------------------+------------------+
]]></artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:47:28 |