codelessgenie blog

Point-to-Point Protocol (PPP) Suite: The Underpinning of Modern Network Communications

Point-to-Point Protocol (PPP) is a foundational data link layer protocol essential for establishing direct connections between two network nodes. Developed as a robust successor to the Serial Line Internet Protocol (SLIP), PPP provides a standardized method for transporting multi-protocol datagrams over point-to-point links while incorporating critical features like authentication, error detection, and configuration negotiation. This comprehensive guide explores PPP's architecture, components, operation mechanisms, and modern relevance.

Relevance Today: While newer technologies exist, PPP remains vital in:

  • DSL broadband implementations (PPPoE)
  • VPN tunnel establishment (L2TP/IPSec)
  • Cellular network backhaul
  • Out-of-band management interfaces
  • Serial WAN connections (T1/E1, leased lines)
2026-07

Table of Contents#

  1. PPP History and Motivation
  2. PPP Architecture Overview
  3. Frame Structure and Framing
  4. Link Control Protocol (LCP)
  5. Authentication Protocols (PAP, CHAP, EAP)
  6. Network Control Protocol (NCP)
  7. PPP Session Lifecycle
  8. Common Implementations & Use Cases
  9. Best Practices for Deployment
  10. Modern PPP Variations (PPPoE, PPPoA)
  11. Conclusion
  12. References

1. PPP History and Motivation#

Developed in the early 1990s, PPP emerged as a standardized alternative to SLIP to address its critical limitations:

  • Lack of authentication
  • No dynamic IP assignment
  • Limited to IP transport only
  • Absence of error correction
  • Proprietary implementations causing incompatibilities

PPP was standardized in RFC 1661 (1994) and evolved through RFC 1662 and RFC 1663, enabling reliable multi-protocol communication over synchronous/asynchronous circuits.

2. PPP Architecture Overview#

PPP operates in layers with modular components:

+-------------------------+
| Network Layer Protocol  |
|      (IP, IPX, AppleTalk) |
+-------------------------+
|    PPP NCP Suites       |  <--- Negotiation protocols per network layer
| (IPCP, IPXCP, ATCP etc.) |
+-------------------------+
| Authentication Protocols| 
|    (PAP, CHAP, EAP)     |
+-------------------------+
| Link Control Protocol   |
|         (LCP)           |  <--- Core control mechanism
+-------------------------+
| PPP Frame Encapsulation |  <--- HDLC-like framing
+-------------------------+
| Physical Layer (Serial, |
|   SONET/SDH, Ethernet)  |
+-------------------------+

Key Features:

  • Multi-protocol support through NCP
  • Dynamic link parameter negotiation
  • Loopback detection and link testing
  • Optional authentication framework

3. Frame Structure and Framing#

PPP uses HDLC-based framing with modifications for flexibility:

| Field     | Size   | Purpose                                 |
|-----------|--------|-----------------------------------------|
| Flag      | 1 byte | Delimiter (0x7E)                       |
| Address   | 1 byte | Broadcast address (0xFF)                |
| Control   | 1 byte | Unnumbered Information (0x03)          |
| Protocol  | 2 bytes| Encapsulated payload protocol (e.g., IP)|
| Data      | Var.   | Payload (max configurable)             |
| FCS       | 2/4    | Error detection (CRC)                  |
| Flag      | 1 byte | End delimiter (0x7E)                   |

Framing Methods:

  • Asynchronous Lines: Escape sequence (0x7D) used before control characters
  • Bit-Synchronous Links: Bit stuffing (five 1s insert 0)
  • SONET/SDH: Frame alignment via payload pointers

Example Payloads:

  • 0xC021 → LCP packet
  • 0x8021 → IP datagram
  • 0xC023 → PAP authentication

Responsible for link establishment, maintenance, and termination. Operates through four-phase negotiation:

  1. Link Configuration: Exchange Configure-Request packets containing options:

    +-------------------+----------+----------------------------------+
| Option            | Type     | Purpose                          |
+-------------------+----------+----------------------------------+
| Maximum-Receive   | 1        | Max frame size (default 1500B)  |
| Unit (MRU)        |          |                                  |
| Authentication     | 3        | Specify PAP/CHAP method         |
| Protocol           |          |                                  |
| Magic Number      | 5        | Loop detection (random value)   |
| Protocol Field    | 7        | Enable address/control field    |
| Compression       |          | compression                      |
| Quality Protocol  | 4        | Specify link quality monitor    |
+-------------------+----------+----------------------------------+

  2. Link Quality Testing: Echo-Request/Echo-Reply messages to verify connectivity

  3. Network Protocol Configuration: Triggered after link establishment

  4. Link Termination: Terminate-Request/Terminate-Acknowledge packets

Common Practice: Always configure Magic Number option to prevent routing loops!

5. Authentication Protocols#

Password Authentication Protocol (PAP)#

  • RFC 1334: Cleartext username/password exchange
  • Flow: 
    Client -------------------> Server
    (Authenticate-Request)
                        Client <------------------- Server
                                (Authenticate-Ack/NAK)

Risk: Vulnerable to sniffing. Use only where encryption exists at lower layers.

Challenge Handshake Authentication Protocol (CHAP)#

  • RFC 1994: Cryptographic challenge-response
  • Flow: 
    Client -------------------> Server
            (Challenge)
                        Client <------------------- Server
                        (Response=MD5(id+secret+challenge))
                                (Success/Failure)

