Earlier I wrote about an incorrect comparison in vif_encapcheck that
caused multicast routing over vifs to have been broken since May 2001.
(No one has told me that it has worked during this time; if so please
speak up.)

With the comparison fixed (in 2.99.15) Christine Jones of BBN found
another problem.  There is a one-back cache intended to enable quick
checking if the packet is on the same vif as the last multicast vif
packet: last_encap_{src,vif}.  Before the encap4_input registration
changes, ipip_input used the cache to check for the same vif and avoid
a search.  Now, encap4_input runs all the filters, and the filter
can't choose to input the packet on the matching vif.  So, the cache
leads to the wrong behavior, and given the encap4_input structure
doesn't help.

So, I propose to completely rip out the last_encap_* cache.
If there is a performance problem, then registering with specific
addresses so the radix tree is used should be done.   This may mean
that we need to add a way to register both a filter and a function, so
that the inner packet is checked for multicast destination by the
function only if the outer src/dst matches.

Also, I think the outer dst should be checked against the local tunnel
endpoint.  While mrouted may take care to only create a single tunnel
with a peer, a packet arriving with a different local address is
incorrect and shouldn't be treated as on-vif.

I'm going to refrain from committing this change until we have
multicast routing working in our testbed (based on 2.99.15, probably
will merge to current this summer).

-- 
        Greg Troxel <gdt@ir.bbn.com>