Hacker News Reader

Comment by p-e-w | Hacker News Reader

The last time I looked into this (which was a few years ago), ISPs were allocating blocks containing billions of IPv6 addresses to anyone who paid a nominal sum.

So that vast address space might not last as long as it would seem...

View on HN

> So that vast address space might not last as long as it would seem...

Have you done the math?

* math property: x^y = x^(a+b) = (x^a )x(x^b )

* IPv4 addresses are 32 bits (2^32 )

* 2^32 ~ 4.3 billion

* So the IPv4 Internet has ~4.3B devices on it

* IPv6 subnets are 64 bits, /64 (2^64 )

So, a IPv6 2^64 subnet is the same as (2^32 )x(2^32 ), which means (4.3B)x(IPv4 Internet). I.e., a single IPv6 subnet can hold the equivalent of four billion (IPv4) Internets.

A second way of thinking about it:

* Stars in the Milky Way: 400 Billion

* Galaxies in the universe: 2 Trillion

So (4x10^11 )x(2x10^12 )=8x10^23 stars in the universe.

* Size of IPv6 address space: 3.4x10^38

Find the ratio between addresses and stars:

* 3.4x10^38 / 8x10^23

IPv6 offers about 430 trillion times more addresses than estimated stars in the universe.

A third way: On the surface of the Earth (land+water), there are 8.4 IPv4 addresses per km2. Not counting the oceans, that would be 28 IPv4 addresses per km2 of land.

IPv6 gives 10^17 addresses per mm2 (yes, square millimeter).

In terms of volume, 10^8 IPv6 addresses per mm3 throughout the Earth.

Since you seem to know what you're talking about:

Imagine a scenario where we have nano-bots to perform "repairs" in our bodies or whatever, and obviously each individual nano-bot use TCP over IPv6 because future software developers are also as lazy as us.

Instead of taking paracetamol, people take nano-bot-shots which include (presumably) millions (or even billions?) of nano-bots that we inject into our bodies. However, they disappear after a week (or some other more realistic timeline).

Now, how many people can use these on a monthly basis before we run out of IPv6 addresses?

Are you implying that we would assign a public /64 subnet to a collection of nanites that were designed to be absorbed after a week in the human body, and then retire that subnet forever? This seems like an unlikely scenario, but I'll assume it's just an intellectual exercise and take a stab!

- Total number of /64 subnets available: 2^64

- Total number of humans in this future: Let's say 16 billion (roughly twice what we're at now)

To get the total number of months before we'd run out of /64 subnets, assuming each human is absorbing one every month, we divide the number of /64 subnets by the number of humans:

2^64 / 16 billion =~ 1,152,921,505

Divide by 12 to get the total number of years:

1,152,921,505 / 12 =~ 96,076,792

So by my math, assuming the human population stayed steady at 16 billion (which seems just as absurd as the initial premise) we'd have about 100 million years to figure out how to start reusing some of those old subnets before we started running into trouble.

> Are you implying that we would assign a public /64 subnet to a collection of nanites that were designed to be absorbed after a week in the human body, and then retire that subnet forever?

No, I meant it as "You can reuse the subnet after 1 week + N" basically.

> it's just an intellectual exercise and take a stab!

Indeed it was, and thanks for conjuring a gratifying answer :)

IPv6 devotes a giant chunk of space to ephemeral link-local connections, if I recall correctly, at least a /64. So you'd need about 10^18 nanobots or so before you start to have to worry about link local address exhaustion.

These do not have to be globally unique, just unique on the local network.

Official assignments are at:

* https://www.iana.org/assignments/ipv6-address-space/ipv6-add...

Currently all public addresses are being assigned out of 2000::/3. The following are reserved for future (public?) use: 4000::/3, 6000::/3, 8000::/3, a000::/3, c000::/3.

Everything that starts with "f" is a special case, so the vast (vast) majority of address space is cleaved off.

