The core of the protocol is naturally the datagram format defined in RFC 2460 [RFC2460]. The datagram design focused mainly on simplicity - to keep the datagram as simple as possible and to keep the size of the headers fixed. The main reason for this decision was to maximise processing performance - simple constant size headers can be processed quickly, at or very close to wire-speed.

The IPv4 header format contains a lot of fields including some unpredictable optional ones leading to fluctuating header sizes. IPv6 shows a different approach: the basic header is minimised and a constant size. Only essential fields (like addresses or datagram length) are contained. Everything else has been shifted aside into so called extension headers, which are attached on demand - for example a mobile node adds mobility related extension headers to its outgoing traffic.

Figure 2-1 Basic IPv6 Datagram Header

The basic datagram header format is showed in Figure 2-1. The contents of individual fields are following:

Version
Protocol version identification. It contains value 6 to identify IPv6.

Traffic Class

Intended for the Quality of Service (QoS). It may distinguish various classes or priorities of traffic (in combination with other header fields, e.g. source/destination addresses).

Flow Label

Identifies a flow which is a “group of related datagrams”.

Payload Length

Length of the datagram payload, i.e. all the contents following the basic header (including extension headers). It is in Bytes, so the maximum possible payload size is 64 KB.

Next Header

The protocol header which follows. It identifies the type of following data - it may be some
extension header or upper layer protocol (TCP, UDP) data.

Hop Limit

Datagram lifetime restriction. The sending node assigns some value to this field defining the reach of given datagram. Every forwarding node decreases the value by 1. If decremented to zero, the datagram is dropped and an ICMP message is sent to the sender. It protects the IPv6 transport system against routing loops - in the case of such loop the datagram circulates around the loop for a limited time only.

Source Address

Sender identification. It contains the IPv6 address of the node who sent this datagram. Addressing is described in more detail in the next chapter.

Destination Address

Receiver identification. This is the target - the datagram should be delivered to this IPv6 address.

Before we dive deeper into some header specialties let us compare the IPv4 and IPv6 headers (see Figure 2-2). The result is quite interesting: the total length of the datagram header doubled (from 20 bytes to 40 bytes) although the IPv6 addresses are four times as long.

How is it possible? Because just a subset of IPv4 header fields have been adopted by IPv6 - the corresponding fields are marked by numbers in Figure 2-2. The whole second line of the IPv4 datagram, designed for fragmentation, has been moved to an extension header. The CRC (cyclic redundancy check) has been abandoned for two good reasons: First, frame consistency is checked in lower layers, so it is largely redundant. Second, CRC decelerates the datagram processing - every forwarding node decreases the datagram lifetime, so it changes the header and must recalculate the CRC. Thanks to the constant header length the corresponding header length field is not necessary anymore.

Figure 2-2 IPv4 and IPv6 Header Comparison