Netwok Working Group Aijun. Wang Internet Draft China Telecom Intended status: Standard Track July 3,2014 Expires: January 2015 IPv6 Flow Label Reflection Requirement draft-wang-v6ops-flow-label-refelction-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 3, 2009. 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 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 Wang Expires January 3, 2015 [Page 1] Internet-Draft Flowlabel Reflection Requirement July 2014 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract IPv6 Flow Label field in IPv6 packet header is designed to differentiate the various traffic flow session within network. Current related RFCs(RFC 6437 and RFC 6438 etc.)describe the IPv6 Flow Label generation recommendation and usage in network traffic load balance. But all of these documents focus mainly how the packet source forms the value of this field and how the forwarder in-path treats it. None of the existing documents describes the relation between the flow label from source nodes and its corresponding value in return packet. This draft describes the requirements for flow label reflection between the upstream session and the corresponding downstream session, the benefit of this mirroring mechanism and its influence to the current proposed IPv6 flow label usage. This mechanism is unique to IPv6, and should be exploited to promote the deployment of IPv6 technology in more rapid pace. Table of Contents 1. Introduction ................................................ 3 1.1. ... 2. Conventions used in this document ............................ 3 3. Flow Label Reflection Mechanism .............................. 3 3.1. Summary of the current usage for IPv6 Flow Label ......... 4 3.2. Various scenarios for requirements of flow label reflection ............................................................ 4 3.2.1. DS-Lite deployment case ............................ 4 3.2.2. Deep Packet Inspection case ........................ 6 3.2.3. End to End QoS deployment within Mobile Internet .... 7 3.3. Recommendation and Benefit of Flow Label Reflection Mechanism ................................................... 7 3.4. Detail of Flow Label Reflection Mechanism ............... 8 3.4.1. DS-Lite environment ................................ 8 3.4.2. NAT64 environment .................................. 9 3.4.3. End to End IPv6 communication environment........... 9 3.5. Influence to the current usage of IPv6 Flow Label ........ 9 4. Security Considerations ..................................... 10 5. IANA Considerations ........................................ 10 6. Conclusions ................................................ 10 7. References ................................................. 10 7.1. Normative References ................................... 10 7.2. Informative References ................................. 11 8. Acknowledgments ............................................ 11 Expires January 3, 2015 [Page 2] Internet-Draft Flowlabel Reflection Requirement July 2014 1. Introduction IPv6 flow label is designed to differentiate the flow session of IPv6 traffic; it can accelerate the clarification and treatment of IPv6 traffic by the network devices in its forwarding path. Currently, the usage of this field mainly focus on the traffic load- balance in ECMP(Equal Cost Multi-Path)environment or the server load balance(see RFC7098),these usages only exploit the characteristic of IPv6 flow label field in one direction, and do not consider the requirement to correlate the upstream and downstream traffic of one session together to create new service model, to simply the traffic policy deployment and to increase the accuracy of network traffic recognition. In this draft, we analyze several scenarios for the flow label reflection; illustrate the benefit of keeping flow label unchanged in the downstream and upstream of one IPv6 traffic session and give the detail IPv6 flow label reflect process in DS-Lite,NAT64 and IPv6 end-to-end communication environment. Further deployment requirements and solutions are welcomed and will be studied later. 2. Conventions used in this document 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 RFC-2119 [RFC2119]. 3. Terminology DS-Lite: Dual-Stack Lite, transition technology defined in RFC6333 B4: DS-Lite Basic Bridging BroadBand (B4) element AFTR: DS-Lite Address Family Transition Router (AFTR) element. NAT-related terminology is defined in [RFC4787]. CPE:Customer Premise Equipment. The layer 3 device in the customer premise that is connected to the service provider network. Expires January 3, 2015 [Page 3] Internet-Draft Flowlabel Reflection Requirement July 2014 4. Flow Label Reflection Mechanism 4.1. Summary of the current usage for IPv6 Flow Label [RFC 6438] describe the usage of IPv6 Flow Label for ECMP and link aggregation in Tunnels, it mainly utilize the random distribution characteristic of IPv6 flow label. [RFC 7098] also describe similar usage case in server farm. All these usage scenarios consider only the usage of IPv6 flow label in one direction, and do not utilize fully the core definition and role of IPv6 flow label for one session. From the point view of service provider, the upstream and downstream of one session should be handled together, then give them the same label value will be more beneficial. Following paragraph analyze several scenarios that require to use IPv6 flow label reflection mechanism. Other use case needs to further study. 4.2. Various scenarios for requirements of flow label reflection This section describes some scenarios that require the IPv6 flow label reflection in IPv6 source and destination nodes. Other similar situations may be required further study. 4.2.1. DS-Lite deployment case During IPv6 transition stage, some service provider select the DS- Lite[RFC 6333] technology to accelerate the deployment of IPv6 within their network. DS-Lite has the beneficial to eliminate the needs to assign the IPv4 address to the subscribers and simplify the administration of network, but it has one disadvantage that encapsulates all IPv4 traffic from one customer into IPv6 packet and the router in-path, such as BRAS,CR etc. cannot see the inner IPv4 destination information. On the other hand, service provider want to differentiate the traffic within their transport pipe, which is based on the requirement from upper CP/SP(Content provider). The general architecture to achieve this goal is illustrated in Figure-1: Expires January 3, 2015 [Page 4] Internet-Draft Flowlabel Reflection Requirement July 2014 CP/SP /\ / \\ // \ / \\ / \ CR CR Policy \ / \ Controller \ / \\ --- \ // \ --- \ / ---AFTR \ / ---- BRAS-- /-- // --- / --- / - CPE CPE / \ / \ / \ / \ Host Host Figure-1: DS-Lite Deployment Scenarios Within Figure-1, CPE acts as B4 to encapsulate the IPv4 traffic from host under it into IPv6 packet. According to the current IPv6 node requirement, CPE is responsible to allocate one random/well distribution value to the flow label, to indicate the different IPv4 flow from host is belong to different flow session. The encapsulate IPv6 traffic pass through BRAS and CR, ends in AFTR which will decapsulate IPv6 traffic into IPv4 packet and return it to CR, the CR will pass the decapsulated IPv4 packet to CP/SP. If the CP/SP wants more bandwidth or quick process, they will deliver the destination IP and port information to the "Policy Controller", which will control the AFTR and then to lift the bandwidth limit on BRAS. For BRAS to act correctly to the appointed IPv4 traffic, it should know the corresponding IPv6 flow label. If the upstream IPv6 flow label is different from the downstream IPv6 label, the ACL lists in BRAS will be quite complex, the upstream and downstream of one session must be processed separately. This will increase the burden of service provider to deploy intelligent network policy. Expires January 3, 2015 [Page 5] Internet-Draft Flowlabel Reflection Requirement July 2014 4.2.2. Deep Packet Inspection case Internet service providers are now deploying more DPI(Deep packet inspection) devices within their network to accomplish the visualization of traffic type in their communication pipe and wish to optimize their network structure based on these information. The accuracy of the DPI devices' traffic recognition will influence the effect of network optimization and controlling policy. To increase the traffic recognition rate, the DPI device should track the upstream and downstream of one session simultaneously, in order to find the symptoms of various traffic, especially for P2P traffic. If the IPv6 flow label of upstream and downstream is different, and the three tuple is used to load balance among different links between BRAS and CR, as illustrated in Figure-2, the upstream and downstream of one session will be distributed into different links, thus increases the difficult of traffic recognition that is based on the correlation of downstream and upstream of one session. CR // \\ // \\\-----DPI // \\\ // \\ // \\\ // \ \ BRAS BRAS Figure-2 Deep Packet Inspection Deployment Scenarios in IPv6-Only Environment Expires January 3, 2015 [Page 6] Internet-Draft Flowlabel Reflection Requirement July 2014 4.2.3. End to End QoS deployment within Mobile Internet Under the mobile Internet environment, the service provider can control the traffic parameter from UE directly. Based on the common architecture as illustrated in Figure-3 below for end to end QoS deployment within Mobile Internet, UE will get the QCI parameter from PCRF, and the traffic from this UE will be treated differently according to its service subscription. If the QCI parameters can be mapped to the IPv6 flow label in underlying transport layer and the value of upstream and downstream is kept same, the transport devices can treat the required flow different very easily. Specially, under the situation of UE to UE communicate directly, the traffic initiated by the privilege user will be processed in high priority, even it communicate with one low precedence user; and the traffic initiated by the normal user will be processed in default queue, even it communicate with one privilege user. This traffic model matches with the service provider's business model and can be easily accomplished. PCRF -- -- --- --- /----\ --- ---- -- /----\ // \\ -- / \ -- // \\ UE | QCI Scope| PCEF/PGW backbone PCEF/PGW | QCI Scope| UE \\ // \ / \\ // \----/ ---- \----/ Figure-3 End to End Qos deployment within Mobile Internet 4.3. Recommendation and Benefit of Flow Label Reflection Mechanism Based on the scenarios described above, we propose the following solution: Expires January 3, 2015 [Page 7] Internet-Draft Flowlabel Reflection Requirement July 2014 1. The value of IPv6 Flow Label should be reflected and kept unchanged by the receiving IPv6 node. 2. Under such reflection mechanism, the IPv6 Flow Label will be used unambiguously to indicate one session's upstream and downstream traffic: a) The service provider can easily apply the same policy to the bi-direction traffic of one interested session; b) The traffic analyzer can also easily correlate the upstream and downstream of one session to find the symptoms of various internet protocol. c) The service provider can offer differentiated service based on the user's privilege condition and their service in use, make the Non-equivalent service possible under the end-to-end communication model in mobile internet environment. 3. The generation method of IPv6 flow label in source IPv6 node and the forward behavior are still recommended to follow the guidelines in RFC 6437, that is the IPv6 flow label should be generated randomly and distributed enough, the devices in the traffic forwarding path should not changed it. 4.4. Detail of Flow Label Reflection Mechanism 4.4.1. DS-Lite environment Under DS-Lite environment, the B4/CPE and AFTR are the two ends of IPv6 communication: a) B4/CPE is responsible for the generation of IPv6 packet, and is responsible for the initial value of IPv6 flow label. Because all IPv4 traffic from it is encapsulated into one IPv6 tunnel packet, the value of IPv6 flow label should distinguish the inner different IPv4 flow. Recommending algorithm is to use the 5-tuple of IPv4 traffic as the input of hash function. b) AFTR is responsible for the decapsulting of IPv6 traffic. The original IPv6 flow label should be kept in the stateful table in AFTR, along with the mapping entry of "private IPv4 source/port, IPv6 source address, public IPv4 source/port, protocol". c) Once the responsible IPv4 traffic back to AFTR, it should check the above mapping table, NAT and encapsulate the IPv4 traffic, Expires January 3, 2015 [Page 8] Internet-Draft Flowlabel Reflection Requirement July 2014 set the IPv6 flow label of returned encapsulated IPv6 packet to the previous stored value. 4.4.2. NAT64 environment Under NAT64 environment, the IPv6 host and the NAT64 device is the two IPv6 communication ends: a) IPv6 host is responsible for the generation of IPv6 packet, and is responsible for the initial value of IPv6 flow label. Recommending algorithm is to use the 5-tuple of IPv6 traffic as the input of hash function. b) NAT64 is the other end of IPv6 communication session. It should record the original value of IPv6 flow label in upstream in its NAT table, along with the mapping entry of "IPv6 source address/port, public IPv4 source address/port, protocol" c) Once the responsible IPv4 traffic back to NAT64 device, it should retrieve the corresponding original value of IPv6 flow label in the above mentioned mapping table, put it in the header of downstream converted IPv6 traffic. 4.4.3. End to End IPv6 communication environment It is more simple to do IPv6 flow label reflection under the end to end Ipv6 communication environment: a) IPv6 source host is responsible for the generation of IPv6 packet, and is responsible for the initial value of IPv6 flow label. Recommending algorithm is to use the 5-tuple of IPv6 traffic as the input of hash function. b) IPv6 destination host just copy the original IPv6 flow label to its corresponding field in reply packet. c) There is no need to keep the value of IPv6 flow label in forwarding path. 4.5. Influence to the current usage of IPv6 Flow Label There is no any influence to the current proposed usages of IPv6 flow label. Expires January 3, 2015 [Page 9] Internet-Draft Flowlabel Reflection Requirement July 2014 5. Security Considerations In order to keep the IPv6 flow label unchanged and same in the upstream and downstream of one session, the in-path devices, which is required in the IPv6 transition period, such as AFTR/NAT64 etc. should be required to store the IPv6 flow label value, retrieve and restore it in the downstream traffic. This may increase the burden of such stateful devices within service provider's network and lower the anti-attack capabilities of these devices. This threat exists only in the transition period and will disappear in the IPv6 end-to- end communication period. 6. IANA Considerations There is no additional IANA requirement for this requirement. 7. Conclusions IPv6 flow label reflection mechanism makes the downstream and upstream of one session be easily recognized, let the service provider take the full control of one session's bi-direction traffic and apply the same traffic policy to them. It also let the correlation of traffic and then the recognition of various traffics easier. Based on such mechanism, the service provider can also offer Non-equivalent service in IPv6 end-to-end communication environment, especially in IPv6 based mobile internet circumstance. 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6146] M. Bagnulo, P. Matthews, I. van Beijnum," Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers" RFC 6146, April 2011 [RFC6333] A. Durand, R. Droms, J. Woodyatt, Y. Lee," Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC6333, August 2011 [RFC6437] S. Amante, B. Carpenter, S. Jiang, J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, November 2011. Expires January 3, 2015 [Page 10] Internet-Draft Flowlabel Reflection Requirement July 2014 [RFC6438] B. Carpenter, S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, November 2011. 8.2. Informative References [RFC 6294] Q. Hu, B. Carpenter, "TSurvey of Proposed Use Cases for the IPv6 Flow Label", RFC 6294, June 2011. [RFC 6436] S. Amante, B. Carpenter, S. Jiang," Rationale for Update to the IPv6 Flow Label Specification", RFC 6436, November 2011 [RFC 7098] B. Carpenter, S. Jiang, W. Tarreau," Using the IPv6 Flow Label for Load Balancing in Server Farms", RFC 7098, January 2014. 9. Acknowledgments TBD This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Aijun Wang China Telecom Coporation Limited Beijing Research Institute No.118,Xizhimenneidajie,Xicheng District,Beijing, 100035,China Phone: 86-10-58552347 Email: wangaj@ctbri.com.cn
Phone: Email: Expires January 3, 2015 [Page 11]