NPF issue with inet6($if) vs. ifaddrs($if)

[Anthony Mallet <anthony.mallet%laas.fr@localhost>]

Hi,

With -current from Sep 24 (9.99.100), I'm seeing packets passing
through NPF via a ~relatively unrelated 'pass' rule when the rule uses
inet6($iface). If the rules uses ifaddrs($iface) the issue
disappears. (of course, the $iface is as statically configured as it
can be and does not change or gain or loose any ip addresses in the
meantime).

Follows a tentative demonstration of the symptom, (with IPs addresses
a bit obfuscated manually or replaced by $variable). For the
demonstration, I'm sending a NTP packet from $remote host to $local
host with `ntpdate -q $local`, with npf running on the gateway
$gateway in between the two hosts ($remote -> $gateway -> $local), via
IPv6 passing through a gif(4) tunnel (in case it matters) on the
$gateway.

All the relevant NPF rules are in the default group.

On the $gateway:
# cat npf.conf | grep "relevant content"
  $ifgw = external re0 interface with public IPv6 == $gateway
  pass stateful in final proto udp to inet6($ifgw) port 123 apply "log"

# npfctl show | grep "relevant content"
  pass stateful in final family inet6 proto udp to { fe80:1::xxx%re0, $gateway } port 123 apply "log" # id="23"

# tcpdump -ne -i npflog0 host $remote # note the 'pass' below
20:26:12.752953 rule 35.rules.0/0(match): pass in on gif0: $remote.57144 > $local.123: NTPv4, Client, length 48

Of course $local != $gateway and $ifgw has only one IPv6 ==
$gateway. But still, the rule 35 (0x23) let the packet pass through??

If now I just replace inet6($ifgw) by ifaddrs($ifgw) (leaving the rest
of npf.conf unchanged), this works as intended:

# cat npf.conf | grep "relevant content"
  pass stateful in final proto udp to ifaddrs($ifgw) port 123 apply "log"

# npfctl show | grep "relevant content"
  pass stateful in final proto udp to ifaddrs(re0) port 123 apply "log" # id="23"

# tcpdump -ne -i npflog0 host $remote
21:05:43.390213 rule 39.rules.0/0(match): block in on gif0: $remote.36391 > $local.123: NTPv4, Client, length 48

Rule 39 is a 'block final all' rule rejecting the traffic as expected.

Did I miss something obvious? Is it the sign of some weird bug?
A quick dive into NPF code was not enough for me to get a grasp on where
to start looking ... if I should start looking for something at all.

Any hint appreciated :)

Anthony