fragmentation
Robert L Ullmann <ariel@world.std.com> Wed, 23 March 1994 02:12 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22565; 22 Mar 94 21:12 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22561; 22 Mar 94 21:12 EST
Received: from news.std.com by CNRI.Reston.VA.US id aa21820; 22 Mar 94 21:13 EST
Received: from world.std.com by news.std.com (5.65c/Spike-2.1) id AA20056; Tue, 22 Mar 1994 21:08:41 -0500
Received: by world.std.com (5.65c/Spike-2.0) id AA18786; Tue, 22 Mar 1994 20:56:59 -0500
Errors-To: catnip-request@world.std.com
X-Orig-Sender: catnip-request@world.std.com
Reply-To: catnip@world.std.com
Precedence: bulk
Return-Path: <ariel>
Received: by world.std.com (5.65c/Spike-2.0) id AA18775; Tue, 22 Mar 1994 20:56:58 -0500
Date: Tue, 22 Mar 1994 20:56:58 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Robert L Ullmann <ariel@world.std.com>
Message-Id: <199403230156.AA18775@world.std.com>
To: catnip@world.std.com
Subject: fragmentation
Hi,
I won't say who pointed this out, but someone just told me something
*very* amusing.
RFC791, (everyone has implemented this, right? You know, STD 1 :-) p26
" The Fragment Offset field identifies the fragment
location, relative to the beginning of the original unfragmented
datagram."
Right. Then it goes on to specify a buggy (consider that variable FO
is not initialized :-) algorithm for fragmentation and then reassembly.
Did anyone read the algorithm? It implies that the fragment offset is
relative to TPDU-start ("the data"), which is (as CATNIP says) the way
it *ought* to have been done. Has anyone actually done this? Or have
you followed the text? Do the existing implementations actually
interoperate?
Certainly the TPDU-start-relative method is easier to translate ...
Best Regards,
Robert
- fragmentation Robert L Ullmann