Skip to content

Commit b62d8ce

Browse files
remcovmremcovm
committed
updated to -01
1 parent 24a5966 commit b62d8ce

2 files changed

Lines changed: 567 additions & 42 deletions

File tree

‎draft-vanmook-intarea-ipv6-resolved-gateway-00.md‎

Lines changed: 376 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,376 @@
1+
---
2+
title: IPv6-Resolved IPv4 Gateway
3+
abbrev: IPv6-Resolved IPv4 GW
4+
docname: draft-vanmook-intarea-ipv6-resolved-gateway-latest
5+
date: 2026-04-30
6+
category: std
7+
ipr: trust200902
8+
workgroup: intarea
9+
submissiontype: IETF
10+
consensus: true
11+
v: 3
12+
keyword: Internet-Draft
13+
14+
venue:
15+
github: "remcovanmook/draft-ipv6-resolved-gateway"
16+
17+
stand_alone: yes
18+
pi: [toc, sortrefs, symrefs]
19+
20+
author:
21+
-
22+
ins: R.S. van Mook
23+
name: Remco van Mook
24+
org: Asteroid International B.V.
25+
email: remco@asteroidhq.com
26+
27+
normative:
28+
RFC4191:
29+
RFC4861:
30+
RFC6890:
31+
RFC8950:
32+
33+
informative:
34+
RFC1122:
35+
RFC5737:
36+
RFC2132:
37+
RFC3927:
38+
RFC6105:
39+
RFC7600:
40+
RFC8925:
41+
--- abstract
42+
43+
This document requests the allocation of the IPv4 special-purpose
44+
address `192.0.0.11/32` to enable IPv4 communication over IPv6-only
45+
networks without subnets, ARP, tunneling, or translation. Hosts
46+
configured with this address as their IPv4 default gateway resolve
47+
the next-hop link-layer address from the IPv6 neighbor cache instead
48+
of via ARP. IPv4 packets are carried natively, end-to-end.
49+
50+
--- middle
51+
52+
# Introduction
53+
54+
Networks migrating to IPv6-only infrastructure still need to carry
55+
IPv4 traffic. Traditional mechanisms such as dual-stack, tunneling,
56+
and translation all reintroduce IPv4 at the infrastructure level.
57+
This document defines a special-purpose IPv4 address, `192.0.0.11`,
58+
that signals to a host stack that link-layer resolution for the
59+
IPv4 default gateway is derived from the link-layer address entry
60+
for the IPv6 default router in the neighbor cache {{RFC4861}},
61+
rather than via ARP. The IPv4 routing table entry is unchanged;
62+
only the ARP resolution path is modified. This eliminates the
63+
need for IPv4 subnets and ARP on the local segment, removing
64+
the requirement for tunneling or translation at the first hop.
65+
66+
# Conventions and Definitions
67+
68+
{::boilerplate bcp14-tagged}
69+
70+
# Problem Statement
71+
72+
IPv4 next-hop resolution on a local link depends on ARP, which
73+
requires an IPv4 subnet to be configured on the link. In an
74+
IPv6-only network, no such subnet exists. Existing solutions
75+
-- dual-stack, tunneling, and translation-based approaches
76+
such as NAT64 -- generally require changes beyond the local
77+
segment. This document closes the first-hop resolution gap
78+
for IPv4 hosts on IPv6-only segments without requiring changes
79+
to host software, packet formats, or DHCPv4 clients.
80+
81+
# Host Behavior and Next-Hop Resolution
82+
83+
When a host is configured to use `192.0.0.11` as its IPv4 default
84+
gateway, the host's operating system MUST implement the following
85+
logic:
86+
87+
1. The host MUST maintain a functional IPv6 Neighbor Discovery
88+
implementation per {{RFC4861}} on the same interface,
89+
including default router discovery and neighbor cache
90+
maintenance. No additional action specific to this mechanism
91+
is required at interface configuration time.
92+
2. When the next hop for an IPv4 packet is `192.0.0.11`, the host
93+
MUST NOT perform ARP. Instead, it consults the IPv6 default
94+
router list and neighbor cache for the link-layer address,
95+
scoped to the interface on which `192.0.0.11` is configured
96+
as the IPv4 default gateway.
97+
3. If the IPv6 default router link-layer address is in a usable
98+
NUD state (REACHABLE, STALE, DELAY, or PROBE per {{RFC4861}}),
99+
the IPv4 packet is sent in a link-layer frame addressed to
100+
that destination.
101+
4. If no reachable IPv6 default router is known after the
102+
interface has completed initial configuration (i.e., at
103+
least one RA has been processed), the packet MAY be queued
104+
or dropped per implementation policy. If a last-known
105+
router address is available, a Neighbor Solicitation
106+
SHOULD be sent to that address. For behavior prior to
107+
first RA reception, see the startup paragraph below.
108+
109+
Host stacks MUST treat `192.0.0.11` as a reserved address
110+
requiring IPv6-based next-hop resolution, regardless of other
111+
address configuration on the interface. This behavior is
112+
unconditional and not dependent on any additional signaling.
113+
When a DHCPv4 lease configuring `192.0.0.11` expires and
114+
is not renewed, the host SHOULD remove `192.0.0.11` as the
115+
IPv4 default gateway and cease IPv6-based resolution on that
116+
interface. For statically configured deployments, removal
117+
is governed by local administrative policy.
118+
119+
Cross-interface resolution MUST NOT be performed. On multi-homed
120+
hosts, each interface independently resolves `192.0.0.11` against
121+
its own IPv6 neighbor cache state.
122+
123+
The following pseudocode defines the resolution logic:
124+
125+
~~~
126+
on interface I (where 192.0.0.11 is the configured IPv4 gateway):
127+
128+
if next-hop(pkt) == 192.0.0.11:
129+
130+
routers = default_router_list(I)
131+
132+
if routers is empty:
133+
if not first_ra_received(I): /* startup: MUST queue */
134+
queue pkt
135+
else: /* mid-operation: MAY drop */
136+
queue or drop pkt
137+
send Router Solicitation on I /* ff02::2; subject to
138+
RFC 4861 rate limiting */
139+
return
140+
141+
selected = select from routers by:
142+
1. highest Default Router Preference (RFC 4191)
143+
2. NUD state == REACHABLE /* if preference equal */
144+
3. implementation-defined /* if reachability equal */
145+
146+
lladdr = neighbor_cache(I, selected).lladdr
147+
148+
if lladdr is valid and NUD state != INCOMPLETE:
149+
/* STALE, DELAY, and PROBE are usable; see RFC 4861 s7.3.3 */
150+
send pkt in link-layer frame with dst = lladdr
151+
else:
152+
queue or drop pkt /* per implementation policy */
153+
send Neighbor Solicitation for selected router on I
154+
~~~
155+
156+
Router selection uses Default Router Preference as defined in
157+
{{RFC4191}}. When multiple routers have equal preference and
158+
reachability, the tiebreaker is implementation-defined; use
159+
of most-recently-heard RA is one reasonable approach.
160+
161+
If the selected IPv6 default router becomes unreachable during
162+
an active session, the host SHOULD re-evaluate the default
163+
router list and select an alternative. Existing transport
164+
sessions will be disrupted if the link-layer next-hop changes;
165+
this is consistent with IPv6 router failure behavior and is not
166+
specific to this mechanism. Packets queued for a router that
167+
has become unreachable SHOULD be flushed and re-evaluated
168+
against the updated router selection.
169+
170+
Each time an interface transitions to an operational state
171+
and begins RA solicitation, a host may receive DHCPv4
172+
configuration before any RA has been processed. Until a
173+
reachable IPv6 default router is known, IPv4 packets MUST
174+
be queued rather than silently dropped, pending RA reception.
175+
Implementations SHOULD bound this queue duration to avoid
176+
indefinite resource consumption. On queue timeout, packets
177+
SHOULD be dropped and an ICMPv4 Host Unreachable message
178+
MAY be generated toward the sending application.
179+
180+
# Router Behavior
181+
182+
## End-to-End Packet Flow
183+
184+
In this model, end hosts are assigned IPv4 addresses with a /32
185+
prefix length. No IPv4 prefix is configured on the link; a
186+
sending host directs all IPv4 traffic to the first-hop router
187+
using the link-layer address derived from the IPv6 neighbor cache.
188+
A host cannot resolve another host's IPv4 address on the
189+
local link without router assistance; direct host-to-host
190+
IPv4 communication on the segment may occur via ICMPv4 redirect
191+
({{RFC1122}}, Section 3.2.2.2) from the gateway, but cannot be
192+
initiated by the host alone.
193+
194+
For return traffic to reach end hosts, operators MUST ensure
195+
that host /32 routes with an IPv6 next-hop per {{RFC8950}}
196+
are present in the routing infrastructure, allowing routers
197+
to forward IPv4 traffic toward the correct first-hop without
198+
requiring IPv4 addresses on any router interface. The mechanism
199+
by which the routing infrastructure learns these host routes is
200+
outside the scope of this document.
201+
202+
The following diagram illustrates the end-to-end packet flow.
203+
Router-to-router forwarding uses {{RFC8950}}; no IPv4 address
204+
is configured on any router interface. IPv4 addresses used in
205+
the diagram are from the documentation ranges defined in
206+
{{?RFC5737}} and are not globally routable.
207+
208+
~~~
209+
Host A Router R1
210+
IPv4: 198.51.100.1/32 (no IPv4 address configured)
211+
IPv6: 2001:db8:1::1 IPv6 link-local: fe80::R1
212+
213+
[1] IPv4 pkt (src: 198.51.100.1, dst: 203.0.113.5)
214+
L2 dst: MAC(R1) -- resolved from ND cache, no ARP
215+
---------------------------------------------------->
216+
217+
Router R1 Router R2
218+
(no IPv4 address) (no IPv4 address configured)
219+
IPv6 link-local: fe80::R1 IPv6 link-local: fe80::R2
220+
221+
[2] FIB lookup: 203.0.113.5/32 via fe80::R2 (RFC 8950)
222+
L2 dst: MAC(R2) -- resolved from ND cache, no ARP
223+
---------------------------------------------------->
224+
225+
Router R2 Host B
226+
(no IPv4 address) IPv4: 203.0.113.5/32
227+
IPv6 link-local: fe80::R2 IPv6: 2001:db8:2::2
228+
229+
[3] FIB lookup: 203.0.113.5/32 via fe80::HostB (ND)
230+
L2 dst: MAC(HostB) -- resolved from ND cache, no ARP
231+
---------------------------------------------------->
232+
[4] IPv4 packet delivered to Host B
233+
~~~
234+
235+
No ARP is exchanged at any point.
236+
237+
## Router Ingress Behavior
238+
239+
Routers MUST treat `192.0.0.11` as an interface-scoped
240+
address -- valid only on the interface on which it is
241+
configured, and only for locally-terminated traffic.
242+
Specifically:
243+
244+
- It MUST NOT be injected into any routing protocol.
245+
- It MUST NOT trigger overlapping-subnet checks.
246+
- It MUST NOT appear as source or destination in any
247+
forwarded packet.
248+
249+
A router MAY respond to ICMPv4 echo requests addressed to
250+
`192.0.0.11` and MAY generate ICMPv4 Time Exceeded messages using
251+
`192.0.0.11` as the source address. All such messages are
252+
interface-local.
253+
254+
ICMPv4 error generation on IPv6-only transit routers is out of
255+
scope; see {{RFC7600}}.
256+
257+
## Backward Compatibility: Router ARP Response
258+
259+
The use of `192.0.0.11` as the DHCPv4 Router Option (Option 3)
260+
value is fully conformant with {{RFC2132}}, which imposes no
261+
requirement that the router address be reachable via ARP on
262+
the same subnet.
263+
264+
Unmodified hosts receiving `192.0.0.11` as their IPv4 default
265+
gateway will issue an ARP request for it. A router SHOULD respond
266+
to such ARP requests with its own MAC address. This is not proxy
267+
ARP: no subnet exists, no remote host is being proxied.
268+
269+
This enables a two-tier deployment model on the same L2 segment:
270+
271+
- **Unmodified hosts:** router answers ARP; IPv4 forwarding works
272+
with zero host-side changes.
273+
- **Updated hosts:** link-layer address resolved from IPv6 neighbor
274+
cache; ARP eliminated entirely.
275+
276+
Both tiers interoperate, allowing incremental deployment.
277+
The router requires no per-host state to support both
278+
tiers simultaneously: updated hosts will not send ARP
279+
requests for `192.0.0.11`, so the router's ARP response
280+
behavior is triggered only by unmodified hosts.
281+
282+
# Deployment Considerations
283+
284+
This mechanism complements {{RFC8925}} (IPv6-Only Preferred
285+
Option). RFC 8925 allows hosts to signal a preference for
286+
IPv6-only operation, but operators must still provide IPv4
287+
for hosts or applications that require it. This document
288+
provides exactly that fallback: IPv4 connectivity on an
289+
IPv6-only segment, without requiring a dual-stack
290+
infrastructure or an IPv4 subnet on the local link. A host
291+
that receives Option 108 and transitions to IPv6-only
292+
operation retains functional IPv4 connectivity via
293+
`192.0.0.11` without any additional configuration.
294+
295+
Hosts without an IPv6 stack are outside the scope of this
296+
document.
297+
298+
On segments with multiple routers advertising equal Default
299+
Router Preference -- common in datacenter ECMP fabrics -- hosts
300+
may make inconsistent router selections based on RA timing.
301+
Operators SHOULD configure explicit Default Router Preference
302+
values per {{RFC4191}} to ensure deterministic behavior.
303+
304+
Implementations in which IPv4 and IPv6 stacks are managed by
305+
separate processes -- as is common on mobile operating systems --
306+
will require inter-process communication to expose the IPv6
307+
neighbor cache to the IPv4 forwarding path. This is an
308+
implementation consideration and does not affect the on-wire
309+
behavior defined in this document.
310+
311+
# Security Considerations
312+
313+
In the updated-host deployment model, ARP is eliminated from the
314+
network entirely. In the unmodified-host model, ARP is constrained
315+
to a single well-known address, reducing the ARP attack surface
316+
relative to conventional dual-stack networks.
317+
318+
The mechanism relies on the integrity of IPv6 Neighbor Discovery.
319+
Rogue RA risks apply as in any IPv6 deployment and can be
320+
mitigated with RA Guard {{RFC6105}}. Subnet scanning is
321+
mitigated since hosts carry /32 addresses only.
322+
323+
A host receiving `192.0.0.11` as its IPv4 default gateway
324+
on a network that does not implement this mechanism will issue
325+
an ARP request that receives no response, causing IPv4
326+
connectivity to fail silently. Operators SHOULD ensure
327+
`192.0.0.11` is only offered via DHCPv4 on segments where
328+
the mechanism is deployed. DHCPv4 snooping and dynamic ARP
329+
inspection, where used, MUST be configured to permit ARP
330+
responses for `192.0.0.11` from the first-hop router.
331+
332+
This mechanism does not interact with IPv4 link-local address
333+
configuration per {{RFC3927}}. A host configured with
334+
`192.0.0.11` as its gateway and a link-local IPv4 source
335+
address will follow the same resolution logic defined in
336+
Section 4 (Host Behavior and Next-Hop Resolution).
337+
338+
# Implementation Requirements
339+
340+
[PLACEHOLDER: This section will document conformance
341+
requirements and reference known implementations prior
342+
to IETF Last Call. An implementation is conformant if
343+
it satisfies all MUST and MUST NOT requirements in
344+
Sections 4 and 5. A reference implementation is
345+
available at https://github.com/remcovanmook/v4-with-v6-nh.]
346+
347+
# IANA Considerations
348+
349+
This document requests that IANA assign `192.0.0.11/32` in the
350+
"IANA IPv4 Special-Purpose Address Registry" {{RFC6890}} as follows:
351+
352+
| Field | Value |
353+
|----------------------|--------------------------------|
354+
| Address Block | 192.0.0.11/32 |
355+
| Name | IPv4 Gateway via IPv6 Resolution |
356+
| RFC | This document |
357+
| Allocation Date | (date of publication) |
358+
| Termination Date | N/A |
359+
| Source | True |
360+
| Destination | True |
361+
| Forwardable | False |
362+
| Globally Reachable | False |
363+
| Reserved-by-Protocol | False |
364+
365+
The Destination=True designation reflects that `192.0.0.11`
366+
may appear as a destination in ICMPv4 messages received by
367+
the router on a local interface (see Section 5.2). It does
368+
not imply global reachability; Forwardable=False and
369+
Globally Reachable=False together preclude any use of this
370+
address beyond the local link.
371+
372+
--- back
373+
374+
# Acknowledgements
375+
376+
The author thanks Tobias Fiebig, Warren Kumari, and Jen Linkova.

0 commit comments

Comments
 (0)