translating fragments
Robert L Ullmann <ariel@world.std.com> Wed, 09 February 1994 01:44 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25310; 8 Feb 94 20:44 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25306; 8 Feb 94 20:44 EST
Received: from news.std.com by CNRI.Reston.VA.US id aa23726; 8 Feb 94 20:44 EST
Received: from world.std.com by news.std.com (5.65c/Spike-2.1) id AA00828; Tue, 8 Feb 1994 20:37:15 -0500
Received: by world.std.com (5.65c/Spike-2.0) id AA00469; Tue, 8 Feb 1994 20:25:09 -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 AA00457; Tue, 8 Feb 1994 20:25:07 -0500
Date: Tue, 08 Feb 1994 20:25:07 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Robert L Ullmann <ariel@world.std.com>
Message-Id: <199402090125.AA00457@world.std.com>
To: catnip@world.std.com
Subject: translating fragments
Greg, It is very good to get detailed comments; thank you. I have a number of related comments, but carrying on an exchange re multiple points is difficult, so I'll pick one to start with, and bring the others back up as I do the close review of the doc with your comments. ---- Translating fragments/segments without reassembling them would be really nice; IPv7 suggested that at one point, butin the process of doing trial implementation, I found a "little" problem: just how do you figure out the offset in the resulting datagram? Note that IPv4 and CLNP have this not-quite-stated assumption that the recving host doing reassembly gets the "offset 0" fragment/segment with a N-layer header that is THE SAME SIZE as the header was when the datagram was fragmented by some router (or router*S*!) THis assumed axiom doesn't hold in the presence of different network headers. I don't know how to solve this so as to allow translating fragments; I'd love to have someone find something I've missed. Note that it doesn't even hold for all-native-CATNIP, since the IPv4/CLNP axiom doesn't apply; CATNIP forwarders can and will change the header size when it pays to do so. The offset (IMHO) should have been defined as offset from the TPDU start; an open issue is whether CATNIP-native should do this (I think it should) but since IPv4/CLNP define it as NDPU-start relative, the translation problem still exists. Ideas anyone? Rob
- translating fragments Robert L Ullmann