IPv6-Resolved IPv4 Gateway
draft-vanmook-intarea-ipv6-resolved-gateway-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Remco van Mook | ||
| Last updated | 2026-06-17 | ||
| Replaces | draft-ipv6-resolved-gateway | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-vanmook-intarea-ipv6-resolved-gateway-01
intarea R. van Mook
Internet-Draft Asteroid International B.V.
Intended status: Standards Track 27 June 2026
Expires: 29 December 2026
IPv6-Resolved IPv4 Gateway
draft-vanmook-intarea-ipv6-resolved-gateway-01
Abstract
This document specifies host behavior enabling IPv4 communication for
dual-stack hosts on IPv6-only segments, without subnets, ARP,
tunneling, or translation. Hosts that receive 192.0.0.11/32 as their
IPv4 default gateway address resolve the next-hop link-layer address
from the IPv6 neighbor cache rather than via ARP. IPv4 packets are
forwarded natively, end-to-end. The mechanism is incrementally
deployable alongside unmodified hosts with no changes to DHCPv4
infrastructure. This document requests the allocation of
192.0.0.11/32 in the IANA IPv4 Special-Purpose Address Registry to
support this mechanism.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-vanmook-intarea-ipv6-resolved-
gateway/.
Source for this draft and an issue tracker can be found at
https://github.com/remcovanmook/draft-ipv6-resolved-gateway.
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."
van Mook Expires 29 December 2026 [Page 1]
Internet-Draft IPv6-Resolved IPv4 GW June 2026
This Internet-Draft will expire on 29 December 2026.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Host Behavior and Next-Hop Resolution . . . . . . . . . . . . 4
5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. End-to-End Packet Flow . . . . . . . . . . . . . . . . . 7
5.2. Router Ingress Behavior . . . . . . . . . . . . . . . . . 8
5.3. Backward Compatibility: Router ARP Response . . . . . . . 9
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7.1. ARP Attack Surface Reduction . . . . . . . . . . . . . . 10
7.2. Universal Gateway Address . . . . . . . . . . . . . . . . 11
8. Implementation Requirements . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. 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
van Mook Expires 29 December 2026 [Page 2]
Internet-Draft IPv6-Resolved IPv4 GW June 2026
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. Traditional mechanisms such as dual-
stack, tunneling, and translation all reintroduce IPv4 at the
infrastructure level. This document defines a sentinel IPv4 address,
192.0.0.11, 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 [RFC4861],
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 (a new DHCPv4 option, or implicit behaviour
when no router is specified) would both require DHCPv4 client changes
across every OS implementation; given typical deployment timescales,
meaningful coverage would take a decade at best. The sentinel
address approach requires no changes to DHCPv4 clients or servers and
is incrementally deployable today.
The mechanism has been verified to work without changes to
applications or DHCPv4 configuration on Windows 11, macOS, Android,
iOS, Linux, FreeBSD, and ChromeOS.
This document addresses the host-side first-hop gap left open by
[I-D.ietf-intarea-v4-via-v6], 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.
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
van Mook Expires 29 December 2026 [Page 3]
Internet-Draft IPv6-Resolved IPv4 GW June 2026
3. Problem Statement
IPv4 next-hop resolution on a local link depends on ARP, which
requires an IPv4 subnet to be configured on the link. In an
IPv6-only segment, no such subnet exists. Existing solutions --
dual-stack, tunneling, and translation-based approaches such as NAT64
-- generally require changes beyond the local segment. This document
closes the first-hop resolution gap for dual-stack hosts on IPv6-only
segments without requiring changes to host software, packet formats,
or DHCPv4 clients.
4. 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 [RFC4861] 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 to reach the host via the [I-D.ietf-intarea-v4-via-v6]
forwarding model, the first-hop router must advertise the host's /32
route with a routable IPv6 next-hop (GUA or ULA); a link-local
address is not valid as an inter-router next-hop. Operators
deploying this mechanism in conjunction with
[I-D.ietf-intarea-v4-via-v6] MUST therefore ensure the host has a
routable IPv6 address on the interface.
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 192.0.0.11 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 [RFC4861] 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.
van Mook Expires 29 December 2026 [Page 4]
Internet-Draft IPv6-Resolved IPv4 GW June 2026
2. When the next hop for an IPv4 packet is 192.0.0.11, 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 192.0.0.11 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 [RFC4861]), 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 192.0.0.11 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 192.0.0.11 expires and is not
renewed, the host SHOULD remove 192.0.0.11 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 192.0.0.11 against its
own IPv6 neighbor cache state.
The following pseudocode defines the resolution logic:
van Mook Expires 29 December 2026 [Page 5]
Internet-Draft IPv6-Resolved IPv4 GW June 2026
on interface I (where 192.0.0.11 is the configured IPv4 gateway):
if next-hop(pkt) == 192.0.0.11:
routers = default_router_list(I)
if routers is empty:
if not first_ra_received(I): /* startup: MUST queue */
queue pkt
else: /* mid-operation: MAY drop */
queue or drop pkt
send Router Solicitation on I /* ff02::2; subject to
RFC 4861 rate limiting */
return
selected = select from routers by:
1. highest Default Router Preference (RFC 4191)
2. NUD state == REACHABLE /* if preference equal */
3. implementation-defined /* if reachability equal */
lladdr = neighbor_cache(I, selected).lladdr
if lladdr is valid and NUD state != INCOMPLETE:
/* STALE, DELAY, and PROBE are usable; see RFC 4861 s7.3.3 */
send pkt in link-layer frame with dst = lladdr
else:
queue or drop pkt /* per implementation policy */
send Neighbor Solicitation for selected router on I
Router selection uses Default Router Preference as defined in
[RFC4191]. 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.
van Mook Expires 29 December 2026 [Page 6]
Internet-Draft IPv6-Resolved IPv4 GW June 2026
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.
5. Router Behavior
5.1. 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. A host cannot
resolve another host's IPv4 address on the local link without router
assistance; direct host-to-host IPv4 communication on the segment may
occur via ICMPv4 redirect ([RFC1122], Section 3.2.2.2) from the
gateway, but cannot be initiated by the host alone.
For return traffic to reach end hosts, operators MUST ensure that
host /32 routes with an IPv6 next-hop per [RFC8950] 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.
The following diagram illustrates the end-to-end packet flow.
Router-to-router forwarding uses [RFC8950]; no IPv4 address is
configured on any router interface. IPv4 addresses used in the
diagram are from the documentation ranges defined in [RFC5737] and
are not globally routable.
van Mook Expires 29 December 2026 [Page 7]
Internet-Draft IPv6-Resolved IPv4 GW June 2026
Host A Router R1
IPv4: 198.51.100.1/32 (no IPv4 address configured)
IPv6: 2001:db8:1::1 IPv6 link-local: fe80::R1
[1] IPv4 pkt (src: 198.51.100.1, dst: 203.0.113.5)
L2 dst: MAC(R1) -- resolved from ND cache, no ARP
---------------------------------------------------->
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.
5.2. Router Ingress Behavior
Routers MUST treat 192.0.0.11 as an interface-scoped address, valid
only on the interface on which it is configured, and only for
locally-terminated traffic. 192.0.0.11 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 192.0.0.11
and MAY generate ICMPv4 Time Exceeded messages using 192.0.0.11 as
the source address. All such messages are interface-local.
ICMPv4 error generation on IPv6-only transit routers is out of scope;
see [RFC7600].
van Mook Expires 29 December 2026 [Page 8]
Internet-Draft IPv6-Resolved IPv4 GW June 2026
5.3. Backward Compatibility: Router ARP Response
The use of 192.0.0.11 as the DHCPv4 Router Option (Option 3) value is
fully conformant with [RFC2132], which imposes no requirement that
the router address be reachable via ARP on the same subnet. Unlike
[RFC1027] (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 192.0.0.11 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. 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 per-host state to support both tiers simultaneously:
updated hosts will not send ARP requests for 192.0.0.11, so the
router's ARP response behavior is triggered only by unmodified hosts.
6. Deployment Considerations
This mechanism applies granularly 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 [RFC8925] (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 192.0.0.11 without any additional
configuration.
This mechanism fits within the IPv6-mostly network deployment model
described in [I-D.ietf-v6ops-6mops], specifically the case where
native IPv4 connectivity is provided to dual-stack hosts on an
IPv6-only segment.
van Mook Expires 29 December 2026 [Page 9]
Internet-Draft IPv6-Resolved IPv4 GW June 2026
CLAT [I-D.ietf-v6ops-claton] provides an alternative approach to IPv4
connectivity via translation. CLAT notes that a CLAT function SHOULD
be disabled when native IPv4 connectivity is available; this
mechanism provides exactly that native connectivity, making CLAT
unnecessary on segments where it is deployed.
Hosts without a functional IPv6 implementation on the relevant
interface cannot perform Neighbor Discovery and are outside the scope
of this document.
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 [RFC4191] to
ensure deterministic behavior.
Implementations in which IPv4 and IPv6 stacks are managed by separate
processes (as is common on mobile operating systems) will require
inter-process communication to expose the IPv6 neighbor cache to the
IPv4 forwarding path. This is an implementation consideration and
does not affect the on-wire behavior defined in this document.
DHCPv4 relay agents that enforce on-link gateway validation may
reject or flag 192.0.0.11 as an invalid router option. Operators
SHOULD verify relay agent behavior in their deployment before relying
on this mechanism.
7. Security Considerations
7.1. ARP Attack Surface Reduction
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 [RFC6105]. Subnet scanning is mitigated since hosts
carry /32 addresses only.
A host receiving 192.0.0.11 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.
van Mook Expires 29 December 2026 [Page 10]
Internet-Draft IPv6-Resolved IPv4 GW June 2026
Operators SHOULD ensure 192.0.0.11 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 192.0.0.11 from the first-hop router.
This mechanism does not interact with IPv4 link-local address
configuration per [RFC3927]. A host configured with 192.0.0.11 as
its gateway and a link-local IPv4 source address will follow the same
resolution logic defined in Section 4 (Host Behavior and Next-Hop
Resolution).
7.2. Universal Gateway Address
A consequence of the IANA allocation and the ARP behavior defined in
Section 5.3 is that 192.0.0.11 can serve as a topology-independent
gateway address in any deployment where routers respond to ARP for
it, not limited to IPv6-only segments. This document does not
specify or require this behavior in IPv4-only deployments; it is an
emergent property of the allocation.
In segments where routers respond to ARP for 192.0.0.11, it functions
as a universal gateway address. Unlike a conventional per-subnet
gateway address, it does not reveal network topology and carries no
subnet membership information. ARP cache poisoning of 192.0.0.11 is
less valuable than poisoning a conventional gateway address, as it
carries no topological information for an attacker to exploit; it can
only redirect local-segment traffic, mitigated by dynamic ARP
inspection. Rogue RA attacks achieve the same redirection and are
mitigated by RA Guard [RFC6105].
As 192.0.0.11 MUST NOT appear as source or destination in any
forwarded packet per Section 5.2, conformant deployments render it
unreachable from any device not on the local segment. This
eliminates it as a target for off-link attacks. As Source=False in
the IANA registry (see IANA Considerations), no conformant off-link
device will originate packets with 192.0.0.11 as source, precluding
volumetric attacks using this address.
IPv6 has long used specific link-local addresses (fe80::) as next-hop
addresses, topology-independent identifiers that work on any segment
without carrying subnet membership information. 192.0.0.11 provides
the same property for IPv4.
8. Implementation Requirements
An implementation is conformant if it satisfies all MUST and MUST NOT
requirements in Sections 4 and 5.
van Mook Expires 29 December 2026 [Page 11]
Internet-Draft IPv6-Resolved IPv4 GW June 2026
A reference implementation in Linux userspace is available at
https://github.com/remcovanmook/v4-with-v6-nh. A full conformance
test suite will be documented prior to IETF Last Call.
9. IANA Considerations
This document requests that IANA assign 192.0.0.11/32 in the "IANA
IPv4 Special-Purpose Address Registry" [RFC6890] as follows:
+======================+==================================+
| Field | Value |
+======================+==================================+
| Address Block | 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 |
+----------------------+----------------------------------+
Table 1
The Destination=True designation reflects that 192.0.0.11 may appear
as a destination in ICMPv4 messages received by the router on a local
interface (see Section 5.2). It does not imply global reachability;
Forwardable=False and Globally Reachable=False together preclude any
use of this address beyond the local link.
10. References
10.1. Normative References
van Mook Expires 29 December 2026 [Page 12]
Internet-Draft IPv6-Resolved IPv4 GW June 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/rfc/rfc4191>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/rfc/rfc4861>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<https://www.rfc-editor.org/rfc/rfc6890>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K.
Patel, "Advertising IPv4 Network Layer Reachability
Information (NLRI) with an IPv6 Next Hop", RFC 8950,
DOI 10.17487/RFC8950, November 2020,
<https://www.rfc-editor.org/rfc/rfc8950>.
10.2. Informative References
[I-D.ietf-intarea-v4-via-v6]
Chroboczek, J., Kumari, W., and T. Høiland-Jørgensen,
"IPv4 routes with an IPv6 next hop", Work in Progress,
Internet-Draft, draft-ietf-intarea-v4-via-v6-08, 17 April
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
intarea-v4-via-v6-08>.
[I-D.ietf-v6ops-6mops]
Buraglio, N., Caletka, O., and J. Linkova, "IPv6-mostly
Networks: Deployment and Operations Considerations", Work
in Progress, Internet-Draft, draft-ietf-v6ops-6mops-07, 2
March 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-v6ops-6mops-07>.
[I-D.ietf-v6ops-claton]
Colitti, L., Linkova, J., and T. Jensen, "464XLAT
Customer-side Translator (CLAT): Node Behavior and
van Mook Expires 29 December 2026 [Page 13]
Internet-Draft IPv6-Resolved IPv4 GW June 2026
Recommendations", Work in Progress, Internet-Draft, draft-
ietf-v6ops-claton-16, 5 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
claton-16>.
[RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to
implement transparent subnet gateways", RFC 1027,
DOI 10.17487/RFC1027, October 1987,
<https://www.rfc-editor.org/rfc/rfc1027>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/rfc/rfc1122>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/rfc/rfc2132>.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
DOI 10.17487/RFC3927, May 2005,
<https://www.rfc-editor.org/rfc/rfc3927>.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737,
DOI 10.17487/RFC5737, January 2010,
<https://www.rfc-editor.org/rfc/rfc5737>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC6105, February 2011,
<https://www.rfc-editor.org/rfc/rfc6105>.
[RFC7600] Despres, R., Jiang, S., Ed., Penno, R., Lee, Y., Chen, G.,
and M. Chen, "IPv4 Residual Deployment via IPv6 - A
Stateless Solution (4rd)", RFC 7600, DOI 10.17487/RFC7600,
July 2015, <https://www.rfc-editor.org/rfc/rfc7600>.
[RFC8925] Colitti, L., Linkova, J., Richardson, M., and T.
Mrugalski, "IPv6-Only Preferred Option for DHCPv4",
RFC 8925, DOI 10.17487/RFC8925, October 2020,
<https://www.rfc-editor.org/rfc/rfc8925>.
van Mook Expires 29 December 2026 [Page 14]
Internet-Draft IPv6-Resolved IPv4 GW June 2026
Appendix A. Acknowledgements
The author thanks Tobias Fiebig, Warren Kumari, Jen Linkova, David
Lamparter, and Jordi Palet Martinez for their feedback and review.
An earlier version of this work was presented as a lightning talk at
RIPE 91 in Bucharest (October 2025) and at IETF 124 in Montreal
(November 2025).
Author's Address
Remco van Mook
Asteroid International B.V.
Email: remco@asteroidhq.com
van Mook Expires 29 December 2026 [Page 15]