Smartphone Snacks

Last night I fed my AT&T Samsung Galaxy S3 some jelly beans - that is, the Android 4.1 Jelly Bean update. AT&T / Samsung announced availability earlier this week. However, they also said there would be no over-the-air update. So this was a manual process - first installing Kies from Samsung.

The Kies install on Windows 7 x64 was kludgy. I started the install and it kept looping at "Installing Hotfix". I pressed "Cancel" and it warned me it hadn't completed the install and asked for a confirmation. I canceled that and allowed the install to continue and that seemed to skip out of the loop as the install proceeded and completed successfully.

The next step was to connect my GS3 to the computer with USB and Kies recognized it. I got a pop-up for the new firmware update and allowed it to go forward. A few confirmations and a very slow loading and update process followed. But again, SUCCESS!

I've only been exploring / using Jelly Bean for a few hours but it seems nice and smooth. I see I have an explicit "Driving Mode" (although I don't know what it does) even though I already side-loaded Google Car Home. I already had loaded Chrome as my default browser so that remained. I didn't like that the Accounts under "Settings" are now all listed in the main Settings menu rather than a sub menu. The previous sub menu had an icon regarding sync status for each account. Now you need to click into each account to see the sync status.

I haven't had a chance to try IPv6 yet. Previously, I would get IPv6 addresses via SLAAC on my home network, but I didn't have access to the IPv6 Internet. I'll do some testing in the next few days when I find the time.

IPv6 over IPv4-only MPLS with 6to4

Last year, I researched, created and presented training on 6VPE technology for our internal consultants. Passing IPv6 routes and traffic over an IPv4-only MPLS network is a problem. 6VPE solves that problem from a carrier perspective allowing the MPLS carrier to provide dual-stack IPv4 and IPv6 at the LAN side interface of the customer edge devices.

But what if your MPLS provider has not rolled out IPv6 support?

I knew you could use tunnels to solve this problem from a client perspective. Further, configuring static tunnels in a full mesh over MPLS would be an awful management burden so automatic 6to4 tunnels could address that. However, I never pursued it further.

Recently, a question about this came up again and forced me to reconsider. Some research yielded Dynamic Routing Over 6to4 Automatic Tunnels which describes how to enable dynamic routing over 6to4 tunnels using BGP - specifically external BGP (eBGP). However, the article doesn't consider an MPLS backbone. I did some testing and it turns out it's not that hard to adapt this concept to an IPv4-only MPLS backbone.

Assume the following scenario:

• MPLS provider offers IPv4-only MPLS VPN access for customers
• Customer A wants IPv6 access
• Customer A has many remote sites so solution must be scalable

Since Customer A wants IPv6 access and the provider doesn’t offer it, the first step is for Customer A to configure tunnel endpoints on each of the remote sites. Static tunnels such as 6in4 will require n(n - 1) tunnel endpoints – essentially an n^2 problem or management burden. Each new site almost exponentially increases the management burden.

The solution is to configure 6to4 tunnel endpoints on each remote site. 6to4 tunnels are dynamic so only a single tunnel endpoint is needed per remote site. Adding a new site now only adds 1 new tunnel interface – a linear increase.

To enable dynamic routing, the customer edge routers already use BGP to connect to the MPLS backbone. We can use the existing BGP configuration to enable internal (iBGP) sessions between the 6to4 addresses and advertise the IPv6 networks.

To begin, let's configure the 6to4 endpoints on each remote site:

---

ACE1

interface Tunnel2002
 ipv6 address 2002:a01:102::/128
 tunnel source Serial1/0
 tunnel mode ipv6ip 6to4

ipv6 unicast-routing

ipv6 route 2002::/16 Tunnel2002

---

ACE2

interface Tunnel2002
 ipv6 address 2002:a01:106::/128
 tunnel source Serial1/0
 tunnel mode ipv6ip 6to4

ipv6 unicast-routing

ipv6 route 2002::/16 Tunnel2002

---

ACE3

interface Tunnel2002
 ipv6 address 2002:a01:10a::/128
 tunnel source Serial1/0
 tunnel mode ipv6ip 6to4

ipv6 unicast-routing

ipv6 route 2002::/16 Tunnel2002

---

At this point, the sites have reachability to the newly configured 6to4 addresses but not the IPv6 addresses on the LAN of each remote site. To enable reachability to those networks we need to enable routing.

The easiest way is to add some static routes pointing to the remote 6to4 address for the remote sites' IPv6 networks. For example, on ACE1, the static IPv6 routes to add for the four (4) IPv6 networks on ACE2 and the four (4) IPv6 networks on ACE3 are:

ipv6 route 2001:DB8:A64:6800::/54 2002:A01:106::
ipv6 route 2001:DB8:A64:6C00::/54 2002:A01:10A::

