Unique application-instance scenario and IPv6-enabled applications

A single instance of an IPv6-enabled TCP application can typically handle communications with IPv4 or IPv6 partner applications. IPv6-enabled TCP server applications usually accomplish these communications by using a single AF_INET6 socket to accept connections from both IPv4 and IPv6 clients. As a result, IPv6-enabled applications have some additional configuration considerations when compared to IPv4-only applications, as they require both an IPv4 DVIPA and an IPv6 DVIPA to be configured. If the application is using the MODDVIPA utility or the SIOCSVIPA IOCTL to define the DVIPA, it must be modified as follows:

• If you are using the MODDVIPA utility, an additional set of invocations for this utility is needed to define and delete the IPv6 DVIPA to be associated with the application.
• If the application is using the SIOCSVIPA IOCTL, it must be modified to also issue the SIOCSVIPA6 IOCTL to define and delete the IPv6 DVIPA to be associated with the application.

Applications that are currently relying on defining the DVIPA dynamically by using the bind() socket API or the BIND parameter on the PORT reservation statement have some additional considerations, as a single socket cannot be bound to more than one IP address.

The following options can help alleviate this issue:

• Instead of relying on the bind to trigger the DVIPA definition, the application or configuration can be modified to allow the application to bind to the IPv6 unspecified address (in6addr_any). The MODDVIPA utility can then be used to define and delete both the IPv4 and IPv6 DVIPAs associated with the application.

  Another similar alternative is for the application to issue the SIOCSVIPA or SIOCSVIPA6 IOCTL for both of these DVIPAs. If two or more application instances are to bind their listeners to the same port and the IPv6 unspecified address, each DVIPA can be created with affinity to the application instance that created it. Such affinity ensures that a connection request is sent to the correct listener. A connection request for a DVIPA that is created with affinity is sent to a TCP Listener if the application instance that created the DVIPA issues the bind() call. If no matching listener is available, normal shareport load balancing is used to choose the best available listener. See Configuring the unique application-instance scenario for information about creating a DVIPA with affinity.

• Start two instances of the application, one binding to the IPv4 DVIPA and the other binding to the IPv6 DVIPA, assuming that multiple instances of the same application can be started within the same MVS™ image or across different images in the sysplex. This configuration allows IPv4 clients to reach the application instance that is bound to the IPv4 DVIPA and IPv6 clients to reach the application instance that is bound to the IPv6 DVIPA.
• In some cases, it might be possible to modify the application so that it can create two sockets, one for IPv6 communications and one for IPv4 communications. Each socket can then be bound to the IPv4 or IPv6 DVIPA as appropriate, and a single instance of the application can handle both IPv4 and IPv6 clients. This solution might be less desirable because it also involves application code changes.