| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
IPv6 Datagram Size, Maximum Transmission Unit (MTU), Fragmentation and Reassembly (Page 2 of 4) Implications of IPv6's "Source Only" Fragmentation Rule I find the changes in the fragmentation and reassembly process interesting. While many other changes in IPv6 represent a shift in responsibility for functions from host devices to routers, this one is the opposite. In IPv4, a source node can really send a datagram of any size its local link can handle, and let the routers take care of fragmenting it as needed. This seems like a sensible model; nodes communicate on a large virtual network and the details of splitting messages as needed for physical links are handled invisibly. The problem with this is that it represents a performance drag on routing. It is much faster for a router to forward a datagram intact than to spend time fragmenting it. In some cases, fragmentation would have to occur multiple times during transmission of a datagram, and remember that this must happen for every datagram on a route. It is a lot more efficient for the source to just send datagrams that are the right size in the first place. Of course, there's a problem here: how does the source know what size to use? It has no idea of the physical networks used by the route datagrams will take to a destination; in fact, it doesn't even know what the routes are! It has two choices:
Since routers can't fragment in IPv6, if a datagram is sent by a source that is too large for a router, it must drop the datagram. It will then send back to the source feedback about this occurrence, in the form of an ICMPv6 Packet Too Big message. This tells the source that its datagram was dropped and that it must fragment (or reduce the size of its fragments.) This feedback mechanism is also used in discovering path MTUs. The source node sends a datagram that has the MTU of its local physical link, since that represents an upper bound on the MTU of the path. If this goes through without any errors, it knows it can use that value for future datagrams to that destination. If it gets back any Packet Too Big messages, it tries again using a smaller datagram size. The advantage of this over the default of 1280 is that it may allow a large communication to proceed with a higher MTU, to improve performance. One drawback of the decision to only fragment at the source is that it introduces the potential for problems if there is more than one route between devices or if routes change. In IPv4, fragmentation is dynamic and automatic; it happens on its own and adjusts as routes change. Path MTU Discovery is a good feature, but it is static. It requires that hosts keep track of MTUs for different routes, and update them regularly. This is done by redoing path MTU discovery if a node receives a Packet Too Big message on a route for which it has previously performed path MTU discovery, but this takes time.
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. |