IPv6-Resolved IPv4 Gateway

1.1. Related Work

The underlying pattern -- a first-hop IPv4 gateway that is not resolved by ordinary ARP against a shared on-link subnet -- has been independently reinvented many times, in mutually incompatible forms.¶

Proxy ARP [RFC925] [RFC1027] had a router answer ARP on behalf of addresses that were not on the requesting host's link. Point-to-point access architectures, among them PPPoE [RFC2516] and 3GPP bearers, deliver an IPv4 address to a terminal over a link with no subnet and no neighbor resolution at all. The softwires IPv4-as-a-Service family [RFC8585] carries IPv4 service across an IPv6-only access network to the customer edge. Container networking reached the same shape independently: Calico gives each workload a next-hop of 169.254.1.1 that is never assigned to any interface and exists only to be answered by proxy ARP on the host side of the interface pair [CALICO-FAQ]. The hosting-provider /32 configurations described above are a further instance, as are the pre-standard arrangements for routing IPv4 over IPv6 next-hops that preceded [RFC8950].¶

Each of these is the same idea, constrained to one domain, and each was previously kept there by a condition that has since expired. There was no standardised transport for IPv4 routes with IPv6 next-hops before [RFC8950]. Host stacks were treated as unchangeable, an assumption disproved by the deployment of [RFC8925] Option 108 and of CLAT across mainstream operating systems. Every prior instance lived inside a walled domain -- a single vendor, access technology, or orchestrator -- and so never needed an interoperable code point. And IPv4 service on an IPv6-only network was generally assumed to call for translation.¶

Those conditions no longer hold. The contribution of this document is therefore not a new mechanism, but a general and interoperable form of one that has repeatedly been built in private and left undocumented.¶

4.1. Multi-Homed Hosts

Cross-interface resolution MUST NOT be performed. On multi-homed hosts, each interface independently resolves IPV4-SENTINEL against its own IPv6 neighbor cache state.¶

The sentinel is an interface-scoped next-hop token, not the address of a particular router. It denotes "the IPv6 default router on this interface" and carries no topological information. Two interfaces configured with the same value resolve it to two different link-layer addresses, by way of two different IPv6 default router lists. This is the property IPv6 link-local next-hops already have, where a route is meaningful only together with the interface it is attached to.¶

Every IPv4 route whose next hop is the sentinel is therefore a triple, not a pair:¶

(destination prefix, outgoing interface, via IPV4-SENTINEL)

A host holding a sentinel default route on each of two interfaces holds two distinct routes rather than a conflict:¶

0.0.0.0/0   dev if1   via IPV4-SENTINEL
0.0.0.0/0   dev if2   via IPV4-SENTINEL

They are disambiguated exactly as the equivalent IPv6 routes with link-local next-hops are: by outgoing interface, and by whatever metric or policy the host already applies when choosing between two default routes. Resolution then proceeds per the algorithm above, independently on each interface, against that interface's own neighbor cache.¶

DHCPv4 needs no extension to express this. A DHCPv4 client already keeps configuration per interface, and a lease obtained on one interface supplies the Router Option (Option 3) default for that interface alone. More specific routes are carried per interface in the same way, through the Classless Static Route Option (Option 121) [RFC3442], whose router field accepts the sentinel as it would any other next-hop value. Both sides of the exchange are thus already interface-scoped; see Section 8 for demonstrations.¶

Source address selection is unaffected by this mechanism. Once an egress interface has been selected, the host chooses a source address from that interface exactly as it does today. The sentinel is never a candidate source address and never appears in a forwarded packet (see Section 5.3).¶

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, so all intra-segment IPv4 traffic is forwarded by the first-hop router.¶

This mechanism does not rely on ICMPv4 redirects ([RFC1122], Section 3.2.2.2). A redirect conveys a next-hop address alone, and so cannot express the (destination, interface, sentinel) form that next-hop resolution takes here (see Section 4.1); on a multi-homed host the result would be ambiguous. Redirects are in any case widely filtered or ignored in current deployments. Where traffic is to be steered towards one of several first-hop routers, that selection is made through Default Router Preference [RFC4191] in Router Advertisements, which operates per interface and is already required by this mechanism for router selection.¶

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.¶

