[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-kostur-dhc-loadbv6) 00 01 02

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


                DHC Load Balancing Algorithm for DHCPv6
                draft-ietf-dhc-dhcpv6-load-balancing-00

Abstract

   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 exchanging any information beyond initial
   configuration.  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 is proposed to
   select the target server of a DHCPv6 relay.

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.

Copyright Notice

   Copyright (c) 2012 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



Kostur                    Expires June 17, 2013                 [Page 1]


Internet-Draft   DHC Load Balancing Algorithm for DHCPv6   December 2012


   (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
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Background and External Requirements  . . . . . . . . . . . . . 3
   3.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Messages with a Server ID . . . . . . . . . . . . . . . . . 3
       3.1.1.  RELEASE, DECLINE, and INFORMATION-REQUEST . . . . . . . 3
       3.1.2.  REQUEST and RENEW . . . . . . . . . . . . . . . . . . . 3
     3.2.  Selecting the STID  . . . . . . . . . . . . . . . . . . . . 4
     3.3.  Replacing the secs field  . . . . . . . . . . . . . . . . . 4
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5


























Kostur                    Expires June 17, 2013                 [Page 2]


Internet-Draft   DHC Load Balancing Algorithm for DHCPv6   December 2012


1.  Introduction

   This protocol is intended to extend the algorithm described in RFC
   3074 [RFC3074] to apply to DHCPv6 [RFC3315] traffic.  Most of the
   terminology and procedures are identical to the ones specified in RFC
   3074.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   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,
   replacing DHCPDISCOVER with SOLICIT, DHCPREQUEST with REQUEST,
   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
   differences.

3.1.  Messages with a Server ID

   Certain messages which contain a Server ID to direct that message may
   need to be handled as if load balancing were not in play.

3.1.1.  RELEASE, DECLINE, and INFORMATION-REQUEST

   A DHCPv6 server receiving a RELEASE, DECLINE, or INFORMATION-REQUEST
   with its own Server ID SHOULD answer the answer the message as if
   there were no load balancing in play.  Since there is no retry
   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

   A DHCPv6 server receiving a REQUEST or RENEW with the server's Server
   ID specified MAY answer the request even if the request would



Kostur                    Expires June 17, 2013                 [Page 3]


Internet-Draft   DHC Load Balancing Algorithm for DHCPv6   December 2012


   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
   balancing in the above case, then the server SHOULD NOT use the
   Delayed Service Parameter feature for the requests containing the
   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
   server load will not rebalance until the clients are rebooted, or
   transition to a Rebind through any other mechanism.

   A server MAY choose to answer REQUESTs and ignore RENEWs so that for
   the REQUEST it is choosing to not require the client to go through
   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

   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
   bytes.

3.3.  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,
   and Bernie's additional comments during the discussions.



Kostur                    Expires June 17, 2013                 [Page 4]


Internet-Draft   DHC Load Balancing Algorithm for DHCPv6   December 2012


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.  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., and R. Stevens, "DHC Load
              Balancing Algorithm", RFC 3074, February 2001.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.


Author's Address

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

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












Kostur                    Expires June 17, 2013                 [Page 5]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/