This article was originally published on Technology.Info.
As part of our continuing strategy for growth, ITProPortal has joined forces with Technology.Info to help us bring you the very best coverage we possibly can.
A sneak peak at the “to-do” list of many network architects and I’m sure you’ll see that “transition to IPv6” has remained on there for a while. Many have delayed due to the undoubted security challenges and have continued to use IPv4 with NAT in the meantime. But with a little careful planning these concerns can be mitigated and it can finally be crossed off the list.
Initially it’s best to look at the most common misunderstandings surrounding IPv6. It’s largely thought of by
as an advanced version of the common IPv4 protocol. This couldn’t be further from the reality.
The IPv6 addressing scheme and address allocation mechanisms are primarily different from IPv4. It’s misleading to suggest that the two protocols are forms of IP when they only have the upper layers in common – it’s the underlying mechanisms that differentiate the two considerably. For example it’s impossible to 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 it’s best to think of it as a transition rather than a simple
Challenge #1: IPv6 multi-homing
The fundamental reason for implementing IPv6 was to increase the scarcity of address space of IPv4.
IPv6 consists of so many additional addresses that it’s virtually unlimited and therefore requires special attention when designing your network security.
In a common IPv4 subnet you’ll find a /24 bit mask which corresponds to a total of 254 addressable addresses. A typical IPv6 unicast subnet however has a /64 bit mask which corresponds to 2^64 addresses. In short it’s far larger than the entire IPv4 address space!
This additional space means that the network design for IPv6 alters from its IPv4 predecessor. So in order to reduce and manage the size of the IPv6 Internet routing table, Telcos can own and assign IPv6 prefixes to clients. Therefore the prefixes are easily combined and bound to an ISP or worldwide organisation.
A good example is, 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. It means that you can have one prefix from the first ISP and the other from the second. Additionally a specific host may have two IPv6 addresses, one from each of the providers.
From a security perspective network architects need to factor in that 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. But it could also mean different entry/exit points of the perimeter firewalls of the company! This can cause management issues but by working with security teams when designing your network you’ll be able to spot holes in advance.
Challenge #2: Perimeter Security
The next issue is setting out a clear separation between what is under the company's responsibility and what’s not.
There was a clear separation between what's inside and what is private and public using RFC 1918 (best practice for the Internet community) and IPv4 NAT. That distinction becomes more blurred for some companies that are using non-RFC-1918 IP addresses for their internal network, even if NAT is being used.
Using IPv6 the host offers one (or many) rout-able IPv6 addresses which are public and exposed to the world. The maintain privacy the solution 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 tool-set
The third challenge is that the IPv6 tool-set is not ready and it’s delaying the transition from IPv4. We’re in a situation where manufacturers aren’t developing the toolset for IPv6 support. And at the same time, customers are waiting for the products to be mature enough to be available to deploy.
The key to overcoming this 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. It makes much more sense to transition service one by one.
One way a phased transition can be achieved is by creating an "Internet-facing" IPv6 environment, which opens up the external resources to the world but keeps an internal network on a legacy IPv4 address space. This can be achieved by introducing a proxy-based or IPv6/IPv4 transition gateway as part of the security architecture, allowing internal IPv4 users to access the external IPv6 applications.
Undoubtedly moving from IPv4 to IPv6 comes with major implications for network security. If you phase this transition you’ll be in a stronger position: Internet facing environments, then internal public networks, then internal private. Of course it will take longer (a few years) and will require tools that are capable of analysing threats with both IPv4 and IPv6 protocols as well as security tools but can be done.