Point-to-Point Protocol over Ethernet
Point-to-Point Protocol over Ethernet (PPPoE) is a networking protocol that encapsulates Point-to-Point Protocol (PPP) frames within Ethernet frames to enable the creation of point-to-point connections over shared Ethernet broadcast domains, particularly in broadband access scenarios.[1] Developed to address the limitations of bridging multiple hosts to a remote access concentrator without per-user control, PPPoE allows Internet service providers (ISPs) to implement authentication, authorization, and accounting (AAA) on an individual basis while leveraging the familiarity of PPP for multi-protocol datagram transport.[1] It combines the link-layer capabilities of Ethernet with PPP's session management, encryption, compression, and error detection features, making it suitable for environments where direct point-to-point links are not feasible.[1] PPPoE was formalized in RFC 2516, published by the Internet Engineering Task Force (IETF) in February 1999 as an informational specification, drawing from concepts developed by the ADSL Forum to support emerging digital subscriber line (DSL) technologies.[1] At the time, broadband access was shifting toward Ethernet-based aggregation, and PPPoE provided a bridge between traditional PPP over asynchronous transfer mode (ATM) in DSL setups and Ethernet infrastructures, enabling scalable deployment without requiring new hardware at customer premises.[2] Contributors from organizations such as UUNET, RedBack Networks, and RouterWare drove its creation to facilitate per-mac-address or per-user billing and access control in bridged networks.[1] The protocol operates in two primary stages: a Discovery stage, where the client (host) identifies the access concentrator's MAC address and negotiates a unique session identifier (SESSION_ID) using Ethernet protocol types 0x8863 for discovery packets and 0x8864 for session data; and a subsequent PPP Session stage, during which encapsulated PPP frames are exchanged for authentication and data transfer.[1] This design ensures compatibility with existing PPP implementations while adding Ethernet overhead, typically resulting in a maximum transmission unit (MTU) of 1492 bytes to accommodate the 8-byte PPPoE header.[3] In DSL broadband networks, PPPoE is commonly deployed over Ethernet interfaces at the customer edge, often in conjunction with access nodes that translate from PPP over ATM (PPPoA) to PPPoE for aggregation to the broadband network gateway (BNG).[2] PPPoE remains a cornerstone for DSL and fiber-to-the-x (FTTx) access, supporting multi-session capabilities per port, dynamic IP assignment, and quality-of-service (QoS) differentiation, though it introduces slight overhead compared to native IP over Ethernet (IPoE).[2] Its widespread adoption in the late 1990s and early 2000s facilitated the global rollout of high-speed internet, and it continues to be used in regions with legacy DSL infrastructure for secure, managed connectivity.[1]History and Development
Origins in Broadband Adoption
In the late 1990s, the rapid shift from dial-up internet access to broadband technologies, particularly asymmetric digital subscriber line (ADSL), created a need for protocols that could adapt established authentication and management practices to always-on connections. Traditional Point-to-Point Protocol (PPP), widely used for dial-up services, supported per-call authentication and session-based billing but was incompatible with the persistent nature of broadband links, which did not involve repeated dialing. PPPoE emerged in 1998–1999 as a solution to encapsulate PPP frames within Ethernet, enabling service providers to leverage existing PPP infrastructure for DSL deployments without overhauling network architectures or customer premises equipment.[1] The protocol was initially proposed by teams from UUNET Technologies, Redback Networks, and RouterWare to resolve the inherent broadcast-oriented design of Ethernet, which conflicted with the point-to-point session requirements of PPP in broadband scenarios. Key contributors included Louis Mamakos, Kurt Lidl, and Jeff Evarts from UUNET; David Carrel and Dan Simone from Redback Networks; and Ross Wheeler from RouterWare. A pivotal event was the IETF BOF session in August 1998 at IETF 42, chaired by Mamakos, where service providers outlined requirements for PPPoE, such as support for multiple sessions per device, compatibility with bridged RFC 1483/1490 encapsulations, and minimal configuration for access concentrators.[1][4] The DSL Forum (now the Broadband Forum) significantly promoted PPPoE to accelerate ADSL network rollout, recognizing its potential for cost-effective, scalable broadband access. The forum's early technical recommendations, including TR-025 in 1999, advocated PPP-based aggregation models that aligned with PPPoE, facilitating wholesale ISP interconnects and RADIUS authentication integration for mass-market services. This endorsement addressed the socio-technical drivers of the era, bridging dial-up legacies with emerging DSL infrastructure amid surging consumer demand for high-speed internet.[1][5]Key RFCs and Standardization
The Point-to-Point Protocol over Ethernet (PPPoE) was first formally specified in RFC 2516, published in February 1999 as an Informational document by the Internet Engineering Task Force (IETF).[1] This RFC, authored by engineers from UUNET Technologies, RedBack Networks, and RouterWare, outlines the encapsulation of PPP frames within Ethernet frames, detailing the discovery stage for peer identification and session establishment, as well as the session stage for PPP data transmission.[1] It defines key packet types in the discovery process, including PADI (Active Discovery Initiation), PADO (Active Discovery Offer), PADR (Active Discovery Request), PADS (Active Discovery Session-confirmation), and PADT (Active Discovery Terminate).[1] Subsequent RFCs extended PPPoE functionality. RFC 3817, published in June 2004 as an Informational document, introduces support for PPPoE relay agents by defining mechanisms to relay Active Discovery messages over Layer 2 Tunneling Protocol (L2TP) control channels, facilitating integration in access aggregation networks.[6] For IPv6 support, RFC 5072, published in September 2007 on the Standards Track, specifies the transmission of IPv6 packets over PPP links, including the IPv6 Control Protocol (IPv6CP) for configuration and link-local address formation, which applies directly to PPPoE sessions carrying PPP.[7] RFC 2516's Informational status, rather than Standards Track, provided implementation flexibility but contributed to variations in vendor-specific deployments, as it was not subject to the same progression through Proposed and Draft Standards.[1] The core PPPoE specification resulted from an individual submission following IETF BOF discussions, while subsequent extensions were developed within the IETF's PPP Extensibility (PPPEXT) Working Group, which focused on extending PPP for new encapsulations and protocols.[8] Beyond IETF efforts, the Broadband Forum's Technical Report TR-101, first issued in 2006 and updated through 2011, adapted PPPoE for Ethernet-based DSL aggregation architectures, enabling migration from ATM to Ethernet in broadband access networks.[9]Protocol Overview
Core Components and Encapsulation
The Point-to-Point Protocol over Ethernet (PPPoE) establishes a point-to-point connection over Ethernet by encapsulating PPP frames within Ethernet frames, enabling the transport of PPP payloads across shared Ethernet broadcast domains typically found in broadband access networks. This encapsulation inserts a 6-byte PPPoE header directly between the Ethernet header and the PPP payload, allowing multiple PPP sessions to coexist on the same Ethernet segment through unique session identifiers. The header consists of a 4-bit Version field (set to 1), a 4-bit Type field (set to 1), an 8-bit Code field (used for discovery packets or set to 0 for session data), a 16-bit Session ID field (0 during discovery and unique thereafter), and a 16-bit Length field indicating the PPPoE payload size in octets.[1] PPPoE's core components include the PPPoE Active Discovery (PPPoED) mechanism for session initiation and the PPPoE Session (PPPoES) for ongoing data transfer. PPPoED operates over Ethernet type 0x8863 and uses specific code values in discovery packets to negotiate a session ID and identify the peer's MAC address, ensuring a virtual point-to-point link amid multi-access Ethernet. Once established, PPPoES employs Ethernet type 0x8864 with a code of 0 and the assigned session ID to carry encapsulated PPP frames bidirectionally.[1] Unlike native PPP, which assumes a direct physical link without addressing concerns, PPPoE incorporates Ethernet addressing (source and destination MAC addresses in the outer frame) to manage broadcast domains in local area networks bridging to wide area networks, such as DSL access multiplexers. This adaptation addresses the need for session multiplexing on shared media while preserving PPP's protocol stack. PPPoE builds on foundational PPP elements, including the Link Control Protocol (LCP) for link establishment and negotiation, Network Control Protocols (NCPs) like IPCP for IP address assignment, and authentication methods such as Password Authentication Protocol (PAP) or Challenge-Handshake Authentication Protocol (CHAP).[1][10]High-Level Stages
The Point-to-Point Protocol over Ethernet (PPPoE) operates through two primary high-level stages: the Discovery Stage and the PPP Session Stage. These stages establish a virtual point-to-point connection over a shared Ethernet broadcast domain, allowing the encapsulation of PPP frames within Ethernet frames to facilitate authenticated access to an Internet Service Provider (ISP) network.[1] In the Discovery Stage, the client device initiates the process by broadcasting a request to identify available access concentrators (servers) on the local Ethernet segment. Responding servers offer their services, and the client selects one by sending a targeted request. The chosen server then confirms the selection by assigning a unique session identifier (Session ID) and confirming the peers' Ethernet addresses, thereby concluding the discovery process and preparing for the transition to the session phase. This stage ensures mutual identification without requiring prior configuration of Ethernet addresses, enabling dynamic peer discovery in multi-access environments.[1] Once the Discovery Stage completes, the process advances to the PPP Session Stage, where the established Session ID encapsulates PPP packets for transmission between the client and server over Ethernet. This stage leverages standard PPP mechanisms for link establishment, authentication (such as PAP or CHAP), and network layer configuration, including IP address assignment by the ISP. The overall role of these stages is to create a logical point-to-point link that supports ISP-specific functions like user authentication and usage-based billing, while maintaining compatibility with Ethernet's broadcast nature.[1]Discovery and Session Management
PPPoE Discovery Protocol
The PPPoE Discovery Protocol establishes a logical point-to-point link between a client (host) and server (access concentrator) over Ethernet prior to PPP session initiation, enabling the assignment of a unique session identifier and service negotiation. This phase involves a series of packet exchanges to discover available access concentrators, select services, and confirm the session, all encapsulated within Ethernet frames using the EtherType0x8863 to distinguish discovery packets from session data.[1]
The discovery sequence begins with the host broadcasting a PADI (PPPoE Active Discovery Initiation) packet (code 0x09, session ID 0x0000) to all potential access concentrators on the Ethernet segment, using the broadcast destination address ff:ff:ff:ff:ff:ff; this packet may include a Service-Name tag (type 0x0101) to specify desired services, such as those offered by a particular ISP.[1] Access concentrators that support the requested service respond individually with a unicast PADO (PPPoE Active Discovery Offer) packet (code 0x07, session ID 0x0000) to the host's MAC address, including their AC-Name tag (type 0x0102) and any matching Service-Name tags to advertise capabilities.[1] The host then selects one access concentrator and sends a unicast PADR (PPPoE Active Discovery Request) packet (code 0x19, session ID 0x0000) to it, potentially repeating the Service-Name tag.[1] Upon receipt, the access concentrator assigns and sends a PADS (PPPoE Active Discovery Session-confirmation) packet (code 0x65) with a unique 16-bit session ID (non-zero value) and the confirmed Service-Name tag, marking the transition to the PPP session phase.[1] To terminate the session during discovery or later, either peer may send a unicast PADT (PPPoE Active Discovery Terminate) packet (code 0xa7) using the established session ID, after which no further PPPoE packets (except additional PADTs) should be processed.[1]
Discovery mechanics rely on Ethernet broadcast for initial outreach and unicast for subsequent exchanges to minimize network overhead, with the destination MAC address set to broadcast only for PADI and unicast otherwise within the 0x8863 EtherType frame.[1] Service-Name tags allow hosts to filter and select ISPs or specific broadband services during PADO responses, enabling multi-ISP environments on shared Ethernet segments.[1] For hosts initiating multiple concurrent discoveries, a Host-Uniq tag (type 0x0103) with arbitrary unique data (e.g., a random value) is included in PADI and PADR packets and echoed back in responses, ensuring proper matching of replies without ambiguity.[1]
The 16-bit session ID field, set to 0x0000 during discovery and assigned a unique non-zero value in the PADS packet, identifies each PPPoE session per access concentrator on the Ethernet segment, preventing conflicts in multi-session scenarios.[1] This ID remains valid until a PADT is received, after which it may be reused for a new session to the same host.[1]
Error handling in the discovery protocol uses dedicated error tags within PADO or PADS packets to indicate failures, such as Service-Name-Error (type 0x0201) for unavailable services, AC-System-Error (type 0x0202) for concentrator issues, or Generic-Error (type 0x0203) for other problems; these may include a UTF-8 string explanation. Success is indicated by the absence of error tags.[1] Retransmission timers, with intervals doubled for each retry, and retry limits ensure robustness against packet loss without indefinite looping.[1]
PPP Session Negotiation
Once the PPPoE Discovery phase assigns a unique Session ID, the client and server transition to the PPP Session phase, where PPPoE Session (PPPoES) frames with EtherType 0x8864 encapsulate PPP control and data packets over Ethernet, using the established Session ID and MAC addresses for unicast communication.[11][12] The session begins with negotiation of the Link Control Protocol (LCP), which establishes and configures the point-to-point link, including mandatory options like Magic Numbers for loopback detection and a Maximum Receive Unit (MRU) limited to 1492 octets to account for PPPoE overhead.[13] Following successful LCP negotiation, authentication occurs if enabled, using protocols such as the Password Authentication Protocol (PAP) for simple username-password verification or the Challenge Handshake Authentication Protocol (CHAP) for more secure challenge-response exchanges. Subsequently, Network Control Protocols (NCPs) are negotiated; for IP connectivity, the Internet Protocol Control Protocol (IPCP) handles IPv4 address assignment and compression options, while IPv6CP supports IPv6 addressing in dual-stack environments. Session maintenance relies on periodic LCP Echo-Request and Echo-Reply packets to monitor link viability and detect failures, ensuring the session remains active without unnecessary termination. Termination can be initiated by either peer sending an LCP Terminate packet to cleanly close the PPP link or a PPPoE Active Discovery Terminate (PADT) packet (code 0xA7) to end the PPPoE session entirely, after which a new Discovery phase is required for reconnection.[14][15] In the active session, user data flows as PPP payloads encapsulated within PPPoES frames, supporting standard PPP extensions for enhanced performance and security.[12] For instance, compression and encryption can be applied via Microsoft Point-to-Point Encryption (MPPE), which uses RC4-based encryption to protect traffic confidentiality without altering packet lengths.[16] Multilink PPP (MLPPP) enables bonding of multiple physical links into a single logical channel for increased bandwidth and load balancing, with fragments reassembled at the receiver.[17] A key feature of the PPP Session phase is the persistence of the 16-bit Session ID, which uniquely identifies the session for its duration and facilitates per-user accounting, traffic monitoring, and Quality of Service (QoS) differentiation in broadband networks.[18][19]Technical Details
Frame Structure and Overhead
The PPPoE frame is constructed by encapsulating PPP frames within an Ethernet frame, adding specific headers to enable point-to-point communication over Ethernet networks. The overall structure consists of a standard Ethernet header (14 bytes: 6 bytes destination MAC address, 6 bytes source MAC address, and 2 bytes EtherType field set to 0x8864 for session frames or 0x8863 for discovery frames), followed by the PPPoE header (6 bytes), the PPP protocol ID (2 bytes for session frames), the PPP payload, and an Ethernet frame check sequence (FCS) trailer (4 bytes).[20][21]| Field | Size (bytes) | Description |
|---|---|---|
| Destination MAC | 6 | Unicast or broadcast address of the recipient. |
| Source MAC | 6 | MAC address of the sender. |
| EtherType | 2 | 0x8863 (Discovery) or 0x8864 (Session). |
| PPPoE Header | 6 | Version/Type (1 byte), Code (1 byte), Session ID (2 bytes), Length (2 bytes). |
| PPP Protocol ID | 2 | Identifies the PPP protocol (e.g., 0x0021 for IP); absent in discovery frames. |
| PPP Payload | Variable | PPP data or discovery tags (TLV format: 2-byte type + 2-byte length + value). |
| FCS | 4 | Ethernet checksum for error detection. |