On this page
|
| SUMMARY | |
| Protocol |
: |
Bootstrap Protocol |
| Protocol suite |
: |
TCP/IP |
| Layer |
: |
Application Layer |
| Type |
: |
Application layer configuration protocol. |
| Ports |
: |
67 (UDP) server
68 (UDP) host |
| Related protocols |
: |
DHCP,IP,
IPv6,
TCP,
UDP,
RARP |
| Working groups |
: |
DHCP, Dynamic Host Configuration Protocol |
|
| DESCRIPTION |
The Bootstrap Protocol (BOOTP) is an UDP/IP-based protocol which allows a booting host to configure itself dynamically and without user supervision. BOOTP provides a means to notify a host of its assigned IP address, the IP address of a boot server host, and the name of a file to be loaded into memory and executed.
This protocol is designed to allow a (possibly diskless) client machine to determine its own Internet address, the address of a boot server, and the name of an appropriate boot file to be loaded and executed. BOOTP does not provide the actual transfer of the boot file, which is typically done with a simple file transfer protocol such as TFTP.
The bootstrap operation can be thought of as consisting of TWO PHASES. Here 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, since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP or FTP
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.
Outline of the protocol
- 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.
- 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.
- 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 The client does not have to deal with name / domain services; instead this function is pushed off to the BOOTP server.
- 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.
- 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.
- 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.
Header format
8 | 16 | 24 | 32 | Opcode | Hardware type | Hardware address length | Hop count | Transaction ID | Number of seconds | Flags | Client IP address | Your IP address | Server IP address | Gateway IP address | Client hardware address | Server host name | Boot filename | Vendor specific info |
- Opcode
8 bits. DHCP message operation code: either BOOTREQUEST or BOOTREPLY.
Value | Description | 1 | BOOTREQUEST, Boot request. | 2 | BOOTREPLY, Boot reply. |
- Hardware type
8 bits.
Value | Description | 1 | Ethernet. | 2 | Experimental Ethernet. | 3 | Amateur Radio AX.25. | 4 | Proteon ProNET Token Ring. | 5 | Chaos. | 6 | IEEE 802. | 7 | ARCNET. | 8 | Hyperchannel. | 9 | Lanstar. | 10 | Autonet Short Address. | 11 | LocalTalk. | 12 | LocalNet (IBM PCNet or SYTEK LocalNET). | 13 | Ultra link. | 14 | SMDS. | 15 | Frame Relay. | 16 | ATM, Asynchronous Transmission Mode. | 17 | HDLC. | 18 | Fibre Channel. | 19 | ATM, Asynchronous Transmission Mode. | 20 | Serial Line. | 21 | ATM, Asynchronous Transmission Mode. | 22 | MIL-STD-188-220. | 23 | Metricom. | 24 | IEEE 1394.1995. | 25 | MAPOS. | 26 | Twinaxial. | 27 | EUI-64. | 28 | HIPARP. |
- Hop count
8 bits. client sets to zero, optionally used by gateways in cross-gateway booting.
- Transaction ID
32 bits. Transaction ID is a random number, used to match this boot request with the responses it generates.
- Number of seconds
16 bits. The elapsed time, in seconds since the client sent its first BOOTREQUEST message.
- Flags
16 bits.
- Client IP address
32 bits. It isfilled in by client in bootrequest if known.
- Your IP address
32 bits. It is filled by server if client doesn't know its own address (ciaddr was 0).
- Server IP address
32 bits. Server IP address returned in bootreply by server.
- Gateway IP address
32 bits. Gateway IP address used in optional cross-gateway booting.
- Client hardware address
16 bytes. Client hardware address filled in by client.
- Server host name
64 bytes. Null terminated string.
- Boot filename
128 bytes. Null terminated string; 'generic' name or null in bootrequest, fully qualified directory-path name in bootreply.
- Vendor specific info
64 bytes. It 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.
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:
- 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.
- 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.
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).
Booting Through Gateways
Gateways listening to broadcast BOOTREQUESTs may decide to forward or rebroadcast these requests 'when appropriate'. For example, thegateway 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.
|
 Top of Page
