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]].

:{| 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.

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 knowledge that the receiver is capable of reassembling such large datagrams.<!--[[User:Kvng/RTH]]-->

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}}