idnits 2.17.1 draft-kostur-dhc-loadbv6-03.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3074, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3074, updated by this document, for RFC5378 checks: 1999-10-22) -- 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 (November 9, 2012) is 4186 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC A. Kostur 3 Internet-Draft Incognito 4 Updates: 3074 (if approved) November 9, 2012 5 Intended status: Standards Track 6 Expires: May 13, 2013 8 DHC Load Balancing Algorithm for DHCPv6 9 draft-kostur-dhc-loadbv6-03 11 Abstract 13 This document proposes a method of algorithmic load balancing for 14 IPv6 Dynamic Host Configuration Protocol (DHCPv6) traffic. It 15 enables multiple, cooperating servers to decide which one should 16 service a client, without exchanging any information beyond initial 17 configuration. The server selection is based on the servers hashing 18 client DHCP Unique Identifiers (DUIDs) when multiple DHCPv6 (DHCPv6) 19 servers are available to service DHCPv6 clients. The proposed 20 technique provides for efficient server selection when multiple 21 DHCPv6 servers offer services on a network without requiring any 22 changes to existing DHCPv6 clients. The same method is proposed to 23 select the target server of a DHCPv6 relay. 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 May 13, 2013. 42 Copyright Notice 44 Copyright (c) 2012 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 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 61 2. Background and External Requirements . . . . . . . . . . . . . 3 62 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Messages with a Server ID . . . . . . . . . . . . . . . . . 3 64 3.1.1. RELEASE, DECLINE, and INFORMATION-REQUEST . . . . . . . 3 65 3.1.2. REQUEST and RENEW . . . . . . . . . . . . . . . . . . . 3 66 3.2. Selecting the STID . . . . . . . . . . . . . . . . . . . . 4 67 3.3. Replacing the secs field . . . . . . . . . . . . . . . . . 4 68 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 71 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 1. Introduction 76 This protocol is intended to extend the algorithm described in RFC 77 3074 [RFC3074] to apply to DHCPv6 [RFC3315] traffic. Most of the 78 terminology and procedures are identical to the ones specified in RFC 79 3074. 81 1.1. Requirements Language 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC2119]. 87 2. Background and External Requirements 89 The requirements for DHCPv6 are substantially the same as for DHCPv4, 90 replacing DHCPDISCOVER with SOLICIT, DHCPREQUEST with REQUEST, 91 CONFIRM, RENEW, or REBIND (as appropriate), etc. 93 3. Operation 95 A DHCPv6 server performing this load balancing will operate in 96 substantially the same manner as if it were a DHCPv4 server load 97 balancing an incoming DHCPv4/BOOTP packet with the following 98 differences. 100 3.1. Messages with a Server ID 102 Certain messages which contain a Server ID to direct that message may 103 need to be handled as if load balancing were not in play. 105 3.1.1. RELEASE, DECLINE, and INFORMATION-REQUEST 107 A DHCPv6 server receiving a RELEASE, DECLINE, or INFORMATION-REQUEST 108 with its own Server ID SHOULD answer the answer the message as if 109 there were no load balancing in play. Since there is no retry 110 mechanism for RELEASE or DECLINE, or only a simple retransmit for 111 INFORMATION-REQUEST, if the server were to ignore the message either 112 the state of the address would be incorrect, or no information would 113 be transferred to the client even though it was instructed to try the 114 INFORMATION-REQUEST against this particular server. 116 3.1.2. REQUEST and RENEW 118 A DHCPv6 server receiving a REQUEST or RENEW with the server's Server 119 ID specified MAY answer the request even if the request would 120 normally be ignored by load balancing. If there were a pair of 121 cooperating DHCPv6 servers (perhaps a failover pair), and after a 122 failure of one of the servers a large portion of the population may 123 have bound to the second server. When the first server returns to 124 service, the clients will continue to Renew against the second 125 server. If the second server ignores the requests, eventually the 126 client will transition to doing a Rebind, at which point since there 127 is no Server ID specified, the first server could then answer the 128 client. The end result would be that the server loads would 129 eventually become balanced again. 131 If the secondary server is choosing to continue to respect the load 132 balancing in the above case, then the server SHOULD NOT use the 133 Delayed Service Parameter feature for the requests containing the 134 server's Server ID. If the Delayed Service Parameter was still being 135 used, then it is likely that the client would never reach the 136 Rebinding state, and the secondary server might as well have answered 137 the first request that arrived instead of waiting for some number of 138 seconds before answering. 140 If the secondary server continues to answer the requests, then the 141 server load will not rebalance until the clients are rebooted, or 142 transition to a Rebind through any other mechanism. 144 A server MAY choose to answer REQUESTs and ignore RENEWs so that for 145 the REQUEST it is choosing to not require the client to go through 146 the entire set of retries and go back to SOLICIT before getting a 147 response, but ignore RENEWs to cause the devices to switch servers at 148 the REBIND time. 150 3.2. Selecting the STID 152 DHCPv6 servers MUST use the client's DUID in its entirety as the 153 STID. This is different than RFC 3074 which limited the STID to 16 154 bytes. 156 3.3. Replacing the secs field 158 A DHCPv6 server providing the capability of Delayed Service SHOULD 159 use the value in the OPTION_ELAPSED_TIME wherever RFC 3074 makes 160 reference to the secs field. 162 4. Acknowledgements 164 Thanks to Bernie Volz, Steve Gonczi, Ted Lemon, and Rob Stevens as 165 this document heavily borrows from their previous work on RFC 3074, 166 and Bernie's additional comments during the discussions. 168 5. IANA Considerations 170 This memo includes no request to IANA. 172 6. Security Considerations 174 This proposal in and by itself provides no security, nor does it 175 impact existing security. Servers using this algorithm are 176 responsible for ensuring that if the contents of the HBA are 177 transmitted over the network as part of the process of configuring 178 any server, that message be secured against tampering, since 179 tampering with the HBA could result in denial of service for some or 180 all clients. 182 7. Normative References 184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 185 Requirement Levels", BCP 14, RFC 2119, March 1997. 187 [RFC3074] Volz, B., Gonczi, S., Lemon, T., and R. Stevens, "DHC Load 188 Balancing Algorithm", RFC 3074, February 2001. 190 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 191 and M. Carney, "Dynamic Host Configuration Protocol for 192 IPv6 (DHCPv6)", RFC 3315, July 2003. 194 Author's Address 196 Andre Kostur 197 Incognito Software Inc. 198 #500 - 375 Water St. 199 Vancouver, BC 200 CA 202 Phone: +1 604 678 2864 203 Email: akostur@incognito.com