Migration Considerations and
Release-to-Release Changes
The information herein describes changes to various aspects of TCP/IP
for z/VM that warrant consideration when migrating from previous
levels to the most current, supported level.
For information about changes that have been implemented in
levels of TCP/IP for z/VM that are not listed here, check the
Migration Considerations for
End-of-Service Levels
information.
Note that in a some cases, existing functions may have been deleted or
replaced by alternate functions. High-level descriptions of these
kinds of changes, as well as the level at which a change was introduced,
are indicated in the text that follows.
Client Topics:
Server Topics:
Other Topics:
Notes:
-
TCP/IP and related features are supported on associated releases of CP
and CMS only.
-
(
)
Select the TCP/IP
Stack server link to review information about changes
introduced that establish changes to the following defaults:
Changes Introduced in TCP/IP Level 530
-
The level of authorization to use the TRACERTE command has changed.
OBEY authority is no longer required to use this command.
-
The Telnet and FTP clients have been updated to accommodate Dynamic
SSL/TLS support. Changes to provide this capability include support
for additional command options, which include:
- CERTFULLCHECK
- CERTNOCHECK
- NOSECURE
- SECURE
-
A new statement, SECURETELNETCLIENT, may now be specified in
the TCPIP DATA file. This statement provides the default Telnet client
security value to use when neither the SECURE nor NOSECURE option is
specified on the Telnet command.
-
Due to changes in CMS resolver code, there is a requirement that some
TCP/IP modules such as FTP be at the 5.3.0 level when the CMS IPLed is
5.3.0. For this same reason, customer-built modules that include
COMMTXT in the GLOBAL TXTLIB command (in order to use routines such as
SayIntAd) must be re-built using the z/VM 5.3.0 level of
COMMTXT. In addition, some TCP/IP modules require Language
Environment (LE) to include APAR VM64055.
Note that the following message will appear if either a TCP/IP routine or
LE is back-level:
DMSZER2571E A resolver request failed due to missing LE support or
incorrect TCP/IP module levels.
To work around this problem, upgrade TCP/IP and LE and re-build programs
that use COMMTXT or IPL an earlier level of CMS.
Changes Introduced in TCP/IP Level 520
-
The IPFORMAT diagnostic utility has been added. This utility
can be used to analyze LAN traffic captured via the CP TRSOURCE
command, as well as data captured using the TCP/IP server packet
tracing facility (which makes use of existing PACKETTRACESIZE
and TRACEONLY configuration statements). A related sample
program, PKTTRACE, is also included. This program may be used
as an aid in gathering TCP/IP server packet trace data, and preparing
this information for use as input to IPFORMAT.
-
The content of the ETC SERVICES sample file (ETC
SAMPSERV) has been revised such that port number assignments
reflect current assignments as listed by the
Internet Assigned Numbers Authority (IANA).
Changes Introduced in Prior Levels
Top of Page
Changes Introduced in TCP/IP Level 530
Changes Introduced in Prior Levels
Top of Page
Changes Introduced in Prior Levels
Top of Page
Changes Introduced in TCP/IP Function Level 520
-
The various sample EXEC files provided with TCP/IP for z/VM are now
supplied with a file type of SAMPEXEC instead of the
previously-used file type of SEXEC.
Changes Introduced in Prior Levels
Top of Page
Changes Introduced in Prior Levels
Top of Page
Changes Introduced in TCP/IP Level 530
Changes Introduced in Prior Levels
Top of Page
Changes Introduced in Prior Levels
Top of Page
Changes Introduced in Prior Levels
Top of Page
Changes Introduced in TCP/IP Level 530
Top of Page
Changes Introduced in TCP/IP Level 520
-
The NETSTAT command has been updated to accommodate the
reporting of IP network masks using BSD-style and Classless
Inter-Domain Routing (CIDR) notation in results produced by the
NETSTAT HOME and NETSTAT GATE commands (as dictated by the notation
used for the TCP/IP (Stack) server HOME and GATEWAY
configuration statements).
-
A new CONFIG option has been added to allow NETSTAT to query
stack configuration information.
Changes Introduced in Prior Levels
Top of Page
Changes Introduced in TCP/IP Level 530
-
The MPRoute server implementation of TCP/IP for z/VM has been adapted
from z/OS V1.8.
-
A combination of an ip_address and a subnet_mask that
describes either a subnet address or a broadcast address, is no longer
accepted for the OSPF_INTERFACE, RIP_INTERFACE or
INTERFACE configuration statements. This change is a result of
TCP/IP server enforcement of RFC rules that restrict a subnetwork
broadcast or network address from being used as a host address.
By convention, an address that has all ones in the host
portion is a subnet broadcast address, whereas an address
that has all zeros in the host portion is a subnet
network address. Therefore, an attempt to use an
ip_address and subnet_mask combination that specifies
one of these special addresses will likely lead to difficulty in
communicating with other hosts on the network.
-
The maximum mtu value that may be specified for the
OSPF_INTERFACE, RIP_INTERFACE or INTERFACE
configuration statements is now the minimum of:
-
the device buffer capacity (as reported by a HiperSockets or QDIO
device; for other devices, the value is based on the device architecture)
-
the buffer_size value associated with the
LARGEENVELOPEPOOLSIZE statement in the TCP/IP server
configuration file.
-
Note:
The RouteD server has been withdrawn from TCP/IP level 530. The
server user ID, command program, configuration statements and files
associated with this server have likewise been removed from the z/VM
Version 5 Release 3.0 System Deliverable.
Changes Introduced in TCP/IP Level 520
-
The MPRoute server implementation provided with this level of
TCP/IP for z/VM has been revised, and is adapted from z/OS V1.7.
With this implementation change, the format of the MPRoute server
messages differs from that of other TCP/IP messages. The
following message numbering convention is used for MPRoute messages:
EZZnnnnt
where:
|
EZZ
|
is the product identifier for MPRoute
|
|
nnnn
|
is a unique 4-digit numeric value assigned to the message
|
|
t
|
is the message type that indicates the action assigned to the message.
|
Types and their meanings are:
|
Type Code
|
Meaning
|
|
A
|
Immediate action required
|
|
E
|
Eventual action required
|
|
D
|
Immediate decision required
|
|
I
|
Informational
|
-
Various MPRoute server configuration statements have been revised,
with respect to their use and supported operands, while others have
been added in support of IPv6.
-
A subnet mask value of 255.255.255.255 is no longer accepted
for the OSPF_INTERFACE, RIP_INTERFACE or
INTERFACE configuration statements. The most specific subnet
mask that now can be specified for these statements is
255.255.255.252. This change is a result of TCP/IP server
enforcement of RFC rules that restrict a subnetwork broadcast or
network address from being used as a host address.
By convention, an address that has all ones in the host
portion is a subnet broadcast address, whereas an address
that has all zeros in the host portion is a subnet
network address. Therefore, the subnet_mask value
specified for the aforementioned statements must have a sufficient
number of zero bits such that no home address in that subnet has all
zeros or all ones in the host portion of the address.
Consider a subnet that incorporates these two home addresses —
10.1.1.1 and 10.1.1.2 The subnet mask for this
subnet must have zeros in at least two bit positions; for example,
255.255.255.252 (where the binary representation of
252 is 11111100). However, if a subnet includes
four home addresses — 10.1.1.1, 10.1.1.2,
10.1.1.3 and 10.1.1.4 — its subnet mask must
have zeros in at least three bit positions; for example
255.255.255.248 (248 in binary form is
11111000). In this instance, up to six
home addresses can be included in this subnet (10.1.1.1
through 10.1.1.6).
In general, if a subnet mask has n zero bits, then there
can be up to 2n – 2 home addresses in that subnet.
This limit applies even if the subject home addresses are configured
on different TCP/IP stacks.
-
The name of the MPRoute server configuration file is no longer
restricted to MPROUTE CONFIG. A newly introduced DTCPARMS
:config. tag can be used to specify the file ID of the
configuration file to be used when an MPRoute server is initialized.
-
The existing support limit of only four equal-cost paths is removed
-- up to 16 equal-cost routes may now be generated for a given
destination, to provide improved load-balancing support.
-
Processing of the of the HOME and GATEWAY
statements by the TCP/IP (Stack) server has been updated to allow for
the specification of subnet masks using BSD-style and Classless
Inter-Domain Routing (CIDR) notation. Corresponding NETSTAT
command changes have been implemented to accommodate the reporting of
such notation in data produced by the NETSTAT HOME and NETSTAT GATE
commands.
-
The TCP/IP server now automatically generates static routes for IP
addresses for which a subnet mask has been specified. When a subnet
mask is specified for IPv4 home addresses, the TCP/IP server
automatically generates a direct static route to the subnet described
by the IP address and mask. For IPv6 addresses, the TCP/IP server
automatically generates a direct static route to the network described
by the first 64 bits of the address. Unlike static routes added
through the GATEWAY statement, these routes may be replaced by dynamic
routing protocols if MPRoute is running.
-
Note:
This is the last TCP/IP level for which a RouteD server may be
deployed to provide dynamic routing support. Future levels of z/VM
TCP/IP will rely solely upon the MPRoute server to provide dynamic
routing services.
Changes Introduced in Prior Levels
Top of Page
| | Remote Execution Services |
Changes Introduced in Prior Levels
Top of Page
Changes Introduced in TCP/IP Level 530
-
The SMTP server has been updated to accommodate Dynamic SSL/TLS support.
Changes to provide this capability include support for additional
server configuration statements, which include:
-
The SMTP server has been enhanced to honor the DOMAINLOOKUP
statement in the TCPIP DATA file. In addition, the SMTP server now
uses the ETC HOSTS file for the local site table, if present. If the
ETC HOSTS file is not present, SMTP uses the HOSTS SITEINFO file.
-
An SMTP NAMES file restriction against using a nickname that is the
same as a user ID in the list defined by that nickname is removed.
With this level, you can specify a nickname that matches a user ID
in that nickname list.
Changes Introduced in Prior Levels
Top of Page
Changes Introduced in TCP/IP Level 530
-
An SNMP Subagent server is introduced which can be customized to
supply a specific set of MIB variables (such as BRIDGE-MIB variables
that are associated with a virtual switch). With this server, support
for the use of various SNMP MIB exit routines, identified within a
MIB_EXIT DATA file is added as well.
Top of Page
Changes Introduced in TCP/IP Level 530
-
The SSL sever has been modified to accommodate "Dynamic SSL/TLS
Support," which introduces a set of Application Programming
Interfaces (APIs) that permit a Pascal or Assembler client or server
application to control the acceptance and establishment of TCP/IP
sessions encrypted using SSL/TLS.
To provide this capability, the interface used by the SSL server to
communicate with the TCP/IP stack server has been modified. Due to the
nature of these changes, one of the SSL-related RPM packages supplied
with TCP/IP level 530 must be used for SSL server setup and
configuration. Note also that the TCP/IP level 530 SSL server
cannot be used with prior levels of TCP/IP for z/VM.
TCP/IP Level 530 SSL and TCP/IP server compatibility is summarized here:
TCP/IP Level 530 SSL and TCP/IP Server Compatibility
| |
TCP/IP Level 530
SSL Server |
Prior-level
SSL Server |
TCP/IP Level 530
Stack Server |
Compatible |
Not Compatible |
Prior-level TCP/IP
Stack Server |
Not Compatible |
Compatible |
-
The SSL server command (VMSSL) has been updated to allow
additional security levels to be specified for the EXEMPT
operand, to more easily eliminate weak ciphers. Support for a
NOHALT operand has also been added, which allows the SSL
server Linux guest to remain active after a critical error is
encountered during server operations.
-
The SSL server administration command (SSLADMIN) has been
modified as follows:
-
The SSLADMIN SELF command has been updated to support an
EXPIRATION operand, which may be used to specify number of days
that a self-signed certificate is to be valid.
-
The SSLADMIN LOG command has been updated to accept file ID
operands that allow SSL server log information to be maintained in a
file named other than SSLADMIN LOG.
-
the SSLADMIN LOGSIZE and SSLADMIN LOGCLEAR commands are
introduced. These respective commands allow a maximum size to be
established for the SSL server log, and for accumulated log information
to be purged within the SSL server.
-
The RPM packages provided with this level of TCP/IP for z/VM support running
the SSL server using these Linux distributions:
- SUSE SLES9 Service Pack 3 (31-bit)
- SUSE SLES9 Service Pack 3 (64-bit)
- Red Hat Enterprise Linux AS (Version 4 U4) (31-bit)
- Red Hat Enterprise Linux AS (Version 4 U4) (64-bit)
Changes Introduced in TCP/IP Level 520
-
A FIPS operand is introduced that signifies the SSL server
is to operate in FIPS (Federal Information Processing Standard, FIPS
140-2) mode, which restricts connections to those that employ
FIPS-approved cipher suites.
-
Server operation has been modified such that a server restart is
not required to activate or remove a certificate.
-
The RPM packages provided with this level of TCP/IP for z/VM support
running the SSL server using these Linux distributions:
- SUSE SLES8 Service Pack 3 (31-bit)
- SUSE SLES9 Service Pack 2 (31-bit)
- SUSE SLES9 Service Pack 2 (64-bit)
- Red Hat Enterprise Linux AS V3 (31-bit)
- Red Hat Enterprise Linux AS V3 (64-bit)
Changes Introduced in Prior Levels
Top of Page
Changes Introduced in TCP/IP Level 530
-
Several enhancements have been added to help maintain high
availability in the event of an ethernet QDIO (IPv4 or IPv6) or LCS
(IPv4 only) device failure. These enhancements include:
- IPv4 ARP Takeover Support
This support provides redundant ethernet (LCS or QDIO) adapters (two
or more adapters connected to the same LAN segment) the ability to
take over for each other in the event of a device failure.
Provided all TCP/IP stack interfaces are properly configured, no
TCP/IP configuration changes should be necessary for this function to
be exploited. The TCP/IP stack uses the configured IP address/subnet
mask pairs for each interface to make a determination about which
interfaces are connected to the same LAN segment and are therefore
eligible to take over for each other.
- IPv6 Neighbor Discovery Takeover Support
This support provides redundant QDIO ethernet adapters (two or more
adapters connected to the same LAN segment) the ability to take over
for each other in the event of a device failure.
Configuration changes should not be necessary for this function to be
used, since the TCP/IP stack perform "same LAN determination"
for IPv6 interfaces at initialization, to identify which adapters are
connected to the same LAN segment and are therefore eligible to take
over for each other.
- Enhanced OSA Address Table (OAT) Management
With this enhancement, the IP addresses reported to an OSA adapter are
restricted to:
- those that are defined as adapters HOME addresses
- IPv4 VIPA addresses (if the device is enabled for IPv4)
- IPv4 Proxy ARP addresses (if the device is enabled for IPv4)
- IPv6 VIPA addresses (if the device is enabled for IPv6)
- any IP addresses for which the device has taken over
-
IPv6 VIPA Support has been added, which gives hosts the ability
to use the VIPA address as a target for IP traffic, allowing such
traffic to be routed to a working adapter on the TCP/IP stack, should
one of several applicable adapters fail. Configuration statement
changes associated with this support include the following additions:
- IPV6SOURCEVIPA operand (added for the
ASSORTEDPARMS statement)
- ENABLEIPV6 option (added for the LINK statement)
-
TCP/IP has been updated to allow both an IPv4 and IPv6 VLAN to be
associated with a QDIOETHERNET link. Changes include:
- acceptance of an IPv6 VLAN ID (in addition to an IPv4 VLAN ID) for
the QDIOETHERNET LINK statement
- IFCONFIG command changes that allow both an IPv4 VLAN ID
and an IPv6 VLAN ID to be specified as part of the VLAN
interface operand
-
The HOME statement now accepts a VSWITCH operand, which
identifies the link that is associated with an IPv4 address as one
that can be used for VSWITCH management purposes, such as retrieval of
SNMP Bridge MIBs for the virtual switch. The named VSWITCH is also
returned in NETSTAT HOME command results.
-
Be aware that with z/VM 5.3.0, it is no longer necessary to
uncouple/recouple to a Guest LAN or VSWITCH for VLAN or promiscuous
mode authorization changes to take effect. Thus, such changes now can
immediately affect the operation of a TCP/IP stack server that is
connected to a VSWITCH or Guest LAN.
-
Support for a -Remove command option has been added to the
IFCONFIG command, which allows an interface to be dynamically
removed from the TCP/IP server configuration. This support makes use
of a new socket API IOCTL subcommand (SIOCDINTERFACE)
introduced at this level.
-
Support for the BSDROUTINGPARMS statement has been
withdrawn.
-
The TCP/IP sever has been modified to accommodate "Dynamic SSL/TLS
Support," which introduces a set of Application Programming
Interfaces (APIs) that permit a Pascal or Assembler client or server
application to control the acceptance and establishment of TCP/IP
sessions encrypted using SSL/TLS. New configuration statements
introduced in conjunction with this capability are:
Note that to provide this capability, the interface used by the TCP/IP
server to communicate with the SSL server has been modified. Due to
the nature of these changes, an SSL server implementation that is
based on prior levels of TCP/IP for z/VM cannot be used with the TCP/IP
level 530 TCP/IP server.
-
The INTERNALCLIENTPARMS statement, used for configuring the
Telnet server, has been updated to accommodate Dynamic SSL/TLS support.
Changes include support for SECURECONNECTION and
TLSLABEL operands.
Changes Introduced in TCP/IP Level 520
-
Processing of the of the HOME and GATEWAY
statements by the TCP/IP (Stack) server has been updated to allow for
the specification of subnet masks using BSD-style and Classless
Inter-Domain Routing (CIDR) notation. Corresponding NETSTAT
command changes have been implemented to accommodate the reporting of
such notation in data produced by the NETSTAT HOME and NETSTAT GATE
commands.
-
The TCP/IP server now automatically generates static routes for IP
addresses for which a subnet mask has been specified. When a subnet
mask is specified for IPv4 home addresses, the TCP/IP server
automatically generates a direct static route to the subnet described
by the IP address and mask. For IPv6 addresses, the TCP/IP server
automatically generates a direct static route to the network described
by the first 64 bits of the address. Unlike static routes added
through the GATEWAY statement, these routes may be replaced by dynamic
routing protocols if MPRoute is running.
Changes to TCP/IP Server Defaults
-
Port Restriction Defaults Have Changed - Action Required
With TCP/IP Level 440, the RestrictLowPorts operand of the
AssortedParms statement was changed to be active by
default.
Because of this change, various TCP/IP applications
may no longer function unless you take action.
Refer to the
TCP/IP Usage Reference Information
for more detail about this change.
Changes Introduced in Prior Levels
Top of Page
Changes Introduced in TCP/IP Level 530
-
The INTERNALCLIENTPARMS statement, used for configuring the
Telnet server, has been updated to accommodate Dynamic SSL/TLS support.
Changes include support for SECURECONNECTION and
TLSLABEL operands.
-
The Telnet client has been updated to accommodate Dynamic SSL/TLS
support. Changes to provide this capability include support for
additional command options, which include:
- CERTFULLCHECK
- CERTNOCHECK
- NOSECURE
- SECURE
-
A new statement, SECURETELNETCLIENT, may now be specified in
the TCPIP DATA file. This statement provides the default Telnet client
security value to use when neither the SECURE nor NOSECURE option is
specified on the Telnet command.
Changes Introduced in Prior Levels
Top of Page
Changes Introduced in TCP/IP Level 530
General Information
Packaging-specific Changes
-
TCP/IP service procedures now require the TCP/IP for z/VM installation
and service user ID (5VMTCP30, by default) to have file pool
administration authority for the VMSYS file pool. Such
authorization is necessary to accommodate service update processing
for LDAP server components that reside in the z/VM Byte File System
(BFS).
For the z/VM Version 5 Release 3.0 System Deliverable, the 5VMTCP30
user ID has already been enrolled as a file pool administrator for the
VMSYS file pool. If you choose to use a different user ID to
service TCP/IP for z/VM, or elect to use a file pool other than VMSYS
for maintaining the Byte File System, you then will need to enroll the
appropriate user ID as an administrator for the applicable file pool.
-
Support for the BOOTPD and RouteD servers has been withdrawn. The server
user IDs, command programs, configuration statements and files associated
with these servers have likewise been removed from the
z/VM Version 5 Release 3.0 System Deliverable.
If appropriate, the DHCPD and MPRoute servers should be configured
to provide any support and functionality for your installation that
was previously provided by the respective BOOTPD and RouteD servers.
-
The default minimum virtual storage size defined for most
TCP/IP server virtual machines is now 32M (however, the
default minimum for certain virtual machines, such as the IMAP, LDAP
and SSL servers, is defined higher than this value).
For detailed information about how specific TCP/IP user IDs have been
defined, consult the 5VMTCP30 PLANINFO file. This file
is located on the 5VMTCP30 191 minidisk.
Changes Introduced in Prior Levels
Top of Page
|
