IPv6-only servers: github.com, the Stripe API and Slack webhooks still have no IPv6 address — 114 endpoints checked

Summary

Why IPv6-only comes up now

Two trends make IPv6-only servers worth considering. AWS and Google Cloud now bill for public IPv4 addresses by the hour, and close to half of Google users reach Google over IPv6.

Prices were read on 2026-09-25. AWS also states that addresses you bring yourself (BYOIP) are not charged. Hetzner lets you create cloud servers without any public IP. We left out Azure because its pricing page fills in prices with a script, so we could not read them.

On the client side, Google's own statistics show the share of users reaching Google over IPv6 above 50% for the first time on 2026-03-28 (50.10%). We downloaded Google's daily data file and counted: 20 days in 2026 have been at or above 50%, and all 20 fell on a weekend (19 Saturdays, one Sunday). For the 30 days ending 2026-09-20, the mean was 47.68% overall, 49.74% on weekends and 46.66% on weekdays. APNIC Labs, which measures through online ads and weights results by each economy's Internet users, put worldwide IPv6 capability at 43.79% for the same period.

So an IPv6-only server is a reasonable thing to consider. The question is what it can still reach.

How we checked

We listed 114 hostnames that a typical server or CI job calls, in eight groups: code hosting, package registries, toolchain downloads and install scripts, container registries, OS package mirrors, AI APIs, SaaS APIs, and hosting and cloud APIs. For each one we asked DNS for its A and AAAA records.

• Tool and date: dig 9.10.6, 2026-09-25
• Three vantage points: Cloudflare's resolver (1.1.1.1) from a line in Seoul, and Google Public DNS (8.8.8.8) with EDNS Client Subnet set to a US subnet (73.162.0.0/24) and to an EU subnet (87.186.0.0/24). EDNS Client Subnet passes a hint about the client's location to the authoritative server, which lets geo-aware DNS answer as if the query came from that region. All 114 hostnames returned the same AAAA result from all three vantage points
• Authoritative check: for ten of the most surprising results (the Stripe API, Slack, Slack webhooks, Discord, Sentry, Twilio, SendGrid, public.ecr.aws, the Vercel API and the Netlify API), we also asked each domain's own name servers. None returned an AAAA record
• Reachability: our Seoul connection has no global IPv6 address, so we tested from a dual-stack Ubuntu 24.04 server that we run on AWS in Seoul. It tried one HTTPS request to every hostname over IPv6 only and one over IPv4 only (curl -6 and curl -4); any HTTP status, including 401 or 404, counted as an answer. We confirmed that the server really leaves over both protocols with the server-side check described in section 8, and that its resolver does not synthesize IPv6 addresses (no DNS64: github.com still had no AAAA there)
• Stability: the same server asked its own resolver, 1.1.1.1 and 8.8.8.8 six times, 35 seconds apart, giving 18 answers per hostname. No hostname's AAAA result changed

Which endpoints have an IPv6 address

Publishing an address and answering on it turned out to be the same thing here: from the dual-stack server, all 85 hostnames with an AAAA record answered over IPv6, and all 29 without one failed at name resolution. Over IPv4, 113 of 114 answered. The exception, ssh.github.com, is the host GitHub documents for SSH over port 443, so an HTTPS request to it fails the TLS handshake (curl exit code 35).

Nearly every hostname used to install software has an AAAA record. Most of the gaps are in services an application calls at runtime: payments, email and SMS, chat webhooks, incident alerts and hosting APIs.

Hostnames with an AAAA record include npm, Yarn, PyPI, crates.io, the Go module proxy, RubyGems, Maven Central, NuGet, Packagist, pub.dev, CocoaPods, Homebrew's formula API, conda and JSR; Node.js, Python, Go, Rust, uv, Bun, Docker, NodeSource, HashiCorp, Helm and Kubernetes downloads; Docker Hub, Quay, gcr.io, Artifact Registry, registry.k8s.io and the Microsoft Container Registry; Debian, Ubuntu, Alpine, Fedora and Arch mirrors; Anthropic, OpenAI, Gemini, Vertex AI, Mistral, Groq, Together, Fireworks, xAI, Perplexity, OpenRouter, Replicate, Hugging Face and the Ollama registry; Resend, Telegram, Datadog, Clerk, Google OAuth, Microsoft sign-in, Apple Push Notification service, Firebase Cloud Messaging and Let's Encrypt; the Cloudflare, Supabase, Fly.io, Railway, DigitalOcean, Linode and Hetzner Cloud APIs; and GitLab, Bitbucket, Codeberg and sourcehut. The shares are our own arithmetic on the counts.

