Gute Argumente gegen die anlasslose #Vorratsdatenspeicherung für IP-Adressen und Portnummern durch Anbieter von Internetzugangsdiensten https://ffmuc.net/politik/freifunk/gesetzgebung/2026/02/11/stellungnahme-referentenentwurf-ip-adressspeicherung/
@paulehoffman @b0rk @spamvictim @andy
2) Limited Public #IPv4 address space forces most organizations into CGNAT. This has lots of challenges (shared IP reputation, scaling/reliability/perf issues, etc). Those NATs can be fairly costly to operate as well. This also makes troubleshooting hard (eg, if a compromised or broken client is behind a NAT, it can be hard to chase the problem down and it can have impact to all of the other users behind that IP).
(Viet Nam has actually been making some great progress with their #Ipv6 transition and unlike some countries just talking about it, they seem to be following through so far: https://blog.apnic.net/2025/08/27/modernizing-viet-nams-internet-infrastructure-security-action/ )
@paulehoffman @b0rk @spamvictim @andy
There are many angles here, so I'll provide one or two.
1) Having a large amount of IPv4 space made address planning and structured addresses easy. For example, MIT used to split up 18.0.0.0/8 in a structured manner -- for example buildings often got a /16. My undergrad dorm didn't *need* 64k IPv4 addresses, but being able to look at the second octet to know where it was turned out to be super convenient.
This is actually one of the huge benefits of IPv6, especially when people treat it as its own things rather than just as "bigger IPv4". If you get you address plan right then you can have structured addresses. As a large scale operator this turns out to be super convenient.
For example, if an organization has a /32 then they can slice this up in various ways. For example:
* Have a /48 per site, and then have common structure within each site.
* Have a /36 per function (prod servers, lab/QA, clients, etc) then have a /48 per site within that.
That sort of structure makes IPv6 addresses actually easier to work with than IPv4 -- it's not like anyone managing a network with hundreds of thousands of nodes is typing IP addresses by hand or memorizing them.
While structured addressing sometimes happens in RFC1918 space (eg, for K8s clusters in net-10), it is much easier to run out of space in IPv4 this way in ways that get you stuck, especially if you ever need to connect multiple environments together. While 24M addresses in 10.0.0.0/8 sounds like a lot, it turns out to be not big enough for structured addressing in large compute environments, or even for unstructured addressing for large ISPs with many tens of millions of subscribers.
@paulehoffman @b0rk @spamvictim @andy
2) Limited Public #IPv4 address space forces most organizations into CGNAT. This has lots of challenges (shared IP reputation, scaling/reliability/perf issues, etc). Those NATs can be fairly costly to operate as well. This also makes troubleshooting hard (eg, if a compromised or broken client is behind a NAT, it can be hard to chase the problem down and it can have impact to all of the other users behind that IP).
(Viet Nam has actually been making some great progress with their #Ipv6 transition and unlike some countries just talking about it, they seem to be following through so far: https://blog.apnic.net/2025/08/27/modernizing-viet-nams-internet-infrastructure-security-action/ )
@b0rk You are totally hitting the ball out of the park today with "Excellent questions that will draw out uninformed opinions from people who wish they were experts in this area but can type like them". (I say this as someone whose response to questions about IP addresses is "ask my friends like @spamvictim, @andy, @nygren or anyone who has been in the RIPE community for >20 years.)
@paulehoffman @b0rk @spamvictim @andy
There are many angles here, so I'll provide one or two.
1) Having a large amount of IPv4 space made address planning and structured addresses easy. For example, MIT used to split up 18.0.0.0/8 in a structured manner -- for example buildings often got a /16. My undergrad dorm didn't *need* 64k IPv4 addresses, but being able to look at the second octet to know where it was turned out to be super convenient.
This is actually one of the huge benefits of IPv6, especially when people treat it as its own things rather than just as "bigger IPv4". If you get you address plan right then you can have structured addresses. As a large scale operator this turns out to be super convenient.
For example, if an organization has a /32 then they can slice this up in various ways. For example:
* Have a /48 per site, and then have common structure within each site.
* Have a /36 per function (prod servers, lab/QA, clients, etc) then have a /48 per site within that.
That sort of structure makes IPv6 addresses actually easier to work with than IPv4 -- it's not like anyone managing a network with hundreds of thousands of nodes is typing IP addresses by hand or memorizing them.
While structured addressing sometimes happens in RFC1918 space (eg, for K8s clusters in net-10), it is much easier to run out of space in IPv4 this way in ways that get you stuck, especially if you ever need to connect multiple environments together. While 24M addresses in 10.0.0.0/8 sounds like a lot, it turns out to be not big enough for structured addressing in large compute environments, or even for unstructured addressing for large ISPs with many tens of millions of subscribers.
Geoff Huston has published an excellent report on the state of #IPv4 and #IPv6 through the course of 2025:
https://www.potaroo.net/ispcol/2026-01/addr2025.html
It is very much worth reading through if this is something you're involved in. It covers topics including where we've landed with IPv4-per-capita for various countries (and associated inequality) as well as how the IPv4 transfer market pricing has substantially softened over the course of 2025.
So looking for different #Mastondon #Fediverse software as the dependencies for #Akkoma are #IPv4 only. Looking at #Misskey but will take a bit to determine #IPv6 only capability. Any input from the crowd here? I don't want to host the Mastodon suite.
So looking for different #Mastondon #Fediverse software as the dependencies for #Akkoma are #IPv4 only. Looking at #Misskey but will take a bit to determine #IPv6 only capability. Any input from the crowd here? I don't want to host the Mastodon suite.
Take the time to read {again} how Stephan has built a self hosted CDN using OpenSource programming and tools.
He literally shares the code. From what I processed, this method can scale up quite easily. You can build a super large CDN yourself using similar modus operandi.
No corporate CDN, but the insight, resilience and technical expertise of a great programmer, with the Passion and Curiosity of someone visionary.
All powered by OpenSource BSD IPv6 jails DNS caching and enthusiasm
Thank you Stephan
#CDN #networking #cache #IPv6 #IPv4 #programming #technology #BSD #freeBSD #jails #DNS #Wireshark
https://it-notes.dragas.net/2024/08/26/building-a-self-hosted-cdn-for-bsd-cafe-media/
Take the time to read {again} how Stephan has built a self hosted CDN using OpenSource programming and tools.
He literally shares the code. From what I processed, this method can scale up quite easily. You can build a super large CDN yourself using similar modus operandi.
No corporate CDN, but the insight, resilience and technical expertise of a great programmer, with the Passion and Curiosity of someone visionary.
All powered by OpenSource BSD IPv6 jails DNS caching and enthusiasm
Thank you Stephan
#CDN #networking #cache #IPv6 #IPv4 #programming #technology #BSD #freeBSD #jails #DNS #Wireshark
https://it-notes.dragas.net/2024/08/26/building-a-self-hosted-cdn-for-bsd-cafe-media/
The Internet needs to move over (from IPv4) to IPv6.
If for nothing else, to make it easier to get a static IP address.
(Although there are some other nice features of IPv6.)
(I remember people talking about IPv6 back in the mid- to late 1990s — and more than 3 decades later, the IPv4 to IPv6 switch over is still in progress.)
Made my FreeBSD server at Netcup ready to host multiple isolated applications with automatic https via Let's Encrypt.
Internet → Server → PF firewall → Caddy jail (reverse proxy) → Individual application jails
Each app gets its own isolated jail for security, while Caddy handles all the routing and https. PF keeps the front door locked.
All of course with IPv6 first, where every Jail has it's own public IP address and using NAT for legacy IPv4.
Love how FreeBSD jails make this kind of segmentation so elegant.
Made my FreeBSD server at Netcup ready to host multiple isolated applications with automatic https via Let's Encrypt.
Internet → Server → PF firewall → Caddy jail (reverse proxy) → Individual application jails
Each app gets its own isolated jail for security, while Caddy handles all the routing and https. PF keeps the front door locked.
All of course with IPv6 first, where every Jail has it's own public IP address and using NAT for legacy IPv4.
Love how FreeBSD jails make this kind of segmentation so elegant.
On va commencer. Mot-croisillon #CIS2025
If, like me, you've ever been annoyed at people just saying to grep the output of ifconfig for inet, and the likes, to get the assigned IP address of a network interface.
I got annoyed one time too many.
Have a proper solution.
May or may not also work on for example the *BSDs, but should definitely work on any modern typical-userland Linux.
https://michael.kjorling.se/blog/2025/ip-address-of-network-interface-linux/
#Linux#BlogPost #blog#PersonalWebSite #indieweb #networking#IPv4#IPv6
If, like me, you've ever been annoyed at people just saying to grep the output of ifconfig for inet, and the likes, to get the assigned IP address of a network interface.
I got annoyed one time too many.
Have a proper solution.
May or may not also work on for example the *BSDs, but should definitely work on any modern typical-userland Linux.
https://michael.kjorling.se/blog/2025/ip-address-of-network-interface-linux/
#Linux#BlogPost #blog#PersonalWebSite #indieweb #networking#IPv4#IPv6
Yes, The Book of PF, 4th Edition Is Coming Soon https://nxdomain.no/~peter/yes_the_book_of_pf_4th_ed_is_coming.html
Long rumored and eagerly anticipated by some, the fourth edition of The Book of PF is now available for preorder https://nostarch.com/book-of-pf-4th-edition #openbsd #pf #packetfilter #freebsd #networking #security #tcpip #ipv6 #ipv4#bookofpf
Yes, The Book of PF, 4th Edition Is Coming Soon https://nxdomain.no/~peter/yes_the_book_of_pf_4th_ed_is_coming.html
Long rumored and eagerly anticipated by some, the fourth edition of The Book of PF is now available for preorder https://nostarch.com/book-of-pf-4th-edition #openbsd #pf #packetfilter #freebsd #networking #security #tcpip #ipv6 #ipv4#bookofpf
📉 IPv4 exhaustion is real. So how are networks coping?
Our latest IP report dives into the rise of IPv4 transfers, trends in pricing and availability, and what it all means for the Internet’s future.
🔗 Read the full report: https://labs.ripe.net/media/documents/The_State_of_IPv4_Report.pdf
Do you think IPv4 transfers have become a crucial lifeline in the wake of address space exhaustion?