QA/Networking/Test environment

Configuration

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

Public address

Client has a public IPv4 address and connectivity.

Masqueraded address

Client has a private address and the local network provides IP masquerading (aka NAT). For most client purposes this is equivalent to a public address.

Isolated private address

Client has a private address and global connectivity is not provided.

Link-local address

Client has a link-local IPv4 address from the 169.254.0.0/16 range instead of a global address.

None

Client doesn't have any IPv4 addresses except loopback.

IPv6 connectivity

Public address

Client has a public IPv6 address and connectivity. Client also has a link-local address as this is the standard situation with IPv6.

Public address without link-local

Client has a public IPv6 address and connectivity but no link-local address. This setup is used by some container solutions.

Link-local only

Client only has link-local addresses (starting with fe80) and the loopback address.

None

Client doesn't have any IPv6 addresses except loopback.

Target DNS records

You need to carefully choose a target hostname for dual-stack networking tests.

Examples of scenarios:

• Hostname with a single A record or a single AAAA record
• Hostname with one A record and one AAAA record
• Hostname with multiple records per family, some of which are obsolete and inacceessible

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.

IPv4 and IPv6 recursive DNS servers

This is entirely orthogonal to IPv4 and IPv6 DNS records and doesn't cause many issues.

IPv4 and IPv6 authoritative DNS servers

This 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

This test, among other things, shows whether IPv6 is preferred and whether sequential or parallel name resolution is used.

Connectivity:

• IPv4 connectivity: Public or masqueraded address
• IPv6 connectivity: Public address

Target DNS:

• A record: Yes
• AAAA record: Yes

Expected result (sequential, IPv6 preferred):

• Client requests AAAA record and receives reply
• Client connects to IPv6 address
• No delays, no A query

Expected result (parallel, first result wins):

• Client requests A and AAAA records simultaneously and receives the first reply
• Client sometimes connects to IPv4 address, sometimes to IPv6 address
• No delays

Expected result (parallel, IPv6 preferred):

• Client requests A and AAAA records simultaneously
• Client waits for the AAAA record
• Client connects to IPv6 address

Dual-stack to dual-stack with lost AAAA answer

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

Connectivity:

• IPv4 connectivity: Public or masqueraded address
• IPv6 connectivity: Public address

Target DNS:

• A record: Yes
• AAAA record: Lost by a broken DNS server

Expected result (sequential, IPv6 preferred):

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

Expected result (parallel, first result wins):

• Client requests A and AAAA records simultaneously and receives the A reply
• Client connects to IPv4 address

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

IPv4 to IPv4

This test, among other things, shows whether unneeded AAAA queries are suppressed from IPv4-only clients.

Connectivity:

• IPv4 connectivity: Public or masqueraded address
• IPv6 connectivity: No

Target DNS:

• A record: Yes
• AAAA record: No

Expected result:

• Client requests A record and receives an answer
• Client connects to IPv4 address
• No delays, no AAAA query

IPv4 to dual-stack

Connectivity:

• IPv4 connectivity: Public or masqueraded address
• IPv6 connectivity: No

Target DNS:

• A record: Yes
• AAAA record: Yes

Expected result:

• Client requests A record and receives an answer
• Client connects to IPv4 address
• No delays

IPv4 to IPv6

Connectivity:

• IPv4 connectivity: Public or masqueraded address
• IPv6 connectivity: No

Target DNS:

• A record: No
• AAAA record: Yes

Expected result:

• Client requests A record and receives NODATA error
• Client reports an error
• No delays