idnits 2.17.1 draft-ietf-dhc-dhcpv6-opt-netboot-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 451. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 464. 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 Copyright Line does not match the current year == Line 127 has weird spacing: '...pt-data toget...' -- 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 (November 18, 2008) is 5632 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) ** Downref: Normative reference to an Informational RFC: RFC 3617 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'VENDORIDS' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC T. Huth 3 Internet-Draft J. Freimann 4 Intended status: Standards Track IBM Deutschland Research & 5 Expires: May 22, 2009 Development GmbH 6 November 18, 2008 8 DHCPv6 option for network boot 9 draft-ietf-dhc-dhcpv6-opt-netboot-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 22, 2009. 36 Abstract 38 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a 39 framework for passing configuration information to nodes on a 40 network. This document describes a new option for DHCPv6 to convey 41 information, required for network booting, to the nodes. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Netboot option format . . . . . . . . . . . . . . . . . . . . 3 48 4. Suboptions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 4.1. Suboption: Boot file Uniform Resource Locator (URL) . . . 4 50 4.2. Suboption: Vendor class extension . . . . . . . . . . . . 6 51 5. Appearance of the Netboot option . . . . . . . . . . . . . . . 7 52 6. Boot protocol considerations . . . . . . . . . . . . . . . . . 8 53 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 54 8. Security considerations . . . . . . . . . . . . . . . . . . . 9 55 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 56 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 58 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 60 Intellectual Property and Copyright Statements . . . . . . . . . . 12 62 1. Introduction 64 Network booting means that a node which should be booted fetches the 65 files required for booting via its network device from a server. 66 Network booting is, for example, very useful in environments where 67 the administrators have to maintain a large number of nodes. Since 68 all boot and configuration files are stored on a central server, the 69 maintenance of all nodes can be kept simple this way. 71 A typical boot file would be, for example, an operating system kernel 72 or a boot loader program. To be able to download such a file, the 73 firmware (BIOS) running on the client node must be provided with 74 information such as: the server on which the boot files can be found, 75 the protocol to be used for the download (for example TFTP [RFC1350]) 76 and the name of the boot file. Since some kernels or boot loaders 77 need to be provided with additional parameters, there should also be 78 the possibility to pass additional parameters along with the server 79 address, the protocol and the file name. 81 DHCPv6 allows client nodes to ask a DHCPv6 server for configuration 82 parameters. Contrary to its IPv4 predecessor, DHCPv6 does not yet 83 define a way to query network boot options such as the IPv6 address 84 of a boot file server and boot file names. Therefore this document 85 defines a new DHCPv6 option which is required for network booting 86 clients. 88 2. Conventions 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 Terminology specific to IPv6 and DHCPv6 are used in the same way as 95 defined in the "Terminology" sections of RFC 3315 [RFC3315]. 97 3. Netboot option format 99 The netboot option is used as an encapsulation for suboptions which 100 carry the actual information needed to boot a client. This option 101 will be used by clients to request boot information from a server. 103 0 1 2 3 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | OPT_NET_BOOT | option-len | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | suboption-code 1 | suboption-len | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | subopt-data 1 (variable length) | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 . . 113 . . 114 . . 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | suboption-code n | suboption-len | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | subopt-data n (variable length) | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 option-code OPT_NET_BOOT (TBD1). 123 option-len Length of the netboot option in octets (not 124 including the size of the option-code and option- 125 len fields). 127 suboption-code, suboption-len and subopt-data together comprise a 128 suboption for the netboot option. The 16-bit 129 unsigned suboption-code values are drawn from a 130 private namespace of the netboot option managed by 131 IANA (cf. Section 8). The 16-bit unsigned 132 suboption-len values indicate the length of the 133 subopt-data field in octets. 135 Multiple occurences of each suboption-type can occur within a netboot 136 option (for example when more than one boot server is available). 137 Clients MUST process the suboptions in the order in which they appear 138 in the message sent by the server. 140 So far, only the suboptions in the following chapters have been 141 defined. Other suboptions might be defined in future RFCs. 143 4. Suboptions 145 4.1. Suboption: Boot file Uniform Resource Locator (URL) 147 This suboption consists of multiple ASCII strings. It is used to 148 convey an URL to a boot file together with additional parameters for 149 the boot file (e.g. parameters for the kernel or boot loader 150 program). 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | SUBOPT_BOOTFILE_URL | suboption-len | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | bootfile-len | bootfile-url | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable length) . 159 . | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | param-len 1 | parameter 1 | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable length) . 163 . | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 . . 166 . . 167 . . 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | param-len n | parameter n | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable length) . 171 . | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Format description: 176 suboption-code SUBOPT_BOOTFILE_URL (1). 178 suboption-len Length of the bootfile suboption in octets (not 179 including the size of the suboption-code and 180 suboption-len fields). 182 bootfile-len 16-bit integer that specifies the length of the 183 bootfile-url in octets (not including the bootfile- 184 length field). 186 bootfile-url This ASCII string is the URL (conforming to 187 [RFC3986]) for a boot file. This string starts 188 with the protocol which is used for downloading. 189 Separated by "://", the hostname or IPv6 address of 190 the server hosting the boot file (see also the note 191 below) follows, and then the path, file name and 192 query parts of the URL. The string is not null- 193 terminated. 195 param-len 1...n This is a 16-bit integer which specifies the length 196 of the following parameter in octets (not including 197 the parameter-length field). 199 parameters 1...n These ASCII strings are parameters needed for 200 booting, e.g. kernel parameters. The strings are 201 not null-terminated. The firmware should pass 202 these parameters in the order they appear in the 203 SUBOPT_BOOTFILE_URL suboption to the boot file 204 which has been specified in the bootfile-url field. 205 In cases where no parameters are needed, everything 206 but the boot file URL (including its length field) 207 can be omitted. 209 Note about the bootfile-url: This string can either contain a 210 hostname or a literal IPv6 address to specify the server where the 211 boot file should be downloaded from. All clients which implement the 212 SUBOPT_BOOTFILE_URL suboption MUST be able to handle IPv6 addresses 213 here and SHOULD also be able to handle a hostname in the URL. The 214 IPv6 address in the URL then MUST be enclosed in "[" and "]" 215 characters, conforming to [RFC3986]. Clients SHOULD also be able to 216 handle hostnames in the URLs. However, in this case the firmware 217 implementation on the client machine must support DNS, too. Due to 218 size limitations, this might not be possible in all firmware 219 implementations, so support for hostnames in the URLs is only 220 optional. 222 Since multiple occurrences of SUBOPT_BOOTFILE_URL can be present in a 223 single OPT_NETBOOT message, clients MUST process them in the order in 224 which they appear within the message. For example in the case of a 225 boot file URL the first file should be downloaded and executed. In 226 case of a failure the process should continue with the second one and 227 so on. 229 4.2. Suboption: Vendor class extension 231 With this suboption, vendors can define their own netboot suboptions: 232 It can be used by clients and servers to exchange vendor-specific 233 information which is related to network booting. 235 This suboption can occur multiple times within a OPT_NET_BOOT option 236 (also with different enterprise-numbers in case a server and client 237 implementation supports different vendor extensions). Clients MUST 238 process them in the order in which they appear within the message. 239 Unsupported vendor extensions MUST be ignored. 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | SUBOPT_NETBOOT_VENDOR | suboption-len | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | enterprise-number | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 . . 249 . vendor-class-data . 250 . (variable length) . 251 . . 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Format description: 256 suboption-code SUBOPT_NETBOOT_VENDOR (2). 258 suboption-len Length of the vendor class suboption in octets 259 (not including the size of the suboption-code and 260 suboption-len fields). 262 enterprise-number The enterprise number of the vendor as registered 263 with IANA (see [VENDORIDS]). 265 vendor-class-data Vendor-specific information. The meaning is 266 defined by the vendor identified by the 267 enterprise-number. It is suggested that the 268 vendor-class-data SHOULD be composed of a series 269 of separate items with a two-octets length field 270 at the beginning of each item, as it is described 271 for the vendor class option in chapter 22.16 of 272 [RFC3315]. 274 5. Appearance of the Netboot option 276 The netboot option MUST NOT appear in DHCPv6 messages other than the 277 types Solicit, Advertise, Request, Renew, Rebind, Information-Request 278 and Reply. 280 The option-code of the netboot option MAY appear in the Option 281 Request Option in the DHCPv6 message types Solicit, Request, Renew, 282 Rebind, Information-Request and Reconfigure. 284 The suboptions MUST appear only in the netboot option. 286 6. Boot protocol considerations 288 RFC 906 [RFC906] suggests to use TFTP for bootstrap loading. Because 289 it is easy to implement this protocol in firmware (where one has to 290 deal with size and complexity constraints), this is still the 291 recommended protocol for network booting. Every firmware 292 implementation SHOULD at least support this protocol. The boot file 293 URLs then must be specified according to RFC 3617 [RFC3617]. 295 An alternative approach to TFTP network booting is to bootstrap the 296 system with iSCSI. In this case, the URL in the SUBOPT_BOOTFILE_URL 297 suboption MUST be specified according to the "iscsi:" string 298 definition in chapter 5 of [RFC4173]. Note that [RFC4173] also 299 suggests that the "iscsi:" string should be specified in the so- 300 called "Root Path" option. However, this option does not exist for 301 DHCPv6 yet, and with the SUBOPT_BOOTFILE_URL it is also not necessary 302 anymore. So for IPv6 iSCSI booting, the "iscsi:" string MUST be 303 specified as URL in the SUBOPT_BOOTFILE_URL suboption instead. 305 In some different scenarios, it might also be useful to use other 306 protocols like FTP or HTTP for network booting, so a firmware 307 implementation can support these protocols, too. Then it is up to 308 the network administrator to choose the appropriate boot protocol for 309 the network, and to specify the right boot file URLs in the DHCPv6 310 server configuration file. 312 7. IANA considerations 314 The following option needs to be assigned by the IANA from the option 315 number space defined in the chapter 22 of the DHCPv6 RFC [RFC3315]. 317 +--------------+-------+--------------+ 318 | Option name | Value | Specified in | 319 +--------------+-------+--------------+ 320 | OPT_NET_BOOT | TBD1 | Section 3 | 321 +--------------+-------+--------------+ 323 The OPT_NET_BOOT option also defines a new 16-bit integer suboption 324 field, for which IANA is to create and maintain a new sub-registry 325 entitled "Netboot Suboptions" under the OPT_NET_BOOT option. Initial 326 values for the Netboot Suboptions registry are given below; future 327 assignments are to be made through IETF Review (see [RFC5226]). 328 Assignments consist of a suboption name and its associated value. 330 +-----------------------+-------+--------------+ 331 | Suboption name | Value | Specified in | 332 +-----------------------+-------+--------------+ 333 | SUBOPT_BOOTFILE_URL | 1 | Section 4.1 | 334 | SUBOPT_NETBOOT_VENDOR | 2 | Section 4.2 | 335 +-----------------------+-------+--------------+ 337 8. Security considerations 339 The new DHCPv6 option described in this document could be sent in 340 untrusted networks by malicious people with a fake DHCPv6 server to 341 confuse the booting clients. The clients could be provided with a 342 wrong URL so that the boot either fails, or even worse, the client 343 boots the wrong operating system which has been provided by a 344 malicious file server. To prevent this kind of attack, clients 345 SHOULD use authentication of DHCPv6 messages (see chapter 21. in RFC 346 3315 [RFC3315]). 348 Note also that DHCPv6 messages are sent unencrypted by default. So 349 the boot file URL options are sent unencrypted over the network, too. 350 This can become a security risk since the URLs can contain sensitive 351 information like user names and passwords (for example a URL like 352 "ftp://username:password@servername/path/file"). At the current 353 point in time, there is no possibility to send encrypted DHCPv6 354 messages, so it is strongly recommended not to use sensitive 355 information in the URLs in untrusted networks. 357 9. Acknowledgements 359 The authors would like to thank Ketan P. Pancholi and Alfred Hoenes 360 for corrections and suggestions. 362 Vijayabhaskar Kalusivalingam and Senthil Balasubramanian published a 363 similar draft for IPv6 network booting some years ago (available at 364 http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-opt-rboot-00), which 365 however was abandoned for unknown reasons. 367 10. References 369 10.1. Normative References 371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", BCP 14, RFC 2119, March 1997. 374 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 375 and M. Carney, "Dynamic Host Configuration Protocol for 376 IPv6 (DHCPv6)", RFC 3315, July 2003. 378 [RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and 379 Applicability Statement for the Trivial File Transfer 380 Protocol (TFTP)", RFC 3617, October 2003. 382 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 383 Resource Identifier (URI): Generic Syntax", STD 66, 384 RFC 3986, January 2005. 386 [RFC4173] Sarkar, P., Missimer, D., and C. Sapuntzakis, 387 "Bootstrapping Clients using the Internet Small Computer 388 System Interface (iSCSI) Protocol", RFC 4173, 389 September 2005. 391 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 392 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 393 May 2008. 395 [VENDORIDS] 396 IANA, "Private Enterprise Numbers", 397 . 399 10.2. Informative References 401 [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, 402 RFC 1350, July 1992. 404 [RFC906] Finlayson, R., "Bootstrap Loading using TFTP", RFC 906, 405 June 1984. 407 Authors' Addresses 409 Thomas H. Huth 410 IBM Deutschland Research & Development GmbH 411 Schoenaicher Strasse 220 412 Boeblingen 71032 413 Germany 415 Phone: +49-7031-16-2183 416 Email: thuth@de.ibm.com 417 Jens T. Freimann 418 IBM Deutschland Research & Development GmbH 419 Schoenaicher Strasse 220 420 Boeblingen 71032 421 Germany 423 Phone: +49-7031-16-1122 424 Email: jfrei@de.ibm.com 426 Full Copyright Statement 428 Copyright (C) The IETF Trust (2008). 430 This document is subject to the rights, licenses and restrictions 431 contained in BCP 78, and except as set forth therein, the authors 432 retain all their rights. 434 This document and the information contained herein are provided on an 435 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 436 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 437 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 438 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 439 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 440 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 442 Intellectual Property 444 The IETF takes no position regarding the validity or scope of any 445 Intellectual Property Rights or other rights that might be claimed to 446 pertain to the implementation or use of the technology described in 447 this document or the extent to which any license under such rights 448 might or might not be available; nor does it represent that it has 449 made any independent effort to identify any such rights. Information 450 on the procedures with respect to rights in RFC documents can be 451 found in BCP 78 and BCP 79. 453 Copies of IPR disclosures made to the IETF Secretariat and any 454 assurances of licenses to be made available, or the result of an 455 attempt made to obtain a general license or permission for the use of 456 such proprietary rights by implementers or users of this 457 specification can be obtained from the IETF on-line IPR repository at 458 http://www.ietf.org/ipr. 460 The IETF invites any interested party to bring to its attention any 461 copyrights, patents or patent applications, or other proprietary 462 rights that may cover technology that may be required to implement 463 this standard. Please address the information to the IETF at 464 ietf-ipr@ietf.org.