Native IPv4 Forwarding over IPv6-Only Routing Infrastructure

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 6 May 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 (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.¶

Table of Contents

1. Introduction

IPv6 deployment continues to expand across service-provider, enterprise, data-center, and interconnection networks. At the same time, IPv4 connectivity remains necessary for many services, applications, and end systems.¶

This creates an architectural question: does continued IPv4 connectivity require continued IPv4 addressing throughout the routing infrastructure that supports it?¶

Existing IETF specifications and operational deployments show that this is not necessarily the case. IPv4 routes may be associated with IPv6 next hops, routing sessions established over IPv6 may exchange IPv4 reachability, and IPv4 packets may continue to be forwarded natively even when IPv4 addressing is no longer required on the corresponding infrastructure links.¶

These capabilities have been specified through different routing mechanisms and applied in different deployment contexts. Generic v4-via-v6 routing describes IPv4 routes with IPv6 next hops independently of a particular routing protocol. Border Gateway Protocol (BGP) extensions provide signaling for IPv4 reachability with IPv6 next-hop information, while similar routing properties also appear in Babel. Deployment examples include provider-edge/customer-edge (PE-CE) interconnections, Internet Exchange Points (IXPs), and data-center fabrics.¶

Although these mechanisms and deployment practices have largely been documented separately, they share a common characteristic: the address family used by the routing infrastructure does not need to determine the address family of the routes or traffic it supports. Making this separation explicit helps explain how IPv6-only routing infrastructure can coexist with continued IPv4 connectivity.¶

The primary scope of this document is native forwarding. Mechanisms that provide IPv4 connectivity through encapsulation, tunneling, translation, or address mapping are outside this forwarding model, except where they are referenced to clarify architectural boundaries or related work.¶

2. Terminology and Scope

This document uses terminology from the referenced RFCs and Internet-Drafts where applicable. In particular, the use of "IPv6-only" follows the scope-oriented approach described in [I-D.ietf-v6ops-ipv6-only]: the term describes the functionality within a specified scope rather than the complete protocol capabilities of a device or network.¶

For clarity, the following terms are used in this document:¶

IPv6-only routing infrastructure

A routing infrastructure in which IPv6 is used for infrastructure addressing, routing adjacencies where applicable, and next-hop resolution. Within this scope, IPv4 addressing is not required on the corresponding infrastructure links or interfaces. IPv4 routes and native IPv4 forwarding may nevertheless remain supported.¶

Infrastructure addressing

Addressing assigned to infrastructure interfaces and links for routing adjacency formation and next-hop reachability.¶

Routing transport address family

The address family used to establish and maintain a routing-protocol session between peers.¶

Route address family

The address family of the destination prefix being advertised, learned, or installed.¶

Next-hop address family

The address family of the next-hop address associated with a route.¶

Forwarded packet address family

The address family of the packet being forwarded.¶

v4-via-v6

The routing model in which an IPv4 route is associated with an IPv6 next hop. Unless otherwise qualified, this document uses the term in the generic sense described by the v4-via-v6 work rather than as a capability of any particular routing protocol.¶

Native IPv4 forwarding

The forwarding of an IPv4 packet as an IPv4 packet, without encapsulation or translation solely for the purpose of traversing the routing infrastructure.¶

The terms above describe distinct roles and should not be interpreted as requiring the same address family. Their relationship is discussed in Section 3.¶

This document focuses on routing and forwarding mechanisms that retain native IPv4 forwarding while IPv6 is used within the routing infrastructure. Mechanisms that provide IPv4 connectivity through tunneling, encapsulation, address translation, or address mapping are outside the primary scope of this document. Examples include softwire mechanisms such as those described in [RFC5565]. Such mechanisms may be referenced where necessary to clarify the scope or architectural distinction.¶

3. A Common Architectural View

Routing and forwarding involve several distinct address-family roles. In many conventional deployments, these roles are aligned: infrastructure interfaces use the same address family as routing adjacencies, routes are associated with next hops of the same address family, and packets of that address family are forwarded across the infrastructure.¶

This alignment is common, but it is not a fundamental requirement.¶

Infrastructure addressing, routing transport address family, route address family, next-hop address family, and forwarded packet address family represent different functions. Existing routing mechanisms allow different address families to be used for these functions. A routing session established over IPv6 may exchange IPv4 reachability, an IPv4 route may resolve through an IPv6 next hop, and the resulting IPv4 packet may still be forwarded natively as an IPv4 packet.¶

The relationship can be represented conceptually as follows:¶

Infrastructure addressing        IPv6
|
Routing transport AF
(where applicable)               IPv6
|
Route AF                         IPv4 or IPv6
|
Next-hop AF                      IPv6
|
Forwarded packet AF              IPv4 or IPv6

The vertical arrangement above illustrates functional relationships rather than a protocol processing sequence. The address-family choice for one role does not, by itself, determine the choice for another.¶

In particular, the route address family identifies the reachability being represented, while the next-hop address family identifies how that reachability is resolved toward the next router. The forwarded packet address family remains a property of the packet being carried and does not need to match the address family used for infrastructure addressing or next-hop resolution.¶

This separation makes it possible for IPv6 to become the common basis for infrastructure addressing, routing adjacencies where applicable, and next-hop resolution while IPv4 reachability and native IPv4 forwarding remain available where required.¶

In the context of this document, the resulting pattern is referred to as an IPv6-only routing infrastructure supporting native IPv4 forwarding. This is an architectural view of existing routing capabilities rather than a new forwarding architecture. The following sections relate this view to the mechanisms and deployment practices that realize it.¶

4. Existing Mechanisms and Relationship to Existing Work

The architectural separation described in Section 3 is supported by existing routing mechanisms and appears in several IETF specifications and Internet-Drafts. Some define how IPv4 routes can use IPv6 next hops, while others apply that capability within particular routing protocols or deployment environments.¶

This section summarizes the mechanisms most directly relevant to this document and relates them to the architectural model in Section 3.¶

5. Deployment Scenarios

The mechanisms described in Section 4 can be applied in several deployment environments. The scenarios in this section illustrate how the architectural separation described in Section 3 appears under different routing relationships, topologies, and operational contexts.¶

These scenarios are representative deployment patterns rather than prescribed architectures. Their applicability depends on implementation support and the operational requirements of the network concerned.¶

Customer Network
PA IPv4 Prefix
|
CE
|
IPv6 PE-CE Link
|
PE
|
Provider Network

CE:  IPv4 default route  -> PE IPv6 next hop
PE:  Customer IPv4 route -> CE IPv6 next hop

Customer Network
IPv4 / IPv6 Prefixes
|
CE
Customer AS
|
eBGP over IPv6
|
PE
|
Provider Network

Routing transport AF:    IPv6
IPv4 route AF:           IPv4
IPv4 next-hop AF:        IPv6
Forwarded packet AF:     IPv4 or IPv6

+--------------+
| Route Server |
|     IPv6     |
+------+-------+
|
IPv6 Peering LAN
-----------------------------
|             |          |
AS-A          AS-B       AS-C

BGP sessions:       IPv6
Reachability:       IPv4 and IPv6
IPv4 next hops:     IPv6

+-----------+       +-----------+
|  Spine 1  |       |  Spine 2  |
| AS 65000  |       | AS 65000  |
+-----+-----+       +-----+-----+
\                   /
\  IPv6 Fabric    /
\     Links     /
+-------+------+------+-------+
|              |              |
+---+---+      +---+---+      +---+---+
| Leaf 1|      | Leaf 2|      | Leaf 3|
|AS65101|      |AS65102|      |AS65103|
+---+---+      +---+---+      +---+---+
|              |              |
IPv4/IPv6      IPv4/IPv6      IPv4/IPv6
Workloads      Workloads      Workloads

Fabric addressing:       IPv6
BGP adjacencies:         IPv6
IPv4 route AF:           IPv4
IPv4 next-hop AF:        IPv6
Forwarded packet AF:     IPv4 or IPv6

IPv4 Workload                    IPv4 Workload
|                                |
VTEP-1 ========================= VTEP-2
VXLAN over IPv6
|
IPv6 Underlay

Inner packet:       IPv4
Outer transport:    IPv6

6. Implementation and Deployment Experience

This section records implementation and deployment experience with the mechanisms described in this document. It is intended to provide evidence of implementation feasibility and operational experience during the Internet-Draft phase and may be removed before publication, consistent with the guidance in [RFC7942].¶

Cross-address-family static routing has been documented in commercial routing implementations. Juniper documents support for IPv4 static routes with IPv6 next hops on multiple Junos platforms [JUNIPER-XAF-STATIC]. Cisco IOS XR documents cross-address-family static routing, including recursive IPv6 next hops for IPv4 prefixes [CISCO-XAF-STATIC]. These implementations provide direct examples of the static-routing model described in Section 5.1.¶

For Internet Exchange Points, the Euro-IX RFC8950-IXP work maintains configuration examples and interoperability information across multiple routing implementations for the use of IPv6 next hops with IPv4 routes [EUROIX-IXP]. Operational experience has also been reported from NIX, BCIX, and TREX, including production use of RFC 8950 on multiple NIX peering subnets and deployment of an IPv6-only approach at TREX Turku [TREX-VNNOG]. This experience corresponds to the interconnection model described in Section 5.3.¶

Meta has reported production deployment of IPv4 NLRI with IPv6 next hops while removing IPv4 addressing from affected links in its edge network [META-NANOG92]. The reported experience also identifies implementation-specific behavior involving IPv4 forwarding on interfaces without IPv4 addresses, mixed IPv4 and IPv6 next-hop multipath behavior, routing policy, and operational tooling.¶

Taken together, these reports demonstrate that the mechanisms described in this document have been implemented and deployed in operational environments. They also show that support in the routing plane does not necessarily imply identical forwarding or operational behavior across implementations.¶

7. What These Deployments Have in Common

The deployment scenarios in Section 5 differ in scale, topology, routing relationships, and operational context. What they have in common is not a single topology or protocol design, but the separation of address-family roles described in Section 3.¶

This common pattern can be summarized in two architectural groups:¶

The first group describes functions of the routing infrastructure. The second describes the reachability and traffic that the infrastructure continues to support. The address-family choices in these two groups need not evolve together.¶

This distinction is important because continued IPv4 connectivity does not necessarily imply a continuing requirement for IPv4 addressing on the corresponding routing-infrastructure links or adjacencies. IPv4 may remain present as route information and forwarded traffic even as IPv6 becomes the common basis for infrastructure addressing and next-hop reachability.¶

Taken together, these deployment patterns, along with the implementation and deployment experience summarized in Section 6, provide a common way to understand existing mechanisms that were developed for different routing and deployment contexts. The recurrence of this pattern across specifications, implementations, and operational deployments provides the basis for the deployment convergence discussed in Section 8.¶

8. Deployment Convergence

Deployment convergence around this pattern can be considered across three related areas: protocol specifications, implementation support, and operational deployment.¶

Protocol specifications define the routing and forwarding behavior of the relevant mechanisms. Implementations determine how those mechanisms are realized on network platforms. Operational deployment shows how they behave under real network conditions and at different scales.¶

These areas are closely related. Specifications guide implementations, implementations affect deployment choices, and deployment experience can reveal interoperability issues or practical limitations.¶

The mechanisms and deployments discussed in Sections 4 through 6 do not converge toward a single topology, protocol design, or migration model. Rather, the convergence considered here lies in the appearance of the same architectural separation between routing-infrastructure functions and the reachability and traffic supported by that infrastructure.¶

This convergence is therefore architectural and operational rather than prescriptive. It provides a common basis for applying existing mechanisms across different network environments while allowing each deployment to retain its own topology, routing design, and operational constraints.¶

9. Applicability and Limitations

The model's applicability depends on several conditions. The participating systems need to support IPv4 routes with IPv6 next hops in both the routing and forwarding planes. Where a routing protocol is used, the required signaling behavior also needs to be supported. The IPv6 next hop needs to be resolvable through the relevant IPv6 routing and neighbor-resolution mechanisms.¶

Implementation and deployment experience described in Section 6 shows that routing-plane support and forwarding-plane behavior may differ across implementations. Support for IPv4 routes with IPv6 next hops does not by itself guarantee that a platform will forward IPv4 packets on interfaces without IPv4 addressing. Implementations may also differ in their treatment of mixed IPv4 and IPv6 next-hop paths, including multipath forwarding behavior.¶

Native IPv4 forwarding over infrastructure links without IPv4 addressing also requires the ability to originate ICMPv4 messages. Source-address selection and related considerations are described in [I-D.ietf-intarea-v4-via-v6].¶

These conditions may be satisfied within a limited part of a network rather than across the network as a whole. A PE-CE interconnection, an IXP peering LAN, or a data-center fabric may use the model described here while other parts of the same network continue to use conventional dual-stack infrastructure.¶

IPv6-only routing infrastructure does not imply the removal of IPv4 routing or forwarding state. Where native IPv4 connectivity remains required, IPv4 routes remain present, IPv4 forwarding state remains necessary, and IPv4 packets continue to be processed and forwarded as IPv4 packets.¶

The model is therefore most relevant where reducing dependency on IPv4 infrastructure addressing provides value while native IPv4 connectivity must still be retained. It is not intended as a universal replacement for dual-stack infrastructure, nor does it define a general migration procedure for removing IPv4 addressing from routing infrastructure.¶

10. Security Considerations

This document does not define a new routing or forwarding protocol and does not introduce new protocol-specific security mechanisms.¶

The security considerations of the specifications that define the underlying routing and forwarding behavior continue to apply. In particular, the security considerations of [RFC8950] and [I-D.ietf-intarea-v4-via-v6] are relevant to deployments described in this document.¶

Where IPv4 forwarding depends on IPv6 next-hop reachability, the availability and integrity of the IPv6 routing and neighbor-resolution infrastructure also affect IPv4 connectivity. Failures or attacks that disrupt IPv6 routing adjacencies, next-hop resolution, or infrastructure reachability may therefore affect both IPv6 and native IPv4 forwarding.¶

The use of IPv6 for infrastructure addressing or next-hop resolution does not remove the security requirements associated with IPv4 traffic. IPv4 routing policy, filtering, and other security controls remain applicable where IPv4 reachability and native IPv4 forwarding are retained.¶

Operational and security visibility also depends on management systems being able to represent the relationship between IPv4 routes and IPv6 next hops. Loss of that visibility can make failures or policy violations affecting native IPv4 forwarding more difficult to detect or diagnose.¶

11. IANA Considerations

This document has no IANA actions.¶

Author's Address