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.
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.