test

Solstice PPP 3.0.1 Administration Guide

Chapter 1 Introducing Solstice PPP

This chapter describes the Solstice PPP implementation of the Point-to-Point Protocol (PPP), and describes how it is used to run IP applications across PPP links.

Overview

Solstice PPP is a standard implementation of the Point-to-Point Protocol (PPP), which defines a method for transmitting multiprotocol datagrams over synchronous and asynchronous serial point-to-point links, and the Internet Protocol Control Protocol (IPCP), which defines a method for transmitting IP datagrams over PPP.

Synchronous PPP provides permanent connections between two endpoints, and is typically used for LAN-to-LAN interconnectivity across dedicated leased-lines. Asynchronous PPP provides temporary connections between two endpoints, and is typically used for mobile communication, teleworking, and Internet access across public and private telephone networks.

Feature Summary

Product Conformance

Solstice PPP is a standard implementation of the following specifications:

Running IP Applications over Solstice PPP

Once configured and started on a host machine, Solstice PPP encapsulates standard IP packets and routes them across serial point-to-point links. This process occurs in three phases, as shown in Figure 1-1.

  1. A physical connection is established between two endpoints.

  2. A PPP link is established over the physical connection.

  3. IP is established over the PPP link.

Figure 1-1 Establishing IP over PPP Links

Graphic

Establishing the Physical Connection

Solstice PPP transmits data over full-duplex, bit-serial connections. It supports any of the common serial communications protocols, including EIA-232-E (formerly, RS-232-C), EIA-422, EIA-423, EIA-530, and CCITT V.24 and V.35. The physical connection for Solstice PPP may be either synchronous or asynchronous.

Synchronous Connections

Synchronous connections use independent clocking signals to synchronize the data transmission. They provide a permanent connection between two endpoints, and are typically established over dedicated leased-lines.

You pay for the synchronous connection for the duration of the lease and the cost is independent of the quantity of data transmitted. For these reasons, synchronous connections are best suited to continuous data traffic and are used typically for LAN-to-LAN interconnectivity and bulk transfers of information as shown in Figure 1-2.

Figure 1-2 Synchronous Connection between LANs.

Graphic

The synchronous connection is established through a synchronous serial interface installed in the host machine. The synchronous connection is established when Solstice PPP is started; therefore, there is no independent connection phase when a PPP link is established over a synchronous connection. Refer to the Solstice PPP 3.0.1 Installation Guide and Release Notes for a list of the synchronous serial interfaces with which Solstice PPP has been tested.

Asynchronous Connections

Asynchronous connections either use information carried in the data itself (software flow control), or handshake signals generated by the serial interface (hardware flow control), to control the data transmission. They provide temporary connections between two endpoints, and are typically established over private and public telephone networks or null modem links.

The cost of the connection is related to the duration of the call and the distance between endpoints. For this reason, asynchronous connections are best suited to transient network traffic, and are used typically for mobile communication, teleworking, and temporary access to Internet servers as shown in Figure 1-3.

Figure 1-3 Asynchronous Connection between Client and Server

Graphic

The asynchronous connection is established through an asynchronous serial interface installed in the host machine, and a modem which represents the interface between the host machine and the analog telephone network. During the connection phase, the modems at each endpoint communicate to set up the call.

Refer to the Solstice PPP 3.0.1 Installation Guide and Release Notes for a list of the asynchronous serial interfaces and modems with which Solstice PPP has been tested. Configuration information for these modems is contained in the modem database file /etc/opt/SUNWconn/ppp/modems.

You can modify the modems database file to add configuration information for additional modems, provided they support standard Hayes AT commands. Refer to the manufacturers' documentation for details of the commands used to configure your modem.

Establishing PPP over the Physical Connection

Once the physical connection is established, the two endpoints negotiate to define a common configuration for the PPP layer. For synchronous connections, the PPP layer is established each time you start Solstice PPP on your machine. For asynchronous connections, the PPP layer is established each time you initiate a call to a remote host.

During the PPP negotiation phase, the endpoints exchange Link Control Protocol (LCP) frames that contain information regarding the desired configuration and the supported protocol options. Negotiated parameters include the use of compression algorithms to improve performance over slow connections, and the use of authentication protocols to protect against unauthorized access. The policy is to converge the negotiation, if at all possible; however, if the two endpoints fail to agree on a common configuration, the link is closed automatically.

Establishing IP over PPP

Once the PPP link is established, the two endpoints negotiate to define a common configuration for the IP layer. During the IP negotiation phase, the two endpoints exchange Network Control Protocol (NCP) frames that contain information about the desired configuration. The negotiated parameters can include the IP address. This feature forms the basis of dynamic IP address allocation.

