NetBSD Problem Report #41472

From www@NetBSD.org  Fri May 22 08:24:17 2009
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id B30C863C2C9
	for <gnats-bugs@gnats.netbsd.org>; Fri, 22 May 2009 08:24:17 +0000 (UTC)
Message-Id: <20090522082417.614A363C2C8@www.NetBSD.org>
Date: Fri, 22 May 2009 08:24:17 +0000 (UTC)
From: hsuenaga@iij.ad.jp
Reply-To: hsuenaga@iij.ad.jp
To: gnats-bugs@NetBSD.org
Subject: IPv6 Path MTU Discovery doesn't work in rare case.
X-Send-Pr-Version: www-1.0

>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);
        }
===================================================================

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.