Chapter 15 Solaris PPP 4.0
(Overview)

This section covers serial networking topics. Serial networking refers
to the use of a serial interface, such as an RS-232 or V.35 port, to connect
two or more computers for data transfer. Unlike LAN interfaces, such as Ethernet,
these serial interfaces are used to connect systems that are separated by
large distances. PPP (Point-to-Point Protocol) and UUCP (UNIX-to-UNIX CoPy)
are distinct technologies that can be used to implement serial networking.
When a serial interface is configured for networking, it is made available
for multiple users, in much the same way as any other network interface, such
as Ethernet.

This chapter introduces Solaris PPP 4.0. This version of PPP enables
two computers in different physical locations to communicate with each other
by using PPP over a variety of media. Starting with the Solaris 9 release,
Solaris PPP 4.0 is included as part of the base installation.

Solaris PPP 4.0 Basics

Solaris PPP
4.0 implements the Point-to-Point Protocol (PPP), a data link protocol, which
is a member of the TCP/IP protocol suite. PPP describes how data is transmitted
between two endpoint machines, over communications media such as telephone
lines.

Since the early 1990s, PPP has been a widely used Internet standard
for sending datagrams over a communications link. The PPP standard is described
in RFC 1661 by the Point-to-Point Working Group of the Internet Engineering
Task Force (IETF). PPP is commonly used when remote computers call an Internet
service provider (ISP) or a corporate server that is configured to receive
incoming calls.

Solaris PPP 4.0 is based on the publicly available Australian National
University (ANU) PPP–2.4 and implements the PPP standard. Both asynchronous
and synchronous PPP links are supported.

Solaris PPP 4.0 Compatibility

Various
versions of standard PPP are available and in wide use throughout the Internet
community. ANU PPP-2.4 is a popular choice for Linux, Tru64 UNIX,and all three
major BSD variants:

FreeBSD

OpenBSD

NetBSD

Solaris PPP 4.0 brings the highly configurable features of ANU
PPP-2.4 to machines that run the Solaris operating system. Machines that run
Solaris PPP 4.0 can easily set up PPP links to any machine that runs an implementation
of standard PPP.

Some non-ANU-based PPP implementations that successfully interoperate
with Solaris PPP 4.0 include the following:

Solaris PPP, also known as asppp, available
with the Solaris 2.4 through Solaris 8 releases

SolsticeTM PPP 3.0.1

Microsoft Windows 98 DUN

Cisco IOS 12.0 (synchronous)

Which Version of Solaris PPP to Use

Starting with the Solaris
9 release, Solaris PPP 4.0 is the PPP implementation that is supported. The
Solaris 9 release and the Solaris 10 release do not include the earlier Asynchronous
Solaris PPP (asppp) software. For more information, refer
to the following:

Setting up asppp requires configuring the asppp.cf configuration file, three UUCP files, and the ifconfig command.
Moreover, you have to preconfigure interfaces for all users who might log
in to a machine.

Setting up Solaris PPP 4.0 requires defining options for the PPP configuration
files, or issuing the pppd command with options. You can
also use a combination of both the configuration file and command-line methods.
Solaris PPP dynamically creates and removes interfaces. You do not have to
directly configure PPP interfaces for each user.

Solaris PPP 4.0 features not available
from asppp

MS-CHAPv1 and MS-CHAPv2 authentication

PPP over Ethernet (PPPoE), to support ADSL bridges

PAM authentication

Plug-in modules

IPv6 addressing

Data compression that uses Deflate or BSD compress

Microsoft client-side callback support

Solaris PPP 4.0 Upgrade Path

If you are converting an existing asppp configuration
to Solaris PPP 4.0, you can use the translation script that is provided with
this release. For complete instructions, refer to How to Convert From asppp to Solaris PPP 4.0.

Where to Go for More Information About
PPP

Many resources with information about PPP can be found in print
and online. The following subsections give some suggestions.

Professional Reference Books About
PPP

For more information about widely used PPP implementations, including
ANU PPP, refer to the following books:

Man Pages About PPP

Also, see the man page for pppdump(1M). You can find
the PPP-related man pages by using the man command.

PPP Configurations and Terminology

This section introduces PPP configurations. The section also defines
terms that are used in this guide.

Solaris PPP 4.0 supports a number of configurations.

Switched-access, or dial-up, configurations

Hardwired, or leased-line configurations

Figure 15–1 Parts of the PPP Link

The previous figure shows a basic PPP link. The
link has the following parts:

Two machines, usually in separate physical locations, called peers. A peer could be a personal computer, engineering workstation,
large server, or even a commercial router, depending on a site's requirements.

