idnits 2.17.1 draft-wang-v6ops-flow-label-refelction-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 20, 2014) is 3561 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Wang 2 Internet Draft China Telecom 3 Intended status: Standard Track S. Jiang 4 Expires: January 21, 2015 Huawei Technologies Co., Ltd 5 July 20, 2014 7 IPv6 Flow Label Reflection 8 draft-wang-v6ops-flow-label-refelction-01.txt 10 Abstract 12 IPv6 Flow Label field in IPv6 packet header is designed to 13 differentiate the various traffic flow session within network. The 14 current definition of IPv6 Flow Label focuses mainly on how the 15 packet source forms the value of this field and how the forwarder 16 in-path treats it. There is no analysis on the relation between the 17 flow label from source nodes and its corresponding value in return 18 packet. This draft analyzes the requirements for flow label 19 reflection between the upstream session and the corresponding 20 downstream session. Based on the analysis, the flow label reflection 21 mechanism is proposed in this document. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 21, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction ................................................ 3 58 2. Conventions used in this document ........................... 3 59 3. Flow Label Reflection Requirements .......................... 3 60 3.1. Summary of the current usage for IPv6 Flow Label ....... 3 61 3.2. Requirements of Flow Label Reflection .................. 4 62 3.2.1. DS-Lite deployment Scenario ....................... 4 63 3.2.2. Deep Packet Inspection Scenario ................... 6 64 3.2.3. End to End QoS Deployment Scenario within Mobile 65 Network .................................................. 6 66 4. Recommendation and Benefit of Flow Label Reflection Mechanism 7 67 5. Detail Process for Flow Label Reflection .................... 8 68 5.1.1. DS-Lite environment ............................... 8 69 5.1.2. NAT64 environment ................................. 8 70 5.1.3. End to End IPv6 communication environment.......... 9 71 5.2. Influence to the current usage of IPv6 Flow Label ..... 9 72 6. Conclusions ................................................. 9 73 7. Security Considerations ..................................... 9 74 8. IANA Considerations ........................................ 10 75 9. Acknowledgments ............................................ 10 76 10. References ................................................ 10 77 10.1. Normative References ................................. 10 78 10.2. Informative References ............................... 10 80 1. Introduction 82 IPv6 flow label [RFC6437] is designed to differentiate the flow 83 session of IPv6 traffic; it can accelerate the clarification and 84 treatment of IPv6 traffic by the network devices in its forwarding 85 path. Currently, the usage of this field mainly focus on the traffic 86 load-balance in ECMP (Equal Cost Multi-Path) environment [RFC6438] 87 or the server load balance [RFC7098], these usages only exploit the 88 characteristic of IPv6 flow label field in one direction, and do not 89 consider the requirement to correlate the upstream and downstream 90 traffic of one session together to create new service model, to 91 simply the traffic policy deployment and to increase the accuracy of 92 network traffic recognition. 94 In this draft, we analyze the requirements of the flow label 95 reflection mechanism in several scenarios. There is administration 96 benefit for keeping flow label unchanged in the downstream and 97 upstream of one IPv6 traffic session. The details IPv6 flow label 98 reflect process in DS-Lite, NAT64 [RFC6146] and IPv6 end-to-end 99 communication environment are also given. 101 Further deployment requirements and solutions are welcomed and will 102 be studied later. 104 2. Conventions used in this document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Flow Label Reflection Requirements 112 3.1. Summary of the current usage for IPv6 Flow Label 114 [RFC6438] describe the usage of IPv6 Flow Label for ECMP and link 115 aggregation in Tunnels, it mainly utilize the random distribution 116 characteristic of IPv6 flow label. [RFC7098] also describe similar 117 usage case in server farm. All these usage scenarios consider only 118 the usage of IPv6 flow label in one direction, and do not utilize 119 fully the core definition and role of IPv6 flow label for one 120 session. From the point view of service provider, the upstream and 121 downstream of one session should be handled together, then give them 122 the same label value will be more beneficial. 124 Following paragraph analyzes several scenarios that require IPv6 125 flow label reflection mechanism. Other use case needs to further 126 study. 128 3.2. Requirements of Flow Label Reflection 130 This section describes some scenarios that require the IPv6 flow 131 label reflection in IPv6 source and destination nodes. Other similar 132 situations may be required further study. 134 3.2.1. DS-Lite deployment Scenario 136 During IPv6 transition stage, some Internet Service Providers the 137 DS-Lite [RFC6333] technology to accelerate the deployment of IPv6 138 within their network. DS-Lite has the beneficial to eliminate the 139 needs to assign the IPv4 address to the subscribers and simplify the 140 administration of network, but it has one disadvantage that 141 encapsulates all IPv4 traffic from one customer into IPv6 packet and 142 the router in-path, such as BRAS, CR etc. cannot see the inner IPv4 143 destination information. 145 On the other hand, the Internet Service Providers want to 146 differentiate the traffic within their transport pipe, which is 147 based on the requirement from upper CP/SP (Content provider). The 148 general architecture to achieve this goal is illustrated in Figure-1: 150 CP/SP 151 /\ 152 / \\ 153 // \ 154 / \\ 155 / \ 156 CR CR Policy 157 \ / \ Controller 158 \ / \\ --- 159 \ // \ --- 160 \ / ---AFTR 161 \ / ---- 162 BRAS-- 163 /-- 164 // --- 165 / --- 166 / - 167 CPE CPE 168 / \ 169 / \ 170 / \ 171 / \ 172 Host Host 174 Figure-1: DS-Lite Deployment Scenarios 176 Within Figure-1, CPE acts as B4 [RFC6333] to encapsulate the IPv4 177 traffic from host under it into IPv6 packet. According to the 178 current IPv6 node requirement, CPE is responsible to allocate one 179 random/well distribution value to the flow label, to indicate the 180 different IPv4 flow from host is belong to different flow session. 182 The encapsulate IPv6 traffic pass through BRAS and CR, ends in AFTR 183 [RFC6333] which will decapsulate IPv6 traffic into IPv4 packet and 184 return it to CR, the CR will pass the decapsulated IPv4 packet to 185 CP/SP. If the CP/SP wants more bandwidth or quick process, they will 186 deliver the destination IP and port information to the "Policy 187 Controller", which will control the AFTR and then to lift the 188 bandwidth limit on BRAS. 190 For BRAS to act correctly to the appointed IPv4 traffic, it should 191 know the corresponding IPv6 flow label. If the upstream IPv6 flow 192 label is different from the downstream IPv6 label, the ACL lists in 193 BRAS will be quite complex, the upstream and downstream of one 194 session must be processed separately. This will increase the burden 195 of service provider to deploy intelligent network policy. 197 3.2.2. Deep Packet Inspection Scenario 199 Internet service providers are now deploying more DPI (Deep packet 200 inspection) devices within their network to accomplish the 201 visualization of traffic type in their communication pipe and wish 202 to optimize their network structure based on these information. The 203 accuracy of the DPI devices' traffic recognition will influence the 204 effect of network optimization and controlling policy. 206 To increase the traffic recognition rate, the DPI device should 207 track the upstream and downstream of one session simultaneously, in 208 order to find the symptoms of various traffic, especially for P2P 209 traffic. If the IPv6 flow label of upstream and downstream is 210 different, and the three tuple is used to load balance among 212 different links between BRAS and CR, as illustrated in Figure-2, the 213 upstream and downstream of one session will be distributed into 214 different links and then to different DPI devices(DPI-A or DPI-B), 215 thus increases the difficult of traffic recognition that is based on 216 the correlation of downstream and upstream of one session. 218 CR 219 // \\ 220 // \\\-----DPI-A 221 // \\\ 222 // \-----DPI-B 223 // \\\ 224 // \ \ 225 BRAS BRAS 227 Figure-2 Deep Packet Inspection Deployment Scenarios in IPv6-Only 228 Environment 230 3.2.3. End to End QoS Deployment Scenario within Mobile Network 232 Under the mobile network environment, the service provider can 233 control the traffic parameter from UE directly. Based on the common 234 architecture as illustrated in Figure-3 below for end to end QoS 235 deployment within mobile networks, UE will get the QCI parameter 236 from PCRF, and the traffic from this UE will be treated differently 237 according to its service subscription. If the UE and PCRF have the 238 same mapping algorithm, the QCI parameters can be mapped to the IPv6 239 flow label in underlying transport layer. By keeping the value of 240 IPv6 flow label in upstream and downstream same, and based on the 241 mapping information and policy from PCRF, the transport devices can 242 treat the required flow different very easily. 244 Specially, under the situation of UE to UE communicate directly, the 245 traffic initiated by the privilege user will be processed in high 246 priority, even it communicate with one low precedence user; and the 247 traffic initiated by the normal user will be processed in default 248 queue, even it communicate with one privilege user. This traffic 249 model matches with the service provider's business model and can be 250 easily accomplished. 252 PCRF 253 -- -- 254 --- --- 255 /----\ --- ---- -- /----\ 256 // \\ -- / \ -- // \\ 257 UE | QCI Scope| PCEF/PGW backbone PCEF/PGW | QCI Scope| UE 258 \\ // \ / \\ // 259 \----/ ---- \----/ 261 Figure-3 End to End QoS deployment within Mobile Network 263 4. Recommendation and Benefit of Flow Label Reflection Mechanism 265 Based on the scenarios described above, we propose the following 266 solution: 268 1. The value of IPv6 Flow Label SHOULD be reflected and kept 269 unchanged by the receiving IPv6 node. 271 2. Under such reflection mechanism, the IPv6 Flow Label will be used 272 unambiguously to indicate one session's upstream and downstream 273 traffic: 275 a) The service provider can easily apply the same policy to the 276 bi-direction traffic of one interested session; 278 b) The traffic analyzer can also easily correlate the upstream and 279 downstream of one session to find the symptoms of various 280 internet protocol. 282 c) The service provider can offer differentiated service based on 283 the user's privilege condition and their service in use, make 284 the Non-equivalent service possible under the end-to-end 285 communication model in mobile network environment. 287 3. The generation method of IPv6 flow label in source IPv6 node and 288 the forward behavior are still recommended to follow the 289 guidelines in RFC 6437, that is the IPv6 flow label should be 290 generated randomly and distributed enough, the devices in the 291 traffic forwarding path should not changed it. 293 5. Detail Process for Flow Label Reflection 295 5.1.1. DS-Lite environment 297 Under DS-Lite environment, the B4/CPE and AFTR are the two ends of 298 IPv6 communication: 300 a) B4/CPE is responsible for the generation of IPv6 packet, and is 301 responsible for the initial value of IPv6 flow label. Because 302 all IPv4 traffic from it is encapsulated into one IPv6 tunnel 303 packet, the value of IPv6 flow label should distinguish the 304 inner different IPv4 flow. Recommending algorithm is to use the 305 5-tuple of IPv4 traffic as the input of hash function. 307 b) AFTR is responsible for the decapsulation of IPv6 traffic. The 308 original IPv6 flow label should be kept in the stateful table 309 in AFTR, along with the mapping entry of "private IPv4 310 source/port, IPv6 source address, public IPv4 source/port, 311 protocol". 313 c) Once the responsible IPv4 traffic back to AFTR, it should check 314 the above mapping table, NAT and encapsulate the IPv4 traffic, 315 set the IPv6 flow label of returned encapsulated IPv6 packet to 316 the previous stored value. 318 5.1.2. NAT64 environment 320 Under NAT64 environment, the IPv6 host and the NAT64 device is the 321 two IPv6 communication ends: 323 a) IPv6 host is responsible for the generation of IPv6 packet, and 324 is responsible for the initial value of IPv6 flow label. 325 Recommending algorithm is to use the 5-tuple of IPv6 traffic as 326 the input of hash function. 328 b) NAT64 is the other end of IPv6 communication session. It should 329 record the original value of IPv6 flow label in upstream in its 330 NAT table, along with the mapping entry of "IPv6 source 331 address/port, public IPv4 source address/port, protocol" 333 c) Once the responsible IPv4 traffic back to NAT64 device, it 334 should retrieve the corresponding original value of IPv6 flow 335 label in the above mentioned mapping table, put it in the 336 header of downstream converted IPv6 traffic. 338 5.1.3. End to End IPv6 communication environment 340 It is simpler to do IPv6 flow label reflection under the end to end 341 Ipv6 communication environment: 343 a) IPv6 source host is responsible for the generation of IPv6 344 packet, and is responsible for the initial value of IPv6 flow 345 label. Recommending algorithm is to use the 5-tuple of IPv6 346 traffic as the input of hash function. 348 b) IPv6 destination host just copy the original IPv6 flow label to 349 its corresponding field in reply packet. 351 c) There is no need to keep the value of IPv6 flow label in 352 forwarding path. 354 5.2. Influence to the current usage of IPv6 Flow Label 356 There is no any influence to the current proposed usages of IPv6 357 flow label. 359 6. Conclusions 361 IPv6 flow label reflection mechanism makes the downstream and 362 upstream of one session be easily recognized, let the service 363 provider take the full control of one session's bi-direction traffic 364 and apply the same traffic policy to them. It also let the 365 correlation of traffic and then the recognition of various traffics 366 easier. Based on such mechanism, the service provider can also offer 367 Non-equivalent service in IPv6 end-to-end communication environment, 368 especially in the IPv6-based mobile network environment. 370 7. Security Considerations 372 In order to keep the IPv6 flow label unchanged and same in the 373 upstream and downstream of one session, the in-path devices, which 374 is required in the IPv6 transition period, such as AFTR/NAT64 etc. 375 should be required to store the IPv6 flow label value, retrieve and 376 restore it in the downstream traffic. This may increase the burden 377 of such stateful devices within service provider's network and lower 378 the anti-attack capabilities of these devices. This threat exists 379 only in the transition period and will disappear in the IPv6 end-to- 380 end communication period. 382 8. IANA Considerations 384 There is no additional IANA requirement for this requirement. 386 9. Acknowledgments 388 Valuable comments were received from Brian Carpenter. 390 This document was prepared using 2-Word-v2.0.template.dot. 392 10. References 394 10.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [RFC6146] M. Bagnulo, P. Matthews, I. van Beijnum," Stateful NAT64: 400 Network Address and Protocol Translation from IPv6 Clients 401 to IPv4 Servers" RFC 6146, April 2011 403 [RFC6333] A. Durand, R. Droms, J. Woodyatt, Y. Lee, "Dual-Stack Lite 404 Broadband Deployments Following IPv4 Exhaustion", RFC6333, 405 August 2011 407 [RFC6437] S. Amante, B. Carpenter, S. Jiang, J. Rajahalme, "IPv6 408 Flow Label Specification", RFC 6437, November 2011. 410 [RFC6438] B. Carpenter, S. Amante, "Using the IPv6 Flow Label for 411 Equal Cost Multipath Routing and Link Aggregation in 412 Tunnels", RFC 6438, November 2011. 414 10.2. Informative References 416 [RFC7098] B. Carpenter, S. Jiang, W. Tarreau,"Using the IPv6 Flow 417 Label for Load Balancing in Server Farms", RFC 7098, 418 January 2014. 420 Authors' Addresses 422 Aijun Wang 423 China Telecom Cooperation Limited Beijing Research Institute 424 No.118, Xizhimenneidajie, Xicheng District, Beijing, 100035, China 426 Phone: 86-10-58552347 427 Email: wangaj@ctbri.com.cn 429 Jiang Sheng 430 Huawei Technologies Co., Ltd 431 Q14, Huawei Campus, No.156 Beiqing Road 432 Hai-Dian District, Beijing, 100095 433 P.R. China 435 Email: jiangsheng@huawei.com