IPCP is used to negotiate a couple 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 to what value. Upon receipt, the remote end inspects each option in turn and either acknowledges or rejects it.
pppd gives you a lot of control about which IPCP options it will try to negotiate. You can tune this through various command-line options we will discuss below.
In the example above, 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 picked vlager's address as the local IP address, and let c3po provide its own. Sometimes, however, it is useful to have control over what address is used on one or the other end of the link. pppd supports several options for doing this.
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. [7] This option makes pppd attempt to use the first address as its own IP address, and the second as the peer's. If the peer rejects either of them during IPCP negotiation, no IP link will be established. [8]
[7] Using hostnames in this option has consequences for CHAP authentication. Please refer to the section on CHAP in this chapter.
[8] You can allow the peer PPP to override your ideas of IP addresses by giving pppd the ipcp-accept-local and ipcp-accept-remote options.
If you want to set only the local address but accept any address the peer uses, you simply leave out the remote_addr part. For instance, to make vlager use the IP address 130.83.4.27 instead of its own, you would give it 130.83.4.27: on the command line. Similarly, to set the remote address only, you would leave the local_addr field blank. By default, pppd will then use the address associated with your hostname.
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. When dialing up such a server, you must make sure that pppd doesn't request any particular IP address from the server but rather accepts the address the server asks you to use. This means that you mustn't specify a local_addr argument. In addition, you have to use the noipdefault option, which makes pppd wait for the peer to provide the IP address instead of using the local host's address.
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; that is, a network route must be set up.
We have already seen above 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 will act as your Internet gateway.
The reverse case, where 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 loner. When connecting to vlager through PPP, he uses an address on the Brewery's subnet. At vlager, we can now give pppd the proxyarp option, which will install a proxy ARP entry for loner. This will automatically make loner accessible from all hosts at the Brewery and the Winery.
However, things aren't always as easy as that. For instance, 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, where packets to unknown destinations would ping-pong between the peers until their time to live expired.
As an example, suppose the Virtual Brewery opens a branch in some other 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 main Ethernet via PPP to update customer databases, etc. Again, vlager acts as the gateway; its peer is called sub-etha and has an IP address of 172.16.3.1.
When sub-etha connects to vlager, it makes the default route point to vlager as usual. On vlager, however, we will have to install a network route for subnet 3 that goes through sub-etha. For this, we use a feature of pppd not discussed so far--the ip-up command. This is a shell script or program located in /etc/ppp that is executed 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
iface names the network interface used, device is the pathname of the serial device file used (/dev/tty if stdin/stdout are used), and speed is the device's speed. local_addr and remote_addr give the IP addresses used at both ends 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 sub-etha
route add -net 172.16.3.0 gw 172.16.3.1;;
...
esac
exit 0
In a similar fashion, /etc/ppp/ip-down is used to undo all actions of ip-up after the PPP link has been taken down again.
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 sub-etha, and all Brewery hosts route to vlager by default. If this is not the case, your only option will usually be to use a routing daemon like gated. After creating the network route on vlager, the routing daemon would broadcast the new route to all hosts on the attached subnets.
Link Control Options
Debugging Your PPP Setup
