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.[1]
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 and
remote_addr may be specified either in
dotted quad notation or as hostnames.[2]
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.[3]
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 A-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:[4]
#!/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.
