IPv6 – Known Issues / Restrictions

# ip -o addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
     \    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
1: lo    inet 127.0.0.1/8 scope host lo
1: lo    inet6 ::1/128 scope host
     \       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
     \    link/ether d2:05:de:4f:a2:e6 brd ff:ff:ff:ff:ff:ff
2: eth0    inet 172.17.100.77/22 brd 172.17.103.255 scope global eth0
2: eth0    inet 172.17.100.79/22 scope global secondary eth0
2: eth0    inet 172.17.100.80/22 scope global secondary eth0
2: eth0    inet6 2001:5c0:110e:3364::1:2/64 scope global
     \       valid_lft forever preferred_lft forever
2: eth0    inet6 2001:5c0:110e:3300:d005:deff:fe4f:a2e6/64 scope global dynamic
     \       valid_lft 86393sec preferred_lft 14393sec
2: eth0    inet6 fe80::d005:deff:fe4f:a2e6/64 scope link
     \       valid_lft forever preferred_lft forever

So for the above output from the ip command, the following lines contain virtual IP addresses for the eth0 interface:

2: eth0    inet 172.17.100.79/22 scope global secondary eth0
2: eth0    inet 172.17.100.80/22 scope global secondary eth0

‘IPV6_AUTOCONF = No’ for /etc/sysconfig/network-scripts/ifcfg-<nicName> is not being honored on reboot or boot

On boot, a stateless, auto-configured IPv6 address is assigned to the network interface. If a comm path is created with a stateless IPv6 address of an interface that has IPV6_AUTOCONF=No set, the address will be removed if any system resources manage the interface, e.g. ifdown <nicName>;ifup <nicName>.

Comm path using auto-configured IPv6 addresses did not recover and remained dead after rebooting primary server because IPV6_AUTOCONF was set to No.

Solution: Use Static IPv6 addresses only. The use of auto-configured IPv6 addresses could cause a comm loss after a reboot, a NIC change, etc.

While IPv6 auto-configured addresses may be used for comm path creation, the system administrator should be aware of the following conditions:

• IPv6 auto-configured/stateless addresses are dependent on the network interface (NIC) MAC address. If a comm path was created and the associated NIC is later replaced, the auto-configured IPv6 address will be different and LifeKeeper will show the comm path is dead. The comm path will need to be recreated.
  
  
• With Red Hat Enterprise Linux, implementing the intended behavior for assuring consistent IPv6 auto-configuration during all phases of host operation requires specific domain knowledge for accurately and precisely setting the individual interface config files AS WELL AS the sysctl.conf, net.ipv6.* directives (i.e. explicitly setting IPV6_AUTOCONF in the ifcfg-<nic> which is referenced by the ‘if/ip’ utilities AND setting directives in /etc/sysctl.conf which impact NIC control when the system is booting and switching init levels).

IP: Modify Source Address Setting for IPv6 doesn’t set source address

When attempting to set the source address for an IPv6 IP resource, it will report success when nothing was changed.

Workaround: Currently no workaround is available. This will be addressed in a future release.

IP: Invalid IPv6 addressing allowed in IP resource creation

Entering IPv6 addresses of the format 2001:5c0:110e:3368:000000:000000001:61:14 is accepted when the octets contain more than four characters.

Workaround: Enter correctly formatted IPv6 addresses.

IPv6 resource reported as ISP when address assigned to bonded NIC but in ‘tentative’ state

IPv6 protected resources in LifeKeeper will incorrectly be identified as ‘In Service Protected’ (ISP) on SLES systems where the IPv6 resource is on a bonded interface, a mode other than ‘active-backup’ (1) and Linux kernel 2.6.21 or lower. The IPv6 bonded link will remain in the ‘tentative’ state with the address unresolvable.

Workaround: Set the bonded interface mode to ‘active-backup’ (1) or operate with an updated kernel which will set the link state from ‘tentative’ to ‘valid’ for modes other than ‘active-backup’ (1).