Requirements for Provider Edge in IPv6-only Underlay Networks

The evolution towards IPv6-only underlay networks presents a compelling opportunity to simplify network architecture and reduce operational overhead. In large-scale service provider environments, this underlay often spans multiple administrative domains (e.g., different Autonomous Systems or organizational boundaries). A framework for such a multi-domain IPv6-only underlay, supporting services like IPv4-as-a-Service (IPv4aaS), is described in . In this architecture, the Provider Edge (PE) device serves as the critical nodal point where customer service attachment intersects with the multi-domain IPv6-only underlay. Its role extends beyond traditional PE functions to include key responsibilities in inter-domain service routing, protocol-agnostic data encapsulation, and cross-domain service assurance. This document specifies the requirements for PE devices operating in this specific context. These requirements ensure that PEs from different vendors and domains can interoperate seamlessly to deliver end-to-end services across a pure IPv6 underlay. It should be noted that this document does not cover all the requirements for PE devices, it only introduces the parts directly related to IPv6-only. By specifying these requirements, this document aims to provide a common recommendation for equipment vendors and network operators, facilitating the development, deployment, and interoperability of multi-domain IPv6-only PE Routers. This will ultimately contribute to the successful establishment and operation of multi-domain IPv6-only network.

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.

The following terms are defined in this draft: Multi-domain Network: A network comprising two or more administratively separate domains (e.g., Autonomous Systems) interconnected to provide end-to-end services. IPv6-only Underlay: A network infrastructure that exclusively uses IPv6 for forwarding and control-plane protocols, with no native IPv4 forwarding path. Inter-domain PE: A PE device located at the boundary between two administrative domains, responsible for exchanging service information and forwarding traffic across domains. Intra-domain PE: A PE device located within a single administrative domain. IPv4-as-a-Service (IPv4aaS): A service model where IPv4 connectivity is provided to customers over an IPv6-only underlay network, using encapsulation or translation techniques. PE: Provider Edge, defined in

In the reference model (Figure 1): Each domain operates an internal IPv6-only IGP (e.g., IS-ISv6 or OSPFv3) . Domains are interconnected via Inter-domain PEs (acting as ASBRs) using IPv6 EBGP sessions. Service layer routes (e.g., IPv4 VPN routes) are exchanged via MP-BGP over the IPv6 underlay. Customer IPv4 traffic is encapsulated within IPv6 (e.g., with an SRv6 header) for traversal across the multi-domain underlay.

REQ-1: A PE device, when acting as an Inter-domain PE, MUST be able to exchange service layer routes (e.g., VPN-IPv4/VPN-IPv6 NLRIs with PEs in other domains using MP-BGP sessions where the next-hop is an IPv6 address. This MUST be supported over IPv6-only underlay transport. REQ-2: A PE device MUST support the necessary MP-BGP extensions and procedures for advertising IPv4-to-IPv6 (and vice versa) service mappings across domain boundaries. This capability is FUNDAMENTAL for enabling services like IPv4-as-a-Service (IPv4aaS) in an IPv6- only underlay. It allows a downstream PE to correctly associate a received IPv4 service prefix with its corresponding IPv6 underlay path identifier or tunnel endpoint. The specific encoding (e.g., a dedicated BGP attribute, extended community, or a new AFI/SAFI) and procedures for distributing these mappings MUST follow . PE devices MUST be able to install forwarding state based on these received mappings. REQ-3: A PE device MUST correctly process and enforce policies based on BGP Extended Community attributes, specifically Route Target, to identify and isolate service routes and their associated mappings belonging to different customers or domains. REQ-4: A PE device MAY support additional mechanisms for inter- domain traffic steering and policy enforcement beyond basic connectivity. If supported, such mechanisms (e.g., BGP-based mechanisms for segment routing or other tunnel technologies) SHOULD operate transparently across the IPv6-only underlay. Crucially, the absence of any specific traffic steering mechanism MUST NOT break basic IPv4aaS service connectivity established through REQ-1 and REQ-2.

REQ-5: A PE device MUST support at least one IETF-standardized encapsulation method for carrying non-IPv6 customer traffic (e.g., IPv4, Ethernet) across the IPv6-only underlay. Possible mechanisms include, but are not limited to, IPv6-in-IPv6 tunneling , Generic Routing Encapsulation (GRE) over IPv6, MPLS-in-UDP/IPv6 , or SRv6 . The choice of encapsulation MUST be derivable from the control-plane information (e.g., the service mapping advertised per REQ-2). REQ-6: As an ingress PE, the device MUST be capable of encapsulating received customer packets (e.g., IPv4) with an appropriate IPv6 header, based on the forwarding state installed via the control plane (driven by REQ-2). As an egress PE, the device MUST be capable of decapsulating the outer IPv6 header to recover the original customer packet and forward it to the correct service instance. REQ-7: Due to the increased packet size from encapsulation, a PE device MUST implement Path MTU Discovery for IPv6 . It MUST either handle fragmentation appropriately or signal MTU issues back to the source (e.g., using ICMPv6 Packet Too Big messages) in a way that functions correctly across domain boundaries, considering the encapsulated path.

REQ-8: A PE device MUST support standardized OAM mechanisms that operate end-to-end across multiple domains over the IPv6-only underlay. This includes, but is not limited to, IPv6-based Bidirectional Forwarding Detection (BFD)and ICMPv6-based traceroute. The OAM packets MUST follow the same encapsulation path as data traffic.As a forwarding node in IPv6-only networks, PE router shall accept centralized policy scheduling from the network controller and implementing automated configuration through the NETCONF protocol/YANG model. Meanwhile, the PE supports syslog and SNMP Trap alarm mechanisms, enabling rapid fault location and security incident tracing through standardized logs. REQ-9: A PE device MUST be able to map the Quality of Service (QoS) markings from the customer packet (e.g., IPv4 DSCP) to the encapsulating IPv6 header's Traffic Class field (or equivalent), and ensure this policy is consistently applied and honored as the packet traverses different domains. REQ-10: A PE device MUST provide robust isolation between traffic from different customers or services across the shared IPv6 underlay. This MUST be enforceable at inter-domain boundaries, typically implemented through the use of distinct VPN routing/forwarding instances or logically separated encapsulation identifiers derived from the control plane.

This document provides the concrete device-level requirements that implement the architecture described in the framework document . It relies upon and extends the principles established in existing VPN specifications (e.g., , ) and places critical new requirements on MP-BGP for service mapping (REQ-2) to enable operation in a multi-domain, IPv6-only context.

Security in a multi-domain IPv6-only environment introduces specific considerations for PE devices: o BGP Session Security: All inter-domain BGP sessions MUST be secured using mechanisms such as IPsec . Route Origin Authorization (ROA) validation via RPKI SHOULD be implemented where feasible. o Mapping Advertisement Integrity: The service mapping advertisements (REQ-2) are critical for correct forwarding. Mechanisms MUST be in place to ensure their integrity and authenticity, potentially leveraging existing BGP security measures. o OAM Protection: OAM protocols MUST be rate-limited and protected from misuse that could lead to denial-of-service attacks across domains. o Encapsulation Overhead and Inspection: The addition of encapsulation headers should be considered in network capacity planning and security monitoring. Techniques for deep packet inspection may need to be adapted to operate on encapsulated traffic within the underlay.

This document has no IANA actions.

The authors would like to thank the contributors and reviewers of this document for their valuable input and feedback.