draft-ietf-dhc-dhcpv6-load-balancing-01.txt		draft-ietf-dhc-dhcpv6-load-balancing-02.txt
	DHC A. Kostur		DHC A. Kostur
	Internet-Draft Incognito		Internet-Draft Incognito
	Intended status: Standards Track March 02, 2014		Intended status: Standards Track July 04, 2014
	Expires: September 01, 2014		Expires: January 03, 2015
	DHC Load Balancing Algorithm for DHCPv6		Load Balancing for DHCPv6
	draft-ietf-dhc-dhcpv6-load-balancing-01		draft-ietf-dhc-dhcpv6-load-balancing-02
	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 necessarily exchanging any information		service a client, without necessarily exchanging any information
	between the servers. The server selection is based on the servers		between the servers. The server selection is based on the servers
	hashing client DHCP Unique Identifiers (DUIDs) when multiple 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
	skipping to change at page 1, line 41		skipping to change at page 1, line 41
	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 September 01, 2014.		This Internet-Draft will expire on January 03, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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 (http://trustee.ietf.org/		Provisions Relating to IETF Documents (http://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Background and External Requirements . . . . . . . . . . . . . 3		2. Background and External Requirements . . . . . . . . . . . . . 3
	3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Messages with a Server Identifier . . . . . . . . . . . . 3		3.1. Messages with a Server Identifier . . . . . . . . . . . . 3
	3.2. RENEWs with the DHCPv6 servers sharing lease information . 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.3. RENEWs with the DHCPv6 servers not sharing lease informatio 4
	3.4. Selecting the STID . . . . . . . . . . . . . . . . . . . . 4		3.4. Selecting the STID . . . . . . . . . . . . . . . . . . . . 4
	3.5. Replacing the secs field . . . . . . . . . . . . . . . . . 5		3.5. Replacing the secs field . . . . . . . . . . . . . . . . . 4
	4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5		4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 5		6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 5		7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
	7.2. Informative References . . . . . . . . . . . . . . . . . . 5		7.2. Informative References . . . . . . . . . . . . . . . . . . 6
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
	1. Introduction		1. Introduction
	This document is intended to extend the algorithm described in DHC		This document is intended to extend the algorithm described in DHC
	Load Balancing Algorithm [RFC3074] to apply to DHCPv6 [RFC3315]		Load Balancing Algorithm [RFC3074] to apply to DHCPv6 [RFC3315]
	traffic. Most of the terminology and procedures are identical to the		traffic. Most of the terminology and procedures are identical to the
	ones specified in RFC 3074. As a short summary: servers which are		ones specified in RFC 3074. As a short summary: servers which are
	participating in load balancing calculate hash values for the Service		participating in load balancing calculate hash values for the Service
	Transaction ID (STID) based on client-specific values (the client		Transaction ID (STID) based on client-specific values (the client
	DUID for DHCPv6, the Client ID or CHADDR field for DHCPv4) for each		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.		incoming UDP packet. This hash is then used to select a hash bucket.
	Servers are assigned to service particular buckets.		Servers are assigned to service particular buckets.
	Load balancing is not the same as failover, as load balancing is not		Load balancing is not the same as failover, as load balancing is not
	attempting to address any redundancy concerns [RFC6853]. Load		attempting to address any redundancy concerns [RFC6853]. Load
	balancing does not attempt to address the issues of configuration or		balancing does not attempt to address the issues of configuration or
	data synchronization between DHCPv6 servers. However, load balancing		data synchronization between DHCPv6 servers. However, load balancing
	may be desirable in a failover set of servers in order to reduce the		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		load on the servers in normal operations, and certain desirable
	[RFC6853]), and certain desirable behaviors can occur if load		behaviors can occur if load balancing is aware that data
	balancing is aware that data synchronization is occurring.		synchronization is occurring.
	1.1. Requirements Language		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.
	skipping to change at page 3, line 21		skipping to change at page 3, line 28
	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.
	Load balancing only applies to incoming UDP DHCPv6 messages that		Load balancing only applies to incoming client-originated UDP DHCPv6
	servers would normally process: SOLICIT, REQUEST, CONFIRM, RENEW,		messages. RELAY-FORWs are processed based on the content of the most
	REBIND, RELEASE, DECLINE, INFORMATION-REQUEST, and RECONFIGURE-		encapsulated packet (ie: the client-originated DHCPv6 message).
	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		Future message types will have to be considered as they are proposed
	as to how they may be load balanced.		as to how they may be load balanced.
	LEASEQUERY [RFC5007] messages with a query based on IP SHOULD NOT		LEASEQUERY [RFC5007] messages MUST NOT be load balanced. Devices
	have load balancing applied to them. The Client DUID that is		which are sending LEASEQUERY packets will have to be sending those
	supplied in a LEASEQUERY message identifies the requestor, and not an		packets to all of the load balanced DHCPv6 servers, and the
	actual client device. This could result in the server which answered		LEASEQUERY specification already considers what the device should do
	the client device deciding that it should not answer the requestor.		when it receives responses to the LEASEQUERY from multiple sources.
	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.
	DHCPV4-QUERY [I-D.ietf-dhc-dhcpv4-over-dhcpv6] messages SHOULD NOT be		DHCPV4-QUERY [I-D.ietf-dhc-dhcpv4-over-dhcpv6] messages SHOULD NOT be
	load balanced, but should be subject to DHCPv4 load balncing, if the		load balanced, but SHOULD be subject to DHCPv4 load balancing, if the
	server supports it.		server supports it.
	ADVERTISE, REPLY, RELAY-REPL, LEASEQUERY-REPLY, LEASEQUERY-DONE,		ADVERTISE, REPLY, RELAY-REPL, LEASEQUERY-REPLY, and RECONFIGURE-REPLY
	LEASEQUERY-DATA, and RECONFIGURE-REPLY are messages which should not		[RFC6977] are messages which should not be received by a DHCPv6
	be received by a DHCPv6 server and thus are not considered in this		server and thus are not considered in this document.
	document.
	3.1. Messages with a Server Identifier		3.1. Messages with a Server Identifier
	Messages which contain a Server Identifier to direct that message to		Messages which contain a Server Identifier to direct that message to
	a specific server SHOULD be processed as if load balancing were not		a specific server SHOULD be processed as if load balancing were not
	in play, with the exception of RENEWs.		in play, with the exception of RENEWs.
	3.2. RENEWs with the DHCPv6 servers sharing lease information		3.2. RENEWs with the DHCPv6 servers sharing lease information
	A DHCPv6 server receiving a RENEW with the server's Server Identifier		A DHCPv6 server receiving a RENEW with the server's Server Identifier
	specified MAY choose to ignore the request if the load balancing		specified MAY choose to ignore the request if the load balancing
	skipping to change at page 4, line 55		skipping to change at page 4, line 55
	3.4. Selecting the STID		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.
	An INFORMATION-REQUEST may have no client DUID in the message.		An INFORMATION-REQUEST may have no client DUID in the message.
	Calculate the hash as if a 0-length DUID were supplied, effectively		Calculate the hash as if a 0-length DUID were supplied, effectively
	assigning those messages to hash bucket 0.		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		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,
	as well as Bernie and Tomek Mrugalski's additional comments during		as well as Bernie and Tomek Mrugalski's additional comments during
	the discussions.		the discussions.
	skipping to change at page 5, line 26		skipping to change at page 5, line 23
	the discussions.		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 hash bucket
	transmitted over the network as part of the process of configuring		assignments are transmitted over the network as part of the process
	any server, that message be secured against tampering, since		of configuring any server, that message be secured against tampering,
	tampering with the HBA could result in denial of service for some or		since tampering with the HBA could result in denial of service for
	all clients.		some or all clients.
			If the hash bucket assignments are not configured such that each
			bucket is assigned to one and only one DHCP server, this results in
			some clients that will be either completely ignored by the DHCP
			servers (if no server is configured to answer that hash bucket), or
			get multiple responses (if more than one server is configured to
			answer that hash bucket).
	7. References		7. References
	7.1. Normative References		7.1. Normative 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.
	[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. and		[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
	M. Carney, "Dynamic Host Configuration Protocol for IPv6		M. Carney, "Dynamic Host Configuration Protocol for IPv6
	(DHCPv6)", RFC 3315, July 2003.		(DHCPv6)", RFC 3315, July 2003.
	[RFC5007] Brzozowski, J., Kinnear, K., Volz, B. and S. Zeng, "DHCPv6		[RFC5007] Brzozowski, J., Kinnear, K., Volz, B. and S. Zeng, "DHCPv6
	Leasequery", RFC 5007, September 2007.		Leasequery", RFC 5007, September 2007.
	[RFC6977] Boucadair, M. and X. Pougnard, "Triggering DHCPv6		[RFC6977] Boucadair, M. and X. Pougnard, "Triggering DHCPv6
	Reconfiguration from Relay Agents", RFC 6977, July 2013.		Reconfiguration from Relay Agents", RFC 6977, July 2013.
	7.2. Informative References		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,		[RFC6853] Brzozowski, J., Tremblay, J., Chen, J. and T. Mrugalski,
	"DHCPv6 Redundancy Deployment Considerations", BCP 180,		"DHCPv6 Redundancy Deployment Considerations", BCP 180,
	RFC 6853, February 2013.		RFC 6853, February 2013.
	Author's Address		Author's Address
	Andre Kostur		Andre Kostur
	Incognito Software Inc.		Incognito Software Inc.
	Suite 500 - 375 Water St.		Suite 500 - 375 Water St.
	Vancouver, BC V6B 5C6		Vancouver, BC V6B 5C6
End of changes. 17 change blocks.
	44 lines changed or deleted		41 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/