TMCnet News
The Impact Of Migration From IPv4 To IPv6 By TMCnet Special Guest Migration from IPv4 to IPv6 is not progressing as was expected. In 1995, the Internet Engineering Task Force (IETF) started considering IPv61. In 1999, at a SIGCOMM99 conference, Sandy Fraser seriously questioned the IETF as to why IPv4 to IPv6 had not occurred. No one knows when the migration is going to be complete2. The U.S. government has mandated that all federal departments have IPv6 deployed on the backbone by June 20083. It is now 2007, and only a small percentage of U.S. companies have started the migration from IPv4 to IPv6.
It is possible but not probable that the U.S. government's migration from IPv4 to IPv6 might stir the private sector into at least the planning stage. It can be argued that much distrust in IPv6 can be pointed at poor early stage testing of IPv64. Classless Inter-domain Routing (CIDR) and Network Address Translation (NAT) have put off what the inevitable by providing a method to create IP
 addresses within a Local Area Network (LAN)5. There are many vendors with various ways and means of implementation of IPv66. Tian & Li (p. 211) write, "Providing graceful transition from IPv4 to IPv6 is crucial for the success of IPv6. During the transition period, it would be essential to maintain compatibility with the existing installed base of IPv4 hosts and routers. Because it is very difficult to predict how long the transition would take, it would be safe to assume that such compatibility would be needed for a very long time."