Serial interface on each peer. On Solaris machines, this interface
could be cua, hihp, or other interface,
depending on whether you configure asynchronous or synchronous PPP.

Physical link, such as a serial cable, a
modem connection, or a leased line from a network provider, such as a T1 or
T3 line.

Dial-up PPP Overview

The most commonly used PPP configuration is the dial-up
link. In a dial-up link, the local peer dials up the
remote peer to establish the connection and run PPP. In the dial-up process,
the local peer calls the remote peer's telephone number to initiate the link.

A common dial-up scenario includes a home computer that calls a peer
at an ISP, configured to receive incoming calls. Another scenario is a corporate
site where a local machine transmits data over a PPP link to a peer in another
building.

In this guide, the local peer that initiates the dial-up connection
is referred to as the dial-out machine. The peer that
receives the incoming call is referred to as the dial-in server.
This machine is actually the target peer of the dial-out machine and might
or might not be a true server.

PPP is not a client-server protocol. Some PPP documents use the terms “client”
and “server” to refer to telephone call establishment. A dial-in
server is not a true server like a file server or name server. Dial-in server
is a widely used PPP term because dial-in machines often “serve”
network accessibility to more than one dial-out machine. Nevertheless, the
dial-in server is the target peer of the dial-out machine.

Parts of the Dial-up PPP Link

See the following figure.

Figure 15–2 Basic Analog Dial-up PPP Link

The configuration for Location 1, the dial-out side of the link, is
composed of the following elements:

Dial-out machine, typically a personal computer or workstation
in an individual's home.

Serial interface on the
dial-out machine. /dev/cua/a or /dev/cua/b is
the standard serial interface for outgoing calls on machines that run Solaris
software.

Asynchronous modem or ISDN terminal adapter (TA) that is connected
to a telephone jack.

Telephone lines and services of a telephone company.

The configuration for Location 2, the dial-in side of the link, is composed
of the following elements:

Telephone jack or similar connector, which is connected to
the telephone network

Asynchronous modem or ISDN TA

Serial interface on the dial-in
server, either ttya or ttyb for incoming
calls

Dial-in server, which is connected to a network, such as a
corporate intranet, or, in the instance of an ISP, the global Internet

Using ISDN Terminal Adapters With
a Dial-out Machine

External
ISDN TAs have faster speeds than modems, but you configure TAs in basically
the same way. The major difference in configuring an ISDN TA is in the chat
script, which requires commands specific to the TA's manufacturer. Refer to Chat Script for External ISDN TA for
information about chat scripts for ISDN TAs.

What Happens During Dial-up Communications

PPP configuration files on both the dial-out and dial-in peers
contain instructions for setting up the link. The following process occurs
as the dial-up link is initiated.

User or process on the dial-out machine runs the pppd command
to start the link.

Dial-out machine reads its PPP configuration files. The dial-out
machine then sends instructions over the serial line to its modem, including
the phone number of the dial-in server.

Modem dials the phone number to establish a telephone connection
with the modem on the dial-in server.

The series of text strings
that the dial-out machine sends to the modem and dial-in server are contained
in a file called a chat script. If necessary, the dial-out
machine sends commands to the dial-in server to invoke PPP on the server.

Modem attached to the dial-in server begins link negotiation
with the modem on the dial-out machine.

When modem-to-modem negotiation is completed, the modem on
the dial-out machine reports “CONNECT.”

PPP on both peers enters Establish phase,
where Link Control Protocol (LCP) negotiates basic link parameters and the
use of authentication.

If necessary, the peers authenticate each other.

PPP's Network Control Protocols (NCPs) negotiate the use of
network protocols, such as IPv4 or IPv6.

The dial-out machine can then run telnet or a similar
command to a host that is reachable through the dial-in server.

Leased-Line PPP Overview

A hardwired, leased-line PPP configuration involves two peers that are connected by a link.
This link consists of a switched or an unswitched digital service leased from
a provider. Solaris PPP 4.0 works over any full-duplex, point-to-point leased-line
medium. Typically, a company rents a hardwired link from a network provider
to connect to an ISP or other remote site.

Comparison of Dial-up and Leased-Line
Links

Both dial-up and leased-line
links involve two peers that are connected by a communications medium. The
next table summarizes the differences between the link types.

Leased Line

Dial-up Line

Always connected, unless a system administrator or power failure takes
the leased-line down.

Initiated on demand, when a user tries to call a remote peer.

Uses synchronous and asynchronous communications. For asynchronous communications,
a long-haul modem is often used.

