]> Asteroid International B.V.

remco@asteroidhq.com

TU Wien

tobias@internet.wien

Internet Internet Area Working Group Internet-Draft This document specifies host behavior enabling IPv4 communication for dual-stack hosts on IPv6-only segments, without IPv4 subnets, ARP, tunneling, or translation. A host is provisioned by ordinary DHCPv4 or by static configuration. Where its IPv4 default gateway is a reserved sentinel address, the host resolves the next-hop link-layer address from the IPv6 neighbor cache rather than by ARP. IPv4 packets are forwarded natively, end to end. The mechanism is incrementally deployable alongside unmodified hosts; no flag day or mandatory switch-over point is needed. This document requests the allocation of one IPv4 address from 192.0.0.0/24 in the IANA IPv4 Special-Purpose Address Registry. 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 mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction An IPv4 address functions as a service endpoint identifier: either for a client seeking access to a service, or a server providing one. The BSD socket API, present in virtually every operating system and language runtime, expresses this directly: a call to connect(AF_INET, "192.0.2.1", 80) is a statement about which service to reach, not about routing or link-layer resolution. The host implements IPv4 natively; routers recognise and forward IPv4 packets and will continue to do so. What this document changes is solely how the host resolves the link-layer next-hop for the first hop. Networks transitioning to IPv6-only segments still need to carry IPv4 traffic for dual-stack hosts. IPv4 next-hop resolution depends on ARP, which presupposes an IPv4 subnet on the link; an IPv6-only segment has none. Dual-stack, tunneling and translation all reintroduce IPv4 at the infrastructure level and require changes beyond the local segment. This document defines a sentinel IPv4 address, IPV4-SENTINEL, that signals to a host stack that link-layer resolution for the IPv4 default gateway is derived from the link-layer address entry for the IPv6 default router in the neighbor cache , rather than via ARP. The IPv4 routing table entry is unchanged; only the next-hop resolution path is modified. This eliminates the need for IPv4 subnets and ARP on the local segment, removing the requirement for tunneling or translation at the first hop. This problem is already being solved in production, but inconsistently. Hosting providers including Hetzner, OVH, and Scaleway independently deploy /32 host addresses with off-link IPv4 gateways using per-OS workarounds (Linux pointopoint, netplan on-link: true, explicit post-up routes). None of this is documented in any RFC, and the implementations are not interoperable across providers. This draft standardises the pattern with a single sentinel address that host stacks can implement natively. Alternative approaches such as a new DHCPv4 option would require client changes across every OS implementation as well as requiring changes across any OSS/BSS software that contains validation logic or encodes the shape of an IPv4 gateway. The sentinel is a valid gateway address; the only place that needs to know the special semantics defined in this document is the host. Unmodified hosts, using the router's ARP response, have been verified to work without changes to applications or DHCPv4 client configuration on Windows 11, macOS, Android, iOS, Linux, FreeBSD, and ChromeOS. This document addresses the host-side first-hop gap left open by , which defines router-to-router forwarding of IPv4 traffic over IPv6 next-hops. Together, the two documents provide a complete solution: hosts reach their first-hop router without ARP, and routers forward IPv4 traffic across an IPv6-only infrastructure without IPv4 addresses on any router interface.

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. IPV4-SENTINEL denotes the IPv4 address whose allocation is requested in . [RFC Editor: replace IPV4-SENTINEL with the address assigned by IANA (TBD1) and remove this note.] Examples and figures use 192.0.2.11, from the TEST-NET-1 documentation range .

Host Behavior and Next-Hop Resolution This mechanism activates only when a functional IPv6 implementation is present on the same interface, sufficient to perform Neighbor Discovery per and process Router Advertisements. Without IPv6 on the interface, the sentinel address has no effect and the host continues to behave as if no gateway were configured. For the outbound path, link-local IPv6 operation is sufficient. For return traffic, a link-local address is valid as a next hop only on its own link. A first-hop router therefore advertises a host's /32 either with itself as next hop, or with a routable IPv6 address of the host (GUA or ULA), in which case the operator MUST ensure the host has one. A host implementing this mechanism SHOULD be configured with a /32 prefix length for its IPv4 address. With a broader prefix, the host will continue to ARP for addresses it considers on-link, defeating the purpose of the mechanism for local segment traffic. A /32 ensures all IPv4 traffic is directed to the first-hop router via the sentinel, with no on-link ARP possible. When a host is configured to use IPV4-SENTINEL as its IPv4 default gateway, the host's operating system MUST implement the following logic:

