QA/Networking/Test environment

Connectivity

The following table lists basic IPv4 connectivity configurations. There are numerous less common configuration including a combination of public and private addresses and multiple public addresses.

IPv4 connectivity	Address				Details
	Pub	Priv	LL	Lo
Global	yes	no	no	yes	Host is connected to the Internet using a public address.
Masqueraded	no	yes	no	yes	Host can use services on the Internet using a masqueraded private address.
Local	no	yes	no	yes	Host can use local services using a private address.
Link-local	no	no	yes	yes	Host can use services in the broadcast domain using a link-local address (IPv4LL).
None	no	no	no	yes	Host cannot use services in the

The following table lists basic IPv6 connectivity configurations. There are numerous less common configuration including a combination of public and ULA addresses or public or ULA address without a link-local one.

IPv6 connectivity	Address				Details
	Pub	ULA	LL	Lo
Global	yes	no	yes	yes	Host has at least one link-local address and one global address, the latter being used for global connectivity.
Local	no	yes	yes	yes	Host has at least one link-local address and one unique local address (ULA) used for local communication.
Link-local	no	no	yes	yes	Client only has a link-local address (IPv6LL).
None	no	no	no	yes	Client doesn't have any addresses except loopback.
Disabled	no	no	no	no	IPv6 has been disabled in the kernel.

The following table lists common or somehow interesting combinations of IPv4 and IPv6 connectivity.

IPv4 \ IPv6	Global	Local	Link-local	None	Disabled
Global	Dual-stack server		IPv4 server
Masqueraded	Dual-stack workstation		IPv4 workstation	IPv4/PPP workstation	Disabled IPv6 workstation
Local		Private network
Link-local			Dual-stack zeroconf	IPv4 zeroconf
None	IPv6 node		IPv6 zeroconf	Isolated node

The following table provides details for selected combinations from the previous table.

Scenario	Details
Dual-stack server	Server available on public IPv4 and IPv6 addresses.
Dual-stack workstation	Workstation connecting via both IPv4 and IPv6 internet services.
IPv4 server	Server available on IPv4 with IPv6 limited to link-local and loopback communication.
IPv4 workstation	Workstation connecting via IPv4 with IPv6 limited to link-local and loopback communication.
IPv4/PPP workstation	Mobile workstation connecting via IPv4 with IPv6 limited to loopback communication as IPv4-only PPP won't assign IPv6LL.
Disabled IPv6	Workstation connecting via IPv4 with IPv6 disabled in the kernel.
IPv6 node	Server available on public IPv6 address with IPv4 limited to loopback communication.
Private network	Workstation or server on an isolated private network using IPv4 private addresses and IPv6 ULA for local communication.
Dual-stack zeroconf	Workstation or appliance in a zero configuration network after a failed DHCPv4 attempt.
IPv6 zeroconf	Workstation or appliance in a zero configuration network on a system with IPv4LL disabled.
IPv4 zeroconf	Old-school node in a zero configuration network.
Isolated node	Disconnected node limited to loopback IPv4 and IPv6 communication.

How to get connectivity for everyday use

Most home and office setups offer masqueraded IPv4 connectivity. In addition they often offer global IPv6 connectivity, often firewalled. Some corporate setups, on the other hand, don't offer connectivity to remote hosts except via a proxy server. Global and unmasqueraded IPv4 and IPv6 connectivity for servers is typically available in datacenters.

IPv4 and IPv6 loopback addresses are assigned automatically at boot time. IPv6 link-local addresses are specific in that they are automatically assigned by the kernel when an interface gets connected to a network on the link layer. On the other hand, IPv4 link-local addresses only serve as a fallback for unsuccessful DHCPv4 attempt.

Note: It looks like link-local IPv4 addresses never get automatically configured in default Fedora 23 Workstation with NetworkManager. This is not necessarily a problem as it is much better to rely on ubiquitous IPv6 link-local addresses nowadays.

IPv6 tunnels

Many networks still only have IPv4 connectivity. You can overcome this limitation by configuring an IPv6 tunnel to a network with IPv6 connectivity. You can use various tunnel technologies to achieve that. There are also services like http://www.tunnelbroker.net/ that offer free tunnelled connectivity with IPv6 subnets.

How to emulate connectivity in a virtual test environment

Using two virtual machines, one can emulate any type of IPv4 and IPv6 connectivity by picking up an address block intended for documentation and testing ( 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 and 2001:DB8::/32) and setting up DHCPv4, RA, DHCPv6 and DNS services on one of the virtual machines, while using the other as a client node.