None of Stripe's API, Twilio, SendGrid, Mailgun, Postmark, Slack, Discord or PagerDuty's events endpoint has an AAAA record, while Resend, Telegram and Apple's and Google's push services do. An IPv6-only application server can often install its dependencies without help and then fail on its first payment or notification.

A separate Korean-language report on this site, written the same day, checked 16 services used by Korean developers, including Naver, Kakao and Toss Payments. None had an AAAA record: the Korean report.

GitHub: three of ten hostnames

Of the ten GitHub hostnames we checked, three have an AAAA record: raw.githubusercontent.com, pkg-containers.githubusercontent.com (which serves container image layers) and avatars.githubusercontent.com. The other seven do not: github.com, api.github.com, codeload.github.com (source archives), ssh.github.com, ghcr.io, release-assets.githubusercontent.com and objects.githubusercontent.com.

On an IPv6-only host, that means single-file downloads from raw.githubusercontent.com have an IPv6 address to connect to. Cloning over HTTPS or SSH, the gh CLI, the REST API, source archives and release downloads do not. We confirmed the release path by requesting a release asset from github.com/…/releases/download/…: it redirected to release-assets.githubusercontent.com. Container pulls from ghcr.io stop at the first step, because the registry API at ghcr.io handles authentication and manifests before any layer is fetched from the host that has IPv6.

We checked this end to end on the dual-stack server. git clone --ipv6, Git's own switch for using IPv6 only, failed on a GitHub repository with "Could not resolve host: github.com" and succeeded on repositories hosted on GitLab and Codeberg. With curl forced to IPv6, a GitHub release download and the ghcr.io registry API failed the same way, while a one-byte range request for a file on raw.githubusercontent.com came back over IPv6 with HTTP 206.

The August "IPv6 for Git SSH" post

On 2026-08-26 a Hacker News submission titled "GitHub Publishes IPv6 Addresses for Git SSH remotes" pointed to GitHub's meta API, api.github.com/meta, whose git block lists two IPv6 ranges, 2a0a:a440::/29 and 2606:50c0::/32. A commenter replied that the same ranges were already there in 2022. We checked archived copies of the meta API in the Wayback Machine: the two ranges are in the git and web blocks of the 2021-10-19 snapshot and absent from the 2021-05-31 one. They have been listed for about five years.