1. The host MUST maintain a functional IPv6 Neighbor Discovery implementation per on the same interface, including default router discovery and neighbor cache maintenance. No additional action specific to this mechanism is required at interface configuration time.
2. When the next hop for an IPv4 packet is IPV4-SENTINEL, the host MUST NOT perform ARP. Instead, it consults the IPv6 default router list and neighbor cache for the link-layer address, scoped to the interface on which IPV4-SENTINEL is configured as the IPv4 default gateway.
3. If the IPv6 default router link-layer address is in a usable NUD state (REACHABLE, STALE, DELAY, or PROBE per ), the IPv4 packet is sent in a link-layer frame addressed to that destination.
4. If no reachable IPv6 default router is known after the interface has completed initial configuration (i.e., at least one RA has been processed), the packet MAY be queued or dropped per implementation policy. If a last-known router address is available, a Neighbor Solicitation SHOULD be sent to that address. For behavior prior to first RA reception, see the startup paragraph below.

Host stacks MUST treat IPV4-SENTINEL as a sentinel address signalling that IPv6-based next-hop resolution is to be used, regardless of other address configuration on the interface. This behavior is unconditional and not dependent on any additional signaling. When a DHCPv4 lease configuring IPV4-SENTINEL expires and is not renewed, the host SHOULD remove IPV4-SENTINEL as the IPv4 default gateway and cease IPv6-based resolution on that interface. For statically configured deployments, removal is governed by local administrative policy. Cross-interface resolution MUST NOT be performed. On multi-homed hosts, each interface independently resolves IPV4-SENTINEL against its own IPv6 neighbor cache state. IPV4-SENTINEL is thus an interface-scoped next-hop token, configured per interface by the DHCPv4 Router Option, with source address selection following the egress interface as for any other gateway. The following pseudocode defines the resolution logic: Router selection uses Default Router Preference as defined in . When multiple routers have equal preference and reachability, the tiebreaker is implementation-defined; use of most-recently-heard RA is one reasonable approach. If the selected IPv6 default router becomes unreachable during an active session, the host SHOULD re-evaluate the default router list and select an alternative. Existing transport sessions will be disrupted if the link-layer next-hop changes; this is consistent with IPv6 router failure behavior and is not specific to this mechanism. Packets queued for a router that has become unreachable SHOULD be flushed and re-evaluated against the updated router selection. Each time an interface transitions to an operational state and begins RA solicitation, a host may receive DHCPv4 configuration before any RA has been processed. Until a reachable IPv6 default router is known, IPv4 packets MUST be queued rather than silently dropped, pending RA reception. Implementations SHOULD bound this queue duration to avoid indefinite resource consumption. On queue timeout, packets SHOULD be dropped and an ICMPv4 Host Unreachable message MAY be generated toward the sending application.

Router Behavior

