Single Stack and Dual Stack Networks

Single Stack Networks

We have a lot of experience with single stack networks running IPv4. We've been doing it since 1983. There are a few situations today where a single stack network running just IPv6 might work, such as several thousand environmental sensors in a smart building.

Single stack networks are fairly simple to manage, since there is only one IP family involved. You need only one flavor of DHCP (not both), your DNS server only needs to worry about one type of address resource record (A or AAAA but not both), and you only need reverse zones for one IP family (IPv4 or IPv6 but not both).

One advantage of a single stack network is that the network administrator only needs to understand one IP family. A big advantage is that the "attack surface" is smaller than in a dual stack network (there are fewer points where a hacker can attack your network). The firewall configuration (on both the border gateway and host-based firewalls) is simpler because only one set of rules is required (IPv4 or IPv6 but not both).

An IPv6-only network is "cleaner" than any network that includes IPv4 (IPv4-only or Dual Stack), since there won't be any broadcast packets, and no ARP. It is also more robust because of Neighbor Unreachability Detection (NUD). It is also trivial to allow incoming connections to any node (subject to rules in the border and/or host-based firewalls).


Dual Stack Access to External Nodes from Nodes in a Single Stack Network

Just because your network is single stack, doesn't mean the nodes in it can't access external nodes running both IP families (IPv4 and IPv6). There are two approaches to allowing this: node-based tunnels and network-level translation.

