Notes from Your App and Next Generation Networks session

Two parts to session:


  • Transitioning to IPv6-only networks
  • Reducing Delays in Networking



Transitioning to IPv6-only networks



More mobile carriers are moving to IPv6 networks


In Ye Olde Days, cellular data networks used IPv4. As IPv4 addresses ran out, NAT was introduced to make IPs go further.

To fix the long-term problem, mobile carriers are now moving to IPv6. But they're also having to support IPv4 with NAT.


The carriers want to drop IPv4 with NAT, so they're deploying DNS64/NAT64 to handle translation between IPv4 and IPv6 networks.


  • DNS64 synthesizes an IPv6 address for an IPv4-only server
  • NAT64 performs IPv6 to IPv4 address translation



App Store apps need to be IPv6 ready - It will be an app submission requirement later in 2015.



Enabling IPv6 test network from a Mac


1. Boot OS X 10.11

2. Open System Preferences

3. Option-click on the Sharing preference pane

4. Option-click on Internet Sharing

5. A Create IPv6 Only Network checkbox will appear

6. Check Create IPv6 Only Network (this may also be labeled Create NAT64 Network)

7. Select the interface to share out over (usually this will be WiFi, to allow iOS devices to connect.)

8. Check the box to start internet sharing





By enabling Create IPv6 Only Network, Internet Sharing will set up the following:


DNS64

NAT64


Use the NAT64 Network for app testing.


Make NAT64 testing part of your regular development process.



What breaks?


  • IPv4-only storage objects
  • IPv4-only APIs
  • IPv4-only usage of an API



Pre-Flight checks before connecting


- Checking to see if a device has an IPv4 address

- Checking to see if a device has a 0.0.0.0 address



Address-family agnostic code


Connect without preflight

- If connection succeeds, great

- If connection doesn't succeed, handle the failure gracefully



Use higher-level networking frameworks

- NSURLSession and CFNetwork-layer APIs


RFC 4038 "Application Aspects of IPv6 Transition"

Connect-by-name APIs - Use DNS hostnames wherever possible instead of IP addresses.


IPv4 literals in NAT64+DNS64 networks


New for 10.11 and iOS 9


Use higher-level networking frameworks

- NSURLSession and CFNetwork-layer APIs



Client supplies IPv4 address Literal

- OS synthesizes IPv6 address





Reducing Delays in Networking


Industry has put resources behind increasing throughput, but not into other areas that cause network delays.


  • Reliable Network Fallback
  • Explicit Congestion Notification
  • TCP_NOTSENT_LOWAT
  • TCP Fast Open



Reliable Network Fallback



Device is on the fringes of a WiFi connection

TCP connection to WiFi network is not succeeding

OS initiates parallel connection over mobile data

First to complete wins - like RFC 6555 (Happy Eyeballs)


Ideally, the user won't notice anything odd. Applies only to apps allowed to use cellular data.


Fully automatic process - user not involved

No more bill shock for cellular data

Use NSURLSession and CFNetwork-layer APIs


For best user experience

- Better Route Notification





Explicit Congestion Notification:


Reduce network delays


tcptrace - www. tcptrace. org - presenter's recommended utility for packet inspection


Watch video for tcptrace experiment detecting and displaying network congestion with regards to streaming video, along with results.



Smart Queuing and ECN


CoDel

- Controlled Delay queuing

- Limits Bufferbloat



Explicit Congestion Notification

- Signals congestion by marking packets instead of discarding

- Available in iOS, OS X, Windows, Linux, etc.


See video for conclusions.



TCP for Streaming Video


Packet loss causes irregular data delivery to client

No problem for file transfer (e.g. sending an email) because what part of the data gets there first and last don't matter; gets assembled into the whole.

Big problem for streaming video over TCP - you don't want the data for the video's end appearing before the video's beginning.



Current state of ECN


Clients


- Routers aren't doing marking

- Some routers may drop the packets - small risk; no reward


For server-side info, see video; went by fast.


  • ECN now enabled by default for all TCP connections in iOS 9 and 10.11
  • Test on your own home and work networks
  • Report bugs to Apple
  • ISPs will be incentivized to start offering ECN service.
  • All apps get this for free





TCP_NOTSENT_LOWAT


Reduce sender-side delay

Don't over-stuff


See video for details, easier to show than explain.



  • Screen Sharing now using this in 10.10.3 and later; reduces Screen Sharing delays overall.
  • Used by AirPlay
  • Available in Linux too, for your server software



Obvious benefit for "real time" applications

- But all applications benefit


Use the NSURLSession and CFNetwork-layer APIs

When runloop reports socket is writable

- Write a single segment atomic chunk

- Don't loop until EWOULDBLOCK



TCP Fast Open



