All IP interfaces require IP addresses assigned to them; a PPP device always has an IP address. The PPP suite of protocols provides a mechanism that allows the automatic assignment of IP addresses to PPP interfaces. It is possible for the PPP program at one end of a point-to-point link to assign an IP address for the remote end to use, or each may use its own.

Some PPP servers that handle a lot of client sites assign addresses dynamically; addresses are assigned to systems only when calling in and are reclaimed after they have logged off again. This allows the number of IP addresses required to be limited to the number of dialup lines. While limitation is convenient for managers of the PPP dialup server, it is often less convenient for users who are dialing in. We discussed the way that hostnames are mapped to IP addresses by use of a database in Chapter 6. In order for people to connect to your host, they must know your IP address or the hostname associated with it. If you are a user of a PPP service that assigns you an IP address dynamically, this knowledge is difficult without providing some means of allowing the DNS database to be updated after you are assigned an IP address. Such systems do exist, but we won’t cover them in detail here; instead, we will look at the more preferable approach, which involves you being able to use the same IP address each time you establish your network connection.^[51]

In the previous example, we had pppd dial up c3po and establish an IP link. No provisions were taken to choose a particular IP address on either end of the link. Instead, we let pppd take its default action. It attempts to resolve the local hostname, vlager in our example, to an IP address, which it uses for the local end, while letting the remote machine, c3po, provide its own. PPP supports several alternatives to this arrangement.

To ask for particular addresses, you generally provide pppd with the following option:

                  local_addr:remote_addr

local_addr and remote_addr may be specified either in dotted quad notation or as hostnames.^[52] This option makes pppd attempt to use the first address supplied as its own IP address, and the second as the peer’s. If the peer rejects either of the addresses during IPCP negotiation, no IP link will be established.^[53]

If you are dialing in to a server and expect it to assign you an IP address, you should ensure that pppd does not attempt to negotiate one for itself. To do this, use the noipdefault option and leave the local_addr blank. The noipdefault option will stop pppd from trying to use the IP address associated with the hostname as the local address.

If you want to set only the local address but accept any address the peer uses, simply leave out the remote_addr part. To make vlager use the IP address 130.83.4.27 instead of its own, give it 130.83.4.27: on the command line. Similarly, to set the remote address only, leave the local_addr field blank. By default, pppd will then use the address associated with your hostname.

After setting up the network interface, pppd will usually set up a host route to its peer only. If the remote host is on a LAN, you certainly want to be able to connect to hosts “behind” your peer as well; in that case, a network route must be set up.

We have already seen that pppd can be asked to set the default route using the defaultroute option. This option is very useful if the PPP server you dialed up acts as your Internet gateway.

The reverse case, in which your system acts as a gateway for a single host, is also relatively easy to accomplish. For example, take some employee at the Virtual Brewery whose home machine is called oneshot. Let’s also assume that we’ve configured vlager as a dialin PPP server. If we’ve configured vlager to dynamically assign an IP address that belongs to the Brewery’s subnet, then we can use the proxyarp option with pppd, which will install a proxy ARP entry for oneshot. This automatically makes oneshot accessible from all hosts at the Brewery and the Winery.

However, things aren’t always that simple. Linking two local area networks usually requires adding a specific network route because these networks may have their own default routes. Besides, having both peers use the PPP link as the default route would generate a loop, through which packets to unknown destinations would ping-pong between the peers until their time to live expired.

Suppose the Virtual Brewery opens a branch in another city. The subsidiary runs an Ethernet of its own using the IP network number 172.16.3.0, which is subnet 3 of the Brewery’s class B network. The subsidiary wants to connect to the Brewery’s network via PPP to update customer databases. Again, vlager acts as the gateway for the brewery network and will support the PPP link; its peer at the new branch is called vbourbon and has an IP address of 172.16.3.1. This network is illustrated in Figure 1.2 in Appendix A.

When vbourbon connects to vlager, it makes the default route point to vlager as usual. On vlager, however, we will have only the point-to-point route to vbourbon and will have to specially configure a network route for subnet 3 that uses vbourbon as its gateway. We could do this manually using the route command by hand after the PPP link is established, but this is not a very practical solution. Fortunately, we can configure the route automatically by using a feature of pppd that we haven’t discussed yet—the ip-up command. This command is a shell script or program located in /etc/ppp that is executed by pppd after the PPP interface has been configured. When present, it is invoked with the following parameters:

ip-up iface 
                  device 
                  speed 
                  local_addr 
                  remote_addr

The following table summarizes the meaning of each of the arguments (in the first column, we show the number used by the shell script to refer to each argument):

In our case, the ip-up script may contain the following code fragment:^[54]

#!/bin/sh
case $5 in
172.16.3.1)            # this is vbourbon
        route add -net 172.16.3.0 gw 172.16.3.1;;
...
esac
exit 0

Similarly, /etc/ppp/ip-down can be used to undo any actions of ip-up after the PPP link has been taken down again. So in our /etc/ppp/ip-down script we would have a route command that removed the route we created in the /etc/ppp/ip-up script.

However, the routing scheme is not yet complete. We have set up routing table entries on both PPP hosts, but so far none of the hosts on either network knows anything about the PPP link. This is not a big problem if all hosts at the subsidiary have their default route pointing at vbourbon, and all Brewery hosts route to vlager by default. If this is not the case, your only option is usually to use a routing daemon like gated. After creating the network route on vlager, the routing daemon broadcasts the new route to all hosts on the attached subnets.