What happens to a packet larger than the MTU depends upon the network protocol.  In some protocols, it also depends upon the contents of the packet's header, and occasionally can be affected by the policies of a router along the path.  

In the case of the most common protocol, IPv4, the packet will be fragmented upon encountering a link with an MTU lower than the packet size, unless the "Don't Fragment" (DF) flag set in the packet's IP header.  Fragmented means the router at that link will split the packet into packets that are smaller than the MTU before sending them through the link.  If the DF flag is set, the packet will instead be dropped, and the router will return an ICMP packet (Type 3, Code 4, "Fragmentation Needed") to the source, which includes that link's maximum MTU.  The source can then reduce its MTU and try again.  Most modern operating systems and routers now exploit this, in what is called Path MTU Discovery, by which they set the DF flag on outgoing IPv4 packets.  If any router on the path returns an ICMP for the test packet indicating too high an MTU, the source lowers its outgoing MTU for that path (called the Path MTU) to the MTU returned in the ICMP.  The process repeats until the entire path is traversed with no dropped packets, assuring the least fragmentation for that path.

In the case of IPv6, routers do not fragment packets, as there is no Don't Fragment option in the IPv6 header. Thus, Path MTU Discovery is a requirement for IPv6.  It works by initially assuming the path MTU is the same as the MTU on the link layer interface where the traffic originates. Then, similar to IPv4, any device along the path whose MTU is smaller than the packet will drop the packet and send back an ICMPv6 (Type 2, "Packet Too Big") message containing its MTU, allowing the source host to reduce its Path MTU appropriately. The process is repeated until the MTU is small enough to traverse the entire path without fragmentation.

In both cases, if the Path MTU changes after the connection is set up and is lower than the previously determined Path MTU, the first large packet will cause an ICMP error and the new, lower Path MTU will be found. However, if the path changes and the new path MTU is larger, the source will not learn about the increase because routers do not store state.

In some instances, a packet may be inadvertently dropped silently for too high MTU.  This can happen when a network security device gets configured to block all ICMP messages for perceived security benefits, including the errors that are necessary for the proper operation of Path MTU Discovery. Such connections may complete the TCP three-way handshake correctly, but then hang when data are transferred. This state is referred to as a black hole connection. 

Some implementations of Path MTU Discovery attempt to prevent this problem by inferring that large payload packets have been dropped due to MTU rather than because of link congestion. However, in order for the Transmission Control Protocol (TCP) to operate most efficiently, ICMP type 3 ("Unreachable") messages should be permitted. A robust method for Path MTU Discovery that relies on TCP or another protocol to probe the path with progressively larger packets has been standardized in RFC 4821.

Another workaround used by some routers is to change the maximum segment size (MSS) of all TCP connections passing through links with MTU lower than the Ethernet default of 1500. This is known as MSS clamping.

You can learn more about how many other protocols handle [MTU](https://en.wikipedia.org/wiki/Maximum_transmission_unit) and [Path MTU Discovery](https://en.wikipedia.org/wiki/Path_MTU_Discovery) on Wikipedia.
spam fails_task lang_mismatch pii not_appropriate hate_speech sexual_content quality toxicity humor helpfulness creativity violence