At Tue, 17 Jul 2007 16:35:33 -0400,
James Carlson <[EMAIL PROTECTED]> wrote:
> 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?
What the BSD (KAME) implementation does is as follows:
- when it first sends a packet to the other end of a point-to-point
(including PPP) link it creates a placeholder of a neighbor cache
with the state of STALE
- the packet is sent to the p2p link immediately since there is no
need to perform address resolution
- eventually the state of the neighbor cache entry is changed to PROBE
and NUD is performed
(this description is a bit simplified to concentrate on the main point
of this discussion)
I believe this is a reasonable behavior, although as far as I know the
protocol specification does not specify this level of details
(e.g. what should be the initial state of such a cache entry).
In any case, it's totally pointless for an implementation to hold the
packet during an exchange of NS/NA for address resolution (which
itself is meaningless) on such a link. Furthermore, if the
implementation doesn't send the held packet unless it gets an NA in
response to NS, it may cause an interoperability problem depending on
the behavior of the other end. I guess that's the issue Dave
originally tried to indicate. I don't know of an implementation that
performs the meaningless NS/NA for address resolution on a p2p link,
but I know an implementation that doesn't respond to an NS (whether
it's for address resolution or for NUD) on a p2p link, so I won't be
surprised if the problem actually happens.
As far as I can see the current specification is pretty clear to
prevent such a pointless behavior, but if there is an implementation
that behaves that way (Dave's message seems to indicate there is) it
may make sense to write a short I-D that clarifies this point. In
this case I believe it should be a generic note on point-to-point link
that doesn't have the notion of L2 address (and thus doesn't require
L2 address resolution) rather than a part of a document for a specific
link type such as ipv6-over-ppp-v2.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
