idnits 2.17.1 draft-ietf-dhc-triggered-reconfigure-07.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 15, 2013) is 3998 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 16, 2013 May 15, 2013 7 Reconfigure Triggered by DHCPv6 Relay Agents 8 draft-ietf-dhc-triggered-reconfigure-07 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 16, 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 Statement . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 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 . . . . 8 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 Statement 106 For cases where the DHCPv6 relay agent possesses some information 107 that would be useful to the DHCPv6 client, [RFC6422] specifies a 108 mechanism whereby the DHCPv6 relay agent can provide such information 109 to the DHCPv6 server, which can, in turn, pass this information on to 110 the DHCP client. This is achieved owing to the use of RSOO (Relay- 111 Supplied Options option) which carries configuration data to the 112 DHCPv6 server. The data conveyed in an RSOO is then sent back by the 113 DHCPv6 server to the requesting DHCPv6 client. 115 An example of a RSOO context is shown in Figure 1; only a subset of 116 exchanged DHCPv6 and RADIUS messages is represented. Figure 1 shows 117 a broadband network scenario in which the Network Access Server (NAS) 118 embeds a DHCPv6 relay agent. 120 +-------+ +-------+ +-------+ 121 |DHCPv6 | | NAS | |Radius | 122 |Client | |(DHCPv6| |Server | 123 | | | Relay)| | | 124 +-------+ +-------+ +-------+ 125 | | | 126 |---Solicit---------------->| | 127 | |---Access-Request---------->| 128 |<--Access-Accept------------| 129 | (e.g. DS-Lite-Tunnel-Name)| 130 .... 131 | +-------+ 132 | |DHCPv6 | 133 | |Server | 134 | | | 135 | +-------+ 136 | | 137 |---Relay-Forward----------->| 138 | (RSOO(OPTION_AFTR_NAME)) | 139 | | 140 | |<--Relay-Reply--------------| 141 |<--Advertise---------------| (e.g., OPTION_AFTR_NAME) | 142 | (e.g., OPTION_AFTR_NAME) | 143 .... 145 Figure 1: An Example of the RSOO Option Usage 147 A configuration change may result in an exchange of CoA (Change-of- 148 Authorization, [RFC5176]) messages between the NAS/DHCPv6 relay agent 149 and Dynamic Authorization Client (DAC) server as shown in Figure 2. 150 In this example, the NAS answers with a CoA-Ack message to notify the 151 DAC the CoA-Request is successfully handled. 153 Note the change of the configuration in the DHCPv6 relay agent can be 154 triggered by any other out-of-band mechanism. 156 +-------+ +-------+ +-------+ 157 |DHCPv6 | | NAS | |Radius | 158 |Client | |(DHCPv6| |Server/| 159 | | | Relay)| | DAC | 160 +-------+ +-------+ +-------+ 161 | | | 162 |<-----CoA-Request-----------| 163 | (e.g. DS-Lite-Tunnel-Name) | 164 |------CoA-Ack-------------->| 165 .... 167 Figure 2: Change of configuration 169 Whenever the configuration information sent by the DHCPv6 relay agent 170 to the DHCPv6 server change, the DHCPv6 server has no means to detect 171 the change so that it can send a Reconfigure message accordingly. A 172 solution is sketched in Section 4. 174 4. Solution Overview 176 To solve the problem described in Section 3, this document proposes a 177 new DHCP message called Reconfigure-Request. In the example depicted 178 in Figure 3, a Reconfigure-Request message is sent by the DHCPv6 179 relay agent to a DHCPv6 server as soon as the configuration data 180 conveyed in an RSOO option have changed. Upon receipt of this 181 message, and if it is configured to support such mode, the DHCPv6 182 server must build Reconfigure-Reply and Reconfigure messages. 183 Reconfigure-Reply is used to acknowledge the receipt of Reconfigure- 184 Request. Reconfigure message encapsulated in Relay-Reply is sent to 185 the DHCPv6 relay, which in turn will forward the message to the 186 appropriate DHCPv6 client. 188 This setup assumes the relay has a record of the client, so that it 189 has enough information to send the Reconfigure-Request message to the 190 server. How the state is recorded in the relay is out of scope. For 191 better resilience of the proposed solution, means to recover state in 192 failure events (e.g., use of stable storage, DHCPv6 Bulk Leasequery 193 [RFC5460]) need to be supported. These state recovery solutions are 194 not discussed in this document. 196 +-------+ +-------+ +-------+ 197 |DHCPv6 | | NAS | |Radius | 198 |Client | |(DHCPv6| |Server/| 199 | | | Relay)| | DAC | 200 +-------+ +-------+ +-------+ 201 | | | 202 |<-----CoA-Request-----------| 203 | (e.g. DS-Lite-Tunnel-Name) | 204 | | 205 |------CoA-Ack-------------->| 206 .... 207 | +-------+ 208 | |DHCPv6 | 209 | |Server | 210 | | | 211 | +-------+ 212 | | 213 |---Reconfigure-Request----->| 214 |<--Reconfigure-Reply--------| 215 | | 216 | |<--Relay-Reply -------------| 217 |<--Reconfigure-------------| (Reconfigure) | 218 | | | 219 .... 221 Figure 3: Flow Example with Reconfigure-Request 223 The support of Reconfigure-Reply simplifies the retransmission 224 procedure of the relay as it provides an explicit indication from the 225 server (see Section 6.3 for more details). An alternative approach 226 is the relay monitors Reconfigure messages received from the server 227 to conclude whether Reconfigure-Request was successfully handled or 228 not. Nevertheless, this implicit approach may fail to achieve its 229 goals in some cases: e.g., the server accepts the request but it 230 delays to generate the corresponding Reconfigure messages due to its 231 rate-limiting policies, the request was partially failed for some 232 clients, etc. To avoid useless reconfigure cycles (e.g., due to the 233 loss of Reconfigure-Reply), the approach adopted in this document 234 allows the relay to correct the content of a re-transmitted 235 Reconfigure-Request based on some observed events (e.g., the client 236 has retrieved the updated configuration). If the relay has no client 237 to be reconfigured, it stops sending Reconfigure-Request messages. 239 The Reconfigure-Request message can also be used in other scenarios 240 than those that assume the use of RSOO. It is out of scope of this 241 document to describe all these scenarios. 243 5. Link Address Option 245 Figure 4 shows the format of the Link Address Option. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | OPTION_LINK_ADDRESS | option-len | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | 253 | link-address (IPv6 address) | 254 | | 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Figure 4: Message Format of Link Address Option 260 The description of the fields are as follows: 262 option-code: OPTION_LINK_ADDRESS (To be assigned by IANA, see 263 Section 8). 265 option-len: 16 (octets). 267 link-address: An IPv6 address used by the server to identify the 268 link on which the client is located. 270 The Link Address Option is used by the relay agent to indicate to the 271 server the link on which the client is located. The relay agent MUST 272 use a link-address value that is equivalent to the value used when 273 relaying messages from the client to the server. Two link-address 274 values are said to be equivalent if both values are IPv6 addresses 275 that are on-link for the network link to which the client is 276 connected. 278 To defend against poor implementations that do not correctly evaluate 279 equivalence, the relay agent SHOULD use the same value that was sent 280 to the DHCPv6 server when relaying messages from the client to the 281 server, as in Section 20.1.1 of [RFC3315]. 283 6. Detailed Specification 285 6.1. Messages Format 287 Two new message type codes are defined: 289 o RECONFIGURE-REQUEST (To be assigned by IANA, see Section 8). 291 o RECONFIGURE-REPLY (To be assigned by IANA, see Section 8). 293 RECONFIGURE-REQUEST and RECONFIGURE-REPLY use the same format as 294 defined in Section 6 of [RFC3315]. 296 6.2. Messages Validation 298 6.2.1. RECONFIGURE-REQUEST 300 Clients MUST silently discard any received RECONFIGURE-REQUEST 301 messages. 303 Servers MUST discard any received RECONFIGURE-REQUEST messages that 304 meet any of the following conditions: 306 o the message does not include a Client Identifier Option [RFC3315]. 308 o the message does not include a Link Address Option (Section 5). 310 o the message includes a Server Identifier Option [RFC3315] but the 311 contents of the Server Identifier Option does not match the 312 server's identifier. 314 6.2.2. RECONFIGURE-REPLY 316 Clients and Servers MUST silently discard any received RECONFIGURE- 317 REPLY messages. 319 The relay MUST silently discard any received RECONFIGURE-REPLY 320 messages that meet any of the following conditions: 322 o the "transaction-id" field in the message does not match the value 323 used in the original message. 325 o the message does not include a Server Identifier Option. 327 o the message does not include a Status Code Option [RFC3315]. 329 6.3. Creation and Transmission of RECONFIGURE-REQUEST 331 For any event (e.g., modification of the configuration information) 332 that requires the server to issue a Reconfigure message, the relay 333 agent determines the client(s) affected by the change and then builds 334 a Reconfigure-Request message: the relay agent sets the "msg-type" 335 field to RECONFIGURE-REQUEST, generates a transaction ID and inserts 336 it in the "transaction-id" field. 338 The relay agent MUST include one or more Client Identifier Options 339 [RFC3315] and a Link Address Option (Section 5) so that the DHCPv6 340 server can identify the corresponding client and the link on which 341 the client is located. 343 The relay agent MAY include a Relay Identifier Option [RFC5460]. 345 The relay agent MAY supply the updated configuration in the RSOO 346 [RFC6422]. The relay agent MAY supply a Reconfigure Message Option 347 to indicate which form of Reconfigure to use. The relay agent MAY 348 include any option (e.g., Interface Identifier [RFC3315]) which it 349 might insert when relaying a message received from a client. 351 When several clients on the same link are affected by a configuration 352 change, the relay MUST include several Client Identifier Options, 353 each of them identifies a specific client. If including Client 354 Identifier Options of all impacted clients exceeds the maximum 355 message size (see Section 7), the relay MUST generate several 356 RECONFIGURE-REQUEST messages required to carry all Client Identifier 357 Options. Rate-limit considerations are discussed in Section 7. 359 The relay sets the destination address of the RECONFIGURE-REQUEST 360 message to the IP address it would have sent a Relay-Forw message 361 (see Section 20 of [RFC3315]). 363 In case multiple servers are configured to the relay agent, several 364 RECONFIGURE-REQUEST messages are to be built. The behavior of the 365 relay agent to disambiguate responses when multiple servers are 366 configured is implementation-specific. For example, an 367 implementation may generate distinct "transaction-id"s per server 368 while another implementation may use the content of the "transaction- 369 id" field and the Server Identifier Option to disambiguate the 370 responses. 372 The relay transmits RECONFIGURE-REQUEST messages according to 373 Section 14 of [RFC3315], using the following parameters: 375 IRT 1 sec 376 MRT 10 secs 377 MRC 5 378 MRD 0 380 The relay MAY remove clients from the client identifier list in 381 subsequent retransmissions, but MUST NOT add clients to the client 382 identifier list. This decision is local to the relay (e.g., it may 383 be based on observed events such as one or more clients were 384 reconfigured on their own). 386 The relay may receive Reconfigure encapsulated in Relay-Reply before 387 Reconfigure-Reply. The relay SHOULD NOT interpret it as if the 388 Reconfigure-Request was successfully handled by the Server. The 389 relay SHOULD use Reconfigure-Reply, not the Reconfigure message, to 390 determine if the request was successful (see the discussion in 391 Section 4) . 393 6.4. Intermediate Relay Agents Behavior 395 The relay agent MUST be configurable to accept or reject RECONFIGURE- 396 REQUEST messages received from other relay agents. If no indication 397 is explicitly configured to the relay, the default behavior is to 398 accept RECONFIGURE-REQUEST messages. 400 If the relay is configured not to allow RECONFIGURE-REQUEST messages, 401 the relay MUST silently discard any RECONFIGURE-REQUEST message it 402 receives. If the relay is configured to accept RECONFIGURE-REQUEST 403 messages, these messages are relayed as specified in Section 20.1.1 404 of [RFC3315]. 406 6.5. Server Behavior 408 The server MUST be configurable to accept or reject RECONFIGURE- 409 REQUEST messages. If no indication is explicitly configured to the 410 server, the default behavior is to reject RECONFIGURE-REQUEST 411 messages. 413 Upon receipt of a valid RECONFIGURE-REQUEST message from a DHCPv6 414 relay agent (see Section 6.2), the server determines the client(s) 415 for which a Reconfigure message is to be sent. 417 The server constructs a Reconfigure-Reply message by setting the 418 "msg-type" field to RECONFIGURE-REPLY, and copying the transaction ID 419 from the RECONFIGURE-REQUEST message into the "transaction-id" field. 420 The server includes its server identifier in a Server Identifier 421 Option. The server MUST include a Status Code Option [RFC3315] 422 indicating whether the request is successfully processed, failed or 423 partially failed. 425 o If the server fails to process the request, the server MUST set 426 the Status Code Option to the appropriate status code (e.g., 427 UnspecFail, NotAllowed, etc.). In particular, 429 * UnspecFail MUST be returned if Reconfigure-Request message is 430 malformed. 432 * NotAllowed MUST be returned if the server is not configured to 433 allow Reconfigure-Request. 435 * NotConfigured MUST be returned if the server has no record of 436 the link [RFC5007]. 438 o If the RECONFIGURE-REQUEST is successfully validated, the server 439 MUST return a Status Code Option indicating "Success". In 440 addition, the server MUST include a list of all the Client 441 Identifier Options of the clients to which Reconfigure messages 442 will not be sent (e.g., the server has no record of the client or 443 the client did not negotiate for Reconfigure support). Note that 444 this means that "Success" will be returned even if Reconfigure 445 messages will not be sent to any of the clients. 447 If RSOO is supplied, the server might use its content to double check 448 whether a Reconfigure is required to be sent to the client. This 449 assumes the server stored the content of RSOO it used to generate 450 configuration data sent to requesting clients. 452 The server might use the content of the Reconfigure Message Option 453 supplied by the relay agent to determine which form of Reconfigure to 454 use. 456 Then, the server MUST follow the procedure defined in Section 19.1 of 457 [RFC3315] to construct a Reconfigure message. 459 Rate-limit considerations are discussed in Section 7. 461 6.6. Receipt of RECONFIGURE-REPLY 463 Depending on the status code enclosed in a received RECONFIGURE-REPLY 464 message, the relay may decide to terminate the request (e.g., 465 NotAllowed, NotConfigured, and Success) or try a different corrected 466 RECONFIGURE-REQUEST (e.g., UnspecFail). 468 When multiple servers are configured, the relay should expect to 469 receive several RECONFIGURE-REPLY messages. As mentioned in 470 Section 6.3, the relay should be able to disambiguate these responses 471 and associate them with a given server. The relay agent assumes the 472 request is successfully handled for a client if there is at least one 473 Reconfigure-Reply message in which the corresponding Client 474 Identifier Option does not appear. 476 7. Rate Limiting Considerations 478 The relay MUST rate-limit RECONFIGURE-REQUEST messages to be sent to 479 the server. The relay MUST be configured with required rate-limit 480 parameters. The maximum RECONFIGURE-REQUEST packet size SHOULD be 481 configurable and the default value MUST be 1280 octets. 483 The server MUST rate-limit Reconfigure messages triggered by 484 RECONFIGURE-REQUEST messages. The server MUST be configured with 485 required rate-limit parameters. 487 8. IANA Considerations 489 IANA is requested to assign the following new DHCPv6 Message type in 490 the registry maintained in http://www.iana.org/assignments/ 491 dhcpv6-parameters: 493 RECONFIGURE-REQUEST 495 RECONFIGURE-REPLY 497 IANA is requested to assign the following new DHCPv6 Option Codes in 498 the registry maintained in http://www.iana.org/assignments/ 499 dhcpv6-parameters: 501 OPTION_LINK_ADDRESS 503 9. Security Considerations 505 Security considerations elaborated in [RFC3315] (in particular 506 Section 21.1) and [RFC6422] must be taken into account. In addition, 507 DHCPv6 servers MAY be configured to reject relayed RECONFIGURE- 508 REQUEST messages or restrict relay chaining (see [RFC5007] for more 509 discussion about the rationale of this recommended behavior). 510 Section 6.5 specifies the error code to return when the server is 511 configured to reject RECONFIGURE-REQUEST messages. 513 Relay agents SHOULD implement appropriate means to prevent using 514 RECONFIGURE-REQUEST messages as a denial-of-service attack on the 515 DHCPv6 servers. 517 Because RECONFIGURE-REQUEST message provides a mechanism for 518 triggering the DHCPv6 Reconfigure message, and the DHCPv6 Reconfigure 519 message can raise security threats (e.g., to control the timing of a 520 DHCPv6 renewal), the DHCPv6 server MUST have some mechanism for 521 determining that the relay agent is a trusted entity. DHCPv6 servers 522 and relay agents MUST implement relay message authentication as 523 described in Section 21.1 of [RFC3315]. DHCPv6 servers MAY also 524 implement a control policy based on the content of received Relay 525 Identifier Option [RFC5460]. Administrators are strongly advised to 526 configure one of these security mechanisms. 528 In an environment where the network connecting the relay agent to the 529 DHCPv6 server is physically secure and does not contain devices not 530 controlled by the server administrator, it may be sufficient to trust 531 the Relay Agent Identifier provided by the relay agent. In networks 532 where the security of the machines with access to the data path is 533 not under the control of the server administrator, IPsec [RFC4301] is 534 necessary to prevent spoofing of RECONFIGURE-REQUEST messages. 535 DHCPv6 servers MUST silently discard RECONFIGURE-REQUEST messages 536 originating from unknown relay agents. 538 10. Acknowledgements 540 Many thanks to R. Maglione, A. Kostur, G. Halwasia, C. Jacquenet, 541 B. Leiba, R. Sparks, A. Farrel, B. Claise, J. Jaeggli, and P. 542 Resnick for the comments and review. 544 Special thanks to T. Lemon, B. Volz and T. Mrugalski who provided 545 a detailed review. 547 11. References 549 11.1. Normative References 551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, March 1997. 554 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 555 and M. Carney, "Dynamic Host Configuration Protocol for 556 IPv6 (DHCPv6)", RFC 3315, July 2003. 558 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC 559 6422, December 2011. 561 11.2. Informative References 563 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 564 Internet Protocol", RFC 4301, December 2005. 566 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 567 "DHCPv6 Leasequery", RFC 5007, September 2007. 569 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 570 Aboba, "Dynamic Authorization Extensions to Remote 571 Authentication Dial In User Service (RADIUS)", RFC 5176, 572 January 2008. 574 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 575 2009. 577 Authors' Addresses 579 Mohamed Boucadair 580 France Telecom 581 Rennes 35000 582 France 584 Email: mohamed.boucadair@orange.com 586 Xavier Pougnard 587 France Telecom 588 Lannion 589 France 591 Email: xavier.pougnard@orange.com