What's New in this Release

You can now import existing TCP/IP configuration into a V2R2 TCP/IP stack for the TCP/IP profile technology. First you must use the VARY TCPIP,,EXPORTPROF operator command to export an existing TCP/IP configuration data set into a format readable by the Configuration Assistant. You can then read that formatted configuration into a stack in the TCP/IP technology, and start working with your TCP/IP profile configuration in the Configuration Assistant.

z/OS Communications Server APAR PI63449 is required to support the EXPORTPROF command.

System symbols are created in reusable configuration and their values are resolved on a stack basis. When you import an existing TCP/IP configuration, system symbols in the fields listed above in reusable configuration will be preserved and resolved on a stack basis.

IPSEC interface name symbols continue to work as before.

The Configuration Assistant opening panel now enables you to begin by creating a new backing store, rather than requiring you to open an existing backing store before creating a new one.

The Welcome screen has changed to allow you to Manage z/OS Cloud configuration or to open a backing store to work with more traditional Configuration Assistant technologies.

You can only manage z/OS Cloud configuration from Configuration Assistant if you are using other z/OSMF features to manage z/OS Cloud. A z/OS Cloud and cloud domains must first be defined by z/OSMF Cloud before the z/OS Cloud features of Configuration Assistant can be used to manage z/OS Cloud networking. Once a z/OS Cloud and cloud domains are created and after you choose to manage z/OS Cloud from the Configuration Assistant welcome screen, all subsequent screens are specific to z/OS Cloud network management. See Getting Started Tutorial - Cloud for more information. To use non-z/OS Cloud features of Configuration Assistant, you must return to the Home screen (Welcome panel) and open a backing store.

A new System Group level has been introduced on the Systems tab in support of configuration that pertains to a Sysplex. All system images must be contained within a group. The Default group is predefined and is used to contain system images that do not require Sysplex level configuration. All system images will be in the Default group the first time an existing backing store is opened. The system images and stacks can be copied from the Default group to new Sysplex groups that you define. You can find it useful to create Sysplex groups to provide a more accurate depiction of your environment. TCP/IP profile support is the only technology that currently supports Sysplex level configuration. The System Group level is available on the Systems tab of all technologies.

The Configuration Assistant introduces the TCP/IP Profile technology to support configuring and installing the TCP/IP profile. With the introduction of the TCP/IP profile support, there was a need to represent Sysplex level definitions that are related to dynamic and distributed VIPAs. The Sysplex definitions are defined at the Sysplex group level and include the dynamic and distributed VIPA definitions, in addition to the dynamic XCF definition that is a configuration requirement for distributed VIPA support.

The configuration process performs real-time error checking that eliminates errors that previously went undetected until run time. Configuration options have been preselected or prefilled to conform to best practices values where they deviate from default configuration values.

Reusable configuration elements have been introduced for the TCP/IP profile support. A reusable configuration element consists of a set of profile definitions that can be included in one or more stacks. This simplifies the configuration process when multiple stacks share a set of common definitions. Configuration elements such as an interface will require different IP addresses to be assigned on each stack where the reusable configuration is included. Stack symbols are used to assign these stack-specific values to configuration elements defined in a reusable configuration. Reusable configuration does not support Sysplex level definitions.

The TCP/IP Profile default IP filter rules define the default IP filter policy. The default IP filter policy is used before the initial loading of IP security policy into the stack from the Policy Agent. It is also used when the IP security policy has been suspended by the z/OS UNIX ipsec command (that is, when the ipsec –f default command is used). The IP filters are defined by using traffic descriptors that are shared with the IPSec technology.

The TCP/IP Profile stack symbols that are defined to resolve Reusable Configuration definitions included in a stack can be referenced by IPSec technology rules.

The LDAP, HTTP and OCSP options can be configured at the image and security level. The certificate validation is enabled at the security level by selecting to use the image level options or by specifying specific options explicit to the security level.

The Import Policy Data function provides the ability to import existing policy definitions from Policy Agent into the Configuration Assistant. The purpose of import was to provide a transition from flat file configuration to using the Configuration Assistant to manage the policy definitions. The Policy import function will be discontinued in a future release. It is recommended you transition to the Configuration Assistant for any policy configuration that is currently managed by using flat files.

Import Policy Data has not been enhanced to support the new AT-TLS configuration options for certificate revocation checking. It is recommended that you move to the Configuration Assistant for managing your AT-TLS policies before configure these new options.

