IPv6 packet: Difference between revisions

An '''IPv6 packet''' is the smallest message entity exchanged using [[IPv6|Internet Protocol version 6]] (IPv6). [[Network packet|Packet]]s consist of control information for addressing and routing and a [[payload (computing)|payload]] of user data. The control information in IPv6 packets is subdivided into a mandatory fixed [[header (computing)|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]] (e.g., [[ICMPv6]]) or [[link layer]] (e.g., [[OSPF]]) instead.

Since July 2017, the [[Internet Assigned Numbers Authority]] (IANA) ishas been responsible for registering all IPv6 parameters that are used in IPv6 packet headers.<ref name=rfc8200/>

The fixed header starts an IPv6 packet and has a size of 40 [[octet (computing)|octets]] (320 [[bit|bits]]).<ref{{Ref name=rfc8200RFC|8200}} />The bytes of the multi-byte fields are in the [[network byte order]].

There are several extension headers defined, and new extension headers may be defined in the future. Most extension headers are examined and processed at the packet's destination. ''Hop-by-Hop Options'' can be processed and modified by intermediate nodes and, if present, must be the first extension. All extension headers are optional and should only appear at most once, except for the ''Destination Options'' header extension, which may appear twice.<ref name=rfc8200 />

:{| class="wikitable" <!-- Listed in order as recommended by RFC8200 -->

| ''Host Identity Protocol'' || 139 || Used for [[Host Identity Protocol]] version 2 (HIPv2)<ref name=rfc7401>{{CiteRef IETFRFC|rfc=7401|title=Host Identity Protocol Version 2 (HIPv2)|editor=R. Moskowitz|author1=T. Heer|author2=P. Jokela|author3=T. Henderson|date=April 2015|publisher=[[Internet Engineering Task Force]] (IETF)|issn=2070-1721}}</ref>

| ''Shim6 Protocol'' || 140 || Used for [[Shim6]]<ref name=rfc5533>{{CiteRef IETFRFC|rfc=5533|title=Shim6: Level 3 Multihoming Shim Protocol for IPv6|author1=E. Nordmark|author2=M. Bagnulo}}

| Due to the fact that with Routing Header type 0 a simple but effective [[denial-of-service attack]] could be launched,<ref>{{cite web |url=http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf |title=IPv6 Routing Header Security |author=Philippe Biondi, Arnoud Ebalard |date=April 2007 |publisher=[[EADS]] |quote=Type 0: the evil mechanism... |access-date=3 December 2010}}</ref> this header was deprecated in 2007 and host and routers are required to ignore these headers.<ref name=rfc5095>{{CiteRef IETFRFC|rfc=5095|author=J. Abley|author2=P. Savola|author3=G. Neville-Neil|date=December 2007|title=Deprecation of Type 0 Routing Headers in IPv6}}</ref>

| Used for the Nimrod project<ref name=rfc1992>{{CiteRef IETFRFC|rfc=1992|author=I. Castineyra|author2=N. Chiappa|author3=M. Steenstrup|date=August 1996|title=The Nimrod Routing Architecture}}</ref> funded by [[DARPA]]. It was deprecated in 2009.

; ''{{APHD|def|name=Segments Left'' (|length=8 bits): |text=Number of nodes this packet still has to visit before reaching its final destination.}}

; ''{{APHD|def|name=Type-specific Data'' (|length=variable): |text=Data that belongs to this type of routing header.}}

In order to send a packet that is larger than the path [[Maximum transmission unit|MTU]], the sending node splits the packet into fragments. The ''Fragment'' extension header carries the information necessary to reassemble the original (unfragmented) packet.<ref{{Ref name=rfc8200/>RFC|8200}}

The ''[[IPsec#Authentication Header|Authentication Header]]'' and the ''[[IPsec#Encapsulating Security Payload|Encapsulating Security Payload]]'' are part of [[IPsec]] and are used identically in IPv6 and in IPv4.{{Ref RFC|4302}}{{Ref RFC|4303}}

Since both [[Transmission Control Protocol|TCP]] and [[User Datagram Protocol|UDP]] include fields limited to 16&nbsp;bits (length, urgent data pointer), support for IPv6 jumbograms requires modifications to the transport layer protocol implementation.<ref name=rfc2675 /> Jumbograms are only relevant for links that have a [[maximum transmission unit|MTU]] larger than {{Val|65583}} octets <!-- The RFC mentions 65575 octets (payload + fixed header) but ignores the fact that you need a Hop-by-Hop extension header to enable payloads over 65535 octets. -->(more than {{Val|65535}} octets for the payload, plus 40 octets for the fixed header, plus 8 octets for the ''Hop-by-Hop'' extension header). Only a few link-layer protocols can process packets larger than {{Val|65535}} octets.{{Citation needed|date=July 2010}}

In any case, the last header of the per-fragment part has its ''Next Header'' value set to <tt>{{mono|44</tt>}} to indicate that a ''Fragment'' extension header follows. Each ''Fragment'' extension header has its ''M'' flag set to <tt>{{mono|1</tt>}} (indicating more fragments follow), except the last, whose flag is set to <tt>{{mono|0</tt>}}. Each fragment's length is a multiple of 8 octets, except, potentially, the last fragment.

The per-fragment headers were historically called the "unfragmentable part", referring to pre-2014 possibility of fragmenting the rest of the header. Now no headers are actually fragmentable.{{Ref RFC|7112}}<!--[[User:Kvng/RTH]]-->

The original packet is reassembled by the receiving node by collecting all fragments and placing each fragment at theits rightindicated 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 (which contains the fixed header) and one or more others are missing, a ''Time Exceeded'' message ([[ICMPv6]] type 3, code 1) is returned to the node originating the fragmented packet, if the packet was discarded for this reason.

When reassembling node detects a fragment that overlaps with another fragment, the reassembly of the original packet abortsis aborted and all fragments must be silentlyare dropped.<ref name=rfc8200 /> The only possible exception is that aA node may optionally ignore the exact duplicates of a fragment instead of treating exact duplicates as overlapping each other.<ref name=rfc8200 />

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 1,500 bytes, but they are also permitted to silently discard any datagram after it becomes apparent that the reassembled packet would be larger than 1,500 bytes. Therefore, senders should avoid sending fragmented IP datagrams with a total reassembled size larger than 1,500 bytes, unless they have previous assuranceknowledge that the receiver is capable of reassembling such large datagrams.

Research has shown that the use of fragmentation can be leveraged to evade network security controls. As a result, in 2014 the earlier allowance for overflowing the IPv6 header chain beyond the first fragment became forbidden in order to avoid some very pathological fragmentation cases.<ref name=rfc7112/> Additionally, as a result of research on the evasion of Router Advertisement Guard,{{Ref RFC|7113}} the use of fragmentation with neighbor[[Neighbor discoveryDiscovery]] is deprecated, and the use of fragmentation with [[Secure Neighbor Discovery]] (SEND) is discouraged.{{Ref RFC|6980}}