IdeaWell

Project ideas from Hacker News discussions.

RFC8950: Announce IPv4 with an IPv6 next-hop

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

Theme 1 – RFC 8950 lets networks run an IPv6‑first core while still transporting IPv4 traffic
- Alifatisk: “I guess the point with this to facilitate usage of IPv6.”
- Sesse__: “More like, the point is to facilitate turning off IPv4.”
- throw0101c (referencing RFC 8950 §6): “IPv4 over IPv6 Core, IPv4 VPN Unicast over IPv6 Core, IPv4 VPN Multicast over IPv6 Core.”

Theme 2 – Ongoing criticism of IPv6’s complexity, privacy issues, and design flaws
- asdfsa32: “IPv6 is a stain in the history of computer science … a privacy nightmare without privacy extensions … scope creep … we got a monster that keeps growing.”
- cyberax: “There's EVERYTHING wrong with IPv6 … extension headers, wtf … IPv6 with extension headers are just dropped by routers in the public Internet.”

Theme 3 – Real‑world IPv6‑only or IPv6‑first deployments using transition mechanisms
- boredatoms: “Running a IPv6-only network that doesn’t interact with IPv4 networks in any way is great and it works.”
- miyuru: “Multiple ISPs in my country have already deployed IPv6 with NAT64 support, and with CLAT support now available, I think IPv6-only networks will be the next step for most ISPs.”
- yayachiken: “Modern operating systems will gladly do CLAT, and old operating systems … can still get their IPv4 by just ignoring the new DHCPv4 option. But admins can finally stop keeping an IPv4 around for every potential client.”

🚀 Project Ideas

IPv6‑Only Network Sandbox as a Service

Summary

  • A hosted, on‑demand lab that lets engineers spin up IPv6‑only backbones with NAT64, CLAT, BGP IPv4‑over‑IPv6 (RFC 8950) and test transition scenarios without touching production gear.
  • Core value: reduces the friction of IPv6 deployment by providing a safe, reproducible environment to validate configurations and troubleshoot real‑world pain points (prefix withdrawal, ULA/GUA clashes, extension‑header drops).

Details

Key Value
Target Audience Network engineers, ISP planners, DevOps teams evaluating IPv6‑only designs
Core Feature One‑click deployment of configurable IPv6 core (FRR/BGP), NAT64 (Tayga), CLAT simulator, and monitoring stack (Prometheus/Grafana)
Tech Stack Linux KVM/Firecracker VMs, Docker‑Compose, FRR, Tayga, CoreDNS, Go‑based control plane, Terraform for provisioning
Difficulty Medium
Monetization Revenue-ready: tiered subscription (Free trial → $29/mo per concurrent lab)

Notes

  • Commenters noted the hassle of “mixing/transitioning” and the desire for a clean testbed: “Running a IPv6-only network that doesn’t interact with IPv4 networks in any way is great and it works.” – boredatoms
  • Provides a concrete way to experiment with the mechanisms discussed (NAT64, CLAT, BGP IPv4‑over‑IPv6) and validate draft fixes for ULA/GUA prefix withdrawal issues raised by cyberax.

BGP IPv4‑over‑IPv6 Config Generator & Validator

Summary

  • CLI/GUI tool that creates and validates BGP configurations where IPv4 prefixes are advertised with IPv6 next hops (RFC 8950) for vendors like FRR, Bird, Cisco/Juniper.
  • Core value: eliminates manual errors and speeds up adoption of IPv6‑only cores that still need to carry IPv4 traffic, directly addressing the pain point of “ ISPs who run a native IPv6 backbone and want to exchange and route IPv4 traffic without setting up IPv4 addressing.” – q3k

Details

Key Value
Target Audience ISP network operators, enterprise network architects using BGP
Core Feature Input IPv4 prefixes + IPv6 peer → generates valid BGP config, simulates route propagation, checks for loops, missing next‑hop reachability, and prefix‑withdrawal scenarios
Tech Stack Go (primary), gobgp library for BGP semantics, Cobra CLI, optional Electron GUI, JSON schema for validation
Difficulty Medium-High
Monetization Revenue-ready: per‑node license $99/yr or hosted SaaS $19/mo for API access

Notes

  • The discussion highlighted the utility of MP‑BGP‑style setups: “That's basically MP‑BGP! Your dream is real.” – q3k
  • A validator would give confidence to engineers wary of extension‑header drops and prefix withdrawal, echoing cyberax’s concerns about stale GUAs vs. ULAs.

ULA/GUA Prefix‑Watcher & DNS Sync Daemon

Summary

  • Lightweight daemon that monitors DHCPv6 Prefix Delegation (PD) changes on a router, preserves a stable ULA for local services, and automatically updates local DNS (CoreDNS/dnsmasq) and /etc/hosts when the GUA prefix changes or is withdrawn.
  • Core value: solves the “when the router withdraws the prefix, your host still has a stale GUA while the printer only has a ULA” problem described by cyberax, enabling reliable IPv6‑only operation for IoT, printers, and internal apps without manual reconfiguration.

Details

Key Value
Target Audience Home/small‑office network admins, IPv6‑enthusiasts, ISP CPE firmware developers
Core Feature Netlink listener for PD events, ULA address maintenance, DNS sync (via RFC2136 updates or file rewrite), health‑check API
Tech Stack Go (systemd service), Linux netlink, CoreDNS plugin or dnsmasq wrapper, optional Prometheus metrics
Difficulty Low-Medium
Monetization Hobby (open‑source) – can be offered as paid firmware add‑on or support contract if desired

Notes

  • Directly addresses cyberax’s example: “If you have a GUA and a ULA… the host is going to prefer the GUA… So when a router withdraws a prefix… your printing is broken.”
  • Provides practical utility for users who want to “remove some IPv4 linknets from my IS‑IS… and just route using IPv6 link-local nexthops” – Sesse__, by ensuring internal services stay reachable despite prefix flux.

Read Later