You can use the V2R2 Configuration Assistant to configure V2R2, V2R1, and V1R13 level z/OS systems. For each z/OS image configured, you indicate the z/OS release level. The Configuration Assistant will ensure that valid configuration is produced for the system level. For example, in V2R2 there are new AT-TLS certificate revocation settings for HTTP and OCSP. If you configure these new settings for a z/OS image that is marked as V2R1, the Configuration Assistant will ignore these new settings during the installation process.

The Configuration Assistant introduces the Cloud technology to support the definition of Cloud policy. Cloud policy is defined through the use of network resource pools which identify network resources available for dynamic provisioning by a network resource provisioner. Available resources include IP addresses which are defined by IP address allocation ranges, ports which are defined by port allocations ranges and SNA application names which are defined by SNA application name ranges. Optional DNS information may be defined to support the automatic registration of a host name with a name server when an IP address is dynamically allocated. Cloud policy is scoped to the local sysplex in which the Configuration Assistant z/OSMF plug-in is running.

Configuration Assistant was rewritten to better integrated with z/OSMF.

• Configuration Assistant now uses common z/OSMF panel widgets resulting in a common look and feel with z/OSMF panels.
• Configuration Assistant now requires less z/OS CPU usage.
• Configuration Assistant initially launches to a home page rather than immediately opening the last used backing store. From the home page, you select which backing store to open.
• Removal of the main technology perspective. Users now go directly to the last technology they configured.
• Removal of the Configuration Assistant navigation tree. Users now select from a group of tabs to access z/OS image, TCP/IP stacks and reusable objects.
• Application setup tasks has moved to the z/OSMF workflow plugin.

New AT-TLS support has been added for the following RFCs:

• Renegotiation options (RFC 5746)

  Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiations are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack.

• Elliptic Curve Cryptography (RFC 4492 and RFC 5480)

  This support provides new algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies:

  • The use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake
  • The use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism
  • The use of ECC with the Subject Public Key Information field in certificates.
• TLSv1.2 (RFC 5246)
• AES GCM Cipher Suites (RFC 5288)

  This involves the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a TLS authenticated encryption operation, and defines TLS cipher suites that use AES-GCM with RSA, DSA, and Diffie-Hellman-based key exchange mechanisms.

• Suite B Profile (RFC 5430)

  The United States government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. This support is now provided in AT-TLS. with Suite B.

• ECC and AES GCM with SHA-256/384 (RFC 5289)

  This defines 16 new cipher suites. All use Elliptic Curve Cryptography for key exchange and digital signature. Eight of the cipher suites use AES in Cipher Block Chaining (CBC) mode with an Hashed Message Authentication Code (HMAC)-based Message Authentication Code (MAC) with SHA-256 or SHA-384. The other eight use the new authenticated encryption modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) with SHA-256 or SHA-384.

You can use the V2R1 Configuration Assistant to configure V2R1, V1R13 and V1R12 level z/OS systems. For each z/OS image configured, you indicate the z/OS release level. The Configuration Assistant will ensure that valid configuration is produced for the correct level system. For example, in V1R13 there are new IDS attack protection types. If you attempt to configure these new protection types for a z/OS image marked as V1R12, the Configuration Assistant will ignore these new attack types since they are not available on V1R12. The Configuration Assistant will provide appropriate warnings to ensure you are aware of any settings that would be ignored.

You can limit the number of filter-match syslogd messages generated for each defensive filer. This can be enabled in the DMD configuration settings with a default log limit value. This default value will be used to limit the number of messages logged unless this value is overridden by the loglimit parameter when the filter is added or updated.

IPv6 addresses are now supported in PBR rules, address groups, and route tables.

A new reusable object called rules is available in the IPSec technology perspective. Users can create a single rule from a single location and reuse this rule in multiple stacks. This reduces the number of rules, and enables changes made to reusable rules from a single location to be applied to all stacks to which the rules are assigned.

To make the rule truly reusable, you configure both stack symbols and local IKE identities with a name associated with the configured values. You configure these values for each TCP/IP stack. After configuring a stack symbol or a local IKE identity for a stack, the names associated with the values are available to all stacks. You can assign unique stack values to the same name for each stack.

