IPv6 hton layout does not match ipv6_mreq

[tenderlove]

Given this C program:

#include <netinet/in.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int main(int argc, char * argv[])
{
 struct ipv6_mreq req;
 memset(&req, 0, sizeof(req));
	req.ipv6mr_multiaddr.s6_addr[0] = 0xFF;
	req.ipv6mr_multiaddr.s6_addr[1] = 0x02;
	req.ipv6mr_multiaddr.s6_addr[15] = 0xFB;

 uint8_t * ptr = (uint8_t *)&req;
 for(int i = 0; i < sizeof(req); i++) {
 fprintf(stderr, "\\%#02x", ptr[i]);
 }

 fprintf(stderr, "\n");
 return 0;
}

The bytes of the ipv6_mreq struct are: \0xff\0x2\00\00\00\00\00\00\00\00\00\00\00\00\00\0xfb\00\00\00\00

However, if I use this Ruby program:

require "ipaddr"

p IPAddr.new("ff02::fb").hton

The bytes are: "\xFF\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xFB"

I think hton should match the ipv6_mreq layout.

[tenderlove]

btw I'm not confident that I'm debugging this correctly, but I think the bytes should be the same.

[tenderlove]

Hi,

I wanted to comment on this issue because of discussions at RubyKaigi. I don't know if this PR is the correct fix, but I was having a problem with IPAddr and had to work around this bug here

[taketo1113]

@tenderlove Thank you for the information.
I will look into it myself as well.

[taketo1113]

@tenderlove I checked the difference in output between ipv6_mreq and IPAddr#hton.

I believe IPAddr#hton is actually returning the correct bytes,
but the comparison is currently between two different things.

IPAddr#hton returns the binary representation of the IPv6 address itself (16 bytes),
while the C example appears to dump the entire struct ipv6_mreq (20 bytes). The difference is visible here:

Bytes	0	1	2-14	15	16-19
ipv6_mreq	FF	02	...	FB	00 00 00 00
IPAddr#hton	FF	02	...	FB	(none)

The trailing 00 00 00 00 bytes are the ipv6mr_interface field (interface index, zeroed out), not part of the IPv6 address itself:

 struct ipv6_mreq {
 struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
 unsigned int ipv6mr_interface; /* interface index */
 };

See also: https://datatracker.ietf.org/doc/html/rfc3493#section-5.2

The first 16 bytes are identical between the two outputs,
so this does not appear to be a bug.

If you need a ready-to-use ipv6_mreq binary for setsockopt,
you can append the interface index yourself for now:

ipv6_mreq = IPAddr.new("ff02::fb").hton + [0].pack('N')
# => 20-byte ipv6_mreq with interface index 0

[tenderlove]

The trailing 00 00 00 00 bytes are the ipv6mr_interface field (interface index, zeroed out), not part of the IPv6 address itself:

Ah, interesting. I see.

If you need a ready-to-use ipv6_mreq binary for setsockopt,
you can append the interface index yourself for now:

Yes, I know I can assemble the bytes myself. But I guess my real question is "is the output of hton meant to be valid input for setsockopt?"

Maybe we need a new API or something? I don't expect most Ruby programmers to investigate the struct layout and manually assemble correct bytes for setsockopt. (I could be wrong though)

Thank you for looking at this by the way. I appreciate it!

[taketo1113]

Maybe we need a new API or something? I don't expect most Ruby programmers to investigate the struct layout and manually assemble correct bytes for setsockopt. (I could be wrong though)

I think that could make sense. Since setsockopt is a fairly low-level socket programming interface, it seems reasonable to have a higher-level API that doesn't require users to manually assemble the byte sequence.

That said, ipv6_mreq is part of the socket interface rather than an IP address abstraction.
So I think such an API would fit better as part of Socket, or perhaps a dedicated abstraction for multicast, rather than IPAddr.