idnits 2.17.1 draft-ietf-dhc-triggered-reconfigure-06.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 (May 06, 2013) is 4007 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 normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group M. Boucadair 3 Internet-Draft X. Pougnard 4 Intended status: Standards Track France Telecom 5 Expires: November 07, 2013 May 06, 2013 7 Reconfigure Triggered by DHCPv6 Relay Agents 8 draft-ietf-dhc-triggered-reconfigure-06 10 Abstract 12 This document defines new DHCPv6 messages: Reconfigure-Request and 13 Reconfigure-Reply. Reconfigure-Request message is sent by a DHCPv6 14 relay agent to notify a DHCPv6 server about a configuration 15 information change, so that the DHCPv6 server can send a Reconfigure 16 message accordingly. Reconfigure-Reply message is used by the server 17 to acknowledge the receipt of Reconfigure-Request. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 07, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 55 3. Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Link Address Option . . . . . . . . . . . . . . . . . . . . . 6 58 6. Detailed Specification . . . . . . . . . . . . . . . . . . . 7 59 6.1. Messages Format . . . . . . . . . . . . . . . . . . . . . 7 60 6.2. Messages Validation . . . . . . . . . . . . . . . . . . . 7 61 6.2.1. RECONFIGURE-REQUEST . . . . . . . . . . . . . . . . . 7 62 6.2.2. RECONFIGURE-REPLY . . . . . . . . . . . . . . . . . . 7 63 6.3. Creation and Transmission of RECONFIGURE-REQUEST . . . . 7 64 6.4. Intermediate Relay Agents Behavior . . . . . . . . . . . 9 65 6.5. Server Behavior . . . . . . . . . . . . . . . . . . . . . 9 66 6.6. Receipt of RECONFIGURE-REPLY . . . . . . . . . . . . . . 10 67 7. Rate Limiting Considerations . . . . . . . . . . . . . . . . 11 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 73 11.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 This document specifies two new DHCPv6 messages [RFC3315]: 79 Reconfigure-Request and Reconfigure-Reply. 81 Section 3 describes a typical problem encountered to trigger the 82 DHCPv6 server to issue a Reconfigure message when the configuration 83 data is supplied by the relay agent. This problem may be encountered 84 in other contexts. It is out of scope of this document to list all 85 these cases. 87 Section 4 describes the proposed solution which relies on the use of 88 Reconfigure-Request and Reconfigure-Reply messages. Reconfigure- 89 Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 90 server about a configuration information change, so that the DHCPv6 91 server can send a Reconfigure message accordingly. Reconfigure-Reply 92 message is used by the server to acknowledge the receipt of 93 Reconfigure-Request. 95 Section 6 provides the detailed specification of the procedure to 96 trigger Reconfigure messages by DHCPv6 relay agents. 98 2. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. Problem 106 [RFC6422] updates the DHCPv6 specification with a new feature to let 107 a DHCPv6 relay agent communicate information towards a DHCPv6 client, 108 and which is not available at the DHCPv6 server. This is achieved 109 owing to the use of RSOO (Relay-Supplied Options option) which 110 carries configuration data to the DHCPv6 server. The data conveyed 111 in an RSOO is then sent back by the DHCPv6 server to the requesting 112 DHCPv6 client. 114 An example of a RSOO context is shown in Figure 1; only a subset of 115 exchanged DHCPv6 and RADIUS messages is represented. Figure 1 shows 116 a broadband network scenario in which the Network Access Server (NAS) 117 embeds a DHCPv6 relay agent. 119 +-------+ +-------+ +-------+ 120 |DHCPv6 | | NAS | |Radius | 121 |Client | |(DHCPv6| |Server | 122 | | | Relay)| | | 123 +-------+ +-------+ +-------+ 124 | | | 125 |---Solicit---------------->| | 126 | |---Access-Request---------->| 127 |<--Access-Accept------------| 128 | (e.g. DS-Lite-Tunnel-Name)| 129 .... 130 | +-------+ 131 | |DHCPv6 | 132 | |Server | 133 | | | 134 | +-------+ 135 | | 136 |---Relay-Forward----------->| 137 | (RSOO(OPTION_AFTR_NAME)) | 138 | | 139 | |<--Relay-Reply--------------| 140 |<--Advertise---------------| (e.g., OPTION_AFTR_NAME) | 141 | (e.g., OPTION_AFTR_NAME) | 142 .... 144 Figure 1: An Example of the RSOO Option Usage 146 The change of the configuration may result in an exchange of CoA 147 (Change-of-Authorization, [RFC5176]) messages between the NAS/DHCPv6 148 relay agent and Dynamic Authorization Client (DAC) server as shown in 149 Figure 2. In this example, the NAS answers with a CoA-Ack message to 150 notify the DAC the CoA-Request is successfully handled. 152 Note the change of the configuration in the DHCPv6 relay agent can be 153 triggered by any other out-of-band mechanism. 155 +-------+ +-------+ +-------+ 156 |DHCPv6 | | NAS | |Radius | 157 |Client | |(DHCPv6| |Server/| 158 | | | Relay)| | DAC | 159 +-------+ +-------+ +-------+ 160 | | | 161 |<-----CoA-Request-----------| 162 | (e.g. DS-Lite-Tunnel-Name) | 163 |------CoA-Ack-------------->| 164 .... 166 Figure 2: Change of configuration 168 Whenever the configuration information sent by the DHCPv6 relay agent 169 to the DHCPv6 server change, the DHCPv6 server has no means to detect 170 the change so that it can send a Reconfigure message accordingly. A 171 solution is sketched in Section 4. 173 4. Proposed Solution 175 To solve the problem described in Section 3, this document proposes a 176 new DHCP message called Reconfigure-Request. In the example depicted 177 in Figure 3, a Reconfigure-Request message is sent by the DHCPv6 178 relay agent to a DHCPv6 server as soon as the configuration data 179 conveyed in an RSOO option have changed. Upon receipt of this 180 message, and if it is configured to support such mode, the DHCPv6 181 server must build Reconfigure-Reply and Reconfigure messages. 182 Reconfigure-Reply is used to acknowledge the receipt of Reconfigure- 183 Request. Reconfigure message encapsulated in Relay-Reply is sent to 184 the DHCPv6 relay, which in turn will forward the message to the 185 appropriate DHCPv6 client. 187 This setup assumes the relay has a record of the client, so that it 188 has enough information to send the Reconfigure-Request message to the 189 server. How the state is recorded in the relay is out of scope. For 190 better resilience of the proposed solution, means to recover state in 191 failure events (e.g., use of stable storage, DHCPv6 Bulk Leasequery 192 [RFC5460]) need to be supported. These state recovery solutions are 193 not discussed in this document. 195 +-------+ +-------+ +-------+ 196 |DHCPv6 | | NAS | |Radius | 197 |Client | |(DHCPv6| |Server/| 198 | | | Relay)| | DAC | 199 +-------+ +-------+ +-------+ 200 | | | 201 |<-----CoA-Request-----------| 202 | (e.g. DS-Lite-Tunnel-Name) | 203 | | 204 |------CoA-Ack-------------->| 205 .... 206 | +-------+ 207 | |DHCPv6 | 208 | |Server | 209 | | | 210 | +-------+ 211 | | 212 |---Reconfigure-Request----->| 213 |<--Reconfigure-Reply--------| 214 | | 215 | |<--Relay-Reply -------------| 216 |<--Reconfigure-------------| (Reconfigure) | 217 | | | 218 .... 220 Figure 3: Flow Example with Reconfigure-Request 222 The support of Reconfigure-Reply simplifies the retransmission 223 procedure of the relay as it provides an explicit indication from the 224 server (see Section 6.3 for more details). An alternative approach 225 is the relay monitors Reconfigure messages received from the server 226 to conclude whether Reconfigure-Request was successfully handled or 227 not. Nevertheless, this implicit approach may fail to achieve its 228 goals in some cases: e.g., the server accepts the request but it 229 delays to generate the corresponding Reconfigure messages due to its 230 rate-limiting policies, the request was partially failed for some 231 clients, etc. To avoid useless reconfigure cycles (e.g., due to the 232 loss of Reconfigure-Reply), the approach adopted in this document 233 allows the relay to correct the content of a re-transmitted 234 Reconfigure-Request based on some observed events (e.g., the client 235 has retrieved the updated configuration). If the relay has no client 236 to be reconfigured, it stops sending Reconfigure-Request messages. 238 The Reconfigure-Request message can also be used in other scenarios 239 than those that assume the use of RSOO. It is out of scope of this 240 document to describe all these scenarios. 242 5. Link Address Option 244 Figure 4 shows the format of the Link Address Option. 246 0 1 2 3 247 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | OPTION_LINK_ADDRESS | option-len | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | | 252 | link-address (IPv6 address) | 253 | | 254 | | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 4: Message Format of Link Address Option 259 The description of the fields are as follows: 261 option-code: OPTION_LINK_ADDRESS (To be assigned by IANA, see 262 Section 8). 264 option-len: 16 (octets). 266 link-address: An IPv6 address used by the server to identify the 267 link on which the client is located. 269 The Link Address Option is used by the relay agent to indicate to the 270 server the link on which the client is located. The relay agent MUST 271 use a link-address value that is equivalent to the value used when 272 relaying messages from the client to the server. Two link-address 273 values are said to be equivalent if both values are IPv6 addresses 274 that are on-link for the network link to which the client is 275 connected. The relay agent SHOULD use the same value that was sent 276 to the DHCPv6 server when relaying messages from the client to the 277 server, as in Section 20.1.1 of [RFC3315]. 279 6. Detailed Specification 281 6.1. Messages Format 283 Two new message type codes are defined: 285 o RECONFIGURE-REQUEST (To be assigned by IANA, see Section 8). 287 o RECONFIGURE-REPLY (To be assigned by IANA, see Section 8). 289 RECONFIGURE-REQUEST and RECONFIGURE-REPLY use the same format as 290 defined in Section 6 of [RFC3315]. 292 6.2. Messages Validation 294 6.2.1. RECONFIGURE-REQUEST 296 Clients MUST silently discard any received RECONFIGURE-REQUEST 297 messages. 299 Servers MUST discard any received RECONFIGURE-REQUEST messages that 300 meet any of the following conditions: 302 o the message does not include a Client Identifier Option [RFC3315]. 304 o the message does not include a Link Address Option (Section 5). 306 o the message includes a Server Identifier Option [RFC3315] but the 307 contents of the Server Identifier Option does not match the 308 server's identifier. 310 6.2.2. RECONFIGURE-REPLY 312 Clients and Servers MUST silently discard any received RECONFIGURE- 313 REPLY messages. 315 The relay MUST silently discard any received RECONFIGURE-REPLY 316 messages that meet any of the following conditions: 318 o the "transaction-id" field in the message does not match the value 319 used in the original message. 321 o the message does not include a Server Identifier Option. 323 o the message does not include a Status Code Option [RFC3315]. 325 6.3. Creation and Transmission of RECONFIGURE-REQUEST 326 For any event (e.g., modification of the configuration information) 327 that requires the server to issue a Reconfigure message, the relay 328 agent determines the client(s) affected by the change and then builds 329 a Reconfigure-Request message: the relay agent sets the "msg-type" 330 field to RECONFIGURE-REQUEST, generates a transaction ID and inserts 331 it in the "transaction-id" field. 333 The relay agent MUST include one or more Client Identifier Options 334 [RFC3315] and a Link Address Option (Section 5) so that the DHCPv6 335 server can identify the corresponding client and the link on which 336 the client is located. 338 The relay agent MAY include a Relay Identifier Option [RFC5460]. 340 The relay agent MAY supply the updated configuration in the RSOO 341 [RFC6422]. The relay agent MAY supply a Reconfigure Message Option 342 to indicate which form of Reconfigure to use. The relay agent MAY 343 include any option (e.g., Interface Identifier [RFC3315]) which it 344 might insert when relaying a message received from a client. 346 When several clients on the same link are affected by a configuration 347 change, the relay MUST include several Client Identifier Options, 348 each of them identifies a specific client. If including Client 349 Identifier Options of all impacted clients exceeds the maximum 350 message size (see Section 7), the relay MUST generate several 351 RECONFIGURE-REQUEST messages required to carry all Client Identifier 352 Options. Rate-limit considerations are discussed in Section 7. 354 The relay sets the destination address of the Reconfigure-Request 355 message to the IP address it would have sent a Relay-Forw message 356 (see Section 20 of [RFC3315]). 358 In case multiple servers are configured to the relay agent, several 359 Reconfigure-Request messages are to be built. The behavior of the 360 relay agent to disambiguate responses when multiple servers are 361 configured is implementation-specific. For example, an 362 implementation may generate distinct "transaction-id"s per server 363 while another implementation may use the content of the "transaction- 364 id" field and the Server Identifier Option to disambiguate the 365 responses. 367 The relay transmits RECONFIGURE-REQUEST messages according to 368 Section 14 of [RFC3315], using the following parameters: 370 IRT 1 sec 371 MRT 10 secs 372 MRC 5 373 MRD 0 375 The relay MAY remove clients from the client identifier list in 376 subsequent retransmissions, but MUST NOT add clients to the client 377 identifier list. This decision is local to the relay (e.g., it may 378 be based on observed events such as one or more clients were 379 reconfigured on their own). 381 The relay may receive Reconfigure encapsulated in Relay-Reply before 382 Reconfigure-Reply. The relay SHOULD NOT interpret it as if the 383 Reconfigure-Request was successfully handled by the Server. The 384 relay SHOULD use Reconfigure-Reply, not the Reconfigure message, to 385 determine if the request was successful. 387 6.4. Intermediate Relay Agents Behavior 389 The relay agent MUST be configurable to accept or reject RECONFIGURE- 390 REQUEST messages received from other relay agents. If no indication 391 is explicitly configured to the relay, the default behavior is to 392 accept RECONFIGURE-REQUEST messages. 394 If the relay is configured to reject RECONFIGURE-REQUEST, the relay 395 MUST silently discard any RECONFIGURE-REQUEST it receives. If the 396 relay is configured to accept RECONFIGURE-REQUEST messages, these 397 messages are relayed as specified in Section 20.1.1 of [RFC3315]. 399 6.5. Server Behavior 401 The server MUST be configurable to accept or reject RECONFIGURE- 402 REQUEST messages. If no indication is explicitly configured to the 403 server, the default behavior is to reject RECONFIGURE-REQUEST 404 messages. 406 Upon receipt of a valid Reconfigure-Request message from a DHCPv6 407 relay agent (see Section 6.2), the server determines the client(s) 408 for which a Reconfigure message is to be sent. 410 The server constructs a Reconfigure-Reply message by setting the 411 "msg-type" field to RECONFIGURE-REPLY, and copying the transaction ID 412 from the RECONFIGURE-REQUEST message into the "transaction-id" field. 413 The server includes its server identifier in a Server Identifier 414 Option. The server MUST include a Status Code Option [RFC3315] 415 indicating whether the request is successfully processed, failed or 416 partially failed. 418 o If the server fails to validate the request, the server MUST set 419 the Status Code Option to the appropriate status code (e.g., 420 UnspecFail, NotAllowed, etc.). In particular, 422 * UnspecFail MUST be returned if Reconfigure-Request message is 423 malformed. 425 * NotAllowed MUST be returned if the server is not configured to 426 allow Reconfigure-Request. 428 * NotConfigured MUST be returned if the server has no record of 429 the link. 431 o If the Reconfigure-Request is successfully validated, the server 432 MUST return a Status Code Option indicating "Success". In 433 addition, the server MUST include a list of all the Client 434 Identifier Options of the clients to which Reconfigure messages 435 will not be sent (e.g., the server has no record of the client or 436 the client did not negotiate for Reconfigure support). Note that 437 this means that "Success" will be returned even if Reconfigure 438 messages will not be sent to any of the clients. 440 If RSOO is supplied, the server MAY use its content to double check 441 whether a Reconfigure is required to be sent to the client. This 442 assumes the server stored the content of RSOO it used to generate 443 configuration data sent to requesting clients. 445 The server MAY use the content of the Reconfigure Message Option 446 supplied by the relay agent to determine which form of Reconfigure to 447 use. 449 Then, the server MUST follow the procedure defined in Section 19.1 of 450 [RFC3315] to construct a Reconfigure message. 452 Rate-limit considerations are discussed in Section 7. 454 6.6. Receipt of RECONFIGURE-REPLY 456 Depending on the status code enclosed in a received RECONFIGURE-REPLY 457 message, the relay may decide to terminate the request or try a 458 different corrected Reconfigure-Request. 460 When multiple servers are configured, the relay should expect to 461 receive several Reconfigure-Reply messages. As mentioned in 462 Section 6.3, the relay should be able to disambiguate these responses 463 and associate them with a given server. The relay agent assumes the 464 request is successfully handled for a client if the corresponding 465 Client Identifier Option does not appear in at least one Reconfigure- 466 Reply message. 468 7. Rate Limiting Considerations 470 The relay MUST rate-limit Reconfigure-Request messages to be sent to 471 the server. The relay MUST be configured with required rate-limit 472 parameters (i.e., the rate of Reconfigure-Request messages). The 473 maximum Reconfigure-Request packet size SHOULD be configurable and 474 the default value MUST be 1280 octets. 476 The server MUST rate-limit Reconfigure messages triggered by 477 Reconfigure-Request messages. The server MUST be configured with 478 required rate-limit parameters (i.e., the rate of Reconfigure 479 messages). 481 8. IANA Considerations 483 IANA is requested to assign the following new DHCPv6 Message type in 484 the registry maintained in http://www.iana.org/assignments/ 485 dhcpv6-parameters: 487 RECONFIGURE-REQUEST 489 RECONFIGURE-REPLY 491 IANA is requested to assign the following new DHCPv6 Option Codes in 492 the registry maintained in http://www.iana.org/assignments/ 493 dhcpv6-parameters: 495 OPTION_LINK_ADDRESS 497 9. Security Considerations 499 Security considerations elaborated in [RFC3315] (in particular 500 Section 21.1) and [RFC6422] must be taken into account. In addition, 501 DHCPv6 servers MAY be configured to reject relayed Reconfigure- 502 Request messages or restrict relay chaining (see [RFC5007] for more 503 discussion about the rationale of this recommended behavior). 504 Section 6.5 specifies the error code to return when the server is 505 configured to reject Reconfigure-Request messages. 507 Relay agents SHOULD implement appropriate means to prevent using 508 Reconfigure-Request messages as a denial-of-service attack on the 509 DHCPv6 servers. 511 Because Reconfigure-Request message provides a mechanism for 512 triggering the DHCP Reconfigure message, and the DHCP Reconfigure 513 message can raise security threats (e.g., to control the timing of a 514 DHCP renewal), the DHCP server MUST have some mechanism for 515 determining that the relay agent is a trusted entity. A control 516 policy based on the content of received Relay Identifier Option MAY 517 be enforced by the DHCPv6 server. Reconfigure-Request messages 518 originating from unknown relay agents MUST be silently dropped. 520 10. Acknowledgements 522 Many thanks to R. Maglione, A. Kostur, G. Halwasia, C. Jacquenet, 523 and R. Sparks for the comments and review. 525 Special thanks to T. Lemon, B. Volz and T. Mrugalski who provided 526 a detailed review. 528 11. References 530 11.1. Normative References 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, March 1997. 535 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 536 and M. Carney, "Dynamic Host Configuration Protocol for 537 IPv6 (DHCPv6)", RFC 3315, July 2003. 539 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC 540 6422, December 2011. 542 11.2. Informative References 544 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 545 "DHCPv6 Leasequery", RFC 5007, September 2007. 547 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 548 Aboba, "Dynamic Authorization Extensions to Remote 549 Authentication Dial In User Service (RADIUS)", RFC 5176, 550 January 2008. 552 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 553 2009. 555 Authors' Addresses 557 Mohamed Boucadair 558 France Telecom 559 Rennes 35000 560 France 562 Email: mohamed.boucadair@orange.com 564 Xavier Pougnard 565 France Telecom 566 Lannion 567 France 569 Email: xavier.pougnard@orange.com