Re: blacklistd and IPv6 mapped IPv4 addresses

[Taylor R Campbell <campbell+netbsd-tech-net%mumble.net@localhost>]

   Date: Fri, 22 Jan 2016 17:18:35 -0500
   From: christos%zoulas.com@localhost (Christos Zoulas)

   What should blacklistd do? Recognize the mapped v4 addresses and convert
   them to real v4 addresses and send those to the packet filter? Is that
   guaranteed to work across different OS's? Or send both the v4 and mapped
   v6 variants to the packet filter?

   Or is it the responsibility of the packet filter to know that this is
   a mapped v4 address and DTRT?

Certainly it should not be the application's responsibility, at least,
to conditionally handle v4-mapped addresses specially -- they should
just send on exactly what the system sent them as easily as possible.
Any other responsibility for the application is likely to be an
error-prone burden.

I expect it to be easy and low-cost to teach blacklistd to recognize
AF_INET6 with a v4-mapped address, and to tell the packet filter to
block AF_INET packets with the enclosed address.

It may be more trouble to teach the packet filter, or the compiler for
the packet filter in the case of npfctl, to do that itself.  The
run-time cost of doing this for rules that are statically written with
AF_INET6 and v4-mapped addresses is likely negligible -- there is no
cost if you don't try to write such rules.  But I can imagine an
operator naively expecting

block in final proto tcp from ::ffff:1.2.3.4/128 to any port 21

to generalize to

block in final proto tcp from mytable to any port 21

Making that generalization to work seems likely to me to incur a
nontrivial run-time cost.  Not to mention that as stated, this rule
doesn't match what will be found in any packet on the wire -- the
kernel already rejects all v4-mapped addresses coming in on the wire
(although only after the packet filter has had a chance to run).