Mobile Devices and IPv6. How Goes? – Part I

Ever wondered if your mobile devices will play nice with IPv6?
Me too 🙂

Wikipedia obviously has an article for this purpose already:

But it’s not entirely up-to-date, and didn’t really give me the details I wanted. (Not to mention the learning effect for me personally isn’t all that much just skimming through a feature matrix.)

The idea for this article came about a long time ago, but it’s taken a good while for me to get around doing the lab work for this exercise.

There’s a number of reasons for this; support in operating systems for desktops and servers of course, as well as support in the network equipment and everything. And let’s be honest, I had to learn a thing or two about IPv6 to be able to get this right.

I’m not going to go into the details of why we need IPv6, what’s so great about it, yada yada yada. If you are reading this site and know what IPv6 is all about odds are you’ve heard a lot of the arguments before. Do we need IPv6 on our mobile devices yet? Well, I’ll admit that it’s not like I have a major issue using my devices with the current IPv4 mobile networks. Most mobile operators I know of do things like NAT, and often block incoming traffic anyways so you don’t need public IPv4 addresses. (It’s not like you host servers on your tablets all that often.) But things like VPN and IPsec, which can a hassle on mobile devices, would most likely work better with fully routable IPv6 mobile networks. My motivation for testing it is not that this is something I desperately need right now, but I want to know if my mobile devices are ready if I decide to switch my LAN to IPv6, and my ISP eventually delivers it natively to my router. When the mobile operators switches over is a different thing entirely, and I’ll focus my testing on the Wi-Fi, not the connectivity provided by the SIM card.

This first post will be a bit longer than average, but there’s a lot of ground to cover just to get started, and it didn’t feel right to split it into more parts just to make the individual exercises shorter. I hope you’ll still tag along to the end.

I could of course attempt to enable full support for IPv6 in the infrastructure I’ve already got running, but my previous experience making some minor mistakes setting up ForeFront UAG and Direct Access tells me it has the potential to mess things up quite good if I don’t get it right, so because of this I’ll be building a separate IPv6 lab.

I’ve used the "Windows Server 2012 Base Configuration" for setting up a lab consisting of two subnets, and a couple of servers:
Windows Server 2012 Test Lab Guides – TechNet Wiki

If you want to go with Windows Server 2008 R2 that’s ok – I believe all the commands I run should work on both R2 and 2012. (With 2012 you can use PowerShell cmdlets, but I’m using netsh commands instead so it’ll be compatible with both OS versions.) When I have all the servers running it eats up about 5 gigs which should be doable if you’ve got at least 8GB RAM, but you can probably skip the INET1 server to save a few bytes of memory if you so wish.

After building this you’ll have a infrastructure working with IPv4, and subsequently we’ll build on that to add IPv6. (I’ll get back to this in a moment.)

While a virtual lab is all nice and dandy it doesn’t play well with mobile devices so I need an actual wireless access point for this purpose. I went with the latest Apple AirPort Express for this lab. There are of course other wireless products out there supporting IPv6, and probably with more bells and whistles too, but I chose the AirPort Express because I needed something reasonable priced for my lab since I don’t want to mess with my "production" wireless. My current environment happens to be served by an AirPort Extreme so I’m already familiar with the settings and know that the IPv6 settings has the dials and knobs I need for the lab. It should likely be easy to transfer the settings to the AirPort Extreme afterwards should I want IPv6 outside this lab if the AirPort Express works. If you want to follow along, and have something else, you’ll just have to make an attempt to configure your gadgets similarly.

If you only want to test this in a closed lab you can simulate Internet access, or more likely just test the intranet, and you’re not dependent on actual IPv6 connectivity to the Internet. If you want to surf "properly" you might want to check out the free tunneling service from Hurricane Electric at I’ve used this with success for some other IPv6 experiments of mine earlier. I’ll have a go at taking us through that too later on in part two of the lab.

So, let’s pretend that I left off for an hour or two to install the servers… And we’re back 🙂

If you’ve followed the instructions in the lab guide you should now have full IPv4 connectivity between the computers on the "Corpnet", and you should have connectivity between the EDGE1 server and the fake Internet. There is however no routing configured on the EDGE1 server so your CLIENT1 computer will not be able to browse the emulated Internet.

