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

[erno]

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.

[erno]

I guess whatever proxy arp / mac-address nat type hack virtualbox is using breaks with ipv6 (802.11 doesn't allow true bridging as ap<->client protocol assumes client has a single mac address).

Could this problem be solved by implementing nd proxy (ipv6 equivalent of proxy arp) described in RFC4389?

Also, I notice the documentation says ipv6+bridge doesn't work on linux or mac - does it work on windows?

[dbp]

This issue is not limited to wlan but ordinary IPv6.

Host 1: Windows Vista + Virtualbox 3.0.10 Guest1: Debian Lenny

Host 2: Windows XP + Virtualbox 3.0.12 Guest2: Debian Lenny

For ping tests with no firewall enabled at all:

Host 1 -> Host 2 : Success Host 1 -> Guest1 : Success Host 2 -> Guest2 : Success Host 1 -> Guest2 : Failed Host 2 -> Guest1 : Failed Guest1 -> Guest2 : Failed

Ping 2 times, packets sniffered by wireshark @ host 1 (IPv6 address simplified for better view):

Host1 -> Guest1:

2001::3 ff02::5 ICMPv6 Neighbor solicitation 2001::5 2001::3 ICMPv6 Neighbor advertisement 2001::3 2001::5 ICMPv6 Echo request 2001::5 2001::3 ICMPv6 Echo reply 2001::3 2001::5 ICMPv6 Echo request 2001::5 2001::3 ICMPv6 Echo reply

Host1 -> Host2:

2001::3 ff02::8 ICMPv6 Neighbor solicitation 2001::8 2001::3 ICMPv6 Neighbor advertisement 2001::3 2001::8 ICMPv6 Echo request 2001::8 2001::3 ICMPv6 Echo reply 2001::3 2001::8 ICMPv6 Echo request 2001::8 2001::3 ICMPv6 Echo reply

Host1 -> Guest2:

2001::3 ff02::7 ICMPv6 Neighbor solicitation 2001::7 2001::3 ICMPv6 Neighbor advertisement 2001::3 2001::7 ICMPv6 Echo request 2001::3 2001::7 ICMPv6 Echo request

[Paul]

I can confirm dbp's findings and have also tested a Window 7 guest which was also not able to ping any other hosts except the VM host.

[Daniel Tams]

I can confirm this issue. I have tested with Mac OS X 10.6.4 as a host and OpenBSD 4.7 as a guest and VirtualBox VM version 3.2.10 r66523.

[Luiz Angelo Daros de Luca]

This is still present in VBox4.0. I get stateless ipv6 address, I can ping host but I can't ping router. My network is over wlan.

[Aleksey Ilyushin]

With VirtualBox 4.0.2 I can ping guest-to-remote-guest or any other possible combination without any issues.

• Host1: Mac OS X 10.6.6 64-bit with VirtualBox 4.0.2 bridged to en0 (Ethernet)
• Guest1: Fedora 12 32-bit
• Host2: Ubuntu 10.10 64-bit with VirtualBox 4.0.2 bridged to eth0 (Ethernet)
• Guest2: Ubuntu 9.10 32-bit

luizluca, can you ping your router via IPv6 over wlan from your host? In other words does your wireless router support IPv6? Because there are lots or wireless routers that do not.

Can anybody confirm that the problem is still present in VirtualBox 4.0.x with bridging to wired interfaces?

[Luiz Angelo Daros de Luca]

My router support IPv6. It uses OpenWRT firmware (linux), specially compiled to contain IPv6 support. I tested with multiple VM OS (Windows and MAC OSX).

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:

root@router:~# ip -6 nei

2001:1291:23f:2:3ca8:661d:f9eb:9458 dev br-lan lladdr 08:00:27:cf:c7:9f DELAY fe80::215:afff:fe66:a27 dev br-lan lladdr 00:15:af:66:0a:27 REACHABLE 2001:1291:23f:2:216:eaff:fed4:619e dev br-lan lladdr 00:16:ea:d4:61:9e REACHABLE 2001:1291:23f:2:215:afff:fe66:a27 dev br-lan lladdr 00:15:af:66:0a:27 REACHABLE fe80::216:eaff:fed4:619e dev br-lan lladdr 00:16:ea:d4:61:9e REACHABLE

00:16:ea:d4:61:9e is the vm host

There is no Layer2 firewall rules and also no restriction to Layer3 internal interfaces in the router.

Aleksey, did you tested bridging to wireless or wired interface?

[Aleksey Ilyushin]

I tested bridging with wired interfaces. Neither Mac OS X nor Linux host bridged networking do not support IPv6 when attached to wireless interfaces. What is your host OS?

[Luiz Angelo Daros de Luca]

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?

[Luiz Angelo Daros de Luca]

Maybe this explains:

​http://www.dd-wrt.com/wiki/index.php/Wireless_Bridge#Limitations

I'll check if the packages arriving at the remote machine uses the MAC from the VM Host machine.

[Aleksey Ilyushin]

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.

[Luiz Angelo Daros de Luca]

Sure, if it is in doc as a known limitation, enhancement is better.

So, currently, there is no way to have IPv6 connectivity for VMs over host wlan connection other than configure a full subnet solution: virtual interface, routing rules, etc.

[Daniel Rösen]

Problem persists in 4.0.4 on Windows 7 32bit host with Linux 64bit guest (Fedora 14 in that case), bridged networking to host laptop wireless interface.

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).

