idnits 2.17.1 draft-henry-remote-boot-protocol-00.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == Mismatching filename: the document gives the document name as 'draft-viswanathan-remote-boot-protocol-01', but the file name used is 'draft-henry-remote-boot-protocol-00' == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** There are 60 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 311 has weird spacing: '.... It is a...' == Line 323 has weird spacing: '...str-len descr...' == Line 337 has weird spacing: '...e Len timeo...' == Line 409 has weird spacing: '... in along w...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 3.4.1.1.1. Multicast transfer already in progress If the client receives a response packet within the MTFTP_TRANSMISSION_START_DELAY period, then a multicast transfer is already in progress. The client starts receiving the packets and stores them in an internal list (or uses some other mechanism to keep track of the received packets). As this client is not the one to initiate the original transfer, it MUST not send a TFTP ACK packet to any of the received packets. When the file transfer finishes (this happens when the TFTP server sends the last block of data of the file), the client would only have received the ending portion of the file. All the beginning blocks of the file were missed by this client, when it joined a multicast transfer which was in progress already. We will discuss how to receive the rest of the file in the section under "mTFTP Receive". == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (Jun 24, 1999) is 9073 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) -- Missing reference section? '1' on line 697 looks like a reference -- Missing reference section? '2' on line 699 looks like a reference -- Missing reference section? '6' on line 707 looks like a reference -- Missing reference section? '7' on line 711 looks like a reference -- Missing reference section? '9' on line 715 looks like a reference -- Missing reference section? '3' on line 701 looks like a reference -- Missing reference section? '4' on line 703 looks like a reference -- Missing reference section? '5' on line 705 looks like a reference -- Missing reference section? '8' on line 713 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT M. Henry, Intel Corp., Editor 2 D. Koeppen, Bootix Tech. GmbH 3 E. Dittert, Intel Corp. 4 Obsoletes: V. Viswanathan, Intel Corp. 5 Jun 24, 1999 6 Expires December, 1999 8 Intel Preboot Execution Environment 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or made obsolete by other documents at 22 any time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This memo describes the Intel PXE (Preboot Execution Environment) 34 remote boot definition (which is part of Intel's Wired for Management 35 initiative), and provides the rationale for proposing an extended 36 remote boot capability beyond what is currently specified in DHCP. 38 < draft-henry-remote-boot-protocol-01.txt > June 24, 1999 40 Table of Contents 42 1. RATIONALE FOR AN EXTENDED REMOTE BOOT CAPABILITY 2 43 2. TERMINOLOGY 3 44 3. PXE REMOTE BOOT 3 45 3.1. Use of DHCP 3 46 3.1.1 DHCPDISCOVER 3 47 3.1.2 DHCPOFFER 4 48 3.2. PXE Use of DHCP Options 4 49 3.2.1 PXE Class Identifier - Option 60 4 50 3.2.2 PXE Client Identifier (UUID) - Option 61 4 51 3.2.3 PXE Vendor specific information - Option 43 5 52 3.3. Remote Boot Configuration Protocol (RBCP) 7 53 3.3.1 Bootserver Discovery 8 54 3.3.2 Bootserver Response 9 55 3.4. Remote Boot Multicast TFTP (mTFTP) 11 56 3.4.1 Multicast Trivial File Transfer Protocol Details 12 57 3.5. Boot Integrity Services (BIS) 14 58 3.5.1 NBP Authentication Request 14 59 3.5.2 NBP Authentication Response 14 60 3.5.3 NBP Credentials Delivery to Booting Client 14 61 4. SECURITY 15 62 5. REFERENCES: 15 63 6. AUTHORS' ADDRESSES 16 65 1. Rationale for an Extended Remote Boot Capability 67 Internet Protocol provides for a remote boot capability through use of 68 DHCP [1]and TFTP [2]. DHCP provides the booting client with a 69 "bootfile" name and the IP address of a TFTP server, from which the 70 client downloads the bootfile. Depending on the capabilities of the 71 DHCP service, the network administrator may program the DHCP service 72 to determine the bootfile name to provide to the booting client based 73 on information presented by the client during the DHCP cycle. 75 While this mechanism is simple and powerful, we believe it could 76 usefully be extended. Specifically: 78 1. Extension of the canonical list of client information (presented to 79 the DHCP service) to include client instruction set architecture, 80 network interface type, etc., would be useful in many cases, as 81 would a well defined means to extend this list. Certainly this 82 information can be defined and included in the client on a case by 83 case basis, and the DHCP service can be specifically configured to 84 recognize and use the information. And certainly the format for 85 transmitting this information from client to DHCP service is 86 defined (option 60 and perhaps option 43). However the content is 87 ad hoc by definition, and in the case of option 60, the format of 88 the content is ad hoc if the content is divided into fields. 90 < draft-henry-remote-boot-protocol-01.txt > June 24, 1999 92 2. It would be useful to have a standard mechanism to expand the 93 number of bootfile sources presented to the client beyond the 94 single TFTP server defined in the DHCP response. Going beyond 95 this, it is desirable in some cases to provide the client with a 96 list of available proprietary and commercial bootservers. 98 3. If the booting client is redirected through the "siaddr" field to a 99 remote tftp service (bootserver), there is no standard method of 100 providing a redundant service. (Certainly, if the tftp service to 101 be used is on the DHCP server then presumably any DHCP redundancy 102 mechanism would apply to the tftp service.) Related to #2 above, 103 there is no method of providing redundancy across a pool of 104 heterogeneous bootservers. As the number of clients affected can 105 be quite large if the bootserver selected is unavailable, it is 106 critical to define a redundancy mechanism. 108 4. When simultaneously booting many (e.g. 100s or 1000s) of identical 109 clients it would be desirable to use a multicast TFTP. The current 110 specifications are silent on the subject of how the client obtains 111 the bootfile. However, the lowest common denominator assumed to be 112 available by commercial IP boot ROMs is TFTP. 114 5. It would be useful for the booting client to have the means to 115 verify the integrity and source of the bootfile. 117 It is the goal of PXE to address these limitations and define a remote 118 boot capability robust enough to allow a heterogeneous set of clients 119 to be selectively configured for remote boot via DHCP, and 120 subsequently to be supported by a heterogeneous set of boot servers. 121 Behaviorally, the goal is that a blank, unconfigured, compliant system 122 can be removed from it's shipping carton, plugged into the network, 123 and upon power on (with no other configuration) find an appropriate 124 bootserver. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119. 132 3. PXE Remote Boot 134 The PXE specification defines a complete remote boot mechanism, 135 including the DHCP configuration of the PXE client necessary for the 136 PXE client to use three new protocols to complete the remote boot. 137 These new protocols are described in this memo. 139 < draft-henry-remote-boot-protocol-01.txt > June 24, 1999 141 The three new protocols are: Remote Boot Configuration Protocol 142 (RBCP), remote boot multicast TFTP (mTFTP), and Boot Integrity 143 Services (BIS). RBCP is used by the PXE client to discover an 144 appropriate boot service. The boot service provides the client with a 145 bootfile name (the PXE client does not necessarily receive its 146 bootfile name from the DHCP service), and it provides the client with 147 any configuration necessary for the client to download the bootfile 148 via either TFTP or mTFTP. The PXE client (optionally) uses BIS to 149 authenticate the bootfile. 151 In addition, PXE defines a proxy DHCP specifically for PXE clients. 152 The proxy is used as an optional means to provide the initial DHCP 153 configuration of PXE clients in the absence of a DHCP service capable 154 of interpreting and/or responding to PXE client specific configuration 155 requests. By definition, the proxy will only respond to PXE clients. 156 The proxy may reside on the same server as the DHCP service or may 157 reside on a separate server. Details of proxy usage are beyond the 158 scope of this document. 160 3.1. Use of DHCP 162 3.1.1 DHCPDISCOVER 164 The PXE client's DHCPDISCOVER packet MUST include: 166 o Client Machine Identifier - UUID (DHCP Option#61). 167 o PXE Client Class Identifier (DHCP option #60 - 168 "PXEClient:Arch:xxxxx:UNDI:yyyzzz") 169 o Parameter Request List (DHCP Option #9). List MUST include at least 170 subnet(1), router(3), vendor(43), class(60) 172 3.1.2 DHCPOFFER 173 The DHCPOFFER includes encapsulated PXEW client vendor options in 174 Option $43 that provide: 176 o A ASCII list of available bootservers. The client MAY display this 177 list to the user and let the user select the bootserver of their 178 choice. 179 o A header prompt for the ASCII bootserver list that the client MUST 180 display to the user if the bootserver list is displayed. 181 o A timeout value in seconds for user to request the bootserver list 182 to be displayed. The client MUST wait for this timeout period 183 before the default bootserver is discovered. 184 o A list of bootserver types and their IP addresses. (IP address are 185 only useful if unicast discovery is enabled.) 186 o An option that specifies whether bootservers are to be discovered 187 by a broadcast, multicast or a unicast discovery method. 188 o A multicast discovery address that the client MAY use to locate the 189 bootserver if the multicast discovery option is enabled through the 190 previous option. 192 < draft-henry-remote-boot-protocol-01.txt > June 24, 1999 194 At this time, the PXE client may receive DHCPOFFER messages from 195 several DHCP servers. However, the PXE client MUST give preference to 196 offers whose replies contain option tag 60 ("PXEClient"). 198 3.2. PXE Use of DHCP Options 200 3.2.1 PXE Class Identifier - Option 60 201 This option identifies PXE clients. This option also identifies the 202 client system's architecture and the version of the Universal Network 203 Driver Interface (UNDI) provided by the client. 204 The code for this option is 60 and its length is 32 octets long. 205 This option is of the form 207 "PXEClient:Arch:xxxxx:UNDI:yyyzzz", where 208 xxxxx = Client System Architecture (5 octets long, value 0 to 65535) 209 yyy = UNDI Major Version Number (3 octets long, value 0 to 255) 210 zzz = UNDI Minor Version Number (3 octets long, value 0 to 255) 212 Code Len 32-octet String 213 +-----+-----+-----+-----+-----+-----+-----+-----+ 214 | 60 | 32 | PXEClient:Arch:xxxxx:UNDI:yyyzzz | 215 +-----+-----+-----+-----+-----+-----+-----+-----+ 217 3.2.2 PXE Client Identifier (UUID) - Option 61 218 This option uniquely identifies a client machine. A 16-byte 219 universally unique identifier (UUID) is used for this purpose [6]. A 220 server can uniquely identify a client using this UUID and provide 221 customized service. 222 The code for this option is 61 and its length is 17, including the 223 type identifier that appears before the UUID. PXE requires a type- 224 identifier value of zero. 226 Code Len Type 16-octet Identifier 227 +-----+-----+-----+-----+-----+-----+-----+-----+ 228 | 61 | 17 | 254 | o1 | o2 | . . . . | o16 | 229 +-----+-----+-----+-----+-----+-----+-----+-----+ 231 3.2.3 PXE Vendor specific information - Option 43 232 The DHCP vendor specific information option is used by clients and 233 servers to exchange vendor specific information. The information is an 234 opaque object of n octets. The Encapsulated vendor-specific options 235 field MUST be encoded as a sequence of code/length/value fields of 236 identical syntax to the DHCP options field. 238 Code Len Vendor-specific information 239 +-----+-----+-----+-----+--- 240 | 43 | n | i1 | i2 | ... 241 +-----+-----+-----+-----+--- 243 < draft-henry-remote-boot-protocol-01.txt > June 24, 1999 245 Within this vendor specific information, we have several 246 code/length/value fields to specify the PXE related configuration 247 information. 249 3.2.3.1 PXE_DISCOVERY_CONTROL 250 This option specifies the different methods by which a client can 251 discover bootservers. 253 The code for this option is 6 and its length is 1. 255 Code Len PXE_DISCOVERY_CONTROL 256 +-----+-----+-----+ 257 | 6 | 1 | b1 | 258 +-----+-----+-----+ 260 The individual bits in this octet (bit 0 is the least significant bit) 261 are defined as follows: 263 Bit 0 - If set, broadcast discovery of servers is NOT allowed. 264 Bit 1 - If set, multicast discovery of servers is NOT allowed. 265 Bit 2 - If set, only use and/or accept replies from servers in 266 the list defined by PXE_BOOT_SERVERS tag 268 If this tag is not supplied, all bits are assumed to be 0. 270 3.2.3.2 DISCOVERY_MCAST_ADDR 271 This option specifies the multicast IP address that is used by the 272 client to discover bootservers. The client sends DHCPREQUEST packets 273 to this multicast address. 274 The code for this option is 7 and its length is 4. 276 Code Len DISCOVERY_MCAST_ADDR 277 +-----+-----+-----+-----+-----+-----+ 278 | 7 | 4 | m1 | m2 | m3 | m4 | 279 +-----+-----+-----+-----+-----+-----+ 281 3.2.3.3 PXE_BOOT_SERVERS 282 This option specifies a list of bootserver types and their IP 283 addresses. 285 The code for this option is 8 and its length is variable. It is a list 286 containing multiple entries of the following 3 elements. 288 o bootserver type (2 octets long) 289 o number of IP addresses (1 octet long) supporting the above type. 290 o IP addresses of those servers ([4 * number of IP addresses] octets 291 long). 293 < draft-henry-remote-boot-protocol-01.txt > June 24, 1999 295 Code Len BS type1 count 'n1' IP addresses 296 +-----+-----+-----+-----+-----+-----..-----+-----..----+--- 297 | 8 | v | t1 | t2 | n1 | IP addr 1 | IP addr 2 | . . 298 +-----+-----+-----+-----+-----+-----..-----+-----..----+--- 300 BS type2 count 'n2' IP addresses 301 +-----+-----+-----+-----..-----+-----..----+--- 302 | t1 | t2 | n2 | IP addr 1 | IP addr 2 | . . 303 +-----+-----+-----+-----..-----+-----..----+--- 305 3.2.3.4 PXE_BOOT_MENU 306 This option specifies a string description for each bootserver type 307 specified in option #8 above. The client MUST display this list to the 308 user on request to provide the user with descriptions of the 309 bootserver types. 311 The code for this option is 9 and its length is variable. It is a 312 list containing multiple entries of the following 3 elements. 314 o bootserver type (2 octets long) 315 o length of the description string (1 octet long) 316 o string describing the bootserver type ('n' octets long). 318 Code Len BS type1 str-len description 319 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----+ 320 | 9 | v | t1 | t2 | n1 | n1 octets of bootserver desc. | 321 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----+ 323 BS type2 str-len description 324 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 325 | t1 | t2 | n2 | n2 octets of bootserver description . . | 326 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 328 3.2.3.5 PXE_MENU_PROMPT 329 This option specifies the prompt message that the client can display 330 to the user before proceeding with the remote boot. This option 331 controls how the information obtained through the tag PXE_BOOT_MENU is 332 presented to the user and the duration for which it is displayed on 333 the screen. 335 The code for this option is 10 and its length is variable. 337 Code Len timeout Prompt String 338 +-----+-----+-----+-----+-----+-----+ 339 | 10 | v | t | prompt string .| 340 +-----+-----+-----+-----+-----+-----+ 342 < draft-henry-remote-boot-protocol-01.txt > June 24, 1999 344 Upon user request before boot, the prompt string and the menu obtained 345 through tag #8 "PXE_BOOT_MENU" are displayed. The prompt is followed 346 by the number of seconds remaining before the first item in the 347 "PXE_BOOT_MENU" is automatically selected. If this option #10 is not 348 returned, the menu MUST be displayed without prompt and timeout. 349 Similarly, if the timeout is 255, the menu and the prompt MUST be 350 displayed indefinitely till there is a user interaction. If the 351 timeout is zero, the client MUST immediately select the first item in 352 the menu. 354 3.2.3.6 PXE_BOOT_ITEM 355 This option specifies the bootserver type that the client is 356 discovering and also the "layer" number of the boot image that is 357 requested. "Layer 0" always indicates the first bootfile for a 358 particular bootserver type. 360 The code for this option is 71 and its length is 4. 362 Code Len BS Type Layer # 363 +-----+-----+----+----+-----+-----+ 364 | 71 | 4 | t1 | t2 | n1 | n2 | 365 +-----+-----+----+----+-----+-----+ 367 If the MSBit of "Layer #" is 0, then the containing message refers to 368 the bootfile itself. If the MSBit of "Layer #" is 1, then the 369 containing message refers to credentials for the bootfile. If the 370 MSBit of "Layer #" is 1 and the containing message is a DHCPREQUEST, 371 then the message MUST also include a PXE_CREDENTIAL_TYPES option. 373 3.2.3.7 PXE_CREDENTIAL_TYPES 374 This option specifies the types of credentials acceptable to the 375 client for authenticating a bootfile. 377 The code for this option is 12 and its length is variable. 379 Code Len Credential Types 380 +-----+-----+----------+----------+ 381 | 12 | v | t1(4) | . . . | 382 +-----+-----+----------+----------+ 384 Each credential type is a 4-byte code that specifies a public key that 385 the client trusts for the authentication of bootfiles. (This also 386 indicates, implicitly, the signature verification algorithms 387 implemented by the client.) The exact formulation of these codes and 388 the format of the credential files is specified in detail in [7]. 390 < draft-henry-remote-boot-protocol-01.txt > June 24, 1999 392 3.3. Remote Boot Configuration Protocol (RBCP) 394 To use RBCP, the client must have an IP address and have been 395 configured to use RBCP by the DHCP service as defined in the previous 396 section. In this case the client will know the type of one or more 397 bootservers. The client discovers one of these bootservers by sending 398 a DHCPREQUEST packet to the bootserver using either unicast, 399 multicast, or broadcast per the discovery instructions in Option #43, 400 Tag #6 (PXE_DISCOVERY_CONTROL). This packet MUST also include options 61 401 and 60. 403 3.3.1 Bootserver Discovery 405 The client displays the menu prompt that it received from the previous 406 step and lets the user pick a bootserver type. Once the user makes a 407 selection, the client tries to locate a bootserver of that type. This 408 is done by sending a DHCPREQUEST packet with the same information as 409 in along with the type of the bootserver it is trying to discover. 410 The discovery method by which this is done is determined by the option 411 received through the previous step. That option could specify a 412 multicast discovery, in which case, the client sends a multicast DHCP 413 REQUEST packet to port 4011. If there is no response to the multicast 414 discovery, then the client tries to broadcast the same request to the 415 DHCP server port (port 67). If there is no response to this request as 416 well, then the client tries to unicast the request to port 4011 using 417 the list of IP addresses (one after another) obtained through step 4. 418 The DHCPREQUEST packet that the client sends out contains the 419 following information. 421 o Client UUID (DHCP option #61) 422 o PXE Client Class Identifier Tag (DHCP option #60) 423 o PXE_BOOT_ITEM tag embedded in vendor specific information option 424 (DHCP option #43) specifying layer 0, not credentials 426 3.3.2 Bootserver Response 427 Bootservers receiving the DHCPREQUEST packet from the client MUST 428 respond if they are a bootserver of the type requested in the 429 PXE_BOOT_ITEM tag and they have bootfiles for the client system 430 architecture defined in the Option 60. If the above conditions are 431 satisfied, the bootserver responds with a DHCPACK packet containing 432 the following information. 434 o PXE Client Class Identifier (DHCP option #60 - "PXEClient") 435 o Bootfile name specified in the fixed DHCP header bootfile portion 436 o Several mTFTP related options embedded in vendor specific 437 information option #43. These are described more in detail in the 438 internet draft "Multicast TFTP in the Intel PXE Remote Boot 439 Environment" 440 o PXE_BOOT_ITEM tag embedded in vendor specific information option 441 (DHCP option #43) 443 < draft-henry-remote-boot-protocol-01.txt > June 24, 1999 445 The specific encapsulated vendor specific options provided by the boot 446 service are: 448 3.3.2.1 MTFTP_MULTICAST_IP_ADDRESS 449 This option specifies the multicast IP address that is used by the 450 client to listen for and receive the multicast packets transmitted by 451 the server. 453 The code for this option is 1 and its length is 4. 455 Code Len MTFTP_MULTICAST_IP_ADDRESS 456 +-----+-----+-----+-----+-----+-----+ 457 | 1 | 4 | m1 | m2 | m3 | m4 | 458 +-----+-----+-----+-----+-----+-----+ 460 3.3.2.2 MTFTP_CLIENT_UDP_PORT 461 This option specifies the UDP port that the client uses for the mTFTP 462 transfers. 464 The code for this option is 2 and its length is 2. 466 Code Len MTFTP_CLIENT_UDP_PORT 467 +-----+-----+-----+-----+ 468 | 2 | 2 | c1 | c2 | 469 +-----+-----+-----+-----+ 471 3.3.2.3 MTFTP_SERVER_UDP_PORT 472 This option specifies the UDP port that the server uses for the mTFTP 473 transfers. The client MUST send its mTFTP requests to this port on the 474 server. 476 The code for this option is 3 and its length is 2. 478 Code Len MTFTP_SERVER_UDP_PORT 479 +-----+-----+-----+-----+ 480 | 3 | 2 | s1 | s2 | 481 +-----+-----+-----+-----+ 483 3.3.2.4 MTFTP_TRANSMISSION_START_DELAY 484 This options specifies, in seconds, the amount of time a client should 485 wait before initiating a mTFTP transfer. 487 The code for this option is 4 and its length is 1. 489 Code Len MTFTP_TRANSMISSION_START_DELAY 490 +-----+-----+-----+ 491 | 4 | 1 | t1 | 492 +-----+-----+-----+ 494 < draft-henry-remote-boot-protocol-01.txt > June 24, 1999 496 3.3.2.5 MTFTP_TRANSFER_TIMEOUT 497 This options specifies, in seconds, the amount of time a client should 498 wait before re-sending a MTFP request. 499 The code for this option is 5 and its length is 1. 501 Code Len MTFTP_TRANSFER_TIMEOUT 502 +-----+-----+-----+ 503 | 5 | 1 | t1 | 504 +-----+-----+-----+ 506 3.3.2.6 PXE_BOOT_ITEM 507 This option specifies the bootserver type that the client is 508 discovering and also the "layer" number of the boot image that is 509 requested. "Layer 0" always indicates the first bootfile for a 510 particular bootserver type. 512 The code for this option is 71 and its length is 4. 514 Code Len BS Type Layer # 515 +-----+-----+----+----+-----+-----+ 516 | 71 | 4 | t1 | t2 | n1 | n2 | 517 +-----+-----+----+----+-----+-----+ 519 If the MSBit of "Layer #" is 0, then the containing message refers to 520 the bootfile itself. If the MSBit of "Layer #" is 1, then the 521 containing message refers to credentials for the bootfile. If the 522 MSBit of "Layer #" is 1 and the containing message is a DHCPREQUEST, 523 then the message MUST also include a PXE_CREDENTIAL_TYPES option. 525 3.4. Remote Boot Multicast TFTP (mTFTP) 527 This protocol is exactly the same as the standard TFTP protocol [2] 528 but for a simple difference. All the TFTP responses from the server 529 MUST be directed to the multicast IP address 530 (MTFTP_MULTICAST_IP_ADDRESS) as the destination IP address. This 531 enables multiple clients to listen to and receive the same packet that 532 is transmitted by the server. 534 Three things happen for a successful mTFTP transfer: 536 1. The bootserver acquires a block of multicast IP addresses that it 537 allocates to booting clients. (How the bootserver is allocated 538 blocks of multicast addresses is beyond the scope of this document. 539 Presumably the bootserver will use MADCAP [8]for this purpose.) 540 2. The bootserver configures the client to use the multicast IP 541 address to download the client bootfile. (This configuration was 542 covered in 3.3.2 above.) 543 3. The client initiates a mTFTP transfer or joins one already in 544 progress. To do this, the client uses the protocol defined in the 545 next section. 547 < draft-henry-remote-boot-protocol-01.txt > June 24, 1999 549 3.4.1 Multicast Trivial File Transfer Protocol Details 551 A client goes through the following 3 stages during a mTFTP transfer: 553 o mTFTP Open 554 o mTFTP Receive 555 o mTFTP Close 557 3.4.1.1 mTFTP Open 558 Any client wishing to download a file through mTFTP first determines 559 whether there is a multicast TFTP transfer already in progress for the 560 file that it wants to download. (The mTFTP server MUST use a unique 561 multicast address for each of the files that it can support in a mTFTP 562 transfer). The client, after binding to the port 563 MTFTP_CLIENT_UDP_PORT, waits for MTFTP_TRANSMISSION_START_DELAY 564 seconds to see whether there are any packets addressed to the 565 MTFTP_MULTICAST_IP_ADDRESS. Depending on whether there is a response 566 or not, the client follows different steps as explained in the next 2 567 sections. 569 3.4.1.1.1. Multicast transfer already in progress 570 If the client receives a response packet within the 571 MTFTP_TRANSMISSION_START_DELAY period, then a multicast transfer is 572 already in progress. The client starts receiving the packets and 573 stores them in an internal list (or uses some other mechanism to keep 574 track of the received packets). As this client is not the one to 575 initiate the original transfer, it MUST not send a TFTP ACK packet to 576 any of the received packets. When the file transfer finishes (this 577 happens when the TFTP server sends the last block of data of the 578 file), the client would only have received the ending portion of the 579 file. All the beginning blocks of the file were missed by this client, 580 when it joined a multicast transfer which was in progress already. We 581 will discuss how to receive the rest of the file in the section under 582 "mTFTP Receive". 584 3.4.1.1.2. No multicast transfer in progress 585 If the client does not receive any packets during the initial 586 MTFTP_TRANSMISSION_START_DELAY period, then it assumes that there is 587 no multicast transfer in progress at that time. At the end of this 588 period, the client requests the server to start a new transfer. This 589 is done by the client sending a regular TFTP open packet (opcode set 590 to 1). However, this packet is sent to the server's 591 MTFTP_SERVER_UDP_PORT so that the server knows that it is a multicast 592 TFTP request versus a standard TFTP request. 594 < draft-henry-remote-boot-protocol-01.txt > June 24, 1999 596 3.4.1.1.3. Server response to a MTFTP_OPEN request 597 When the server receives a MTFTP_OPEN request on its 598 MTFTP_SERVER_UDP_PORT, it checks to make sure that a transfer is not 599 already in progress. If there is a transfer already in progress for 600 the requested file, then the server ignores this request. The client 601 soon starts to receive some block of the file transfer that is in 602 progress on its MTFTP_CLIENT_UDP_PORT. However, if there is no 603 transfer in progress, then the server unicasts a response back to the 604 client for the first data packet and also follows that by multicasting 605 the same packet so that all other interested clients can also receive 606 that. 608 3.4.1.2 mTFTP Receive 609 As mentioned in the previous section, the first packet of a multicast 610 transfer MUST be sent both as unicast and multicast UDP packets. 611 Subsequent packets are only multicast. The recipient of the first 612 unicast packet becomes the master client which acknowledges each 613 received packet. The master client (i.e. the acknowledging client) 614 MUST acknowledge all packets even if that client has received the 615 entire file. A server MUST transmit the complete file. Therefore, 616 clients that start listening to a transfer part way through can wait 617 and then get the rest of the file on the next mTFTP transfer to make 618 up for what was missed during the first transmission. 620 3.4.1.3 mTFTP Close 621 A mTFTP transfer is finished when the acknowledging client has 622 received all packets and disconnects. Clients who joined the transfer 623 part way through the transfer can initiate a new transfer if one has 624 not already started. If there are multiple clients who joined part way 625 through, then there is an algorithm to minimize the number of clients 626 simultaneously trying to initiate a new transfer. Before a new 627 transfer is started, there is a calculated delay. An algorithm based 628 on the number of packets received modifies the default delay of 629 MTFTP_TRANSMISSION_START_DELAY seconds. Clients who received fewer 630 packets (because of the faster transfer rate of the server) wait for a 631 shorter time than those who received more. This algorithm ensures that 633 o Slower clients define the transmission speed as they are more 634 likely to become the acknowledging clients. 635 o Clients with a large number of received packets may disconnect from 636 the transfer after they received all missing packets as they are 637 less likely to become acknowledging clients. 639 < draft-henry-remote-boot-protocol-01.txt > June 24, 1999 641 3.5. Boot Integrity Services (BIS) 643 3.5.1 NBP Authentication Request 644 At this point the client MAY contact the bootserver again to obtain 645 authentication information for the bootfile. The protocol steps to do 646 this are very similar to the steps for obtaining the bootfile. In 647 particular, the client sends (unicast) a request to port 4011 on the 648 bootserver from which the bootfile was obtained. The DHCPREQUEST 649 packet that the client sends out contains the following information. 651 o Client UUID (DHCP option #61) 652 o PXE Client Class Identifier Tag (DHCP option #60) 653 o PXE_BOOT_ITEM tag embedded in vendor specific information option 654 (DHCP option #43) specifying layer 0, credentials 655 o PXE_CREDENTIAL_TYPES tag embedded in vendor specific information 656 option (DHCP option #43) specifying the type(s) of credentials 657 accepted by the client. 659 3.5.2 NBP Authentication Response 660 Bootservers receiving the packet described in MUST respond if they 661 have a credentials file of the type specified in the 662 PXE_CREDENTIALS_TYPE tag for a boot image file corresponding to the 663 bootserver type specified in the PXE_BOOT_ITEM tag and the client 664 system architecture defined in the class identifier tag. If the above 665 conditions are satisfied, the bootserver responds with a DHCPACK 666 packet containing the following information. 668 o PXE Client Class Identifier (DHCP option #60 - "PXEClient") 669 o Several mTFTP related options embedded in vendor specific 670 information option #43. These are described more in detail in the 671 internet draft "Multicast TFTP in the Intel PXE Remote Boot 672 Environment" [work in progress] 673 o PXE_BOOT_ITEM tag embedded in vendor specific information option 674 (DHCP option #43) 675 o Credentials file name specified in the fixed DHCP header bootfile 676 portion 678 3.5.3 NBP Credentials Delivery to Booting Client 679 The client, on receiving the DHCPACK packet from the bootserver, 680 contacts the (m)TFTP service on the bootserver which sent the reply 681 and downloads the credentials file. If the Multicast TFTP option is 682 chosen by the client, then the client follows the guidelines provided 683 in the internet draft "Multicast TFTP in the Intel PXE Remote Boot 684 Environment" 686 < draft-henry-remote-boot-protocol-01.txt > June 24, 1999 688 4. Security 690 This memo defines methods for bootfile authentication (covered in 691 section 3.5). Otherwise the protocols and usage of the protocols in 692 this memo are not secure. However, as PXE is based on DHCP, methods 693 being devised to protect DHCP [9] should generally apply to PXE. 695 5. References: 697 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 698 March 1997. 699 [2] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, June 700 1981. 701 [3] Preboot Execution Environment (PXE) Specification Version 2.0 702 ftp://download.intel.com/ial/wfm/pxespec.pdf 703 [4] Intel's Wired for Management Baseline v2.0 Specification, 704 ftp://download.intel.com/ial/wfm/base20.pdf 705 [5] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor 706 Extension", RFC 2132, March 1997. 707 [6] CAE Specification DCE 1.1: Remote Procedure Call Document 708 Number: C706 Universal Unique Identifier Appendix Copyright (c) 709 1997 The Open Group 710 http://www.opengroup.org/onlinepubs/9629399/toc.htm 711 [7] Boot Integrity Services Application Programming Interface 712 Version 1.0 ftp://download.intel.com/ial/wfm/bisspec.pdf 713 [8] S. Hanna, et al, "Multicast Address Dynamic Client Allocation 714 Protocol (MADCAP)" (Work in Progress) 715 [9] R. Droms, W. Arbaugh, "Authentication for DHCP Messages" (Work 716 in Progress) 718 < draft-henry-remote-boot-protocol-01.txt > June 24, 1999 720 6. Authors' Addresses 722 Michael Henry 723 Intel Corporation, MS JF3-206 724 5200 NE Elam Young Pkwy 725 Hillsboro, OR 97124 726 Phone: (503) 264-9689 727 Email: mike.henry@intel.com 729 Eric Dittert 730 Intel Corporation, MS JF3-206 731 5200 NE Elam Young Pkwy 732 Hillsboro, OR 97124 733 Phone: (503) 264-8561 734 Email: eric.dittert@intel.com 736 Dirk Koeppen 737 Bootix Technology GmbH (formerly InCom) 738 Geranienstr. 19 739 D-41466 Neuss 740 Germany 741 Phone: (011) 49 69 89 3000 742 Email: dirk@incom.de 744 Vish Viswanathan 745 Intel Corporation, MS JF3-303 746 5200 NE Elam Young Pkwy 747 Hillsboro, OR 97124 748 Phone: (503) 264-9693 749 Email: vish.viswanathan@intel.com