Aug 13 ’13

Strategies for Migrating Your Mainframe to IPv6

by Trevor Eddolls in Enterprise Tech Journal

Every device connected to the Internet—such as your smartphone, computer, tablet, even certain high-tech household devices—must be assigned an IP address for identification and location addressing in order to communicate with other devices. With the number of new devices being connected to the Internet rapidly increasing, it’s no wonder IPv4 addresses were predicted to run out.  

We’ve been talking about the cut-over from IPv4 to IPv6 for years now, and it was expected that IPv4 would run out of addresses in late 2011. With that in mind, the federal government set two deadlines for migrating to IPv6:

• All federal organizations must be IPv6-compliant by Sept. 30, 2012. This included public/external facing servers and services, such as Webmail, Domain Name Server (DNS), and Internet Service Provider (ISP) services.
• Internal client enterprise networks were given until the end of fiscal year 2014.

Well, it appears the first date has been largely ignored, much as it was back in 2005, with only a small percentage of Internet traffic adopting the new protocol. And there don’t seem to be any consequences or penalties as a result of not meeting the first mandate. 

So, Why Haven’t Sites Migrated?

IPv6 was formally announced in 1996. There have been various initiatives to encourage people to move to it, such as the World IPv6 Launch on June 6, 2012, and announcements of IPv4 addresses running out throughout 2011. However, many companies don’t see the benefits of migrating, as they already have the IP addresses they need to conduct business. Other organizations have avoided the need to migrate by using techniques such as Network Address Translation (NAT), which lets ISPs and enterprises hide their private network addresses behind a single, publicly routable, Internet-facing IPv4 address.

There are other issues associated with the use of IPv6 addressing. Not many ISPs currently support it, nor do routers or internal routing at phone companies. Even though routers, switches and other networking hardware bought within the last two years are most likely IPv6-capable, ISPs, phone companies and businesses will likely incur huge costs replacing older hardware. According to network testing specialists, Ixia, ISPs and enterprises upgrading their networks to IPv6 are likely to incur costs running into hundreds of millions of dollars.

Managers may have mixed feelings about the fact that since their smartphone and tablet will have an IP address, the Internet will need to know where those devices are in order to deliver PUSH messages. And that means there will be a record of wherever their phone has been! On the other hand, devices can roam among different networks without losing their network connectivity.

In addition, sites may feel that having a public-facing IP address makes them less secure and more open to cyber attack. They may feel that any kind of migration is going to impact their every day activities, which in turn could impact their bottom line. There’s a natural reluctance to embrace change unless there’s an obvious and immediate benefit. As is often the case, when weighing the benefits of a migration, more weight is given to short-term benefits and less weight is given to longer-term ones. This explains why so many sites have yet to migrate to IPv6.

The Benefits of IPv6

The first obvious benefit is there are far more addresses available. IPv6 provides 340 trillion addresses whereas IPv4 provides roughly only 4 billion addresses. Migrating to IPv6 provides these additional benefits:

• IPv6 networks are easier to manage; they provide auto-configuration capabilities and are simpler and flatter. Auto configuration offers the benefit of true out-of-the-box, plug-and-play connectivity. This removes much of the burden currently felt by IPv4 network managers. IPv4 networks must be configured manually or with DHCP. Being simpler and flatter means they’re easier to manage, particularly across large installations. Also, a flat network provides more paths through the network and can maximize bandwidth and promote lower latency, which enhances performance.
• Direct addressing is possible, providing end-to-end connective integrity. The large number of addresses available means there’s virtually no need for NAT.
• Security with IPv6 is so much better than IPv4. Internet Protocol Security (IPSec) is built into the IPv6 protocol and is usable with a suitable key infrastructure. IPSec support was an optional feature with IPv4. IPsec allows authentication, encryption and integrity protection at the network layer.
• IPv6 enables more efficient routing, because routing tables can be so much smaller, and more efficient packet processing, because of IPv6’s simplified packet header.
• IPv6 provides integrated interoperability and mobility capabilities that are already widely used in network devices.
• Multicasting, which allows organizations to send messages to multiple devices at once
• Organizations can push information to their users. For example, your bank could push out a message telling you that your last transaction caused your account to be overdrawn.

