Starlink tells the world it has over 150 sextillion IPv6 addresses

Internetworking wonks have investigated Starlink’s use of IP addresses and found some interesting facts. Internet infrastructure analyst Doug Madory on Wednesday used the Internet Society’s Pulse blog to share his analysis of the IP addresses Starlink lists in its IP geolocation file, the format network operators use to self- …

[Michael Hoffmann]

How many IPv6 addresses is that for every single atom currently constituting the Earth and everything on and in it?

Fine, up the Korman line, if you insist!

PS: LLM tells me in the ball park of 10^51. If that's correct, that's simply insane.

[David Newall]

A different LLM says it's one per 3e12 atoms. Still totally bonkers.

[Anonymous Coward]

Ballpark answer to question ... needs an LLM to answer it ... for 'extra' inprecision ... NOT !!!

"PS: LLM tells me in the ball park of 10^51. If that's correct, that's simply insane."

"A different LLM says it's one per 3e12 atoms. Still totally bonkers."

I can also make a 'complete guess' at the number WITHOUT using an LLM ... just as valid as any !!!

(A question, answered on the basis of ill-defined information gives you a 'complete guess' with no accuracy ... I can do that !!!)

:)

[DS999]

A little back of the envelope math

Adding up all the numbers (just via their magnitude) shows that Starlink is using 1/2^32 of all IPv6 addresses. If they used the same percentage in IPv4 addresses they'd have exactly ONE (actually less than one since IPv4 has a lot of wasted address space for multicast, localhost, 10.x and various other reservations)

So while the numbers sound crazy IPv6 is designed to be very wasteful of address space, to justify the stupidity of going to 128 bits instead of doing a backwards compatible 64 bit deployment (which IMHO would have seen the whole world on IPv6 long ago)

[Anonymous Coward]

Re: A little back of the envelope math

There are many 6-to-4 compatibility layers, ipv6 couldn't be more compatible than it already is.

You want to bump the bits to 64? Straight away, you've created an incompatible system, which would require all the upgrades that ipv6 requires.

I do agree that 64 bits would have worked - the fact they are throwing away 64 bits for the "address part" due to the silly SLAAC system (when they could leverage DAD [ipv6 duplicate address discovery]) shows it.

However, 128 bits, 64 bits, 65 bits, or 999 bits, the incompatibility problem would be the same.

Or maybe you think that an alternate IPv6 could have been created as a superset, containing the IPv4 address range?

Guess what? :

$ host -t a theregister.com

theregister.com has address 104.18.4.22

theregister.com has address 104.18.5.22

$ telnet -6 ::ffff:104.18.4.22 80

Trying ::ffff:104.18.4.22...

Won't send login name and/or authentication information.

Connected to ::ffff:104.18.4.22.

Escape character is '^]'.

get /

HTTP/1.1 400 Bad Request

Server: cloudflare

...

Finally, I've heard people moan about the "confusing" hexadecimal format of IPv6 addresses.. Sigh, it's just a representation of a 128bit value, just like the IP4 use of 4 base256 digits is just a representation of a 32bit value. Both can be chopped and changed as necessary:

$ host -t a theregister.com

theregister.com has address 104.18.4.22

theregister.com has address 104.18.5.22

$ echo "$((((104 * 256 + 18) * 256 + 4) * 256 +22))"

1746011158

$ telnet 1746011158 80

Trying 104.18.4.22...

Won't send login name and/or authentication information.

Connected to 1746011158.

Escape character is '^]'.

get /

HTTP/1.1 400 Bad Request

Server: cloudflare

...

[Jellied Eel]

Re: Talking telephone numbers

Finally, I've heard people moan about the "confusing" hexadecimal format of IPv6 addresses.. Sigh, it's just a representation of a 128bit value, just like the IP4 use of 4 base256 digits is just a representation of a 32bit value.

I kinda agree and disagree. We're used to remembering relatively small numbers, like phone, SSID, maybe bank accounts. But we're much less used to remembering hex numbers, which can lead to forgetfulness, or mistakes like hexes backfiring. And although some apps allow decimal representations, not all do. But thanks to (mostly) mobile operators, we're stuck with IPv6 instead of alternate proposals, like just slapping a country code in front of an IPv4 prefix and calling it good. Then maybe a planet code, which would also support planet+colony code. Phone companies mostly solved the addressing problem over a century ago, but the IETF just had to be different.

[Anonymous Coward]

Re: Talking telephone numbers

If a numbering space is increased, the numbers have to get bigger. You can't have over 9999 phone numbers with a 4 digit scheme! :-)

Don't forget, IPV6 can "skip" "unused" parts of the address not used, and of course, "decimal" BCD addresses can be used!

