MTU can either be ignored or handled. If an application attempts to increase efficiency via MTU discovery, the network must be capable of proper MTU negotiation to avoid potential misalignment.

First, let us examine two methods that ignore downstream MTU. The first method is to send very small packets. Doing so ensures that no fragmentation will be required anywhere on the way, at the cost of neglecting CPU utilization and network overhead as factors. Typically, implementations that use this method send 576-byte packets.

The second MTU-unaware method uses the "DF" (Don't Fragment) bit in the IP header, which controls the fragmentation of each packet. This method simply unsets this bit, enabling fragmentation throughout the entire path. Routers that receive packets that are too large must handle the situation by fragmenting the packets. In practice, this method simply ignores the MTU issue at the source, and leaves the dirty work for the other entities in the path.
This method wastes even more network resources than the previous small-packet example. The router must work very hard to fragment packets, and the destination host must reassemble the data. Forcing the router to do fragmentation for over-sized packets is not scalable or practical. Luckily, today's TCP/IP implementations rarely require down-stream fragmentation.

Well-behaved TCP/IP implementations attempt to discover the downstream MTU and adjust the packet sizes accordingly. They set the "Don't Fragment" bit in all IP packets ensuring that downstream routers are never burdened with unnecessary fragmentation duties. The entire "Path" MTU (PMTU) is discovered as per RFC 1191, and packet sizes are adjusted to the smallest Link MTU in the path.
Although at first this method does not seem very efficient, it uses the least network resources of all. Furthermore, the router does not have to suffer the overhead of fragmenting packets, and the end devices are passing large payloads using the largest packet sizes allowed.
In a perfect Internet, this method would be used all the time, in order to optimize performance of all hosts and routers. However, as you'll see in the next section, this is not always applicable.

There are some significant network errors that can occur during path MTU negotiation:

1. The router must respond with the appropriate ICMP message when the maximum packet size is exceeded. Often with older routers or routers configured as bridges, oversized packets are dropped without any notification to the originating station. The originating station considers the packet as lost due to congestion, and retransmits repeatedly. This is considered to be a "blackhole" hop.
2. Some routers respond with an old-style "fragmentation needed and DF set" ICMP message that does not contain additional destination information that lets the source computer know where the failing packet was trying to get to. Without this information, the source computer will not be able to figure out which socket the ICMP message is associated with. The result is that PMTU discovery fails when routers send old-style ICMP messages.
3. Some routers report their MTU incorrectly. This is particularly destructive if it reports an MTU larger than reality. These routers are referred to as "gray-hole" hops.
4. MTU negotiation errors are very difficult to detect and manifest themselves in subtle but destructive behaviors. Often MTU problems are mistaken for viruses. Some examples are:
   • FTP upload of a large file takes a few minutes, but download takes hours, or even fails.
   • FTP downloads work only with small files.
   • Web pages load quickly, but .GIF files do not make it.
   • E-mail works, but discussion databases fail.