Electronic Design

Support IPv6 Now Or Later?

Internet Protocol version 6 offers many benefits, but widespread adoption is a few years away.

IPv6 is coming! IPv6 is coming! Unfortunately, nobody is hanging lanterns in the church tower to tell our Paul Revere how or when Internet Protocol version 6 (IPv6) will arrive. Eventually, IPv6 will be pervasive, and it's up to embedded designers to prepare for it.

From a software developer's perspective, basic IPv6 support is relatively easy. Most applications interface to a TCP/IP protocol stack via a socket interface. IPv6 will have a different socket library, and a dual-stack implementation will contain both the IPv4 and IPv6 socket libraries.

Supporting both protocols will increase complexity and testing re-quirements, while providing a longer life and wider market for embedded network-based products. IPv6 will become more important as its use grows in applications such as intelligent mobile phones.

IPv6 is actually deployed throughout the world today. It's the native protocol of the Internet II project. IPv6 has been around for quite a while, starting with work on the Internet Protocol Next Generation (IPng) in 1994. This eventually became IPv6 (don't ask about IPv5). IPv6 was designed to address many of IPv4's shortcomings. Yet as Larry Larder, president of Interniche, said, "The IPv6 design is elegant, but from a business perspective, it may be its own worst enemy."

While IPv4 and IPv6 traffic can co-exist on one network, IPv6 requires additional support in applications, protocol stacks, and routers (see "IPv6 Basics," p. 48). These changes are relatively straightforward in software platforms, although they're obviously not free.

Unfortunately, most current routers include hardware acceleration for handling IPv4 and TCP/IP. Tom Hussey, product line manager for wireless Internet at Nortel Networks Limited, indicates that this process has occurred over the past five years. Further, John Bartas, CTO of Interniche, notes that "Companies that own these routers haven't been eager to dump their huge investments in IPv4 infrastructure and buy new hardware to handle IPv6. There's simply no payback in it for them."

Companies like Nortel and Cisco Systems are now shipping products that work with both IPv4 and IPv6. It will take at least another five years to upgrade or replace existing products. But the process has started. IPv6 is a checkbox item for most new enterprise purchases in the U.S. Although new products are IPv6 capable, the IPv6 support typically isn't enabled as no significant IPv6 traffic exists, at least not in the U.S.

Over There, Over There: IPv6 traffic is a different story in Asia, especially Japan, and Europe. This has to do with one of the main disadvantages of IPv4. Organizations in the U.S. were very influential in the creation of the Internet and its use of TCP/IP. Large IP address blocks were allocated. The distribution is rather odd to the point that some American companies and universities have more allocated IP address space than countries like China (see Table 1).

Unfortunately, reallocation isn't an option. The problem is similar to the shortage of telephone numbers in the U.S. in certain areas, resulting in overlapping area codes and 10-digit dialing. The answer to the IP problem is twofold.

The first approach uses network address translation (NAT), which also is employed on home broadband gateways. The gateway has one IP address and supports a local network with a set of IP addresses. Multiple gateways can use the same IP addresses for the local networks. The gateway translates packets so they appear to be working with the gateway while being forwarded to local workstations after translation. This effectively reduces the number of IP addresses needed to support a collection of workstations.

Internet service providers (ISPs) can implement NAT to handle many customers, preserving their limited supply of fixed, allocated addresses. ISPs also dynamically allocate addresses using DHCP (dynamic host control protocol) to further reduce the need for allocating fixed IP addresses to customers.

Unfortunately, this approach provides just a short-term fix that's fraught with problems. NAT doesn't work well with many protocols, including Voice over IP (VoIP) and virtual private networks (VPNs). Specialized gateways and proxy servers normally support these protocols, but there's a downside. They're costly and can be difficult to manage. Also, performance suffers.

The second approach to solving the IP address problem is IPv6. Not only is its 128-bit address space larger, but it's allocated in a different way (see Table 2). This is because country information is included in an IPv6 address. This has beneficial routing implications that will be discussed later. The IPv6 address space is largely unallocated, although it's partitioned with respect to location. The same kind of problem may arise in the distant future.

A number of ISPs all over have taken the first approach. With government support, the second technique is being applied in Asia and Europe. For example, Japan's ISPs receive a tax break for building IPv6-based networks.

Nations have other incentives for pushing IPv6. The U.S. has dominated the IPv4 arena. Although a relatively new technology, competition for IPv6 is still growing. Getting experience now will pay off later.

Increased cell phone use is another reason for heading toward IPv6. The need for IP addresses for computers is dwarfed by the necessity for embedded devices like cell phones. NAT can act as a stopgap, but the goal is a separate IP address for every cell phone.

