Hello (IPv6) world!
This is my sub-account for #IPv6 and related things. My main account is @litchralee
He/him | Pronouns |
Hello (IPv6) world!
This is my sub-account for #IPv6 and related things. My main account is @litchralee
He/him | Pronouns |
@jima Minnesota and #IPv6 represent: https://openriver.winona.edu/rca/2025/schedule/92/
I wish we could see their code. I see lots of chatter about NAT64 and eBPF but I haven't yet found anything I can actually load.
IPv4 exhaustion has been a prevalent problem for years, as organizations and service providers have fought against the scarcity of IPv4 address space on the internet. NAT64 is increasingly deployed as a solution to this problem. As a result, it becomes increasingly important that the deployment of NAT64 technologies is easy and performant. Numerous implementations of NAT64 technologies already exist, and some new implementations use eBPF as well. In this research, we implemented a CLAT with an eBPF TC classifier and compared its performance to Jool, a widely used kernel module. We did this using a series of virtual machines on two networks, and a VyOS router. Using iperf3, we compared throughput in TCP and UDP and analyzed throughput and performance loss. Deployment is trivial – essentially loading the program to the appropriate interfaces – and the overhead is minimized because both approaches stay entirely within kernel space.
The #homeautomation protocol is named #Thread, perhaps that is a typo as #Threat is more apt and accurate. If you roll your own device you might very well experience the full force of their blood thirsty lawyers.
What the actual F.
I used to think Kubernetes was complex machinery solving scalability problems I would never have. I was wrong.
Kubernetes has less moving parts than my handmade deployments. It's sturdier than my hand written playbooks. It solves problems I already have.
https://ergaster.org/posts/2025/07/09-kubernetes-black-friday/
I self-host services mostly for myself. My threat model is particular: the highest threats I face are my own incompetence and hardware failures. To mitigate those risks used to rely on podman containers to "standardize" my services, and on ansible to automate the deployment on my VPS.
Some back-of-the-napkin math for those worried that we might still exhaust #IPv6 if we're not careful:
We are currently numbering out of 2000:/3, but effectively it's been 2000::/4 so far. The smallest amount of space that can be announced in BGP is a /48.
4 bits off the top and 16 bits off the bottom leaves us with 2^28 individual /48 networks we _could_ issue (obviously we're issuing larger chunks where possible, eg: /32 for many ISPs). This is representable without having to go to engineering notation: 268,435,456.
Last night's bgp.tools dump shows 117,731 active ASNs. We could issue every org with an ASN a starter /48 and still have several orders of magnitude worth of room for growth. And that's even before we get to 3000::/4.
So, don't worry about filling up the pool. Grab what you need (and maybe a bit more) and build the network you've been dreaming of.
I just got a microphone. Looking forward to reading some, to make free audiobooks for librivox.org.