Evangelizing Mainframe
Print Email

Whatever Happened to the Network Guy?

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 reduced—and so did the head count. Many sites have managed for a quite a while now with just a systems programmer—the network has been pretty stable. But now, IPv6 is not just slide in a PowerPoint presentation, it’s really here. And organizations are going to have to deal with it. And then they realize they don’t have their network guy.

Why should anyone move from IPv4 to IPv6? Two reasons really. Firstly, IPv4 addresses are meant to run out—there are many more devices than there are available addresses, and the 64-bit addressing found in IPv6 will overcome that issue. Of course, we know that many other techniques have been used over the years to extend the life of IPv4. The second reason is that IPv6 allows organizations to PUSH information to users. For example, your bank could push out a message telling you the last transaction made your account overdrawn.

And in the US, there’s a third reason. US CIO Vivek Kundra set a Sept. 30, 2012, deadline for public/external-facing servers and services—such as webmail, Domain Name Server (DNS) and Internet Service Provider (ISP) services—to use native IPv6. At the time, internal client enterprise networks were given until the end of fiscal year 2014 to become compliant. It means that, by now, federal organizations in the US should be IPv6-compliant.

So how do mainframe sites change from IPv4 to IPv6? To start, they make a simple change to the BPXPRMxx member in PARMLIB—and then the “fun” starts. Individual sites will have to rewrite their IPv4 definitions. They’ll have to change their routing statements—they can’t use GATEWAY, they have to use BEGIN ROUTE. And, of course, the mainframe will need a public IP address. Currently sites have their public IP address on a router, and Network Address Translation handles traffic going to and coming from the mainframe. No one outside the organization knows the mainframe’s IP address, but with IPv6, they probably will! And a public IP address brings with it a host of security issues—if you’re secure, the mainframe can’t use the Internet; but if it does, the mainframe isn’t secure. Quite a conundrum!

As well as needing the network guy to deal with the issues mentioned above. Someone is going to have to administer the new 64-bit internal addresses. Someone is going to need a massive Excel spreadsheet to manage the allocation of thousands of addresses to devices, because there will need to be an address range for each organization. These are called site “unicast addresses.” There needs to be an agreement within the company about a naming convention. And the likelihood—in the short term—is that every device will retain its IPv4 address and have an IPv6 address. You might think that the sensible thing is to incorporate the old v4 address as part of the v6 address. If you already know the v4 addresses, you’ll have more of an idea about where that device is when you see its v6 address. But there’s a hidden gotcha in that idea! The number 192 turns on a reserved bit, which produces strange EZZ messages from z/OS Communications Server leading to, what they call, unpredictable results!

So let’s suppose you’ve decided to make all the necessary changes to the TCP/IP parameters. You need to restart networking to make those changes go live—which, pretty much, means a reboot. And as the system comes up you find you’ve made a mistake—the TCP/IP parameters specified aren’t quite right. What happens next? Well, not much, because you lack a working TCP/IP stack, so you can’t get into the system to make any changes! You need to find an SNA local terminal and make the changes from 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, and across the network to the user. Simple enough, but now, to be IPv6-compliant, you have IPv6 users and IPv6 applications. However, at the moment, you typically have IPv4 users and IPv4 applications. And in the short term, you could have a combination of IPv4 and IPv6 users, and IPv4 and IPv6 applications. That means, v6 users can talk to v6 applications, but not v4 applications; and v4 users can talk to v4 applications and probably v6 applications. Why do I say probably? It’s because of the address that IPv4 users listen on for a response from the application. Typically they listen on a VIPA (Virtual IP Address) or a dynamic address, but with IPv6, listening on a specific address doesn’t always work.

Where is the network guy when you need him?!?!

We’ll look at some solutions to the problem of being IPv6 compliant next month.

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: 12/19/2012 1:05:34 AM by Trevor Eddolls | with 0 comments

Print Email

Please sign in to comment.

Sign In


Comments
Blog post currently doesn't have any comments.

Join Now!