[Top] [All Lists]

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

To: Rick Jones <rick.jones2@xxxxxx>
Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Andi Kleen <ak@xxxxxx>
Date: Tue, 17 May 2005 21:53:08 +0200
Cc: netdev@xxxxxxxxxxx
In-reply-to: <428A470A.6010703@xxxxxx> (Rick Jones's message of "Tue, 17 May 2005 12:33:30 -0700")
References: <Pine.LNX.4.61.0505170914130.29021@xxxxxxxxxx> <20050517.104947.112621738.davem@xxxxxxxxxxxxx> <m1zmut7l5q.fsf@xxxxxx> <428A3F86.1020000@xxxxxxxxxx> <428A425F.7000807@xxxxxx> <428A452B.2010008@xxxxxxxxxx> <428A470A.6010703@xxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux)
Rick Jones <rick.jones2@xxxxxx> writes:

>> Actually, the problem is much worse now - we have virtual
>> partitions in the Xen environment for instance where some
>> packets are headed for local consumption (virtual network,
>> no actual network latency to speak of) and some going
>> out to the network. Having a global IP id generator just
>> won't be able to keep up - we could wrap in submilliseconds...
> and the classic TCP sequence number isn't _really_ all that far behind :)

But it has PAWS at least. But I agree even IPv6 fragmentation
with 32bit IDs is not significantly safer.


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