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.
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.
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 , or the nodes on your own LAN?
 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?
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.)
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. :/
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 ::
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?
> Third, wouldn't temporary (privacy) addresses undermine this entire EUI-64 setup's efficiency improvements?
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 . 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 . This stuff is more well thought out and less complicated than you seem to think that it is.
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  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  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.
 Let's ignore encapsulation and tunnelling for a moment.
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.
*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.
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.
- 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.
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...
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, on Earth, yeah.
But not in space.
There are issues and missed opportunities in IPv6 but that isn't one of them.
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.
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.
> 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 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, and so we have a lot of people that see NAT's limitations as a good thing.
 Aral Balkan's recent talk ( https://projectbullrun.org/surveillance/2015/video-2015.html... ) shows just how successful the digital imprimatur has been.
Not based around IPv6 specifically now, but we have interesting long-term IPv6 plans. :)
Perhaps we can at least make it until solar systems no longer exist.
Hardly a problem. According to , 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:
64285009*1000 = 64,285,009,000 < 2^36 = 68,719,476,736
Having a /48 oder /44 would make deploying IPv6 VPNs a breeze because of ULA and prefix translation. https://tools.ietf.org/html/rfc6296
Where is the problem?
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?
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.
Or you set up a static route (as a provider this would be recommended) or let the edge do a BGP announcement of it's address space.
"...the router (last hop before your server) sets up a route for that entire /48 to the link-local address of your server."
Was "your server" the ISP's server, or the customer's server? If the former, why are you saying "server", rather than "router"?
I'd recommend getting your own allocation and running your own network and AS if you want to offer VPN services.
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.
Differently from IPv4, IPv6 addresses are strictly hierarchical. You block areas by blocking their root network.
Now, why do you need to firewall entire countries again? Are you working at the Great Firewall of China or some similar project?
GeoIP blocking is not one's only defense, of course, but it's one of many tools to keep the low-to-mid level groups at bay.
But yes, this type of blocking with IPv6 should be eaiser.
Your firewall rules will actually get smaller!
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."
BC and CE go after the date.
For an industry that is supposed to be so cutting edge and innovative and disruptive (urgh), we sure have been slow as shit in transitioning to IPv6.
BT are apparently going the opposite direction (and looking to create a lot of hurt) with CG-NAT:
Additionally, their core infrastructure has been IPv6 only for a very long time.