Proposed patch for Port Randomization modifications according to RFC6056

[Bjoern A. Zeeb]

On Sun, 27 Feb 2011, Doug Barton wrote:

> On 02/27/2011 12:23, Fernando Gont wrote:
>> On 08/02/2011 03:47 p.m., Doug Barton wrote:
>> 
>> [catching up with e-mail]
>> 
>>> I've been up and running on this patch vs. r218391 for over 24 hours
>>> now, using algorithm 4 (as someone said is now the default in Linux)
>>> without any problems.
>>> 
>>> I think Bjoern is better qualified than I to comment on the style of the
>>> patch, but it applies cleanly, and seems to run fine on both v4 and v6.
>> 
>> Has this been commited to the tree, already? -- If so, what's the
>> default algorithm?
>
> Bjoern was planning to do it, I'm going to do it if he doesn't get around to 
> it.
>
> As for default algorithm, is there any reason not to make it 4?

Yes, it's expensive both computation time and stack wise.  Last I put
MD5ctxs on the stack I was told that it was previously avoided do to
stack limits.  I haven't seen complaints on lists about it but it
possibly still true for small embedded.

I'd also like to see a proper benchmark before switching the default
on both state of the art and a soekris kind class of machine.

That said I messed with the patch to avoid the two copies of the
algorithms (so it will not be 4 soon).  I know it compiles but I have
yet to test it.  I'd love to hear opinions.  The #ifdef INET6/INETs
are ugly but we'll see those a lot more and need to figure out
differnt ways to our code was written the last 10 years.

http://people.freebsd.org/~bz/20110303-01-rfc6056.diff

The patch also includes a bugfix for the ipv6 case wrt to
"un-binding" on error.

/bz

-- 
Bjoern A. Zeeb                                 You have to have visions!
          Stop bit received. Insert coin for new address family.