Point-to-Point Protocol


 This article may require cleanup to meet Wikipedia's quality standards. Please improve this article if you can. (March 2009)
This article is in need of attention from an expert on the subject. WikiProject Computer Science or the Computer Science Portal may be able to help recruit one. (March 2009)
The Internet Protocol Suite
Application Layer
BGP · DHCP · DNS · FTP · GTP · HTTP · IMAP · IRC · Megaco · MGCP · NNTP · NTP · POP · RIP · RPC · RTP · RTSP · SDP · SIP · SMTP · SNMP · SOAP · SSH · Telnet · TLS/SSL · XMPP · (more)
Transport Layer
TCP · UDP · DCCP · SCTP · RSVP · ECN · (more)
Internet Layer
IP (IPv4, IPv6) · ICMP · ICMPv6 · IGMP · IPsec · (more)
Link Layer
ARP · RARP · NDP · OSPF · Tunnels (L2TP) · PPP · Media Access Control (Ethernet, MPLS, DSL, ISDN, FDDI) · Device Drivers · (more)
This box: view • talk • edit

In networking, the Point-to-Point Protocol, or PPP, is a data link protocol commonly used to establish a direct connection between two networking nodes. It can provide connection authentication, transmission encryption privacy, and compression.

PPP over ATM Adaptation Layer 5 (AAL5), which is also sometimes used with DSL.

PPP is specified in RFC 1661. [1]

Contents

Basic Features

PPP was designed somewhat after the original HDLC specifications. The designers of PPP included many additional features that had been seen only in proprietary data-link protocols up to that time.

Automatic self configuration

Link Control Protocol (LCP) is an integral part of PPP, and is defined in the same standard specification. LCP provides automatic configuration of the interfaces at each end (such as setting datagram size, escaped characters, and magic numbers) and for selecting optional authentication. The LCP protocol runs on top of PPP (with PPP protocol number 0xC021) and therefore a basic PPP connection has to be established before LCP is able to configure it.

RFC 1994 describes Challenge-handshake authentication protocol (CHAP), which is preferred for establishing dial-up connections with ISPs. Although deprecated, Password authentication protocol (PAP) is still sometimes used.

Another option for authentication over PPP is Extensible Authentication Protocol (EAP).[2]

After the link has been established, additional network (layer 3) configuration may take place. Most commonly, the Internet Protocol Control Protocol (IPCP) is used, although Internetwork Packet Exchange Control Protocol (IPXCP) and AppleTalk Control Protocol (ATCP) were once very popular. Internet Protocol Version 6 Control Protocol (IPv6CP) will see extended use in the future, when IPv6 replaces IPv4's position as the dominant layer-3 protocol.

Multiple network layer protocols

PPP permits multiple network layer protocols to operate on the same communication link. For every network layer protocol used, a separate Network Control Protocol (NCP) is provided in order to encapsulate and negotiate options for the multiple network layer protocols.

For example, Internet Protocol (IP) uses the IP Control Protocol (IPCP), and Internetwork Packet Exchange (IPX) uses the Novell IPX Control Protocol (IPXCP). NCPs include fields containing standardized codes to indicate the network layer protocol type that the PPP connection encapsulates.

Looped link detection

PPP detects looped links using a feature involving magic numbers. When the node sends PPP LCP messages, these messages may include a magic number. If a line is looped, the node receives an LCP message with its own magic number, instead of getting a message with the peer's magic number.

Most important features

  • Link Control Protocol initiates and terminates connections gracefully, allowing hosts to negotiate connection options. It also supports both byte- and bit-oriented encodings[citation needed].
  • Network Control Protocol is used for negotiating network-layer information, e.g. network address or compression options, after the connection has been established.

PPP frame

Name Number of bytes Description
Protocol 1 or 2 setting of protocol in data field
Information variable (0 or more) datagram
Padding variable (0 or more) optional padding

The Protocol field indicates the type of payload packet (e.g. LCP, NCP, IP, IPX, AppleTalk, etc.).

The Information field contains the PPP payload; it has a variable length with a negotiated maximum called the Maximum Transmission Unit. By default, the maximum is 1500 octets. It might be padded on transmission; if the information for a particular protocol can be padded, that protocol must allow information to be distinguished from padding.

Encapsulation

PPP frames are encapsulated in a lower-layer protocol that provides framing and may provide other functions such as a checksum to detect transmission errors. PPP on serial links is usually encapsulated in a framing similar to HDLC, described by IETF RFC 1662.

