IPv6 Header Format Explained

The IPv6 header byte by byte: 40 bytes fixed, 8 fields, extension headers, Next Header chaining, comparison to IPv4, and what it looks like in Wireshark.

The IPv6 header is 40 bytes, fixed length, with eight fields. Compared to IPv4's variable-length 20-60 byte header with thirteen fields, IPv6 is intentionally minimalist. The simplification is not cosmetic - it makes IPv6 packets faster to parse, easier to hardware-accelerate, and cleaner for routers to forward.

This article walks through the IPv6 header byte by byte, explains each field, covers extension headers (the IPv6 way of adding optional features), and shows how the header looks in Wireshark. If you are studying for CCNP/CCIE or trying to read an IPv6 packet capture, this is the byte reference.

The IPv6 Header Layout

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                       (128 bits / 16 bytes)                   |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                       (128 bits / 16 bytes)                   |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

40 bytes total: 8 bytes of header fields plus 16 bytes source address plus 16 bytes destination address.

Field by Field

FieldBitsPurpose
Version4Always 6 for IPv6
Traffic Class8QoS marking (DSCP + ECN, like IPv4 ToS)
Flow Label20Per-flow identifier (flows = packets that should follow the same path)
Payload Length16Length of payload in bytes (excludes the 40-byte header itself)
Next Header8Type of the next header (TCP=6, UDP=17, ICMPv6=58, extension headers, etc.)
Hop Limit8TTL equivalent; decremented at each router; packet dropped at 0
Source Address128IPv6 source address
Destination Address128IPv6 destination address

Version

4 bits. Value is always 6 for IPv6 packets. The first hex digit of the header is always 6 (followed by the upper nibble of the Traffic Class).

Traffic Class

8 bits. Functions identically to the IPv4 ToS / DSCP byte. Top 6 bits are DSCP (QoS marking, see DSCP article); bottom 2 bits are ECN (Explicit Congestion Notification).

QoS configurations on Cisco apply identically to IPv4 and IPv6 - a class-map matching DSCP EF works on both because the byte position differs but the semantics are the same.

Flow Label

20 bits. Identifies a "flow" of packets that should follow the same path through the network. The intent: routers can use the flow label as a hash input for ECMP without parsing into Layer 4 headers. Identical Flow Label = same flow, deterministic path.

In practice, Flow Label adoption has been mixed. Some implementations set it; many leave it 0. Routers may or may not honor it for ECMP. RFC 6437 sets the modern usage rules but real-world behavior varies. Treat it as "useful when the surrounding stack honors it; ignored otherwise."

Payload Length

16 bits. Length in bytes of everything after the 40-byte header. Maximum value 65,535 = 64 KB minus 1; for jumbograms larger than 64 KB, the Hop-by-Hop extension header carries an extended length field.

Note this is "payload" length, not "total" length (as in IPv4). The 40-byte header itself is excluded. So an IPv6 packet on the wire is always 40 + Payload Length bytes total.

Next Header

8 bits. Identifies the type of the next thing in the packet. This is roughly equivalent to IPv4's Protocol field but with two important differences:

  1. It can point to a Layer 4 protocol directly (TCP=6, UDP=17, ICMPv6=58)
  2. It can point to an Extension Header that itself contains another Next Header field

This creates a chained-header model. Common Next Header values:

ValueHeader type
0Hop-by-Hop Options (extension header)
6TCP
17UDP
43Routing (extension header, including Segment Routing)
44Fragment (extension header)
50ESP (IPsec encapsulating security payload)
51AH (IPsec authentication header)
58ICMPv6
59No Next Header (end of chain)
60Destination Options (extension header)

Hop Limit

8 bits. Decremented at each router that forwards the packet. Packet is dropped when Hop Limit reaches 0; ICMPv6 Time Exceeded message is sent back to the source. Equivalent to IPv4 TTL.

Default starting values: 255 from most modern hosts (some use 64). The high default is intentional - by the time the packet is dropped due to Hop Limit, it has likely traversed many networks (which is itself diagnostic).

The Hop Limit also serves a security role: NDP messages (RS, RA, NS, NA, Redirect) must have Hop Limit 255 when received, otherwise they are dropped. This prevents off-link attackers from injecting NDP messages because their packets would have decremented Hop Limit while transiting routers.