The first approach involves individual nodes in the single-stack network building tunnels to external tunnel end-points that have access to the other IP family's Internet. For example, a node in an IPv4-only network can use Teredo, ISATAP, 6to4 or various other schemes to access external IPv6-capable nodes via a tunnel that crosses the network's border gateway and terminates at each node. This is difficult to secure, unless your border gateway knows how to look inside of possibly several different tunnel mechanisms (most don't). For the most part, these nodes could be sending anything to external sites, and could be attacked from external sites right through your firewall. Most node-based tunnel schemes provide no protection of any kind. You have opened a hole right through your secure front door and are letting anything come in and go out through it. Your firewall can't even see the traffic in the tunnel, let alone filter it. In general it is a bad idea to allow tunnels to cross your border gateway. They should always terminate at the border, with a firewall controlling everything going out or in the tunnel endpoint. A good firewall today should prevent all tunnel mechanisms from crossing it to internal nodes, by default (but it should be possible to override this).

This is especially important if you have Windows Vista (or later) nodes in your network, since they enable several automatic tunnel mechanisms by default. In particular, Teredo doesn't require any configuration. It just works. Fortunately, if you node belongs to a Microsoft domain, by default Teredo is disabled. If it is a standalone node, or a member of a workgroup, by default, Teredo is enabled and just works. There is no simple obvious way to disable it. With Windows out-of-the box, you must issue a netsh command to do this, unless you have my NetConf GUI utility, which makes it really easy to see whether any of the three tunnel schemes are enabled, and to disable them if desired, with point-and-click ease.

The better approach is to provide IP translation at the border gateway (or even "in the cloud") that can translate outgoing traffic to the other IP family (e.g. IPv4 to IPv6) and then re-translate it on the way back in to the native IP family (e.g. IPv6 to IPv4). This can be done at the Internet Layer (L3) with NAT64/DNS64, but this is difficult to set up and it has many problems. One of the issues is that nodes using NAT64 must use a nonstandard DNS server (a DNS64 server). See coverage of NAT64/DNS64 later in this section.

A better approach is to provide an Application Layer (L7) Proxy that can accept outgoing connections using the native IP family (e.g. IPv4) and make an ongoing connection using the other IP family (e.g. IPv6). On the way back in, it can translate the response (e.g. over IPv6) to the native IP family (e.g. IPv4). There are no issues with this like there are with NAT64/DNS64 (only standard DNS is used at all points). However, being at Layer 7, a different proxy server is required for each protocol to be translated. Sixscape sells a Layer 7 translating web proxy called SolidProxy. It can allow nodes in either an IPv4 single stack network, or nodes in an IPv6 single stack network use external nodes of either IP family transparently. It does require setting the "proxy address" on all internal browsers to point to the proxy server. The proxy server can be installed at the network border (like a NAT64 translator), but it can also be anywhere "in the cloud", e.g. at a co-location facility that has dual stack service (NAT64 cannot be deployed like this). Also, SolidProxy can obtain access to the other IP family internet via a tunnel. NAT64 can only translate from IPv6-only clients to external IPv4 servers, which is not the situation normally found. SolidProxy can provide dual stack access to nodes in IPv4-only or IPv6-only single stack networks. It can also do reverse proxy to allow internal IPv4-only (or IPv6-only) web servers to be accessible by external nodes via either IPv4 or IPv6. Of course the SolidProxy unit must have a public IPv4 address for this to work (another reason to deploy it at a co-location facility).


The Advantage of IPv6-only Networks Translation

Soon you may see some network administrators remove all IPv4 in the local network, and run IPv6-only internally. As we stated above, it is simpler and less expensive to manage a single stack network. IPv6 is inherently more stable, cleaner, more reliable and can be made more secure (if the network administrator is IPv6 savvy). This is especially true if there is no IPv4 also running on the network. Every node has real public addresses - no NAT to worry about. With a translator like SolidProxy available, IPv6-only browsers can be configured with the IPv6 address of SolidProxy as their "proxy address", and access legacy sites transparently. They make an outgoing connection over IPv6 to SolidProxy, it finds the IPv4 address of the site via DNS, and connects to it over IPv4. The response comes from the target server to SolidProxy over IPv4, and is relayed to the original browser over IPv6. Most users will have no idea that they don't have any IPv4 address or connectivity, unless they use the ipconfig command.

One type of network that will likely be IPv6-only is one consisting of smartphones and tablets (or even notebooks) that use real 4G (LTE Advanced, not LTE, which is "3.9G") for their Internet connectivity. A SolidProxy unit could be deployed to allow these nodes to access legacy IPv4 websites as if those nodes had IPv4 addresses and connectivity themselves.


Dual Stack Networks

The IETF recommended strategy for introducing IPv6 into existing legacy IPv4-only networks is dual stack. This means adding new infrastructure (or upgrading old infrastructure) as required to support IPv6 in addition to the existing IPv4. All Layer 3 devices, such as routers, firewalls and Layer 3 ("smart") switches must be upgraded or replaced with dual stack units if they don't already support it. Most equipment bought in the last 5 years probably includes support for IPv6, in which case only configuration is required. In most cases, upgrades for older devices are already available. In some cases (e.g. insufficient ROM or RAM to hold new version that supports IPv6) this will involve a "fork lift" upgrade (dump the old unit, buy a new one). You should make sure a border router or firewall contains a configurable source of Router Advertisements, and that the firewall allows configuration of rules for both IPv4 and IPv6.

If you don't have native dual stack service available, you need to have a border router or firewall that includes one or more tunnel mechanisms. If you have a public IPv4 address (could be the same one used for Hide-Mode NAT44), that is sufficient. In that case, you should configure a manual 6in4 tunnel. Most dual stack router/firewall units include this support. If you have only private addresses, you may need TSP or 6rd tunnel support in the border firewall or router. Fewer units support these tunnel mechanisms. You will also need a source of tunneled IPv6. To begin with, you can use free tunneled IPv6 service (e.g. from Hurricane Electric).

If DNS and/or DHCP are provided by appliances, most recent units have support for IPv6, or can be upgraded. If these services are provided by software (on *NIX or Windows Servers), recent versions already fully support IPv6, and upgrades are readily available. If you are still using Windows Server 2003, it is time to upgrade to at least Windows Server 2008 R2.

Any network management system (SNMP, IPAMS) should be verified to support IPv6. SNMP v2c and v3 already support IPv6. Unfortunately most existing IPAMS systems have very poor support for IPv6, due to their design and dependence on DHCP to push out configuration from a central server.

You will need to configure internal servers (DNS, DHCP, web, email, etc) to support dual stack, but initially users can continue web and email over IPv4. In many cases, once the server has been made to support dual stack, the services on it will run dual stack. There may be minor configuration changes required.

Layer 2 ("dumb") switches are IP agnostic (they will run IPv4 and IPv6 equally well, since they work below the Internet layer). Likewise, NICs and network cables already work with both IPv4 and IPv6.