|To:||Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>|
|Subject:||Re: [RFC/PATCH] "strict" ipv4 reassembly|
|From:||John Heffner <jheffner@xxxxxxx>|
|Date:||Tue, 17 May 2005 21:09:00 -0400|
|Cc:||netdev@xxxxxxxxxxx, Arthur Kepner <akepner@xxxxxxx>, dlstevens@xxxxxxxxxx, rick.jones2@xxxxxx|
|References:||<E1DYBED-0006wa-00@xxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.61.0505171612440.3335@xxxxxxxxxx> <20050517232556.GA26846@xxxxxxxxxxxxxxxxxxx>|
On May 17, 2005, at 7:25 PM, Herbert Xu wrote:
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.
Of course (as usual) NATs break everything. ;-)There are also the ugly case where fragments could be delayed in the network for a period of time, for example during a path change, and show up at exactly the wrong time.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [RFC/PATCH] "strict" ipv4 reassembly, Arthur Kepner|
|Next by Date:||Re: [RFC/PATCH] "strict" ipv4 reassembly, Herbert Xu|
|Previous by Thread:||Re: [RFC/PATCH] "strict" ipv4 reassembly, Herbert Xu|
|Next by Thread:||Re: [RFC/PATCH] "strict" ipv4 reassembly, Rick Jones|
|Indexes:||[Date] [Thread] [Top] [All Lists]|