On Wed, 20 Oct 2004, JINMEI Tatuya / [ISO-2022-JP] [EMAIL PROTECTED]@C#:H wrote: > Forgot to respond to this point: > > >>>>> On Wed, 29 Sep 2004 10:59:32 +0300 (EEST), > >>>>> Pekka Savola <[EMAIL PROTECTED]> 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 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