For example, on stack1 you configure a stack symbol value 1.1.1.1 and assign the name OSA to the value. On stack2 you can configure a different value, such as 2.2.2.2, to the name OSA. You can re-create a reusable rule and specify the name %OSA in the local data endpoint field. You can then assign this reusable rule to both stack1 and stack2. The stack symbol name %OSA will resolve to the correct IP address value associated with the name OSA per stack.

Stack symbol names can also be used in address groups. These address groups can be used as the local data endpoints in rules.

Stack symbol names and local IKE identity names can be used in both reusable rules and stack specific connectivity rules. They are likely most beneficial in the reusable rules model.

For more information about reusable rules see How to take advantage of reusable rules. .

Local IP addresses can be configured for each TCP/IP stack and have a name associated with the configured values. After configuring a local IP address and assigning it a name, the name is available to all TCP/IP stacks. You assign a unique IP address to the name for each TCP/IP stack. These names can be used in conjunction with the new reusable rules.

Rather than manually configuring the local IP addresses for each TCP/IP stack, the Configuration Assistant can discover the local IP address values and names from TCP/IP stacks. The discovery function connects to an active Policy Agent application running on a target TCP/IP stack. The discovery function is only available when you are using the z/OSMF client. For more information, see How do I discover and include configuration information from TCP/IP stacks on my z/OS systems?

New scan detection is available for the ICMPv6 protocol.

Eleven new IDS attack protection types were added. For each attack protection, the Configuration Assistant provides best practice default values. If stacks are using the IDS_Default requirement map settings, the new attacks are included with it. Otherwise, you may easily edit your requirement maps and enable the new attack protection types.

Data Hiding

Certain fields within a packet can be used to hide data. This support allows you to detect inbound IP packets that may contain hidden data. The following checks for hidden data can be enabled:

• The IP option pad fields are checked for hidden data. For IPv4 packets, the options field is in the IP header and can contain padding for alignment purposes. For IPv6 packets, a hop-by-hop option extension header or a destination extension header can include one or more PadN options for alignment purposes.
• The embedded packets within ICMP / ICMPv6 error messages are checked for hidden data.

IPv6 Destination Options

There are 256 possible IPv6 destination option values, with only a small number currently defined. This support allows you to prevent misuse of IPv6 destination options you are not intentionally using.

IPv6 Hop-by-Hop Options

There are 256 possible IPv6 hop-by-hop option values, with only a small number currently defined. This support allows you to prevent misuse of IPv6 hop-by-hop options you are not intentionally using.

IPv6 Next Header

An IPv6 packet header and any subsequent extension headers include a next header field. The next header field identifies the next header in the packet, either an upper layer protocol (such as TCP or UDP) or an extension header (such as fragmentation header or routing header). While there are 256 possible next header values, only a handful are in common usage today. This support allows you to protect your system against future attacks by prohibiting those next header values for IPv6 traffic that you are not actively and intentionally using.

IPv6 Outbound Raw

Most network attacks require the ability to craft packets that would not normally be built by a proper protocol stack implementation. This support allows you to detect and prevent many of these crafting attempts so that your system is not used as the source of attacks on other systems. As part of this checking, you can restrict the upper level protocols (such as TCP) allowed in an outbound RAW packet for IPv6 traffic. It is recommended that you restrict the TCP protocol (6) on the outbound raw rule.

TCP Queue Size

This support detects when a TCP connection's send, receive, or out-of-order queue becomes constrained. A queue can be constrained due to the amount of data on the queue or the age of the data on the queue. Optionally, the TCP connection can be reset when a constraint is detected. If the TCP connection is not reset, this support will continue to monitor the queue and detect when it becomes unconstrained. A queue size is specified in the rule's conditions. An exclusion list can optionally be specified in the rule's conditions.

Global TCP Stall

This support detects when an attack causes a large number of TCP connections to be stalled or unable to send data. A global TCP stall condition is detected for a TCP/IP stack when at least 50% of the active TCP connections are stalled. When the condition is detected, the stalled TCP connections are reset if the action specifies "Drop Packets or Connection", or "Both Drop and Report".

EE LDLC Check

The Enterprise Extender architecture defines five ports that map to SNA data priorities. The lowest port, usually 12000, is used for signaling data. If signaling data is received on any of the other ports, it is suspicious. If the EE LDLC Check attack type is enabled, receiving data on any of the other ports will detected as an attack. This type of attack can be a denial of service (DoS) attack designed to keep resources busy such that SNA LUs are not able to start sessions with applications on this host. An exclusion list can optionally be specified in the rule's conditions.

