>You seem to forget the fact that the FreeBSD security advisory generally talks about that particular implementation. Anything written there is true, if you read it in the context of the FreeBSD implementation (as >an extreme example, a PC router that runs an unmodified FreeBSD kernel). I believe people normally interpret this document in the correct context and won't be confused.
>You also seem to be trapped in a specific router implementation model where neighbor cache entries and forwarding tables are clearly separated and the latter doesn't affect the former. As far as I understand it, >such a model is not a protocol-level requirement, but just an implementation choice. And, in fact, the FreeBSD kernel (or BSD implementations in general) tightly couples the ARP/ND tables with the forwarding >table, so if a bogus entry is inserted in the former, it will affect forwarding behavior. As mentioned in the first paragraph, a PC router using a vanilla FreeBSD kernel behaves that way. I won't surprised even other >commercial routers that use a customized BSD kernel have the same problem. >--- >JINMEI, Tatuya >Internet Systems Consortium, Inc. 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? Further, in the discussion of the David Miles issue, none of us from IETF in myself, Erik, Thomas, and Wes agreed there is a security issue with the problem David Miles reported. Hemant -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
