Network Working Group C. Donley
Internet-Draft CableLabs
Intended status: Experimental K. Erichsen
Expires: July 10, 2011 Time Warner Cable
January 6, 2011
Using the Flow Label with Dual-Stack Lite
draft-donley-softwire-dslite-flowlabel-01
Abstract
This document extends the use of Dual-Stack Lite to identify discrete
traffic flows using the IPv6 Flow Label. The identification of
discrete traffic flows allows for the application of Quality of
Service (QoS) classification and prioritization of traffic traversing
Dual-Stack Lite tunnels.
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 July 10, 2011.
Copyright Notice
Copyright (c) 2011 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 Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Donley & Erichsen Expires July 10, 2011 [Page 1]
Internet-Draft dslite-flowlabel January 2011
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Allowing Dual-Stack Lite QoS Using the IPv6 Flow Label . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Donley & Erichsen Expires July 10, 2011 [Page 2]
Internet-Draft dslite-flowlabel January 2011
1. Introduction
Dual-Stack Lite [I-D.ietf-softwire-dual-stack-lite] describes a
method for transitioning to IPv6 by encapsulating IPv4 traffic inside
an IPv6 tunnel and translating it at the Address Family Translation
Router. By encapsulating such traffic, DS-Lite obfuscates the IPv4
5-tuple behind the IPv6 header, thereby making it difficult to
classify IPv4 traffic. To QoS classifiers, all IPv4 traffic is
encapsulated as an IP-in-IP tunnel using the same IPv6 source
address, destination address, and protocol. There is no
differentiation for IPv4 traffic requiring differentiated quality of
service such as Voice over IP.
This lack of differentiation can be problematic for traffic types
where prioritization is desired, and service providers need a way to
classify such traffic. For example, it is common practice to provide
QoS for voice traffic. In a cable environment, such classification/
prioritization is performed using PacketCable Multimedia (PCMM).
PCMM identifies traffic at an application manager (AM)/policy
server(PS) and notifies the Cable Modem Termination System (CMTS) to
provide QoS using DOCSIS classifiers. However, in a Dual-Stack Lite
environment, the AM/PS is unable to identify characteristics of a
particular IPv4 traffic flow and apply QoS using DOCSIS classifiers.
This problem is applicable to other QoS systems, as well, including
access-list-based classifiers.
This document proposes a method of identifying individual traffic
flows encapsulated using DS-Lite using the IPv6 Flow Label.
Donley & Erichsen Expires July 10, 2011 [Page 3]
Internet-Draft dslite-flowlabel January 2011
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].
Donley & Erichsen Expires July 10, 2011 [Page 4]
Internet-Draft dslite-flowlabel January 2011
3. Allowing Dual-Stack Lite QoS Using the IPv6 Flow Label
As described in [RFC3697], a flow is a sequence of packets sent from
a particular source to a particular unicast, anycast, or multicast
destination that the source desires to label as a flow. IPv6 uses
the Flow Label in the IPv6 header to identify such flows. In cases
where the Flow Label field uniquely identifies such traffic flows,
packet classifiers can use the triplet of Flow Label, Source Address,
and Destination Address fields to identify packets belonging to a
particular flow.
As described in [I-D.ietf-softwire-dual-stack-lite], traffic is
encapsulated between the Basic BroadBand Bridging (B4) element and
Address Family Transition Router (AFTR). Both the B4 and AFTR are
aware of the 5-tuple of the encapsulated IPv4 traffic. Thus, both
the B4 and AFTR are capable of identifying IPv4 traffic flows and
setting the IPv6 Flow Label for the DS-Lite tunnel accordingly. By
populating the Flow Label field in DS-Lite tunnels, service providers
can use Flow Label classifiers to provide priority treatment to
appropriate traffic flows.
The B4 SHOULD uniquely set the IPv6 Flow Label to a non-zero value
per IPv4 traffic flow in accordance with [RFC3697] and
[I-D.ietf-6man-flow-update]. That is, the B4 SHOULD identify IPv4
traffic flows by the IPv4 5-tuple of IPv4 Source Address, Destination
Address, Protocol, Source Port, and Destination Port. The B4 SHOULD
construct a unique flow label based on the IPv4 5-tuple and apply it
to the IPv6 header attached to that flow as it is encapsulated inside
a DS-Lite tunnel. If the B4 sets the IPv6 Flow-Label to a non-zero
value, it MUST use the same Flow Label value for other IPv4 packets
belonging to the same flow (as determined by the IPv4 5-tuple).
The AFTR SHOULD uniquely set the IPv6 Flow Label per IPv4 traffic
flow in accordance with [RFC3697] and [I-D.ietf-6man-flow-update].
That is, the AFTR SHOULD identify IPv4 traffic flows to be sent to
the B4 by the IPv4 5-tuple of IPv4 Source Address, Destination
Address, Protocol, Source Port, and Destination Port after completing
Network Address Translation. The AFTR SHOULD construct a unique flow
label based on the IPv4 5-tuple and apply it to the IPv6 header
attached to that flow as it is encapsulated inside a DS-Lite tunnel.
If the AFTR sets the IPv6 Flow-Label to a non-zero value, it MUST use
the same Flow Label value for other IPv4 packets belonging to the
same flow (as determined by the IPv4 5-tuple).
The exact mechanism for constructing the Flow Label is not specified,
except as per [RFC3697] and [I-D.ietf-6man-flow-update].
Implementations could use a 20-bit hash of the IPv4 5-tuple such that
subsequent IPv4 packets with the same 5-tuple will receive the same
Donley & Erichsen Expires July 10, 2011 [Page 5]
Internet-Draft dslite-flowlabel January 2011
flow label.
As directed by [RFC3697] and [I-D.ietf-6man-flow-update], Flow Label
information is only significant to the B4 or AFTR transmitting the
particular DS-Lite flow. Since the Flow Label will be consistently
applied to all packets in the flow, however, intermediate devices
between the B4 and AFTR can use the Flow Label in packet classifiers
to provide quality of service treatment to the flow.
Donley & Erichsen Expires July 10, 2011 [Page 6]
Internet-Draft dslite-flowlabel January 2011
4. Security Considerations
Security considerations are described in [RFC3697], section 5. The
flow label is not protected, and could be modified by an on-path
attacker. However, the impact of any such modification would be
limited to the QoS treatment of the modified packet(s).
Donley & Erichsen Expires July 10, 2011 [Page 7]
Internet-Draft dslite-flowlabel January 2011
5. IANA Considerations
There are no IANA considerations.
Donley & Erichsen Expires July 10, 2011 [Page 8]
Internet-Draft dslite-flowlabel January 2011
6. Normative References
[I-D.ietf-6man-flow-update]
Amante, S., Carpenter, B., and S. Jiang, "Update to the
IPv6 flow label specification",
draft-ietf-6man-flow-update-00 (work in progress),
December 2010.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work
in progress), August 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004.
Donley & Erichsen Expires July 10, 2011 [Page 9]
Internet-Draft dslite-flowlabel January 2011
Appendix A. Acknowledgements
Thanks to the following people for their guidance and feedback:
Lee Howard
Andy Shappell
Chris Williams
Donley & Erichsen Expires July 10, 2011 [Page 10]
Internet-Draft dslite-flowlabel January 2011
Authors' Addresses
Chris Donley
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Email: c.donley@cablelabs.com
Kirk Erichsen
Time Warner Cable
12101 Airport Way
Broomfield, CO 80021
USA
Email: kirk.erichsen@twcable.com
Donley & Erichsen Expires July 10, 2011 [Page 11]