Re: Kernel SCTP and DCCP?

[Kevin Bowling <kevin.bowling%kev009.com@localhost>]

On Mon, Jul 20, 2026 at 3:16 PM Taylor R Campbell <riastradh%netbsd.org@localhost> wrote:
>
> What applications either do, or reasonably could, use SCTP and DCCP in
> the NetBSD kernel?  How do we test them?
>
> These are very large code bases that have been off by default for a
> long time, and appear to have had essentially no maintenance (other
> than build fixes and typo fixes) since 2019.  But I don't know what
> they would be useful for, or even how to use them.
>
> - I know SCTP is used by webrtc, but as far as I know all webrtc
>   implementations just use userland SCTP encapsulated in (DTLS over)
>   UDP, so the kernel SCTP implementation is not relevant.
>
> - I know (in principle) SCTP is used in the control planes of mobile
>   telecoms but I don't know how I would even interact with or simulate
>   such a network if I don't work at a mobile telecom company.
>
> - We appear to have zero userland programs, or automatic tests, that
>   mention SCTP and DCCP at all, except for kdump(1) and netstat(1)
>   output formatters.
>
> - We appear to have no documentation on the wiki or in the guide about
>   how to do anything with SCTP or DCCP.  If I had to fix a
>   vulnerability in it, I wouldn't even know where to start testing it
>   to make sure I didn't break something.
>
> Linux seems to have dropped DCCP in version 6.16.  FreeBSD seems not
> to have ever had kernel DCCP at all.
>
> Is this large code base worth the maintenance costs?  If it is useful,
> can the folks for whom it is useful suggest how to keep it exercised,
> and contribute automatic tests for the basic functionality?

I would vote DCCP as an easy call to just drop.  For protocol research
it can be done in userspace but it appears to be intellectually
abandoned.  SCTP is more technically interesting as well as more
defensible to have in kernel vs userland but the one in tree is
ancient KAME or early FreeBSD code and carries various risks.  I would
vote to drop it, leaving room for an import of newer FreeBSD (this is
the de facto reference stack) code if desired in the future.  Keeping
the current code in tree wouldn't necessarily help with that; no more
than looking at it in version control.

Regards,
Kevin