1 2 3Network Working Group R. Droms 4Internet-Draft Cisco Systems 5Expires: October 5, 2003 April 6, 2003 6 7 8 A Guide to Implementing Stateless DHCPv6 Service 9 draft-ietf-dhc-dhcpv6-stateless-00.txt 10 11Status of this Memo 12 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 15 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 20 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 26 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 29 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 32 33 This Internet-Draft will expire on October 5, 2003. 34 35Copyright Notice 36 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 39Abstract 40 41 Stateless DHCPv6 service is used by nodes to obtain configuration 42 information such as the addresses of DNS recursive name servers 43 that does not require the maintenance of any dynamic state for 44 individual clients. A node that uses stateless DHCP must have 45 obtained its IPv6 addresses through some other mechanism, 46 typically stateless address autoconfiguration. This document is a 47 guide to the protocol messages and options that must be 48 implemented to provide stateless DHCPv6 service. 49 50 51 52 53 54 55Droms Expires October 5, 2003 [Page 1] 56 57Internet-Draft Stateless DHCPv6 Implementation Guide April 2003 58 59 60 1. Introduction 61 62 Nodes that have obtained IPv6 addresses through some other 63 mechanism can use stateless DHCPv6 to obtain other configuration 64 information such as a list of DNS recursive name servers or NTP 65 servers. A stateless DHCPv6 server provides only configuration 66 information to nodes and does not perform any address assignment. 67 Such a server is called "stateless" because it need not maintain 68 any dynamic state for individual clients. 69 70 While the DHCPv6 specification [1] defines more than 10 protocol 71 messages and 20 options, only a subset of those messages and 72 options are required for stateless DHCPv6 service. This document 73 gives guidelines about which messages and options are required for 74 stateless DHCPv6 service. The intended use of the document is to 75 guide the efficient and complete implementation of clients and 76 servers that use stateless DHCPv6 service. 77 78 The operation of relay agents is the same for stateless and 79 stateful DHCPv6 service. The operation of relay agents is 80 described in the DHCPv6 specification. 81 82 Section 4 of this document lists the sections of the DHCPv6 83 document that an implementor should read for an overview of the 84 DHCPv6 specification and the basic requirements of a DHCPv6 85 service. Section 5 lists the specific messages and options that 86 are specifically required for stateless DHCPv6 service. Section 6 87 describes how stateless and stateful DHCPv6 servers interact to 88 provide service to clients that require address assignment and 89 clients that require only stateless service. 90 91 2. Terminology 92 93 Throughout this document, "DHCP" refers to DHCP for IPv6. 94 95 This document uses the terminology defined in RFC2460 [2], the 96 DHCP specification, the DHCP DNS configuration options 97 specification [3] and the DHCP NTP configuration options 98 specification [4]. 99 100 "Stateless DHCP" refers to the use of DHCP to provide 101 configuration information to clients that does not require the 102 server to maintain dynamic state about the DHCP clients. 103 104 3. Overview 105 106 This document assumes that a node using stateless DHCP 107 configuration is not using DHCP for address assignment, and that a 108 109 110 111Droms Expires October 5, 2003 [Page 2] 112 113Internet-Draft Stateless DHCPv6 Implementation Guide April 2003 114 115 116 node has determined at least a link-local address as described in 117 section 5.3 of RFC2461 [5] 118 119 To obtain configuration parameters through stateless DHCP, a node 120 uses the DHCP Information-request message. DHCP servers respond 121 to the node's message with a Reply message that carries the DNS 122 configuration parameters. The Reply message from the server can 123 carry configuration information such as a list of DNS recursive 124 name servers and NTP servers. 125 126 4. Basic Requirements for Implementation of DHCP 127 128 Several sections of the DHCP specification [1] provide background 129 information or define parts of the specification that are common 130 to all implementations: 131 132 1-4: give an introduction to DHCPv6 and an overview of DHCP 133 message flows 134 135 5: defines constants used throughout the protocol 136 specification 137 138 6, 7: illustrates the format of DHCP messages 139 140 8: describes the representation of Domain Names 141 142 9: defines the "DHCP unique identifier" (DUID) optionally used 143 to identify DHCP participants 144 145 13-16: describe DHCP message transmission, retransmission and 146 validation 147 148 21: describes authentication for DHCP 149 150 151 5. Implementation of stateless DHCP 152 153 The client indicates that it is requesting configuration 154 information by sending an Information-request message that 155 includes an Option Request option specifying the options that it 156 wishes to receive from the DHCP server. For example, if the 157 client is attempting to obtain DNS configuration information, it 158 includes either or both of the DNS configuration options in the 159 Information-request message. The server determines the 160 appropriate configuration parameters for the client based on its 161 configuration policies and responds with a Reply message 162 containing the requested parameters. In this example, the server 163 would respond with DNS configuration parameters. 164 165 166 167Droms Expires October 5, 2003 [Page 3] 168 169Internet-Draft Stateless DHCPv6 Implementation Guide April 2003 170 171 172 A node uses the DUID option to identify itself to a server, 173 because the server administrator may want to customize the 174 server's response to each node, based on the node's identity. 175 176 5.1 Messages required for stateless DHCP 177 178 Clients and servers implement the following messages for stateless 179 DHCP service; the section numbers in this list refer to the DHCPv6 180 specification: 181 182 Information-request: sent by a DHCP client to a server to request 183 DNS configuration parameters (sections 18.1.5 and 18.2.5) 184 185 Reply: sent by a DHCP server to a client containing 186 the DNS configuration parameters (sections 18.2.6 and 18.2.8) 187 188 In addition, servers and relay agents implement the following 189 messages for stateless DHCP service: 190 191 Relay-forward: Sent by a DHCP relay agent to carry the client 192 message to a server (section 15.13) 193 194 Relay-reply: Sent by a DHCP server to carry a response message 195 to the relay agent (section 15.14) 196 197 198 5.2 Options required for stateless DHCP service 199 200 Clients and servers implement the following options for stateless 201 DHCP service; the section numbers in this list refer to the DHCPv6 202 specification: 203 204 Option Request: specifies the configuration information that the 205 client is requesting from the server (section 22.7) 206 207 Status Code: used to indicate completion status or other status 208 information (section 22.13) 209 210 Servers and relay agents implement the following options for 211 stateless DHCP service; the section numbers in this list refer to 212 the DHCPv6 specification: 213 214 Client message: Sent by a DHCP relay agent in a Relay-forward 215 message to carry the client message to a server (section 20) 216 217 Server message: Sent by a DHCP server in a Relay-reply message to 218 carry a response message to the relay agent (section 20) 219 220 221 222 223Droms Expires October 5, 2003 [Page 4] 224 225Internet-Draft Stateless DHCPv6 Implementation Guide April 2003 226 227 228 Interface-ID: Sent by the DHCP relay agent and returned by the 229 server to identify the interface to use to forward a message to 230 the client (section 22.18) 231 232 233 5.3 Options used for configuration information 234 235 Clients and servers use the following options to pass 236 configuration information to clients: 237 238 DNS Recursive Name Servers: specifies the DNS recursive name 239 servers [6] the client uses for name resolution; see "DNS 240 Configuration options for DHCPv6" 241 242 DNS search list: specifies the domain names to be 243 searched during name resolution; see "DNS Configuration options 244 for DHCPv6" 245 246 NTP Servers: specifies the NTP servers the client 247 uses for synchronizing its clock; see "Time Configuration 248 Options for DHCPv6" 249 250 251 5.4 Other options used in stateless DHCP 252 253 Clients and servers may implement the following options for 254 stateless DHCP service; the section numbers in this list refer to 255 the DHCPv6 specification [1]: 256 257 Preference: Sent by a DHCP server to indicate the preference 258 level for the server (section 22.8) 259 260 Elapsed time: Sent by a DHCP client to indicate the time since 261 the client began the DHCP configuration process (section 22.9) 262 263 User Class: Sent by a DHCP client to give additional 264 information to the server for selecting configuration 265 parameters for the client (section 22.15) 266 267 Vendor Class: Sent by a DHCP client to give additional 268 information about the client vendor and hardware to the server 269 for selecting configuration parameters for the client (section 270 22.16) 271 272 Vendor-specific Information: Sent by a DHCP server to pass 273 information to clients in options defined by vendors (section 274 22.17) 275 276 277 278 279Droms Expires October 5, 2003 [Page 5] 280 281Internet-Draft Stateless DHCPv6 Implementation Guide April 2003 282 283 284 Client DUID: Sent by a DHCP client to identify itself (section 285 22.2). Clients are not required to send this option; servers 286 never send this option 287 288 Authentication: Used to provide authentication of DHCP messages 289 (section 21) 290 291 292 6. Interaction with DHCP for Address Assignment 293 294 In some networks, there may be both clients that are using 295 stateless address autoconfiguration [7] and DHCP for DNS 296 configuration and clients that are using DHCP for stateful address 297 configuration. Depending on the deployment and configuration of 298 relay agents, DHCP servers that are intended only for stateless 299 configuration may receive messages from clients that are 300 performing stateful address configuration. 301 302 A DHCP server that is only able to provide stateless configuration 303 information through an Information-request/Reply message exchange 304 discards any other DHCP messages it receives. Specifically, the 305 server discards any messages other than Information-Request or 306 Relay-forward it receives, and the server does not participate in 307 any stateful address configuration messages exchanges. If there 308 are other DHCP servers that are configured to provide stateful 309 address assignment, one of those servers will provide the address 310 assignment. 311 312 7. Security Considerations 313 314 Stateless DHCPv6 service is a proper subset of the DHCPv6 service 315 described in the DHCPv6 specification [1]. Therefore, stateless 316 DHCPv6 service introduces no additional security considerations 317 beyond those discussed in sections 21, 22.11 and 23 of the DHCPv6 318 specification. 319 320 Configuration information provided to a node through stateless 321 DHCPv6 service may be used to mount spoofing, man-in-the-middle, 322 denial-of-service and other attacks. These attacks are described 323 in more detail in the specifications for each of the options that 324 carry configuration information. Authenticated DHCPv6, as 325 described in sections 21 and 22.11 of the DHCPv6 specification, 326 can be used to avoid attacks mounted through the stateless DHCPv6 327 service. 328 329 Usually, a node using stateless DHCPv6 service will have 330 configured its interfaces with IPv6 addresses through stateless 331 address autoconfiguration. A node that has configured an 332 333 334 335Droms Expires October 5, 2003 [Page 6] 336 337Internet-Draft Stateless DHCPv6 Implementation Guide April 2003 338 339 340 appropriate IPv6 address can use IPsec [8] to authenticate and 341 secure DHCPv6 messages exchanged between the node and the DHCPv6 342 server. 343 344 8. Acknowledgments 345 346 Jim Bound, Ted Lemon and Bernie Volz reviewed this document and 347 contributed editorial suggestions. Thanks to Pekka Savola and 348 Christian Huitema for their review and comments. 349 350Normative References 351 352 [1] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and 353 R. Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 354 (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), 355 October 2002. 356 357 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 358 (IPv6) Specification", RFC 2460, December 1998. 359 360 [3] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and 361 R. Droms, "DNS Configuration options for DHCPv6", draft-ietf- 362 dhc-dhcpv6-opt-dnsconfig-01 (work in progress), October 2002. 363 364 [4] Vijayabhaskar, A., "Time Configuration Options for DHCPv6", 365 draft-ietf-dhc-dhcpv6-opt-timeconfig-00 (work in progress), 366 February 2002. 367 368Informative References 369 370 [5] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 371 for IP Version 6 (IPv6)", RFC 2461, December 1998. 372 373 [6] Mockapetris, P., "Domain names - concepts and facilities", 374 STD 13, RFC 1034, November 1987. 375 376 [7] Thomson, S. and T. Narten, "IPv6 Stateless Address 377 Autoconfiguration", RFC 2462, December 1998. 378 379 [8] Kent, S. and R. Atkinson, "Security Architecture for the 380 Internet Protocol", RFC 2401, November 1998. 381 382 383 384 385 386 387 388 389 390 391Droms Expires October 5, 2003 [Page 7] 392 393Internet-Draft Stateless DHCPv6 Implementation Guide April 2003 394 395 396Author's Address 397 398 Ralph Droms 399 Cisco Systems 400 300 Apollo Drive 401 Chelmsford, MA 01824 402 USA 403 404 Phone: +1 978 497 4733 405 EMail: rdroms@cisco.com 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447Droms Expires October 5, 2003 [Page 8] 448 449Internet-Draft Stateless DHCPv6 Implementation Guide April 2003 450 451 452Full Copyright Statement 453 454 Copyright (C) The Internet Society (2003). All Rights Reserved. 455 456 This document and translations of it may be copied and furnished 457 to others, and derivative works that comment on or otherwise 458 explain it or assist in its implementation may be prepared, 459 copied, published and distributed, in whole or in part, without 460 restriction of any kind, provided that the above copyright notice 461 and this paragraph are included on all such copies and derivative 462 works. However, this document itself may not be modified in any 463 way, such as by removing the copyright notice or references to the 464 Internet Society or other Internet organizations, except as needed 465 for the purpose of developing Internet standards in which case the 466 procedures for copyrights defined in the Internet Standards 467 process must be followed, or as required to translate it into 468 languages other than English. 469 470 The limited permissions granted above are perpetual and will not 471 be revoked by the Internet Society or its successors or assigns. 472 473 This document and the information contained herein is provided on 474 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 475 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 476 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 477 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 478 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 479 480Acknowledgement 481 482 Funding for the RFC Editor function is currently provided by the 483 Internet Society. 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503Droms Expires October 5, 2003 [Page 9] 504 505