[Top] [All Lists]

Re: [RFC/PATCH] "strict" ipv4 reassembly

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Nivedita Singhvi <niv@xxxxxxxxxx>
Date: Tue, 17 May 2005 17:06:55 -0700
Cc: Arthur Kepner <akepner@xxxxxxx>, dlstevens@xxxxxxxxxx, rick.jones2@xxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20050517232556.GA26846@xxxxxxxxxxxxxxxxxxx>
References: <E1DYBED-0006wa-00@xxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.61.0505171612440.3335@xxxxxxxxxx> <20050517232556.GA26846@xxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217
Herbert Xu wrote:

Such systems would be violating the spirit of RFC791 which says:

   The identification field is used to distinguish the fragments of one
   datagram from those of another.  The originating protocol module of
   an internet datagram sets the identification field to a value that
   must be unique for that source-destination pair and protocol for the
   time the datagram will be active in the internet system.

Are you aware of any extant systems that do this?

Are you aware of any (new) systems that _don't_ violate this? I wouldn't want to own one of them!

Perhaps you misunderstood what I was saying.  I meant are there any
extant systems that would transmit 1 set of fragments to host A with
id x, then 65535 packets host B, and then wrap around and send a new
set of fragments to host A with idx.

Linux will never do this thanks to inetpeer.c.

Actually, it depends on which Linux you are using.

Mainline linux certainly has this (per-inetpeer ip_id) - but
at least one distro did not (use inetpeer) :). Not sure
what the current situation is.

Of course, if all the traffic is on the same connection
(which isn't out of the ordinary) would still come down
to the same thing...


<Prev in Thread] Current Thread [Next in Thread>