Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
|
NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.
|
|
|
|
IPv6 Datagram Main Header Format
(Page 1 of 3)
As we saw in the
previous topic, IPv6 datagrams use a structure
that includes a regular header and optionally, one or more extension
headers. This regular header is like the
header of IPv4 datagrams, though it has
a different format, as we will see shortly. The standards don't give
this header a name; it is just the IPv6 header. To
differentiate it from IPv6 extension headers, I call it the main
header.
Main Header Format
The IPv6 main header is required
for every datagram. It contains addressing and control information that
are used to manage the processing and routing of the datagram. The main
header format of IPv6 datagrams is described in Table 68
and illustrated in Figure 105.
Table 68: IPv6 Main Header Format
Field
Name
|
Size (bytes)
|
Description
|
Version
|
1/2
(4 bits)
|
Version: Identifies
the version of IP used to generate the datagram. This field is used
the same way as in IPv4, except of course that it carries the value
6 (0110 binary).
|
Traffic
Class
|
1
|
Traffic
Class: This field replaces the Type Of Service (TOS)
field in the IPv4 header. It is used not in the original way that the
TOS field was defined (with Precedence, D, T and R bits) but using the
new Differentiated Services (DS) method defined in RFC 2474.
That RFC actually specifies quality of service (QOS) techniques for
both IPv4 and IPv6; see
the IPv4 format description for a bit more information.
|
Flow Label
|
2 1/2
(20 bits)
|
Flow Label: This
large field was created to provide additional support for real-time
datagram delivery and quality of service features. The concept of a
flow is defined in RFC 2460 as a sequence of datagrams sent from
a source device to one or more destination devices. A unique flow label
is used to identify all the datagrams in a particular flow, so that
routers between the source and destination all handle them the same
way, to help ensure uniformity in how the datagrams in the flow are
delivered. For example, if a video stream is being sent across an IP
internetwork, the datagrams containing the stream could be identified
with a flow label to ensure that they are delivered with minimal latency.
Not all devices and routers may support flow label handling, and use
of the field by a source device is entirely optional. Also, the field
is still somewhat experimental and may be refined over time.
|
Payload
Length
|
2
|
Payload
Length: This field replaces the Total Length field from
the IPv4 header, but it is used differently. Rather than measuring the
length of the whole datagram, it only contains the number of bytes of
the payload. However, if extension headers are included, their length
is counted here as well.
In simpler terms, this field measures the length of the datagram less
the 40 bytes of the main header itself.
|
Next Header
|
1
|
Next Header: This
field replaces the Protocol field and has two uses. When a datagram
has extension headers, this field specifies the identity of the first
extension header, which is the next header in the datagram. When a datagram
has just this main header and no extension headers, it serves
the same purpose as the old IPv4 Protocol field and has the same
values, though new numbers are used for IPv6 versions of common protocols.
In this case the next header is the header of the upper
layer message the IPv6 datagram is carrying. See below for more details.
|
Hop
Limit
|
1
|
Hop Limit:
This replaces the Time To Live (TTL) field in the IPv4 header;
its name better reflects the way that TTL is used in modern networks
(since TTL is really used to count hops, not time.)
|
Source
Address
|
16
|
Source Address:
The 128-bit IP address of the originator of the datagram. As with IPv4,
this is always the device that originally sent the datagram.
|
Destination
Address
|
16
|
Destination
Address: The 128-bit IP address of the intended recipient of
the datagram; unicast, anycast or multicast. Again, even though devices
such as routers may be the intermediate targets of the datagram, this
field is always for the ultimate destination.
|
|