Closing the IPv6 first-packet gap with GRAND
m_montazeri
26 points
20 comments
September 15, 2026
Related Discussions
Found 5 related stories in 65.7ms across 6,718 title embeddings via pgvector HNSW
- A Farewell to ARPs: IPv4 Service on IPv6-Only Networks speckx · 46 pts · July 13, 2026 · 58% similar
- Show HN: We Implemented the IPv8 Internet-Draft in Linux, Libc, and BGP turborigby · 69 pts · August 14, 2026 · 52% similar
- GitHub Publishes IPv6 Addresses for Git SSH remotes tonymet · 33 pts · August 26, 2026 · 44% similar
- Reimplementing pf as an eBPF/XDP dataplane on Linux 882542F3884314B · 15 pts · July 11, 2026 · 43% similar
- GPT 5.6 Cyber gizmodo59 · 100 pts · August 10, 2026 · 42% similar
Discussion Highlights (3 comments)
mort96
Wait I don't get this. If I understand correctly, traditional IPv6 flow is: * A host configures its own IP address via SLAAC * The host sends a packet to its gateway with some destination address * The gateway forwards the packet to the Internet * Eventually, a response packet arrives to the gateway * At this point, the gateway does neighbour discovery to try to figure out how to send the packet to the host * The gateway might drop the packet or delay forwarding it until neighbour discovery completes Why couldn't we change the flow to: * A host configures its own IP address via SLAAC * The host sends a packet to its gateway with some destination address * The gateway forward the packet, and at the same time starts neighbour discovery because almost all computers which send outgoing packets will eventually receive some incoming packet * When the response packet arrives, neighbour discovery is likely already done, or if not it got a good head start Isn't this the obvious solution which wouldn't require changes to hosts or new protocols, just a small tweak to the router? Usually, when there's a seemingly obvious simple solution to a real problem and that solution hasn't been implemented by any of the clever people working in networking standards, there's a good reason and the solution isn't as simple as it seems. So what am I missing?
basilikum
Interesting topic. Started reading, the text is dreadfully lengthy, hard to stay concentrate on due to all the filler and mindlessly arranged words that obscure the actual content, notice AI tell signs. Stop reading, paste into Pangram, mostly AI, scroll down on the text, find this: > Note: The author used AI tools to assist with drafting and language. The technical work, analysis and conclusions are the author’s own. For more information about our policy on AI-generated content, see our Contributing to RIPE Labs page. Do better RIPE. I assumed RIPE had some standard. If you decide to not have any standards, at the very least put the AI disclaimer at the top so I don't waste my time on slop. It's disrespectful. Does anyone have an article about NDP and GRAND that is not slop and worth sharing and reading?
happyPersonR
it's interesting to watch all of this having dealt recently with behvaior in an environment that expected 1) SLAAC/static ip 2) multiple default gateways, and then you import routes(including multiple default gateway's) over bgp and start BFD to figure out which one is active 3) and then you start broadcasting your own address over bgp i wish there were a daemon in systemd, that i could configure to do this. It seems absurd to people that aren't aware of how it works, but it's quite the interesting flow in a datacenter. wish there were an equivalent in the kubernetes/normal linux world, but i can understand the scalability concerns :) I know BIRD exists, but i wish this was kind of built in ... lemme see if systemd supports extensions... it would be cool to add :) i'm sure more people might want it.