How a Machine-to-Machine World is Shaping the Future of the Internet

The increased use of computing and communication technology has led to global growth of the Internet. Mobile equipment, home appliances and other consumer devices are finding their way online and are becoming interconnected. In a “machine-to-machine” Internet, each of these devices will need an IP address.

This presents a problem. In February 2011, the last of the 4.3 billion IPv4 (Internet Protocol, Version 4) addresses were allocated. To provide a virtually limitless address space, a new protocol, IPv6, has been introduced. IPv6 will help enable capabilities such as push applications, peer-to-peer based applications and Cloud Computing over the Internet. If your company hasn’t already, it needs to prepare for IPv6 because unfortunately, IPv4 and IPv6 are incompatible.

The transition to IPv6 will not happen overnight. Every networked device, every software application and every interface with customers, suppliers and other key stakeholders must be examined and tested to verify that it is compatible with IPv6. The impact of IPv6 will vary from one organization to another, and there will be important differences among functions and operations even within the same enterprise. Now is the time for every enterprise to understand how it, its customers, suppliers and other business partners will be affected by the move from IPv4 to IPv6 – and start planning the transition.

In the first Q&A of a series, Dennis Oniki, Lead Marketing Manager, VPN Solutions at AT&T, answers questions about the transition from IPv4 to IPv6.

Q: When customers choose to move to IPv6 and they own IPv4 addresses – has there been any de facto industry agreement to give customers some financial credit for making the move to IPv6? Or will they have to pay for IPv6 addresses? What happens to their IPv4 addresses?

Oniki: There are no industry agreements whereby customers are compensated for migrating to IPv6. If allocated by AT&T, there is no cost to the customer to obtain IPv6 addresses. If the customer migrates to “Pure IPv6” and their IPv4 addresses were allocated by AT&T, the IPv4 addresses would be returned to AT&T.

Q: We have IPv4 block assigned from AT&T. Will we keep assigned block from AT&T?

Oniki: Yes, you may keep the assigned block as part of your contracted services. Similarly, if you sign up for dual-stack MIS, you would receive v6 addresses.

Q: How will the new IPV6 addresses be distributed to the users? It must be assumed that we cannot just pick our own addresses.

Oniki: You must first acquire address space for your network, either directly from an Internet registry or from your service provider. Then you’ll create an addressing plan for each site. Lastly you’ll decide on a strategy to assign addresses from this block to individual workstations, for example, via DHCPv6.

Q: Are the applications that customers may have—filtering, firewall, etc., going to have to be replaced?

Oniki: Hopefully not replaced, but perhaps updated. Any application that has a “field” to represent an IP address will need to be modified to handle the change from a 32-bit field—likely an Integer—to a 128-bit field. Devices such as firewalls, load balancers, etc. will likely require a software upgrade from the manufacturer.

Q: What are the key challenges with application migration?

Oniki: The two primary challenges were:

  1. inventorying the application’s space to identify those impacted by the transition to v6 and
  2. creating/testing the associated minimum standards that each impacted application will need to use for upgrade.

The inventorying effort was significant in size and scope and impacted multiple organizations. Coordination of that effort as well as the associated upgrade roadmaps for those impacted required careful coordination. Additionally, steps should be taken in software and applications design/architecture to ensure usage of Fully Qualified Domain Names (FQDN), removal of IPv4 literals, and adjustment of field sizes when IP capture and storage is needed to an appropriate size to handle the larger v6 address.

Q: What are the major pitfalls expected during the migration?

Oniki: With any new technology, it must be carefully planned out and tested prior to full-scale deployment. Our experience has shown that just because a manufacturer claims its device is IPv6 capable does not mean it will work as expected. Also, default values and behavior can vary between releases or Operating Systems as IPv6 matures. Network management should remain IPv4 based initially until you can migrate all tools, monitoring systems, etc to IPv6. Migrating to Dual Stack will give you time to migrate applications, as IPv4 to IPv6 interworking will be initially challenging across the enterprise. While NAT [network address translation] or Proxy devices may become available, centralized translation devices will increase latency and create single points of failure. They can also make troubleshooting more difficult as end-to-end visibility disappears.

Q: Do you have basis phases and the timing of those phases based on AT&T’s requirements?

Oniki: Timing of these phases is likely based on your own individual requirements and investment plan.   But roughly:

  • Phase 1: Dual Stack Internet presence – 2011
  • Phase 2: Extending v6 reachabilty into WAN – 2011/2012
  • Phase 3: Dual Stack WAN – 2012/2013
  • Phase 4: Application Migration to IPv6 – 2013-2016
  • Phase 5: IPv6 ONLY – 2014-2020

Q: Is Phase 5 where IPv6 exists end-to-end and no IPv4 addresses are used?

Oniki: Yes, this would be the goal, at least internally. You’d likely still need reachability to IPv4 Internet endpoints that could remain in existence for a long time. This will likely be done via IPv6 to IPv4 NAT function that could reside at your DMZ [demilitarized zone] or provided for you as part of your service. We are investigating network based NAT functions like this for the future.

Q: What’s the motivation for us to change to IPv6 on the WAN since those are all private addresses anyway?

Oniki: This will be based on your individual requirements but the motivation to jump to “Phase 3” of migrating your internal WAN will likely be application driven.

  • If you are integrating mobility into a Unified Communications strategy, than you’ll likely have many endpoints migrating to IPv6—such as LTE devices.
  • If you want to integrate Cloud Computing offers with your Data Center architecture, you might need to support IPv6 in the future.
  • If you want to support any push-down apps or peer-to-peer applications across partner/supplier relationships, they may not work through NAT and you’d need IPv6.
  • If you deploy any sensor networks internally—say tracking pallets with RFID tags—you may need IPv6 to support the great expansion of devices.
  • If you manage vending machines and they report back when they need to be refilled, you’ll likely need IPv6.
  • Lastly, if you are in an organization often involved in mergers or acquisitions, you might be motivated to move to IPv6 to avoid NAT overlap issues.

Your marketing or manufacturing teams may create revenue-generating opportunities that take advantage of machine-to-machine communications that will likely not work through NAT where the origination of the session is a machine on a mobile network.

Q: Will IPv4 become retired completely at some point?

Oniki: We hope so, but this could take decades. We imagine some clients may choose to keep their Internal WANs on IPv4 for a long time if they don’t see an application driving them to IPv6 internally.

Dennis Oniki VPN Solutions Lead Marketing Manager AT&T About Dennis