Name Number of bytes Description
Flag 1 indicates frame's begin or end
Address 1 broadcast address
Control 1 control byte
Protocol 1 or 2 setting of protocol in information field
Information variable (0 or more) datagram
Padding variable (0 or more) optional padding
FCS 2 (or 4) error check

The Flag field is present when PPP with HDLC-like framing is used.

The Address and Control fields always have the value hex FF (for "all stations") and hex 03 (for "unnumbered information"), and can be omitted whenever PPP LCP Address-and-Control-Field-Compression (ACFC) is negotiated.

The Frame Check Sequence (FCS) field is used to determine whether an individual frame has an error. It contains a checksum computed over the frame to provide basic protection against errors in transmission. This is a CRC code similar to the one used for other layer two protocol error protection schemes such as the one used in Ethernet. According to RFC 1662, it can be either 16 bits (2bytes) or 32 bits (4 bytes) in size (default is 16 bits - Polynomial x16 + x12 + x5 + 1).

The FCS is calculated over the Address, Control, Protocol, Information and Padding fields.

PPP line activation and phases

A diagram depicting the phases of PPP according to RFC 1661.

The phases of the Point to Point Protocol according to RFC 1661 are listed below:

  • Link Dead. This phase occurs when the link fails, or one side has been told not to connect (e.g. a user has finished his or her dialup connection.)
  • Link Establishment Phase. This phase is where Link Control Protocol negotiation is attempted. If successful, control goes either to the authentication phase or the Network-Layer Protocol phase, depending on whether authentication is desired.
  • Authentication Phase. This phase is optional. It allows the sides to authenticate each other before a connection is established. If successful, control goes to the network-layer protocol phase.
  • Network-Layer Protocol Phase. This phase is where each desired protocols' Network Control Protocols are invoked. For example, IPCP is used to establish IP service over the line. Data transport for all protocols which are successfully started with their network control protocols also occurs in this phase. Closing down of network protocols also occur in this phase.
  • Link Termination Phase. This phase closes down this connection. This can happen if there is an authentication failure, if there are so many checksum errors that the two parties to the link decide to tear down the link automatically, if the link suddenly fails, or if the user decides to hang up his connection. This phase tries to close everything down as gracefully as possible depending on the circumstances.

Multiclass PPP

MP's monotonically increasing sequence numbering (contiguous numbers are needed for all fragments of a packet) does not allow suspension of the sending of a sequence of fragments of one packet in order to send another packet. The obvious approach to providing more than one level of suspension with PPP Multilink is to run Multilink multiple times over one link. Multilink as it is defined provides no way for more than one instance to be active. Each class runs a separate copy of the mechanism defined i.e. uses a separate sequence number space and reassembly buffer. See RFC 2686.

This section requires expansion.

Other features

Numerous documents on PPP have been published through the RFC process since July 1990, including various authentication, encryption, and compression methods, and the use of PPP in conjunction with other network protocols.

RFC 2615 is also used in Packet over SONET/SDH (PoS) transmissions.

PPTP is a form of PPP between two hosts via GRE. It is often used to set up a VPN, with optional encryption (MPPE) or compression (MPPC).

RFCs

PPP is defined in RFC 1661 (The Point-to-Point Protocol, July 1994). RFC 1547 (Requirements for an Internet Standard Point-to-Point Protocol, December 1993) provides historical information about the need for PPP and its development. A series of related RFCs have been written to define how a variety of network control protocols-including TCP/IP, DECnet, AppleTalk, IPX, and others-work with PPP. [3]

  • RFC 1661, Standard 51, The Point-to-Point Protocol (PPP)
  • RFC 1662, Standard 51, PPP in HDLC-like Framing
  • RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP)
  • RFC 2153, Informational, PPP Vendor Extensions
  • RFC 2687, Proposed Standard, PPP in a Real-time Oriented HDLC-like Framing
  • RFC 5072, IP Version 6 over PPP
    • RFC 5172, Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol

Other VPN Protocols

References

  1. ^ http://www.ietf.org/rfc/rfc1661.txt
  2. ^ RFC2284 - PPP Extensible Authentication Protocol (EAP)
  3. ^ PPP (Point-to-Point Protocol) (Linktionary term)

See also







stock | retire | vm
Why are we here?
All text is available under the terms of the GNU Free Documentation License
This page is cache of Wikipedia. History