IPCONFIG6 statement

Parameters

CHECKSUMOFFLOAD | NOCHECKSUMOFFLOAD

Specifies whether the stack should offload inbound and outbound checksum processing (TCP and UDP checksums) for IPv6 packets to OSA-Express® features. The checksum offload support transfers the overhead of most checksum processing to QDIO-attached OSA-Express devices that support this function. Offloading checksum processing reduces CPU use and increases throughput. This parameter is ignored for OSA-Express features that do not support IPv6 checksum offload.

See Steps for modifying for information about changing this parameter while the TCP/IP stack is active. See Checksum offload in z/OS Communications Server: IP Configuration Guide for more information about the checksum offload support and for specific information about which packets can have checksum processing performed by the OSA-Express.

NOCHECKSUMOFFLOAD

Checksum processing is performed by the TCP/IP stack.

CHECKSUMOFFLOAD

Checksum processing is offloaded to the OSA-Express feature. This value is the default value.

DATAGRAMFWD | NODATAGRAMFWD

NODATAGRAMFWD

Disables the forwarding of IP packets that are received by, but not addressed to, the stack. This statement can be used for security or to ensure correct usage of limited resources. The NODATAGRAMFWD parameter is confirmed by the message:

EZZ0699I IPV6 FORWARDING IS DISABLED

If the TCP/IP stack is also configured to be a sysplex distributor (see VIPADYNAMIC statement summary for more information), datagrams destined to a sysplex-distributed dynamic VIPA are forwarded to stacks, whether or not forwarding is enabled.

DATAGRAMFWD

Enables the forwarding of IP packets that are received by, but not addressed to, the stack. This is the default value.

NOFWDMULTIPATH

When forwarding is in effect and there are multiple equal-cost routes to the destination and the NOFWDMULTIPATH parameter is specified, TCP/IP uses the first active route found for forwarding each IP packet. This is the default value. The DATAGRAMFWD NOFWDMULTIPATH parameter is confirmed by the message:

EZZ0700I IPV6 FORWARDING NOFWDMULTIPATH SUPPORT IS ENABLED

FWDMULTIPATH PERPACKET

When forwarding is in effect and there are multiple equal-cost routes to the destination and the FWDMULTIPATH PERPACKET parameter is specified, TCP/IP selects a route for forwarding each IP packet on an approximate round-robin basis from the multiple equal-cost routes. Connection or connectionless-oriented IP packets using the same destination address do not always use the same route, but they do use all possible active routes to that destination host. All IP packets for a given association with a destination host are spread across the multiple equal-cost routes. The DATAGRAMFWD FWDMULTIPATH PERPACKET parameter is confirmed by the message:

EZZ0700I IPV6 FORWARDING FWDMULTIPATH PERPACKET SUPPORT IS ENABLED

DYNAMICXCF | NODYNAMICXCF

NODYNAMICXCF

Indicates XCF dynamic support is not enabled for IPv6 on this TCP/IP. The NODYNAMICXCF parameter for IPCONFIG6 is confirmed by the message:

EZZ0739I IPV6 DYNAMIC XCF DEFINITIONS ARE DISABLED

DYNAMICXCF

Indicates that dynamic XCF support is enabled for IPv6.

When DYNAMICXCF is coded in the profile, the purpose is to generate those dynamic XCF devices or interfaces, if possible. When TCP/IP is up, but ISTLSXCF is not active, dynamic creation is deferred. Later, when a TCP/IP command such as VARY TCPIP,,OBEYFILE or VARY TCPIP,,START is executed, triggering profile processing, the stack again checks to see if ISTLSXCF is active. If ISTLSXCF is active at that time, then the dynamic XCF devices and interfaces are generated.

Dynamic XCF definitions are not generated if there is a DEVICE or INTERFACE definition with the same device or interface name that dynamic XCF would generate.

Activation of dynamic XCF links is delayed if VTAM® is not up or if OMPROUTE is not up and DELAYJOIN is coded on the GLOBALCONFIG SYSPLEXMONITOR statement. For more information about connectivity problems in a sysplex, see z/OS Communications Server: IP Configuration Guide.

