From Fedora Project Wiki

< QA‎ | Networking

(Created page with "== Dual-stack to dual-stack == {| |IPv4 connectivity||Global or masqueraded |- |IPv6 connectivity||Global |- |Target DNS||Dual-stack |} === What is tested === * Whether IPv...")
 
No edit summary
Line 1: Line 1:
== Dual-stack to dual-stack ==
A networking client typically connects to a server identified by connection information specified in its configuration or by the user. The general client procedure is to use [[../Name resolution|name resolution]] service (often through the system C library) and use the result to negotiate a connection through the operating system kernel.
 
== Name resolution phase ==
 
Client software retrieves a domain name from the user or from its configuration either as a verbatim value or by parsing a more complex configuration item like an URL or an e-mail address. Client software can often handle special values like literal IP addresses or empty host names. Most often this is the only configuration that is needed. Other name resolution input is built-in but can often also be tweaked by configuration or URL.
 
Name resolution typically consists of multiple actions. The most typical combination of actions is host name resolution using DNS
where <code>A</code> and <code>AAAA</code> are requested separately in order to get IPv4 and IPv6 addresses. Sequential or parallel queries can be used to handle that situation.
 
''See [[../Name resolution|Name resolution]] page for more details.''
 
=== Example: Jabber (XMPP client connection) ===
 
Identifier: user@example.net
 
Client extracts domain name <code>example.net</code> from the configuration option above, resolves <code>SRV</code> record <code>_xmpp-client._tcp.example.net</code> to get the list of host names and then attempts to resolve <code>A</code> and <code>AAAA</code> records of those host names to get the list of IPv4 and IPv6 addresses to be attempted for connection.
 
You can use ''netresolve'' to mimic the above procedure:
 
<pre>netresolve --node example.net --service xmpp-client --srv --protocol tcp</pre>
 
== Connection phase ==
 
Connection procedure can start after or during the name resolution phase and uses the name resolution results. The connection procedure can also be fully sequential (client attempts addresses in a given order until a successful connection is established) or using parallelization. The most prominent reason for parallel connection is to avoid a defunct protocol version by attempting an IPv4 address at the same time as an IPv6 address.
 
== Test cases ==
 
=== Dual-stack to dual-stack ===


{|
{|
Line 9: Line 36:
|}
|}


=== What is tested ===
==== What is tested ====


* Whether IPv6 is preferred over IPv4.
* Whether IPv6 is preferred over IPv4.
Line 15: Line 42:
* Whether sequential or parallel DNS resolution is in use.
* Whether sequential or parallel DNS resolution is in use.


=== Test flow ===
==== Test flow ====
'''TBD'''
'''TBD'''
# step
# step
# another step
# another step


=== Expected result (sequential, IPv6 preferred) ===
==== Expected result (sequential, IPv6 preferred) ====


* Host requests AAAA record and receives a reply.
* Host requests AAAA record and receives a reply.
Line 26: Line 53:
* No delays, no A query.
* No delays, no A query.


=== Expected result (parallel, IPv6 preferred) ===
==== Expected result (parallel, IPv6 preferred) ====


* Host requests A and AAAA records simultaneously and receives the AAAA reply.
* Host requests A and AAAA records simultaneously and receives the AAAA reply.
Line 32: Line 59:
* No delays, A reply is ignored if received.
* No delays, A reply is ignored if received.


=== Alternative result (parallel, first result wins, no protocol preference) ===
==== Alternative result (parallel, first result wins, no protocol preference) ====


* Host requests A and AAAA records simultaneously and receives the first reply.
* Host requests A and AAAA records simultaneously and receives the first reply.
Line 38: Line 65:
* No delays.
* No delays.


== Dual-stack to dual-stack with lost AAAA answer ==
=== Dual-stack to dual-stack with lost AAAA answer ===


Same as above, except that the AAAA answer is lost by a broken DNS server.
Same as above, except that the AAAA answer is lost by a broken DNS server.
Line 50: Line 77:
|}
|}


=== What is tested ===
==== What is tested ====


* Wheter the component reverts to IPv4 in reasonable time when AAAA answer gets lost.
* Wheter the component reverts to IPv4 in reasonable time when AAAA answer gets lost.