One of my home machines has the IPv6 address: 2001:470:6900::1 which isn't too preposterous, especially as after the 2001:470:6900: bit I can use any decimal number format I want.

My point wasn't made very clearly - I wasn't necessarily supporting the use of hex numbers specifically, I was saying that implementations should have been more free to support multiple representations. There's nothing technically stopping an IPv6 address being specified as ip6:2.3.4.5 or ip6:1.2.3.4.5.6.7 etc. - although some may consider it confusing, at the end of the day, whatever format is used, it's all just converted to a 128bit number internally. ::ffff:A.B.C.D is "allowed" as a way to represent IP4 in IP6 - there's no technical reason why a dotted format IP6 address could be used generally - after all, it doesn't matter what format is used by us humans, at the end of it, it's all just a single 128 bit number.

Anyone could modify their IPV6 stack to accept the above formats, and it would work with all systems unmodified, so the point I was trying to make is that people are complaining about user-level implementation rather thank the internal protocol itself.

(Not my downvote)

[Solviva]

Re: Talking telephone numbers

Which part of IPv4 allows for country codes?

Oh that's right, none so you'll need IPv4.1 which is 100% not backwards compatible with IPv4. OK so a country code + IPv4 would be simpler to remember than a 128 bit number, so all you've done is add another byte to the address making a not very round 40 bit length. But dividing by country isn't very efficient, compare say Lichtenstein with China.

There is truth they could have simply added a byte or two to make an incompatible IPv4.x, but if you're going to break everything then why not start from scratch and try and design something functionally better?

[R Soul]

why not start from scratch and try and design something functionally better?

The IETF did that with IPv6. And failed.

[Anonymous Coward]

Re: why not start from scratch and try and design something functionally better?

No, they didn't fail.

Roughly a third of worldwide internet traffic is IPv6 (as of 2023) https://blog.cloudflare.com/ipv6-from-dns-pov/

It's use is increasing every year, but admittedly it's slow.

However, IPv4 will eventually fail, and there will be nothing else to replace it other than IPv6.

Put it this way, even if IPv4 continues to dominate, there will NEVER be any "IPv7" protocol as a successor - the successor to IPv4 is IPv6, and that will happen however long it takes

[Nanashi]

Re: why not start from scratch and try and design something functionally better?

They didn't even try!

IPv6 is mostly a clone of IPv4 with bigger addresses. There's some amount of difference in the details (like NDP vs ARP) but fundamentally it all functions the same way. The addresses work the same as they do in v4, subnetting works the same, routing works the same, it runs over the same networks, DNS works the same, TCP or UDP work the same. You can't really call it a "from scratch" design.

And having over 2.5 billion users, and growing, is an odd definition of failed.

[bemusedHorseman]

Re: A little back of the envelope math

"IPv6 is designed to be very wasteful of address space"

...Funny thought. I wonder if it's semi intentional wardialing prevention? You can iterate the entire IPv4 address space relatively trivially (in fact it's practically guaranteed someone in the world is doing this right now, at all times of the day, for various purposes), but it's astronomically unlikely to fire off a ping at a random v6 address and actually hit something...

[Anonymous Coward]

Re: A little back of the envelope math

IP4 was originally designed in a similar way - they just didn't expect the huge growth.

You could assign a whole "class A" to a country, for example, and "Class B"s within that class A to different regions.

(Of course, as it started pretty much US centric, instead, whole Class A's were assigned to specific institutions - they in turn could allocate class b's to various locations in their institution, and so on)

So, the IP numbering system - as with the phone system - helps simplify routing.

They may be running low on phone numbers in the 01234 area code, whilst having plenty free in the 01567 area code, but imagine the routing mess if someone in Stockport was allocated a phone number on the Plymouth exchange because the Stockport one was becoming full.

This shortage of addresses is why the IP4 routing tables are so massive - a wide range of addresses lets you simplify them significantly.

[Nanashi]

Re: A little back of the envelope math

Yes, it's partly that.

The main reason is to reduce the size of routing tables - if you give everybody overly large blocks then they won't need to expand as often, and if you allocate sparsely then expansion doesn't necessitate splitting the block in two. For example, if you get a /32 from RIPE then they leave the next 7 /32s unallocated, allowing you to expand your allocation up to a /29 without needing to deal with a second disjoint block. RIPE can spend the 3 bits on doing this because they themselves have an overly large allocation, and this logic applies at every level.

For that matter, imagine trying to get a second block from your ISP if you ran out of the first one. Getting an overly large block that you can't possibly completely use is surely better than needing to try and get that request through your ISP's support line.