When using dynamic XCF for sysplex configuration, make sure that XCFINIT=YES or XCFINIT=DEFINE is coded in the VTAM start options, or if XCFINIT=NO was specified, ensure that a VARY ACTIVATE command is issued for the ISTLSXCF major node. This ensures that XCF connections between TCP stacks on different VTAM nodes in the sysplex can be established. See z/OS Communications Server: SNA Resource Definition Reference for directions for coding the XCFINIT VTAM start option. The DISPLAY NET,VTAMOPTS command can be used to determine the XCFINIT setting.

The VTAM ISTLSXCF major node must be active for XCF dynamics to work, except for the following two scenarios:

• Multiple TCP/IP stacks on the same MVS™ image; a dynamic samehost definition is generated, whether ISTLSXCF is active or not.
• HiperSockets is configured and enabled across multiple z/OS systems that are in the same sysplex and the same CEC; a dynamic IUTIQDIO link is created, whether ISTLSXCF is active or not.

For information about activating the ISTLSXCF major node, see z/OS Communications Server: SNA Resource Definition Reference.

Dynamic XCF can be enabled even in a single system sysplex. HiperSockets can be used between LPARs on the same central processor complex (CPC) even when MVS images in those LPARs are not defined to be part of the same sysplex. HiperSockets can also be used between LPARs even when some of those other LPARs are running Linux®, as long as all of the stacks connecting to HiperSockets and needing to exchange IP packets with each other define IP addresses that are all in the same subnet (as defined by the dynamic XCF IP address and subnet mask in the IPCONFIG6 DYNAMICXCF profile statement).

A mix of static and dynamic IPv4 and IPv6 definitions for a device are not allowed. For example, if a static IUTSAMEH IPv4 device/link is defined, then the IPv6 dynamic definition for IUTSAMEH is not created. If a static IUTSAMEH IPv6 interface is defined, then the IPv4 dynamic definition for IUTSAMEH is not created. The same logic is also applied for XCF links; a mix of static and dynamic IPv4 and IPv6 definitions is not allowed for an XCF link.

ipv6_address

The fully qualified IPv6 address that is used for all dynamically generated XCF, Same Host, and HiperSockets interfaces.

See Restrictions on IPv6 addresses configured in the TCP/IP profile for a list of restrictions that must be observed when specifying this parameter.

prefix_route_len

The length of the routing prefix (an integer value in the range 1 - 128). If specified, and if DYNAMICXCF generates a HiperSockets interface definition, TCP/IP creates a prefix route over the HiperSockets interface using the number of bits specified in prefix_route_len of the ipv6_address. Therefore, you can configure other stacks outside the sysplex for the same IQD CHPID using IP addresses with the same prefix such that this stack automatically has a route to these other stacks over the HiperSockets interface generated by DYNAMICXCF. If prefix_route_len is not specified, then TCP/IP does not create a prefix route over the HiperSockets interface. For interfaces other than HiperSockets which are generated from DYNAMICXCF, the prefix_route_len value has no meaning.

Guideline: Configure a prefix_route_len to simplify connectivity if you use HiperSockets on the same IQD CHPID for stacks outside the sysplex or if you configure VIPAROUTE statements.

INTFID interface_id

An optional 64-bit interface identifier in colon-hexadecimal format. IPv6 address shorthand notation (for example, the use of :: to indicate multiple groups of 16 bits of zeros) is not allowed when specifying the interface ID. If specified, this interface ID is used to form the link-local address for the interface.

If INTFID is not coded, TCP/IP generates a random value to be used to form the link-local address.

See INTERFACE - IPAQENET6 OSA-Express QDIO interfaces statement for an explanation of restrictions that must be observed when manually specifying the INTFID parameter.

SECCLASS security_class

Use this parameter to associate a security class for IP filtering with each IPv6 dynamic XCF interface. In order for traffic over the interface to match a filter rule, the filter rule must have the same security class value as the interface or a value of 0. Filter rules can be specified in the TCP/IP profile or in an IP Security policy file read by the Policy Agent. Filter rules can include a security class specification on the IpService statement in an IP Security policy file or on the SECCLASS parameter on the IPSEC6RULE statement in the TCP/IP profile.

Valid security classes are identified as a number in the range 1 - 255. The default value is 255. For more information about security class values, see z/OS Communications Server: IP Configuration Guide.

Restriction: This value is used only when IPSECURITY is specified on the IPCONFIG6 statement.

