draft-ietf-6man-flow-update-01.txt   draft-ietf-6man-flow-update-02.txt 
6MAN S. Amante 6MAN S. Amante
Internet-Draft Level 3 Internet-Draft Level 3
Intended status: Informational B. Carpenter Intended status: Informational B. Carpenter
Expires: July 14, 2011 Univ. of Auckland Expires: August 4, 2011 Univ. of Auckland
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
January 10, 2011 January 31, 2011
Update to the IPv6 flow label specification Rationale for update to the IPv6 flow label specification
draft-ietf-6man-flow-update-01 draft-ietf-6man-flow-update-02
Abstract Abstract
Various published proposals for use of the IPv6 flow label are Various published proposals for use of the IPv6 flow label are
incompatible with its existing specification in RFC 3697. incompatible with its original specification in RFC 3697.
Furthermore, very little practical use is made of the flow label, Furthermore, very little practical use is made of the flow label,
partly due to some uncertainties about the correct interpretation of partly due to some uncertainties about the correct interpretation of
the specification. This document describes and motivates proposed the specification. This document discusses and motivates changes to
changes to the specification in order to clarify it, making it clear the specification in order to clarify it, and to introduce some
what types of usage are possible, and to introduce some additional additional flexibility.
flexibility. It does not formally update RFC 3697.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 14, 2011. This Internet-Draft will expire on August 1, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Impact of current specification . . . . . . . . . . . . . . . 4 2. Impact of current specification . . . . . . . . . . . . . . . 4
3. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 6 3. Changes to specification . . . . . . . . . . . . . . . . . . . 6
4. Proposed changes to specification . . . . . . . . . . . . . . 6 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 10
Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The flow label field in the IPv6 header was reserved but left The flow label field in the IPv6 header was reserved but left
experimental by [RFC2460], which mandates only that "Hosts or routers experimental by [RFC2460], which mandates only that "Hosts or routers
that do not support the functions of the Flow Label field are 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 required to set the field to zero when originating a packet, pass the
field on unchanged when forwarding a packet, and ignore the field field on unchanged when forwarding a packet, and ignore the field
when receiving a packet." when receiving a packet."
skipping to change at page 3, line 46 skipping to change at page 3, line 46
implementations. To some extent this is due to the main focus being implementations. To some extent this is due to the main focus being
on basic deployment of IPv6, but the absence of a default method of on basic deployment of IPv6, but the absence of a default method of
choosing the flow label value means that most host implementations choosing the flow label value means that most host implementations
simply set it to zero. There is also anecdotal evidence that the simply set it to zero. There is also anecdotal evidence that the
rules quoted above have led to uncertainty about exactly what is rules quoted above have led to uncertainty about exactly what is
possible. Furthermore, various use cases have been proposed that possible. Furthermore, various use cases have been proposed that
infringe one or another of the rules. None of these proposals has infringe one or another of the rules. None of these proposals has
been accepted as a standard and in practice there is no significant been accepted as a standard and in practice there is no significant
deployment of any mechanism to set the flow label. deployment of any mechanism to set the flow label.
The intention of this document is to explain this in more detail and The intention of this document is to explain this situation in more
to propose changes to RFC 3697 intended to remove the uncertainties detail and to motivate changes to RFC 3697 intended to remove the
and encourage active usage of the flow label. It does not formally uncertainties and encourage active usage of the flow label. It does
update RFC 3697. not formally update RFC 3697.
2. Impact of current specification 2. Impact of current specification
Rule (a) makes it impossible for the routing system to use the flow Rule (a) makes it impossible for the routing system to use the flow
label as any form of dynamic routing tag. This was a conscious label as any form of dynamic routing tag. This was a conscious
choice in the early design of IPv6 and there appears to be no choice in the early design of IPv6 and there appears to be no
practical possibility of revisiting this choice at this stage in the practical possibility of revisiting this choice at this stage in the
deployment of IPv6, which uses conventional routing mechanisms like deployment of IPv6, which uses conventional routing mechanisms like
those used for IPv4. However, this rule also makes it impossible to those used for IPv4. However, this rule also makes it impossible to
make any use at all of the flow label unless hosts choose to set it. make any use at all of the flow label unless hosts choose to set it.
skipping to change at page 5, line 44 skipping to change at page 5, line 44
prevail, and that complicated proposals such as defining quality of prevail, and that complicated proposals such as defining quality of
service semantics in the flow label, or sub-dividing the flow label service semantics in the flow label, or sub-dividing the flow label
field into smaller sub-fields, will not prove efficient or field into smaller sub-fields, will not prove efficient or
deployable, especially in high speed routers. There is also a deployable, especially in high speed routers. There is also a
clearly expressed view that using the flow label for various forms of clearly expressed view that using the flow label for various forms of
stateless load balancing is the best simple application for it. At stateless load balancing is the best simple application for it. At
the same time, it is necessary to recognize that the strict the same time, it is necessary to recognize that the strict
immutability rule has drawbacks as noted above. immutability rule has drawbacks as noted above.
Even under the rules of RFC 3697, the flow label is intrinsically Even under the rules of RFC 3697, the flow label is intrinsically
untrustworthy, because modifcations en route cannot be detected. For untrustworthy, because modifications en route cannot be detected.
this reason, even with the current strict immutability rule, For this reason, even with the current strict immutability rule,
downstream nodes cannot rely on the value being unchanged. In this downstream nodes cannot rely on the value being unchanged. In this
sense, any use of the flow label must be viewed as an optimisation on sense, any use of the flow label must be viewed as an optimisation on
a best effort basis; a packet with a changed (or zero) flow label a best effort basis; a packet with a changed (or zero) flow label
value should never cause a hard failure. value should never cause a hard failure.
The remainder of this document is in the form of a set of proposed The remainder of this document discusses specific modifications to
modifications to the standard, consistent with the points above and the standard, which are defined normatively in a companion document
written in normative form. It is suggested that if the proposal is [I-D.draft-ietf-6man-flow-3697bis].
generally accepted, a revised version of RFC 3697 should be produced
including these changes.
3. Normative Notation
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].
4. Proposed changes to specification 3. Changes to specification
Although RFC 3697 requires the flow label to be delivered unchanged, Although RFC 3697 requires the flow label to be delivered unchanged,
as noted above, it is not included in any transport layer pseudo- as noted above, it is not included in any transport layer pseudo-
header checksums nor in IPsec authentication [RFC4302]. Both RFC header checksums nor in IPsec authentication [RFC4302]. Both RFC
2460 and RFC 3697 define the default flow label to be zero. At the 2460 and RFC 3697 define the default flow label to be zero. At the
time of writing, this is the observed value in an overwhelming time of writing, this is the observed value in an overwhelming
proportion of IPv6 packets; neither operating systems nor proportion of IPv6 packets; neither operating systems nor
applications currently set it, and routers do not rely on it. Thus applications currently set it, and routers do not rely on it. Thus
there is no reason to expect operational difficulties if a careful there is no reason to expect operational difficulties if a careful
change is made to the rules of RFC 3697. change is made to the rules of RFC 3697.
skipping to change at page 6, line 41 skipping to change at page 6, line 33
The purposes of the proposed changes are to remove the uncertainties The purposes of the proposed changes are to remove the uncertainties
left by RFC 3697, in order to encourage setting of the flow label by left by RFC 3697, in order to encourage setting of the flow label by
default, and to enable its generic use. The proposed generic use is default, and to enable its generic use. The proposed generic use is
to encourage pseudo-random flow labels that can be used to assist to encourage pseudo-random flow labels that can be used to assist
load balancing. There should be no impact on existing IETF load balancing. There should be no impact on existing IETF
specifications other than RFC 3697 and no impact on currently specifications other than RFC 3697 and no impact on currently
operational software and hardware. operational software and hardware.
A secondary purpose is to modify the immutability of the flow label A secondary purpose is to modify the immutability of the flow label
in a limited way, to allow hosts that do not set the flow label to in a limited way, to allow hosts that do not set the flow label to
benefit from it nevertheless. benefit from it nevertheless. The fact that the flow label may in
practice be changed en route is also reflected in the reformulation
The fact that the flow label may in practice be changed en route is of the rules.
also reflected in the reformulation of the rules.
A description of the changes follows. They are written in normative
language to avoid ambiguity. They are mainly not written as specific
text changes to RFC 3697, and significant rewriting of the latter is
needed to incorporate these changes.
The definition of a flow is subtly changed from RFC 3697 as follows:
A flow is a sequence of packets sent from a particular source to a
particular unicast, anycast, or multicast destination that a node
desires to label as a flow. A flow could consist of all packets
in a specific transport connection or a media stream. However, a
flow is not necessarily 1:1 mapped to a transport connection.
The change is that the words 'the source' have been replaced by 'a
node'. Nodes that do not support the flow label remain subject to
RFC 2460. The intention is to enable the following new
specifications:
1. It is RECOMMENDED that source hosts support the flow label by
setting the flow label field for all packets of a flow to the
same pseudo-random value.
* This rule updates the less precise recommendation made in
Section 3 of RFC 3697. Both stateful and stateless methods of
assigning a pseudo-random value could be used, but it is
outside the scope of this specification to mandate an
algorithm.
* An OPTIONAL algorithm for generating such a pseudo-random
value is proposed in [I-D.gont-6man-flowlabel-security].
* Section 3 of RFC 3697 also allows nodes to participate in an
unspecified method of flow state establishment. The changes
do not remove that option.
2. A node that forwards a flow whose flow label value in arriving
packets is zero MAY set the flow label value. In that case, it
is RECOMMENDED that the forwarding node sets the flow label field
for a flow to a pseudo-random value.
* The same considerations apply as to the first recommendation.
* This option, if implemented, would presumably be used by
ingress routers. It would place a considerable per-packet
processing load on them, even if they adopted a stateless
method of flow identification and label assignment. This is
why the principal recommendation is that the source host
should set the label.
3. A forwarding node MUST NOT change the flow label value in an A general description of the changes follows. The normative text is
arriving packet if it is non-zero. However, there are two to be found in [I-D.ietf-6man-flow-3697bis].
qualifications to this rule:
1. Implementers are advised that forwarding nodes, especially
those acting as domain border devices, might nevertheless be
configured to change the flow label value in packets (e.g.,
to a new pseudo-random value). This is undetectable, unless
some future version of IPsec authentication [RFC4302]
protects the flow label value.
2. To enable stateless load balancing at any point in the The definition of a flow is subtly changed from RFC 3697 to allow any
Internet, a network domain MUST NOT forward packets outside node, not just the source node, to set the flow label value.
the domain whose flow label values are other than zero or However, it is recommended that sources should set a pseudo-random
pseudo-random. Neither domain border egress routers nor flow label value in all flows, replacing the less precise
intermediate routers/devices (using a flow-label, for recommendation made in Section 3 of RFC 3697. Both stateful and
example, as a part of an input-key for a load-balancing hash) stateless methods of assigning a pseudo-random value could be used.
can determine by inspection that a value is not pseudo-
random. Therefore, if nodes within a domain ignore the above
recommendations to set zero or pseudo-random flow label
values, and such packets are forwarded outside the domain,
this would likely result in undesirable operational
implications (e.g., congestion, reordering) for not only the
inappropriately flow-labelled packets, but also well-behaved
flow-labelled packets, during forwarding at various
intermediate devices. Thus, a domain must protect its peers
by never exporting inappropriately labelled packets. This
document does not specify the method for enforcing this rule.
The suggested way to enforce it is that nodes within a domain
MUST NOT set the flow label to a non-zero and non-pseudo-
random number if the packet will leave the domain. If this
is not known to be the case, the border router will need to
change outgoing flow labels.
Note that the new rules above, taken together, allow a given Section 3 of RFC 3697 also allows nodes to participate in an
network domain to include routers that set flow labels on behalf unspecified method of flow state establishment. The changes do not
of hosts that do not do so. They also require that flow labels remove that option, but it is made clear that stateless models are
exported to the Internet must always be either zero or pseudo- also possible.
random. These changes replace rule (a) quoted in Section 1.
However, there is no way to verify whether a flow label has been
modified en route. No Internet-wide mechanism can depend
mathematically on immutable flow labels. This leads to the
following formal rule:
4. IPv6 nodes MUST NOT assume that the Flow Label value in a The main novelty is that a forwarding node (typically a first-hop or
incoming packet is identical to the value set by the source node. ingress router) may set the flow label value if the source has not
* This replaces rule (b) quoted in Section 1. done so, according to the same recommendations that apply to the
source. This might place a considerable processing load on ingress
routers, even if they adopted a stateless method of flow
identification and label assignment.
5. Forwarding nodes such as routers and load balancers MUST NOT The immutability of the flow label, once it has been set, is not
depend only on Flow Label values being randomly distributed. In changed. However, some qualifications are placed on this property,
any usage such as a hash key for load balancing, the Flow Label to allow for the fact that the flow label is an unprotected field and
bits MUST be combined with bits from other sources within the might be changed undetectably. No Internet-wide mechanism can depend
packet, so as to produce a suitable distribution of hash values. mathematically on immutable flow labels. The new rules require that
* This replaces rule (c) quoted in Section 1. Although a flow labels exported to the Internet must always be either zero or
pseudo-random flow label is recommended, and will always be pseudo-random, but even this cannot be relied on mathematically. Use
helpful for load balancing, it is unsafe to assume its cases need to be robust against non-conforming flow label values.
presence in the general case, and the use case needs to work
even if the flow label value is zero.
5. Discussion 4. Discussion
The following are the consequences of the above changes, taken The following are some practical consequences of the above changes:
together with the unaffected parts of RFC 3697:
o Sending hosts that are not updated will in practice continue to o Sending hosts that are not updated will in practice continue to
send all-zero labels. If there is no label-setting router along send all-zero labels. If there is no label-setting router along
the path taken by a packet, the label will be delivered as zero. the path taken by a packet, the label will be delivered as zero.
o Sending hosts conforming to this specification will by default o Sending hosts conforming to the new specification will by default
choose pseudo-random labels between 1 and 0xFFFFF. choose pseudo-random labels between 1 and 0xFFFFF.
o Sending hosts may continue to send all-zero labels, in which case o Sending hosts may continue to send all-zero labels, in which case
an ingress router may set pseudo-random labels between 1 and an ingress router may set pseudo-random labels between 1 and
0xFFFFF. 0xFFFFF.
o The flow label is no longer unrealistically asserted to be o The flow label is no longer unrealistically asserted to be
strictly immutable; it is recognised that it may, incorrectly, be strictly immutable; it is recognised that it may, incorrectly, be
changed en route. In some circumstances this will break end-to- changed en route. In some circumstances this will break end-to-
end usage, e.g. potential detection of third-party spoofing end usage, e.g. potential detection of third-party spoofing
attacks [I-D.gont-6man-flowlabel-security]. attacks [I-D.gont-6man-flowlabel-security].
o The expected default usage of the flow label is some form of load o The expected default usage of the flow label is some form of
balancing, such as the ECMP/LAG usage defined in stateless load distribution, such as the ECMP/LAG usage defined in
[I-D.carpenter-flow-ecmp]. [I-D.carpenter-flow-ecmp].
o If the rules in Section 4 are followed, including rule 3.2, all o If the new rules are followed, all IPv6 traffic flows on the
IPv6 traffic flows on the Internet will have zero or pseudo-random Internet should have zero or pseudo-random flow label values.
flow label values.
From an operational viewpoint, existing IPv6 hosts that set a default From an operational viewpoint, existing IPv6 hosts that set a default
(zero) flow label value and ignore the flow label on receipt will be (zero) flow label value and ignore the flow label on receipt will be
unaffected by implementations of this specification. In general, it unaffected by implementations of the new specification. In general,
is assumed that hosts will ignore the value of the flow label on it is assumed that hosts will ignore the value of the flow label on
receipt; it cannot be relied on as an end-to-end signal. receipt; it cannot be relied on as an end-to-end signal. However,
this doesn't apply if a cryptographically generated label is being
used to detect attackers [I-D.gont-6man-flowlabel-security].
Similarly, routers that ignore the flow label will be unaffected by Similarly, routers that ignore the flow label will be unaffected by
implementations of this specification. implementations of the specification.
Hosts that set a default (zero) flow label and are in a domain where Hosts that set a default (zero) flow label but are in a domain where
routers adopt the recommended pseudo-random mechanism in Section 4 routers set a pseudo-random label as recommended in Section 3 will
will benefit from whatever flow label handling is used in the local benefit from whatever flow label handling is used on the path.
domain.
Hosts and routers that adopt the recommended pseudo-random mechanism Hosts and routers that adopt the recommended pseudo-random mechanism
will enhance the performance of any load balancing devices that will enhance the performance of any load balancing devices that
include the flow label in the hash used to select a particular path include the flow label in the hash used to select a particular path
or server, even when packets leave the local domain. or server, even when packets leave the local domain.
6. Security Considerations 5. Security Considerations
The flow label is not protected in any way and can be forged by an
on-path attacker. On the other hand, a pseudo-random flow label
cannot be readily guessed by an off-path attacker. See RFC 3697 and
[I-D.gont-6man-flowlabel-security] for further discussion.
Security devices that clear or rewrite flow label values would be in See [I-D.draft-ietf-6man-flow-3697bis] and
violation of this specification. [I-D.gont-6man-flowlabel-security] for full discussion.
7. IANA Considerations 6. IANA Considerations
This document requests no action by IANA. This document requests no action by IANA.
8. Acknowledgements 7. Acknowledgements
The authors are grateful to Qinwen Hu for general discussion about The authors are grateful to Qinwen Hu for general discussion about
the flow label and for his work in searching the literature. the flow label and for his work in searching the literature.
Valuable comments and contributions were made by Fred Baker, Steve Valuable comments and contributions were made by Fred Baker, Steve
Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Haberman, Tony Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Haberman, Tony
Hain, Joel Halpern, Chris Morrow, Thomas Narten, Mark Smith, Pascal Hain, Joel Halpern, Chris Morrow, Thomas Narten, Mark Smith, Pascal
Thubert, Iljitsch van Beijnum, and other participants in the 6man Thubert, Iljitsch van Beijnum, and other participants in the 6man
working group. working group.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
9. Change log 8. Change log
draft-ietf-6man-flow-update-02: repurposed as rationale for update of
RFC 3697, 2011-01-31
draft-ietf-6man-flow-update-01: clarified that this is not a formal draft-ietf-6man-flow-update-01: clarified that this is not a formal
update of RFC 3697, clarified text about domains exporting update of RFC 3697, clarified text about domains exporting
inappropriate labels, 2011-01-10 inappropriate labels, 2011-01-10
draft-ietf-6man-flow-update-00: adopted as WG document at IETF 79, draft-ietf-6man-flow-update-00: adopted as WG document at IETF 79,
mutability rules adjusted according to WG discussion, 2010-12-03 mutability rules adjusted according to WG discussion, 2010-12-03
draft-carpenter-6man-flow-update-04: even more simplified according draft-carpenter-6man-flow-update-04: even more simplified according
to WG discussion, 2010-09-16 to WG discussion, 2010-09-16
draft-carpenter-6man-flow-update-03: futher simplified according to draft-carpenter-6man-flow-update-03: futher simplified according to
WG discussion, 2010-05-07 WG discussion, 2010-05-07
draft-carpenter-6man-flow-update-02: revised and simplified according draft-carpenter-6man-flow-update-02: revised and simplified according
to WG discussion, 2010-04-13 to WG discussion, 2010-04-13
draft-carpenter-6man-flow-update-01: revised according to mail list draft-carpenter-6man-flow-update-01: revised according to mail list
skipping to change at page 11, line 5 skipping to change at page 9, line 18
WG discussion, 2010-05-07 WG discussion, 2010-05-07
draft-carpenter-6man-flow-update-02: revised and simplified according draft-carpenter-6man-flow-update-02: revised and simplified according
to WG discussion, 2010-04-13 to WG discussion, 2010-04-13
draft-carpenter-6man-flow-update-01: revised according to mail list draft-carpenter-6man-flow-update-01: revised according to mail list
discussion, 2010-03-05 discussion, 2010-03-05
draft-carpenter-6man-flow-update-00: original version, 2010-02-18 draft-carpenter-6man-flow-update-00: original version, 2010-02-18
10. References 9. References
10.1. Normative References 9.1. Normative References
[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.
[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.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 9.2. Informative References
"IPv6 Flow Label Specification", RFC 3697, March 2004.
10.2. Informative References
[I-D.carpenter-flow-ecmp] [I-D.carpenter-flow-ecmp]
Carpenter, B. and S. Amante, "Using the IPv6 flow label Carpenter, B. and S. Amante, "Using the IPv6 flow label
for equal cost multipath routing and link aggregation in for equal cost multipath routing and link aggregation in
tunnels", draft-carpenter-flow-ecmp-03 (work in progress), tunnels", draft-carpenter-flow-ecmp-03 (work in progress),
October 2010. October 2010.
[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),
skipping to change at page 11, line 49 skipping to change at page 10, line 13
(work in progress), March 2007. (work in progress), March 2007.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[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.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
Appendix A. Alternative Approaches Appendix A. Alternative Approaches
A model was discussed in an earlier version of this document which A model was discussed in an earlier version of this document which
defined a notion of 'flow label domain' analogous to a differentiated defined a notion of 'flow label domain' analogous to a differentiated
services domain [RFC2474]. This model would have encouraged local services domain [RFC2474]. This model would have encouraged local
usage of the flow label as an alternative to any form of generic use, usage of the flow label as an alternative to any form of generic use,
but it required complex rules for the behaviour of domain boundary but it required complex rules for the behaviour of domain boundary
 End of changes. 35 change blocks. 
176 lines changed or deleted 90 lines changed or added

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