Related to this unique address idea is Mobile IP and 3G wireless support. Mobile IP lets a device move from one service area to another while allowing contact with other devices. Mobile IP works with IPv4, but more native support for it exists within IPv6. Check out the Universal Mobile Telecommunications System (UMTS) Forum and the IETF Mobile IP Working Group for more details on 3G wireless systems.

IPv6 stacks may be found in cell phone environments. In most other areas, dual IPv4/IPv6 stacks will be used.

Applications Benefit From IPv6: Mobile IP and 3G cell phone systems can implement IPv6 for a variety of applications, including VoIP, streaming multimedia, and Internet access. VoIP in fixed locations can also benefit from IPv6 support.

VoIP is finding more uses within large organizations, but IPv4's lack of address space and the use of NAT have made these islands of communication. Calling within an organization works, yet calling outside typically means going through a private branch ex-change (PBX) and the standard phone system. It's not uncommon for a call to start as a VoIP call, then move through at least a pair of PBXs and back to a VoIP call, instead of communicating directly between a pair of VoIP nodes, which IPv6 makes possible.

IPv6 benefits VPNs with standard encryption and authentication support. A special extension header is defined for this purpose, making it easier for software and routers to handle.

Unfortunately, IPv6 application support isn't free. Simply adding an IPv6 stack isn't sufficient. New applications need to include IPv6 support, and legacy applications must be modified to tolerate IPv6. Most applications will have to be written to take advantage of a dual IPv4/IPv6 stack, complicating this technology even more.

IPv4 support enables applications to take advantage of the existing technology, including the Internet backbone. IPv6 support can improve performance and address problems in IPv4 networks.

Attacking Routing Table Overflow: IPv4 networks must contend with growing routing tables due to an increased number of nodes. Also, the IPv4 addresses don't contain location information like IPv6, so the routers must keep track of all links for traffic passing through.

Location information in IPv6 shrinks the routing table and reduces its growth because only location information needs to be saved to handle any packets heading in that direction. Performance also is enhanced as routing decisions can be made using part of the address even though the address is larger than with IPv4. Users of IPv6 can't fully take advantage of these features until there are completely native IPv6 transports. But ways exist to make IPv4 and IPv6 transport each other's packets.

Cloudy Day:Side-by-side support for IPv4 and IPv6 is possible, yet many routing environments stick to just one for efficiency and management reasons. So movement of IPv6-based information through an IPv4 network or cloud must be handled differently than the way native protocol routing methods allow.

Standards like IETF RFC-3056 IPv6 Connection of IPv6 Domains via IPv4 Clouds, and RFC-2529, Transmission of IPv6 over IPv4 Domains without Explicit Tunnels, enable IPv6 packets to traverse an IPv4 cloud (see the figure). In this case, a 6-to-4 router is located at both ends of a tunnel through an IPv4 network. A symmetrical relationship exists between the routers, and a connection through them generates a dynamic tunnel.

Similar standards are available for moving IPv4 over IPv6. This is less of a concern because IPv4 will probably find limited use once IPv6 becomes dominant. Meanwhile, the number and size of IPv6 clouds will continue to grow. IPv6 hardware is leaning toward this.

New IPv6 Hardware:Network processing units (NPUs) like Xelerated's X10 line lead the way for high-performance routers and switches. Available in single, dual, and quad 10-Gbit/s channel packages, the X10 handles Multiprotocol Label Switching, plus IPv6 and IPv4 processing at wire speeds. Its packet-driven architecture accomplishes IPv6's multicasting, forwarding, multifield classification for traffic conditioning, and extension-header parsing.

Xelerated isn't alone in its ability to tolerate IPv6. EzChip's NP-1 also handles IPv6 at 10-Gbit/s wire speeds without external CAMs or classifier engines. Novilit, creator of the AnyWhere network stack compiler, works with IPv6 as well. AnyWhere allows the creation of any type of network stack, including IPv6, and its output can be employed for NPUs, FPGAs, or software stacks that suit most operating systems.

The lanterns are on and embedded developers can no longer ignore IPv6. Supporting both IPv4 and IPv6 will be the norm for 10 years or more, a long time for many embedded systems. So expect to see dual stacks for quite a while.

Need More Information?
Cisco Systems Inc.
(408) 526-4000
www.cisco.com

EzChip Technologies Inc.
(408) 879-7355
www.exchip.com

Internet Engineering
Task Force

www.ietf.org

Interniche
(408) 257-8014
www.interniche.com

Interpeak AB
(650) 917-1882
www.interpeak.se

Nortel Networks Ltd.
(800) 4-NORTEL
www.nortelnetworks.com

Novilit Inc
(508) 485-0050
www.novilit.com

RFC-Editor
(800) 336-5236
www.rfc-editor.org

Universal Mobile
Telecommunications
System

(650) 210-1500
www.umts-forum.org

Xelerated
(781) 505-1921
www.xelerated.com


TAGS: Mobile
Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish