Readit Newsdunder_cat commented on The Holy Grail of Linux Binary Compatibility: Musl and Dlopen github.com/quaadgras/grap... · Posted by u/Splizard
Related discussion (the actual project is mentioned in the issue):
"Detour: Dynamic linking on Linux without Libc" https://news.ycombinator.com/item?id=45740241
dunder_cat commented on IPv6 is not insecure because it lacks a NAT johnmaguire.me/blog/ipv6-... · Posted by u/johnmaguire
There was a report a few years back about people running NTP servers to harvest IPv6 addresses.
Security via obscurity will only get you so far.
In theory, IPv6 Privacy Extensions (https://datatracker.ietf.org/doc/html/rfc4941) could mitigate this. In practice, I imagine when you bind to `[::]:port`, that also means that the randomized addresses would work for new inbound connections, too. Not sure how long they typically last, but you'd be fighting against the clock at least before a new randomized address.
That being said, on a slightly less common note: it is quite possible to have each individual service running on a /128. E.g. on IPv6 k8s clusters, each pod can have a publicly addressable /128, so activities like NTP would require the container to have an NTP client in it to expose in that way. That'd mitigate a good chunk of information exposure -- that being said, I agree with the larger point about security via obscurity being insufficient.
I'm glad I stumbled across this: life circumstances have allowed me go abroad for a trip the past two years. One thing I had forgotten about since the last trip were some of my group being unable to get one of the cheap prepaid data eSIMs because their phone was still locked to the carrier. I've been tempted to replace my aging iPhone SE 2022 (^1) with a trade-in deal and get a new phone, but it never occurred to me that would mean being forced to use AT&T's $10/day (capped at $100 in one billing cycle) "International Day Pass" during future trips until it had been paid off for long enough.
(^1) I wish I wasn't so tempted after ~4 years, but the battery health has dropped to 75% and the performance has suffered dramatically. A new battery is on the table I suppose, but I am split between just putting that money towards a new phone.
dunder_cat commented on IP Addresses Through 2025 potaroo.net/ispcol/2026-0... · Posted by u/petercooper
Really need governments to start pushing harder on IPv6 adoption. We need sticks, not just carrots. My favorite is chaos engineering forced IPv4 downtime.
In the US, I really want the FCC to mandate that an ISP provides IPv6 connectivity in order to meet the criteria to be considered broadband (and access the subsidies related to that). Don't even care if the functionality is off by default / you have to call and agree the routing may be sub-optimal, whatever. I currently use HE tunnels but on top of additional latency, the HE <-> Cogent peering dispute still makes it difficult to access services over IPv6.
Hmm. If it is an attempt at DDoS attacks, it's probably not very fruitful:
>$ resolvectl query gyrovague.com
gyrovague.com: 192.0.78.25 -- link: eno1
192.0.78.24 -- link: eno1
It occurred to me while reading the article that I could also just have checked the TLS cert. The cert I was given presents "Common Name tls.automattic.com". However, maybe someone will discover bgp.he.net via this :-)
Hmm. If it is an attempt at DDoS attacks, it's probably not very fruitful:
>$ resolvectl query gyrovague.com
gyrovague.com: 192.0.78.25 -- link: eno1
192.0.78.24 -- link: eno1
dunder_cat commented on A new vulnerability on IPv6 parsing in linux nvd.nist.gov/vuln/detail/... · Posted by u/flyahn06
It looks like this is just a kernel memory leak? I suppose it could lead to DoS attacks from untrusted containers, but that seems to be the extent of it.
Also, the issue seems to be with storing already-parsed IPv6 addresses, not with actually parsing them.
It seems to be about a GRE tunnel implementation too:
From https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
> The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver.
> Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it.
I wasn't familiar with the 'mlxsw' module so I found this on GitHub which was quite helpful: https://github.com/Mellanox/mlxsw/wiki. Seems the impact is even more niche (i.e. this won't be affecting most people's cloud VMs and regular linux desktop/mobile users):
> mlxsw: Mellanox Technologies is the first hardware vendor to use the switchdev API to offload the kernel's forwarding plane to a real ASIC. Mellanox's/Nvidia's current switchdev-based solution is focused on Spectrum ASICs.
Also, nobody should be buying an (overpriced) Raspberry Pi for self-hosting, when used mini-PCs are faster, more reliable (no SD card, better cooling), and often cheaper.
Finally, I don't think you should use Proxmox in a home setting: too much abstraction, too much overhead (mainly memory). Use Docker where it makes sense, and deploy the rest bare metal.
I'll take my turn on the soapbox to say I hope people keep posting about their adventures and misadventures in trying something new. I'd much rather be reading that than seeing yet another post on LLM-based agentic startups or pelicans riding bicycles.