End-to-End Packet Flow In this model, end hosts are assigned IPv4 addresses with a /32 prefix length. No IPv4 prefix is configured on the link; a sending host directs all IPv4 traffic to the first-hop router using the link-layer address derived from the IPv6 neighbor cache. For return traffic to reach end hosts, operators MUST ensure that host /32 routes with an IPv6 next-hop per are present in the routing infrastructure, allowing routers to forward IPv4 traffic toward the correct first-hop without requiring IPv4 addresses on any router interface. The mechanism by which the routing infrastructure learns these host routes is outside the scope of this document. For the lifetime of a host's address assignment, the first-hop router MUST maintain the ability to deliver to that host's /32 without depending on opportunistically learned neighbor cache state, so that expiry of a cache entry cannot permanently break return traffic. The following diagram illustrates the end-to-end packet flow. Router-to-router forwarding uses ; no IPv4 address is configured on any router interface. IPv4 addresses used in the diagram are from the documentation ranges defined in and are not globally routable. Router R1 Router R2 (no IPv4 address) (no IPv4 address configured) IPv6 link-local: fe80::R1 IPv6 link-local: fe80::R2 [2] FIB lookup: 203.0.113.5/32 via fe80::R2 (RFC 8950) L2 dst: MAC(R2) -- resolved from ND cache, no ARP ----------------------------------------------------> Router R2 Host B (no IPv4 address) IPv4: 203.0.113.5/32 IPv6 link-local: fe80::R2 IPv6: 2001:db8:2::2 [3] FIB lookup: 203.0.113.5/32 via fe80::HostB (ND) L2 dst: MAC(HostB) -- resolved from ND cache, no ARP ----------------------------------------------------> [4] IPv4 packet delivered to Host B ]]> No ARP is exchanged at any point.

Router Ingress Behavior Routers MUST treat IPV4-SENTINEL as an interface-scoped address, valid only on the interface on which it is configured, and only for locally-terminated traffic. IPV4-SENTINEL does not appear in IPv4 fragment headers; fragmentation behavior is unchanged by this mechanism. Specifically:

• It MUST NOT be injected into any routing protocol.
• It MUST NOT trigger overlapping-subnet checks.
• It MUST NOT appear as source or destination in any forwarded packet.

A router MAY respond to ICMPv4 echo requests addressed to IPV4-SENTINEL and MAY generate ICMPv4 Time Exceeded messages using IPV4-SENTINEL as the source address. All such messages are interface-local. ICMPv4 error generation on IPv6-only transit routers is out of scope; see .

Backward Compatibility: Router ARP Response The use of IPV4-SENTINEL as the DHCPv4 Router Option (Option 3) value is fully conformant with , which imposes no requirement that the router address be reachable via ARP on the same subnet. Unlike (proxy ARP), the router is not proxying for a remote host; it owns this address on the interface for the purpose of link-layer reachability. Unmodified hosts receiving IPV4-SENTINEL as their IPv4 default gateway will issue an ARP request for it. A router SHOULD respond to such ARP requests with its own MAC address if unmodified hosts may be on the segment, and MAY omit the response otherwise. This is not proxy ARP: no subnet exists, no remote host is being proxied. This enables a two-tier deployment model on the same L2 segment:

• Unmodified hosts: router answers ARP; IPv4 forwarding works with zero host-side changes.
• Updated hosts: link-layer address resolved from IPv6 neighbor cache; ARP eliminated entirely.

Both tiers interoperate, allowing incremental deployment. The router requires no additional per-host state to support both tiers simultaneously: updated hosts will not send ARP requests for IPV4-SENTINEL, so the router's ARP response behavior is triggered only by unmodified hosts. Note: This ARP response exists for the migration period. Once no unmodified hosts remain on a segment, an operator can disable it, leaving the segment free of ARP.

