idnits 2.17.1 draft-ietf-dhc-dhcpv6-load-balancing-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 02, 2014) is 3706 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-dhcpv6-05 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC A. Kostur 3 Internet-Draft Incognito 4 Intended status: Standards Track March 02, 2014 5 Expires: September 01, 2014 7 DHC Load Balancing Algorithm for DHCPv6 8 draft-ietf-dhc-dhcpv6-load-balancing-01 10 Abstract 12 This document proposes a method of algorithmic load balancing for 13 IPv6 Dynamic Host Configuration Protocol (DHCPv6) traffic. It 14 enables multiple, cooperating servers to decide which one should 15 service a client, without necessarily exchanging any information 16 between the servers. The server selection is based on the servers 17 hashing client DHCP Unique Identifiers (DUIDs) when multiple DHCPv6 18 servers are available to service DHCPv6 clients. The proposed 19 technique provides for efficient server selection when multiple 20 DHCPv6 servers offer services on a network without requiring any 21 changes to existing DHCPv6 clients. This algorithm is an extension 22 of an already defined and proven algorithm used for DHCPv4, as 23 described in RFC 3074. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 01, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 60 2. Background and External Requirements . . . . . . . . . . . . . 3 61 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Messages with a Server Identifier . . . . . . . . . . . . 3 63 3.2. RENEWs with the DHCPv6 servers sharing lease information . 3 64 3.3. RENEWs with the DHCPv6 servers not sharing lease informatio 4 65 3.4. Selecting the STID . . . . . . . . . . . . . . . . . . . . 4 66 3.5. Replacing the secs field . . . . . . . . . . . . . . . . . 5 67 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 This document is intended to extend the algorithm described in DHC 78 Load Balancing Algorithm [RFC3074] to apply to DHCPv6 [RFC3315] 79 traffic. Most of the terminology and procedures are identical to the 80 ones specified in RFC 3074. As a short summary: servers which are 81 participating in load balancing calculate hash values for the Service 82 Transaction ID (STID) based on client-specific values (the client 83 DUID for DHCPv6, the Client ID or CHADDR field for DHCPv4) for each 84 incoming UDP packet. This hash is then used to select a hash bucket. 85 Servers are assigned to service particular buckets. 87 Load balancing is not the same as failover, as load balancing is not 88 attempting to address any redundancy concerns [RFC6853]. Load 89 balancing does not attempt to address the issues of configuration or 90 data synchronization between DHCPv6 servers. However, load balancing 91 may be desirable in a failover set of servers in order to reduce the 92 load on the servers in normal operations (see Section 5.3 of 93 [RFC6853]), and certain desirable behaviors can occur if load 94 balancing is aware that data synchronization is occurring. 96 1.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2. Background and External Requirements 103 The requirements for DHCPv6 are substantially the same as for DHCPv4, 104 replacing DHCPDISCOVER with SOLICIT, DHCPREQUEST with REQUEST, 105 CONFIRM, RENEW, or REBIND (as appropriate), etc. 107 3. Operation 109 A DHCPv6 server performing this load balancing will operate in 110 substantially the same manner as if it were a DHCPv4 server load 111 balancing an incoming DHCPv4/BOOTP packet with the following 112 differences. 114 Load balancing only applies to incoming UDP DHCPv6 messages that 115 servers would normally process: SOLICIT, REQUEST, CONFIRM, RENEW, 116 REBIND, RELEASE, DECLINE, INFORMATION-REQUEST, and RECONFIGURE- 117 REQUEST [RFC6977]. RELAY-FORWARDs are processed based on the content 118 of the most encapsulated packet (ie: the above listed message types). 119 Future message types will have to be considered as they are proposed 120 as to how they may be load balanced. 122 LEASEQUERY [RFC5007] messages with a query based on IP SHOULD NOT 123 have load balancing applied to them. The Client DUID that is 124 supplied in a LEASEQUERY message identifies the requestor, and not an 125 actual client device. This could result in the server which answered 126 the client device deciding that it should not answer the requestor. 128 LEASEQUERY messages with a query based on Client ID SHOULD have load 129 balancing applied to them, using the Client DUID contained in the 130 OPTION_LQ_QUERY option for the STID. 132 DHCPV4-QUERY [I-D.ietf-dhc-dhcpv4-over-dhcpv6] messages SHOULD NOT be 133 load balanced, but should be subject to DHCPv4 load balncing, if the 134 server supports it. 136 ADVERTISE, REPLY, RELAY-REPL, LEASEQUERY-REPLY, LEASEQUERY-DONE, 137 LEASEQUERY-DATA, and RECONFIGURE-REPLY are messages which should not 138 be received by a DHCPv6 server and thus are not considered in this 139 document. 141 3.1. Messages with a Server Identifier 143 Messages which contain a Server Identifier to direct that message to 144 a specific server SHOULD be processed as if load balancing were not 145 in play, with the exception of RENEWs. 147 3.2. RENEWs with the DHCPv6 servers sharing lease information 148 A DHCPv6 server receiving a RENEW with the server's Server Identifier 149 specified MAY choose to ignore the request if the load balancing 150 algorithm decides that this server should not process this message. 151 Let us assume the following sequence of events: 153 1. There is a pair of DHCPv6 servers that are known to be exchanging 154 lease information with each other 156 2. The first server fails and is no longer servicing DHCPv6 clients 158 3. Some number of DHCPv6 clients are bound to the second DHCPv6 159 server (whether by performing a SOLCIT-ADVERTISE-REQUEST-REPLY 160 sequence, or by REBINDing to the second server) 162 4. The first server is restored to service and is able to service 163 DHCPv6 clients 165 At this point, a disproportionate set of DHCPv6 clients are now bound 166 to the second DHCPv6 server. If the second DHCPv6 server is 167 permitted to ignore the RENEW even though the Server Identifier would 168 indicate that it should respond, then the clients which should be 169 answered by the first server will get no response to the RENEW that 170 contains the second server's Server Identifier and will perform the 171 normal retry mechanisms. At some point the client will transition 172 into the REBIND state and will attempt to REBIND. That REBIND will 173 not have a Server Identifier and will be received by both DHCPv6 174 servers. Since the servers were exchanging lease information, the 175 first DHCPv6 server would have sufficient information to be able to 176 REPLY to the client to extend the lease and those clients would now 177 be bound to the first DHCPv6 server again. Over time this would 178 result in the DHCPv6 population being rebalanced. 180 3.3. RENEWs with the DHCPv6 servers not sharing lease information 182 A DHCPv6 server receiving a RENEW with the server's Server Identifier 183 specified SHOULD be processed as if load balancing were not in play. 184 If the server ignored these RENEWs, the requesting device would 185 eventually transition to REBIND, and the other servers may not have 186 any lease information to answer the REBIND with, forcing the client 187 to eventually drop its lease and start again from SOLICIT. 189 3.4. Selecting the STID 191 DHCPv6 servers MUST use the client's DUID in its entirety as the 192 STID. This is different than RFC 3074 which limited the STID to 16 193 bytes. 195 An INFORMATION-REQUEST may have no client DUID in the message. 196 Calculate the hash as if a 0-length DUID were supplied, effectively 197 assigning those messages to hash bucket 0. 199 A LEASEQUERY based on Client ID MUST use the Client ID contained in 200 the OPTION_LQ_QUERY option. 202 3.5. Replacing the secs field 204 A DHCPv6 server providing the capability of Delayed Service SHOULD 205 use the value in the OPTION_ELAPSED_TIME wherever RFC 3074 makes 206 reference to the secs field. 208 4. Acknowledgements 210 Thanks to Bernie Volz, Steve Gonczi, Ted Lemon, and Rob Stevens as 211 this document heavily borrows from their previous work on RFC 3074, 212 as well as Bernie and Tomek Mrugalski's additional comments during 213 the discussions. 215 5. IANA Considerations 217 This memo includes no request to IANA. 219 6. Security Considerations 221 This proposal in and by itself provides no security, nor does it 222 impact existing security. Servers using this algorithm are 223 responsible for ensuring that if the contents of the HBA are 224 transmitted over the network as part of the process of configuring 225 any server, that message be secured against tampering, since 226 tampering with the HBA could result in denial of service for some or 227 all clients. 229 7. References 231 7.1. Normative References 233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 234 Requirement Levels", BCP 14, RFC 2119, March 1997. 236 [RFC3074] Volz, B., Gonczi, S., Lemon, T. and R. Stevens, "DHC Load 237 Balancing Algorithm", RFC 3074, February 2001. 239 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 240 M. Carney, "Dynamic Host Configuration Protocol for IPv6 241 (DHCPv6)", RFC 3315, July 2003. 243 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B. and S. Zeng, "DHCPv6 244 Leasequery", RFC 5007, September 2007. 246 [RFC6977] Boucadair, M. and X. Pougnard, "Triggering DHCPv6 247 Reconfiguration from Relay Agents", RFC 6977, July 2013. 249 7.2. Informative References 251 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 252 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S. and I. 253 Farrer, "DHCPv4 over DHCPv6 Transport", Internet-Draft 254 draft-ietf-dhc-dhcpv4-over-dhcpv6-05, February 2014. 256 [RFC6853] Brzozowski, J., Tremblay, J., Chen, J. and T. Mrugalski, 257 "DHCPv6 Redundancy Deployment Considerations", BCP 180, 258 RFC 6853, February 2013. 260 Author's Address 262 Andre Kostur 263 Incognito Software Inc. 264 Suite 500 - 375 Water St. 265 Vancouver, BC V6B 5C6 266 CA 268 Phone: +1 604 678 2864 269 Email: akostur@incognito.com