IPv4 is the addressing and delivery layer behind many everyday network tests. This Tping reference maps its header fields, address ranges, fragmentation behavior, and diagnostic implications for controlled lab work.
offset 0 1 2 3 4 5 6 7 version / ihl dscp / ecn total length identification flags / fragment offset ttl protocol header checksum source address: 192.0.2.10 destination: 198.51.100.24 note addresses above are documentation ranges scope: authorized packet analysis
IPv4 reference
IPv4 wraps transport data in a header that helps routers and hosts make forwarding, lifetime, and reassembly decisions. The fields below are useful when reading captures or designing a narrowly scoped packet experiment.
The first 20 bytes form the minimum IPv4 header. Options can extend it, which is why the Internet Header Length field matters when locating the payload.
| Field | Purpose |
|---|---|
| Version | Identifies IPv4 as version 4. |
| Total length | Measures the complete datagram, header and payload. |
| TTL | Limits how long a datagram may be forwarded. |
| Protocol | Identifies the next protocol, such as ICMP or TCP. |
| Source / destination | Provides the endpoint addresses used for delivery and replies. |
Field notes
Packet captures become more useful when each value is considered in context. A single field rarely explains a result on its own.
When a datagram is larger than the path can carry, IPv4 may divide it into fragments. The identification value groups fragments, while the flags and fragment offset describe their position and whether more fragments follow.
Modern networks often rely on path MTU discovery and avoid fragmentation where possible. If fragments appear in a capture, compare interface MTUs, filtering devices, and the packet sizes used by the test.
TTL is not a time measurement in seconds. Each forwarding hop normally decreases it, and a device that reaches zero may return an ICMP time-exceeded message.
The protocol field directs the receiving host to the next handler. For example, ICMP is commonly represented by 1 and TCP by 6. Confirm values against the complete capture rather than inferring them from a tool label.
Analysis workflow
A repeatable reading order helps separate packet facts from assumptions about routing, filtering, or application behavior.
Record the permitted hosts, interfaces, timing, and test conditions before collecting traffic.
Check version, header length, total length, addresses, TTL, and protocol before examining payload data.
Relate ICMP messages, transport responses, timing, and loss to the original packet sequence.
Note NAT, tunnels, fragmentation, filtering, and operating-system differences that may affect interpretation.
Related reference
IPv4 fields are most useful when paired with the protocol and tool documentation that generated or inspected the traffic.
| Topic | Why it helps |
|---|---|
| TCP/IP fundamentals | Places IPv4 inside the wider protocol model. |
| ICMP reference | Explains common diagnostic replies and errors. |
| IP TTL utility | Connects TTL changes with path observation. |
| Tool overview | Provides context for packet-generation workflows. |
FAQ
Short answers for readers moving from basic connectivity checks to packet-level analysis.
It is the network-layer unit consisting of an IPv4 header and its payload. The datagram is routed between addresses and may carry a transport or control protocol.
TTL provides a forwarding limit and can help compare paths when used carefully. It does not directly reveal the exact number of hops in every situation.
IPv4 options can extend the header. The Internet Header Length field specifies the header size in 32-bit words.
Fragmentation splits a datagram into pieces that can fit a smaller link maximum transmission unit. The destination uses identifying fields and offsets to reassemble them.
Private address ranges are intended for internal networks and are not globally routed in the ordinary public Internet. Translation, tunnels, or other network arrangements can change what an operator observes.
Only test systems and networks covered by explicit authorization. A technically visible address is not permission to send crafted or unusual traffic.
Send corrections or compatibility observations without including credentials, private captures, or confidential network details.