IPv4, Internet Protocol version 4, is the fourth and historically dominant version of the Internet Protocol, the fundamental communication standard that governs how data is addressed, routed, and delivered across the internet and other IP networks. Standardised in RFC 791 in September 1981 IPv4 has been the backbone of internet communication for over four decades, the protocol that made the modern internet possible and that still carries the majority of internet traffic today despite the gradual transition to its successor IPv6.

IPv4 defines a 32-bit addressing scheme that identifies every device on a network with a unique numerical label, the IP address. A 32-bit address space provides 2³², approximately 4.3 billion, unique addresses. This number seemed extraordinarily large in 1981 when the internet was a research network connecting a few hundred computers. As billions of internet-connected devices came online the 4.3 billion address limit proved insufficient, the exhaustion of IPv4 addresses is one of the primary drivers of the transition to IPv6 with its vastly larger 128-bit address space.

IPv4 operates at the network layer of the internet protocol suite, the layer responsible for addressing and routing packets across networks. It works in conjunction with higher-level protocols, TCP for reliable connection-oriented communication, UDP for connectionless communication, and lower-level protocols, Ethernet, Wi-Fi, for physical network communication. Every web request, every HTTP and HTTPS connection, relies on IPv4 or IPv6 at the network layer to route data between the browser and the web server.

How IPv4 works

IPv4 provides the addressing and routing mechanism that enables data to travel from a source device to a destination device across potentially many intermediate networks and routers.

Packet-based communication: IPv4 communication is packet-based rather than circuit-based. Data is divided into packets, small units of data, each containing a header with addressing and routing information and a payload with the actual data. Each packet is routed independently through the network, potentially taking different paths to the same destination. The receiving device reassembles the packets into the original data.

This packet-based approach is fundamental to the internet’s resilience, if a network path fails packets are rerouted through alternative paths without establishing a new dedicated circuit. The stateless, connectionless nature of IPv4 packet routing enables the internet’s decentralised architecture.

IPv4 packet header: every IPv4 packet carries a header containing essential routing and delivery information. Key header fields include:

Version, identifies the IP version, 4 for IPv4. Internet Header Length, the length of the header itself. Type of Service, quality of service indicators for prioritising certain traffic types. Total Length, the total size of the packet including header and payload. Identification, Flags, and Fragment Offset, fields supporting packet fragmentation and reassembly when packets are too large for a specific network segment. Time to Live, TTL, a counter decremented by each router that forwards the packet, when TTL reaches zero the packet is discarded, preventing packets from circulating indefinitely. Protocol, identifies the higher-level protocol, TCP is protocol 6, UDP is protocol 17. Source IP address, the sender’s IPv4 address. Destination IP address, the recipient’s IPv4 address.

Routing: IPv4 routers forward packets toward their destination by consulting routing tables, databases of network prefixes and the interfaces or next-hop routers through which those networks are reachable. A router receives a packet, examines the destination IP address, looks up the longest matching prefix in its routing table, and forwards the packet through the appropriate interface. This hop-by-hop routing process continues until the packet reaches a router directly connected to the destination network.

Fragmentation and reassembly: when a packet is too large for a network segment’s maximum transmission unit, MTU, IPv4 allows fragmentation, dividing the packet into smaller fragments that fit within the MTU. Each fragment is routed independently and the destination device reassembles them into the original packet. Fragmentation adds overhead and is generally avoided in modern networking, path MTU discovery allows senders to determine the smallest MTU along a path and send packets small enough to avoid fragmentation.

IPv4 address classes and reserved ranges

IPv4 addresses are organised into classes and reserved ranges, each with specific purposes and routing characteristics.

Address classes, historical: the original IPv4 specification divided the address space into classes based on the leading bits of the address. Class A addresses, first bit 0, used the first 8 bits for the network and the remaining 24 for hosts, suitable for very large networks. Class B addresses, first two bits 10, used 16 bits for network and 16 for hosts. Class C addresses, first three bits 110, used 24 bits for network and 8 for hosts, suitable for small networks.

Classful addressing was replaced by CIDR, Classless Inter-Domain Routing, in the 1990s. CIDR allows arbitrary prefix lengths, any number of bits can be the network portion, enabling more efficient address allocation than the rigid class system. Modern IPv4 addressing uses CIDR notation, 192.168.1.0/24 specifies a 24-bit network prefix.

Private address ranges: three IPv4 address ranges are reserved for private networks, not routable on the public internet:

10.0.0.0/8: 10.0.0.0 to 10.255.255.255, approximately 16.7 million addresses. Used in large enterprise networks and data centres.

172.16.0.0/12: 172.16.0.0 to 172.31.255.255, approximately 1 million addresses. Used in medium-sized networks.

192.168.0.0/16: 192.168.0.0 to 192.168.255.255, approximately 65,000 addresses. The most familiar private range, used in home and small office networks. The 192.168.1.1 address of a typical home router is in this range.

Devices using private addresses communicate with the internet through Network Address Translation, NAT, a technique that maps private addresses to a shared public address. NAT allows many devices on a private network to share a single public IPv4 address, a critical mechanism for extending the usable IPv4 address space beyond its physical limits.