As for the /64 subnet size, SEND (which is an approach to securing neighbor discovery) uses the 64 bits of host IP space to store a cryptographic key. But even if you aren't using SEND, a /64 does indeed serve as a huge sparse space that's impossible to exhaustively scan: it takes something like a million petabytes of traffic to exhaustively scan a /64, per port.

(It's possible to narrow the search space a bit from "every single IP", since people often use addresses like ::2, ::1000 etc, and with SLAAC you can sometimes narrow things a little by scanning addresses that correspond to specific OUIs. But even one single OUI is a gigabyte of traffic per port, or 65 terabytes for all ports. That's a far cry from the setup most people have on v4, where scanning the 65k ports on the router is enough to reveal every publicly accessible server on the entire network. I'd expect that "randomly scan for vulnerable servers" isn't going to be a viable technique in v6, which will improve the overall security of the Internet to some degree. This is backed up by looking at tcpdump for my routers, which see a great deal more scan traffic on v4 than they do on v6, and the vast majority of what I do get on v6 is either to IPs that were scraped from TLS cert transparency logs, or it's to unused addresses.)

[Nanashi]

Re: A little back of the envelope math

There's no such thing as a "backwards compatible 64-bit deployment", or at least not in any sense that doesn't already apply to v6 - because the core problem is that v4 isn't forwards compatible with addresses bigger than 32 bits. No amount of "use less than 128 bits" will help with that, unless you go all the way down to 32 bits which would be pointless since at that point you can just use v4.

That's kind of the reason we needed a new protocol in the first place.

128 bits isn't particularly stupid either. 64 isn't enough and 128 is the next power of 2 up from that.

[Flocke Kroes]

Couple of quick checks on wikipedia:

Mass of Earth is about: 6e24kg. Earth is approximately iron with a relative molecular mass of 56(g/mol). Avagadro's number is about 6e23 atoms/mol. So Earth has about 6.4e49 atoms. 2^128 is about 3.4e38 IPv6 addresses. That makes about 2e11 atoms/IPv6 address.

Now for the difficult question: why are people investing billions in LLMs?

[bemusedHorseman]

...So what you're saying is, since nanobots are much larger than single atoms [citation needed], they actually wouldn't "run out of addresses" on IPv6?

[ropter]

Registered because I think this an amusing exercise!

Earth mass is roughly 5.9722×10^24 kg

According to wikipedia the composition is as follows:

iron 32% of weight (1911,104*10^21 kg or 1911,104*10^24 g)

oxygen 32% of weight (1911,104*10^21 kg)

magnesium 15% of weight (895,83*10^21 kg)

silicon 15% of weight (895,83*10^21 kg)

calcium 1.5% of weight (895,83*10^21 kg)

aluminium 1.5% of weight (89,583*10^21 kg)

nickel 1.5% of weight (89,583*10^21 kg)

Let's use molar masses, seems like the easiest way to do that

Fe 55.8450

O 15.99940

Mg 24.30500

Si 28.08550

Ca 40.0780

Al 26.98153860

Ni 58.69340

n = m (in grams!) * Na (avogadro const) / M (molar mass)

So, according to my Excel sheet thats like

Fe 206.0871572 *10^47 atoms

O 719.335556 *10^47 atoms

Mg 221.9631498 *10^47 atoms

Si 192.0853948 *10^47 atoms

Ca 13.46078736 *10^47 atoms

Al 19.99446524 *10^47 atoms

Ni 9.191517883 *10^47 atoms

And to sum it up, roughly 1382.118028 *10^47 or 1.382118028 *10^50 or to put it more simply: 138.2118028 american quindecillions

[DrewPH]

"interesting facts"

I think that's perhaps overstating it.

[that one in the corner]

So many IP addresses in the Suez Canal

Obviously that is down to all the spyware buried inside the cheap tat being shipped from China.

That is why the stuffed toy is always tiny compared to what you thought the picture showed, shipped inside a too-big box: disappointing the kid when it is unwrapped is just one purpose. The other is - well, you know that crinkly stuff filling the otherwise empty package? That isn't simply old fashioned excelsior, it is a cunningly designed fractal omnidirectional antenna for the Starlink connection. And have you noticed how the bubbles in the wrap they use is a slightly different size from the stuff we use? Tuned cavity! They are watching everything and now have a detailed map of every tat-filled seaside gift shop, which can be targeted to make our rain-soaked Summer hols just slightly more bleak. The fiends!

[Graham Dawson]

Re: So many IP addresses in the Suez Canal

They don't want you to know that aluminium foil, when folded or crumpled, forms a highly efficient antenna that if placed on the head, can be used as a simple neuralink analogue. The most obvious effects are docility and lack of scepticism, but also slavish interest in bizarre television programming and unswerving obedience to certain "masters". Once a person has donned a foil "cap" in this way, they're lost to everyone.

[kmorwath]

Since the smallest prefix allocation to a customer should be a /64...

... and RIRs ask to allocate at least a /56, to allow for VLANs - the actual math is a bit different. What matters is how many prefixes can be assigned from the IPv6 pool, and that depends on the average prefix size.

[Roland6]

Re: Since the smallest prefix allocation to a customer should be a /64...

What also matters is the “standard “ prefixing and subnetting ie. That which is baked into firmware and hardware, helping to minimise routing table and processing overheads.

[Anonymous Coward]

Re: Since the smallest prefix allocation to a customer should be a /64...

I hope not. "standard" prefixing baked into firmware and hardware are what made many of the adaptions to IPv4 so difficult to make. (CLASS assumptions is one example)

There is no reason to hardcode prefixing and subnetting. If it's a /64, specify it as a 64 - no need to make assumptions anywhere. It doesn't add to routing tables or processing.

[TJ1]

Re: Since the smallest prefix allocation to a customer should be a /64...

The Starlink user terminal (UT a.k.a. dishy or antenna/router) has a Starlink-network /64. The customer router (in bypass mode) or the Starlink LAN-side router/Wifi AP gets a Starlink-customer /64 and in addition the UT offers a /56 prefix.

So each /40 allocation can support up to 64k delegations and the /32 allocations can support up to 16.7M.

[Pascal Monett]

2^128 addresses

340 undecillion. For those of you, like me, who simply can't grasp the beauty of exponents, here is what that number looks like :

340282366920938000000000000000000000000

That's 340.28 trillion trillion trillion addresses (because I just learned of the existence of the word 'undecillion', and I still can't grok that).

