TL;DR in case you don't want to read my long post of discovery: if you run a Firebase app and use custom domains (i.e. not just *.firebaseapp.com), for every A record on your custom domain pointing at 199.36.158.100, please add an identical AAAA record for 2620:0:890::100. Tada, your app can now use IPv6. Why don't the Firebase docs have you do this???????????
So, I am a IPv6 evangelist, and want to see as many things as possible existing natively on IPv6. My home network is dual-stack (and is soon to be single-stack v6) and most of my servers are single-stack v6. I like my IPv6.
Recently, I was cleaning up my subscriptions, and found my $4.99/yr payment to Shadow Weather. It's a weather app that was created back in 2020 in response to Apple's purchase and immediate shutdown of Dark Sky. My understanding is that Apple integrated Dark Sky's tech into Apple Weather on macOS/iOS/iPadOS, but I don't care, fuck you Apple give me my nice Android weather app back.
Anyways, Shadow Weather is the closest replacement I've found, and I've kept using them since then. I went to their site, and as I was poking around their stuff, I saw it...
getting nerdsniped by an extension
the mark of the beast
My favorite (still alive) weather app doesn't support IPv6! How dare they!
Naturally, I started to poke around. Most everything these days is hosted through a CDN or some other hosting platform. Who was 199.36.158.100? They probably support IPv6. How do I get IPv6 out of them?
Well, it didn't take long to find who it was. 199.36.158.100 is Firebase, Google's incredibly weird little pet hosting project (not to be confused with Google Sites, or Google App Engine, or Google Cloud Platform). Firebase is very strange, but it's what Shadow Weather uses, so whatever let's go with this.
Sure enough, if we check Firebase's custom domain instructions, they have you configure your domain to point at 199.36.158.100, so we've definitely found our hosting service.
But this is Google? Google supports IPv6 pretty well across their whole product stack, so I'd expect them to include IPv6 instructions.
Render Unto César
If we search "firebase ipv6", we get a lot of angry posts from random users on reddit, a very long GitHub issue chain complaining about Indian ISPs, and a Google Groups thread: Does Firebase supports iPv6? [sic]. Scrolling to the bottom, we find:
Actually it does. Firebase Hosting runs on Fastly and Fastly supports IPv6.
Here are all the (IPv4 and IPv6)s of Firebase Hosting:
151.101.1.195 151.101.65.195 151.101.129.195 151.101.193.195 2a04:4e42::451 2a04:4e42:200::451 2a04:4e42:400::451 2a04:4e42:600::451Even SSL/TLS works properly on Firebase Hosting IPv6 addresses: https://imgur.com/a/gHb2kdc
César
And sure enough, these IPs do work, complete with TLS:
$ curl --resolve 'shadowweather.com:443:[2a04:4e42::451]' https://shadowweather.com/
...<title>Shadow Weather</title>...
But, uh, where'd they come from? I don't like IPs pulled from the void.
Wait, who runs Firebase?
Wait, Fastly? Firebase is Google's product, it lives at firebase.google.com. Yet, this person claims Fastly does. whois 2a04:4e42::451 shows that it's Fastly's IP space, yet it returns a webpage, with accompanying valid TLS cert, for a Google product.
whois 199.36.158.100 shows the prefix is part of a /21 owned by Google, but if we look at the actual BGP announcement, it's announced by AS54113, aka Fastly. So, it is Google's product, but its fronted by Fastly?
Aha, it's using Fastly's Subscriber Provided Prefix product, where they announce your IP space on their ASN, and use the IPs to front their HTTPS reverse proxies for your service. Alright then.
Gotta Go Fastly
Okay, let's dig into Fastly. I'm mostly familiar with how to abuse Cloudflare's network, but Fastly is an up and coming abuse target.
Let's dig into this...
https://docs.fastly.com/en/guides/working-with-cname-records-and-your-dns-provider
https://docs.fastly.com/en/guides/working-with-domains
https://docs.fastly.com/en/guides/ipv6-support
Ugh, okay.
Unlike Cloudflare, Fastly largely works off CNAME records. To enable Fastly on your site, you'd make a record like www.myproject.com with a CNAME to perhaps dualstack.j.sni.global.fastly.net, which would then send it through Fastly. The IPs returned by these are in the same prefixes César mentioned above:
$ dig +noall +answer AAAA dualstack.j.ssl.global.fastly.net
dualstack.j.ssl.global.fastly.net. 19 IN AAAA 2a04:4e42:400::68
dualstack.j.ssl.global.fastly.net. 19 IN AAAA 2a04:4e42:600::68
dualstack.j.ssl.global.fastly.net. 19 IN AAAA 2a04:4e42::68
dualstack.j.ssl.global.fastly.net. 19 IN AAAA 2a04:4e42:200::68
but aren't the same IPs, and don't work for Firebase:
$ curl --resolve 'shadowweather.com:443:[2a04:4e42::68]' https://shadowweather.com/
curl: (60) SSL: no alternative certificate subject name matches target host name 'shadowweather.com'
Fastly seems to like spreading sites out across the different letters though. Could it be just that I need a different letter?
Quick bash script to check:
for i in dualstack.{a..z}.{ssl,sni}.{global,us-eu}.fastly.net; do
IP="$(dig +short aaaa $i | head -1)"
echo "$i -> $IP"
curl --resolve "shadowweather.com:443:[$IP]" https://shadowweather.com/
done
and no, none of them resolve to an IP ending ::451, and none of them will load the page.
Okay, so presumably the IPs César mentioned were previously in use by Firebase running on Fastly, but have since swapped to Google's own IPs.
Wait, Firebase has firebaseapp.com, right?
As I sat and waited for the firebase demo project to never load (it seems to be working now though), I remembered something. Firebase projects usually live on a subdomain that looks like something.firebaseapp.com, right? Well, if I go to https://something.firebaseapp.com/, I get a happy IPv6 icon in my browser. What IPs is this using?
$ dig +noall +answer something.firebaseapp.com
something.firebaseapp.com. 300 IN A 199.36.158.100
Hey look at that, there's that same Google-owned Fastly-announced IP! This feels like the right track.
$ dig +noall +answer AAAA something.firebaseapp.com
something.firebaseapp.com. 300 IN AAAA 2620:0:890::100
Oh hello, that's not one of those 2a04:4e42... Fastly IPs. Looking at whois 2620:0:890::100, it's Google owned IP space, but the BGP announcement is once again being done by Fastly.
And sure enough, it works for Shadow Weather:
$ curl --resolve 'shadowweather.com:443:[2620:0:890::100]' https://shadowweather.com/
...<title>Shadow Weather</title>...
In Conclusion
Dear Princess Celestia, what did we learn today?
- Firebase, a Google product, built and operated by one of the largest tech companies on the planet, uses Fastly CDN for its service.
- Google spent a /24 and /48 to hand to Fastly to run Firebase
- Firebase (appears to) fully support IPv4 and IPv6
- Firebase (appears to) fully support custom domains on IPv4 and IPv6
- The Firebase docs for domains tell you to make an A record for
199.36.158.100, but never an AAAA record for2620:0:890::100, even though you should add both. - Apparently, no-one else on the entire internet has figured this out in a way that appears when googling "firebase ipv6" (hopefully this post will help with that).
- I've wasted an entire evening of my finite life and will never get it back.
A much shorter version of this post has been sent to the Shadow Weather dev's email, in the hopes of getting IPv6 support on their app. Will update if I get a response.
