Subject: [Efficientnd-dt] NS/NA address resolution - some thoughts

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Mar 2014 11:37:41 -0700

Seems like there are several potential origins of multicast NA and/or NS.
The ones that come to mind are:

1. Initial address resolution
1a. host->router
1b. router->host
1c. host->host

1a shouldn't happen if the RA contains the SLLAO
1b shouldn't happen if the RS contains the SLLAO
1c. why do hosts on the IETF link talk to each other?
Could this host-to-host be triggered by Bonjour finding e.g. a file 
server causing it to unicast to find out more about the server?

We can remove 1c using L=0, but that in itself wasn't a big chunk in 
Eric's piechart.

2. Unsolicited NA to all-nodes
Why do we see those on the link? Do implementations send each time the 
link/interface comes up?

3. Discarding NCEs (on hosts or routers) causing redoing multicast 
address resolution
Is this due to NUD timing things out after 3 seconds of unreachable? Due 
to LRU/garbage collection?

We can potentially address #3 using higher ReachableTime (if there is 
only one router in the default router list) or by hosts and/or routers 
implementing impatient-nud (RFC 7048); either will reduce the 
probability of discarding a entry just because the target was 
unreachable for a few seconds.

4. Router loosing state (e.g., reboot or VRRP failover) causes a flood 
of 1b NSs

Seems like we need more analysis of the traffic and implementations to 
determine the causes so we can think about useful remedies.

     Erik