ipv6 doesn't work with network bridged to wlan on mac

I made a VM with bridged networking. The guest is running Ubuntu 9.10 (Karmic) i386 with the linux-virtual kernel.
It gets a v4 address via dhcp and v6 addres via stateless autoconfiguration. I can ping the host's ipv6 address from
the guest and vice versa. The guest also gets the v6 default gateway correctly, but I can't ping6 its link-local
address (using ping6 -I eth0 <gw-addr> and I can't get anywhere using ipv6.

Everything work bridging to wired interface. The same VMs are able to ping remote and local machines. The problem is only with bridging to wlan interface. Is there anything in wlan specs that avoid the presence of two MAC addess? I guess not because IPv4 just works. My packet sniffing from host machine interface and from the remote (another linux and real) machine shows that NDP (ipv6's ARP) from a VM is sent and answered by the real remote machine. However, the answer does not arrive.
If I send cross ping (from VM to remote and from remote to VM at the same time), NPD in Linux, probably based on the NPD neighbor solicitation received from the VM, manages to find the remote machine MAC. However, in this situation, ping still does not work. It sends ICMP echo, VM answer but the answer does not arrive to the real machine.

Maybe this is a Linux IPv6 problem over wlan and not VBox problem.

This is the neighbor that my router list when I ping from both real machines and from vm at the same time:

I use Linux (ubuntu). I didn't understand your last comment. Linux support ipv6 over wlan but it does not support bridge over wlan, specially for ipv6? Is that it? Or it is vbox that does not support ipv6 bridge over wlan in Linux? Would Windows support it? Who is lacking the support?

For now, IPv6 is not cricital. However, in the near future, this will be a must-have feature. It currently have no NAT support and without bridge for wlan, only host-only and manual routing remains as an option. However, not everyone would have a spare IPv6 subnet avaiable for it, specially if needed for each host machine.

What do you suggest in order to have IPv6 connectivity for VMs over host wlan connection?

I meant to say that VirtualBox does not support IPv6 when guest is configured to use "bridged adapter" attached to wlan interface on Linux or Mac OS host. It is in the manual, section 6.4. Perhaps we should change the type of this ticket to "enhancement" unless somebody confirms that there are problems with IPv6 when attaching to wired interfaces.

RAs from the router are received fine in the guest system and autoconfigured global address. When trying to ND the default gateway (link-local address of the router), it sends the neighbor solicitation, router replies with neighbor advertisement (can be seen when sniffing with Wireshark on the host systems wireless interface, but the neighbor advertisement doesn't reach the guest system at all.

Result: broken IPv6 connectivity leading to long timeouts due to applications trying dualstack operation!

So if that cannot be fixed easily, IPv6 should be filtered completely for the guest system in order to avoid "half-working" IPv6 (SLAAC words, DAD doesn't but noone notices, ND fails completely and thus operational traffic fails).

Fedora 14 guest system as described above. Start up Firefox (3.6.13), surf to http://start.fedoraproject.org/ (dual-stacked host). It takes 13 minutes for that to fall back to IPv4! Of course this abymal long timeout is not VBox' fault, but that's what "real users" will experience because of half-broken IPv6 by VBox.

OK, this problem is really serious. Maybe some comments might be from other problems.

I'm going to try to summary it with what I notice with myself and what I read in this bug report:

It occurs in any host OS: MAC(reporter), Windows and Linux(myself)

It occurs only with hosts that use WLAN interface

There is no problem with IPv4 (so no ethernet broadcast problem?)

VM receives RA packages and get a valid ipv6 addess

In my case, for Linux endpoints (VM and external machine), if both pings each other, NDP gets filled by the address in NDP request of the other part and ping succeeds. So, no problem with part of ICMPv6.

It seems to be something related exclusively to NDP ICMPv6 packages and over WLAN. Weird.

I can add that Windows 7 also has the issue.
I verified that it's fine on wired interfaces under Linux host OS (ubuntu).
It does seem to be an issue with ND responses not making it to the guest OS, even though they're IPv6 unicasts.
I can see the Neighbor Solicitations go out from the guest OS, and the target host respond with a unicast Neighbor Advertisement. But this response never makes to to the guest OS.

Here's some tcpdump output from the IPv6 target of the ping (IPv6 prefix obfuscated):

Of interest here is the fact that the solicitation is sent using the host OS' MAC address, but the response from the target of the ping6 is directed to the guest OS' MAC address (it obviously pulls this from the "source link-address option" section of the packet). The host OS in this case is Windows 7, guest is gentoo linux, the host NIC is a WLAN interface.

I originally thought that this was a guest O/S problem, because these guest operating systems work fine on my server
with wired LAN and IPv6. I haven't attempted using IPv6 over wired LAN on my Windows 7 laptop, but will give it a try
in the next few days.

With events like World IPv6 Daycoming up, there are likely to be more and more VirtualBox
users running into this problem.

I wonder when this bug will be fixed.
I just tripped it on Ubuntu 11.04 x64 with VBox 4.1.0 from the Oracle/Vbox Repository. In the VM Win7 (bridged over WiFi) gets v6 addresses etc. but ping www.google.com failing with timeout, on the hostmachine it works on over IPv6.
Does this bug need to be open another nearly 2 years until a fix is released?

Disappointed that it wasn't fixed in 4.1, I grabbed the sources to see
if there was anything obvious. The source code seems pretty straight
forward without anything obvious that would prevent IPv6 from working.

From my packet observations, network discovery is working just fine, so
the interface get an address. When it tries to send an outgoing packet
though, it needs to do address discovery to find the MAC address to
send the packet to. The disovery packet makes it out and gets to the
destination, the reply packet makes it onto the wire, but doesn not
make it to the guest OS.

One experiment that I might try is it to see if I can get IPv6 working on an
internal vnet, that should eliminate the bridging to the physical network
as a source of the problem.

This is similar to my own observations. The incoming packets just don't make it from the host OS to the guest OS.
Based on your investigation on the source code, it would seem that it's something on the OS level that is behaving differently
in this situation. It may require some special set up, or perhaps it might even be beyond anything that the Vbox people can do.

I was hoping that perhaps it was some filtering layer between the host and guest that needed adjusting (maybe it was blocking IPv6 ethertype
or something), but I guess it's more complicated of an issue.

Ok, I think I've found the problem in the code, something I had not looked at before.

In VBox/Devices/Network/SrvIntNetR0.cpp:2518 there is a block of IPv6 code that is commented out. The code is commented out because
it has not really been implemented yet and the support functions are not there. The net result of this is that incoming packets do not
get routed to the guest like IPv4 packets do.

For wireless, MAC addresses need to be rewritten for incoming packets so that they have the address of the guest and not the address
of the host.

I would be glad to assist with implementing this bit of functionality, I can provide the networking expertise if some one has the
VBox expertise.

The VirtualBox dev team fixes bugs on best-effort base. As the fix is not only a one-liner, it will take more time to investigate and to implement the code. You might have seen that there are a lot of open bugs.

I'm currently trying to track down a bug that looks very much like this bug, but I'm experiencing it with a guest bridged to a *wired* network interface. Can anyone confirm if this is, in fact, the same bug, or should I file a separate bug?

Setup:

VM guest: Linux 3.1.0 (Debian)

VM host: Windows 7 x64

VM guest has a network interface bridged to the vm host's ethernet interface

This patch adds support for ipv6 on bridged network configurations using MAC address sharing (mostly on wifi). It could probably use more testing but has been working fine for days on two macbooks (air and pro) with 2-3 VMs running on each, on the same ethernet segment.

The code modifies ICMPv6 Neighbor Discovery packets going over the trunk connection by replacing the MAC address advertised by VMs with the physical MAC address of the trunk interface, and uses the same MAC NAT code as IPv4.
Most of the MAC NAT code was written with ipv6 in mind (kudos to the developers for that), the only missing piece was the icmpv6 parsing and modification code.

New entries will be added to the MAC NAT table when seeing ipv6 traffic originating from VMs.
Flushing of stale entries occur when we receive Duplicate Address Detection packets from the trunk interface for an address which is present in the table (which means that someone on the network is trying to acquire an address that we have in our cache).

The MAC address sharing mechanism only applies to traffic going over the trunk. VM to VM traffic as well as traffic between the host and VMs will use the unmodified MAC addresses of the VMs.

The patch was developed and tested on MacOSX 10.8 (Mountain Lion) 64-bits, compiled with gcc 4.2 (llvm-gcc coming with Xcode won't work, for people looking to install gcc 4.2 on Mountain Lion, look at https://github.com/kennethreitz/osx-gcc-installer), using VirtualBox 4.2.6 as codebase.
I had to compile with --disable-hardening --disable-opengl --disable-python because of compile errors against the OSX 10.8 SDK, but none of these should impact the network in any way (correct me if I'm wrong).

I have been transferring tens of gigabytes between VMs and the local network without any problem so far. Guests OSes are a mix of ubuntu 32 and 64 bits, using privacy extensions (random generation of ipv6 addresses).
Unfortunately, I did not have any other guest OS to test with.

Simon, thanks for the patches! I just want to let you know that we are testing your patches and that we found a problem if a remote host tries to resolve IPv6 addresses belonging to a VM. We are currently working on fixing this problem. More information soon.

thanks for the update.
Could you please describe your failing test case? I wrote the code and have a testbed set up, so fixing this bug should not take me very long.

I was able to ssh into VMs from the host and from other computers sitting on the local network and from the internet without any problem. The computer hosting the VMs was running OSX 10.8.3, with VMs being ubuntu 32 and 64 bits, if that makes any difference.

Note that for ipv6 to work, multicast has to be forwarded by the wireless access point, which some old routers/access points might have problems with.

Note that for ipv6 to work, multicast has to be forwarded by the wireless access point, which some old routers/access points might have problems with.

That is precisely the problem. Some wireless routers/access points replace Ethernet multicast destination addresses with unicast ones. We need to work around this problem.

Wow, interesting. I knew of multicast traffic not being propagated, but this is new to me.
I don't see how an access point could reliably swap multicast destination mac addresses with unicast ones, this is just asking for trouble.
If you don't mind, what make/vendor is it?

Does it only affect VMs inside virtualbox? If it also affects the host's ability to use ipv6, I would advise not to work around it.
The access point needs to be fixed instead and it will cause problems with other devices as well.

In this example, 08:00:27:11:76:b6 is the mac address of my VM and 54:26:92:c0:bd:d1 is the address of my laptop's airport interface.
In this trace, my VM (linux) is querying the link-local address of my local router.
The local router adds an entry to its ND cache (2601:9:8cd0:77a1:a00:27ff:fe11:76b6 is at 08:00:27:11:76:b6), and sends neighbor advertisements back to 08:00:27:11:76:b6, which are in the end not passed to my laptop (they should be directed at 54:26:92:c0:bd:d1 for this to work).

Even weirder, build 4.2.51-86105-OSX, which had been posted on the mailing list as a test build (to fix an issue with 3d rendering if I recall correctly) had the fix included.
I have tested it thoroughly and used it successfully for weeks while waiting for the new version to be released.

Note that for ipv6 to work, multicast has to be forwarded by the wireless access point, which some old routers/access points might have problems with.

That is precisely the problem. Some wireless routers/access points replace Ethernet multicast destination addresses with unicast ones. We need to work around this problem.

Wow, interesting. I knew of multicast traffic not being propagated, but this is new to me.
I don't see how an access point could reliably swap multicast destination mac addresses with unicast ones, this is just asking for trouble.

It seems unfortunately this bug still hasn't been fully fixed. I haven't actively tried to get IPv6 working before 4.3.18, but for me this is only partially working (now using 4.3.20).

I can ping the host and the router/gateway, I can even connect to the router via http using both its private and global ipv6 address, but as soon as I try to leave the local network (for example ping6 www.google.com) I get a timeout. Posting my problems on the Gentoo forums didn't raise any apparent configuration or routing issues. After that I've tried various VM's (Windows 7, Gentoo, Arch Linux, Kubuntu and KNOPPIX) and all experience the same issue, an IPv6 address is configured but trying to reach anything on the internet results in a timeout.

My VM uses a bridged adapter connected to a wlan adapter on the Windows host system (with Wired Connection checked).

My setup is a FRITZ!Box 7360 router that gets an IPv6 prefix from my ISP, the router has DHCP enable for both IPv4 and IPv6. My host system is connected via a wireless adapter to a separate wireless AP (that has no DHCP or firewall configured) which is in turn connected by wire to my router.

My setup is a FRITZ!Box 7360 router that gets an IPv6 prefix from my ISP, the router has DHCP enable for both IPv4 and IPv6. My host system is connected via a wireless adapter to a separate wireless AP (that has no DHCP or firewall configured) which is in turn connected by wire to my router.

What kind of packet captures would you like to see? Or a tcpdump or wireshark example you'd like me to do?

To minimize additional requests for captures, can you capture everything, as seen by the host's wireless interface, starting with guest's boot, and including a successful local connection and failed remote connection?

I've made a capture the hosts wireless interface and the VirtualBox virtual interface on the host. Started the capture, then booted the VM, did some ping6's to various local and global addresses of the host and router which got replies execpt for 1 which is probably blocked, also did some ping6's to www.google.com which failed, tried www.test-ipv6.com which failed too, and accessed the router via http through its ipv6 address which succeeded. Then shutdown the VM.

Can I send the capture via e-mail or in an otherwise non-public way? My e-mail is marijn@….

In the last past years several people looked at it, taking the network capture and concluded that the problem exists only in combination with a wireless interface. Wired works just fine. Look at the posting from three years ago, there is the clue about the problem. The Hypervisor doesn't pass on the packet to the guest OS that comes as an answer to the ND (Network Discovery) packet request. The response packet is received on the host, but the hypervisor doesn't passes it on to the guest OS. That's the reason the entries don't show up in the guest OS.

RAs from the router are received fine in the guest system and autoconfigured global address. When trying to ND the default gateway (link-local address of the router), it sends the neighbor solicitation, router replies with neighbor advertisement (can be seen when sniffing with Wireshark on the host systems wireless interface, but the neighbor advertisement doesn't reach the guest system at all.

Result: broken IPv6 connectivity leading to long timeouts due to applications trying dualstack operation!

So if that cannot be fixed easily, IPv6 should be filtered completely for the guest system in order to avoid "half-working" IPv6 (SLAAC words, DAD doesn't but noone notices, ND fails completely and thus operational traffic fails).