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)
Well it should be redesigned so it works all the way down to individual addresses.
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.
Why? What's wrong with how it works at the moment?
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.
Collisions are very unlikely, and a quick ARP packet should detect them if they do happen.
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.
You can do that, sure. But it's more complex and slower.
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.
At least with the current state of affairs, you have the option to use ND Proxy instead of NAT66.
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.
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:
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.
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 is also not global; if it is part of IANA's unicast allocation (2000::/3) it is global.
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...
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.
A reasonable sized /32 allocation would have allowed for giving every ATM they operate worldwide its own globally routable /48.
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.
* 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.
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.
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.
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/[email protected]/msg0...
Example reddit discussion : https://old.reddit.com/r/ipv6/comments/17yuqvp/til_capital_o...
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.
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 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.
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).
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).
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.
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.
Of course we'd all be paperclips long before they need to worry about networking
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.
(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)
Weren't they supposed to allocate a /48? Or did that change while I wasn't looking?
2^32 is ~4.3*10^9
2^64 = 2^32 * 2^32 , so quite a bit moreHave 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.
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?
- 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.
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 :)
These do not have to be globally unique, just unique on the local network.
* 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.
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.
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.
So that vast address space might not last as long as it would seem...