kern/47001: pf + IPv6 forwarding broken

[t.e.spanjaard%gmail.com@localhost]

>Number:         47001
>Category:       kern
>Synopsis:       pf + IPv6 forwarding broken
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Sep 26 19:25:00 +0000 2012
>Originator:     T.E. Spanjaard
>Release:        6.0_POST_RC1
>Organization:
>Environment:
NetBSD irminsul.deepslack.eu 6.0_POST_RC1 NetBSD 6.0_POST_RC1 (IRMINSUL) #0: 
Thu Sep  6 20:12:49 UTC 2012  
root%leo.ssr.netphreax.net@localhost:/usr/obj/sys/arch/amd64/compile/IRMINSUL 
amd64
>Description:
Using pf(4) on a host which is configured as a gateway/router, forwarding of 
IPv6 traffic is broken because pf(4) is not tracking states properly. For 
traffic originating/targeting the gateway itself, all packets of a TCP 
handshake are seen by pf(4), allowing it to establish state for a TCP 
connection. However, when the session is between two hosts, one remote, the 
other internal, it never sees the SYNACK, so it drops the state because it 
never progresses beyond SYN_SENT on one end, as far as pf(4) is concerned.

Example: SSH session between 2001:838:32c:2::c and 
2a02:2770::21a:4aff:fed3:e6ac:

state according to pf(4):
all tcp 2001:838:32c:2::c[25820] -> 2a02:2770::21a:4aff:fed3:e6ac[22]       
ESTABLISHED:SYN_SENT

state on internal host:
tcp6       0      0 2001:838:32c:2::.25820 2a02:2770::21a:4.22    ESTABLISHED

state on remote host:
tcp6       0      0 2a02:2770::21a:4.22    2001:838:32c:2::.25820 ESTABLISHED

Looking on pflog0, I see no blocked packets, except after when pf(4) tears the 
ESTABLISHED:SYN_SENT state down and the block rule applies.

If a default rule of 'pass' is used, traffic beyond the first max_tcp_winsize 
bytes starts to flow only *after* the ESTABLISHED:SYN_SENT state is torn down, 
but obviously no state is tracked for the remainder of the connection, because 
pf(4) has forgotten about it.

To show locally-originating IPv6 sessions' SYNACKs are caught by pf(4) as it 
should:
all tcp 2001:838:300:29e::2[65512] -> 2a02:2770::21a:4aff:fed3:e6ac[22]       
ESTABLISHED:ESTABLISHED
(the 29e::2 address is a local one on the gateway)
>How-To-Repeat:
1) Setup a NetBSD IPv6 router with pf(4) stateful tracking and default blocking 
of traffic
2) watch your forwarded sessions get killed
>Fix: