On 18 November 2014 15:30, Martin Pieuchot <mpieuc...@nolizard.org> wrote: > On 13/11/14(Thu) 16:41, Stuart Henderson wrote: >> This changes behaviour of ping6 ff02::1%pppoe0 for me, previously I saw >> a response to each icmp message in the sequence, now I just see the >> first response. I am not using "set skip" on that machine. >> >> $ ping6 ff02::1%pppoe0 >> PING6(56=40+8+8 bytes) fe80::225:90ff:fec0:77b4%pppoe0 --> ff02::1%pppoe0 >> 16 bytes from fe80:15::225:90ff:fec0:77b4, icmp_seq=0 hlim=64 time=0.271 ms >> ^C >> --- ff02::1%pppoe0 ping6 statistics --- >> 6 packets transmitted, 1 packets received, 83.3% packet loss >> round-trip min/avg/max/std-dev = 0.271/0.271/0.271/0.000 ms > > Thanks for spotting this Stuart, diff below fixes this issue. > > It was another funky situation to debug. Problem was that 2 new states > were created on loopback for the echo reply instead of matching the > corresponding echo request states. But according to mikeb@ new states > should never be created for replies. > > So the diff below changes the icmp multicast check in pf to take into > consideration the scope of the sender, and in a more general way no > longer clear the scopes of addresses for packets sent through loopback > when calling pf_test(). >
To put it into the perspective: firewall policy wise we want to differentiate between traffic on one interface and traffic on the other interface. Since you can have exactly the same IPv6 link-local addresses on two interfaces that only differ in scope IDs we want to make sure that state matching code treats packets outgoing on these two interfaces as subjects to different policy restrictions and therefore can't match the same state. With this patch we ensure that IPv6 input and output routines provide scoped addresses to the pf and pf uses them to create states. Needless to say I'm OK with both diffs.
