SRv6 for PPPoE Transport
draft-huang-spring-pppoe-srv6-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Cancan Huang , Xueyan Song , Mengmeng Li | ||
| Last updated | 2026-08-09 | ||
| Replaces | draft-song-spring-pppoe-srv6 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-huang-spring-pppoe-srv6-01
SPRING Working Group C. Huang
Internet-Draft China Telecom
Intended status: Standards Track X. Song
Expires: 8 February 2027 ZTE Corp.
M. Li
China Mobile
7 August 2026
SRv6 for PPPoE Transport
draft-huang-spring-pppoe-srv6-01
Abstract
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.
Status of This Memo
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 8 February 2027.
Copyright Notice
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
Huang, et al. Expires 8 February 2027 [Page 1]
Internet-Draft SRv6 for PPPoE August 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation for PPPoE over SRv6 . . . . . . . . . . . . . . . 3
4. Encapsulation of PPPoE over SRv6 . . . . . . . . . . . . . . 4
5. SRv6 SID behavior design philosophy . . . . . . . . . . . . . 6
5.1. Signaling Messages Between PPPoE Client and Server . . . 6
5.2. Plain User Data Messages and Value-Added Services
Steering . . . . . . . . . . . . . . . . . . . . . . . . 7
6. SR Endpoint Behaviors . . . . . . . . . . . . . . . . . . . . 7
7. Pseudocode describing the behaviors . . . . . . . . . . . . . 8
7.1. End.D.addslice.PPPOE . . . . . . . . . . . . . . . . . . 8
7.2. End.D.adddscp.PPPOE . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
11. Normative References . . . . . . . . . . . . . . . . . . . . 10
12. Informative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
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 SRv6 Endpoint Behavior
(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 and associated
network slice ID and DSCP value, 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.
Huang, et al. Expires 8 February 2027 [Page 2]
Internet-Draft SRv6 for PPPoE August 2026
2. Conventions
2.1. Requirements Language
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.
2.2. Terminology
Refer to [RFC2516], [RFC8986] for the key terms used in this
document.
3. Motivation for PPPoE over SRv6
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.
Huang, et al. Expires 8 February 2027 [Page 3]
Internet-Draft SRv6 for PPPoE August 2026
+--------+ +--------------+
| DC | | Controller |
+--------+ +--------------+
| |
| |
+--------+ +--------+
| Network+----------+ BRAS |
| Anchor | | |
+--+-----+ +--+-----+
\ /
\ 2nd dial-up /
\ / 1st dial-up
+-------------+
| CPE |
+-------------+
Figure 1: PPPoE over SRv6 applied in intensive data transmission
services
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
4. Encapsulation of PPPoE over SRv6
Huang, et al. Expires 8 February 2027 [Page 4]
Internet-Draft SRv6 for PPPoE August 2026
+---------------------------+
| Payload |
+---------------------------+
| ppp |
+---------------------------+
| PPPoE Session |
+---------------------------+
| Ethernet |
| EtherType=0x8863/0x8864 |
+---------------------------+
| IPv6 header, nh=143 |
+---------------------------|
| Ethernet |
+---------------------------+
| Phsical Layer |
+---------------------------+
| Physical |
+---------------------------+
Figure 2: PPPoE over SRv6 BE
+---------------------------+
| Payload |
+---------------------------+
| ppp |
+---------------------------+
| PPPoE Session |
+---------------------------+
| Ethernet |
| EtherType=0x8863/0x8864 |
+---------------------------+
| SRH header, nh=143 |
+---------------------------|
| Ethernet |
+---------------------------+
| Phsical Layer |
+---------------------------+
| Physical |
+---------------------------+
Figure 3: PPPoE over SRv6 Policy
Huang, et al. Expires 8 February 2027 [Page 5]
Internet-Draft SRv6 for PPPoE August 2026
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.
5. SRv6 SID behavior design philosophy
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.
5.1. Signaling Messages Between PPPoE Client and Server
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.
Huang, et al. Expires 8 February 2027 [Page 6]
Internet-Draft SRv6 for PPPoE August 2026
5.2. Plain User Data Messages and Value-Added Services Steering
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).
6. SR Endpoint Behaviors
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).
Huang, et al. Expires 8 February 2027 [Page 7]
Internet-Draft SRv6 for PPPoE August 2026
7. Pseudocode describing the behaviors
7.1. End.D.addslice.PPPOE
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. }
Figure 4
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 (etherType == 0x8864 (PPPOE session phase)) {
S04. Remove the ethernet header and PPPOE session header;
S05. if (protocol == 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. }
Figure 5
7.2. End.D.adddscp.PPPOE
When N receives a packet destined to S and S is a local
End.D.adddscp.PPPOE,N does the following:
Huang, et al. Expires 8 February 2027 [Page 8]
Internet-Draft SRv6 for PPPoE August 2026
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. }
Figure 6
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 (etherType == 0x8864 (PPPOE session phase)) {
S04. Remove the ethernet header and PPPOE session header;
S05. if (protocol == 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. }
Figure 7
8. IANA Considerations
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.
Huang, et al. Expires 8 February 2027 [Page 9]
Internet-Draft SRv6 for PPPoE August 2026
9. Security Considerations
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.
10. Acknowledgements
The authors would like to acknowledge Zhenlin Tan for his helpful
comments.
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
12. Informative References
Huang, et al. Expires 8 February 2027 [Page 10]
Internet-Draft SRv6 for PPPoE August 2026
[I-D.ietf-spring-srv6-security]
Buraglio, N., Mizrahi, T., tongtian, Contreras, L. M., and
F. Gont, "Segment Routing IPv6 Security Considerations",
Work in Progress, Internet-Draft, draft-ietf-spring-srv6-
security-16, 29 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-security-16>.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516,
February 1999, <https://www.rfc-editor.org/info/rfc2516>.
Authors' Addresses
Cancan Huang
China Telecom
China
Email: huangcanc@chinatelecom.cn
Xueyan Song
ZTE Corp.
China
Email: song.xueyan2@zte.com.cn
Mengmeng Li
China Mobile
China
Email: limengmeng@chinamobile.com
Huang, et al. Expires 8 February 2027 [Page 11]