Suricata

When Suricata encounters an IP protocol that has no dedicated decoder (e.g., PGM, protocol 113), the engine does not populate p->payload/p->payload_len. In decode-ipv4.c protocol switch there's no matching case or default at all for these; in decode-ipv6.c it falls into a default: case, which only raises IPV6_UNKNOWN_NEXT_HEADER and records the L4 proto — neither path touches the payload pointer. Since default content matching always inspects p->payload (detect-engine-payload.c)

I propose the default behavior for IP protocols without a registered decoder, set p->payload to point at the start of the data immediately following the IP header, and p->payload_len to the remaining length, instead of leaving both zeroed. This would apply generically as a fallback in the IPv4/IPv6 next-protocol dispatch (not per-protocol), so any current or future protocol lacking a dedicated decoder gets a basic, generic payload buffer for content inspection — without requiring a full protocol-specific parser for each one.

This was discovered when I attempted to build a rule focused on detecting specific content within Pragmatic General Multicast (PGM) (protocol 113). it has zero decode support in Suricata today (only a display-name string in util-proto-name.c), so rule writers cannot write detections against PGM payloads at all. A generic "unhandled protocol → raw payload" fallback would immediately unblock content matching for PGM and any other IP protocol without needing bespoke decoders written for each one.

This wouldn't replace real protocol decoders (which can still parse structure, offsets, and set decoder events) — it's a baseline so content isn't silently unusable for anything not yet explicitly supported.