Evangelizing Mainframe
Print Email

Needing That Network Guy

In a recent blog post, Whatever Happened to the Network Guy?, I looked at why organizations need to be thinking about migrating from IPv4 to IPv6. I mentioned the shortage of IPv4 addresses and the fact that IPv6 allows organizations to PUSH information to users. I also mentioned U.S. CIO Vivek Kundra’s ultimatum to U.S. federal organizations to be IPv6-compliant.

I went on to look at issues of security and administration, and real-life difficulties a site might face with conversion work, and with users and applications being IPv4 and IPv6 compatible at the same time. This time I’ll explore some solutions.

The first “solution” is the one that most sites have been adopting for the longest period of time – don’t do anything. Just wait until critical mass is reached and it becomes business critical to make the change. And then throw resources at the problem and make use of lessons learned at other sites to make the change as easy as possible.

The second, and more realistic, solution is to use two TCP stacks on the mainframe—one for normal IPv4 use and one to test the IPv6 settings. So if the new settings don’t work, you can still log in through the old stack and make the necessary changes. This seems the most straightforward answer to the IPv6 problem. Unfortunately, using two or more stacks also has problems:

• Applications must support multiple stacks and not all do.
• Data-sharing issues might arise.
• There may be licensing problems.

The third solution is to use application layer gateways (ALGs). These basically sit on the router connecting the mainframe with the Internet. They work, more-or-less, like the old-style network address translators. There’s no need to worry about changing anything on the mainframe to IPv6. They capture the messages that come in and route them as IPv4 messages to the TCP/IP stack on the mainframe and then to the application. Traffic going the other way is converted from IPv4 to IPv6 before going across the Internet. Many people might feel this doesn’t comply with the spirit of Kundra’s directive requiring all U.S. federal agencies to upgrade their public-facing websites and services by Sept. 30, 2012, to support IPv6 because the end user is still using IPv4.

A fourth, logical, solution to the problem is to place something like an ALG at the users’ end. It could convert their IPv6 desktop address to IPv4 and send that to the mainframe. The results would come back and be converted immediately to IPv6 before arriving with the user. Again, this doesn’t comply with the spirit of the directive because, now, the end user is using IPv6, but the mainframe application still isn’t.

Most mainframers like to keep control of things and don’t want to have to ask the distributed guy for help, so the fourth solution is to take that ALG away from the router and add it as a software layer onto 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 a dual TCP/IP stack underneath it. In this scenario, IPv4 clients could still connect straight to IPv4 applications, and IPv6 clients could still talk directly to IPv6 applications, but where there needs to be a conversion from v4 to v6 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. And it would all take place inside the mainframe environment. And, the use of an ALG should even allow PUSH technologies to work.

There are other issues associated with the use of IPv6 addressing. Not many ISPs currently support it. Routers don’t usually support it. Internal routing at phone companies don’t seem to support it. This means that someone will have to pay for the hardware to be upgraded and new hardware to be installed.

It also means that your smartphone and tablet will have an IP address, and it means that the Internet will have to know where any device is located, in order to deliver PUSH messages. And that means there will be a record of wherever your phone has been!

But someone has to be first to use IPv6, and those network guys have a lot of work ahead of them to make sure everything works seamlessly in what is still a predominantly IPv4 world.

Trevor Eddolls is CEO at iTech-Ed Ltd., an IT consultancy. For many years, he was the editorial director for Xephon’s Update publications and is now contributing editor to the Arcati Mainframe Yearbook. Eddolls has written three specialist IT books, and has had numerous technical articles published. He currently chairs the Virtual IMS and Virtual CICS user groups.

Posted: 1/22/2013 12:01:45 AM by Trevor Eddolls

Print Email

Join Now!