Host A                      Router R1
IPv4: 198.51.100.1/32       (no IPv4 address configured)
IPv4 gw: 192.0.2.11         IPv6 link-local: fe80::R1
IPv6: 2001:db8:1::1

  [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-to-Host Binding Durability

A first-hop router MUST be able, for the lifetime of a host's IPv4 address assignment, to deliver IPv4 traffic to that host's /32 without depending on opportunistically learned neighbor cache state.¶

The failure mode this prohibits is the following. A router that learns a host's link-layer address only as a side effect of traffic, and holds the resulting IPv6 neighbor cache entry under ordinary garbage collection, will discard that entry once the host has been idle long enough. If the host's /32 route is derived from that entry, the route is withdrawn with it, and inbound traffic that would have prompted re-resolution never arrives, because it is discarded upstream for want of a route. Connectivity then does not recover, and the host cannot recover it, since the host has no way to learn that it has become unreachable from outside. Outbound traffic from the host repairs the binding, but a host with no reason to send will remain unreachable indefinitely.¶

Satisfying this requirement is a matter of router implementation and operator configuration, and the mechanisms are outside the scope of this document. They include deriving the binding from DHCPv4 lease state rather than from traffic, provoking Neighbor Discovery from that lease state, populating the binding from an orchestration or route distribution system, and anchoring it to a delegated prefix. A separate document is expected to catalogue acceptable configurations.¶

5.3. 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 [RFC7600].¶

5.4. Backward Compatibility: Router ARP Response

The use of IPV4-SENTINEL 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 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. 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 IPV4-SENTINEL, so the router's ARP response behavior is triggered only by unmodified hosts.¶

The ARP responder is migration machinery, and it is under operator control. It exists so that unmodified hosts keep working while a segment is being converted. An operator SHOULD enable it for as long as unmodified hosts remain on the segment, and SHOULD disable it once none do. The two-tier model is a transitional state rather than the end state: on a fully migrated segment no ARP is exchanged at all, the router's own responder included.¶

The requirement in Section 4 that a host MUST NOT perform ARP for the sentinel is correspondingly strict, and this document deliberately defines no host-side fallback to ARP. A sanctioned fallback would mean that no operator could safely retire the responder on any segment, since a conformant host might resort to ARP at any time. The zero-ARP end state would be foreclosed permanently, and the return would be the masking of a misconfiguration that is better surfaced (see Section 7).¶

6.1. Applicability

Hosts without a functional IPv6 implementation on the relevant interface cannot perform Neighbor Discovery and are outside the scope of this document.¶

6.2. Relationship to Other Transition Mechanisms

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 IPV4-SENTINEL 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.¶

CLAT [I-D.ietf-v6ops-claton] and this mechanism serve different demand profiles, and are not alternatives for the same host. CLAT provides outbound IPv4 reachability by translating into a pool shared at the PLAT; address sharing is the point of it, and a host behind a CLAT has no IPv4 address of its own that a remote peer can address. This mechanism provides the complementary thing: a per-host IPv4 address that is routable end to end, retains inbound reachability, and appears to the host stack as ordinary IPv4 configuration. A host that needs only outbound access to IPv4 services is well served by CLAT; a host that is itself an IPv4 service endpoint, or that runs software requiring a real IPv4 address, is not.¶

The two interact cleanly. A CLAT function SHOULD be disabled when native IPv4 connectivity is available [I-D.ietf-v6ops-claton], and this mechanism supplies exactly that native connectivity through ordinary DHCPv4. The existing trigger therefore applies with no modification.¶

The per-host address need not be globally unique. On client segments, a /32 drawn from [RFC1918] space with translation at the network edge works with this mechanism unchanged. What the host requires is a routable IPv4 identity on the segment, not a public one.¶

6.3. Access Provider Deployments

The common access-network case is a single public IPv4 address per subscriber, delivered over an IPv6-only access network. This mechanism addresses that case directly, and removes several costs usually treated as unavoidable.¶

No IPv4 space is carved per service area, because no segment carries an IPv4 prefix. No addresses are consumed by subnet and broadcast overhead, and none are stranded by a mismatch between a subnet's size and the number of subscribers actually attached to it. ARP is not present at MAC-domain scale. The pool is flat: any /32 may be assigned to any subscriber anywhere in the network, and reclaimed and reissued without regard to topology.¶

Per-subscriber service differentiation follows from the same property. One access segment can serve subscribers holding public IPv4, subscribers holding addresses from shared CGN space, and subscribers with no IPv4 at all, at the same time. The distinction lies entirely in what DHCPv4 provisioning returns, and nowhere in the configuration of the segment.¶

The model is not specific to one access technology. It applies to FTTH and DOCSIS, to enterprise and campus wireless, and to fixed wireless access over a mobile operator's IPv6-only transport, in each case as a per-subscriber /32 over IPv6-only infrastructure. An operator running several of these obtains a single IPv4 service architecture across all of them. Handsets remain a separate case, well served by 464XLAT [RFC6877].¶

6.4. Neighbor Discovery Prerequisites

Because IPv4 next-hop resolution now depends on Neighbor Discovery, this mechanism inherits ND's operational prerequisites. A fault in ND becomes an IPv4 fault as well as an IPv6 one.¶

Specifically: ICMPv6 must be permitted by host firewalls, for Neighbor Solicitation and Neighbor Advertisement as well as Router Solicitation and Router Advertisement; multicast must be delivered correctly across the segment, including by any MLD snooping in the path, so that solicited-node multicast reaches its target; and link-layer filtering must not discard frames addressed to solicited-node multicast groups.¶

None of these is a new requirement. Each is already a prerequisite for functioning IPv6 on the segment, and a segment on which they are not met does not have working IPv6 service. They are stated here because an operator whose IPv6 service is nominally working, but whose ND health has never been examined closely, may otherwise meet the dependency for the first time as an IPv4 symptom.¶

6.5. Intra-Segment Traffic

Because hosts carry /32 addresses, traffic between two hosts on the same segment is forwarded by the first-hop router rather than switched directly. The cost of this is topology-dependent, and is frequently overstated.¶

Where the first-hop router is the access switch itself, as in an L3 access design or a datacenter leaf, the forwarded path traverses the same physical links the switched path would have used, and is forwarded in hardware at line rate. The additional cost is a forwarding lookup, not additional wire. The case that does cost bandwidth twice is a router on a stick behind a shared L2 domain, where each intra-segment packet crosses the uplink once in each direction.¶

Guidance therefore follows the demand rather than the mechanism. On the segments this mechanism most obviously suits -- access and hosting segments, where lateral IPv4 between customers is suppressed by policy or simply absent -- the cost rounds to zero. On enterprise segments with an L3 access layer it is a forwarding lookup. A segment carrying heavy east-west IPv4 traffic behind a shared L2 domain, reached by a router on a stick, is the case that should not adopt this mechanism first: such a segment is better left dual-stack, or moved to IPv6 for its east-west traffic before the IPv4 first hop is converted.¶

6.6. Layer 2 Integrity Features

DHCP snooping, Dynamic ARP Inspection and IP Source Guard were specified against an assumption of a shared subnet with on-link bindings. Their behaviour with an off-subnet gateway and /32 leases needs to be validated per platform before deployment.¶

The expected analysis is favourable. The first-hop router sits on a trusted port, so its ARP reply for the sentinel is not subject to inspection and passes unchanged. An unmodified host's ARP request validates against that host's own sender binding, which the DHCPv4 /32 lease supplies in the usual way. IP Source Guard sees the leased address and permits it. None of this depends on the gateway being a member of the host's subnet.¶

The residue is where attention is warranted. A first-hop router on an untrusted port needs a static permit for the sentinel. Platforms vary in whether inspection examines the ARP target address as well as the sender, and in how gratuitous ARP is treated. Some platforms carry binding machinery beyond these three features, with its own subnet assumptions. Where a static permit is required, a single universal entry suffices for an entire deployment, because the sentinel holds the same value on every segment.¶

This apparatus becomes unnecessary for IPv4 as migration completes. Once no unmodified hosts remain and the router's ARP responder has been retired, there is no ARP on the segment to inspect, and host impersonation is an ND concern met by ND-specific protections (see Section 7).¶

6.7. Multiple Gateways and Redundancy

Because the sentinel is resolved from the neighbor cache and never by election, any number of routers on a segment may present it at the same time, with no coordination between them and no shared virtual address. Each updated host resolves the sentinel to whichever IPv6 default router it has itself selected. The requirement on the routers reduces to holding distinct IPv6 identities, which they must do in any case. The effect is anycast-like, though this is not anycast in the technical sense: one value, many holders, and selection made independently by each host.¶

That holds for the updated tier. Unmodified hosts still ARP for the sentinel, and where more than one router answers, the last reply received wins. The resulting nondeterminism is benign, since every answering router is a valid first hop, but it is nondeterminism nonetheless; an operator who wants a determinate answer for the ARP tier can run a conventional FHRP in front of it. That choice affects unmodified hosts only.¶

Every router a host may select MUST be able to forward that host's IPv4 traffic, and MUST have a return path for it per [RFC8950]. Where some routers on a segment qualify and others do not, operators MUST steer host selection with Default Router Preference [RFC4191]. On segments where several routers advertise equal preference, as is common in datacenter ECMP fabrics, hosts may select inconsistently according to RA timing; operators SHOULD set preferences explicitly wherever a deterministic outcome is wanted.¶

Return traffic needs no additional machinery. Where route origination is configured correctly, every router on the segment originates a route to each host /32, and inbound traffic is distributed active-active by ordinary ECMP. The two directions heal independently: the downstream path converges at the pace of the routing protocol, and the upstream path at the pace of RA processing and Neighbor Unreachability Detection on the host. Operators running stateful functions on segment routers inherit the usual consequences of ECMP path asymmetry, and should apply the same measures they would in any other ECMP deployment.¶

No failover MAC address is involved. An updated host elects nothing and inherits nothing; it follows its own IPv6 default router selection, and a change of router is a change of link-layer destination like any other. An unmodified host either accepts the timing of its ARP cache expiring and re-resolving, or sits behind a conventional FHRP as above.¶

More generally, the two things a first-hop redundancy protocol is usually asked for are a gateway address that survives a change of owner and a floating service address that does the same. Both are the same requirement: an address that must appear on-link while the device holding it may change. This model meets the first by removing the address from the link altogether, and the second by route origination, where the address is originated by whichever member currently owns it, and originated conditionally by the active member for stateful pairs.¶

6.8. First-Hop Failover Pacing

IPv4 first-hop failover under this mechanism is paced entirely by IPv6 default router selection. There is no IPv4-specific detection mechanism and no IPv4-specific latency: whatever a host's IPv6 first-hop failover behaviour is on a segment, its IPv4 behaviour is now the same.¶

For a planned decommission, the departing router sends a final Router Advertisement with a Router Lifetime of zero ([RFC4861], Section 6.2.5). Hosts remove it from the default router list on receipt and select another immediately, so a planned failover need not involve detection at all. Operators SHOULD ensure this advertisement is sent by any procedure that stops an RA daemon or removes a router from service; where it is omitted, a planned change degrades into the unplanned case.¶

For an unplanned failure, detection is by Neighbor Unreachability Detection, which is traffic-driven. A host with active flows through the failed router moves the neighbor entry through DELAY and PROBE to FAILED and selects another router within single-digit seconds, comparable to a conventional FHRP in its default configuration. A host with nothing in flight detects nothing, by design, and drops the router when its advertised lifetime expires; the next packet it sends drives resolution. Where sub-second failover is required it is engineered rather than assumed, exactly as with a conventional FHRP, by pairing the first hop with a liveness mechanism such as BFD or by shortening RA intervals.¶

Two further notes. On platforms where the IPv4 and IPv6 stacks are separate, the IPv4 path inherits whatever the operating system's NUD implementation concludes, so failover timing is a property of that stack rather than of this document. And DHCPv4 lease renewal or release does not affect next-hop selection: the lease governs the host's address and the configured gateway value, while resolution of that value is driven solely by Neighbor Discovery.¶

6.9. Return Path Provisioning

Section 5.2 requires that a first-hop router be able to deliver to each host /32 for the lifetime of the assignment. The mechanisms are outside the scope of this document, but one practical point is worth recording.¶

Lease-triggered origination is existing practice rather than a new invention. Where the first-hop router is the DHCPv4 relay, or observes relayed traffic, it already holds the lease binding; together with the host's link-layer address from Neighbor Discovery, that is sufficient to originate the [RFC8950] route for the host's /32 when the lease is granted and to withdraw it when the lease ends. Broadband network gateways originate subscriber routes on exactly this basis today. This is an illustration only: route origination belongs to [RFC8950] and [I-D.ietf-intarea-v4-via-v6], and nothing in this document constrains how it is done.¶

The choice of IPv6 next-hop identity for those routes deserves care. An IPv6 link-local address is not a stable identifier for a host under current address-generation practice. An implementation that moves from an interface-identifier-derived address to a semantically opaque one [RFC7217] may do so during interface bring-up, in the middle of the DHCPv4 exchange, so a return route keyed to the first link-local address observed can be stale before the host has finished configuring.¶

Operators SHOULD therefore key return routes to a stable next-hop identity wherever one is available: a global address the provisioning system already knows, an address anchored to a delegated prefix, or a binding derived from ND snooping or a source address validation mechanism [RFC7513], using the link-local address only as a fallback. Where only link-local addresses are available, origination has to track changes of identity through Neighbor Discovery rather than assume that the first address seen persists. Where a global address is used, it MUST be a stable one: temporary addresses [RFC8981] are designed to rotate and are unsuitable as a next-hop identity.¶

6.10. DHCPv4 Relay Considerations

A relay agent's interface toward the segment needs no IPv4 address, since the segment carries no IPv4 prefix. The relay does need a routable IPv4 address for the giaddr field, but that address need not be on the segment: one loopback address per relaying router is sufficient, whatever the number of segments it relays for.¶

Where giaddr would otherwise be conflated with address pool selection, the two are decoupled by the link selection sub-option [RFC3527]. In practice the need for this is reduced, because flat /32 pools largely dissolve the question of which pool serves which segment. Where segment identity is still wanted for policy or accounting, it is carried by the relay agent information option circuit identifier [RFC3046].¶

Relay agents that enforce on-link gateway validation may reject or flag IPV4-SENTINEL as an invalid Router Option value. Operators SHOULD verify relay agent behaviour in their deployment before relying on this mechanism.¶

ICMPv4 messages sourced by a first-hop router on the segment use the sentinel and are interface-local (see Section 5.3). ICMPv4 generated further along the path, by IPv6-only transit routers with no interface-local sentinel to use, is a separate problem addressed by [RFC7600], which allocates 192.0.0.8/32 for that purpose.¶

6.11. Host Implementation Considerations

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.¶

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 consequence for inspection policy is a simplification. On a segment where this mechanism is deployed, the first-hop router is the only legitimate ARP responder, and the sentinel is the only address it answers for. ARP inspection therefore reduces to permitting ARP replies from router ports and denying them everywhere else. Expressing that policy requires no snooping database and no per-host binding table, because the policy does not refer to host addresses at all.¶

Host impersonation is not eliminated by this; it moves. With ARP gone, an attacker seeking to divert traffic must attack Neighbor Discovery, where RA Guard [RFC6105] and ND inspection already apply. The segment is then defended by one protection stack covering one resolution protocol, instead of parallel stacks for ARP and ND that have to be configured and kept consistent separately.¶

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 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 [RFC3927]. A host configured with IPV4-SENTINEL as its gateway and a link-local IPv4 source address will follow the same resolution logic defined in Section 4.¶

7.2. First-Hop Redundancy Protocol Attack Surface

Because any number of routers may present the sentinel without coordination (see Section 6.7), a first-hop redundancy protocol is not required for the updated tier. Where one is consequently no longer run, its attack surface goes with it. VRRP and HSRP advertisement spoofing, election manipulation, and the traffic diversion or denial of service that follow from them are not merely mitigated on such a segment: they cease to be possible, because no election takes place.¶

This benefit is contingent on actually retiring the protocol. An operator who keeps a conventional FHRP in front of the unmodified-host tier (see Section 5.4) keeps its attack surface for as long as it runs.¶

7.3. Universal Gateway Address

A consequence of the IANA allocation and the ARP behavior defined in Section 5.4 is that IPV4-SENTINEL 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 IPV4-SENTINEL, 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 IPV4-SENTINEL 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 IPV4-SENTINEL MUST NOT appear as source or destination in any forwarded packet per Section 5.3, conformant deployments render it unreachable from any device not on the local segment. This eliminates it as a target for off-link attacks, and by the same prohibition prevents its use as a spoofed source address from off-link: a conformant router forwards no packet carrying it in either field, so such a packet cannot cross the first hop in either direction.¶

These off-link properties rest on that forwarding prohibition alone. They do not derive from the Source field of the registry entry, which records Source=True (see Section 9). Source=True is correct, because a first-hop router does legitimately originate interface-local ICMPv4 messages with IPV4-SENTINEL as the source address, as described in Section 5.3. What confines the address to the segment is that no such message is ever forwarded.¶

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. IPV4-SENTINEL provides the same property for IPv4.¶

10.1. Normative References

[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

[CALICO-FAQ]

Project Calico, "Calico Documentation: Frequently Asked Questions", 2026, <https://docs.tigera.io/calico/latest/reference/faq>.

[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-10, 10 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-6mops-10>.

[I-D.ietf-v6ops-claton]

Colitti, L., Linkova, J., and T. Jensen, "464XLAT Customer-side Translator (CLAT): Node Behavior and 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>.

[RFC925]

Postel, J., "Multi-LAN address resolution", RFC 925, DOI 10.17487/RFC925, October 1984, <https://www.rfc-editor.org/rfc/rfc925>.

[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>.

[RFC1918]

Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/rfc/rfc1918>.

[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>.

[RFC2516]

Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February 1999, <https://www.rfc-editor.org/rfc/rfc2516>.

[RFC3046]

Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, DOI 10.17487/RFC3046, January 2001, <https://www.rfc-editor.org/rfc/rfc3046>.

[RFC3442]

Lemon, T., Cheshire, S., and B. Volz, "The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4", RFC 3442, DOI 10.17487/RFC3442, December 2002, <https://www.rfc-editor.org/rfc/rfc3442>.

[RFC3527]

Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, "Link Selection sub-option for the Relay Agent Information Option for DHCPv4", RFC 3527, DOI 10.17487/RFC3527, April 2003, <https://www.rfc-editor.org/rfc/rfc3527>.

[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>.

[RFC6877]

Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <https://www.rfc-editor.org/rfc/rfc6877>.

[RFC7217]

Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <https://www.rfc-editor.org/rfc/rfc7217>.

[RFC7513]

Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address Validation Improvement (SAVI) Solution for DHCP", RFC 7513, DOI 10.17487/RFC7513, May 2015, <https://www.rfc-editor.org/rfc/rfc7513>.

[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>.

[RFC8585]

Palet Martinez, J., Liu, H. M.-H., and M. Kawashima, "Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May 2019, <https://www.rfc-editor.org/rfc/rfc8585>.

[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>.

[RFC8981]

Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, <https://www.rfc-editor.org/rfc/rfc8981>.