Parts of this article (those related to RFC8200) need to be updated.(November 2017)
An IPv6 packet is the smallest message entity exchanged via the Internet Protocol across an Internet Protocol version 6 (IPv6) 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 (e.g., ICMPv6) or Link Layer (e.g., OSPF) 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).
- 1 Fixed header
- 2 Extension headers
- 3 Payload
- 4 Fragmentation
- 5 References
Fixed header format Offsets Octet 0 1 2 3 Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 Version Traffic Class Flow Label 4 32 Payload Length Next Header Hop Limit 8 64 Source Address 12 96 16 128 20 160 24 192 Destination Address 28 224 32 256 36 288
- Version (4 bits)
- The constant 6 (bit sequence 0110).
- Traffic Class (6+2 bits)
- The bits of this field hold two values. The 6 most-significant bits hold the Differentiated Services (DS) field, which is used to classify packets. 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.
- The remaining two bits are used for Explicit Congestion Notification (ECN); priority values subdivide into ranges: traffic where the source provides congestion control and non-congestion control traffic.
- Flow Label (20 bits)
- Originally created for giving real-time applications special service. When set to a non-zero value, it 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 (16 bits)
- 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 (8 bits)
- 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).
- Hop Limit (8 bits)
- 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 (128 bits)
- The IPv6 address of the sending node.
- Destination Address (128 bits)
- 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 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 (ICMPv6 type 4, code 1). When a Next Header value 0 appears in a header other than the fixed header a node should do the same.
Extension Header Type Description Hop-by-Hop Options 0 Options that need to be examined by all devices on the path. Destination Options (before routing header) 60 Options that need to be examined only by the destination of the packet. Routing 43 Methods to specify the route for a datagram (used with Mobile IPv6). Fragment 44 Contains parameters for fragmentation of datagrams. Authentication Header (AH) 51 Contains information used to verify the authenticity of most parts of the packet. Encapsulating Security Payload (ESP) 50 Carries encrypted data for secure communication. Destination Options (before upper-layer header) 60 Options that need to be examined only by the destination of the packet. Mobility (currently without upper-layer header) 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. 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.
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.
Hop-by-Hop Options and Destination Options extension header format Offsets Octet 0 1 2 3 Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 Next Header Hdr Ext Len Options and Padding 4 32 Options and Padding 8 64 Optional: more Options and Padding ... 12 96
- Next Header (8 bits)
- Specifies the type of the next header.
- Hdr Ext Len (8 bits)
- Length of this header in 8-octet units, not including the first 8 octets.
- Options (variable)
- 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.
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.
Routing extension header format Offsets Octet 0 1 2 3 Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 Next Header Hdr Ext Len Routing Type Segments Left 4 32 Type-specific Data 8 64 Optional: more Type-specific Data ... 12 96
- Next Header (8 bits)
- Indicates the type of the next header.
- Hdr Ext Len (8 bits)
- The length of this header, in multiples of 8 octets, not including the first 8 octets.
- Routing Type (8 bits)
- A value between 0 and 255, as assigned by IANA.
Type Status Comment 0 Deprecated 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 since 2007 and host and routers are required to ignore these headers.
1 Deprecated Used for the Nimrod project funded by DARPA. It is deprecated since 2009. 2 Allowed A limited version of type 0 and is used for Mobile IPv6, where it can hold the Home Address of the Mobile Node. 3 Allowed RPL Source Route Header for Low-Power and Lossy Networks. 253 Private Use May be used for testing, not for actual implementations. RFC3692-style Experiment 1. 254 Private Use May be used for testing, not for actual implementations. RFC3692-style Experiment 2.
- Segments Left (8 bits)
- Number of nodes this packet still has to visit before reaching its final destination.
- Type-specific Data (variable)
- Data that belongs to this type of routing header.
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 (unfragmented) packet.
Fragment extension header format Offsets Octet 0 1 2 3 Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 Next Header Reserved Fragment Offset Res M 4 32 Identification
- Next Header (8 bits)
- Identifies the type of the next header.
- Reserved (8 bits)
- Initialized to all zeroes.
- Fragment Offset (13 bits)
- Offset, in 8-octet units, relative to the start of the fragmentable part of the original packet.
- Res (2 bits)
- Reserved; initialized to zeroes.
- M Flag (1 bit)
- 1 means more fragments follow; 0 means last fragment.
- Identification (32 bits)
- Packet identification value, generated by the source node. Needed for reassembly of the original packet.
Authentication Header (AH) and Encapsulating Security Payload (ESP)
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 (and IPv4) has a size of 16 bits, capable of specifying a maximum length of 53565 octets for the payload. In practice, hosts determine the maximum usable payload length using Path MTU discovery (yielding the minimum MTU along the path from sender to receiver), to avoid having to fragment packets. Most Link Layer protocols have MTUs considerably smaller than 535 octets. Also, 65 is a valid payload length for UDP. 0
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 octet less than 4 GB (232 − 1 = 2949672954 octets), 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 (length, urgent data pointer), support for IPv6 jumbograms requires modifications to the Transport Layer protocol implementation. Jumbograms are only relevant for links that have a MTU larger than 583 octets (more than 65535 octets for the payload, plus 40 octets for the fixed header, plus 8 octets for the Hop-by-Hop extension header). Only few Link Layer protocols can process packets larger than 65535 octets.[ 65citation needed]
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.
A packet containing a fragment of an original (larger) packet consists of two parts: the unfragmentable part of the original packet (which is the same for all fragments), and a piece of the fragmentable part of the original packet, identified by a Fragment Offset. The Fragment Offset of the first ("leftmost") fragment is 0.
The unfragmentable part of a packet consists of the fixed header and some of the extension headers of the original packet (if present): 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 (extension) 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 (if present). 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 (indicating more fragments follow), except the last, whose flag is set to 0.
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 (which contains the fixed header), 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.
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.
Research has shown that the use of fragmentation can be leveraged to evade network security controls. As a result, it is now required that the first fragment of an IPv6 packet contains the entire IPv6 header chain, such that some very pathological fragmentation cases are forbidden. Additionally, as a result of research on the evasion of Router Advertisement Guard, the use of fragmentation with Neighbor Discovery is deprecated, and the use of fragmentation with Secure Neighbor Discovery (SEND) is discouraged.
- S. Deering; R. Hinden (July 2017), Internet Protocol, Version 6 (IPv6) Specification, Internet Engineering Task Force (IETF), RFC Obsoletes RFC 2460.
- K. Nickols; S. Blake; F. Baker; D. Black (December 1998), Definition of the Differentiated Service Field (DS Field) in the IPv4 and IPv6 Headers, RFC
- D. Grossman (April 2002), New Terminology and Clarifications for DiffServ, RFC
- B. Fenner (November 2006), Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers, Network Working Group, RFC
- K. Ramakrishnan; S. Floyd; D. Black (September 2001), The Addition of Explicit Congestion Notification (ECN) to IP, RFC
- B. Wijnen (September 2003), Textual Conventions for IPv6 Flow Label, RFC
- S. Amante; B. Carpenter; S. Jiang; J. Rajahalme (November 2011), IPv6 Flow Label Specification, RFC
- D. Borman; S. Deering; R. Hinden (August 1999), IPv6 Jumbograms, RFC
- C. Partridge; F. Kastenholz (December 1994), "6.2", Technical Criteria for Choosing IP The Next Generation (IPng), RFC
- T. Heer; P. Jokela; T. Henderson (April 2015), R. Moskowitz, ed., Host Identity Protocol Version 2 (HIPv2), Internet Engineering Task Force (IETF), ISSN 2070-1721, RFC
- E. Nordmark; M. Bagnulo (June 2009), Shim6: Level 3 Multihoming Shim Protocol for IPv6, Networking Working Group, RFC
- T. Narten (January 2004), Assigning Experimental and Testing Numbers Considered Useful, Network Working Group, RFC BCP 82. Updates RFC 2434.
- "Internet Protocol Version 6 (IPv6) Parameters: Routing Types". IANA. Retrieved 2017-11-17.
- Philippe Biondi, Arnoud Ebalard (April 2007). "IPv6 Routing Header Security" (pdf). EADS. Retrieved 3 December 2010.
Type 0: the evil mechanism...
- J. Abley; P. Savola; G. Neville-Neil (December 2007), Deprecation of Type 0 Routing Headers in IPv6, RFC
- I. Castineyra; N. Chiappa; M. Steenstrup (August 1996), The Nimrod Routing Architecture, RFC
- J. Hui; JP. Vasseur; D. Culler; V. Manral (March 2012), An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL), Internet Engineering Task Force (IETF), RFC
- S. Kent (December 2005), IP Authentication Header, RFC
- S. Kent (December 2005), IP Encapsulating Security Payload, RFC
- F. Gont; V. Manral; R. Bonica (January 2014), Implications of Oversized IPv6 Header Chains, RFC
- F. Gont (February 2014), Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard), RFC
- F. Gont (August 2013), Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery, RFC