Notes On Chapter Forty-One -- Initialization (Configuration)

• 41.1 Introduction
  
  
  • This chapter is about how protocol software gets started as a host or router boots up.
  
  
• 41.2 Bootstrapping Protocol Software
  
  
  • Typically a computer executes a ROM boot sequence when you turn it on.
    
    
  • The ROM program loads a bootstrap program from a known location on disk.
    
    
  • The computer executes the bootstrap program.
    
    
  • The bootstrap program loads the operating system and the computer then starts executing the operating system.
  
  
• 41.3 Protocol Parameters
  
  
  • Protocol software is generic. Something has to pass it specific parameters when it starts up. Parameters are things like the host MAC and IP addresses, and the network mask.
  
  
• 41.4 Protocol Configurations
  
  
  • Protocol configuration is the giving of values to the parameters of the protocols.
    
    
  • There are different ways to do it.
    
    
  • In order to boot successfully sometimes a system has to use the network before the protocol software is fully configured. The system uses partially configured software to obtain information it needs to complete the configuration. (It has to lift itself with its own bootstraps -- this illustrates how the term "boot" originated.)
  
  
• 41.5 Examples of Items That Need To Be Configured
  
  
  What is needed varies with the protocol. Typically TCP/IP needs:
  
  
  • Host IP address(es)
    
    
  • Default router IP address
    
    
  • Subnet mask(s)
    
    
  • DNS server IP address(es)
  
  
• 41.6 Configuration From Stable Storage
  
  
  • If a system boots off a hard disk then usually much of the protocol configuration information will be stored in one or more files on disk
    
    
  • The booting system will read the information, transform into the appropriate internal form, and store.
    
    
  • If this information is changed, it may be possible to signal the OS to reread it. Sometimes a reboot is required - or at least is the preferred method.
    
    
  • (Examples of configurations files in folder /private/etc on Macs: hostconfig, resolv.conf, hosts, hosts.equiv, hosts.lpd, inetd.conf, networks, protocols, services, and probably others; in directory /etc on Suns: defaultdomain, defaultrouter, hostname.hme0, hosts, hosts.allow, host.deny, hosts.equiv, inted.conf, netconfig, nodename, resolv.conf, and probably others.)
    
    
  • The reader should bear in mind that when a network information database such as netinfo, NIS+, or LDAP is in use the information in the files may be used only as a backup to information that hosts obtain through queries to the distributed database.
  
  
• 41.7 The Need To Automate Protocol Configuration
  
  
  • When there are large numbers of computers to administrate it can become a challenge to keep all the configuration files updated with the right information.
    
    
  • Portable computers are a special challenge in this regard because users move them from one network to another.
  
  
• 41.8 Methods For Automated Protocol Configuration
  
  
  • A booting host can "ask the network" for a bootstrap program.
    
    
  • A host that does not know its own IP address can use Reverse Address Resolution Protocol (RARP) to get the information from a server. (It broadcasts its MAC address and receives a reply from a server.)
    
    
  • A host can broadcast an ICMP Router Discovery message to get the address of a router.
    
    
  • It can then send an ICMP Address Mask Request to the router. (It is also possible for a host to broadcast an Address Mask Request.)
    
    
  • It may take a lot less administrator work to set up the servers that furnish the BOOTP, RARP, and ICMP information if the only alternative is to put copies of the information in files on each host.
  
  
• 41.9 The Address Used To Find An Address
  
  
  • The configuring of the protocol software can be done in layers from lowest to highest. Higher layers can use the functionality of lower layers to obtain (some of ) their configuration information.
  
  
• 41.10 A Sequence Of Protocols Used During Bootstrap
  
  
  1. Broadcast a RARP Request message to obtain an IP address
     
     
  2. Wait for a RARP Response message. If none arrives within T₁ seconds, return to step 1.
     
     
  3. Broadcast an ICMP Address Mask Request message.
     
     
  4. Wait for an ICMP Address Mask Response message. If none arrives within T₂ seconds, return to step 3.
     
     
  5. Use ICMP Gateway Discovery to find the IP address of a default router, and add a default route to the routing table.
  
  
