idnits 2.17.00 (12 Aug 2021) /tmp/idnits48426/draft-lemon-dhcpv4-to-v6-id-trans-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 14 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Unrecognized Status in 'Category: Standards Track ', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: draft-ietf-dhc-3315id-for-v4 has been published as RFC 4361 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Group Ted Lemon 2 INTERNET DRAFT Nominum 3 Expires: July 2004 Bill Sommerfeld 4 Internet Draft Sun Microsystems 5 Document: 6 Category: Standards Track January, 2004 8 Transition from RFC2131-style to RFC3315-style 9 Client Identifiers for DHCPv4. 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-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 21 any 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 26 The list of Internet-Draft Shadow Directories can be accessed at: 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document explores ways for a node that is configured using 32 DHCP and that has in the past been configured using one of the 33 client identification schemes described in RFC2131 and RFC2132 to 34 make the transition to using the identification scheme described in 35 RFC3315 and in draft-ietf-dhc-3315-id-for-v4.txt. 37 1. Problem Statement 39 The DHCPv4 protocol specification [RFC2131, RFC2132] and the 40 DHCPv6 protocol specification [RFC3315] both describe ways that 41 DHCP clients can identify themselves to DHCP servers. 42 Unfortunately, the methods described in these specifications are 43 incompatible - a node that identifies itself according to the 44 mechanism specified in RFC3315 will use different identification 45 information than a node that identifies itself according to 46 RFC2131/RFC2132, and it's not possible to describe a method for 47 converting between the two types of identification. 49 The internet-draft, Node-Specific Client Identifiers for DHCPv4 50 [NODSPC], defines a new client identifier for DHCPv4 that is 51 derived identically to the identifier used in DHCPv6. DHCPv4 52 clients that identify themselves using this method can have 53 identifiers that are the same as the identifier sent by a DHCPv6 54 client running on the same node. 56 There is a problem with this, however. At the time that this 57 document is being written, there are no DHCPv4 clients that use 58 the mechanism described in [NODSPC]. In the case of IPv4-only 59 nodes that will never run a DHCPv6 client, this is not a 60 problem. 62 However, in the case where the node may be updated to run both IPv4 63 and IPv6, it may be useful for the DHCPv4 client to change client 64 identifiers so that its client identifier is compatible with the 65 one used by the DHCPv6 client. When it does this, any state on 66 the DHCP server that is associated with the old client identifier 67 will be lost. For example, the IP address formerly assigned to 68 the client will not continue to be assigned to the client, and if 69 the client has a domain name registered in the DNS, the client's 70 association with that name will be lost. 72 An additional problem is that in administrative domains where long 73 leases are assigned, when a client changes its client identifier, 74 the server will wind up allocating it a second lease. If a large 75 number of clients in a single administrative domain make the 76 migration to new identifiers at the same time, this could result 77 in address depletion. A more short-lived version of this problem 78 can also happen in environments where DHCP servers implement 79 per-customer lease limiting - because the lease limit per customer 80 is probably quite small, when a customer attempts to migrate, 81 there may not be an additional lease to allocate to the new client 82 identifier until the lease associated with the old identifier is 83 freed. 85 2. Applicability 87 This draft proposes a number of solutions to the stated 88 problem. The intention of the authors is that once one of these 89 solutions is chosen, the draft should go to standards track. 91 3.. Proposed Solutions 93 3.1. Do Nothing 95 One answer to this problem is to just switch client identifiers, 96 but not do anything special to migrate resources associated with 97 the client identifier. The way this will play out is as follows: 99 - The client will get a new IP address, if one is available. 100 - While the old lease is valid, any resources associated with it 101 (e.g., the client's domain name) will be unavailable to the 102 client. 103 - Once the old lease has expired, these resources (particularly the 104 - client's domain name) will be available for any client to claim. 105 - If a different client attempts to claim these resources first, 106 that client will get them. 108 - If no other client attempts to claim the resources, the original 109 client will reclaim them the first time it renews after the old 110 lease has expired. 112 On networks where the client's IP address is not precious (for 113 example, many NATted networks) and where the DHCP server does not 114 maintain any other resources (e.g., domain names) on behalf of the 115 client, this method is probably the best one, because it requires 116 the least effort from the client and server. 118 3.2. Propose New Identifier in DHCPREQUEST 120 Another answer to the problem is to require the client to send a 121 DHCPREQUEST to transfer the resources to a new client identifier. 122 The DHCPREQUEST message would send the old identifier in the 123 client identifier option, and would send the proposed new 124 identifier in a newly-defined option. 126 If the server supports the transition option, it sends back a 127 DHCPACK with the new client identifier in the 128 dhcp-client-identifier option. If it does not support the 129 transition option, it either does not send back a client 130 identifier option, or sends back a client identifier option that 131 contains the old client identifier. RFC2131 specifies the former 132 behavior, but some existing DHCP server implementations send the 133 client identifier anyway, so the client should be prepared for 134 either possibility. 136 If the response indicates that the server doesn't support the 137 transition option, the client sends a DHCPRELEASE to release the 138 lease and the resources associated with it, and then issues a 139 DHCPDISCOVER using the new identifier to acquire a new lease. It 140 uses the requested-address option to try to get the server to 141 assign it the same lease. The DHCPRELEASE attempts to assure that 142 any resources that are allocated to the client are released before 143 the new identifier is used. 145 If, when the client is directed to change to the new identifier, 146 it does not have a valid lease, it acquires a lease using the old 147 client identifier and then follows the procedure described above. 149 Once a client that implements this method has made the transition 150 one time, it always uses the new identifier in any subsequent DHCP 151 messages, even if the server with which it is communicating 152 changes. 154 This proposal works quite nicely for a DHCP client that is always 155 in the same administrative domain. Such a client will never have 156 more than one outstanding lease. This case coincides with the 157 most likely case where the client is going to care about getting a 158 consistent IP address. Clients that roam between administrative 159 domains probably do not benefit very much either from having a 160 stable IP address or from having the DHCP server maintain the 161 client's name in the DNS. So although this solution does not 162 address all possible cases, it is nevertheless probably good 163 enough. 165 3.3. Send Old Client Identifier 167 Another answer to the problem is for the client to send the new 168 client identifier in the client-identifier option in any DHCP 169 messages it sends after the transition has been made. In addition, 170 it sends the old client identifier in a new option. When a 171 compliant server looks up the client, it looks both under the old 172 client identifier and under the new client identifier. If it finds 173 the lease under the old identifier, it converts it to the new 174 identifier. If it finds leases under both identifiers, the server 175 uses the one that's associated with the new identifier and does 176 nothing to the lease associated with the old identifier. 178 A client that implements this method needs to keep track of the 179 last expiry time of a lease that was acquired under the old 180 client identifier. Until that lease time has expired, it must 181 continue to send the old client identifier option in every DHCP 182 message it sends. After that time has expired, it can forget 183 that it ever used the old identifier. 185 This solution has the advantage that if a client has more than one 186 outstanding lease recorded under the old identifier, it will 187 potentially be able to reclaim all of those leases. One 188 disadvantage is that leases held by non-compliant servers are 189 never upgraded. Another disadvantage is that the client has to 190 keep track of old leases, and it's possible that many existing 191 clients do not keep track of this information, and thus would not 192 be able to determine when it would be safe to stop sending the old 193 client identifier. 195 3.4. Probe for Leases Under Old Identifier 197 This is a more elaborate version of the solution described in 198 section 3.2. In this case, the client remembers all the leases it 199 had. When it attaches to a new network segment, it sends a 200 DHCPDISCOVER under the old client identifier, including the new 201 client identifier option as described in section 3.2. If it gets a 202 DHCPOFFER listing one of the leases it remembers, it acquires that 203 lease and then converts it using the method described in section 204 3.2. It then removes the lease from its list of leases that need 205 to be converted. 207 If the client doesn't recognize the lease it gets, it converts it 208 anyway, as described in section 3.2. Leases that are acquired 209 during the probing process are never _added_ to the list of leases 210 needing to be converted. 212 If the server has a IP address associated with the new identifier, 213 it sends that IP address to the client. In that case the client 214 just starts using that lease. 216 When any lease on the list of leases to be converted expires, the 217 client removes that lease from the list. When the list of leases 218 to be converted is empty, the client no longer attempts to probe - 219 at that point it is free to use the new client identifier, and need 220 no longer remember that it made a transition from a different 221 identifier. 223 This solution eliminates the problem with the solution proposed in 224 section 3.2, that only one lease can be converted. Thus, a 225 roaming client can be sure that it will not run into problems. 226 The downside to this proposal is that it required a great deal of 227 the client. The advantage is that it is completely compatible 228 with the solution proposed in section 3.2, which means that the 229 implementor has the option of implementing either proposal. 231 4. Recommendations 233 The solutions proposed in sections 3.2 and 3.4 are compatible, 234 and solve the stated problem nicely. So if a solution is to be 235 implemented, it seems that pursuing one or both of these 236 solutions would be the right thing to do. However, it's a lot 237 of trouble to implement this, so it's worth discussing whether or 238 not there's any advantage to undertaking this work, or whether it 239 would be better not to try to solve this problem. 241 5. Security Considerations 243 This draft introduces a new mechanism by which a malicious DHCP 244 client could steal resources from an existing client. Currently, a 245 malicious DHCP client that knows the client identifier of another 246 client can send a DHCPRELEASE message to release the resources 247 associated with that lease, and then send a DHCPDISCOVER message 248 and attempt to acquire that client's lease. Using the mechanism 249 proposed in sections 3.2 and 3.3, a malicious client could steal a 250 lease in a single transaction, rather than using two transactions. 251 It's not clear that this makes any difference - in order to avoid 252 having this happen, the DHCP protocol needs to be protected with 253 some kind of authentication scheme, for example the one defined in 254 the DHCP Authentication specification [RFC3118]. It does not 255 appear to be the case that that this proposal adds any new 256 vulnerability. 258 6. IANA Considerations 260 This document may define a new DHCP option, and the code for that 261 option would need to be assigned by the IANA. 263 7. Normative References 265 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 266 March 1997. 267 [RFC2132] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor 268 Extensions", RFC2132, March, 1997 269 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 270 Carney, M., "Dynamic Host Configuration Protocol for 271 IPv6 (DHCPV6)", July, 2003 272 [NODSPC] Lemon, E., Sommerfeld, W., "Node-Specific Client 273 Identifiers for DHCPv4", draft-ietf-dhc-3315id-for-v4.txt, 274 January, 2004 276 8. Informative References 278 [RFC3118] Droms, R., Arbaugh, W., "Authentication for DHCP 279 Messages", RFC3118, June, 2001 281 Author's Addresses 283 Ted Lemon 284 Nominum 285 2385 Bay Road 286 Redwood City, CA 94063 USA 287 +1 650 381 6000 288 mellon@nominum.com 290 Bill Sommerfeld 291 Sun Microsystems 292 1 Network Drive 293 Burlington, MA 01824 294 +1 781 442 3458 295 sommerfeld@sun.com 297 Full Copyright Statement 299 "Copyright (C) 2003, 2004 The Internet Society. All Rights Reserved. 300 This document and translations of it may be copied and furnished to 301 others, and derivative works that comment on or otherwise explain 302 it or assist in its implementation may be prepared, copied, 303 published and distributed, in whole or in part, without restriction 304 of any kind, provided that the above copyright notice and this 305 paragraph are included on all such copies and derivative 306 works. However, this document itself may not be modified in any 307 way, such as by removing the copyright notice or references to the 308 Internet Society or other Internet organizations, except as needed 309 for the purpose of developing Internet standards in which case the 310 procedures for copyrights defined in the Internet Standards process 311 must be followed, or as required to translate it into languages 312 other than English. 314 The limited permissions granted above are perpetual and will not be 315 revoked by the Internet Society or its successors or assigns. 317 This document and the information contained herein is provided on 318 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 319 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 320 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 321 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 322 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 324 Acknowledgement 326 Funding for the RFC Editor function is currently provided by the 327 Internet Society.