idnits 2.17.1 draft-ietf-dhc-dhcpv6-opt-netboot-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 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 (August 10, 2009) is 5374 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'PXE21' ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 4578 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'UEFI22' -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 6 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 Germany Research & 5 Expires: February 11, 2010 Development GmbH 6 V. Zimmer 7 Intel 8 D. Thaler 9 Microsoft 10 August 10, 2009 12 DHCPv6 option for network boot 13 draft-ietf-dhc-dhcpv6-opt-netboot-05 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on February 11, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a 52 framework for passing configuration information to nodes on a 53 network. This document describes new options for DHCPv6 which are 54 required for booting a node from the network. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Boot File Uniform Resource Locator (URL) Option . . . . . 4 62 3.2. Boot File Parameters Option . . . . . . . . . . . . . . . 5 63 3.3. Client System Architecture Type Option . . . . . . . . . . 6 64 3.4. Client Network Interface Identifier Option . . . . . . . . 7 65 4. Appearance of the options . . . . . . . . . . . . . . . . . . 8 66 5. Download protocol considerations . . . . . . . . . . . . . . . 8 67 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 68 7. Security considerations . . . . . . . . . . . . . . . . . . . 9 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 This draft describes DHCPv6 options that can be used to provide 78 configuration information for a node that must be booted using the 79 network, rather than from local storage. 81 Network booting is used, for example, in some environments where 82 administrators have to maintain a large number of nodes. By serving 83 all boot and configuration files from central server, the effort 84 required to maintain these nodes is greatly reduced. 86 A typical boot file would be, for example, an operating system kernel 87 or a boot loader program. To be able to execute such a file, the 88 firmware (BIOS) running on the client node must perform the following 89 two steps (see Figure 1): First get all information which is required 90 for downloading and executing the boot file. Second, download the 91 boot file and execute it. 93 +------+ 94 _______________________\| DHCP | 95 / 1 Get boot file info /|Server| 96 +------+ +------+ 97 | Host | 98 +------+ +------+ 99 \_______________________\| File | 100 2 Download boot file /|Server| 101 +------+ 103 Figure 1: Network Boot Sequence 105 Information that is required for booting over the network can include 106 information about the server on which the boot files can be found, 107 the protocol to be used for the download (for example HTTP [RFC2616] 108 or TFTP [RFC1350]), the name of the boot file and additional 109 parameters which should be passed to the OS kernel or boot loader 110 program respectively. 112 DHCPv6 allows client nodes to ask a DHCPv6 server for configuration 113 parameters. This document provides new options which a client can 114 request from the DHCPv6 server to satisfy its requirements for 115 booting. 117 2. Conventions 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 Terminology specific to IPv6 and DHCPv6 are used in the same way as 124 defined in the "Terminology" sections of RFC 3315 [RFC3315]. 126 3. Options 128 Option formats comply with DHCPv6 options per [RFC3315] (section 6). 130 3.1. Boot File Uniform Resource Locator (URL) Option 132 This option consists of an US-ASCII string. It is used to convey an 133 URL to a boot file. 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | OPT_BOOTFILE_URL | option-len | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | precedence | bootfile-url | 141 +-+-+-+-+-+-+-+-+ (variable length) . 142 . | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Format description: 147 option-code OPT_BOOTFILE_URL (TBD1). 149 option-len Length of the bootfile URL option in octets (not 150 including the size of the option-code and option- 151 len fields). 153 precedence A single unsigned octet indicating the order in 154 which this URL should be processed, if more than 155 one URL appears in the message. 157 bootfile-url This US-ASCII string is the URL for the boot file, 158 as defined in [RFC3986]. The string is not NUL- 159 terminated. 161 The node identifier in the URL must be reachable using IPv6. If the 162 URL is expressed using an IPv6 address rather than a domain name, the 163 address in the URL then MUST be enclosed in "[" and "]" characters, 164 conforming to [RFC3986]. Clients that have DNS implementations 165 should support the use of domain names in the URL. 167 Multiple occurrences of OPT_BOOTFILE_URL MAY be present in a single 168 DHCP message. Clients MUST process them according to the value of 169 the precedence field - the lowest precedence should be processed 170 first. If this fails, then the second-lowest should be used, and so 171 on. 173 Servers SHOULD NOT send two Bootfile URL options with the same 174 precedence. Clients receiving more than one OPT_BOOTFILE_URL option 175 with the same precedence SHOULD discard any extra such options. The 176 order in which the client processes options is not specified, and 177 therefore server implementations cannot assume that the client will 178 discard a particular such option. 180 The value of the precedence field MUST NOT be zero. 182 3.2. Boot File Parameters Option 184 This option consists of multiple US-ASCII strings. They are used to 185 specify parameters for the boot file (e.g. parameters for the kernel 186 or boot loader program). 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | OPT_BOOTFILE_PARAM | option-len | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | precedence | param-len 1 | parameter 1 | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable . 195 . length) | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 . . 198 . . 199 . . 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | param-len n | parameter n | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable length) . 203 . | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Format description: 208 option-code OPT_BOOTFILE_PARAM (TBD2). 210 option-len Length of the bootfile parameters option in octets 211 (not including the size of the option-code and 212 option-len fields). 214 precedence A one-octet quantity indicating the bootfile-url 215 option to which this set of parameters applies. 217 param-len 1...n This is a 16-bit integer which specifies the length 218 of the following parameter in octets (not including 219 the parameter-length field). 221 parameters 1...n These US-ASCII strings are parameters needed for 222 booting, e.g. kernel parameters. The strings are 223 not NUL-terminated. 225 The firmware MUST pass these parameters in the order they appear in 226 the OPT_BOOTFILE_PARAM option to the boot file which has been 227 specified in the OPT_BOOTFILE_URL option. 229 Multiple occurrences of OPT_BOOTFILE_PARAM MAY be present in a single 230 DHCP message. Clients MUST process them according to the value of 231 the precedence field: 233 o If the precedence field of the Bootfile Parameters option is zero, 234 the client SHOULD provide these parameters when it attempts to 235 execute any Bootfile it has loaded using any of the provided 236 Bootfile URL options. 238 o If the precedence field of the Bootfile Parameters option is 239 nonzero, the client SHOULD provide these parameters only when it 240 attempts to execute a Bootfile it loaded using a Bootfile URL 241 option with a precedence field that has the same value. 243 o In the event that the client receives both a Bootfile Parameters 244 option with a precedence field of zero and one with a precedence 245 field that matches a certain Bootfile URL option, the client MUST 246 use the Bootfile Parameters option whose predence matches the 247 precedence of the Bootfile URL option. 249 3.3. Client System Architecture Type Option 251 This option provides parity with the Client System Architecture Type 252 Option defined for DHCPv4 in [RFC4578] section 2.1. 254 The format of the option is: 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | OPTION_CLIENT_ARCH_TYPE | option-len | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 . . 262 . Architecture Type (variable length) . 263 . . 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 option-code OPTION_CLIENT_ARCH_TYPE (TBD3). 268 option-len Length of the "processor architecture type" field 269 in octets (not including the option-code and 270 option-len fields). It MUST be an even number 271 greater than zero. See [RFC4578] section 2.1 for 272 details. 274 Architecture Type A list of one or more architecture types, as 275 specified in [RFC4578] section 2.1. 277 3.4. Client Network Interface Identifier Option 279 The Client Network Interface Identifier option is sent by a DHCP 280 client to a DHCP server to provide information about its level of 281 Universal Network Device Interface (UNDI) support (see also [PXE21] 282 and [UEFI22]). 284 This option provides parity with the Client Network Interface 285 Identifier Option defined for DHCPv4 in [RFC4578] section 2.2. 287 The format of the option is: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | OPTION_NII | option-len | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Type | Major | Minor | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 option-code OPTION_NII (TBD4). 299 option-len 3 300 Type As specified in [RFC4578] section 2.2. 302 Major As specified in [RFC4578] section 2.2. 304 Minor As specified in [RFC4578] section 2.2. 306 4. Appearance of the options 308 These options MUST NOT appear in DHCPv6 messages other than the types 309 Solicit, Advertise, Request, Renew, Rebind, Information-Request and 310 Reply. 312 The option-codes of these options MAY appear in the Option Request 313 Option in the DHCPv6 message types Solicit, Request, Renew, Rebind, 314 Information-Request and Reconfigure. 316 5. Download protocol considerations 318 The Bootfile URL option does not place any constraints on the 319 protocol used for downloading the Bootfile, other than that it must 320 be possible to specify it in a URL. For the sake of administrative 321 simplicity, we strongly recommend that, at a mininum, implementors of 322 network boot loaders implement the well-known and established 323 hypertext transfer protocol (HTTP, see [RFC2616]) for downloading. 324 Please note that for IPv6, this supersedes [RFC906] which recommended 325 to use TFTP for downloading (see [RFC3617] for TFTP URL definition). 327 When using iSCSI for booting, the "iscsi:"-URI is formed as defined 328 in [RFC4173]. The functionality attributed in RFC4173 to a root path 329 option is provided for IPv6 by the bootfile URL option instead. 331 6. IANA considerations 333 The following options need to be assigned by the IANA from the option 334 number space defined in the chapter 22 of the DHCPv6 RFC [RFC3315]. 336 +-------------------------+-------+--------------+ 337 | Option name | Value | Specified in | 338 +-------------------------+-------+--------------+ 339 | OPT_BOOTFILE_URL | TBD1 | Section 3.1 | 340 | OPT_BOOTFILE_PARAM | TBD2 | Section 3.2 | 341 | OPTION_CLIENT_ARCH_TYPE | TBD3 | Section 3.3 | 342 | OPTION_NII | TBD4 | Section 3.4 | 343 +-------------------------+-------+--------------+ 345 This document also introduces a new IANA registry for processor 346 architecture types. The name of this registry shall be "Processor 347 Architecture Type". Registry entries consist of a 16-bit integer 348 recorded in decimal format, and a descriptive name. The initial 349 values of this registry can be found in [RFC4578] section 2.1. 351 The assignment policy for values shall be Expert Review (see 352 [RFC5226]), and any requests for values must supply the descriptive 353 name for the processor architecture type. 355 7. Security considerations 357 In untrusted networks, a rogue DHCPv6 server could send the new 358 DHCPv6 options described in this document. The booting clients could 359 then be provided with a wrong URL so that the boot either fails, or 360 even worse, the client boots the wrong operating system which has 361 been provided by a malicious file server. To prevent this kind of 362 attack, clients can use authentication of DHCPv6 messages (see 363 chapter 21. in [RFC3315]). 365 Note also that DHCPv6 messages are sent unencrypted by default. So 366 the boot file URL options are sent unencrypted over the network, too. 367 This can become a security risk since the URLs can contain sensitive 368 information like user names and passwords (for example a URL like 369 "ftp://username:password@servername/path/file"). At the current 370 point in time, there is no possibility to send encrypted DHCPv6 371 messages, so it is strongly recommended not to use sensitive 372 information in the URLs in untrusted networks. 374 Even if the DHCPv6 transaction is secured, this does not protect 375 against attacks on the bootfile download channel. Consequently, we 376 recommend that either a protocol like HTTPS (see [RFC2817] and 377 [RFC2818]) be used to prevent spoofing, or that the boot loader 378 implementation implement a mechanism for signing boot images and a 379 configurable signing key in memory, so that if a malicious image is 380 provided, it can be detected and rejected. 382 8. Acknowledgements 384 The authors would like to thank Ruth Li, Dong Wei, Kathryn Hampton, 385 Phil Dorah, Richard Chan, and Fiona Jensen for discussions that led 386 to this document. 388 The authors would also like to thank Ketan P. Pancholi, Alfred 389 Hoenes, Gabriel Montenegro and Ted Lemon for corrections and 390 suggestions. 392 9. References 394 9.1. Normative References 396 [PXE21] Johnston, M., "Preboot Execution Environment (PXE) 397 Specification", September 1999, 398 . 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, March 1997. 403 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 404 and M. Carney, "Dynamic Host Configuration Protocol for 405 IPv6 (DHCPv6)", RFC 3315, July 2003. 407 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 408 Resource Identifier (URI): Generic Syntax", STD 66, 409 RFC 3986, January 2005. 411 [RFC4173] Sarkar, P., Missimer, D., and C. Sapuntzakis, 412 "Bootstrapping Clients using the Internet Small Computer 413 System Interface (iSCSI) Protocol", RFC 4173, 414 September 2005. 416 [RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration 417 Protocol (DHCP) Options for the Intel Preboot eXecution 418 Environment (PXE)", RFC 4578, November 2006. 420 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 421 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 422 May 2008. 424 [UEFI22] UEFI Forum, "Unified Extensible Firmware Interface 425 Specification, Version 2.2", September 2008, 426 . 428 9.2. Informative References 430 [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, 431 RFC 1350, July 1992. 433 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 434 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 435 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 437 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 438 HTTP/1.1", RFC 2817, May 2000. 440 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 442 [RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and 443 Applicability Statement for the Trivial File Transfer 444 Protocol (TFTP)", RFC 3617, October 2003. 446 [RFC906] Finlayson, R., "Bootstrap Loading using TFTP", RFC 906, 447 June 1984. 449 Authors' Addresses 451 Thomas H. Huth 452 IBM Germany Research & Development GmbH 453 Schoenaicher Strasse 220 454 Boeblingen 71032 455 Germany 457 Phone: +49-7031-16-2183 458 Email: thuth@de.ibm.com 460 Jens T. Freimann 461 IBM Germany Research & Development GmbH 462 Schoenaicher Strasse 220 463 Boeblingen 71032 464 Germany 466 Phone: +49-7031-16-1122 467 Email: jfrei@de.ibm.com 469 Vincent Zimmer 470 Intel 471 2800 Center Drive 472 DuPont WA 98327 473 USA 475 Phone: +1 253 371 5667 476 Email: vincent.zimmer@intel.com 477 Dave Thaler 478 Microsoft 479 One Microsoft Way 480 Redmond WA 98052 481 USA 483 Phone: +1 425 703-8835 484 Email: dthaler@microsoft.com