VM systems and IPv6?

Rickman, Phil phrickman at upcbroadband.com
Thu Mar 18 10:02:58 CET 2010


we use it in testing on VMware and have no problems with it so far for customer simulation.

From: ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de [ipv6-ops-bounces+ipv6=aorta.net at lists.cluenet.de] On Behalf Of Phil Pennock [ipv6-ops+phil at spodhuis.org]
Sent: 18 March 2010 06:49
To: ipv6-ops at lists.cluenet.de
Subject: VM systems and IPv6?


How common is it these days to have people using Windows under VMs?

How common is it for VM virtual bridges to somehow be breaking IPv6?

I see another source of some of the broken machines in the stats that
various people have published ...

I've not previously played with VMs (I'm a latecomer).  Playing with
Parallels 5 on a Mac, I couldn't get FreeBSD able to route out, looks
like NDP announcements weren't making it out, so packets weren't
returning so the router wasn't able to send packets back to the VM dom.
I could only ping the dom0 and vice-versa.

So I brought up a Debian VM, same problem.

Interface configures up, gets a default route pointing to the router
(Apple Airport) on link-local.  I ping ipv6.google.com, see neighbour
solicitations for the gateway address but no response.  This is from {
tcpdump -vvvnpi eth0 -s1500 ip6 } (after ssh'ing back in on explicitly
IPv4 to avoid the loop of output-generating-packets, oops).

If I ping the fe80:: address of the router itself then: from dom0 I get
a response, so the gateway isn't filtering and in the VM; when I try
from the VM, I again see neighbour solicitation go out, this time I also
see neighbour solicitations from the router for the VM's address
(progress!) , then I see the VM send a solicited neighbour advertisement
but then nothing.

VM eth0 (Debian 5.0):
dom0 IF is en1:
Gateway is:
  fe80::fa1e:dfff:fef7:86a0  [ set as default route on hosts ]

----------------------------8< cut here >8------------------------------
22:06:05.560193 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64)
  fe80::24a:5bff:fe9b:355c > fe80::fa1e:dfff:fef7:86a0:
  [icmp6 sum ok] ICMP6, echo request, length 64, seq 1
22:06:05.565442 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32)
  fe80::fa1e:dfff:fef7:86a0 > ff02::1:ff9b:355c:
  [icmp6 sum ok] ICMP6, neighbor solicitation, length 32,
  who has fe80::24a:5bff:fe9b:355c
          source link-address option (1), length 8 (1): f8:1e:df:f7:86:a0
            0x0000:  f81e dff7 86a0
22:06:05.565514 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32)
  fe80::24a:5bff:fe9b:355c > fe80::fa1e:dfff:fef7:86a0:
  [icmp6 sum ok] ICMP6, neighbor advertisement, length 32,
  tgt is fe80::24a:5bff:fe9b:355c, Flags [solicited, override]
          destination link-address option (2), length 8 (1): 00:4a:5b:9b:35:5c
            0x0000:  004a 5b9b 355c
22:06:06.573865 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64)
  fe80::24a:5bff:fe9b:355c > fe80::fa1e:dfff:fef7:86a0:
  [icmp6 sum ok] ICMP6, echo request, length 64, seq 2
----------------------------8< cut here >8------------------------------

tcpdump from the dom0 is not more informative.

It really looks as though neighbour solicitations are not making it
across, which begs the question of how did the VM get its address
configured up in the first place.

Anyone have any better thoughts?  Am I going to say "doh"?

Which returns to my second question.  Are there VM environments that do
work with IPv6?


More information about the ipv6-ops mailing list