draft-ietf-dhc-dhcpv6-loadb-00.txt   draft-ietf-dhc-dhcpv6-loadb-01.txt 
Internet Engineering Task Force B. Volz Internet Engineering Task Force B. Volz
INTERNET DRAFT Ericsson INTERNET DRAFT Ericsson
DHC Working Group Feb 2002 DHC Working Group June 2002
Expires: August 22, 2002 Expires: December 18, 2002
Load Balancing for DHCPv6 Load Balancing for DHCPv6
draft-ietf-dhc-dhcpv6-loadb-00.txt draft-ietf-dhc-dhcpv6-loadb-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 31
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 22, 2002. This Internet-Draft will expire on December 18, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This document specifies a load balancing algorithm for use with This document specifies a load balancing algorithm for use with
DHCPv6. Load balancing enables multiple cooperating DHCPv6 servers DHCPv6. Load balancing enables multiple cooperating DHCPv6 servers
to decide which one should service a client, without exchanging to decide which one should service a client, without exchanging
skipping to change at page 2, line 14 skipping to change at page 2, line 14
3. Terminology 3. Terminology
This document uses terminology specific to IPv6 and DHCPv6 as defined This document uses terminology specific to IPv6 and DHCPv6 as defined
in the "Terminology" section of the DHCP specification [2]. in the "Terminology" section of the DHCP specification [2].
This document uses many of the concepts and terminology specific to This document uses many of the concepts and terminology specific to
load balancing as defined in the "Load Balancing Terminology" section load balancing as defined in the "Load Balancing Terminology" section
of the DHC Load Balancing specification [3]. of the DHC Load Balancing specification [3].
4. DHCPv6 Server Operation 4. Motivation for Load Balancing
DHCP [2] provides for multiple servers to advertise service to the
clients on links. A client is generally offered configuration service
from each of the servers and there is no guarantee of consistency for
the client (a different server may be selected each time).
Load balancing provides a quick and easy way for a server to
determine whether it should service a particular client. Only the
selected server or servers respond to the client instead of all of
the servers. Load balancing provides a means to efficiently and
consistently distribute the processing load for clients across
multiple servers rather than having each server respond to every
client.
In addition, rather than having multiple servers service the same
clients, load balancing allows each server to service a different set
of clients. If a server is down, the other servers may take over the
clients that the downed server was to handle by monitoring the
elapsed time option in client requests.
The load balancing technique described here and in RFC 3074 [3] work
well for request/reply transaction protocols where a consistent
client identifier is available.
For example, a high performance (non-redundant) configuration of DHCP
servers might be as follows:
+---------------+ +---------------+
| DHCP Server 1 | | DHCP Server 2 |
| HBA 0-127 | | HBA 128-255 |
+-------+-------+ +-------+-------+
| |
| |
<---------+-------------------------+-------Network--->
In this example, rather than both servers servicing all clients, each
services appropriate half the clients and each services the same set
of clients consistently. A redundant set of servers could be added
(each configured with appropriate HBAs).
5. DHCPv6 Server Operation
DHCPv6 uses a DUID (DHCP Unique Identifier) to identify clients. The DHCPv6 uses a DUID (DHCP Unique Identifier) to identify clients. The
DUID is carried in most client-generated messages in the Client DUID is carried in most client-generated messages in the Client
Identifier option as described in [2]. The client's DUID is defined Identifier option as described in [2]. The client's DUID is defined
to be the Service Transaction ID (STID) [3]. to be the Service Transaction ID (STID) [3].
DHCPv6 uses two types of client messages, those that are directed to DHCPv6 uses two types of client messages, those that are directed to
a specific server and those that are directed to all servers. The a specific server and those that are directed to all servers. The
messages directed to a specific server contain a Server Identifier messages directed to a specific server contain a Server Identifier
option as described in [2] and include the Request, Renew, Release, option as described in [2]. The messages directed to all servers do
Decline, and Information-Request messages. The messages directed to not include a Server Identifier option.
all servers do not include a Server Identifier option and include
the Solicit, Confirm, Rebind, and Information-Request messages.
For the messages directed to a specific server, this load balancing For the messages directed to a specific server, this load balancing
algorithm does not apply and a server processes that client's algorithm does not apply and a server processes that client's request
request if the Server Identifier option's DUID of the request matches if the Server Identifier option's DUID of the request matches its own
it own and discards all other requests. and discards all other requests.
For the messages directed to all servers, the load balancing For the messages directed to all servers, the load balancing
algorithm MAY be used to limit the clients that a server services algorithm MAY be used to limit the clients that a server services if
if the request contains a Client Identifier option. The server uses the request contains a Client Identifier option. The server uses the
the hash algorithm described in [3] on the client's DUID (the STID) hash algorithm described in [3] on the client's DUID (the STID) and
and uses the resulting hash value to determine if the client is uses the resulting hash value to determine if the client is within
within the server's configured hash bucket assignment (HBA) [3]. If the server's configured hash bucket assignment (HBA) [3]. If the hash
the hash value is assigned to the server, the server MUST process value is assigned to the server, the server MUST process the client
the client request (other server policy may of course determine how request (other server policy may of course determine how the request
the request is processed and whether a reply is sent to the client). is processed and whether a reply is sent to the client). If the hash
If the hash value is not assigned to the server, the server SHOULD value is not assigned to the server, the server SHOULD NOT process
NOT process the request. The server MAY process the request if the the request. The server MAY process the request if the elapsed time
elapsed time value in the Elapsed Time option of the request exceeds value in the Elapsed Time option of the request exceeds a configured
a preconfigured value (the Service Delay or SD in [3]). How the SD is value (the Service Delay or SD in [3]). How the SD is configured for
configured for a server is outside the scope of this document. a server is outside the scope of this document.
For client requests (such as Information-Request messages) which do For client requests which do not contain a Client Identifier option,
not contain a Client Identifier option, there is no STID and thus all there is no STID and thus all servers process these requests.
servers MUST process these requests.
A load balancing server would have the following processing flow for
received client messages:
1. If the Server Identifier option is present in the message,
process the message as per [2].
2. If no Client Identifier option is present in the message,
process the message as per [2].
3. If the Client Identifier option's DUID is within the server's
hash bucket assignment, process as per [2].
4. If the Elapsed Time option is present in the message and its
value exceeds the configured threshold, process as per [2].
5. Otherwise, do not process the message because load balancing
dictates that another server should be processing the message.
The hash bucket assignments for each server must be configured and The hash bucket assignments for each server must be configured and
care must be taken to assign each hash bucket to at least one care must be taken to assign each hash bucket to at least one server.
server. How the hash buckets are configured in servers is outside How the hash buckets are configured in servers is outside the scope
the scope of this document. of this document.
If a single hash bucket is assigned to multiple servers, the logic If a single hash bucket is assigned to multiple servers, the logic a
a client uses to select a server applies (just as if there were client uses to select a server applies (just as if there were
multiple servers for clients without load balancing). For example, multiple servers for clients without load balancing). For example,
each server can be configured with a different server preference each server can be configured with a different server preference
value [2]. value [2].
5. DHCPv6 Relay Operation 6. DHCPv6 Relay Agent Operation
This document does not specify any techniques related to load Relay agents MAY be configured to relay client requests using load
balancing for relays. While a similar approach to that described balancing. A load balancing relay agent must be configured with
in [3] could be used with DHCPv6 relays, further investigation of additional information as to the hash buckets assigned to each
the benefits and complexities this may add to DHCPv6 configurations server, in a manner similar to that presented in [3]. Care must be
is needed before any recommendations can be made. This is an area taken to assure consistent information if both relay agents and
of further work and discussion. servers are configured with load balancing information.
Relays MUST be configured to forward client requests to all of A relay agent would have the following processing flow for received
client messages:
1. If no Client Identifier option is present in the client's
message, relay the message to all configured servers
regardless of hash bucket assignments.
2. Otherwise, use the hash algorithm described in [3] on the DUID
in the Client Identifier option and relay the message to the
server or servers assigned that hash bucket.
Relay agents MUST be configured to forward client requests to all of
the DHCPv6 servers that may be part of a load balancing group. the DHCPv6 servers that may be part of a load balancing group.
6. DHCPv6 Client Operation Note: If relay agents are configured to do load balancing, the
Elapsed Time option will be ineffective in allowing any server (not
just the servers in the load balancing group) to respond to a
client's request.
7. DHCPv6 Client Operation
DHCPv6 clients need not be aware that load balancing is in use by DHCPv6 clients need not be aware that load balancing is in use by
the servers. A client operates as described in [2]. the servers. A client operates as described in [2].
Client operation with respect to load balancing is the same as Client operation with respect to load balancing is the same as
client operation with multiple servers. If a server that was client operation with multiple servers. If a server that was
servicing a client becomes unavailable for some reason, the client servicing a client becomes unavailable for some reason, the client
will eventually time-out and communicate with all servers. When will eventually time-out and communicate with all servers. When
this happens, if there are multiple servers assigned to handle this happens, if there are multiple servers assigned to handle
that client's hash bucket, one or more of these remaining servers that client's hash bucket, one or more of these remaining servers
will respond. If there are no other servers for that hash bucket, will respond. If there are no other servers for that hash bucket,
other servers may respond once the elapsed time value in the other servers may respond once the elapsed time value in the
Elapsed Time option exceeds their configured SD. Elapsed Time option exceeds their configured SD.
If there is only one server (either for all clients or for some If there is only one server (either for all clients or for some
of the hash buckets), failure of that server will prevent clients of the hash buckets), failure of that server will prevent clients
from obtaining or extending the lifetimes of addresses. However, from obtaining or extending the lifetimes of addresses. However,
there is no difference whether load balancing is used or not. there is no difference whether load balancing is used or not.
7. Security Considerations 8. Security Considerations
This proposal in and by itself provides no security, nor does it This proposal in and by itself provides no security, nor does it
impact existing security. See [2] for further details as to DHCPv6 impact existing security. See [2] for further details as to DHCPv6
security issues. security issues.
Servers using load balancing are responsible for ensuring that if Servers using load balancing are responsible for ensuring that if
the contents of the HBA are transmitted over the network as part the contents of the HBA are transmitted over the network as part
of the process of configuring any server, that message be secured of the process of configuring any server, that message be secured
against tampering, since tempering with the HBA could result in a against tampering, since tempering with the HBA could result in a
denial of service for some or all clients. denial of service for some or all clients.
8. Acknowledgements 9. Acknowledgements
Thanks to the DHC Working Group for their time and input into the Thanks to the DHC Working Group for their time and input into the
specification starting at IETF-52. Thanks also to the following specification starting at IETF-52. Thanks also to the following
individuals for their comments and questions (in alphabetical individuals for their comments and questions (in alphabetical
order) Stefan Berg, Herold Fagerberg, Ted Lemon, Tony Lindstrm, order) Stefan Berg, Herold Fagerberg, Ted Lemon, Tony Lindstrom,
Thomas Narten, Anders Strand, and Jack Wong. Thomas Narten, Anders Strand, and Jack Wong.
References References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. [2] Droms (ed.), R., Bound, J., Volz, Bernie, Lemon, Ted, Perkins,
Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 C., Carney, M., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", draft-ietf-dhc-dhcpv6-23 (work in progress), February (DHCPv6)", draft-ietf-dhc-dhcpv6-26 (work in progress), June
2002. 2002.
[3] Volz, B., Gonczi, S., Lemon, T., Stevens, R., "DHC Load [3] Volz, B., Gonczi, S., Lemon, T., Stevens, R., "DHC Load
Balancing Algorithm", RFC 3074, February 2001. Balancing Algorithm", RFC 3074, February 2001.
Author's Address Author's Address
Bernie Volz Bernie Volz
Ericsson Ericsson
959 Concord Street 959 Concord Street
Framingham, MA 01701 Framingham, MA 01701
USA USA
Phone: +1 508 875 3162 Phone: +1 508 875 3162
EMail: bernie.volz@ericsson.com EMail: bernie.volz@ericsson.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1970). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/