How Can You Migrate Your Mainframe?

So, how does a mainframe site change from IPv4 to IPv6? Simply put, all they need to do is edit the BPXPRMxx member in PARMLIB. But life is never really that simple. Each site will have to rewrite their IPv4 definitions and change their routing statements; they can’t use GATEWAY. Rather, they will have to use BEGIN ROUTE. And, of course, the mainframe will need a public IP address. This is a huge change in culture and opens the door to all kinds of security issues.

Currently, sites have their public IP address on a router and NAT handles traffic going to and coming from the mainframe. No one outside the organization knows the mainframe’s IP address, but with IPv6, this potentially changes. A public IP address brings with it a host of security issues: If you want to remain secure, the mainframe can’t use the Internet; but if it does use the Internet, then the mainframe isn’t secure. Quite a conundrum!

There are also staffing and administration issues around the migration to IPv6 because someone needs to administer the new 64-bit internal addresses. That person will need a massive Excel spreadsheet to manage the allocation of thousands of addresses to devices because there needs to be an address range (site unicast address) for each organization. There also needs to be an agreement within the company about a naming convention and whether, in the short-term, every device will retain its IPv4 address and also have an IPv6 address. You might think that the sensible thing to do is incorporate the old IPv4 address as part of the IPv6 address.

If you’re familiar with the IPv4 addresses at your site, incorporating them into the IPv6 address seems to make perfect sense; when you look at the new IPv6 address, you will have some idea of which device it’s referring to and where that device is located. But simply incorporating the old address isn’t as straightforward as it sounds.

Many people are probably unaware that with IPv6, a 192 IP address (which would be a commonplace IPv4 address) turns on a reserved bit, resulting in strange EZZ messages from z/OS Communications Server, which in turn can lead to unpredictable results.

So, in our hypothetical scenario, you’ve made what you think are all the necessary changes to the TCP/IP parameters. Next, you need to restart (reboot) your network to make those changes go live. What do you do if, as the system comes up, you find that you’ve made a mistake? What happens if one of those TCP/IP parameters you specified isn’t quite right? What can you do? The answer, unfortunately, isn’t much, and that’s because you can’t get into the system over the network to make any changes. You will need to find an SNA local terminal and make the changes there.

In a typical scenario, a user talks over the network to a TCP/IP stack on the mainframe and that passes the message to an application. A response then goes from the application through TCP/IP across the network to the user. Simple enough. So, to be IPv6-compliant, you must allow for IPv6 users and IPv6 applications. The trouble is that currently, most end users are IPv4 users and most applications are IPv4 applications. In the short-term, during the transition to full IPv6, you will have a combination of IPv4 and IPv6 users and IPv4 and IPv6 applications. That means IPv6 users can talk to IPv6 applications, but not IPv4 applications; and IPv4 users can talk to IPv4 applications and probably IPv6 applications. Why do I say probably? Because of the address that IPv4 users listen on for a response from the application. Typically, they listen on a Virtual IP Address (VIPA) or a dynamic address, but with IPv6, listening on a specific address doesn’t always work.

So let’s move on from theorizing about how to migrate a mainframe to some practical migration options available to sites.

Five Migration Options

Let’s take a look at several solutions to this migration problem: 

1. Do nothing. This is the solution most sites have been adopting since 1996 when IPv6 was first announced—the ostrich solution. Here organizations just wait until it becomes business-critical to make the change and then throw resources at the problem, make use of lessons learned at other sites and employ experienced staff to make the change as easy as possible.

