Point-to-Point Protocol

Point-to-Point Protocol


In computer networking, Point-to-Point Protocol
is a data link protocol used to establish a direct connection between two nodes. It can provide connection authentication,
transmission encryption, and compression. PPP is used over many types of physical networks
including serial cable, phone line, trunk line, cellular telephone, specialized radio
links, and fiber optic links such as SONET. PPP is also used over Internet access connections. Internet service providers have used PPP for
customer dial-up access to the Internet, since IP packets cannot be transmitted over a modem
line on their own, without some data link protocol. Two derivatives of PPP, Point-to-Point Protocol
over Ethernet and Point-to-Point Protocol over ATM, are used most commonly by Internet
Service Providers to establish a Digital Subscriber Line Internet service connection with customers. PPP is commonly used as a data link layer
protocol for connection over synchronous and asynchronous circuits, where it has largely
superseded the older Serial Line Internet Protocol and telephone company mandated standards
in the X.25 protocol suite). The only requirement for PPP is that the circuit
provided be full duplex. PPP was designed to work with numerous network
layer protocols, including Internet Protocol, TRILL, Novell’s Internetwork Packet Exchange,
NBF, DECnet and AppleTalk. Description
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. RFC 2516 describes Point-to-Point Protocol
over Ethernet as a method for transmitting PPP over Ethernet that is sometimes used with
DSL. RFC 2364 describes Point-to-Point Protocol
over ATM as a method for transmitting PPP over ATM Adaptation Layer 5, which is also
a common alternative to PPPoE used with DSL. PPP is a layered protocol that has three components:
An encapsulation component that is used to transmit datagrams over the specified physical
layer. A Link Control Protocol to establish, configure,
and test the link as well as negotiate capabilities. One or more NCPs used to negotiate optional
configuration parameters and facilities for the network layer. There is one Network Control Protocol for
each protocol supported by PPP. PPP is specified in RFC 1661. Automatic self configuration
Link Control Protocol initiates and terminates connections gracefully, allowing hosts to
negotiate connection options. It is an integral part of PPP, and is defined
in the same standard specification. LCP provides automatic configuration of the
interfaces at each end and for selecting optional authentication. The LCP protocol runs on top of PPP and therefore
a basic PPP connection has to be established before LCP is able to configure it. RFC 1994 describes Challenge-handshake authentication
protocol, which is preferred for establishing dial-up connections with ISPs. Although deprecated, Password authentication
protocol is still sometimes used. Another option for authentication over PPP
is Extensible Authentication Protocol described in RFC 2284. After the link has been established, additional
network configuration may take place. Most commonly, the Internet Protocol Control
Protocol is used, although Internetwork Packet Exchange Control Protocol and AppleTalk Control
Protocol were once very popular. Internet Protocol Version 6 Control Protocol
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 is provided in order to encapsulate and negotiate options for the
multiple network layer protocols. It negotiates network-layer information, e.g.
network address or compression options, after the connection has been established. For example, Internet Protocol uses the IP
Control Protocol, and Internetwork Packet Exchange uses the Novell IPX Control Protocol. 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. PPP Configuration Options
The previous section introduced the use of LCP options to meet specific WAN connection
requirements. PPP may include the following LCP options:
Authentication – Peer routers exchange authentication messages. Two authentication choices are Password Authentication
Protocol and Challenge Handshake Authentication Protocol. Authentication is explained in the next section. Compression – Increases the effective throughput
on PPP connections by reducing the amount of data in the frame that must travel across
the link. The protocol decompresses the frame at its
destination. See RFC 1962 for more details. Error detection – Identifies fault conditions. The Quality and Magic Number options help
ensure a reliable, loop-free data link. The Magic Number field helps in detecting
links that are in a looped-back condition. Until the Magic-Number Configuration Option
has been successfully negotiated, the Magic-Number must be transmitted as zero. Magic numbers are generated randomly at each
end of the connection. Multilink – Provides load balancing several
interfaces used by PPP through Multilink PPP. PPP frame
Structure of a PPP frame The Protocol field indicates the type of payload
packet. 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. The Flag field is present when PPP with HDLC-like
framing is used. The Address and Control fields always have
the value hex FF and hex 03, and can be omitted whenever PPP LCP Address-and-Control-Field-Compression
is negotiated. The frame check sequence field is used for
determining 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 or 32 bits in size. The FCS is calculated over the Address, Control,
Protocol, Information and Padding fields after the message has been encapsulated. PPP line activation and phases 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 to disconnect
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 in establishing
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 decide to tear down the
link automatically, if the link suddenly fails, or if the user decides to hang up his connection. PPP over several links
Multilink PPP Multilink PPP provides a method for spreading
traffic across multiple distinct PPP connections. It is defined in RFC 1990. It can be used, for example, to connect a
home computer to an Internet Service Provider using two traditional 56k modems, or to connect
a company through two leased lines. On a single PPP line frames cannot arrive
out of order, but this is possible when the frames are divided among multiple PPP connections. Therefore Multilink PPP must number the fragments
so they can be put in the right order again when they arrive. Multilink PPP is an example of a link aggregation
technology. Cisco IOS Release 11.1 and later supports
Multilink PPP. Multiclass PPP
With PPP, one cannot establish several simultaneous distinct PPP connections over a single link. That’s not possible with Multilink PPP either. Multilink PPP uses contiguous numbers for
all the fragments of a packet, and as a consequence it is not possible to suspend the sending
of a sequence of fragments of one packet in order to send another packet. This prevents from running Multilink PPP multiple
times on the same links. Multiclass PPP is a kind of Multilink PPP
where each “class” of traffic uses a separate sequence number space and reassembly buffer. Multiclass PPP is defined in RFC 2686. PPP and tunnels
Derived protocols PPTP is a form of PPP between two hosts via
GRE using encryption and compression. PPP as a layer 2 protocol between both ends
of a tunnel Many protocols can be used to tunnel data
over IP networks. Some of them, like SSL, SSH, or L2TP create
virtual network interfaces and give the impression of a direct physical connections between the
tunnel endpoints. On a Linux host for example, these interfaces
would be called tun0. As there are only two endpoints on a tunnel,
the tunnel is a point-to-point connection and PPP is a natural choice as a data link
layer protocol between the virtual network interfaces. PPP can assign IP addresses to these virtual
interfaces, and these IP addresses can be used, for example, to route between the networks
on both sides of the tunnel. IPsec in tunneling mode does not create virtual
physical interfaces at the end of the tunnel, since the tunnel is handled directly by the
TCP/IP stack. L2TP can be used to provide these interfaces,
this technique is called L2TP/IPsec. In this case too, PPP provides IP addresses
to the extremities of the tunnel. See also
Diameter Extensible Authentication Protocol
Hayes command set Link Access Procedure for Modems
Multiprotocol Encapsulation for MPEG transport stream
Point-to-Point Protocol daemon PPPoX
RADIUS Shortest Path Bridging
Unidirectional Lightweight Encapsulation for MPEG transport stream
References RFCs
PPP is defined in RFC 1661. RFC 1547 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. RFC 1661, Standard 51, The Point-to-Point
Protocol RFC 1662, Standard 51, PPP in HDLC-like Framing
RFC 1962, PPP Compression Control Protocol RFC 1963, PPP Serial Data transport Protocol
RFC 1990, The PPP Multilink Protocol RFC 1994, PPP Challenge Handshake Authentication
Protocol RFC 2153, Informational, PPP Vendor Extensions
RFC 2284, PPP Extensible Authentication Protocol RFC 2364, PPP over ATM
RFC 2516, PPP over Ethernet RFC 2615, PPP over SONET/SDH
RFC 2686, The Multi-Class Extension to Multi-Link PPP
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 RFC 6361, PPP Transparent Interconnection
of Lots of Links Protocol Control Protocol

Danny Hutson

3 thoughts on “Point-to-Point Protocol

Leave a Reply

Your email address will not be published. Required fields are marked *