IPv6 Datagram Header

IPv6 Header Structure

In every IPv6 packet, a header contains metadata and control fields for every IPv6 packet. IPv6 addresses have 128 bits, while IPv4 addresses have 32 bits. Routers use these fields when forwarding a packet, and the receiver uses them to interpret the remaining data. The Version field identifies the format, the source and destination addresses identify the communication endpoints, and Next Header starts the chain of subsequent headers. IPv6 defines a fixed base header with separate extension headers.

The IPv6 base header has a fixed layout. Compared with IPv4, some fields were removed and optional information was moved into Extension Headers. The fixed header contains control fields, two 128-bit addresses, and values for describing length and flow identification. A router usually reads the fields needed for forwarding, while a host interprets the complete chain. This reduces common-case processing and allows the protocol to add functions without changing the base header layout.

IPv6 Base Header: Fixed Size and Fields

The IPv6 base header has a fixed size of 40 bytes (320 bits). The first fields describe the version, traffic class, and flow label; the middle fields describe length, the next header, and the hop limit; the two addresses occupy 32 bytes. Extension headers and the payload follow it, so the fixed layout identifies the start of the remaining part of the packet.

The IPv6 base header contains eight fields; their roles are described below. The position and size of each field are defined by the standard, so a parser can reach extension headers without interpreting application data first. These fields are processed before the transport payload is delivered.

Classification and Flow Label Fields

1. Version - 4 bits

This first field identifies the IP version. For IPv6, it contains the binary value 0110 (decimal 6); IPv4 uses the value 4, written as 0100. The value determines how the rest of the header is interpreted. A device can reject a packet with an unsupported format before further processing; coexistence of the stacks comes from recognizing the version, not from converting this field.

2. Traffic Class - 8 bits

This field serves the same classification role as IPv4 traffic fields, including DSCP. It lets routers differentiate traffic and apply Quality of Service (QoS). For example, packets from a delay-sensitive video conference can receive a different class from packets carrying a large file download. Traffic Class does not impose a particular priority. Its value follows network policy and may be changed within an administrative domain. The meaning of its code is defined by the administrative domain, and routers may use the value for classification, queuing, and congestion management.

3. Flow Label - 20 bits

The Flow Label identifies a sequence of packets for which the sender requests consistent treatment in the network. A flow consists of packets from a particular source to a particular destination; the exact criteria depend on the application and network policy. A source should keep the same nonzero label for packets belonging to one flow, while zero indicates that no such flow label is declared.

The source host can assign a common 20-bit value to packets in the same flow. Routers may use it with the addresses to keep packet treatment consistent, for example when selecting a path or applying QoS. The label itself does not define a priority; its meaning follows the configured network policy. VoIP and video streaming are examples of traffic that may require such consistency. An intermediate device should not change the label without an applicable processing rule.

Length and Extension Fields

4. Payload Length - 16 bits

This 16-bit field specifies the length of the payload in bytes, meaning the rest of the packet after the base header. It includes extension headers and excludes the fixed 40-byte base header.

• Being a 16-bit field, it can specify a payload length of up to $2^{16} - 1 = 65,535$ bytes.
• IPv6 also supports "jumbograms," which are packets larger than 65,535 bytes. The Jumbo Payload option in the Hop-by-Hop Options header carries the extended length; the Payload Length field is set to zero.

This is a simplification from IPv4, where the 'Total Length' field included the header, which could be variable.

5. Next Header - 8 bits

This 8-bit field identifies the type of header that immediately follows the IPv6 header. It can identify a protocol header or an extension header, and its value lets the receiver continue parsing the chain. The fixed base header is followed by extension headers in packet order, with each element identified by a protocol number. It can identify:

• A transport layer header, like TCP (value 6) or UDP (value 17), just like the Protocol field in IPv4.
• The header of an IPv6 Extension Header.

Extension Headers carry optional information such as fragmentation, routing, and security. The 'Next Header' field points to the next header, and each extension header contains its own field of the same type. The chain may include Hop-by-Hop Options, Destination Options, a Routing Header, and a Fragment Header. The last element points to a transport header such as TCP or to No Next Header.

6. Hop Limit - 8 bits

This 8-bit field corresponds to the IPv4 Time To Live (TTL) field. It is a hop counter, not a time measurement. A router decreases it for each forwarding operation, regardless of how long the transmission takes.

• The sending host sets an initial Hop Limit value.
• Every router that forwards the packet decrements the Hop Limit by 1.
• If a router decrements the Hop Limit to 0, it discards the packet and may send an ICMPv6 Time Exceeded message, type 3 code 0, to the source.

The field limits the number of forwarding operations a packet can undergo, preventing indefinite circulation if a routing loop occurs along its path.

Address Fields

7. Source Address - 128 bits

This field contains the 128-bit IPv6 address of the packet source and occupies 16 bytes of the header.

8. Destination Address - 128 bits

This field contains the 128-bit address of the packet recipient and occupies the final 16 bytes of the 40-byte base header. When a Routing Header is present, it may identify the current recipient; processing that header determines the ultimate destination. Routers make forwarding decisions from the current destination address and the Routing Header information.

Fields Omitted from the Base Header

Compared with IPv4, the IPv6 base header omits several fields. Their functions are covered by the fixed layout, extension headers, or mechanisms in upper layers.

• No Header Length (IHL) field: The IPv6 base header is always 40 bytes, so its length is defined. An IHL field is unnecessary.
• No Fragmentation Fields (ID, Flags, Offset): IPv6 routers do not fragment packets while forwarding them. If a packet exceeds a link MTU, the router drops it and sends an ICMPv6 Packet Too Big message containing the determined MTU to the source. The sending host selects a suitable size with Path MTU Discovery. If fragmentation is required, the source adds the optional Fragment Header and the destination reassembles the fragments; intermediate routers do not perform reassembly.
• No Header Checksum: IPv6 has no checksum field in the base header. In IPv4, changing TTL required a checksum update at every hop. The link layer can check frame integrity, for example with Ethernet FCS, while TCP and UDP use their own checksums. The TCP and UDP checksum also covers information from the IPv6 pseudo-header. Omitting the base-header checksum reduces the operations needed when forwarding a packet.