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.