From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 04:42:04 2004 Return-Path: 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 D9FD616A4CE for ; Wed, 20 Oct 2004 04:42:04 +0000 (GMT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEF9E43D2F for ; Wed, 20 Oct 2004 04:42:03 +0000 (GMT) (envelope-from pekkas@netcore.fi) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9K4fkx02007; Wed, 20 Oct 2004 07:41:46 +0300 Date: Wed, 20 Oct 2004 07:41:46 +0300 (EEST) From: Pekka Savola To: snap-users@kame.net In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 cc: freebsd-net@freebsd.org Subject: Re: (KAME-snap 8847) MUT of stf (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 04:42:05 -0000 On Wed, 20 Oct 2004, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote: > Forgot to respond to this point: > > >>>>> On Wed, 29 Sep 2004 10:59:32 +0300 (EEST), > >>>>> Pekka Savola said: > > > Speaking of 6to4, if_stf.c does not support setting the MTU, because > > there's no ioctl handler for it. It wouldn't IMHO hurt to be able to > > raise it from the glued-in default of 1280.. > > According to itojun (the principal author of the stf driver), it's on > purpose. He said the reason for the restriction is because stf > normally had multiple (anonymous) destinations and we couldn't > pre-negotiate the size of the receiving buffer at the other ends. I'm not sure if I see the argument. Are you assuming that some destinations might not have a 1500-byte receive buffer? That would seem to be .. a rather cautious assumption. I recall IPv6 specs already require being able to receive a packet of 1500 bytes.. (Due to this, e.g., draft-ietf-v6ops-mech-v2 now also requires at least 1500 byte reasm/receive buffer.) AFAIK, A bigger potential issue comes from how the implementation plays with PMTUD, e.g., does it set the DF-bit on the IPv4 header of the tunnelened packets or not. If it does, the code would need to reflect back v4 ICMP packet too big errors as ICMPv6 errors, and I believe KAME doesn't do that. I fully agree that setting MTU of the stf interface to a high value would be bad, but especially on relays, something higher than 1280 (e.g., 1480) would probably make a lot of sense. > (No further questions on this to me, please:-) Hey, we're on public mailing lists, so itojun can respond if he feels like it :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings