idnits 2.17.1 draft-ietf-dhc-dhcpv6-loadb-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 6) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7957 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) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-26 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force B. Volz 2 INTERNET DRAFT Ericsson 3 DHC Working Group June 2002 4 Expires: December 18, 2002 6 Load Balancing for DHCPv6 7 draft-ietf-dhc-dhcpv6-loadb-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on December 18, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This document specifies a load balancing algorithm for use with 39 DHCPv6. Load balancing enables multiple cooperating DHCPv6 servers 40 to decide which one should service a client, without exchanging 41 any information beyond initial configuration. It expands on RFC 42 3074 "DHC Load Balancing Algorithm" to include DHCPv6. 44 1. Introduction 46 This document extends the load balancing concepts described in 47 RFC 3074 "DHC Load Balancing Algorithm" [3] to DHCPv6 [2]. 49 2. Requirements 51 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 52 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 53 document, are to be interpreted as described in RFC 2119 [1]. 55 3. Terminology 57 This document uses terminology specific to IPv6 and DHCPv6 as defined 58 in the "Terminology" section of the DHCP specification [2]. 60 This document uses many of the concepts and terminology specific to 61 load balancing as defined in the "Load Balancing Terminology" section 62 of the DHC Load Balancing specification [3]. 64 4. Motivation for Load Balancing 66 DHCP [2] provides for multiple servers to advertise service to the 67 clients on links. A client is generally offered configuration service 68 from each of the servers and there is no guarantee of consistency for 69 the client (a different server may be selected each time). 71 Load balancing provides a quick and easy way for a server to 72 determine whether it should service a particular client. Only the 73 selected server or servers respond to the client instead of all of 74 the servers. Load balancing provides a means to efficiently and 75 consistently distribute the processing load for clients across 76 multiple servers rather than having each server respond to every 77 client. 79 In addition, rather than having multiple servers service the same 80 clients, load balancing allows each server to service a different set 81 of clients. If a server is down, the other servers may take over the 82 clients that the downed server was to handle by monitoring the 83 elapsed time option in client requests. 85 The load balancing technique described here and in RFC 3074 [3] work 86 well for request/reply transaction protocols where a consistent 87 client identifier is available. 89 For example, a high performance (non-redundant) configuration of DHCP 90 servers might be as follows: 92 +---------------+ +---------------+ 93 | DHCP Server 1 | | DHCP Server 2 | 94 | HBA 0-127 | | HBA 128-255 | 95 +-------+-------+ +-------+-------+ 96 | | 97 | | 98 <---------+-------------------------+-------Network---> 100 In this example, rather than both servers servicing all clients, each 101 services appropriate half the clients and each services the same set 102 of clients consistently. A redundant set of servers could be added 103 (each configured with appropriate HBAs). 105 5. DHCPv6 Server Operation 107 DHCPv6 uses a DUID (DHCP Unique Identifier) to identify clients. The 108 DUID is carried in most client-generated messages in the Client 109 Identifier option as described in [2]. The client's DUID is defined 110 to be the Service Transaction ID (STID) [3]. 112 DHCPv6 uses two types of client messages, those that are directed to 113 a specific server and those that are directed to all servers. The 114 messages directed to a specific server contain a Server Identifier 115 option as described in [2]. The messages directed to all servers do 116 not include a Server Identifier option. 118 For the messages directed to a specific server, this load balancing 119 algorithm does not apply and a server processes that client's request 120 if the Server Identifier option's DUID of the request matches its own 121 and discards all other requests. 123 For the messages directed to all servers, the load balancing 124 algorithm MAY be used to limit the clients that a server services if 125 the request contains a Client Identifier option. The server uses the 126 hash algorithm described in [3] on the client's DUID (the STID) and 127 uses the resulting hash value to determine if the client is within 128 the server's configured hash bucket assignment (HBA) [3]. If the hash 129 value is assigned to the server, the server MUST process the client 130 request (other server policy may of course determine how the request 131 is processed and whether a reply is sent to the client). If the hash 132 value is not assigned to the server, the server SHOULD NOT process 133 the request. The server MAY process the request if the elapsed time 134 value in the Elapsed Time option of the request exceeds a configured 135 value (the Service Delay or SD in [3]). How the SD is configured for 136 a server is outside the scope of this document. 138 For client requests which do not contain a Client Identifier option, 139 there is no STID and thus all servers process these requests. 141 A load balancing server would have the following processing flow for 142 received client messages: 144 1. If the Server Identifier option is present in the message, 145 process the message as per [2]. 147 2. If no Client Identifier option is present in the message, 148 process the message as per [2]. 150 3. If the Client Identifier option's DUID is within the server's 151 hash bucket assignment, process as per [2]. 153 4. If the Elapsed Time option is present in the message and its 154 value exceeds the configured threshold, process as per [2]. 156 5. Otherwise, do not process the message because load balancing 157 dictates that another server should be processing the message. 159 The hash bucket assignments for each server must be configured and 160 care must be taken to assign each hash bucket to at least one server. 161 How the hash buckets are configured in servers is outside the scope 162 of this document. 164 If a single hash bucket is assigned to multiple servers, the logic a 165 client uses to select a server applies (just as if there were 166 multiple servers for clients without load balancing). For example, 167 each server can be configured with a different server preference 168 value [2]. 170 6. DHCPv6 Relay Agent Operation 172 Relay agents MAY be configured to relay client requests using load 173 balancing. A load balancing relay agent must be configured with 174 additional information as to the hash buckets assigned to each 175 server, in a manner similar to that presented in [3]. Care must be 176 taken to assure consistent information if both relay agents and 177 servers are configured with load balancing information. 179 A relay agent would have the following processing flow for received 180 client messages: 182 1. If no Client Identifier option is present in the client's 183 message, relay the message to all configured servers 184 regardless of hash bucket assignments. 186 2. Otherwise, use the hash algorithm described in [3] on the DUID 187 in the Client Identifier option and relay the message to the 188 server or servers assigned that hash bucket. 190 Relay agents MUST be configured to forward client requests to all of 191 the DHCPv6 servers that may be part of a load balancing group. 193 Note: If relay agents are configured to do load balancing, the 194 Elapsed Time option will be ineffective in allowing any server (not 195 just the servers in the load balancing group) to respond to a 196 client's request. 198 7. DHCPv6 Client Operation 200 DHCPv6 clients need not be aware that load balancing is in use by 201 the servers. A client operates as described in [2]. 203 Client operation with respect to load balancing is the same as 204 client operation with multiple servers. If a server that was 205 servicing a client becomes unavailable for some reason, the client 206 will eventually time-out and communicate with all servers. When 207 this happens, if there are multiple servers assigned to handle 208 that client's hash bucket, one or more of these remaining servers 209 will respond. If there are no other servers for that hash bucket, 210 other servers may respond once the elapsed time value in the 211 Elapsed Time option exceeds their configured SD. 213 If there is only one server (either for all clients or for some 214 of the hash buckets), failure of that server will prevent clients 215 from obtaining or extending the lifetimes of addresses. However, 216 there is no difference whether load balancing is used or not. 218 8. Security Considerations 220 This proposal in and by itself provides no security, nor does it 221 impact existing security. See [2] for further details as to DHCPv6 222 security issues. 224 Servers using load balancing are responsible for ensuring that if 225 the contents of the HBA are transmitted over the network as part 226 of the process of configuring any server, that message be secured 227 against tampering, since tempering with the HBA could result in a 228 denial of service for some or all clients. 230 9. Acknowledgements 232 Thanks to the DHC Working Group for their time and input into the 233 specification starting at IETF-52. Thanks also to the following 234 individuals for their comments and questions (in alphabetical 235 order) Stefan Berg, Herold Fagerberg, Ted Lemon, Tony Lindstrom, 236 Thomas Narten, Anders Strand, and Jack Wong. 238 References 240 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 241 Levels", BCP 14, RFC 2119, March 1997. 243 [2] Droms (ed.), R., Bound, J., Volz, Bernie, Lemon, Ted, Perkins, 244 C., Carney, M., "Dynamic Host Configuration Protocol for IPv6 245 (DHCPv6)", draft-ietf-dhc-dhcpv6-26 (work in progress), June 246 2002. 248 [3] Volz, B., Gonczi, S., Lemon, T., Stevens, R., "DHC Load 249 Balancing Algorithm", RFC 3074, February 2001. 251 Author's Address 253 Bernie Volz 254 Ericsson 255 959 Concord Street 256 Framingham, MA 01701 257 USA 259 Phone: +1 508 875 3162 260 EMail: bernie.volz@ericsson.com 262 Full Copyright Statement 264 Copyright (C) The Internet Society (2002). All Rights Reserved. 266 This document and translations of it may be copied and furnished to 267 others, and derivative works that comment on or otherwise explain it 268 or assist in its implementation may be prepared, copied, published 269 and distributed, in whole or in part, without restriction of any 270 kind, provided that the above copyright notice and this paragraph are 271 included on all such copies and derivative works. However, this 272 document itself may not be modified in any way, such as by removing 273 the copyright notice or references to the Internet Society or other 274 Internet organizations, except as needed for the purpose of 275 developing Internet standards in which case the procedures for 276 copyrights defined in the Internet Standards process must be 277 followed, or as required to translate it into languages other than 278 English. 280 The limited permissions granted above are perpetual and will not be 281 revoked by the Internet Society or its successors or assigns. 283 This document and the information contained herein is provided on an 284 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 285 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 286 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 287 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 288 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 290 Acknowledgement 292 Funding for the RFC Editor function is currently provided by the 293 Internet Society.