I am lucky to have a full dual-stack ISP connection at home. However, the ISP only offers a dynamic IPv6 prefix with all of its disadvantages (while no single advantage). In this post, I am summarizing the limitations of a dynamic prefix and some of the ideas on how to overcome them. I am always comparing the “IPv6 dynamic prefix” state with the legacy “dynamic IPv4 address” situation. I suppose that some of these problems will hit many small office / home office locations during the next years.
Of course, IPv6 ISP connections with dynamic prefixes should only be purchased at private home sites. It is no problem to have new IPv6 addresses there because all connections are outbound. However, many small remote offices (SOHO) might rely on such cheap ISP connections, too. If they provide some servers in a DMZ or other components such as network cameras, building components with IPv6 connections, etc., they will run into these kind of problems.
DNS Changes
One of the biggest problems are the many DNS changes inside the trusted network. If a company provides several IPv6 services that are running on IPv6 nodes, each IPv6 DNS record must be changed to the new IPv6 address in case of a prefix change.
In the case of IPv4, only the router had a single IPv4 address and a “Dyn DNS” service. Several port forwardings were used to reach the servers behind it. In the IPv6 world, every single service/address would require an own dyn DNS name. This might work for some Linux based servers that can run a dyn DNS client, but not for many other appliances such as printers, network cameras, coffee machines, or what ever.
A possible solution for this would be the usage of a DNS server that updates many AAAA records based on a single updated prefix, such as listed here. Currently, this is not widely available at dynamic DNS servers.
Security Policies with DynDNS Ranges
A similar problem is the usage of the dynamic prefix within security policies (ACLs) on other sites. For example, with IPv4 it was possible to have a policy at the headquarter that allows all connections from the single dyn DNS FQDN from the remote office to reach all services inside the network. This is not possible for an IPv6 prefix since there is no DNS type that lists the whole prefix.
Such policies can be used e.g. to manage servers in the DMZ via SSH. The protocol itself is authenticated and encrypted, while it is still desirable to block incoming SSH connections from the whole world into the DMZ. FQDN policy objects can allow these connections.
(Even though the first IPv6 problem concerning the DNS changes would be solved, this won’t help here since all IPv6 clients will have an own and interchangeable IPv6 address that won’t be listed somewhere.)
An option would be the usage of the experimental RFC 3123: A DNS RR Type for Lists of Address Prefixes (APL RR) which has DNS RR type 42. If the ISP router would update this DNS record and if the headquarter firewall could use this type of record, a security policy could be built similar to those on IPv4 FQDN address objects.
Routing inside IPv6 VPN Tunnels
IPv4 site-to-site VPN tunnels always route the other IPv4 networks statically through the tunnel. Both sides (mostly) relied on private RFC 1918 addresses. In the IPv6 world, the site with a dynamic prefix is not reachable via a static route. A dynamic routing protocol must be used.
Luckily, this is the only case that is already solved today. I showed in this blog post how I am using OSPFv3 on a site-to-site VPN tunnel.
Comments?
I am highly interested in comments/suggestions/field reports from other IPv6 adopters. Please use the comment section below!