draft-ietf-intarea-flow-label-balancing-01.txt   draft-ietf-intarea-flow-label-balancing-02.txt 
IntArea B. E. Carpenter IntArea B. Carpenter
Internet-Draft Univ. of Auckland Internet-Draft Univ. of Auckland
Intended status: Informational S. Jiang Intended status: Informational S. Jiang
Expires: November 26, 2013 Huawei Technologies Co., Ltd Expires: April 10, 2014 Huawei Technologies Co., Ltd
W. Tarreau W. Tarreau
Exceliance Exceliance
May 25, 2013 October 07, 2013
Using the IPv6 Flow Label for Server Load Balancing Using the IPv6 Flow Label for Server Load Balancing
draft-ietf-intarea-flow-label-balancing-01 draft-ietf-intarea-flow-label-balancing-02
Abstract Abstract
This document describes how the IPv6 flow label as currently This document describes how the IPv6 flow label as currently
specified can be used to enhance layer 3/4 load distribution and specified can be used to enhance layer 3/4 load distribution and
balancing for large server farms. balancing for large server farms.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 26, 2013. This Internet-Draft will expire on April 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary of Flow Label Specification . . . . . . . . . . . . . 2 2. Summary of Flow Label Specification . . . . . . . . . . . . . 3
3. Summary of Load Balancing Techniques . . . . . . . . . . . . 4 3. Summary of Load Balancing Techniques . . . . . . . . . . . . 4
4. Applying the Flow Label to L3/L4 Load Balancing . . . . . . . 7 4. Applying the Flow Label to L3/L4 Load Balancing . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 10 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The IPv6 flow label has been redefined [RFC6437] and is now a The IPv6 flow label has been redefined [RFC6437] and is now a
recommended IPv6 node requirement [RFC6434]. Its use for load recommended IPv6 node requirement [RFC6434]. Its use for load
sharing in multipath routing has been specified [RFC6438]. Another sharing in multipath routing has been specified [RFC6438]. Another
scenario in which the flow label could be used is in load scenario in which the flow label could be used is in load
distribution for large server farms. Load distribution is a slightly distribution for large server farms. Load distribution is a slightly
more general term than load balancing, but the latter is more more general term than load balancing, but the latter is more
commonly used. This document starts with brief introductions to the commonly used. Both terms refer to mechanisms that distribute the
flow label and to load balancing techniques, and then describes how workload of a server farm among different servers in order to
the flow label can be used to enhance layer 3/4 load balancers in optimize performance. Server load balancing commonly applies to HTTP
particular. traffic, but most of the techniques described would apply to other
upper layer applications as well. This document starts with brief
introductions to the flow label and to load balancing techniques, and
then describes how the flow label can be used to enhance load
balancers operating on IP packets and TCP sessions, commonly known as
layer 3/4 load balancers.
The motivation for this approach is to improve the performance of The motivation for this approach is to improve the performance of
most types of layer 3/4 load balancers, especially for traffic most types of layer 3/4 load balancers, especially for traffic
including multiple IPv6 extension headers and in particular for including multiple IPv6 extension headers and in particular for
fragmented packets. Fragmented packets, often the result of fragmented packets. Fragmented packets, often the result of
customers reaching the load balancer via a VPN with a limited MTU, customers reaching the load balancer via a VPN with a limited MTU,
are a common performance problem. are a common performance problem.
2. Summary of Flow Label Specification 2. Summary of Flow Label Specification
The IPv6 flow label is a 20 bit field included in every IPv6 header
[RFC2460]. It is recommended to be supported in all IPv6 nodes by The IPv6 flow label [RFC6437] is a 20 bit field included in every
[RFC6434] and it is defined in [RFC6437]. There is additional IPv6 header [RFC2460]. It is recommended to be supported in all IPv6
background material in [RFC6436] and [RFC6294]. According to its nodes by [RFC6434]. There is additional background material in
definition, the flow label should be set to a constant value for a [RFC6436] and [RFC6294]. According to its definition, the flow label
given traffic flow (such as an HTTP connection), and that value will should be set to a constant value for a given traffic flow (such as
belong to a uniform statistical distribution, making it potentially an HTTP connection), and that value will belong to a uniform
valuable for load balancing purposes. statistical distribution, making it potentially valuable for load
balancing purposes.
Any device that has access to the IPv6 header has access to the flow Any device that has access to the IPv6 header has access to the flow
label, and it is at a fixed position in every IPv6 packet. In label, and it is at a fixed position in every IPv6 packet. In
contrast, transport layer information, such as the port numbers, is contrast, transport layer information, such as the port numbers, is
not always in a fixed position, since it follows any IPv6 extension not always in a fixed position, since it follows any IPv6 extension
headers that may be present. In fact, the logic of finding the headers that may be present. In fact, the logic of finding the
transport header is always more complex for IPv6 than for IPv4, due transport header is always more complex for IPv6 than for IPv4, due
to the absence of an Internet Header Length field in IPv6. to the absence of an Internet Header Length field in IPv6.
Additionally, if packets are fragmented, the flow label will be Additionally, if packets are fragmented, the flow label will be
present in all fragments, but the transport header will only be in present in all fragments, but the transport header will only be in
skipping to change at page 4, line 43 skipping to change at page 5, line 12
different users. This is typically done by rotating the order in different users. This is typically done by rotating the order in
which different addresses within the server site are listed by the which different addresses within the server site are listed by the
relevant authoritative DNS server, on the assumption that the relevant authoritative DNS server, on the assumption that the
client will pick the first one. Routing may be configured such client will pick the first one. Routing may be configured such
that the different addresses are handled by different ingress that the different addresses are handled by different ingress
routers. Several variants of this load balancing mechanism exist, routers. Several variants of this load balancing mechanism exist,
such as expecting some clients to use all the advertised addresses such as expecting some clients to use all the advertised addresses
when multiple connections are involved, or directing the traffic when multiple connections are involved, or directing the traffic
to multiple sites, also known as global load balancing. None of to multiple sites, also known as global load balancing. None of
these mechanisms are in the scope of this document, and what this these mechanisms are in the scope of this document, and what this
document proposes does not affect their usability nor aims to document proposes does not affect their usability nor aim to
replace them, so they will not be discussed further. replace them, so they will not be discussed further.
o Another method, for HTTP servers, is to operate a layer 7 reverse o Another method, for HTTP servers, is to operate a layer 7 reverse
proxy in front of the server farm. The reverse proxy will present proxy in front of the server farm. The reverse proxy will present
a single IP address to the world, communicated to clients by a a single IP address to the world, communicated to clients by a
single AAAA record. For each new client session (an incoming TCP single AAAA record. For each new client session (an incoming TCP
connection and HTTP request), it will pick a particular server and connection and HTTP request), it will pick a particular server and
proxy the session to it. The act of proxying should be more proxy the session to it. The act of proxying should be more
efficient and less resource-intensive than the act of serving the efficient and less resource-intensive than the act of serving the
required content. The proxy must retain TCP state and proxy state required content. The proxy must retain TCP state and proxy state
for the duration of the session. This TCP state could, for the duration of the session. This TCP state could,
potentially, include the incoming flow label value. potentially, include the incoming flow label value.
o A component of some load balancing systems is an SSL reverse proxy o A component of some load balancing systems is an SSL reverse proxy
farm. The individual SSL proxies handle all cryptographic aspects farm. The individual SSL proxies handle all cryptographic aspects
and exchange raw HTTP with the actual servers. Thus, from the and exchange unencrypted HTTP with the actual servers. Thus, from
load balancing point of view, this really looks just like a server the load balancing point of view, this really looks just like a
farm, except that it's specialised for HTTPS. Each proxy will server farm, except that it's specialised for HTTPS. Each proxy
retain SSL and TCP and maybe HTTP state for the duration of the will retain SSL and TCP and maybe HTTP state for the duration of
session, and the TCP state could potentially include the flow the session, and the TCP state could potentially include the flow
label. label.
o Finally the "front end" of many load balancing systems is a layer o Finally the "front end" of many load balancing systems is a layer
3/4 load balancer. While it can be a dedicated device, it is also 3/4 load balancer. While it can be a dedicated device, it is also
a standard function of some network switches or routers (e.g. a standard function of some network switches or routers (e.g.
using ECMP, [RFC2991]). In this case, it is the layer 3/4 load using Equal Cost Multipath Routing (ECMP) [RFC2991]). In this
balancer whose IP address is published as the primary AAAA record case, it is the layer 3/4 load balancer whose IP address is
for the service. All client sessions will pass through this published as the primary AAAA record for the service. All client
device. According to the specific scenario, it will spread new sessions will pass through this device. Depending on the specific
sessions across the actual application servers, across an SSL scenario, the balancer will assign new sessions among the actual
proxy farm, or across a set of layer 7 proxies. In all cases, the application servers, across an SSL proxy farm, or among a set of
layer 3/4 load balancer has to recognize incoming packets as layer 7 proxies. In all cases, the layer 3/4 load balancer has to
belonging to new or existing client sessions, and choose the recognize incoming packets as belonging to new or existing client
target server or proxy so as to ensure persistence. 'Persistence' sessions, and choose the target server or proxy so as to ensure
is defined as guaranteeing that a given session will run to persistence. 'Persistence' is defined as the guarantee that a
completion on a single server. The layer 3/4 load balancer given session will run to completion on a single server. The
therefore needs to inspect each incoming packet to identify the layer 3/4 load balancer therefore needs to inspect each incoming
session. There are two common types of layer 3/4 load balancers, packet to identify the session. There are two common types of
the totally stateless ones which only act on packets, generally layer 3/4 load balancers, the totally stateless ones which only
involving a per-packet hashing of easy-to-find information such as act on packets, generally involving a per-packet hashing of easy-
the source address and/or port into a server number, and the to-find information such as the source address and/or port into a
stateful ones which take the routing decision on the very first server number, and the stateful ones which take the routing
packets of a session and maintain the same direction for all decision on the very first packets of a session and maintain the
packets belonging to the same session. Clearly, both types of same direction for all packets belonging to the same session.
layer 3/4 balancers could inspect and make use of the flow label Clearly, both types of layer 3/4 balancers could inspect and make
value. use of the flow label value.
Our focus is on how the balancer identifies a particular flow. Our focus is on how the balancer identifies a particular flow.
For clarity, note that two aspects of layer 3/4 load balancers are For clarity, note that two aspects of layer 3/4 load balancers are
not affected by use of the flow label to identify sessions: not affected by use of the flow label to identify sessions:
1. Balancers use various techniques to redirect traffic to a 1. Balancers use various techniques to redirect traffic to a
specific target server. specific target server.
- All servers are configured with the same IP address, they - All servers are configured with the same IP address, they
are all on the same LAN, and the load balancer sends directly are all on the same LAN, and the load balancer sends directly
skipping to change at page 6, line 22 skipping to change at page 6, line 41
performs NAPT (network address and port translation) to performs NAPT (network address and port translation) to
deliver the client's packets to that address. deliver the client's packets to that address.
The choice between these methods is not affected by use of the The choice between these methods is not affected by use of the
flow label. flow label.
2. A layer 3/4 balancer must correctly handle Path MTU Discovery 2. A layer 3/4 balancer must correctly handle Path MTU Discovery
by forwarding relevant ICMPv6 packets in both directions. by forwarding relevant ICMPv6 packets in both directions.
This too is not affected by use of the flow label. This too is not affected by use of the flow label.
The following diagram, inspired by [Tarreau], shows a maximum layout The following diagram, inspired by [Tarreau], shows a layout with
with various methods in use together. various methods in use together.
___________________________________________ ___________________________________________
( ) ( )
( Clients in the Internet ) ( Clients in the Internet )
(___________________________________________) (___________________________________________)
| | | |
------------ ------------ ------------ ------------
| Ingress | | Ingress | | Ingress | | Ingress |
| router | | router | | router | | router |
------------ ------------ ------------ ------------
skipping to change at page 7, line 19 skipping to change at page 7, line 39
From the previous paragraphs, we can identify several points in this From the previous paragraphs, we can identify several points in this
diagram where the flow label might be relevant: diagram where the flow label might be relevant:
1. Layer 3/4 load balancers. 1. Layer 3/4 load balancers.
2. SSL proxies. 2. SSL proxies.
3. HTTP proxies. 3. HTTP proxies.
However, usage by the proxies seems unlikely to be cost-effective, so However, usage by the proxies seems unlikely to be cost-effective,
in this document we focus only on layer 3/4 balancers. because they must in any case process the application layer header,
so in this document we focus only on layer 3/4 balancers.
4. Applying the Flow Label to L3/L4 Load Balancing 4. Applying the Flow Label to L3/L4 Load Balancing
The suggested model for using the flow label to enhance a L3/L4 load The suggested model for using the flow label to enhance a L3/L4 load
balancing mechanism is as follows: balancing mechanism is as follows:
o We are only concerned with IPv6 traffic in which the flow label o We are only concerned with IPv6 traffic in which the flow label
value has been set at or near the source according to [RFC6437]. value has been set at or near the source according to [RFC6437].
If the flow label of an incoming packet is zero, load balancers If the flow label of an incoming packet is zero, load balancers
will continue to use the transport header in the traditional way. will continue to use the transport header in the traditional way.
skipping to change at page 8, line 29 skipping to change at page 9, line 6
chain, in order to locate and modify the port number and transport chain, in order to locate and modify the port number and transport
checksum. The same would apply to balancers that perform TCP checksum. The same would apply to balancers that perform TCP
state tracking for any reason. state tracking for any reason.
o Note that correct handling of ICMPv6 for Path MTU Discovery o Note that correct handling of ICMPv6 for Path MTU Discovery
requires the layer 3/4 balancer to keep state for the client requires the layer 3/4 balancer to keep state for the client
source address, independently of either the port numbers or the source address, independently of either the port numbers or the
flow label. flow label.
o SSL and HTTP proxies, if present, should forward the flow label o SSL and HTTP proxies, if present, should forward the flow label
value towards the server. This has no performance benefit, but is value towards the server. This usually has no performance
consistent with the general RFC 6437 model for the flow label. benefit, but is consistent with the general RFC 6437 model for the
flow label.
It should be noted that the performance benefit, if any, depends It should be noted that the performance benefit, if any, depends
entirely on engineering trade-offs in the design of the L3/L4 entirely on engineering trade-offs in the design of the L3/L4
balancer. An extra test is needed (is the label non-zero?), but all balancer. An extra test is needed (is the label non-zero?), but if
logic for handling extension headers can be omitted except for the there is a non-zero label, all logic for handling extension headers
first packet of a new flow. Since the only state to be stored is the can be skipped except for the first packet of a new flow. Since the
2-tuple and the server identifier, storage requirements will be only state to be stored is the 2-tuple and the server identifier,
reduced. Additionally, the method will work for fragmented traffic storage requirements will be reduced. Additionally, the method will
and for flows where the transport information is missing (unknown work for fragmented traffic and for flows where the transport
transport protocol) or obfuscated (e.g., IPsec). Traffic reaching information is missing (unknown transport protocol) or obfuscated
the load balancer via a VPN is particularly prone to the (e.g., IPsec). Traffic reaching the load balancer via a VPN is
fragmentation issue, due to MTU size issues. For some load balancer particularly prone to the fragmentation issue, due to MTU size
designs, these are very significant advantages. issues. For some load balancer designs, these are very significant
advantages.
In the unlikely event of two simultaneous flows from the same source In the unlikely event of two simultaneous flows from the same source
address having the same flow label value, the two flows would end up address having the same flow label value, the two flows would end up
assigned to the same server, where they would be distinguished as assigned to the same server, where they would be distinguished as
normal by their port numbers. There are approximately one million normal by their port numbers. There are approximately one million
possible flow label values, and if the rules for flow label possible flow label values, and if the rules for flow label
generation [RFC6437] are followed, this would be a statistically rare generation [RFC6437] are followed, this would be a statistically rare
event, and would not damage the overall load balancing effect. event, and would not damage the overall load balancing effect.
Moreover, with a million possible label values, it is very likely Moreover, with a million possible label values, it is very likely
that there will be many more flow label values than servers at most that there will be many more flow label values than servers at most
sites, so it is already expected that multiple flow label values will sites, so it is already expected that multiple flow label values will
end up on the same server for a given client IP address. end up on the same server for a given client IP address.
In the case that many thousands of clients are hidden behind the same In the case that many thousands of clients are hidden behind the same
large-scale NAPT (network address and port translator) with a single large-scale NAPT (network address and port translator) with a single
shared IP address, the assumption of low probability of conflicts shared IP address, the assumption of low probability of conflicts
might become incorrect, unless flow label values are random enough to might become incorrect, unless flow label values are random enough to
avoid following similar sequences for all clients. This is not avoid following similar sequences for all clients. This is not
skipping to change at page 9, line 17 skipping to change at page 9, line 43
sites, so it is already expected that multiple flow label values will sites, so it is already expected that multiple flow label values will
end up on the same server for a given client IP address. end up on the same server for a given client IP address.
In the case that many thousands of clients are hidden behind the same In the case that many thousands of clients are hidden behind the same
large-scale NAPT (network address and port translator) with a single large-scale NAPT (network address and port translator) with a single
shared IP address, the assumption of low probability of conflicts shared IP address, the assumption of low probability of conflicts
might become incorrect, unless flow label values are random enough to might become incorrect, unless flow label values are random enough to
avoid following similar sequences for all clients. This is not avoid following similar sequences for all clients. This is not
expected to be a factor for IPv6 anyway, since there is no need to expected to be a factor for IPv6 anyway, since there is no need to
implement large-scale NAPT with address sharing [RFC4864]. The implement large-scale NAPT with address sharing [RFC4864]. The
statistical assumption is valid for sites that implement network probability of conflicts is low for sites that implement network
prefix translation [RFC6296], since this technique provides a prefix translation [RFC6296], since this technique provides a
different address for each client. different address for each client.
5. Security Considerations 5. Security Considerations
Security aspects of the flow label are discussed in [RFC6437]. As Security aspects of the flow label are discussed in [RFC6437]. As
noted there, a malicious source or man-in-the-middle could disturb noted there, a malicious source or man-in-the-middle could disturb
load balancing by manipulating flow labels. This risk already exists load balancing by manipulating flow labels. This risk already exists
today where the source address and port are used as hashing key in today where the source address and port are used as hashing key in
layer 3/4 load balancers, as well as where a persistence cookie is layer 3/4 load balancers, as well as where a persistence cookie is
used in HTTP to designate a server. It even exists on layer 3 used in HTTP to designate a server. It even exists on layer 3
components which only rely on the source address to select a components which only rely on the source address to select a
destination, making them more DDoS-prone. Nevertheless, all these destination, making them more DDoS-prone. Nevertheless, all these
methods are currently used because the benefits for load balancing methods are currently used because the benefits for load balancing
and persistence hugely outweigh the risks. The flow label does not and persistence hugely outweigh the risks. The flow label does not
significantly alter this situation. significantly alter this situation.
Specifically, the specification [RFC6437] states that "stateless Specifically, the standard [RFC6437] states that "stateless
classifiers should not use the flow label alone to control load classifiers should not use the flow label alone to control load
distribution, and stateful classifiers should include explicit distribution, and stateful classifiers should include explicit
methods to detect and ignore suspect flow label values." The former methods to detect and ignore suspect flow label values." The former
point is answered by also using the source address. The latter point point is answered by also using the source address. The latter point
is more complex. If the risk is considered serious, the site ingress is more complex. If the risk is considered serious, the site ingress
router or the layer 3/4 balancer should use a suitable heuristic to router or the layer 3/4 balancer should use a suitable heuristic to
verify incoming flows with non-zero flow label values. If a flow verify incoming flows with non-zero flow label values. If a flow
from a given source address and port number does not have a constant from a given source address and port number does not have a constant
flow label value, it is suspect and should be dropped. This would flow label value, it is suspect and should be dropped. This would
deal with both intentional and accidental changes to the flow label. deal with both intentional and accidental changes to the flow label.
skipping to change at page 10, line 41 skipping to change at page 11, line 17
cryptographic hash function of some kind, to ensure that an attacker cryptographic hash function of some kind, to ensure that an attacker
cannot predict the behaviour of the load balancer. cannot predict the behaviour of the load balancer.
6. IANA Considerations 6. IANA Considerations
This document requests no action by IANA. This document requests no action by IANA.
7. Acknowledgements 7. Acknowledgements
Valuable comments and contributions were made by Fred Baker, Olivier Valuable comments and contributions were made by Fred Baker, Olivier
Bonaventure, Lorenzo Colitti, Linda Dunbar, Donald Eastlake, Joel Bonaventure, Ben Campbell, Lorenzo Colitti, Linda Dunbar, Donald
Jaeggli, Gurudeep Kamat, Warren Kumari, Julia Renouard, Julius Volz, Eastlake, Joel Jaeggli, Gurudeep Kamat, Warren Kumari, Julia
and others. Renouard, Julius Volz, and others.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
8. Change log [RFC Editor: Please remove] 8. Change log [RFC Editor: Please remove]
draft-ietf-intarea-flow-label-balancing-02: Last Call comments,
2013-10-07.
draft-ietf-intarea-flow-label-balancing-01: clarifications based on draft-ietf-intarea-flow-label-balancing-01: clarifications based on
WG comments, 2013-05-25. WG comments, 2013-05-25.
draft-ietf-intarea-flow-label-balancing-00: WG adoption, minor WG draft-ietf-intarea-flow-label-balancing-00: WG adoption, minor WG
comments, 2013-01-15. comments, 2013-01-15.
draft-carpenter-flow-label-balancing-02: updates based on external draft-carpenter-flow-label-balancing-02: updates based on external
review, 2012-12-05. review, 2012-12-05.
draft-carpenter-flow-label-balancing-01: update following comments, draft-carpenter-flow-label-balancing-01: update following comments,
skipping to change at page 11, line 26 skipping to change at page 12, line 4
draft-carpenter-v6ops-label-balance-02: clarified after WG draft-carpenter-v6ops-label-balance-02: clarified after WG
discussions, 2012-03-06. discussions, 2012-03-06.
draft-carpenter-v6ops-label-balance-01: updated with community draft-carpenter-v6ops-label-balance-01: updated with community
comments, additional author, 2012-01-17. comments, additional author, 2012-01-17.
draft-carpenter-v6ops-label-balance-00: original version, 2011-10-13. draft-carpenter-v6ops-label-balance-00: original version, 2011-10-13.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
6 (IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, December 2011. Requirements", RFC 6434, December 2011.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, November 2011. "IPv6 Flow Label Specification", RFC 6437, November 2011.
9.2. Informative References 9.2. Informative References
[RFC2629] Rose, M.T., "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.
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
Multicast Next-Hop Selection", RFC 2991, November 2000. Multicast Next-Hop Selection", RFC 2991, November 2000.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864, E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007. May 2007.
[RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for [RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for
 End of changes. 25 change blocks. 
76 lines changed or deleted 86 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/