Ole Troan writes: > > I think it's easy to see the disagreement just comparing the responses > > from Ole and James. > > > > Ole says: > >> I don't see the point of doing address resolution on links without > >> addresses. > > > > James says: > >> IPV6CP (RFC 2472) negotiates > >> only interface identifiers, and not addresses, and ND > >> (2461) says that Neighbor Discovery is supposed to be implemented for > >> point-to-point links, so I'd expect ND to be used on those links. > > I didn't interpret James's reply to mean that his interpretation was to > do address resolution on a link. James can you clarify.
Yes, I expect address resolution to be done on PPP links, just as is described in 2461. I expect it to be done _regardless_ of the underlying link technology. > >> If one implementation sends a NS and > >> expects to see a NA before sending the first message to the neighbors > >> address but the other implementation doesn't use NS/NA messages on the > >> PPP link, there is a problem. > > the other peer should consider that as a NUD exchange. NS/NA messages > must be supported on PPP links too, otherwise how can you do NUD. Indeed. > >> 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.) Neighbor > >> Discovery should be implemented as described in > >> this document. > > > > If this is the behavior we agree on, then I think that answers my > > question. > > agree on PPP links should be treated as multicast links. that doesn't > mean you should require address resolution before sending packets. That text says that "Neighbor Discovery should be implemented as described in this document." I don't see how that's unclear, or how it supports a "may solicit if you feel like it" design. > 2461, 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 PPP links we always know the link-layer address. That seems like a too-strict reading of that text. I think the issue here is that this explanatory text has too much of an Ethernet bias, and could be worded better. I think that this was unintentional, as later on in the same section, it goes on to say: If the solicitation is being sent to a solicited-node multicast address, the sender MUST include its link-layer address (if it has one) as a Source Link-Layer Address option. Otherwise, the sender In what cases don't you have a link layer address, other than point- to-point? As long as this is describing what to do with point-to- point, why read the introduction as ruling out the use of solicitations on PPP links? Instead, the issue is that if the neighbor cache entry doesn't exist or is STALE, then you need to solicit. It's not a matter of just "knowing" (somehow) that the peer doesn't have any link-layer address. Plus, as you point out, unreachability detection falls apart if ND isn't there. And you don't get to see the weird 'R' bit. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
