Description of problem: Node can not include a fragment header in packets sent after receiving icmpv6 packet_too_big message. RFC1981:4 Protocol Requirements A node may receive a Packet Too Big message reporting a next-hop MTU that is less than the IPv6 minimum link MTU. In that case, the node is not required to reduce the size of subsequent packets sent on the path to less than the IPv6 minimun link MTU, but rather must include a Fragment header in those packets. According to RFC1981, after the Packet Too Big message is received, a node must include a fragment header in subsequent packets sent on the path. But RHEL4.8 does not. Version-Release number of selected component: kernel-2.6.9-89.EL How reproducible: always Steps to Reproduce: Test environment: _______ _______ | |eth0 eth0 | | |Tester|-------------------------------|Target|(RHEL4.8) |______| |______| MAC: xx:xx:xx:xx:xx:xx yy:yy:yy:yy:yy:yy ipaddr:3ffe:501:ffff:100:2xx:xxff:fexx:xx 3ffe:501:ffff:100:2yy:yyff:feyy:yyyy Compile the attached program on the Tester: # gcc -o sendtoobig sendtoobig.c program usage: ./sendtoobig saddr daddr saddr :source ipv6 global address daddr :destination ipv6 global address Step1: Target: execute tcpdump to capture packets # tcpdump -i eth0 -s0 -w tcpdump.pcap Step2: Tester: send packet too big message to NUT # ./sendtoobig 3ffe:501:ffff:100:2xx:xxff:fexx:xxxx 3ffe:501:ffff:100:2yy:yyff:feyy:yyyy Step3: Tester: ping6 NUT in order to see if the echo reply include fragment header # ping6 -c1 -I eth0 3ffe:501:ffff:100:2yy:yyff:feyy:yyyy Step4: Target: stop the tcpdump Step5: Target: Investigate 'tcpdump.pcap' file to check if a fragment header is included on the echo reply packet. Actual results: There is no fragment header. Expected results: Fragment header is present in the IPv6 part of the ICMPv6 echo reply. Additional info: This has been already fixed in the upstream and RHEL-5 kernels.
Created attachment 351035 [details] Testing program
Created attachment 351036 [details] Proposed patch Tested with kernel-2.6.9-89.5.EL and it fixed the problem in the description.
Hello, Tomas. How do you get that patch? I can't find it in upstream (2.6.31-rc3), so probably it has been changed. Thanks.
Hello, this patch has been provided by the customer and I can see the code in the RHEL-5 and the recent upstream kernels (with slight differences caused by the fact that we're patching 2.6.9). Apparently it's a backport. I don't know whether there exists 1-1 mapping of the proposed patch with some that has been submitted upstream.
Hi, thanks, Moritoshi and Tomas. I compiled the patched kernel, but I don't find a proper RHEL4 machine to test (I need to have two machine in the same IPV6 subnet). Could any of you give me a hand? The complied kernel is here: i686: https://brewweb.devel.redhat.com/taskinfo?taskID=1891664 x86_64: https://brewweb.devel.redhat.com/taskinfo?taskID=1891503
Committed in 89.7.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0263.html