Bootstrapping

BOOTP (Boot Protocol) may be used to boot remote computers over a network. BOOTP messages are encapsulated inside UDP messages and therefore its requests and replies are forwarded by routers. BOOTP is defined by RFCs 951 and 1542. The drawing below illustrates the data encapsulation It is a process when the computers start the first operations - initializes and contains drivers for all interfaces. If the PC is connected to the network, it needs to be configured. The following information will be required IP Address Subnet Mask Default Router Address DNS Address A host can read this information from its internal disk but some devices have no storage. They need help from another device on the network to provide them some information. This problem of getting a new machine up and running is commonly called bootstrapping, and to provide this capability to IP hosts, the TCP/IP Bootstrap Protocol (BOOTP) was created. RARP was the first attempt to resolve this bootstrap problem created in 1984. RARP is capable of providing a diskless device with its IP address, using a simple client-server exchange of a request and reply between a host and an RARP server. The difficulty with RARP are : Operates at a fairly low level using hardware broadcasts, so it requires adjustments for different hardware types. An RARP server is also required on every physical network. RARP only provides an IP address to a host and none of the other information a host may need.

Developed in 1985. It is based on a client/server exchange, but is implemented as a higher-layer software protocol, using UDP for message transport. It is not dependent on the particular hardware of the network like RARP.

It supports sending additional configuration information to a client beyond just an IP address. It can handle having client and server on different networks of an internetwork. The host broadcast BOOTP request message. When BOOTP server receives the request, it searches the database, placed the information in single BOOTP reply message and returns the reply to the requesting computer. Main disadvantage is that manual configuration of tables mapping IP address to MAC address is required. BOOTP messaging uses UDP. Since the client doesn't know the address of a BOOTP server, the request is broadcast on its local network; UDP supports broadcasts while TCP does not. BOOTP servers listen on port 67 for these requests sent by clients. In computer networking, the Bootstrap Protocol, or BOOTP, is a network protocol used by a network client to obtain an IP address from a configuration server. The BOOTP protocol was originally defined in. BOOTP is usually used during the bootstrap process when a computer is starting up. A BOOTP configuration server assigns an IP address to each client from a pool of addresses. BOOTP uses the User Datagram Protocol (UDP) as a transport on IPv4 networks only. Historically, BOOTP has also been used for Unix-like diskless workstations to obtain the network location of their boot image in addition to an IP address, and also by enterprises 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. Recently, users with an interest in diskless stand-alone media center PCs have shown new interest in this method of booting a Windows operating system. The Dynamic Host Configuration Protocol (DHCP) is a more advanced protocol for the same purpose and has superseded the use of BOOTP. Most DHCP servers also function as BOOTP servers. The BOOTP protocol was first defined in RFC 951as a replacement for the Reverse Address Resolution Protocol RARP, published in RFC 903in June 1984. The primary motivation for replacing RARP with BOOTP is that RARP was a data 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 a relay agent, which allowed BOOTP packets to be forwarded from the local network using standard IP routing, so that one central BOOTP server could serve hosts on many subnets.

BOOTP Header Format

OP: Type of Operation HTYPE: Hardware Type HLEN: Length of hardware address HOPS: How many servers forwarded the request. Transaction Identifier: Provides a value that a client can use to determine if an incoming response matches its request. Seconds Elapsed: Total elapsed time since the computer began to boot.

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Hardware address Opcode Hardware type Hop count length Transaction ID Number of seconds Flags Client IP address Wer IP address Server IP address Gateway IP address Client hardware address ::: Server host name ::: Boot filename :::

Opcode. 8 bits.
Value
1 BOOTREQUEST 2 BOOTREPLY

Description
Boot request. Boot reply.

Hardware type. 8 bits.

Value
1) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11) 12) 13) 14) 15) 16) 17) 18) 19) 20) 21) 22) 23) 24) 25) 26) 27) 28)

Description
Ethernet. Experimental Ethernet. Amateur Radio AX.25. Proteon ProNET Token Ring. Chaos. IEEE 802. ARCNET. Hyperchannel. Lanstar. Autonet Short Address. LocalTalk. LocalNet (IBM PCNet or SYTEK LocalNET). Ultra link. SMDS. Frame Relay. ATM, Asynchronous Transmission Mode. HDLC. Fibre Channel. ATM, Asynchronous Transmission Mode. Serial Line. ATM, Asynchronous Transmission Mode. MIL-STD-188-220. Metricom. IEEE 1394.1995. MAPOS. Twinaxial. EUI-64. HIPARP.

Hardware address length. 8 bits. Hop count. 8 bits. Transaction ID. 32 bits.

Number of seconds. 16 bits. The elapsed time, in seconds since the client sent its first BOOTREQUEST message. Flags. 16 bits.
Defined in RFC 1542.

