]> IRIF, University of Paris

Case 7014 75205 Paris Cedex 13 France jch@irif.fr

Google, LLC

warren@kumari.net

Red Hat

toke@toke.dk

Internet Internet Area Working Group Internet-Draft This document proposes "v4-via-v6" routing, a technique that uses IPv6 next-hop addresses for routing IPv4 packets, thus making it possible to route IPv4 packets across a network where routers have not been assigned IPv4 addresses. The document both describes the technique, as well as discussing its operational implications. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Internet Area Working Group Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The dominant form of routing in the Internet is next-hop routing, where a routing protocol constructs a routing table which is used by a forwarding process to forward packets. The routing table is a data structure that maps network prefixes in a given family (IPv4 or IPv6) to next hops, pairs of an outgoing interface and a neighbor's network address, for example: When a packet is routed according to a given routing table entry, the forwarding plane typically maps the next-hop address to a link-layer address (a "MAC address") by using a neighbor discovery protocol (for example the Neighbor Discovery protocol (ND) in the case of IPv6 over Ethernet, and the Address Resolution Protocol (ARP) in the case of IPv4 over Ethernet). The link-layer address is then used to construct the link-layer frames that encapsulate forwarded packets. It is apparent from the description above that there is no fundamental reason why the destination prefix and the next-hop address should be in the same address family: there is nothing preventing an IPv6 packet from being routed through a next hop with an IPv4 address (in which case the next hop's MAC address will be obtained using ARP), or, conversely, an IPv4 packet from being routed through a next hop with an IPv6 address. (In fact, it is even possible to store link-layer addresses directly in the next-hop entry of the routing table, thus avoiding the use of an address resolution protocol altogether, which was commonly done in networks using the OSI protocol suite.) This document focuses on the specific case of routing IPv4 packets through an IPv6 next-hop. This case is particularly interesting, since it makes it possible to build networks that have no IPv4 addresses except at the edges and still provide IPv4 connectivity to edge hosts. In addition, since an IPv6 next hop can use a link-local address that is autonomously configured, the use of such routes enables a mode of operation where the network core has no statically assigned IP addresses of either family, which significantly reduces the amount of manual configuration required. (See also for a discussion of the issues involved with such an approach.) We call a route towards an IPv4 prefix that uses an IPv6 next hop a "v4-via-v6" route. V4-via-v6 routing is not restricted to routers, and could usefully be applied to hosts, but doing so would require solving the issue of host configuration, for example by extending either DHCPv4 or DHCPv6 to publish an IPv4 default route with an IPv6 next hop, which is out of scope for this document. discusses advertising of IPv4 Network Layer Reachability Information (NLRI) with a next-hop address that belongs to the IPv6 protocol, but confines itself to how this is carried and advertised in the BGP protocol. This document, on the other hand, discusses the concept of v4-via-v6 routes independently of any specific routing protocol, their design and operational considerations, and the implications of using them. { Editor note, to be removed before publication. This document is heavily based on draft-ietf-babel-v4viav6. When draft-ietf-babel-v4viav6 was going through IESG eval, Warren raised concerns that something this fundamental deserved to be documented in a separate, standalone document, so that it can be more fully discussed, and, more importantly, referenced cleanly in the future.}

Conventions and Definitions 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.

Operation Next-hop routing is implemented by two separate components, the routing protocol and the forwarding plane, that communicate through a shared data structure, the routing table.

Structure of the routing table The routing table is a data structure that maps address prefixes to next-hops, pairs of the form (interface, address). In traditional next-hop routing, the routing table maps IPv4 prefixes to IPv4 next hops, and IPv6 addresses to IPv6 next hops. With v4-via-v6 routing, the routing table is extended so that an IPv4 prefix may map to either an IPv6 or an IPv4 next hop. Resolution may be recursive: the next-hop may itself be a prefix that requires further resolution to map to the outgoing interface and L2 address. V4-via-v6 routing does not prevent recursive resolution.

Operation of the forwarding plane The forwarding plane is the part of the routing implementation that is executed for every forwarded packet. As a packet arrives, the forwarding plane consults the routing table, selects a single route matching the packet, and forwards the packet through the outgoing interface to the associated next-hop address. With v4-via-v6 routing, the address family of the next-hop address is no longer determined by the address family of the prefix: since the routing table may map an IPv4 prefix to either an IPv4 or an IPv6 next-hop, the forwarding plane must be able to determine, on a per-packet basis, which address resolution protocol (ARP for IPv4, ND for IPv6) to consult.

Operation of routing protocols The routing protocol is the part of the routing implementation that is executed asynchronously from the forwarding plane, and whose role is to build the routing table. Since v4-via-v6 routing is a generalization of traditional next-hop routing, v4-via-v6 can interoperate with existing routing protocols: a traditional routing protocol produces a traditional next-hop routing table, which can be used by an implementation supporting v4-via-v6 routing. However, in order to use the additional flexibility provided by v4-via-v6 routing, routing protocols need to be extended with the ability to populate the routing table with v4-via-v6 routes when an IPv4 address is not available or when the available IPv4 addresses are not suitable for use as a next-hop. Some protocols already support the advertisement of IPv4 routes with an IPv6 next-hop, including Babel and BGP . Other protocol advertise both IPv4 and IPv6 prefixes over a single neighbor; these include:

