Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Nov 2006 17:09:20 +0100
From:      Max Laier <max@love2party.net>
To:        freebsd-hackers@freebsd.org
Cc:        freebsd-net@freebsd.org
Subject:   ipv6 connection hash function wanted ...
Message-ID:  <200611141709.26644.max@love2party.net>

next in thread | raw e-mail | index | archive | help
--nextPart1529959.aSOhg96bU6
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

this one is something for people who know their math.

Input: 2x128bit of address (lower ~80bit selectable by user) and 2x16bit=20
of ports (more or less selectable by user).  Note that the "flow_id" is=20
not useable as several broken stack implementations do not set it=20
consistently - and it is user settable as well.
Output: "int" hash value - by default we use the lower 8bit of it.

Problems: Most of the input can be selected by a user meaning it is easy=20
to produce collisions.  For legal connections, the lower 64bit are the=20
one with the highest entropy - in fact the upper 64bit might be the same=20
for many connections coming from/going to the same subnet.  This function=20
will be used for every packet that is passed to a dynamic IPFW rule, so=20
efficiency is a concern.

Any ideas?  Any papers that deal with this problem?

ref: sys/netinet/ip_fw2.c::hash_packet6

=2D-=20
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News

--nextPart1529959.aSOhg96bU6
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQBFWeo2XyyEoT62BG0RAv5YAJ99W3lFucWxtqwM2DffEMRd9B3DIgCdG5Nh
0cHxQBrsibVS6R+saGqA0mY=
=l4Hy
-----END PGP SIGNATURE-----

--nextPart1529959.aSOhg96bU6--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611141709.26644.max>