| Internet-Draft | SRv6 Deployment Options | July 2026 |
| McBride, et al. | Expires 7 January 2027 | [Page] |
When deciding to migrate a network from existing data-plane technologies (e.g. MPLS, SR-MPLS or overlay encapsulations such as VXLAN) to SRv6, common questions involve how to perform the migration, how to minimize impact to the existing network and what techniques are available to support a smooth transition. This document presents various deployment and migration options for networks evolving toward SRv6 from prior transport or overlay technologies.¶
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 7 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.¶
Segment Routing IPv6 (SRv6) [RFC8986] is a network architecture that leverages IPv6 data plane encapsulation to enable flexible and efficient traffic engineering. It allows for the creation of explicit paths through the network by encoding routing instructions directly into packet headers. Many operators are looking for direction in how to migrate their existing networks to a SRv6 network. It is common for them to have had an IP/MPLS network for over ten years and now ready for a network refresh. Many are convinced it's time to evolve their network to segment routing. And now that SRv6 is mature, they are often planning on that deployment even if currently running SR-MPLS. How to evolve an existing IP/MPLS network to meet the new demands upon a network? Should they run ships in the night (protocol messages coexist being unaware of each other), utilize various tunneling/overlay techniques, use an interworking translation mechanism or other deployment solution? If they are currently running an IP/MPLS network how should they migrate to SRv6? This draft provides various deployment alternatives to help provide guidance to those wanting to migrate their network to SRv6.¶
SRv6 can be deployed on a typical single-AS network (such as IP backbone network, metro network, mobile transport network, or data center network) or on a multi-AS network (such as an inter-AS VPN or carrier's carrier network). These topics are discussed further in Section 5. Before SRv6 is deployed, IPv6 address planning is needed for SID allocation. IGP and BGP designs are then implemented for network nodes, and the corresponding SIDs are advertised for services such as TE and VPN.¶
[I-D.ietf-srv6ops-problem-summary] provides an overview of the common problems encountered during SRv6 deployment and operation. It provides a foundation for further work, including potential solutions and best practices to navigate deployment. The purpose of this deployment draft is to provide an overview and considerations for the various solutions available for SRv6 deployment, particularly in scenarios involving migration from existing transport or overlay technologies to SRv6.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
MPLS: Multiprotocol Label Switching¶
RSVP: Resource Reservation Protocol¶
SR-MPLS: Segment Routing based on MPLS¶
SRv6: Segment Routing based on IPv6¶
SRMS: Segment Routing Mapping Server¶
SITN: Ships in the Night¶
VTEP: Virtual Tunnel End Point¶
Migration from an MPLS network to SRv6 constitutes an architectural transition. Two approaches are possible: a phased evolution via SR-MPLS or a direct migration to SRv6.¶
A phased approach introduces SR-MPLS (Segment Routing over MPLS) as an intermediate step. SR-MPLS reuses the MPLS data plane while simplifying the control plane through removal of LDP and RSVP-TE. Because it preserves label forwarding, many existing MPLS platforms can support SR-MPLS through software upgrades. At first glance, this appears to reduce migration risk by limiting changes to the data plane. However, introducing SR-MPLS creates an additional architectural stage that must later be migrated again to SRv6. This results in two sequential transitions: first from MPLS to SR-MPLS and then from SR-MPLS to SRv6. Each transition requires planning, testing, operational adaptation and validation. While SR-MPLS may appear incremental, it does not eliminate the need for eventual IPv6 enablement, hardware validation for 128-bit SIDs or operational readiness for SRv6. Instead, it postpones those activities.¶
In practice, the overall complexity of migrating directly from MPLS to SRv6 is often less than the cumulative complexity of migrating from MPLS to SR-MPLS and then to SRv6. A direct transition avoids introducing an intermediate architecture that must later be redesigned or retired. Operationally, this reduces duplicated effort in design validation, tooling updates, documentation, training and service migration procedures. These requirements must ultimately be addressed regardless of whether SR-MPLS is deployed first, and addressing them once in a single coordinated migration phase is typically operationally simpler.¶
For networks that are already IPv6-enabled, such as many data center or 5G mobile backhaul deployments, direct migration to SRv6 is typically the most straightforward and future-proof strategy. Even in IPv4-only environments planning IPv6 adoption, it may be operationally more efficient to combine IPv6 deployment and SRv6 introduction into a single transformation program rather than introducing SR-MPLS as an interim solution.¶
In greenfield deployments where SRv6 is natively supported, direct adoption avoids unnecessary architectural layering. Similarly, if the operations team is already familiar with IPv6 and SRv6 concepts, a direct evolution from MPLS to SRv6 minimizes transitional complexity. Note that introducing SR-MPLS as an intermediate step is most relevant when migrating from an existing MPLS network; for networks starting from overlay technologies such as VXLAN, this intermediate stage offers little advantage.¶
Within this context, several SRv6 transport evolution models can be considered when migrating from traditional MPLS networks or deploying new SRv6-based infrastructures. In practice, operators may employ a combination of these models across different network segments or migration phases.¶
Ships-in-the-Night (Dual Stack: Independent SRv6 and MPLS): SRv6 and MPLS operate independently within the same network without interworking between them.¶
Dual-Plane Deployment: A new SRv6 infrastructure is introduced alongside the existing MPLS infrastructure. New services are activated on SRv6 and MPLS services are migrated over time.¶
SRv6 Overlay (SRv6 over MPLS/IP): SRv6 is deployed as an overlay over the existing transport network, preserving the underlying infrastructure during transition.¶
SRv6 and MPLS Interworking (Coexistence): Interoperability mechanisms enable communication between SRv6 and MPLS domains, allowing phased service migration.¶
Similar phased or direct transition considerations apply when migrating from overlay-based data center fabrics (e.g. VXLAN) or other encapsulation technologies toward SRv6. In such environments, operators may choose to introduce SRv6 incrementally alongside existing overlay mechanisms, deploy SRv6 as an underlay replacing the existing transport or directly adopt SRv6-based network virtualization. The migration principles described in this document therefore apply more broadly to networks evolving from either label based or overlay based architectures toward SRv6.¶
The following diagram depicts the high level options of phased vs direct evolution to SRv6. An existing MPLS network can first migrate to SR-MPLS as an intermediate step before migrating to SRv6, or it can migrate directly to SRv6 and bypass SR-MPLS deployment:¶
+---------+ +---------+ +---------+
| MPLS | | SR-MPLS | | SRv6 |
+---------+ +---------+ +---------+
| | | |
Phased +----------+ +---------+
| |
Direct +-----------------------+
This section elaborates on the deployment and transition models introduced in Section 3. Several SRv6 migration options are described, providing various options for migration, some of which avoid the need for a complete forklift of existing infrastructure.¶
Ships-in-the-Night (SITN) is a method in which SRv6 and MPLS run in parallel in the same network. They coexist as separate "ships in the night," with no interworking between them. This technique is well-known from IPv4 to IPv6 transition as a dual-stack approach, and can equally be applied to MPLS and SRv6. As with IPv4 and IPv6, MPLS and SRv6 are separate data planes that cannot work together without some form of translation or interworking mechanism.¶
Ships-in-the-Night is applicable to networks where SRv6 and MPLS serve different purposes (e.g., MPLS for existing VPNs, SRv6 for new services), as well as to networks where the same services need to be supported across both planes during transition. The separation of the two control and data planes avoids interoperability issues and provides flexibility to deploy SRv6 incrementally. This is a straightforward and popular deployment option.¶
The following diagram depicts using Ships-in-the-night SRv6 and MPLS over the same PE/P infrastructure:¶
+----+ +---+ +----+
| PE |------| P |------| PE | (MPLS)
| |......| |......| | (SRv6)
+----+ +---+ +----+
There are drawbacks to running protocols ships-in-the-night. These include:¶
Additional resource usage (parallel control planes and data planes), including increased memory and processing load on networking devices.¶
No traffic engineering integration between the two planes.¶
Some routers may struggle with simultaneous MPLS and SRv6, particularly in multi-vendor environments where expecting all platforms to handle both protocols without issues can be optimistic. For example, in networks with frequent link events, having both MPLS and SRv6 protection mechanisms active simultaneously (e.g., TI-LFA and RSVP-TE FRR) means every link event triggers recalculations in two separate protection frameworks, which can cause significant control plane load.¶
Managing two control planes increases operational overhead.¶
Some operators prefer an incremental migration approach (Overlay) rather than parallel operation.¶
Maintaining two protocols may introduce additional security vulnerabilities if not managed correctly, as dual-stack networks have an increased attack surface.¶
The cost of maintaining both networks can be prohibitive.¶
Let's take MPLS L3VPN as an example to describe how L3VPN services can migrate from MPLS to SRv6 using Ships-in-the-night. After network nodes are software upgraded to support SRv6, L3VPN services can be migrated from MPLS to SRv6 using the following procedure:¶
Configure interface IPv6 addresses and locators.¶
Configure IS-IS IPv6 and enable SRv6, and then configure the forwarders to advertise locator routes.¶
Establish BGP peer relationships between the controller and forwarders (the controller may be, for example, an SDN controller or PCE, and the forwarders are typically P/PE routers) using the IPv6 unicast address family, and enable BGP-LS and BGP IPv6 SR-Policy. The controller delivers SRv6 Policies, and SRv6 TE tunnels are established on forwarders.¶
On Forwarders, establish BGP VPNv4 peer relationships using IPv6 addresses so that BGP VPNv4 peers advertise VPN routes to each other. The color attribute of the VPN routes is consistent with that of SRv6 Policies to ensure that VPN routes can recurse to the SRv6 Policy.¶
Each forwarder has two routes with the same prefix, one carrying the MPLS VPN label received from the BGP peer established using IPv4 addresses and the other carrying the VPN SID received from the BGP peer established using IPv6 addresses. If the two routes have the same attributes, a forwarder by default preferentially selects the route received from the BGP peer established using IPv4 addresses, and services can still be carried over MPLS tunnels.¶
Configure a route policy so that the forwarder preferentially selects the route received from the BGP peer established using IPv6 addresses. Then, traffic will be automatically switched to SRv6 tunnels, and L3VPN services will be migrated to the SRv6 tunnels.¶
Delete the MPLS tunnel, BGP peer relationships established using the IPv4 unicast address family, and MPLS configurations.¶
After an SRv6 tunnel is established, and the network is running in SITN mode, services can then be migrated from MPLS to SRv6. Once all services have moved to SRv6, all MPLS related configuration can then be removed.¶
Dual plane refers to building a second, new SRv6-based infrastructure alongside the existing MPLS infrastructure. The primary driver for this approach is alignment with hardware lifecycle replacement cycles: new equipment is brought in as SRv6-capable, while the existing MPLS network continues operating without requiring simultaneous dual-stack upgrades across all platforms. The idea is to introduce a separate SRv6 network by first activating new services on it and later migrating existing MPLS services onto it. A secondary benefit is that any protocol bugs, interop issues, or unexpected behavior can be isolated within a limited and controlled environment instead of affecting all existing customers. Once stability is confirmed, new equipment can be integrated into the SRv6 plane, expanding the network organically. Migrating existing MPLS services onto the new SRv6 plane is not simply a matter of moving access circuits: since the two planes are otherwise unconnected, completing the migration of live services typically requires combining Dual Plane with another approach, such as Ships-in-the-Night or Interworking, at the points where existing services or access circuits are cut over. If both planes coexist, an interworking point between the legacy and new domains may become necessary, which could add complexity. With dual plane, the investment cost is also higher, but when aligned with network renewal cycles, it becomes feasible.¶
With an overlay model, one technology runs on top of the other. The underlying network provides transport, while the overlay provides services. With SRv6 over MPLS, SRv6 packets are encapsulated in MPLS (e.g., in a brownfield migration scenario). SRv6 is deployed as an overlay on top of an existing MPLS transport network. The underlying network remains unchanged, and SRv6 tunnels are encapsulated over the infrastructure. Overlays are useful for gradual migration, allowing operators to introduce SRv6 services without disrupting the existing MPLS/IP core and only minimal changes to the existing network. This allows early adoption of SRv6 features (e.g., network programming, service chaining). There is some overhead due to additional encapsulation (SRv6 headers over MPLS/IP) and it does not fully leverage native SRv6 capabilities in the data plane. It's a common migration technique because migration is fairly easy, it works with existing IPv4 MPLS networks, provides incremental deployment with only the services provider edge (PE) routers needing SRv6 software upgrades. Core network routers can remain IPv4 MPLS (or SR-MPLS) while the rest of the network is migrating to SRv6. How long those core routers remain using MPLS is up to the network operator and can either be a temporary or long term solution depending upon network goals.¶
For instance, we could utilize a IPv6 provider edge (6PE) overlay if the backbone does not support IPv6. SRv6 services on transit nodes are forwarded through IPv6 over MPLS. 6PE is an MPLS-based overlay mechanism that allows IPv6 traffic to be transported over an IPv4/MPLS core network without requiring IPv6 support on core (P) routers. It leverages MP-BGP and MPLS label stacking to tunnel IPv6 packets across an existing IPv4/MPLS infrastructure. Edge routers connect IPv6 islands and encapsulate IPv6 in MPLS. When it’s challenging to provision dual stack on the core network, a 6PE (or L3VPN, L2VPN, etc) overlay could be used as a transitional technique with the capability to evolve to SRv6 in the future. BGP is used to advertise the SRv6 locator and loopback routes of the ingress and egress. If the core (P layer) already supports IPv6 natively, this 6PE-style overlay is effectively a lightweight variant of Ships-in-the-Night limited to that layer, since IPv4/MPLS and native IPv6 forwarding coexist on the same core routers without interworking between them.¶
The following diagram depicts using 6PE as the MPLS overlay between SRv6 capable PE nodes:¶
+----+ +---+ +--+ +--+ +---+ +----+ |SRv6| |6PE| |P | MPLS |P | |6PE| |SRv6| | PE | +---+ +--+ +--+ +---+ | PE | +----+ | | +----+ | | 6PE | | | +------------------------------------+ | | | | SRv6 | +------------------------------------------------------+
Overlays can be particularly relevant for multi-vendor networks where some of the multi vendor platforms do not yet support SRv6 or there are other readiness gaps. They may have initiated gradual hardware replacement plans but it is not always possible to invest in SRv6-capable hardware across all vendors and network layers at the same time. For this reason, the overlay approach can be used as a transitional mechanism for operators who want to gain early experience with SRv6 within limited domains during their migration.¶
Turkcell’s network architecture, for instance, uses a layered design, and each layer includes devices from different vendors. In the data center (DC) network, they are using one vendors equipment which will carry the first SRv6 deployment. This will allow them to observe SRv6 behavior directly in a live environment. By starting with a single-vendor domain, they will also have the opportunity to experience the operational simplicity of a homogeneous environment, which will help better understand the added complexity that comes with multi-vendor SRv6 deployments in later phases. In the mobile traffic layers, two different vendors’ equipment are used together, and these domains include complex L3VPN-based service chaining. These cases are being analyzed separately to assess SRv6 readiness and migration feasibility.¶
The overlay model is typically not considered a long-term migration path, but rather a transitional deployment approach that provides flexibility during the migration phase. While Overlay models may offer short-term practical advantages, they do not fully leverage native SRv6 data-plane capabilities and may introduce additional encapsulation overhead. For long-term migration goals, Ships-in-the-Night and/or Dual Plane models are typically preferred.¶
Some data center and metro networks use VXLAN as an overlay to provide L2/L3 services over an IP or MPLS network. As operators look to migrate these networks to SRv6, a clear path is needed to transition VXLAN-based deployments to a SRv6 infrastructure.¶
VXLAN-encapsulated traffic is carried within SRv6 headers while the underlying IP network remains unchanged. This allows services carried over VXLAN to continue operating while gradually introducing SRv6 capabilities at the edges and on SRv6-capable transit nodes. This is similar in principle to SRv6 over MPLS (6oM) overlays.¶
Existing VXLAN Virtual Tunnel Endpoints (VTEPs) can be upgraded to support SRv6 encapsulation for north-south traffic, while east-west traffic within a data center may continue using native VXLAN encapsulation during transition.¶
+---------------+ +---------------+
| VXLAN |===========================| VXLAN |
| VTEP | | VTEP |
+---------------+ +---------------+
| |
+------ SRv6 Encapsulation / Transport -----+
+-------- SRv6 Core --------+
The following steps provide a phased approach to migrate VXLAN networks to SRv6:¶
Upgrade edge VTEPs to support IPv6 and SRv6 encapsulation while continuing VXLAN forwarding.¶
Plan and assign SRv6 locators and SIDs for all ingress and egress VTEPs and SRv6 transit nodes.¶
Deploy SRv6 core infrastructure, either natively or as an overlay on the existing IP (or IP/MPLS) network, since VXLAN deployments typically run over an IP underlay.¶
Enable SRv6 encapsulation on upgraded VTEPs and steer selected VXLAN traffic over SRv6 transport paths.¶
Gradually migrate VXLAN traffic to SRv6 paths by modifying VTEP policies to encapsulate traffic in SRv6. During this step, VXLAN and SRv6 encapsulation effectively coexist on the same VTEPs in a Ships-in-the-Night-like fashion, with per-flow policy determining which encapsulation is used, until VXLAN is fully decommissioned.¶
Validate traffic flows, TE policies and service SLAs.¶
Decommission VXLAN encapsulation once all services have transitioned to native SRv6.¶
Another migration strategy is to allow an existing MPLS network to interwork with SRv6, as an alternative to ships-in-the-night or overlay. [I-D.ietf-spring-srv6-mpls-interworking] describes SRv6 and MPLS/SR-MPLS interworking procedures which can roughly be compared to translation solutions such as NAT or 464XLAT. This strategy enables interworking between SRv6 and MPLS domains in situations where completely separate domains must be maintained. Translation mechanisms (e.g., Segment Routing Mapping Server or SRMS) are used to map SRv6 SIDs between the two domains. This option allows hybrid operation (e.g., SRv6 at the edge, MPLS in the core). Interworking requires additional control-plane mechanisms for SID translation and may add complexity in managing two different forwarding paradigms. New SRv6 behaviors, and MPLS labels, stitch the end to end path across different data planes. The interworking document assumes SR-MPLS-IPv4 for MPLS domains but the design equally works for SR-MPLS-IPv6, LDP-IPv4/IPv6 and RSVP-TE-MPLS label binding protocols. It provides transport interworking solutions such as SRv6 over MPLS (6oM) and MPLS over SRv6 (Mo6) along with service interworking solutions such as SRv6 to MPLS(6toM) and MPLS to SRv6 (Mto6).¶
Using a gateway is an Interworking (IW) example which supports both BGP SRv6 based L2/L3 services and BGP MPLS based L2/L3 services for a service instance. It terminates service encapsulation and performs L2/L3 destination lookup in a service instance:¶
+-------------------+ +-------------------+ | ....|S-RR|.... | | ....|S-RR|..... | | : +----+ : | | : +----+ : | | : : | | : : | |----+ +-------------------------------------+ +----| |PE1 | | IW border node | | PE2| |----+ | VPN Label<->L2/L3 lookup<->SRv6 SID | +----| | | | | | +-------------------------------------+ | | MPLS | | SRv6 | +-------------------+ +-------------------+ <------MPLS VPN-----> <------SRv6 VPN----->
In interworking scenarios where the core network has migrated to SRv6, but the access or aggregation layers continue to operate using MPLS, the MPLS-over-SRv6 (Mo6) technology ([I-D.ietf-spring-srv6-mpls-interworking]) can be used to provide seamless service continuity. This approach is particularly relevant for large-scale networks that use BGP-LU to achieve end-to-end MPLS LSPs.¶
+-------BGP-LU--------+
: :
: :
+-----------------------+:---------------------:+-----------------------+
| |: :| |
+---+ +---+ +---+ +---+
| 1 | MPLS | 2 | SRv6 | 3 | MPLS | 4 |
+---+ +---+ +---+ +---+
| | | |
+-----------------------+-----------------------+-----------------------+
iPE iBR eBR ePE
The ingress and egress Border Routers (BRs) perform the interworking between MPLS and SRv6 domains. The BRs exchange loopback prefixes using BGP-LU SAFI, where the SRv6 SID associated with each prefix is an END.DT or END.DTM SID. The prefix may be learned directly via BGP-LU or redistributed from the IGP.¶
This principle applies equally to traditional MPLS networks that use LDP or RSVP-TE signaling, as well as to networks using SR-MPLS. In each case, the Mo6 mechanism allows MPLS-based transport services to be extended seamlessly across an SRv6 core, facilitating a phased migration strategy while preserving end-to-end service continuity.¶
The interworking and migration approaches discussed above focus primarily on label/SID translation and route/service continuity. Networks that use RSVP-TE for bandwidth-engineered Traffic Engineering (TE), rather than only as an LSP signaling protocol, have an additional requirement during migration. RSVP-TE LSPs reserve bandwidth along explicit paths, and this bandwidth accounting needs to be preserved, or otherwise coordinated, when SR-TE or SRv6 policies begin sharing the same links.¶
[RFC8426] provides recommendations for RSVP-TE and Segment Routing LSPs to coexist on a shared MPLS forwarding plane, including guidance on link bandwidth accounting so that RSVP-TE and SR LSPs do not oversubscribe shared links during a phased migration. Operators migrating bandwidth-engineered RSVP-TE services to SRv6 should apply the coexistence recommendations in [RFC8426] as services are incrementally moved from RSVP-TE signaled LSPs to SR-TE or SRv6 policies, rather than assuming that a simple protocol substitution preserves existing bandwidth guarantees.¶
This section describes considerations on specific topics related to SRv6 deployment and migration to SRv6.¶
SRv6 requires a network running IPv6 and forwards packets based on native IPv6. Interface IPv6 addresses need to be configured prior to SRv6 configuration. IP address planning is an important part of network design and directly affects subsequent routing, aggregation, tunnel, and security designs. Well-designed IP address planning makes service provisioning and network OAM much easier. When SRv6 needs to be deployed on a network, if IPv6 has been deployed and IPv6 addresses have been planned, the original IPv6 address planning does not necessarily need to be modified, and in the simplest case an operator only needs to select a reserved network prefix and use it to allocate SRv6 locators. Operators may nonetheless choose to revise an existing IPv6 address plan when introducing SRv6, for example to better align with locator aggregation or domain boundaries. If neither IPv6 has been deployed on a network, nor IPv6 addresses have planned, IPv6 address planning can be performed by determining the principles for IPv6 address planning on the network, determining the method of IPv6 address allocation, and hierarchically allocating IPv6 addresses.¶
During IPv6 address planning, for an E2E SRv6 network for instance, each network domain is configured with a network prefix for locator allocations to devices in this domain, allowing advertisement of only an aggregated locator route to devices outside the domain. If no IPv6 loopback interface has been configured on the network, the locator and loopback address with the same network prefix can be allocated so that only the aggregated route shared by the locator and loopback address needs to be advertised, thereby reducing the number of routes. A separate network prefix is allocated to the access and aggregation layers, and another separate network prefix is allocated to the IP core layer. Only an aggregated IPv6 route (locator and loopback address) is advertised between the aggregation and IP core layers. SRv6 service nodes only need to learn the aggregated route and the specific routes in the local domain to carry E2E SRv6 services. In addition, the number of service configuration points is reduced to two: ingress and egress. As such, the specific routes of a domain are not flooded to other domains. In addition, route changes, such as route flapping, in one domain do not cause frequent route changes in another domain. This enhances security and stability within the network.¶
Operators should consider the guidance in [RFC9602], which updates the IPv6 addressing architecture to describe the use of SIDs as IPv6 addresses. RFC9602 allocates a dedicated IPv6 prefix for SRv6 SIDs and clarifies their structure and semantics. Using the dedicated SRv6 SID prefix can simplify address planning, improve operational consistency, and provide a clearer distinction between infrastructure addresses and SRv6 locator space.¶
On an SRv6 network, in addition to the conventional route advertisement function, BGP also supports information exchange between forwarders and a controller (the controller may be, for example, an SDN controller or PCE, and the forwarders are typically P/PE routers). Forwarders use BGP-LS (Link State) to report information, such as the network topology and latency, to the controller for path computation. To support SR, forwarders need to report SR information to the controller through BGP-LS ([I-D.ietf-idr-bgp-ls-sr-policy]). Additionally, the controller uses BGP SR Policy ([I-D.ietf-idr-sr-policy-safi]) to deliver SR path information. For this reason, on an SRv6 network, BGP design needs to consider not only the IPv6 unicast address family peer design and VPN/EVPN address family peer design, but also the BGP-LS address family peer design and BGP IPv6 SR-Policy address family peer design.¶
In a VPN network (which uses MP-BGP to distribute VPN routes), a Route Reflector (RR) eliminates the need for a full mesh by allowing PE routers to peer only with the RR, which then reflects VPN routes to all other PEs. BGP treats VPNv4 (IPv4 VPN) and VPNv6 (IPv6 VPN) as different address families. Both VPNv4 and VPNv6 need to be enabled in MP-BGP when using both address families in, for example, Ships-in-the-night deployments. A single VPN can be supported by both MPLS and SRv6 simultaneously in SITN mode, but the two control planes operate independently, and seamless interworking requires additional mechanisms. VPN service over SRv6 is described in [RFC9252].¶
BGP information types have various roles in SRv6. VPNv6 routes carry customer VPN routes with SRv6 SIDs (End.DT6, End.DX4, etc.). BGP-LS collects and distributes SRv6 topology info to controllers (e.g., for SDN) and BGP SRv6 policies distribute SRv6 Traffic Engineering (TE) policies (e.g., Flex-Algo, explicit paths).¶
SRv6 VPN services can use BGP as the unified signaling control plane to provide L2/3 service connections. EVPN can be used to carry both L3VPN and L2VPN services in SRv6, thereby simplifying protocols. Hierarchical VPN is widely deployed on MPLS networks to reduce the number of routes on access devices at network edges. E2E VPN is recommended for SRv6 networks because only service access points, instead of transit nodes, need to be configured. Also, transit nodes do not need to be aware of services, and this in turn facilitates both deployment and maintenance.¶
SRv6 encapsulation introduces additional IPv6 header and SRH overhead. In VPN deployments, where multiple encapsulations (e.g., IPv6 + SRH + VPN service headers) may be present, packets are more likely to exceed the default IPv6 Path MTU (PMTU). Exceeding the PMTU can result in fragmentation or packet drops if PMTU discovery is not functioning reliably.¶
Operators could explicitly account for SRv6 overhead in access and core MTU planning. Common practices include configuring consistent MTU values across the SRv6 domain, enabling IPv6 PMTU Discovery [RFC8201], and reserving sufficient headroom for SRH and VPN encapsulation. During migration or mixed MPLS/SRv6 deployments, operators should validate MTU consistency end-to-end to avoid service interruption.¶
Where PMTU discovery cannot be assured, setting a conservative maximum packet size at ingress PEs can prevent customer traffic from exceeding the supported path MTU.¶
Inter-AS VPN is widely deployed in MPLS networks and remains critical during SRv6 migration. In SRv6, inter-AS VPN can be realized by extending VPNv6 routes with SRv6 SIDs across ASes using MP-BGP. Depending on the migration strategy, different options can be applied:¶
With ships-in-the-night, each AS can independently operate MPLS or SRv6 VPNs, with traffic exchanged over dual-stack BGP sessions.¶
In an overlay model, SRv6 traffic between ASes can be tunneled over existing MPLS or IP interconnects until both domains natively support SRv6.¶
With interworking, SRv6 SIDs may be translated to MPLS labels (or vice versa) at the ASBR, enabling hybrid deployments while preserving existing inter-AS VPN services.¶
These approaches are not mutually exclusive across a multi-AS network: an operator may apply the same strategy uniformly across all ASes, or apply different strategies on a per-AS basis depending on each AS's migration progress and priorities.¶
Operators need to consider the impact on route scaling, locator design, convergence, and policy enforcement at AS boundaries. Security measures described in [RFC8754] also apply to inter-AS SRv6 deployments, with additional need to enforce filtering and validation at ASBRs. The procedures for VPN service over SRv6 are further described in [RFC9252].¶
N/A¶
The security considerations for Segment Routing are discussed in [RFC8402]. Section 5 of [RFC8754] describes the SR Deployment Model and the requirements for securing the SR Domain. The security considerations of [RFC8754] also cover topics such as attack vectors and their mitigation mechanisms that also apply the behaviors introduced in this document. Together, they describe the required security mechanisms that allow establishment of an SR domain of trust. Having such a well-defined trust boundary is necessary in order to operate SRv6-based services for internal traffic while preventing any external traffic from accessing or exploiting the SRv6-based services. Care and rigor in IPv6 address allocation for use for SRv6 SID allocations and network infrastructure addresses, as distinct from IPv6 addresses allocated for end users and systems (as illustrated in Section 5.1 of [RFC8754], can provide the clear distinction between internal and external address space that is required to maintain the integrity and security of the SRv6 Domain. Additionally, [RFC8754] defines a Hashed Message Authentication Code (HMAC) TLV permitting SR Segment Endpoint Nodes in the SR domain to verify that the SRH applied to a packet was selected by an authorized party and to ensure that the segment list is not modified after generation, regardless of the number of segments in the segment list. When enabled by local configuration, HMAC processing occurs at the beginning of SRH processing as defined in Section 2.1.2.1 of [RFC8754].¶
Thank you to Dhruv Dhody and Eduard Metz for providing extensive comments on this draft. We also recognize the comments from Dongjie, Yanrong, Liuyao, Nat Kao, Cheng Li, Luis Miguel Contreras Murillo, Nick Morris and Vishnu Pavan Beeram.¶