2. Use two TCP stacks on the mainframe—one for normal IPv4 use and one to test the IPv6 settings. So, if (as in our earlier scenario) the new settings don’t work, you can still log in through the old stack and make the necessary changes. While this may seem like the most straightforward answer to the IPv6 problem, unfortunately, using two or more stacks also has its drawbacks:

• Applications must support multiple stacks and not all do
• There are data sharing issues
• There may be licensing issues.

3. Use Application Layer Gateways (ALGs). These basically sit on the router that connects the mainframe to the Internet and work like the old style NAT. There’s no need to worry about changing anything on the mainframe to IPv6. The ALG captures the messages that come in and routes them as IPv4 to the TCP/IP stack on the mainframe and then to the application. Traffic going the other direction is converted to IPv6 before going across the Internet. Many people might feel this doesn’t comply with the directive requiring all U.S. federal agencies to upgrade their public-facing Websites and services to support IPv6. This is because the mainframe itself isn’t IPv6-compliant, only the router.

4. Place an ALG at the user’s end to convert their IPv6 desktop address to IPv4 and send that to the mainframe. The results would come back and be converted immediately before being sent to the user. Again, this doesn’t comply with the spirit of the directive because even though the end user is now using IPv6, the mainframe application still isn’t.

5. Take that ALG away from the router and add it as a software layer on the mainframe. Picture it as a layer just above the TCP/IP layer and below the applications layer in an LPAR diagram. It would require dual TCP/IP stacks underneath it. In this scenario, IPv4 clients would connect straight to IPv4 applications, and IPv6 clients would talk directly to IPv6 applications. However, where there needed to be a conversion from IPv4 to IPv6 and vice versa, the ALG could handle that. It would let IPv4 desktops easily communicate with IPv6 applications and IPv6 users could continue to use IPv4 applications. It would all take place inside the mainframe environment. And the use of an ALG should even allow push technologies to work. You will notice I said “should” rather than “will.” That’s because this is all new technology and, while the expectation is that push technologies will work, there’s always a chance they might not because of something completely unexpected.

The most obvious strategy for mainframers is to take a serious look at the fifth migration option and find vendors with some experience in this space. It complies with the spirit of the 2012 directive, while at the same time keeping control of what’s happening on and around the mainframe in the hands of those who understand the mainframe technology best.

Conclusion

Even though IPv4 applications will probably be around well into the future, mainframe sites need to start planning now for the implementation of IPv6. Not only does it provide numerous benefits, but staying on IPv4 will eventually become cost-prohibitive. Moving to IPv6 may cost more initially because of new investments, but in the long-term it will cost less because of the increased flexibility and operational aspects if offers.

 

Additional Information: Networking History

Years ago, mainframe sites were happily running Systems Network Architecture (SNA) and using Virtual Telecommunications Access Method (VTAM), along with Network Control Program (NCP) and Synchronous Data Link Control (SDLC) to handle communications. However, the rest of the world started using Transmission Control Protocol/Internet Protocol (TCP/IP), which was originally developed by the U.S. Department of Defense as a way to connect networks from different vendors. IBM sites could use SNA Enterprise Extender (EE), which enabled SNA applications to run over IP networks. EE utilizes IP and Advanced Peer-to-Peer Networking/High-Performance Routing (APPN/HPR) technologies to preserve SNA applications and make use of IP networking. SNA data is encapsulated inside User Datagram Protocol (UDP) datagrams.

All of this, along with using Open Systems Adapters (OSAs), meant the mainframe networking staff was kept fairly busy. But gradually, over time, things became much quieter in terms of planned changes. TCP/IP networks were mainly used. Suitable monitoring and managing software were in place, and gradually sites forgot just how important looking after the network really was.

Not so long ago, most companies had a networking team that wrestled with SNA-related issues. And then, gradually, as sites migrated to TCP/IP, networking issues diminished—and so did the head count. Many sites have managed for a quite a while now with just a systems programmer, as the network has been pretty stable. But now that organizations are faced with migrating to IPv6, they realize they no longer employ a networking specialist.