B, Broadcast. 1 bit. Client IP address. 32 bits. Wer IP address. 32 bits. Server IP address. 32 bits. Gateway IP address. 32 bits. Client hardware address. 16 bytes. Server host name. 64 bytes. Boot filename. 128 bytes. Vendor specific info. 64 bytes Bit range
0-7

# of Bits
8

Name
Op code

Description
Tells if the message is a BOOTP request or reply. Request=1, reply=2

8-15

Hardware

Indicates the type of hardware (link level). A value of 6 indicates Ethernet type Tells the length in bytes of the hardware Ethernet addresses are 6 bytes long. Initially set to 0. Incremented each time it is forwarded. A random number set by the client and returned by the server. Used to match replies with requests

16-23

Hardware

23-31 32-63

8 32

Hop count Transaction ID

64-79

16

Number of seconds

The time since the client started trying to bootstrap. Used to tell if a backup BOOTP server should respond.

80-95

16

unused

not used

96-127

32

Clients IP address

The clients IP address. If a request, it is normally 0.0.0.0

128-159

32

IP address For client

The server sets this in the reply message.

160-191

32

Server IP address Gateway IPaddress Clients hardware address

Filled in by the server.

192-223

32

Returned by the server.

224-351

128

Provided by the client.

352-1375

1024

Server hostname

A null terminated string optionally filled in by the server.

1376-3423

2048

Boot filename A fully qualified boot file name with path information, terminated with a null. Supplied by the server. Vendor Information

3424-4447

1024

Used for various options to BOOTP including the subnet mask to the client.

BOOTP

The diskless system reads its unique hardware address from its network interface card then sends a BOOTP request. The table below shows the BOOTP package format from most significant bit to least significant bit. The BOOTP server uses port 67 and the BOOTP client uses port 68. The following is a brief explanation of what happens when a remote client boots: 1) BOOTP request. The client sends a BOOTP request from 0.0.0.0.68 to 255.255.255.255.67 with its ethernet address and number of second's fields filled in. 2) BOOTP reply. The server responds with the client's IP address, the server's IP address (it's own), and the IP address of a default gateway. 3) ARP request. The client issues an ARP to tell if the IP address it just received is being used. It uses 0.0.0.0 as it's own address 4) ARP request. The client waits 0.5 seconds and repeats the same ARP request. 5) ARP request. The client waits another 0.5 seconds and repeats the ARP request with its own address as the senders address. 6) BOOTP request. The client waits 0.5 seconds and sends another BOOTP request with its own IP address in the IP header 7) BOOTP reply. The server sends the same BOOTP reply it sent the last time. 8) ARP request. The client outputs an ARP request for the server hardware address 9) ARP reply. The server replies with its own Ethernet address.

10) TFTP read request. The client sends a TFTP read request asking for its specified boot file. DHCP was designed to replace the older BOOTP BOOTP can only provide an IP to a computer while it is booting while DHCP can provide an IP when the OS is already loaded DHCP is primarily used to seamlessly provide IP addresses to computers while BOOTP is used to configure and boot diskless computers or thin clients BOOTP has a 30 day lease on the IP address as a default while DHCP only sets 8 as a default DHCP can automatically rebind or renew their leases while BOOTP requires a system restart

BOOTP is the Bootstrap Protocol. The BOOTP protocol is utilized by diskless workstations to gather configuration information from a network server.

The information provided by the BOOTP protocol is: The IP address which should be utilized by the diskless workstation The IP address of a server which will provide an Operating System image for the diskless workstation The filename of an Operating System image which the diskless workstation should boot BOOTP workstations are identified by their MAC addresses.

Address Allocation Option 2: BOOTP

A BOOTP server automatically assigns the IP address from a pool of available addresses. By default, the address is leased for 30 days. In its usual mode of operation, a BOOTP server always assigns the same address to a client based on the clients MAC address. BOOTP operation has two phases: Address determination and boot file selection. File transfer (the operating system download). The transfer typically occurs using Trivial File Transfer Protocol (TFTP). The BOOTP server does not need to be the same server as the TFTP image server. In the BOOTP request, the client can include its MAC address (typically held in non-volatile memory on the network card) and any previously bound IP address, if such information has been stored. The BOOTP server can then respond with a particular IP address for the client, based on either the MAC address mapping or the IP address that had been previously assigned. BOOTP requests are network broadcasts; if routers support BOOTP replay, these broadcasts can be passed through routers to other subnets so that a BOOTP server on every subnet is not required. The BOOTP protocol supports a limited number of client configuration parameters called vendor extensions that can be used to provide the client with information, such as default gateway and host name.

Advantages
The advantages of BOOTP include:

Centralized service: BOOTP provides for centralized IP address allocation and

management. A network administrator can configure the BOOTP server, and then any device using BOOTP can connect to this server to get an IP address (and, optionally, an operating system).

