Specifically sin_addr seems to be located on different memory locations for IPv4 and IPv6 socket addressed. This results in weirdness:
#include
Why aren't these 2 values the same ?
sockaddr_in
and sockaddr_in6
are different structs used for different address families (IPv4 and IPv6, respectively). They are not required to be compatible with each other in any way except one - the first field must be a 16-bit integer to hold the address family. sockaddr_in
always has that field set to AF_INET
, and sockaddr_in6
always has that field set to AF_INET6
. By standardizing the family field in this way, any sockaddr
-based API can access that field and know how to interpret the rest of the struct data as needed. That is also why sockaddr
-based APIs usually also have an int
size value as input/output as well, since sockaddr_in
and sockaddr_in6
are different byte sizes, so APIs need to be able to validate the size of any buffers you pass around.
Since this is pointing to the same data (the address to connect to), this should be located at the same address.
No, it should not. The location of the address field within the struct is specific to the type of address family the struct belongs to. There is no requirement that sockaddr_in
and sockaddr_in6
should store their addresses at the exact same offset.
Otherwise, how are you supposed to call inet_ntop with a sockaddr_in that you don't know is IPv4 or IPv6 ?
sockaddr_in
can only be used with IPv4 and nothing else, and sockaddr_in6
can only be used with IPv6 and nothing else. If you have a sockaddr_in
then you implicitally know you have an IPv4 address, and if you have a sockaddr_in6
then you implicitally know you have an IPv6 address. You have to specify that information to inet_ntop()
so it knows how to interpret the data you pass in to it:
struct sockaddr_in sa;
inet_ntop(AF_INET, &(sa.sin_addr), ...);
.
struct sockaddr_in6 sa;
inet_ntop(AF_INET6, &(sa.sin6_addr), ...);
To help you write family-agnostic code, you should be using sockaddr_storage
instead of sockaddr_in
or sockaddr_in6
directly when possible. sockaddr_storage
is large enough in size to hold both sockaddr_in
and sockaddr_in6
structs. Since both structs define a family field at the same offset and size, sockaddr_storage
can be used with any API that operates on sockaddr*
pointers (connect()
, accept()
, bind()
, getsockname()
, getpeername()
, etc).
However, inet_ntop()
does not fall into that category, so you have to pull apart a sockaddr_storage
manually when using inet_ntop()
, eg:
struct sockaddr_storage sa;
switch (sa.ss_family)
{
case AF_INET:
inet_ntop(AF_INET, &(((sockaddr_in*)&sa)->sin_addr), ...);
break;
case AF_INET6:
inet_ntop(AF_INET6, &(((sockaddr_in6*)&sa)->sin6_addr), ...);
break;
}
No, for ipv6 you need to use
in6_addr // is used to store the 128-bit network address
and
sockaddr_in6
Details can be referenced here
For writing code which supports dual stack i.e. ipv4 and 6 along use this