At Sun, 5 Oct 2008 08:37:34 -0400, "Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote:
> BSD has a bug that it needs to fix. Further, it's debatable that > separation of ND-cache and data forwarding table for a node are not a > protocol-level requirement. RFC4861 clearly describes a Conceptual > Sending Algorithm in section 5.2 - both a host and host portion of an > IPv6 router follow this section. Internally, a node may implement its > s/w architecture and code any way the implementation wants to. But > conceptually, the data forwarding from this section has to be applied. > The section clearly says the following: > > [When sending a packet to a destination, a node uses a combination of > the Destination Cache, the Prefix List, and the Default Router List > to determine the IP address of the appropriate next hop, an operation > known as "next-hop determination".] > > Where does one see ND-cache being used in a data forwarding decision or > what is called as next-hop determination? Hmm...good point. I've not realized for 10+ years that the conceptual sending algorithm doesn't really use the full definition of "on-link" (as defined in Section 2.1 of RFC2461/4861) to "determine whether the packet's destination is on- or off-link." That is, while the definition "on-link" per section 2.1 is as follows: 1. it is covered by one of the link's prefixes (e.g., as indicated by the on-link flag in the Prefix Information option), or 2. a neighboring router specifies the address as the target of a Redirect message, or 3. a Neighbor Advertisement message is received for the (target) address, or 4. any Neighbor Discovery message is received from the address. the conceptual sending algorithm doesn't mention bullets 3 or 4 at all. If the original intent of the spec authors was to ignore these additional conditions in the conceptual sending algorithm, I'll more strongly agree that removing the third and fourth bullets is the right way to go. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