Platform support: BOOTP is an established and widely supported protocol. BOOTP

client support is available for most, if not all, operating systems and BOOTP servers are available for Windows, UNIX, mainframe, and other server platforms.

Disadvantages
The disadvantages of BOOTP include:

Renewal on restart only: BOOTP clients rebind or renew their configuration with
the BOOTP server only when the system restarts. This can be a major disadvantage given that BOOTP has default 30-day expiration on IP address leases. An IP address allocation cannot be changed before the 30-day lease has expired unless the client system is rebooted.

No automatic address reuse: BOOTP does not provide automatic reclamation of

unused IP addresses, so it requires a manual method for reclaiming addresses that are no longer in service.

Limited support for dynamic addressing: Addresses are usually fixed, so there is
limited opportunity for address reuse. It is difficult to support a greater number of hosts than there are addresses in the pool because there is typically a one-to-one mapping between host MAC addresses and static IP addresses. This means an IP address is effectively in use all the time, even if the host is not permanently online.

Limited extensions: BOOTP provides for vendor extensions that allow extra
information, such as the address of a DNS server, to be sent to a client from the BOOTP server. However, these extensions are limited to one 64-byte field. RFC 1084 originally standardized these extensions; however, this approach does not allow much customization.

Configuring the BOOTP server

We can use two ways to configure the BOOTP server. Specify the Configure TCP/IP BOOTP (CFGTCPBP) command from the command prompt. Specify the Configure TCP/IP Applications (CFGTCPAPP) command from the command prompt and select option 4 (Configure BOOTP). After we specify the command, the following display appears: Configure TCP/IP BOOTP System: SYSNAM01 Select one of the following: 1. Change BOOTP attributes 2. Work with BOOTP table

We can control the BOOTP server by using the following commands:

With the Change BOOTP Attributes (CHGBPA) command, we can set the configurable attributes for the BOOTP server. With the Work with BOOTP Table (WRKBPTBL) command, we can work with the BOOTP table.

Changing BOOTP attributes

From the Change BOOTP Attributes (CHGBPA) display, we can specify the AUTOSTART attribute. This attribute determines whether the BOOTP server starts automatically when TCP/IP is started by the STRTCP command, or when the STRTCPSVR SERVER (*AUTOSTART) command is issued. To change BOOTP attributes, follow these steps: 1. Specify the Configure TCP/IP BOOTP (CFGTCPBP) command from the command prompt. 2. Select option 1 (Change BOOTP Attributes) on the Configure TCP/IP BOOTP display to view the Change BOOTP Attributes display. We can also type CHGBPA, and then press F4. Note: We must have *IOSYSCFG special authority to make changes to the BOOTP attributes by using the Change BOOTP Attributes (CHGBPA) command. The following display appears.

Change BOOTP Attributes (CHGBPA) Type choices, press Enter. Autostart server . . . . . . . . *YES *YES, *NO, *SAME

Working with the BOOTP table

From the Work with BOOTP Table display, we can add, change, remove, or display an entry in the BOOTP table. To work with BOOTP table, perform the following steps: 1. Specify the Configure TCP/IP BOOTP (CFGTCPBP) command from the command prompt. 2. Select option 2 (Work with BOOTP Table) on the Configure TCP/IP BOOTP display to view the Work with BOOTP Table display. We can also type WRKBPTBL. The following display appears. System i: Networking Bootstrap Protocol

Work with BOOTP Table System: SYSNAM01 Type options, press Enter. 1=Add 2=Change Client Host MAC Opt Name act01.ibm.com 02.01.8C.06.34.98 4=Remove IP Address 9.130.42.1 5=Display

Address

Work with BOOTP Table (WRKBPTBL) display

Using the Rockwell BootP Tool

The 1756-ENET/B module ships with the Rockwell BootP tool. This is a standalone software package that incorporates the functionality of BootP with a user friendly graphical interface. The module must have BootP enabled (factory default) to use this software. To configure our ENET/B module using the Rockwell BootP tool perform the following steps: 1. Start the Rockwell BootP software, BootPSever.exe. Modules on the same subnet issuing BootP requests will appear in the BootP Servers upper window.

2. Select the Hardware Address of the module in the upper window and click on the Down Arrow. The Add Entry window will open.

3. Enter the desired IP Address, Subnet Mask, and Gateway address for the module. Then click on OK. The new configuration will appear in the lower window.

4. Click on Send Disable Bootp Command to permanently save the configuration to the module. Upon re-start the module will use this configuration. It will not issue BootP requests. Note: Clicking on Send Enable Bootp Command will store the configuration in nonpermanent memory. The module will lose the configuration when powered down and issue BootP requests upon re-start. 5. Repeat this procedure for any remaining unconfigured ENET/Bmodules on our network. 6. Exit the BootP Server software (It is not necessary to save our changes).