draft-ietf-6man-flow-3697bis-04.txt   draft-ietf-6man-flow-3697bis-05.txt 
6MAN S. Amante 6MAN S. Amante
Internet-Draft Level 3 Internet-Draft Level 3
Obsoletes: 3697 (if approved) B. Carpenter Obsoletes: 3697 (if approved) B. Carpenter
Updates: 2205, 2460 (if approved) Univ. of Auckland Updates: 2205, 2460 (if approved) Univ. of Auckland
Intended status: Standards Track S. Jiang Intended status: Standards Track S. Jiang
Expires: November 12, 2011 Huawei Technologies Co., Ltd Expires: December 31, 2011 Huawei Technologies Co., Ltd
J. Rajahalme J. Rajahalme
Nokia Siemens Networks Nokia Siemens Networks
May 11, 2011 June 29, 2011
IPv6 Flow Label Specification IPv6 Flow Label Specification
draft-ietf-6man-flow-3697bis-04 draft-ietf-6man-flow-3697bis-05
Abstract Abstract
This document specifies the IPv6 Flow Label field and the minimum This document specifies the IPv6 Flow Label field and the minimum
requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding
labeled packets, and flow state establishment methods. Even when labeled packets, and flow state establishment methods. Even when
mentioned as examples of possible uses of the flow labeling, more mentioned as examples of possible uses of the flow labeling, more
detailed requirements for specific use cases are out of scope for detailed requirements for specific use cases are out of scope for
this document. this document.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 12, 2011. This Internet-Draft will expire on December 31, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 13 skipping to change at page 3, line 13
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. IPv6 Flow Label Specification . . . . . . . . . . . . . . . . 5 2. IPv6 Flow Label Specification . . . . . . . . . . . . . . . . 5
3. Flow Labeling Requirements in the Stateless Scenario . . . . . 6 3. Flow Labeling Requirements in the Stateless Scenario . . . . . 6
4. Flow State Establishment Requirements . . . . . . . . . . . . 8 4. Flow State Establishment Requirements . . . . . . . . . . . . 8
5. Essential correction to RFC 2205 . . . . . . . . . . . . . . . 8 5. Essential correction to RFC 2205 . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Covert Channel Risk . . . . . . . . . . . . . . . . . . . 8 6.1. Covert Channel Risk . . . . . . . . . . . . . . . . . . . 9
6.2. Theft and Denial of Service . . . . . . . . . . . . . . . 9 6.2. Theft and Denial of Service . . . . . . . . . . . . . . . 9
6.3. IPsec and Tunneling Interactions . . . . . . . . . . . . . 10 6.3. IPsec and Tunneling Interactions . . . . . . . . . . . . . 11
6.4. Security Filtering Interactions . . . . . . . . . . . . . 11 6.4. Security Filtering Interactions . . . . . . . . . . . . . 11
7. Differences from RFC 3697 . . . . . . . . . . . . . . . . . . 11 7. Differences from RFC 3697 . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 12 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Simple 20-bit Hash Function . . . . . . . . . . . . . 14 Appendix A. Example 20-bit Hash Function . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
From the viewpoint of the network layer, a flow is a sequence of From the viewpoint of the network layer, a flow is a sequence of
packets sent from a particular source to a particular unicast, packets sent from a particular source to a particular unicast,
anycast, or multicast destination that a node desires to label as a anycast, or multicast destination that a node desires to label as a
flow. From an upper layer viewpoint, a flow could consist of all flow. From an upper layer viewpoint, a flow could consist of all
packets in a specific transport connection or a media stream. packets in a specific transport connection or a media stream.
However, a flow is not necessarily 1:1 mapped to a transport However, a flow is not necessarily 1:1 mapped to a transport
skipping to change at page 6, line 45 skipping to change at page 6, line 45
3. Flow Labeling Requirements in the Stateless Scenario 3. Flow Labeling Requirements in the Stateless Scenario
This section defines the minimum requirements for methods of setting This section defines the minimum requirements for methods of setting
the flow label value within the stateless scenario of flow label the flow label value within the stateless scenario of flow label
usage. usage.
To enable Flow Label based classification, source nodes SHOULD assign To enable Flow Label based classification, source nodes SHOULD assign
each unrelated transport connection and application data stream to a each unrelated transport connection and application data stream to a
new flow. A typical definition of a flow for this purpose is any set new flow. A typical definition of a flow for this purpose is any set
of packets carrying the same 5-tuple {dest addr, source addr, of packets carrying the same 5-tuple {dest addr, source addr,
protocol, dest port, source port}. protocol, dest port, source port}. It should be noted that a source
node always has convenient and efficient access to this 5-tuple,
which is not always the case for nodes that subsequently forward the
packet.
It is desirable that flow label values should be uniformly It is desirable that flow label values should be uniformly
distributed to assist load distribution. It is therefore RECOMMENDED distributed to assist load distribution. It is therefore RECOMMENDED
that source hosts support the flow label by setting the flow label that source hosts support the flow label by setting the flow label
field for all packets of a given flow to the same value chosen from field for all packets of a given flow to the same value chosen from
an approximation to a discrete uniform distribution. Both stateful an approximation to a discrete uniform distribution. Both stateful
and stateless methods of assigning a value could be used, but it is and stateless methods of assigning a value could be used, but it is
outside the scope of this specification to mandate an algorithm. The outside the scope of this specification to mandate an algorithm. The
algorithm SHOULD ensure that the resulting flow label values are algorithm SHOULD ensure that the resulting flow label values are
unique with high probability. However, if two simultaneous flows are unique with high probability. However, if two simultaneous flows are
by chance assigned the same flow label value, and have the same by chance assigned the same flow label value, and have the same
source and destination addresses, it simply means that they will source and destination addresses, it simply means that they will
receive the same treatment throughout the network. As long as this receive the same treatment throughout the network. As long as this
is a low probability event, it will not significantly affect load is a low probability event, it will not significantly affect load
distribution. distribution.
A possible stateless algorithm is to use a suitable 20 bit hash of A possible stateless algorithm is to use a suitable 20 bit hash of
values from the IP packet's 5-tuple. A simple hash function is values from the IP packet's 5-tuple. A simple example hash function
described in Appendix A. is described in Appendix A.
An alternative approach is to to use a pseudo-random number generator An alternative approach is to to use a pseudo-random number generator
to assign a flow label value for a given transport session; such a to assign a flow label value for a given transport session; such a
method will require minimal local state to be kept at the source method will require minimal local state to be kept at the source
node, by recording the flow label associated with each transport node, by recording the flow label associated with each transport
socket. socket.
Viewed externally, either of these approaches will produce values Viewed externally, either of these approaches will produce values
that appear to be uniformly distributed and pseudo-random. that appear to be uniformly distributed and pseudo-random.
skipping to change at page 7, line 40 skipping to change at page 7, line 43
guess the next value. guess the next value.
A source node which does not otherwise set the flow label MUST set A source node which does not otherwise set the flow label MUST set
its value to zero. its value to zero.
A node that forwards a flow whose flow label value in arriving A node that forwards a flow whose flow label value in arriving
packets is zero MAY change the flow label value. In that case, it is packets is zero MAY change the flow label value. In that case, it is
RECOMMENDED that the forwarding node sets the flow label field for a RECOMMENDED that the forwarding node sets the flow label field for a
flow to a uniformly distributed value as just described for source flow to a uniformly distributed value as just described for source
nodes. nodes.
o The same considerations apply as to source hosts setting the flow o The same considerations apply as to source hosts setting the flow
label; in particular, the normal case is that a flow is defined by label; in particular, the preferred case is that a flow is defined
the 5-tuple. by the 5-tuple. However, there are cases in which the complete
o This option, if implemented, would presumably be used by first-hop 5-tuple for all packets is not readily available to a forwarding
or ingress routers. It might place a considerable per-packet node, in particular for fragmented packets. In such cases a flow
processing load on them, even if they adopted a stateless method can be defined by fewer IPv6 header fields, typically using only
of flow identification and label assignment. This is why the the 2-tuple {dest addr, source addr}. There are alternative
principal recommendation is that the source host should set the approaches that implementers could choose, such as:
label.
* A forwarding node might use the 5-tuple to define a flow
whenever possible, but use the 2-tuple when the complete
5-tuple is not available. In this case, unfragmented and
fragmented packets belonging to the same transport session
would receive different flow label values, altering the effect
of subsequent load distribution based on the flow label.
* A forwarding node might use the 2-tuple to define a flow in all
cases. In this case, subsequent load distribution would be
based only on IP addresses.
o This option, if implemented, would presumably be of value in
first-hop or ingress routers. It might place a considerable per-
packet processing load on them, even if they adopted a stateless
method of flow identification and label assignment. However, it
will not interfere with host-to-router load sharing [RFC4311].
Therefore, it needs to be under the control of network managers,
to avoid unwanted processing load and any other undesirable
effects. For this reason it MUST be a configurable option,
disabled by default.
The preceding rules taken together allow a given network to include The preceding rules taken together allow a given network to include
routers that set flow labels on behalf of hosts that do not do so. routers that set flow labels on behalf of hosts that do not do so.
The complications described explain why the principal recommendation
They also recommend that flow labels exported to the Internet are is that the source hosts should set the label.
always either zero or uniformly distributed.
4. Flow State Establishment Requirements 4. Flow State Establishment Requirements
A node that sets the flow label MAY also take part in a flow state A node that sets the flow label MAY also take part in a flow state
establishment method that results in assigning specific treatments to establishment method that results in assigning specific treatments to
specific flows, possibly including signaling. Any such method MUST specific flows, possibly including signaling. Any such method MUST
NOT disturb nodes taking part in the stateless scenario just NOT disturb nodes taking part in the stateless scenario just
described. Thus, any node that sets flow label values according to a described. Thus, any node that sets flow label values according to a
stateful scheme MUST choose labels that conform to Section 3 of the stateful scheme MUST choose labels that conform to Section 3 of the
present specification. Further details are not discussed in this present specification. Further details are not discussed in this
skipping to change at page 12, line 11 skipping to change at page 12, line 28
firewalls. firewalls.
For further details see [I-D.ietf-6man-flow-update]. For further details see [I-D.ietf-6man-flow-update].
8. IANA Considerations 8. IANA Considerations
This document requests no action by IANA. This document requests no action by IANA.
9. Acknowledgements 9. Acknowledgements
Valuable comments and contributions were made by Ran Atkinson, Fred Valuable comments and contributions were made by Jari Arkko, Ran
Baker, Steve Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Atkinson, Fred Baker, Steve Blake, Remi Despres, Alan Ford, Fernando
Haberman, Tony Hain, Joel Halpern, Qinwen Hu, Chris Morrow, Thomas Gont, Brian Haberman, Tony Hain, Joel Halpern, Qinwen Hu, Chris
Narten, Mark Smith, Pascal Thubert, Iljitsch van Beijnum, and other Morrow, Thomas Narten, Mark Smith, Pascal Thubert, Iljitsch van
participants in the 6man working group. Beijnum, and other participants in the 6man working group.
Cristian Calude suggested the von Neumann algorithm in Appendix A. Cristian Calude suggested the von Neumann algorithm in Appendix A.
David Malone and Donald Eastlake gave additional input about hash
algorithms.
Steve Deering and Alex Conta were co-authors of RFC 3697, on which Steve Deering and Alex Conta were co-authors of RFC 3697, on which
this document is based. this document is based.
Contributors to the original development of RFC 3697 included Ran Contributors to the original development of RFC 3697 included Ran
Atkinson, Steve Blake, Jim Bound, Francis Dupont, Robert Elz, Tony Atkinson, Steve Blake, Jim Bound, Francis Dupont, Robert Elz, Tony
Hain, Robert Hancock, Bob Hinden, Christian Huitema, Frank Hain, Robert Hancock, Bob Hinden, Christian Huitema, Frank
Kastenholz, Thomas Narten, Charles Perkins, Pekka Savola, Hesham Kastenholz, Thomas Narten, Charles Perkins, Pekka Savola, Hesham
Soliman, Michael Thomas, Margaret Wasserman, and Alex Zinin. Soliman, Michael Thomas, Margaret Wasserman, and Alex Zinin.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
10. Change log [RFC Editor: Please remove] 10. Change log [RFC Editor: Please remove]
draft-ietf-6man-flow-3697bis-05: resolved AD comments, improved hash
algorithm, 2011-06-29.
draft-ietf-6man-flow-3697bis-04: update to resolve further WG draft-ietf-6man-flow-3697bis-04: update to resolve further WG
comments, 2011-05-11: comments, 2011-05-11:
o Suggested a specific hash algorithm to generate a flow label. o Suggested a specific hash algorithm to generate a flow label.
o Removed reference to stateful domain. o Removed reference to stateful domain.
o Added text about covert channel and tuned text about firewall o Added text about covert channel and tuned text about firewall
behavior; removed the confusing word "immutable". behavior; removed the confusing word "immutable".
o Added that Section 6 of RFC 2460 is replaced. o Added that Section 6 of RFC 2460 is replaced.
o Editorial fixes. o Editorial fixes.
draft-ietf-6man-flow-3697bis-03: update to resolve WGLC comments, draft-ietf-6man-flow-3697bis-03: update to resolve WGLC comments,
skipping to change at page 13, line 47 skipping to change at page 14, line 22
11.2. Informative References 11.2. Informative References
[I-D.gont-6man-flowlabel-security] [I-D.gont-6man-flowlabel-security]
Gont, F., "Security Assessment of the IPv6 Flow Label", Gont, F., "Security Assessment of the IPv6 Flow Label",
draft-gont-6man-flowlabel-security-01 (work in progress), draft-gont-6man-flowlabel-security-01 (work in progress),
November 2010. November 2010.
[I-D.ietf-6man-flow-update] [I-D.ietf-6man-flow-update]
Amante, S., Carpenter, B., and S. Jiang, "Rationale for Amante, S., Carpenter, B., and S. Jiang, "Rationale for
update to the IPv6 flow label specification", update to the IPv6 flow label specification",
draft-ietf-6man-flow-update-05 (work in progress), draft-ietf-6man-flow-update-06 (work in progress),
May 2011. May 2011.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
skipping to change at page 14, line 21 skipping to change at page 14, line 44
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load
Sharing", RFC 4311, November 2005.
[vonNeumann] [vonNeumann]
von Neumann, J., "Various techniques used in connection von Neumann, J., "Various techniques used in connection
with random digits", National Bureau of Standards Applied with random digits", National Bureau of Standards Applied
Math Series 12, 36-38, 1951. Math Series 12, 36-38, 1951.
Appendix A. Simple 20-bit Hash Function Appendix A. Example 20-bit Hash Function
As mentioned in Section 3, a stateless hash function may be used to As mentioned in Section 3, a stateless hash function may be used to
generate a flow label value from an IPv6 packet's 5-tuple. An generate a flow label value from an IPv6 packet's 5-tuple. It is not
example function, based on an algorithm by von Neumann known to trivial to choose a suitable hash function, and it is expected that
produce an approximately uniform distribution [vonNeumann], is as extensive practical experience will be required to identify the best
follows: choices. An example function, based on an algorithm by von Neumann
known to produce an approximately uniform distribution [vonNeumann],
follows. For each packet for which a flow label must be generated,
execute the following steps:
1. Split the destination and source addresses into two 64 bit values 1. Split the destination and source addresses into two 64 bit values
each, thus transforming the 5-tuple into a 7-tuple. each, thus transforming the 5-tuple into a 7-tuple.
2. Add the seven components together using unsigned 64 bit 2. Add the following five components together using unsigned 64 bit
arithmetic, discarding any carry bits. arithmetic, discarding any carry bits: both parts of the source
address, both parts of the destination address, and the protocol
number.
3. Apply the von Neumann algorithm to the resulting string of 64 3. Apply the von Neumann algorithm to the resulting string of 64
bits: bits:
1. Starting at the least significant end, select two bits. 1. Starting at the least significant end, select two bits.
2. If the two bits are 00 or 11, discard them. 2. If the two bits are 00 or 11, discard them.
3. If the two bits are 01, output a 0 bit. 3. If the two bits are 01, output a 0 bit.
4. If the two bits are 10, output a 1 bit. 4. If the two bits are 10, output a 1 bit.
5. Repeat with the next two bits in the input 64 bit string. 5. Repeat with the next two bits in the input 64 bit string.
6. Stop when 20 bits have been output (or when the 64 bit string 6. Stop when 16 bits have been output (or when the 64 bit string
is exhausted). is exhausted).
4. In the highly unlikely event that the result is exactly zero, set 4. Add the two port numbers to the resulting 16 bit number.
5. Shift the resulting value 4 bits left and mask with 0xfffff.
6. In the highly unlikely event that the result is exactly zero, set
the flow label arbitrarily to the value 1. the flow label arbitrarily to the value 1.
Note that this simple example does not include any form of
obfuscation.
Authors' Addresses Authors' Addresses
Shane Amante Shane Amante
Level 3 Communications, LLC Level 3 Communications, LLC
1025 Eldorado Blvd 1025 Eldorado Blvd
Broomfield, CO 80021 Broomfield, CO 80021
USA USA
Email: shane@level3.net Email: shane@level3.net
Brian Carpenter Brian Carpenter
Department of Computer Science Department of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland, 1142 Auckland, 1142
New Zealand New Zealand
Email: brian.e.carpenter@gmail.com Email: brian.e.carpenter@gmail.com
Sheng Jiang Sheng Jiang
 End of changes. 26 change blocks. 
40 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/