Dynamic Allocation

One thing that automatic allocation doesn’t define is a way to reclaim addresses that are no longer in use. Reclaiming addresses is essential in networks that have more potential hosts than available IP addresses. For example, the hosts connected to an ISP at any one time will vary as different customers go on and off line. If the ISP assigns a permanent, or static, address to every computer that connects, it will eventually run out of addresses, even if only a few customers connect at once. A solution is to use dynamic allocation, which reclaims IP addresses that are no longer in use. As with automatic allocation, in dynamic allocation, the DHCP server begins with a list of available IP addresses and returns addresses in response to DHCPDISCOVER messages. But instead of assigning a permanent address, the server leases the address to the client for a specified time. To keep an address, the client must periodically send a request to renew the lease. If the client disconnects from the network or for any other reason fails to renew its lease, the server is free to assign the address to another computer.

A client may request an infinite lease or suggest a lease time, but servers aren’t required to comply with these requests. The lease time is a 32-bit value in seconds, with FFFFFFFFh indicating an infinite lease. On receiving a request for an IP address, a DHCP server uses the previously assigned address for that host if available. A computer can also request a specific IP address. But with dynamic allocation, there is no guarantee that a request for an IP address will return a specific value. For some small embedded systems, it may be easier to store a static IP address in firmware. The DHCP server must then be configured to reserve this address. Each network may have its own DHCP server, or multiple networks may use relay agents to share a DHCP server. A relay agent accepts DHCPDISCOVER messages from hosts in a network and sends the messages to a DHCP server. The server replies to the relay agent, which then sends the message to the host that requested it. In a network that has a NAT router that connects to a cable modem or DSL modem, the router typically can function as a DHCP server for the local network and as a DHCP client for the public network. The server can assign addresses to the hosts in the local network. The client enables the router to request an IP address from a DHCP server at the ISP. Windows XP can function as a DHCP client for a server at an ISP or other location. Using Internet Connection Sharing, Windows XP can function as a DHCP server that assigns IP addresses to computers in a local network.

Considerations when Using Dynamic IP Addresses

When a domain’s IP address changes, the DHCP server or other entity that changed the address must send an updated resource record to the domain’s name servers. If your ISP uses DHCP in assigning your network’s public IP address and your embedded system has a domain name, you’ll need to update the domain’s name servers when the system’s IP address changes. A way to achieve this is by using a service that handles the updates automatically. One provider of this service is Tzolkin Corporation (www.tzo.com).

To use Tzolkin’s service with an embedded system, you’ll need a PC in the same local network as the embedded system, and both computers must share a public IP address (using a NAT router as described earlier). At the registrar where you registered the domain, you must change the registration to indicate that Tzolkin’s name servers are the name servers for your domain. On a PC that shares the embedded system’s public IP address, run Tzolkin’s application, which monitors the PC’s current public IP address. When the address changes, the application automatically informs the name servers of the change. For best results, the PC running the Tzolkin application should be on line all of the time.

Matching an IP Address to an Ethernet Interface

Every IP datagram must include the IP address of its destination. A host can use a variety of ways to learn the IP address of a destination the host wants to communicate with. A network administrator can provide each host with the IP addresses the host will communicate with. The hosts will need a way to update their lists when a host is added, removed, or changes its address, but if changes are rare, the updates can be done manually. Some computers only need to reply to received communications using the source address in received datagrams. For example, a host that functions as a Web server that sends Web pages on request only needs to respond to received requests that include the IP address to reply to. A host that wants to request a Web page or other resource or send other communications over the Internet must know the destination’s IP address. As described earlier in this networking tutorial, if a host knows only the domain name, a name resolver can query name servers to learn the IP address that corresponds to the domain name.

Using ARP

In a local network, the Address Resolution Protocol (ARP) can match an IP address with the Ethernet hardware address of the computer with that IP address. The document that defines ARP is RFC 0826: An Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware, also available as standards-track document STD0037. To learn the Ethernet hardware address that corresponds to an IP address, a host broadcasts an Ethernet frame containing an ARP packet. In the Ethernet header, the Type field contains 0806h, which indicates that the frame is carrying an ARP message. The destination address is all ones or a broadcast address for a specific network or subnet. In a similar way, a computer can broadcast a RARP (reverse ARP) request to learn the IP address that corresponds to a hardware address, including the computer’s own IP address. RARP is defined in RFC0903: A Reverse Address Resolution Protocol, also available as standards-track document STD0038. In Chapter 1, Network article 1-5 showed an example ARP request captured with the Ethereal Ethernet analyzer.

How a Datagram Finds Its Way to Its Destination

When a host wants to send a message and knows the IP address of its destination, it’s ready to send the IP datagram on the network. But how does the datagram find its way to its destination? The IP address contains no information about the physical location of the destination.

Direct Routing

Messages whose destination is within the local subnet, or within the local network when there is no subnet, use direct routing. In direct routing in an Ethernet network, the originating host sends an IP datagram in an Ethernet frame that contains the destination’s Ethernet hardware address, as described in Chapter 1. The originating host uses ARP if needed to learn the destination’s hardware address. Within an Ethernet network, hosts connected by repeater hubs receive all valid frames sent by any of the hosts. An Ethernet switch forwards frames to a specific port if possible, and otherwise forwards the frame to all of the switch’s ports.

Indirect Routing

Messages whose destination is outside the local subnet or network use indirect routing. With indirect routing, a designated default router accepts messages destined for outside the local subnet or network. An Ethernet network that connects to the Internet should have a default router for messages whose destination is outside the local network. For example, if a computer in an Ethernet network wants to send a message on the Internet, the computer places the message in an IP datagram in an Ethernet frame. The destination address in the Ethernet frame is the default router’s hardware address. The default router uses the destination address in the IP datagram to decide where to forward the datagram. To decide where to forward the datagram, the router first checks its internal forwarding table for a matching IP address. Each entry in the table has the IP address of the router that is the next hop, or the next router on the way, for datagrams going to a specific address, network, or subnet. A router builds its forwarding table by saving entries containing the source address of received datagrams and the router port that the datagram arrived on. To ensure that there’s room for new entries, each entry has a timeout and is removed on timing out. Of course, no forwarding table will contain an entry that matches every received destination address, if only because a router may begin with no entries other than a default router. On receiving a datagram with a destination address that isn’t in the forwarding table, the router sends the datagram to another router designated as the first router’s default router. In a similar way, the router that receives the datagram looks for a match in its forwarding table and sends the segment on either to a destination found in its forwarding table or to another default router. An IP datagram may travel through a number of routers on the way to its destination. The source may have no way of knowing the maximum size of datagrams the routers or the destination can accept. If a datagram is too large for its destination, a router may send the data payload in multiple, smaller datagrams, with a portion, or fragment, of the data in each. On receiving the datagrams, the destination uses information in the IP header to put the fragments back together.