idnits 2.17.1 draft-jiang-dhc-stateless-reconfiguration-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 (February 14, 2014) is 3723 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) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 4242 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC WG S. Jiang 3 Internet-Draft B. Liu 4 Intended status: Standards Track Huawei Technologies Co., Ltd 5 Expires: August 18, 2014 February 14, 2014 7 Stateless Reconfiguration in Dynamic Host Configuration Protocol for 8 IPv6 (DHCPv6) 9 draft-jiang-dhc-stateless-reconfiguration-01 11 Abstract 13 This document defines a mechanism to propagate reconfigure messages 14 towards stateless configured DHCPv6 clients. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 18, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 52 3. Stateless Reconfiguration Use Cases . . . . . . . . . . . . . 4 53 4. New DHCPv6 Specifications . . . . . . . . . . . . . . . . . . 5 54 4.1. Multicast Address . . . . . . . . . . . . . . . . . . . . 5 55 4.2. Stateless Reconfigure Message . . . . . . . . . . . . . . 5 56 5. Stateless Reconfiguration Procedure . . . . . . . . . . . . . 5 57 5.1. Server Behavior . . . . . . . . . . . . . . . . . . . . . 6 58 5.2. Relay Agent Behavior . . . . . . . . . . . . . . . . . . 7 59 5.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 8 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 65 9.2. Informative References . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 [RFC3736] defines a stateless configuration procedure using DHCPv6. 71 With it, the network configure information, such as the addresses of 72 DNS recursive name servers, can be propagated to nodes, which have 73 obtained their IPv6 addresses through some other mechanism. The 74 basic scenario is that a newly online client initiates an information 75 request to DHCPv6 server, then the server responses with requested 76 configuration information. This mechanism is called the Stateless 77 DHCPv6 services, because DHCPv6 servers do not maintain any dynamic 78 state for individual clients, including the unicast addresses of 79 clients. 81 However, the specification of stateless DHCPv6 service lacks a 82 mechanism to inform these configured clients if some configuration 83 information is changed. Transplanting Reconfigure message of 84 [RFC3315] into stateless DHCPv6 services does not solve the issue, 85 because in stateful DHCPv6, servers send Reconfigure messages to 86 clients using their unicast addresses. 88 The lifetime option for DHCPv6 [RFC4242] assigns a lifetime to 89 configuration information obtained through DHCPv6. At the expiration 90 of the lifetime, the host contacts the DHCPv6 server to obtain 91 updated configuration information. This lifetime gives the network 92 administrator another mechanism to configure hosts with new 93 configuration by controlling the time at which the host refreshes the 94 list. However, such mechanism is not flexible enough: one aspect is 95 the minimum of refresh time is 10 minutes, which is so long that it 96 might not be suitable for unplanned configuration changes; the other 97 aspect is, in order to update the configuration quickly, the short 98 time setting would cause un-necessary refresh all the time. 100 This document defines a mechanism to propagate a newly defined 101 Stateless-Reconfigure message towards stateless configured DHCPv6 102 clients. It requests a mechanism for the DHCPv6 server to be aware 103 of all relay agent destinations. 105 {Question to WG No.1} There are three potential mechanisms to create 106 relay agent destinations on the DHCPv6 server: 108 a) Static configuration 110 Network administrators manually configure static unicast addresses of 111 all relay agents on the DHCPv6 server. 113 Pros: no need to update any protocol/function implementation in 114 relays; allows fast deployment in current network. 116 Cons: cost significant human management burden; error-prone, 117 mistakenly configuring the relay addresses or leaving out some relays 118 are expected. 120 b) Define a new ALL_RELAY_AGENT multicast address 122 The DHCPv6 server could send the stateless reconfiguration messages 123 directly to the new multicast address. 125 Pros: a solid coverage of all relays. 127 Cons: network administrators need to maintain an all-relay-agent 128 multicast group; all relays and DHCPv6 servers need to be updated to 129 know the new multicast address. 131 c) DHCPv6 server dynamic learning 133 the DHCPv6 server dynamically records unicast addresses of all relay 134 agents from client Information-request messages and maintains the 135 relay addresses list. A keepalive mechanism is needed between relay 136 agents and servers to track the availability of the list entries. 138 Pros: automatic processing without human intervene. 140 Cons: requires more function update to the DHCPv6 server; the 141 keepalive mechanism requires more function/protocol burden to the 142 whole DHCP system. 144 [Editor Notes] the current form of this document is based on only the 145 first mechanism of above three. If the WG decided to change or 146 include other mechanism, the document would be updated accordingly. 148 The document newly defines a new link-scope well-known all-client 149 multicast address and a new DHCPv6 message type for stateless 150 reconfiguration. Correspondent server behavior, agent behavior and 151 client behavior are specificed in details. 153 The design of new DHCPv6 elements and precedures obey the 154 recommendations and guidance of [I-D.ietf-dhc-option-guidelines]. 156 2. Requirements Language 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 160 "OPTIONAL" in this document are to be interpreted as described in 161 [RFC2119] when they appear in ALL CAPS. When these words are not in 162 ALL CAPS (such as "should" or "Should"), they have their usual 163 English meanings, and are not to be interpreted as [RFC2119] key 164 words. 166 3. Stateless Reconfiguration Use Cases 168 This section described scenarisos where stateless reconfiguration are 169 expected. 171 - Configuration error 173 Configuration errors, eithor caused by human or program, are hard to 174 be immune in networks. Especially, human errors is identified as one 175 of the top reasons of network failure. In stateless DHCPv6, if the 176 administrators/program accidentally mis-configure the parameters 177 (e.g. DNS), then significant network failure would be expected. 178 Current protocols just lack the ability to eliminate the 179 configuration errors when such accident happens. The hosts 180 configured with wrong parameters can only wait until the wrong 181 parameters lifetime expired then to refresh them. This would not be 182 acceptable especially when the lifetime was long. The stateless 183 reconfiguration mechanism could be highly expected in this scenario. 185 - Emergent event 187 The network needs to initially update the already configured 188 parameters within a short period due to some emergent events; and 189 waiting the clients to refresh the parameters according to the 190 lifetime is just un-acceptable. These scenarios would also require 191 statless reconfiguration. 193 4. New DHCPv6 Specifications 195 This section define new DHCPv6 elements requested by the stateless 196 configuration mechanism, including multicast address constant, and 197 message type. 199 4.1. Multicast Address 201 ALL_CLIENT_MULTICAST_ADDRESS (FF02::xxxx, TBD1) A link-scoped 202 multicast address used by a DHCPv6 server or relay agent to 203 communicate with neighboring (i.e., on-link) clients. All clients 204 are members of this multicast group 206 4.2. Stateless Reconfigure Message 208 A new Stateless-Reconfigure message, which is mainly based on server 209 to clients advertise model, is defined in order to distinguish from 210 the existing Reconfigure message, which is mainly based on server/ 211 client one-to-one model. 213 [Editor Notes] According to the results of Qeston 2 and Question 4 214 (in Section 5 & 7 below), there might be two new messages needed. 215 Current document uses the alternative of one new message. 217 STATELESS-RECONFIGURE-TRIGGER Message type value is TBD2. It 218 follows the message format specification, defined in Section 6 of 219 [RFC3315]. A server sends a Stateless-Reconfigure message to a 220 client to inform the client that the server has new or updated 221 configuration parameters, and that the client is to initiate an 222 Information-Request transaction with the server in order to 223 receive the updated information. 225 5. Stateless Reconfiguration Procedure 227 {Question to WG No.2} There could be two kind of stateless DHCPv6 228 reconfiguration modes as the following, which one is proper? Or we 229 should support both? 231 - Trigger mode 233 The server sends out a multicast Stateless-Reconfiguration message to 234 ALL_CLIENT_MULTICAST_ADDRESS. As response, every client is requested 235 to initiate an Information-Request message back to the server. The 236 server can then inform the changed configuration information to 237 clients. 239 This mode is similar with stateful DHCPv6 reconfiguration and also 240 provide the potential possibility that the server response to 241 information-request differently according to various user policies. 243 - Push mode 245 The server sends out a multicast Stateless-Reconfiguration message to 246 ALL_CLIENT_MULTICAST_ADDRESS to directly advertise new configuration 247 to the clients. The clients then update the parameters accordingly. 249 Trigger mode requires every client to initial individual request to 250 servers. This is reasonable for the stateful information that need 251 to be maintaind and tracked in the servers, e.g. clients' IP 252 addresses. But for the stateless information shared among clients 253 (such as DNS), it might not necessary. Some resource constrained 254 networks (e.g. a 802.15.4e/g based mesh network) might have efficency 255 problem with the trigger mode. These scenarios might significantly 256 benifit from the push mode stateless reconfiguration mechanism. 257 However, push mode seems breaking the triditional behavior model of 258 DHCP. Whether it is a good break needs further discussion. 260 [Editor Notes] the current form of this document is based on 261 triggering client information-request model, which complies the 262 traditional behavior model of DHCPv6. If the WG chooses to directly 263 advertise new configuration, the document would be updated 264 accordingly. 266 5.1. Server Behavior 268 When the network configuration information on a stateless DHCPv6 269 server changes, the server creates and transmit a new Stateless- 270 Reconfigure message towards all clients following the below steps: 272 o The server sets the "msg-type" field to STATELESS-RECONFIGURE. 273 The server sets the transaction-id field to 0. The server MUST 274 include a Server Identifier option containing its DUID in the 275 Reconfigure message. 277 o The server MAY include an Option Request option to inform the 278 client of what information has been changed or new information 279 that has been added. 281 o The server MUST NOT include a Reconfigure Message option (defined 282 in section 22.19 of [RFC3315]), which is mandated in Reconfigure 283 message to indicate the client to respond a Renew or an 284 Information-Request message. It is because there is only one 285 possible response on the client follow a Stateless-Reconfigure 286 message - an Information-request message. 288 o The server MUST NOT include any other options in the Reconfigure 289 except as specifically allowed in the definition of individual 290 options. 292 o The server sends Stateless-Reconfigure message to its direct local 293 link using ALL_CLIENT_MULTICAST_ADDRESS. 295 o Simultaneously, the server uses a Relay-Reply message (as 296 described in Section 20.3 of [RFC3315]) to send the Stateless- 297 Reconfigure message to all relay agents in its static relay-agent- 298 destination record using the unicast address of these relay 299 agents. The peer-address of the Relay-Reply message MUST be 300 filled by Relay-Reply message ALL_CLIENT_MULTICAST_ADDRESS. 302 Notes: since there is no previous Relay-Forward message that went 303 through multiple relay agents and the server has to send the Relay- 304 Reply message through the return same path, the server should be able 305 to send the Relay-Reply message to the relay agent that direct 306 connects with clients. Consequently, the Relay-Reply message SHOULD 307 NOT contain another Relay-Reply message. 309 The below is an example of a typical Relay-Reply message that 310 contains a Stateless-Reconfigure message: 312 msg-type: RELAY-REPLY 313 hop-count: 0 314 link-address: 0 315 peer-address: ALL_CLIENT_MULTICAST_ADDRESS 316 Relay Message option: 318 Servers MUST discard any received Stateless-Reconfigure messages. 320 5.2. Relay Agent Behavior 322 The relay agent extracts the Stateless-Reconfigure message from the 323 Relay Message option and relays it to all clients. If the relay 324 agent is attached to multiple links, it MUST broadcast the Stateless- 325 Reconfigure message on every links. This behavior is compliance with 326 normal behavior of relaying a Relay-reply message, defined in 327 Section 20.2 of [RFC3315]. 329 Relay agents MUST discard any received Stateless-Reconfigure 330 messages. By design, relay agents do not process any directly 331 received Stateless-Reconfigure messages. 333 The result is that the relay agent sends out a Stateless-Reconfigure 334 message towards all client on the local link using 335 ALL_CLIENT_MULTICAST_ADDRESS. 337 5.3. Client Behavior 339 Clients MUST discard any Stateless-Reconfigure messages that meets 340 any of the following conditions: 342 o the message was not multicast to the client using 343 ALL_CLIENT_MULTICAST_ADDRESS. 345 o the message does not include a Server Identifier option. 347 o the message contains a Reconfigure Message Option, defined in 348 Section 22.19 of [RFC3315]. 350 Upon receipt of a valid Stateless-Reconfigure message, after a random 351 delay time, the client responds with an Information-request message. 352 The random delay time is designed to avoid congested Information- 353 request on the server. While the transaction is in progress, the 354 client silently discards any Stateless-Reconfigure messages it 355 receives. 357 {Question to WG No.3} Should we define a maximum time of random delay 358 time? If yes, should it come from server by a new option? 360 6. Security Considerations 362 Malicious server sends Stateless Reconfigure message to cause all 363 clients response. There is the risk of denial of service attacks 364 against DHCP clients and server. {Current auth mechanism cannot work 365 in this broadcast model, server public key model maybe work.} 367 Since the clients response to Information-Request using the standard 368 mechanism, defined in [RFC3315], the chance that receive wrong 369 configuration information from malicious attackers does not raise. 371 7. IANA Considerations 373 Per this document, IANA has assigned one new well-known Multicast 374 Address in the "IPv6 Multicast Address Space Registry" registry 375 (currently located at http://www.iana.org/assignments/ipv6-multicast- 376 addresses) for the following attribute: 378 ALL_CLIENT_MULTICAST_ADDRESS: (FF02::xxxx, TBD1). 380 Per this document, IANA has assigned one new DHCPv6 message type in 381 the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry 382 (currently located at http://www.iana.org/assignments/ 383 dhcpv6-parameters) for the following attribute: 385 STATELESS-RECONFIGURE Message Type, TBD2. 387 {Question to WG No.4} As raised in Question 2, if we support both 388 Trigger mode and Push mode, then there should be two kind of 389 corresponding messages. We could use two message types to 390 distinguish them; or use a flag in one message type. Which is 391 better? 393 8. Acknowledgements 395 The authors would like to thanks the valuable comments made by Suresh 396 Krishnan, Ted Lemon, Bernie Voltz and other members of DHC WG. 398 This document was produced using the xml2rfc tool [RFC2629]. 400 9. References 402 9.1. Normative References 404 [I-D.ietf-dhc-option-guidelines] 405 Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 406 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 407 draft-ietf-dhc-option-guidelines-17 (work in progress), 408 January 2014. 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, March 1997. 413 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 414 and M. Carney, "Dynamic Host Configuration Protocol for 415 IPv6 (DHCPv6)", RFC 3315, July 2003. 417 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 418 (DHCP) Service for IPv6", RFC 3736, April 2004. 420 9.2. Informative References 422 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 423 June 1999. 425 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 426 Time Option for Dynamic Host Configuration Protocol for 427 IPv6 (DHCPv6)", RFC 4242, November 2005. 429 Authors' Addresses 431 Sheng Jiang 432 Huawei Technologies Co., Ltd 433 Q14, Huawei Campus, No.156 Beiqing Road 434 Hai-Dian District, Beijing, 100095 435 P.R. China 437 Email: jiangsheng@huawei.com 439 Bing Liu 440 Huawei Technologies Co., Ltd 441 Q14, Huawei Campus, No.156 Beiqing Road 442 Hai-Dian District, Beijing, 100095 443 P.R. China 445 Email: leo.liubing@huawei.com