Designing Cloud Workloads For LEO Satellite Internet Users - YouTube
The recent talk on designing cloud workloads for LEO satellite users was a useful overview. The terrestrial framing was clear and the maps were a good way to think about egress. A few points on the geolocation layer are worth clarifying against primary sources, because they shape how operators should treat Starlink IP data.
These are not disagreements about the architecture material. They are clarifications, and each one is anchored to either Starlink’s own documentation or to the presenter’s own answer during Q&A.
1. “IP geolocation broadly works” for static users
The talk stated that IP geolocation “broadly works” for static Starlink users, and that it is “broadly going to be managed correctly by them because they are the first party who’s publishing that data” (around 10:39 and 11:00).
Starlink’s own Help Center documents the part that complicates this. The default IPv4 configuration is carrier-grade NAT using the 100.64.0.0/10 range, so many subscribers share one public address. Starlink also states that it does not provide static IP addresses, and that addresses change “for resilience, as network capacity increases, or when new countries are added.”
A published geofeed maps a pooled, dynamic address to a service area. It does not place an individual subscriber. So the geofeed is a useful starting point, not a settled answer. Pooled satellite ranges need careful handling in any geolocation pipeline.
2. The in-flight IP “changes based on the country overflown”
The talk described the aircraft terminal as one that “keeps changing its IP address based on the country it’s overflying” (around 13:45).
Starlink’s documentation describes a different mechanism. A mobile user acquires a new IP as they migrate between ground stations, and the address follows the serving ground station and the network state, not the territory below. On long routes, inter-satellite links can carry traffic to a ground station far from the flight path. The address tracks where the traffic leaves the network, which is often not the country being overflown.
3. The maps labeled “internet exchange points”
Several egress locations across the Middle East and Africa were labeled as internet exchange points. During Q&A, the presenter clarified that the term was being used generally for any point where traffic is traded, and confirmed that actual IXPs do not exist in some of those locations (around 31:13).
For anyone using these maps, the authoritative record of real IXP presence is PeeringDB. It is worth checking before treating a labeled point as an exchange.
Closing
None of this takes away from the cloud architecture portion of the talk, which stands on its own. The geolocation layer is simply where the primary sources are worth a second look. We work with these ranges daily and are happy to share measurement data on Starlink address space with anyone who finds it useful.
Sources
- Starlink Help Center, “IP Address” (default CGNAT on 100.64.0.0/10, dynamic addressing, ground-station migration): Starlink
- PeeringDB, the authoritative registry for internet exchange points: https://www.peeringdb.com
- Talk timestamps reference the published session recording.