If you followed the first part of this article you should now have come to the stage where you have a working IPv6 lab, and an iOS device enjoying the IPv6 intranet. If you’re interested in doing the hands-on testing you should complete part one first before continuing, but if you’ve already done that, or just want to read about my experiences come along for the next part of the ride.
I started with the iPad since I knew that would play nice with the AirPort Express, and it would let me play with the AirPort Utility on the device as well. But how about throwing some other mobile operating systems into the mix? Let’s start with Windows Phone. (Yes, there’s a reason I test this before Android which will be apparent in the next paragraph.) Windows Phone 7 and 7.5 Mango doesn’t support IPv6 as far as I know (I believe I read this on an official feature list way back in time). My HTC Titan is upgraded to Tango though, and I’ve heard some conflicting rumors previously regarding IPv6 support in this build so I want to verify if this build is the same in the networking department.
Windows Phone was able to find the network and prompted me for the WPA password before attempting to acquire an address. It then simply informed me it would not work because the network was not responding. Since you’re not able to configure Wi-Fi manually in Windows Phone I made no attempts to set a static IPv6 address. The MSDN library indicates that the OS itself supports IPv6 addresses, but maybe the Wi-Fi app and driver stack doesn’t support it yet. (My device came with Mango installed, and has been upgraded to Tango. I don’t have access to a device with Tango as the stock build, so I don’t know if they might have different driver stacks.) Since the SDK and docs for Windows Phone 8 isn’t public yet I don’t know if the upcoming WP devices will work, but since the kernel is supposed to share traits with the desktop counterpart this time around it wouldn’t be wrong to hope IPv6 support is coming to Windows Phone with the new devices.
Android…What to say… Yes, I have heard of the internet, and I know there are posts on the official developer forums demanding full IPv6 support indicating this effort might not yield the result I want. But since some of that information was outdated, and I just upgraded to Jelly Bean on my Galaxy Nexus I thought it would still be worth hands-on testing.
The Nexus was also able to find the network and authenticate, but got stuck on the "getting IP address" part of it. Oh, well, there is an option for setting the IP address manually in Android so let’s have a go. There was no indication as to whether it would accept IPv6 or not, but when I typed in an IPv6 address it suggested an IPv6 router address so it looked promising. Typed in the details and hit save, spotted a strange error message about avoiding a bad internet connection, and the device rebooted. And rebooted. And rebooted. When rebooting it will get to the point where I’m supposed to enter my pin code / password (whichever comes first), and before having time to type anything it will reboot again. The fix? Unplug the power from the AirPort Express so the IPv6 network is not available. You should then be able to login to your device, and remove the offending network. Proceed to plug the AirPort into the wall outlet and boot it up again. You should probably never think of connecting your Nexus again with this configuration before having a statement in your hand that IPv6-only is officially supported… I mean, go ahead and ignore adding proper support for IPv6 in the devices, but going so far as to break the OS – that’s a mean bug.
Granted, this could be something specific to the Nexus. I found a Galaxy Note 10.1 (running Android 4.0.4), to see what that gave me. That one also got stuck on the part where the device is supposed to acquire an IP address. But it didn’t enter the reboot loop, so the fail to connect was graceful at least.
I’m not done with the testing for Android and Windows Phone yet, but I’ll leave them be for now and will be revisiting them a few paragraphs down.
I didn’t feel it was necessary to test more operating systems at this point having covered what is most relevant for me 🙂 But if you’ve got the devices and the lab you can test anything you like of course.
At this point I was thinking about doing some testing based on the fake Internet running on the INET1 server, but decided it wouldn’t really add that much to this lab. Instead I wanted to try connecting to the real Internet, but if your connectivity options will not allow you to reproduce the steps I take you might want to have a go at doing the same thing with the fake scenario.
I previously mentioned Hurricane Electric and their IPv6 tunneling offer, and since I haven’t got native IPv6 on the WAN side I decided to use that for reaching the IPv6 part of the Internet. If you go to http://www.tunnelbroker.net you should be able to create an account and request a tunnel. Doesn’t cost you a dime, and you’ll have the necessary details in seconds. You can also do cool things like choosing the egress point you want, so you can have your IPv6 traffic originate "wherever" you want in the world.
I re-configured my AirPort to have a proper WAN connection to the WAN port, which in my case is a proper public IPv4 address. Both static and dynamic IP addresses will work unless your ISP is up to tricks preventing it. If you have a NAT in front you need to pass protocol 41 along to your tunnel endpoint (the wireless router in this case). I hooked the LAN port to my CorpWLAN subnet. While not technically necessary I did a hard reset of the AirPort as well to start with a clean slate.
There is a configuration example for the AirPort when you login to your Tunnelbroker account and look into the details page, but other routers would also work for this exercise. There’s samples for establishing the tunnel directly to a Windows server, Cisco box, etc. You could say it’s a bonus that having the tunnel endpoint on the wireless router you don’t need yet another box to figure out when troubleshooting your lab environment. The only slight change I did compared to the instructions on the site was that while the sample tells you to fill in the prefix (2001:470:x:y::) for the LAN IPv6 address I typed in a complete address (adding 1111 to the prefix, ending up with 2001:470:x:y::1111). This is because I will still be using DC1 for DHCPv6 and SLAAC. This lets me know the actual LAN IPv6 address of the AirPort instead of having it auto-assign itself an address I’m not able to learn from the device. (It doesn’t seem like the address it assigns itself is available in any logs or UI.)
For the AirPort to work in this configuration you also have to enable NAT and set up IPv4 DHCP even though you will not be needing this for IPv6. This is slightly annoying because the AirPort will insist on being in router mode where it acts as the DHCP server, and will not allow me to let me run my own DHCP server. For an enterprise setup it is of course entirely normal to not have the router perform DHCP (or DNS) services and just act as, well, like a router 🙂 But unless someone knows of a secret config mode in the AirPort I’m not aware of let’s just call this further proof that it is a device intended for your average consumer scenarios. (You can’t disable IPv4 on the LAN side either in case you’re wondering. And since we need IPv4 WAN side for the tunnel, we can’t provide a fake IPv4 setup either.)
Note: I am getting the tunneling error Hurricane Electric mentions on the config sample page, and I’m not able to get rid of it. This doesn’t seem to have an actual impact as long as the rest of the components are correctly configured.
If you want to get creative I guess you could work out something like putting it in bridge mode, and not wire it to the LAN, only to have another device at the edge to route IPv6 through to the LAN. This way you could use the AirPort for the sole purpose of acting as an IPv6 tunnel endpoint. Not sure if this would be very logical if you wanted your wireless devices to access internal resources though. You just do whatever works best for your infrastructure; for the sake of this lab we’ll go with this setup 🙂
I initially had an idea that I’d be using a Cisco ASA 5505 to host the tunnel and perform firewall duties on the edge with the AirPort sitting behind that, but from what I can gather of info the ASA cannot be the tunnel endpoint, even though it does support IPv6 and firewalling of IPv6 traffic. It can function as an IPv6 endpoint if it is supplied with "native" IPv6 by a router in front. I’m not a Cisco expert by any means so I’m not going to try to disprove this statement or hack my way around it.
I reverted the VM state to the snapshots I made earlier so DC1 would start with a clean IPv6 configuration server side as well, and I assume for the next steps that the previous config steps have been removed or reversed. (This means that you cannot access APP1 any longer unless you re-establish the routing between CorpWLAN and Corpnet as performed in part 1.)
Make a note of the /64 prefix supplied to you by Hurricane Electric (or your ISP if they provide this service) and substitute accordingly in the commands.
Logon to DC1 and run through the following steps:
–Netsh interface ipv6 set interface CorpWLAN advertise=enabled advertisedefaultroute=enabled
– Netsh interface ipv6 add route 2001:470:x:y::/64 interface=CorpWLAN publish=yes
– Netsh interface ipv6 add route ::/0 interface=CorpWLAN nexthop="AirPort LAN IPv6 Address" publish=yes
– Netsh interface ipv6 add address CorpWLAN 2001:470:x:y::2222
– Create a new IPv6 DHCP Scope with the following details:
Scope name: CorpWLAN
Scope prefix: 2001:470:x:y::
Do not activate the scope yet.
– Back to the command prompt:
Netsh interface ipv6 set interface CorpWLAN managedaddress=enable otherstateful=enable
– Return to the DHCP Console.
Right-click Server Options –> Configure Options
Check "0023 DNS Recursive Name Server IPv6 Addresses" and add the following address 2001:470:20::2 -> Add followed by "OK".
This is Hurricane Electric’s DNS server. If you want to you can use Google’s DNS instead; 2001:4860:4860::8888. If you get an error choose to ignore it.
– Activate the scope.
You might want to surf to http://ipv6-test.com or something similar to verify functionality now. Hopefully it will state that you have a native IPv6 address, and display the IPv6 address of the device. Usually with IPv4 and NAT a public IP address will be shown in these tests, (which is the case for the IPv4 address on this test page), but one of the purposes of IPv6 is to have fully routable addresses, so it is the "internal" IPv6 address that is displayed externally as well. The AirPort by default blocks all incoming IPv6 traffic so this shouldn’t be a risk per se.
There is no option to disable IPv4 in the iPad, so you’ll have to run dual-stack, but that’s realistically what you’ll be doing anyways in most LANs for the near future. I tested surfing on CLIENT1 (which runs Windows 8) with IPv4 disabled, and that worked nicely. The restriction on the iPad does not come from the AirPort, but rather from iOS itself. With IPv4 disabled in Windows the IPv6-test web site did however say that my internet connection is not IPv4 capable, and I can only surf IPv6-enabled sites – the extent of the Internet is reduced by running IPv6-only. So, yeah, you’ll want both versions of the TCP/IP protocol enabled in most cases.
I said that I would be revisiting Windows Phone and Android, and this would be the time for it. The first test was with an IPv6-only WLAN, and that didn’t work out well. With the setup we’re running now the devices should at least be able to connect to the Internet over IPv4. Let’s see if that works out.
Windows Phone is first up to bat, and the easiest one at that. I’m able to connect and I’m able to reach the Internet. But testing shows that it is not able to reach any IPv6 sites, and it fails on the IPv6 test sites. Guess we’ve confirmed IPv6 is not an option on current Windows Phone devices.
Android behaves differently this time around. Both the Android devices I used connect without any issues now, and will happily inform me of the IPv4 address in the UI. This is expected. There are however no problems browsing sites like http://ipv6.google.com either this time. If I access the test sites I even get an IPv6 address, and a "pass" result. The problem is figuring out where the IPv6 address came from… It’s not in the DHCP console of DC1, and it’s not in the DHCP Clients view in the AirPort UI (the devices are listed, but only with their IPv4 addresses). So did they get their address doing a stateless autoconfig from the AirPort or DC1? There’s no telling really at this point, but that doesn’t really matter, they have an IPv6 address and if it’s not through DHCPv6 it’s most likely through SLAAC.
If anything it confirms the information in this thread (scroll to the end):
http://ipv6-test.com as viewed on the Galaxy Nexus
Nice, isn’t it?
I tested a couple of different Android combos just to make sure:
Galaxy Nexus w/Android 4.1.1 – works, but prefers IPv4.
Galaxy Note 10.1 w/Android 4.0.4 – works, and prefers IPv6.
Galaxy Tab 8.9 w/Android 3.2 – works, and prefers IPv6.
LG P500 w/Android 2.2 – does not work.
(Old device with old Android version so I wasn’t expecting it to work.)
I don’t know why the tablets prefer IPv6 and the phone prefers IPv4. Could be coincidences.
Bottom line; the quick summary / conclusion of the tests:
Windows Phone: IPv6 support not present.
Android: IPv6 support present, but sketchy. Don’t rely upon it unless you test it in your specific IPv6 environment. Requires Android 3.x.
iOS: IPv6 support present and top-notch.
Technically Windows 8 could be included on the list as well since we will be seeing devices shipping with it in about a month. The tablets we’ve seen announced so far running Windows 8 Pro work the same way as a desktop/laptop does and those aren’t going to have IPv6 issues, but from what I gather it’s Windows 8 RT that will go head on competing with iPad and Android tablets. There’s not any devices available yet that I can test with so it’s hard to verify anything. Sure, I can make assumptions, but I prefer actual testing.
I have mixed feelings about the results. I would have expected more mature implementations at this point, while at the same time realizing that IPv6 isn’t the type of feature you woo consumers with. Dual-stack wasn’t a problem, so I might look into actually deploying IPv6 on my LAN and take responsibility for future-proofing my network 🙂