IPv4 Address Depletion

For decades, the world has known that IPv4 addresses would eventually be depleted. Technologies such as Classless Inter-Domain Routing (CIDR) and network address translation (NAT) helped delay the inevitable. However, on January 31, 2011, the top-level pool of Internet Assigned Numbers Authority (IANA) IPv4 addresses was officially exhausted. The American Registry for Internet Numbers (ARIN) is projected to run out of IPv4 addresses in the summer of 2015—a countdown is available here.

IPv6 More Efficient than IPv4

Aside from solving for the IPv4 depletion problem, IPv6 is more efficient than IPv4. For example, IPv6:

• Avoids the need for network address translation (NAT)

• Provides faster routing through the network by using simplified headers

• Prevents network fragmentation

• Avoids broadcasting for neighbor address resolution

4G Deployment

The fourth generation of mobile telecommunication technology (4G) is based on packet switching only. Due to the limited supply of IPv4 addresses, IPv6 support is required in order for 4G deployment to be scalable.

Multimedia Service Compatibility

IP Multimedia Core Network Subsystem (IMS) allows services such as multimedia SMS messaging and Voice over LTE (VoLTE) to be delivered over IP. The IMS used by some service providers is compatible with IPv6 only.

Cost

Service providers incur additional operational and administrative costs by continuing to support the legacy IPv4 network while the industry continues migrating to IPv6.

Use High-Level Networking Frameworks

Apps requiring networking can be built upon high-level networking frameworks or low-level POSIX socket APIs. In most cases, the high-level frameworks are sufficient. They are capable, easy to use, and less prone to common pitfalls than the low-level APIs.

• WebKit. This framework provides a set of classes for displaying web content in windows, and implements browser features such as following links, managing a back-forward list, and managing a history of pages recently visited. WebKit simplifies the complicated process of loading webpages—that is, asynchronously requesting web content from an HTTP server where the response may arrive incrementally, in random order, or partially due to network errors. For more information, see WebKit Framework Reference.

• Cocoa URL loading system. This system is the easiest way to send and receive data over the network without providing an explicit IP address. Data is sent and received using one of several classes—such as NSURLSession, NSURLRequest, and NSURLConnection—that work with NSURL objects. NSURL objects let your app manipulate URLs and the resources they reference. Create an NSURL object by calling the initWithString: method and passing it a URL specifier. Call the checkResourceIsReachableAndReturnError: method of the NSURL class to check the reachability of a host. For more information, see URL Loading System Programming Guide.

• CFNetwork. This Core Services framework provides a library of abstractions for network protocols, which makes it easy to perform a variety of network tasks such as working with BSD sockets, resolving DNS hosts, and working with HTTP/HTTPS. To target a host without an explicit IP address, call the CFHostCreateWithName method. To open a pair of TCP sockets to the host, call the CFStreamCreatePairWithSocketToCFHost method. For more information, see CFNetwork Concepts in CFNetwork Programming Guide.

If you do require the low-level socket APIs, follow the guidelines in RFC4038: Application Aspects of IPv6 Transition.

Don’t Use IP Address Literals

Make sure you aren’t passing IPv4 address literals in dot notation to APIs such as getaddrinfo and SCNetworkReachabilityCreateWithName. Instead, use high-level network frameworks and address-agnostic versions of APIs, such as getaddrinfo and getnameinfo, and pass them hostnames or fully qualified domain names (FQDNs). See getaddrinfo(3) Mac OS X Developer Tools Manual Page and getnameinfo(3) Mac OS X Developer Tools Manual Page.

Connect Without Preflight

The Reachability APIs (see SCNetworkReachability Reference) are intended for diagnostic purposes after identifying a connectivity issue. Many apps incorrectly use these APIs to proactively check for an Internet connection by calling the SCNetworkReachabilityCreateWithAddress method and passing it an IPv4 address of 0.0.0.0, which indicates that there is a router on the network. However, the presence of a router doesn’t guarantee that an Internet connection exists. In general, avoid preflighting network reachability. Just try to make a connection and gracefully handle failures. If you must check for network availability, avoid calling the SCNetworkReachabilityCreateWithAddress method. Call the SCNetworkReachabilityCreateWithName method and pass it a hostname instead.

Some apps also pass the SCNetworkReachabilityCreateWithAddress method an IPv4 address of 169.254.0.0, a self-assigned link-local address, to check for an active Wi-Fi connection. To check for Wi-Fi or cellular connectivity, look for the network reachability flag kSCNetworkReachabilityFlagsIsWWAN instead.

