[Starlink] Re: Ookla's Speedtest results now map the city & PoP where your traffic joins the IXPs as the aircraft moves

[Frantisek Borsik <frantisek.borsik@gmail.com>]

Thanks, Jianping! Dave is definitely happy up in the air, seeing all this
improvements happening over time, courtesy of hard work and ideas of many,
coming together.

There was another great question asked in the discussion on the original
post on LinkedIn, so copy+pasting it with the Luke's answer.

Does it use IP addresses dedicated to aircraft or does it use landing
> country allocated ranges as per their public IP Geofeed ? Last year I was
> discussing anomalies with Geoff Huston on the way they allocate country IPs
> to maritime communications clients. [Ben Roberts
> <https://www.linkedin.com/feed/update/urn:li:ugcPost:7519146674263498752/?dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287519370925272883200%2Curn%3Ali%3AugcPost%3A7519146674263498752%29>
> ]


Luke's answer:

(...) My understanding is that both exist (depending on the airline). Most
Starlink airlines in our data (e.g., Qatar Airways, United, Emirates,
WestJet and others) use address blocks dedicated to aviation. Each block
has one fixed city in Starlink’s geofeed, usually but not always the
airline’s home (Doha, Chicago, Dubai, Calgary).

The aircraft’s traffic still reaches the internet wherever it is (for
example, one Qatar Airways block exited through at least 18 different PoPs,
each confirmed independently by the internet exchange the traffic entered
next).

An example like Air France works the other way though. Its addresses are
listed against individual PoPs (London, Frankfurt, Madrid, Milan) and
change as the aircraft moves, while the geofeed shows Paris for all of them.

This means the geofeed can say little about where an aircraft’s traffic
actually goes, and so we don’t use it or IP-based location for that. Each
result’s PoP here comes from Starlink’s own routers in the passenger’s
traceroute, and its position from the phone’s GPS.

The UVic team saw the same split but from the outside (i.e., some aircraft
keep one address across PoPs, others change it).



All the best,

Frank

Frantisek (Frank) Borsik


*In loving memory of Dave Täht: *1965-2025

https://libreqos.io/2025/04/01/in-loving-memory-of-dave/


https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714 <+421%20919%20416%20714>

iMessage, mobile: +420775230885 <775%20230%20885>

Skype: casioa5302ca

frantisek.borsik@gmail.com


On Fri, Oct 23, 2026 at 7:12 PM Jianping Pan <pan@uvic.ca> wrote:

> Thanks Frank: this is a(nother) example of network users, engineers and
> researchers interaction and collaboration to make the internet a better
> place for everyone. it started as user complaints on starlink geoip/content
> mismatch, our initial investigation, ietf ipgeo workshop, starlink
> response, our follow-up work, inside-out measurement, wars in middle east,
> outside-in measurement, and an imc paper award ;-)
>
> a lot of people on the mailing list helped along the way. yes, those 900+
> aircraft are part of the dave daht memorial testbed too. thanks!
>
> is
> https://www.reddit.com/r/StarlinkEngineering/comments/1wtu2d0/ookla_vs_cloudflare_speedtest_on_starlinkequipped/
> fixed now?
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA,
> Web.UVic.CA/~pan
>
> ________________________________________
> From: Frantisek Borsik via Starlink <starlink@lists.bufferbloat.net>
> Sent: Friday, October 23, 2026 1:23 AM
> To: Dave Taht via Starlink
> Subject: [Starlink] Ookla's Speedtest results now map the city & PoP where
> your traffic joins the IXPs as the aircraft moves
>
> Nice job, Ookla (or rather, Accenture now, lol)
>
> Kudos to Jianping Pan and Jinwei Zhao (University of Victoria).
>
> Original post shared by Luke Kehoe annoucing it on LinkedIn:
> https://www.linkedin.com/feed/update/urn:li:activity:7519293982208761856/
>
> *TL; DR;* Now we can trace Starlink packets from the ground (thanks to work
> done by Jianping Pan and Jinwei Zhao at University of Victoria - see their
> research paper below) AND also from inside the cabin, using passengers’ own
> Speedtest results, thanks to Ookla.
>
> If you don't want to go there, here is a copy+paste:
>
> On a Starlink-connected flight, the city and PoP where your traffic joins
> the internet changes as the aircraft moves, and passengers’ own Speedtest
> results now let us map that from inside the cabin across more than 20
> airlines around the world, building on research by Jinwei Zhao and Jianping
> Pan at the University of Victoria (who identified more than 900 Starlink
> aircraft from the ground).
>
> *Speedtest app results carry a traceroute, and on Starlink those that get a
> reply cross Starlink’s routers at the point of presence (PoP) where traffic
> meets the internet. We matched those routers to PoPs using Starlink’s own
> address records (archived by the UVic team), keeping only passengers with a
> fresh GPS fix at airliner speed (April to September 2026).*
>
> Over the North Atlantic, passengers connected through Montreal or New York
> until roughly halfway across, then London or Madrid (i.e., directionally
> consistent with the mid-ocean handovers UVic observed).
>
> Hawaii has Starlink ground stations but no PoP, so passengers within 1,500
> km of Honolulu reached the internet in Los Angeles, nearly 4,000 km away,
> at a median multi-server latency of 95 ms (against 43 ms within 750 km of
> their PoP).
>
> The most policy-relevant (and interesting) observation here concerns
> in-country egress. Starlink places home users in Oman on its Muscat PoP and
> in Indonesia on Jakarta, Surabaya or Batam, yet passengers over Oman and
> Indonesia connected through Doha and Singapore respectively in our data
> (small numbers, but UVic saw the same and hypothesise these PoPs exist for
> local egress rules). As more governments mandate in-country egress, how
> overflying aircraft are treated is an open question.
>
> Separately, but relevant, passengers measured about twice the median
> download speed of Starlink homes in the same areas and months in our data.
>
> The University of Victoria research was able to follow one aircraft for a
> whole flight by combining publicly reachable IPv6 addresses, MPLS routing
> labels and flight tracking data (e.g., one Qatar Airways flight from Doha
> to New York connected through seven cities in turn, at times over 2,000 km
> away, as visualised in the film), and the team found aircraft unreachable
> over India and Pakistan.
>
> *The research also showed how Starlink's new "anycast users" feature allows
> aircraft to retain the same public IP address as traffic moves between
> geographically distant PoPs, avoiding the TCP connection disruptions
> associated with previous handovers.*
>
> Research paper linked in the comments.
>
> The research by Jinwei Zhao and Jianping Pan (University of Victoria),
> *“Measuring
> Starlink Aviation Around the World”*, ACM IMC 2026, open access:
>
> doi.org/10.1145/3777912.3839781
>
> *Their method works from the ground.* They identified more than 900
> Starlink aircraft by their router addresses, read Starlink’s own routing
> labels from a Starlink terminal in Canada, and measured latency from 27
> cloud servers over five months. *Our view complements theirs from inside
> the cabin, using passengers’ own Speedtest results.*
>
>
> All the best,
>
> Frank
>
> Frantisek (Frank) Borsik
>
>
> *In loving memory of Dave Täht: *1965-2025
>
> https://libreqos.io/2025/04/01/in-loving-memory-of-dave/
>
>
> https://www.linkedin.com/in/frantisekborsik
>
> Signal, Telegram, WhatsApp: +421919416714 <+421%20919%20416%20714>
>
> iMessage, mobile: +420775230885 <775%20230%20885>
>
> Skype: casioa5302ca
>
> frantisek.borsik@gmail.com
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>