Of course, with static routing we've simply shifted the n^2 problem of tunnel endpoint management to static route management, which could actually be much worse if routes are not hierarchical like the /54 summaries above. Imagine managing several static routes per site on each remote router.

The best solution is dynamic routing and as the previous linked article described, an internal gateway routing protocol will not work as the 6to4 addresses are not on the same subnet. BGP solves this with explicit peering definitions and since the edge routers are already running BGP to the MPLS provider, we can use that configuration.

BGP peers will be configured to the 6to4 addresses so BGP routing traffic will be passed as over the 6to4 tunnels the same way data traffic is passed. We use iBGP since the customer edge routers are all in the same BGP Autonomous System. Finally, we offloaded the configuration burden of an iBGP full mesh by configuring ACE1 as a route reflector ACE2 and ACE3 as route reflector clients.

---

ACE1

router bgp 65100
 neighbor 2002:A01:106:: remote-as 65100
 neighbor 2002:A01:10A:: remote-as 65100
 address-family ipv6
  neighbor 2002:A01:106:: activate
  neighbor 2002:A01:106:: route-reflector-client
  neighbor 2002:A01:10A:: activate
  neighbor 2002:A01:10A:: route-reflector-client
  network 2001:DB8:A64:6400::/64
  network 2001:DB8:A64:6500::/64
  network 2001:DB8:A64:6600::/64
  network 2001:DB8:A64:6700::/64

---

ACE2

router bgp 65100
 neighbor 2002:A01:102:: remote-as 65100
 address-family ipv6
  neighbor 2002:A01:102:: activate
  network 2001:DB8:A64:6800::/64
  network 2001:DB8:A64:6900::/64
  network 2001:DB8:A64:6A00::/64
  network 2001:DB8:A64:6B00::/64

---

ACE3

router bgp 65100
 neighbor 2002:A01:102:: remote-as 65100
 address-family ipv6
  neighbor 2002:A01:102:: activate
  network 2001:DB8:A64:6C00::/64
  network 2001:DB8:A64:6D00::/64
  network 2001:DB8:A64:6E00::/64
  network 2001:DB8:A64:6F00::/64

---

Note that we've made no changes to the PE router - meaning the MPLS provider does not need to support IPv6 at all for this configuration to work. You will need to make sure the provider doesn't do any exotic filtering at the edge or in the MPLS backbone such as blocking IP protocol 41 (IPv6 in IPv4 encapsulation).

At this point, we can test the configuration with some BGP show commands and pings to test connectivity. Without the benefit of a live demo here, rest assured these commands produced the provided output:

ACE1#show bgp ipv6 unicast
BGP table version is 17, local router ID is 10.100.103.1

   Network          Next Hop        Metric LocPrf Weight Path
*> 2001:DB8:A64:6400::/64
                    ::                   0         32768 i
[...]
*>i2001:DB8:A64:6800::/64
                    2002:A01:106::       0    100      0 i
*>i2001:DB8:A64:6900::/64
                    2002:A01:106::       0    100      0 i
[...]
*>i2001:DB8:A64:6C00::/64
                    2002:A01:10A::       0    100      0 i
*>i2001:DB8:A64:6D00::/64
                    2002:A01:10A::       0    100      0 i

ACE1#ping ipv6 2001:db8:a64:6800::1 source 2001:db8:a64:6400::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:A64:6800::1, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:A64:6400::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 148/205/276 ms
ACE1#ping ipv6 2001:db8:a64:6c00::1 source 2001:db8:a64:6400::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:A64:6C00::1, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:A64:6400::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 128/167/204 ms

And there you have it! Dynamic routing of IPv6 over an IPv4-only MPLS network without the MPLS provider supporting IPv6.

Fourth Annual RI 6 Hour Ultramarathon

On Sunday, November 11, 2012, I ran in the fourth annual RI 6 Hour Ultramarathon. This is quickly becoming a favorite race of mine - like RTB.

My goal - as in past years, was to do at least as well as I did the previous year. Given a good training build up during the past few months and last year's performance, I didn't think it would be too hard.

I started quite easy on a mild November day but the heat started to become an issue by 11 AM. Sixty degrees may not sound too hot to run in, but when you're getting to marathon distance with the intent of going much farther, it does matter. I started to get a little cramping due to dehydration - I was sweating more than I anticipated and drinking too little to compensate. I grabbed my running bottle for a lap and that eased the cramps.

Food intake was good this time. No stomach issues or lack of appetite. I stayed content throughout the race.

As I crossed the start/finish line to end my 13th lap and start my 14th - which was potentially my last and all I needed to equal last year's distance - I saw my wife and mother pull in to the parking lot beeping and waving at me. I yelled a quick "hello" and "1 more lap" and then started on my 14th lap.

