[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/