Uses asynchronous communications.

Rented from a provider.

Uses existing telephone lines.

Requires synchronous units.

Uses less costly modems.

Requires synchronous ports, which are common on most SPARC systems.
However, synchronous ports are not common on x86 systems and newer SPARC systems.

Uses standard serial interfaces that are included on most computers.

Parts of a Leased-Line PPP Link

See the following figure.

Figure 15–3 Basic Leased-Line Configuration

The leased-line link contains the following parts:

Two peers, each peer at one
end of the link. Each peer might be a workstation or server. Often the peer
functions as a router between its network or the Internet, and the opposite
peer.

Synchronous
interface on each peer. Some machines that run Solaris software
require you to purchase a synchronous interface card, such as HSI/P, to connect
to a leased line. Other machines, such as UltraSPARC® workstations, have built-in synchronous interfaces.

CSU/DSU synchronous digital unit on each
peer, which connects the synchronous port to the leased line.

A CSU might be
built-in to the DSU, or owned by you, or leased from a provider, depending
on your locale. The DSU gives the Solaris machine a standard synchronous serial
interface. With Frame Relay, the Frame Relay Access Device (FRAD) performs
the serial interface adaptation.

What Happens During Leased-Line Communications

On most types of leased lines, peers do not actually dial each other.
Rather, a company purchases a leased-line service to connect explicitly between
two fixed locations. Sometimes the two peers at either end of the leased line
are at different physical locations of the same company. Another scenario
is a company that sets up a router on a leased line that is connected to an
ISP.

Leased lines are less commonly used than dial-up links, though the hardwired
links are easier to set up. Hardwired links do not require chat scripts. Authentication
is often not used because both peers are known to each other when a line is
leased. After the two peers initiate PPP over the link, the link stays active.
A leased-line link remains active unless the line fails, or either peer explicitly
terminates the link.

A peer on a leased line that runs Solaris PPP 4.0 uses most of the same
configuration files that define a dial-up link.

The following process occurs to initiate communication over the leased
line:

Each peer machine runs the pppd command
as part of the booting process or another administrative script.

The peers read their PPP configuration files.

The peers negotiate communications parameters.

An IP link is established.

PPP Authentication

Authentication is the process of verifying
that a user is who he or she claims to be. The UNIX login sequence is a simple
form of authentication:

The login command prompts the user for
a name and password.

login then attempts to authenticate the
user by looking up the typed user name and password in the password database.

If the database contains the user name and password, then
the user is authenticated and given access to the system.
If the database does not contain the user name and password, the user is denied
access to the system.

By default, Solaris PPP 4.0 does not demand
authentication on machines that do not have a default route specified. Thus,
a local machine without a default route does not authenticate remote callers.
Conversely, if a machine does have a default route defined, the machine always
authenticates remote callers.

You might use PPP authentication protocols to verify the identity of
callers who are trying to set up a PPP link to your machine. Conversely, you
must configure PPP authentication information if your local machine must call
peers that authenticate callers.

Authenticators and Authenticatees

The calling machine on a PPP link is considered the authenticatee because the caller must prove its identity to the
remote peer. The peer is considered the authenticator.
The authenticator looks up the caller's identity in the appropriate PPP files
for the security protocol and authenticates or does not authenticate the caller.

You typically
configure PPP authentication for a dial-up link. When the call begins, the
dial-out machine is the authenticatee. The dial-in server is the authenticator.
The server has a database in the form of a secrets file.
This file lists all users who are granted permission to set up a PPP link
to the server. Think of these users as trusted callers.

Some dial-out machines require remote peers to provide authentication
information when responding to the dial-out machine's call. Then their roles
are reversed: the remote peer becomes the authenticatee and the dial-out machine
the authenticator.

Note –

PPP 4.0 does
not prevent authentication by leased-line peers, but authentication is not
often used in leased-line links. The nature of leased-line contracts usually
means that both participants on the ends of the line are known to each other.
Both participants often are trusted. However, because PPP authentication is
not that difficult to administer, you should seriously consider implementing
authentication for leased lines.

PPP Authentication Protocols

The PPP authentication protocols are Password Authentication Protocol
(PAP) and Challenge-Handshake Authentication Protocol (CHAP). Each protocol
uses a secrets database that contains identification
information, or security credentials, for each caller
that is permitted to link to the local machine. For a detailed explanation
of PAP, see Password Authentication Protocol (PAP). For a CHAP explanation, see Challenge-Handshake Authentication Protocol (CHAP).

Why Use PPP Authentication?

