From Fedora Project Wiki

< QA‎ | Networking

Revision as of 16:32, 19 October 2015 by Jpopelka (talk | contribs) (typos)

Server operations

A networking server typically listens for new connections from clients. Basic operation doesn't require any name resolution as the server can listen on wildcard addresses.

Address list generation phase

Many servers support listening on specific local IPv4 and IPv6 addresses. It is especially useful for running multiple instances on one host, but it is also used as a security measure for example to limit scope to the local host. Although configuration typically includes literal addresses, it may be useful to use actual domain names like localhost or even those from DNS, provided that they are immediately resolvable using the local infrastructure.

Typical configuration situations:

  • no configuration – server listens on :: and
  • localhost – server listens on ::1 and
  • list of domain names or literal IP addresses – server listens on listed or resolved IP addresses

Known issues:

  • Fedora by default enables dual-stack sockets on ::0 address and therefore explicit listening on both wildcard addresses doesn't work as intended.

Query using getaddrinfo()

struct addrinfo hints = { .ai_flags = AI_PASSIVE };
struct addrinfo *res;
int status;

status = getaddrinfo(nodename, servname, &hints, &res);

Note: AI_PASSIVE option ensures NULL nodename is translated to :: and

Note: You need to explicitly set IPV6_V6ONLY socket option on all IPv6 sockets to avoid conflict between an IPv4 and an IPv6 socket.

Binding and listening phase

Server should listen on all addresses from the previous phase.

Accepting clients phase

A dual-stack server accepts connections from clients of both protocols. It often needs to cope with both types of addresses for logging and access control purposes.

Related library calls:

  • accept()
  • getsockname()

How to test

Testing servers is a bit more complicated in that different servers use IP addresses in different ways. So the test cases below are rather vague and must be adapted to specific server packages.

Local host client-server connection

  • Connect a client to localhost
  • Check log for correct IPv6 node-local address (::1)
  • Check successful client-server operation

Known problems

  • Some servers, especially those employing access lists, accept connections via but not via ::1.

Remote client connected over IPv4

  • Connect a client over IPv4
  • Check log for correct IPv4 address
  • Check successful client-server operation

Remote client connected over IPv6

  • Connect a client over IPv6
  • Check log for correct IPv6 address
  • Check successful client-server operation