• Multi-Topology (MT) Routing in OSPF ()
• Multi-Topology (MT) Routing in IS-IS ()

While both of these employ a common control plane, they use separate data planes, and therefore don't implement v4-via-v6 routing.

ICMP Considerations The Internet Control Message Protocol (ICMPv4, or simply ICMP) is a protocol related to IPv4 that is primarily used to carry diagnostic and debugging information. ICMPv4 packets may be originated by end hosts (e.g., the "destination unreachable, port unreachable" ICMPv4 packet), but they may also be originated by intermediate routers (e.g., most other kinds of "destination unreachable" packets). Some protocols deployed in the Internet rely on ICMPv4 packets sent by intermediate routers. Most notably, path MTU Discovery (PMTUd) is an algorithm executed by end hosts to discover the maximum packet size that a route is able to carry. While there exist variants of PMTUd that are purely end-to-end , the variant most commonly deployed in the Internet has a hard dependency on ICMPv4 packets originated by intermediate routers: if intermediate routers are unable to send ICMPv4 packets, PMTUd may lead to persistent black-holing of IPv4 traffic. A router must therefore be able to generate ICMP Destination Unreachable messages ( Section 5.2.7.1). The source address of these messages must be one of the addresses assigned to the outgoing interface; if no such address has been assigned, then one of the other addresses assigned to the router, known as the "router-id", must be used ( Section 4.3.2.4). Routers implementing the mechanism described in this document do not need to have any IPv4 addresses assigned to any of their interfaces, and does not specify what happens if no router-id has been assigned. If a router does not have any IPv4 addresses assigned, the router MUST use the dummy address 192.0.0.8 as the source address of outgoing ICMP packets (, Section 4.8, Requirement R-22). Using the dummy address as the source of ICMPv4 packet causes a number of drawbacks:

• using the same address on multiple routers may hamper debugging and fault isolation, e.g., when using the traceroute utility (but see for a possible solution to this problem);
• packets originating from 192.0.0.8 might be considered as spoofed traffic and dropped by firewalls at network boundaries.

For these reasons, even if a router performs v4-via-v6 routing on all interfaces, it SHOULD be assigned at least one IPv4 address.

Implementation Status ( This section to be removed before publication. ) As this document does not really define a protocol, this implementation status section is much less formal. Instead, it is being used as a place to list implementations that are known to support this functionality, examples, notes, etc. This information is provided as a guide to the reader, and is not intended to be a complete list, nor endorsement, etc. If you know of an implementation which is not listed, please let the authors know.

Arista EOS Arista has supported static IPv4 routes with IPv6 nexthops since EOS-4.30.1.

