Network Working Group Q. Ma Internet-Draft Y. Liu Intended status: Informational China Mobile Expires: 30 April 2027 2 November 2026 SRv6 Based IPv6 Only Deployment Considerations draft-ma-v6ops-srv6-ipv6only-01 Abstract This document describes considerations for deploying IPv6-only networks based on SRv6 encapsulation in metro and backbone networks. It presents several deployment scenarios, including fixed broadband internet access, high-value leased-line services, and traffic steering to data center resource pools, and provides operational guidance derived from production network pilots. 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 April 24, 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 (http://trustee.ietf.org/license-info) in effect on the date of Ma, et al. Expire April, 2027 [Page 1] Internet-Draft SRv6 Based IPv6 Only Deployment November 2026 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. IPv6-Only Solution Based on SRv6...............................4 4. Service Scenario Examples......................................6 4.1. Fixed Broadband Internet Access...........................6 4.2. High-Value Leased-Line Scenario...........................7 4.3. Data Center Steering Scenario.............................8 5. Operational Considerations and Recommendations.................9 5.1. Technical Planning........................................9 5.2. O&M Capability............................................9 5.3. Security Readiness........................................9 5.4. Evolution Pace...........................................10 6. Security Considerations.......................................10 7. IANA Considerations...........................................11 8. References....................................................11 8.1. Normative References.....................................11 8.2. Informative References...................................11 Acknowledgments..................................................12 Contributors.....................................................13 Authors' Addresses...............................................13 1. Introduction In the early stages of IPv6[RFC8200] transition, the dual- stack[RFC4213] approach predominated in network upgrades. This solution offers certain compatibility advantages with existing terminals and applications, and is well supported on the network side. However, dual-stack deployment is just a temporary solution with high complexity, demanding hardware requirements, and significant O&M costs. Furthermore, it does not resolve IPv4 address exhaustion. Ma, et al. Expires April, 2027 [Page 2] Internet-Draft SRv6 Based IPv6 Only Deployment November 2026 IETF has reached a clear consensus that IPv6-only is the long-term direction for the Internet-in 2016, the IAB expected that the IETF would stop requiring IPv4 compatibility in new or extended protocols[IAB-statement]. The IPv6-only transition now faces multiple challenges. On fixed networks, some legacy home routers do not support IPv6 or have IPv6 disabled by default. In addition, issues such as low IPv6 utilization on government and enterprise dedicated lines, and insufficient IPv6 support in cloud service products, also hinder the advancement of IPv6-only deployment and the growth of IPv6 traffic. Metro and backbone networks shoule take the lead in IPv6-only deployment. This simplifies network architecture, improves performance, and enables early adoption of technologies such as SRv6[RFC8986], in-situ flow measurement[RFC9197], and network slicing[RFC9543]. Moreover, it will push the industry chain to accelerate terminal and application upgrades. SRv6 BE encapsulation allows the metro and backbone networks to be IPv6-only while maintaining IPv4 functionality on the user network. The core mechanism involves encapsulating IPv4 traffic within IPv6 packets. On the control plane, BGP routing policy optimization enables IPv4 service routes to be transferred in an IPv6 environment. On the forwarding plane, matching the inner IPv4 addresses of SRv6 packets resolves the issue that existing IPv4 scheduling policies-such as ACL, QoS, and CGN-become ineffective for SRv6-encapsulated traffic.This solution requires no device changes, preserves existing IPv4 policies, and enables imperceptible migration. Production network testing showed that the SRv6 BE solution outperforms the dual-stack model in protocol complexity, resource utilization, operations management, and service support. It also ensures zero interruption during migration and maintains network KPIs at or above their original levels. This approach provides a practical path to address the main challenge in IPv6-only deployment: the lagging upgrade of applications and user terminals. It also drives a substantial increase in IPv6 traffic. 2. Terminology The following terms are used in this document: IPv6 : Internet Protocol Version 6 [RFC8200] Ma, et al. Expires April, 2027 [Page 3] Internet-Draft SRv6 Based IPv6 Only Deployment November 2026 SRv6 : Segment Routing over IPv6 [RFC8986] SRv6 BE : Segment Routing over IPv6 Best Effort IPv6-only: Only IPv6 is native within a given scope; IPv4 is neither configured nor managed [I-D.ietf-v6ops-ipv6-only] P: Provider Router. PE: Provider Edge CE: Customer Edge. DC: Data Center. DCGW: Data Center Gateway Pool-GW: Resource Pool Gateway CGN Carrier-Grade NAT[RFC6888] ONU: Optical Network Unit, provides access on the user side. 3. IPv6-Only Solution Based on SRv6 The IPv6-only solution based on SRv6 BE follows the design philosophy of "reachability of routes means reachability of services." Leveraging IPv6 route reachability within the carrier network, it establishes end-to-end IPv6 forwarding paths between WAN edge devices, uniformly carrying multiple service types such as IPv4/IPv6 public network, L3VPN, and EVPN. This solution only requires enabling SRv6 functionality on network edge devices, while intermediate nodes merely need standard IPv6 forwarding capability. Customer-side devices require no changes and can gradually evolve toward IPv6 as service demands dictate. It enables bearer and forwarding of all-IPv6 traffic across metro and backbone networks with minimal live-network changes and without user perception. SRv6 BE serves as the data-plane bearer. IPv6 encapsulation tunnels are established between head and tail nodes. Internet access traffic from fixed broadband, internet leased lines, 4G/5G access, and IDC is steered into SRv6 BE tunnels by resolving the next hop to an SRv6 SID. IPv4 service traffic is thus transparently carried over the IPv6-only network.IPv4 flow policies are simplified to basic traffic steering rules. Ma, et al. Expires April, 2027 [Page 4] Internet-Draft SRv6 Based IPv6 Only Deployment November 2026 Alternatively, they may be managed through more granular Flowspec route policies[RFC8955].A simplified SRv6 network architecture with three service scenarios fixed broadband access, data center interconnection, and user-side access is illustrated in Figure 1. +--------+ +--------+ +---------------+ | DC1 | | DC2 DCGW---Pool-GW Resource | | | | | | Pool | +--------+ +--------+ +---------------+ | | +---PE3----+ +---PE6---+ +-------+ | | | | +------+ | CE1 |--BNG/PE1---P---PE2--PE4---P---PE5---| CE2 | +-------+ / | AS1 | | AS2 | +------+ / +----------+ +---------+ +-------+/ | ONU | +-------+ Figure 1: SRv6 Network Architecture with Service Scenarios The deployment imposes requirements on each network element, PE: Must support SRv6 capabilities and be able to steer service traffic into SRv6 tunnels through various means such as route iteration. For special requirements, the PE can perform redirection based on flow policies or BGP Flowspec rules matching the inner packets of SRv6 tunnels, delivering decapsulated IP packets to specific devices. For example, traffic can be sent to CGN devices for translation of IPv4 private addresses to public addresses, or to security inspection devices for security requirements. P: Require no SRv6-specific upgrades and only need to maintain standard IPv6 forwarding capability. Controller: Must support Flowspec route advertisement, with the ability to specify next hops and outbound interfaces, enabling centralized management and unified distribution of traffic steering policies. Ma, et al. Expires April, 2027 [Page 5] Internet-Draft SRv6 Based IPv6 Only Deployment November 2026 4. Service Scenario Examples 4.1. Fixed Broadband Internet Access Fixed broadband internet access accounts for a large share of internet traffic, and its IPv6 adoption significantly affects the progress of IPv6-only deployment and IPv6 traffic growth. Therefore, taking the lead in IPv6-only transformation for fixed broadband is a high priority and of great significance. For IPv6-only deployment in fixed broadband, the access side shall keep existing networking and user terminal configurations unchanged. The transformation focuses on the segment between the BNG and its upstream P device: enabling the exchange of IPv4 routing information within their IPv6 BGP neighbor relationship, activating SRv6 extension functions, and configuring public network Service SIDs. Meanwhile, based on SRv6 encapsulation, the following two types of traffic steering capabilities shall be implemented on the core router: 1. Centralized NAT steering for IPv4 private network traffic. After deploying IPv6-only based on SRv6 BE, IPv4 private network traffic must still be accurately steered to centralized NAT44 devices to ensure that IPv4 internet services remain unaffected. The metro core router (or carrier network edge router) must support PBR based on the inner IPv4 packets of SRv6 tunnels, and be able to identify inner original IPv4 packet characteristics after decapsulation and execute precise steering actions. 2. Traffic detouring for internet leased lines. Internet leased-line traffic typically needs to be detoured through specific devices to meet particular requirements such as security inspection, billing, and auditing. The metro core router (or carrier network edge router) must support PBR based on the inner IPv4 source address of SRv6 tunnel packets. For legacy devices that do not support PBR, BGP Flowspec policies[RFC5575] can serve as an alternative to achieve equivalent traffic steering. The production network pilot demonstrated a notable increase in IPv6 traffic share. IPv6 traffic shares on the BRAS-to-metro link Ma, et al. Expires April, 2027 [Page 6] Internet-Draft SRv6 Based IPv6 Only Deployment November 2026 and the metro-to-backbone link increased from less than 30% to 100%. 4.2. High-Value Leased-Line Scenario High-value leased-line services impose extremely stringent requirements on network quality, typically demanding low latency, high reliability, deterministic bandwidth, and differentiated SLA guarantees. After implementing SRv6-based IPv6-only deployment, SRv6 network slicing and in-situ flow measurement can be leveraged to provide logically isolated, on-demand leased-line services for customers across different industries, while enabling high- precision quality measurement and fault localization without affecting existing services. The specific deployment steps are as follows: 1. Basic capability deployment Metro routers are loaded with SRv6 functionality, and fundamental planning and deployment of Locators and SIDs are completed, enabling the network to support SRv6 forwarding. 2. Tunnel and policy provisioning The controller performs unified orchestration, issuing SRv6 TE Policy tunnels to network devices, along with corresponding Flowspec steering policies. 3. Network slice construction Corresponding network resources are allocated to the established SRv6 tunnels, realizing network slices with deterministic forwarding paths and resource allocation. High-value leased-line services are steered into the corresponding slices via Flowspec based on their SLA requirements, enabling differentiated bearer services. 4. In-situ flow detection and dynamic optimization After slices are operational, in-situ flow detection capabilities are overlaid to monitor the SLA quality of each slice in real time. The collected detection data is fed back to the controller, enabling dynamic optimization and adjustment of network states, and ensuring that high-value services stably meet committed SLA indicators over the long term. Ma, et al. Expires April, 2027 [Page 7] Internet-Draft SRv6 Based IPv6 Only Deployment November 2026 4.3. Data Center Steering Scenario As enterprise digital transformation accelerates, traffic from the carrier network to data center resource pools including compute, security, and value-added services is growing significantly. These resource pools are typically hosted in carrier or third-party cloud data centers, residing in autonomous systems different from those on the user side, thus requiring traffic to traverse both the carrier network and the data center domains. Traditionally, steering such traffic to specific service nodes in resource pools has relied on disparate technologies like PBR[I- D.kini-i2rs-pbr-info-model] or MPLS L3VPN inter-AS. These approaches involve complex configurations, tight topology coupling, and limited end-to-end visibility. The situation is further complicated when traffic must pass through multi-node service chains such as firewalls and load balancers. Based on SRv6, a cross-domain SRv6 tunnel is established between the carrier network ingress PE and the data center resource pool gateway, simplifying both the data-plane and control-plane protocols while enabling service chain steering and return traffic optimization. on the control plane, BGP neighbors are established hop by hop among the carrier network PE, the DCGW, and the resource pool gateway to exchange SRv6 Locator routes, enabling cross-domain IPv6 underlay interconnection. The resource pool gateway establishes an MP-BGP neighbor with the carrier network PE, advertising VPNv4 routes within the resource pool along with their corresponding SRv6 VPN SIDs, so that the PE obtains the tunnel encapsulation information required to reach the resource pool. It also advertises the public IP routes after service chain processing, together with their SRv6 SIDs, to enable tunnel-based return traffic delivery. On the forwarding plane, end-to-end SRv6 encapsulation and forwarding are performed for user traffic from the carrier network to the resource pool, through the service chain, and back to the carrier network. When a tenant orders a resource pool service, the controller delivers a BGP FlowSpec policy to the corresponding carrier network PE, steering traffic into the SRv6 tunnel and forwarding it to the resource pool gateway. To ensure service reliability, BFD for BGP [RFC5880] is used to detect reachability between the Ma, et al. Expires April, 2027 [Page 8] Internet-Draft SRv6 Based IPv6 Only Deployment November 2026 PE and the resource pool gateway. When unreachable, the corresponding route is withdrawn, and traffic falls back to the original public network routing and forwarding process, without affecting normal service forwarding. 5. Operational Considerations and Recommendations This section provides deployment recommendations for accelerating IPv6-only evolution in metro and backbone networks. The recommendations cover technical planning, O&M capability, security readiness, and evolution pace. Operators should coordinate these aspects from a global perspective and implement them in phases, by service, and by region. 5.1. Technical Planning Pre-deploy foundational capabilities. Complete SRv6 enablement and other non-service-impacting operations in advance. This avoids overlap with traffic cutovers. A phased approach reduces operational complexity and risk during single-stack migration. Plan Locator space upfront. Plan and provision Locator space at the initial stage according to the target topology. This prevents large-scale route flapping and service disruption caused by later Locator changes. Mitigate MTU risk. SRv6 encapsulation adds an IPv6 extension header, increasing packet length. If the encapsulated packet exceeds the path MTU, packet loss may occur. Configure a proper Path MTU on the SRv6 head node to keep encapsulated packets within the maximum allowed MTU. Enable end-to-end MTU dynamic negotiation for adaptive adjustment. 5.2. O&M Capability Enhance traffic steering granularity. Enhance device support for flexible matching and steering of outer and inner SRv6 packet headers. This enables fine-grained traffic scheduling based on inner 5-tuple, application identifiers, and other dimensions, accommodating differentiated multi-service bearer requirements. 5.3. Security Readiness Adapt security concurrently. Evaluate SRv6 capabilities of firewalls, DDoS mitigation systems, and other security functions during planning. Complete version upgrades or redeployment ahead of time to eliminate security blind spots during protocol evolution. Ma, et al. Expires April, 2027 [Page 9] Internet-Draft SRv6 Based IPv6 Only Deployment November 2026 5.4. Evolution Pace To accelerate IPv6-only evolution in metro and backbone networks, coordinate the planning of target architecture, protocol roadmap, transition strategy, and transformation pace. Implement in phases, by service, and by region. Service evolution sequence. Proceed from simple to complex. Deploy SRv6 basic capabilities first, then unicast traffic bearer, then VPN leased-line bearer. Ensure controllable risk at each stage. Network evolution sequence. Enable IPv6-only first on PE nodes that already support SRv6. Expand gradually network-wide for smooth scaling. 6. Security Considerations SRv6-specific security considerations are fully described in [I- D.ietf-spring-srv6-security]. This document does not repeat them. The primary security considerations relevant to the SRv6-based IPv6-only solution described here include middlebox filtering, trust domain boundaries, threat classification across the data, control, and management planes, and resource exhaustion risks. Operators deploying this solution SHOULD refer to that document for the complete threat model and mitigation methods. The SRv6-based IPv6-only solution imposes specific upgrade requirements on security devices: SRv6 parsing. Security middleboxes (e.g., firewalls and traffic scrubbers) MUST be capable of parsing the SRH[RFC8754] and extracting the actual destination address from the last entry in the Segment List. Tunnel decapsulation. Security devices MUST be able to strip the outer SRv6 encapsulation and inspect the inner original IPv4 packet for policy enforcement. Hardware capability assessment. ACL filtering resources may be shared with routing tables, VLANs, and other functions on some hardware platforms. Hardware limitations MUST be considered when designing SRv6 control-plane and data-plane filtering capabilities. Ma, et al. Expires April, 2027 [Page 10] Internet-Draft SRv6 Based IPv6 Only Deployment November 2026 7. IANA Considerations This document has no IANA actions. 8. References 8.1. Normative References [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6(IPv6) Specification", STD 86, RFC 8200,DOI 10.17487/RFC8200, July 2017,. [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, [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020., 8.2. Informative References [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, . [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier- Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, . Ma, et al. Expires April, 2027 [Page 11] Internet-Draft SRv6 Based IPv6 Only Deployment November 2026 [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, . [RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024, . [IAB-statement] "IAB statement on IPv6", . [I-D.ietf-v6ops-ipv6-only] Martinez, J. P., "IPv6-Only and IPv6- Mostly Terminology Definitions", Work in Progress, Internet-Draft, draft-ietf-v6ops-ipv6-only-00, 1 July 2026, . [I-D.kini-i2rs-pbr-info-model] Kini, S., et al., "Information Model for Policy Based Routing", Work in Progress, Internet-Draft, draft-kini-i2rs-pbr-info-model-00, February 2014, . [RFC8955] Loibl, C., Ed., et al., "Dissemination of Flow Specification Rules", RFC 8955, December 2020. [I-D.ietf-spring-srv6-security] Buraglio, N., Mizrahi, T., Tong, T., Contreras, L. M., and F. Gont, "Segment Routing IPv6 Security Considerations", Work in Progress, Internet-Draft, draft-ietf- spring-srv6-security-16, 2026, https://datatracker.ietf.org/doc/draft-ietf-spring-srv6- security/16/. Acknowledgments The authors would like to acknowledge the valuable input and contributions from Liyan Qong, Yongwei Liu. Ma, et al. Expires April, 2027 [Page 12] Internet-Draft SRv6 Based IPv6 Only Deployment November 2026 Contributors Liyan Qong China Mobile Email: gongliyan@chinamobile.com Yongwei Liu China Mobile Email: liuyongwei@chinamobile.com Authors' Addresses Qiongfang Ma China Mobile Email:maqfcm@163.com Yisong Liu China Mobile Email:liuyisong@chinamobile.com Ma, et al. Expires April, 2027 [Page 13]