I was reading through my backed up email and saw the Veeam forum digest with a note from Gostev. I really wanted to point out a poor attitude here:
You can't go and put your heads under the sand with IPv6 rollout Veeam/Gostev. Perhaps in your home base of North America you have plenty of IPv4 space but here in Asia Pacific (APNIC), IPv4 address space is extremely hard to get now. Our whole company has transitioned to using a dual stack IPv6/IPv4 network with virtually everything (other than Veeam, an old VOIP system and Ubiquiti equipment) running native IPv6 and IPv4 being mainly for the none-IPv6 enabled internet. 98% of our network traffic is now IPv6 if you discount Veeam.While this bug is off the table, there is another newly discovered issue which we are seeing a lot with the customers who have upgraded to ESXi 6.0. Fortunately, this one is environmental-specific and has a workaround that should work for majority of users. The issue causes jobs using Direct SAN access mode to crash on backup proxies with a large amount of NIC adapters having IPv6 enabled. The actual fault sits in one of the VDDK 6.0 libraries, in the function that collects DNS addresses from all proxy NICs, and puts them into a string. When string's length becomes larger than certain amount of characters, VDDK crashes. As you can probably guess by now, the main issue here is IPv6 address length. For example, in our own lab VDDK does not have any issues with a backup proxy having 10 IPv4-only adapters does not have any issues, however it crashes on a backup proxy with a single IPv4 adapter and 7 IPv6 adapters.
Obviously, aside of removing some of the unused network interfaces, the easiest workaround is to simply go into each NIC's properties, and disable IPv6 – which is enabled by default on every network connection, but rarely actually used - outside perhaps huge telecoms and service providers. We are also testing the code that patches the faulty VDDK function, and if all is well, this will be available momentarily as a hot fix for customers who cannot disable IPv6. Also, due to how wide spread the issue is – over 50 support cases as of end of last week – we are now considering releasing the new Update 2 build (U2a) with the fix embedded. This will also give us a chance to address a few other, less wide-spread U2 support issues. I will keep you posted regarding this newer build.
I have seen a similar attitude from Ubiqiuti and it was only recently that our mail server (Smartermail) was enabled for IPv6. It seems that many of these North American software companies are oblivious to the fact IPv4 exhaustion is here. Parts of the world and many companies in South East Asia have already enabled IPv6.
This problems hasn't had any effect on us but I really dislike this "throw away" attitude of disabling IPv6 to fix poorly implemented/tested software. While I realise this is a VMware rather than Veeam fault - suggesting disabling is not the right approach guys!