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.The following topics are discussed:Solaris PPP 4.0 Basics PPP Configurations and Terminology PPP Authentication Support for DSL Users Through PPPoE 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 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 Solstice PPP 3.0.1 Microsoft Windows 98 DUN Cisco IOS 12.0 (synchronous) 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:Chapter 23, Migrating From Asynchronous Solaris PPP to Solaris PPP 4.0 (Tasks) Solaris 8 System Administrator Collection at http://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 modesasppp supports asynchronous communications only. Solaris PPP 4.0 supports both asynchronous communications and synchronous communications. Configuration processSetting 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 aspppMS-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 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 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 Microsystems' system administrators' resource, http://www.sun.com/bigadmin/home/index.html. For modem configuration and advice about many different implementations of PPP, refer to Stokely Consulting's Web Project Management & Software Development web site: http://www.stokely.com/unix.serial.port.resources/ppp.slip.html. Some useful Internet RFCs about PPP include the following:1661 and 1662, which describe the major features of PPP 1334, which describes authentication protocols, such as Password Authentication Protocol (PAP) and Challenge-Handshake Authentication Protocol (CHAP) 1332, 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:pppd1M chat1M pppstats1M pppoec1M pppoed1M sppptun1M snoop1M Also, see the man page for pppdump(1M). You can find the PPP-related man pages by using 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 diagram shows the parts of a basic PPP link, which is further described in the following context.

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. 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.See the following figure.

The graphic shows a basic dial-up link between Locations 1 and 2, which is described in the following context.

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 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. 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. 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 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. See the following figure.

The graphic shows the parts of a leased-line-link, which are described in the following context.

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. Leased line, providing switched or unswitched digital services. Some examples are SONET/SDH, Frame Relay PVC, and T1. 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. 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. 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, Kerberos, 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. This section introduces terms that are associated with PPPoE and an overview of a basic PPPoE topology.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.

The figure shows how PPPoE is implemented at an enterprise, a telephone company, and a service provider.

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 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. 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.