PPPoE and IPoE step by step

Theoretical foundations and architecture

BNG architectures use two primary subscriber models: PPPoE (RFC 2516) and IPoE (IP over Ethernet: a DHCP-based session without PPP, described by Broadband Forum specifications such as TR-101 and TR-146 rather than by a single RFC). 1. PPPoE carries a PPP session between the CPE and the BNG in two phases: Discovery (PADI broadcast by the client, PADO offer from the BNG, PADR request by the client, PADS confirmation with the Session ID, PADT teardown) and PPP Session (LCP negotiating link parameters and an MRU of 1492, PAP/CHAP authentication, IPCP/IPv6CP addressing). Strengths: built-in authentication, a familiar session model and easy disconnection of non-paying users. Drawbacks: 8 bytes of overhead (needs MSS clamping or RFC 4638), a PPP state machine and keepalives in the control plane, and awkward multicast IPTV; modern BNGs still forward the data in hardware. 2. IPoE is tunnel-less access based on DHCP (DHCPv4 Option 82 / DHCPv6 Options 18/37). The access switch inserts a Circuit-ID (port) and a Remote-ID (access node); the BNG identifies the line from them and asks RADIUS to authorize it, so no login or password is typed. Option 82 only identifies the line, it does not authenticate it: it can be trusted only when your own access switch inserts and filters it. The MTU stays at 1500.

PPPoE: two phases and the frame format

PPPoE (RFC 2516) carries PPP inside Ethernet. Discovery frames use EtherType 0x8863 and session frames use 0x8864. The PPPoE header (6 bytes) is: Version=1 (4 bits), Type=1 (4 bits), Code (1 byte), Session-ID (2 bytes), Length (2 bytes); it is followed by the 2-byte PPP Protocol field. The total overhead is 8 bytes: with an Ethernet MTU of 1500 the maximum IP packet is 1492, which is why the default MRU is 1492. RFC 4638 (the PPP-Max-Payload tag) allows negotiating 1500 if the MTU along the whole path is at least 1508 (baby-jumbo), but not all CPEs support it.

Discovery is four packets and TLV-formatted tags:

• PADI (Code 0x09), broadcast ff:ff:ff:ff:ff:ff, Session-ID 0: the client looks for a concentrator; tags Service-Name (0x0101, empty = "any"), Host-Uniq (0x0103).
• PADO (0x07), unicast: the BNG offers itself; tags AC-Name (0x0102) and Service-Name, and if needed AC-Cookie (0x0104) against PADR floods.
• PADR (0x19), unicast: the client picks one of the PADOs and requests a session.
• PADS (0x65): the BNG assigns a Session-ID (1-65535, unique per client MAC + BNG MAC pair) and confirms.
• PADT (0xA7): either side tears the session down. The client repeats PADI with exponential back-off; an empty answer means that the service-name did not match, the VLAN is wrong or the sessions per-mac limit is exhausted.

PPP: LCP, authentication, NCP

After PADS comes PPP on 0xC021 (LCP): Configure-Request/Ack/Nak/Reject, with the options MRU (1), Authentication-Protocol (3) and Magic-Number (5). The Magic-Number lets a loop be detected, and Echo-Request/Reply is the keepalive (usually an interval of 10-30 s, 3-5 losses = teardown). Authentication: PAP (0xC023) sends the password in clear text once, the client initiates; CHAP (0xC223, RFC 1994) - the BNG sends a random challenge and the client answers with MD5(id + secret + challenge), the password never crosses the link, and the BNG may repeat the challenge during the session. For RADIUS the CHAP variant is carried in the CHAP-Password and CHAP-Challenge attributes; the server must know the secret in clear or reversible form. Then NCP: IPCP (0x8021) negotiates the IP-Address (option 3) and DNS servers (129/131, RFC 1877); IPv6CP (0x8057) negotiates only the 64-bit Interface-Identifier, while the prefix is delivered outside PPP: SLAAC (RA from the BNG) for the WAN address and DHCPv6 IA_PD (RFC 8415) for the delegated LAN prefix (usually /56 or /60). The IPv4 address from IPCP is a /32 point-to-point: the BNG installs a /32 route towards the session's virtual interface.

IPoE: DHCP instead of PPP

IPoE creates no tunnel: the client sends a DHCPv4 Discover (RFC 2131) straight into Ethernet, and the BNG acts as a DHCP server or relay (giaddr = BNG address). A session is the combination MAC + (S-VLAN, C-VLAN) + option 82; the BNG creates it on the first packet (a DHCP Discover or any unclassified IP/MAC packet) rather than through a dedicated protocol. Authorisation goes to RADIUS: User-Name = the MAC or the Circuit-ID/Remote-ID from option 82 (sub-options 1 and 2, RFC 3046), so the subscriber enters no password and is bound to the port. For unauthorised users (first connection, zero balance) the BNG creates a "restricted" session in a walled garden: DNS and an HTTP redirect to the payment portal, and after the data is entered the billing system sends a CoA and the session is moved to the working profile. DHCPv6 uses IA_NA/IA_PD and options 18/37 (Interface-ID/Remote-ID). The standards for IP sessions are Broadband Forum TR-101 and TR-146.

The BNG determines the liveness of an IPoE session indirectly: by the DHCP lease and by ARP/ICMP probes of the client address; if there is no answer, the session is closed and accounting stops. Limits on the number of addresses per port and MAC-IP binding (IP source guard/anti-spoofing) are enforced on the BNG based on the DHCP binding.

Comparison and choice of model

A modern BNG forwards both kinds of traffic in hardware, so the difference lies mostly in the control plane (PPP state machine, CHAP, keepalive) and in the customer equipment.

MTU and MSS

The MSS for IPv4 over PPPoE is 1492 - 20 (IP) - 20 (TCP) = 1452; for IPv6 it is 1492 - 40 - 20 = 1432. If ICMP "fragmentation needed" (type 3 code 4) or ICMPv6 Packet Too Big is filtered, Path MTU Discovery breaks and sites with large responses hang after the TCP handshake. The cure is MSS clamping on the BNG (ip tcp adjust-mss, tcp-mss/change-tcp-mss) and allowing ICMP. For IPoE the MTU equals Ethernet, but on the way to the BNG account for the tags (4 bytes each).