The Internet Protocol has three defining characteristics that shape how every IP-based network actually behaves: it’s connectionless, it provides best-effort (unreliable) delivery, and it’s media independent. Understanding these three properties explains a lot about why the internet is architected the way it is, and why so much responsibility for reliability gets pushed up to higher layers. This guide covers each characteristic in detail, along with the fragmentation process that falls directly out of IP’s media independence.
Connectionless
IP doesn’t establish a connection with the destination before sending data. No initial exchange of control information sets up an end-to-end session before packets start flowing; a device simply sends its packets and hopes they arrive. This mirrors sending a letter without any prior notice to the recipient, rather than placing a phone call, which would require the other party to actually pick up first.
Because no connection needs to be maintained, IP’s header doesn’t need additional fields to track connection state, which keeps IP’s overhead genuinely low. The tradeoff is real, though: with no pre-established connection, a sending device has no way to know whether the destination device is even present and functional, let alone whether it actually received and could process a given packet. This tradeoff is central to understanding almost everything else about how IP behaves.
IP and UDP are both connectionless protocols, and both are described as stateless, since neither endpoint has any protocol-defined mechanism for remembering where it is in an ongoing exchange of messages. The alternative is a connection-oriented, stateful protocol like TCP, which does track exactly that kind of conversational state, remembering sequence numbers, acknowledgments, and session details across the entire exchange.
Best-Effort (Unreliable) Data Delivery
IP provides no guarantee that a packet will actually arrive. Its header has no fields for delivery tracking, acknowledgments, or retransmission, so if a packet gets lost, arrives out of order, or arrives corrupted, IP itself does nothing about it. This is precisely why the phrase “best-effort” is used rather than “reliable”: IP will try to deliver a packet, but it makes no promises.
Responsibility for actually resolving these problems falls to the layers above IP. In the TCP/IP protocol suite, the transport layer is specifically where reliability, when an application needs it, gets implemented. TCP adds sequencing, acknowledgments, and retransmission on top of IP’s best-effort delivery, turning an unreliable underlying transport into a reliable one from the application’s point of view.
UDP, by contrast, doesn’t add any of that, which is a deliberate design choice for applications, like real-time voice or video, where a late retransmitted packet is often less useful than simply dropping it and moving on, since a stale frame of video arriving late is worse than no frame at all.
Media Independent
IP operates independently of whatever physical medium actually carries it, copper, fiber optic, or wireless. The data link layer is responsible for taking a fully formed IP packet and preparing it appropriately for transmission over whatever specific medium is in use. This separation is exactly what lets the same IP packet travel across a Wi-Fi link, then an Ethernet cable, then a fiber backbone, all within a single end-to-end journey, without IP itself needing to know or care about any of those transitions.
Each medium does impose one real constraint: a Maximum Transmission Unit (MTU), the largest frame size that specific medium can carry. The data link layer communicates its MTU value up to the network layer, which then has to account for it when determining how large a given packet can actually be for that particular hop.
Packet Fragmentation and Reassembly
When an IP packet is larger than the MTU of a network segment it needs to cross, it has to be fragmented, split into smaller pieces, each carrying its own IP header, before it can be sent across that segment. The destination host reassembles these fragments back into the original packet using the fragment offset and identification fields present in each fragment’s IP header.
It’s important to be precise about one detail that’s often left out: this description applies specifically to IPv4. IPv4 allows routers along a packet’s path to fragment it in transit if a segment’s MTU is smaller than the packet. IPv6 removed this capability entirely.
Under IPv6, intermediate routers never fragment a packet; if a packet is too large for a given link, the router simply drops it and sends back an ICMPv6 “Packet Too Big” message to the source. The source host is then responsible for performing Path MTU Discovery and fragmenting the packet itself before sending, if fragmentation is genuinely needed at all.
This shift moves fragmentation work off routers entirely, reducing their processing burden, at the cost of requiring source hosts to be more proactive about discovering the effective path MTU up front. It’s a good example of how IPv6’s design choices generally trade a bit more upfront host responsibility for meaningfully simpler, faster router behavior across the network as a whole.
A Worked Example: All Three Characteristics in One Transfer
It helps to see all three characteristics working together in a single scenario. Say a laptop on a Wi-Fi network downloads a large file from a web server reached over a mix of fiber and copper links along the way.
The connectionless nature of IP means each individual packet in that download is addressed and sent independently, with no session state tracked at the IP level itself; if this were purely IP with no TCP layered on top, there would be no way to know whether packets arrived in order, or at all. Best-effort delivery means IP itself makes no promises about any of those packets; some may indeed be lost or arrive out of order as they cross congested links along the path.
Media independence means those packets don’t care that they started on Wi-Fi, then crossed a fiber backbone, then possibly a copper Ethernet segment at the server’s end; IP treats the entire journey uniformly, leaving the data link layer at each hop to handle the specifics of whatever medium is actually in use there.
None of this would work reliably for a file download without TCP running on top, tracking sequence numbers, requesting retransmission of lost segments, and reassembling everything in the correct order before handing a complete, correct file to the application. This is exactly the division of labor IP’s design assumes: keep the network layer simple, fast, and universally applicable, and let the transport layer add whatever reliability a specific application actually needs.
Troubleshooting Issues Related to These Characteristics
Intermittent packet loss on an otherwise healthy-looking connection. Since IP itself provides no delivery guarantee, some baseline packet loss is normal, especially over long paths or congested links, and TCP is specifically designed to recover from it transparently. Persistent, heavy loss beyond what TCP can efficiently recover from usually points to a specific link or device along the path, worth isolating with tools like traceroute or MTR rather than assuming IP itself is misbehaving. A loss pattern that consistently appears at the same hop across repeated tests is a strong signal to focus troubleshooting there specifically.
A VPN or tunneled connection working for small transfers but failing or stalling on larger ones. This is a classic MTU-related symptom. Tunneling protocols add their own header overhead on top of the original packet, which can push an otherwise normal-sized packet over a link’s actual MTU. If Path MTU Discovery isn’t working correctly, often because ICMP messages needed for it are being blocked somewhere along the path, packets that should be resized or fragmented instead simply vanish, causing exactly this kind of size-dependent failure.
A UDP-based application, like VoIP or video streaming, experiencing choppy quality under network congestion. Since UDP doesn’t add retransmission or ordering on top of IP’s best-effort delivery, packet loss shows up directly as degraded quality rather than a delay while data gets resent. This is an expected tradeoff for latency-sensitive applications, not a bug, though it does mean UDP-based applications need their own application-layer strategies, like forward error correction, if they want to tolerate loss more gracefully. Comparing observed loss and jitter against the application’s documented tolerance thresholds is usually more productive than chasing a “fix” for behavior that’s actually working as designed.
Why This Design Choice Has Aged So Well
It’s worth appreciating how deliberately this division of labor was designed, rather than treating IP’s simplicity as a limitation to work around. Pushing reliability, ordering, and connection state up to the transport layer, rather than baking them into IP itself, is exactly what let the internet scale the way it has. A network layer that had to track connection state for every single flow passing through every router would face a fundamentally harder scaling problem than one that just forwards independent, stateless packets as fast as possible.
The tradeoff of pushing complexity upward, into TCP for applications that need it and leaving it out entirely for applications like UDP that don’t, has proven remarkably durable across decades of dramatically increasing network scale and traffic volume. Very few architectural decisions from IP’s original design have needed to change as fundamentally as this one has stayed the same.
Frequently Asked Questions
Why is IP described as connectionless?
IP sends packets without first establishing a session or exchanging setup information with the destination, unlike a connection-oriented protocol that confirms a session is ready before data flows. This keeps IP’s own overhead low, but it also means IP itself has no way to know whether a destination device is available or actually received what was sent.
What does “best-effort delivery” actually mean?
Best-effort delivery means IP attempts to deliver a packet but makes no guarantees about it arriving, arriving in order, or arriving uncorrupted, since its header has no fields for tracking delivery or triggering retransmission. Applications that need guaranteed, ordered delivery rely on a transport layer protocol like TCP, built on top of IP, to provide that reliability instead.
What does it mean for IP to be media independent?
Media independence means IP doesn’t care whether the underlying physical medium is copper, fiber, or wireless; the data link layer handles preparing a packet for whichever specific medium is actually in use for a given hop. This is what lets a single packet cross multiple different physical media types during one end-to-end journey without IP itself needing any medium-specific logic.
What is MTU and why does it matter?
MTU, Maximum Transmission Unit, is the largest packet size a specific network medium can carry in a single frame. It matters because a packet exceeding a segment’s MTU can’t cross that segment without being fragmented first, and understanding MTU is often the key to diagnosing certain intermittent connectivity issues, particularly ones involving VPNs or tunneling protocols that add extra header overhead, since those extra headers can push a normal packet just over a link’s actual limit.
How does IPv6 handle fragmentation differently from IPv4?
IPv4 allows routers to fragment a packet in transit if it’s too large for the next segment’s MTU. IPv6 removed this entirely; routers simply drop an oversized packet and notify the source via ICMPv6, leaving the source host responsible for discovering the correct path MTU and fragmenting the packet itself before sending, rather than relying on routers to handle it along the way.
Why does IP push reliability up to higher layers instead of handling it itself?
This is a deliberate architectural choice, not an oversight. Not every application needs guaranteed, ordered delivery, real-time voice and video generally prefer a dropped packet over a late retransmitted one, so building mandatory reliability into IP itself would add overhead that many applications don’t actually want. Letting each application choose between TCP and UDP, depending on what it actually needs, is far more flexible than a one-size-fits-all approach at the network layer, and it’s a design principle that shows up repeatedly throughout the rest of the TCP/IP stack as well.
