I started to do some of the hacks on faith(4) that I mentioned a while
ago, and it looks to me as though it's rather fundamentally broken,
even as an implementation of its intent, even in -current.

If keepfaith is set, ip6_input correctly sets deliverifp to the faith
interface in question.  But then it proceeds to completely ignore
deliverifp, except for some statistics-gathering calls!

The reason faith appears to work anyway, in that there are people known
to be running faith gateways, is that the "faith" argument to
in6_pcblookup_{connect,bind} does almost nothing: if it is incorrectly
0 instead of 1 (which I think is happening all the time), all that can
go wrong is that an incoming faith packet may be matched by a
non-IPV6_FAITH socket.  I conjecture that it's just a case of nobody
having run into this yet; it looks as though it may not work to bind
wildcard-address faith sockets and wildcard-address non-faith sockets
on the same port, which would make it harder to notice.  (This is
presumably why faithd has an option to fork local daemons, rather than
just having faithd handle faith traffic and non-faith daemons handle
other traffic, which if the test in in6_pcblookup_* worked would be the
right way to do it, and as long as the faith socket is earlier in the
list (bound later) I think it will work.  I prefer to make it
impossible for faith sockets to catch non-faith traffic, so there's no
collision possible.)

It seems to me that before upcalling through pr_input, about four lines
from the end of ip6_input, m->m_pkthdr.rcvif should be set to
deliverifp.  Am I hallucinating, or is this really a bug?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B