Why IPv6 is the new MPLS Label Stack

By Leonir Hoxha on December 28, 2025

For many years, MPLS has been the foundation of traffic engineering and service delivery across service provider networks. It is reliable and extremely good at one thing, steering traffic across predetermined paths using simply a label stack. But the networking world around MPLS has changed. We now operate in environments that require more automation, more integration between domains, more service awareness inside the data plane, and a more scalable way of encoding and distributing forwarding instructions.

This is where SRv6 enters the picture, not as an incremental enhancement, but as a fundamentally new way of thinking of how we express forwarding behavior in the network. IPv6, which many people still view as “just a larger address space,” becomes much more than that. In SRv6, IPv6 becomes the language of the network, a mechanism to encode not only where packets should go, but what the network should do with them along the way. This is why now, I say that IPv6 is becoming the new MPLS label stack.

Before we can appreciate what SRv6 changes, it’s worth looking back at why MPLS succeeded so widely. The MPLS label stack offered something that pure IP forwarding could never do reliably: a deterministic sequence of forwarding decisions. Each MPLS label represented an instruction from one router to the next. The top label told the router where to send the packet next, and once that label was consumed, the next label became active. This allowed us to build traffic-engineered paths, VPN services, and through mechanisms like RSVP-TE, very predictable forwarding behavior, though, personally I never liked the amount of signaling with RSVP, but that’s another story.

However, MPLS labels, by design, carry very limited semantic meaning. A label identifies a forwarding equivalence class or what we as Engineers mostly call ‘the FEC’, that’s all, nothing more. The network operator must rely on additional signaling protocols to distribute those labels, define their meaning, maintain their scope, and ensure consistency across routers of the same IGP domain, sometimes also between different domains. Labels are always locally significant, meaning Router A’s label ‘200’ has no relationship to Router B’s label ‘200’. Every hop must therefore participate in a control plane that constantly updates and refreshes label mappings.

So, how do we turn IPv6 Addresses into Network Instructions? SRv6 brings a fundamentally different mindset. Instead of depending on opaque numerical identifiers like MPLS labels, SRv6 uses IPv6 addresses to represent both a location and an action. A Segment Identifier (SID) is simply an IPv6 prefix that tells a router: “When you receive a packet with this SID as the active destination, perform this specific behavior.”

This is the essence of SRv6 Network Programming. The network no longer forwards blindly based on top labels, it tries to execute a series of functions, each encoded inside the segment list of the packet. A SID can tell a router to forward normally (much like a Node-SID), to forward via a specific adjacency, to lookup a VPN forwarding table, to apply a service policy or other instructions. These are not separate features requiring additional encapsulations; they are part of the SRv6 behavior set that is universally recognized across the network.

What makes this powerful is that a SID’s meaning is globally consistent. Unlike MPLS labels (LDP era, not SR-MPLS), you don’t need separate distribution protocols to tell each router what the “value” of the SID represents. The SID is just an IPv6 address (or a portion of it, depending on whether it is a full-SID or uSID), advertised through IS-IS (today) so every router understands how to reach it and what behavior it represents. This alone simplifies quiet a lot on the control plane side.

The closest parallel between MPLS and SRv6 appears in the Segment Routing Header (SRH). This header carries an ordered list of SIDs, exactly like an MPLS label stack carries an ordered set of labels. As the packet moves through the network, each router examines the current active SID, performs the associated behavior, and then moves to the next SID in the list.

While the mechanics resemble MPLS, the expressiveness is far greater. Each SID is a 128-bit IPv6 address capable of encoding structured behaviors instead of simply pointing to a next-hop. The SID becomes an instruction, not just a forwarding hint. For example, a SID such as 2001:db8:100:e100 (End.DT4) indicates that the router must perform a specific L3VPN lookup. Another SID might instruct the router to force traffic through a particular low-latency path, while a different SID triggers an SRv6 based service function like redirecting the packet through a firewall chain. This creates a pipeline of network actions executed in sequence, similar to how a program executes instructions.

One of the most compelling aspects of adopting SRv6 is the simplification of the control plane. MPLS requires the orchestration of label distributions and sometimes multiple signaling protocols to maintain forwarding consistency. SRv6 collapses much of this complexity by leveraging the existing IPv6 control plane. IS-IS or OSPFv3 advertises SID prefixes exactly as they advertise any other IPv6 route. There is no need for RSVP to signal bandwidth requirements or LDP to maintain label mappings. This reduction in protocol dependencies does not just simplify device configuration, it simplifies troubleshooting, automation, and large-scale operations. Operators no longer need to inspect multiple protocol databases to determine why a label is missing or why an LSP did not form. Everything is routed through familiar IPv6 reachability. Because SIDs are globally meaningful, an operator can debug forwarding behavior using standard IPv6 visibility tools without translating labels or querying protocol databases.

So, why IPv6 truly replaces the MPLS Label Stack you might ask? When I say that IPv6 is the new MPLS label stack, I’m not simply making a conceptual analogy. In SRv6 deployments, the SRH and SIDs literally take over the role that the MPLS label stack performed. But SRv6 enhances this model by allowing those “labels” to carry behaviors, service functions, and policy logic. In MPLS, the label stack could only steer the packet through the network. In SRv6, the segment list can define a complete chain of actions that combine forwarding, service logic, security enforcement, or some kind of telemetry operations. The simplicity of a deterministic forwarding path remains intact, but the capability expands dramatically beyond what MPLS can express.

This is not to say MPLS is obsolete or inadequate. MPLS still powers vast global networks and will continue to do so. But SRv6 presents a cleaner, more scalable long term model that integrates naturally with IPv6 deployment strategies and aligns with modern network principles. Once you start viewing SIDs as instructions rather than addresses, the significance becomes clear. The network is no longer just moving packets toward a destination, it is executing an ordered sequence of actions defined by the packet itself, well, by the source itself to be more specific. And all of it is encoded in IPv6 destination address field.

The MPLS label stack served the industry extremely well. But SRv6 shows that IPv6 can evolve beyond being an endpoint address to becoming a full programming language for the network. That is why IPv6 is not just replacing the MPLS label stack, but it is redefining what the label stack can be.

With that, I’d like to close it for now and let me know if you want to read more about SRv6 in the future posts. I’m planning to go more in depth in the next posts.