draft-ietf-dhc-dhcpv6-load-balancing-00.txt   draft-ietf-dhc-dhcpv6-load-balancing-01.txt 
DHC A. Kostur DHC A. Kostur
Internet-Draft Incognito Internet-Draft Incognito
Updates: 3074 (if approved) December 14, 2012 Intended status: Standards Track March 02, 2014
Intended status: Standards Track Expires: September 01, 2014
Expires: June 17, 2013
DHC Load Balancing Algorithm for DHCPv6 DHC Load Balancing Algorithm for DHCPv6
draft-ietf-dhc-dhcpv6-load-balancing-00 draft-ietf-dhc-dhcpv6-load-balancing-01
Abstract Abstract
This document proposes a method of algorithmic load balancing for This document proposes a method of algorithmic load balancing for
IPv6 Dynamic Host Configuration Protocol (DHCPv6) traffic. It IPv6 Dynamic Host Configuration Protocol (DHCPv6) traffic. It
enables multiple, cooperating servers to decide which one should enables multiple, cooperating servers to decide which one should
service a client, without exchanging any information beyond initial service a client, without necessarily exchanging any information
configuration. The server selection is based on the servers hashing between the servers. The server selection is based on the servers
client DHCP Unique Identifiers (DUIDs) when multiple DHCPv6 (DHCPv6) hashing client DHCP Unique Identifiers (DUIDs) when multiple DHCPv6
servers are available to service DHCPv6 clients. The proposed servers are available to service DHCPv6 clients. The proposed
technique provides for efficient server selection when multiple technique provides for efficient server selection when multiple
DHCPv6 servers offer services on a network without requiring any DHCPv6 servers offer services on a network without requiring any
changes to existing DHCPv6 clients. The same method is proposed to changes to existing DHCPv6 clients. This algorithm is an extension
select the target server of a DHCPv6 relay. of an already defined and proven algorithm used for DHCPv4, as
described in RFC 3074.
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 June 17, 2013. This Internet-Draft will expire on September 01, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2014 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/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Background and External Requirements . . . . . . . . . . . . . 3 2. Background and External Requirements . . . . . . . . . . . . . 3
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Messages with a Server ID . . . . . . . . . . . . . . . . . 3 3.1. Messages with a Server Identifier . . . . . . . . . . . . 3
3.1.1. RELEASE, DECLINE, and INFORMATION-REQUEST . . . . . . . 3 3.2. RENEWs with the DHCPv6 servers sharing lease information . 3
3.1.2. REQUEST and RENEW . . . . . . . . . . . . . . . . . . . 3 3.3. RENEWs with the DHCPv6 servers not sharing lease informatio 4
3.2. Selecting the STID . . . . . . . . . . . . . . . . . . . . 4 3.4. Selecting the STID . . . . . . . . . . . . . . . . . . . . 4
3.3. Replacing the secs field . . . . . . . . . . . . . . . . . 4 3.5. Replacing the secs field . . . . . . . . . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
This protocol is intended to extend the algorithm described in RFC This document is intended to extend the algorithm described in DHC
3074 [RFC3074] to apply to DHCPv6 [RFC3315] traffic. Most of the Load Balancing Algorithm [RFC3074] to apply to DHCPv6 [RFC3315]
terminology and procedures are identical to the ones specified in RFC traffic. Most of the terminology and procedures are identical to the
3074. ones specified in RFC 3074. As a short summary: servers which are
participating in load balancing calculate hash values for the Service
Transaction ID (STID) based on client-specific values (the client
DUID for DHCPv6, the Client ID or CHADDR field for DHCPv4) for each
incoming UDP packet. This hash is then used to select a hash bucket.
Servers are assigned to service particular buckets.
1.1. Requirements Language Load balancing is not the same as failover, as load balancing is not
attempting to address any redundancy concerns [RFC6853]. Load
balancing does not attempt to address the issues of configuration or
data synchronization between DHCPv6 servers. However, load balancing
may be desirable in a failover set of servers in order to reduce the
load on the servers in normal operations (see Section 5.3 of
[RFC6853]), and certain desirable behaviors can occur if load
balancing is aware that data synchronization is occurring.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Background and External Requirements 2. Background and External Requirements
The requirements for DHCPv6 are substantially the same as for DHCPv4, The requirements for DHCPv6 are substantially the same as for DHCPv4,
replacing DHCPDISCOVER with SOLICIT, DHCPREQUEST with REQUEST, replacing DHCPDISCOVER with SOLICIT, DHCPREQUEST with REQUEST,
CONFIRM, RENEW, or REBIND (as appropriate), etc. CONFIRM, RENEW, or REBIND (as appropriate), etc.
3. Operation 3. Operation
A DHCPv6 server performing this load balancing will operate in A DHCPv6 server performing this load balancing will operate in
substantially the same manner as if it were a DHCPv4 server load substantially the same manner as if it were a DHCPv4 server load
balancing an incoming DHCPv4/BOOTP packet with the following balancing an incoming DHCPv4/BOOTP packet with the following
differences. differences.
3.1. Messages with a Server ID Load balancing only applies to incoming UDP DHCPv6 messages that
servers would normally process: SOLICIT, REQUEST, CONFIRM, RENEW,
REBIND, RELEASE, DECLINE, INFORMATION-REQUEST, and RECONFIGURE-
REQUEST [RFC6977]. RELAY-FORWARDs are processed based on the content
of the most encapsulated packet (ie: the above listed message types).
Future message types will have to be considered as they are proposed
as to how they may be load balanced.
Certain messages which contain a Server ID to direct that message may LEASEQUERY [RFC5007] messages with a query based on IP SHOULD NOT
need to be handled as if load balancing were not in play. have load balancing applied to them. The Client DUID that is
supplied in a LEASEQUERY message identifies the requestor, and not an
actual client device. This could result in the server which answered
the client device deciding that it should not answer the requestor.
3.1.1. RELEASE, DECLINE, and INFORMATION-REQUEST LEASEQUERY messages with a query based on Client ID SHOULD have load
balancing applied to them, using the Client DUID contained in the
OPTION_LQ_QUERY option for the STID.
A DHCPv6 server receiving a RELEASE, DECLINE, or INFORMATION-REQUEST DHCPV4-QUERY [I-D.ietf-dhc-dhcpv4-over-dhcpv6] messages SHOULD NOT be
with its own Server ID SHOULD answer the answer the message as if load balanced, but should be subject to DHCPv4 load balncing, if the
there were no load balancing in play. Since there is no retry server supports it.
mechanism for RELEASE or DECLINE, or only a simple retransmit for
INFORMATION-REQUEST, if the server were to ignore the message either
the state of the address would be incorrect, or no information would
be transferred to the client even though it was instructed to try the
INFORMATION-REQUEST against this particular server.
3.1.2. REQUEST and RENEW ADVERTISE, REPLY, RELAY-REPL, LEASEQUERY-REPLY, LEASEQUERY-DONE,
LEASEQUERY-DATA, and RECONFIGURE-REPLY are messages which should not
be received by a DHCPv6 server and thus are not considered in this
document.
A DHCPv6 server receiving a REQUEST or RENEW with the server's Server 3.1. Messages with a Server Identifier
ID specified MAY answer the request even if the request would
normally be ignored by load balancing. If there were a pair of
cooperating DHCPv6 servers (perhaps a failover pair), and after a
failure of one of the servers a large portion of the population may
have bound to the second server. When the first server returns to
service, the clients will continue to Renew against the second
server. If the second server ignores the requests, eventually the
client will transition to doing a Rebind, at which point since there
is no Server ID specified, the first server could then answer the
client. The end result would be that the server loads would
eventually become balanced again.
If the secondary server is choosing to continue to respect the load Messages which contain a Server Identifier to direct that message to
balancing in the above case, then the server SHOULD NOT use the a specific server SHOULD be processed as if load balancing were not
Delayed Service Parameter feature for the requests containing the in play, with the exception of RENEWs.
server's Server ID. If the Delayed Service Parameter was still being
used, then it is likely that the client would never reach the
Rebinding state, and the secondary server might as well have answered
the first request that arrived instead of waiting for some number of
seconds before answering.
If the secondary server continues to answer the requests, then the 3.2. RENEWs with the DHCPv6 servers sharing lease information
server load will not rebalance until the clients are rebooted, or A DHCPv6 server receiving a RENEW with the server's Server Identifier
transition to a Rebind through any other mechanism. specified MAY choose to ignore the request if the load balancing
algorithm decides that this server should not process this message.
Let us assume the following sequence of events:
A server MAY choose to answer REQUESTs and ignore RENEWs so that for 1. There is a pair of DHCPv6 servers that are known to be exchanging
the REQUEST it is choosing to not require the client to go through lease information with each other
the entire set of retries and go back to SOLICIT before getting a
response, but ignore RENEWs to cause the devices to switch servers at
the REBIND time.
3.2. Selecting the STID 2. The first server fails and is no longer servicing DHCPv6 clients
3. Some number of DHCPv6 clients are bound to the second DHCPv6
server (whether by performing a SOLCIT-ADVERTISE-REQUEST-REPLY
sequence, or by REBINDing to the second server)
4. The first server is restored to service and is able to service
DHCPv6 clients
At this point, a disproportionate set of DHCPv6 clients are now bound
to the second DHCPv6 server. If the second DHCPv6 server is
permitted to ignore the RENEW even though the Server Identifier would
indicate that it should respond, then the clients which should be
answered by the first server will get no response to the RENEW that
contains the second server's Server Identifier and will perform the
normal retry mechanisms. At some point the client will transition
into the REBIND state and will attempt to REBIND. That REBIND will
not have a Server Identifier and will be received by both DHCPv6
servers. Since the servers were exchanging lease information, the
first DHCPv6 server would have sufficient information to be able to
REPLY to the client to extend the lease and those clients would now
be bound to the first DHCPv6 server again. Over time this would
result in the DHCPv6 population being rebalanced.
3.3. RENEWs with the DHCPv6 servers not sharing lease information
A DHCPv6 server receiving a RENEW with the server's Server Identifier
specified SHOULD be processed as if load balancing were not in play.
If the server ignored these RENEWs, the requesting device would
eventually transition to REBIND, and the other servers may not have
any lease information to answer the REBIND with, forcing the client
to eventually drop its lease and start again from SOLICIT.
3.4. Selecting the STID
DHCPv6 servers MUST use the client's DUID in its entirety as the DHCPv6 servers MUST use the client's DUID in its entirety as the
STID. This is different than RFC 3074 which limited the STID to 16 STID. This is different than RFC 3074 which limited the STID to 16
bytes. bytes.
3.3. Replacing the secs field An INFORMATION-REQUEST may have no client DUID in the message.
Calculate the hash as if a 0-length DUID were supplied, effectively
assigning those messages to hash bucket 0.
A LEASEQUERY based on Client ID MUST use the Client ID contained in
the OPTION_LQ_QUERY option.
3.5. Replacing the secs field
A DHCPv6 server providing the capability of Delayed Service SHOULD A DHCPv6 server providing the capability of Delayed Service SHOULD
use the value in the OPTION_ELAPSED_TIME wherever RFC 3074 makes use the value in the OPTION_ELAPSED_TIME wherever RFC 3074 makes
reference to the secs field. reference to the secs field.
4. Acknowledgements 4. Acknowledgements
Thanks to Bernie Volz, Steve Gonczi, Ted Lemon, and Rob Stevens as Thanks to Bernie Volz, Steve Gonczi, Ted Lemon, and Rob Stevens as
this document heavily borrows from their previous work on RFC 3074, this document heavily borrows from their previous work on RFC 3074,
and Bernie's additional comments during the discussions. as well as Bernie and Tomek Mrugalski's additional comments during
the discussions.
5. IANA Considerations 5. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
6. Security Considerations 6. 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. Servers using this algorithm are impact existing security. Servers using this algorithm are
responsible for ensuring that if the contents of the HBA are responsible for ensuring that if the contents of the HBA are
transmitted over the network as part of the process of configuring transmitted over the network as part of the process of configuring
any server, that message be secured against tampering, since any server, that message be secured against tampering, since
tampering with the HBA could result in denial of service for some or tampering with the HBA could result in denial of service for some or
all clients. all clients.
7. Normative References 7. References
7.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.
[RFC3074] Volz, B., Gonczi, S., Lemon, T., and R. Stevens, "DHC Load [RFC3074] Volz, B., Gonczi, S., Lemon, T. and R. Stevens, "DHC Load
Balancing Algorithm", RFC 3074, February 2001. Balancing Algorithm", RFC 3074, February 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
and M. Carney, "Dynamic Host Configuration Protocol for M. Carney, "Dynamic Host Configuration Protocol for IPv6
IPv6 (DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B. and S. Zeng, "DHCPv6
Leasequery", RFC 5007, September 2007.
[RFC6977] Boucadair, M. and X. Pougnard, "Triggering DHCPv6
Reconfiguration from Relay Agents", RFC 6977, July 2013.
7.2. Informative References
[I-D.ietf-dhc-dhcpv4-over-dhcpv6]
Sun, Q., Cui, Y., Siodelski, M., Krishnan, S. and I.
Farrer, "DHCPv4 over DHCPv6 Transport", Internet-Draft
draft-ietf-dhc-dhcpv4-over-dhcpv6-05, February 2014.
[RFC6853] Brzozowski, J., Tremblay, J., Chen, J. and T. Mrugalski,
"DHCPv6 Redundancy Deployment Considerations", BCP 180,
RFC 6853, February 2013.
Author's Address Author's Address
Andre Kostur Andre Kostur
Incognito Software Inc. Incognito Software Inc.
#500 - 375 Water St. Suite 500 - 375 Water St.
Vancouver, BC V6B 5C6 Vancouver, BC V6B 5C6
CA CA
Phone: +1 604 678 2864 Phone: +1 604 678 2864
Email: akostur@incognito.com Email: akostur@incognito.com
 End of changes. 27 change blocks. 
89 lines changed or deleted 155 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/