Comment by jon128
19 hours ago
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.
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."
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:
and this one too
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
1 reply →