On my 14th lap - the one to complete 37.8 miles and equal last year's distance - I kept saying this was it. My wife and mother were waiting to see me finish - a nice ending to the day. Looking at my watch, I could maybe have enough time to make it past the start/finish line to the first split timer at the 50k mark - an additional 1.35 miles. Although I was well past 50k at this point, the timing mat is still there and crossed on each lap and we were told by the race director at the start that partial laps to either the 50k or marathon split timing mats would count. But I kept talking myself out of it saying I would finish 14 laps and be done.

I crossed the start/finish line to end my 14th lap just shy of 5 hours, 42 minutes. I walked to the aid station and the volunteers asked if I was going to do a partial lap to the 50k split mat. That did it. I had 18 minutes. Even with my slow pace, I could do it. Jen was walking to me to congratulate me and instead, I quickly told her, "get in the car and meet me at the entrance of the park." Then I turned and started running.

I think part of me didn't want to run the extra 1.35 miles - literally half the course - and end up having to walk back to the start/finish line. I liked the idea of finishing at the start/finish line and being done. But with an unexpected taxi service in the form of my wife and mom, it seemed perfect.

There is a slight crest at the 50k timing mat and I crossed it at 5:54:08 completing 39.15 miles. My wife had parked behind another truck, so I didn't see her car right away, but then I saw her, waved and walked (painfully) towards my ride. Some congratulations from them and a quick explanation and thank you from me and we were on our way back to the start/finish for the post race activities.

The official results place me 5/43 with an official total mileage of 39.173 miles in 5:55:55.5 (although that time is wrong).

The table below documents my miles and times (by my watch).

RI 6 Hour Ultramarathon: November 11, 2012
Lap	Mileage	Cumm. Mile.	Lap Split	Cumm. Time	Lap Pace	Avg. Pace
1	2.7	2.7	21:53.56	0:21:53.6	08:06.5	08:06.5
2	2.7	5.4	22:09.94	0:44:03.5	08:12.6	08:09.5
3	2.7	8.1	21:55.90	1:05:59.4	08:07.4	08:08.8
4	2.7	10.8	22:30.58	1:28:30.0	08:20.2	08:11.7
5	2.7	13.5	22:51.23	1:51:21.2	08:27.9	08:14.9
6	2.7	16.2	22:14.74	2:13:35.9	08:14.3	08:14.8
7	2.7	18.9	22:48.34	2:36:24.3	08:26.8	08:16.5
8	2.7	21.6	23:30.16	2:59:54.5	08:42.3	08:19.7
9	2.7	24.3	24:19.56	3:24:14.0	09:00.6	08:24.3
Marathon		26.2	--	3:41:58.0	--	08:28.3
10	2.7	27	25:18.30	3:49:32.3	09:22.3	08:30.1
11	2.7	29.7	26:39.65	4:16:12.0	09:52.5	08:37.6
50K		31.25	--	4:30:26.0	--	08:39.2
12	2.7	32.4	27:53.00	4:44:05.0	10:19.6	08:46.1
13	2.7	35.1	28:55.01	5:13:00.0	10:42.6	08:55.0
14	2.7	37.8	28:53.37	5:41:53.3	10:42.0	09:02.7
14+	1.35	39.15	12:15.56	5:54:08.9	09:04.9	09:02.8
Totals:		39.15		5:54:08		09:02.7

Windows Virtual PC IPv6: Part 3

The original title of the first post in the this series was "Windows Virtual PC Wireless IPv6", but dropped the "Wireless" before publishing. At that point, I had Part 1 and Part 2 written and knew the problem was with the wireless card versus the wired card, but didn't yet know the root cause. And since I had exhausted my troubleshooting tools (tcpdump and network based analysis) and wasn't about to dive into wireless driver software reverse engineering, I figured I may never have the exact answer. Instead, I focused the posts on discussing the problem and how it relates to the question, "is 'X' IPv6 ready?"

I did want to close the loop and exhaust all possible angles. So I called my friend and colleague Randy who had experience with wireless bridging / routing and virtual machines from a previous client. I remember he would lament about the issues he faced and custom drivers and wireless cards needed to get things only partially working. Since I was only an observer, I didn't have the intimate details, so now I sought them out over a phone call.

I explained my set up and issue and Randy immediately knew the problem. It wasn't IPv6 specific nor was it related to Windows Virtual PC. In fact, it wasn't even the wireless card or its respective drivers (per se), it was the 802.11 protocol itself. Randy explained the technical issues and gave me the proper Google terms to search to flush out the entire explanation.

And sure enough, after our call I started finding links such as:

