From Fedora Project Wiki

< QA‎ | Networking

Revision as of 09:32, 14 October 2015 by Pavlix (talk | contribs) (→‎Router)

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.

In most cases you will only need masqueraded IPv4 connectivity and that is the most common way to connect to the Internet nowadays. You can mimic all of the cases above in an isolated testing network by setting up DHCP and DNS servers on one host and configuring the other e.g. using NetworkManager.

How to get IPv4 connectivity

You most often only get actual global connectivity for public servers in datacenters. Beware of corporate setups where you often get global addresses but no connectivity apart from proxy server connections. For most client use cases masqueraded connectivity is sufficient and is typically available in SOHO networks and some corporate environments. You can get local connectivity by connecting to an isolated testing network with a DHCP server. You can very easily achieve none by disconnecting from all networks.

TODO: I have just tested connecting a default Fedora 23 workstation with the goal of getting zeroconf IPv4 connectivity but NetworkManager doesn't set it up. That is not necessarily wrong as we nowadays have link-local IPv6 connectivity which is much more straightforward at least we should document it.


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 only Client only has a link-local address.
None Client doesn't have any addresses except loopback.

In most cases you will either need global connectivity or link-local only connectivity. The latter is typically configured automatically when you connect via IPv4, the former needs to be present in the network. You can overcome this limitation by using an IPv6 tunnel like the one provided by http://www.tunnelbroker.net/. Any of the setups above can be mimicked on an isolated testing network by configuring a router advertisement daemon, an optional DHCP server and a DNS server. You can use dnsmasq to provide all those services at once.

How to get IPv6 connectivity

Only some networks offer IPv6 addresses and only some of them offer actual global connectivity using those addresses. If you are not that lucky to have such a network at hand, you can use one of the many services that offer IPv6 subnets via IPv6 tunnels. For virtually all practical purposes tunnelled connectivity is equivalent to native one. Getting local connectivity is not different from IPv4. On the other hand, you get link-local IPv6 connectivity automatically when connected to a physical ethernet or wireless ethernet network and it is usually kept through the physical connection lifetime unline IPv4 zeroconf addresses. It is normally enough to connect two client machines using a cable to get it.

TODO As far as I know NetworkManager also supports disconnected IPv6 configuration where you don't even have link-local addresses but that needs to be tested first.

IPv4 and IPv6 connectivity combinations

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

IPv4 \ IPv6 Global LL Only None
Global Dual-stack server IPv4 only server Disabled IPv6
Masqueraded Dual-stack workstation IPv4 only workstation IPv4 only workstation on PPP
None IPv6 only IPv6LL only No connectivity

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 iproute2 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.

If you just want to check functionality of the router, install dhcpcd and run the following command. Without -T it would configure kernel and /etc/resolv.conf.

# 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. 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 not accessible over IPv4 or IPv6

Recursive servers need to be accessible over one of the protocols supported by the client machine. Therefore if a network serves both IPv4-only and IPv6-only hosts, the recursive name server must be accessible via both protocols and addresses for both protocols must be advertised via automatic configuration protocols.

Authoritative servers need to be accessible over one of the protocols supported by the recursive server. When the condition for recursive servers is met, you can generally assume the recursive server will talk the same protocols the client does. Therefore an authoritative server serving A records should generally be available at least over IPv4 and one serving AAAA records should be available at least over IPv6. An authoritative server serving records for dual-stack servers should therefore be dual-stack as well.

It is therefore important that all DNS server packages are available 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: