From Fedora Project Wiki

< QA‎ | Networking

 
(One intermediate revision by one other user not shown)
Line 5: Line 5:
== Address list generation phase ==
== 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 measuer for example to limit scope to the local host. Although configuration typically includes literal addresses, it may be useful to use actual domains names like ''localhost'' or even those from DNS provided that they are immediately resolvable using the local infrastructure.
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:
Typical configuration situations:
Line 27: Line 27:
</pre>
</pre>


Note: <code>AI_PASSIVE</code> options ensures NULL nodename is translated to <code>::</code> and <code>0.0.0.0</code>.
Note: <code>AI_PASSIVE</code> option ensures NULL nodename is translated to <code>::</code> and <code>0.0.0.0</code>.


Note: You need to explicitly set <code>IPV6_V6ONLY</code> socket option on all IPv6 sockets to avoid conflict between an IPv4 and an IPv6 socket.
Note: You need to explicitly set <code>IPV6_V6ONLY</code> socket option on all IPv6 sockets to avoid conflict between an IPv4 and an IPv6 socket.
Line 44: Line 44:
* <code>getsockname()</code>
* <code>getsockname()</code>


== How to test ==
== 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.
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 ===
=== Loopback, IPv6 only server ===


* Connect a client to <code>localhost</code>
{|
* Check log for correct IPv6 node-local address (<code>::1</code>)
!rowspan=2| Connectivity
* Check successful client-server operation
! IPv4
| Any (loopback address wanted)
|-
! IPv6
| Any except disabled (loopback address required)
|-
!colspan=2| Other
| Server software only listens on IPv6.
|}


==== Known problems ====
==== What is tested ====


* Some servers, especially those employing access lists,  accept connections via <code>127.0.0.1</code> but not via <code>::1</code>.
* Ability to accept IPv6 connections.
* Correct handling of IPv6 loopback clients.
 
==== Steps to reproduce ====
 
# Connect a client using <code>localhost</code> hostname.
# Check server log for IPv6 connection.
# Check successful operation.
 
==== Expected result ====
 
* Client connects to server using <code>::1</code> 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 ===
=== Remote client connected over IPv4 ===


* Connect a client over IPv4
{|
* Check log for correct IPv4 address
!rowspan=2| Source connectivity
* Check successful client-server operation
! IPv4
| Global or masqueraded
|-
! IPv6
| None
|-
!rowspan=2| 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
<abbr title="Network Address Translation">NAT</abbr>
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 ===
=== Remote client connected over IPv6 ===


* Connect a client over IPv6
{|
* Check log for correct IPv6 address
!rowspan=2| Source connectivity
* Check successful client-server operation
! IPv4
| None
|-
! IPv6
| Global
|-
!rowspan=2| 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.

Latest revision as of 23:18, 11 November 2015

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 0.0.0.0
  • localhost – server listens on ::1 and 127.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

  1. Connect a client using localhost hostname.
  2. Check server log for IPv6 connection.
  3. 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.