Hacker Newsnew | past | comments | ask | show | jobs | submit | TZubiri's commentslogin

One issue with this argument is that, almost everything is memory, especially in C. It's not really descriptive. If you write a reactionary language like Rust, it may be possible that you just fix one type of issue (with an error type taxonomy that's not very refined), and end up with a language that does not necessarily cause less bugs and vulns, but that causes less vulns that can be classified as that type of issue, while increasing other types of bugs/vulns, either of an existing type, or of a new type that only exists in that new language.

Like are we empirically seeing less Rust CVEs? Adjusted for popularity of software and perhaps age of software.


Are you saying by attempting to reduce certain types of bug category such as memory safety, other types of vulns would suddenly be increased because of it? It sounds to me like you are saying we shouldn't treat common cold because cancer rates might increase. And what do you mean by reactionary?

> It sounds to me like you are saying we shouldn't treat common cold because cancer rates might increase

surprisingly that’s almost not a strawman, I’d support an argument like that, and it’s how medicine works

if a cancer treatment is discovered, it needs to be trialled for side effects, and actually chemotherapy can have side effects that are worse than the cancer, it’s entirely possible for chemo to weaken the immune system and thus increase colds.

so hillariously, yes, that’s almost what I’m saying. but to be precise I’m not saying we shouldn’t cure cancer or solve bugs, just saying that solving one kind of issue doesn’t prove the tech is beneficial overall, and the more generic the problem being solved, the more likely the panacea will fail or have side effects


It seems like the anthropic PoC involves MPTCP, but the bug itself is not in the MPTCP code, it's in a generic TCP codepath relating to options, MPTCP was probably just a convenient codepath for memory manipulation.

maybe

i’d focus on writing new stuff with rust though, not rewriting old stuff

and time will tell whether it actually reduces bugs or just change the failure modes to something else

also C will always be there in some way or the other, at least in conventions and syntax


In what sense is the internet not P2P already? If we manage to establish a signal between us, we can definitely make an internet connection without any third party.

Huge asymmetries both in bandwidth and capability between up and downstream. A lot of US users are still on DOCSIS, a lot of users worldwide behind CGNAT (less of an issue with IPv6), stateful firewalls for cellular to avoid creating unsolicited radio traffic. A ton of the bandwidth the average person is consuming is from talking to a caching box sitting in the ISP's DC. Basically the network you're connected to is optimized for feeding you lots of data and having you send back ACKs.

I do like the analogy that cowlevel makes with blockchains being P2P but regular centralized tech being built on top of that P2P layer. Similarly on top of the P2P internet, these intermediaries are building something less co-operative and more half-duplex.

I always found it interesting what the direction of the data has been in this dystopia, might not be signficantly interpretable (as in, "capitalism mainly uses the internet to blast propaganda and ads" instead of "capitalism uses the internet to spy on the citizens"), because the up/downstream direction of data will probably be dominated by video, so the direction only tells us which way video is going, and it makes sense that corps want to send videos, but consumers are more apprehensive about sending huge volumes of theirs.

But in general, it does seem to be that as time goes by, the corporations seem to be less interested in receiving messages, as opposed to sending messages. Maybe a decade or two ago virality was this interesting organic phenomenon that emerged and was followed by the companies, nowadays it seems to be more of them controlling what is viral and what is not, preferring to distribute a unified message.

Interestingly a tax on consumer bandwidth would not deter peering and huge volumes of traffic on the backend, so I feel it would greatly deter edge caching, which relies on reducing traffic distance instead of end-user traffic. I'd assume that at least video would be a bit less top-heavy and more indie/personal. That said, that's just video, the rest of the media forms will probably be unaffected by such a tax, 5 cents per GB is only relevant to video.


Historically, P2P networks have needed enforcement of share-and-share-alike if they wanted people to contribute as much as they downloaded. There are plenty of derogatory names for people who only download and never contribute.

But obviously, this is the reality of a consumer Internet. We all want to download and install software, and we want to consume media, watch Netflix/YouTube, and generally read web pages rather than write them, or produce videos or upload massive amounts of content. It's typically been beyond our resources, as consumers, to produce any appreciable amount of uploads that are worth contributing.

However, and this chills me to the bone to think about it, but now AIs have democratized the production of content, and so anyone who can afford a few tokens can absolutely generate mounds of spam, whether it's walls-of-text or fake music or hours of video content that they didn't need to write, produce, or edit. Hollywood can produce mass amounts of crap every year, but salaries are still paid and audiences still pay, in order to say how much they hated every minute.

So if you think about it, the commercial consumer Internet may be at a precipice where, all of a sudden, everyone begins contributing beyond their means, and it's all slop that needs to be gated and throttled and rate-limited. Furthermore, it won't be monetizable or copyrightable; people will just fill up social media storage with streams of consciousness where nobody cares. Nobody would miss it if it were deleted or shadowbanned.

The DOCSIS is a good start; I mean I'm behind 100Mbps/12Mbps nominally, so I should only be able to contribute 1/10th of what I'm consuming, currently. But do we really want a truly P2P Internet, where everyone is just shoveling slop at everyone else? Really?


> the commercial consumer Internet may be at a precipice where, all of a sudden, everyone begins contributing beyond their means, and it's all slop that needs to be gated and throttled and rate-limited.

Reminds me of Metal Gear Solid 2 where the AI is talking about humans getting overloaded with data, and requiring an AI to curate it into information.

This video goes into it, especially around the 13:20 mark:

https://youtu.be/jIYBod0ge3Y


Far too many people don't realise this. The internet only isn't P2P because of market economies of scale - like how all the bitcoins are (were) in Binance. The underlying tech is still P2P.

There is going to be a problem with everyone trying to register an address block. The internet addressing scheme isn't designed for many tiny networks and you'd have to use sub-blocks of a big block, but then someone owns the big block and gets held liable for the use of the whole block and therefore for the whole P2P system.


It actually works perfectly fine with many tiny networks, as we have been seeing with IPv4 blocks being carved up into increasingly smaller pieces. You might not be able to get a /12, but with enough cash you can for sure scrape together 2^12 discontinuous /24s, and it'll Just Work.

Barely. People keep having problems with their routers running out of RAM, and there are less than 2^24 blocks available which isn't enough for everyone to have one.

the underlying tech of the internet is of course P2P but there's little out there that allows us to actually establish a direct signal between us without needing to go through a bunch of centralized intermediary services. bitchat is one of the few that actually kind of manages it

I'm interested in this intersection of technical problems where we already have the tech to solve it, but the bottlenecks are social/legal/financial incentive.

Recently there was an old lady in the family that had an appendicitis, an ambulance rejected her, and the next day it got worse, and at that point she was accepted, but it was a bit too late.

One hypothesis is that triaging is hard and there's a lot of demand so things only go in when it's bad enough (considering there was medical insurance, they aren't charging per patient, so there's no incentive to take on more patients). But if that were the case, then preventive measures would actually reduce the total burden on their system.

The more cynical hypothesis that I'm holidng is that that health system is maximizing for work, if there's 10 appendicitis per month, and they are all handled in time, that's maybe like 5 hours of billable hours per patient? But if the appendicitis becomes bad enough and there's a puncture, then you have infections, complications, the patients have to stay for weeks and often come back for checkups, we are looking at maybe 100 billable hours? So the financial incentive is there.

In that sense what I want to add is that the title would be completely wrong, the solution is not for the hospital to pay 100$ for prevention, but for prevention to be more accurately priced, we should be paying 50k, and maybe even 100k for prevention, because we value it more than emergency action.

In a broader economic sense, there's a lot of cases where there's a huge difference between the cost and the value, Shkreli got a lot of heat for surging up medicine prices, but I don't think it's immediately obvious that something should be valued in proportion to what it costs. Maybe if we price heart prevention at 100K, there would be more incentive for everyone involved to just get a fucking pill to those in need, imagine how many people would jump at that opportunity to make it happen, call centers, bureocrats, NOC support, legal teams, all dedicated to making sure a pill gets to the patient before a heart attack does.


Nobody likes to say this out loud, but because the US healthcare system is largely based on “fee for service” billing, it is true by definition that the sicker the patients are, the more profit the providers make. So incentives for actually making people healthier have to be imposed in indirect ways.

There are some pockets of “per capita” payment, where the provider gets a fixed amount per person and is thus encouraged to reduce treatment costs, which indirectly should encourage preventative care, but also encourages just refusing to treat people.

We could remove these weird constraints by making health care a government service rather than a highly contorted pseudo-market, but that would not be the American way. It has to at least look like a market, even if it’s an ineffective, inefficient, opaque, corrupt one.


> We could remove these weird constraints by making health care a government service rather than a highly contorted pseudo-market, but that would not be the American way. It has to at least look like a market, even if it’s an ineffective, inefficient, opaque, corrupt one.

It is still a market (and a single-payer one, ultimately) in these places, but it is not a government service. It is the best solution: the government funds the appropriate cost of care, the provider group is financially responsible for meeting it, and they are incentivized directly to get it right.

The left needs to stop shrieking about Medicare-for-all and the right needs to stop pretending like it can even spell healthcare. There are good solutions.

> but also encourages just refusing to treat people.

It categorically does not. It would be foolish to do so.


