| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
ICMPv6 Packet Too Big Messages (Page 1 of 3) One of the most interesting changes made to the operation of the Internet Protocol in version 6 is related to the process of datagram fragmentation and reassembly. In IPv4, a host can send a datagram of any size allowed by the IP specification out onto the internetwork. If a router needs to send the datagram over a physical link that has a maximum transmission unit (MTU) size that is too small for the size of the datagram, it will automatically fragment the datagram and send the fragments individually so they will fit. The destination device will receive the fragments and reassemble them. I explain the basics behind this in the section on IPv4 datagram size, MTU, fragmentation and reassembly.
Even though it is convenient for hosts to be able to rely on routers to automatically fragment messages as needed, it is inefficient for routers to spend time doing this. For this reason, in IPv6 the decision was made to not allow routers to fragment datagrams. This puts the responsibility on each host to ensure that datagrams they send out are small enough to fit over every physical network between itself and any destination. This is done either by using the IPv6 default minimum MTU of 1280, which every physical link must support, or a special Path MTU Discovery process for determining the minimum MTU between a pair of devices. Again, the full details are in the discussion of IPv6 datagram size, MTU, fragmentation and reassembly. If an IPv6 router is not allowed to fragment an IPv6 datagram that is too large to fit on the next physical link over which it must be forwarded, what should the router do with it? The datagram can't be forwarded, so the router has no choice but to discard it. When this happens, the router is required to report this occurrence back to the device that initially sent the datagram, using an ICMPv6 Packet Too Big message. The source device will know that it needs to fragment the datagram in order to have it successfully reach its destination.
Home - Table Of Contents - Contact Us The TCP/IP Guide (http://www.TCPIPGuide.com) Version 3.0 - Version Date: September 20, 2005 © Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. |