• IPv6 and networking pain
• The problem with wireless bridging

that detail the IPv6 neighbor discovery problem I encountered when using wireless bridging. In my case, it wasn't a standalone bridge device, but the virtual network bridge when using a virtual machine. Note that in my testing the issue happened with Windows Virtual PC, but Randy's previous work involved VMware, which also had the issue. Again, this is protocol / driver related, not specific to IPv6 (network) or application layer software.

Further complicating the matter was the "incorrect" 'tcpdump' decodes. While the Ethernet header in the packets I posted showed source and destination MAC addresses, it wasn't the full picture. Wireless 802.11 has a different frame format than wired 802.3 Ethernet. However, the *pcap (winpcap in my case) libraries can't decode the 802.11 header if the wireless driver software doesn't pass it along. With my stock Broadcom wireless on a Dell laptop running Windows 7, I was seeing the "fake" header.

This final link from the OpenWRT project does a good job visualizing what is happening. Again, the link details physical bridges versus the virtual bridge introduced with machine virtualization software, but the same holds true.

So what does all this mean? Depending on how you look at this problem, it could be hardware, protocol or software related. For me, it manifested when trying IPv6 on Windows Virtual PC - so that was my first thought. It turns out the answer was much more involved and complicated than I imagined. However, broken IPv6 connectivity was the symptom and the casual user experiencing that will probably just say, "the network is down." No amount of planning is going to identify these unique use cases until they occur - hopefully during a pilot, more likely during production. You're going to need some smart people when you start rolling out IPv6.

Windows Virtual PC IPv6: Part 2

In the previous post we saw the wireless card was responsible for some IPv6 connectivity issues between a Windows XP Virtual PC and the Internet due to it rewriting the VPC virtual MAC address to the MAC address of the HOST.

Suspecting the wireless card may be the culprit, I physically connected the HOST to the switch on the router and changed the VPC settings to use the wired NIC instead of the wireless one. A quick reset and back to testing - this time in somewhat reverse order.

I first checked the router to see what the MAC address for the VPC was. It was correct!

ROUTER# arp -a
? (192.168.10.102) at C4:17:FE:12:7D:75 [ether]  on br0
? (192.168.10.104) at 00:03:FF:13:7D:75 [ether]  on br0

So I started my 'tcpdump' captures and launched the pings from the VPC.

HOST> tcpdump -i2 -nevvXX icmp or icmp6
00:03:ff:13: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 553
  0x0000:  586d 8f78 ad40 0003 ff13 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 9120 0000 0229 6162  .....h.......)ab
  0x0040:  6364 6566 6768 696a 6b6c 6d6e 6f70 7172  cdefghijklmnopqr
  0x0050:  7374 7576 7761 6263 6465 6667 6869       stuvwabcdefghi
00:03:ff:13:7d:75 > 58:6d:8f:78:ad:40, ethertype IPv4 (0x0800),
length 74: (tos 0x0, ttl 128, id 25380, offset 0, flags [none], 
proto: ICMP (1), length: 60)
192.168.10.104 > 74.125.228.80
ICMP echo request, id 512, seq 9728, length 40
  0x0000:  586d 8f78 ad40 0003 ff13 7d75 0800 4500  Xm.x.@....}u..E.
  0x0010:  003c 6324 0000 8001 ddbe c0a8 0a68 4a7d  .< c$.........hJ}
  0x0020:  e450 0800 255c 0200 2600 6162 6364 6566  .P..%\..&.abcdef
  0x0030:  6768 696a 6b6c 6d6e 6f70 7172 7374 7576  ghijklmnopqrstuv
  0x0040:  7761 6263 6465 6667 6869                 wabcdefghi

The two packets show the IPv6 and IPv4 pings (echo requests) respectively. Notice the first line of each packet has the VPC source MAC address - '00:03:ff:13:7d:75' - not the HOST MAC address as seen in the previous test on the wireless card.

And the satisfying result:

VM> ping 2607:f8b0:400c:c03::68
Reply from 2607:f8b0:400c:c03::68: time=50ms

VM> ping 74.125.228.80
Reply from 74.125.228.80: bytes=32 time=166ms TTL=52

Just to make sure this whole testing regime wasn't an anomaly, I rebooted and reset to my wireless configuration and tested again with same failed results described in the previous post.

Why do the wireless and wired cards behave differently? I haven't answered that yet. Certainly, they are from different manufacturers and have different settings as verified in the "Properties" page, "Configure..." button, "Advanced" tab of each adapter. I did verify the common settings were matched between cards. I have some more research to do to get to the bottom of this one.

So, "does Windows Virtual PC support IPv6?" It's complicated. As we've seen, it depends on the application, the host and virtual machine operating systems, and in this case, the hardware used.

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!