It appears that the prediction is holding up and may continue for a long period.
Network managers are going to have to maintain a dual TCP/IP stack to handle both IP protocols. This means there will be some tools that work only on IPv4 only, some tools that work on both IPv4 and IPv6, and some tools that work only on IPv6. With Simple Network Management Protocol operating in a dual stack, IPv4 MIB's have to be collected on the IPv4 side of the stack and IPv6 MIB’s have to be collected on the other side of the stack. IPv6 MIB’s can transport over IPv4.
Some of the manufacturers support SNMP over IPv6. Cisco IOS versions that can perform this task are 12.0 (27)S, 12.3(14)T, 12.4, and 12.4T. Juniper and Hitachi (News - Alert) support SNMP over IPv6. For IPv6 to properly handle MIB's, more work needs to be completed. The MIB's need to be reachable from IPv6 addresses7. The organization in the IPv4 to IPv6 migration suffers due to poor planning and organization at the outset.
A managed network requires access to Secure Shell (SSH), Trivial File Transfer Protocol (TFTP), and TELNET. To date, routers using TELNET and SSH can support these requirements in an IPv6 environment. Other equipment that supports IPv6 uses TFTP7.
At the outset of IPv6, there was not a unified MIB approach. RFC1902 for IPv4 and RFC2465 for IPv6 define MIB's for textual conventions. MIB 2011 defines IPv4 IP MIB and ICMP MIB, while RFC2465 defines IPv6 IP MIB. RFC2465 defines IPv6 IP MIB. RFC2466 defines IPv6 ICMP MIB's. RFC2012 defines IPv4 TCP MIB, and RFC2013 defines UDP
MIB. RFC 2452 defines IPv6 TCP MIB, and RFC2454 defines UDP. The IETF is working toward unified MIB's7. On top of all this is the proprietary MIB's. The IETF has a lot of work left on IPv6.6DSS (2006) makes the following recommendations for network management:
1. LAN
management
2. WAN
management
The need exists for a better Internet design. Since the Internet is so complex, and there is not a real controlling authority, it is a work of eventual consensus. Before its initial release to the public, systematic thinking outside of the box would have been a worthwhile venture. It is possible that IPv6 could have come on line at an earlier date if there had been a plan at the outset. It is understandable that no one probably had the foresight that the IPv4 addresses would run out. The exponential growth of technology eventually was a causal agent in the depletion of IPv4 addresses.
Attacks on the Internet probably were not expected, but early on viruses attached themselves to bulletin boards as friendly executable files. The attacks continue today and into the future. Although IPv6 has a stronger security suite, it is vulnerable to certain kinds of attacks. In migrating from IPv4 to IPv6, it is essential that there are no holes in security. During the migration both IPv4 and IPv6 are more vulnerable to attacks.
There is a better way to design communication infrastructures. It is the Global Environment for Network Innovations (GENI), and National Science Foundation's (NSF) purpose for GENI is for creation of a experimental design facility for research toward a better Internet or establishing and demonstrating a communication structure that is beyond the capabilities of the existing Internet8. Since this is a research facility, NSF desires input from the public and private computer community for comments on creating the best global research facility The NSF expects that GENI research while delving in the areas of experimental research will develop new research and technology products that can then be made available through technology transfer8.
As GENI research focuses on networked and distributed systems, the potential among the U.S. research community to conceptualize, design, and deploy a communication system beyond the scope of the Internet is inevitable8. It is hard to imagine a replacement for the Internet while thinking inside the box, but as thinking occurs outside of the box then high technology innovations will follow.
For a project of this immensity, it has to have funding. Once approved, GENI receives 12.5 million dollars per year and additional 10 million dollars per year with a justified need. The NSF Directorate for Computer and Information Science (CISE) is the controlling authority of the GENI initiative8. The GENI Planning Group, acting as an advisory to the NSF, is comprised of representatives from 12 U.S. universities and one private network related company8.
GENI is an offshoot of the NSF's 2005 Disruptive Network Innovation (DNI) conference8. DNI focused on the need for architectural research for developing infrastructure that would support research8. GENI includes but is not limited to research in distributed systems and optical, sensor, and wireless networks8.
There are two views per NSF for how to design a new Internet: the first method is to start over from scratch with a clean slate; the second method is an overlaying of applications on the Internet8. The NSF prefers and in between approach, that utilizes overlays and phase-outs; however, the Internet rules will not impede GENI research8.
The conceptual GENI platform design supports research and eventual deployment of products through technology transfer8. GENI is comprised of a substrate that is programmable and sliceable8. There is management software that overlays and controls the slices where experiments are in progress8. The GENI platform physical layer is comprised of links, forwarders, storage units, processor clusters and wireless subnets8.
The slices under the substrate are independent an autonomous, non-stop experiment runs, and dynamic due to the modular make up8. GENI requires a neutral stance on services and architecture, edge diversity, ease of user access, data analysis, and instrumentation8.
For continuous operation over the long haul, GENI will require a federation of universities, the private sector, and possibly more government funding8. GENI can be counted successful if a better Internet is designed and developed, development and deployment of innovative services and applications, eventual replacement of architecture, the ability if required to retrofit into the existing Internet, develop an accepted blueprint of the new Internet, and design and develop protocols that operate above and below IP9.
A new GENI announcement made on April 25, 2006 called Project Execution Plan (Conceptual Design) is a milestone10. The Internet's older design limits security, availability, flexibility, and manageability. Patches have reached the limit, and now it is time to rethink the Internet and the NSF has sanctioned this new approach to research. Belief is that the method of consensus building is untenable for the new Internet, and the future needs require an organized methodology (Clark, Shenker, &, Falk, 2007). GENI is going to revolutionize the way users view the Internet today11.
GENI can overcome the problem of the present Internet to collect and analyze data due to privacy and/or proprietary issues (Clark et al., 2007). Compared to the existing Internet, the new generation Future Internet design provides a proactive instead of a reactive mode in respect to attacks11.
Clark et al., 2007, p.19, write concerning network management, "A primary challenge for these networks is operation without large teams of highly trained specialists, which implies low-cost automatic management, so the work described in this report on network management is an important building block, as is the work on wireless systems. Management must be cross-layer, from the physical layers up: the replacement infrastructure must be self-managing and self-organizing to a much larger degree than today's networks. Both initial setup and ongoing maintenance and upgrades must be simple, fast, and safe. Vastly reduced management complexity would ultimately reduce the impact of the most significant cause of unavailability---human error."
The present Internet network management systems require piecing together on an as needed basis, and more than often are difficult to configure due to so many vendors, brands, and commands11.
Conclusion
The Internet has been a good method for handling data in its early days. Since then, the Internet has grown at a faster pace than expected. Ultimately, because of the early dissemination of IP addresses, there is in a sense a contrived shortage of addresses. Consumption of Class A addresses occurred early on in the process.
As time progressed, more and more new products required IP addresses. The growth in the need for more addresses in the United States in turn drove the need for NAT. NAT then became the driver for complacency that steers entities away from migrating from IPv4 to IPv6. Since the Internet builds on consensus, there will continue to be problems. The present Internet acts more in the reactive mode than a proactive mode. The introduction of IPv6 and the expected migration from IPv4 to IPv6 adoption and implementation is slow in the United States. FCAPS is premature in IPv6.
The IPv6 Internet is still vulnerable to different kinds of attacks. Instead of continuously having to react to problems, it is best to start thinking ahead to better systems that can eventually replace the Internet. The GENI program is a new generation of innovative research that leads to deployment through technology transfer of communication infrastructures, protocols, and systems that, now, belongs to the imagination. The only drawback is that the GENI research facility is several years into the future. The hope is that the GENI program can be fast-tracked so that research can begin as soon as possible. It is exciting to watch and be a part of the unfolding of future communications.
Robert Chavous, Jr., holds a bachelor of science degree from University of Tennessee at Knoxville and a master’s degree in technology systems from East Carolina University. He has more than 30 years of telecom and computer systems experience, and has applied his knowledge in management and teacher-training roles at CISCO Regional Academy. Chavous holds two U.S. patents. He can be reached at [email protected].
References
1. Deering, S., & Hending, R. (1995). Internet Protocol Version 6 (IPv6) specification (RFC1883rd ed.). Retrieved March 30, 2007, from RFC Index Search Engine Web site: http://www.rfc-editor.org/?cgi-bin/?rfcsearch.pl
2. Ladid, L. (2003). IPv6 on everything: The new Internet. 3g Mobile Communication Technologies, Conference Publication No. 477, 317-322. Retrieved April 28, 2007, from IEEE
Xplore Web site: https://jproxy.lib.ecu.edu/login?url=http://ieeexplore.ieee.org/iel5/7359/19962/00923561.pdf?tp=&arnumber=923561&isnumber=199623. Garretson, C. (2005, October). Bechtel says move to IPv6 is all about business. Networkworld. Retrieved April 27, 2007, from NETWORKWORLD Web site:
4. Wang, Y., Ye, S., & Li, X. (2005). Understanding current IPv6 performance: A measurement study. Ieee, 71-76. Retrieved April 29, 2007, from IEEE (News - Alert) Web site: http://ieeexplore.ieee.org/search/freesearchresult.jsp?history=yes&queryText=%28shaozhi+ye%29
5. Grosse, E., & Lakshman, Y. N. (2003). Network Processors Applied to IPv4/IPv6 Tarnsition. Ieee Network, 17(4), 35-39. Retrieved April 29, 2007, from IEEE Web site: http://ieeexplore.ieee.org/search/freesearchresult.jsp?history=yes&queryText=%28network+processors+applied%29
6. Tian, J., & Li, Z. (2001). The next generation protocol and its test. Ieee, 1, 210-215. Retrieved April 29, 2007, from IEEE Xplore Web site: http://ieeexplore.ieee.org/search/freesearchresult.jsp?history=yes&queryText=%28jun+tian%29
7. 6DISS. (2006). IPv6 network management. . Retrieved April 30, 2007, from 6DISS Web site: http://www.6diss.org/workshops/mediterranean/management.pdf
Benzel, T., Wroclawski, J., & Casey, D. (2007). Facility construction plan (GDD-07-05). Retrieved April 30, 2007, from GENI Web site: http://www.geni.net/GDD/GDD-07-45.pdf
8. GENI Planning Group-Overview. (2006). What is GENI? In Overview (NSF). Retrieved April 27, 2007, from GENI Web site: http://geni.net/overview.php
9. GENI Planning Group - Success. (2006). Success Scenarios (NSF). Retrieved April 29, 2006, from GENI Web site: http://geni.net/success.php
10. GENI Planning Group. (2007). Facility design (GDD-07-44). . Retrieved April 30, 2007, from GENI Web site: http://www.geni.net/GDD/GDD-07-44.pdf
11. Clark, D., Shenker, S., & Falk, A. (2007). GENI researcch plan (GDD-06-28). Retrieved April 30, 2007, from GENI Web site: http://www.geni.net/GDD/GDD-06-28.pdf
and
Falk, A. (2007). GENI systems requirements document (srd). In GENI (GDD-07-46). Retrieved April 30, 2007, from GENI Web site: http://www.geni.net/GDD/GDD-07-46.pdf
|