Dave Thaler 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.
If you've actually got links with no addresses at all, then I agree. That seems odd, though, given the usual automatic assignment of at least link-locals. > > 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. > > We have now observed the problem Markus predicted, with real > implementations. > That is, I know of two non-interoperable implementations of RFC 2472. Sigh. > I think James' argument does have real substance. The quote from 2461 > section 3.2 is (especially the last sentence): > > > 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. Changing that 'should' to a 'MUST' may fix the problem with the document. As for implementations, I'd expect the implementor to have a really good explanation of why he ignored fairly clear (if not capitalized) 'should' advice like that, if it was in fact done on purpose. If it's just a bug, then it's a bug, and might not need to be immortalized. My reading of that text is that if the peers have prior agreement that they're not going to do ND, and if the designer or user of the system has a Very Good Reason to believe that omitting ND is desirable, then it's possible to do. Otherwise, as with any recommendation, you 'should' do what it says, and use ND as usual. I don't know of any cases where omitting ND for IPv6 addresses makes much sense. -- 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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
