are unaware of RFC 3542 can construct control messages.
The kernel disallows mixing RFC 2292 behaviour with RFC 3542 behaviour.
Only sockets that have specifically been marked as using the RFC 2292
API can use RFC 2292 specific options. This is all good and well, but
libc itself seems inconsistent with this.
The root cause of this inconsistency seems to relate to the definitions
of IPV6_HOPOPTS and IPV6_DSTOPTS. They are defined in RFC 2292 and re-used
in RFC 3542, yet have distinct values in the kernel. It's for this reason
that the kernel also has definitions for IPV6_2292HOPOPTS and
IPV6_2292DSTOPTS. Not so in libc.
For example: some program calls inet6_option_init() (defined by RFC 2292)
with the RFC 2292 defined IPV6_HOPOPTS and IPV6_DSTOPTS. Before RFC 3542,
this was translated to values of 22 and 23 (resp.) The libc implementation
correctly checks that only options IPV6_HOPOPTS and IPV6_DSTOPTS are given
(as per RFC 2292) but since these defines have taken on the values defined
by RFC 3542 (values 49 and 50 resp,) rejects the correct option values
(22 and 23) passed said program and returns -1.
The precisie fix is to have inet6_option_init() and friends only accept the
RFC 2292 defined IPV6_HOPOPTS & IPV6_DSTOPTS, but that breaks other code
(like mld6query(8)), which seem to not be aware of RFC 3542 and how it
hi-jacked the option names. So the best fix is to accept the options from
both.
Obtained from: Juniper Networks, Inc.
MFC after: 1 week
4ed06f2924