IPv6 networking

Caplin Platform 7's DataSource libraries introduce support for IPv6 networking.

You need to read this page if you are deploying Caplin Platform 7 to a network in which hosts have both IPv4 and IPv6 addresses (a dual-stack network).

Contents:

Support for IPv6

Caplin Platform 6.2 supports IPv4 in single-stack and dual-stack networks.

Caplin Platform 7 supports IPv4 and IPv6 in single-stack networks, and IPv4 and IPv6 in dual-stack networks.

IPv6 and IPv4 support
  Single Stack Dual Stack
IPv4 IPv6 IPv4/IPv6
Caplin Platform 6.2  
(IPv4)
Caplin Platform 7.0
(IPv4 and IPv6)

Resolving connectivity issues in dual-stack networks

This section describes connectivity issues that can arise from variations in how DataSource components resolve hostnames in dual-stack networks. You need to read this section if you assign hostnames to either of the DataSource configuration items datasrc-interface and add-peer > addr.

In a dual-stack network, a name resolution query for a hostname will return a list of IPv4 and IPv6 addresses. In circumstances described in this section, one DataSource component may resolve a hostname to an IPv4 address while another DataSource component may resolve the same hostname to an IPv6 address.

This variation in hostname resolution can cause connectivity issues when a DataSource server-socket is bound to a single IP address and one or both of the following conditions are true:

  • a hostname is used to specify the IP address to bind the DataSource server-socket to (datasrc-interface)
  • a hostname is used to specify the IP address that DataSource peers can reach the server-socket at (add-peer > addr).

This section describes the factors that cause variations in name resolution, and then suggests possible solutions to three example scenarios:

Factors affecting name resolution

Whether a DataSource component resolves a hostname to an IPv4 address to an IPv6 address depends on two factors:

DataSource library version

DataSource 6.2 components only support IPv4 and so always resolve a hostname to an IPv4 address. DataSource 7 components, however, may resolve a hostname to an IPv4 address or to an IPv6 address.

This difference in hostname resolution by different versions of DataSource components may be noticed in the following circumstances:

  • On upgrading to Caplin Platform 7, an IP address that previously resolved to an IPv4 address now resolves to an IPv6 address.
  • In a Caplin Platform 7 deployment, a legacy DataSource 6.2 integration adapter resolves a hostname to an IPv4 address that DataSource 7 peers resolve to an IPv6 address.

Rules of IP address precedence

DataSource components delegate name resolution queries to the underlying platform (operating system or runtime). From the list of IP addresses returned, the DataSource component selects the IP address determined by the platform to have the highest precedence. On dual-stack networks, this could be an IPv4 address or an IPv6 address.

Different platforms have different rules of precedence when comparing an IPv4 address and an IPv6 address of equal validity. The table below lists the default rules of precedence for common platforms (your system administrator may have changed the rules of precedence in accordance with your network conventions).

Comparing an IPv4 address and an IPv6 address of equal validity
Platforms that give the IPv6 address higher precedence Platforms that give the IPv4 address higher precedence
Red Hat Enterprise Linux (RHEL) 6 and 7 Oracle Java 8
Microsoft Windows 7 and 10  
Microsoft .NET Framework  
Apple OSX/macOS (see note below)  

Note: some versions of Apple OSX/macOS sort IP addresses by round-trip time when routing statistics are available. This can result in an IPv4 address having higher precedence than an IPv6 address of equal validity.

From the table above, variations in hostname resolution between DataSource 7 components will mainly affect DataSource 7 for Java adapters connecting to Liberator 7 or Transformer 7.

Quick solutions

For a quick resolution, use one of the solutions below:

  • Solution one: avoid connection issues by ensuring that every DataSource server-socket is available at both its host's IPv4 address and its host's IPv6 address. Follow both steps below:
    1. Do not bind DataSource server sockets using the datasrc-interface configuration item.
    2. Use a firewall to restrict which interfaces the DataSource server socket is available on. Ensure that the socket is permitted to receive connections at its host's IPv4 address and its host's IPv6 address.
  • Solution two: avoid connection issues by not assigning hostnames to key configuration items. Follow both steps below:
    1. Only assign an IPv4 address to the configuration item datasrc-interface.
    2. Only assign an IPv4 address to the configuration item add-peer > addr.

If the solutions above are not suitable for your network, continue reading for reference topics and detailed examples with solutions.

Example: DataSource 6.2 for C adapter and Transformer 7

Consider a legacy DataSource 6.2 for C integration adapter on a Red Hat Enterprise Linux (RHEL) 7 host legacy1.example.com initiating a connection to a Transformer 7 server on a RHEL 7 host tr1.example.com.

The integration adapter is configured to initiate a connection to the Transformer server at host tr1.example.com:

add-peer
   remote-label     transformer1
   addr             tr1.example.com
add-peer

The Transformer server is configured to bind its server socket to host tr1.example.com.

datasrc-interface   tr1.example.com

There are two DNS entries for tr1.example.com: an IPv4 address, 192.168.0.10, and an IPv6 address, 2001:0DB8::::::0001.