I think this turns out to be a pretty good example of how stupidly big the ipv6 space is. Because it sounds like a big ask until it meets the numbers.

So you want "even billions(!!1!)" of nanobots per allocation. Well I'm lazy, and dynamically allocating a /64 is built right into the protocol. So lets let my medication dynamically allocate out of a /64. How many billions? Billions of billions. So lazy, so sorted.

But of course, I don't want my medication talking to my wife's medication. So lets de-conflict that. In fact, let's de-conflict everyone's medication.

We all know that 32bits is a bit over 4 billion. So 33 bits is going to be a bit over 8 billion. That's enough for now, but it's iffy, so let's go for 34bits, a bit over 16 billion. But in ipv6 world, it's polite to land on a nibble-boundary, so we'll go for 36 to be polite.

I'm going to steal the old allocation for ULA as an example. It was /7, but I'm going to call it /8 because I like round numbers.

So lets have an 8-bit prefix ala ULA. Then an 8bit planet number. Then an 8bit country/healthservice/issuingbody number. Then a 40bit human number, because I ran out of reasons to waste 8's There's our 64bit network number. With 64 bits left for billions of billions of nanobots to dynamically allocate.

The best bit about ipv6 isn't billions, it's that we get to actually structure our networks instead of cramming them into every nook and cranny we can buy.

https://xkcd.com/865/

That sure sounds like a lot. But "billions" is less than a /64. Try "sextillions" (/56) or "septillions" (/48). Of course, when the denominator is "undecillions", it becomes clear that this is actually a non-issue.

I'd even go out of my way and say that undecillion of IP addresses ought to be enough for anybody.

Bold prediction! Let's see if it holds true in 200 years when every cybernetic cell in your body is individually addressable from the public internet.

This is almost IPv9 (RFC1606)! https://datatracker.ietf.org/doc/html/rfc1606

   The up to 42 deep hierarchy of routing levels built into IPv9 must
   have been one of the key features for its wide deployment. [...]
   As yet, no requirement has been found for levels 40-42, with level 39
   still being used for experimental interrogation of atomic structure
   of components where required.

Of course, it's a 1st April RFC. For those who don't know them, see https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_C...: they include thinks like terminals with subliminal messages, IP over pigeons...

98% of all IPv6 addresses will be set aside for self-replicating nanobots and our bodily cells will have to fight over only the remaining 2%.

ARIN recently handed out a /16 allocation to Capital One. That is one 65,025th of all of IPv6.

A reasonable sized /32 allocation would have allowed for giving every ATM they operate worldwide its own globally routable /48.

Too bad ARIN tickets aren't public - I would love to read the one in which that was justified. Reading NRPM 6.5.2.1, it seems that they must have submitted documentation claiming at least 2^28 distinct serving sites in order to qualify for an assignment that large.

I find the insistence of using /64s everywhere for networks frustrating. Any network larger than a /112 seems crazy, that's already 65k IPs per subnet. A /104 for every normal end user (256 subnets per user), or a /80 for massive companies like Capital One (4 billion subnets) should be more than enough.

There is a really practical reason behind this, and it is called "routers". Due to longest prefix match, you'll end up wasting resources on the networking hardware. And you waste both precious and expensive TCAM and LPM latency for matching the prefixes. So routers do optimize for anything shorter than /64, and have special lookup memory for /64 and /128. But nothing in-between.

That's fair enough, in which case ipv6 is really only a /76 (having more than 1000 hosts on a subnet isn't a great thing, even with no broadcast and arp and other traffic, and /76 allows 4000 on a /64)

