kern/41472: IPv6 Path MTU Discovery doesn't work in rare case.

[hsuenaga%iij.ad.jp@localhost]

>Number:         41472
>Category:       kern
>Synopsis:       IPv6 Path MTU Discovery doesn't work in rare case.
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri May 22 08:25:00 +0000 2009
>Originator:     SUENAGA Hiroki
>Release:        HEAD of netbsd-4-0
>Organization:
Internet Initiative Japan Inc.
>Environment:
hsuenaga@sue-dev:/usr/src/sys/netinet6 > uname -a
NetBSD sue-dev.iij.ad.jp 4.0 NetBSD 4.0 (GENERIC) #0: Sun Dec 16 00:20:10 PST 
2007  
builds@wb34:/home/builds/ab/netbsd-4-0-RELEASE/i386/200712160005Z-obj/home/builds/ab/netbsd-4-0-RELEASE/src/sys/arch/i386/compile/GENERIC
 i386


>Description:
IPv6 Path MTU Discovery doen't work in rare case. For example, 

  - NetBSD received an ICMP6 Packet Too Big message with MTU < 1272
  - And,  NetBSD received an ICMP6 ECHO Request
  - Then NetBSD sends an ICMP6 ECHO Reply with link MTU. This violates RFC 1981.
     NetBSD must send the ECHO Reply with MTU=1280 and must include a fragment 
header.

RFC1981 says following:

 - RFC1981 Path MTU Dicovery for IP version 6
   - Section 4. Protocol Requirements
      ...
      A node MUST NOT reduce its estimate of the Path MTU below the IPv6
      minimum link MTU.

        Note: 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 [IPv6-
        SPEC].

The cause of this problem is  src/sys/icmp6.c::icmp6_mtudisc_update(). The code 
discards a Packet Too Big message when the message is reporting MTU < 1272 and 
there is no connected-pcb matched to the message. But there are flows that 
don't have connected-pcb. For example, ICMPv6 ECHO, gif tunnels, IPsec tunnels, 
and so on. We should care such flows.

My proposal is following patch:
===================================================================
RCS file: /cvsroot/src/sys/netinet6/icmp6.c,v
retrieving revision 1.152
diff -u -r1.152 icmp6.c
--- icmp6.c     18 Mar 2009 16:00:22 -0000      1.152
+++ icmp6.c     22 May 2009 07:11:37 -0000
@@ -1092,8 +1092,16 @@
                /* is the mtu even sane? */
                if (mtu < sizeof(struct ip6_hdr) + sizeof(struct ip6_frag) + 8)
                        return;
+#if 0
+               /*
+                * This code may violate RFC 1981 section 4.
+                *
+                * We need to care traffic from non-connected pcb.
+                * For example, ECHO Request/Reply don't have connected pcb.
+                */
                if (!validated)
                        return;
+#endif
                mtu = IPV6_MMTU - sizeof(struct ip6_frag);
        }
===================================================================

Recording Path MTU of all non-connected flow may cause a resource problem. We 
should care this problem too. To ignore non-connected flow(original code) is 
one of the solutions. But the care can be achieved in other way. It seems that 
icmp6_mtudisc_update() has codes to deal the resource problem around line 1113. 
The codes is not enough at this time, but I think that improving the codes is 
good way to solve the resource problem.

This problem found on IPv6 Conformance test tool from TAHI project 
(http://www.tahi.org/). The test tool is used in IPv6 Ready LOGO 
program(http://www.ipv6ready.org/). I try to acquire the IPv6 Ready LOGO on our 
product which is based on NetBSD. And I found the test tool reports NG on Path 
MTU Discovery. After applied above patch, the test tool reports OK.

>How-To-Repeat:
1. Send an ICMPv6 Packet Too Big message with MTU < 1272 to NetBSD.
2. Send an ICMPv6 Echo Request to NetBSD.
3. NetBSD sends invalid ICMPv6 Echo reply.

Or use the test tool from TAHI project. Try following test.
  - Section 4: RFC 1981 - Path MTU Discovery for IPv6
     - No.9 Part A: MTU equal to 56


>Fix:
===================================================================
RCS file: /cvsroot/src/sys/netinet6/icmp6.c,v
retrieving revision 1.152
diff -u -r1.152 icmp6.c
--- icmp6.c     18 Mar 2009 16:00:22 -0000      1.152
+++ icmp6.c     22 May 2009 07:11:37 -0000
@@ -1092,8 +1092,16 @@
                /* is the mtu even sane? */
                if (mtu < sizeof(struct ip6_hdr) + sizeof(struct ip6_frag) + 8)
                        return;
+#if 0
+               /*
+                * This code may violate RFC 1981 section 4.
+                *
+                * We need to care traffic from non-connected pcb.
+                * For example, ECHO Request/Reply don't have connected pcb.
+                */
                if (!validated)
                        return;
+#endif
                mtu = IPV6_MMTU - sizeof(struct ip6_frag);
        }
===================================================================