The Babel routing protocol As noted above, this document is heavily based on RFC9229 (nee draft-ietf-babel-v4viav6), and this functionality is supported by babeld. Pasted below is email sent to the babel mailing list (archived at https://mailarchive.ietf.org/arch/msg/babel/QtFi3F4TFfF7fXXlkHSpEnuT44Y/) An IPv4 route across three nodes with IPv6 addresses only: Here's how it's logged by babeld: Traceroute is a little confusing: PMTUD works fine (thanks to Toke): 10.0.0.2.22: Flags [.],\ seq 33:1481, ack 33, win 502, options [nop,nop,TS val 917354570\ ecr 1849974691], length 1448 19:58:47.402874 IP 192.168.0.27.60046 > 10.0.0.2.22: Flags [P.],\ seq 1481:1537, ack 33, win 502, options [nop,nop,TS val 917354570\ ecr 1849974691], length 56 19:58:47.402906 IP 192.0.0.8 > 192.168.0.27: ICMP 10.0.0.2 \ unreachable- need to frag (mtu 1420), length 556 19:58:47.402919 IP 10.0.0.2.22 > 192.168.0.27.60046: Flags [.],\ ack 33, win 509, options [nop,nop,TS val 1849974692 \ ecr 917354569,nop,nop,sac 1 {1481:1537}], length 0 19:58:47.402934 IP 192.168.0.27.60046 > 10.0.0.2.22: Flags [.], \ seq 33:1401, ack 33, win 502, options [nop,nop,TS val 917354570 \ ecr 1849974692], length 1368 ]]> -- Juliusz

Linux Linux has supported v4-via-v6 routes since kernel version 5.2, released on 2019-07-07.

Example:

Mikrotik RouterOS Mikrotik RouterOS has supported v4-via-v6 routes since (at least) version 7.11beta2 {Editor note: I'm not sure when support was added. I tested this in Version 7.11beta2, and it worked there, but I believe that this functionality has existed for a while. I'll try to find out when it was added.}

Example print Flags: D - DYNAMIC; I - INACTIVE, A - ACTIVE; c - CONNECT, s - STATIC, d -DHCP, v - VPN; H - HW-OFFLOADED Columns: DST-ADDRESS, GATEWAY, DISTANCE # DST-ADDRESS GATEWAY DISTANCE 0 As 192.0.2.0/24 fe80::201:5cff:feb2:1646%1_Comcast 1 ]]>

Cisco NX-OS Cisco NX-OS has supported v4-via-v6 routes "for more than 8 years" -- Krishnaswamy Ananthamurthy

Operational Considerations Even though v4-via-v6 routes are similar in structure to traditional next-hop routes, at least some monitoring and management tools will not be able to interpret them. Deployment of v4-via-v6 routing in a network will require testing and updating of all tools and scripts that manipulate or examine routes. V4-via-v6 routing encourages a model of deployment where some routers have no IPv4 addresses even though they forward IPv4 traffic. Such routers make debugging of IPv4 routing issues somewhat more difficult, most notably by making the output of the traceroute utility less informative than it would otherwise be (see Section ). Even if the procedures described in are deployed on all such routers, older versions of traceroute will not be able to interpret the additional information. Network administrators might want to provision IPv4 addresses on all routers in order to simplify debugging.

Security Considerations The techniques described in this document make routing more flexible by allowing IPv4 routes to propagate across a section of a network that has only been assigned IPv6 addresses. This additional flexibility might invalidate otherwise reasonable assumptions made by network administrators, which could potentially cause security issues. For example, if an island of IPv4-only hosts is separated from the IPv4 Internet by routers that have not been assigned IPv4 addresses, a network administrator might reasonably assume that the IPv4-only hosts are unreachable from the IPv4 Internet. This assumption is broken if the intermediary routers implement v4-via-v6 routing, which might make the IPv4-only hosts reachable from the IPv4 Internet. If this is not desirable, then the network administrator must filter out the undesirable traffic in the forwarding plane by implementing suitable packet filtering rules.

IANA Considerations No IANA actions are requested by this document.

References Normative References This document specifies a stateless solution for service providers to progressively deploy IPv6-only network domains while still offering IPv4 service to customers. The solution's distinctive properties are that TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during domain traversal and that IPv4 fragmentation rules are fully preserved end to end. Each customer can be assigned one public IPv4 address, several public IPv4 addresses, or a shared address with a restricted port set. This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is an issue of general concern in the ARPA Internet Community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of an Internet Standard. This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. [STANDARDS-TRACK] This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. [STANDARDS-TRACK] This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] This document describes an extension to Open Shortest Path First (OSPF) in order to define independent IP topologies called Multi- Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in- band network management topology. An optional extension to exclude selected links from the default topology is also described. [STANDARDS-TRACK] This document describes an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. [STANDARDS-TRACK] In an IPv6 network, it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to facilitate the decision process for a given network. Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a next-hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI. This document specifies the extensions necessary to allow the advertising of IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the next hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the next hop to determine which of the protocols the address actually belongs to, and a BGP Capability allowing MP-BGP peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 next hop. This document obsoletes RFC 5549. This document defines an extension to the Babel routing protocol that allows announcing routes to an IPv4 prefix with an IPv6 next hop, which makes it possible for IPv4 traffic to flow through interfaces that have not been assigned an IPv4 address. Arista Networks Arista Networks RFC5837 describes a mechanism for Extending ICMP for Interface and Next-Hop Identification, which allows providing additional information in an ICMP error that helps identify interfaces participating in the path. This is especially useful in environments where a given interface may not have a unique IP address to respond to, e.g., a traceroute. This document introduces a similar ICMP extension for Node Identification. It allows providing a unique IP address and/or a textual name for the node, in the case where each node may not have a unique IP address (e.g., a deployment in which all interfaces have IPv6 addresses and all nexthops are IPv6 nexthops, even for IPv4 routes).

Acknowledgments This document is based on , which was produced by the IETF Babel working group. We are grateful to Joe Abley, Krishnaswamy Ananthamurthy, Vint Cerf, Joe Clarke, Lorenzo Colitti, Bill Fenner, Tobias Fiebig, John Gilmore, Bob Hinden, Jen Linkova, David Lamparter, Gyan Mishra, tom petch, Herbie Robinson, Behcet Sarikaya, David Schinazi, Ole Troan, and Éric Vyncke for helpful comments and suggestions about this document.

Changes This section is to be removed before publication, and the primary change log is the git repository. This is just a place to note some of the more substantive changes.

Version 03-04

• Added a section about operational considerations.
• Made it clear that ARP/ND are not necessarily used.
• Removed any mention of v4-only, since it's not quite correct that v4-via-v6 is v4-only.

Version 02-03

• Warren is a smart guy, but he still pushed a branch instead of the main one, so -03 is actually what -02 should have been.

Version 01-02

• Addressed comments from Vint and Jen.

Version 00-01

• Added note that this works just as well for IPv6 routes with an IPv4 next hop. (Éric Vyncke)
• Cisco NX-OS has supported v4-via-v6 routes "for more than 8 years" (Krishnaswamy Ananthamurthy)
• Mention recursive next hops, and that the next hop may be a prefix. (Krishnaswamy Ananthamurthy)
• Hosts are routers too! (David Lamparter)
• Removed the claim that it's mainly a UI issue.