Those fanboys going "we'll never run out of 2^128 IPs" are being disingenuous when about 2^59 of them have been burnt straight away (I'd guess most subnets have less than 30 devices)

2^64 subnets is a reasonable number, but when they are handed out like candy that number dwindles quickly. ARIN is allocating the equivalent of a /15 every year. That's fine if it's a constant allocation, there's 100,000 years worth, but if that rate grows, the space will be eaten in a matter of a few decades.

It's not being burnt, there are two useful things we're doing with the 64-bit network size:

* Sparse networks. 64 bits is too big to feasibly do a brute force scan on, which reduces how often servers get exploited by random network attacks. * SEND secures NDP by using those 64 bits for a public key

Reducing network sizes to 12 bits would destroy both advantages.

This still not justifies a /16 allocation

thankfully I replied to a comment speaking about a tangent (/64s) and not to its parent. /s

Snark aside, very much agreed, and I don't like that they got away with it. It's precisely with the mindset of "we'll have enough" that companies like ford have a /8 or the DoD has more /8s that we can count. And with this mindset we'll run out of IPv6 the same we ran out of IPv4.

Except you need at least a /64 for v6 to properly work.

You only need it because that's how the protocol was designed.

You only need it for SLAAC, and only because SLAAC was made that way.

It's not just about the number of devices. Stateless Address Autoconfiguration for example basically needs a /64 subnet.

because it was designed that way. "we need it because we need it".

Having a ludicrously large address space is kinda the point of IPv6.

You're not ment to utilize every address assigned to you. Trying to do so will always lead you to situations where you messed up and need to renumerate.

>ARIN recently handed out a /16 allocation to Capital One. That is one 65,025th of all of IPv6. A reasonable sized /32 allocation [...]

The more one digs, the more egregious it seems. If the NETIFY webpage is accurate, it shows that Capital One already had "/32" and "/36" blocks, and yet they also got "/16" : https://www.netify.ai/resources/networks/capital-one

And if I'm reading the ARIN fees correctly, it only costs $4000 annually for a "/16" allocation: https://www.arin.net/resources/fees/fee_schedule/

There doesn't seem to be any public transparency of the approval process to explain how a non-ISP company could justify a "/16" block so it just leaves everybody guessing.

John Sweeting from ARIN only confirmed that the "/16" was allocated to Capital One according to policy but he didn't elaborate on the rationale: https://www.mail-archive.com/arin-tech-discuss@arin.net/msg0...

Example reddit discussion : https://old.reddit.com/r/ipv6/comments/17yuqvp/til_capital_o...

> And if I'm reading the ARIN fees correctly, it only costs $4000 annually for a "/16" allocation:

For better or worse, you're not; that's for IPv4 /16. For IPv6 /16, it'd be the X-Large service category, so $16,000/year.

And for $256,000/year you can... exhaust the entirety of 2000::/3?

Yeah, that's not okay. Either the price needs to go up a lot or they need to include factors other than money in the allocation criteria.

> they need to include factors other than money in the allocation criteria

They already do, and simply being able to pay the fee does nothing to qualify you for an allocation: https://www.arin.net/participate/policy/nrpm/#6-ipv6

At least, in theory. I'm not going to attempt to defend the Capital One allocation.

They might have included them in the published policy, but it seems they aren't in whatever policy they're actually following.

It seems more likely to me that ARIN is following the text of published policy, but Capital One found a way to interpret it that violates its spirit. My guess is that they're treating each customer debit/credit card as a serving site that qualifies for a /48. To address this, ARIN should fix the policy, not raise fees.

It's ARIN's job to call BS on BS justifications, otherwise they're not following the policy, they're following whatever they allow. "The purpose of a system is what the system does" and all.

That's an interesting idea for how they justified it. There might be something like 4 billion active credit/debit cards in the US (but they probably weren't all issued by Capital One).

I'm sure people said exactly this about IPv4 back in the days.

Can you even begin to imagine a use case that could come close to exhausting an IP space that is perfectly capable of assigning a /60 subnet to every single grain of sand on earth?

That subnet is large enough to then assign an IP address to every individual atom in that grain of sand.

For comparison, if we wanted to assign every living person on Earth a grain of sand, we would only need a few cubic feet of it (less than 1 cubic meter).

