What are the eight fields of the fixed 40-byte IPv6 base header, and what job does each one do?
answer
- addresses fill most of it
- first 32 bits hold three fields
- second 32 bits hold three more
- Payload Length starts after byte 40
- Next Header reuses IPv4 protocol numbers
basics
~20 sThe IPv6 base header is always 40 bytes: Version, Traffic Class, Flow Label, Payload Length, Next Header and Hop Limit fill the first 8 bytes, and the 128-bit Source and Destination addresses fill the other 32.
solid answer
~50 sRFC 8200 fixes the base header at 40 bytes and eight fields. `Version` is 4 bits set to 6. `Traffic Class` is an 8-bit octet carrying the 6-bit DSCP and the 2-bit ECN field. `Flow Label` is 20 bits a source sets so one flow can be recognised without reading transport ports; zero means unlabelled. `Payload Length` (16 bits) counts every byte after the base header, extension headers included. `Next Header` (8 bits) names whatever follows, an extension header or the upper layer, using the IPv4 protocol numbers: 6 for TCP, 17 for UDP, 58 for ICMPv6. `Hop Limit` (8 bits) is decremented by every forwarding node, which discards the packet rather than forward it at zero. The two 128-bit addresses take the remaining 32 bytes. Because the size never varies, no header-length field is needed.
go deeper
Recall the size, 40 bytes, and that two 128-bit addresses take 32 of them. Name Hop Limit as the counterpart of IPv4's TTL and Next Header as the counterpart of its Protocol field.
Walk all eight fields with their widths and say who reads each. Stress that Payload Length excludes the base header and that Next Header may name an extension header rather than the transport.
Use the layout when reading captures and writing filters: Traffic Class can be re-marked in transit, and a match on Next Header equal to TCP misses segments sitting behind an extension header.
Reason about what a forwarding device can act on without parsing further: addresses, Hop Limit, Traffic Class and Flow Label sit at fixed offsets, while transport ports may sit behind a variable extension-header chain.
## The 40 bytes, field by field The IPv6 specification, **RFC 8200** (2017, obsoleting RFC 2460), defines a base header whose size and layout never change. Every IPv6 packet starts with exactly these eight fields: | Field | Width | Position | Job | |---|---|---|---| | `Version` | 4 bits | byte 0, high nibble | Always 6 | | `Traffic Class` | 8 bits | bits 4-11 | DSCP (6 bits) plus ECN (2 bits) | | `Flow Label` | 20 bits | bits 12-31 | The source's label for one flow; 0 = unlabelled | | `Payload Length` | 16 bits | bytes 4-5 | Bytes after the base header, extension headers included | | `Next Header` | 8 bits | byte 6 | Type of the header that comes next | | `Hop Limit` | 8 bits | byte 7 | Decremented by each forwarding node | | `Source Address` | 128 bits | bytes 8-23 | The originator | | `Destination Address` | 128 bits | bytes 24-39 | The intended recipient | The arithmetic is worth doing once, because interviewers like to ask why the header is twice the size of IPv4's 20-byte minimum while having fewer fields: 1. First 32-bit word: 4 + 8 + 20 = 32 bits. 2. Second word: 16 + 8 + 8 = 32 bits. 3. Addresses: 128 + 128 = 256 bits, which is 32 bytes. 4. Total: 32 + 32 + 256 = 320 bits = **40 bytes**, and 32 of those 40 bytes are addresses. ## What each field means in practice - **Version** is 6, held in the same first four bits where IPv4 carries its 4. - **Traffic Class** is the octet the network uses for traffic management. Today it carries the **Differentiated Services codepoint** (6 bits, RFC 2474) and the **ECN** field (2 bits, RFC 3168), laid out exactly as in IPv4's former Type of Service octet. RFC 8200 warns that the value received may differ from the value sent: networks re-mark DSCP and congested routers set ECN bits. - **Flow Label** lets a source tag packets of one flow so that a classifier can identify the flow from the label plus the two addresses, all at fixed offsets. A source that does not label flows sets it to zero (RFC 6437). - **Payload Length** is a 16-bit unsigned count of the octets *after* the 40-byte base header, and it includes any extension headers. That is a different definition from IPv4's `Total Length`, which counts the header too. - **Next Header** is an 8-bit selector using the same numbers as IPv4's `Protocol` field. It can name an upper layer (6 TCP, 17 UDP, 58 ICMPv6) or an **extension header**: 0 Hop-by-Hop Options, 43 Routing, 44 Fragment, 60 Destination Options, 50 ESP, 51 AH. The value 59 means **No Next Header**: nothing follows. - **Hop Limit** is an 8-bit counter decremented by 1 by each node that forwards the packet. A forwarding node discards the packet if the value was zero on arrival or reaches zero when decremented, and RFC 4443 then has it send an ICMPv6 Time Exceeded message with code 0. A destination receiving a packet with Hop Limit 0 should still process it. The field was renamed from IPv4's `Time to Live` because IPv6 nodes are not required to enforce a maximum packet lifetime; RFC 791 had defined TTL nominally in seconds. - **Source and Destination Address** are 128 bits each. The destination may not be the final recipient: when a Routing header is present, it holds the next node the packet must visit. ## What the base header leaves out Compared field by field with IPv4, four things are missing from the fixed header: - no **header length** field, because the size never varies; - no **header checksum**; - no **Identification, flags or fragment offset**, which moved into the Fragment extension header that only the source inserts; - no **options** area, replaced by extension headers chained through `Next Header`. ## A worked packet A host at `2001:db8::1` sends a 1,000-byte TCP segment (header plus data) to `2001:db8::2`: 1. `Payload Length` = 1000 and `Next Header` = 6. 2. The packet on the wire is 1,040 bytes. 3. If the sender adds an 8-byte Destination Options header, `Payload Length` becomes 1008, the base header's `Next Header` becomes 60, and the Destination Options header's own `Next Header` field holds the 6. ## Slips interviewers listen for - Saying the header is variable length, or quoting IPv4's 20-to-60 range. - Counting the 40 base bytes inside `Payload Length`. - Assuming `Next Header` always names TCP or UDP; filters written that way miss traffic behind extension headers. - Treating Hop Limit as a time budget rather than a hop count.
- An IPv6 packet carries a 1,000-byte TCP segment behind an 8-byte Destination Options header. What do Payload Length and the base header's Next Header hold?`Payload Length` is 1008, because it counts every byte after the 40-byte base header, the 8-byte extension header included. The base header's `Next Header` is 60, naming Destination Options; that header's own `Next Header` field carries 6 for TCP. The whole packet is 1,048 bytes.
- Does an IPv6 destination drop a packet that arrives with Hop Limit 0?No. RFC 8200 makes the discard a forwarding rule: a node forwarding the packet drops it if Hop Limit was zero on arrival or reaches zero when decremented. A node that is itself the destination should not discard it and should process it normally.
- What does a Next Header value of 59 mean in an IPv6 packet?It is No Next Header: nothing follows the header that carries it. If `Payload Length` says there are octets beyond that header, RFC 8200 says they are ignored, and passed on unchanged if the packet is forwarded.
saying these in an interview costs you the question
- The IPv6 header varies between 40 and 60 bytes, like IPv4's.
- Payload Length counts the whole packet, the 40-byte base header included.
- The base header's Next Header field always names TCP or UDP.
- Hop Limit is a time budget in seconds that routers count down.
- IPv6 addresses take 16 of the base header's 40 bytes.