I started reading TCP/IP Vol1 by Jeff Doyle and came across an interesting field for IPv4 packet headers; the Flags field. I will be talking on how to use this field to your advantage and give a little insight about IPv6 fragmentation.
The Flags field is a 3 bit field in which the first bit is always unused. The second bit is the “Don’t Fragment (DF) bit”. When you set the DF bit to 1, the router does not fragment the packet. This function is often used for the testing and troubleshooting of MTU issues in IPv4 networks. When using the ping extended command, you can specify to “Set the DF bit in IP header” and use it with “sweep range of sizes” option to determine the largest MTU of the path to a destination network. You can combine this with the “Record” option (assuming ip source routing hasn’t been disabled) to determine the exact location where you have an MTU bottleneck.
In IPV6 however, routers do not fragment packets because IPV6 headers do not have a “Flags” or the “Fragment Offset” field. Instead the TCP Path MTU Discovery process is used. The only problem is that this process relies on ICMPv6 (Type 2) Packet too Big messages to be passed through the network and often ICMP and ICMPv6 messages are blocked or filtered. This results in having to set configurations for tunnel interfaces, FDDI or PPPoE to the maximum MTU of the link (usually 1500 bytes), for the network to function properly. Another option would be to use the Packetization Layer Path MTU Discovery defined by RFC 4821 which, as far as I know, has not been implemented by Cisco.
Note: A common misconception is that IPv6 does not do fragmentation. This is not true. IPv6 does not allow routers to fragment packets but end-nodes may insert an IPv6 fragmentation extension header to fragment a packet.