Nanites might give you a good start

Of course we'd all be paperclips long before they need to worry about networking

> Can you even begin to imagine a use case that could come close to exhausting an IP space that is perfectly capable of assigning a /60 subnet to every single grain of sand on earth?

As parent said, I'm sure people made the exact same argument about IPv4 back in the day, but comparing it to something else.

And when IPv16 finally appears in the future, people will yet again make exactly the same argument.

> As parent said, I'm sure people made the exact same argument about IPv4 back in the day, but comparing it to something else.

You're ignoring the sheer scale of this question. We don't have enough raw materials on this planet, or likely in the observable universe, to produce enough devices that would consume that many IPs.

We could colonize 1 billion planets.

Each of those planets could have 100 billion people.

Each of those 100 billion people could own 1 billion "things" that could be considered "networked devices".

Each of those "things" could consume 1 billion IPs.

We could have all that, and we would still have 70% of the IPv6 space left.

> The decision to put a 32-bit address space on there was the result of a year’s battle among a bunch of engineers who couldn’t make up their minds about 32, 128 or variable length. And after a year of fighting I said — I’m now at ARPA, I’m running the program, I’m paying for this stuff and using American tax dollars — and I wanted some progress because we didn’t know if this is going to work. So I said 32 bits, it is enough for an experiment, it is 4.3 billion terminations — even the defense department doesn’t need 4.3 billion of anything and it couldn’t afford to buy 4.3 billion edge devices to do a test anyway. So at the time I thought we were doing a experiment to prove the technology and that if it worked we’d have an opportunity to do a production version of it. Well — [laughter] — it just escaped! — it got out and people started to use it and then it became a commercial thing.

- https://www.youtube.com/watch?v=mZo69JQoLb8&t=816s

They were contemplating 128 bits addresses all the way back then, but settled on 32 bits as a mere proof of concept that got out of hand.

One use case is private entities squatting on massive ranges that they have no hope of ever practically using, and thereby extorting other people and organizations as the rest of the address space gets massively over-allocated to other uses.

Allowing a credit card company to have a /16 is one way to do it. Do that 65,535 more times and IPv6 is exhausted.

Fair point, but that's politics and bad actors, no standard can survive that.

So the funny thing is .. they didn't. They really didn't.

The original numbering plan for IP was that each network number became a /8. Which is how we miraculously ended up with 10/8, because network 10 was ARPANET itself, so 'flag day' left 10/8 vacant.

But back to the point at hand. IP itself is RFC 791, September 1981, nice and famous. The addition of classful networking because 255 network numbers wasn't going to last long, was RFC 790.

The first workaround for IP exhaustion was published before IP. It's been a Known Issue since day negative-one.

One of the features of IPv6 is address autoconfiguration, obviating the need for a central authority like DHCP on v4.

However, that only works with a /64 prefix and given that larger sites might want to have multiple subnets, that’s why most assignments are /56 or /48.

But still. If all assignments were /48s, that would still leave room for 281 trillion networks which even I believe is enough for the foreseeable future.

If the number space is so big, it makes sense to take advantage of it if that allows for other additional features (like SLAAC)

> However, that only works with a /64 prefix

Well it should be redesigned so it works all the way down to individual addresses.

You can use DHCPv6 instead of SLAAC if you need autoconfiguration on sub-/64 prefixes.

Some systems like android don't support anything but SLAAC

IMHO it means that they are not fully IPv6 compliant. Corporate networks often have DHCPv6 rather than just SLAAC.

They are fully compliant, SLAAC is part of the standard whereas DHCPv6 is an optional extra.

DHCPv6 also does not work without RA. DHCPv6 just assigns an address, a routable prefix, dns servers etc, it does not assign a subnet or any routes, you need route advertisements for that.

Seen like this, you can also argue that DHCP is an optional extra for IPv4, but it almost essential in most networks. Sure, IPv4 has no SLAAC that can be a valid alternative, but still, given that SLAAC doesn't solve every use case...

