idnits 2.17.1 draft-wang-6man-flow-label-reflection-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 (March 8, 2015) is 3334 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) == Unused Reference: 'RFC6146' is defined on line 426, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Wang 3 Internet-Draft China Telecom 4 Intended status: Standards Track S. Jiang 5 Expires: September 9, 2015 Huawei Technologies Co., Ltd 6 March 8, 2015 8 IPv6 Flow Label Reflection 9 draft-wang-6man-flow-label-reflection-01 11 Abstract 13 The current definition of the IPv6 Flow Label focuses mainly on how 14 the packet source forms the value of this field and how the forwarder 15 in-path treats it. In network operations, there are needs to 16 correlate an upstream session and the corresponding downstream 17 session together. This document propose a flow label reflection 18 mechanism that network devices copy the flow label value from 19 received packets to the corresponding flow label field in return 20 packets. This mechanism could simplify the network traffic 21 recognition process in network operations and make the policy for 22 both directions of traffic of one session consistent. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 9, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Summary of the current usage for IPv6 Flow Label . . . . 3 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 61 3. Potential Benefit of Flow Label Reflection . . . . . . . . . 4 62 4. Flow Label Reflection Behaviors on Network Devices . . . . . 4 63 5. Applicable Scenarios . . . . . . . . . . . . . . . . . . . . 5 64 5.1. Flow Label Reflection on CP servers . . . . . . . . . . . 5 65 5.2. Flow Label Reflection for Bi-direction Tunnels . . . . . 6 66 5.3. Flow Label Reflection on edge devices . . . . . . . . . . 7 67 5.4. Misc Possible Scenarios . . . . . . . . . . . . . . . . . 7 68 5.4.1. Aid to mitigate the ND cache DDoS Attack . . . . . . 7 69 5.4.2. Improve the efficiency of PTB problem solution in 70 load-balance environment . . . . . . . . . . . . . . 8 71 6. Deployment Consideration . . . . . . . . . . . . . . . . . . 8 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 10.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 The IPv6 flow label [RFC6437] in the fixed IPv6 header is designed to 83 differentiate the various flow session of IPv6 traffic; it can 84 accelerate the clarification and treatment of IPv6 traffic by the 85 network devices in its forwarding path. In practice, many current 86 implementations use the 5-tuple {dest addr, source addr, protocol, 87 dest port, source port} as the identifier of network flows. However, 88 transport-layer information, such as the port numbers, is not always 89 in a fixed position, since it follows any IPv6 extension headers that 90 may be present; in contrast, the flow label is at a fixed position in 91 every IPv6 packet and easier to access. In fact, the logic of 92 finding the transport header is always more complex for IPv6 than for 93 IPv4, due to the absence of an Internet Header Length field in IPv6. 94 Additionally, if packets are fragmented, the flow label will be 95 present in all fragments, but the transport header will only be in 96 one packet. Therefore, within the lifetime of a given transport- 97 layer connection, the flow label can be a more convenient "handle" 98 than the port number for identifying that particular connection. 100 The usages of IPv6 flow label, so far as briefly summarized in 101 Section 1.1, only exploit the characteristic of IPv6 flow label in 102 one direction. 104 In current practice, an application session is often recognized as 105 two separated IP traffics, in two opposite directions. However, from 106 the point view of a service provider, the upstream and downstream of 107 one session should be handled together, particularly, when 108 application-aware operations are placed in the network. A ubiquitous 109 example is that end user initiates a request, with small-scale data 110 transmitted, towards a content server, then the server responds with 111 a large set of follow-up packets. The bi-directional flows should be 112 correlated together and handled with the same policy. Ideally, the 113 request embeds a flow recognition identifier that is accessible and 114 the follow-up response packets carry the same identifier. The flow 115 label is a good choice for the flow recognition identifier. 117 This document proposes a flow label reflection mechanism so that 118 network devices copy the flow label value from received packets to 119 the corresponding flow label field in return packets. By having the 120 same flow label value in the downstream and upstream of one IPv6 121 traffic session, the network traffic recognition process and the 122 traffic policy deployment in network operations could be simplified. 123 It may also increase the accuracy of network traffic recognition. 125 Several applicable scenarios of the IPv6 flow label reflection are 126 also given, in Section 5. For now, this document only considers the 127 scenario in a single administrative domain, although the IPv6 flow 128 label reflection mechanism may also bring benefits into cross domain 129 scenarios. 131 1.1. Summary of the current usage for IPv6 Flow Label 133 [RFC6438] describe the usage of IPv6 Flow Label for ECMP and link 134 aggregation in Tunnels; it mainly utilizes the random distribution 135 characteristic of IPv6 flow label. [RFC7098] also describes similar 136 usage in server farms. 138 All these usage scenarios consider only the usage of IPv6 flow label 139 in one direction, while many bi-directional network traffics need to 140 be treated together. 142 2. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in 147 [RFC2119] when they appear in ALL CAPS. When these words are not in 148 ALL CAPS (such as "should" or "Should"), they have their usual 149 English meanings, and are not to be interpreted as [RFC2119] key 150 words. 152 Flow Label Reflection A mechanism/behavior so that a network device 153 copies the value of flow label from a IPv6 flow into a 154 corresponding return IPv6 flow. 156 Flow Label Reflection Device A network device that applies the flow 157 label reflection mechanism. It is the end of an IPv6 flow and the 158 initiation node of the corresponding return IPv6 flow. 160 3. Potential Benefit of Flow Label Reflection 162 With flow label reflection mechanism, the IPv6 Flow Label could be 163 used to correlate the upstream and downstream packets of bi- 164 directional traffics: 166 o It makes the downstream and upstream of one session be easily 167 recognized. It makes the correlation of traffic and then the 168 recognition of various traffics easier. 170 o The network operator can easily apply the same policy to the bi- 171 directional traffic of one interested session 173 o The traffic analyzer can also easily correlate the upstream and 174 downstream of one session to find the symptoms of various internet 175 protocols. 177 4. Flow Label Reflection Behaviors on Network Devices 179 To fulfill the flow label reflection mechanism, the below proposed 180 behaviors on network devices: 182 o The generation method of IPv6 flow label in source IPv6 node 183 SHOULD follow the guidelines in [RFC6437], that is the IPv6 flow 184 label should be generated randomly and distributed enough. 186 o On the Flow Label Reflection Device, the value of IPv6 Flow Label 187 from received packets SHOULD be copied into the corresponding flow 188 label field in return packets by the flow label reflection 189 devices. 191 o The forwarding nodes within the management domain SHOULD follow 192 the specification in [RFC6437], that is the IPv6 flow label SHOULD 193 NOT be modified in the path, unless flow label value in arriving 194 packets is zero. The forwarding nodes MAY follow the 195 specification in [RFC6438] when using the flow label for load 196 balancing by equal cost multipath (ECMP) routing and for link 197 aggregation, particularly for IPv6-in-IPv6 tunneled traffic. 199 o The network traffic recognition devices, or devices that may have 200 differentiated operations per flow, SHOULD recognize and analyze 201 network traffics based on 3-tuple of {dest addr, source addr, 202 flowlabel}. It SHOULD consider the traffics that have same flow 203 label value and reversed source/dest addr as upstream and 204 downstream of the same flow, match them together to accomplish the 205 traffic recognition process. 207 o Other network operations MAY also be based on 3-tuple of {dest 208 addr, source addr, flowlabel}. 210 5. Applicable Scenarios 212 This section describes some applicable scenarios, which network 213 operators can benefit from deploying the flow label reflection 214 mechanism. It is not a complete enumeration. More scenarios may be 215 introduced in the future. 217 5.1. Flow Label Reflection on CP servers 219 There is rapidly increasing requirement from service providers (SP) 220 to cooperate with the content providers (CP) to provide more accurate 221 services and charging policies based on accurate traffic recognition. 222 The service providers need to recognize the CP/SP's bi-directional 223 traffics at the access edge devices of the network, such as 224 BRAS/PDSN/P-GW devices. 226 Normally, the burden for these edge devices to recognize the 227 subscriber's upstream traffic is light, because request messages are 228 typically small. But they often need more resource to recognize 229 downstream traffics, which normally contain large data. With flow 230 label reflection on CP servers, recognition based on the 3-tuple of 231 {dest addr, source addr, flowlabel} would reduce the consumption of 232 recognition and make the correlation process much easier. 234 In this scenario, the CP servers would be the Flow Label Reflection 235 Devices. They copy the flow label value from received upstream user 236 request packets to the corresponding flow label field in return 237 downstream packets. 239 The access edge devices of service provider scrutinize the 240 subscriber's upstream IPv6 traffic and record the binding of 3-tuple 241 and traffic-specific policy. If the flow label is zero, the access 242 edge devices must rewrite the flow label value according to local 243 policy. With the recorded binding information, the access edge 244 devices can easily recognize and match the downstream packet to the 245 previous recognized upstream packet, by just accessing 3-tuple. The 246 edge devices can then apply the corresponding traffic policy to the 247 upstream/downstream of the session to the cooperated CP. 249 Note: this mechanism may not reliable when the CP servers are not 250 directly connected to the service provider, because there is no 251 guarantee the flow label would not be changed by intermediate devices 252 in other administrative domains. 254 5.2. Flow Label Reflection for Bi-direction Tunnels 256 Tunnel is ubiquitous within service provider networks. It is very 257 difficult (important if the tunnel is encrypted) for intermediate 258 network devices to recognize the inner encapsulated packet, although 259 such recognition could be very helpful in some scenarios, such as 260 traffic statistics, network diagnoses, etc. Furthermore, such 261 recognition normally requires to correlate bi-direction traffic 262 together. The flow label reflection mechanism could provide help in 263 such requirement scenarios. 265 In this scenario, the tunnel end devices would be the Flow Label 266 Reflection Devices. They record the flow label value from received 267 tunnel packets, and copy it to the corresponding flow label field in 268 return packets, which can be recognized by 5-tuple or 3-tuple of the 269 inner packet at the tunnel end devices. 271 The tunnel initiating devices should generate different flow label 272 values for different inner flow traffics based on their 5-tuple or 273 3-tuple in accordance with [RFC6437]. Note: if the inner flow is 274 encryption in ESP model [RFC4303], the transport-layer port numbers 275 are inaccessiable. In such case, 5-tuple is not available. 277 Then the intermediate network device can easily distinguish the 278 different flow within the same tunnel transport link and correlate 279 bi-direction traffics of same flow together. This can also increase 280 the service provider's traffic control capabilities. 282 This mechanism can also work when the encapsulated traffics are IPv4 283 traffics, such as DS-Lite scenario [RFC6333]. The IPv4 5-tuple may 284 be used as the input for the flow label generation. 286 5.3. Flow Label Reflection on edge devices 288 If the flow label reflection mechanisms have been applied on peer 289 host, the service provider could always use it for bi-directional 290 traffic recognition. However, there is no guarantee the flow label 291 would not be changed by intermediate devices in other administrative 292 domains. Therefore, to make the flow label value trustful, the edge 293 devices need to validate the flow label reflection. 295 In this scenario, the edge devices would be the (backup) Flow Label 296 Reflection Devices. They record the flow label value from the 297 packets that leave the domain. When the corresponding flow label 298 field in return packets are recognized by 5-tuple or 3-tuple at the 299 edge devices, the edge devices should check the flow label as below: 301 o if the flow label matches the record value, it remains; 303 o if the flow label is zero, the edge devices copy the record value 304 into it; 306 o if the flow label is non-zero, but does not matches the record 307 value, the edge devices can decide the flow label are modified by 308 other intermediate devices (with the assumption the peer host has 309 reflect the original flow label), then restore the flow label 310 using the record value. 312 Then the network recognition devices located anywhere within the 313 service provider network could easily correlate bi-directional 314 traffics together, and apply traffic-specific policy accordingly. 316 5.4. Misc Possible Scenarios 318 In the below scenarios, the flow label reflection mechanism needs to 319 be combined with other mechanisms in order to achieve the design 320 goals. 322 5.4.1. Aid to mitigate the ND cache DDoS Attack 324 Neighbor Discovery Protocol [RFC4861][RFC4861] is vulnerable for the 325 possible DDoS attack to the device's ND cache, see section 11.1, 326 [RFC4861]. There are many proposals are aiming to mitigate this 327 problem, but none of them are prevalent now. It is mainly because 328 that there is no obvious mechanism to assure the validation of the 329 NS/RS packet on the first arrival, the receiving node by default will 330 cache the link-layer address of the NA packet. Reverse detection 331 mechanisms can be added to solve this issue. However, for reverse 332 detection mechanisms, there would be another issue: how to pair the 333 return NA/RA packet with the NS/RS packet on the sending node. It 334 can be solved by applying the flow label reflection mechanism in the 335 return NA/RA packet. Then the sending node can pair the reverse 336 detect NS/RS packet with original NA/RA packet and response to the 337 reverse detect NS/RS packet correctly. Only the NS/RS packet that 338 passed the reverse detection validation will be accept by the node 339 and the link-layer address within it will be cached. 341 5.4.2. Improve the efficiency of PTB problem solution in load-balance 342 environment 344 [I-D.v6ops-pmtud-ecmp-problem] introduces the Packet Too Big 345 [RFC4443] problem in load-balance environment. The downstream packet 346 from a server, which responses to a client request message, may meet 347 a forwarding node that rejects the packet for "too big" reason. The 348 PTB error ICMPv6 message should be returned to the original server. 349 However, it requests the load balancer to distribute the PTB error 350 ICMPv6 message based on the information of the invoking packet within 351 the ICMPv6 packet, not the ICMPv6 packet itself. The load balancer 352 needs to obtain the source IP address and transport port information 353 within the invoking packet. 355 However, if both the server and the forwarding node that generates 356 the PTB message apply the flow label reflection mechanism, the PTB 357 error ICMPv6 message would have the same flow label with the original 358 client request message. Then, the load balancer, that follows 359 [RFC7098], could easily forward the PTB packet to same server without 360 parsing the transport port in the invoking packet, thus increases the 361 efficiency. 363 6. Deployment Consideration 365 The IPv6 flow label reflection mechanism requires the "Flow Label 366 Reflection Device" to be stateful, store the flow label value and 367 copy it to the corresponding return packet. Such change cannot be 368 accomplished within a short term, and therefore the deployment of 369 this mechanism will be accomplished gradually. During the 370 incremental deployment period, the traditional recognition 371 mechanisms, which are more expensive, would coexist. The traffics 372 that could not be recognized by 3-tuple of {dest addr, source addr, 373 flowlabel} could fall back to the traditional process or be skipped 374 over by advanced services. The more devices support the flow label 375 reflection mechanism, the less consumption for traffic recognition 376 from the network management perspective, or the better coverage of 377 advanced services that are based on the traffic recognition. 379 7. Security Considerations 381 Security aspects of the flow label are discussed in [RFC6437]. A 382 malicious source or man-in-the-middle could disturb the traffic 383 recognition by manipulating flow labels. However, the worst case is 384 that fall back to the current practice that an application session is 385 often recognized as two separated IP traffics. The flow label does 386 not significantly alter this situation. 388 Specifically, the IPv6 flow label specification [RFC6437] states that 389 "stateless classifiers should not use the flow label alone to control 390 load distribution." This is answered by also using the source and 391 destination addresses with flow label. 393 8. IANA Considerations 395 This draft does not request any IANA action. 397 9. Acknowledgements 399 The authors would like to thanks Brian Carpenter, who gave many 400 useful advices. The authors would also like to thanks the valuable 401 comments made by Fred Baker, Lee Howard, Mark ZZZ Smith, Jeroen 402 Massar, Florent Fourcot and other members of V6OPS WG. Also, special 403 thanks for Florent Fourcot, who have implemented the flow label 404 reflection mechanims in the Linux. 406 This document was produced using the xml2rfc tool [RFC2629]. 408 10. References 410 10.1. Normative References 412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 413 Requirement Levels", BCP 14, RFC 2119, March 1997. 415 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 416 June 1999. 418 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 419 Message Protocol (ICMPv6) for the Internet Protocol 420 Version 6 (IPv6) Specification", RFC 4443, March 2006. 422 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 423 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 424 September 2007. 426 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 427 NAT64: Network Address and Protocol Translation from IPv6 428 Clients to IPv4 Servers", RFC 6146, April 2011. 430 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 431 "IPv6 Flow Label Specification", RFC 6437, November 2011. 433 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 434 for Equal Cost Multipath Routing and Link Aggregation in 435 Tunnels", RFC 6438, November 2011. 437 10.2. Informative References 439 [I-D.v6ops-pmtud-ecmp-problem] 440 Byerly, M., Hite, M., and J. Jaeggli, "Close encounters of 441 the ICMP type 2 kind (near misses with ICMPv6 PTB)", 442 draft-v6ops-pmtud-ecmp-problem-00 (work in progress), 443 August 2014. 445 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 446 4303, December 2005. 448 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 449 Stack Lite Broadband Deployments Following IPv4 450 Exhaustion", RFC 6333, August 2011. 452 [RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 453 Flow Label for Load Balancing in Server Farms", RFC 7098, 454 January 2014. 456 Authors' Addresses 458 Aijun Wang 459 China Telecom 460 Beijing Research Institute, China Telecom Cooperation Limited 461 No.118, Xizhimenneidajie, Xicheng District, Beijing 100035 462 China 464 Phone: 86-10-58552347 465 Email: wangaj@ctbri.com.cn 466 Sheng Jiang 467 Huawei Technologies Co., Ltd 468 Q14, Huawei Campus, No.156 Beiqing Road 469 Hai-Dian District, Beijing, 100095 470 P.R. China 472 Email: jiangsheng@huawei.com