Router

Server always needs to have a valid static configuration. For simple testing, you can configure the server temporarily using iproute package.

# ip address add 192.0.2.1/24 dev eth1
# ip address add 2001:db8::1/64 dev eth1

The easiest way to provide a testing IPv4 and IPv6 configuration server together with a local DNS server is using dnsmasq. The command bellow can be easily transformed into permanent configuration in dnsmasq.conf.

# dnsmasq -d \
    --dhcp-range=lan,192.0.2.100,192.0.2.200,10m \
    --enable-ra --dhcp-range=lan,2001:db8::1:0,2001:db8::2:0,10m

Workstation

A proper workstation installation will get configured automatically.

On the other hand you can test the server configuration using dhcpcd command from the dhcpcd package. Use the following command. If you leave out the -T option, dhcpcd would configure kernel and /etc/resolv.conf using the information from the server.

# dhcpcd -d -T eth0

Notes on connectivity checks

Network application behavior may change based on various connectivity checks. Some of them work with IP addresses, some with routes and some are even based on attempting connections. All of the mentioned types of checks are currently present in glibc name resolution code, so you need to be careful about subtle differences in configuration.

DNS configuration

A dual-stack server is announced in DNS by at least one A record and at least one AAAA record. IPv4 only and IPv6 only servers have only A record or AAAA record respectively. Configurations with multiple A and AAAA records are interesting as well and so are configurations with SRV and other intermediate records.

Key requirements:

• The server must have a known host name
• Authoritative DNS servers must provide the right A/AAAA records
• They should be accessible over both IPv4 and IPv6
• Recursive DNS server must be able to get the records
• Local host must be able to query it and get all the records

The test environment often requires a local recursive and authoritative DNS server. In most cases a dnsmasq instance or any other forwarding nameserver with some authoritative capabilities will do the job. For testing, domains can be chosen under example.net and example.com subtrees.

Configuration examples

Dual-stack server

Using dnsmasq, /etc/dnsmasq.conf follows:

address=/server.example.net/192.0.2.1
address=/server.example.net/2001:DB8::1

Testing with netresolve:

$ netresolve --node server.example.net --protocol raw

Dual-stack server with SRV record

Using dnsmasq, /etc/dnsmasq.conf follows:

srv-host=_http._tcp.example.net,server.example.net,80,10,10
address=/server.example.net/192.0.2.1
address=/server.example.net/2001:DB8::1

Testing with netresolve:

$ netresolve --srv --node example.net --service http --protocol tcp

Common DNS issues

DNS server accessibility

Domain name servers serve different roles. Authoritative servers provide zone data configured by service administrators. Recursive servers retrieve zone data from authoritative servers on behalf of the clients.

Recursive servers are part of the client infrastructure. In a dual-stack network they need to be be available on both IPv4 and IPv6 to also serve single-stack clients using any of the protocols and addresses for both protocols should be announced using automatic configuration protocols. In setups with additinal forwarding DNS servers that do not perform full recursion this applies to those DNS servers that actually serve clients.

Clients			Local DNS
Dual-stack	IPv4 only	IPv6 only	IPv4	IPv6
yes	yes	yes	yes	yes
yes	yes	no	yes	optional
yes	no	yes	optional	yes
yes	no	no	at least one of them

Authoritative servers are part of the service infrastructure. For dual-stack services they need to be available on both protocols in order to serve single-stack recursive DNS servers. For single-stack services they need to be available on the respective protocol.

Service connectivity	DNS records		Authoritative DNS
	A	AAAA	IPv4	IPv6
Dual-stack	yes	yes	yes	yes
IPv4 only	yes	no	yes	optional
IPv6 only	no	yes	optional	yes

All packages providing a DNS server should listen on both protocols by default.

Lost AAAA request or reply

Lost AAAA request is typically caused by the local firewall. Lost AAAA reply may have the same cause but may also be the result of buggy recursive DNS server, authoritative DNS server or a firewall issue on the way between them.

This issue can be simulated by dropping DNS AAAA requests while keeping other requests intact. Unfortunately there seems to be no easy way to do that using conventional firewall. Possible solutions are through delegating the firewall to userspace or using pcap.

TODO: Provide a way to simulate lost AAAA requests/replies.

Note: A similar issue with dropped A records is theoretically possible.

Test cases:

• Lost AAAA request or reply