Accelerates the TCP handshake


Traditionally, TCP sends a handshake, then gets back data


TCP Fast Open combines handshake and data transmission in one step


TCP Fast Open only for idempotent data; restricting to idempotent avoids problems with duplicate packets causing a server to perform an operation multiple times.



Server-side


Must support TFO and application has to opt-in

iOS/OSX: Socket-option TCP-FastOpen



See video for all the details.

Replies

Hi;

Enabling IPv6 test network from a Mac

I dont see the option in the current 10.11 seed:

6. Check Create IPv6 Only Network (this may also be labeled Create NAT64 Network)


When it will be available ? Or do I need to do any other settings to see the option ?


Thanks


-- Inca

Hi,


Thanks for posting your query!

The option should be visible in the current seed.

Make sure option key is pressed when clicking on Sharing and InternetSharing.


Having said that, there's an issue with the feature that will be fixed in next seed.


There's a workaround though!

For the current seed, the work-around is to create directory /usr/local/etc/unbound

sudo mkdir -p /usr/local/etc/unbound

After that one can create NAT64/DNS64 by navigating through Apple Menu > System Preferences... > :


1. Option click on Sharing


2. Option click on Internet Sharing


3. Check "Create IPv6 Only Network" (this would be renamed to "Create NAT64 Network" in later seeds).


4. Select "Share your connection from" interface (on which you have internet connectivity) and "To computers using" interfaces (which will host IPv6 only access network with NAT64/DNS64).

Note: If you are choosing WiFi interface to host NAT64 network, make sure that you have set Wi-Fi options to ensure a secure Wi-Fi network


5. Check Internet Sharing and start sharing your network.


When you are testing your application on the client device for IPv6, make sure NAT64 network is the only network your client device is connected to.

For example if you are testing an applications installed on an iPhone, make sure you are connected over WiFi to NAT64 network hosted by the Mac and ensure that cellular data is disabled on your iPhone.

Have a great day!

The workaround doesn't work for me, devices can't connect successfully, they get a self assigned IPv4 address only still.... Undound process does run, and unbound.pid is present in /usr/local/etc/unbound ... Something more is missing...

Hi Tlmi,


When you are connecting your iOS devices to this network, from Settings > WiFi >, information about the network right now does not display assigned IPv6 addresses to the iOS devices. You will get an self assigned IPv4 but the IPv6 address will also be assigned (they just won't show up in wifi network info on iOS devices).


However the device should have network connectivity. In case you do not have networking connectivity (can't browse internet etc) on your client device, please file a bug report with Apple and we'll work with you to have it resolved.


https://developer.apple.com/bug-reporting/


Thanks!

Mac: OSX 10.11, both wired and wifi

iPhone: iOS 9.0 (I think beta 2 - downloaded/installed 7/7/2015)


Followed the directions for setting this up. All went flawlessly. The iPhone is connected wifi to the created shared wifi connection, hosted on the iMac. I've confirmed there is an IPv6 connection in existence using a 3rd party app (HE Network Tools). The iMac is still able to open websites, ping, etc. using IPv4.


BUT the iPhone has no network connectivity. It's like the translation in OSX isn't happening from IPv6 to IPv4.


How do I troubleshoot this?


Thanks.

I'm having this same issue...


Macbook Pro: OS X 10.11 with wired (Thunderbolt/Ethernet adapter) and wifi

iPhone 6+: iOS 8.4


Internet Sharing set up with 'Create IPv6 Only Network' checked, sharing connection from Thunderbolt Ethernet to computers using Wi-Fi (with security).


If I re-create Internet Sharing with the same options except with 'Create IPv6 Only Network' unchecked, it works. So, the 'IPv6 Only Network' seems to be the issue. I really need to test my app's capability to run on IPv6 networks, so this is a blocker.


Thanks!

Update: I thought I was on the latest Beta, but apparently not. After install of Beta 3 all is good!

I had upgraded to beta 3, and one machine can work another one cannot. The problem for me is the connected device cannot get the ipv6 address. Any idea on how to trouble shooting why the DHCP/DNS service cannot work?

Today I tried to manually configure IPv6 address and it works perfectly for DNS64 and NAT64, but still cannot automatically get the IPv6 address. I tried to send Router Solicitation with "sudo rtsold -f1 ppp0" and then capture the wireshark dump, I cannot get Router Advertisement from the Capitan. Anyone know which daemon on the MAC responding to send out RA?

update, I checked rtadvd, it is running and tcpdump showing Capitian is sending out RA through bridge100, but I cannot capture that packet in client side. Both firewall has been turned off, very strange.

Another update, after I disable wifi authentication, it can get the IP address! so confused...

Same for me. NAT64 Network Internet sharing only works when I set Security to "None" in Wi-fi options.