Point-to-Point Protocol over Ethernet
PPPoE was developed to address the need for connecting multiple hosts at a remote site through a single customer premises equipment (CPE) device while maintaining the access control, billing, and session management capabilities of traditional PPP dial-up connections. [^10^]
Before PPPoE, Internet Service Providers (ISPs) used PPP over dial-up modems, which provided excellent per-user authentication and accounting. With the advent of broadband technologies like DSL and cable, there was a need to maintain these PPP benefits while utilizing the cost-effective Ethernet infrastructure. RFC 2516, published in February 1999, standardized the PPPoE protocol. [^10^]
PPPoE functions at the Data Link Layer (Layer 2) of the OSI model, specifically operating between the Ethernet MAC layer and the Network Layer (IP). It creates a point-to-point tunnel over the inherently broadcast nature of Ethernet. [^5^]
Understanding how data is encapsulated in PPPoE:
Note: Total overhead = 6 bytes (PPPoE) + 2 bytes (PPP) = 8 bytes additional overhead compared to standard Ethernet.
PPPoE operates in two distinct stages that must be completed sequentially: [^2^][^3^]
The client discovers available Access Concentrators (ACs), establishes the Ethernet MAC address of the peer, and obtains a unique Session ID. This stage uses EtherType 0x8863. [^6^]
Once discovery completes, standard PPP negotiation occurs including authentication and IP configuration. This stage uses EtherType 0x8864. [^6^]
| Component | Description | Role |
|---|---|---|
| Host (Client) | User device or router initiating PPPoE connection | Initiates discovery, provides credentials, receives IP configuration |
| Access Concentrator (AC) | ISP equipment (BRAS/BNG) terminating PPPoE sessions | Responds to discovery, authenticates users, manages sessions |
| DSLAM/OLT | Digital Subscriber Line Access Multiplexer or Optical Line Terminal | Layer 2 aggregation between CPE and AC |
| RADIUS Server | Remote Authentication Dial-In User Service | Centralized authentication, authorization, and accounting |
The Discovery phase is a client-server process where the Host (client) locates one or more Access Concentrators (servers) and establishes a unique session identifier. [^3^] This phase is essential because PPP requires knowledge of the peer's Ethernet address, and Ethernet is inherently a multi-access medium.
The client broadcasts a PADI packet containing a Service-Name tag indicating the service it requests. This allows the client to discover all available ACs on the network. [^6^]
One or more ACs respond with PADO packets containing their names and the services they offer. The client may receive multiple PADOs if several ACs are available. [^6^]
The client selects one AC based on the AC-Name or services offered, then sends a PADR packet to request a session with that specific AC. [^6^]
The selected AC generates a unique Session ID and sends a PADS packet to confirm the session establishment. If the AC rejects the request, it sends a PADS with Session ID 0x0000 and a Service-Name-Error tag. [^6^]
Either the client or AC can terminate an established session at any time by sending a PADT (PPPoE Active Discovery Terminate) packet with Code 0xa7. The PADT contains the destination address and Session ID of the session to be terminated. Once sent, no further PPP traffic is allowed for that session. [^6^]
After successful discovery, the PPPoE session begins. During this phase, standard PPP protocols operate over the established PPPoE connection. The session uses EtherType 0x8864 and includes the Session ID in every packet. [^3^]
Link Control Protocol establishes, configures, and tests the data link connection. Parameters negotiated include:
User credentials are verified using:
Authentication is typically backed by a RADIUS server. [^11^]
Network Control Protocol configures network layer protocols:
The standard Ethernet MTU is 1500 bytes. PPPoE adds 8 bytes of overhead (6 bytes PPPoE header + 2 bytes PPP protocol field), reducing the effective MTU to 1492 bytes for the IP payload. [^2^] If RFC 4638 (Mini Jumbo Frames) is supported by the underlying Ethernet connection, larger MTUs may be possible. [^3^]
| Field | Size | Description |
|---|---|---|
| VER | 4 bits | PPPoE version, must be 0x1 |
| TYPE | 4 bits | PPPoE type, must be 0x1 |
| CODE | 8 bits | Packet type (0x00=Session, 0x09=PADI, 0x07=PADO/PADT, 0x19=PADR, 0x65=PADS) |
| SESSION_ID | 16 bits | Unique session identifier (0x0000 in discovery, assigned in PADS) |
| LENGTH | 16 bits | Length of PPPoE payload (does not include Ethernet or PPPoE headers) |
| Packet | Code | Session ID | Direction |
|---|---|---|---|
| PADI | 0x09 | 0x0000 | Client → Broadcast |
| PADO | 0x07 | 0x0000 | AC → Client (Unicast) |
| PADR | 0x19 | 0x0000 | Client → AC (Unicast) |
| PADS | 0x65 | Assigned | AC → Client (Unicast) |
| PADT | 0xa7 | Session ID | Client ↔ AC (Unicast) |
Discovery packets contain TLV (Type-Length-Value) tags: [^10^]
| Tag Type | Value | Description |
|---|---|---|
| Service-Name | 0x0101 | Required in PADI, PADO, PADR, PADS; identifies requested service |
| AC-Name | 0x0102 | Required in PADO; identifies the Access Concentrator |
| Host-Uniq | 0x0103 | Optional; used by client to match responses with requests |
| AC-Cookie | 0x0104 | Optional; state information for AC, helps prevent DoS attacks |
| Vendor-Specific | 0x0105 | Optional; vendor-specific extensions |
| Service-Name-Error | 0x0201 | Used in PADS when requested service not available |
PPPoE supports multiple authentication protocols, with PAP and CHAP being the most common. The choice of authentication method is negotiated during the LCP phase. [^11^]
CHAP requires passwords to be stored in plaintext (or reversible encryption) on the server to compute the expected hash response. [^1^][^4^]
ISPs typically use RADIUS (Remote Authentication Dial-In User Service) for centralized authentication. The NAS (Network Access Server) forwards authentication requests to a RADIUS server, which validates credentials and returns configuration parameters (IP address, DNS, session timeout, etc.). [^12^]
| RADIUS Attribute | Description |
|---|---|
| User-Name (1) | Username provided by PPPoE client |
| User-Password (2) | Password for PAP authentication (encrypted) |
| CHAP-Password (3) | CHAP response from client |
| NAS-IP-Address (4) | IP address of the access concentrator |
| Framed-IP-Address (8) | IP address assigned to client |
While PPPoE is widely used in DSL and some fiber networks, DHCP-based access (often called IPoE) has become increasingly popular for Ethernet and fiber-to-the-home (FTTH) deployments. [^9^][^13^]
| Feature | PPPoE | DHCP/IPoE |
|---|---|---|
| Authentication | Per-user authentication (username/password) | Typically circuit-based (port/VLAN) or MAC authentication |
| Session Management | Explicit session establishment and termination | Lease-based, implicit sessions |
| Overhead | 8 bytes PPPoE + PPP headers, reduced MTU (1492) | No additional overhead, standard MTU (1500) |
| Configuration | Requires username/password configuration | Plug-and-play, automatic configuration |
| Scalability | Session state maintained per subscriber | More scalable, stateless operation |
| Roaming | Easy session mobility (any port) | Tied to physical circuit or requires additional mechanisms |
| Use Cases | DSL, legacy networks, per-user accounting needed | FTTH, cable, high-speed enterprise networks |
PPPoE is predominantly used in:
Strong per-user authentication ensures only authorized users access the network. Credentials can be easily provisioned and revoked.
Session-based accounting allows for time-based or volume-based billing. RADIUS provides detailed usage records.
Different service tiers can be offered based on username/domain, with different bandwidth limits and QoS policies.
| Issue | Possible Cause | Solution |
|---|---|---|
| PADI timeout | No AC available, physical layer issue | Check DSL sync, verify VLAN configuration |
| Authentication failure | Wrong credentials, RADIUS unreachable | Verify username/password, check RADIUS server status |
| IP configuration failure | IP pool exhausted, IPCP negotiation failed | Check address pools, verify NCP configuration |
| MTU/MSS issues | Large packets being dropped | Enable TCP MSS clamping, verify 1492 byte MTU |