The adapter's DataSource 6.2 for C only supports IPv4, but the Transformer server's DataSource 7 for C supports both IPv4 and IPv6. DataSource 7 for C will resolve a hostname to the IP address given the highest precedence by the underlying operating system. By default, RHEL 7 gives IPv6 addresses higher precedence than IPv4 addresses of otherwise equal validity.

The connection will fail because the integration adapter will try to connect to the Transformer at 192.168.0.10, and the Transformer's server-socket is bound to 2001:0DB8::::::0001.

There are two possible solutions:

  • Configure the Transformer server socket to bind to the host's IPv4 address 192.168.0.10, not the hostname tr1.example.com.
    • Note: although not included in this example, you must also configure any DataSource 7 for C peers of the Transformer to initiate connections to the Transformer server at the IPv4 address 192.168.0.1, not the hostname tr1.example.com.
  • Leave the Transformer's server-socket unbound, so that the socket can receive connections at all addresses on its host. If access restrictions are required, ask a system administrator to use a firewall to block all incoming DataSource connections to the socket except those with a destination address of 192.168.0.10 or 2001:0DB8::::::0001.

Example: DataSource 7 for Java adapter and Transformer 7

Consider a DataSource 7 for Java adapter on host adapter1.example.com initiating a connection to a Transformer 7 server on a Red Hat Enterprise Linux (RHEL) 7 host tr1.example.com.

The Java integration adapter is configured to initiate a connection to the Transformer server at host tr1.example.com:

add-peer
   remote-label     transformer1
   addr             tr1.example.com
add-peer

The Transformer server is configured to bind its server socket to host tr1.example.com:

datasrc-interface   tr1.example.com

There are two DNS entries for tr1.example.com: an IPv4 address, 192.168.0.10, and an IPv6 address, 2001:0DB8::::::0001.

By default, Java 8 and RHEL 7 have different rules of precedence for an IPv4 address and IPv6 address of otherwise equal validity: Java 8 grants higher precedence to the IPv4 address and RHEL 7 grants higher precedence to the IPv6 address.

The connection will fail because the Java integration adapter will try to connect to the Transformer at 192.168.0.10, and the Transformer's server socket is bound to 2001:0DB8::::::0001.

There are four possible solutions:

  • Configure the Java integration adapter to connect to the Transformer's IPv6 address, 2001:0DB8::::::0001, not the Transformer's hostname tr1.example.com.
  • Configure the Java integration adapter's Java runtime to give IPv6 addresses greater precedence than IPv4 addresses. Add the following line to the adapter's java.conf override file:
    • jvm-options  -Djava.net.preferIPv6Addresses=true
    • For more information, see the DataSource configuration item jvm-options on the Caplin website and the Networking IPv6 User Guide on the Oracle Java website.
  • Configure the Transformer server socket to bind to the IPv4 address 192.168.0.10, not the hostname tr1.example.com.
    • Note: although not included in this example, you must also configure any DataSource 7 for C peers of the Transformer to initiate connections to the Transformer server at the IPv4 address 192.168.0.1, not the hostname tr1.example.com.
  • Leave the Transformer's server socket unbound, so that the socket can receive connections at all addresses on its host. If access restrictions are required, ask a system administrator to use a firewall to block all incoming DataSource connections to the socket except those with a destination address of 192.168.0.10 or 2001:0DB8::::::0001.

Example: DataSource 7 for Java adapter and Transformer 7 (same host)

This example is a variant of the first example.

Consider a DataSource 7 for Java integration adapter and a Transformer 7 server on the same Red Hat Enterprise Linux (RHEL) 7 host, server1.example.com.

The Java integration adapter is configured to initiate a connection to the Transformer server at host localhost:

add-peer
   remote-label     transformer1
   addr             localhost
add-peer

The Transformer server is configured to bind its server socket to host localhost:

datasrc-interface   localhost

The RHEL 7 host has two IP addresses for the hostname localhost: the IPv4 loopback address 127.0.0.1 and the IPv6 loopback address ::1.

By default, Java 8 and RHEL 7 have different rules of precedence for an IPv4 address and IPv6 address of otherwise equal validity: Java 8 grants higher precedence to the IPv4 address and RHEL 7 grants higher precedence to the IPv6 address.

The connection will fail because the Java integration adapter will try to connect to the Transformer at 127.0.0.1, and the Transformer's server socket is bound to ::1.

There are four possible solutions:

  • Configure the Java integration adapter to connect to the Transformer server at the IPv6 loopback address ::1, not the hostname localhost.
  • Configure the Java integration adapter's Java runtime to give IPv6 addresses greater precedence than IPv4 addresses. Add the following line to the adapter's java.conf override file:
    • jvm-options -Djava.net.preferIPv6Addresses=true
    • For more information, see the DataSource configuration item jvm-options on the Caplin website and the Networking IPv6 User Guide on the Oracle Java website.
  • Configure the Transformer server socket to bind to the IPv4 loopback address 127.0.0.1, not the hostname localhost.
    • Note: this solution would potentially create connectivity issues for any DataSource 7 for C adapters connecting to the hostname localhost.
  • Leave the Transformer's server socket unbound, so that socket can receive connections at all addresses on its host. If access restrictions are required, ask a system administrator to use a firewall to block all incoming DataSource connections to the socket except those with a destination address of 127.0.0.1 or ::1.

See also: