IPCP is used to negotiate a number of IP parameters at link configuration time. Usually, each peer sends an IPCP Configuration Request packet, indicating which values it wants to change from the defaults and the new value. Upon receipt, the remote end inspects each option in turn and either acknowledges or rejects it.
pppd gives you a lot of control over which IPCP options it will try to negotiate. You can tune it through various command-line options that we will discuss in this section.
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.
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:
remote_addr may be specified either in
dotted quad notation or as hostnames.
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
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
If you want to set only the local address but accept any address the
peer uses, simply leave out the
part. To make vlager use
the IP address 22.214.171.124 instead of
its own, give it
126.96.36.199: 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
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
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
/etc/ppp that is executed by
pppd after the PPP interface has been
configured. When present, it is invoked with the following parameters:
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):
The network interface used, e.g.,
The pathname of the serial device file used (
The speed of the serial device in bits per second
The IP address of the link’s remote end in dotted quad notation
The IP address of the remote end of the link in dotted quad notation
In our case, the ip-up script may contain the following code fragment:
#!/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.
options instruct your pppd to accept the local and remote
IP addresses being offered by the remote PPP, even if you’ve supplied some in
your configuration. If these options are not configured, your
pppd will reject any attempt to negotiate the IP addresses
 If we
wanted to have routes for other sites created when they dial in, we’d
add appropriate case statements to cover those in which the
... appears in the example.