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
::
and0.0.0.0
- localhost – server listens on
::1
and127.0.0.1
- 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 0.0.0.0
.
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()
Test cases
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.
Loopback, IPv6 only server
Connectivity | IPv4 | Any (loopback address wanted) |
---|---|---|
IPv6 | Any except disabled (loopback address required) | |
Other | Server software only listens on IPv6. |
What is tested
- Ability to accept IPv6 connections.
- Correct handling of IPv6 loopback clients.
Steps to reproduce
- Connect a client using
localhost
hostname. - Check server log for IPv6 connection.
- Check successful operation.
Expected result
- Client connects to server using
::1
address. - Server accepts the client connection and operates correctly.
Bad result
- Server refuses to serve the client e.g. due to access lists
containing only IPv4 loopback.
Remote client connected over IPv4
Source connectivity | IPv4 | Global or masqueraded |
---|---|---|
IPv6 | None | |
Target connectivity | IPv4 | Global |
IPv6 | Global |
What is tested
- Whether the software accepts IPv4 connections.
Steps to reproduce
- Connect a client via IPv4.
- Check server logs for connection details.
- Check successful operation.
Expected result
- Client connects using its IPv4 address or using
external IPv4 addresses of a NAT device.
- Server accepts the client connection and operates correctly.
Note: An IPv4-mapped IPv6 addres in the log is generally accepted but should be printed in a way showing the actual IPv4 address.
Bad result
- Server doesn't accept the connection, reports wrong connection data or fails to operate correctly.
Remote client connected over IPv6
Source connectivity | IPv4 | None |
---|---|---|
IPv6 | Global | |
Target connectivity | IPv4 | Global |
IPv6 | Global |
What is tested
- Whether the software accepts IPv6 connections.
Steps to reproduce
- Connect a client via IPv6.
- Check server logs for connection details.
- Check successful operation.
Expected result
- Client connects using its IPv6 address.
- Server accepts the client connection and operates correctly.
Bad result
- Server doesn't accept the connection, reports wrong connection data or fails to operate correctly.