IP version considerations for cells

There are compatibility issues to consider when configuring the IP version for cells.

(iseries) Support for Internet Protocol Versions

The product supports Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6). IPv6 support was introduced with IBM i release V5R4, and although WebSphere Application Server V6.0 only supports IPv4, when running on V5R4 and later releases of IBM i, WebSphere Application Server V6.1 and later support IPv4 and IPv6. When defining a node, specify the host name as a string or as a 32-bit numerical address.


Support for Internet Protocol Version 4 and Internet Protocol Version 6

Internet Protocol Version 4 is no longer viable for many businesses. Because it is based on 32-bit architecture, there is a growing shortage of Internet Protocol Version 4 (IPv4) addresses. Internet Protocol Version 6 (IPv6) is based on 128-bit architecture, which allows a far greater number of addresses to be available for use over the Internet.

In response, the product now includes support for IPv6, in addition to continued support for IPv4. This means that nodes running WAS v6 and later can use IPv6. However, note that nodes running WebSphere Application Server Version 5.x cannot use IPv6.

The product supports a dual mode environment in which we can have older legacy applications running on IPv4 and IPv6-enabled applications running on IPv6. Note, however, that there are restrictions on using IPv4 and IPv6 in the same cell. This information documents those restrictions as well as outlines the ways in which we can set up the cells, depending on the version of IP that you will be using.

IPv6 is not supported on native transports. If we need this function, configure a channel chain. Channel chains may not be configured automatically for a server migrated from WebSphere Application Server V5 to WebSphere Application Server V6. Channel chains are automatically configured when creating a V6 server.

When defining a node, specify the host name as a string or as a 32-bit numerical address.


Dual mode cell

In a dual mode cell, mixed IPv4 and IPv6 communications are supported. By default, a cell is set to dual mode when it is created. Note, however, that only nodes running WAS v6 and later are valid in a dual mode cell.

The deployment manager can manage both IPv4 and IPv6 nodes. Application servers can listen to both IPv4 and IPv6 communications.

IPv4 and IPv6 nodes cannot communicate with each other, so the purpose of the dual mode cell is to enable this communication, thereby allowing you to use your existing applications, running over IPv4, with newer applications that have been enabled for IPv6.

The following illustration shows a dual mode cell:


IPv4-only cell

In an IPv4-only cell, all nodes must:

It is important to note that, by default, a cell is set to dual mode. However, in order to run in an IPv4-only environment, you will need to explicitly set the cell to IPv4. See the topic on JVM settings for more information.

To run a combination of WAS Version 5.x and WAS v6.0 or later nodes over IPv4, see the section on setting up a mixed node cell, below.


Mixed node cell

A mixed node cell consists of some nodes running WebSphere Application Server Version 5.x and other nodes running WAS v6 or later. In a mixed node cell, all nodes must use IPv4. When defining a node that will be used in a mixed node cell, specify the host name as a string or as a 32-bit numerical address, regardless of whether the node is running WebSphere Application Server Version 5.x or WAS v6 and later, 128-bit numerical addresses cannot be specified.

In a mixed node cell, even though the WAS v6 and later nodes will be configured to use IPv4, the operating system running on them can still support both IPv4 and IPv6. This is true as long as the Version 6 and later nodes are configured with string-based host names or 32-bit numerical addresses.

Note also, that we can only add Version 5.x nodes into a mixed node cell through migration. You first need to migrate from a Version 5.x dmgr to a Version 6.0 or later dmgr, and then either keep the Version 5.x nodes or migrate them to Version 6.0 or later nodes.


IPv6-only cell

In an IPv6-only cell, all nodes must:

(iseries) Specify host names

When creating a new profile, we can optionally specify the host name for the profile using the -hostName parameter. If we do not specify the host name, the host name for the profile defaults to the fully qualified host name for the server. If we choose to use the -hostName parameter and want to specify the IP address for the server, specify the valid 32-bit numerical address.


Specify host names

During profile creation for WebSphere Application Server, you are asked to provide the host name or IP address of the machine on which the profile is being created in the Host Name or IP address field. The host name or IP address specified is used to advertise this profile to all other WebSphere Application Server profiles in the cell configurations. All nodes in the cell will use the host names or IP addresses defined in this way to reach each other. In general, it is best to always use a host name to identify a profile. By using a host name, you will not have to be concerned about which IP address is being used (32-bit versus 128-bit), whether it runs on IPv4 or IPv6, and so on. As long as the DNS service is properly configured, the nodes should all be able to work together.

However, if you prefer, we can control which IP stack or address is used. To do this, enter the specific IP address (32-bit for IPv4 or 128-bit for IPv6) into the Host Name or IP Address field. This profile will then be identified with this IP address and other WebSphere Application Server nodes will use this IP address to communicate with this node.

When specifying IPv6 addresses, it is good practice to surround them with protective square brackets. For example, [fe80::202:57ff:fec4:2334]. The reason for this is that in system internal processing, IP addresses are often combined with port numbers in the form of <IP address>:<port number> , and the colons in IPv6 addresses could be confusing in such circumstances. However, note that we cannot use IPv6 addresses that are surrounded by square brackets within the console or the Profile Management Tool.

Note that the use of IPv6 (Internet Protocol Version 6) and WS-AT (Web Services Atomic Transactions) are not supported on HTTP transports; they are only supported on HTTP transport channel chains.

Note that in scripting, the square brackets might have special meaning, depending on the language binding used (for example, Jacl). We can work around this problem by using a special escape character in front of the opening and closing brackets. Using the Jacl binding, for example, the same IPv6 address cited earlier can be entered as \[fe80::202:57ff:fec4:2334\]

While we cannot use square brackets with IPv6 addresses within the console, use square brackets to specify an IPv6 address as part of the administrative console's URL in a browser. This allows the browser to distinguish the IPv6 address from the port value.


Multicast configuration

(iseries) The product uses multicast broadcasting at the node level to allow a node agent to discover the managed processes in the node. IPv4 and IPv6 addresses are not compatible. Therefore, to allow a WAS node to run after initial installation, both IPv4 and IPv6 multicast addresses are initially defined in the node agent configuration, and when a node agent starts, both addresses are tried in sequence. Delete the NODE_IPV6_MULTICAST_DISCOVERY_ADDRESS address after installation because, by limiting the multicast discovery to the known protocol, the node agent runs more efficiently.

(dist) The product uses multicast broadcasting at the node level to allow a node agent to discover the managed processes in the node. IPv4 and IPv6 addresses are not compatible. Therefore, to allow a WAS node to run after initial installation, both IPv4 and IPv6 multicast addresses are initially defined in the node agent configuration, and when a node agent starts, both addresses are tried in sequence. Delete either the NODE_MULTICAST_DISCOVERY_ADDRESS address or the NODE_IPV6_MULTICAST_DISCOVERY_ADDRESS address after installation. By that time, you should know whether the node is running IPv4 or IPv6, so limiting multicast discovery to the known protocol, the node agent runs more efficiently.

The configuration of the multicast address depends on whether the cells have the same or different cell names. The following conditions apply:


Related tasks

  • Delete the Internet Protocol Version 4 or the Internet Protocol Version 6 multicast port

  • Java virtual machine settings