• 41.11 Bootstrap Protocol (BOOTP)
  
  
  • BOOTP is a newer protocol which a host can use to get all the RARP and ICMP information mentioned above -- and more -- with just one request.
    
    
  • The requesting host uses the IP broadcast destination address (255.255.255.255) in the request packet and uses all zero's (0.0.0.0 - meaning "me") for the source address.
    
    
  • A server answers. It may broadcast the answer or use the hardware address that arrived in the request packet to designate the recipient.
    
    
  • The format of the BOOTP packet and an explanation of most fields appears on pages 629-630 of the fourth edition (figure reproduced here).
    
    
  • Things the client can learn with BOOTP:
    • Its IP address
    • the IP address of a server machine
    • the IP address of a router
    • the host name of a server machine
    • a path name for a boot file (which can be downloaded afterwards with TFTP).
  
  
• 41.12 Dynamic Host Configuration Protocol (DHCP)
  
  
  • A computer C can't use BOOTP unless someone has entered information about C into a server database in advance.
    
    
  • DHCP can allow a "complete stranger" to join a network.
    
    
  • The booting client broadcasts a DHCP request and a DHCP server responds.
    
    
  • The DHCP server has a pool of IP addresses. DHCP can give an address from the pool to a "stranger."
    
    
  • DHCP can also accommodate a "server computer" that needs to have a fixed IP address. The "server computer" must be registered with the DHCP server. The DHCP server will recognize the "server computer" by its hardware address, and give it the particular IP address associated with that hardware address.
    
    
  • The DHCP server can refuse to extend the lease on an IP address it has assigned.
  
  
• 41.13 Optimizations in DHCP
  
  
  • After a power excursion a large number of computers may boot at about the same time. This could overwhelm the DHCP server.
    
    
  • Clients wait a random time before making their DHCP request. This helps alleviate possible swamping of DHCP servers.
    
    
  • The client actually sends a "discover" broadcast to find a DHCP server. The client picks one of the DHCP server(s) that replies to the client. The client then sends its request for protocol configuration information to that server.
    
    
  • A client may cache the identity of the DHCP server that responded to it. Also the client may cache the IP address it received from the server. When rebooting, the client may simply try to revalidate its former IP address with its former server.
  
  
• 41.14 Indirect Server Access Through A Relay
  
  
  • DHCP can work for a client X even if there is no DHCP server on X's network
    
    
  • If a relay agent is present on X's network, configured with the IP address of a DHCP server, it will forward the request to the server using unicast and relay the reply to the client.
    
    
  • It is relatively simple to manage one or a few centralized DHCP servers and a multiplicity of relay agents.
    
    
  • Many commercial routers are easy to configure as relay agents.
  
  
• 41.15 DHCP Message Format
  
  
  • The DHCP message and protocol is not much different from BOOTP.
    
    
  • See page 633 of the fourth edition for details (figure reproduced here).
  
  
• 41.16 DHCP And Domain Names
  
  
  • If a computer is not registered with the DHCP server then it may get different IP addresses when it boots at different times. It will be "hard" for such a computer to keep the same domain name across reboots.
    
    
  • To ameliorate that situation, there is a protocol which would allow DHCP to "talk to" DNS to notify DNS of the change in mapping between IP address and domain name. However, that protocol has not been widely deployed.
    
    
  • If we want a set of computers to have fixed IP addresses and domain names under DHCP, then it helps to have them all registered with DHCP.
    
    
  • However if the computers are registered by hardware address, we have to change the DHCP database each time we introduce a new hardware address. This happens when we change the NIC of an existing computer, or when we add a new computer to the network.
  
  
• 41.17 Summary