- Another feature with IPv6 is that so-called
jumbograms can be supported by using the hop-
by-hop extension header (normal packets are
limited to 64 kbyte).
The header format of IPv6 is depicted in Figure
- In addition to the basic format a number of
options can be included as described later.
In the same way as for IPv4, the Versionfield
gives the version number, i.e. equal to 6 here.
The Traffic classfield indicates traffic class or
priorities for packets. It was intended that this
field could be used similar to the ToS/DS field
for IPv4, see Box A. The 20 bit field called Flow
labelcontains an identifier of the packets be-
longing to the same flow. A flow is said to be a
sequence of packets sent from a particular source
to a particular (unicast or multicast) destination
for which the source may ask special handling
by the intermediate nodes. The nature of the spe-
cial handling can be conveyed by a control pro-
tocol (e.g. RSVP or similar) or carried by infor-
mation within the packets. A flow is uniquely
identified by the combination of source address
and a non-zero flow label. Hence, assigning a
zero flow label to a packet by a source, tells that
the packet does not belong to any flow.
The Payload lengthfield gives the length of
the packet following the basic IPv6 header, in
octets. Any extension header fields (options)
are considered as part of the payload.
The Next headerfield specifies the protocol
header following (e.g. TCP, UDP or any of the
header extensions). The Hop limitfield contains
an integer that is decrement by one for each node
that forwards the packet. If the value becomes
equal to zero, the packet is dropped. This basi-
cally replaces the time field in IPv4 realising the
way it was implemented by most IPv4 routers
anyway. The Source addressand Destination
addressfields contain the addresses of the
sender and the receiver of the packet, respec-
tively, each 128 bits long.
The optional fields are contained in separate
headers, where the Next header field specifies
which header type that follows. Most extension
headers are not processed in the intermediate
nodes along a path, only in the source and desti-
nation node. One exception is given for the Hop-
by-hopoption header as explained below.
The extension headers should be processed in
the same order as they are given. All extension
headers begin with a Next headerfield, 8 bits as
for the basic IPv6 header. As several of the ex-
tension headers may have a variable length, a
Header extension lengthfield is also given for
most of them.
Each extension header should only be included
once, except the destination options header that
should not be given more than twice; once
before the routing header and once before the
upper-layer header, see below. In case tunnelling
is used, the outer header could be another IPv6
header, again containing its separate set of ex-
tension headers. Most of the options within a
header follow a TLV-formatting, see Box B,
with 8 bits for the type field, 8 bits for the length
field and a variable value field.The following sequence of extension headers is
recommended, ref. [RFC2460]:- IPv6 header as depicted in Figure 3.
- Hop-by-hop options header containing op-
tional information that is to be examined in
every node along a packet’s path. This is not
further elaborated in [RFC2460]. - Destination options header to be processed by
the first destination that is given in the IPv6
destination address field and subsequent desti-
nations listed in the routing header. The infor-
mation in this header is not further detailed in
[RFC2460]. - Routing header is used by a sender to list a set
of intermediate nodes that a packet has to pass
through. This is similar to IPv4 loose source
and record route option. The addresses of the
intermediate nodes (and the final destination)
are given as a list of IPv6 addresses in this
extension header. By having a counter that is
increased for each node, the node can find
which node that is the next one. Then, the
address of the next node is inserted in the Des-
tination address field in the IPv6 basic header,
see example in Figure 4. Dividing the Header
extension length by 2 gives the number of
addresses. - Fragment header is used when a packet larger
then the path MTU is to be sent. Unlike for
IPv4, the source node is the only one frag-
menting packets. The fragment header in-
cludes a fragment offset (relative to the start
of the original packet) and a unique identifier.
When a packet is to be fragmented, all unfrag-
mentable parts of the packet are repeated in all
fragments. The unfragmentable parts consist
of all fields of the IPv6 packet header and any
extension headers up to and including the
routing header, if present. Then each of the
fragments consists of a repeated unfrag-
mentable part, the fragment header and the
fragment itself, see Figure 5. - Authentication header, see [RFC2402].