On Sun, 17 Jul 2022 15:29:39 -0700 Guy Harris via tcpdump-workers <tcpdump-workers@lists.tcpdump.org> wrote:
> On Jul 17, 2022, at 11:09 AM, Francois-Xavier Le Bail > <devel.fx.leb...@orange.fr> wrote: > > > Remain some stuff about 'struct in6_addr'. Any need to keep them? > > > > $ git grep -l 'struct in6_addr' > > CMakeLists.txt > > cmakeconfig.h.in > > config.h.in > > configure > > configure.ac > > netdissect-stdinc.h > > That's there for the benefit of OSes whose APIs don't have standard > IPv6 support; if there are any left that we care about (or if there > are old non-IPv6 versions we care about for any OSes we support), > then it might be useful, but I'm not sure it would build (we use > gethostbyaddr(), so *maybe* it'll compile, and maybe gethostbyaddr() > will fail when passed AF_INET6 and the code will just show the IPv6 > address rather than a name). After a closer look at this code it turns out the only remaining case of struct in6_addr is Windows-specific win32_gethostbyaddr(), so the conditional declaration of struct in6_addr can be at least moved into the same "#ifdef _WIN32" block and at least Autoconf-specific checks for struct in6_addr are moot. If anyone could confirm that supported versions of Windows always have struct in6_addr, that could be removed altogether and the only occurrence of struct in6_addr would be in win_gethostbyaddr(). AF_INET6 looks a bit more convoluted. There is some code that uses AF_INET6 to dissect wire encoding, which is usually a wrong idea. For example, pimv2_addr_print() switches on AF_INET and AF_INET6, and the PIMv2 header encoding (RFC 4601 Section 4.9.1) clearly says the AF is the IANA AF [1]: 1: IP 2: IP6 Which is different from most OS definitions of AF_INET and AF_INET6, but this function has been implemented this way since 1999, and somehow it seems to be able to decode a few PIMv2 packet captures I found on the Internet. So cases like this will require more attention and some of the remaining AF_INET6 instances may become wire encoding constants rather than the OS AF_INET6 constant. The only sound reason for tcpdump to use AF_INET6 seems to be in ip6addr_string() for address-to-name resolving. That use case already has nd_ipv6 and could have a simple "#ifdef AF_INET6" guard. This would eliminate respective logistics in Autoconf and CMake and would make OS IPv6 support a nice-to-have, but not an essential dependency. 1: https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml -- Denis Ovsienko _______________________________________________ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