|
| EXAMPLES |
|
|
Top of Page
|
| PROTOCOL RELATIONS |
■ Parent layer
■ Child layer
|
Top of Page
|
| GLOSSARY |
|
ARP
Address Resolution Protocol (ARP) is a network layer protocol used to convert an IP address into a physical address (called a DLC address), such as an Ethernet address. A host wishing to obtain a physical address broadcasts an ARP request onto the TCP/IP network. The host on the network that has the IP address in the request then replies with its physical hardware address.
DHCP
Dynamic Host Configuration Protocol (DHCP) is a protocol for assigning dynamic IP addresses to devices on a network. With dynamic addressing, a device can have a different IP address every time it connects to the network. In some systems, the device's IP address can even change while it is still connected. DHCP also supports a mix of static and dynamic IP addresses.
Dynamic addressing simplifies network administration because the software keeps track of IP addresses rather than requiring an administrator to manage the task. This means that a new computer can be added to a network without the hassle of manually assigning it a unique IP address. Many ISPs use dynamic IP addressing for dial-up users.
Gateway
A network device used to translate between two different protocols. Used to interconnect two networks that use incompatible protocols. It is a node on a network that serves as an entrance to another network. In enterprises, the gateway is the computer that routes the traffic from a workstation to the outside network that is serving the Web pages. In homes, the gateway is the ISP that connects the user to the internet.
In enterprises, the gateway node often acts as a proxy server and a firewall. The gateway is also associated with both a router, which use headers and forwarding tables to determine where packets are sent, and a switch, which provides the actual path for the packet in and out of the gateway.
It is also a computer system located on earth that switches data signals and voice signals between satellites and terrestrial networks and an earlier term for router, though now obsolete in this sense as router is commonly used.
IP address
IP address is an identifier for a computer or device on a TCP/IP network. Networks using the TCP/IP protocol route messages based on the IP address of the destination. The format of an IP address is a 32-bit numeric address written as four numbers separated by periods. Each number can be zero to 255. For example, 1.160.10.240 could be an IP address. Within an isolated network, you can assign IP addresses at random as long as each one is unique. However, connecting a private network to the Internet requires using registered IP addresses (called Internet addresses) to avoid duplicates.
The four numbers in an IP address are used in different ways to identify a particular network and a host on that network. Four regional Internet registries -- ARIN, RIPE NCC, LACNIC and APNIC -- assign Internet addresses from the following three classes.
Class A - supports 16 million hosts on each of 126 networks
Class B - supports 65,000 hosts on each of 16,000 networks
Class C - supports 254 hosts on each of 2 million networks
The number of unassigned Internet addresses is running out, so a new classless scheme called CIDR is gradually replacing the system based on classes A, B, and C and is tied to adoption of IPv6.
TFTP
TFTP(Trivial File Transfer Protocol) is a simple form of the File Transfer Protocol (FTP). TFTP uses the User Datagram Protocol (UDP)and provides no security features. It is often used by servers to boot diskless workstations, X-terminals, and routers.
UDP
UDP (User Datagram Protocol) is a connectionless protocol that, like TCP, runs on top of IP networks. Unlike TCP/IP, UDP/IP provides very few error recovery services, offering instead a direct way to send and receive datagrams over an IP network. It's used primarily for broadcasting messages over a network.
|
Top of Page
|
| REFERENCES |
RFCs:
[ RFC 951] BOOTSTRAP PROTOCOL (BOOTP).
[ RFC 1534] Interoperation Between DHCP and BOOTP.
[ RFC 1542] Clarifications and Extensions for the Bootstrap Protocol.
Obsoletes: RFC 1532.
Updates: RFC 951.
[ RFC 1812] Requirements for IP Version 4 Routers.
[ RFC 2132] DHCP Options and BOOTP Vendor Extensions.
Obsoletes: RFC 1533.
[ RFC 2242] NetWare/IP Domain Name and Information.
Obsolete RFCs:
[ RFC 1048] BOOTP Vendor Information Extensions.
[ RFC 1084] BOOTP Vendor Information Extensions.
Obsoletes: RFC 1048.
[ RFC 1395] BOOTP Vendor Information Extensions.
Obsoletes: RFC 1048, RFC 1084.
Updates: RFC 951.
[ RFC 1497] BOOTP Vendor Information Extensions.
Obsoletes: RFC 1048, RFC 1084, RFC 1395.
Updates: RFC 951.
[ RFC 1532] Clarifications and Extensions for the Bootstrap Protocol.
Updates: RFC 951.
[ RFC 1533] DHCP Options and BOOTP Vendor Extensions.
Obsoletes: RFC 1048, RFC 1084, RFC 1395, RFC 1497.
|
Top of Page
|
| OTHER PROTOCOLS OF TCP/IP SUITE |
|
|
|
|
|