>It categorically does not. It would be foolish to do so.

Foolish hardly implies categorically false. It's a well-documented incentive for other risk-bearing entities (see insurance claim denials). Why are providers under capitated contracts categorically immune to refusing treatment to protect margins?


The Medicare “star system” attempts to compensate for this, but somewhat perversely by giving higher reimbursement rates to providers with higher quality. Logically, they should be getting lower rates because they’re more efficient at providing the service. But because the only real incentive is their profit margin, it has to be that way. And of course the star system definitions end up being a constant target of lobbying and stat-gaming.

IIRC this gets gamed by patterns like refusing to readmit patients following complications to hack low readmission rates and preserve higher reimbursement rates? Feels like so much in healthcare where you have a well-intentioned patch trying to solve deep incentive alignment issues and creating more problems.

Completely agree with your characterization of the current system but why does making healthcare a government service necessarily lead to better outcomes vs current state or a more sensibly constrained market?

Seems obviously right in terms of total cost to the median patient (less obvious for individuals in higher tax brackets), so I'm not disputing that. More curious about incentives to improve care delivery for better long-term outcomes.


Healthcare as a government service is one approach to the actual goal, which is healthcare that maximizes the quality of life and productivity of the citizens, rather than maximizing the profits of the providers.

When goods are discretionary and there are no externalities, it’s fine to have a purely autonomous market solution. Healthcare fits neither of those criteria. There’s a reason we don’t (or at least shouldn’t) have private subscription markets for baseline levels of law enforcement, fire prevention, public transit, food and drug quality enforcement, etc. etc. That same reasoning applies to healthcare.

Capitated reimbursement is a hybrid approach that helps a bit, but you can see from Medicare Advantage how the private sector relentlessly games the system because that’s how the incentive is inherently set up by the for-profit nature of the providers.


Yeah capitated reimbursement moves the risk but doesn't seem to effectively encourage innovation on care delivery when it's relatively easy to just cut costs at patients' expense because they have no agency and meaningful recourse.

Your criteria for when a market is (not) a good solution seem reasonable. My biggest concern is there's a fundamental problem with scaling labor-driven services that's exacerbated by entrenched interests constraining the labor supply to support wage growth. Care delivery needs to change if you want to fix both cost and quality, and I have a hard time imagining monumental changes to care delivery from a government service. Care will be expensive as long as it's constrained by scarce labor. That means either costs will balloon at the taxpayers' expense, service quality will decline to cut costs, or more likely both.

The way you fix that is either a) dramatically increasing the supply of qualified clinicians, or b) automation. Clinicians don't want more clinicians because it lowers their wages, so it will be fought at every level in the name of patient safety. But they also don't want automation to decouple care from their labor, so automation, too, will be fought at every level in the name of patient safety.

Most of this is opaque to voters who are largely under the impression that it's all health insurance executive greed, so there's not much of a political incentive to impose meaningful changes.

Where's the way out?


> "fee for service"

> "per capita"

I don't quite get the difference, patients pay a fixed amount for insurance, hospitals charge "fee for service" to the insurance. Both systems coexist, it's not one or the other.

To be clear, I'm not suggesting changing the whole system, I think that's infantile sorry to be blunt, I'm proposing a more down to earth (and commercially appealing approach) of increasing the price (and thus financial incentives) of medical goods that have low cost but high health values.

My economic theory clearly isn't as strong, because how much should a CT scan and a pill be priced at relative to a heart attack response with a 1 week hospitalization and a bunch of work. Because the cost of a CT scan and a pill is low (100$), the value of it is high (50K$ lower bound), and the cost of treating a heart attack is clearly around 50K$, but the value of it is clearly lower than the preventive treatment (perhaps stochastically adjusted).

So should we be pricing by cost or pricing by value? The naïve approach is pricing by cost, so that everything is cheap, the first issue with this approach is that it disincentivizes research, which is why legal systems widely recognize patents, copyright and intellectual property.

I looked into Shkreli's case a bit deeper, and he was a stupid kid of course, but it's what comes to mind when thinking of 'raising prices' of medicine, there's not many faces to that idea.

That said, I'm not saying that prices SHOULD be hiked, just that I'm not convinced that medicine pricing should be cost based, or that it should be value based, or that some supply-and-demand principle would magically find a value in the middle. I'm just saying that it can be either way, and I just don't know which way it ought to be.

And ultimately, it's a decision that every actor in the industry can make, what they price their products and time at. And to reiterate my thesis, pricing your product as cheaply as possible might counterintuitively reduce it's impact, since there is no incentive for intermediaries (or even yourself) to work on it. So I'm not saying that prices should be maximalized either, just that the relationship between price and value contributed to society is not linear, if you price your medicine at 0, you go bankrupt, that's not helpful obviously, and evidently pricing a CT scan and a heart attack pill at 100$ is not cutting it either, hike that up.


>I don't quite get the difference, patients pay a fixed amount for insurance, hospitals charge "fee for service" to the insurance. Both systems coexist, it's not one or the other.

I think their reference to "per capita" here is referring to a capitated payment structure where a provider organization is given a fixed amount per patient up front instead of billing for every service they provide. The software analog would be something like a flat subscription fee vs usage-based billing. While it's not the default in the US, it theoretically encourages providers to provide cost-effective care rather than just racking up bills on unhealthy patients.

The mechanism here is who bears the financial risk. The model you're familiar with is one where the payer (commercial insurance or medicare/medicaid) is the risk-bearing entity. They want more cost-effective care so they can protect their margins while the provider is incentivized to push a high volume of expensive care so they can boost their margins. Don't have it handy but the data on this shows providers are winning this battle with healthier, growing margins vs insurance companies whose margins generally aren't great.


Insurance companies generally have regulated profit margins. Healthcare providers don’t. However, note that this is all percentages — if the total cost of healthcare goes up, providers and insurance companies both win in absolute dollar terms.

Yeah absolutely re regulated profit margins (indirectly through MLRs - their actual margins are way below the cap due to expenses) but that only reinforces my point that providers are having more success growing their margins (on a relative basis, anyway).

Great point on bigger pie increasing both shares. I didn't mean to imply it's zero sum.

Oh the irony of MLRs encouraging insurers to provide terrible service (opex recovery boosts profits) and let providers push fees ever upward (bigger pie, bigger premiums, bigger net profit on constrained margin).


>CZ saying it is confirmed, and that he expects accountholders to be made fully whole

Sure you can print USD to make it all magically go away

But it would be very convenient if there's some experimental token of which a majority was stolen, so that irreversible damage was caused. If the token is experimental it could have a low damage, but could demonstrate the irreversible nature of these types of attacks, returning fiat money doesn't waive the issue away.

There's also the fact of funding criminal networks for billions of dollars, which probably causes them to scale cyber or non cyber operations or otherwise gain power.


>IPv4 is actually a form of land (it's a finite "natural resource", although that's not quite proper),

It's closer to radiofrequencies I think, these are heavily regulated.

However radiofrequencies are purely natural resources, while IPv4 have a specific copyrightable spec design, domains have trademarkable TLDs


> https://xkcd.com/1172/

Here I am complaining that I lose my static address, but your problem is that the address is static!

Bottom line is that once a system is a certain way for a while, other systems and people grow dependency on that

>https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...


I recall something like this, what did you call this? ipv8?

the thing is that it does require a switch similar to ipv6. but maybe there’s a subnet that maps 1 to 1 with the legacy block?

something like this could theoretically be pinned onto ipv6 AND anyone could do it, just select a 98 bit prefix you own, and the rest of the 32 bits you can map to ipv4.

phase -1 could be tunneling traffic through a single zone proxy which would be inefficient and is purely conceptual

phase 0 would be the same, but with an anycast ipv6,same ip that resolves differently based on location, like 8.8.8.8

phase 1 would be the mapping prefix to ipv4 (and viceversa?) being distributed to the routing tables like, which could be done via application logic (most efficient), or via some deep arcane isp routing conf files, or just a hell of a lot of routing table entries for each ipv4 but duplicated, possibly programatically controlled by an application that generates router table files as a target, thus avoiding desyncs and effectively becoming the first option of application level implementation

maybe something like this already exists though

of course it’s horrible hacking (as hacking in the non crime sense often is), but it allows for a purely technical solution to issues of political and administrative nature.. which is all the rage nowadays


There already is a subnet. Actually a few. ::ffff:192.168.0.1 is reserved for when you need to pass an ipv4 address through an ipv6 API (e.g. v6 client application on a dual-stack OS on a dual-stack network) and 64:ff9b::192.168.0.1 is reserved as an actual address for NAT64 gateways to use (v6-only client, network has a NAT64 gateway somewhere on it)

Hi, I’m helping a hospital in Buenos Aires that has lost their IPv4 due to their ISP moving to CGNAT, putting their on prem imaging servers offline for 7 days. (it’s ok for us though, we have a backup failover isp)

Might have to do something horrible like:

- setup an ipv4 tunnel, which will require hacking a VPN to allow TCP listening, and routing connections to some external proxy with a dedicated static ipv4 address

- or do some modem router level nat port forwarding, and use a ddns to avoid ip changes breaking stuff. but that won’t work probably since public ip is shared

