Many network architects have had IPv6 on their to-do list for a while. Periodically, they revisit this topic and ask themselves whether to start the transition to IPv6 now or to postpone it and continue using IPv4 with NAT. While the long term objective should be a transition to IPv6 protocol, there are certain challenges in an uncontrolled transition that can be mitigated by careful planning – I’d like to share my take on these.
But first, I’d like to address a common misconception about IPv6.
Many networking professionals consider IPv6 as a simple evolution of the well-known IPv4 protocol. This, unfortunately, is not 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 behavior of the network. That would be like attempting to implement an IPv4 network architecture over IPX/SPX. That’s why I refer to this as a transition rather than a simple migration.
One last note before moving on to discuss the challenges: it is not recommended to perform a trivial mapping of an IPv4 network to IPv6 – this approach will not yield the benefits offered by IPv6.
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 can practically be considered as unlimited. 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 organizations 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 organization.
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.
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!
This challenge requires special attention when designing your network security.
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, 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.
But IPv6 per essence is intended to provide to each host one or many routable IPv6 addresses and therefore any host is known, thus eventually reachable and exposed to the world.
The control of the perimeter firewall is therefore more critical in IPv6 that it is in IPv4.
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, my first and most 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.
To summarize, transitioning from IPv4 to IPv6 is a complex project with major implications on network security. The transition to IPv6 should be phased: Internet facing environments, then internal public networks, then internal private. The transition will take few years and will require tools that are capable of analyzing threats in a heterogeneous environment with both IPv4 and IPv6 protocols and security tools from multiple vendors.
Don't miss out on more Tufin blogs
Subscribe to our weekly blog digest
