Hello Kristof,

On Fri, Feb 28, 2025 at 10:12:16AM +0100, Kristof Provost wrote:
</snip>
> > I feel the case of 4->6 is similar. IPv4 host connects to some
> > IPv4 address and firewall translates that to IPv6 and forwards
> > the packet to IPb6 network. The last hop IPv4 client sees
> > is the public IP address of firewall. That's my understanding.
> >

> That makes sense, yes. The implication would be that we can???t sensible
> translate the remote IPv6 addresses to make traceroute work in that scenario,
> right? 
 
    yes, that's exactly how I understand that.

>  In any event, fixing it for nat64 is a clear step forward, so we
> should do that regardless.

    I agree. to understand what happens in NAT-46 case we need to test
    situation where there are more IPv6 hops behind NAT-46 firewall.  for
    example assume path between IPv4 client and IPv6 server takes 5 hops.
    there are 2 hops between NAT-46 router and IPv6 destination where IPv4
    client is connecting to. Now let client to send packet with TTL set to 5
    how ICMP error sent back from IPv6 router will look like when seen
    by client? I need to look at it myself first to find answer. And yes
    this is out of scope the problem we are fixing here.
> 

> >> I also didn???t make any changes for the pf_icmp_mapping() == 0 case (i.e.
> >> it???s an ICMP query/reply not related to a TCP/UDP packet). In that case we
> >> do the state lookup based on the ICMP packet???s source address (and
> >> destination and type and code, of course). So I don???t think we can have a
> >> situation where the packet???s source address doesn???t match the one for the
> >> state we found.
> >>
> >
> > I think you are right. For case pf_icmp_mapping() the packet should be
> > sent by destination host as found in state. I will adjust my diff.
> >
> I???ve ported your patch to FreeBSD and run it through my test cases. That all passes.
> 
> Doing the extra translation as in the first version also worked, because it
> always ends up translating to the same address anyway. Still, less code and
> less work is better.
> 

    thank you very much for testing out the change on FreeBSD too.

regards
sashan