EE Malformed Packet

This support detects when the EE packets have incorrect information in the IP and UDP headers. For example, an EE packet that is too long or too short for the LDLC command is considered malformed, as well as, a packet that is not a valid EE command. An exclusion list can optionally be specified in the rule's conditions.

EE Port Check

This support checks the source and destination ports in the UDP header of received EE packets. The port values are expected to be the same. For example, both source and destination port are 12000 in a received packet. If the port values are not the same, this will be considered an attack packet. An exclusion list can optionally be specified in the rule's conditions.

EE XID Flood

A flood of XIDs can consume all available EE lines causing additional EE connection requests to fail. You can enable the EE XID Flood attack type to receive notification when an XID flood is occurring for a specific VIPA. An exclusion list can optionally be specified in the rule's conditions.

You can use the V1R13 Configuration Assistant to configure both V1R13 and V1R12 level z/OS systems. For each z/OS image configured, you indicate whether the z/OS level is V1R13 or V1R12. The Configuration Assistant will ensure that valid configuration is produced for the correct level system. For example, in V1R13 there are new IDS attack protection types. If you attempt to configure these new protection types for a z/OS image marked as V1R12, the Configuration Assistant will ignore these new attack types since they are not available on V1R12. The Configuration Assistant will provide appropriate warnings to ensure you are aware of any settings that would be ignored.

The following default AT-TLS rules are now available. RACF Remote Sharing Facility (RRSF) Client RACF Remote Sharing Facility (RRSF) Server Policy Agent Services Connection

Dynamic tunnels can be negotiated using either IKEv1 or IKEv2.

New encryption algorithm

Advanced Encryption Standard (AES) Cipher Block Chaining (CBC) 256-bit key

New authentication algorithms

AES Galois Message Authentication Code (GMAC) 128-bit key

AES GMAC 256-bit key (for dynamic tunnels only)

AES Extended Cipher Block Chaining (XCBC) 128-bit key (96-bit Integrity Check Value (ICV))

Hashed Message Authentication Code (HMAC) Secure Hash Algorithm (SHA2) 256-bit key (128-bit ICV)

HMAC SHA2 384-bit key (192-bit ICV)

HMAC SHA2 512-bit key (256-bit ICV)

New combined encryption/authentication algorithms (for dynamic tunnels only)

AES Galois Counter Mode (GCM) 128-bit key

AES GCM 256-bit key

New Diffie-Hellman groups to use for perfect forward secrecy (PFS)

Group 19

Group 20

Group 21

Group 24

New IKE phase 1 encryption algorithm for dynamic tunnels

AES CBC 256-bit key

New IKE phase 1 authentication algorithms for dynamic tunnels

AES XCBC 128-bit key (96-bit ICV) (IKEv2 only)

SHA2 256-bit key (With HMAC and 128-bit ICV where appropriate)

SHA2 384-bit key (With HMAC and 192-bit ICV where appropriate)

SHA2 512-bit key (With HMAC and 256-bit ICV where appropriate)

New IKE phase 1 pseudo-random function algorithms for dynamic tunnels (IKEv2 only)

HMAC Message Digest 5 (MD5)

HMAC SHA1

AES XCBC 128-bit key (96-bit ICV)

SHA2 256-bit key (With HMAC and 128-bit ICV where appropriate)

SHA2 384-bit key (With HMAC and 192-bit ICV where appropriate)

SHA2 512-bit key (With HMAC and 256-bit ICV where appropriate)

New IKE phase 1 Diffie-Hellman groups for dynamic tunnels

Group 19

Group 20

Group 21

Group 24

New IKE phase1 message authentication algorithms for dynamic tunnels (IKEv2 only)

Elliptic curve digital signature algorithm (ECDSA) with SHA-256 on the P-256 curve.

ECDSA with SHA-384 on the P-384 curve.

ECDSA with SHA-521 on the P-521 curve.

Key ID - ASCII

Key ID - EBCDIC

Key ID - hexadecimal

Enabling FIPS 140 provides a higher degree of assurance of the integrity of the cryptographic modules that are used, including ICSF and System SSL; however, enabling FIPS 140 might result in a reduction in performance. FIPS 140 restricts the available set of cryptographic algorithms, and it might require additional setup and configuration.

