CARP takeover in IPv6 network


In my last article I was describing issue with CARP in Virtual Infrastructure. Issue was focussed to IPv4 protocol that is still more widened than IPv6. However, today is commonly used Dual stack in Enterprise and Educations infrastructures, it means IPv4 and IPv6 simultaneously. IPv6 protocol has many differences compared to IPv4 and require also different way of troubleshooting. This article is focused to compare IPv4 and IPv6 takeover in CARP environments.

Difference of behaviour between IPv4 and IPv6 I was finding incidentally during implementing CARP onto CentOS 7. For CentOS 7 is CARP available only from EPEL repository and what more – isn’t implemented well. So, therefore I was rebuilding RPM package from source code and add native support for IPv6 into base configuration file. This release of CARP package is accessible through my repository located on

Comparison of CARP takeover for IPv4 and IPv6

As was described in previous article for floating IPv4, node that takeover floating IP is announce this state by sending advertisement to multicast address In this message is announcing „I’m new holder of specified IP address“. This situation occurs when Slave is not receiving Masters advertisement for three times in row. So, Slave is sending ARP Gratuitous to inform all other machines and routers in subnet about fact that he is new Master. Scenario is described on picture below.


In case of IPv6 is scenario little bit different. That’s rooted from IPv6 architecture because in IPv6 protocol is function of ARP replaced by NDP(Neighbor Discovery Protocol) that is among other things responsible for finding correct MAC addresses of a neighbors. Main difference is that new holder of IP address, in case of CARP, can’t send Neighbor Advertisement without receiving Neighbor Solicitation. Message Neighbor Advertisement is in principle replacement for ARP Gratuitous. In case of IPv6 it means that CARP can’t somehow force router to update his IPv6 Neighbor table because can’t send Response(Advertisement) without Request(Solicitation). That is possible only in case of IPv4 ARP Gratuitous. Conclusion is that destination floating IPv6 can be unavailable up to 30 seconds in case of default timers. Real time depends on router timer settings (or each IPv6 neighbor in subnet). In case of Cisco routers is default expiration of Neighbor table set to 30 seconds.

Situation on picture above is following. Master node lost IP connectivity. After 3 seconds(CARP Hello timer set to 1 sec) Slave node takeover virtual IP address 2001:db2::1:1 and this IP is set to interface immediately. But unfortunately IP is still not reachable because border router is still holding in his Heighbor table old record, it means that neighbor 2001:db2::1:1 has MAC AA:BB:CC:DD:EE:F2 but real situation is now different. So, it means that router is waiting for expiring record and then send new Neighbor Solicitation ang obtain respond from new active node(Master). In case of IPv4 address is node after takeover immediately sending ARP Gratuitous and border router is updating his ARP table accordingly.


Conclusion is simple – do not be afraid that availability of your services on IPv6 is more delayed during takeover than on IPv4. If validity of neighbor table is set on your border router to more that 30 seconds, you can decrease them, but keep in mind that each decreasing of this value is generating more traffic in your subnet.