net: Fix fragment forwarding and IPv6 reassembly keys

[masc2008]

Summary

• suppress ICMP errors for IPv4 non-initial fragments during forwarding failures
• include IPv6 source/destination addresses in fragment reassembly matching

Risk without this change

• IPv6 reassembly can mix fragments from different packets when they arrive on the same interface with the same Fragment Identification value.
• A mixed reassembly can corrupt payload data by combining fragment zero from one IPv6 flow with later fragments from another flow.
• NAT66 and IP filter paths reassemble fragments before processing, so a corrupted reassembled packet can lead to wrong NAT/filter decisions.
• Legitimate fragmented traffic can be dropped or timed out if another packet poisons its reassembly node.
• An attacker able to inject IPv6 fragments with a chosen or guessed Fragment Identification value can interfere with another fragmented flow on the same interface.
• Tracking the IP family in the reassembly key also avoids accidental IPv4/IPv6 node matching on the same interface and identification value.

Testing

• git diff --check HEAD~2..HEAD
• tools/nxstyle net/ipforward/ipv4_forward.c
• tools/nxstyle net/ipfrag/ipfrag.c
• tools/nxstyle net/ipfrag/ipfrag.h
• tools/nxstyle net/ipfrag/ipv6_frag.c

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb

[xiaoxiang781216]

why need this check which is already done in ip_fragin_match