=== Test flow ===
==== Test flow ====
'''TBD'''
'''TBD'''
# step
# step
# another step
# another step


=== Expected result (sequential, IPv6 preferred) ===
==== Expected result (sequential, IPv6 preferred) ====


* Host requests AAAA record and gives up after a delay (e.g. 15 seconds).
* Host requests AAAA record and gives up after a delay (e.g. 15 seconds).
Line 65: Line 92:
* Host connects via IPv4.
* Host connects via IPv4.


=== Expected result (parallel, IPv6 preferred) ===
==== Expected result (parallel, IPv6 preferred) ====


* Host requests A and AAAA records simultaneously and receives the A reply.
* Host requests A and AAAA records simultaneously and receives the A reply.
Line 71: Line 98:
* Host connects via IPv4.
* Host connects via IPv4.


=== Alternative result (parallel, first result wins) ===
==== Alternative result (parallel, first result wins) ====


* Host requests A and AAAA records simultaneously and receives the A reply.
* Host requests A and AAAA records simultaneously and receives the A reply.
Line 77: Line 104:
* No delay.
* No delay.


== IPv4 to dual-stack with lost AAAA answer ==
=== IPv4 to dual-stack with lost AAAA answer ===


Same as above, except that the host doesn't have any IPv6 address except link-local and loopback.
Same as above, except that the host doesn't have any IPv6 address except link-local and loopback.
Line 89: Line 116:
|}
|}


=== What is tested ===
==== What is tested ====


* Wheter the component suppresses AAAA queries when lacking global IPv6 connectivity.
* Wheter the component suppresses AAAA queries when lacking global IPv6 connectivity.


=== Test flow ===
==== Test flow ====
'''TBD'''
'''TBD'''
# step
# step
# another step
# another step


=== Expected result ===
==== Expected result ====


* Host requests A record and receives reply.
* Host requests A record and receives reply.
Line 104: Line 131:
* No delay, no AAAA query.
* No delay, no AAAA query.


== Dual-stack to dual-stack with lost communication ==
=== Dual-stack to dual-stack with lost communication ===


{|
{|
Line 114: Line 141:
|}
|}


=== What is tested ===
==== What is tested ====


* Whether the component reverts to IPv4 in reasonable time when local or remote network drops all IPv6 communication.
* Whether the component reverts to IPv4 in reasonable time when local or remote network drops all IPv6 communication.


=== Test flow ===
==== Test flow ====
'''TBD'''
'''TBD'''
# step
# step
# another step
# another step


=== Expected result (sequential, IPv6 preferred) ===
==== Expected result (sequential, IPv6 preferred) ====


* Host requests AAAA record and receives reply.
* Host requests AAAA record and receives reply.
Line 130: Line 157:
* Host connects via IPv4
* Host connects via IPv4


=== Expected result (parallel DNS, IPv6 preferred) ===
==== Expected result (parallel DNS, IPv6 preferred) ====


* Host requests A and AAAA records simultaneously and waits for AAAA reply.
* Host requests A and AAAA records simultaneously and waits for AAAA reply.
Line 136: Line 163:
* Host connects via IPv4.
* Host connects via IPv4.


=== Expected result (parallel DNS, parallel TCP, IPv6 preferred) ===
==== Expected result (parallel DNS, parallel TCP, IPv6 preferred) ====


* Host requests A and AAAA records simultaneously
* Host requests A and AAAA records simultaneously

Revision as of 08:59, 8 October 2015

A networking client typically connects to a server identified by connection information specified in its configuration or by the user. The general client procedure is to use name resolution service (often through the system C library) and use the result to negotiate a connection through the operating system kernel.

Name resolution phase

Client software retrieves a domain name from the user or from its configuration either as a verbatim value or by parsing a more complex configuration item like an URL or an e-mail address. Client software can often handle special values like literal IP addresses or empty host names. Most often this is the only configuration that is needed. Other name resolution input is built-in but can often also be tweaked by configuration or URL.

Name resolution typically consists of multiple actions. The most typical combination of actions is host name resolution using DNS where A and AAAA are requested separately in order to get IPv4 and IPv6 addresses. Sequential or parallel queries can be used to handle that situation.

See Name resolution page for more details.

Example: Jabber (XMPP client connection)

Identifier: user@example.net

