Here's how I know I'm reading something about IPv6 that wasn't written by an expert: it contains a line somewhere in it that spells out exactly how many addresses can be represented in 128 bits. Hint: it's a galactic size number, and people who quote it to you usually want you to believe that such a large number of addresses couldn't possibly be exhausted as quickly as the comparatively smaller range of IPv4 addresses. Sometimes, they even try to boggle your mind with analogies involving how many addresses per gram of matter in the solar system, etc.



Well, I'm here to explain why those people need to put on their thinking caps and cogitate a little harder. The IPv6 address space is finite and it's NOT consumed one address at a time.



Sure, the address space in IPv6 is a lot larger than in IPv4, but that space isn't used the same way. Here's the thing: when you've got only 32-bits in a nice flat allocation space, the temptation to start encoding information in your IP addresses is pretty manageable. People just don't try to do much of that because there aren't really a lot of bits with which to do it. Not much information can be encoded in the spare bits of a 32-bit IPv4 address.



With IPv6 addresses, on the other hand, there's a very real temptation to start encoding things in various subfields of the addresses. And the IPv6 addressing architecture is probably the first place where you see that happening. Most IPv6 addresses are divided into a 64-bit network identifier and a 64-bit interface identifier. The network identifier can be divided further into fields assigned by the RIR, then by the LIR, then finally comes the subnetwork identifier.



There are working groups inside IETF that have succumbed to the siren call to encode information in the bits of IPv6 addresses. Teredo, 6to4, IRON and NAT64 are some examples of protocols that embed IPv4 addresses in bits carved out between a short prefix assigned by IANA and the subnet identifier. The Host Identity Protocol wants to encode cryptographic material in IPv6 addresses using a protocol called ORCHID. These are just the IETF efforts I know about that eat surprisingly large blocks of IPv6 address space by encoding things into subfields.



I predict once the vast teeming masses of Internet application developers really start cranking on IPv6 adoption, the street will find many new and interesting uses for that large address space, and the Internet registries will be inundated with demand for blocks of sufficient size to support their designs. Once you start trying to cram useful information into IP addresses, you pretty quickly discover that the number of available addresses isn't as galactic as those news articles and blog posts you're reading would like you to believe. Now, I feel certain that the experts at the NRO and the regional Internet registries know all this, but I suspect the rest of the Internet engineering community is developing some unhealthy misconceptions as interest in IPv6 spreads.



So... people... please stop gushing about how it's "inconceivable" that we might ever exhaust the free pool of IPv6 addresses like we've now run out of free IPv4 addresses. It's pretty easy to conceive how it could happen, and it would be a good idea to bear that in mind when developing your address plans.