IP packet
An IP packet, also known as an Internet datagram, is the basic unit of data transmission in the Internet Protocol (IP), consisting of a header with routing and control information and a payload carrying the user data.[1] The IP operates at the network layer of the TCP/IP model, providing a connectionless, best-effort delivery mechanism that routes packets independently across interconnected networks without ensuring reliability, ordering, or error correction—these functions are handled by higher-layer protocols like TCP.[1] Defined initially in RFC 791 for IPv4 in 1981, the protocol has evolved to IPv6 in RFC 8200 (2017), addressing limitations such as address exhaustion while maintaining core principles of datagram forwarding.[1][2] In IPv4, the packet header is variable in length, with a minimum of 20 octets (160 bits) comprising fields for version (4 bits, indicating IP version 4), internet header length (4 bits, specifying header size in 32-bit words), type of service (8 bits, for quality-of-service precedence and parameters like delay or throughput), total length (16 bits, up to 65,535 octets for the entire packet), identification (16 bits, for fragment reassembly), flags and fragment offset (16 bits total, controlling and positioning fragments), time to live (8 bits, preventing infinite loops by decrementing at each hop), protocol (8 bits, identifying the next-layer protocol such as TCP or UDP), header checksum (16 bits, for header integrity), source and destination addresses (32 bits each), and optional padding or options for features like security or routing.[1] The IPv4 data payload follows immediately after the header and can be fragmented by routers if it exceeds the maximum transmission unit (MTU) of a link, with reassembly performed at the destination host.[1] IPv6 packets introduce a fixed 40-octet header for simplicity and efficiency, featuring version (4 bits, value 6), traffic class (8 bits, for differentiated services), flow label (20 bits, enabling special handling for packet sequences), payload length (16 bits, for the length of the payload including extension headers), next header (8 bits, indicating the subsequent header type), hop limit (8 bits, analogous to IPv4's time to live), and expanded 128-bit source and destination addresses to support vastly more unique identifiers (approximately 3.4 × 10^38 addresses).[2] Unlike IPv4, IPv6 eliminates in-flight router fragmentation by requiring the source to perform path MTU discovery and fragment only at the origin, while optional extension headers (e.g., for hop-by-hop options, routing, or fragmentation) insert between the base header and payload to provide modular functionality without bloating the fixed header.[2] IP packets form the backbone of internet communication, enabling the global exchange of data in applications ranging from web browsing to email and streaming, with IPv4 still dominant in deployed infrastructure as of 2025 despite IPv6's growing adoption for its scalability and security enhancements like mandatory IPsec support.[2][3] The protocol's design emphasizes simplicity and interoperability across diverse network technologies, from Ethernet to wireless links, as standardized by the Internet Engineering Task Force (IETF).[1][2]Overview
Definition and Purpose
An IP packet, also known as an IP datagram, is a formatted unit of data used for transmission across packet-switched networks employing the Internet Protocol (IP).[1] It consists of two primary components: a header containing metadata for routing and delivery, and a payload that carries the actual user data or data from higher-layer protocols.[1] This structure enables the packet to traverse multiple interconnected networks, known as a catenet, from source to destination.[1] The primary purpose of an IP packet is to facilitate connectionless, best-effort delivery of datagrams, where each packet is treated independently without establishing a persistent connection.[1] It handles essential functions such as source and destination addressing, routing through intermediate gateways or hosts, and basic error detection via checksums, ensuring packets can be forwarded across diverse network topologies.[1] This design supports unreliable but efficient transmission, leaving reliability mechanisms like retransmission to higher layers if needed.[4] IP packets operate specifically at the network layer of the TCP/IP model, distinguishing them from link-layer frames, which encapsulate packets for transmission over physical media on a single network segment, and from transport-layer segments, which provide end-to-end services such as reliability or port addressing atop the IP layer.[4] For instance, an IP packet may carry a TCP segment as its payload, while being embedded within an Ethernet frame for link-layer delivery.[4] This layered separation allows IP to focus on inter-network routing without managing local transmission details or application-specific error handling.[4]Role in the TCP/IP Model
In the TCP/IP model, the Internet Protocol (IP) operates at the Internet layer, also known as Layer 3, positioned between the Transport layer above it—typically handling protocols such as TCP or UDP—and the Network Access layer below, which manages physical transmission over local networks like Ethernet.[5] This layered architecture enables IP to serve as the core mechanism for internetworking, abstracting the complexities of diverse underlying networks while providing a uniform addressing and routing framework across heterogeneous systems.[6] IP interacts with the Transport layer by encapsulating segments or datagrams from protocols like TCP or UDP into IP packets, adding a header that includes source and destination IP addresses to facilitate routing. These IP packets are then passed to the Network Access layer, where they are further encapsulated into frames suitable for transmission over physical media, such as adding Ethernet headers for local delivery. At the receiving end, the process reverses: frames are decapsulated to extract IP packets, which are then demultiplexed to the appropriate Transport layer protocol based on the Protocol field in the IP header. This encapsulation ensures that transport-layer data can traverse multiple interconnected networks without modification to its content.[7] IP's primary role in end-to-end delivery involves providing logical addressing and datagram routing, allowing packets to be forwarded across routers toward their destination IP address without establishing connections or maintaining state at intermediate nodes. Reliability, ordering, and error correction are delegated to higher-layer protocols like TCP, which can request retransmissions based on acknowledgments, while UDP relies on the application for any such handling.[8] Fundamentally, IP delivers a best-effort, connectionless service that offers no guarantees of delivery, ordering, duplication avoidance, or integrity; datagrams may arrive damaged, out of sequence, or not at all, with any necessary robustness provided by overlying layers.[5] This unreliable nature optimizes for simplicity and scalability in large-scale networks, as routers process packets independently without per-flow state.[8]IPv4 Packet Format
Header Structure
The IPv4 packet header is a variable-length structure, with a minimum size of 20 bytes (160 bits) organized into five 32-bit words when no options are present.[1] The header length is indicated by the Internet Header Length (IHL) field, allowing for optional fields that can extend the header up to 60 bytes, padded to a multiple of 32 bits.[1] All fields are transmitted in network byte order (big-endian), with the header followed directly by the payload data.[1] The header starts with the Version field (4 bits, value 4 for IPv4), followed by the Internet Header Length (IHL) (4 bits, specifying the header length in 32-bit words, minimum 5).[1] Next is the Type of Service (TOS) field (8 bits), used for quality-of-service parameters.[1] The Total Length field (16 bits) indicates the entire packet size in octets, up to 65,535.[1] Subsequent fields support fragmentation: the Identification (16 bits) for matching fragments, Flags (3 bits) including Don't Fragment (DF) and More Fragments (MF), and Fragment Offset (13 bits) for reassembly positioning in 8-octet units.[1] The Time to Live (TTL) (8 bits) prevents loops by decrementing at each hop, with discard at zero.[1] The Protocol field (8 bits) identifies the upper-layer protocol (e.g., TCP=6, UDP=17).[1] The Header Checksum (16 bits) provides error detection for the header, recomputed at each router.[1] This is followed by the Source Address (32 bits) and Destination Address (32 bits).[1] Optional fields at the end support features like routing or timestamps, though rarely used due to processing overhead and security concerns.[1][9]| Field | Size (bits) | Purpose |
|---|---|---|
| Version | 4 | Identifies the IP version (value 4). |
| Internet Header Length (IHL) | 4 | Length of header in 32-bit words (minimum 5). |
| Type of Service (TOS) | 8 | QoS parameters (precedence, delay, etc.; evolved to DSCP/ECN). |
| Total Length | 16 | Total size of datagram in octets. |
| Identification | 16 | Unique ID for fragment reassembly. |
| Flags | 3 | Fragmentation control (DF, MF bits). |
| Fragment Offset | 13 | Position of fragment in original datagram (8-octet units). |
| Time to Live (TTL) | 8 | Hop limit to prevent loops. |
| Protocol | 8 | Identifies upper-layer protocol. |
| Header Checksum | 16 | Error detection for header. |
| Source Address | 32 | IPv4 address of sender. |
| Destination Address | 32 | IPv4 address of recipient. |
| Options (variable) | 0-320 | Optional features (e.g., routing, timestamps); padded as needed. |
Key Header Fields
The Version field, occupying the first 4 bits of the IPv4 header, specifies the IP version in use, ensuring compatibility across network devices by indicating the header format to be parsed.[1] It is set to 4 for IPv4 packets.[1] Adjacent to it, the Internet Header Length (IHL) field, also 4 bits, denotes the header's length in 32-bit words, allowing receivers to locate the start of the data payload.[1] The minimum value is 5, corresponding to a 20-byte header without options.[1] The Type of Service (TOS) field, an 8-bit octet originally intended to indicate desired quality of service parameters such as precedence, delay, throughput, and reliability, has evolved for modern traffic management.[1] In contemporary implementations, the first 6 bits form the Differentiated Services Code Point (DSCP), which classifies packets for per-hop behaviors like expedited forwarding or assured forwarding to prioritize routing.[10] The remaining 2 bits support Explicit Congestion Notification (ECN), signaling network congestion to endpoints without packet loss; values include 00 for non-ECN-capable transport, 01 or 10 for ECN-capable, and 11 for congestion experienced.[11] The Total Length field, 16 bits long, measures the entire datagram size in octets, encompassing both the header and data, with a maximum of 65,535 octets.[1] Payload size is derived by subtracting the header length (from IHL) from this value, which informs Maximum Transmission Unit (MTU) handling; IPv4 requires hosts to accept at least 576-octet datagrams to accommodate varying link MTUs.[1] For fragmentation support, the 16-bit Identification field assigns a unique value to fragments from the same original datagram, enabling reassembly at the destination; updated specifications clarify that for non-fragmented packets (with Don't Fragment set), IDs need not be globally unique but must avoid reuse within a datagram's lifetime for fragmented ones.[1][12] The 3-bit Flags field includes the Don't Fragment (DF) bit (bit 1: 1 prevents fragmentation, signaling path MTU discovery) and More Fragments (MF) bit (bit 2: 1 indicates additional fragments follow, 0 for the last).[1] Complementing this, the 13-bit Fragment Offset field specifies the fragment's position in the original datagram, measured in 8-octet units, with the first fragment at offset 0 to facilitate ordered reassembly.[1] The 8-bit Time to Live (TTL) field limits a packet's lifespan in the network, decremented by at least 1 at each router; reaching zero causes discard and an ICMP Time Exceeded message to prevent indefinite looping.[1] The Protocol field, also 8 bits, identifies the upper-layer protocol encapsulated in the data (e.g., 1 for ICMP, 2 for IGMP), with values maintained in the IANA registry for standardized assignment.[1][13] The 16-bit Header Checksum field ensures header integrity through a one's complement sum, computed only over the header and recomputed by each router due to TTL changes.[1] The 32-bit Source Address identifies the packet's originator and remains unchanged throughout transit, while the Destination Address specifies the final recipient; post-CIDR, these employ classless addressing for efficient allocation and routing without fixed class boundaries.[1][14] Finally, the variable-length Options field, padded to a 32-bit boundary, supports advanced features like loose source routing (specifying intermediate routers) or record route (logging path timestamps), but is rarely used today due to security vulnerabilities such as topology mapping, firewall evasion, and denial-of-service risks from processing overhead.[1][9] When absent, IHL is 5, keeping the header at 20 bytes.[1]IPv6 Packet Format
Header Structure
The IPv6 packet header is a fixed-size structure designed for simplicity and efficiency in processing, consisting of 40 bytes (320 bits) organized into eight 32-bit words.[2] This fixed layout eliminates the variable-length options present in earlier protocols, ensuring consistent parsing without the need for header length indicators.[2] All fields are aligned in network byte order, with the base header followed optionally by extension headers and the payload.[2] The header begins with the Version field, a 4-bit value set to 6 to indicate IPv6.[2] Immediately following are the Traffic Class (8 bits) and Flow Label (20 bits), which together form a 28-bit field for quality-of-service handling; the Traffic Class supports differentiated services code points (DSCP) and explicit congestion notification (ECN), while the Flow Label enables per-flow treatment for sequences of packets, such as in multimedia streams.[2] Subsequent fields include the Payload Length (16 bits), which specifies the size in octets of the packet's payload plus any extension headers (excluding the base header itself), allowing for jumbo payloads up to 65,535 octets or more via special handling.[2] The Next Header field (8 bits) identifies the type of the header immediately following the base header, which could be an extension header, an upper-layer protocol (e.g., TCP or UDP), or the payload if no extensions are present; it uses values from the IANA protocol numbers registry.[2] The Hop Limit (8 bits) functions as a time-to-live mechanism, decremented by one at each forwarding node and causing packet discard if it reaches zero to prevent infinite loops.[2] The header concludes with the Source Address and Destination Address fields, each 128 bits long, providing a vastly expanded address space compared to prior versions and formatted as specified in the IPv6 addressing architecture.[2] Unlike some earlier protocols, the IPv6 base header contains no checksum field, relying instead on link-layer mechanisms or upper-layer protocols (e.g., TCP) for error detection and integrity checks.[2] Extension headers, if present, are inserted as a chain after the base header and processed by nodes in the order they appear, with each one's type indicated by the preceding Next Header field.[2] Common examples include the Hop-by-Hop Options header, which carries options processed by every node along the path, and the Routing header, which specifies intermediate nodes for the packet to visit.[2]| Field | Size (bits) | Purpose |
|---|---|---|
| Version | 4 | Identifies the IP version (value 6). |
| Traffic Class | 8 | Supports QoS classification (DSCP + ECN). |
| Flow Label | 20 | Enables flow-based handling for packet sequences. |
| Payload Length | 16 | Length of extension headers + upper-layer data. |
| Next Header | 8 | Type of the next header or protocol. |
| Hop Limit | 8 | Decrements per hop; discards at zero. |
| Source Address | 128 | IPv6 address of the sender. |
| Destination Address | 128 | IPv6 address of the recipient. |
Extension Headers and Options
IPv6 extension headers provide a modular mechanism to carry optional internet-layer information, allowing additional functionality without increasing the size of the fixed base header. These headers are inserted between the IPv6 base header and the upper-layer header (or another extension header), enabling features such as security, routing, and fragmentation to be added as needed by the source node.[2] This design enhances flexibility and efficiency compared to mandatory parsing of all options in earlier protocols.[2] Extension headers are chained together using the Next Header field in the preceding header, which identifies the type of the next header in the sequence. Processing occurs in a defined order: the base IPv6 header first, followed by Hop-by-Hop Options (examined by every node along the path), then any initial Destination Options, Routing Header, Fragment Header, Authentication Header, Encapsulating Security Payload, a second set of Destination Options (processed only by the final destination), and finally the upper-layer header.[2] Routers and destinations must process these headers sequentially, skipping unrecognized ones based on option action codes to ensure forward compatibility.[2] The primary types of IPv6 extension headers include:- Hop-by-Hop Options (Next Header value 0): Processed by all intermediate nodes; used for options like the Jumbo Payload option, which supports packets larger than 65,535 bytes (up to 4,294,967,295 bytes) by specifying a 32-bit payload length.[2][15]
- Routing Header (Next Header value 43): Enables source routing by listing intermediate nodes the packet must visit.[2]
- Fragment Header (Next Header value 44): Handles fragmentation when packets exceed the path MTU.[2]
- Authentication Header (Next Header value 51): Provides integrity and authentication for IPsec, as defined in the IPsec architecture.[2]
- Encapsulating Security Payload (Next Header value 50): Offers confidentiality, integrity, and authentication for IPsec payloads.[2]
- Destination Options (Next Header value 60): Processed only by the final destination; includes options like the Home Address option for Mobile IPv6, allowing a mobile node to use its home address while roaming.[2]
Fragmentation and Reassembly
IPv4 Mechanisms
In IPv4, fragmentation occurs when a datagram exceeds the maximum transmission unit (MTU) of the outgoing network interface on an intermediate router, such as the 1500-byte limit typical of standard Ethernet links.[1] If the Don't Fragment (DF) bit in the packet's Flags field is cleared, the router divides the datagram into smaller fragments to forward them across the link.[1] The Flags and Fragment Offset fields in the IPv4 header, as described in the key header fields section, govern this splitting process.[1] The fragmentation process copies the original IP header to each fragment, updating the Total Length field to reflect the fragment's size, setting the More Fragments (MF) bit to 1 for all but the last fragment, and assigning a Fragment Offset value (in units of 8 bytes) to indicate the position of the fragment's data relative to the start of the original datagram's payload.[1] All fragments retain the same Identification field value, source and destination addresses, and protocol number to enable later reassembly.[1] The payload is divided into chunks such that each fragment's total length (header plus data) fits within the MTU, with offsets ensuring alignment on 8-byte boundaries; the minimum reassembly buffer size required at destinations is 576 bytes, though non-last fragments must contain at least 8 bytes of data (28 bytes total with 20-byte header), and every internet module must be able to forward a datagram of 68 octets without further fragmentation (accounting for up to 60-byte header plus 8 bytes of data).[1] Reassembly takes place exclusively at the final destination host, which identifies matching fragments using the Identification field combined with the source address, destination address, and upper-layer protocol.[1] The host orders the fragments by their offset values and concatenates the payloads sequentially until the fragment with MF=0 (the last one) arrives, at which point the complete datagram is delivered to the transport layer.[1] This reassembly is atomic: the upper layer receives the datagram only after all fragments have been collected, preventing partial delivery.[1] To manage incomplete reassembly, the destination sets a fixed reassembly timer—recommended to be between 60 and 120 seconds—for each datagram; if any fragments fail to arrive before expiration, the entire set is discarded to free resources.[4] If the DF bit is set and fragmentation is required, the router discards the datagram and generates an ICMP Destination Unreachable message (Type 3, Code 4: "Fragmentation Needed and DF Set") back to the source, including the MTU of the obstructing link in the message's unused field to suggest an adjusted packet size.[18][19] This mechanism supports Path MTU Discovery (PMTUD), where the source host iteratively reduces its estimated path MTU based on such ICMP feedback, probing upward periodically (e.g., every 10 minutes initially) to optimize transmission while avoiding fragmentation.[19] Fragmentation introduces drawbacks, including increased end-to-end latency from multiple packet transmissions and heightened vulnerability to errors, as the loss of even one fragment necessitates discarding and retransmitting the entire original datagram.[19] PMTUD mitigates these issues by enabling endpoints to discover and adhere to the path's minimum MTU, thereby reducing reliance on in-network fragmentation.[19]IPv6 Mechanisms
IPv6 implements an endpoint-only fragmentation model, where fragmentation is performed exclusively by the source host rather than by intermediate routers.[2] This design shift requires senders to ensure that packets do not exceed the path's maximum transmission unit (MTU), with a minimum link MTU of 1280 bytes mandated for all IPv6-capable interfaces.[2] If a packet exceeds this limit, the source must fragment it prior to transmission or use Path MTU Discovery to determine an appropriate size.[20] Routers encountering oversized packets simply discard them and send an ICMPv6 "Packet Too Big" message (Type 2) to the source, without attempting fragmentation.[2] The Fragment Header serves as an IPv6 extension header to support this process, inserted by the source when fragmentation is necessary.[2] It consists of an 8-octet structure including a Next Header field (8 bits, indicating the type of header following the Fragment Header), a Reserved field (8 bits, set to zero), a Fragment Offset field (13 bits, specifying the offset of the data in 8-octet units from the start of the original packet's payload), a Reserved bits field (2 bits), an M flag (1 bit, set to 1 for more fragments or 0 for the last fragment), and an Identification field (32 bits, used to match fragments of the same original packet).[2] The source inserts the Fragment Header immediately before the upper-layer header or another extension header, creating multiple fragments from a single original packet if required, each carrying a copy of the unfragmented portion of the header chain.[2] As noted in the IPv6 extension headers overview, the Fragment Header (Next Header value 44) is processed at the destination only.[2] Reassembly occurs solely at the destination host, using the Source Address, Destination Address, and Identification fields from the Fragment Headers to group matching fragments, along with the Fragment Offset to reconstruct the original payload in order.[2] The process supports atomic reassembly, where fragments with a zero offset and M flag set to 0 are treated as complete, non-fragmented datagrams.[2] If reassembly is not completed within 60 seconds, the packet is silently discarded.[2] Path MTU Discovery (PMTUD) is mandatory in IPv6 to enable senders to adapt to varying path MTUs dynamically.[20] The source begins with an assumed PMTU equal to the first-hop interface MTU and sends packets at that size; upon receiving an ICMPv6 "Packet Too Big" message (Type 2, Code 0 for MTU exceeded), it reduces the PMTU to the value indicated in the message (never below 1280 bytes) and retransmits smaller packets.[20] To probe for potential PMTU increases, the sender periodically sends packets larger than the current PMTU after a minimum interval (at least 5 minutes following a reduction, preferably 10 minutes), adjusting upward only upon successful delivery.[20] ICMPv6 messages must be validated per security guidelines to prevent spoofing.[20] For payloads exceeding 65,535 octets on links supporting MTUs greater than 65,575 octets, the Jumbo Payload option in the Hop-by-Hop Options extension header allows transmission of jumbograms.[15] This option includes a 32-bit Jumbo Payload Length field specifying the exact payload size (from 65,536 to 4,294,967,295 octets), overriding the 16-bit Payload Length field in the IPv6 header, which is set to zero when this option is present.[15] The option type is C2 (hexadecimal), with an option data length of 4 octets, and requires alignment on a 4n+2 boundary.[15] This fragmentation model reduces processing load on routers by eliminating in-transit fragmentation, making it more suitable for high-speed networks where router efficiency is critical.[21] However, firewalls or security policies that block ICMPv6 "Packet Too Big" messages can disrupt PMTUD, leading to persistent packet drops and connectivity issues.[21]Error Detection and Checksum
IPv4 Header Checksum
The IPv4 header checksum serves to detect bit errors in the header during transmission across networks, ensuring the integrity of control information such as addresses and protocol fields. It is a 16-bit value computed over the entire header, excluding the payload, and is verified at each hop to discard corrupted datagrams before further processing.[1] The checksum is calculated using a 16-bit one's complement sum of all 16-bit words in the header, including any options but with the checksum field itself temporarily set to zero. The header is divided into 16-bit words, aligned from the most significant byte, and their values are added together, with any carry bits wrapped around by adding them to the least significant bits (end-around carry addition). The final checksum is the one's complement (bitwise inversion) of this sum, expressed as: \text{Checksum} = \sim \left( \sum_{i=1}^{n} w_i \mod 2^{16} \right) where w_i are the 16-bit words of the header (checksum field zeroed), and \sim denotes one's complement negation. This method, detailed in the Internet checksum algorithm, allows efficient computation and is independent of byte order.[1][22] At the receiver, the checksum is verified by recomputing the one's complement sum over the received header, including the received checksum value in place of the zeroed field. If the result equals 0xFFFF (all ones, equivalent to zero in one's complement arithmetic), the header is valid; otherwise, the packet is silently discarded. This verification occurs at every router and endpoint to catch transmission errors early.[1][22] The checksum applies solely to the IPv4 header and does not cover the payload data, which relies on checksums in upper-layer protocols like TCP or UDP, or on link-layer mechanisms for integrity checks. Options in the header, if present, are padded to a multiple of 16 bits and included in the sum.[1] Routers must recompute the checksum whenever they modify header fields, such as decrementing the Time to Live (TTL) value or adjusting during fragmentation, to maintain validity for subsequent hops. This incremental update can be performed efficiently using formulas that account only for the changed fields, avoiding full recalculation.[1][23] While effective against single-bit errors and many multi-bit errors, the checksum has limitations: it cannot detect all error patterns, such as certain burst errors where the damaged bits sum to zero modulo $2^{16}, and it provides no protection for the payload. Originally provisional in IPv4 design, it was retained but omitted in IPv6 due to advancements in link-layer error detection and the assumption of more reliable transmission media in modern networks, shifting burden to upper layers.[1][2] For illustration, consider a minimal 20-byte IPv4 header in hexadecimal (no options), with the checksum field zeroed for computation:- 45 00 00 28 00 00 00 00 40 06 00 00 C0 A8 01 01 C0 A8 01 02
- 0x4500 + 0x0028 = 0x4528
- 0x4528 + 0x0000 = 0x4528
- 0x4528 + 0x0000 = 0x4528
- 0x4528 + 0x4006 = 0x852E
- 0x852E + 0x0000 = 0x852E
- 0x852E + 0xC0A8 = 0x145D6 → carry 1, add to low: 0x45D6 + 0x0001 = 0x45D7
- 0x45D7 + 0x0101 = 0x46D8
- 0x46D8 + 0xC0A8 = 0x0780 → carry 0 (full sum 0x10780, but wrapped: 0x0780 + 0x0001? Wait, precise: 0x46D8 + 0xC0A8 = 0x10780, carry 1 to low 0x0780 +1 =0x0781
- 0x0781 + 0x0102 = 0x0883