tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Applying the inet6 ND state engine to inet4



On 12/07/2020 09:57, Roy Marples wrote:
One of the really nice things about INET6 is Neighbour Discovery. Not really the on-wire protocol itself, but the state engine it has. The equivalent in ARP is not quite so nice.
I think it would be a good win to split the ND state engine out of netinet6 and 
into net to make it protocol agnostic (which it already is to some extent thanks 
the the LLE work done prior).
Why is this a good win? Well, the ARP state relies on the net.inet.arp.keep 
timer of 20 minutes where it thinks that once resolved the host *will* be up for 
20 minutes. ND on the other hand sets short timers based on the flow of data so 
we can readily detect hosts becoming unreachable a lot faster.
$ obj.amd64/arp -an
? (10.73.1.2) at 40:8d:5c:f4:71:34 on re0 1s D
? (10.73.1.1) at 04:18:d6:f0:02:cc on re0 2s R
? (10.73.1.230) at (incomplete) on re0 6s I
? (10.73.1.71) at f8:ad:cb:18:5a:88 on re0 23h56m28s S
? (10.73.1.30) at b4:2e:99:e0:33:f4 on re0 28s R
$

Patch here: https://www.netbsd.org/~roy/netbsd-nd.diff

Passing a named union as an argument unusual, but needed because the llentry has an anonymous union we need to pass as an argument.
The ugly ARP output is even uglier - but it supplies the new state data.

Some ARP timer settings have been dropped from sysctl as they no longer make sense. I'm in 2 minds about moving the nd6 ones to a more generic nd and getting ARP to use them as well, or having ones for ARP as well. The current patch is sort of the latter but my mind says the former is probably better. Comments welcome for this.
Whilst going over the code I'm pretty sure that rt_rmx.rmx_expire no longer 
needs to be set as it stands without my work, but that may warrant a little more 
investigation.
I had a few ups and downs getting the psref stuff to work, so extra eyes on that 
would be nice. I think I also plugged an existing hole here we have the ifp of 
the llentry, unlock the llentry and then use the ifp without it being locked in 
any way or form and then passed to the output functions.
Roy


Home | Main Index | Thread Index | Old Index