idnits 2.17.1 draft-gandhewar-dhc-relay-initiated-release-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 1, 2015) is 3130 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc Working Group S. Gandhewar 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track October 1, 2015 5 Expires: April 3, 2016 7 DHCP Relay Initiated Release 8 draft-gandhewar-dhc-relay-initiated-release-01 10 Abstract 12 The Dynamic Host Configuration Protocol (DHCP) is initiated by a DHCP 13 client. A DHCP server can force DHCP client to send DHCPRENEW by 14 sending a DHCPFORCERENEW message. There may be multiple DHCP network 15 devices connected in between a DHCP client and a server, each one 16 reserving resources for the DHCP client. There are no DHCP messages 17 that a relay can initiate in order to control the client binding. 19 A DHCP client may not always send a DHCPRELEASE message when it no 20 longer needs the IP address and network resources for the associated 21 services it is using. This document specifies a way to request 22 release message to be initiated by an intermediate DHCP network 23 device, e.g. DHCP relay, on behalf of DHCP client. This helps to 24 relinquish network resources sooner than the lease expiration time. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 3, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 62 3. New Message and Option Value Definitions . . . . . . . . . . 5 63 3.1. DHCPRELEASEBYRELAY . . . . . . . . . . . . . . . . . . . 5 64 3.2. DHCPRELAYREPLY . . . . . . . . . . . . . . . . . . . . . 5 65 3.3. NoBinding . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.4. NotConfigured . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. First DHCP Network Device Behavior . . . . . . . . . . . 6 69 4.1.1. Generation and Transmission of DHCPRELEASEBYRELAY 70 Message . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1.2. Receipt of DHCPRELEASEBYRELAY Message . . . . . . . . 7 72 4.1.3. Receipt of DHCPRELAYREPLY Message . . . . . . . . . . 7 73 4.1.4. Receiving No Response . . . . . . . . . . . . . . . . 7 74 4.2. DHCP Server Behavior . . . . . . . . . . . . . . . . . . 8 75 4.2.1. Receipt of DHCPRELEASEBYRELAY Message . . . . . . . . 8 76 4.2.2. Generation and Transmission of DHCPRELAYREPLY Message 8 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 8.2. Informative References . . . . . . . . . . . . . . . . . 11 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 DHCP [RFC2131] provides a framework for configuring clients with 88 network addresses and other network parameters. It includes a relay 89 agent capability where DHCP server may not be directly connected to 90 the DHCP client. A relay agent is an intermediate node that passes 91 DHCP messages between DHCP clients and DHCP servers. As per 92 [RFC2131], a relay agent cannot generate a message on its own which 93 can control the client binding. Figure 1 below shows a typical 94 network with multiple DHCP devices. 96 +---------+ +---------+ +---------+ +---------+ 97 | DHCP |-----| DHCP |--...--| DHCP |-----| DHCP | 98 | Server | | Relay n | | Relay 1 | | Client | 99 +---------+ +---------+ +---------+ +---------+ 101 Figure 1: Typical DHCP Network 103 While providing an IP address to the DHCP Client, Service Providers 104 (e.g. Broadband Service Providers), creates a logical interface per 105 client, programs various routes (e.g. access routes, framed routes) 106 for the client to access the network and services, attaches services 107 (e.g. voice, video, data), maintains policy, applies QoS. Along with 108 these resources there is a need for memory and bandwidth per client. 109 Since all these resources are limited on a network device (e.g. 110 Broadband Network Gateway), it defines the scaling capacity of the 111 device. Subscription rate for the Service Providers is thus limited 112 by the availability of the IP addresses as well as the resources on 113 their network device. 115 A DHCP client may be connected to the DHCP server through multiple 116 DHCP network devices, e.g. multiple DHCP relay and/or relay-proxy. 117 These network resources remain reserved for the client at all the 118 DHCP network devices until the lease expires. 120 In some situations, there might be need to clear the client binding 121 administratively. The process of administratively clearing the 122 client binding is very cumbersome. The administrator needs to access 123 every single DHCP network device (relay, relay-proxy) and also the 124 DHCP server, and clear the DHCP client binding at each of these 125 devices manually. 127 In some situations when the DHCP client is replaced (e.g. replacing 128 the set-top-box) due to the device failure or upgrade, the older DHCP 129 client might not have sent the DHCPRELEASE message on its failure. 130 In this case, the previously assigned IP address and network 131 resources for the older (stale) client will stay reserved and unused 132 until the lease expires. 134 Same is the situation where clients move frequently without sending 135 DHCPRELEASE e.g. in the case of mobile networks, network resources 136 stay reserved and unused. Similarly, network resources stay reserved 137 and unused where DHCP clients login and logout frequently without 138 sending DHCPRELEASE e.g. Wi-Fi access centers. 140 As per DHCP protocol it is not mandatory for the DHCP client to send 141 a DHCPRELEASE message while disconnecting. As per the statistics 142 from Service Providers, 95% of the cases DHCP client does not send 143 DHCPRELEASE message when it no longer needs the service. It is also 144 possible that the UDP datagram carrying a DHCPRELEASE message may get 145 dropped due to network issues. 147 All the resources including the IP address remain reserved for the 148 client at all the DHCP network devices until the lease expires. 149 Service Providers needs to take into account such situations and are 150 forced to lower the subscription rate. Thus it reduces the scaling 151 per network device. Also it causes errors for the time based 152 billing. 154 It is possible for the first DHCP network device, i.e. "DHCP Relay 1" 155 in Figure 1 which is closest to the DHCP client, to detect that the 156 DHCP client is replaced, moved or is no longer present on the 157 network. In this scenario, the relay agent doesn't have any 158 mechanism to inform the server to release the client's binding and 159 subsequently relinquish network resources. 161 With the relay initiated release message, when a relay detects 162 client's unavailability or needs to clear the client binding 163 administratively, it can generate the release message on behalf of 164 the client and send it to the server. Thus, all the DHCP network 165 devices along the path will be in synchronization with respect to the 166 client's binding information and network resources can be 167 relinquished earlier than the lease expiry. The server MAY choose to 168 integrate some mechanism to confirm with the client, e.g. generate 169 FORCERENEW message before sending reply to the relay. It is outside 170 the scope of this document. 172 Generation of the relay initiated release SHOULD be a configurable 173 behavior at the first relay. The configuration at Relay SHOULD be 174 further granular to indicate the situation under which relay should 175 initiate the release e.g. administratively clearing DHCP binding, 176 client replaced, client moved, client unavailable, etc. 178 Forwarding of the relay initiated release related messages SHOULD be 179 a configurable behavior at the intermediate DHCP network devices. 181 Acceptance of relay initiated release SHOULD also be a configurable 182 behavior at the server. 184 2. Requirements Language 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 3. New Message and Option Value Definitions 192 This document specifies 2 new DHCP message types (option 53 from 193 Section 9.6 of [RFC2132]): 195 o DHCPRELEASEBYRELAY 197 o DHCPRELAYREPLY 199 The format of these messages is same as defined in [RFC2131]. 201 This document specifies 2 new values for the Status Code Option 202 (option 151 from Section 6.2.2 of [RFC6926]): 204 o NoBinding 206 o NotConfigured 208 3.1. DHCPRELEASEBYRELAY 210 This message MAY be generated by the first DHCP network device ("DHCP 211 Relay 1" in Figure 1), on behalf of the DHCP client. This gives an 212 indication to the server that the client binding can be cleared. 214 3.2. DHCPRELAYREPLY 216 This is the reply from DHCP server in response to the 217 DHCPRELEASEBYRELAY message. The server conveys success or failure of 218 the DHCPRELEASEBYRELAY. 220 3.3. NoBinding 222 When the server does not find the binding for which 223 DHCPRELEASEBYRELAY is received, it uses this new value in the Status 224 Code Option. 226 3.4. NotConfigured 228 When the server is not configured to accept DHCPRELEASEBYRELAY, it 229 uses this new value in the Status Code Option. 231 4. Functionality 233 The generation of a DHCPRELEASEBYRELAY message SHOULD be a 234 configurable behavior at the DHCP relay. Taking action to release 235 the binding SHOULD also be a configurable behavior at the server and 236 intermediate DHCP network devices. Depending upon the configuration, 237 the server responds with DHCPRELAYREPLY 239 4.1. First DHCP Network Device Behavior 241 Devices MAY be configured to generate the newly defined 242 DHCPRELEASEBYRELAY message. 244 The first DHCP network device ("DHCP Relay 1" in Figure 1) can be 245 configured such that when it detects the client is no longer on the 246 network or is replaced or the binding information needs to be deleted 247 administratively, the device can generate the DHCPRELEASEBYRELAY 248 message. 250 In order to generate the DHCPRELEASEBYRELAY message this network 251 device needs to store the information related to the client, e.g. 252 hardware address, client identifier, server identifier and giaddr 253 used while obtaining client lease. 255 4.1.1. Generation and Transmission of DHCPRELEASEBYRELAY Message 257 This new message is similar to the DHCPRELEASE generated by the 258 client, as explained in [RFC2131]. The construction of the 259 DHCPRELEASEBYRELAY is similar to the construction of any other DHCP 260 messages as described in Section 4.1 of [RFC2131]. Note that this 261 message is generated on behalf of the DHCP client hence all the 262 fields in the message MUST be with respect to the client, as if it 263 was generated by the client. 265 Set the following fields in the DHCPRELEASEBYRELAY message: 267 o op - MUST be set to BOOTREQUEST 269 o xid - MUST be filled as a random number 271 o chaddr - MUST be filled with hardware address of the client on 272 whose behalf the DHCPRELEASEBYRELAY is being sent 274 o ciaddr - MUST be filled with client's network address 276 o giaddr - MUST be filled and SHOULD be same as what was used when 277 client obtained the lease 279 Include the following options in the DHCPRELEASEBYRELAY message: 281 o DHCP message type - MUST be included as DHCPRELEASEBYRELAY 283 o Client identifier - if the client had used this option while 284 obtaining the lease, it MUST include this option with the same 285 value 287 o Server identifier - MUST be included and SHOULD be same as what 288 was used when client obtained the lease 290 o Relay Agent Information Option 82 - MAY include this option 291 [RFC3046] with the same value as what was used while obtaining the 292 lease 294 DHCPRELEASEBYRELAY SHOULD be sent as unicast message to the server. 296 4.1.2. Receipt of DHCPRELEASEBYRELAY Message 298 In order to protect against spoofed DHCPRELEASEBYRELAY messages 299 attempting to disconnect the clients, the first DHCP network device 300 SHOULD drop any received DHCPRELEASEBYRELAY messages. It MUST be a 301 configurable behavior if these messages are from the trusted sources 302 and needs to be forwarded to the server. 304 4.1.3. Receipt of DHCPRELAYREPLY Message 306 If xid of the DHCPRELAYREPLY does not match with the xid of the 307 DHCPRELEASEBYRELAY which was sent, DHCPRELAYREPLY MUST be silently 308 dropped. 310 The first DHCP network device ("DHCP Relay 1" in Figure 1), upon 311 receipt of a valid DHCPRELAYREPLY message from the server, considers 312 the completion of DHCPRELEASEBYRELAY event. 314 The action at this device is based on the Status Code Option. In the 315 absence of Status Code Option or if the value is Success or 316 NoBinding, then this device MUST clear the binding. If the Status 317 Code is not Success or NoBinding, those client bindings MUST remain 318 until the lease expires. 320 If DHCPRELAYREPLY from the DHCP server is lost then the 321 DHCPRELEASEBYRELAY will be retransmitted, and the server MAY respond 322 with a DHCPRELAYREPLY indicating a Status Code as NoBinding. 323 Therefore, in this message exchange, the relay SHOULD NOT treat a 324 DHCPRELAYREPLY message with a Status Code of NoBinding as an error. 326 4.1.4. Receiving No Response 328 The DHCP relay does not receive a response from the server if the 329 DHCPRELEASEBYRELAY or DHCPRELAYREPLY message is lost. In such cases, 330 relay SHOULD resend the DHCPRELEASEBYRELAY message to the server 331 using a backoff algorithm for the retry time that approximates an 332 exponential backoff. Depending on the network bandwidth between the 333 relay and the server, the relay SHOULD choose a delay. This delay 334 grows exponentially as retransmissions fail. The number of 335 retransmissions SHOULD be limited. The exponential backoff algorithm 336 is specified in Section 4.1 of [RFC3046]. 338 4.2. DHCP Server Behavior 340 DHCP server ("DHCP Server" in Figure 1) SHOULD be configurable either 341 to accept or reject the newly defined DHCPRELEASEBYRELAY message. 343 4.2.1. Receipt of DHCPRELEASEBYRELAY Message 345 If the DHCP server does not support the new message type then it can 346 simply drop the packet. 348 If the server is not configured to accept this relay initiated 349 DHCPRELEASEBYRELAY message then it can simply drop the packet or send 350 DHCPRELAYREPLY with status code as NotConfigured. 352 The server MAY be configured to restrict itself from accepting this 353 message with the same giaddr which was used while obtaining the lease 354 (DISCOVER-OFFER_REQUEST-ACK message exchange). If server decides not 355 to accept the DHCPRELEASEBYRELAY message from a particular relay, it 356 can simply drop the packet or send DHCPRELAYREPLY with status code as 357 NotAllowed. 359 On receipt of a valid and acceptable DHCPRELEASEBYRELAY message, if 360 configuration allows, server MAY decide to clear the binding as 361 explained in Section 4.3.4 of [RFC2131]. Server MUST send a 362 DHCPRELAYREPLY message to the relay. 364 If the server does not find the binding for which it received the 365 DHCPRELEASEBYRELAY message, it MUST send the DHCPRELAYREPLY with 366 status code as Nobinding. 368 4.2.2. Generation and Transmission of DHCPRELAYREPLY Message 370 Construction of the DHCPRELAYREPLY is similar to construction of any 371 other DHCP messages as described in Section 4.1 of [RFC2131]. This 372 message is similar to DHCPACK which is generated by the server, as 373 explained in [RFC2131]. 375 Set the following fields in the DHCPRELAYREPLY message: 377 o op - MUST be set to BOOTREPLY 379 o xid - MUST be copied from DHCPRELEASEBYRELAY 381 o chaddr - MUST be copied from DHCPRELEASEBYRELAY 382 o ciaddr - MUST be filled with client's network address 384 o giaddr - MUST be copied from DHCPRELEASEBYRELAY 386 Include the following options in the DHCPRELAYREPLY message: 388 o DHCP message type - MUST be included as DHCPRELAYREPLY 390 o Client identifier - MUST be copied from DHCPRELEASEBYRELAY 392 o Server identifier - MUST be copied from DHCPRELEASEBYRELAY 394 o Relay Agent Information Option 82 - if present, MUST be copied 395 from DHCPRELEASEBYRELAY 397 o Status Code - MAY include the option depending upon the result 399 DHCPRELAYREPLY MUST be sent as unicast message to the address of the 400 relay as recorded in DHCPRELEASEBYRELAY. 402 5. Security Considerations 404 DHCP protocol as defined in [RFC2131] provides no authentication or 405 security mechanisms. Potential exposure to attacks are discussed in 406 Section 7 of the DHCP protocol specification in [RFC2131]. 407 Unauthorized and malicious network device MAY spoof and send the 408 false DHCPRELEASE message. Similarly unauthorized and malicious 409 network device MAY spoof and send the false DHCPRELEASEBYRELAY 410 message. 412 A defense using the authentication for DHCP messages [RFC3118] SHOULD 413 be deployed where the networks are not secure or not directly under 414 the control of the server administrator. The DHCPRELEASEBYRELAY and 415 DHCPRELAYREPLY messages SHOULD be authenticated using the procedures 416 described in [RFC3118]. However, implementation of authentication is 417 not a MUST to support DHCPRELEASEBYRELAY and DHCPRELAYREPLY messages. 419 Although DHCP network devices that send the DHCPRELEASEBYRELAY 420 message perform the functions of a DHCP relay, essentially they are 421 DHCP clients for the purposes of the DHCPRELEASEBYRELAY message. 422 Thus, [RFC3118] is an appropriate mechanism for DHCPRELEASEBYRELAY 423 message authentication. 425 Since [RFC3118] discusses the normal DHCP client interaction, 426 consisting of a DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK, it 427 is necessary to transpose the operations described in [RFC3118] to 428 the DHCPRELEASEBYRELAY domain. The operations described in [RFC3118] 429 for DHCPDISCOVER are performed for DHCPRELEASEBYRELAY, and the 430 operations described for DHCPOFFER are performed for DHCPRELAYREPLY 431 message. 433 6. IANA Considerations 435 We request IANA to assign following new message types from the 436 registry of Message Types 53 Values maintained in: 437 http://www.iana.org/assignments/bootp-dhcp-parameters/ 439 o DHCPRELEASEBYRELAY 441 o DHCPRELAYREPLY 443 We request IANA to assign following new Status Code values from the 444 registry of Status Codes Type 151 Values maintained in: 445 http://www.iana.org/assignments/bootp-dhcp-parameters/ 447 o NoBinding 449 o NotConfigured 451 7. Acknowledgements 453 We would like to acknowledge Utae Kim (Smart GiGA Network Project, 454 Korea Telekom), Dan Seibel (Sr. Engineer, TELUS), Ian Farrer 455 (Network Architect, Deutsche Telekom) and Chris Topazi (Access 456 Engineering, Cox Communications) for their valuable contributions, 457 suggestions and support for this document. 459 We would like to thank Bernie Volz, Ted Lemon, Andrew Sullivan, Ole 460 Troan and Shrivinas Joshi for their valuable comments and suggestions 461 for improving the document. 463 Many thanks to Tomek Mrugalski, Bernie Volz and Jaya Bhawtankar (Lead 464 Engineer, Coriant) for their support. 466 We would like to acknowledge Anand Vijayvergiya, Jeff Haas and Ross 467 Callon for their guidance and tirelessly reviewing the document 468 multiple times. 470 8. References 472 8.1. Normative References 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, 476 DOI 10.17487/RFC2119, March 1997, 477 . 479 8.2. Informative References 481 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 482 RFC 2131, DOI 10.17487/RFC2131, March 1997, 483 . 485 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 486 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 487 . 489 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 490 RFC 3046, DOI 10.17487/RFC3046, January 2001, 491 . 493 [RFC3118] Droms, R. and W. Arbaugh., Ed., "Authentication for DHCP 494 Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001, 495 . 497 [RFC6926] Kinnear, K., Stapp, M., Desetti, R., Joshi, B., Russell, 498 N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery", 499 RFC 6926, DOI 10.17487/RFC6926, April 2013, 500 . 502 Author's Address 504 Sunil M. Gandhewar 505 Juniper Networks, Inc. 507 Email: sgandhewar@juniper.net