idnits 2.17.1 draft-ietf-dhc-triggered-reconfigure-04.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 (Using the creation date from RFC3315, updated by this document, for RFC5378 checks: 1995-02-03) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 11, 2013) is 4036 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 (==), 2 comments (--). 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 Updates: 3315, 6422 (if approved) France Telecom 5 Intended status: Standards Track March 11, 2013 6 Expires: September 12, 2013 8 Reconfigure Triggered by DHCPv6 Relay Agents 9 draft-ietf-dhc-triggered-reconfigure-04 11 Abstract 13 This document defines new DHCPv6 messages: Reconfigure-Request and 14 Reconfigure-Reply. Reconfigure-Request message is sent by a DHCPv6 15 relay agent to notify a DHCPv6 server about a configuration 16 information change, so that the DHCPv6 server can send a Reconfigure 17 message accordingly. Reconfigure-Reply message is used by the server 18 to acknowledge the receipt of Reconfigure-Request. 20 This document updates RFC 3315 and RFC 6422. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 12, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Link Address Option . . . . . . . . . . . . . . . . . . . . . 6 61 4. RECONFIGURE-REQUEST and RECONFIGURE-REPLY . . . . . . . . . . 6 62 4.1. Messages Format . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. Messages Validation . . . . . . . . . . . . . . . . . . . 7 64 4.2.1. RECONFIGURE-REQUEST . . . . . . . . . . . . . . . . . 7 65 4.2.2. RECONFIGURE-REPLY . . . . . . . . . . . . . . . . . . 7 66 4.3. Creation and Transmission of RECONFIGURE-REQUEST . . . . . 7 67 4.4. Intermediate Relay Agents Behaviour . . . . . . . . . . . 8 68 4.5. Server Behaviour . . . . . . . . . . . . . . . . . . . . . 9 69 4.6. Receipt of RECONFIGURE-REPLY . . . . . . . . . . . . . . . 10 70 5. Rate Limiting Considerations . . . . . . . . . . . . . . . . . 10 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 1.1. Problem 83 [RFC6422] updates the DHCPv6 specification [RFC3315] with a new 84 feature to let a DHCPv6 relay agent communicate information towards a 85 DHCPv6 client, and which is not available at the DHCPv6 server. This 86 is achieved owing to the use of RSOO (Relay-Supplied Options option) 87 which carries configuration data to the DHCPv6 server. The data 88 conveyed in an RSOO is then sent back by the DHCPv6 server to the 89 requesting DHCPv6 client. 91 An example of a RSOO context is shown in Figure 1; only a subset of 92 exchanged DHCPv6 and RADIUS messages is represented. Figure 1 shows 93 a broadband network scenario in which the Network Access Server (NAS) 94 embeds a DHCPv6 relay agent. 96 +-------+ +-------+ +-------+ 97 |DHCPv6 | | NAS | |Radius | 98 |Client | |(DHCPv6| |Server | 99 | | | Relay)| | | 100 +-------+ +-------+ +-------+ 101 | | | 102 |---Solicit---------------->| | 103 | |---Access-Request---------->| 104 |<--Access-Accept------------| 105 | (e.g. DS-Lite-Tunnel-Name)| 106 .... 108 | +-------+ 109 | |DHCPv6 | 110 | |Server | 111 | | | 112 | +-------+ 113 | | 114 |---Relay-Forward----------->| 115 | (RSOO(OPTION_AFTR_NAME)) | 116 | | 117 | |<--Relay-Reply--------------| 118 |<--Advertise---------------| (e.g., OPTION_AFTR_NAME) | 119 | (e.g., OPTION_AFTR_NAME) | 120 .... 122 Figure 1: An Example of the RSOO Option Usage 124 The change of the configuration may result in RADIUS exchanges 125 [RFC5176] between the NAS/DHCPv6 relay agent and Dynamic 126 Authorization Client (DAC) server as shown in Figure 2. Note the 127 change of the configuration in the DHCPv6 relay agent can be 128 triggered by any other out-of-band mechanism. 130 +-------+ +-------+ +-------+ 131 |DHCPv6 | | NAS | |Radius | 132 |Client | |(DHCPv6| |Server/| 133 | | | Relay)| | DAC | 134 +-------+ +-------+ +-------+ 135 | | | 136 |<-----CoA-Request-----------| 137 | (e.g. DS-Lite-Tunnel-Name) | 138 |------CoA-Response--------->| 139 .... 141 CoA (Change-of-Authorization, [RFC5176]) 143 Figure 2: Change of configuration 145 Whenever the configuration information sent by the DHCPv6 relay agent 146 to the DHCPv6 server change, the DHCPv6 server has no means to detect 147 it so that it can send a Reconfigure message with the updated 148 configuration data accordingly. A solution is sketched in Section 2. 150 1.2. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 2. Proposed Solution 158 To solve the problem described in Section 1.1, this document proposes 159 a new DHCP message called Reconfigure-Request. In the example 160 depicted in Figure 3, a Reconfigure-Request message is sent by the 161 DHCPv6 relay agent to a DHCPv6 server as soon as the configuration 162 data conveyed in an RSOO option have changed. Upon receipt of this 163 message, and if it is configured to support such mode, the DHCPv6 164 server must build Reconfigure-Reply and Reconfigure messages. 165 Reconfigure-Reply is used to acknowledge the receipt of Reconfigure- 166 Request. Reconfigure message encapsulated in Relay-Reply is sent to 167 the DHCPv6 relay, which in turn will forward the message to the 168 appropriate DHCPv6 client. 170 This setup assumes the relay has a record of the client, so that it 171 has enough information to send the Reconfigure-Request message to the 172 server. How the state is recorded in the relay is out of scope. 174 Furthermore, means to recover state in failure events must be 175 supported, but are not discussed in this document. 177 +-------+ +-------+ +-------+ 178 |DHCPv6 | | NAS | |Radius | 179 |Client | |(DHCPv6| |Server/| 180 | | | Relay)| | DAC | 181 +-------+ +-------+ +-------+ 182 | | | 183 |<-----CoA-Request-----------| 184 | (e.g. DS-Lite-Tunnel-Name) | 185 | | 186 |------CoA-Response--------->| 187 .... 188 | +-------+ 189 | |DHCPv6 | 190 | |Server | 191 | | | 192 | +-------+ 193 | | 194 |---Reconfigure-Request----->| 195 |<--Reconfigure-Reply--------| 196 | | 197 | |<--Relay-Reply -------------| 198 |<--Reconfigure-------------| (Reconfigure) | 199 | | | 200 .... 202 Figure 3: Flow Example with Reconfigure-Request 204 The support of Reconfigure-Reply simplifies the retransmission 205 procedure of the relay as it provides an explicit indication from the 206 server (see Section 4.3 for more details). An alternative approach 207 is the relay monitors Reconfigure messages received from the server 208 to conclude whether Reconfigure-Request was successfully handled or 209 not. Nevertheless, this implicit approach may fail to achieve its 210 goals in some cases: e.g., the server accepts the request but it 211 delays to generate the corresponding Reconfigure messages due to its 212 rate-limiting policies, the request was partially failed for some 213 clients, etc. To avoid useless reconfigure cycles (e.g., due to the 214 loss of Reconfigure-Reply), the approach adopted in this document 215 allows the relay to correct the content of a re-transmitted 216 Reconfigure-Request based on some observed events (e.g., the client 217 has retrieved the updated configuration). If the relay has no client 218 to reconfigured, it stops sending Reconfigure-Request messages. 220 The Reconfigure-Request message can also be used in other scenarios 221 than those that assume the use of RSOO. It is out of scope of this 222 document to describe all these scenarios. 224 3. Link Address Option 226 Figure 4 shows the format of the Link Address Option. 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | OPTION_LINK_ADDRESS | option-len | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | | 234 | link-address (IPv6 address) | 235 | | 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Figure 4: Message Format of Link Address Option 241 The description of the fields are as follows: 243 option-code: OPTION_LINK_ADDRESS (To be assigned by IANA, see 244 Section 6). 246 option-len: 16 (octets). 248 link-address: An IPv6 address used by the server to identify the 249 link on which the client is located. 251 The Link Address Option is used by the relay agent to indicate to the 252 server the link on which the client is located. The relay agent MUST 253 use a link-address value that is equivalent to the value used when 254 relaying messages from the client to the server. Two link-address 255 values are said to be equivalent if both values are IPv6 addresses 256 that are on-link for the network link to which the client is 257 connected. The relay agent SHOULD use the same value that was sent 258 to the DHCPv6 server when relaying messages from the client to the 259 server, as in Section 20.1.1 of [RFC3315]. 261 4. RECONFIGURE-REQUEST and RECONFIGURE-REPLY 263 4.1. Messages Format 265 Two new message type codes are defined: 267 o RECONFIGURE-REQUEST (To be assigned by IANA, see Section 6). 269 o RECONFIGURE-REPLY (To be assigned by IANA, see Section 6). 271 RECONFIGURE-REQUEST and RECONFIGURE-REPLY use the same format as 272 defined in Section 6 of [RFC3315]. 274 4.2. Messages Validation 276 4.2.1. RECONFIGURE-REQUEST 278 Clients MUST silently discard any received RECONFIGURE-REQUEST 279 messages. 281 Servers MUST silently discard any received RECONFIGURE-REQUEST 282 messages that meet any of the following conditions: 284 o the message does not include a Client Identifier Option [RFC3315]. 286 o the message does not include a Link Address Option (Section 3). 288 o the message includes a Server Identifier Option [RFC3315] but the 289 contents of the Server Identifier Option does not match the 290 server's identifier. 292 4.2.2. RECONFIGURE-REPLY 294 Clients and Servers MUST silently discard any received RECONFIGURE- 295 REPLY messages. 297 The relay MUST silently discard any received RECONFIGURE-REPLY 298 messages that meet any of the following conditions: 300 o the "transaction-id" field in the message does not match the value 301 used in the original message. 303 o the message does not include a Server Identifier Option. 305 o the message does not include a Status Code Option [RFC3315]. 307 4.3. Creation and Transmission of RECONFIGURE-REQUEST 309 For any event (e.g., modification of the configuration information) 310 that requires the server to issue a Reconfigure message, the relay 311 agent determines the client(s) affected by the change and then builds 312 a Reconfigure-Request message: the relay agent sets the "msg-type" 313 field to RECONFIGURE-REQUEST, generates a transaction ID and inserts 314 it in the "transaction-id" field. 316 The relay agent MUST include one or more Client Identifier Options 317 [RFC3315] and a Link Address Option (Section 3) so that the DHCPv6 318 server can identify the corresponding client and the link on which 319 the client is located. 321 The relay agent MAY supply the updated configuration in the RSOO 322 [RFC6422]. The relay agent MAY supply a Reconfigure Message Option 323 to indicate which form of Reconfigure to use. The relay agent MAY 324 include any option (e.g., Interface Identifier [RFC3315]) which it 325 might insert when relaying a message received from a client. 327 When several clients on the same link are affected by a configuration 328 change, the relay MUST include several Client Identifier Options, 329 each of them identifies a specific client. If including Client 330 Identifier Options of all impacted clients exceeds the maximum 331 message size (see Section 5), the relay MUST generate several 332 RECONFIGURE-REQUEST messages required to carry all Client Identifier 333 Options. Rate-limit considerations are discussed in Section 5. 335 The relay transmits RECONFIGURE-REQUEST messages according to Section 336 14 of [RFC3315], using the following parameters: 338 IRT 1 sec 339 MRT 10 secs 340 MRC 5 341 MRD 0 343 When retransmission is required, the relay may decide to correct the 344 content of RECONFIGURE-REQUEST message it issues (e.g., update the 345 Client Identifier list). This decision is local to the relay (e.g., 346 it may be based on observed events such as one or more clients were 347 reconfigured on their own). 349 The relay may receive Reconfigure encapsulated in Relay-Reply before 350 Reconfigure-Reply. The relay SHOULD NOT interpret it as if the 351 Reconfigure-Request was successfully handled by the Server. The 352 relay SHOULD use Reconfigure-Reply, not the Reconfigure message, to 353 determine if the request was successful. 355 4.4. Intermediate Relay Agents Behaviour 357 The relay agent MUST be configurable to accept or reject RECONFIGURE- 358 REQUEST messages received from other relay agents. If no indication 359 is explicitly configured to the relay, the default behavior is to 360 accept RECONFIGURE-REQUEST messages. 362 If the relay is configured to reject RECONFIGURE-REQUEST, the relay 363 MUST silently discard any RECONFIGURE-REQUEST it receives. If the 364 relay is configured to accept RECONFIGURE-REQUEST messages, these 365 messages are relayed as specified in Section 20.1.1 of [RFC3315]. 367 4.5. Server Behaviour 369 The server MUST be configurable to accept or reject RECONFIGURE- 370 REQUEST messages. If no indication is explicitly configured to the 371 server, the default behavior is to reject RECONFIGURE-REQUEST 372 messages. 374 If the server is configured to reject RECONFIGURE-REQUEST, the server 375 MUST silently discard any RECONFIGURE-REQUEST it receives. 377 Upon receipt of a valid Reconfigure-Request message from a DHCPv6 378 relay agent (see Section 4.2), the server determines the client(s) 379 for which a Reconfigure message is to be sent. 381 The server constructs a Reconfigure-Reply message by setting the 382 "msg-type" field to RECONFIGURE-REPLY, and copying the transaction ID 383 from the RECONFIGURE-REQUEST message into the "transaction-id" field. 384 The server MUST include a Status Code Option [RFC3315] indicating 385 whether the request is successfully processed, failed or partially 386 failed. 388 o If the server fails to validate the request, the server MUST set 389 the Status Code Option to the appropriate status code (e.g., 390 UnspecFail, NotAllowed, etc.). In particular, 392 * UnspecFail MUST be returned if Reconfigure-Request message is 393 malformed. 395 * NotAllowed MUST be returned if the server is not configured to 396 allow Reconfigure-Request. 398 * NotConfigured MUST be returned if the server has no record of 399 the link. 401 o If the Reconfigure-Request is successfully validated, the server 402 MUST return a Status Code Option indicating "Success". In 403 addition, the server MUST include a list of all the Client 404 Identifier Options of the clients to which Reconfigure messages 405 will not be sent (e.g., the server has no record of the client or 406 the client did not negotiate for Reconfigure support). Note that 407 this means that "Success" will be returned even if Reconfigure 408 messages will not be sent to any of the clients. 410 If RSOO is supplied, the server MAY use its content to double check 411 whether a Reconfigure is required to be sent to the client. This 412 assumes the server store the content of RSOO it used to generate 413 configuration data sent to requesting clients. 415 The server MAY use the content of the Reconfigure Message Option 416 supplied by the relay agent to determine which form of Reconfigure to 417 use. 419 Then, the server MUST follow the procedure defined in Section 19.1 of 420 [RFC3315] to construct a Reconfigure message. 422 Rate-limit considerations are discussed in Section 5. 424 4.6. Receipt of RECONFIGURE-REPLY 426 Depending on the status code enclosed in a received RECONFIGURE-REPLY 427 message, the relay may decide to terminate the request or try a 428 different corrected Reconfigure-Request. 430 5. Rate Limiting Considerations 432 The relay MUST rate-limit Reconfigure-Request messages to be sent to 433 the server. The relay MUST be configured with required rate-limit 434 parameters (i.e., the rate of Reconfigure messages). The maximum 435 Reconfigure-Request packet size SHOULD be configurable and the 436 default value MUST be 1280 octets. 438 The server MUST rate-limit Reconfigure messages triggered by 439 Reconfigure-Request messages. The server MUST be configured with 440 required rate-limit parameters (i.e., the rate of Reconfigure 441 messages). 443 6. IANA Considerations 445 IANA is requested to assign the following new DHCPv6 Message type in 446 the registry maintained in 447 http://www.iana.org/assignments/dhcpv6-parameters: 449 RECONFIGURE-REQUEST 451 RECONFIGURE-REPLY 453 IANA is requested to assign the following new DHCPv6 Option Codes in 454 the registry maintained in 455 http://www.iana.org/assignments/dhcpv6-parameters: 457 OPTION_LINK_ADDRESS 459 7. Security Considerations 461 Security considerations elaborated in [RFC3315] (in particular 462 Section 21.1) and [RFC6422] must be taken into account. In addition, 463 DHCPv6 servers MAY be configured to discard relayed Reconfigure- 464 Request messages or restrict relay chaining (see [RFC5007] for more 465 discussion about the rationale of this recommended behavior). 467 Relay agents SHOULD implement appropriate means to prevent using 468 Reconfigure-Request messages as a denial-of-service attack on the 469 DHCPv6 servers. 471 Because Reconfigure-Request message provides a mechanism for 472 triggering the DHCP Reconfigure message, and the DHCP Reconfigure 473 message can raise security threats (e.g., to control the timing of a 474 DHCP renewal), the DHCP server MUST have some mechanism for 475 determining that the relay agent is a trusted entity. Reconfigure- 476 Request messages originating from unknown relay agents MUST be 477 silently dropped. 479 8. Acknowledgements 481 Many thanks to R. Maglione, A. Kostur, G. Halwasia and C. Jacquenet 482 for the comments and review. 484 Special thanks to T. Lemon, B. Volz and T. Mrugalski who provided a 485 detailed review. 487 9. References 489 9.1. Normative References 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, March 1997. 494 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 495 and M. Carney, "Dynamic Host Configuration Protocol for 496 IPv6 (DHCPv6)", RFC 3315, July 2003. 498 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 499 RFC 6422, December 2011. 501 9.2. Informative References 503 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 504 "DHCPv6 Leasequery", RFC 5007, September 2007. 506 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 507 Aboba, "Dynamic Authorization Extensions to Remote 508 Authentication Dial In User Service (RADIUS)", RFC 5176, 509 January 2008. 511 Authors' Addresses 513 Mohamed Boucadair 514 France Telecom 515 Rennes, 35000 516 France 518 Email: mohamed.boucadair@orange.com 520 Xavier Pougnard 521 France Telecom 522 Lannion, 523 France 525 Phone: 526 Email: xavier.pougnard@orange.com