Technical Features of IPv6

IPv6 Protocol

The technical aspects of the IPv6 protocol are currently specified in RFC 2460, "Internet Protocol, Version 6 (IPv6) Specification", December 1998.

This RFC covers the IPv6 Packet Header syntax, IPv6 Extension Headers, packet size, the Flow Label field of the IPv6 Header, traffic classes and how IPv6 impacts upper layer protocols (e.g. UDP and TCP).

An IPv6 packet is a sequence of bytes sent over a networking medium. Every packet starts with the basic IPv6 Packet Header, which is followed by zero or more Extension Headers, then an ICMPv6 or Transport Layer Header (UDP, TCP or SCTP), and finally the packet payload (data).

  Basic Packet Header | Extension Headers | ICMPv6/Transport Header | Data

This is basically the same structure as IPv4 packets, except for the new Extension Headers.

 

IPv6 Packet Header

The basic IPv6 Packet Header contains the following fields:

  • IP version number (6)
  • Traffic Class (used for QoS, identical to Traffic Class field in IPv4)
  • Flow Label (used for tagging traffic flows for better QoS)
  • Payload Length (number of bytes of data in packet)
  • Next Header (specifies type of following Header)
  • Hop Limit (how many routers this packet can cross)
  • Source Address (IP address of original sender)
  • Destination Address (IP address of final packet recipient)

The basic IPv6 Packet Header is simpler than the IPv4 Packet Header (fewer fields), because some of the IPv4 fields were discarded, and others were moved to Extension Headers. Even so, it is twice as long as the IPv4 Packet Header (40 bytes for IPv6 vs. 20 bytes for IPv4). This is because of one new field (Flow Label), and the much larger source and destination addresses (16 bytes each for IPv6, vs. 4 bytes each for IPv4). This means there is 20 bytes of additional overhead for IPv6 (plus potentially even more from Extension Headers) on every packet, compared to IPv4. With short packets (under 100 bytes) this is significant. For longer packets (e.g. 1500 bytes) it is less of an issue.

The Next Header field of the basic Packet Header specifies the type of the next header. It can specify one of the possible Extension headers, an ICMPv6 header or one of the Transport Layer Headers. The start of the next header pointed to by the basic Packet Header is always 20 bytes after the start of the overall packet (because the basic Packet Header has a fixed length of 20).

 

Extension Headers

The IPv6 Extension Headers are new in IPv6. They allow IPv6 to be more extensible than IPv4 was (all but one bit of the 20 byte IPv4 Packet Header was accounted for years ago - there was no place to add new features). They also allow unfragmented packets to avoid carrying unnecessary overhead (the information needed to reassemble packet fragments). A few Extension Headers are defined in RFC 2460, but more have already been defined in other RFCs, such as the IPsec AH and ESP extension headers.

Every Extension Header contains a Next Header field which specifies the type of the header following the current one. As before, this can be any of the Extension Headers, an ICMPv6 header, or one of the Transport Layer Headers. Each Extension Header contains a Length field, that specifies the length of that header extension. The start of the following header will be the start of the current header plus this length.This allows construction of a chain of IPv6 headers, starting with the basic IPv6 Header, and ending with an ICMPv6 or Transport Layer Header. This chain can be parsed using the Length fields to extract each header (extension, ICMPv6 or Transport Layer) from the overall packet.

There are rules as to the order of Extension Headers. You can't just insert them in any old order. These rules are specified in RFC 2460 (or any other RFC that defines a new Extension Header).

extension header chains

 

The ICMPv6 / Transport Layer Header

After the basic Packet Header and any Extension Headers, there is either an ICMPv6 Header or a Transport Layer Header (for UDP, TCP or SCTP). There is actually one Next Header value that says "No Next Header". In this case, there is no ICMPv6 or Transport Layer Header, or data. This would be used if all of the necessary information was included in the Extension Headers.

