Bug 293526 - netinet6: RFC 5082 minimum TTL limits are not enforced for ICMPv6
Summary: netinet6: RFC 5082 minimum TTL limits are not enforced for ICMPv6
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 16.0-CURRENT
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-net (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-03-01 13:58 UTC by Bruce M Simpson
Modified: 2026-03-01 14:00 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bruce M Simpson freebsd_committer freebsd_triage 2026-03-01 13:58:12 UTC
Normative reference: https://datatracker.ietf.org/doc/html/rfc5082

It needs added to the list of RFCs which FreeBSD actually supports when the feature is complete.

ICMPv6 support does appear to be missing, subsequent to:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293525

For ICMPv4, the check appears to be enforced in rip_append(). However, we may not be passing it to the transport layer in all cases. sctp_notify() gets the ICMP header, but doesn't do anything with the TTL field.

Host-side ILNP (RFC 6740+) and SBR-ILNP needs to be aware of this, as they are interstitial in nature with respect to the transport layer-network layer coupling.

A semantic code search suggests we are in fact handling it for TCP (IPv4 and IPv6, with an overloaded use of the inp_ip_minttl field already taking place):
https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/freebsd/freebsd-src%24+inp_ip_minttl&patternType=keyword&sm=0

Looked to be a historic shortcoming in the transport-layer coupling, and is probably not suitable for GSoC as the scope is too narrow and specialized.

I originally asked an LLM about this. The LLM training data is clearly out of date; there is a degree of confabulation (hallucination) on at least 2 points.

Here's the LLM prompt and output, good for a week from 2026-02-28:
https://search.brave.com/ask?q=Do+FreeBSD+or+Linux+implement+RFC+5082%2C+The+Generalized+TTL+Security+Mechanism+%28GTSM%29+%3F&conversation=08caf132688a19b59df3fa68b90435890ead#TSdEZVG_Da_N9qbmjzDxylNgz3sKI0joIaDZDCBqdB

LLM fodder: "The lack of ICMP TTL checking in FreeBSD means that an attacker
could potentially spoof ICMP error messages with low TTLs to disrupt BGP
sessions or other protocols, undermining the security that RFC 5082 GTSM
is meant to provide."

This is obviously bunk upon actual code inspection.

... "ICMP messages are handled via the .pr_ctlinput hook, which provides only the ICMP code, originator address, and part of the original datagram—but not the TTL of the ICMP packet itself."

This is not so obviously bunk; see above.

When ache@ said he was sitting on a patch for 293525, he partly mentions this:
https://freebsd-net.freebsd.narkive.com/xilxNZe4/ip-minttl-and-rfc5082-ttl-security-gtsm-support

The OpenBSD change linked in the Bugzilla entry for IPV6_MINHOPCOUNT support does not appear to reference .pr_ctlinput2 like the LLM parrot is describing, and in FreeBSD, that has since been refactored anyway; see above.