INTERNET DRAFT M. Henry, Intel Corp., Editor
D. Koeppen, Bootix Tech. GmbH
E. Dittert, Intel Corp.
Obsoletes: V. Viswanathan, Intel Corp.
<draft-viswanathan-remote-boot-protocol-01.txt> Jun 24, 1999
Expires December, 1999
Intel Preboot Execution Environment
<draft-henry-remote-boot-protocol-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or made obsolete by other documents at
any time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo describes the Intel PXE (Preboot Execution Environment)
remote boot definition (which is part of Intel's Wired for Management
initiative), and provides the rationale for proposing an extended
remote boot capability beyond what is currently specified in DHCP.
Expires December, 1999 [Page 1]
< draft-henry-remote-boot-protocol-01.txt > June 24, 1999
Table of Contents
1. RATIONALE FOR AN EXTENDED REMOTE BOOT CAPABILITY 2
2. TERMINOLOGY 3
3. PXE REMOTE BOOT 3
3.1. Use of DHCP 3
3.1.1 DHCPDISCOVER 3
3.1.2 DHCPOFFER 4
3.2. PXE Use of DHCP Options 4
3.2.1 PXE Class Identifier - Option 60 4
3.2.2 PXE Client Identifier (UUID) - Option 61 4
3.2.3 PXE Vendor specific information - Option 43 5
3.3. Remote Boot Configuration Protocol (RBCP) 7
3.3.1 Bootserver Discovery 8
3.3.2 Bootserver Response 9
3.4. Remote Boot Multicast TFTP (mTFTP) 11
3.4.1 Multicast Trivial File Transfer Protocol Details 12
3.5. Boot Integrity Services (BIS) 14
3.5.1 NBP Authentication Request 14
3.5.2 NBP Authentication Response 14
3.5.3 NBP Credentials Delivery to Booting Client 14
4. SECURITY 15
5. REFERENCES: 15
6. AUTHORS' ADDRESSES 16
1. Rationale for an Extended Remote Boot Capability
Internet Protocol provides for a remote boot capability through use of
DHCP [1]and TFTP [2]. DHCP provides the booting client with a
"bootfile" name and the IP address of a TFTP server, from which the
client downloads the bootfile. Depending on the capabilities of the
DHCP service, the network administrator may program the DHCP service
to determine the bootfile name to provide to the booting client based
on information presented by the client during the DHCP cycle.
While this mechanism is simple and powerful, we believe it could
usefully be extended. Specifically:
1. Extension of the canonical list of client information (presented to
the DHCP service) to include client instruction set architecture,
network interface type, etc., would be useful in many cases, as
would a well defined means to extend this list. Certainly this
information can be defined and included in the client on a case by
case basis, and the DHCP service can be specifically configured to
recognize and use the information. And certainly the format for
transmitting this information from client to DHCP service is
defined (option 60 and perhaps option 43). However the content is
ad hoc by definition, and in the case of option 60, the format of
the content is ad hoc if the content is divided into fields.
Expires December, 1999 [Page 2]
< draft-henry-remote-boot-protocol-01.txt > June 24, 1999
2. It would be useful to have a standard mechanism to expand the
number of bootfile sources presented to the client beyond the
single TFTP server defined in the DHCP response. Going beyond
this, it is desirable in some cases to provide the client with a
list of available proprietary and commercial bootservers.
3. If the booting client is redirected through the "siaddr" field to a
remote tftp service (bootserver), there is no standard method of
providing a redundant service. (Certainly, if the tftp service to
be used is on the DHCP server then presumably any DHCP redundancy
mechanism would apply to the tftp service.) Related to #2 above,
there is no method of providing redundancy across a pool of
heterogeneous bootservers. As the number of clients affected can
be quite large if the bootserver selected is unavailable, it is
critical to define a redundancy mechanism.
4. When simultaneously booting many (e.g. 100s or 1000s) of identical
clients it would be desirable to use a multicast TFTP. The current
specifications are silent on the subject of how the client obtains
the bootfile. However, the lowest common denominator assumed to be
available by commercial IP boot ROMs is TFTP.
5. It would be useful for the booting client to have the means to
verify the integrity and source of the bootfile.
It is the goal of PXE to address these limitations and define a remote
boot capability robust enough to allow a heterogeneous set of clients
to be selectively configured for remote boot via DHCP, and
subsequently to be supported by a heterogeneous set of boot servers.
Behaviorally, the goal is that a blank, unconfigured, compliant system
can be removed from it's shipping carton, plugged into the network,
and upon power on (with no other configuration) find an appropriate
bootserver.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
3. PXE Remote Boot
The PXE specification defines a complete remote boot mechanism,
including the DHCP configuration of the PXE client necessary for the
PXE client to use three new protocols to complete the remote boot.
These new protocols are described in this memo.
Expires December, 1999 [Page 3]
< draft-henry-remote-boot-protocol-01.txt > June 24, 1999
The three new protocols are: Remote Boot Configuration Protocol
(RBCP), remote boot multicast TFTP (mTFTP), and Boot Integrity
Services (BIS). RBCP is used by the PXE client to discover an
appropriate boot service. The boot service provides the client with a
bootfile name (the PXE client does not necessarily receive its
bootfile name from the DHCP service), and it provides the client with
any configuration necessary for the client to download the bootfile
via either TFTP or mTFTP. The PXE client (optionally) uses BIS to
authenticate the bootfile.
In addition, PXE defines a proxy DHCP specifically for PXE clients.
The proxy is used as an optional means to provide the initial DHCP
configuration of PXE clients in the absence of a DHCP service capable
of interpreting and/or responding to PXE client specific configuration
requests. By definition, the proxy will only respond to PXE clients.
The proxy may reside on the same server as the DHCP service or may
reside on a separate server. Details of proxy usage are beyond the
scope of this document.
3.1. Use of DHCP
3.1.1 DHCPDISCOVER
The PXE client's DHCPDISCOVER packet MUST include:
o Client Machine Identifier - UUID (DHCP Option#61).
o PXE Client Class Identifier (DHCP option #60 -
"PXEClient:Arch:xxxxx:UNDI:yyyzzz")
o Parameter Request List (DHCP Option #9). List MUST include at least
subnet(1), router(3), vendor(43), class(60)
3.1.2 DHCPOFFER
The DHCPOFFER includes encapsulated PXEW client vendor options in
Option $43 that provide:
o A ASCII list of available bootservers. The client MAY display this
list to the user and let the user select the bootserver of their
choice.
o A header prompt for the ASCII bootserver list that the client MUST
display to the user if the bootserver list is displayed.
o A timeout value in seconds for user to request the bootserver list
to be displayed. The client MUST wait for this timeout period
before the default bootserver is discovered.
o A list of bootserver types and their IP addresses. (IP address are
only useful if unicast discovery is enabled.)
o An option that specifies whether bootservers are to be discovered
by a broadcast, multicast or a unicast discovery method.
o A multicast discovery address that the client MAY use to locate the
bootserver if the multicast discovery option is enabled through the
previous option.
Expires December, 1999 [Page 4]
< draft-henry-remote-boot-protocol-01.txt > June 24, 1999
At this time, the PXE client may receive DHCPOFFER messages from
several DHCP servers. However, the PXE client MUST give preference to
offers whose replies contain option tag 60 ("PXEClient").
3.2. PXE Use of DHCP Options
3.2.1 PXE Class Identifier - Option 60
This option identifies PXE clients. This option also identifies the
client system's architecture and the version of the Universal Network
Driver Interface (UNDI) provided by the client.
The code for this option is 60 and its length is 32 octets long.
This option is of the form
"PXEClient:Arch:xxxxx:UNDI:yyyzzz", where
xxxxx = Client System Architecture (5 octets long, value 0 to 65535)
yyy = UNDI Major Version Number (3 octets long, value 0 to 255)
zzz = UNDI Minor Version Number (3 octets long, value 0 to 255)
Code Len 32-octet String
+-----+-----+-----+-----+-----+-----+-----+-----+
| 60 | 32 | PXEClient:Arch:xxxxx:UNDI:yyyzzz |
+-----+-----+-----+-----+-----+-----+-----+-----+
3.2.2 PXE Client Identifier (UUID) - Option 61
This option uniquely identifies a client machine. A 16-byte
universally unique identifier (UUID) is used for this purpose [6]. A
server can uniquely identify a client using this UUID and provide
customized service.
The code for this option is 61 and its length is 17, including the
type identifier that appears before the UUID. PXE requires a type-
identifier value of zero.
Code Len Type 16-octet Identifier
+-----+-----+-----+-----+-----+-----+-----+-----+
| 61 | 17 | 254 | o1 | o2 | . . . . | o16 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3.2.3 PXE Vendor specific information - Option 43
The DHCP vendor specific information option is used by clients and
servers to exchange vendor specific information. The information is an
opaque object of n octets. The Encapsulated vendor-specific options
field MUST be encoded as a sequence of code/length/value fields of
identical syntax to the DHCP options field.
Code Len Vendor-specific information
+-----+-----+-----+-----+---
| 43 | n | i1 | i2 | ...
+-----+-----+-----+-----+---
Expires December, 1999 [Page 5]
< draft-henry-remote-boot-protocol-01.txt > June 24, 1999
Within this vendor specific information, we have several
code/length/value fields to specify the PXE related configuration
information.
3.2.3.1 PXE_DISCOVERY_CONTROL
This option specifies the different methods by which a client can
discover bootservers.
The code for this option is 6 and its length is 1.
Code Len PXE_DISCOVERY_CONTROL
+-----+-----+-----+
| 6 | 1 | b1 |
+-----+-----+-----+
The individual bits in this octet (bit 0 is the least significant bit)
are defined as follows:
Bit 0 - If set, broadcast discovery of servers is NOT allowed.
Bit 1 - If set, multicast discovery of servers is NOT allowed.
Bit 2 - If set, only use and/or accept replies from servers in
the list defined by PXE_BOOT_SERVERS tag
If this tag is not supplied, all bits are assumed to be 0.
3.2.3.2 DISCOVERY_MCAST_ADDR
This option specifies the multicast IP address that is used by the
client to discover bootservers. The client sends DHCPREQUEST packets
to this multicast address.
The code for this option is 7 and its length is 4.
Code Len DISCOVERY_MCAST_ADDR
+-----+-----+-----+-----+-----+-----+
| 7 | 4 | m1 | m2 | m3 | m4 |
+-----+-----+-----+-----+-----+-----+
3.2.3.3 PXE_BOOT_SERVERS
This option specifies a list of bootserver types and their IP
addresses.
The code for this option is 8 and its length is variable. It is a list
containing multiple entries of the following 3 elements.
o bootserver type (2 octets long)
o number of IP addresses (1 octet long) supporting the above type.
o IP addresses of those servers ([4 * number of IP addresses] octets
long).
Expires December, 1999 [Page 6]
< draft-henry-remote-boot-protocol-01.txt > June 24, 1999
Code Len BS type1 count 'n1' IP addresses
+-----+-----+-----+-----+-----+-----..-----+-----..----+---
| 8 | v | t1 | t2 | n1 | IP addr 1 | IP addr 2 | . .
+-----+-----+-----+-----+-----+-----..-----+-----..----+---
BS type2 count 'n2' IP addresses
+-----+-----+-----+-----..-----+-----..----+---
| t1 | t2 | n2 | IP addr 1 | IP addr 2 | . .
+-----+-----+-----+-----..-----+-----..----+---
3.2.3.4 PXE_BOOT_MENU
This option specifies a string description for each bootserver type
specified in option #8 above. The client MUST display this list to the
user on request to provide the user with descriptions of the
bootserver types.
The code for this option is 9 and its length is variable. It is a
list containing multiple entries of the following 3 elements.
o bootserver type (2 octets long)
o length of the description string (1 octet long)
o string describing the bootserver type ('n' octets long).
Code Len BS type1 str-len description
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----+
| 9 | v | t1 | t2 | n1 | n1 octets of bootserver desc. |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----+
BS type2 str-len description
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| t1 | t2 | n2 | n2 octets of bootserver description . . |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
3.2.3.5 PXE_MENU_PROMPT
This option specifies the prompt message that the client can display
to the user before proceeding with the remote boot. This option
controls how the information obtained through the tag PXE_BOOT_MENU is
presented to the user and the duration for which it is displayed on
the screen.
The code for this option is 10 and its length is variable.
Code Len timeout Prompt String
+-----+-----+-----+-----+-----+-----+
| 10 | v | t | prompt string .|
+-----+-----+-----+-----+-----+-----+
Expires December, 1999 [Page 7]
< draft-henry-remote-boot-protocol-01.txt > June 24, 1999
Upon user request before boot, the prompt string and the menu obtained
through tag #8 "PXE_BOOT_MENU" are displayed. The prompt is followed
by the number of seconds remaining before the first item in the
"PXE_BOOT_MENU" is automatically selected. If this option #10 is not
returned, the menu MUST be displayed without prompt and timeout.
Similarly, if the timeout is 255, the menu and the prompt MUST be
displayed indefinitely till there is a user interaction. If the
timeout is zero, the client MUST immediately select the first item in
the menu.
3.2.3.6 PXE_BOOT_ITEM
This option specifies the bootserver type that the client is
discovering and also the "layer" number of the boot image that is
requested. "Layer 0" always indicates the first bootfile for a
particular bootserver type.
The code for this option is 71 and its length is 4.
Code Len BS Type Layer #
+-----+-----+----+----+-----+-----+
| 71 | 4 | t1 | t2 | n1 | n2 |
+-----+-----+----+----+-----+-----+
If the MSBit of "Layer #" is 0, then the containing message refers to
the bootfile itself. If the MSBit of "Layer #" is 1, then the
containing message refers to credentials for the bootfile. If the
MSBit of "Layer #" is 1 and the containing message is a DHCPREQUEST,
then the message MUST also include a PXE_CREDENTIAL_TYPES option.
3.2.3.7 PXE_CREDENTIAL_TYPES
This option specifies the types of credentials acceptable to the
client for authenticating a bootfile.
The code for this option is 12 and its length is variable.
Code Len Credential Types
+-----+-----+----------+----------+
| 12 | v | t1(4) | . . . |
+-----+-----+----------+----------+
Each credential type is a 4-byte code that specifies a public key that
the client trusts for the authentication of bootfiles. (This also
indicates, implicitly, the signature verification algorithms
implemented by the client.) The exact formulation of these codes and
the format of the credential files is specified in detail in [7].
Expires December, 1999 [Page 8]
< draft-henry-remote-boot-protocol-01.txt > June 24, 1999
3.3. Remote Boot Configuration Protocol (RBCP)
To use RBCP, the client must have an IP address and have been
configured to use RBCP by the DHCP service as defined in the previous
section. In this case the client will know the type of one or more
bootservers. The client discovers one of these bootservers by sending
a DHCPREQUEST packet to the bootserver using either unicast,
multicast, or broadcast per the discovery instructions in Option #43,
Tag #6 (PXE_DISCOVERY_CONTROL). This packet MUST also include options 61
and 60.
3.3.1 Bootserver Discovery
The client displays the menu prompt that it received from the previous
step and lets the user pick a bootserver type. Once the user makes a
selection, the client tries to locate a bootserver of that type. This
is done by sending a DHCPREQUEST packet with the same information as
in along with the type of the bootserver it is trying to discover.
The discovery method by which this is done is determined by the option
received through the previous step. That option could specify a
multicast discovery, in which case, the client sends a multicast DHCP
REQUEST packet to port 4011. If there is no response to the multicast
discovery, then the client tries to broadcast the same request to the
DHCP server port (port 67). If there is no response to this request as
well, then the client tries to unicast the request to port 4011 using
the list of IP addresses (one after another) obtained through step 4.
The DHCPREQUEST packet that the client sends out contains the
following information.
o Client UUID (DHCP option #61)
o PXE Client Class Identifier Tag (DHCP option #60)
o PXE_BOOT_ITEM tag embedded in vendor specific information option
(DHCP option #43) specifying layer 0, not credentials
3.3.2 Bootserver Response
Bootservers receiving the DHCPREQUEST packet from the client MUST
respond if they are a bootserver of the type requested in the
PXE_BOOT_ITEM tag and they have bootfiles for the client system
architecture defined in the Option 60. If the above conditions are
satisfied, the bootserver responds with a DHCPACK packet containing
the following information.
o PXE Client Class Identifier (DHCP option #60 - "PXEClient")
o Bootfile name specified in the fixed DHCP header bootfile portion
o Several mTFTP related options embedded in vendor specific
information option #43. These are described more in detail in the
internet draft "Multicast TFTP in the Intel PXE Remote Boot
Environment"
o PXE_BOOT_ITEM tag embedded in vendor specific information option
(DHCP option #43)
Expires December, 1999 [Page 9]
< draft-henry-remote-boot-protocol-01.txt > June 24, 1999
The specific encapsulated vendor specific options provided by the boot
service are:
3.3.2.1 MTFTP_MULTICAST_IP_ADDRESS
This option specifies the multicast IP address that is used by the
client to listen for and receive the multicast packets transmitted by
the server.
The code for this option is 1 and its length is 4.
Code Len MTFTP_MULTICAST_IP_ADDRESS
+-----+-----+-----+-----+-----+-----+
| 1 | 4 | m1 | m2 | m3 | m4 |
+-----+-----+-----+-----+-----+-----+
3.3.2.2 MTFTP_CLIENT_UDP_PORT
This option specifies the UDP port that the client uses for the mTFTP
transfers.
The code for this option is 2 and its length is 2.
Code Len MTFTP_CLIENT_UDP_PORT
+-----+-----+-----+-----+
| 2 | 2 | c1 | c2 |
+-----+-----+-----+-----+
3.3.2.3 MTFTP_SERVER_UDP_PORT
This option specifies the UDP port that the server uses for the mTFTP
transfers. The client MUST send its mTFTP requests to this port on the
server.
The code for this option is 3 and its length is 2.
Code Len MTFTP_SERVER_UDP_PORT
+-----+-----+-----+-----+
| 3 | 2 | s1 | s2 |
+-----+-----+-----+-----+
3.3.2.4 MTFTP_TRANSMISSION_START_DELAY
This options specifies, in seconds, the amount of time a client should
wait before initiating a mTFTP transfer.
The code for this option is 4 and its length is 1.
Code Len MTFTP_TRANSMISSION_START_DELAY
+-----+-----+-----+
| 4 | 1 | t1 |
+-----+-----+-----+
Expires December, 1999 [Page 10]
< draft-henry-remote-boot-protocol-01.txt > June 24, 1999
3.3.2.5 MTFTP_TRANSFER_TIMEOUT
This options specifies, in seconds, the amount of time a client should
wait before re-sending a MTFP request.
The code for this option is 5 and its length is 1.
Code Len MTFTP_TRANSFER_TIMEOUT
+-----+-----+-----+
| 5 | 1 | t1 |
+-----+-----+-----+
3.3.2.6 PXE_BOOT_ITEM
This option specifies the bootserver type that the client is
discovering and also the "layer" number of the boot image that is
requested. "Layer 0" always indicates the first bootfile for a
particular bootserver type.
The code for this option is 71 and its length is 4.
Code Len BS Type Layer #
+-----+-----+----+----+-----+-----+
| 71 | 4 | t1 | t2 | n1 | n2 |
+-----+-----+----+----+-----+-----+
If the MSBit of "Layer #" is 0, then the containing message refers to
the bootfile itself. If the MSBit of "Layer #" is 1, then the
containing message refers to credentials for the bootfile. If the
MSBit of "Layer #" is 1 and the containing message is a DHCPREQUEST,
then the message MUST also include a PXE_CREDENTIAL_TYPES option.
3.4. Remote Boot Multicast TFTP (mTFTP)
This protocol is exactly the same as the standard TFTP protocol [2]
but for a simple difference. All the TFTP responses from the server
MUST be directed to the multicast IP address
(MTFTP_MULTICAST_IP_ADDRESS) as the destination IP address. This
enables multiple clients to listen to and receive the same packet that
is transmitted by the server.
Three things happen for a successful mTFTP transfer:
1. The bootserver acquires a block of multicast IP addresses that it
allocates to booting clients. (How the bootserver is allocated
blocks of multicast addresses is beyond the scope of this document.
Presumably the bootserver will use MADCAP [8]for this purpose.)
2. The bootserver configures the client to use the multicast IP
address to download the client bootfile. (This configuration was
covered in 3.3.2 above.)
3. The client initiates a mTFTP transfer or joins one already in
progress. To do this, the client uses the protocol defined in the
next section.
Expires December, 1999 [Page 11]
< draft-henry-remote-boot-protocol-01.txt > June 24, 1999
3.4.1 Multicast Trivial File Transfer Protocol Details
A client goes through the following 3 stages during a mTFTP transfer:
o mTFTP Open
o mTFTP Receive
o mTFTP Close
3.4.1.1 mTFTP Open
Any client wishing to download a file through mTFTP first determines
whether there is a multicast TFTP transfer already in progress for the
file that it wants to download. (The mTFTP server MUST use a unique
multicast address for each of the files that it can support in a mTFTP
transfer). The client, after binding to the port
MTFTP_CLIENT_UDP_PORT, waits for MTFTP_TRANSMISSION_START_DELAY
seconds to see whether there are any packets addressed to the
MTFTP_MULTICAST_IP_ADDRESS. Depending on whether there is a response
or not, the client follows different steps as explained in the next 2
sections.
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".
3.4.1.1.2. No multicast transfer in progress
If the client does not receive any packets during the initial
MTFTP_TRANSMISSION_START_DELAY period, then it assumes that there is
no multicast transfer in progress at that time. At the end of this
period, the client requests the server to start a new transfer. This
is done by the client sending a regular TFTP open packet (opcode set
to 1). However, this packet is sent to the server's
MTFTP_SERVER_UDP_PORT so that the server knows that it is a multicast
TFTP request versus a standard TFTP request.
Expires December, 1999 [Page 12]
< draft-henry-remote-boot-protocol-01.txt > June 24, 1999
3.4.1.1.3. Server response to a MTFTP_OPEN request
When the server receives a MTFTP_OPEN request on its
MTFTP_SERVER_UDP_PORT, it checks to make sure that a transfer is not
already in progress. If there is a transfer already in progress for
the requested file, then the server ignores this request. The client
soon starts to receive some block of the file transfer that is in
progress on its MTFTP_CLIENT_UDP_PORT. However, if there is no
transfer in progress, then the server unicasts a response back to the
client for the first data packet and also follows that by multicasting
the same packet so that all other interested clients can also receive
that.
3.4.1.2 mTFTP Receive
As mentioned in the previous section, the first packet of a multicast
transfer MUST be sent both as unicast and multicast UDP packets.
Subsequent packets are only multicast. The recipient of the first
unicast packet becomes the master client which acknowledges each
received packet. The master client (i.e. the acknowledging client)
MUST acknowledge all packets even if that client has received the
entire file. A server MUST transmit the complete file. Therefore,
clients that start listening to a transfer part way through can wait
and then get the rest of the file on the next mTFTP transfer to make
up for what was missed during the first transmission.
3.4.1.3 mTFTP Close
A mTFTP transfer is finished when the acknowledging client has
received all packets and disconnects. Clients who joined the transfer
part way through the transfer can initiate a new transfer if one has
not already started. If there are multiple clients who joined part way
through, then there is an algorithm to minimize the number of clients
simultaneously trying to initiate a new transfer. Before a new
transfer is started, there is a calculated delay. An algorithm based
on the number of packets received modifies the default delay of
MTFTP_TRANSMISSION_START_DELAY seconds. Clients who received fewer
packets (because of the faster transfer rate of the server) wait for a
shorter time than those who received more. This algorithm ensures that
o Slower clients define the transmission speed as they are more
likely to become the acknowledging clients.
o Clients with a large number of received packets may disconnect from
the transfer after they received all missing packets as they are
less likely to become acknowledging clients.
Expires December, 1999 [Page 13]
< draft-henry-remote-boot-protocol-01.txt > June 24, 1999
3.5. Boot Integrity Services (BIS)
3.5.1 NBP Authentication Request
At this point the client MAY contact the bootserver again to obtain
authentication information for the bootfile. The protocol steps to do
this are very similar to the steps for obtaining the bootfile. In
particular, the client sends (unicast) a request to port 4011 on the
bootserver from which the bootfile was obtained. The DHCPREQUEST
packet that the client sends out contains the following information.
o Client UUID (DHCP option #61)
o PXE Client Class Identifier Tag (DHCP option #60)
o PXE_BOOT_ITEM tag embedded in vendor specific information option
(DHCP option #43) specifying layer 0, credentials
o PXE_CREDENTIAL_TYPES tag embedded in vendor specific information
option (DHCP option #43) specifying the type(s) of credentials
accepted by the client.
3.5.2 NBP Authentication Response
Bootservers receiving the packet described in MUST respond if they
have a credentials file of the type specified in the
PXE_CREDENTIALS_TYPE tag for a boot image file corresponding to the
bootserver type specified in the PXE_BOOT_ITEM tag and the client
system architecture defined in the class identifier tag. If the above
conditions are satisfied, the bootserver responds with a DHCPACK
packet containing the following information.
o PXE Client Class Identifier (DHCP option #60 - "PXEClient")
o Several mTFTP related options embedded in vendor specific
information option #43. These are described more in detail in the
internet draft "Multicast TFTP in the Intel PXE Remote Boot
Environment" [work in progress]
o PXE_BOOT_ITEM tag embedded in vendor specific information option
(DHCP option #43)
o Credentials file name specified in the fixed DHCP header bootfile
portion
3.5.3 NBP Credentials Delivery to Booting Client
The client, on receiving the DHCPACK packet from the bootserver,
contacts the (m)TFTP service on the bootserver which sent the reply
and downloads the credentials file. If the Multicast TFTP option is
chosen by the client, then the client follows the guidelines provided
in the internet draft "Multicast TFTP in the Intel PXE Remote Boot
Environment"
Expires December, 1999 [Page 14]
< draft-henry-remote-boot-protocol-01.txt > June 24, 1999
4. Security
This memo defines methods for bootfile authentication (covered in
section 3.5). Otherwise the protocols and usage of the protocols in
this memo are not secure. However, as PXE is based on DHCP, methods
being devised to protect DHCP [9] should generally apply to PXE.
5. References:
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[2] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, June
1981.
[3] Preboot Execution Environment (PXE) Specification Version 2.0
ftp://download.intel.com/ial/wfm/pxespec.pdf
[4] Intel's Wired for Management Baseline v2.0 Specification,
ftp://download.intel.com/ial/wfm/base20.pdf
[5] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
Extension", RFC 2132, March 1997.
[6] CAE Specification DCE 1.1: Remote Procedure Call Document
Number: C706 Universal Unique Identifier Appendix Copyright (c)
1997 The Open Group
http://www.opengroup.org/onlinepubs/9629399/toc.htm
[7] Boot Integrity Services Application Programming Interface
Version 1.0 ftp://download.intel.com/ial/wfm/bisspec.pdf
[8] S. Hanna, et al, "Multicast Address Dynamic Client Allocation
Protocol (MADCAP)" (Work in Progress)
[9] R. Droms, W. Arbaugh, "Authentication for DHCP Messages" (Work
in Progress)
Expires December, 1999 [Page 15]
< draft-henry-remote-boot-protocol-01.txt > June 24, 1999
6. Authors' Addresses
Michael Henry
Intel Corporation, MS JF3-206
5200 NE Elam Young Pkwy
Hillsboro, OR 97124
Phone: (503) 264-9689
Email: mike.henry@intel.com
Eric Dittert
Intel Corporation, MS JF3-206
5200 NE Elam Young Pkwy
Hillsboro, OR 97124
Phone: (503) 264-8561
Email: eric.dittert@intel.com
Dirk Koeppen
Bootix Technology GmbH (formerly InCom)
Geranienstr. 19
D-41466 Neuss
Germany
Phone: (011) 49 69 89 3000
Email: dirk@incom.de
Vish Viswanathan
Intel Corporation, MS JF3-303
5200 NE Elam Young Pkwy
Hillsboro, OR 97124
Phone: (503) 264-9693
Email: vish.viswanathan@intel.com
Expires December, 1999 [Page 16]