> Well it should be redesigned so it works all the way down to individual addresses.

Why? What's wrong with how it works at the moment?

I actually have the issue where my ISP gives me a single /64 and it makes it difficult to split between multiple LANs.

Published guidance says they're meant to give out at least a /56. I don't know that making autoallocation work on smaller subnets would help with this problem - ISPs that currently give out the smallest possible subnet would probably just switch to whatever the new smallest possible subnet was.

There probably is a way to ask my ISP for a larger block, but I think it would be nice to be able to subnet a /64 regardless.

CIDR and the resulting address space fragmentation was the problem that IPv6 was originally meant to solve; allowing splitting into random-sized subnets makes routing more complex and worse. And if you made the routable part of an IPv6 address longer than 64 bits then that makes the routing much more compute-intensive. 64 bits in the local part of the address is sort of overkill, but a 128 bit address isn't really any harder to use than a 96 bit address, and it means things like, well, being able to automatically assign the local part based on the MAC address, which only works if the local part of the address is more than 48 bits.

You can still use a shorter hash of the Mac address.

Collisions are very unlikely, and a quick ARP packet should detect them if they do happen.

> Collisions are very unlikely, and a quick ARP packet should detect them if they do happen.

You can do that, sure. But it's more complex and slower.

It would rather be an ICMPv6 neighbor discovery packet or something like that, IPv6 doesn't use ARP.

Collisions are just as likely with the 48 bits as they are with the last 24 bits, as some OUI vendors reuse mac addresses.

Using a mac address in the IP is terrible anyway from a privacy point of view, use a random IP in the subnet, send out a check to see if it's already used, if it is choose a new one. That check is already a feature of ipv6.

On Comcast Business the SLAAC would hand out a /64, and DHCPv6 would give you a /64 unless you requested "Prefix Delegation" in which case they'd give you a /56, /58 or /60 depending on how large your static IPv4 allocation was.

Some do give you one but in the most incorrect way possible. When I had fibre through Orange France, they properly allocated a /56 to my connection, but the ISP provided router only routed the first /64 from the block. The UI even proudly displayed the full /56 in all of its glory followed by a "xx/64 usable".

Oh and I ended up disabling IPv6 altogether as their router would crap itself with a modest amount of IPv6 traffic. Pulling ~10Mbps of IPv6 would completely DoS the router, as it would not even go as far as answering to ARP. Some quality hardware for sure.

What do you mean by that? What you do inside your assigned range is completely up to you - you can split that up as you want.

Not if you want SLAAC to work in each LAN. Basically in IPv6 each LAN is supposed to have a /64, that's the real minimum allocation by design. Per the official recommendations, ISPs are supposed to give every individual customer at a minimum a /56.

Ah, right. That leaves a custom dhcpv6 pools config for you...

This is the same as if you get a /24 from your ISP, but the ISP has the .1 address on their router. In this case, you can't (easily) subnet the v4 range either, since the ISP router expects to be able to arp for all the 254 ips, meaning you have to resort to trickery in order to make subnetting almost work.

Same goes for ipv6. If you get one single net (and a 'small' one at that), you once again have to resort to trickery to subnet at your end.

Preferably in both cases, you would get a small (/31 for v4, /127 for v6) transport net that goes to the ISP router or your first fw device, then the ISP routes the real net /24 (or whatever size you can get from it on v6) behind your IP on the /31,/127 so that your first device can split this in any way you prefer.

Shitty ISPs will always give you as little as they can get away with. If the software enforces /64, they'll you /64. Raise the limit to /128 and they'll give you /128.

At least with the current state of affairs, you have the option to use ND Proxy instead of NAT66.

Doesn't AWS currently hand out /128?

If you create a v6 VPC you can choose /44-/60. Subnets can be between /44-/64.

There was a proposal for that: https://www.ietf.org/archive/id/draft-mishra-6man-variable-s...

