Internet Protocol Version 6

To many, IPv4 is like a beloved but aging pair of jeans . The knees are patched, the cuffs are fraying, and you sure don't need a belt to keep them up anymore, but they fitmore or less. Getting rid of them means a lot of hassle: going to the mall, trying on a bunch of new pairs, and washing them half a dozen times before they feel right. Who needs that?

The fact is, the Internet is expanding. Besides the routers, servers, PCs, and laptops coming online, devices such as PDAs, cell phones, copier machines, and automobiles are clamoring for IP addresses. And even if the wild-eyed prophecies of Internet-enabled toasters don't pan out, eventually the buttons are going to pop on version 4's 32-bit address space.

Yet address scarcity is just one argument for the next generation of IP. The standard's architects tout other benefits of version 6: improved routing efficiency, simplified administration, and the opportunity to tailor the protocol to the new demands of modern global communications.

This tutorial examines the basics of the next generation of IP. It reviews the number of new addresses, explains the shape of an IPv6 packet, describes how IPv4 and IPv6 devices and networks will interoperate , and briefly examines IPv6's new security features.

What's Your Address?

IPv4, with its 32-bit address space, allows for approximately 4.2 billion addresses. While this is a huge number, the protocol's developers didn't anticipate how quickly the Internet would grow. Techniques such as Network Address Translation (NAT) and Classless Interdomain Routing (CIDR) will extend IPv4's wearability for years to come, but sooner or later the Internet will outgrow IPv4.

IPv6's 128-bit address space promises more legroom than the mind can comfortably comprehend. Just how many addresses is that? Approximately 3.4x1038. If that's too abstract, try this on for size : The new version allows for 6.5x1023 (or 655,570,793,348,866,943, 898,599) addresses for every square meter of the Earth's surface.

Besides having a far greater quantity of addresses, IPv6 also departs somewhat from IPv4's familiar " dotted quad" format (for example, 193.10.10.154). Instead, IPv6 uses hexadecimal notation, and colons replace the periods. A mock example shows the structure of the address: FEDC:BA98:7654:3210:FEDC:BA98:7654:3210.

Check Your Head

While the IPv6 header has twice as many bytes as an IPv4 header (40 bytes vs. 20 bytes), IPv6 boasts a streamlined header format. As Figure 1 shows, the IPv6 header has eight fields to IPv4's 14. IPv6 removes and repurposes several of the header fields in IPv4 to make packet processing more efficient.

Figure 1: The IPv6 packet header has fewer fields than its predecessor for more efficient processing. (Field lengths are not drawn to scale.)

Here's how the two headers stack up. The Version field is unchanged between the two protocols. IPv4's Internet Header Length, Type of Service, Identification, Flags, Fragment Offset, and Header Checksum fields are dropped. The Total Length, Time to Live (TTL), and Protocol fields have new names and slightly redefined functions in IPv6. The Option field in IPv4 has been removed from the header and repurposed as an extension capability. Lastly, IPv6 includes two new fields: Class and Flow Label. The following section examines each of the header fields in an IPv6 packet.

Version: The Version field is still 4 bits long and identifies the version number of the protocol.

Traffic Class: This 8-bit field permits packets to be assigned different classes or priorities. It's similar to the Type of Service field in IPv4 and should allow for differentiated services.

Flow Label: The Flow Label field is new to the IPv6 header. A source node uses this 20-bit field to request special handling (that is, better than best-effort forwarding) for a specific sequence of packets. Real-time data transmissions such as voice and video can use the Flow Label field to help ensure QoS.

Payload Length: This 16-bit field tells the length of the payload. Unlike the Total Length field in an IPv4 packet, the value in this field doesn't include IPv6's 40-bit header; only the extensions and data that follow the header are tallied. Because the field is 16 bits, it can indicate a data payload of up to 64Kbytes. For larger payloads, a "jumbogram" extension is available.

Next Header: This 8-bit field approximates the Protocol field in IPv4, but with some differences. In IPv4 packets, a Transport-layer header such as TCP or UDP always follows the IP header. In IPv6, extensions can be inserted between the IP and Transport-layer headers. Such extensions include authentication, encryption, and fragmentation capabilities. The Next Header field indicates whether a Transport-layer header or an extension follows the IPv6 header.

Hop Limit: This 8-bit field replaces the TTL field in IPv4. It prevents a packet from being forwarded forever by discarding the packet after a specified number of router hops. Each router that a packet traverses reduces value in the Hop Limit field by one. IPv4 uses a time value, subtracting one second from the TTL field for each router hop. IPv6 simply swaps out a time value for a hop value.

Source Address: This field identifies the source of the originating host. It is 128 bits.

Destination Address: This field identifies the recipient of the transmission. It is 128 bits.

Networkers may be surprised to see the checksum and fragmentation fields missing from IPv6's header. The packet header checksum was discarded to improve router efficiency. While errors in the packet header are still possible, the new protocol's designers decided that the risk was acceptable, especially considering that the Data-Link and Transport layers (just below and above the IP layer) check for errors.