[Daniel Rösen]

BTW, for a real-world example why that is so bad:

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.

[James Burwell]

This issue is still unresolved.

Can someone verify for me that it's only an issue on virtual interfaces bridged through WLAN physical interfaces? Or does it also not work on ethernet interfaces, etc?

[James Burwell]

Actually I verified it myself. It appears to only be a problem with WLAN interfaces.

[Luiz Angelo Daros de Luca]

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:

1. It occurs in any host OS: MAC(reporter), Windows and Linux(myself)
2. It occurs only with hosts that use WLAN interface
3. There is no problem with IPv4 (so no ethernet broadcast problem?)
4. VM receives RA packages and get a valid ipv6 addess
5. 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.

[James Burwell]

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):

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
02:23:26.906606 58:94:6b:48:d7:b4 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd),
   length 86: (hlim 255, next-header ICMPv6 (58) 
payload length: 32) 2001:db8:1234:0:a00:27ff:fe96:fe78 > ff02::1:ff00:1: [icmp6 sum ok] ICMP6,
   neighbor solicitation, length 32, 
who has 2001:db8:1234::1
          source link-address option (1), length 8 (1): 08:00:27:96:fe:78
            0x0000:  0800 2796 fe78
02:23:26.906763 00:50:da:53:65:64 > 08:00:27:96:fe:78, ethertype IPv6 (0x86dd),
   length 86: (hlim 255, next-header ICMPv6 (58) 
payload length: 32) 2001:db8:1234::1 > 2001:db8:1234:0:a00:27ff:fe96:fe78: [icmp6 sum ok] ICMP6,
   neighbor advertisement, length 32, 
tgt is 2001:db8:1234::1, Flags [router, solicited, override]
          destination link-address option (2), length 8 (1): 00:50:da:53:65:64
            0x0000:  0050 da53 6564
02:23:27.897530 58:94:6b:48:d7:b4 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd),
   length 86: (hlim 255, next-header ICMPv6 (58) 
payload length: 32) 2001:db8:1234:0:a00:27ff:fe96:fe78 > ff02::1:ff00:1: [icmp6 sum ok] ICMP6,
   neighbor solicitation, length 32, 
who has 2001:db8:1234::1
          source link-address option (1), length 8 (1): 08:00:27:96:fe:78
            0x0000:  0800 2796 fe78
02:23:27.897689 00:50:da:53:65:64 > 08:00:27:96:fe:78, ethertype IPv6 (0x86dd),
   length 86: (hlim 255, next-header ICMPv6 (58) 
payload length: 32) 2001:db8:1234::1 > 2001:db8:1234:0:a00:27ff:fe96:fe78: [icmp6 sum ok] ICMP6,
   neighbor advertisement, length 32, 
tgt is 2001:db8:1234::1, Flags [router, solicited, override]
          destination link-address option (2), length 8 (1): 00:50:da:53:65:64
            0x0000:  0050 da53 6564

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.

The ND is failing as indicated by the IPv6 neighbor table:

{root@gts/pts/1}/# ip -6 neigh
fe80::250:daff:fe53:6564 dev eth0 lladdr 00:50:da:53:65:64 router STALE
2001:db8:1234::1 dev eth0  FAILED

