Archives
 
 
 
  Special
 
 
 
  About Us
 
 
 

Newsletter
Free E-mail Newsletter from BYTE.com

 
    
           
Visit the home page Browse the four-year online archive Download platform-neutral CPU/FPU benchmarks Find information for advertisers, authors, vendors, subscribers Request free information on products written about or advertised in BYTE Submit a press release, or scan recent announcements Talk with BYTE's staff and readers about products and technologies

ArticlesCreate More IP Addresses


April 1995 / Core Technologies / Create More IP Addresses

The transition to a new IP address format doesn't have to be painful

Tim Winston

The explosive growth in demand for IP addresses has led to the development of a new IP address format called IPng (IP next generation). Eventually, all internetworking equipment will run the new format because of its expanded addressing capability and also because of other new features incorporated into IPng that simplify packet routing and handling.

The challenge for a corporate network manager is how and when to make the transition from their current IP (IP version 4) network to one based on IPng. Fortunately, there are several ways to make the migration.

Companies have the option of upgrading routers to start, or they can mix IP host and router upgrades. All the while, they have to maintain compatibility with existing IP internetworks that may have different migration strategies.

Why Change?

TCP/IP's growth has prompted the need for a new version of IP addressing. The Internet, the largest IP internetwork, is comprised of over 40,000 networks. This number has been doubling about every 12 months.

The most apparent threat is depletion of the 232 available IP 4 addresses that represent over 4 billion nodes. Although it seems like that's enough addresses to go around, there's a potential shortage because of the way addresses are assigned.

IP addresses are allocated in chunks per network, not by the individual device. The minimum allocation is 256 addresses. Yet, a network backbone may use only two of these (one for a router and one for a host computer). This hierarchical assignment is necessary for routing, but it reduces the practical number of available addresses.

A more pressing problem is that route rs, especially those on the Internet, are rapidly being overwhelmed. Backbone routers on the Internet must effectively keep a table of every network address. A router must use this table to look up the destination address of each packet it receives before it can forward the packet. Before it receives the next packet, the router must complete the entire process (address lookup and forwarding).

While new protocols for sharing route information and new hardware are in continual development, the growth of internetworks may outpace such developments. Thus, the potential shortage of IP addresses and the burden on routers require that a new version of IP be deployed within three to seven years.

The IETF (Internet Engineering Task Force) and the Internet community began looking at proposals for the IPng in early 1992. As the debate progressed, proposals merged and evolved until the IPng area directors made a recommendation in September 1994. The result is that IPng (technically, IP version 6) has severa l key features that distinguish it from IP 4:

-- IP 6 offers greatly expanded routing and addressing capabilities. IP 6 addresses are 128 bits, compared to 32-bit IP 4 addresses. While this obviously provides astronomically more addresses, it mainly supports more levels of addressing hierarchy to simplify routing.

-- IP 6 has simpler packet headers. IP 4 headers include options that are not necessary for routing, but routers must process them. IP 6 has a fixed-size header containing only information needed to route the packet. Options that only the final recipient needs are put in subheaders and don't have to be processed for the router to send the packet to the appropriate output port.

-- IP 6 lets you label packets for special handling, such as "real-time" service.

Other protocols, most notably OSI (Open Systems Interconnection), have solved some of these problems that face TCP/IP. But none had an adequate transition plan. For example, an OSI router can't support a computer running only TCP/IP. Before the transition to an OSI network is complete, all devices must be upgraded.

The IETF avoided this problem by ensuring a smooth transition from IP 4 to IP 6. The IETF's primary goal for its transition plan, called SIT (Simple Internet Transition), is that it be easy. If it is difficult, people won't do it, and IP 6 will fail.

One key element in meeting this goal is that incremental deployment is possible in a transition to IP 6 networks. Any router, computer, or other device can be upgraded without requiring anything else to be upgraded simultaneously (see the figure " IPng Handles Mixed Addressing "). This means that IP 6 support can be added in the regular maintenance cycle of each device.

Furthermore, devices do not need to be upgraded in any specific order. Routers can be upgraded at any time, regardless of the state of other routers or hosts (computers and other end nodes). The exception is that hosts need an upgraded DNS (Domain Name System) to resolve names for IP 6 devices. Existing IP addresses that are compatible with the new addressing structure also make the transition easier. IP 4 addresses map to IP 6 addresses.

If you've been allocated IP addresses, you can use them according to your plans while upgrading your routers and hosts to IP 6 software. By the time you run out of your allocation and can't get another IP 4 allocation, the software transition should be complete. Until then, you won't need an address deployment plan.

While IP 6 supports IP 4, it does not extend it. As IP 4 depletion nears, hosts will begin using addresses outside of the IP 4 "network." Any device that does not have its software upgraded (e.g., a device that is IP 4 only) will not be able to interoperate with these "IP 6-only" devices.

When devices are upgraded, the IP 4 "network" is divided into two parts, IP 4-only (all TCP/IP hosts), and IP 6/IP 4 (hosts that do both). The IP 4-only addresses ar e represented by their 32-bit address padded out to 128 bits with zeros. For example, 0:0:0:0:0:0:192.128.3.24 (numbers followed by colons represent 16 bits, 8 bits if followed by periods. And IP 6 addresses are represented by eight 16-bit numbers separated by colons). When an IP 6/IP 4 node sees this type of address, it knows it must use IP 4 to communicate.

