| Internet-Draft | SRv6 for PPPoE | July 2026 |
| Huang, et al. | Expires 19 January 2027 | [Page] |
This document proposes a method that employs SRv6 underlay tunnel to transport PPPoE session information across broadband networks. By leveraging the programmability of SRv6 SIDs, the approach not only delivers trusted authentication and secure subscriber access, but also enables operators to offer differentiated services and flexibly instantiate network functions for broadband users.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document proposes a method of transmitting PPPoE session information through SRv6 underlay tunnel technology. By leveraging the PPPoE session management capabilities and the programmability of SRv6 [RFC8986], it not only provides broadband users with trusted authentication and secure access but also meets the operators' needs for ensuring differentiated services and flexibly deploying specific services.¶
This draft focuses on substantiating the necessity of PPPoE over SRv6 based on emerging service requirements (Section 2), and on the corresponding PPPoE over SRv6 encapsulation (Section 3), the SID design philosophy (Section 4), the SID format (Section 5), and pseudocode-level implementation (Section 6). The applicability of PPPoE over SRv6 in real-world deployments-including how the CPE obtains the SRv6 SID of the network anchor, as well as the end-to-end procedure from the first dial-up to the second dial-up is out of scope for this document and will be described in a separate draft.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Refer to [RFC2516], [RFC8986] for the key terms used in this document.¶
PPPoE over SRv6 is expected to extensive deployed in intensive data transmission scenarios. This section substantiates the necessity of PPPoE over SRv6 by examining emerging service requirements, solution requirements, and the corresponding technical requirements.¶
Regarding service requirements, data-intensive workload transmission is frequently employed in scenarios such as scientific computing and inter-site AI model placement. Such services exhibit five principal characteristics: periodic generation, massive volume, significant impact on Internet access services, extremely high cost, and the need for deterministic assurance.¶
From a solution perspective: 1) The requirements of periodicity and massive volume imply that there is no need to lease long-term private lines; instead, the access circuit (AC) for Internet access SHOULD be reused and adjusted to carry giant traffic volumes within a dedicated time scope. This further entails a technical implementation whereby the client performs a secondary dial-up to re-negotiate bandwidth, as well as activation and de-activation times, with the new network anchor. 2) The requirement of "great impact on Internet access service" dictates that different services MUST be carried by separate network planes (eg. different network slice) and steered to distinct anchors. The associated technical realization requires a first dial-up for Internet access service to the BRAS, and a second dial-up for intensive data transmission to another network anchor. 3) The "extremely high cost" nature of such traffic necessitates that charging SHOULD NOT be monthly based; rather, it MUST be metered in minutes or finer granularity. The technical approach leverages the widely deployed PPPoE protocol for its advantages in authentication, charging, and service keep-alive, among others.¶
+--------+ +--------------+
| DC | | Controller |
+--------+ +--------------+
| |
| |
+--------+ +--------+
| Network+----------+ BRAS |
| Anchor | | |
+--+-----+ +--+-----+
\ /
\ 2nd dial-up /
\ / 1st dial-up
+-------------+
| CPE |
+-------------+
Notably, the network anchor (PPPoE Server) MAY not reside within the same Layer 2 domain as the PPPoE client. PPPoE over IP is therefore required to break the restriction of Layer 2. When selecting the IP-layer protocol, SRv6 is capable of programming SID behaviors to bind dedicated network slices or other value-added services (VAS) and consequently it represents a preferable underlay solution for intensive data transmission services. It is concluded that PPPoE over SRv6 is required for intensive data transmission service¶
+---------------------------+ | Payload | +---------------------------+ | ppp | +---------------------------+ | PPPoE Session | +---------------------------+ | Ethernet | | EtherType=0x8863/0x8864 | +---------------------------+ | IPv6 header, nh=143 | +---------------------------| | Ethernet | +---------------------------+ | Phsical Layer | +---------------------------+ | Physical | +---------------------------+
+---------------------------+ | Payload | +---------------------------+ | ppp | +---------------------------+ | PPPoE Session | +---------------------------+ | Ethernet | | EtherType=0x8863/0x8864 | +---------------------------+ | SRH header, nh=143 | +---------------------------| | Ethernet | +---------------------------+ | Phsical Layer | +---------------------------+ | Physical | +---------------------------+
PPPoE over SRv6 is categorized into two modes: SRv6 BE and SRv6 Policy, with their respective encapsulations illustrated in Figure 2 and Figure 3. The PPPoE header comprises an Ethernet header, a PPPoE session header, and a PPP header. The Ethernet EtherType field value of 0x8863 denotes the PPPoE Discovery stage, while a value of 0x8864 indicates the PPPoE Session stage.¶
PPPoE, which is defined in [RFC2516], is roughly divided into two phases: the Discovery Phase and the Session Phase. These two phases transport distinct categories of messages. Depending on the functional role of the transmitted messages, different Endpoint behavior design approaches MUST be adopted.¶
Signaling messages are exchanged between the PPPoE client and the PPPoE server, and there is no requirement for deterministic transport guarantees over a subsequent network segment. Therefore, END.DX2 MAY be used directly.¶
The Discovery Phase employs Ethertype 0x8863 and is primarily used for server discovery, server selection, session request by the client, and unique Session ID assignment by the server. The corresponding Discovery signaling messages and their PPP header Protocol values are as follows: PADI (Code=0x09), PADO (Code=0x07), PADR (Code=0x19), and PADS (Code=0x65).¶
The Session Phase employs Ethertype 0x8864 and is mainly used to establish the PPP link based on the discovered parameters and to transfer data. Within the link establishment sub-phase, the signaling messages and their PPP header Protocol values are: LCP (0xC021) for link parameter negotiation; PAP (0xC023) / CHAP (0xC223) for authentication; and NCP (0x8021) for network-layer parameter negotiation. Additionally, during the data transfer stage, certain signaling messages are also present, e.g., LCP (0xC021) is used for session keep-alive.¶
These signaling messages exist solely between the PPPoE client (CPE) and the PPPoE server (network anchor), with no need for onward transmission to a subsequent network segment (e.g., no requirement for intensive data transfer). Consequently, deterministic network guarantees (such as network slicing or QoS) are not required. END.DX2 SHOULD be used directly, and the PPPoE tunnel decapsulation operation can be performed within the device's PPPoE module.¶
After egressing the PPPoE server, plain user data packets(PPP protocol value=0x0021(IPv4)/0x0057(IPv6)) require deterministic transport guarantees in the subsequent network; thus, new END behaviors MUST be defined to bind the packet to value-added services (VAS) of the network.¶
The plain user data packet needs to be steered to a VAS (e.g., network slice) for low-latency or low packet-loss guarantees. After PPPoE header decapsulation, the plain user data remains. SLICE ID A(for example) needs to be inserted into the IP header for the purpose of network slice steering. If only END.DX2 is used, the PPPoE packet remains intact, and there is no opportunity to program the VAS steering behavior into the END behavior for the plain user data packet.¶
In conclusion, for PPPoE signaling messages, the existing END.DX2 SHOULD be used, while for PPPoE user data packets, new END behaviors need to be defined (see Section 5 for details).¶
The SID format in this draft conforms to the SID format defined in [RFC8986].¶
This section defines two Endpoint behaviors, which are used to bind two representative differentiated services. If additional services be introduced in the future, corresponding behaviors MAY be defined subsequently. The introduced behaviour inludes:¶
End.D.addslice.PPPOE, which is defined as Endpoint with decapsulation and add Slice ID value to the IP header Upper-Layer header type == 0x0021 (IPv4) /0x0057 (IPv6).¶
End.D.adddscp.PPPOE, which is defined as Endpoint with decapsulation and add DSCP value to the IP header Upper-Layer header type == 0x0021 (IPv4) /0x0057 (IPv6).¶
It should be noted that the term "Decapsulation" as used in this document differs from that specified in [RFC8986], which mandates removal of the outer IPv6 header together with all its extension headers. In contrast, the "Decapsulation" defined herein requires, in addition to the removal of the outer IPv6 header and all its extension headers, the removal of the PPPoE headers (i.e., the Ethernet header, the PPPoE session header, and the PPP header).¶
When N receives a packet destined to S and S is a local End.D.addslice.PPPOE SID,N does the following:¶
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an D.addslice.PPPOE, N does the following:¶
S01. if (Upper-Layer header type == 143 (Ethernet)) {
S02. Remove the outer IPv6 header with all its extension headers;
S03. if (Upper-Layer header type == 0x8864 (PPPOE session phase)) {
S04. Remove the ethernet header and PPPOE session header;
S05. if (Upper-Layer header type == 0x0021 or 0x0057 ) {
S06. Remove the PPP header and add slice ID value
to the IP header;
S07. } else {
S08. Process as End.DX2 (for non-user data PPP payload);
S09. }
S10. } else {
S11. Process as End.DX2 (for non-PPPoE session-phase ethernet);
S12. }
S13. } else {
S14. Process as End.DX2;
S15. }
When N receives a packet destined to S and S is a local End.D.adddscp.PPPOE,N does the following:¶
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard
the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.D.adddscp.PPPOE, N does the following:¶
S01. if (Upper-Layer header type == 143 (Ethernet)) {
S02. Remove the outer IPv6 header with all its extension headers;
S03. if (Upper-Layer header type == 0x8864 (PPPOE session phase)) {
S04. Remove the ethernet header and PPPOE session header;
S05. if (Upper-Layer header type == 0x0021 or 0x0057) {
S06. Remove the PPP header and add DSCP
value to the IP header;
S07. } else {
S08. Process as End.DX2 (for non-user data PPP payload);
S09. }
S10. } else {
S11. Process as End.DX2 (for non-PPPoE session-phase ethernet);
S12. }
S13. } else {
S14. Process as End.DX2;
S15. }
The SRv6 SID is consisted of LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits of arguments (ARG). The SID format is defined in [RFC8986].¶
The PPPoE client and PPPoE server deploy SRv6 tunnel across the broadband networks. The PPPoE client and server are required to enable for SRv6 and advertise SRv6 SIDs. The SRv6 SID is in the Destination Address field of an IPv6 header of a packet in this document. Specifically.¶
The locator is the Prefix Delegation assigned by the IPv6 access gateway.¶
The function defines the processing behavior executed at an SRv6 Segment Endpoint node.¶
The arguments are optional parameters, used for the identifier of service type, such as VLAN ID used in this document.¶
This document introduces new SRv6 Function types to support PPPoE operations, which require an extension based on [RFC8986]. Specifically, the PPPoE server should support the following Functions.¶
End.DXPPPoE SID (Decapsulation and IPv4 Cross - connect): The behaviors associated with this SID is endpoint behavior with decapsulation and IPv4 cross-connect. The processing actions involve stripping the IPv6 tunnel header, the PPPoE header, and the PPP header, and then forwarding the decapsulated IPv4/IPv6 packet to a specific next-hop through the Layer 3 interface associated with this SID.¶
End.DX3PPPoE SID (Decapsulation and PPPoE L3VPN table lookup): The behaviors associated with this SID is endpoint behavior with decapsulation and PPPoE L3VPN table lookup. The processing actions involve removing the IPv6 tunnel header, the PPPoE header, and the PPP header, and then performing a VPN lookup and forwarding based on the inner-layer PPPoE session information in the packet. This SID is mainly used in L3VPN scenarios.¶
End.DT46PPPoE SID (Decapsulation and Specific IP Table Lookup): The behaviors associated with this SID is endpoint behavior with decapsulation and specific IP table lookup. The processing actions involve stripping the IPv6 tunnel header, the PPPoE header, and the PPP header, and then forwarding the decapsulated IPv4/IPv6 packet according to the routing table.¶
The PPPoE client SHOULD support the following Function:¶
End.DT46PPPoE SID (Decapsulation and Specific IP Table Lookup): It supports the forwarding action of decapsulating the packet. The decapsulation actions involve removing the IPv6 tunnel header, the PPPoE header, and the PPP header, and then forwarding the decapsulated IPv4/IPv6 packet according to the routing table.¶
During the address encapsulation process, the PPPoE client will encapsulate the SID field with the corresponding function identifier as the destination IPv6 address based on application requirements. Once the PPPoE server receives this packet, it will conduct packet decapsulation. Then, it will parse the packet and perform forwarding operations in accordance with the defined decapsulation actions. When encapsulating packets, the PPPoE server will use the End.DPPPoET46 SID field as the destination IPv6 address. Upon receipt of the packet, the PPPoE client will decapsulate it and carry out corresponding forwarding and other operations.¶
IANA is requested to allocate values for the new SRv6 End behavior End.D.addslice.PPPOE and End.D.adddscp.pppoe introduced in this document.¶
The header information of SRv6, such as the Segment List and SID fields in the SRH, is transmitted in plain text, which may be eavesdropped on or tampered with. If the PPPoE payload content is not encrypted, user authentication information such as CHAP passwords and PPPoE Session IDs may be intercepted. It is necessary to authenticate SRv6 tunnel nodes and strongly bind them with PPPoE authentication to prevent unauthenticated SRv6 tunnel nodes from handling PPPoE traffic, which could lead to unauthorized access or man - in - the - middle attacks.¶
In terms of data protection, it is recommended to enable IPsec to encrypt SRv6 traffic and protect the SRH and payload content.¶
The security considerations of SRv6 [I-D.ietf-spring-srv6-security] and the security considerations of PPPoE introduced in [RFC2516] apply to this document.¶
The authors would like to acknowledge Zhenlin Tan for his helpful comments.¶