SSH Reference Manual

TCP/IPv6 Migration and Backout
Start Using TCP/IPv6
After the TCP/IP processes have been prepared for IPv6 support the SSH2 processes can be enabled for IPv6 by
restarting them with parameter IPMODE set to IPv6 or DUAL. The default for this parameter is value IPv4, i.e. the
SSH2 process does not automatically switch to IPv6. This is done because errors would occur when an SSH2 process
starts in IPMODE
IPv6 or DUAL against a TCP/IP process not supporting IPv6. The object the TCP/IP process is
running may not support IPv6 at all ($SYSTEM.SYSnn.TCPIP) or the object may principally support IPv6 but is not
configured for IPv6.
As listed in section "Usage of IPv6 Addresses", various SSH database records can contain IPv6 addresses. These fields
are updated either when sessions are established (USER field LAST-IP-ADDRESS, name field of KNOWNHOST and
PASSWORD entity, ADDRESSES field of KNOWNHOST record) or when the entities are modified via SSHCOM
commands (USER field CI-PROGRAM when configured with “TELNET <ip-address> <port>”) and RESTRICTION-
PROFILE attributes).
It is recommended to make a copy of each RESTRICTION-PROFILE record before adding any IPv6 addresses/patterns
to any of the RESTRICTION-PROFILE records. This can easily be done using SSHCOM command ADD
RESTRICTION-PROFILE with LIKE option, e.g.:
ADD RESTRICTION-PROFILE ABC_copy, LIKE ABC
This step allows a simple way of backing out the IPv6 related changes, in case that is needed.
When multiple SSH2 processes access the same SSH database, then all SSH2 processes should run the same SSH2
object (i.e. either one that supports IPv6 or one that doesn't).
Reverting Back to Pre-IPv6 SSH2 Release
Due to database record versioning there is no change made in the SSH2 database by an SSH2 object with IPv6 support
that would cause problems when an SSH2 object without IPv6 support accesses this database. Therefore a backout of an
SSH2 IPv6 release to a pre-IPv6 SSH2 release does not represent a problem.
Obviously any change to CI-PROGRAM that was made using format "TELNET <ip-address> <port>" with an IPv6 IP
address for the <ip-address> part will no longer work in an IPv4 environment and must be changed back to using an IPv4
address.
Similarly, any changes to RESTRICTION-PROFILE that include IPv6 addresses should be reverted. If a copy of
restriction profiles had been made, then simple rename commands will be sufficient:
RENAME RESTRICTION-PROFILE <active-profile-name>, <saved-IPv6-profile>
RENAME RESTRICTION-PROFILE <saved-IPv4-profile>, <active-profile-name>
For example:
RENAME RESTRICTION-PROFILE ABC, ABC_IPV6
RENAME RESTRICTION-PROFILE ABC_copy, ABC
If there are RESTRICTION-PROFILE records left containing IPv6 addresses/patterns, then these do not represent a
problem: these IPv6 addresses/patterns would just not match when checked against IPv4 addresses being processed by an
SSH2 process without IPv6 support.
IPv6 addresses stored in the ADDRESSES field of KNOWNHOST entities will be ignored by SSH2 processes without
IPv6 support. A KNOWNHOST entry with an IPv6 address as part of the name cannot be modified or removed using an
SSH2 version without IPv6 support but an SSH2 process that supports IPv6 started in ADMIN mode can be used to do
that, if required.
A pre-IPv6 SSH2 process builds the key (name of PASSWORD entry) using an IPv4 address and will therefore not find
any entries containing IPv6 addresses; that is, no change is required when reverting to a pre-IPv6 SSH2 release. Such
HP NonStop SSH Reference Manual Configuring and Running SSH2 • 141