ISC dhcp, needs security audit for sure

1 files changed, 684 insertions, 0 deletions

diff --git a/usr.sbin/dhcp/doc/rfc951.txt b/usr.sbin/dhcp/doc/rfc951.txt
new file mode 100644
index 00000000000..86cd69e63c5
--- /dev/null
+++ b/usr.sbin/dhcp/doc/rfc951.txt
@@ -0,0 +1,684 @@
+
+
+Network Working Group                   Bill Croft (Stanford University)
+Request for Comments: 951                John Gilmore (Sun Microsystems)
+                                                          September 1985
+
+                       BOOTSTRAP PROTOCOL (BOOTP)
+
+
+1. Status of this Memo
+
+   This RFC suggests a proposed protocol for the ARPA-Internet
+   community, and requests discussion and suggestions for improvements.
+   Distribution of this memo is unlimited.
+
+2. Overview
+
+   This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows
+   a diskless client machine to discover its own IP address, the address
+   of a server host, and the name of a file to be loaded into memory and
+   executed.  The bootstrap operation can be thought of as consisting of
+   TWO PHASES.  This RFC describes the first phase, which could be
+   labeled 'address determination and bootfile selection'.  After this
+   address and filename information is obtained, control passes to the
+   second phase of the bootstrap where a file transfer occurs.  The file
+   transfer will typically use the TFTP protocol [9], since it is
+   intended that both phases reside in PROM on the client.  However
+   BOOTP could also work with other protocols such as SFTP [3] or
+   FTP [6].
+
+   We suggest that the client's PROM software provide a way to do a
+   complete bootstrap without 'user' interaction.  This is the type of
+   boot that would occur during an unattended power-up.  A mechanism
+   should be provided for the user to manually supply the necessary
+   address and filename information to bypass the BOOTP protocol and
+   enter the file transfer phase directly.  If non-volatile storage is
+   available, we suggest keeping default settings there and bypassing
+   the BOOTP protocol unless these settings cause the file transfer
+   phase to fail.  If the cached information fails, the bootstrap should
+   fall back to phase 1 and use BOOTP.
+
+   Here is a brief outline of the protocol:
+
+      1. A single packet exchange is performed.  Timeouts are used to
+      retransmit until a reply is received.  The same packet field
+      layout is used in both directions.  Fixed length fields of maximum
+      reasonable length are used to simplify structure definition and
+      parsing.
+
+      2. An 'opcode' field exists with two values.  The client
+      broadcasts a 'bootrequest' packet.  The server then answers with a
+      'bootreply' packet.  The bootrequest contains the client's
+      hardware address and its IP address, if known.
+
+
+Croft & Gilmore                                                 [Page 1]
+
+
+
+RFC 951                                                   September 1985
+Bootstrap Protocol
+
+
+      3. The request can optionally contain the name of the server the
+      client wishes to respond.  This is so the client can force the
+      boot to occur from a specific host (e.g. if multiple versions of
+      the same bootfile exist or if the server is in a far distant
+      net/domain).  The client does not have to deal with name / domain
+      services; instead this function is pushed off to the BOOTP server.
+
+      4. The request can optionally contain the 'generic' filename to be
+      booted.  For example 'unix' or 'ethertip'.  When the server sends
+      the bootreply, it replaces this field with the fully qualified
+      path name of the appropriate boot file.  In determining this name,
+      the server may consult his own database correlating the client's
+      address and filename request, with a particular boot file
+      customized for that client.  If the bootrequest filename is a null
+      string, then the server returns a filename field indicating the
+      'default' file to be loaded for that client.
+
+      5. In the case of clients who do not know their IP addresses, the
+      server must also have a database relating hardware address to IP
+      address.  This client IP address is then placed into a field in
+      the bootreply.
+
+      6. Certain network topologies (such as Stanford's) may be such
+      that a given physical cable does not have a TFTP server directly
+      attached to it (e.g. all the gateways and hosts on a certain cable
+      may be diskless).  With the cooperation of neighboring gateways,
+      BOOTP can allow clients to boot off of servers several hops away,
+      through these gateways.  See the section 'Booting Through
+      Gateways' below.  This part of the protocol requires no special
+      action on the part of the client.  Implementation is optional and
+      requires a small amount of additional code in gateways and
+      servers.
+
+3. Packet Format
+
+   All numbers shown are decimal, unless indicated otherwise.  The BOOTP
+   packet is enclosed in a standard IP [8] UDP [7] datagram.  For
+   simplicity it is assumed that the BOOTP packet is never fragmented.
+   Any numeric fields shown are packed in 'standard network byte order',
+   i.e. high order bits are sent first.
+
+   In the IP header of a bootrequest, the client fills in its own IP
+   source address if known, otherwise zero.  When the server address is
+   unknown, the IP destination address will be the 'broadcast address'
+   255.255.255.255.  This address means 'broadcast on the local cable,
+   (I don't know my net number)' [4].
+
+
+
+Croft & Gilmore                                                 [Page 2]
+
+
+
+RFC 951                                                   September 1985
+Bootstrap Protocol
+
+
+   The UDP header contains source and destination port numbers.  The
+   BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68)
+   and 'BOOTP server' (67).  The client sends requests using 'BOOTP
+   server' as the destination port; this is usually a broadcast.  The
+   server sends replies using 'BOOTP client' as the destination port;
+   depending on the kernel or driver facilities in the server, this may
+   or may not be a broadcast (this is explained further in the section
+   titled 'Chicken/Egg issues' below).  The reason TWO reserved ports
+   are used, is to avoid 'waking up' and scheduling the BOOTP server
+   daemons, when a bootreply must be broadcast to a client.  Since the
+   server and other hosts won't be listening on the 'BOOTP client' port,
+   any such incoming broadcasts will be filtered out at the kernel
+   level.  We could not simply allow the client to pick a 'random' port
+   number for the UDP source port field; since the server reply may be
+   broadcast, a randomly chosen port number could confuse other hosts
+   that happened to be listening on that port.
+
+   The UDP length field is set to the length of the UDP plus BOOTP
+   portions of the packet.  The UDP checksum field can be set to zero by
+   the client (or server) if desired, to avoid this extra overhead in a
+   PROM implementation.  In the 'Packet Processing' section below the
+   phrase '[UDP checksum.]' is used whenever the checksum might be
+   verified/computed.
+
+      FIELD   BYTES   DESCRIPTION
+      -----   -----   -----------
+
+         op      1       packet op code / message type.
+                         1 = BOOTREQUEST, 2 = BOOTREPLY
+
+         htype   1       hardware address type,
+                         see ARP section in "Assigned Numbers" RFC.
+                         '1' = 10mb ethernet
+
+         hlen    1       hardware address length
+                         (eg '6' for 10mb ethernet).
+
+         hops    1       client sets to zero,
+                         optionally used by gateways
+                         in cross-gateway booting.
+
+         xid     4       transaction ID, a random number,
+                         used to match this boot request with the
+                         responses it generates.
+
+         secs    2       filled in by client, seconds elapsed since
+                         client started trying to boot.
+
+
+Croft & Gilmore                                                 [Page 3]
+
+
+
+RFC 951                                                   September 1985
+Bootstrap Protocol
+
+
+         --      2       unused
+
+         ciaddr  4       client IP address;
+                         filled in by client in bootrequest if known.
+
+         yiaddr  4       'your' (client) IP address;
+                         filled by server if client doesn't
+                         know its own address (ciaddr was 0).
+
+         siaddr  4       server IP address;
+                         returned in bootreply by server.
+
+         giaddr  4       gateway IP address,
+                         used in optional cross-gateway booting.
+
+         chaddr  16      client hardware address,
+                         filled in by client.
+
+         sname   64      optional server host name,
+                         null terminated string.
+
+         file    128     boot file name, null terminated string;
+                         'generic' name or null in bootrequest,
+                         fully qualified directory-path
+                         name in bootreply.
+
+         vend    64      optional vendor-specific area,
+                         e.g. could be hardware type/serial on request,
+                         or 'capability' / remote file system handle
+                         on reply.  This info may be set aside for use
+                         by a third phase bootstrap or kernel.
+
+4. Chicken / Egg Issues
+
+   How can the server send an IP datagram to the client, if the client
+   doesnt know its own IP address (yet)?  Whenever a bootreply is being
+   sent, the transmitting machine performs the following operations:
+
+      1. If the client knows its own IP address ('ciaddr' field is
+      nonzero), then the IP can be sent 'as normal', since the client
+      will respond to ARPs [5].
+
+      2. If the client does not yet know its IP address (ciaddr zero),
+      then the client cannot respond to ARPs sent by the transmitter of
+      the bootreply.  There are two options:
+
+         a. If the transmitter has the necessary kernel or driver hooks
+
+
+Croft & Gilmore                                                 [Page 4]
+
+
+
+RFC 951                                                   September 1985
+Bootstrap Protocol
+
+
+         to 'manually' construct an ARP address cache entry, then it can
+         fill in an entry using the 'chaddr' and 'yiaddr' fields.  Of
+         course, this entry should have a timeout on it, just like any
+         other entry made by the normal ARP code itself.  The
+         transmitter of the bootreply can then simply send the bootreply
+         to the client's IP address.  UNIX (4.2 BSD) has this
+         capability.
+
+         b. If the transmitter lacks these kernel hooks, it can simply
+         send the bootreply to the IP broadcast address on the
+         appropriate interface.  This is only one additional broadcast
+         over the previous case.
+
+5. Client Use of ARP
+
+   The client PROM must contain a simple implementation of ARP, e.g. the
+   address cache could be just one entry in size.  This will allow a
+   second-phase-only boot (TFTP) to be performed when the client knows
+   the IP addresses and bootfile name.
+
+   Any time the client is expecting to receive a TFTP or BOOTP reply, it
+   should be prepared to answer an ARP request for its own IP to
+   hardware address mapping (if known).
+
+   Since the bootreply will contain (in the hardware encapsulation) the
+   hardware source address of the server/gateway, the client MAY be able
+   to avoid sending an ARP request for the server/gateway IP address to
+   be used in the following TFTP phase.  However this should be treated
+   only as a special case, since it is desirable to still allow a
+   second-phase-only boot as described above.
+
+6. Comparison to RARP
+
+   An earlier protocol, Reverse Address Resolution Protocol (RARP) [1]
+   was proposed to allow a client to determine its IP address, given
+   that it knew its hardware address.  However RARP had the disadvantage
+   that it was a hardware link level protocol (not IP/UDP based).  This
+   means that RARP could only be implemented on hosts containing special
+   kernel or driver modifications to access these 'raw' packets.  Since
+   there are many network kernels existent now, with each source
+   maintained by different organizations, a boot protocol that does not
+   require kernel modifications is a decided advantage.
+
+   BOOTP provides this hardware to IP address lookup function, in
+   addition to the other useful features described in the sections
+   above.
+
+
+
+Croft & Gilmore                                                 [Page 5]
+
+
+
+RFC 951                                                   September 1985
+Bootstrap Protocol
+
+
+7. Packet Processing
+
+   7.1. Client Transmission
+
+      Before setting up the packet for the first time, it is a good idea
+      to clear the entire packet buffer to all zeros; this will place
+      all fields in their default state.  The client then creates a
+      packet with the following fields.
+
+      The IP destination address is set to 255.255.255.255.  (the
+      broadcast address) or to the server's IP address (if known).  The
+      IP source address and 'ciaddr' are set to the client's IP address
+      if known, else 0.  The UDP header is set with the proper length;
+      source port = 'BOOTP client' port destination port = 'BOOTP
+      server' port.
+
+      'op' is set to '1', BOOTREQUEST.  'htype' is set to the hardware
+      address type as assigned in the ARP section of the "Assigned
+      Numbers" RFC. 'hlen' is set to the length of the hardware address,
+      e.g. '6' for 10mb ethernet.
+
+      'xid' is set to a 'random' transaction id.  'secs' is set to the
+      number of seconds that have elapsed since the client has started
+      booting.  This will let the servers know how long a client has
+      been trying.  As the number gets larger, certain servers may feel
+      more 'sympathetic' towards a client they don't normally service.
+      If a client lacks a suitable clock, it could construct a rough
+      estimate using a loop timer.  Or it could choose to simply send
+      this field as always a fixed value, say 100 seconds.
+
+      If the client knows its IP address, 'ciaddr' (and the IP source
+      address) are set to this value.  'chaddr' is filled in with the
+      client's hardware address.
+
+      If the client wishes to restrict booting to a particular server
+      name, it may place a null-terminated string in 'sname'.  The name
+      used should be any of the allowable names or nicknames of the
+      desired host.
+
+      The client has several options for filling the 'file' name field.
+      If left null, the meaning is 'I want to boot the default file for
+      my machine'.  A null file name can also mean 'I am only interested
+      in finding out client/server/gateway IP addresses, I dont care
+      about file names'.
+
+      The field can also be a 'generic' name such as 'unix' or
+
+
+
+Croft & Gilmore                                                 [Page 6]
+
+
+
+RFC 951                                                   September 1985
+Bootstrap Protocol
+
+
+      'gateway'; this means 'boot the named program configured for my
+      machine'.  Finally the field can be a fully directory qualified
+      path name.
+
+      The 'vend' field can be filled in by the client with
+      vendor-specific strings or structures.  For example the machine
+      hardware type or serial number may be placed here.  However the
+      operation of the BOOTP server should not DEPEND on this
+      information existing.
+
+      If the 'vend' field is used, it is recommended that a 4 byte
+      'magic number' be the first item within 'vend'.  This lets a
+      server determine what kind of information it is seeing in this
+      field.  Numbers can be assigned by the usual 'magic number'
+      process --you pick one and it's magic.  A different magic number
+      could be used for bootreply's than bootrequest's to allow the
+      client to take special action with the reply information.
+
+      [UDP checksum.]
+
+   7.2. Client Retransmission Strategy
+
+      If no reply is received for a certain length of time, the client
+      should retransmit the request.  The time interval must be chosen
+      carefully so as not to flood the network.  Consider the case of a
+      cable containing 100 machines that are just coming up after a
+      power failure.  Simply retransmitting the request every four
+      seconds will inundate the net.
+
+      As a possible strategy, you might consider backing off
+      exponentially, similar to the way ethernet backs off on a
+      collision.  So for example if the first packet is at time 0:00,
+      the second would be at :04, then :08, then :16, then :32, then
+      :64.  You should also randomize each time; this would be done
+      similar to the ethernet specification by starting with a mask and
+      'and'ing that with with a random number to get the first backoff.
+      On each succeeding backoff, the mask is increased in length by one
+      bit.  This doubles the average delay on each backoff.
+
+      After the 'average' backoff reaches about 60 seconds, it should be
+      increased no further, but still randomized.
+
+      Before each retransmission, the client should update the 'secs'
+      field. [UDP checksum.]
+
+
+
+
+
+Croft & Gilmore                                                 [Page 7]
+
+
+
+RFC 951                                                   September 1985
+Bootstrap Protocol
+
+
+   7.3. Server Receives BOOTREQUEST
+
+      [UDP checksum.]  If the UDP destination port does not match the
+      'BOOTP server' port, discard the packet.
+
+      If the server name field (sname) is null (no particular server
+      specified), or sname is specified and matches our name or
+      nickname, then continue with packet processing.
+
+      If the sname field is specified, but does not match 'us', then
+      there are several options:
+
+         1. You may choose to simply discard this packet.
+
+         2. If a name lookup on sname shows it to be on this same cable,
+         discard the packet.
+
+         3. If sname is on a different net, you may choose to forward
+         the packet to that address.  If so, check the 'giaddr' (gateway
+         address) field.  If 'giaddr' is zero, fill it in with my
+         address or the address of a gateway that can be used to get to
+         that net.  Then forward the packet.
+
+      If the client IP address (ciaddr) is zero, then the client does
+      not know its own IP address.  Attempt to lookup the client
+      hardware address (chaddr, hlen, htype) in our database.  If no
+      match is found, discard the packet.  Otherwise we now have an IP
+      address for this client; fill it into the 'yiaddr' (your IP
+      address) field.
+
+      We now check the boot file name field (file).  The field will be
+      null if the client is not interested in filenames, or wants the
+      default bootfile.  If the field is non-null, it is used as a
+      lookup key in a database, along with the client's IP address.  If
+      there is a default file or generic file (possibly indexed by the
+      client address) or a fully-specified path name that matches, then
+      replace the 'file' field with the fully-specified path name of the
+      selected boot file.  If the field is non-null and no match was
+      found, then the client is asking for a file we dont have; discard
+      the packet, perhaps some other BOOTP server will have it.
+
+      The 'vend' vendor-specific data field should now be checked and if
+      a recognized type of data is provided, client-specific actions
+      should be taken, and a response placed in the 'vend' data field of
+      the reply packet.  For example, a workstation client could provide
+
+
+
+
+Croft & Gilmore                                                 [Page 8]
+
+
+
+RFC 951                                                   September 1985
+Bootstrap Protocol
+
+
+      an authentication key and receive from the server a capability for
+      remote file access, or a set of configuration options, which can
+      be passed to the operating system that will shortly be booted in.
+
+      Place my (server) IP address in the 'siaddr' field.  Set the 'op'
+      field to BOOTREPLY.  The UDP destination port is set to 'BOOTP
+      client'.  If the client address 'ciaddr' is nonzero, send the
+      packet there; else if the gateway address 'giaddr' is nonzero, set
+      the UDP destination port to 'BOOTP server' and send the packet to
+      'giaddr'; else the client is on one of our cables but it doesnt
+      know its own IP address yet --use a method described in the 'Egg'
+      section above to send it to the client. If 'Egg' is used and we
+      have multiple interfaces on this host, use the 'yiaddr' (your IP
+      address) field to figure out which net (cable/interface) to send
+      the packet to.  [UDP checksum.]
+
+   7.4. Server/Gateway Receives BOOTREPLY
+
+      [UDP checksum.]  If 'yiaddr' (your [the client's] IP address)
+      refers to one of our cables, use one of the 'Egg' methods above to
+      forward it to the client.  Be sure to send it to the 'BOOTP
+      client' UDP destination port.
+
+   7.5. Client Reception
+
+      Don't forget to process ARP requests for my own IP address (if I
+      know it).  [UDP checksum.]  The client should discard incoming
+      packets that: are not IP/UDPs addressed to the boot port; are not
+      BOOTREPLYs; do not match my IP address (if I know it) or my
+      hardware address; do not match my transaction id.  Otherwise we
+      have received a successful reply. 'yiaddr' will contain my IP
+      address, if I didnt know it before.  'file' is the name of the
+      file name to TFTP 'read request'.  The server address is in
+      'siaddr'.  If 'giaddr' (gateway address) is nonzero, then the
+      packets should be forwarded there first, in order to get to the
+      server.
+
+8. Booting Through Gateways
+
+   This part of the protocol is optional and requires some additional
+   code in cooperating gateways and servers, but it allows cross-gateway
+   booting.  This is mainly useful when gateways are diskless machines.
+   Gateways containing disks (e.g. a UNIX machine acting as a gateway),
+   might as well run their own BOOTP/TFTP servers.
+
+   Gateways listening to broadcast BOOTREQUESTs may decide to forward or
+   rebroadcast these requests 'when appropriate'.  For example, the
+
+
+Croft & Gilmore                                                 [Page 9]
+
+
+
+RFC 951                                                   September 1985
+Bootstrap Protocol
+
+
+   gateway could have, as part of his configuration tables, a list of
+   other networks or hosts to receive a copy of any broadcast
+   BOOTREQUESTs.  Even though a 'hops' field exists, it is a poor idea
+   to simply globally rebroadcast the requests, since broadcast loops
+   will almost certainly occur.
+
+   The forwarding could begin immediately, or wait until the 'secs'
+   (seconds client has been trying) field passes a certain threshold.
+
+   If a gateway does decide to forward the request, it should look at
+   the 'giaddr' (gateway IP address) field.  If zero, it should plug its
+   own IP address (on the receiving cable) into this field.  It may also
+   use the 'hops' field to optionally control how far the packet is
+   reforwarded. Hops should be incremented on each forwarding.  For
+   example, if hops passes '3', the packet should probably be discarded.
+   [UDP checksum.]
+
+   Here we have recommended placing this special forwarding function in
+   the gateways.  But that does not have to be the case.  As long as
+   some 'BOOTP forwarding agent' exists on the net with the booting
+   client, the agent can do the forwarding when appropriate.  Thus this
+   service may or may not be co-located with the gateway.
+
+   In the case of a forwarding agent not located in the gateway, the
+   agent could save himself some work by plugging the broadcast address
+   of the interface receiving the bootrequest into the 'giaddr' field.
+   Thus the reply would get forwarded using normal gateways, not
+   involving the forwarding agent.  Of course the disadvantage here is
+   that you lose the ability to use the 'Egg' non-broadcast method of
+   sending the reply, causing extra overhead for every host on the
+   client cable.
+
+9. Sample BOOTP Server Database
+
+   As a suggestion, we show a sample text file database that the BOOTP
+   server program might use.  The database has two sections, delimited
+   by a line containing an percent in column 1.  The first section
+   contains a 'default directory' and mappings from generic names to
+   directory/pathnames.  The first generic name in this section is the
+   'default file' you get when the bootrequest contains a null 'file'
+   string.
+
+   The second section maps hardware addresstype/address into an
+   ipaddress. Optionally you can also overide the default generic name
+   by supplying a ipaddress specific genericname.  A 'suffix' item is
+   also an option; if supplied, any generic names specified by the
+   client will be accessed by first appending 'suffix' to the 'pathname'
+
+
+Croft & Gilmore                                                [Page 10]
+
+
+
+RFC 951                                                   September 1985
+Bootstrap Protocol
+
+
+   appropriate to that generic name.  If that file is not found, then
+   the plain 'pathname' will be tried.  This 'suffix' option allows a
+   whole set of custom generics to be setup without a lot of effort.
+   Below is shown the general format; fields are delimited by one or
+   more spaces or tabs; trailing empty fields may be omitted; blank
+   lines and lines beginning with '#' are ignored.
+
+      # comment line
+
+      homedirectory
+      genericname1    pathname1
+      genericname2    pathname2
+      ...
+
+      % end of generic names, start of address mappings
+
+      hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname suffix
+      hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix
+      ...
+
+   Here is a specific example.  Note the 'hardwaretype' number is the
+   same as that shown in the ARP section of the 'Assigned Numbers' RFC.
+   The 'hardwaretype' and 'ipaddr' numbers are in decimal;
+   'hardwareaddr' is in hex.
+
+      # last updated by smith
+
+      /usr/boot
+      vmunix          vmunix
+      tip             ethertip
+      watch           /usr/diag/etherwatch
+      gate            gate.
+
+      % end of generic names, start of address mappings
+
+      hamilton        1 02.60.8c.06.34.98     36.19.0.5
+      burr            1 02.60.8c.34.11.78     36.44.0.12
+      101-gateway     1 02.60.8c.23.ab.35     36.44.0.32      gate 101
+      mjh-gateway     1 02.60.8c.12.32.bc     36.42.0.64      gate mjh
+      welch-tipa      1 02.60.8c.22.65.32     36.47.0.14      tip
+      welch-tipb      1 02.60.8c.12.15.c8     36.46.0.12      tip
+
+   In the example above, if 'mjh-gateway' does a default boot, it will
+   get the file '/usr/boot/gate.mjh'.
+
+
+
+
+
+Croft & Gilmore                                                [Page 11]
+
+
+
+RFC 951                                                   September 1985
+Bootstrap Protocol
+
+
+10. Acknowledgements
+
+   Ross Finlayson (et. al.) produced two earlier RFC's discussing TFTP
+   bootstraping [2] using RARP [1].
+
+   We would also like to acknowledge the previous work and comments of
+   Noel Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, and David Plummer.
+
+REFERENCES
+
+   1.  Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer.  A
+       Reverse Address Resolution Protocol.  RFC 903, NIC, June, 1984.
+
+   2.  Ross Finlayson.  Bootstrap Loading using TFTP.  RFC 906, NIC,
+       June, 1984.
+
+   3.  Mark Lottor.  Simple File Transfer Protocol.  RFC 913, NIC,
+       September, 1984.
+
+   4.  Jeffrey Mogul.  Broadcasting Internet Packets.  RFC 919, NIC,
+       October, 1984.
+
+   5.  David Plummer.  An Ethernet Address Resolution Protocol.  RFC
+       826, NIC, September, 1982.
+
+   6.  Jon Postel.  File Transfer Protocol.  RFC 765, NIC, June, 1980.
+
+   7.  Jon Postel.  User Datagram Protocol.  RFC 768, NIC, August, 1980.
+
+   8.  Jon Postel.  Internet Protocol.  RFC 791, NIC, September, 1981.
+
+   9.  K. R. Sollins, Noel Chiappa.  The TFTP Protocol.  RFC 783, NIC,
+       June, 1981.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Croft & Gilmore                                                [Page 12]
+