idnits 2.17.1 draft-ietf-dhc-dhcpv6-loadb-00.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) 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 (Feb 2002) is 8099 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-23 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force B. Volz 3 INTERNET DRAFT Ericsson 4 DHC Working Group Feb 2002 5 Expires: August 22, 2002 7 Load Balancing for DHCPv6 8 draft-ietf-dhc-dhcpv6-loadb-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 22, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 39 This document specifies a load balancing algorithm for use with 40 DHCPv6. Load balancing enables multiple cooperating DHCPv6 servers 41 to decide which one should service a client, without exchanging 42 any information beyond initial configuration. It expands on RFC 43 3074 "DHC Load Balancing Algorithm" to include DHCPv6. 45 1. Introduction 47 This document extends the load balancing concepts described in 48 RFC 3074 "DHC Load Balancing Algorithm" [3] to DHCPv6 [2]. 50 2. Requirements 52 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 53 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 54 document, are to be interpreted as described in RFC 2119 [1]. 56 3. Terminology 58 This document uses terminology specific to IPv6 and DHCPv6 as defined 59 in the "Terminology" section of the DHCP specification [2]. 61 This document uses many of the concepts and terminology specific to 62 load balancing as defined in the "Load Balancing Terminology" section 63 of the DHC Load Balancing specification [3]. 65 4. DHCPv6 Server Operation 67 DHCPv6 uses a DUID (DHCP Unique Identifier) to identify clients. The 68 DUID is carried in most client-generated messages in the Client 69 Identifier option as described in [2]. The client's DUID is defined 70 to be the Service Transaction ID (STID) [3]. 72 DHCPv6 uses two types of client messages, those that are directed to 73 a specific server and those that are directed to all servers. The 74 messages directed to a specific server contain a Server Identifier 75 option as described in [2] and include the Request, Renew, Release, 76 Decline, and Information-Request messages. The messages directed to 77 all servers do not include a Server Identifier option and include 78 the Solicit, Confirm, Rebind, and Information-Request messages. 80 For the messages directed to a specific server, this load balancing 81 algorithm does not apply and a server processes that client's 82 request if the Server Identifier option's DUID of the request matches 83 it own and discards all other requests. 85 For the messages directed to all servers, the load balancing 86 algorithm MAY be used to limit the clients that a server services 87 if the request contains a Client Identifier option. The server uses 88 the hash algorithm described in [3] on the client's DUID (the STID) 89 and uses the resulting hash value to determine if the client is 90 within the server's configured hash bucket assignment (HBA) [3]. If 91 the hash value is assigned to the server, the server MUST process 92 the client request (other server policy may of course determine how 93 the request is processed and whether a reply is sent to the client). 94 If the hash value is not assigned to the server, the server SHOULD 95 NOT process the request. The server MAY process the request if the 96 elapsed time value in the Elapsed Time option of the request exceeds 97 a preconfigured value (the Service Delay or SD in [3]). How the SD is 98 configured for a server is outside the scope of this document. 100 For client requests (such as Information-Request messages) which do 101 not contain a Client Identifier option, there is no STID and thus all 102 servers MUST process these requests. 104 The hash bucket assignments for each server must be configured and 105 care must be taken to assign each hash bucket to at least one 106 server. How the hash buckets are configured in servers is outside 107 the scope of this document. 109 If a single hash bucket is assigned to multiple servers, the logic 110 a client uses to select a server applies (just as if there were 111 multiple servers for clients without load balancing). For example, 112 each server can be configured with a different server preference 113 value [2]. 115 5. DHCPv6 Relay Operation 117 This document does not specify any techniques related to load 118 balancing for relays. While a similar approach to that described 119 in [3] could be used with DHCPv6 relays, further investigation of 120 the benefits and complexities this may add to DHCPv6 configurations 121 is needed before any recommendations can be made. This is an area 122 of further work and discussion. 124 Relays MUST be configured to forward client requests to all of 125 the DHCPv6 servers that may be part of a load balancing group. 127 6. DHCPv6 Client Operation 129 DHCPv6 clients need not be aware that load balancing is in use by 130 the servers. A client operates as described in [2]. 132 Client operation with respect to load balancing is the same as 133 client operation with multiple servers. If a server that was 134 servicing a client becomes unavailable for some reason, the client 135 will eventually time-out and communicate with all servers. When 136 this happens, if there are multiple servers assigned to handle 137 that client's hash bucket, one or more of these remaining servers 138 will respond. If there are no other servers for that hash bucket, 139 other servers may respond once the elapsed time value in the 140 Elapsed Time option exceeds their configured SD. 142 If there is only one server (either for all clients or for some 143 of the hash buckets), failure of that server will prevent clients 144 from obtaining or extending the lifetimes of addresses. However, 145 there is no difference whether load balancing is used or not. 147 7. Security Considerations 149 This proposal in and by itself provides no security, nor does it 150 impact existing security. See [2] for further details as to DHCPv6 151 security issues. 153 Servers using load balancing are responsible for ensuring that if 154 the contents of the HBA are transmitted over the network as part 155 of the process of configuring any server, that message be secured 156 against tampering, since tempering with the HBA could result in a 157 denial of service for some or all clients. 159 8. Acknowledgements 161 Thanks to the DHC Working Group for their time and input into the 162 specification starting at IETF-52. Thanks also to the following 163 individuals for their comments and questions (in alphabetical 164 order) Stefan Berg, Herold Fagerberg, Ted Lemon, Tony Lindstr�m, 165 Thomas Narten, Anders Strand, and Jack Wong. 167 References 169 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 170 Levels", BCP 14, RFC 2119, March 1997. 172 [2] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. 173 Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 174 (DHCPv6)", draft-ietf-dhc-dhcpv6-23 (work in progress), February 175 2002. 177 [3] Volz, B., Gonczi, S., Lemon, T., Stevens, R., "DHC Load 178 Balancing Algorithm", RFC 3074, February 2001. 180 Author's Address 182 Bernie Volz 183 Ericsson 184 959 Concord Street 185 Framingham, MA 01701 186 USA 188 Phone: +1 508 875 3162 189 EMail: bernie.volz@ericsson.com 191 Full Copyright Statement 193 Copyright (C) The Internet Society (1970). All Rights Reserved. 195 This document and translations of it may be copied and furnished to 196 others, and derivative works that comment on or otherwise explain it 197 or assist in its implementation may be prepared, copied, published 198 and distributed, in whole or in part, without restriction of any 199 kind, provided that the above copyright notice and this paragraph are 200 included on all such copies and derivative works. However, this 201 document itself may not be modified in any way, such as by removing 202 the copyright notice or references to the Internet Society or other 203 Internet organizations, except as needed for the purpose of 204 developing Internet standards in which case the procedures for 205 copyrights defined in the Internet Standards process must be 206 followed, or as required to translate it into languages other than 207 English. 209 The limited permissions granted above are perpetual and will not be 210 revoked by the Internet Society or its successors or assigns. 212 This document and the information contained herein is provided on an 213 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 214 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 215 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 216 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 217 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 219 Acknowledgement 221 Funding for the RFC Editor function is currently provided by the 222 Internet Society.