RFC8950: Announce IPv4 with an IPv6 next-hop
porridgeraisin
102 points
63 comments
October 16, 2026
Related Discussions
Found 5 related stories in 102.7ms across 9,716 title embeddings via pgvector HNSW
- A Farewell to ARPs: IPv4 Service on IPv6-Only Networks speckx · 46 pts · July 13, 2026 · 55% similar
- Closing the IPv6 first-packet gap with GRAND m_montazeri · 26 pts · September 15, 2026 · 52% similar
- Show HN: We Implemented the IPv8 Internet-Draft in Linux, Libc, and BGP turborigby · 69 pts · August 14, 2026 · 49% similar
- GitHub Publishes IPv6 Addresses for Git SSH remotes tonymet · 33 pts · August 26, 2026 · 44% similar
- RFC 8890 – The Internet is for End Users (2020) notarobot123 · 121 pts · July 30, 2026 · 44% similar
Discussion Highlights (7 comments)
Alifatisk
I guess the point with this to facilitate usage of IPv6.
petecooper
https://www.rfc-editor.org/info/rfc8950/
asdfsa32
A few more RFCs, a few more IP over IP bandaid, a few more extensions, and we will get there. By God IPv6 is a stain in the history of computer science. IPv6 should have really just worked like NAT/IP over IP on IPv4 hardware and fast path on IPv6 hardware. But instead we got a monster that keeps growing with things like NAT64, 4over6, DS-Lite, MAP-E, and now BGP stopgaps and a growing https://en.wikipedia.org/wiki/List_of_IPv6_transition_mechan...
Isomer
I don't understand why you can't have any protocol that can (potentially recursively) resolve to a layer 2 address as a next hop. v4 route with v6 next hop? Seems reasonable. v6 route with v4 next hop? Why not? v4/v6 route with a mac address as a next hop? Trivial. v4/v6 route with a DNS next hop? Could be recursively resolved to a v4/v6 address, and then potentially recursively resolved to a MAC address. I wouldn't recommend it, but sure. v4/v6 route with a netbeui name as a next hop? You appear to be mad, but I'm not going to be the one to stand in your way.
gopalv
> They still do things the old way but Backbone can run IPv6 only at its core. This would turn an internal IPv4 into an externally routed IPv6, which is a neat trick which would replace all the NAT madness that we do run today. I'd like nothing more than the ability to run ipv4 internally indefinitely, especially with things like mesh networks where the ACLs are carried over from ages ago (2018 doesn't feel that long ago, but it is). Most of the time I don't even need a route to a direct connection, I just need legible flow logs out of a kubernetes platform.
imoverclocked
> R1 & R2 are IPv6 only with no IPv4 anywhere on their interfaces (but carry IPv4 routes in their table) … proceeds to traceroute with IPv4 addresses showing up for each router… It’s neat but still requires IPv4 to be configured on the router? What am I missing?
billpg
Shameless plug: https://billpg.com/sixgate/ (Short version: IPv6-only networks can provide a gateway for IPv4-only clients and advertise it via reverse DNS.) SixGate has an interesting contrast with this RFC. RFC8950 removes IPv4 from the network core while preserving IPv4 reachability, whereas SixGate removes IPv4 from the service side while preserving reachability for IPv4-only clients. In both cases, IPv4 survives as a compatibility layer rather than a fundamental requirement. The difference is that RFC8950 is aimed at network operators, while SixGate is aimed at the last remaining IPv4-only users. In both cases, the goal is the same. Turn IPv4 from a requirement into an optional compatibility feature.