idnits 2.17.1 draft-gandhewar-dhc-v6-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 3129 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) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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 October 1, 2015 5 Expires: April 3, 2016 7 DHCPv6 Relay Initiated Release 8 draft-gandhewar-dhc-v6-relay-initiated-release-01 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 or prefix and network resources for the 22 associated services it is using. This document specifies a way to 23 request release to be initiated by an intermediate DHCPv6 network 24 device, e.g. DHCPv6 relay, on behalf of DHCPv6 client. This helps 25 to relinquish network resources sooner than the lease expiration 26 time. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 3, 2016. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Problem Description . . . . . . . . . . . . . . . . . . . 3 64 1.2. Relay Initiated Release . . . . . . . . . . . . . . . . . 4 65 1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 7 67 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 7 68 3.1. Message Definitions . . . . . . . . . . . . . . . . . . . 7 69 3.1.1. RELEASE-REQUEST . . . . . . . . . . . . . . . . . . . 7 70 3.1.2. RELEASE-REQUEST-REPLY . . . . . . . . . . . . . . . . 8 71 3.2. Message Validation . . . . . . . . . . . . . . . . . . . 8 72 3.2.1. RELEASE-REQUEST . . . . . . . . . . . . . . . . . . . 8 73 3.2.2. RELEASE-REQUEST-REPLY . . . . . . . . . . . . . . . . 9 74 4. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1. First DHCPv6 Network Device Behavior . . . . . . . . . . 9 76 4.1.1. Generation and Transmission of RELEASE-REQUEST 77 Message . . . . . . . . . . . . . . . . . . . . . . . 10 78 4.1.2. Receipt of RELEASE-REQUEST Message . . . . . . . . . 11 79 4.2. Intermediate DHCPv6 Network Device Behavior . . . . . . . 11 80 4.3. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 11 81 4.4. Receipt of RELEASE-REQUEST-REPLY . . . . . . . . . . . . 12 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 87 8.2. Informative References . . . . . . . . . . . . . . . . . 13 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Introduction 92 DHCPv6 [RFC3315] and [RFC3633] provides a framework for configuring 93 clients with network addresses, address prefixes and other network 94 parameters. It includes a relay agent capability where DHCPv6 server 95 may not be directly connected to the DHCPv6 client. A relay agent is 96 an intermediate node that passes DHCPv6 messages between DHCPv6 97 clients and DHCPv6 servers. As per [RFC3315], a relay agent cannot 98 generate a message on its own which can control the client binding. 99 Figure 1 below shows a typical network with multiple DHCPv6 devices. 101 +---------+ +---------+ +---------+ +---------+ 102 | DHCPv6 |-----| DHCPv6 |--...--| DHCPv6 |-----| DHCPv6 | 103 | Server | | Relay n | | Relay 1 | | Client | 104 +---------+ +---------+ +---------+ +---------+ 106 Figure 1: Typical DHCPv6 Network 108 1.1. Problem Description 110 While providing an IPv6 address or IPv6 Prefix to the DHCPv6 Client, 111 Service Providers (e.g. Broadband Service Providers), creates a 112 logical interface per client, programs various routes (e.g. access 113 routes, framed routes) for the client to access the network and 114 services, attaches services (e.g. voice, video, data), maintains 115 policy, applies QoS. Along with these resources there is a need for 116 memory and bandwidth per client. Since all these resources are 117 limited on a network device (e.g. Broadband Network Gateway), it 118 defines the scaling capacity of the device. Since the availability 119 of the IPv6 addresses is large, subscription rate for the Service 120 Providers is thus limited by the availability of the resources on 121 their network device. 123 A DHCPv6 client may be connected to the DHCPv6 server through 124 multiple DHCPv6 network devices, e.g. multiple DHCPv6 relays. These 125 network resources remain reserved for the client at all the DHCPv6 126 network devices until the lease expires. 128 In some situations, there might be need to clear the client binding 129 administratively. The process of administratively clearing the 130 client binding is very cumbersome. The administrator needs to access 131 every single DHCPv6 network device (relay, relay-proxy) and also the 132 DHCPv6 server, and clear the DHCPv6 client binding at each of these 133 devices manually. 135 In some situations when the DHCPv6 client is replaced (e.g. replacing 136 the set-top-box) due to the device failure or upgrade, the older 137 DHCPv6 client might not have sent the RELEASE message on its failure. 139 In this case, the previously assigned IPv6 address or prefix and 140 network resources for the older (stale) client will stay reserved and 141 unused until the lease expires. 143 Same is the situation where clients move frequently without sending 144 RELEASE e.g. in the case of mobile networks, network resources stay 145 reserved and unused. Similarly, network resources stay reserved and 146 unused where DHCPv6 clients login and logout frequently without 147 sending RELEASE e.g. Wi-Fi access centers. 149 As per DHCPv6 protocol it is not mandatory for the DHCPv6 client to 150 send a RELEASE message while disconnecting. As per the statistics 151 from Service Providers, 95% of the cases DHCPv6 client does not send 152 RELEASE message when it no longer needs the service. It is also 153 possible that the UDP datagram carrying a RELEASE message may get 154 dropped due to network issues. 156 All the resources including the IPv6 address or prefix remains 157 reserved for the client at all the DHCPv6 network devices until the 158 lease expires. Service Providers needs to take into account such 159 situations and are forced to lower the subscription rate. Thus it 160 reduces the scaling per network device. Also it causes errors for 161 the time based billing. 163 1.2. Relay Initiated Release 165 It is possible for the first DHCPv6 network device, i.e. "DHCPv6 166 Relay 1" in Figure 1 which is closest to the DHCPv6 client, to detect 167 that the DHCPv6 client is replaced, moved or is no longer present on 168 the network. In this scenario, the relay agent doesn't have any 169 mechanism to inform the server to release the client's binding and 170 subsequently relinquish network resources. 172 With the relay initiated release message, when a DHCPv6 relay detects 173 client's unavailability or needs to clear the client binding 174 administratively, it can generate the release message on behalf of 175 the client and send it to the server. Thus, all the DHCPv6 network 176 devices along the path will be in synchronization with respect to the 177 client's binding information and network resources can be 178 relinquished earlier than the lease expiry. The server MAY choose to 179 integrate some mechanism to confirm with the client, e.g. generate 180 RECONFIGURE message before sending reply to the relay. It is outside 181 the scope of this document. 183 Generation of the relay initiated release SHOULD be a configurable 184 behavior at the first relay. The configuration at Relay SHOULD be 185 further granular to indicate the situation under which relay should 186 initiate the release e.g. administratively clearing DHCPv6 binding, 187 client replaced, client moved, client unavailable, etc. 189 Forwarding of the relay initiated release related messages SHOULD be 190 a configurable behavior at the intermediate DHCPv6 network devices. 192 Acceptance of relay initiated release SHOULD also be a configurable 193 behavior at the server. 195 The purpose of such configurable behavior is explained in 196 Section 1.3. 198 1.3. Applicability 200 As per the statistics from Service Providers, 95% of the cases DHCPv6 201 client does not send RELEASE message when it no longer needs the 202 service. This functionality is useful in order to relinquish network 203 resources sooner than the lease expiry. This allows Service 204 Providers for higher subscription rate and accurate time based 205 billing. 207 This functionality described in Section 1.2 is useful for clearing 208 the client binding administratively, client replacement, frequent 209 client login and logout without sending RELEASE (e.g. at Wi-Fi 210 centers) or where client moves frequently without sending RELEASE 211 (e.g. mobile networks). All these situations can be detected by the 212 first DHCPv6 network device. Thus this functionality is applicable 213 to all these situations without any problems. 215 This functionality is also useful where client unavailability can be 216 detected. Client unavailability could be because of multiple 217 reasons. Client may become unavailable due to powered-off, 218 disconnect from the network or problems in the network itself. Since 219 it is difficult to identify the cause of client's absence, precaution 220 must be taken in such situations. With this functionality described 221 in Section 1.2, the state of the binding is cleared and network 222 resources are relinquished at DHCPv6 Relay, DHCPv6 Server and all the 223 intermediate network devices. However it is possible that the 224 binding is still not cleared at the DHCPv6 client. There may be a 225 situation where client remembers the IPv6 address or prefix as well 226 as the lease it received and continue to use when network comes back. 227 This situation may happen when the network between Relay and client 228 becomes unavailable and Relay may assume that the client is 229 unavailable. 231 When such a situation happens where all the DHCPv6 network devices 232 cleared the binding but client still remembers and tries to use the 233 address or prefix, at that moment there is no way to clear the 234 binding at the client. The client's binding will get cleared at the 235 client at the time of Renew or Rebind or when the lease expires or 236 when client restarts DHCPv6 process. 238 This may not be a problem in case of DSL based networks where DHCPv6 239 is over PPP session. The failed PPP session will cause the DHCPv6 240 client to bring up the PPP session and restart the DHCPv6 discovery 241 process. However it may be a problem with an Ethernet based access 242 network since there is no trigger event to the CPE (client) to 243 restart the DHCPv6 binding process. 245 In some provider networks, DHCPv6 Relay has liveness detection. When 246 the network between DHCPv6 Relay and client becomes unavailable, 247 DHCPv6 Relay may initiate Release, whereas client is completely 248 unaware. It is not possible to differentiate between network 249 unavailable and client unavailable. This will very likely be the 250 case with cable network configurations. If the link between Cable 251 Modem and the CMTS goes down, the Relay running on CMTS may initiate 252 release for the Cable Modem as well as the devices behind the Cable 253 Modem unless Cable Modem runs the DHCPv6 Relay. The granular 254 configuration to initiate Release on client unavailability should be 255 turned off in such networks. 257 However, there are some Service Provider networks where DHCPv6 client 258 runs the liveness detection e.g. BFD on the provider facing 259 interface. Such DHCPv6 clients can identify the network 260 unavailability and may restart the DHCPv6 binding process. 262 In some Service Provider networks, Relay takes up longer lease from 263 the Server but gives out very small lease to the DHCPv6 client. This 264 forces DHCPv6 client to frequently renew the lease. Thus recovery 265 from problematic state of the DHCPv6 client will be much faster in 266 such network configurations. 268 For some of the Service Provider's configurations, DHCPv6 Relay adds 269 access routes per subscriber (DHCPv6 client) and remove these routes 270 on clearing the binding on receiving the REPLY for RELEASE or the 271 RELEASE-REQUEST-REPLY. Thus the Relay can restrict DHCPv6 client's 272 network traffic based on the source or the destination address and 273 thus restrict the harm and protects from two devices accessing the 274 network with the same IPv6 address. 276 This functionality SHOULD be a configurable behavior since there is 277 no clear way to distinguish between DHCPv6 client unavailable and 278 network unavailable. Having configurable behavior equips 279 administrator to enable this granular knob (send Relay Initiated 280 Release on DHCPv6 client's unavailability) at Relay only if it is 281 certain that such a situation will not occur or client will clear the 282 binding state and reestablish or the risk of such situation is being 283 accounted. 285 2. Requirements Language 287 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 288 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 289 document are to be interpreted as described in RFC 2119 [RFC2119]. 291 3. Protocol Details 293 3.1. Message Definitions 295 This document specifies 2 new DHCPv6 message types: 297 o RELEASE-REQUEST 299 o RELEASE-REQUEST-REPLY 301 The RELEASE-REQUEST and RELEASE-REQUEST-REPLY messages use the 302 Client/Server Message Formats described in Section 6 of [RFC3315], 303 similar to the LEASEQUERY and LEASEQUERY-REPLY in [RFC5007]. 305 3.1.1. RELEASE-REQUEST 307 This is the relay initiated release request message. 309 The RELEASE-REQUEST message MAY be generated by the first DHCPv6 310 network device ("DHCPv6 Relay 1" in Figure 1), on behalf of the 311 DHCPv6 client. The RELEASE-REQUEST message MUST contain one or more 312 Client Data Options as described in Section 4.1.2.2 of [RFC5007], 313 requesting release for one or more clients. 315 The RELEASE-REQUEST message MUST contain the Server Identifier 316 Option. It MAY contain Interface-Id Option indicating common values 317 for all the clients requesting the release. This reduces the 318 redundant data when there are multiple clients with common 319 information. 321 Each Client Data Option MUST include the Client Identifier Option 322 OPTION_CLIENTID. It MUST also include options containing the IAs - 323 OPTION_IAADDR, OPTION_IAPREFIX, etc. - for the addresses or prefixes 324 it is releasing. If the Interface-Id option is different from the 325 one included directly under RELEASE-REQUEST message then it MUST be 326 included here. 328 3.1.2. RELEASE-REQUEST-REPLY 330 This is the reply for the RELEASE-REQUEST message. 332 The message RELEASE-REQUEST-REPLY will be generated by the DHCPv6 333 Server to communicate the status of the request. The server conveys 334 the success or failure of the RELEASE-REQUEST by including Status 335 Code Option at different levels: 337 o Status Code Option directly inside RELEASE-REQUEST: Indicates 338 success or failure of the complete RELEASE-REQUEST message it 339 received. 341 o Status Code Option inside Client Data Option: Indicates success or 342 failure to release all the addresses or prefixes for a particular 343 client. Client Data Option MUST include the Client-Id Option. 345 o Status Code Option inside IA Option: Indicates success or failure 346 to release a particular address or prefix for a particular client. 347 Client Data Option MUST include the Client-Id Option and the IA 348 option. 350 The RELEASE-REQUEST-REPLY message MAY contain one or more Client Data 351 Options, described in Section 4.1.2.2 of [RFC5007], responding to the 352 request to release for each of the clients. 354 The RELEASE-REQUEST-REPLY message SHOULD contain the Interface-Id 355 option if it was included in RELEASE-REQUEST message. 357 3.2. Message Validation 359 3.2.1. RELEASE-REQUEST 361 Clients MUST silently discard any received RELEASE-REQUEST messages. 363 Relay MAY accept or discard any received RELEASE-REQUEST messages 364 depending upon the configuration as explained in Section 4.1.2. 366 Servers MUST discard any received RELEASE-REQUEST messages that meet 367 any of the following conditions: 369 o The message does not include a Relay Id Option. 371 o The message does not include a Client Data Option. 373 o The Client Data Option does not include a Client Identifier 374 Option. 376 o The message does not include a Server Identifier option. 378 o The message includes a Server Identifier Option but the contents 379 of the Server Identifier Option do not match the server's 380 identifier. 382 3.2.2. RELEASE-REQUEST-REPLY 384 Clients MUST silently discard any received RELEASE-REQUEST-REPLY 385 messages. 387 Servers MUST silently discard any received RELEASE-REQUEST-REPLY 388 messages. 390 Relay MUST discard any received RELEASE-REQUEST-REPLY messages that 391 meet any of the following conditions: 393 o The "transaction-id" field in the message does not match the value 394 used in the RELEASE-REQUEST message. 396 o The message does not include a Status Code Option. 398 4. Functionality 400 The generation of a RELEASE-REQUEST message SHOULD be a configurable 401 behavior at DHCPv6 network device. Similarly, taking action to 402 release the binding SHOULD also be a configurable behavior at the 403 DHCPv6 server and intermediate DHCPv6 network devices. 405 4.1. First DHCPv6 Network Device Behavior 407 Devices MAY be configured to generate the newly defined RELEASE- 408 REQUEST message. 410 The first DHCPv6 network device ("DHCPv6 Relay 1" in Figure 1) can be 411 configured such that when it detects the client is no longer 412 available on the network or is replaced or the binding information 413 needs to be deleted administratively, the device can generate the 414 RELEASE-REQUEST message. 416 In order to generate the RELEASE-REQUEST message this network device 417 needs to store the information related to the client, e.g. the client 418 identifier and the server identifier used while obtaining the client 419 lease. 421 4.1.1. Generation and Transmission of RELEASE-REQUEST Message 423 Set the "msg-type" field to RELEASE-REQUEST. 425 Generate a transaction ID and insert it in the "transaction-id" 426 field. 428 MUST include Server-Id Option. 430 MUST include Relay-Id option [RFC5460]. 432 MAY add Interface-Id option [RFC3315]. 434 MUST include one or more Client Data Options each one: 436 o MUST include Client Identifier and MUST be same as what was used 437 when client obtained the lease. 439 o MAY include options containing the IAs (IA_NA, IA_TA, IA_PD) for 440 the addresses or prefixes it is requesting to be released. 441 Absence of this option indicates release of all the addresses and 442 prefixes associated with this Client Identifier. 444 o MAY include Interface-Id option [RFC3315] if it is different from 445 the one included outside of the Client Data Option 447 Because RELEASE-REQUEST messages MAY be lost, the message SHOULD be 448 retransmitted if no RELEASE-REQUEST-REPLY message is received. The 449 client transmits the message according to Section 14 of [RFC3315], 450 using the following parameters: 452 o IRT REL_TIMEOUT 454 o MRT 0 456 o MRC REL_MAX_RC 458 o MRD 0 460 If RELEASE-REQUEST-REPLY from a DHCPv6 server is lost, then the 461 RELEASE-REQUEST will be retransmitted, and the server MAY respond 462 with a RELEASE-REQUEST-REPLY indicating a status as NoBinding. 463 Therefore, in this message exchange, the relay SHOULD NOT treat a 464 RELEASE-REQUEST-REPLY message with a status of NoBinding as an error. 466 4.1.2. Receipt of RELEASE-REQUEST Message 468 In order to protect against spoofed RELEASE-REQUEST messages 469 attempting to disconnect the clients, the first DHCPv6 network device 470 SHOULD drop any received RELEASE-REQUEST messages. It MUST be a 471 configurable behavior if these messages are from the trusted sources 472 and needs to be forwarded to the server. 474 4.2. Intermediate DHCPv6 Network Device Behavior 476 The behavior of the intermediate DHCPv6 network device can be 477 configurable to either accept or reject these messages. On 478 accepting, it can forward the messages as specified in Section 20.1 479 and 20.2 of [RFC3315]. 481 4.3. DHCPv6 Server Behavior 483 DHCPv6 server ("DHCPv6 Server" in Figure 1) SHOULD be configurable to 484 either accept or reject the relay initiated release message RELEASE- 485 REQUEST. Upon receipt of a RELEASE-REQUEST message, the server MUST 486 confirm the validity of the message. 488 If server does not support the new message type then it MAY simply 489 drop the packet. 491 If the server is not configured to accept this relay initiated 492 RELEASE-REQUEST message then it MAY simply drop the packet or send 493 RELEASE-REQUEST-REPLY with status as NotConfigured. 495 If the server decides not to accept the RELEASE-REQUEST from a 496 particular relay, it MAY simply drop the packet or send RELEASE- 497 REQUEST-REPLY with status as NotAllowed. 499 The server SHOULD iterate through each of the Client Data Options and 500 examine the Client-Id and the addresses in the IAs for validity. If 501 the addresses or prefixes in the IAs have been assigned by the 502 server, the server deletes the binding of these addresses and 503 prefixes and makes them available for assignment to other clients. 504 Server keeps note of these addresses and prefixes in the IAs for 505 generating the RELEASE-REQUEST-REPLY. 507 After all of the clients have been processed, the server generates a 508 RELEASE-REQUEST-REPLY message and includes a Status Code Option with 509 value Success. It also includes Server Identifier option. 511 For each of the clients where there is a failure in releasing 512 addresses or prefixes, server MUST include Client Data Option. In 513 the Client Data Option, it MUST include the Client Identifier option 514 from the RELEASE-REQUEST message. It MUST also include Status Code 515 Option for each of the failed IAs from the RELEASE-REQUEST message. 516 For the clients or IAs for which the server has no binding 517 information, correspondingly, the server MUST include a Status Code 518 Option with the value NoBinding. No other options are included in 519 the IA option. 521 4.4. Receipt of RELEASE-REQUEST-REPLY 523 The first DHCPv6 network device ("DHCPv6 Relay 1" in Figure 1), upon 524 receipt of a valid RELEASE-REQUEST-REPLY message, considers the 525 completion of RELEASE-REQUEST event. The action at this device is 526 based on the status. For all of the IAs or clients where the Status 527 Code is not Success or NoBinding, addresses and prefixes remain 528 unchanged until the lease expires. For all other clients and IAs, 529 bindings MUST be cleared. 531 5. Security Considerations 533 The RELEASE-REQUEST message provides a mechanism for releasing the 534 client binding, it can be the cause of security threat. The DHCPv6 535 server SHOULD have some mechanism for determining that the relay 536 agent is a trusted entity. DHCPv6 servers and relay agents MAY 537 implement relay message authentication as described in Section 21.1 538 of [RFC3315]. DHCPv6 servers MAY also implement a control policy 539 based on the content of a received Relay Identifier Option [RFC5460]. 540 Administrators MAY configure one of these security mechanisms. 542 In an environment where the network connecting the relay agent to the 543 DHCPv6 server is physically secure and does not contain devices not 544 controlled by the server administrator, it MAY be sufficient to trust 545 the Relay Agent Identifier provided by the relay agent. In networks 546 where the security of the machines with access to the data path is 547 not under the control of the server administrator, IPsec [RFC4301] is 548 necessary to prevent spoofing of messages. 550 DHCPv6 servers MUST silently discard RELEASE-REQUEST messages 551 originating from unknown or untrusted relay agents or reject the 552 RELEASE-REQUEST. Section 4.3 specifies the error code to return when 553 the server is configured to reject RELEASE-REQUEST messages. 555 6. IANA Considerations 557 We request IANA to assign following new message types from the 558 registry of Message Types maintained in: 559 http://www.iana.org/assignments/dhcpv6-parameters/ 561 o RELEASE-REQUEST 562 o RELEASE-REQUEST-REPLY 564 7. Acknowledgements 566 We would like to acknowledge Utae Kim (Smart GiGA Network Project, 567 Korea Telekom), Dan Seibel (Sr. Engineer, TELUS), Ian Farrer 568 (Network Architect, Deutsche Telekom) and Chris Topazi (Access 569 Engineering, Cox Communications) for their valuable contributions, 570 suggestions and support for this document. 572 We would like to thank Bernie Volz, Ted Lemon, Andrew Sullivan, Ole 573 Troan and Shrivinas Joshi for their valuable comments and suggestions 574 for improving the document. 576 Many thanks to Tomek Mrugalski, Bernie Volz and Jaya Bhawtankar (Lead 577 Engineer, Coriant) for their support. 579 We would like to acknowledge Anand Vijayvergiya, Jeff Haas and Ross 580 Callon for their guidance and tirelessly reviewing the document 581 multiple times. 583 8. References 585 8.1. Normative References 587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 588 Requirement Levels", BCP 14, RFC 2119, 589 DOI 10.17487/RFC2119, March 1997, 590 . 592 8.2. Informative References 594 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 595 C., and M. Carney, "Dynamic Host Configuration Protocol 596 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 597 2003, . 599 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 600 Host Configuration Protocol (DHCP) version 6", RFC 3633, 601 DOI 10.17487/RFC3633, December 2003, 602 . 604 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 605 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 606 December 2005, . 608 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 609 "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, 610 September 2007, . 612 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 613 DOI 10.17487/RFC5460, February 2009, 614 . 616 Author's Address 618 Sunil M. Gandhewar 619 Juniper Networks, Inc. 621 Email: sgandhewar@juniper.net