One consequence of many of the design decisions made when devising IPv4 is the lack of a reasonable reliability guarantee, even if the network itself is behaving reliably. Although IP ID numbers are intended to minimize the risk of reassembly collisions, their relatively small 16-bit size (which allows for 65,536 possible values) permits problems to arise occasionally when two packets with identical IP IDs are reassembled at the same time. Also, IP header checksums are simply insufficient to provide reliable integrity protection; although unlikely, a random change in a packet could still give an identical checksum. Too, if the network actually failed, there is no way to find out what data has gone missing, even if the failure is due to something as straightforward as a brief overload of a single network component.

Finally, the Internet Protocol does not provide any way to verify the sender of a message, simply trusting that the real sender is the one listed in the IP header. It is left to higher-level protocols to provide some of the integrity and reliability assurance functionality as necessary—and more often than not, this is necessary. As such, higher-level protocols on top of IP are needed.

TCP, and to a lesser extent, UDP, not only provide much-needed protection for traffic, but also enable the user to specify the recipient (or sender) on a level beyond pointing at a certain system.

Whereas the IP header simply contains enough information to route traffic between two systems, and not enough to decide to which application the information should be delivered, UDP and TCP take things a step further: they move in the realm of the endpoint system, telling the recipient to which application they should direct incoming data.