draft-ietf-6man-flow-3697bis-06.txt   draft-ietf-6man-flow-3697bis-07.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: January 12, 2012 Huawei Technologies Co., Ltd Expires: January 30, 2012 Huawei Technologies Co., Ltd
J. Rajahalme J. Rajahalme
Nokia Siemens Networks Nokia Siemens Networks
July 11, 2011 July 29, 2011
IPv6 Flow Label Specification IPv6 Flow Label Specification
draft-ietf-6man-flow-3697bis-06 draft-ietf-6man-flow-3697bis-07
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 January 12, 2012. This Internet-Draft will expire on January 30, 2012.
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 12 skipping to change at page 3, line 12
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
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 . . . . . . . . . . . . . . . . . . . 9
6.1. Covert Channel Risk . . . . . . . . . . . . . . . . . . . 9 6.1. Covert Channel Risk . . . . . . . . . . . . . . . . . . . 9
6.2. Theft and Denial of Service . . . . . . . . . . . . . . . 9 6.2. Theft and Denial of Service . . . . . . . . . . . . . . . 10
6.3. IPsec and Tunneling Interactions . . . . . . . . . . . . . 11 6.3. IPsec and Tunneling Interactions . . . . . . . . . . . . . 11
6.4. Security Filtering Interactions . . . . . . . . . . . . . 12 6.4. Security Filtering Interactions . . . . . . . . . . . . . 12
7. Differences from RFC 3697 . . . . . . . . . . . . . . . . . . 12 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] . . . . . . . . . . . . 13 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Example 20-bit Hash Function . . . . . . . . . . . . 15 Appendix A. Example 20-bit Hash Function . . . . . . . . . . . . 15
skipping to change at page 4, line 35 skipping to change at page 4, line 35
classification, where only IPv6 main header fields in fixed positions classification, where only IPv6 main header fields in fixed positions
are used. are used.
The flow label could be used in both stateless and stateful The flow label could be used in both stateless and stateful
scenarios. A stateless scenario is one where any node that processes scenarios. A stateless scenario is one where any node that processes
the flow label in any way does not need to store any information the flow label in any way does not need to store any information
about a flow before or after a packet has been processed. A stateful about a flow before or after a packet has been processed. A stateful
scenario is one where a node that processes the flow label value scenario is one where a node that processes the flow label value
needs to store information about the flow, including the flow label needs to store information about the flow, including the flow label
value. A stateful scenario might also require a signaling mechanism value. A stateful scenario might also require a signaling mechanism
to establish flow state in the network. to inform downstream nodes that the flow label is being used in a
certain way and to establish flow state in the network. For example,
RSVP [RFC2205] and GIST [RFC5971] can signal flow label values.
The flow label can be used most simply in stateless scenarios. This The flow label can be used most simply in stateless scenarios. This
specification concentrates on the stateless model and how it can be specification concentrates on the stateless model and how it can be
used as a default mechanism. Details of stateful models, signaling, used as a default mechanism. Details of stateful models, signaling,
specific flow state establishment methods and their related service specific flow state establishment methods and their related service
models are out of scope for this specification. The basic models are out of scope for this specification. The basic
requirement for stateful models is set forth in Section 4. requirement for stateful models is set forth in Section 4.
The minimum level of IPv6 flow support consists of labeling the The minimum level of IPv6 flow support consists of labeling the
flows. A specific goal is to enable and encourage the use of the flows. A specific goal is to enable and encourage the use of the
flow label for various forms of stateless load distribution, flow label for various forms of stateless load distribution,
especially across Equal Cost Multi-Path (EMCP) and/or Link especially across Equal Cost Multi-Path (EMCP) and/or Link
Aggregation Group (LAG) paths. ECMP and LAG are methods to bond Aggregation Group (LAG) paths. ECMP and LAG are methods to bond
together multiple physical links used to procure the required together multiple physical links used to procure the required
capacity necessary to carry an offered load greater than the capacity necessary to carry an offered load greater than the
bandwidth of an individual physical link. IPv6 source nodes SHOULD bandwidth of an individual physical link. Further details are in a
be able to label known flows (e.g., TCP connections, application separate document [I-D.ietf-6man-flow-ecmp]. IPv6 source nodes
streams), even if the node itself does not require any flow-specific SHOULD be able to label known flows (e.g., TCP connections,
treatment. Node requirements for stateless flow labeling are given application streams), even if the node itself does not require any
in Section 3. flow-specific treatment. Node requirements for stateless flow
labeling are given in Section 3.
This document replaces [RFC3697] and Section 6 and Appendix A of This document replaces [RFC3697] and Section 6 and Appendix A of
[RFC2460]. A rationale for the changes made is documented in [RFC2460]. A rationale for the changes made is documented in
[I-D.ietf-6man-flow-update]. The present document also includes a [I-D.ietf-6man-flow-update]. The present document also includes a
correction to [RFC2205] concerning the flow label. correction to [RFC2205] concerning the flow label.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
2. IPv6 Flow Label Specification 2. IPv6 Flow Label Specification
The 20-bit Flow Label field in the IPv6 header [RFC2460] is used by a The 20-bit Flow Label field in the IPv6 header [RFC2460] is used by a
node to label packets of a flow. A Flow Label of zero is used to node to label packets of a flow. A Flow Label of zero is used to
indicate packets that have not been labeled. Packet classifiers can indicate packets that have not been labeled. Packet classifiers can
use the triplet of Flow Label, Source Address, and Destination use the triplet of Flow Label, Source Address, and Destination
Address fields to identify which flow a particular packet belongs to. Address fields to identify which flow a particular packet belongs to.
Packets are processed in a flow-specific manner by nodes that are Packets are processed in a flow-specific manner by nodes that are
able to do so in a stateless manner, or that have been set up with able to do so in a stateless manner, or that have been set up with
skipping to change at page 5, line 47 skipping to change at page 6, line 5
probability distribution in which each value in a given range of probability distribution in which each value in a given range of
equally spaced values (such as a sequence of integers) is equally equally spaced values (such as a sequence of integers) is equally
likely to be chosen as the next value. The values in such a likely to be chosen as the next value. The values in such a
distribution exhibit both variability and unguessability. Thus, as distribution exhibit both variability and unguessability. Thus, as
specified below in Section 3, an approximation to a discrete uniform specified below in Section 3, an approximation to a discrete uniform
distribution is preferable as the source of flow label values. distribution is preferable as the source of flow label values.
Intentionally, there are no precise mathematical requirements placed Intentionally, there are no precise mathematical requirements placed
on the distribution or the method used to achieve such a on the distribution or the method used to achieve such a
distribution. distribution.
Once set to a non-zero value, the Flow Label MUST be delivered Once set to a non-zero value, the Flow Label is expected to be
unchanged to the destination node(s). That is, a forwarding node delivered unchanged to the destination node(s). A forwarding node
MUST NOT change the flow label value in an arriving packet if it is MUST either leave a non-zero flow label value unchanged, or change it
non-zero. A possible exception to this rule is if a security gateway only for compelling operational security reasons as described in
for operational security reasons changes a non-zero Flow Label value Section 6.1.
to a different non-zero value compliant with this RFC; see
Section 6.1 for details.
There is no way to verify whether a flow label has been modified en There is no way to verify whether a flow label has been modified en
route or whether it belongs to a uniform distribution. Therefore, no route or whether it belongs to a uniform distribution. Therefore, no
Internet-wide mechanism can depend mathematically on unmodified and Internet-wide mechanism can depend mathematically on unmodified and
uniformly distributed flow labels; they have a "best effort" quality. uniformly distributed flow labels; they have a "best effort" quality.
Implementers should be aware that the flow label is an unprotected Implementers should be aware that the flow label is an unprotected
field that could have been accidentally or intentionally changed en field that could have been accidentally or intentionally changed en
route (see Section 6). This leads to the following formal rule: route (see Section 6). This leads to the following formal rule:
o Forwarding nodes such as routers and load distributors MUST NOT o Forwarding nodes such as routers and load distributors MUST NOT
depend only on Flow Label values being uniformly distributed. In depend only on Flow Label values being uniformly distributed. In
any usage such as a hash key for load distribution, the Flow Label any usage such as a hash key for load distribution, the Flow Label
bits MUST be combined at least with bits from other sources within bits MUST be combined at least with bits from other sources within
the packet, so as to produce a constant hash value for each flow the packet, so as to produce a constant hash value for each flow
and a suitable distribution of hash values across flows. and a suitable distribution of hash values across flows.
Typically the other fields used will be some or all components of Typically the other fields used will be some or all components of
the usual 5-tuple. In this way, load distribution will still the usual 5-tuple. In this way, load distribution will still
occur even if the Flow Label values are poorly distributed. occur even if the Flow Label values are poorly distributed.
skipping to change at page 9, line 21 skipping to change at page 9, line 26
fixed position might assist traffic analysis and cryptoanalysis. fixed position might assist traffic analysis and cryptoanalysis.
The flow label is not protected in any way, even if IPsec The flow label is not protected in any way, even if IPsec
authentication [RFC4302] is in use, so it can be forged by an on-path authentication [RFC4302] is in use, so it can be forged by an on-path
attacker. Implementers are advised that any en-route change to the attacker. Implementers are advised that any en-route change to the
flow label value is undetectable. On the other hand, a uniformly flow label value is undetectable. On the other hand, a uniformly
distributed pseudo-random flow label cannot be readily guessed by an distributed pseudo-random flow label cannot be readily guessed by an
attacker; see [I-D.gont-6man-flowlabel-security] for further attacker; see [I-D.gont-6man-flowlabel-security] for further
discussion. If a hash algorithm is used, as suggested in Section 3, discussion. If a hash algorithm is used, as suggested in Section 3,
it SHOULD include a step that makes the flow-label value it SHOULD include a step that makes the flow-label value
significantly difficult to predict, even with knowledge of the significantly difficult to predict [RFC4086], even with knowledge of
algorithm being used. the algorithm being used.
6.1. Covert Channel Risk 6.1. Covert Channel Risk
The flow label could be used as a covert data channel, since The flow label could be used as a covert data channel, since
apparently pseudo-random flow label values could in fact consist of apparently pseudo-random flow label values could in fact consist of
covert data [NSA]. This could for example be achieved using a series covert data [NSA]. This could for example be achieved using a series
of otherwise innocuous UDP packets whose flow label values constitute of otherwise innocuous UDP packets whose flow label values constitute
a covert message, or by co-opting a TCP session to carry a covert a covert message, or by co-opting a TCP session to carry a covert
message in the flow labels of successive packets. Both of these message in the flow labels of successive packets. Both of these
could be recognised as suspicious - the first because isolated UDP could be recognised as suspicious - the first because isolated UDP
skipping to change at page 9, line 44 skipping to change at page 9, line 49
and the second because the flow label values in a given TCP session and the second because the flow label values in a given TCP session
should all be equal. However, other methods, such as co-opting the should all be equal. However, other methods, such as co-opting the
flow labels of occasional packets, might be rather hard to detect. flow labels of occasional packets, might be rather hard to detect.
In situations where the covert channel risk is considered In situations where the covert channel risk is considered
significant, the only certain defense is for a firewall to rewrite significant, the only certain defense is for a firewall to rewrite
non-zero flow labels. This would be an exceptional violation of the non-zero flow labels. This would be an exceptional violation of the
rule that the flow label, once set to a non-zero value, must not be rule that the flow label, once set to a non-zero value, must not be
changed. To preserve load distribution capability, such a firewall changed. To preserve load distribution capability, such a firewall
SHOULD rewrite labels by following the method described for a SHOULD rewrite labels by following the method described for a
forwarding node (see Section 3) and MUST NOT set non-zero flow labels forwarding node (see Section 3), as if the incoming label value were
to zero. zero, and MUST NOT set non-zero flow labels to zero. This behaviour
is nevertheless undesirable, since (as discussed in Section 3), only
source nodes have straightforward access to the complete 5-tuple.
6.2. Theft and Denial of Service 6.2. Theft and Denial of Service
Since the mapping of network traffic to flow-specific treatment is Since the mapping of network traffic to flow-specific treatment is
triggered by the IP addresses and Flow Label value of the IPv6 triggered by the IP addresses and Flow Label value of the IPv6
header, an adversary may be able to obtain unintended service by header, an adversary may be able to obtain a class of service that
modifying the IPv6 header or by injecting packets with false the network did not intend to provide by modifying the IPv6 header or
addresses and/or labels. Theft of service is not further discussed by injecting packets with false addresses and/or labels. A concrete
in this document, since it can only be analysed for specific stateful analysis of this threat is only possible for specific stateful
methods of using the flow label. However, a denial of service attack methods of signaling and using the flow label, which are out of scope
becomes possible in the stateless model when the modified or injected for this document. Clearly, a full analysis will be required when
traffic depletes the resources available to forward it and other any such method is specified, but in general networks SHOULD NOT make
traffic streams. If a DoS attack were undertaken against a given resource allocation decisions based on flow labels without some
Flow Label (or set of Flow Labels), then traffic containing an external means of assurance.
affected Flow Label might well experience worse-than-best-effort
network performance. A denial of service attack [RFC4732] becomes possible in the
stateless model when the modified or injected traffic depletes the
resources available to forward it and other traffic streams. If a
DoS attack were undertaken against a given Flow Label (or set of Flow
Labels), then traffic containing an affected Flow Label might well
experience worse-than-best-effort network performance.
Note that since the treatment of IP headers by nodes is typically Note that since the treatment of IP headers by nodes is typically
unverified, there is no guarantee that flow labels sent by a node are unverified, there is no guarantee that flow labels sent by a node are
set according to the recommendations in this document. A man-in-the- set according to the recommendations in this document. A man-in-the-
middle or injected-traffic denial of service attack specifically middle or injected-traffic denial of service attack specifically
directed at flow label handling would involve setting unusual flow directed at flow label handling would involve setting unusual flow
labels. For example, an attacker could set all flow labels reaching labels. For example, an attacker could set all flow labels reaching
a given router to the same arbitrary non-zero value, or could perform a given router to the same arbitrary non-zero value, or could perform
rapid cycling of flow label values such that the packets of a given rapid cycling of flow label values such that the packets of a given
flow will each have a different value. Either of these attacks would flow will each have a different value. Either of these attacks would
skipping to change at page 12, line 36 skipping to change at page 12, line 44
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 Jari Arkko, Ran Valuable comments and contributions were made by Jari Arkko, Ran
Atkinson, Fred Baker, Steve Blake, Remi Despres, Alan Ford, Fernando Atkinson, Fred Baker, Richard Barnes, Steve Blake, Remi Despres, Alan
Gont, Brian Haberman, Tony Hain, Joel Halpern, Qinwen Hu, Chris Ford, Fernando Gont, Brian Haberman, Tony Hain, Joel Halpern, Qinwen
Morrow, Thomas Narten, Mark Smith, Pascal Thubert, Iljitsch van Hu, Chris Morrow, Thomas Narten, Mark Smith, Pascal Thubert, Iljitsch
Beijnum, and other participants in the 6man working group. van 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 David Malone and Donald Eastlake gave additional input about hash
algorithms. 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-06: resolved IESG comments, 2011-07-29.
draft-ietf-6man-flow-3697bis-06: resolved IETF Last Call comments, draft-ietf-6man-flow-3697bis-06: resolved IETF Last Call comments,
2011-07-11. 2011-07-11.
draft-ietf-6man-flow-3697bis-05: resolved AD comments, improved hash draft-ietf-6man-flow-3697bis-05: resolved AD comments, improved hash
algorithm, 2011-06-29. 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,
2011-05-02: 2011-05-02:
o Clarified that the network layer view of flows is agnostic about o Clarified that the network layer view of flows is agnostic about
transport sessions. transport sessions.
o Honed the definition of stateless v stateful models. o Honed the definition of stateless v stateful models.
o Honed the text about using a pseudo-random function. o Honed the text about using a pseudo-random function.
o Moved material about violation of immutability to Security o Moved material about violation of immutability to Security
section, and rephrased accordingly. section, and rephrased accordingly.
o Dropped material about setting the flow label at a domain exit o Dropped material about setting the flow label at a domain exit
router: doesn't belong here now that we have dropped almost all router: doesn't belong here now that we have dropped almost all
the stateful text. the stateful text.
o Removed normative reference to draft-gont-6man-flowlabel-security. o Removed normative reference to draft-gont-6man-flowlabel-security.
o Removed the statement that a node that does not set or use the o Removed the statement that a node that does not set or use the
flow label must ignore it: this statement appears to be a no-op. flow label must ignore it: this statement appears to be a no-op.
o Added a summary of changes from RFC 3697. o Added a summary of changes from RFC 3697.
o Miscellaneous editorial fixes. o Miscellaneous editorial fixes.
draft-ietf-6man-flow-3697bis-02: update to remove most text about draft-ietf-6man-flow-3697bis-02: update to remove most text about
stateful methods, 2011-03-13 stateful methods, 2011-03-13
draft-ietf-6man-flow-3697bis-01: update after resolving 11 initial draft-ietf-6man-flow-3697bis-01: update after resolving 11 initial
skipping to change at page 14, line 20 skipping to change at page 14, line 34
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
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-ecmp]
Carpenter, B. and S. Amante, "Using the IPv6 flow label
for equal cost multipath routing and link aggregation in
tunnels", draft-ietf-6man-flow-ecmp-05 (work in progress),
July 2011.
[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-07 (work in progress), draft-ietf-6man-flow-update-07 (work in progress),
July 2011. July 2011.
[NSA] Potyraj, C., "Firewall Design Considerations for IPv6", [NSA] Potyraj, C., "Firewall Design Considerations for IPv6",
National Security Agency I733-041R-2007, 2007, National Security Agency I733-041R-2007, 2007,
<http://www.nsa.gov/ia/_files/ipv6/I733-041R-2007.pdf>. <http://www.nsa.gov/ia/_files/ipv6/I733-041R-2007.pdf>.
skipping to change at page 15, line 12 skipping to change at page 15, line 34
[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 [RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load
Sharing", RFC 4311, November 2005. Sharing", RFC 4311, November 2005.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
Service Considerations", RFC 4732, December 2006.
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", RFC 5971, October 2010.
[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. Example 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. It is not generate a flow label value from an IPv6 packet's 5-tuple. It is not
trivial to choose a suitable hash function, and it is expected that trivial to choose a suitable hash function, and it is expected that
 End of changes. 22 change blocks. 
40 lines changed or deleted 70 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/