| 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. -Andi |
| Previous by Date: | Re: [RFC/PATCH] "strict" ipv4 reassembly, Nivedita Singhvi |
|---|---|
| Next by Date: | Re: [RFC/PATCH] "strict" ipv4 reassembly, David Stevens |
| Previous by Thread: | Re: [RFC/PATCH] "strict" ipv4 reassembly, Rick Jones |
| Next by Thread: | Re: [RFC/PATCH] "strict" ipv4 reassembly, Herbert Xu |
| Indexes: | [Date] [Thread] [Top] [All Lists] |