net: Fix IP fragment forwarding and L4 handling

[masc2008]

Summary

• Forward IPv4 fragments before local reassembly, and preserve the original fragment offset/MF bit when re-fragmenting forwarded IPv4 packets.
• Reassemble received IPv6 fragments before NAT66, and dispatch inbound NAT66 using the parsed next-header after IPv6 extension headers.
• Reassemble received IPv6 fragments before IPFILTER so L4 filter matching does not inspect incomplete IPv6 fragments.

Testing

• tools/nxstyle net/devif/ipv4_input.c net/ipforward/ipv4_forward.c net/ipfrag/ipv4_frag.c net/devif/ipv6_input.c net/nat/ipv6_nat.c
• git diff --check
• /tmp/nuttx-ipfrag-verify: sim:dynconns + NAT44/NAT66/IPFRAG, make -j1 net/libnet.a
• /tmp/nuttx-ipfrag-verify: sim:dynconns + CONFIG_NET_IPFILTER=y + CONFIG_NET_NAT66=y + CONFIG_NET_IPFRAG=y, make -j1 net/libnet.a
• Full make -j8 reached the touched net objects, then stopped in external apps/nshlib at O_RDOK undeclared, unrelated to this PR.

[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

[masc2008]

The rule comes directly from the IPv4 router requirements.

The strongest spec is RFC 1812, section 5.2.6:

“A router MUST NOT reassemble any datagram before forwarding it.”

It also gives the reason: fragments may take different paths, so a transit router cannot safely assume it will see all fragments. Source: RFC 1812 section 5.2.6
(https://www.rfc-editor.org/rfc/rfc1812.txt)

The original IPv4 spec, RFC 791, also says the basic model is fragmentation at gateways, with reassembly at the destination host’s IP layer. Source: RFC 791 section 3.2
(https://www.rfc-editor.org/info/rfc791/)

So the intended IPv4 router behavior is:

fragment received
check IPv4 header
decide local vs forward
if forward:
forward this fragment independently
re-fragment only if egress MTU requires it
if local:
reassemble before TCP/UDP/ICMP processing

One more related point: RFC 791’s fragmentation algorithm says that if a fragment is split again, the new fragment offset is based on the original offset plus the new split offset,
and MF follows the original fragment state. That is why the PR also fixes ipv4_fragout() to preserve original offset/MF when re-fragmenting.