Here's a capture of a successful ND transaction captured on the same target, but this time sent from a CentOS 5.5 guest OS running on a ubuntu host OS with a wired ethernet interface:

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
02:47:38.933405 08:00:27:fc:eb:ee > 33:33:ff:00:00:01, ethertype IPv6   (0x86dd),
   length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32)
   2001:db8:1234:0:a00:27ff:fefc:ebee > ff02::1:ff00:1: [icmp6 sum ok] ICMP6,
   neighbor solicitation, length 32, who has 2001:db8:1234::1
          source link-address option (1), length 8 (1): 08:00:27:fc:eb:ee
            0x0000:  0800 27fc ebee
02:47:38.933608 00:50:da:53:65:64 > 08:00:27:fc:eb:ee, ethertype IPv6 (0x86dd),
   length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32)
   2001:db8:1234::1 > 2001:db8:1234:0:a00:27ff:fefc:ebee: [icmp6 sum ok] ICMP6,
   neighbor advertisement, length 32, tgt is 2001:db8:1234::1, Flags [router, solicited, override]
          destination link-address option (2), length 8 (1): 00:50:da:53:65:64
            0x0000:  0050 da53 6564

As you can see, the MAC addresses on the solicitation and response match.

I experimented by placing permanent entries into the neighbor table of both the source and target hosts, using both the source's guest MAC and the source's host os' MAC, and it still didn't work.

When I let tcpdump run listening for IPv6 packets on the guest OS, I never see any incoming IPv6 packets.

Hopefully this info will help.

[James Burwell]

OOPS. Sorry for the long lines. I forgot to break them up.

Also, I was thinking that ND/MAC differences were the problem, but now I'm thinking that IPv6 is just being blocked from the guest OS somehow when a WLAN interface is involved.

[TJ Merritt]

I can confirm this problem.

Host: Windows 7
VirtualBox: 4.0.6r71416
Guests: Ubuntu 10.10, Fedora 14, FreeBSD 8.1

ND fails for all three guest O/S's under VirtualBox 4.0.6.

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.

[Carlos Martinez]

I can re-confirm the bug on:

• OSX host running Ubuntu 10.04 guest
• Windows 7 host running Ubuntu 11.04 guest

IPv6 works just fine over bridged wlan on VmWare... Is there any idea of what is going wrong here? We might be able to help...

[Dominik Bay]

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?

[James Burwell]

Bah. I just installed 4.1.0 under Win7 x64, and the IPv6 over Wifi problem was not fixed. Maybe there's some fundamental problem with bridging IPv6 over wifi? I wouldn't think so though.

[TJ Merritt]

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.

[James Burwell]

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.

[TJ Merritt]

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.

[James Burwell]

Excellent. Hopefully they'll fix this soon.

[Ferry]

I wonder when this issue will be fixed. I can confirm that it still exists with Virtualbox V4.1.4 on OS X Lion, which is quit annoying when your Mac is an Mac Book Air (without RJ45 etherjack).

If there is code available to test drive, let me know as I'm more than happy doing that for you.

Who is working on this???

[Frank Mehnert]

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.

[Sam Morris]

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
• Network gateway: Linux 2.6.32 (Debian)
• VM guest picks up a ipv6 address via SLAAC
• VM guest picks up a default route via router advertisement

Bug:

1. In VM guest, attempt to ping ipv6 address on Internet (e.g., www.kame.net)
2. I observe icmpv6 echo request packets leaving the VM guest with the correct detination
3. I observe these packets arriving at the network gateway
4. I observe these packets arriving at the internet host (obviously I don't admin www.kame.net, but here I'm pinging a host I control)
5. I observe icmpv6 echo replies leaving the internet host
6. I observe these replies arriving at the network gateway
7. I observe the network gateway transmitting icmpv6 neighbour solicitation packets to the local network
8. I never see these neighbour solicitation packets arriving at the VM ghest
9. Eventually the gateway gives up and sends an icmpv6 address unreachable packet back to the internet host

[bpennec]

I am on a dual stack lan, and this bug prevents me to switch easily from wired to wireless lan.

I know that IPv6 is not widely deployed and there are many bugs to solve before this one.

But this bugs is really annoying for people who had yet switched to IPV6 and this bug had been opened for 2 years.

How can I help on this topic ? Is there a official/unofficial patch to test ? (I have got Vbox guests (Windows, linux, ...) on linux64 Host)

[thoughton]

I am running Ubuntu 10.10 on a Mac OS X Lion host (4.1.16), and I cannot see IPv6 packets when I do a tcpdump (only IPv4) within the Ubuntu guest. I am presuming that this is due to the above bug?

[Luiz Angelo Daros de Luca]

Is there anything related to this case?