Client extracts domain name example.net from the configuration option above, resolves SRV record _xmpp-client._tcp.example.net to get the list of host names and then attempts to resolve A and AAAA records of those host names to get the list of IPv4 and IPv6 addresses to be attempted for connection.

You can use netresolve to mimic the above procedure:

netresolve --node example.net --service xmpp-client --srv --protocol tcp

Connection phase

Connection procedure can start after or during the name resolution phase and uses the name resolution results. The connection procedure can also be fully sequential (client attempts addresses in a given order until a successful connection is established) or using parallelization. The most prominent reason for parallel connection is to avoid a defunct protocol version by attempting an IPv4 address at the same time as an IPv6 address.

Test cases

Dual-stack to dual-stack

IPv4 connectivity Global or masqueraded
IPv6 connectivity Global
Target DNS Dual-stack

What is tested

  • Whether IPv6 is preferred over IPv4.
  • Whether the component is capable of working over IPv6.
  • Whether sequential or parallel DNS resolution is in use.

Test flow

TBD

  1. step
  2. another step

Expected result (sequential, IPv6 preferred)

  • Host requests AAAA record and receives a reply.
  • Host connects via IPv6.
  • No delays, no A query.

Expected result (parallel, IPv6 preferred)

  • Host requests A and AAAA records simultaneously and receives the AAAA reply.
  • Host connects via IPv6.
  • No delays, A reply is ignored if received.

Alternative result (parallel, first result wins, no protocol preference)

  • Host requests A and AAAA records simultaneously and receives the first reply.
  • Host connects via IPv4 or IPv6.
  • No delays.

Dual-stack to dual-stack with lost AAAA answer

Same as above, except that the AAAA answer is lost by a broken DNS server.

IPv4 connectivity Global or masqueraded
IPv6 connectivity Global
Target DNS Lost IPv6

What is tested

  • Wheter the component reverts to IPv4 in reasonable time when AAAA answer gets lost.

Test flow

TBD

  1. step
  2. another step

Expected result (sequential, IPv6 preferred)

  • Host requests AAAA record and gives up after a delay (e.g. 15 seconds).
  • Host requests A record and receives reply.
  • Host connects via IPv4.

Expected result (parallel, IPv6 preferred)

  • Host requests A and AAAA records simultaneously and receives the A reply.
  • Host gives up waiting for AAAA record after a short delay (e.g. 300 milliseconds).
  • Host connects via IPv4.

Alternative result (parallel, first result wins)

  • Host requests A and AAAA records simultaneously and receives the A reply.
  • Host connects via IPv4.
  • No delay.

IPv4 to dual-stack with lost AAAA answer

Same as above, except that the host doesn't have any IPv6 address except link-local and loopback.

IPv4 connectivity Global or masqueraded
IPv6 connectivity Link-local
Target DNS Lost IPv6

What is tested

  • Wheter the component suppresses AAAA queries when lacking global IPv6 connectivity.

Test flow

TBD

  1. step
  2. another step

Expected result

  • Host requests A record and receives reply.
  • Host connects via IPv4.
  • No delay, no AAAA query.

Dual-stack to dual-stack with lost communication

IPv4 connectivity Global or masqueraded
IPv6 connectivity Global but packets to destination get dropped
Target DNS Dual-stack, DNS server accessed via IPv4

What is tested

  • Whether the component reverts to IPv4 in reasonable time when local or remote network drops all IPv6 communication.

Test flow

TBD

  1. step
  2. another step

Expected result (sequential, IPv6 preferred)

  • Host requests AAAA record and receives reply.
  • Host attempts connecting to IPv6 and times out.
  • Host requests A record and receives reply.
  • Host connects via IPv4

Expected result (parallel DNS, IPv6 preferred)

  • Host requests A and AAAA records simultaneously and waits for AAAA reply.
  • Host attempts connecting to IPv6 and times out, receiving A reply in the meantime.
  • Host connects via IPv4.

Expected result (parallel DNS, parallel TCP, IPv6 preferred)

  • Host requests A and AAAA records simultaneously
  • Host attempts IPv4 and IPv6 connections upon receiving the respective records
  • IPv4 connection is established
  • IPv6 connection is given up after a short delay (e.g. 300 milliseconds)
  • IPv4 connection is used