CHAPTER 35. Introduction to the IPv6 Protocol
SOME OF THE MAIN TOPICS IN THIS CHAPTER ARE
What’s the Difference Between IPv4 and IPv6? 654
The first Request for Comments (RFC) to define the next generation of the Internet Protocol (IP) was RFC 1883, “Internet Protocol, Version 6 (IPv6) Specification,” published as a “standards track” RFC in 1995. When you consider that the Internet was expanding at a very rapid rate at that time (as it continues to do), it seemed a natural thing to develop a new version of IP to accommodate a larger address space, and to patch some holes in the current version of IP. Many other RFCs have been created since this original one. Specifically, RFC 2460 has updated RFC 1883. Other RFCs apply to very specific aspects of IPv6, such as changes to the Internet Control Message Protocol (ICMP) and other standard TCP/IP protocols and utilities. These RFCs are too numerous to be discussed in this chapter. You can, however, do a quick search at www.rfc-editor.org to get a list of all the RFCs related to IPv6.
During the years since, other technologies such as Network Address Translation (NAT) and Classless Interdomain Routing (CIDR) have enabled the current IPv4 address space to remain viable for the current Internet. Yet IPv6 encompasses many other capabilities. Currently, IPv6 is used only in very large enterprise networks, and in many routers at the Internet’s core. The hardware to route and use IPv6 exists today. Indeed, in Windows XP and Windows Server 2003, you’ll find that you can use IPv6.
Both NAT and CIDR are covered in greater detail in Chapter 24, “Overview of the TCP/IP Protocol Suite.”
However, besides the increased address space, IPv6 offers many other features that will make it the ideal replacement for IPv4 (down to the desktop) in a few years.
This chapter is not meant to be as comprehensive as Chapters 24 through 28, which cover the current TCP/IP protocols, applications, and utilities. However, this chapter provides a good overview of what IPv6 has to offer. Some of the capabilities of IPv6 (such as security) have already been implemented in IPv4 technologies (especially in Virtual Private Networks, or VPNs). The fact that some IPv6 features are already being backward implemented for IPv4 applications should give you an idea of the revolution that this newer IP version will bring.
What’s the Difference Between IPv4 and IPv6?
The IP protocol is a connectionless, unreliable protocol. TCP uses IP to establish sessions with remote computers and provides the reliability of the data transactions. IP, however, provides the hierarchical address space used by IPv4. Yet this address space is limited to fields in the IP datagram that are only 32 bits in length. When first created, it seemed like this address space would provide enough IP addresses to last for decades or more. After all, only government, educational facilities, and a few other institutions used what was then the ARPANET (the predecessor of the Internet). The address classes’ original part of the IPv4 address space has pretty much been displaced by CIDR, to prevent wasting large ranges of addresses allocated to a single entity (such as class A networks).
Note
TCP (the Transmission Control Protocol) is not the only protocol that uses IP for sending datagrams across a network. There are many other protocols, such as the User Datagram Protocol (UDP) and the Internet Control Message Protocol (ICMP), that also use IP. The point to be made is that when it comes to the Internet and most modern networks, IP is the workhorse that other protocols rely on to get data from one point to another. It is up to the upper-level protocols to ensure that the data is delivered in a reliable fashion.
IPv6 increases this 32-bit address space to 128 bits. At first glance, 32 bits versus 128 bits doesn’t seem to be a big difference. When you consider the number of possible addresses that each of these bit ranges can provide, however, there is a tremendous difference. Fill a 32-bit field with all ones and you end up with a number just over 4 billion. A 128-bit field can provide a much larger number of possible addresses. The actual number of addresses, of course, depends on which bits are used to identify a network and which are used to identify a host on a network.
The address space that IPv4 enables can give us enough addresses to satisfy the demand today, especially when using NAT for LANs and using CIDR to reclaim wasted address space that was created by the original address classes. Yet the world of electronics today has changed the playing field. It’s not just computers that need an IP address. Handheld devices, mobile phones, and other consumer devices will likely require an IP address in the near future. NAT might work well in a LAN or a small enterprise network, but when you consider that many wireless devices will roam from one provider to another, an assigned IP address becomes more important. NAT is performed at a local level, not a national or global one.
Expanding the IP address space is not the only feature that IPv6 gives to the Internet and your LAN or WAN. Other important features include the following:
A simpler header format for the IP datagram, which makes it possible to create faster routing techniques implemented in hardware designs.
Support for new extensions to the IP header, as well as a means to include future expansion for additional headers that may be created later.
The replacement of certain options left over from the IPv4 specification, as well as new options, and, again, room for expansion of additional options as required in the future.
The capability to specify which datagrams require special handling when it comes to flow control. This capability can enable real-time handling of a stream of IP datagrams (needed, for example, for real-time voice or video communication over an IP network), a feature usually accomplished by other protocols tunneling IP.
Authentication and encryption capabilities to provide for a secure connection.
As you can see, there are many differences between the capabilities of IPv4 and those of IPv6. The remainder of this chapter will give you an idea of how this new functionality is accomplished.
The IPv6 Headers
In Chapter 24 you learned about the simple IPv4 header format. Headers are used by protocols to provide information about source and destination addresses, protocols, or the payload encapsulated by the datagram. It is typical that one protocol’s packet is sent as the payload of another protocol. For example, the IP datagram is usually sent across most LANs encapsulated in an Ethernet frame. At the destination, the Ethernet portion of the frame is stripped off and the IP packet information is revealed. The IP information is then removed by the protocol stack, and the TCP (or other protocol) information is then removed before the actual data is reassembled and sent to an application.
A few of the IPv4 fields were never put to any practical use. And some of those fields no longer exist in the IPv6 header. In Figure 35.1 you can see the fields that make up the IPv6 header.
The fields for IPv6, as shown in Figure 35.1, are as listed here:
Version—This 4-bit field is the version of the Internet Protocol. The value for IPv4 was 4. The version for IPv6 in this field is 6. Routers and other devices use this value to determine what type of datagram is being processed.
Traffic Class—Similar to the Flow Label field, this field enables nodes to specify a particular “traffic class,” the definition of which is still being defined by many RFC documents. This field should be supported by any intervening device (such as a router) that understands this field (as it exists today), and ignored by those that do not.
Flow Label—This 20-bit field is used to request that devices that stand between the source and the destination give special preference to this datagram. This can be compared to the Quality of Service field of IPv4 headers.
Payload Length—This 16-bit field is used to indicate the length of the payload section of the datagram. This does not include the original header of the IP datagram, but it does include any additional headers, as well as the actual payload of the datagram.
Next Header—One of the most useful features that IPv6 provides is that additional headers can be included in a datagram, in addition to the main IPv6 header itself. There are many types of headers (discussed later in this chapter), and they can be useful depending on the type of payload, or the treatment of the current datagram (such as routing techniques).
Hop Limit—This 8-bit field is similar to a Time to Live (TTL) field used by many other protocols. It is decremented by 1 at each router the datagram passes through. When the value reaches 0, the datagram can be discarded.
Source Address—A 128-bit address used to describe the IP source of the datagram.
Destination Address—A 128-bit address used to describe the IP destination address of the datagram.
Figure 35.1. The IPv6 header is vastly different from the IPv4 header.
This section describes just the initial IPv6 header format. In the next section you will learn about how IPv6 can include additional headers that extend the traditional header to provide information about additional services for the IP protocol.
IPv6 Extension Headers
In general, most protocols have header information followed by a payload that contains the actual data to be transmitted from one point to another. Some protocols include a trailer that usually is used to provide some type of integrity check, such as CRC, to ensure that the frame or datagram has arrived at the destination without corruption.
Still other protocols, and we’re talking about IPv6 here, allow for additional headers to follow the initial IPv6 header, to describe certain aspects of the datagram. These headers are not required, but one or more can be placed into the datagram. These additional extension headers are placed directly after the IPv6 header, where the payload section is usually located. The payload that follows the IPv6 header, or the extension headers, will be a header for the encapsulated upper-layer protocol being transported by the IPv6 datagram. It is interesting to note that among the following headers, if the hop-by-hop header is used, it must follow the IPv6 header as the first additional header. Other extension headers don’t have to be in any particular order, but the RFCs do suggest that certain headers be placed in a certain order.
Note
Although the extension headers don’t necessarily have to be placed in any particular order (except for the hop-by-hop header, described in the following text), any node that needs to look at the extension headers is required to do so in the order in which they appear in the datagram. A node cannot simply look through the headers trying to find a specific header.
The field Next Header is used to indicate whether another header follows the current header, after the initial IPv6 header. Yet if the next header is not one that the receiving node recognizes, the node should discard the datagram and send an ICMP message to the source indicating that there was a problem with the packet. In IPv6, the ICMP code for this is 1, which in text format means “unrecognized Next Header Field Header type encountered.” This ICMP message is used in many of the IPv6 procedures.
It is important to note that an IPv6 datagram doesn’t have to have any extension headers. They are used only when the feature is implemented in the IPv6 hardware (or software) routing mechanism.
The extension headers that can follow the IPv6 header include these:
Hop-by-Hop—If present, this is the only header that must be examined by every node (read that as router, whether an actual router device or a computer acting as a router). This header, as described previously, must be placed directly after the IPv6 header. If you look back at the Next Header field of the IPv6 header shown in Figure 35.1, a value of zero indicates that the Hop-by-Hop header is the next header, and must be examined. The IPv6 header is the only header that can use a value of zero in the Next Header field. If any other extension header contains this value, an ICMP message value of 1 will be sent back to the source. This value indicates “unrecognized Next Header type encountered.” This option type can be of variable length.
Destination Options—This header can also be of variable length, and is used only by the destination of the packet. This extension header is used to carry additional information, which is to be defined by other RFCs.
Routing—This field specifies specific network nodes that a packet should be passed through (a route) to reach its destination. Routers usually decide the route a packet will take depending on the routing protocol. Using this option, IPv6 routers can specify a route. The nodes listed in this option are not guaranteed, however, because there is always the possibility that a particular node might not be online. Or the Maximum Transmission Unit (MTU) of a router listed here might not accept the size of the packet, and thus the packet can’t be sent through that router.
Fragment—This option enables the source node to fragment a packet so that it will be able to reach its destination based on the MTU of the routers between the source and the destination. However, because this value is set by the source node, and it cannot be certain of the MTU value of intervening nodes, packets can still be dropped. A field called the M flag field can be set to one if more fragments of the original message are to be sent, or zero if the packet contains the last fragment of the original message. An Identification field is used to identify which fragmented packets should be considered as a group to be reassembled at the destination node. At the destination, fragments are identified by the source address + destination address + Identification field.
Note
IPv6 assumes a minimum MTU of 1,280 bytes. If the MTU of any link (router) that lies between the source and the destination of the packet uses a smaller MTU, then the packet will be fragmented by the router that lies between the source and the destination, not by IPv6 itself.
Authentication—This extension header is described in detail in Chapter 46, “Virtual Private Networks (VPNs) and Tunneling.”
Encapsulating Security Payload—This extension header is described in detail in Chapter 46.
Upper-layer header—This header follows the other headers, as in an IPv4 packet, and describes the data contained in the remainder of the payload section of the packet.
The preceding list is described in the recommended order suggested by the RFC. This can change depending on a few circumstances. For example, if the Destination Options header should be read not just by the node specified by the destination address found in the initial IPv6 header, but also by the other destinations listed in the Routing header, then the Destination Options header should be placed immediately after the Hop-by-Hop header, followed by the Routing header.
The Options Type Field for Hop-by-Hop and Destination Options
If the Destination Options header should be examined only by the final destination node, it should be placed just before the upper-layer header. The Options Type field for Hop-by-Hop and Destination Options is an 8-bit field. However, it should be interpreted by bit values, not by byte values.
Table 35.1 lists the first two highest-order options type bits. These bits specify what should be done if a node does not understand the option.
Table 35.1. High-Order 2-Bit Option Type Values
The third-highest-ordered bit used is either zero or one. If the bit has a value of zero, the data contained in the option cannot be changed by a node it passes through on the way to its eventual destination. If the bit has a value of one, a node can change data in the extension header.
The Next Header field is used by all options. It simply specifies what the next option (following the current option) will be. These option type numbers are based on those described for IPv4. These numbers were originally defined in RFC 1700, and later RFCs. However, the RFC process was not sufficient to keep up with newer protocols and services that were being developed, so an online database now exists at the Web site www.iana.org. You can use this database to determine what type of protocol or option the Next Header field indicates.
Other IPv6 Considerations
Although IPv6 contains a field that defines the maximum number of hops (the Hop-to-Hop field), it is not required that all nodes support this function, though they can if desired. Instead, upper-layer protocols (such as TCP) are generally delegated this responsibility.
In addition, upper-level protocols should be aware that the maximum payload space has been reduced if IPv6 headers are to be added to the packet. Again, this is a modification that will require that upper-layer protocols be modified, or that the source use fragmentation to deliver packets to their destination.
The Future of IPv6
IPv4 has been in use for more than 10 years now, and although most of the address-space issues have been resolved, there will come a time when the usefulness and flexibility of IPv6 becomes more and more important. There are many enhancements to IPv6 that might warrant its implementation in your network. If your network hasn’t yet adopted IPv6, you can bet that eventually it will.