That was not the premise, and I see no relation between license and telemetry.
That being said, I used to run ClamAV, and as I understood it, it was far from a complete security suite, only a scanner, and had no reason to communicate with anything.
Also, it never gave me anything but false positives, flagging image files (jpg, png) on my Linux system with obsolete/benign win32 malware. I wasn't running win32. Idiots.
Indeed, that's the idea, such as protecting the users of an MTA/POP3 host. That's not what I was running, and ClamAV cannot replace Windows Defender, McAfee or Norton, no matter how freakin' free its source is. Honestly.
I don't run antivirus on my desktop but you're probably right. They don't have the resources to be an all around antivirus solution. Their engine does have value beyond antivirus though. For example I am using it with non-virus signatures to block various malicious email types.
That's what I was thinking too. It looks like someone just reinvented tar, and given how it's a JavaScript thing I'm wondering if it's a zoomer who didn't know tar existed and the HN crowd would set them straight. But then I come into the comments here and people are posting about how absolutely brilliant it is, so surely I'm missing something… right?
The funny thing is that IPv6 is used more by general public more than professionals. Public doesn't notice that their mobile network is IPv6, or that there home internet also supports it. It is the professionals that are dragging feet upgrading the business networks.
More people access Google with IPv6 on weekends, currently 46%, than on weekdays, 43%. Presumably because mobile and home networks are more likely to be IPv6 than offices.
No, IPv6 is the underlying technology behind the general consumers' internet connections, but the general public is not using IPv6. The general public has no idea what IPv6 is.
I.e. IPv6 is used by the general public, but the general public is not using IPv6.
By that same token the general public is also not using IPv4. The general public doesn't care, so long as TikTok and Facebook appear on their mobile devices.
When I drive my work van I use a throttle body, when I drive my car I use a carburettor. From my point of view as a user, I'm just driving a vehicle. The point is that users see a holistic system and neither know nor care about the underlying implementation details.
We could also have bumped 255.255.255.255 to 999.999.999.999 = 1 trillion IP addresses, easy-to-remember and backward compatibility with legacy devices.
Modern clients and servers get IP addresses in these new whole IP ranges and can communicate together.
Relatively easy to adapt the code of modern software also since it's about removing a restriction from a client-perspective.
Load-balancers and legacy clients use IP addresses from the old pool.
If you have Windows XP you can communicate only to legacy IPv4 (in practice only loadbalancers from Cloudflare, GCP, AWS and co) and your other legacy stuff.
Others happily communicate together.
But no, we got this wonderful IPv6.
Sad because it was really doable, theoretical maximum below 512 GB of memory for routers to store the whole routing table, it's manageable, versus the 2.176×10^22 exabytes (!) of IPv6.
I'm guessing everyone downvotes you for the very strange implication that most software stores IP addresses in ASCII. All networking APIs I'm aware of expect IPv4 addresses as a DWORD.
This is the point, instead of rewriting a full stack, I would rather change the prototype of these APIs.
To store 999.999.999.999, then you are totally fine with a 64-bits INT (QWORD), and there is no struggle to backward-compatibility store a 32-bits INT (DWORD) into it.
It's more of a matter of doing #ifdef IPV4_EXTENDED #define DWORD QWORD #endif
and add an extra IP field inside the IP header packet itself that says, "this is the IPV4_EXTENDED DESTINATION 5-bytes IP", and the previous field is marked a legacy/deprecated.
In fact, it's quite convenient, since we are all INT64, sockaddr_in would largely fit in an INT64 for both IP itself and the other elements that are in the struct.
5 bytes for the sin_addr field is enough to store until 999.999.999.999.
Gives you 3 bytes to store the port etc.
The networking APIs guys could be drinking cocktails at the bar by now, if they would change these types.
There is backward compatibility and smaller effort for a great impact, and this is beautiful.
It's actually beneficial for the majority of developers.
From the developer of Windows, to the developer of Age of Empires, to the developer of a CRUD app on the web (who stores IP addresses as a string or as an int), they wouldn't see too much struggle to port to int64.
Less than having to build a full new IPv6 experience.
In practice, client apps, at the time you open a new socket, if your lib says it wants an INT32 or an INT64 it doesn't matter for the developer of that app, since type is automatically casted.
time() had a similar situation.
We migrated by adding new bytes, we didn't redefine the concept of time.
From a developer-experience, "link to the latest version of the network library, oh btw, connect() accepts an int64" and remove the UI restriction of 255.
It could even be possible to give compatibility to very old software that we lost source-code from by overriding the network layer with LD_LIBRARY_PRELOAD or equivalent, and patch these softwares by manually NOP the right JGE instruction (the asm code for " >= " ) that checks if we are over 255.
So you need to send a message from your host 5.6.7.8 to one of these newly enabled hosts 500.600.700.800. You update the software on your host, and your target's ISP is updated, and your target updates, and we'll even hand wave and assume your ISP is updated despite apparently having enough legacy addresses to allocate you one.
The message goes out to your ISP router, who then sends it to their upstream ISP, who looks at the IP message, doesn't understand whatever header you've shoved the extended address in, and discards it. Then what's in your standard, backwards compatible 32 bit field? The start of the address? Does your packet go to some other random host on the internet? A placeholder address like all 0s? Does your message get discarded?
How do you convince that middleman to update their hardware? They have no benefit from it? This is the situation IPv6 was in for decades until their literally were not enough IPv4 addresses which finally lit a fire under companies to start enabling it.
(I'm not pushing this idea to the max, I mean, now IPv6 is here so we'll just go with it, but this is for the mental and engineering exercise).
To answer your question, in my model, the legacy IPv4 field contains the IP addresses of "IPv4 to IPv4 Extended bridges".
Let's imagine you want to connect to [example.com]:
Clients who speak IPv4 Extended and their ISP is compatible, get the IPv4 Extended answer:
425.223.231.123 A+ example.com
and directly to it
Clients who speak IPv4 Extended but don't have an IPv4 Extended compatible ISP, add that extra IPv4 Extended header and speak to the bridges.
425.223.231.123 A+ example.com
34.23.12.2 BR example.com (the bridge)
Clients who speak IPv4 only but don't speak IPv4 Extended don't have to think about IPv4 Extended at all, since they will go through the usual layer-7 (typically HTTP) reverse-proxy, or a routing based on rules (ip/port pair).
Cloudflare does search large scale reverse proxies, it works fine in practice.
If someone has an incentive to run such bridges or reverse proxies solution, first it's yourself, to save your preciouses IPv4.
To the end user the promise is "you will connect faster to the internet if you are in native IPv4 Extended (because you skip these intermediate bridges)"
We actually have a nice mechanism that we could reuse for knowing which bridges to use, it's reverse DNS lookup.
> In practice, client apps, at the time you open a new socket, if your lib says it wants an INT32 or an INT64 it doesn't matter for the developer of that app, since type is automatically casted.
A lot of networking gear is far closer to an ASIC than a general-purpose CPU, so you can't "just change it to int64". They were built to process 32-bit addresses, and are unlikely to be able to swap to 64-bit without enormous performance penalties.
E.g. routing tables would balloon in size, which in practice means that you can store far fewer routes. Ignoring changes in the size of the netmask, it's 4x the size to store 64-bit address pairs, so your route tables are a quarter the size they used to be.
The hardware refresh requirements are a big part of the reason why IPv6 rollout is so slow, and your proposal doesn't avoid that. Getting the software side of things to play nice has always been the easy part of this, even in IPv6.
> It could even be possible to give compatibility to very old software that we lost source-code from by overriding the network layer with LD_LIBRARY_PRELOAD or equivalent, and patch these softwares by manually NOP the right JGE instruction (the asm code for " >= " ) that checks if we are over 255.
In IPv6 land, you just encapsulate IPv4 in IPv6 [1]. It's a lot cleaner than jankily trying to override instructions, especially when the relevant code may run on your NIC rather than your CPU and require kernel firmware patches (or, god forbid, custom NIC firmware) to implement.
and what about the protocol bytes that go over the wire - you know, the most important and hardest to change part?
There've been several proposals to make "IPv4 but bigger addresses". All of them are just as hard to deploy as IPv6. You still need to upgrade all your routers and you still need to run two parallel networks.
If it's going in the same spot in the packet header as the current IPv4 address, how do you make sure that the 20-30 routers owned by 3 different companies that are likely to be between your computer and the destination computer exhibit a behavior that is consistent with moving packet closer to the destination?
(If they don't, you've just made a version of IPv6 that is worse-- it's missing the last 30 years of IPv6 implementation.)
It's written above, bridge destination address in the "legacy" IPv4 destination header, and that bridge can be figured out by looking up the reverse dns entries on a IPv4 Extended IP, until the user is natively using an IPv4 Extended network.
This brings the packet closer to the destination.
The new address goes into the Options field, you can store lot of data there (somewhere up-to-60 bytes, and we need 1 or 2 byte actually).
Reminder: The goal is to add one-byte to have more IP addresses, not rewrite the whole internet.
Here it looks like the guys wanted to fix that IP allocation problem, and then they went all-in, and decided to rewrite everything at the same time.
It's ok, and even a good idea in theory, but network administrators don't like to be pressured "in emergency" into upgrading to this solution.
The practice shows that people rather prefer doing NAT than IPv6.
Do your devices behind the router get IPv6 addresses, or just the router itself?
I wouldn't be super surprised to see routers getting IPv6 addresses and doing a 6in4 NAT, so devices behind the router get IPv4 addresses.
I would be surprised and impressed if your devices were actually getting public IPv6 addresses.
IPv6 can be kind of unwieldy, but the bigger issue to me is that old and/or very cheap clients (like bargain-bin AliExpress IoT stuff) may not support IPv6 at all.
I believe you can run DHCP for both and let the client pick one, but then you're into running dual-stack routers, and I would be very surprised if ISPs had any interest in supporting them for home use.
I may well be wrong, though. I haven't looked into it in a few years, because my ISP doesn't support it.
edit: Okay I thought it did but apparently my router doesn't assign publically routable IPv6 addresses by default. I found a setting that would enable this though. Gonna leave it off for security reasons, but it's just a toggle, so still seems pretty easy. Also my local interface apparently has an (unrouted) ip in the same subnet as my router's public address, and I'm not sure how it got it.
Every device on my LAN that responds to Bonjour on `.local` uses link-local IPv6 without me having had to do any configuration or put any thought into it whatsoever. ¯\_(ツ)_/¯
EDIT - Oh, you’re talking about public IPv6… similarly, my router (a TP-Link Archer 1200) gets assigned a prefix by my ISP, which it then auto-assigns inside devices IPs from, again without any explicit configuration or intervention on my part. Super easy.
Do you understand on what basis? Do you know enough to assign addresses in a way that you, not your router, wants?
Can you ssh/other forms of remote into any machine that accepts ssh on your local network using only ipv6?
Can you redirect ports to specific local machines using only ipv6 (that implies they keep constant addresses)?
Can you easily switch between two internet connections going through different routers that are plugged into the same switch for any machine on your local network using only ipv6?
Speaking of which, since the ISP decides on the addresses behind your NAT, can two separate ipv6 internet connections even exist on a local network?
This is all easily doable with ipv4 in like two afternoons without setting up anything beyond perhaps a dhcp server and some firewall rules. How many additional services do you need to do that with ipv6? And how enterprisey are they?
Do not "ssh/other forms of remote" using ip addresses. Use domain names or local domain. It is easier to remember, is more secure (if configured in DNS), and less prone to errors.
> Can you redirect ports to specific local machines using only ipv6 (that implies they keep constant addresses)?
Yes. Use domain names in configuration files. It more robust, easier to read, and is better protected against network changes on the local network.
I have been part of multiple ISP changes and searching through configuration files for ISP specific IP address ranges is never fun. It wastes time and is prone to errors. In enterprise settings domain names rarely changes and even when they do, the old primary name are usually retained for backward compatibility. An ISP can get replaced fairly quickly if an alternative is cheaper or provide a better service.
> Can you easily switch between two internet connections going through different routers that are plugged into the same switch for any machine on your local network using only ipv6?
Are you talking about BGP? BGP is a fairly complex protocol and uses some archaic configuration syntax, but even so there are generally no differences between ipv4 and ipv6. It is the same pain making sure both ipv4 and ipv6 switch between the two routes correctly.
I have absolutely no problem remembering the last byte of any machine on my network. Because that's all it takes with ipv4 on a sorta complex home network, no need for extra services.
> Are you talking about BGP?
No, with ipv4 i can just change the default route :)
Everything is NATed behind the two routers so changing the default route changes which connection that machine uses. You're thinking enterprise, and then ipv6 becomes ... fine. I just have a hack that works fine for me.
> Do you know enough to assign addresses in a way that you, not your router, wants?
If I want to manually assign addresses it's still pretty simple, but in the end I normally just don't care. I don't want to know what IP my printer is, I just want to reach it. Which isn't a challenge at all. Even for things at my home that are IPv4 only they're practically all DHCP. Because there's little reason to ever really care about something's address.
> Can you ssh/other forms of remote into any machine that accepts ssh on your local network using only ipv6?
I have no problems reaching any host on any of my networks even if they're running only IPv6. It's nice too because I can trivially reach any port I want globally as well with a basic firewall change. Even better I can have one host have many IP addresses with different services bound to each address if I want.
> Can you redirect ports to specific local machines using only ipv6 (that implies they keep constant addresses)?
Why do any port redirection at all? Just set the firewall rule and things can hit it. And yeah, they can keep constant addresses. They can have dozens, hundreds of static host addresses if I want.
> Can you easily switch between two internet connections going through different routers that are plugged into the same switch for any machine on your local network using only ipv6?
If that's something you're really wanting, Network Prefix Translation can be done pretty easily. But the vast majority of home users aren't using dual WAN anyways.
> This is all easily doable with ipv4 in like two afternoons
Sounds like your setup with IPv4 took more work than mine with IPv6, as mine only took me an hour or so while yours took multiple days.
> as mine only took me an hour or so while yours took multiple days.
Yeah, because the first time I had no idea what I was doing, except vague feelings about ipv4 works. Did you factor in your pre existing ipv6 knowledge when you counted just an hour?
> Network Prefix Translation can be done pretty easily.
What's "easily"? How many services do I need to setup? Some other helpful HNer tried to explain to me once and the list was like 2 or 3 daemons in addition to dhcp, firewall etc.
Your standard was "It's unusable on your fucking home network."
I've set up and managed IPv6 at work before, yes. I don't know if I'd call them "complex" networks though. Either way I set it up at home several years before. And I had been running IPv6 at home before I even bothered setting it up in a way I wanted, as my ISP's box previously had a decently competent SLAAC and IPv6 firewall setup in their CPE router. So that took me 0 minutes of time past plugging it in.
As for this disdain of running such complicated systems like "DNS", so many things support mDNS these days and plenty of home routers will automatically update their local DNS with DHCP entries. I didn't have to manually configure a DNS entry for my printer, I just gave it the hostname "brother" when I first set it up and now when I need to add it, I just do "brother" on a new computer and boom it finds it wherever it is. If I want to check the toner level, I open a browser and go to http://brother and its there. And even though I've radically changed my networking setups over the years, all my configurations pointing to "brother" still just work.
But hey just complain about how it's just impossible and takes so much work instead of actually learning new things.
From the sibling comment:
> No, with ipv4 i can just change the default route :)
Are you suggesting you're running around and changing the default route on all the devices on your network when a gateway goes down? What a nightmare. Just have your router have multiple WAN connections and have it do the failover for you.
> I have absolutely no problem remembering the last byte of any machine on my network
If you want, you can do the same with IPv6. You could set your stuff to have your IP addresses be fd12:3456::1, then fd12:3456::2, then fd12:3456::3, then fd12:3456::4, then fd12:3456::5, etc. Remembering 123456 as your home ULA prefix isn't too challenging, is it? You can then set up an NPT rule like the one above on your router to translate this prefix fd12:3456::/64 with whatever your public prefix is from your ISP. Most wouldn't do this though, as its essentially the Fisher Price of networking designs.
> As for this disdain of running such complicated systems like "DNS"
Disdain? I run a few bind instances for my own domains. On rented servers where they belong. I'm just opposed to having one required for my local network.
"NPt makes perfect sense for SOHO IPv6 Multi-WAN deployments." Wait, they agree with me. That there are SOHO IPv6 Multi-WAN deployments. Who would have thought?
> running around and changing the default route on all the devices on your network when a gateway goes down? What a nightmare. Just have your router have multiple WAN connections and have it do the failover for you.
It used to be that but I don't think any of my internets has failed since like 2010... mostly keeping them out of inertia. So I've never felt the need to fix the manual failover. It's not all devices anyway, just the one I'm using at the moment.
> But hey just complain about how it's just impossible and takes so much work instead of actually learning new things.
Too many new things to be exact. Most of them needless. However either people have figured out by now how to work around the ipv6 commitee to simplify things, or they were always there but whoever tried to explain ipv6 to me before had a fetish for enterprise solutions. I distinctly remember being told I need to set up at least 2-3 extra services for my dual wan setup.
Your answers are almost devoid of acronyms and "helper" services that i need to set up and learn because it sounds professional. You almost only included firewall rules :)
This was not my opinion of ipv6 before. Maybe I'll give it a chance in the future. My current setup still works "just fine" though so I need to be very bored to fuck it up.
> "NPt makes perfect sense for SOHO IPv6 Multi-WAN deployments." Wait, they agree with me.
Well yeah, without implementing BGP and controlling your public prefixes its the only way to have multi-WAN deployments, and chances are home users aren't messing with BGP. Most users will get by fine just adopting their WAN-issued prefixes.
> I don't think any of my internets has failed since like 2010... mostly keeping them out of inertia.
So next time you do some big network maintenance just drop your redundant WAN connection, sounds like you haven't really needed it in 14 years (imagine the thousands of dollars you'll save not keeping it another decade and a half!). Just adopt whatever public prefix you have, and life will be simple.
> Your answers are almost devoid of acronyms and "helper" services
Largely because there aren't really many "helper" services needed if you're willing to adopt some pretty basic network designs. Add DNS/mDNS, and suddenly you don't need to care about the specific numbers of things. Just accept SLAAC, which comes with any Linux/BSD distro/MacOS/Windows/whatever IPv6 embedded stack you've got comes out of the box for the last decade+, and suddenly you'll get publicly routable IP addresses. If you want to access SSH on a box, add a firewall rule for its IP and register its IP in a public DNS, and suddenly its accessible anywhere. You can make any host in your network accessible if you want to. Its nice.
> This was not my opinion of ipv6 before. Maybe I'll give it a chance in the future.
I get there's a lot of new acronyms with it digging deep in docs. I get it sounds like there's a million ways to deploy it. There's a lot to know, if you want to get deep in it. Honestly, if you just kind of loosen your reins a little bit, accept the things that are already shipping on the things you've been running for a decade will just work with the newer dynamic stuff, and adopt DNS, it'll probably be perfectly fine. You probably don't need to install/configure dozens of additional things.
> imagine the thousands of dollars you'll save not keeping it another decade and a half!
Uh well, i'm in eastern europe and the fiber i would give up on is in a package with the cell phones and the tv channels, so i think i wouldn't even notice it missing from the bill. And it's all iptv so I don't think I can have tv without the fiber.
The other pipe is business ish (symmetrical, no restrictions on servers) so I'm not giving up on it, I'm using it to give stuff to customers etc.
> I get there's a lot of new acronyms with it digging deep in docs. I get it sounds like there's a million ways to deploy it.
As i said, last time I asked on some forum (maybe hn, maybe ars technica) i got drowned in acronyms. Most of them for extra daemons to handle ... some config for a larger network, i guess.
And believe it or not, I didn't know until today that you can ignore your ISPs prefix and do address translation with ipv6 :) I thought you use what you get and that's all. Because that was the promise of ipv6 wasn't it? No more NAT.
Lots of machines at home and yet having DNS tied to DHCP or running mDNS is too much of a hassle.
I would hate to have to remember even the last octet of all my machines in my house. Instead it's just the simple names. The numbers underneath can all change whenever, it doesn't matter. Until I start calling my kids by an octet a name will be easier to remember instead of "is that north camera 101 or 105 or 113 or..." versus "north-camera.my.net" or "is my pool controller 10.7 or 10.8 or..." Instead it's just pool-pump.my.net.
I mean why would anyone really care to deal with DNS anyways, just a bunch of fluff. Real IT admins just memorize IP addresses. Why would I bother dealing with all that DNS hassle?
If its easier to remember this site by its name, why wouldn't it also be easier to remember what your file share's host is by just remembering its name instead of some collection of digits? Do you remember people by their phone numbers or by their names?
Having functional local DNS is not complicated these days. On tons of systems it comes out of the box, you almost have to go out of your way to not make it work. You need to actively try to not use it.
What you forget is on your average home network only the last byte matters. The first 3 don't change. It's always 192.168.x.y, x is fixed so you only need to remember the y.
We certainly do performance tests, and we also don't auto-update. The issue here was it was a slow leak, so it took time and significant load for the pattern of errors to present itself.
reply