idnits 2.17.1 draft-gandhewar-dhc-v6-relay-initiated-release-00.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 (June 28, 2015) is 3224 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) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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 June 28, 2015 5 Expires: December 30, 2015 7 DHCPv6 Relay Initiated Release 8 draft-gandhewar-dhc-v6-relay-initiated-release-00 10 Abstract 12 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) is 13 initiated by a DHCPv6 client. A DHCPv6 server can force DHCPv6 14 client to send RENEW or INFORMATION-REQUEST by sending a RECONFIGURE 15 message. There may be multiple DHCPv6 network devices connected in 16 between a DHCPv6 client and a server, each one reserving resources 17 for the DHCPv6 client. There are no DHCPv6 messages that a relay can 18 initiate in order to control the client binding. 20 A DHCPv6 client may not always send a RELEASE message when it no 21 longer needs the IPv6 address. This document specifies a way to 22 request release to be initiated by an intermediate DHCPv6 network 23 device, e.g. DHCPv6 relay, on behalf of DHCPv6 client. This helps 24 to relinquish network resources sooner than the lease expiration 25 time. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 30, 2015. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 63 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Message Definitions . . . . . . . . . . . . . . . . . . . 4 65 3.1.1. RELEASE-REQUEST . . . . . . . . . . . . . . . . . . . 4 66 3.1.2. RELEASE-REQUEST-REPLY . . . . . . . . . . . . . . . . 4 67 3.2. Message Validation . . . . . . . . . . . . . . . . . . . 5 68 3.2.1. RELEASE-REQUEST . . . . . . . . . . . . . . . . . . . 5 69 3.2.2. RELEASE-REQUEST-REPLY . . . . . . . . . . . . . . . . 5 70 4. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1. First DHCPv6 Network Device Behavior . . . . . . . . . . 6 72 4.1.1. Generation and Transmission of RELEASE-REQUEST 73 Message . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.2. Intermediate DHCPv6 Network Device Behavior . . . . . . . 7 75 4.3. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7 76 4.4. Receipt of RELEASE-REQUEST-REPLY . . . . . . . . . . . . 8 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 7.2. Informative References . . . . . . . . . . . . . . . . . 9 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 DHCPv6 [RFC3315] provides a framework for configuring clients with 87 network addresses and other network parameters. It includes a relay 88 agent capability where DHCPv6 server may not be directly connected to 89 the DHCPv6 client. A relay agent is an intermediate node that passes 90 DHCPv6 messages between DHCPv6 clients and DHCPv6 servers. As per 91 [RFC3315], a relay agent cannot generate a message on its own which 92 can control the client binding. Figure 1 below shows a typical 93 network with multiple DHCPv6 devices. 95 +---------+ +---------+ +---------+ +---------+ 96 | DHCPv6 |-----| DHCPv6 |--...--| DHCPv6 |-----| DHCPv6 | 97 | Server | | Relay n | | Relay 1 | | Client | 98 +---------+ +---------+ +---------+ +---------+ 100 Figure 1: Typical DHCPv6 Network 102 A DHCPv6 client may be connected to DHCPv6 server through multiple 103 DHCPv6 network devices, e.g. multiple DHCPv6 relays. In the DHCPv6 104 protocol it is not mandatory for the DHCPv6 client to send a RELEASE 105 message while disconnecting. It is also possible that the UDP 106 datagram carrying a RELEASE message may get dropped due to network 107 issues. Network resources, including IPv6 address, may remain 108 reserved for this client at all the DHCPv6 network devices until the 109 lease expires. 111 In some situations when the DHCPv6 client is replaced (e.g. replacing 112 the set-top-box) due to failure, the first DHCPv6 client may not have 113 sent the RELEASE message on its failure. In this case, the IPv6 114 address and network resources for the first client will be reserved 115 and unused until the lease expires. 117 It is possible for the first DHCPv6 network device, i.e. "DHCPv6 118 Relay 1" in Figure 1 which is closest to the DHCPv6 client, to detect 119 that the DHCPv6 client is replaced or is no longer present on the 120 network by a health check. This health check may be done by some 121 kind of liveness detection mechanism or some other mechanism. In 122 this scenario, the relay agent doesn't have any mechanism to inform 123 the server about such liveness state. 125 In some situations, the administrator might want to clear some 126 clients' bindings administratively. In such cases, the administrator 127 may need to access every single DHCPv6 network device (relay, relay- 128 proxy) and also the DHCPv6 server, and clear the DHCPv6 client 129 binding. 131 With the relay initiated release message, when a relay detects 132 client's unavailability or needs to clear the client binding 133 administratively, it can generate the release message on behalf of 134 client and send it to the server. Thus, all of the DHCPv6 network 135 devices can be in synchronization with respect to the client's 136 binding information and network resources can be relinquished earlier 137 than the lease expiry. The server MAY choose to integrate some 138 mechanism to confirm with the client, e.g. generate RECONFIGURE 139 message before sending reply to the relay. It is outside the scope 140 of this document. 142 2. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 3. Protocol Details 150 3.1. Message Definitions 152 This document specifies 2 new DHCPv6 message types: 154 o RELEASE-REQUEST 156 o RELEASE-REQUEST-REPLY 158 3.1.1. RELEASE-REQUEST 160 This is the relay initiated release request message. The format of 161 the RELEASE-REQUEST is same as the Client/Server message formats 162 described in Section 6 of [RFC3315]. 164 The RELEASE-REQUEST message MAY be generated by the first DHCPv6 165 network device ("DHCPv6 Relay 1" in Figure 1), on behalf of the 166 DHCPv6 client. The RELEASE-REQUEST message contains one or more 167 Client Data Options as described in Section 4.1.2.2 of [RFC5007], 168 requesting release for one or more clients. 170 The RELEASE-REQUEST message MUST contain the Server Identifier 171 Option. It MAY contain Interface-Id Option indicating common values 172 for all the clients requesting the release. This reduces the 173 redundant data when there are multiple clients with common 174 information. 176 Each Client Data Option MUST include the Client Identifier Option 177 OPTION_CLIENTID. It MUST also include options containing the IAs - 178 OPTION_IAADDR, OPTION_IAPREFIX, etc. - for the addresses it is 179 releasing. If the Interface-Id option is different from the one 180 included directly under RELEASE-REQUEST message then it MUST be 181 included here. 183 3.1.2. RELEASE-REQUEST-REPLY 185 This is the reply for the RELEASE-REQUEST message. The format of the 186 RELEASE-REQUEST-REPLY is same as the Client/Server message formats 187 described in Section 6 of [RFC3315]. 189 The message RELEASE-REQUEST-REPLY will be generated by the DHCPv6 190 Server to communicate the status of the request. The server conveys 191 the success or failure of the RELEASE-REQUEST by including Status 192 Code Option at different levels: 194 o Status Code Option directly inside RELEASE-REQUEST: Indicates 195 success or failure of the complete RELEASE-REQUEST message. 197 o Status Code Option inside Client Data Option: Indicates failure to 198 release all the addresses for a particular client. Client Data 199 Option MUST include the Client-Id Option. 201 o Status Code Option inside IA Option: Indicates failure to release 202 a particular address for a particular client. Client Data Option 203 MUST include the Client-Id Option and the IA option. 205 The RELEASE-REQUEST-REPLY message MAY contain one or more Client Data 206 Options, described in Section 4.1.2.2 of [RFC5007], responding to the 207 request to release for each of the clients. 209 The RELEASE-REQUEST-REPLY message SHOULD contain the Interface-Id 210 option if it was included in RELEASE-REQUEST message. 212 3.2. Message Validation 214 3.2.1. RELEASE-REQUEST 216 Clients MUST silently discard any received RELEASE-REQUEST messages. 218 Servers MUST discard any received RELEASE-REQUEST messages that meet 219 any of the following conditions: 221 o The message does not include a Client Data Option. 223 o The Client Data Option does not include a Client Identifier 224 Option. 226 o The message includes a Server Identifier Option but the contents 227 of the Server Identifier Option do not match the server's 228 identifier. 230 3.2.2. RELEASE-REQUEST-REPLY 232 Clients MUST silently discard any received RELEASE-REQUEST-REPLY 233 messages. 235 Servers MUST silently discard any received RELEASE-REQUEST-REPLY 236 messages. 238 Relay MUST discard any received RELEASE-REQUEST-REPLY messages that 239 meet any of the following conditions: 241 o The "transaction-id" field in the message does not match the value 242 used in the RELEASE-REQUEST message. 244 o The message does not include a Status Code Option. 246 4. Functionality 248 The generation of a RELEASE-REQUEST message can be a configurable 249 behavior at DHCPv6 network device. Similarly, taking action to 250 release the binding can also be a configurable behavior at the DHCPv6 251 server and intermediate DHCPv6 network devices. 253 4.1. First DHCPv6 Network Device Behavior 255 Devices MAY be configured to generate the newly defined RELEASE- 256 REQUEST message. 258 The first DHCPv6 network device ("DHCPv6 Relay 1" in Figure 1) can be 259 configured such that when it detects the client is no longer 260 available on the network or is replaced or the binding information 261 needs to be deleted administratively, the device can generate the 262 RELEASE-REQUEST message. 264 In order to generate the RELEASE-REQUEST message this network device 265 needs to store the information related to the client, e.g. the client 266 identifier and the server identifier used while obtaining the client 267 lease. 269 4.1.1. Generation and Transmission of RELEASE-REQUEST Message 271 Set the "msg-type" field to RELEASE-REQUEST. 273 Generate a transaction ID and insert it in the "transaction-id" 274 field. 276 MUST include Server-Id Option. 278 MAY include Relay-Id option [RFC5460]. 280 If configuration allows, relay MAY choose to add Interface-Id option 281 [RFC3315]. 283 Include one or more Client Data Options each one containing: 285 o Client identifier MUST be included and SHOULD be same as what was 286 used when client obtained the lease. 288 o Include options containing the IAs for the addresses it is 289 requesting to be released. 291 o If the configuration allows, the relay MAY choose to add 292 Interface-Id option [RFC3315] if it is different from the one 293 included outside of the Client Data Option 295 Because RELEASE-REQUEST messages MAY be lost, the message SHOULD be 296 retransmitted if no RELEASE-REQUEST-REPLY message is received. The 297 client transmits the message according to Section 14 of [RFC3315], 298 using the following parameters: 300 o IRT REL_TIMEOUT 302 o MRT 0 304 o MRC REL_MAX_RC 306 o MRD 0 308 If RELEASE-REQUEST-REPLY from a DHCP server is lost, then the 309 RELEASE-REQUEST will be retransmitted, and the server MAY respond 310 with a RELEASE-REQUEST-REPLY indicating a status as NoBinding. 311 Therefore, in this message exchange, the relay SHOULD NOT treat a 312 RELEASE-REQUEST-REPLY message with a status of NoBinding as an error. 314 4.2. Intermediate DHCPv6 Network Device Behavior 316 The behavior of the intermediate DHCPv6 network device can be 317 configured to either accept or reject these messages. On accepting, 318 it can forward the messages as specified in Section 20.1 and 20.2 of 319 [RFC3315]. 321 4.3. DHCPv6 Server Behavior 323 DHCPv6 server ("DHCPv6 Server" in Figure 1) SHOULD be configurable to 324 either accept or reject the relay initiated release message RELEASE- 325 REQUEST. Upon receipt of a RELEASE-REQUEST message, the server MUST 326 confirm the validity of the message. 328 If server does not support the new message type then it MAY simply 329 drop the packet. 331 If the server is not configured to accept this relay initiated 332 RELEASE-REQUEST message then it MAY simply drop the packet or send 333 RELEASE-REQUEST-REPLY with status as NotConfigured. 335 If the server decides not to accept the RELEASE-REQUEST from a 336 particular relay, it MAY simply drop the packet or send RELEASE- 337 REQUEST-REPLY with status as NotAllowed. 339 The server SHOULD iterate through each of the Client Data Options and 340 examine the Client-Id and the addresses in the IAs for validity. If 341 the addresses in the IAs have been assigned by the server, the server 342 deletes the binding of these addresses and makes the addresses 343 available for assignment to other clients. Server keeps note of 344 these addresses in the IAs for generating the RELEASE-REQUEST-REPLY. 346 After all of the clients have been processed, the server generates a 347 RELEASE-REQUEST-REPLY message and includes a Status Code Option with 348 value Success. It also includes Server Identifier option. 350 For each of the clients where there is a failure in releasing 351 addresses, server MUST include Client Data Option. In the Client 352 Data Option, it MUST include the Client Identifier option from the 353 RELEASE-REQUEST message. It MUST also include Status Code Option for 354 each of the failed IAs from the RELEASE-REQUEST message. For the 355 clients or IAs for which the server has no binding information, 356 correspondingly, the server MUST include a Status Code Option with 357 the value NoBinding. No other options are included in the IA option. 359 4.4. Receipt of RELEASE-REQUEST-REPLY 361 The first DHCPv6 network device ("DHCPv6 Relay 1" in Figure 1), upon 362 receipt of a valid RELEASE-REQUEST-REPLY message, considers the 363 completion of RELEASE-REQUEST event. The action at this device is 364 based on the status. For all of the IAs or clients where the Status 365 Code is not Success or NoBinding, addresses remain unchanged until 366 the lease expires. For all other clients and IAs, bindings MUST be 367 cleared. 369 5. Security Considerations 371 In order to prevent using RELEASE-REQUEST messages as a denial-of- 372 service attack on the DHCPv6 servers, DHCPv6 relay agents SHOULD 373 combine release requests for multiple clients in one RELEASE-REQUEST 374 as explained in Section Section 4.1.1. 376 Because the RELEASE-REQUEST message provides a mechanism for 377 releasing the client binding, it can be the cause of security 378 threats. The DHCPv6 server MUST have some mechanism for determining 379 that the relay agent is a trusted entity. DHCPv6 servers and relay 380 agents MUST implement relay message authentication as described in 381 Section 21.1 of [RFC3315]. DHCPv6 servers MAY also implement a 382 control policy based on the content of a received Relay Identifier 383 Option [RFC5460]. Administrators are strongly advised to configure 384 one of these security mechanisms. 386 In an environment where the network connecting the relay agent to the 387 DHCPv6 server is physically secure and does not contain devices not 388 controlled by the server administrator, it MAY be sufficient to trust 389 the Relay Agent Identifier provided by the relay agent. In networks 390 where the security of the machines with access to the data path is 391 not under the control of the server administrator, IPsec [RFC4301] is 392 necessary to prevent spoofing of messages. 394 DHCPv6 servers MUST silently discard RELEASE-REQUEST messages 395 originating from unknown or untrusted relay agents or reject the 396 RELEASE-REQUEST. Section Section 4.3 specifies the error code to 397 return when the server is configured to reject RELEASE-REQUEST 398 messages. 400 6. IANA Considerations 402 We request IANA to assign following new message types from the 403 registry of Message Types maintained in: 404 http://www.iana.org/assignments/dhcpv6-parameters/ 406 o RELEASE-REQUEST 408 o RELEASE-REQUEST-REPLY 410 7. References 412 7.1. Normative References 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC 2119, March 1997. 417 7.2. Informative References 419 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 420 and M. Carney, "Dynamic Host Configuration Protocol for 421 IPv6 (DHCPv6)", RFC 3315, July 2003. 423 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 424 Internet Protocol", RFC 4301, December 2005. 426 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 427 "DHCPv6 Leasequery", RFC 5007, September 2007. 429 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 430 2009. 432 Author's Address 434 Sunil M. Gandhewar 435 Juniper Networks, Inc. 437 Email: sgandhewar@juniper.net