JINMEI Tatuya / 神明達哉 writes:
> At Tue, 17 Jul 2007 16:35:33 -0400,
> James Carlson <[EMAIL PROTECTED]> wrote:
> > 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
I understand the desire, but I don't think the current RFC supports
that behavior. Section 5.2 sets out the basic operation:
Once the IP address of the next-hop node is known, the sender
examines the Neighbor Cache for link-layer information about that
neighbor. If no entry exists, the sender creates one, sets its state
to INCOMPLETE, initiates Address Resolution, and then queues the data
packet pending completion of address resolution. For multicast-
capable interfaces Address Resolution consists of sending a Neighbor
Solicitation message and waiting for a Neighbor Advertisement. When
And, as documented in 2.2, point-to-point links (such as PPP) are
assumed to be multicast-capable:
point-to-point - a link that connects exactly two interfaces. A
point-to-point link is assumed to have multicast
capability and have a link-local address.
The implication is that a trip through INCOMPLETE isn't optional. I
agree that it (at least in theory) could be, but I don't see how the
existing text supports what you're describing.
> - 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)
Sure.
> 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).
Actually, it does. Section 7.2.2 specifies that new entries are
created in INCOMPLETE state.
It might be possible to carve out an exception for point-to-point, but
I don't see one there now. I *think* that you're hanging your
argument on this phrase from section 7.2.2:
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
I believe that this needs to be cleared up. If it really means that
point-to-point links should not send NS and wait for NA, then it
should say so and it should not go on to explain what
"multicast-capable" interfaces (which include point-to-point) links
should do.
> 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
I agree that it seems pointless, but it's what the current text says.
> 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.
It doesn't respond to a valid NS? How is that a viable
implementation.
In this part, I think you're just describing a bug. I don't see
anything in the RFC that supports simply ignoring an NS. (And if you
do that, then how can NUD possibly work?)
> 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.
The part I support is clarifying the document. I don't think I
support changing the functionality described in the document.
--
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
--------------------------------------------------------------------
