Skip to content

RFC 2292 struct and constant definitions#4954

Open
Skyb0rg007 wants to merge 1 commit intorust-lang:mainfrom
Skyb0rg007:icmpv6-filters
Open

RFC 2292 struct and constant definitions#4954
Skyb0rg007 wants to merge 1 commit intorust-lang:mainfrom
Skyb0rg007:icmpv6-filters

Conversation

@Skyb0rg007
Copy link

@Skyb0rg007 Skyb0rg007 commented Jan 30, 2026

Description

This PR adds the structs and constants as defined by RFC 2292 - Advanced Sockets API for IPv6.
These constants are available for use in get/setsockopt on supported Unix platforms.
The operations defined on the icmp6_filter struct are defined as C macros, so the implementations are not included here.

Sources

https://github.com/bminor/glibc/blob/04e750e75b73957cf1c791535a3f4319534a52fc/inet/netinet/icmp6.h
https://github.com/kraj/musl/blob/kraj/master/include/netinet/icmp6.h
https://github.com/freebsd/freebsd-src/blob/9ae367d11de8abbdf53884836c9ba30908c5c8db/sys/netinet/icmp6.h

Also in the RFC: https://datatracker.ietf.org/doc/html/rfc2292#section-3.2

Checklist

Unfortunately I could not get the libc-tests working locally, so this PR is marked as draft.

  • Relevant tests in libc-test/semver have been updated
  • No placeholder or unstable values like *LAST or *MAX are
    included (see #3131)
  • Tested locally (cd libc-test && cargo test --target mytarget);
    especially relevant for platforms that may not be checked in CI

@rustbot label +stable-nominated

@rustbot rustbot added the stable-nominated This PR should be considered for cherry-pick to libc's stable release branch label Jan 30, 2026
@Skyb0rg007 Skyb0rg007 force-pushed the icmpv6-filters branch 15 times, most recently from b8f20e4 to 16f3cea Compare February 3, 2026 20:32
@Skyb0rg007
Copy link
Author

Alright, I need help. On *BSD platforms (FreeBSD, macOS, etc), struct in6_addr is defined as the union of uint32_t[4], uint16_t[8], and uint8_t[16], so Rust encodes it as [u8; 16] with repr(align(4)).

But the nd_(router|neighbor)_(solicit|advert) structures are marked as __packed (so their C alignment is 1), even though they include a in6_addr. Rust won't allow using repr(packed) on a struct containing a repr(align(...)) attribute, so I'm stuck.

Linux doesn't mark these structs as __packed, so there's no issue there.

@Skyb0rg007 Skyb0rg007 force-pushed the icmpv6-filters branch 13 times, most recently from 742cf17 to 6d97ed6 Compare February 4, 2026 20:49
@Skyb0rg007 Skyb0rg007 force-pushed the icmpv6-filters branch 2 times, most recently from d5989eb to dfe9971 Compare February 4, 2026 21:31
This PR adds the icmp6_filter struct and constants as defined
by RFC 2292 - Advanced Sockets API for IPv6.
These constants are available for use in get/setsockopt
on supported Unix platforms.
The operations defined on the icmp6_filter struct are defined
as C macros, so the implementations are not included here.
See the RFC for definitions and use.
@Skyb0rg007
Copy link
Author

For now, I simply guard the offending struct definitions with #[cfg(...)]. I still think the src/unix/mod.rs file is the right place (instead of one of the platform-specific subdirectories) because these structures and definitions are specified by network protocols. I think the three "complete" solutions would be:

  1. Add struct ip6_addr_packed without an alignment attribute. Use that for these fields.
  2. Use [u8; 16] instead of ip6_addr for these platforms.
  3. Break alignment compatibility with these structures on the offending platforms. From the FreeBSD documentation, the use of __packed is used in network protocol code to avoid padding bytes, not to allow non-aligned data.

Otherwise I think this PR is ready to review.

@Skyb0rg007 Skyb0rg007 marked this pull request as ready for review February 4, 2026 22:03
@Skyb0rg007
Copy link
Author

Skyb0rg007 commented Feb 4, 2026

I think GNU Hurd (due to using glibc) and Fuchsia (due to Zircon) could add ICMP6_FILTER = 1. It's also available on Solaris (docs). I don't have a way to test these platforms though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review stable-nominated This PR should be considered for cherry-pick to libc's stable release branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants