idnits 2.17.1 draft-cui-intarea-unified-v6-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2014) is 3696 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-07 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-10 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Cui 3 Internet-Draft Y. Chen 4 Intended status: Standards Track Tsinghua University 5 Expires: September 5, 2014 March 4, 2014 7 Unified IPv6 Transition Framework With Flow-based Forwarding 8 draft-cui-intarea-unified-v6-framework-01 10 Abstract 12 This document describes a unified IPv6 transition framework. This 13 framework makes use of the flow-based packet forwarding technology, 14 which can simplify the implementation of both control plane and data 15 plane operations of transition mechanisms. The purpose of this work 16 is to provide an integrated and flexible framework to implement and 17 deploy the most popular translation and tunneling mechanisms, such as 18 NAT64, DS-Lite, Lightweight 4over6 and MAP-E. This framework can 19 benefit the industry by reducing the cost of implementation, 20 providing flexibility for deployment, and enabling transition 21 mechanisms to coexist and cooperate in the common infrastructure. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 5, 2014. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Framework Overview . . . . . . . . . . . . . . . . . . . . . 3 66 4. Control Plane Behavior . . . . . . . . . . . . . . . . . . . 4 67 5. Data Plane Behavior . . . . . . . . . . . . . . . . . . . . . 5 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 8.2. Informative References . . . . . . . . . . . . . . . . . 6 73 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 Currently several translation and tunneling mechanisms have been 79 proposed, such as NAT64 [RFC6146], DS-Lite [RFC6333], Lightweight 80 4over6 [I-D.ietf-softwire-lw4over6] and MAP-E 81 [I-D.ietf-softwire-map]. These mechanisms have been or being 82 implemented by the industry. Nowadays Internet Service Providers 83 (ISPs) usually should deploy multiple parallel mechanisms in order to 84 fulfill transition requirements. However, the concurrent deployment 85 and management of several mechanisms are not cost-effective. In 86 addition, the suitable transition mechanisms may change along the 87 ISP's transition period. It's complicated to replace the previous 88 implementations with the new devices. 90 This document describes a unified IPv6 transition framework. This 91 framework adopts a kind of flow-based packet forwarding technology, 92 which can simplify the implementation of both control plane and data 93 plane operations of transition mechanisms. The purpose of this work 94 is to provide an integrated framework to implement the most popular 95 transition mechanisms like NAT64, DS-Lite, Lightweight 4over6 and 96 MAP-E. This framework can benefit the industry by reducing the cost 97 of implementing and deploying transition mechanisms, and enable these 98 mechanisms to coexist in the common infrastructure. 100 2. Terminology 102 This document uses the following terms: 104 Customer Premises Equipment Switch (CPE Switch): The dual-stack L3 105 swtich that performs the flow-based packet 106 forwarding function. It is the local 107 gateway of the customer LAN, and connects to 108 the IPv6 ISP network. 110 Border Relay Switch (BR Switch): The dual-stack L3 switch that 111 performs the flow-based packet forwarding 112 function. It is the entry of the IPv6 ISP 113 network to the IPv4/ IPv6 Internet. 115 Controller: The centrallized manager that controls both 116 CPE Switch and BR Switch. Controller can be 117 a single device or a cluster of devices. It 118 can connect to the CPE Switch and BR Switch 119 through specific links. 121 Flow-based Packet Forwarding: A function that forwards packets 122 according to the forwarding rules specified 123 by a flow table. Each of these rules 124 includes a match field and a action set. 125 The match field specifies a certain flow. 126 This flow is a set of packets that share 127 some common features (e.g. same source and 128 destionation address). The action set 129 specifies the actions that should act on the 130 certain flow. 132 3. Framework Overview 134 The architecture of the proposed unified IPv6 transition framework is 135 illustrated in Figure 1. The customer LAN is a dual-stack/ IPv6 136 network, in which there could be arbitrary customer end devices. A 137 DHCP server could be deployed in this network, in order to provision 138 private IPv4 addresses to the end devices. The customer LAN connects 139 the IPv6 ISP network through CPE Switch. The IPv6 ISP Network is the 140 access network, and it accesses the IPv4/IPv6 Internet through BR 141 Switch. 143 +---------------+ 144 ______| Controller |______ 145 | | | | 146 | +---------------+ | 147 | | 148 ______________ v _______________ v ______________ 149 | | +--------+ | | +--------+ | | 150 | Customer LAN |_| CPE |_| IPv6 ISP |_| BR |_| IPv4/ IPv6 | 151 |(dual-stack/ | | Switch | | Network | | Switch | | Internet | 152 | IPv6 network)| +--------+ | | +--------+ |______________| 153 |______________| |_______________| 155 Figure 1 Architecture Overview 157 CPE Switch performs the flow-based packet forwarding function. It 158 MUST support the softwire encapsulation/ decapuslation function 159 specified in [RFC6333], [I-D.ietf-softwire-lw4over6] and 160 [I-D.ietf-softwire-map]. It MUST also support traditional NAPT44 and 161 NAT64 translator ([RFC6146]) function. 163 BR Switch also performs the flow-based packet forwarding function. 164 It MUST support the softwire encapsulation/ decapuslation function 165 specified in [RFC6333], [I-D.ietf-softwire-lw4over6] and 166 [I-D.ietf-softwire-map]. Particularly, it MUST support the port-set 167 matching for incoming IPv4 packets, which is defined in section 6.2 168 of [I-D.ietf-softwire-lw4over6]. 170 Controller is responsible for controlling the performance of both CPE 171 Switch and BR Switch. Controller can be an individual device or a 172 cluster of devices. In case of being a cluster, Controller can be 173 implemented by mulitiple physic or virtual machines, and each machine 174 connects to a Switch. It must configure the forwarding rules in the 175 flow tables maintained by the CPE Switch and BR Switch. It maintains 176 the NAPT44 state and NAT64 state that is associated with the CPE 177 Switch. It also maintains the NAPT44 state, MAP mapping rules, and 178 Lightweight 4over6 binding table state that are associated with the 179 BR Switch. 181 Controller communicates with Switch using protocols that is able to 182 carry flow information and flow table configuration, such as NETCONF 183 [RFC6241], Openflow, etc. 185 4. Control Plane Behavior 187 At least one softwire mechanism (e.g. DS-Lite , Lightweight 4over6 or 188 MAP-E) should be deployed in the system. Multiple softwire 189 mechanisms can be deployed at the same time. This situation includes 190 two cases: (1) mechanisms are implemented in different devices (e.g. 191 DS-Lite B4 and Lightweight 4over6 LwB4 are implemented in different 192 CPE Switches); (2) mechanisms are activated in the same devices (e.g. 193 both DS-Lite B4 and LwB4 are activated in the same CPE Switch). In 194 the first case, Controller can distinguish the CPE Switches or BR 195 Switches by their addresses; in the second case, CPE Switch and BR 196 Switch can apply actions of different mechanisms to different flows 197 according to the flow table. 199 The end devices in the customer LAN can be provisioned with private 200 IPv4 addresses by a local DHCP server. They can also be provisioned 201 with at least one global IPv6 address. 203 CPE Switch and BR Switch MUST be provisioned with at least one IPv6 204 address in the IPv6 ISP network. They MUST be configured with 205 default forwarding rules by Controller. These default rules should 206 cover actions such as forward-to-controller action and default 207 encapsulation/ decapsulation action. Note that configuring default 208 encapsulation/ decapsulation rules can be regarded as establishing a 209 tunnel between CPE Switch and BR Switch if Lightweight 4over6 or 210 MAP-E is deployed in the network. 212 5. Data Plane Behavior 214 When receiving an incoming packet that doesn't have a match in the 215 flow table (usually the intial packet of a new flow), CPE Switch and 216 BR Switch MUST forward the packet to Controller. Controller MUST 217 determine how to proceed the flow (e.g. whether to apply NAT/ NAT64 218 translation and/ or softwire encapsluaton/ decapuslutaion), and 219 interpret the process into a set of forwarding rule configurations. 220 Controller then passes these configurations to CPE Swtich and BR 221 Switch. CPE Switch and BR Switch then configure their flow table 222 according to these configurations, continue to apply the 223 corresponding actions to the packet, and forward it to the next step. 224 When receiving the subsequent packets of the flow, CPE Switch and BR 225 Switch will apply the same actions to them, according to the 226 forwarding rules in the flow table. 228 6. Security Considerations 230 As Switch should always send unknown flows to Controller, the link 231 between Switch and Controller might be vulnerable to a typical DoS 232 attack, which is done by flooding new sessions and can exhaust all 233 available resources of Switch and/or Controller. Some monitoring or 234 filtering approaches should be used to prevent against such an 235 attack. In addition, Controller can implement a policy that 236 restricts the resource allocated to a Switch, or restricts the 237 resource of Switch allocated to a flow. 239 Further security consideration is TBD. 241 7. IANA Considerations 243 This document does not include an IANA request. 245 8. References 247 8.1. Normative References 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, March 1997. 252 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 253 NAT64: Network Address and Protocol Translation from IPv6 254 Clients to IPv4 Servers", RFC 6146, April 2011. 256 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 257 Bierman, "Network Configuration Protocol (NETCONF)", RFC 258 6241, June 2011. 260 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 261 Stack Lite Broadband Deployments Following IPv4 262 Exhaustion", RFC 6333, August 2011. 264 8.2. Informative References 266 [I-D.ietf-softwire-lw4over6] 267 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 268 I. Farrer, "Lightweight 4over6: An Extension to the DS- 269 Lite Architecture", draft-ietf-softwire-lw4over6-07 (work 270 in progress), February 2014. 272 [I-D.ietf-softwire-map] 273 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 274 Murakami, T., and T. Taylor, "Mapping of Address and Port 275 with Encapsulation (MAP)", draft-ietf-softwire-map-10 276 (work in progress), January 2014. 278 Appendix A. Examples 280 Both CPE Switch and BR Switch can perform mulitiple mechanism 281 functions at the same time. When receving a flow that has a match in 282 the flow table, they should determine how to proceed this packet 283 according to the corresponding matched actions in the flow table. 284 Table 1 shows an example about how can CPE Switch or BR Switch choose 285 the right action automatically. 287 +--------+---------------+-----------------------+------------------+ 288 | Switch | Flow type | Matched actions | Processing | 289 +--------+---------------+-----------------------+------------------+ 290 | | | Encapsulation | encapsulate v6 | 291 | | | | header | 292 | | Outbound IPv4 | --------------------- | ---------------- | 293 | | | | NAT44 -> | 294 | | | NAT44 + Encapsulation | encapsulate v6 | 295 | | | | header | 296 | | ------------- | --------------------- | ---------------- | 297 | | Outbound IPv6 | | NAT64 -> | 298 | | | NAT64 + Encapsulation | encapsulate v6 | 299 | | | | header | 300 | CPE | ------------- | --------------------- | ---------------- | 301 | | | Decapsulation | decapsulate v6 | 302 | | | | header | 303 | | | --------------------- | ---------------- | 304 | | Inbound IPv6 | NAT44 + Decapsulation | decapsulate v6 | 305 | | | | header -> NAT44 | 306 | | | --------------------- | ---------------- | 307 | | | NAT64 + Decapsulation | decapsulate v6 | 308 | | | | header -> NAT64 | 309 | ------ | ------------- | --------------------- | ---------------- | 310 | | | NAT44 + Decapsulation | decapsulate v6 | 311 | | | | header -> NAT44 | 312 | | Outbound IPv6 | --------------------- | ---------------- | 313 | | | Decapsulation | decapsulate v6 | 314 | | | | header | 315 | BR | ------------- | --------------------- | ---------------- | 316 | | | | NAT44 -> | 317 | | | NAT44 + Encapsulation | encapsulate v6 | 318 | | | | header | 319 | | Inbound IPv4 | --------------------- | ---------------- | 320 | | | Encapsulation | encapsulate v6 | 321 | | | | header | 322 +--------+---------------+-----------------------+------------------+ 324 Table 1 Auto Processing of Flows 326 Authors' Addresses 328 Yong Cui 329 Tsinghua University 330 Beijing 100084 331 P.R.China 333 Phone: +86-10-6260-3059 334 Email: yong@csnet1.cs.tsinghua.edu.cn 335 Yuchi Chen 336 Tsinghua University 337 Beijing 100084 338 P.R.China 340 Phone: +86-10-6278-5822 341 Email: chenycmx@gmail.com