An IPv6 packet is the smallest message entity exchanged via the Internet
Protocol across an Internet Protocol version 6 network.
Packets consist of control information for addressing and routing, and a
payload consisting of user data. The control information in IPv6 packets is
subdivided into a mandatory fixed header and optional extension headers. The
payload of an IPv6 packet is typically a datagram or segment of the higher-level
Transport Layer protocol, but may be data for an Internet Layer or Link Layer
instead. IPv6 packets are typically transmitted
over a Link Layer protocol, such as Ethernet which encapsulates each packet
in a frame, but this may also be a higher layer tunneling protocol, such as
IPv4 when using 6to4 or Teredo transition technologies.
Routers do not fragment IPv6 packets, as they do for IPv4. Hosts are "strongly
recommended" to implement Path MTU Discovery to take advantage of MTUs
greater than the smallest MTU of 1280 octets. A node may use the IPv6 Fragment
header to fragment the packet at the source and have it reassembled at the
destination(s). Fixed header
The fixed header of an IPv6 packet consists of its first 40 octets. It has
the following format: Version
The constant 6. Traffic Class
The bits of this field hold two values. The 6 most-significant bits are used for
differentiated services, which is used to classify packets. The remaining two
bits are used for ECN; priority values subdivide into ranges: traffic where the
source provides congestion control and non-congestion control traffic.
Flow Label Originally created for giving real-time
applications special service. The flow label when set to a non-zero value now
serves as a hint to routers and switches with multiple outbound paths that these
packets should stay on the same path so that they will not be reordered. It has
further been suggested that the flow label be used to help detect spoofed
packets. Payload Length
The size of the payload in octets, including any extension headers. The
length is set to zero when a Hop-by-Hop extension header carries a Jumbo Payload
option. Next Header
Specifies the type of the next header. This field usually specifies the
transport layer protocol used by a packet's payload. When extension headers
are present in the packet this field indicates which extension header
follows. The values are shared with those used for the IPv4 protocol field,
as both fields have the same function. Hop Limit
Replaces the time to live field of IPv4. This value is decremented by one at each
intermediate node visited by the packet. When the counter reaches 0 the packet is
discarded. Source Address
The IPv6 address of the sending node. Destination Address
The IPv6 address of the destination node(s).
In order to increase performance, and since current link layer technology and
transport or application layer protocols are assumed to provide sufficient error
detection, the header has no checksum to protect it.
Extension headers Extension headers carry optional
Internet Layer information, and are placed between the fixed header and the
upper-layer protocol header. The headers form a chain, using the Next Header
fields. The Next Header field in the fixed header indicates the type of the
first extension header; the Next Header field of the last extension header
indicates the type of the upper-layer protocol header in the payload of the
packet. All extension headers are a multiple of
8 octets in size; some extension headers require internal padding to meet this
requirement. There are several extension headers
defined, and new extension headers may be defined in the future. Extension
headers are to be examined and processed at the packet's destination only, except
for Hop-by-Hop Options, which need to be processed at every intermediate node on
the packet's path, including sending and receiving node. The defined extension
headers below are listed in the preferred order, should there be more
than one extension header following the fixed header. Note that all extension
headers are optional and should only appear at most once, except for the
Destination Options header, which may appear twice.
If a node does not recognize a specific extension header, it should discard the
packet and send a Parameter Problem message. When a Next Header value 0
appears in a header other than the fixed header a node should do the same.
Value 59 in the Next Header field indicates that there is no next header
whatsoever following this one, not even a header of an upper-layer protocol. It
means that, from the header's point of view, the IPv6 packet ends right after
it: the payload should be empty. There could, however, still be data in the
payload if the payload length in the first header of the packet is greater
than the length of all extension headers in the packet. This data should be
ignored by hosts, but passed unaltered by routers.
= Hop-by-hop options and destination options=
The Hop-by-Hop Options extension header needs to be examined by all nodes on the
packet's path, including sending and receiving nodes. The Destination Options
extension header need to be examined by the destination node(s) only. The
extension headers are both at least 8 octets in size; if more options are
present than will fit in that space, blocks of 8 octets are added to the
header repeatedly—containing options and padding—until all options are
represented. Next Header
Specifies the type of the next header. Hdr Ext Len
Length of this header in 8-octet units, not including the first 8 octets.
Options Contains one or more options, and
optional padding fields to align options and to make the total header length a
multiple of 8 octets. Options are TLV-coded.
= Routing= The Routing extension header is used to
direct a packet to one or more intermediate nodes before being sent to
its destination. The header is at least 8 octets in size; if more Type-specific
Data is needed than will fit in 4 octets, blocks of 8 octets are added to
the header repeatedly, until all Type-specific Data is placed.
Next Header Indicates the type of the next header.
Hdr Ext Len The length of this header, in multiples
of 8 octets, not including the first 8 octets.
Routing Type 0, 1, or 2.
Segments Left Number of nodes this packet still has to
visit before reaching its final destination.
Type-specific Data Data that belongs to this type of
routing header. Routing types
Due to the fact that with Routing Header type 0 a simple but effective
denial-of-service attack could be launched, this header is deprecated and
host and routers are required to ignore these headers.
Routing Header type 1 is used for the Nimrod project funded by DARPA.
Routing Header type 2 is a limited version of type 0 and is used for Mobile
IPv6, where it can hold the Home Address of the Mobile Node.
= Fragment= In order to send a packet that is larger
than the path MTU, the sending node splits the packet into fragments. The
Fragment extension header carries the information necessary to reassemble the
original packet. Next Header
Identifies the type of the next header. Reserved
Initialized to all zeroes. Fragment Offset
Offset, in 8-octet units, relative to the start of the fragmentable part of
the original packet. Res
Reserved; initialized to zeroes. M Flag
1 means more fragments follow; 0 means last fragment.
Identification Packet identification value, generated
by the source node. Needed for reassembly of the original packet.
= Authentication Header and Encapsulating Security Payload=
The Authentication Header and the Encapsulating Security Payload are part
of IPsec and are used identically in IPv6 and in IPv4.
Payload The fixed and optional IPv6 headers are
followed with the upper-layer payload, the data provided by the transport
layer, for example a TCP segment or a UDP datagram. The Next Header field of
the last IPv6 header indicates what type of payload is contained in this packet.
= Standard payload length= The payload length field of IPv6 has a
size of 16 bits, capable of specifying a maximum size of 65535 octets for the
payload. Most Link Layer protocols cannot process packets larger than 65535
octets. = Jumbogram=
An optional feature of IPv6, the jumbo payload option in a Hop-By-Hop Options
extension header, allows the exchange of packets with payloads of up to one byte
less than 4 GB, by making use of a 32-bit length field. Packets with such
payloads are called jumbograms. Since both TCP and UDP include fields
limited to 16 bits, support for IPv6 jumbograms requires modifications to the
Transport Layer protocol implementation. Jumbograms are only relevant for links
that have a MTU larger than 65583 octets.
Fragmentation Unlike in IPv4, IPv6 routers never
fragment IPv6 packets. Packets exceeding the size of the maximum transmission
unit of the destination link are dropped and this condition is signaled by a
Packet too Big ICMPv6 type 2 message to the originating node, similarly to the
IPv4 method when the Don't Fragment bit is set.
End nodes in IPv6 are expected to perform path MTU discovery to determine
the maximum size of packets to send, and the upper-layer protocol is expected to
limit the payload size. However, if the upper-layer protocol is unable to do so,
the sending host may use the Fragment extension header in order to perform
end-to-end fragmentation of IPv6 packets. Any data link layer conveying
IPv6 data must be capable of delivering an IP packet containing 1280 bytes
without the need to invoke end-to-end fragmentation at the IP layer.
= Fragmenting= A packet containing a fragment of an
original packet consists of two parts: the unfragmentable part of the original
packet, and a piece of the fragmentable part of the original packet, identified
by a fragment offset. The unfragmentable part of a packet
consists of the fixed header and some of the extension headers of the original
packet: all extension headers up to and including the Routing extension header,
or else the Hop-by-Hop extension header. If neither extension headers are
present, the unfragmentable part is just the fixed header.
The Next Header value of the last header of the unfragmentable part is set to 44
to indicate that a Fragment extension header follows. After the Fragment
extension header a fragment of the rest of the original packet follows.
The first fragment(s) hold the rest of the extension headers. After that the
rest of the payload follows. Each fragment is a multiple of 8 octets in
length, except the last fragment. Each Fragment extension header has its M
flag set to 1, except the last, whose flag is set to 0.
= Reassembly= The original packet is reassembled by
the receiving node by collecting all fragments and placing each fragment at
the right offset and discarding the Fragment extension headers of the
packets that carried them. Packets containing fragments need not arrive in
sequence; they will be rearranged by the receiving node.
If not all fragments are received within 60 seconds after receiving the first
packet with a fragment, reassembly of the original packet is abandoned and all
fragments are discarded. If the first fragment was received, a Time Exceeded
message is returned to the node originating the fragmented packet, if
the packet was discarded for this reason.
Receiving hosts must make a best-effort attempt to reassemble fragmented IP
datagrams that, after reassembly, contain up to 1500 bytes. Hosts are
permitted to make an attempt to reassemble fragmented datagrams larger
than 1500 bytes, but they are also permitted to silently discard any
datagram after it becomes apparent that the reassembled packet would be larger
than 1500 bytes. Therefore, senders should avoid sending fragmented IP
datagrams with a total reassembled size larger than 1500 bytes, unless they have
previous assurance that the receiver is capable of reassembling such large
datagrams. References