(KAME-snap 8847) MUT of stf (Re: Weird memory exhaustion with FreeBSD 4.10-STABLE)

[Pekka Savola]

On Wed, 20 Oct 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L at C#:H(B wrote:
> Forgot to respond to this point:
> 
> >>>>> On Wed, 29 Sep 2004 10:59:32 +0300 (EEST), 
> >>>>> Pekka Savola <pekkas at 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