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.
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.
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.
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.
Thank you, I needed a good laugh today, that is amazing!
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.
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
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.
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.
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.arIf 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!
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.