To route IP datagrams across synchronous or asynchronous PPP links, you must define the logical IP interfaces that represent the boundary between Solstice PPP and the IP layer of the Solaris operating system. These interfaces are initialized with the negotiated configuration information.

Solstice PPP supports two types of IP interface:

Point-to-Point IP Interfaces (ipdptpn)

The point-to-point IP interface for Solstice PPP is /dev/ipdptp. This interface is used to create a direct connection for IP between exactly two hosts, as shown in Figure 1-4.

Figure 1-4 IP Point-to-Point Configuration

Graphic

A point-to-point IP interface is defined by specifying a source address (or point of attachment) and a unique destination address. There is a single possible destination for the next hop, once the IP datagram has been passed to a given point-to-point interface. Therefore, the same source address can be used for multiple point-to-point connections on the same host. Multiple point-to-point connections can be used to connect to several remote hosts simultaneously.

IP point-to-point connections are supported by both synchronous and asynchronous Solstice PPP links.

Point-to-Multipoint IP Interfaces (ipdn)

The point-to-multipoint IP interface for Solstice PPP is /dev/ipd. A single interface is used to create IP connections between one host and several others, as shown in Figure 1-5. The effect of using point-to-multipoint interfaces is to create a virtual subnetwork, which is usually assigned its own subnetwork number.

Figure 1-5 IP Point-to-Multipoint Configuration

Graphic

A point-to-multipoint interface is defined by specifying a source address only. There are multiple possible destinations for the next hop, once an IP datagram has been passed to a point-to-multipoint interface. Therefore, each point-to-multipoint interface must be assigned a unique source address.

IP point-to-multipoint connections are only supported by asynchronous Solstice PPP links.

Load-Sharing for Synchronous PPP Links

Load-sharing is a Sun-specific enhancement to the standard implementation of PPP. It increases the available bandwidth by sharing the network traffic from one IP interface equally between two or more synchronous links, as shown in Figure 1-6.

Figure 1-6 Load-Sharing over Synchronous Links

Graphic

Note -

For optimum performance, all of the synchronous devices used for load-sharing must be operating at the same line speed. Both ends of the link must be running Solstice PPP in order to implement load-sharing.

See "Load-Sharing over Synchronous Links" for a detailed example that shows how to enable load-sharing using Solstice PPP.

Dynamic IP Address Allocation

Solstice PPP provides a mechanism for dynamic IP address allocation over asynchronous PPP links. This mechanism is used by clients to request IP addresses from a server at the time the PPP link is established.

Dynamic IP address allocation is enabled on the client side. When the client initiates a PPP link to the server, it requests an IP address for the connection. The server responds with its own IP address and the IP address it has allocated for the client's local interface, and the client uses these addresses to establish a point-to-point IP connection over the existing PPP link.

To support dynamic IP address allocation on the server, you must define a pool of point-to-point IP interfaces. The server allocates an interface from this pool when it receives a request for IP addresses from a client, and the interface is returned to the pool when the PPP link is terminated.

The number of IP interfaces in the pool should be equal to the number of modems connected to the server; however, the number of clients supported by the server may be much larger. IP addresses are allocated on demand for as long as there are modems available to accept the connections.

See Chapter 4, Editing the Configuration Filesfor instructions on how to set up servers and clients to use dynamic IP address allocation.

Static and Dynamic IP Interfaces

Point-to-point IP interfaces may be static or dynamic:

See "Generic Internet Server Configuration" for a detailed example of an Internet server configuration that uses dynamic IP address allocation with dynamic IP interfaces.

Peer Authentication using PAP and CHAP

Solstice PPP implements peer authentication based on the Password Authentication Protocol (PAP) and the Challenge-Handshake Authentication Protocol (CHAP) defined by RFC 1334. Peer authentication is optional, and is negotiated during the link establishment phase.

See "Editing the PPP Path Configuration File (ppp.conf)" for instructions on how to enable and use peer authentication.

Password Authentication Protocol (PAP)

The Password Authentication Protocol (PAP) provides simple password authentication on initial link establishment. It is not a strong authentication method, since passwords are transmitted in clear over the link and there is no protection from repeated attacks during the life of the link.

When PAP authentication is requested by one end of the link during the link establishment phase, the other end must respond with a valid and recognized identifier and password pair. If it fails to respond, or if either the identifier or password are rejected, authentication fails and the link is closed.

PAP authentication may be requested by one end of the link only, or by both ends of the link simultaneously. If both ends request PAP authentication, they exchange identifiers and passwords. Authentication must be successful at both ends, or the link is closed.

