IPv6 Fragmentation

Fragmentation has been a frequent source of security vulnerabilities in IPv4, and for good reason. With fragmented IPv4 packets, the layer 4 header information is not available in the second through the last fragment. The process of fragmentation and fragment reassembly can create unexpected and harmful behaviors in intermediate nodes (such as firewalls and routers) and end nodes (such as user computers). In this blog, I will discuss how fragmentation is implemented in IPv6 and how it varies from IPv4 fragmentation.

If there is one myth about IPv6 that otherwise clueful engineers have clung to, it is the misconception that packets cannot be fragmented in IPv6. This is only partially true. Intermediate devices, such as routers and firewalls, cannot fragment a packet, but the source node can fragment packets. As such, end nodes and intermediate nodes must know how to properly handle fragmented packets.

There are two primary concerns when a packet is fragmented in IPv6. First, fragmentation requires the use of the fragmentation extension header. As such, the byte offset in the packet for the layer 4 header will be shifted 8 bytes because of the fragmentation extension header and nodes must know how to locate the layer 4 header. Second, like IPv4, only one fragment will contain the layer 4 header (the layer 4 header is typically the first packet although there are scenarios where the layer 4 header could appear in the second fragment). The remaining fragments of the packet will not contain the layer 4 header and the intermediate device must either correlate the layer 4 information from the fragment that does contain the layer 4 header with other fragments or forward the fragments without knowledge of the layer 4 information for the assembled packet that the fragment is associated with.

Unlike IPv4, because intermediate nodes cannot fragment IPv6 fragments, it is essential that the source node either send a packet that is the same as or smaller than the maximum transmission unit (MTU) size for the network path or break packets into fragments that are the same size or smaller than the MTU size for the path.

Path MTU Discovery (PMTUD) is nice to have in IPv4(1), but PMTUD is crucial in IPv6(2). When an intermediate node receives a packet that is too big for the MTU of the forwarding path, the intermediate mode must drop the packet and send an ICMPv6 “packet too big” back to the source node. Since an intermediate node cannot fragment an IPv6 packet; it is critical that intermediate nodes allow the “packet too big” messages from other intermediate nodes to be forwarded. If the node sourcing the large packets does not receive the “packet too big” message, there is a considerable risk that the source node will continue to transmit packets that will be dropped before they reach their destination. IETF RFC 4890 provides additional details on ICMPv6 filtering recommendations(3).

If the source node does not perform PMTU discovery, it must send packets no larger than the minimum IPv6 MTU size of 1,280 bytes. Some Internet-based services eliminate PMTU discovery problems by sourcing IPv6 packets with an MTU of 1,280 bytes(4). At the cost of not being able to transit larger packets, sending IPv6 packets no larger than 1,280 bytes ensures that the packet will not be dropped because it is too large to be transited across a network path and the source does not need to rely upon a “packet-too-big” ICMPv6 message. The approach of setting the MTU to 1,280 bytes by default is safe, but, as found during World IPv6 Day, is also controversial(5).

Fragmentation in IPv6 neighbor discovery has also caused some concern recently because of its potential use as an evasion technique for RA-Guard(6). A solution that has been proposed is elimination of all extension headers in neighbor discovery packets(7).

Sources:
(1) IETF RFC 1191, “Path MTU Discovery,” Mogel, J and Deering, S, November 1990.
(2) IETF RFC 1981, “Path MTU Discovery for IPv6” Macann, J, Deering, S and Mogel, J, August 1996.
(3) IETF RFC 4890, “Recommendations for Filtering ICMPv6 Messages in Firewalls,” Davies, E and Mohacsi, J, May 2007.
(4) IETF RFC 2460, “Internet Protocol, Version 6 (IPv6) Specification,” Deering, S and Hinden, R, December 1998.
(5) See discussion on the IPv6 operations e-mail list: http://lists.cluenet.de/pipermail/ipv6-ops/2011-June/005755.html
(6) Internet-Draft, “IPv6 Router Advertisement Guard (RA-Guard) Evasion,” Gont, F, May 31, 2011, http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt
(7) Internet-Draft, “Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery,” Gont, F, May 31, 2011, http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-00.txt