|
|
|
|
| IPv6 and its Position on the Technology
Acceptance Curve, a Historical and Personal Perspective
(This article is dedicated to the late Mr. Jack Kilby, inventor of the Integrated Circuit (IC), who made all of this possible.) This is the first in a series of articles on IP addressing issues and how they can affect IPv6 deployment. To understand where IPv6 technology and solutions are we need to review the history leading up to IPv6 and utilize a method to quantify, compare and contrast significant issues surrounding the technology. We will first take a look at the concept of the Technology Acceptance Curve (TAC) and how it applies to IPv6. We will then identify several of the technologies and issues leading up to IPv6 and its current state of deployment. In “Innovation, the Attacker’s Advantage,” Richard Foster explained the S-curve, a qualitative and quantitative method for tracking and analyzing change, performance and other factors. The S-curve has been used by technologists and system engineers to track both performance of systems and the locations of technologies on their life cycle curve, the Technology Acceptance Curve. This article will examine different computer related technologies, IPv6 and IPv4 and how they relate to each other and to the eventual success of IPv6. The S-curve is a forward-leaning lazy S that is in the first quadrant of a graph. (See figure 1.) The positive x-axis can be time or number of users and is usually a log scale, and the y-axis can be multiple variables such as percentage of systems performance, numbers of IP addresses or numbers of users of IP addresses. To explain how to interpret the S-curve let us review the installation and operation of a new multi-user mainframe or server. The use of the S-curve to look at performance issues is a straightforward graph that starts at zero and ends at 100% utilization. The use of the S-curve to look at Technology Acceptance is not as straight forward or as simple to interpret for a technology like IPv6.
In our example, at the start of the curve all the users are running on their current systems. Time = 0, number of users = 0, percentage utilization is 0 (i.e. on the graph x = 0, y = 0). As the system support engineers set up the system and install software the number of users begins to grow. X begins to increase as time progresses and y will go up with the number of users. As applications are available some users will try the new system and discover that the system is very fast since no one is currently utilizing the system. As additional users discover the system the graph of utilization edges up at a greater angle going toward the knee of the S-curve. Once general acceptance has occurred for the system, the knee of the S-curve has been passed and the graph shoots up at a sharp angle. At some point, the critical path elements of the system will be saturated and the angle of the graph will flatten back out asymptotically, approaching the upper practical limit of the system. For computer systems this was usually the processor running out of power, with too many simultaneous users on the system. At this point on the performance graph, the organization has purchased a bigger, better computer and the graph starts over again. Now let’s apply the S-curve to the IPv4 address structure and then to IPv6 and its addressing structure.
I would like to thank Alex and the entire IPv6 Summit group for allowing us to hear from the individual who, that fateful day a few years ago, turned off the old network addressing scheme and turned on IPv4 addresses. That was the beginning time and some initial number of users for IPv4 on the IPv4 TAC. During this period when I was at Georgia Tech it took a few more years before my mini computers and PCs were part of the IPv4 TAC since they were interconnected with proprietary networking protocols. To review the S-curve for IP addresses is really a composite curve for the computer and IC technology, computer and network architectures and the networking technology used to interconnect the systems. All of these factors affected how fast the S-curve grew and where the knee of the S-curve was. Figure 2. is a representative S-curve for IPv4. The actual number of addresses is more than the 4 billion because of NAT space. As a child of the sixties, when I started in digital hardware design, there were these new ICs in TO-10 packages, based on RTL / DTL (Resistor Transistor Logic / Diode Transistor Logic) that allowed you to design hardware with complete “AND” and “OR” logic gates as well as flip-flops. In the seventies, TTL (Transistor Transistor Logic) and CMOS were the computer design technologies of choice, which allowed greater performance and better integration of functions. Original mainframes were built with discrete transistors which meant they were large and very power hungry. The next generation of digital technology allowed minicomputers and newer generation of mainframes to use TTL logic circuits. In the mid seventies, AMD developed a bit slice processor that allowed all of the components for the CPU on a single board. Texas Instruments, Intel and Motorola originally introduced small bit sized single chip microprocessors with Large Scale Integration (LSI) logic. Then VLSI and ULSI chip technology came along, these allowed full microcomputers and all the peripheral functions on a single chip. This led to the modern PC, since you could compact all of the logic functions with peripherals in a small enclosure. Memory and mass storage technologies, based on the same LSI and VLSI circuits, followed the same curves of increasing densities at decreasing costs. Original networking technology started with page and character terminals being multiplexed and serially connected to mainframes. By the time I was at Georgia Tech, minicomputers allowed each lab at Georgia Tech to have its own standalone computers. Since early minicomputers did not have the math processing power of mainframes, connecting the minicomputers to each other and the mainframes became a priority. DEC (Digital Equipment Corporation) was one of the pioneers of both the minicomputer and peer-to-peer networking, with IBM the leader in mainframe networking. The DEC node number, which had to be unique for all machines in a DECnet network was 16 bits, so you could have 65,534 DEC machines as part of a single DECnet network. It was reported at the time in the late seventies and early eighties that there was a 16,000-node DECnet network that was operating with PDP-11s and Vaxes. Some numbers of these machines were dual-stacked to be able to handle both DECnet as well as TCP/IP. I had been at Georgia Tech since I was 16, working on all aspects of computers and networking, I finally graduated with a BS in Computer Science (after nine years) and went to work for Hayes Microcomputer Products, the modem folks. Going back to the IPv4 acceptance curve, we have moved on in time and the number of users has grown to hundreds and maybe thousands of computers that are using IP addressing. DARPA became ARPA and finally TCP/IP was no longer blue sky. NSF took over control of the ARPAnet to extend the technology to more schools and universities and to help expand its use. The Internet backbone was increased to T3 or 45 megabits per-second-speed and then to OC-3c. During my tenure at Hayes there were several factors that were coming together to move IPv4 along the IPv4 TAC and propel it around the knee in the bend of the S-curve and start up the curve at a very fast rate. At Georgia Tech, I had a number of different computer vendors I had to support and the only reliable networking was sneaker net with a nine-track tape. When I went to work for Hayes supporting its minicomputers, it was working on modems for these new beasts called Personal Computers. Modems are those devices needed to allow digital computers to communicate over analog phone lines. Having joined the Engineering Support group for Hayes, I had responsibility for voice and data communications, engineering computers and software. While I originally supported a standard DECnet network, we installed a new LAN technology called Ethernet in our technology center. And I was beginning to increase the number of devices connected by IP addresses from tens, to hundreds and thousands. In the Hayes Technology center we had a RG-9 “thick wire” Ethernet installation with vampire taps. Connected to this bridged segment were several DEC VAXes, Apollo and Daisy Workstations with original PCs and ATs. Originally on the Ethernet segment we were running both DECnet and DEC LAT traffic. DECnet traffic at this time was large file transfers with large packet sizes and the DEC LAT traffic was small packets with character oriented traffic that was very delay sensitive. In today’s terminology, it would be putting video distribution and VoIP traffic on the same link. To interconnect the heterogeneous environment we installed Wollongong TCP/IP stacks on our different computers. While all the Ethernet devices came with their own MAC address, I was now going to have to manage these new identifiers called IP addresses. I had a text file that contained all of my IP addresses. My first spreadsheet of addresses had to wait until they invented the spreadsheet application. Once we had all of the computers communicating on this one 10 Mbps Ethernet segment, we were beginning to get Ethernet packet collisions that were affecting data throughput. On the original Ethernet segment we were still running DECnet and LAT, TCP/IP and Apollo proprietary network software. We then installed a second Ethernet segment, making one of the VAXes a TCP/IP routing node so that small packet terminal traffic would run on one segment, and computer-to-computer file transfers would run on the other segment. To illustrate one of the cracks in my crystal ball, I was running routing software as a process on my VAX computers as well as all the other applications that were running. There was a company that was going to use a computer to only route traffic and I thought that this was a waste of a good computer. Cisco, of course, proved me wrong. After moving to Hayes, we developed low-cost modems for two companies. One was a startup in California called Apple Computer, and the other was a stealth project out of Boca Raton, Florida, from a company called IBM. This meant that Hayes went from producing several hundred modems a month to producing over 50,000 modems a month. Modems speeds increased from 300 bps to dial up 56 Kbps with greater data throughput when you added compression technology. Then in the early eighties, with the breakup of AT&T, the number of orders for fully digital Central Office (CO) phone switches went through the roof. As part of the Advanced Technology Group at Hayes, we started a project on Integrated Services Digital Networks (ISDN) to allow computers to connect to other computers over the digital phone lines that would become available. Since going digital end to end would remove the need for analog modems for PCs this initiative was considered a strategic move by Hayes and started an S-curve for ISDN technology. The S-curve for modems had several more years to go, but Hayes did not perceive the threat to modems was from LANs, not ISDN. There is an interesting analogy between the rollout of ISDN services and the rollout of IPv6. ISDN required digital end devices, digital switches and digital long distance facilities. The digital switches came first with the ability to handle both analog and digital end devices. The critical path for ISDN was the analog long distance facilities that required bit robbing to maintain synchronization and could only assure 56 Kbps of data not 64 Kbps. When all digital facilities became available, you could order and maintain end-to-end digital connectivity. So for a number of years metro areas had ISDN service from wire serving central offices but they could not connect across the country. Also, with the breakup of AT&T, MCI and other companies began looking at microwave and then fiber optic equipment for high speed all digital communications. There are islands of IPv6 networks that will be interconnected by IPv4 networks for the foreseeable future, the same as ISDN islands were interconnected by analog trunks for years. While Hayes was able to successfully handle the consumer end of the Internet the CO side had to wait for a group of Hayes alumni to start their next company in California, called Ascend Communications. When Rob, Jeanette, Jay and Steve left Hayes to start Ascend Communications, they were prohibited from doing a PC-based terminal adapter either in card or standalone format. Rob Ryan had been in on the development of Ethernet and Jay was developing the Hayes ISDN Terminal Adaptor in California. Ascend put modems, ISDN and Ethernet together in a seminal box called the TNT. The TNT was finally the CO equivalent of the Hayes modem and allowed hundreds to thousands of users to dial up computer networks at one time. To be able to ship packets over point-to-point links a new protocol PPP or Point to Point Protocol was developed. They also developed a multi-link protocol to allow bonding of different B channels to allow up to a T1 (1.544 Mbps) of bandwidth on a single “dial up” connection. In these times of burgeoning IP addresses, DHCP and DNS were developed. Dynamic Host Configuration Protocol was needed because nobody can manually address millions of PCs which may change addresses several times a day. Dynamic Name System was developed — since the original text files we used to name all of the computers on the network did not work any more with hundreds of thousands of computers, a name resolution system had to be developed. DNS is used to map human readable names to machine readable IP addresses. While Hayes lost market share to the modem clones, Ascend became the new Internet infrastructure provider of choice and was finally sold to Lucent Technologies for $1.5 billion. From the early to mid-nineties, the position on the IPv4 curve shot around the knee and began ascending at several million new Internet users to tens of millions of Internet users per year. By projecting those curves, the IETF saw two ways to handle the growing Internet. There was the “Flat Earth Society” that thought it was a passing fad. IETF charted two paths at the time, one to patch IPv4 until IPng was available and the next was to push IPng so that it would be available before the IPv4 S-curve totally maxed out. Network Address Translation (NAT) was developed as the interim patch for IPv4, since a number of computers were connected to company Internets and they did not need their own globally routable IP space NAT fit the bill. IPng was renamed IPv6 and would be the next generation IP addressing structure. Now that our journey is almost complete for this article, we can examine the IPv4 S-curve versus the IPv6 S-curve.
The first obvious different is the relative scale of the two curves. The IPv6 graph would be for 128 bits of addresses while the IPv4 is only for 32 bits of addresses. In Figure 3 the IPv6 S-curve is only the beginning since the range of addresses is so large. The quantitative method for IPv4 or IPv6 S-curves does not show IP address churn. The redistribution of already used IPv4 addresses would not increment the y-axis. . Spending time and effort for QoS and MPLS support only for IPv4 would not be prudent with the markets current position on the IPv4 TAC. Any changes to IPv4 today need to also address IPv6 issues. IPv6 Issues 1. Device ability to handle IPv6 addresses and protocols —With the continued dropping of line spacing and sizes on ICs to 90 nm, the number of devices on an IC continues to grow and allow sufficient processing power for the manipulation of IPv6 addresses and protocols. 2. IP Address Management — Two years ago it took my engineers two hours to two days to allocate globally routable IPv4 space. Currently, one of my clients allocates NAT space in ten minutes. If an organization gets a /48 or more number of addresses it will take years to allocate them. Requirements for computer assisted IP address allocation will be addressed in one of my next articles. This application also has to drive DHCP and DNS configuration. Duplicate address detection needs to be avoided by not allocating duplicate address space. 3. IPv6 Transition Methods — There are a number of IPv6 transition techniques. I would suggest that there are too many. Using these techniques, existing equipment and applications can be used for their useful life cycle and can be replaced with lower cost, more powerful equipment that can support IPv6. Conclusion With the number of new communication devices coming onto the market and with each of us having several different IP addresses attached to those devices, the requirement for IPv6 will be getting stronger. Internationally, both Europe and Asia had more pressing business reasons to jump on the IPv6 curve earlier, and they will gain the competitive advantage of being farther down the curve than the US is. There is no doubt that we are at the top right of the IPv4 S-curve today,
and it is just a matter of time before we need to switch to the IPv6 S-curve.
I would hypothesize that we are going to reach the lower knee of the IPv6
curve in the next two years and began to shoot up after that. Bio – John L Lee has been involved with computers for all of his life. He started
his professional career at Georgia Tech. as an electronics technician,
designing and wire wrapping printed circuit boards, and has worked on
all aspects of computer hardware, architectures, software, firmware and
networking, ending up as the Director of Network Engineering for a Fortune
500 company. John is a subject matter expert in narrowband and broadband
ISDN. John is currently the SVP of Business Development for Internet Associates,
LLC. a developer of IP Address Life Cycle Management software. John can
be reached at john@internetassociatesllc.com;
the company is at |
|
|