As for fragmentation, IPv6 does allow packets to be split, but the process happens in a header extension, rather than in the header itself. In addition, an IPv6 packet can be broken up only by the source node and reassembled at the destination node intervening routers aren't permitted to break up or reassemble a packet. This fragmentation feature is intended to reduce processing overhead in transit, and assumes that the frame sizes of today's networks are large enough that most packets won't require fragmenting.

If an IPv6 packet must be divided, the source node determines the Maximum Transmission Unit (MTU) of each link. One way it does this is by sending a test packet to the destination address. If the test packet is too large for a particular link, that link will return an Internet Control Message Protocol (ICMP) message to the source node, which will scale down the packet size.

The extension mechanism that enables fragmentation (among other options) represents a significant redesign feature of IPv6. It replaces the Options field in IPv4, which allows enhancements such as security capabilities and source routing choices in the IPv4 packet.

Rather than pack such enhancements into the IPv6 header, the architects designed extensions to be inserted between the IP header and the higher-layer protocol header (see Figure 2). This enables packets without extensions to be processed more quickly, and also provides a host of extensible options, such as encryption, authentication, fragmentation, source routing, and hop and destination options, among others. As mentioned ealier, such extensions count toward the packet's overall payload length.

Figure 2: IPv6 uses extension headers to provide a host of options, such as fragmentation and source routing. The extension headers, which replace the Options field in IPv4, are inserted between the IP header and the Transport-layer header.

Integrating V4 And V6

While it's pleasant to imagine one grand and all-encompassing wardrobe change from version 4 to version 6, both versions must interoperate, and it will likely be yearsif everbefore IPv6 entirely replaces IPv4. Thus, transition methods have been put forward to ensure that IPv4 packets aren't stiffed by IPv6 devices and vice versa. Those methods are dual stacks and tunneling.

The dual stack proposition is simple. New IPv6 devices will be backward-compatible with IPv4, and IPv4 devices can be programmed with both IPv4 and IPv6 stacks to process respective packets appropriately. Hosts with dual stacks can send and receive both IPv4 and IPv6 data, and routers with dual stacks can forward either kind of packet.

The tunneling mode sends packets between two IPv6 domains over an IPv4 network. To do so, a dual-stack node encapsulates an IPv6 packet with an IPv4 header. This encapsulated packet can then be routed over an IPv4 networkthe tunneluntil it reaches the second IPv6 domain. A second node strips away the IPv4 header and processes the packet accordingly .

Tunnels can be configured manually or automatically. A manual configuration requires a network administrator to define IPv4-to-IPv6 address mappings at the tunnel endpoints. While IPv6's 128-bit address can normally be used on either side of the tunnel, the router at the tunnel entry point must be manually configured to define which IPv4 address will cross through the tunnel.

Automatic configuration uses an IPv4-compatible address, which is a 32-bit address padded out with zeros to reach 128 bits. If an IPv6 node uses the compatible address, the router at the tunnel entrance simply removes the extra zeros to reveal the true IPv4 address. Once the packet passes through the tunnel, the node at the tunnel exit removes the IPv4 header to reveal the actual IPv6 address.

Packet Protectors

IP datagrams can be intercepted, and the data read and modified. Thus, IPSec protects IP packets through authentication and encryption. Because IPSec was developed some time after IPv4, support for IPSec has to be grafted onto IPv4 packets. By contrast, IPv6 supports IPSec by design, through extension headers.

Authentication header extensions can help administrators verify that packets are indeed coming from the source address in the header. This should help prevent address spoofing, a technique in which an attacker forges the source address to make the packet appear as if it's coming from a legitimate or trusted location.

The encryption extension, known as the Encapsulating Security Payload (ESP) service, renders the packet's payload data illegible unless the recipient has the proper key to unscramble the data. Encryption provides a measure of confidentiality and data authentication. Ad- ministrators can choose to encrypt only the transport and data payload of a packet or the entire packet, including headers and extensions. If the entire packet is encrypted, an additional unencrypted header must be appended to the packet so that it can reach its destination.

Resources

The IETF has a host of RFCs on IPv6 implementation. RFC 2460 is the most current commentary on general IPv6 specifications. Go to www.ietf.org.

IPv6: The New Internet Protocol , Second Edition, by Christian Huitema, is a concise and informative guide to the next-generation protocol.

The 6bone network at www.6bone.net is an international testbed for IPv6. It has links to other IPv6 related sites.

For white papers, news, training, and information on IPv6 for Linux, Berkeley Software Distribution (BSD), Microsoft, and other operating systems, go to www.hs247.com.

For more information on integrating IPv4 and IPv6 environments, see a white paper entitled "Connecting IPv6 Routing Domains over the IPv4 Internet." The paper is available at www.cisco.com/ipv6/. Click on the "Technical documents" link at the bottom of the page.

This tutorial, number 159, by Andrew Conry-Murray, was originally published in the October 2001 issue of Network Magazine.