Browse Prior Art Database

Network IPL without a TFTPD Server

IP.com Disclosure Number: IPCOM000111328D
Original Publication Date: 1994-Feb-01
Included in the Prior Art Database: 2005-Mar-26
Document File: 4 page(s) / 119K

Publishing Venue

IBM

Related People

Mott, JM: AUTHOR

Abstract

Disclosed are some requirements for network IPL that are not brought out in the existing architecture document [*]. Most of the requirements have been uncovered by the team that created the IBM X-terminal.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 39% of the total text.

Network IPL without a TFTPD Server

      Disclosed are some requirements for network IPL that are not
brought out in the existing architecture document [*].  Most of the
requirements have been uncovered by the team that created the IBM
X-terminal.

      The network IPL architecture calls for a client to use the TFTP
protocol, defined in RFC 783, to load a kernel.  There is an
undocumented assumption in the architecture, namely, that the
customer is able and willing to run a tftp server on the system that
contains the kernel for the workstation attempting to boot over the
network.  The customer must be able to run the tftp server if they
wish to use our network IPL story.

      It is not clear that all customers will be willing to run the
standard UNIX* tftp server.  As shipped, tftpd, the standard UNIX
tftp server, will read any file that has read permission for others.
Since some users of a system don't want to be bothered to protect
their files, it is often the case that a system will contain many
files readable by others that should not be distributed.  While this
is not the best way to run a system from a security standpoint, it is
a common way.  Many system administrators on systems like these will
not run the tftp daemon in an attempt to limit their exposure to
unauthorized file browsing.

      The function required of the tftp daemon, by a client trying to
load a kernel over the network, is significantly less than the
function provided by a full RFC 783 compliant server.  This section
tries to document the minimum subset of the function that is required
by network IPL.

      There are five types of packets processed by a tftp server.  Of
these five, we require support for 4:

     1 - RRQ(01)    Read request   (receive only)

     2 - data(03)   Data packet    (send only)

     3 - ACK(04)    Acknowledgment (receive only)

     4 - error(05)  Error occurred  (send and receive)

      There will be an initial RRQ packet from the client, multiple
data packets sent from the server to the client, one or more acks per
data packet from the client, and, hopefully, no error packets.

      There are normally two data modes and one obsolete mode
requested in the initial RRQ packet.  In addition, we may have the
IBM-defined SECIPL mode requested by a network IPL client.  These
modes are:

     1 - netascii   Data should be translated to/from ASCII, includes
                    <CR><LF> and \n \0 conversions.  (No support
                    required)

     2 - octet      Data is untranslated 8-bit bytes in network
                    order. (Support required)

     3 - mail       This is an obsolete mode to support mail.  (No
                    support required)

     4 - SECIPL     This is an IBM-defined secure network IPL
                    formatte...