idnits 2.17.00 (12 Aug 2021) /tmp/idnits55931/draft-ietf-dhc-dhcpv6-loadb-02.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 6 longer pages, the longest (page 1) 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 (August 2002) is 7212 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: draft-ietf-dhc-dhcpv6 has been published as RFC 3315 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 August 2002 4 Expires: February 1, 2003 6 Load Balancing for DHCPv6 7 draft-ietf-dhc-dhcpv6-loadb-02.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 February 1, 2003. 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 Note: For CONFIRM messages (which do not include a Server Identifier 160 option), a server MAY forgo the load balancing algorithm and respond 161 to all clients. 163 The hash bucket assignments for each server must be configured and 164 care must be taken to assign each hash bucket to at least one server. 165 How the hash buckets are configured in servers is outside the scope 166 of this document. 168 If a single hash bucket is assigned to multiple servers, the logic a 169 client uses to select a server applies (just as if there were 170 multiple servers for clients without load balancing). For example, 171 each server can be configured with a different server preference 172 value [2]. 174 6. DHCPv6 Relay Agent Operation 176 Relay agents MAY be configured to relay client requests using load 177 balancing. A load balancing relay agent must be configured with 178 additional information as to the hash buckets assigned to each 179 server, in a manner similar to that presented in [3]. Care must be 180 taken to assure consistent information if both relay agents and 181 servers are configured with load balancing information. 183 A relay agent would have the following processing flow for received 184 client messages: 186 1. If no Client Identifier option is present in the client's 187 message, relay the message to all configured servers 188 regardless of hash bucket assignments. 190 2. Otherwise, use the hash algorithm described in [3] on the DUID 191 in the Client Identifier option and relay the message to the 192 server or servers assigned that hash bucket. 194 Relay agents MUST be configured to forward client requests to all of 195 the DHCPv6 servers that may be part of a load balancing group. 197 Note: If relay agents are configured to do load balancing, the 198 Elapsed Time option will be ineffective in allowing any server (not 199 just the servers in the load balancing group) to respond to a 200 client's request. 202 7. DHCPv6 Client Operation 204 DHCPv6 clients need not be aware that load balancing is in use by 205 the servers. A client operates as described in [2]. 207 Client operation with respect to load balancing is the same as 208 client operation with multiple servers. If a server that was 209 servicing a client becomes unavailable for some reason, the client 210 will eventually time-out and communicate with all servers. When 211 this happens, if there are multiple servers assigned to handle 212 that client's hash bucket, one or more of these remaining servers 213 will respond. If there are no other servers for that hash bucket, 214 other servers may respond once the elapsed time value in the 215 Elapsed Time option exceeds their configured SD. 217 If there is only one server (either for all clients or for some 218 of the hash buckets), failure of that server will prevent clients 219 from obtaining or extending the lifetimes of addresses. However, 220 there is no difference whether load balancing is used or not. 222 8. Security Considerations 224 This proposal in and by itself provides no security, nor does it 225 impact existing security. See [2] for further details as to DHCPv6 226 security issues. 228 Servers using load balancing are responsible for ensuring that if 229 the contents of the HBA are transmitted over the network as part 230 of the process of configuring any server, that message be secured 231 against tampering, since tempering with the HBA could result in a 232 denial of service for some or all clients. 234 9. Acknowledgements 236 Thanks to the DHC Working Group for their time and input into the 237 specification starting at IETF-52. Thanks also to the following 238 individuals for their comments and questions (in alphabetical 239 order) Stefan Berg, Herold Fagerberg, Ted Lemon, Tony Lindstrom, 240 Thomas Narten, Anders Strand, and Jack Wong. 242 References 244 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 245 Levels", BCP 14, RFC 2119, March 1997. 247 [2] Droms (ed.), R., Bound, J., Volz, Bernie, Lemon, Ted, Perkins, 248 C., Carney, M., "Dynamic Host Configuration Protocol for IPv6 249 (DHCPv6)", draft-ietf-dhc-dhcpv6-26 (work in progress), June 250 2002. 252 [3] Volz, B., Gonczi, S., Lemon, T., Stevens, R., "DHC Load 253 Balancing Algorithm", RFC 3074, February 2001. 255 Author's Address 257 Bernie Volz 258 Ericsson 259 959 Concord Street 260 Framingham, MA 01701 261 USA 263 Phone: +1 508 875 3162 264 EMail: bernie.volz@ericsson.com 266 Full Copyright Statement 268 Copyright (C) The Internet Society (2002). All Rights Reserved. 270 This document and translations of it may be copied and furnished to 271 others, and derivative works that comment on or otherwise explain it 272 or assist in its implementation may be prepared, copied, published 273 and distributed, in whole or in part, without restriction of any 274 kind, provided that the above copyright notice and this paragraph are 275 included on all such copies and derivative works. However, this 276 document itself may not be modified in any way, such as by removing 277 the copyright notice or references to the Internet Society or other 278 Internet organizations, except as needed for the purpose of 279 developing Internet standards in which case the procedures for 280 copyrights defined in the Internet Standards process must be 281 followed, or as required to translate it into languages other than 282 English. 284 The limited permissions granted above are perpetual and will not be 285 revoked by the Internet Society or its successors or assigns. 287 This document and the information contained herein is provided on an 288 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 289 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 290 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 291 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 292 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 294 Acknowledgement 296 Funding for the RFC Editor function is currently provided by the 297 Internet Society.