SMCD | NOSMCD

Specifies whether the dynamically generated XCF HiperSockets interface can be used for new TCP connections with Shared Memory Communications - Direct Memory Access (SMC-D).

SMCD

Specifies that the dynamically generated XCF HiperSockets interface can be used for new TCP connections with SMC-D. This is the default setting.

NOSMCD

Specifies that the dynamically generated XCF HiperSockets interface cannot be used for new TCP connections with SMC-D.

SOURCEVIPAINTERFACE vipa_name

The SOURCEVIPAINTERFACE parameter is optional. This parameter specifies which static VIPA interface is to be used as the source IP address when IPCONFIG6 SOURCEVIPA is specified and outbound packets are sent over the dynamically generated XCF or Same Host interfaces. The vipa_name value is the interface name for a VIRTUAL6 interface. If the VIPA has multiple IP addresses, then the source VIPA address for outbound packets is selected from among these addresses according to the default source address selection algorithm. The maximum length is 16 characters. For more information, see the default source address selection algorithm information in z/OS Communications Server: IPv6 Network and Application Design Guide.

The use of the SOURCEVIPAINTERFACE parameter can be overridden. See the information about source IP address selection in z/OS Communications Server: IP Configuration Guide for the hierarchy of ways that the source IP address of an outbound packet is determined.

For more details about the use of DYNAMICXCF, see the DYNAMICXCF information in z/OS Communications Server: IP Configuration Guide. The DYNAMICXCF parameter is confirmed by the message:

EZZ0739I IPV6 DYNAMIC XCF DEFINITIONS ARE ENABLED

HOPLIMIT hoplimit

Number of hops a packet originating at this host can travel enroute to the destination. If the destination is more hops away, the packet never reaches the destination. The valid range is between 1 - 255. The default is 255.

ICMPERRORLIMIT msgs_per_sec

This parameter controls the rate at which ICMP error messages can be sent to a particular IPv6 destination address. The number specified is messages per second. The default is 3 messages per second, and the valid range is 1 - 20 messages per second. A token bucket algorithm is used to allow bursts of ICMP errors while limiting the long-term rate.

IGNOREREDIRECT

Causes TCP/IP to ignore ICMPv6 Redirect packets. The IGNOREREDIRECT parameter is confirmed by the message:

EZZ0701I ICMPV6 REDIRECTS WILL BE IGNORED

If you are using OMPROUTE, and IPv6 interfaces are configured to OMPROUTE, and this option is not specified, IGNOREREDIRECT is enabled automatically. If you are using intrusion detection services (IDS) policy to detect and discard ICMPv6 redirect packets and this option is not specified, ICMPv6 redirect packets are discarded while the policy is active.

IGNOREROUTERHOPLIMIT | NOIGNOREROUTERHOPLIMIT

NOIGNOREROUTERHOPLIMIT

NOIGNOREROUTERHOPLIMIT causes TCP/IP to not ignore a hop limit value received in a router advertisement from a router over an IPAQENET6 interface. This results in the configured global hop limit value being overridden by the router advertisement value for all routes using the interface on which the router advertisement was received. This is the default value. The NOIGNOREROUTERHOPLIMIT parameter is confirmed by the message:

EZZ0720I ROUTER ADVERTISEMENT HOP LIMIT VALUES WILL NOT BE IGNORED

IGNOREROUTERHOPLIMIT

Although you can configure a global hop limit value for the stack (by way of IPCONFIG6 HOPLIMIT), your stack might receive a different hop limit value in a router advertisement from a router, over an IPAQENET6 interface. This results in the configured global hop limit value being overridden by the router advertisement value for all routes using the interface on which the router advertisement was received. IGNOREROUTERHOPLIMIT gives you a way to prevent this, ensuring that your configured value is always used. The IGNOREROUTERHOPLIMIT parameter is confirmed by the message:

EZZ0719I ROUTER ADVERTISEMENT HOP LIMIT VALUES WILL BE IGNORED

IPSECURITY

Activates IPv6 IP filtering and IPv6 IPSec tunnel support. This parameter requires the IPSECURITY parameter to be configured for IPv4 on the IPCONFIG statement.

Requirements:

