All it means is the free lunch is over and people have to start buying their IPs off of an informal market.
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.
They don't need an "informal market" when there's a perfectly good formal market. You can sell some of your IPv4 allocation to another LIR party which needs the addresses, the only case that you can't do through the formal mechanism is speculation. You can't buy a /16 and then sit on it hoping to sell it later when the prices are highest before a collapse. Good.
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.
Why, do you think? We're talking about computer people, not exactly Luddites. We all upgrade to new tech all the time, but IPv6 is more than 20 years old and adoption is still shit.
It's not more of a mess than IPv4. It's okay, people can learn it as they learned the weirdness of IPv4 (DHCP, ARP, NAT, RFC1918, IP fragmentation, ...).
Will any device made of matter / operating in polynomial time ever be able to hold the full 2^128 address space? It seems like we will forever be sub-netting into huge blocks simply because the entire space if mathematically infeasible to operate on. I think its fair to ask: Whats the point?
You are completely misunderstanding the purpose of IP address space. The purpose of IP address space is not to all be used, the point of address space is to enable connectivity. You enable connectivity by (a) having addresses available whereever you need them while (b) allowing for efficient delivery of messages. Both of those you achieve with sparse allocations, where it is easy to add machines and networks with minimal changes to the overall structure and minimal administrative overhead.
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".
For IPv6, the Internet routing table will never be split into more than 2^64 blocks, as a /64 is the general minimum BGP-announcable IPv6 block.
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?
It is over-engineering the same way that setting the maximum length of a database field longer than absolutely necessary is over-engineering, so not at all, except even far less so, because resizing a database field tends to be trivial, resizing the IP address size we've been working on for 20 years already and there is still no end in sight.
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.
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.
Do you also have a problem with 64-bit systems that have provisions for 64 bits of address space? In your book they also seem like a waste, and we should have designed something closer to ~48 bits of address space.
No, I wouldn’t make the same comment if it was just a 64bit address space. Some excess isn’t necessarily bad, but excess on top of excess is. If that makes sense.
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.
A 64 bit address space wouldn't be an excess though, it would be outright too small.
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.
> If that’s not the definition of overkill, I dunno what is.
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:
> A fully-populated 128-bit storage pool would contain
2^128 blocks = 2^137 bytes = 2^140 bits; therefore the minimum mass required to hold the bits would be (2^140 bits) / (10^31 bits/kg) = 136 billion kg.
> 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!
> 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
And then we expand to the stars, and suddenly one planet full of people isn't that great. And we'll develop nanomachines that need to be individually addressed, and suddenly our nice and new IPv6 space only lasts us only a hundred years.
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.
A subnet (i.e. a layer 2 network) always gets a /64 in IPv6; so the actual address space available for layer 3 routing is 64 bits.
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.
IP Fragmentation at routers was removed from the protocol for one.
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.
> 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.
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.
> Another is that it changes the way you think about IP addresses,
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.
I wasn't quite precise, because there are cases where you do DHCPv6, but as Android doesn't support it the protocol is a bit dead in the water.
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.
> I wasn't quite precise, because there are cases where you do DHCPv6, but as Android doesn't support it the protocol is a bit dead in the water.
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.
> Well, sure, and with IPv6 you are "typically assigned a single IPv6 address via SLAAC"!?
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.
No, SLAAC is the name of the configuration mechanism, the network protocol that is used for SLAAC is NDP, specifically router advertisements (RA), and SLAAC assigns a specific address to a host, based on the information in the RA and local policy on the host that specifies how specifically to generate the host part of that specific address.
No, SLAAC is the name of the configuration mechanism, the network protocol that is used for SLAAC is NDP, specifically router advertisements (RA), and SLAAC assigns a specific address to a host, based on the information in the RA and local policy on the host that specifies how specifically to generate the host part of that specific address.
If someone is smart enough to hop IP addresses to avoid your firewall, surely they can come up with ways to tunnel a VPN out of your network (eg through DNS or over port 443...)
Changes to the way that DHCP works. There are now different methods if you're handing out subnets to a router, IPs to an end device or allowing devices to (automatically) self assign. And not all devices support all methods.
Every device that I saw as of 4 years ago (when I was working on edge IPv6 implementation) supported the NDP/SLAAC method of assigning IP addresses, which is the default for most leaf node use cases. It's optimized for a unidirectional transmission of information from routers to leaf nodes.
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.
Aside from what everyone else is saying about the semantics, there were also a lot of changes in the header format to make it easier to parse in hardware by ASICs. Fixed-length basic header, a single integer flag that indicates to routers when they need to parse variable-length options, a requirement that in the unlikely event they are used that those options need to be 64-bit-aligned, etc.
As long as they were breaking compatibility, all kinds of details were changed to make things easier on implementers.
There is no router advertisement/NDP/SLAAC in IPv4, so that's not a fair comparison. NDP/SLAAC has a vastly different architecture and behavior than DHCP(v4), and also deprecates other hacked-on IPv4 features (like DHCPv4 link local addresses and ARP).
1.8442.16384.20.9000.42.1337.999 looks half like somebody dropped a phone number into a mass-doubling machine, and half like an overgrown object identifier.
Can I ask how old you are or how long you’ve been in the industry? I have been hearing about the impending coming up IPv6 since I was in school 15 years ago.
Things have changed a lot in 15 years. When you sign up with a major cable company like Spectrum and open up your browser and visit Google or Facebook, IPv6 is being used.
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.)
Yes, Residential ISP's can sell or lease their space to AWS, etc. for example and just start moving their customers over to CGNAT. Why bother upgrading your entire network, planning allocations, etc when you can just NAT everyone for cheap?
Can confirm this is happening. If you're lucky enough to have a choice in ISP, there are a few that won't CGNAT you. I pay a little extra for this ($10 a month) but it's worth it for me. Ask your ISP if that sounds interesting.
Is that really a feasible long term solution though? I require port forwarding and also work from home so require my service not get blocked due to some spammer on my block.
This honestly sounds like a perfect case for a business connection. Not only does it give you a static IP without NAT, possibly in an address block with other high paying (==reputable) people, it also bumps you up a lot in terms of customer service and service availability. Usually the first two questions in an outage are "how many customers are offline, and are any business connections impacted".
That assumes the ISP is willing to run a business connection to a residential address. Not every ISP will, especially if you're just a home user with special requirements and not an actual business.
Yes, but it doesn’t require upgrading all your routing hardware and the planning involved with adapting your physical network design to work with the hierarchical structure of IPv6 (we’ve had TCAM large enough to map every /24 of the v4 space for some time now, you can’t get away with that shit with v6 even if your hardware optimizes TCAM usage for routes up to /64’s).
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).
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.
Kind of. IPv6 addresses are for the most part worthless. They're only useful to shed load for CGNAT but that's only workable if you can configure the end user devices, hence why it's taken off with carriers.
Not just incumbents. Have you seen a single startup that uses IPv6 for all their internal networking (running NAT on their internet uplink if needed)?
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.
This sounds a lot like "These newfangled automobiles are scaring the horses!"
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.
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.