Configuring IPv6 For Cisco IOS

Read an Excerpt

The IPv6 header is fixed in length and aligned at 8-octet boundary, unlike the IPv4 header, which is of variable length and aligned at 4-octet boundary. Most modern computer architectures are optimized to read eight octets at a time. Thus, the length of the IPv6 header (or extension headers) is designed to be a multiple of eight octets for 8-octet alignment. With a fixed IPv6 header, a router can efficiently process a packet. For instance, a router must decide if there are any options in an IPv4 packet by reading the header length field. Processing a variable-length header can lead to inefficient router implementation.

The changes from the IPv4 header to the IPv6 header will be covered in the next section. In this section, we will describe each field in the IPv6 header and its intended role. Figure 3.1 shows the format of an IPv6 header.

The IPv6 header stores the information necessary to route and deliver packets to their destination. The headers are processed by each node along the path. The first 4-bit field, version, indicates the version of the Internet Protocol being used, and its value is 6 for IPv6. This field is necessary because it allows both protocols to coexist on the same segment without conflicts.

he next two fields, traffic class and flow label, are used to provide differentiated services and support applications requiring special per-flow handling. The 8-bit traffic class field can be used to provide differentiated services based on the nature of the data being transmitted. This field is similar to the intended use of the type of service field in the IPv4 header. For instance, an organization may set up its network to prioritize network traffic based on applications or source and destination information, and hosts and/or routers can use the traffic class field to differentiate the priority. The values and the exact use of this field are yet to be determined. The flow label, in combination with source and destination addresses, can uniquely identify a flow that requires special handling by intermediate routers. When a router identifies a flow for the first time, it remembers the flow and any special handling this flow requires. Once per-flow handling has been set up, the processing of subsequent packets belonging to this flow can be shorter than processing individual packets.

The 16-bit payload length field, similar to the total length field in the IPv4 header, indicates the length of the packet, not including the length of the IPv6 header. The 8-bit Next Header field is used to indicate the next header following the IPv6 header. The intended use of this field is identical to that of the protocol field in the IPv4 header. The hop limit can be used to limit the number of intermediate hops a packet is allowed to visit, which can prevent packets from being circularly routed in a network. (In IPv4, the TTL field has been used to prevent packets from being routed circularly—the new name for this field was chosen to more accurately reflect accurately its purpose.) As in IPv4 headers, IPv6 headers contain source and destination IP addresses. Unlike IPv4 nodes, IPv6 nodes use 128-bit addresses.

Comparing the IPv6 and IPv4 Headers

The IPv6 header shares some similarities with its predecessor, the IPv4 header. We will review the IPv4 header and discuss its similarities and differences to the IPv6 header. Figure 3.2 illustrates the format of an IPv4 header.

Let's take a look at each of the fields in an IPv4 header and how they relate to the IPv6 header: Version The first 4-bit version field in the IPv4 header is used to indicate the current version of the IP being used. The same field is used in the IPv6 header and is necessary in order to make IPv6 backward compatible. Header Length The 4-bit header length field is necessary for the IPv4 header to indicate the length of the header since the total length of the IPv4 header is variable between 20 and 64 bytes, depending on the presence and the length of options in the option field. However, this field is not necessary in an IPv6 header, because an IPv6 header is a fixed length of 40 bytes.

Type of Service (ToS) The intent of the type of service field in IPv4 is similar to that of the traffic class field in the IPv6 header. Nevertheless, this field has not been widely accepted or used in IPv4 implementations. Total Length This field indicates the entire length of the IP portion of the packet. It only includes the IP portion, so it does not include parts of a packet that are not related to IP, such as the Ethernet header or the Frame Check Sequence (also used on Ethernet packets), for example. IPv6 uses a similar field called payload length.

Identification, Flags, Fragment Offset The next three fields in the IPv4 header, the identification, flags and fragmentation offset fields, are all related to the handling of fragmentation and the reassembly of packets. In IPv4, an intermediate hop may further fragment a packet when the maximum transmission unit (MTU) on the outgoing link is smaller than the size of the packet that is to be transmitted on that link. Unlike IPv4, fragmentation processing in IPv6 takes place only at the source node, using a path MTU. Further, information related to fragmentation is encoded in the fragmentation header as an extension header in an IPv6 packet. Therefore, these three fields are not necessary in the IPv6 header.

Time To Live (TTL) In the original design of IPv4, the TTL field was used to indicate the number of seconds to live in a network, thus preventing packets from being circularly routed if a circular route existed in a network. However, in implementations, this field has been used to limit the number of hops the packet is allowed to visit. At each hop, a router decrements this field, and when it reaches zero, the packet is removed from the network. In IPv6, this field has been renamed hop limit, a more accurate description of its implementation.

Protocol The protocol field, which is used to indicate the next protocol (header) following the IPv4 header, is similar to the next header field in the IPv6 header.

Header Checksum The header checksum field is used to maintain the integrity of the IPv4 header. However, the higher layer calculates the checksum again for the entire packet, making this field redundant. Therefore, this field is not used in IPv6 header. If applications require a higher degree of integrity, they can achieve it through appropriate use of the Authentication and Encapsulating Security Payload extension headers.

Source and Destination Address The source and destination fields in IPv4 header remain the same in IPv6, except that the IPv4 node addresses are 32 bits and the IPv6 node addresses are 128 bits.

Options The use of options in IPv4 implies that each intermediate node in the path needs to examine the options field in the IPv4 header, although the options may be pertinent only to the destination node. This leads to inefficient router performance when options are used. In IPv6, optional information is encoded in extension headers.