This article needs additional citations for verification. (July 2013) (Learn how and when to remove this template message)
The Bootstrap Protocol (BOOTP) is a computer networking protocol used in Internet Protocol networks to automatically assign an IP address to network devices from a configuration server. The BOOTP was originally defined in RFC 951.
When a computer that is connected to a network is powered up and boots its operating system, the system software broadcasts BOOTP messages onto the network to request an IP address assignment. A BOOTP configuration server assigns an IP address based on the request from a pool of addresses configured by an administrator.
BOOTP is implemented using the User Datagram Protocol (UDP) as transport protocol, port number 67 is used by the (DHCP) server to receive client requests and port number 68 is used by the client to receive (DHCP) server responses. BOOTP operates only on IPv4 networks.
Historically, BOOTP has also been used for Unix-like diskless workstations to obtain the network location of their boot image, in addition to the IP address assignment. Enterprises used it to roll out a pre-configured client (e.g., Windows) installation to newly installed PCs.
Originally requiring the use of a boot floppy disk to establish the initial network connection, manufacturers of network cards later embedded the protocol in the BIOS of the interface cards as well as system boards with on-board network adapters, thus allowing direct network booting.
While some parts of BOOTP have been effectively superseded by the Dynamic Host Configuration Protocol (DHCP), which adds the feature of leases, parts of BOOTP are used to provide service to the DHCP protocol. DHCP servers also provide the legacy BOOTP functionality.
The BOOTP was first defined in September 1985 in RFC 951 as a replacement for the Reverse Address Resolution Protocol RARP, published in RFC 903 in June 1984. The primary motivation for replacing RARP with BOOTP is that RARP was a link layer protocol. This made implementation difficult on many server platforms, and required that a server be present on each individual IP subnet. BOOTP introduced the innovation of relay agents, which forwarded BOOTP packets from the local network using standard IP routing, so that one central BOOTP server could serve hosts on many subnets.
Case 1 : Client and server on same network
- The bootp server issues a passive open command on UDP port 67 and waits for client.
- The booted client issues active open command on port 68.This message is encapsulated in UDP user data-gram which in turn is encapsulated in IP data-gram. Client uses all 0's as source address and all 1's as destination address.
- The server now knows physical and IP address of the client. The server responds with either a broadcast or unicast UDP message with a source port of 67 and a destination port of 68.
Case 2 : Client and server on different networks
- Problem with the bootp request is that the request is broadcast. A broadcast IP data-gram cannot pass through any router. The router discards this packet.
- To solve this problem there is a need for an intermediary (relay).
- One of the host or router can be configured at application layer to operate as relay agent.
- The relay agent knows the uni-cast address of bootp server and listens for broadcast message on port 67.
- When it receives this broadcast packet, it encapsulates the message in uni-cast data-gram and sends request to bootp server.
- The packet carrying a uni-cast destination address is routed by any router and reaches the bootp server.
- The relay agent after receiving the reply, sends it to bootp client.
IETF standards documentationEdit
|RFC #||Title||Date||Obsolete and Update Information|
|RFC 3942||Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options||Nov-04||Updates RFC 2132|
|RFC 2132||DHCP Options and BOOTP Vendor Extensions||Mar-97||Obsoletes RFC 1533, Updated by RFC 3442, RFC 3942, RFC 4361, RFC 4833, RFC 5494|
|RFC 1542||Clarifications and Extensions for the Bootstrap Protocol||Oct-93||Obsoletes RFC 1532, Updates RFC 951|
|RFC 1534||Interoperation Between DHCP and BOOTP||Oct-93|
|RFC 1533||DHCP Options and BOOTP Vendor Extensions||Oct-93||Obsoletes RFC 1497, RFC 1395, RFC 1084, RFC 1048, Obsoleted by RFC 2132|
|RFC 1532||Clarifications and Extensions for the Bootstrap Protocol||Oct-93||Obsoleted by RFC 1542, Updates RFC 951|
|RFC 1497||BOOTP Vendor Information Extensions||Aug-93||Obsoletes RFC 1395, RFC 1084, RFC 1048, Obsoleted by RFC 1533, Updates RFC 951|
|RFC 1395||BOOTP Vendor Information Extensions||Jan-93||Obsoletes RFC 1084, RFC 1048, Obsoleted by RFC 1497, RFC 1533, Updates RFC 951|
|RFC 1084||BOOTP vendor information extensions||Dec-88||Obsoletes RFC 1048, Obsoleted by RFC 1395, RFC 1497, RFC 1533|
|RFC 1048||BOOTP vendor information extensions||Feb-88||Obsoleted by RFC 1084, RFC 1395, RFC 1497, RFC 1533|
|RFC 951||Bootstrap Protocol||Sep-85||Updated by RFC 1395, RFC 1497, RFC 1532, RFC 1542, RFC 5494|