From owner-freebsd-net@FreeBSD.ORG Sat Jul 3 07:39:00 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C46DA16A4CE for ; Sat, 3 Jul 2004 07:39:00 +0000 (GMT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 104BC43D53 for ; Sat, 3 Jul 2004 07:39:00 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 17873 invoked from network); 3 Jul 2004 07:38:58 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 3 Jul 2004 07:38:58 -0000 Message-ID: <40E66292.95598473@freebsd.org> Date: Sat, 03 Jul 2004 09:38:58 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack References: <200406291413.ab33924@salmon.maths.tcd.ie> <20040702190516.Q65076@odysseus.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: David Malone cc: freebsd-net@freebsd.org Subject: Re: RANDOM_IP_ID sysctl? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2004 07:39:00 -0000 Mike Silbersack wrote: > > On Tue, 29 Jun 2004, David Malone wrote: > > > It seems to me that RANDOM_IP_ID might be better as a sysctl rather > > than a kernel option. Would anyone mind if I changed this? > > > > David. > > I'd rather see a sysctl that switched between incremental frag IDs and > arc4random() based IDs, followed by the removal of RANDOM_IP_ID. > > For more info, see: > > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/ip_id.c > > (I think we're still using the old code that's collision prone.) > > Given that we're in a 16-bit space anyway, it's simpler to just use > arc4random and stop pretending that we can avoid collisions. > > Remember: An IP ID collision is equivalent to a packet being lost; this > is not a big deal. An ip_id collision is only a problem (packet loss) if it is being fragmented along the way and the delivery of the fragments happens out-of-order, so that a fragment from a different packet gets re- assembled with part of an earlier one. Having many concurrent connections to the same remote end-point with fragmentation in between is of course making the chances bigger to hit this. -- Andre