Robert L Ullmann <> Wed, 23 March 1994 02:12 UTC

Received: from 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 by CNRI.Reston.VA.US id aa21820; 22 Mar 94 21:13 EST
Received: from by (5.65c/Spike-2.1) id AA20056; Tue, 22 Mar 1994 21:08:41 -0500
Received: by (5.65c/Spike-2.0) id AA18786; Tue, 22 Mar 1994 20:56:59 -0500
Precedence: bulk
Return-Path: <ariel>
Received: by (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 <>
Message-Id: <>
Subject: fragmentation


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

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

Certainly the TPDU-start-relative method is easier to translate ...

Best Regards,