• Use this parameter so that the stack can function with the Communications Server IKE daemon and to enable the stack to receive IPv6 IPSec policy information, such as IP filter rules from the policy agent.
• Use this parameter so that the stack can receive IPv6 defensive filters from the Defense Manager daemon (DMD).

The IPSECURITY parameter is confirmed by the message:

 EZZ0786I IPV6 SECURITY SUPPORT IS ENABLED

Restriction: IPSec functions can be activated only at initial activation of TCP/IP.

OSMSECCLASS security_class

Use this parameter to associate a security class for IP filtering with each OSM interface. In order for traffic over the interface to match a filter rule, the filter rule must have the same security class value as the interface or a value of 0. Filter rules can be specified in the TCP/IP profile or in an IP Security policy file read by the Policy Agent. Filter rules can include a security class specification on the IpService statement in an IP Security policy file or on the SECCLASS parameter on the IPSEC6RULE statement in the TCP/IP profile. For more information about OSM interfaces, see the TCP/IP in an intraensemble network section in z/OS Communications Server: IP Configuration Guide.

Valid security classes are identified as a number in the range 1 - 255. The default value is 255. For more information about security class values, see z/OS Communications Server: IP Configuration Guide.

MULTIPATH | NOMULTIPATH

NOMULTIPATH

Disables the multipath routing selection algorithm for outbound IP traffic. If there are multiple equal-cost routes to a destination and NOMULTIPATH is specified, TCP/IP uses the first active route found to send each IP packet. The NOMULTIPATH parameter is confirmed by the message:

EZZ0703I IPV6 MULTIPATH SUPPORT IS DISABLED

NOMULTIPATH is the default value.

Rule: The NOMULTIPATH parameter applies to outbound IP traffic that is routed by using the main route table. This parameter applies also to outbound IP traffic that is routed by using a policy-based route table if the Multipath6 UseGlobal parameter is specified on the RouteTable statement that defines the policy-based route table. See RouteTable statement for more information.

MULTIPATH

Enables the multipath routing selection algorithm for outbound IP traffic. In general, multipath routing provides the routing distribution necessary to balance the network utilization of outbound packets by load splitting. Multipath routing requires the definition of multiple equal-cost routes that are either defined statically or added dynamically by routing protocols (except for RIP, which does not provide multipath routing). If MULTIPATH is specified without any subparameters, the default is PERCONNECTION. The MULTIPATH parameter has no effect if there are no multipath routes in the TCP/IP configuration.

Rules:

• The MULTIPATH parameter and its subparameters apply to outbound IP traffic that is routed by using the main route table. This parameter and its subparameters apply also to outbound IP traffic that is routed by using a policy-based route table if the Multipath6 UseGlobal parameter is specified on the RouteTable statement that defines the policy-based route table. See RouteTable statement for more information.
• The multipath routing selection algorithm is applied and can be specified separately for each route table. Specify the algorithm for the main route table using the MULTIPATH parameter on the IPCONFIG6 statement. Specify the algorithm for policy-based route tables in the policy definition for each table. See RouteTable statement for more information.

Note: The IPCONFIG6 MULTIPATH|NOMULTIPATH configuration option affects Enterprise Extender (EE) traffic when MULTPATH=TCPVALUE is coded. For information about multipath for EE, see z/OS Communications Server: SNA Network Implementation Guide. For information about the MULTPATH start option, see z/OS Communications Server: SNA Resource Definition Reference.

PERCONNECTION

If there are multiple equal-cost routes to a destination and MULTIPATH PERCONNECTION is specified, TCP/IP, upon first sending an IP packet to a given destination, selects a route on a round-robin basis from a multipath routing list to that destination host. The selected route is used to route IP packets for a given connection or connectionless oriented association to that destination host. Connection or connectionless oriented IP packets using the same association always use the same route, as long as that route is active. The MULTIPATH PERCONNECTION parameter is confirmed by the message:

EZZ0704I IPV6 MULTIPATH PERCONNECTION SUPPORT IS ENABLED

PERPACKET

If there are multiple equal-cost routes to a destination, TCP/IP, upon sending an IP packet in that destination, selects a route on an approximate round-robin basis from a multipath routing list to that destination host. The selected route is used for routing that IP packet. Connection or connectionless oriented IP packets using the same source and destination address pair do not always use the same route, but do use all possible active routes to that destination host. All IP packets for a given association with a destination host are spread across the multiple equal-cost routes. The MULTIPATH PERPACKET parameter is confirmed by the message:

