idnits 2.17.00 (12 Aug 2021) /tmp/idnits33389/draft-zimmer-dhc-dhcpv6-remote-boot-options-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 467. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 491. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 6) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The abstract seems to contain references ([RFC3315], [UEFI22], [RFC4173], [RFC2131], [PXE21]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (November 3, 2008) is 4940 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2132' is mentioned on line 183, but not defined == Missing Reference: 'RFC1350' is mentioned on line 99, but not defined == Missing Reference: 'RFC2396' is mentioned on line 140, but not defined ** Obsolete undefined reference: RFC 2396 (Obsoleted by RFC 3986) == Unused Reference: 'RFC4172' is defined on line 412, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Duplicate reference: RFC4174, mentioned in 'RFC4174', was also mentioned in 'RFC4172'. Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group November 3, 2008 3 Internet Draft Vincent Zimmer 4 Intended status: Informational Intel Corporation 5 Expires: May 2009 Dave Thaler 6 Microsoft 8 DHCPv6 Remote Boot Options 9 draft-zimmer-dhc-dhcpv6-remote-boot-options-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that 14 any applicable patent or other IPR claims of which he or she is 15 aware have been or will be disclosed, and any of which he or she 16 becomes aware will be disclosed, in accordance with Section 6 of 17 BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on May 3, 2009. 37 Abstract 39 This document describes a means by which to support network boot of a 40 bare-metal platform utilizing a pre-boot execution environment, such 41 as the Unified Extensible Firmware Interface [UEFI22]. The problem 42 being addressed is that the PXE [PXE21] and UEFI Specifications 43 [UEFI22] only describe how to ascertain boot configuration options 44 using DHCPv4 [RFC2131], not for DHCPv6 [RFC3315]. Similarly, iSCSI 45 boot [RFC4173] does not specify how to discover boot device 46 information in an DHCPv6 environment. This document will describe 47 how to ascertain this boot information in an IPv6 environment 48 utilizing options in the DHCPv6 hand-off [RFC3315]. 50 Table of Contents 52 1. Introduction...................................................2 53 2. DHCPv6 Options ................................................3 54 2.1. Root Path Option..........................................3 55 2.2. Next Server Address Option...............................45 56 2.3. Boot File Size Option....................................56 57 2.4. Client System Architecture Type Option...................56 58 2.5. Client Network Interface Identifier Option...............67 59 2.6. iSNS Option..............................................67 60 2.7. SLP Directory Agent Option................................8 61 2.8. SLP Service Scope Option.................................89 62 3. Security Considerations........................................9 63 4. IANA Considerations..........................................910 64 5. Acknowledgments...............................................10 65 6. References....................................................11 66 6.1. Normative References.....................................11 67 6.2. Informative References...................................12 69 1. Introduction 71 Many hosts today have the ability to boot an Operating System image 72 (or "boot file") that is located on a server in the network. To do 73 so, the host must begin with some functionality just sufficient to be 74 able to get on the network and retrieve the boot file. As indicated 75 in Figure 1, it is desirable to obtain from DHCP the information 76 needed to locate the boot file, so that by the time the host is able 77 to communicate on the network, it can immediately begin downloading 78 the boot file. 80 +------+ 81 _______________________\| DHCP | 82 / 1 Get boot file info /|Server| 83 +------+ +------+ 84 | Host | 85 +------+ +------+ 86 \_______________________\| File | 87 2 Download boot file /|Server| 88 +------+ 90 Figure 1: Network Boot Sequence 92 Two methods for downloading a boot file are specified today. 94 o iSCSI: [RFC2132] specifies a DHCPv4 option for retrieving boot file 95 information and [RFC4173] specifies how to download the boot 96 file. 98 o TFTP: [RFC2132] and [RFC4578] specify DHCPv4 options for retrieving 99 boot file information and [RFC1350] specifies how to download the 100 boot file. 102 The problem with both is that while the methods for downloading the 103 boot files can work over either IPv4 or IPv6, the boot file info can 104 only be obtained over DHCPv4. As a result, they do not support a 105 network that only provides IPv6, nor do they support IPv6-only 106 devices. To address this gap, this document specifies DHCPv6 107 options that provide parity with the DHCPv4 options. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2. DHCPv6 Options 115 2.1. Root Path Option 117 The Root Path option specifies the path-name that contains the 118 client's root disk. The path is formatted as a character string 119 consisting of characters from the NVT ASCII character set. 121 This option provides parity with the Root Path Option defined for 122 DHCPv4 in [RFC2132] section 3.19. 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | OPTION_ROOT_PATH | option-len | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 . . 130 . root-disk-pathname (variable length) . 131 . . 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 option-code OPTION_ROOT_PATH (TBD1). 136 option-len Length of Root Path Name in octets. 138 root-disk-pathname See below 140 This NULL-terminated ASCII string is the URL (conforming to [RFC2396]) to 141 a boot file. This string starts with the protocol which is used for downloading. 142 Separated by '://', the hostname or IPv6 address of the server hosting the boot 143 file (see also the note below), the path, file name and query parts of the URL 144 follow. For iSCSI, the format of the URL is specified in [RFC4173] section 5. 146 2.2. Next Server Address Option 148 This option conveys the address of the server to use in the next step of 149 the client's bootstrap process. A DHCP server may return its own 150 address in this option, if the server is prepared to supply the next 151 bootstrap service (e.g., delivery of an operating system executable 152 image). 154 This option provides parity with the siaddr field in DHCPv4. 156 The format of the option is: 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | OPTION_NEXT_SERVER_ADDRESS | option-len | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | | 164 | Next Server Address | 165 | | 166 | | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 option-code OPTION_NEXT_SERVER_ADDRESS (TBD3). 171 option-len 16 173 Next Server Address The IPv6 address or IPv4-mapped address of the 174 next server 176 2.3. Boot File Size Option 178 This option specifies the length in 512-octet blocks of the default 179 boot image for the client. The file length is specified as a 32-bit 180 integer. 182 This option provides parity with the Boot File Size Option defined 183 for DHCPv4 in [RFC2132] section 3.15. 185 The format of the option is: 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | OPTION_BOOT_FILE_SIZE | option-len | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | File Size | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 option-code OPTION_BOOT_FILE_SIZE (TBD4). 197 option-len 4 199 File Size The length in 512-octet blocks of the boot image for the 200 client. 202 2.4. Client System Architecture Type Option 204 This option provides parity with the Client System Architecture Type 205 Option defined for DHCPv4 in [RFC4578] section 2.1. 207 The format of the option is: 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | OPTION_CLIENT_ARCH_TYPE | option-len | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 . . 215 . Processor Architecture Type (variable length) . 216 . . 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 option-code OPTION_CLIENT_ARCH_TYPE (TBD5). 221 option-len See below. 223 Processor Architecture Type A list of one or more architecture 224 types, as specified in [RFC4578] 225 section 2.1. 227 2.5. Client Network Interface Identifier Option 229 The Client Network Interface Identifier option is sent by a DHCP 230 client to a DHCP server to provide information about its level of 231 Universal Network Device Interface (UNDI) support. 233 This option provides parity with the Client Network Interface 234 Identifier Option defined for DHCPv4 in [RFC4578] section 2.2. 236 The format of the option is: 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | OPTION_NII | option-len | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Type | Major | Minor | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 option-code OPTION_NII (TBD6). 248 option-len 3 250 Type As specified in [RFC4578] section 2.2. 252 Major 253 As specified in [RFC4578] section 2.2. 255 Minor 256 As specified in [RFC4578] section 2.2. 258 2.6. iSNS Option 260 As specified in [RFC4173] section 6, iSCSI boot requires either iSNS 261 or SLP support. 263 This option provides parity with the iSNS Option defined for DHCPv4 264 in [RFC4174] section 2. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | OPTION ISNS | option-len | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | iSNS Functions | Reserved | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | DD Access | Administrative FLAGS | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | iSNS Server Security Bitmap | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | | 278 | Address A | 279 | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | | 282 | Address B | 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | . . . . | 286 | Additional Secondary iSNS Servers | 287 | . . . . | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 option-code OPTION_ISNS (TBD7) 292 option-len 2 294 iSNS Functions As specified in [RFC4174] section 2. 296 Reserved MUST be set to zero 298 DD Access As specified in [RFC4174] section 2. 300 Administrative FLAGS As specified in [RFC4174] section 2. 302 iSNS Server Security Bitmap 303 As specified in [RFC4174] section 2. 305 Address A As specified in [RFC4174] section 2, 306 except that it contains an IPv6 address. 308 Address B As specified in [RFC4174] section 2, 309 except that it contains an IPv6 address. 311 Additional Secondary iSNS Servers 312 As specified in [RFC4174] section 2, 313 except that it contains IPv6 addresses. 315 2.7. SLP Directory Agent Option 317 As specified in [RFC4173] section 6, iSCSI boot requires either iSNS 318 or SLP support. 320 This option provides parity with the SLP Directory Agent Option 321 defined for DHCPv4 in [RFC2610] section 3. 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | OPTION SLP | option-len | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Mandatory | Reserved | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 . . 331 . Address List (variable) . 332 . . 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 2.8. SLP Service Scope Option 337 As specified in [RFC4173] section 6, iSCSI boot requires either iSNS 338 or SLP support. 340 This option provides parity with the SLP Directory Agent Option 341 defined for DHCPv4 in [RFC2610] section 4. 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | OPTION SLP SERVICE | option-len | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Mandatory | Scope List (variable) | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 option-code OPTION_SLP_SERVICE (TBD8) 353 option-len 2 355 Scope List As specified in [RFC2610] section 4 357 3. Security Considerations 359 If an adversary manages to modify the response from a DHCP server or 360 insert its own response, a host could be led to contact a rogue file 361 server, resulting in an attacker being able to run arbitrary code on 362 the host. Consequently, a practical way to verify loaded boot images 363 is to make sure that each host verifies the boot file to be executed 364 using a mechanism of their choice. 366 In addition, some options contain information about a client's system 367 architecture and may be of use to potential attackers. 369 See the security considerations in [RFC3315], [RFC4173], and 370 [RFC4578] for more discussion. This document introduces no new 371 concerns beyond the ones covered therein for IPv4. 373 4. IANA Considerations 375 This document introduces a new IANA registry for processor 376 architecture types. The name of this registry shall be "Processor 377 Architecture Type". Registry entries consist of a 16-bit integer 378 recorded in decimal format, and a descriptive name. The initial 379 values of this registry can be found in [RFC4578] section 2.1. 381 The assignment policy for values shall be Expert Review, and any 382 requests for values must supply the descriptive name for the 383 processor architecture type. 385 5. Acknowledgments 387 The authors would like to thank Ruth Li, Dong Wei, Kathryn Hampton, 388 Phil Dorah, Richard Chan, and Fiona Jensen for discussions that led 389 to this document. 391 6. References 393 6.1. Normative References 395 [PXE21] Henry, M. and M. Johnston, "Preboot Execution Environment 396 (PXE) Specification", September 1999, 397 http://www.pix.net/software/pxeboot/archive/pxespec.pdf 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, March 1997. 402 [RFC2131] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, 403 March, 1997. 405 [RFC2610] C. Perkins, E. Guttman, "DHCP Options for Service Location 406 Protocol," RFC2610, June 1999. 408 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and 409 Carney, M., "Dynamic Host Configuration Protocol for IPv6 410 (DHCPv6)," RFC 3315, July 2003. 412 [RFC4172] Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic 413 Host Configuration Protocol (DHCP) Option for the 414 Internet Storage Name Service", RFC 4174, September 2005. 416 [RFC4173] Sarkar, P., Missimer, D. and Sapuntzakis, C., 417 "Bootstrapping Clients using the Internet Small Computer 418 System Interface (iSCSI) Protocol," RFC 4173, September 419 2005. 421 [RFC4174] Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic 422 Host Configuration Protocol (DHCP) Option for the Internet 423 Storage Name Service", RFC 4174, September 2005. 425 [RFC4578] Johnston, M. and Venaas, S. "Dynamic Host Configuration 426 Protocol (DHCP) Options for the Intel Preboot eXecution 427 Environment (PXE)", RFC 4578, November 2006. 429 [UEFI22] Unified Extensible Firmware Interface Specification, 430 Version 2.2, September 2008, http://www.uefi.org 432 6.2. Informative References 434 Author's Addresses 436 Vincent Zimmer 437 Intel 438 DP2-420 439 2800 Center Drive 440 DuPont, WA 98327 442 Phone: +1 253 371 5667 443 Email: vincent.zimmer@intel.com 445 Dave Thaler 446 Microsoft 447 One Microsoft Way 448 Redmond, WA 98052 450 Phone: +1 425 703-8835 451 Email: dthaler@microsoft.com 453 Full Copyright Statement 455 Copyright (C) The IETF Trust (2008). 457 This document is subject to the rights, licenses and restrictions 458 contained in BCP 78, and except as set forth therein, the authors 459 retain all their rights. 461 This document and the information contained herein are provided on an 462 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 463 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 464 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 465 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 466 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 467 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 469 Intellectual Property Statement 471 The IETF takes no position regarding the validity or scope of any 472 Intellectual Property Rights or other rights that might be claimed to 473 pertain to the implementation or use of the technology described in 474 this document or the extent to which any license under such rights 475 might or might not be available; nor does it represent that it has 476 made any independent effort to identify any such rights. Information 477 on the procedures with respect to rights in RFC documents can be 478 found in BCP 78 and BCP 79. 480 Copies of IPR disclosures made to the IETF Secretariat and any 481 assurances of licenses to be made available, or the result of an 482 attempt made to obtain a general license or permission for the use of 483 such proprietary rights by implementers or users of this 484 specification can be obtained from the IETF on-line IPR repository at 485 http://www.ietf.org/ipr. 487 The IETF invites any interested party to bring to its attention any 488 copyrights, patents or patent applications, or other proprietary 489 rights that may cover technology that may be required to implement 490 this standard. Please address the information to the IETF at 491 ietf-ipr@ietf.org.