The ICMPv6 Header (or Transport Layer Header) contains a Length field (but no Next Header field - this is the end of the chain. The start of the data field is the start of the ICMPv6/Transport Layer header plus this length. This makes it possible to parse the data field from the overall packet.

 

Example: ICMPv6 Packet Capture

The following is a capture of an ICMPv6 message (Router Solicitation) over IPv6, over Ethernet.

rs msg capture

 

The Ethernet header comes first (14 bytes), but is not a part of the IPv6 packet. It contains the source and destination MAC addresses (6 bytes each), plus a 2 byte Ethertype field. There is also an Ethernet trailer (not shown in this capture), after the IPv6 packet, that is part of the Ethernet frame. The trailer contains the 4 byte CRC-32 checksum. The real length of the entire Ethernet frame is 14 + 56 + 4 = 74 bytes, not counting the (up to) 8 byte Ethernet preamble (used for synchronization, also not shown).

The overall IPv6 packet starts 14 bytes into the Ethernet frame as shown.

The IPv6 Packet Header starts at offset 0 (within the overall IPv6 Packet), and is 40 bytes long (fixed length).  Its Next Header field contains the value 58 (for ICMPv6).

There are no packet extensions in this capture.

The ICMPv6 header begins immediately after the basic IPv6 Packet Header (offset 40 within the packet). The ICMPv6 header is 8 bytes long, followed by an 8 byte Source Link Layer Address option.

There is no payload in this message.

Therefore, the IPv6 packet is 40 + 8 + 8 = 56 bytes long. If you add the 14 byte Ethernet header, then the entire Ethernet frame is 56 + 14 = 70 bytes (which agrees with the information at the start of the capture).

 

Example: DNS packet capture

Here is a capture of a DNS query over UDP, over IPv6, over Ethernet:

dnsv6 capture

 

The Ethernet header comes first, but is not a part of the IPv6 packet. It contains the source and destination MAC addresses (6 bytes each), plus a 2 byte Ethertype field (0x86dd, for IPv6). So, the length of the Ethernet header is 6 + 6 +2 = 14 bytes. There is also an Ethernet trailer (not shown in this capture), after the IPv6 packet, that is part of the Ethernet frame. The trailer contains the 4 byte CRC-32 checksum. The real length of the entire Ethernet frame is 14 + 127 + 4 = 145 bytes, not counting the (up to) 8 byte Ethernet preamble (used for synchronization, also not shown).

The IPv6 packet starts 14 bytes into the Ethernet frame as shown.

The IPv6 Packet Header starts at offset 0 (within the IPv6 Packet), and is 40 bytes long (fixed length).  It contains the source and destination IPv6 addresses. Its Next Header field contains the value 17 (for UDP). The Payload Length field is 87 bytes, which includes the UDP Header (8 bytes) plus the actual data field (79 bytes).

There are no packet extensions in this capture, since the Next Header field contains an ICMPv6 or Transport Layer header protocol number (in this case, 17 for UDP).

The UDP Transport Layer header begins immediately after the basic IPv6 Packet Header (offset 40 within the packet). The UDP header is 8 bytes long. It contains the 16 bit source and destination ports, along with a 16 bit checksum.

The data (a DNS query) begins at offset 40 + 20 = 60 bytes in the IPv6 packet. The data is 79 bytes long (Payload length - 8 byte UDP header = 87 - 8 = 79 bytes).

Therefore, the IPv6 packet is 40 + 8 + 79 = 127 bytes long. If you add the 14 byte Ethernet header, then the entire Ethernet frame (not counting the 4 byte CRC-32) is 127 + 14 = 141 bytes (which agrees with the information at the start of the capture).

 

Example: SMTP packet capture

Here is a capture of the first packet of an SMTP session over TCP, over IPv6, over Ethernet.

SMTPv6 Capture

 

The Ethernet header comes first, but is not a part of the IPv6 packet. It contains the source and destination MAC addresses (6 bytes each), plus a 2 byte Ethertype field (0x86dd, for IPv6). So, the length of the Ethernet header is 6 + 6 +2 = 14 bytes. There is also an Ethernet trailer (not shown in this capture), after the IPv6 packet, that is part of the Ethernet frame. The trailer contains the 4 byte CRC-32 checksum. The real length of the entire Ethernet frame is 14 + 111 + 4 = 129 bytes, not counting the (up to) 8 byte Ethernet preamble (used for synchronization, also not shown).

The IPv6 packet starts 14 bytes into the Ethernet frame as shown.

The IPv6 Packet Header starts at offset 0 (within the IPv6 Packet), and is 40 bytes long (fixed length).  It contains the source and destination IPv6 addresses. Its Next Header field contains the value 6 (for TCP). The Payload Length field is 71 bytes, which includes the TCP Header (20 bytes) plus the actual data field (51 bytes).

There are no packet extensions in this capture, since the Next Header field contains an ICMPv6 or Transport Layer header protocol number (in this case, 6 for TCP).

The TCP Transport Layer header begins immediately after the basic IPv6 Packet Header (offset 40 within the packet). The TCP header is 20 bytes long. It contains the source and destination ports, along with quite a bit of TCP specific information.

The data ("220 mx.google.com ESMTP g1sm31842994oeq.6 - gsmpt\r\n") begins at offset 40 + 20 = 60 bytes in the IPv6 packet. The data is 51 bytes long (Payload length - 20 byte TCP header = 71 - 20 = 51 bytes).

Therefore, the IPv6 packet is 40 + 20 + 51 = 111 bytes long. If you add the 14 byte Ethernet header, then the entire Ethernet frame (not counting the 4 byte CRC-32) is 111 + 14 = 125 bytes (which agrees with the information at the start of the capture).

 

IPv6 Packet Size

The IPv6 Packet Header is a fixed 40 bytes in length. Its Payload Length field specifies the number of bytes in the Extension Headers, ICMPv6/Transport Layer Headers and data field combined. It can be a 16 bit value up to 65,535. Therefore the upper limit of IPv6 packet size is 65,535 + 40 = 65,575 bytes. The smallest IPv6 packet would consist of a basic Packet Header with the No Next Header protocol number (59). There would be no extension headers, no ICMPv6/Transport Layer header or data. Although it would not be particularly useful, the lower limit for IPv6 packet size is 40 bytes.

There is an extension header that includes a replacement Payload Length that is specified with a 32 bit field (jumbograms). If using this, the maximum packet size is over 4 gigabytes. Not all devices support this extension header. These are not often used and there is not much operational experience with these. I would not recommend using them in a production environment.

IPv4 a minimum MTU of 586 bytes. For IPv6, the minimum MTU is 1280 bytes. This means any path that carries IPv6 must be able to handle packets of up to 1280 bytes without having to fragment them.

 

IPv6 Packet Fragmentation

In IPv4, any node can fragment packets, or reassemble them. In IPv6, only the original source node is supposed to fragment a packet. Any router that receives a packet that is too big to relay onward must discard that packet and send a "Packet Too Big" ICMPv6 message to the source address of the failed packet (which should be the original sender, along with the MTU of the onward path). The sending node can then reduce the packet size, or fragment the packet if this is not possible. The "fragmentation" extension header is used to provide information required to reassemble the original packet. Only the final destination node should ever need to reassemble fragmented packets.

Firewall gateways are allowed to reassemble fragmented packets in order to perform deep packet inspection, but if the firewall decides to forward the packet, it should forward the original fragments.  If the firewall decides to reject the packet, then it should send an ICMPv6 "unable to deliver" message to the source address of the reassembled packet (which should be the original sender). This error message is sent only regarding the first fragment of the original packet, not every fragment. If the firewall decides to drop the packet, no ICMPv6 message is sent.

 

Path MTU Discovery

In IPv6, the sending node starts with using the MTU of the link it is attached to for maximum packet size. If it gets packets returned from a given path with a "Packet too big" message, it will reduce the maximum packet size for further packets sent along that path to the returned MTU. Most implementations will try resuming use of the MTU of the local link every 10 minutes or so, to see if it can resume sending larger packets. If not, it will again reduce maximum packet size as needed to get the packet all the way to the destination.

RFC 4821, "Packetization Layer Path MTU Discovery", March 2007, documents this, including an algorithm for incrementally increasing packet size in an efficient manner.

 

Other Technical Features of IPv6

There are a number of technical features of IPv6 not covered in RFC 2460. These are covered in other articles on this website. These include: