netstack: factor ICMP echo reply helpers

[Amaindex]

Overview

This is a mechanical follow-up to the previous ICMP Echo handler PR, #13189.¹

It factors the built-in IPv4 and IPv6 ICMP Echo Reply construction paths into private endpoint helpers, without changing the Echo Request handling semantics.

The immediate goal is to make the existing built-in reply path reusable by a follow-up ICMP handler API, while keeping this PR limited to a behavior-preserving refactor.

No public API is added in this change, and LocalAddressTemporary behavior is unchanged.

Behavior

This PR should preserve the current behavior matrix:

no ICMP default handler        -> built-in Echo Reply is preserved
default handler returns false  -> built-in Echo Reply is preserved
default handler returns true   -> no built-in Echo Reply
registered ICMP endpoint       -> default handler is not called; built-in Echo Reply is preserved
IPv4 LocalAddressTemporary     -> built-in Echo Reply is still suppressed

The only code movement is the built-in reply construction itself:

• IPv4 Echo Reply construction moves to a private IPv4 endpoint helper.
• IPv6 Echo Reply construction moves to a private IPv6 endpoint helper.

The call sites still make the same decisions before invoking those helpers.

Why and Follow-up Direction

For the next PR, I would like to continue with the same handler action direction.

The follow-up API should preserve the distinction between explicit handler actions and the no-explicit-action path:

explicitly suppress the built-in Echo Reply
explicitly send/delegate to the built-in Echo Reply path
take no explicit action and preserve the current behavior matrix

That should address the large-address-space embedder case raised in the previous discussion¹ without requiring downstreams to reimplement ICMP Echo Reply construction, while still preserving explicit ownership for tunnel/proxy handlers that intentionally consume Echo Requests.

This refactor is the small mechanical step needed before that API. The built-in reply path should stay in the network endpoint layer because it depends on protocol-specific details such as route lookup, source address selection, rate limiting, stats, checksums, IPv4 options, IPv6 traffic class, and output hooks. The follow-up API should delegate to this path rather than copying those details into transport/icmp.

One possible API shape could be along these lines:

f := icmp.NewForwarder(s, func(r *icmp.ForwarderRequest) icmp.ForwarderAction {
    if shouldHandleByTunnel(r) {
        return icmp.ForwarderActionSuppress
    }
    return r.Reply()
})

s.SetTransportProtocolHandler(icmp.ProtocolNumber4, f.HandlePacket)
s.SetTransportProtocolHandler(icmp.ProtocolNumber6, f.HandlePacket)

or an equivalent API where the handler can explicitly request the built-in reply path.

The important part is that explicit suppress/reply decisions remain distinguishable from the no-explicit-action path, and that Reply() / SendReply delegates to the existing network-layer helper rather than duplicating that protocol-specific reply logic in transport/icmp.

The follow-up should align the ICMPv4 and ICMPv6 handler action surface while preserving the current default behavior matrix.

Does that action-style direction still look right for the follow-up?

Tests

make test TARGETS=//pkg/tcpip/network/ipv4:ipv4_test OPTIONS=--test_filter=TestICMPEcho
make test TARGETS=//pkg/tcpip/network/ipv6:ipv6_test OPTIONS=--test_filter=TestICMPEcho
make test TARGETS=//pkg/tcpip/network/ipv4:ipv4_test OPTIONS=--test_filter=TestIcmpRateLimit
make test TARGETS=//pkg/tcpip/network/ipv6:ipv6_test OPTIONS=--test_filter=TestNeighborSolicitationResponse
make test TARGETS="//pkg/tcpip/network/ipv4:ipv4_test //pkg/tcpip/network/ipv6:ipv6_test"
make test TARGETS=//pkg/tcpip/stack:stack_test

Footnotes

1. netstack: let ICMP echo handlers consume requests #13189 ↩ ↩²