One document matched: draft-donley-6man-flowlabel-transport-sig-00.txt
Network Working Group C. Donley
Internet-Draft CableLabs
Intended status: Experimental K. Erichsen
Expires: September 2, 2010 Time Warner Cable
March 1, 2010
Using the Flow Label for Transport Signaling
draft-donley-6man-flowlabel-transport-sig-00
Abstract
This document extends the use of the IPv6 Flow Label to include
transport header and port information. The inclusion of these
details allows for the application of Quality of Service (QoS)
classification and prioritization, and permits hardware acceleration
of IP traffic flows encapsulated within other protocols such as Dual-
Stack Lite, Generic Routing Encapsulation (GRE) and Layer 2 Tunneling
Protocol version 3 (L2TPv3).
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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 September 2, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Donley & Erichsen Expires September 2, 2010 [Page 1]
Internet-Draft flowlabel-transport-sig March 2010
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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Using the IPv6 Flow Label for Transport Signaling . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Donley & Erichsen Expires September 2, 2010 [Page 2]
Internet-Draft flowlabel-transport-sig March 2010
1. Introduction
As described in [RFC2460], the IP version 6 (IPv6) Main Header may
include IPv6 Extension Headers in any order between the IPv6 Main
Header and the upper layer protocol header. This poses a problem for
some routers, many deep packet inspection (DPI) appliances, and most
residential/small office devices such as home gateways. These
devices may have difficulty identifying the upper layer transport
protocol and/or port number for special handling of the packet in
hardware.
By providing a pointer to expose the transport header and port number
directly within the Main Header, an implementer may more easily
support hardware-assisted packet forwarding and prioritization of
flows based on transport information. For example, during the
transition from IPv4 to IPv6, it is likely that IP traffic will be
encapsulated inside of IPv6 at a home gateway, thereby inserting an
additional Extension Header and further obscuring transport protocol
information from the forwarding engine. The QoS advantage is
compounded as additional Extension Headers are added, such as an
Encapsulating Security Payload (ESP) header for IPSEC VPNs. The IPv6
main header's Flow Label field and its relation to the other fields
in the IPv6 header are detailed in Figure 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 IPv6 Main Header
Donley & Erichsen Expires September 2, 2010 [Page 3]
Internet-Draft flowlabel-transport-sig March 2010
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. Packet
classifiers can use the triplet of Flow Label, Source Address, and
Destination Address fields to identify packets belonging to a
particular flow. [RFC3697] assumes that Flow Labels uniquely
identify a flow and that they do not contain mathematical or other
properties; however, as allowed by [I-D.carpenter-6man-flow-update],
if protocol and port information are included in the Flow Label,
routers can use the Flow Label for hardware-accelerated forwarding
and packet classification.
Donley & Erichsen Expires September 2, 2010 [Page 4]
Internet-Draft flowlabel-transport-sig March 2010
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 September 2, 2010 [Page 5]
Internet-Draft flowlabel-transport-sig March 2010
3. Using the IPv6 Flow Label for Transport Signaling
The IPv6 Main Header contains a Next Header field that points to the
Extended Header following the Main Header, as shown in Figure 1.
Each Extended Header that may be present contains its own Next Header
field, providing a chain to each Extended Header until the last
Extended Header in the sequence is populated with a Next Header value
of "no next header".
The IPv6 Main Header also contains a Flow Label field that is
intended to be used for QoS classification. To enhance Flow Label
based classification, encapsulating routers MUST set the most
significant bit to 1 to indicate [I-D.carpenter-6man-flow-update]
behavior, and SHOULD include the 8-bit IANA-assigned protocol number
and the low order 10 bits of the IANA-assigned port number (if
applicable) of the unencapsulated IP packet in the Flow Label field
of the encapsulating IPv6 header, as shown in Figure 2. Such routers
SHOULD set the P bit to 0 to indicate that the port number is the
destination port or 1 to indicate that the port number is the source
port.
Whenever the Next Header field in the IPv6 Main Header does not
contain the transport header information (e.g. TCP, UDP), as would
be the case when IP in IP encapsulation is configured, the Flow Label
will expose the transport protocol and port information directly
within the IPv6 Main Header, allowing classification on any router
implementing Flow Label handling while providing performance
enhancement on most commodity-based routers.
Routers along the transmission path can classify traffic based on the
Flow Label either in its entirety or by using a wildcard mask to
consider only certain bits such as the representation of the
transport protocol or port number.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|Transport Proto|P| Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 IPv6 Flow Label
L - Set to 1 to indicate that the flow label follows
[I-D.carpenter-6man-flow-update], rather than [RFC3697] behavior.
Transport Protocol - 8-bit IANA-defined protocol [IANAProtocol]
P - Set to 0 to indicate Destination Port or 1 to indicate Source
Donley & Erichsen Expires September 2, 2010 [Page 6]
Internet-Draft flowlabel-transport-sig March 2010
Port
Port Number - the lower 10 bits of the 16-bit IANA-defined port
number [IANAPort] (e.g. the modulo(1024) representation of the port
number). If the P bit is set to 0, the port number MUST be set to
the segment's destination port. If the P bit is set to 1, the port
number MUST be set to the segment's source port. If the transport
protocol does not use ports, these bits MAY be set to a pseudo-random
sequence, as described in [RFC3697].
Donley & Erichsen Expires September 2, 2010 [Page 7]
Internet-Draft flowlabel-transport-sig March 2010
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 September 2, 2010 [Page 8]
Internet-Draft flowlabel-transport-sig March 2010
5. IANA Considerations
There are no IANA considerations.
Donley & Erichsen Expires September 2, 2010 [Page 9]
Internet-Draft flowlabel-transport-sig March 2010
6. Normative References
[I-D.carpenter-6man-flow-update]
Carpenter, B. and S. Jiang, "Update to the IPv6 flow label
specification", draft-carpenter-6man-flow-update-00 (work
in progress), February 2010.
[IANAPort]
Internet Assigned Numbers Authority (IANA), "Port Numbers
Registry", http://www.iana.org/assignments/port-numbers.
[IANAProtocol]
Internet Assigned Numbers Authority (IANA), "Protocol
Registry",
http://www.iana.org/assignments/protocol-numbers.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004.
Donley & Erichsen Expires September 2, 2010 [Page 10]
Internet-Draft flowlabel-transport-sig March 2010
Appendix A. Acknowledgements
Thanks to the following people for their guidance and feedback:
Lee Howard
Andy Shappell
Chris Williams
Donley & Erichsen Expires September 2, 2010 [Page 11]
Internet-Draft flowlabel-transport-sig March 2010
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 September 2, 2010 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 01:48:20 |