​http://wiki.openwrt.org/doc/howto/clientmode#bridged.client.mode.issues ​http://wiki.openwrt.org/doc/recipes/relayclient (about relayd)

I don't know why it works today with ipv4. It shouldn't. Maybe someone implemented something like relayd for ipv4 but forgot for ipv6. Maybe it would be an "one line fix".

[simon_vetter]

Hi all,

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 also had to apply this patch (https://www.virtualbox.org/pipermail/vbox-dev/attachments/20130121/d635d120/attachment.obj) to get my compiled version running, as indicated on the virtualbox mailing lists. My patch does not include this and focuses only on network code.

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.

Let me know if you have any question or comments.

Best Regards,

Simon

[simon_vetter]

As per https://www.virtualbox.org/wiki/Contributor_information, I am releasing the attached patch and submitting my contribution under the MIT license.

The terms of the MIT license can be found at https://www.virtualbox.org/wiki/MIT%20license.

[simon_vetter]

Updated patch, tested OK against v4.2.10

[simon_vetter]

Updated patch (it now uses RTNetIPv6PseudoChecksum() from src/VBox/Runtime/common/checksum/ipv6.cpp, recently fixed). Tested OK against v4.2.10 on OSX 10.8.3 with multiple Ubuntu 32 and 64 bit guests. MIT licence.

[Frank Mehnert]

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.

[simon_vetter]

Hi Frank,

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.

[Aleksey Ilyushin]

Replying to simon_vetter:

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.

[simon_vetter]

Replying to aleksey:

Replying to simon_vetter:

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.

Would you happen to have a pcap file of this behaviour?

[simon_vetter]

The bug is still present in 4.2.14, although https://www.virtualbox.org/changeset/45716/vbox tends to hint that the code has been merged.

AFAICT, the source MAC address is not replaced in outgoing ICMP6 neighbor solicitations:

54:26:92:c0:bd:d1 > 33:33:ff:d1:5e:fa, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) 2601:9:8cd0:77a1:a00:27ff:fe11:76b6 > ff02::1:ffd1:5efa: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::27:22ff:ffd1:5efa
	  source link-address option (1), length 8 (1): 08:00:27:11:76:b6
	    0x0000:  0800 2711 76b6

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.

Any word on the status of the bug?

Thanks in advance

[Valery Ushakov]

Re: link layer unicast for IPv6 multicast

Replying to simon_vetter:

Replying to aleksey:

Replying to simon_vetter:

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.

I guess this document explains the motivation behind it:
​http://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-01

[Valery Ushakov]

We have committed some additional fixes that should improve IPv6 support over WLAN. They will be part of 4.3.16. Feedback is welcome.

[Luiz Angelo Daros de Luca]

I don't know which changes since may/2011 fixed my problem but now I can use ipv6 through bridged wlan0 with no problems.

I can ping and access TCP services. I did not tried UDP yet.

[Marijn van Zon]

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.

[Valery Ushakov]

Replying to SunMar:

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.

Please, provide packet captures.

[Marijn van Zon]

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

I also tested with VMWare free player in Bridged mode and both the Win7 IE image and the Gentoo LiveDVD worked properly with IPv6, to try to futher rule out issues with my router.

[Valery Ushakov]

Replying to SunMar:

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?

Thanks in advance.

[Marijn van Zon]

Is there a way in VirtualBox to do this? Or do I need to install something on the Windows host to capture? Since you ask to include the guest boot I'm not sure how to capture.

[Valery Ushakov]

I need a capture on the host's interface, so you will need to run Wireshark on the host.

[Marijn van Zon]

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@….

[Marijn van Zon]

Thank you! Sent the capture, if you need anything else let me know.

[FerryIPv6]

Hello,

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.

See a earlier posting describing it:

Problem persists in 4.0.4 on Windows 7 32bit host with Linux 64bit guest (Fedora 14 in that case), bridged networking to host laptop wireless interface.

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).

comment:15 Changed 4 years ago by droesen

Regards, Ferry

[Valery Ushakov]

Re-closing. Original problems are addressed. Problems described in comment:47 (when the bug was re-opened) are a different bug, most likely the same as described in #14212.

[treysis]

Problem still persisting in VBox 6.10 on wireless adapter. Why was this closed?

[Valery Ushakov]

Replying to treysis:

Problem still persisting in VBox 6.10 on wireless adapter. Why was this closed?

Which problem? This bug took several diversions.

[treysis]

Replying to vushakov: You're right, I found that out now. Different problems with same symptoms.