SRv6 for PPPoE Transport

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 , 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.

Conventions

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 when, and only when, they appear in all capitals, as shown here.

Terminology Refer to , for the key terms used in this document.

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.

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

Encapsulation of PPPoE over SRv6

PPPoE over SRv6 BE

PPPoE over SRv6 Policy 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.

SRv6 SID behavior design philosophy PPPoE, which is defined in , 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 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.

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).

SR Endpoint Behaviors The SID format in this draft conforms to the SID format defined in . 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 , 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).

Pseudocode describing the behaviors

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:

When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an D.addslice.PPPOE, N does the following:

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:

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:

SID Format 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 . 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 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.

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 and the security considerations of PPPoE introduced in apply to this document.

Acknowledgements The authors would like to acknowledge Zhenlin Tan for his helpful comments.