Source and Destination Addresses

128 bits each. The IPv6 addresses (see IPv6 Address Format for the format details).

16 bytes each = 32 bytes of address space, which is most of the 40-byte header. The minimalism of the rest of the header is partly because the addresses themselves consume so much.

Extension Headers

IPv6 moves features that were "options" in IPv4 into separate extension headers chained between the base header and the payload. Each extension header has its own Next Header field pointing to whatever comes next.

Extension HeaderNH ValueUse
Hop-by-Hop Options0Examined by every router along the path (e.g. Jumbograms, Router Alert)
Routing43Specifies intermediate destinations (Type 0 deprecated; Type 4 = Segment Routing)
Fragment44Carries fragmentation info if the source had to fragment
ESP50IPsec encryption
AH51IPsec authentication
Destination Options60Examined only by the destination

The chain terminates when a Next Header value points to a real Layer 4 protocol (TCP, UDP, ICMPv6) or to "No Next Header" (59).

Most ordinary IPv6 packets have no extension headers - the base header points directly to TCP/UDP/ICMPv6. Extension headers are common for fragments, IPsec, and segment routing.

Comparison to the IPv4 Header

Field in IPv4Status in IPv6
VersionSame field, value 6
IHL (Internet Header Length)Removed (header is fixed 40 bytes)
ToS / DSCPRenamed Traffic Class; same semantics
Total LengthRenamed Payload Length (excludes header)
Identification, Flags, Fragment OffsetMoved to Fragment extension header
TTLRenamed Hop Limit
ProtocolRenamed Next Header (with extension header chain)
Header ChecksumRemoved (relies on L2 + L4 checksums)
Source / Destination AddressSame purpose; 128 bits instead of 32
OptionsReplaced by extension headers (chained, optional)

The biggest change is removing the header checksum. IPv4 routers had to recalculate the checksum each time they decremented TTL - an expensive operation that ASIC designers worked hard to optimize. IPv6 routers do not. The Layer 2 (Ethernet) FCS and Layer 4 (TCP/UDP) checksums together catch errors; the IP-layer checksum was redundant.

In a Packet Capture

An IPv6 packet in Wireshark shows the base header parsed:

Internet Protocol Version 6, Src: 2001:db8:1::1, Dst: 2001:db8:2::1
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00
        .... 0000 00.. .... .... .... .... .... = DSCP: Default (0)
        .... .... ..00 .... .... .... .... .... = ECN: Not-ECT (0)
    .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
    Payload Length: 40
    Next Header: TCP (6)
    Hop Limit: 64
    Source: 2001:db8:1::1
    Destination: 2001:db8:2::1
Transmission Control Protocol, ...

If extension headers are present, Wireshark dissects them in order, showing each in a separate tree section. The Next Header field of the last extension header points to the actual Layer 4 protocol, which Wireshark then parses.

Why the Header Is Faster

Three reasons IPv6 forwarding is faster than IPv4 on similar hardware:

  1. Fixed header length. Routers know exactly where each field is; no IHL math.
  2. No checksum recomputation. Decrementing Hop Limit does not require updating the header.
  3. No options parsing on the fast path. Extension headers exist but are usually skipped on intermediate routers (only the destination examines Destination Options; only routers along the path examine Hop-by-Hop).

Combined with hardware acceleration in modern silicon, IPv6 typically forwards at line rate on any router that does IPv4 at line rate.

Summary

The IPv6 header is 40 bytes fixed: 4-bit Version, 8-bit Traffic Class, 20-bit Flow Label, 16-bit Payload Length, 8-bit Next Header, 8-bit Hop Limit, plus 128-bit source and destination addresses. Extension headers chain between the base header and the payload via Next Header values; common ones include Fragment, Routing, ESP, AH, and Destination Options.

The header is intentionally minimalist - simpler than IPv4, faster to parse, easier to hardware-accelerate. Master the field layout and the Next Header chain and you can read any IPv6 packet capture. Bookmark this article alongside the IPv6 cluster pillar.

Read next

© 2025 Ping Labz. All rights reserved.