The Illustrated Network- P51:In this chapter, you will learn about the protocol stack used on the global public Internet and how these protocols have been evolving in today’s world. We’ll review some key basic defi nitions and see the network used to illustrate all of the examples in this book, as well as the packet content, the role that hosts and routers play on the network, and how graphic user and command line interfaces (GUI and CLI, respectively) both are used to interact with devices. | CHAPTER 18 Dynamic Host Configuration Protocol 469 LAN FIGURE BOOTP and TFTP servers showing the ports used by the servers and client. BOOTP Implementation Diskless workstations never became a popular line and most users saw them as a return to the bad old days of dumb terminals and considered a full-blooded PC on the desktop as a sign of status. And soon enough the cost differential for diskless devices as opposed to full-fledged workstations or desktops shrunk to zero and then went negative. Applications for devices with no local storage still exist but there is no cost benefit associated with them. Once almost all PCs began to ship with minimal hard disks it became more common to split the boot server functions between two separate servers. The boot server still listened on UDP port 67 for client broadcast requests sent on port 68 and this was usually all PCs needed. But for truly diskless devices one or more TFTP servers provided the files needed for further operation usually separated by type. This arrangement is shown in Figure . BOOTP was very flexible. Clients could start with some or no information accept any boot server or pick a particular one and use no file a default or a specific download file. BOOTP Messages All BOOTP requests and replies are sent as 300-byte UDP messages. These are shown in Figure . Fields shown in bold must be filled in for a BOOTP request and those in italic represent optional information supplied by the client. Opcode This byte is set to 1 for a request and 2 for a reply. Hardware Type This byte is set to 1 for Ethernet and uses the same values as the hardware type field in an ARP message. 470 PART IV Application Level 1 byte 1 byte 1 byte 1 byte Opcode 1 request 2 reply Hardware Type Length of Hardware Address Hop Counter initially 0 Transaction ID used to match request and reply Seconds Elapsed since Client Sent First Request Message Unused Client IP Address if known to Client otherwise all 0 Client IP Address .