There isn’t any hook-up for wireless access either, so that needs to be fixed before the mobile devices has any chances of connecting.

Oh, and you might want to take snapshots of your virtual machines now in case a rollback is needed after messing around 🙂 Even if you don’t mess up it sure is a quick way to reset things back to an initial state.

There are a number of places we could have inserted a wireless Access Point. I’ve made the choice of adding an additional subnet, which will be connected to DC1 and attached to my wired LAN. (The rest of the network is purely virtual at the moment – since it’s all on one Hyper-V host I went for a VM-internal network.)

So, here are the steps we’ll start out with:
– Add a new network interface card (NIC) to DC1. Make sure this virtual NIC is connected to a physical NIC.
Start and log on to DC1
– Rename the two NICs – I called them "Corpnet" (per the Lab Guide) and "CorpWLAN".
– The two network cards should be configured for IPv4; set the following details for the CorpWLAN NIC:
IP Address, subnet mask, DNS suffix
(DNS suffix can be found under "Advanced Settings".)
The Corpnet NIC should already be configured if you followed the lab guide for setup.
– Add a new IPv4 DHCP Scope called CorpWLAN.
Use the following parameters:
IP Range: Start, End, Subnet Length 24
– Right-click the Corpnet scope and choose to "Configure options".
Check "121 Classless Static Routes" and add a route with the following details
Destination, Network Mask, Router
– Open the command prompt and run the following two commands:
Netsh interface ipv4 set interface Corpnet forwarding=enabled
Netsh interface ipv4 set interface CorpWLAN forwarding=enabled

Switch over to EDGE1
– Open the command prompt and run the following command:
Netsh interface ipv4 add route interface=Corpnet nexthop=
– Open "Network and Sharing Center", "Change advanced sharing settings", click "Domain" and switch to "Turn on file and printer sharing"

Switch over to APP1
– Run the following command (in a command prompt window):
Netsh interface ipv4 add route interface=Ethernet nexthop=

Using the CLIENT1 VM you should now be able to test that there is full IPv4 connectivity on the Intranet including between the corporate subnets. (You can move CLIENT1 between the subnets by changing the mapping of the virtual NIC.) While not technically required I decided this would be a good time to test that the AirPort is able to play nice with the lab servers. After all – unless IPv4 is a known-good config it’ll be real fun to troubleshoot a non-working IPv6 network later on.

I’ll setup the AirPort by connecting the WAN interface to what is my LAN wired network. There is nothing connected to the LAN port. The AirPort does a rather nifty job at figuring out how you’ve wired things and configuring itself accordingly, but let’s double check that it’s making the right choices this time.

We want it to have the WAN IP set to an address in the CorpWLAN IP range, and we want it to act as an access point so we’ll place it in bridge mode on the WLAN side.

This is what it looks like using AirPort Utility 6.1 on OS X.

Internet Settings

Router Mode

I don’t expect all of you to use AirPorts, but so far we’re looking at standard settings for wireless equipment, and this should be fair game for both wireless routers and dedicated access points. The AirPort actually configured itself like this automatically to use DHCP on the WAN side and act as a bridge on the WLAN side so this is really just me verifying the settings.

In the DHCP console on DC1 both the Airport and the iPad now shows up with an IP address:


I tested with an iPad that I was able to surf to the default web site configured on the APP1 server, and it worked the way I wanted/expected it to, so at least now we know that the basic infrastructure itself is good.


Alrighty then, the packets are moving like they should so let’s move on to IPv6.

There’s a couple of different scenarios regarding the configuring of the endpoints (aka devices) when it comes to IPv6. Do you want to use DHCP, or do you want the devices to configure themselves with auto-assignment of addresses? (Static addressing is possible, but probably something you want to avoid.) Do you want native IPv6, or use any of a number of tunneling protocols like ISATAP, Teredo or 6to4? ("Want to" and "need to" aren’t necessarily the same thing.) How do you design the subnets with public vs. non-public addresses? (NAT doesn’t exactly serve the same purpose anymore.) There’s a couple of options, and it also depends on whether you’re only looking to deploy IPv6 internally, or you want to access the IPv6 Internet as well. If you have a bunch of legacy apps and servers they might not be able to support IPv6 in any form.

