Content deleted Content added
→Hop-by-hop options and destination options: hop-by-hop can be ignored since RFC8200. |
m Reverted edits by 2600:100F:B1B1:DD02:0:1D:E02C:C501 (talk) (HG) (3.4.13) |
||
| (98 intermediate revisions by 38 users not shown) | |||
Line 1:
{{short description|Smallest message entity exchanged using Internet Protocol version 6}}
An '''IPv6 packet''' is the smallest message entity exchanged using [[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 [[
IPv6 packets are typically transmitted over
In contrast to IPv4, [[router (computing)|routers]] do not fragment IPv6 packets larger than the [[maximum transmission unit]] (MTU), it is the sole responsibility of the originating node. A minimum MTU of 1,280 [[octet (computing)|octets]] is mandated by IPv6, but [[Host (network)|hosts]] are "strongly recommended" to use [[Path MTU Discovery]] to take advantage of MTUs greater than the minimum.{{Ref RFC|8200}}
Since July 2017, the [[Internet Assigned Numbers Authority]] (IANA)
==Fixed header==
The fixed header starts an IPv6 packet and has a size of 40 [[octet (computing)|octets]] (320 [[bit|bits]]).
{{APHD|start|title=Fixed header format}}
{{APHD|0|bits1=4|bits2=8|bits3=20|field1=Version|field2=Traffic class|field3=Flow label}}
{{APHD|4|bits1=16|bits2=8|bits3=8|field1=Payload length|field2=Next header|field3=Hop limit}}
{{APHD|8|bits1=128|field1=Source address}}
{{APHD|24|bits1=128|field1=Destination address}}
{{APHD|end}}
;{{APHD|def|name=Version|length=4 bits|text=The constant 6 (bit sequence {{mono|0110}}).}}
;{{anchor|Traffic Class field}}{{APHD|def|name=Traffic Class|length=6+2 bits|text=The bits of this field hold two values. The six most-significant bits hold the [[differentiated services field]] (DS field), which is used to classify packets.{{Ref RFC|2474}}{{Ref RFC|3260}} Currently, all standard DS fields end with a '0' bit. Any DS field that ends with two '1' bits is intended for local or experimental use.{{Ref RFC|4727}} The remaining two bits are used for [[Explicit Congestion Notification]] (ECN);{{Ref RFC|3168}} priority values subdivide into ranges: traffic where the source provides congestion control and non-congestion control traffic.}}
;{{APHD|def|name=Flow Label|length=20 bits|text=A high-entropy identifier of a flow of packets between a source and destination. A flow is a group of packets, e.g., a TCP session or a media stream. The special flow label 0 means the packet does not belong to any flow (using this scheme). An older scheme identifies flow by source address and port, destination address and port, protocol (value of the last ''Next Header'' field).{{Ref RFC|6437}} It has further been suggested that the flow label be used to help detect spoofed packets.<ref>[http://tools.ietf.org/html/draft-blake-ipv6-flow-label-nonce-02 Use of the IPv6 Flow Label as a Transport-Layer Nonce to Defend Against Off-Path Spoofing Attacks]</ref>}}
;{{APHD|def|name=Payload Length|length=16 bits|text=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 [[#Jumbogram|Jumbo Payload]] option.{{Ref RFC|2675}}}}
;{{APHD|def|name=Next Header|length=8 bits|text=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 (see [[List of IP protocol numbers]]).}}
;{{APHD|def|name=Hop Limit|length=8 bits|text=Replaces the [[time to live]] field in IPv4. This value is decremented by one at each forwarding node and the packet is discarded if it becomes 0. However, the destination node should process the packet normally even if received with a hop limit of 0.}}
;{{APHD|def|name=Source Address|length=128 bits|text=The unicast [[IPv6 address]] of the sending node.}}
;{{APHD|def|name=Destination Address|length=128 bits|text=The IPv6 unicast or multicast address of the destination node(s).}}
In order to increase performance, and since current [[link layer]] technology and transport layer protocols are assumed to provide sufficient error detection,{{Ref RFC|1726|section=2.6}} the header has no [[checksum]] to protect it.{{Ref RFC|8200}}
==Extension headers==
Extension headers carry optional [[internet layer]] information and are placed between the fixed header and the upper-layer protocol header.<ref name=rfc8200 /> Extension 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. 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 appear at most once, except for the ''Destination Options'' header extension, which may appear twice.<ref name=rfc8200 />
If a node does not recognize a specific extension header, it should discard the packet and send a ''Parameter Problem'' message ([[ICMPv6]] type 4, code 1).<ref name=rfc8200 />
{| class="wikitable" <!-- Listed in order as recommended by RFC8200 -->
|-
! Extension
! [[List of IP protocol numbers|
! Description
|-
| ''[[IPv6 packet#Hop-by-hop options and destination options|Hop-by-Hop Options]]''
| | 0 || Options that need to be examined by all devices on the path
|-
| ''[[IPv6 packet#Routing|Routing]]''
| | 43 || Methods to specify the route for a datagram (used with [[Mobile IPv6]])
|-
| ''[[IPv6 packet#Fragment|Fragment]]''
| | 44 || Contains parameters for fragmentation of datagrams
|-
| ''[[IPv6 packet#Authentication Header (AH) and Encapsulating Security Payload (ESP)|Authentication Header (AH)]]''
| | 51 || Contains information used to verify the authenticity of most parts of the packet
|-
| ''[[IPv6 packet#Authentication Header (AH) and Encapsulating Security Payload (ESP)|Encapsulating Security Payload (ESP)]]''
| | 50 || Carries encrypted data for secure communication
|-
| ''[[IPv6 packet#Hop-by-hop options and destination options|Destination Options]]'' (before upper-layer header) <!-- May appear twice in the chain of headers. -->
| | 60 || Options that need to be examined only by the destination of the packet
|-
| ''Mobility'' (currently without upper-layer header) <!-- RFC 6275 -->
| | 135 || Parameters used with [[Mobile IPv6]]
|-
| ''Host Identity Protocol'' || 139 || Used for [[Host Identity Protocol]] version 2 (HIPv2)
|-
| ''Shim6 Protocol'' || 140 || Used for [[Shim6]]
|-
| Reserved || 253 || Used for experimentation and testing{{Ref RFC|3692}}{{Ref RFC|4727}}
|-
| Reserved || 254 || Used for experimentation and testing
|}
Value 59 (No Next Header) 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.<ref name=rfc8200/>{{rp|4.7}}
===Hop-by-hop options and destination options===
{{anchor|hop-by-hop options|destination options}}
The ''Hop-by-Hop Options'' extension header may be examined and altered by all nodes on the packet's path, including sending and receiving nodes. (For authentication, option values that may change along the path are ignored.) The ''Destination Options'' extension header needs 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, containing options and padding, are added to the header repeatedly until all options are represented.
{{APHD|
{{APHD|0|bits1=8|bits2=8|bits3=16|field1=Next header|field2=Header extension length|field3=Options and padding}}
{{APHD|4|bits1=32|field1=Options and padding}}
{{APHD|8|bits1=0|background1=linen|field1=Optional: more Options and padding}}
{{APHD|end}}
;{{APHD|def|name=Next Header|length=8 bits|text=Specifies the [[List of IP protocol numbers|type]] of the next header.}}
;{{APHD|def|name=Header extension length|length=8 bits|text=Length of this header in 8-octet units, not including the first 8 octets.}}
;{{APHD|def|name=Options and padding|length=variable|text=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 [[Type–length–value|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.<ref name=rfc8200/>
{{APHD|start|title=''Routing'' extension header format}}
{{APHD|0|bits1=8|bits2=8|bits3=8|bits4=8|field1=Next header|field2=Header extension length|field3=Routing type|field4=Segments left}}
{{APHD|4|bits1=32|field1=Type-specific data}}
{{APHD|8|bits1=0|background1=linen|field1=Optional: more type-specific data...}}
{{APHD|end}}
;{{APHD|def|name=Next header|length=8 bits|text=Indicates the type of the next header.}}
;{{APHD|def|name=Header extension length|length=8 bits|text=The length of this header, in multiples of 8 octets, not including the first 8 octets.}}
;{{APHD|def|name=Routing type|length=8 bits|text=A value between 0 and 255, as assigned by [[IANA]].<ref name=iana_routing_options>{{Cite web|url=https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml|title=Internet Protocol Version 6 (IPv6) Parameters: Routing Types|publisher=[[IANA]]|access-date=2021-10-15}}</ref>}}
:{| class="wikitable" style="text-align: left"
!| Type
Line 303 ⟶ 103:
| 0
| Deprecated
| 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... |
|-
| 1
| Deprecated
| Used for the Nimrod
|-
| 2
| Allowed
| A
|-
| 3
| Allowed
| RPL Source Route Header{{Ref RFC|6554}} for low-power and lossy networks.
|-
| 4
| Allowed
| Segment Routing Header (SRH).{{Ref RFC|8754}}
|-
| 253 || Private use
| May be used for testing, not for actual implementations. ''RFC3692-style Experiment 1''.<ref name=rfc3692></ref>
|-
| 254 || Private
| May be used for testing, not for actual implementations. ''RFC3692-style Experiment 2''.<ref name=rfc3692></ref>
|}
;
;
===Fragment===
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.
{{APHD|start|title=''Fragment'' extension header format}}
{{APHD|0|bits1=8|bits2=8|bits3=13|bits4=2|field1=Next Header|field2=Reserved|field3=Fragment offset|field4=Res|hint4=Reserved2|field5=M|hint5=M Flag}}
{{APHD|4|bits1=32|field1=Identification}}
{{APHD|end}}
;{{APHD|def|name=Next header|length=8 bits|text=Identifies the type of the next header.}}
;{{APHD|def|name=Reserved|length=8 bits|constraint=Reserved == 0|text=Initialized to all zeroes.}}
;{{APHD|def|name=Fragment offset|length=13 bits|text=Offset, in 8-octet units, relative to the start of the fragmentable part of the original packet.}}
;{{APHD|def|name=Reserved2|short=Res|length=2 bits|constraint=Res == 0|text=Reserved; initialized to zeroes.}}
;{{APHD|def|name=M Flag|short=M|length=1 bit|text=1 means more fragments follow; 0 means last fragment.}}
;{{APHD|def|name=Identification|length=32 bits|text=Packet identification value, generated by the source node. Needed for reassembly of the original packet.}}
===Authentication Header (AH) and Encapsulating Security Payload (ESP)===
The ''[[
==Payload==
The fixed and optional IPv6 headers are followed
===Standard payload length===
The [[#Fixed header|payload length field of IPv6]] (and [[IPv4#Header|IPv4]]) has a size of 16 bits, capable of specifying a maximum length of [[65535 (number)|{{Val|65535}}]] octets for the payload. In practice, hosts determine the maximum usable payload length using [[Path MTU Discovery]] (yielding the minimum [[maximum transmission unit|MTU]] along the path from sender to receiver), to avoid having to fragment packets. Most link-layer protocols have MTUs considerably smaller than {{Val|65535}} octets.
===Jumbogram===
{{See also|Jumbogram#IPv6 jumbograms}}
An optional feature of IPv6, the ''jumbo payload'' option in a ''Hop-By-Hop Options'' extension header,<ref name=rfc2675/> allows the exchange of packets with payloads of up to one octet less than 4{{nbsp}}[[Gigabyte|GB]] (2<sup>32</sup>{{nbsp}}−{{nbsp}}1{{nbsp}}= [[4294967295 (number)|{{Val|4294967295}}]] octets), by making use of a 32-bit length field. Packets with such payloads are called [[jumbogram]]s.
Since both [[Transmission Control Protocol|TCP]] and [[User Datagram Protocol|UDP]] include fields limited to 16 bits (length, urgent data pointer), support for IPv6 jumbograms requires modifications to the
==Fragmentation==
Unlike in IPv4, IPv6 [[router (computing)|router]]s
===Fragmenting===
A packet containing
The
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}}
===Reassembly===
The original packet is reassembled by the receiving node by collecting all fragments and placing each fragment at
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.
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
===Security===
Research has shown that the use of fragmentation can be leveraged to evade network security controls. As a result,
==References==
{{Reflist
{{IPv6}}
| |||