Native IpV6 support on ZTPF

ORIGINATOR: Chevelle Strobel, Alex Renko
chevelle.strobel@irs.gov, alexander.p.renko@irs.gov,


REQUIREMENT ABSTRACT

z/TPF needs to support an IP Version 6 stack in parallel with IPv4 since the computing industry is moving in that direction.



REQUIREMENT DESCRIPTION

• z/TPF needs to support IP Version 6. Federal Agencies and corporate customers are moving to an IPV6 network and IPV4 will eventually be turned off.
• IPv6 provides for a more scalable and secure architecture. It will be expensive and complex for customers to maintain two networks if z/TPF does not support an IPv6 stack.
• Utilizing NAT64/DNS64 replacement devices in front of a z/TPF host may not work for certain applications because visibility to the end-user's IP address is lost. Applications running through NAT64/DNS64 devices may require modifications.
• Provide appropriate TCP/IP and Socket API's in a standard industry fashion.
• Enhance existing TPF services such as MQ, OpenSSL, Apache, FTP, Mail Server, Tracerte, Ping, and others to work with either IPv4 or IPv6.




PURPOSE/BENEFIT

December 2009 Federal Acquisition Regulation states that any device that connects to the network and uses the Internet Protocol (IP) to communicate must be IPv6 Capable.

Native support of IPv6 on ZTPF will improve the security and stability of the operating system. The world has run out of IP version 4 addresses, and the old protocol does not have the capacity and security features in IPv6.

• IPv6 has vastly larger address space because addresses are 128 bits.
• IPV6 has mandatory inclusion of IP Security (IPsec).
• IPsec can provide cryptographically based services at the IP layer.
• IPv6 has improved authentication, confidentiality, integrity, and access control.
• IPv6 has improved Quality of Service (QoS) support




CRITICAL SUCCESS FACTORS

zTPF will support both an IPv6 and IPv4 stack. Existing programming interfaces and the sockets library will be enhanced to work in either mode, as well as for services such as MQ, OpenSSL, Apache, FTP, Mail Server, Tracerte, Ping, and others.



ALTERNATIVE SOLUTIONS

Maintaining both an IPV4 network along with an IPv6 network is expensive, complex, and impairs security. NAT 6to4 and IP tunnel type solutions require additional security measures such as packet filtering to prevent security attacks. They also carry additional maintenance and operations costs, and administrative overhead. NAT64 work-arounds prevent z/TPF from seeing the ‘real' IP address of the client.

Existing TCP/IP IPv4 library functions used by applications on an IPv6 network will not work without intervention:
1. getpeername()
This function obtains the remote IP address and port values of the connecting system. ZTPF can't obtain or store an IP version 6 128-bit address.
2. inet_ntoa()
ZTPF server applications provide the 32-bit IP address to the function to obtain the dotted decimal notation form of the address, such as ‘175.925.###.###'. It won't be possible to provide a 128-bit IPV6 address to this function.
3. gethostbyaddr()
ZTPF server applications use the function to obtain the host name of a workstation such as ‘hostname.ds.irsnet.gov'. An IPV4 address is passed to the function.
Without some third-party conversion of an IPv4 address to an IPv6 address, the function can't be used to return the name to the application.

• IBM should confirm if Websphere/MQ, z/TPF firewall, FTP, OpenSSL, Apache, and other products available for ZTPF use these functions.

Other Concerns:

• The user will presumably have to configure IPV4 addresses that can be translated to IPv6 addresses possibly using NATT64/DNS64 or a similar scheme.

• Loss of troubleshooting tools like `ZDTCP NSL', ‘ZDTCP tracerte' and ‘ZDTCP ping', probably have visibility only to the NAT64 device.
• NAT64 devices maintain a pool of IPv4 addresses, so reliable reverse DNS lookups from z/TPF may be impossible.
• Using NAT64 devices or Linux LPARS to perform NAT64 translation could have a significant negative impact on performance.
• IBM has stated that the OSA-ICC adapters used by TPF Operations Server, (TOS) are not IPv6 capable.


IPv6 is now the industry standard, and how long the interim IPv4 technology will be maintained or supported by vendors is anybody's guess.


SOLUTION CONSIDERATIONS


There are many RFC's pertaining to IPv6 support, determining which ones are required for zTPF is a project unto itself. At a minimum, support for RFC 2460 (IPv6 specification) and RFC 3513 (IPv6 addressing architecture) would be required. Other RFC's would likely be necessary for zTPF environments.