IPv4 - Internet Protocol version 4. Header, addressing and security (RFC 791)
IPv4 per RFC 791 - header fields, addressing, fragmentation, NAT, private ranges. Security limitations and the role of IPsec.
IPv4 is the network layer protocol underpinning the majority of the public Internet and most corporate networks. The specification was published as RFC 791 in September 1981 and - despite its official successor in the form of IPv6 - it remains the dominant packet delivery protocol.
Understanding the IPv4 header structure is the starting point for traffic analysis, network diagnostics, firewall rule design and anomaly detection.
IPv4 header
The standard header is 20 bytes long, extending to a maximum of 60 bytes with options. Every field has a precisely defined meaning:
| Field | Length | Purpose |
|---|---|---|
| Version | 4 bits | Protocol version (always 4 for IPv4) |
| IHL (Internet Header Length) | 4 bits | Header length in 32-bit words (min. 5 = 20 bytes) |
| Type of Service / DSCP+ECN | 8 bits | Traffic priority (QoS) and congestion notification |
| Total Length | 16 bits | Length of the entire packet (max. 65,535 bytes) |
| Identification | 16 bits | Packet identifier for reassembly after fragmentation |
| Flags | 3 bits | Reserved (0), DF (Don’t Fragment), MF (More Fragments) |
| Fragment Offset | 13 bits | Fragment position in the original packet (in 8-byte units) |
| TTL (Time to Live) | 8 bits | Hop counter - decremented by each router |
| Protocol | 8 bits | Upper-layer protocol (1 = ICMP, 6 = TCP, 17 = UDP) |
| Header Checksum | 16 bits | Checksum over the header only |
| Source Address | 32 bits | Sender IP address |
| Destination Address | 32 bits | Receiver IP address |
| Options | 0-40 bytes | Options (Record Route, Timestamp, Loose/Strict Source Routing) |
Note that the checksum covers the header only - not the data. Detecting errors in the payload is the job of higher-layer protocols (TCP checksum, optionally UDP checksum). Because TTL changes at every router, the checksum must be recalculated at each hop.
Addressing
An IPv4 address is 32 bits wide, giving a theoretical 2^32 ~ 4.29 billion addresses. Part of the space is reserved (loopback, multicast, broadcast, private), so the pool of public addresses is smaller.
IANA allocated the last free /8 block to the RIRs in February 2011. Successive RIRs exhausted their pools between 2011 and 2019. IPv4 addresses are now bought on the secondary market (typical prices of 40-70 USD per address in 2026), which indirectly motivates migration to IPv6.
Special ranges
| Range | Purpose | RFC |
|---|---|---|
| 10.0.0.0/8 | Private (large) | RFC 1918 |
| 172.16.0.0/12 | Private (medium) | RFC 1918 |
| 192.168.0.0/16 | Private (small) | RFC 1918 |
| 100.64.0.0/10 | Carrier-Grade NAT (CGN) | RFC 6598 |
| 127.0.0.0/8 | Loopback | RFC 1122 |
| 169.254.0.0/16 | Link-local (APIPA) | RFC 3927 |
| 224.0.0.0/4 | Multicast | RFC 5771 |
| 240.0.0.0/4 | Reserved | RFC 1112 |
| 255.255.255.255 | Limited broadcast | RFC 919 |
Fragmentation
When a packet exceeds the link MTU (typically 1500 bytes for Ethernet, 1492 for PPPoE, 576 for a conservative minimum), a router may split it into fragments. Each fragment receives the same Identification, an appropriate Fragment Offset and the MF flag set, except the last one.
Fragmentation burdens routers and introduces security issues:
- Tiny fragment attack - fragmenting the TCP header so fields such as the destination port end up in the second fragment, bypassing simple filters
- Fragment overlap - operating systems handle overlapping fragments differently, enabling IDS evasion (Fyodor’s “teardrop” technique)
- Amplification DDoS - fragmented traffic in certain protocols (DNS, NTP) used to amplify attacks
The DF (Don’t Fragment) flag combined with Path MTU Discovery (RFC 1191) allows the sender to discover the minimum MTU along the path and adjust the TCP segment size (MSS) before transmission, eliminating the need for fragmentation.
WARNING
Firewall rules should handle fragments explicitly. Allowing fragments through by default without reassembly lets an attacker bypass layer 4 filters. Modern firewalls (stateful, deep packet inspection) reassemble the packet before analysis.
Protocol security
IPv4 in its basic form does not provide:
- Sender authentication - the Source Address field can be set to anything (spoofing). BCP 38 (RFC 2827) recommends filtering in carrier networks, but deployment remains incomplete - which is why source address spoofing based DDoS amplification attacks are still effective.
- Data integrity - the header checksum is a CRC-16, easily computable, non-cryptographic.
- Confidentiality - the entire header and payload are transmitted in the clear.
The extension addressing these shortcomings is IPsec (RFC 4301, 4302, 4303) - a suite consisting of AH (Authentication Header) and ESP (Encapsulating Security Payload) protocols together with the IKE key exchange mechanism (RFC 7296). IPsec operates in two modes:
- Transport mode - protects the payload, the IP header remains visible (used for host-to-host)
- Tunnel mode - the whole original IP packet is encapsulated inside a new one (used for site-to-site VPNs)
In OT environments IPsec is rarely deployed on end devices - PLCs typically do not have the computing resources for AES-GCM at full I/O rates. Instead, IPsec tunnels are used between segments (for example for remote service) terminated on secure devices (firewalls, VPN gateways).
NAT - necessity or defect?
Network Address Translation (RFC 3022) was created as a workaround for IPv4 exhaustion - it lets many hosts with private addresses share a single public address. NAT has consequences, however:
- Broken end-to-end connectivity - servers behind NAT require port forwarding or STUN/TURN (RFC 5389)
- Problems with protocols embedding IP addresses in the payload (SIP, active FTP) - they require an ALG (Application Layer Gateway)
- Limited auditability - from the Internet’s perspective all users behind a CGN share one address
In IPv6 NAT is unnecessary (addresses are abundant) and discouraged - the end-to-end model is restored.
Fields worth monitoring for security
| Field | What to watch for |
|---|---|
| Source Address | Spoofing, packets from bogon (unallocated) addresses |
| TTL | TTL anomalies - different systems use different starting values; an atypical TTL can indicate tunnelling |
| Identification | ID sequence - some systems (older Windows) use sequential IDs; this enables fingerprinting and idle scans |
| Flags (DF) | A sudden DF change may indicate MITM with a different MTU |
| Protocol | Unusual protocol numbers (other than TCP/UDP/ICMP) in a production network - a potential tunnel (GRE = 47, ESP = 50, IPIP = 4) |
| Options | Source Routing (7, 137) - historically abused, blocking them is now recommended |
TIP
OS fingerprinting from IP fields (p0f, nmap -O) relies on a combination of starting TTL, TCP window size, TCP option order and others. In an OT network, effective detection of unauthorised devices can be built on the stability of these profiles - a PLC always looks the same on the wire.
Summary
IPv4 remains a protocol with high operational maturity, but also with real limitations - an exhausted address pool, no built-in security mechanisms, fragmentation as a source of weaknesses. IPv4 will dominate OT networks for a long time yet; the security task is to layer protection (segmentation, firewalling, monitoring) around a protocol that does not provide it on its own.
The continuation is protocol IPv6, which addresses most IPv4 limitations - at the cost of a longer header and a different addressing model.
Sources
- RFC 791 - Internet Protocol (IPv4) - base specification
- RFC 1918 - Address Allocation for Private Internets - private ranges
- RFC 4301 - Security Architecture for IP - IPsec
- RFC 2827 / BCP 38 - Network Ingress Filtering - anti-spoofing
- IANA IPv4 Address Space - global allocations
- IANA Protocol Numbers - Protocol field value registry
Need help in this area?
Our experts will help you assess the risk and plan next steps.