T_X's Junkyard - Proposal: Unicasting Unsolicited Neighbor Advertisements¶

Update 2. June 2016: Another look at various Freifunk communities seems to indicate that the number of unsolicited neighbor advertisements is currently rather low. It seems that at least Linux'es (including Androids) do not send unsolicited neighbor advertisements upon roaming.

Scenario¶

In a layer 2 mesh network, a lot of broadcast "noise" consists of so called Unsolicited Neighbor Advertisements. It is the main ICMPv6 packet overhead in a mesh network with devices dynamically joining, leaving and roaming.

A device roaming from one node to another – and after that flooding Neighbor Advertisements

Just like regular, solicited neighbor advertisements, the purpose of this message is to inform other nodes about the MAC address belonging to the IPv6 address of the sender. The difference between unsolicited and solicited messages is that the former may even be sent if no one asked for it.

Goals¶

• Reducing broadcast overhead
• Eliminating last, mandatory ICMPv6 overhead
  ➔ no more flooding for IPv6 communication needed
• Enhancing reliability of arrival of unsol. NAs and therefore roaming

Purpose of Unsolicited Neighbor Advertisements¶

Sending unsolicited additionally to solicited Neighbor Advertisements has two purposes:

Device Hot-swapping¶

When the IPv6 stack notices, that the link-layer address below one of its IPv6 addresses has changed, then Unsolicited Neighbor Advertisements may be sent. The advantage of this is that a neighbor will not need to wait for the now outdated link-layer address in its neighbor table to time out.

Updating Switches after Roaming¶

Secondly, Unsolicited Neighbor Advertisements are needed to update the MAC table in a switch promptly, to avoid potential packet loss after a host roamed.

Without unsol. NAs: The switch will not forward data from B to A via the mesh – data is lost!

Overhead Concerns regarding Unsol. NAs¶

Unfortunately, Unsolicited Neighbor Advertisements are sent to the all-hosts multicast address (ff02::1). This means that everytime a host is roaming in the mesh network, it creates an Unsolicited Neighbor Advertisement which is flooded through the whole mesh. Since all hosts are addressed, the Multicast Optimization adding group-awareness is not having any effect. With many mobile devices, the overhead is significant.

Solution: Unicasting Unsol. NAs to Previous Node¶

Fortunately, there is just one segment of the mesh where switches need to be updated: Any switch behind the node where the host roamed from.

A unicasted unsol. NA updating the MAC table of the switch

For all the other batman-adv nodes potentially having switches, nothing has changed for these switches even after the roaming: For them, host A is still somewhere in the mesh and therefore still behind the same switch port leading to the mesh.

IPv4 Pendant: Gratuitous ARP Reply¶

For IPv4 a similar mechanism exists: Gratuitous ARP Replies are sent without having received any ARP Request beforehand. In the wild, implementations of this mechanism are a lot less common compared to ICMPv6 Unsolicited Neighbor Advertisements. Nevertheless they should be treated just like unsol. NAs and can be forwarded via unicast, too.

Limitations¶

• Device hot-swapping with up to a few minutes delay
  (later, the arrival of IPv6 Neighbor Solicitations could be memorized, to know which other hosts might be interested in unsol. NAs after hot-swapping)