Solaris PPP 4.0 enables two computers in different physical locations to communicate with each other by using Point-to-Point Protocol (PPP) over a variety of media. The Solaris 9 operating environment includes Solaris PPP 4.0 as part of the base installation.
This chapter introduces Solaris PPP 4.0. Topics that are discussed include the following:
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.
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 environment. 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 operating environments
SolsticeTM PPP 3.0.1
Microsoft Windows 98 DUN
Cisco IOS 12.0 (synchronous)
Solaris PPP 4.0 is the PPP implementation that is supported by the Solaris 9 operating environment. The Solaris 9 operating environment does not include the earlier asynchronous PPP (asppp) software. Asynchronous PPP configuration is discussed in the Solaris 8 System Administrator Collection at http://www.docs.sun.com.
If you currently use asppp, consider migrating to Solaris PPP 4.0. Note the following differences between the two Solaris PPP technologies:
Transfer modes
asppp supports asynchronous communications only. Solaris PPP 4.0 supports both asynchronous communications and synchronous communications.
Configuration process
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
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.
Many resources with information about PPP can be found in print and online. The following subsections give some suggestions.
For more information about widely used PPP implementations, including ANU PPP, refer to the following books:
Carlson, James. PPP Design, Implementation, and Debugging. 2nd ed. Addison-Wesley, 2000.
Sun, Andrew. Using and Managing PPP. O'Reilly & Associates, 1999.
Go to the following web sites for general information about PPP:
For a list of frequently asked questions (FAQ) and other information about pppd, go to the following site that is provided by the Internet Engineering group at Sun Microsystems, http://playground.sun.com/pppd.
For ANU PPP information, go to the PPP repository of Australian National University, http://.pserver.samba.org/cgi-bin/cvsweb/ppp/.
For technical information, FAQs, discussions about Solaris system administration, and earlier versions of PPP, go to Sun Microsystem's system administrators' resource, http://www.sun.com/bigadmin/home/index.html.
For modem configuration and advice on many different implementations of PPP, refer to Stokely Consulting's Web Project Management & Software Development web site: http://www.stokely.com/unix.serial.port.resource/ppp.slip.htm.
Some useful Internet RFCs about PPP include the following:
1661 and 1662, which describe the major features of the PPP protocol
1334, which describes authentication protocols, such as Password Authentication Protocol (PAP) and Challenge-Handshake Authentication Protocol (CHAP)
2516, an informational RFC that describes PPP over Ethernet (PPPoE)
To obtain copies of PPP RFCs, specify the number of the RFC on the IETF RFC web page at http://www.ietf.org/rfc.html .
For technical details about the Solaris PPP 4.0 implementation, refer to the following man pages:
You can find the PPP-related man pages at http://www.docs.sun.com or through the man command.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
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, hih, 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.
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.
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.
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
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 on chat scripts for ISDN TAs.
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.
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.
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.
When modem-to-modem negotiation completes, 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.
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.
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 communications |
Uses asynchronous communications |
Rented from a provider |
Uses existing telephone lines |
Requires synchronous units |
Uses less costly modems |
Requires specialized interfaces |
Uses standard serial interfaces that are included on most computers |
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/S, to connect to a leased line. Other machines, such as UltraSPARCTM 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.
Leased line, providing switched or unswitched digital services. Some examples are SONET/SDH, Frame Relay PVC, and T1.
SONET is called an octet synchronous link. PPP uses a framing mechanism that is similar to asynchronous framing over a SONET line. PPP does not use the expected bit-synchronous protocol.
On most types of leased lines, peers do not actually dial each other. Rather, a company purchases a leased-line service to explicitly connect 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.
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, by default the machine does authenticate 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.
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.
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.
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).
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, and the Solaris secure shell.
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.
Your corporate security policy requires remote users to provide authentication credentials when accessing your network through a corporate firewall or when engaging in secure transactions.
You want to authenticate callers against a standard UNIX password database, such as /etc/passwd, NIS, 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.
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.
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.
Three participants are involved in a PPPoE configuration: a consumer, a telephone company, and a service provider, as the following figure shows.
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.
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.
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.
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 25–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.
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.