EZZ0704I IPV6 MULTIPATH PERPACKET SUPPORT IS ENABLED

Restriction: The MULTIPATH PERPACKET parameter cannot be enabled if the IPSECURITY parameter is specified. If both values are specified, the following messages are displayed, and multipath routing is disabled.

EZZ0792I CANNOT ENABLE IPV6 MULTIPATH PERPACKET SUPPORT WHEN 
IPV6 SECURITY IS ENABLED 
EZZ0703I IPV6 MULTIPATH SUPPORT IS DISABLED

SEGMENTATIONOFFLOAD | NOSEGMENTATIONOFFLOAD

Specifies whether the stack should offload TCP segmentation for IPv6 packets to OSA-Express features. The TCP segmentation offload support transfers the overhead of segmenting outbound data into individual TCP packets to QDIO-attached OSA-Express devices that support this function. Offloading segmentation of streaming-type workloads reduces CPU use and increases throughput. This parameter is ignored for OSA-Express features that do not support IPv6 segmentation offload.

See the steps for modifying topic for information about changing this parameter while the TCP/IP stack is active. See TCP segmentation offload in z/OS Communications Server: IP Configuration Guide for more information about the TCP segmentation offload support.

NOSEGMENTATIONOFFLOAD

TCP segmentation is performed by the TCP/IP stack. This value is the default value.

SEGMENTATIONOFFLOAD

TCP segmentation is offloaded to the OSA-Express feature.

SOURCEVIPA | NOSOURCEVIPA

NOSOURCEVIPA

Specifies that TCP/IP is not requested to use a VIPA address as the source IP address for outbound datagrams. The NOSOURCEVIPA parameter is confirmed by the message:

EZZ0702I IPV6 SOURCEVIPA SUPPORT IS DISABLED

NOSOURCEVIPA is the default value.

SOURCEVIPA

Requests that TCP/IP use a virtual IP address assigned to the TCPSTACKSOURCEVIPA interface (if TCPSTACKSOURCEVIPA is specified) or to the SOURCEVIPAINTERFACE interface as the source address for outbound datagrams that do not have an explicit source address. If multiple addresses are assigned to the TCPSTACKSOURCEVIPA interface or the SOURCEVIPAINTERFACE interface, the source address is selected from among these addresses according to the default source address selection algorithm. For more information, see the default source address selection algorithm information in z/OS Communications Server: IPv6 Network and Application Design Guide.

Requirement: You must specify the SOURCEVIPAINTERFACE keyword on the INTERFACE statement for each interface on which you want that SOURCEVIPA to take effect.

The SOURCEVIPA parameter is confirmed by the message:

EZZ0702I IPV6 SOURCEVIPA SUPPORT IS ENABLED

Tip: The use of SOURCEVIPA or TCPSTACKSOURCEVIPA can be overridden. See the information about source IP address selection in z/OS Communications Server: IP Configuration Guide for the hierarchy of ways that the source IP address of an outbound packet is determined.

TCPSTACKSOURCEVIPA | NOTCPSTACKSOURCEVIPA

NOTCPSTACKSOURCEVIPA

Specifies that TCP/IP does not use a stack-level IPv6 address as the source address for outbound TCP connections. The source IP address is determined by the normal default selection.

TCPSTACKSOURCEVIPA intf_name

The name of a static VIPA or a dynamic VIPA interface. The maximum length is 16 characters.

If the interface has multiple IP addresses, then the sourcevipa address for outbound packets is selected from among these addresses according to the default source address selection algorithm. For more information, see the default source address selection algorithm information in z/OS Communications Server: IPv6 Network and Application Design Guide.

If SOURCEVIPA has not been enabled for IPCONFIG6, IPCONFIG6 TCPSTACKSOURCEVIPA is ignored and the following message is issued:

EZZ0760I IPV6 TCPSTACKSOURCEVIPA IS IGNORED - SOURCEVIPA IS NOT ENABLED

Tips:

