Internet DRAFT - draft-wang-v6ops-flow-label-refelction
draft-wang-v6ops-flow-label-refelction
Network Working Group A. Wang
Internet Draft China Telecom
Intended status: Standard Track S. Jiang
Expires: January 21, 2015 Huawei Technologies Co., Ltd
July 20, 2014
IPv6 Flow Label Reflection
draft-wang-v6ops-flow-label-refelction-01.txt
Abstract
IPv6 Flow Label field in IPv6 packet header is designed to
differentiate the various traffic flow session within network. The
current definition of IPv6 Flow Label focuses mainly on how the
packet source forms the value of this field and how the forwarder
in-path treats it. There is no analysis on the relation between the
flow label from source nodes and its corresponding value in return
packet. This draft analyzes the requirements for flow label
reflection between the upstream session and the corresponding
downstream session. Based on the analysis, the flow label reflection
mechanism is proposed in this document.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 21, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang Expires January 15, 2015 [Page 1]
Internet-Draft Flow Label Reflection July 2014
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
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction ................................................ 3
2. Conventions used in this document ........................... 3
3. Flow Label Reflection Requirements .......................... 3
3.1. Summary of the current usage for IPv6 Flow Label ....... 3
3.2. Requirements of Flow Label Reflection .................. 4
3.2.1. DS-Lite deployment Scenario ....................... 4
3.2.2. Deep Packet Inspection Scenario ................... 6
3.2.3. End to End QoS Deployment Scenario within Mobile
Network .................................................. 6
4. Recommendation and Benefit of Flow Label Reflection Mechanism 7
5. Detail Process for Flow Label Reflection .................... 8
5.1.1. DS-Lite environment ............................... 8
5.1.2. NAT64 environment ................................. 8
5.1.3. End to End IPv6 communication environment.......... 9
5.2. Influence to the current usage of IPv6 Flow Label ..... 9
6. Conclusions ................................................. 9
7. Security Considerations ..................................... 9
8. IANA Considerations ........................................ 10
9. Acknowledgments ............................................ 10
10. References ................................................ 10
10.1. Normative References ................................. 10
10.2. Informative References ............................... 10
<Wang> Expires January 15, 2015 [Page 2]
Internet-Draft Flow Label Reflection July 2014
1. Introduction
IPv6 flow label [RFC6437] 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 [RFC6438]
or the server load balance [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 the requirements of the flow label
reflection mechanism in several scenarios. There is administration
benefit for keeping flow label unchanged in the downstream and
upstream of one IPv6 traffic session. The details IPv6 flow label
reflect process in DS-Lite, NAT64 [RFC6146] and IPv6 end-to-end
communication environment are also given.
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 [RFC2119].
3. Flow Label Reflection Requirements
3.1. Summary of the current usage for IPv6 Flow Label
[RFC6438] 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. [RFC7098] 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.
<Wang> Expires January 15, 2015 [Page 3]
Internet-Draft Flow Label Reflection July 2014
Following paragraph analyzes several scenarios that require IPv6
flow label reflection mechanism. Other use case needs to further
study.
3.2. 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.
3.2.1. DS-Lite deployment Scenario
During IPv6 transition stage, some Internet Service Providers the
DS-Lite [RFC6333] 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, the Internet Service Providers 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:
<Wang> Expires January 15, 2015 [Page 4]
Internet-Draft Flow Label Reflection 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 [RFC6333] 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
[RFC6333] 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.
<Wang> Expires January 15, 2015 [Page 5]
Internet-Draft Flow Label Reflection July 2014
3.2.2. Deep Packet Inspection Scenario
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 <IPv6 source address, IPv6
destination address, flow label> 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 and then to different DPI devices(DPI-A or DPI-B),
thus increases the difficult of traffic recognition that is based on
the correlation of downstream and upstream of one session.
CR
// \\
// \\\-----DPI-A
// \\\
// \-----DPI-B
// \\\
// \ \
BRAS BRAS
Figure-2 Deep Packet Inspection Deployment Scenarios in IPv6-Only
Environment
3.2.3. End to End QoS Deployment Scenario within Mobile Network
Under the mobile network 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 networks, 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 UE and PCRF have the
same mapping algorithm, the QCI parameters can be mapped to the IPv6
flow label in underlying transport layer. By keeping the value of
IPv6 flow label in upstream and downstream same, and based on the
mapping information and policy from PCRF, the transport devices can
treat the required flow different very easily.
<Wang> Expires January 15, 2015 [Page 6]
Internet-Draft Flow Label Reflection July 2014
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 Network
4. Recommendation and Benefit of Flow Label Reflection Mechanism
Based on the scenarios described above, we propose the following
solution:
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 network environment.
3. The generation method of IPv6 flow label in source IPv6 node and
the forward behavior are still recommended to follow the
<Wang> Expires January 15, 2015 [Page 7]
Internet-Draft Flow Label Reflection July 2014
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.
5. Detail Process for Flow Label Reflection
5.1.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 decapsulation 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,
set the IPv6 flow label of returned encapsulated IPv6 packet to
the previous stored value.
5.1.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
<Wang> Expires January 15, 2015 [Page 8]
Internet-Draft Flow Label Reflection July 2014
label in the above mentioned mapping table, put it in the
header of downstream converted IPv6 traffic.
5.1.3. End to End IPv6 communication environment
It is simpler 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.
5.2. Influence to the current usage of IPv6 Flow Label
There is no any influence to the current proposed usages of IPv6
flow label.
6. 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 the IPv6-based mobile network environment.
7. 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.
<Wang> Expires January 15, 2015 [Page 9]
Internet-Draft Flow Label Reflection July 2014
8. IANA Considerations
There is no additional IANA requirement for this requirement.
9. Acknowledgments
Valuable comments were received from Brian Carpenter.
This document was prepared using 2-Word-v2.0.template.dot.
10. References
10.1. Normative References
[RFC2119] 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.
[RFC6438] B. Carpenter, S. Amante, "Using the IPv6 Flow Label for
Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, November 2011.
10.2. Informative References
[RFC7098] B. Carpenter, S. Jiang, W. Tarreau,"Using the IPv6 Flow
Label for Load Balancing in Server Farms", RFC 7098,
January 2014.
<Wang> Expires January 15, 2015 [Page 10]
Internet-Draft Flow Label Reflection July 2014
Authors' Addresses
Aijun Wang
China Telecom Cooperation Limited Beijing Research Institute
No.118, Xizhimenneidajie, Xicheng District, Beijing, 100035, China
Phone: 86-10-58552347
Email: wangaj@ctbri.com.cn
Jiang Sheng
Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
P.R. China
Email: jiangsheng@huawei.com
<Wang> Expires January 15, 2015 [Page 11]
