IPv4

IPv4 is version 4 of the Internet Protocol. RFC 791 specified it in September 1981. It is still the addressing scheme that a public service has to answer on. It identifies each interface with a 32-bit address. The address is written as four dotted decimal octets, such as 192.0.2.1. So the whole space is 2^32 = 4,294,967,296 values. IPv4 is not the current-generation protocol: IPv6 is the designated successor. IPv6 raises the address size from 32 bits to 128 bits. IPv4 is also not a transport or a security protocol. RFC 791 treats each datagram as an independent entity, with no connections or logical circuits. It states that there are no mechanisms to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols. So acknowledgements, retransmission and encryption all live above IPv4. The fact that shapes CDN work is scarcity. The IANA free pool was depleted on 3 February 2011. The RIPE NCC exhausted its own pool on 25 November 2019. The gap is now filled by address sharing at both ends of a request: carrier-grade NAT in front of the client, and ranges shared by many customer hostnames at the edge. One public IPv4 address therefore no longer means one user.

How it works

RFC 791 defines the packet header. A 4-bit Version field tells the receiver the format of the header. A 32-bit Source Address and 32-bit Destination Address identify the endpoints. That is the whole of IPv4 addressing: everything else is a convention layered on those 32 bits.

• Classful to classless. The original Class A/B/C model was replaced by classless prefixes. RFC 4632 describes the change as making explicit which bits in a 32-bit IPv4 address are interpreted as the network number. It writes a prefix as a 4-octet quantity, followed by the slash character and a decimal value between 0 and 32. That value gives the number of significant bits. So 10.0.0.0/8 fixes the first 8 bits as the prefix and leaves 24 bits to number hosts inside it.
• Reserved space. Several blocks are carved out of the 32-bit space. RFC 1918 reserves 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 for private use. Those addresses are only unique within an enterprise. Routing information about them shall not be propagated on inter-enterprise links. Packets carrying them should not be forwarded across such links. RFC 6598 reserves 100.64.0.0/10 as Shared Address Space for the interfaces between carrier-grade NAT devices and customer premises equipment. RFC 5737 reserves 192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24 for documentation. It says addresses in them SHOULD NOT appear on the public Internet. RFC 6890 records 240.0.0.0/4 as Reserved and neither forwardable nor global.
• Names to addresses. DNS reaches an IPv4 address through the A record, RR type 1. RFC 1035 defines it as a host address whose RDATA is an Internet address, expressed as four decimal numbers separated by dots. RFC 1035 also notes that hosts with multiple Internet addresses will have multiple A records. That is how a name can point at a set of edge addresses rather than one.

Why it matters for a CDN

• Every name a CDN serves needs A records. IPv6 is the successor, but it is not a replacement yet. Google measures the share of its own users who reach it over IPv6. Over the thirty days to 17 August 2026, that share sat between 46.9% and 50.8%. Roughly half of clients therefore still need an IPv4 path. That is why an IPv4-only edge is workable and an IPv6-only edge is not.
• Anycast spends IPv4 space. A single IPv4 address is shared by servers in many locations. BGP routes each request to the topologically nearest one. Topologically nearest is not the same as geographically nearest: routing policy, peering and transit decide it. So a request can land at a further point of presence than a map would suggest. Each anycast prefix has to be usable at every site that announces it. IPv4 space costs real money: AWS said in July 2023 that IPv4 addresses are an increasingly scarce resource. AWS also said the cost to acquire a single public IPv4 address had risen more than 300% over the previous 5 years.
• Address sharing breaks source-IP logic in both directions. In front of the client, Cloudflare's research on carrier-grade NAT notes that a single IPv4 address may represent hundreds or even thousands of users. So an IP-based security system may inadvertently block or throttle large groups of users because of one abuser behind that address. Behind the CDN, the effect reverses. Cloudflare's own documentation warns that once records are proxied, an origin stops seeing individual visitor addresses. Instead it sees Cloudflare addresses shared by all proxied hostnames. To an origin firewall that can look like a few sources sending a high volume of traffic, and it can itself trigger blocking or rate limiting.
• The real client address has to travel in a header. Because the TCP source address at the origin is the CDN's, the client address is carried in a request header. Cloudflare adds CF-Connecting-IP on edge-to-origin traffic. Cloudflare also maintains X-Forwarded-For. If the request arrived without that header, X-Forwarded-For is set to the same value as CF-Connecting-IP. If one was already present, Cloudflare appends the address of the proxy that connected to it. True-Client-IP carries the same value under a different name, and it is Enterprise-plan only.

What CDNs do

Answering on IPv4 is not optional. What differs is how each provider rations the space and how it bridges an IPv6 client to an IPv4 origin.

