The Internet layer provides logical addressing and the delivery of IP datagrams across interconnected networks. From a digital forensics and incident response (DFIR) perspective, IP addresses are fundamental correlation attributes used to reconstruct network activity across firewall logs, network flow records (e.g., NetFlow and IPFIX), intrusion detection alerts, and packet captures. The source and destination addresses are recorded in the IP header and identify the addresses claimed by the datagram at the observation point. However, an IP address is not, by itself, proof of the identity of a user, device, or threat actor. Network address translation (NAT), carrier-grade NAT, dynamic address assignment, shared infrastructure, virtual private networks (VPNs), proxies, and address spoofing can all complicate attribution. Reliable conclusions therefore require correlation with timestamps, time zones, address-allocation records, NAT translation logs, transport-layer ports, authentication events, endpoint telemetry, and other corroborating evidence, where available.
Hostnames are commonly used by users and applications to identify network services, while the Domain Name System (DNS) provides mappings between domain names and resource records containing address information. Forward resolution commonly retrieves IPv4 addresses through A records and IPv6 addresses through AAAA records. Reverse DNS uses PTR records to map an IP address to a name within the relevant reverse-DNS namespace. These relationships are not necessarily one-to-one: a hostname may resolve to multiple addresses, and an address may be associated with multiple names. PTR records may be absent, stale, or configured for administrative purposes that do not correspond to the identity of the system observed during an incident. Their presence does not establish ownership, control, or the historical identity of a host. Reverse-resolution results should therefore be treated as contextual evidence rather than authoritative attribution. DNS resolver caches, query logs, authoritative DNS records, and passive DNS datasets can help establish historical name-to-address relationships, but their evidentiary value depends on provenance, timestamps, retention, and the limitations of the data source. These artifacts will be examined in greater depth later in a subsequent post.
IP addressing is logically end-to-end, whereas packet forwarding is performed hop-by-hop. At each forwarding hop, a router consults its forwarding information and selects a next hop or outgoing interface according to the destination address, routing policy, and applicable forwarding rules. IP treats each datagram as an independent unit and does not establish a connection or guarantee per-flow delivery state. Nevertheless, routers and network devices may maintain state for other purposes, including flow-based load balancing, NAT, firewall inspection, and connection tracking. Where multiple paths are available, routing changes, link or router failures, convergence events, policy changes, or load-balancing mechanisms may cause packets to traverse different paths. Many networks use flow-based hashing to keep packets belonging to the same flow on a consistent path, so path variation should not be assumed to occur for every packet.
These forwarding characteristics have direct implications for network evidence collection. A sensor observes traffic only within its capture domain, at its collection point, and during its period of operation. Asymmetric routing may cause the two directions of a communication to traverse different paths, while routing changes, packet loss, capture filters, interface limitations, sampling, and monitoring gaps may produce incomplete records. Consequently, a packet capture containing only one direction of a conversation does not necessarily indicate that the other direction never occurred. Likewise, the absence of a packet or flow record at a particular sensor is not sufficient to establish that the traffic did not exist. Investigators should document sensor placement, capture configuration, collection intervals, filtering and sampling policies, clock synchronization, and known visibility limitations before drawing conclusions from missing evidence.
IP is a connectionless, best-effort protocol. It does not guarantee that datagrams will be delivered, arrive in order, arrive only once, or be retransmitted if lost. A datagram may be discarded because of congestion, routing failure, filtering policy, an invalid header, or expiration of its Time to Live (TTL) in IPv4 or Hop Limit in IPv6. IPv4 includes a header checksum that helps detect corruption of the IP header, but it does not provide an end-to-end checksum covering the entire datagram payload. Other protocol layers may provide their own error-detection mechanisms; these mechanisms have different scopes and guarantees. IP itself does not provide a general delivery-recovery mechanism.
The Internet Control Message Protocol (ICMP) provides error-reporting and diagnostic functions associated with IP. Depending on the circumstances, a router or destination host may generate an ICMP error such as Time Exceeded or Destination Unreachable when a datagram cannot be forwarded or processed. Traceroute commonly exploits TTL or Hop Limit expiration and the resulting ICMP responses to infer intermediate hops along a path. However, ICMP messages are not guaranteed to be generated, delivered, or observed. Protocol-defined exceptions, filtering, rate limiting, network policy, and implementation behavior may prevent an error from reaching the investigator's collection point. Therefore, the absence of an ICMP response does not establish that a datagram reached its destination, just as the presence of an ICMP response does not independently establish the outcome of an entire application transaction. Reliability and recovery, where required, are implemented by transport protocols such as TCP or by application-level mechanisms, including retransmission over UDP.
Several IP header fields may provide useful investigative leads, but their interpretation requires caution. The observed TTL or Hop Limit can help characterize packet forwarding and, under suitable assumptions, support a rough estimate of the number of traversed hops. In IPv4, investigators sometimes compare the observed TTL with commonly used initial values, such as 64, 128, or 255, to form a tentative operating-system or network-stack hypothesis. This inference is inherently uncertain: initial values vary, intermediate devices decrement TTL, and tunnels, proxies, packet-generating appliances, deliberate manipulation, and nonstandard configurations can affect the observation. IPv6 uses a Hop Limit field with similar hop-limiting behavior. Neither field independently identifies the originating operating system, physical location, or source device. Any fingerprinting hypothesis should be corroborated with independent evidence.
The source IP address is not cryptographically authenticated by IP itself. An observed source address therefore establishes what the packet's header claimed at the capture point, not necessarily the identity of the system or person that originated the traffic. Source-address spoofing may be possible where network controls do not prevent it, although its feasibility depends on the network path, filtering, and communication pattern. Best Current Practice 38 (BCP 38) describes ingress filtering practices intended to reduce traffic with forged source addresses. Even where spoofing is unlikely, attribution can remain complicated by NAT, shared public addresses, VPN endpoints, proxies, compromised intermediary systems, and dynamically assigned addresses. Investigators should distinguish the observed network-layer source address from the subscriber, endpoint, account, or individual ultimately responsible for the activity.
Fragmentation is another important consideration when examining packet captures and network-security telemetry. In IPv4, fragmentation may be performed by the source host or by an intermediate router when necessary and permitted by the packet's fragmentation settings and network conditions. The Identification, Flags, and Fragment Offset fields help associate fragments with the original datagram and determine their positions. Reassembly is normally performed by the destination host. As a result, a capture may contain fragments that arrive out of order, are missing, or cannot be reassembled from the available evidence. An individual fragment may not contain the transport-layer header, which can limit conventional port-based analysis. Fragmentation has also been used to exploit inconsistencies between packet-processing devices and destination systems. Inspection devices that do not correctly reassemble fragments or that interpret overlapping or malformed fragments differently from the destination may produce incomplete or misleading inspection results. Investigators should therefore distinguish observations about individual fragments from conclusions about the reconstructed datagram and should document whether reassembly was performed by the capture tool or another inspection component.
IPv6 differs from IPv4 in an important respect: IPv6 routers do not fragment packets in transit. When a packet exceeds the path's supported maximum transmission unit, a router may return an ICMPv6 Packet Too Big message; the source is responsible for adapting packet size and, when necessary, fragmenting the packet using the IPv6 Fragment extension header. IPv6 fragments may therefore appear in captures, but their presence should not be interpreted as evidence that an intermediate IPv6 router fragmented the packet. IPv4 and IPv6 fragmentation behavior must be evaluated according to the protocol version and the relevant header fields.
Forensic conclusions drawn from IP-layer evidence should remain proportional to what the data actually demonstrates. An address, TTL value, fragment sequence, routing observation, or ICMP message may support a hypothesis, but none should be treated as conclusive attribution in isolation. Investigators should preserve the original evidence, record collection conditions, normalize timestamps carefully, identify known visibility gaps, and corroborate network observations with independent sources wherever possible. Missing telemetry should be reported as a limitation of the available evidence, not automatically interpreted as proof that an event did not occur.
IP header diagrams are conventionally drawn as rectangles 32 bits (4 bytes) wide. This is a documentation convention, not a representation of how packets are physically transmitted. On the wire, a packet is represented as a sequence of octets, with multibyte fields encoded in network byte order (big-endian). The diagram's rectangular layout makes field boundaries, bit positions, and header alignment easier to interpret. This convention is established in RFC 791, which presents the IPv4 header in 32-bit-wide rows. It does not mean that the network transmits the header as discrete 32-bit words, nor is the diagram's width determined by the Header Length field. IPv6 uses the same diagramming convention despite having a fixed 40-byte base header and no IPv4-style header-length field. TCP, UDP, and ICMP headers are commonly illustrated using similar layouts.
From a network forensics perspective, understanding this distinction is essential when moving between protocol diagrams, packet-analyzer output, and raw hexadecimal data. The IPv4 header consists of a mandatory 20-byte base portion, followed by an optional Options field when present. Options are padded, where necessary, to ensure that the complete header length is a multiple of 32 bits. The Internet Header Length (IHL) field occupies 4 bits and specifies the total IPv4 header length in units of 32-bit words. Its valid values range from 5 to 15, corresponding to header lengths of 20 to 60 bytes. Consequently, the Options field can occupy up to 40 bytes. When IHL equals 5, no Options field is present; when IHL exceeds 5, options and any associated padding extend the header beyond its minimum length.
This distinction has direct implications for forensic packet parsing. The IPv4 header length in bytes is calculated as IHL × 4, and the transport-layer header, if present, begins at that offset within the IPv4 datagram. For example, a first header byte of 0x45 has a version value of 4 and an IHL value of 5, indicating a 20-byte IPv4 header with no options. A first byte of 0x4F indicates version 4 and IHL 15, corresponding to a 60-byte header with up to 40 bytes available for options and padding. Treating the raw IHL value as a byte count produces an incorrect header boundary and may cause a parser to misinterpret IPv4 options as transport-layer data. Robust forensic parsers should also validate the captured length, the IPv4 Total Length field, and the consistency of the declared header and payload boundaries before interpreting subsequent fields.
Other IPv4 header fields must likewise be interpreted according to their defined units and semantics. The Total Length field is measured in bytes and specifies the complete IPv4 datagram length, including the IPv4 header and payload. The 13-bit Fragment Offset field is measured in units of eight bytes and indicates the fragment's position relative to the beginning of the original datagram's payload. The Identification and Flags fields provide additional context for fragment association and reassembly. These fields are particularly relevant when packet captures contain fragmented, out-of-order, incomplete, or malformed traffic.
The second octet of the IPv4 header was historically designated the Type of Service (ToS) field. Its modern interpretation comprises a 6-bit Differentiated Services Code Point (DSCP), used for differentiated packet treatment, and a 2-bit Explicit Congestion Notification (ECN) field, used to signal congestion-related information under applicable conditions. Forensic tools and analysts should interpret this octet using the modern DSCP/ECN definitions rather than assuming that it represents a single legacy ToS value. These distinctions are important when validating packet dissections, writing custom parsers, examining malformed traffic, or assessing discrepancies between packet captures and security-monitoring tools. A correct interpretation of field boundaries, lengths, and units is necessary to avoid false conclusions about transport protocols, fragmentation, and the contents of the observed traffic.
An IPv4 implementation must validate the Version field before processing a datagram as IPv4. Under RFC 1122, Section 3.2.1.1, a host MUST silently discard any datagram whose Version field is not 4. In this context, “silently discard” means that the datagram is discarded without further processing and that the host does not return an ICMP error message as a result. RFC 1122 also states that hosts should provide diagnostic logging and record such events in a statistics counter where supported. Routers are subject to corresponding validation requirements under RFC 1812, Section 5.2.2, which requires a router to discard packets that fail the specified IP header validity checks and recommends logging the errors.
The Version field is only one component of IPv4 header validation. Implementations must also check the header checksum and validate the Internet Header Length (IHL) and Total Length fields according to the applicable requirements. RFC 1122 explicitly requires hosts to discard datagrams with an invalid header checksum. RFC 1812 specifies that routers must silently discard packets failing its basic validation tests, including an incorrect checksum, an unsupported IP version, an insufficient header length, or a Total Length value smaller than the declared header length. It permits a narrowly defined exception in which a router may send an ICMP Parameter Problem message for certain header-length or Total Length errors, provided the stated conditions are met. Consequently, the behavior associated with invalid fields should be described according to the specific field and applicable standard rather than generalized to every malformed header. These requirements are documented in RFC 1122 and RFC 1812.
From a forensic perspective, it is useful to distinguish between an unassigned version value and a version value assigned to another protocol. An IPv4 parser is required to reject any Version value other than 4; it does not need to determine whether the value represents an unassigned number or a different protocol that the implementation does not support. This distinction is relevant when interpreting anomalous traffic because a non-4 value is not necessarily evidence of a randomly corrupted packet or deliberate evasion. It may reflect another protocol, malformed traffic, or an error introduced during capture or decoding.
The evidentiary significance of a non-4 Version field depends on where and how the packet was observed. Such traffic may be relevant when evaluating parser robustness, intrusion detection and prevention system (IDS/IPS) consistency, or discrepancies between the interpretations produced by network security devices. Historically, some inspection systems classified traffic using link-layer protocol identifiers without adequately validating the encapsulated network-layer header. Inconsistent parsing between monitoring devices and destination systems can create opportunities for detection gaps. However, a non-4 Version value alone does not establish malicious intent. Before drawing conclusions, investigators should verify the capture's link-layer type, packet offsets, encapsulation metadata, truncation status, and decoding configuration. Where available, the original packet capture should be compared with independent sensor records and relevant device logs.
On Ethernet, the EtherType identifies the network-layer protocol carried in the frame. The value 0x0800 identifies IPv4, while 0x86DD identifies IPv6. Under normal Ethernet encapsulation, this classification directs the packet to the appropriate protocol handler. An IPv6 packet carried in a correctly formed Ethernet frame with EtherType 0x86DD should therefore be handled as IPv6 rather than submitted as an ordinary IPv4 datagram. Nevertheless, the IP Version field remains important as a validation check, and malformed frames, unusual encapsulation, implementation defects, or capture-decoding errors may produce apparent inconsistencies between the EtherType and the version nibble.
The interpretation differs for capture formats and interfaces that do not expose an Ethernet header. Raw-IP capture formats, such as those represented by the DLT_RAW link-layer type in libpcap-based systems, omit the Ethernet header; the IP Version field at the beginning of the captured packet is then an important discriminator between IPv4 and IPv6. TUN-style interfaces also commonly expose network-layer packets without an Ethernet header, although their precise behavior depends on the operating system and interface configuration. Investigators must therefore establish the capture format before interpreting the first nibble as an IP Version field.
Encapsulation introduces another important qualification. In IPv4 protocol-number terminology, IP-in-IP encapsulation uses protocol number 4, whereas IPv6 encapsulated directly within IPv4 uses IP protocol number 41. In the latter case, an IPv4 header legitimately precedes an IPv6 header in the packet payload. A capture that begins at the outer IPv4 header should therefore show Version 4 at the start of the packet and Version 6 at the appropriate offset within the encapsulated payload. Seeing both values in one packet is not, by itself, anomalous; their positions and the surrounding encapsulation fields determine their meaning.
The historical allocation of Version 5 illustrates why a version value should not automatically be described as invalid. Version 5 was assigned to the Internet Stream Protocol (ST), a stream-oriented protocol designed to operate alongside IP. ST-II, specified in RFC 1190, was a later version of that protocol, not a separate IP-version successor. The protocol used the IP Version field to identify ST packets and was not widely deployed. Its history also illustrates the importance of consistent packet classification: a device that relies solely on an outer link-layer identifier, without validating the network-layer structure it processes, may classify traffic incorrectly. See RFC 1190 and the IANA IP Version Numbers registry.
Other version numbers have historical associations with experimental or proposed internetworking protocols. Values 1–3 were used or discussed during early experimental work, while values 7, 8, and 9 were assigned to TP/IX, PIP, and TUBA, respectively, during earlier efforts to evolve Internet-layer protocols. These allocations are of historical interest and do not indicate that the corresponding protocols are in routine contemporary use. IPv6 uses Version 6. For current assignments, the IANA registry is preferable to secondary summaries because it provides the authoritative allocation status.
Forensic conclusions should distinguish the packet's observed contents from the explanation proposed for those contents. A Version field other than 4 in a suspected IPv4 packet may indicate a validation failure, a different protocol, an encapsulation boundary, or an error in capture or decoding. Investigators should establish which interpretation is consistent with the complete packet structure and collection context before attributing the anomaly to evasion, corruption, or malicious activity.
The Internet Header Length (IHL) field specifies the length of the IPv4 header, not the total datagram length. Although most IPv4 packets use the minimum 20-byte header, the protocol supports optional header fields that can extend it to 60 bytes. Correctly calculating the header length is therefore an essential first step in packet dissection: it establishes where the IPv4 payload begins and, for an unfragmented packet carrying TCP, where the TCP header is located.
Packet offsets are measured from zero relative to the start of the relevant header or capture buffer. In the IPv4 header, the first byte is at offset 0. Its high-order nibble contains the Version field, while its low-order nibble contains IHL. In the example capture, the byte at offset 0 is `0x45`. The high nibble (`4`) identifies IPv4, and the low nibble (`5`) indicates an IHL value of five 32-bit words. IHL is not a byte count. Its value is expressed in units of four bytes, so the IPv4 header length is calculated as IHL × 4. Here, 5 × 4 = 20 bytes, so the IPv4 payload begins at IP-relative offset 0x14 (decimal 20). For an unfragmented datagram carrying TCP, this is where the TCP header begins. Because this field is 4 bits, the greatest value that can be found in it is a binary 1111 or a hexadecimal 0xf, which is a decimal 15. This means the longest IP header can be 60 bytes (15*4). Misreading IHL as a byte count, or forgetting the multiplication, yields a wrong payload offset and misaligns every field parsed above the IP layer.
TCP applies a similar word-based encoding in its Data Offset field. This field occupies the high-order nibble of the byte at TCP-relative offset 12, and it shares the 16 bits at TCP offsets 12–13 with the reserved bits and control flags. With the TCP header beginning at IP-relative offset 0x14, these bytes fall at IP-relative offset 0x20 (0x14 + 12). In the dump, the line beginning at 0x0020 starts with 5010. The leading nibble 5 is a Data Offset of five 32-bit words (giving a 20-byte TCP header), and the low byte 0x10 sets the ACK flag, consistent with tcpdump’s [.] notation. The full 16-bit value 0x5010 also contains other TCP header bits. It is not the Data Offset value itself and must not be read as such.
IHL is a 4-bit field, so its maximum value is 0xF (15), corresponding to a 60-byte header: the 20-byte fixed header plus up to 40 bytes of options and padding. The minimum valid value is 5, because the mandatory header alone occupies five 32-bit words. A datagram with IHL below 5 describes an invalid IPv4 header and must be discarded by a conforming implementation. Whether the sender is notified (for example, by an ICMP Parameter Problem message) is implementation-dependent, so examiners should not infer anything from the absence of an error response. Evidence of such events, where it exists, is more likely to be in device diagnostic counters or logs.
The word-based encoding works because every IPv4 header length is a multiple of four bytes: the fixed header occupies five words, and options are padded, as necessary, to maintain 32-bit alignment. Representing up to 60 bytes directly would require six bits (2⁶ = 64), and the two low-order bits would be zero in every valid header. Encoding in words eliminates that redundancy and fits the valid range of 5–15 into four bits, which also preserves the single octet shared with Version.
The capture can be validated arithmetically. The IPv4 Total Length field is 0x0029, or 41 bytes, and covers the IPv4 header plus its payload. The flags/fragment-offset field at IP offsets 6–7 is 0x4000, meaning DF is set, MF is clear, and Fragment Offset is zero. The datagram is therefore unfragmented, which is observed rather than assumed. Protocol 0x06 confirms TCP. Subtracting the IPv4 and TCP header lengths gives the segment’s data length:
41 − 20 − 20 = 1 byte
This agrees with the length 1 reported by tcpdump. The same dump supports a second check: three full 16-byte rows plus 9 bytes on the last line total 41 bytes, matching Total Length. The calculation is valid only when the declared lengths and capture context support those assumptions; fragmentation, truncation, or additional header options would require a different interpretation. Offsets must also be read against the correct reference point. tcpdump -x begins its hex output at the IPv4 header, so the offsets displayed are IP-relative. -xx includes the link-layer header, giving Ethernet-frame-relative offsets. In an untagged Ethernet II frame, the IPv4 header begins at frame offset 14. With one 802.1Q VLAN tag, it begins at offset 18. Capture hardware, VLAN offloading, and the selected link-layer capture format can affect how these headers appear in the recorded data, so investigators should verify the actual capture representation before applying fixed offsets.
Length calculations should also derive from the IP Total Length field, not from the captured frame length. In this example, a 41-byte datagram plus a 14-byte Ethernet header is 55 bytes, below the 60-byte minimum Ethernet frame size (excluding FCS). If the frame was captured after the NIC applied padding, up to 5 trailing bytes follow the datagram. If it was captured before the NIC padded it, as is typical for locally generated traffic, they will be absent. Trailing padding is not part of the IP payload, and it should be examined separately, since it can contain residual memory contents rather than zeros.
In practice, reliable interpretation requires validating IHL, Total Length, fragmentation status, and the transport-layer header length before establishing payload boundaries or carving application data. A single incorrect header offset shifts the interpretation of every subsequent field and can lead to false conclusions about the observed traffic.
IPv4 options extend the base header beyond its minimum length of 20 bytes. Their presence is indicated by an Internet Header Length (IHL) value greater than 5, with the complete header length calculated as IHL × 4. The options area begins at IP-relative offset 20. Individual options may occupy different numbers of bytes, and padding may be used to align the complete header to a 32-bit boundary. A No Operation (NOP) option can precede another option for alignment, shifting that subsequent option's starting offset. In the supplied capture, the first IPv4 header byte is 0x46, indicating Version 4 and IHL 6. The header is therefore 24 bytes long, leaving four bytes for options at offsets 20–23. Those bytes are 94 04 00 00, which encode an IPv4 Router Alert option.
The first byte, 0x94 (10010100 in binary), contains three fields: the copied flag, the option class, and the option number. The copied flag (the high bit) is 1, indicating that the option must be copied into all fragments. The option class (the next two bits, 00 in this case ) is 0, identifying a control option, and the option number (the low five bits, 10100 in this case) is 20, identifying Router Alert (RFC 2113). The second byte, 0x04, specifies the total option length of four bytes, including the type and length bytes themselves. The final two bytes, 0x0000, form the option's value field. Under RFC 2113, value zero means that a router should examine the packet more closely. The option's presence does not guarantee that every router along the path will process it identically; behavior depends on protocol requirements and implementation support. IPv4 options generally use a type-length-value structure, with two single-byte exceptions: End of Option List (EOL, 0x00) and No Operation (NOP, 0x01). EOL marks the end of meaningful options, while NOP provides alignment padding. The assigned option types and their definitions are documented in the IANA IP Parameters registry.
Router Alert is the expected option in this capture. The IPv4 datagram carries an IGMPv3 Membership Report (protocol 0x02) from 10.5.1.242 to 224.0.0.22, the multicast address used by IGMPv3-capable multicast routers. The IP Protocol field is 0x02, identifying IGMP; the TTL is 1, and the Don't Fragment (DF) flag is set. Router Alert allows routers to identify packets requiring protocol-specific examination, including multicast-control traffic that may need processing even when the packet is not addressed to an individual router.
The Total Length field is 0x0028, or 40 bytes. Subtracting the 24-byte IPv4 header leaves 16 bytes for the IGMP message. These consist of an eight-byte IGMPv3 report header and one eight-byte group record. The record identifies multicast group 224.0.0.251. The IP header checksum covers the complete 24-byte header, including the options. The six zero bytes appearing after the 40-byte IP datagram in the supplied dump are consistent with Ethernet padding: a conventional Ethernet frame requires a minimum 46-byte payload, and the 40-byte IP datagram requires six additional bytes to reach that minimum. These padding bytes are not part of the IP Total Length.
Options are rare in ordinary traffic, so their presence is an investigative signal that needs interpretation. The protocol context matters when interpreting Router Alert. The IPv4 option defined by RFC 2113 is used by protocols including IGMP and RSVP. IPv6 uses a distinct Router Alert option, defined by RFC 2711, within the IPv6 Hop-by-Hop Options header. That IPv6 option is relevant to protocols including Multicast Listener Discovery (MLD) and RSVP. The two options serve related purposes but have different encodings and protocol-specific value assignments.
Other IPv4 options may warrant additional investigation. Loose Source and Record Route (0x83) and Strict Source and Record Route (0x89) allow the sender to specify routing information and are frequently filtered or disabled because of security and operational concerns. Their presence is not proof of malicious activity, but it warrants examination of the packet's origin, path, destination, and surrounding traffic. Record Route (0x07) and Timestamp (0x44) can expose information about network interfaces, forwarding paths, or processing times, making them potentially useful for reconnaissance. Their actual evidentiary value depends on which devices process the option and whether the resulting information is populated and trustworthy.
The Record Route option illustrates the constraints imposed by the IPv4 header format. It contains a type byte, a length byte, and a pointer byte, followed by space for recorded IPv4 addresses. The initial pointer value is normally 4, identifying the first available address slot relative to the start of the option. Each address occupies four bytes. A router processing the option records an appropriate interface address in the slot identified by the pointer and advances the pointer by four. When the pointer exceeds the option length, the recording area is full and no further addresses can be added. Because the IPv4 options area cannot exceed 40 bytes, a Record Route option can use at most 39 bytes for its own encoding: three bytes of metadata and space for nine four-byte addresses, giving a total of 39 bytes. One additional byte can be used for EOL padding to complete the 40-byte options area. Thus, a maximum-length IPv4 header can accommodate nine recorded addresses, although the actual number captured depends on the configured option length and the devices that process the packet. Routes exceeding the available slots will be recorded only partially.
Record Route and traceroute can both provide information about a network path, but they do so differently. Record Route relies on participating systems writing interface addresses into the packet header. Traceroute generally infers intermediate hops from responses to probes with progressively varied TTL or Hop Limit values, often using ICMP Time Exceeded messages. The addresses revealed by these techniques may differ because they reflect different interfaces, processing points, and observation mechanisms. Neither method necessarily provides a complete representation of the forward and return paths.
IPv4 options can affect packet handling by network infrastructure. Some routers and security devices process option-bearing packets through slower paths, filter them, or apply special policies; behavior varies by implementation and configuration. Consequently, a failed options-bearing probe provides weak evidence about destination reachability unless the filtering and forwarding behavior of the intervening network is understood. A returned Record Route response provides an observation of the interfaces that actually recorded addresses, not proof that every intermediate hop was captured.
Forensic analysis should therefore preserve the original packet, validate header and option lengths, distinguish IP content from link-layer padding, and interpret each option in its protocol context. The presence of an option is a lead for investigation, not a conclusion about intent.
In RFC 791, the octet at IP-relative offset 1 is the Type of Service (ToS) field. Originally, its three most significant bits represented Precedence, a sender-specified indication of a datagram's relative importance. The eight precedence values ranged from 0 (Routine, 0x00) to 7 (Network Control, 0xE0). The remaining bits represented Delay, Throughput, and Reliability preferences, followed by two reserved bits. Precedence was intended to influence the treatment of traffic within networks that implemented precedence-aware service. Under congestion, a network could favor higher-precedence datagrams and, under specified policies, discard lower-precedence traffic first. Precedence did not inherently determine the packet's route, although later routing specifications allowed service-related metrics to influence path selection. The Delay, Throughput, and Reliability bits expressed service preferences rather than guarantees. RFC 791 noted that these objectives could conflict and advised that, except in unusual circumstances, no more than two of the three should be set.
RFC 1349, published in 1992, revised the interpretation of the service portion of the octet. It retained the three-bit Precedence field but redefined the next four bits as a single enumerated service value. The resulting values were 0x10 for minimizing delay, 0x08 for maximizing throughput, 0x04 for maximizing reliability, 0x02 for minimizing monetary cost, and 0x00 for normal service. The least significant bit was designated must-be-zero, subject to the specification's provision for authorized experiments. These service preferences were intended to help networks select appropriate treatment for differing application requirements and network costs. In principle, routing and forwarding mechanisms could use service-related information to select paths or influence packet handling. In practice, realizing these benefits required suitable network support and configuration, and widespread consistent use did not emerge. The requested service was never a guarantee of the resulting performance: a network could deliver a packet using its ordinary treatment when the requested service was unavailable.
RFC 2474, published in 1998, superseded the earlier ToS model by defining the Differentiated Services (DS) field. RFC 3168 subsequently specified Explicit Congestion Notification (ECN) in the two least significant bits. Under the modern interpretation, the octet is divided into a six-bit Differentiated Services Code Point (DSCP) and a two-bit ECN field. For a byte value (b), the fields are decoded as follows:
DSCP = byte >> 2
ECN = byte & 0x03Here, >> 2 shifts the byte right by two bits, and & 0x03 masks out all but the two least significant bits. For example, 0xB8 yields DSCP 46 and ECN 0, while 0xC0 yields DSCP 48 and ECN 0. These examples assume the ECN field is zero; the same DSCP can coexist with other valid ECN values.
The legacy Precedence structure has a direct relationship to the modern Class Selector (CS) codepoints. CS0 through CS7 preserve the historical three-bit precedence pattern in the high-order bits of the DSCP. For example, the legacy Precedence 6 pattern corresponds to CS6, whose DSCP value is 48. With ECN set to 00, the complete DS field byte is 0xC0. Similarly, Expedited Forwarding (EF), standardized in RFC 3246 and commonly used for suitably engineered low-latency traffic such as voice, has DSCP 46. Its complete DS field byte is 0xB8 when ECN is 00. These relationships are useful when examining older software, legacy network configurations, or traffic that retains historical ToS markings. However, the numerical resemblance between legacy and modern values does not establish that a sender intended the original ToS semantics. The modern DSCP value must be decoded first, and any historical interpretation should be supported by evidence about the relevant implementation or configuration.
For a forensic examiner, the DS field is a sender-supplied, unauthenticated marking that may be changed by network infrastructure. Applications and operating systems can request particular markings, while routers, firewalls, VPN gateways, and other devices may preserve, rewrite, normalize, or clear them according to local policy. A DSCP value therefore does not, by itself, prove the originating application, the sender's identity, or the forwarding treatment actually received. Nevertheless, the field can provide useful corroborative evidence. A CS6 marking may be consistent with network-control traffic in an environment where CS6 is configured for that purpose. An EF marking on a flow otherwise characterized as bulk data transfer may warrant investigation, particularly if it conflicts with the organization's traffic-classification policy. Neither observation proves misuse: the markings may reflect legitimate application behavior, local configuration, encapsulation, or a policy applied at an intermediate network boundary.
The ECN field requires separate interpretation. Its four codepoints are 00 (Not-ECT, not ECN-capable), 01 (ECT(1)), 10 (ECT(0)), and 11 (CE, Congestion Experienced). The ECT values indicate ECN-capable traffic under the applicable transport and protocol rules; CE indicates that congestion has been experienced and marked. Because ECN occupies the two least significant bits, an octet whose DSCP is zero can read 0x01, 0x02, or 0x03, values that collide with legacy RFC 1349 service values. For example, 0x02 was “minimize monetary cost” under the old model but is ECT(0) under the current one. Decode the octet under the DSCP/ECN model first. A nonzero ECN field is not inherently anomalous, but it can be tested against transport behavior. A TCP sender may use ECT only after ECN has been negotiated in the handshake, and RFC 3168 prohibits ECT on SYN and SYN-ACK segments and on pure ACKs, except where experimental specifications permit it (e.g., RFC 5562, RFC 8311). Routers set CE only on datagrams that arrived ECT-marked, so CE on a connection with no ECN negotiation has no ordinary explanation and warrants scrutiny of intermediate devices or the sender. ECT(1) is also the identifier for L4S traffic (RFC 9331) and should be treated as expected where L4S is deployed. In every case, interpret the field against the transport protocol, the endpoints’ ECN negotiation, and the path.
Because the DS field is relatively compact and may receive limited attention in some monitoring workflows, unusual markings or unexplained changes across a flow can also be examined as potential covert-channel indicators. Such an interpretation requires caution: ordinary quality-of-service policies, ECN behavior, encapsulation, and administrative remarking can all explain differences in the field. A credible covert-channel hypothesis should be supported by repeatable patterns, timing or payload correlations, and evidence that the observed variation cannot be adequately explained by normal network behavior. The recommended investigative procedure is to decode the octet under the current DSCP/ECN model first, record the observed value at each available collection point, and correlate it with the packet's protocol, application behavior, network location, and relevant QoS policies. Only then should an examiner consider a legacy Precedence or ToS interpretation. This approach preserves the distinction between what the packet contains, what the sender may have requested, and how the network actually handled it.
RFC 2474 (1998) defines the Differentiated Services (DS) field in IPv4 and IPv6 headers, replacing the earlier Type of Service (ToS) terminology. Subsequent specifications refine its terminology, codepoint assignments, and congestion-signalling behavior, including RFC 3168 (Explicit Congestion Notification, ECN), RFC 3260 (DiffServ terminology clarifications), and RFC 8436 (DSCP Pool 3 allocation policy). The DS field is one octet long. Its six most significant bits encode the Differentiated Services Codepoint (DSCP), while its two least significant bits encode ECN. Given the field's byte value:
DSCP =
byte >> 2ECN =
byte & 0x03
For forensic analysis, these fields must be interpreted separately: DSCP indicates a requested forwarding classification, while ECN communicates congestion-related information. Neither field, on its own, proves an application's identity or the network treatment a packet actually received. RFC 2474 · RFC 3168
The six-bit DSCP space contains 64 possible codepoints, divided into three allocation pools:
Pool 1 (
xxxxx0): assigned through Standards Action.Pool 2 (
xxxx11): reserved for experimental or local use.Pool 3 (
xxxx01): assigned through Standards Action following RFC 8436, which removed its former availability for experimental or local use.
These patterns describe codepoint allocation policy, not the forwarding behavior of every possible value. The IANA registry identifies the currently assigned codepoints and their associated references. IANA DSCP Registry · RFC 8436
Important assignments include:
Default (BE/CS0):
000000(decimal 0). This is the recommended codepoint for the Default Per-Hop Behavior (PHB), commonly associated with best-effort forwarding.Class Selector (CS0–CS7):
xxx000(decimal 0, 8, 16, 24, 32, 40, 48, and 56). These codepoints preserve the corresponding legacy IP Precedence pattern in the three most significant bits.Assured Forwarding (AF, RFC 2597):
xxx yy 0, wherexxxidentifies one of four forwarding classes andyyidentifies one of three drop-precedence levels. The twelve assignments are AF11–AF43, with decimal values 10, 12, 14, 18, 20, 22, 26, 28, 30, 34, 36, and 38. AF drop precedence is a DiffServ-specific concept, not the legacy IP Precedence field.VOICE-ADMIT (RFC 5865):
101100(decimal 44), associated with admitted voice traffic.Expedited Forwarding (EF, RFC 3246):
101110(decimal 46), associated with the EF Per-Hop Behavior.Lower Effort (LE, RFC 8622):
000001(decimal 1), associated with lower-effort forwarding.
Pool membership and assignment status should not be confused with maliciousness. A codepoint that is unassigned in the registry is not, by itself, evidence of misuse. It may reflect an implementation, a local marking scheme, or a policy-specific configuration. Investigators should compare observed values with the network's documented QoS policy and, where appropriate, confirm the intended mapping with network administrators. Also, a valid DSCP assignment does not guarantee that the network implements the corresponding PHB as expected: the mapping and treatment may be configurable, and devices may remark packets at administrative boundaries. RFC 2474
ECN allows a network device using an active queue management mechanism to signal congestion without necessarily discarding a packet. RFC 7567 provides recommendations for active queue management, while RFC 3168 specifies the classic ECN mechanism for IP and TCP. The two ECN bits have four possible values:
| Bits | Meaning |
|---|---|
00 | Not-ECT — Not ECN-Capable Transport |
01 | ECT(1) — ECN-Capable Transport (1) |
10 | ECT(0) — ECN-Capable Transport (0) |
11 | CE — Congestion Experienced |
When ECN is supported and enabled for a transport, the sender can mark eligible packets ECT(0) or ECT(1). A congested router may change an ECT marking to CE instead of dropping the packet. A Not-ECT packet cannot receive a valid ECN congestion mark under the standard mechanism; if congestion requires a packet to be discarded, it may be dropped. ECT-marked packets can also be dropped, including during severe congestion. Thus, ECN can reduce congestion-related packet loss, but it does not eliminate packet loss.
For classic TCP ECN, the endpoints negotiate support during connection establishment. When the receiver gets a packet marked CE, it signals congestion to the sender using the TCP ECE flag. The sender responds by reducing its congestion window and uses the TCP CWR flag to indicate that it has reacted to the congestion notification. This is transport-level signalling that complements the ECN bits in the IP header. RFC 3168
An examiner should interpret ECN markings in the context of the transport protocol and the available capture evidence:
ECT(0) or ECT(1): The packet is marked as ECN-capable. For TCP, inspect the handshake to determine whether ECN was negotiated. An ECT marking alone does not establish successful negotiation or prove that the receiver processed ECN correctly.
CE: The packet has been marked as having experienced congestion somewhere before the observation point. The marking does not identify the router that set it, locate the congested queue, or establish how severe the congestion was.
Not-ECT: The packet is not marked as ECN-capable. This is normal for traffic that does not use ECN; it is not evidence of a fault by itself.
Unexpected ECN markings: A CE-marked packet in a TCP flow whose observed handshake did not negotiate ECN warrants investigation, but it is not conclusive evidence of tampering. The capture may be incomplete, the flow may traverse tunnels or middleboxes, or the observed packets may not represent the original end-to-end exchange.
As with DSCP, header markings are not authenticated proof of origin or intent. End systems can set header fields, and network devices may rewrite or normalize them. Although standards specify how compliant ECN-capable devices should behave, observed traffic can reflect implementation differences, tunnelling, or noncompliant equipment.
For reliable conclusions, correlate packet captures from multiple observation points with TCP handshake and acknowledgement behavior, router or firewall telemetry, QoS configuration, and other available logs. Treat DSCP and ECN values as contextual evidence of packet classification and congestion signalling, not as standalone proof of application identity, malicious intent, or the precise location of a network event.
The IPv4 Total Length field occupies byte offsets 2–3 of the IP header. It is an unsigned 16-bit integer encoded in network byte order (big-endian), giving a range of 0–65,535 as a field value. Valid IPv4 datagrams must be large enough to contain their complete IP header. The maximum representable datagram length is 65,535 bytes. RFC 791.
In an untagged Ethernet II frame, the IP header begins at frame offset 14, so the Total Length field appears at frame offsets 16–17. VLAN tags and other encapsulations can shift these frame-relative offsets; therefore, confirm the actual link-layer header before interpreting raw byte positions. Total Length specifies the size of the entire IPv4 datagram, including the IP header, any IP options, and the IP payload. It does not include the Ethernet header, frame check sequence (FCS), or Ethernet padding added to satisfy the minimum frame size. If the IP datagram is fragmented, Total Length describes the individual fragment—not the original, reassembled datagram. RFC 791
The Total Length field provides the overall IP datagram boundary. When the relevant headers are present and valid, it can be used to derive the number of bytes available to the transport or upper-layer protocol. The IP header length is calculated from the Internet Header Length (IHL) field: IP header length (bytes) = IHL × 4. For a complete, unfragmented UDP datagram, the expected relationship is: UDP Length = Total Length − IP header length. UDP's own Length field includes the UDP header and UDP data. In a first fragment of a fragmented UDP datagram, however, the UDP Length field describes the complete UDP datagram, while the fragment's IP Total Length describes only that fragment. The two values therefore should not be compared as if they necessarily describe the same amount of data. RFC 768
For TCP, ICMPv4, and IGMP, the upper-layer data length can be derived when the relevant header length is known: Upper-layer data length = IP Total Length − IP header length − upper-layer header length. For TCP, the header length is calculated using the TCP Data Offset field: TCP header length (bytes) = Data Offset × 4. This includes any TCP options. The fixed ICMPv4 header is 8 bytes; IGMP message lengths depend on the message type and format. For ICMPv4 error messages, the message body commonly includes a quoted portion of the original datagram, so its contents require interpretation according to the ICMP message type.
These calculations assume that the relevant headers are present and valid. For an unfragmented datagram, the complete upper-layer header should be available if the packet is well-formed. In a first fragment, the transport header is normally present, but malformed or truncated captures can prevent reliable calculation. A non-initial fragment does not begin with a transport header; in that case, subtract only the IP header length to determine the fragment's IP payload length.
Example 1: TCP packet
Suppose the Total Length field contains hexadecimal 0029, which equals 41 bytes. The IP header has IHL = 5, giving a 20-byte header. The TCP Data Offset is also 5, giving a 20-byte TCP header. The remaining TCP data length is:
41 − 20 − 20 = 1 byte
This agrees with a packet-analysis tool reporting one byte of TCP data, provided the displayed packet is a complete, unfragmented datagram and the reported lengths refer to the same packet representation.
Example 2: IGMP packet
In the IGMP capture, Total Length is 0028, or 40 bytes, and IHL = 6, giving a 24-byte IP header.
40 − 24 = 16 bytes of IP payload
The resulting 16-byte payload corresponds to the IGMP message in this example. Its length is derived from the IP header because IGMP does not have a general message-length field equivalent to IPv4 Total Length.
During forensic examination, compare three distinct measurements:
Reported frame length: The original packet length recorded by the capture mechanism, where available.
Captured length: The number of bytes actually retained in the capture file.
IPv4 Total Length: The length declared by the IP header.
A captured length smaller than the reported original frame length is consistent with capture truncation, such as snaplen limitations. Verify the capture metadata before attributing the difference to truncation.
If the Ethernet payload is longer than the IPv4 datagram, the extra bytes may be Ethernet padding. For an ordinary Ethernet II frame, the minimum Ethernet payload is 46 bytes, excluding the Ethernet header and FCS. A short IP datagram may therefore be followed by padding bytes. Extra bytes can also arise from malformed traffic, encapsulation, or capture artifacts, so their presence should be evaluated in context.
Padding and trailing bytes should be preserved when they may be evidentially relevant. Historical Ethernet padding disclosures, sometimes associated with the term Etherleak, demonstrate that padding can expose unintended data in some circumstances. However, the presence of padding alone does not establish that it contains residual memory or sensitive information.
A Total Length value smaller than the declared IP header length is invalid. Similarly, a value that cannot accommodate a required transport header warrants investigation. Such inconsistencies may indicate malformed traffic, a crafted packet, incomplete capture data, or an artifact of the capture path.
Host-based packet captures do not always reproduce the exact packets transmitted on the wire. TCP Segmentation Offload (TSO) and Large Send Offload (LSO) allow a host to hand large TCP data buffers to the network interface, which then segments them into wire-sized packets. Depending on the capture point and operating system, a capture may consequently display oversized packets that do not correspond one-to-one with actual Ethernet frames. Receive-side offloads and other capture-path processing can also affect the representation of observed packets. An unusually large Total Length or apparent packet boundary should therefore be compared with the capture location, interface configuration, and—when available—a capture taken outside the host.
A Total Length of zero is not a normal, general consequence of segmentation offload. Treat it as an anomalous observation and investigate the raw bytes, capture format, and capture path rather than automatically attributing it to offloading. The 16-bit Total Length field limits the size of an individual IPv4 datagram to 65,535 bytes. Fragment reassembly combines payload portions from multiple fragments, using information such as the Identification field and Fragment Offset. A suspicious reassembly result should be assessed against fragment consistency, overlap handling, implementation behavior, and the available capture evidence; it is not, by itself, proof of malicious activity.
The key forensic principle is to reconcile the IP-declared length with the transport headers, fragment structure, captured bytes, and link-layer framing before treating a packet's contents as complete or trustworthy.
The IPv4 Identification (ID) field is a 16-bit value located at byte offsets 4–5 of the IP header. It is transmitted in network byte order (big-endian). Its original purpose is to support fragmentation and reassembly: fragments belonging to the same original datagram carry the same Identification value, which the destination uses alongside the source address, destination address, protocol, and fragment offset to associate fragments correctly.
RFC 791 originally required the Identification value to be unique for a given source address, destination address, and protocol during the datagram's maximum lifetime. In practice, that requirement became difficult to maintain at modern network speeds because the field has only 65,536 possible values. RFC 6864 updated the specification to reflect current implementations and clarified that the field is intended for fragmentation and reassembly rather than general-purpose packet identification. RFC 6864 distinguishes between two categories:
Atomic datagrams: DF = 1, MF = 0, and fragment offset = 0. These datagrams are not fragmented, and further fragmentation is prohibited. Their Identification values may be arbitrary, including zero.
Non-atomic datagrams: Datagrams that have been fragmented or for which fragmentation remains possible. Their Identification values remain relevant to correct fragmentation and reassembly.
Consequently, an IPv4 ID should not be treated as a universally unique packet identifier. Its significance depends on the fragmentation flags, the packet's context, and the behavior of the originating system. RFC 791 · RFC 6864
IPv4 ID generation varies across operating systems, versions, network stacks, and traffic conditions. Observed patterns may include incrementing sequences, destination-specific counters, randomized values, or constant values on atomic datagrams. Some legacy implementations have also exhibited byte-order-related patterns that produce apparent increments of 256 when the field is interpreted in network byte order. These patterns can help characterize traffic, but they should not be treated as definitive operating-system fingerprints. Modern implementations may use different strategies for different traffic classes, and network devices can rewrite header fields. An attribution based on ID behavior should therefore be tested against the relevant system version, configuration, and independent evidence. Potential forensic applications include:
Sequence analysis: Incrementing IDs may reveal patterns in a host's traffic. Gaps can reflect intervening packets, dropped observations, or other traffic, but only when the observed ID-generation strategy makes sequential interpretation meaningful.
NAT investigation: Interleaved or inconsistent ID patterns may suggest traffic from multiple internal hosts sharing a public address. However, randomized IDs, per-destination counters, concurrency, and rewriting can produce similar observations.
Packet-injection analysis: A suspicious packet with an ID, TTL, or other header characteristics inconsistent with surrounding traffic may warrant closer examination. Such differences are clues, not proof of injection.
Cross-sensor correlation: Matching IP IDs may contribute to a correlation when fragmentation behavior makes the field meaningful. For atomic datagrams, RFC 6864 explicitly says devices must not rely on the ID field.
Stack characterization: Repeated observations may help identify an ID-generation strategy. Results should be treated as supporting evidence rather than conclusive identification of an operating system.
The general rule is to corroborate ID patterns with timestamps, addresses, transport headers, TCP sequence behavior, TTL, fragmentation flags, capture location, and other available evidence.
Historically, some hosts used predictable, globally incrementing IPv4 ID sequences. Such behavior could expose information about packets a host had sent, even when an observer could not directly see that traffic. The classic Nmap idle-scan technique demonstrates this weakness by using a third-party host as an indirect measurement point. At a high level, the technique relies on three behaviors: the intermediary host must generate predictable IDs, unsolicited TCP responses can cause it to transmit reset packets, and the target's response to a connection probe can affect whether the intermediary sends an additional packet. Comparing ID observations before and after the interaction can reveal indirect information about the target's TCP port state. In the classic case, an increase of two is consistent with an open port because the intermediary sends an additional reset packet. An increase of one is consistent with a port that is closed or filtered because the intermediary does not send that additional packet. The method cannot reliably distinguish closed from filtered ports based on that observation alone. Unrelated traffic, packet loss, or an unsuitable ID-generation strategy can invalidate the inference.
RFC 6864 is particularly important when interpreting this technique today. Atomic datagrams may carry arbitrary IDs, so a modern host may not provide the predictable sequence required by the classic method. The behavior is therefore an implementation-dependent side channel, not a universal property of IPv4.
When investigating suspected idle-scan activity or other uses of predictable IDs, separate directly observed facts from inferred roles:
At the intermediary host: A packet capture may reveal unsolicited probes and the host's responses. The presence of such packets does not guarantee that operating-system logs will record them.
At the target: Packets may appear to originate from the intermediary's address. That source address alone does not establish that the intermediary originated the traffic; IP source addresses can be spoofed.
Across capture points: Compare timestamps, TTL, IP ID, transport headers, and other available packet characteristics. Differences may help distinguish traffic paths, but network conditions and crafted packets can also produce differences.
Source-address validation and ingress filtering, described in BCP 38, help reduce spoofed-source traffic, although deployment and effectiveness vary. Their presence or absence should be established from network configuration and observations rather than assumed.
The key forensic principle is that the IPv4 Identification field is primarily a fragmentation mechanism. Predictable values can provide useful contextual evidence in particular environments, but arbitrary IDs, modern implementations, middlebox rewriting, and incomplete captures limit the reliability of conclusions based on the field alone.
The IPv4 Flags and Fragment Offset fields occupy the 16-bit word at IP header byte offsets 6–7, transmitted in network byte order (big-endian). The three most significant bits are flags, and the remaining 13 bits encode the Fragment Offset. The flags are numbered from the most significant bit:
Bit 0 — Reserved (R): Must be zero.
Bit 1 — Don't Fragment (DF): Indicates that the datagram must not be fragmented.
Bit 2 — More Fragments (MF): Indicates that more fragments follow this fragment.
The Fragment Offset specifies the position of this fragment's data within the original datagram's IP payload, in units of eight bytes. To decode the 16-bit word:
Flags =
word >> 13Fragment Offset (bytes) =
(word & 0x1FFF) × 8
In hexadecimal, 0x8000 sets the reserved bit, 0x4000 sets DF, and 0x2000 sets MF. The most significant hexadecimal digit contains the three flag bits and the highest bit of the offset field.
When DF = 1, a router must not fragment the datagram to fit a smaller outgoing MTU. If the datagram cannot be forwarded without fragmentation, the router typically discards it and may return an ICMPv4 Destination Unreachable message (Type 3, Code 4: Fragmentation Needed and Don't Fragment was Set). This behavior supports IPv4 Path MTU Discovery, although the ICMP response may be filtered or otherwise not reach the sender. When MF = 1, additional fragments follow. The offset identifies where the current fragment's payload belongs in the original IP payload, allowing the destination to place the data in the appropriate position during reassembly. An unfragmented datagram has MF = 0 and Fragment Offset = 0. A fragmented datagram's final fragment has MF = 0 but a nonzero offset. Therefore, a useful test for a fragment is: MF = 1 OR Fragment Offset ≠ 0.
Fragments belonging to the same original datagram are associated using the source address, destination address, Protocol field, and Identification field. The Fragment Offset and MF flag help determine where each fragment belongs and when the complete payload has been received. Fragmentation and reassembly should be examined alongside Total Length and the relevant header fields.
Both earlier captures contain 4000 at IP header offsets 6–7. Decoding this value gives:
Reserved flag = 0
DF = 1
MF = 0
Fragment Offset = 0
These values indicate an unfragmented datagram that must not be fragmented by a router.
For comparison, suppose an IPv4 datagram carries a 3,000-byte IP payload and must traverse a link with an MTU of 1,500 bytes. Assuming a 20-byte IPv4 header with no options, each non-final fragment can carry 1,480 bytes of payload because non-final fragment payload lengths must be multiples of eight bytes. The resulting fragments have the following Flags-and-Offset words:
| Fragment | Payload position | Payload length | Flags and offset word |
|---|---|---|---|
| First | 0 bytes | 1,480 bytes | 0x2000 |
| Second | 1,480 bytes | 1,480 bytes | 0x20B9 |
| Final | 2,960 bytes | 40 bytes | 0x0172 |
The second fragment's offset is (1480 / 8 = 185), giving 0x00B9 in the offset bits, with MF set to produce 0x20B9. The final fragment's offset is (2960 / = 370), giving 0x0172 with MF clear. The complete IP packet sizes are 1,500, 1,500, and 60 bytes, respectively. Their payload lengths sum to 3,000 bytes.
RFC 791 specifies that the reserved flag must be zero. A packet with this bit set is therefore anomalous and warrants examination, but the observation alone does not establish malicious intent. RFC 3514, published on 1 April 2003, humorously proposed assigning the reserved flag an “evil bit” to indicate whether a packet contained malicious intent. This was an April Fools' joke, not a real security mechanism; network devices do not use the bit as a reliable indicator of malicious traffic.During an examination, a set reserved bit may indicate crafted or fuzzed traffic, a nonstandard implementation, or corruption. Inspect the complete header, checksum validity, capture integrity, and surrounding traffic before drawing conclusions. A valid checksum does not prove that a packet is legitimate, and a failed checksum in a host capture may also result from checksum offloading. The key forensic principle is to interpret the flags and offset together. They describe fragmentation state and placement—not whether a packet is trustworthy or malicious.
The Time to Live (TTL) field is an 8-bit value at byte offset 8 of the IPv4 header. Its purpose is to limit how far a datagram can travel through a network and prevent it from circulating indefinitely, for example, because of a routing loop. RFC 791 originally defined TTL as a lifetime measured in seconds. Each module processing the datagram was required to decrement the value by at least one, even if it processed the packet in less than a second. RFC 1812 retains the seconds-based definition but makes additional time-based decrementing optional for routers. Consequently, modern routers generally decrement TTL by one each time they forward a packet, making it function primarily as a hop limit rather than an accurate measure of elapsed time.
A router decrements TTL when forwarding a datagram. If forwarding would reduce the value to zero, the router discards the datagram and normally generates an ICMPv4 Time Exceeded message (Type 11, Code 0), indicating that the TTL expired in transit. Under RFC 1812, this message is required when the destination is not an IPv4 multicast address, although applicable ICMP suppression rules and implementation or network conditions can affect whether the message reaches the sender. The absence of an ICMP response does not establish that a packet was delivered: the message may be filtered, rate-limited, or otherwise lost.
TTL handling applies to forwarding, not simply to packet reception. A valid datagram addressed to the router itself is not discarded solely because it arrives with TTL 0 or 1; the router must attempt to receive it. A host that receives a packet for local delivery likewise does not discard it merely because its TTL is low. If the host subsequently forwards the packet, the forwarding rules apply.
In the figure above, the initial TTL is 7, although this value is not shown. The labels indicate the TTL after each router's decrement. Router X receives the datagram with TTL 1; forwarding would reduce the value to zero, so the router discards the datagram and normally sends an ICMP Time Exceeded response to the source. A separate ICMP Time Exceeded condition is Type 11, Code 1, which indicates that a destination could not complete fragment reassembly within the permitted time.
TTL is part of the IPv4 header, which is protected by the IPv4 header checksum. Whenever a router decrements TTL, it must update that checksum to reflect the modified header. Therefore, the same packet observed at successive points along a path will normally have a lower TTL and a correspondingly updated header checksum. Other fields may also change during transit, so investigators should not assume that every field other than TTL and checksum must remain identical. ICMP error messages normally include the original IP header and at least the first eight bytes of the original datagram's payload. This information can help an examiner correlate the error with the packet that triggered it. The quoted data may be insufficient to identify a packet uniquely, so correlate additional fields and surrounding traffic where possible.
The initial TTL is selected by the sending system or application and can be configured. Common initial values include:
64: Common on Unix-like operating systems.
128: Common on Windows systems.
255: Used by many network devices and in certain network-control mechanisms.
These are conventions, not universal defaults or reliable operating-system identifiers.
The TTL observed at a capture point reflects the initial value minus the decrements applied along the path. An examiner may estimate the likely initial TTL by rounding the observed value up to a plausible conventional starting value, such as 64, 128, or 255. The difference provides a rough hop-count estimate only if the assumed initial value is correct and the packet's path and TTL handling are understood.
For example, a captured TTL of 0x80 is decimal 128. This is consistent with a packet originating with TTL 128 that has not passed through a TTL-decrementing router, but it does not prove that the source runs Windows. A different initial value, a different route, or tunnelling could produce the same observation. The IGMP capture discussed earlier shows TTL 1, a common value for link-local multicast-control traffic.
TTL can help identify unusual traffic patterns, but it should be treated as a contextual indicator rather than conclusive evidence.
Inconsistent TTL values: Packets within an apparent flow that have substantially different TTLs may originate from different systems, traverse different paths, or reflect routing changes, load balancing, spoofing, or packet injection. Investigators should compare other packet fields and capture context before drawing conclusions.
Traceroute-style probing: A sequence of probes sent with progressively increasing TTL values can reveal successive routing hops through the ICMP Time Exceeded responses. The precise pattern varies by implementation.
TTL-based IDS evasion: Historically, attackers have exploited differences in how an intrusion detection system and an end host handle packets with low TTL values. A packet might reach an intermediate sensor but expire before reaching the destination. Whether this succeeds depends on the network path, sensor placement, and packet-processing behavior.
Generalized TTL Security Mechanism (GTSM): RFC 5082 describes using TTL or IPv6 Hop Limit checks to help protect certain single-hop control-plane sessions. A packet arriving with TTL 255 is consistent with having traversed no ordinary TTL-decrementing router since it was sent with that value. This is a security check under specific assumptions, not cryptographic proof of the sender's identity, and it does not protect against every on-link attacker.
IPv6 replaces the IPv4 TTL field with the Hop Limit field. The forwarding behavior is similar: routers decrement the Hop Limit, and a packet whose Hop Limit expires is discarded. The corresponding ICMPv6 Time Exceeded message is Type 3, Code 0 for Hop Limit exceeded in transit and Type 3, Code 1 for fragment reassembly time exceeded.
For forensic analysis, TTL is most useful when combined with routing context, ICMP responses, packet-header comparisons, and other indicators. It can help reconstruct packet paths and identify anomalies, but no single TTL value reliably establishes a packet's origin or proves malicious activity.
The two Wireshark extracts illustrate what happens when an IPv4 packet's TTL expires during forwarding. In the left-hand extract, host 192.168.11.62 sends an ICMP Echo Request to 192.168.1.1. The packet's TTL is 1. Because the destination is beyond the first router, the router at 192.168.11.1 cannot forward the packet: decrementing its TTL would reduce the value to zero. The router therefore discards the original packet. The right-hand extract shows the resulting ICMP error message. The router sends an ICMP Time Exceeded message, with Type 11 and Code 0, to the original source, 192.168.11.62. This indicates that the packet's TTL expired in transit. Wireshark decodes the returned message into its IP and ICMP headers, making the router's response easier to interpret. The outer IP header identifies the router as the source and the original sender as the destination. The ICMP header identifies the error as TTL exceeded in transit.
Although we have not yet examined ICMP in detail, the key idea is that an ICMP error normally includes a portion of the original datagram: its original IP header and at least the first eight bytes of its payload. This quoted information helps the sender's TCP/IP stack associate the error with the packet that caused it. It also gives an examiner useful evidence for correlating the ICMP response with the original traffic. In this example, the original Echo Request is not delivered to 192.168.1.1. Instead, the sender receives an ICMP error indicating that the packet could not proceed because its TTL expired. ICMP errors are not guaranteed to reach the sender, so their absence does not necessarily mean that a packet was successfully delivered.
The Protocol field is an 8-bit value at byte offset 9 of the IPv4 header. It identifies the protocol carried in the IP payload, allowing the receiving system to pass the payload to the appropriate protocol handler. Although commonly associated with transport-layer protocols, the field can also identify network-control protocols and encapsulated traffic. Common IPv4 Protocol field values include:
| Decimal | Hexadecimal | Protocol |
|---|---|---|
| 1 | 0x01 | ICMP |
| 6 | 0x06 | TCP |
| 9 | 0x09 | IGP (historical/general assignment) |
| 17 | 0x11 | UDP |
| 50 | 0x32 | ESP (Encapsulating Security Payload) |
| 89 | 0x59 | OSPF |
| 58 | 0x3A | ICMPv6, normally associated with IPv6 rather than IPv4 |
The IANA Protocol Numbers registry maintains the complete list of assigned values. Different routing protocols use different protocol numbers or transport mechanisms; for example, OSPF uses IP protocol number 89, while RIP commonly uses UDP. Protocol number 9 should therefore not be interpreted as a universal identifier for all interior routing protocols.
When examining a packet in hexadecimal form, the Protocol field is one of the useful fields to inspect early. For a standard IPv4 header without options, byte offset 9 identifies the protocol carried immediately after the 20-byte IP header. If the header includes options, the payload begins later, at the offset specified by the Internet Header Length (IHL) field.
Protocol identification is also relevant to network security and digital forensics. An examiner may encounter packets using protocols that are uncommon in the environment, unexpected for a particular host, or inconsistent with the organization's documented network design. Firewalls can apply rules based on IP protocol numbers as well as TCP or UDP port numbers. Consequently, a policy that restricts common TCP and UDP services may not necessarily restrict every other IP protocol. This is why firewall reviews should consider the full range of relevant protocols rather than only familiar port numbers. IPv4 and IPv6 filtering should both be reviewed. Do not assume that an IPv6 firewall is unrestricted or that its policy is identical to the IPv4 policy; verify the actual configuration, applicable rules, and network controls.
If a receiving IPv4 host cannot deliver a datagram because the indicated protocol is unsupported, it may return an ICMP Destination Unreachable message with Type 3, Code 2 (Protocol Unreachable). However, this response is not guaranteed: firewall rules, ICMP filtering, and host implementation behavior may prevent it from appearing in a capture. For forensic analysis, an unfamiliar Protocol field value is a reason to investigate, not proof of malicious activity. Correlate it with the packet payload, source and destination addresses, surrounding traffic, host configuration, and applicable firewall rules before drawing conclusions.
The IPv4 header checksum is used to detect errors in the IPv4 header that may occur during transmission or processing. It uses a 16-bit one's-complement checksum algorithm to calculate a value that helps the receiving system determine whether the header is internally consistent.
To calculate the checksum, the sending host sets the checksum field to zero and divides the IPv4 header into 16-bit words. It adds these words using one's-complement addition, in which any carry beyond the most significant bit is wrapped around and added to the least significant bit. The sender then takes the one's complement of the final 16-bit sum and places the result in the two-byte checksum field. To validate the checksum, the receiver adds all 16-bit words of the IPv4 header, including the checksum field, using the same one's-complement addition. If the resulting sum is 0xFFFF, the header passes the checksum test. Any other result indicates a checksum failure.
The IPv4 checksum protects only the IP header, including its options if present. It does not detect corruption in the packet's payload. Other protocols, including TCP and UDP, have their own checksum mechanisms to help detect errors in their headers and payloads. Their checksums also cover an IP pseudo-header containing selected IP-layer information, such as the source and destination addresses, to help detect certain forms of misdelivery or header inconsistency.
The checksum fields at different layers must be considered separately. For example, a router that decrements the IPv4 TTL must update the IPv4 header checksum because the header has changed. The TCP checksum generally does not need to change solely because a router decremented TTL, since TTL is not part of the TCP checksum's pseudo-header or TCP segment. However, changes to fields covered by the TCP or UDP checksum may require those checksums to be recalculated.
Checksums are important when examining packet captures, investigating malformed traffic, and troubleshooting IDS or IPS alerts. A packet may appear reasonable when interpreted by a packet analyzer but still contain an invalid checksum.
For example, if expected Snort alerts are missing during an authorized traffic-analysis test, checksum handling is one possible factor to investigate. Depending on its configuration and inspection mode, an IDS or IPS may validate checksums, flag malformed packets, ignore certain checksum errors, or drop packets that fail validation. Investigators should review the product's configuration and logs rather than assume that every system handles invalid checksums identically.
When analyzing a packet capture, examine the IPv4 header checksum and, where applicable, the TCP or UDP checksum. Compare the results with the capture location and the behavior of the capturing system. Network interface checksum offloading can cause outgoing packets to appear to have incorrect or incomplete checksums in host-based captures because the network adapter may calculate the final checksum after the packet has been captured by the software.
A checksum failure is evidence of a failed checksum validation, not conclusive proof that a packet was deliberately crafted or malicious. It may result from corruption, packet modification, incomplete capture processing, or checksum offloading. Conversely, a valid checksum does not prove that a packet is legitimate or trustworthy.
Terminology note: RFC 1071, Computing the Internet Checksum, describes this algorithm using one's-complement arithmetic. It is important not to confuse one's-complement arithmetic with two's-complement representation, which is a different arithmetic convention.
The IPv4 header checksum occupies bytes 10 and 11 of the IPv4 header, using zero-based byte offsets. It protects all fields in the IPv4 header, including any options, but does not cover the encapsulated protocol's header or payload. The IPv4 header checksum differs from checksums used by protocols such as TCP, UDP, and ICMP in both its coverage and how it is handled during forwarding. Routers forwarding IPv4 datagrams verify the IP header checksum and update it when they modify the header. Transport-layer checksums are typically verified by the destination host's protocol stack, although intermediate devices can also inspect or validate them.
If a router detects an invalid IPv4 header checksum, it discards the datagram without normally sending an ICMP error message. This avoids generating an error response based on a potentially corrupted header. For example, if the destination address has been corrupted, sending an error to the address specified in that header might direct the response to the wrong system.
The IPv4 header checksum is particularly important because certain header fields change as a packet travels through the network. Each forwarding router decrements the TTL by at least one. Because TTL is part of the IPv4 header, this modification changes the checksum calculation. The router must update the checksum before forwarding the datagram. It may do this incrementally rather than recalculating the checksum from scratch.
This process continues at each forwarding hop. The router validates the incoming IPv4 header checksum, discards the datagram if the checksum is invalid, and, if it forwards the packet, updates the TTL and corresponding checksum. The destination host also validates the IPv4 header checksum before processing the packet. Remember that this checksum protects only the IP header; it does not establish the integrity of the encapsulated TCP, UDP, ICMP, or application data.
IPv6 removes the header checksum found in IPv4. One reason is efficiency: an IPv4 router must update the header checksum whenever it decrements TTL, whereas an IPv6 router can decrement the Hop Limit without recalculating a network-layer checksum.
IPv6 relies on other mechanisms for error detection. Link-layer technologies may provide their own frame checks, while protocols such as TCP and UDP use transport-layer checksums to protect their headers and payloads, including a pseudo-header containing selected IP-layer information. The IPv6 Hop Limit is not included in that pseudo-header, so decrementing it does not require the transport checksum to change. This design reduces per-hop processing while retaining error-detection mechanisms at other layers. However, a valid transport checksum does not guarantee that every part of an IPv6 packet is free from corruption, nor does it prove that the packet is trustworthy. IPv6's missing header checksum is therefore a deliberate protocol-design choice, not an absence of all packet-integrity checks.
The IPv4 source address occupies byte offsets 12–15, and the destination address occupies byte offsets 16–19, using zero-based offsets from the beginning of the IPv4 header. These fields are fundamental to network traffic analysis because they help investigators determine where packets claim to originate and where they are intended to go.
When a packet enters an organization's network from an external interface and claims to have originated from an address belonging to that organization, the traffic warrants investigation. Possible explanations include source-address spoofing, incorrect routing, a misconfigured network, or a legitimate VPN or private interconnection. The packet's source address alone does not establish which explanation is correct.
Similarly, outbound traffic should generally use source addresses authorized for the organization's network or the relevant egress interface. Packets with unexpected source addresses may indicate spoofing, host or router misconfiguration, or an unusual routing arrangement. Network administrators can use egress filtering to prevent unauthorized source addresses from leaving the network.
Source-address validation is an important defense against IP spoofing. Some denial-of-service attacks use forged source addresses to obscure the origin of traffic or cause responses to be sent to other systems. Reflection and amplification attacks are examples in which spoofed source addresses can contribute to the attack. However, not every denial-of-service attack uses spoofing, and an unfamiliar source address is not, by itself, proof of malicious activity.
Ingress and egress filtering should reflect the network's actual addressing and routing design. RFC 2827, commonly known as BCP 38, describes network ingress filtering as a way to reduce attacks that use forged source addresses. RFC 3704 discusses the additional considerations involved in multi-homed networks.
Certain IPv4 address ranges have special purposes and should be interpreted in context when observed at a network boundary.
Loopback —
127.0.0.0/8: Reserved for loopback use within a host. Packets using these addresses should not ordinarily arrive from an external network or be forwarded across a network boundary.Private-use addresses —
10.0.0.0/8,172.16.0.0/12, and192.168.0.0/16: Intended for private networks and not globally routable across the public internet. Their presence can be legitimate on internal links, private WANs, and VPNs, so their appearance at a particular interface must be evaluated against the network design.Link-local addresses —
169.254.0.0/16: Normally confined to the local link and not forwarded by routers. Unexpected appearances beyond that scope may indicate misconfiguration or unusual encapsulation.Other special-purpose addresses: Additional ranges are reserved for specific protocol functions, documentation, benchmarking, and other uses. Their interpretation should be checked against the current IANA IPv4 Special-Purpose Address Registry.
For forensic investigations, the key question is not simply whether an address is private or special-purpose, but whether its use is appropriate for the interface, direction, and network segment where it was captured.
Outbound packets directed to an unexpected broadcast or subnet address may also deserve attention. However, determining whether a destination is a network or broadcast address generally requires the relevant subnet prefix or network mask. For example, the address 192.168.10.255 is the directed broadcast address for 192.168.10.0/24, but it is not the broadcast address for every subnet containing that address. The interpretation changes with the subnet mask, and some address ranges have special semantics.
Investigators should therefore correlate destination addresses with routing information, interface configuration, subnet boundaries, and firewall policy before classifying traffic as suspicious. Source and destination addresses provide valuable clues, but they are not proof of a packet's true origin or intent. Combine address analysis with routing context, packet contents, interface direction, and network security controls before drawing conclusions.
The minimum IPv4 header length is 20 bytes. If the Internet Header Length (IHL) field specifies a value greater than 5, the header contains additional space for IP options and any required padding. Because IHL is measured in 32-bit words, the total header length is calculated as IHL × 4 bytes. The options area can occupy up to 40 bytes. Although IPv4 options are rarely encountered in everyday internet traffic, they are worth examining in network forensics. The options discussed here are a selection of notable examples, not a complete list of all defined options.
Many networks filter or discard packets containing certain IP options at their boundaries because options can introduce processing overhead, complicate packet inspection, or create security concerns. However, filtering practices vary, and options may still appear on internal networks or in specialized environments. From a forensic perspective, unexpected IP options may indicate unusual network behavior, a misconfiguration, diagnostic activity, or deliberate probing. Their presence alone does not establish malicious intent, but investigators should identify the option, determine whether it is expected, and examine the surrounding traffic.
Two particularly noteworthy IPv4 options are Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR). These options allow the sender to specify routing constraints by including a sequence of IP addresses in the packet header. Loose Source and Record Route (LSRR) uses option type 0x83. The sender specifies addresses that the packet must visit along its route. Routers may forward the packet through additional intermediate hops between the listed addresses, provided the routing constraints can be satisfied. The option also supports recording the route information as the packet progresses. Strict Source and Record Route (SSRR) uses option type 0x89. It imposes a stricter requirement: each listed address must be the next hop, rather than allowing additional unlisted routers between successive addresses. This makes SSRR more restrictive and potentially harder to use in modern networks. Both options are defined in the IPv4 specification, but support and acceptance are limited in many current network environments. Routers, firewalls, and other security devices may reject source-routed packets, so the presence of either option does not mean the requested route will be followed.
When examining IPv4 options, investigators should record the option type, length, and contents, then correlate these details with the source and destination addresses, TTL, protocol, and surrounding packets. Source-routing options deserve particular attention when they are unexpected because they express routing constraints that differ from ordinary destination-based forwarding. However, an unusual option is an investigative lead, not proof of an attack. Establishing intent requires corroborating evidence from network behavior, device configuration, and related activity.
Post a Comment