Remember my "happy eyeballs" post? Well, it looks like it's causing issues with YouTube clips both on MacOS X (Mountain Lion) as IOS (6). The symptoms? Clips that refuse to launch and result in a black screen filled with pseudo static and a "An error has occurred. Please try again later." Even worse, some clips actually start to play and stop after a while. BTW, the error message is very helpful Google, thanks. The issue exists on Safari and Firefox; Chrome seems to immune. I was quite sure it had to do something with the dual stacked IPv4/IPv6 set-up we use at home as disabling IPv6 on my MBP made the issue disappear. But what is causing the problem? And is there a fix? Googling quickly pointed to "happy eyeballs", which confirmed my findings after some observations and a good deal of TCPdumping. But why would this happen as "happy eyeballs" was created to prevent bad user experience on IPv6 in the first place. To understand what happens while viewing a YouTube clip, I used HTTPfox on Firefox. HTTPfox is basically a local proxy which shows all the requests generated by the page you're visiting. The following screenshot shows a clip I was viewing and that stopped halfway... Digging into the output of HTTPfox one can easily retrieve the URLs that deliver the actual video stream. Google has its own Content Delivery Network (CDN), which presumably tries to deliver data as close as possible to the end user.
In the above example the content cache was:
And now it becomes interesting as this host resolves to:
How and where the actual caching node is defined in the HTTP exchange is not really clear to me, but typically this is "somewhere" defined through geoIP lookups of the source IP of the requester. The obvious issue here is that my geo-location is completely different over IPv4 and IPv6 as I use a Hurricane Electric tunnel for my IPv6 connectivity. And even if my provider would deliver native IPv6 connectivity, it will still show a very different routing path. While one is looking at a YouTube clip, multiple HTTP GETs are send out to the content cache to retrieve gradually the content. And here lives the culprit! As "happy eyeballs" kicks in and tries to deliver connectivity over the "best path", it might actually change its decision during the session. In other words, one HTTP GET can go out over IPv4 but seconds later, the next HTTP GET would go over IPv6. In theory this shouldn't be a problem if all caches are equal, but it depends heavily on how the caches actually operate and the application works. If sessions are involved i.e., are we sure that the IPv4 and IPv6 are actually the same machine(s); if not how is the system supposed to stitch the IPv4 and IPv6 session together? I believe this is exactly what happens with Safari and Firefox on YouTube. The fact that my IPv4 and IPv6 routing is completely different and the likelihood that the IPv4 and IPv6 infrastructure is not the same on the CDN side, might very well result in lost, unknown and zombie sessions. For a pseudo streaming application like HTTP-based QuickTime streams or YouTube clips, "happy eyeballs" is very dangerous. Pseudo streaming applications send chunks of media data and rely on the fact that the network is faster than the realtime stream. For this specific clip it sends packets of 1,6 MB according to the HTTPfox output. Conclusion: the browser should not only rely on the OS implementation of "happy eyeballs" as it could change IP stacks during a session or HTTP conversation with potential undesired side effects. It should stick to one IP stack after the initial decision handler to preserve session integrity. As to view YouTube clips, I think I'll stick with Chrome until Apple and Mozilla engineers have figured out a way to fix this issue.
0 Comments
When looking for information on IPv6 support in Apple's iDevices, one finds very little information regarding the subject. Does the iPhone or iPad support IPv6 and if so how well is implemented? The short answer on this question is: YES, Apple's iDevices support IPv6; but it will default over IPv4 unlike most desktop and server Operating Systems. The iPad used in the following screenshots is an iPad 2 running IOS 5.01 as shown below. If you have an IPv6 enabled network, with an IPv6 router that does router advertisements, an IOS devices will perfectly auto configure itself as expected. Yet oddly enough it will prefer IPv4 over IPv6. To find your IPv6 settings, look under Settings and Wi-Fi. You will not see its IPv6 address nor the IPv6 gateway, but the fact that it has an IPv6 name server address, that appeared automagically, says enough. I was rather surprised to find 2001:470:1f13:75c::1 as the IP address for a NS since this is actually the router address of my IPv6 router. It's an Apple Time Capsule I use for its IPv6 tunneling capabilities. It must contain an implementation of RFC 6106 which describes DNS Configuration Options for IPv6 Router Advertisements. The name server behaves like a caching name server. From the IP configuration one can only guess the IPv6 address of the iPad. Why Apple shows the IPv6 address of the name server, but omits the iPad's address is a mystery. To prove the iPad can actually function over IPv6, I downloaded and installed zatelnet, a telnet and ssh client for iPad. It might not be the fanciest telnet/ssh client on the market, but for this purpose it did what it was supposed to do. I could connect without any problem to tripple6, a Linux machine on my IPv6 network, which shows the iPad is perfectly capable of functioning correctly over IPv6, if forced to do so. Once connected to a linux machine, it's child's play to figure out what the actual IP address is of the iPad. So what does this prove?
Conclusion: you will only benefit of an iPad's IPv6 features if and when you are on a IPv6-only network. The device will auto-configure and work as expected. In a dual-stacked environment, it will stick to old school IPv4. |
About this BlogIT Technology, networking, Apple, iDevices, Android, IPv6, DNS. Archives
November 2015
Categories
All
|