• Cloudflare serves proxied hostnames from several published IPv4 ranges. Those ranges are shared by all proxied hostnames, which is how Cloudflare multiplexes many customers onto few addresses. Customers who need their own space use Bring Your Own IP, where Cloudflare announces a range the customer leases or owns. They can also use static IP addresses. Both are Enterprise arrangements. Business and Enterprise customers can reduce how many Cloudflare addresses their domain shares by uploading a custom SSL certificate. IPv6 compatibility is on by default and auto-generates AAAA records. Only Enterprise accounts can turn it off. For an IPv4-only origin, non-Enterprise customers use Pseudo IPv4. It hashes the client's IPv6 address into a Class E IPv4 address and puts it in CF-Pseudo-IPv4. Alternatively, it overwrites CF-Connecting-IP and X-Forwarded-For with that address, while preserving the real address in CF-Connecting-IPv6. Where a proxied record has both an IPv6 and an IPv4 origin address, Cloudflare prefers the IPv4 address when connecting to the origin. Cloudflare also runs a classifier for carrier-grade NAT addresses. Its stated goal is a fairer treatment of users behind CGNAT IPs by security techniques that rely on IP reputation.
• AWS meters public IPv4. Since 1 February 2024, it charges 0.005 USD per IP per hour for all public IPv4 addresses, whether attached to a service or not. This applies across all AWS services that can have one attached, and in all regions.
• Microsoft Azure also bills public IPv4 by the hour. The rate depends on SKU and on whether the address is dynamic or static. Its Basic SKU public IPs were retired on 30 September 2025, so a new address comes from a Standard tier. A public IPv4 prefix is charged per IPv4 per hour from the moment it is created. Prefixes derived from customer-supplied ranges are not charged.

Watch out for

• 4,294,967,296 is the size of the 32-bit space, not the size of the usable public pool. Private, shared, documentation and reserved blocks are carved out of it. Much of the rest is already allocated.
• Exhaustion was not a single event in 2011. IANA handed out the last five /8 blocks on 3 February 2011. The RIPE NCC reached its final /8 on 14 September 2012. It exhausted its available pool on 25 November 2019, and it now runs a waiting list. On that list, a member that has never held an IPv4 allocation can receive a single /24 out of addresses recovered later. Registry policy and the transfer market, not a free pool, are where IPv4 space comes from today.
• Addresses like 192.0.2.1 and 198.51.100.42, including the ones in this entry's examples, are RFC 5737 documentation ranges. Treat them as placeholders. RFC 5737 says they SHOULD NOT appear on the public Internet. Network operators are advised to add them to non-routeable address lists and packet filters.
• A name can answer with several A records, and a CDN rotates its endpoints. So hard-coding one IPv4 address for a hostname is fragile. Resolve the name.
• One public IPv4 address is not one user. A filter keyed purely on the source address can throttle or block a whole carrier-grade NAT population because of a single abuser. That damage falls hardest on regions where CGNAT is most common.
• Ranges that look private are not always private. Cloudflare uses 172.64.0.0/13 as public egress space. That range does not overlap RFC 1918's 172.16.0.0/12. But an AWS VPC route covering 172.16.0.0/12, or a broader supernet, can capture that traffic if it is pointed at an internal target rather than an internet gateway. That capture can produce 521 and 522 errors from the affected data centres.
• A pseudo-IPv4 address synthesised from an IPv6 client is not a real address. It comes out of 240.0.0.0/4, which RFC 6890 records as Reserved and neither forwardable nor global. So it is fine as a stable per-client key. But it is useless for geolocation or for talking back to the client.
• IPv4 supplies no confidentiality or integrity of its own. Those come from a layer above, such as TLS, or from IPsec alongside it. An IPv4-only threat model is not a security control.

Best practice

• Stay dual-stack. Publish A records and AAAA records for every public name. Never operate an edge reachable only over IPv6 while about half of clients still arrive over IPv4.
• Rate-limit and score abuse on the client address your own edge asserts. Do not use the raw connecting address, and do not use an inbound X-Forwarded-For you did not write. Strip or overwrite client-supplied forwarding headers at the trust boundary. Treat a known carrier-grade NAT address as a population rather than a person.
• Give the origin room for the CDN's shared addresses. Allowlist your provider's published prefixes rather than individual addresses. Re-check the published list, because it does change. Make sure no broad internal route swallows one of those prefixes.
• Treat public IPv4 as metered inventory. Release idle addresses. Keep an inventory of what is attached. Prefer IPv6 for paths where every client can use it.
• Use only RFC 5737 documentation ranges and RFC 1918 private ranges in examples, tests and fixtures. That way, a copied snippet can never send traffic to somebody's live host.
• Budget IPv4 for anycast growth. Every prefix you announce has to be usable at every site announcing it. So the number of points of presence you can add per prefix is an address-space decision as much as a capacity one.