will investigate the isp to see if they are truly short in ipv4 or if they are just moving clients off them in order to sell them to higher bidders and plans, which is likely since I’ve been upsold into optic fiber, static ip surcharge, sd-wan, dedicated connection so far

if you have any advice or RIR contacts (or an ipv4 block to donate, invest or sell), I’d be thankful, my email is in my profile


The first thing you need to ask is: Why do you need IPv4?

I don't know much about your imaging servers: Do they accept incoming https connections, or is it some other kind of TCP or UDP protocol? Assuming it's https, why do you need to stick with IPv4?

> Hi, I’m helping a hospital in Buenos Aires that has lost their IPv4 due to their ISP moving to CGNAT, putting their on prem imaging servers offline for 7 days. (it’s ok for us though, we have a backup failover isp)

Two more things:

1: If you require IPv4, that needs to be part of the contract with your ISP. If they just arbitrarily turned you off, it means that you didn't contract for the services you thought you had.

2: IPv6 is supposed to solve a lot of these problems... So again, why can't you move to IPv6?


> I don't know much about your imaging servers: Do they accept incoming https connections, or is it some other kind of TCP or UDP protocol?

Yes

>why do you need to stick with IPv4?

To support devices and routes that do not have ipv6 support?

>1: If you require IPv4, that needs to be part of the contract with your ISP. If they just arbitrarily turned you off, it means that you didn't contract for the services you thought you had.

That is correct in principle. Although, in the absence of a contract, if a service has been provided for a long time in one way, I'd say there's an argument for breach of contract when that way changes for the worst.

Another argument for breach of contract, which can work jointly with the previous, are industry standards, as far as they define the terms that are implied by common words like "internet connection".

Finally, there's the specifications themselves, since the service is billed as "internet", one can refer to the Internet Protocol Specification, although if they do offer IPv6, that might be reasonably considered a substitute, it is a material change that was not agreed to originally (this being a pre IPv6 contract). That said, an IPv4 with a local address might technically still be defined as internet, what is broken in this case is TCP, not the IP, although by lacking a public IP address, TCP is broken via an IP protocol failure, so there's an argument that something is being sold as Internet but it isn't really internet, there's no written contract necessary, the term used to describe the product creates the contract in the same way that selling a carton labeled Milk would create a contract based on milk coming from mammaries of a domestic mammal, and not pressed Soy Juice with artificial coloring.

>2: IPv6 is supposed to solve a lot of these problems... So again, why can't you move to IPv6?

I'm open to proposals to moving IPv6, I'm not content with having that be forced and removing it from people and institutions, if there's a shortage, then that means no new IP addresses can be issued, why are we normalizing the removal of IPv4 addresses? Are they being removed from lower priority users in order to serve high priority usecases? If so is a hospital a low priority user?

The main issue with IPv6 seems to be IPv6 proponents that try to kill IPv4, no one will migrate if you force them to, if you propose, we will consider.


The professional services that I work with give plenty of notice (years) before turning off services. Were you using an internet connection that's intended for hosting servers? (As in you were paying for a dedicated static IP.) If so, then you have a case.

Otherwise, your arguments about what "internet" is are flawed. IPv6 has been a thing for about 30 years, with a well-publicized problem with IPv4 address space and migration plan. I suspect that it's (IPv6) older than your hospital's contract. Even in the IPv4 world, your IP can change at any time and you can be put behind a NAT. That's why ISPs will sell you a static IP if you need one.

>> why do you need to stick with IPv4?

> To support devices and routes that do not have ipv6 support?

> Are they being removed from lower priority users in order to serve high priority usecases? If so is a hospital a low priority user?

After reading your response, I suspect the real problem is attitude and experience. The hospital should have IT staff that know to purchase a static IPv4 IP. This should be part of the contract with the ISP. If it wasn't, ultimately it's up to the IT staff to approach the ISP and arrange to purchase one.


> The hospital should have IT staff that know to purchase a static IPv4 IP

I purchased a static IPv4 IP, and they made the CGNAT IP static.

I thought about making a blog post about it, but I realize there's so much nuance and details. I can't tell if it's just venting about work, or a genuinely interesting clusterfuck in some forlorn corner of the new world.


> I purchased a static IPv4 IP, and they made the CGNAT IP static.

Thank you, I needed a good laugh today, that is amazing!


> The main issue with IPv6 seems to be IPv6 proponents that try to kill IPv4, no one will migrate if you force them to, if you propose, we will consider.

My experience is more the opposite. I keep seeing people say things like "I don't do v6 at home because I don't need it". These people are outright telling us that they're not going to start using v6 unless we make them need it.

Note that I didn't say "migrate to" v6. They're not even willing to do the first step of that ("start using v6"), even with no pressure to do the last step ("stop using v4").

I read an anecdote from Facebook that they had huge trouble getting their developers to stop writing v4-only code. Eventually they ended up removing v4 from their developer machines, who all of a sudden were able to write v6-capable code -- and it didn't take long for them to start asking when they could drop support for v4.

People will moan and moan and moan about v6 until you make them use it, at which point they discover that it was never as bad as they imagined it being.


So you admit that IPv6 people routinely create the problem if it doesn't exist. Maybe there's some nuance where you need to go backwards in order to go forwards?

In any case it's not relevant to the case from the root comment, since the ISP doesn't offer IPv6. IPv6 folk are siding with the ISP here or getting distracted with IPv6.

Essentially IPv6 people are delusional about the state of support of the tech and the extent of issues it brings, there's regions where there's no IPv6 support, so when a network with IPv4 has an IP related problem, IPv6 folk will blame it on IPv4 even if it's entirely unrelated, even if the infrastructure isn't even at dual-stack phase.

One of the thing the ISP did was try to upgrade the connection from copper to fiber optics, like instead of understanding the issue, "let's just try upgrading from your OLD technology which is OUTDATED, no wonder you were having issues? Also have you tried turning it off an on again that helps? Talk to you tomorrow.". IPv6 guys so far have been a distraction, get walmart to run their website on IPv6 before you push it to a hospital in southamerica who is having downtime.


No? It wouldn't be taking this long if they could do that.

The problem in this thread stems entirely from v4: they're being moved onto CGNAT (which is NATed v4), because the v4 address space is exhausted, and this is only a problem because the hospital relies completely on v4. None of these problems were created by "IPv6 people". The IPv6 people created the thing that solves these problems.

This hospital has had twenty years to gradually move things over to v6 which would have rendered the CGNAT a non-issue, but instead they've done zero work towards that and are completely unprepared to deal with the realities of v4 running out. Had they been forced to use v6, they would've be fine.

> when a network with IPv4 has an IP related problem, IPv6 folk will blame it on IPv4 even if it's entirely unrelated, even if the infrastructure isn't even at dual-stack phase.

Another opposite. What usually happens is that IPv6 gets blamed for any network problems, even on networks that don't use it.

I've seen people run software that failed to connect to a server's v4 address over a v4-only network due to broken v4, that have then blamed v6 for the problem. The error message from the software was somewhat misleading (it only prints the last connection failure instead of all of them), but even so.

It's usually the people not doing v6 that are delusional about it. Even on HN there's a steady stream of people complaining that v6 didn't do <thing that v6 did do> or that it's impossible to do <thing that's possible to do in v6>.

I do realize that you're likely to hit bugs or lacking support or something somewhere or another, but that's what the past twenty years of gradual transition were for. We've all put a ton of effort into buying you more time to figure this stuff out in. If you squandered all that time and then need to deal with everything after it becomes a big emergency, that's not v6's fault.

> get walmart to run their website on IPv6 before you push it to a hospital in southamerica who is having downtime.

If you wanted a nice orderly transition, you needed to start doing it earlier. Instead everybody is fighting to be the last person to transition, and you probably won't be able to beat Walmart on that fight.


I will reiterate, the ISP does not offer IPv6

Have you noted that in the mainline Linux build config file, the option to enable IPv4 functionality is CONFIG_LEGACY_IP= ?

I can tell you that in cicd for production Linux systems today, we have

  CONFIG_LEGACY_IP=""
which in a Linux build config file means "do not include this in the build".

_

What might work well for your organization is ZeroTier which will make you immune to what any ISPs do. The downside is your organization would be dependent on ZeroTier, but ZeroTier is much less likely to screw you over than any ISP.

  https://www.zerotier.com/
_

I appreciate your speculation on the principles of contract law. Like you, I believe those principles should be upheld and I believe in morality. If you lived under a monarchy and I were of the monarch, I would cross-examine your ISP in public and solve your problem in minutes. I would also on occasion take someone to the side of the road and chop off their head in front of the entire village, and everyone would know on a visceral level they are all much better off with someone taking out the trash now and then.

But, as many technical workers know, the contract stuff takes months or years to resolve, and technical issues involving IP addresses are best worked around with technical approaches.

_

What I would suggest your network team (you and whoever) do in your shoes is:

- set up NAT64 and DNS64 at the edges of subnets that contain devices that don't do IPv6 properly, because if these devices do not have updates to do IPv6 properly then they are broken in a fundamental way, and a workaround is necessary;