Providing authentication on a PPP link is optional. Moreover, though
authentication does verify that a peer is to be trusted, PPP authentication
does not provide confidentiality of data. For confidentiality, use encryption
software, such as IPsec, PGP, SSL, Kerberos, and the Solaris Secure Shell.

Note –

Solaris PPP 4.0 does not implement the PPP Encryption Control
Protocol (ECP), which is described in RFC 1968.

Consider implementing PPP authentication in the following situations:

Your company accepts incoming calls from users over the public,
switched telephone network.

You want to authenticate callers against a standard UNIX password
database, such as /etc/passwd, NIS, LDAP, or PAM. Use PAP
authentication for this scenario.

Your company's dial-in servers also provide the network's
Internet connection. Use PAP authentication for this scenario.

The serial line is less secure than the password database
on the machine or networks at either end of the link. Use CHAP authentication
for this scenario.

Support for DSL Users Through PPPoE

Many network
providers and individuals who are working at home use Digital Subscriber Line
(DSL) technology to provide fast network access. To support DSL users, Solaris
PPP 4.0 includes the PPP over Ethernet (PPPoE) feature. PPPoE technology enables
multiple hosts to run PPP sessions over one Ethernet link to one or more destinations.

If one of the following factors applies to your situation, you should
use PPPoE:

You support DSL users, possibly including yourself. Your DSL
service provider might require users to configure a PPPoE tunnel to receive
services over the DSL line.

Your site is an ISP that intends to offer PPPoE to customers.

This section introduces terms that are associated with PPPoE and an
overview of a basic PPPoE topology.

PPPoE Overview

PPPoE is a proprietary protocol from RedBack Networks. PPPoE is a discovery
protocol, rather than another version of standard PPP. In a PPPoE scenario,
a machine that initiates PPP communications first must locate, or discover, a peer that runs PPPoE. The PPPoE protocol uses Ethernet broadcast
packets to locate the peer.

After the discovery process, PPPoE sets up an
Ethernet-based tunnel from the initiating host, or PPPoE client,
to the peer, the PPPoE access server. Tunneling is
the practice of running one protocol on top of another protocol. Using PPPoE,
Solaris PPP 4.0 tunnels PPP over Ethernet IEEE 802.2, both of which are data
link protocols. The resulting PPP connection behaves like a dedicated link
between the PPPoE client and the access server. For detailed information about
PPPoE, see Creating PPPoE Tunnels for DSL Support.

Parts of a PPPoE Configuration

Three participants are involved in a PPPoE configuration: a consumer,
a telephone company, and a service provider, as the following figure shows.

Figure 15–4 Participants in a PPPoE Tunnel

PPPoE Consumers

As system administrator, you might assist consumers with their PPPoE
configurations. One common type of PPPoE consumer is an individual who needs
to run PPPoE over a DSL line. Another PPPoE consumer is a company that purchases
a DSL line through which employees can run PPPoE tunnels, as illustrated in
the previous figure.

The main reason for a corporate consumer to use PPPoE is to offer PPP
communications through a high-speed DSL device to a number of hosts. Often,
a single PPPoE client has an individual DSL modem. Or,
a group of clients on a hub might share a DSL modem that is also connected
to the hub by an Ethernet line.

Note –

DSL devices
are technically bridges, not modems. However, because common practice is to
refer to these devices as modems, this guide uses the term “DSL modem.”

PPPoE runs PPP over a tunnel on the Ethernet line that is connected
to the DSL modem. That line is connected to a splitter, which, in turn connects
to a telephone line.

PPPoE at a Telephone Company

The telephone company is the middle layer of the PPPoE
scenario. The telephone company splits the signal that is received over the
phone line by using a device that is called a Digital Subscriber
Line Access Multiplexer (DSLAM). The DSLAM breaks out the signals
onto separate wires, analog wires for telephone service, and digital wires
for PPPoE. From the DSLAM, the digital wires extend the tunnel over an ATM
data network to the ISP.

PPPoE at a Service Provider

The ISP receives the PPPoE transmission from the ATM data network over
a bridge. At the ISP, an access server that runs PPPoE functions as the peer
for the PPP link. The access server is very similar in function to the dial-in
server that was introduced in Figure 15–2, but the access server does not use modems. The access server converts
the individual PPPoE sessions into regular IP traffic, for example Internet
access.

If you are a system administrator for an ISP, you might be responsible
for configuring and maintaining an access server.

Security on a PPPoE Tunnel

The PPPoE tunnel is inherently insecure. You can use PAP or CHAP to
provide user authentication for the PPP link that is running over the tunnel.