You configure FIPS 140 mode independently for each of the IKED, the NSSD and the TCP/IP stack components. FIPS 140 mode must also be configured in ICSF and System SSL. If you use FIPS 140 mode in some components and not others, the resulting system may not be operating in FIPS 140 mode. The components that are configured to use FIPS 140 mode may only use cryptographic services from components that are also operating in FIPS 140 mode, so the FIPS 140 mode mismatch may cause functional problems.

The following suites were added:

VPN-B Suite-B-GCM-128

Suite-B-GCM-256

Suite-B-GMAC-128

Suite-B-GMAC-256

Certificate Revocation checking

NSSD provides certificate revocation checking for IPSec. Configuration options to invoke this function are provided both at the stack level, and can be overridden at the connectivity rule level.

Certificate URL lookup for IKEv2 using NSSD

For IKEv2 connections, IKED can send URL lookup information to retrieve a digital certificate rather than including the certificate within the IKE payload. Configuration support is available at the stack level to indicate if this function is supported. Configuration identifying the local URL information is provided at the z/OS image level for NSSD.

Beginning in V1R12, all IP security connectivity rules must be compliant with RFC 4301. The ability to set Not compliant for a stack and bypass RFC 4301 checking is no longer available. Compliance with RFC 4301 is enforced.

IP filter policy support for filtering fragments was improved in z/OS V1R10. Before z/OS V1R10, Communications Server filtered all IP fragments using a policy of first possible filter match, and filtered IPv6 fragments as protocol IPv6Frag. Beginning in z/OS V1R10, Communications Server follows rules and restrictions established by RFC 4301 to ensure proper classification of fragments. RFC 4301, "Security Architecture for the Internet Protocol," specifies the base architecture for IPSec-compliant systems, including restrictions on the routing of fragmented packets.

Communications Server does not implement stateful fragment checking; therefore, restrictions were added as required by RFC 4301 to require that IP security connectivity rules applying to routed traffic not apply to specific ports, types, or codes. In z/OS V1R10 and z/OS V1R11 a setting was provided to optionally configure whether or not the RFC 4301 restrictions should be applied. Beginning in z/OS V1R12 this setting has been removed. All IP security connectivity rules must support the RFC 4301 rules and restrictions.

When running in z/OSMF, many informational, warning and error messages are now displayed as pop-up messages.

The following default AT-TLS rules are now available.

DB2 Requester

DB2 Server

IMS Connect

JES Client

JES Server

NSS Client (IKED as the NSS client)

An external security information and event manager, by analyzing and correlating messages from multiple sources and systems in the network, can take action to block attacks by installing defensive filters in your TCP/IP stack. A defensive filter is an IP filter rule to discard packets, separate from IP security filters, and is typically installed for a short duration (for example, 30 minutes) to block a specific attack or a pattern of attacks. If traffic being blocked by a defensive filter should be blocked on a long-term basis, update your configured IP security policy to add an IP security deny rule.

AT-TLS has been updated to support System SSL functions that were added since z/OS V1R7. The Configuration Assistant provides support for configuring the added functions.

• TLSv1.1 Protocol
• Use of RFC3820 to validate certificates
• FIPS 140-2
• Negotiation and use of a truncated HMAC
• Negotiation and use of maximum SSL fragment size
• Negotiation and use of handshake server name indication
• CRL LDAP server access security level

After creating an image and stack, new default connectivity rules are now defined for the user in the AT-TLS technology perspective. Enabling any of the default rules will generate a complete AT-TLS policy which can then be installed on the user's z/OS system. Each rule is defined to protect the specified application with a default level of security. By providing default rules for all known AT-TLS applications for the user, the Configuration Assistant makes it easier and quicker to create an AT-TLS policy. All existing AT-TLS rules are kept, along with the newer default rules. The user may configure AT-TLS rules using either the default rule approach or the previous requirement map approach.

Changes to the requirement map reusable objects help new users to understand these objects. Existing users will also benefit from better and easier dialogs. The new dialogs eliminate the step of creating requirement map objects prior to the creation of the connectivity rules. Now, requirement maps can be created seamlessly using the connectivity rule dialogs. The new panels also help users to visualize better the level of protection applied to their traffic in a connectivity rule. This change enforces the reusable nature of the requirement maps and help users to easily use this functionality. This has been implemented in both the IPSec and AT-TLS technology perspectives.

