Windows Virtual PC IPv6: Part 1

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.

More on IPv6 in Perl Modules

Recently, I went on a tear updating my Perl modules on CPAN to support IPv6. Since my modules (and scripts) rely on other core modules like Socket, IO::Socket and some non core modules like Net::SNMP and Net::Telnet(::Cisco), I had a task to make sure the underlying modules supported IPv6.

I already dealt with IPv6 in the core Socket module for Windows in a previous post. So now to deal with a higher level of code written by other developers. Would they be responsive?

Turns out ... YES! I worked with the author of Net::TFTPd a while back to get an ASCII / BIN mode bug fix submitted and he was again very responsive with my IPv6 ask and patch. So IPv6 capable TFTP server - Perl has one!

I also rely on Net::Telnet::Cisco which uses Net::Telnet to do all the heavy lifting. Net::Telnet looked like it hadn't been updated since 2002 but I submitted the query / patch and contacted the author. In a few days he got back to me and we had a pretty detailed dialogue about adding IPv6 support. There may be a coming version which does this "natively", but imagine my surprise when I found Net::Telnet was already IPv6-capable!

The "workaround" - and as workarounds go, this is the least kludgey I've seen - goes like this:

Open a socket using an IPv6 capable module - like IO::Socket::IP:

use IO::Socket::IP -register;

my $socket = IO::Socket::IP->new(
    PeerHost => '192.168.10.1' # or 2001:db8:192:168::10:1
    PeerPort => 23,
    Family   => AF_INET # or AF_INET6
) or die "not connected\n";

Then, use the $socket handle as an argument to the 'fhopen' parameter in the Net::Telnet new() constructor:

my $session = Net::Telnet->new(
    fhopen => $socket
);

Jay Rogers (Net::Telnet author) is obviously a genius providing IPv6 support in Net::Telnet before Perl core even supported IPv6! Ok, maybe that's a stretch, but certainly the openness of the Net::Telnet API allows for this kind of "plug-and-play" with IPv4/v6 sockets and enables IPv6 right now, while in the background "native" support may be coming.

Thanks Jay!