Itojun,

There is no need to change m_pkthdr.rcvif.  The idea behind how I think
it should be implemented would not change this field at all, or if it
did, something would be seriously wrong.  Just because OpenBSD has an
enc0 that breaks IPv6 scoping doesn't mean NetBSD needs to use the same
implentation and come up with a similarly broken result.

You'll notice that in the callout to pfil_run_hooks() that m_pkthdr.rcvif
is passed in as the interface pointer.

The aim here is just to provide an easy way to identify packets that
are coming out of or going into the IPSec crpyto engine.  That's all.
We're not trying to create an enc0 or an equivalent thereof for this
purpose(*).  So all we are required to do is somehow pass information
into the pfil handlers about their status w.r.t IPSec.

I don't know where the relevant places in the IP[Sec] code to make the
changes are, but what I see happening is something like this:

#ifdef PFIL_HOOKS
        /*
         * Run through list of hooks for output packets.
         */
        if ((error = pfil_run_hooks(&inet6_pfil_hook, &m, ENC_IFP(ifp), PFIL_OUT)) != 0)
                goto done;
        if (m == NULL)
                goto done;
        ip6 = mtod(m, struct ip6_hdr *);
#endif /* PFIL_HOOKS */

What is ENC_IFP() ?  It _might_ be something like this:

#define	 ENC_IFP(x)     &(x)->if_encifp

Where if_encifp is part of 'struct ifnet' like this:

#ifdef IPSEC
        struct ifnet if_encifp;     /* interface used for identifying ipsec
                                     * packets for packet filtering. */
#endif

This "virtual" interface should not appear in "ifconfig" output and
it should not be used for enquing data onto of off of - the if_output,
if_input, etc, functions for these virtual interfaces should all return
errors or be null pointers or whatever is appropriate to indicate "do
not use me to do real work."  So far as what's required for ipfilter to
work properly, it's name is important - and that might be all - and
being able to resolve the name to a pointer.

To support this, I believe only the function ifunit() would need to be
changed so it understood the prefix or suffix used with the interface
name, but that's just a SMOP.

So, in summary, there's absolutely no reason that I can see for why
scoping should be impacted by allowing filter rules of the form:

block in on ipsec_ex0 from any to any port = 25


* NOW, the other side of this is it might be nice to use tcpdump or
similar tools on ipsec_ex0.  If this was felt strongly enough then
I'd hope that the solution deployed for the solution of the packet
filtering problem could be also applied to interfacing with bpf in
some fashion.

Darren