Deployment Considerations This mechanism applies at the segment level. A network may contain a mix of IPv4-only, dual-stack, and IPv6-only segments; this mechanism is applicable specifically to IPv6-only segments carrying dual-stack hosts and does not affect other segment types. This mechanism complements (IPv6-Only Preferred Option). RFC 8925 allows hosts to signal a preference for IPv6-only operation, but operators must still provide IPv4 for hosts or applications that require it. This document provides exactly that fallback: IPv4 connectivity on an IPv6-only segment, without requiring a dual-stack infrastructure or an IPv4 subnet on the local link. A host that receives Option 108 and transitions to IPv6-only operation retains functional IPv4 connectivity via IPV4-SENTINEL without any additional configuration. This mechanism fits within the IPv6-mostly network deployment model described in , specifically the case where native IPv4 connectivity is provided to dual-stack hosts on an IPv6-only segment. CLAT provides outbound IPv4 through a shared translator pool, whereas this mechanism gives a host its own IPv4 address; they meet different needs. CLAT notes that a CLAT function SHOULD be disabled when native IPv4 connectivity is available, which this mechanism provides. Hosts without a functional IPv6 implementation on the relevant interface cannot perform Neighbor Discovery and are outside the scope of this document. The mechanism inherits ND's operational prerequisites: ICMPv6 permitted on host firewalls, functioning MLD snooping and multicast forwarding, no MAC filtering of solicited-node groups. These are already prerequisites for IPv6 service. On segments with multiple routers advertising equal Default Router Preference (common in datacenter ECMP fabrics), hosts may make inconsistent router selections based on RA timing. Operators SHOULD configure explicit Default Router Preference values per to ensure deterministic behavior. Every router advertising itself as an IPv6 default router on the segment can be selected as the IPv4 first hop, so it MUST forward IPv4 and have a return path per ; a lower preference does not remove a router from selection. DHCPv4 relay agents that enforce on-link gateway validation may reject or flag IPV4-SENTINEL as an invalid router option. Operators SHOULD verify relay agent behavior in their deployment before relying on this mechanism. A relaying interface needs no IPv4 address, but giaddr must be a routable IPv4 address, for which one loopback per relay router suffices; link selection decouples giaddr from pool selection where needed.

Security Considerations In the updated-host deployment model, ARP is eliminated from the segment entirely. In the unmodified-host model, ARP is constrained to the sentinel address from a known source (the first-hop router), eliminating the class of ARP-based network reconnaissance and spoofing attacks that are possible in conventional subnet deployments. Broadcast traffic is reduced to a single predictable ARP exchange per unmodified host at startup, compared to continuous ARP traffic across a conventional subnet. The mechanism relies on the integrity of IPv6 Neighbor Discovery. Rogue RA risks apply as in any IPv6 deployment and can be mitigated with RA Guard . Subnet scanning is mitigated since hosts carry /32 addresses only. IPV4-SENTINEL carries no topology information, so poisoning its ARP entry only redirects local-segment traffic; dynamic ARP inspection mitigates this. As IPV4-SENTINEL MUST NOT appear as source or destination in any forwarded packet per , conformant deployments render it unreachable from off-link and unusable as a spoofed source address beyond the segment. A host receiving IPV4-SENTINEL as its IPv4 default gateway on a network that does not implement this mechanism will issue an ARP request that receives no response, causing IPv4 connectivity to fail silently. Operators SHOULD ensure IPV4-SENTINEL is only offered via DHCPv4 on segments where the mechanism is deployed. DHCPv4 snooping and dynamic ARP inspection, where used, MUST be configured to permit ARP responses for IPV4-SENTINEL from the first-hop router. This mechanism does not interact with IPv4 link-local address configuration per . A host configured with IPV4-SENTINEL as its gateway and a link-local IPv4 source address will follow the same resolution logic defined in .

IANA Considerations This document requests that IANA assign a single IPv4 address from the 192.0.0.0/24 IETF Protocol Assignments block in the "IANA IPv4 Special-Purpose Address Registry" . The address 192.0.0.11/32 is suggested. The registry's current contents are maintained by IANA at .

Field	Value
Address Block	TBD1 (suggested: 192.0.0.11/32)
Name	IPv4 Gateway via IPv6 Resolution
RFC	This document
Allocation Date	(date of publication)
Termination Date	N/A
Source	True
Destination	True
Forwardable	False
Globally Reachable	False
Reserved-by-Protocol	False

Source=True and Destination=True reflect that a first-hop router originates and receives interface-local ICMPv4 messages using this address (see ). Forwardable=False and Globally Reachable=False preclude any use beyond the local link.