- dictate that starting on December 1st, all new devices and VMs have IPv6 addresses with all userspace services listening on IPv6 addresses or some nftables rule to kludge IPv6:$port -> 127.0.0.1:$port if necessary, with firewall configured to block that IPv6 traffic, then at a later date firewalls not blocking those IPv6 addresses, then at a later date prohibit any new IPv4 addresses being assigned anywhere with special exception to devices tagged "legacy" or "end of life" requiring documentation of such;

- use a combination of IPv6 GUA addresses assigned by whatever ISP and IPv6 ULA addresses chosen by your team -- in IPv6, multiple local gateways and multiple addresses on a network interface issued by those local gateways via RA is relatively a norm rather than an exception (requires userspace tooling in IPv4, DHCP doesn't have this functionality), so leverage this advantage;

- use IPv6 AH (authenticated headers) wherever possible;

- because in an ideal world, ISPs would behave consistently and IPv6 GUA addresses would always be stable, but we aren't living in an ideal world, so be ready to update your internal DNS to drop AAAA records containing IPv6 GUA that an upstream ISP fumbled;

- or, if you have the internal resources, register your own AS and command your own official block of IPv6 addresses;

- use a combination of OpenTOFU (Terraform) and Salt or Ansible, all versioned with Git, be very strict with your team about versioning with Git, to manage everything, and use

  terraform plan -detailed-exitcode
and Salt or Ansible equivalents for continuous monitoring;

- move userspace services to Podman where possible.

Personally I like Salt. I know Ansible is more popular out there with more inertia.

_

>> why are we normalizing the removal of IPv4 addresses?

This was normalized a long time ago actually. "The future is already here, it's just not evenly distributed".

You and I are total strangers on different corners of the globe. You may not like what you're about to read, but it's better that you get a hint where the wind is blowing sooner than not.

If my team were consulting with your organization's execs and we caught a hint that the existing internal resources were not already proactively staying current with internet protocol (which is IPv6), we would point out there is urgency to start right away with emphasis that the existing internal team is over two decades behind staying current.

Or, if a detected hint the internal team were at all resistant to IPv6, we would advise the executive team to start developing a plan to flush out the replacements for the internal team ASAP.

Many network engineers at many ISPs would gladly drop all IPv4 traffic if they thought they could get away with it.

IPv6 only seems more complicated if you still need to unlearn IPv4. IPv6 does have a steeper learning curve, but once that learning curve is overcome, IPv6 is actually much simpler than IPv4. More people than not don't like reading RFCs, but professionals do slowly read RFCs on their own time.


Thanks, I'll take a look into the recommended protocols.

One clarification I'd like to make is that IPv6 is not offered, I can only get IPv4 addresses through the ISP DHCP, there is no ipv6 being offered with command 'dhclient -6' for example on linux, neither does window pick any ipv6 up so it doesn't seem to be an us problem.

It's often that Argentinians miss nuances when copying ethical gray areas from the Americans, and without those slight nuances the debate often gets mixed up with a much more subtle debate.

To make a parallel, Trump issued a memecoin days before entering office, it wasn't technically while being president, it was a memecoin so there was no underlying asset, a gray area, see? America.

Now Milei saw and culted the cargo, he made a coin during his office mandate, and he mentioned it would be used to fund Argentina tech projects, so it's an unregulated security. The nuances are lost, and it's just plain bad.

EDIT1:

>Or, if a detected hint the internal team were at all resistant to IPv6, we would advise the executive team to start developing a plan to flush out the replacements for the internal team ASAP.

>we would point out there is urgency to start right away with emphasis that the existing internal team is over two decades behind staying current.

I appreciate the candor

>You and I are total strangers on different corners of the globe.

This is true and it might impact the nuances and extra-technical semantics of the protocol. For example, in here dropping IPv4 support might mean dropping support for older devices, which might be less common in America, ISPs might not support it, so it's not just about the device but the network, to give you an idea I just got off the phone with the ISP which is THE biggest ISP in Argentina, they don't offer IPv6, period.

>If my team were consulting with your organization's execs

Here might be a big disconnect, my organization execs would probably be way out of budget for whatever your org may charge, that would never happen.

If you want to point the salesmen of your org to try and stir some shit up like that with the ISP, then that may make a bit more sense, the budgets may align for importing American consulting, and berating a big org chart that includes engineers might make more sense than trying to replace a 'team' of 1 or 2 fractionalist generalist IT guys on <500$ month contracts.

The ISP brand is Personal, local corp is Telecom Argentina S.A, Asynchronous System Number AS7303, trades as TEO in NYSE I think, owned by Grupo Clarin which comes is a traditional Media and news company. IPv6 is not offered to consumers right now.

>we would advise the executive team to start developing a plan to flush out the replacements for the internal team ASAP.

go nuts


Everything I am suggesting here is what an internal team with full ownership of the network should do. An external team could chisel little by little, and progress the network in phases.

What is shared here is a general direction. I am sure some people I know where all they do is networking could tell me harshly some of these ways could be done better, and often these people are right ; but sometimes these same people are actually wrong and don't fully consider the positions of people in IT roles at companies that aren't ISPs.

All suggested below is not necessarily the ultimate way but a general direction.

_

>> can only get IPv4 addresses through the ISP DHCP

ISP-owned IP addresses, either of legacy IP or IPv6, are capricious and can suddenly change, as you experienced recently.

I suggest to adopt a mindset of "our network" and "their network", rather than functionally have your network be a passive extension of their network by using their IP addresses.

The router announcements (IPv6 RA) or DHCP (IPv4) for any IP addresses within your network should always be issued by devices controlled solely by our organization.

NAT64 and tunnels exist, any upstream ISP is not a blocker.

Modern Linux has eBPF and eXpress Data Path. Both Linux and FreeBSD (use HardenedBSD if you can) have DPDK. They can make for surprisingly high performance edge routers on x86_64 server boxes over a decade old, exceeding what most campuses or even datacenter footprints actually need and at low cost. Even without eBPF & XDP or DPDK, these on x86_64 are often "good enough" for router and firewall.

DNS running on these or adjacent boxes internal to the organization is essential.

The addresses at the gateways, either of IPv4 or IPv6, can be made highly available with VRRPv3.

IPv6 has an elegant way to handle multiple upstream ISPs without VRRP or CARP at the gateways, but even Linux is just recently implementing what may only be a piece of them (the BSDs will later), some mention of them here https://news.ycombinator.com/item?id=50143420

_

What I would do, which is opinionated so I'm not necessarily suggesting others do it, assuming tunneling will be involved: if the organizational wherewithal is there to register an AS and do BGP, is pay the AUD 500 fee to register an AS and have a chunk of IPv6 space for to use IPv6 GUA addresses that officially belong to the organization.

If not, which is often enough the case because we know how some organizations can be slow (not making any assumptions about your's), the remaining avenue is to use IPv6 ULA addresses which are the spiritual counterpart to IPv4 RFC1918 addresses.

You can embed MAC addresses in IPv6 ULA addresses, like the MAC 82c6.7943.acb2 put in an IPv6 like

  fc00:5007:6525:2001:3003:82c6:7943:acb2
and use DHCPv6 to always assign a specific IPv6 ULA address to a specific MAC address, where you have thought through the potential information-disclosure implications and you are certain you want to do that.

Then I would use IPv4-only ISP paths for what they're good for: dumb paths to tunnel IPv6 packets to where there is proper internet.

For the option with an AS, BGP announcements on the other side of the tunnel. Personally I would do SCION on the gateways and out the other side of the tunnel, but you don't want to do SCION unless you are also crazy (like a fox).

For the IPv6 ULA option, PAT which is the spiritual counterpart to IPv4's NAT but is also technologically simpler.

With IPv6 ULA and no tunneling, NAT64 and DNS64 can work for outbound.

Site to site tunnels will be tricky no matter what. Tailscale, ZeroTier, Netbird, and similar may be able to do much of the work for you ; these should run in a DMZ on another side of a router/firewall that filters the appropriate IPv6 ULA prefixes.

I would try to see if I could make vanilla Wireguard work with NAT traversal techniques using some cloud-hosted VMs that help with the "hole punching", but not everyone would do that.

There aren't many options that will all work well but almost always more than one option that can work well, all subject to the specific site and inter-organizational resources.

_

>> dropping IPv4 support might mean dropping support for older devices

For as long as it makes organizational sense to continue using these devices, put them behind an OpenBSD box that performs NAT46 and DNS46, with IPv4 addresses statically mapped to IPv6 addresses, maybe ones that contain the MAC addresses of the devices.

With Salt or Ansible, such a scheme with NAT, DNS, DHCP configuration may all be templatized and in perfect alignment, and is scalable.

Authoritative inventory of canonical identifiers/names versioned with Git, what Ansible calls "inventory", is imperative.

Sometimes this looks like a couple of old x86_64 boxes doing CARP (similar to VRRP) on the IPv4 side for a few dozen or couple hundred devices downstream.

Sometimes this looks like, in a handful of distant corners of the larger network, a cheap single-board computer between a single device and the rest of the network ; without a wifi chip or the wifi chip removed by heating (board-repair style), unless downstream of a wifi AP.

_

>> the ISP which is THE biggest ISP in Argentina, they don't offer IPv6 >> The ISP brand is Personal, local corp is Telecom Argentina S.A, Asynchronous System Number AS7303, trades as TEO in NYSE I think, owned by Grupo Clarin which comes is a traditional Media and news company.

I can think of some service provider network engineers that would gladly drop all of Argentina's IPv4 off the entire internet and "IPv6 prefix announcements welcome", if the business sides would let them do it.

Something like this will probably start happening sooner than people think.


>I can think of some service provider network engineers that would gladly drop all of Argentina's IPv4 off the entire internet and "IPv6 prefix announcements welcome", if the business sides would let them do it.

Yes, there's no shortage of employees that would vote to reduce their workload by removing their service offering, if you ask a physician here if the hospital should stop taking patients of X type, they'd be onboard, less work for them.

It's a dream though, try to make an AAAA request for any website, it's not there, even government websites.

>Something like this will probably start happening sooner than people think.

I'm even trying american companies, like citi.com, walmart.com, there's no AAAA records there.

>For as long as it makes organizational sense to continue using these devices, put them behind an OpenBSD box that performs NAT46 and DNS46, with IPv4 addresses statically mapped to IPv6 addresses, maybe ones that contain the MAC addresses of the devices.

This is an external facing service, so we don't control the devices or routes that patients and external physicians will be accessing the website.

>Tunneling

Yeah, I'm going to go this route, IPv4 tunnel, it's a horrible hack, but this is hacker news after all.


Almost all large companies in the US are on IPv6 and more of the smaller companies are on IPv6 than not.

If your device isn't able to reach 2606:4700:4700::1111, try using the DNS server 1.1.1.1

and run this bash command:

  for  USCompany  in    apple akamai att berkshire bestbuy boeing bofa burgerking cnn chase chevron citi comcast costco cvs dell disney fedex fidelity gatorade google goldmansachs gopro hellofresh hilton homedepot infowars in-n-out jcpenny johnsonandjohnson kaiser kroger lulumon macys mcdonalds microsoft nike pepsi petco radioshack safeway shell southwest sprouts statefarm tacobell target tesla traderjoes ups usbank uschamber walgreens walmart wellsfargo wholefoods yahoo    aquantuo atlanticseafarms beehivemeals beetlesplumbing dynamicautomotive jamies-farm joeandbella jovyco privacy4cars prosperityehr redroostercoffee resortlifecarts sproutlabs tradedesignbuild 
  do
    echo ${USCompany}
    dig +short aaaa www.${USCompany}.com
    echo  ; done

and this one too

  for  USent  in    cia congress dhs epa ice fbi fcc nasa nsa whitehouse
  do
    echo ${USent}
    dig +short aaaa www.${USent}.gov
    echo  ; done

Then maybe call up your ISP and rant about them allowing your country to devolve into some 3rd world shit hole stuck on legacy IP and over two decades behind the Western countries.

Argentina deserves better!


>If your device isn't able to reach 2606:4700:4700::1111, try using the DNS server 1.1.1.1

We run a public facing server, we aren't going to ask patients and external physicians to configure a DNS or run a (linux) script

>Then maybe call up your ISP and rant

You wouldn't be surprised how unhelpful and unfun that is


  user@host:~$ dig +short  aaaa  www.citi.com
  san.www.citi.com.edgekey.net.
  e16976.x.akamaiedge.net.

  user@host:~$ dig +short  aaaa  www.walmart.com
  www.walmart.com.cdn-wal.net.
You should run the commands yourself, not your end users. Obvio.

those are CNAMEs not AAAA, and the CNAME chain doesn't end up resolving to IPv6, only IPv4.

Yeah I had later noticed that too. Much of the US companies do end up resolving to IPv6.

100% of the aforementioned US gov domains resolve to IPv6.

More 5G networks than not are using IPv6 and 464xlat. Many ISPs are IPv6 only too so closer to half the time than not there are IPv6 packets to reach to those IPv4 addresses.

  $   for  USCompany  in    apple akamai att berkshire bestbuy boeing bofa burgerking cnn chase chevron citi comcast costco cvs dell disney fedex fidelity gatorade google goldmansachs gopro hellofresh hilton homedepot infowars in-n-out jcpenny johnsonandjohnson kaiser kroger lulumon macys mcdonalds microsoft nike pepsi petco radioshack safeway shell southwest sprouts statefarm tacobell target tesla traderjoes ups usbank uschamber walgreens walmart wellsfargo wholefoods yahoo    aquantuo atlanticseafarms beehivemeals beetlesplumbing dynamicautomotive jamies-farm joeandbella jovyco privacy4cars prosperityehr redroostercoffee resortlifecarts sproutlabs tradedesignbuild 
    do
      echo ${USCompany}
      dig +short aaaa www.${USCompany}.com
      echo  ; done
  apple
  www-apple-com.v.aaplimg.com.
  www.apple.com.edgekey.net.
  e6858.dsce9.akamaiedge.net.
  2600:1406:3a00:493::1aca
  2600:1406:3a00:492::1aca
  2600:1406:3a00:494::1aca
  2600:1406:3a00:486::1aca
  2600:1406:3a00:48a::1aca
  
  akamai
  www.akamai.com.edgekey.net.
  2600:1406:2e00:49::172e:d8cf
  2600:1406:2e00:49::172e:d8c6
  
  att
  prod-www.zr-att.com.akadns.net.
  cac2.m.att.com.edgekey.net.
  e11697.cd.akamaiedge.net.
  
  berkshire
  3tfzq88u2cbx.wpeproxy.com.
  
  bestbuy
  www.bestbuy.com.edgekey.net.
  e5816.x.akamaiedge.net.
  
  boeing
  d1pt7e7bvjlgwo.cloudfront.net.
  2600:9000:24bc:7a00:16:a4e1:f600:93a1
  2600:9000:24bc:3600:16:a4e1:f600:93a1
  2600:9000:24bc:b400:16:a4e1:f600:93a1
  2600:9000:24bc:e000:16:a4e1:f600:93a1
  2600:9000:24bc:6e00:16:a4e1:f600:93a1
  2600:9000:24bc:be00:16:a4e1:f600:93a1
  2600:9000:24bc:fc00:16:a4e1:f600:93a1
  2600:9000:24bc:c000:16:a4e1:f600:93a1
  
  bofa
  redirect.ecglb.bac.com.
  
  burgerking
  prod-bk-us-web.com.rbi.tools.
  
  cnn
  cnn-tls.map.fastly.net.
  2a04:4e42:200::773
  2a04:4e42:400::773
  2a04:4e42:600::773
  2a04:4e42::773
  
  chase
  gtm.www.chase.com.akadns.net.
  www.chase.com.edgekey.net.
  e129412.a.akamaiedge.net.
  
  chevron
  www-afd-b9aycqabggbkcsdt.z01.azurefd.net.
  mr-z01.tm-azurefd.net.
  2603:1061:14:95::1
  
  citi
  san.www.citi.com.edgekey.net.
  e16976.x.akamaiedge.net.
  
  comcast
  www.comcast.com.edgekey.net.
  e523.dscb.akamaiedge.net.
  2600:1406:3a00:482::20b
  2600:1406:3a00:48d::20b
  
  costco
  costco.map.fastly.net.
  
  cvs
  www.cvs.edgekey.net.
  e5769.x.akamaiedge.net.
  
  dell
  www1.dell-cidr.akadns.net.
  cdn-www.dell.com-v2.edgekey.net.
  e13665.x.akamaiedge.net.
  
  disney
  www-cdn.matterhorn.app.
  
  fedex
  www.fedex.com.akadns.net.
  cidr.fedex.com.akadns.net.
  ipv6www.fedex.com.edgekey.net.
  e111296.dsca.akamaiedge.net.
  2600:1406:2e00:49::172e:d8cc
  2600:1406:2e00:49::172e:d8c8
  2600:1406:2e00:49::172e:d8d0
  2600:1406:2e00:49::172e:d8ca
  2600:1406:2e00:49::172e:d8c4
  
  fidelity
  www.fidelity.com.edgekey.net.
  e94446.x.akamaiedge.net.
  
  gatorade
  2606:4700:4409::ac40:9261
  2a06:98c1:3105::6812:299f
  
  google
  2001:4860:482d:7700::
  2001:4860:482a:7700::
  2001:4860:4828:7700::
  2001:4860:4827:7700::
  2001:4860:482c:7700::
  2001:4860:4826:7700::
  2001:4860:4829:7700::
  2001:4860:482b:7700::
  
  goldmansachs
  www.gs.com.
  www.gs.com.edgekey.net.
  e17133.x.akamaiedge.net.
  
  gopro
  d1h7n50c10z72v.cloudfront.net.
  2600:9000:201e:6800:17:765c:a5c0:93a1
  2600:9000:201e:4c00:17:765c:a5c0:93a1
  2600:9000:201e:a200:17:765c:a5c0:93a1
  2600:9000:201e:2400:17:765c:a5c0:93a1
  2600:9000:201e:a800:17:765c:a5c0:93a1
  2600:9000:201e:fe00:17:765c:a5c0:93a1
  2600:9000:201e:ca00:17:765c:a5c0:93a1
  2600:9000:201e:c200:17:765c:a5c0:93a1
  
  hellofresh
  www.hellofresh.com.cdn.cloudflare.net.
  2606:4700:4409::6812:209d
  2a06:98c1:3106::ac40:9b63
  
  hilton
  www.hilton.com.edgekey.net.
  e2904.dscx.akamaiedge.net.
  2600:1406:2e00:49a::b58
  2600:1406:2e00:4a3::b58
  
  homedepot
  www.homedepot.com.edgekey.net.
  e301254.x.akamaiedge.net.
  
  infowars
  2606:4700:10::6814:1a60
  2606:4700:10::ac42:9d27
  
  in-n-out
  sw6cs.x.incapdns.net.
  
  jcpenny
  www.jcpenny.com.edgesuite.net.
  a1441.b.akamai.net.
  
  johnsonandjohnson
  prod.jnj.psdops.com.
  
  kaiser
  kaiser.com.
  2001:1ab0:7e1e:151::58
  
  kroger
  www.kroger.com.edgekey.net.
  e8023.a.akamaiedge.net.
  
  lulumon
  lulumon.com.
  
  macys
  www.macys.com.edgekey.net.
  e5791.a.akamaiedge.net.
  
  mcdonalds
  direct-san.mcdonalds.com.edgekey.net.
  e179224.a.akamaiedge.net.
  
  microsoft
  www.microsoft.com-c-3.edgekey.net.
  e13678.dscb.akamaiedge.net.
  2600:1406:3a00:487::356e
  2600:1406:3a00:486::356e
  2600:1406:3a00:497::356e
  2600:1406:3a00:481::356e
  2600:1406:3a00:482::356e
  
  nike
  www.nike.com-v1.edgekey.net.
  e2785.x.akamaiedge.net.
  
  pepsi
  g2wh497.x.incapdns.net.
  
  petco
  2a06:98c1:3108::6812:20c7
  2a06:98c1:310a::ac40:9b39
  
  radioshack
  prod.magentocloud.map.fastly.net.
  2a04:4e42::380
  2a04:4e42:200::380
  2a04:4e42:400::380
  2a04:4e42:600::380
  
  safeway
  htu5x69.x.incapdns.net.
  
  shell
  www.nic.shell.edgekey.net.
  e200089.dscb.akamaiedge.net.
  2600:1406:3a00:33::170b:cfef
  2600:1406:3a00:33::170b:cfe6
  
  southwest
  www.southwest.com.edgekey.net.
  e7466.a.akamaiedge.net.
  
  sprouts
  2606:4700:10::ac42:9705
  2606:4700:10::6814:2445
  
  statefarm
  statefarm.edgekey.net.
  e124943.a.akamaiedge.net.
  
  tacobell
  www.tacobell-prod.com.edgekey.net.
  e78335.b.akamaiedge.net.
  
  target
  sites.target.map.fastly.net.
  
  tesla
  www.tesla.com.edgekey.net.
  e1792.dscx.akamaiedge.net.
  2600:1406:3a00:291::700
  2600:1406:3a00:280::700
  2600:1406:3a00:293::700
  2600:1406:3a00:290::700
  2600:1406:3a00:296::700
  
  traderjoes
  www.traderjoes.com.edgekey.net.
  e4528.b.akamaiedge.net.
  
  ups
  ev.ups.com.akadns.net.
  ev2b.ups.com.edgekey.net.
  e13626.dsca.akamaiedge.net.
  2600:1406:2e00:986::353a
  2600:1406:2e00:98b::353a
  2600:1406:2e00:983::353a
  2600:1406:2e00:984::353a
  
  usbank
  www.usbank.com.edgekey.net.
  e374753.a.akamaiedge.net.
  
  uschamber
  uschamber.map.fastly.net.
  
  walgreens
  walgreens.com.edgekey.net.
  e36070.dsca.akamaiedge.net.
  2600:1406:2e00:20::45c0:8be8
  2600:1406:2e00:20::45c0:8bda
  
  walmart
  www.walmart.com.cdn-wal.net.
  
  wellsfargo
  www.wellsfargo.com.edgekey.net.
  e82164.b.akamaiedge.net.
  
  wholefoods
  2600:9000:25ef:c800:8:df9e:eb80:93a1
  2600:9000:25ef:e000:8:df9e:eb80:93a1
  2600:9000:25ef:7400:8:df9e:eb80:93a1
  2600:9000:25ef:6400:8:df9e:eb80:93a1
  2600:9000:25ef:ca00:8:df9e:eb80:93a1
  2600:9000:25ef:9e00:8:df9e:eb80:93a1
  2600:9000:25ef:5400:8:df9e:eb80:93a1
  2600:9000:25ef:fa00:8:df9e:eb80:93a1
  
  yahoo
  me-ycpi-cf-www.g06.yahoodns.net.
  2001:4998:18:800::4003
  2001:4998:18:800::4002
  
  aquantuo
  2606:4700:20::681a:2e
  2606:4700:20::681a:12e
  2606:4700:20::ac43:4547
  
  atlanticseafarms
  2606:4700:3033::6815:4581
  2606:4700:3035::ac43:d0b4
  
  beehivemeals
  beehivemeals.myshopify.com.
  shops.myshopify.com.
  2620:127:f00f:e::
  
  beetlesplumbing
  s.multiscreensite.com.
  global.multiscreensite.com.
  a3c02b2530d6f27ca.awsglobalaccelerator.com.
  
  dynamicautomotive
  dynamicautomotive.com.
  
  jamies-farm
  shops.myshopify.com.
  2620:127:f00f:e::
  
  joeandbella
  joebella.myshopify.com.
  shops.myshopify.com.
  2620:127:f00f:e::
  
  jovyco
  jovy-brand.myshopify.com.
  shops.myshopify.com.
  2620:127:f00f:e::
  
  privacy4cars
  2606:4700:20::681a:dca
  2606:4700:20::ac43:4af6
  2606:4700:20::681a:cca
  
  prosperityehr
  2606:4700:10::6814:2f68
  2606:4700:10::ac42:94bd
  
  redroostercoffee
  cname.vercel-dns.com.
  
  resortlifecarts
  sprod-dnn-gce6a8hab5g5bkf6.a03.azurefd.net.
  mr-a03.tm-azurefd.net.
  2603:1061:14:99::1
  
  sproutlabs
  cdn.webflow.com.
  2620:cb:2000::1
  
  tradedesignbuild
  ext-sq.squarespace.com.



  $   for  USent  in    cia congress dhs epa ice fbi fcc nasa nsa whitehouse
    do
      echo ${USent}
      dig +short aaaa www.${USent}.gov
      echo  ; done
  cia
  cia.gov.edgekey.net.
  e10004744.dsca.akamaiedge.net.
  2600:1406:3a00:33::170b:cfeb
  2600:1406:3a00:33::170b:cff2
  
  congress
  2606:4700:4402::ac40:90ce
  2a06:98c1:3109::6812:2b32
  
  dhs
  www.dhs.gov.edgekey.net.
  e6485.dsca.akamaiedge.net.
  2600:1406:2e00:98b::1955
  2600:1406:2e00:983::1955
  
  epa
  d32i4z0dxazdtp.cloudfront.net.
  2600:9000:201e:a600:10:f3db:af40:93a1
  2600:9000:201e:f400:10:f3db:af40:93a1
  2600:9000:201e:6000:10:f3db:af40:93a1
  2600:9000:201e:c400:10:f3db:af40:93a1
  2600:9000:201e:b600:10:f3db:af40:93a1
  2600:9000:201e:d200:10:f3db:af40:93a1
  2600:9000:201e:d600:10:f3db:af40:93a1
  2600:9000:201e:6400:10:f3db:af40:93a1
  
  ice
  www.ice.gov.edgekey.net.
  e6485.dsca.akamaiedge.net.
  2600:1406:2e00:98b::1955
  2600:1406:2e00:983::1955
  
  fbi
  www.fbi.gov.cdn.cloudflare.net.
  2606:4700::6810:94f4
  2606:4700::6810:95f4
  
  fcc
  www.fcc.gov.edgekey.net.
  e4909.dscb.akamaiedge.net.
  2600:1406:3a00:484::132d
  2600:1406:3a00:497::132d
  
  nasa
  nasa-gov.go-vip.net.
  2a04:fa87:fffd::c000:426c
  
  nsa
  nsa.gov.edgekey.net.
  e16248.dscb.akamaiedge.net.
  2600:1406:3a00:487::3f78
  2600:1406:3a00:496::3f78
  
  whitehouse
  wh47.go-vip.net.
  2a04:fa87:fffd::c000:4233

If the www. is prefixed or not, results for domains of Argentina differ. The results aren't almost-perfect like US, but IPv6 is apparently already somewhat prevalent in Argentina.

The list from ChatGPT:

"This 2026 list ranks organizations by LinkedIn employee count, not revenue, and includes public bodies and universities as well as companies. I’ve kept the listed order; entries without a domain in the source are omitted."

  $ for argdo in $(cat arg2) ; do echo $argdo ; dig +short aaaa $argdo  ;  echo ; done
  www.tytconsultores.com.ar
  
  www.mercadolibre.com
  a35f64fceb718ad27.awsglobalaccelerator.com.
  
  www.es.wikipedia.org
  
  www.dyna.wikimedia.org.
  
  www.techintgroup.com
  fdcomm01-egdmdkhuhfbgb9gx.z01.azurefd.net.
  mr-z01.tm-azurefd.net.
  2603:1061:14:90::1
  
  www.cencosud.com
  www.cencosud.com.cdn.cloudflare.net.
  2606:4700::6812:247
  2606:4700::6812:347
  
  www.ypf.com
  ypf.com.
  
  www.gob.ar
  
  www.uba.ar
  aijewx4.ng.impervadns.net.
  
  www.coto.com.ar
  
  www.somosjob.ar
  somosjob.ar.
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.telecom.com.ar
  
  www.arcor.com
  arcor.P0585910867.fortiwebcloud.net.
  lb-3.us-east-1.aws.waas-online.net.
  
  www.techint.com
  techintcomprd.azurewebsites.net.
  waws-prod-cq1-003.sip.azurewebsites.windows.net.
  waws-prod-cq1-003.brazilsouth.cloudapp.azure.com.
  
  www.abc.gob.ar
  
  www.century21.com.ar
  
  www.uca.edu.ar
  
  www.galicia.ar
  
  www.osde.com.ar
  
  www.elalmacen.tv
  cdn3.wixdns.net.
  cfd.wixdns.net.
  
  www.carrefour.com.ar
  2a06:98c1:3108::ac40:9379
  2a06:98c1:3108::6812:2887
  
  www.unlp.edu.ar
  2800:340:0:64::135
  
  www.somosfarmacity.com
  farmacitybr02-bzf9h8a2fmbbfyeb.z01.azurefd.net.
  mr-z01.tm-azurefd.net.
  2603:1061:14:97::1
  
  www.hospitalitaliano.org.ar
  
  www.andreani.com
  www.andreani.com.cdn.cloudflare.net.
  2606:4700::6812:161a
  2606:4700::6812:171a
  
  www.mostazaweb.com.ar
  
  www.aesa.com.ar
  aesa.com.ar.
  
  www.claroempleos-aup.com
  
  www.swissmedical.com.ar
  swissmedical.com.ar.
  
  www.unc.edu.ar
  2801:120:842::5
  2801:120:842::4
  2801:120:842::6
  
  www.bbva.com.ar
  www.bbva.com.ar.edgekey.net.
  e6251.a.akamaiedge.net.
  
  www.bna.com.ar
  bna.com.ar.
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.accenture.com
  4229prod2cf.r53cioaccenturecloud.net.
  d13iavm24b37u0.cloudfront.net.
  2600:9000:25f2:0:d:5159:5a00:93a1
  2600:9000:25f2:7e00:d:5159:5a00:93a1
  2600:9000:25f2:bc00:d:5159:5a00:93a1
  2600:9000:25f2:2600:d:5159:5a00:93a1
  2600:9000:25f2:2e00:d:5159:5a00:93a1
  2600:9000:25f2:9000:d:5159:5a00:93a1
  2600:9000:25f2:6a00:d:5159:5a00:93a1
  2600:9000:25f2:ca00:d:5159:5a00:93a1
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.aerolineas.com.ar
  
  www.bancoprovincia.com.ar
  
  www.ocasa.com
  ocasa.com.
  
  www.macro.com.ar
  
  www.arca.gob.ar
  
  www.laanonima.com.ar
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.naranjax.com
  2a06:98c1:3105::ac40:95eb
  2606:4700:440b::6812:2615
  
  www.informeg.com.ar
  informeg.com.ar.
  
  www.gruposancorseguros.com
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.pecomenergia.com
  dam5tpv20rcp8.cloudfront.net.
  
  www.santander.com.ar
  www.santander.com.ar.edgekey.net.
  e90036.dscb.akamaiedge.net.
  2600:1406:2e00:28::17cb:a618
  2600:1406:2e00:28::17cb:a60d
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.2606:4700:20::681a:4b7
  
  www.2606:4700:20::681a:5b7
  
  www.2606:4700:20::ac43:4b23
  
  www.unr.edu.ar
  
  www.utn.edu.ar
  
  www.cerveceriaymalteriaquilmes.com
  ug2aj8e.x.incapdns.net.
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.adecoagro.com
  hostweb.adecoagro.com.
  
  www.mendoza.edu.ar
  
  www.veronicapalermo.com.ar
  
  www.uncuyo.edu.ar
  
  www.toyota.com.ar
  d14rtqisu6jdh1.cloudfront.net.
  2600:9000:211f:7800:e:6ac2:3d40:93a1
  2600:9000:211f:c800:e:6ac2:3d40:93a1
  2600:9000:211f:2600:e:6ac2:3d40:93a1
  2600:9000:211f:b200:e:6ac2:3d40:93a1
  2600:9000:211f:3200:e:6ac2:3d40:93a1
  2600:9000:211f:7400:e:6ac2:3d40:93a1
  2600:9000:211f:6800:e:6ac2:3d40:93a1
  2600:9000:211f:a600:e:6ac2:3d40:93a1
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.uade.edu.ar
  
  www.diaonline.supermercadosdia.com.ar
  
  www.pan-energy.com
  
  www.sancorsalud.com.ar
  
  www.ar.linkedin.com
  
  www.cctld.linkedin.com.
  
  www.cctld.es.lnkdns.net.
  
  www.www.linkedin.com.cdn.cloudflare.net.
  
  www.rosario.gob.ar
  websrv2.rosario.gob.ar.
  
  www.mpf.gob.ar
  
  www.aysa.com.ar
  aysa.com.ar.
  
  www.uai.edu.ar
  alb-virt02-umbraco-503988087.us-east-1.elb.amazonaws.com.
  
  www.hospitalsanjuandedios.org.ar
  
  www.telecentro.com.ar
  
  www.nadro.mx
  d1j9d2nbk27vjw.cloudfront.net.
  2600:9000:21dd:8a00:3:847:5f00:93a1
  2600:9000:21dd:7400:3:847:5f00:93a1
  2600:9000:21dd:4200:3:847:5f00:93a1
  2600:9000:21dd:5a00:3:847:5f00:93a1
  2600:9000:21dd:1000:3:847:5f00:93a1
  2600:9000:21dd:fa00:3:847:5f00:93a1
  2600:9000:21dd:7c00:3:847:5f00:93a1
  2600:9000:21dd:200:3:847:5f00:93a1
  
  www.usal.edu.ar
  
  www.hospitalaleman.org.ar
  22pt6nf.impervadns.net.
  
  www.pluspetrol.net
  environmental-longan-72bw7rzlnwqdk0vjpbrlycnz.herokudns.com.
  
  www.edenor.com
  d14d07xru8rz5.cloudfront.net.
  2600:9000:21dd:f800:10:d7ce:6840:93a1
  2600:9000:21dd:9a00:10:d7ce:6840:93a1
  2600:9000:21dd:9600:10:d7ce:6840:93a1
  2600:9000:21dd:aa00:10:d7ce:6840:93a1
  2600:9000:21dd:8a00:10:d7ce:6840:93a1
  2600:9000:21dd:6600:10:d7ce:6840:93a1
  2600:9000:21dd:4c00:10:d7ce:6840:93a1
  2600:9000:21dd:6400:10:d7ce:6840:93a1
  
  www.cge.entrerios.gov.ar
  
  www.supervielle.com.ar
  
  www.pwc.com.ar
  www.pwc.com.ar.edgekey.net.
  e675.x.akamaiedge.net.
  
  www.mdp.edu.ar
  proxy.mdp.edu.ar.
  
  www.hospitalbritanico.org.ar
  ambitious-field-049c5d310.1.azurestaticapps.net.
  azurestaticapps1.trafficmanager.net.
  msha-slice-1-wus2-0.msha-slice-1-wus2-0-ase.p.azurewebsites.net.
  waws-prod-mwh-a269a7b8.sip.p.azurewebsites.windows.net.
  
  www.edu.ar
  
  www.gov.ar
  
  www.gdmseeds.com
  wp.wpenginepowered.com.
  
  www.iosfa.gob.ar
  2606:4700:3035::6815:25b7
  2606:4700:3037::ac43:d3a2
  
  www.unsam.edu.ar
  2606:4700:20::ac43:4b64
  2606:4700:20::681a:b10
  2606:4700:20::681a:a10
  
  www.newsan.com.ar
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.argentina.gob.ar
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  2606:4700:20::681a:4b7
  
  www.edilizia.com.ar
  www.edilizia.com.ar.cdn.hstgr.net.
  2a02:4780:50:83e3:2d34:afe1:afaf:97bc
  2a02:4780:4e:a704:36c6:c5a7:478e:3a77
  
  www.hospitalaustral.edu.ar
  adc.hospitalaustral.edu.ar.
  
  www.unne.edu.ar
  wwwproxy.unne.edu.ar.
  
  www.bsg.global
  
  www.icbc.com.ar
  
  www.uca.edu.ar
  
  www.uns.edu.ar
  uns.edu.ar.
  
  www.fravega.com
  
  www.grupopetersen.com.ar
  376ee70d1c774050adbdb0e659a74dd5.v1.radwarecloud.net.



  $ echo ;  for  Argentina_Domain  in   tytconsultores.com.ar mercadolibre.com es.wikipedia.org techintgroup.com cencosud.com ypf.com gob.ar uba.ar coto.com.ar somosjob.ar argentina.gob.ar telecom.com.ar arcor.com techint.com abc.gob.ar century21.com.ar uca.edu.ar galicia.ar osde.com.ar elalmacen.tv carrefour.com.ar unlp.edu.ar somosfarmacity.com hospitalitaliano.org.ar andreani.com mostazaweb.com.ar aesa.com.ar claroempleos-aup.com swissmedical.com.ar unc.edu.ar bbva.com.ar bna.com.ar argentina.gob.ar accenture.com argentina.gob.ar aerolineas.com.ar bancoprovincia.com.ar ocasa.com macro.com.ar arca.gob.ar laanonima.com.ar argentina.gob.ar naranjax.com informeg.com.ar mseg.gba.gov.ar gruposancorseguros.com axionenergy.com argentina.gob.ar pecomenergia.com santander.com.ar argentina.gob.ar unr.edu.ar utn.edu.ar cerveceriaymalteriaquilmes.com argentina.gob.ar adecoagro.com mendoza.edu.ar veronicapalermo.com.ar uncuyo.edu.ar toyota.com.ar argentina.gob.ar uade.edu.ar diaonline.supermercadosdia.com.ar pan-energy.com sancorsalud.com.ar ar.linkedin.com rosario.gob.ar mpf.gob.ar aysa.com.ar uai.edu.ar hospitalsanjuandedios.org.ar telecentro.com.ar nadro.mx usal.edu.ar hospitalaleman.org.ar pluspetrol.net edenor.com cge.entrerios.gov.ar supervielle.com.ar pwc.com.ar mdp.edu.ar hospitalbritanico.org.ar edu.ar gov.ar gdmseeds.com iosfa.gob.ar unsam.edu.ar newsan.com.ar argentina.gob.ar argentina.gob.ar edilizia.com.ar hospitalaustral.edu.ar unne.edu.ar bsg.global icbc.com.ar uca.edu.ar uns.edu.ar fravega.com grupopetersen.com.ar   ;    do     echo $Argentina_Domain   ;   dig +short aaaa $Argentina_Domain   ;  echo    ; done
  
  tytconsultores.com.ar
  
  mercadolibre.com
  
  es.wikipedia.org
  dyna.wikimedia.org.
  2620:0:863:ed1a::1
  
  techintgroup.com
  
  cencosud.com
  
  ypf.com
  
  gob.ar
  
  uba.ar
  
  coto.com.ar
  
  somosjob.ar
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  telecom.com.ar
  
  arcor.com
  
  techint.com
  
  abc.gob.ar
  
  century21.com.ar
  
  uca.edu.ar
  
  galicia.ar
  
  osde.com.ar
  
  elalmacen.tv
  
  carrefour.com.ar
  2a06:98c1:3108::ac40:9379
  2a06:98c1:3108::6812:2887
  
  unlp.edu.ar
  2800:340:0:64::135
  
  somosfarmacity.com
  
  hospitalitaliano.org.ar
  
  andreani.com
  
  mostazaweb.com.ar
  
  aesa.com.ar
  
  claroempleos-aup.com
  
  swissmedical.com.ar
  
  unc.edu.ar
  2801:120:842::4
  2801:120:842::5
  2801:120:842::6
  
  bbva.com.ar
  
  bna.com.ar
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  accenture.com
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  aerolineas.com.ar
  
  bancoprovincia.com.ar
  
  ocasa.com
  
  macro.com.ar
  
  arca.gob.ar
  
  laanonima.com.ar
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  naranjax.com
  2a06:98c1:3105::ac40:95eb
  2606:4700:440b::6812:2615
  
  informeg.com.ar
  
  mseg.gba.gov.ar
  
  gruposancorseguros.com
  
  axionenergy.com
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  pecomenergia.com
  
  santander.com.ar
  2600:1406:bc00:6a::172b:330f
  2600:1406:bc00:6a::172b:330d
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  unr.edu.ar
  
  utn.edu.ar
  
  cerveceriaymalteriaquilmes.com
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  adecoagro.com
  
  mendoza.edu.ar
  
  veronicapalermo.com.ar
  
  uncuyo.edu.ar
  
  toyota.com.ar
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  uade.edu.ar
  
  diaonline.supermercadosdia.com.ar
  diaonline.supermercadosdia.com.ar.cdn.vtex.com.
  d3p7gg3f271ro.cloudfront.net.
  2600:9000:204d:5200:9:b144:ad00:93a1
  2600:9000:204d:7200:9:b144:ad00:93a1
  2600:9000:204d:7800:9:b144:ad00:93a1
  2600:9000:204d:9400:9:b144:ad00:93a1
  2600:9000:204d:8000:9:b144:ad00:93a1
  2600:9000:204d:5000:9:b144:ad00:93a1
  2600:9000:204d:6400:9:b144:ad00:93a1
  2600:9000:204d:4a00:9:b144:ad00:93a1
  
  pan-energy.com
  
  sancorsalud.com.ar
  
  ar.linkedin.com
  cctld.linkedin.com.
  cctld.es.lnkdns.net.
  www.linkedin.com.cdn.cloudflare.net.
  2a06:98c1:3109::6812:2929
  2a06:98c1:310b::ac40:92d7
  
  rosario.gob.ar
  
  mpf.gob.ar
  
  aysa.com.ar
  
  uai.edu.ar
  
  hospitalsanjuandedios.org.ar
  
  telecentro.com.ar
  
  nadro.mx
  
  usal.edu.ar
  
  hospitalaleman.org.ar
  
  pluspetrol.net
  
  edenor.com
  2600:9000:21dd:4000:10:d7ce:6840:93a1
  2600:9000:21dd:fc00:10:d7ce:6840:93a1
  2600:9000:21dd:6a00:10:d7ce:6840:93a1
  2600:9000:21dd:7a00:10:d7ce:6840:93a1
  2600:9000:21dd:2000:10:d7ce:6840:93a1
  2600:9000:21dd:5e00:10:d7ce:6840:93a1
  2600:9000:21dd:7000:10:d7ce:6840:93a1
  2600:9000:21dd:e000:10:d7ce:6840:93a1
  
  cge.entrerios.gov.ar
  
  supervielle.com.ar
  
  pwc.com.ar
  
  mdp.edu.ar
  
  hospitalbritanico.org.ar
  
  edu.ar
  
  gov.ar
  
  gdmseeds.com
  
  iosfa.gob.ar
  2606:4700:3035::6815:25b7
  2606:4700:3037::ac43:d3a2
  
  unsam.edu.ar
  2606:4700:20::ac43:4b64
  2606:4700:20::681a:a10
  2606:4700:20::681a:b10
  
  newsan.com.ar
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  argentina.gob.ar
  2606:4700:20::681a:4b7
  2606:4700:20::681a:5b7
  2606:4700:20::ac43:4b23
  
  edilizia.com.ar
  2a02:4780:84:881e:443e:9364:14fd:ed8f
  2a02:4780:84:8c81:c13b:f920:84f2:6f33
  
  hospitalaustral.edu.ar
  
  unne.edu.ar
  
  bsg.global
  
  icbc.com.ar
  
  uca.edu.ar
  
  uns.edu.ar
  
  fravega.com
  
  grupopetersen.com.ar

You're a hospital. You have an actual contract with the ISP, right? Does it say you get an IPv4 address? If not, ask them for one, and pay up.

You don't need an address block from an RIR. You just need your ISP to give you an address.

You could also update to IPv6.


>You're a hospital.

I work for the hospital, occasionally, they are my client.

> You have an actual contract with the ISP, right?

They do not, it's an implied consumer contract, like when someone buys a hot dog from a stand.

I'd like a written contract too, but when trying to negotiate one, they want a lot more money for them, it depends of the nuances of the terms, but I've talked to sales reps, and it comes down to having a 1Gbps line that works right now vs a 100Mbps line that's more expensive, with the only difference being that the contract is now written and there's a symbolic SLA with some 10% penalty, and a single professional beration receiver instead of multiple anonymous on call rotation.

It's not a clear choice, especially considering that the dedicated route with SLA means introducing change risk to the operational and SLA benefit of the ISP, fiber, new holes, new lines, etc..

>You could also update to IPv6.

I would, they don't offer IPv6

>You don't need an address block from an RIR. You just need your ISP to give you an address.

Yeah, maybe. If I get an IPv4 block though what I'd do is a regional entity whether for profit or NFP to offer emergency regional tunneling, potentially while finding alternative revenue streams like collecting lists of wronged ISP customers and notifying them of class action lawsuits they may participate in. A 25K check, or a 5K check with an ipv4 block and I'm golden.


In fact as an IT service provider you should try to get an ISP to give you a contract to provide internet to all your customers as needed.

Well if your hospital is running on the cheapest possible internet made for houses, then you have no rights. You should GET a contract that includes what you actually need.

Service was marketed to corporations, (FiberCorp, business branch of FiberTel)

Also, in technical terms the tech is the same, the internet connects corporations with consumers so it's not surprising that the connective tissue is homogeneous, and there is no strict protocol asymmetry (unless you posit that there's an upload/download semantic association with upload producers and download consumers) so if there's any difference between an consumer and a corporate connection, it comes down to raw traffic volume, which in this case is 1Gbps, which both theoretically and empirically has been fine for years.


Actually, the difference is how much the ISP gives a shit about you. On a residential connection, they do not.

Email sent!

Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: