ARIN is out but your ISP has extras. Why doesn't your ISP sell its extras, since a scarce resource should have monetary value?
Routing tables.
Selling individual IPs off piecemeal isn't practical because routers simply do not have enough RAM to handle the enormous routing tables that would resultantly be necessary in order for packets to find their destinations.
The problem with IPv4 is that when ISP can't get more, so they have to put some unlucky users behind a NAT. The company I worked for got /21, but we had way more than 2K simultaneously connected users. And, well, we failed the timing to get another allocation, and (I had left since then) is even more unlikely they'll get one those days.
IPv6 solves that by making all the blocks giant. With IPv6, when ISP is allocated /48 and allocates /64 per client - comparing to IPv4, it's like everyone gets a mighty /16 block right from the start, so even a tiniest company can grow to 65K users. And if they grow more, there is no problem in getting another subnet, those are not scarce, too.
The logic still stands, it's just that problem's solved by just making everything giant.
With IPv6, we have enough bits of address space that we can drastically over-provision each level of delegation -- by orders of magnitude, if necessary -- and still have plenty of room to spare. e.g. as a home customer, my ISP gives me a /56 with no questions asked, which means 256 subnets each with an effectively unlimited number of devices.
In theory, this means it should become very rare for a single physical or logical network to have non-contiguous addresses. Which in turn means that routing tables can use a single prefix to cover an entire provider, instead of having to know about all of the individual sub-allocations.
There are some rival pressures here:
- IPv6 space is so abundant (and cheap to allocate) that you can have as much as you ask for. This obviously leads to massive overdemand, after which it's hard to reallocate while preserving the idea that everyone who owns space owns one contiguous block.
- You can counter that by restricting how much people can ask for. But at that point you're not using the full space; you're restricted to the amount that can be allocated, which is smaller.
- Not everyone will be on board with "I'm going to take as much space as I can get, just in case I end up needing a million times as much space as expected." But some of those less-demanding people really will end up with addressing needs in excess of what they anticipated. We could call this the Hofstadter's Law ("it always takes longer than you expect, even after accounting for Hofstadter's Law") of addressing.
We can't expect everyone to get things right the first time; we need a working reallocation system. If reallocation doesn't work, abundance alone isn't going to save us.
Eh, think of IPv6 as allocating from a 64 bit subnet space. So they're only allocating 1/8 of the address space.
> using the same proportions, the level above "home customer" might have a /25, the level above "ISP" might have a /10
More like /40 and /28
And once you are in the million-customer range you don't really need prefixes any more, but that gives room for more layers of generous prefixing and still having most of the address space spare.
Basically: you can't give everyone as much as they might ever ask for, but you can give everyone 10x as much as they seem to need and still have a dozen bits to spare
Right now, if you need more IPv4 addresses, you have to buy a /22 or so from someone else. Because the address space is so hotly-contested, that block could come from almost anywhere, which means every core router on the internet needs to remember where it lives on the actual topology.
With IPv6, maybe once in a while a customer comes along who needs more than a /56. No big deal; you just give them another (maybe non-contiguous, if you're unlucky) allocation from the ISP's block. The ISP needs to remember that both allocations belong to the same customer, and route packets accordingly. But everyone else can just route based on the ISP's all-encompassing prefix. That's what makes the system fundamentally more scalable.
The reason for that is because as of IPv6, DHCP is is no longer the standard way of getting an address. With IPv6 autoconfig each device assigns its own /64 address (either based on MAC, or randomly generated), thus subnets smaller than /64 are simply not practical for most use cases.
Having a /56 means you get 256 distinct subnets to assign as you please, just like you did with 192.168.0.0/16
A few things.
There's only 4,294,967,296 addresses in IPv4, so if you hand out giant blocks, you run out quite fast, whereas with 340,282,366,920,938,463,463,374,607,431,768,211,456 you could hand out huge IPv4 /8 sized blocks from now until the heat death of the sun if you wanted to.
But there's more to it than that. Right now only 1/8th of the IPv6 address space is "assigned to the internet", so there's effectively 7/8ths being held in reserve for the foreseable future -- this is partially to accommodate realistic router memory limits in the near term. IPv6 also has a more efficient hierarchical routing scheme than CIDR (which was kind of bolted on to IPv4 after-the-fact), which helps keep router tables from consuming terabytes of RAM. And IPv6 is designed to be more easily renumberable when we do make mistakes with assignments, with a clear separation between subnet prefix all that requires is changing the routing prefix.
At the end of the day, with 340 trillion trillion trillion addresses, handing out too many isn't ever going to be a big worry in the foreseeable lifetime of...anything, really.
Well, why can't I have them all?
Before spending some time in a wireless sensor net research lab as an undergrad, I had a difficult time imagining the scale of an application that could justify such a massive network address space...probably because I was too focused on trying to visualize what it might look like without considering the possibility that it would be invisible to the human eye.
[1] http://www.eecs.berkeley.edu/~pister/SmartDust/SmartDustBAA9...
there are 3.4 * 10^38 addresses in the IPv6 space
we could individual address every water molecule on earth and still have an enormous amount of space left over
so even if DARPA is planning on replacing the oceans with dust (and somehow managing to not exhaust a number of critical resources in this drive to make a truly staggering volume of dust), it's still not an issue
I was thinking more along the lines of an architecture adopted today which survives many millennia into the future that accounts for exponential human population growth on a galactic scale, isn't limited by the natural resources of this planet, where increment() will be the only pragmatic address assignment operation, meaningful archaeologic insight might be attained by discovering a microscopic 128-bit invariant, and so on.
path MTU discovery algorithms aren't going to be efficient when packet transit times are measured in decades, for one thing
In an internet-usable sense, there's fewer than that, too. The entire 127.0.0.0/8 block is for localhost/loopback, for example.
If there's software that treats IP traffic to or from 240.0.0.0/4 as invalid, then it's defective. I mean, I get that the broken software is a concern, but -if we care about carving out more IPv4 space- it's not something that we should be overly worried about. :)
[0] Indeed, mDNS/Bonjour/Avahi uses 224.0.0.251 for service discovery.
It's far too late for that now. :( Perhaps if IPv4 multicast were more widely used on The Internet the large carve-out would look more sensible to you.
> That range isn't general-purpose IP space.
Yeah, that's a true statement. Just remember that "reserved" has a particular meaning when it comes to IP address ranges. :)
Well, according to [1] the sun will stay white-hot effectively forever. But, given that it will continue in its current state for another 5 billion years, and that there are 2^96 IPv4-sized blocks in IPv6's address space, one could give out 2.5e21 IPv4-sized blocks every second from now until the end of the sun's lifespan.
So yeah, IPv6's address space is really, really, tremendously, amazingly, enormously big.
[1] http://astrosociety.org/edu/publications/tnl/39/sun2.html
For a 256-bit key, give each electron from above it's own universe, and assign values to all. That's the keyspace to be broken.
Bruce Schneier once did a little thought exercise where he demonstrated that, assuming one needed to shift one electron (the absolute minimal amount needed to conceive of a compute switching operation), the energy requirements needed to brute force the key would exhaust the energy potential of the solar system.
"These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space."
Interesting to ponder.
(Source: https://www.schneier.com/blog/archives/2009/09/the_doghouse_... )
Seemed close enough.
Make it known from the start that when the currently unallocated blocks are needed they will be used, and if that breaks things for people who have used them already that is their fault and their problem to fix.
Can you point me to some information about this? I apologize if this is an easy question I am interested in ipv6 but only know enough to be confused more often than not.
Gates already made that mistake.
I know "this time is different", but if you start thinking of "internet of things", where literally every little thing in the world can be called (so needs its own name/number/ip/etc), then at some point we might run out of those numbers as well.
I'm not sure how much (2^128) / 7 000 000 000 is, but it seemed not alot of every human's property can have its own address.
And all of sudden, 640 kilobytes is not enough.
Well, to put it into perspective, imagine that humans would colonize planets around all 400 billion stars in our galaxy (let's say that each star has 10 planets), with 7 billion people on each of them, and each person having 7 billion devices, each device could still have almost 2 million unique addresses available. The range by itself IS big enough for any foreseeable future. The problem may come from the fact that not all that range is available for use.
This is untrue, and a big over exaggeration.
Consider that pretty much any business (even a mom-and-pop shop) is allocated a /48 if they ask for it. Assuming one thousand /48 are allocated every second (ie. one thousand "business" IPv6 users coming online per second, which might be absolutely plausible 100+ years from now --we made IPv6 to be future proof right?), then we would run out of allocatable blocks in the global unicast IPv6 space (2000::/3) in 1,115 years. And we would run out of allocatable blocks in the entire IPv6 space in 8,919 years. So, yeah, I get annoyed when people mention the "death of the sun" or the "lifetime of the universe" when talking about IPv6, when in fact we could start running into exhaustion issues in the next ~1000 years.
Note that I am being pedantic here. I think any technology that seems to scale "only" for our needs up to ~1000 years from now is good enough :)
http://www.wolframalpha.com/input/?i=%282%5E125%29%2F%282%5E...
What IPv6 have address-space-wise, is 2^64 subnets, out of which 2^61 is actually allocated to be routable over public internet.
Then comes granularity of /48 allocations (= 2^16 subnets) to end users and /32 allocations (= 2^32 subnets) to ISPs. That gives just 2^45 end users and 2^29 ISPs at best. In practice, if handing a user a /48 would become a common practice, all medium and large IPSs would start accumulating multiple /32s, then routing concerns would come back, and largest ISPs will start aggregating to /28s or /24s or whatnot.
That is still a whole lot of addresses (and IPv4 still looks laughably small in comparison), but actual, practical numbers are way, way lower then "340 undecillion" marketing figure being plastered all over the place.
There are currently half a million active BGP entries. There's no reason to massively change that number.