IPv6 Flow Label Reflection Requirement
draft-wang-v6ops-flow-label-refelction-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Aijun Wang | ||
| Last updated | 2014-07-03 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-v6ops-flow-label-refelction-00
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. <Sub-section 1.1 heading as appropriate> ...
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
<Wang> 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.
<Wang> 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:
<Wang> 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.
<Wang> 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 <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, 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
<Wang> 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:
<Wang> 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,
<Wang> 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.
<Wang> 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.
<Wang> 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
<Firstname> <Lastname>
<Affiliation>
<Address>
Phone: <optional>
Email: <Your email address>
<Wang> Expires January 3, 2015 [Page 11]