DHC                                                            A. Kostur
Internet-Draft                                                 Incognito
Updates: 3074 (if approved)                            December 14, 2012
Intended status: Standards Track                          March 02, 2014
Expires: June 17, 2013 September 01, 2014

                DHC Load Balancing Algorithm for DHCPv6


   This document proposes a method of algorithmic load balancing for
   IPv6 Dynamic Host Configuration Protocol (DHCPv6) traffic.  It
   enables multiple, cooperating servers to decide which one should
   service a client, without necessarily exchanging any information beyond initial
   between the servers.  The server selection is based on the servers
   hashing client DHCP Unique Identifiers (DUIDs) when multiple DHCPv6 (DHCPv6)
   servers are available to service DHCPv6 clients.  The proposed
   technique provides for efficient server selection when multiple
   DHCPv6 servers offer services on a network without requiring any
   changes to existing DHCPv6 clients.  The same method  This algorithm is proposed to
   select the target server an extension
   of a DHCPv6 relay. an already defined and proven algorithm used for DHCPv4, as
   described in RFC 3074.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 17, 2013. September 01, 2014.

Copyright Notice

   Copyright (c) 2012 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) (http://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3  2
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . . . 3  2
   2.  Background and External Requirements . . . . . . . . . . . . .  3
   3.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Messages with a Server ID Identifier  . . . . . . . . . . . .  3
     3.2.  RENEWs with the DHCPv6 servers sharing lease information .  3
     3.3.  RENEWs with the DHCPv6 servers not sharing lease informatio 4
     3.4.  Selecting the STID . . . . . 3
       3.1.1.  RELEASE, DECLINE, and INFORMATION-REQUEST . . . . . . . 3
       3.1.2.  REQUEST and RENEW . . . . . . . .  4
     3.5.  Replacing the secs field . . . . . . . . . . . 3
     3.2.  Selecting the STID . . . . . .  5
   4.  Acknowledgements . . . . . . . . . . . . . . 4
     3.3.  Replacing the secs field . . . . . . . . .  5
   5.  IANA Considerations  . . . . . . . . 4
   4.  Acknowledgements . . . . . . . . . . . . .  5
   6.  Security Considerations  . . . . . . . . . . 4
   5.  IANA Considerations . . . . . . . . .  5
   7.  References . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . .  5
     7.1.  Normative References . . . . . . . 5
   7.  Normative References . . . . . . . . . . . .  5
     7.2.  Informative References . . . . . . . . . . . . . . . . . .  5
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5  6

1.  Introduction

   This protocol document is intended to extend the algorithm described in RFC
   3074 DHC
   Load Balancing Algorithm [RFC3074] to apply to DHCPv6 [RFC3315]
   traffic.  Most of the terminology and procedures are identical to the
   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.

   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",
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Background and External Requirements

   The requirements for DHCPv6 are substantially the same as for DHCPv4,
   CONFIRM, RENEW, or REBIND (as appropriate), etc.

3.  Operation

   A DHCPv6 server performing this load balancing will operate in
   substantially the same manner as if it were a DHCPv4 server load
   balancing an incoming DHCPv4/BOOTP packet with the following

3.1.  Messages with a Server ID

   Certain messages which contain a Server ID

   Load balancing only applies to direct incoming UDP DHCPv6 messages that message may
   need to be handled as if load balancing were not in play.

   servers would normally process: SOLICIT, REQUEST, CONFIRM, RENEW,

   with its own Server ID SHOULD answer RECONFIGURE-
   REQUEST [RFC6977].  RELAY-FORWARDs are processed based on the answer content
   of the most encapsulated packet (ie: the above listed message types).
   Future message types will have to be considered as if
   there were no they are proposed
   as to how they may be load balanced.

   LEASEQUERY [RFC5007] messages with a query based on IP SHOULD NOT
   have load balancing in play.  Since there applied to them.  The Client DUID that is no retry
   mechanism for RELEASE or DECLINE, or only
   supplied in a simple retransmit for
   INFORMATION-REQUEST, if LEASEQUERY message identifies the requestor, and not an
   actual client device.  This could result in the server were which answered
   the client device deciding that it should not answer the requestor.

   LEASEQUERY messages with a query based on Client ID SHOULD have load
   balancing applied to ignore them, using the message either Client DUID contained in the state of
   OPTION_LQ_QUERY option for the address would STID.

   DHCPV4-QUERY [I-D.ietf-dhc-dhcpv4-over-dhcpv6] messages SHOULD NOT be incorrect, or no information would
   load balanced, but should be transferred subject to DHCPv4 load balncing, if the client even though it was instructed
   server supports it.

   LEASEQUERY-DATA, and RECONFIGURE-REPLY are messages which should not
   be received by a DHCPv6 server and thus are not considered in this

3.1.  Messages with a Server Identifier

   Messages which contain a Server Identifier to try direct that message to
   a specific server SHOULD be processed as if load balancing were not
   in play, with the
   INFORMATION-REQUEST against this particular server.

3.1.2.  REQUEST and RENEW exception of RENEWs.

3.2.  RENEWs with the DHCPv6 servers sharing lease information
   A DHCPv6 server receiving a REQUEST or RENEW with the server's Server
   ID Identifier
   specified MAY answer choose to ignore the request even if the request would
   normally be ignored by load balancing.  If there were balancing
   algorithm decides that this server should not process this message.
   Let us assume the following sequence of events:

   1.  There is a pair of
   cooperating DHCPv6 servers (perhaps a failover pair), that are known to be exchanging
       lease information with each other

   2.  The first server fails and after a
   failure of one of the servers a large portion is no longer servicing DHCPv6 clients

   3.  Some number of the population may
   have DHCPv6 clients are bound to the second server.  When the first DHCPv6
       server returns to
   service, the clients will continue (whether by performing a SOLCIT-ADVERTISE-REQUEST-REPLY
       sequence, or by REBINDing to Renew against the second
   server.  If the second server)

   4.  The first server ignores the requests, eventually the
   client will transition is restored to doing a Rebind, at which point since there service and is no Server ID specified, the first server could then answer the
   client.  The end result would be that able to service
       DHCPv6 clients

   At this point, a disproportionate set of DHCPv6 clients are now bound
   to the server loads would
   eventually become balanced again. second DHCPv6 server.  If the secondary second DHCPv6 server is choosing
   permitted to continue to respect ignore the load
   balancing in RENEW even though the above case, Server Identifier would
   indicate that it should respond, then the server SHOULD NOT use clients which should be
   answered by the
   Delayed Service Parameter feature for first server will get no response to the requests containing RENEW that
   contains the second server's Server ID.  If Identifier and will perform the Delayed Service Parameter was still being
   used, then it is likely that
   normal retry mechanisms.  At some point the client would never reach will transition
   into the
   Rebinding state, 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 secondary servers were exchanging lease information, the
   first DHCPv6 server might as well would have answered sufficient information to be able to
   REPLY to the first request that arrived instead of waiting for some number of
   seconds before answering.

   If client to extend the secondary server continues lease and those clients would now
   be bound to answer the requests, then 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 will balancing were not rebalance until in play.
   If the clients are rebooted, or server ignored these RENEWs, the requesting device would
   eventually transition to a Rebind through any REBIND, and the other mechanism.

   A server MAY choose servers may not have
   any lease information to answer REQUESTs and ignore RENEWs so that for the REQUEST it is choosing to not require REBIND with, forcing the client
   to go through
   the entire set of retries eventually drop its lease 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. start again from SOLICIT.

3.4.  Selecting the STID

   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


   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
   use the value in the OPTION_ELAPSED_TIME wherever RFC 3074 makes
   reference to the secs field.

4.  Acknowledgements

   Thanks to Bernie Volz, Steve Gonczi, Ted Lemon, and Rob Stevens as
   this document heavily borrows from their previous work on RFC 3074,
   as well as Bernie and Bernie's Tomek Mrugalski's additional comments during
   the discussions.

5.  IANA Considerations

   This memo includes no request to IANA.

6.  Security Considerations

   This proposal in and by itself provides no security, nor does it
   impact existing security.  Servers using this algorithm are
   responsible for ensuring that if the contents of the HBA are
   transmitted over the network as part of the process of configuring
   any server, that message be secured against tampering, since
   tampering with the HBA could result in denial of service for some or
   all clients.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3074]  Volz, B., Gonczi, S., Lemon, T., T. and R. Stevens, "DHC Load
              Balancing Algorithm", RFC 3074, February 2001.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., C. and
              M. Carney, "Dynamic Host Configuration Protocol for IPv6
              (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

              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

   Andre Kostur
   Incognito Software Inc.
   Suite 500 - 375 Water St.
   Vancouver, BC V6B 5C6

   Phone: +1 604 678 2864
   Email: akostur@incognito.com