DHC Load Balancing Algorithm for DHCPv6
draft-kostur-dhc-loadbv6-02

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 May 11, 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 (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
• 1.1. Requirements Language
• 2. Background and External Requirements
• 3. Operation
• 3.1. Requests with a Server ID
• 3.2. Selecting the STID
• 3.3. Replacing the secs field
• 4. Acknowledgements
• 5. IANA Considerations
• 6. Security Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Author's Address

1. Introduction

This protocol is intended to extend the algorithm described in RFC 3074 [RFC3074] to apply to DHCPv6 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 two differences.

3.1. Requests with a Server ID

A DHCPv6 server receiving a RELEASE, DECLINE, or INFORMATION-REQUEST with the server's Server ID MUST NOT consider load balancing for the message. 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-REQEUST against this particular server.

A DHCPv6 server receiving a RENEW with the server's Server 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 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 second 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.

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.

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

7.2. Informative References

Author's Address