References Normative References This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. [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 memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block. 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. 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 IANA n.d. This RFC describes the use of the Address Resolution Protocol (ARP) by subnet gateways to permit hosts on the connected subnets to communicate without being aware of the existence of subnets, using the technique of "Proxy ARP". IRIF, Université Paris-Cité Google, LLC Red Hat V4-via-v6 routing is a technique that uses IPv6 next-hop addresses for routing IPv4 packets, and thus makes it possible to route IPv4 packets across a network where some routers have not been assigned IPv4 addresses. This document describes v4-via-v6 routing, and defines related operational procedures, notably the origination of ICMPv4 packets by nodes that might not have an IPv4 address. Three IPv4 unicast address blocks are reserved for use in examples in specifications and other documents. This document describes the use of these blocks. This document is not an Internet Standards Track specification; it is published for informational purposes. This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK] This document describes the link selection sub-option of the relay- agent-information option for the Dynamic Host Configuration Protocol (DHCPv4). The giaddr specifies an IP address which determines both a subnet, and thereby a link on which a Dynamic Host Configuration Protocol (DHCP) client resides as well as an IP address that can be used to communicate with the relay agent. The subnet-selection option allows the functions of the giaddr to be split so that when one entity is performing as a DHCP proxy, it can specify the subnet/link from which to allocate an IP address, which is different from the IP address with which it desires to communicate with the DHCP server. Analogous situations exist where the relay agent needs to specify the subnet/link on which a DHCP client resides, which is different from an IP address that can be used to communicate with the relay agent. [STANDARDS-TRACK] To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link. IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface. [STANDARDS-TRACK] This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK] Routed protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. This document is not an Internet Standards Track specification; it is published for informational purposes. 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 document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This document specifies a DHCPv4 option to indicate that a host supports an IPv6-only mode and is willing to forgo obtaining an IPv4 address if the network provides IPv6 connectivity. It also updates RFC 2563 to specify DHCPv4 server behavior when the server receives a DHCPDISCOVER not containing the Auto-Configure option but containing the new option defined in this document. Energy Sciences Network RIPE NCC Google This document discusses a deployment scenario called "an IPv6-mostly network", when IPv6-only and IPv4-enabled endpoints coexist on the same network (e.g. local area network (LAN)). This approach enables incremental transition from dual-stack to IPv6-only networks by allowing IPv6-capable devices to remain IPv6-only while the network is seamlessly supplying IPv4 addresses to those devices that require them. This document discusses the requirements, recommendations, and challenges associated with deploying IPv6-mostly networks in enterprise and public Wi-Fi environments. Google Google Cloudflare 464XLAT defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution involves two functional elements: a provider-side translator (PLAT) and a customer-side translator (CLAT). This document updates the 464XLAT specification (RFC6877) and Requirements for IPv6 Customer Edge Routers (RFC8585) by further defining CLAT node behavior and IPv6 Customer Edge Routers to support IPv4-as-a-Service by providing recommendations for node developers on enabling and disabling CLAT.

Implementation Status [RFC Editor: remove this section and the reference to before publication.] This section records implementation status per . Reference implementations by one of the authors are available at https://github.com/remcovanmook/v4-with-v6-nh. They use 192.0.0.11 as a provisional value for IPV4-SENTINEL. Host implementations:

• Linux: v4gwd, a user-space daemon, and a systemd-networkd patch that is not upstream.
• FreeBSD: a daemon using the kernel's support for IPv4 routes with IPv6 next hops.
• macOS and Windows: daemons that pin IPV4-SENTINEL in a static neighbor entry to the IPv6 default router's link-layer address. They follow a single router, and macOS sends transient ARP at boot before the daemon starts.

None is fully conformant with . Implementations outside the kernel cannot queue packets pending the first RA, and apply sentinel handling only while running or, for networkd, when enabled. Conformance needs native support in the host stack. Router implementations: Debian configurations for a single router, an active/active pair and a centrally orchestrated fabric, run on live testbeds; and example configurations for IOS XR, Junos, SR OS, EOS and RouterOS, not yet tested on hardware. The repository maps the requirements of an earlier version of this document to the code, with lab tests for connectivity, the absence of ARP, and withdrawal on lease expiry.

Acknowledgements The authors thank Warren Kumari, Jen Linkova, David Lamparter, and Jordi Palet Martinez for their feedback and review.