On Tue, Feb 13, 2024 at 2:18 AM Jay R. Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Dave Taht" <dave.taht@gmail.com>
The angst around ipv6 on hackernews that this triggered was pretty revealing and worth thinking about independently. https://news.ycombinator.com/item?id=39316266
Thanks; the source where I got the other link mentioned that, and I meant to include it...
I was inspired to try a couple traceroutes. It used to be 240 escaped my prior comcast router and wandered around a while; it does not do that anymore. I would be dryly amused if that box was actually running my old OpenWrt bcp38 stuff which blocked 240 for a couple years. My cloud works, my aws stack works, openwrt works.
Damn; I haven't touched the bcp38 wiki in some time.
In what way do you plan to touch it?
Thanks for the reminder.
The bcp38 code for OpenWrt was not updated in light of the nftables switch, as of a few years ago, but I have not looked at it in a long time. Maybe someone else fixed it. I have not been doing much development. As it is bcp38 needs to be applied carefully by an ISP given the sordid mess of other rfc1918 addresses along the path nowadays. I doubt it is a good idea for consumer devices anymore. I liked the side-effects of running it then tho, stopping random worms for chewing up my external bandwidth. (the code was not just bcp38 related) A plug - that I have NO IDEA made it into other ipv6 implementations - is that we put ipv6 source specific routing into the OpenWrt stack to elegantly make bcp38-like behavior the default there, back in 2013. ip route add :: from my:ipv6:address:ranges/mask dest:addr:of:your:choice. And also made the idea work in babel and ISIS to help with poor man´s multihoming. Most distro kernels I have seen lately do not seem to support "from" anymore.
Peering into a murky crystal ball, say, 5 years in the future:
Another thing that I worry about is port space exhaustion, which is increasingly a thing on firewalls and CGNs. If I can distract you - in this blog cloudflare attempted to cut the number of ipv4 addresses they use from 2 to 1, after observing some major retry issues. With a nice patch, reducing the problem.
https://blog.cloudflare.com/linux-transport-protocol-port-selection-performa...
Interesting. Isn't that something CGNAT implementers would have had to deal with already?
I do not know of a single CGNAT that gives an operator a report on syn retries, and thus exhaustion is hidden by the native retry behaviors of the host stacks. Is there one? The cloudflare work seems helpful here.
Peering further into the soi-distant decades ahead, perhaps we should just allocate all the remaining protocol space in the IP header to a quic native protocol, and start retiring the old ones.
Well, I've been able to avoid thinking about it for some time, but ISTR my reaction to QUIC as violating a number of organized religions' blasphemy rules...
/me hides
Indeed.
I enjoy being offline ever the more, these days. The internet addiction level out there has become rather depressing. https://www.linkedin.com/feed/update/urn:li:activity:7162457657210044416/
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
-- 40 years of net history, a couple songs: https://www.youtube.com/watch?v=D9RGX6QFm5E Dave Täht CSO, LibreQos