llbbl
09-13-2004, 06:06 PM
BOOTP stands for the Bootstrap or BOOT Protocol. The standard method for booting a computer is to locate a boot block on a local drive and then go from there, so why are we discussing booting in a book that is supposed to be about networks? During the 1980s, BOOTP was developed to allow diskless workstations to boot by downloading the operating system from another network node. Many operating systems at that time used this protocol because it allowed the use of cheaper desktop workstations on the network—long before PCs became a standard desktop item. At the time, the X-Windows workstation was popular in Unix and OpenVMS networks. BOOTP was an economical way to provide an X-Windows desktop with an operating system, without the need to equip the machine with disk drives and other devices not necessary for a simple client. Other types of network clients adopted the BOOTP protocol, allowing network devices to also be suitably configured by use of the protocol.
Note
The BOOTP protocol was originally defined in RFC 951, "Bootstrap Protocol," in 1985, and further details were provided by RFC 1542, "Clarifications and Extensions for the Bootstrap Protocol," in 1993. That RFC was made obsolete by several other RFCs, of which the most current is the proposed standard of the same name (RFC 2132). Another important proposed standard is RFC 1534, "Interoperation Between DHCP and BOOTP."
Downloading an operating system is only one of the functions performed by BOOTP. In addition, the diskless workstation (or other client) can also obtain network addressing information. This is because the lowest-level BOOTP client is presumed to be "diskless." It has no method to store configurable IP addressing information between power cycles.
The BOOTP protocol is not complex. Indeed, it is a simple protocol that is small and easy to implement in programmable read-only memory (PROM) chips. The following are some important features of BOOTP:
*
A simple request/reply mechanism is used. The same packet format is used for both requests and replies.
*
The UDP protocol is used to carry messages (ports 67 and 68, the same as are used by DHCP).
*
Using relay agents, BOOTP exchanges can occur across routers.
*
BOOTP can supply the client with an IP address, a subnet mask, and a default gateway. A BOOTP server also can give the client name of a trivial FTP server (TFTP) and a filename that can be used to download an operating system. This TFTP server is especially important for diskless workstations, as well as network devices that need to download an operating system. The trivial FTP server, which is a stripped-down simple version of FTP, is covered in Chapter 26, "Basic TCP/IP Services and Applications."
Another protocol, the Reverse Address Resolution Protocol (RARP), operates at the second layer of the OSI network model and also is capable of providing an IP address to another node that is booting on the network. However, RARP is very limited. For more information about RARP, see Chapter 25, "Overview of the TCP/IP Protocol Suite."
Format of the BOOTP Packet
The client and server share a common packet format. This packet is passed to UDP (the User Datagram Protocol) and encapsulated inside a UDP packet. The UDP and IP headers are added, and the information finally is passed to the Data Link and Physical layers for transmission on the network medium.
The IP and UDP protocols are also discussed in greater detail in Chapter 25.
The fields of the BOOTP packet are used for the following purposes:
*
Opcode— This 1-byte field has a value of either zero or one. If set to a value of one, the packet is a request from a client to a BOOTP server (or a DHCP server, as explained later). If the value is zero, the packet is a reply from a server to the client.
*
Hardware Type— Values in this 1-byte field are used to designate different kinds of hardware, or different computer types or network device types, for example. A value of one in this field indicates that the underlying hardware type of the network is 10Mb Ethernet, whereas the value of 32 is used for the emerging technology known as InfiniBand. You can find the full list of values at www.iana.org/assignments/arp-parameters.
*
Hardware Address Length— This 1-byte field indicates the number of bytes that the client hardware address field contains. For Ethernet, this value is six, because it takes 6 bytes to represent the 48-bit Media Access Control (MAC) address used by Ethernet network cards.
*
Hop Count— This 1-byte field is always set to zero by the client, though the BOOTP server uses this field when relaying BOOTP requests across routers.
*
Transaction ID— This is a 4-byte field that is a unique 32-bit integer the client sets so that it can match up replies from the server to the requests the client has sent.
*
Seconds— This 2-byte field is expressed in seconds and is filled in by the client with a value indicating the time that has elapsed since the client started the boot process. This value can be used by secondary servers to recognize that the client's primary server is not responding. In that case, a secondary BOOTP server can make an attempt to satisfy the request.
*
Flags— In the original specifications for BOOTP, this 2-byte field was not used. However, in RFC 1542 this field was set aside to store flag bits. Only one has been defined so far. The most significant bit in this field is used as a Broadcast flag. The remaining bits are not yet defined and should be set to zeros.
*
Client IP Address (ciaddr)— If the client already knows its own address (which is explained shortly), it will fill in that address in this 4-byte field. In most cases, the client does not know its own IP address (because that's one of the main things BOOTP is used to supply to the client), and in that case the value for this field should be zero.
*
Your IP Address (yiaddr)— This field is used by the BOOTP server to supply an IP address to a client requesting one. It also is a 4-byte field, the number of bytes needed to store an IP address. Although the client can fill in the ciaddr field with a requested address, this field contains the address the DHCP server returns to the client to use.
*
Server IP Address (siaddr)— The BOOTP server fills in this field, usually placing its own address here.
*
Gateway IP Address (giaddr)— If a BOOTP proxy server is being used, the address in this 4-byte field is the address of the router or other device performing the proxy function. Proxy BOOTP services are discussed later in this chapter. Note that this is not the address the client should use as a default gateway for TCP/IP configuration (though it could be the same). This field is used only to relay BOOTP requests across routers to and from the actual BOOTP server. The default gateway information is supplied in BOOTP options, described later in this chapter (see the section "Enabling the DHCP Relay Agent").
*
Client's Hardware Address (chaddr)— If the client already knows its own IP address, it will place the IP address into this 4-byte field. The client must fill in this required field because the typical BOOTP server uses it in an index of values it keeps track of for its clients.
*
Server Hostname (sname)— This field can be up to 64 bytes in length and contains a null-terminated ASCII string of characters that represent the server's hostname on the network. This hostname can be a simple hostname or a fully qualified domain name (FQDN). This is an optional field.
*
Boot Filename (file)— This field can be up to 128 characters in length and is used to supply the client with the filename it can download and use to boot. The value here is also a null-terminated string and includes the full path the client needs in order to locate the file.
*
Vendor-Specific Area— These 64 bytes are set aside to store vendor-specific optional information. The items are listed in Table 29.1 in the section "BOOTP Vendor-Specific Information Options." The first four octets in this field will be a "magic cookie." The last octet is the "End" tag, the value 255.
The client's hardware address (technically called the Media Access Control address, or MAC address) that is placed in the BOOTP packet is the same hardware address that will be found in the Ethernet frame that delivers the packet. However, after the Ethernet frame is received, the lower-level header information (such as the client's hardware address) is stripped off before the remaining packet is passed up through the IP and UDP layers. At the point where the BOOTP protocol begins to examine the packet, the Ethernet frame header information is not available in most TCP/IP stacks. For this reason, the hardware address is duplicated inside the BOOTP packet. Remember that the RARP protocol is a link-layer protocol, so it can retrieve the client's hardware address from the Ethernet frame, something most implementations of BOOTP cannot do.
Note
For those who are interested in the nitty-gritty details, the packets discussed here are transmitted on the wire in the order shown in the figures in this chapter. Additionally, the individual bytes are sent with the leftmost bit being the most significant. For multi-octet values, the most significant octet is transmitted first. This information might help you when diagnosing problems on the network using a LAN analyzer or other methods to intercept and interpret network packets.
http://www.informit.com/title/0789728176&aid=3F57BAFE-6844-4E3E-B416-1E4E8B625D34&p=SFCPBAS
Cool huh . I never knew about BOOTP
Note
The BOOTP protocol was originally defined in RFC 951, "Bootstrap Protocol," in 1985, and further details were provided by RFC 1542, "Clarifications and Extensions for the Bootstrap Protocol," in 1993. That RFC was made obsolete by several other RFCs, of which the most current is the proposed standard of the same name (RFC 2132). Another important proposed standard is RFC 1534, "Interoperation Between DHCP and BOOTP."
Downloading an operating system is only one of the functions performed by BOOTP. In addition, the diskless workstation (or other client) can also obtain network addressing information. This is because the lowest-level BOOTP client is presumed to be "diskless." It has no method to store configurable IP addressing information between power cycles.
The BOOTP protocol is not complex. Indeed, it is a simple protocol that is small and easy to implement in programmable read-only memory (PROM) chips. The following are some important features of BOOTP:
*
A simple request/reply mechanism is used. The same packet format is used for both requests and replies.
*
The UDP protocol is used to carry messages (ports 67 and 68, the same as are used by DHCP).
*
Using relay agents, BOOTP exchanges can occur across routers.
*
BOOTP can supply the client with an IP address, a subnet mask, and a default gateway. A BOOTP server also can give the client name of a trivial FTP server (TFTP) and a filename that can be used to download an operating system. This TFTP server is especially important for diskless workstations, as well as network devices that need to download an operating system. The trivial FTP server, which is a stripped-down simple version of FTP, is covered in Chapter 26, "Basic TCP/IP Services and Applications."
Another protocol, the Reverse Address Resolution Protocol (RARP), operates at the second layer of the OSI network model and also is capable of providing an IP address to another node that is booting on the network. However, RARP is very limited. For more information about RARP, see Chapter 25, "Overview of the TCP/IP Protocol Suite."
Format of the BOOTP Packet
The client and server share a common packet format. This packet is passed to UDP (the User Datagram Protocol) and encapsulated inside a UDP packet. The UDP and IP headers are added, and the information finally is passed to the Data Link and Physical layers for transmission on the network medium.
The IP and UDP protocols are also discussed in greater detail in Chapter 25.
The fields of the BOOTP packet are used for the following purposes:
*
Opcode— This 1-byte field has a value of either zero or one. If set to a value of one, the packet is a request from a client to a BOOTP server (or a DHCP server, as explained later). If the value is zero, the packet is a reply from a server to the client.
*
Hardware Type— Values in this 1-byte field are used to designate different kinds of hardware, or different computer types or network device types, for example. A value of one in this field indicates that the underlying hardware type of the network is 10Mb Ethernet, whereas the value of 32 is used for the emerging technology known as InfiniBand. You can find the full list of values at www.iana.org/assignments/arp-parameters.
*
Hardware Address Length— This 1-byte field indicates the number of bytes that the client hardware address field contains. For Ethernet, this value is six, because it takes 6 bytes to represent the 48-bit Media Access Control (MAC) address used by Ethernet network cards.
*
Hop Count— This 1-byte field is always set to zero by the client, though the BOOTP server uses this field when relaying BOOTP requests across routers.
*
Transaction ID— This is a 4-byte field that is a unique 32-bit integer the client sets so that it can match up replies from the server to the requests the client has sent.
*
Seconds— This 2-byte field is expressed in seconds and is filled in by the client with a value indicating the time that has elapsed since the client started the boot process. This value can be used by secondary servers to recognize that the client's primary server is not responding. In that case, a secondary BOOTP server can make an attempt to satisfy the request.
*
Flags— In the original specifications for BOOTP, this 2-byte field was not used. However, in RFC 1542 this field was set aside to store flag bits. Only one has been defined so far. The most significant bit in this field is used as a Broadcast flag. The remaining bits are not yet defined and should be set to zeros.
*
Client IP Address (ciaddr)— If the client already knows its own address (which is explained shortly), it will fill in that address in this 4-byte field. In most cases, the client does not know its own IP address (because that's one of the main things BOOTP is used to supply to the client), and in that case the value for this field should be zero.
*
Your IP Address (yiaddr)— This field is used by the BOOTP server to supply an IP address to a client requesting one. It also is a 4-byte field, the number of bytes needed to store an IP address. Although the client can fill in the ciaddr field with a requested address, this field contains the address the DHCP server returns to the client to use.
*
Server IP Address (siaddr)— The BOOTP server fills in this field, usually placing its own address here.
*
Gateway IP Address (giaddr)— If a BOOTP proxy server is being used, the address in this 4-byte field is the address of the router or other device performing the proxy function. Proxy BOOTP services are discussed later in this chapter. Note that this is not the address the client should use as a default gateway for TCP/IP configuration (though it could be the same). This field is used only to relay BOOTP requests across routers to and from the actual BOOTP server. The default gateway information is supplied in BOOTP options, described later in this chapter (see the section "Enabling the DHCP Relay Agent").
*
Client's Hardware Address (chaddr)— If the client already knows its own IP address, it will place the IP address into this 4-byte field. The client must fill in this required field because the typical BOOTP server uses it in an index of values it keeps track of for its clients.
*
Server Hostname (sname)— This field can be up to 64 bytes in length and contains a null-terminated ASCII string of characters that represent the server's hostname on the network. This hostname can be a simple hostname or a fully qualified domain name (FQDN). This is an optional field.
*
Boot Filename (file)— This field can be up to 128 characters in length and is used to supply the client with the filename it can download and use to boot. The value here is also a null-terminated string and includes the full path the client needs in order to locate the file.
*
Vendor-Specific Area— These 64 bytes are set aside to store vendor-specific optional information. The items are listed in Table 29.1 in the section "BOOTP Vendor-Specific Information Options." The first four octets in this field will be a "magic cookie." The last octet is the "End" tag, the value 255.
The client's hardware address (technically called the Media Access Control address, or MAC address) that is placed in the BOOTP packet is the same hardware address that will be found in the Ethernet frame that delivers the packet. However, after the Ethernet frame is received, the lower-level header information (such as the client's hardware address) is stripped off before the remaining packet is passed up through the IP and UDP layers. At the point where the BOOTP protocol begins to examine the packet, the Ethernet frame header information is not available in most TCP/IP stacks. For this reason, the hardware address is duplicated inside the BOOTP packet. Remember that the RARP protocol is a link-layer protocol, so it can retrieve the client's hardware address from the Ethernet frame, something most implementations of BOOTP cannot do.
Note
For those who are interested in the nitty-gritty details, the packets discussed here are transmitted on the wire in the order shown in the figures in this chapter. Additionally, the individual bytes are sent with the leftmost bit being the most significant. For multi-octet values, the most significant octet is transmitted first. This information might help you when diagnosing problems on the network using a LAN analyzer or other methods to intercept and interpret network packets.
http://www.informit.com/title/0789728176&aid=3F57BAFE-6844-4E3E-B416-1E4E8B625D34&p=SFCPBAS
Cool huh . I never knew about BOOTP