Use Appropriately Sized Storage Containers

Use address storage containers, such as sockaddr_storage, that are large enough to store IPv6 addresses.

Check Source Code for IPv6 DNS64/NAT64 Incompatibilities

Check for and eliminate IPv4-specific APIs, such as:

• inet_addr()

• inet_aton()

• inet_lnaof()

• inet_makeaddr()

• inet_netof()

• inet_network()

• inet_ntoa()

• inet_ntoa_r()

• bindresvport()

• getipv4sourcefilter()

• setipv4sourcefilter()

If your code handles IPv4 types, make sure the IPv6 equivalents are handled too.

Use System APIs to Synthesize IPv6 Addresses

If your app needs to connect to an IPv4-only server without a DNS hostname, use getaddrinfo to resolve the IPv4 address literal. If the current network interface doesn’t support IPv4, but supports IPv6, NAT64, and DNS64, performing this task will result in a synthesized IPv6 address.

Listing 10-1 shows how to resolve an IPv4 literal using getaddrinfo. Assuming you have an IPv4 address stored in memory as four bytes (such as {192, 0, 2, 1}), this example code converts it to a string (such as "192.0.2.1"), uses getaddrinfo to synthesize an IPv6 address (such as a struct sockaddr_in6 containing the IPv6 address "64:ff9b::192.0.2.1") and tries to connect to that IPv6 address.

Listing 10-1  Using getaddrinfo to resolve an IPv4 address literal

#include <sys/socket.h>

#include <netdb.h>

#include <arpa/inet.h>

#include <err.h>

    uint8_t ipv4[4] = {192, 0, 2, 1};

    struct addrinfo hints, *res, *res0;

    int error, s;

    const char *cause = NULL;

    char ipv4_str_buf[INET_ADDRSTRLEN] = { 0 };

    const char *ipv4_str = inet_ntop(AF_INET, &ipv4, ipv4_str_buf, sizeof(ipv4_str_buf));

    memset(&hints, 0, sizeof(hints));

    hints.ai_family = PF_UNSPEC;

    hints.ai_socktype = SOCK_STREAM;

    hints.ai_flags = AI_DEFAULT;

    error = getaddrinfo(ipv4_str, "http", &hints, &res0);

    if (error) {

        errx(1, "%s", gai_strerror(error));

        /*NOTREACHED*/

    }

    s = -1;

    for (res = res0; res; res = res->ai_next) {

        s = socket(res->ai_family, res->ai_socktype,

                   res->ai_protocol);

        if (s < 0) {

            cause = "socket";

            continue;

        }

        if (connect(s, res->ai_addr, res->ai_addrlen) < 0) {

            cause = "connect";

            close(s);

            s = -1;

            continue;

        }

        break;  /* okay we got one */

    }

    if (s < 0) {

        err(1, "%s", cause);

        /*NOTREACHED*/

    }

    freeaddrinfo(res0);

Test for IPv6 DNS64/NAT64 Compatibility Regularly

The easiest way to test your app for IPv6 DNS64/NAT64 compatibility—which is the type of network most cellular carriers are deploying—is to set up a local IPv6 DNS64/NAT64 network with your Mac. You can then connect to this network from your other devices for testing purposes. See Figure 10-6.

To set up a local IPv6 Wi-Fi network using your Mac

1. Make sure your Mac is connected to the Internet, but not through Wi-Fi.

2. Launch System Preferences from your Dock, LaunchPad, or the Apple menu.

3. Press the Option key and click Sharing. Don’t release the Option key yet.

   

4. Select Internet Sharing in the list of sharing services.

   

5. Release the Option key.

6. Select the Create NAT64 Network checkbox.

   

7. Choose the network interface that provides your Internet connection, such as Thunderbolt Ethernet.

   

8. Select the Wi-Fi checkbox.

   

9. Click Wi-Fi Options, and configure the network name and security options for your network.

   

   

10. Select the Internet Sharing checkbox to enable your local network.

    

11. When prompted to confirm you want to begin sharing, click Start.

    

Once sharing is active, you should see a green status light and a label that says Internet Sharing: On. In the Wi-Fi menu, you will also see a small, faint arrow pointing up, indicating that Internet Sharing is enabled. You now have an IPv6 NAT64 network and can connect to it from other devices in order to test your app.