How to test and fix IPv6 fragmentation issues
In an earlier blog post, I discussed the issues associated with IPv6 packet fragmentation. Of particular significance, IPv6 fragmentation relies extensively on the computer sourcing packets being able to receive ICMPv6 “packet too big” message type 2 sent from any intermediate device in the route to the packet’s destination.
The capability to confirm that an end user in a network will correctly receive the packet-too-big ICMPv6 message has been added to the test-ipv6 mirrors, including http://test-ipv6.arbor.net. This new capability allows a user to identify if the packet-too-big message is being discarded between the user’s computer and the web site.
In the “Tests Run” tab of the main test-ipv6 mirror page, the “Test IPv6 large packet” test documents the IPv6 fragmentation behavior. If further information is desired, one can click on the “Technical Info” link.
If the “Test IPv6 large packet” test is failing, the packet-too-big ICMPv6 message is likely being dropped. This indicates issues within the user’s computer, enterprise network or elsewhere along the path to the test-ipv6 mirror. The problematic device may be a router or firewall device, although it may even be the “firewall” software configured on the user’s computer.
Any device in the network path may be dropping packet-too-big messages. After the user has confirmed that the source computer isn’t dropping the packet-too-big ICMPv6 message, the user may need to work with the enterprise or service provider network support staff to isolate and resolve where the packet-too-big ICMPv6 message is being dropped. The user may also want to test against other test-ipv6 mirrors (these sites are accessible via the “Other IPv6 Sites” link on http://test-ipv6.arbor.net), which may confirm that the specific test-ipv6 mirror isn’t a problem or if the problem potentially follows a specific network path. The user may also wish to either run the test from the same computer, but on different networks or from a different computer on the same network.
When I configured packet-too-big testing on test-ipv6.arbor.net, I rediscovered some of the pitfalls of ensuring that a router or firewall will correctly allow packet-too-big messages to be transited. After enabling the test on the test-ipv6.arbor.net web server, I discovered that the router/firewall protecting test-ipv6.arbor.net was not transiting packet-too-big messages from the web server back to the originating host computer. Fixing this problem required changing the router/firewall configuration to explicitly allow packet-too-big messages. From an IPv6 proponent’s perspective, it is concerning that the router/firewall is relatively well-known and frequently used. The “workaround” to fix the fragmentation handling problems was non-trivial and it would seem that most network administrators are unlikely to fix this problem in lieu of an otherwise perfectly functional firewall policy.