Loopback address: 127.0.0.0/8: the entire 127.x.x.x range is reserved for loopback. The most commonly used loopback address is 127.0.0.1: localhost, which refers to the device itself. Network traffic sent to a loopback address never leaves the device, it loops back to the sending process. Used extensively in development and testing, a web server listening on 127.0.0.1 is accessible only from the same machine.

Link-local addresses: 169.254.0.0/16: automatically assigned to network interfaces when no DHCP server is available and no static address is configured. Link-local addresses allow communication within the same network segment but are not routable beyond it.

Multicast range: 224.0.0.0/4: addresses reserved for IP multicast, communication to multiple recipients simultaneously. Multicast addresses allow a single packet to be delivered to multiple interested receivers, used for streaming media, network discovery protocols, and routing protocol communications.

Broadcast address: the highest address in any subnet, all host bits set to 1. In a 192.168.1.0/24 network the broadcast address is 192.168.1.255. Packets sent to the broadcast address are delivered to all devices on the subnet. Broadcast traffic is limited to the local network segment, not routed across internet boundaries.

IPv4 exhaustion

The depletion of available IPv4 addresses is one of the most significant infrastructure challenges in internet history, driving both creative solutions to extend IPv4’s usability and the transition to IPv6.

IANA exhaustion: the Internet Assigned Numbers Authority, IANA, allocated the last blocks of IPv4 addresses to the Regional Internet Registries in February 2011. After IANA exhaustion no new large blocks of IPv4 addresses were available for allocation to regional registries, the global pool of unallocated IPv4 addresses was depleted.

Regional registry exhaustion: following IANA exhaustion the Regional Internet Registries depleted their own allocations at different times. APNIC, Asia-Pacific, reached exhaustion in April 2011. RIPE NCC, Europe and Middle East, in September 2012. LACNIC, Latin America, in June 2014. ARIN, North America, in September 2015. AFRINIC, Africa, maintained its allocations longest but entered last-resort allocation policies in 2020.

IPv4 address market: following exhaustion of free allocations IPv4 addresses became tradeable commodities. Organisations with unused IPv4 allocations sell them to organisations needing additional addresses. IPv4 addresses are sold through brokers and exchanges, prices have ranged from $10 to $50 per address in recent years, reflecting genuine scarcity. Large blocks of unused addresses, assigned to universities, corporations, and government agencies in the early internet era, have been sold or transferred.

NAT as an exhaustion mitigation: Network Address Translation allows many devices to share a single public IPv4 address, a home router with one public IPv4 address may serve dozens of household devices. Carrier-grade NAT, CGNAT, extends this approach to internet service providers, a single public IPv4 address may be shared by hundreds of customers. CGNAT extends IPv4’s usability but introduces complications, devices behind CGNAT cannot be directly reached from the internet, peer-to-peer connectivity is impaired, and logging and tracing are complicated by address sharing.

IPv4 in web infrastructure

IPv4 remains the dominant protocol for web infrastructure, the majority of web servers, CDNs, and network devices are still primarily addressed through IPv4.

Web server IPv4 configuration: web servers bind to IPv4 addresses to receive incoming connections. An Nginx or Apache server configured to listen on 0.0.0.0:443 accepts HTTPS connections on all IPv4 interfaces. A server configured to listen on a specific IP, 93.184.216.34:443: accepts connections only on that address. The DNS A record for the domain points to the server’s public IPv4 address, browsers resolve the domain and connect to the IPv4 address.

IPv4 in CDN infrastructure: CDN edge servers maintain IPv4 addresses at each point of presence, browsers connecting to CDN-served sites connect to the CDN’s IPv4 addresses. CDNs with anycast routing announce the same IPv4 address from multiple geographic locations, network routing directs each user to the nearest edge node with that address. IPv4 anycast is the mechanism that enables global CDNs to route users to nearby edge servers.

IPv4 and SSL certificates: historically each HTTPS domain required a dedicated IPv4 address for SSL certificate presentation. SNI, Server Name Indication: a TLS extension, allows multiple SSL certificates to be presented from the same IPv4 address. SNI is now universally supported, multiple HTTPS domains can share a single IPv4 address. This SNI-enabled shared IP hosting is the default configuration for web hosting and CDN platforms.

IPv4 and redirects

IPv4 addresses interact with redirect management through DNS configuration and infrastructure addressing.

DNS A records for redirect source domains: redirect source domains, old domains being redirected to new destinations, need DNS A records pointing to the redirect management platform’s IPv4 addresses. The A record directs all traffic for the redirect source domain to the redirect platform’s infrastructure, where redirect rules are applied and redirect responses are generated.

Alternatively redirect source domains can use CNAME records pointing to the redirect platform’s domain, the platform manages its own IP addressing. CNAME-based configuration simplifies DNS management for redirect source domains, IP address changes at the redirect platform are automatically reflected without updating A records on each redirect source domain.

IPv4 and IPv6 dual-stack for redirect infrastructure: redirect management platforms should support both IPv4 and IPv6, serving redirect responses to clients connecting over either protocol. Dual-stack configuration, publishing both A records for IPv4 and AAAA records for IPv6, ensures redirect responses are accessible regardless of the client’s IP protocol preference.