Subject: Question about ND for p2p links

From: Philip Homburg <[email-masked]>
Date: Fri, 19 Mar 2010 14:42:43 +0100

I've a question about ND for p2p links, especially tunnels as defined
in RFC-4213.

I noticed some time ago that my tunnel did something weird w.r.t. neighbor
discovery, but I didn't have the time to investigate, and just disabled ND.
Recently, did look at what was going on and what happened is that my
implementation tries to multicast a NS and the other side seems to ignore it.

RFC-4861 (Neighbor Discovery) says:
"3.2.  Supported Link Types
"[...]
"point-to-point -
"	Neighbor Discovery handles such links just like multicast
"	links.  (Multicast can be trivially provided on point-to-point
"	links, and interfaces can be assigned link-local addresses.)

"
"7.2.2.  Sending Neighbor Solicitations
"
"   When a node has a unicast packet to send to a neighbor, but does
"   not know the neighbor's link-layer address, it performs address
"   resolution.  For multicast-capable interfaces, this entails
"   creating a Neighbor Cache entry in the INCOMPLETE state and
"   transmitting a Neighbor Solicitation message targeted at the
"   neighbor.  The solicitation is sent to the solicited-node
"   multicast address corresponding to the target address.

Based on this and a desire to avoid special cases, my code tries to multicast
NS message when in INCOMPLETE even on point-to-point links. Is this correct
behavior?

However, thinking about this a bit more, and especially in the context of 
RFC-3056 (Connection of IPv6 Domains via IPv4 Clouds) it may be better to
use unicast for any link that doesn't have link layer addresses as far ND is
concert even in INCOMPLETE state.

Maybe something for a future revision or the host requirements RFC.