IPv6 - A Brief Overview
Thom Garrett
At the foundation of the Internet and its derivatives (the Web, intranets, extranets, and Virtual Private Networks) is the definition of the Internet Protocol (IP). Most administrators of UNIX systems have, at minimum, a basic understanding of the structure of IP addresses. Additionally, most are aware of the growth of the Internet and the resulting stress on the addressing scheme of IPv4, the specification of IP currently employed around the world. This article concentrates on IP next generation (IPng), namely IPv6. This article is intended to raise your awareness of IPv6 and to suggest a possible migration strategy.
IPv6 is designed to address the next generation of products, such as high performance networks, as well as, perform effectively on networks operating at lower bandwidths such as hand-held devices. IPv6 does more than just attack the "depletion of IP addresses" problem. It also addresses new security features, autoconfiguration capabilities, and router improvements. The migration to IPv6 has already begun. An experimental network called the 6bone has been established to test IPv6, and implementations for IPv6 have already been developed or are currently being developed on several operating systems and router software. Many vendors offer beta versions of these products that can be obtained and tested.
Background The version of IP that we all know is Classic IP or IPv4. IPv4 can handle 232 (4,294,967,296) addresses, assuming perfect allocation. That may seem like a lot, but when you look at the continuing growth of the Internet (see www.nw.com/zone/hosts.gif for information) and further inspect the method of address assignment, you begin to see why it's not such a large number. As it was initially designed, IPv4 assigns addresses in a very inefficient way. A vast number of addresses are not even used. For example, a small organization (needing fewer than 256 unique addresses), would most likely apply for a Class C address (21-bit net number). However, an organization that needed slightly more than 256 addresses, would apply for a Class B address (14-bit net number, 16-bit host number), which would yeild 64,000 possible IP addresses. The largest organizations are assigned Class A addresses (7-bit net number, 24-bit host number), yielding approximately 16 million possible addresses.
Thus, an enormous number of assigned IP addresses are definitely underutilized. Fortunately, a provisional proposal was submitted a few years back to help address this problem for IPv4. One of the actions taken was to permit the assignment of Class C addresses in contiguous chunks to create mini-Class B networks. This divided the potentially unused portions of large Class C addresses into smaller usable segments.
IPv6 was presented to the Internet Engineering Task Force (IETF) in July, 1994. The recommendation was reviewed and accepted by the Internet Engineering Steering Group in November, 1994. Then in September, 1995, the IPv6 protocols were approved and became an IETF Proposed Standard. The IETF is now committed to IPv6. It realizes that the next generation products and technologies will probably look toward IP to provide a structured backbone. Some examples of next generation products are hand-held devices, applications over NetPCs, and networking for home entertainment. IPv4 will not be able to handle the products in store for the future. This market explosion will happen regardless of IPv6, and, if IPv6 is available and stable, it will be used. Most of the ISPs I spoke with were aware of the impending growth, but did not yet have a plan for switching over to IPv6.
I imagine IPv6 addresses will be assigned to providers much in the same way addresses are assigned now. Most providers should be able to accommodate both IPv4 and IPv6 traffic in the near future, but it would be prudent to call your ISP to determine their status on this issue. Also, if you are looking for a provider for the first time or switching providers, IPv6 readiness should be one of the factors involved in your decision. IPv6 will not happen suddenly, destroying your current configuration and all that you have worked for; however, you should learn about it. You will probably encounter it in house first, in a controlled environment.
You may be wondering what happened to IPv5. IPv5 was an experimental protocol known as ST. This protocol was never widely used, in essence, becoming a footnote.
Differences Between IPv4 and IPv6 IPv4 and IPv6 differ in several ways. The predominant difference is the simplified header format (see below for details). Some of the other major differences in IPv6 include the increased network address size (128 bits compared to the 32 bits in IPv4), the absence of header checksums, the introduction of flow labels, and the fact that fragmentation information is an option rather than a requirement for all datagrams.
The simplified header is designed to facilitate efficiency of header processing software. Software can easily be tailored and optimized around the 40-byte (fixed-length) IPv6 headers. This contrasts with IPv4 headers, which are of arbitrary length. Thus, current IPv4-based systems must process headers of varying length, resulting in considerable processing overhead. Multi-byte fields have been realigned to be more efficient in IPv6, and a number of IPv4 fields have been done away with altogether.
When viewing the IPv6 datagram, note that the source and destination addresses are four times larger that the IPv4 counterpart. Four times larger is 128 bits, which is equivalent to 340,282,366,920,938,463,463,374,607,431,768,211,456 possible addresses. IPv6 addresses are represented by sixteen 8-bit segments separated by colons. Those of you who enjoy typing ATM addresses or entering flexlm licenses for third party software will just love IPv6 addresses. A typical address might look like the following:
C87E:34CA:BA55:0000:CDE7:92E4:58D1:1729
Fortunately, the developers of IPv6 have provided some conventions to help those who must work with them. A few addressing conventions are:
A new capability introduced with IPv6 enables the labeling of packets belonging to particular traffic "flows", for which the sender requests special handling. These are called Flow Labels. The flow label, along with a source address, identifies a particular traffic flow in the network. An example of a special request would be a real-time service or a non-default quality of service (QOS). At the time of this article, the definition of flow label is still in a state of flux and thus is subject to change.
IPv6 is security conscience and offers improved security features. Actually, it makes security a mandatory feature of the protocol. IPv6 provides features such as authentication, encryption, and confidentiality, and specifies the MD5 (Message Digest 5) algorithm as the default authentication algorithm. It can use many different encryption algorithms. The default encryption algorithm is DES-CBC (Data Encryption Standard, Cipher Block Chaining model). It helps support confidentiality by using ESP (encapsulating security payload).
The IPv4 and IPv6 datagram formats shown in Figures 1 and 2 were taken from the RFCs. Figure 1 shows the IPv4 format and a brief field description. Figure 2 shows the IPv6 datagram header format.
Migration Expectations When will the IPv4-based Internet run out of addresses? Some resources predict anywhere between 2005 and 2020. If nothing were being done about the situation, it would probably be closer to 2003-2005. However, because of the efforts of the IETF, the Internet Architecture Board, and others, IPv6 will already be employed into the current Internet, thereby alleviating some of the pressure. IPv6 implementers have configured an experimental backbone to test the IPv6 protocol called the 6bone. Its fundamental purpose is to facilitate the evolution and deployment of IPv6. Currently, several systems from different manufacturers are connected to it, and they are working on various connectivity issues. Interoperability between IPv4 and IPv6 is probably one of the most important objectives for migration. The designers built in several migration mechanisms to help facilitate the transition process. Note that IPv4 will not be totally replaced by IPv6 anytime in the near future. There is an enormous IPv4 base that must be protected; IPv6 developers recognize this. The following is a suggested migration path and some mechanisms that may help:
1. Set up a mock network for testing and learning. Setting up a separate network may not be feasible for every system/network administrator because of your particular environment, however, it is highly desirable. I found Linux systems advantageous for this step. I used a Linux system (2.030 kernel) that was sitting around the office and downloaded IPv6 software from:
ftp://ftp.thridwave.net/pub/linux/ \ kernel/IPv6/
- If a mock network is not set up, the following steps still can be applied to an existing network.
- Upgrade DNS server to handle IPv6 - Before nodes can be upgraded to IPv6, the DNS server must be upgraded to IPv6.
- Introduce dual stack systems that support IPv4 and IPv6. Update the DNS records to include these dual stack systems. Nodes and routers can be introduced to the network one at a time. The entire network does not need to be upgraded at the same time. When IPv4 nodes are upgraded, they can continue to use their current addresses.
- Take advantage of the automatic tunneling feature to connect IPv6 segments separated by IPv4 segments. There may be situations when IPv4 compatible addresses are not available, thus automatic tunneling will not work. In these cases, configured tunneling can be used. This requires explicit configuration at the IPv4 entry point and is more work, but does offer a solution.
- Use the header translation mechanism to reach IPv4-only nodes. By providing a way to convert the older addresses to and from the new format, IPv6 can communicate directly with IPv4 hosts. This will protect the huge investment currently seen in IPv4 networks.
ConclusionIPv6 is an essential part of the next generation Internet. IPv6 implementation efforts are underway by many vendors. The designers are aware of its implications and have done well in communicating them to the ITEF. Several ISPs are actively participating in the upgrade process and are involved with testing 6bone. System and network administrators should become familiar with IPv6 as soon as possible and learn how it differs from IPv4. The more you know about the subject, the better equipped you are to assess and manage it.
Additional Resources
RFCs http://ds.internic.net/rfc/rfc791.txt - IPv4 Specification
http://ds.internic.net/rfc/rfc1883.txt - IPv6 Specification
http://ds.internic.net/rfc/rfc1884.txt - IPv6 Addressing Architecture
http://ds.internic..net/rfc/rfc1886.txt - DNS Extensions to Support IPv6
http://ds.internic.net/rfc/rfc1933.txt - Transition Mechanisms for IPv6 Hosts & Routers
http://ds.internic.net/rfc/rfc1971.txt - IPv6 Stateless Address Autoconfiguration
http://ds.internic.net/rfc/rfc1972.txt - A Method For The Transmission of IPv6 Packets Over Ethernet Networks
Informative Web sites: http://playground.sun.com/pub/ipng/html/ipng-main.html - A good IPv6 Resource Page
www.ietf.org/html.charters/ipngwg-charter.html - IPng Working Group Charter
www.visc.vt.edu/ipv6 - Virginia Tech IPv6 Testbed
www.6bone.net - 6Bone Home Page
http://docs.bit.ternopil.ua/Incoming/FAQ/IPv6/linux-ipv6.faq-5.html - Linux Reference
Mailing Lists
IPng working group - Send email to: majordomo@sunroof.eng.sun.com with "subscribe ipng" in the body portion of the message. An archive can be found in the IETF directories at: cnri.reston.va.us.
6Bone Mailing List - Send email to: majordomo@isi.edu with "subscribe 6bone" in the body portion of the message.
Books IPng, Internet Protocol Next Generation by Scott O. Bradner, Addison-Wesley.
IPng and the TCP/IP Protocols, Implementing the Next Generation Internet By Stephen A. Thomas, John Wiley & Sons, ISBN: 0471130885.
Some vendors and organizations that have begun IPv6 development:
DEC
3Com
IBM
Silicon Graphics
Bay Networks
Siemens
SUN
Novell
CISCO
Linux
NRL
Hitachi
Telebit
Ipsilon Networks
UUnet
Apple
Microsoft
AT&T
NIST
NASA
About the Author
Thom Garrett has been inolved in various aspects of system/network installation and administration for 12 years. He received a B.S. in Mathematics/Computer Science from Virginia Commonwealth University. He is currently employed at Digital System Resources, Inc located in Fairfax, Virginia, where he is Manager of Computer Services. He can be reached at: tgarrett@dsrnet.com.
|