On Sun, 17 Jul 2022 15:29:39 -0700
Guy Harris via tcpdump-workers <tcpdump-workers@lists.tcpdump.org>

> 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

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.


    Denis Ovsienko
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org

Reply via email to