Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Oct 2004 07:41:46 +0300 (EEST)
From:      Pekka Savola <pekkas@netcore.fi>
To:        snap-users@kame.net
Cc:        freebsd-net@freebsd.org
Subject:   Re: (KAME-snap 8847) MUT of stf (Re: Weird memory exhaustion with FreeBSD  4.10-STABLE)
Message-ID:  <Pine.LNX.4.44.0410200732320.1633-100000@netcore.fi>
In-Reply-To: <y7vd5zenpzq.wl@ocean.jinmei.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <pekkas@netcore.fi> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.44.0410200732320.1633-100000>