IPv6 compliance when connecting to IPv4 device on private network

This relates to Apple's requirement for IPv6 support, as discussed at https://developer.apple.com/news/?id=05042016a


Our app connects to a private WiFi access point generated by a hardware device which only supports IPv4, and does not have a DNS entry or other FQDN. We are connecting to this device using a hard-coded IPv4 address string using the CFNetwork library (specifically CFStreamCreatePairWithSocketToCFHost()).


Is this an acceptable use per Apple's new policy? We understand that using an IPv4 address literal is not ideal, but don't really have an alternative at this point. Our reading of the policy is that this usage would be acceptable (since the app is otherwise compliant and will continue to function normally when connected to an IPv6-only network). However, we would still like to confirm one way or the other.


Thanks.

Up vote post of chrisvig Down vote post of chrisvig
2.4k views
Posted by
chrisvig
Reply
Add a Comment

Replies

We are facing exactly same issue. Our apps also connect to private WiFi access point generated by a hardware device which only supports IPv4. Our customer sells the HW device for some time and it will become useless if the IPv4 cannot be used.


I would also like to ask for an answer from Apple.

Posted by
Petr Hoffman
Up vote reply of Petr Hoffman Down vote reply of Petr Hoffman
Add a Comment

We are facing exactly same issue.

Looking forword Dear eskimo's answer.

Posted by
Wenji
Up vote reply of Wenji Down vote reply of Wenji
Add a Comment

Note I use the term accessory here because we already use device to mean iOS device.

What does your accessory do if you attach it to an IPv6-only network? Does it support IPv4 link-local addressing? Does it include a DHCP server, and thus hand out IPv4 addresses itself? Or does it just fail?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

In our case, the accessory has a static IP address and includes WiFi AP and DHCP (only IPv4).

An iOS device connects to the AP, receives IP address from the DHCP and communicates with the accessory using harcoded IP address.


The connection is direct between the device and the accessory. There is no DNS. The accessory itself does not connect to any external network.


Is there any chance that this kind of communication will be supported after June 1 2016?

Posted by
Petr Hoffman
Up vote reply of Petr Hoffman Down vote reply of Petr Hoffman
Add a Comment

If you’re accessory has a DHCP server handing out IPv4 addresses then it’s impossible for the iOS device running your app to be both:

  • able to ‘see’ the accessory

  • on an IPv6-only network (because it will get an IPv4 address from your accessory)

Right?

The only gotcha here relates to multihoming. If the device was WWAN and the WWAN only supports IPv6, you’re in a situation where Wi-Fi is IPv4 and WWAN is IPv6. This should work but it’s hard to test.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

I also have an existing app that connects to an eternal "accessory". The accessory can be connected to via Access Point (specific IPv4 address) on a dedicated WiFi connection, or through the user's home wifi. When connecting via Access Point, the IP address is always the same IPv4 address. When connecting via the user's home wifi, the app must perform an IPv4 search (brute force look up) because the accessory does not support dynamic discovery. Thus the address is effectively hardcoded.


I set up the NAT64 environment, as outined in Apple's docs. I was able to successfully connect to the "accessory" using an IPv4 address using "NSStream.getStreamsToHostWithName(...)", where the hostname is something like "10.0.1.31". I assume NSStream is taking care of translating the IPv4 address to an IPv6 address.

Just curious if this fits the IPv6 requirement.

Posted by
bcprog
Up vote reply of bcprog Down vote reply of bcprog
Add a Comment

I set up the NAT64 environment, as outined in Apple's docs. I was able to successfully connect to the "accessory" using an IPv4 address using "NSStream.getStreamsToHostWithName(...)", where the hostname is something like "10.0.1.31". I assume NSStream is taking care of translating the IPv4 address to an IPv6 address.

I believe this is working due to the magic of IPv4 link-local addresses. When the iOS device joins a network without IPv4 infrastructure, it assigns itself an IPv4 link-local address per RFC 3927. The system treats that address specially. Specifically, if you have no other IPv4 address available, the system will treat all IPv4 addresses as if they were link local. That is, when you try to connect to 10.0.1.31 the system won’t try to communicate via a router (because there is no IPv4 router) but will instead simply ARP for that address. Your accessory responds to the ARP and away you go.

This is quite clever from a technical perspective but, really, you should put some investment into your accessory’s IP stack. Having a hard-wired IPv4 address is very poor form. The technology to make IP accessories completely bulletproof [1], you just have to use it.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"

[1] That is:

  • IPv4 link-local addressing per RFC 3927

  • IPv6, which supports link-local addressing out of the box

  • Multicast DNS, per RFC 6762

  • DNS Service Discovery, per RFC 6763

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment