The specified discover range in the OneClick Discovery UI is limited for IPv6 addresses, so dashes are not permitted. Input is any legal address format (refer to RFC 4291).
Server/client connections are first attempted using IPv6 addresses. If that fails, the IPv4 address is used as IPv6 is backward compatible with IPv4.
An IPv6 address consists of eight sets of four hexadecimal characters of 0-9 and A-F, with each set separated by a colon. Leading zeros and zero value sets are abbreviated.
i.e.: 1080:0000:0000:0000:0008:0800:200C:417A becomes 1080:0:0:0:8:800:200C:417A
Furthermore, consecutive zero sets are replaced by a pair of colons (only once)
i.e.: 1080:0:0:0:8:800:200C:417A becomes 1080::8:800:200C:417A
eHealth reports display addresses using the proper formatting characters (colons or dots) as per the address type. Square brackets are used with IPv6 address/port combination.
Where systems are dual IP version addressed and a host name lookup (/etc/hosts, NIS or DNS) occurs, the address resolves to an IPv4 address.
New Traffic Accountant with enhanced Netflow support handles IPv6 source and destination addresses. Netflow itself does not recognize IPv6 transport protocol.
Trap agents with an IPv6 address create compliance complications because there is no agreed standard.
-The ASN.1 IP address primitive is four bytes by existing standards but there is no new primitive defined for IPv6.
-In a pdu, the IP address has always been length encoded and the length value has always been four.
-SNMPv1 traps from Cisco routers with IPv6 addresses overload the trap headers and set the length value to 16.
-eHealth goes one step further in allowing the construct in variable bindings in SNMPv2c traps as well.
There are some limitations for IPv6 address-only systems or where IPv6 addresses are primary:
FlexLm v9 License Manager
Brass SNMPv3 Proxy Agent
Windows 2003 (partial compliance)
Oracle 10g and FlexLm v9 do not support IPv6. However, all connections between these components and eHealth are local, and all IPv6 systems support local IPv4
connections even if the system does not have as assigned IPv4 address.
The Brass proxy agent must reside on a system with an IPv4 address because it does not support IPv6.
Windows 2003 is only partially compliant. eHealth supports this particular implementation by mimicking the dual stack behavior. For eHealth servers, this
means opening at least two listening sockets, one for IPv4 and one for IPv6 connections. For clients, this means attempting to connect first using IPv6
and failing that, falling back for an IPv4 connection.
One areas where eHealth cannot compensate for Windows 2003 partial compliance is FTP support. Windows 2003 FTP cannot connect to an IPv6 address. For
eHealth, this means that all Integration Modules must reside on systems with at least one IPv4 address and whose host name resolves to an IPv4 address.
This includes the remote poller.
Preparing for IPv6:
Solaris 2.9 and 2.10 work out of the box.
HPUX 11.11 requires patches PHINE_35351 and PHINE_35453 (this is subject to change by HP).
HPUX 11.23 works out of the box.
Windows 2003 SP1 and SP2 require installation of TCP IP v6.
The installation command for Windows 2003 is "netsh interface ipv6 install" ('uninstall' will disable).
Through the Windows UI: Network connections->install->protocols->click add to add and select TCPIP v6.
*Running the following from the command line will show if IPv6 has a.lready been set up: netsh interface ipv6 show interface.
-The Apache Web server for eHealth 6.1 supports IPv6 as long as the Web browser also supports IPv6. Any Firefox browser and Internet Explorer 7 (IE7) support IPv6 while IE6 does not.
-On Windows 2003, IE6 does not support IPv6. eHealth OneClick (OCE) will not work with IPv6 addresses unless IE7 is installed on the host.
-All of the eHealth 6.1 Live Health clients (Exceptions, Status and Trend) support IPv6.
-All of the eHealth 6.1 peripheral products (e.g. SystemEDGE and Trap Exploder) support IPv6.
-Both SystemEDGE and the CA NSM agent do not record data for IPv6 interfaces. This means that IPv6 interfaces on systems where one of these agents is running cannot be discovered by eHealth.
-SystemEDGE agents on systems with an IPv6 address do not present the IPv6 address as the trap source when sending traps. This makes it impossible for eHealth to match the trap to the corresponding element for the IPv6 addressed agent
-The Application Response (AR) controller (as all eHealth servers do) supports IPv6. The AR agent for eHealth 6.1 can monitor IPv4 traffic on a system with an IPv6 address but it cannot monitor IPv6 traffic.
-For users of the eHealth High Availability (HA) feature, while Sun Cluster does support IPv6, the Veritas clusterware package does not. The virtual host must have an IPv6 address when using Sun Cluster to enable eHealth IPv6 support.
-For users of the eHealth Disaster Recovery (DR) feature, because XOSoft WANSync does not support IPv6, enabling DR disables eHealth IPv6 support.
-The Traffic Accountant module for eHealth 6.1 supports IPv6 for RMON2 probes and the Cisco Netflow NMS does not support IPv6.
-While both Spectrum and eHealth support IPv6 individually, the integration of Spectrum with eHealth does NOT support IPv6..