An address range in the meta API lists addresses GitHub may use; it is not the same as publishing an AAAA record in DNS. On 2026-09-25 neither github.com nor ssh.github.com had an AAAA record, so no Git client would connect over IPv6. The long-running community request, "IPv6 support for cloning Git repositories" (discussion #10539), was opened on 2022-01-25 and had 1,310 upvotes and 236 comments on the day we checked.

The hostname you request is not always the one that serves the file

An AAAA record on the first hostname says nothing about where the download or the SDK traffic actually goes. We found the difference in both directions.

We replayed the main destination of each row from the dual-stack server with curl forced to IPv6: the Bun release on github.com, the uv mirror, the ghcr.io registry API for Homebrew, the Hugging Face file, o0.ingest.sentry.io, api.stripe.com and the two AWS dual-stack hostnames. The red rows failed at the hostname without an AAAA record; for Hugging Face that was the second hop, after huggingface.co had answered over IPv6 with a redirect. The uv mirror, the Sentry ingest sample and both AWS dual-stack hostnames answered over IPv6.

Stripe's browser script host is a case of its own. We asked Stripe's authoritative name server for js.stripe.com 30 times: 15 answers pointed to a CloudFront name that has AAAA records and 15 to a Fastly name, stripecdn.map.fastly.net, that has none. Whether that hostname has IPv6 depends on which answer your resolver cached. api.stripe.com had no AAAA in any of our lookups.

For AWS, the SDKs switch to dual-stack endpoints when use_dualstack_endpoint = true is set in the shared config file, or AWS_USE_DUALSTACK_ENDPOINT=true in the environment. The default is false, and AWS's own documentation warns that if a dual-stack endpoint does not exist for the service and Region, "the request will fail". We tried two dual-stack-style names for the Bedrock runtime in us-east-1 (bedrock-runtime.us-east-1.api.aws and bedrock-runtime.dualstack.us-east-1.amazonaws.com); neither resolved. That does not prove there is none, only that those two names do not exist.

curl -6 reached github.com from a Mac

curl -6 tells curl to use IPv6 only, so a successful curl -6 is often read as proof that IPv6 works. On the Mac we used for this report, it connected to a host that has no IPv6 address at all.

$ dig +short AAAA github.com
$ curl -6 -s -o /dev/null -w '%{http_code} %{remote_ip}\n' https://github.com/
200 ::ffff:20.200.245.247

The empty dig output means github.com has no AAAA record. The address curl connected to, ::ffff:20.200.245.247, is an IPv4-mapped IPv6 address (RFC 4291, section 2.5.5.2): an IPv4 address written in IPv6 notation. A socket connected to it sends ordinary IPv4 packets. The Mac had no global IPv6 address, only link-local addresses and a unique local address (ULA, the IPv6 equivalent of a private network address).

We ran the same request through six clients against three targets: github.com (IPv4 only), myip.helpmek.com (IPv4 and IPv6) and ipv6.icanhazip.com (IPv6 only).

Red marks a result that reports success over IPv4; green marks an honest failure. wget resolved the names to the same ::ffff: addresses, but each connection attempt failed with "Address family not supported by protocol family".

The cause is documented in the getaddrinfo(3) manual page installed with macOS 26.7 (man getaddrinfo): "If ai_flags is zero, getaddrinfo() gives the AI_DEFAULT behavior ( AI_V4MAPPED_CFG | AI_ADDRCONFIG )." We called getaddrinfo from a small C program with each flag combination. With AI_ADDRCONFIG set, the AAAA answers were dropped (the link-local and ULA addresses did not count as configured IPv6); with AI_V4MAPPED_CFG or AI_V4MAPPED also set, the IPv4 answers came back in ::ffff: form. A program that asks for IPv6 with no flags therefore gets IPv4 addresses that look like IPv6. All four clients that reported success resolve names through the system getaddrinfo, and their results match this default. The manual page names the escape hatch: pass AI_UNUSABLE instead of zero to suppress the implicit default.

Linux did not do this. In Linux containers with no IPv6 other than loopback (OrbStack's Linux VM, kernel 7.0.14-orbstack), curl 8.22.0 on Alpine (musl) failed against github.com with "could not resolve host" and against the other two with "could not connect". Python 3.13 on Debian (glibc) got no address for github.com and, for the other two, resolved the real IPv6 addresses and failed with "Network is unreachable". Both are honest answers.

With IPv6 actually available, Linux also did the right thing. On the dual-stack server (Ubuntu 24.04 with curl 8.5.0, GNU Wget 1.21.4, Python 3.12.3, Node.js 24.21.0 and OpenBSD nc; Go was not installed), all five clients failed against github.com when forced to IPv6 and connected over native IPv6 to myip.helpmek.com and ipv6.icanhazip.com. MyIP reported "version": 6 for both curl -6 and wget -6. Without a flag, curl also chose IPv6 there.

Checking which protocol a connection really used

There are three checks that do not depend on how your client resolves names. The first uses myip.helpmek.com, the service we built (see the disclosure in section 7).

1. Ask a dual-stack server which protocol it saw. The server's view is the ground truth.

   $ curl -s https://myip.helpmek.com/json
   # "version": 6 means the request arrived over IPv6, 4 means IPv4

   On the Mac above, curl -6 -s https://myip.helpmek.com/json returned "version": 4, which gave the ::ffff: trick away at once. MyIP's API reference states that /ip and /json need no API key or cookie, are not rate limited and send Cache-Control: no-store, so they are usable from deploy scripts. curl myip.helpmek.com returns the bare address as plain text.
2. Connect to hosts that have only one kind of address. ipv6.icanhazip.com has only AAAA records and ipv4.icanhazip.com has only A records, so neither can be reached through the other protocol by accident. On the same Mac, curl -6 https://ipv6.icanhazip.com failed immediately, which is the correct answer for that machine.
3. In a browser, test each protocol separately. Browsers race IPv6 and IPv4 under Happy Eyeballs (RFC 8305 gives 250 milliseconds as one recommended default delay before the next connection attempt, which gives IPv6, tried first, a head start), so seeing IPv4 on a dual-stack page does not mean IPv6 is missing. MyIP's IPv6 test loads one probe reachable only over IPv4 and one reachable only over IPv6, using the two icanhazip hosts above, which the page describes as Cloudflare-operated, and reports which protocol the browser chose for the page itself. The long-running independent test at test-ipv6.com is still available: its operator announced a shutdown for December 2025, then said the project is moving to a Regional Internet Registry that will keep it running.

On macOS you can also catch the mapped address directly: add -w '%{remote_ip}' to a curl -6 command and treat any answer that starts with ::ffff: as IPv4.

If you use a VPN, check IPv6 while it is connected. A VPN that tunnels only IPv4 can let IPv6 traffic leave outside the tunnel; MyIP's VPN check suggests turning on the app's IPv6 block or kill switch when that happens.

Reaching IPv4-only services from an IPv6-only host

The standard answer is two cooperating pieces. DNS64 answers a query for a host that has no AAAA record with a synthesized IPv6 address: the host's IPv4 address behind the well-known prefix 64:ff9b::/96 (RFC 6052). NAT64 takes packets sent to that prefix, translates them to IPv4 and translates the replies back. When a host does have an AAAA record, DNS64 returns it unchanged and no translation happens.

On AWS

AWS's documentation says NAT64 "is automatically available" on NAT gateways and that DNS64 is turned on per subnet. For an IPv6-only subnet, the documented setup comes down to one subnet attribute and two routes (AWS also lists an IPv4 default route to the NAT gateway for subnets that have IPv4):

# Turn on DNS64 for the subnet that holds the IPv6-only workloads
aws ec2 modify-subnet-attribute --subnet-id subnet-XXXX --enable-dns64

# Send synthesized addresses to the NAT gateway
aws ec2 create-route --route-table-id rtb-XXXX \
  --destination-ipv6-cidr-block 64:ff9b::/96 --nat-gateway-id nat-XXXX

# Send all other IPv6 traffic to the egress-only internet gateway
aws ec2 create-route --route-table-id rtb-XXXX \
  --destination-ipv6-cidr-block ::/0 --egress-only-internet-gateway-id eigw-XXXX

This does not remove IPv4 from the bill. The NAT gateway sends translated traffic out through an Elastic IP address, which is a public IPv4 address, and the gateway has its own hourly and per-gigabyte charges. What you gain is one or a few IPv4 addresses for a whole subnet instead of one per server. With only a handful of servers, the gateway can cost more than the addresses it replaces; run the numbers first.

After setup, the checks from section 8 tell you both paths work. According to AWS's description of DNS64, curl -s https://myip.helpmek.com/json should go out directly over IPv6 and report "version": 6 with the server's own address, because MyIP has an AAAA record. curl -s https://ipv4.icanhazip.com has no AAAA record, so it should go through NAT64 and print the NAT gateway's Elastic IP.

Elsewhere

A free public NAT64 and DNS64 service exists at nat64.net, operated by Kasper Dupont according to the site; it lists three DNS64 resolvers (2a01:4f9:c010:3f02::1, 2a00:1098:2b::1, 2a01:4f8:c2c:123f::1). Its front page makes no claim about production use. Any public NAT64 translates many users' traffic onto a small pool of IPv4 addresses, so services that rate-limit or block by IPv4 address treat all of those users as one. It suits a hobby server or a bootstrap step better than a payment path.

The other options are to keep a single dual-stack egress proxy for the IPv4-only destinations, or to keep IPv4 on the servers that talk to them. For Supabase the direction is reversed: its documentation says direct database connection strings map to an IPv6 address and lists Retool, Vercel, GitHub Actions and Render as "prominent ones that only accept IPv4 connections". From those platforms, use the Supavisor pooler connection string (transaction mode on port 6543, session mode on port 5432) or turn on the IPv4 add-on.

What to do before you drop IPv4

1. List every hostname the server calls, then check it. Include redirect targets, install-script downloads, webhook destinations and SDK hostnames, not just the registries. Most of the gaps in this report were in those places.

   # hosts.txt: one hostname per line
   while read h; do
     a=$(dig +short A "$h" | grep -cE '^[0-9.]+$')
     q=$(dig +short AAAA "$h" | grep -c ':')
     printf "%-45s A:%s AAAA:%s %s\n" "$h" "$a" "$q" \
       "$([ "$q" -eq 0 ] && echo '<- needs an IPv4 path')"
   done < hosts.txt

2. Decide the IPv4 path before you need it. The core GitHub hostnames, the Stripe API, Twilio, SendGrid, Mailgun, Postmark, Slack, Discord and PagerDuty's events endpoint had no IPv6 address on 2026-09-25. If any of them is in the list, set up NAT64 and DNS64 or an egress proxy first.
3. Turn on AWS dual-stack endpoints service by service. Set use_dualstack_endpoint and test each service you call. A service without a dual-stack endpoint fails instead of falling back.
4. Verify from the server, not from your laptop. curl -s https://myip.helpmek.com/json should report "version": 6, and curl -s https://ipv4.icanhazip.com should print the IPv4 address you expect for your NAT64 or proxy.
5. Do not accept curl -6 on a Mac as proof. Check %{remote_ip} for ::ffff:, or use the two single-protocol probes.
6. Check CI and managed platforms separately. Supabase names GitHub Actions and Vercel among the services that only accept IPv4 connections. An IPv6-only database is unreachable from them unless you go through a pooler or buy an IPv4 address.

What this does not show

• Reachability comes from one server and one request per hostname and protocol. Any HTTP status counted as an answer. That shows the address answers from AWS in Seoul; it does not show that every API call or large download would complete over IPv6, or that the result holds from other networks.
• Where we asked from. Our lookups came from Seoul directly and through US and EU client subnets, plus 18 answers per hostname from the AWS server over about three minutes. EDNS Client Subnet changes the answer only where the authoritative server uses it, and records change over time; js.stripe.com shows that a single lookup can mislead. Check again before you migrate.
• We chose the 114 hostnames. They are common, not a sample of anything. Your SDK may call a different hostname than the one we checked, as the Sentry row shows, and redirect targets can differ by file and region. We saw the Hugging Face redirect from Seoul only, from both the home line and AWS.
• The client results come from one Mac, two Linux containers and one dual-stack Linux server. macOS 26.7 with the versions listed; Linux through OrbStack and on Ubuntu 24.04. We did not test Windows, other macOS versions or Homebrew's curl.
• We did not build the AWS NAT64 setup. Section 9 describes AWS's documentation, and the expected outputs follow from it.
• The meta API history rests on Wayback snapshots. The IPv6 ranges first appear in the 2021-10-19 snapshot; the exact date GitHub added them falls somewhere between 2021-05-31 and that day.
• Prices are as of 2026-09-25. Azure is missing because we could not read its price table.
• myip.helpmek.com is ours. Its API behavior is described from its own documentation.

References

We opened every primary source on 2026-09-25. Measurements are our own. Revised on the day of publication: the first version reported AAAA lookups only, and this one adds the tests from a dual-stack server.

Google's figure counts users who reach Google over IPv6; APNIC's counts users reached through ads and is weighted by country. They measure different populations and should not be compared directly. Shares and monthly prices marked "derived" are our arithmetic.