This counter is completely inaccurate. I used to work for a company that was doing email marketing (I quit because I disagreed with their practices). My employer was buying about one /48 per week. What does this mean? We alone exhausted 2^80 ip addresses per week, or 2e18 addresses per second (that's 2 quintillion!). So this counter showing 2 addresses exhausted per second is wrong by an order of 1 quintillion.
In fact, with the proper paperwork you can still relatively easily buy an entire /40 or maybe even /32. With these practices, IPv6 WILL run out of addresses within the next 100 years. Well, to be pedantic, it will run out of allocatable subnets, but the vast majority of their addresses will remain unused.
On the one hand, it seems cheap to give me one-four-billionth of the relative amount of space as the one IPv4 address they give me.
On the other hand, I can't possibly imagine which consumer home network needs four billion times more IP addresses than all of IPv4 combined. (EUI-64 notwithstanding.)
It would seem like /112 would be way more than enough for home use (131,072 unique IPs), even for complex setups with lots of subnetting, and /96 for small business use.
I understand that giving out /64s will still take 4 billion times longer to exhaust all IPs than IPv4, but ... it still feels like they're being overly generous. 64-bit IPs would have more than enough to outlast our sun going supernova if we were smarter about allocating them.
This is part of the design of IPv6. There are (amost) never networks other than /64. This allows the possibility of generating addresses based on a mac address, and frequently changing addresses for privacy reasons.
Most devices will not work on a network with a mask longer than 64. The only common exception is point to point links between routers, which may be a /127.
Removing variable length subnet masks from end networks makes routing and configuration a lot simpler.
You say that but in a few years we'll probably be fighting neighbour discovery DoS attacks. /64 prefixes seem to be the worst thought out idea of IPv6.
IIRC (and I may not RC), ND traffic is supposed to be constrained to a local link.
If this is true, then it would be totally safe to drop ND traffic that didn't originate on your network, and drop ND traffic that occurs on networks that you manage that have manually configured addresses.
So, how would you DoS anything other than your upstream router [0], or the nodes on your own LAN?
[0] Even this DoS seems trivially preventable by dropping ND requests that happen too frequently. If you assume that there is one router on each end of a link, then the rate of ND messages would have to be very low in the ordinary course of operation, no?
Honest question, how does privacy come into play here? If you're given a /64, even if you change the last 64 bits, isn't it trivial for someone to assume everything from the first 64 is you?
Yeah. It is a trivial assumption. In my experience with Comcast Residential internet, one's IPv6 prefix remains the same for as long as one's IPv4 address, which is to say that they remain the same forever.
Comcast hands out allocations as wide as /60, but even this doesn't help much with privacy; if you're being unusually proactive with your network renumbering, that's only four bits of entropy that you're adding to your identifiers. :)
1. The /64 is the same for your whole local network. Granted that at home that is usually not many devices, but it's almost certainly more than one.
2. The /64 changes when you change networks, and unless you have a static IP address it will change for your home network too. On the other hand, if the low 64 bits is derived from your MAC address, it never changes (unless you replace your NIC of course.)
> The /64 is the same for your whole local network.
This means that -at best- IPv6 "Privacy Extensions" give advertisers no more information than they get today with non-Carrier-Grade IPv4 NATs. That's not a big win, in my book. :/
I get that EUI-64 uses your 48-bit MAC address plus 16-bit "ff:fe" token. But I don't really understand why this matters.
First, why does your home office need globally unique identifiers for its devices? 48-bits seems really excessive. A CRC16 hash of the MAC should cover far more before a conflict arises than any home networking devices could handle anyway. (you're really unlucky if you hit a 1:65,536 conflict. But make it CRC32 if you're really worried about that.)
Second, how does having the MAC address make routing simpler? When a packet comes into the router, it has to have a table to say MAC A == LAN port B. So instead, you'd just have it be: IP A == LAN port B. In the reverse direction, the PC already has to ask the router "what is my IP prefix?", so why is that harder than it just asking "what is my IP?" and getting a full address from it?
Third, wouldn't temporary (privacy) addresses undermine this entire EUI-64 setup's efficiency improvements? Now you're back to randomized data in the low 64-bits, so the router and PC need to have some kind of negotiation to know the IP addresses just like before anyway.
Lastly, I do think it's a valid privacy concern. Now when you do something the government doesn't like and they show up, that IP address with your MAC in it lets them say "yep, this is the exact computer that was used." Before, there was the argument that it could have been a Wifi guest. Even worse, it could follow you between dynamic IP reassignments from your ISP, and even from switching to different ISPs.
So all that said ... it doesn't seem like we really need 18 quintillion addresses to do decent routing and subnetting. Just drop EUI-64 as a bad idea, and have 16-bits of randomized values for the home network. And when you go a small business, increase it to 24-bits. Fortune 500, 32-bits.
And now to make the whole system even better ... make most of the IPv6 values used by ISPs 0000, so you can collapse 80% of the address to ::
> First, why does your home office need globally unique identifiers for its devices?
For the same reason that the original plans for the Internet ensured that every connected machine was a peer of every other: a network of peers easily allows for new and novel services on the network.
> Second, how does having the MAC address make routing simpler?
That's not the point. The point of this setup is to provide a way for SLAAC to easily create a stable IPv6 address to make DNS forward and reverse mapping on the LAN easy to manage. There's also an alternative method for stable address creation that doesn't use the system's MAC address.
> Now you're back to randomized data in the low 64-bits, so the router and PC need to have some kind of negotiation to know the IP addresses just like before anyway.
You really need to read how SLAAC works [0]. In particular, pay attention to the Duplicate Address Detection section, and note how DHCPv4 uses a similar method for determining whether or not an IP in a pool is safe to hand out.
After you've read about SLAAC and DAD, read about Neighbor Discovery [1]. This stuff is more well thought out and less complicated than you seem to think that it is.
The simplest way to allocate addresses on a LAN is something called SLAAC. To use SLAAC, an IPv6 router advertises a /64 on a LAN and connected machines automatically select addresses from that /64. So, -by design- the smallest general-purpose network will always be a /64.
The IETF recommends that ISPs hand out /52's to their customers. Why? IIRC, there are no specific examples in the RFC, but I've cooked up a likely scenario:
First, remember that traffic amongst machines in the same subnet never [0] touches a router. This means that traffic within a subnet can only be filtered by endpoints.
Now, imagine that -say- the Open Wireless Router Project [1] gets clever, recognizes that our ISP is allocating a /60 or a /52, automatically splits that into one /64 for each advertised SSID, then sets up firewall rules that create real "guest network" isolation (both from other SSIDs and from machines on the LAN), while still giving every connected machine a globally routeable address.
That would be nice, no? The beauty of it is that an end-user doesn't have to even be aware of IP networking for this to work!
The practice of automatically giving end-user sites the ability to create rather large numbers of subnets will inevitably give rise to consumer networking gear that allows for interesting, secure configurations while still ensuring that all machines on the Internet have a globally-routable IP address.
[0] Let's ignore encapsulation and tunnelling for a moment.
IMO every edge user should be getting a /62 at the smallest, but a /60 seems doable. /64 is the smallest idiomatic subnet. So a /60 would grant 2^4 subnets for SOHO use. Frankly, no one really probably needs more than 3 (internal, DMZ and external) for even SOHO operations.
While others are asking "Why is CompanyA buying a /48 a week?", my question is "Why isn't ISP-A asking CompanyA why they need a /48 a week?"
IPv6 operates in several of these hierarchical subnets. A /64 is the smallest, and is usually for customers and edges. A /48 or /52 is reasonable for a datacenter, as it provides up to 2^12 subnets.
But even then, doing a /48 per DC, there is no reason for not-Huge-Cloud-Provider to be gathering that much IP.
This may actually be a situation the market can take care of: If you're an ISP that is hooking up spammers with a new /48 each week, that starts to reflect poorly on your /40.
Because "email marketing" means "spammers". They were buying new blocks of IP addresses to try to evade blacklists. They are the scum of the internet, dumping their pollution far and wide because nobody is stopping them.
*to be clear, not all email marketers are spammers. But you can be damn sure anyone buying that many IP blocks is. There's literally no legitimate reason for them to need that many IP addresses.
My guess is that their subnets would be periodically marked as spammers in various black lists, so they would need new subnets to continue "email marketing".
At the same time, where I work, at least with ipv4, we like to segment product by ip block. This way if one gets a bad reputation it can't adversely affect the others. This hasn't been an issue in practice, but its just an extra layer of protection we like to have.
I'm not sure if there's the same concern with ipv6 or not.
Were they holding on to a /48 per week? If they were, I'd have to imagine that at some point a single company that's not in the ISP or hosting business would be effectively holding on to a /32 and some questions would be raised.
- No more tradeoff between number of networks vs hosts, vastly simplifying planning in large networks. (/64 subnets gives you 10^19 networks each with effectively an infinite number of hosts.)
- Security/privacy. Try port-scanning a /64 subnet -- let me know when you're done. (BTW, that was just one network.)
- Host addresses can be encoded in the lower 64 bits, which allows for all kinds of efficiencies, like stateless autoconfiguration.
- ULA, which allows you to reserve a site-local (non-Internet-routable) address space, without an external registry, and with very high probability of global uniqueness. (Remember the time your company acquired that other company, and had to merge their 10.0.0.0/8 with yours?)
- Global unicast is a /3, which means if we screwed something up, we still have 7 more attempts (each with 10^37 addresses.)
The thing with having more bits is that it allows you to do more interesting things, without the pressures of scarcity.
Limitations are good. See the currently highly-rated top-level comment: "why can't every server get a /48 so I can perpetrate the most ridiculous waste of address space imaginable?"
The idea of 128-bit address space seems to be that people can waste it like crazy and there will still be plenty for centuries to come. But that underestimates people's ingenuity in coming up with nifty things they could do if they wasted even more address space, and with no obvious reason not to they'll do it, until we're back in the same situation. Really, one day people will be wanting a /32 so they can do something nifty, and then it'll become a common thing, and the situation will seem oddly familiar...
10 years ago I played graphically rich instant-response video games on a desktop computer with 512mb ram and 128mb video ram (and fairly powerful cpu and gpu for the time). I knew that in the coming years more memory and processing power would enable ever more detailed visuals. But I didn't know that I would use significantly more system and gpu memory than that, just to read email in a browser tab. Because why not I guess...
You forgot the one where you could use them as two 9bit/55bit fixed point numbers representing latitude and longitude and have your IP address identify where you are to within a couple of microns :-).
And computers have gotten so fast and memory so large and storage so cheap that nobody cares. I get it. During the IPV6 discussions at IETF people kept saying "but 64 bits is just twice as big as our current space, we'll run out in no time" and I kept saying "No its 4 billion times bigger". It is water under the bridge.
At some point I'm going to sit down and reason out the cost of 128 versus 64 bits (which is the inverse of 'why they are great' but more 'why they aren't great') but since I never expect that I'll get a chance to design network protocols at that level again its really just a hobby for me.
Well - realistically for many addresses 64-bits will be "device identity" and 64-bits will be "network identity", many clients set their lower 64 to the nic MAC.
Large address spaces give you more than just more addresses. There's room in IPv6 addresses to put meaningful information such as cryptographically significant identifiers. It also allows for stateless auto-configuration with ridiculously small chances of collision.
There are issues and missed opportunities in IPv6 but that isn't one of them.
I understand the argument, I just fundamentally disagree with all this "... There's room in IPv6 addresses to put meaningful information ..." part. I've never been a fan of the "IP address as the way we get the OSI object identifier concept foisted on to the TCP/IP crowd." :-)
One man's "meaningful information" is another mans "privacy leak." If I visit foobar.com and they can find out from my ipv6 address what make and model of motherboard I am running, is that really a good thing? There is a reason why MAC addresses were not included in ipv4.
The ipv6 designers seem to have hated the idea of network address translation (NAT). But a lot of people have come to depend on it for security. For example, with ipv4 my wireless router only exposes one IP address to the world, no matter how many devices are behind it. But with ipv6 in its default mode, all the devices are exposed. So if I visit evildude.com on my laptop, they will know my ipv6 address. This will then map back directly to the device (no NAT), and they can port scan me and try to do bad things to any ports I have open. You can fix this with firewalls or just with NAT, but you lose a lot of the supposed benefits of ipv6 by doing so.
I think there's a strong argument to be made that point-to-point communication is more useful for evil than for good. Most of the time when you're doing something legitimate you don't mind going through a gateway. For example, I don't need to talk to my bank's backend servers directly... I can just use their public IP address and let their load-balancer send me to some open server. But if I'm a hacker, maybe I want to target something deep inside the internal network, and ipv6 makes that easier.
> I think there's a strong argument to be made that point-to-point communication is more useful for evil than for good.
It's not true in meatspace. It's also not true in cyberspace.
> ...they can port scan me and try to do bad things to any ports I have open.
It's software that's behind those ports, and software that's the target of attack. :)
> For example, I don't need to talk to my bank's backend servers directly... I can just use their public IP address and let their load-balancer send me to some open server. But if I'm a hacker, maybe I want to target something deep inside the internal network, and ipv6 makes that easier.
...IPv6 still supports stateful and stateless firewalls. Those haven't gone away, yanno? What's more, ULA space exists for a couple of reasons. If you really want to give something a non-publically-routable IP address, creating a ULA prefix and going to town is the preferred way of doing this.
Can we please kill off this old, tired fallacy that NAT provides security? NAT is not the firewall, and nobody has ever suggest removing firewalls from home routers.
> all the devices are exposed
Please tell us which shipping IPlv6 home routers with the firewall disabled, so we can avoid their terrible products.
> So if I visit evildude.com on my laptop, they will know my ipv6 address
You must be really annoyed that you have to give Amazon a valid shipping address when you want them to ship you something. When you want to ask a remote computer to send you some data, you are going to have to tell them where to send it. If you don't want that to be your local address, use some sort of proxy (e.g. Tor).
> (no NAT), and they can port scan me
Again, stop conflating NAT with the firewall. They are totally separate features. If you only have a NAT and not firewall, you can still be port scanned if the router uses static NAT, and sometimes you can source-route packets addressed to an internal address, which most NAT-without-firewall routers will happily route to the internal network.... because you left out the part that filters packets.
Why bother? IPv4 NAT "works" right now, right? So there should be no harm in using it even if NAT provides no actual security benefits? While that's a popular belief, it isn't actually true. NAT has been and continues to be incredibly damaging to not only network-software, but also damages our freedom.
When considering how technology affects the freedom and security of the people that use it, getting rid of NAT is probably right next to "encrypt everything" as the most important change we need to make to the internet (we should have done it a decade ago). We are missing a huge amount of software that wasn't even started because you have to assume everybody on IPv4 is using a "party-line" that cannot accept incoming calls. Over two decades of network software was left unwritten.
Instead software was forced to rely on central servers with real IPv4 addresses. You see to have a lot of concerns about privacy - which is good - but advocating for an IPv6 version of NAT is the same as arguing that services should remain centralized. You are arguing that we should remove the most important feature of IP networking: that any network address can be a server, giving everybody the ability to publish without needing permission[1] from a central authority.
Unfortunately, this is an uphill fight, because far too much of the tech industry is currently finding the role of "central authority" to be very profitable[2], and so we have a lot of people that see NAT's limitations as a good thing.
I was also wondering this. For example, they were talking about the debunked idea of solar panel roadways. If something like that took off in the future, literally every panel would require its own ipv6 address.
Perhaps we can at least make it until solar systems no longer exist.
> For example, they were talking about the debunked idea of solar panel roadways. If something like that took off in the future, literally every panel would require its own ipv6 address.
Hardly a problem. According to [1], there is 64,285,009 km of roadway in the world. So every meter of road in the world could be addressed with merely a 36 bit integer:
Which would be fine. Even if you covered the entire earth with 1 square millimeter solar panels, you could give each of them about 66 quadrilion IPv6 addresses.
Router hardware cannot keep up with any real number of IPv6 addresses. You'll quickly overflow router tables if you try to use even a tiny fraction of that /48 at once.
For example, Cisco Nexus 9000 can deal with 30k IPv6 neighbors. Once you cross that, things start blowing up.
This isn't really a limit for the backbone routers, because they're all dealing with routes, not individual IPs (they know that 2001:DB8::/32 goes to peer A, which only consumes one routing table entry). It's only a provide when you get to the network edge.
I'm not a networking guy. Where is the difference? One table entry for the /48 should be enough? Where is the difference to a /64 that still allows enough IP addresses to blow something up? I can't image that a lot of people map their ULA network 1:1 to a /48 or is this the reason? As far as I undetstand it it shouldn't matter because the prefix translation is happening on the server itself on not on the router. So a single router should suffice?
Wasn't at least the IPv6 header explicitly designed to be more router friendly?
At the edge, the last router before your server has to have a mapping that a single particular IPv6 address maps to a specific MAC address. You can't really condense this down to a single entry, because any given switchport might have multiple MAC addresses active (think of the case where you have a dumb switch attached to your router, and 20 servers attached to that dumb switch. You're looking at 20 different mac addresses, so no way to condense that down to a few entries).
Even a /64 is more then enough to blow up a router at this point. The /48 just makes it a lot more likely that that will happen.
The simplest solution here is to route the entire /48 at a specific IPv6 address. This brings you back down to a couple table entries, but requires that your customer configure things properly.
A lot of the cool stuff of IPv6 like ULA or prefix translation is only working if you have more than a /64 for an server. A /64 is specified as an endpoint. If you want to run a few VMs that are globally routable without DHCPv6 you need more than a /64.
In my case we have a local mesh network that we'd like to switch to IPv6 using ULA - no more hassle with IP-configuration... would be cool if could do 1:1 VPN with prefix translation but it's hard to get a server with a /48.
For a mostly hobbyist project running your own AS and BGB and having at least some redundancy for VPN services e.g. at least 2 providers looks like it's quite a challenge. The organisation got a /44 for each community but try finding a provider that reasonable cheap and that offers announcing your AS.
I'm just curious because it's definitely not lack of addresses that seems to be limit here.
My firewall blocks China, a lot of the former Soviet countries and a few others to block spam and other traffic hitting my home network because I have no legitimate reason to be communicating with them.
But yes, this type of blocking with IPv6 should be eaiser.
You block the top-level /16 or whatever has been assigned to the regional registry for the region you want to firewall. Instead of multiple IPv4 ranges you will simply block a single IP/netmask ;-)
You don't. You fix security more fundamentally instead of doing ham-fisted things like that. IPv6 is going to require that we stop using IP-based hacks as a substitute for actual authentication and robust protocols.
Small point of grammar: AD goes in front of the date. IPv6 will be exhausted in AD 5,395,000,000,000,000,000,000,000,000,000, not 5,395,000,000,000,000,000,000,000,000,000 AD.
Explanation: AD stands for anno Domini, "in the year of our Lord...." You would say "in the year of our Lord 2015," not "2015 in the year of our Lord."
All of this discussion of the accuracy of the counter also overlooks the cosmology- Sol is projected to expand into a red giant, which while it will certainly destroy the Earth, will not actually explode. Our sun isn't heavy enough to go supernova.
Comcast turned IPv6 (through DHCPv6-PD) on by default on for all of their residential customers a little while ago, have had it on-by-default in many cities for quite some time, and have had it opt-in for even longer.
Additionally, their core infrastructure has been IPv6 only for a very long time.
In fact, with the proper paperwork you can still relatively easily buy an entire /40 or maybe even /32. With these practices, IPv6 WILL run out of addresses within the next 100 years. Well, to be pedantic, it will run out of allocatable subnets, but the vast majority of their addresses will remain unused.