PPPoE all you need to know and more!

PPPoE (Point-to-Point Protocol over Ethernet) operates as a Layer-2.5 protocol that enables traditional PPP session semantics to be transported over Ethernet-based access networks. The protocol consists of two distinct phases: the Discovery Phase and the Session Phase.

During the Discovery Phase, the client (CPE) broadcasts a PADI (PPPoE Active Discovery Initiation) frame to locate available access concentrators (ACs). An AC responds with a PADO (Offer), advertising its availability and supported services. The client then selects an AC and sends a PADR (Request), to which the AC replies with a PADS (Session-confirmation) frame, assigning a unique Session ID. At this point, a dedicated logical point-to-point session is established over the shared Ethernet medium.

Once in the Session Phase, PPP frames are encapsulated within Ethernet frames using the assigned Session ID. Standard PPP control protocols are then negotiated, including LCP (Link Control Protocol) for link parameters, authentication via PAP or CHAP, and NCPs (Network Control Protocols) such as IPCP for IPv4 or IPv6CP for IPv6 address negotiation. Authentication credentials are typically validated against a backend AAA system (e.g., RADIUS), allowing ISPs to apply per-user policies such as IP assignment, VLAN mapping, QoS profiles, rate limiting, and accounting.

PPPoE introduces an 8-byte overhead, reducing the effective Ethernet MTU from 1500 to 1492 bytes unless jumbo frames are supported end-to-end. Improper MTU handling can lead to fragmentation or PMTUD black-holing, making MSS clamping a common operational requirement on customer edge devices. Despite this overhead, PPPoE remains widely deployed due to its strong session control, granular subscriber management, and tight integration with billing, monitoring, and policy enforcement systems.

In modern ISP architectures, PPPoE sessions terminate on a Broadband Network Gateway (BNG) or BRAS, which acts as the policy enforcement point and subscriber edge. This design allows service providers to scale millions of concurrent sessions while maintaining isolation between subscribers, supporting advanced features such as per-session routing instances, lawful intercept, and seamless session re-establishment during access network changes.

Deep Dive

There are multiple stages for a PPPoE to work Discovery, Session, Data Transfer, Session Teardown 

Discovery Stage (EtherType 0x8863) 

These packets establish who you connect to and create the session. there are 4 sections involved in the discovery stage: PADI (Active Discovery Initiation), PADO (Active Discovery Offer), PADR (Active Discovery Request), PADS (Active Discovery Session-confirmation).

PADI (Active Discovery Initiation) 

The CPE is looking for an Access Concentrator. Client -> Broadcast This is because the client doesn’t yet know which AC to use. The packet should contain something like as follows 

Ethernet:
  Destination: ff:ff:ff:ff:ff:ff
  Source:      CPE-MAC
  EtherType:   0x8863 (PPPoE Discovery)

PPPoE Header:
  Version: 1
  Type:    1
  Code:    0x09 (PADI)
  Session: 0x0000

Tags:
  Service-Name: ""
  Host-Uniq: 0xA1B2C3D4

PADO (Active Discovery Offer) 

Access Concentrator -> Client  Multiple ACs may reply; the client chooses one.

Ethernet:
  Destination: CPE-MAC
  Source:      AC-MAC
  EtherType:   0x8863

PPPoE Header:
  Code:    0x07 (PADO)

Tags:
  Service-Name: ""
  AC-Name: "ISP-BNG-01"
  Host-Uniq: 0xA1B2C3D4

PADR (Active Discovery Request)  

Client -> Selected AC

Ethernet:
  Destination: AC-MAC
  Source:      CPE-MAC
  EtherType:   0x8863

PPPoE Header:
  Code:    0x19 (PADR)

Tags:
  Service-Name: ""
  Host-Uniq: 0xA1B2C3D4

PADS (Active Discovery Session-confirmation)

AC -> Client Session ID assigned Discovery phase complete

Ethernet:
  Destination: CPE-MAC
  Source:      AC-MAC
  EtherType:   0x8863

PPPoE Header:
  Code:    0x65 (PADS)
  Session: 0x001A

Session Phase (EtherType 0x8864)

Now PPP frames are encapsulated and real control begins. LCP (Link Control Protocol), Authentication (PAP or CHAP), IPCP (IPv4 Configuration) / IPv6CP (if enabled), 

LCP (Link Control Protocol)

  Negotiates link parameters

PPP:
  Protocol: 0xC021 (LCP)
  Code:     Configure-Request
  Options:
    MRU: 1492
    Magic-Number: 0xCAFEBABE

Authentication (PAP or CHAP)

  CHAP Example (most common)

PPP:
  Protocol: 0xC223 (CHAP)
  Code:     Challenge
  ID:       0x05
  Value:    random-challenge

Client response

PPP:
  Code:     Response
  Name:     username@isp
  Value:    MD5(challenge + secret)

BNG validates via RADIUS

RADIUS Access-Request:
  User-Name: username@isp
  CHAP-Password
  NAS-IP-Address

IPCP (IPv4 Configuration) / IPv6CP (if enabled)

  IP address negotiation

PPP:
  Protocol: 0x8021 (IPCP)
  Code:     Configure-Request
  Options:
    IP-Address: 0.0.0.0

BNG response:

PPP:
  Code:     Configure-Ack
  Options:
    IP-Address: 203.0.113.42

IPv6CP (if enabled)

PPP:
  Protocol: 0x8057 (IPv6CP)
  Interface-Identifier: ::1a2b:3c4d

Data Transfer (Encapsulated IP)

Once negotiated:

Ethernet
  └─ PPPoE Session (0x8864)
       └─ PPP
            └─ IP
                 └─ TCP / UDP

MTU Impact

• Ethernet MTU: 1500
• PPPoE overhead: 8 bytes
• Effective MTU: 1492
• TCP MSS usually clamped to 1452

Session Teardown

PADT (Active Discovery Terminate)

Either side can terminate

PPPoE Header:
  Code:    0xA7 (PADT)
  Session: 0x001A

Session state is cleared on the BNG and accounting stops.

Why ISPs Still Like PPPoE (at Packet Level)

• Stateless Ethernet + stateful PPP sessions
• Clean subscriber isolation
• Per-session policy injection
• Accurate accounting start/stop records
• Seamless integration with RADIUS, QoS, CGNAT, lawful intercept

Recent Articles