Ole Troan writes: > > I don't know of any cases where omitting ND for IPv6 addresses makes > > much sense. > > OK, so at least we've clarified that we're in disagreement. I don't see > support in the specs for doing address resolution on links without > link-layer addresses. what would the purpose be in doing address > resolution on a link without link-layer addresses?
Generating NS and processing NA drives the state machine associated with neighbor cache entries. > other ND functions, of course they should be supported. I don't see how you get there at all. You need to be doing solicitations and advertisements in order to do unreachability detection and those "other ND functions," don't you? If you're going to somehow omit ND for address resolution, but use it for everything else, what exactly does that look like on the wire, and what support in the existing RFC is there for this sort of operation? I know what the current RFC suggests -- that is, that we send all of the usual messages based on neighbor cache entry state (just as with broadcast-type networks), but that the SLLA/TLLA option isn't used on any messages because the peers are point-to-point. It's the same protocol -- one option less. What alternative usage are you suggesting? At a guess, the system that would send NS because it lacks a neighbor cache entry instead simply creates the entry and "jumps" straight to REACHABLE state because it already "knows" where the peer is located. Is that it? What other protocol changes are required in order to make ND-for- everything-but-address-resolution mode work? -- 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 --------------------------------------------------------------------