In addition to installing a particular policy file, there are a variety of tasks to perform before that policy file can be put into action. The tasks include defining RACF permissions, the configuration and startup of associated daemons, and the configuration of Policy Agent to bring it all together. From within a technology technology perspective, select an image in the tree node and click "Application Setup Tasks" to see a list of all the tasks that are needed to support that technology. For each task, you can read instructions for completing the task and the associated task material is set to match your configuration. These tasks are all optional and should be considered as just one possible way of preparing the application.

As you make changes in the configuration data, this may impact the contents of one or more policy files. Other changes may affect the setup information included in an application setup task. When these changes occur, the Configuration Assistant marks the install objects to alert the administrator that a previous policy install or setup task completion is no longer valid.

One important application setup task is to define a base location where the Configuration Assistant will, by default, deliver configuration materials. From the list of application setup tasks, the base location setup task is always listed first. Associated with the base location is the FTP information required to transfer the files themselves. When you specify a base file location, the Configuration Assistant will deliver individual configuration files to that base location using a naming convention. Once the configuration materials have been placed in the base location, you can make final changes to the files and have them reviewed before that material becomes active.

The base location may be a zFS path specification, a sequential data set HLQ, or a partitioned data set name. The naming convention used by the Configuration Assistant includes the stack names with which the material is associated. You may change the name and location of any the configuration materials at install time.

Base location information also includes a code page specification for the target z/OS system. If the z/OS system uses one of the listed EBCDIC code pages, the Configuration Assistant can transfer the file encoded to that code page.

The installation interface is improved to allow the collection of all configuration files available within a technology perspective. From within a technology perspective, select the z/OS images and click "Install All Files" to see a list of all files. The Configuration Assistant always maintains a time stamp of the most recent delivery of each of the files.

The Configuration Assistant can read in existing policy data syntax statements and parameters.

For IPSecurity and AT-TLS you can create groups of IP addresses and use these address groups as the endpoints for connectivity rules. This allows you to create a single rule that applies to a group of IP addresses.

• Support to protect traffic for mobile users with dynamic tunnels. Mobile user connectivity rules
• RFC 4301 compliance -

  RFC4301 states that you cannot use ports, types, or codes, as selectors when matching routed traffic. The reason for this restriction is that IP packet fragments may not contain these selectors. Therefore, to be compliant with RFC4301, you are not allowed to have any connectivity rules for routed traffic that use traffic descriptors defined with specific ports, types, or codes.

  Prior to V1R10, the default for traffic descriptors indicated the traffic would be matched for either local or routed traffic. As part of enforcing RFC 4301 compliance, this setting would no longer be valid if configured with TCP or UDP ports. Therefore, this setting has been removed from the traffic descriptors and is set based on the topology of each connectivity rule. Prior to V1R10, the topology selection of a connectivity rule was used to determine whether traffic was local or remote for IPSec tunnels, but not for filter rules. This now also applies to filter rules using security levels of Permit or Deny.

  When migrating from a pre-V1R10 release, the Configuration Assistant will update your configuration to the new use of the topology setting for filter rules. If the Configuration Assistant cannot properly determine the new settings, it shows a report indicating any required user actions.

• VPN-A supported as an IETF User Interface suite
• Option to generate ICMP errors on packet discard
• Manual tunnel security endpoint enhancements
• Traffic descriptors using ICMP or ICMPv6 can configure the type and codes as ranges
• Traffic descriptors can configure IPv6 Mobility Header as a protocol
• Security levels can configure the DSCP and do not fragment fields to propagate from the inner IP header to the outer IP header.
  • DSCP panel help
  • Do not fragment bit panel help

Prior to V1R9, you selected a specific technology to configure within the Configuration Assistant. With V1R9, you can configure all technologies together within a single Configuration Assistant instance. You can use a new import function to combine technologies.

• Option to use active or passive mode
• Separate log to aid in diagnosing FTP failures
• Enhanced error messages
• Auto save of pending changes after FTP

• Ability to enter comments when saving backing store file
• Ability to insert comment into produced flat file when FTPing to z/OS

• Flat file support for QoS policy
• Consistent and improved user interface
• No LDAP required

• QoS overview

• Flat file support for IDS policy
• Consistent and improved user interface
• No LDAP required

• IDS overview

• AES Cryptographic Algorithm Support
• Complete NAT Traversal Support
• IPv6 Support

• IPSec overview
• How does IPv6 affect IPSecurity?
• How do I protect IPv6 OSPF traffic?

• IPv6 Support

• AT-TLS overview
• How does IPv6 affect AT-TLS?