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.
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.
If you’ve ever played around with setting up multiple web sites on your servers using SSL for enabling HTTPS there’s probably a thing that’s been annoying you once or twice – the fact that you can only use one SSL certificate per IP address. (I am assuming IIS is your web server of choice for the sake of this discussion.)
Now of course if you happen to have an ISP which will happily supply you with IP addresses this isn’t a problem (at least in the short term); I have TMG servers with 20 external IPs for this very purpose. But IPv4 addresses are getting harder to come by, and if you try to sign up for 100 public IPs from your DSL-connection at home your ISP will most likely just laugh at you and say “no go”.
But why does it work for HTTP and not HTTPS? Well, the thing is that the host name is included in the HTTP header, and as such the client’s intended host name can be parsed by the web server. With HTTPS an SSL handshake is performed before exchanging headers, and the web server thus cannot base itself on the header information.
Server Name Indication (SNI) is an attempted solution to fix this issue. The domain name is extended to be part of the SSL handshake process, and then you can do for HTTPS what you can do for HTTP.