QA/Networking/Test environment

Test environment

Connectivity checks

Applications may behave differently based on connectivity checks. Those can be performed using the following per protocol characteristics.

• Existence of any IP address (including 127.0.0.1 or ::1
• Existence of non-loopback IP address (including IPv6 link-local addresses)
• Existence of a global IP address
• Existence of a default route (or route for the target we want to reach)

Example: To test application behavior on a host connected via IPv6-only network you should make sure you only have the loopback IPv4 address and that you have a global IPv6 address and a default IPv6 gateway as that what you would normally call an IPv6-only setup. Similarly for IPv4-only setup you would make sure that there are only IPv6 loopback and link-local addresses and that there is a global IPv4 address and a default IPv4 gateway. But there are still many corner cases that may trigger unexpected issues.

IPv4 connectivity

connectivity	details
Global	Host is connected to the Internet using a global IPv4 address.
Masqueraded	Host can access Internet services using a masqueraded private IPv4 address.
Local	Host has a private address with no global connectivity.
Zeroconf	Host has a link-local IPv4 address.
None	Host doesn't have any IPv4 addresses except loopback.

IPv6 connectivity

connectivity	details
Global	Host has at least one link-local address and one global address, the latter being used for global connectivity.
Local	Host has at least one link-local address and one unique local address used for local communication.
Link-local	Client only has a link-local address.
None	Client doesn't have any addresses except loopback.

Target DNS

configuration	A query	AAAA query	notes
Dual-stack	At least one A record	At least one AAAA record
IPv4 only	At least one A record	NODATA
Lost IPv6	At least one A record	Timeout	Typically caused by bad recursive DNS servers
IPv6 only	NODATA	Answer with at least one AAAA record
Multiple IPv4 and IPv6 addresses	At least two A records	At least two AAAA records

Other DNS records typically point to names, not addresses and thus are protocol agnostic but it may still be useful to test e.g. SRV records so that the SRV code path is correct as well.

DNS server IPv4/IPv6 accessibility notes

It usually doesn't matter how recursive servers are accessed, whether via IPv4 and IPv6, the network is expected to be configured correctly.

Authoritative servers inaccessible via one of the protocols is a rather special case important for domain operators. A bad configuration can make otherwise working IPv6 hosts inaccessible from IPv6-only networks with their own recursive servers.

Client software test cases

Dual-stack to dual-stack

IPv4 connectivity	Global or masuqeraded
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.

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 masuqeraded
IPv6 connectivity	Global
Target DNS	Lost IPv6

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):

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

Alternative result (parallel, first result wins):

• Host requests A and AAAA records simultaneously and receives the A reply
• Host connects to IPv4 address
• No delay

Dual-stack to dual-stack with lost IPv6 packets

This test, among other things, shows whether an application can recover from a broken IPv6 connectivity where IPv6 packets are dropped. It works just as well when connectivity is broken on the target network.

Connectivity:

• IPv4 connectivity: Public or masqueraded address
• IPv6 connectivity: Public address but packets are dropped

Target DNS:

• A record: Yes
• AAAA record: Yes

Other:

• Recursive DNS server is on IPv4

Expected result (sequential, IPv6 preferred):

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

Expected result (parallel DNS, first result wins):

• Client requests A and AAAA records simultaneously and receives the first reply
• When the first reply is IPv6, client times out attempting IPv6 connection
• Client connects via IPv4

Expected result (parallel DNS, IPv6 preferred):

• Client requests A and AAAA records simultaneously
• Client waits for the AAAA record
• Client times out connecting to IPv6 address

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

• Client requests A and AAAA records simultaneously
• Client attempts IPv4 and IPv6 connections simultaneously
• IPv4 connection is established, client gives up IPv6 after a short delay
• Client uses IPv4 connection