Seems like a lot to me, but okay, IPv6 was apparently designed to be future-proof, so with enough space to guarantee that colonies on the Moon, Mars, Ganymede, the asteroid belt and the rest of the Solar System would be able to connect. Apparently, we'll have to invent a new version of NAT translation when we invade colonize Alpha Centauri. We'll handle that when we get there.

In any case; Starlink claiming that it has over 150 sextillion IPv6 addresses means that it holds, wait for it : 360 trillion trillion addresses.

We have an estimated 8 billion people on this planet. That means Starlink is hoarding enough IPv6 space to allow for more or less 125 billion IPv6 addresses for every single living person on the planet.

Now I realize that all that fucking "smart" tat that is being sold is going to take up a portion (mathematical, >0) of that space, and smartphones are selling like hotcakes despite the fact that, like PC tech, the newest version is now only incrementally better (for a given definition of 'better') than the previous one but still, it seems to me to be a bit much for one company to hold.

What in God's green Earth is Starlink doing with all of that address space ? There has to be a technical reason. No company buys address blocks for bragging rights.

[Roland6]

Re: 2^128 addresses

Surely Pascal that’s:

340.282.366.920.938.000.000.000.000.000.000.000.000

> There has to be a technical reason.

I presume they will be assigning each end point a /56 or a /64 address, just like fixed line ISPs.

Also they probably need each individual address space to be of some specific size so that it can handle all the potential end-points in some geographic region or what ever Starlink are dividing the world into to be able to efficiently route stuff.

[wangi]

Re: 2^128 addresses

>What in God's green Earth is Starlink doing with all of that address space ? There has to be a technical reason. No company buys address blocks for bragging rights.

You're looking at this from an IPv4 perspective, rather than IPv6. Compare my ISP / Starlink dynamically allocating me a single IPv4 address, vs it giving an IPv6 /48, /56 or /64 allocation. The "meanest" of those, the /64 which Starlink allocates, is 18.4 quintillion IPv6 addresses. So what really should be compared is the gross number of addresses divided by the range allocated to each terminal.

https://en.wikipedia.org/wiki/IPv6_address#General_allocation

[Anonymous Coward]

Re: 2^128 addresses

Yeah, this is nothing to brag about. The smallest default allocation of IPv6 space you get from RIPE is a /32, which is 79 septillion (a septillion is a thousand sextillions) individual addresses. You only have to ask them over email to have that extended to a /29; which holds 633 septillion addresses.

Then again, as pointed out in other parts of the thread, the allocation of IPv6 addresses to end customers is sooo wasteful! We delegate a /56 to all our residential cable Internet subscribers; as per the norm. We tried allocating a /60 at first (which of course is "only" 16 x /64 subnets; or 295 quintillion addresses) but some customers actually complained. They needed the full 4.7 sextillion addresses, apparently.