Security: Requires pre-shared secret. Periodic re-authentication.

Extensible Authentication Protocol (EAP)#

  • RFC 2284: Framework supporting multiple methods (EAP-TLS, EAP-MD5)
  • Advantage: Flexible backend integration with RADIUS/TACACS+

Best Practice:

| Scenario          | Recommended Protocol | Why?                              |
|-------------------|----------------------|-----------------------------------|
| Plaintext Channel | Avoid PAP            | Credential exposure              |
| Unencrypted Lines | CHAP or EAP          | Cryptographic protection          |
| Large Enterprise  | EAP with RADIUS      | Centralized authentication        |

6. Network Control Protocol (NCP)#

Dynamically configures network-layer protocols after LCP establishes the link:

  • IP Control Protocol (IPCP): RFC 1332
    Negotiates IP addresses (static/dynamic) and optionally DNS servers via Configuration Options:

    Option 1: IP Address
Option 129: Primary DNS Server
Option 131: Secondary DNS Server

  • Example IPCP Negotiation:

    Client -> Server: Configure-Request(IP=0.0.0.0, DNS1=0.0.0.0)
Server -> Client: Configure-Nak(IP=192.168.1.2, DNS1=8.8.8.8)
Client -> Server: Configure-Request(IP=192.168.1.2, DNS1=8.8.8.8)
Server -> Client: Configure-Ack

7. PPP Session Lifecycle#

Complete state machine:

graph TD
    A[Link Dead] -->|Initialize| B(Link Establishment)
    B -->|Configure-Ack| C[Link Open]
    B -->|Configure-Nak/Reject| B
    C --> D[Authentication]
    D -->|Success| E[Network Layer Protocol]
    D -->|Failure| A
    E -->|NCP Complete| F[Data Transfer]
    F -->|Error/Loop detect| G[Link Termination]
    F -->|Idle Timeout| G
    G --> A

8. Common Implementations & Use Cases#

DSL Connections via PPPoE#

Configuration Example (Cisco):

interface Ethernet0
  pppoe enable
  pppoe-client dial-pool-number 1
!
interface Dialer1
  encapsulation ppp
  ip address negotiated
  ppp chap hostname USER@ISP
  ppp chap password SECRET
  ppp ipcp dns request

Real-World Flow:

  1. Client sends PPPoE Active Discovery Initiation (PADI)
  2. Access Concentrator replies with Offer (PADO)
  3. Session established via PADR/PADS

Router-to-Router Leased Line#

! Router A Configuration
interface Serial0/0
  encapsulation ppp
  ip address 10.0.0.1 255.255.255.252
  ppp authentication chap
  ppp chap hostname ROUTER_A
!
! Router B Configuration
interface Serial0/0
  encapsulation ppp
  ip address 10.0.0.2 255.255.255.252
  ppp authentication chap
  ppp chap hostname ROUTER_B
  ppp chap password shared_secret

9. Best Practices for Deployment#

  1. Mandatory CHAP/EAP: Avoid PAP unless explicitly required by legacy systems
  2. MRU/MSS Adjustment: Align MRU with physical media MTU (e.g., 1492 for PPPoE)
  3. Timeout Tuning:
    • Set ppp timeout authentication to 10 seconds
    • Configure LCP echo intervals < 60 seconds for failure detection
  4. Disable Compression: Modern processors handle payloads faster than compression algorithms
  5. Persistent LCP Echo: Add keepalive 10 3 on Cisco IOS for fault detection

10. Modern PPP Variations#

PPP over Ethernet (PPPoE)#

  • RFC 2516: Tunnel PPP frames over Ethernet networks
  • Benefit: ISP subscriber management via PPP authentication/IP assignment
  • Frame Overhead: 6 bytes (PPPoE header) + 6 bytes PPP = 12 bytes total

PPP over ATM (PPPoA)#

  • RFC 2364: Used in DSL networks over ATM adaptation layer
  • Efficiency: Lower overhead than PPPoE (no Ethernet header)

11. Conclusion#

PPP remains a resilient framework for point-to-point communications despite its age. Its modular design—separating core negotiation (LCP), authentication, and protocol transport (NCP)—provides flexibility that sustains relevance in modern networks. While primarily supplanted by Ethernet in LAN environments, PPP's adaptations (PPPoE, PPPoA) continue underpinning broadband infrastructures globally. Understanding PPP principles is essential for diagnosing legacy connections and appreciating contemporary protocol designs.

References#

  1. RFC 1661: "The Point-to-Point Protocol (PPP)"
  2. RFC 1662: "PPP in HDLC-like Framing"
  3. RFC 1994: "Challenge Handshake Authentication Protocol (CHAP)"
  4. RFC 2516: "A Method for Transmitting PPP Over Ethernet (PPPoE)"
  5. RFC 1332: "PPP Internet Protocol Control Protocol (IPCP)"
  6. Cisco IOS PPP Configuration Guides
  7. Microsoft Windows PPP Architecture Documentation
  8. ITU-T Recommendation X.25 (Packet Layer Protocol over PPP)

Revision History:

  • Initial Release: Sept 2023
  • Updated: Dec 2023 (Added EAP details)

Author: Network Engineering Team @ ProtocolInsights.org