idnits 2.17.1 draft-droms-dhcpv6-stateless-guide-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 24, 2002) is 7849 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) == Unused Reference: '6' is defined on line 283, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. '1') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-27 == Outdated reference: A later version (-04) exists of draft-ietf-dhc-dhcpv6-opt-dnsconfig-01 == Outdated reference: A later version (-03) exists of draft-ietf-dhc-dhcpv6-opt-timeconfig-00 ** Obsolete normative reference: RFC 2402 (ref. '6') (Obsoleted by RFC 4302, RFC 4305) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Droms 3 Internet-Draft Cisco Systems 4 Expires: April 24, 2003 October 24, 2002 6 A Guide to Implementing Stateless DHCPv6 Service 7 draft-droms-dhcpv6-stateless-guide-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on April 24, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 Stateless DHCPv6 service is used by hosts to obtain configuration 39 information such as the addresses of DNS servers that does not 40 require the maintenance of any dynamic state for individual clients. 41 A host that uses stateless DHCP must have obtained its IPv6 addresses 42 through some other mechanism, typically stateless address 43 autoconfiguration. This document is a guide to the protocol messages 44 and options that must be implemented to provide stateless DHCPv6 45 service. 47 1. Introduction 49 Hosts that have obtained IPv6 addresses through some other mechanism 50 can use stateless DHCPv6 to obtain other configuration information 51 such as a list of DNS server or NTP servers. A stateless DHCPv6 52 server provides only configuration information to hosts and does not 53 perform any address assignment. Such a server is called "stateless" 54 because it need not maintain any dynamic state for individual 55 clients. 57 While the DHCPv6 specification [3] defines more than 10 protocol 58 messages and 20 options, only a subset of those messages and options 59 are required for stateless DHCPv6 service. This document gives 60 guidelines about which messages and options are required for 61 stateless DHCPv6 service. The intended use of the document is to 62 guide the efficient and complete implementation of clients and 63 servers that use stateless DHCPv6 service. 65 The operation of relay agents is the same for stateless and stateful 66 DHCPv6 service. The operation of relay agents is described in the 67 DHCPv6 specification. 69 Section 4 of this document lists the sections of the DHCPv6 document 70 that an implementor should read for an overview of the DHCPv6 71 specification and the basic requirements of a DHCPv6 service. 72 Section 5 lists the specific messages and options that are 73 specifically required for stateless DHCPv6 service. Section 6 74 describes how stateless and stateful DHCPv6 servers interact to 75 provide service to clients that require address assignment and 76 clients that require only stateless service. 78 2. Terminology 80 Throughout this document, "DHCP" refers to DHCP for IPv6. 82 This document uses the terminology defined in RFC2460 [1], the DHCP 83 specification, the DHCP DNS configuration options specification [4] 84 and the DHCP NTP configuration options specification [5].. 86 "Stateless DHCP" refers to the use of DHCP to provide configuration 87 information to clients that does not require the server to maintain 88 dynamic state about the DHCP clients. 90 3. Overview 92 This document assumes that a host using stateless DHCP configuration 93 is not using DHCP for address assignment, and that a host has 94 determined at least a link-local address as described in section 5.3 95 of RFC2461 [2] 97 To obtain configuration parameters through stateless DHCP, a host 98 uses the DHCP Information-request message. DHCP servers respond to 99 the host's message with a Reply message that carries the DNS 100 configuration parameters. The Reply message from the server can 101 carry configuration information such as a list of DNS servers and NTP 102 servers. 104 4. Basic Requirements for Implementation of DHCP 106 Several sections of the DHCP specification [3] provide background 107 information or define parts of the specification that are common to 108 all implementations: 110 1-4 - give an introduction to DHCPv6 and an overview of DHCP 111 message flows 113 5 - defines constants used throughout the protocol specification 115 6, 7 - illustrates the format of DHCP messages 117 8 - describes the representation of Domain Names 119 9 - defines the "DHCP unique identifier" (DUID) used to identify 120 DHCP participants 122 13-16 - describe DHCP message transmission, retransmission and 123 validation 125 21 - describes authentication for DHCP 127 5. Implementation of stateless DHCP 129 The client indicates that it is requesting configuration information 130 by sending an Information-request message that includes an Option 131 Request option specifying the options that it wishes to receive from 132 the DHCP server. For example, if the client is attempting to obtain 133 DNS configuration information, it includes either or both of the DNS 134 configuration options in the Information-request message. The server 135 determines the appropriate configuration parameters for the client 136 based on its configuration policies and responds with a Reply message 137 containing the requested parameters. In this example, the server 138 would respond with DNS configuration parameters. 140 Use of the Client DUID option and the Server DUID option are not 141 required for stateless DHCP service. However, it can be beneficial 142 for the client to include a client DUID option, because the server 143 administrator may want to customize the server's response on a per- 144 client basis, and this requires that the client identify itself. 146 5.1 Messages required for stateless DHCP 148 Clients and servers implement the following messages for stateless 149 DHCP service; the section numbers in this list refer to the DHCPv6 150 specification: 152 Information-request: sent by a DHCP client to a server to request DNS 153 configuration parameters (sections 18.1.5 and 18.2.5) 155 Reply: sent by a DHCP server to a client containing the 156 DNS configuration parameters (sections 18.1.6 and 18.2.8) 158 In addition, servers and relay agents implement the following 159 messages for stateless DHCP service: 161 Relay-forward: Sent by a DHCP relay agent to carry the client message 162 to a server (section 15.13) 164 Relay-reply: Sent by a DHCP server to carry a response message to 165 the relay agent (section 15.14) 167 5.2 Options required for stateless DHCP service 169 Clients and servers implement the following options for stateless 170 DHCP service; the section numbers in this list refer to the DHCPv6 171 specification: 173 Option Request: specifies the configuration information that the 174 client is requesting from the server (section 22.7) 176 Status Code: used to indicate completion status or other status 177 information (section 22.13) 179 Servers and relay agents implement the following options for 180 stateless DHCP service; the section numbers in this list refer to the 181 DHCPv6 specification: 183 Client message: Sent by a DHCP relay agent in a Relay-forward message 184 to carry the client message to a server (section 20) 186 Server message: Sent by a DHCP server in a Relay-reply message to 187 carry a response message to the relay agent (section 20) 189 Interface-ID: Sent by the DHCP relay agent and returned by the 190 server to identify the interface to use to forward a message to 191 the client (section 22.18) 193 5.3 Options used for configuration information 195 Clients and servers use the following options to pass configuration 196 information to clients: 198 DNS Server: specifies the DNS servers the client uses for name 199 resolution; see "DNS Configuration options for DHCPv6" 201 DNS search list: specifies the domain names to be searched during 202 name resolution; see "DNS Configuration options for DHCPv6" 204 NTP Servers: specifies the NTP servers the client uses for 205 synchronizing its clock; see "Time Configuration Options for 206 DHCPv6" 208 5.4 Other options used in stateless DHCP 210 Clients and servers may implement the following options for stateless 211 DHCP service; the section numbers in this list refer to the DHCPv6 212 specification [3]: 214 Preference: Sent by a DHCP server to indicate the preference 215 level for the server (section 22.8) 217 Elapsed time: Sent by a DHCP client to indicate the time since the 218 client began the DHCP configuration process (section 22.9) 220 User Class: Sent by a DHCP client to give additional information 221 to the server for selecting configuration parameters for the 222 client (section 22.15) 224 Vendor Class: Sent by a DHCP client to give additional information 225 about the client vendor and hardware to the server for selecting 226 configuration parameters for the client (section 22.16) 228 Vendor-specific Information: Sent by a DHCP server to pass 229 information to clients in options defined by vendors (section 230 22.17) 232 Client DUID: Sent by a DHCP client to identify itself (section 233 22.2). Clients are not required to send this option; servers 234 never send this option 236 Authentication: Used to provide authentication of DHCP messages 237 (section 21) 239 6. Interaction with DHCP for Address Assignment 241 In some networks, there may be both clients that are using stateless 242 address autoconfiguration and DHCP for DNS configuration and clients 243 that are using DHCP for stateful address configuration. Depending on 244 the deployment and configuration of relay agents, DHCP servers that 245 are intended only for stateless configuration may receive messages 246 from clients that are performing stateful address configuration. 248 A DHCP server that is only able to provide stateless configuration 249 information through an Information-request/Reply message exchange 250 discards any other DHCP messages it receives. Specifically, the 251 server discards any messages other than Information-Request or Relay- 252 forward it receives, and the server does not participate in any 253 stateful address configuration messages exchanges. If there are 254 other DHCP servers that are configured to provide stateful address 255 assignment, one of those servers will provide the address assignment. 257 7. Acknowledgments 259 Ted Lemon, Bernie Volz and Jim Bound reviewed this document and 260 contributed editorial suggestions. 262 References 264 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 265 Specification", RFC 2460, December 1998. 267 [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 268 IP Version 6 (IPv6)", RFC 2461, December 1998. 270 [3] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. 271 Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 272 (DHCPv6)", draft-ietf-dhc-dhcpv6-27 (work in progress), October 273 2002. 275 [4] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. 276 Droms, "DNS Configuration options for DHCPv6", draft-ietf-dhc- 277 dhcpv6-opt-dnsconfig-01 (work in progress), October 2002. 279 [5] Vijayabhaskar, A., "Time Configuration Options for DHCPv6", 280 draft-ietf-dhc-dhcpv6-opt-timeconfig-00 (work in progress), 281 February 2002. 283 [6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 284 November 1998. 286 Author's Address 288 Ralph Droms 289 Cisco Systems 290 300 Apollo Drive 291 Chelmsford, MA 01824 292 USA 294 Phone: +1 978 497 4733 295 EMail: rdroms@cisco.com 297 Full Copyright Statement 299 Copyright (C) The Internet Society (2002). All Rights Reserved. 301 This document and translations of it may be copied and furnished to 302 others, and derivative works that comment on or otherwise explain it 303 or assist in its implementation may be prepared, copied, published 304 and distributed, in whole or in part, without restriction of any 305 kind, provided that the above copyright notice and this paragraph are 306 included on all such copies and derivative works. However, this 307 document itself may not be modified in any way, such as by removing 308 the copyright notice or references to the Internet Society or other 309 Internet organizations, except as needed for the purpose of 310 developing Internet standards in which case the procedures for 311 copyrights defined in the Internet Standards process must be 312 followed, or as required to translate it into languages other than 313 English. 315 The limited permissions granted above are perpetual and will not be 316 revoked by the Internet Society or its successors or assigns. 318 This document and the information contained herein is provided on an 319 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 320 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 321 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 322 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 323 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 325 Acknowledgement 327 Funding for the RFC Editor function is currently provided by the 328 Internet Society.