Addresses for nodes that handle both IP versions look the same with one exception--the 16 bits preceding the IP 4 address. For example, the address would look something like 0:0:0:0:0:FFFF:192.128.3.24. This identifies the node to other IP 6 devices as an IP 6-capable node, but it also has a unique IP 4 address to interoperate with IP 4-only devices.

As the transition progresses, enough devices will be upgraded to IP 6 that it will become practical to assign addresses outside of the IP 4 "network." The addresses that use the higher order bits will not be inherently interoperable with IP 4-only nodes. However, any IP 6/IP 4 node will interop erate, even if it is assigned an IP 4-compatible address.

There has been discussion of a mechanism to map IP 6 addresses onto the IP 4 network. This would let a local network stay IP 4 only, yet interoperate with remote IP 6-only devices.

Implementation Strategies

Taking this level of compatibility designed into IP 6 and applying it to internetworking equipment is straightforward. For most companies, routers will almost certainly be the first devices to gain IP 6 capability. Routers use addresses, not names, so they are not dependent on any other IP 6 support. All existing router protocols work with IP 6, so common router-to-router links will probably be the first IP 6 networks (tunneling IP 4 across IP 6 networks).

Because computers and other end nodes need to resolve the mapping of names to IP 6 addresses to establish an IP 6 connection, DNSes need to be upgraded to support an additional record type. Thus, new records need to be added for each device as it becomes IP 6-capable.

One of the new features of IP 6 is support for auto-configuration (plug and play) and mobile devices. This will necessitate changes to make DNS dynamic so that roaming devices can update their location on the network based on their name. Authentication is a key part of mobile support. It allows a specific device to be positively identified before updating its network location.

Network management software will also need to support the (as-yet-undefined) MIB (Management Information Base) for IP 6. Support for monitoring authentication, auto-configured devices, and mobile devices will also have to be added.

Servers should have simultaneous support for IP 6 and IP 4. They will be used by devices with different transition schedules and priorities. Thus, they should be as accessible as possible, both locally and remotely (remember, a remote device may not be upgraded on the same schedule). Upgrading servers also can move heavy server-to-server traffic to IP 6, helping the routers and improving performance.

Desktops and other end nodes vary greatly in their use and priority of upgrade (and the availability of upgrades). General-purpose computers, such as PCs and workstations, will probably have dual-protocol support available about the same time as servers. IP 6/IP 4 capability is important to give them access to remote hosts and stay independent of each host's upgrade schedule.

As printers and terminals wear out, their replacements will probably support IP 6, but as long as the computers that use them are dual protocol, these devices may never have to be upgraded.

Rules to Live By

When faced with a transition from IP 4 to IP 6, the main thing to remember is don't panic. IP 4 will exist for a long time. The move to IP 6 will prolong the viability of IP 4 networks by freeing up addresses and increasing the efficiency of routers.

For the most part, network software upgrades will "automatically" add IP 6 capability as vendors add IP 6 su pport to their products to stay competitive. This will be part of the normal upgrade and maintenance procedures. And existing address assignments will work automatically.

Upgrades should be available before IP 4 addresses are depleted. By the time you need to deploy new addresses, auto-configuration, which is planned as part of IP 6, should be defined and available. Auto-configuration assigns addresses to devices as needed. It should also permit centralized address management.

As devices are upgraded to IP 6, simply add a new record to the DNS so that other upgraded devices will be able to use an IP 6 connection to reach them. Taking these steps and the backward compatibility of IP 6 into account, should allow a smooth transition from IP 4 to IP 6.


IPng Handles Mixed Addressing

illustration_link (42 Kbytes)

The flexibility designed into IPng ensures compa tibility even when there's a mix of current and new IP addressing formats. Here are just two examples of the types of mixed environments that can be supported.


Tim Winston has worked extensively in the design of large corporate networks. He is a development group manager at WRQ, a PC connectivity company with headquarters in Seattle, Washington. He can be reached on the Internet at timw@wrq.com or on BIX c/o "editors."

Up to the Core Technologies section contentsGo to previous article: The Software StopwatchSearchSend a comment on this articleSubscribe to BYTE or BYTE on CD-ROM  
Flexible C++
Matthew Wilson
My approach to software engineering is far more pragmatic than it is theoretical--and no language better exemplifies this than C++.

more...

BYTE Digest

BYTE Digest editors every month analyze and evaluate the best articles from Information Week, EE Times, Dr. Dobb's Journal, Network Computing, Sys Admin, and dozens of other CMP publications—bringing you critical news and information about wireless communication, computer security, software development, embedded systems, and more!

Find out more

BYTE.com Store

BYTE CD-ROM
NOW, on one CD-ROM, you can instantly access more than 8 years of BYTE.
 
The Best of BYTE Volume 1: Programming Languages
The Best of BYTE
Volume 1: Programming Languages
In this issue of Best of BYTE, we bring together some of the leading programming language designers and implementors...

Copyright © 2005 CMP Media LLC, Privacy Policy, Your California Privacy rights, Terms of Service
Site comments: webmaster@byte.com
SDMG Web Sites: BYTE.com, C/C++ Users Journal, Dr. Dobb's Journal, MSDN Magazine, New Architect, SD Expo, SD Magazine, Sys Admin, The Perl Journal, UnixReview.com, Windows Developer Network