Based in The Netherlands
Articles
Likes on articles
Technology executive with a passion for Internet and how the pieces come together - going down that rabbit hole for 25+ years. Prolific policy author, former chair of the Connect working group in the RIPE community and board member of RIPE NCC from 2010 to 2025.
• 9 min read
IPv6-only networks often still depend on IPv4 subnets and ARP. This article introduces an IETF proposal to eliminate both, allowing IPv4 to operate as a service over IPv6-only infrastructure without translation or tunnelling.
• 5 min read
Now that we have begun the process of reviewing the RIPE Compact, it’s time for the community to share its thoughts on the nature of the challenges facing the RIPE NCC and what its mission should be.
• 12 min read
The RIPE NCC’s mission to support a free, open and global Internet is becoming increasingly demanding. This is raising costs at a time when there is less agreement on how they should be distributed. We need to agree on a roadmap for the decades ahead so the RIPE NCC remains stable and fit for the m…
Showing 3 article(s)
“RFC 9663 was authored by Google, and Google has published a post describing an Android implementation of a DHCPv6 client based on this approach: https://android-developers.googleblog.com/2025/09/simplifying-advanced-networking-with.html?m=1. There are also implementations available for Linux. Moreover, the following statement leaves the issue of how the network learns the return path unresolved. Therefore, it cannot be considered a complete solution to the problem. In contrast, the new DHCPv6 Prefix Delegation option conveys this information to the network natively: DRAFT text: 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.”
Hi Roman, Thanks for the pointer: as of September, Android ships a DHCPv6 client, for Prefix Delegation specifically (still no IA_NA; the post is explicit about why). What the post also does is date-stamp the deployment argument better than I ever could. DHCPv6-PD was standardised in RFC 3633 in December 2003; the first Android client arrived in 2025, twenty-two years later. A new DHCPv6 option carrying IPv4 semantics starts that clock again: today's PD clients, including Android's new one, wouldn't parse it, so every DHCPv6 client needs another update, and this time the entire IPv4 provisioning ecosystem needs to learn DHCPv6 as well. The sentinel needs none of that, which is the whole design. On the return path: it isn't in the draft because it isn't what was missing. RFC 8950 and v4-via-v6 already carry IPv4 routes with IPv6 next-hops through the routing infrastructure, and originating them from subscriber state is existing practice under both: the first-hop router is, or snoops, the DHCPv4 relay, lease state gives it the /32-to-interface binding, ND gives it the client's link-local, and it originates the route the way BNGs install subscriber routes today, tens of millions of times over. This draft deliberately covers the one thing that had no standard: the host's first hop. Note also that PD has the same second half: the delegated prefix is natively known at the delegating router, but beyond it the route is redistributed like any other. Both models reduce to the first hop learning a binding from DHCP state. Completeness is a property of the stack, and the stack is 8950 plus v4-via-v6 plus this. Worth adding: RFC 9663 and this draft are fighting the same war, per-device accountability and state that scales in large broadcast domains, just in different address families. I don't read them as competitors. You're clearly reading the draft closely, and this is exactly the kind of review it needs. The right places for it are the GitHub repo (github.com/remcovanmook/draft-ipv6-resolved-gateway) or the int-area list, where the adoption discussion will happen after Vienna. I'd genuinely welcome your comments there. Remco
“My five cents: Router ID: A Router ID is a 32-bit identifier conventionally represented in IPv4 dotted-decimal notation; it is not necessarily an IPv4 address assigned to an interface. It cannot be used as an ICMPv4 source address unless it is configured as an address—for example, on a loopback interface—and the router is configured to use it for ICMPv4 messages. Forwarding: The fast path normally does not query ARP/ND tables for every packet. ARP/ND resolves a neighbor and installs an adjacency/rewrite entry; the forwarding plane then uses FIB and adjacency entries, typically programmed in hardware/forwarding cache. DHCPv4 relay: How can an IPv4-unaddressed router interface relay DHCPv4? What value is used for giaddr, and how does the DHCP server select the correct client subnet or address pool? DHCPv4 service: If DHCPv4 relay is not possible, does this model require a local DHCPv4 server on the first-hop router? Rather than introducing a new provisioning mechanism and adding workarounds to DHCPv4, could DHCPv6 Prefix Delegation be extended to delegate an IPv4 prefix to a VM or bare-metal server? The delegated IPv4 prefix could then be routed via the client’s IPv6 link-local address. RFC 9663 already describes per-client IPv6 prefix delegation in large broadcast networks. A similar model for IPv4 prefixes might provide a cleaner provisioning approach, although it would require new DHCPv6 options and clearly defined IPv4-specific semantics.”
Hi Roman, Good points, all five. In order: Router ID: agreed, it's a 32-bit identifier and nothing more. The concern underneath, where router-originated ICMPv4 comes from on an unaddressed router, has two answers. On-link, the draft has the first-hop router source ICMP from 192.0.0.11 itself (section 5.2). For transit routers deeper in an IPv6-only core, that's v4-via-v6 territory, and the registry already holds the answer: 192.0.0.8, the IPv4 dummy address from RFC 7600, registered precisely as a placeholder source for routers with no IPv4 address of their own. It sits three doors down from the address this draft requests. Forwarding: exactly right, and it's how the mechanism works. Resolution binds when the adjacency is installed, not per packet. The IPv4 route's rewrite comes from the same adjacency object the IPv6 entry uses; NUD maintains it; nothing consults the ND table in the forwarding path. This is why RFC 8950 deployments needed no silicon changes, and it's arguably a simplification: one adjacency table serving two FIBs. Relay and giaddr: the relaying interface needs no address, giaddr needs a routable IPv4 address, and one loopback per relay router is enough. Where per-segment distinction matters, RFC 3527's link-selection sub-option decouples giaddr as return address from pool selection. But note that in this model the pool-selection problem largely dissolves: there are no per-segment subnets, so any /32 from the pool works anywhere, with Option 82 circuit-id carrying segment identity where policy wants it. A local DHCPv4 server on the first hop works too, but nothing requires it. On DHCPv6-PD for IPv4: it's a reasonable design, and the family exists (RFC 7341 does DHCPv4 transport over DHCPv6). Two things stop it in practice. New DHCPv6 options mean updating every DHCPv6 client and teaching the entire IPv4 provisioning ecosystem to speak DHCPv6, which puts you a decade out before meaningful coverage. And the largest host population there is, Android, has no DHCPv6 client at all, by explicit design choice. The sentinel works with every DHCPv4 client, server and relay that exists today, unchanged. That makes adoption before my retirement feasible. The relay/giaddr point deserves a sentence in the draft's deployment considerations; it'll go in the next revision. Remco
“fe80::1 is only "on the right subnet" because it's an interface-scoped address. When you reference it from an arbitrary host, potentially with multiple interfaces, you also specify the interface identifier in the address, e.g. fe80::1%eth0. We were able to implement interface identification in the IPv6 addressing model because it was a green-field protocol. We don't have that luxury in ipv4 which is at this stage the ultimate brown-field protocol. So, it's not accurate to say "192.0.0.11 gives IPv4 the same property", and it won't be accurate until "192.0.0.11%eth0" is generally accepted as an addressable destination in an arbitrary context in IPv4.”
Hi Nick, you are correct in pointing out that the analogy as written in the article is too much of a shortcut. fe80 gets its interface disambiguation from the addressing model itself, and that was a greenfield luxury. There will never be a 192.0.0.11%eth0. The mechanism doesn't need one though. The sentinel only appears in contexts that are already bound to an interface: the DHCPv4 lease arrives on an interface, the default route it produces is bound to that interface, and resolution happens there. It never appears in forwarded packets, so it's never an addressable destination in an arbitrary context, which is the ambiguity zone identifiers were invented to resolve. A multihomed host ends up with one interface-bound route per interface, much like its routing table already stores fe80 next-hops with an ifindex next to them. For diagnostics on a multihomed host, ping 192.0.0.11 follows the routing table and forcing an interface is ping -I or SO_BINDTODEVICE. Not pretty, but that's brownfield for you. The draft itself makes the narrower claim: topology independence, a value that works on any segment without carrying subnet membership information. The compression to "the same property" happened in this article, and that one's on me. Remco
Showing 3 comment(s)