Rationale for Update to the IPv6 Flow Label Specification
RFC 6436
| Document | Type | RFC - Informational (November 2011; No errata) | |
|---|---|---|---|
| Authors | Sheng Jiang , Shane Amante , Brian Carpenter | ||
| Last updated | 2015-10-14 | ||
| Replaces | draft-carpenter-6man-flow-update | ||
| Stream | IETF | ||
| Formats | plain text html pdf htmlized bibtex | ||
| Stream | WG state | WG Document | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 6436 (Informational) | |
| Action Holders |
(None)
|
||
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Jari Arkko | ||
| IESG note | Brian Haberman (brian@innovationslab.net) is the document shepherd for this document. | ||
| Send notices to | (None) | ||
Internet Engineering Task Force (IETF) S. Amante
Request for Comments: 6436 Level 3
Category: Informational B. Carpenter
ISSN: 2070-1721 Univ. of Auckland
S. Jiang
Huawei
November 2011
Rationale for Update to the IPv6 Flow Label Specification
Abstract
Various published proposals for use of the IPv6 flow label are
incompatible with its original specification in RFC 3697.
Furthermore, very little practical use is made of the flow label,
partly due to some uncertainties about the correct interpretation of
the specification. This document discusses and motivates changes to
the specification in order to clarify it and to introduce some
additional flexibility.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6436.
Amante, et al. Informational [Page 1]
RFC 6436 Flow Label Update November 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
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Impact of Current Specification . . . . . . . . . . . . . . . 3
3. Changes to the Specification . . . . . . . . . . . . . . . . . 6
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. Informative References . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 12
1. Introduction
The flow label field in the IPv6 header was reserved but left
Experimental by [RFC2460], which mandates only that "Hosts or routers
that do not support the functions of the Flow Label field are
required to set the field to zero when originating a packet, pass the
field on unchanged when forwarding a packet, and ignore the field
when receiving a packet."
The flow label field was normatively specified by [RFC3697]. In
particular, we quote three rules from that RFC:
a. "The Flow Label value set by the source MUST be delivered
unchanged to the destination node(s)."
b. "IPv6 nodes MUST NOT assume any mathematical or other properties
of the Flow Label values assigned by source nodes."
c. "Router performance SHOULD NOT be dependent on the distribution
of the Flow Label values. Especially, the Flow Label bits alone
make poor material for a hash key."
Amante, et al. Informational [Page 2]
RFC 6436 Flow Label Update November 2011
Additionally, RFC 3697 does not define the method a host should adopt
by default to choose the value of the flow label, if no specific
method is in use. It was expected that various signaling methods
might be defined for agreeing on values of the flow label, but no
such methods have been standardized, except a pre-existing option in
RSVP [RFC2205].
The flow label is hardly used in practice in widespread IPv6
implementations, although some operating systems do set it
[McGann05]. To some extent, this is due to the main focus being on
basic deployment of IPv6, but the absence of a default method of
choosing the flow label value means that most host implementations
simply set it to zero. There is also anecdotal evidence that the
Show full document text