ARIN (North America) and APNIC (Asia-Pacific) ran out of addresses some time ago (2015 I guess).
Game over IPv4.
Game over IPv4.
Theoretically we could have transitioned to IPv6 instead and avoided this hassle, but too many incumbents are dragging their feet on the whole IPv6 issue.
Fingers crossed they don't lol.
But IPv6 prefix delegation doesn't always work if you put your own router behind the ISP box...
However, I also have native ipv6 to the home for as many devices as I want. It's easy to forget that carrier NAT is expensive for ISPs as NAT hardware needs a lot of fast RAM.
This is why many residential ISPs and business haven’t implemented IPv6 yet (well, the later enjoys the false sense of security NAT provides too).
All they needed to do was expand the address space, but it looks like the kitchen sink got thrown in.
Another is that it changes the way you think about IP addresses, with endpoints getting a /64 instead of a single address like you did in IPv4. This allows users to change their IP address for every connection if they want, so if you want to apply policy to them you need to apply it to the entire subnet they are on. Granted, this also happens in IPv4 if you are doing NAT, so it's not really a change for most people.
There are a few other changes to stuff like QoS to better reflect modern practice, but for the most part it's pretty similar. Also, the IP header lost its checksum, as it was basically never useful.
Everyone that I talked to about this seemed to like the change.
End points get /128, it's just that subnets are now /64.
That simply means that endpoints can auto-assign themselves a new /128 because--instead ofhaving only space for 2^8 hosts in the typical /24 subnet of IPv4--there is now space for 2^64 hosts, which makes it unlikely that collisions will occur.
Only if you don't have a clue of IPv4 either.
> with endpoints getting a /64 instead of a single address like you did in IPv4.
That's just wrong. And endpoint gets one address, just as with IPv4 (and can optionally assign additional addresses where address space is available, also just as with IPv4).
What gets a /64 by default is a link, like, an ethernet. Which is also exactly like in IPv4, except, of course, with IPv4 you had shorter/fewer addresses, and thus obviously also smaller prefixes/fewer addresses per link.
> This allows users to change their IP address for every connection if they want, so if you want to apply policy to them you need to apply it to the entire subnet they are on.
Which is also exactly the same as with IPv4. If your LAN has an IPv4 /24, you can also change you address for every connection.
> Granted, this also happens in IPv4 if you are doing NAT, so it's not really a change for most people.
You have it all backwards?! NAT is what makes this impossible for connections to the public internet, in that no matter how you change your RFC1918 address, you keep the same address to the outside world? But that obviously is not a property of IPv4, but of NAT.
SLAAC the router gives you the 64 bit prefix and the host chooses its own 64 bit host address, which can be any address not already in use. With IPv4 you are typically assigned a single IP address via DHCP. While it is true that you are free to ignore the DHCP address assigned to your host and select something else on the same subnet, this is not typical. With SLAAC however it is the norm for the host to figure out its own address, and to leverage the enormous IP space available in IPv6 to change up their source address at will.
Filtering individual hosts by IP has always been leaky, but IPv6 makes it more or less impossible. You have to filter by subnet.
IPv6 does have some braindamage. SLAAC didn't have a way to communicate the local DNS server address to hosts, nor a way for hosts to update the DNS with their selected addresses and hostnames. This is something that has just worked in DHCP for decades and was completely ignored by the IETF. There was some handwaving about mDNS and anycasting but the actual protocol for doing the updates was never nailed down and it ignored the fact that multicast on wireless networks has always been fragile and plagued by hardware/driver issues.
Arguably, it's alive and well for the use case where it actually makes sense: For prefix delegation.
> With IPv4 you are typically assigned a single IP address via DHCP.
Well, sure, and with IPv6 you are "typically assigned a single IPv6 address via SLAAC"!?
I mean, if you are talking about a controlled environment, that's not exactly difficult to achieve, by either using MAC-address based v6 addresses, or by configuring a fixed host suffix on the respective machine, just as you would configure DHCP. If you are talking about random people/devices on your network, neither case prevents them from assigning themselves whatever addresses they please.
> Filtering individual hosts by IP has always been leaky, but IPv6 makes it more or less impossible. You have to filter by subnet.
But that is what you are doing with IPv4 as well? Just because you can't see the individual addresses of individual machines, and thus have no other choice but to block the whole subnet (that is, the NAT gateway address that proxies for it), doesn't mean you aren't blocking whole subnets!?
> SLAAC didn't have a way to communicate the local DNS server address to hosts
Well, yeah, but that's been resolved, as you seem to know.
> nor a way for hosts to update the DNS with their selected addresses and hostnames.
Except it does? If you ask me, it does not make any sense for the DHCP server to update the DNS server anyway: It's the host that owns the host name and that knows where it is reachable, and also a host in principle could be getting its connectivity from anywhere, not just a particular fixed DHCP server. The host should have the credentials for updating its DNS name, should select the address to publish for inbound connections based on its local policy, and then publish that address to the DNS. It makes no sense to tightly couple naming services and connectivity: When my laptop switches from ethernet to LTE, it should just update its DNS name to point to the address it obtained from the LTE provider, and obviously that should not involve the DHCP server of the LTE provider.
Unlike DHCP, SLAAC doesn't assign specific addresses to hosts. It communicates the network prefix via periodic broadcasts, and hosts choose their own addresses within that prefix.
DHCPv6 is used for routers, which need to be given not just an individual address on the local interface but also a prefix that they can hand out to their clients. It's optimized for flows that require a confirmation from the client that it has accepted/reserved the configuration that it's been given.
It is technically possible to use DHCPv6 to hand out IPs to endpoints, but I have not seen any production network in the wild that does this.
As long as they were breaking compatibility, all kinds of details were changed to make things easier on implementers.
Regardless, I don't get your argument. Why would not being able to address all of a given address space be a bad thing? Isn't the whole point to have more address space than will ever by physically possible to need?
Is that not the definition of over-engineering?
Now we just took what we thought we needed, and added a few tens of orders of magnitude.
An average human cell is composed of 100 trillion atoms. [0]
An average human body is composed of 100 trillion cells.
By that we see there are about 10^28 atoms in a human body.
Let’s be conservative, and say the world population for the next fifty years stays under 10 billion (most estimates say closer to 100 years).
That gives us about 10^38 atoms across all human beings on earth.
Why does this matter? Because 2^128 is 3.4 × 10^38.
That’s three IPv6 addresses for each and every atom in all the humans on earth for at least the next 50 years.
If that’s not the definition of overkill, I dunno what is.
[0] https://www.thoughtco.com/how-many-atoms-in-human-cell-60388...
Edit: And if you say the real routable space of IPv6 is only 2^64, then my point still stands. Rather than it being 3 IPs for every atom, it’s still an IP for essentially every cell of every human on earth for the foreseeable future.
My edit I made last night might seem to imply otherwise, but that was due to me being a bit terse with that part and I can’t go back and edit further now.
The whole point of L3 is to provide a layer of routing and aggregation on top of L2. Routing and aggregation requires sparse allocations, so L3 requires more address space than L2 does. L2 is 64 bits for new protocols today (which are supposed to be using EUI-64), so L3 needs to be more than 64 bits.
People would complain loudly if we didn't use a power of two, so here we are at 128 bits.
These are just silly examples, but the point is that we don't yet know what will happen to make us run out of space.
Even if that’s true, that’s about 3x longer than IPv4.
A hundred years ago, computers didn’t exist. Can you imagine how well a network address scheme invented back then would work for our needs?
Why do you presume we can do a better job of predicting what the networking needs of a hundred years from now will be?
Or perhaps you are short sighted. :)
Look at all the drama and effort that we have had to go through over a decade or two to get past IPv4: if we went with "only" 64 bits for addresses, and we miscalculated and ran out again, we would have to go through that all over again.
It's the same reason why the ZFS folks (Jeff Bonwick) designed in 128 bit from the start:
* https://blogs.oracle.com/bonwick/128-bit-storage:-are-you-hi...
> Thus, fully populating a 128-bit storage pool would, literally, require more energy than boiling the oceans.
Very definition of excess as well, so thanks for proving my point!
Except you're skipping over the part about running out at 2^64:
> Some customers already have datasets on the order of a petabyte, or 250 bytes. Thus the 64-bit capacity limit of 264 bytes is only 14 doublings away. Moore's Law for storage predicts that capacity will continue to double every 9-12 months, which means we'll start to hit the 64-bit limit in about a decade.
2^64 bits ought to be enough for anybody. -- jsjohnst
Try reading what you quoted again, nobody is running out yet.
There are a lot of intermediate steps between 2^64 and 2^128! ;)
Really, this has absolutely nothing to do with "over-engineering", as there is absolutely no "engineering" in making the address larger, it adds zero complexity, and it massively simplifies network design because it removes constraints that really complicate the building and maintenance of networks.
Login to a route server and see for yourself.
That makes it even less possible routes then, 248.
The point of this ridiculously large space is that it makes routing tables smaller, because topologically-near areas can be given common prefixes without worrying about address exhaustion.
Designing the IPv6 address space to be filled with devices is about as sensible as designing the DNS system to be filled with domains. Like, instead of allowing for domain names with 63 characters per label, we could have just said DNS names are alphanumeric strings 7 characters long, and you get assigned a random one if you register a domain, to maximize the utilization of the address space. But that would be simply idiotic, because the purpose of that address space is to provide readable names, not to "use all the addresses".
65536.65536.65536.65536.65536.65536.65536.65536
One thing you don't see enough of yet is providers charging for the IPv4 address their customers probably don't need. Those have a real cost, and economics 101 tells us if something has a cost, even a small cost, and you surface that cost to your customers, suddenly they're a lot more interested in helping avoid that cost than they were when you just ate it as part of the service. Plastic carrier bags weren't free back when grocery stories didn't charge for them -- they just absorbed the financial cost and externalised the environmental cost. Charge for the bags and suddenly customers remember they already have a bag, they don't need a bag. Same with IPv4.
Do other cloud providers (Azure, Google Cloud, Digital Ocean) do this?
I feel like the adoption problem is now firmly on "us". Last time I was setting up an internal network, I was afraid of the consequences of using IPv6 internally, so I just didn't. I imagine a lot of people are in the same boat, and they are the stragglers preventing us from turning off IPv4. The big players are ready.
(I will say that jrock.us has worked over IPv6 for almost as long as Google, though. When you only have one computer on the network, IPv6 is not much work.)
If every single incumbent and every single newcomer is dragging their feet on IPv6, maybe, just maybe, the problem isn't every single engineer in the industry, the problem is IPv6.
Theoretically we could have had a straightforward extension of IPv4 to a longer address length and the exact same design, but some architecture astronauts took over the IETF and they think it's more valuable to push their weird redesign of the internet than to actually solve IPv4 address exhaustion.
The situation feels like chicken-and-egg to me. If I had the option to use IPv6 at home, I'd be on it 100%... as-is, there's little motivation to move off of v4 internally since I'd have to NAT/tunnel to get to the v6 internet over Fios. That said, most of my link-local intranet traffic is on the fe80:: network, because that's what avahi and mDNS prefer as answers.
There's still a lot of waste that can be reclaimed before it's game over for IPv4. For just two examples - both Ford Motor Company and Prudential Securities are currently assigned over 16.7 million public IPv4 addresses each.
https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_addre...
So do Apple, AT&T, the U.S. Postal Service and others.
Even better would be for Apple to return most of those addresses and only use a handful of /16s for its hosted services like any other business and switch the internal nets to RFC1918.
https://en.wikipedia.org/wiki/IPv4_address_exhaustion#Addres...
Entire networks of computers can share a single public IP address so the 33.5 million public IP addresses supplied by two /8s could last quite a long time. Or we can let Ford sit on them.
EDIT: just found it https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_addre...
https://en.wikipedia.org/wiki/IPv4_address_exhaustion#/media...
with some 1M ips given out PER DAY, how long would two /8s last? 4 weeks, or 33 days. That is not "quite a bit longer", it is literally what I suggested.
It is only now, long after the crunch that thinking entire networks would share a single ip (hopefully never running any SIP,bittorrent or something that needs more than one port simultaneously) or the entire network would quickly run out of the 64k ports usable...
So, if Ford and whoever had that second net did give it back when it started to get scarce, all of 33 days is what we would have "won". Good margin for writing up that ipv6 migration plan I guess.
[0] https://www.networkworld.com/article/2228854/microsoft-pays-...
Second reaction (after the "$10/IP" part clicked): oooh, this person is going to have a lot of money soon o.o
But you don't have any contact info in your bio!
(I'm in no position to seriously respond - I'd only want one or two addresses to play with)
Thanks.
https://neverthenetwork.com/notes/lisp/
Full disclosure, the second link is my blog.
I believe Cisco is the only large vendor that's implemented it, but there are Linux and BSD implementations, which should make it easy for any Linux or BSD based NOS to implement it in the future.
Honestly this problem will probably be mostly solved in hardware with larger FIBs/TCAMs
Edit - I should clarify the problem I'm referring to here is fragmentation, not exhaustion.
I could see most others doing it though.
I'm wondering how much justification validation they are actually doing, or if something worse is going on.
given the recent corruption allegations with PIR/ICANN, I wouldn't be surprised if it was corruption.
- APNIC ran out
- ARIN ran out
- RIPE NCC just ran out
- AfriNIC is expected to run out in 2020
- LACNIC is expected to run out in May 2020 https://www.lacnic.net/1039/1/lacnic/ipv4-depletion-phases