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].

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.

         --      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.