Open Radar

 
Area:
Wi-Fi

Summary:
Sometimes iOS will send an IPv4 packet over WiFi, but with the packet type set to 0x86dd, or IPv6.

This will cause the receiving router to parse the header as if it were IPv6, and if it makes it pass the parse, extract an incorrect destination address from the header. At best the packet appears to be destined for a nonsensical IP address. In general the packet is dropped, later the application on iOS retransmits, and the packet is sent correctly.

While this only happens for a very small percentage of packets, it is 100% reproducable. The errors are enough to cause retransmits, and for IPv4 connections to suffer some performance. Our routers see these bad packets regularly. We have seen the problem both in U.S. and Europe.

Steps to Reproduce:
1. Connect an iOS device to an unencrypted WiFi network that offers both IPv4 and IPv6 service to the iOS device.
2. Use the YouTube application on iOS.
3. Watch a video. (This will send mostly IPv6, but with some IPv4)

At the same time, use an OS X device nearby, start "Wireless Diagnostics", and use the Sniffer function. This will capture packets off the air.

Expected Results:
All IPv4 is sent as IPv4

Actual Results:
Some small, but appreciable percentage of IPv4 packets will be sent over the air marked in the Logical-Link header as IPv6 (type 0x86dd).

Configuration:
iPhone 6s

Version:
iOS 10.2.1

Notes:
1) We have observed this on multiple models of iPhone, and with various iOS versions.

2) If you capture the traffic off the device using the remote virtual interface (RVI) for developers - the packets as catpured there will have the correct ethernet type field, marking them IPv4. It is only over the air that they are sent with the incorrect type, marked IPv6.

3) We do not see this issue on authenticated WiFi networks, only open, unencrypted ones.