Moving Enterprise Network to IPv6

Yoichi Tsukioka
Hitachi, Ltd.



There are three things you want to consider when you IPv6-enable your network.

• Return on investment
  
• Security
  
• Practical method for transition to IPv6

This article discusses the current situations on the above three elements and talks about practical transition method in detail.


Return on Investment

Return on investment is an indispensable element to consider in IPv6-enabling a corporate network. You want some sort of advantages for the investment you make. It is often said that return on IPv6-related investment is not clear. For one thing, IPv4 can serve most of current applications.

Currently, it is hard to find clear advantages of adopting IPv6. But wider and better IPv6 support in networking products is enabling low cost transition to IPv6, especially in regular replacement of network hardware or OS/software updates. You can't IPv6-enable a large corporate network overnight. Ideally, you want to make a step-by-step move to IPv6, so that your entire network will be IPv6-enabled before many people know it in the end.

We can expect that IPv6 will be used by more and more applications such as IP phone, instant messenger, and video phone in the near future. I believe making a move to IPv6 now is well justified.


Security

More security vulnerabilities and viruses and worms are reported these days. Network administrators need to know if transition to IPv6 might make their network more vulnerable.

Anti-virus firewalls and OS/application network updates won't be affected by network layer (layer 3) in principle. Anti-virus firewalls work independent of IPv4 or IPv6. But network configuration may allow input of only IPv4 address, and IP interfaces of the systems may only support IPv4. You will have to confirm on these points with each application. As for IPv6 packet processing by firewalls and IDSes, which deals with network layer protection of the network,, we had no choice but relying on router packet filtering, because no firewalls and IDSes provided IPv6 support. But we are beginning to see more commercial firewalls and IDSes with IPv6 support. We can say that this is not a big issue anymore. (See Commercial Network Security Products with IPv6 Support)

We will be better off accumulating more expertise on firewall configuration, while we want to find a better way to cope with end-to-end and IPsec communications. But we have enough tools to start using IPv6 for specific applications now.


Practical Method for Transition to IPv6

We used to have very limited number of IPv6-enabled products and services. A few products had IPv6 support, but such support was restricted. So, IPv6-enabling a network was a huge task itself. But IPv6-enabling process is not difficult anymore. Current issue is how to move to IPv6 in a straightforward and secure manner.

IPv6 Promotion Council Transition Working Group has come up with IPv6 transition guidelines for various scenarios.

Figure 1 shows a typical IPv6 transition process.


Figure 1 IPv6 transition process (from IPv6 Transition Guideline)

Basically, we can think of two types of transition to IPv6. One is phased IPv6 support for entire network, and the other is building an independent IP-enabled network segment for specific purposes and merging this later with general-purpose organizational network. In each of these two types, there are multiple ways to apply IPv6 transition mechanisms such as tunneling and translators. I will explain the use of tunneling as a low cost and relatively easy IPv6 transition method.

Figure 2 shows a typical corporate network structure, and Figure 3 shows use of tunneling for transition to IPv6.


Figure 2 Typical corporate network structure before IPv6


Figure 3 An example of using tunneling for IPv6 transition

In Figure 3, outside IPv6 connection and perimeter segments (including DMZ) are built independent of existing network. This is to prevent influence on existing IPv4 security configuration. New access line is not connected to internal network as far as IPv4 is concerned. You can use a common access line for IPv4 and IPv6, if you can give your new IPv6-enabled firewall the same IPv4 configuration as your existing firewall.


Tunnel

Ideally, you want to use a dual-protocol connectivity service, but you can start by IPv6 over IPv4 tunnel service as it is lower in cost. For experimental use of IPv6, 6to4 is an even easier method you can use.

Current 6to4 relay router services are not provided for production networking, so you should limit the use of such services to trial only. You may say you can do tunneling between outside tunnel router and internal routers or end user terminals. But current IPv6-enabled firewalls can only recognize tunnel packets (protocol number 41). It cannot check encapsulated IPv6 packets. It is practical to terminate tunneling outside the firewall, and let native IPv6 packets filtered by organizational firewall, from network management point of view.

Ideally, you want to give entire internal network dual protocol support. But that's not easy to do for larger network. You can start by placing a tunnel router on DMZ for quick IPv6 support. If you can IP-enable edge routers for specific segments of the internal network, you can build configured tunnels between DMZ tunnel router and such edge routers, thereby IPv6-enabling the network segment under these routers. If you can put an ISATAP router on DMZ, terminals supporting ISATAP (such as Windows XP SP1) can do direct ISATAP tunneling with DMZ ISATAP router, enabling these terminals to conduct IPv6 communications while internal network remains IPv4 only.


DNS

Existing corporate DNS needs to be given IPv6 support. But at this point, you don't have to worry about IPv6 transport (DNS lookup by IPv6 packets).
When you use ISATAP, you can register ISATAP router resource record to internal DNS, as shown below. It makes ISATAP terminals automatically recognize ISATAP router.

ISATAP IN A "ISATAP router IPv4 address"

In registering AAAA records, you should carefully register working domain name and IPv6 address pairs only. In many IPv6 applications, name resolution is started by making an IPv6 record (AAAA record) query. If it fails, the application would switch to IPv4 record (A record) query.

But at the early stages of IPv6 transition, you may register AAAA records for hosts with no IPv6 support, because you want to allocate IPv6 addresses to all the servers in corporate network. As a result, you enable IPv6 name resolution for servers with no IPv6 transport support, but the servers won't make any response, affecting the performance of existing IPv4 network.


Proxy

In IPv6, you can use proxy servers for Web accesses by user terminals in the same way as its use in IPv4. Many corporate network use proxy servers for access control or better performance through caching. You should build IP-enabled proxy servers. You can use Apache 2 for building proxy servers. Read the following article for building Apache 2 in Windows.

• IPv6 Apache 2.x

If you install an IPv6-enabled (thus, dual protocol) proxy server, IPv4-only terminals can point to this IPv6-enabled proxy and this proxy works as translator, enabling indirect IPv6-based Web access.

IPv6 transition process explained above aims to enable IPv6 networking with the same functionalities as IPv4 networking. In this case, adding IPv6-support doesn't enable particularly secure or free networking environment. It realizes almost the same networking environment as IPv4. If you want to introduce special applications for IPv6, you should consider security implication of the use of such applications, and add firewall configuration for each application, limiting source and destination addresses and used protocol.

For more advanced use of IPv6, such as end-to-end communications and IPsec, we still have to find an adequate security model yet. In such applications, you cannot rely on perimeter defense. Perhaps perimeter defense may need to be supplemented by personal firewalls and other tools, in order to make end user terminals a part of entire security framework. A lot of discussions are going on the next generation network security model for the age of IPv6. A new security paradigm may gradually emerge through diffusion of new applications and accumulation of many IPv6 transition experiences.

Corporate networks are built for practical benefits. There is no need for hasty move to IPv6. But on the other hand, it is true that all major network elements are IPv6-enabled. Gradual move to IPv6 should lead to practical benefits in the end.