IPv6 in Perl on Windows

The state of IPv6 support in Perl has long been lamented but there are those trying to change this including Paul Evans who's updating many of the networking modules - including the Socket core module - to support IPv6. It's a shame the C compiler shipping with Strawberry Perl still doesn't accommodate IPv6 on Windows.

I've been using Strawberry Perl after switching from ActiveState since version 5.10. I found myself needing more and more XS modules and the ActiveState PPM process was always lagging behind. I had a copy of MinGW gcc - the free Windows port of the 'gcc' compiler - and with 'dmake', I could build my own modules directly from CPAN. However, I had some issues and when I learned about Strawberry Perl including the gcc compiler in the distribution, I switched. I've used Strawberry Perl on Windows XP 32-bit and now Windows 7 64-bit.

I've also recently been doing a lot of IPv6 work and using Perl as a quick development platform to test the IPv6 protocol proved easy with the Net::Frame modules detailed in an early series of blog posts. However, when looking to create sockets with Perl, I found errors, most notably:

Socket::inet_ntop not implemented on this architecture

The lack of this function prevented the display of IPv6 addresses and it's missing complement - inet_pton - prevents the resolution of IPv6. These functions are certainly present in Windows 7.

The issue lies in the header and library files distributed with MinGW gcc compiler in the Strawberry Perl release. They simply don't identify the functions in the headers, nor provide linkage to them in the libraries. Fortunately, tools shipped with the MinGW gcc compiler in Strawberry Perl can be used to remedy the issue and get full IPv6 functionality. Here's how.

First off, we need to update the header file with the function prototypes. I did this by creating a new header file called 'ws2tcpip-win.h':

---

#ifndef WS2TCPIP_WIN_H
#define WS2TCPIP_WIN_H

typedef USHORT ADDRESS_FAMILY;

#if (NTDDI_VERSION >= NTDDI_VISTA)
WINSOCK_API_LINKAGE INT WSAAPI inet_pton(INT, PCSTR, PVOID);
WINSOCK_API_LINKAGE INT WSAAPI InetPtonW(INT, PCWSTR, PVOID);

WINSOCK_API_LINKAGE PCSTR WSAAPI inet_ntop(INT, PVOID, PSTR, size_t);
WINSOCK_API_LINKAGE PCWSTR WSAAPI InetNtopW(INT, PVOID, PWSTR, size_t);

#define InetPtonA       inet_pton
#define InetNtopA       inet_ntop

#ifdef UNICODE
#define InetPton        InetPtonW
#define InetNtop        InetNtopW
#else
#define InetPton        InetPtonA
#define InetNtop        InetNtopA
#endif

#if INCL_WINSOCK_API_TYPEDEFS
typedef INT (WSAAPI * LPFN_INET_PTONA)(INT Family, PCSTR pszAddrString, PVOID pAddrBuf);
typedef INT (WSAAPI * LPFN_INET_PTONW)(INT Family, PCWSTR pszAddrString, PVOID pAddrBuf);

typedef PCSTR (WSAAPI * LPFN_INET_NTOPA)(INT Family, PVOID pAddr, PSTR pStringBuf, size_t StringBufSize);
typedef PCWSTR (WSAAPI * LPFN_INET_NTOPW)(INT Family, PVOID pAddr, PWSTR pStringBuf, size_t StringBufSize);

#ifdef UNICODE
#define LPFN_INET_PTON          LPFN_INET_PTONW
#define LPFN_INET_NTOP          LPFN_INET_NTOPW
#else
#define LPFN_INET_PTON          LPFN_INET_PTONA
#define LPFN_INET_NTOP          LPFN_INET_NTOPA
#endif

#endif  //  TYPEDEFS
#endif  //  (NTDDI_VERSION >= NTDDI_VISTA)

#endif

---

Next, copy that file to the appropriate location:

copy ws2tcpip-win.h c:\strawberry\c\x86_64-w64-mingw32\include

and update the existing 'ws2tcpip.h' file in that location with the following:

#include <ws2tcpip-win.h>

