Proceeding to make rwhod ipv6 clean.

[luthramihir708_gmail.com]

Summary

Currently, I haven't changed much code, just introduced in6addr_whod_group like INADDR_WHOD_GROUP is for ipv4. Also changed come code in main() to use getaddrinfo(3) with AF_UNSPEC.

Also struct servent *hp was a global variable just being used for port information. So I replaced it with in_port_t who_port.

I didn't change code further to first get advise on how should I conditionally select ipv6/ipv4 for
multicast. The global multicast_addr currently sticks to AF_INET. I can use struct sockaddr_storage,
but on what basis should I select whether to use` ipv6` or ipv4, like should I conditionally allow both or
take it as input through args?

[luthramihir708_gmail.com]

This comment was removed by luthramihir708_gmail.com.

[luthramihir708_gmail.com]

1. use getopt(3) to parse options
2. introduce -4/-6 flags to enable ipv4/6
3. introduce multicast_addr6 for ipv6 multicasting with hops/ttl
4. clean receiver_process() to receive from both ip4/6

Plans for next update:

1. Placing #ifdefs INET/INET6 so that no extra code is ran on ipv4/6 only machines
2. As ipv6 doesn't implement broadcast, need advice on how should I proceed when v6 is enabled? Maybe link-local multicast? If yes, should I use dual stack ipv6/v4 accepting socket in that case?

[hrs]

Your change looks to me trying to add IPv6 support by a copy-and-paste of the logic used in IPv4. I do not think it is a good idea in general or even for rwhod. At the time when rwhod utility was written there was an IPv4-specific API only, but nowadays we have a lot of address family independent APIs. For multicast membership management, an API defined in RFC 3678 is the standard way to support IPv4 and IPv6 in a AF-agnostic manner. Therefore, multicast support of rwhod needs a major rewrite by using this new API to support both IPv4 and non-IPv4 protocols at least. While we welcome converting an IPv4-only program to support IPv6 in an AF-independent API such as getaddrinfo(3), we do not want to add another IPv6-only code path to every single IPv4-only utility unless it is the only way to do so.

After converting rwhod to use RFC 3678 multicast membership management API, rwhod will support IPv4 multicast and IPv6 multicast seamlessly. IPv4 boardcast support still requires its own code path. You do not need to consider IPv6 boardcast because it is impossible.

usr.sbin/rwhod/rwhod.c

95

I think the multicast scope must be configurable. It is also controlled by TTL, but IPv6 has link-local, site-local, admin-local, realm-local, and org-local, and IPv4 has some similar to them by using different addresses. Considering practical scenarios where rwhod works with IPv6, it is possible to join multiple scopes at the same time (e.g. link-local for hosts on the same link and site-local for hosts beyond the subnet boundaries). The default should be link-local for both IPv4 and IPv6.

101

This should be initialized by using a result of getaddrinfo(), not a binary constant, even for IPv4.

263

When both enable_v4 and enable_v6 are equal to 1, is only AF_INET6 used? It looks it assumes whod_port is the same as each address family. Do not use hints.ai_family to limit based on enable_v[46] here. In this logic, what you should do is getaddrinfo() with AF_UNSPEC, and then checking an AF_INET entry if enable_v4 == 1 and doing an AF_INET6 entry if enable_v6 == 1.

However, resolving only "who" without an address does not make sense here in the first place. You should to resolve ff05::103 and 224.0.1.3 at the same time to let getaddrinfo() to set a struct sockaddr. whod_port is not necessary at all if the bound sockaddr structures are stored somewhere.

299

Why the third argument is zero instead of res->ai_protocol?

308

This conditional must use res->ai_family.

314

AI_PASSIVE is required in getaddrinfo(3) if you want to use its ai_addr for bind(2).

446

The port number can be extracted by using getnameinfo() in AF-independent manner.

465

ip is not initialized in some cases.