I really don’t consider myself enough of a pro on the topic to give a full-on tutorial of IPv6 and advise on best practices. To get up to speed I used Understanding IPv6 3rd Edition ( which I can recommend if you feel you’re not entirely comfy with version 6 yet. (I borrowed some advice from the Appendix section to build this lab.)

What I want to test in this first part is that my device is able to reach Intranet locations on IPv6, so a tunneling scheme would actually work against what I want to test. I’ll be setting up IPv6 native on my servers. For the test I choose the 2001:db8::/64 prefix since that address range is designed for serving documentation purposes.

Here’s the steps needed to set up the interfaces and routes.

Make sure CLIENT1 is connected to the CorpWLAN subnet.
Logon to EDGE1:
– Run ipconfig from the command prompt. Make a note of the link-local IPv6 address on the Corpnet interface – the one starting with fe80::

Logon to DC1:
– Open the command prompt and run the following commands:
Netsh interface ipv6 set interface Corpnet forwarding=enabled advertise=enabled advertisedefaultroute=enabled
Netsh interface ipv6 set interface CorpWLAN forwarding=enabled advertise=enabled advertisedefaultroute=enabled
Netsh interface ipv6 add route 2001:db8::/64 interface=Corpnet publish=yes
Netsh interface ipv6 add route 2001:db8:0:2::/64 interface=CorpWLAN publish=yes
Netsh interface ipv6 add route ::/0 interface=Corpnet nexthop="EDGE1 link-local IPv6 address" publish=yes

At this point DC1 will start to advertise the routes and the prefixes, so if you check on the CLIENT1 computer you’ll see that it’s got an IPv6 address starting with 2001:db8:0:2. CLIENT1 should also be able to ping the computers on the Corpnet subnet by their names. However, this being Windows we really need to setup DHCP as well. The configuration above will enable "Stateless Address Autoconfiguration" (shortened SLAAC), meaning that the information DC1 broadcasts will be sufficient for a client to give itself an address and the necessary routes for reaching other clients on the same subnet. It will however not give the client the address of an IPv6 DNS Server, meaning you’ll have a hard time surfing the Internet the normal way.

So, for things like this we need "Stateful Address Autoconfiguration", aka DHCPv6. Why not rely only on DHCP? Well, DHCP will give the client some info, but it will not provide the clients with the routes for the local subnet. This means that the clients will have to make an extra trip to DC1 just to be redirected to the correct host on the same subnet. Not optimal. (Broadcasting doesn’t work the same way any longer either.)

Therefore we need to combine the two address configuration methods to get all the necessary info provided to the client. The devices will receive two IP addresses this way, but we’ll be able to live with that. Note that this is a Windows specific thing in this lab, so it may or may not be relevant depending on what other IPv6 network equipment you have. I currently don’t have information on how mobile devices have implemented the relevant RFCs so I don’t know what they require. When you have both methods enabled it should work one way or the other 🙂

At this point I was not able to find anything in the AirPort Utility indicating that the Access Point had picked up any IPv6 settings from DC1. Yes, maybe it is working with IPv6 behind the scenes without me knowing it, but it’s not like that helps me.

Moving along the following will configure DHCPv6:
Log on to DC1
– Open command prompt and run the following commands:
Netsh interface ipv6 add address Corpnet 2001:db8::1111
Netsh interface ipv6 add address CorpWLAN 2001:db8:0:2::2222
Open the DHCP console, and select IPv6 in the tree.
Right-click and click "New Scope".
Click "Next".
Set Scope name: Corpnet –> Next
Scope Prefix: 2001:db8:: –> Next
Add Exclusions –> Next
Scope Lease –> Next
Activate Scope Now -> "No"
– Create another new scope with following details:
Scope name: CorpWLAN
Scope prefix 2001:db8:0:2::
Select "No" on Activate Scope Now here too.
– Back to the command prompt and run these two commands:
Netsh interface ipv6 set interface Corpnet managedaddress=enable otherstateful=enable
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:db8::1111 -> Add followed by "OK".

You can now activate both scopes.

By now we should be ready for the interesting part – will it blend? Eh, I mean, will it work? 🙂

So, I checked the settings of the AirPort Express to see if there’s anything new to report, and that’s a fun thing to do sometimes… I’m still not able to find in the UI any indication of any IPv6 addresses assigned to it. I am however able to find it by checking the logs of the device. But I’m only able to find the option to view the logs when using AirPort Utility 5.6.1 for Windows. I’m not finding it in the iOS or OS X version of AirPort utility. (As a side-note Apple got a lot of flak for removing features from the interface in version 6.0, so they re-added some of them in 6.1. The older 5.x versions will not run on Mountain Lion without hacks, but if you get that working in OS X it could be that it’s available there as well; I haven’t tested this.)

AirPort Utility for Windows

The iPad is still able to browse to APP1, but only displays an IPv4 address when I check the properties for the wireless network. It includes the IPv6 DNS server address however indicating it has received a DHCPv6 reply from DC1 (in addition to showing the IPv4 DNS server address). The MacBook which is connected to the same wireless network shows an IPv6 address when running ifconfig (this being OS X, and not the Windows partition ipconfig is not the command of choice) so I’m hoping it’s working behind the scenes.

To get in to the real testing mode however, we need to make sure that we’re only running IPv6 to force the devices to not attempt IPv4. Windows will prefer IPv6 if both are available, but we can’t be sure with the mobile devices. Let’s deactivate IPv4 on our CorpWLAN.

Log on to DC1
– Select at the root of the DHCP console, right-click->"Add/Remove Bindings…"
– Uncheck the IPv4 bindings.
– Restart DHCP service.
– Restart AirPort Express.

As an additional measure I also disable IPv4 on the network adapters involved in the lab so they can’t communicate with a static IP set either. I probably could have got away performing this last step, and not removing the bindings from the DHCP server, but it doesn’t hurt to do both. You should still be able to ping all servers by name without any issues if the infrastructure components are working.

The AirPort Express got fussy at this point and claimed that Internet is not ok any longer, and resorts to 169.254.x.y as it’s WAN address. I’m still able to ping the IPv6 address of the WAN interface though. The AirPort Utility throws a fit when I disabled IPv4 on CLIENT1 so I had to re-enable it to be able to configure the AirPort. Since DHCPv4 isn’t available CLIENT1 also reports to 169.254..x.y, but that’s not a problem as long as IPv4 is enabled AirPort Utility is happy. (Fun fact – the utility is able to find the AirPort without IPv4 enabled, but not connect to it for configuration purposes.)

I then proceeded to manually fill in the IPv4 details it had previously been given from IPv4 DHCP, in other words an IPv4 address in the range. While I wouldn’t call those settings "working" given the rest of the servers has IPv4 disabled, the AirPort me that it had Internet access now. Go figure… The setting for a IPv6 DNS Server is on the same tab as the manual IPv4 settings, (which I just set), and since there is no clue as to whether this behaves statically as well I assumed it was and configured it accordingly figuring it doesn’t matter whether the AirPort gets this from me or from DHCPv6.

To enable IPv6 on the client side of the Airport I set "IPv6 Mode" to Host, and "Configure IPv6" Automatically. This may be called something else entirely on your non-Apple router 🙂

AirPort Utility –> Advanced –> IPv6

Not entirely unexpected my iPad ended up with 169.254.x.y. as it’s IP address as there is no DHCPv4 server on this subnet any longer.

I tried looking into the settings panel on my iPad to see if I could figure out the IPv6 address, but no luck. While the IPv6 DNS server address will be present in the UI it seems you don’t get to see the IPv6 addresses in the interface. I had to hook up the iPad to iPhone Configuration Utility running on my computer to learn that it had indeed acquired IPv6 addresses and make a note of them. One probably came from the stateless autoconfig, and the other I’m able to find in my DHCP console so that probably was delivered by DC1 to the iPad. iOS thusly seems to support both stateless and stateful even if Apple deems it to be too secret to expose directly on the iPad 🙂

iPhone Configuration Utility –> Console

I’m still able to browse to http://app1 without any issues so there must be IPv6 traffic flowing to and from the iPad. (Parsing the logs on APP1 will not present the correct results as the traffic was routed through DC1, so you’re not seeing the iPad IPv6 address in the logs.)

We now have a working IPv6 lab, and you’re probably getting used to the far too long addresses by now, so let’s take a break at this point 🙂 There’s more to come, and I’ll continue in the second part of this article.

2 thoughts on “Mobile Devices and IPv6. How Goes? – Part I”

Leave a Reply

Your email address will not be published. Required fields are marked *