Now we need to create the library. This is done by first exporting the symbols from the appropriate DLL file - in this case, ws2_32.dll - and then creating the link library. The version of the MinGW gcc compiler with Strawberry Perl has 'pexports' included, so simply create the DEF file:

pexports c:\windows\system32\ws2_32.dll > ws2_32.def

Now create the library:

dlltool --as-flags=--64 -m i386:x86-64 -k --output-lib libws2_32-new.a --input-def WS2_32.def

Then put the new library in the appropriate location:

copy libws2_32-new.a c:\strawberry\c\x86_64-w64-mingw32\lib

Now we're ready to go. Get the latest release of Socket from CPAN, unzip and extract the tar file. Change into the directory and start the build process:

perl Makefile.PL

Now, before doing the 'dmake', edit the generated Makefile. Find the "DEFINE =" and "LDLOADLIBS =" lines and update them as per below:

DEFINE = -DHAS_GETADDRINFO -DHAS_GETNAMEINFO -DHAS_SOCKADDR_IN6 -DHAS_IP_MREQ -DHAS_IP_MREQ_SOURCE -DHAS_IPV6_MREQ -DHAS_INETNTOP -DHAS_INETPTON -DAF_INET6

LDLOADLIBS = -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 -lws2_32-new

Finally, 'dmake', 'dmake test' and 'dmake install' and you're good to go with IPv6!

The Adventures of Rich and Vince

Characters courtesy of SP Studio

Makeshift Mobile IPv6

For all its benefits, IPv6 also has increased support for mobility. This is due to the header structure of IPv6 accommodating extension headers - one of which is a mobility header.

However, given the slow adoption and limited deployment of IPv6, use of the mobility header isn't really prevalent and mobility of IPv6 nodes - my computer in this example - leaves a lot to be desired.

In fact, the only reason I have IPv6 working at home isn't from the forethought of my Internet Service Provider - Comcast, but because I'm tech-savvy and configured a Hurricane Electric 6in4 tunnel through their Tunnel Broker service.

---

NOTE: Comcast is very far ahead of many ISPs when it comes to IPv6 support including dual-stack support to end customers - unfortunately, just not in my area.

---

While the HE 6in4 tunnel works fine from my home - terminating on my home router with DD-WRT and providing all equipment in my home network with IPv4/IPv6 support - it doesn't help me when I'm not at home. When I take my computer anywhere - even into the office - I no longer can use IPv6, unless of course the network I connect to has IPv6 deployed (not likely).

My solution albeit not a very elegant one is to use another of the 5 free 6in4 tunnels HE provides me with. The first is for my home network and that stays static. The second one I have configured to a random endpoint which changes based on my location. HE offers a web-based update both manually and via a simple GET URL to change the local endpoint IP address of any of your 6in4 tunnels. The HE server examines the IP address from which it sees your request come from and adjusts the tunnel configuration on the server side. I even wrote a simple batch script to call the HE URL and configure the local tunnel interface on my computer. This works great ...

... but of course there's a catch. HE requires that the local IP address to terminate the tunnel be reachable via Ping. Therefore, if ICMP echo-requests are blocked or echo-replies are not sent, the tunnel won't get built. This is an issue as many sites prevent ICMP for security purposes - in fact, most all home routers disable ICMP from the Internet by default. For my home router, I can change the setting to have the tunnel built, but when I'm travelling, I'm relying on the network to allow ICMP so my mobile IPv6 tunnel can be built. Again, not the most elegant solution.

There are other options. SixXS offers a tunnel broker service and a client AICCU that provides AYIYA (Anything In Anything) support. This may provide a client-based alternative that doesn't rely on a provider network to support IPv6 or ICMP to build a 6in4 tunnel. I may test this next time I'm away.

The Adventures of Rich and Vince

Characters courtesy of SP Studio

Reach the Beach Relay - MA - 2012

Massakruliks - Mixed Open

46/175 - 13/52

Back row from left: Emily (leg 9), Bayen (leg 8), Bill (leg 7), Dan (leg 2), Robert (leg 3), Jen (leg 12)

Middle row from left: Ashley (leg 10, 11), Patty (leg 5), Jodi (leg 6), Suzi (leg 1)

