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. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
