draft-ietf-intarea-flow-label-balancing-00.txt | draft-ietf-intarea-flow-label-balancing-01.txt | |||
---|---|---|---|---|
IntArea B. Carpenter | IntArea B. E. Carpenter | |||
Internet-Draft Univ. of Auckland | Internet-Draft Univ. of Auckland | |||
Intended status: Informational S. Jiang | Intended status: Informational S. Jiang | |||
Expires: July 19, 2013 Huawei Technologies Co., Ltd | Expires: November 26, 2013 Huawei Technologies Co., Ltd | |||
W. Tarreau | W. Tarreau | |||
Exceliance | Exceliance | |||
January 15, 2013 | May 25, 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-00 | draft-ietf-intarea-flow-label-balancing-01 | |||
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 | |||
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 19, 2013. | This Internet-Draft will expire on November 26, 2013. | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Summary of Flow Label Specification . . . . . . . . . . . . . 3 | 2. Summary of Flow Label Specification . . . . . . . . . . . . . 2 | |||
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 . . . . . . . . . . . . . . . . . . . . . 10 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | |||
8. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 11 | 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 10 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 | 9.2. Informative References . . . . . . . . . . . . . . . . . 11 | |||
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. This document starts with brief introductions to the | |||
skipping to change at page 3, line 50 | skipping to change at page 3, line 27 | |||
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 | |||
one packet. Therefore, within the lifetime of a given transport | one packet. Therefore, within the lifetime of a given transport | |||
layer connection, the flow label can be a more convenient "handle" | layer connection, the flow label can be a more convenient "handle" | |||
than the port number for identifying that particular connection. | than the port number for identifying that particular connection. | |||
According to RFC 6437, source hosts should set the flow label, but, | According to RFC 6437, source hosts should set the flow label, but, | |||
if they do not (i.e. its value is zero), forwarding nodes (such as | if they do not (i.e., its value is zero), forwarding nodes (such as | |||
the first-hop router) may set it instead. In both cases, the flow | the first-hop router) may set it instead. In both cases, the flow | |||
label value must be constant for a given transport session, normally | label value must be constant for a given transport session, normally | |||
identified by the IPv6 and Transport header 5-tuple. By default, the | identified by the IPv6 and Transport header 5-tuple. By default, the | |||
flow label value should be calculated by a stateless algorithm. The | flow label value should be calculated by a stateless algorithm. The | |||
resulting value should form part of a statistically uniform | resulting value should form part of a statistically uniform | |||
distribution, regardless of which node sets it. | distribution, regardless of which node sets it. | |||
It is recognised that at the time of writing, very few traffic flows | It is recognised that at the time of writing, very few traffic flows | |||
include a non-zero flow label value. The mechanism described below | include a non-zero flow label value. The mechanism described below | |||
is one that can be added to existing load balancing mechanisms, so | is one that can be added to existing load balancing mechanisms, so | |||
skipping to change at page 4, line 46 | skipping to change at page 4, line 25 | |||
3. The flow label field is in an unprotected part of the IPv6 | 3. The flow label field is in an unprotected part of the IPv6 | |||
header, which means that intentional or unintentional changes to | header, which means that intentional or unintentional changes to | |||
its value cannot be easily detected by a receiver. | its value cannot be easily detected by a receiver. | |||
The first two points are addressed below in Section 4 and the third | The first two points are addressed below in Section 4 and the third | |||
in Section 5. | in Section 5. | |||
3. Summary of Load Balancing Techniques | 3. Summary of Load Balancing Techniques | |||
Load balancing for server farms is achieved by a variety of methods, | Load balancing for server farms is achieved by a variety of methods, | |||
often used in combination [Tarreau]. The flow label is not relevant | often used in combination [Tarreau]. This section gives a general | |||
to all of them, and the actual load balancing algorithm (the choice | overview of common methods, although the flow label is not relevant | |||
of which server to use for a new client session) is irrelevant to | to all of them. The actual load balancing algorithm (the choice of | |||
this discussion. | which server to use for a new client session) is irrelevant to this | |||
discussion. | ||||
o The simplest method is simply using the DNS to return different | o The simplest method is simply using the DNS to return different | |||
server addresses for a single name such as www.example.com to | server addresses for a single name such as www.example.com to | |||
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 are listed by the relevant authoritative | which different addresses within the server site are listed by the | |||
DNS server, on the assumption that the client will pick the first | relevant authoritative DNS server, on the assumption that the | |||
one. Routing may be configured such that the different addresses | client will pick the first one. Routing may be configured such | |||
are handled by different ingress routers. The flow label can have | that the different addresses are handled by different ingress | |||
no impact on this method and it is not discussed further. | routers. Several variants of this load balancing mechanism exist, | |||
such as expecting some clients to use all the advertised addresses | ||||
when multiple connections are involved, or directing the traffic | ||||
to multiple sites, also known as global load balancing. None of | ||||
these mechanisms are in the scope of this document, and what this | ||||
document proposes does not affect their usability nor aims to | ||||
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. | |||
skipping to change at page 6, line 8 | skipping to change at page 5, line 43 | |||
the totally stateless ones which only act on packets, generally | the totally stateless ones which only act on packets, generally | |||
involving a per-packet hashing of easy-to-find information such as | involving a per-packet hashing of easy-to-find information such as | |||
the source address and/or port into a server number, and the | the source address and/or port into a server number, and the | |||
stateful ones which take the routing decision on the very first | stateful ones which take the routing decision on the very first | |||
packets of a session and maintain the same direction for all | packets of a session and maintain the same direction for all | |||
packets belonging to the same session. Clearly, both types of | packets belonging to the same session. Clearly, both types of | |||
layer 3/4 balancers could inspect and make use of the flow label | layer 3/4 balancers could inspect and make use of the flow label | |||
value. | 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 | For clarity, note that two aspects of layer 3/4 load balancers are | |||
could not be affected by use of the flow label to identify | not affected by use of the flow label to identify sessions: | |||
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 | |||
to their individual MAC addresses. | to their individual MAC addresses. In this case, return | |||
packets from the server to the client are sent back without | ||||
passing through the balancer, a technique known as direct | ||||
server return, but we are not concerned here with the return | ||||
packets. | ||||
- Each server has its own IP address, and the balancer uses an | - Each server has its own IP address, and the balancer uses an | |||
IP-in-IP tunnel to reach it. | IP-in-IP tunnel to reach it. | |||
- Each server has its own IP address, and the balancer | - Each server has its own IP address, and the balancer | |||
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 maximum layout | |||
with various methods in use together. | ||||
___________________________________________ | ___________________________________________ | |||
( ) | ( ) | |||
( Clients in the Internet ) | ( Clients in the Internet ) | |||
(___________________________________________) | (___________________________________________) | |||
| | | | | | |||
------------ ------------ | ------------ ------------ | |||
| Ingress | | Ingress | | | Ingress | | Ingress | | |||
| router | | router | | | router | | router | | |||
------------ ------------ | ------------ ------------ | |||
___|_______DNS-based____________|___ | ___|_______DNS-based____________|___ | |||
| load splitting | | | load splitting | | |||
| | | | (if used) occurs | | |||
| | | | here | | |||
------------ ------------ | ------------ ------------ | |||
| L3/4 ASIC| | L3/4 ASIC| | | L3/4 ASIC| | L3/4 ASIC| | |||
| balancer | | balancer | | | balancer | | balancer | | |||
------------ ------------ | ------------ ------------ | |||
| load | | | load | | |||
| spreading | | | spreading | | |||
__________|________________________|___________ | __________|________________________|___________ | |||
| | | | | | | | | | |||
------------ ------------ -------- -------- | ------------ ------------ -------- -------- | |||
|HTTP proxy|...|HTTP proxy| | SSL |...| SSL | | |HTTP proxy|...|HTTP proxy| | SSL |...| SSL | | |||
| balancer | | balancer | | proxy| | proxy| | | balancer | | balancer | | proxy| | proxy| | |||
------------ ------------ -------- -------- | ------------ ------------ -------- -------- | |||
____|_____________|_____________|_________|_____ | ____|_____________|_____________|_________|_____ | |||
| | | | | | | | | | | | |||
-------- -------- -------- -------- -------- | -------- -------- -------- -------- -------- | |||
|HTTP | |HTTP | |HTTP | |HTTP | |HTTP | | |HTTP | |HTTP | |HTTP | |HTTP | |HTTP | | |||
|server| |server| |server| |server| |server| | |server| |server| |server| |server| |server| | |||
-------- -------- -------- -------- -------- | -------- -------- -------- -------- -------- | |||
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, so | |||
in this document we focus only on layer 3/4 balancers. | 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 in a load balancing | The suggested model for using the flow label to enhance a L3/L4 load | |||
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. | |||
As the use of the flow label becomes more prevalent according to | As the use of the flow label becomes more prevalent according to | |||
RFC 6434, load balancers, and therefore users, will reap a growing | RFC 6434, load balancers, and therefore users, will reap a growing | |||
performance benefit. | performance benefit. | |||
o If the flow label of an incoming packet is non-zero, layer 3/4 | o If the flow label of an incoming packet is non-zero, layer 3/4 | |||
load balancers can use the 2-tuple {source address, flow label} as | load balancers can use the 2-tuple {source address, flow label} as | |||
the session key for whatever load distribution algorithm they | the session key for whatever load distribution algorithm they | |||
support. If any IPv6 extension headers, including fragment | support. If any IPv6 extension headers, including fragment | |||
headers, are present, this will be significantly quicker than | headers, are present, this will be significantly quicker than | |||
searching for the transport port numbers later in the packet. | searching for the transport port numbers later in the packet. | |||
Moreover, the transport layer information such as the source port | Moreover, the transport layer information such as the source port | |||
is not repeated in fragments, which generally prevents stateless | is not repeated in fragments, which generally prevents stateless | |||
load balancers from supporting fragmented traffic since they | load balancers from supporting fragmented traffic since they | |||
generally cannot reassemble fragments. | generally cannot reassemble fragments. | |||
skipping to change at page 8, line 26 | skipping to change at page 7, line 49 | |||
headers, are present, this will be significantly quicker than | headers, are present, this will be significantly quicker than | |||
searching for the transport port numbers later in the packet. | searching for the transport port numbers later in the packet. | |||
Moreover, the transport layer information such as the source port | Moreover, the transport layer information such as the source port | |||
is not repeated in fragments, which generally prevents stateless | is not repeated in fragments, which generally prevents stateless | |||
load balancers from supporting fragmented traffic since they | load balancers from supporting fragmented traffic since they | |||
generally cannot reassemble fragments. | generally cannot reassemble fragments. | |||
A stateless layer 3/4 load balancer would simply apply a hash | A stateless layer 3/4 load balancer would simply apply a hash | |||
algorithm to the 2-tuple {source address, flow label} on all | algorithm to the 2-tuple {source address, flow label} on all | |||
packets, in order to select the same target server consistently | packets, in order to select the same target server consistently | |||
for a given flow. | for a given flow. Needless to say, the hash algorithm has to be | |||
well chosen for its purpose, but this problem is common to several | ||||
forms of stateless load balancing. The discussion in [RFC6438] | ||||
applies. | ||||
A stateful layer 3/4 load balancer would apply its usual load | A stateful layer 3/4 load balancer would apply its usual load | |||
distribution algorithm to the first packet of a session, and store | distribution algorithm to the first packet of a session, and store | |||
the {2-tuple, server} association in a table so that subsequent | the {2-tuple, server} association in a table so that subsequent | |||
packets belonging to the same session are forwarded to the same | packets belonging to the same session are forwarded to the same | |||
server. Thus, for all subsequent packets of the session, it can | server. Thus, for all subsequent packets of the session, it can | |||
ignore all IPv6 extension headers, which should lead to a | ignore all IPv6 extension headers, which should lead to a | |||
performance benefit. Whether this benefit is valuable will depend | performance benefit. Whether this benefit is valuable will depend | |||
on engineering details of the specific load balancer. | on engineering details of the specific load balancer. | |||
skipping to change at page 9, line 18 | skipping to change at page 8, line 48 | |||
reduced. Additionally, the method will work for fragmented traffic | reduced. Additionally, the method will work for fragmented traffic | |||
and for flows where the transport information is missing (unknown | and for flows where the transport information is missing (unknown | |||
transport protocol) or obfuscated (e.g., IPsec). Traffic reaching | transport protocol) or obfuscated (e.g., IPsec). Traffic reaching | |||
the load balancer via a VPN is particularly prone to the | the load balancer via a VPN is particularly prone to the | |||
fragmentation issue, due to MTU size issues. For some load balancer | fragmentation issue, due to MTU size issues. For some load balancer | |||
designs, these are very significant advantages. | 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. Since this would be a statistically | normal by their port numbers. There are approximately one million | |||
rare event, it would not damage the overall load balancing effect. | possible flow label values, and if the rules for flow label | |||
Moreover, it is very likely that there will be many more flow label | generation [RFC6437] are followed, this would be a statistically rare | |||
values than servers at most sites (1 million possible label values), | event, and would not damage the overall load balancing effect. | |||
so it is already expected that multiple flow label values will end up | ||||
on the same server for a given IP address. | Moreover, with a million possible label values, it is very likely | |||
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 | ||||
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 | statistical assumption is valid for sites that implement network | |||
prefix translation [RFC6296], since this technique provides a | prefix translation [RFC6296], since this technique provides a | |||
skipping to change at page 10, line 44 | skipping to change at page 10, line 29 | |||
New flows are assigned to a server according to any of the usual | New flows are assigned to a server according to any of the usual | |||
algorithms available on the load balancer (e.g., least connections, | algorithms available on the load balancer (e.g., least connections, | |||
round robin, etc.). The association between the flow label value and | round robin, etc.). The association between the flow label value and | |||
the server is stored in a table (often called stick table) so that | the server is stored in a table (often called stick table) so that | |||
future connections using the same flow label can be sent to the same | future connections using the same flow label can be sent to the same | |||
server. This method is more robust against a loss of server and also | server. This method is more robust against a loss of server and also | |||
makes it harder for an attacker to target a specific server, because | makes it harder for an attacker to target a specific server, because | |||
the association between a flow label value and a server is not known | the association between a flow label value and a server is not known | |||
externally. | externally. | |||
In the case that a stateless hash function is used to assign client | ||||
packets to specific servers, it may be advisable to use a | ||||
cryptographic hash function of some kind, to ensure that an attacker | ||||
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, Lorenzo | Valuable comments and contributions were made by Fred Baker, Olivier | |||
Colitti, Joel Jaeggli, Gurudeep Kamat, Warren Kumari, Julia Renouard, | Bonaventure, Lorenzo Colitti, Linda Dunbar, Donald Eastlake, Joel | |||
Julius Volz, and others. | Jaeggli, Gurudeep Kamat, Warren Kumari, Julia 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-01: clarifications based on | ||||
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, | |||
2012-06-12. | 2012-06-12. | |||
draft-carpenter-flow-label-balancing-00: restructured after IETF83, | draft-carpenter-flow-label-balancing-00: restructured after IETF83, | |||
skipping to change at page 11, line 39 | skipping to change at page 11, line 29 | |||
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. and R. Hinden, "Internet Protocol, Version 6 | [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version | |||
(IPv6) Specification", RFC 2460, December 1998. | 6 (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., "Writing I-Ds and RFCs using XML", RFC 2629, | [RFC2629] Rose, M.T., "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 | |||
skipping to change at page 12, line 40 | skipping to change at page 12, line 25 | |||
[Tarreau] Tarreau, W., "Making applications scalable with load | [Tarreau] Tarreau, W., "Making applications scalable with load | |||
balancing", 2006, <http://1wt.eu/articles/2006_lb/>. | balancing", 2006, <http://1wt.eu/articles/2006_lb/>. | |||
Authors' Addresses | Authors' Addresses | |||
Brian Carpenter | Brian Carpenter | |||
Department of Computer Science | Department of Computer Science | |||
University of Auckland | University of Auckland | |||
PB 92019 | PB 92019 | |||
Auckland, 1142 | Auckland 1142 | |||
New Zealand | New Zealand | |||
Email: brian.e.carpenter@gmail.com | Email: brian.e.carpenter@gmail.com | |||
Sheng Jiang | Sheng Jiang | |||
Huawei Technologies Co., Ltd | Huawei Technologies Co., Ltd | |||
Q14, Huawei Campus | Q14, Huawei Campus | |||
No.156 Beiqing Road | No.156 Beiqing Road | |||
Hai-Dian District, Beijing 100095 | Hai-Dian District, Beijing 100095 | |||
P.R. China | P.R. China | |||
Email: jiangsheng@huawei.com | Email: jiangsheng@huawei.com | |||
Willy Tarreau | Willy Tarreau | |||
End of changes. 27 change blocks. | ||||
80 lines changed or deleted | 111 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/ |