Front row: Vince [aka: Me] (leg 4)

			Vert
	Distance	Difficulty	Gain	Loss	Net	Time	Pace
Leg 4	8.42	Moderate	678	750	-255	62:51	7:28
Leg 16	4.63 (actual)	Easy	164	127	37	32:10	6:57
Leg 28	8.11	Hard	194	248	-54	59:05	7:17
	21.16 (actual)					2:34:06	7:17

The Adventures of Rich and Vince

Characters courtesy of SP Studio

Network Virtualization - Then and Now ... and Future

Recent events in Software Defined Networking (SDN) - not the least of which was major vendors including Cisco and Juniper partner with universities to launch the Open Networking Research Center (ONRC) - have spurred me to take a closer look at the hype.

It's not like I was totally in the dark about this. "Network Virtualization" has been talked about since just after server virtualization hit the scene. It was more of a theory or pie-in-the-sky idea back then - no one really could articulate the real benefits in terms of cost or new functionality, but if you virtualized servers, networks were the next logical step - right?

So today, we hear about OpenFlow, which is just one implementation of network virtualization. How does all this fit in? What is the evolution? This is the way I break it down:

• Network Virtualization
• Software Defined Networking
• OpenFlow
• ...
• Multi-Topology Routing
• ...

So what's this multi-topology routing? Apparently, it's been around since at least 2007 and ready to go on Cisco devices, among other vendors. In fact, when I was working with mobile ad-hoc networks (MANET) from 2009 to 2011, we looked at various new routing protocols and enhancements to existing routing protocols to compensate for the low bandwidth, unreliable links typical in a MANET. One option was multi-topology versions of IS-IS and OSPF which would create logically separate routing tables over the same physical network links to provide routing based on user-defined categories. For example, one routing table would use higher bandwidth links and route only video traffic while another would use low bandwidth but more reliable links for voice. This would happen simultaneously over the same physical network.

The main difference from this network virtualization approach from the SDN approach that OpenFlow is championing is the control plane. In the multi-topology routing example, the routing processes are still distributed between the nodes that create the network. The network nodes need to be "intelligent"; they need to run a routing process, communicate with neighbors, maintain adjacencies and create a localized view of the network. With SDN and OpenFlow, the control plane is removed from the distributed node model and centralized in a controller.

This has some advantages. From experience, configuring multi-topology routing is complex and the more nodes in the network increases the difficulty and the chance for errors. A centralized controller that automatically distributes routing policy to small footprint agents on commodity network nodes eliminates the configuration distribution issue while also reducing costs of the network deployment. This starts to answer the "benefits in terms of cost or new functionality" question earlier in this post.

Additionally, with treating streams of similar packets as "flows", we can realize the benefits of a circuit switched model where routes through a network can be defined not just by the least hop count, but by other factors such as reliability of links, actual load on links and delay sensitive issues for real-time traffic such as voice and video. This all without compromising or changing the packet nature of IP(v6) networks.

Great - so where do I sign up? Not so fast. While research in this area is hot - trade magazines and conferences are highlighting OpenFlow and major vendors like Cisco and Juniper are taking notice, I don't expect a revolution soon. Places you'll see this first are certainly academia and high-tech content hosting companies with large-scale complex data centers. As always, enterprise adoption will be halted until a major vendor has an offering. And don't confuse Cisco's and Juniper's support of the ONRC as an immanent product offering. SDN has some real implications for major vendors. The removal of the routing smarts to a centralized controller means 'dumb' switches will suffice and for companies that make money off intelligent switches, a migration to SDN will hurt their bottom line unless they can control their destiny and entrance into the SDN fray.

And there are other mitigating factors that will push SDN in the enterprise off for about 5 years. The outsourcing of corporate networks to providers means one place SDN makes sense - the WAN - is offloaded. The other place - the data center - is another outsourcing play between all forms of cloud computing. Enterprises that maintain their own data centers are just coming to grips with data center "fabrics". Typical capital expenditures for networking components are closer to 5 years. Besides, those heavy into virtualization may already be using "network virtualization" - the Cisco Nexus 1000V.