Re: SMB's proposal: using an IP option for "Report Fragmentation" flag

Philippe Prindeville <> Tue, 28 November 1989 15:10 UTC

Received: from by (5.54.5/4.7.34) id AA13062; Tue, 28 Nov 89 07:10:43 PST
Received: by; id AA17250; Tue, 28 Nov 89 07:10:26 -0800
Received: from by (5.61+/89.0.8) via Fnet-EUnet id AA18677; Tue, 28 Nov 89 16:09:51 +0100 (MET)
Received: by; Tue, 28 Nov 89 16:10:13 -0100 (MET)
Date: Tue, 28 Nov 89 16:10:13 -0100
From: Philippe Prindeville <>
Message-Id: <>
Phone: +33 1 30 60 75 25 / +33 1 47 34 42 74
To: mogul
Subject: Re: SMB's proposal: using an IP option for "Report Fragmentation" flag
Cc: MTU Discovery <mtudwg>

	Steve B's proposal (introduce a new "flag" IP Option that means "Report
	Fragmentation") has several nice advantages.  First, it doesn't appear
	to require any changes to existing gateway implementations (which are
	all required to pass along unknown options, subject to the usual
	orthogonal rules about copying on fragmentation).  Second, it doesn't
	intrude on any "architecture resource" scarcities (i.e., bits in the IP

This may sound a little heretical, but perhaps we are considering
fragmentation "Not Harmful Enough"?  Maybe fragmentation really
should be looked upon as something quite severe and that *any*
fragmentation should be reported via an ICMP message back to the
source.  This way, no options or header bits are used.  We would
have to allocate a new ICMP message type, though: reason being it
must be something that hosts not yet equiped with this MTU discovery
code can safely ignore (albiet at the cost of much degraded
performance -- if the performance is bad enough, perhaps the users
will bang on the management to upgrade to a more reasonable release).
Anyway, just using Fragmentation Required But Not Permitted (or
whatever, I don't have 791 handy) with a different Code would not
be adequate.