• After it is set, TCPSTACKSOURCEVIPA is not disabled until a profile explicitly adds NOTCPSTACKSOURCEVIPA to the IPCONFIG6 statement.
• A dynamic VIPA that becomes inactive because it moves to another TCP/IP stack, or that is deleted because the application that caused its creation (in the case of a VIPARANGE statement created address) causes its deletion, is no longer a valid interface for the TCPSTACKSOURCEVIPA parameter.
• If you specify the same distributed DVIPA interface for TCPSTACKSOURCEVIPA on multiple target stacks, you also should specify SYSPLEXPORTS on the VIPADISTRIBUTE statement. Otherwise connections might be disrupted because identical connections could be created from more than one stack.
• Carefully consider the following when determining the interface to use for TCPSTACKSOURCEVIPA.
  • A dynamic VIPA that becomes inactive because it moves to another TCP/IP stack, or that is deleted because the application that caused its creation (in the case of a VIPARANGE statement created address) causes its deletion, is no longer a valid interface for TCPSTACKSOURCEVIPA.
  • A dynamic VIPA interface that is created by a VIPARANGE statement can have multiple dynamic VIPA addresses associated with it. The actual address chosen as the source IP for the outbound connection is not predictable or necessarily meaningful.
• The use of TCPSTACKSOURCEVIPA can be overridden. See the information about source IP address selection in z/OS Communications Server: IP Configuration Guide for the hierarchy of ways that the source IP address of an outbound packet is determined.

TEMPADDRS | NOTEMPADDRS

NOTEMPADDRS

Specifies that TCP/IP should not generate IPv6 temporary addresses. Use of the NOTEMPADDRS parameter is confirmed by the message:

EZZ0821I IPV6 TEMPORARY ADDRESS SUPPORT IS DISABLED

NOTEMPADDRS is the default value.

TEMPADDRS

Requests that TCP/IP generate IPv6 temporary addresses for IPAQENET6 OSA-Express QDIO interfaces for which stateless address autoconfiguration is enabled. Stateless address autoconfiguration is enabled for an interface if no address or prefix is specified with the IPADDR keyword. See the information about using IPv6 temporary addresses to address privacy concerns in the z/OS Communications Server: IPv6 Network and Application Design Guide.

Requirement: You must specify the job name of an application in the SRCIP statement block with a value of TEMPADDRS to cause a temporary IPv6 address to be preferred over a public IPv6 address as the source IP address for the application; otherwise, the default source address selection algorithm prefers public IPv6 addresses over temporary addresses. See the information about default source address selection in the z/OS Communications Server: IPv6 Network and Application Design Guide .

The TEMPADDRS parameter is confirmed by the message:

EZZ0816I IPV6 TEMPORARY ADDRESS SUPPORT IS ENABLED

PREFLIFETIME pref_lifetime

Preferred lifetime for temporary addresses specified in hours. At the expiration of the preferred lifetime, a new temporary address is generated and the existing address is deprecated. Valid values are in the range 1 - 720 hours (30 days). The default is 24 hours (1 day).

Results:

• A temporary address can be deprecated sooner than specified by the pref_lifetime value if the preferred lifetime of the prefix that is learned from a router advertisement is less than the pref_lifetime.
• A short preferred lifetime results in new temporary addresses being generated more quickly.

VALIDLIFETIME valid_lifetime

Valid lifetime for temporary addresses, specified in hours. At the expiration of the valid lifetime, the temporary address is deleted. Valid values are in the range 2 - 2160 hours (90 days). The default is 7 times the preferred lifetime, not to exceed a maximum value of 90 days.

Rules:

• valid_lifetime value must be greater than pref_lifetime value.
• If PREFLIFETIME is not explicitly configured, the valid_lifetime value must be greater than the default value for pref_lifetime.

Results:

• A temporary address can be deleted sooner than specified by the valid_lifetime value if the valid lifetime of the prefix that is learned from a router advertisement is less than valid_lifetime.
• A short valid lifetime results in deprecated temporary addresses being deleted more quickly.

Guideline: Do not specify a small pref_lifetime value with a large valid_lifetime value. A large number of deprecated temporary addresses can have an impact on storage usage.

VALIDLIFETIME default_valid_lifetime

Specifies the default valid lifetime for temporary addresses in hours. The default is 7 times the preferred lifetime; you can specify a maximum value of 90 days.

Steps for modifying

Related topics

• GLOBALCONFIG statement
• IPCONFIG statement
• SRCIP statement