But they aren't all /48s. Upthread there's a post about /16s already being allocated.

I still haven't figured out how to get these auto-configured addresses into my home network's DNS (or any DNS, for that matter).

It is pretty easy on OPNsense but it's virtually impossible on many other types of routers. Meraki and Asus as two examples of that.

I'm actually running dnsmasq from a FreeBSD host. How would dnsmasq know about the self-configured addresses? I guess I could run DHCPv6, but it's next to impossible to get any kind of prefix delegation going with my ISP anyway. At the moment their router hands out the v6 addresses and I use v4 for dnsmasq.

I don't understand why getting rid of DHCP is desirable. DHCP provides a nice central place where you can map MAC addresses to IP addresses instead of configuring it ad-hoc on every device which needs a static IP address (if you're lucky and the device even supports static IP!). Checking "Does my interface have an IP address?" is also a really really useful and quick analogue for "is the gear related to the LAN pretty much working or is something broken/misconfigured?".

As it is, all my interfaces just have these random IPv6 addresses configured which don't work most of the time. I don't get it.

FWIW; SLAAC works by setting the local part to the mac address.

So, if you have knowledge of your mac address (which is what you say you are using for DHCP) then you will know the fe80::<> IPv6 IP too, which, while not globally routable is probably what you want based on this comment.

Wait SLAACs aren't globally routable? I thought the whole idea behind IPv6 was to not use NAT?

There's an education here that unfortunately I don't have the time to give you.

SLAAC is the replacement for DHCP, it provides a local prefix address (fe80::) and optionally (and, crucially: additionally) provides a publicly routable IP if there's a public prefix available.

You can think of the subject being split into two components:

As a base: You will get a local IP

On top: you get DNS/Public routing.

Here's a bit more about how it works: https://www.networkacademy.io/ccna/ipv6/stateless-address-au...

> Wait SLAACs aren't globally routable?

It is not the host-component of IPv6 that determines routability, it is the prefix.

If you have a link-local prefix (fe80::/10) then it is not global, if it is a private prefix (fc00::/7) then it also may not be global; if it is part of IANA's unicast allocation (2000::/3) it is global (firewall permitting).

> I don't understand why getting rid of DHCP is desirable.

It's less infrastructure to run, especially with embedded networks.

> DHCP provides a nice central place where you can map MAC addresses to IP addresses instead of configuring it ad-hoc on every device which needs a static IP address (if you're lucky and the device even supports static IP!).

You are limiting your thinking to macro-scale 'user-managed' devices, as opposed to things like embedded things:

* https://en.wikipedia.org/wiki/Matter_(standard)

ISPs are SUPPOSED to allocate a /64 for a single customer. Mine does, so I have 4.5 billion available addresses within my 2001:4653:nnnn:nnnn::/64 prefix...

  2^32 is ~4.3*10^9

  2^64 = 2^32 * 2^32 , so quite a bit more

> ISPs are SUPPOSED to allocate a /64 for a single customer.

Weren't they supposed to allocate a /48? Or did that change while I wasn't looking?

> Or did that change while I wasn't looking?

Yes: https://datatracker.ietf.org/doc/html/rfc6177

Billions of addresses might seem like a lot, but every IPv6 network has at least 2^64 addresses and it doesn't make much sense (to me) to give any customer less than one network.

(Maybe you meant billions of /64 blocks? ISPs could be providing a /32 ≈ 4 billion /64 blocks, though there still are 2 billion of those in the entire IPv6 space)

The space currently assigned to globally routable addresses is 1/8th of the v6 address space. Over 50% of the addressable space is currently reserved.

The numbers are frankly mind-bending. Even if we we make a complete pigs ear of assigning billions of IPs to billions of networks in the current /3, we have space for more than one do-over.

But I do believe there's a higher chance the next /3 will be assigned to Mars.

We never learn

Reply on news.ycombinator.com