Transitioning to IPv6? Here's how to beat the security risks

Look at the "to-do" list for many network architects and there's every chance that "transition to IPv6" has been on there a while. Many have been put off by the undoubted security challenges and have decided to postpone and continue using IPv4 with NAT, at least in the short-term. But with a little careful planning these challenges can be mitigated.

The first thing is to address is the common misconceptions around IPv6. Many networking professionals consider IPv6 as a simple evolution of the well-known IPv4 protocol. This, unfortunately, isn't the case.

The IPv6 addressing scheme and address allocation mechanisms are fundamentally different from IPv4. The fact that the two protocols are referred to as versions of IP is deceiving - in practice, they have only the upper layers in common while the underlying mechanisms differ significantly.

You cannot migrate from one protocol to the other without affecting the behaviour of the network. It's not as easy as undertaking a trivial mapping of an IPv4 network to IPv6 - this approach won't yield the benefits offered by IPv6. That's why I refer to this as a transition rather than a simple migration.

Challenge #1: IPv6 multi-homing

The primary driver for IPv6 was to expand the limited address space of IPv4.

While IPv4 consists of approximately 4 Billion addresses. IPv6 contains so many more addresses that it's practically unlimited and requires special attention when designing your network security.

A typical IPv4 subnet has a /24 bit mask which corresponds to a total of 254 addressable addresses. A typical IPv6 unicast subnet has a /64 bit mask which corresponds to 2^64 addresses. This is by far larger than the entire IPv4 address space!

Based on this larger space, IPv6 offers a different network design. Telcos own IPv6 prefixes that they can assign to their clients (only a few organisations will be eligible for IPv6 prefix registration). This has been done to reduce the size of the IPv6 Internet routing table by having easily aggregated prefixes bound to an ISP or a worldwide organisation.

For example, 2001::/23 may be allocated to a certain service provider and 2001:0200::/23 may be allocated to another. Clients served by both ISPs could therefore have the two IPv6 prefixes, one from the first ISP and the other from the second and a specific host may have two IPv6 addresses, one from each of the providers.

Network architects need to consider that from a security standpoint, the address scheme and multiple prefix could mean that a single machine may be using different routing paths in the network to and from the Internet and different entry/exit points of the perimeter firewalls of the company! By working with security teams when designing your network you'll be able to spot holes in advance.

Challenge #2: Perimeter Security

The second challenge is related to the defining a clear separation between what is under the company's responsibility and what is not.

With IPv4 NAT and the use of RFC 1918 (best practice for the Internet community), there is a clear separation between what's inside and what is private and public. The border is less easily defined for some companies that are using non-RFC-1918 IP addresses for their internal network, even if NAT is being used.

IPv6 provides to each host either one (or many) routable IPv6 addresses which are public and exposed to the world. The answer is to provide more control of the perimeter firewall so you can set a clear barrier between what's inside and outside of your control.

Challenge #3: Maturity of the toolset

The third challenge which is delaying transition to IPv6 is that the toolset is not ready. It is a kind of catch-22 situation where manufacturers do not develop the toolset for IPv6 support while customer are awaiting for the products to be mature enough to be available to deploy and use them into production.

Considering these challenges, one important recommendation is to plan a phased transition. The required effort to perform a full scale transition from IPv4 to IPv6 is by far too complex to be achieved in an uncontrolled manner. A phased approach must be defined to transition the services one by one.

One possible approach is to start a phased transition by creating an "Internet-facing" IPv6 environment, which exposes only the external resources to the world but keeps an internal network on a legacy IPv4 address space.

To do this you will need to implement a proxy-based or IPv6/IPv4 transition gateway as part of the security architecture which will allow internal IPv4 users to access the external IPv6 applications.

Clearly transitioning from IPv4 to IPv6 is a complex project with major implications on network security. The key is the transition to IPv6 should be phased: Internet facing environments, then internal public networks, then internal private. It will take few years and will require tools that are capable of analysing threats in a heterogeneous environment with both IPv4 and IPv6 protocols and security tools from multiple vendors but it's all possible!

Stephane Perez is senior security consultant at Tufin Technologies

Porthole Ad