Linux: Link local IPv6 address is the only one returned for host-only interfaces

[timuralp]

When configuring IPv6 on Linux, the interface may have a Link Local Address (fe::) in addition to the address configured through VirtualBox. VirtualBox retrieves the addresses from /proc/net/if_inet6. Here is an example of what these entries look like:

$ cat /proc/net/if_inet6 
00000000000000000000000000000001 01 80 10 80       lo
fd22dfff102810700000000000000000 06 40 00 80 vboxnet3
fe80000000000000020acdfffe20a291 02 40 20 80     eth0
fe80000000000000080027fffe000003 06 40 20 80 vboxnet3

Note the order of the addresses. When VirtualBox parses the file, the code assumes there would only be one entry for an interface (and does not terminate early), i.e. (this is NetIf-linux.cpp):

173             for (;;)
174             {
[...]
182                 if (n == EOF)
183                     break;
184                 if (n != 9 || uLength > 128)
185                 {
[...]
188                     break;
189                 }
190                 if (!strcmp(Req.ifr_name, szName))
191                 {
192                     pInfo->IPv6Address.au32[0] = htonl(IPv6Address.au32[0]);
193                     pInfo->IPv6Address.au32[1] = htonl(IPv6Address.au32[1]);
194                     pInfo->IPv6Address.au32[2] = htonl(IPv6Address.au32[2]);
195                     pInfo->IPv6Address.au32[3] = htonl(IPv6Address.au32[3]);
196                     ASMBitSetRange(&pInfo->IPv6NetMask, 0, uLength);
197                 }
198             }
199             fclose(fp);
200         }

For the above example, the last, Link-Local entry wins. Since VirtualBox does not handle multiple addresses per interface, it should at least ignore the Link-Local automatically created addresses. Unfortunately, this means that it would be impossible to tell which address to pick if a user configures a different link-local address.

I attached a proposed patch to resolve this.

[timuralp]

I am adding the above patch under the MIT license if anyone wants to use it or integrate it into the existing VirtualBox code.

[timuralp]

I noticed that this becomes an issue only if the autoconf flag is set for the interface (which I'm observing to be the case by default in the newer kernels -- 4.3). If IPv6 autoconf is disabled, exactly one address is present. I will look into whether the vboxnetadp|flt drivers could be modified to explicitly disable IPv6 auto-configuration.

[Valery Ushakov]

Replying to timuralp:

I will look into whether the vboxnetadp|flt drivers could be modified to explicitly disable IPv6 auto-configuration.

This is not the right direction. The problem is entirely different. API should report whatever is configured in the VirtualBox global settings, not what happens to be configured on the interface. But fixing this properly requires some thinking about potential fallout from the change in API behaviour.

[Valery Ushakov]

#8796 and #12459 are other manifestations of this underlying problem.

[timuralp]

Replying to vushakov:

This is not the right direction. The problem is entirely different. API should report whatever is configured in the VirtualBox global settings, not what happens to be configured on the interface. But fixing this properly requires some thinking about potential fallout from the change in API behaviour.

Makes sense. I'm happy to look into making such a change. Assuming that VirtualBox ensures the interface settings are in-sync with the current configuration, however, I'd imagine it wouldn't affect the consumers. I also noticed that if the interface is not up, then VirtualBox does already return the currently configured values (rather than what the interface reports).

Another (possibly related) issue with IPv6 configuration is where issuing VBoxManage hostonlyif ipconfig <iface> --ipv6 <addr> results in adding an address to the interface and does not remove the previously configured one. This may not be a big deal, but did not match my expectations for the VBoxManage interface. I'll see if I can figure out the right place to fix that (let me know if I should open a separate ticker for it).

[Hoang Tran]

As I observed, this bug also exists on MacOS hosts (10.11.2).

The patch is fine for local developments, but it does not work for those who want to share vagrant boxes.

[alopez]

How is the status of this bug? Without an official fix, it is not possible to work with IPv6 private networks and Vagrant