Challenge-Handshake Authentication Protocol (CHAP)

The Challenge-Handshake Authentication Protocol (CHAP) provides password authentication on initial link establishment, based on a three-way handshake mechanism. It depends on a CHAP secret, known only to the authenticator and its peer, which is not transmitted over the link.

When CHAP authentication is requested by one end of the link, it generates a challenge message that includes a challenge value, which is calculated from the CHAP secret. The other end must respond to the challenge message with a response value, which is calculated from the challenge value received, and the common secret. If it fails to respond, or if the response does not correspond to that expected by the authenticator, the link is closed.

CHAP is a stronger authentication method than PAP, because the secret is not transmitted over the link, and because it provides protection against repeated attacks during the life of the link. As a result, if both PAP and CHAP authentication are enabled, CHAP authentication is always performed first.

CHAP authentication may be requested by one end of the link only, or by both ends of the link simultaneously. If both ends request CHAP authentication, they exchange challenge and response messages. Authentication must be successful at both ends, or the link is closed.

Solstice PPP Product Architecture

The primary components of Solstice PPP are shown in Figure 1-7 and are described in the following sections.

Figure 1-7 Solstice PPP Product Architecture

Graphic

Point-to-Point Protocol (PPP) STREAMS Module

The PPP STREAMS module is a standard implementation of the Point-to-Point Protocol described by RFC 1661. It establishes and configures data-link level connections across serial point-to-point links, and encapsulates IP datagrams for transmission as PPP frames.

IP Dialup Layer

The IP dialup layer represents the boundary between Solstice PPP and the Solaris TCP/IP protocol suite. It includes a connection manager (ipdcm), which maintains and monitors the logical IP interfaces used by the IP layer to transmit datagrams across a PPP link, and the IP interfaces themselves. There are two types of IP interface associated with Solstice PPP:

See "Establishing IP over PPP" for a detailed description of these interfaces.

PPP Link Manager

The PPP link manager (pppd) controls all the communication links established using Solstice PPP. It reads the information in the Solstice PPP configuration files and configures the IP dialup layer and the PPP STREAMS module.

PPP Login Service

The PPP login service (pppls) is used to accept incoming connections from remote users. It relies on the standard UNIX login to validate the user name and password, and informs the PPP link manager of the existence of a valid PPP connection when the user is accepted.

Before a machine running Solstice PPP can accept incoming calls, the system administrator must create a user account for each remote user. This account must contain the user name and password, and must call /usr/sbin/pppls as the default login shell.

See "Adding User Accounts for Incoming Connections" for a detailed description of how to create user accounts for the PPP login service.

PPP Diagnostic Utilities (ppptrace and pppstat)

Solstice PPP includes two diagnostic utilities that display information recovered from the PPP STREAMS module. The PPP trace utility /usr/bin/ppptrace displays PPP frame information, and the statistics collection utility /usr/bin/pppstat displays a cumulative record of the number and type of PPP frames sent and received since Solstice PPP was started.

PPP Initialization Script (pppinit)

The PPP initialization script, /usr/bin/pppinit, is used to create a basic network configuration. Use pppinit to configure Solstice PPP for the first time, and then modify the configuration files to create more complex PPP networks.

PPP Configuration Files (ppp.conf and link.conf)

Configuration information for Solstice PPP is contained in two configuration files. These files are created with basic configuration information using the PPP initialization script (pppinit). They may be modified later to add details of more complex configurations.

The file /etc/opt/SUNWconn/ppp/ppp.conf describes the synchronous and asynchronous paths used for IP connections over PPP. The file /etc/opt/SUNWconn/ppp/link.conf defines the various serial devices available for establishing PPP links, and creates a mapping between these devices and the remote hosts for outgoing connections.

See Chapter 4, Editing the Configuration Filesfor a detailed description of these files.

PPP CHAT (or Connect) Scripts

By default, the CHAT (or connect) scripts are located in the directory /etc/opt/SUNWconn/ppp/script. CHAT scripts contain information that defines the login dialog used to initiate asynchronous connections to remote hosts, including the login id and login password sent by the local host. You must create a unique CHAT script for each remote host to which connections will be initiated.

Some of the information contained in the CHAT script is dependent on the operating system running on the remote host. The PPP initialization script (pppinit) can be used to create CHAT scripts to initiate connections to hosts running a SolarisTM environment.

PPP Log File (ppp.log)

The status and error messages generated by the PPP link manager are logged in the file /var/adm/log/ppp.log. See "Status and Error Messages" for a detailed description of the messages that appear in this file.

Figure 1-8 IP Connections over Synchronous and Asynchronous Links

Graphic