The last unallocated IPv4 address blocks were distributed to Regional Internet Registries (RIRs) back in 2011. Today, all RIRs have entered their final /8 phase, with ARIN and APNIC completely exhausting their pools. However, the market has developed sophisticated redistribution mechanisms:

# Example: Checking available IPv4 ranges in AWS
import boto3
ec2 = boto3.client('ec2')
response = ec2.describe_addresses()
print("Available Elastic IPs:", len(response['Addresses']))

The continued availability stems from several technical and economic factors:

• Address trading between organizations (secondary market)
• More efficient allocation using techniques like NAT444
• Reclamation of unused addresses (about 20% of allocated space)

While providers may offer "cheap" IPv4 addresses, the economics have changed significantly:

// Typical cloud provider pricing example
const awsPricing = {
  elasticIP: 0.005,  // $ per hour
  dataTransfer: 0.09 // $ per GB
};
// Compare to IPv6 which often has no additional charge

Modern networking solutions make IPv4 exhaustion manageable:

# Linux NAT configuration example
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo sysctl -w net.ipv4.ip_forward=1

# Docker IPv6 preference setting
{
  "ipv6": true,
  "fixed-cidr-v6": "2001:db8:1::/64"
}

Certain use cases still require dedicated IPv4 addresses:

• Legacy systems without IPv6 support
• Email server configurations (avoiding blacklists)
• Specific financial APIs with IP whitelisting

The reality is more nuanced than simple "exhaustion." While the free pool is gone, market mechanisms and technical solutions have created a new equilibrium where IPv4 remains available - just at increasingly higher costs that many applications can avoid through proper architecture.

As a developer who's been deploying servers since 2010, I've witnessed the IPv4 crisis evolve from theoretical concern to practical reality. While it's true you can still get IPv4 addresses for $3-5/month from providers like Linode or DigitalOcean, this availability masks deeper infrastructure challenges.

Hosting companies use several techniques to stretch their IPv4 pools:

# Example of NAT configuration keeping multiple servers behind one IP
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT

Major cloud providers implement complex solutions like:

• Carrier-grade NAT (CGNAT) systems
• IPv4 address markets (where /24 blocks trade for $50+/IP)
• Recycling abandoned IP ranges

While individual developers might not feel the pinch, consider these real-world impacts:

// AWS example showing IPv4 pricing vs IPv6
const pricing = {
  IPv4: {
    elasticIP: 0.005, // per hour
    dataTransfer: 0.01 // per GB
  },
  IPv6: {
    elasticIP: 0.00,
    dataTransfer: 0.00
  }
}

From my experience migrating services, these technical hurdles slow IPv6 adoption:

# Common gotcha in dual-stack configurations
import socket
def get_ip_version(url):
    try:
        # This will prefer IPv4 by default in Python
        return socket.getaddrinfo(url, None)[0][0]
    except:
        return None

Here's what I recommend for new projects:

1. Always request IPv6 addresses first
2. Implement dual-stack support
3. Test with IPv6-only environments

// Node.js dual-stack server example
const server = require('http').createServer();
server.listen(80, '::', () => {
  console.log('Listening on IPv6 (and IPv4 via OS mapping)');
});

The reality is more nuanced than headlines suggest - we're in a transition period where IPv4 remains usable but increasingly expensive to maintain.