I have a Windows XP Virtual PC for testing - among other things - all the Perl experimenting I've been doing lately around IPv6. Windows XP supports IPv6 if you install it - it's not on by default. However, I've had some issues with IPv6 connectivity from my VPC to the rest of the Internet.
I run in bridge mode as Shared Networking (NAT) doesn't make much sense with IPv6; there is no NATv6. With bridge mode, the VPC should act as another computer on the network with it's own IP(v6) address(es) and a unique MAC address. I should also note at this time, that I use wireless throughout the house and never connect over the wired LAN.
The setup is pretty simple. Note: I've changed the IPv6 prefix to the documentation prefix for this example but was using global unicast addressing for the actual troubleshooting tests.
+-----------------------------------------+ | (HOST) Windows 7 | | c4:17:fe:12:7d:75 | | 192.168.10.102 | | 2001:db8:192.168:c417:feff:fe12:7d75 | | | | +-------------------------------------+ | | | (VPC) Windows XP | | | | 00:03:ff:13:7d:75 | | | | 192.168.10.104 | | | | 2001:db8:192.168:203:FFFF:FE13:7D75 | | | +-------------------------------------+ | +-----------------------------------------+ | | +-----------------------------+ | ROUTER | | 58:6d:8f:78:ad:40 | | 192.168.10.1 | | FE80::5A6D:8FFF:FE78:AD40 | | ('radvd' running for SLAAC) | +-----------------------------+ | __|_ __/ \__ / \ | Internet | \__ __/ \____/
When I try to ping the IPv6 address returned by 'dig' for "www.google.com" from the VPC, I get 'destination unreachables'. I can ping the same IPv6 address from the HOST. To be sure, I also tried the IPv4 address returned by 'dig' for "www.google.com" from the VPC and was successful.
VPC> ping 2607:f8b0:400c:c03::68 Destination host unreachable. VPC> ping 74.125.228.80 Reply from 74.125.228.80: bytes=32 time=22ms TTL=52
So the VPC has network connectivity all the way to the Internet for IPv4, but not for IPv6. Why? A packet capture may help.
HOST> tcpdump -i3 -nevvXX icmp or icmp6 c4:17:fe:12:7d:75 > 58:6d:8f:78:ad:40, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 19700, offset 0, flags [none], proto: ICMP (1), length: 60) 192.168.10.104 > 74.125.228.80 ICMP echo request, id 512, seq 19713, length 40 0x0000: 586d 8f78 ad40 c417 fe12 7d75 0800 4500 Xm.x.@....}u..E. 0x0010: 003c 4cf4 0000 8001 f3ee c0a8 0a68 4a7d .< L..........hJ} 0x0020: e450 0800 fe5a 0200 4d01 6162 6364 6566 .P...Z..M.abcdef 0x0030: 6768 696a 6b6c 6d6e 6f70 7172 7374 7576 ghijklmnopqrstuv 0x0040: 7761 6263 6465 6667 6869 wabcdefghi 58:6d:8f:78:ad:40 > c4:17:fe:12:7d:75, ethertype IPv4 (0x0800), length 74: (tos 0x20, ttl 52, id 62188, offset 0, flags [none], proto: ICMP (1), length: 60) 74.125.228.80 > 192.168.10.104 ICMP echo reply, id 512, seq 19713, length 40 0x0000: c417 fe12 7d75 586d 8f78 ad40 0800 4520 ....}uXm.x.@..E. 0x0010: 003c f2ec 0000 3401 99d6 4a7d e450 c0a8 .<....4...J}.P.. 0x0020: 0a68 0000 065b 0200 4d01 6162 6364 6566 .h...[..M.abcdef 0x0030: 6768 696a 6b6c 6d6e 6f70 7172 7374 7576 ghijklmnopqrstuv 0x0040: 7761 6263 6465 6667 6869 wabcdefghi c4:17:fe:12:7d:75 > 58:6d:8f:78:ad:40, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header: ICMPv6 (58), length: 32) FE80::203:FFFF:FE13:7D75 > FE80::5A6D:8FFF:FE78:AD40 [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has FE80::5A6D:8FFF:FE78:AD40 source link-address option (1), length 8 (1): 00:03:ff:13:7d:75 0x0000: 586d 8f78 ad40 c417 fe12 7d75 86dd 6000 Xm.x.@....}u..`. 0x0010: 0000 0020 3aff fe80 0000 0000 0000 0203 ....:........... 0x0020: ffff fe13 7d75 fe80 0000 0000 0000 5a6d ....}u........Zm 0x0030: 8fff fe78 ad40 8700 55bb 0000 0000 fe80 ...x.@..U....... 0x0040: 0000 0000 0000 5a6d 8fff fe78 ad40 0101 ......Zm...x.@.. 0x0050: 0003 ff13 7d75 ....}u c4:17:fe:12:7d:75 > 58:6d:8f:78:ad:40, ethertype IPv6 (0x86dd), length 94: (hlim 128, next-header: ICMPv6 (58), length: 40) 2001:db8:192:168:203:FFFF:FE13:7D75 > 2607:F8B0:400C:C03::68 [icmp6 sum ok] ICMP6, echo request, length 40, seq 498 0x0000: 586d 8f78 ad40 c417 fe12 7d75 86dd 6000 Xm.x.@....}u..`. 0x0010: 0000 0028 3a80 2001 0db8 0192 0168 0203 ...(:....p...|.. 0x0020: ffff fe13 7d75 2607 f8b0 400c 0c03 0000 ....}u&...@..... 0x0030: 0000 0000 0068 8000 9157 0000 01f2 6162 .....h...W....ab 0x0040: 6364 6566 6768 696a 6b6c 6d6e 6f70 7172 cdefghijklmnopqr 0x0050: 7374 7576 7761 6263 6465 6667 6869 stuvwabcdefghi
The first two packets show the IPv4 ping (echo request) and reply (echo reply). The next two packets are more interesting (although, if you were paying attention, you could see it in the first two also).
The second two packets are an IPv6 ICMPv6 neighbor solicitation from the VPC asking for the router's MAC address - the IPv6 version of address resolution protocol (ARP), and an IPv6 ICMPv6 ping request (echo request). Let's look closer at the neighbor solicitation message.
You can see "who has FE80::5A6D:8FFF:FE78:AD40" (the router IPv6 link-local address) and the source of the request in line that follows, "source link-address option (1), length 8 (1): 00:03:ff:13:7d:75" - the MAC address of the VPC. However, look at the first line of that packet, "c4:17:fe:12:7d:75 > 58:6d:8f:78:ad:40, ethertype IPv6 (0x86dd)". The source MAC address is the HOST MAC, not the VPC MAC! WHAT?!?!
Is this normal behavior for bridge mode, to rewrite the source MAC of the VPC with the source MAC of the HOST? Why the virtual MAC address on the VPC in the first place? The HOST operating systems sees the virtual MAC:
HOST> arp -a Interface: 192.168.10.102 --- 0xb Internet Address Physical Address Type 192.168.10.104 00-03-ff-13-7d-75 dynamic
Could this be just a 'tcpdump' anomaly, perhaps capturing at a point in the stack before/after a rewrite? Apparently not, because the router confirms the MAC address for the VPC IPv4 address (192.168.10.104) is in fact the MAC address of the HOST, not the virtual MAC of the VPC:
ROUTER# arp -a ? (192.168.10.102) at C4:17:FE:12:7D:75 [ether] on br0 ? (192.168.10.104) at C4:17:FE:12:7D:75 [ether] on br0
This touches on a problem that will manifest in the years to come regarding IPv6 support - "does 'X' support IPv6". The answer isn't really binary (yes or no). In this case, the VM can get IPv6 addresses and ping the HOST over IPv6; however, the wireless card (and I say that because in the next post, I'll show how the wired card does not exhibit this behavior) doesn't handle the virtual and host MAC addresses properly and thus breaks IPv6 ICMPv6 neighbor solicitation.