IPv6: At the Starting Line
Articles and Tips:
01 Apr 1999
Many experts predict that Internet Protocol version 6 (IPv6), also known as Internet Protocol next generation (IPng), is still years away from widespread adoption. (See Bob Metcalfe's "From the Ether," InfoWorld, May 18, 1998. You can download this article from http://www.infoworld.com/cgi-bin/displayNew.pl?/metcalfe/980518bm.htm.) If these experts are right, why should you be thinking about IPv6 now? After all, you probably haven't experienced any difficulty with the old IP (now commonly called IPv4).
Although IPv6 may be a few years away from rendering IPv4 obsolete, Internet Technology (IT) experts such as Prashant Shukla, NetWare 5 product manager for Novell Inc., say the time for IPv6 is definitely coming. "The fact of the matter is IPv6 has to come," Shukla says. "There's no choice in this." IPv6 is necessary, Shukla explains, because IPv4 is no longer able to meet the demands of the rapidly expanding Internet.
The Internet Engineering Task Force (IETF)--specifically its Internet Architecture Board (IAB)--agrees that IPv6 is necessary to remedy the inadequacies of IPv4, which include too little address space and an inherent lack of security. The IETF isn't alone in its support of IPv6: IT industry leaders including Novell, Microsoft, NEC, and Cisco are also committed to the future of IPv6. In fact, IPv6-enabled products by IT companies such as Cisco are already on the market.
In other words, if you haven't given much thought to learning more about what IPv6 is, why it is necessary, and how best to go about upgrading your network to accommodate IPv6, it isn't too early to start. This article introduces you to the format of IPv6 addresses and to the different types of IPv6 addresses that are available and their purposes. In addition, this article explains the following:
The way IPv6 address assignments make routing IPv6 addresses easy
The structure and purpose of IPv6 packet header extensions
Your options for converting an IPv4 network to IPv6
IPV6 ADDRESSES WIN 128-32
Who could have foreseen that IPv4's 4,294,967,296 unique addresses would prove to be inadequate? Certainly not the handful of network researchers who helped design IPv4's 32-bit addressing format in the 1970s. By 1995, however, it was clear to IT professionals that IPv4's more than four billion addresses would be used up before the first decade of the 21st century. To avert the impending address shortage, the IETF went to work on a new, improved Internet protocol--one that would, among other things, provide a seemingly unlimited number of unique Internet addresses.
To solve this address shortage, the IETF approved IPv6 as a replacement to IPv4. IPv6's 128-bit addressing format provides 40,282,366,920,938,463,463,374,607,431,768,211,456 addresses--that's well over one undecillion addresses. According to Metcalfe's "From the Ether," one undecillion addresses translates to "more than a thousand IPv6 addresses for every square meter on the surface of planet Earth."
The new IPv6 addresses look different than the IPv4 addresses that you are used to seeing. (For a detailed discussion of IPv4 addresses, see "Choosing IP Addresses for Your Network," NetWare Connection, Feb. 1997, pp. 20-26 You can download this article from http://www.nwconnection.com/feb.97/ipadd27.) Unlike IPv4 addresses, which consist of a series of four decimal numbers connected by periods, IPv6 addresses consist of a series of eight hexadecimal numbers separated by colons. For example, a typical IPv4 address would appear as 123.45.234.56. In contrast, a typical IPv6 address would appear as 2DF1:0000:0000:5EA8:ACDE:4823:0067:ABCD.
To make IPv6 addresses easier to write, the IETF has approved a few alternative ways to represent these addresses. One alternative is to abbreviate a series of four zeros by using a single zero and to eliminate leading zeros within a series. For example, you could write the IPv6 address above as 2DF1:0:0:5EA8:ACDE:4823:67:ABCD.
Another alternative is to replace a series of consecutive zeros with a double colon. For example, the IPv6 address above can be further shortened to 2DF1::5EA8:ACDE:4823:67:ABCD. However, you can use only one double colon per IPv6 address. (For more information about how to write legal IPv6 addresses, download Request for Comments [RFC] 2373 from http://ietf.org/rfc/rfc2373.txt.)
In binary terms, each of the four numbers in IPv4 addresses are eight bits long and range from 00000000 (0) to 11111111 (255 in decimal terms). In contrast, each of the eight numbers in IPv6 addresses is sixteen bits long and ranges from 0000000000000000 (0) to 1111111111111111 (FFFF in hexadecimal terms, or 65,535 in decimal terms).
With IPv4, each host, or node, on the Internet (or on a TCP/IP intranet) is assigned a unique IPv4 address. With IPv6, each host is assigned multiple addresses. For example, an IPv6 host has, among other assigned addresses, a unique global address, which can be reached from anywhere on the Internet, and a link-local address, which can be reached only from other hosts on the same link. (For more information about IPv6 local-use addresses, see RFC 2373.)
IPv6's much larger address space and the ability to assign multiple IPv6 addresses to network hosts are just two ways IPv6 differs from IPv4. Additional features of IPv6 include the following:
Format prefixes
Hierarchical addressing
Fixed-length headers
Extension headers
Neighbor discovery and automatic addressing
FORMAT PREFIXES
The leading bits of an IPv4 address designate its format prefix. In contrast, before the adoption of Classless InterDomain Routing (CIDR) the leading bits of an IPv4 address designated the address class. CIDR is the protocol that is currently used to mitigate both the wasted address spaces and the inordinately large routing tables resulting from IPv4's class-based addressing protocol. (To review Pre-CIDR IPv4 class addresses, see "Choosing IP Addresses for Your Network," NetWare Connection.)
The leading bits of an IPv4 address determine the type of address that follows. Likewise, the format prefix of an IPv6 address indicates the type of IPv6 address that follows. The format prefix designates that the IPv6 address is one of the following types of addresses:
Unicast address
Anycast address
Multicast address
Reserved address
Unassigned address
Unicast Address
A unicast address is the address for a single network node. A packet sent to a unicast address goes only to the node to which the address belongs. The format prefix for unicast addresses is 001.
Anycast Address
Unlike unicast addresses, which can be assigned to any type of node, anycast addresses presently can be assigned only to routers. In addition, anycast addresses identify a set of nodes within a given topological region. For example, all of the routers on a particular network can be defined as a set of nodes. You can then assign these nodes a shared anycast address in addition to their unique unicast addresses. A packet sent to this anycast address is routed to the node that the network routing protocol determines is nearest to the sending node.
Anycast addresses have several uses. For example, you can use an anycast address in an IPv6 routing header to send a time-sensitive packet (such as audio or video files) to the closest host that shares that anycast address. You can also use an anycast address to identify the set of routers for a specific subnet. (The IETF defines a required anycast address format for a set of subnet routers. For more information about anycast addresses for subnet routers, see RFC 2373.) The format prefix for anycast addresses (001) is the same as the format prefix for unicast addresses (001).
Multicast Address
Like anycast addresses, multicast addresses belong to a set of nodes rather than to a single node. For example, you can assign routers a shared multicast address and an anycast address. However, each node that shares a multicast address receives all of the multicast packets that are sent to that address.
Multicast addresses also have multiple uses: For example, multicast addresses are used as part of the IPv6 Stateless Address Autoconfiguration protocol, which allows hosts on intranets or on the Internet to obtain or to create their own IPv6 addresses. (Stateless Address Autoconfiguration is explained later in this article.) The format prefix for multicast addresses is 11111111 or, in hexadecimal terms, FF. (For information about how to assign IPv6 multicast addresses to nodes on your company's network, see RFC 2373.)
Reserved Address
The IETF has reserved several predefined multicast addresses. These addresses are reserved for purposes such as news, music multicasts, and experimental purposes. (For more information about reserved multicast addresses, download RFC 2375 from http://ietf.org/rfc/rfc2375.txt.)
In addition to the predefined multicast addresses reserved by the IETF, the following addresses are reserved:
The IPv6 Unspecified Address. Each of the 128 bits in the IPv6 unspecified address have a value of zero. (The hexadecimal representation of this address is 0:0:0:0:0:0:0:0.) Because this reserved address is actually the absence of an address, the unspecified address should neither be assigned to a node nor be used as a packet's destination. However, hosts can use this address as a source address to initialize themselves before they have configured their own unicast addresses.
The Loop Back Address. The loop back address is another reserved address that should not be assigned to a node. (The hexadecimal representation of this address is 0:0:0:0:0:0:0:1.) Packets that contain the loop back address as a destination code come back to the node from which the packet was sent. For example, you can use the loop back address to test network connections.
Addresses Reserved for IPX Packets. IPv6 includes two options for integrating IPX networks with IPv6 networks. The first option uses an address space that is reserved for IPX packets. This reserved address space enables enterprises that use the IPX network layer protocol to map their IPX addresses to IPv6 addresses. These enterprises can then send and receive packets over the Internet. The format prefix that defines these mapped addresses is 0000010. The bits following this prefix contain the mapped 80-bit IPX address.
The second option for integrating IPX networks with IPv6 networks is to tunnel IPX packets in IPv6 packets. The IETF has defined an IPv6 header extension specifically for this purpose. (This option is discussed later in the article.)
Addresses Reserved for Network Service Access Point (NSAP) Packets. To facilitate the mapping of NSAP addresses to IPv6 addresses, the IETF has reserved the set of addresses with a format prefix of 0000001. Unlike IPv6 addresses, which belong to organizations rather than a physical location, NSAP addresses describe the physical locations at which a network is attached to the Internet. (For more information about the NSAP addressing protocol, download RFC 941 from http://www.ietf.cnri.reston.va.us/rfc/rfc0941.txt.)
Unassigned Address
According to RFC 2373, the IPv6 addresses to which format prefixes have been assigned--including unicast, anycast, multicast, and reserved addresses--account for only 15 percent of the total number of addresses available. The IETF has not assigned format prefixes to the remaining 85 percent of addresses. These unassigned addresses are set aside for future use.
HIERARCHICAL ADDRESSING
The bits following the format prefix in an IPv6 address contain information that allows IPv6 addresses to be routed hierarchically, just as country codes and area codes allow telephone calls to be routed hierarchically. For example, the bits following the format prefix of unicast addresses are divided among the following hierarchically structured identifiers:
Top-Level Aggregation Identifiers (TLA IDs)
Next-Level Aggregation (NLA) IDs
Site-Level Aggregation (SLA) IDs
Interface IDs
TLA IDs function much as country codes function within the telecommunication system. Similarly, NLA IDs function much as area codes function, SLA IDs function much as local zone codes function, and Interface IDs function much as the digits that identify individual telephone numbers.
This hierarchical design significantly reduces the number of entries routing tables must contain. For example, TLA routers need to know only the addresses of the other TLA routers on the Internet and of the NLA routers beneath them. (See Figure 1.) In contrast, IPv4 class-based addressing (without CIDR) requires top-level routers to have entries for every network on the Internet.
Figure 1: Hierarchical addressing makes assigning and routing IPv6 addresses more efficient.
TLA IDs
The thirteen bits that follow the format prefix of unicast addresses contain the TLA ID. Representing 8,192 available addresses, these thirteen bits are assigned by Internet Assigned Numbers Authority (IANA) designated registries. The TLA ID is used to identify the relatively small number of large, long-haul backbone providers (such as AT&T) that exist worldwide. (For more information about the criteria for assigning TLA ID addresses, download the IETF draft "Proposed TLA and NLA Assignment Rules" from http://www.6bone.net/tla-assign-05.txt.)
The eight bits that follow the TLA ID space are reserved either for TLA expansion or to add to the number of addresses in the 24-bit space that follows this eight-bit reserved segment.
NLA IDs
The 24-bit space that follows the eight-bit reserved segment contains the NLA ID. The NLA ID is used to identify the service providers whose networks are attached to TLA networks. Each IPv6 provider is responsible for assigning the next-lower addressing sequences. Therefore, TLA providers are responsible for assigning the 8,388,608 NLA addresses available within the 24-bit NLA ID space.
SLA IDs
The NLA providers, in turn, assign single addresses or blocks of addresses to individuals and companies from the 16-bit SLA ID address space that follows the NLA ID space. NLA providers can also subdivide their own 24-bit address allocation. They can then assign blocks of address space to smaller service providers. In addition, NLA providers can allocate part of their 24-bit address space to large organizations, such as government organizations, that require more than the 65,535 addresses available within the 16-bit SLA ID space.
Finally, companies that are assigned blocks of SLA ID addresses are responsible for assigning those addresses to networks and subnetworks within their organizations. IPv6 subnet prefixes are allocated out of the SLA address space. As with IPv4 subnet prefixes, IPv6 subnet prefixes are associated with one link. Unlike IPv4, however, IPv6 allows you to assign multiple subnet prefixes to any given link. For example, the subnet prefix in a link's anycast address may be just one of the subnet prefixes that identifies that link.
Interface IDs
The last 64 bits of the IPv6 128-bit address space are called the Interface ID. In IPv4, each host is assigned a unique number out of the total number of host addresses available within a given class-based address. In IPv6, on the other hand, interface addresses are assigned according to either the new Institute of Electrical and Electronics Engineers (IEEE) Equipment Identifier (EUI) 64 identifier or the old IEEE EUI-48 identifier. (EUI identifiers are also known as Medium Access Control [MAC] addresses.)
The new IEEE EUI-64 format is a 64-bit series of numbers. The first 24 bits in an EUI-64 number identify the manufacturer of a particular interface, and the last 40 bits identify the device itself.
For example, the first 24 bits of a router's EUI-64 identifier identify the company that manufactured the router (such as Cisco). The IEEE assigns 24-bit manufacturer numbers, and the manufacturer then assigns the following 40 bits of the router's EUI-64 identifier. (For more information about EUI-64 identifiers, download http://www.standards.ieee.org/regauth/oui/tutorials/EUI64.html. For information on creating EUI identifiers for IPv6, download RFC 2373, Appendix A at http://ietf.org/rfc/rfc2373.txt.)
FIXED-LENGTH HEADERS
Implementing a hierarchical addressing structure is just one way that IPv6 simplifies routing. Unlike IPv4, which uses variable-length packet headers, IPv6 uses fixed-length packet headers of 40 bytes. These fixed-length headers allow routers to parse packets more efficiently.
IPv6 further simplifies routing requirements by using a smaller number of header fields. IPv4 packet headers contain 14 fields; IPv6 packet headers contain only eight fields. (See Figure 2.)
Figure 2: IPv6 significantly reduces and standardizes the number of fields in packet headers from the IPv4 format.
Since IPv6 packets have fixed-length headers, the old IPv4 header length field is obviously no longer needed. Other eliminated IPv4 fields include the fragment offset, identification, flags, and header checksum fields.
The most significant deletion is the IPv4 header checksum field, which contains a computation based on the total number of bits in each particular IPv4 header. Each time a router receives an IPv4 packet, the router recomputes the number of bits the header contains.
The router then checks its computation against the computation contained in the IPv4 header checksum field. If these two computations are identical, the data contained in the IPv4 header is most likely uncorrupted. In this case, the router forwards the packet. If the two computations are not identical, the router assumes the IPv4 packet is corrupted and discards it.
According to the IAB's Internet draft titled "The Case for IPv6," the IPv4 header checksum field is an unnecessary field that "has caused reduced performance in today's Internet." Because corrupted packets can be detected at both the data-link layer of the Open Systems Interconnection (OSI) model and the transport layer of the OSI model, routers do not need to check for bad packet headers. Any bad packets the data-link layer misses, the transport layer will catch. (You can download "The Case for IPv6" from http://www.6bone.net/case-for-ipv6.txt.)
EXTENSION HEADERS
To further enhance router performance, IPv6 transfers the functions available through the IPv4 options field to separate IPv6 headers, called extension headers. The IPv4 options field presents options to routers in a single, variable-length field. In contrast, IPv6 extension headers present selected options to routers in separate header fields, allowing routers to process the packets more efficiently.
IPv6 extension headers follow the primary (40-byte) header and precede the protocol header and the payload fields in IPv6 packets. (The payload fields contain the data packet being transmitted. Normally, IPv6 payload fields can accommodate up to 64 KB of data. See Figure 2.) Each extension header ends with a "next header" field that indicates whether the field following the extension header contains another extension header, the protocol header, or the payload field. (For a complete list of currently approved IPv6 extension headers, see "The Case for IPv6.")
The IETF has defined a variety of extension headers, including the following:
Hop-by-hop extension header
Authentication extension header
Encapsulating Security Protocol (ESP) extension header
IPX-in-IP extension header
Hop-by-Hop Extension Header
Because hop-by-hop extension headers are read by every router in an IPv6 packet's forwarding path, this extension header must be placed directly behind the primary IPv6 header. The hop-by-hop extension header has several uses. For example, this extension headers allows you to use the Router Alert option, which instructs all routers in an IPv6 packet's forwarding path to intercept and parse the contents of the entire packet.
You can choose this option if you are sending a Resource Reservation Protocol (RSVP) packet. RSVP instructs routers to reserve the network resources--such as maximum bandwidth or maximum delay--that are necessary to support bandwidth-intensive packets, such as those containing audio and video data, or delay-sensitive packets, such as real-time communications. (For more information about RSVP, visit http://www.micom.com/WhitePapers/rsvp/wprsvpte.htm.)
The hop-by-hop extension header also allows you to use the Jumbogram option. The Jumbogram option allows you to send packets that contain payloads larger than the 64 kilobyte payload normally allowed in IPv6 packets. (For more information about the hop-by-hop Jumbogram option, visit http://ietf.org/internet-drafts/draft-ietf-ipngwg-jumbograms-00.txt.)
In addition, the hop-by-hop extension header provides Quality-of-Service (QoS) features. A protocol can then request the specific capabilities it needs to perform its functions from the IP network on which the protocol is operating.
Authentication Extension Header
IPv6 headers also provide enhanced security. Two of IPv6's header extensions, the Authentication Header (AH) and the Encapsulating Security Protocol (ESP) Header, work either together or separately to keep data packets secure as they travel across your company's network or the Internet.
The IPv6 AH extension header uses secret keys to authenticate the source of the packets you receive via hosts on your company's network or on the Internet. These secret keys are strings of alphanumeric characters that you configure authorized network hosts to recognize.
To prevent spoofing on your company's network, you can configure network hosts to recognize a secret key. You can then use an IPv6 AH extension header that uses this secret key to ensure that the information contained in IPv6 packets, such as requests for access to network resources, is from an authorized source. (Spoofing is the practice of configuring an unauthorized host to impersonate an authorized host to gain access to resources such as your company's confidential databases.)
The AH extension header also uses the secret key and the entire contents of the IPv6 packet to create a message digest. A message digest is a mathematical function (such as IPv6-approved Message Digest version 5 algorithm [MD5]) that represents the entire contents of a data packet as a single number.
This number is transmitted with the data packet. The message digest is recomputed by the host that receives the data packet. If the two message digest numbers are identical, the receiver can be reasonably sure that the data contained in the packet is uncorrupted.
The IPv6 AH extension header can protect your network from spoofing and from attempts to modify the data you receive. However, the IPv6 AH extension header cannot protect your company's network from snooping, which is the practice of unobtrusively reading the contents of data packets as they travel across the network or the Internet.
Snooping can risk the security of your company's most confidential data. To protect your company's information from snooping devices as it travels over the network or over the Internet, you can implement the IPv6 ESP header extension.
ESP Extension Header
The ESP extension header increases the security of your company's data by allowing you to use various encryption algorithms such as U.S. Data Encryption Standard (DES) in Cipher Block Chaining (CBC) mode and RC5. (DES-CBC is the IPv6 default encryption algorithm. RC5 is an encryption algorithm that was developed by Ron Rivest of RSA Laboratories Inc. For more information about DES-CBC, see "Securing IP," SunWorld, June 1998. You can download this article at http://www.sunworld.com/swol-06-1998/swol-06-ipsec.html. For more information about the RC5 encryption algorithm, visit http://www.uni-siegen.de/security/krypto/rc5-rsainfo.txt.)
You can use IPv6 ESP headers to send snoop-proof IPv6 packets in one of two modes: transport mode or tunneling mode. In transport mode, only the transport-layer header (for example, the TCP header) and the payload (the actual data being transmitted) are encrypted. In tunneling mode, a dummy IPv6 header that contains neither the packet's source nor its destination address is placed in front of the ESP header, which in turn is placed in front of the original IPv6 header. Everything behind the ESP header is encapsulated and encrypted. As a result, the entire contents of the original packet are hidden from packet-sniffing devices.
For example, you can use the ESP tunneling mode to create a security tunnel between the firewall at a remote site and the firewall at your company's headquarters. After a packet transported in tunneling mode is inside a firewall, the dummy IPv6 header and the leading ESP header are discarded. The entire original packet is then visible.
Because all portions of the IPv6 packet that follow the ESP extension header are encapsulated and encrypted and, therefore, unavailable to routers, you must insert ESP extension headers with care. For example, you should never put an ESP extension header in front of a hop-by-hop extension header because the packet will not be parsed by each router along its destination path as you intend. Because the information behind the ESP extension header, including the hop-by-hop extension header, will be encrypted, routers cannot be signaled to provide options such as RSVP. (For more information about the recommended use of IPv6 extension headers, see "The Case for IPv6.")
IPX-in-IP Extension Header
In addition to providing a way to transport confidential information via a security tunnel, IPv6 provides a way to transport IPX packets via IPv6 tunnels. The IPX-in-IP header extension allows you to transport IPX packets by encapsulating those packets within an IPv6 packet. When the IPX packet reaches the destination IPX network, the encapsulating IPv6 packet is discarded, and the IPX packet is visible to the IPX network.
DISCOVERY AND AUTOMATIC ADDRESSING
Autoconfiguration is one of the obvious advantages IPv6 has over IPv4. Autoconfiguration is a protocol that allows IPv6-enabled hosts to automatically configure and reconfigure their IPv6 addresses.
To automatically configure addresses, an IPv6-enabled host first configures an address for itself using a local network prefix and the host's own link address. (A host's link address is the physical address that identifies the host's Ethernet, Token Ring, or LocalTalk controller board.) The host then uses a protocol called Neighbor Discovery to determine whether or not this link address is unique.
IPv6 Neighbor Discovery is a function of Internet Control Message Protocol version 6 (ICMPv6), a protocol that provides services, such as error reporting, for protocols that operate at the network layer of the OSI model. Using Neighbor Discovery, a host on an IPv6 network can discover whether or not its self-configured link address is unique: The host simply sends an ICMP Neighbor Solicitation multicast message to all of the hosts on the local link.
If the originating host receives no reply, its link address is unique. If another host on this local link recognizes the new self-configured link address as its own link address, this host sends the originating host an ICMP message called a Neighbor Advertisement message. The Neighbor Advertisement message informs the originating host that the new self-configured address is not unique. The originating host then configures another address and sends a new multicast Neighbor Discovery message to the hosts on the link.
When the host finds a unique self-configured link address, the host then sends another Neighbor Discovery multicast message that includes the host's official link address as a source address. However, rather than sending a message to all of the hosts on its local link, the host sends the message to the router that connects that link to other network links.
When an IPv6-enabled router receives a Neighbor Discovery message from a host, the router sends that host a unicast message called a router advertisement. A router advertisement includes information such as a valid range of addresses for the subnet to which the router and host are attached. The router also tells the host whether it must use stateful or stateless autoconfiguration.
Stateful configuration requires a Dynamic Host Configuration Protocol (DHCP) server to assign an IPv6 address to the host. If the router instructs the host to use stateful autoconfiguration, the host contacts a DHCP server with a request for a valid IPv6 address. DHCP servers assign valid IPv6 addresses dynamically--that is, each time a host makes a request, the DHCP server assigns the host IPv6 addresses from a pool of IPv6 addresses. (For more information about how DHCP works in an IPv4 environment, see "NDS and DHCP: Configuring DHCP for a Complex Environment." You can also download RFC 2131 at http://ietf.org/rfc/rfc2131.txt.)
If the router instructs the host to use stateless autoconfiguration, the host uses information contained in the router's advertisement to generate its own address. This router-supplied information includes the numbers of the subnets associated with the host's link. The host then uses its own EUI-64 identifier to generate an interface ID for itself. Finally, the host appends the interface ID it generates to the subnet information supplied by the router. (For more information about stateless autoconfiguration, see RFC 2462 at http://ietf.org/rfc/rfc2462.txt.)
Autoconfiguration allows your company to change service providers without having to manually reconfigure addresses for every node on your company's network. Naturally, the bigger your company's network, the more time and money address autoconfiguration can save.
Address autoconfiguration also makes using roaming mobile hosts, such as your laptop or Internet-enabled cellular telephone, easier. Using autoconfiguration, a roaming mobile host can configure a valid IPv6 address for itself, regardless of the network to which it is temporarily attached. Using this current, temporary IPv6 address, the roaming mobile host can then ask a router on its home network (called a home agent) to forward packets to this newly configured address. In fact, technologies such as roaming mobile hosts may prove to be the push that starts the IPv6 ball rolling.
IT'S NEVER TOO EARLY TO MAKE A PLAN
There are a few good reasons why IPv6 is not already in wide use on the Internet. First, protocols such as Network Address Translation (NAT), DHCP, and CIDR have temporarily eased concerns about the scarcity of remaining IPv4 addresses. Thanks to these address-saving protocols, there are still 1.6 billion unallocated IPv4 addresses. (NAT allows you to make the most of hard-to-get publicly assigned Internet address assignments by mapping the privately assigned IPv4 addresses you've given to hosts on your intranet to the publicly assigned IP address of a proxy server that interacts with the Internet. This proxy server then makes Internet connections on behalf of the non-publically assigned addresses behind it.)
Second, the change from IPv4 to IPv6 will entail upgrading everything from the government-owned Domain Name System (DNS) servers at the Internet's backbone to the routers that deliver packets from one subnetwork to another. (DNS servers map domain names to their Internet-unique addresses, a process that enables routers and switches to deliver packets to the appropriate network.)
Despite the arguments for sticking with IPv4, it's only a matter of time before IPv4's limitations make change necessary. In other words, the question isn't whether or not to upgrade your company's network to accommodate IPv6, but when and how you should upgrade your company's network.
Wait and Hurry Up
Since time-frame estimates for IPv6's widespread adoption range from two or three years (see "Light at the end of the IPv6 tunnel," PC Week, Jan. 26, 1998) to as long as a decade (see "From the Ether"), you should have sufficient time to determine the best way to upgrade your company's network from IPv4 to IPv6. Your choices for managing this upgrade are simple: You can wait until the majority of Internet components (such as the DNS servers that sit on the Internet backbone and your Internet Service Provider's [ISP's] equipment) are IPv6-enabled and then upgrade to IPv6 all at once, or you can migrate to IPv6 gradually.
If you opt to wait until nearly everyone on the Internet (including your ISP) has upgraded to IPv6, you will probably need to purchase a great deal of IPv6-enabled hardware and software all at once. You will need to replace non-IPv6 compatible routers, switches, operating systems, and applications. Obviously, the more extensive your company's network, the greater the costs will be, both in terms of purchasing necessary equipment and software and in the time and effort it takes to implement this new equipment.
Although a total network overhaul may prove to be unwieldy for large companies with complicated networks, small companies may benefit from this wait-and-see approach. One of the most compelling advantages of waiting to upgrade your company's network is that many IT companies are also taking a wait-and-see approach.
According to "Spreading the IPv6 Gospel: A Tall Order" (PC Week, Nov. 16, 1998), the IPv6 stacks that are currently available for routers and operating systems are "still in development phases." This article goes on to predict that IT companies will iron out the kinks in currently available IPv6-enabled products such as routers and operating systems within the next few years.
However, whether or not you choose to wait until IT companies iron out all the kinks in IPv6-enabled products, the sooner you become familiar with IPv6 in general, the less stress this migration will cause in the long run. In fact, since IPv6-literate network consultants and programmers will almost certainly be in high demand when it becomes necessary to migrate to IPv6--and will therefore demand high prices for their services--having an IT staff that is familiar with IPv6 could save your company money and headaches.
Proceed With Caution
If you decide to migrate to IPv6 gradually, you'll have the luxury of learning IPv6 gradually. In addition, a gradual migration may eliminate late nights of trying to get your company's network up and running to meet either a self-imposed or an externally imposed deadline.
However, making a gradual transition to IPv6 will probably not be painless although IPv6's designers have worked hard to make migrating to IPv6 as easy as possible. For example, early versions of IPv6-enabled hosts and routers will use both an IPv4 stack and an IPv6 stack. These dual stacks will allow you the flexibility to upgrade your network piece-by-piece.
You may put an IPv6-enabled router on one subnetwork and an IPv6-enabled host on an entirely different subnetwork. In this case, the IPv6-enabled router will process both IPv4 and IPv6 packets, enabling IPv4 traffic to flow freely throughout your company's network. The IPv6-enabled host will also process both IPv6 and IPv4 packets, ensuring that IPv4 packets addressed to this host are not discarded. However, IPv4 hosts on your company's network will not be able to process IPv6 packets, and you will need an IPv6-enabled DNS server to send or receive IPv6 packets over the Internet. (For more information about implementing IPv6-enabled DNS servers, see "The Case for IPv6.")
The designers of IPv6 have further facilitated the transition from IPv4 through a process called IPv6 over IPv4 tunneling. With IPv6 over IPv4 tunneling, IPv6 packets can reach IPv6-enabled hosts via IPv4-only networks. For example, if isolated IPv6 hosts need to communicate with one another over an IPv4 network, an IPv6-enabled router on one host's side of the network can encapsulate IPv6 packets and readdress them as IPv4 packets.
These readdressed packets are then able to traverse an IPv4 network as ordinary IPv4 packets do. When the IPv6 packets reach their destination, another IPv6-enabled router removes their IPv4 addresses and forwards them to the IPv6-enabled host to which they were originally addressed.
IPv6 also provides a standard to embed your company's IPv4 addresses in an IPv6 address. You can then continue to use the addresses already configured for your company's network until the transition to IPv6 has progressed and your company's network can readdress itself through autoconfiguration. You can embed an IPv4 address in an IPv6 address by setting all of the bits in the IPv6 address to zero, with the exception of the last 32 bits, which comprise the 32 bits of the original IPv4 address. (See Figure 3.)
Figure 3: To facilitate migration to an IPv6 environment, IPv6 provides a way to embed IPv4 addresses within IPv6 addresses.
If you embed your company's IPv4 addresses in IPv6 addresses until the transition to IPv6 is nearly completed, you will forgo the benefits of using standard IPv6 addresses. However, you will also avoid the necessity of manually defining the IPv4-to-IPv6 mapping procedures that tell your company's IPv6-enabled routers how to tunnel IPv6 packets over IPv4 networks. Instead, these IPv6-enabled routers can automatically tunnel IPv6 packets by converting the 128-bit IPv6 address to a 32-bit IPv4 address and vice versa.
CONCLUSION
Critics of early migration to IPv6 cite the lack of refinement in currently available IPv6 protocol stacks as one reason to adopt a wait-and-see attitude. (See "Spreading the IPv6 Gospel: A Tall Order.") Advocates of IPv6 see the availability of free IPv6 protocol downloads as the logical starting point. (For example, you can download Cisco IPv6 beta software at http://www.cisco.com/warp/public/732/ipv6/download.html.)
Despite these diverse opinions, the widespread deployment of IPv6 may be closer than you think: Out of 20 respondents to a recent Cutter Information Corp. survey on IPv6 awareness, more than 50 percent were aware of IPv6. Furthermore, nearly 25 percent of these respondents reported that they plan to test IPv6 on their company's networks this year. (For more information about this survey, see Cutter Information Corp.'s Corporate Internet Strategies, Sept. 1998. You can also visit http://www.cutter.com/cis/cistoc.htm.) However, only you can decide how soon your company should begin the transition to the IPv6 format.
Cheryl Walton is a writer for Niche Associates, an agency that specializes in editing and writing technical documents. Niche Associates is based in Sandy, Utah.
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.