Chapter 1. Why IPv6?
The IP version currently used in networks and the Internet is IP Version 4 (IPv4). IPv4 was developed in the early ’70s to facilitate communication and information sharing between government researchers and academics in the United States. At the time, the system was closed with a limited number of access points, and consequently the developers didn’t envision requirements such as security or quality of service. To its credit, IPv4 has survived for over 30 years and has been an integral part of the Internet revolution. But even the most cleverly designed systems age and eventually become obsolete. This is certainly the case for IPv4. Today’s networking requirements extend far beyond support for web pages and email. Explosive growth in network device diversity and mobile communications, along with global adoption of networking technologies, are overwhelming IPv4 and have driven the development of a next-generation Internet Protocol.
IPv6 has been developed based on the rich experience we have from developing and using IPv4. Proven and established mechanisms have been retained, known limitations have been discarded, and scalability and flexibility have been extended. IPv6 is a protocol designed to handle the growth rate of the Internet and to cope with the demanding requirements on services, mobility, and end-to-end security.
When the Internet was switched from using Network Control Protocol (NCP) to Internet Protocol (IP) in one day in 1983, IP was not the mature protocol that we know today. Many of the well-known and commonly used extensions were developed in subsequent years to meet the growing requirements of the Internet. In comparison, hardware vendors and operating system providers have been supporting IPv6 since 1995 when it became a Draft Standard. In the decade since then, those implementations have matured, and IPv6 support has spread beyond the basic network infrastructure and will continue to be extended.
There is certainly a need for caution when considering adoption of IPv6—there is still work to be done to reach parity with the maturity of IPv4 (refer to Chapter 10 for more details). The missing pieces of IPv6 will be developed in the coming years, just the way it happened with IPv4. And many enterprises are not finding enough reasons to adopt it right now. However, it is very important for organizations to pay attention to the introduction of IPv6 because its use is inevitable in the long term. If IPv6 is included in strategic planning; if organizations think about possible integration scenarios ahead of time; and if its introduction is considered when investing in IT capital expenditures, organizations can save considerable cost and can enable IPv6 more efficiently when it is needed.
An interesting and humorous overview of the history of the Internet can be found in RFC 2235, “Hobbes’ Internet Timeline.” The account starts in 1957 with the launch of Sputnik in Russia and the formation of the Advanced Research Projects Agency (ARPA) by the Department of Defense (DoD) in the United States. The RFC contains a list of yearly growth rate of hosts, networks, and domain registrations in the Internet.
Some excerpts from the RFC:
1969: Steve Crocker makes the first Request for Comment (RFC 1): “Host Software.”
1970: ARPANET hosts start using Network Control Protocol (NCP).
1971: 23 hosts connect with ARPANET (UCLA, SRI, UCSB, University of Utah, BBN, MIT, RAND, SDC, Harvard, Lincoln Lab, Stanford, UIU(C), CWRU, CMU, NASA/Ames).
1972: InterNetworking Working Group (INWG) is created with Vinton Cerf as Chairman to address the need for establishing agreed-upon protocols. Telnet specification (RFC 318) is published.
1973: First international connections to the ARPANET are made at the University College of London (England) and Royal Radar Establishment (Norway). Bob Metcalfe’s Harvard Ph.D. thesis outlines the idea for Ethernet. File transfer specification (RFC 454) is published.
1976: Queen Elizabeth II sends an email.
1981: Minitel (Teletel) is deployed across France by France Telecom.
1983: The cutover from NCP to TCP/IP happens on January 1.
1984: The number of hosts breaks 1,000.
1987: An email link is established between Germany and China using CSNET protocols, with the first message from China sent on September 20. The thousandth RFC is published. The number of hosts breaks 10,000.
1988: An Internet worm burrows through the Net, affecting 10 percent of the 60,000 hosts on the Internet.
1989: The number of hosts breaks 100,000. Clifford Stoll writes Cuckoo’s Egg, which tells the real-life tale of a German cracker group that infiltrated numerous U.S. facilities.
1991: The World Wide Web (WWW) is developed by Tim Berners-Lee and released by CERN.
1992: The number of hosts breaks 1,000,000. The World Bank comes online.
1993:The White House comes online during President Bill Clinton’s time in office. Worms of a new kind find their way around the Net—WWW Worms (W4) are joined by Spiders, Wanderers, Crawlers, and Snakes.
1994: Internet shopping is introduced; the first spam mail is sent; Pizza Hut comes online.
1995: The Vatican comes online. Registration of domain names is no longer free.
1996: 9,272 organizations find themselves unlisted after the InterNIC drops their name service as a result of their not having paid their domain name fees.
1997: The 2,000th RFC is published.
This is as far as the RFC goes. But history goes on. According to http://www.nua.ie/surveys/how_many_online/world.html, the worldwide online population reached 254 million users in 2000 and 580 million users in 2002. According to http://www.clickz.com/stats/web_worldwide, the online user population reached 1.08 billion users in 2005. In 2003, the U.S. Department of Defense (DoD) announced that they would be migrating the DoD network to IPv6 by 2008, and the Moonv6 (http://www.moonv6.com) project was started. In 2005, Google registered a /32 IPv6 prefix, and Vint Cerf, known as “Father of the Internet,” joined Google. These are just a few selected events and milestones of the Internet’s history. Keep watching as more history unfolds.
The History of IPv6
The Internet Engineering Task Force (IETF) began the effort to develop a successor protocol to IPv4 in the early 1990s. Several parallel efforts to solve the foreseen address space limitation and to provide additional functionality began simultaneously. The IETF started the Internet Protocol—Next Generation (IPng) area in 1993 to investigate the different proposals and to make recommendations for further procedures.
The IPng area directors of the IETF recommended the creation of IPv6 at the Toronto IETF meeting in 1994. Their recommendation is specified in RFC 1752, “The Recommendation for the IP Next Generation Protocol.” The Directors formed an Address Lifetime Expectation (ALE) working group to determine whether the expected lifetime for IPv4 would allow the development of a protocol with new functionality, or if the remaining time would allow only the development of an address space solution. In 1994, the ALE working group projected that the IPv4 address exhaustion would occur sometime between 2005 and 2011 based on the available statistics.
For those of you who are interested in the different proposals, here’s some more information about the process (from RFC 1752). There were four main proposals: CNAT, IP Encaps, Nimrod, and Simple CLNP. Three more proposals followed: the P Internet Protocol (PIP), the Simple Internet Protocol (SIP), and TP/IX. After the March 1992 San Diego IETF meeting, Simple CLNP evolved into TCP and UDP with Bigger Addresses (TUBA), and IP Encaps became IP Address Encapsulation (IPAE). IPAE merged with PIP and SIP and called itself Simple Internet Protocol Plus (SIPP). The TP/IX working group changed its name to Common Architecture for the Internet (CATNIP). The main proposals were now CATNIP, TUBA, and SIPP. For a short discussion of the proposals, refer to RFC 1752.
The Internet Engineering Steering Group approved the IPv6 recommendation and drafted a Proposed Standard on November 17, 1994. RFC 1883, “Internet Protocol, Version 6 (IPv6) Specification,” was published in 1995. The core set of IPv6 protocols became an IETF Draft Standard on August 10, 1998. This included RFC 2460, which obsoleted RFC 1883.
What’s New in IPv6?
IPv6 is an evolution of IPv4. The protocol is installed as a software upgrade in most devices and operating systems. If you buy up-to-date hardware and operating systems, IPv6 is usually supported and needs only activation or configuration. Currently available transition mechanisms allow the step-by-step introduction of IPv6 without putting the current IPv4 infrastructure at risk.
Here is an overview of the main changes:
- Extended address space
The address format is extended from 32 bits to 128 bits. This provides an IP address for every grain of sand on the planet. In addition, it also allows for hierarchical structuring of the address space in favor of optimized global routing.
- Autoconfiguration
Perhaps the most intriguing new feature of IPv6 is its Stateless autoconfiguration mechanism. When a booting device in the IPv6 world comes up and asks for its network prefix, it can get one or more network prefixes from an IPv6 router on its link. Using this prefix information, it can autoconfigure for one or more valid global IP addresses by using either its MAC identifier or a private random number to build a unique IP address. In the IPv4 world, we have to assign a unique IP address to every device, either by manual configuration or by using DHCP. Stateless autoconfiguration should make the lives of network managers easier and save substantial cost in maintaining IP networks. Furthermore, if we imagine the number of devices we may have in our homes in the future that will need an IP address, this feature becomes indispensable. Imagine reconfiguring your DHCP server at home when you buy a new television! Stateless autoconfiguration also allows for easy connection of mobile devices, such as a mobile phone or handheld, when moving to foreign networks.
- Simplification of header format
The IPv6 header is much simpler than the IPv4 header and has a fixed length of 40 bytes. This allows for faster processing. It basically accommodates two times 16 bytes for the Source and Destination address and only 8 bytes for general header information.
- Improved support for options and extensions
IPv4 integrates options in the base header, whereas IPv6 carries options in so-called extension headers , which are inserted only if they’re needed. Again, this allows for faster processing of packets. The base specification describes a set of six extension headers, including headers for routing, Mobile IPv6, and quality of service and security.
Why Do We Need IPv6?
For historic reasons, organizations and government agencies in the United States use approximately 60 percent of the allocatable IPv4 address space. The remaining 40 percent is shared by the rest of the world. Of the 6.4 billion people in the world, approximately 330 million live in North America, 807 million in Europe, and 3.6 billion in Asia. This means that the 5 percent of the world’s population living in the United States has 60 percent of the address space allocated. Of the 3.6 billion people living in Asia, approximately 364 million have Internet access, and the growth rate is exponential. This is one explanation of why the deployment of IPv6 in Asia is much more common than in Europe and the United States. (All statistics are based on 2005 numbers.)
Tip
An interesting resource site for statistics can be found at: http://www.internetworldstats.com/stats.htm.
The IPv4 address space has a theoretical limit of 4.3 billion addresses. However, early distribution methods allocated addresses inefficiently. Consequently, some organizations obtained address blocks much larger than they needed, and addresses that could be used elsewhere are now unavailable. If it were possible to reallocate the IPv4 address space, it could be used much more effectively, but this process is not possible, and a global reallocation and renumbering is simply not practical. We also have to be aware of the fact that today, as the IPv4 address space approaches exhaustion, only about 14 percent of the world’s population has Internet access. If we want to provide Internet access to only 20 percent of the world’s population, we will need the IPv6 address space. And this calculation does not take into account that in the future we will need IP addresses for billions of devices. Vendors in all industries are developing monitoring, control, and management systems based on IP.
As the previous section shows, the IPv6 working group has done more than extend the address space. For many complex networks of today and tomorrow, and for the number of IP devices of all types, the autoconfiguration capability of IPv6 will be a necessity. The management of such services can’t be accomplished with traditional addressing methods, and Stateless autoconfiguration will also help to reduce administrative costs for organizations.
The extended address space and the restoration of the original end-to-end model of the Internet allows for the elimination of Network Address Translation (NAT), in which a single or a few public IPv4 address(es) are used to connect a high number of users with private addresses to the Internet by mapping the internal addresses to the public address(es). NATs were introduced as a short term fix for solving the address space limitations with IPv4, since IPv6 was not ready yet (refer to RFC 1631; the original NAT specification was obsoleted by RFC 3022 in 2001). NATs have become pretty common in IPv4 networks, but they create serious disadvantages in management and operation: in order to do the address mapping, NATs modify end node addresses in the IP header. Very often, application level gateways (ALG) are used in conjunction with NAT to provide application-level transparency. There is a long list of protocols and applications that create problems when used in a NAT environment. IPsec and peer-to-peer applications are two well-known examples. Another known issue with NAT is the overlapping of private address space when merging networks, which requires either the renumbering of one of the networks or the creation of a complex address mapping scheme. The amplification of limited address space, the primary benefit of NAT, is not needed with IPv6 and therefore is not supported by design.
By introducing a more flexible header structure (extension headers), the protocol has been designed to be open and extensible. In the future, new extensions can easily be defined and integrated in the protocol set. Based on the fact that IPv4 has been in use for almost 30 years, the development of IPv6 was based on the experience with IPv4 and focused on creating an extensible foundation; you can expect it to last a long time.
Broadband penetration rates in countries such as South Korea, Japan, Germany, France, and the United States continue to accelerate and, in some cases, have reached 65 percent or more. In fact, a 2004 study done by Nielsen//NetRatings (http://www.nielsen-netratings.com) showed that the city of San Diego, California had a broadband penetration rate of 69 percent. This level of always-on connectivity with substantial bandwidth capacity (when compared to dial-up services) means that there is greater opportunity for devices to be connected. And many consumer electronic manufacturers have taken advantage of this. Online gaming is no longer the sole purview of games on PCs. Gaming stations, such as Sony’s PlayStation 2, the Nintendo DS, and Microsoft’s Xbox, have added capabilities to take them online. In Japan, many telecommunication carriers are providing television-type services (movies, audio content, etc.) over their IP networks. Even appliances, such as refrigerators, stoves, water heaters, and bathtubs are getting connected. While it may seem rather silly to network-enable a bathtub, many of these devices are being connected to facilitate things such as power management, remote control, and troubleshooting, and for telemetry/monitoring purposes. The end result of this network-enablement process is a greater number of devices that need addressing, many of which will not have standard user interfaces. In these cases, the IPv6 address space, coupled with features such as Neighbor Discovery, autoconfiguration, and Mobile IPv6, will help to usher in a new era of computerization in the home, but hopefully without the enormous deployment headache that it would cause if it were attempted with the current protocol.
The growth of the wireless industry (both cellular and wireless networks based on protocols such as 802.11x, 802.16, 802.20, UMTS, UWB, MIMO, etc.) has been nothing short of phenomenal. In some countries, such as Italy and Great Britain, the number of cell phones actually exceeds the number of people. In this world of continuous reachability and reliance on the ability to access information at any time, the mobility requirements for end users have become exceptionally important. From the carriers’ perspective, especially those supporting multiple media access types (e.g. 3G and WiMax), leveraging IP as the method of transporting and routing packets makes sense. Cell phones and PDAs can already access the Internet, play games with other users, make phone calls, and even stream video content. Instead of supporting all of these functions using different transport protocols and creating intermediary applications to facilitate communications, it is far more efficient to leverage the existing network infrastructure of the Internet and a company’s network. We will see later that from a technical perspective, Mobile IPv6 is very elegant in its design, supporting mobile users in a highly efficient manner and providing the overlay mechanisms for users to maintain their connections when moving between networks, even if those networks do not use the same type of media access.
For many of the reasons discussed here, much of the world is already adopting IPv6. There has been significant adoption in Japan and Korea, with production networks and consumers paying for IPv6-based services. China is spending millions of dollars (USD) developing a new backbone network that is reportedly going to be IPv6. The European Union (EU) has also spent millions for the research and development of IPv6 backbone networks and innovative services that leverage many of the beneficial features of IPv6. India, with a growing middle class and a strong presence in the world of IT, has demonstrated substantial interest in the deployment and use of IPv6. In June 2003 and then again in July 2005, the U.S. government mandated the adoption of IPv6. Other countries such as Australia, Taiwan, Singapore, England, and Egypt have all made similar announcements. So IPv6 is on its way, and it happened faster than we expected when we published the first edition of this book.
There still remain some questions about the value of IPv6 to the enterprise, and it is worth conceding that each organization needs to evaluate the benefits of IPv6 carefully for their own internal use and determine the best time for its introduction. In many instances, organizations can find clever ways to use IPv6 to solve “pain” issues without migrating their entire network. Adoption can occur in an incremental fashion with a plan that minimizes integration pain but also ensures that everything is ready when the time comes to “flip the switch.” As the case studies in Chapter 10 show, well-planned introduction costs less than you would expect; the step-by-step introduction allows you to learn as you go, thereby saving a lot of money and headaches, and you can do it without putting the current IPv4 infrastructure at risk.
But with all these thoughts and considerations, let’s not forget the most essential advantage of IPv6. With its new structure and extensions, IPv6 provides the foundation for a new generation of services. There will be devices and services on the market in the near future that cannot be developed with IPv4. This opens up new markets and business opportunities for vendors and service providers alike. The first-mover opportunities are substantial, as are the opportunities to extend current product lifecycles by refreshing their technology with IPv6. On the other hand, it means that organizations and users will require such services in the mid-term. It is therefore advisable to integrate the new protocol carefully and in a nondisruptive manner, by taking one step at a time to prepare the infrastructure for these new services. This protects you from having to introduce a business-critical application based on IPv6 with no time for thorough planning and unreasonably high cost.
Common Misconceptions
When considering all these advantages, maybe the question should be: “Why not IPv6?” When talking to customers, we often find that they share a similar set of misconceptions preventing them from considering IPv6. Here are the most common ones:
- “The introduction of IPv6 puts our current IP infrastructure—our networks and services—at risk.”
This concern is unsubstantiated. A major focus in IPv6’s development was to create integration mechanisms that allow both protocols to coexist peacefully. You can use IPv6 both in tandem with and independently of IPv4. It is possible to introduce IPv6 and use it for access to new services while retaining IPv4 to access legacy services. This not only ensures undisrupted access to IPv4 services, but it also allows a step-by-step introduction of IPv6. I discuss these mechanisms in Chapter 10.
- “The IPv6 protocol is immature and hasn’t proven that it stands the test of time or whether it is capable of handling the requirements.”
This is only partially true. IPv6 has been implemented in most router and operating systems for almost a decade, and has been tested and optimized extensively. There are substantial international research efforts and test networks for deployment that are further optimizing integration methods. One of the largest tests currently running is Moonv6 (http://www.moonv6.com). Moonv6 is a test network where the U.S. Department of Defense (DoD), IPv6 developers and vendors, and various academic and industry bodies conduct extensive interoperability and conformance testing of the IPv6 base features, as well as extended features such as quality of service, mobility, and security. You can find a more detailed description of Moonv6 in Chapter 10.
- “The costs of introducing IPv6 are too high.”
There will certainly be costs associated with adopting IPv6. In many cases, newer networks will find that the level of IPv6 support in their current infrastructure is actually high. Regardless, the transition will necessitate some hardware and software costs. Organizations will need to train their IT staff, and, depending on the speed at which integration must occur, they may need to seek outside expertise.
However, the cost savings associated with IPv6 are becoming easier to define. Networks based on IPv4 are becoming increasingly more complex. New IT services such as VoIP, instant messaging, video teleconferencing, IPTV, and unified communications are adding layers of middleware and complexity. Merging organizations or those conducting B2B transactions are implementing NAT overlap solutions that have high management costs and are difficult to troubleshoot. And a growing market of mobile devices and network appliances requires robust access models that are expensive and difficult to implement in an IPv4 world. In all of these cases, IPv6 presents a cleaner and more cost-effective model in the long run than IPv4 can provide.
- “With Stateless autoconfiguration, we will not be able to control or monitor network access.”
While this statement may generally be true for networks that widely utilize Stateless autoconfiguration, administrators will have a choice about their level of control. DHCPv6 as defined in RFC 3315 has been extended to support two general modes of operation, Stateful and Stateless. Stateful mode is what those who currently utilize DHCP (for IPv4) are familiar with, in which a node (DHCP client) requests an IP address and configuration options dynamically from a DHCP server. DHCPv6 also offers a Stateless mode in which DHCPv6 clients simply request configuration options from a DHCPv6 server and use other means, such as Stateless autoconfiguration, to obtain an IPv6 address. On the other hand, you can configure IPv6 networks to force the use of DHCPv6 for dynamic address assignment and configure DHCPv6 to enhance security, since authentication is available as part of the protocol.
- “Our Internet Service Provider (ISP) does not offer IPv6 services, so we can’t use it.”
You do not have to wait for your ISP to use IPv6 in your corporate or private network. If you want to connect to the global IPv6 Internet, you can use one of the transition mechanisms and tunnel your IPv6 packets over the IPv4 infrastructure of your ISP.
- “It would be too expensive and complex to upgrade our backbone.”
The transition mechanisms make it possible to use IPv6 where appropriate without dictating an order of upgrade. Usually for the backbone it is advisable to wait for the regular life cycle, when hardware needs to be exchanged anyway. Make sure to choose hardware that supports performance IPv6 routing. In the meantime, you can tunnel your IPv6 packets over the IPv4 backbone. Networks that use MPLS have an easy way to tunnel IPv6 packets over their IPv4 MPLS backbone. Read more about it in Chapter 10.
- “It would be too complex and expensive to port all of our applications to IPv6.”
The effort necessary to port applications to run over IPv6 is often much lower than expected. If an application is well-written, it may simply run over IPv6 without modification. Instead of assuming that it won’t work, test it to find out. For applications that need modifications that are not yet available, or for applications in which porting does not make sense, there are mechanisms available that support IPv4 applications in IPv6 networks and IPv6 applications in IPv4 networks. Alternatively, you can run a dual-stack network, in which you use IPv4 to access IPv4 applications and IPv6 to access IPv6 applications.
- “We have enough IPv4 addresses; we don’t need IPv6.”
True—if you have enough IPv4 addresses, there may be no immediate need to integrate IPv6 today. But ignoring IPv6 for this reason is a perspective that assumes that your network stands completely isolated from the rest of the world, including your vendors, partners, and customers. IPv6 adoption is further along in Asia than in the United States, so even though you may have adequate address space for your operations in Denver, interconnecting with a partner organization in Tokyo may eventually become complicated if you do not support IPv6. Plus, the assumption that IPv6 is about address space only doesn’t account for the advanced features that IPv6 brings to the table.
When Is It Time for IPv6?
If the rest of the world moves to IPv6 while you insist on continuing to use IPv4, you will exclude yourself from global communication and reachability. This might not be a critical issue today, but times are changing fast these days. The risks if you wait too long include losing potential customers and access to new markets and the inability to use new IPv6-based business applications until you implement it.
There is a golden rule in IT: “Never touch a running system.” As long as your IPv4 infrastructure runs well and fulfills your needs, there is no reason to change anything. But from now on, whenever you invest in your infrastructure, you should consider IPv6. An investment in the new technology gives it a much longer lifetime and keeps your network state-of-the-art.
These are the main indicators that it may be time for you to consider switching to or integrating IPv6:
You need to extend or fix your IPv4 network or NAT implementation.
You are running out of address space.
You want to prepare your network for applications that are based on advanced features of IPv6.
You need end-to-end security for a large number of users and you do not have the address space, or you struggle with a NAT implementation.
You need to replace your hardware or applications that are at the end of their lifecycles. Make sure you buy products that support IPv6, even if you don’t enable it right away.
You want to introduce IPv6 while there is no time pressure.
The following provisions can be taken in order to prepare for IPv6 adequately:
Build internal knowledge, educate IT staff, and create a test network.
Include IPv6 in your IT strategy.
Create integration scenarios based on your network and requirements.
Put IPv6 support on all of your hardware and software shopping lists. Be specific about which features (RFCs) must be supported.
Compel your vendors to add IPv6 support to their products.
If you do this, you can determine the right moment for the introduction of IPv6 in your network. You can also assess whether a further investment in your IPv4 infrastructure makes sense or whether introducing IPv6 would be a better way to go.
There will be no “flag day” for IPv6 like there was for the 1983 move from NCP to IPv4. Probably there will be no killer application either, so don’t wait for one. IPv6 will slowly and gradually grow into our networks and the Internet. Taking a step-by-step approach to IPv6 may be the most cost-efficient way to integrate it, depending on your requirements. This method does not put your current infrastructure at risk or force you to exchange hardware or software before you are ready, and it allows you to become familiar with the protocol, to experiment, to learn, and to integrate what you’ve learned into your strategy.
IPv6 Around the World
The oldest IPv6 network is the 6Bone
(http://www.6bone.net). It was started in 1996, and by 2004 it connected more than 1,000 hosts in more than 50 countries across the world. Originally, it was used as a test network for the IETF working groups. Over time it became an international project in which everybody was welcome to participate. The address allocation had not been standardized at that time, so the 6Bone received the special prefix 3FFE. Today, the IPv6 address allocation is specified and open for registration, and the 6Bone will gradually be moved to the official IPv6 address space by mid-2006. Their web site is still accessible for historical and statistical reasons. The 6Bone proved that IPv6 is stable and can be used globally. It was also used to get experience with routing and network management processes, as well as to test transition mechanisms and IPv6 applications and services.
If we look at the global deployment of IPv6, the scenarios are different on each continent. The International IPv6 Forum (http://www.ipv6forum.com) coordinates the worldwide activities. The International Task Force (http://www.ipv6tf.org) coordinates the regional Task Forces all over the world. There is a North American IPv6 Task Force (http://www.nav6tf.org), a European Task Force (http://www.eu.ipv6tf.org), and different Task Forces in Asia and other parts of the world. They can all be found from the main Task Force Site. The regional Task Forces coordinate the activities in their regions. In Europe, for example, there is a Task Force in almost every country.
Asia
In Asia, IPv6 is already a reality. The high population and accelerated Internet growth rate, combined with the limited IPv4 address space, does not leave any other choices.
Japan was one of the first countries to take the lead. In March 2001, they published the “e-Japan Priority Policy Program,” announcing that they would build the largest IPv6 network. The Japanese Task Force can be found at http://www.v6pc.jp/en/index.phtml.
In Japan there is a showroom where vendors demo their IPv6-capable devices. Sony, for instance, announced that in the near future, all Sony devices will include IPv6 support. To give you an idea of the status of IPv6 in Japan, here are some things you can see in this showroom:
- Toshiba
Displays a refrigerator and a microwave oven with routing and IPv6 support included. You operate the devices by a panel through web access and email.
- Sanyo
Shows an IPv6-capable digital camera and an IPv6-enabled television with a home gateway. The camera can upload your digital pictures to your home gateway when you are on the road through any public wireless network. The television can be operated and used remotely, so different participants can view the same pictures or movies from different locations.
- Canon
Demonstrates a webcam system that can be remotely controlled. You can watch your kids, your dogs, or your coffee machine while you are on the road.
- Nokia Japan and NTT Communications (global ISP)
Displays an Internet terminal that combines wireless, RFID, and Mobile IPv6 technology. The demo shows that it is possible for mobile devices to use services over the Internet in a secured, certified way.
In China, the China Next Generation Internet (CNGI) project was started in 2001. In the first half of 2006, the deployment of IPv6 in the backbone should be completed in 300 campus networks, including 100 universities, 100 institutes, and 100 enterprises. China’s five major telecommunication operators play a key role in this project. They estimate that they will complete the construction of all the backbone and Shanghai NAPs in the first quarter of 2006, and complete the interlink of foreign IPv6 Internet before mid-2006. IPv6 Mobility was built into the CNGI from the beginning. The CNGI production deployment and application trials in 2005 consist of a total of 61 projects undertaken by over 100 of China’s top technology companies and universities; these trials have been approved and are estimated to be complete before the end of 2006. Metropolitan Area Networks (MANs) will be deployed gradually in each city, with IPv6 playing an important part in this deployment. IPv6 will also be used in other industries, such as the military, meteorology, seismology, intelligence architecture, and digital home networking. Many of the giant industry companies in China began to focus on IPv6, such as Lenovo (IBM PCs) and Konka. Lenovo has launched its Intelligent Grouping and Resource Sharing (IGRS) technology to support IPv6.
Many other countries in Asia are active as well. Countries such as India, Korea, Thailand, and Taiwan each have their own Task Force, and in most of these countries, IPv6 has strong governmental support.
Europe
In Europe, the European Commission has taken the lead and supported the introduction of IPv6 since 2000. The European Commission believes that IPv6 is essential for the competitiveness of their economic area. The European Task Force (http://www.eu.ipv6tf.org) coordinates the activities in Europe.
Telia Sweden was one of the first ISPs to offer commercial IPv6 services. In 2001, Telia already offered six POPs (Points of Presence) in different locations in Europe. Most ISPs currently do not offer IPv6 services commercially, but in the background, many of them have prepared the introduction and will be able to react quickly to growing demand on the market. The numbers of IPv6 Internet backbones and Internet Exchange Points (IEX) are growing. For instance, NTT Communications offers commercial IPv6 services around the globe. They started in 2001 in Japan; since February 2003, they have offered their services in Europe; and since June 2003, in the United States and in some Asian countries. NTT Communication runs two network operation centers around the clock, seven days a week, and the company has more than four years of IPv6 network management experience. You’ll find a description of their deployment in Chapter 10.
In Europe, there are two major research projects partially funded by the European Commission: the 6net project (http://www.6net.org) and Euro6IX (http://www.euro6ix.org). 6net was a three-year European project created to test whether IPv6 could cope with the demands of today’s global Internet. For this purpose, an IPv6 network connecting 16 countries was created and used as a platform for interoperability and integration tests. The three years have passed, and the 6net project ended in 2005. The Internet Society Technologies (IST) initialized the Euro6IX project. Its goal is to support a rapid introduction of IPv6 in Europe. You can find details on both projects and tons of interesting research materials on their respective web sites.
The IPv6 address space and Mobility support offer a good basis for further deployment of Voice over IP (VoIP). Mobile IPv6 removes some limitations with the IPv4 implementations of Mobility and makes it much more suitable for global use. The German company Telekom stated in early 2004 that they believe that by the year 2020, global telephone communication will be entirely IP-based. Many of the telecom providers are preparing for this challenge in the background. There are a number of VoIP implementations using IPv6.
Car vendors will use IP as well. Renault, for instance, has a prototype of an IPv6-networked car that they co-developed with Cisco. It has a Cisco router built-in with a Mobile IPv6 implementation, so the car has an internal IPv6-based network that can be used for monitoring, control, and maintenance; for accessing weather, traffic, and road condition information; or by passengers to connect through wireless or Bluetooth to surf the Web or watch digital TV with any IPv6-capable device. With the Mobile IPv6 implementation, the Cisco router can switch networks to find the best possible connection depending on its position. The systems and devices connected from inside the car will not lose their connections while the router is switching from one network to another. Other car vendors, such as BMW, DaimlerChrysler, and Audi, are working on similar projects. I heard that the IP car of the future will have a minimum of 20 IP addresses. Go figure.
The United States
Originally it was assumed that the United States would be the last part of the world to adopt IPv6, simply because the address space issue is not that critical. In summer 2003, the situation significantly changed with the U.S. DoD’s announcement that it will migrate its network to IPv6 by 2008. Starting in 2003, all IT purchasing done by DoD agencies had to include requirements for IPv6 enablement. Given that the U.S. DoD’s IT spending budget is around 30 billion dollars a year (USD), this provides significant motivation for vendors. Many other defense departments and NATO allies all over the globe have followed their example. This decision will accelerate the IPv6 market not only in the United States, but all over the world. Given the extreme diversity of how IP can be applied in the military space, there should be accelerated development of additional services and applications.
In addition to the U.S. DoD, the Office of Management and Budget (OMB), a presidential office, announced in July 2005 that all Federal agencies must also use IPv6 by 2008. While the DoD budget for IT is impressive, the entire U.S. Federal government is certainly bigger.
The North American IPv6 Task Force can be found at http://www.nav6tf.org. The largest test and research network is Moonv6 (http://www.moonv6.com). Use these two entry points to find the information about activities, tests and results, deployments, and general IPv6 resources.
IPv6 Status and Vendor Support
As previously mentioned, IPv6 is implemented in most up-to-date versions of routing and operating systems. For standard applications, assume that IPv6 support will be added with their next major release at the latest. For creating an IPv6 integration plan for your corporate network, you will need to assess the status and degree of IPv6 support with each vendor individually. Many vendors have an information site that can often be found at http://www.<vendor>.com/ipv6.
It can be said that IPv6 support up to the network layer is mature, tested, and optimized. This includes routing, transition mechanisms, and DNS. DHCPv6 was standardized in 2004, and early implementations have been available in select platforms since 2005.
Development is most active in the quality of service, security, IPv4/IPv6 MIB integration, and Mobile IPv6 areas. Currently, there is a lack of support in the areas of network management, firewalls, and proxies. Vendors such as Cisco, Checkpoint, Juniper, and many others are working on these areas. The application area is continuously developing, and new applications will appear on the market that will make use of the advanced features of IPv6. Thanks to the transition mechanisms mentioned earlier, you can still use IPv4 applications in IPv6 networks. Worldwide development goes beyond infrastructure, as the showroom in Japan demonstrates.
Tip
Find more information on the status of application and vendor support in Chapter 10.
Now you know why you should care about IPv6. The rest of the chapters in this book aim to make learning about IPv6 a joy. So please read on.
References
Here’s a list of the most important RFCs and Drafts mentioned in this chapter. Sometimes I include additional subject-related RFCs for your personal further study.
RFCs
RFC 1, “Host Software,” 1969
RFC 318, “Telnet Protocol,” 1972
RFC 454, “FILE TRANSFER PROTOCOL,” 1973
RFC 1347, “TCP and UDP with Bigger Addresses (TUBA),” 1992
RFC 1526, “Assignment of System Identifiers for TUBA/CLNP Hosts,” 1993
RFC 1561, “Use of ISO CLNP in TUBA Environments,” 1993
RFC 1631, “The IP Network Address Translator (NAT),” 1994
RFC 1707, “CATNIP: Common Architecture for the Internet,” 1994
RFC 1710, “Simple Internet Protocol Plus White Paper,” 1994
RFC 1752, “The Recommendation for the IP Next Generation Protocol,” 1995
RFC 1883, “Internet Protocol, Version 6 (IPv6) Specification,” 1995
RFC 2235, “Hobbes’ Internet Timeline,” 1997
RFC 2324, “Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0),” 1998
RFC 2460, “Internet Protocol, Version 6 (IPv6) Specification,” 1998
RFC 2663, “IP Network Address Translator (NAT) Terminology and Considerations,” 1999
RFC 3022, “Traditional IP Network Address Translator (Traditional NAT),” 2001
RFC 3027, “Protocol Complications with the IP Network Address Translator,” 2001
RFC 3315, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” 2003
Get IPv6 Essentials, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