RFC6164 FTW.

[John Sager]

Re: 2^128 addresses

I've got a /48 from my ISP, and only used a /64 until the other day. Now I've just used another /64 to upgrade my private VPN to carry IPv6. I guess I'll need to use some more if I start using v6 IoT stuff.

[Nanashi]

Re: 2^128 addresses

It's not wasteful. Those bits serve a useful purpose, and a /56 is the same fraction of the v6 address space as one 0.4% of one TCP port of one v4 address is of the v4 space. Would anybody argue that allocating 0.00000006 IPs per customer was wasteful in v4?

They needed the full 4.7 sextillion addresses, apparently.

It's implausible that they needed all of those IPs, but needing more than 4 bits of subnetting space isn't difficult. Especially if you start doing sub-delegations inside your own network (which is ideally done on multiples of 4 bits because that means you can subnet by character in the IP address rather than needing to get your subnetting tables out).

Thinking in terms of number of IPs is v4 thinking. You don't bother doing that in v6, because there's so many of them it just doesn't matter.

[t0m5k1]

sense made = none

So if Starlink owns:

150 sextillion IPv6 addresses

350,000 IPv4 addresses

Why do they use CG-NAT ?

[GNU Enjoyer]

Re: sense made = none

Since there are over 6 million users now, 350,000 addresses aren't enough to provide IPv4 connectivity without nasty hacks like CGNAT.

Starlink is likely collecting address allocations while it's still possible (there are no IPv4 addresses left for allocation, thus those need to be purchased from those no longer using certain ranges for a fortune), so at least 340,000 users can be offered non-broken IPv4 connectivity - which might eventually be reached (although the limits of radio communication severely limits the connection speed for any area with more than a small number of users might be an issue before that stage).

[Sok Puppette]

IP geolocation is evil

It doesn't meaningfully "fight crime", but it does fight privacy, while giving idiots yet another set of knobs to tweak to break things.

[Anonymous Coward]

"As of July, Elon Musk’s space ISP had 1,379 /24s, plus hundreds of smaller blocks, and therefore over 350,000 IPv4 addresses to play with."

It is not completely clear what the author meant by "hundreds of smaller blocks", the word "smaller" would imply blocks containing fewer IP addresses and so with a prefix length of between 25 and 32.

However AFAIK IPv4 subnets with a prefix length of greater than /24 cannot be announced in the global routing tables (i.e. via BGP).

Perhaps the author actually meant "hundreds of blocks with a shorter prefix than /24" (i.e. larger blocks)?

[doublelayer]

They're talking about entries in a file listing locations, and the entries there (that file is public) are smaller, including many /25s and /27s. I have not bothered to check whether those all fit together into neat /24s and are just divided here for geographic tracking or whether they might be splitting blocks with someone else and routing internally to handle that, but when the article refers to smaller blocks, they are talking about smaller blocks.

[Anonymous Coward]

Whilst the article is about geolocation for Starlink IP addresses the particular sentence I quoted:

"As of July, Elon Musk’s space ISP had 1,379 /24s, plus hundreds of smaller blocks, and therefore over 350,000 IPv4 addresses to play with."

is not talking about "entries in a file listing locations", it is general comment referring to the total IPv4 address space that Starlink have available to use.

My previous post pointed out that BGP announcements of IPv4 blocks with a prefix longer than /24 are generally not supported on the Internet (in order to control the size of full routing tables) and therefore Starlink wouldn't have such IPv4 blocks "to play with" (i.e. to be Internet accessible) unless some ISP(s) were BGP announcing shorter prefixes (i.e. <= /24) that included the contents of those "smaller" blocks.

[doublelayer]

"is not talking about "entries in a file listing locations", it is general comment referring to the total IPv4 address space that Starlink have available to use."

That's probably what it should have been, but that is not what it is. They were still using the entries directly from Starlink's geolocation feed. Since you want to know the details, I've just retrieved the same feed (keep in mind that this is now the October feed rather than the July one), and they have gained some more /24s, now listing 1437 of those. And they list several smaller blocks, specifically 470 /25s, 131 /26s, 152 /27s, and 6 /28s.

You are correct that they won't be announcing these as /25s and smaller in BGP. That is how they list them in the file, and that is where the numbers in the article, even the general ones, are coming from. In a slight defense of the article, this represents the IPs Starlink claims to operate, so it is more representative of the number of addresses in use than the number of addresses they own would. If we analyzed this further, we could determine how they are announcing these smaller blocks and whether they completely own the large blocks from which they cut them, but I don't care. If you want to make more sense of the article, you have the background.