From owner-freebsd-net@FreeBSD.ORG  Mon Sep 27 20:28:01 2004
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id E323916A4D0
	for <freebsd-net@freebsd.org>; Mon, 27 Sep 2004 20:28:01 +0000 (GMT)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp
	[202.249.10.124])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 263C943D31
	for <freebsd-net@freebsd.org>; Mon, 27 Sep 2004 20:28:01 +0000 (GMT)
	(envelope-from jinmei@isl.rdc.toshiba.co.jp)
Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4])
	by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
	id 943ED1525D; Tue, 28 Sep 2004 05:27:58 +0900 (JST)
Date: Tue, 28 Sep 2004 05:27:57 +0900
Message-ID: <y7v8yavsbhu.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
To: snap-users@kame.net
In-Reply-To: <Pine.LNX.4.44.0409270747480.27601-100000@netcore.fi>
References: <y7vbrfs6c9f.wl@ocean.jinmei.org>
	 <Pine.LNX.4.44.0409270747480.27601-100000@netcore.fi>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0
	(SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
cc: freebsd-net@freebsd.org
Subject: Re: (KAME-snap 8803) Re: Weird memory exhaustion with FreeBSD
	4.10-STABLE
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Sep 2004 20:28:02 -0000

>>>>> On Mon, 27 Sep 2004 07:57:02 +0300 (EEST), 
>>>>> Pekka Savola <pekkas@netcore.fi> said:

>> I can think of several possibilities that may cause the entries:
>> 
>> - when this node sends ICMPv6 error messages to those addresses, it
>> can create route entries.  I suspect this is the main reason since
>> in this case the destination of route entries would contain other
>> types of addresses than 6to4.  You can (implicitly) check if this
>> happened by looking at the result of 'netstat -s -p icmp6'

> This is likely the case.  Due to Microsoft's implementation of '6to4 
> relay probing', each host tries to send an IPv6 packet of Hop Count=1, 
> which results in an ICMP unreachable back from the relays.  See below.

Okay.  Now I think I figure out the problem.  Those host routes were
created not deliberately, so the kernel will eventually need a fix to
this.

But if you are in a hurry and/or cannot replace the kernel soon, I
think setting net.inet6.ip6.rtexpire to 0 can be a workaround (with
this you even do not have to reboot the kernel - though rebooting may
also help if you can).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp