Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
Application awareness of whether system is IPv6 enabled z/OS Communications Server: IPv6 Network and Application Design Guide SC27-3663-00 |
|||||
A z/OS® system might or might not be enabled for IPv6 communications. Enabling a z/OS system for IPv6 support requires explicit configuration by the system administrator to allow AF_INET6 sockets to be created. As a result, an application cannot typically assume that IPv6 is enabled on the systems where the application is running. Some exceptions do exist. For example, applications can run on a limited number of systems that are known to be IPv6 enabled. However, in general, most applications that are being enhanced to support IPv6 must first perform a runtime test to determine whether IPv6 is enabled on the system where they are executing. If the system is not enabled for IPv6, the application should proceed with its existing IPv4 logic. If the system is enabled for IPv6, the application can now use AF_INET6 sockets and features to communicate with both IPv4 and IPv6 applications. Determine if a system is enabled for IPv6 by attempting to create
an AF_INET6 socket. If this operation is successful, the application
can assume that IPv6 is enabled. If the operation fails (with return
code EAFNOSUPPORT) the application should revert to its IPv4 logic
and create an AF_INET socket.
The getaddrinfo() API is an alternative mechanism that can be used
by TCP/IP client applications to determine whether IPv6 is enabled.
This API is a replacement for the gethostbyname() API and is typically
used by TCP/IP client programs to resolve a host name to an IP address.
For example, a client application that receives the server application's
host name or IP address (such as FTP) as input can invoke the getaddrinfo()
function before opening up a socket with a selected set of options.
This allows the application to receive a list of addrinfo structures
(one for each IP address of the destination host) that contain the
following information:
A client application can be coded with this information in a manner that allows it to be protocol-independent without having to perform specific runtime checks to determine whether IPv6 is enabled and without having to have dual-path logic (IPv4 versus IPv6). The following application is an example of this approach: Figure 1. Example of protocol-independent
client application
When this example executes on a system where IPv6 is not enabled, only IPv4 addresses are returned in AF_INET format (in sockaddr_in structures). When this identical example executes on an IPv6-enabled system, both IPv4 and IPv6 addresses are returned, and the IPv4 addresses are returned in IPv4-mapped IPv6 address format (in sockaddr_in6 structures). Note that an AF_INET6 socket can be used for the connection even when the address returned by getaddrinfo() is an IPv4-mapped IPv6 address. |
Copyright IBM Corporation 1990, 2014
|